8.1. Media Type Registration (Registrazione del tipo di media)

8.1. Media Type Registration (Registrazione del tipo di media)

Il sottotipo di media per il codec ITU-T H.264 | ISO/IEC 14496-10 è stato assegnato nell'albero IETF.

Nome del tipo di media (Media Type name): video

Nome del sottotipo di media (Media subtype name): H264

Parametri obbligatori (Required parameters): nessuno

Parametri OPZIONALI:

profile-level-id: rappresentazione base16 [7] (esadecimale) dei tre byte seguenti nella NALU del sequence parameter set secondo [1]: 1) profile_idc, 2) un byte qui chiamato profile-iop, composto dai valori di constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag e reserved_zero_2bits nell'ordine di significatività dei bit, a partire dal bit più significativo, e 3) level_idc. In [1], reserved_zero_2bits deve essere 0, ma ITU-T o ISO/IEC possono specificare altri valori in futuro.

Il parametro profile-level-id indica il sottoprofilo predefinito (cioè il sottoinsieme di strumenti di codifica che possono essere stati usati per generare il flusso o che il ricevente supporta) e il livello predefinito del flusso o supportato dal ricevente.

Il sottoprofilo predefinito è indicato congiuntamente dal byte profile_idc e dai campi nel byte profile-iop. In base ai valori dei campi in profile-iop, il sottoprofilo predefinito può essere l'insieme di strumenti di un profilo o un'intersezione comune di più profili, come specificato nella sezione 7.4.2.1.1 di [1]. Il livello predefinito è indicato dal byte level_idc e, quando profile_idc è 66, 77 o 88 (profili Baseline, Main o Extended) e level_idc è 11, anche dal bit 4 (constraint_set3_flag) di profile-iop. Quando profile_idc è 66, 77 o 88, level_idc è 11 e il bit 4 (constraint_set3_flag) di profile-iop è 1, il livello predefinito è il livello 1b.

La tabella 5 elenca tutti i profili definiti nell'allegato A di [1] e, per ciascuno, le possibili combinazioni di profile_idc e profile-iop che rappresentano lo stesso sottoprofilo.

Tabella 5. Combinazioni di profile_idc e profile-iop che rappresentano lo stesso sottoprofilo corrispondente all'insieme completo di strumenti di codifica supportato da un profilo. Qui sotto, x può essere 0 o 1; nomi profilo: 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 (esadecimale)	profile-iop (binario)
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

Esempio: nella tabella sopra, profile_idc uguale a 58 (Extended) con profile-iop uguale a 11xx0000 indica lo stesso sottoprofilo di profile_idc uguale a 42 (Baseline) con profile-iop uguale a x1xx0000. Altre combinazioni di profile_idc e profile-iop (non elencate nella tabella 5) possono rappresentare un sottoprofilo equivalente all'intersezione di strumenti di più profili. Un decodificatore conforme a un dato profilo può talvolta decodificare flussi di altri profili.

Se profile-level-id indica le proprietà di un flusso NALU, il sottoinsieme minimo di strumenti da supportare per decodificare il flusso è il sottoprofilo predefinito, e il livello più basso da supportare è il livello predefinito.

Se profile-level-id è usato per scambio di capacità o instaurazione di sessione, indica il sottoinsieme di strumenti uguale al sottoprofilo predefinito che il codec supporta in ricezione e in invio. Senza max-recv-level, il livello predefinito da profile-level-id è il livello più alto che il codec intende supportare. Con max-recv-level, è il livello più alto di ricezione. Per ricezione e invio, tutti i livelli inferiori al livello più alto supportato DEVONO essere supportati.

Nota informativa: le procedure di scambio capacità e instaurazione sessione dovrebbero consentire di elencare separatamente le capacità per ogni sottoprofilo supportato. Ad esempio, la selezione one-of-N del modello SDP Offer/Answer (sezione 10.2 di [8]) può essere usata, così come per fornire diverse combinazioni equivalenti profile_idc / profile-iop. Con molte combinazioni equivalenti, il messaggio SDP può diventare voluminoso; un ricevente dovrebbe comprenderle e accettare un'offerta che ne usi una qualsiasi.

Senza profile-level-id, si DEVE dedurre il profilo Baseline senza vincoli aggiuntivi al livello 1.

max-recv-level: questo parametro PUÒ indicare il livello più alto supportato dal ricevente quando è superiore al livello predefinito (profile-level-id). Il valore è una rappresentazione base16 dei due byte che seguono profile_idc nella NALU SPS secondo [1]: profile-iop (come sopra) e level_idc. Se il byte level_idc di max-recv-level è 11 e il bit 4 di profile-iop di max-recv-level è 1, oppure se level_idc è 9 e il bit 4 di profile-iop è 0, il livello più alto è il livello 1b. Altrimenti è uguale al byte level_idc di max-recv-level diviso per 10.

