昨日書いたように、再生環境のビミョウな悩みですが、PS-3を買う、というのもありかなー、なんて思ったのですが、最新版のPS3はＹＤ linuxが動かないんですね。これじゃ、CodecSys ttp://codecsys.fixstars.com/ja/
とか使えません。 orz
------
それはともかく、
Hauppauge HD PVR でaac 5.1チャンネルのビデオをつくるプロジェクトですが、
その5、その６に書いた手順で作業手順としてはだいたい確立しました。その6の手順は確実なのですが、面倒くさいうえ、下準備に結構時間がかかるのでなんとかならないか考えていたのですが、ちょっとうまい方法を思いつきました。原理というか理屈(それほどたいそうなものでもない)は以下のとおりです。
前提として、STBの出力は2chステレオの場合はLPCM、5.1chサラウンドの場合は、AAC出力になるように設定しています。HD PVRの音声入力は、S/PDIFにしています。また、録画は、EPGでの開始・終了時刻の1分前から1分後までを録画する設定にしています。このように条件で録画すると、多くの場合録画期間中に音声がLPCM→AAC→LPCMと変化します。
この場合、拙作のHD PVR用のソフトでは、LPCM⇔AACの切り替え時に録画が停止し、再度録画を開始します(こういう仕様なのです)。このときの反応時間は0にできないので2-3秒間頭が切れた録画になります(図の薄緑のところ)。(もうちょっと短くできるが、未対策。トレーラーのぶぶんなので、気にしないことにしています。)
一方、別録音しているAAC音声のほうは、LPCM⇔AACの切り替え時にも前後のLPCMも含めすべて録音され、ext_bsでAAC部分を抽出することで、完璧なデータを用意できます(図の黄色のところ)。
これらのはじめが微妙に切れた映像(しかも切れた分の長さは一定ではない)と音声を張り合わせるために、リップシンクの調整が必要になるわけです。
これを、それぞれのデータの最後の部分は一致してると仮定してみました。上記の考察を考えると原理的には、うまくいきそうな気がします。
映像の長さは、TMPGEncで仮読みして、ミリSec単位ではかります(L1)。音声の方は、とりあえずext_bsの出力ファイル、(AACのファイル)をLPCMのWAVファイルに変換します。で、WAVファイル中のデータチャンクの長さから、正確な長さをミリSec単位で求めます(L2)。
L1-L2の値を「その6」での、txMuxeRでの音声の遅延の値の代わりに使おう、という目論見です。
早速やってみたのですが、イマイチ。 orz
「その6」の手順とおりのでやったのに比べ、やや音声がすすんでしまいます。
さらに調べると、もともとHD PVRで録画された、tsファイルをMediaInfoで見てみると、音声が100msほど進んでいるようです。
ということで、(L1-L2-100)を音声トラックの遅延に指定して、tsMuxeRでマージしてみると、イイ感じ。
我が家の再生環境の問題と思いますが、ほんのすこし音声が進んでいる感じがしますが、違和感を感じるほどではありません。
複数のサラウンド音声の番組で試しましたが、この方法で問題ないようです。 (ヤホ～っ!)
音声は、なんとかなりそうな気がします。AAC→WAV変換は今回はvlcでやったが、コマンドラインツールもありそうです。vlcもコマンドラインで使えるらしいし…WAVになってしまえば、最悪WAVファイル中のRIFFヘッダを読んで、DATAチャンクの長さから、長さを調べるプログラムを作ってもいいや。
問題は映像かな。いまはTMPGEncを使っていますが、「tsフォーマットから、H264のストリームをとりだして、総フレーム数を数える」がTMPGEnc がやっていることだろうと思います(でなければ、入力ファイルを指定した際に「黙り込んでいる」時間の長さは説明できない)。
んー。TMPGEncをUWSC やAutoItで自動化して動かす。→ 2008/9ころ良くはまってた。できれば避けたい。
自分で、 「tsフォーマットから、H264のストリームをとりだして、総フレーム数を数える」プログラムを作る。H264とはいえ、録画ファイルはかなりでかいので、ちゃんと作らないと超鈍足になりそう。Rubyとかでなくcじゃないとだめ?
それ以前にｔｓとかH264の技術資料ってどこにあるの?
effelpist@
Jun@
ＡＳＯＢＯ@
