【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】
■ このスレッドは過去ログ倉庫に格納されています
>>223 そう、CUDAとNVENCじゃ全く違う GTX1060(6G)でH265エンコしまくりですわ。 RTX2070が7万だものなぁ そこまでは出費したくないから2050か2030で・・・ スペック次第だけど gtx1060にはtiはないのですか? tiは無印と何が違うのでしょうか? ・【ニュース・フラッシュ】玄人志向、実売で7万円を切るGeForce RTX 2070 https://pc.watch.impress.co.jp/docs/news/news_flash/1149634.html 「価格はオープンプライスで、税別店頭予想価格は63,980円前後の見込み。」 >>227 Tiと無印に違いがあるというより、「無印とTiの間に何か関連性がある」という発想自体が間違い GTX1080と1080Tiのように、Tiが付いたら中身が全く別物になるパターンもある 法則性があるわけではないので、何が違っているのかは自分で一つ一つ把握するしかない 20シリーズの性能ベンチがほしいな 10シリーズとの比較で ほぼ値段相応だとは思うけど >>229 今ならドスパラで64800ってのもあるけどな どれ? ドスパラとか祖父とか税別表示だからぬか喜びしないように気をつけてる ハードの値段やらの話は自作板にスレが多数あるんだから、そっちでやったほうがいいと思うよ。 RTX2070はTU106だから、GP106のGTX1060と一緒でNVEncのエンジンが1基しかないと思う Maxwell以降は上位のチップには2基積まれて、エンコ2本同時までは速度が落ちない(ただし3本以上同時エンコできるのはQuadroのミドル以上 数は1つでいいや 問題は性能で Bフレーム使えるみたいだけどその他もどれくらい 性能が上がってるのか気になる 気になるけど買えない 2060待ち >>235 106じゃなかった、104だすまん; 処理速度自体の向上は「高解像度で速度低下しづらくなった」ってだけなんで4K以上でエンコしないと殆ど動作クロックなりの速度よ RTX 2080でも2070でもいいけど、 NVEncC.exe --check-features で、H.265/HEVCの Max Bframes がどうなるか調べた人ってまだいないのかな? 479分 14GBあるAVを容量節約のためにNVENCでH.265の低ビットレートでエンコードしたが速くていいわ(汚い穴が綺麗に見えてしまうので低ビットレートで充分) >>239 新人のインタービューやワンパターンのやるだけ明るい部屋はいいけど、8時間BESTとかだと暗いシーン多くて暗部ひどくならね? リアルタイムエンコが目的だから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等にアップロードしてもらえると エラーが発生した場合の原因などもわかるので助かります) よろしくお願いいたします。 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる