8.1. Media Type Registration (Medientyp-Registrierung)

8.1. Media Type Registration (Medientyp-Registrierung)

Der Medienuntertyp für den Codec ITU-T H.264 | ISO/IEC 14496-10 wurde aus dem IETF-Baum zugeteilt.

Medientypname (Media Type name): video

Medienuntertypname (Media subtype name): H264

Erforderliche Parameter (Required parameters): keine

OPTIONALE Parameter:

profile-level-id: Eine base16 [7] (hexadezimale) Darstellung der folgenden drei Bytes in der Sequence-Parameter-Set-NAL-Einheit gemäß [1]: 1) profile_idc, 2) ein hier als profile-iop bezeichnetes Byte, zusammengesetzt aus den Werten von constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag und reserved_zero_2bits in Bit-Signifikanz-Reihenfolge, beginnend mit dem höchstwertigen Bit, und 3) level_idc. In [1] ist reserved_zero_2bits gleich 0 erforderlich, ITU-T oder ISO/IEC können jedoch künftig andere Werte festlegen.

Der Parameter profile-level-id gibt das Standard-Subprofil an (d. h. die Teilmenge der Codierwerkzeuge, die zur Erzeugung des Stroms verwendet worden sein können oder die der Empfänger unterstützt) sowie das Standard-Level des Stroms bzw. die der Empfänger unterstützt.

Das Standard-Subprofil wird gemeinsam durch das Byte profile_idc und Felder im Byte profile-iop angezeigt. Je nach Werten der Felder in profile-iop kann das Standard-Subprofil die von einem Profil unterstützte Werkzeugmenge oder eine gemeinsame Teilmenge mehrerer Profile sein, wie in Abschnitt 7.4.2.1.1 von [1] spezifiziert. Das Standard-Level wird durch das Byte level_idc angezeigt und, wenn profile_idc gleich 66, 77 oder 88 (Baseline-, Main- bzw. Extended-Profil) und level_idc gleich 11 ist, zusätzlich durch Bit 4 (constraint_set3_flag) von profile-iop. Wenn profile_idc gleich 66, 77 oder 88 ist, level_idc gleich 11 und Bit 4 (constraint_set3_flag) von profile-iop gleich 1 ist, ist das Standard-Level Level 1b.

Tabelle 5 listet alle in Anhang A von [1] definierten Profile und für jedes Profil die möglichen Kombinationen von profile_idc und profile-iop auf, die dasselbe Subprofil darstellen.

Tabelle 5. Kombinationen von profile_idc und profile-iop, die dasselbe Subprofil repräsentieren, das der vollen von einem Profil unterstützten Werkzeugmenge entspricht. Im Folgenden kann x 0 oder 1 sein; Profilnamen: 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 (binär)
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

Beispiel: In der Tabelle oben entspricht profile_idc gleich 58 (Extended) mit profile-iop gleich 11xx0000 demselben Subprofil wie profile_idc gleich 42 (Baseline) mit profile-iop gleich x1xx0000. Andere Kombinationen von profile_idc und profile-iop (nicht in Tabelle 5) können ein Subprofil darstellen, das der gemeinsamen Teilmenge von mehr als einem Profil entspricht. Ein Decoder, der einem bestimmten Profil entspricht, kann möglicherweise Bitströme anderer Profile dekodieren.

Wird profile-level-id verwendet, um Eigenschaften eines NAL-Einheitenstroms anzugeben, bedeutet dies: Zur Dekodierung des Stroms ist die minimale Werkzeugteilmenge das Standard-Subprofil, und das niedrigste zu unterstützende Level ist das Standard-Level.

Wird profile-level-id für Fähigkeitsaustausch oder Sitzungsaufbau verwendet, gibt er die dem Standard-Subprofil entsprechende Werkzeugteilmenge an, die der Codec sowohl zum Empfangen als auch zum Senden unterstützt. Ist max-recv-level nicht vorhanden, gibt das Standard-Level aus profile-level-id das höchste vom Codec gewünschte Level an. Ist max-recv-level vorhanden, gibt es das höchste Level an, das der Codec zum Empfangen unterstützt. Für Empfang und Senden MÜSSEN alle niedrigeren Level als das höchste unterstützte ebenfalls unterstützt werden.

Hinweis (informativ): Verfahren zum Fähigkeitsaustausch und Sitzungsaufbau sollten Mittel bereitstellen, die Fähigkeiten je unterstütztem Subprofil getrennt aufzulisten. Beispielsweise kann das One-of-N-Codec-Auswahlverfahren des SDP-Offer/Answer-Modells verwendet werden (Abschnitt 10.2 von [8]). Es kann auch genutzt werden, verschiedene Kombinationen von profile_idc und profile-iop bereitzustellen, die dasselbe Subprofil darstellen. Bei vielen äquivalenten Kombinationen kann die SDP-Nachricht groß werden. Ein Empfänger sollte äquivalente Kombinationen verstehen und ein Angebot mit jeder davon akzeptieren können.

Ist kein profile-level-id vorhanden, MUSS das Baseline-Profil ohne zusätzliche Einschränkungen auf Level 1 angenommen werden.

max-recv-level: Dieser Parameter KANN verwendet werden, um das höchste Level anzugeben, das ein Empfänger unterstützt, wenn es höher ist als das Standard-Level (aus profile-level-id). Der Wert von max-recv-level ist eine base16-Darstellung der zwei Bytes nach dem Syntaxelement profile_idc in der SPS-NAL-Einheit gemäß [1]: profile-iop (wie oben) und level_idc. Ist das Byte level_idc von max-recv-level gleich 11 und Bit 4 von profile-iop von max-recv-level gleich 1, oder ist level_idc gleich 9 und Bit 4 von profile-iop gleich 0, ist das höchste unterstützte Level Level 1b. Andernfalls ist es gleich dem Byte level_idc von max-recv-level geteilt durch 10.

max-recv-level DARF NICHT vorhanden sein, wenn das höchste unterstützte Level des Empfängers nicht höher ist als das Standard-Level.

max-mbps, max-smbps, max-fs, max-cpb, max-dpb und max-br: Diese Parameter KÖNNEN die Fähigkeiten einer Empfängerimplementierung signalisieren. Sie DÜRFEN NICHT für andere Zwecke verwendet werden. Das in profile-level-id oder max-recv-level ausgedrückte höchste Level MUSS so sein, dass der Empfänger es vollständig unterstützen kann. Die genannten Parameter KÖNNEN Fähigkeiten signalisieren, die über die des signalisierten höchsten Levels hinausgehen, wie unten spezifiziert.

Sind mehr als ein Parameter aus der Menge (max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br) vorhanden, MUSS der Empfänger alle signalisierten Fähigkeiten gleichzeitig unterstützen. Beispiel: Sind sowohl max-mbps als auch max-br vorhanden, wird das signalisierte höchste Level mit Erweiterung von Bildrate und Bitrate unterstützt; der Empfänger kann NAL-Einheitenströme dekodieren, in denen die Makroblock-Verarbeitungsrate bis einschließlich max-mbps, die Bitrate bis einschließlich max-br, die CPB-Größe gemäß der Semantik von max-br unten abgeleitet ist und die übrigen Eigenschaften dem höchsten Level aus profile-level-id oder max-recv-level entsprechen.

Kann ein Empfänger alle Eigenschaften von Level A unterstützen, MUSS das in profile-level-id oder max-recv-level angegebene höchste Level Level A sein (d. h. nicht niedriger). Mit anderen Worten: Ein Empfänger DARF keine Werte von max-mbps, max-fs, max-cpb, max-dpb und max-br signalisieren, die zusammen ein höheres Level erfüllen als das angegebene höchste Level.

Hinweis (informativ): Werden OPTIONALE Medientyp-Parameter nur zur Angabe von NAL-Einheitenstrom-Eigenschaften verwendet, sind max-mbps, max-smbps, max-fs, max-cpb, max-dpb und max-br nicht vorhanden, und profile-level-id muss stets so sein, dass der Strom vollständig dem Profil und Level entspricht.

max-mbps: Ganzzahl: maximale Makroblock-Verarbeitungsrate in Makroblöcken pro Sekunde. Signalisiert, dass der Empfänger schneller dekodieren kann als vom signalisierten höchsten Level gefordert.

