QSVとメモリ帯域 (2022年1月版)
かなり前だが、QSVEncのエンコード速度にはメモリ帯域もそこそこ効いているということを検証した。
これは、HWエンコードだとエンコード速度が速いために、時間あたりに転送するフレーム数が増大するため、エンコーダをフルに生かしきるにはメモリ帯域も重要になってくるということだと思う。
ただ、これは10年ぐらい前の話で、まだDDR3-2133とかを使っていた時代だった。
今ではDDR4-3600とか、DDR5-4800とかの時代で、メモリ帯域も相当強化されている。
この前テストしたi9 12900KのQSVは、i7 11700Kと同じエンジンのGPUクロック上昇版だと確認できたが、その時気になったのが、11700Kに対するGPUクロック上昇分(20%)がほぼそのままエンコード速度上昇につながっていた点だった。
メモリ帯域で律速していれば、GPUクロックが上がってもそのぶんきれいにエンコード速度は上昇しないはず。GPUクロック上昇分がほぼそのままエンコード速度上昇しているということは、メモリ帯域は現状のDDR4-3600で十分ということになる。
そこで、現在もQSVEncにメモリ帯域が効くのか、それとももう十分な時代になったのかをもう少し細かく検証してみた。
環境
検証では、
・AviutlのQSVEnc.auoプラグイン経由で出力する場合
・QSVEncCですべて処理する場合
の2通りを試した。
CPUは、
・i9 12900K (ADL)
・i7 11700K (RKL)
・i7 7700K (KBL)
・i3 4170 (HSW)
の各CPUでメモリの速度を変えてエンコード速度をチェックすることにした。メモリのレイテンシの値は、メモリのクロックを変えたときにどんな値にするのがいいのかよくわからないので、とりあえず原則としてはもともとの値からクロックに比例した調整をしておいた。
テストしたのは、
・H.264
・HEVC
・HEVC 10bit
の各固定品質モード(icq)のHWエンコードで、プリセットは
・P1: --quality best
・P4: --quality balanced
・P7: --quality fastest
の3通りを試した。
使用環境詳細
使用ソフト
QSVEnc 6.06 (QSVEncC/QSVEnc.auo)
Aviutl 1.00
テスト内容
QSVEnc.auo
lwinput.auiでMPEG2 1920x1080 29.97fps 5203frameを読み込み、
固定品質モード(icq) 25でエンコード。
QSVEncC
avhw(hwデコード)でMPEG2 1920x1080 29.97fps 5203frameを--icq 25で再エンコード。
Aviutl経由でQSV出力 (QSVEnc.auo)
まずはQSVEnc.auoでのH.264エンコードから。横軸がメモリ速度(DDR3/4-xxxx)、縦軸がエンコード速度(fps)になっている。
色をCPUごとに変えてあって、実線がP1(--quailty best)、破線がP4(--quality balanced)、点線がP7(--quality fastest)の結果。
やはり、P7のような高速なエンコードプリセットの場合にはかなりメモリの速度によってエンコード速度が左右されている結果になっていて、3600以上でもまだ多少速度の伸びしろがありそうな感じ。
一方でP1のような品質重視の設定では、ある程度メモリ速度の影響は緩和され、DDR4-3200以上はあまり伸びしろがなさそうな結果になっている。
まあ個人的にはDDR4-3200ぐらいあればそれ以上はあんまり気にしなくてもいいのかなと思った。
次にHEVCの結果。
こちらもH.264と似たような結果だが、メモリ速度はH.264よりは効かなくなっていて、全体的に傾きが小さくなっている。
特に高品質寄りの設定(P1)では特にDDR4-2000以降でほとんど速度が変わらなくなっていて、メモリ速度が気にならない感じ。HEVCのエンコードは重く、fpsが下がるため、メモリ帯域をあまり使わないのだろう。
最後にHEVC 10bitの結果。
HEVC 10bitはHEVCと比べ、フレームサイズが倍になるためメモリ帯域を使用しやすくなる。
そのため、HEVCの時よりもメモリ速度への感度が上がっていて、グラフの傾きがやや大きくなっている。それでもまあ、DDR4-3200ぐらいあればだいたい実力を出し切っている感じだろうか。
QSVEncC単体で使用
次にQSVEncCでのH.264エンコードの結果。
こちらはAviutlプラグイン(QSVEnc.auo)の場合と異なり、hwデコードが可能で、よりエンコードが速くなる。
エンコードが速くなるとメモリ速度が重要になるのかと思いきや、DDR4-2000ぐらいからは逆にメモリ速度はあまり重要ではなくなっていて、ほとんど同じ速度となっている。
次にHEVCの結果。
ほぼフラットな面白みのないグラフになっていて、ほとんどメモリ速度は効かない状態。
最後にHEVC 10bitの結果。
こちらは先ほど書いたように10bitではフレームサイズが倍になる関係で、少しメモリ速度に影響されるようになっている。
とはいってもAviutl経由で出力した場合と異なり、メモリ速度によるエンコード速度への影響は微々たるもので、DDR4-2400ぐらいでもう十分そう。
まとめ
・Aviutl経由でQSV出力
10年ほど前に調べたように、やはりメモリ速度がそこそこ効きそう。ただ、DDR4-3200とかまで来ると、それ以上にしてもさすがにもうあまり変わらないかなあという感じになってきている。
・QSVEncC単体
こちらはAviutl経由のものと比べるとあまりメモリ速度が影響せず、メモリ帯域は足りていそうなことが分かった。一般的なDDR4-2400以上に上げても、ほとんどの場合でエンコード速度は変わらなさそう。
Aviutl経由かそうでないかで、メモリ速度の影響が大きく違うのは、やはりAviutl経由の場合、Aviutlの内部処理でYC48と呼ばれる内部フォーマットを経由するためだと思う。
YC48は編集時の劣化を防ぐため、比較的大きなデータフォーマットになっていて、これが高速にエンコードをしようとするとメモリ帯域を圧迫することになるのだと思う。
一方、QSVEncCの場合は、なるべく軽量なデータフォーマットを使用するため、メモリ速度への要求はさほど大きくないのだと思う。
なお、もちろん今回のテストはなにもフィルタ等を入れていない状態で計測しているので、フィルタを追加したりすると、そのフィルタの演算量やメモリ帯域の使用量によって、このあたりの結果は変わってくると思うので注意してください。
今回調べた結果、QSVのエンコード速度は、現在使用しているDDR4-3600であれば、おおむね十分に発揮できていそうなことがわかった。
なので、もっと速いメモリを買っても、QSVエンコードに関しては効果は限定的だし、エンコードをさらに高速化しようとすると、GPU/Media Functionのクロック上げるぐらいしかなさそう。
将来的世代のGPUではEU数の増加やMedia Functionの速度向上を期待したい。
これは、HWエンコードだとエンコード速度が速いために、時間あたりに転送するフレーム数が増大するため、エンコーダをフルに生かしきるにはメモリ帯域も重要になってくるということだと思う。
ただ、これは10年ぐらい前の話で、まだDDR3-2133とかを使っていた時代だった。
今ではDDR4-3600とか、DDR5-4800とかの時代で、メモリ帯域も相当強化されている。
この前テストしたi9 12900KのQSVは、i7 11700Kと同じエンジンのGPUクロック上昇版だと確認できたが、その時気になったのが、11700Kに対するGPUクロック上昇分(20%)がほぼそのままエンコード速度上昇につながっていた点だった。
メモリ帯域で律速していれば、GPUクロックが上がってもそのぶんきれいにエンコード速度は上昇しないはず。GPUクロック上昇分がほぼそのままエンコード速度上昇しているということは、メモリ帯域は現状のDDR4-3600で十分ということになる。
そこで、現在もQSVEncにメモリ帯域が効くのか、それとももう十分な時代になったのかをもう少し細かく検証してみた。
環境
検証では、
・AviutlのQSVEnc.auoプラグイン経由で出力する場合
・QSVEncCですべて処理する場合
の2通りを試した。
CPUは、
・i9 12900K (ADL)
・i7 11700K (RKL)
・i7 7700K (KBL)
・i3 4170 (HSW)
の各CPUでメモリの速度を変えてエンコード速度をチェックすることにした。メモリのレイテンシの値は、メモリのクロックを変えたときにどんな値にするのがいいのかよくわからないので、とりあえず原則としてはもともとの値からクロックに比例した調整をしておいた。
テストしたのは、
・H.264
・HEVC
・HEVC 10bit
の各固定品質モード(icq)のHWエンコードで、プリセットは
・P1: --quality best
・P4: --quality balanced
・P7: --quality fastest
の3通りを試した。
使用環境詳細
| CPU | i9 12900K | i7 11700K | i7 7700K | i3 4170 |
|---|---|---|---|---|
| CPU cores | 16C/24T | 8C/16T | 4C/8T | 2C/4T |
| CPU L3 | 30MB | 16MB | 8MB | 3MB |
| GPU | HDG770 | HDG750 | HDG630 | HDG4400 |
| GPU Gen | Gen12 | Gen12 | Gen9.5 | Gen7.5 |
| GPU EU | 32 | 32 | 24 | 20 |
| GPU Clock | 1550MHz | 1300MHz | 1150MHz | 1150MHz |
| GPU driver | 30.0.101.1002 | 27.20.100.9316 | 30.0.100.9955 | 20.19.15.5107 |
| DRAM Gear | Gear1 | Gear1 | ||
| RAM | G.Skill F4-3600C16 -8GTZNC | G.Skill F4-3600C18 -8GTZRX | G.Skill F4-3400C16 -4GRBD | G.Skill F3-17000CL9 -4GBZH |
| Max Speed | DDR4-3600 | DDR4-3600 | DDR4-3600 | DDR3-2133 |
| RAM Size | 8GBx4 | 8GBx2 | 8GBx2 | 4GBx2 |
| DDRx-3600 | 16-19-19-39-1 | 18-22-22-42-2 | 16-18-18-38-2 | |
| DDRx-3400 | 16-18-18-37-1 | 17-21-21-40-2 | 15-16-16-34-2 | |
| DDRx-3200 | 15-17-17-35-1 | 16-20-20-38-2 | 14-15-15-31-2 | |
| DDRx-2933 | 14-16-16-32-1 | 15-18-18-35-2 | 12-14-14-29-2 | |
| DDRx-2666 | 12-15-15-29-1 | 14-17-17-32-2 | 11-12-12-28-2 | |
| DDRx-2400 | 11-13-13-26-1 | 12-15-15-28-2 | 10-11-11-28-2 | |
| DDRx-2133 | 10-12-12-24-1 | 11-14-14-25-2 | 10-11-11-28-2 | 9-11-10-28-2 |
| DDRx-1866 | 9-10-10-21-1 | 10-12-12-22-2 | 10-11-11-28-2 | 8-10-9-25-2 |
| DDRx-1600 | 8-9-9-18-1 | 8-10-10-19-2 | 10-11-11-28-2 | 7-9-8-25-2 |
| DDRx-1333 | 7-9-9-16-2 | 10-11-11-28-2 | 6-7-7-18-2 | |
| DDRx-1066 | 5-6-5-14-2 | |||
| DDRx-800 | 5-5-5-12-2 | |||
| M/B | MSI MAG Z690 TOMAHAWK WIFI DDR4 | Gigabyte Z590I AORUS ULTRA | Asrock Fatal1ty Z270 Gaming-ITX/ac | Asrock Z97E-ITX/ac |
| OS | Win 11 x64 Pro | Win 11 x64 Pro | Win 10 x64 Pro | Win 10 x64 Pro |
使用ソフト
QSVEnc 6.06 (QSVEncC/QSVEnc.auo)
Aviutl 1.00
テスト内容
QSVEnc.auo
lwinput.auiでMPEG2 1920x1080 29.97fps 5203frameを読み込み、
固定品質モード(icq) 25でエンコード。
QSVEncC
avhw(hwデコード)でMPEG2 1920x1080 29.97fps 5203frameを--icq 25で再エンコード。
Aviutl経由でQSV出力 (QSVEnc.auo)
まずはQSVEnc.auoでのH.264エンコードから。横軸がメモリ速度(DDR3/4-xxxx)、縦軸がエンコード速度(fps)になっている。
色をCPUごとに変えてあって、実線がP1(--quailty best)、破線がP4(--quality balanced)、点線がP7(--quality fastest)の結果。
やはり、P7のような高速なエンコードプリセットの場合にはかなりメモリの速度によってエンコード速度が左右されている結果になっていて、3600以上でもまだ多少速度の伸びしろがありそうな感じ。
一方でP1のような品質重視の設定では、ある程度メモリ速度の影響は緩和され、DDR4-3200以上はあまり伸びしろがなさそうな結果になっている。
まあ個人的にはDDR4-3200ぐらいあればそれ以上はあんまり気にしなくてもいいのかなと思った。
次にHEVCの結果。
こちらもH.264と似たような結果だが、メモリ速度はH.264よりは効かなくなっていて、全体的に傾きが小さくなっている。
特に高品質寄りの設定(P1)では特にDDR4-2000以降でほとんど速度が変わらなくなっていて、メモリ速度が気にならない感じ。HEVCのエンコードは重く、fpsが下がるため、メモリ帯域をあまり使わないのだろう。
最後にHEVC 10bitの結果。
HEVC 10bitはHEVCと比べ、フレームサイズが倍になるためメモリ帯域を使用しやすくなる。
そのため、HEVCの時よりもメモリ速度への感度が上がっていて、グラフの傾きがやや大きくなっている。それでもまあ、DDR4-3200ぐらいあればだいたい実力を出し切っている感じだろうか。
QSVEncC単体で使用
次にQSVEncCでのH.264エンコードの結果。
こちらはAviutlプラグイン(QSVEnc.auo)の場合と異なり、hwデコードが可能で、よりエンコードが速くなる。
エンコードが速くなるとメモリ速度が重要になるのかと思いきや、DDR4-2000ぐらいからは逆にメモリ速度はあまり重要ではなくなっていて、ほとんど同じ速度となっている。
次にHEVCの結果。
ほぼフラットな面白みのないグラフになっていて、ほとんどメモリ速度は効かない状態。
最後にHEVC 10bitの結果。
こちらは先ほど書いたように10bitではフレームサイズが倍になる関係で、少しメモリ速度に影響されるようになっている。
とはいってもAviutl経由で出力した場合と異なり、メモリ速度によるエンコード速度への影響は微々たるもので、DDR4-2400ぐらいでもう十分そう。
まとめ
・Aviutl経由でQSV出力
10年ほど前に調べたように、やはりメモリ速度がそこそこ効きそう。ただ、DDR4-3200とかまで来ると、それ以上にしてもさすがにもうあまり変わらないかなあという感じになってきている。
・QSVEncC単体
こちらはAviutl経由のものと比べるとあまりメモリ速度が影響せず、メモリ帯域は足りていそうなことが分かった。一般的なDDR4-2400以上に上げても、ほとんどの場合でエンコード速度は変わらなさそう。
Aviutl経由かそうでないかで、メモリ速度の影響が大きく違うのは、やはりAviutl経由の場合、Aviutlの内部処理でYC48と呼ばれる内部フォーマットを経由するためだと思う。
YC48は編集時の劣化を防ぐため、比較的大きなデータフォーマットになっていて、これが高速にエンコードをしようとするとメモリ帯域を圧迫することになるのだと思う。
一方、QSVEncCの場合は、なるべく軽量なデータフォーマットを使用するため、メモリ速度への要求はさほど大きくないのだと思う。
なお、もちろん今回のテストはなにもフィルタ等を入れていない状態で計測しているので、フィルタを追加したりすると、そのフィルタの演算量やメモリ帯域の使用量によって、このあたりの結果は変わってくると思うので注意してください。
今回調べた結果、QSVのエンコード速度は、現在使用しているDDR4-3600であれば、おおむね十分に発揮できていそうなことがわかった。
なので、もっと速いメモリを買っても、QSVエンコードに関しては効果は限定的だし、エンコードをさらに高速化しようとすると、GPU/Media Functionのクロック上げるぐらいしかなさそう。
将来的世代のGPUではEU数の増加やMedia Functionの速度向上を期待したい。
スポンサーサイト
