【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

114 ：名無しさん＠編集中 ：2018/08/26(日) 17:18:48.39 ID:BIBv3N7z0.net

>>113
指摘の弁解も理由も全部後出し
取り繕いばっかりじゃねーかよ

そんで、waifu2xの演算に精度不足というなのがTensorコアが機械学習用途に不適というこじつけなるか理由聞かせてくれよ

115 ：名無しさん＠編集中 ：2018/08/26(日) 17:29:49.46 ID:BIBv3N7z0.net

>>112
「可能性」とか言い出せばどっち前者だろうが後者だろうがイチャモン付けられるってか？

品質基準のVBRロジックなんだから、ビットレート指定時に品質基準での調整ロジックが動いて無く、ビットレート指定を無くした時にだけ稼働すなら、ビットレート指定時は品質基準のVBRじゃなくなるわな
nvidiaが品質基準VBRとして実装しているものすら疑いだしたら、何を基準で正否とするよの？

後者と判断するなら、その根拠を提示してくれよ

116 ：名無しさん＠編集中 ：2018/08/26(日) 18:05:10.01 ID:k5cd80q8M.net

ffmpegでのエンコードパラメータを極めるスレはどこ？

117 ：名無しさん＠編集中 ：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処理に変えてみるのももしかしたらアリではないか？

ってことでしょ。まあディープラーニングっつっても目的によって必要な精度は変わってくるんだろうから
そんな単純な話が成り立つかどうかは知らんけどね。

とりあえず落ち着いて、やりとりを最初から見直してみたほうがいいんじゃねえの。

118 ：名無しさん＠編集中 ：2018/08/26(日) 18:36:13.01 ID:m7n2BMFu0.net

まあwaifu2xについて、「処理をfp16にしたらまともな品質にならない」みたいな検証が既にされてるのであれば
淡々とその結果を示してあげればいいと思うけど、これ以上続けたいなら
そろそろ画像拡大スレに移ったほうがいいんじゃないかとは思う。

　【超解像】画像拡大ソフト総合スレ２【waifu2x】
　https://egg.5ch.net/test/read.cgi/software/1462848853/

119 ：名無しさん＠編集中 ：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のレートコントロールが働くって考えるのが
最もシンプルな理解だと思うから、そうじゃないときはちゃんと書いてくれないと分からないよ

120 ：名無しさん＠編集中 ：2018/08/26(日) 20:51:24.96 ID:m7n2BMFu0.net

細かいことはよくわかんねーけど、とりあえずNVIDIA Video Codec SDK 8.2.15 の
NVENC_VideoEncoder_API_ProgGuide.pdf の 「3.8.3 Rate control」の内容を貼っとくわ。

　https://pastebin.com/LuGCNXbY

121 ：名無しさん＠編集中 ：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
これだけ

122 ：名無しさん＠編集中 ：2018/08/27(月) 10:48:37.03 ID:KSUuDcZo0.net

紙芝居のためにご苦労さま

123 ：名無しさん＠編集中 ：2018/08/27(月) 11:34:45.47 ID:dyyUpjbe0.net

これが捨て台詞ってヤツか

124 ：名無しさん＠編集中 ：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
どーせアニメだろｗ

122 名無しさん＠編集中 (ﾜｯﾁｮｲWW ea84-/kQw) sage 2018/08/27(月) 10:48:37.03 ID:KSUuDcZo0
紙芝居のためにご苦労さま

この間46レスと50時間ｗ

