X

【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠編集中 (ﾜｯﾁｮｲ 4381-Xflc)
垢版 |
2018/08/08(水) 04:44:09.82ID:NnYmcXUx0
ソフトウェアエンコーダーに画質は劣るものの、エンコード完了までの処理速度が爆速なハードウェアエンコーダーを語りましょう

●Intel
・https://software.intel.com/en-us/media-sdk
・https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video

●NVIDIA
・https://developer.nvidia.com/nvidia-video-codec-sdk
・エンコード： https://en.wikipedia.org/wiki/Nvidia_NVENC
・デコード： https://en.wikipedia.org/wiki/Nvidia_PureVideo

●AMD
・https://github.com/GPUOpen-LibrariesAndSDKs/AMF
・エンコード： https://en.wikipedia.org/wiki/Video_Coding_Engine
・デコード： https://en.wikipedia.org/wiki/Unified_Video_Decoder
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured
0246名無しさん＠編集中 (ﾜｯﾁｮｲWW 9fc3-8G0i)
垢版 |
2018/10/25(木) 12:36:20.43ID:STwk5yxX0
そもそも、H265の圧縮率向上の根幹はI/Pフレの圧縮率向上が大きいからな
だからNVEncのマクロブロック配置ロジックの強化されてもH264に効果が殆ど無くてH265の方に効果が出てる
元々がGPUのクラウド化で画面転送するためのエンジンを転用・下位モデルにも解放してるものだし
わざわざ面倒な方の性能向上するぐらい低レイテンシ保持が大事という
0247名無しさん＠編集中 (ｽﾌﾟｯｯ Sdaf-2TN5)
垢版 |
2018/10/25(木) 13:41:09.39ID:bUPCRSoJd
265のエンコご優れてるのは分かったのですが
動画再生時デコードにパワー要りますよね？
古いpc環境とか人にも見せたいとか、モバイルでも見たいなら
264の方がまだ使い勝手が良いですか？
0249名無しさん＠編集中 (ﾜｯﾁｮｲ f7ec-7TBo)
垢版 |
2018/10/25(木) 17:26:52.29ID:rQ/d4Tyo0
>>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を使った方がいいと思うよ。
0256名無しさん＠編集中 (ﾜｯﾁｮｲ 8fc3-7TBo)
垢版 |
2018/10/26(金) 20:48:35.08ID:4O36bTgr0
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
0264名無しさん＠編集中 (ﾜｯﾁｮｲ 45ec-7TBo)
垢版 |
2018/10/27(土) 00:03:15.28ID:ys8cVnL20
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．「今の時点では数か月以内としか言えないっす。」
0270名無しさん＠編集中 (ﾜｯﾁｮｲ 57e8-wZW4)
垢版 |
2018/10/27(土) 01:09:28.23ID:EhqLT3Ob0
>>267
10xxも併売するらしいから無理じゃない？
NVIDIAはNVENCを付加価値にしてるから
実売1万円以下のカードに乗ることは当分無さそう。
AMDに頑張ってほしい、
5千円で買ったx30,x40でNVENCが動くって今では無理だもんな
0271名無しさん＠編集中 (ﾜｯﾁｮｲWW 9fc3-U+1r)
垢版 |
2018/10/27(土) 01:52:47.92ID:Q9KzXn1A0
Bフレ数は参照距離とかの兼ね合いで品質評価や圧縮効率にも影響するからエンコーダと設定値による
基本的に参照距離より大きくなると圧縮効率が下がるからBフレ増やす意義が下がる
0277名無しさん＠編集中 (ﾜｯﾁｮｲ 5306-t6cX)
垢版 |
2018/10/27(土) 16:49:16.70ID:d7Sa2MDK0
まぁレス番もつけずに比較出せって言われてもな
善意でエスパー反応しても後出しで証拠だせとか
追加であれやれこれやれっていうのが沸くだけだし
自分でやってみればっていわれるのが落ちだぞ
0284名無しさん＠編集中 (ﾜｯﾁｮｲ 4dec-7TBo)
垢版 |
2018/10/28(日) 01:24:13.21ID:42x5MzyR0
>>283
ビットレートが載ってるんだから必要ないと思うけど、何故に？
実写の方はrigaya氏のQSVBenchmarkに含まれてる2分53秒の動画で、
アニメOPの方は1分30秒くらいだろうから、ファイルサイズはそこから計算できると思うが。
0285名無しさん＠編集中 (ﾜｯﾁｮｲ 8fc3-7TBo)
垢版 |
2018/10/28(日) 01:35:24.69ID:GZzWkstI0
>>282
なんでって現状そういう実装になってるから、としか
まだ、QSVのHEVCエンコードは出たばかりだし、今後改善される可能性はあると思う
一応、このグラフで使ってるのはKaby Lakeで、QSVは最新世代のはず

