Streaming-engines

De twee engines vergeleken

	Remux-engine	Pass-through-engine
Koude start, van join tot eerste pakket	~4.4 s	~1.9 s
Volledige datagrammen van 1316 bytes	85%	100%
CPU per zender	~5% van één core	~15%
RAM per zender	~72 MB	~23 MB
Zenders op een apparaat met 2 GB	~16	25+
PID's en service-ID	Herschreven	Oorspronkelijk, behouden
Geleverde audiosporen	Eén	Alle, met ISO-639-taallabels
Ondertitels en teletekst	Verwijderd	Doorgegeven
Pakketverlies aan de bronzijde	Verborgen	Getrouw gemeld
Opvulling tot constante bitrate	Ja	Nee
fMP4/CMAF-HLS-bron	Ja	Nee

Welke kiest u

De pass-through-engine is de standaard en is voor bijna alles de juiste keuze. Hij gebruikt ongeveer een derde van het geheugen, en dat bepaalt het aantal zenders op een apparaat met 2 GB; hij heeft het eerste beeld in ongeveer de helft van de tijd, en dat ervaart een kijker als zapsnelheid; elk datagram dat hij verstuurt is volledig 1316 bytes; en elke audiotaal in de bron komt met intact taallabel bij de televisie aan. Hij doet minder, en juist daardoor doet hij het beter.

Kies de remux-engine als een van de volgende situaties geldt:

• De HLS-originserver publiceert fMP4/CMAF-segmenten. De HLS-lezer van de pass-through-engine verwerkt alleen MPEG-TS-segmenten. Dit is niet instelbaar.
• De bron is RTMP. RTMP wordt door de pass-through-engine helemaal niet ondersteund.
• Een apparaat verderop in de keten vereist een constante bitrate op de UDP-uitgang. Alleen de remux-engine kan de stream met null-pakketten opvullen tot een vaste rate. Sommige oudere settopboxen en sommige RF-modulatoren hebben dit nodig; de meeste moderne apparatuur niet.

Het hogere CPU-verbruik is reëel, maar zelden de beperkende factor: op deze apparaten raakt het geheugen eerder op. Plan de capaciteit op basis van RAM.

Waarom de remux-engine maar één audiospoor levert

De pass-through-engine demuxt niet, dus elke audio-PID in de bron — samen met de oorspronkelijke PMT en de ISO-639-taaldescriptors — komt ongewijzigd verderop in de keten aan. Een kijker kan op de televisie een taal kiezen, omdat de televisie kan zien dat die talen er zijn.

De remux-engine bouwt een nieuwe transportstream. De argumentenlijst kopieert de audio in plaats van die opnieuw te coderen, maar legt geen expliciete streamtoewijzing vast, dus geldt de standaard streamselectie: één videostream, één audiostream, de rest wordt weggegooid. Het spoor dat u krijgt, is het spoor dat de bron als beste kandidaat vermeldt, en het is het enige.

Alle audiosporen meenemen is één optie verwijderd, en die staat bewust uit. Ze zou de uitgangsbitrate van elke zender verhogen — audiosporen zijn klein, maar een feed met zes talen is op een multiplex niet gratis — en ze zou de uitgezonden stream veranderen van elke zender die al in gebruik is, en dat doet u niet globaal op een apparaat dat iemand vorig jaar heeft opgeleverd. Een opt-in per zender staat op de roadmap.

Geen van beide engines kan maken wat de bron niet heeft

Draagt de originserver één audiospoor, dan levert geen enkele engine-instelling een tweede op. Daarom is ook de beveiliging tegen gedemuxte ladders bij resolutieprofielen van belang: bij een ladder waarvan de audio buiten de videovarianten staat, is er helemaal geen audio om door te geven zodra één videovariant is gekozen.

Waarom de remux-engine bronverlies verbergt

Een nieuwe transportstream bouwen betekent de continuity counters opnieuw stempelen. Elk pakket dat het apparaat verlaat, heeft daardoor een correcte, ononderbroken tellerreeks, ongeacht wat er binnenkwam. Gaten die eerder in de keten zijn ontstaan — door de originserver, door het internetpad, door een haperende encoder — worden onzichtbaar zodra ze erdoorheen gaan.

