AVIからMP4へのmuxには潜在的な問題があります。特に、Bフレーム（B-VOPs、bi-directional
encodingとも言う）を使っている場合は注意が必要です。
- 1) "delay
frames"
- 古いVFW インターフェイスに内在する問題。今でも使うコデックがある (XviD,
DivX5)。これらのコデックでb-frameを使ってエンコードする場合、"delay frames"を自動的にドロップするのはVirtualDub/Mod だけだ。
- 2) "packed
bitstream"
- 本来はb-frameを扱えないAVIコンテナに内在する問題。PBは DivX5
（連続b-frame1がセットの時のみ）が使う。また、新しいXviDビルドはデフォルトで、b-frameを他のフレームと"パック"する（XviD
オプションでPB optionのチェックをちゃんと外す事）。AVIとB-frameに関する詳細はこちら（＊試訳＊）。
- 3) "userdata"
- XviD
と DivX PBストリームがPBを使っている場合にその存在を示すフラグ。一部のデコーダはこのフラグをデコード
する（＊たぶん映像の一部として＊）。
- 4) "vol"
- AVIで全てのキーフレーム
に付加されているものだが、MP4ではムービーデータとは別個にしてやる必要がある。
- 5) "ctts"
atom
- MP4にb-frameをmuxする際に書き込む必要がある [1]。
現在、これら全てを正しく扱えるのは
3ivx
mp4 muxer と GPACの
MP4Box だけだ！[1]
AVIからMP4への変換にはこの二つ以外使わないように。packed
bitstreamがある場合や、そもそもそのAVIを作ったエンコードアプリがなんだったか
/ どんなb-frame関連オプションを使ったか判らない場合は特に。さもないと規格適合性が不完全なMP4ファイルが出来る
可能性が非常に高くなる！
[1] MP4コンテナでBフレームを使う場合、ctts atomの他にEdit
Boxなるものを書き込む必要がある模様。raw
video.264からMP4を作成する場合、手許のMP4boxでは冒頭に白紙フレームが1～２枚入る。白紙フレームが出るのはQuickTime系の
プレイヤのみだが、uenoB
さんによるとこれはQT系の挙動が正しい。傾向と対策はtag:
白紙フレーム参照。
原文：MP4 FAQ - Doom9's Forum Last edited by bond :
28th April 2007 at 15:32.
※以下メモ
- 6）ゼロビット・フレーム（仮称）
- MEncoderは、完全に同一のフレームが連続すると、コンテナヘッダに「前のフレーム繰り返し」と書き込んで、画像データを生成しない。しかしこれはAVIが前提の仕様なので、AVIからraw video.264/xvidを抽出したり、または直にそれらを吐かせると、総フレーム数が不足する事がある。症状としては不規則な音ズレ。Bの有無とは無関係。
回避するには-vf チェイン末尾にharddupを書く必要がある。
AVIコンテナに「前のフレーム繰り返し」と書くだけで、該当フレームの実データをゼロにするこの手法は、いわゆる120fps.AVIなどでも使われ
ている可能性がある、、、と思う。
※これら多彩な「AVIハッキング」が [MPEG-4 ASP].mp4の普及にとって「落とし穴」になったもののように思える。PS3, Xbox 360ともにMP4サポートはMPEG-4 SPまたはH264/AVCという変則的なものになっているなど。
