3. Motivation

Cette section discute de la motivation et de l'utilisation des différents messages de contrôle vidéo et média. Les messages de contrôle vidéo ont été discutés pendant longtemps, et un document d'exigences a été élaboré [Basso]. Ce document a expiré, cependant, nous citons des sections pertinentes pour fournir la motivation et les exigences.

3.1. Cas d'usage

Il existe un certain nombre d'utilisations possibles pour les messages de feedback proposés. Commençons par examiner les cas d'usage que Basso et al. [Basso] ont proposés. Certains des cas d'usage ont été reformulés et des commentaires ont été ajoutés.

1. Un mixeur vidéo RTP compose plusieurs sources vidéo codées en un seul flux vidéo codé. Chaque fois qu'une source vidéo est ajoutée, le mixeur RTP doit demander un point de rafraîchissement du décodeur à partir de la source vidéo, afin de démarrer une chaîne de prédiction non corrompue sur la zone spatiale de l'image mixte occupée par les données de la nouvelle source vidéo.

2. Un mixeur vidéo RTP reçoit plusieurs flux vidéo RTP codés de participants à la conférence et sélectionne dynamiquement l'un des flux à inclure dans son flux RTP de sortie. Au moment d'un changement de flux binaire (déterminé par des moyens tels que l'activation vocale ou l'interface utilisateur), le mixeur demande un point de rafraîchissement du décodeur à la source distante, afin d'éviter d'utiliser un contenu non lié comme données de référence pour la prédiction inter-image. Après avoir demandé le point de rafraîchissement du décodeur, le mixeur vidéo arrête la livraison du flux RTP actuel et surveille le flux RTP de la nouvelle source jusqu'à ce qu'il détecte des données appartenant au point de rafraîchissement du décodeur. À ce moment-là, le mixeur RTP commence à transférer le flux nouvellement sélectionné au(x) récepteur(s).

3. Une application doit signaler à l'encodeur distant que le compromis souhaité entre résolution temporelle et résolution spatiale a changé. Par exemple, un utilisateur peut préférer un taux de trame plus élevé et une qualité spatiale inférieure, et un autre utilisateur peut préférer l'inverse. Ce choix dépend également fortement du contenu. De nombreux systèmes de vidéoconférence actuels offrent dans l'interface utilisateur un mécanisme pour effectuer cette sélection, généralement sous la forme d'un curseur. Le mécanisme est utile dans les utilisations point à point, multipoint centralisé et multipoint non centralisé.

4. Le cas d'usage 4 du document Basso s'applique uniquement à Picture Loss Indication (PLI) tel que défini dans AVPF [RFC4585] et n'est pas reproduit ici.

5. Le cas d'usage 5 du document Basso concerne un mécanisme connu sous le nom de "freeze picture request". L'envoi de requêtes de gel d'image sur un canal RTCP avant non fiable a été identifié comme problématique. Par conséquent, aucune requête de gel d'image n'a été incluse dans ce mémo, et la discussion du cas d'usage n'est pas reproduite ici.

6. Un mixeur vidéo sélectionne dynamiquement l'un des flux vidéo reçus à envoyer aux participants et tente de fournir le débit binaire le plus élevé possible à tous les participants, tout en minimisant le trans-rating du flux. Une façon d'y parvenir consiste à configurer des sessions avec des points de terminaison en utilisant le débit binaire maximum accepté par chaque point de terminaison et accepté par la méthode d'admission d'appel utilisée par le mixeur. Au moyen de commandes qui réduisent le débit binaire maximal du flux média en dessous de ce qui a été négocié lors de la configuration de la session, le mixeur peut réduire le débit binaire maximum envoyé par les points de terminaison au plus bas de tous les débits binaires acceptés. Lorsque le débit binaire accepté le plus bas change en raison de points de terminaison qui rejoignent et quittent ou en raison de la congestion du réseau, le mixeur peut ajuster les limites auxquelles les points de terminaison peuvent envoyer leurs flux pour correspondre à la nouvelle valeur. Le mixeur demande ensuite un nouveau débit binaire maximum, qui est égal ou inférieur au débit binaire maximum négocié lors de la configuration de session pour un flux média spécifique, et le point de terminaison distant peut répondre avec le débit binaire réel qu'il peut supporter.

L'image que Basso et al. dressent couvre la plupart des applications que nous prévoyons. Cependant, nous aimerions étendre la liste avec deux cas d'usage supplémentaires:

7. Les algorithmes de contrôle de congestion actuellement déployés (AIMD et TCP Friendly Rate Control (TFRC) [RFC3448]) sondent pour une capacité supplémentaire disponible tant qu'il y a quelque chose à envoyer. Avec les algorithmes de contrôle de congestion utilisant la perte de paquets comme indication de congestion, ce sondage entraîne généralement une qualité média réduite (souvent à un point où la distorsion est suffisamment importante pour rendre le média inutilisable), en raison de la perte de paquets et du délai accru.

   Dans un certain nombre de scénarios de déploiement, en particulier cellulaires, le lien goulot d'étranglement est souvent le lien de dernier saut. Ce lien cellulaire dispose également couramment d'un certain type de négociation QoS permettant au dispositif cellulaire d'apprendre le débit binaire maximal disponible sur ce dernier saut. Un récepteur média derrière ce lien peut, dans la plupart (sinon tous) des cas, calculer au moins une borne supérieure pour le débit binaire disponible pour chaque flux média qu'il reçoit actuellement. La façon dont cela est fait est un détail d'implémentation et n'est pas discuté ici. Indiquer le débit binaire maximum disponible à la partie émettrice pour les différents flux média peut être bénéfique pour empêcher cette partie de sonder la bande passante pour ce flux au-delà d'une limite dure connue. Pour les dispositifs cellulaires ou autres dispositifs mobiles, le débit binaire disponible connu pour chaque flux (déduit du débit binaire du lien) peut changer rapidement, en raison d'un transfert vers une autre technologie de transmission, d'une renégociation QoS due à la congestion, etc. Pour permettre une perturbation minimale du service, une convergence rapide est nécessaire, et par conséquent, la signalisation du chemin média est souhaitable.

