AVI ファイル形式
Audio Video Interleave。Microsoft の古典的な RIFF 動画コンテナ。
- MIME タイプ
- video/x-msvideo
- 拡張子
- .avi
- カテゴリ
- 動画
マジックナンバー（ファイル署名）
| 0x00000000 | 52494646 | RIFF | RIFF container |
| 0x00000008 | 41564920 | AVI | 'AVI ' form type |
AVI 形式について
AVI は Microsoft が 1992 年に作った動画コンテナで、土台は RIFF です。WAV と同じチャンク構造で、どのチャンクも 4 文字の識別子、リトルエンディアン 32 ビットの長さ、そしてその長さぶんのペイロードでできています。設計は 1 ページのコードで解析できるほど単純で、その単純さがすべてを物語ります。AVI には可変フレームレートというまともな概念がなく、今どきの音声へのコンテナレベルの対応もなく、字幕トラックもトラックごとの言語もなく、32 ビットのサイズフィールドは OpenDML 拡張が回避策を作るまでファイル長に厳しい天井を課していました。代わりに持っているのは完全に固定されたヘッダです。仕様が hdrl リストを先頭に、そのリストの中でメインヘッダチャンクを先頭に置くことを要求しているので、AVI の幅・高さ・フレームレートは常に同じバイトオフセットにあります。
ヘッダーの構造（バイト単位）
| オフセット | 長さ | フィールド | 意味 |
|---|---|---|---|
| 0 | 4 | RIFF signature | 52 49 46 46、ASCII の RIFF。WAV や WebP をはじめ Microsoft 時代の他の形式とも共有しているので、これ単体で分かるのはチャンク構造であって形式ではありません。 |
| 4 | 4 | RIFF chunk size | このフィールドより後ろ全体のバイト数をリトルエンディアンで表したもの、つまりファイルサイズから 8 を引いた値です。AVI のサイズはすべてリトルエンディアンで、QuickTime ファイルを見ているのではないと確かめるいちばん速い方法になります。 |
| 8 | 4 | Form type 'AVI ' | 41 56 49 20。末尾の ASCII スペースは 4 文字コードの一部です。このファイルを WAV でも WebP でもなく AVI にしているのはこのフィールドで、素朴な文字列比較が取り逃すのはこのスペースのせいです。 |
| 12 | 4 | LIST identifier | 4C 49 53 54。RIFF はチャンクをリストにまとめますが、仕様はヘッダリストがファイル中で最初のリストであることを要求しています。以下のオフセットが予測可能なのはそのおかげです。 |
| 16 | 4 | LIST size | ヘッダリストの長さをリトルエンディアンで表したもので、直後に来る 4 文字のリスト型は数えますが、この 4 バイト自体は数えません。メインヘッダと、トラックごとのストリームヘッダブロックをカバーします。 |
| 20 | 4 | List type 'hdrl' | 68 64 72 6C。このリストがヘッダリストであることを名乗ります。仕様上どのデータよりも前に来ることが要求されていて、MP4 とは逆の配置です。途中で切れた AVI でも寸法だけは正しく報告されるのはこのためです。 |
| 24 | 4 | Chunk identifier 'avih' | 61 76 69 68、メインの AVI ヘッダです。hdrl の中の最初のチャンクでなければならないので、整形式のファイルでは必ずこのオフセットにあります。 |
| 28 | 4 | avih chunk size | リトルエンディアンで、常に 38 00 00 00、つまり 56 バイトです。この後ろに続く 14 個の 32 ビットフィールドの合計です。これ以外の値なら、ヘッダが壊れているか、書き手が標準外のものを出力しています。 |
| 32 | 4 | Microseconds per frame | リトルエンディアンで、コンテナレベルでフレームレートを述べる唯一の場所です。00 01 86 A0 をリトルエンディアンで読むと 100000 で、毎秒 10 フレームになります。AVI には可変レートを表す手段がまったくなく、これがこの形式で最も影響の大きい制約です。 |
| 36 | 4 | Maximum bytes per second | このファイルが必要とすると見込まれるデータレートの上限を、1 秒あたりのバイト数で表したものです。メディアが追いつけるかどうかをプレイヤーが判断できるようにする意図でしたが、今日では事実上の参考値です。 |
| 40 | 4 | Padding granularity | データチャンクをパディングする際のアラインメントをバイトで示します。CD-ROM 再生向けに書かれたファイルでは 2048、それ以外のほぼすべてではパディングなしを意味する 0 です。ここに挙げているのは、省くとこの表に説明のつかない 4 バイトの穴が空くからです。 |
| 44 | 4 | Flags | ビットフィールドです。ビット 4 は索引チャンクがあること、ビット 5 は再生順の決定に索引を使うべきこと、ビット 8 はインターリーブされていること、ビット 16 はライブ収録されたことを示します。効いてくるのは索引のビットで、これが無いとシークが線形走査に成り下がります。 |
| 48 | 4 | Total frames | ファイルの総フレーム数をリトルエンディアンで。エンコード完了後に書かれるので、中断された録画ではここが 0 か古い値のまま残り、フレームは全部あるのにプレイヤーの表示する再生時間が間違ったものになります。 |
| 52 | 4 | Initial frames | インターリーブされたファイルで、音声が映像より何フレーム先行しているかを示します。ライブソースから収録したもの以外では 0 で、0 でない値をプレイヤーが無視することが、ファイル全体を通した固定の音ズレの原因のひとつになります。 |
| 56 | 4 | Stream count | hdrl の中に続くストリームヘッダブロックの数です。映像 1 つと音声 1 つで 2 が通例ですが、形式としてはもっと持てますし、古いファイルには今どこもデコードしないテキストや MIDI のストリーム用に 3 つ目が入っていることもあります。 |
| 60 | 4 | Suggested buffer size | プレイヤーに必要だと書き手が考える読み込みバッファの大きさをバイトで示し、通常はファイル中で最大のチャンクのサイズです。純粋な参考値で、実測ではなくきりのよい 1 メガバイトが書かれていることがよくあります。 |
| 64 | 4 | Width in pixels | リトルエンディアン。これは絵の大きさについてのコンテナ側の主張であって、映像ストリーム自身が述べる値と常に一致するとは限りません。両者の食い違いは、古いキャプチャ機器が作ったファイルで実際に起こります。 |
| 68 | 4 | Height in pixels | リトルエンディアンで、幅とまったく同じ符号化です。オフセット 64 と合わせたこの 8 バイトが、AVI の寸法を読むいちばん速くて確実な方法になります。準拠したファイルなら必ず固定位置にあるからです。 |
| 72 | 16 | Reserved | 32 ビットワードが 4 つ、すべて 0 です。これで 56 バイトのメインヘッダが終わるので、次のチャンクはオフセット 88 から始まります。通常は最初のストリームのヘッダを収める strl リストです。 |
似た形式との見分け方
| 紛らわしい形式 | 見分け方 |
|---|---|
| WAV | 同じ RIFF コンテナで、オフセット 8 のフォームタイプが違います。AVI の 41 56 49 20 ではなく WAVE の 57 41 56 45 です。オフセット 7 までは同一なので、先頭 4 バイトを見て分かるのはこのファイルが RIFF だということだけです。フォームタイプから先の配置は完全に分かれます。WAV はいきなり fmt チャンクへ行き、AVI は hdrl リストを開きます。 |
| WebP | こちらも RIFF で、オフセット 8 が WEBP の 57 45 42 50 です。3 つとも hex ダンプの冒頭が同じ 4 文字の ASCII とリトルエンディアンの長さなので、ぱっと見の紛らわしさは本物です。動画と音声と静止画を分けているのは、オフセット 8 のバイトだけです。 |
| Matroska | 共有しているものはありません。Matroska はオフセット 0 が 1A 45 DF A3 で始まり、全体を通して可変長のサイズを使います。この 2 つを組で覚えておく価値があるのは、古い AVI を MKV へ remux するとフレームは可逆コピーのまま、可変フレームレートと字幕トラックときちんとした索引が手に入るからです。 |
| OpenDML AVI 2.0 | 実質的な 2 GB と 4 GB の上限を取り払った拡張です。そういうファイルも冒頭は上と同じく RIFF と AVI で始まり、違いは後ろに出てきます。フォームタイプが AVI ではなく AVIX のトップレベル RIFF チャンクが追加され、それぞれがストリームの続きを運びます。最初の RIFF チャンクで読み止めるリーダーは、大きなファイルの冒頭部分だけを再生し、壊れているのではなく短いファイルだと報告します。 |
よくある壊れ方
- idx1 索引チャンクの欠落や途中切れ。これはファイルの末尾にあるので、中断したダウンロードや打ち切られた収録で真っ先に失われます。チャンク自体が自己記述的なので映像は最初から再生できますが、シークは失敗するか、1 回のジャンプに数秒かかる線形走査に落ちます。
- 2 GB と 4 GB の壁。オフセット 4 の RIFF サイズフィールドは 32 ビットなので、OpenDML の AVIX 拡張を出力しない書き手は、ファイルが上限を超えた時点で値が単純に回り込みます。できあがるものは整形式で、数値だけが間違っています。プレイヤーはディスク上のファイルよりはるかに小さいサイズを読み、早々に停止します。
- オフセット 48 のフレーム数の誤り。エンコード完了時に書かれるので、クラッシュしたり強制終了したりした収録では 0 か、書き手が推測した値のまま残ります。フレームはすべて存在して再生もでき、表示される再生時間だけが無意味な値になります。再エンコードではなくヘッダの修復で済む話です。
- 音声と映像のずれ。AVI は固定レートのチャンクをインターリーブする設計なので、そもそも想定されていない可変ビットレートで符号化された音声は、長いファイルにわたって映像に対する誤差を積み上げます。最初の 1 分では聞き取れず、20 分目にはひどくずれていて、ヘッダにはその兆候が何ひとつありません。
- もう誰も持っていないコーデック。各ストリームヘッダの 4 文字コードは DIVX・XVID・MP42・IV50 といったものを名指ししますが、その手のデコーダの多くは、同梱していた OS と一緒に消えました。コンテナは無傷でオフセットもすべて正しく読めます。デコーダが無いから再生できないだけで、修復ではなくトランスコードで解決します。
この形式の現在地
AVI は消えることを拒み続けるレガシー形式で、新規の作業には少なくとも 15 年前から不適切な選択です。制約は偶発的なものではなく構造的なもので、固定フレームレートのみ、字幕トラックなし、トラックごとの言語なし、今どきの音声なし、拡張で取り繕った 32 ビットのサイズフィールドといった具合です。MP4 も Matroska もその全部を解決しています。今でも出会うのはアーカイブの中で、ビデオカメラのキャプチャ、古いキャプチャカードでの画面収録、テープからデジタル化した映像、そして一度書かれたきり見直されないファームウェアを積んだ科学用・産業用カメラの出力です。無圧縮や軽い圧縮の AVI は、いくつかのキャプチャ経路で今も一時形式として使われています。チャンクと長さを書くことは、機器がリアルタイムでできる処理としてほぼ最も安いからです。残しておきたいものなら、Matroska へ remux すればフレームには手を触れないまま、このコンテナに欠けているものをすべて手に入れられます。
AVI ファイルをこのサイトで開く
どれもブラウザ内で動きます。ファイルが端末から出ることはありません。
関連する形式
AVI と混同しやすい形式です。先頭バイトを見比べてください。