【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】
■ このスレッドは過去ログ倉庫に格納されています
リアルタイムエンコが目的だからBフレ対応はしないでしょ そもそも、H265の圧縮率向上の根幹はI/Pフレの圧縮率向上が大きいからな だからNVEncのマクロブロック配置ロジックの強化されてもH264に効果が殆ど無くてH265の方に効果が出てる 元々がGPUのクラウド化で画面転送するためのエンジンを転用・下位モデルにも解放してるものだし わざわざ面倒な方の性能向上するぐらい低レイテンシ保持が大事という 265のエンコご優れてるのは分かったのですが 動画再生時デコードにパワー要りますよね? 古いpc環境とか人にも見せたいとか、モバイルでも見たいなら 264の方がまだ使い勝手が良いですか? 画質音質にこだわるのもいいけど扱いやすさがないと消滅するよ 音質が悪いと叩かれ続けてもmp3が生き残る理由 >>244 ありがと。それはどの機種での数値だろ? できれば結果全体をpaste.binあたりに貼ってもらえると嬉しい。 (調べた人が0って意味じゃないよね?) >>245 NVEncのH.264ではBフレ対応してるし、低レイテンシ重視の時はBフレ切ればいいだけだと思うけどね。 まあH.265でいまだにBフレ対応してないってのは何か理由があるんだろうけども。 >>247 原理的にはH.264よりもH.265の方がデコード自体は軽いと聞いた気がする。 ただ、H.264は既にほとんどの環境でHW再生支援が効くのに対して H.265は少し前の環境だとHW再生支援が無いことも多いので、そのあたりの差はでてくる。 そのへんを気にするならH.264を使った方がいいと思うよ。 根掘り葉掘り他人様頼みで身銭切らずに聞いている癖に、証拠まで求めるぐらいなら手前で買えよ 稼働させてるエンコ鯖止めてまでする気は無い 争いは、同じレベルの者同士でしか発生しない!!のAA思い出したw > Codec: H.265/HEVC > Max Bframes 5 Bフレーム来たね > Codec: H.264/AVC > ... > Field Encoding no 代わりにH264のフィールドエンコーディングが無くなってる? NVEncCのデフォだとBフレーム使ってくれないけど、 -b 5 とか指定すればちゃんと使ってくれた frame type IDR 59 frame type I 59, total size 6.44 MB frame type P 871, total size 36.53 MB frame type B 4297, total size 51.27 MB bフレーム対応でようやくハードウェアエンコードが市民権得られる時代になったかな? SSIM-ビットレート https://i.imgur.com/CB3oE11.png https://i.imgur.com/gpT781R.png 一定品質(--vbrhq 0 --vbr-quality N)でエンコード Nは実写が24,28,32,36、アニメが20,24,28,32 25%の性能向上は本当だったようだ 性能向上は、Bフレームで半分、その他で半分くらい >>250 Bフレーム使ってないの?エンコ鯖一旦止めてでもBフレーム使うように設定する価値はあると思うよ Bフレームはあまり多くしてもダメで2〜5を試したけど3が最適値っぽいな >>253-261 色々な情報を出していただき、ありがとうございます。 去年QSVスレで調べた時点でもNVEncのHEVCは結構良好な結果を出してましたし、 それを着実に改善していってるというのもすごいな・・・。 http://mevius.5ch.net/test/read.cgi/avi/1486130737/335 Nvidiaのフォーラムで見つけたTuringのNVEnc関連の話題 ●Details about NVENC in Turing? https://devtalk.nvidia.com/default/topic/1038493/video-codec-sdk/details-about-nvenc-in-turing-/ ・RTX2080も2080Tiも、NVEncユニットを1つしか積んでないような気がする (2本並列エンコするとパフォーマンスが半分になる。GTX1080とかでは2つ積んでたのに。) ・デコードは速いけど、エンコードはGTX1070や1080よりかなり遅い ※ただ、テスト時のドライバが410.57とか410.66と書かれていて少し古いのが気になる。 RTX2080に対応したのは411.63かららしいが・・・。 ※テスト条件等もところどころ曖昧。 ●Video Encode and Decode GPU Support Matrix https://devtalk.nvidia.com/default/topic/1039145/video-codec-sdk/video-encode-and-decode-gpu-support-matrix/ Q.新しいSDKのリリースとかサポート一覧表の更新の予定は? A.「今の時点では数か月以内としか言えないっす。」 いよいよNVEncを本格的に使う時代がやってきたようだね 2070以上じゃないと使えないとかじゃなきゃ良いが >>264 少なくともウチの環境の1060 vs 2070だと、2070遅くないよ h264は2070の方が速くて(vbrhqが330fps vs 400fpsくらい)、hevcは同じくらい(vbrhqが290fpsくらい)だった >>267 10xxも併売するらしいから無理じゃない? NVIDIAはNVENCを付加価値にしてるから 実売1万円以下のカードに乗ることは当分無さそう。 AMDに頑張ってほしい、 5千円で買ったx30,x40でNVENCが動くって今では無理だもんな Bフレ数は参照距離とかの兼ね合いで品質評価や圧縮効率にも影響するからエンコーダと設定値による 基本的に参照距離より大きくなると圧縮効率が下がるからBフレ増やす意義が下がる 参照距離は3以上は無意味だとH.264でも答えが出てたはず >>272 2070でHEVC main10で試したけど無意味だったわ 参照距離Bフレともに3が最適値かな。H264と同じっぽいね で、実際にエンコードした動画の品質はどんな感じなの? x264やx265といい勝負しているの? 「いい感じだよ」とか「全然ダメだよ」とかレスが返ってきたときに、 その情報の真偽をお前はどうやって区別つけるの? まぁレス番もつけずに比較出せって言われてもな 善意でエスパー反応しても後出しで証拠だせとか 追加であれやれこれやれっていうのが沸くだけだし 自分でやってみればっていわれるのが落ちだぞ 自分の感じたままに書くだけのことがそんなに怖いのか? 失敗することに恐怖を感じるタイプか? 俺が怖いものは、「醜態を晒している自分に気づけていない人間」かな x264,x265,QSVと比較 https://i.imgur.com/QJFOuDV.png https://i.imgur.com/AP16tNS.png 映像の見た目は、HEVCとH264だとHEVCの方がノイズの隠し方はうまいから、 同じSSIMでもHEVCの方がきれいに見えるかな あとはだいたい数値通り なんでQSVはHEVCよりH264の方が高性能なん? >>283 ビットレートが載ってるんだから必要ないと思うけど、何故に? 実写の方はrigaya氏のQSVBenchmarkに含まれてる2分53秒の動画で、 アニメOPの方は1分30秒くらいだろうから、ファイルサイズはそこから計算できると思うが。 >>282 なんでって現状そういう実装になってるから、としか まだ、QSVのHEVCエンコードは出たばかりだし、今後改善される可能性はあると思う 一応、このグラフで使ってるのはKaby Lakeで、QSVは最新世代のはず Pascal世代のNVEncもHEVCの性能は相対的に低かったから、実写ではH264の方がSSIM高かったよ (グラフには載せてないけど2070のH264は実写でもHEVCより少し低い) >>281 乙 これはある意味、衝撃的な結果とも言えるね アニメのほうから見ていくと、「x265 midium main10」と「2070 B=3 HEVC main10」が ほぼ同じSSIMと言っていいレベルで第1位と第2位! 画質のみで判断する場合、「QSV」と「x264」は、アニメに関してはもはや不要と言いたいレベル! 実写に関しては「x265」と「x264」がほぼ同点のトップ3タイと言っていい感じかな 次点で「2070 B=3 HEVC main10」と「QSV H264」が同じようなSSIMだが、全体としては 「2070 B=3 HEVC main10」のほうが若干優勢 おそらくよりビットレートを高く設定できる場合になればなるほど「2070 B=3 HEVC main10」のほうが 優勢になりそうな傾向 ※「2070 B=3 HEVC main10」で12000kbps以上ならば「x265」や「x264」と相当いい勝負になりそうな傾向 「QSV HEVC」は実写でも出る幕ないね 意外だったのが、「1060 HEVC main10」 アニメでは中位につけるも、実写では下位グループと振るわず 全体として、ギリギリまでファイル容量を削減したいのであれば「x265」で詰めるべきだろうけど、そこまで削減する 必要はなく、それよりも高速で処理できるほうがいいというのであれば、「2070 B=3 HEVC main10」でビットレートを x265比で2割増し程度にする設定にしておけば、もはや十分な結果が得られると言えるのではないだろうか >>281 ありがたい 実写は何使ってもSSIM厳しいなー 数値化された指標ってそれしかないんじゃないのかな なら仕方ない話で 俺はそれはそれ話半分で聞いてる >>289 SSIMのみで画質のすべてを語れるわけではないけれど、重要な指標になりうることは確か >>281 のテストの場合、画質として差が出ると判断できるだけの数値の差が出ているところから見て Turing世代のHEVCエンコーダーの実用性が高いと判断することはできる あまり話題には出ないがNVEncの場合、H.264、H.265ともにLOSSLESSエンコードもできるようになっているので、 今後ノートPC用のTuring世代GPUが出た場合、ノートPCにキャプチャー機器を接続してLOSSLESSでキャプチャーし 編集などしたのちH.265に再エンコードして保存などということも楽々とできるようになるのだろう CPUやメモリーに必要以上に金つぎ込むよりGPUに金つぎ込んだほうが得られるメリットが確実に高くなる むしろ気になったのは改善度合いのわりにNvidiaのアピールとか情報開示が控えめな感じがするところ HEVCのBフレーム対応はQSVが先にやっているとはいえ、充分Turingの売りになると思うんだけどな >>293 Netflixあたりが使っているようだね 使う意味はあるかと >>294 動画の品質を重視する層には確かにウリ文句にはなるだろうけど、そもそもNVIDIAは PureVideoにしてもそうだが世代の違いで何がよくなったかとかそういう情報を細かく 発信しようとしない風潮があるので、伝統的に商売の仕方がヘタクソな会社だとは言える。 特にノート用のGeForceなんかだとMaxwell世代は厳密には3つの区分で見分けないといけないのに、 GTX 965Mなんか公式情報すらあやふやというとんでもない状態を放置したままだし GTX 965MはMaxwell世代のモバイル用GPUには珍しく、HEVCやVP9の再生支援が搭載されているのに! ・NVIDIA VIDEO CODEC SDK https://developer.nvidia.com/nvidia-video-codec-sdk (※GTX 965Mは「Maxwell (GM206)」に該当) これはNVIDIAに限らず、Intelも同様の傾向があるけれど (Intelの場合、新しい世代であっても再生支援を使って動画再生をするとカクカクした動きになることすら あるからなおのこと始末が悪いが…) この手の業界の連中は、ともすれば「コミュ障か!」と突っ込みたくなる傾向が強いのが最大の弱点 > Codec: H.264/AVC > ... > Field Encoding no これ何かと思ったら、H264のインタレサポートが無くなってたわ NVEncCで--tffオプション指定するとエラーになった > interlaced output is not supported for current setting. インタレ保持エンコができなくなるとは・・・これも時代の流れか 要するに、60pは対応するが60iは捨てられたのか まあ面発光する表示デバイスしか無くなってるからな 有機ELはあるが 60iから60pへのip変換は出来るのかな? >>294 nvidiaが詳細明示せずSDKやAPIで叩いて実際の挙動見ろ的なのは何時もの事なのでは? きょーび動画がらみの機能は訴求力ない ゲームのフレームレート至上主義や 出始めの頃はDCTだ動き補償だなんだと 並び立てて煙幕張ってたが Rage128とかそんな頃w >>297 インターレースは非対応ですか 時代の流れと言えばそれまでですが、いささか早すぎるような気もするけれど 放送はこれから先も2K以下についてはインターレースのまま継続するのだし ただ、インターレースが動画圧縮を行う上で非効率なことは間違いないし、 再生機器でのリアルタイムインターレース解除より、QTGMCなどであらかじめ じっくり解除しておいたほうがきれいなことは間違いないわけで ※4Kテレビなどで2K放送などをアップコンバートして表示している映像を見ると、 インターレース解除がうまくできていないことによるジャギジャギ感が目につき 気になって仕方がない 問題は、RTX20*0世代に搭載されているハードウェアのインターレース解除が QTGMCクラスの品質をもっていれば簡単に対応できるのだけれども、おそらく インターレース解除の品質につては特に変化はないのではないかと思われ となると、インターレース解除のためだけにQTGMCなどを利用することになる のだけれど、これをGUI環境で使えるAmatsukazeはts信号の処理専用のようなので ハードウェアキャプチャーなどをした素材の取り込みには向かない様子 望みがあるとすれば、>>292 でも書いたH.264及びH.265のLOSSLESSエンコードに 対応しているGeForceにてH.264のLOSSLESSエンコードでキャプチャーし、ts形式で 保存したファイルをAmatsukazeが読み込めるようであればこのストーリーは辛うじて 成立するかもしれないけれど、こればかりは試してみないとわからない ※NVEncのLOSSLESSエンコードに関する具体的な資料は乏しすぎる それを確かめる機材としてGeForce GTX965M搭載のゲーミングPCが1台格安で手に 入りそうなので、手に入れば実験してみようかと思っているのだけれど… キャプチャする対象をインタレと決めつけてるけど ソースは何を想定してるのよ? amatsukazeはts信号処理と言ってるから放送波なんじゃね 撮影ts化する人はいないだろうから、放送波だろうな いやね、tsならファイル扱えば良い訳で レス元のみたいなキャプチャー機器使う環境をあげてる人へのレスで、何処からインタレとかの発想出てきたのかと DVDやBDのインタレソースにAmatsukazeのKTGMC使ってみてえな >>303 QTGMCなんて只のavisynthの関数だろ? 自分でスクリプト書いて使えばいいだけ。 それが出来ないレベルなのか。 >>311 だからインタレのキャプチャなんぞDVDプレイヤーやD端子以前の旧世代の機器の出力とか、旧世代のインタレ表示機器向けの信号取り込もうとしない限り今じゃ無いでしょ 後者なら出力側をプログレにすりゃ良いのだから、わざわざインタレ出力にしてまで取り込む意味が無いし インタレとも書いてない書き込みに付けるレスとしては謎すぎる レコとかテレビ任せのインタレ解除よりQTGMCのほうが綺麗でしょ QTGMC単体だと副作用多すぎなのでQTGMC+KFMか なんだか勘違いしている人がいるようだな ts化するというのはAmatsukazeがtsしか受け付けないからtsで保存と言っているわけなのだが… 個人的には大事な録画をサポートはおろか何の保証もないBonDriverを使ったts録画に任せる気には ならないので、録画はレコーダーでしているけれど (放送局側の都合で突然仕様が変更されて録画できなくなってもどうすることもできないし) キャプチャーは主にアナログ時代に録画したものやD-VHSで録画したものを念頭に置いている 特にD-VHSからのキャプチャーはドロップアウトとの戦いもあるから念入りにしなければならないので まぁ一人アレルギー反応示している人がいるからこの件はクローズにしておきましょ >>318 >>(放送局側の都合で突然仕様が変更されて録画できなくなってもどうすることもできないし) ISDB規格って知ってる? もしPT3とかで録画出来なくなったら他の民生品レコーダーも全滅だよ。 (続き) そこで、ffmpegではどうなっているのか念のため確認してみたかったのですが、 うちは残念ながらIntelノートなので、代わりに H264:yuv420p/yuv444p, HEVC:yuv420p/yuv444p/yuv420p10le/yuv444p10le の6パターンについて ffmpeg -i yuv4**p*.y4m -pix_fmt yuv4**p* -c:v h***_nvenc -preset lossless out.mp4 でロスレスエンコしてみて、出力形式とSSIMを確認するバッチファイルを作ってみました。 https://www.axfc.net/u/3944339.zip (同梱ffmpeg/ffprobeはZeranoe氏の4.0.2) ダブルクリック1発で、結果は https://pastebin.com/AcNCu9V3 のような感じで記録されるので、PascalやTuringなどの環境をお持ちで 気が向いた方がいたら、試して結果を教えてもらえるとありがたいです。 (できればoutputフォルダをzipにしてAxfc等にアップロードしてもらえると エラーが発生した場合の原因などもわかるので助かります) よろしくお願いいたします。 ffmpegは全部対応してるけど、rigaya氏のNVEncCはh264のYUV444にしか対応してないようだね HEVCやYUV420を使いたい場合はffmpeg使うしかないっぽい h264のYUV444に比べてHEVCのYUV420はサイズが半分近くまで減るし >>323 ありがとうございます。環境にあわせてテストしていただいたようで申し訳ない。 ログを確認させていただきましたが、Pascal(GTX 1060)、Turing(RTX 2070)ともに、 420/444、8/10bitの全パターンでちゃんと一致したフォーマットで可逆になってますね。 YUV4:2:0でもロスレスエンコードできると考えてよさそうです。 とりあえずrigayaさんのブログに情報としてお知らせしておこうと思います。 ご協力いただき、ありがとうございました。 >>324 一応NVEnc3.05でHEVCのロスレス出力に対応しているようです。 また、現在は--losslessが指定された時点でYUV 4:4:4出力にする実装になっているようなので、 HEVCのYUV 4:4:4ロスレス出力はできるのではないかと。 NVEncのマニュアルである https://github.com/rigaya/NVEnc/blob/master/NVEncC_Options.ja.md の --lossless の説明には「H.264のみ」とありますが、これは修正漏れのようで、helpでは --lossless for lossless (YUV444 only) / default: off となっています。 >>326 NVEnc4.21だけど、 NVEncC64.exe -c h264 --lossless -i input.y4m -o output.mp4 これはOK > Rate Control CQP I:0 P:0 B:0 (lossless) って表示されるし、ssimは1.0になる NVEncC64.exe -c hevc --lossless -i input.y4m -o output.mp4 これはロスレスにはならなかった > Rate Control CQP I:0 P:0 B:0 "(lossless)"って表記がなくなってるし、ssimが1.0にならない これ以外のオプション指定の仕方が分からない >>327 そうなると自分もちょっとわかりませんね・・・。 AviUtlから拡張NVEnc出力を使ってHEVCを選んで、readmeにあるように 「CQPでIフレーム、Bフレーム、PフレームのQP値を0にする」 で出力するのを試してみるという手もありますが、同じ結果になる可能性が高そうな・・・。 一応ロスレス出力のファイルサイズまとめ。(640x360, 30frames, ffmpeg 4.0.2) nvencは、 Turing(RTX 2070) / Pascal(GTX 1060) の結果。 ■yuv420p libx264 medium 4.52 MB libx264 veryslow 4.36 MB libx265 medium 4.65 MB libx265 veryslow 4.35 MB h264_nvenc 5.15 MB / 5.23 MB hevc_nvenc 4.70 MB / 4.75 MB ■yuv444p libx264 medium 7.49 MB libx264 veryslow 7.20 MB libx265 medium 7.83 MB libx265 veryslow 7.25 MB h264_nvenc 8.52 MB / 8.70 MB hevc_nvenc 7.88 MB / 7.94 MB ■yuv420p10le libx264 medium 7.17 MB libx264 veryslow 6.95 MB libx265 medium 7.14 MB libx265 veryslow 6.67 MB hevc_nvenc 7.23 MB / 7.29 MB ■yuv444p10le libx264 medium 12.3 MB libx264 veryslow 11.9 MB libx265 medium 12.5 MB libx265 veryslow 11.6 MB hevc_nvenc 12.6 MB / 12.7 MB >>303 などでNVEncのLOSSLESSエンコードについて書いていた者だけど、俺より先にいろいろテストしてくれている人がいるようなので とても助かります 今、気になっていることが二つあります 1.「AVerMedia Live Gamer Ultra」をレビュー。 高画質&高速プレイを妥協せず、手軽に快適な録画・配信環境を構築できるUSB外付け機器型ビデオキャプチャ http://blog.livedoor.jp/wisteriear/archives/1071577199.html#more という記事の中で紹介されている 「上のようにGPUハードウェアエンコードとCPUによるソフトウェアエンコードの間に基本的には大きな差はありませんが、 NVENCについては特定の条件下でノイズが発生する可能性があるようです。」 ・CPUエンコードの場合(問題なし) http://livedoor.blogimg.jp/wisteriear/imgs/2/e/2e3f1b76.jpg ・NVEncによるエンコードの場合(破綻している) http://livedoor.blogimg.jp/wisteriear/imgs/e/b/eb4742a8.jpg ・動画での確認 https://www.youtube.com/watch?v=Bzv6z2NKw5A このノイズがLOSSLESSの場合でも発生するのかどうか? 2.上記の問題はRTX20*0(Turing)世代のGPUでも相変わらず発生するのか? という点が気になっています そもそもこの問題はハードウェア的にどうしようもない問題なのか、それともドライバーソフトなど含めたソフトウェアレベルで 改善出来うる問題なのか 果たして真相やいかに? AVerMediaのAVT-C878を使ってる感じだとPS4-単体録画モードでもたまにコマ落ちしてるよ あとそのサイトの話だと途中59.94FPS録画もあったり条件がそろってないから注意ね >>330-331 ノイズや破綻の発生と言っても、 ・SW側の実装の問題(NVEncをどのような設定で呼び出しているのか等) ・HWや環境側の問題(電源不安定や突発的な負荷増加等) ・NVEncやドライバ側の問題 など、要因が多数あるわけで、「発生しない」なんて言い切ることは誰にもできないと思うよ。 あと、ぶっちゃけた話、ロスレスキャプチャにこだわらない方がいいと思う。 >>323 のテスト結果を見ると、 RTX2070/HEVC/yuv420pロスレス/640x360/29.970fps → ビットレート 39.4Mbps になっている。1080p30に換算すると単純計算で9倍で354.6Mbpsになる。 「データ量が膨大になってもいいからロスレス(可逆)キャプチャしたい」という強いこだわりがあるなら別に止めないけど、 得られる画質は数分の1のビットレートで通常の非可逆キャプチャした場合と大差ないだろうし、 ロスレスだからといって編集時のデコード処理等が軽くなるわけでもないし、 最終的に保存エンコしたりYoutube等にアップロードすることを考えると、どうせその画質も保持できないわけだし。 >>333 補足 > 1080p30に換算すると単純計算で9倍で354.6Mbpsになる さすがに雑すぎてつっこまれそうなので一応縮小前の素材を使ってlibx265で確認したら libx265/veryslow/yuv420p/640x360/29.970fps → 36.5 Mbps libx265/veryslow/yuv420p/1920x1080/29.970fps → 229 Mbps (360pの約6.27倍) という感じだった。 >>330-331 キャプチャボード付属のソフトでエンコードしてるから、 どっちかというとドライバやHWよりそのソフト側に問題がある可能性が高そう NVEncやffmpegでも同じ現象が発生するなら別だけど、 そういう破綻は俺は見たことも聞いたこともないなぁ 4K60fpsYUV444でロスレスなんてやったら700MB/sくらいになるから、 SATAじゃ帯域足りなくて、M2でやっとって感じ。相当やばそうw --- 2018.11.03 NVEnc 4.22 [共通] ・yuv420のlossless出力に対応。 [NVEncC] ・Caption.dllによる字幕抽出処理を実装。(--caption2ass) ・--check-featuresでGPU名が正しく表示されていなかったのを修正。 ・--check-featuresにバージョン情報も出力するように。 ・--check-environmentの出力先をstderrからstdoutに。 --- はやいもうできたのか(感謝) >>327 のHEVCロスレスの件についてはどうなったのか不明。 >>337 HEVCは10bitも含めて全部できるようになってたわ! [NVEnc 4.22v2] (※2018/11/3 23.37) NVEnc 4.22でlosslessでないときもlosslessと表示されてしまっていたのを修正。 GTX1050でもHEVC H265エンコ快適に出来ますか? 世代格差によって画質も向上してるなら買い換えも検討します。 >>341 スレのログを読めばTuringでHEVCのBフレームに対応したのがわかるので、 画質を重視するならTuringへの買い替えを検討すればいいと思う。 もしかすると今後のSDKやドライバーの更新でPascal等にも HEVCのBフレーム利用が開放される可能性もあるけど、まだ不明だし。 Turingは今のところNVENCコアが1つしか載ってないらしいという情報もあるので、 並列エンコを効率よく行いたいという要望があるなら NVENCコアが複数載っているGTX1080なんかも候補にあがるだろうけど。 https://developer.nvidia.com/video-encode-decode-gpu-support-matrix ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる