preAudio,preVideo
VolMaxのうち、もっとも注力したのは、preAudio,preVideoです。DirectShowをC#のプログラムで使用して、それぞれ音声、映像をデコードします。C++でファイル出力用フィルタを作って、インストールするのが普通の方法のようですが、「C#」と「フィルタをインストールしない」ことを目標にしました。
また、パイプ（標準入出力のリダイレクト）で映像を受け渡すようにもしました。生映像をファイルに書いてから渡すと、非常に大きな容量になるのを回避しようとしました。
■なぜDirectShowでデコードするのか
私も最初は以下のように考えて、NSVSplitなどを作りました。
１．ファイル構造を調べて、直接ストリームデータを切り出せば高速化できる
２．できるだけ、他のソフトウエアを必要としないようにしたい
しかし、音がズレたり、プツプツするのに、「汎用的な解決方法がないこと」が分かってきました。たとえば、固定フレームレートの動画ファイルの場合、音声データを集めると、映像の再生時間より短いことがあります。コンテナが映像と音声のペアを管理できる場合には、「データがないことが無音を表現している」ことによるのだと思います。MP3の音声の場合、1フレームが26ms固定のものが使われています。映像が29.97fpsなどで固定なら、無音の時間は、音声の単位である26ms未満になりえるので、もともと表現することができません。
実態はもっと複雑で、コンテナ、コーデックの組み合わせごとにそれぞれの事情があるものと考えられます。
どんな動画ファイルも、ベストで再生できるように考えられていることは確かだと思います。再生困難で、見苦しいものをわざわざ作る理由はありません。もっとも普及しているDirectShowの再生環境への対応も必ずあるはずだと思い至りました。
音声を「ファイルから抽出してPCM化」したものと、「DirectShowでPCM化」したものは、時間的に同じでない。と言う理解に基づいています。
おそらく、映像についても同じようなことがあると考えています。良く理解していませんが、DirectShowの世界では、コンテナ、コーデックの組み合わせごとに、時間を刻むものがあって、その刻みに応じて出力しているのだと思って（期待して）います。
■なぜ音声をPCMファイルにしたか
- 音量を調節するためにピークを見つけるため
- タイムスタンプに隙間がある場合補間する必要があるため
■なぜ映像をYUY2にしたか
YUY2も圧縮のうちかもしれないが、そのままレンダラーに入力できるので、ここでは生データと考える。DirectShowとffmpegの両方にあるものが候補。
YUY2、RGB24の順に使われるようにした。
■preAudioのコマンドラインオプション
preAudio in_file [-o out_file] [-at n] [-m media_info_file] [-log log_file]
n_file ：入力となる動画ファイル
-o out_file ：出力する音声ファイル（PCM）
-at n ：音声トラックの指定※1
-m media_info_file ：出力するメディア情報ファイル
-log log_file ：ログファイル名
※1 数字の場合トラックの番号(ゼロから)。文字の場合、指定文字列が含まれるトラック。（大文字小文字区別しない）。
スプリッタが音声出力を複数持つ場合は、Pin名に対して、前述の方法で音声を選択する。
スプリッタが音声出力を1つしか持たない場合は、IAMStreamSelectを実装を確認する。実装している場合には、
Ihfo()メソッドが返すストリーム名に対して、前述の方法で音声を選択する。
Pin名、ストリーム名には、命名法が決まっていない。フィルタの作成者次第。そのまま表示して、人が選択するのが使い方のよう。
名前が無いこともある。日本語のこともありえるものと考えられる。
atが指定されない場合は、Jを含むトラックを選択する。
■preVideoのコマドラインオプション
preVideo media_info_file [-log log_file]
media_info_file ：出力するメディア情報ファイル
-log log_file ：ログファイル名
■注意
１．DOS窓で使用していて、スクロールバーを左ボタンで掴んだままにするとアボートする。デコード結果のフレームを受信する箇所の時間監視でエラーを検出する。この時間監視の要否は良く分からないが、当面このままにする。
２．同様のことが、おそらくパソコンの高負荷の場合も起こる可能性がある。数秒以上、制御が戻らないようなことがおきると、タイムアウトする。
|
インデクス