8. Habituellement, dans une session point à point, c'est la responsabilité de l'émetteur média de configurer le flux média pour rester dans les limites de la bande passante de chemin disponible. Cependant, dans certains scénarios vidéo point à point, il est avantageux de laisser le récepteur restreindre davantage le débit binaire média maximum. Un exemple est la dégradation de la capacité de rendu du récepteur (par exemple, en raison d'une pénurie de ressources CPU). Dans ce cas, le récepteur peut vouloir signaler à l'émetteur de réduire le débit binaire média à un niveau gérable. Un autre exemple est un récepteur qui souhaite enregistrer la session. Dans ce cas, le récepteur peut vouloir limiter le débit média pour ne pas dépasser les vitesses d'écriture fiables sur le dispositif de stockage.

3.2. Utilisation du chemin média

Pour supporter les cas d'usage ci-dessus, on peut utiliser le canal de signalisation (par exemple, SIP) et renégocier la définition des flux média. Cependant, cela présente plusieurs inconvénients.

D'une part, la renégociation des paramètres via le canal de signalisation peut être lente. Dans certains protocoles de contrôle (comme H.323), les phases de démontage d'un canal existant et de configuration d'un nouveau sont distinctes, et un "écart" dans la lecture des médias peut se produire.

Deuxièmement, le canal de contrôle utilise des protocoles différents (souvent TCP) du chemin média (souvent UDP/RTP). Dans de nombreuses topologies, le "chemin" du canal de signalisation est distinct du chemin des médias. Si une middlebox telle qu'un NAT-fw est présente, le canal de contrôle peut ne pas être en mesure de réagir aux changements dans les caractéristiques du chemin média, ou peut même ne pas être conscient du chemin média.

Troisièmement, l'utilisation du canal de signalisation pour renégocier les paramètres média est souvent lourde.

En conséquence, il est avantageux d'effectuer le contrôle des médias dans le chemin média, et d'une manière qui est légère, et donc rapide.

3.3. Utilisation d'AVPF

Pour les messages de feedback, nous utilisons le profil AVPF [RFC4585]. (Voir [RFC4585] pour la justification de l'utilisation de RTCP pour les messages de feedback.) AVPF fournit des types de paquets RTCP valides et des modes de fonctionnement pour transmettre les messages de feedback.

3.3.1. Fiabilité

AVPF ne fournit pas de fiabilité intégrée. Les paquets d'accusé de réception, la retransmission et d'autres mécanismes de fiabilité sont difficiles à implémenter et à utiliser avec le multicast.

Pour les messages définis dans ce document, nous avons choisi une conception qui repose sur l'émetteur du message de feedback pour surveiller le flux qu'il reçoit. Si le message de feedback a été perdu, ou si l'émetteur média n'a pas encore agi en conséquence, l'émetteur du message de feedback (par exemple, le récepteur média) ne verra pas la réaction attendue sous la forme d'un flux RTP modifié. Dans ce cas, l'émetteur du message de feedback devrait renvoyer le message. L'intervalle pour de telles retransmissions devrait respecter les règles de timing AVPF. Cependant, il y a certains messages qui ne nécessitent simplement pas de fiabilité (notifications), et pour d'autres, la fiabilité est résolue en répétant le message.

3.4. Multicast

Les messages de feedback définis dans ce document sont principalement destinés aux scénarios point à point et multipoint centralisés. Cependant, leur utilisation dans des scénarios multicast non centralisés n'est pas interdite. Mais, lors de l'utilisation des messages dans de tels scénarios, leurs effets doivent être bien compris.

En multicast, l'émetteur média envoie le même flux binaire à tous les récepteurs. Si un récepteur envoie une demande de débit binaire plus bas, ou pour une image intra, satisfaire cette demande affecte tous les autres récepteurs de la session. Cela peut ne pas être souhaitable.

De plus, AVPF exige que tous les paquets RTCP dans une session multicast soient envoyés à tous les participants. Cela signifie qu'un message de feedback envoyé par un récepteur est vu par tous les autres récepteurs. Cela peut provoquer une inondation de messages de feedback si de nombreux récepteurs envoient tous le même message en même temps. Les règles de timing AVPF sont conçues pour prévenir de telles inondations, mais elles ne sont pas parfaites.

3.5. Messages de feedback

Cette section fournit une description de haut niveau des messages de feedback définis dans cette spécification. La définition formelle des messages se trouve dans la section 4.

3.5.1. Full Intra Request Command

Une commande Full Intra Request (FIR) indique à l'émetteur média qu'il doit envoyer un point de rafraîchissement du décodeur (pour la vidéo, une image Intra) dès que possible. Les cas d'usage 1 et 2 de la section 3.1 sont les principaux moteurs de ce message.

Le message FIR est similaire au message Picture Loss Indication (PLI) défini dans [RFC4585]. Cependant, il y a une différence subtile. PLI est utilisé lorsque le récepteur a perdu des données et veut restaurer l'image. L'émetteur peut choisir d'envoyer une image Intra, ou il peut utiliser d'autres moyens pour restaurer l'image (par exemple, s'il sait quelles données le récepteur a, il peut envoyer des données de différence). FIR, en revanche, est une commande qui force l'émetteur à envoyer un point de rafraîchissement du décodeur. Cela est nécessaire lorsque le récepteur n'a aucune image de référence valide, par exemple, lors du changement de flux dans un mixeur.

3.5.1.1. Fiabilité

Le message FIR est une commande. S'il est perdu, la vidéo restera corrompue (ou vide). Par conséquent, l'émetteur du message FIR répète généralement le message jusqu'à ce qu'il voie un point de rafraîchissement du décodeur dans le flux reçu. Les règles de timing AVPF s'appliquent à ces répétitions.

3.5.2. Temporal-Spatial Trade-off Request and Notification

Les messages Temporal-Spatial Trade-off Request (TSTR) et Notification (TSTN) permettent à un récepteur média de signaler sa préférence pour le compromis entre résolution temporelle (taux de trame) et résolution spatiale (qualité d'image). Cela répond au cas d'usage 3.

Le compromis est exprimé comme une valeur entière de 0 à 31, où 0 représente la qualité spatiale la plus élevée (et potentiellement le taux de trame le plus bas) et 31 représente le taux de trame le plus élevé (et potentiellement la qualité spatiale la plus basse).

Le message TSTR est envoyé par un récepteur pour demander un compromis spécifique. Le message TSTN est envoyé par l'émetteur pour notifier les récepteurs du paramètre de compromis actuel, ou pour accuser réception d'un TSTR.

3.5.2.1. Point à point

Dans un scénario point à point, le récepteur envoie un TSTR. L'émetteur ajuste probablement son encodage et envoie un TSTN pour confirmer.

3.5.2.2. Point à multipoint utilisant multicast ou translators

Dans ces scénarios, plusieurs récepteurs peuvent envoyer des messages TSTR contradictoires. L'émetteur doit décider comment réagir. Il pourrait, par exemple, honorer la demande pour le taux de trame le plus élevé, ou la qualité spatiale la plus élevée, ou une moyenne. L'émetteur envoie ensuite un TSTN pour informer tous les récepteurs du paramètre réel.

3.5.2.3. Point à multipoint utilisant RTP Mixer

Un mixeur peut gérer les messages TSTR de plusieurs récepteurs et potentiellement générer différents flux pour différents récepteurs, ou agréger les demandes et envoyer un seul TSTR à l'émetteur d'origine.

3.5.2.4. Fiabilité

TSTR et TSTN sont des requêtes et des notifications. Si un TSTR est perdu, l'émetteur ne changera pas le compromis. Le récepteur peut détecter cela (en ne recevant pas de TSTN ou en voyant un changement dans le flux) et renvoyer le TSTR.

3.5.3. H.271 Video Back Channel Message

Ce message permet de transporter des messages de canal arrière vidéo ITU-T H.271 dans RTCP. Cela est utile pour les codecs vidéo établis qui utilisent H.271 pour le feedback.

3.5.3.1. Fiabilité

La fiabilité pour VBCM dépend de l'application. Certains messages H.271 peuvent nécessiter une fiabilité, tandis que d'autres non. Le mécanisme décrit dans ce document ne fournit pas de fiabilité au niveau RTCP; il appartient à l'application de gérer les retransmissions si nécessaire.

3.5.4. Temporary Maximum Media Stream Bit Rate Request and Notification

Les messages Temporary Maximum Media Stream Bit Rate Request (TMMBR, prononcé "timber") et Notification (TMMBN, prononcé "tim-ben") sont utilisés pour contrôler le débit binaire du flux média. Cela répond aux cas d'usage 6, 7 et 8.

TMMBR est une requête d'un récepteur à un émetteur pour limiter le débit binaire du flux média à une certaine valeur. TMMBN est une notification de l'émetteur au(x) récepteur(s) indiquant le débit binaire maximum que l'émetteur respecte actuellement.

3.5.4.1. Comportement pour les récepteurs média utilisant TMMBR

Un récepteur estime le débit binaire maximum qu'il peut gérer (par exemple, basé sur la capacité du lien) et envoie un message TMMBR contenant cette valeur.

3.5.4.2. Algorithme pour établir les limitations actuelles

Un émetteur peut recevoir des messages TMMBR de plusieurs récepteurs. Il doit calculer l'"ensemble de délimitation" de ces demandes. Fondamentalement, il doit trouver le débit binaire minimum demandé parmi tous les récepteurs (ou au moins l'ensemble des récepteurs qui l'intéressent) et limiter son taux d'envoi à cette valeur. L'algorithme décrit comment maintenir l'état des messages TMMBR reçus et calculer la limite actuelle.

3.5.4.3. Utilisation de TMMBR dans une opération multipoint basée sur un mixeur

Un mixeur agit comme un récepteur pour les points de terminaison qui lui envoient, et comme un émetteur pour les points de terminaison qui reçoivent de lui. Il peut utiliser TMMBR pour limiter le taux des flux entrants, et il doit respecter les messages TMMBR reçus des points de terminaison auxquels il envoie.

3.5.4.4. Utilisation de TMMBR en point à multipoint utilisant multicast ou translators

En multicast, l'émetteur doit respecter le débit binaire demandé le plus bas du groupe de récepteurs (ou utiliser une autre politique).

3.5.4.5. Utilisation de TMMBR en opération point à point

Cas simple: le récepteur demande une limite, l'émetteur la respecte.

3.5.4.6. Fiabilité

TMMBR est une requête. TMMBN est une notification qui sert d'accusé de réception. Si un récepteur envoie TMMBR et ne reçoit pas de TMMBN correspondant (ou ne voit pas de réduction de débit), il renvoie le TMMBR.