Resolutieprofielen

Het probleem dat dit oplost

Een master-playlist noemt meerdere treden — bijvoorbeeld 1080p, 720p en 480p — en een gewone speler kiest daartussen door zijn eigen doorvoer te meten. Wanneer een kopstation die playlist afneemt, heeft zo’n aanpassing geen betekenis: de stream gaat naar een vaste multicastgroep voor een vaste set televisies, in de kwaliteit van de eerste trede die de engine toevallig kiest.

In de praktijk beslist de volgorde van de originserver, en originservers zetten hun beste trede bovenaan. Het gebruikelijke resultaat is dat er continu een 1080p-trede wordt opgehaald om SD-schermen in gastenkamers te voeden. Dat is geen kleine verspilling: het is meerdere keren de bandbreedte voor beeld waarvan niemand het voordeel kan zien, vermenigvuldigd met elke zender op het apparaat, en juist op de beperkte uplinks waar het het meeste pijn doet.

Door een resolutieprofiel op de zender in te stellen, neemt u die beslissing uit handen van de originserver.

De profielen

Profiel	Doelhoogte	Ook geaccepteerd
4k	2160	`uhd`, `2160p`
fullhd	1080	`1080p`
hd	720	`720p`
sd	576	`576p`, `480p`
mobile	360	`360p`, `low`
(leeg)	—	Standaard. De master-playlist wordt ongewijzigd aan de engine doorgegeven.

Leeg is de standaard, en dat is wat elke bestaande zender heeft. Dat is belangrijk: de komst van deze functie heeft niets veranderd aan zenders die al waren geconfigureerd. Een profiel kiest u per zender bewust; het is geen gedrag dat ineens verscheen en uw playlists anders begon te interpreteren.

Hoe een variant wordt gekozen

De dichtstbijzijnde hoogte wint. Bij gelijke stand wint de hogere bitrate.

Castmux leest de master-playlist, neemt de opgegeven RESOLUTION van elke variant en kiest de variant waarvan de hoogte het dichtst bij de doelhoogte van het profiel ligt. Liggen twee varianten even ver weg, dan wordt die met de hoogste opgegeven bandbreedte gekozen.

Dit is bewust geen ‘exact of niets’. Originservers publiceren elke ladder die ze willen, en met name 576p komt in de praktijk weinig voor — de meeste publiceren in plaats daarvan 480p. Een zender die weigert te starten omdat niemand precies 576 lijnen levert, is gewoonweg slechter dan een zender die 480p streamt en u vertelt dat hij dat doet. Geen perfecte match vinden is geen foutsituatie; het is het normale geval.

Het matchlabel

De kop van de zenderkaart toont beide helften van de beslissing: waar u om vroeg, en wat de originserver daadwerkelijk had.

Label	Betekenis
HD	Er is om 720p gevraagd en er bestaat een 720p-trede. Exacte match.
4K (1080p)	Er is om 4K gevraagd; het beste wat de originserver biedt is 1080p, en dat wordt gestreamd. Weergegeven in amber.
SD (480p)	Er is om 576 lijnen gevraagd; 480p was de dichtstbijzijnde trede. Weergegeven in amber.

Amber is informatie, geen storing. Het zegt dat het profiel niet exact kon worden ingevuld en vertelt u wat er in plaats daarvan is gebruikt. Een zender met een amberkleurig label werkt correct. Amber behandelen als alarmsituatie levert bij elke realistische verzameling originservers een muur van valse meldingen op, omdat de meeste ladders niet precies aansluiten op een vaste set profielhoogtes.

Kon een opzoeking helemaal niet worden voltooid, dan staat de reden in de tooltip van het label. Daar kijkt u als eerste wanneer een zender niet de trede streamt die u verwachtte.

De vervanging geldt per start en wordt nooit opgeslagen

De configuratie bevat altijd de URL van de master-playlist die u hebt ingevoerd. Wanneer een zender start, bepaalt Castmux de variant en geeft die URL alleen voor die run aan de engine door. Er wordt niets teruggeschreven.

Dit verdient een stellig standpunt, want de variant-URL in de configuratie schrijven lijkt een voor de hand liggende optimalisatie en is om twee afzonderlijke redenen een valkuil:

De zender zou vastzitten aan een trede die de originserver kan intrekken. Ladders veranderen. Een originserver die volgende maand zijn 480p-trede schrapt, laat een vastgezette zender voor altijd een URL ophalen die nu 404 geeft, zonder weg terug naar de master-playlist tenzij een beheerder die opnieuw intypt.
Het zou niet te onderscheiden zijn van een eigen keuze van een beheerder. Zodra een variant-URL in het configuratiebestand staat, legt niets vast of een mens die er bewust heeft neergezet of dat de software hem heeft vervangen. Elke latere poging tot opnieuw bepalen zou het risico lopen een bewuste beslissing te overschrijven.

Bij elke start opnieuw bepalen kost één gecachte playlist-leesactie en zorgt ervoor dat de zender de ladder van de originserver blijft volgen, waar die ook heen gaat.

Het faalt open

