07/12/16 14:11:02 /YCnmG+P
>>87 以降
まるも氏までこられるとは。
私がparserの話を出したのは、MakKi氏のデコード方法がストリームデータを一旦蓄積するデコードモデルだったので、
h264 parser辺りにその仕事を割り振る感覚で出しました。
まるもさんはDirectShow前提のモデルで話しているのかな。
たとえば>>87の処理では、デコーダがレンダラーのFIFOで利用すべきタイムスタンプを設定したときに、その時刻は
現実世界では既に経過してしまっている、という矛盾が発生するのではないですか？
現状、DirectShowのレンダラーはがんばってその時間に近づけようとしてくれるので、この場合は再生直後が早送り
になってしまうはずなんですよね。
>>88 のMP4においては、MP4 Splitterの実装を見てみないと正確に書けないところがありますが、MP4のCTS/DTSの
仕組みを考慮すると、Splitterは指示された「時刻」に該当するCTSのサンプルを見つけ、そのCTS以前に存在する
IDRフレームまで遡り、サンプルの格納順にDTSが「時刻」になるまで取得したサンプルを、CTSの表示時刻をつけ
てデコーダに送っているはずっと… あとは連続した再生用に直近で取得したサンプルの位置を保存して無駄なFetch
を回避している感じかな。
edtsとか無視しているんで、こんなところじゃないですかね。
実際、この動作を狙って作られたのがtc2mp4ModやDTSRepairであり、それで作成されたMP4はまさにそのように動い
ているので。
エンコにかける青春スレも最近の記事は読ませてもらいましたが、そこであがっていた100カウントするMP4がこれで
したね。まだ残っていますので、ご覧になってみては？