Summary

  • Die acht Bit der FIR-Sequenz trennen eine neue Anforderung von deren Wiederholung innerhalb eines konkreten Sender-Ziel-SSRC-Paars. Sie sind kein Fortschrittszähler des Decoders.
  • Ein belastbarer Abschluss entsteht erst aus zusammenhängenden Belegen für Steuerung, codecgerechte Medienvollständigkeit, Decoderzustand und Darstellung; bei einer MCU muss jeder Abschnitt gesondert erhalten bleiben.

Im Störungsticket steht als Abschlussbeleg: „FIR sequence advanced“. Die Nummer ist tatsächlich neu, die RTCP-Rückmeldung formal gültig. Trotzdem bleibt das Endgerät auf einem beschädigten Bild stehen. Die acht Bit haben ihre Aufgabe erfüllt. Das Ticket hat ihnen nur eine Aufgabe zugeschrieben, die das Protokoll nie vergeben hat.

RFC 5104 ergänzt AVPF um codecbezogene Steuerungsnachrichten nahe am Medienstrom. Full Intra Request fordert einen Decoder-Refresh-Punkt an. TSTR und TSTN betreffen die zeitlich-räumliche Gewichtung, VBCM transportiert H.271-Rückmeldungen, und TMMBR sowie TMMBN beschreiben vorübergehende Gesamtratenlimits und die begrenzende Tupelmenge. Aus dem gemeinsamen Transport folgt kein gemeinsames Erfolgsmodell.

Ein FIR-Eintrag nennt den SSRC des betreffenden Mediensenders und führt eine acht Bit breite Sequenz. Der Nummernraum gehört zum Paar aus rückmeldendem SSRC und Ziel-SSRC. Eine wirklich neue FIR erhöht den Wert modulo 256. Jede Wiederholung derselben Anforderung behält ihn bei.

Damit kann der Empfänger eine verspätete Kopie von einem neuen Auftrag unterscheiden. Der Encoder muss wegen wiederholter Kontrollpakete nicht mehrfach teure Refresh-Bilder erzeugen. Mehr beweist die Zahl nicht. Sie enthält weder Annahmezeit noch Ausführungsstatus, Paketbereich, Verlust, Decoderzustand oder Renderereignis.

Selbst „neu“ ist ohne Geltungsbereich kein stabiler Begriff. Nach dem Umlauf von 255 auf 0, nach einem SSRC-Wechsel oder in einer neuen Sitzung können identische Werte verschiedene Anforderungen bezeichnen. Ein Prüfpfad muss deshalb Sitzung, SSRC-Paar, Richtung, Sicherheitskontext und Zeitunsicherheit bewahren. Eine isolierte Sequenz in einem Ticket ist ein entkernter Beleg.

Der angeforderte Refresh-Punkt ist eine Folge von Bits, die den Decoder vollständig in einen bekannten Zustand versetzt. Sie kann über ein oder mehrere RTP-Pakete verteilt sein, als Intra-Bild, IDR oder graduelle Aktualisierung erscheinen. Benötigt die weitere Decodierung Parameter oberhalb der Bildschicht, müssen auch diese im Strom verfügbar sein.

Ein Encoderprotokoll „IDR gesendet“ beschreibt daher nur eine Beobachtung am Ursprung. Eine Fragmentgruppe kann unvollständig ankommen, Parameter können fehlen, oder der Refresh kann nach einem Quellenwechsel nicht mehr zur angezeigten Periode gehören. RFC 6184 zeigt am H.264-Payload, warum Paketierung und Codec-Kontext für die Vollständigkeit maßgeblich sind.

Der Encoder soll nach dem Empfang einer FIR so bald wie möglich einen Refresh-Punkt senden. Er bleibt aber an die Überlastkontrolle gebunden. Ein Refresh-Bild kann ein Vielfaches eines prädizierten Bildes beanspruchen. Bei niedriger verfügbarer Rate dauert die Übertragung länger als ein Bildintervall. „Bearbeitet“ im Kontrollsystem kann zeitlich weit vor vollständiger Medienzustellung liegen.

