録画サーバ構築 QSVエンコード Linux編

前回に引き続いて、今回はLinuxでのエンコード性能を見ていく。うちのLinuxは特別な事情がない限り、全てCentOS7となる。録画サーバは前回Windowsとしても評価した、sh67h3のCore-i7 2600Sである。デュアルブートなので、Windowsを止めてLinuxで起動する。まずはWindows同様にソフトウェア・エンコードから評価する。エンコードに使用するffmpegのインストールは非常に簡単で、epelとnux-dextopのyumリポジトリを有効化してyum installするだけ。依存するパッケージもたくさん入っちゃうので、気になる人は『-y』しないで一度見てからinstallした方がよいかも。

yum install -y epel-release
yum install -y http://li.nux.ro/download/nux/dextop/el7/x86_64/nux-dextop-release-0-5.el7.nux.noarch.rpm
yum install -y ffmpeg

早速ffmpegの性能検証だが、データソースは前回同様アメトーク60分を録画した6.5GBのTSファイル。これを以下のコマンドで2GB程度のMP4ファイルに変換した。

ffmpeg -y -i ame.ts -f mp4 -preset medium -crf 20 -tune film -vcodec libx264 -s 1280x720 -vf yadif -acodec aac -strict -2 -ac 2 -ar 48000 -ab 128k -threads 4 ame_sw.mp4

要した時間は64分ほど。Core-i7はスレッドに余力があるので、8スレッドで実行すると47分に早まった。Windowsのhandbrakeだと半分くらいの時間だったので、処理としては遅い方だろう。他のLinuxとも比較したかったので、ZBOX-CI520でも検証してみる。このサーバもCentOS7で、CPUはHaswellのCore-i3 4020Yだ。yumでffmpegを準備して同じ処理を行ったところ124分かかった。このCPUのスレッド数は4なので、スレッド数を8にしても効果は薄く、数分早まった程度。Linux(ffmpeg?)のソフトウェア・エンコードはあまり効率よくなさそうだね。

続いて肝心のQSVエンコード。Linuxの場合、そもそも環境を用意するのが大変だ。QSVに対応したffmpegを作るのに、IntelのMedia Server Studioをインストールする必要があるのだが、このソフトの推奨kernelがCentOS 7.1.1503になる。幸いうちの標準OS。こういうkernel制限はいまどき非常に煩わしいのだが、それよりも問題なのがシステム要件で、Intelの第4世代プロセッサー以降且つHD Graphics 4200以上であること。うちのSandyBridgeなんか軽くぶっちされてる状況。それでも何となく動くかなと思ってやるだけやってみた。現在、入手出来るMedia Server StudioはMediaServerStudioEssentials2016.tar.gzというものだったが、ネット上にある知見は2015R6を使ったものが多いので、1世代前のこちらを使う。実際は2016の方も試したんだけど、正常動作には至らなかったので割愛。

tarの中にあるinstall_sdk_UMD_CentOS.shというスクリプトを実行してパッケージをインストール。続いて一般ユーザーでbuild_kernel_rpm_CentOS.shを実行してパッケージをビルド。ビルドしたパッケージをインストールして再起動すると、QSV対応したkernelで起動してくるという流れ。

yum install mesa-dri-drivers redhat-lsb
scp xxxx/MediaServerStudioEssentials2015R6.tar.gz /usr/local/src
cd /usr/local/src
tar xzf MediaServerStudioEssentials2015R6.tar.gz
cd MediaServerStudioEssentials2015R6
tar xzf SDK2015Production16.4.2.1.tar.gz
cd SDK2015Production16.4.2.1/Generic
tar xzf intel-linux-media-ocl_generic_16.4.2.1-39163_64bit.tar.gz
./install_media.sh
cd ../CentOS
tar xzf install_scripts_centos_16.4.2.1-39163.tar.gz
./install_sdk_UMD_CentOS.sh
mkdir /usr/local/src/MSS
cp build_kernel_rpm_CentOS.sh /usr/local/src/MSS
chown -R USER /usr/local/src/MSS
usermod -G video USER
cd /usr/local/src/MSS
sudo -u USER ./build_kernel_rpm_CentOS.sh
cd /usr/local/src/MSS/rpmbuild/RPMS/x86_64
yum install *
reboot

新たなkernelで起動してきたら、テスト用のサンプルが用意されているので実行してみる。

cd /usr/local/src/MediaServerStudioEssentials2015R6
tar xzf MediaSamples_Linux_bins_6.0.16043175.175.tar.gz
cd MediaSamples_Linux_bins_6.0.16043175.175
./sample_encode_drm h264 -i content/test_stream_176x96.yuv -o test.264 -w 176 -h 96
    :
Unrecognized device ID 0102Unrecognized device ID 0102中止 (コアダンプ)

これが見事にコアダンプ。0102というデバイスIDを認識出来ないらしい。何だろうと思ったけど、Intelの公式を確認してみたら、このCPUのデバイスIDが0x102と記載されている。うーん、要件満たしていないから蹴られちゃってるのかな。やっぱりHaswell以降じゃないとダメみたい。まずは成功モデルを作りたいなあ。あれ、そういえばCI520ってHaswellじゃん。喜々として同じ手順をCI520で繰り返す。無事起動してきたのでサンプルを動かしてみる。

 ZOTAC ZBOX-CI520NANO-J

 ZOTAC ZBOX-CI520NANO-J
