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

1 名前：名無しさん＠編集中 [2018/08/08(水) 04:44:09.82 ID:NnYmcXUx0.net] ソフトウェアエンコーダーに画質は劣るものの、エンコード完了までの処理速度が爆速なハードウェアエンコーダーを語りましょう ●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 257 名前：名無しさん＠編集中 mailto:sage [2018/10/25(木) 11:57:30.78 ID:STwk5yxX0.net] >>238 0 258 名前：名無しさん＠編集中 mailto:sage [2018/10/25(木) 12:18:47.45 ID:Qmy18hJN0.net] リアルタイムエンコが目的だからBフレ対応はしないでしょ 259 名前：名無しさん＠編集中 mailto:sage [2018/10/25(木) 12:36:20.43 ID:STwk5yxX0.net] そもそも、H265の圧縮率向上の根幹はI/Pフレの圧縮率向上が大きいからな だからNVEncのマクロブロック配置ロジックの強化されてもH264に効果が殆ど無くてH265の方に効果が出てる 元々がGPUのクラウド化で画面転送するためのエンジンを転用・下位モデルにも解放してるものだし わざわざ面倒な方の性能向上するぐらい低レイテンシ保持が大事という 260 名前：名無しさん＠編集中 mailto:sage [2018/10/25(木) 13:41:09.39 ID:bUPCRSoJd.net] 265のエンコご優れてるのは分かったのですが 動画再生時デコードにパワー要りますよね？ 古いpc環境とか人にも見せたいとか、モバイルでも見たいなら 264の方がまだ使い勝手が良いですか？ 261 名前：名無しさん＠編集中 mailto:sage [2018/10/25(木) 14:35:50.05 ID:tONme0Ee0.net] 画質音質にこだわるのもいいけど扱いやすさがないと消滅するよ 音質が悪いと叩かれ続けてもmp3が生き残る理由 262 名前：名無しさん＠編集中 mailto:sage [2018/10/25(木) 17:26:52.29 ID:rQ/d4Tyo0.net] >>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を使った方がいいと思うよ。 263 名前：名無しさん＠編集中 mailto:sage [2018/10/25(木) 17:44:02.97 ID:STwk5yxX0.net] 根掘り葉掘り他人様頼みで身銭切らずに聞いている癖に、証拠まで求めるぐらいなら手前で買えよ 稼働させてるエンコ鯖止めてまでする気は無い 264 名前：名無しさん＠編集中 mailto:sage [2018/10/25(木) 19:02:32.56 ID:7N4Tp5iWF.net] 元気だねぇー 何か良いことあった？ 265 名前：名無しさん＠編集中 mailto:sage [2018/10/25(木) 20:03:21.41 ID:2ed29L1A0.net] 争いは、同じレベルの者同士でしか発生しない!!のAA思い出したｗ 266 名前：名無しさん＠編集中 mailto:sage [2018/10/26(金) 11:08:46.55 ID:4O36bTgr0.net] >>238 RTX 2070 https://pastebin.com/raw/zzMUkFJP GTX 1060 6GB（参考） https://pastebin.com/raw/qruXMnmC 267 名前：名無しさん＠編集中 mailto:sage [2018/10/26(金) 11:12:30.11 ID:4O36bTgr0.net] > Codec: H.265/HEVC > Max Bframes 5 Bフレーム来たね > Codec: H.264/AVC > ... > Field Encoding no 代わりにH264のフィールドエンコーディングが無くなってる？ 268 名前：名無しさん＠編集中 mailto:sage [2018/10/26(金) 15:40:22.36 ID:9aUksCRaM.net] とうとうBフレーム対応か 隔世の感 269 名前：がありますなぁ [] [ここ壊れてます] 270 名前：名無しさん＠編集中 mailto:sage [2018/10/26(金) 20:48:35.08 ID:4O36bTgr0.net] 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 271 名前：名無しさん＠編集中 mailto:sage [2018/10/26(金) 21:53:48.42 ID:5tUyQmet0.net] 同ビットレートでの画質差を・・・ 272 名前：名無しさん＠編集中 mailto:sage [2018/10/26(金) 21:56:21.34 ID:WduSYcIU0.net] ｂフレーム対応でようやくハードウェアエンコードが市民権得られる時代になったかな？ 273 名前：名無しさん＠編集中 mailto:sage [2018/10/26(金) 22:46:46.03 ID:4O36bTgr0.net] 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フレームで半分、その他で半分くらい 274 名前：名無しさん＠編集中 mailto:sage [2018/10/26(金) 22:52:01.61 ID:4O36bTgr0.net] >>250 Bフレーム使ってないの？エンコ鯖一旦止めてでもBフレーム使うように設定する価値はあると思うよ 275 名前：名無しさん＠編集中 mailto:sage [2018/10/26(金) 23:37:54.30 ID:4O36bTgr0.net] Bフレームはあまり多くしてもダメで2〜5を試したけど3が最適値っぽいな 276 名前：名無しさん＠編集中 mailto:sage [2018/10/26(金) 23:41:30.18 ID:p3F/gXTv0.net] そういやAMDって死んだんだっけ？ 277 名前：238 mailto:sage [2018/10/26(金) 23:49:32.81 ID:N4zrz6VR0.net] >>253-261 色々な情報を出していただき、ありがとうございます。 去年QSVスレで調べた時点でもNVEncのHEVCは結構良好な結果を出してましたし、 それを着実に改善していってるというのもすごいな・・・。 　mevius.5ch.net/test/read.cgi/avi/1486130737/335 278 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 00:03:15.28 ID:ys8cVnL20.net] 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．「今の時点では数か月以内としか言えないっす。」 279 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 00:04:10.25 ID:FTUp+p+x0.net] いよいよNVEncを本格的に使う時代がやってきたようだね 280 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 00:22:00.32 ID:eOCStpwQ0.net] 2070以上じゃないと使えないとかじゃなきゃ良いが 281 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 00:37:08.38 ID:AkK5mm1N0.net] 2030とかに搭載してたら買う 282 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 01:01:30.37 ID:yLZZ6lTR0.net] >>264 少なくともウチの環境の1060 vs 2070だと、2070遅くないよ h264は2070の方が速くて（vbrhqが330fps vs 400fpsくらい）、hevcは同じくらい（vbrhqが290fpsくらい）だった 283 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 01:03:10.45 ID:yLZZ6lTR0.net] 画像サイズはフルHDで 284 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 01:09:28.23 ID:EhqLT3Ob0.net] >>267 10xxも併売するらしいから無理じゃない？ NVIDIAはNVENCを付加価値にしてるから 実売1万円以下のカードに乗ることは当分無さそう。 AMDに頑張ってほしい、 5千円で買ったx30,x40でNVENCが動くって今では無理だもんな 285 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 01:52:47.92 ID:Q9KzXn1A0.net] Bフレ数は参照距離とかの兼ね合いで品質評価や圧縮効率にも影響するからエンコーダと設定値による 基本的に参照距離より大きくなると圧縮効率が下がるからBフレ増やす意義が下がる 286 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 03:14:07.17 ID:eOCStpwQ0.net] 参照距離は3以上は無意味だとH.264でも答えが出てたはず 287 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 03:37:58.82 ID:yLZZ6lTR0.net] >>272 2070でHEVC main10で試したけど無意味だったわ 参照距離Bフレともに3が最適値かな。H264と同じっぽいね 288 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 14:22:44.59 ID:5CDNEkUDM.net] で、実際にエンコードした動画の品質はどんな感じなの？ x264やx265といい勝負しているの？ 289 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 14:34:17.18 ID:loEY7bAF0.net] 「いい感じだよ」とか「全然ダメだよ」とかレスが返ってきたときに、 その情報の真偽をお前はどうやって区別つけるの？ 290 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 15:31:39.62 ID:5CDNEkUDM.net] そういうのいらないから 291 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 16:49:16.70 ID:d7Sa2MDK0.net] まぁレス番もつけずに比較出せって言われてもな 善意でエスパー反応しても後出しで証拠だせとか 追加であれやれこれやれっていうのが沸くだけだし 自分でやってみればっていわれるのが落ちだぞ 292 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 19:42:58.27 ID:3i4fAC3IM.net] 自分の感じたままに書くだけのことがそんなに怖いのか？ 失敗することに恐怖を感じるタイプか？ 293 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 20:10:01.30 ID:loEY7bAF0.net] 俺が怖いものは、「醜態を晒している自分に気づけていない人間」かな 294 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 20:13:24.22 ID:3i4fAC3IM.net] 気取ってんじゃねぇよ ただの腰抜けだろ 295 名前：名無しさん＠編集中 mailto:sage [2018/10/27(土) 23:44:27.63 ID:yLZZ6lTR0.net] x264,x265,QSVと比較 https://i.imgur.com/QJFOuDV.png https://i.imgur.com/AP16tNS.png 映像の見た目は、HEVCとH264だとHEVCの方がノイズの隠し方はうまいから、 同じSSIMでもHEVCの方がきれいに見えるかな あとはだいたい数値通り 296 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 00:40:17.81 ID:gjMu3C/j0.net] なんでQSVはHEVCよりH264の方が高性能なん？ 297 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 01:14:21.02 ID:P2HtKYlC0.net] >>281 これサイズ比較も欲しい 298 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 01:24:13.21 ID:42x5MzyR0.net] >>283 ビットレートが載ってるんだから必要ないと思うけど、何故に？ 実写の方はrigaya氏のQSVBenchmarkに含まれてる2分53秒の動画で、 アニメOPの方は1分30秒くらいだろうから、ファイルサイズはそこから計算できると思うが。 299 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 01:35:24.69 ID:GZzWkstI0.net] >>282 なんでって現状そういう実装になってるから、としか まだ、QSVのHEVCエンコードは出たばかりだし、今後改善される可能性はあると思う 一応、このグラフで使ってるのはKaby Lakeで、QSVは最新世代のはず Pascal世代のNVEncもHEVCの性能は相対的に低かったから、実写ではH264の方がSSIM高かったよ （グラフには載せてないけど2070のH264は実写でもHEVCより少し低い） 300 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 02:46:35.85 ID:mrO/Sdoo0.net] >>281 乙 これはある意味、衝撃的な結果とも言えるね アニメのほうから見ていくと、「x265 midium main10」と「2070 B=3 HEVC main10」が ほぼ同じSSIMと言っていいレベルで第1位と第2位！ 画質のみで判断する場合、「QSV」と「x264」は、アニメに関してはもはや不要と言いたいレベル！ 301 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 02:46:51.15 ID:mrO/Sdoo0.net] 実写に関しては「x265」と「x264」がほぼ同点のトップ3タイと言っていい感じかな 次点で「2070 B=3 HEVC main10」と「QSV H264」が同じようなSSIMだが、全体としては 「2070 B=3 HEVC main10」のほうが若干優勢 おそ� 302 名前：轤ｭよりビットレートを高く設定できる場合になればなるほど「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割増し程度にする設定にしておけば、もはや十分な結果が得られると言えるのではないだろうか [] [ここ壊れてます] 303 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 11:08:35.72 ID:ftI7zJ8S0.net] >>281 ありがたい 実写は何使ってもSSIM厳しいなー 304 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 12:17:03.84 ID:QuPM3EHW0.net] そもそも画質がSSIMで語れるのかと 305 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 13:31:50.58 ID:AIjwuTyg0.net] 数値化された指標ってそれしかないんじゃないのかな なら仕方ない話で 俺はそれはそれ話半分で聞いてる 306 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 13:53:36.53 ID:AIjwuTyg0.net] 痛みの単位HANAGEを思い出した 307 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 15:45:20.66 ID:3GVWrMAV0.net] >>289 SSIMのみで画質のすべてを語れるわけではないけれど、重要な指標になりうることは確か >>281のテストの場合、画質として差が出ると判断できるだけの数値の差が出ているところから見て Turing世代のHEVCエンコーダーの実用性が高いと判断することはできる あまり話題には出ないがNVEncの場合、H.264、H.265ともにLOSSLESSエンコードもできるようになっているので、 今後ノートPC用のTuring世代GPUが出た場合、ノートPCにキャプチャー機器を接続してLOSSLESSでキャプチャーし 編集などしたのちH.265に再エンコードして保存などということも楽々とできるようになるのだろう CPUやメモリーに必要以上に金つぎ込むよりGPUに金つぎ込んだほうが得られるメリットが確実に高くなる 308 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 18:34:37.91 ID:q1RCfS2y0.net] VMAFってどうなんだろ 309 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 19:43:45.84 ID:dqPT1FY80.net] むしろ気になったのは改善度合いのわりにNvidiaのアピールとか情報開示が控えめな感じがするところ HEVCのBフレーム対応はQSVが先にやっているとはいえ、充分Turingの売りになると思うんだけどな 310 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 20:32:21.34 ID:3GVWrMAV0.net] >>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)」に該当） 311 名前：名無しさん＠編集中 mailto:sage [2018/10/28(日) 20:32:38.99 ID:3GVWrMAV0.net] これはNVIDIAに限らず、Intelも同様の傾向があるけれど （Intelの場合、新しい世代であっても再生支援を使って動画再生をするとカクカクした動きになることすら あるからなおのこと始末が悪いが…） この手の業界の連中は、と 312 名前：もすれば「コミュ障か！」と突っ込みたくなる傾向が強いのが最大の弱点 [] [ここ壊れてます] 313 名前：名無しさん＠編集中 mailto:sage [2018/10/29(月) 04:39:38.65 ID:AzT2hbUL0.net] > Codec: H.264/AVC > ... > Field Encoding no これ何かと思ったら、H264のインタレサポートが無くなってたわ NVEncCで--tffオプション指定するとエラーになった > interlaced output is not supported for current setting. インタレ保持エンコができなくなるとは・・・これも時代の流れか 314 名前：名無しさん＠編集中 mailto:sage [2018/10/29(月) 08:38:43.00 ID:01sVuNYh0.net] 要するに、60pは対応するが60iは捨てられたのか まあ面発光する表示デバイスしか無くなってるからな 有機ELはあるが 60iから60pへのip変換は出来るのかな？ 315 名前：名無しさん＠編集中 mailto:sage [2018/10/29(月) 08:52:53.42 ID:sYHP33Ej0.net] >>294 nvidiaが詳細明示せずSDKやAPIで叩いて実際の挙動見ろ的なのは何時もの事なのでは？ 316 名前：名無しさん＠編集中 mailto:sage [2018/10/29(月) 09:57:06.91 ID:dU/S2c/9a.net] きょーび動画がらみの機能は訴求力ない ゲームのフレームレート至上主義や 出始めの頃はDCTだ動き補償だなんだと 並び立てて煙幕張ってたが Rage128とかそんな頃ｗ 317 名前：名無しさん＠編集中 mailto:sage [2018/10/29(月) 11:20:58.69 ID:5qgUaohH0.net] ゲームの中継ととかで需要はうなぎのぼりだよ 318 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 01:57:43.60 ID:6swiaWs40.net] >>297 インターレースは非対応ですか 時代の流れと言えばそれまでですが、いささか早すぎるような気もするけれど 放送はこれから先も2K以下についてはインターレースのまま継続するのだし ただ、インターレースが動画圧縮を行う上で非効率なことは間違いないし、 再生機器でのリアルタイムインターレース解除より、QTGMCなどであらかじめ じっくり解除しておいたほうがきれいなことは間違いないわけで ※4Kテレビなどで2K放送などをアップコンバートして表示している映像を見ると、 インターレース解除がうまくできていないことによるジャギジャギ感が目につき 気になって仕方がない 319 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 01:57:58.08 ID:6swiaWs40.net] 問題は、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台格安で手に 入りそうなので、手に入れば実験してみようかと思っているのだけれど… 320 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 05:04:17.92 ID:Cr8xUI/50.net] キャプチャする対象をインタレと決めつけてるけど ソースは何を想定してるのよ？ 321 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 11:18:17.80 ID:MqAHCJNS0.net] amatsukazeはts信号処理と言ってるから放送波なんじゃね 322 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 11:55:09.90 ID:praWeO5TM.net] 撮影ts化する人はいないだろうから、放送波だろうな 323 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 12:02:45.30 ID:Cr8xUI/50.net] いやね、tsならファイル扱えば良い訳で レス元のみたいなキャプチャー機器使う環境をあげてる人へのレスで、何処からインタレとかの発想出てきたのかと 324 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 12:20:10.29 ID:ZgNtru3g0.net] DVDやBDのインタレソースにAmatsukazeのKTGMC使ってみてえな 325 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 14:37:23.21 ID:VTxPizmd0.net] >>303 QTGMCなんて只のavisynthの関数だろ？ 自分でスクリプト書いて使えばいいだけ。 それが出来ないレベルなのか。 326 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 14:43:27.09 ID:wilPKf0o0.net] そういうの余所でやって 327 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 17:23:10.50 ID:PLMRbtTq0.net] >>307 ロケフリ用途とか? 328 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 19:38:56.39 ID:Cr8xUI/50.net] >>311 だからインタレのキャプチャなんぞDVDプレイヤーやD端子以前の旧世代の機器の出力とか、旧世代のインタレ表示機器向けの信号取り込もうとしない限り今じゃ無いでしょ 後者なら出力側をプログレにすりゃ良いのだから、わざわざインタレ出力にしてまで取り込む意味が無いし インタレとも書いてない書き込みに付けるレスとしては謎すぎる 329 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 20:07:46.12 ID:30eOo37X0.net] レコとかテレビ任せのインタレ解除よりQTGMCのほうが綺麗でしょ 330 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 20:12:09.90 ID:30eOo37X0.net] QTGMC単体だと副作用多すぎなのでQTGMC+KFMか 331 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 20:30:20.23 ID:jJrgI2Lj0.net] そういうの余所でやって 332 名前：名無しさん＠編集中 mailto:sage [2018/10/30(火) 23:17:53.06 ID:MqAHCJNS0.net] ほっとけばすぐ収まるんだからスルーしときなはれ 333 名前：名無しさん＠編集中 mailto:sage [2018/10/31(水) 02:59:37.42 ID:W4uaGaXp0.net] Apple T2 チップってのはどうなんだろ 334 名前：名無しさん＠編集中 mailto:sage [2018/10/31(水) 03:03:56.44 ID:HL+tE8NE0.net] なんだか勘違いしている人がいるようだな ts化するというのはAmatsukazeがtsしか受け付けないからtsで保存と言っているわけなのだが… 個人的には大事な録画をサポートはおろか何の保証もないBonDriverを使ったts録画に任せる気には ならないので、録画はレコーダーでしているけれど （放送局側の都合で突然仕様が変更されて録画できなくなってもどうすることもできないし） キャプチャーは主にアナログ時代に録画したものやD-VHSで録画したものを念頭に置いている 特にD-VHSからのキャプチャーはドロップアウトとの戦いもあるから念入りにしなければならないので まぁ一人アレルギー反応示している人がいるからこの件はクローズにしておきましょ 335 名前：名無しさん＠編集中 mailto:sage [2018/10/31(水) 12:14:43.06 ID:vRp2peue0.net] >>318 >>（放送局側の都合で突然仕様が変更されて録画できなくなってもどうすることもできないし） ISDB規格って知ってる？ もしPT3とかで録画出来なくなったら他の民生品レコーダーも全滅だよ。 336 名前：名無しさん＠編集中 mailto:sage [2018/10/31(水) 12:46:16.61 ID:Yt9WJetm0.net] スレ違い長文はスルーでok 337 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 01:55:10.07 ID:uB0majyg0.net] 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/ (続く) 338 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 01:57:27.24 ID:uB0majyg0.net] (続き) そこで、ffmpegではどうなっているのか念のため確認してみたかったのですが、 うちは残念ながらIntelノートなので、代わりに 　H264:yuv420p/yuv444p, HEVC:yuv420p/yuv444p/yuv420p10le/yuv444p10le の6パターンについて ffmpeg -i yuv4**p*.y4m -pix_f 339 名前：mt 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等にアップロードしてもらえると 　エラーが発生した場合の原因などもわかるので助かります) よろしくお願いいたします。 [] [ここ壊れてます] 340 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 02:29:58.68 ID:J40rNpwz0.net] >>322 https://www.axfc.net/u/3944343 341 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 03:13:14.80 ID:J40rNpwz0.net] ffmpegは全部対応してるけど、rigaya氏のNVEncCはh264のYUV444にしか対応してないようだね HEVCやYUV420を使いたい場合はffmpeg使うしかないっぽい h264のYUV444に比べてHEVCのYUV420はサイズが半分近くまで減るし 342 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 03:13:52.29 ID:uB0majyg0.net] >>323 ありがとうございます。環境にあわせてテストしていただいたようで申し訳ない。 ログを確認させていただきましたが、Pascal(GTX 1060)、Turing(RTX 2070)ともに、 420/444、8/10bitの全パターンでちゃんと一致したフォーマットで可逆になってますね。 YUV4:2:0でもロスレスエンコードできると考えてよさそうです。 とりあえずrigayaさんのブログに情報としてお知らせしておこうと思います。 ご協力いただき、ありがとうございました。 343 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 03:37:43.12 ID:uB0majyg0.net] >>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 となっています。 344 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 03:55:29.32 ID:J40rNpwz0.net] >>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にならない これ以外のオプション指定の仕方が分からない 345 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 04:06:01.76 ID:uB0majyg0.net] >>327 そうなると自分もちょっとわかりませんね・・・。 AviUtlから拡張NVEnc出力を使ってHEVCを選んで、readmeにあるように 　「CQPでIフレーム、Bフレーム、PフレームのQP値を0にする」 で出力するのを試してみるという手もありますが、同じ結果になる可能性が高そうな・・・。 346 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 07:35:14.62 ID:oyWwovRq0.net] 一応ロスレス出力のファイルサイズまとめ。(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 347 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 17:06:40.04 ID:3hZOcD7m0.net] >>303などでNVEncのLOSSLESSエンコードについて書いていた者だけど、俺より先にいろいろテストしてくれている人がいるようなので とても助かります 今、気になっていることが二つあります 1．「AVerMedia Live Gamer Ultra」をレビュー。 高画質＆高速プレイを妥協せず、手軽に快適な録画・配信環境を構築できるUSB外付け機器型ビデオキャプチャ blog.livedoor.jp/wisteriear/archives/1071577199.html#more という記事の中で紹介されている 「上のようにGPUハードウェアエンコードとCPUによるソフトウェアエンコードの間に基本的には大きな差はありませんが、 NVENCについては特定の条件下でノイズが発生する可能性があるようです。」 348 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 17:07:10.59 ID:3hZOcD7m0.net] ・CPUエンコードの場合（問題なし） livedoor.blogimg.jp/wisteriear/imgs/2/e/2e3f1b76.jpg ・NVEncによるエンコードの場合（破綻している） livedoor.blogimg.jp/wisteriear/imgs/e/b/eb4742a8.jpg ・動画での確認 https://www.youtube.com/watch?v=Bzv6z2NKw5A このノイズがLOSSLESSの場合でも発生するのかどうか？ 2．上記の問題はRTX20*0（Turing）世代のGPUでも相変わらず発生するのか？ という点が気になっています そもそもこの問題はハードウェア的にどうしようもない問題なのか、それともドライバーソフトなど含めたソフトウェアレベルで 改善出来うる問題なのか 果たして真相やいかに？ 349 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 17:27:09.65 ID:xQq3bNCe0.net] AVerMediaのAVT-C878を使ってる感じだとPS4-単体録画モードでもたまにコマ落ちしてるよ あとそのサイトの話だと途中59.94FPS録画もあったり条件がそろってないから注意ね 350 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 18:48:20.13 ID:oyWwovRq0.net] >>330-331 ノイズや破綻の発生と言っても、 　・SW側の実装の問題（NVEncをどのような設定で呼び出しているのか等） 　・HWや環境側の問題（電源不安定や突発的な負荷増加等） 　・NVEncやドライバ側の問題 など、要因が多数あるわけで、「発生しない」なんて言い切ることは誰にもできないと思うよ。 　 　 あと、ぶっちゃけた話、ロスレスキャプチャにこだわらない方がいいと思う。 >>323のテスト結果を見ると、 　　RTX2070/HEVC/yuv420pロスレス/640x360/29.970fps → ビットレート 39.4Mbps になっている。1080p30に換算すると単純計算で9倍で354.6Mbpsになる。 「データ量が膨大になってもいいからロスレス(可逆)キャプチャしたい」という強いこだわりがあるなら別に止めないけど、 得られる画質は数分の１のビットレートで通常の非可逆キャプチャした場合と大差ないだろうし、 ロスレスだからといって編集時のデコード処理等が軽くなるわけでもないし、 最終的に保存エンコしたりYoutube等にアップロードすることを考えると、どうせその画質も保持できないわけだし。 351 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 20:29:04.08 ID:oyWwovRq0.net] >>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倍) という感じだった。 352 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 20:32:09.61 ID:J40rNpwz0.net] >>330-331 キャプチャボード付属のソフトでエンコードしてるから、 どっちかというとドライバやHWよりそのソフト側に問題がある可能性が高そう NVEncや 353 名前：ffmpegでも同じ現象が発生するなら別だけど、 そういう破綻は俺は見たことも聞いたこともないなぁ 4K60fpsYUV444でロスレスなんてやったら700MB/sくらいになるから、 SATAじゃ帯域足りなくて、M2でやっとって感じ。相当やばそうｗ [] [ここ壊れてます] 354 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 22:29:43.39 ID:oycFKwRy0.net] >>331 そもそもスレ違い AVerMediaのキャプチャデバイス使った問題なら ちゃんとスレがあるだろ https://mevius.5ch.net/test/read.cgi/avi/1486558448/ 355 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 22:36:55.92 ID:oyWwovRq0.net] --- 2018.11.03 NVEnc 4.22 [共通] ・yuv420のlossless出力に対応。 [NVEncC] ・Caption.dllによる字幕抽出処理を実装。(--caption2ass) ・--check-featuresでGPU名が正しく表示されていなかったのを修正。 ・--check-featuresにバージョン情報も出力するように。 ・--check-environmentの出力先をstderrからstdoutに。 --- はやいもうできたのか（感謝） >>327のHEVCロスレスの件についてはどうなったのか不明。 356 名前：名無しさん＠編集中 mailto:sage [2018/11/03(土) 23:45:03.74 ID:J40rNpwz0.net] >>337 HEVCは10bitも含めて全部できるようになってたわ！ 357 名前：名無しさん＠編集中 mailto:sage [2018/11/04(日) 00:00:00.96 ID:eJsOmTbV0000000.net] お、よかった

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef