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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 4381-Xflc) · 2018/08/08(水) 04:44:09.82

ソフトウェアエンコーダーに画質は劣るものの、エンコード完了までの処理速度が爆速なハードウェアエンコーダーを語りましょう

●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

**名無しさん＠編集中** (ｽﾌﾟｯｯ Sdea-k1/v) · 2018/08/25(土) 10:37:27.22

圧縮効率が何で画質の悪さと関係あるんだよ
映像見て語れよ

**名無しさん＠編集中** (ﾜｯﾁｮｲ b9ec-PcWx) · 2018/08/25(土) 11:10:16.68

>>76
面倒くさい奴だな・・・。
一応crowd_runでも調べてやったけど、Bフレ無しだと圧縮効率が下がることに変わりはないぞ。

　QSV-H.264-LAICQ_Bフレーム有無の差_crowd_run
　http://2sen.dip.jp/cgi-bin/upgun/up2/source/up3502.jpg
　ソース： https://media.xiph.org/video/derf/

>>77
もしかして圧縮効率を考えずに「画質が悪い」とか言ってるのか・・・？
「Bフレありの1Mbps」と「Bフレ無しの5Mbps」みたいに
ビットレートが異なるファイルを比べて「Bフレ無しの方が綺麗」とか言ってるんじゃないだろうな・・・。
それとも「Bフレーム有効にするといくらビットレートを上げても糞汚いHWエンコーダがある」とでも言いたいのか？

>>75での疑問にも何も答えてないし、何が言いたいのかよくわからん。

**名無しさん＠編集中** (ｽﾌﾟｯｯ Sdea-k1/v) · 2018/08/25(土) 12:19:30.24

何で同じビットレートで比べないの？アホなの？

**名無しさん＠編集中** (ﾜｯﾁｮｲ b9ec-PcWx) · 2018/08/25(土) 12:54:51.04

>>79
最低限の情報も出さず、まともな説明もしないお前の方がアホだと思うが・・・。

もしかしてグラフの意味を理解できてないのか？
同じビットレートで比較したいなら、同一ビットレートでのSSIMの値を見て比較すればいいだけなんだが。

SSIMでの客観評価じゃなく、同一ビットレートでの主観評価をしろってことなら、俺はそこまでやる気はないんで
「Bフレ有効だと画質が悪い」と主張するお前がテストして、その結果を示せばいいと思うけど。

それ以前に

　　・どのようなソースを
　　・どのHWエンコーダの
　　・どのコーデックで
　　・どのような条件でどのように評価した結果、Bフレありだと画質が悪いと主張しているのか

をちゃんと書いたほうがいいと思うけどね。そういった情報も無しにただ喚かれても、話にならんだろ。

**名無しさん＠編集中** (ｽﾌﾟｯｯ Sdea-k1/v) · 2018/08/25(土) 13:04:32.35

やる気ないってwww
エンコしてるならその映像見てグラフと一緒に示せば完全論破でドヤ顔出来るのに、しないのが証拠だろ？

**名無しさん＠編集中** (ｱｳｰｲﾓ MMa1-0Goq) · 2018/08/25(土) 13:40:40.56

頭悪…

**名無しさん＠編集中** (ﾜｯﾁｮｲ b9ec-PcWx) · 2018/08/25(土) 13:54:05.89

最低限の情報すら頑なに出さないアホの探偵ごっこか・・・。
目の前にある事実を無視して、わざわざ遠くにある迷宮に入りにいって帰ってこないタイプなんだろうな・・・。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/25(土) 14:10:51.00

いや、単純にSSIMやグラフの見方が分からないだけだと思う・・・

**名無しさん＠編集中** (ｽﾌﾟｯｯ Sdea-k1/v) · 2018/08/25(土) 14:35:44.36

>>83=84
とうとう自演しやがったwww
全角の使い方でバレバレ

**名無しさん＠編集中** (ﾜｯﾁｮｲ ddeb-MHz5) · 2018/08/25(土) 15:36:05.17

>>83-84
ﾜｯﾁｮｲ b9ec-PcWx
ﾜｯﾁｮｲ 29c3-PcWx

くっさｗｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6ad2-MHz5) · 2018/08/25(土) 16:35:38.35

