2005年11月07日

AVIからH.264を抽出すると3フレームずれる

【リンク】 MKVToolNix 1.6.0 has been released
【タグ】[XviD-in-AVI][AVC -in-AVI]

リンク先はMKV作成スレだが、AVIか らH.264を抽出すると3フレームずれるとの話が出ている。

スレッド内の#148。stephanV氏の発言。(2005/08/29)
Quote:
Originally Posted by Liisachan
思いついたんだけど、最終目的がMKVなら、XviDエンコードの際にもMP4を使った方が良いんじゃないか。
mkvmergeはMPEG-4 Part2 Video in MP4を受け付ける筈だし、少なくともHaali Splitter (それからたぶん MPCも)は再生できると思う。 後でテストしてみよう。
関係あるかどうか、、、
その方式でもMP4からのmuxはVFWモードになるし、Native modeはAVI経由でも同等にサポートされてる。(間違ってたらMosuさんに訂正してほしい。)
Quote:
@stephanV: I see. Thanks for info. But can't the encoder (x264) add 3 null frames at the end of the clip when it decides to put the 'empty chunks at the beginning of avi file'?
過去にはできたが、(今は?)そうはしない。

empty chunkはエンコードの開始点に書き込まれる。終了点じゃない。有名なVFWの"1 frame in - 1 frame out"制限によるものだ。
基本的にVirtualDubはx264へのフィードをフレームから始めるが、x264はb-frameエンコードの為にバッファを必要とする。x264 は、出力をバッファリングしている間は0 byte frame を出力する(またはなにも出力しない)。だからVirtualDubも0 byte frameを書き出す。
VirtualDubはx264に全フレームをフィードし終えると終了する(*フィードを?*)。そして、まだx264のバッファに溜まっているフレーム は永遠に天国と地獄の狭間を漂う事になる(要するに失われる)。

これを解決するには2つの事が必要だ。

1. VirtualDub にx264のバッファリング終了を検出させる。これで正しい位置からファイル書き出しを始める。
2. 全フレームをフィードし終わってもVirtualDub を終了させない。x264のバッファが空になるまで待たせる。

この両方で恐らくちょっとしたwork(*ソースコードの改訂?*)が必要だ。

自分は、冒頭のempty chunkがそう大した問題とは思わない。簡単に除去できるものだし、尻のmissing frameも気にならない。

でもMKVの場合は、真剣にx264cliのMKV-出力機能を考えるだろう。そっちのほうが確実だ。

続く#149。Mosu氏のレス。(2005/08/29)
Quote:
Originally Posted by stephanV
関係あるかどうか、、、
その方式でもMP4からのmuxはVFWモードになるし、Native modeはAVI経由でも同等にサポートされてる。(間違ってたらMosuさんに訂正してほしい。)
まったくその通り。
ASP ( = MPEG-4 part 2) では VfW モードがデフォルトだ。素材のコンテナ形式は関係ない (AVI, OGM, MP4)。native モードを使うには "--engage native_mpeg4" を指定するか、native ASP track を Matroska fileからmuxする必要が有る。

AVC はまた別。
__________________
Latest mkvtoolnix is v1.6.0 (non-Unicode)
Mosu氏はさらに#152で、XviD-in-AVIは非常に枯れたハッキングでほとんどの ツールでサポートされているから心配ご無用と述べている。
さて原文の"supported by every tool"にMacのQTPが含まれているかと言うと、ないだろうな。

んで、"AVCはまた別"としたが、原文は" For AVC things are different."ニュアンスが少し違うかもしれない。

考える。

MEncoderにVFWは存在しない。だから最初はこの問題は関係ないと思った。しかしMEncoderは元々AVI出力に特化したものだ。
冒頭の3フレームは無視するのがxvid+mp3.avi再生ソフトの(ひいては世にあるXvid+mp3.aviの)「デファクト」であるならば、 VFWの存在しない世界でも、b付きエンコードする時には、冒頭にnull frameを3枚入れるのが「妥当な実装」ってものだろう。
MEncoderは、AVC.AVIであれAVC.264であれ、冒頭にempty chunk(もしくは、余計な3フレーム)を付けてしまうのかも知れない。

これなら以下の現象が、両方説明できる。

・MEncoder(すなわちffmpegX0.0.9t)でbframe=1を使ったものはQTP7で加工不能になる。
・AとVの持続時間に0.1秒台のズレが出る。23.976fpsなら概ね3フレーム分に相当。

こいつを除去する方法を探しだせれば、ひょっとしたらB付きでもQTで加工できるようになるかも知れない。

なお、0.1秒の差は、でかい。特に実写のリップシンク。音楽モノでは許されまい。
音楽製作ソフトなどでは1/3ミリセカンドまで気を使うらしいから。
アニメで気になった事は無いのだが、やっぱ、、、なんつうの?もったいないというか、作った人に悪いな感が漂うので、なんとかしたいところ。
Disneyのファンタジアなんか、まぁTVでやる事はないだろうが、致命的だろう。

他の問題。
・音ズレ防止の為に一旦AVIで吐くってのは、問題を複雑化させるリスクがあるかもしれない。どの程度のリスクか決めるには、もっと知識が要る。
・ffmpegX版は古い。というか、MEncoderにせよffmpegにせよ、Macでちゃんと動く頃にはCVS版のソースコード〜ユーザの大半は x86機〜はずっと進化している。
posted by ばる at 21:32| Comment(0) | TrackBack(0) | mencoder-x264 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前: [必須入力]

メールアドレス: [必須入力]

ホームページアドレス: [必須入力]

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。