価格:45,799円(税込、送料別)

./sample_encode_drm h264 -i content/test_stream_176x96.yuv -o test.264 -w 176 -h 96
libva info: VA-API version 0.35.0
libva info: va_getDriverName() returns 0
libva info: User requested driver 'iHD'
libva info: Trying to open /opt/intel/mediasdk/lib64/iHD_drv_video.so
libva info: Found init function __vaDriverInit_0_32
libva info: va_openDriver() returns 0
Encoding Sample Version 6.0.16043175.175

Input file format    YUV420
Output video        AVC
Source picture:
    Resolution    176x96
    Crop X,Y,W,H    0,0,176,96
Destination picture:
    Resolution    176x96
    Crop X,Y,W,H    0,0,176,96
Frame rate    30.00
Bit rate(Kbps)    112
Target usage    balanced
Memory type    system
Media SDK impl        hw
Media SDK version    1.16

Processing started
Frame number: 101
Processing finished

正しく動作した。今度はQSVに対応したffmpegをビルドする。yumで入れたffmpegと混同しそうな人は、先ほどのffmpegパッケージを予め削除しておくように。

yum install --enablerepo=epel,nux-dextop yasm fdk-aac-devel freetype-devel lame-devel opus-devel libvorbis-devel libvpx-devel x264-devel x265-devel

vi /usr/lib64/pkgconfig/libmfx.pc
----
prefix=/usr/local
libdir=${prefix}/lib
includedir=${prefix}/include

Name: libmfx
Description: Intel Media SDK Dispatched static library
Version: 2015
Requires:
Requires.private:
Conflicts:
Libs: -L/usr/local/lib -L${libdir} -lmfx -ldispatch_shared -lva -lva-drm -lstdc++ -ldl
Libs.private:
Cflags: -I${includedir} -I/opt/intel/mediasdk/opensource/mfx_dispatch/include -I/usr/local/include
----

mkdir /opt/intel/mediasdk/opensource/mfx_dispatch/build
cd /opt/intel/mediasdk/opensource/mfx_dispatch/build
yum install cmake
cmake –D__ARCH:STRING=intel64 ..
make
ln -s /opt/intel/mediasdk/include /usr/local/include/mfx
ln -s /opt/intel/mediasdk/opensource/mfx_dispatch/build/__lib/libdispatch_shared.a /usr/local/lib
ln -s /opt/intel/mediasdk/opensource/mfx_dispatch/build/__lib/libdispatch_trace.a /usr/local/lib
ln -s /opt/intel/mediasdk/opensource/mfx_dispatch/build/__lib/libmfx.a /usr/local/lib
ranlib /usr/local/lib/libdispatch_shared.a

cd /usr/local/src
git clone --depth 1 git://source.ffmpeg.org/ffmpeg
cd ffmpeg
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure --pkg-config-flags="--static" --enable-gpl --enable-nonfree --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libmfx
make
make install

簡単に書いているが、実際のところは相当の試行錯誤を必要とした。皆さんも同様の手順で成功する事を祈るばかり。苦労して作ったffmpegを噛み締めながらQSVエンコードを試してみる。

ffmpeg -y -i ame.ts -f mp4 -preset medium -tune film -vcodec h264_qsv -s 1280x720 -vf yadif -acodec aac -strict -2 -ac 2 -ar 48000 -ab 128k -threads 4 ame_qsv.mp4

37分かかって、500MBのmp4ファイルが生成された。500MBだとさすがに画質が悪過ぎるので、クオリティを上げる方法を探す。『-q』オプションに品質値を指定する事でbitrateが上がる。数値は小さいほど高品質。ただし、このオプションだけではエラーになってしまうので、look_aheadオプションと一緒に使う。『-q』オプションに22を指定すると、38分かかって大体2GBほどのmp4ファイルを作れた。

time ffmpeg -y -i ame.ts -f mp4 -preset medium -tune film -vcodec h264_qsv -s 1280x720 -vf yadif -q 22 -look_ahead 0 -acodec aac -strict -2 -ac 2 -ar 48000 -ab 128k -threads 4 ame_qsv.mp4

素のソフトウェア・エンコードから比較すれば3分の1くらいまで高速化しているが、60分の動画エンコードに38分かかっている計算になってしまう。i7機で全力出せば47分でソフトウェア・エンコード出来る事からも高速と言えるほどのスピードではない。CPU使用率は倍くらい違うのは確かなんだけど、処理時間の問題だけでなくkernelやCPUが縛られる事も現時点では採用しにくい理由となる。Haswellもいつ対象外になってしまうかわからないし。次回はなるべく制限の少ない高速化を目指して、ビデオカードを使ったハードウェア・エンコードを試してみる。うーん、skylakeのceleronとか試してみたいなあw

One reply

  1. kazu yamamoto より:

    yamamotoです。

     Linuxでnvencやったことあるんですが、画質が悪くファイルサイズが大きかったです。
    確かに速度は速いのですが、速度倍、ファイルサイズも倍では保存には適さないので、
    ffmpegだけで変換やってます。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)