ワッチョイの下4桁はUserAgentで決まるから被ってもおかしくないはず
PcWxはMonazilla/1.00 JaneStyle/4.00 Windows/10.0.17134らしいから利用者も多いだろうし

**名無しさん＠編集中** (ﾜｯﾁｮｲ ddeb-MHz5) · 2018/08/25(土) 16:43:08.51

たまたまこんな過疎スレで全角もワッチョイも被って
たまたまレスが並ぶなんて珍しい事が起きたんだね
なるほど～

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/25(土) 17:00:29.06

JaneStyle使ってるだけで同じ人扱いされるとは・・・俺はずっと↓このIDだから
http://hissi.org/read.php/avi/20180825/RG92RG4vWWEw.html
>>88
君はもう少し勉強してからレスしような

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/25(土) 17:35:59.42

NVEncの固定品質(>>58)試してるんだけど、どうもコレ内部では
ビットレート指定VBRと全く同じモードで動いてるっぽい
（少なくともGTX1060では）

ビットレート指定VBRと画質が全然変わらなかった

実写、アニメ、前半実写で後半アニメの3つくらいでエンコしてSSIM測って
SSIM-ビットレートをプロットしたら全部同じ線上に並んでしまった

という訳で今の所使う意味なさそう
次のTuringでは良くなるのかなぁ

2018/08/25(土) 17:36:37.74

んなもんソースによる、一概な答えしか容認出来ない馬鹿は頬っておけ

2018/08/25(土) 17:43:46.29

Turingの方はTensorコア使ったポストエフェクトとか超解像の方がトピックかもしれん
SDKから機能的にどう触れるかはまだ解らんけども、描画フレームにms単位の処理時間で適用出来る変態仕様みたいなんで
デコードされたフレームデータにも使えたらフィルタ処理系で色々面白い事出来るかも

**名無しさん＠編集中** (ﾜｯﾁｮｲ dd11-PcWx) · 2018/08/25(土) 18:04:54.22

>>90
mpc-hcでビットレート観測するのが簡単
なんか、どっかでも書いたけど3Mbpsとか比較的十分にビットレートを使ってたら画質差は出にくい

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/25(土) 19:10:57.61

あれ、でもやっぱりビットレート分布は全然違った
ビットレート指定VBRと同じではなかった
ビットレート分布が変わっても平均するとプラマイゼロでSSIMは変わらないのか・・・

**名無しさん＠編集中** (ﾜｯﾁｮｲ ddeb-MHz5) · 2018/08/25(土) 19:11:18.75

>>83
分かったからID:Fz8j+osy0 連れて来いよｗｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/25(土) 19:23:10.26

NVEncの固定品質はちゃんと固定品質になってた
↓最初4分の1が実写で以降アニメの動画をエンコードしてCheckBitrateでビットレート分布出した
https://i.imgur.com/BfPIXjI.png

SSIMはほぼ同じだったけどSSIMはそういうものなのかな
まぁでも固定品質がちゃんと使えることは分かったわ

これからは固定品質一択だね
ビットレート指定VBRなんて必要ないわ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/25(土) 19:56:16.56

>>92
Tensorコアでリアルタイムwaifu2xに期待

**名無しさん＠編集中** (ﾜｯﾁｮｲ d9ec-PcWx) · 2018/08/25(土) 20:19:17.91

>>90 >>96

>>55と>>58にあるNVEncの

　> --vbrhq 0 --vbr-quality 32

については、rigaya氏のブログのNVEnc 4.12の記事のコメント欄でやりとりされていて、
そこでのrigaya氏のコメントは以下のようになってる。

---
固定品質モードですが、ご指摘の方法でよろしいかと思います。

NVEncCのドキュメントにないのは、一応NVENCのSDK上では、
これがビットレート指定モードの一部だからです。
(「Rate control」としてはずばり固定品質モードというのはなく、
vbrhqでビットレートを指定しない(つまり0)、という形が必要です)
---

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/25(土) 20:42:10.78

ビットレート指定モードの一部が固定品質モードってのはなんか分かりにくいなｗ

2018/08/25(土) 20:49:29.76

>>97
何勘違いしているのか、知ってるフィルタの名前使いたいのか知らんけど
Tensorコアでwaifuの処理内容が高速に処理出来る訳じゃ無い

