転載元の執筆者は muken氏 で、2010年10月に投稿された記事です（翌2011年にデッドリンク化）。
そのため現在の認識と齟齬が生じる部分があります。
/* 内容が難しいかもしれないので要約 */
Open-GOPやintra-refreshを有効にして現行のx264cliでmp4出力すると規格違反ですよ。
Open-GOPはMPEG-2 Videoの頃から使用されている技術で、DVDやMPEG-2 Videoを映像CODECに含む放送TSでも使われている。
このどこにでも見られるような技術が、AVCを含むMP4コンテナでの実装において、現在、困難な状況となっている。
Open-GOPは開いたGOPである。開いているGOPとわざわざ言うからには閉じているGOPもある。これをClosed-GOPと呼ぶ。
GOPはGroup Of Picturesの略であり、一般に、あるI-pictureからその次のI-pictureの直前までを一つのGOPとみなす。
I-pictureとは、動画像を構成する一枚一枚のpicture(画像)の内、単独で圧縮符号化されているpictureである。IはIntra(空間内)という意味である。
今、未来を後方、過去を前方と表現することにする。
前方の動画像圧縮符号化情報のみを参照して、その差分から構成されるpictureをP-pictureと言う。PはPredictive(予測的な)という意味である。
前方と後方の両方の動画像圧縮符号化情報を参照して、その差分から構成されるpictureをB-pictureと言う。BはBi-directional(双方向の)という意味である。
I-pictureは、単独で符号化されている、すなわち、他のpictureとは独立しているので、他のpictureを参照しない。
P-pictureもB-pictureも、データ上の並び順(符号順/復号順)で見て他の古いpictureを参照する。
気を付けなければならないのは、B-pictureではデータ上の並び順と、実際に再生時に表示される順番が異なることだ。
B-pictureは参照先のpictureの差分で生成される。参照先が事前に復号・解釈されていないと、それ自体も完全に解釈できない。
これはP-pictureに関しても同じであるが、B-pictureは後方をも参照するのである。
従って、B-pictureが参照する後方(未来)のpictureは、データ上ではそのB-pictureよりも先行する。
例を見てみよう。
[]で括られた数字はデータ上での並び順で番号を付したものである。
デコーダ(復号器)はこの番号順に従って復号を行う。
符号順: I[0]P[1]B[2]P[3]P[4]P[5]B[6]P[7]I[8]P[9]B[10]P[11]I[12]B[13]B[14]P[15]B[16]
表示順: I[0]B[2]P[1]P[3]P[4]B[6]P[5]P[7]I[8]B[9]P[10]P[11]B[13]B[14]I[12]B[16]P[15]
P[1]はI[0]を参照し、B[2]はI[0]とP[1]を参照している。これによりI[0]->B[2]->P[1]という表示順を実現している。
また、P[9]はI[8]を参照し、B[10]はI[8]とP[9]を参照している。
符号順で見て、I[8]以降のpictureは全て、I[0]～P[7]までのpictureを参照しない。
つまりI[0]～P[7]のpictureはI[8]以降のpictureからは依存されてはいない。
従って、I[0]～P[7]間のpictureから構成されるGOPを全てバッサリ切り捨てても、I[8]以降のpicutureの復号及びその表示には何の影響もないのである。
I[8]は直前のGOP I[0]～P[7]がを考慮せずに、それ以降の復号及び表示を難なく行えることからランダムアクセス(ファイル上でのシーク)に適したpictureと言える。このようなpictureをkey-frameと呼ぶ。
さて、I[8]～P[11]のGOPについてはどうだろう。これをバッサリ切り捨てたら、I[12]～B[16]のGOPは正常に復号出来るだろうか？
答えは否である。なぜならばI[12]の直後にB[13]があるからである。これはつまりB-pictureの性質からB[13]は、符号順でI[12]より前のpictureを参照していることを表す。
I[8]～P[11]のGOPのいずれかのpictureを参照していることに他ならない。I[12]～B[16]のGOPは、I[12]より前のGOPに依存していることを示している。
P[15], B[16]がB[13], B[14]を参照せず、また、I[12]より前のpictureを参照しないならば、I[12]～B[16]のGOPはB[13], B[14]の復号には失敗するが、これらを落とす(dropさせる)ことで、I[12]->B[16]->P[15]という流れを表示することにおいては成功する。[*脚注1]
I[12]～B[16]のような、I-pictureを跨いで他のGOP参照をするB-pictureがあるGOPをOpen-GOPと言う。
また、I[0]～P[7]やI[8]～P[11]のような、I-pictureを跨いでGOPを参照しないで独立しているGOPをClosed-GOPと言う。
14496-12はISOベースメディアファイルフォーマットの規格である。
14496-14はMP4ファイルフォーマット(MP4コンテナ)の規格である。
14496-15はAVCファイルフォーマットの規格である。
MP4コンテナはISOベースメディアというファイルフォーマットを基盤に派生したファイルフォーマットとされている。
AVCファイルフォーマットはMP4コンテナの仕様をAVCを格納する場合について拡張したものである。
すなわち、AVCを含むMP4コンテナというのは 14496-12 <- 14496-14 <- 14496-15 というように依存関係が成立している。
14496-12または14496-14で定義されたいくつかの機能及び特徴(feature)は14496-15においてoverride(上書き)されている。
ランダムアクセスに関わるsync sampleの定義もここでは上書きされている。
14496-15は言っている。sync sampleである条件の一つがIDR-pictureであると。
IDR-pictureとはAVC stream(14496-10)において、I-pictureと同様にそれ単体で圧縮符号化を成しているpictureであるが、データ上でそれより後ろのpictureが、それより前のpictureへの参照を行わないことを保証しているpictureであり、またPOC(Picture Order Count, pictureの表示順のカウンター)をリセットするpictureである。
Open-GOPでのI-pictureは、この条件に当てはまらず、sync sampleという機能を用いてランダムアクセスすることは暗に禁止されている。
(注: H.264/AVCの規格には、そもそもOpen-GOPの概念はない。規格上、いくらでもI-pictureを飛び越して参照できる上、これが為にただのI-pictureとIDR-pictureを区別しているのである。だが、ここでは便宜的にOpen-GOPという用語を持ち出すことにする。)
AVCファイルフォーマットにおいて、IDRタイプのランダムアクセスを制御するのがsync sampleという概念である。
H.264/AVCには他にrecovery pointタイプのランダムアクセスが定義されている。
recoveryという概念の中にはGDR(Gradual Decoding Refreshの略で、漸次復号リフレッシュの意である)というものが定義されている。
GDRは徐々にpicture内の一部を新調して(この一部分は他のpictureに依存しない)、ある程度pictureを復号し終わった段階で、ある地点より前との依存関係から解放されるものである。[*脚注2]
recovery pointタイプのランダムアクセスはroll recoveryというという機能を用いてランダムアクセスを実現できる。
roll recoveryで使用される変数にroll_distanceというものがあり、これは任意にグループ化された先頭のサンプルからどれくらい復号を行えば、最後に復号したサンプル以降が完全な形で復号できるか、ということを示している。
AVCファイルフォーマットでは、グルーピングはrecovery point SEIが付いたサンプルを先頭となるように行う。
これをOpen-GOPに当てはめた場合に、I-pictureより先行して表示されるB-picture以外のグループ内のpictureが、先行するGOPを参照することがないならば、これらのB-pictureを全て復号した時点でrecovery(復元)が完遂されたことになる、すなわちこれらB-pictureの総数に1を足したものがroll_distanceとなる。
しかし、このroll recoveryは実装している既存のオープンソースプロジェクトがないほど、面倒な代物である。
従って、仮にMP4ファイルフォーマット出力側に実装を施しても、それをランダムアクセスの手段として扱える再生系が存在しない、というのが現状である。
なお、roll_distanceでは0の値が禁止されており、実質IDRであるにも関わらず、IDR-pictureとしてエンコーダがみなさずに単なるI-pictureとして扱っている場合にはroll groupとしては扱えず、且つsync sampleとしても扱えない点と、それに対する言及がないあたりに規格上の不備があるとは個人的に思う。
ISOベースメディアファイルフォーマットのアイディアの基礎となったQuickTimeファイルフォーマット(MOVコンテナ)においてはOpen-GOPのI-pictureに対するランダムアクセスの機構が別途定義されている。
Appleの開発者からするとOpen-GOPのI-pictureはkey-frameとはみなせないとのことらしい。
key-frameとはみなせないが、ランダムアクセスを可能にするpictureとして、これをpartial sync sampleと呼ぶ。
partial sync sampleの定義はQuickTime SDKに含まれているインクルードファイル(CIncludes/ImageCompression.h)で確認できる。(ここではpictureをframeという語に置き換えている。)
「partial sync frameはframe間の依存性を部分的に初期化するものである。二枚のpartial sync frameは、その間に存在するdrop不可能な差分frameを復号することは、デコーダに後に続く差分frameの正確な復号を準備させるのに十分である。」
これはOpen-GOPのI-picture直後のB-picture群のみが直後のGOPに依存している、すなわちこのB-picture群がdrop可能な差分pictureであるケースに等しい。
ISOベースメディアファイルフォーマットは、これを基に派生フォーマットを定義させることを想定した規格であり、MP4コンテナもISOベースメディアファイルフォーマットの派生フォーマットの一つである。
ftyp box(Filetype Box)にはbrandという、どんな仕様とその要求を基にファイルが成立しているか、ということと、プレイヤーはそれを見てどの仕様に則ってを再生をサポートするか、について要求される機構を持つ。
brandは複数であってもよくて、ファイルフォーマットの複合体(chimera)を許容している。
従って、brandにQuickTimeのモノを加えることによってそのファイルがMOVコンテナの機能から成り立っていることを示し、且つ、プレイヤーにそのMOVコンテナの仕様を飲んで再生を行うか、または飲まずに無視して再生を行うかを選ばせることが出来る。
つまり、MP4コンテナとMOVコンテナのchimeraを作り、これを明示することで、MOVコンテナの機能に対応したプレイヤーで、ランダムアクセスを行わせることができるのである。
要は、別の規格で簡単な解決策が提示されていることを利用して、その規格に責任を押し付けるというわけである。
/** 現在確認している partial sync sample をサポートする再生系 **/
QuickTime Player
MPlayer
LAVFSplitter
/** 参考資料 **/
ISO/IEC 14496-12:2008
ISO/IEC 14496-14:2003
ISO/IEC 14496-15:2010
Re: handle Open-GOP B-Frame http://lists.apple.com/archives/QuickTime-API/2006/Dec/msg00020.html
QuickTime 7.3 SDK for Windows
[*脚注1]
x264にてOpen-GOPと呼ばれるものの実装は、実はこのような形式を取っている。
GOPの先頭に位置するI-pictureより表示順で先行するB-picture群をdropさせることを前提にすれば、これはこの位置を基準にシークするようなランダムアクセスポイントとして適している。
しかし、このI-pictureはIDRではないため、sync sampleにはならない。
現在のx264のGPACに依存したMP4出力の実装では、このI-pictureをsync sampleとして扱っているので、明らかに規格違反である。
x264の実装の範囲では、このI-pictureはpartial sync sampleの定義に準じているので、partial sync sampleとして扱えばMP4コンテナ的にもMOVコンテナ的にも規格違反は避けられる。
[*脚注2]
x264ではGDRはintra-refreshという呼称で実装されている。
GPACでは未だにroll recoveryを実装していないため、GPACに依存している限り、規格で定義された方法を以てしてランダムアクセスをすることは不可能である。
このx264のGPACに依存した現在のMP4出力では、Recovery Point SEIを付したP-pictureをsync sampleとして扱っている。
勿論、これも明白な規格違反である。
転載元：AVCを含むMP4コンテナのランダムアクセス問題
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。