8.1. Media Type Registration (Enregistrement du type de média)

8.1. Media Type Registration (Enregistrement du type de média)

Le sous-type de média pour le codec ITU-T H.264 | ISO/IEC 14496-10 a été alloué dans l'arbre IETF.

Nom du type de média (Media Type name): video

Nom du sous-type de média (Media subtype name): H264

Paramètres requis (Required parameters): aucun

Paramètres OPTIONNELS:

profile-level-id: Représentation base16 [7] (hexadécimale) des trois octets suivants dans la NALU du sequence parameter set selon [1]: 1) profile_idc, 2) un octet appelé ici profile-iop, composé des valeurs de constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag et reserved_zero_2bits dans l'ordre de signification des bits, en commençant par le bit de poids le plus fort, et 3) level_idc. Dans [1], reserved_zero_2bits doit valoir 0, mais ITU-T ou ISO/IEC peuvent spécifier d'autres valeurs à l'avenir.

Le paramètre profile-level-id indique le sous-profil par défaut (c'est-à-dire le sous-ensemble d'outils de codage pouvant avoir servi à générer le flux ou pris en charge par le récepteur) et le niveau par défaut du flux ou pris en charge par le récepteur.

Le sous-profil par défaut est indiqué conjointement par l'octet profile_idc et des champs dans l'octet profile-iop. Selon les valeurs des champs de profile-iop, le sous-profil par défaut peut être l'ensemble d'outils d'un profil ou une intersection commune de plusieurs profils, comme spécifié à la section 7.4.2.1.1 de [1]. Le niveau par défaut est indiqué par l'octet level_idc et, lorsque profile_idc vaut 66, 77 ou 88 (profils Baseline, Main ou Extended) et level_idc vaut 11, également par le bit 4 (constraint_set3_flag) de profile-iop. Lorsque profile_idc vaut 66, 77 ou 88, que level_idc vaut 11 et que le bit 4 (constraint_set3_flag) de profile-iop vaut 1, le niveau par défaut est le niveau 1b.

Le tableau 5 liste tous les profils définis dans l'annexe A de [1] et, pour chacun, les combinaisons possibles de profile_idc et profile-iop représentant le même sous-profil.

Tableau 5. Combinaisons de profile_idc et profile-iop représentant le même sous-profil correspondant à l'ensemble complet d'outils de codage pris en charge par un profil. Ci-dessous, x peut être 0 ou 1; noms de profils: CB: Constrained Baseline, B: Baseline, M: Main, E: Extended, H: High, H10: High 10, H42: High 4:2:2, H44: High 4:4:4 Predictive, H10I: High 10 Intra, H42I: High 4:2:2 Intra, H44I: High 4:4:4 Intra, C44I: CAVLC 4:4:4 Intra.

Profile	profile_idc (hexadezimal)	profile-iop (binaire)
CB	42 (B)	x1xx0000
same as	4D (M)	1xxx0000
same as	58 (E)	11xx0000
B	42 (B)	x0xx0000
same as	58 (E)	10xx0000
M	4D (M)	0x0x0000
E	58	00xx0000
H	64	00000000
H10	6E	00000000
H42	7A	00000000
H44	F4	00000000
H10I	6E	00010000
H42I	7A	00010000
H44I	F4	00010000
C44I	2C	00010000

Exemple: dans le tableau ci-dessus, profile_idc égal à 58 (Extended) avec profile-iop égal à 11xx0000 indique le même sous-profil que profile_idc égal à 42 (Baseline) avec profile-iop égal à x1xx0000. D'autres combinaisons de profile_idc et profile-iop (non listées dans le tableau 5) peuvent représenter un sous-profil équivalent à l'intersection d'outils de plusieurs profils. Un décodeur conforme à un profil donné peut parfois décoder des flux d'autres profils.

Si profile-level-id indique les propriétés d'un flux de NALU, le sous-ensemble minimal d'outils à prendre en charge pour décoder le flux est le sous-profil par défaut, et le niveau le plus bas à prendre en charge est le niveau par défaut.

Si profile-level-id sert à l'échange de capacités ou à l'établissement de session, il indique le sous-ensemble d'outils égal au sous-profil par défaut que le codec prend en charge en réception et en émission. Sans max-recv-level, le niveau par défaut issu de profile-level-id est le plus haut niveau que le codec souhaite prendre en charge. Avec max-recv-level, il s'agit du plus haut niveau de réception. Pour la réception comme pour l'émission, tous les niveaux inférieurs au plus haut niveau pris en charge DOIVENT aussi être pris en charge.

Note informative: Les procédures d'échange de capacités et d'établissement de session devraient permettre de lister séparément les capacités pour chaque sous-profil. Par exemple, la sélection one-of-N du modèle SDP Offer/Answer (section 10.2 de [8]) peut être utilisée, ainsi que pour fournir différentes combinaisons profile_idc / profile-iop équivalentes. Avec de nombreuses combinaisons équivalentes, le message SDP peut devenir volumineux; un récepteur devrait les comprendre et accepter une offre utilisant l'une quelconque d'entre elles.

Sans profile-level-id, le profil Baseline sans contrainte supplémentaire au niveau 1 DOIT être déduit.

max-recv-level: ce paramètre PEUT indiquer le plus haut niveau pris en charge par le récepteur lorsqu'il est supérieur au niveau par défaut (profile-level-id). La valeur est une représentation base16 des deux octets suivant profile_idc dans la NALU SPS selon [1]: profile-iop (comme ci-dessus) et level_idc. Si l'octet level_idc de max-recv-level vaut 11 et le bit 4 de profile-iop de max-recv-level vaut 1, ou si level_idc vaut 9 et le bit 4 de profile-iop vaut 0, le plus haut niveau est le niveau 1b. Sinon il vaut l'octet level_idc de max-recv-level divisé par 10.

max-recv-level NE DOIT PAS être présent si le plus haut niveau pris en charge par le récepteur n'est pas supérieur au niveau par défaut.

max-mbps, max-smbps, max-fs, max-cpb, max-dpb et max-br: ces paramètres PEUVENT signaler les capacités d'une implémentation réceptrice. Ils NE DOIVENT PAS servir à d'autres fins. Le plus haut niveau exprimé dans profile-level-id ou max-recv-level DOIT être tel que le récepteur puisse le prendre entièrement en charge. Ces paramètres PEUVENT étendre les capacités au-delà du plus haut niveau signalisé, comme spécifié ci-dessous.

Si plus d'un paramètre parmi (max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br) est présent, le récepteur DOIT prendre en charge simultanément toutes les capacités signalisées. Exemple: si max-mbps et max-br sont présents, le plus haut niveau signalisé avec extensions de cadence et de débit est pris en charge; le récepteur peut décoder des flux NALU où le débit de macroblocs est jusqu'à max-mbps, le débit jusqu'à max-br, la taille CPB dérivée comme dans la sémantique de max-br ci-dessous, et les autres propriétés conformes au plus haut niveau de profile-level-id ou max-recv-level.

