8.1. Media Type Registration (メディアタイプの登録)

8.1. Media Type Registration (メディアタイプの登録)

ITU-T H.264 | ISO/IEC 14496-10 コーデックのメディアサブタイプは IETF ツリーに割り当てられている.

メディアタイプ名 (Media Type name): video

メディアサブタイプ名 (Media subtype name): H264

必須パラメータ (Required parameters): なし

任意 (OPTIONAL) パラメータ:

profile-level-id: [1] に従うシーケンスパラメータセットの NALU 内の次の 3 バイトの base16 [7] (16 進) 表現である: 1) profile_idc, 2) ここでは profile-iop と呼ぶ 1 バイト (constraint_set0_flag, constraint_set1_flag, constraint_set2_flag, constraint_set3_flag, constraint_set4_flag, constraint_set5_flag および reserved_zero_2bits を最上位ビットからのビット有意順で並べたもの), 3) level_idc. [1] では reserved_zero_2bits は 0 でなければならないが, ITU-T または ISO/IEC が将来別値を規定してもよい.

パラメータ profile-level-id は, ストリームの生成に用いられ得るまたは受信側がサポートする符号化ツールの部分集合であるデフォルトサブプロファイルと, ストリームまたは受信側がサポートするデフォルトレベルを示す.

デフォルトサブプロファイルは profile_idc バイトと profile-iop バイト内のフィールドによって共同で示される. profile-iop のフィールド値に応じて, デフォルトサブプロファイルは 1 つのプロファイルがサポートするツール集合または複数プロファイルの共通部分集合になり得る ([1] の 7.4.2.1.1 参照). デフォルトレベルは level_idc バイトで示され, profile_idc が 66, 77 または 88 (Baseline, Main, Extended) かつ level_idc が 11 のときは profile-iop のビット 4 (constraint_set3_flag) でも示される. profile_idc が 66, 77 または 88, level_idc が 11, かつ profile-iop のビット 4 (constraint_set3_flag) が 1 のとき, デフォルトレベルはレベル 1b である.

表 5 は [1] の付録 A で定義されるすべてのプロファイルと, 各プロファイルについて同一サブプロファイルを表す profile_idc と profile-iop の可能な組合せを列挙する.

表 5. あるプロファイルがサポートする符号化ツールの全体に対応する同一サブプロファイルを表す profile_idc と profile-iop の組合せ. 以下 x は 0 または 1. プロファイル名: 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 (16 進)	profile-iop (2 進)
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

例: 上表で profile_idc が 58 (Extended) かつ profile-iop が 11xx0000 のときは, profile_idc が 42 (Baseline) かつ profile-iop が x1xx0000 の場合と同一サブプロファイルである. 表 5 にない profile_idc と profile-iop の他の組合せは, 複数プロファイルのツールの共通部分集合に相当するサブプロファイルを表し得る. あるプロファイルに適合するデコーダは, 他プロファイルのストリームをデコードできる場合がある.

profile-level-id が NALU ストリームの属性を示す場合, そのストリームをデコードするためにサポートすべき最小ツール集合はデフォルトサブプロファイルであり, サポートすべき最低レベルはデフォルトレベルである.

profile-level-id が能力交換またはセッション確立に用いられる場合, コーデックが受信および送信の両方でサポートするツール部分集合はデフォルトサブプロファイルに等しい. max-recv-level がない場合, profile-level-id のデフォルトレベルはコーデックがサポートしたい最高レベルである. max-recv-level がある場合, それは受信でサポートする最高レベルである. 受信および送信について, サポートする最高レベルより低いすべてのレベルもサポートしなければならない.

参考注: 能力交換およびセッション確立の手続きは, サポートする各サブプロファイルごとに能力を別々に列挙できる手段を備えるべきである. 例えば SDP Offer/Answer モデルの one-of-N コーデック選択 ([8] のセクション 10.2) が使える. 同一サブプロファイルを表す profile_idc / profile-iop の異なる組合せを提供するためにも用いられる. 等価な組合せが多いと SDP メッセージが大きくなり得る. 受信側はそれらを理解し, いずれかの等価組合せを用いたオファーを受理できるようにすべきである.

profile-level-id がない場合, 追加制約のない Baseline プロファイル Level 1 と推定しなければならない.