Pascal世代のNVEncもHEVCの性能は相対的に低かったから、実写ではH264の方がSSIM高かったよ
（グラフには載せてないけど2070のH264は実写でもHEVCより少し低い）
0286名無しさん＠編集中 (ﾜｯﾁｮｲ 8de9-pP8n)
垢版 |
2018/10/28(日) 02:46:35.85ID:mrO/Sdoo0
>>281
乙
これはある意味、衝撃的な結果とも言えるね

アニメのほうから見ていくと、「x265 midium main10」と「2070 B=3 HEVC main10」が
ほぼ同じSSIMと言っていいレベルで第1位と第2位！
画質のみで判断する場合、「QSV」と「x264」は、アニメに関してはもはや不要と言いたいレベル！
0287名無しさん＠編集中 (ﾜｯﾁｮｲ 8de9-pP8n)
垢版 |
2018/10/28(日) 02:46:51.15ID:mrO/Sdoo0
実写に関しては「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割増し程度にする設定にしておけば、もはや十分な結果が得られると言えるのではないだろうか
0292名無しさん＠編集中 (ﾜｯﾁｮｲ 5723-pP8n)
垢版 |
2018/10/28(日) 15:45:20.66ID:3GVWrMAV0
>>289
SSIMのみで画質のすべてを語れるわけではないけれど、重要な指標になりうることは確か
>>281のテストの場合、画質として差が出ると判断できるだけの数値の差が出ているところから見て
Turing世代のHEVCエンコーダーの実用性が高いと判断することはできる

あまり話題には出ないがNVEncの場合、H.264、H.265ともにLOSSLESSエンコードもできるようになっているので、
今後ノートPC用のTuring世代GPUが出た場合、ノートPCにキャプチャー機器を接続してLOSSLESSでキャプチャーし
編集などしたのちH.265に再エンコードして保存などということも楽々とできるようになるのだろう
CPUやメモリーに必要以上に金つぎ込むよりGPUに金つぎ込んだほうが得られるメリットが確実に高くなる
0294名無しさん＠編集中 (ﾜｯﾁｮｲ 7b9f-7TBo)
垢版 |
2018/10/28(日) 19:43:45.84ID:dqPT1FY80
むしろ気になったのは改善度合いのわりにNvidiaのアピールとか情報開示が控えめな感じがするところ
HEVCのBフレーム対応はQSVが先にやっているとはいえ、充分Turingの売りになると思うんだけどな
0295名無しさん＠編集中 (ﾜｯﾁｮｲ 5723-pP8n)
垢版 |
2018/10/28(日) 20:32:21.34ID:3GVWrMAV0
>>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)」に該当）
0296名無しさん＠編集中 (ﾜｯﾁｮｲ 5723-pP8n)
垢版 |
2018/10/28(日) 20:32:38.99ID:3GVWrMAV0
これはNVIDIAに限らず、Intelも同様の傾向があるけれど
（Intelの場合、新しい世代であっても再生支援を使って動画再生をするとカクカクした動きになることすら
あるからなおのこと始末が悪いが…）

この手の業界の連中は、ともすれば「コミュ障か！」と突っ込みたくなる傾向が強いのが最大の弱点
0297名無しさん＠編集中 (ﾜｯﾁｮｲ 8fc3-7TBo)
垢版 |
2018/10/29(月) 04:39:38.65ID:AzT2hbUL0
> Codec: H.264/AVC
> ...
> Field Encoding no

これ何かと思ったら、H264のインタレサポートが無くなってたわ
NVEncCで--tffオプション指定するとエラーになった

> interlaced output is not supported for current setting.

インタレ保持エンコができなくなるとは・・・これも時代の流れか
0298名無しさん＠編集中 (ﾜｯﾁｮｲWW 076e-vV9E)
垢版 |
2018/10/29(月) 08:38:43.00ID:01sVuNYh0
要するに、60pは対応するが60iは捨てられたのか
まあ面発光する表示デバイスしか無くなってるからな
有機ELはあるが

