【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】at AVI
【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】 - 暇つぶし2ch1:名無しさん@編集中
18/08/08 04:44:09.82 NnYmcXUx0.net
ソフトウェアエンコーダーに画質は劣るものの、エンコード完了までの処理速度が爆速なハードウェアエンコーダーを語りましょう
●Intel
URLリンク(software.intel.com)
URLリンク(en.wikipedia.org)
●NVIDIA
URLリンク(developer.nvidia.com)
・エンコード: URLリンク(en.wikipedia.org)
・デコード: URLリンク(en.wikipedia.org)
●AMD
URLリンク(github.com)
・エンコード: URLリンク(en.wikipedia.org)
・デコード: URLリンク(en.wikipedia.org)
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured

2:名無しさん@編集中
18/08/08 04:44:33.44 NnYmcXUx0.net
■各社GPUのHWエンコーダでのH.265/HEVCおよびVP9のサポート状況(2018年7月上旬時点)
●Intel QSV (Kaby Lake/Coffee Lake+Intel Media SDK 2018 R1)
 〇HEVC
  mainおよびmain10。Bフレーム使用可。
 〇VP9
  ・LinuxでVA-APIを使えばKaby Lakeで利用可能らしい。
   URLリンク(gist.github.com)
  ・Intel Media SDK for Windows 2018 R1で、Cannon Lake向けの
   プレビュー機能としてVP9エンコーダ関連のAPIが追加されたので
   Cannon LakeからはWindowsでも使えるようになるかもしれない。
●Nvidia NVEnc (Pascal+NVIDIA Video Codec SDK 8.2)
 〇HEVC
  mainおよびmain10。Bフレーム使用不可。
 〇VP9
  未対応
●AMD VCE (Polaris+AMF 1


3:.4.7)  〇HEVC   mainのみ。main10は不可。Bフレーム使用不可。  〇VP9   未対応



4:名無しさん@編集中
18/08/08 04:44:53.44 NnYmcXUx0.net
1

5:名無しさん@編集中
18/08/08 04:45:33.06 NnYmcXUx0.net
2

6:名無しさん@編集中
18/08/08 04:45:48.95 NnYmcXUx0.net
3

7:名無しさん@編集中
18/08/08 04:46:05.03 NnYmcXUx0.net
4

8:名無しさん@編集中
18/08/08 04:46:21.78 NnYmcXUx0.net
5

9:名無しさん@編集中
18/08/08 04:46:37.81 NnYmcXUx0.net
6

10:名無しさん@編集中
18/08/08 04:46:53.94 NnYmcXUx0.net
7

11:名無しさん@編集中
18/08/08 04:47:17.84 NnYmcXUx0.net
8

12:名無しさん@編集中
18/08/08 04:48:11.70 NnYmcXUx0.net
9

13:名無しさん@編集中
18/08/08 04:49:01.04 NnYmcXUx0.net
10

14:名無しさん@編集中
18/08/08 04:49:16.94 NnYmcXUx0.net
11

15:名無しさん@編集中
18/08/08 04:50:03.71 NnYmcXUx0.net
12

16:名無しさん@編集中
18/08/08 04:50:26.11 NnYmcXUx0.net
13

17:名無しさん@編集中
18/08/08 04:52:05.80 NnYmcXUx0.net
14

18:名無しさん@編集中
18/08/08 04:52:21.60 NnYmcXUx0.net
15

19:名無しさん@編集中
18/08/08 04:52:37.21 NnYmcXUx0.net
16

20:名無しさん@編集中
18/08/08 04:53:33.62 NnYmcXUx0.net
17

21:名無しさん@編集中
18/08/08 04:53:50.54 NnYmcXUx0.net
18

22:名無しさん@編集中
18/08/08 05:04:32.81 7j4al10Ud.net
QSVスレとかに筋通してるのか?

23:名無しさん@編集中
18/08/08 08:58:16.68 sLAum6/L00808.net
>>21
((((;゚Д゚)))))))

