Sender und Quellen

Was ein Sender ist

Eine Quelle plus ein Ziel. Die Quelle ist eine URL, von der Castmux abruft; das Ziel ist eine IPv4-Adresse mit Port, an die es MPEG-TS sendet. Alles andere am Sender — Engine, Auflösungsprofil, Verhalten bei On-Demand-Streaming, erwartete Bitrate — verändert, wie diese eine Leitung betrieben wird, nicht, was sie transportiert.

Sender sind voneinander unabhängig. Jeder wird für sich überwacht, für sich neu gestartet und für sich gemessen. Ein ausgefallener Ursprungsserver bei einem Sender stört die anderen also nicht.

Quelltypen

Über IP werden heute vier Quelltypen unterstützt: HLS, SRT, RTMP und einfaches MPEG-TS, Letzteres entweder per UDP-Multicast oder per HTTP. Die folgende Tabelle zeigt, was darüber hinaus unterstützt wird und was geplant ist.

Quelle	Status	Hinweise
HLS	Unterstützt	Master-Playlist oder eine einzelne Media-Playlist. Wie eine Stufe ausgewählt wird, steht unter Auflösungsprofile.
SRT	Unterstützt	Caller-Modus, vollständig über die URL konfiguriert. Die Latenz wird automatisch ermittelt.
RTMP	Unterstützt	Nur mit der Remux-Engine. Typischerweise ein lokaler Encoder, der in das Netzwerk des Geräts sendet.
UDP-Multicast (MPEG-TS)	Unterstützt	Erneuter Empfang eines vorhandenen Multicast-Signals, etwa des Ausgangs einer anderen Kopfstation. Quelltyp mpegts mit einer udp://-URL. Siehe MPEG-TS-Quellen.
HTTP-MPEG-TS	Unterstützt	Ein einfacher Transport Stream über HTTP, ohne Playlist. Quelltyp mpegts mit einer http://- oder https://-URL.
RTP-Multicast	Geplant	In RTP verpackter Transport Stream. Heute wird nur einfaches MPEG-TS über UDP gelesen. geplant
RTSP-Kameras	Geplant	Für Signale aus Lobby, Kapelle und Videoüberwachung. geplant
DVB-S/S2-Tunereingang	Geplant	Satellitenprogramme, die per Antenne statt über IP empfangen werden. Heute nicht verfügbar: Es gibt keinerlei Tunereingang, kaufen Sie also keine Tunerkarte dafür. geplant
DVB-T-Tunereingang	Geplant	Terrestrische Programme, per Antenne empfangen. geplant
DVB-C-Tunereingang	Geplant	Programme aus einem Kabelnetz statt über IP übernehmen. geplant

HLS-Quellen

Geben Sie dem Sender die URL einer Master-Playlist. Castmux liest die angebotene Qualitätsleiter und wählt entsprechend dem Auflösungsprofil des Senders eine Variante aus, die es an die Engine übergibt. Ohne Profil — die Voreinstellung, und das, was jeder bereits bestehende Sender hat — wird die Master-Playlist unverändert durchgereicht, und die Reihenfolge des Ursprungsservers entscheidet.

Die Startposition an der Live-Kante ist konfigurierbar. Weiter hinten in der Playlist zu beginnen macht robuster gegenüber einem Ursprungsserver, der Segmente unregelmäßig veröffentlicht, kostet aber eine größere Verzögerung gegenüber live und ein langsameres erstes Bild nach dem Umschalten.

Ursprungsserver mit fMP4/CMAF brauchen die Remux-Engine

Der HLS-Reader der Pass-through-Engine verarbeitet ausschließlich MPEG-TS-Segmente. Veröffentlicht der Ursprungsserver fragmentierte MP4-Segmente (CMAF), muss dieser Sender die Remux-Engine verwenden. Das ist eine Eigenschaft des Readers, keine Einstellung — keine Kombination von Optionen bringt die Pass-through-Engine dazu, fMP4 zu verarbeiten. Siehe Streaming-Engines.

SRT-Quellen

SRT-Sender laufen im Caller-Modus: Castmux baut die Verbindung zum Ursprungsserver auf. Die gesamte Konfiguration steht in der URL, und die folgenden Query-Parameter werden an die Engine weitergegeben:

streamid, passphrase, transtype, latency, rcvlatency, peerlatency, rcvbuf, sndbuf, maxbw, pbkeylen, payloadsize, tlpktdrop, linger.

srt://origin.example.net:9000?streamid=play/news&passphrase=••••••••&transtype=live

Automatische Latenz

Castmux misst die Round-Trip-Zeit zum Ursprungshost und setzt das SRT-Latenzbudget auf das Vierfache der gemessenen RTT, mit einer Untergrenze von 200 ms und einer Obergrenze von 4000 ms. Ein in der URL angegebener Latenzwert wird ersetzt.

