UDP-Multicast-Ausgang

Adressierung

Verwenden Sie für die Verteilung innerhalb eines Gebäudes den administrativ begrenzten Bereich 239.0.0.0/8. Er ist das Multicast-Gegenstück zu 10.0.0.0/8: für die lokale Nutzung reserviert, nie ins öffentliche Internet geroutet und ohne Abgleich mit einem Register sicher zu vergeben. Weisen Sie jedem Sender eine eigene Gruppe zu und dokumentieren Sie die Vergabe schriftlich, denn eine Kollision zwischen zwei Sendern ist derselbe Fehler wie ein doppelter Sender und zeigt sich genauso.

Verwenden Sie nicht 224.0.0.0/24. Dieser Block ist für linklokale Steuerprotokolle reserviert — Routing-Nachbarschaften, IGMP selbst und bei manchen Geräten die Nachbarerkennung. Video, das dorthin gesendet wird, geht an jedes Gerät im Segment und wird von Control-Plane-Code verarbeitet, der nicht mit 38 Mbps gerechnet hat. Castmux warnt, wenn ein Ziel in diesem Bereich liegt, statt es rundweg abzulehnen — in der Annahme, dass Sie vielleicht bewusst etwas testen. Im Produktivbetrieb sollten Sie die Warnung aber wie einen Fehler behandeln.

Unicast-Ziele werden akzeptiert und sind die richtige Wahl für eine Punkt-zu-Punkt-Verbindung: um eine andere Kopfstation über einen gerouteten Pfad zu speisen, einen Sender an einen Recorder oder einen Compliance-Logger zu übergeben oder von einem Laptop aus zu testen, der nicht im Fernseh-VLAN hängt. Hinter einem Unicast-Sender steht keine IGMP-Membership, deshalb kann On-Demand-Streaming für ihn keine Zuschauer erkennen, und der Sender muss dauerhaft laufen.

Bereich	Verwendung
239.0.0.0/8	empfohlen Administrativ begrenzt. Die richtige Wahl für die Verteilung im Gebäude.
224.0.0.0/24	vermeiden Für linklokale Steuerprotokolle reserviert. Castmux warnt, wenn ein Sender hierhin zeigt.
Unicast-Adresse	Punkt-zu-Punkt Akzeptiert. Geeignet für eine andere Kopfstation oder einen Recorder. Keine Zuschauererkennung, lassen Sie den Sender also dauerhaft laufen.

Datagrammgröße

Die Nutzlast jedes Datagramms beträgt 1316 Bytes, also genau sieben Transportpakete zu 188 Bytes. Diese Zahl ist nicht willkürlich, und es lohnt sich zu verstehen, warum sie die einzig vernünftige Wahl ist.

Ein Transportpaket hat 188 Bytes und lässt sich nicht auf mehrere Datagramme aufteilen, ohne dass der Empfänger es wieder zusammensetzen muss. Sieben davon ergeben 1316 Bytes, mit 8 Bytes UDP-Header und 20 Bytes IPv4-Header also 1344 — bequem innerhalb einer Ethernet-MTU von 1500 Bytes, mit Platz für ein VLAN-Tag. Acht Pakete wären 1504 Bytes Nutzlast und würden fragmentiert.

Weniger als sieben Pakete pro Datagramm zu senden ist zulässig, aber in zweierlei Hinsicht verschwenderisch. Jedes Datagramm trägt dieselben 28 Bytes Header, egal wie voll es ist. Ein Stream aus halb gefüllten Datagrammen verbraucht für dasselbe Video also ungefähr den doppelten Header-Overhead und die doppelte Paketverarbeitung auf dem Empfangsgerät. Wichtiger noch: Manche Set-Top-Boxen kommen mit ungleichmäßigen Datagrammen schlecht zurecht. Ein Decoder, der sieben Pakete pro Datagramm voraussetzt oder nach Datagrammanzahl statt nach Bytes puffert, erzeugt sporadische Bildfehler, die nur bei manchen Modellen auftreten und sich mit einem PC-Player kaum reproduzieren lassen.

Hier unterscheiden sich die beiden Engines. Die Pass-through-Engine sendet zu 100% volle 1316-Byte-Datagramme. Die Remux-Engine füllt sie zu etwa 85% und schickt jedes Mal ein kurzes Datagramm ab, wenn ihr interner Muxer eine Bildgrenze erreicht. Deshalb erzwingt Castmux die Paketgröße bei HLS-Sendern ausdrücklich, statt die Voreinstellung der Engine zu übernehmen — den vollständigen Vergleich finden Sie unter Streaming-Engines.

TTL

Die Voreinstellung ist 16. Die TTL eines Multicast-Datagramms wird von jedem Router, der es weiterleitet, verringert und begrenzt damit, wie weit der Verkehr gelangen kann.

TTL 1

Das Datagramm verlässt nie das lokale Segment. In einem einzelnen Gebäude, in dem Gerät und Fernsehgeräte im selben VLAN liegen, ist das meist der richtige Wert, und er ist ein nützliches Sicherheitsnetz: Eine Fehlkonfiguration kann kein Video in den Rest des Netzwerks durchsickern lassen.

TTL 16 (Voreinstellung)

Erlaubt die Weiterleitung über einige Router-Hops. Als Voreinstellung gewählt, weil sie sowohl im flachen als auch im gerouteten Fall funktioniert, und weil ein Stream, der nicht ankommt, ein schwerer zu diagnostizierender Fehler ist als einer, der etwas weiter reist als nötig.

Höhere Werte

Nur nötig, wo ein Router Multicast bewusst zwischen VLANs weiterleitet. Dafür muss der Netzwerkbetreiber PIM oder etwas Gleichwertiges konfiguriert haben. Eine höhere TTL allein bringt Multicast nicht über einen Router.

Ausgangsschnittstelle

Einem Sender kann eine Quelladresse zugewiesen werden, und die Engine bindet ihren Socket daran. Das ist nützlich, um die Absenderadresse des Verkehrs vorhersagbar zu machen — für Firewall-Regeln und um in einem Segment mit mehreren Geräten zu erkennen, von welchem Gerät ein Stream stammt.

Das Binden der Quelladresse wählt nicht die ausgehende Schnittstelle

Das ist das mit Abstand teuerste Missverständnis bei Multicast-Installationen. Einen Socket an 192.168.10.5 zu binden heißt nicht, dass die Pakete die Netzwerkkarte mit 192.168.10.5 verlassen. Der Kernel entscheidet über die Ausgangsschnittstelle weiterhin anhand der Routingtabelle, und bei Multicast trifft diese Entscheidung die Route für 224.0.0.0/4. Zeigt diese Route auf die falsche Netzwerkkarte, verlässt der Verkehr die falsche Netzwerkkarte — ganz gleich, welche Quelladresse Sie gebunden haben.

Schlimmer noch: Innerhalb des Prozesses lässt sich das nicht erkennen. sendto() an ein Ziel, das irgendwohin ins Leere geroutet wird, gelingt trotzdem. Jeder Zähler in der Oberfläche zeigt also einen gesunden Zustand, während kein Fernsehgerät etwas empfängt. Castmux prüft die Routingtabelle von außerhalb des Streaming-Pfads und meldet den Zustand, kann ihn aber nicht beheben.

Wie Sie die Routingtabelle lesen und korrigieren, steht unter Fehlerbehebung → Multicast-Routing; wie die Korrektur einen Neustart übersteht, unter Installation.

Aus derselben Tatsache folgen zwei weitere Punkte. Korrigieren Sie den Bereich 224.0.0.0/4, nicht einzelne Gruppen: Eine Host-Route pro Gruppe flickt nur die Sender, die Sie heute zufällig haben, und macht jeden später hinzugefügten Sender unbemerkt unroutbar. Und Routenänderungen mit ip route überstehen keinen Neustart; sie müssen deshalb als Unit installiert werden, die beim Booten läuft.

Konstante Bitrate

Manche nachgelagerten Geräte und manche älteren Set-Top-Boxen arbeiten mit einem Transport Stream konstanter Bitrate besser als mit einem, der der Quelle folgt. Auffüllen auf CBR bedeutet, Nullpakete einzufügen, damit die Leitungsrate flach bleibt, egal was das Video gerade tut.

Die Remux-Engine kann das, weil sie ihren eigenen Transport Stream baut und selbst entscheiden kann, wie viel davon Füllung ist. Die Pass-through-Engine kann es nicht: Sie leitet die Pakete der Quelle unverändert weiter und hat keinen Mechanismus zum Einfügen von Nullpaketen — dieselbe Eigenschaft, durch die sie die ursprünglichen PIDs erhält und Verluste auf der Quellseite originalgetreu meldet. Beides zugleich ist nicht möglich.

Auf dem DVB-C-Pfad stellt sich die Frage nicht. Ein DVB-C-Träger hat bauartbedingt eine konstante Bitrate, und der Multiplexer füllt ihn auf. Ein Sender, der für einen Multiplex bestimmt ist, braucht daher kein CBR an seinem UDP-Ausgang.

Konstante Bitrate pro Sender am reinen UDP-Ausgang, unabhängig von der Engine konfigurierbar, ist geplant.

Service-Namen

Ein Fernsehgerät oder eine Set-Top-Box, die eine Multicast-Gruppe durchsucht, zeigt den Namen an, den der Transport Stream in seiner Service Description Table angibt. Bei der Pass-through-Engine schreibt Castmux den Sendernamen in die SDT; der Name, den Sie in der Weboberfläche eingeben, ist also der Name auf dem Bildschirm.

Die Remux-Engine schreibt keine SDT. Sender auf dieser Engine erscheinen unter dem Namen, den sich das Empfangsgerät ausdenkt, typischerweise die Gruppenadresse oder ein allgemeiner Platzhalter. Wenn der angezeigte Name wichtig ist und die Quelle es zulässt, verwenden Sie die Pass-through-Engine.

Doppelte Sender

Zwei Prozesse, die an dieselbe Gruppe und denselben Port senden, erzeugen einen Stream, in dem beide verschachtelt sind. Continuity Counter widersprechen sich, PIDs kollidieren, und auf dem Bildschirm zeigen sich Pixelbildung und Tonaussetzer, die kommen und gehen.

Dieser Fehler ist ungewöhnlich aufwendig zu diagnostizieren, weil beide Absender völlig gesund aussehen. Jeder erzeugt einen gültigen Stream mit der richtigen Bitrate, bei jedem sind die Messwerte grün. Die auf der Leitung gemessene Bitrate ist ungefähr doppelt so hoch wie sie sein sollte — das ist der einzige Hinweis, und er wird leicht etwas anderem zugeschrieben.

Castmux sucht deshalb vor dem Start eines Senders nach anderen Absendern auf Zieladresse und Port und meldet den Zustand, statt zusätzlich zu ihnen zu starten. Die klassische Ursache sind nicht zwei Castmux-Sender — das verhindert die Oberfläche —, sondern ein älterer Dienst, der neben einer neuen Installation weiterläuft: ein früherer Streamer, der deaktiviert, aber nicht gestoppt wurde, oder eine systemd-Unit, die ein cron-Eintrag jede Nacht neu startet.

Das Deaktivieren einer Unit hindert cron nicht daran, sie zu starten

systemctl disable entfernt nur den Symlink für den Systemstart. Eine Zeile systemctl restart in der Crontab von root startet den alten Dienst trotzdem, planmäßig und für immer. Wenn Sie ein Gerät von einer Paketinstallation auf einen Container umstellen, prüfen Sie die Crontab und verwenden Sie systemctl mask.

Dummy-Listener

Wenn im Netzwerk niemand einer Multicast-Gruppe beigetreten ist, gibt es keinen Empfänger, der Gegendruck erzeugt, und bei manchen Kombinationen aus Kernel und Treiber kann der Sendepuffer des Sockets überlaufen, statt einfach zu verwerfen. Das Symptom sind sporadische Sendefehler bei einem Sender, den gar niemand sieht.

Castmux kann für jede Gruppe einen lokalen Abnehmer betreiben, der ihr beitritt, den Verkehr liest und verwirft. So bleiben Gruppenmitgliedschaft und Pufferverhalten gleich, ob echte Zuschauer da sind oder nicht. Die Funktion ist standardmäßig eingeschaltet und kostet sehr wenig; es gibt keinen Grund, sie abzuschalten, es sei denn, Sie messen etwas und wollen, dass der Gruppe wirklich niemand beigetreten ist.

Beachten Sie das Zusammenspiel mit On-Demand-Streaming: Der Dummy-Listener wird bewusst nicht als Zuschauer gezählt. Täte er das, würde kein Sender on demand jemals stoppen.

Den Ausgang überprüfen

Drei Prüfungen, geordnet danach, wie viel sie beweisen.

Erstens: Spielen Sie die Gruppe auf einem Rechner im selben Segment ab:

# ffplay, on a host in the same VLAN as the appliance
ffplay udp://@239.10.0.1:1234

# The @ is required. Without it ffplay listens on a unicast socket
# and never joins the group, so you will see nothing and blame the encoder.

Verwenden Sie in VLC Media → Open Network Stream (in der deutschen Oberfläche Medien → Netzwerkstream öffnen) und geben Sie dieselbe URL ein:

udp://@239.10.0.1:1234

Zweitens: Verwenden Sie die Browser-Vorschau in der Weboberfläche. Sie bestätigt, dass die Quelle ankommt und korrekt aufbereitet wird, beweist aber nichts über den Multicast-Pfad, denn die Vorschau läuft nicht über ihn.

Drittens, und am aussagekräftigsten: Lesen Sie die Kachel für die UDP-Bitrate auf der Senderkarte ab. Dieser Wert wird per Paketmitschnitt an der Schnittstelle direkt auf der Leitung gemessen und nicht von der Engine gemeldet. Er ist daher das einzige Signal, das nicht davon abhängt, dass die Engine über sich selbst die Wahrheit sagt, und er ist für beide Engines dieselbe Messung. Ein Sender, dessen Engine angeblich läuft, dessen UDP-Bitrate aber null ist, ist nicht auf Sendung.

Ein laufendes Bild auf einem Laptop ist kein Beweis

Hängt Ihr Laptop am selben Switch wie das Gerät und liegen die Fernsehgeräte hinter einem Uplink, sagt Ihnen ein erfolgreiches ffplay nur, dass der Stream existiert — aber nichts darüber, ob das IGMP-Snooping auf dem dazwischenliegenden Switch ihn weiterleitet. Testen Sie aus dem Segment, in dem die Fernsehgeräte hängen, oder mit einem Fernsehgerät.