LoginSignup
101
57

More than 3 years have passed since last update.

DMMグループAdvent Calendar 2019Day 1dmmcom
@yanoshiinDMM.com

AV1エンコーダーの速度と品質の比較 - ffmpeg(libaom) vs SVT-AV1

Last updated at Posted at 2019-12-01

本記事はDMMグループ Advent Calendar 2019の1日目の投稿です。

どうもこんにちは。DMMで動画の配信基盤を作っているチームでプロダクトオーナーをやっているyanoshiです。
数日前に見たらアドベントカレンダーの1日目が開いてるじゃないですか！ってことで確保した1日目です。私なんかが1日目で良かったのだろうか。

どんな話を書こうかなと思ったのですが、メモ書き程度にちょっと調べたいことがあったのでそれについて書きたいと思います。
動画コーデックの話です。

注意(お約束):
本記事の内容は所属する組織との関係は一切ありません。全て筆者の個人による調査/私的見解であり個人利用の範疇による技術的検証となっています。
また本稿の内容を実施して発生したあらゆる損害を筆者は一切保証しません。

概要

本稿ではAWSの c4.8xlarge インスタンスを用意し、下記のエンコーダーそれぞれでエンコードを行い、速度や画質を比較しています。

  • x264: ffmpeg(libx264)
  • VP9: ffmpeg(libvpx)
  • AV1: ffmpeg(libaom) -cpu-used 1
  • AV1: ffmpeg(libaom) -cpu-used 5
  • AV1: SVT-AV1 -enc-mode 1
  • AV1: SVT-AV1 -enc-mode 5

まえがき

AV1ってなに？SVTってなに？って人は読むといいかも。そうじゃない人は恐らく既知なので読み飛ばしていただければ…

ついに来年はAV1の大波が来るかもしれない

さて皆さん、AV1ってご存知でしょうか？
近頃は大手メディアでも取り上げられるようになってきました。数年前までは「AV1？なにそれ？」って感じだったので大きな変化ですね。

沈むH.265、グーグル動画仕様AV1が主役へ　アップル採用で加速か | 日経 xTECH（クロステック）
それにしても大手メディアのテック系新技術とかテック系新興企業に対する記事、煽り系のタイトル多すぎやしませんか…(ぼそっ)

AOMediaというコンソーシアムが作っています。
Alliance for Open Media
AOMedia Video 1 - Wikipedia
横道にそれますが、初期メンバーにGoogleとAmazonとNetflixが入っていて、彼らのオープンな動画コーデックに対する思いの強さが伝わってきますね。はじめにAppleが入っていないのも含めて、各社のビジネスモデルの違いや規格に対する戦略の違いが垣間見え、とても趣があると思っています。

すごーくざっくりいうと圧縮率がかなり高い動画コーデックです。
HEVCやVP9と比較して50%の圧縮効率上昇を目指しているらしいので、単純に考えてYouTubeの動画(多くがVP9やAVC)がこれまでの半分の通信量で見れるようになる…かもしれません。少なくとも現在標榜しているスペックでも1080pのコンテンツが2Mbpsを切るビットレートで楽しめるようになるわけで 胸熱ですね。
Chrome 70からは標準サポートをしており、YouTubeはしれっと一部コンテンツをAV1で配信していたりします。
image.png
余談ですがこの記事を書く上で久しぶりに「どの程度AV1で配信されているか？」を調べてみたのですが、最近のコンテンツでなおかつそれなりの再生数を稼いでいるものについてはAV1をサポートしている動画が増えてそう。すごい！


見ていると近頃公開された100万前後再生超えのコンテンツはAV1のデータを作っている雰囲気がありました。どこかに損益分岐点があって、「これはエンコードリソースを割いてでも通信量を減らすべき」というボーダーがあるんでしょうね。気になるなぁ。

あとAV1を語る上で欠かせないのが オープンかつロイヤリティフリー ってところ。我々配信の基盤を手掛けるエンジニアにとってはとても嬉しいポイントです。(色々とまだ懸念点は有りそうですが)

SVTってエンコーダー

そもそもエンコードというのはとても時間がかかります。
そのため人々は、頑張ってハードウェアでアクセラレーションしたり、ロジックを最適化してマルチコアでスケールするエンコーダーを作ったりと試行錯誤していたりします。