nvidiaが用意した機械学習成果を元にTensorコアで判断処理して補正・補完を適用するnvidiaの超解像技術になる
学習データが更新されると精度も上がるだろうし、レイトレなんかよりコンシューマPC環境にTensorコアを使用した処理環境が降りてくる方がデカい

2018/08/25(土) 21:01:03.56

nvencの固定品質モードってのは便宜上やりとりとしてがそう呼称してるだけで

ビットレートの指定を明示的に無くす事で、指定ビットレートに近づけるために量子化係数の増減調整がされなくなるから、実質上固定品質と同意の処理になるってだけ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/25(土) 21:04:45.93

>>100
別に勘違いしてないよ
nvidiaが用意するモデルにも興味はあるけど、既に高画質だって分かってるwaifu2xが
Tensorコアを使えるようになってリアルタイムくらいの速さになればいいなって期待してる

Tensorコアはfp16(半精度)で4x4の行列積を演算するコアだよ
convolutionを高速に計算するためにあるんだから、
convolutionがボトルネックになってるwaifu2xも高速化できるはず

今はfp32で演算してるからfp16でも精度がなるべく落ちないようにチューニングする必要はあるだろうけど
Tensorコア使ってconvolutionを計算するところはcuDNNがやってくれるから
書き換えはそんなに大変じゃないと思う

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/25(土) 21:09:21.97

>>101
揚げ足取るようで申し訳ないけど、固定量子化量(Constant QP)じゃないんだから
量子化係数は調整してるでしょ
もしかして今の実装的には固定品質＝固定量子化量だったりする？

2018/08/25(土) 21:59:30.04

>>103
「指定ビットレートに近づけるために量子化係数の増減調整」と書いているんだが
画質評価基準に擦り寄せる為の量子化係数の調整と勝手に思い込みで混同されても困る

waifu2xの件も行列積の浮動小数点演算精度が半精度化しているなら、行列積としての精度どれほど落ちると思ってる？
もうそれはwaifu2xのロジックをベースとした精度が大幅低下した派生物でwifu2xでは無いんだよ、同じ処理が出来ている訳じゃ無いんだしな

都合良く読み替えたり、後出しで精度不足とか都合の良い部分容認してみたりとか、ほんとに狡い奴だなお前は

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/26(日) 02:11:05.20

>>104
えっと、つまり>>101の

ビットレートの指定を明示的に無くす事で、指定ビットレートに近づけるために量子化係数の増減調整が
されなくなるから、実質上固定品質と同意の処理になるってだけ

↑これの解釈は

ビットレートの指定を明示的に無くす事で、（「指定ビットレートに近づけるために量子化係数の増減調整」と
「画質評価基準に擦り寄せる為の量子化係数の調整」の両方をやっていたところの）
指定ビットレートに近づけるために量子化係数の増減調整がされなくなるから、
（「画質評価基準に擦り寄せる為の量子化係数の調整」だけになって）実質上固定品質と同意の処理になるってだけ

ってことか？それとも

ビットレートの指定を明示的に無くす事で、指定ビットレートに近づけるために量子化係数の増減調整が
されなくなるから、（代わりに「画質評価基準に擦り寄せる為の量子化係数の調整」がされるようになって）
実質上固定品質と同意の処理になるってだけ

ってことか？うーむ・・・

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/26(日) 02:30:07.42

>>104
waifu2xは「Tensorコアで」って書いてるんだから半精度化することも含めて
できたらいいなっていう期待で書いてるんだけど・・・

> waifu2xの件も行列積の浮動小数点演算精度が半精度化しているなら、行列積としての精度どれほど落ちると思ってる？

ディープラーニングの推論をfp16やint8でやっても精度低下は僅かって話はたくさんあるし、
nvidiaがfp16の演算コアを導入したのは、「ディープラーニングでは精度低下は僅かで十分実用的」だからでしょ
それを否定されてもなぁ・・・

2018/08/26(日) 09:46:57.21

>>106
ホントに手前の都合良く緩さを容認した事は「当たり前」と話して、そうじゃない事は違いを許さないとか利己的だな

行列積は単純な浮動小数点の計算と違って、複数回計算で精度取り戻せない
32bit精度で行列演算するコードを16bit精度のTensorコアで高速化とか、半精度を容認する前置きも無く書き込んでおいて
後出しで半精度容認している旨書き込んで悪びれもしないし

