RDNA3世代のエンコード・デコード機能
12月16日にAMDの新世代GPU、RDNA3世代となるRX7900XTX/RX7900XTが発売された。
新しい世代ということで、エンコード・デコード機能も、もちろん刷新されている。
ということで、そのあたりの概要をざっとチェックしてみたい。
デコード
まずはデコードのほうから。
デコードについては、RDNA2→RDNA3で大きく変わってはいないが、AV1 12bitデコード機能が追加されている。
DXVA Checkerで確認するとこんな感じ。
RDNA2で削除されたMPEG2 hwデコードは、RDNA3でも存在しないのはちょっと残念だ。(まあいったん削除したのならもう復活することはないのだろうが…)
エンコード
やっぱり一番大きいのは、Dual Media Engineで8K60PのAV1 HWエンコードに対応したこと。
エンコーダの対応状況を調べた結果はこちらで、ちゃんとAV1エンコーダが追加されていて、10bitにも対応していることが確認できる。
これで、QSV/NVENC/VCEにそれぞれAV1エンコードが出そろったことになる。
現状、配信等ではまだまだH.264がよく使われていると思うけど、今後AV1への対応がどんどん進んで、動画の高画質化が進んでいくといいなあと思う。
SafariのAV1対応は…?
AMDの発表によれば、RDNA3ではエンコードの画質向上のために、
(1). AI Enhanced Video Encode
機械学習モデルによって、入力フレームのエンコードによる圧縮劣化で「つぶれやすい」テキスト等の部分を強調し、エンコード後につぶれにくくする
(2). Pre Filter
エンコード前の入力フレームの画質を補正し、品質を向上させる
(3). 先行解析(Pre-analysis)
エンコード前に映像を詳細に解析することで、エンコーダのレート制御やビットレートの割り振りを改善し、画質を向上させる
あたりが強化されたみたい。
ただ、(1)(2)は言ってしまえば映像の前処理によって圧縮劣化の影響を抑制するという感じの話なので、エンコーダの圧縮劣化そのものの、つまり本質的な画質ー容量比の改善ではない。
そのため、本質的な画質ー容量比改善の取り組みは、(3)の先行解析関係がメインということになる。
VCEEncCでは、先行解析関係は--paオプションから使えるので、実際に動かして様子を見てみることにした。
先行解析
この先行解析、AV1エンコードでフルで使うとかなり遅い。
特に、motion-quality=autoを使用すると激烈に遅い。
-c av1 -u slow --pa lookahead=32,motion-quality=auto,taq=2,paq=caq
まず、固定品質モード使用時からエンコード速度を見ていくと、"motion-quality=auto"を使ったquality+motionと、"motion-quality=auto"を使ったqualityを比較すると、ものすごい速度差がついている。quality+motionは23fps前後と非常に遅い一方で、qualityでは120fps弱は出ている。
じゃあそんなに重いんだったら画質はすごくよくなるの? というのをvmaf-bitrateで確認したのがこちら。
"motion-quality=auto"を使ったquality+motionと、"motion-quality=auto"を使ったqualityにはほとんど差がない。
次にビットレート指定モード(VBR)でも見てみよう。まず速度から。
ここでもquality+motionと、qualityの差は大きい。
一方、画質ー容量比を確認すると、固定品質モードと違ってVBRモードではquality+motionのほうがqualityより画質が改善しているのがわかる。VBR使用時には、有効にすると少し効果があるようだ。
motion-qualityオプションがなぜ遅いのかなと思っていろいろみてみると、どうもGPUの演算ユニットでの解析演算が激増しているみたい。
まず、高速な"motion-quality=none"の時のGPUの状態をHWiNFOでみてみよう。
GPU Utilization 50%前後、D3D Usage 30%、Video Decoder(おそらくEncoderのこと)がほぼ100%近くで、消費電力が100W前後。
これが、"motion-quality=auto"にするとえらいことになってる。
Video Decoder(おそらくEncoderのこと)が逆に10%しかない一方で、GPU Utilization ほぼ100%、D3D Usage ほぼ100%、GPUが3GHzでぶんまわってるのもあって、消費電力が160W前後。
あと直接は関係ないけど、ほかと比べてGPUメモリ熱くない?
ということで先行解析にはGPUの演算ユニットが使われてるっぽくて、"motion-quality=auto"にすると結構重いよ、というところを見てきた。
GPU負荷があがるということは、エンコードのためだけにぶん回すときはまあいいかもしれないけど、ゲームをしながら録画・配信するといった用途には不向きかもしれない。(フレームレート落ちそう)
そのうち来る? Smart Access Video
AMDによれば、エンコード関係でさらにSmart Access Videoという機能が準備中(?)で、RX7xxxシリーズのGPUとRyzen CPUの内蔵GPUを連携させてより高速にエンコードするといったことができるようになるらしい。
もっとも、まだAMF SDKにも出てきていなくて、どんな感じでできるようになるのかはわからない。
AMDいわく、この機能を使うと4K AV1エンコードが最大30%高速になるらしい。
一応、手元の環境はR9 7950X + RX7900XTなので、このあたりの再現も将来できるはず。果たして本当に30%高速になるのか楽しみだ。(往々にしてこの手の別デバイスのエンジンを並列動作させるやつはいろいろ制限はありそうだが…)
新しい世代ということで、エンコード・デコード機能も、もちろん刷新されている。
ということで、そのあたりの概要をざっとチェックしてみたい。
デコード
まずはデコードのほうから。
デコードについては、RDNA2→RDNA3で大きく変わってはいないが、AV1 12bitデコード機能が追加されている。
DXVA Checkerで確認するとこんな感じ。
RDNA2で削除されたMPEG2 hwデコードは、RDNA3でも存在しないのはちょっと残念だ。(まあいったん削除したのならもう復活することはないのだろうが…)
エンコード
やっぱり一番大きいのは、Dual Media Engineで8K60PのAV1 HWエンコードに対応したこと。
エンコーダの対応状況を調べた結果はこちらで、ちゃんとAV1エンコーダが追加されていて、10bitにも対応していることが確認できる。
これで、QSV/NVENC/VCEにそれぞれAV1エンコードが出そろったことになる。
現状、配信等ではまだまだH.264がよく使われていると思うけど、今後AV1への対応がどんどん進んで、動画の高画質化が進んでいくといいなあと思う。
AMDの発表によれば、RDNA3ではエンコードの画質向上のために、
(1). AI Enhanced Video Encode
機械学習モデルによって、入力フレームのエンコードによる圧縮劣化で「つぶれやすい」テキスト等の部分を強調し、エンコード後につぶれにくくする
(2). Pre Filter
エンコード前の入力フレームの画質を補正し、品質を向上させる
(3). 先行解析(Pre-analysis)
エンコード前に映像を詳細に解析することで、エンコーダのレート制御やビットレートの割り振りを改善し、画質を向上させる
あたりが強化されたみたい。
ただ、(1)(2)は言ってしまえば映像の前処理によって圧縮劣化の影響を抑制するという感じの話なので、エンコーダの圧縮劣化そのものの、つまり本質的な画質ー容量比の改善ではない。
そのため、本質的な画質ー容量比改善の取り組みは、(3)の先行解析関係がメインということになる。
VCEEncCでは、先行解析関係は--paオプションから使えるので、実際に動かして様子を見てみることにした。
先行解析
この先行解析、AV1エンコードでフルで使うとかなり遅い。
特に、motion-quality=autoを使用すると激烈に遅い。
-c av1 -u slow --pa lookahead=32,motion-quality=auto,taq=2,paq=caq
まず、固定品質モード使用時からエンコード速度を見ていくと、"motion-quality=auto"を使ったquality+motionと、"motion-quality=auto"を使ったqualityを比較すると、ものすごい速度差がついている。quality+motionは23fps前後と非常に遅い一方で、qualityでは120fps弱は出ている。
じゃあそんなに重いんだったら画質はすごくよくなるの? というのをvmaf-bitrateで確認したのがこちら。
"motion-quality=auto"を使ったquality+motionと、"motion-quality=auto"を使ったqualityにはほとんど差がない。
次にビットレート指定モード(VBR)でも見てみよう。まず速度から。
ここでもquality+motionと、qualityの差は大きい。
一方、画質ー容量比を確認すると、固定品質モードと違ってVBRモードではquality+motionのほうがqualityより画質が改善しているのがわかる。VBR使用時には、有効にすると少し効果があるようだ。
motion-qualityオプションがなぜ遅いのかなと思っていろいろみてみると、どうもGPUの演算ユニットでの解析演算が激増しているみたい。
まず、高速な"motion-quality=none"の時のGPUの状態をHWiNFOでみてみよう。
GPU Utilization 50%前後、D3D Usage 30%、Video Decoder(おそらくEncoderのこと)がほぼ100%近くで、消費電力が100W前後。
これが、"motion-quality=auto"にするとえらいことになってる。
Video Decoder(おそらくEncoderのこと)が逆に10%しかない一方で、GPU Utilization ほぼ100%、D3D Usage ほぼ100%、GPUが3GHzでぶんまわってるのもあって、消費電力が160W前後。
あと直接は関係ないけど、ほかと比べてGPUメモリ熱くない?
ということで先行解析にはGPUの演算ユニットが使われてるっぽくて、"motion-quality=auto"にすると結構重いよ、というところを見てきた。
GPU負荷があがるということは、エンコードのためだけにぶん回すときはまあいいかもしれないけど、ゲームをしながら録画・配信するといった用途には不向きかもしれない。(フレームレート落ちそう)
そのうち来る? Smart Access Video
AMDによれば、エンコード関係でさらにSmart Access Videoという機能が準備中(?)で、RX7xxxシリーズのGPUとRyzen CPUの内蔵GPUを連携させてより高速にエンコードするといったことができるようになるらしい。
もっとも、まだAMF SDKにも出てきていなくて、どんな感じでできるようになるのかはわからない。
AMDいわく、この機能を使うと4K AV1エンコードが最大30%高速になるらしい。
一応、手元の環境はR9 7950X + RX7900XTなので、このあたりの再現も将来できるはず。果たして本当に30%高速になるのか楽しみだ。(往々にしてこの手の別デバイスのエンジンを並列動作させるやつはいろいろ制限はありそうだが…)