ただ、一般的にハードウェアエンコーダーの画質はソフトウェアエンコーダーと比較すると少々劣ると言われています。
rigayaの日記兼メモ帳 画質比較 2018.11 (アニメ版)
ソフトウェアエンコーダーでも過剰に並列実行数を増やすと画質が劣化したり…例えばlibx264でエンコードする場合、スレッド数を増やしすぎると画質が下がるという報告もあったりします。(少々古い記事ですが、近頃検証しても似たような傾向は確かにあります)
rigayaの日記兼メモ帳 x264の--threads 参

要は速度と画質はトレードオフの関係にあると言えるわけですね。

ハードウェアアプローチで高速化している有名な実例はdwangoさんやSocionextさんでしょう。

良いパフォーマンスが出せていて素敵ですよね。

で、ソフトウェアアプローチで頑張っているのがOpenVisualCloudプロジェクト(インテルのOSSプロジェクト)で開発が進んでいるSVT-AV1です。
OpenVisualCloud/SVT-AV1
IntelのつよつよCPUでCPU性能をフルフルに使ってエンコードするというアプローチだったりします。

新型Ryzenでも高いパフォーマンスを出すSVT

これが本稿を書こうかな？と思った理由。
AMD Ryzen Threadripper 3970X / 3960X Linux Benchmarks Review - Phoronix
image.png
image.png

速いじゃん！！！Intelよりも速い！！！素敵！！！
インターネットでは「Intel CPUに最適化されているSVT-AV1がAMD CPUに負けるのウケる」みたいな感じでちょびっと話題になっていました。
でも片方がThreadripperなのにXeonと比較していないのちょっともにょりますよね…

私もAV1の速度と画質を測定したいぞ

ってことで私も比較してみようと思ったんだなぁ。
(上記のdwangoさんの記事とOpenBenchmarking.orgを漁れば大方情報は集まったりするんですけどね)(要は自己滿足的メモです)(おとこのこは、みんな、エンコードが、すき！)

エンコードRTA

ということでエンコードするぞ！
今は2019年11月29日の23時52分です。12月1日中に記事は完成するのでしょうか！？
image.png

環境準備

サクッとパブリッククラウド上にエンコーダー環境を用意したい！
ってことで今回の検証用にサクッとクラウド上に計算リソースを展開する Vagrantfile を作ってみました。こういうときにVagrantは便利ですね。(割とビルドチャレンジで手こずったのは内緒)

急にクラウドリソースを使って高品質エンコードをしたくなった時のためにVagrantfileを作った - さわっても熱くない花火

今回はAWSのオレゴンリージョンでc4.8xlargeインスタンスを動かして検証しています。

素材を用意

BigBuckBunny飽きたよね。ってことで今回はSintelです。これもBigBuckBunnyと同様にCC BY 3.0です。
公式サイトより1080pのデータをダウンロードしてきました。

エンコードコマンド

-crf 30 で 2000kbps を目標にエンコードさせるように設定。
恐らくクソ遅いだろうと思うので、冒頭30秒のみエンコードするようにさせました。
が、SVT-AV1にはcrfでの設定ができなくて、なおかつ -crf 30 だとろくに 2000kbps に届かなかったので、SVTについてはlibaomの吐いたファイルの平均ビットレートをターゲットビットレートにして動かしています。これはぬかった(おかげで正直ちゃんとした検証になっているかびみょい)

ffmpeg(libx264)

もはや噛ませ犬になりかねないx264のエンコードコマンドはこんな感じ。
経験則的に veryslow とか設定してもあまりコストメリットが無い気がしているので medium で設定。

ffmpeg -y -ss 00:00:00 -i "/sync_folder/input.mkv" \
  -t 00:00:30 \
  -strict -2 \
  -crf 30 \
  -r 24 \
  -c:v libx264 \
  -b:v 2000k \
  -profile:v main \
  -preset:v medium \
  -c:a libopus \
  -b:a 128k \
  -ac 2 \
  -ar 48000 \
  "/sync_folder/output_x264.mp4"

ffmpeg(libvpx-vp9)

現役勢VP9のエンコードコマンドはこんな感じ。