max-recv-level: 受信側がサポートする最高レベルがデフォルトレベル (profile-level-id) より高いとき, その最高レベルを示すためにこのパラメータを用いてもよい. 値は [1] に従う SPS NALU 内の構文要素 profile_idc の直後の 2 バイト (profile-iop (上記同様) と level_idc) の base16 表現である. max-recv-level の level_idc バイトが 11 かつ max-recv-level の profile-iop のビット 4 が 1 のとき, または level_idc が 9 かつ profile-iop のビット 4 が 0 のとき, 最高レベルはレベル 1b である. それ以外は max-recv-level の level_idc バイトを 10 で割った値に等しい.

受信側がサポートする最高レベルがデフォルトレベルより高くない場合, max-recv-level を含んではならない.

max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br: これらのパラメータは受信実装の能力を通知するために用いてもよい. 他の目的に用いてはならない. profile-level-id または max-recv-level で表される最高レベルは, 受信側が完全にサポートできるものでなければならない. これらのパラメータは, 以下で述べるように通知された最高レベルを超える能力を示してもよい.

(max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br) のうち複数が同時にある場合, 受信側は通知されたすべての能力を同時にサポートしなければならない. 例: max-mbps と max-br の両方がある場合, フレームレートとビットレートを拡張した通知最高レベルがサポートされる. すなわち受信側は, マクロブロック処理レートが max-mbps 以下, ビットレートが max-br 以下, CPB サイズが下記 max-br の意味から導出され, その他の属性が profile-level-id または max-recv-level の最高レベルに適合する NALU ストリームをデコードできる.

受信側がレベル A のすべての属性をサポートできる場合, profile-level-id または max-recv-level の最高レベルはレベル A でなければならない (それより低くてはならない). 言い換えると, 受信側は, 合わせて指示された最高レベルより高いレベルの要件を満たすような max-mbps, max-fs, max-cpb, max-dpb, max-br の値を通知してはならない.

参考注: 任意のメディアタイプパラメータが NALU ストリームの属性のみを通知するとき, max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br はなく, profile-level-id は常にストリームが規定のプロファイルとレベルに完全に適合するように取らなければならない.

max-mbps: 1 秒あたりのマクロブロック数で表す最大マクロブロック処理レートを示す整数. 通知最高レベルが要求するより速いデコードが受信側に可能であることを示す.

max-mbps が通知されている場合, 受信側は [1] の表 A-1 の MaxMBPS を max-mbps で置き換えた場合を除き通知最高レベルに適合する NALU ストリームをデコードできなければならない. max-mbps は最高レベルに対する表 A-1 の MaxMBPS 以上でなければならない. 送信側はより高いフレームレートで画像を送ってもよい.

max-smbps: すべてのマクロブロックが静的であると仮定したときの最大静的マクロブロックレート. 通知されると, [1] の表 A-1 の MaxMBPS は次の計算で置き換えるべきである:

• max-mbps が通知されていれば MaxMacroblocksPerSecond = max-mbps. そうでなければ profile-level-id または max-recv-level の通知最高レベルについて [1] 表 A-1 の MaxMBPS.

• P_non-static: 画像 n における非静的マクロブロックの割合.

• P_static: 画像 n における静的マクロブロックの割合.

• エンコーダは [1] 表 A-1 の MaxMBPS を次とみなすべきである:

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

エンコーダは画像ごとに再計算すべきである. max-smbps は明示的な max-mbps または通知最高レベルについて表 A-1 の暗黙の MaxMBPS 以上でなければならない.

max-fs: マクロブロック単位の最大フレームサイズ. レベルが要求するより大きい画像を示す. 通知されている場合, 受信側は表 A-1 の MaxFS を max-fs で置き換えた場合にデコードできなければならない. max-fs は表 A-1 の MaxFS 以上でなければならない. 送信側はより低いレートでより大きい画像を送ってもよい.

max-cpb: coded picture buffer の最大サイズを, VCL HRD では 1000 ビット単位, NAL HRD では 1200 ビット単位で示す. cpbBrVclFactor および cpbBrNALFactor ([1] 表 A-1) を直接使用しない. 最小より大きい CPB メモリを示す. 通知されている場合, 表 A-1 の MaxCPB は max-cpb で置き換えられる (必要なら係数を考慮). 値は表 A-1 の MaxCPB 以上でなければならない.

