本当はHandBrake0.10.0をインストールしたかったのですが、できなかった+目的の状態にならなかったのでバージョンを更新するだけにしました。そのため、ちょっと意味が薄れた書き方になってしまいますのでそのつもりで読んで下さい。一応0.10.0で失敗した点なども解説します。
本来の目的は「QSVをLinuxで使えないか？」というところから
とにもかくにもCPUのみのエンコードはGPUを含めた場合に比べて遅いのが現状です。ファイルサーバーとして使っているマシンはQSVに対応しているCPUを使っているのでどうにかして使うことができればエンコード環境が大幅に引き上げられるのでは？と思っています。それでQSVが正式に使える様になったHandBrake0.10.0をコンパイルして使える様にしてやれ～戸考えていたのですが、うまくいかず、せめてバージョンアップを、ということで一つ古いバージョンとなる0.9.9をコンパイルすることにしました。
一年以上前にHandBrakeを更新しようとして失敗しているのですが、あのときから見るとOSのバージョンも上がりましたしいけるのでは、と思って踏み込んでみました。その結果は、というと・・・
HandBrake0.9.9であればコンパイルは簡単
前回更新に失敗した最大の問題であったGTK+も2.24系に更新されているので普通にconfigureをしてコンパイルしただけでできました。今回は選択すべきオプションも無かったので本当にそのままやっただけです。起動テストまでは終わっていますが、エンコードテストはやっていないです。ただ単に更新しただけになってしまったので。
HandBrake0.10.0をコンパイルするときの注意点
結局はできなかったのですが、HandBrake0.10.0をQSVありでコンパイルを試していました。で、その結果として
- QSVが使用できる様にするためにはIntelMediaSDKが必要で、Linuxの場合はIntelMediaServerStudioという有償のソフトウェアに含まれる。
- QSVのライブラリが含まれるIntelMediaServerStudioはFedoraやCentOSに対応していない様子。UbuntuであればOK
- QSVが含まれた状態でGCCによるコンパイルを行うとIntelMediaSDK部分の構造体の定義がVisualStudio仕様となる(共用体内の無名構造体など)のため、コンパイル時の追加オプションとして-fms-extensionが必要になる可能性もあり
- 今までダウンロードして組み込んでいたx264やLameのライブラリが外から呼び出す形に変更されているため、コンパイル時には対象のdevelのパッケージ、実行時にはランタイムが必要になる
- HandBrake0.10.0で使用するGTKはGTK3.0系なのでそちらがインストールされていない限りGUI版はコンパイルできない
ということが分かりました。QSVなしでもいいから、というわけでずっと試していましたがCentOSの場合はGTK2.24なので最後の条件でアウトとなったためやめました。前回と同じような理由なのが悲しいところですが・・・。
一応更新したけれども意味はほとんど無かったか
結局はQSVが今のところ使えない、という結論となったのでMainPC側でエンコードをすることにしています。いままではMediaCoderを使っていたのですが、固定品質でのエンコードができないようなので、次からはAviUtl+L-SMASH+QSVEncを組み合わせを考えていますが、はてさて。
