Delay_frame 除去実験 その2　yadif=0、 -ofps 30000/1001の場合　ageha was here

1.1. 現象

Bフレーム関連設定は、bframes=3:b_adapt:weight_b:b_pyramid
下図は MovieVideoChart 。Apple-H.264で作成した場合は最上段「Frames in Track」にも映像が出る。
映像開始点が2フレームずれる。(1/30)*2≒0.066秒。
ここまではpullupのケースと同じだが、そこから2枚、緑のフレームが入る。真の映像開始点は0.133秒目。
緑のフレームはbitを消費している為、rawvideoの段階でDelay frame以外にヘッダと実データを持ったフレームが2枚入っている。

図１）緑フレームはIDRとP。３枚目がPとなっているため、カットできねぇだろこれわというカンジ。


図２）３枚目がsync（IDR）となっているケースもある。これはGOP単位編集できる可能性がある。

1.2.対策

図１のやばそうなほうで実験してみた。
１）mp4box -rawでrawvideo抽出。

$ mp4box -raw 1 kinshubanya_061203.mp4

２）fpsを指定して映像のみ.mp4に。

$ mp4box -fps 29.970030 -add kinshubanya_061203_track1.h264 -new kinshubanya_061203_track1.h264.mp4

３）muxmovie -startAtで映像にスタートディレイを設定。-startAtは時刻指定なので近似値で良い。

$ muxmovie -startAt 00:00:00.14 -self-contained kinshubanya_061203_track1.h264.mp4 -o out kinshubanya_061203.h264.mp4.mov

４）QuickTime Player Proで音声貼付け、.mp4へ書き出し。映音とも「そのまま」
　映像を全選択して「選択範囲に追加」。「選択範囲に調整して追加」のほうがデータ表示上のDurationは揃うが地味に音が濁るケースが有る。

1.3.結果

人を不安にさせる表示だが、QuickTime Player Pro、VLC 0.8.6とも再生は平気。
QuickTime Player Proは白紙フレームを表示する事も、開始点で早回しを押すと末尾に飛ぶ事もなく、まぁ平気。
終点で白紙フレームを表示する事があるが、これは実データを２コマも飛ばしてるわけだし。
再生中にマウスで任意の点に飛ぶとしばらくの間カクカクになるなど全般にトリックプレイに弱い印象があるが、これは元のファイルをQuickTime Player Proで見る際も同様。
VLCは開いた直後に一瞬緑フレームを表示する事がある。

図1、2を見た後では、意外になんとかなるもんだという印象を持ったが、かなりやばめなファイルである事は確実。

Avidemuxにはより実験的なmcdeintが移植されていながら、yadifが移植されて無いので奇妙に思っていたが、こうゆうことですか。
手許のファイルを20個ほど MovieVideoChartで開いてみたが、yadif=0固有の現象のようだ。フィールドオーダーの分析でアタマ２枚喰ってしまうのだろうか。
30fpsで他に有用なインタレ解除となると、filmdintかpp系という事になるが、、、いっそインタレ保持かなぁ。