125 ：名無しさん＠編集中 ：2018/09/02(日) 19:42:33.51 ID:DuBTtQDB0.net

　　　　 　 　
　　　　r　‐､　　　　　 　 　 　 　 　 　 　
　　　　| ○ | 　　　　　　　 r‐‐､　　　 　 良い子の諸君！
　　　_,;ﾄ - ｲ、　　　　　 ∧l☆│∧　 　
　（⌒`　　　 ⌒ヽ　　　/,､,,ﾄ.-ｲ/,､ l.　　 証拠を要求するネトヲタがいるが
　　|ヽ　 ~~⌒γ⌒）　r'⌒ ｀ｉ´　`⌒） 　 君がいくら証拠を開示しても
　│　ヽー―'^ー-'　（ ⌒γ⌒~~　/|　　そのネトヲタは絶対信じないぞ！
　│　　〉　　　 |│　　|｀ー^ｰ― r'　|　　おまけにそいつは自分側の証拠を出したことがない。
　│　/───|　|　　|/　| 　l　　ﾄ､ |　　
　|　 irｰ-､ ｰ　,}　|　　　 / 　　　　i 　 　 自分の信じたいものしか信じなくなったらおしまいだな！
　| /　　　｀X´　ヽ　　　/ 　 入　 ｜

126 ：名無しさん＠編集中 ：2018/09/09(日) 04:59:21.22 ID:apyEih63r.net

なにが正しいかなんてわからんよ
エンコードしないのが一番いい気がするわ

127 ：名無しさん＠編集中 ：2018/09/09(日) 10:55:29.43 ID:vbK7CwBM00909.net

マヌケの戯言

128 ：名無しさん＠編集中 ：2018/09/09(日) 10:57:32.83 ID:SWOzIg6M00909.net

たしかに
劣化させて喜ぶアホ

129 ：名無しさん＠編集中 ：2018/09/09(日) 13:57:41.51 ID:614xNICFM0909.net

劣化を感じるようなエンコードしかできないのは、ユーザーの能力不足による無理な設定によるところが大きい
いくら優秀なエンコーダーを用いたところで、フルHD動画を最大1Mbpsなんかに設定したら、どうやっても劣化は目につく
それに放送番組を再エンコードするのにノイズ除去すらもせずにエンコード直行など、愚かにもほどがある

130 ：名無しさん＠編集中 ：2018/09/09(日) 14:14:25.74 ID:eDINVlxYr0909.net

マヌケの戯言

131 ：名無しさん＠編集中 ：2018/09/11(火) 09:19:07.11 ID:nd7uezLA0.net

もうHDD買い足してソースをそのまま保存しとけよ
エンコードなんかしてたら人生損するよ

132 ：名無しさん＠編集中 ：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の録画後に自動処理で録画タスク毎に処理するのには向かない（やりようはいくらでもあるけど）のが難点

133 ：名無しさん＠編集中 ：2018/09/11(火) 10:55:40.29 ID:cvr00PSpa.net

録画後処理じゃなくて
定期的にファイルリストに対して
1本ずつ処理したらええだないかね

134 ：名無しさん＠編集中 ：2018/09/11(火) 16:32:00.96 ID:gbdYj/Dq0.net

>>115
組める人には問題ないけどね（自分もそうやっている
フォルダ監視して順次エンコさせる場合には、リスト取得や録画中のファイルか録画完了したファイルかの判断とか
録画管理ソフトで録画終了時に実行する様なバッチみたいに、コマンドラインのエンコード命令にに毛の生えたぐらいのと違って、自分で組まなきゃならん部分多いから多少はハードル高くはなる

実際に他のスレで同時エンコ数の制限有るから使いづらいみたいな事書き込んでた奴も見かけてるし

135 ：名無しさん＠編集中 ：2018/09/11(火) 16:34:04.00 ID:gbdYj/Dq0.net

ありゃ、リンクミス
>>133
>>115

136 ：名無しさん＠編集中 ：2018/09/11(火) 22:40:56.55 ID:UKWbxX7R0.net

Amatsukazeなら何の問題もない

137 ：名無しさん＠編集中 ：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/

138 ：名無しさん＠編集中 ：2018/09/15(土) 00:24:18.61 ID:6Guydu2D0.net

>>137
「また，エンコーダの圧縮アルゴリズムにも改良が入っており，Pascal世代と比較して，同じ画質ならH.264で15％，H.265なら25％も低ビットレート化できるようになった。
逆に言えば，同じビットレートならPascal世代のGPUを使うよりも高い画質を得られるということだ。」

おぉー！
これは期待しちゃうなぁ

