※この記事はASCII.jpからの転載です（文中リンクはASCII.jpの記事に飛ぶことがあります）
だがエンコードする対象が自然画ではなく、CGに近いものの場合はどうだろうか？ そこでAfterEffectsを使い、無数の文字が画面の上から回転しながら落ちてくるというコンポジションを準備した。これをMedia Encoder 2020にキュー出しすることで、フルHDのMP4動画にエンコードした。ソースになる素材が違うだけで、Media Encoder 2020のエンコード設定は前のテストと共通とした。
文字の輪郭はハッキリしているうえに数も多く、背景のグラデーションもじわじわと変化する。動いている部分が多いため、ビットレート的には厳しいコンポジションを準備した
H.264、VBR 1パス、CPUエンコーダーを使い目標ビットレート80Mbps/最大95Mbpsでエンコードした時の拡大図
H.264、VBR 1パス、GPUエンコーダーを使い目標ビットレート80Mbpsでエンコードした時の拡大図
こちらでもビットレートが高い時はCPUとGPUの差は認められない。では目標ビットレートを8Mbpsとした時にどう違いが出るか見てみよう
H.264、VBR 1パス、CPUエンコーダーを使い目標ビットレート8Mbps/最大10Mbpsでエンコードした時の拡大図。グラデーション部にブロックノイズが出ているほか、文字の形状が一部潰れてしまっている
H.264、VBR 1パス、GPUエンコーダーを使い目標ビットレート8Mbpsでエンコードした時の拡大図。グラデーションのブロックノイズは健在だが、文字の輪郭はかなり鮮明になった
CPUエンコーダーで目標ビットレート8Mbps/最大10Mbps、VBR 2パスエンコード時の状態。グラデーションのブロックノイズはあるが、文字が消えるようなことはなくなった
ビットレートを8Mbpsに下げた場合、CPUエンコードで1パスだとブロックノイズが出まくるどころか細い線で構成された文字が所々消失してしまうが、GPUエンコードだと文字が消えるようなことはなかった。CPUエンコードでも2パスにすることで文字の消失は回避できたので、これは単純にMedia Encoderが使っているエンコーダーの特性と考えられる。自然画よりもCGやグラフィックっぽいカチッとした絵では、GPUがCPUよりも画質で上回ることもある、と考えたい。
ただAfterEffectsからMedia Encoderへキュー出しした場合の処理時間はかなり不安定だ、という点も書いておくべきだろう。AfterEffectsでも速度比較をしようと思ったが、処理時間が時に2倍近くブレることもあるため、データをまとめるのを断念した。今回筆者が作ったコンポジションが悪い可能性もあるが、AfterEffectsでGPUエンコーダーを使おうと考えている方はこういう事例もあった、と覚えておいた方がいいかもしれない。
まとめ：高ビットレート出力ならGPU一択
以上でPremiere ProやMedia Encoderに実装されたRadeonのGPUエンコーダーの検証は終了だ。これまでのGPUエンコーダーの実装例と同じく、VBR 2パスは選択できないという点は残念だが、Ryzen 9 3950Xの半分から7分の1程度の時間で処理が済むという点において、極めて強力だといえる。
自然画において良い出力を得るにはビットレートをある程度上げる必要があるものの、H.264の80Mbpsで数分かかっていた処理が半分以下にできるのは大きい。画質を極大化したい場合やビットレートを精密に制御したい時にはまだCPUエンコードの方が有用だが、少しでも時間を短縮したいなら、Radeonの持つGPUエンコーダーは、ぜひとも活用していきたい機能といえるだろう。
