4. Application à la récupération de l'ordre de décodage dans les codecs en couches

Les paquets dans les flux RTP sont souvent codés de manière prédictive, le récepteur devant organiser les paquets dans un ordre particulier avant de pouvoir décoder les données média. Selon le format de la charge utile (payload), l'ordre de décodage peut être explicitement spécifié sous forme de champ dans l'en-tête de la charge utile RTP, ou le récepteur peut décoder les paquets dans l'ordre de leurs horodatages RTP. Si un codage en couches est utilisé, où les données média sont réparties sur plusieurs flux RTP, il est souvent nécessaire de synchroniser exactement les flux RTP comprenant les différentes couches avant que les couches autres que la couche de base puissent être décodées. Des exemples de tels codages en couches sont le H.264 SVC en mode NI-T [AVT-RTP-SVC] et l'audio multi-canal MPEG surround [RFC5691]. Comme décrit dans la section 2, une telle synchronisation est possible en RTP, mais peut être difficile à réaliser rapidement. Ci-dessous, nous décrivons comment les extensions définies dans la section 3.3 peuvent être utilisées pour synchroniser les flux en couches et fournir un ordre de décodage commun basé sur l'horodatage.

4.1. Synchronisation en bande pour la récupération de l'ordre de décodage

Lorsqu'un codec en couches, à descriptions multiples ou multi-vues est utilisé, les différentes composantes du média étant transférées sur des flux RTP séparés, l'émetteur RTP DEVRAIT utiliser une livraison en bande synchrone périodique de métadonnées de synchronisation pour permettre aux récepteurs de synchroniser rapidement et précisément les composantes séparées du flux média en couches. Il y a trois parties à cela :

• L'émetteur doit négocier l'utilisation des extensions d'en-tête RTP décrites dans la section 3.3 et doit périodiquement et de manière synchrone insérer de telles extensions d'en-tête dans tous les flux RTP formant les composantes séparées du flux en couches, à descriptions multiples ou multi-vues.

• L'insertion synchrone exige que l'émetteur insère ces extensions d'en-tête RTP dans les paquets correspondant exactement au même instant d'échantillonnage dans tous les flux. Étant donné que les extensions d'en-tête pour chaque flux sont insérées exactement au même instant d'échantillonnage, elles auront des horodatages au format NTP identiques, permettant ainsi aux récepteurs d'aligner précisément les horodatages RTP pour les flux composants. Cela peut nécessiter l'insertion de paquets de données supplémentaires dans certains des flux RTP composants, si certains flux composants contiennent des paquets pour des instants d'échantillonnage qui n'existent pas dans d'autres flux (par exemple, un codec vidéo en couches, où les couches ont des fréquences d'images différentes).

• La fréquence à laquelle l'émetteur insère les extensions d'en-tête correspondra directement à la latence de synchronisation, une insertion plus fréquente entraînant des surdébits par flux plus élevés, mais une latence de synchronisation plus faible. Il est RECOMMANDÉ que l'émetteur insère les extensions d'en-tête de manière synchrone dans tous les flux RTP composants au moins une fois par point d'accès aléatoire du média, mais elles PEUVENT être insérées plus souvent.

L'émetteur DOIT continuer à envoyer des rapports RTCP périodiques incluant des paquets SR, et DOIT s'assurer que la correspondance entre l'horodatage RTP et l'horodatage au format NTP dans les paquets RTCP SR est cohérente avec celle utilisée dans les extensions d'en-tête RTP. Les récepteurs doivent utiliser à la fois les informations contenues dans les paquets RTCP SR et la correspondance en bande des horodatages RTP et au format NTP comme entrées du processus de synchronisation, mais il est RECOMMANDÉ que les récepteurs vérifient la cohérence des correspondances reçues et rejettent les valeurs aberrantes (outliers), afin d'assurer une robustesse contre les données invalides (on pourrait penser qu'il est plus probable que les correspondances RTCP SR soient invalides, puisqu'elles sont envoyées à des moments irréguliers et sujettes au décalage, mais la présence de traducteurs RTP défaillants pourrait également corrompre les horodatages dans l'extension d'en-tête RTP ; les récepteurs doivent faire face aux deux types de défaillance).

