「フレームの種類」の編集履歴（バックアップ）一覧はこちら
「フレームの種類」(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フレーム
***直前直後のフレームとの差分。
ちょっと絵面が想像しにくい。搦め手から説明。
最大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以外で使える。
&html(<strike>[[MPEG-1]], [[MPEG-2]]には無い。</strike>)
***【参考】[[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>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]]。
*基本
**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フレーム]]を[[デコード]]する必要がある為。
直前直後のフレームを先に読み込んで、その２枚を元に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>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]]。