Die Wiederholungsregel verwaltet diese Unsicherheit. Der Anforderer darf dieselbe FIR wiederholen, bis der gewünschte Inhalt eintrifft. Er soll Wiederholungen jedoch sowohl bei einem vollständigen Refresh als auch dann beenden, wenn er einen durch Verlust beschädigten Refresh-Versuch erkennt. Aus dem Ende der Wiederholung allein lässt sich Erfolg nicht ableiten.

Ist nach einem beschädigten Versuch weiterhin ein Refresh erforderlich, entsteht mit erhöhter Sequenz eine neue FIR. Pro Mediensender darf nur eine unterschiedliche FIR ausstehen. Wiederholt der Anforderer länger als zwei Umlaufzeiten, nachdem der Encoder einen Refresh gesendet hat, muss der Encoder einen weiteren erzeugen. Das steigert die Lieferchance, liefert aber keinen Nachweis für Bildausgabe.

Eine eigene FIR-Erfolgsbestätigung fehlt bewusst. RFC 5104 begründet das damit, dass Decoder-Refresh-Punkte im Bitstrom erkennbar sind. Der Anforderer kann die Wirkung also im Datenpfad suchen, statt einer Bestätigung im Kontrollpfad zu vertrauen. Der maßgebliche erste Wirkungsbeleg liegt bei den Medien.

Auch dort endet die Kette noch nicht. Ein codecverständiger Beobachter kann einen vollständigen oder beschädigten Versuch feststellen. Erst der Decoder kann melden, dass sein Referenzzustand zurückgesetzt wurde. Erst Renderer oder Anwendung können melden, dass ein brauchbares Bild erschien. Wer „Nutzer wiederhergestellt“ sagt, braucht eine definierte Verbindung dieser Nachweise.

Die Regel „nur eine unterschiedliche FIR ausstehend“ schützt außerdem nicht vor organisatorischer Mehrdeutigkeit. Zwei Überwachungssysteme können dieselbe Wiederholung verschieden benennen, wenn sie die Paarbildung nicht teilen. Oder ein Steuerdienst kann einen neuen Auftrag eröffnen, während ein später Medienbeobachter noch Pakete des alten Versuchs sieht. Der gemeinsame Schlüssel muss aus der Protokollidentität stammen, nicht aus einer beliebigen Ticketnummer.

Mit einer MCU teilt sich die Zuständigkeit. Nach den RTP-Topologien der RFC 5117 kann eine schaltende MCU die FIR eines Empfängers erhalten und eine weitere FIR an die aktuell ausgewählte Quelle erzeugen. RFC 5104 behandelt die Zuverlässigkeit zwischen Empfänger und MCU sowie zwischen MCU und Quelle unabhängig.

Die eingehende FIR kann ankommen, während die ausgehende verloren geht. Die Quelle kann einen Refresh erzeugen, während die MCU auf eine andere Quelle umschaltet. Die MCU kann den Refresh erhalten und nur einen Teil zum ursprünglichen Empfänger weitergeben. Jede Strecke benötigt ihren eigenen SSRC-Geltungsbereich, Sicherheitskontext, Zeitbezug und Medienbeleg.

Eine zentrale Zeile „FIR abgeschlossen“ kann diese Übergaben nicht erklären. Im besten Fall verschleiert sie eine Lücke; im schlechtesten Fall ordnet sie einen echten Refresh dem falschen Empfänger zu. Nachweise sollten Auswahlwechsel, Medienepochennummer, Paketbereich und die Unsicherheit zwischen Uhren festhalten, ohne Zeitstempel nachträglich passend zu machen.

FIR ist auch keine Standardreaktion auf gewöhnlichen Bildverlust. Für diesen Zweck empfiehlt RFC 5104 die Picture Loss Indication aus RFC 4585. FIR gehört zu Situationen, in denen das Ausbleiben eines Refreshs Video unbrauchbar lässt, etwa beim Beitritt ohne regelmäßigen Refresh oder beim Umschalten einer MCU auf eine andere codierte Quelle.