Si un récepteur peut prendre en charge toutes les propriétés du niveau A, le plus haut niveau dans profile-level-id ou max-recv-level DOIT être le niveau A (c'est-à-dire pas inférieur). En d'autres termes, un récepteur NE DOIT PAS signaliser des valeurs de max-mbps, max-fs, max-cpb, max-dpb et max-br qui, ensemble, satisfont un niveau supérieur au plus haut niveau indiqué.

Note informative: lorsque les paramètres OPTIONNELS du type de média décrivent seulement les propriétés du flux NALU, max-mbps, max-smbps, max-fs, max-cpb, max-dpb et max-br sont absents, et profile-level-id doit toujours être tel que le flux respecte entièrement le profil et le niveau.

max-mbps: entier indiquant le débit maximal de traitement des macroblocs en macroblocs par seconde. Indique que le récepteur peut décoder plus vite que l'exigé par le plus haut niveau signalisé.

Si max-mbps est signalisé, le récepteur DOIT pouvoir décoder des flux NALU conformes au plus haut niveau signalisé, sauf que MaxMBPS du tableau A-1 de [1] est remplacé par max-mbps. max-mbps DOIT être ≥ MaxMBPS du tableau A-1 pour le plus haut niveau. Les expéditeurs PEUVENT envoyer des images à cadence plus élevée.

max-smbps: débit maximal de macroblocs statiques (hypothèse: tous les macroblocs statiques). Lorsqu'il est signalisé, MaxMBPS du tableau A-1 de [1] devrait être remplacé par le calcul suivant:

• Si max-mbps est signalisé, MaxMacroblocksPerSecond = max-mbps. Sinon, MaxMBPS du tableau A-1 [1] pour le plus haut niveau signalisé de profile-level-id ou max-recv-level.

• P_non-static: proportion de macroblocs non statiques dans l'image n.

• P_static: proportion de macroblocs statiques dans l'image n.

• L'encodeur devrait considérer MaxMBPS du tableau A-1 de [1] comme égal à:

MaxMacroblocksPerSecond * max-smbps / (P_non-static * max-smbps + P_static * MaxMacroblocksPerSecond)

L'encodeur devrait recalculer pour chaque image. max-smbps DOIT être ≥ la valeur explicite de max-mbps ou MaxMBPS implicite du tableau A-1 pour le plus haut niveau signalisé.

max-fs: taille d'image maximale en macroblocs. Indique des images plus grandes que requis par le niveau. Si signalisé, le récepteur DOIT pouvoir décoder avec MaxFS du tableau A-1 remplacé par max-fs. max-fs DOIT être ≥ MaxFS du tableau A-1. Les expéditeurs PEUVENT envoyer des images plus grandes à cadence plus basse.

max-cpb: taille maximale du tampon d'image codée en unités de 1000 bits (VCL HRD) et 1200 bits (NAL HRD). N'utilise pas directement cpbBrVclFactor et cpbBrNALFactor (tableau A-1 [1]). Indique plus de mémoire CPB que le minimum. Si signalisé, MaxCPB du tableau A-1 est remplacé par max-cpb (en tenant compte des facteurs si besoin). La valeur DOIT être ≥ MaxCPB du tableau A-1.

Note informative: le coded picture buffer est utilisé dans le décodeur de référence hypothétique (annexe C de H.264). L'usage du HRD est recommandé dans les encodeurs H.264 pour vérifier la conformité du flux et contrôler le débit. Le coded picture buffer est conceptuellement indépendant des autres tampons de réception, y compris désentrelacement et déjitterage. Il n'a pas besoin d'être implémenté comme en annexe C; les décodeurs conformes peuvent avoir toute organisation de tampons tant qu'ils décodent des flux conformes. En pratique, le tampon d'entrée du décodeur vidéo peut être intégré aux tampons de désentrelacement et déjitterage.

max-dpb: taille maximale du decoded picture buffer en unités de 8/3 macroblocs. Si signalisé, MaxDpbMbs du tableau A-1 est remplacé par max-dpb * 3 / 8. Capacité de stockage pour images décodées, paires de champs complémentaires et champs non appariés:

Min(max-dpb * 3 / 8 / (PicWidthInMbs * FrameHeightInMbs), 16)

PicWidthInMbs et FrameHeightInMbs selon [1]. max-dpb DOIT être ≥ MaxDpbMbs * 3 / 8 du tableau A-1.

Note informative: complète un point de code similaire dans ITU-T H.245; pas de relation directe avec les tampons RTP.

Note informative: dans RFC 3984 l'unité était 1024 octets; ici 8/3 macroblocs à cause de H.264 2010 et du tableau A-1.

max-br: débit vidéo maximal en 1000 bit/s (VCL HRD) et 1200 bit/s (NAL HRD). Remplace MaxBR du tableau A-1; sans max-cpb, MaxCPB est remplacé par (MaxCPB du niveau signalisé) * max-br / (MaxBR du plus haut niveau). Exemple Main niveau 1.2 avec max-br=1550: 1550 kbit/s VCL, 1860 kbit/s NAL, CPB 4036458 bits. max-br DOIT être ≥ MaxBR du tableau A-1.

Note informative: on ne peut pas en déduire que le réseau supporte ces débits ni sous contraintes de contrôle de congestion.

redundant-pic-cap: capacité réceptrice. 0: pas d'utilisation d'images codées redondantes; l'expéditeur DEVRAIT éviter les slices redondantes. 1: peut décoder des slices redondantes; l'expéditeur PEUT en envoyer. Absent: valeur 0. Présent: 0 ou 1 uniquement.

Si profile-level-id est dans la même signalisation et interdit les images redondantes (ex. Main), redundant-pic-cap DOIT être 0. Avec 0, le flux reçu NE DEVRAIT PAS contenir d'images codées redondantes.

Note informative: même à 0, le décodeur peut ignorer les images redondantes si le profil les autorise.

Note informative: même à 1, d'autres stratégies de dissimulation d'erreurs sont possibles.

sprop-parameter-sets: PEUT transporter les NALU SPS/PPS initiales précédant toute autre NALU en ordre de décodage. NE DOIT PAS indiquer la capacité du codec. Valeur: liste séparée par virgules en base64 [7] selon 7.3.2.1 et 7.3.2.2 de [1].

Note informative: avec plusieurs types de charge utile, le récepteur devrait mettre en tampon tous les sprop-parameter-sets.

Uniquement des jeux de paramètres conformes à profile-level-id; le sous-ensemble d'outils et le niveau doivent correspondre au sous-profil et au niveau par défaut.

sprop-level-parameter-sets: comme ci-dessus pour des niveaux différents du niveau par défaut. Jeux regroupés avec préfixe PLId sur trois octets (même syntaxe que profile-level-id); PSL comme sprop-parameter-sets. Forme PLId:PSL, paires séparées par :; dans un PSL, plusieurs jeux séparés par ,.

Chaque PLId: même sous-profil par défaut, niveau ≠ niveau par défaut. Toutes les SPS dans chaque PSL: octets de profile_idc à level_idc égaux au PLId précédent.

Note informative: permet un changement de niveau efficace en Offer/Answer avec transport hors bande.

use-level-src-parameter-sets: capacité réceptrice, 0 ou 1; absent → 0. 0: ne comprend pas sprop-level-parameter-sets ni l'attribut source fmtp [9] §6.3, les ignore. 1: comprend et peut utiliser les jeux de ces mécanismes.

Note informative: un récepteur RFC 3984 ignore ces extensions; si le niveau accepté est inférieur sans use-level-src-parameter-sets=1, le transport in-band est nécessaire.

in-band-parameter-sets: 1: le récepteur rejette les jeux hors bande dans sprop-parameter-sets et sprop-level-parameter-sets; l'expéditeur DOIT tout envoyer in-band. 0: utilise les jeux hors bande; l'expéditeur PEUT quand même envoyer in-band. Avec 1, use-level-src-parameter-sets NE DOIT PAS être présent ou doit valoir 0. Absent: capacité non spécifiée.

level-asymmetry-allowed: Offer/Answer, asymétrie de niveau entre directions? 0 ou 1; absent → 0. Les deux à 1: asymétrie permise. 0 dans l'un ou l'autre: asymétrie interdite; même niveau dans les deux sens.

packetization-mode: propriétés d'un type de charge utile RTP ou capacité réceptrice. Un seul point de configuration; plusieurs modes → plusieurs types de charge utile.

0 ou absent: mode single NAL (notamment H.241 [3], section 12.1). 1: non entrelacé. 2: entrelacé. La valeur DOIT être un entier 0 à 2.

sprop-interleaving-depth: NE DOIT PAS être absent si mode 2; NE DOIT PAS être présent si mode 0 ou 1. Nombre maximal de NALU VCL en ordre d'émission précédant une NALU VCL qui les suit en ordre de décodage. Taille de tampon ≥ sprop-interleaving-depth + 1 NALU VCL. Valeur 0–32767.

sprop-deint-buf-req: présence obligatoire en mode 2 comme ci-dessus. Taille requise du tampon de désentrelacement en octets ≥ section 7.2. Valeur 0–4294967295.

Note informative: concerne uniquement le tampon de désentrelacement; prévoir aussi un tampon de gigue réseau.

deint-buf-cap: capacité de tampon de désentrelacement du récepteur en octets. Absent → 0. 0–4294967295.

Note informative: taille maximale possible du tampon de désentrelacement du récepteur uniquement.

sprop-init-buf-time: PEUT décrire les propriétés du flux; NE DOIT PAS être présent si packetization-mode vaut 0 ou 1.

Indique le temps de tamponnage initial que le récepteur DOIT attendre avant de commencer le décodage pour rétablir l'ordre de décodage NAL à partir de l'ordre d'émission. C'est le maximum de (temps de décodage de la NALU − temps de transmission d'une NALU), en supposant transmission fiable et instantanée, même échelle de temps pour émission et décodage, et démarrage du décodage à l'arrivée du premier paquet.

Exemple pour sprop-init-buf-time: flux NALU envoyé dans l'ordre entrelacé suivant; la valeur correspond au temps de décodage, l'ordre d'émission est de gauche à droite:

0 2 1 3 5 4 6 8 7 ...

À débit NALU constant, les temps de transmission:

0 1 2 3 4 5 6 7 8 ...

Colonne par colonne, transmission moins décodage donne:

0 -1 1 0 -1 1 0 -1 1 ...

En unités d'intervalles de transmission NAL, sprop-init-buf-time vaut donc 1 dans cet exemple. Codé en entier base10 non négatif en tops d'horloge 90 kHz. Absent: pas de valeur de tamponnage initial. Sinon la valeur DOIT être 0–4294967295.

Outre sprop-init-buf-time, les récepteurs DEVRAIENT tenir compte du tampon de gigue de transmission (mixers, traducteurs, passerelles, proxies, façonneurs de trafic, etc.).

sprop-max-don-diff: propriétés du flux; pas pour capacité expéditeur/récepteur/codec; absent en mode 0/1. 0–32767; absent: valeur non spécifiée. Calcul:

sprop-max-don-diff = max{AbsDON(i) - AbsDON(j)}, for any i and any j>i,

where i and j indicate the index of the NAL unit in the transmission order and AbsDON denotes a decoding order number of the NAL unit that does not wrap around to 0 after 65535.  In other words, AbsDON is calculated as follows: let m and n be consecutive NAL units in transmission order.  For the very first NAL unit in transmission order (whose index is 0), AbsDON(0) = DON(0).  For other NAL units, AbsDON is calculated as follows:

If DON(m) == DON(n), AbsDON(n) = AbsDON(m)

If (DON(m) < DON(n) and DON(n) - DON(m) < 32768), AbsDON(n) = AbsDON(m) + DON(n) - DON(m)

If (DON(m) > DON(n) and DON(m) - DON(n) >= 32768), AbsDON(n) = AbsDON(m) + 65536 - DON(m) + DON(n)

If (DON(m) < DON(n) and DON(n) - DON(m) >= 32768), AbsDON(n) = AbsDON(m) - (DON(m) + 65536 - DON(n))

If (DON(m) > DON(n) and DON(m) - DON(n) < 32768), AbsDON(n) = AbsDON(m) - (DON(m) - DON(n))

where DON(i) is the decoding order number of the NAL unit having index i in the transmission order.  The decoding order number is specified in Section 5.5.

Note informative: les récepteurs peuvent l'utiliser pour décider quelles NALU envoyer au décodeur.

max-rcmd-nalu-size: récepteur; pas d'autres usages. Taille maximale de NALU gérée efficacement en octets (recommandation). Les expéditeurs PEUVENT produire des NALU plus grandes. 0–4294967295; absent: pas de limite connue. Tenir compte du MTU et de la découverte de MTU. Motivation par ex. passerelle IP–H.223.

Note informative: des valeurs trop petites peuvent nuire.

sar-understood: récepteur; plus grand aspect_ratio_idc compris < 255 selon le tableau E-1 de [1]. Pour décodeurs [1]: typiquement 16; extension du tableau → plus élevé; [1] 2003: 13. Absent → 13.

sar-supported: de 1 à sar-understood ou 255. N < 255: prend en charge les SAR pour aspect_ratio_idc 1..N sans distorsion géométrique. 255: tous les SAR représentables via Extended_SAR.

Les encodeurs conformes H.264 DEVRAIENT éviter d'envoyer aspect_ratio_idc 0 ou entre sar-understood et 255; DEVRAIENT envoyer un SAR que le récepteur peut afficher sans distorsion; PEUVENT toutefois choisir un SAR arbitraire. SAR réel dans la VUI de la SPS.

Encoding considerations: uniquement pour transport RTP (RFC 3550).

Security considerations: section 9 de RFC 6184.

Public specification: RFC 6184 et section 17.

Additional information: aucune

File extensions: aucune

Macintosh file type code: aucune

Object identifier or OID: aucune

Person & email address to contact for further information: Ye-Kui Wang, [email protected]

Intended usage: COMMON

Author: Ye-Kui Wang, [email protected]

Change controller: groupe de travail IETF Audio/Video Transport, délégué par l'IESG.