24:名無しさん@編集中
18/08/08 12:45:44.53 6VYiCY4d00808.net
>>21
どこの組の方ですかage?

25:名無しさん@編集中
18/08/08 12:57:33.55 UgZyISBQ00808.net
婬手瑠組です

26:名無しさん@編集中
18/08/08 13:02:01.81 b+wpPJh000808.net
nvencはyuv420エンコ出来るようにして欲しい

27:名無しさん@編集中
18/08/08 13:21:07.59 Z+uV4B1x00808.net
多分に既存スレと重複するスレ立てするなら、統合持ちかけるなり勧誘するなりして既存スレの次スレのタイミングで立てるなりしないと、ニッチな内容のスレほど書き込み分散して過疎化で共倒れしたりもする
内容の重複するスレは、後から立てる方がそういう手間をするのが2ch時代からの流儀
関連スレのリンクも無いから、そういうスレが有るかのチェックもせずに立てた様にしか見えないから指摘したまで

28:名無しさん@編集中
18/08/08 13:21:55.85 Z+uV4B1x00808.net
>>25
出来るだろ

29:名無しさん@編集中
18/08/08 13:43:59.77 BIbDOhMd00808.net
え、QSVスレってあるの?

30:名無しさん@編集中
18/08/08 13:59:25.41 Z+uV4B1x00808.net
何年も前から有るってのw
そして論議も無くQSVスレにコッチのアドレスいきなり放り込んで向こうでも怒られてる始末
当たり前だわな

31:名無しさん@編集中
18/08/08 14:49:04.74 YproHzAT00808.net
yuv420p10の事

32:名無しさん@編集中
18/08/08 14:56:48.91 pFTXtSt000808.net
>>30
ワロタ
そんな省略されても誰も分からんわw

33:名無しさん@編集中
18/08/08 14:59:23.11 YproHzAT00808.net
経験者なら分かると思ったから

34:名無しさん@編集中
18/08/08 16:38:58.83 g6GuMzoE00808.net
君の経験が浅いのはよくわかった

35:名無しさん@編集中
18/08/08 16:42:03.50 YproHzAT00808.net
p010にしかならないでしょ?

36:名無しさん@編集中
18/08/08 18:45:29.51 IqNf1jbw00808.net
 
次世代ビデオコーデックスレのために作ったテンプレが丸パクリされたでござる・・・。
まぁそれはいいんだけど、QSVスレは既にあるんだからQSVを除くか、
せめて関連スレにQSVスレ入れるくらいはすればいいのに。
  【Intel】 Quick Sync Video Part.7 【QSV】
  スレリンク(avi板)

37:名無しさん@編集中
18/08/08 18:52:06.58 IqNf1jbw00808.net
>>34
マジレスする前に聞いておきたいんだけど、何を見てどう考えて「p010にしかならない」と判断したの?

38:名無しさん@編集中
18/08/08 19:05:59.05 tGVjs11i00808.net
どこかにそう解説してたページがあったから
単純にHDRのメタデータ埋め込んでも再生出来なかったから調べたんだけど
マジレスに期待してる
ご教示頂きたい

39:名無しさん@編集中
18/08/08 19:06:56.32 tGVjs11i00808.net
使ってるのはgtx1060

40:名無しさん@編集中
18/08/08 19:23:36.65 arlQhxab00808.net
10bitエンコはNVEncで普通にできるでしょ
-c hevc --profile main10
これでエンコしまくってるよ

41:名無しさん@編集中
18/08/08 19:33:32.54 tGVjs11i00808.net
いやそういう事じゃなくて

42:名無しさん@編集中
18/08/08 19:36:29.65 arlQhxab00808.net
どういうこと?w

43:名無しさん@編集中
18/08/08 19:46:15.91 arlQhxab00808.net
>>34
あ、これ見落としてた
>>37
俺も君がどう勘違いしたのかには興味があるから、是非その解説ページを教えてくれ

