【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】
■ このスレッドは過去ログ倉庫に格納されています
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 >>297
>NVEncCで--tffオプション指定するとエラーになった
って事は--avhw --tff --vpp-deinterlace normal -i in.ts -o out.mp4
とかも駄目なの? >>344
インタレのままMP4には出来ないって事ね。
了解。 RTX 2080 Ti の NVEncC64.exe --check-featuresの結果
https://devtalk.nvidia.com/default/topic/1038493/video-codec-sdk/details-about-nvenc-in-turing-/post/5294644/#5294644
・機能項目の内容はRTX2070と一致
・質問時に>>259の内容を引用させていただきました
その後の記述によると、
・Win10 + 2080Ti + ドライバ416.34(現時点最新) + ffmpeg4.0 → hevc_nvencでBフレーム指定(-bf)が効く
・Linux + 2080Ti + ドライバ410.73(現時点最新) + ffmpeg4.0 → hevc_nvencでBフレーム指定(-bf)するとエラー
となるらしい。 上位モデルでのNVEnc2基搭載やめると、本来の目的であるクラウドでのGPU仮想化して描画を配信する手のサービスでの更新機器に当てられなくなるから大問題になるけども
1070やGP104搭載1060が、後からNVEncの2基目開放されたみたいに、物理的に実装されてりゃドライバでどうにでもなる クラウドでGeForceは使われない。というかNVIDIAが禁止してる
https://pc.watch.impress.co.jp/docs/news/1099481.html
NVEnc1基しか載せない、あるいはドライバで1基しか使えないようにする
というのはTeslaやQuadroと差別化するためのNVIDIAの戦略でしょ
最新のNVIDIAは結構えげつないことしてくるからね >>348
使えないのと載っていないというのは違うでしょ
「載っていない」と言ったらTU102や104に載っていないだし
「使えない」なら現状でコンシューマ向けでリリース済みで一般で入手可能なGEFORCE RTXで現状使えないという解釈になるでしょ
フォーラム関係の報告も正式対応じゃ無いドライバでで報告された情報から更新されて居ないまま拡散してるのも多い
何故かフライングで検証して報告できる奴が、その後の正規対応ドライバでの追加報告とかしていないままだったり
あとSupport Matrixのところは更新入るのが毎度遅い(多分Quadroが市場流通し始める前後あたりとか) 久しぶりに来たけど最近のハートエンコは画質上がったのねー >>349
載ってるかどうかは知らないけど、載せる必要もないし、載ってたとしても使えるようにする必要もないって話 >>347
> 1070やGP104搭載1060が、後からNVEncの2基目開放されたみたいに
GP104搭載1060は、8月時点のSupport Matrixでは2基とされてるけど、現在はひっそりと分離されて1基になってるね・・・。
8月の一覧
https://web.archive.org/web/20180814195717/https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
現在の一覧
https://web.archive.org/web/20181105054441/https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
1070の2基目って、後から解放されたの? >>352
元は>>347へのレスなんだから、
「そもそもクラウドでのGeForceの利用は禁止されてるんだから、
クラウド用更新機器としての利用の都合を考える必要はなく、
GeForceにNVEncを何基載せるか、何基有効にするかはNVIDIAのさじ加減次第。」
ってことだと思うよ。
現状のTuringでNVENcが1基しか載っていない、あるいは1基しか有効になっていないという根拠は
>>264とかにあるようにフォーラムでのユーザ報告のみで、NVIDIAの公式情報ではないから、
正確な情報は公式情報の更新を待つしかなさそうだけどね。
スペック発表の際にNVENC/DECの詳細情報も含めるとか、もっと素早く動いてくれればいいのにねえ。 >>353
ひどい話だ〜 GigaByteのパッケージみてのGP104のGTX1060に期待してたのに・・・ >>355
昔は抵抗張替でdevice id書き換えられたんだが、今は無理みたいね。 選別落ちの眠ってるコアを有効にするのは楽しかったねぇ
8月時点のSupport Matrixの誤植ってだけかもしれないけどね
ゲームしないのに1070や2070はちょっと手が出ないです ■ このスレッドは過去ログ倉庫に格納されています