2021年6月10日木曜日

ffmpegのlibsvtav1でH.265をAV1(SVT-AV1)へトランスコードしてみた

 

動機と方針

 録画をH.265且つ高帯域で大量に保存しており、できれば品質を落とさずに圧縮したい。
 高品質且つ高圧縮率を持つAV1へトランスコードすることでこれを試みることにするが、他所でどれだけAV1のベンチマークを見せられても実際に結果を見ないと何もわからないので複数条件での結果を出し比較する。

コマンドと元データ

 ffmpegで-c:v libsvtav1オプションを指定すれば、比較的現実的な処理時間で済むSVT-AV1エンコードが行えるようだったので試してみた。オフィシャルの例。

 ffmpeg -i h265.mp4 -c:v libsvtav1 -qp 30 -b:v 0 av1.mkv、などとするだけで良い。いつものことだが、しばらくffmpegを使っていないので、細かいオプションについてはチンプンカンプンに。最初勘違いして、-qpではなく-crfを使ってしまっていたが結果に全く影響しておらず、これだとおそらくデフォルトのqp=50あたりが使われるだけなのだろう。libaom-av1のオプションではcrfを使っているのに何が違うのだろうか。

 元動画は、1080p、60fps、H.265、crf=16、最大帯域20Mbps、1-passでエンコしてある。私の眼力ではRAWデータに対し遜色のない画質。データはこちらからダウンロード可能。大きな声では言えないがこの記事を最初に出した時、H264の元動画を使ってしまい、全部やりなおしている。ffmpegは元動画のコーデックをコピーするオプションを付けないとデフォルトでh.264を使うことが多いので注意しよう(自分が)。

バッチ処理

 条件が複数あるとコマンドが面倒になるのでバッチファイルで以下のようにした。簡単である。

for %%a in (50,45,40,35,30,25) do (
    ffmpeg -i %1 -c:v libsvtav1 -qp %%a -b:v 0 qp%%a.mkv
)

 CVBR用はこちら。入力ファイル名と帯域オプションの値を引数に取る。

ffmpeg -y -i %1 -c:v libsvtav1 -rc cvbr -b:v %2 %1_%2.mkv

トランスコード結果

 Googleドライブのプレイヤーで見ても強制的に劣化させられた動画しか見られないので、結果の確認時にはダウンロード必須。

固定品質モード(可変ビットレート)での結果

 圧縮率=圧縮後ファイルサイズ/元動画ファイルサイズ、で計算するものとする。帯域はffprobeの値を参考にしており、最大値なのか平均値なのか微妙だが、仕組み的におそらく動画内における最大値だろう。

 デフォルトのqp=50の場合、ファイルサイズが1/8まで減り、帯域は約2.5Mbps。画質は悪いが、この帯域の画質としては良い。

 qp=45の場合、圧縮率0.17、帯域3.5Mbps。

 qp=40の場合、圧縮率0.24、帯域4.9Mbps。

 qp=35の場合、圧縮率0.34、帯域6.9Mbps。

 qp=30の場合、圧縮率0.49、帯域10Mbps。

 qp=25の場合、圧縮率0.69、帯域14Mbps。

 qpの値が下がるにつれ品質は上がるが、エンコード時間が徐々にかかるようになる。今回のqp値の範囲だと、私の環境では(16コア32スレッドCPU)17~25fpsの間ぐらいで処理できていたので、動画の長さの2.4~3.5倍ほどの間で処理に時間がかかったことになる。SVT-AV1より前のAV1エンコーダーに比べれば十分実用的な処理時間になったのではないだろうか。

 qpが40~45では元動画からかなり画質が落ちている事が肉眼でもはっきりと分かるものの、それでもこの帯域と圧縮率の動画としては非常に良く、価値のある結果で使い所もあると言える。

 qp=30~35あたりになると、画質の劣化が肉眼ではかなりわかりづらくなる。それにも関わらず高圧縮率を実現している。

 qp=25まで下げると、圧縮率こそ70%ほどにまで下がっているが、元動画とほぼ同等品質で30%のファイルサイズ削減を実現している事には非常に価値がある。当初AV1が謳っていた性能がよく分かるのはこのあたりのqp値ではなかろうか。

 今回はトランスコードしか行っていないが、この処理速度だと高fpsでリアルタイム録画を行うことは難しそうではあるものの、圧縮用途には非常に有用だ。

