録画サーバ環境を構築する上で、もう1つ問題になりそうなのがエンコード。録画したTSファイルをMP4に圧縮してディスク容量を有効活用する。ソフトウェアエンコードだと張り付くくらいCPUを使うので、出来ればハードウェアエンコードを使いたい。エンコード方法をざっと調べた感じだと、Intel CPUのSandyBridge以降で使えるQSVエンコードという方法と、NVIDIAのグラボGeForceを使ったNVENCという方法だ。これらのHWエンコードを行うのはWindowsに比べるとハードルが高そうなので、まずはWindowsで動作検証を行う。ちなみにNVENCが出来るグラボは持っていないので、これは調達してから。
構築より先にエンコード方法を調べるのは、それによって選択するOSが影響を受けそうだからだ。例えばLinuxでQSVエンコードを使うならCentOS7.1.1503が推奨されるし、CPUもHaswell以降が必要になる。SandyBridgeのsh67h3でQSVするにはWindowsになってしまうかもしれない。foltiaやPX-Q3PEを使う録画サーバはCentOS6に固定されるので、録画機とエンコード機が別OSになるのか。その2サーバを別ノードにするのか、同一ノード上の仮想サーバにするのか。同一ノードの場合、ゲスト間でファイルシステムを共有させるのはglusterfsなのか、VirtFSなのか。ネットワークの負荷を回避出来る分だけ後者の方が望ましいが、そのVirtFSはCentOS7が対応していなかったりとOS構成の悩みが増えていく。
という訳で、いろいろ理由をつけた上でエンコードの検証を先行する。Windowsのエンコードは簡単で以前から利用実績のあるhandbrakeというツールを使う。自分の使っているバージョンは0.10.5.0だった。変換に使うデータソースはアメトーク60分を録画した6.5GBのTSファイル。handbrakeだとソフトウェアエンコードもQSVエンコードもお手のものでプルダウンメニューで選択するだけ。エンコード方式にも2通りあって、従来からのh264と4k時代向けのh265、どちらでも選べる。後者の方が圧縮率が高くなるが、当然そのコストも大きくなるので、どちらが効率的かも見ておきたい。
検証に使うWindows機は2台で、SandyBridgeのi7 2600Sとi5 2400S。ソフトウェアエンコードはクロック依存するので前者の方が性能よいはず。逆にQSVエンコードはクロックに影響を受ける事はなく、内蔵GPUに依存する。内蔵GPUはどちらもIntel HD Graphics 2000なので性能は同じになる。とはいえ、ビデオエンコードだけでなく、同時にオーディオエンコードも行うので、この部分についてはCPU依存余地が残ってしまう。
【送料無料】【中古】intelCore i7 2600S (クーラー無し)【291-ud】
|
まずはi5 2400S機でソフトウェアエンコードから。h264での変換は32分間CPU張り付きで3.1GBに圧縮出来た。h265は初期の見積もりですら150分となった上、更に伸びていく気配だったので諦めた。続いてQSVエンコードのh264を試す。ソフトウェアエンコードよりは若干ましだが、それでもCPUは常に100%近く使っていた。22分間かかってサイズは5.4GBほど。画質はどちらもサイズ比例と思ってもらってよい。もう少しCPU使わないイメージだったが、こんなものなのかな。ちなみにQSVエンコードのh265はSkylake世代でないとサポートされていないので、うちの環境では無理でした。
次にi7 2600S機で試験。ソフトウェアエンコードのh264は23分間CPU張り付きで3.1GB。i5機より10分弱早まった。h265の状況は一緒だったので諦め。QSVエンコードのh264はCPU半分程度の使用率で19分かかり、サイズは5.4GB。QSVエンコードは当初の予想通り、クロックの影響を受けにくい事が証明された。が、時間はともかくCPU使用率に結構な違いがあるのはどういうことなのだろう。スレッド数の違いかな？スレッド数を明示指定できたら、今度は指定してやってみよう。今のところは予定通り、i7機を録画サーバにしてエンコードも担当させる方向でよさそうだ。