【Intel】 Quick Sync Video Part.7 【QSV】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
前スレ
【Intel】 Quick Sync Video Part.6 【QSV】 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/avi/1453245696/ rigaya氏のQSVBenchmark(20170108)のmpgファイルをソースにして、
QSV H.264/x264(8/10bit)/x265(8/10bit)/VP9(8bit)でエンコードを行い、
SSIM/ビットレート図を作成してみました。
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3424.jpg
この図にQSV HEVCのmain/main10の結果も重ねてみたいのですが、
当方はHaswellノート環境なので、QSV HEVCには未対応です。
そこで、QSV HEVCのmain/main10で1度に7パターンのMP4ファイルと
ログを作成するバッチファイルを作りました。
内容物をQSVBenchmarkフォルダに置いてバッチを実行するだけです。
QSVEncC v2.70とffmpegのバイナリを同梱していますが、
不安な方は公式サイトのものを使うようにして下さい。
https://www.axfc.net/u/3820061.zip
Kabylake環境をお持ちの方にお願いなのですが、ログ7種を取得していただき、
アップしていただけないでしょうか。時間もそれほどかからないと思います。
ログをいただけたらエンコード時間等も加えて画像を更新しようと思っています。 >>298
いつもありがとうございます。
いただいたHEVC main/main10の情報を>>297の画像に追加しました。
速度の追加については今はちょっと時間がとれないので・・・。
QSV_HEVCを追加したSSIM_Bitrate図
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3425.jpg
どうせならNVEncやVCEEncも重ねてみたいとこですね。
VBR指定で5000/10000/15000あたりを測るバッチ作って依頼投げればいいのかな。 ゴガギーン
ドッカン
m ドッカン
=====) )) ☆
∧_∧ | | / / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
( )| |_____ ∧_∧ < おらっ!出てこい>>280>>158
「 ⌒ ̄ | | || (´Д` ) \___________
| /  ̄ | |/ 「 \
| | | | || || /\\
| | | | | へ//| | | |
| | | ロ|ロ |/,へ \| | | |
| ∧ | | | |/ \ / ( )
| | | |〈 | | | |
/ / / / | / | 〈| | |
/ / / / | | || | |
/ / / / =-----=-------- | | rigayaさんの目視の結果と変わらないってことでいいのかな? >>301
当たり前じゃん
>>300は主観で物見ろって言ってんのにrigayaも>>297も客観で語ってんだから
お互いに話通じる訳ねーよ >>302
?
ちょっと意味がわからない
主観評価って目視のことじゃないの? >>302
よくわからないが、とりあえずアンカの付け方がおかしくないか。
お前さんは>>158と>>280と同じ人で、
× >>300は主観で物見ろって言ってんのに
○ >>158と>>280は主観で物見ろって言ってんのに
ということであってる?
「RDグラフ描いたらHEVCの方が断然良いからx264に迫るぐらいのビット効率になる」って
そもそもどういうものを「RDグラフ」と呼んでるのかもよくわからないが。 >>304
ごめん、同じ人じゃないけど、確かに書き方の変だったわ
「>>300が挙げた奴らは〜」だな >>303
こいつらが言う目視って直で動画見ろって事なんだろ? 動画直で見て、H264 ICQ=26 と HEVC main ICQ=26 比べてみたけど、あまり変わらないね
細かい所よく見るとH264の方がきれいな気がする
この動画実写だから、アニメだと変わるかもね >>308
実写は複雑で情報量も多いし、その組み合わせだとSSIMでもあまり差が無いから目視では色々きついと思う。
誰もが問題なく入手できて少なくともYoutubeよりも高画質なFHDアニメサンプルでもあれば、試してみたいところ。 >>297、>>299の続きとして、NVEncとVCEEncのSSIMログ取得用バッチも作成しました。
環境が無いのでオプション指定で失敗していなければいいのですが。
■NVEnc 3.13用(要Pascal環境) → https://www.axfc.net/u/3820325.zip
・基本オプション(--aq、--aq-temporal(H.264のみ)付きも含め計21パターン)
--avcuvid -c *** --profile *** --vbrhq ***
--ref 3 --bframes 3 --lookahead 10 --output-depth **
■VCEEnc 3.06用(要Polaris環境) → https://www.axfc.net/u/3820330.zip
・基本オプション(--vbaq、--pre-analysis付きも含め計18パターン)
--avvce -c *** --profile *** --vbr *** --ref 3 --bframes 3 --b-pyramid
同梱バイナリだと不安な方は公式から個別にダウンロードを。
Nortonが同梱DLLを検疫してたので、検疫によるDLL欠けなどにもご注意下さい。
Pascal、Polaris環境持ちの方にお願いなのですが、ログを取得して上げていただけないでしょうか。
結果を>>299の図に反映したいと思っています。 3DCGアニメならクリエイティブコモンズの物がいくつかあるけど日本式のアニメでそういうのは見当たらないからエンコードの試験評価は難しいよね いや今回の件だとエンコードの成果物は上げなくてもいいから著作権は気にしなくていいか >>310
https://www.axfc.net/u/3820359.zip
VCEEncエラー出てたからコマンドプロンプトに出てたログも一緒に入れておいた
ちゃんと出力はされてたから大丈夫かな いや、VCEEncのHEVC出力はサイズがめちゃくちゃ小さかったわ。2MBとかw >>313-314
ありがとうございます。
VCEEncのエラーですが、ログを見ると環境がAMF1.3となっているので、それが原因ではないかと思います。
AMF1.4で実装されたオプションも使っているため、ドライバの更新が必要になるのではないかと。
ログからはそちらのドライババージョンはわかりませんでしたが、
AMD Radeon Software Crimson 17.1.1 以降が必要とのことです。 Windows10なんだけど外部GPUとQSVの併用って出来なくなった?
QSVEnc使おうとしても下記のエラー吐くんだけど
qsv [error]: D3D9Device: Failed CreateDeviceEx: -2005530516.
qsv [error]: Failed to initialize HW Device. : null pointer.
qsv [error]: Failed to CreateHWDevice. : null pointer.
auo [error]: null pointer. 2.39の米欄と同じだな
最悪DP問題みたいにiGPUとdGPUで同じモニタに出力するといいかも >>319
重ね重ねありがとうございます。
VCEEncのH.264エンコードのログを見ると、H.264のエンコードなのに
Bframes is not supported with HEVC encoding, disabled.
というメッセージが出てBフレーム無効にされていたので、一応rigaya氏のブログに報告しておきました。
>>299の画像への追加はなるべく早く行おうと思います。 アニメでも測ってみた。使ったのはビビオペOP(テロなし) 1080p 24fps AVC 42Mbps
https://www.axfc.net/u/3820427.zip
全体的に低めに出てるのは元動画にディザがたくさんあるからかな なんかSSIM低いと思ったら、ffmpegの引数の入力ファイル指定の順番入れ替えたらSSIM変わったw
バグってるなww >>322
うーん・・・なんだろう、ソース由来だろうか。
以前直接ファイル指定するとSSIMの値が低くなってしまうケースがあって、
よくわからないので仕方なく入力を全部avs経由にしたことがあったような・・・。
あと、グラフ化はまだ作業中なんですが、>>321のVCEのログで
Found NALU with forbidden_bit set, bit error?
というメッセージが出てたのが気になりました。(デコード警告?) >>323
逆にすると高めのSSIMが出て、このm2tsをavs経由で入力すると同じ値になるから、この高めの値が本物っぽい
測り直してくるわ
この警告なんだろうね。ソースのストリームがおかしいか、デコーダがおかしいか、
だけど、ソースは自分で作ったわけじゃないし、おかしいわけないんだよな ごめん、どうやらVisual Studio 2015のx86版をインスコしてなかったのが原因だったみたい
ただ、QSVEnc 2.70だとやっぱエラーでエンコ出来ないや・・・
2.69だと問題ないんだけどね >>317 >>325
QSVEnc 2.71
・2.70でdGPU付きの環境だと正常に動作しないことがあったのを修正。
・2.70で起動が遅くなっていたのを修正。
・la/la-hrdでビットレートが表示されていなかったのを修正。
>>320
ブログでrigaya氏からの回答があったので概要を貼り。
・メッセージをHEVCと誤表示してしまっているだけで、Bフレームがサポートされてないというのは正しい。
・Polaris(RX 4xx系)のH.264エンコードはBフレームに対応していない。
・以前所持していたRX 3xx系でもBフレームありにしたほうが画質が悪かったと思う。 >>299に>>319のデータやエンコード速度を追加しました。
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3426.jpg
◎>>310のオプションについて
・NVEncの--aq-temporalはほぼ変わらず。
・NVEncの--aqは少し良くなった。
・VCEEncの--pre-analysisは結果に変化無し。
→参考: https://github.com/GPUOpen-LibrariesAndSDKs/AMF/issues/66
・VCEEncの--vbaqは、H.264だと結果に変化無し。HEVCだと少し良くなった。
◎感想
・QSVとNVのH.264はなかなか
・QSVとNVのHEVC-mainも、H.264には劣るもののそこそこ
・QSVやNVのHEVC-main10のSSIMは正しいのだろうか?
x264/x265の10bitも8bitに対する優位性が見えない。
10bitのSSIMは8bitのものと同じ測り方でいいのだろうか?
ソースが8bitだということも関係するのだろうか?よくわからない。
・VCEの幸の薄さがやばい >>321を測り直した
https://www.axfc.net/u/3820881.zip
高めの値になってるけどアニメだとこんなもんなのかな
>>327
おぉ、ありがとう
QSVとNVあまり変わらないね。NVの方が速いし >>328
ありがとうございます。グラフ化しました。NVのaqとVCEのvbaqは、こちらではいまいち。
http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3427.jpg
ただ、HEVC-main10がやけに良いなと思って少し試していたら、
A: ffmpeg.exe -i src8bit -i out10bit -lavfi "ssim;[0:v][1:v]psnr" -f null
B: ffmpeg.exe -i out10bit -i src8bit -lavfi "ssim;[0:v][1:v]psnr" -f null
とでは結果が異なり、Bの方が良い数値になるということに気づきました・・・。(>>327はA、328はBでの計測)
最初に入力した方のフォーマットにあわせて計算してるのかな。
8bitソースで8/10bit出力を公平に評価するなら、全てソースを10bit化した上でエンコードさせて
C: ffmpeg.exe -i src10bit -i out8/10bit -lavfi "ssim;[0:v][1:v]psnr" -f null
で10bit基準のSSIM値(?)で比較したほうがいいんだろうか?
それともソースが8bitなんだからAで比較してしまっていいのだろうか?
諸々踏まえてバッチの更新も考えてみます。 もう何がしたいんだかわかんねーな
エンコ後の結果が全てなんじゃねーの? >>330
オマエが馬鹿なだけ。ていうかエンコに関心無いなら見るなよw >>329
こっちまでやってくれるとは思ってなかった。ありがとう!
まとめると↓こんな感じかな
実写
NV,H264 = QSV,H264 > NV,HEVC = QSV,HEVC > VCE
アニメ
NV,HEVC = QSV,H264 > NV,H264 = QSV,HEVC > VCE
10bit基準か8bit基準かは、10bit基準の方がいいのかな
10bitを使う理由は、暗いところやバンディングがあるから、
10bitでエンコしたのをバンディングの出る8bitに落として
比較するのは、利点を潰した土俵で比較してるように思う
まぁ、ffmpegが8bitと10bitを入力したとき一体何を計算してるのか
よく分からないところがあるがw
エンコしたやつ見ても、これくらいの差だと、エンコで出たノイズに関しては
両者あまり変わらないように見えて、暗いところやグラデーションは
10bitの利点はちゃんと出てたから、俺的には10bitの方がいいと思った >>332
いくつか実験してみたところ、
ffmpeg.exe -i out8/10bit -i in8bit -lavfi "ssim;[0:v][1:v]psnr" -f null
という入力順で計測させて、10bit出力の場合は10bit基準のSSIM値になるようにすれば
公平な比較になりそうだという結論になりました。
つまり、>>329でNVのHEVC(main10)が良い結果になってるのは公平な結果なのだと思います。
逆に、>>327ではHEVC(main10)のSSIMが8bit基準の値になっており、少し不利な結果になっていると思います。
一応、>>327のQSV/NVのHEVC(main10)だけやりなおすバッチと、>>329にx264の結果を足すためのバッチを作ってみました。
https://www.axfc.net/u/3821112.zip
もし気が向きましたら、よろしくお願いいたします。 >>333
https://www.axfc.net/u/3821172.zip
x265の結果も追加した。x264/x265はCore i7 6700のPCで実行した結果 >>334
ありがとうございます。こちらでもx26x 10bitのSSIMを測りなおし、
>>327、>>329の図を更新しました。
■実写(sample_movie_1080p.mpg) → http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3428.jpg
・NV-HEVCで、main10がmainより悪いのが少し気になる
■アニメ(ビビオペOP1080p) → http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3429.jpg
・NV-HEVC、特にmain10がかなり優秀
・QSV-HEVC(main10)が高ビットレート領域で伸びそう
・QSV-HEVC(main)の伸びが少し悪いのが気になる
基本的にはNVとQSVのH.264が安定していて、アニメなど圧縮しやすいものでは
NV-HEVC(main,main10)やQSV-HEVC(main10)が力を発揮しそうという感じでしょうか。
何度も協力していただき、ありがとうございました。
ちょっと時間が必要ですが、計測用バッチはもう少しちゃんとした形に整理して公開しようと思っています。 ■ このスレッドは過去ログ倉庫に格納されています