「フレームの種類」の編集履歴(バックアップ)一覧に戻る

フレームの種類 - (2006/08/18 (金) 19:52:43) のソース

*基本
**Iフレーム
***完全な一枚絵。
厳密には知らないが、JPEG((これもISO規格ではある))かなにかと思えば良い。
Iフレームが多いほど画質が良く、サイズがデカイ。
シーク(早送りや巻き戻し)はIフレームを基準にする。
[[Pフレーム]]や[[Bフレーム]]は、Iフレームを基準に生成される。
GOP(グループ・オブ・ピクチャ)の基準点になる。
GOPは[[MPEG-2]]では約0.5秒程度。

**Pフレーム
***直前のフレームとの差分。アニメの口パクのようなもの。
動いた部分だけの絵。別名時間軸圧縮。
IフレームにPフレームを乗っけると、「次のフレームの映像」になる。
I P P P P P P ,,,とすることで、
I I I I I I I  ,,,よりもデータが縮む。
この「I P P P P P P」がGOP。

[[MPEG-1]], [[MPEG-2]], [[MPEG-4]]([[H.264/AVC]]含む)が使う。

**Bフレーム
***直前直後のフレームとの差分。これがあると
+ 劇的に[[圧縮率]]が向上し、
+ [[互換性]]がやや劣(る場合があ)り、
+ [[再生]]時に[[CPU]]の負荷が大きくなる

***傾向がある。ちょっと絵面が想像しにくい。搦め手から説明。

最大Bフレーム数=1の場合、
画面に表示する順番は、" I B P " だが、データの中には、" I P B "の順番で入っている。
デコーダは、Bを[[デコード]]する前に、まず[[Iフレーム]]と[[Pフレーム]]を[[デコード]]する必要がある為。
直前直後のフレームを先に読み込んで、その2枚を元にBフレームを[[デコード]]する。
出来上がったら(=画面に表示できる信号になったら)" I B P " に並べ替えて出力。

別名、時間軸双方向圧縮。
IとPだけよりうんと縮むが、実はなんで縮むのか厳密には解っていないのだとか。

[[MPEG-1]], [[MPEG-2]], [[MPEG-4]]の[[ASP]]以上と[[H.264/AVC]]のBaseline profile以外で使える。

[[MPEG-1]], [[MPEG-2]]にはBフレームは存在しない。

***【参考】[[AVI]]とBフレーム
Bフレームは本来は[[AVI]]に入れる事ができない。
Winで[[AVI]]作成に長く使われたvfw(Video for Windows)は、「1フレーム in, 1フレームout」の原則がある。
この原則では、[[デコード]]の際にIとPを読み込んで、次にBを読み込むと、バッファからなにか1枚出力しなければならない。
これではBフレームの[[デコード]]ができない。[[エンコード]]でも同様。

この制限を回避して[[MPEG-4]] - [[ASP]](アドヴァンスド・シンプル・プロファイル、DivX, Xvid, 3ivxなど)映像を[[AVI]]に突っ込むために、PとBを1枚のフレームと偽ってvfwを騙したり(packed bitstream)、動画のアタマにダミーフレームをくっ付けてみたり(delay frame)という裏技が開発された。これはややこしいが、枯れており、広く普及した為、[[MPEG-4]] = [[XviD]](互換コデック).aviというイメージの元となった。

しかし、[[H.264/AVC]]のBフレームはさらに複雑化したため、さすがに[[AVI]]では対応困難になった。また、新しいDirectShowベースのエンコードではこの問題は存在しない事が、ややこしさの一因のようだ。
これらの結果、[[AVC>H.264/AVC]]-in-[[AVI]]はWinでも基本的には廃れつつある。


*[[H.264/AVC]]の特殊なフレーム
**IDRフレーム
***新種のIフレーム
これまでは、Pフレームは直前のIフレームを元に生成するものだったが、[[H.264/AVC]]では、直前より前のフレームを基にPフレームを生成しても良くなった。
この結果、GOP構造が崩れる。
Iフレームは必ずしもGOPに束縛されないものとなり、必ずしもシーク可能なものでは無くなった。
IDRフレームはこれを解決する為に考案されたもの。
後続のPフレームに、自分より前にある全フレームを参照禁止にする。

**Bフレーム関係
***[[H.264/AVC]]では、Bフレームが複雑化。
以下のオプションが規格書に存在する模様。
-adaptive Bフレーム:Bフレームの使用枚数を映像内容に応じてエンコーダが自動で決める。
-arbitrarily frame order:データの中のフレームの順番をエンコーダが「自由に」決める。
これらを使うとQuickTime Playerで再生できなくなる(iPodはそもそもBフレーム非対応)ので関係ないが、x264cliや[[MEncoder]]では使える。現状、Macでこうした.mp4を見るには、[[MPlayer]]か[[VLC]]。