44:名無しさん@編集中
18/08/08 19:50:39.96 tGVjs11i00808.net
勘違いなの?
>>39でエンコした結果p010にしかなってないんじゃないのかな

45:名無しさん@編集中
18/08/08 19:53:04.54 tGVjs11i00808.net
あ、ブックマークつけてないからもうどこだったか分からない
申し訳ない

46:名無しさん@編集中
18/08/08 19:54:38.06 arlQhxab00808.net
>>43
p010は無圧縮10bitYUV420データのメモリレイアウトの名前
圧縮されたデータとは関係ない

47:名無しさん@編集中
18/08/08 19:58:52.99 IqNf1jbw00808.net
>>37
URLが無いとわからんが、多分解説ページの意味をお前さんが理解できなかったかだけだろう・・・。
 yuv420p10 : (一般的には)10bit深度のYUV4:2:0形式のこと。
 p010     : 10bit深度のYUV4:2:0形式のデータフォーマット(Y/U/Vの並べ方も含めた規定)の1つ。P010でググれ。
「形式」と「データフォーマット」を混同してる時点で根本的に勘違いしていることがわかる。
>>39が書いてるとおり、NVEncのH.265で10bit4:2:0のエンコードはできる。
H.265の圧縮データをデコードしてYUVに戻す時にP010というデータフォーマットにするのか、
別のデータフォーマットにするのかはデコーダとかの設定次第。
ついでに言うと、10bit深度であっても、HDRであるとは限らないので、
なんでHDRのメタデータを埋め込むなんて話が出てきたのかもよくわからない。
思い込みでソフトのバグや問題だと決めつけるのは初心者にありがちなことだけど、
何をどうやってエンコしてどういうもので再生しようとして再生できなかったのかなど、
ちゃんと詳細を書いて質問したほうがいいと思うよ。

48:名無しさん@編集中
18/08/08 20:04:25.57 IqNf1jbw00808.net
というかスレ立てた人とワッチョイが酷似してることに気づいたけど、同じ人なんだろうか。
もしかしてこの質問をしたいだけでスレ立てたのか・・・?

49:名無しさん@編集中
18/08/08 20:59:42.02 Z+uV4B1x00808.net
要は昨今多い内輪以外にもいきなり主語省略で話し出す手合いか
そりゃ思慮に欠けてる書き込みしか出来ないわな
そもそもnvencは低レイテンシの映像配信用のエンコードエンジンだから、根本的に圧縮コーデックで出力する事しか考えられていない
あくまでそういう用途のハードウェアエンコーダを転用して利用しているだけなんだし
既に3.5世代目になってもその路線崩さないから、今後も望み薄
単なる色空間的な変換とかそういう用途に使いたいなら、他を当たるかソフトウェアでやれと

50:名無しさん@編集中
18/08/08 21:20:31.26 p/pe9GS200808.net
結局のところ何がしたかったのかわからない

51:名無しさん@編集中
18/08/09 18:26:38.09 tMqheFDJ0.net
普通にQSVは向こうでNVENCとAMD VCEはこのスレでやれ�


52:ホええんちゃうん



53:名無しさん@編集中
18/08/09 18:45:06.69 CTzR29v+0.net
スパーズはどこでやればいいですか

54:名無しさん@編集中
18/08/09 18:50:13.92 6Ho9t3qW0.net
QSVについては専用スレがあるので、込み入った話はこちらへ とかでテンプレにURL張って、むこうにもその旨書き込んでおけば良かっただけんだけど
関連スレの有無も確認せず、この手のスレの立ち上げに必要な諸情報も簡便なのすら無いからな

55:名無しさん@編集中
18/08/10 16:02:36.68 HoPYm3mjd.net
どこかのスレにテンプレ丸々コピーされたとか書いてあったなw
元はどこなんだろ

56:名無しさん@編集中
18/08/10 17:20:17.03 T84aDOTf0.net
>>53
>>35
次世代ビデオコーデック総合スレPart2 【HEVC/VP9/AV1/VVC等】
スレリンク(avi板)

57:名無しさん@編集中
18/08/15 22:41:07.00 btpZ+ZRu0.net
俺今までNVEncはCRFモードをサポートしていないと思っていたけど、
--vbr-qualityを設定すれば良かったんだな
知らなくてずっとビットレート設定してた・・・

58:名無しさん@編集中
18/08/17 13:45:54.50 TJRwI7N20.net
GUIに毒されすぎやな

59:名無しさん@編集中
18/08/17 15:24:09.61 8EF2z3JOM.net
CUIに飼いならされた犬よりはマシ

60:名無しさん@編集中
18/08/18 23:28:41.45 6qFeImMv0.net
>>55
> --vbrhq 0 --vbr-quality 32
この使い方は知らなかった

61:名無しさん@編集中
18/08/21 07:15:14.35 yqsVs0ST0.net
Deploy an 8K HEVC pipeline using Amazon EC2 P3 instances with AWS Batch
URLリンク(aws.amazon.com)

62:名無しさん@編集中
18/08/22 02:33:39.49 Z+hOLHXS0.net
一体いくらかかるんだろうw
MSのAzureにも似たサービスあるけど、あっちはMS独自のエンコーダーだったかな

63:名無しさん@編集中
18/08/22 07:55:19.18 GavI77zZ0.net
URLリンク(www.anandtech.com)

64:名無しさん@編集中
18/08/22 07:56:33.50 GavI77zZ0.net
ビデオエンコーダブロックNVENCはTuring用に更新されています。
NVENCの最新の反復では、特に8K HEVCエンコーディングのサポートが追加されています。
一方、NVIDIAはエンコーダの品質をさらに向上させることができ、これまでと同様の品質を25%低いビデオビットレートで達成することができます。
NEVCでB-FRAME使えるのかな??

65:名無しさん@編集中
18/08/22 12:30:51.90 BmdgRtst0.net
いつも思うけどハードエンコの開発元はPSNRなりのデータ出して欲しいね
ソフトウェアならデータ出してるとこ多いのに

66:名無しさん@編集中
18/08/22 14:06:24.68 6MU2DjnS0.net
狙い目はRTX2080か

67:名無しさん@編集中
18/08/23 07:31:13.62 rfE9DtyV0.net
Pascal世代でもマクロブロックの捜査処理部の性能向上だけでHEVCの画質上げてたからな
Maxwellで同じプロセスルールのまま動作クロックとワットパフォーマンスをKeplerから馬鹿みたいに向上させてみたり
地味にnvidiaの回路設計技術は変態の域

68:名無しさん@編集中
18/08/23 11:45:58.09 7cheRLu0a.net
NVIDIAはBフレを軽視しすぎている
というか規格に対する準拠意識が低い



69:回発表のチューリングで、そのあたりがどこまで改善されるのか



70:名無しさん@編集中
18/08/23 12:12:20.69 JCmRqS+kd.net
HWエンコでBフレ有りだと明らかに劣化する上、速度が遅いから要らんな
永久保存したいならSWエンコしなさいよ

71:名無しさん@編集中
18/08/23 12:55:31.52 7cheRLu0a.net
そんなもん、エンコーダーの出来が糞なだけだ
「Bフレを有効にする=画質劣化」ではない

72:名無しさん@編集中
18/08/23 16:35:20.50 YcdR2YjvF.net
Bフレ有りHWエンコが糞な事に変わりなし

73:名無しさん@編集中
18/08/23 17:23:49.57 rfE9DtyV0.net
>>68
規格的にBフレ使用義務なんて無いが?
規格準拠とか言いつつ糞も理解してないだろ

74:名無しさん@編集中
18/08/23 17:24:53.98 LeoZTWXta.net
追加して汚くなるって何なんだよ……w

75:名無しさん@編集中
18/08/23 18:25:40.40 0qSSdGG/H.net
>>69
現状の実装だけみてハードウェアエンコーダは汚いと言い切るのは、さすがにどうかしている
実装次第だからな
ソフトウェアであっても実装がクソなエンコーダならば汚いことに変わりはない
ハードウェアかソフトウェアかだけで語るのは無意味

76:名無しさん@編集中
18/08/23 18:56:03.23 dvM35vUkd.net
>>72
現状の実装以外に何を語るの?未来人なの?
1人だけ勝手にSWエンコ時もBフレが汚い話に捉えてるけど、おまえ以外はHWエンコ時の話しかしてないよ

77:名無しさん@編集中
18/08/23 19:30:18.06 7cheRLu0a.net
敵は常に一人タイプか…

78:名無しさん@編集中
18/08/23 19:55:59.68 bJgeH7qy0.net
少なくともQSVのH.264(LA-ICQ)でエンコしてSSIMやVMAFで評価した場合は、
BフレームとBピラミッド無し(--bframes 0)にすると、かなり酷いレベルで圧縮効率が低下するんだけどな。
(ちなみにデフォルトだと--brframes 3 --b-pyramid)
 QSV-H.264-LAICQ_Bフレーム有無の差
 URLリンク(2sen.dip.jp)
>>67>>69のように「BフレありのHWエンコは劣化が酷い」みたいに言ってる人は、
どのHWエンコーダのどのコーデックで、どのように評価してそう言ってるんだろ?
他にBフレームが使えるHWエンコというと、
 ・QSVのH.265
 ・NVEncのH.264
 ・VCEのH.264 (Polarisより古いハードのみ?)
のいずれかだが・・・。

79:名無しさん@編集中
18/08/25 08:51:46.65 A+XxIkPU0.net
どーせアニメだろw

80:名無しさん@編集中
18/08/25 10:37:27.22 mS1Jre1Jd.net
圧縮効率が何で画質の悪さと関係あるんだよ
映像見て語れよ

81:名無しさん@編集中
18/08/25 11:10:16.68 Fz8j+osy0.net
>>76
面倒くさい奴だな・・・。
一応crowd_runでも調べてやったけど、Bフレ無しだと圧縮効率が下がることに変わりはないぞ。
 QSV-H.264-LAICQ_Bフレーム有無の差_crowd_run
 URLリンク(2sen.dip.jp)
 ソース: URLリンク(media.xiph.org)

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

82:名無しさん@編集中
18/08/25 12:19:30.24 mS1Jre1Jd.net
何で同じビットレートで比べないの?アホなの?

83:名無しさん@編集中
18/08/25 12:54:51.04 Fz8j+osy0.net
>>79
最低限の情報も出さず、まともな説明もしないお前の方がアホだと思うが・・・。
もしかしてグラフの意味を理解できてないのか?
同じビットレートで比較したいなら、同一ビットレートでのSSIMの値を見て比較すればいいだけなんだが。
SSIMでの客観評価じゃなく、同一ビットレートでの主観評価をしろってことなら、俺はそこまでやる気はないんで
「Bフレ有効だと画質が悪い」と主張するお前がテストして、その結果を示せばいいと思うけど。
それ以前に
  ・どのようなソースを
  ・どのHWエンコーダの
  ・どのコーデックで
  ・どのような条件でどのように評価した結果、Bフレありだと画質が悪いと主張しているのか
をちゃんと書いたほうがいいと思うけどね。そういった情報も無しにただ喚かれても、話にならんだろ。

84:名無しさん@編集中
18/08/25 13:04:32.35 mS1Jre1Jd.net
やる気ないってwww
エンコしてるならその映像見てグラフと一緒に示せば完全論破でドヤ顔出来るのに、しないのが証拠だろ?

85:名無しさん@編集中
18/08/25 13:40:40.56 ABEpDGdUM.net
頭悪…

86:名無しさん@編集中
18/08/25 13:54:05.89 Fz8j+osy0.net
最低限の情報すら頑なに出さないアホの探偵ごっこか・・・。
目の前にある事実を無視して、わざわざ遠くにある迷宮に入りにいって帰ってこないタイプなんだろうな・・・。

87:名無しさん@編集中
18/08/25 14:10:51.00 DovDn/Ya0.net
いや、単純にSSIMやグラフの見方が分からないだけだと思う・・・

88:名無しさん@編集中
18/08/25 14:35:44.36 mS1Jre1Jd.net
>>83=84
とうとう自演しやがったwww
全角の使い方でバレバレ

89:名無しさん@編集中
18/08/25 15:36:05.17 M6Y4pqeA0.net
>>83-84
ワッチョイ b9ec-PcWx
ワッチョイ 29c3-PcWx
くっさww

90:名無しさん@編集中
18/08/25 16:35:38.35 nJe+uVbx0.net
ワッチョイの下4桁はUserAgentで決まるから被ってもおかしくないはず
PcWxはMonazilla/1.00 JaneStyle/4.00 Windows/10.0.17134らしいから利用者も多いだろうし

91:名無しさん@編集中
18/08/25 16:43:08.51 M6Y4pqeA0.net
たまたまこんな過疎スレで全角もワッチョイも被って
たまたまレスが並ぶなんて珍しい事が起きたんだね
なるほど~

92:名無しさん@編集中
18/08/25 17:00:29.06 DovDn/Ya0.net
JaneStyle使ってるだけで同じ人扱いされるとは・・・俺はずっと↓このIDだから
URLリンク(hissi.org)
>>88
君はもう少し勉強してからレスしような

93:名無しさん@編集中
18/08/25 17:35:59.42 DovDn/Ya0.net
NVEncの固定品質(>>58)試してるんだけど、どうもコレ内部では
ビットレート指定VBRと全く同じモードで動いてるっぽい
(少なくともGTX1060では)
ビットレート指定VBRと画質が全然変わらなかった
実写、アニメ、前半実写で後半アニメの3つくらいでエンコしてSSIM測って
SSIM-ビットレートをプロットしたら全部同じ線上に並んでしまった
という訳で今の所使う意味なさそう
次のTuringでは良くなるのかなぁ

94:名無しさん@編集中
18/08/25 17:36:37.74 k4YhneCR0.net
んなもんソースによる、一概な答えしか容認出来ない馬鹿は頬っておけ

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

96:名無しさん@編集中
18/08/25 18:04:54.22 OpoSyjzx0.net
>>90
mpc-hcでビットレート観測するのが簡単
なんか、どっかでも書いたけど3Mbpsとか比較的十分にビットレートを使ってたら画質差は出にくい

97:名無しさん@編集中
18/08/25 19:10:57.61 DovDn/Ya0.net
あれ、でもやっぱりビットレート分布は全然違った
ビットレート指定VBRと同じではなかった
ビットレート分布が変わっても平均するとプラマイゼロでSSIMは変わらないのか・・・

98:名無しさん@編集中
18/08/25 19:11:18.75 M6Y4pqeA0.net
>>83
分かったからID:Fz8j+osy0 連れて来いよww

99:名無しさん@編集中
18/08/25 19:23:10.26 DovDn/Ya0.net
NVEncの固定品質はちゃんと固定品質になってた
↓最初4分の1が実写で以降アニメの動画をエンコードしてCheckBitrateでビットレート分布出した
URLリンク(i.imgur.com)
SSIMはほぼ同じだったけどSSIMはそういうものなのかな
まぁでも固定品質がちゃんと使えることは分かったわ
これからは固定品質一択だね
ビットレート指定VBRなんて必要ないわ

100:名無しさん@編集中
18/08/25 19:56:16.56 DovDn/Ya0.net
>>92
Tensorコアでリアルタイムwaifu2xに期待

