5件
AV1またはAOMedia Video 1とは、Alliance for Open Media（以下AOMedia）が開発する動画圧縮規格の一つである。2018年3月28日にAOMedia Video Codec 1.0として正式に仕様が公開された。ニコニコ動画でも採用の動きがある、詳細は後述する。
概要
VP8やVP9の直接的な後継としてH.264など既存動画圧縮技術の置き換えを目指している。その最大の特徴はロイヤリティーフリーであることで、H.265で発生した複雑怪奇なパテント・プール問題や不透明な特許使用料問題を解決するものとして注目されている。
開発の中心を担うAOMediaはAmazon、アップル、ARM、シスコ、Facebook、Google、IBM、インテル、マイクロソフト、Mozilla、謎のAI半導体メーカー NVIDIA、Netflixなどと、現代の代表的なIT界の巨人が参加メンバーとなっている。
特徴
動画投稿サイトやVODなどストリーミング向けに設計されている。エンコードに計算能力を要する一方、再生負荷は相対的に小さい。再生数が多い動画のコーデックをAV1にすることで動画の転送量を下げ、回線輻輳を抑えることができる。ただ圧縮率に対して計算コストが高くアーカイブ用途にはあまり向かない。
その性質は個人や小規模な運用より大規模事業者向けという趣があり、変換コスト<回線コストが成り立つケースにおいて威力を発揮する規格とも言える。パーソナルユースでは再生することはあっても作成する機会は少ないかもしれない。ブロードキャスト用途もアップロードを負荷の低いコーデックに任せ、配信サーバーでAV1に変換送出など間接的な使用が多いのではないかとされる。直接配信はハードウェア支援など環境整備を待つ必要がある。
再生にかかる負荷が相対的に小さいとはいえH.264など既存のコーデックより要求される性能は高い。特にバッテリー駆動で省電力を求められる携帯端末や非力な組み込み機器には再生支援は不可欠となる。策定メンバーに半導体企業が居るのもこのため。それでも余程古い機器でもない限り最適化によってFullHD程度の解像度であればソフトウェアデコードでも再生できるようになってきている。
ニコニコ動画との関係
上述の通り再生負荷は相対的に小さいが逆にエンコード時間、計算コストはとても大きい。それはひとえに雑巾絞りに喩えられるような圧縮技術の採用にある。もととなった既存コーデックの発展形でありつつもパテント回避のため新規の圧縮技法を導入した結果、最適な結果を得るため動画の解析にとてつもない量の時間が必要になってしまった。
現状、リファレンス実装のlibaomや最適化の進んでいる第三者実装のSVT-AV1でさえリアルタイムエンコードは厳しく、AV1の高画質が活きる設定(cpu-used=0や１程度)ではCore i9だろうがThreadripperだろうが1080pで数十fpsも怪しい状況である。現実的な速度でリアルタイム動作させようとすれば品質を落とすしかなく、これではH.265やVP9から移行する利点が霞んでしまう。
ニコニコ生放送を擁するドワンゴとしてもそれではいけないということで
https://twitter.com/yue_roo/status/1128207726817861632
https://twitter.com/kwappa/status/1128207724846600197
いやいやニコニコは半導体企業じゃないでしょなんで？な話だが、圧縮と回路技術に明るいエンジニアが社内にいたらしく、エンコードパラメータは限定されるが2019年3月時点で720p 30fpsの性能を達成した。内製とか家電メーカーかよという気もするがもともとニコニコにはH.265配信をFPGA実装して配信テストをした実績がありハードウェアに強いエンジニアが在籍してる模様。なぜAOMに参加しないのか。
それはそれとして蓄積型のニコニコ動画の方がAV1対応するかは未だ不明である。ただYouTubeは2018年9月15日からベータ版として既にAV1配信を開始している。Googleはスケールしないなら分割エンコードすればいいじゃないとばかりに力技で運用しているという噂もある。そのため回線コストで元が取れるならニコニコ動画も追随する可能性は十分にあると思われる。AWSを札束で殴ればドワンゴだって対抗できるのかもしれない。
とりあえず使ってみたい人は
元動画をy4m化
>ffmpeg -i src.mp4 -pix_fmt yuv420p -f yuv4mpegpipe temp.y4mOpus化
>ffmpeg -i src.mp4 -c:a libopus -b:a (ビットレート[kbps]) audio.opus１パス目
>aomenc --threads=(使用CPUコア数) --end-usage=vbr --passes=2 --pass=1 --fpf=FirstPassStatisticsFile.fpf --cpu-used=1 --tile-columns=(縦分割数) --tile-rows=(横分割数) --color-primaries=(色空間) --transfer-characteristics=(ガンマ) --matrix-coefficients=(YUV⇔RGB変換式) --output=FirstPassStatisticsFile.fpf temp.y4m２パス目
>aomenc --threads=(使用CPUコア数) --end-usage=vbr --passes=2 --pass=2 --target-bitrate=(ビットレート[kbps]) --fpf=FirstPassStatisticsFile.fpf --cpu-used=1 --tile-columns=(縦分割数) --tile-rows=(横分割数) --color-primaries=(色空間) --transfer-characteristics=(ガンマ) --matrix-coefficients=(YUV⇔RGB変換式) --output=video.webm temp.y4m音声とMUX
>ffmpeg -i audio.opus -i video.webm -c:v copy -c:a copy out.webm
libaomはパイプとy4mファイル(生のYUVデータに簡単なメタ情報をつけたコンテナ)二通りの入力をサポートしている。ただしパイプ入力はInter Prediction [フレーム間予測]や2-Passエンコードにおいて制限や予期せぬ動作を招くためあまり勧められていない。パイプ入力でcpu-used=0(複雑度最高)だとエンコーダーが落ちてしまう。
ただファイルで読み込むにしても、y4mは単純な形式な故にタイムコードや字幕などのメタデータ、そしてカラープロファイルを保持できない。ソースがVFR(スマホで撮影した動画など)であればCFRにしておくかタイムコード情報をtimecode v1なりnhmlとして、メタデータもffmetadataで別途書き出してMUXするなど工夫する必要がある。
関連リンク
関連項目
- 6
- 0pt