max-recv-level NON DEVE essere presente se il livello più alto supportato dal ricevente non è superiore al livello predefinito.

max-mbps, max-smbps, max-fs, max-cpb, max-dpb e max-br: questi parametri POSSONO segnalare le capacità di un'implementazione ricevente. NON DEVONO essere usati per altri scopi. Il livello più alto espresso in profile-level-id o max-recv-level DEVE essere tale che il ricevente possa supportarlo completamente. Questi parametri POSSONO estendere le capacità oltre il livello più alto segnalato, come specificato sotto.

Se è presente più di un parametro tra (max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br), il ricevente DEVE supportare simultaneamente tutte le capacità segnalate. Esempio: se sono presenti max-mbps e max-br, il livello più alto segnalato con estensioni di frame rate e bitrate è supportato; il ricevente può decodificare flussi NALU in cui il tasso di macroblocchi è fino a max-mbps, il bitrate fino a max-br, la dimensione CPB derivata come nella semantica di max-br sotto, e le altre proprietà conformi al livello più alto di profile-level-id o max-recv-level.

Se un ricevente può supportare tutte le proprietà del livello A, il livello più alto in profile-level-id o max-recv-level DEVE essere il livello A (cioè non inferiore). In altre parole, un ricevente NON DEVE segnalare valori di max-mbps, max-fs, max-cpb, max-dpb e max-br che, insieme, soddisfano un livello superiore al livello più alto indicato.

Nota informativa: quando i parametri OPZIONALI del tipo di media descrivono solo le proprietà del flusso NALU, max-mbps, max-smbps, max-fs, max-cpb, max-dpb e max-br sono assenti, e profile-level-id deve sempre essere tale che il flusso rispetti interamente profilo e livello.

max-mbps: intero che indica il tasso massimo di elaborazione macroblocchi in macroblocchi al secondo. Indica che il ricevente può decodificare più velocemente di quanto richiesto dal livello più alto segnalato.

Se max-mbps è segnalato, il ricevente DEVE poter decodificare flussi NALU conformi al livello più alto segnalato, salvo che MaxMBPS della tabella A-1 di [1] sia sostituito da max-mbps. max-mbps DEVE essere ≥ MaxMBPS della tabella A-1 per il livello più alto. I mittenti POSSONO inviare immagini a frame rate più elevato.

max-smbps: tasso massimo di macroblocchi statici (ipotesi: tutti i macroblocchi statici). Quando è segnalato, MaxMBPS della tabella A-1 di [1] dovrebbe essere sostituito dal calcolo seguente:

• Se max-mbps è segnalato, MaxMacroblocksPerSecond = max-mbps. Altrimenti MaxMBPS dalla tabella A-1 [1] per il livello più alto segnalato in profile-level-id o max-recv-level.

• P_non-static: proporzione di macroblocchi non statici nell'immagine n.

• P_static: proporzione di macroblocchi statici nell'immagine n.

• Il codificatore dovrebbe considerare MaxMBPS della tabella A-1 di [1] come uguale a:

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

Il codificatore dovrebbe ricalcolare per ogni immagine. max-smbps DEVE essere ≥ il valore esplicito di max-mbps o MaxMBPS implicito dalla tabella A-1 per il livello più alto segnalato.

max-fs: dimensione massima immagine in macroblocchi. Indica immagini più grandi di quanto richiesto dal livello. Se segnalato, il ricevente DEVE poter decodificare con MaxFS della tabella A-1 sostituito da max-fs. max-fs DEVE essere ≥ MaxFS della tabella A-1. I mittenti POSSONO inviare immagini più grandi a frame rate inferiore.

max-cpb: dimensione massima del coded picture buffer in unità di 1000 bit (VCL HRD) e 1200 bit (NAL HRD). Non usa direttamente cpbBrVclFactor e cpbBrNALFactor (tabella A-1 [1]). Indica più memoria CPB del minimo. Se segnalato, MaxCPB della tabella A-1 è sostituito da max-cpb (considerando i fattori se necessario). Il valore DEVE essere ≥ MaxCPB della tabella A-1.

Nota informativa: il coded picture buffer è usato nel decodificatore di riferimento ipotetico (allegato C di H.264). L'uso dell'HRD è raccomandato negli encoder H.264 per verificare la conformità del flusso e controllare il bitrate. Il coded picture buffer è concettualmente indipendente dagli altri buffer di ricezione, inclusi de-interleaving e de-jitter. Non deve essere implementato come nell'allegato C; i decodificatori conformi possono avere qualsiasi disposizione di buffer purché decodifichino flussi conformi. In pratica, il buffer di ingresso del decodificatore video può essere integrato con i buffer di de-interleaving e de-jitter.

max-dpb: dimensione massima del decoded picture buffer in unità di 8/3 macroblocchi. Se segnalato, MaxDpbMbs della tabella A-1 è sostituito da max-dpb * 3 / 8. Capacità di memorizzazione per immagini decodificate, coppie di campi complementari e campi non accoppiati:

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

PicWidthInMbs e FrameHeightInMbs secondo [1]. max-dpb DEVE essere ≥ MaxDpbMbs * 3 / 8 dalla tabella A-1.

Nota informativa: completa un punto di codice simile in ITU-T H.245; nessuna relazione diretta con i buffer RTP.

Nota informativa: in RFC 3984 l'unità era 1024 byte; qui 8/3 macroblocchi a causa di H.264 2010 e della tabella A-1.

max-br: bitrate video massimo in 1000 bit/s (VCL HRD) e 1200 bit/s (NAL HRD). Sostituisce MaxBR della tabella A-1; senza max-cpb, MaxCPB è sostituito da (MaxCPB del livello segnalato) * max-br / (MaxBR del livello più alto). Esempio Main livello 1.2 con max-br=1550: 1550 kbit/s VCL, 1860 kbit/s NAL, CPB 4036458 bit. max-br DEVE essere ≥ MaxBR della tabella A-1.

Nota informativa: non si può dedurre che la rete supporti tali bitrate né sotto vincoli di controllo della congestione.

redundant-pic-cap: capacità ricevente. 0: nessun uso di coded picture ridondanti; il mittente DOVREBBE evitare slice ridondanti. 1: può decodificare slice ridondanti; il mittente PUÒ inviarli. Assente: valore 0. Presente: solo 0 o 1.

Se profile-level-id è nella stessa segnalazione ed esclude coded picture ridondanti (es. Main), redundant-pic-cap DEVE essere 0. Con 0, il flusso ricevuto NON DOVREBBE contenere coded picture ridondanti.

Nota informativa: anche con 0, il decodificatore può ignorare immagini ridondanti se il profilo lo consente.

Nota informativa: anche con 1, sono possibili altre strategie di mascheramento errori.

sprop-parameter-sets: PUÒ trasportare le NALU SPS/PPS iniziali che precedono qualsiasi altra NALU in ordine di decodifica. NON DEVE indicare la capacità del codec. Valore: lista separata da virgole in base64 [7] secondo 7.3.2.1 e 7.3.2.2 di [1].

Nota informativa: con più tipi di payload, il ricevente dovrebbe mettere in buffer tutti i sprop-parameter-sets.

Solo parameter set conformi a profile-level-id; sottoinsieme strumenti e livello devono corrispondere al sottoprofilo e livello predefiniti.

sprop-level-parameter-sets: come sopra per livelli diversi dal livello predefinito. Set raggruppati con prefisso PLId su tre byte (stessa sintassi di profile-level-id); PSL come sprop-parameter-sets. Forma PLId:PSL, coppie separate da :; in un PSL, più set separati da ,.

Ogni PLId: stesso sottoprofilo predefinito, livello ≠ livello predefinito. Tutte le SPS in ogni PSL: byte da profile_idc a level_idc uguali al PLId precedente.

Nota informativa: consente cambio livello efficiente in Offer/Answer con trasporto fuori banda.

use-level-src-parameter-sets: capacità ricevente, 0 o 1; assente → 0. 0: non comprende sprop-level-parameter-sets né l'attributo sorgente fmtp [9] §6.3, li ignora. 1: comprende e può usare i set da questi meccanismi.

Nota informativa: un ricevente RFC 3984 ignora queste estensioni; se il livello accettato è inferiore senza use-level-src-parameter-sets=1, serve trasporto in-band.

in-band-parameter-sets: 1: il ricevente scarta i set fuori banda in sprop-parameter-sets e sprop-level-parameter-sets; il mittente DEVE inviare tutto in-band. 0: usa i set fuori banda; il mittente PUÒ comunque inviare in-band. Con 1, use-level-src-parameter-sets NON DEVE essere presente o deve valere 0. Assente: capacità non specificata.