60iから60pへのip変換は出来るのかな？
0300名無しさん＠編集中 (ｱｳｱｳｶｰ Sad3-6ZOO)
垢版 |
2018/10/29(月) 09:57:06.91ID:dU/S2c/9a
きょーび動画がらみの機能は訴求力ない
ゲームのフレームレート至上主義や
出始めの頃はDCTだ動き補償だなんだと
並び立てて煙幕張ってたが
Rage128とかそんな頃ｗ
0302名無しさん＠編集中 (ﾜｯﾁｮｲ 8de9-pP8n)
垢版 |
2018/10/30(火) 01:57:43.60ID:6swiaWs40
>>297
インターレースは非対応ですか
時代の流れと言えばそれまでですが、いささか早すぎるような気もするけれど
放送はこれから先も2K以下についてはインターレースのまま継続するのだし

ただ、インターレースが動画圧縮を行う上で非効率なことは間違いないし、
再生機器でのリアルタイムインターレース解除より、QTGMCなどであらかじめ
じっくり解除しておいたほうがきれいなことは間違いないわけで

※4Kテレビなどで2K放送などをアップコンバートして表示している映像を見ると、
インターレース解除がうまくできていないことによるジャギジャギ感が目につき
気になって仕方がない
0303名無しさん＠編集中 (ﾜｯﾁｮｲ 8de9-pP8n)
垢版 |
2018/10/30(火) 01:57:58.08ID:6swiaWs40
問題は、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台格安で手に
入りそうなので、手に入れば実験してみようかと思っているのだけれど…
0307名無しさん＠編集中 (ﾜｯﾁｮｲWW 9fc3-8G0i)
垢版 |
2018/10/30(火) 12:02:45.30ID:Cr8xUI/50
いやね、tsならファイル扱えば良い訳で
レス元のみたいなキャプチャー機器使う環境をあげてる人へのレスで、何処からインタレとかの発想出てきたのかと
0312名無しさん＠編集中 (ﾜｯﾁｮｲWW 9fc3-8G0i)
垢版 |
2018/10/30(火) 19:38:56.39ID:Cr8xUI/50
>>311
だからインタレのキャプチャなんぞDVDプレイヤーやD端子以前の旧世代の機器の出力とか、旧世代のインタレ表示機器向けの信号取り込もうとしない限り今じゃ無いでしょ
後者なら出力側をプログレにすりゃ良いのだから、わざわざインタレ出力にしてまで取り込む意味が無いし
インタレとも書いてない書き込みに付けるレスとしては謎すぎる
0318名無しさん＠編集中 (ﾜｯﾁｮｲ 8de9-pP8n)
垢版 |
2018/10/31(水) 03:03:56.44ID:HL+tE8NE0
なんだか勘違いしている人がいるようだな
ts化するというのはAmatsukazeがtsしか受け付けないからtsで保存と言っているわけなのだが…

個人的には大事な録画をサポートはおろか何の保証もないBonDriverを使ったts録画に任せる気には
ならないので、録画はレコーダーでしているけれど
（放送局側の都合で突然仕様が変更されて録画できなくなってもどうすることもできないし）

キャプチャーは主にアナログ時代に録画したものやD-VHSで録画したものを念頭に置いている
特にD-VHSからのキャプチャーはドロップアウトとの戦いもあるから念入りにしなければならないので
まぁ一人アレルギー反応示している人がいるからこの件はクローズにしておきましょ
0319名無しさん＠編集中 (ﾜｯﾁｮｲ 57e8-7TBo)
垢版 |
2018/10/31(水) 12:14:43.06ID:vRp2peue0
>>318
>>（放送局側の都合で突然仕様が変更されて録画できなくなってもどうすることもできないし）
ISDB規格って知ってる？
もしPT3とかで録画出来なくなったら他の民生品レコーダーも全滅だよ。
0321名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-MyS3)
垢版 |
2018/11/03(土) 01:55:10.07ID:uB0majyg0
NVEncのロスレスエンコードについて。
去年rigaya氏からは「ロスレスはYUV 4:4:4のみ」という回答をいただいており、
実際にNVEncCのhelpだと --lossless は「YUV444 only」になってるのですが、
以下でのやりとりを見ると、YUV 4:2:0でもできそうな気配が無きにしもあらず。

