6. Considérations spécifiques aux codecs (Codec-Specific Considerations)
Le SDP (Session Description Protocol) permet l'indication indépendante du codec des résolutions vidéo préférées en utilisant le mécanisme décrit dans [RFC6236]. Les points d'extrémité WebRTC peuvent envoyer un attribut "a=imageattr" pour indiquer la résolution (Resolution) maximale qu'ils souhaitent recevoir. Les expéditeurs devraient interpréter et honorer cet attribut en limitant la résolution encodée à la taille maximale indiquée, car le récepteur peut ne pas être capable de gérer des résolutions plus élevées.
De plus, les codecs peuvent inclure des moyens spécifiques au codec pour signaler les capacités maximales du récepteur en ce qui concerne la résolution, la fréquence d'images (Frame Rate) et le débit binaire (Bitrate).
Sauf indication contraire dans le SDP, les récepteurs de flux vidéo doivent être capables de décoder de la vidéo à une fréquence d'au moins 20 fps à une résolution d'au moins 320 pixels par 240 pixels. Ces valeurs sont sélectionnées sur la base des recommandations dans [HSUP1].
Les encodeurs (Encoder) sont encouragés à prendre en charge l'encodage de médias avec au moins la même résolution et les mêmes fréquences d'images citées ci-dessus.
6.1. VP8
Pour le codec VP8, défini dans [RFC6386], les points d'extrémité doivent prendre en charge les formats de charge utile (Payload Format) définis dans [RFC7741].
En plus du mécanisme [RFC6236], les encodeurs VP8 doivent limiter les flux qu'ils envoient pour se conformer aux valeurs indiquées par les récepteurs dans les attributs SDP max-fr et max-fs correspondants.
Sauf indication contraire, les implémentations qui utilisent VP8 doivent encoder et décoder les pixels avec un rapport d'aspect (Aspect Ratio) implicite de 1:1 (carré).
6.2. H.264
Pour le codec [H264], les points d'extrémité doivent prendre en charge les formats de charge utile définis dans [RFC6184]. De plus, ils doivent prendre en charge le profil Baseline contraint niveau 1.2 (Constrained Baseline Profile Level 1.2) et devraient prendre en charge le profil High contraint H.264 niveau 1.3 (Constrained High Profile Level 1.3).
Les implémentations du codec H.264 ont utilisé une grande variété de paramètres optionnels. Pour améliorer l'interopérabilité (Interoperability), les paramètres suivants sont spécifiés :
packetization-mode (mode de paquétisation) : Le mode de paquétisation 1 doit être pris en charge. D'autres modes peuvent être négociés et utilisés.
profile-level-id (identifiant de profil-niveau) : Les implémentations doivent inclure ce paramètre dans le SDP et doivent l'interpréter lors de sa réception.
max-mbps, max-smbps, max-fs, max-cpb, max-dpb et max-br :
Ces paramètres permettent à l'implémentation de spécifier qu'elle peut prendre en charge certaines fonctionnalités de H.264 à des taux et valeurs supérieurs à ceux signalés par leur niveau (défini avec profile-level-id). Les implémentations peuvent inclure ces paramètres dans leur SDP, mais elles devraient les interpréter lors de leur réception, leur permettant d'envoyer la vidéo de la plus haute qualité possible.
sprop-parameter-sets : H.264 permet d'envoyer les informations de séquence et d'image à la fois intrabande et hors bande. Les implémentations WebRTC doivent signaler ces informations en intrabande. Cela signifie que les implémentations WebRTC ne doivent pas inclure ce paramètre dans le SDP qu'elles génèrent.
Les codecs H.264 peuvent envoyer et doivent prendre en charge l'interprétation correcte des messages d'information d'amélioration supplémentaire (Supplemental Enhancement Information, SEI) "filler payload" et "full frame freeze". Les messages "full frame freeze" sont utilisés dans les MCU de commutation vidéo, pour assurer une image affichée décodée stable lors de la commutation entre divers flux d'entrée.
Lorsque l'utilisation de l'extension d'en-tête RTP d'orientation vidéo (CVO) n'est pas signalée dans le SDP, les implémentations H.264 peuvent envoyer et devraient prendre en charge l'interprétation correcte des messages SEI d'orientation d'affichage (Display Orientation SEI Messages).
Les implémentations peuvent envoyer et agir sur les messages "User data registered by Rec. ITU-T T.35" et "User data unregistered". Même si elles n'agissent pas sur eux, les implémentations doivent être préparées à recevoir de tels messages sans effets néfastes.
Sauf indication contraire, les implémentations qui utilisent H.264 doivent encoder et décoder les pixels avec un rapport d'aspect implicite de 1:1 (carré).