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
113 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 11:21:56.08 ID:m7n2BMFu0.net] 要するに 45c3-iM7h : 精度を落としたものをwaifu2xと呼ぶことは絶対に認めない 29c3-PcWx : 今の waifu2x は高品質だけど遅すぎるから、半精度化によってある程度品質が落ちる代わりに Tensorコアによる高速化メリットが得られる waifu2x' みたいなもんができるといいな。 (半精度化による品質低下やTensorコアによる高速化がどれくらいかにもよるけど) ってことじゃないの。 技術的なこだわりが強いのか何なのか知らんが、受け取り方がねじ曲がりすぎじゃね? カリカリして人格攻撃するほどの話じゃないだろ。
114 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 14:06:55.17 ID:i4axf3T+0.net] >>107 > 32bit精度で行列演算するコードを16bit精度のTensorコアで高速化とか、半精度を容認する前置きも無く書き込んでおいて >>92 > Tensorコア使ったポストエフェクトとか超解像 これはディープラーニングを使ったもので、「Tensorコアでディープラーニングを計算する」 って時点で、fp16に精度を落として行列積を計算するってことだよ つまり、ディープラーニング(正確には行列積部分)をfp16で計算するっていうのは君が最初に言ってること 同じようにディープラーニングで超解像するwaifu2xもTensorコアで高速化できるよね って話をしてるんだから、fp16で計算するっていうのは何の脈絡もなく出てきたわけではない > waifu2xと同様の処理が出来ても同じ精度維持出来ないから同じ処理は出来ないと言っているのに > 機械学習でTensorコアの効果を否定しているかの様に勝手に話置き換え始めたり ディープラーニングを使った代表例みたいなwaifu2xにTensorコアを使うことを否定するのは 「機械学習でTensorコアの効果を否定」するのと同義だと思うのだが
115 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 14:26:50.50 ID:ztucUYzzM.net] 0か1しか価値判断基準のない人は疲れるな
116 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 15:11:35.59 ID:i4axf3T+0.net] >>108
117 名前: NVEncの実際の実装が後者の可能性もあると思うけど、なんで前者だって分かるの? [] [ここ壊れてます]
118 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 15:22:59.23 ID:m7n2BMFu0.net] >>110 のように「お前が最初に言った」みたいな書き方をすると、また不毛な返答が返ってくる気がするので "こっちは元々「fp16化+Tensorコアで高速化したリアルタイムwaifu2x(もどき)」を想定して書き込んでて、 >>100 でお前が勘違いとか言ってきたからそれに答えて詳細を説明しただけなのに、 精度落としたらwaifu2xじゃないとか、後出しとか狡いとか利己的とか言われて迷惑してる。” って書いてやった方がよい気がする。
119 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 17:18:48.39 ID:BIBv3N7z0.net] >>113 指摘の弁解も理由も全部後出し 取り繕いばっかりじゃねーかよ そんで、waifu2xの演算に精度不足というなのがTensorコアが機械学習用途に不適というこじつけなるか理由聞かせてくれよ
120 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 17:29:49.46 ID:BIBv3N7z0.net] >>112 「可能性」とか言い出せばどっち前者だろうが後者だろうがイチャモン付けられるってか? 品質基準のVBRロジックなんだから、ビットレート指定時に品質基準での調整ロジックが動いて無く、ビットレート指定を無くした時にだけ稼働すなら、ビットレート指定時は品質基準のVBRじゃなくなるわな nvidiaが品質基準VBRとして実装しているものすら疑いだしたら、何を基準で正否とするよの? 後者と判断するなら、その根拠を提示してくれよ
121 名前:名無しさん@編集中 [2018/08/26(日) 18:05:10.01 ID:k5cd80q8M.net] ffmpegでのエンコードパラメータを極めるスレはどこ?
122 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 18:28:06.93 ID:m7n2BMFu0.net] >>114 > waifu2xの演算に精度不足というなのがTensorコアが機械学習用途に不適というこじつけなるか理由聞かせてくれよ そもそもその前の時点でお前が話を読み違えてるんだよ。>>107 でお前が > 機械学習でTensorコアの効果を否定しているかの様に勝手に話置き換え始めたり と書いてるが、106はTensorコアの効果の否定なんてしてないだろ。 下3行の解釈を、お前が間違えてるだけのように見えるが。 29c3-PcWx が言いたいのは、 ・Tensorコアがfp16なのは、NVIDIAがfp16でもディープラーニングでは十分実用的だと判断したからではないか ・ならばwaifu2xのfp32処理の部分を、Tensorコアのfp16処理に変えてみるのももしかしたらアリではないか? ってことでしょ。まあディープラーニングっつっても目的によって必要な精度は変わってくるんだろうから そんな単純な話が成り立つかどうかは知らんけどね。 とりあえず落ち着いて、やりとりを最初から見直してみたほうがいいんじゃねえの。
123 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 18:36:13.01 ID:m7n2BMFu0.net] まあwaifu2xについて、「処理をfp16にしたらまともな品質にならない」みたいな検証が既にされてるのであれば 淡々とその結果を示してあげればいいと思うけど、これ以上続けたいなら そろそろ画像拡大スレに移ったほうがいいんじゃないかとは思う。 【超解像】画像拡大ソフト総合スレ2【waifu2x】 https://egg.5ch.net/test/read.cgi/software/1462848853/
124 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 20:25:54.45 ID:i4axf3T+0.net] >>115 ビットレート指定時は品質基準VBRじゃないでしょ ビットレート指定のVBRなんだから ビットレートを指定しなかったときに品質基準VBRになる > nvidiaが品質基準VBRとして実装しているものすら疑いだしたら、何を基準で正否とするよの? 固定QPモードがあるんだから、ビットレート指定VBRは、 平均ビットレートが目標より大きくズレたら、適当にQP操作してるだけかもしれないじゃん そこから、ビットレートを目標にあわせる処理を抜いたら、固定QPになっちゃう NVEncCのデフォは固定QPだし > 後者と判断するなら、その根拠を提示してくれよ 後者か前者かなんて分からないよ 中の実装がどうなってるかなんて知らないから エンコード結果、どういう出力がされたかくらいでしか観測できない ビットレート指定VBR時はビットレート指定VBRのレートコントロールが働いて 品質基準VBR時は品質基準VBRのレートコントロールが働くって考えるのが 最もシンプルな理解だと思うから、そうじゃないときはちゃんと書いてくれないと分からないよ
125 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 20:51:24.96 ID:m7n2BMFu0.net] 細かいことはよくわかんねーけど、とりあえずNVIDIA Video Codec SDK
126 名前:8.2.15 の NVENC_VideoEncoder_API_ProgGuide.pdf の 「3.8.3 Rate control」の内容を貼っとくわ。 https://pastebin.com/LuGCNXbY [] [ここ壊れてます]
127 名前:名無しさん@編集中 mailto:sage [2018/08/26(日) 21:11:24.15 ID:i4axf3T+0.net] >>120 サンクス この資料だと、Target Quality(固定品質)がVBRの一部って書き方じゃないんだよね 対応してるレートコントロールは以下の4つです - CBR - VBR - 固定QP - 固定品質 って感じ あとVBRのレートコントロールについての記述は主に > The encoder tries to conform to average bitrate of averageBitRate over the long term これだけ
128 名前:名無しさん@編集中 mailto:sage [2018/08/27(月) 10:48:37.03 ID:KSUuDcZo0.net] 紙芝居のためにご苦労さま
129 名前:名無しさん@編集中 mailto:sage [2018/08/27(月) 11:34:45.47 ID:dyyUpjbe0.net] これが捨て台詞ってヤツか
130 名前:名無しさん@編集中 mailto:sage [2018/08/30(木) 18:15:44.74 ID:h+nfkzzo0.net] 76 名無しさん@編集中 (ワッチョイWW ea84-/kQw) sage 2018/08/25(土) 08:51:46.65 ID:A+XxIkPU0 どーせアニメだろw 122 名無しさん@編集中 (ワッチョイWW ea84-/kQw) sage 2018/08/27(月) 10:48:37.03 ID:KSUuDcZo0 紙芝居のためにご苦労さま この間46レスと50時間w
131 名前:名無しさん@編集中 mailto:sage [2018/09/02(日) 19:42:33.51 ID:DuBTtQDB0.net] r ‐、 | ○ | r‐‐、 良い子の諸君! _,;ト - イ、 ∧l☆│∧ (⌒` ⌒ヽ /,、,,ト.-イ/,、 l. 証拠を要求するネトヲタがいるが |ヽ ~~⌒γ⌒) r'⌒ `i´ `⌒) 君がいくら証拠を開示しても │ ヽー―'^ー-' ( ⌒γ⌒~~ /| そのネトヲタは絶対信じないぞ! │ 〉 |│ |`ー^ー― r' | おまけにそいつは自分側の証拠を出したことがない。 │ /───| | |/ | l ト、 | | irー-、 ー ,} | / i 自分の信じたいものしか信じなくなったらおしまいだな! | / `X´ ヽ / 入 |
132 名前:名無しさん@編集中 mailto:sage [2018/09/09(日) 04:59:21.22 ID:apyEih63r.net] なにが正しいかなんてわからんよ エンコードしないのが一番いい気がするわ
133 名前:名無しさん@編集中 mailto:sage [2018/09/09(日) 10:55:29.43 ID:vbK7CwBM00909.net] マヌケの戯言
134 名前:名無しさん@編集中 mailto:sage [2018/09/09(日) 10:57:32.83 ID:SWOzIg6M00909.net] たしかに 劣化させて喜ぶアホ
135 名前:名無しさん@編集中 mailto:sage [2018/09/09(日) 13:57:41.51 ID:614xNICFM0909.net] 劣化を感じるようなエンコードしかできないのは、ユーザーの能力不足による無理な設定によるところが大きい いくら優秀なエンコーダーを用いたところで、フルHD動画を最大1Mbpsなんかに設定したら、どうやっても劣化は目につく それに放送番組を再エンコードするのにノイズ除去すらもせずにエンコード直行など、愚かにもほどがある
136 名前:名無しさん@編集中 mailto:sage [2018/09/09(日) 14:14:25.74 ID:eDINVlxYr0909.net] マヌケの戯言
137 名前:名無しさん@編集中 mailto:sage [2018/09/11(火) 09:19:07.11 ID:nd7uezLA0.net] もうHDD買い足してソースをそのまま保存しとけよ エンコードなんかしてたら人生損するよ
138 名前:名無しさん@編集中 mailto:sage [2018/09/11(火) 10:44:00.24 ID:CJzWO1xPd.net] ソースで多少前後するけど 静止画比較しないと気にならないレベルなら 固定量子化ベースの量子化係数設定値なら H264 QSV 〜22 H264 NVEnc〜20 HEVC QSV 〜24 HEVC EVEnc Pascal 〜23 Maxwwll 〜22 あたりが画質に目立った劣化が知覚できるかの境界線あたりかと(あとは好みで1減らすなり、IPBで階段状に設定するなり コーデック問わず画質容量比と処理時間でなら、PascalのNVEncが速度とのバランス的に優秀 H264→HEVCでの速度低下がQSVが1/3〜1/4にもなるけど、NVEncだとMaxwellで1/2、Pascalで2/3程度の速度にしか落ちないのがデカい HWエンコーダで時間問わずならQSVのHEVCなんだろうけど HEVCだと速度低下激しすぎて(GT2で40fps前後)CPUの方がOC4コア以上ならx264のfasterとかで処理しちまった方が良くなってくる ただNVEncはGeforce/Titanだと同時処理が2件までなんで、TSの録画後に自動処理で録画タスク毎に処理するのには向かない(やりようはいくらでもあるけど)のが難点
139 名前:名無しさん@編集中 mailto:sage [2018/09/11(火) 10:55:40.29 ID:cvr00PSpa.net] 録画後処理じゃなくて 定期的にファイルリストに対して 1本ずつ処理したらええだないかね
140 名前:名無しさん@編集中 mailto:sage [2018/09/11(火) 16:32:00.96 ID:gbdYj/Dq0.net] >>115 組める人には問題ないけどね(自分もそうやっている フォルダ監視して順次エンコさせる場合には、リスト取得や録画中のファイルか録画完了したファイルかの判断とか 録画管理ソフトで録画終了時に実行する様なバッチみたいに、コマンドラインのエンコード命令にに毛の生えたぐらいのと違って、自分で組まなきゃならん部分多いから多少はハードル高くはなる 実際に他のスレで同時エンコ数の制限有るから使いづらいみたいな事書き込んでた奴も見かけてるし
141 名前:名無しさん@編集中 mailto:sage [2018/09/11(火) 16:34:04.00 ID:gbdYj/Dq0.net] ありゃ、リンクミス >>133 >>115
142 名前:名無しさん@編集中 mailto:sage [2018/09/11(火) 22:40:56.55 ID:UKWbxX7R0.net] Amatsukazeなら何の問題もない
143 名前:名無しさん@編集中 mailto:sage [2018/09/14(金) 23:28:10.31 ID:mw+2E23g0.net] https://www.4gamer.net/games/421/G042134/20180913178/SS/047.jpg なかなかえーんでない? 元記事: 西川善司の3DGE:GeForce RTX 20完全理解。レイトレ以外の部分も強化が入ったTuringアーキテクチャにとことん迫る https://www.4gamer.net/games/421/G042134/20180913178/
144 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 00:24:18.61 ID:6Guydu2D0.net] >>137 「また,エンコーダの圧縮アルゴリズムにも改良が入っており,Pascal世代と比較して,同じ画質ならH.264で15%,H.265なら25%も低ビットレート化できるようになった。 逆に言えば,同じビットレートならPascal世代のGPUを使うよりも高い画質を得られるということだ。」 おぉー! これは期待しちゃうなぁ
145 名前:名無しさん@編集中 [2018/09/15(土) 00:27:43.52 ID:fy+82PFP0.net] AMDって今何してるの? 動画ならAMDなんて時代もあったのに…
146 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 00:33:21.67 ID:6Guydu2D0.net] 画像の中の表によると 1080・60pの動画をビットレート6Mbps設定でエンコードした場合に x264のプリセットFastと、Turing世代のGPUでH.264(かと思われ)を比較すると、 PSNRの値が少しTuring世代のGPUのほうが上回っている となると、x264のプリセットslowと比べるとしてもビットレートを2割増程度で充分対抗できるかも? なんかすごいことになってきたな
147 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 00:38:14.81 ID:cjvlLd9kr.net] >>139 CPU作ってるよ ATiって言わない時点で知ってるんだろマヌケ
148 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 00:46:15.23 ID:vV+sK+U50.net] Poralisでリアルタイム2パスエンコードエンジン採用してディティールが残るとか言ってたのは結局どうだったの? https://www.4gamer.net/games/329/G032949/20160629072/
149 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 00:46:40.52 ID:rREhMZBO0.net] 文脈読むならNVIDIAやインテルにGPUエンコでぼろ負けだけどGPUでエンコやる気ないの?
150 名前:だろ どう見てもなさそうだねw 費用対効果で割りに合わないと思ってそう [] [ここ壊れてます]
151 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 01:04:36.37 ID:rLzU4Nl20.net] >>140 6Mbpsか・・ 2Mbpsとかでも馬脚を出さなかったら凄いけど どうなんだろ
152 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 01:08:09.38 ID:6Guydu2D0.net] >>144 2MbpsはHEVCでもキツいだろ 解像度かフレームレート落とせば収まるだろうけど
153 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 01:09:41.00 ID:cjvlLd9kr.net] >>131 それな
154 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 01:46:55.02 ID:7QW1sL+Z0.net] >>139 動画再生なら今もAMDだがな
155 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 10:34:47.56 ID:EB9ltRQx0.net] >>138 6万弱になってる1080無印でも新しく載せようかと思ってたが 2070待ってた方がいいのかな。
156 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 13:09:31.74 ID:Z9qm6hFN0.net] AMDのGPUは二度と手を出さない 過去にいい思い出がないから
157 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 13:27:48.90 ID:q5uhmf3xM.net] >>148 待てるなら待ったほうがいい それと、2070と2080以上ではいろいろ違いがあるから、可能ならば2080もしくは2080Tiを狙ったほうが後々後悔しなくて済む
158 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 13:40:22.01 ID:vV+sK+U50.net] >>150 NVLINK以外に何が違うのけ?
159 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 15:03:11.50 ID:ycK06X7a0.net] >>151 ・RTX 2080 Ti / 2080 / 2070が登場、スペックや性能、価格と発売日をまとめ https://chimolog.co/bto-gpu-geforce-20-series/#GeForce_RTX_2080 ・GTX 1080 Ti VS RTX 2080 Ti 理論上約20%の性能向上 ・GTX 1080 Ti VS RTX 2080 理論上約13.4%の性能向上(GTX 1080 Tiに近い性能) ・GTX 1070 Ti VS RTX 2070 理論上約9%の低い性能低下(価格は1070Tiよりも100ドル程度上昇したにもかかわらず) ・GTX 1070 VS RTX 2070 理論上約16%の性能向上 コスパで考えると、1070Tiと2070の比較は分が悪い 1070との比較で性能向上したから良しとするならば性能については問題はないが、 今回の2080Ti、2080、2070はすべてチップが別々になっているところから言って、 細かいところで2070は省略されているものがあるのではないかと噂があるのは確か
160 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 15:08:21.91 ID:vV+sK+U50.net] >>152 そのページ古くね? 2070は1080超えてると思うぞ?
161 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 17:37:16.95 ID:kNeKe3/D0.net] 今は買うな時期が悪い7nmまで待て 今は買うな時期が悪いHBM2搭載まで待て とりあえずこれで東京オリンピックまではいける
162 名前:名無しさん@編集中 mailto:sage [2018/09/15(土) 18:05:15.54 ID:J9FwwRkQ0.net] >>147 > 動画再生なら今もAMDだがな 動画再生におけるAMD GPU →メリット ・Fluid Motionがある。 →デメリット ・VP9のDXVAに対応しているのが今のところRavenRidgeのみ。 他に何かあるっけ?
163 名前:名無しさん@編集中 mailto:sage [2018/09/16(日) 02:11:11.67 ID:PMq8EgC10.net] 2050Tiはまだか
164 名前:名無しさん@編集中 mailto:sage [2018/09/16(日) 12:06:58.48 ID:BkKFxbPh0.net] 2060狙いだわ俺
165 名前:名無しさん@編集中 mailto:sage [2018/09/16(日) 14:23:06.56 ID:sg7wXxWi0.net] 2020 TOKYO Olympicモデルは出ますか?
166 名前:名無しさん@編集中 mailto:sage [2018/09/16(日) 17:38:32.95 ID:UIqfW6niM.net] >>158 オリンピックで頭の中がいっぱいの蜃気楼ことミスターサマータイムにでもお願いしたら?
167 名前:名無しさん@編集中 mailto:sage [2018/09/19(水) 03:43:00.21 ID:xo7/0Jwt0.net] 2030までじっと待つよ
168 名前:名無しさん@編集中 [2018/09/20(木) 04:45:35.71 ID:wD9/jjC60.net] コピペ 836 名前:Socket774[sage] 投稿日:2018/09/17(月) 08:45:38.58 ID:qUO+QI5X0 (
169 名前:PC) GTX1060とGTX1050はNVENCの速度一緒らいいんですけど、GTX1050とGTX950は変わりますか?どれくらい変わりますかね 884 名前:836[sage] 投稿日:2018/09/19(水) 10:43:23.58 ID:nm/uFXXB0 [1/4] (PC) 836ですけどあまりにも気になったので買って1時間の動画のNVENC速度を比較してみました GTX950 2GB 7分43秒 http://i.imgur.com/BWC2skv.jpg http://i.imgur.com/83Pnzm8.jpg http://i.imgur.com/fEOzVgZ.jpg http://i.imgur.com/eIrkJsy.jpg GTX1060 6GB 4分33秒 http://i.imgur.com/MR7u0SY.jpg http://i.imgur.com/n43YZgH.jpg http://i.imgur.com/BZdGzVz.jpg http://i.imgur.com/YVzC1sV.jpg 9世代のNVENCめちゃめちゃ遅いですね。ヤフオクで売ってきます [] [ここ壊れてます]
170 名前:名無しさん@編集中 mailto:sage [2018/09/20(木) 07:24:20.06 ID:vSkJq7A40.net] 今度は2070あたりで試しそうw
171 名前:名無しさん@編集中 mailto:sage [2018/09/20(木) 16:33:06.73 ID:lKO/EpKZ0.net] >>161 【Pascal】NVIDIA GeForce GTX10XX総合 Part115 https://egg.5ch.net/test/read.cgi/jisaku/1535363555/836-884 ・ソース 1440x1080、29.97fps ・コマンド ffmpeg.exe -i mpeg2.ts -c:v hevc_nvenc -b:v 3000k output.mp4 ・結果 GTX950 236fps GTX1060 399fps どうせやるなら ffmpeg.exe -hwaccel cuvid -c:v mpeg2_cuvid -i mpeg2.ts -c:v hevc_nvenc -b:v 3000k output.mp4 にしてデコードもHWでやった方がよい気もするけど、MPEG2だとSWデコードと大して変わらないかな?
172 名前:名無しさん@編集中 mailto:sage [2018/09/20(木) 16:50:31.73 ID:ZsqadvCjd.net] >>163 これ、CUDA数とか全く関係ないNVENC能力だけのエンコ結果なの?
173 名前:名無しさん@編集中 mailto:sage [2018/09/20(木) 19:02:45.31 ID:lKO/EpKZ0.net] >>164 CODEC SDKのドキュメントによると、NVENCも ・Two-pass rate control modes for high quality presets ・Look-ahead ・All adaptive quantization modes ・Weighted prediction ・Encoding of RGB contents ではCUDAを使うけど、影響は最小限で気にするほどのことではないみたいだし、CUDAコア数は関係ないかな。 ffmpegのデフォルト設定で上記機能がどう有効/無効になるのか知らんけど。 ちなみに各世代のNVDEC/NVENCのパフォーマンスについてはSDKのドキュメントに表が載ってる。 NVIDIA各世代GPU(Kepler〜Pascal)のNVDEC/NVENCのパフォーマンス(解像度1920x1080) ・NVDEC→ 2sen.dip.jp/cgi-bin/upgun/up2/source/up3508.jpg ・NVENC→ 2sen.dip.jp/cgi-bin/upgun/up2/source/up3509.jpg ※Video_Codec_SDK_8.2.15より。 >>161 (>>163 )で仮にSWデコードがボトルネックになってるとすると、 HWデコードにすればPascalはもう少し伸びる可能性はあるかも。
174 名前:名無しさん@編集中 mailto:sage [2018/09/20(木) 19:06:05.15 ID:lKO/EpKZ0.net] 参考: ffmpegでNVDEC(CUVID)/NVENCを使ってフルHWトランスコードする方法 HWAccelIntro ? FFmpeg https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNVDEC
175 名前:名無しさん@編集中 mailto:sage [2018/09/20(木) 19:31:19.63 ID:BCCdw+boM.net] 2080出たけどnvencは速くなる?クロックが2000MHz近いし消費電力がすごいから電源も必要だけど
176 名前:名無しさん@編集中 mailto:sage [2018/09/20(木) 20:00:35.48 ID:F9/vH15Ea.net] ゴミネオ注意報
177 名前:名無しさん@編集中 mailto:sage [2018/09/20(木) 22:44:29.64 ID:2H1c86eW0.net] 今回もマクロブロック捜査部分が強化入っている 当該処理が重くなる、より高解像度での処理や、ブロックパターンの複雑なHEVCでより効果が大きいそうな 解像度による速度低下の緩和 複雑なマクロブロック配置の最適化でH264で1割強、HEVCで2割強の画質容量比の改善とからしい
178 名前: [] [ここ壊れてます]
179 名前:名無しさん@編集中 mailto:sage [2018/09/20(木) 22:56:50.16 ID:F9/vH15Ea.net] 西川レジェンド善司氏のレポート待ちですな
180 名前:名無しさん@編集中 mailto:sage [2018/09/20(木) 23:51:49.65 ID:YsH+9uCm0.net] >>169 どこの情報?
181 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 00:03:13.17 ID:5ndzxww90.net] >>137-138 を読んでないのか
182 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 00:31:24.95 ID:V511doi/0.net] >>172 それにはマクロブロックどうこうということまでは書かれてないから、 どっか別のとこでに詳細な説明でもされてたのかなと思って。 NVIDIA Turing Architecture In-Depth | NVIDIA Developer Blog https://devblogs.nvidia.com/nvidia-turing-architecture-in-depth/ の記事でもそこまでは書かれてないし。
183 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 01:41:09.43 ID:5ndzxww90.net] 資料としてマクロブロックと明言しているものは確かに見当たらないね ただ、H.264で15%、HEVCで25%もの改善を得るとの文面から考えると、H.264から強化された動き保障精度向上のための マクロブロック(HEVCではCUとか言うのだったか?)の探索範囲の強化がキモであるわけだから、実質的にマクロブロック 関連の処理の改善がされているだろうことは容易に想像できる もちろん、Bフレーム関連とかも手は入っているとは思われるが
184 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 05:59:20.60 ID:GcHtw70R0.net] HEVCはBフレームサポートして改善したとかの方が説得力あると思うよ
185 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 09:36:29.68 ID:U1pwa+rf0.net] Bフレームなくても困ってないしなぁ あるに越したことはないけど
186 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 12:44:58.95 ID:7HD3xzwNa.net] >>175 Bフレは所詮オプション あんなものの改良で25%もの改善は無理だ それにBフレに頼りすぎると画質低下の要因にもなるから、必要最小限の利用に留めることが肝心
187 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 15:26:42.06 ID:lKRfOAqF0.net] >>177 >>75 と>>78 のQSV H.264の例で A: --brframes 0 B:--brframes 3 --b-pyramid を比較すると A:3000kbps→B:2100kbps = 30%のビットレート削減 (SSIM=0.988ライン) A:36000kbps→B:30000kbps = 17%のビットレート削減 (SSIM=0.92ライン) になってるけどな。 NVENCのH.264で同様の調査をしてくれる人がいるといいんだが。
188 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 15:46:40.15 ID:7HD3xzwNa.net] >>177 そりゃ0と3を比較したらそうなるよ NVENCはBフレ自体は既に対応しているのだから、改善したと発表するならば同じBフレ設定条件下でどれだけ変化するのかを比較しないと意味がない
189 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 16:00:58.80 ID:lKRfOAqF0.net] >>179 いや、25%の改善と言ってるのはHEVCでしょ。 NVENCのHEVCは現状Bフレーム未対応なんだから、対応すればビットレート25%削減もできそうだねってことを QSVのH.264の例を出して書いただけ。 まあHEVCでBフレーム対応するとは限らないし、H.264も改善されてるんだから Bフレーム以外の改善もあるだろうし、まだなんとも言えんけどね。
190 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 16:31:03.94 ID:7HD3xzwNa.net] >>180 勘違いしていた NVENCのHEVCは、Bフレに対応していなかったな 対応しているのはQSVのほうだな とは言え、すでにBフレ対応済のH.264でも15%の改善をし、さらにHEVCでは25%の改善となると、 共通して改善できる部分はマクロブロック関連が1番大きいだろうことは疑いようがない エンコーダの動作の7割方はマクロブロックがらみなのだから
191 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 16:36:14.83 ID:lKRfOAqF0.net] まあ細かいことはよくわかってないんだけど、俺としては>>169 が元情報を明かしてくれるのを願うばかり。
192 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 16:50:38.73 ID:7HD3xzwNa.net] 現物を買った人がマクロブロックの探索モードに、パスカル以前にはなかった新しいモードが搭載されたか確認してくれるのが1番手っ取り早い方法かと あと、もちろんBフレの対応可否 Bフレについては公式発表が何もなかった時点で期待しにくいけれど…
193 名前:名無しさん@編集中 mailto:sage [2018/09/21(金) 23:19:25.16 ID:GcHtw70R0.net] 新しいモードが搭載されたかなんてどうやって確認するの? オプションが増えたのなら現物なくてもSDKのドキュメントに書いてあるでしょ
194 名前:名無しさん@編集中 mailto:sage [2018/09/23(日) 02:42:30.46 ID:j3oG3i0p0.net] HEVCのブロック捜査処理を最適化すすめて高速化したら、副次的に細部確認すれば解る程度の画質も改善してたという程度だけだったPascalの時もMaxwellから強化されていても捜査モードの追加なんて無かったし そもそもエンジン側の処理でQSVみたいにGPGPU処理にしていないからモード切り換え意義が無いんだが モードの有無で確認出来ると思っている理由が知りたい
195 名前:名無しさん@編集中 mailto:sage [2018/09/23(日) 03:29:43.62 ID:bRzvZQZ60.net] >>185 その前に>>169 の > 今回もマクロブロック捜査部分が強化入っている > 当該処理が重くなる、より高解像度での処理や、ブロックパターンの複雑なHEVCでより効果が大きいそうな > 解像度による速度低下の緩和 > 複雑なマクロブロック配置の最適化で という話がどこで聞いたものなのか教えてもらえると嬉しいのだが・・・。 探索モード云々は>>183 のちょっと先走った想像にすぎないから、情報の無い段階で考えてもしょうがないと思うけど、 こっそりTuringのNVENCコアに追加された(あるいは従来も実装されてたけど使ってなかった)とかで 今後のSDKの更新で新たに利用可能になるという可能性も・・・、うん、まあ無さそうだけど。
196 名前:名無しさん@編集中 mailto:sage [2018/09/23(日) 03:51:56.86 ID:HyLnLbY70.net] >>185 HWなんだから複数のモード実装して無駄に回路規模増やすとはあまり考えられないし、 新しいモードが追加されることをなんらかのルートを通じて知っていたとかかな https://devtalk.nvidia.com/default/topic/1038493/video-codec-sdk/details-about-nvenc-in-turing-/post/5285387/#5285387 試した人によると、GTX1080とあまり変わらなかったらしい 25%の性能向上は、今後のドライバの更新、あるいは、新しいSDKでソフトウェア側の対応必須って感じかな >>186 Turingに対応した新しいSDKがまだ出てないから、分からないよ 新しいモードが追加されるにしてもSDK出ないと使えるようにならないし
197 名前:名無しさん@編集中 mailto:sage [2018/09/23(日) 04:01:14.05 ID:HyLnLbY70.net] モードが追加されるにしても、新しいSDK出ないと分からないし、 そのままエンコードしてもBフレームは出力されないし、性能向上もあまりないんじゃ 現物あっても何も分からないね >>183 はなぜ現物があれば分かると思ったのだろうか・・・
198 名前:名無しさん@編集中 mailto:sage [2018/09/23(日) 04:02:53.30 ID:bRzvZQZ60.net] >>187 > Turingに対応した新しいSDKがまだ出てないから うん、それは理解してる。>>186 で書いたのは「今後の(Turingに対応した)SDKの更新」ってこと。
199 名前:名無しさん@編集中 [2018/10/14(日) 02:00:33.76 ID:kbRq5SJT0.net] アホな質問だと思うけど誰か答えてくれると嬉しい 動画のカット・字幕など付けて可逆圧縮のAVI出力したものを最終的に NVEncCのHWエンコで高速にリサイズしたいんだけど、コーデックに対応してない?から現状無理 って認識であってる?他にうまいやり方あるんだろうか。
200 名前:名無しさん@編集中 mailto:sage [2018/10/14(日) 02:48:45.54 ID:Lnrlmmek0.net] リサイズがしたいのか、NVENCでエンコードしたいのか、可逆圧縮にしたいのかって感じですな 読めるように書き出してあればリサイズはできる。NVENCはエンコーダーであってリサイズはAvitulとかそっちの仕事 リサイズして可逆圧縮で保存したいならNVENCは必要ないので、高速のCPUを買う あとNVECNで吐き出すものは可逆圧縮じゃないきがする
201 名前:名無しさん@編集中 mailto:sage [2018/10/14(日) 03:18:47.39 ID:v7cF/vO60.net] >>191 いや、>>190 は可逆圧縮したAVIファイルをNVEncCで読み込んで --vpp-resizeや--output-resを使ってリサイズ&エンコードしたいってことでしょ。 --losslessにしたいのかどうかは知らんけど。 >>190 その質問をするなら可逆圧縮に使ったコーデック名(必要ならその設定も)をちゃんと書くべきだと思うが・・・。 まあ一応答えるけど、AMVシリーズなら --avi で読み込めばよさそうだし、avs経由で--avs読みするという手もある。 UtVideoならffmpegで対応してるから、上の手法に加えて--avswでも読めると思う。 ただ、どんな編集ソフト使ってるのか知らないけど、そもそも可逆圧縮AVIを挟む意味あるの? カットも字幕もAviUtlでやって、NVEnc.auoで出力すればいいだけのような・・・。
202 名前:名無しさん@編集中 mailto:sage [2018/10/14(日) 11:28:47.80 ID:kbRq5SJT0.net] >>191 >>192 まず質問に答えてくれてありがとうございます。 まさに>>192 が言ってくれている通り、あらかた編集を済ませたものを-vpp-resizeでリサイズ&エンコードできればなと。 使ってるコーデックはUtVideoの420でAviutlを使用しています。 最終的にvppで2kとか4kとかにリサイズしたくnvenccのhwエンコードの速度に惹かれた次第です AVI出力も含めたトータルの時間で早くなるのかな?と そんなのAviutlでsharpen-resizeでも使えばと言われそうですが せっかくnvenccで出来るのであればと思ったのと、単純に新グラボのSDK?とか 技術的な進歩に対応してるんだから良いんじゃないか?と思った次第です。 他に策があるようなので少し勉強して試したいと思います、ありがとうございました。
203 名前:名無しさん@編集中 mailto:sage [2018/10/14(日) 18:24:58.71 ID:ZlTDkV240.net] >>193 >>192 で書いたけど、UtVideo出力せずに、拡張NVEnc出力(NVEnc.auo)で 「フィルタ」タブの「リサイズ」を有効にしてエンコードすれば、それでいいのでは。 NVEncCの--vpp-resizeや--output-res指定と同等だし、 わざわざ可逆でサイズが巨大なファイルを中間出力する意味はないと思うよ。 2Kや4Kへのリサイズというのが拡大するということなら、そもそも拡大自体やめた方がいい気はするけど。
204 名前:名無しさん@編集中 mailto:sage [2018/10/14(日) 21:30:04.16 ID:kbRq5SJT0.net] >>194 自分が一番こだわっているのがHWエンコの速度という部分でして、以前のどこかで質問した時に Aviutlはデコードの部分に時間がかかると聞きました だったら最終的な仕上げだけnvenccでやれば良いのでは?と考えに至り 何分使用しているPCが何世代も前のi5、グラボがgtx1050tiという貧弱構成でして・・・ 2kや4kの拡大の件も苦肉の策といいますか、やってるゲームをyoutubeにアップしているんですが 1080pであげた物と2kや4kで上げてVP9でエンコされた物を目視で比較するとVP9のほうが綺麗だなと なぜかは知りませんがエフェクトが激しい場面での破綻がより少ないカンジに見えました 同じ素材をx264(ソフト)やnvenc(ハード)でyoutubeにupしても、2kや4kでupしたVP9の動画のほうが綺麗に見える。 これはもうyoutube側の仕様なのかな?という結論に至り(自分の中で) 正直いいますと2kや4kにはあまりこだわっていないんです 動画編集をやってエンコードを調べていくほど「知りたい」 と思った次第であります、丁寧にお返事ありがとうございます。
205 名前:名無しさん@編集中 mailto:sage [2018/10/14(日) 22:00:48.85 ID:ur+KzSlL0.net] >>195 いくらAviutlでNVEnc使うと遅いって言っても、UtVideoで可逆圧縮出力するよりは速いぞ デコードが遅いと言うより、Aviutlの中をフレームが通るのが遅いってだけ もう既にAviutl通してるんだったら、直接NVEnc(NVEnc.auo)で出力したほうが良いに決まってる
206 名前:名無しさん@編集中 mailto:sage [2018/10/14(日) 23:56:22.28 ID:kbRq5SJT0.net] >>196 なるほど勉強になりました、素直にNVEncでやろうと思います。
207 名前:名無しさん@編集中 [2018/10/15(月) 00:17:08.43 ID:25ikQSo00.net] こういう
208 名前:CPUで、ソフトエンコすればいい。 https://i.imgur.com/TrqBnGs.jpg [] [ここ壊れてます]
209 名前:名無しさん@編集中 mailto:sage [2018/10/16(火) 04:48:50.77 ID:MU8B31bq0.net] >1080pであげた物と2kや4kで上げてVP9でエンコされた物を目視で比較するとVP9のほうが綺麗 VP9の方が後発なんだから当たり前やん
210 名前:名無しさん@編集中 mailto:sage [2018/10/16(火) 07:59:53.94 ID:we4ARETc0.net] HWデコード支援も出てきてるし今後増えるんだろうけど まだまだ扱いにくいわなぁ
211 名前:名無しさん@編集中 mailto:sage [2018/10/16(火) 08:47:21.11 ID:FHIjlP1LM.net] 先月あたりからyoutubeがhevcに対応してるような
212 名前:名無しさん@編集中 mailto:sage [2018/10/16(火) 16:11:12.15 ID:Tzq1uDqUa.net] !! マジで? Appleの圧力? こうなるとYouTube側にもしオリジナルが残っているならばダウンロードし直したくなるな… ビットレートと画質次第だけど
213 名前:名無しさん@編集中 mailto:sage [2018/10/16(火) 17:00:16.15 ID:5Qu0m5+G0.net] >>195 > 1080pであげた物と2kや4kで上げてVP9でエンコされた物を目視で比較するとVP9のほうが綺麗 ・1080pと2kって同じものでは? ・どれとどれを比較したのかよくわからん。 ・1080p投稿→H.264/1080p再エンコ ・1080p投稿→VP9/1080p再エンコ ・4K拡大投稿→VP9/4K(2160p)再エンコ ・4K拡大投稿→VP9/1080p再エンコ ・比較条件もよくわからん。4K拡大投稿して4K再エンコされたものを1080p縮小状態で見たら綺麗だったという話なら、 そりゃそうなることが多いだろうという感じだが。 >>199 > VP9の方が後発なんだから当たり前 そんなわけない。 ビットレートの違いもあるから、H.264よりVP9の方が汚いことも普通にある。