Ist max-mbps signalisiert, MUSS der Empfänger NAL-Einheitenströme dekodieren können, die dem signalisierten höchsten Level entsprechen, außer dass der MaxMBPS-Wert in Tabelle A-1 von [1] durch max-mbps ersetzt wird. max-mbps MUSS größer oder gleich MaxMBPS aus Tabelle A-1 für das höchste Level sein. Sender KÖNNEN größere Bildraten nutzen.

max-smbps: Maximale statische Makroblockrate unter der Annahme, alle Makroblöcke seien statisch. Bei Signalisierung soll MaxMBPS in Tabelle A-1 von [1] durch folgende Berechnung ersetzt werden:

• Ist max-mbps signalisiert, setze MaxMacroblocksPerSecond auf max-mbps. Sonst auf MaxMBPS aus Tabelle A-1 [1] für das signalisierte höchste Level aus profile-level-id oder max-recv-level.

• P_non-static: Anteil nicht-statischer Makroblöcke in Bild n.

• P_static: Anteil statischer Makroblöcke in Bild n.

• Der Encoder soll MaxMBPS in Tabelle A-1 von [1] wie folgt betrachten:

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

Der Encoder soll dies pro Bild neu berechnen. max-smbps MUSS ≥ dem expliziten max-mbps oder impliziten MaxMBPS aus Tabelle A-1 für das signalisierte höchste Level sein.

max-fs: Maximale Bildgröße in Makroblöcken. Signalisiert größere Bilder als vom Level gefordert. Bei Signalisierung MUSS der Empfänger dekodieren können mit MaxFS aus Tabelle A-1 ersetzt durch max-fs. max-fs MUSS ≥ MaxFS aus Tabelle A-1. Sender KÖNNEN größere Bilder mit entsprechend niedrigerer Rate senden.

max-cpb: Maximale coded-picture-Buffer-Größe in Einheiten von 1000 Bit (VCL HRD) bzw. 1200 Bit (NAL HRD). Verwendet nicht direkt cpbBrVclFactor und cpbBrNALFactor (Tabelle A-1 [1]). Signalisiert mehr CPB-Speicher als Minimum. Bei Signalisierung MaxCPB in Tabelle A-1 durch max-cpb ersetzen (unter Berücksichtigung der Faktoren). Wert MUSS ≥ MaxCPB aus Tabelle A-1.

Hinweis (informativ): Der coded picture buffer wird im hypothetischen Referenzdecoder (Annex C von H.264) genutzt. Die Verwendung des HRD wird in H.264-Encodern empfohlen, um Bitstream-Konformität zu prüfen und die Ausgangsbitrate zu steuern. Der coded picture buffer ist konzeptionell unabhängig von anderen Empfangspuffern einschließlich De-Interleaving und De-Jitter. Er muss in Decodern nicht wie in Annex C implementiert sein; konforme Decoder können beliebige Pufferanordnungen haben, solange sie konforme Bitströme dekodieren können. Praktisch kann der Eingangspuffer des Videodecoders mit De-Interleaving- und De-Jitter-Puffern integriert sein.

max-dpb: Maximale decoded-picture-buffer-Größe in Einheiten von 8/3 Makroblöcken. Bei Signalisierung MaxDpbMbs durch max-dpb * 3 / 8 ersetzen. Speicherkapazität für decodierte Frames, komplementäre Feldpaare und nicht gepaarte Felder:

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

PicWidthInMbs und FrameHeightInMbs gemäß [1]. max-dpb MUSS ≥ MaxDpbMbs * 3 / 8 aus Tabelle A-1.

Hinweis (informativ): Ergänzt ITU-T H.245; keine direkte Beziehung zu RTP-Puffern.

Hinweis (informativ): In RFC 3984 war die Einheit 1024 Byte; hier 8/3 Makroblöcke wegen H.264-2010 und Tabelle A-1.

max-br: Maximale Videobitrate in 1000 bit/s (VCL HRD) bzw. 1200 bit/s (NAL HRD). Ersetzt MaxBR in Tabelle A-1; wenn max-cpb fehlt, MaxCPB durch (MaxCPB des Levels) * max-br / (MaxBR des höchsten Levels) ersetzen. Beispiel Main Level 1.2 mit max-br=1550: 1550 kbit/s VCL, 1860 kbit/s NAL, CPB 4036458 bit. max-br MUSS ≥ MaxBR aus Tabelle A-1.

