【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】at AVI
【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】 - 暇つぶし2ch150:だろ どう見てもなさそうだねw 費用対効果で割りに合わないと思ってそう



151:名無しさん@編集中
18/09/15 01:04:36.37 rLzU4Nl20.net
>>140
6Mbpsか・・
2Mbpsとかでも馬脚を出さなかったら凄いけど
どうなんだろ

152:名無しさん@編集中
18/09/15 01:08:09.38 6Guydu2D0.net
>>144
2MbpsはHEVCでもキツいだろ
解像度かフレームレート落とせば収まるだろうけど

153:名無しさん@編集中
18/09/15 01:09:41.00 cjvlLd9kr.net
>>131
それな

154:名無しさん@編集中
18/09/15 01:46:55.02 7QW1sL+Z0.net
>>139
動画再生なら今もAMDだがな

155:名無しさん@編集中
18/09/15 10:34:47.56 EB9ltRQx0.net
>>138
6万弱になってる1080無印でも新しく載せようかと思ってたが
2070待ってた方がいいのかな。

156:名無しさん@編集中
18/09/15 13:09:31.74 Z9qm6hFN0.net
AMDのGPUは二度と手を出さない
過去にいい思い出がないから

157:名無しさん@編集中
18/09/15 13:27:48.90 q5uhmf3xM.net
>>148
待てるなら待ったほうがいい
それと、2070と2080以上ではいろいろ違いがあるから、可能ならば2080もしくは2080Tiを狙ったほうが後々後悔しなくて済む

158:名無しさん@編集中
18/09/15 13:40:22.01 vV+sK+U50.net
>>150
NVLINK以外に何が違うのけ?

159:名無しさん@編集中
18/09/15 15:03:11.50 ycK06X7a0.net
>>151
・RTX 2080 Ti / 2080 / 2070が登場、スペックや性能、価格と発売日をまとめ
URLリンク(chimolog.co)
・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:名無しさん@編集中
18/09/15 15:08:21.91 vV+sK+U50.net
>>152
そのページ古くね?
2070は1080超えてると思うぞ?

161:名無しさん@編集中
18/09/15 17:37:16.95 kNeKe3/D0.net
今は買うな時期が悪い7nmまで待て
今は買うな時期が悪いHBM2搭載まで待て
とりあえずこれで東京オリンピックまではいける

162:名無しさん@編集中
18/09/15 18:05:15.54 J9FwwRkQ0.net
>>147
> 動画再生なら今もAMDだがな
動画再生におけるAMD GPU
  →メリット
     ・Fluid Motionがある。
  →デメリット
     ・VP9のDXVAに対応しているのが今のところRavenRidgeのみ。
他に何かあるっけ?

163:名無しさん@編集中
18/09/16 02:11:11.67 PMq8EgC10.net
2050Tiはまだか

164:名無しさん@編集中
18/09/16 12:06:58.48 BkKFxbPh0.net
2060狙いだわ俺

165:名無しさん@編集中
18/09/16 14:23:06.56 sg7wXxWi0.net
2020 TOKYO Olympicモデルは出ますか?

166:名無しさん@編集中
18/09/16 17:38:32.95 UIqfW6niM.net
>>158
オリンピックで頭の中がいっぱいの蜃気楼ことミスターサマータイムにでもお願いしたら?

167:名無しさん@編集中
18/09/19 03:43:00.21 xo7/0Jwt0.net
2030までじっと待つよ

168:名無しさん@編集中
18/09/20 04:45:35.71 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:名無しさん@編集中
18/09/20 07:24:20.06 vSkJq7A40.net
今度は2070あたりで試しそうw