ffmpeg -y -ss 00:00:00 -i "/sync_folder/input.mkv" \
  -t 00:00:30 \
  -strict -2 \
  -r 24 \
  -crf 30 \
  -c:v libvpx-vp9 \
  -b:v 2000k \
  -c:a libopus \
  -b:a 128k \
  -ac 2 \
  -ar 48000 \
  "/sync_folder/output_vp9.mp4"

ffmpeg(libav1)

下記を参考にオプションを組み立てました。
https://trac.ffmpeg.org/wiki/Encode/AV1

ffmpeg -ss 00:00:00 -i /sync_folder/input.mkv \
  -c:v libaom-av1 \
  -t 00:00:30 \
  -strict experimental \
  -row-mt 1 \
  -cpu-used 1 \
  -crf 30 \
  -b:v 2000k \
  -c:a libopus \
  -ac 2 \
  -ar 48000 \
  -b:a 128k \
  /sync_folder/output.mp4

近頃の記事(Good News: AV1 Encoding Times Drop to Near-Reasonable Levels)によると -cpu-used を良い塩梅にすればそれなりな速度を担保しつつ良いクオリティが出せるみたいですね。
曰く -cpu-uced 5 あたりが良さそうなので、今回の検証ではデフォルト値である -cpu-uced 1 と -cpu-uced 5 の比較もしてみようかと思います。

SVT-AV1

詳しいオプションについては下記を参考にしました。
SVT-AV1/svt-av1_encoder_user_guide.md at f29b8124c938c370c1ed0036be48776209becee1 · OpenVisualCloud/SVT-AV1

SvtAv1EncApp は標準出力に出せ無さそうだったのでこんな感じになりました。

ffmpeg -ss 00:00:00 -i /sync_folder/input.mkv \
  -s 1920x818 \
  -r 24 \
  -nostdin \
  -f rawvideo \
  -pix_fmt yuv420p \
  -an \
  -sn \
  -t 00:00:30 - \
  | SvtAv1EncApp -i stdin \
    -tbr 841000 \
    -rc 3 \
    -irefresh-type 2 \
    -enc-mode 1 \
    -w 1920 \
    -h 818 \
    -fps 24 \
    -b /tmp/output.ivf \
  && ffmpeg -y -ss 00:00:00 -i /tmp/output.ivf \
    -i /sync_folder/input.mkv \
    -c:v copy \
    -c:a libopus \
    -strict -2 \
    -ac 2 \
    -ar 48000 \
    -b:a 128k \
    -t 00:00:30 \
    /sync_folder/output_mode1.mp4

この辺のissueを読むと、-enc-mode と -cpu-used の値の変化による画質の変化は似たりよったりらしいです。
ってことでこの記事ではlibaomで利用している-cpu-usedの値に合わせることにしました。

品質確認

今回はVMAFを使って評価をしようと思います。SSIMと比較すると少々時間は掛かりますが、エンコードと比べると微々たるものなので。
詳しい設定方法とかについてはここに載っています。

SVT用

SVTはアルゴリズムの都合により、うまく割り切れないサイズに対しては余白が添加されてしまうようです。
利用している素材の解像度がトリッキーだったため今回は下に6px追加されてしまいました。(これは盲点でした…)
なので切り取るようなフィルターを掛けています。

ffmpeg -i /sync_folder/output.mp4 \
  -t 00:00:30 \
  -r 24 \
  -i /sync_folder/input.mkv \
  -r 24 \
  -t 00:00:30 \
  -filter_complex "[0:v]crop=w=1920:h=818:x=0:y=0,settb=1/AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=1/AVTB,setpts=PTS-STARTPTS[ref];[main][ref]libvmaf" \
  -f null -

SVT以外

ffmpeg -i /sync_folder/output.mp4 \
  -t 00:00:30 \
  -r 24 \
  -i /sync_folder/input.mkv \
  -r 24 \
  -t 00:00:30 \
  -filter_complex "[0:v]settb=1/AVTB,setpts=PTS-STARTPTS[main];[1:v]settb=1/AVTB,setpts=PTS-STARTPTS[ref];[main][ref]libvmaf" \
  -f null -

結果(オーバービュー)