waifu2xと同様の処理が出来ても同じ精度維持出来ないから同じ処理は出来ないと言っているのに
機械学習でTensorコアの効果を否定しているかの様に勝手に話置き換え始めたり
ホントに最低に狡い奴だな

2018/08/26(日) 09:50:58.32

>>105
前者

**名無しさん＠編集中** (ﾜｯﾁｮｲ d9ec-PcWx) · 2018/08/26(日) 11:21:56.08

要するに

　45c3-iM7h ：
　　精度を落としたものをwaifu2xと呼ぶことは絶対に認めない

　29c3-PcWx ：
　　今の waifu2x は高品質だけど遅すぎるから、半精度化によってある程度品質が落ちる代わりに
　　Tensorコアによる高速化メリットが得られる waifu2x' みたいなもんができるといいな。
　　(半精度化による品質低下やTensorコアによる高速化がどれくらいかにもよるけど)

ってことじゃないの。

技術的なこだわりが強いのか何なのか知らんが、受け取り方がねじ曲がりすぎじゃね？
カリカリして人格攻撃するほどの話じゃないだろ。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/26(日) 14:06:55.17

>>107
> 32bit精度で行列演算するコードを16bit精度のTensorコアで高速化とか、半精度を容認する前置きも無く書き込んでおいて

>>92
> Tensorコア使ったポストエフェクトとか超解像

これはディープラーニングを使ったもので、「Tensorコアでディープラーニングを計算する」
って時点で、fp16に精度を落として行列積を計算するってことだよ

つまり、ディープラーニング（正確には行列積部分）をfp16で計算するっていうのは君が最初に言ってること

同じようにディープラーニングで超解像するwaifu2xもTensorコアで高速化できるよね
って話をしてるんだから、fp16で計算するっていうのは何の脈絡もなく出てきたわけではない

> waifu2xと同様の処理が出来ても同じ精度維持出来ないから同じ処理は出来ないと言っているのに
> 機械学習でTensorコアの効果を否定しているかの様に勝手に話置き換え始めたり

ディープラーニングを使った代表例みたいなwaifu2xにTensorコアを使うことを否定するのは
「機械学習でTensorコアの効果を否定」するのと同義だと思うのだが

**名無しさん＠編集中** (ｱｳｰｲﾓ MMa1-0Goq) · 2018/08/26(日) 14:26:50.50

0か1しか価値判断基準のない人は疲れるな

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/26(日) 15:11:35.59

>>108
NVEncの実際の実装が後者の可能性もあると思うけど、なんで前者だって分かるの？

**名無しさん＠編集中** (ﾜｯﾁｮｲ d9ec-PcWx) · 2018/08/26(日) 15:22:59.23

>>110のように「お前が最初に言った」みたいな書き方をすると、また不毛な返答が返ってくる気がするので

　　"こっちは元々「fp16化+Tensorコアで高速化したリアルタイムwaifu2x(もどき)」を想定して書き込んでて、
　　　>>100でお前が勘違いとか言ってきたからそれに答えて詳細を説明しただけなのに、
　　　精度落としたらwaifu2xじゃないとか、後出しとか狡いとか利己的とか言われて迷惑してる。”

って書いてやった方がよい気がする。

2018/08/26(日) 17:18:48.39

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

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

2018/08/26(日) 17:29:49.46

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

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

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

**名無しさん＠編集中** (ﾌﾞｰｲﾓ MM01-AWmg) · 2018/08/26(日) 18:05:10.01

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ d9ec-PcWx) · 2018/08/26(日) 18:28:06.93

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

そもそもその前の時点でお前が話を読み違えてるんだよ。>>107でお前が

　　> 機械学習でTensorコアの効果を否定しているかの様に勝手に話置き換え始めたり

と書いてるが、106はTensorコアの効果の否定なんてしてないだろ。
下3行の解釈を、お前が間違えてるだけのように見えるが。

29c3-PcWx が言いたいのは、

　・Tensorコアがfp16なのは、NVIDIAがfp16でもディープラーニングでは十分実用的だと判断したからではないか

　・ならばwaifu2xのfp32処理の部分を、Tensorコアのfp16処理に変えてみるのももしかしたらアリではないか？

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

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ d9ec-PcWx) · 2018/08/26(日) 18:36:13.01

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

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/26(日) 20:25:54.45

