更新されたまとめ記事があります

Intel QSVによる動画エンコーディングを試してみた。

LinuxにおいてIntel QSVはVA-APIを通して利用することができる。 そのため、FFmpegのVA-API機能を使用してエンコードしてみる。

VP9 WebM。

ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i source.mp4 -vf 'format=nv12|vaapi,hwupload,scale_vaapi=w=1280:h=720' -c:v vp9_vaapi -b:v 2.5M -strict -2 -c:a libopus -b:a 128k outfile.webm

おおよそ基本的なフォーマットに従っているけれども、注意点は-vfオプションだろう。

これはビデオフィルタを指定するのだが、この中でscale_vaapiは動画の画像サイズ(よく解像度と言われるもの)を変更している。 これは、ソフトウェアエンコーディングのものと比べ柔軟性が劣るため、スクリプトで連続処理する場合はよく考えて設定する必要がある。 特にアスペクト比が一定でない場合は注意が必要。

VP9でconstant qualityエンコーディングしたいと考えたのだけど、結局まともな結果は得られなかった。 -qだろうが-qpだろうが、設定は基本的に無視される(もちろん、-b:v 0しているのだけど)。

H.265の動画を作る。

ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i source.mp4 -vf 'format=nv12|vaapi,hwupload,scale_vaapi=w=1280:h=720' -c:v hevc_vaapi -c:a copy outfile.mp4

そして、-qp 32のH.265なMP4と、-b:v 2.5MのVP9なWebMの比較が次の通り。

-rw-r--r-- 1 aki aki  43215798  1月 24 14:27 _comp_fuwa.mp4
-rw-r--r-- 1 aki aki  43365795  1月 24 14:30 _comp_fuwa.webm

VP9のほうは、とても見られたものではない。 オリジナルは171484771バイトのH.264 MP4であるが、

encoder         : Lavf57.25.100
  Duration: 00:02:14.08, start: 0.000000, bitrate: 10231 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m/unknown/smpte170m), 1080x1920 [SAR 1:1 DAR 9:16], 9942 kb/s, 29.88 fps, 29.88 tbr, 15296 tbn, 59.75 tbc (default)

H.265のほうがなんら問題なく見られるのに対して、VP9のほうはちょっと実用に耐えない。 フリーのコーデックを使いたいという気持ちは強いので、何度も実験しているのだけれども、今のところ「高圧縮のH.265並の圧縮度を求めるとひどい結果になる」という結論しか得られていない。

そもそも(VP10が合流した)AV1が「HEVCに迫る」なんて言っている状況を鑑みればそんなものなのかもしれない。 AV1はまだavcodecには載っていないので、WebM勢は遅れが目立ち、このままではWeb配信のみのフォーマットになってしまいそうだ。

WebPが後発のHEIFに飲み込まれそうな情勢を考えても、世界はライセンス問題という頭痛の種をなんとかしようという方向には進まないらしい。

個人的に所蔵するデータについては、恐らくおとなしくH.265/MP4にするのが無難だろう。 公開・配布する場合はVP9も選択肢に入るだろうし、その場合はIntel QSVでエンコードできるのは非常に嬉しいだろう。¹

先日のNVENCを使用する方法(Nvidia版, H.264)は次のようなものだった。 どちらかといえばVA-APIにして欲しいなぁ…

ffmpeg -i source.mp4 -vcodec nvenc_h264 -qmin 20 -qmax 24 outfile.mp4