【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】
■ このスレッドは過去ログ倉庫に格納されています
>>172
それにはマクロブロックどうこうということまでは書かれてないから、
どっか別のとこでに詳細な説明でもされてたのかなと思って。
NVIDIA Turing Architecture In-Depth | NVIDIA Developer Blog
https://devblogs.nvidia.com/nvidia-turing-architecture-in-depth/
の記事でもそこまでは書かれてないし。 資料としてマクロブロックと明言しているものは確かに見当たらないね
ただ、H.264で15%、HEVCで25%もの改善を得るとの文面から考えると、H.264から強化された動き保障精度向上のための
マクロブロック(HEVCではCUとか言うのだったか?)の探索範囲の強化がキモであるわけだから、実質的にマクロブロック
関連の処理の改善がされているだろうことは容易に想像できる
もちろん、Bフレーム関連とかも手は入っているとは思われるが HEVCはBフレームサポートして改善したとかの方が説得力あると思うよ Bフレームなくても困ってないしなぁ
あるに越したことはないけど >>175
Bフレは所詮オプション
あんなものの改良で25%もの改善は無理だ
それにBフレに頼りすぎると画質低下の要因にもなるから、必要最小限の利用に留めることが肝心 >>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で同様の調査をしてくれる人がいるといいんだが。 >>177
そりゃ0と3を比較したらそうなるよ
NVENCはBフレ自体は既に対応しているのだから、改善したと発表するならば同じBフレ設定条件下でどれだけ変化するのかを比較しないと意味がない >>179
いや、25%の改善と言ってるのはHEVCでしょ。
NVENCのHEVCは現状Bフレーム未対応なんだから、対応すればビットレート25%削減もできそうだねってことを
QSVのH.264の例を出して書いただけ。
まあHEVCでBフレーム対応するとは限らないし、H.264も改善されてるんだから
Bフレーム以外の改善もあるだろうし、まだなんとも言えんけどね。 >>180
勘違いしていた
NVENCのHEVCは、Bフレに対応していなかったな
対応しているのはQSVのほうだな
とは言え、すでにBフレ対応済のH.264でも15%の改善をし、さらにHEVCでは25%の改善となると、
共通して改善できる部分はマクロブロック関連が1番大きいだろうことは疑いようがない
エンコーダの動作の7割方はマクロブロックがらみなのだから まあ細かいことはよくわかってないんだけど、俺としては>>169が元情報を明かしてくれるのを願うばかり。 現物を買った人がマクロブロックの探索モードに、パスカル以前にはなかった新しいモードが搭載されたか確認してくれるのが1番手っ取り早い方法かと
あと、もちろんBフレの対応可否
Bフレについては公式発表が何もなかった時点で期待しにくいけれど… 新しいモードが搭載されたかなんてどうやって確認するの?
オプションが増えたのなら現物なくてもSDKのドキュメントに書いてあるでしょ HEVCのブロック捜査処理を最適化すすめて高速化したら、副次的に細部確認すれば解る程度の画質も改善してたという程度だけだったPascalの時もMaxwellから強化されていても捜査モードの追加なんて無かったし
そもそもエンジン側の処理でQSVみたいにGPGPU処理にしていないからモード切り換え意義が無いんだが
モードの有無で確認出来ると思っている理由が知りたい >>185
その前に>>169の
> 今回もマクロブロック捜査部分が強化入っている
> 当該処理が重くなる、より高解像度での処理や、ブロックパターンの複雑なHEVCでより効果が大きいそうな
> 解像度による速度低下の緩和
> 複雑なマクロブロック配置の最適化で
という話がどこで聞いたものなのか教えてもらえると嬉しいのだが・・・。
探索モード云々は>>183のちょっと先走った想像にすぎないから、情報の無い段階で考えてもしょうがないと思うけど、
こっそりTuringのNVENCコアに追加された(あるいは従来も実装されてたけど使ってなかった)とかで
今後のSDKの更新で新たに利用可能になるという可能性も・・・、うん、まあ無さそうだけど。 >>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出ないと使えるようにならないし モードが追加されるにしても、新しいSDK出ないと分からないし、
そのままエンコードしてもBフレームは出力されないし、性能向上もあまりないんじゃ
現物あっても何も分からないね
>>183はなぜ現物があれば分かると思ったのだろうか・・・ >>187
> Turingに対応した新しいSDKがまだ出てないから
うん、それは理解してる。>>186で書いたのは「今後の(Turingに対応した)SDKの更新」ってこと。 アホな質問だと思うけど誰か答えてくれると嬉しい
動画のカット・字幕など付けて可逆圧縮のAVI出力したものを最終的に
NVEncCのHWエンコで高速にリサイズしたいんだけど、コーデックに対応してない?から現状無理
って認識であってる?他にうまいやり方あるんだろうか。 リサイズがしたいのか、NVENCでエンコードしたいのか、可逆圧縮にしたいのかって感じですな
読めるように書き出してあればリサイズはできる。NVENCはエンコーダーであってリサイズはAvitulとかそっちの仕事
リサイズして可逆圧縮で保存したいならNVENCは必要ないので、高速のCPUを買う
あとNVECNで吐き出すものは可逆圧縮じゃないきがする >>191
いや、>>190は可逆圧縮したAVIファイルをNVEncCで読み込んで
--vpp-resizeや--output-resを使ってリサイズ&エンコードしたいってことでしょ。
--losslessにしたいのかどうかは知らんけど。
>>190
その質問をするなら可逆圧縮に使ったコーデック名(必要ならその設定も)をちゃんと書くべきだと思うが・・・。
まあ一応答えるけど、AMVシリーズなら --avi で読み込めばよさそうだし、avs経由で--avs読みするという手もある。
UtVideoならffmpegで対応してるから、上の手法に加えて--avswでも読めると思う。
ただ、どんな編集ソフト使ってるのか知らないけど、そもそも可逆圧縮AVIを挟む意味あるの?
カットも字幕もAviUtlでやって、NVEnc.auoで出力すればいいだけのような・・・。 >>191
>>192
まず質問に答えてくれてありがとうございます。
まさに>>192が言ってくれている通り、あらかた編集を済ませたものを-vpp-resizeでリサイズ&エンコードできればなと。
使ってるコーデックはUtVideoの420でAviutlを使用しています。
最終的にvppで2kとか4kとかにリサイズしたくnvenccのhwエンコードの速度に惹かれた次第です
AVI出力も含めたトータルの時間で早くなるのかな?と
そんなのAviutlでsharpen-resizeでも使えばと言われそうですが
せっかくnvenccで出来るのであればと思ったのと、単純に新グラボのSDK?とか
技術的な進歩に対応してるんだから良いんじゃないか?と思った次第です。
他に策があるようなので少し勉強して試したいと思います、ありがとうございました。 >>193
>>192で書いたけど、UtVideo出力せずに、拡張NVEnc出力(NVEnc.auo)で
「フィルタ」タブの「リサイズ」を有効にしてエンコードすれば、それでいいのでは。
NVEncCの--vpp-resizeや--output-res指定と同等だし、
わざわざ可逆でサイズが巨大なファイルを中間出力する意味はないと思うよ。
2Kや4Kへのリサイズというのが拡大するということなら、そもそも拡大自体やめた方がいい気はするけど。 >>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にはあまりこだわっていないんです
動画編集をやってエンコードを調べていくほど「知りたい」
と思った次第であります、丁寧にお返事ありがとうございます。 >>195
いくらAviutlでNVEnc使うと遅いって言っても、UtVideoで可逆圧縮出力するよりは速いぞ
デコードが遅いと言うより、Aviutlの中をフレームが通るのが遅いってだけ
もう既にAviutl通してるんだったら、直接NVEnc(NVEnc.auo)で出力したほうが良いに決まってる >>196
なるほど勉強になりました、素直にNVEncでやろうと思います。 >1080pであげた物と2kや4kで上げてVP9でエンコされた物を目視で比較するとVP9のほうが綺麗
VP9の方が後発なんだから当たり前やん HWデコード支援も出てきてるし今後増えるんだろうけど
まだまだ扱いにくいわなぁ 先月あたりからyoutubeがhevcに対応してるような !!
マジで?
Appleの圧力?
こうなるとYouTube側にもしオリジナルが残っているならばダウンロードし直したくなるな…
ビットレートと画質次第だけど >>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の方が汚いことも普通にある。 >>201
> 先月あたりからyoutubeがhevcに対応してるような
「対応」ってどういう意味?
「HEVCでの投稿」ってことなら結構前から対応してたはずだし、
先月あたりから対応と言えばAV1のテスト配信くらいだと思うし、
配信にHEVCを使うなんて話は出てないと思うけど。 >>203
自分が比較したのは1080p,1440p,2160p
VP9で再エンコされるラインが1440p以上っぽい
再エンコがh264なのかVP9かで破綻具合が違った(特にエフェクトの激しい場面)
・1080p投稿→H.264/1080p再エンコと
・2K拡大投稿→VP9/1080p再エンコ
自分の見解としてはyoutubeのh264とVP9はコーデックが違うこともあり
ビットレートの配分具合とかそもそも割り当てられる総ビットレートが
違うんだろうな(あたりまえなんでしょうが)と学んだ次第です 私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。 >>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動画」なんて見せたら、失望されるかもしれないし。 趣味で撮りためたTVアニメや映画をH264で720*480程度にリサイズしてMediacoderでエンコしてたのですが
ハードが逝ってしまい、数年ぶりに環境再構築してます
CPUも劇的に早くなり、フォーマットやソフトを見直しているのですが下記条件をみたす
おすすめのソフトはなんでしょうか?
画面サイズは720*480程度で十分
H264より新しいフォーマット希望
複数ファイルを連続で処理したい(夜間とか)
実時間以下でエンコード終了したい
できればフリーソフトが良い
アドバイスお願いします >>210
CPUはi5-8400です、オンボードビデオですが
VGAはGT730という骨董品があまってます
付けたら遅くなりそうですはめてません
ram16G、osはssd240Gにwin10home載せて全然あまってます ffmpegでhevc_nvencをバッチとかシェルでぶん回せば? >>209
「AviUtlでバッチのやり方」「rigayaの日記兼メモ帳」をググって読んで、
これで面倒なって思えば、TMPGEncとか多少出費する 最近はAmatsukazeにソース投げて終わり
ツールもAviSynthのスクリプトもみんな含まれてる 同じHD630のKabyだけどなんかもっさりしてて
GT730の方が体感はよかった 当然Kelperな730
ゲーム一切やらないけどブラウザ描画や動画再生に支援使われて
2GB版のメモリ1GBくらい食ってる
逆にHD630がQSV専用になってしまってる gt730 よりも前に使ってた
10年前の9800gtのcudaの方が
エンコが早かったでござるorz >>217
速度は速いかもしれんがCUDAの画質は… 速度優先で画質捨ててた、とりあえずHW時代だもんねぇ・・・
NVENCも世代ごとによくなってるってリリースにある通り
詳しくはWikiかなにかにまとめてあったともうぐぐってくだちゃい(-_ゞゴシゴシ 10年近く前からmediacoderのcuda使ってたんですけど
今の主流のエンコはなんですか?
intelのqsvもすごいって聞きますが
gpuのnvencやvce、cpuパワーでソフトエンコなど皆さんどんな
ハードとソフト使ってるんでしょうか? >>218-219
最新世代のNVEncは、かなりよくなったんじゃなかったっけ?
まだ値段が高いけど >>223
そう、CUDAとNVENCじゃ全く違う GTX1060(6G)でH265エンコしまくりですわ。 RTX2070が7万だものなぁ
そこまでは出費したくないから2050か2030で・・・
スペック次第だけど gtx1060にはtiはないのですか?
tiは無印と何が違うのでしょうか? ・【ニュース・フラッシュ】玄人志向、実売で7万円を切るGeForce RTX 2070
https://pc.watch.impress.co.jp/docs/news/news_flash/1149634.html
「価格はオープンプライスで、税別店頭予想価格は63,980円前後の見込み。」 >>227
Tiと無印に違いがあるというより、「無印とTiの間に何か関連性がある」という発想自体が間違い
GTX1080と1080Tiのように、Tiが付いたら中身が全く別物になるパターンもある
法則性があるわけではないので、何が違っているのかは自分で一つ一つ把握するしかない 20シリーズの性能ベンチがほしいな
10シリーズとの比較で
ほぼ値段相応だとは思うけど >>229
今ならドスパラで64800ってのもあるけどな どれ?
ドスパラとか祖父とか税別表示だからぬか喜びしないように気をつけてる ハードの値段やらの話は自作板にスレが多数あるんだから、そっちでやったほうがいいと思うよ。 RTX2070はTU106だから、GP106のGTX1060と一緒でNVEncのエンジンが1基しかないと思う
Maxwell以降は上位のチップには2基積まれて、エンコ2本同時までは速度が落ちない(ただし3本以上同時エンコできるのはQuadroのミドル以上 数は1つでいいや
問題は性能で
Bフレーム使えるみたいだけどその他もどれくらい
性能が上がってるのか気になる
気になるけど買えない
2060待ち >>235
106じゃなかった、104だすまん;
処理速度自体の向上は「高解像度で速度低下しづらくなった」ってだけなんで4K以上でエンコしないと殆ど動作クロックなりの速度よ RTX 2080でも2070でもいいけど、
NVEncC.exe --check-features
で、H.265/HEVCの Max Bframes がどうなるか調べた人ってまだいないのかな? 479分 14GBあるAVを容量節約のためにNVENCでH.265の低ビットレートでエンコードしたが速くていいわ(汚い穴が綺麗に見えてしまうので低ビットレートで充分) >>239
新人のインタービューやワンパターンのやるだけ明るい部屋はいいけど、8時間BESTとかだと暗いシーン多くて暗部ひどくならね? リアルタイムエンコが目的だからBフレ対応はしないでしょ そもそも、H265の圧縮率向上の根幹はI/Pフレの圧縮率向上が大きいからな
だからNVEncのマクロブロック配置ロジックの強化されてもH264に効果が殆ど無くてH265の方に効果が出てる
元々がGPUのクラウド化で画面転送するためのエンジンを転用・下位モデルにも解放してるものだし
わざわざ面倒な方の性能向上するぐらい低レイテンシ保持が大事という 265のエンコご優れてるのは分かったのですが
動画再生時デコードにパワー要りますよね?
古いpc環境とか人にも見せたいとか、モバイルでも見たいなら
264の方がまだ使い勝手が良いですか? 画質音質にこだわるのもいいけど扱いやすさがないと消滅するよ
音質が悪いと叩かれ続けてもmp3が生き残る理由 >>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を使った方がいいと思うよ。 根掘り葉掘り他人様頼みで身銭切らずに聞いている癖に、証拠まで求めるぐらいなら手前で買えよ
稼働させてるエンコ鯖止めてまでする気は無い 争いは、同じレベルの者同士でしか発生しない!!のAA思い出したw > Codec: H.265/HEVC
> Max Bframes 5
Bフレーム来たね
> Codec: H.264/AVC
> ...
> Field Encoding no
代わりにH264のフィールドエンコーディングが無くなってる? 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 bフレーム対応でようやくハードウェアエンコードが市民権得られる時代になったかな? 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フレームで半分、その他で半分くらい >>250
Bフレーム使ってないの?エンコ鯖一旦止めてでもBフレーム使うように設定する価値はあると思うよ Bフレームはあまり多くしてもダメで2〜5を試したけど3が最適値っぽいな >>253-261
色々な情報を出していただき、ありがとうございます。
去年QSVスレで調べた時点でもNVEncのHEVCは結構良好な結果を出してましたし、
それを着実に改善していってるというのもすごいな・・・。
http://mevius.5ch.net/test/read.cgi/avi/1486130737/335 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.「今の時点では数か月以内としか言えないっす。」 いよいよNVEncを本格的に使う時代がやってきたようだね 2070以上じゃないと使えないとかじゃなきゃ良いが >>264
少なくともウチの環境の1060 vs 2070だと、2070遅くないよ
h264は2070の方が速くて(vbrhqが330fps vs 400fpsくらい)、hevcは同じくらい(vbrhqが290fpsくらい)だった >>267
10xxも併売するらしいから無理じゃない?
NVIDIAはNVENCを付加価値にしてるから
実売1万円以下のカードに乗ることは当分無さそう。
AMDに頑張ってほしい、
5千円で買ったx30,x40でNVENCが動くって今では無理だもんな Bフレ数は参照距離とかの兼ね合いで品質評価や圧縮効率にも影響するからエンコーダと設定値による
基本的に参照距離より大きくなると圧縮効率が下がるからBフレ増やす意義が下がる 参照距離は3以上は無意味だとH.264でも答えが出てたはず ■ このスレッドは過去ログ倉庫に格納されています