【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】
■ このスレッドは過去ログ倉庫に格納されています
きょーび動画がらみの機能は訴求力ない
ゲームのフレームレート至上主義や
出始めの頃はDCTだ動き補償だなんだと
並び立てて煙幕張ってたが
Rage128とかそんな頃ｗ >>297
インターレースは非対応ですか
時代の流れと言えばそれまでですが、いささか早すぎるような気もするけれど
放送はこれから先も2K以下についてはインターレースのまま継続するのだし
ただ、インターレースが動画圧縮を行う上で非効率なことは間違いないし、
再生機器でのリアルタイムインターレース解除より、QTGMCなどであらかじめ
じっくり解除しておいたほうがきれいなことは間違いないわけで
※4Kテレビなどで2K放送などをアップコンバートして表示している映像を見ると、
インターレース解除がうまくできていないことによるジャギジャギ感が目につき
気になって仕方がない 問題は、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台格安で手に
入りそうなので、手に入れば実験してみようかと思っているのだけれど… キャプチャする対象をインタレと決めつけてるけど
ソースは何を想定してるのよ？ amatsukazeはts信号処理と言ってるから放送波なんじゃね 撮影ts化する人はいないだろうから、放送波だろうな いやね、tsならファイル扱えば良い訳で
レス元のみたいなキャプチャー機器使う環境をあげてる人へのレスで、何処からインタレとかの発想出てきたのかと DVDやBDのインタレソースにAmatsukazeのKTGMC使ってみてえな >>303
QTGMCなんて只のavisynthの関数だろ？
自分でスクリプト書いて使えばいいだけ。
それが出来ないレベルなのか。 >>311
だからインタレのキャプチャなんぞDVDプレイヤーやD端子以前の旧世代の機器の出力とか、旧世代のインタレ表示機器向けの信号取り込もうとしない限り今じゃ無いでしょ
後者なら出力側をプログレにすりゃ良いのだから、わざわざインタレ出力にしてまで取り込む意味が無いし
インタレとも書いてない書き込みに付けるレスとしては謎すぎる レコとかテレビ任せのインタレ解除よりQTGMCのほうが綺麗でしょ QTGMC単体だと副作用多すぎなのでQTGMC+KFMか なんだか勘違いしている人がいるようだな
ts化するというのはAmatsukazeがtsしか受け付けないからtsで保存と言っているわけなのだが…
個人的には大事な録画をサポートはおろか何の保証もないBonDriverを使ったts録画に任せる気には
ならないので、録画はレコーダーでしているけれど
（放送局側の都合で突然仕様が変更されて録画できなくなってもどうすることもできないし）
キャプチャーは主にアナログ時代に録画したものやD-VHSで録画したものを念頭に置いている
特にD-VHSからのキャプチャーはドロップアウトとの戦いもあるから念入りにしなければならないので
まぁ一人アレルギー反応示している人がいるからこの件はクローズにしておきましょ >>318
>>（放送局側の都合で突然仕様が変更されて録画できなくなってもどうすることもできないし）
ISDB規格って知ってる？
もしPT3とかで録画出来なくなったら他の民生品レコーダーも全滅だよ。 (続き)
そこで、ffmpegではどうなっているのか念のため確認してみたかったのですが、
うちは残念ながらIntelノートなので、代わりに
H264:yuv420p/yuv444p, HEVC:yuv420p/yuv444p/yuv420p10le/yuv444p10le
の6パターンについて
ffmpeg -i yuv4**p*.y4m -pix_fmt 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等にアップロードしてもらえると
エラーが発生した場合の原因などもわかるので助かります)
よろしくお願いいたします。 ffmpegは全部対応してるけど、rigaya氏のNVEncCはh264のYUV444にしか対応してないようだね
HEVCやYUV420を使いたい場合はffmpeg使うしかないっぽい
h264のYUV444に比べてHEVCのYUV420はサイズが半分近くまで減るし >>323
ありがとうございます。環境にあわせてテストしていただいたようで申し訳ない。
ログを確認させていただきましたが、Pascal(GTX 1060)、Turing(RTX 2070)ともに、
420/444、8/10bitの全パターンでちゃんと一致したフォーマットで可逆になってますね。
YUV4:2:0でもロスレスエンコードできると考えてよさそうです。
とりあえずrigayaさんのブログに情報としてお知らせしておこうと思います。
ご協力いただき、ありがとうございました。 >>324
一応NVEnc3.05でHEVCのロスレス出力に対応しているようです。
また、現在は--losslessが指定された時点でYUV 4:4:4出力にする実装になっているようなので、
HEVCのYUV 4:4:4ロスレス出力はできるのではないかと。
NVEncのマニュアルである
https://github.com/rigaya/NVEnc/blob/master/NVEncC_Options.ja.md
の --lossless の説明には「H.264のみ」とありますが、これは修正漏れのようで、helpでは
--lossless for lossless (YUV444 only) / default: off
となっています。 >>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にならない
これ以外のオプション指定の仕方が分からない >>327
そうなると自分もちょっとわかりませんね・・・。
AviUtlから拡張NVEnc出力を使ってHEVCを選んで、readmeにあるように
「CQPでIフレーム、Bフレーム、PフレームのQP値を0にする」
で出力するのを試してみるという手もありますが、同じ結果になる可能性が高そうな・・・。 一応ロスレス出力のファイルサイズまとめ。(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 >>303などでNVEncのLOSSLESSエンコードについて書いていた者だけど、俺より先にいろいろテストしてくれている人がいるようなので
とても助かります
今、気になっていることが二つあります
1．「AVerMedia Live Gamer Ultra」をレビュー。
高画質＆高速プレイを妥協せず、手軽に快適な録画・配信環境を構築できるUSB外付け機器型ビデオキャプチャ
http://blog.livedoor.jp/wisteriear/archives/1071577199.html#more
という記事の中で紹介されている
「上のようにGPUハードウェアエンコードとCPUによるソフトウェアエンコードの間に基本的には大きな差はありませんが、
NVENCについては特定の条件下でノイズが発生する可能性があるようです。」 ・CPUエンコードの場合（問題なし）
http://livedoor.blogimg.jp/wisteriear/imgs/2/e/2e3f1b76.jpg
・NVEncによるエンコードの場合（破綻している）
http://livedoor.blogimg.jp/wisteriear/imgs/e/b/eb4742a8.jpg
・動画での確認
https://www.youtube.com/watch?v=Bzv6z2NKw5A
このノイズがLOSSLESSの場合でも発生するのかどうか？
2．上記の問題はRTX20*0（Turing）世代のGPUでも相変わらず発生するのか？
という点が気になっています
そもそもこの問題はハードウェア的にどうしようもない問題なのか、それともドライバーソフトなど含めたソフトウェアレベルで
改善出来うる問題なのか
果たして真相やいかに？ AVerMediaのAVT-C878を使ってる感じだとPS4-単体録画モードでもたまにコマ落ちしてるよ
あとそのサイトの話だと途中59.94FPS録画もあったり条件がそろってないから注意ね >>330-331
ノイズや破綻の発生と言っても、
・SW側の実装の問題（NVEncをどのような設定で呼び出しているのか等）
・HWや環境側の問題（電源不安定や突発的な負荷増加等）
・NVEncやドライバ側の問題
など、要因が多数あるわけで、「発生しない」なんて言い切ることは誰にもできないと思うよ。
あと、ぶっちゃけた話、ロスレスキャプチャにこだわらない方がいいと思う。
>>323のテスト結果を見ると、
RTX2070/HEVC/yuv420pロスレス/640x360/29.970fps → ビットレート 39.4Mbps
になっている。1080p30に換算すると単純計算で9倍で354.6Mbpsになる。
「データ量が膨大になってもいいからロスレス(可逆)キャプチャしたい」という強いこだわりがあるなら別に止めないけど、
得られる画質は数分の１のビットレートで通常の非可逆キャプチャした場合と大差ないだろうし、
ロスレスだからといって編集時のデコード処理等が軽くなるわけでもないし、
最終的に保存エンコしたりYoutube等にアップロードすることを考えると、どうせその画質も保持できないわけだし。 >>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倍)
という感じだった。 >>330-331
キャプチャボード付属のソフトでエンコードしてるから、
どっちかというとドライバやHWよりそのソフト側に問題がある可能性が高そう
NVEncやffmpegでも同じ現象が発生するなら別だけど、
そういう破綻は俺は見たことも聞いたこともないなぁ
4K60fpsYUV444でロスレスなんてやったら700MB/sくらいになるから、
SATAじゃ帯域足りなくて、M2でやっとって感じ。相当やばそうｗ ---
2018.11.03 NVEnc 4.22
[共通]
・yuv420のlossless出力に対応。
[NVEncC]
・Caption.dllによる字幕抽出処理を実装。(--caption2ass)
・--check-featuresでGPU名が正しく表示されていなかったのを修正。
・--check-featuresにバージョン情報も出力するように。
・--check-environmentの出力先をstderrからstdoutに。
---
はやいもうできたのか（感謝）
>>327のHEVCロスレスの件についてはどうなったのか不明。 >>337
HEVCは10bitも含めて全部できるようになってたわ！ [NVEnc 4.22v2] (※2018/11/3 23.37)
NVEnc 4.22でlosslessでないときもlosslessと表示されてしまっていたのを修正。 ＧＴＸ1050でもHEVC H265エンコ快適に出来ますか？
世代格差によって画質も向上してるなら買い換えも検討します。 >>341
スレのログを読めばTuringでHEVCのBフレームに対応したのがわかるので、
画質を重視するならTuringへの買い替えを検討すればいいと思う。
もしかすると今後のSDKやドライバーの更新でPascal等にも
HEVCのBフレーム利用が開放される可能性もあるけど、まだ不明だし。
Turingは今のところNVENCコアが１つしか載ってないらしいという情報もあるので、
並列エンコを効率よく行いたいという要望があるなら
NVENCコアが複数載っているGTX1080なんかも候補にあがるだろうけど。
https://developer.nvidia.com/video-encode-decode-gpu-support-matrix >>297
＞NVEncCで--tffオプション指定するとエラーになった
って事は--avhw --tff --vpp-deinterlace normal -i in.ts -o out.mp4
とかも駄目なの？ >>344
インタレのままMP4には出来ないって事ね。
了解。 RTX 2080 Ti の NVEncC64.exe --check-featuresの結果
https://devtalk.nvidia.com/default/topic/1038493/video-codec-sdk/details-about-nvenc-in-turing-/post/5294644/#5294644
・機能項目の内容はRTX2070と一致
・質問時に>>259の内容を引用させていただきました
その後の記述によると、
・Win10 ＋ 2080Ti ＋ ドライバ416.34(現時点最新） ＋ ffmpeg4.0 → hevc_nvencでBフレーム指定(-bf)が効く
・Linux ＋ 2080Ti ＋ ドライバ410.73（現時点最新） ＋ ffmpeg4.0 → hevc_nvencでBフレーム指定(-bf)するとエラー
となるらしい。 上位モデルでのNVEnc2基搭載やめると、本来の目的であるクラウドでのGPU仮想化して描画を配信する手のサービスでの更新機器に当てられなくなるから大問題になるけども
1070やGP104搭載1060が、後からNVEncの2基目開放されたみたいに、物理的に実装されてりゃドライバでどうにでもなる クラウドでGeForceは使われない。というかNVIDIAが禁止してる
https://pc.watch.impress.co.jp/docs/news/1099481.html
NVEnc1基しか載せない、あるいはドライバで1基しか使えないようにする
というのはTeslaやQuadroと差別化するためのNVIDIAの戦略でしょ
最新のNVIDIAは結構えげつないことしてくるからね >>348
使えないのと載っていないというのは違うでしょ
「載っていない」と言ったらTU102や104に載っていないだし
「使えない」なら現状でコンシューマ向けでリリース済みで一般で入手可能なGEFORCE RTXで現状使えないという解釈になるでしょ
フォーラム関係の報告も正式対応じゃ無いドライバでで報告された情報から更新されて居ないまま拡散してるのも多い
何故かフライングで検証して報告できる奴が、その後の正規対応ドライバでの追加報告とかしていないままだったり
あとSupport Matrixのところは更新入るのが毎度遅い（多分Quadroが市場流通し始める前後あたりとか） 久しぶりに来たけど最近のハートエンコは画質上がったのねー >>349
載ってるかどうかは知らないけど、載せる必要もないし、載ってたとしても使えるようにする必要もないって話 >>347
> 1070やGP104搭載1060が、後からNVEncの2基目開放されたみたいに
GP104搭載1060は、8月時点のSupport Matrixでは2基とされてるけど、現在はひっそりと分離されて1基になってるね・・・。
8月の一覧
https://web.archive.org/web/20180814195717/https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
現在の一覧
https://web.archive.org/web/20181105054441/https://developer.nvidia.com/video-encode-decode-gpu-support-matrix
1070の2基目って、後から解放されたの？ >>352
元は>>347へのレスなんだから、
「そもそもクラウドでのGeForceの利用は禁止されてるんだから、
クラウド用更新機器としての利用の都合を考える必要はなく、
GeForceにNVEncを何基載せるか、何基有効にするかはNVIDIAのさじ加減次第。」
ってことだと思うよ。
現状のTuringでNVENcが1基しか載っていない、あるいは1基しか有効になっていないという根拠は
>>264とかにあるようにフォーラムでのユーザ報告のみで、NVIDIAの公式情報ではないから、
正確な情報は公式情報の更新を待つしかなさそうだけどね。
スペック発表の際にNVENC/DECの詳細情報も含めるとか、もっと素早く動いてくれればいいのにねえ。 >>353
ひどい話だ〜 GigaByteのパッケージみてのGP104のGTX1060に期待してたのに・・・ >>355
昔は抵抗張替でdevice id書き換えられたんだが、今は無理みたいね。 選別落ちの眠ってるコアを有効にするのは楽しかったねぇ
8月時点のSupport Matrixの誤植ってだけかもしれないけどね
ゲームしないのに1070や2070はちょっと手が出ないです NVENCの為に1060から2070にしようとしてる俺
しかし買えるのは12月かなぁ >>358
俺も20シリーズ欲しいんだが
突然死問題があるからなあ
しばらくは様子見だな。 >>354
そういうことしゃなくて、「載ってるかどうかは知らないけど、載せる必要もないし」ってくだりのことだよ
知らないくせに必要もないとか、何様だって話 >>360
落ち着いて元レス（>>347-348）や解説（>>354）を読もうぜ。
> 載ってるかどうかは知らない
TuringにNVENCが複数基載ってるかどうかはNVIDIA公式の発表がないとわからないので当たり前。
> 載せる必要もない
「（GeForceはコンシューマ用であってクラウド用GPUの後継として考える必要はないので、
"NVIDIAとしては"、新しいGeForceに複数基のNVENCを）載せる必要（義務）もないし、
載ってたとしても使えるようにする必要（義務）もない」
という意味だと思うよ。
ユーザ目線としては載っててほしいと思うのは当たり前だけど、そういう話ではない。 rigaya氏の画質比較。
「RTX 2070のHEVC＋Bフレーム」の結果も含めたx264/x265/QSV/NVEncの比較。
rigayaの日記兼メモ帳 画質比較 2018.11 (アニメ版)
https://rigaya34589.%62%6cog.fc2.com/%62%6cog-entry-1069.html
rigayaの日記兼メモ帳 画質比較 2018.11 (実写版)
https://rigaya34589.%62%6cog.fc2.com/%62%6cog-entry-1070.html >>362
静止画でやっと差がわかるレベルの話だもんな
よほど速度とビットレート気にしなきゃ、好きなハードで好きな設定でっていういい時代がきたもんだ >>361
ばんなそかなw
おまえらエスパーだろw >>362
実写のグラフが見れないのって俺だけ？
EdgeとVivaldiともにグラフが表示されない（adブロッカーは無効） >>365
ソースにある画像のURL見に行っても404になるから、URL指定ミスっぽいかな？ chromeなら正常に見えてるよ？
しかしエンコードしかやらん人なのにRTX2070買ったんか
漢やなあ
まあ、CUDAでもつかえるからいいけど。 >>365 >>367
rigayaさんが対応してくれたので見れるようになりました。 >>362
QSVのH.264もHaswellより改善されてたのね
こりゃ比較する時に注意する必要があるな
H.265が悪いのは謎だが
AMDのVCEもRyzenGで世代新しくなったみたいだけど、
こっちは情報無いのかな VCEって何のソフト使えばいい？
rigayaさんはもう更新予定無いみたいなこと言ってるし AMDの方が更新必要なほどの更新してないからな
古いバイナリそのまま使ってりゃいいだけでは？
でも、速度はQSV並で画質は2世代前のMaxwell世代搭載のNVEnc以下と良いところ無いから、QSVやNVEnc使えるならそっちの方が良いよ >>372
VCEのリアルタイム2パスエンコードエンジンとはいったい何だったのか… >>374
そもそも2passは一度出したVBRの量子化成果を元に再度量子化係数設定してデータ効率向上させるものだけど
リアルタイムでやると再検討の元にする1度目の結果が短期的すぎて再計算する効果が薄くなる
レイテンシ的に許す限りのLookaheadと大差無いというか計算量的にも成果の効率的にもLookaheadでいいだろという >>373
A's Video Converter知らんの？ 主にアニメ、テレビ映画のエンコ目的ですが
Handbrake
A's Video Converter
Mediacoder
どれがお薦めでしょうか？
8年前くらいのMediacoder使ってたのですが
時代が変わってて全く分かりません amatsukazeでFFMPEGあたりの処理で止まって完走出来ないようなTSも、TMSRでCM抜いてスマレンで出力させたTS食わせ直せば大抵完走出来る
ロゴはチャンネル不明に複数登録しときゃいい >>377
速度重視のHWエンコードならNVEncC CPUとGPUを併用して速度と画質が両立する手法できないかなあ A's Video Converterは使い勝手がよい A'sは、なぜ QSVで LA-ICQ 使えないの？ HWエンコーダでは画質はまだx264には敵わないようだからNVDecとCUDAのフィルタリングをHWに任せて、多コアCPUで並列処理って感じですかね？ AMDのVCEは画質が期待できず、NVidiaのはクソ高いとしたら、IntelのQSVしかない
なんてこった
>>389
> HWエンコーダでは画質はまだx264には敵わないようだから
ようやくそれが時代遅れになるのではと むしろH265で問題ないならX264を使うメリットがなくなりつつある
CPUのマルチスレッド化にも遅れてる印象だし Apple T2 chipのハードウェアエンコードがソフトウェアエンコードと画質の違いを感じないとあるな。速度は爆速だし、Mac mini買って確認したい
I wasn’t able to notice any quality differences between the videos encoded with x265 and the T2’s hardware acceleration.
https://marco.org/2018/11/06/mac-mini-2018-review 主観評価（実質あてににならない）なのかとかソースの解像度と内容にもよるし
特にビットレート高いほどエンコーダの差が出づらくなるから、そこら辺伏せられた評価はマジ当てにならんぞ
実写の屋外撮影でカメラ自体が位置移動しているような状態でFHDで3〜4Mbpsとか4Kで15Mbps切りとかで言っているなら凄いかもだが ぶっちゃけSSIM0.99と0.89だって実際の動画みても違いはわかりゃしないし そう言える奴なら、pascal世代のnvencでH264でも問題ないんだろうから
そもそも「T2ならHWエンコーダでも」とかならんわな
T2のエンコーダ持ち上げたいという贔屓目が先に立ってるんじゃねーの？ >>393
買って報告よろしく
Macでx265ソフトエンコードしたもの見てみたいから忘れずにね >>397
その通りだと思う
300MbpsのUHDを150MbpsのH.264に圧縮するなら、
NVENCもffmpegも見た目の差が出ない
T2使うかどうか、とあまり無関係になる >>396
> ぶっちゃけSSIM0.99と0.89だって実際の動画みても違いはわかりゃしないし
さすがにそれはちょっと・・・
SSIM 0.99と0.89の違い： https://imgur.com/a/CevbZBV ■ このスレッドは過去ログ倉庫に格納されています