4.2. Récupération de l'ordre de décodage basée sur l'horodatage

Une fois qu'un récepteur a synchronisé les composants d'un flux en couches, à descriptions multiples ou multi-vues à l'aide des extensions d'en-tête RTP comme décrit dans la section 4.1, il peut alors dériver un ordre de décodage basé sur les horodatages synchronisés comme suit (ou il peut utiliser les informations figurant dans l'en-tête de la charge utile RTP pour dériver l'ordre de décodage, si elles sont présentes et souhaitées).

Il peut y avoir des dépendances explicites entre les flux composants d'un flux en couches, à descriptions multiples ou multi-vues. Par exemple, il est courant que les flux en couches soient organisés en une hiérarchie, où les flux des couches "supérieures" ne peuvent pas être décodés tant que les données correspondantes dans les flux de couches "inférieures" n'ont pas été reçues et décodées. Si une telle hiérarchie de décodage existe, elle DOIT être signalée hors bande, par exemple en utilisant la [RFC5583] lorsque la signalisation SDP est utilisée.

Chaque flux RTP composant DOIT contenir des paquets correspondant à tous les instants d'échantillonnage des flux RTP dont il dépend. Si de tels paquets ne sont pas naturellement présents dans le flux RTP, l'émetteur DOIT générer des paquets supplémentaires si nécessaire afin de satisfaire à cette règle. Le format de ces paquets dépend du format de la charge utile utilisé. Pour le H.264 SVC, le paquet d'unité Empty Network Abstraction Layer (NAL) [AVT-RTP-SVC] doit être utilisé. Les flux peuvent également inclure des paquets correspondant à des instants d'échantillonnage supplémentaires qui ne sont pas présents dans les flux dont ils dépendent.

Le récepteur doit décoder les paquets dans tous les flux RTP composants comme suit :

• Pour chaque paquet RTP dans chaque flux, utiliser la correspondance contenue dans les extensions d'en-tête RTP et les paquets RTCP SR pour dériver l'horodatage au format NTP correspondant à son horodatage RTP.

• Regrouper les paquets de données RTP de tous les flux composants qui ont des horodatages au format NTP calculés identiques.

• En traitant les groupes par ordre croissant d'horodatages au format NTP, décoder les paquets RTP de chaque groupe selon la hiérarchie de décodage des flux RTP signalée. C'est-à-dire, transmettre d'abord au décodeur les données du paquet RTP du flux dont tous les autres flux dépendent, puis celles du flux dépendant suivant, et ainsi de suite. L'ordre de décodage de la hiérarchie des flux RTP peut être indiqué par des mécanismes définis dans la [RFC5583] ou par d'autres moyens.

Notez que l'ordre de décodage ne correspondra pas nécessairement à l'ordre de transmission des paquets. Le récepteur devra mettre les paquets en mémoire tampon pendant une durée dépendant du codec afin que tous les paquets nécessaires arrivent pour permettre le décodage.

4.3. Exemple

