Streaming-Engines

Die beiden Engines im Vergleich

	Remux-Engine	Pass-through-Engine
Kaltstart, Join bis zum ersten Paket	~4.4 s	~1.9 s
Volle 1316-Byte-Datagramme	85%	100%
CPU pro Sender	~5% eines Kerns	~15%
RAM pro Sender	~72 MB	~23 MB
Sender auf einem Gerät mit 2 GB	~16	25+
PIDs und Service-ID	Neu vergeben	Original, erhalten
Ausgelieferte Audiospuren	Eine	Alle, mit ISO-639-Sprachkennung
Untertitel und Videotext	Verworfen	Durchgereicht
Paketverlust auf der Quellseite	Verdeckt	Originalgetreu gemeldet
Auffüllen auf konstante Bitrate	Ja	Nein
HLS-Quelle mit fMP4/CMAF	Ja	Nein

Welche Engine Sie wählen

Die Pass-through-Engine ist die Voreinstellung und für fast alles die richtige Wahl. Sie braucht etwa ein Drittel des Arbeitsspeichers, und genau das bestimmt die Senderzahl auf einem Gerät mit 2 GB. Sie liefert das erste Bild in ungefähr der halben Zeit, und das erlebt der Zuschauer als Umschaltgeschwindigkeit. Jedes Datagramm, das sie sendet, hat volle 1316 Bytes, und jede Audiosprache der Quelle kommt mit intakter Sprachkennung beim Fernsehgerät an. Sie tut weniger — und gerade deshalb tut sie es besser.

Wählen Sie die Remux-Engine, wenn einer der folgenden Punkte zutrifft:

• Der HLS-Ursprungsserver liefert fMP4/CMAF-Segmente. Der HLS-Reader der Pass-through-Engine verarbeitet ausschließlich MPEG-TS-Segmente. Das ist nicht konfigurierbar.
• Die Quelle ist RTMP. RTMP wird von der Pass-through-Engine überhaupt nicht unterstützt.
• Ein nachgelagertes Gerät verlangt eine konstante Bitrate am UDP-Ausgang. Nur die Remux-Engine kann den Stream mit Nullpaketen auf eine feste Rate auffüllen. Manche älteren Set-Top-Boxen und manche HF-Modulatoren brauchen das; die meisten modernen Geräte nicht.

Ihr höherer CPU-Bedarf ist real, aber selten der begrenzende Faktor: Auf diesen Geräten geht zuerst der Arbeitsspeicher aus. Planen Sie die Kapazität nach dem RAM.

Warum die Remux-Engine nur eine Audiospur ausliefert

Die Pass-through-Engine demultiplext nicht. Daher kommt jede Audio-PID der Quelle — zusammen mit der ursprünglichen PMT und ihren ISO-639-Sprachdeskriptoren — unverändert beim nachgelagerten Gerät an. Ein Zuschauer kann am Fernsehgerät eine Sprache wählen, weil das Fernsehgerät sieht, dass die Sprachen vorhanden sind.

Die Remux-Engine baut einen neuen Transport Stream. Ihre Argumentliste kopiert das Audio, statt es neu zu kodieren, legt aber keine explizite Stream-Zuordnung fest. Deshalb greift die Standardauswahl: ein Videostream, ein Audiostream, alles andere wird verworfen. Sie erhalten die Spur, die die Quelle als beste Kandidatin auflistet — und nur diese eine.

Alle Audiospuren mitzuführen wäre nur eine einzige Option entfernt, und sie ist bewusst nicht aktiviert. Sie würde die Ausgangsbitrate jedes Senders erhöhen — Audiospuren sind klein, aber ein Signal mit sechs Sprachen ist auf einem Multiplex nicht umsonst —, und sie würde den gesendeten Stream jedes bereits in Betrieb befindlichen Senders verändern. Das tut man nicht global auf einem Gerät, das jemand letztes Jahr in Betrieb genommen hat. Eine Aktivierung pro Sender ist geplant.

Keine Engine kann erzeugen, was der Quelle fehlt

Führt der Ursprungsserver eine Audiospur, erzeugt keine Engine-Einstellung eine zweite. Deshalb ist auch die Schutzregel für demultiplexte Qualitätsleitern bei den Auflösungsprofilen wichtig: Bei einer Leiter, deren Audio außerhalb der Videovarianten liegt, gibt es nach Auswahl einer einzelnen Videovariante überhaupt kein Audio mehr zum Durchreichen.

Warum die Remux-Engine Quellverluste verdeckt

Ein neuer Transport Stream bedeutet neu gesetzte Continuity Counter. Jedes Paket, das das Gerät verlässt, trägt daher eine korrekte, lückenlose Zählerfolge — unabhängig davon, was angekommen ist. Lücken, die vorgelagert entstanden sind — beim Ursprungsserver, auf dem Internetpfad, durch einen unzuverlässigen Encoder —, werden in dem Moment unsichtbar, in dem sie die Engine passieren.

Im Betrieb ist das nützlich, weil ein nachgelagerter Analysator nicht mehr bei Fehlern alarmiert, gegen die er nichts tun kann. Bei einer Fehleranalyse ist es dagegen regelrecht irreführend. Wenn Sie klären wollen, ob ein vorgelagertes Signal Pakete verliert, stellen Sie den Sender zuerst auf die Pass-through-Engine um. Sonst messen Sie die Qualität Ihrer eigenen Reparatur und nicht die des Signals.

Die Pass-through-Engine meldet Verluste originalgetreu, aus demselben Grund, aus dem sie PIDs und Audio erhält: Sie baut nichts neu auf.

Die Messwerte unterscheiden sich je nach Engine

Bilder pro Sekunde, Wiedergabegeschwindigkeit und die vom Encoder gemeldete Bitrate werden aus der Fortschrittsausgabe der Remux-Engine gelesen. Die Pass-through-Engine dekodiert nie Video, kennt also die Bildrate nicht und hat keinen Begriff von Wiedergabegeschwindigkeit. Diese Werte gibt es für sie nicht.

Auf einem Pass-through-Sender zeigen diese Kacheln n/a. Das ist korrekt und zu erwarten — kein Fehler und kein Zeichen dafür, dass der Sender nicht in Ordnung ist.

Das Engine-unabhängige Signal ist die Leitungsbitrate, gemessen per Paketmitschnitt an der Ausgangsschnittstelle. Sie ist die einzige Lebendigkeitsmessung, die auf beiden Engines identisch funktioniert, sie misst, was tatsächlich den Netzwerkport verlassen hat, und nicht, was ein Prozess gesendet zu haben behauptet — und ihr sollten Sie vertrauen. Siehe Überwachung und Messwerte.

Knüpfen Sie externe Überwachung nicht an Bilder pro Sekunde oder Wiedergabegeschwindigkeit

Jeder Watchdog, jede Alarmregel und jeder Dashboard-Schwellwert, der auf diesen Werten aufbaut, schlägt bei Pass-through-Sendern ununterbrochen an, weil die Werte fehlen und nicht null sind — und eine Regel, die „fehlt“ als null behandelt, startet einwandfreie Sender endlos neu. Das ist im Feld mehr als einmal passiert, und beide Male sah das Symptom nach einem Engine-Fehler aus, nicht nach einem Überwachungsfehler. Machen Sie solche Prüfungen von der verwendeten Engine abhängig, oder knüpfen Sie sie stattdessen an die Leitungsbitrate.

Service-Namen

Bei der Pass-through-Engine wird der Sendername in die SDT des ausgehenden Streams geschrieben. Ein Fernsehgerät, das die Multicast-Gruppe oder den DVB-C-Multiplex durchsucht, zeigt deshalb den Namen, den Sie konfiguriert haben, und nicht den, den der Ursprungsserver zufällig eingebettet hat.

Die Remux-Engine überträgt keine Service-Namen. Ein Sender auf der Remux-Engine zeigt den Service-Namen, der beim Remuxen entsteht, und das ist in der Regel nicht der Name in der Castmux-Oberfläche. Wenn der am Fernsehgerät angezeigte Name wichtig ist — und in einem Hotel oder Krankenhaus ist er das meistens —, spricht das für die Pass-through-Engine.

Die Engine festlegen

Es gibt zwei Ebenen:

Globale Voreinstellung

Wird in Settings festgelegt. Gilt für jeden Sender, der sie nicht überschreibt, auch für später hinzugefügte Sender.

Überschreibung pro Sender

Wird am Sender festgelegt. Verwenden Sie sie für die Ausnahmen — den fMP4-Ursprungsserver, das RTMP-Signal vom lokalen Encoder, den einen Sender, dessen nachgelagerter Modulator auf konstanter Bitrate besteht.

Ein Sender ohne Überschreibung zeigt den geerbten Wert an, als geerbt gekennzeichnet. So ist immer erkennbar, ob die angezeigte Engine für diesen Sender gewählt wurde oder der globalen Einstellung folgt. Eine Änderung der globalen Voreinstellung ändert alle erbenden Sender auf einmal; Sender mit Überschreibung sind nicht betroffen.

Ein Engine-Wechsel startet den Sender neu

Die Engine wird beim Start des Senders gewählt. Ein Wechsel wird daher beim nächsten Start wirksam, und der Sender wird dafür neu gestartet. Die Zuschauer erleben die Kaltstartverzögerung der jeweiligen Engine — etwa 1.9 s bei Pass-through, etwa 4.4 s bei Remux. Ein Wechsel der globalen Voreinstellung startet jeden erbenden Sender neu; nehmen Sie ihn also in einer ruhigen Phase vor und nicht am Abend.