帯域の制約 CVBRモードの結果

 CVBRモードを有効にしてから最大帯域を指定することで、帯域制限をかけてトランスコード出来る。ffmpeg -i in.mp4 -c:v libsvtav1 -rc cvbr -b:v 1M out.mkv、などとする。

 いくつかのqp値で、1Mbpsに制限した結果。流石に1Mbps程度だと画質は悪い。また、エンコード開始前の情報を見るとCVBRモードのときにQP値の情報が何もない上に結果にも特に差が見受けられない。つまりCVBRではQP値を指定したところで一切影響しないようだ。結果が同じ様に見えるのも当然。

 2Mbpsに制限した結果がこちら。

 1M、2M共に良い画質とは言えないが、1080p、60fpsの動画をこの品質でここまで圧縮しているということには価値があると言えるのでは。

 しかしやはり、ビットレート制限モードはライブ配信等では有用であるものの、できるだけ高品質での保存時には固定品質モードで要件に合ったqp値を探すほうが無難だろう。

H.265(HEVC)動画の再生と使用料

 現在WindowsでH.265コーデックを使う場合、現在120円ほど支払ってMicrosoft Storeから買わなければならない。この使用料や特許管理の煩雑さが普及を妨げている理由であるとされているものの、個人の場合を想像してみた時に節約出来そうな資源(物、エネルギー、時間)と比べるとお得感はあるはずだが、パテントプールを儲けさせたくない的な価値観が強いとそれも吹っ飛ぶのかもしれない。

 これからハードウェアエンコーダーなども充実し、AV1が動画配信だけではなくライブ配信などでも主流になる未来は見えている。だがH.265(HEVC)に価値がないとは思わない。特別高価なハードウェアがなくてもリアルタイム録画が手軽に行えるし、1080p動画をCRF=16という高帯域でエンコしたとしても、RAWデータの0.6%ほどにまで圧縮してくれるという高性能ぶりだ。普通の計算機とそこそこの記憶容量があれば大体の要件を満たすためにベストな選択肢だと思う。

 また、H.264が無料だからといって使うのはいいが、H.264を使い続けることによってかかりつづけるコストを考えた時、それが120円より安いわけがない事は容易にわかる。使用料を払うことによってパテントプールが集中的に儲けることは確かなのだが、それは誰かのコストを削減した者が得る通常の報酬だとは思う。もともと勝ち組の一部を集中的に儲けさせてまで使いたくねーわ、という気持ちもわからんではないが。

 Google等が無料の標準規格を出してくれることがエコだと思っている人がいるかもしれないが、そういった動きは自分たちが持っているかもしれない可能性をビッグテックが摘んでいるという見方も出来るはずだ。例えばAV1が主流になったとき、パテントフリーだとしても専用ハードウェアの主導権を握るのはGoogleらになるのでは。

 それらがすべてのデバイスに標準装備され購入するコストは旧いH.264を使い続けるコストやH.265の使用料より安くなるのだろうか?

H.265ライセンス問題回避手段としてのAV1

 リアルタイム録画にH.265を使いたいが、H.265特許問題に依存したくないという場合があるかもしれない。その場合、H.265録画ファイルに対してAV1へのトランスコードを一気に行うような自動化を施しておくというAV1の使い方がある気がする。少し時間はかかるが、品質保持とファイルサイズ削減は行え、出力結果は有償コーデック使用料が不要となる。

 AV1アライアンスはこういう事を狙っている?だとしたらかなりはらぐ・・・

 とはいえ大量の動画をトランスコードする場合、そのコストが120円より安くなるはずもないわけだが、節約される記憶領域や帯域を勘定に入れるとH.265回避として使う価値もあるかも。

ffmpegを使用した動画編集の小技

 録画した動画は編集したくなるもの。ffmpegではいろいろな編集が出来るが、簡単なコマンドだけでは出来ない処理もある。個人的に必要になったものを別記事としてまとめた。

0 件のコメント:

コメントを投稿

Google Cloud SDKにおけるAPIキーとOAuthキーの使い所の違い

  Google Cloud SDKを使っていると、APIキーのみで済むものとOAuthキーを求められるものとの使い分けを要求される。認証方式の堅牢性によって使い分けが必然的に要求されるのだろうが、用途は以下のようにわけられているらしい。 アプリケーションに求められる内容と実行さ...