>>115
ビットレート指定時は品質基準VBRじゃないでしょ
ビットレート指定のVBRなんだから
ビットレートを指定しなかったときに品質基準VBRになる

> nvidiaが品質基準VBRとして実装しているものすら疑いだしたら、何を基準で正否とするよの？

固定QPモードがあるんだから、ビットレート指定VBRは、
平均ビットレートが目標より大きくズレたら、適当にQP操作してるだけかもしれないじゃん
そこから、ビットレートを目標にあわせる処理を抜いたら、固定QPになっちゃう
NVEncCのデフォは固定QPだし

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

後者か前者かなんて分からないよ
中の実装がどうなってるかなんて知らないから
エンコード結果、どういう出力がされたかくらいでしか観測できない

ビットレート指定VBR時はビットレート指定VBRのレートコントロールが働いて
品質基準VBR時は品質基準VBRのレートコントロールが働くって考えるのが
最もシンプルな理解だと思うから、そうじゃないときはちゃんと書いてくれないと分からないよ

**名無しさん＠編集中** (ﾜｯﾁｮｲ d9ec-PcWx) · 2018/08/26(日) 20:51:24.96

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

　https://pastebin.com/LuGCNXbY

**名無しさん＠編集中** (ﾜｯﾁｮｲ 29c3-PcWx) · 2018/08/26(日) 21:11:24.15

>>120
サンクス

この資料だと、Target Quality(固定品質)がVBRの一部って書き方じゃないんだよね

対応してるレートコントロールは以下の4つです
- CBR
- VBR
- 固定QP
- 固定品質

って感じ

あとVBRのレートコントロールについての記述は主に
> The encoder tries to conform to average bitrate of averageBitRate over the long term
これだけ

2018/08/27(月) 10:48:37.03

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2580-PcWx) · 2018/08/27(月) 11:34:45.47

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

2018/08/30(木) 18:15:44.74

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時間ｗ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 8bdc-P9Fo) · 2018/09/02(日) 19:42:33.51

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

**名無しさん＠編集中** (ｵｯﾍﾟｹ Srab-Em6u) · 2018/09/09(日) 04:59:21.22

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

2018/09/09(日) 10:55:29.43

マヌケの戯言

2018/09/09(日) 10:57:32.83

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

**名無しさん＠編集中** (ｷｭｯｷｭ MM77-4kZw) · 2018/09/09(日) 13:57:41.51

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

**名無しさん＠編集中** (ｷｭｯｷｭ Srab-Em6u) · 2018/09/09(日) 14:14:25.74

マヌケの戯言

2018/09/11(火) 09:19:07.11

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

**名無しさん＠編集中** (ｽﾌﾟｯｯ Sd7a-HjvB) · 2018/09/11(火) 10:44:00.24

ソースで多少前後するけど
静止画比較しないと気にならないレベルなら
固定量子化ベースの量子化係数設定値なら
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の録画後に自動処理で録画タスク毎に処理するのには向かない（やりようはいくらでもあるけど）のが難点

2018/09/11(火) 10:55:40.29

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

2018/09/11(火) 16:32:00.96

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

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

2018/09/11(火) 16:34:04.00

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 17c3-7GfT) · 2018/09/11(火) 22:40:56.55

Amatsukazeなら何の問題もない

**名無しさん＠編集中** (ﾜｯﾁｮｲ 379f-okpm) · 2018/09/14(金) 23:28:10.31

https://www.4gamer.net/games/421/G042134/20180913178/SS/047.jpg
なかなかえーんでない？

元記事: 西川善司の3DGE：GeForce RTX 20完全理解。レイトレ以外の部分も強化が入ったTuringアーキテクチャにとことん迫る
https://www.4gamer.net/games/421/G042134/20180913178/

2018/09/15(土) 00:24:18.61

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

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7feb-TNGn) · 2018/09/15(土) 00:27:43.52

AMDって今何してるの？

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

2018/09/15(土) 00:33:21.67

画像の中の表によると
1080・60pの動画をビットレート6Mbps設定でエンコードした場合に
x264のプリセットFastと、Turing世代のGPUでH.264（かと思われ）を比較すると、
PSNRの値が少しTuring世代のGPUのほうが上回っている