Diese Begrenzung verhindert eine Rückkopplung. Häufige Refresh-Punkte benötigen deutlich mehr Bandbreite, können die Bildrate senken und ruckelnde Ausgabe verursachen. Wandelt eine Automatisierung jedes Verlustsignal in FIR um, kann sie die Überlast erzeugen, die ihr Dashboard anschließend als Netzproblem meldet. Befehlspolitik und Qualitätswirkung müssen getrennt prüfbar sein.

Die übrigen Nachrichten widerlegen eine universelle „Acknowledged“-Anzeige. TSTR bittet um eine andere zeitlich-räumliche Gewichtung, TSTN meldet die tatsächlich gewählte Gewichtung. Sie darf von der Bitte abweichen, weil der Encoder mehrere Empfänger, lokale Regeln und Ressourcen ausgleicht. Die Rückmeldung belegt eine Auswahl, nicht die wortgetreue Erfüllung.

TMMBR und TMMBN folgen erneut anderer Semantik. Ein Empfänger meldet eine maximale Gesamtmedienrate samt Paket-Overhead. Der Sender berechnet einen zulässigen Bereich und jene Tupel, die dessen Grenze bilden, und kündigt Menge sowie Eigentümer an. Selbst wenn das neue Tupel nicht in die Grenzmenge eingeht, ist eine TMMBN-Antwort erforderlich. Antwort bedeutet nicht Annahme.

Die Gesamtrate hängt zudem vom Beobachtungspunkt ab. Sender und Empfänger können auf verschiedenen Protokollschichten zählen und unterschiedlichen Overhead erfassen. TMMBR beschreibt bekannte, oft lokale Grenzen, keine Garantie für die ganze Strecke. RFC 8083 ordnet RTCP-Rückmeldungen in die Überlastkontrolle ein.

Sicherheit schützt die Aussage des Befehls. Gefälschte Rückmeldungen könnten extrem niedrige Raten erzwingen, Eigentümer der Grenzmenge vortäuschen, unerwünschte Qualitätspräferenzen setzen oder so viele Refresh-Punkte auslösen, dass Video ruckelt. RFC 3711 und das SAVPF-Profil in RFC 5124 liefern Authentizität und Integrität.

Eine authentisierte FIR ist damit stärker als ein ungeschütztes Paket. Sie beweist den Sprecher im jeweiligen Sicherheitskontext. Sie authentisiert jedoch nicht nachträglich die Encoderwarteschlange, die RTP-Zustellung, den Decoderzustand oder den Bildschirm. Werden gefälschte und echte Rückmeldungen nicht unterschieden, ist der Befehl unzuverlässig; werden Befehl und Ergebnis nicht unterschieden, ist die Betriebsbewertung unzuverlässig.

RFC 5104 bleibt Proposed Standard und wurde durch RFC 7728 für Pause und Fortsetzung von RTP-Strömen sowie durch RFC 8082 für geschichtete Codecs aktualisiert. Ein Sammler, der nur die ursprüngliche Nachricht erkennt, kann in einer aktuellen Sitzung eine pausierte oder falsch geschichtete Quelle dennoch als fehlerhaftes Verhalten bewerten.

Ein belastbares Evidenzbuch führt deshalb Sitzung und Sicherheitskontext, Quell- und Ziel-SSRC, Sequenzgeneration, Erstsendung und Wiederholungen, MCU-Strecken, Encoderempfang, codecspezifische Refresh-Erzeugung, RTP-Paketbereich und Verlust, Erkennung eines vollständigen oder beschädigten Versuchs, Decoderreset, dargestelltes Bild und nutzersichtbare Wiederherstellung zusammen. Es bewahrt die Grenzen jeder Aussage.

Das entspricht Heng Lus Disziplin der Realitätsebenen. Das Kontrollsystem darf sagen, dass der richtige Befehl gesendet wurde. Der Medienbeobachter darf sagen, dass ein Versuch eintraf. Decoder und Renderer dürfen ihre jeweiligen Zustände bestätigen. Führung darf daraus ein Diensturteil bilden, aber keiner Ebene nachträglich die Autorität der nächsten zuschreiben.

Sources