Hinweis (informativ): Kein Schluss auf Netzkapazität oder Congestion Control.

redundant-pic-cap: Empfängerfähigkeit. 0: keine Nutzung redundanter coded pictures; Sender SOLLTEN keine redundanten Slices senden. 1: kann redundante Slices nutzen; Sender KÖNNEN sie senden. Fehlt der Parameter, MUSS 0 angenommen werden; wenn vorhanden, nur 0 oder 1.

Ist profile-level-id im selben Signaling und schließt redundante coded pictures aus (z. B. Main), MUSS redundant-pic-cap 0 sein. Bei 0 SOLL der Strom keine redundanten coded pictures enthalten.

Hinweis (informativ): Bei 0 können redundante Bilder ignoriert werden, wenn das Profil sie erlaubt.

Hinweis (informativ): Bei 1 können andere Fehlerverdeckungsstrategien genutzt werden.

sprop-parameter-sets: KANN initiale SPS/PPS-NAL-Einheiten übermitteln, die in Dekodierreihenfolge vor allen anderen stehen. DARF NICHT Codec-Fähigkeit signalisieren. Wert: kommagetrennte base64 [7]-Liste gemäß 7.3.2.1 und 7.3.2.2 von [1].

Hinweis (informativ): Mehrere Payload-Typen: Empfänger soll alle sprop-parameter-sets puffern.

Nur Parametersätze konform zu profile-level-id; Werkzeugteilmenge und Level müssen dem Standard-Subprofil bzw. -Level entsprechen.

sprop-level-parameter-sets: Wie oben, für Level ungleich Standard-Level. Gruppiert mit drei Byte PLId (Syntax wie profile-level-id); PSL wie sprop-parameter-sets. Form PLId:PSL, Paare durch Doppelpunkt getrennt; in PSL mehrere durch Komma.

Jedes PLId: gleiches Standard-Subprofil, Level ≠ Standard-Level. Alle SPS in jedem PSL: Bytes profile_idc bis level_idc gleich vorhergehendem PLId.

Hinweis (informativ): Ermöglicht effizientes Level up/down in Offer/Answer mit außerbandigen Parametersätzen.

use-level-src-parameter-sets: Empfängerfähigkeit, 0 oder 1; fehlend → 0. 0: versteht sprop-level-parameter-sets und fmtp-Quellattribut [9] 6.3 nicht, ignoriert sie. 1: versteht und kann Parametersätze aus diesen Mechanismen nutzen.

Hinweis (informativ): RFC-3984-Empfänger ignoriert diese Erweiterungen; bei niedrigerem akzeptiertem Level ohne use-level-src-parameter-sets=1 ist In-Band-Transport nötig.

in-band-parameter-sets: 1: Empfänger verwirft außerbandige SPS in sprop-parameter-sets und sprop-level-parameter-sets; Sender MUSS alles in-band senden. 0: nutzt außerbandige; Sender KANN trotzdem in-band senden. Bei 1 darf use-level-src-parameter-sets nicht 1 sein oder fehlen. Fehlt der Parameter, ist die Fähigkeit nicht spezifiziert.

level-asymmetry-allowed: Offer/Answer: unterschiedliche Level je Richtung erlaubt? 0 oder 1; fehlend → 0. Beide mit 1: Asymmetrie erlaubt. 0 in einem: nicht erlaubt; Level in beiden Richtungen gleich.

packetization-mode: Eigenschaften eines RTP-Payload-Typs oder Empfängerfähigkeit. Nur ein Konfigurationspunkt; mehrere Modi → mehrere Payload-Typen.

0 oder fehlend: Single-NAL-Modus (u. a. H.241 [3], Abschnitt 12.1). 1: non-interleaved. 2: interleaved. Wert MUSS 0–2 sein.

sprop-interleaving-depth: DARF NICHT fehlen bei mode 2; nicht bei 0/1. Maximalzahl VCL-NAL-Einheiten in Sendereihenfolge vor einer VCL-NAL-Einheit, die ihr in Dekodierreihenfolge folgen. Puffergröße ≥ sprop-interleaving-depth + 1 VCL-NAL-Einheiten. Wert 0–32767.

