18/08/25 20:19:17.91 gHNH7/ie0.net
>>90 >>96
>>55と>>58にあるNVEncの
> --vbrhq 0 --vbr-quality 32
については、rigaya氏のブログのNVEnc 4.12の記事のコメント欄でやりとりされていて、
そこでのrigaya氏のコメントは以下のようになってる。
---
固定品質モードですが、ご指摘の方法でよろしいかと思います。
NVEncCのドキュメントにないのは、一応NVENCのSDK上では、
これがビットレート指定モードの一部だからです。
(「Rate control」としてはずばり固定品質モードというのはなく、
vbrhqでビットレートを指定しない(つまり0)、という形が必要です)
---
102:名無しさん＠編集中
18/08/25 20:42:10.78 DovDn/Ya0.net
ビットレート指定モードの一部が固定品質モードってのはなんか分かりにくいなｗ
103:名無しさん＠編集中
18/08/25 20:49:29.76 k4YhneCR0.net
>>97
何勘違いしているのか、知ってるフィルタの名前使いたいのか知らんけど
Tensorコアでwaifuの処理内容が高速に処理出来る訳じゃ無い
nvidiaが用意した機械学習成果を元にTensorコアで判断処理して補正・補完を適用するnvidiaの超解像技術になる
学習データが更新されると精度も上がるだろうし、レイトレなんかよりコンシューマPC環境にTensorコアを使用した処理環境が降りてくる方がデカい
104:名無しさん＠編集中
18/08/25 21:01:03.56 k4YhneCR0.net
nvencの固定品質モードってのは便宜上やりとりとしてがそう呼称してるだけで
ビットレートの指定を明示的に無くす事で、指定ビットレートに近づけるために量子化係数の増減調整がされなくなるから、実質上固定品質と同意の処理になるってだけ
105:名無しさん＠編集中
18/08/25 21:04:45.93 DovDn/Ya0.net
>>100
別に勘違いしてないよ
nvidiaが用意するモデルにも興味はあるけど、既に高画質だって分かってるwaifu2xが
Tensorコアを使えるようになってリアルタイムくらいの速さになればいいなって期待してる
Tensorコアはfp16(半精度)で4x4の行列積を演算するコアだよ
convolutionを高速に計算するためにあるんだから、
convolutionがボトルネックになってるwaifu2xも高速化できるはず
今はfp32で演算してるからfp16でも精度がなるべく落ちないようにチューニングする必要はあるだろうけど
Tensorコア使ってconvolutionを計算するところはcuDNNがやってくれるから
書き換えはそんなに大変じゃないと思う
106:名無しさん＠編集中
18/08/25 21:09:21.97 DovDn/Ya0.net
>>101
揚げ足取るようで申し訳ないけど、固定量子化量(Constant QP)じゃないんだから
量子化係数は調整してるでしょ
もしかして今の実装的には 固定品質＝固定量子化量 だったりする？
107:名無しさん＠編集中
18/08/25 21:59:30.04 k4YhneCR0.net
108:>>103 「指定ビットレートに近づけるために量子化係数の増減調整」と書いているんだが 画質評価基準に擦り寄せる為の量子化係数の調整と勝手に思い込みで混同されても困る waifu2xの件も行列積の浮動小数点演算精度が半精度化しているなら、行列積としての精度どれほど落ちると思ってる？ もうそれはwaifu2xのロジックをベースとした精度が大幅低下した派生物でwifu2xでは無いんだよ、同じ処理が出来ている訳じゃ無いんだしな 都合良く読み替えたり、後出しで精度不足とか都合の良い部分容認してみたりとか、ほんとに狡い奴だなお前は
109:名無しさん＠編集中
18/08/26 02:11:05.20 i4axf3T+0.net
>>104
えっと、つまり>>101の
ビットレートの指定を明示的に無くす事で、指定ビットレートに近づけるために量子化係数の増減調整が
されなくなるから、実質上固定品質と同意の処理になるってだけ
↑これの解釈は
ビットレートの指定を明示的に無くす事で、（「指定ビットレートに近づけるために量子化係数の増減調整」と
「画質評価基準に擦り寄せる為の量子化係数の調整」の両方をやっていたところの）
指定ビットレートに近づけるために量子化係数の増減調整がされなくなるから、
（「画質評価基準に擦り寄せる為の量子化係数の調整」だけになって）実質上固定品質と同意の処理になるってだけ
ってことか？それとも
ビットレートの指定を明示的に無くす事で、指定ビットレートに近づけるために量子化係数の増減調整が
されなくなるから、（代わりに「画質評価基準に擦り寄せる為の量子化係数の調整」がされるようになって）
実質上固定品質と同意の処理になるってだけ
ってことか？うーむ・・・
110:名無しさん＠編集中
18/08/26 02:30:07.42 i4axf3T+0.net
>>104
waifu2xは「Tensorコアで」って書いてるんだから半精度化することも含めて
できたらいいなっていう期待で書いてるんだけど・・・
> waifu2xの件も行列積の浮動小数点演算精度が半精度化しているなら、行列積としての精度どれほど落ちると思ってる？
ディープラーニングの推論をfp16やint8でやっても精度低下は僅かって話はたくさんあるし、
nvidiaがfp16の演算コアを導入したのは、「ディープラーニングでは精度低下は僅かで十分実用的」だからでしょ
それを否定されてもなぁ・・・
111:名無しさん＠編集中
18/08/26 09:46:57.21 BIBv3N7z0.net
>>106
ホントに手前の都合良く緩さを容認した事は「当たり前」と話して、そうじゃない事は違いを許さないとか利己的だな
行列積は単純な浮動小数点の計算と違って、複数回計算で精度取り戻せない
32bit精度で行列演算するコードを16bit精度のTensorコアで高速化とか、半精度を容認する前置きも無く書き込んでおいて
後出しで半精度容認している旨書き込んで悪びれもしないし
waifu2xと同様の処理が出来ても同じ精度維持出来ないから同じ処理は出来ないと言っているのに
機械学習でTensorコアの効果を否定しているかの様に勝手に話置き換え始めたり
ホントに最低に狡い奴だな
112:名無しさん＠編集中
18/08/26 09:50:58.32 BIBv3N7z0.net
>>105
前者
113:名無しさん＠編集中
18/08/26 11:21:56.08 m7n2BMFu0.net
要するに
45c3-iM7h ：
精度を落としたものをwaifu2xと呼ぶことは絶対に認めない
29c3-PcWx ：
今の waifu2x は高品質だけど遅すぎるから、半精度化によってある程度品質が落ちる代わりに
Tensorコアによる高速化メリットが得られる waifu2x' みたいなもんができるといいな。
(半精度化による品質低下やTensorコアによる高速化がどれくらいかにもよるけど)
ってことじゃないの。
技術的なこだわりが強いのか何なのか知らんが、受け取り方がねじ曲がりすぎじゃね？
カリカリして人格攻撃するほどの話じゃないだろ。
114:名無しさん＠編集中
18/08/26 14:06:55.17 i4axf3T+0.net
>>107
> 32bit精度で行列演算するコードを16bit精度のTensorコアで高速化とか、半精度を容認する前置きも無く書き込んでおいて
>>92
> Tensorコア使ったポストエフェクトとか超解像
これはディープラーニングを使ったもので、「Tensorコアでディープラーニングを計算する」
って時点で、fp16に精度を落として行列積を計算するってことだよ
つまり、ディープラーニング（正確には行列積部分）をfp16で計算するっていうのは君が最初に言ってること
同じようにディープラーニングで超解像するwaifu2xもTensorコアで高速化できるよね
って話をしてるんだから、fp16で計算するっていうのは何の脈絡もなく出てきたわけではない
> waifu2xと同様の処理が出来ても同じ精度維持出来ないから同じ処理は出来ないと言っているのに
> 機械学習でTensorコアの効果を否定しているかの様に勝手に話置き換え始めたり
ディープラーニングを使った代表例みたいなwaifu2xにTensorコアを使うことを否定するのは
「機械学習でTensorコアの効果を否定」するのと同義だと思うのだが
115:名無しさん＠編集中
18/08/26 14:26:50.50 ztucUYzzM.net
0か1しか価値判断基準のない人は疲れるな
116:名無しさん＠編集中
18/08/26 15:11:35.59 i4axf3T+0.net
>>108
117: NVEncの実際の実装が後者の可能性もあると思うけど、なんで前者だって分かるの？
118:名無しさん＠編集中
18/08/26 15:22:59.23 m7n2BMFu0.net
>>110のように「お前が最初に言った」みたいな書き方をすると、また不毛な返答が返ってくる気がするので
"こっちは元々「fp16化+Tensorコアで高速化したリアルタイムwaifu2x(もどき)」を想定して書き込んでて、
>>100でお前が勘違いとか言ってきたからそれに答えて詳細を説明しただけなのに、
精度落としたらwaifu2xじゃないとか、後出しとか狡いとか利己的とか言われて迷惑してる。”
って書いてやった方がよい気がする。
119:名無しさん＠編集中
18/08/26 17:18:48.39 BIBv3N7z0.net
>>113
指摘の弁解も理由も全部後出し
取り繕いばっかりじゃねーかよ
そんで、waifu2xの演算に精度不足というなのがTensorコアが機械学習用途に不適というこじつけなるか理由聞かせてくれよ
120:名無しさん＠編集中
18/08/26 17:29:49.46 BIBv3N7z0.net
>>112
「可能性」とか言い出せばどっち前者だろうが後者だろうがイチャモン付けられるってか？
品質基準のVBRロジックなんだから、ビットレート指定時に品質基準での調整ロジックが動いて無く、ビットレート指定を無くした時にだけ稼働すなら、ビットレート指定時は品質基準のVBRじゃなくなるわな
nvidiaが品質基準VBRとして実装しているものすら疑いだしたら、何を基準で正否とするよの？
後者と判断するなら、その根拠を提示してくれよ
121:名無しさん＠編集中
18/08/26 18:05:10.01 k5cd80q8M.net
ffmpegでのエンコードパラメータを極めるスレはどこ？
122:名無しさん＠編集中
18/08/26 18:28:06.93 m7n2BMFu0.net
>>114
> waifu2xの演算に精度不足というなのがTensorコアが機械学習用途に不適というこじつけなるか理由聞かせてくれよ
そもそもその前の時点でお前が話を読み違えてるんだよ。>>107でお前が
> 機械学習でTensorコアの効果を否定しているかの様に勝手に話置き換え始めたり
と書いてるが、106はTensorコアの効果の否定なんてしてないだろ。
下3行の解釈を、お前が間違えてるだけのように見えるが。
29c3-PcWx が言いたいのは、
・Tensorコアがfp16なのは、NVIDIAがfp16でもディープラーニングでは十分実用的だと判断したからではないか
・ならばwaifu2xのfp32処理の部分を、Tensorコアのfp16処理に変えてみるのももしかしたらアリではないか？
ってことでしょ。まあディープラーニングっつっても目的によって必要な精度は変わってくるんだろうから
そんな単純な話が成り立つかどうかは知らんけどね。
とりあえず落ち着いて、やりとりを最初から見直してみたほうがいいんじゃねえの。
123:名無しさん＠編集中
18/08/26 18:36:13.01 m7n2BMFu0.net
まあwaifu2xについて、「処理をfp16にしたらまともな品質にならない」みたいな検証が既にされてるのであれば
淡々とその結果を示してあげればいいと思うけど、これ以上続けたいなら
そろそろ画像拡大スレに移ったほうがいいんじゃないかとは思う。
【超解像】画像拡大ソフト総合スレ２【waifu2x】
ｽﾚﾘﾝｸ(software板)
124:名無しさん＠編集中
18/08/26 20:25:54.45 i4axf3T+0.net
>>115
ビットレート指定時は品質基準VBRじゃないでしょ
ビットレート指定のVBRなんだから
ビットレートを指定しなかったときに品質基準VBRになる
> nvidiaが品質基準VBRとして実装しているものすら疑いだしたら、何を基準で正否とするよの？
固定QPモードがあるんだから、ビットレート指定VBRは、
平均ビットレートが目標より大きくズレたら、適当にQP操作してるだけかもしれないじゃん
そこから、ビットレートを目標にあわせる処理を抜いたら、固定QPになっちゃう
NVEncCのデフォは固定QPだし
> 後者と判断するなら、その根拠を提示してくれよ
後者か前者かなんて分からないよ
中の実装がどうなってるかなんて知らないから
エンコード結果、どういう出力がされたかくらいでしか観測できない
ビットレート指定VBR時はビットレート指定VBRのレートコントロールが働いて
品質基準VBR時は品質基準VBRのレートコントロールが働くって考えるのが
最もシンプルな理解だと思うから、そうじゃないときはちゃんと書いてくれないと分からないよ
125:名無しさん＠編集中
18/08/26 20:51:24.96 m7n2BMFu0.net
細かいことはよくわかんねーけど、とりあえずNVIDIA Video Codec SDK
126:8.2.15 の NVENC_VideoEncoder_API_ProgGuide.pdf の 「3.8.3 Rate control」の内容を貼っとくわ。 https://pastebin.com/LuGCNXbY
127:名無しさん＠編集中
18/08/26 21:11:24.15 i4axf3T+0.net
>>120
サンクス
この資料だと、Target Quality(固定品質)がVBRの一部って書き方じゃないんだよね
対応してるレートコントロールは以下の4つです
- CBR
- VBR
- 固定QP
- 固定品質
って感じ
あとVBRのレートコントロールについての記述は主に
> The encoder tries to conform to average bitrate of averageBitRate over the long term
これだけ
128:名無しさん＠編集中
18/08/27 10:48:37.03 KSUuDcZo0.net
紙芝居のためにご苦労さま
129:名無しさん＠編集中
18/08/27 11:34:45.47 dyyUpjbe0.net
これが捨て台詞ってヤツか
130:名無しさん＠編集中
18/08/30 18:15:44.74 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時間ｗ
131:名無しさん＠編集中
18/09/02 19:42:33.51 DuBTtQDB0.net
r ‐､
| ○ | r‐‐､ 良い子の諸君！
_,;ﾄ - ｲ、 ∧l☆│∧
（⌒` ⌒ヽ /,､,,ﾄ.-ｲ/,､ l. 証拠を要求するネトヲタがいるが
|ヽ ~~⌒γ⌒） r'⌒ ｀ｉ´ `⌒） 君がいくら証拠を開示しても
│ ヽー―'^ー-' （ ⌒γ⌒~~ /| そのネトヲタは絶対信じないぞ！
│ 〉 |│ |｀ー^ｰ― r' | おまけにそいつは自分側の証拠を出したことがない。
│ /──| | |/ | l ﾄ､ |
| irｰ-､ ｰ ,} | / i 自分の信じたいものしか信じなくなったらおしまいだな！
| / ｀X´ ヽ / 入 ｜
132:名無しさん＠編集中
18/09/09 04:59:21.22 apyEih63r.net
なにが正しいかなんてわからんよ
エンコードしないのが一番いい気がするわ
133:名無しさん＠編集中
18/09/09 10:55:29.43 vbK7CwBM00909.net
マヌケの戯言
134:名無しさん＠編集中
18/09/09 10:57:32.83 SWOzIg6M00909.net
たしかに
劣化させて喜ぶアホ
135:名無しさん＠編集中
18/09/09 13:57:41.51 614xNICFM0909.net
劣化を感じるようなエンコードしかできないのは、ユーザーの能力不足による無理な設定によるところが大きい
いくら優秀なエンコーダーを用いたところで、フルHD動画を最大1Mbpsなんかに設定したら、どうやっても劣化は目につく
それに放送番組を再エンコードするのにノイズ除去すらもせずにエンコード直行など、愚かにもほどがある
136:名無しさん＠編集中
18/09/09 14:14:25.74 eDINVlxYr0909.net
マヌケの戯言
137:名無しさん＠編集中
18/09/11 09:19:07.11 nd7uezLA0.net
もうHDD買い足してソースをそのまま保存しとけよ
エンコードなんかしてたら人生損するよ
138:名無しさん＠編集中
18/09/11 10:44:00.24 CJzWO1xPd.net
ソースで多少前後するけど
静止画比較しないと気にならないレベルなら
固定量子化ベースの量子化係数設定値なら
H264 QSV ～22
H264 NVEnc～20
HEVC QSV ～24
HEVC EVEnc Pascal ～23 Maxwwll ～22
あたりが画質に目立った劣化が知覚できるかの境界線あたりかと（あとは好みで1減らすなり、IPBで階段状に設定するなり
コーデック問わず画質容量比と処理時間でなら、PascalのNVEncが速度とのバランス的に優秀
H264→HEVCでの速度低下がQSVが1/3～1/4にもなるけど、NVEncだとMaxwellで1/2、Pascalで2/3程度の速度にしか落ちないのがデカい
HWエンコーダで時間問わずならQSVのHEVCなんだろうけど
HEVCだと速度低下激しすぎて（GT2で40fps前後）CPUの方がOC4コア以上ならx264のfasterとかで処理しちまった方が良くなってくる
ただNVEncはGeforce/Titanだと同時処理が2件までなんで、TSの録画後に自動処理で録画タスク毎に処理するのには向かない（やりようはいくらでもあるけど）のが難点
139:名無しさん＠編集中
18/09/11 10:55:40.29 cvr00PSpa.net
録画後処理じゃなくて
定期的にファイルリストに対して
1本ずつ処理したらええだないかね
140:名無しさん＠編集中
18/09/11 16:32:00.96 gbdYj/Dq0.net
>>115
組める人には問題ないけどね（自分もそうやっている
フォルダ監視して順次エンコさせる場合には、リスト取得や録画中のファイルか録画完了したファイルかの判断とか
録画管理ソフトで録画終了時に実行する様なバッチみたいに、コマンドラインのエンコード命令にに毛の生えたぐらいのと違って、自分で組まなきゃならん部分多いから多少はハードル高くはなる
実際に他のスレで同時エンコ数の制限有るから使いづらいみたいな事書き込んでた奴も見かけてるし
141:名無しさん＠編集中
18/09/11 16:34:04.00 gbdYj/Dq0.net
ありゃ、リンクミス
>>133
>>115
142:名無しさん＠編集中
18/09/11 22:40:56.55 UKWbxX7R0.net
Amatsukazeなら何の問題もない
143:名無しさん＠編集中
18/09/14 23:28:10.31 mw+2E23g0.net
URLﾘﾝｸ(www.4gamer.net)
なかなかえーんでない？
元記事: 西川善司の3DGE：GeForce RTX 20完全理解。レイトレ以外の部分も強化が入ったTuringアーキテクチャにとことん迫る
URLﾘﾝｸ(www.4gamer.net)
144:名無しさん＠編集中
18/09/15 00:24:18.61 6Guydu2D0.net
>>137
「また，エンコーダの圧縮アルゴリズムにも改良が入っており，Pascal世代と比較して，同じ画質ならH.264で15％，H.265なら25％も低ビットレート化できるようになった。
逆に言えば，同じビットレートならPascal世代のGPUを使うよりも高い画質を得られるということだ。」
おぉー！
これは期待しちゃうなぁ
145:名無しさん＠編集中
18/09/15 00:27:43.52 fy+82PFP0.net
AMDって今何してるの？
動画ならAMDなんて時代もあったのに…
146:名無しさん＠編集中
18/09/15 00:33:21.67 6Guydu2D0.net
画像の中の表によると
1080・60pの動画をビットレート6Mbps設定でエンコードした場合に
x264のプリセットFastと、Turing世代のGPUでH.264（かと思われ）を比較すると、
PSNRの値が少しTuring世代のGPUのほうが上回っている
となると、x264のプリセットslowと比べるとしてもビットレートを2割増程度で充分対抗できるかも？
なんかすごいことになってきたな
147:名無しさん＠編集中
18/09/15 00:38:14.81 cjvlLd9kr.net
>>139
CPU作ってるよ
ATiって言わない時点で知ってるんだろマヌケ
148:名無しさん＠編集中
18/09/15 00:46:15.23 vV+sK+U50.net
Poralisでリアルタイム2パスエンコードエンジン採用してディティールが残るとか言ってたのは結局どうだったの？
URLﾘﾝｸ(www.4gamer.net)
149:名無しさん＠編集中
18/09/15 00:46:40.52 rREhMZBO0.net
文脈読むならNVIDIAやインテルにGPUエンコでぼろ負けだけどGPUでエンコやる気ないの？
150:だろ どう見てもなさそうだね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の例で
Ａ： --brframes 0
Ｂ：--brframes 3 --b-pyramid
を比較すると
Ａ：3000kbps→Ｂ：2100kbps ＝ 30%のビットレート削減 （SSIM＝0.988ライン)
Ａ：36000kbps→Ｂ：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:ＣＰＵで、ソフトエンコすればいい。 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
新人のインタービューやワンパターンのやるだけ明るい部屋はいいけど、８時間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に書き換えたなｗ
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思い出したｗ
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
ｂフレーム対応でようやくハードウェアエンコードが市民権得られる時代になったかな？
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とかそんな頃ｗ
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) ダブルクリック１発で、結果は 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になる。
「データ量が膨大になってもいいからロスレス(可逆)キャプチャしたい」という強いこだわりがあるなら別に止めないけど、
得られる画質は数分の１のビットレートで通常の非可逆キャプチャした場合と大差ないだろうし、
ロスレスだからといって編集時のデコード処理等が軽くなるわけでもないし、
最終的に保存エンコしたり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でやっとって感じ。相当やばそうｗ
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
ＧＴＸ1050でもHEVC H265エンコ快適に出来ますか？
世代格差によって画質も向上してるなら買い換えも検討します。
360:名無しさん＠編集中
18/11/04 15:03:34.52 xAruxQ/q0.net
>>341
スレのログを読めばTuringでHEVCのBフレームに対応したのがわかるので、
画質を重視するならTuringへの買い替えを検討すればいいと思う。
もしかすると今後のSDKやドライバーの更新でPascal等にも
HEVCのBフレーム利用が開放される可能性もあるけど、まだ不明だし。
Turingは今のところNVENCコアが１つしか載ってないらしいという情報もあるので、
並列エンコを効率よく行いたいという要望があるなら
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)するとエラー
となるらしい。