【NVENC/VCE】ハードウェアエンコーダーを語るスレ3【QSV】
■ このスレッドは過去ログ倉庫に格納されています
>>775
OBSは、いろいろおかしいから信頼性がない Bブレ対応としては最安だけどもう一声あっても良い感じね >>754
それ、たかが100Mbpsじゃねーか。 >>775
OBS公式のそのまま使ってない？
OBSでffmpeg 使いたいなら自分でビルドしたほうがいいよ 1650ｓのビデオ関連コアが1660と同等だといいのにね
一番早いのは22日発売予定だったそうだから、そろそろ買って報告してくれる人出てこないかな。
まぁ私が買うとしたら4ヶ月位後になるんだけれど。 >>782
公式の仕様くらい見ようぜ
NVIDIA Encoder (NVENC) 対応 (Turing) >>783
ああ、言葉が足りなくてごめん
そこはこのスレで出て来てるから理解しているけど、駆動クロック数とかが落とされていたら
悩ましいなって思って書いたんだ。
GPUコアのクロックはともかく、ビデオ用のコア部分はどうなのかなとか 今時別クロックでなんて動いてないぞ
ビデコアの部分はGPUコアクロックに依存する 非ブーストクロック依存じゃないの？
ブースト時はコアまわりだけクロックが上がる 今の8K放送ってRAWの1/1000のサイズのビットレートで放送してるんだな。
H.265とは言えとんでもねー圧縮率だわ。 >>788 は、冗長性って言葉を理解できてないだけの奴なんだろ >>790
8k4k放送で冗長性を持たせる為に使われている 16APSKの冗長符号化は
外符号 BCH符号、内符号 LDPC符号だから、
映像符号化のH.265とは何も関係ないぞ。 >>791
> 8k4k放送で冗長性を持たせる為に使われている 16APSKの冗長符号化は
それ、放送信号のエラー訂正するための冗長化の話だからな
コンテンツの圧縮に関わる冗長性とは、そりゃ何の関係もないだろうよ
冗長性で必死にググった挙句、当たり前に無関係なレスしてツッコミが成立してると思って悦に浸ってたの？ >>795
符号化を理解していないようだから、まずはシャノンの定理から勉強しよう。
H.265は非可逆圧縮だから、冗長性は無いよ。 元からエラー訂正の事を言ってるように見えるんだが
H265は何処から出てきたの？ >>798
1030みたいにNVENC自体消えてそう それは困る
ゲームしないでエンコ主体だからビデオ性能はそこそこでNVEncに力入れたビデオカードが欲しい ハードエンコにあえてVCEを選ぶ人ってどんな人？
QSVはビデオカード使いたくない人とかって何となく分かるんだけど radeonしか持ってない人
正直、HWエンコ（NVEnc）の性能がこんな上がるとは思ってなかったし
性能は470程度あれば不自由しないから買い替えるほどでもないって感じ ３万切ったので1660Ti購入
HEVC Bフレ良いね QSVは未だにHWエンコでならH264で一番画質容量比が良いから、エンコード成果をHEVC非対応の環境での再生対応等でH264縛りな人には悪くは無いよ
Turing世代のNVEncでもH264の画質性能的にQSVにギリ追い付いていないし VCEは処理速度がQSV並で、画質は初期のNVEnc並かそれ以下 そのうえNAVIで微妙に画質容量比性能落ちてるしな
多分事前発表の処理速度確保するために、想定した7nmでのエンジン動作クロックが不足している分、マクロブロック配置検討の処理を従来世代より少し甘くして処理速度確保してる臭い
RADEON買ったついでに有るから使う以外の意義は無くて、ましてやVCE（VCN）狙いでRADEON買うってのはまず無い
古井戸狙いで550買うとかの方がまだ購入理由になる罠 Radeonはラジャ・コドゥリをIntelに取られた時点で終わったんだよ >>796
> H.265は非可逆圧縮だから、冗長性は無いよ。
冗長性がなかったら圧縮不可能なんだが。可逆か非可逆かは関係がない。
お前は、符号化以前に、圧縮に関して基礎から勉強する必要があるぞ
>>797
そりゃ、 >>787 からの話の流れでしょ。 冗長性を無くしてしまうのが、非可逆圧縮。
人間が見て違和感がない限界ギリギリまでデータをそぎ落としていく。
データそのものは劣化する。それがH.265の映像符号化技術。
FLACなどの可逆圧縮は、冗長性の重複部分を纏める事でデータサイズを圧縮している。
冗長性は失われないのでデータは劣化しないが、冗長性は足されない。
冗長性を足して圧縮する機能ってのは、WinRARのリカバリレコードが有名かな？
>>811
その分野の人間か知らんが、通信・情報システム関係でそんな事言っていると恥ずかしいよ。
まずはシャノンの標本化定理から勉強してこい。このデジタル社会の基礎だ。 全くもってどうでもいい言い争い
俺の方がスゲーって言いたいだけでしょ まぁ頓珍漢なこと言ってるバカ認識間違ってたと認めて謝罪しとけ
素直に誤りを認めて改めることでまともになんだし 「こんきょはありません。わかりません。誰が決めたのかもわかりません。」 H.264とH.265で同等画質になるようにエンコして画質を見比べてみたけど、俺の目だと画質の違いがわからない・・・
でもファイルサイズが2.5倍ほど違うからH.264はもうお役御免だな >>816
そら同等画質になるようにエンコすればそうだろうよっ！ｗ
強いて言うなら、HWデコード前提の場合に限りHEVCは10bitが使えるので、バンディング低減処理が活きてくるくらいかな
背景が暗めのトーンのシーンなどは違いが判り易い >>812
> 冗長性を無くしてしまうのが、非可逆圧縮。
冗長性を減らすのが「圧縮」。
不可逆か、可逆かは、元に戻せるか戻せないかの差があるだけで冗長性とは関係がない。
> 冗長性は失われないのでデータは劣化しないが、冗長性は足されない。
それは違う。
もっと簡単に言えば、圧縮できないほど無駄がない状態が「冗長性がない」状態で、
さらにどれだけ圧縮が効くかってのが冗長性がどれほどあるかって話。
>>790 で言われてる通り、お前さんは「冗長性」って言葉を正しく理解してないだけか、
逆に、指摘された内容をごまかすために、本質的には関係のない符号化の話とエラー訂正の話を織り交ぜて
マウント取って逃亡しようとしてるか、のどっちかにしか見えない。
前者にしろ後者にしろ、俺はお前の方が恥ずかしいレスしてると思うが。 揚げ足は取ったほうが負けだからな
反論できなくなって余裕が無くなった負け犬になった証拠だから
取られる方が基本的に間違ってないことの証明。 発端が冗長性関係ない当たりでスルーすればいいのにな エンコードの品質を上げるためにはまずデコードの段階で品質が良くないと駄目って考えてるけど合ってる？
ソフトウェアデコードの後にハードウェアエンコードが一番高画質かもしれない h.264/HEVCはデコード誤差が出ないように整数使うようになったから
元ソースがmpeg2の場合を除いて気にする必要はない >>820
別に、勝ち負けでレスしてんじゃないし負けでもいいのだが、それ本当に揚げ足とりなのか？
揚げ足ってのは、わざわざツッコミ入れるまでもない「明らかな間違い」のことだと俺は思うのだが？
今回の場合はそんなんじゃなくて、>>818 の最後で書いたとおり、
本当に理解してないか、ごまかそうとしたか、のどっちにしか見えなかったのだが。
それ、本当に揚げ足か？ まだ言っているのか
冗長性という言葉が、情報・通信・PC業界でどう使われているか知らなかっただけだろ？
冗長性は英語では以下の通り。alcより引用
redundancy
1.余剰性、余剰が［過剰で］あること
2.《電気》〔回路の〕重複性、冗長性◆バックアップ用の回路を用意すること。
3.〔通信における情報の〕冗長性、冗長度
1番の意味で使っていると恥ずかしいと気付いてくれ。 ツクモ店頭で戯画のGV-N1660OC-6Gが税込22000円で売ってたので、エンコ用に買ってしまった。1650Sの予定だったけどこちらのほうが安かった。 >>826
> 冗長性という言葉が、情報・通信・PC業界でどう使われているか知らなかっただけだろ？
おお。明らかにごまかし始めたな。>>787 のレスでいうと「冗長性」がどういう意味か、だぞ。
業界的にはどうでもいい。
というか、そこがお前にとっての話題の逸らしポイントだもんな。 >>791 の時点から、ずっとそれ。
> 1番の意味で使っていると恥ずかしいと気付いてくれ。
無理がある引用だったな。「冗長性」を英単語にした時の意味なんだろ？
日本語なら、「冗長性」って言葉だけで「余剰性が過剰」って意味になる使い方は思いつかんけど。
その時点で、その意味で使いようがないのに「１番の意味で使うのは恥ずかしい」、って何かのギャグかな？
普通に言いたいなら、「冗長だ」で良いからな。
自分に向いたツッコミは何一つ認めずに話題をそらすも、次々とボロが出てるけど、
そんなお前の状態の方が、よっぽど恥ずかしい状態だと思うんだが、まだ続けるの？ 1660とゲーム用にメインで使ってる2080ti比べるとエンコーダ自体は変わらない速度が出るけどCUDAでデインタレ処理すると結構差が出るな。
1440iの地デジソースをHEVCエンコードするときAmatsukazeでKFM使うと1660で150fpsくらいだが2080tiだと300fps程度でる。 ゲームの配信って自分がプレイした動画をみんなに見てもらうこと？
ほらほら俺こんなにすごいプレイしたよ、とか、こんなに高得点出したよ、とか 動画投稿サイトでアップロードして承認欲求を満たすんだぞ ようつべなんかゲームプレイ動画も収益はがされたらしいね
当たり前っちゃ当たり前なんだが 自宅に呼んだ友達にゲームプレイを見せている感覚で、Mixerで配信しつつDiscordで会話しているよ。
NVEncのLow Latencyと組み合わせるとMixerは0.3秒位しか配信遅延しない。配信専用に1650積んでる。
2080ti側のNVEncはShadowPlay動かして、スーパープレイや爆笑プレイを簡単に保存できるようにしている。
もちろん保存先は記憶域で双方向ミラーにして冗長性を持たせているよｗ 別にスゴいプレイでなくてもいい
初見プレイと称してやっとるのもいるし
謎なのは同じのを毎日初見と称してやってるやつ
お前完全にパターン暗記しとるがなとｗ steamlinkでリモートプレイすんのにもNVEnc使って配信してるから便利やで
有線なら遅延もほぼ感じないしマジNVEnc有能 >>837
それ、うちのAthlon200GEでも同じこと言えんの？ 16コアあってもAmatsukazeでCUDAフィルタオフにするとそんなに早くならないのがなぁ・・・
x265自体は大満足なんだが。この時期暖房にもいいね。 そりゃCUDAで作りこまれたものなんだから
お情けでついてるCPUモードじゃ遅くてもしょうがない 家電のHDDレコーダーに使われてるのはハードウェアエンコードだから
むしろHDDエンコードの方が一般的 Intelの安いcpu買ってqsvエンコサーバ作ろうと思ってるんだけど
エンコ速度ってメモリ速度とEU数で変わるって認識で合ってる？ 元々の話のレイテンシも、OBS配信(6Mbps)では、
CPUエンコ(i9-7980XE@4.7GHz)のzerolatencyと、NVEncのMax Quality設定を比べると、
NVEncのほうが圧倒的に遅延が少なく綺麗で省エネです。
最近のNASはQSV使って、オンザフライエンコ配信出来るから、何も考えずに高ビットレートでNVEncしてNASに保存している。
ネット環境の整った出張先ならリアルタイムエンコ再生、海外や飛行機出張時は事前にNASで小サイズにエンコしておいて持ち出し。
自宅の4kテレビでは元サイズのまま再生、FHDテレビやタブレットでは1080pにリアルタイムエンコ再生と・・・ハードウェアエンコ様様です。 >>844
HDDレコーダーのエンコードとqsvとかNVcncだと画質の良さはどっちが上なんかな？ >>847
> 元々の話のレイテンシも、OBS配信(6Mbps)では、
> CPUエンコ(i9-7980XE@4.7GHz)のzerolatencyと、NVEncのMax Quality設定を比べると、
> NVEncのほうが圧倒的に遅延が少なく綺麗で省エネです。
自分では配信やってないんだけど、配信の遅延の原因って
Ａ．配信者側のエンコード処理による送出遅延（BフレとかLookaheadとかの関係でフレーム送出まで少し待ちが入るとか）
Ｂ．配信プロトコルそのものや、サーバー側での再エンコード等による遅延
の２つに大別されるとして、現状では基本的にＢの方が圧倒的にでかいから、
Ａの方は設定でよほど酷い差をつけない限りはSWエンコでもHWエンコでもあまり差は出ないんじゃないの？
基本的に両方ともZeroまたはLow Latencyにするとして、SWエンコとHWエンコで「圧倒的」というほどの遅延の差って出るもんなの？ >>849
Mixerは鯖側の遅延が最大で0.2秒なので、自分の配信を自分で見れば一目瞭然
NVEnc（Max Quality）＞＞ QSV(Quality) ＞ CPU(i9-7980XE@4.7GHz)のzerolatency
それぞれ0.3秒、0.5秒、0.8秒位のラグになるから見てわかる。 >>850
ありがと。実際にそんな差が出るものなのか。
30fpsなら1フレーム当たり0.033秒、60fpsなら1フレーム当たり0.0166秒で送り出す能力があるってことだし
そこまで差は出ないだろーとか思ってたけど、差が出る原因はエンコーダの起動時間とかなのかな？ >>851
初期化処理の差じゃないの？
デフォルト設定の違いに振り回されてそう >>852
あ、そうか。なんか言葉が出てこなかったから起動時間なんて書いちゃったけど、初期化処理か・・・。 icelakeのQSVはかなり強化されたらしいけどレビューどこかに無いかね？
探したけど見つからん 処理速度面でUHD620〜630のH264もHEVCも倍程度というぐらいしか情報無いな
画質容量比性能については皆無
H264用途とすれば従来でもTuringのNVEncより画質面で優れてはいたから、倍速化してもNVEncの速度にはまだ届かないが、差が小さくなっているのは意義がある
HEVCは倍になっても1440x1080処理で80fps程度とかだろうし、画質面でNVEnc超えてなければ遅すぎてどうもならんのよね 265のBフレ使用OKはいいものなの？
そうだというのであれば1650Sを今から買いに行こうかと 適応的な挿入が出来るわけじゃないから7nmまで待ったほうがいいと思うけど そら圧縮目的ならBフレ仕えた方がえぇに決まっとる。 >>857
GTXシリーズのミドル・ローエンド辺りが7nmプロセスに移行するのって何時頃なん？ 今の12nmでRADEONの7nmより十分効率良いからなぁ >>861
このスレでBフレ使えないからって状態のRADEONと比べてどうするんだよ。
再生のときにｍａｄＶＲとかでリアルタイム補正するならRADEON一択だぞ。 >>867
ここハードウェアエンコーダのスレなんですが
MadVR云々はスレ違いな >>866
TuringのH.265 Bフレ有り10bitと比べるならx264のpreset Fastでしょ 1280ｘ720〜1920x1080(MAX6Mbps程度)のネット配信をエンコするのに
BT2020は無駄かな？
Turingだから幸いBフレは使用可でエンコソフトはTVMW7です AMD免罪符「視覚的損失なし」をまだやってるみたいだな
PS5も変わらんらしい＝今後3，4年はやる気なし >>871
カラーグレーディングやカラースペースわからないなら触るな。709のままにしとけ。 ■ このスレッドは過去ログ倉庫に格納されています
