UbuntuでのQSVを実現するに当たって、今まで2つのドライバを使ってきた。Intel Media Server Studioに付属しているiHDドライバとmadia-driver (Intel Media Driver for VAAPI)でmakeするiHDドライバ。何となく前者はQSVで使い、後者はVAAPIで使うものみたいに考えてきた。実はmedia-driverも元はと言えばQSVで使うつもりで準備したものだったが、UbuntuでQSV対応のffmpegを準備することが出来ずに断念。やむなくVAAPIで使ってみたら思いの外きれいだったという結果。
しかし、media-driver + VAAPIの組み合わせだと、一部のBS番組でひどいブロックノイズが頻発してしまうため利用を見合わせた。その後、情報提供頂いたpatchなども試したが、自分の環境ではどうしても改善せず。そうこうしているうちに、z270チップセットでも動作するIMSS2018R2が出たので、そちらに乗り換える。そしてffmpeg4のQSV対応も確立したので、IMSS + QSVでの運用に切り替えた。唯一、気に入らないのはIMSSがkernelを限定してしまうという点。
理想はkernelを限定しないmedia-driver + VAAPIで問題となるブロックノイズをクリアすることなんだけど、これがどうしてもうまくいかない。よくよく思い返せば、media-driverもQSVで使う前提で導入したものなのだから、ffmpeg4のQSV対応が確立できている今、media-driver + QSVを試せばいいんじゃない!という自明の結論にようやく気が付く。実はmedia-driverを使ったffmpeg4のQSV化はまだ実績がないんだけど、これだけ慣れた今なら何とかなるに違いない。
という訳で、久々にmedia-driverでiHDドライバを構築する。以前もまとめた気がするが、以下のような手順。
apt update
apt install -y autoconf automake cmake g++ libtool pkg-config libva-dev libdrm-dev libpciaccess-dev libx11-dev vainfo
vainfo
mkdir -p ~/vaapi
cd ~/vaapi
git clone https://github.com/01org/libva
cd libva
./autogen.sh --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu
make
make install
ldconfig
mkdir -p ~/vaapi/workspace
cd ~/vaapi/workspace
git clone https://github.com/intel/gmmlib
mkdir -p build
cd build
cmake -DCMAKE_BUILD_TYPE= Release -DARCH=64 ../gmmlib
make
cd ~/vaapi/workspace
git clone https://github.com/intel/media-driver
cd media-driver
git submodule init
git pull
mkdir -p ~/vaapi/workspace/build_media
cd ~/vaapi/workspace/build_media
cmake ../media-driver \
-DMEDIA_VERSION="2.0.0" \
-DBS_DIR_GMMLIB=$PWD/../gmmlib/Source/GmmLib/ \
-DBS_DIR_COMMON=$PWD/../gmmlib/Source/Common/ \
-DBS_DIR_INC=$PWD/../gmmlib/Source/inc/ \
-DBS_DIR_MEDIA=$PWD/../media-driver \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_INSTALL_LIBDIR=/usr/lib/x86_64-linux-gnu \
-DINSTALL_DRIVER_SYSCONF=OFF \
-DLIBVA_DRIVERS_PATH=/usr/lib/x86_64-linux-gnu/dri
make
make install
export LIBVA_DRIVER_NAME=iHD
echo LIBVA_DRIVER_NAME=iHD >> /etc/environment
vainfo
続いて、このライブラリを使ってffmpeg4をQSV対応させる。手順は以下。
cd ~/vaapi
git clone https://github.com/Intel-Media-SDK/MediaSDK msdk
cd msdk
git submodule init
git pull
apt install -y libx11-xcb-dev libxcb-dri3-dev libxcb-present-dev
mkdir -p ~/vaapi/build_msdk
cd ~/vaapi/build_msdk
cmake -DCMAKE_BUILD_TYPE=Release -DENABLE_WAYLAND=ON -DENABLE_X11_DRI3=ON -DENABLE_OPENCL=ON ../msdk
time make -j4
make install
echo '/opt/intel/mediasdk/lib' > /etc/ld.so.conf.d/imsdk.conf
ldconfig
apt install -y libfdk-aac-dev libvorbis-dev libvpx-dev libx264-dev libx265-dev ocl-icd-opencl-dev pkg-config yasm
cd /usr/local/src
git clone https://github.com/FFmpeg/FFmpeg
cd FFmpeg
PKG_CONFIG_PATH=/opt/intel/mediasdk/lib/pkgconfig \
./configure \
--prefix=/usr/local/ffmpeg \
--extra-cflags="-I/opt/intel/mediasdk/include" \
--extra-ldflags="-L/opt/intel/mediasdk/lib" \
--extra-ldflags="-L/opt/intel/mediasdk/plugins" \
--enable-libmfx \
--enable-vaapi \
--enable-opencl \
--disable-debug \
--enable-libvorbis \
--enable-libvpx \
--enable-libdrm \
--enable-gpl \
--cpu=native \
--enable-libfdk-aac \
--enable-libx264 \
--enable-libx265 \
--extra-libs=-lpthread \
--enable-nonfree
time make -j4
make install
/usr/local/ffmpeg/bin/ffmpeg -encoders | grep qsv
これでmedia-driverのiHDドライバと、そのQSVに対応したffmpegを準備することが出来た。当然だけど、kernelはUbuntu18.04標準のもののまま。ビルドにはまあまあ苦労したんだけど、media-driverもffmpeg4も成功実績がある分、以前ほどの絶望感もなく乗り切ることが出来た。いよいよmedia-driver + QSVの実験に移るわけだが、まずはmedia-driver + VAAPIで必ず映像が乱れてしまうBSの妖怪ウォッチを圧縮してみる。コマンドとしてはいつものもの。
time /usr/local/ffmpeg/bin/ffmpeg -y -nostdin -hwaccel qsv -vcodec mpeg2_qsv -i test.ts -vcodec h264_qsv -preset medium -tune film -vb 4M -vf deinterlace_qsv,scale_qsv=1280:720 -acodec copy -threads 0 test.mp4
出来上がったmp4を視聴してみると、まったく映像が乱れていない!幸い圧縮品質も目に見えるような劣化はない。おお、これで遂に理想のQSV環境に辿り着いた。しかし、うっすらと別の劣化に気付いてしまう。圧縮時間が倍くらい遅くなってしまったのだ。30分番組の圧縮にIMSS + QSVなら6分程度だったのが、media-driver + QSVだと11分ほどかかってしまう。これくらいの時間だったらまだいいんだけど、数時間番組とかになるとなかなか終わらないんだよね。
もともと録画直後に圧縮を始めるのは、サーバリソースを急激に消費することになるので嫌いだった。つまりだらだらと何時間も録画しているんだから、その間にじわじわ圧縮してしえばサーバの消費リソースを時間に対して平均化できる訳だ。この手法を私はリアルタイムエンコードと呼んでいる。もともとのepgrec UNA環境ではこれを実現していたので、次の新環境でも何とか対応させよう。UbuntuでのQSV環境は申し分ない状態になったので、次回はいい加減録画サーバを作りますw
hevc_qsvを試してみたください。新世界が。。
おお、意味深なコメントを。。。
とりあえず簡単に試してみましたが、速度は残念な感じでした。
Skylakeだとイマイチなんでしょうかね。
どっちかというとリアルタイムエンコとして使っています。
30fps以上出してくれればいいわけで。
media-driver + QSV組み合わせは試してみたいですね。
IMSSの結果とどっちがきれいですかね。
なるほど、そういう意味でしたか。
画質面での評価はまだ出来ていないので、今度確認してみます。
感覚的には以前に比べてh264_qsvの品質は落ちてるような気がしています。
今回の構成でCPU/OS/IMSS/ffmpegなど、いろいろ変えてしまったので、
一概に比較できるようなものではないのかもしれませんが。
注意深く見るようになっただけという可能性も否定できませんw