Ubuntu20.04にhevc-qsvコーデックを実装する(後編)

2021年1月1日

まえがき

前回はffmpegの導入と各種コーデックの導入を行い、環境構築自体は完了しました。

今回は各種コーデックによる違いを変換時間や画質の違いから見ていきます。
まず最初に今回の比較に用いた実行環境の振り返ります。

  • CPU:Intel 10700T 8C/16T 2.0GHz(TB無効)
  • RAM:DDR4-2666 64GB(16GB x 4)
  • ROM:NVMe SSD(読み書き同一)
  • OS:Ubuntu20.04

エンコード比較

比較用画像

まずは、エンコード対象の生データを確認。

録画生データ
録画生データ

このシーンに思い入れもなにもないのですが、動きが激しい場面のためこちらを比較対象にしました。
(とはいえ、今後の比較は完全にコンマ秒まで同じにはしていないので大体の参考にしてください)
ちなみにこの動画の長さは7分1秒、容量は812.3MBです。

では各種エンコードスタート!!
(エンコードオプションは極力シンプルに、デフォルトの設定を使用しています)

h.264ソフトウェアエンコード

# h.264のソフトウェアエンコード
/usr/local/ffmpeg/bin/ffmpeg -i testMovie.ts -vcodec libx264 h264.mp4

上記コマンドをtimeコマンドで測定した結果、real 3m33.681sでした。
エンコード速度も約2倍速と、あまり速くはありません。

h.264 ソフトウェアエンコード 結果
h.264 ソフトウェアエンコード 結果

変換されたmp4の容量は280.9MBで34.6%まで圧縮。
指先のブレについては今後の比較画像全てに言えることなのですが、インターレース解除前なので多少は見逃すこととします。
それ以外は非常に綺麗にエンコードができているかと思います。

h.264 ソフトウェアエンコード top
h.264 ソフトウェアエンコード top

当たり前ですが、CPUメインのエンコードなのでCPUの使用率はかなり高めです。

h.264ハードウェアエンコード

# h.264のハードウェアエンコードエンコード
/usr/local/ffmpeg/bin/ffmpeg -i testMovie.ts -vcodec h264_qsv h264_qsv.mp4

上記コマンドをtimeコマンドで測定した結果、real 0m35.123sでした。
エンコード速度も約12倍速と、恐ろしい速さです。

h.264 ハードウェアエンコード 結果
h.264 ハードウェアエンコード 結果

変換されたmp4の容量は57.2MBで7%まで圧縮。
速度と圧縮率は圧倒的ですが、圧縮率が高すぎて画像が乱れていますね。

h.264 ハードウェアエンコード top
h.264 ハードウェアエンコード top

きちんとiGPUが使用されているおかげか、CPUの利用率もそこまで高くありません。

hevcソフトウェアエンコード

# hevcのソフトウェアエンコード
/usr/local/ffmpeg/bin/ffmpeg -i testMovie.ts -vcodec libx265 hevc.mp4

上記コマンドをtimeコマンドで測定した結果、real 7m12.218sでした。
hevcはh.264よりも演算が複雑なのか、エンコード速度もほぼ等倍でh.264よりも遅かったです。

hevc ソフトウェアエンコード 結果
hevc ソフトウェアエンコード 結果

変換されたmp4の容量は111.4MBで13.7%まで圧縮。
ただ、h.264のソフトウェアエンコードと比べ容量が少ない(圧縮率が高い)にも関わらず、画質はそこまで劣化していない印象を受けました。

hevc ソフトウェアエンコード top
hevc ソフトウェアエンコード top

CPU使用率はソフトウェアエンコードということもあり、使用率は高め。

hevcソフトウェアエンコード

# hevcのハードウェアエンコード
/usr/local/ffmpeg/bin/ffmpeg -i testMovie.ts -vcodec hevc_qsv hevc_qsv.mp4

上記コマンドをtimeコマンドで測定した結果、real 1m49.773sでした。
エンコード速度は約4倍と十分な速度でした。
ソフトウェアエンコードの結果からもわかるように、変換速度は全般的にh.264のほうが速いです。

hevc ハードウェアエンコード 結果
hevc ハードウェアエンコード 結果

変換されたmp4の容量は56.9MBで7%まで圧縮。圧縮率はかなりの物です。
ただ、h.264と同じくハードウェアエンコードのデフォルト設定では圧縮率が高すぎて画質が落ちてしまいます。

hevc ハードウェアエンコード top
hevc ハードウェアエンコード top

きちんとiGPUが使用されているおかげかCPU使用率も終始低く、h.264よりも低かったです。

ここまでのまとめ

今まで結果を表にまとめるとこんな感じです。

エンコード倍率[倍]基本圧縮率[%]画質(参考)
ソフトウェアh.2641.9834.6きれい
ハードウェアh.26412.07.04見れたものじゃない
ソフトウェアhevc0.9713.7きれい
ハードウェアhevc3.867.00まぁまぁ
各コーデックの比較

速度を求めればh.264のハードウェアエンコードが理想ですが(圧倒的すぎ)
エンコードの実施は夜間に行うと考えると、速度は倍速程度あればよしとします。
それよりも、いかにきれいな状態でデータ量を圧縮するかのほうが(ストレージ事情的に)重要なので、今回はバランスのとれたhevcのハードウェアエンコードをもとにパラメータを簡単に変更し、もう少し理想的なエンコード環境を探っていきたいと思います。

ぼくのかんがえたさいきょうのエンコードかんきょう

いきなり結果からになりますがビットレート3000Kbpsまで上げたhevcのハードウェアエンコードが最もバランスが取れていました。

# hevcのハードウェアエンコード(高ビットレート)
/usr/local/ffmpeg/bin/ffmpeg -i testMovie.ts -vcodec hevc_qsv -vb 3000k saikyo.mp4
ビットレート3000でのhevcハードウェアエンコード 結果
ビットレート3000でのhevcハードウェアエンコード 結果

変換されたmp4の容量は161.4MBで19.9%まで圧縮。
エンコード速度も、CPUへの不可もhevcソフトウェアエンコードと変わりませんでした。
単純に結果データ量が増えるだけで演算へは影響がないようでした。

不可逆圧縮であるmp4のため、どうあがいても画質の劣化は避けられませんが普通に視聴する分にはこれで何も困らないので今後はこれで運用していきたいと思います。