Het bepalen van het profiel zit op het streamingpad, dus het valt terug op het geconfigureerde gedrag en niet op zwart beeld. In alle onderstaande gevallen blijft de geconfigureerde URL ongemoeid, wordt de reden gelogd en start de zender:

De originserver is onbereikbaar of het ophalen loopt in een time-out.
De URL blijkt een media-playlist te zijn en geen master — er is geen ladder om uit te kiezen.
De master bevat geen RESOLUTION-attributen, dus er valt geen hoogte te vergelijken.
De playlist is zodanig misvormd dat de varianten niet kunnen worden gelezen.

In elk geval streamt de zender precies zoals hij zonder ingesteld profiel zou hebben gedaan. De reden blijft niet verborgen: hij wordt gelogd en staat in de tooltip van het label, zodat u in het dashboard kunt zien waarom een profiel niet wordt toegepast.

Opzoekingen blokkeren nooit het laden van een pagina

Resultaten worden gecachet — ongeveer tien minuten bij succes, één minuut na een fout — en op de achtergrond ververst. Een pagina weergeven of een statusverzoek beantwoorden leest de cache en plant een verversing als de vermelding verouderd is; er wordt nooit gewacht. De enige plek die op een live opzoeking wacht, is een volledig koude start van de engine, waarbij er toch nog niets te streamen valt.

De rekensom is de reden. Vijfentwintig zenders, elk met een time-out van acht seconden voor het ophalen, bij elke paginalading en elk statusverzoek, levert een interface op die minutenlang hangt zodra een originserver traag is — en originservers zijn juist traag op de momenten dat een beheerder naar het dashboard probeert te kijken. De kortere cacheduur na een fout bestaat zodat een tijdelijk kapotte originserver snel opnieuw wordt geprobeerd in plaats van tien minuten te worden afgeschreven.

Twee beveiligingen die u moet kennen

Beide bestaan omdat een naïeve implementatie een kapotte zender in de lucht brengt en tegelijk succes meldt.

Renditions met alleen audio worden overgeslagen

Veel ladders bevatten een rendition met alleen audio. Die heeft geen RESOLUTION-attribuut, dus de hoogte telt als nul, en een naïeve vergelijking op dichtstbijzijnde hoogte met de doelhoogte 360 van het profiel mobile laat die winnen van elke echte videotrede. De zender start dan, meldt zich gezond, produceert pakketten en zet een playlist zonder video in de lucht.

Varianten zonder RESOLUTION-attribuut worden daarom volledig van de selectie uitgesloten.

Een gedemuxte ladder wordt geweigerd

Als de master audio opgeeft met #EXT-X-MEDIA:TYPE=AUDIO en die opgave een eigen URI= heeft, zit de audio niet in de videosegmenten. Het is een aparte rendition die de client naast de video hoort op te halen en zelf te combineren.

Eén videovariant uit zo’n ladder kiezen, zou de engine een playlist geven met video en verder niets. Het resultaat is video zonder geluid in de lucht — een zender die op elke meter perfect lijkt en geen geluid heeft.

Castmux weigert dus. Een zender waarvan de master een gedemuxte audioladder aanbiedt, houdt zijn master-URL, de eigen audioafhandeling van de master blijft van toepassing, en het label vermeldt de reden. Er is geen gedeeltelijke omweg: een engine met één URL kan twee renditions niet weer samenvoegen, en dat laten gebeuren vereist een tweede invoer en expliciete stream-mapping, wat de opbouw van de zender volledig verandert.

Alleen HLS

Resolutieprofielen gelden voor HLS-bronnen en voor niets anders. SRT en RTMP leveren één vaste encoding zonder ladder om uit te kiezen, dus er valt niets op te zoeken.

Dit is niet alleen „de instelling wordt genegeerd”. Voor een niet-HLS-zender wordt helemaal geen HTTP-verzoek gedaan. Dat onderscheid is belangrijk, omdat het faalgedrag als dit fout gaat onaangenaam en stil is: bij elke paginaweergave en elk statusverzoek een HTTP GET afvuren op een srt://-URL, voor elke SRT-zender op het apparaat, met vertraging en logruis die uit het niets lijken te komen.

Uitgewerkt voorbeeld

Een originserver publiceert deze ladder:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=5200000,RESOLUTION=1920x1080
v1080.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2800000,RESOLUTION=1280x720
v720.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1400000,RESOLUTION=854x480
v480.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=96000,CODECS="mp4a.40.2"
audio.m3u8

De zender staat op resolution_profile: sd, met als doel 576 lijnen.

Eerst wordt de rendition met alleen audio weggegooid: die heeft geen RESOLUTION-attribuut. Zonder die stap zou hij een hoogte van nul scoren en bij het profiel mobile meteen winnen.
Voor de rest worden de afstanden tot 576 berekend: 1080p ligt er 504 vanaf, 720p 144 en 480p 96.
480p ligt het dichtstbij, dus v480.m3u8 wordt voor deze run aan de engine doorgegeven. De configuratie bevat nog steeds de master-URL.

De kop van de kaart toont SD (480p) in amber: er is om 576 gevraagd, 480p was het dichtstbijzijnde wat de originserver had, en de zender streamt dat correct.