Ubuntu20.04にhevc-qsvコーデックを実装する(後編)
まえがき
前回は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倍速と、あまり速くはありません。
変換されたmp4の容量は280.9MBで34.6%まで圧縮。
指先のブレについては今後の比較画像全てに言えることなのですが、インターレース解除前なので多少は見逃すこととします。
それ以外は非常に綺麗にエンコードができているかと思います。
当たり前ですが、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倍速と、恐ろしい速さです。
変換されたmp4の容量は57.2MBで7%まで圧縮。
速度と圧縮率は圧倒的ですが、圧縮率が高すぎて画像が乱れていますね。
きちんと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よりも遅かったです。
変換されたmp4の容量は111.4MBで13.7%まで圧縮。
ただ、h.264のソフトウェアエンコードと比べ容量が少ない(圧縮率が高い)にも関わらず、画質はそこまで劣化していない印象を受けました。
CPU使用率はソフトウェアエンコードということもあり、使用率は高め。
hevcソフトウェアエンコード
# hevcのハードウェアエンコード
/usr/local/ffmpeg/bin/ffmpeg -i testMovie.ts -vcodec hevc_qsv hevc_qsv.mp4
上記コマンドをtimeコマンドで測定した結果、real 1m49.773sでした。
エンコード速度は約4倍と十分な速度でした。
ソフトウェアエンコードの結果からもわかるように、変換速度は全般的にh.264のほうが速いです。
変換されたmp4の容量は56.9MBで7%まで圧縮。圧縮率はかなりの物です。
ただ、h.264と同じくハードウェアエンコードのデフォルト設定では圧縮率が高すぎて画質が落ちてしまいます。
きちんとiGPUが使用されているおかげかCPU使用率も終始低く、h.264よりも低かったです。
ここまでのまとめ
今まで結果を表にまとめるとこんな感じです。
エンコード倍率[倍] | 基本圧縮率[%] | 画質(参考) | |
ソフトウェアh.264 | 1.98 | 34.6 | きれい |
ハードウェアh.264 | 12.0 | 7.04 | 見れたものじゃない |
ソフトウェアhevc | 0.97 | 13.7 | きれい |
ハードウェアhevc | 3.86 | 7.00 | まぁまぁ |
速度を求めればh.264のハードウェアエンコードが理想ですが(圧倒的すぎ)
エンコードの実施は夜間に行うと考えると、速度は倍速程度あればよしとします。
それよりも、いかにきれいな状態でデータ量を圧縮するかのほうが(ストレージ事情的に)重要なので、今回はバランスのとれたhevcのハードウェアエンコードをもとにパラメータを簡単に変更し、もう少し理想的なエンコード環境を探っていきたいと思います。
ぼくのかんがえたさいきょうのエンコードかんきょう
いきなり結果からになりますがビットレート3000Kbpsまで上げたhevcのハードウェアエンコードが最もバランスが取れていました。
# hevcのハードウェアエンコード(高ビットレート)
/usr/local/ffmpeg/bin/ffmpeg -i testMovie.ts -vcodec hevc_qsv -vb 3000k saikyo.mp4
変換されたmp4の容量は161.4MBで19.9%まで圧縮。
エンコード速度も、CPUへの不可もhevcソフトウェアエンコードと変わりませんでした。
単純に結果データ量が増えるだけで演算へは影響がないようでした。
不可逆圧縮であるmp4のため、どうあがいても画質の劣化は避けられませんが普通に視聴する分にはこれで何も困らないので今後はこれで運用していきたいと思います。
ディスカッション
コメント一覧
まだ、コメントがありません