フレームの種類 - Mpeg on Mac

基本

Iフレーム

完全な一枚絵。

厳密には知らないが、JPEG(*1)かなにかと思えば良い。
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フレーム

直前直後のフレームとの差分。これがあると

1. 劇的に圧縮率?が向上し、
2. 互換性?がやや劣（る場合があ）り、
3. 再生時にCPU?の負荷が大きくなる

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

最大Bフレーム数=1の場合、
画面に表示する順番は、" I B P " だが、データの中には、" I P B "の順番で入っている。
デコーダは、Bをデコードする前に、まずIフレーム?とPフレーム?をデコードする必要がある為。
直前直後のフレームを先に読み込んで、その２枚を元に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を読み込むと、バッファからなにか１枚出力しなければならない。
これではBフレームのデコードができない。エンコードでも同様。

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

しかし、H.264/AVCのBフレームはさらに複雑化したため、さすがにAVIでは対応困難になった。また、新しいDirectShowベースのエンコードではこの問題は存在しない事が、ややこしさの一因のようだ。
これらの結果、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。

---

*1 これもISO規格ではある