139 ：名無しさん＠編集中 ：2018/09/15(土) 00:27:43.52 ID:fy+82PFP0.net

AMDって今何してるの？

動画ならAMDなんて時代もあったのに…

140 ：名無しさん＠編集中 ：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割増程度で充分対抗できるかも？

なんかすごいことになってきたな

141 ：名無しさん＠編集中 ：2018/09/15(土) 00:38:14.81 ID:cjvlLd9kr.net

>>139
CPU作ってるよ
ATiって言わない時点で知ってるんだろマヌケ

142 ：名無しさん＠編集中 ：2018/09/15(土) 00:46:15.23 ID:vV+sK+U50.net

Poralisでリアルタイム2パスエンコードエンジン採用してディティールが残るとか言ってたのは結局どうだったの？
https://www.4gamer.net/games/329/G032949/20160629072/

143 ：名無しさん＠編集中 ：2018/09/15(土) 00:46:40.52 ID:rREhMZBO0.net

文脈読むならNVIDIAやインテルにGPUエンコでぼろ負けだけどGPUでエンコやる気ないの？だろ

どう見てもなさそうだねw
費用対効果で割りに合わないと思ってそう

144 ：名無しさん＠編集中 ：2018/09/15(土) 01:04:36.37 ID:rLzU4Nl20.net

>>140
6Mbpsか・・
2Mbpsとかでも馬脚を出さなかったら凄いけど
どうなんだろ

145 ：名無しさん＠編集中 ：2018/09/15(土) 01:08:09.38 ID:6Guydu2D0.net

>>144
2MbpsはHEVCでもキツいだろ
解像度かフレームレート落とせば収まるだろうけど

146 ：名無しさん＠編集中 ：2018/09/15(土) 01:09:41.00 ID:cjvlLd9kr.net

>>131
それな

147 ：名無しさん＠編集中 ：2018/09/15(土) 01:46:55.02 ID:7QW1sL+Z0.net

>>139
動画再生なら今もAMDだがな

148 ：名無しさん＠編集中 ：2018/09/15(土) 10:34:47.56 ID:EB9ltRQx0.net

>>138
6万弱になってる1080無印でも新しく載せようかと思ってたが
2070待ってた方がいいのかな。

149 ：名無しさん＠編集中 ：2018/09/15(土) 13:09:31.74 ID:Z9qm6hFN0.net

AMDのGPUは二度と手を出さない
過去にいい思い出がないから

150 ：名無しさん＠編集中 ：2018/09/15(土) 13:27:48.90 ID:q5uhmf3xM.net

>>148
待てるなら待ったほうがいい
それと、2070と2080以上ではいろいろ違いがあるから、可能ならば2080もしくは2080Tiを狙ったほうが後々後悔しなくて済む

151 ：名無しさん＠編集中 ：2018/09/15(土) 13:40:22.01 ID:vV+sK+U50.net

>>150
NVLINK以外に何が違うのけ？

152 ：名無しさん＠編集中 ：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は省略されているものがあるのではないかと噂があるのは確か

153 ：名無しさん＠編集中 ：2018/09/15(土) 15:08:21.91 ID:vV+sK+U50.net

>>152
そのページ古くね？
2070は1080超えてると思うぞ？

154 ：名無しさん＠編集中 ：2018/09/15(土) 17:37:16.95 ID:kNeKe3/D0.net

今は買うな時期が悪い7nmまで待て
今は買うな時期が悪いHBM2搭載まで待て

とりあえずこれで東京オリンピックまではいける

155 ：名無しさん＠編集中 ：2018/09/15(土) 18:05:15.54 ID:J9FwwRkQ0.net

>>147
> 動画再生なら今もAMDだがな

動画再生におけるAMD GPU
　　→メリット
　　　　　・Fluid Motionがある。
　　→デメリット
　　　　　・VP9のDXVAに対応しているのが今のところRavenRidgeのみ。

他に何かあるっけ？

156 ：名無しさん＠編集中 ：2018/09/16(日) 02:11:11.67 ID:PMq8EgC10.net

2050Tiはまだか