171:名無しさん@編集中
18/09/20 16:33:06.73 lKO/EpKZ0.net
>>161
【Pascal】NVIDIA GeForce GTX10XX総合 Part115
スレリンク(jisaku板: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:名無しさん@編集中
18/09/20 16:50:31.73 ZsqadvCjd.net
>>163
これ、CUDA数とか全く関係ないNVENC能力だけのエンコ結果なの?

173:名無しさん@編集中
18/09/20 19:02:45.31 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→ URLリンク(2sen.dip.jp)
  ・NVENC→ URLリンク(2sen.dip.jp)
  ※Video_Codec_SDK_8.2.15より。
>>161(>>163)で仮にSWデコードがボトルネックになってるとすると、
HWデコードにすればPascalはもう少し伸びる可能性はあるかも。

174:名無しさん@編集中
18/09/20 19:06:05.15 lKO/EpKZ0.net
参考: ffmpegでNVDEC(CUVID)/NVENCを使ってフルHWトランスコードする方法
 HWAccelIntro ? FFmpeg
 URLリンク(trac.ffmpeg.org)

175:名無しさん@編集中
18/09/20 19:31:19.63 BCCdw+boM.net
2080出たけどnvencは速くなる?クロックが2000MHz近いし消費電力がすごいから電源も必要だけど

176:名無しさん@編集中
18/09/20 20:00:35.48 F9/vH15Ea.net
ゴミネオ注意報

177:名無しさん@編集中
18/09/20 22:44:29.64 2H1c86eW0.net
今回もマクロブロック捜査部分が強化入っている
当該処理が重くなる、より高解像度での処理や、ブロックパターンの複雑なHEVCでより効果が大きいそうな
解像度による速度低下の緩和
複雑なマクロブロック配置の最適化でH264で1割強、HEVCで2割強の画質容量比の改善とからしい


178:



179:名無しさん@編集中
18/09/20 22:56:50.16 F9/vH15Ea.net
西川レジェンド善司氏のレポート待ちですな

180:名無しさん@編集中
18/09/20 23:51:49.65 YsH+9uCm0.net
>>169
どこの情報?

181:名無しさん@編集中
18/09/21 00:03:13.17 5ndzxww90.net
>>137-138を読んでないのか

182:名無しさん@編集中
18/09/21 00:31:24.95 V511doi/0.net
>>172
それにはマクロブロックどうこうということまでは書かれてないから、
どっか別のとこでに詳細な説明でもされてたのかなと思って。
 NVIDIA Turing Architecture In-Depth | NVIDIA Developer Blog
 URLリンク(devblogs.nvidia.com)
の記事でもそこまでは書かれてないし。

183:名無しさん@編集中
18/09/21 01:41:09.43 5ndzxww90.net
資料としてマクロブロックと明言しているものは確かに見当たらないね
ただ、H.264で15%、HEVCで25%もの改善を得るとの文面から考えると、H.264から強化された動き保障精度向上のための
マクロブロック(HEVCではCUとか言うのだったか?)の探索範囲の強化がキモであるわけだから、実質的にマクロブロック
関連の処理の改善がされているだろうことは容易に想像できる
もちろん、Bフレーム関連とかも手は入っているとは思われるが

184:名無しさん@編集中
18/09/21 05:59:20.60 GcHtw70R0.net
HEVCはBフレームサポートして改善したとかの方が説得力あると思うよ

185:名無しさん@編集中
18/09/21 09:36:29.68 U1pwa+rf0.net
Bフレームなくても困ってないしなぁ
あるに越したことはないけど

186:名無しさん@編集中
18/09/21 12:44:58.95 7HD3xzwNa.net
>>175
Bフレは所詮オプション
あんなものの改良で25%もの改善は無理だ
それにBフレに頼りすぎると画質低下の要因にもなるから、必要最小限の利用に留めることが肝心

187:名無しさん@編集中
18/09/21 15:26:42.06 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:名無しさん@編集中
18/09/21 15:46:40.15 7HD3xzwNa.net
>>177
そりゃ0と3を比較したらそうなるよ
NVENCはBフレ自体は既に対応しているのだから、改善したと発表するならば同じBフレ設定条件下でどれだけ変化するのかを比較しないと意味がない

189:名無しさん@編集中
18/09/21 16:00:58.80 lKRfOAqF0.net
>>179
いや、25%の改善と言ってるのはHEVCでしょ。
NVENCのHEVCは現状Bフレーム未対応なんだから、対応すればビットレート25%削減もできそうだねってことを
QSVのH.264の例を出して書いただけ。
まあHEVCでBフレーム対応するとは限らないし、H.264も改善されてるんだから
Bフレーム以外の改善もあるだろうし、まだなんとも言えんけどね。

190:名無しさん@編集中
18/09/21 16:31:03.94 7HD3xzwNa.net
>>180
勘違いしていた
NVENCのHEVCは、Bフレに対応していなかったな
対応しているのはQSVのほうだな
とは言え、すでにBフレ対応済のH.264でも15%の改善をし、さらにHEVCでは25%の改善となると、
共通して改善できる部分はマクロブロック関連が1番大きいだろうことは疑いようがない
エンコーダの動作の7割方はマクロブロックがらみなのだから

191:名無しさん@編集中
18/09/21 16:36:14.83 lKRfOAqF0.net
まあ細かいことはよくわかってないんだけど、俺としては>>169が元情報を明かしてくれるのを願うばかり。

192:名無しさん@編集中
18/09/21 16:50:38.73 7HD3xzwNa.net
現物を買った人がマクロブロックの探索モードに、パスカル以前にはなかった新しいモードが搭載されたか確認してくれるのが1番手っ取り早い方法かと
あと、もちろんBフレの対応可否
Bフレについては公式発表が何もなかった時点で期待しにくいけれど…

193:名無しさん@編集中
18/09/21 23:19:25.16 GcHtw70R0.net
新しいモードが搭載されたかなんてどうやって確認するの?
オプションが増えたのなら現物なくてもSDKのドキュメントに書いてあるでしょ

194:名無しさん@編集中
18/09/23 02:42:30.46 j3oG3i0p0.net
HEVCのブロック捜査処理を最適化すすめて高速化したら、副次的に細部確認すれば解る程度の画質も改善してたという程度だけだったPascalの時もMaxwellから強化されていても捜査モードの追加なんて無かったし
そもそもエンジン側の処理でQSVみたいにGPGPU処理にしていないからモード切り換え意義が無いんだが
モードの有無で確認出来ると思っている理由が知りたい

195:名無しさん@編集中
18/09/23 03:29:43.62 bRzvZQZ60.net
>>185
その前に>>169
 > 今回もマクロブロック捜査部分が強化入っている
 > 当該処理が重くなる、より高解像度での処理や、ブロックパターンの複雑なHEVCでより効果が大きいそうな
 > 解像度による速度低下の緩和
 > 複雑なマクロブロック配置の最適化で
という話がどこで聞いたものなのか教えてもらえると嬉しいのだが・・・。
探索モード云々は>>183のちょっと先走った想像にすぎないから、情報の無い段階で考えてもしょうがないと思うけど、
こっそりTuringのNVENCコアに追加された(あるいは従来も実装されてたけど使ってなかった)とかで
今後のSDKの更新で新たに利用可能になるという可能性も・・・、うん、まあ無さそうだけど。

196:名無しさん@編集中
18/09/23 03:51:56.86 HyLnLbY70.net
>>185
HWなんだから複数のモード実装して無駄に回路規模増やすとはあまり考えられないし、
新しいモードが追加されることをなんらかのルートを通じて知っていたとかかな
URLリンク(devtalk.nvidia.com)
試した人によると、GTX1080とあまり変わらなかったらしい
25%の性能向上は、今後のドライバの更新、あるいは、新しいSDKでソフトウェア側の対応必須って感じかな
>>186
Turingに対応した新しいSDKがまだ出てないから、分からないよ
新しいモードが追加されるにしてもSDK出ないと使えるようにならないし

197:名無しさん@編集中
18/09/23 04:01:14.05 HyLnLbY70.net
モードが追加されるにしても、新しいSDK出ないと分からないし、
そのままエンコードしてもBフレームは出力されないし、性能向上もあまりないんじゃ
現物あっても何も分からないね
>>183はなぜ現物があれば分かると思ったのだろうか・・・

198:名無しさん@編集中
18/09/23 04:02:53.30 bRzvZQZ60.net
>>187
> Turingに対応した新しいSDKがまだ出てないから
うん、それは理解してる。>>186で書いたのは「今後の(Turingに対応した)SDKの更新」ってこと。

199:名無しさん@編集中
18/10/14 02:00:33.76 kbRq5SJT0.net
アホな質問だと思うけど誰か答えてくれると嬉しい
動画のカット・字幕など付けて可逆圧縮のAVI出力したものを最終的に
NVEncCのHWエンコで高速にリサイズしたいんだけど、コーデックに対応してない?から現状無理
って認識であってる?他にうまいやり方あるんだろうか。

200:名無しさん@編集中
18/10/14 02:48:45.54 Lnrlmmek0.net
リサイズがしたいのか、NVENCでエンコードしたいのか、可逆圧縮にしたいのかって感じですな
読めるように書き出してあればリサイズはできる。NVENCはエンコーダーであってリサイズはAvitulとかそっちの仕事
リサイズして可逆圧縮で保存したいならNVENCは必要ないので、高速のCPUを買う
あとNVECNで吐き出すものは可逆圧縮じゃないきがする

201:名無しさん@編集中
18/10/14 03:18:47.39 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:名無しさん@編集中
18/10/14 11:28:47.80 kbRq5SJT0.net
>>191
>>192
まず質問に答えてくれてありがとうございます。
まさに>>192が言ってくれている通り、あらかた編集を済ませたものを-vpp-resizeでリサイズ&エンコードできればなと。
使ってるコーデックはUtVideoの420でAviutlを使用しています。
最終的にvppで2kとか4kとかにリサイズしたくnvenccのhwエンコードの速度に惹かれた次第です
AVI出力も含めたトータルの時間で早くなるのかな?と
そんなのAviutlでsharpen-resizeでも使えばと言われそうですが
せっかくnvenccで出来るのであればと思ったのと、単純に新グラボのSDK?とか
技術的な進歩に対応してるんだから良いんじゃないか?と思った次第です。
他に策があるようなので少し勉強して試したいと思います、ありがとうございました。

203:名無しさん@編集中
18/10/14 18:24:58.71 ZlTDkV240.net
>>193
>>192で書いたけど、UtVideo出力せずに、拡張NVEnc出力(NVEnc.auo)で
「フィルタ」タブの「リサイズ」を有効にしてエンコードすれば、それでいいのでは。
NVEncCの--vpp-resizeや--output-res指定と同等だし、
わざわざ可逆でサイズが巨大なファイルを中間出力する意味はないと思うよ。
2Kや4Kへのリサイズというのが拡大するということなら、そもそも拡大自体やめた方がいい気はするけど。

204:名無しさん@編集中
18/10/14 21:30:04.16 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:名無しさん@編集中
18/10/14 22:00:48.85 ur+KzSlL0.net
>>195
いくらAviutlでNVEnc使うと遅いって言っても、UtVideoで可逆圧縮出力するよりは速いぞ
デコードが遅いと言うより、Aviutlの中をフレームが通るのが遅いってだけ
もう既にAviutl通してるんだったら、直接NVEnc(NVEnc.auo)で出力したほうが良いに決まってる

206:名無しさん@編集中
18/10/14 23:56:22.28 kbRq5SJT0.net
>>196
なるほど勉強になりました、素直にNVEncでやろうと思います。

207:名無しさん@編集中
18/10/15 00:17:08.43 25ikQSo00.net
こういう


208:CPUで、ソフトエンコすればいい。 https://i.imgur.com/TrqBnGs.jpg



209:名無しさん@編集中
18/10/16 04:48:50.77 MU8B31bq0.net
>1080pであげた物と2kや4kで上げてVP9でエンコされた物を目視で比較するとVP9のほうが綺麗
VP9の方が後発なんだから当たり前やん

210:名無しさん@編集中
18/10/16 07:59:53.94 we4ARETc0.net
HWデコード支援も出てきてるし今後増えるんだろうけど
まだまだ扱いにくいわなぁ

211:名無しさん@編集中
18/10/16 08:47:21.11 FHIjlP1LM.net
先月あたりからyoutubeがhevcに対応してるような

212:名無しさん@編集中
18/10/16 16:11:12.15 Tzq1uDqUa.net
!!
マジで?
Appleの圧力?
こうなるとYouTube側にもしオリジナルが残っているならばダウンロードし直したくなるな…
ビットレートと画質次第だけど

213:名無しさん@編集中
18/10/16 17:00:16.15 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の方が汚いことも普通にある。

214:名無しさん@編集中
18/10/16 17:01:06.97 5Qu0m5+G0.net
>>201
> 先月あたりからyoutubeがhevcに対応してるような
「対応」ってどういう意味?
「HEVCでの投稿」ってことなら結構前から対応してたはずだし、
先月あたりから対応と言えばAV1のテスト配信くらいだと思うし、
配信にHEVCを使うなんて話は出てないと思うけど。

215:名無しさん@編集中
18/10/16 20:25:50.76 /AsRmAMe0.net
WebMの立場は・・・

216:名無しさん@編集中
18/10/17 01:49:06.98 p2fT1tI10.net
>>203
自分が比較したのは1080p,1440p,2160p
VP9で再エンコされるラインが1440p以上っぽい
再エンコがh264なのかVP9かで破綻具合が違った(特にエフェクトの激しい場面)
・1080p投稿→H.264/1080p再エンコと
・2K拡大投稿→VP9/1080p再エンコ
自分の見解としてはyoutubeのh264とVP9はコーデックが違うこともあり
ビットレートの配分具合とかそもそも割り当てられる総ビットレートが
違うんだろうな(あたりまえなんでしょうが)と学んだ次第です

217:名無しさん@編集中
18/10/17 02:26:19.20 VTrg57yl0.net
 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。

218:名無しさん@編集中
18/10/17 23:36:15.65 tsUttaVy0.net
>>206
> VP9で再エンコされるラインが1440p以上っぽい
ちゃんと検証したわけじゃないが、今のYoutubeは
 ・1080pまでの解像度なら、とりあえずH.264の配信ファイルを作る。
  更に何らかの条件(たぶん再生数やチャンネルの再生実績等)を満たす場合は、
  VP9の配信ファイルも作る。(つまり条件を満たせないとH.264のみとなる)
 ・1080pより上の解像度はVP9でしか配信しないのでVP9の配信ファイルを作る
  (そのため4K投稿すれば、ついでに1080pのVP9も作られる)
という感じになってるようでな。
そこそこ再生数が見込まれる場合は1080p投稿でもVP9ファイルが作られるんだ・・・。
>>203でも書いたけど、動画によってはVP9よりH.264の方が綺麗になることもあるし、
「1080pを確実にVP9で見てもらう」なんて目的で4K拡大投稿するのは無意味だと思うよ。
それに4K投稿した場合、視聴者は4K解像度の綺麗な動画を期待すると思うので、
「1080pの動画を雑に拡大しただけの4K動画」なんて見せたら、失望されるかもしれないし。

219:名無しさん@編集中
18/10/22 13:52:41.31 LE74PYGnd.net
趣味で撮りためた


220:TVアニメや映画をH264で720*480程度にリサイズしてMediacoderでエンコしてたのですが ハードが逝ってしまい、数年ぶりに環境再構築してます CPUも劇的に早くなり、フォーマットやソフトを見直しているのですが下記条件をみたす おすすめのソフトはなんでしょうか? 画面サイズは720*480程度で十分 H264より新しいフォーマット希望 複数ファイルを連続で処理したい(夜間とか) 実時間以下でエンコード終了したい できればフリーソフトが良い アドバイスお願いします



221:名無しさん@編集中
18/10/22 14:15:01.48 W/a+WlvB0.net
PCスペックは?

222:名無しさん@編集中
18/10/22 14:18:57.41 LE74PYGnd.net
>>210
CPUはi5-8400です、オンボードビデオですが
VGAはGT730という骨董品があまってます
付けたら遅くなりそうですはめてません
ram16G、osはssd240Gにwin10home載せて全然あまってます

223:名無しさん@編集中
18/10/22 14:20:47.43 dV3GbeQ00.net
ffmpegでhevc_nvencをバッチとかシェルでぶん回せば?

224:名無しさん@編集中
18/10/22 17:00:14.78 rhRUIsoy0.net
>>209
「AviUtlでバッチのやり方」「rigayaの日記兼メモ帳」をググって読んで、
これで面倒なって思えば、TMPGEncとか多少出費する

225:名無しさん@編集中
18/10/22 18:10:33.41 HqrRwZLZ0.net
>>209
スレ違いなんで移動したほうがいいと思うよ。
■動画変換ソフトウェア総合スレ■
スレリンク(software板)
【初心者歓迎】総合質問スレッド-85-【ダウソNG】
スレリンク(avi板)

226:名無しさん@編集中
18/10/22 18:49:44.81 O0k+sXAi0.net
最近はAmatsukazeにソース投げて終わり
ツールもAviSynthのスクリプトもみんな含まれてる

227:名無しさん@編集中
18/10/24 00:57:56.65 vZuwSmRm0.net
同じHD630のKabyだけどなんかもっさりしてて
GT730の方が体感はよかった 当然Kelperな730
ゲーム一切やらないけどブラウザ描画や動画再生に支援使われて
2GB版のメモリ1GBくらい食ってる
逆にHD630がQSV専用になってしまってる

228:名無しさん@編集中
18/10/24 01:42:54.61 2wO6iHpU0.net
gt730 よりも前に使ってた
10年前の9800gtのcudaの方が
エンコが早かったでござるorz

229:名無しさん@編集中
18/10/24 02:06:29.16 +O/e6gwJ0.net
>>217
速度は速いかもしれんがCUDAの画質は…

230:名無しさん@編集中
18/10/24 08:13:14.82 /AKji+A80.net
速度優先で画質捨ててた、とりあえずHW時代だもんねぇ・・・
NVENCも世代ごとによくなってるってリリースにある通り
詳しくはWikiかなにかにまとめてあったともうぐぐってくだちゃい(-_ゞゴシゴシ

231:名無しさん@編集中
18/10/24 11:26:08.81 Y/cx0/8Md.net
10年近く前からmediacoderのcuda使ってたんですけど
今の主流のエンコはなんですか?
intelのqsvもすごいって聞きますが
gpuのnvencやvce、cpuパワーでソフトエンコなど皆さんどんな
ハードとソフト使ってるんでしょうか?

232:名無しさん@編集中
18/10/24 11:44:49.35 Hh3bFx9M0.net
>>214

233:名無しさん@編集中
18/10/24 12:01:28.90 Y/cx0/8Md.net
>>218
有難う�


234:I



235:名無しさん@編集中
18/10/24 16:56:25.61 eiIZmuL30.net
>>218-219
最新世代のNVEncは、かなりよくなったんじゃなかったっけ?
まだ値段が高いけど

236:名無しさん@編集中
18/10/24 17:31:06.14 YbjGiC9Md.net
>>223
そう、CUDAとNVENCじゃ全く違う

237:名無しさん@編集中
18/10/24 17:36:17.73 lmPUcqNGa.net
GTX1060(6G)でH265エンコしまくりですわ。

238:名無しさん@編集中
18/10/24 17:44:12.07 /AKji+A80.net
RTX2070が7万だものなぁ
そこまでは出費したくないから2050か2030で・・・
スペック次第だけど

239:名無しさん@編集中
18/10/24 17:44:44.66 Y/cx0/8Md.net
gtx1060にはtiはないのですか?
tiは無印と何が違うのでしょうか?

240:名無しさん@編集中
18/10/24 18:14:38.32 lmPUcqNGa.net
RTXは2060か2050まで待とうホトトギス

241:名無しさん@編集中
18/10/24 18:22:44.30 eiIZmuL30.net
・【ニュース・フラッシュ】玄人志向、実売で7万円を切るGeForce RTX 2070
URLリンク(pc.watch.impress.co.jp)
「価格はオープンプライスで、税別店頭予想価格は63,980円前後の見込み。」

242:名無しさん@編集中
18/10/24 18:38:04.53 ZQP/1nQ80.net
>>227
Tiと無印に違いがあるというより、「無印とTiの間に何か関連性がある」という発想自体が間違い
GTX1080と1080Tiのように、Tiが付いたら中身が全く別物になるパターンもある
法則性があるわけではないので、何が違っているのかは自分で一つ一つ把握するしかない

243:名無しさん@編集中
18/10/24 20:06:22.65 KKHs4QU90.net
20シリーズの性能ベンチがほしいな
10シリーズとの比較で
ほぼ値段相応だとは思うけど

244:名無しさん@編集中
18/10/24 21:20:56.38 /AKji+A80.net
>>229
今ならドスパラで64800ってのもあるけどな

245:名無しさん@編集中
18/10/24 21:57:53.57 oqoNC0tH0.net
どれ?
ドスパラとか祖父とか税別表示だからぬか喜びしないように気をつけてる

246:名無しさん@編集中
18/10/24 22:08:19.25 hMzuR7Wk0.net
ハードの値段やらの話は自作板にスレが多数あるんだから、そっちでやったほうがいいと思うよ。

247:名無しさん@編集中
18/10/25 00:22:09.56 STwk5yxX0.net
RTX2070はTU106だから、GP106のGTX1060と一緒でNVEncのエンジンが1基しかないと思う
Maxwell以降は上位のチップには2基積まれて、エンコ2本同時までは速度が落ちない(ただし3本以上同時エンコできるのはQuadroのミドル以上

248:名無しさん@編集中
18/10/25 00:35:02.83 nkF+Xa5s0.net
数は1つでいいや
問題は性能で
Bフレーム使えるみたいだけどその他もどれくらい
性能が上がってるのか気になる
気になるけど買えない
2060待ち

249:名無しさん@編集中
18/10/25 00:35:57.68 STwk5yxX0.net
>>235
106じゃなかった、104だすまん;
処理速度自体の向上は「高解像度で速度低下しづらくなった」ってだけなんで4K以上でエンコしないと殆ど動作クロックなりの速度よ

250:名無しさん@編集中
18/10/25 02:24:14.31 vAq8J/IR0.net
RTX 2080でも2070でもいいけど、
  NVEncC.exe --check-features
で、H.265/HEVCの Max Bframes がどうなるか調べた人ってまだいないのかな?

251:名無しさん@編集中
18/10/25 04:20:47.52 WTE0P24Q0.net
479分 14GBあるAVを容量節約のためにNVENCでH.265の低ビットレートでエンコードしたが速くていいわ(汚い穴が綺麗に見えてしまうので低ビットレートで充分)

252:名無しさん@編集中
18/10/25 05:50:54.84 H+nrIq8F0.net
>>239
新人のインタービューやワンパターンのやるだけ明るい部屋はいいけど、8時間BESTとかだと暗いシーン多くて暗部ひどくならね?

253:名無しさん@編集中
18/10/25 0


254:8:04:27.99 ID:Qmy18hJN0.net



255:名無しさん@編集中
18/10/25 08:23:13.78 d2Cr0J1Ea.net
pascalは上位GTXでも2ストリームまでなのか
その為だけにquadro買うわけにもいかんしなぁ
URLリンク(developer.nvidia.com)

256:名無しさん@編集中
18/10/25 10:13:27.18 2ed29L1A0.net
>>242
昔はこういうMODが流行ったんだけど、今はもう出来ないのかね?
URLリンク(www.eevblog.com)
俺もGT640をGRID K1に書き換えたなw

257:名無しさん@編集中
18/10/25 11:57:30.78 STwk5yxX0.net
>>238
0

258:名無しさん@編集中
18/10/25 12:18:47.45 Qmy18hJN0.net
リアルタイムエンコが目的だからBフレ対応はしないでしょ

259:名無しさん@編集中
18/10/25 12:36:20.43 STwk5yxX0.net
そもそも、H265の圧縮率向上の根幹はI/Pフレの圧縮率向上が大きいからな
だからNVEncのマクロブロック配置ロジックの強化されてもH264に効果が殆ど無くてH265の方に効果が出てる
元々がGPUのクラウド化で画面転送するためのエンジンを転用・下位モデルにも解放してるものだし
わざわざ面倒な方の性能向上するぐらい低レイテンシ保持が大事という

260:名無しさん@編集中
18/10/25 13:41:09.39 bUPCRSoJd.net
265のエンコご優れてるのは分かったのですが
動画再生時デコードにパワー要りますよね?
古いpc環境とか人にも見せたいとか、モバイルでも見たいなら
264の方がまだ使い勝手が良いですか?

261:名無しさん@編集中
18/10/25 14:35:50.05 tONme0Ee0.net
画質音質にこだわるのもいいけど扱いやすさがないと消滅するよ
音質が悪いと叩かれ続けてもmp3が生き残る理由

262:名無しさん@編集中
18/10/25 17:26:52.29 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:名無しさん@編集中
18/10/25 17:44:02.97 STwk5yxX0.net
根掘り葉掘り他人様頼みで身銭切らずに聞いている癖に、証拠まで求めるぐらいなら手前で買えよ
稼働させてるエンコ鯖止めてまでする気は無い

264:名無しさん@編集中
18/10/25 19:02:32.56 7N4Tp5iWF.net
元気だねぇー
何か良いことあった?

265:名無しさん@編集中
18/10/25 20:03:21.41 2ed29L1A0.net
争いは、同じレベルの者同士でしか発生しない!!のAA思い出したw

266:名無しさん@編集中
18/10/26 11:08:46.55 4O36bTgr0.net
>>238
RTX 2070
URLリンク(pastebin.com)
GTX 1060 6GB(参考)
URLリンク(pastebin.com)

267:名無しさん@編集中
18/10/26 11:12:30.11 4O36bTgr0.net
> Codec: H.265/HEVC
> Max Bframes 5
Bフレーム来たね
> Codec: H.264/AVC
> ...
> Field Encoding no
代わりにH264のフィールドエンコーディングが無くなってる?

268:名無しさん@編集中
18/10/26 15:40:22.36 9aUksCRaM.net
とうとうBフレーム対応か
隔世の感


269:がありますなぁ



270:名無しさん@編集中
18/10/26 20:48:35.08 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:名無しさん@編集中
18/10/26 21:53:48.42 5tUyQmet0.net
同ビットレートでの画質差を・・・

272:名無しさん@編集中
18/10/26 21:56:21.34 WduSYcIU0.net
bフレーム対応でようやくハードウェアエンコードが市民権得られる時代になったかな?

273:名無しさん@編集中
18/10/26 22:46:46.03 4O36bTgr0.net
SSIM-ビットレート
URLリンク(i.imgur.com)
URLリンク(i.imgur.com)
一定品質(--vbrhq 0 --vbr-quality N)でエンコード
Nは実写が24,28,32,36、アニメが20,24,28,32
25%の性能向上は本当だったようだ
性能向上は、Bフレームで半分、その他で半分くらい

274:名無しさん@編集中
18/10/26 22:52:01.61 4O36bTgr0.net
>>250
Bフレーム使ってないの?エンコ鯖一旦止めてでもBフレーム使うように設定する価値はあると思うよ

275:名無しさん@編集中
18/10/26 23:37:54.30 4O36bTgr0.net
Bフレームはあまり多くしてもダメで2~5を試したけど3が最適値っぽいな

276:名無しさん@編集中
18/10/26 23:41:30.18 p3F/gXTv0.net
そういやAMDって死んだんだっけ?

277:238
18/10/26 23:49:32.81 N4zrz6VR0.net
>>253-261
色々な情報を出していただき、ありがとうございます。
去年QSVスレで調べた時点でもNVEncのHEVCは結構良好な結果を出してましたし、
それを着実に改善していってるというのもすごいな・・・。
 スレリンク(avi板:335番)

278:名無しさん@編集中
18/10/27 00:03:15.28 ys8cVnL20.net
Nvidiaのフォーラムで見つけたTuringのNVEnc関連の話題
●Details about NVENC in Turing?
  URLリンク(devtalk.nvidia.com)
  ・RTX2080も2080Tiも、NVEncユニットを1つしか積んでないような気がする
   (2本並列エンコするとパフォーマンスが半分になる。GTX1080とかでは2つ積んでたのに。)
  ・デコードは速いけど、エンコードはGTX1070や1080よりかなり遅い
    ※ただ、テスト時のドライバが410.57とか410.66と書かれていて少し古いのが気になる。
      RTX2080に対応したのは411.63かららしいが・・・。
    ※テスト条件等もところどころ曖昧。
●Video Encode and Decode GPU Support Matrix
  URLリンク(devtalk.nvidia.com)
  Q.新しいSDKのリリースとかサポート一覧表の更新の予定は?
  A.「今の時点では数か月以内としか言えないっす。」

279:名無しさん@編集中
18/10/27 00:04:10.25 FTUp+p+x0.net
いよいよNVEncを本格的に使う時代がやってきたようだね

280:名無しさん@編集中
18/10/27 00:22:00.32 eOCStpwQ0.net
2070以上じゃないと使えないとかじゃなきゃ良いが

281:名無しさん@編集中
18/10/27 00:37:08.38 AkK5mm1N0.net
2030とかに搭載してたら買う

282:名無しさん@編集中
18/10/27 01:01:30.37 yLZZ6lTR0.net
>>264
少なくともウチの環境の1060 vs 2070だと、2070遅くないよ
h264は2070の方が速くて(vbrhqが330fps vs 400fpsくらい)、hevcは同じくらい(vbrhqが290fpsくらい)だった

283:名無しさん@編集中
18/10/27 01:03:10.45 yLZZ6lTR0.net
画像サイズはフルHDで

284:名無しさん@編集中
18/10/27 01:09:28.23 EhqLT3Ob0.net
>>267
10xxも併売するらしいから無理じゃない?
NVIDIAはNVENCを付加価値にしてるから
実売1万円以下のカードに乗ることは当分無さそう。
AMDに頑張ってほしい、
5千円で買ったx30,x40でNVENCが動くって今では無理だもんな

285:名無しさん@編集中
18/10/27 01:52:47.92 Q9KzXn1A0.net
Bフレ数は参照距離とかの兼ね合いで品質評価や圧縮効率にも影響するからエンコーダと設定値による
基本的に参照距離より大きくなると圧縮効率が下がるからBフレ増やす意義が下がる

286:名無しさん@編集中
18/10/27 03:14:07.17 eOCStpwQ0.net
参照距離は3以上は無意味だとH.264でも答えが出てたはず

287:名無しさん@編集中
18/10/27 03:37:58.82 yLZZ6lTR0.net
>>272
2070でHEVC main10で試したけど無意味だったわ
参照距離Bフレともに3が最適値かな。H264と同じっぽいね

288:名無しさん@編集中
18/10/27 14:22:44.59 5CDNEkUDM.net
で、実際にエンコードした動画の品質はどんな感じなの?
x264やx265といい勝負しているの?

289:名無しさん@編集中
18/10/27 14:34:17.18 loEY7bAF0.net
「いい感じだよ」とか「全然ダメだよ」とかレスが返ってきたときに、
その情報の真偽をお前はどうやって区別つけるの?

290:名無しさん@編集中
18/10/27 15:31:39.62 5CDNEkUDM.net
そういうのいらないから

291:名無しさん@編集中
18/10/27 16:49:16.70 d7Sa2MDK0.net
まぁレス番もつけずに比較出せって言われてもな
善意でエスパー反応しても後出しで証拠だせとか
追加であれやれこれやれっていうのが沸くだけだし
自分でやってみればっていわれるのが落ちだぞ

292:名無しさん@編集中
18/10/27 19:42:58.27 3i4fAC3IM.net
自分の感じたままに書くだけのことがそんなに怖いのか?
失敗することに恐怖を感じるタイプか?

293:名無しさん@編集中
18/10/27 20:10:01.30 loEY7bAF0.net
俺が怖いものは、「醜態を晒している自分に気づけていない人間」かな

294:名無しさん@編集中
18/10/27 20:13:24.22 3i4fAC3IM.net
気取ってんじゃねぇよ
ただの腰抜けだろ

295:名無しさん@編集中
18/10/27 23:44:27.63 yLZZ6lTR0.net
x264,x265,QSVと比較
URLリンク(i.imgur.com)
URLリンク(i.imgur.com)
映像の見た目は、HEVCとH264だとHEVCの方がノイズの隠し方はうまいから、
同じSSIMでもHEVCの方がきれいに見えるかな
あとはだいたい数値通り

296:名無しさん@編集中
18/10/28 00:40:17.81 gjMu3C/j0.net
なんでQSVはHEVCよりH264の方が高性能なん?

297:名無しさん@編集中
18/10/28 01:14:21.02 P2HtKYlC0.net
>>281
これサイズ比較も欲しい

298:名無しさん@編集中
18/10/28 01:24:13.21 42x5MzyR0.net
>>283
ビットレートが載ってるんだから必要ないと思うけど、何故に?
実写の方はrigaya氏のQSVBenchmarkに含まれてる2分53秒の動画で、
アニメOPの方は1分30秒くらいだろうから、ファイルサイズはそこから計算できると思うが。

299:名無しさん@編集中
18/10/28 01:35:24.69 GZzWkstI0.net
>>282
なんでって現状そういう実装になってるから、としか
まだ、QSVのHEVCエンコードは出たばかりだし、今後改善される可能性はあると思う
一応、このグラフで使ってるのはKaby Lakeで、QSVは最新世代のはず
Pascal世代のNVEncもHEVCの性能は相対的に低かったから、実写ではH264の方がSSIM高かったよ
(グラフには載せてないけど2070のH264は実写でもHEVCより少し低い)

300:名無しさん@編集中
18/10/28 02:46:35.85 mrO/Sdoo0.net
>>281

これはある意味、衝撃的な結果とも言えるね
アニメのほうから見ていくと、「x265 midium main10」と「2070 B=3 HEVC main10」が
ほぼ同じSSIMと言っていいレベルで第1位と第2位!
画質のみで判断する場合、「QSV」と「x264」は、アニメに関してはもはや不要と言いたいレベル!

301:名無しさん@編集中
18/10/28 02:46:51.15 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:名無しさん@編集中
18/10/28 11:08:35.72 ftI7zJ8S0.net
>>281
ありがたい
実写は何使ってもSSIM厳しいなー

304:名無しさん@編集中
18/10/28 12:17:03.84 QuPM3EHW0.net
そもそも画質がSSIMで語れるのかと

305:名無しさん@編集中
18/10/28 13:31:50.58 AIjwuTyg0.net
数値化された指標ってそれしかないんじゃないのかな
なら仕方ない話で
俺はそれはそれ話半分で聞いてる

306:名無しさん@編集中
18/10/28 13:53:36.53 AIjwuTyg0.net
痛みの単位HANAGEを思い出した

307:名無しさん@編集中
18/10/28 15:45:20.66 3GVWrMAV0.net
>>289
SSIMのみで画質のすべてを語れるわけではないけれど、重要な指標になりうることは確か
>>281のテストの場合、画質として差が出ると判断できるだけの数値の差が出ているところから見て
Turing世代のHEVCエンコーダーの実用性が高いと判断することはできる
あまり話題には出ないがNVEncの場合、H.264、H.265ともにLOSSLESSエンコードもできるようになっているので、
今後ノートPC用のTuring世代GPUが出た場合、ノートPCにキャプチャー機器を接続してLOSSLESSでキャプチャーし
編集などしたのちH.265に再エンコードして保存などということも楽々とできるようになるのだろう
CPUやメモリーに必要以上に金つぎ込むよりGPUに金つぎ込んだほうが得られるメリットが確実に高くなる

308:名無しさん@編集中
18/10/28 18:34:37.91 q1RCfS2y0.net
VMAFってどうなんだろ

309:名無しさん@編集中
18/10/28 19:43:45.84 dqPT1FY80.net
むしろ気になったのは改善度合いのわりにNvidiaのアピールとか情報開示が控えめな感じがするところ
HEVCのBフレーム対応はQSVが先にやっているとはいえ、充分Turingの売りになると思うんだけどな

310:名無しさん@編集中
18/10/28 20:32:21.34 3GVWrMAV0.net
>>293
Netflixあたりが使っているようだね
使う意味はあるかと
>>294
動画の品質を重視する層には確かにウリ文句にはなるだろうけど、そもそもNVIDIAは
PureVideoにしてもそうだが世代の違いで何がよくなったかとかそういう情報を細かく
発信しようとしない風潮があるので、伝統的に商売の仕方がヘタクソな会社だとは言える。
特にノート用のGeForceなんかだとMaxwell世代は厳密には3つの区分で見分けないといけないのに、
GTX 965Mなんか公式情報すらあやふやというとんでもない状態を放置したままだし
GTX 965MはMaxwell世代のモバイル用GPUには珍しく、HEVCやVP9の再生支援が搭載されているのに!
・NVIDIA VIDEO CODEC SDK
URLリンク(developer.nvidia.com)
(※GTX 965Mは「Maxwell (GM206)」に該当)

311:名無しさん@編集中
18/10/28 20:32:38.99 3GVWrMAV0.net
これはNVIDIAに限らず、Intelも同様の傾向があるけれど
(Intelの場合、新しい世代であっても再生支援を使って動画再生をするとカクカクした動きになることすら
あるからなおのこと始末が悪いが…)
この手の業界の連中は、と


312:もすれば「コミュ障か!」と突っ込みたくなる傾向が強いのが最大の弱点



313:名無しさん@編集中
18/10/29 04:39:38.65 AzT2hbUL0.net
> Codec: H.264/AVC
> ...
> Field Encoding no
これ何かと思ったら、H264のインタレサポートが無くなってたわ
NVEncCで--tffオプション指定するとエラーになった
> interlaced output is not supported for current setting.
インタレ保持エンコができなくなるとは・・・これも時代の流れか

314:名無しさん@編集中
18/10/29 08:38:43.00 01sVuNYh0.net
要するに、60pは対応するが60iは捨てられたのか
まあ面発光する表示デバイスしか無くなってるからな
有機ELはあるが
60iから60pへのip変換は出来るのかな?

315:名無しさん@編集中
18/10/29 08:52:53.42 sYHP33Ej0.net
>>294
nvidiaが詳細明示せずSDKやAPIで叩いて実際の挙動見ろ的なのは何時もの事なのでは?

316:名無しさん@編集中
18/10/29 09:57:06.91 dU/S2c/9a.net
きょーび動画がらみの機能は訴求力ない
ゲームのフレームレート至上主義や
出始めの頃はDCTだ動き補償だなんだと
並び立てて煙幕張ってたが
Rage128とかそんな頃w

317:名無しさん@編集中
18/10/29 11:20:58.69 5qgUaohH0.net
ゲームの中継ととかで需要はうなぎのぼりだよ

318:名無しさん@編集中
18/10/30 01:57:43.60 6swiaWs40.net
>>297
インターレースは非対応ですか
時代の流れと言えばそれまでですが、いささか早すぎるような気もするけれど
放送はこれから先も2K以下についてはインターレースのまま継続するのだし
ただ、インターレースが動画圧縮を行う上で非効率なことは間違いないし、
再生機器でのリアルタイムインターレース解除より、QTGMCなどであらかじめ
じっくり解除しておいたほうがきれいなことは間違いないわけで
※4Kテレビなどで2K放送などをアップコンバートして表示している映像を見ると、
インターレース解除がうまくできていないことによるジャギジャギ感が目につき
気になって仕方がない

319:名無しさん@編集中
18/10/30 01:57:58.08 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:名無しさん@編集中
18/10/30 05:04:17.92 Cr8xUI/50.net
キャプチャする対象をインタレと決めつけてるけど
ソースは何を想定してるのよ?

321:名無しさん@編集中
18/10/30 11:18:17.80 MqAHCJNS0.net
amatsukazeはts信号処理と言ってるから放送波なんじゃね

322:名無しさん@編集中
18/10/30 11:55:09.90 praWeO5TM.net
撮影ts化する人はいないだろうから、放送波だろうな

323:名無しさん@編集中
18/10/30 12:02:45.30 Cr8xUI/50.net
いやね、tsならファイル扱えば良い訳で
レス元のみたいなキャプチャー機器使う環境をあげてる人へのレスで、何処からインタレとかの発想出てきたのかと

324:名無しさん@編集中
18/10/30 12:20:10.29 ZgNtru3g0.net
DVDやBDのインタレソースにAmatsukazeのKTGMC使ってみてえな

325:名無しさん@編集中
18/10/30 14:37:23.21 VTxPizmd0.net
>>303
QTGMCなんて只のavisynthの関数だろ?
自分でスクリプト書いて使えばいいだけ。
それが出来ないレベルなのか。

326:名無しさん@編集中
18/10/30 14:43:27.09 wilPKf0o0.net
そういうの余所でやって

327:名無しさん@編集中
18/10/30 17:23:10.50 PLMRbtTq0.net
>>307
ロケフリ用途とか?

328:名無しさん@編集中
18/10/30 19:38:56.39 Cr8xUI/50.net
>>311
だからインタレのキャプチャなんぞDVDプレイヤーやD端子以前の旧世代の機器の出力とか、旧世代のインタレ表示機器向けの信号取り込もうとしない限り今じゃ無いでしょ
後者なら出力側をプログレにすりゃ良いのだから、わざわざインタレ出力にしてまで取り込む意味が無いし
インタレとも書いてない書き込みに付けるレスとしては謎すぎる

329:名無しさん@編集中
18/10/30 20:07:46.12 30eOo37X0.net
レコとかテレビ任せのインタレ解除よりQTGMCのほうが綺麗でしょ

330:名無しさん@編集中
18/10/30 20:12:09.90 30eOo37X0.net
QTGMC単体だと副作用多すぎなのでQTGMC+KFMか

331:名無しさん@編集中
18/10/30 20:30:20.23 jJrgI2Lj0.net
そういうの余所でやって

332:名無しさん@編集中
18/10/30 23:17:53.06 MqAHCJNS0.net
ほっとけばすぐ収まるんだからスルーしときなはれ

333:名無しさん@編集中
18/10/31 02:59:37.42 W4uaGaXp0.net
Apple T2 チップってのはどうなんだろ

334:名無しさん@編集中
18/10/31 03:03:56.44 HL+tE8NE0.net
なんだか勘違いしている人がいるようだな
ts化するというのはAmatsukazeがtsしか受け付けないからtsで保存と言っているわけなのだが…
個人的には大事な録画をサポートはおろか何の保証もないBonDriverを使ったts録画に任せる気には
ならないので、録画はレコーダーでしているけれど
(放送局側の都合で突然仕様が変更されて録画できなくなってもどうすることもできないし)
キャプチャーは主にアナログ時代に録画したものやD-VHSで録画したものを念頭に置いている
特にD-VHSからのキャプチャーはドロップアウトとの戦いもあるから念入りにしなければならないので
まぁ一人アレルギー反応示している人がいるからこの件はクローズにしておきましょ

335:名無しさん@編集中
18/10/31 12:14:43.06 vRp2peue0.net
>>318
>>(放送局側の都合で突然仕様が変更されて録画できなくなってもどうすることもできないし)
ISDB規格って知ってる?
もしPT3とかで録画出来なくなったら他の民生品レコーダーも全滅だよ。

336:名無しさん@編集中
18/10/31 12:46:16.61 Yt9WJetm0.net
スレ違い長文はスルーでok

337:名無しさん@編集中
18/11/03 01:55:10.07 uB0majyg0.net
NVEncのロスレスエンコードについて。
去年rigaya氏からは「ロスレスはYUV 4:4:4のみ」という回答をいただいており、
実際にNVEncCのhelpだと --lossless は「YUV444 only」になってるのですが、
以下でのやりとりを見ると、YUV 4:2:0でもできそうな気配が無きにしもあらず。
 URLリンク(devtalk.nvidia.com)
 URLリンク(devtalk.nvidia.com)
 URLリンク(devtalk.nvidia.com)
(続く)

338:名無しさん@編集中
18/11/03 01:57:27.24 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) ダブルクリック1発で、結果は  https://pastebin.com/AcNCu9V3 のような感じで記録されるので、PascalやTuringなどの環境をお持ちで 気が向いた方がいたら、試して結果を教えてもらえるとありがたいです。 (できればoutputフォルダをzipにしてAxfc等にアップロードしてもらえると  エラーが発生した場合の原因などもわかるので助かります) よろしくお願いいたします。



340:名無しさん@編集中
18/11/03 02:29:58.68 J40rNpwz0.net
>>322
URLリンク(www.axfc.net)

341:名無しさん@編集中
18/11/03 03:13:14.80 J40rNpwz0.net
ffmpegは全部対応してるけど、rigaya氏のNVEncCはh264のYUV444にしか対応してないようだね
HEVCやYUV420を使いたい場合はffmpeg使うしかないっぽい
h264のYUV444に比べてHEVCのYUV420はサイズが半分近くまで減るし

342:名無しさん@編集中
18/11/03 03:13:52.29 uB0majyg0.net
>>323
ありがとうございます。環境にあわせてテストしていただいたようで申し訳ない。
ログを確認させていただきましたが、Pascal(GTX 1060)、Turing(RTX 2070)ともに、
420/444、8/10bitの全パターンでちゃんと一致したフォーマットで可逆になってますね。
YUV4:2:0でもロスレスエンコードできると考えてよさそうです。
とりあえずrigayaさんのブログに情報としてお知らせしておこうと思います。
ご協力いただき、ありがとうございました。

343:名無しさん@編集中
18/11/03 03:37:43.12 uB0majyg0.net
>>324
一応NVEnc3.05でHEVCのロスレス出力に対応しているようです。
また、現在は--losslessが指定された時点でYUV 4:4:4出力にする実装になっているようなので、
HEVCのYUV 4:4:4ロスレス出力はできるのではないかと。
NVEncのマニュアルである
 URLリンク(github.com)
の --lossless の説明には「H.264のみ」とありますが、これは修正漏れのようで、helpでは
 --lossless  for lossless (YUV444 only) / default: off
となっています。

344:名無しさん@編集中
18/11/03 03:55:29.32 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:名無しさん@編集中
18/11/03 04:06:01.76 uB0majyg0.net
>>327
そうなると自分もちょっとわかりませんね・・・。
AviUtlから拡張NVEnc出力を使ってHEVCを選んで、readmeにあるように
 「CQPでIフレーム、Bフレーム、PフレームのQP値を0にする」
で出力するのを試してみるという手もありますが、同じ結果になる可能性が高そうな・・・。

346:名無しさん@編集中
18/11/03 07:35:14.62 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:名無しさん@編集中
18/11/03 17:06:40.04 3hZOcD7m0.net
>>303などでNVEncのLOSSLESSエンコードについて書いていた者だけど、俺より先にいろいろテストしてくれている人がいるようなので
とても助かります
今、気になっていることが二つあります
1.「AVerMedia Live Gamer Ultra」をレビュー。
高画質&高速プレイを妥協せず、手軽に快適な録画・配信環境を構築できるUSB外付け機器型ビデオキャプチャ
URLリンク(blog.livedoor.jp)
という記事の中で紹介されている
「上のようにGPUハードウェアエンコードとCPUによるソフトウェアエンコードの間に基本的には大きな差はありませんが、
NVENCについては特定の条件下でノイズが発生する可能性があるようです。」

348:名無しさん@編集中
18/11/03 17:07:10.59 3hZOcD7m0.net
・CPUエンコードの場合(問題なし)
URLリンク(livedoor.blogimg.jp)
・NVEncによるエンコードの場合(破綻している)
URLリンク(livedoor.blogimg.jp)
・動画での確認
URLリンク(www.youtube.com)
このノイズがLOSSLESSの場合でも発生するのかどうか?
2.上記の問題はRTX20*0(Turing)世代のGPUでも相変わらず発生するのか?
という点が気になっています
そもそもこの問題はハードウェア的にどうしようもない問題なのか、それともドライバーソフトなど含めたソフトウェアレベルで
改善出来うる問題なのか
果たして真相やいかに?

349:名無しさん@編集中
18/11/03 17:27:09.65 xQq3bNCe0.net
AVerMediaのAVT-C878を使ってる感じだとPS4-単体録画モードでもたまにコマ落ちしてるよ
あとそのサイトの話だと途中59.94FPS録画もあったり条件がそろってないから注意ね

350:名無しさん@編集中
18/11/03 18:48:20.13 oyWwovRq0.net
>>330-331
ノイズや破綻の発生と言っても、
 ・SW側の実装の問題(NVEncをどのような設定で呼び出しているのか等)
 ・HWや環境側の問題(電源不安定や突発的な負荷増加等)
 ・NVEncやドライバ側の問題
など、要因が多数あるわけで、「発生しない」なんて言い切ることは誰にもできないと思うよ。
 
 
あと、ぶっちゃけた話、ロスレスキャプチャにこだわらない方がいいと思う。
>>323のテスト結果を見ると、
  RTX2070/HEVC/yuv420pロスレス/640x360/29.970fps → ビットレート 39.4Mbps
になっている。1080p30に換算すると単純計算で9倍で354.6Mbpsになる。
「データ量が膨大になってもいいからロスレス(可逆)キャプチャしたい」という強いこだわりがあるなら別に止めないけど、
得られる画質は数分の1のビットレートで通常の非可逆キャプチャした場合と大差ないだろうし、
ロスレスだからといって編集時のデコード処理等が軽くなるわけでもないし、
最終的に保存エンコしたりYoutube等にアップロードすることを考えると、どうせその画質も保持できないわけだし。

351:名無しさん@編集中
18/11/03 20:29:04.08 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:名無しさん@編集中
18/11/03 20:32:09.61 J40rNpwz0.net
>>330-331
キャプチャボード付属のソフトでエンコードしてるから、
どっちかというとドライバやHWよりそのソフト側に問題がある可能性が高そう
NVEncや


353:ffmpegでも同じ現象が発生するなら別だけど、 そういう破綻は俺は見たことも聞いたこともないなぁ 4K60fpsYUV444でロスレスなんてやったら700MB/sくらいになるから、 SATAじゃ帯域足りなくて、M2でやっとって感じ。相当やばそうw



354:名無しさん@編集中
18/11/03 22:29:43.39 oycFKwRy0.net
>>331
そもそもスレ違い
AVerMediaのキャプチャデバイス使った問題なら
ちゃんとスレがあるだろ
スレリンク(avi板)

355:名無しさん@編集中
18/11/03 22:36:55.92 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:名無しさん@編集中
18/11/03 23:45:03.74 J40rNpwz0.net
>>337
HEVCは10bitも含めて全部できるようになってたわ!

357:名無しさん@編集中
18/11/04 00:00:00.96 eJsOmTbV0000000.net
お、よかった

358:名無しさん@編集中
18/11/04 00:16:02.97 eJsOmTbV0.net
[NVEnc 4.22v2] (※2018/11/3 23.37)
NVEnc 4.22でlosslessでないときもlosslessと表示されてしまっていたのを修正。

359:名無しさん@編集中
18/11/04 14:16:53.98 NW8jvxFN0.net
GTX1050でもHEVC H265エンコ快適に出来ますか?
世代格差によって画質も向上してるなら買い換えも検討します。

360:名無しさん@編集中
18/11/04 15:03:34.52 xAruxQ/q0.net
>>341
スレのログを読めばTuringでHEVCのBフレームに対応したのがわかるので、
画質を重視するならTuringへの買い替えを検討すればいいと思う。
もしかすると今後のSDKやドライバーの更新でPascal等にも
HEVCのBフレーム利用が開放される可能性もあるけど、まだ不明だし。
Turingは今のところNVENCコアが1つしか載ってないらしいという情報もあるので、
並列エンコを効率よく行いたいという要望があるなら
NVENCコアが複数載っているGTX1080なんかも候補にあがるだろうけど。
  URLリンク(developer.nvidia.com)

361:名無しさん@編集中
18/11/04 15:35:43.05 /7KW/feH0.net
>>297
>NVEncCで--tffオプション指定するとエラーになった
って事は--avhw --tff --vpp-deinterlace normal -i in.ts -o out.mp4
とかも駄目なの?

362:名無しさん@編集中
18/11/04 16:00:46.36 eZ7AM1Hz0.net
インタレ解除すれば大丈夫だよ

363:名無しさん@編集中
18/11/04 17:27:57.85 /7KW/feH0.net
>>344
インタレのままMP4には出来ないって事ね。
了解。

364:名無しさん@編集中
18/11/04 21:34:34.60 xzALgcB+0.net
RTX 2080 Ti の NVEncC64.exe --check-featuresの結果
  URLリンク(devtalk.nvidia.com)
  ・機能項目の内容はRTX2070と一致
  ・質問時に>>259の内容を引用させていただきました
その後の記述によると、
 ・Win10 + 2080Ti + ドライバ416.34(現時点最新) + ffmpeg4.0 → hevc_nvencでBフレーム指定(-bf)が効く
 ・Linux + 2080Ti + ドライバ410.73(現時点最新) + ffmpeg4.0 → hevc_nvencでBフレーム指定(-bf)するとエラー
となるらしい。

365:名無しさん@編集中
18/11/05 05:41:21.59 knaMJWHmd.net
上位モデルでのNVEnc2基搭載やめると、本来の目的であるクラウドでのGPU仮想化して描画を配信する手のサービスでの更新機器に当てられなくなるから大問題になるけども
1070やGP104搭載1060が、後からNVEncの2基目開放されたみたいに、物理的に実装されてりゃドライバでどうにでもなる

366:名無しさん@編集中
18/11/05 06:15:55.27 iJw5+rsZ0.net
クラウドでGeForceは�


367:gわれない。というかNVIDIAが禁止してる https://pc.watch.impress.co.jp/docs/news/1099481.html NVEnc1基しか載せない、あるいはドライバで1基しか使えないようにする というのはTeslaやQuadroと差別化するためのNVIDIAの戦略でしょ 最新のNVIDIAは結構えげつないことしてくるからね



368:名無しさん@編集中
18/11/05 06:33:26.33 Cf5VuBNo0.net
>>348
使えないのと載っていないというのは違うでしょ
「載っていない」と言ったらTU102や104に載っていないだし
「使えない」なら現状でコンシューマ向けでリリース済みで一般で入手可能なGEFORCE RTXで現状使えないという解釈になるでしょ

フォーラム関係の報告も正式対応じゃ無いドライバでで報告された情報から更新されて居ないまま拡散してるのも多い
何故かフライングで検証して報告できる奴が、その後の正規対応ドライバでの追加報告とかしていないままだったり
あとSupport Matrixのところは更新入るのが毎度遅い(多分Quadroが市場流通し始める前後あたりとか)

369:名無しさん@編集中
18/11/05 06:44:00.28 U3iUdNuT0.net
久しぶりに来たけど最近のハートエンコは画質上がったのねー

370:名無しさん@編集中
18/11/05 07:10:42.42 iJw5+rsZ0.net
>>349
載ってるかどうかは知らないけど、載せる必要もないし、載ってたとしても使えるようにする必要もないって話

371:名無しさん@編集中
18/11/05 13:32:43.08 8lLAHoSW0.net
何を言ってるんだコイツは?

372:名無しさん@編集中
18/11/05 14:57:34.41 EqjTAyqW0.net
>>347
> 1070やGP104搭載1060が、後からNVEncの2基目開放されたみたいに
GP104搭載1060は、8月時点のSupport Matrixでは2基とされてるけど、現在はひっそりと分離されて1基になってるね・・・。
 8月の一覧
 URLリンク(web.archive.org)
 現在の一覧
 URLリンク(web.archive.org)
 
 
1070の2基目って、後から解放されたの?

373:名無しさん@編集中
18/11/05 15:18:41.97 EqjTAyqW0.net
>>352
元は>>347へのレスなんだから、
  「そもそもクラウドでのGeForceの利用は禁止されてるんだから、
   クラウド用更新機器としての利用の都合を考える必要はなく、
   GeForceにNVEncを何基載せるか、何基有効にするかはNVIDIAのさじ加減次第。」
ってことだと思うよ。
現状のTuringでNVENcが1基しか載っていない、あるいは1基しか有効になっていないという根拠は
>>264とかにあるようにフォーラムでのユーザ報告のみで、NVIDIAの公式情報ではないから、
正確な情報は公式情報の更新を待つしかなさそうだけどね。
スペック発表の際にNVENC/DECの詳細情報も含めるとか、もっと素早く動いてくれればいいのにねえ。

374:名無しさん@編集中
18/11/05 15:41:59.20 mhaZf1JN0.net
>>353
ひどい話だ~ GigaByteのパッケージみてのGP104のGTX1060に期待してたのに・・・

375:名無しさん@編集中
18/11/05 16:09:58.18 nXlYzYqj0.net
>>355
昔は抵抗張替でdevice id書き換えられたんだが、今は無理みたいね。

376:名無しさん@編集中
18/11/05 16:54:57.40 mhaZf1JN0.net
選別落ちの眠ってるコアを有効にするのは楽しかったねぇ
8月時点のSupport Matrixの誤植ってだけかもしれないけどね
ゲームしないのに1070や2070はちょっと手が出ないです

377:名無しさん@編集中
18/11/05 17:14:13.82 ijee7cms0.net
NVENCの為に1060から2070にしようとしてる俺
しかし買えるのは12月かなぁ

378:名無しさん@編集中
18/11/05 17:48:43.55 nXlYzYqj0.net
>>358
俺も20シリーズ欲しいんだが
突然死問題があるからなあ
しばらくは様子見だな。

379:名無しさん@編集中
18/11/05 20:16:04.07 IYllvk


380:b8M.net



381:名無しさん@編集中
18/11/05 20:36:15.97 EqjTAyqW0.net
>>360
落ち着いて元レス(>>347-348)や解説(>>354)を読もうぜ。
> 載ってるかどうかは知らない
TuringにNVENCが複数基載ってるかどうかはNVIDIA公式の発表がないとわからないので当たり前。
> 載せる必要もない
「(GeForceはコンシューマ用であってクラウド用GPUの後継として考える必要はないので、
 "NVIDIAとしては"、新しいGeForceに複数基のNVENCを)載せる必要(義務)もないし、
 載ってたとしても使えるようにする必要(義務)もない」
という意味だと思うよ。
ユーザ目線としては載っててほしいと思うのは当たり前だけど、そういう話ではない。

382:名無しさん@編集中
18/11/05 20:52:41.84 EqjTAyqW0.net
rigaya氏の画質比較。
「RTX 2070のHEVC+Bフレーム」の結果も含めたx264/x265/QSV/NVEncの比較。
rigayaの日記兼メモ帳 画質比較 2018.11 (アニメ版)
URLリンク(rigaya34589.%62%6cog.fc2.com)
rigayaの日記兼メモ帳 画質比較 2018.11 (実写版)
URLリンク(rigaya34589.%62%6cog.fc2.com)

383:名無しさん@編集中
18/11/05 21:05:18.01 mhaZf1JN0.net
>>362
静止画でやっと差がわかるレベルの話だもんな
よほど速度とビットレート気にしなきゃ、好きなハードで好きな設定でっていういい時代がきたもんだ

384:名無しさん@編集中
18/11/05 22:02:01.00 f27k4QdJM.net
>>361
ばんなそかなw
おまえらエスパーだろw

385:名無しさん@編集中
18/11/05 22:34:02.92 0W+dXKSX0.net
>>362
実写のグラフが見れないのって俺だけ?
EdgeとVivaldiともにグラフが表示されない(adブロッカーは無効)

386:名無しさん@編集中
18/11/05 22:37:52.08 EqjTAyqW0.net
>>365
ソースにある画像のURL見に行っても404になるから、URL指定ミスっぽいかな?

387:名無しさん@編集中
18/11/05 23:06:27.34 nXlYzYqj0.net
chromeなら正常に見えてるよ?
しかしエンコードしかやらん人なのにRTX2070買ったんか
漢やなあ
まあ、CUDAでもつかえるからいいけど。

388:名無しさん@編集中
18/11/05 23:11:51.56 EqjTAyqW0.net
>>365 >>367
rigayaさんが対応してくれたので見れるようになりました。

389:名無しさん@編集中
18/11/05 23:44:29.44 0W+dXKSX0.net
rigaya様乙

390:名無しさん@編集中
18/11/08 03:09:05.23 2fZSnnvM0.net
>>362
QSVのH.264もHaswellより改善されてたのね
こりゃ比較する時に注意する必要があるな
H.265が悪いのは謎だが
AMDのVCEもRyzenGで世代新しくなったみたいだけど、
こっちは情報無いのかな

391:名無しさん@編集中
18/11/08 07:03:49.19 FdmsdeZf0.net
VCEって何のソフト使えばいい?
rigayaさんはもう更新予定無いみたいなこと言ってるし

392:名無しさん@編集中
18/11/08 07:52:16.90 2PebhbHyd.net
AMDの方が更新必要なほどの更新してないからな
古いバイナリそのまま使ってりゃいいだけでは?
でも、速度はQSV並で画質は2世代前のMaxwell世代搭載のNVEnc以下と良いところ無いから、QSVやNVEnc使えるならそっちの方が良いよ

393:名無しさん@編集中
18/11/08 08:00:08.90 FdmsdeZf0.net
>>372
そっか、ありがと

394:名無しさん@編集中
18/11/08 09:29:53.60 IPUvP01x0.net
>>372
VCEのリアルタイム2パスエンコードエンジンとはいったい何だったのか…

395:名無しさん@編集中
18/11/08 10:19:37.80 2PebhbHyd.net
>>374
そもそも2passは一度出したVBRの量子化成果を元に再度量子化係数設定してデータ効率向上させるものだけど
リアルタイムでやると再検討の元にする1度目の結果が短期的すぎて再計算する効果が薄くなる
レイテンシ的に許す限りのLookaheadと大差無いというか計算量的にも成果の効率的にもLookaheadでいいだろという


396:



397:名無しさん@編集中
18/11/08 11:51:35.76 BVtZBysRd.net
>>373
A's Video Converter知らんの?

398:名無しさん@編集中
18/11/08 12:37:39.10 LqXiJeWAd.net
主にアニメ、テレビ映画のエンコ目的ですが
Handbrake
A's Video Converter
Mediacoder
どれがお薦めでしょうか?
8年前くらいのMediacoder使ってたのですが
時代が変わってて全く分かりません

399:名無しさん@編集中
18/11/08 12:42:10.14 zXPHusOq0.net
aviutl

400:名無しさん@編集中
18/11/08 12:48:57.42 GE1X/tGD0.net
>>377
Amatsukaze

401:名無しさん@編集中
18/11/08 15:01:25.79 bqI5FaWX0.net
Amatsukaze + スマレン

402:名無しさん@編集中
18/11/08 15:53:46.28 hyBaQnJF0.net
amatsukazeでFFMPEGあたりの処理で止まって完走出来ないようなTSも、TMSRでCM抜いてスマレンで出力させたTS食わせ直せば大抵完走出来る
ロゴはチャンネル不明に複数登録しときゃいい

403:名無しさん@編集中
18/11/08 16:56:28.56 jrUEvY9i0.net
>>377
編集しないならffmpeg

404:名無しさん@編集中
18/11/08 17:13:21.85 HdTcBruC0.net
>>377
>>214

405:名無しさん@編集中
18/11/08 18:23:01.40 Jre7sfPJd.net
>>377
速度重視のHWエンコードならNVEncC

406:名無しさん@編集中
18/11/08 18:43:48.26 iEUTGqzhM.net
CPUとGPUを併用して速度と画質が両立する手法できないかなあ

407:名無しさん@編集中
18/11/08 18:53:34.56 wB94F1kCa.net
A's Video Converterは使い勝手がよい

408:名無しさん@編集中
18/11/08 18:58:35.34 IWlQOKfNM.net
oh

409:名無しさん@編集中
18/11/08 22:03:28.14 XPBHw5ub0.net
A'sは、なぜ QSVで LA-ICQ 使えないの?

410:名無しさん@編集中
18/11/08 22:10:22.69 7DctvHWbd.net
HWエンコーダでは画質はまだx264には敵わないようだからNVDecとCUDAのフィルタリングをHWに任せて、多コアCPUで並列処理って感じですかね?

411:名無しさん@編集中
18/11/08 23:18:45.76 wtyFlTPsM.net
>>362を読んだのか?

412:名無しさん@編集中
18/11/09 00:33:45.95 KEKoUShr0.net
AMDのVCEは画質が期待できず、NVidiaのはクソ高いとしたら、IntelのQSVしかない
なんてこった

>>389
> HWエンコーダでは画質はまだx264には敵わないようだから
ようやくそれが時代遅れになるのではと

413:名無しさん@編集中
18/11/09 01:48:09.31 zsv/wa0M0.net
むしろH265で問題ないならX264を使うメリットがなくなりつつある
CPUのマルチスレッド化にも遅れてる印象だし

414:名無しさん@編集中
18/11/09 05:02:49.15 8KUf80Rm0.net
Apple T2 chipのハードウェアエンコードがソフトウェアエンコードと画質の違いを感じないとあるな。速度は爆速だし、Mac mini買って確認したい
I wasn’t able to notice any quality differences between the videos encoded with x265 and the T2’s hardware acceleration.
URLリンク(marco.org)

415:名無しさん@編集中
18/11/09 11:55:17.66 j+vD8clG0.net
主観評価(実質あてににならない)なのかとかソースの解像度と内容にもよるし
特にビットレート高いほどエンコーダの差が出づらくなるから、そこら辺伏せられた評価はマジ当てにならんぞ
実写の屋外撮影でカメラ自体が位置移動しているような状態でFHDで3~4Mbpsとか4Kで15Mbps切りとかで言っているなら凄いかもだが

416:名無しさん@編集中
18/11/09 12:10:31.12 MP1kjoZW0.net
そんな映像どれも最悪じゃないかと

417:名無しさん@編集中
18/11/09 12:25:25.35 mdRLJfsKd.net
ぶっちゃけSSIM0.99と0.89だって実際の動画みても違いはわかりゃしないし

418:名無しさん@編集中
18/11/09 12:44:12.60 j+vD8clG0.net
そう言える奴なら、pascal世代のnvencでH264でも問題ないんだろうから
そもそも「T2ならHWエンコーダでも」とかならんわな
T2のエンコーダ持ち上げたいという贔屓目が先に立ってるんじゃねーの?

419:名無しさん@編集中
18/11/09 13:12:45.71 +eoF7JeM0.net
>>393
買って報告よろしく
Macでx265ソフトエンコードしたもの見てみたいから忘れずにね

420:名無しさん@編集中
18/11/09 20:19:04.49 QrSgcle10.net
>>397
その通りだと思う
300MbpsのUHDを150MbpsのH.264に圧縮するなら、
NVENCもffmpegも見た目の差が出ない
T2使うかどうか、とあまり無関係になる

421:名無しさん@編集中
18/11/09 21:54:03.83 TrtIWpvY0.net
>>396
> ぶっちゃけSSIM0.99と0.89だって実際の動画みても違いはわかりゃしないし
さすがにそれはちょっと・・・
 SSIM 0.99と0.89の違い: URLリンク(imgur.com)

422:名無しさん@編集中
18/11/09 22:12:15.02 gyFZGYAD0.net
最近はBSのソースが腐ってきてるからなあ。
過去の番組とビットレート違いすぎる。

423:名無しさん@編集中
18/11/09 22:48:13.74 pP/+RlNkd.net
>>400
それ静止画じゃん
動いてりゃって言ってんだろ

424:名無しさん@編集中
18/11/09 23:14:39.13 zIEOZrkW0.net
さすがにわかるでしょ
crf 30超えてるみたいだし、これで分からないなら
画質を語る資格はないと思う

425:名無しさん@編集中
18/11/09 23:53:25.65 rY/TuQQ+0.net
0.89とか絶対に許せないわ!

426:名無しさん@編集中
18/11/09 23:58:25.20 pjDFErQ+0.net
0.9は超えてないとパッと見で汚く見える

427:400
18/11/10 00:32:32.98 DVNRc0zn0.net
>>402
Axfcが死んでるようなので動画はやめといたんだけど、
往生際が悪すぎるんで、動画の方もアップしといたよ。
 URLリンク(www.mediafire.com)
静止画であれだけ差があれば、動画でも明らかにわかるってことは想像つくだろうに。

428:名無しさん@編集中
18/11/10 01:11:00.05 7hY72uZBM.net
ssim0.980は個人的に最低欲しい。
できれば0.985

429:名無しさん@編集中
18/11/10 01:44:17.82 DVNRc0zn0.net
NVIDIAの「NVENC/DEC一覧表」と「VIDEO CODEC SDK」のページにTuringに関する記述が追加された。
なお新SDKのリリース日はまだ未定とのこと。
 URLリンク(devtalk.nvidia.com)
 一覧表: URLリンク(developer.nvidia.com)
 SDK:  URLリンク(developer.nvidia.com)
一覧表によると、今のところTuringに載ってるNVENCは1基だけらしいけど、
 The video encoder in Turing GPUs has substantially improved quality and performance
 compared with Pascal. The overall encoding capacity of one NVENC in Turing is comparable to
 two NVENC’s in Pascal.
 TuringのエンコーダーはPascalよりも品質と性能を大幅に向上させたんや。
 TuringのNVENC1つは、PascalのNVENC2つ分の能力があるんやで。
とのこと。

430:名無しさん@編集中
18/11/10 02:10:12.94 ZbEwVURh0.net
高解像度時の処理速度低下が緩和されたし
Quadro以上は同時処理数無制限だしで、鯖用途考えても2基積む必要無くなった訳か
機械学習成果を元にした超解像の実装されたら尚更って感じかね

431:名無しさん@編集中
18/11/10 02:18:23.88 ZbEwVURh0.net
NVEncの占有サイズ相当増えたのかな
下手すると今後出るかもしれないTU107とかでオミットされそうで怖いな
地味にNVDecがH.265 (HEVC) 4:4:4の12bitまで対応しとるね
4:4:4でもlossress出来たら映像編修関係の職業ユーザ需要�


432:J拓できそう



433:名無しさん@編集中
18/11/10 02:47:57.36 MqNljwjW0.net
Pascalで4k60fps*2だったのがTuringで8k30fps*1になったってことけ?

434:名無しさん@編集中
18/11/10 03:20:00.20 ZbEwVURh0.net
8KはPascalでも処理出来る
書いて有るとおりTuringだと1基でも8KでPascal世代2基分(同等以上?)のパフォーマンス出せるって事だろうね
そうなるとFHDとかでの並行処理していない時の処理速度はリミッターで制限掛かってるか可能性有るな

435:名無しさん@編集中
18/11/10 03:40:58.38 DVNRc0zn0.net
>>410
> 地味にNVDecがH.265(HEVC) 4:4:4の12bitまで対応しとるね
> 4:4:4でもlossress出来たら映像編修関係の職業ユーザ需要開拓できそう
ちょっと前に検証したとおり4:4:4のロスレスエンコードもできるけど、今のNVEncはHEVC 10bit 4:4:4までだから
「NVEnc側もHEVC 12bit 4:4:4 ロスレスに対応すれば」という意味かな?
一般ユーザレベルだと10bitでも事足りるだろうけど、職業レベルだと12bitが求められることもあるか。
でもHEVCでNVDECを使ったとして、シークとか逆再生とかの操作で
他の素材向けフォーマット(ProRes等)より優位になれるんだろか。(詳しい編集事情は知らんけども)


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch