Auflösungsprofile

Welches Problem das löst

Eine Master-Playlist führt mehrere Stufen auf — etwa 1080p, 720p und 480p —, und ein gewöhnlicher Player wählt zwischen ihnen, indem er seinen eigenen Durchsatz misst. Verarbeitet eine Kopfstation diese Playlist, ist eine solche Anpassung sinnlos: Der Stream geht an eine feste Multicast-Gruppe für eine feste Menge von Fernsehern, in genau der Qualität, die die erste Stufe hat, die der Engine zusagt.

In der Praxis entscheidet die Reihenfolge beim Ursprungsserver, und Ursprungsserver führen ihre beste Stufe zuerst auf. Das übliche Ergebnis: Eine 1080p-Stufe wird dauerhaft bezogen, um SD-Bildschirme in Gästezimmern zu versorgen. Das ist keine kleine Verschwendung: Es ist ein Vielfaches der Bandbreite für ein Bild, dessen Vorteil niemand sehen kann, multipliziert mit jedem Sender auf dem Gerät — und das gerade auf knappen Uplinks, wo es am meisten schmerzt.

Ein Auflösungsprofil am Sender nimmt diese Entscheidung dem Ursprungsserver ab.

Die Profile

Profil	Zielhöhe	Ebenfalls akzeptiert
4k	2160	`uhd`, `2160p`
fullhd	1080	`1080p`
hd	720	`720p`
sd	576	`576p`, `480p`
mobile	360	`360p`, `low`
(leer)	—	Standard. Die Master-Playlist wird unverändert an die Engine übergeben.

Leer ist der Standard und der Wert aller bereits bestehenden Sender. Das ist wichtig: Die Einführung dieser Funktion hat an keinem bereits konfigurierten Sender etwas geändert. Ein Profil aktivieren Sie bewusst pro Sender; es ist kein Verhalten, das plötzlich aufgetaucht ist und Ihre Playlists neu interpretiert.

Wie eine Variante ausgewählt wird

Die nächstliegende Höhe gewinnt. Bei Gleichstand gewinnt die höhere Bitrate.

Castmux liest die Master-Playlist, nimmt die deklarierte RESOLUTION jeder Variante und wählt diejenige, deren Höhe der Zielhöhe des Profils am nächsten kommt. Sind zwei Varianten gleich weit entfernt, wird die mit der höheren angegebenen Bandbreite gewählt.

Das ist bewusst kein „exakte Übereinstimmung oder Fehler“. Ursprungsserver veröffentlichen beliebige Stufenleitern, und insbesondere 576p ist in der Praxis selten — die meisten bieten stattdessen 480p an. Ein Sender, der nicht startet, weil niemand genau 576 Zeilen liefert, ist in jeder Hinsicht schlechter als einer, der 480p streamt und Ihnen das mitteilt. Keine perfekte Übereinstimmung zu finden ist kein Fehlerzustand, sondern der Normalfall.

Das Treffer-Badge

Der Kopf der Senderkarte zeigt beide Hälften der Entscheidung: was Sie angefordert haben und was der Ursprungsserver tatsächlich hatte.

Badge	Bedeutung
HD	720p wurde angefordert, und eine 720p-Stufe existiert. Exakte Übereinstimmung.
4K (1080p)	4K wurde angefordert; das Beste, was der Ursprungsserver bietet, ist 1080p, und das wird gestreamt. In Bernstein dargestellt.
SD (480p)	576 Zeilen wurden angefordert; 480p war die nächstliegende Stufe. In Bernstein dargestellt.

Bernstein ist eine Information, kein Fehler. Es besagt, dass das Profil nicht exakt erfüllt werden konnte, und zeigt, was stattdessen verwendet wurde. Ein Sender mit bernsteinfarbenem Badge arbeitet korrekt. Wer Bernstein als Alarmzustand behandelt, erzeugt bei jeder realistischen Auswahl an Ursprungsservern eine Flut von Fehlalarmen, weil die meisten Stufenleitern nicht exakt zu einer festen Menge von Profilhöhen passen.

Konnte eine Abfrage überhaupt nicht abgeschlossen werden, nennt der Tooltip des Badges den Grund. Dort sollten Sie zuerst nachsehen, wenn ein Sender nicht die erwartete Stufe streamt.

Die Ersetzung gilt pro Start und wird nie gespeichert

Die Konfiguration enthält immer die URL der Master-Playlist, die Sie eingegeben haben. Beim Start eines Senders ermittelt Castmux die Variante und übergibt deren URL nur für diesen Lauf an die Engine. Nichts wird zurückgeschrieben.

Darauf ist ausdrücklich zu bestehen, denn die Varianten-URL in die Konfiguration zu schreiben, wirkt wie eine naheliegende Optimierung und ist aus zwei unabhängigen Gründen eine Falle:

Der Sender würde auf eine Stufe festgelegt, die der Ursprungsserver zurückziehen kann. Stufenleitern ändern sich. Streicht ein Ursprungsserver nächsten Monat seine 480p-Stufe, ruft ein festgelegter Sender dauerhaft eine URL ab, die nun 404 liefert — ohne Weg zurück zur Master-Playlist, es sei denn, ein Bediener tippt sie neu ein.
Sie wäre nicht von einer bewussten Wahl des Bedieners zu unterscheiden. Sobald eine Varianten-URL in der Konfigurationsdatei steht, hält nichts fest, ob ein Mensch sie absichtlich eingetragen oder die Software sie ersetzt hat. Jeder spätere Versuch, neu aufzulösen, liefe Gefahr, eine bewusste Entscheidung zu überschreiben.

Die Auflösung bei jedem Start kostet einen Lesezugriff auf eine zwischengespeicherte Playlist und sorgt dafür, dass der Sender der Stufenleiter des Ursprungsservers folgt, wie auch immer sie sich ändert.

Im Fehlerfall bleibt der Sender offen

Die Profilauflösung liegt im Streaming-Pfad und fällt deshalb auf das konfigurierte Verhalten zurück statt auf einen schwarzen Bildschirm. In allen folgenden Fällen bleibt die konfigurierte URL unverändert, der Grund wird protokolliert, und der Sender startet:

Der Ursprungsserver ist nicht erreichbar, oder der Abruf läuft in ein Timeout.
Die URL erweist sich als Media-Playlist, nicht als Master — es gibt keine Stufenleiter, aus der gewählt werden könnte.
Die Master-Playlist enthält keine RESOLUTION-Attribute, sodass keine Höhe verglichen werden kann.
Die Playlist ist auf irgendeine Weise fehlerhaft, die das Lesen der Varianten verhindert.

In jedem dieser Fälle streamt der Sender genau so, wie er es ohne gesetztes Profil täte. Der Grund bleibt nicht verborgen: Er wird protokolliert und im Tooltip des Badges angezeigt, sodass Sie im Dashboard sehen, warum ein Profil nicht angewendet wird.

Abfragen blockieren nie den Seitenaufbau

Ergebnisse werden zwischengespeichert — nach Erfolg etwa zehn Minuten, nach einem Fehler eine Minute — und im Hintergrund aktualisiert. Beim Aufbau einer Seite oder bei der Antwort auf eine Statusabfrage wird der Cache gelesen und bei veraltetem Eintrag eine Aktualisierung eingeplant; gewartet wird nie. Die einzige Stelle, die auf eine Live-Abfrage wartet, ist ein vollständig kalter Engine-Start, bei dem es ohnehin noch nichts zu streamen gibt.

Der Grund ist schlichte Rechnung. Fünfundzwanzig Sender mit je acht Sekunden Abruf-Timeout, bei jedem Seitenaufruf und jeder Abfrage, ergeben eine Oberfläche, die minutenlang hängt, sobald ein Ursprungsserver langsam ist — und Ursprungsserver sind genau dann langsam, wenn ein Bediener auf das Dashboard schauen will. Die kürzere Cache-Dauer nach einem Fehler sorgt dafür, dass ein vorübergehend gestörter Ursprungsserver zügig erneut versucht wird, statt für zehn Minuten abgeschrieben zu sein.