157 ：名無しさん＠編集中 ：2018/09/16(日) 12:06:58.48 ID:BkKFxbPh0.net

2060狙いだわ俺

158 ：名無しさん＠編集中 ：2018/09/16(日) 14:23:06.56 ID:sg7wXxWi0.net

2020 TOKYO Olympicモデルは出ますか?

159 ：名無しさん＠編集中 ：2018/09/16(日) 17:38:32.95 ID:UIqfW6niM.net

>>158
オリンピックで頭の中がいっぱいの蜃気楼ことミスターサマータイムにでもお願いしたら？

160 ：名無しさん＠編集中 ：2018/09/19(水) 03:43:00.21 ID:xo7/0Jwt0.net

2030までじっと待つよ

161 ：名無しさん＠編集中 ：2018/09/20(木) 04:45:35.71 ID:wD9/jjC60.net

コピペ


836 名前：Socket774[sage] 投稿日：2018/09/17(月) 08:45:38.58 ID:qUO+QI5X0 (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めちゃめちゃ遅いですね。ヤフオクで売ってきます

162 ：名無しさん＠編集中 ：2018/09/20(木) 07:24:20.06 ID:vSkJq7A40.net

今度は2070あたりで試しそうw

163 ：名無しさん＠編集中 ：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デコードと大して変わらないかな？

164 ：名無しさん＠編集中 ：2018/09/20(木) 16:50:31.73 ID:ZsqadvCjd.net

>>163
これ、CUDA数とか全く関係ないNVENC能力だけのエンコ結果なの？

165 ：名無しさん＠編集中 ：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→　http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3508.jpg
　　・NVENC→ http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3509.jpg
　　※Video_Codec_SDK_8.2.15より。

>>161(>>163)で仮にSWデコードがボトルネックになってるとすると、
HWデコードにすればPascalはもう少し伸びる可能性はあるかも。

166 ：名無しさん＠編集中 ：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

167 ：名無しさん＠編集中 ：2018/09/20(木) 19:31:19.63 ID:BCCdw+boM.net

2080出たけどnvencは速くなる？クロックが2000MHz近いし消費電力がすごいから電源も必要だけど

168 ：名無しさん＠編集中 ：2018/09/20(木) 20:00:35.48 ID:F9/vH15Ea.net

ゴミネオ注意報

169 ：名無しさん＠編集中 ：2018/09/20(木) 22:44:29.64 ID:2H1c86eW0.net

今回もマクロブロック捜査部分が強化入っている
当該処理が重くなる、より高解像度での処理や、ブロックパターンの複雑なHEVCでより効果が大きいそうな

解像度による速度低下の緩和
複雑なマクロブロック配置の最適化でH264で1割強、HEVCで2割強の画質容量比の改善とからしい

170 ：名無しさん＠編集中 ：2018/09/20(木) 22:56:50.16 ID:F9/vH15Ea.net

西川レジェンド善司氏のレポート待ちですな

171 ：名無しさん＠編集中 ：2018/09/20(木) 23:51:49.65 ID:YsH+9uCm0.net

>>169
どこの情報？

172 ：名無しさん＠編集中 ：2018/09/21(金) 00:03:13.17 ID:5ndzxww90.net

>>137-138を読んでないのか

173 ：名無しさん＠編集中 ：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/

の記事でもそこまでは書かれてないし。

174 ：名無しさん＠編集中 ：2018/09/21(金) 01:41:09.43 ID:5ndzxww90.net

資料としてマクロブロックと明言しているものは確かに見当たらないね
ただ、H.264で15%、HEVCで25%もの改善を得るとの文面から考えると、H.264から強化された動き保障精度向上のための
マクロブロック（HEVCではCUとか言うのだったか？）の探索範囲の強化がキモであるわけだから、実質的にマクロブロック
関連の処理の改善がされているだろうことは容易に想像できる
もちろん、Bフレーム関連とかも手は入っているとは思われるが

175 ：名無しさん＠編集中 ：2018/09/21(金) 05:59:20.60 ID:GcHtw70R0.net

HEVCはBフレームサポートして改善したとかの方が説得力あると思うよ

176 ：名無しさん＠編集中 ：2018/09/21(金) 09:36:29.68 ID:U1pwa+rf0.net

Bフレームなくても困ってないしなぁ
あるに越したことはないけど

177 ：名無しさん＠編集中 ：2018/09/21(金) 12:44:58.95 ID:7HD3xzwNa.net

>>175
Bフレは所詮オプション
あんなものの改良で25％もの改善は無理だ
それにBフレに頼りすぎると画質低下の要因にもなるから、必要最小限の利用に留めることが肝心

178 ：名無しさん＠編集中 ：2018/09/21(金) 15:26:42.06 ID:lKRfOAqF0.net

>>177
>>75と>>78のQSV H.264の例で
　　Ａ： --brframes 0
　　Ｂ：--brframes 3 --b-pyramid
を比較すると

　　Ａ：3000kbps→Ｂ：2100kbps ＝ 30%のビットレート削減　（SSIM＝0.988ライン)

　　Ａ：36000kbps→Ｂ：30000kbps ＝ 17%のビットレート削減 （SSIM=0.92ライン）

になってるけどな。

NVENCのH.264で同様の調査をしてくれる人がいるといいんだが。

179 ：名無しさん＠編集中 ：2018/09/21(金) 15:46:40.15 ID:7HD3xzwNa.net

>>177
そりゃ0と3を比較したらそうなるよ
NVENCはBフレ自体は既に対応しているのだから、改善したと発表するならば同じBフレ設定条件下でどれだけ変化するのかを比較しないと意味がない

180 ：名無しさん＠編集中 ：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フレーム以外の改善もあるだろうし、まだなんとも言えんけどね。

181 ：名無しさん＠編集中 ：2018/09/21(金) 16:31:03.94 ID:7HD3xzwNa.net

>>180
勘違いしていた
NVENCのHEVCは、Bフレに対応していなかったな
対応しているのはQSVのほうだな
とは言え、すでにBフレ対応済のH.264でも15％の改善をし、さらにHEVCでは25％の改善となると、
共通して改善できる部分はマクロブロック関連が1番大きいだろうことは疑いようがない
エンコーダの動作の7割方はマクロブロックがらみなのだから

182 ：名無しさん＠編集中 ：2018/09/21(金) 16:36:14.83 ID:lKRfOAqF0.net

まあ細かいことはよくわかってないんだけど、俺としては>>169が元情報を明かしてくれるのを願うばかり。

183 ：名無しさん＠編集中 ：2018/09/21(金) 16:50:38.73 ID:7HD3xzwNa.net

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

184 ：名無しさん＠編集中 ：2018/09/21(金) 23:19:25.16 ID:GcHtw70R0.net

新しいモードが搭載されたかなんてどうやって確認するの？
オプションが増えたのなら現物なくてもSDKのドキュメントに書いてあるでしょ

185 ：名無しさん＠編集中 ：2018/09/23(日) 02:42:30.46 ID:j3oG3i0p0.net

HEVCのブロック捜査処理を最適化すすめて高速化したら、副次的に細部確認すれば解る程度の画質も改善してたという程度だけだったPascalの時もMaxwellから強化されていても捜査モードの追加なんて無かったし

そもそもエンジン側の処理でQSVみたいにGPGPU処理にしていないからモード切り換え意義が無いんだが
モードの有無で確認出来ると思っている理由が知りたい

186 ：名無しさん＠編集中 ：2018/09/23(日) 03:29:43.62 ID:bRzvZQZ60.net

>>185
その前に>>169の

　> 今回もマクロブロック捜査部分が強化入っている
　> 当該処理が重くなる、より高解像度での処理や、ブロックパターンの複雑なHEVCでより効果が大きいそうな
　> 解像度による速度低下の緩和
　> 複雑なマクロブロック配置の最適化で

という話がどこで聞いたものなのか教えてもらえると嬉しいのだが・・・。