Das gibt es, weil die übliche Voreinstellung von 120 ms auf jeder Verbindung mit nennenswertem Jitter falsch ist und weil niemand den daraus entstehenden Fehler der Latenz zuschreibt. Ein zu knappes Budget legt den Sender nicht lahm; es erzeugt sporadische Bildfehler — immer wieder ein paar Sekunden Blockbildung, in keinem vorhersagbaren Abstand, auf einem Sender, dessen Dashboard vollständig grün ist. Installationen jagen wochenlang dem Encoder, dem Switch und dem Fernsehgerät hinterher, bevor jemand eine Transporteinstellung verdächtigt, die aus einer anderen Installation mit kürzerem Pfad kopiert wurde.

Der Faktor ist die übliche SRT-Empfehlung: Ein Empfänger muss eine Neuübertragung abwarten können, die eine volle Round Trip kostet, und dazu Raum für einen zweiten Versuch haben. Die Untergrenze verhindert, dass eine sehr kurze Verbindung ein Budget erhält, das zu klein ist, um überhaupt Verluste aufzufangen; die Obergrenze verhindert, dass eine einzige fehlerhafte Messung einem Sender Sekunden an Verzögerung hinzufügt.

Wenn Sie den Wert lieber selbst festlegen, schalten Sie das Verhalten mit overwrite_srt_latency: false in der globalen Konfiguration ab; die Latenz in der URL bleibt dann unverändert.

Listener- und Rendezvous-Modus

Beide sind heute erreichbar, indem Sie Engine-Parameter in der URL übergeben, sie sind aber in der Oberfläche nicht abgebildet: Es gibt kein Feld mit der Bedeutung „auf diesem Port lauschen“, und nichts prüft, was Sie eingeben. Vollwertige Unterstützung für Listener- und Rendezvous-Sender ist geplant.

RTMP-Quellen

RTMP wird mit der Remux-Engine unterstützt und normalerweise für einen lokalen Encoder im selben Netzwerk wie das Gerät verwendet, nicht für ein Signal, das über das Internet ankommt.

RTMP funktioniert nicht mit der Pass-through-Engine

Das ist kein Abstimmungsproblem und keine fehlende Option. Wenn Sie einen RTMP-Sender auf die Pass-through-Engine stellen, läuft er nicht. Lassen Sie solche Sender auf der Remux-Engine, oder setzen Sie am Sender die Engine-Überschreibung, wenn Ihre globale Voreinstellung Pass-through ist.

MPEG-TS-Quellen

Der Quelltyp mpegts übernimmt einen Transport Stream, der unverändert ankommt, ohne Playlist und ohne Container darum herum. Das URL-Schema bestimmt den Transportweg:

# a multicast group, e.g. another headend's output
source:
  type: mpegts
  url: udp://239.20.0.5:1234?localaddr=192.168.10.4

# a continuous transport stream over HTTP
source:
  type: mpegts
  url: https://origin.example.net/news/mpegts

Über UDP tritt der Sender der Gruppe bei und liest die Transport-Stream-Datagramme genau so, wie sie ankommen. Die URL nimmt drei optionale Parameter an, die für beide Engines gleich geschrieben werden:

• localaddr ist die lokale Adresse, auf der die Gruppe empfangen wird. Setzen Sie sie auf einem Gerät mit mehreren Schnittstellen, damit der Join über die Schnittstelle zum Absender hinausgeht.
• sources beschränkt den Empfang auf einen Absender, für Source-Specific Multicast.
• buffer_size ist der Empfangspuffer des Kernels in Bytes. Die Voreinstellung ist großzügig, damit ein Aussetzer bei der Prozessplanung keine Datagramme verwirft.

Über HTTP liest der Sender eine einzige, endlose Antwort, etwa die /mpegts-Ausgabe eines Streaming-Servers. Schließt der Ursprungsserver die Verbindung, startet der Sender neu, wie bei jedem anderen Ausfall einer Quelle.

Einiges unterscheidet sich von den anderen Quelltypen:

• Auflösungsprofile gelten nicht. Ein Transport Stream führt eine einzige, feste Rendition, und es gibt keine Qualitätsleiter zur Auswahl.
• Ein Sender kann nicht seinen eigenen Ausgang empfangen. Eine udp://-Quelle, die der eigenen Zieladresse und dem eigenen Port des Senders entspricht, wird beim Speichern abgelehnt. Die Engine würde sonst endlos aufnehmen, was sie gerade gesendet hat, während die Bitratenanzeige einen gesunden Sender meldet. Die Gruppe eines anderen Senders zu lesen ist erlaubt und eine bewusste Möglichkeit, einen Sender in einen anderen zu verketten.
• Es wird nur einfacher Transport Stream gelesen. Ein in RTP verpacktes Multicast-Signal wird noch nicht unterstützt.