101:名無しさん@編集中
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
ビットレート指定モードの一部が固定品質モードってのはなんか分かりにくいなw

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にしたらまともな品質にならない」みたいな検証が既にされてるのであれば
淡々とその結果を示してあげればいいと思うけど、これ以上続けたいなら
そろそろ画像拡大スレに移ったほうがいいんじゃないかとは思う。
 【超解像】画像拡大ソフト総合スレ2【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
どーせアニメだろw
122 名無しさん@編集中 (ワッチョイWW ea84-/kQw) sage 2018/08/27(月) 10:48:37.03 ID:KSUuDcZo0
紙芝居のためにご苦労さま
この間46レスと50時間w

131:名無しさん@編集中
18/09/02 19:42:33.51 DuBTtQDB0.net
        
    r ‐、                   
    | ○ |         r‐‐、      良い子の諸君!
   _,;ト - イ、      ∧l☆│∧   
 (⌒`    ⌒ヽ   /,、,,ト.-イ/,、 l.   証拠を要求するネトヲタがいるが
  |ヽ  ~~⌒γ⌒) r'⌒ `i´ `⌒)   君がいくら証拠を開示しても
 │ ヽー―'^ー-' ( ⌒γ⌒~~ /|  そのネトヲタは絶対信じないぞ!
 │  〉    |│  |`ー^ー― 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の例で
  A: --brframes 0
  B:--brframes 3 --b-pyramid
を比較すると
  A:3000kbps→B:2100kbps = 30%のビットレート削減 (SSIM=0.988ライン)
  A:36000kbps→B:30000kbps = 17%のビットレート削減 (SSIM=0.92ライン)
になってるけどな。
NVENCのH.264で同様の調査をしてくれる人がいるといいんだが。

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

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

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

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

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

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

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

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

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

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

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

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

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

201:名無しさん@編集中
18/10/14 03:18:47.39 v7cF/vO60.net
>>191
いや、>>190は可逆圧縮したAVIファイルをNVEncCで読み込んで
--vpp-resizeや--output-resを使ってリサイズ&エンコードしたいってことでしょ。
--losslessにしたいのかどうかは知らんけど。
>>190
その質問をするなら可逆圧縮に使ったコーデック名(必要ならその設定も)をちゃんと書くべきだと思うが・・・。
まあ一応答えるけど、AMVシリーズなら --avi で読み込めばよさそうだし、avs経由で--avs読みするという手もある。
UtVideoならffmpegで対応してるから、上の手法に加えて--avswでも読めると思う。
ただ、どんな編集ソフト使ってるのか知らないけど、そもそも可逆圧縮AVIを挟む意味あるの?
カットも字幕もAviUtlでやって、NVEnc.auoで出力すればいいだけのような・・・。

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

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

204:名無しさん@編集中
18/10/14 21:30:04.16 kbRq5SJT0.net
>>194
自分が一番こだわっているのがHWエンコの速度という部分でして、以前のどこかで質問した時に
Aviutlはデコードの部分に時間がかかると聞きました
だったら最終的な仕上げだけnvenccでやれば良いのでは?と考えに至り
何分使用しているPCが何世代も前のi5、グラボがgtx1050tiという貧弱構成でして・・・
2kや4kの拡大の件も苦肉の策といいますか、やってるゲームをyoutubeにアップしているんですが
1080pであげた物と2kや4kで上げてVP9でエンコされた物を目視で比較するとVP9のほうが綺麗だなと
なぜかは知りませんがエフェクトが激しい場面での破綻がより少ないカンジに見えました
同じ素材をx264(ソフト)やnvenc(ハード)でyoutubeにupしても、2kや4kでupしたVP9の動画のほうが綺麗に見える。
これはもうyoutube側の仕様なのかな?という結論に至り(自分の中で)
正直いいますと2kや4kにはあまりこだわっていないんです
動画編集をやってエンコードを調べていくほど「知りたい」
と思った次第であります、丁寧にお返事ありがとうございます。

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

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

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


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



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

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

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

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

213:名無しさん@編集中
18/10/16 17:00:16.15 5Qu0m5+G0.net
>>195
> 1080pであげた物と2kや4kで上げてVP9でエンコされた物を目視で比較するとVP9のほうが綺麗
・1080pと2kって同じものでは?
・どれとどれを比較したのかよくわからん。
  ・1080p投稿→H.264/1080p再エンコ
  ・1080p投稿→VP9/1080p再エンコ
  ・4K拡大投稿→VP9/4K(2160p)再エンコ
  ・4K拡大投稿→VP9/1080p再エンコ
・比較条件もよくわからん。4K拡大投稿して4K再エンコされたものを1080p縮小状態で見たら綺麗だったという話なら、
 そりゃそうなることが多いだろうという感じだが。
>>199
> VP9の方が後発なんだから当たり前
そんなわけない。
ビットレートの違いもあるから、H.264よりVP9の方が汚いことも普通にある。

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

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

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

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

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

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


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



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

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

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

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

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

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

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

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

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

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

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

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

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


234:I



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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



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

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

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

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

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

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

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

262:名無しさん@編集中
18/10/25 17:26:52.29 rQ/d4Tyo0.net
>>244
ありがと。それはどの機種での数値だろ?
できれば結果全体をpaste.binあたりに貼ってもらえると嬉しい。
(調べた人が0って意味じゃないよね?)
>>245
NVEncのH.264ではBフレ対応してるし、低レイテンシ重視の時はBフレ切ればいいだけだと思うけどね。
まあH.265でいまだにBフレ対応してないってのは何か理由があるんだろうけども。
>>247
原理的にはH.264よりもH.265の方がデコード自体は軽いと聞いた気がする。
ただ、H.264は既にほとんどの環境でHW再生支援が効くのに対して
H.265は少し前の環境だとHW再生支援が無いことも多いので、そのあたりの差はでてくる。
そのへんを気にするならH.264を使った方がいいと思うよ。

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

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

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

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

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

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


269:がありますなぁ



270:名無しさん@編集中
18/10/26 20:48:35.08 4O36bTgr0.net
NVEncCのデフォだとBフレーム使ってくれないけど、 -b 5 とか指定すればちゃんと使ってくれた
frame type IDR 59
frame type I 59, total size 6.44 MB
frame type P 871, total size 36.53 MB
frame type B 4297, total size 51.27 MB

271:名無しさん@編集中
18/10/26 21:53:48.42 5tUyQmet0.net
同ビットレートでの画質差を・・・

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

301:名無しさん@編集中
18/10/28 02:46:51.15 mrO/Sdoo0.net
実写に関しては「x265」と「x264」がほぼ同点のトップ3タイと言っていい感じかな
次点で「2070 B=3 HEVC main10」と「QSV H264」が同じようなSSIMだが、全体としては
「2070 B=3 HEVC main10」のほうが若干優勢
おそ�


302:轤ュよりビットレートを高く設定できる場合になればなるほど「2070 B=3 HEVC main10」のほうが 優勢になりそうな傾向 ※「2070 B=3 HEVC main10」で12000kbps以上ならば「x265」や「x264」と相当いい勝負になりそうな傾向 「QSV HEVC」は実写でも出る幕ないね 意外だったのが、「1060 HEVC main10」 アニメでは中位につけるも、実写では下位グループと振るわず 全体として、ギリギリまでファイル容量を削減したいのであれば「x265」で詰めるべきだろうけど、そこまで削減する 必要はなく、それよりも高速で処理できるほうがいいというのであれば、「2070 B=3 HEVC main10」でビットレートを x265比で2割増し程度にする設定にしておけば、もはや十分な結果が得られると言えるのではないだろうか



303:名無しさん@編集中
18/10/28 11:08:35.72 ftI7zJ8S0.net
>>281
ありがたい
実写は何使ってもSSIM厳しいなー

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

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

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

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


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