参考注: coded picture buffer は H.264 の仮想参照デコーダ (付録 C) で用いられる. HRD の使用は H.264 エンコーダでストリーム適合性の検証と出力ビットレート制御のために推奨される. coded picture buffer は去インターリーブやデジッターなど他の受信バッファとは概念的に独立である. 付録 C と同じ実装である必要はない. 適合ストリームをデコードできる限り, 適合デコーダは任意のバッファ配置を取ってよい. 実際にはビデオデコーダの入力バッファは去インターリーブおよびデジッタバッファと一体になり得る.

max-dpb: 8/3 マクロブロック単位の decoded picture buffer の最大サイズ. 通知されている場合, 表 A-1 の MaxDpbMbs は max-dpb * 3 / 8 で置き換えられる. デコード済みフレーム, 補完フィールドペア, 非ペアフィールドの記憶容量:

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

PicWidthInMbs および FrameHeightInMbs は [1] に従う. max-dpb は表 A-1 の MaxDpbMbs * 3 / 8 以上でなければならない.

参考注: ITU-T H.245 の類似コードポイントを補完する. RTP バッファとの直接的な関係はない.

参考注: RFC 3984 では単位は 1024 バイトであった. 本仕様では H.264 2010 と表 A-1 のため 8/3 マクロブロックとする.

max-br: 1000 bit/s (VCL HRD) および 1200 bit/s (NAL HRD) 単位の最大ビデオビットレート. 表 A-1 の MaxBR を置き換える. max-cpb がない場合, MaxCPB は (通知レベルの MaxCPB) * max-br / (最高レベルの MaxBR) で置き換えられる. 例: Main レベル 1.2 で max-br=1550 のとき, VCL 1550 kbit/s, NAL 1860 kbit/s, CPB 4036458 ビット. max-br は表 A-1 の MaxBR 以上でなければならない.

参考注: ネットワークがそのビットレートを常に扱えるとか, 輻輳制御下で通知ビットレートが実現可能であるとは推測できない.

redundant-pic-cap: 受信能力. 0: 冗長 coded picture を使わない. 送信側は冗長スライスを避けるべきである. 1: 冗長スライスをデコードできる. 送信側は送ってもよい. 欠落時は 0 とみなす. 存在するときは 0 または 1 のみ.

同一通知に profile-level-id があり冗長 coded picture を許さないプロファイル (例: Main) の場合, redundant-pic-cap は 0 でなければならない. 0 のとき, 受信ストリームに冗長 coded picture を含めないべきである.

参考注: 0 でもプロファイルが冗長画像を許せばデコーダは無視できる.

参考注: 1 でも他の誤り隠蔽戦略を用いてよい.

sprop-parameter-sets: デコード順で他の任意の NALU より前に置く初期 SPS/PPS NALU を運んでもよい. コーデック能力を示してはならない. 値は [1] の 7.3.2.1 および 7.3.2.2 に従うカンマ区切り base64 [7] リストである.

参考注: 複数ペイロード型がある場合, 受信側はすべての sprop-parameter-sets をバッファすべきである.

profile-level-id に適合するパラメータセットのみ. ツール部分集合とレベルはデフォルトサブプロファイルおよびデフォルトレベルに一致しなければならない.

sprop-level-parameter-sets: デフォルトレベル以外のレベルについて上記と同様. 3 バイトの PLId 接頭辞 (profile-level-id と同じ構文) でグループ化. PSL は sprop-parameter-sets と同じ. 形式 PLId:PSL, ペアは : で区切る. PSL 内は , で複数セット.

各 PLId: 同一デフォルトサブプロファイル, レベルはデフォルトと異なる. 各 PSL 内のすべての SPS の profile_idc から level_idc までのバイトは先行する PLId と等しい.

参考注: Offer/Answer で帯外パラメータセットとともにレベル変更を効率よく行える.

use-level-src-parameter-sets: 受信能力, 0 または 1. 欠落 → 0. 0: sprop-level-parameter-sets および [9] §6.3 の fmtp ソース属性を理解せず無視する. 1: 理解しこれらの機構のセットを用いられる.

参考注: RFC 3984 受信側はこれらの拡張を無視する. 受理レベルが下がり use-level-src-parameter-sets=1 がない場合は帯内搬送が必要.

