録画人間の末路 -

人は記録をしながらじゃないと生きていけない

OPEN CL対応?のx264を使ってみた

2012-10-24 00:16:09 | 次世代ビデオへの懸念
腹の立つ記事の紹介から

週刊アスキープラス 
始まる違法ダウンロード刑罰化とDRM回避規制 (第3回)
DRM回避規制で録画したテレビ番組の利用に制限は出るのか?


この連載、前から意図的に普通の録画(自由な録画)を違法扱いにしよう、違法だという解釈をさせようという明確な意図が感じられ、腹立たしいものでしたが、今回はさらにひどい。
途中から"DRM"という言葉が頻繁に出てきますが、最初に登場するのが改造B-CASカードのQ&Aの欄に"DRM(アクセスガード)"と書かれたもの。それ以降の質問欄すべてに"DRM"は入っています。改造カードの問題と著作権法改定は特に関係のない話です。ところが、なんとなく"DRM"という言葉は使われ続け、いつのまにか自由な録画機や、規制録画機を自由な録画機とした場合の"DRM"、著作権法改定のときの案作りでは問題なしとされたはずの"無視機"の解釈の話に映っているのです。つまり、改造カードの"DRM"破りと無視機の"DRM"無視を読み手が無意識のうちに同一視してしまう構成を行うことで、"無視機"を違法品と思うようになってしまう記事になっているのです。当然恣意的に行ったものでしょう。IT系の老舗アスキーもしょせんマスコミか、ああ気持ち悪い。


そんなムカムカする話は書き流しておいて。
オープンな形で使えるようになっているH.264エンコーダ、x264にはOPEN CLにある程度対応させようというプロジェクトが存在します。まだ極一部がOPEN CL化しているのみでエンコードそのものはCPUで行っているようですが、せっかくなので使ってみましょう、もちろんパソコンはAMD APU Trinity A10-5800Kです。Catarystは、15.8ではなくなんとなく15.9ベータを入れてます。

こちらでビルドされていたものをダウンロードして使わせてもらいました。OSは64bitなので64bit版を使いましょう。出力は、AviUtlからプラグインのx264guiEx 1.59。x264画面の一番上に表示されているx264エンコーダ(普通はx264.exeを選ぶ箇所)を、アップ先のx264_64_tMod+MixAQ-8bit-420-opencl.exeに変更すれば使えるようになります。あとはほとんどデフォルトのまま試しました。ビットレートは品質基準VBRの23、速度はmediumで。それと"拡張"の"追加コマンド"に

--opencl

のコマンドを追加したのみです。これを入れると、出力の際のテキストウィンドゥに"x264 [info]: OpenCL acceleration enabled with Advanced Micro Devices, Inc. Devastator"の一言が表示され、OPEN CLが使われていることが確認できます。ちなみにこのままだとAMDがCPU部分かGPU部分か分からないですが、GeForceを使っているPCだとnVIDIA~と出ますのでGPUの方でOPEN CLが利いていることがわかります。ちなみに元ファイルは1920x1080のMPEG2で、それをm2vconf経由でAviUtlに読み込ませてあります。インターレースの解除などのフィルタは一切入れていません。
エンコードさせ、状態を AMD System Monitorでチェックすると、GPUのバーが時折グンと延びます。おお、OPEN CLが使われている!とちょっと楽しくなれます。ただ、CPUがほとんど100%近い使用率に貼りついているのに対し、GPUはだいたい30%くらい。稀に60%を超えることもありますが、滅多にありません。むしろ0%に落ちることのほうが多いくらいです。エンコードそのものはCPUで行われ、GPUは一部の処理だけを担当しているためでしょう。

さて、この状態での総エンコード時間(音声含む)は、テキストウィンドウに従うと

51分24.3秒(音声込み) 17.93fps

なるほど。でも普通と言えば普通なような。今度はオプションコマンドの"--opencl"をはずして見ます。モニターではGPUバーはほとんど伸びず、OPEN CLが使われていないのが分かりますが。

50分01.2秒 18.42fps

うわ、ほんのわずかですけどこっちの方が速い(笑)。OPEN CL対応と言っても、どうやらlookaheadの部分だけのようですし、かえってCPU-GPU間のやり取りがボトルネックになっちゃったのかも知れません。

さらに、普通のx264.exeも使ってみます。バージョンは調査の時点で一番新しいと思われた0.128.2216.0。これの64bitの8bit版を持ってきて、同じ条件でエンコードして比べてみます。

52分14.1秒 17.61fps

一応これよりは速いですが、誤差の範囲・・・というよりOPEN CL版のベースになったx264のバージョンが速いだけな気がします。
ちなみに、x264.exeもOPEN CL版のopenclオプション切りにしても、cfr23で出来上がったファイルサイズは約777MB(128Kbpsの音声含む)でほとんど同じ。それに対し--openclを有効にした場合、787MBとちょっぴり容量も大きくなってしまっています。

うーん、A10-5800Kで使う分には速度面でもCPU負担面でも特に使う意味はないですが、CPUやGPU能力次第で結果は異なるかも知れません。OPEN CLがあればここが便利!になるよう少し煮詰まってくることを期待したいですね。

そういえば、AMDの新CPU、FX-8350が発売されたようですね。クロックの上がり具合で予想すると、この間のTrinityのCPUエンコード実験の条件で1時間くらい(A10-5800Kは2時間)になるかな? と思うんですが、個人的にもう単体CPUはいいかな? と思ってます。手元にはFX-8120もあるし、APUの成長を見守っている方が面白いですしね。さらに、このところAMDばかり使っていたんで、そろそろIntelシステムをどうにかしたくてたまらなくなってきましたし。

コメント    この記事についてブログを書く
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする
« Windows8タブレットは成功し... | トップ | 絶妙すぎてもう一つなiPad mini »

コメントを投稿

次世代ビデオへの懸念」カテゴリの最新記事