　https://devtalk.nvidia.com/default/topic/1029036/video-codec-sdk/enable-lossless-feature/
　https://devtalk.nvidia.com/default/topic/1024699/-nvidia-video-codec-sdk-lossless/
　https://devtalk.nvidia.com/default/topic/992481/video-codec-sdk/lossless-hp-encoder-producing-serious-artifacts/

(続く)
0322名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-MyS3)
垢版 |
2018/11/03(土) 01:57:27.24ID:uB0majyg0
(続き)
そこで、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)

ダブルクリック１発で、結果は
　https://pastebin.com/AcNCu9V3
のような感じで記録されるので、PascalやTuringなどの環境をお持ちで
気が向いた方がいたら、試して結果を教えてもらえるとありがたいです。
(できればoutputフォルダをzipにしてAxfc等にアップロードしてもらえると
　エラーが発生した場合の原因などもわかるので助かります)

よろしくお願いいたします。
0324名無しさん＠編集中 (ﾜｯﾁｮｲ 27c3-MyS3)
垢版 |
2018/11/03(土) 03:13:14.80ID:J40rNpwz0
ffmpegは全部対応してるけど、rigaya氏のNVEncCはh264のYUV444にしか対応してないようだね
HEVCやYUV420を使いたい場合はffmpeg使うしかないっぽい
h264のYUV444に比べてHEVCのYUV420はサイズが半分近くまで減るし
0325名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-MyS3)
垢版 |
2018/11/03(土) 03:13:52.29ID:uB0majyg0
>>323
ありがとうございます。環境にあわせてテストしていただいたようで申し訳ない。

ログを確認させていただきましたが、Pascal(GTX 1060)、Turing(RTX 2070)ともに、
420/444、8/10bitの全パターンでちゃんと一致したフォーマットで可逆になってますね。
YUV4:2:0でもロスレスエンコードできると考えてよさそうです。