L'exemple présenté dans la figure 7 fait référence à trois flux RTP A, B et C, contenant un flux média en couches, multi-vues ou à descriptions multiples. Dans l'exemple, la signalisation de dépendance telle que définie dans la [RFC5583] indique que le flux A est le flux RTP le plus bas. Le flux B est le flux RTP de niveau immédiatement supérieur et dépend de A. Le flux C est le plus élevé des trois flux RTP et dépend à la fois de A et de B. Une structure de codage média est utilisée, ce qui se traduit par des unités d'accès vidéo (c'est-à-dire des trames vidéo codées) présentes dans les flux supérieurs, mais pas dans tous les flux inférieurs. Le flux A a la fréquence d'images la plus basse. Les flux B et C ont la même fréquence d'images, qui est supérieure à celle du flux A. La figure montre les unités d'accès vidéo complètes avec leurs horodatages RTP correspondants "(x)". Les unités d'accès vidéo sont déjà réordonnées selon leur ordre de numéro de séquence RTP. La figure indique la partie de l'unité d'accès vidéo reçue dans l'ordre de décodage au sein de chaque flux RTP, ainsi que les horodatages média NTP associés ("TS[..]"). Comme le montre la figure, ces horodatages peuvent être dérivés à l'aide de l'horodatage au format NTP fourni dans les rapports d'émetteur RTCP tel qu'indiqué par l'horodatage entre accolades "{x}", ou dérivés directement de l'horodatage NTP contenu dans les extensions d'en-tête RTP tel qu'indiqué par l'horodatage entre chevrons "". Notez que les horodatages ne sont pas par ordre croissant car, dans cet exemple, l'ordre de décodage est différent de l'ordre de sortie/présentation.

Le processus de récupération de l'ordre de décodage avance d'abord jusqu'aux parties de l'unité d'accès vidéo associées à la première insertion synchrone disponible de l'horodatage NTP dans les extensions d'en-tête RTP à l'horodatage média NTP TS=[8]. Le récepteur commence dans le flux RTP C le plus élevé et supprime/ignore toutes les parties de l'unité d'accès vidéo précédentes (dans l'ordre de décodage) par rapport aux parties de l'unité d'accès vidéo avec TS=[8] in chacune des tampons de dé-gigue des flux RTP A, B et C. Ensuite, en commençant par le flux C, le premier horodatage média disponible dans l'ordre de décodage (TS=[8]) est sélectionné, et les parties de l'unité d'accès vidéo provenant du flux RTP A, et des flux B et C sont placées dans l'ordre de la dépendance du flux RTP tel qu'indiqué par les mécanismes définis dans l' [RFC5583] (dans l'exemple pour TS[8] : d'abord le flux B puis le flux C dans l'unité d'accès vidéo AU(TS[8]) associée à l'horodatage média NTP TS=[8]). Ensuite, l'horodatage média suivant TS=[6] (horodatage RTP=(4)) dans l'ordre d'apparition dans le flux RTP C le plus élevé est traité, et le processus décrit ci-dessus est répété. Notez qu'il peut y avoir des unités d'accès vidéo sans parties d'unité d'accès vidéo présentes, par exemple, dans le flux RTP A le plus bas (voir, par exemple, TS=[5]). Le processus de récupération de l'ordre de décodage peut également être lancé après qu'un rapport d'émetteur RTCP contenant la correspondance entre l'horodatage RTP et l'horodatage au format NTP (indiqué comme horodatages "(x){y}") a été reçu, en assumant qu'il n'y ait pas de décalage d'horloge dans la source utilisée pour la génération de l'horodatage au format NTP.

    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)-----

    --------------------------------------ordre décodage/transmission->
    TS:[1]    [3]    [8]=<8> [6]    [5]    [7]    [12]    [10]


    Légende :

    A, B, C                - flux RTP

    Valeurs entières en "()" - unité d'accès vidéo avec son horodatage RTP
                             tel qu'indiqué dans son paquet RTP.

    "|"                    - indique les parties correspondantes de la même
                             unité d'accès vidéo AU(TS[..]) dans les
                             flux RTP.

    Valeurs entières en "[]" - horodatage média NTP TS, temps
                             d'échantillonnage tel que dérivé de
                             l'horodatage NTP associé à l'unité
                             d'accès vidéo AU(TS[..]), constituée de
                             parties d'unité d'accès vidéo dans les flux
                             ci-dessus.

    Valeurs entières en "<>" - horodatage média NTP TS tel que tiré
                             directement des extensions d'en-tête RTP NTP.

    Valeurs entières en "{}" - horodatage média NTP TS tel que fourni dans
                             les rapports d'émetteur RTCP.

                  Figure 7 : Exemple d'un flux RTP en couches