となると、x264のプリセットslowと比べるとしてもビットレートを2割増程度で充分対抗できるかも？

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

**名無しさん＠編集中** (ｵｯﾍﾟｹ Sr8b-dlVL) · 2018/09/15(土) 00:38:14.81

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 379f-okpm) · 2018/09/15(土) 00:46:15.23

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

2018/09/15(土) 00:46:40.52

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

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9f11-okpm) · 2018/09/15(土) 01:04:36.37

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

2018/09/15(土) 01:08:09.38

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

**名無しさん＠編集中** (ｵｯﾍﾟｹ Sr8b-dlVL) · 2018/09/15(土) 01:09:41.00

>>131
それな

2018/09/15(土) 01:46:55.02

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 97c3-6Nbz) · 2018/09/15(土) 10:34:47.56

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 77a9-okpm) · 2018/09/15(土) 13:09:31.74

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

**名無しさん＠編集中** (ｱｳｰｲﾓ MM1b-kO1E) · 2018/09/15(土) 13:27:48.90

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 379f-okpm) · 2018/09/15(土) 13:40:22.01

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ b7e9-TNGn) · 2018/09/15(土) 15:03:11.50

>>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は省略されているものがあるのではないかと噂があるのは確か

**名無しさん＠編集中** (ﾜｯﾁｮｲ 379f-okpm) · 2018/09/15(土) 15:08:21.91

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ bfc2-cYcl) · 2018/09/15(土) 17:37:16.95

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

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 57ec-okpm) · 2018/09/15(土) 18:05:15.54

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

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

他に何かあるっけ？

**名無しさん＠編集中** (ﾜｯﾁｮｲ 97c3-KPUK) · 2018/09/16(日) 02:11:11.67

2050Tiはまだか

**名無しさん＠編集中** (ﾜｯﾁｮｲ 7780-okpm) · 2018/09/16(日) 12:06:58.48

2060狙いだわ俺

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5780-OhoC) · 2018/09/16(日) 14:23:06.56

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

**名無しさん＠編集中** (ｱｳｰｲﾓ MM1b-kO1E) · 2018/09/16(日) 17:38:32.95

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 9706-G9Ec) · 2018/09/19(水) 03:43:00.21

2030までじっと待つよ

**名無しさん＠編集中** (ﾜｯﾁｮｲ 6581-coYL) · 2018/09/20(木) 04:45:35.71

コピペ

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めちゃめちゃ遅いですね。ヤフオクで売ってきます

2018/09/20(木) 07:24:20.06

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 01ec-coYL) · 2018/09/20(木) 16:33:06.73

>>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デコードと大して変わらないかな？

**名無しさん＠編集中** (ｽﾌﾟｯｯ Sdc2-GVbW) · 2018/09/20(木) 16:50:31.73

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 01ec-coYL) · 2018/09/20(木) 19:02:45.31

>>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はもう少し伸びる可能性はあるかも。

**名無しさん＠編集中** (ﾜｯﾁｮｲ 01ec-coYL) · 2018/09/20(木) 19:06:05.15

参考： ffmpegでNVDEC(CUVID)/NVENCを使ってフルHWトランスコードする方法

　HWAccelIntro ? FFmpeg
　https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNVDEC

2018/09/20(木) 19:31:19.63

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

2018/09/20(木) 20:00:35.48

ゴミネオ注意報

2018/09/20(木) 22:44:29.64

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

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

2018/09/20(木) 22:56:50.16

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2dec-coYL) · 2018/09/20(木) 23:51:49.65

>>169
どこの情報？

2018/09/21(金) 00:03:13.17

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 2dec-coYL) · 2018/09/21(金) 00:31:24.95

>>172
それにはマクロブロックどうこうということまでは書かれてないから、
どっか別のとこでに詳細な説明でもされてたのかなと思って。

　NVIDIA Turing Architecture In-Depth | NVIDIA Developer Blog
　https://devblogs.nvidia.com/nvidia-turing-architecture-in-depth/

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ f1e9-Y82R) · 2018/09/21(金) 01:41:09.43

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ 5dc3-coYL) · 2018/09/21(金) 05:59:20.60

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

**名無しさん＠編集中** (ﾜｯﾁｮｲ c980-coYL) · 2018/09/21(金) 09:36:29.68

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