星空を含む場合は--aq-*を使うとよいで書いたように、ブロックごとに最適な量子化パラメータを推定して、同じ容量で画質を改善する機能がx264の一部ビルドに試験的に実装されていましたが、3月末に公式に取り入れられました。
一方、公式のものより更に改良を進めたVAQ2.0の試験公開も始まっていて、 どのビルドでどの機能が使えて、パラメータはどうすれば良いのかが 分かりにくくなってきたので、簡略にまとめてみました。
テレビアニメをファイル共有ソフト「ウィニー」に流したとして、著作権法違反罪で起訴された会社員(略)が4年以上前から、(略)約5700回(略)にわたりアニメを違法に流していた
1年あたり1,000本以上ってことだから一日平均3本ですか。 Charlieは自分で観る用にエンコしてますが、 エンコしやすい60iのTVドラマ、テレシネ周期が一定の24p映画・アニメは手作業がほとんど生じないのでいいとして、カットごとに周期が変わるアニメなんかはきちんとテレシネ解除しようと思ったらものすごく手作業の時間がかかる(1話30分ぶんに手作業3時間とか)ので、 2話分作るのに時給1,000円で見積もっても6,000円の作業と考えればDVDを買った方が安いかもしれません。ま、DVDでテレシネ解除してない(30/24混合で出来ないとかではなく)とか、コンポジットの素材から起こしたらしいドット妨害出まくりのDVDとか、テレビでは作画が間に合ってなくてDVDで修正されちゃったレアシーンを後で見たいとかいう要求があるので、単純にコストだけの話にできないけど。
アナログキャプチャは30分から2時間の間、休み無くHDDにデータを取り込む処理です。
この「休み無く」というのがミソで、キャプチャ中は基本的に他の処理、特にHDDにアクセスするような処理をさせてはいけません。
結構簡単にコマ落ちしてしまいます。
キャプチャしたデータを記録するHDDは、OSやアプリケーションをインストールしたドライブとは物理的に別に用意して、(パラレルの)ATAであればケーブルも別にしたほうがよいでしょう。
そしてキャプチャ前にデフラグ(ディスクの最適化)を実行するとよいでしょう。 PerfectDiskは空き領域の結合を行なってくれるのでキャプチャ用ディスク向きです。
MTVXでのキャプチャ中は、他のプログラムのせいでHDDへの書き出しが追い付かなくなると、コマ落ちが発生してしまいますから、基本的に他のプログラムが動かないようにします。OSやプログラムの自動更新も、スクリーンセイバーもです。
予め起動を抑止できるものはいいんですが、困るのはエンコード。 番組改変のこの時期に特番なんかで録っておきたい番組が毎日続くような場合、 一つエンコードしているうちに、次の放送時間が来てしまうのです。
うちのエンコマシンでは、1時間物のテレビドラマ(インタレース)をx264でエンコードするのに20時間くらいかかります。1秒間に2フレームも処理できないという状態。マシンのパーツを買い替えて、CPUをCore2の速いのにすればいいんでしょうが、お金も暇も十分ではないので今はじっと我慢。
キャプチャ中はエンコを止めないとコマ落ちするし、 かといって放送する時間帯に家にいるとは限らないので出がけにエンコを中断しておくと、キャプチャ量>エンコ量になってしまって、ディスクが足りなくなってしまいます。連休がエンコのせいで家から離れられないとなると哀し過ぎます。
TMPGEncからVfW(Video for Windows)経由でエンコードする場合、TMPGEncの「Iピクチャが指定されたフレームはキーフレームで出力する」にチェックを入れておくと、ffdshowで当該フレーム前後の表示がおかしくなる。具体的には、例えばキーフレームとなった直後の1フレームがキーフレームと同じ画像になる。
VfW(Video for Windows)経由でもコマンドラインからx264.exeを使ってエンコードしても、ソースの末尾4フレームくらいがffdshowで表示できないような気が。
仕方がないので、TMPGEncやAviUtlで末尾にコピーフレームを水増しして渡している。
関連記事
日々の戯言@まるも製作所を参考に--interlaced --direct spatialでエンコードしてみたところ、 ffdshowでは正常に表示できないものがあった。
現象としては、別のフィールドの画像に置き換わってしまう(1コマだけ引っかかるような表示になる)のと、なぜかインタレ縞が無くなってぶれたような表示になることが確認できた。1時間の映像中それぞれ1回ずつ程度の確率。ffdshowの問題なのかx264の問題なのか切り分けはしていないが、しばらくは--interlaced --direct noneのまま使おうと思う。
確かにファイルサイズ(ビットレート)は7%程度縮んだので、早くまっとうな表示になることを期待したい。
x264はH.264形式の動画ファイルのエンコーダプログラムの一つで、無償配布されています。
長い間、x264は「インターレース保持エンコードに対応しない」ことが開発者のポリシーとしてうたわれていました。
このため、30fps映像か、テレシネ解除が可能な場合はx264でエンコード、それ以外はxvidでエンコード、と使い分けが必要でした。
昨年末頃からx264でインターレース保持モードが実装され始めましたが、trellis符号化と併用できないなどの制約がある上、無償の対応デコーダが存在しない状況だったため、実用性に乏しく、手を出せませんでした。
今年に入って、Charlieが使う機能はほぼ全て対応されたようなので(8月前半の段階ではマクロブロック単位のQP変更 --aq-*を指定するとffdshowで正しく再生できない。これは痛い)現在ではインターレース画像もx264でエンコードしています。