やっぱりlibaomはとても遅かったですね。SVTはちゃんとしたマシンで動かせばそれなりに良い感じな気がします。CPUをいい感じに使ってくれていて好感が持てますね。

image.png
image.png
image.png

エンコード時間(秒) VMAF(ソースとの比較) VMAF(libaom -cpu-used 1 との比較) エンコード時間(%) 画質(%)
x264: ffmpeg(libx264) 5.719 87.969659 88.591174 0.201788255 90.45864
VP9: ffmpeg(libvpx) 75.16 96.28681 96.305983 2.651933078 99.01112
AV1: ffmpeg(libaom) -cpu-used 1 2,834.16 97.248482 100 100 100
AV1: ffmpeg(libaom) -cpu-used 5 795.297 96.868897 97.575347 28.06112854 99.60968
AV1: SVT-AV1 -enc-mode 1 501.466 96.962693 97.056684 17.69364386 99.70612
AV1: SVT-AV1 -enc-mode 5 54.261 95.945126 96.153606 1.914536199 98.65977

結果(詳細)

ペタペタ出力をあっておきます。

ffmpeg(libx264)

さすがはx264です。いい感じにCPUを使っていますね。
image.png

Output #0, mp4, to '/sync_folder/output_x264.mp4':
  Metadata:
    encoder         : Lavf58.20.100
    Chapter #0:0: start 0.000000, end 30.000000
    Metadata:
      title           : Chapter 01
    Stream #0:0(eng): Video: h264 (libx264) (avc1 / 0x31637661), yuv420p, 1920x818 [SAR 1:1 DAR 960:409], q=-1--1, 2000 kb/s, 24 fps, 12288 tbn, 24 tbc
    Metadata:
      encoder         : Lavc58.35.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/2000000 buffer size: 0 vbv_delay: -1
    Stream #0:1(eng): Audio: opus (libopus) (Opus / 0x7375704F), 48000 Hz, stereo, flt, 128 kb/s
    Metadata:
      title           : AC3 5.1 @ 640 Kbps
      encoder         : Lavc58.35.100 libopus
frame=  720 fps=127 q=-1.0 Lsize=    3429kB time=00:00:30.01 bitrate= 935.8kbits/s speed=5.29x
video:2895kB audio:511kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.663656%
[libx264 @ 0x39cd680] frame I:5     Avg QP:22.51  size: 10978
[libx264 @ 0x39cd680] frame P:283   Avg QP:27.69  size:  6883
[libx264 @ 0x39cd680] frame B:432   Avg QP:29.13  size:  2225
[libx264 @ 0x39cd680] consecutive B-frames: 12.8% 18.1% 10.8% 58.3%
[libx264 @ 0x39cd680] mb I  I16..4: 89.6%  0.0% 10.4%
[libx264 @ 0x39cd680] mb P  I16..4: 15.2%  0.0%  1.0%  P16..4: 30.2%  2.7%  1.1%  0.0%  0.0%    skip:49.8%
[libx264 @ 0x39cd680] mb B  I16..4:  0.4%  0.0%  0.0%  B16..8: 26.9%  0.8%  0.1%  direct: 0.1%  skip:71.8%  L0:34.7% L1:64.7% BI: 0.5%
[libx264 @ 0x39cd680] coded y,uvDC,uvAC intra: 3.9% 8.7% 0.1% inter: 1.3% 1.2% 0.0%
[libx264 @ 0x39cd680] i16 v,h,dc,p: 43% 29% 15% 13%
[libx264 @ 0x39cd680] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 14% 43%  4%  5%  5%  4%  3%  2%
[libx264 @ 0x39cd680] i8c dc,h,v,p: 88%  7%  5%  0%
[libx264 @ 0x39cd680] Weighted P-Frames: Y:19.4% UV:0.4%
[libx264 @ 0x39cd680] ref P L0: 45.0% 30.7% 17.0%  6.7%  0.8%
[libx264 @ 0x39cd680] ref B L0: 90.3%  8.0%  1.7%
[libx264 @ 0x39cd680] ref B L1: 98.0%  2.0%
[libx264 @ 0x39cd680] kb/s:790.41

real    0m5.719s
user    1m12.724s
sys     0m1.147s

そして画質についてもx264って感じです。まぁそうなるよね。