探索モード云々は>>183のちょっと先走った想像にすぎないから、情報の無い段階で考えてもしょうがないと思うけど、
こっそりTuringのNVENCコアに追加された（あるいは従来も実装されてたけど使ってなかった）とかで
今後のSDKの更新で新たに利用可能になるという可能性も・・・、うん、まあ無さそうだけど。

187 ：名無しさん＠編集中 ：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出ないと使えるようにならないし

188 ：名無しさん＠編集中 ：2018/09/23(日) 04:01:14.05 ID:HyLnLbY70.net

モードが追加されるにしても、新しいSDK出ないと分からないし、
そのままエンコードしてもBフレームは出力されないし、性能向上もあまりないんじゃ
現物あっても何も分からないね

>>183はなぜ現物があれば分かると思ったのだろうか・・・

189 ：名無しさん＠編集中 ：2018/09/23(日) 04:02:53.30 ID:bRzvZQZ60.net

>>187
> Turingに対応した新しいSDKがまだ出てないから

うん、それは理解してる。>>186で書いたのは「今後の（Turingに対応した）SDKの更新」ってこと。

190 ：名無しさん＠編集中 ：2018/10/14(日) 02:00:33.76 ID:kbRq5SJT0.net

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

191 ：名無しさん＠編集中 ：2018/10/14(日) 02:48:45.54 ID:Lnrlmmek0.net

リサイズがしたいのか、NVENCでエンコードしたいのか、可逆圧縮にしたいのかって感じですな
読めるように書き出してあればリサイズはできる。NVENCはエンコーダーであってリサイズはAvitulとかそっちの仕事
リサイズして可逆圧縮で保存したいならNVENCは必要ないので、高速のCPUを買う
あとNVECNで吐き出すものは可逆圧縮じゃないきがする

192 ：名無しさん＠編集中 ：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で出力すればいいだけのような・・・。

193 ：名無しさん＠編集中 ：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？とか
技術的な進歩に対応してるんだから良いんじゃないか？と思った次第です。

他に策があるようなので少し勉強して試したいと思います、ありがとうございました。

194 ：名無しさん＠編集中 ：2018/10/14(日) 18:24:58.71 ID:ZlTDkV240.net

>>193
>>192で書いたけど、UtVideo出力せずに、拡張NVEnc出力（NVEnc.auo）で
「フィルタ」タブの「リサイズ」を有効にしてエンコードすれば、それでいいのでは。
NVEncCの--vpp-resizeや--output-res指定と同等だし、
わざわざ可逆でサイズが巨大なファイルを中間出力する意味はないと思うよ。

2Kや4Kへのリサイズというのが拡大するということなら、そもそも拡大自体やめた方がいい気はするけど。

195 ：名無しさん＠編集中 ：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にはあまりこだわっていないんです
動画編集をやってエンコードを調べていくほど「知りたい」
と思った次第であります、丁寧にお返事ありがとうございます。

196 ：名無しさん＠編集中 ：2018/10/14(日) 22:00:48.85 ID:ur+KzSlL0.net

>>195
いくらAviutlでNVEnc使うと遅いって言っても、UtVideoで可逆圧縮出力するよりは速いぞ
デコードが遅いと言うより、Aviutlの中をフレームが通るのが遅いってだけ
もう既にAviutl通してるんだったら、直接NVEnc（NVEnc.auo）で出力したほうが良いに決まってる

197 ：名無しさん＠編集中 ：2018/10/14(日) 23:56:22.28 ID:kbRq5SJT0.net

>>196
なるほど勉強になりました、素直にNVEncでやろうと思います。

198 ：名無しさん＠編集中 ：2018/10/15(月) 00:17:08.43 ID:25ikQSo00.net

こういうＣＰＵで、ソフトエンコすればいい。
https://i.imgur.com/TrqBnGs.jpg

199 ：名無しさん＠編集中 ：2018/10/16(火) 04:48:50.77 ID:MU8B31bq0.net

>1080pであげた物と2kや4kで上げてVP9でエンコされた物を目視で比較するとVP9のほうが綺麗

VP9の方が後発なんだから当たり前やん

