ffmpeg: h264_qsv hvec_qsv

raspberry pi 上でh265のハードウェアエンコードができないならWindowsで試してみるかと、試してみました。

ffmpegをダウンロードして様子を見てみると、intel系のチップで使えるハードウェアコーディックがありました。

quickなんちゃらと呼ばれているコーデックですが、ちゃんとエンコードもできそうなので早速エンコードしてみました。どうせならとソースはタイムラプスのmpgファイル…画像のソースは65%ぐらいなのでざらついていてノイジーな圧縮に不向きな状態だと思います。

試しの試でlibx265でエンコードしてみたところ、安価なネットブックなのでパワー不足なのは確かなのですが、1280x960で出だしから0.2倍速とか10FPS程度。
h265は設定にもよると思うのですが、後になるほどエンコード速度が落ちてゆくので、結構時間かかりそうなので[ctrl]+[c]を２回押して止めましたｗ

youtubeのアップロードでHDRにならなさそうなので動画のクリッピングをして720pでエンコードしてみようと思い、指定の仕方を調べていざスタート。（今だと720pは低画質に分類される気がしますが、まぁ2Kや4Kなんて環境はそろえる予定もないので…）

hevc_qsvで、エンコード速度は2.2ぐらいで始まって最終的に1.6～1.8倍(46FPS)程度でh264_qsvでは7～8倍で始まって、最終的に5.0倍(151FPS)程度でした。 

ただ、qsvは設定がハマってくれないのか、実際に出来上がったものを見たかぎりhevc_qsvのハードウェアエンコーダはあまり圧縮はできていないようで、h264_qsvとの差はあまりないような印象を受けました。（効果のあるオプションは -b:v -minrate -maxrate ぐらいしか見つけられませんでした。）libx265で驚くべきファイルサイズになったので感動したのですが、hevc_qsvは実装こそしてあるものの中身はh264なのでは？と疑いたくなるレベル。

hevcとh264のqsvはかなり似ていて、平均ビットレートの効果が強く、常に平均ビットレートに合わせる感じでした。変換中のビットレート表示を見る限りminrateとmaxrateはあまり効果がないようでした。出来上がったファイルサイズは、maxrateを上げた方が若干小さかったりとよくわからない結果も。