ソースとの比較

[libvmaf @ 0x4b09500] VMAF score: 87.969659

libaomの-cpu-used 1との比較

[libvmaf @ 0x7e55bc0] VMAF score: 88.591174

ffmpeg(libvpx-vp9)

相変わらずlibvpx-vp9はそこまでCPUを使うのが得意じゃありません。1スレッド辺りの処理速度が速いほうが有利なのでしょうね。

image.png

Output #0, mp4, to '/sync_folder/output_vp9.mp4':
  Metadata:
    encoder         : Lavf58.20.100
    Chapter #0:0: start 0.000000, end 30.000000
    Metadata:
      title           : Chapter 01
    Stream #0:0(eng): Video: vp9 (libvpx-vp9) (vp09 / 0x39307076), yuv420p, 1920x818 [SAR 1:1 DAR 960:409], q=-1--1, 2000 kb/s, 24 fps, 12288 tbn, 24 tbc
    Metadata:
      encoder         : Lavc58.35.100 libvpx-vp9
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
    Stream #0:1(eng): Audio: opus (libopus) (Opus / 0x7375704F), 48000 Hz, stereo, flt, 128 kb/s
    Metadata:
      title           : AC3 5.1 @ 640 Kbps
      encoder         : Lavc58.35.100 libopus
frame=  720 fps=9.6 q=0.0 Lsize=    3804kB time=00:00:30.01 bitrate=1038.3kbits/s speed= 0.4x    
video:3276kB audio:511kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.466767%

real    1m15.160s
user    4m5.044s
sys     0m1.694s

VMAFが95を超えてきたのでなかなかな結果と言えます。

ソースとの比較

[libvmaf @ 0x51e5380] VMAF score: 96.286810

libaomの-cpu-used 1との比較

[libvmaf @ 0x62beb40] VMAF score: 96.305983

ffmpeg(libaom:-cpu-used 1)

CPU、回ってません。悲しい。

image.png

そして遅い。噂通りですね。
1フレームあたりに3.9秒くらいかかっているので、30fpsの1時間コンテンツで421,200秒=117時間=5日弱…
ひぇぇ…
AWSのオレゴンリージョンc4.8xlargeインスタンスで動かして186.147ドルを超えます。エンコードによって2万円弱のコスパが見込める場合のみ実行すれば良いやつですね。
ただ、まぁこのCPU使用率ならもっとコア数の少ないインスタンスで良い気がします。なのでちゃんとやればもっとコストは安そうですね。ただ、シーケンスでやった場合の速度が遅いのでT2Mを気にする場合は工夫が必要でしょうね。

Output #0, mp4, to '/sync_folder/output.mp4':
  Metadata:
    encoder         : Lavf58.20.100
    Chapter #0:0: start 0.000000, end 30.000000
    Metadata:
      title           : Chapter 01
    Stream #0:0(eng): Video: av1 (libaom-av1) (av01 / 0x31307661), yuv420p, 1920x818 [SAR 1:1 DAR 960:409], q=-1--1, 2000 kb/s, 24 fps, 12288 tbn, 24 tbc
    Metadata:
      encoder         : Lavc58.35.100 libaom-av1
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
    Stream #0:1(eng): Audio: opus (libopus) (Opus / 0x7375704F), 48000 Hz, stereo, flt, 128 kb/s
    Metadata:
      title           : AC3 5.1 @ 640 Kbps
      encoder         : Lavc58.35.100 libopus
frame=  720 fps=0.3 q=0.0 Lsize=    2908kB time=00:00:30.01 bitrate= 793.6kbits/s speed=0.0106x    
video:2381kB audio:511kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.562104%

real    47m14.159s
user    82m7.017s
sys     0m12.249s

でもやっぱりきれいですね。さすがといった感じです。

ソースとの比較

[libvmaf @ 0x84d6b40] VMAF score: 97.248482

libaomの-cpu-used 1との比較

省略(これが100)

ffmpeg(libaom:-cpu-used 5)

てっきりCPU使用率が5倍になるかと思っていたのですが…そんなことはなかったですね。割と微増だったりします。たまに250%くらい使うこともありました。

image.png

エンコード速度についてはだいぶ速くなりました。

