※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。

基本

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-4H.264/AVC含む)が使う。

Bフレーム

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

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

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


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

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

MPEG-1?, MPEG-2, MPEG-4ASP?以上と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-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を見るには、MPlayerVLC