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

本記事は[DMMグループ Advent Calendar 2019](https://qiita.com/advent-calendar/2019/dmm)の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（クロステック）]
(https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00944/083000001/)
それにしても大手メディアのテック系新技術とかテック系新興企業に対する記事、煽り系のタイトル多すぎやしませんか…(ぼそっ)

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


すごーくざっくりいうと圧縮率がかなり高い動画コーデックです。
HEVCやVP9と比較して50%の圧縮効率上昇を目指しているらしいので、単純に考えてYouTubeの動画(多くがVP9やAVC)がこれまでの半分の通信量で見れるようになる…かもしれません。少なくとも現在標榜しているスペックでも**1080pのコンテンツが2Mbpsを切るビットレートで楽しめるようになるわけで** 胸熱ですね。
Chrome 70からは標準サポートをしており、YouTubeはしれっと一部コンテンツをAV1で配信していたりします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/40b055a8-3ee0-7ca0-a8b3-16f9bbb2261f.png)
余談ですがこの記事を書く上で久しぶりに「どの程度AV1で配信されているか？」を調べてみたのですが、最近のコンテンツでなおかつそれなりの再生数を稼いでいるものについてはAV1をサポートしている動画が増えてそう。すごい！
<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">YouTubeがAV1で撒き始めたという話は聞いていたけど、割とカジュアルにAV1使う領域に来ているっぽくて感動of感動！！！ <a href="https://t.co/mFaIZ8QZdh">pic.twitter.com/mFaIZ8QZdh</a></p>&mdash; yanoshi (@yanoshi) <a href="https://twitter.com/yanoshi/status/1200709213132972032?ref_src=twsrc%5Etfw">November 30, 2019</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
見ていると近頃公開された100万前後再生超えのコンテンツはAV1のデータを作っている雰囲気がありました。どこかに損益分岐点があって、「これはエンコードリソースを割いてでも通信量を減らすべき」というボーダーがあるんでしょうね。気になるなぁ。

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



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


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


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


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

- [AV1リアルタイムハードウェアエンコーダを開発しました - dwango on GitHub](https://dwango.github.io/articles/av1hwencoder/)
- [ソシオネクスト、AWS でリアルタイム AV1 エンコーディングを実現 | Amazon Web Services ブログ] (https://aws.amazon.com/jp/blogs/news/socionext-av1-realtime-encode/)

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


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


## 新型Ryzenでも高いパフォーマンスを出すSVT
これが本稿を書こうかな？と思った理由。
[AMD Ryzen Threadripper 3970X / 3960X Linux Benchmarks Review - Phoronix](https://www.phoronix.com/scan.php?page=article&item=amd-linux-3960x-3970x&num=8)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/9b1959ee-036b-e22f-4176-fa31f14cbebd.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/ee16073d-9a9a-98fb-7ec1-19be89c4f5db.png)

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


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


# エンコードRTA
ということでエンコードするぞ！
今は2019年11月29日の23時52分です。12月1日中に記事は完成するのでしょうか！？
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/577e9e49-9577-4e43-e229-d3021365c63c.png)

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

[急にクラウドリソースを使って高品質エンコードをしたくなった時のためにVagrantfileを作った - さわっても熱くない花火](https://yanoshi.hatenablog.jp/entry/2019/12/01/230236)

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


## 素材を用意
BigBuckBunny飽きたよね。ってことで今回は[Sintel](https://durian.blender.org/news/sintel-4k-dcp/)です。これもBigBuckBunnyと同様にCC BY 3.0です。
[公式サイト](https://durian.blender.org/download/)より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](https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=130284))によると `-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](https://github.com/OpenVisualCloud/SVT-AV1/blob/f29b8124c938c370c1ed0036be48776209becee1/Docs/svt-av1_encoder_user_guide.md)

`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](https://github.com/OpenVisualCloud/SVT-AV1/issues/730)を読むと、`-enc-mode` と `-cpu-used` の値の変化による画質の変化は似たりよったりらしいです。
ってことでこの記事ではlibaomで利用している`-cpu-used`の値に合わせることにしました。


## 品質確認
今回はVMAFを使って評価をしようと思います。SSIMと比較すると少々時間は掛かりますが、エンコードと比べると微々たるものなので。
詳しい設定方法とかについては[ここ](https://github.com/Netflix/vmaf/blob/master/resource/doc/libvmaf.md)に載っています。

### 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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/579ba8cd-fdc9-1266-dfe5-b11191025e14.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/df90d9c5-550b-21f0-7869-c5a7d027dd82.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/f2116ab8-6b4d-b13c-cb64-e089f8e56ced.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/805ac2fc-3d20-d11a-2a8d-95886fa69ea4.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/a759fe7d-bbed-e744-f832-ac3f226b2e4f.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/2d61b013-8570-33bd-bffa-d7e52195a881.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/c38e50c6-2c2e-6fdf-8808-96ef5ebdac4a.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/9b6b76c3-33e3-b252-9b02-12598546515e.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](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/133666/73235ad8-60a9-ca5b-4f17-051b922c8f97.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](https://qiita.com/i35_267)さんの記事です！
[「失敗できる」を作り出すと開発組織は加速する - i35-267 - Medium](https://medium.com/i35-267/%E5%A4%B1%E6%95%97%E3%81%A7%E3%81%8D%E3%82%8B-%E3%82%92%E4%BD%9C%E3%82%8A%E5%87%BA%E3%81%99%E3%81%A8%E9%96%8B%E7%99%BA%E7%B5%84%E7%B9%94%E3%81%AF%E5%8A%A0%E9%80%9F%E3%81%99%E3%82%8B-83245669e9a0)


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

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

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

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


# 追記(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 さん、ありがとうございます！