8.4. Parameter Set Considerations (Considérations sur les jeux de paramètres)

8.4. Parameter Set Considerations (Considérations sur les jeux de paramètres)

Les jeux de paramètres H.264 sont une partie fondamentale du codec vidéo et vitaux pour son fonctionnement (voir la section 1.2). En raison de leurs caractéristiques et de leur importance pour le processus de décodage, les jeux de paramètres perdus ou transmis par erreur peuvent difficilement être dissimulés localement au récepteur. Une référence à un jeu de paramètres corrompu a normalement des conséquences fatales pour le décodage. La corruption peut survenir, par exemple, en raison de la transmission erronée ou de la perte d'une unité NAL de jeu de paramètres, mais aussi en raison de la transmission intempestive d'une mise à jour de jeu de paramètres. Une mise à jour de jeu de paramètres désigne un changement d'au moins un paramètre dans un jeu de paramètres d'image ou de séquence pour lequel l'identifiant du jeu de paramètres d'image ou de séquence reste inchangé. Par conséquent, les recommandations suivantes sont fournies comme guide pour l'implémenteur de l'émetteur RTP.

Les NALU de jeux de paramètres peuvent être transportés selon trois principes différents :

A. À l'aide d'un protocole de contrôle de session (hors bande) avant la session RTP réelle.

B. À l'aide d'un protocole de contrôle de session (hors bande) pendant une session RTP en cours.

C. Dans le flux de paquets RTP dans la charge utile (en bande) pendant une session RTP en cours.

Il est recommandé d'implémenter les principes A et B dans un protocole de contrôle de session. SIP et SDP peuvent être utilisés comme décrit dans le modèle SDP Offer/Answer et dans les sections précédentes de ce mémo. La section 8.2.2 contient une discussion détaillée sur le transport en bande ou hors bande des jeux de paramètres dans SDP Offer/Answer à l'aide des paramètres de type média sprop-parameter-sets, sprop-level-parameter-sets, use-level-src-parameter-sets et in-band-parameter-sets. Cette section contient des lignes directrices sur la manière dont les principes A et B doivent être implémentés dans les protocoles de contrôle de session. Elle est indépendante du protocole particulier utilisé. Le principe C est pris en charge par le format de charge utile RTP défini dans cette spécification. Il existe des topologies comme Topo-Video-switch-MCU [29] pour lesquelles l'utilisation du principe C peut être souhaitable.

Si la signalisation en bande des jeux de paramètres est utilisée, les NALU de jeux de paramètres d'image et de séquence DEVRAIENT être transmis dans la charge utile RTP en utilisant une méthode fiable de livraison RTP (voir ci-dessous), car la perte d'un jeu de paramètres de l'un ou l'autre type empêchera probablement le décodage d'une portion considérable du flux de paquets RTP correspondant.

Si la signalisation en bande des jeux de paramètres est utilisée, l'émetteur DEVRAIT tenir compte des caractéristiques d'erreur et utiliser des mécanismes pour fournir une forte probabilité de livraison correcte des jeux de paramètres. Les mécanismes qui augmentent la probabilité d'une réception correcte incluent la répétition de paquets, le FEC et la retransmission. L'utilisation d'un protocole de contrôle hors bande non fiable présente des inconvénients similaires à la signalisation en bande (perte possible) et peut en outre entraîner des difficultés de synchronisation (voir ci-dessous). Par conséquent, ce n'est PAS RECOMMANDÉ.

Les jeux de paramètres PEUVENT être ajoutés ou mis à jour pendant la durée de vie d'une session en utilisant les principes B et C. Il est exigé que les jeux de paramètres soient présents au décodeur avant les unités NAL qui y font référence. La mise à jour ou l'ajout de jeux de paramètres peut entraîner d'autres problèmes ; par conséquent, les recommandations suivantes DEVRAIENT être prises en compte.

• Lorsque des jeux de paramètres sont ajoutés ou mis à jour, il convient de veiller à ce que tout jeu de paramètres soit livré avant son utilisation. Lorsque de nouveaux jeux de paramètres sont ajoutés, des identifiants de jeu de paramètres auparavant inutilisés sont employés. Il est courant qu'aucune synchronisation n'existe entre la signalisation hors bande et le trafic en bande. Si la signalisation hors bande est utilisée, il est RECOMMANDÉ qu'un émetteur ne commence pas à envoyer des NALU nécessitant les jeux de paramètres ajoutés ou mis à jour avant l'accusé de réception de la livraison par le protocole de signalisation.

• Lorsque des jeux de paramètres sont mis à jour, le problème de synchronisation suivant DEVRAIT être pris en compte. Lors de l'écrasement d'un jeu de paramètres au récepteur, l'émetteur doit s'assurer que le jeu de paramètres en question n'est requis par aucun NALU présent dans les tampons réseau ou récepteur. Sinon, un décodage avec un mauvais jeu de paramètres peut survenir. Pour atténuer ce problème, il est RECOMMANDÉ soit d'écraser uniquement les jeux de paramètres qui n'ont pas été utilisés depuis suffisamment longtemps (pour s'assurer que tous les NALU associés ont été consommés), soit d'ajouter un nouveau jeu de paramètres à la place (ce qui peut avoir des conséquences négatives sur l'efficacité du codage vidéo).

Note informative : Dans certaines topologies comme Topo-Video-switch-MCU [29], l'origine de l'ensemble des jeux de paramètres peut provenir de plusieurs sources pouvant utiliser des identifiants de jeux de paramètres non uniques. Dans ce cas, une offre peut écraser un jeu de paramètres existant si aucun autre mécanisme garantissant l'unicité des jeux de paramètres dans le canal hors bande n'existe.

• Dans une session multipartite, un participant DOIT associer les jeux de paramètres provenant de différentes sources à l'identification de la source chaque fois que possible, par exemple en transportant hors bande les jeux de paramètres, car différentes sources utilisent typiquement des espaces de valeurs d'identifiants de jeux de paramètres indépendants.

• Ajouter ou modifier des jeux de paramètres en utilisant à la fois les principes B et C dans la même session RTP peut conduire à des incohérences des jeux de paramètres en raison du manque de synchronisation entre le canal de contrôle et le canal RTP. Par conséquent, les principes B et C NE DOIVENT PAS tous deux être utilisés dans la même session à moins qu'une synchronisation suffisante puisse être fournie.

Dans certains scénarios (par exemple, lorsque seul le sous-ensemble de cette spécification de format de charge utile correspondant à H.241 est utilisé) ou topologies, il n'est pas possible d'employer la transmission hors bande des jeux de paramètres. Dans ce cas, les jeux de paramètres doivent être transmis en bande. Ici, la synchronisation avec les données hors jeu de paramètres dans le bitstream est implicite, mais la possibilité d'une perte doit être prise en compte.

La probabilité de perte DEVRAIT être réduite en utilisant les mécanismes discutés ci-dessus. En cas de détection de perte d'un jeu de paramètres, la récupération peut être obtenue à l'aide d'une procédure de point de rafraîchissement du décodeur, par exemple en utilisant le retour RTCP Full Intra Request (FIR) [30]. Deux exemples de procédures de point de rafraîchissement du décodeur sont fournis dans la section informative 8.5.

• Lorsque les jeux de paramètres sont initialement fournis en utilisant le principe A puis ajoutés ou mis à jour en bande (principe C) plus tard, un risque est associé à la mise à jour des jeux de paramètres livrés hors bande. Si les récepteurs manquent certaines mises à jour en bande (par exemple en raison d'une perte ou d'une arrivée tardive), ces récepteurs tentent de décoder le bitstream en utilisant des paramètres obsolètes. Il est donc RECOMMANDÉ que les ID de jeux de paramètres soient partitionnés entre les jeux de paramètres hors bande et en bande.