4. Anwendung zur Wiederherstellung der Dekodierungsreihenfolge bei geschichteten Codecs

Pakete in RTP-Strömen sind oft prädiktiv kodiert, wobei ein Empfänger die Pakete in einer bestimmten Reihenfolge anordnen muss, bevor er die Mediendaten dekodieren kann. Abhängig vom Nutzlastformat (Payload Format) kann die Dekodierungsreihenfolge explizit als Feld im RTP-Payload-Header angegeben werden, oder der Empfänger dekodiert die Pakete in der Reihenfolge ihrer RTP-Zeitstempel. Wenn eine geschichtete Kodierung verwendet wird, bei der die Mediendaten auf mehrere RTP-Ströme aufgeteilt sind, ist es oft notwendig, die RTP-Ströme, die die verschiedenen Schichten bilden, exakt zu synchronisieren, bevor andere Schichten als die Basisschicht dekodiert werden können. Beispiele für solche geschichteten Kodierungen sind H.264 SVC im NI-T-Modus [AVT-RTP-SVC] und MPEG-Surround-Mehrkanal-Audio [RFC5691]. Wie in Abschnitt 2 beschrieben, ist eine solche Synchronisation in RTP möglich, kann aber schwierig schnell durchzuführen sein. Im Folgenden beschreiben wir, wie die in Abschnitt 3.3 definierten Erweiterungen verwendet werden können, um geschichtete Ströme zu synchronisieren und eine gemeinsame zeitstempelbasierte Dekodierungsreihenfolge bereitzustellen.

4.1. In-Band-Synchronisation zur Wiederherstellung der Dekodierungsreihenfolge

Wenn ein geschichteter, Multi-Description- oder Multi-View-Codec verwendet wird, wobei die verschiedenen Komponenten der Medien auf separaten RTP-Strömen übertragen werden, SOLLTE der RTP-Sender eine periodische synchrone In-Band-Übermittlung von Synchronisations-Metadaten verwenden, um den Empfängern eine schnelle und genaue Synchronisation der separaten Komponenten des geschichteten Medienstroms zu ermöglichen. Dies umfasst drei Teile:

• Der Sender muss die Verwendung der in Abschnitt 3.3 beschriebenen RTP-Header-Erweiterungen aushandeln und muss diese Header-Erweiterungen periodisch und synchron in alle RTP-Ströme einfügen, die die separaten Komponenten des geschichteten, Multi-Description- oder Multi-View-Stroms bilden.

• Das synchrone Einfügen erfordert, dass der Sender diese RTP-Header-Erweiterungen in Pakete einfügt, die in allen Strömen exakt demselben Abtastzeitpunkt entsprechen. Da die Header-Erweiterungen für jeden Strom zu exakt denselben Abtastzeitpunkten eingefügt werden, weisen sie identische Zeitstempel im NTP-Format auf, was es den Empfängern ermöglicht, die RTP-Zeitstempel für die beteiligten Ströme exakt aufeinander auszurichten. Dies kann das Einfügen zusätzlicher Datenpakete in einige der beteiligten RTP-Ströme erfordern, falls einige beteiligte Ströme Pakete für Abtastzeitpunkte enthalten, die in anderen Strömen nicht vorhanden sind (z. B. ein geschichteter Video-Codec, bei dem die Schichten unterschiedliche Bildraten haben).

• Die Häufigkeit, mit der der Sender die Header-Erweiterungen einfügt, entspricht direkt der Synchronisationslatenz, wobei häufigeres Einfügen zu höheren Overheads pro Strom, aber zu einer geringeren Synchronisationslatenz führt. Es wird EMPFOHLEN, dass der Sender die Header-Erweiterungen mindestens einmal pro Random-Access-Point der Medien synchron in alle beteiligten RTP-Ströme einfügt, sie KÖNNEN jedoch auch häufiger eingefügt werden.

Der Sender MUSS weiterhin periodische RTCP-Berichte einschließlich SR-Pakete senden und MUSS sicherstellen, dass die Zuordnung von RTP-Zeitstempel zu NTP-Format-Zeitstempel in den RTCP SR-Paketen konsistent mit der in den RTP-Header-Erweiterungen verwendeten ist. Empfänger sollten sowohl die in den RTCP SR-Paketen enthaltenen Informationen als auch die In-Band-Zuordnung von RTP- und NTP-Format-Zeitstempeln als Eingabe für den Synchronisationsprozess verwenden. Es wird jedoch EMPFOHLEN, dass Empfänger die empfangenen Zuordnungen auf Plausibilität prüfen und Ausreißer (Outliers) verwerfen, um Robustheit gegenüber ungültigen Daten zu gewährleisten (man könnte meinen, dass es wahrscheinlicher ist, dass die RTCP SR-Zuordnungen ungültig sind, da sie zu unregelmäßigen Zeiten gesendet werden und Taktabweichungen (Skew) unterliegen, aber das Vorhandensein fehlerhafter RTP-Translatoren könnte auch die Zeitstempel in der RTP-Header-Erweiterung korrumpieren; Empfänger müssen mit beiden Arten von Fehlern umgehen können).

4.2. Zeitstempelbasierte Wiederherstellung der Dekodierungsreihenfolge

Sobald ein Empfänger die Komponenten eines geschichteten, Multi-Description- oder Multi-View-Stroms unter Verwendung der RTP-Header-Erweiterungen wie in Abschnitt 4.1 beschrieben synchronisiert hat, kann er wie folgt eine Dekodierungsreihenfolge basierend auf den synchronisierten Zeitstempeln ableiten (oder er kann die Informationen im RTP-Payload-Header verwenden, um die Dekodierungsreihenfolge abzuleiten, falls vorhanden und erwünscht).

Es kann explizite Abhängigkeiten zwischen den beteiligten Strömen eines geschichteten, Multi-Description- oder Multi-View-Stroms geben. Zum Beispiel ist es üblich, dass geschichtete Ströme in einer Hierarchie angeordnet sind, in der Ströme aus "höheren" Schichten erst dekodiert werden können, wenn die entsprechenden Daten in "niedrigeren" Schichten empfangen und dekodiert wurden. Falls eine solche Dekodierungshierarchie existiert, MUSS diese Out-of-Band signalisiert werden, zum Beispiel unter Verwendung von [RFC5583], wenn eine SDP-Signalisierung verwendet wird.

Jeder beteiligte RTP-Strom MUSS Pakete enthalten, die allen Abtastzeitpunkten der RTP-Ströme entsprechen, von denen er abhängt. Falls solche Pakete nicht von Natur aus im RTP-Strom vorhanden sind, MUSS der Sender nach Bedarf zusätzliche Pakete erzeugen, um diese Regel zu erfüllen. Das Format dieser Pakete hängt vom verwendeten Nutzlastformat ab. Für H.264 SVC sollte das Empty Network Abstraction Layer (NAL) Unit-Paket [AVT-RTP-SVC] verwendet werden. Ströme können auch Pakete enthalten, die zusätzlichen Abtastzeitpunkten entsprechen, die in den Strömen, von denen sie abhängen, nicht vorhanden sind.

Der Empfänger sollte die Pakete in allen beteiligten RTP-Strömen wie folgt dekodieren:

• Verwenden Sie für jedes RTP-Paket in jedem Strom die in den RTP-Header-Erweiterungen und RTCP SR-Paketen enthaltene Zuordnung, um den seinem RTP-Zeitstempel entsprechenden Zeitstempel im NTP-Format abzuleiten.

• Gruppieren Sie RTP-Datenpakete aus allen beteiligten Strömen, die identische berechnete Zeitstempel im NTP-Format haben.

• Verarbeiten Sie die Gruppen in der Reihenfolge aufsteigender NTP-Format-Zeitstempel und dekodieren Sie die RTP-Pakete in jeder Gruppe gemäß der signalisierten RTP-Strom-Dekodierungshierarchie. Das heißt, übergeben Sie zuerst die RTP-Paketdaten aus dem Strom, von dem alle anderen Ströme abhängen, an den Dekodierer, dann die aus dem nächsten abhängigen Strom und so weiter. Die Dekodierungsreihenfolge der RTP-Strom-Hierarchie kann durch in [RFC5583] definierte Mechanismen oder auf andere Weise angezeigt werden.

Beachten Sie, dass die Dekodierungsreihenfolge nicht notwendigerweise mit der Paketübertragungsreihenfolge übereinstimmen muss. Der Empfänger muss Pakete für eine vom Codec abhängige Zeitspanne puffern, damit alle erforderlichen Pakete eintreffen können, um die Dekodierung zu ermöglichen.

4.3. Beispiel

Das in Abbildung 7 gezeigte Beispiel bezieht sich auf drei RTP-Ströme A, B und C, die einen geschichteten, Multi-View- oder Multi-Description-Medienstrom enthalten. In dem Beispiel zeigt die Abhängigkeitssignalisierung gemäß [RFC5583] an, dass Strom A der unterste RTP-Strom ist. Strom B ist der nächsthöhere RTP-Strom und hängt von A ab. Strom C ist der höchste der drei RTP-Ströme und hängt sowohl von A als auch von B ab. Es wird eine Medienkodierungsstruktur verwendet, die dazu führt, dass Video-Access-Units (d. h. kodierte Video-Frames) in höheren Strömen vorhanden sind, aber nicht in allen niedrigeren Strömen. Strom A hat die niedrigste Bildrate. Die Ströme B und C haben die gleiche Bildrate, die höher ist als die von Strom A. Die Abbildung zeigt die vollständigen Video-Access-Units mit ihren entsprechenden RTP-Zeitstempeln "(x)". Die Video-Access-Units sind bereits gemäß ihrer RTP-Sequenznummernreihenfolge umgeordnet. Die Abbildung zeigt den empfangenen Teil der Video-Access-Unit in der Dekodierungsreihenfolge innerhalb jedes RTP-Stroms sowie die zugehörigen NTP-Medienzeitstempel ("TS[..]"). Wie in der Abbildung gezeigt, können diese Zeitstempel unter Verwendung des in den RTCP-Senderberichten bereitgestellten NTP-Format-Zeitstempels abgeleitet werden, wie durch den Zeitstempel in "{x}" angedeutet, oder direkt aus dem in den RTP-Header-Erweiterungen enthaltenen NTP-Zeitstempel abgeleitet werden, wie durch den Zeitstempel in "" angedeutet. Beachten Sie, dass die Zeitstempel nicht in aufsteigender Reihenfolge sind, da in diesem Beispiel die Dekodierungsreihenfolge von der Ausgabe-/Präsentationsreihenfolge abweicht.