Output #0, mp4, to '/sync_folder/output_cpu5.mp4':
  Metadata:
    encoder         : Lavf58.20.100
    Chapter #0:0: start 0.000000, end 30.000000
    Metadata:
      title           : Chapter 01
    Stream #0:0(eng): Video: av1 (libaom-av1) (av01 / 0x31307661), yuv420p, 1920x818 [SAR 1:1 DAR 960:409], q=-1--1, 2000 kb/s, 24 fps, 12288 tbn, 24 tbc
    Metadata:
      encoder         : Lavc58.35.100 libaom-av1
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
    Stream #0:1(eng): Audio: opus (libopus) (Opus / 0x7375704F), 48000 Hz, stereo, flt, 128 kb/s
    Metadata:
      title           : AC3 5.1 @ 640 Kbps
      encoder         : Lavc58.35.100 libopus
frame=  720 fps=0.9 q=0.0 Lsize=    3081kB time=00:00:30.01 bitrate= 840.8kbits/s speed=0.0377x
video:2553kB audio:511kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.530404%

real    13m15.297s
user    22m57.127s
sys     0m8.435s

97を切ってきました。だんだんVP9に近づいてきましたね。

ソースとの比較

[libvmaf @ 0x840a740] VMAF score: 96.868897

libaomの-cpu-used 1との比較

[libvmaf @ 0x9244b00] VMAF score: 97.575347

SVT-AV1(-enc-mode 1)

おぉ！CPU回ってます。噂通りメモリーもバカ食いですね。かなり分割してエンコードしているんだろうと思います。

image.png

時間もかなり早くなりました。とはいえ1フレームあたりに0.7秒近くかかっているので、単純計算で30fpsの1時間コンテンツで75,600秒=21時間掛かってくることになります。まぁでもそれなりに現実的になったかな？
AWSのオレゴンリージョンc4.8xlargeインスタンスで動かしてたった33.411ドルですね。割と現実的な感じ。

SVT [version]:  SVT-AV1 Encoder Lib v0.7.5
SVT [build]  :  GCC 6.3.1 20170216 (Red Hat 6.3.1-3)     64 bit
LIB Build date: Dec  1 2019 09:57:40
-------------------------------------------
Number of logical cores available: 36
Number of PPCS 87
-------------------------------------------
SVT [config]: Main Profile      Tier (auto)     Level (auto)
SVT [config]: EncoderMode                                                       : 1
SVT [config]: EncoderBitDepth / EncoderColorFormat / CompressedTenBitFormat     : 8 / 1 / 0
SVT [config]: SourceWidth / SourceHeight                                        : 1920 / 824
SVT [config]: FrameRate / Gop Size                                              : 24 / 33
SVT [config]: HierarchicalLevels / BaseLayerSwitchMode / PredStructure          : 4 / 0 / 2
SVT [config]: RCMode / TargetBitrate / LookaheadDistance / SceneChange          : Constraint VBR / 841000 / 32 / 0
-------------------------------------------
frame=  720 fps=1.6 q=-0.0 Lsize= 1656450kB time=00:00:30.00 bitrate=452321.3kbits/s speed=0.0678x    68x     0328x
video:1656450kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
      720
SUMMARY --------------------------------- Channel 1  --------------------------------
Total Frames            Frame Rate              Byte Count              Bitrate
         720            24.00 fps                  2706907              721.84 kbps


Channel 1
Average Speed:          1.445 fps
Total Encoding Time:    498175 ms
Total Execution Time:   500668 ms
Average Latency:        59945 ms
Max Latency:            81389 ms
Encoder finished

real    8m21.466s
user    243m32.499s
sys     1m23.776s

ソースとの比較

[libvmaf @ 0x6f51a40] VMAF score: 96.962693

libaomの-cpu-used 1との比較

[libvmaf @ 0x8998ec0] VMAF score: 97.056684

SVT-AV1(-enc-mode 5)

こちらもまたぶん回ってます。ただ-enc-mode 1と比較しても同じくらいのCPU負荷みたいですね。アルゴリズム変更で並列性を高めているわけじゃなくて、単純に計算を端折ってるのかな？

image.png