とりあえずrigayaさんのブログに情報としてお知らせしておこうと思います。
ご協力いただき、ありがとうございました。
0326名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-MyS3)
垢版 |
2018/11/03(土) 03:37:43.12ID:uB0majyg0
>>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
となっています。
0327名無しさん＠編集中 (ﾜｯﾁｮｲ 27c3-MyS3)
垢版 |
2018/11/03(土) 03:55:29.32ID:J40rNpwz0
>>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にならない
これ以外のオプション指定の仕方が分からない
0328名無しさん＠編集中 (ﾜｯﾁｮｲ 37ec-MyS3)
垢版 |
2018/11/03(土) 04:06:01.76ID:uB0majyg0
>>327
そうなると自分もちょっとわかりませんね・・・。
AviUtlから拡張NVEnc出力を使ってHEVCを選んで、readmeにあるように
　「CQPでIフレーム、Bフレーム、PフレームのQP値を0にする」
で出力するのを試してみるという手もありますが、同じ結果になる可能性が高そうな・・・。
0329名無しさん＠編集中 (ﾜｯﾁｮｲ d7ec-MyS3)
垢版 |
2018/11/03(土) 07:35:14.62ID:oyWwovRq0
一応ロスレス出力のファイルサイズまとめ。(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
0330名無しさん＠編集中 (ﾜｯﾁｮｲ 9ab7-ZA70)
垢版 |
2018/11/03(土) 17:06:40.04ID:3hZOcD7m0
>>303などでNVEncのLOSSLESSエンコードについて書いていた者だけど、俺より先にいろいろテストしてくれている人がいるようなので
とても助かります

今、気になっていることが二つあります

1．「AVerMedia Live Gamer Ultra」をレビュー。
高画質＆高速プレイを妥協せず、手軽に快適な録画・配信環境を構築できるUSB外付け機器型ビデオキャプチャ
http://blog.livedoor.jp/wisteriear/archives/1071577199.html#more

という記事の中で紹介されている
「上のようにGPUハードウェアエンコードとCPUによるソフトウェアエンコードの間に基本的には大きな差はありませんが、
NVENCについては特定の条件下でノイズが発生する可能性があるようです。」
0331名無しさん＠編集中 (ﾜｯﾁｮｲ 9ab7-ZA70)
垢版 |
2018/11/03(土) 17:07:10.59ID:3hZOcD7m0
・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でも相変わらず発生するのか？

という点が気になっています
そもそもこの問題はハードウェア的にどうしようもない問題なのか、それともドライバーソフトなど含めたソフトウェアレベルで
改善出来うる問題なのか
果たして真相やいかに？
0332名無しさん＠編集中 (ﾜｯﾁｮｲ 5b06-75/g)
垢版 |
2018/11/03(土) 17:27:09.65ID:xQq3bNCe0
AVerMediaのAVT-C878を使ってる感じだとPS4-単体録画モードでもたまにコマ落ちしてるよ
あとそのサイトの話だと途中59.94FPS録画もあったり条件がそろってないから注意ね
0333名無しさん＠編集中 (ﾜｯﾁｮｲ d7ec-MyS3)
垢版 |
2018/11/03(土) 18:48:20.13ID:oyWwovRq0
>>330-331
ノイズや破綻の発生と言っても、
　・SW側の実装の問題（NVEncをどのような設定で呼び出しているのか等）
　・HWや環境側の問題（電源不安定や突発的な負荷増加等）
　・NVEncやドライバ側の問題
など、要因が多数あるわけで、「発生しない」なんて言い切ることは誰にもできないと思うよ。
　
　
あと、ぶっちゃけた話、ロスレスキャプチャにこだわらない方がいいと思う。
>>323のテスト結果を見ると、
　　RTX2070/HEVC/yuv420pロスレス/640x360/29.970fps → ビットレート 39.4Mbps
になっている。1080p30に換算すると単純計算で9倍で354.6Mbpsになる。

「データ量が膨大になってもいいからロスレス(可逆)キャプチャしたい」という強いこだわりがあるなら別に止めないけど、
得られる画質は数分の１のビットレートで通常の非可逆キャプチャした場合と大差ないだろうし、
ロスレスだからといって編集時のデコード処理等が軽くなるわけでもないし、
最終的に保存エンコしたりYoutube等にアップロードすることを考えると、どうせその画質も保持できないわけだし。
0334名無しさん＠編集中 (ﾜｯﾁｮｲ d7ec-MyS3)
垢版 |
2018/11/03(土) 20:29:04.08ID:oyWwovRq0
>>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倍)
という感じだった。
0335名無しさん＠編集中 (ﾜｯﾁｮｲ 27c3-MyS3)
垢版 |
2018/11/03(土) 20:32:09.61ID:J40rNpwz0
>>330-331
キャプチャボード付属のソフトでエンコードしてるから、
どっちかというとドライバやHWよりそのソフト側に問題がある可能性が高そう
NVEncやffmpegでも同じ現象が発生するなら別だけど、
そういう破綻は俺は見たことも聞いたこともないなぁ

4K60fpsYUV444でロスレスなんてやったら700MB/sくらいになるから、
SATAじゃ帯域足りなくて、M2でやっとって感じ。相当やばそうｗ
0337名無しさん＠編集中 (ﾜｯﾁｮｲ d7ec-MyS3)
垢版 |
2018/11/03(土) 22:36:55.92ID:oyWwovRq0
---
2018.11.03 NVEnc 4.22
[共通]
・yuv420のlossless出力に対応。

[NVEncC]
・Caption.dllによる字幕抽出処理を実装。(--caption2ass)
・--check-featuresでGPU名が正しく表示されていなかったのを修正。
・--check-featuresにバージョン情報も出力するように。
・--check-environmentの出力先をstderrからstdoutに。
---

はやいもうできたのか（感謝）

>>327のHEVCロスレスの件についてはどうなったのか不明。
0342名無しさん＠編集中 (ﾜｯﾁｮｲ d7ec-MyS3)
垢版 |
2018/11/04(日) 15:03:34.52ID:xAruxQ/q0
>>341
スレのログを読めばTuringでHEVCのBフレームに対応したのがわかるので、
画質を重視するならTuringへの買い替えを検討すればいいと思う。
もしかすると今後のSDKやドライバーの更新でPascal等にも
HEVCのBフレーム利用が開放される可能性もあるけど、まだ不明だし。

Turingは今のところNVENCコアが１つしか載ってないらしいという情報もあるので、
並列エンコを効率よく行いたいという要望があるなら
NVENCコアが複数載っているGTX1080なんかも候補にあがるだろうけど。
　　https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況