level-asymmetry-allowed: Offer/Answer, asimmetria di livello tra direzioni? 0 o 1; assente → 0. Entrambi a 1: asimmetria consentita. 0 in uno o nell'altro: asimmetria vietata; stesso livello in entrambe le direzioni.

packetization-mode: proprietà di un tipo di payload RTP o capacità ricevente. Un solo punto di configurazione; più modalità → più tipi di payload.

0 o assente: modalità single NAL (in particolare H.241 [3], sezione 12.1). 1: non interleaved. 2: interleaved. Il valore DEVE essere un intero da 0 a 2.

sprop-interleaving-depth: NON DEVE mancare se modalità 2; NON DEVE essere presente se modalità 0 o 1. Numero massimo di NALU VCL in ordine di trasmissione che precedono una NALU VCL che le segue in ordine di decodifica. Dimensione buffer ≥ sprop-interleaving-depth + 1 NALU VCL. Valore 0–32767.

sprop-deint-buf-req: presenza obbligatoria in modalità 2 come sopra. Dimensione richiesta del buffer di de-interleaving in byte ≥ sezione 7.2. Valore 0–4294967295.

Nota informativa: riguarda solo il buffer di de-interleaving; prevedere anche buffer jitter di rete.

deint-buf-cap: capacità buffer de-interleaving del ricevente in byte. Assente → 0. 0–4294967295.

Nota informativa: solo dimensione massima possibile del buffer de-interleaving del ricevente.

sprop-init-buf-time: PUÒ descrivere le proprietà del flusso; NON DEVE essere presente se packetization-mode è 0 o 1.

Indica il tempo di buffer iniziale che il ricevente DEVE attendere prima di iniziare la decodifica per ripristinare l'ordine di decodifica NAL dall'ordine di trasmissione. È il massimo di (tempo di decodifica della NALU − tempo di trasmissione di una NALU), assumendo trasmissione affidabile e istantanea, stessa scala temporale per trasmissione e decodifica, e avvio decodifica all'arrivo del primo pacchetto.

Esempio per sprop-init-buf-time: flusso NALU inviato nel seguente ordine interleaved; il valore corrisponde al tempo di decodifica, l'ordine di trasmissione è da sinistra a destra:

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

A tasso NALU costante, i tempi di trasmissione:

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

Colonna per colonna, trasmissione meno decodifica dà:

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

In unità di intervalli di trasmissione NAL, sprop-init-buf-time vale quindi 1 in questo esempio. Codificato come intero base10 non negativo in tick di clock 90 kHz. Assente: nessun valore di buffer iniziale. Altrimenti il valore DEVE essere 0–4294967295.

Oltre a sprop-init-buf-time, i riceventi DOVREBBERO considerare il buffer jitter di trasmissione (mixer, traduttori, gateway, proxy, traffic shaper, ecc.).

sprop-max-don-diff: proprietà del flusso; non per capacità mittente/ricevente/codec; assente in modalità 0/1. 0–32767; assente: valore non specificato. Calcolo:

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.

Nota informativa: i riceventi possono usarlo per decidere quali NALU passare al decodificatore.

max-rcmd-nalu-size: ricevente; nessun altro uso. Dimensione massima NALU gestita efficientemente in byte (raccomandazione). I mittenti POSSONO produrre NALU più grandi. 0–4294967295; assente: nessun limite noto. Considerare MTU e MTU discovery. Motivazione es. gateway IP–H.223.

Nota informativa: valori troppo piccoli possono essere dannosi.

sar-understood: ricevente; massimo aspect_ratio_idc compreso < 255 secondo tabella E-1 di [1]. Per decodificatori [1]: tipicamente 16; estensione tabella → più alto; [1] 2003: 13. Assente → 13.

sar-supported: da 1 a sar-understood o 255. N < 255: supporta SAR per aspect_ratio_idc 1..N senza distorsione geometrica. 255: tutti i SAR rappresentabili via Extended_SAR.

Encoder conformi H.264 DOVREBBERO evitare di inviare aspect_ratio_idc 0 o tra sar-understood e 255; DOVREBBERO inviare un SAR che il ricevente possa visualizzare senza distorsione; POSSONO tuttavia scegliere un SAR arbitrario. SAR effettivo nella VUI della SPS.

Encoding considerations: solo per trasporto RTP (RFC 3550).

Security considerations: sezione 9 di RFC 6184.

Public specification: RFC 6184 e sezione 17.

Additional information: nessuna

File extensions: nessuna

Macintosh file type code: nessuna

Object identifier or OID: nessuna

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

Intended usage: COMMON

Author: Ye-Kui Wang, [email protected]

Change controller: working group IETF Audio/Video Transport, delegato dall'IESG.