Zusammenfassung

  • Bei einer Resynchronisation kann der Empfänger sein jüngstes erfolgreich decodiertes Referenzbild nennen. Der Sender muss dennoch prüfen, ob genau diese Referenz noch in seinem eigenen Puffer liegt.
  • Ist sie dort nicht mehr verfügbar, sollte der Sender ein Schlüsselbild erzeugen. Empfängerwissen, Senderretention, Aussendung, Zustellung, Decodierung und Darstellung bleiben getrennte Nachweise.

Der Decoder meldete Frame ID 602 als jüngste gute Referenz. Für ihn war das eine präzise Aussage: 602 war erfolgreich decodiert worden, und der nächste brauchbare Abzweig konnte von dort beginnen. Der Encoder hatte 602 jedoch bereits aus seinem Referenzpuffer entfernt. Eine Steuerung, die allein der Empfängermeldung folgte, forderte eine Ableitung von einem Bild an, das auf der Senderseite nicht mehr existierte.

Beide Komponenten sagten die Wahrheit. Das System hatte ihnen nur eine gemeinsame Wahrheit unterstellt.

Der Entwurf RTCP Feedback Message and Request Mechanism for Frame-level Acknowledgement macht diese doppelte Zuständigkeit ausdrücklich. Setzt der Empfänger das R-Bit zur Resynchronisation, soll er seine jüngste erfolgreich decodierte Frame ID nennen und – soweit die Nachrichtenlänge reicht – Zustände bis zur jüngsten empfangenen Einheit liefern. Der Sender soll danach prüfen, ob die genannte Referenz noch in seinem Referenzpuffer vorhanden ist.

Ist sie vorhanden, sollte er das nächste Bild von dieser oder einer anderen Referenz codieren, die beim Empfänger nachweislich verfügbar ist. Ist sie senderseitig nicht mehr vorhanden, sollte er ein Schlüsselbild erzeugen. Die Meldung des Empfängers erteilt also keine einseitige Anweisung. Sie liefert eine Hälfte einer verteilten Entscheidung.

Die hier untersuchte Revision 01 ist auf den 6. Juli 2026 datiert und läuft am 7. Januar 2027 ab. Sie ist ein aktiver AVTCORE-Arbeitsgruppenentwurf im IETF-Stream mit vorgesehenem Status Informational. Datatracker führt I-D Exists, aber keinen Shepherd, verantwortlichen Area Director, keine IESG-Evaluierung, RFC-Nummer oder abgeschlossene IANA-Zuteilung. Das RTCP-Format nutzt PT 205; der FMT bleibt TBD, vorgeschlagen ist 12. Diese Fakten belegen Dokumentfortschritt, nicht Implementierung oder Betrieb.

Früh bestätigt heißt noch nicht fertig decodiert

Der Mechanismus arbeitet mit einer 16-Bit-Frame-ID, die für jede markierte Einheit in Sendereihenfolge um eins steigt und umläuft. Die RTP-Erweiterung sollte am letzten Paket der Einheit stehen und darf innerhalb eines Frames nicht mehrfach erscheinen. Jeder Startwert ist zulässig.

Ein Frame ist dabei jede decodierbare Bitstream-Einheit, die referenzierbaren Codec-Zustand aktualisiert. Das kann ein Vollbild, ein nicht dargestelltes Bild, ein eigenständig decodierbarer Tile oder Slice sein. Die ID ist daher nicht automatisch ein Beleg für ein sichtbares Bild.

Der positive Status hat ebenfalls eine bewusst weitere Bedeutung. Eins heißt: empfangen und decodiert oder empfangen und zur Decodierung vorgesehen. Um Verzögerung zu verringern, darf der Empfänger den Status schon vor Abschluss melden, wenn er den Versuch garantiert. Scheitert dieser danach, muss er ein Schlüsselbild anfordern, selbst bei einer verwerfbaren Schicht. Null fasst nicht empfangen, nicht decodiert und nicht zur Decodierung vorgesehen zusammen.

Eine früh positive 602 kann also zunächst nur ein Versprechen gewesen sein. Für eine Resynchronisation muss zusätzlich bekannt sein, ob die Decodierung später tatsächlich gelang. Selbst der erfolgreiche Abschluss sagt weiterhin nichts über die Retention beim Encoder.

Zwei Puffer, zwei Lebensdauern

Empfänger-Statusfenster und Sender-Referenzpuffer verfolgen unterschiedliche Zwecke. Das Empfängerfenster ist zusammenhängend, standardmäßig 255 IDs groß und kann zwischen 1 und 32.767 ausgehandelt werden. Ältere Einträge werden FIFO verworfen. Eine Antwort verschiebt ihren Start, wenn nur noch ein Teil der angefragten Spanne vorhanden ist; ohne Überschneidung liefert sie Länge null.

Ein verschobener Start oder eine Null-Länge sagt: Der Empfänger hält den abgefragten Einzelzustand nicht mehr vor. Der Sender darf die alten Frames nicht als Referenz verwenden. Die Meldung diagnostiziert weder Paketverlust noch Decodiererfolg.

Der Encoderpuffer kann kürzer, anders organisiert oder durch Codec- und Produktentscheidungen begrenzt sein. status-window-size garantiert keine korrespondierende Encoderkapazität. Eine Organisation, die beide Werte gleichsetzt, verwechselt ein ausgehandeltes Feedbacklimit mit einer lokalen Implementierungsressource.

Eine belastbare Resynchronisationsentscheidung braucht daher zwei Abfragen mit Zeitbezug: Welchen Zustand hält der Empfänger, und welche dafür geeignete Referenz hält der Sender jetzt? Dazwischen kann Eviktion stattfinden. Ein Cache-Hit aus einer alten Abfrage reicht nicht.

Auch die Antwortzeit verändert das Bild

RTCP-Zeit- und Bandbreitenregeln können Feedback verzögern. Währenddessen wandert das Empfängerfenster weiter. Der Entwurf verlangt, die Antwort aus dem Zustand zum Sendezeitpunkt zu bilden, nicht aus einer Momentaufnahme beim Eintreffen der Anfrage. Aus einer Anfrage 1–4 kann deshalb eine Antwort 3–4 werden.

Trifft eine neuere Anfrage ein, bevor die alte Antwort gesendet wurde, sollte der Empfänger die ältere verwerfen und nur die aktuelle beantworten. Das verhindert Rückstau, macht den Eingang einer Anfrage aber nicht zum dauerhaften Versprechen einer Antwort über genau diesen Bereich.

Außer Reihenfolge eintreffende, wiederhergestellte oder erneut gesendete Anforderungen werden nach der zugehörigen neueren Frame ID bewertet. Der Frame-Zustand kann gespeichert werden; die alte Anforderung wird ignoriert, wenn eine neuere bereits verarbeitet wurde. Ankunftszeit ist nicht dieselbe Ordnung wie Kontrollautorität.

Für das Beispiel 602 bedeutet das: Die Aussage muss den Zeitpunkt tragen. Zwischen Empfängerbericht, Senderprüfung und Codierentscheidung kann die Referenz an einem oder beiden Enden verschwinden.

SSRC und unabhängige Ketten begrenzen die Aussage

Frame-ID- und Feedbackzustand gehören zu einem Sender-/Empfänger-SSRC-Paar. Wechselt eine Seite ihren SSRC, beginnt die Folge neu und der alte Zustand wird verworfen. Ansonsten sind Lücken und willkürliche Resets unzulässig. Eine gleichlautende 602 aus einer anderen Epoche darf nicht als dieselbe Referenz gelten.

In einem SSRC können zudem unabhängige Simulcast- oder Abhängigkeitsketten ineinandergreifen. Eine spätere positive ID in einer Kette belegt keinen früheren Zustand in einer anderen. Die Referenzwahl muss Kettenzugehörigkeit berücksichtigen; ein globaler Höchstwert genügt nicht.

Ein SFU oder SFM kann IDs pro Ausgang umschreiben. Typischerweise sollte er upstream erst bestätigen, wenn alle aktiven Empfänger bestätigt haben. Dafür braucht es den aktiven Nenner und die Übersetzungslinie. Eine zusammengefasste Referenz ohne diese Angaben kann nicht als gemeinsamer Zustand aller Empfänger dienen.

SDP-Anzeigen für Header-Erweiterung und rtcp-fb beweisen nur ausgehandelte Fähigkeit. Sie zeigen weder, dass 602 angefordert wurde, noch dass beide Puffer sie hielten oder ein Wiederanlauf gelang.

Vom Referenzentscheid bis zum Nutzer bleibt Ausführung

Selbst wenn eine gemeinsame Referenz gefunden ist, ist die Wiederherstellung nicht abgeschlossen. Der Sender muss daraus eine neue Einheit codieren, paketieren und senden. Das Netz muss sie liefern. Der Empfänger muss sie rekonstruieren, decodieren und gegebenenfalls darstellen. Jede Stufe kann einen eigenen Fehler haben.

Der Parameter resync-timeout zwischen 1 und 65.535 Millisekunden beschreibt, wann Decodierstillstand eine Anforderung auslösen kann. Er ist keine Garantie, dass bis zum Ablauf wieder ein Bild sichtbar ist. Die R-Meldung ist eine Steuerhandlung, kein Ergebnis-SLA.

Für Führung und Audit ist deshalb ein gestuftes Vokabular nötig: Resynchronisation angefordert; Empfängerreferenz benannt; Senderreferenz bestätigt oder verworfen; Schlüsselbild entschieden; Recovery-Frame erzeugt; gesendet; empfangen; decodiert; dargestellt. Wer alles unter recovered speichert, verliert den Fehlerort.

Der kleinste gemeinsame Nachweis

Heng Lus Realitätsebenen trennen Symbol, Ausführungszustand und Beobachtung. Frame ID, Bereich und R-Bit sind Koordinationsaussagen. Statusfenster und Referenzpuffer sind flüchtiger Maschinenzustand. Paketzustellung, abgeschlossene Decodierung, Darstellung und wahrgenommene Qualität sind spätere Beobachtungen.

Eine Minimum Initial Specification sollte SSRC-Paar, Epoche, Frame ID, Anfragebereich und -zeit, Antwortzeit, Fenstergrenzen, exakte Bitbedeutung, Empfängerreferenz, Senderprüfung, gewählte Aktion und nachfolgende Ergebnisse halten. Sie muss nicht jeden Codec vereinheitlichen, wohl aber die Übergabe zwischen beiden Puffern.

Running-Code-Tests sollten die gemeldete Referenz vor der Senderprüfung eviktieren, Feedback bis zum Fensterrollover verzögern, nach einem frühen Positiv die Decodierung scheitern lassen, 16 Bit umlaufen lassen, SSRC wechseln, Ketten verschachteln und SFU-Empfängermengen verändern. Ein gutes System entscheidet sich dann sichtbar für eine andere Referenz oder ein Schlüsselbild, statt eine nicht mehr vorhandene Vergangenheit zu behaupten.

Die 602 des Empfängers blieb ein wertvoller Fakt. Sie sagte, wo dessen Decoder zuletzt sicher stand. Erst die getrennte Senderprüfung zeigte, dass dieser Ausgangspunkt nicht mehr ausführbar war. Resynchronisation entsteht nicht, indem eine Seite mehr Autorität erhält, sondern indem beide Seiten ihren aktuellen Zustand belegen.

Sources