sprop-deint-buf-req: Wie oben Anwesenheitspflicht bei mode 2. Erforderliche De-Interleaving-Puffergröße in Byte ≥ Abschnitt 7.2. Wert 0–4294967295.

Hinweis (informativ): Nur De-Interleaving; Jitterpuffer zusätzlich.

deint-buf-cap: Empfänger-De-Interleaving-Kapazität in Byte. Fehlt → 0. 0–4294967295.

Hinweis (informativ): Nur De-Interleaving-Maximum des Empfängers.

sprop-init-buf-time: KANN Stromeigenschaften signalisieren; DARF NICHT vorhanden sein, wenn packetization-mode 0 oder 1 ist.

Der Parameter gibt die anfängliche Pufferzeit an, die ein Empfänger VOR Dekodestart warten MUSS, um die NAL-Dekodierreihenfolge aus der Sendereihenfolge wiederherzustellen. Es ist der Maximalwert von (Dekodierzeit der NAL-Einheit − Übertragungszeit einer NAL-Einheit), unter Annahme zuverlässiger und verzögerungsfreier Übertragung, derselben Zeitachse für Übertragung und Dekodierung und Beginn der Dekodierung beim Eintreffen des ersten Pakets.

Beispiel zur Angabe von sprop-init-buf-time: Ein NAL-Einheitenstrom wird in folgender verschachtelter Reihenfolge gesendet; der Wert entspricht der Dekodierzeit, die Sendereihenfolge ist von links nach rechts:

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

Bei konstanter NAL-Senderate sind die Übertragungszeiten:

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

Spaltenweise Übertragungszeit minus Dekodierzeit ergibt:

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

In Intervallen der NAL-Übertragungszeiten ist sprop-init-buf-time in diesem Beispiel daher 1. Der Parameter ist als nicht negative base10-Ganzzahl in Taktzyklen eines 90-kHz-Takts codiert. Fehlt er, ist keine Anfangspufferzeit definiert. Andernfalls MUSS der Wert 0–4294967295 sein.

Zusätzlich zum signalisierten sprop-init-buf-time SOLLTEN Empfänger Übertragungs-Jitter-Puffer berücksichtigen, einschließlich Jitter durch Mixer, Übersetzer, Gateways, Proxies, Traffic Shaper und andere Netzelemente.

sprop-max-don-diff: Stromeigenschaften; nicht für Sender/Empfänger/Codec-Fähigkeit; nicht bei mode 0/1. 0–32767; fehlend: Wert unspezifiziert. Berechnung:

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.

Hinweis (informativ): Empfänger können damit steuern, welche NAL-Einheiten an den Decoder gehen.

max-rcmd-nalu-size: Empfänger; keine anderen Zwecke. Größte effizient handhabbare NALU-Größe in Byte (Empfehlung). Sender KÖNNEN größere NALUs erzeugen. 0–4294967295; fehlend: keine bekannte Grenze. MTU und MTU-Discovery beachten. Motivation z. B. IP–H.223-Gateway.

Hinweis (informativ): Zu kleine Werte können schaden.

sar-understood: Empfänger; max. verstandenes aspect_ratio_idc < 255 gemäß [1] Tabelle E-1. Für Decoder gemäß [1]: typisch 16; Erweiterung der Tabelle → höher; 2003er [1]: 13. Fehlt → 13.

sar-supported: 1 bis sar-understood oder 255. N < 255: unterstützt SARs für aspect_ratio_idc 1..N ohne geometrische Verzerrung. 255: alle über Extended_SAR darstellbaren SARs.

H.264-konforme Encoder SOLLTEN kein aspect_ratio_idc 0 oder zwischen sar-understood und 255 senden; SOLLTEN SAR senden, die der Empfänger verzerrungsfrei darstellen kann; KÖNNEN aber beliebige SAR wählen. Tatsächliches SAR in VUI der SPS.

Encoding considerations: Nur für RTP-Übertragung (RFC 3550).

Security considerations: Abschnitt 9 von RFC 6184.

Public specification: RFC 6184 und Abschnitt 17.

Additional information: Keine

File extensions: keine

Macintosh file type code: keine

Object identifier or OID: keine

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

Intended usage: COMMON

Author: Ye-Kui Wang, [email protected]

Change controller: IETF Audio/Video Transport working group, delegiert von der IESG.