MEncoderでBフレームを使うとムービー冒頭にDelay frameが入る。
これはMEncoder 固有のバグであり、もちろん規格外であり、地味なA/V desyncを産む。
MEncoder GUIとしてスタートしたMeGUIが、あんまMEncoderにチカラ入ってねぇように見えるのは、これの所為かもってくらい
古くさいバグ。
手許ではA/V desyncを知覚できない事から放置していたが、
avc1Decoder の登場によりHigh Profileでも
muxmovieでの対策が可能になった。
そこで、手許で作成したx264+faac.mp4からDelay frameを除去する実験。
使用ツール
pullup、-ofps 24000/1001の場合
1.1.現象
Bフレーム関連設定は、
bframes=3:b_adapt:weight_b:b_pyramid 下図は
MovieVideoChart 。
映像開始点が0.083秒ずれている。≒(1/24)*2なので、2フレームぶん、タイムスタンプが後方にずれている。
このタイムスタンプのずれ自体は問題では無い。後述するが、Apple-H.264でB付き.mp4を吐いた場合も同様だから。
問題はApple-H.264で作成した場合は最上段「Frames in Track」にも映像が出る事。
原因は、rawvideoの段階で冒頭にいわゆるDelay frame、ヘッダだけで実データが無いもの、が入っているからと思われる。そんなの規格外だし、そもそもMEncoder固有のバグだ（AviSynth to x264cliには無いらしい）。
これは一旦映像だけを抽出し、muxmovieで処理できる。
1.2.対策
１）mp4box -rawでrawvideo抽出。
$ mp4box -raw 1 ケロロ軍曹_061201.mp4
２）fpsを指定して映像のみ.mp4に。
$ mp4box -fps 23.976025 -add ケロロ軍曹1_track1.h264 -new ケロロ軍曹_061201_track1.h264.mp4
３）muxmovie -startAtで映像にスタートディレイを設定。-startAtは時刻指定なので近似値で良い。
$ muxmovie -startAt 00:00:00.09 -self-contained ケロロ軍曹_061201_track1.h264.mp4 -o out ケロロ軍曹_061201_track1.h264.mp4.mov
４）QuickTime Player Proで音声貼付け、.mp4へ書き出し。映音とも「そのまま」
映像を全選択して「選択範囲に追加」。「選択範囲に調整して追加」のほうがデータ表示上のDurationは揃うが地味に音が濁るケースが有る。
1.3. 結果
下図の通り、QuickTime Player Pro/Apple-H.264で作成したものと表示が揃った。
最上段のFrames in Trackを正しく表示できる。
QuickTime Player Proの表示（林檎+Jのデータレート等）も正常表示。
開始フレームのタイムスタンプが0.083のままな事に注意。 |
QuickTime Player Pro、Apple-H.264、30fpsで作成、
フレーム並べ替え（bframes=1相当）有り。
開始フレームのタイムスタンプが0.033（30fpsの1フレームぶん）な事に注意。 |
 |
 |
b_adaptの効果でB枚数は不規則。bframes=3にもかかわらずのっけからIPBP。
syncフラグがIDR。I/P/B/参照Bなどの区別は出ない。
rawvideoを経由しているせいか、droppableフラグも無し。
少なくともQuickTimeインフラ上ではトリックプレイや低速CPUに弱い筈だ。 |
bframes=1、nob_adapt相当なのでBは規則的に入る。
syncフラグがIDR。Bにはdroppableなるフラグもついている。
トリックプレイや低速CPUに強い筈だ。
このへんの用語は映像コデック側の理屈よりなにかと「同期」を意識したものが多い。
Quick"Time"はやっぱ時間軸のインフラなのだろう。 |
1.4.疑問点
QuickTime Player Pro、Apple-H.264で作成した場合も1st Frameのタイムスタンプが0では無い。音声は、上記1.2.4）の段階で.movに素材から抽出したaiffを貼付け、QuickTime Player Proに任せるほうが安心かも知れない。
スポンサーサイト