Das Ziel

Eine IPv4-Adresse und ein Port. Die Adresse kann eine Multicast-Gruppe sein, der Normalfall bei der Fernsehverteilung, oder eine Unicast-Adresse für einen einzelnen Empfänger oder einen Test.

Verwenden Sie für Multicast den administrativ begrenzten Bereich 239.0.0.0/8. Er ist genau für diesen Zweck reserviert — private, organisationsinterne Nutzung —, sodass nichts, was Sie darin wählen, mit einer bekannten Zuweisung kollidieren kann.

Verwenden Sie 224.0.0.0/24 niemals für Inhalte

Dieser Bereich ist für linklokale Steuerprotokolle reserviert: Routing-Nachbarschaften, IGMP selbst und die Nachbarerkennung liegen dort. Pakete an diese Adressen werden mit einer TTL von eins gesendet und von jedem Gerät im Segment verarbeitet. Ein Fernsehsender dort flutet Ihre Switches mit Control-Plane-Verkehr und stört das Netzwerk, lange bevor jemand bemerkt, dass das Bild fehlt.

Heute gibt es ein Ziel pro Sender. Um denselben Sender an mehrere Gruppen zu senden — zum Beispiel an eine Multicast-Gruppe und an eine Unicast-Messstelle —, brauchen Sie einen zweiten Sender mit derselben Quell-URL. Mehrere Ziele pro Sender sind geplant.

Einstellungen pro Sender

active

Ob der Sender überhaupt überwacht wird. Ein inaktiver Sender behält seine Konfiguration, wird aber nie gestartet und erzeugt keine Messwerte.

force_always_on

Den Sender laufen lassen, egal ob jemand zusieht. Die Voreinstellung ist aus, das heißt On-Demand-Streaming: Der Sender läuft nur, solange auf seiner Gruppe ein Zuschauer erkannt wird. Setzen Sie diese Option für Sender, die beim Umschalten nie die Kaltstartverzögerung haben dürfen. Siehe On-Demand-Streaming.

engine

Überschreibt die globale Engine-Wahl für diesen Sender. Leer bedeutet: erben. Siehe Streaming-Engines.

resolution_profile

Welche Stufe einer HLS-Qualitätsleiter genommen wird. Leer bedeutet: die Master-Playlist unverändert übernehmen. Wird bei SRT und RTMP ignoriert, da diese keine Qualitätsleiter haben. Siehe Auflösungsprofile.

min_output_kbps

Die Ausgangsbitrate, unterhalb derer dieser Sender als nichts erzeugend gilt und daher einen Neustart braucht.

Bei Radiosendern muss die Bitraten-Untergrenze gesenkt werden

Die globale Voreinstellung für die minimal erwartete Ausgangsbitrate geht von Video aus. Ein reiner Audio-Service liegt berechtigterweise weit darunter — 128 kbps ist eine gewöhnliche Radiobitrate. Mit der globalen Untergrenze wird er deshalb bei jeder Prüfung als stumm eingestuft und endlos neu gestartet, obwohl er einwandfrei funktioniert. Setzen Sie min_output_kbps an diesem Sender auf einen Wert deutlich unter seiner tatsächlichen Rate.

Einen Sender benennen

Der Sendername ist nicht nur eine Beschriftung in der Oberfläche. Er wird zum DVB-Service-Namen in der SDT, den ein Fernsehgerät in seiner Senderliste anzeigt, und er ist das Label an jedem Messwert, den der Sender erzeugt.

Die zweite Folge ist die, die Leute überrascht: Wer einen Sender umbenennt, benennt seine Messwertreihen um. Die historischen Daten folgen der Umbenennung nicht. Ein Dashboard oder Alarm, der am alten Namen hängt, verstummt, und ein Diagramm des Senders scheint bei null zu beginnen. Legen Sie die Namen fest, bevor Sie Dashboards bauen, und betrachten Sie eine Umbenennung als Vorgang mit nachgelagerten Kosten, nicht als kosmetische Änderung.

Senderkennung

Sender werden über eine ganzzahlige ID identifiziert. Diese ID steht in der Konfigurationsdatei, in der HTTP-API und überall, wo von außen auf einen Sender verwiesen wird.

IDs werden derzeit nach dem Löschen wiederverwendet. Löschen Sie Sender 7 und legen dann einen neuen Sender an, kann dieser die ID 7 erhalten. In jeder Hinsicht, die für einen Betreiber zählt, ist es ein anderer Sender — anderer Name, andere Quelle, anderes Ziel —, aber alles, was an der ID hängt, sieht Kontinuität, wo keine ist.

Die praktischen Folgen sollten Sie kennen, bevor Sie sich auf IDs verlassen:

• Alles, was Zustand pro Sender unter der ID speichert — ein externer Scheduler, ein gespeicherter API-Aufruf, ein Lesezeichen in der Oberfläche —, kann nach einem Zyklus aus Löschen und Neuanlegen auf den falschen Sender zeigen.
• Browser stellen den Zustand von Formularelementen bei einem einfachen Neuladen unabhängig davon wieder her, was der Server ausgeliefert hat. Ein neu angelegter Sender kann deshalb kurzzeitig eine Einstellung anzeigen, die vom gelöschten Sender mit derselben ID stammt. Maßgeblich ist, was das Badge neben dem Bedienelement anzeigt.
• Bei DVB-C ergibt sich die Service-Kennung aus der Position im Multiplex, nicht aus der Sender-ID. Das Umsortieren oder Entfernen eines Senders verschiebt also die Services um ihn herum.

Stabile, nicht wiederverwendete Kennungen und festlegbare Service-Kennungen sind geplant. Bis dahin gilt die sichere Regel: Eine ID bezeichnet einen Platz, ein Name bezeichnet einen Sender.

Sender aus der Lizenz

Eine Lizenz kann neben der Berechtigung zum Streamen auch eine Senderliste enthalten. Bei jeder Lizenzprüfung vergleicht das Gerät diese Senderliste mit seinen eigenen Sendern. Jeder Sender hält fest, wem er gehört (managed_by in der Konfigurationsdatei), und daraus folgen zwei Regeln:

• Ein Sender, den die Lizenz geliefert hat, gehört dem Lizenzserver. Bei jeder Lizenzprüfung werden Quelle, Ziel, Auflösungsprofil, Dauerbetrieb und Ein/Aus-Zustand auf das aktualisiert, was der Server sendet. Ein Sender, der umzieht, wird so ohne Vor-Ort-Termin korrigiert. Führt der Server ihn nicht mehr auf, wird er entfernt. Die Weboberfläche kennzeichnet diese Sender und lässt sie weder bearbeiten noch löschen, da die nächste Lizenzprüfung die Änderung rückgängig machen würde.
• Ein Sender, den Sie selbst angelegt haben, wird nie angetastet. Der Server ändert oder entfernt ihn nie, selbst wenn die Senderliste einen Sender gleichen Namens enthält. Die einzige Ausnahme ist ein Sender, den Sie ausgeschaltet haben: Er betreibt nichts, deshalb darf ein lizenzierter Sender mit demselben Namen oder Ziel ihn übernehmen. Dadurch funktioniert die Migration eines älteren Geräts, ohne vorher dessen alte Sender zu löschen.

Die Lizenz legt außerdem eine Höchstzahl gleichzeitig laufender Sender fest. Ein lizenzierter Sender über dieser Grenze wird ausgeschaltet hinzugefügt statt verworfen. Ein späteres Upgrade des Tarifs heißt also, ihn einzuschalten, nicht, ihn neu einzugeben. Die Grenze gilt auch für Sender, die Sie selbst anlegen: Ein Sender, der hinzugefügt wird, wenn die Grenze bereits erreicht ist, kommt ausgeschaltet an, mit einer Meldung, die den Grund nennt.

Ein lizenzierter Sender, der an eine Gruppe senden würde, die ein anderer laufender Sender bereits verwendet, wird abgelehnt statt eine Kollision zuzulassen — ebenso einer, den der Server ohne Quell-URL oder Ziel geschickt hat. Ablehnungen werden in der Weboberfläche angezeigt und protokolliert, sodass sich „der Server hat nichts geschickt“ von „das Gerät hat abgelehnt, was er geschickt hat“ unterscheiden lässt.

Ausführliches Beispiel

Zwei Sender in config.yaml — einer per HLS mit Auflösungsprofil, einer per SRT mit gesenkter Bitraten-Untergrenze, weil es ein Radioservice ist:

streams:
  - id: 1
    name: BBC One
    description: Reception and lounge
    active: true
    source:
      type: hls
      url: https://origin.example.net/bbcone/master.m3u8
    destination:
      address: 239.1.1.10
      port: 5000
    # Televisions here are 720p panels; the origin lists 1080p first.
    resolution_profile: hd
    force_always_on: true

  - id: 2
    name: Classic FM
    description: Audio only
    active: true
    source:
      type: srt
      url: srt://origin.example.net:9000?streamid=play/classicfm&transtype=live
    destination:
      address: 239.1.1.11
      port: 5000
    # Radio: well under the video-oriented global floor, so lower it or the
    # channel is treated as silent and restarted forever.
    min_output_kbps: 64
    force_always_on: true

In der SRT-URL steht kein latency, weil Castmux sie aus der gemessenen Round-Trip-Zeit ableitet. Bei keinem der beiden Sender ist engine angegeben, also erben beide die globale Voreinstellung.