Der Prozess zur Wiederherstellung der Dekodierungsreihenfolge rückt zuerst zu den Video-Access-Unit-Teilen vor, die mit dem ersten verfügbaren synchronen Einfügen des NTP-Zeitstempels in RTP-Header-Erweiterungen beim NTP-Medienzeitstempel TS=[8] verknüpft sind. Der Empfänger beginnt im höchsten RTP-Strom C und entfernt/ignoriert alle vorangehenden Video-Access-Unit-Teile (in Dekodierungsreihenfolge) bis hin zu den Video-Access-Unit-Teilen mit TS=[8] in jedem der De-Jittering-Puffer der RTP-Ströme A, B und C. Dann wird, beginnend mit Strom C, der erste in Dekodierungsreihenfolge verfügbare Medienzeitstempel (TS=[8]) ausgewählt, und Video-Access-Unit-Teile beginnend mit RTP-Strom A sowie die Ströme B und C werden in der Reihenfolge der RTP-Strom-Abhängigkeit angeordnet, wie durch in [RFC5583] definierte Mechanismen angezeigt (im Beispiel für TS[8]: zuerst Strom B und dann Strom C in die Video-Access-Unit AU(TS[8]), die mit dem NTP-Medienzeitstempel TS=[8] verknüpft ist). Dann wird der nächste Medienzeitstempel TS=[6] (RTP-Zeitstempel=(4)) in der Reihenfolge des Erscheinens im höchsten RTP-Strom C verarbeitet und der oben beschriebene Prozess wiederholt. Beachten Sie, dass es Video-Access-Units geben kann, in denen keine Video-Access-Unit-Teile vorhanden sind, z. B. im untersten RTP-Strom A (siehe z. B. TS=[5]). Der Prozess zur Wiederherstellung der Dekodierungsreihenfolge könnte auch gestartet werden, nachdem ein RTCP-Senderbericht empfangen wurde, der die Zuordnung zwischen dem RTP-Zeitstempel und dem Zeitstempel im NTP-Format enthält (angegeben als Zeitstempel "(x){y}"), vorausgesetzt, dass in der für die Erzeugung des Zeitstempels im NTP-Format verwendeten Quelle keine Taktabweichung (Clock Skew) vorliegt.

    C:-(0)----(2)----(7)<8>--(5)----(4)----(6)-----(11)----(9){10}-
       |      |      |       |      |      |       |       |
    B:-(3)----(5)---(10)<8>--(8)----(7)----(9){7}--(14)----(12)----
                     |       |                     |       |
    A:---------------(3)<8>--(1)-------------------(7){12}-(5)-----

    --------------------------------------Dekodier/Übertrag-Reihenfolg->
    TS:[1]    [3]    [8]=<8> [6]    [5]    [7]    [12]    [10]


    Legende:

    A, B, C                - RTP-Ströme

    Ganzzahlen in "()"     - Video-Access-Unit mit ihrem RTP-Zeitstempel,
                             wie in ihrem RTP-Paket angegeben.

    "|"                    - zeigt die entsprechenden Teile derselben
                             Video-Access-Unit AU(TS[..]) in den
                             RTP-Strömen an.

    Ganzzahlen in "[]"     - NTP-Medienzeitstempel TS, Abtastzeit abgeleitet
                             vom NTP-Zeitstempel, der mit der Video-Access-
                             Unit AU(TS[..]) verknüpft ist, bestehend aus
                             Video-Access-Unit-Teilen in den obigen Strömen.

    Ganzzahlen in "<>"     - NTP-Medienzeitstempel TS, wie er direkt
                             aus den NTP RTP Header-Erweiterungen
                             entnommen wurde.

    Ganzzahlen in "{}"     - NTP-Medienzeitstempel TS, wie er in den
                             RTCP-Senderberichten bereitgestellt wird.

                Abbildung 7: Beispiel für einen geschichteten RTP-Strom