In productie is dat nuttig, omdat een analyser verderop in de keten dan niet meer alarmeert over fouten waar hij niets aan kan doen. Tijdens een storingsonderzoek is het ronduit misleidend. Wilt u vaststellen of een inkomende feed pakketten verliest, zet de zender dan eerst op de pass-through-engine; anders meet u de kwaliteit van uw eigen reparatiewerk in plaats van de kwaliteit van de feed.

De pass-through-engine meldt verlies getrouw, om dezelfde reden waarom hij PID’s en audio behoudt: hij bouwt niets opnieuw op.

Meetwaarden verschillen per engine

Frames per seconde, afspeelsnelheid en de door de encoder gemelde bitrate worden uit de eigen voortgangsuitvoer van de remux-engine gelezen. De pass-through-engine decodeert nooit video, dus kent hij de framerate niet en heeft hij geen notie van afspeelsnelheid. Die waarden bestaan voor hem niet.

Op een pass-through-zender tonen die tegels n/a. Dat is juist en te verwachten, geen storing en geen teken dat de zender ongezond is.

Het engine-onafhankelijke signaal is de wire bitrate (bitrate op de lijn), gemeten met pakketcapture op de uitgaande interface. Het is de enige levendigheidsmeting die op beide engines identiek werkt, ze meet wat de netwerkpoort daadwerkelijk heeft verlaten in plaats van wat een proces beweert te hebben verzonden, en het is de meting die u kunt vertrouwen. Zie Monitoring en meetwaarden.

Baseer externe monitoring niet op frames per seconde of afspeelsnelheid

Elke watchdog, alertregel of dashboarddrempel die op die waarden is gebouwd, gaat voortdurend af bij pass-through-zenders, omdat de waarden ontbreken in plaats van nul te zijn — en een regel die ontbrekend als nul behandelt, herstart volkomen gezonde zenders eindeloos. Dit is in de praktijk meer dan eens gebeurd, en beide keren leek het symptoom op een engine-bug in plaats van een monitoringbug. Maak zulke controles afhankelijk van de gebruikte engine, of baseer ze op wire bitrate.

Servicenamen

Op de pass-through-engine wordt de zendernaam in de SDT van de uitgaande stream geschreven, zodat een televisie die de multicastgroep of de DVB-C-multiplex scant de naam toont die u hebt ingesteld, en niet wat de originserver toevallig heeft meegegeven.

De remux-engine neemt geen servicenamen mee. Een zender op de remux-engine toont de servicenaam die uit de remux voortkomt, en dat is doorgaans niet de naam in de Castmux-interface. Is de naam op de televisie belangrijk — en in een hotel of ziekenhuis is dat meestal zo — dan is dat een reden om de pass-through-engine te verkiezen.

De engine instellen

Er zijn twee niveaus:

Globale standaard

Ingesteld in Settings. Geldt voor elke zender die de instelling niet overschrijft, ook voor zenders die later worden toegevoegd.

Overschrijving per zender

Ingesteld op de zender. Gebruik dit voor de uitzonderingen — de fMP4-originserver, de RTMP-feed van de lokale encoder, die ene zender waarvan de modulator verderop in de keten per se een constante bitrate wil.

Een zender zonder overschrijving toont de overgenomen waarde, gemarkeerd als overgenomen, zodat altijd zichtbaar is of de getoonde engine voor die zender is gekozen of de globale instelling volgt. Wijzigt u de globale standaard, dan verandert elke overnemende zender tegelijk; zenders met een overschrijving blijven ongewijzigd.

Het wijzigen van de engine herstart de zender

De engine wordt gekozen wanneer de zender start, dus een wijziging gaat in bij de volgende start en de zender wordt herstart om die toe te passen. Kijkers zien de koude-startvertraging van die engine — ongeveer 1.9 s bij pass-through, ongeveer 4.4 s bij remux. Het wijzigen van de globale standaard herstart elke overnemende zender; doe dat dus in een rustig moment en niet ‘s avonds.