in-band-parameter-sets: 1: 受信側は sprop-parameter-sets と sprop-level-parameter-sets の帯外セットを破棄する. 送信側はすべて帯内で送らなければならない. 0: 帯外を用いる. 送信側は帯内でも送ってよい. 1 のとき use-level-src-parameter-sets を含めてはならないか 0 でなければならない. 欠落: 能力は未規定.

level-asymmetry-allowed: Offer/Answer で方向間のレベル非対称を許すか. 0 または 1. 欠落 → 0. 両方 1 なら非対称可. いずれか 0 なら不可. 両方向同一レベル.

packetization-mode: RTP ペイロード型の属性または受信能力. 構成点は 1 つ. 複数モードは複数ペイロード型.

0 または欠落: single NAL モード (特に H.241 [3] セクション 12.1). 1: non-interleaved. 2: interleaved. 値は 0〜2 の整数でなければならない.

sprop-interleaving-depth: モード 2 では欠落してはならない. モード 0 または 1 ではあってはならない. 伝送順である VCL NALU の後にデコード順で続く VCL NALU の前にある VCL NALU の最大個数. バッファサイズ ≥ sprop-interleaving-depth + 1 VCL NALU. 値 0〜32767.

sprop-deint-buf-req: モード 2 では上記どおり必須. 去インターリーブバッファに必要なサイズ (バイト) はセクション 7.2 以上. 値 0〜4294967295.

参考注: 去インターリーブバッファのみ. ネットワークジッタバッファは別途.

deint-buf-cap: 受信側の去インターリーブバッファ容量 (バイト). 欠落 → 0. 0〜4294967295.

参考注: 受信側去インターリーブバッファの最大可能サイズのみ.

sprop-init-buf-time: ストリーム属性を示してもよい. packetization-mode が 0 または 1 のときはあってはならない.

受信側がデコードを開始する前に, 伝送順から NAL デコード順を復元するために待つ初期バッファ時間. (NALU のデコード時間 − NALU の伝送時間) の最大値とし, 伝送は信頼かつ遅延なし, 伝送とデコードは同一時間軸, 最初のパケット到着でデコード開始と仮定する.

sprop-init-buf-time の指定例: 次のインターリーブ順で NALU ストリームを送信. 値はデコード時間, 伝送順は左から右:

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

NALU レート一定のときの伝送時間:

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

列ごとに 伝送 − デコード:

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

NAL 伝送時間間隔の単位では本例の sprop-init-buf-time は 1. 90 kHz クロックティックでの非負 base10 整数. 欠落: 初期バッファ値なし. それ以外は 0〜4294967295.

sprop-init-buf-time に加え, 受信側は伝送ジッタバッファ (ミキサ, トランスレータ, ゲートウェイ, プロキシ, トラフィックシェイパなど) を考慮すべきである.

sprop-max-don-diff: ストリーム属性. 送信/受信/コーデック能力ではない. モード 0/1 ではあってはならない. 0〜32767. 欠落: 値未規定. 計算:

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.

参考注: 受信側はデコーダに渡す NALU を制御するために用いてよい.

max-rcmd-nalu-size: 受信側. 他用途禁止. 効率的に扱える最大 NALU サイズ (バイト) の推奨. 送信側はより大きい NALU を生成してもよい. 0〜4294967295. 欠落: 既知の上限なし. MTU と MTU 探索を考慮. 動機の例: IP–H.223 ゲートウェイ.

参考注: 小さすぎる値は有害になり得る.

sar-understood: 受信側. [1] 表 E-1 に従い理解する最大 aspect_ratio_idc < 255. [1] 適合デコーダの受信側では通常 16. 表拡張でより大きく. [1] 2003 版では 13. 欠落 → 13.

sar-supported: 1 から sar-understood または 255. N < 255: aspect_ratio_idc 1..N の SAR を幾何歪みなくサポート. 255: Extended_SAR で表現可能なすべての SAR.

H.264 適合エンコーダは aspect_ratio_idc 0 または sar-understood と 255 の間を送るべきではない. 受信側が歪みなく表示できる SAR を送るべきである. 任意の SAR を選んでもよい. 実際の SAR は SPS の VUI にある.

Encoding considerations: RTP 搬送 (RFC 3550) のみ.

Security considerations: RFC 6184 のセクション 9.

Public specification: RFC 6184 およびセクション 17.

Additional information: なし

File extensions: なし

Macintosh file type code: なし

Object identifier or OID: なし

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 ワーキンググループ (IESG が委任).