Zwei Schutzmechanismen, die Sie kennen sollten

Beide existieren, weil die naive Implementierung einen defekten Sender auf Sendung bringt und dabei Erfolg meldet.

Reine Audio-Renditions werden übersprungen

Viele Stufenleitern enthalten eine reine Audio-Rendition. Sie trägt kein RESOLUTION-Attribut, ihre Höhe wird also als null gelesen, und ein naiver Vergleich der nächstliegenden Höhe mit der Zielhöhe 360 des Profils mobile macht sie zum Sieger über jede echte Videostufe. Der Sender startet dann, meldet sich als gesund, erzeugt Pakete und bringt eine Playlist ohne Video auf Sendung.

Varianten ohne RESOLUTION-Attribut werden deshalb vollständig von der Auswahl ausgeschlossen.

Eine gedemuxte Stufenleiter wird abgelehnt

Deklariert die Master-Playlist Audio mit #EXT-X-MEDIA:TYPE=AUDIO und hat diese Deklaration ein eigenes URI=, liegt der Ton nicht in den Videosegmenten. Er ist eine separate Rendition, die der Client zusätzlich zum Video abrufen und selbst zusammenführen soll.

Würde aus einer solchen Stufenleiter eine einzelne Videovariante gewählt, erhielte die Engine eine Playlist, die nur Video enthält. Das Ergebnis ist stummes Video auf Sendung — ein Sender, der auf jeder Anzeige perfekt aussieht und keinen Ton hat.

Deshalb lehnt Castmux ab. Ein Sender, dessen Master-Playlist eine gedemuxte Audio-Stufenleiter anbietet, behält seine Master-URL, die Audioverarbeitung der Master-Playlist greift weiterhin, und das Badge nennt den Grund. Einen Teil-Workaround gibt es nicht: Eine Engine, die eine URL erhält, kann zwei Renditions nicht wieder zusammenführen, und dafür bräuchte sie einen zweiten Eingang und ein explizites Stream-Mapping — was den Aufbau des Senders grundlegend ändert.

Nur HLS

Auflösungsprofile gelten für HLS-Quellen und für nichts anderes. SRT und RTMP liefern eine einzige feste Kodierung ohne Stufenleiter, es gibt also nichts nachzuschlagen.

Das heißt nicht bloß „die Einstellung wird ignoriert“. Für einen Nicht-HLS-Sender wird überhaupt keine HTTP-Anfrage gestellt. Der Unterschied ist wichtig, weil der Fehler, wenn man es falsch macht, unangenehm und unauffällig ist: Bei jedem Seitenaufbau und jeder Statusabfrage, für jeden SRT-Sender auf dem Gerät, geht ein HTTP-GET an eine srt://-URL — mit Latenz und Log-Rauschen, die scheinbar aus dem Nichts kommen.

Ein durchgerechnetes Beispiel

Ein Ursprungsserver veröffentlicht diese Stufenleiter:

#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

Der Sender ist auf resolution_profile: sd eingestellt, Zielhöhe 576 Zeilen.

Zuerst wird die reine Audio-Rendition verworfen: Sie hat kein RESOLUTION-Attribut. Ohne diesen Schritt käme sie auf eine Höhe von null und würde beim Profil mobile klar gewinnen.
Für die übrigen wird der Abstand zu 576 berechnet: 1080p liegt 504 entfernt, 720p 144, 480p 96.
480p liegt am nächsten, also wird v480.m3u8 für diesen Lauf an die Engine übergeben. Die Konfiguration enthält weiterhin die Master-URL.

Der Kartenkopf zeigt SD (480p) in Bernstein: 576 wurde angefordert, 480p war das Nächstliegende, was der Ursprungsserver hatte, und der Sender streamt es korrekt.