３年ほど前から気になっていたコーデック、「av1」。
一度試してみたものの、あまりに速度が遅くて宙ぶらりんになっていましたが…
今の動画保存はHevcが主力ですが、さらに小さくなるならディスクの圧迫も減るしいいことだらけ！
自身のPCのスペックも向上したし、ffmpegもVer5になったりしたので、再度トライしてみました。
その結果を備忘録として残します。
環境と素材
使用しているPCのスペックは以下の通り。
・CPU Intel Core i7 11700K
・メモリ 64GB
・GPU NVIDIA GeForce GTX 1050 Ti
・OS Windows10 pro
使用ソフト
ffmpeg version 5.0-full_build-www.gyan.dev
使用素材
・org.ts 1440×1080 Mpeg2 29.97fps 45分30秒 4.6GB YUV420
エンコード
1. 比較用にこれまでのHevcのエンコード
ffmpeg -hide_banner -threads 8 -i org.ts -filter:v bwdif=0 -c:v hevc_nvenc -cq 30 -c:a aac -y no1.mp42.高速と名高い、av1-svt
ffmpeg -hide_banner -threads 8 -i org.ts -filter:v bwdif=0 -c:v libsvtav1 -qp 30 -c:a aac -y no2.mp43.どこかのサイトで見つけた、libaom-av1を使った高速エンコード
ffmpeg -hide_banner -threads 8 -i org.ts -filter:v bwdif=0 -c:v libaom-av1 -qmin 10 -qmax 63 -usage 1 -lag-in-frames 0 -cpu-used 8 -aom-params error-resilient=0:enable-cdef=1:enable-tpl-model=0:deltaq-mode=0:enable-order-hint=0:aq-mode=3:max-intra-rate=300:coeff-cost-upd-freq=2:mode-cost-upd-freq=2:mv-cost-upd-freq=3:tile-columns=4:row-mt=1 -c:a aac -y no3.mp44.libaom-av1を使った固定品質のエンコード
ffmpeg -hide_banner -threads 8 -i org.ts -filter:v bwdif=0 -c:v libaom-av1 -cpu-used 5 -crf 30 -b:v 0 -row-mt 1 -c:a aac -y no4.mp4結果
| ファイル | エンコード速度 | ファイルサイズ | vmaf値 |
| no1.mp4 | 15.7x | 825MB | 94.686864 |
| no2.mp4 | 8.57x | 614MB | 93.442809 |
| no3.mp4 | 3.98x | 596MB | 93.572186 |
| no4.mp4 | 0.251x | 447MB | 95.034212 |
この結果を見て、そこそこの速度があってvmafも93超えてるしsvtいいじゃない！
なんて思ったのですが…
実画像比較
svtでエンコードした動画をしばらく見ていたら、とあるシーンでブロックノイズを発見しました。
カメラの前を人が横切って、コートの背中が大写しになってしまったシーンです。
真ん中あたりに大きなブロックノイズが出ているのがわかると思います。
あ、右上の黒いのは気にしないでください。
他のエンコードでは以下の通り。
No1 
No3 
No4
他のエンコードではブロックノイズはでていません。
それじゃあ、そこそこ速度がでていて画質もよさげ、そしてsvtよりもファイルサイズが小さくなるNo3かと思いきや…
5分単位でしかシークができないのです(;’∀’)
max-intra-rate=300
の設定が効いているのかな… この値を小さくすると細かくIフレームが作られて、細かなシークができるようになるのだろうけど、そうするとファイルサイズが犠牲になりそうですね…
結局…
動画の種類にもよるのでしょうが、no4の品質固定が一番サイズも小さいしvmaf値もよく、実際に見てみても綺麗な画像です。 保存には最適の設定となりますが…
エンコード速度0.251xとは、実時間の4倍の時間がかかるということ！
さすがにそれは厳しいなぁ～
実運用にはちょいと遠い状況となってしまいました。
ハードウェアエンコードができるようになるまで、待ちますか～
コメント