TMPGEnc4XP から VFW インタフェースで x264 + raw PCM の AVI を出力して， それを faac で AAC エンコして gpac の MP4Box で mux して .mp4 ファイルを作る日々．

先週はいつものモータスポーツに加えて NHK「失われた文明 インカ・マヤ・アステカ」とかも録画したもんで， 週間 23本，エンコ時間が合計で 40時間くらい？ とかすごいことになってました． 今週は今週で BS-i でバレーボールワールドグランプリ予選があるんで， こいつを HD 画質に近くエンコすると 2時間番組 1本に 13時間かかる罠．

ここまで読んで「バカじゃね？」と思った方は，正常です．お帰りください(ぉ

というわけで，Core 2 Quad Q6600 がいい感じに値下がりしたわけですよ． 巷では「4コアなんて使い道ない」「2コアで充分」といった声も聞かれるわけですが， エンコ厨には何コアあっても使いきれないぜ！ たぶん！

んが，ここで問題になるのが，上記の「VFW インタフェースで」の部分． こいつはエンコ時に「1フレーム読んで 1フレーム書く」という動作をするのだが， 複数コアの CPU を駆使するために複数スレッドを使ってエンコすると問題が発生する． 前後のフレームデータを参照しなければならないために入力フレームを同ターンで出力できないので， 最初の数ターンは何も出力しないでおいて，最期に帳尻を合わせるように動作するのだな． ところが VFW は入力が終わったら出力の読み取りも終えてしまうので， 結果その帳尻合わせができず，後ろの方のフレームが欠落してしまう．

で，4コア CPU を活用するためにスレッド数を増やせば，その分だけ多く欠落してしまう． ちなみに B フレームの連続数を増やすと同様に欠落が増えていってしまう． 圧縮率を上げつつ速度も向上させたい場合は，とにかく欠落が増える方向になってしまうわけだ． 今は「末尾のほんの数フレームが欠落してもまぁ仕方ない」と無対策でエンコしているのだが， 欠落量が増えてくるとそうも言ってられん．

というわけで，フレーム欠落対策をしっかりするために， まずはどのくらい欠落するのかをチェックしてみた．

欠落数 = ( スレッド数 - 1 ) + ( Bフレ数 )，というとても明快な式が得られる模様． てことは 4コア CPU で 8 スレッド動かして B フレ 5 にすると 12 フレーム欠落， 時間にしておよそ 0.4 秒．とても無視できる量ではなくなるなぁ．

まぁそんなわけで，ビデオに関していえば，TMPGEnc でカットする時にあらかじめ 12 フレーム多くカットしておけばいいのだが， そうすると今度は音声が 0.4 秒くらい長く入ってしまうことになる． raw PCM を AAC にエンコする前に，2ch * 16bit * 48000Hz * 0.4 == 76800バイトくらい末尾から削り取る必要があるな．

話がどんどん複雑になっていくのは，ひとえに TMPGEnc の CM カット機能が優秀すぎる上にカット情報を単体で出力できねーからです． それができればなぁ，普通に AVISynth とかでコマンドラインだけでエンコできちゃうのに． のにのにの．