SVT [version]:  SVT-AV1 Encoder Lib v0.7.5
SVT [build]  :  GCC 6.3.1 20170216 (Red Hat 6.3.1-3)     64 bit
LIB Build date: Dec  1 2019 09:57:40
-------------------------------------------
Number of logical cores available: 36
Number of PPCS 87
-------------------------------------------
SVT [config]: Main Profile      Tier (auto)     Level (auto)
SVT [config]: EncoderMode                                                       : 5 
SVT [config]: EncoderBitDepth / EncoderColorFormat / CompressedTenBitFormat     : 8 / 1 / 0
SVT [config]: SourceWidth / SourceHeight                                        : 1920 / 824
SVT [config]: FrameRate / Gop Size                                              : 24 / 33
SVT [config]: HierarchicalLevels / BaseLayerSwitchMode / PredStructure          : 4 / 0 / 2 
SVT [config]: RCMode / TargetBitrate / LookaheadDistance / SceneChange          : Constraint VBR / 841000 / 32 / 0
-------------------------------------------
frame=  720 fps= 15 q=-0.0 Lsize= 1656450kB time=00:00:30.00 bitrate=452321.3kbits/s speed=0.636x    636x    .0321x    
video:1656450kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
      720
SUMMARY --------------------------------- Channel 1  --------------------------------
Total Frames            Frame Rate              Byte Count              Bitrate
         720            24.00 fps                  2783282              742.21 kbps


Channel 1
Average Speed:          14.502 fps
Total Encoding Time:    49647 ms
Total Execution Time:   52192 ms
Average Latency:        6048 ms
Max Latency:            7712 ms
Encoder finished

real    0m54.261s
user    22m17.298s
sys     0m42.432s

ただ、画質が結構普通でした。比較対象がlibaomじゃなくてlibvpx-vp9になりそうです。
CPU負荷的にはこちらの方が圧倒的に高いので、コスパを考えると実に微妙なところですね。

ソースとの比較

[libvmaf @ 0x76c5e80] VMAF score: 95.945126

libaomの-cpu-used 1との比較

[libvmaf @ 0xa305d40] VMAF score: 96.153606

総評

「エンコードのコスパ」というのはなかなか評価しにくいですが、特にSVTのEnc Mode 1のアウトプットを見ると割とコストパフォーマンスの良い領域に来つつあるように見受けられました。
今後も動向を追いかけていかないとですね。

なんとかギリギリ間に合ったものの、12月1日中に終わらせるために色々と端折った部分も多いですが、とりあえず一応画質評価までできたのは何よりですね。
AV1のエンコードパラメータに関してまだよくわかってないところが多いので、色々と掘っていかないとなぁというお気持ちです。
配信用のデータを作る上ではGOPとかも気にしないといけないとは思うのですが、その辺りについては今回の検証項目からは外したりしています。今度はその辺りも含めて検証してみないと駄目ですね。

明日は @i35_267さんの記事です！
「失敗できる」を作り出すと開発組織は加速する - i35-267 - Medium

余談

今回はAWSのオレゴンリージョンでc4.8xlargeインスタンスを動かして検証したわけですが…
皆さん気になりますよね。お値段。このインスタンスで1.591USD/時間の課金があります。

概ね環境作成の検証で多くの時間を溶かしてしまったわけなのですが…

「そんなときでも大丈夫！」
弊社には「AWS実弾演習場」という概念がありまして。AWSの個人開発環境を毎月100ドルまで自由に使うことができます。良い話！
DMM.comの改革とAWS 【AWS Summit Tokyo 2019】 - DMM inside

こういう個人的な検証で懐を気にせずペシれる環境があるって素敵ですよね。弊社に感謝！
(という宣伝でした)

追記(2020年4月27日)

2020年現在、MP4にopusを入れるのはサポートされていないっぽいです。
本記事の主題に直接は影響しませんが、これはうっかりさんってやつですね。

@yumetodo
2020-04-27 14:09
え、AV1が格納できることは触れられていますが、Opusが格納できることは触れられていないように思います。

ちなみにOpus in MP4に関わっているmuken氏とのやり取りを貼っておきます
https://twitter.com/yumetodo/status/1240236486412234753
https://github.com/webmproject/opus-dash/pull/2

ご指摘くださった @yumetodo さん、ありがとうございます！

101
57
10

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
101
57