200 ：名無しさん＠編集中 ：2018/10/16(火) 07:59:53.94 ID:we4ARETc0.net

HWデコード支援も出てきてるし今後増えるんだろうけど
まだまだ扱いにくいわなぁ

201 ：名無しさん＠編集中 ：2018/10/16(火) 08:47:21.11 ID:FHIjlP1LM.net

先月あたりからyoutubeがhevcに対応してるような

202 ：名無しさん＠編集中 ：2018/10/16(火) 16:11:12.15 ID:Tzq1uDqUa.net

!!
マジで？
Appleの圧力？

こうなるとYouTube側にもしオリジナルが残っているならばダウンロードし直したくなるな…
ビットレートと画質次第だけど

203 ：名無しさん＠編集中 ：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の方が汚いことも普通にある。

204 ：名無しさん＠編集中 ：2018/10/16(火) 17:01:06.97 ID:5Qu0m5+G0.net

>>201
> 先月あたりからyoutubeがhevcに対応してるような

「対応」ってどういう意味？
「HEVCでの投稿」ってことなら結構前から対応してたはずだし、
先月あたりから対応と言えばAV1のテスト配信くらいだと思うし、
配信にHEVCを使うなんて話は出てないと思うけど。

205 ：名無しさん＠編集中 ：2018/10/16(火) 20:25:50.76 ID:/AsRmAMe0.net

WebMの立場は・・・

206 ：名無しさん＠編集中 ：2018/10/17(水) 01:49:06.98 ID:p2fT1tI10.net

>>203
自分が比較したのは1080p,1440p,2160p
VP9で再エンコされるラインが1440p以上っぽい

再エンコがh264なのかVP9かで破綻具合が違った（特にエフェクトの激しい場面）
・1080p投稿→H.264/1080p再エンコと
・2K拡大投稿→VP9/1080p再エンコ

自分の見解としてはyoutubeのh264とVP9はコーデックが違うこともあり
ビットレートの配分具合とかそもそも割り当てられる総ビットレートが
違うんだろうな(あたりまえなんでしょうが)と学んだ次第です

207 ：名無しさん＠編集中 ：2018/10/17(水) 02:26:19.20 ID:VTrg57yl0.net

　私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。

208 ：名無しさん＠編集中 ：2018/10/17(水) 23:36:15.65 ID: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動画」なんて見せたら、失望されるかもしれないし。

209 ：名無しさん＠編集中 ：2018/10/22(月) 13:52:41.31 ID:LE74PYGnd.net

趣味で撮りためたTVアニメや映画をH264で720*480程度にリサイズしてMediacoderでエンコしてたのですが
ハードが逝ってしまい、数年ぶりに環境再構築してます
CPUも劇的に早くなり、フォーマットやソフトを見直しているのですが下記条件をみたす
おすすめのソフトはなんでしょうか？

画面サイズは720*480程度で十分
H264より新しいフォーマット希望
複数ファイルを連続で処理したい（夜間とか）
実時間以下でエンコード終了したい
できればフリーソフトが良い

アドバイスお願いします

210 ：名無しさん＠編集中 ：2018/10/22(月) 14:15:01.48 ID:W/a+WlvB0.net

PCスペックは？

211 ：名無しさん＠編集中 ：2018/10/22(月) 14:18:57.41 ID:LE74PYGnd.net

>>210
CPUはi5-8400です、オンボードビデオですが
VGAはGT730という骨董品があまってます
付けたら遅くなりそうですはめてません
ram16G、osはssd240Gにwin10home載せて全然あまってます

212 ：名無しさん＠編集中 ：2018/10/22(月) 14:20:47.43 ID:dV3GbeQ00.net

ffmpegでhevc_nvencをバッチとかシェルでぶん回せば？

213 ：名無しさん＠編集中 ：2018/10/22(月) 17:00:14.78 ID:rhRUIsoy0.net

>>209
「AviUtlでバッチのやり方」「rigayaの日記兼メモ帳」をググって読んで、
これで面倒なって思えば、TMPGEncとか多少出費する