【NVENC/VCE】ハードウェアエンコーダーを語るスレ【QSV】
■ このスレッドは過去ログ倉庫に格納されています
なんでQSVはHEVCよりH264の方が高性能なん？ >>283
ビットレートが載ってるんだから必要ないと思うけど、何故に？
実写の方はrigaya氏のQSVBenchmarkに含まれてる2分53秒の動画で、
アニメOPの方は1分30秒くらいだろうから、ファイルサイズはそこから計算できると思うが。 >>282
なんでって現状そういう実装になってるから、としか
まだ、QSVのHEVCエンコードは出たばかりだし、今後改善される可能性はあると思う
一応、このグラフで使ってるのはKaby Lakeで、QSVは最新世代のはず
Pascal世代のNVEncもHEVCの性能は相対的に低かったから、実写ではH264の方がSSIM高かったよ
（グラフには載せてないけど2070のH264は実写でもHEVCより少し低い） >>281
乙
これはある意味、衝撃的な結果とも言えるね
アニメのほうから見ていくと、「x265 midium main10」と「2070 B=3 HEVC main10」が
ほぼ同じSSIMと言っていいレベルで第1位と第2位！
画質のみで判断する場合、「QSV」と「x264」は、アニメに関してはもはや不要と言いたいレベル！ 実写に関しては「x265」と「x264」がほぼ同点のトップ3タイと言っていい感じかな
次点で「2070 B=3 HEVC main10」と「QSV H264」が同じようなSSIMだが、全体としては
「2070 B=3 HEVC main10」のほうが若干優勢
おそらくよりビットレートを高く設定できる場合になればなるほど「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割増し程度にする設定にしておけば、もはや十分な結果が得られると言えるのではないだろうか >>281
ありがたい
実写は何使ってもSSIM厳しいなー 数値化された指標ってそれしかないんじゃないのかな
なら仕方ない話で
俺はそれはそれ話半分で聞いてる >>289
SSIMのみで画質のすべてを語れるわけではないけれど、重要な指標になりうることは確か
>>281のテストの場合、画質として差が出ると判断できるだけの数値の差が出ているところから見て
Turing世代のHEVCエンコーダーの実用性が高いと判断することはできる
あまり話題には出ないがNVEncの場合、H.264、H.265ともにLOSSLESSエンコードもできるようになっているので、
今後ノートPC用のTuring世代GPUが出た場合、ノートPCにキャプチャー機器を接続してLOSSLESSでキャプチャーし
編集などしたのちH.265に再エンコードして保存などということも楽々とできるようになるのだろう
CPUやメモリーに必要以上に金つぎ込むよりGPUに金つぎ込んだほうが得られるメリットが確実に高くなる むしろ気になったのは改善度合いのわりにNvidiaのアピールとか情報開示が控えめな感じがするところ
HEVCのBフレーム対応はQSVが先にやっているとはいえ、充分Turingの売りになると思うんだけどな >>293
Netflixあたりが使っているようだね
使う意味はあるかと
>>294
動画の品質を重視する層には確かにウリ文句にはなるだろうけど、そもそもNVIDIAは
PureVideoにしてもそうだが世代の違いで何がよくなったかとかそういう情報を細かく
発信しようとしない風潮があるので、伝統的に商売の仕方がヘタクソな会社だとは言える。
特にノート用のGeForceなんかだとMaxwell世代は厳密には3つの区分で見分けないといけないのに、
GTX 965Mなんか公式情報すらあやふやというとんでもない状態を放置したままだし
GTX 965MはMaxwell世代のモバイル用GPUには珍しく、HEVCやVP9の再生支援が搭載されているのに！
・NVIDIA VIDEO CODEC SDK
https://developer.nvidia.com/nvidia-video-codec-sdk
（※GTX 965Mは「Maxwell (GM206)」に該当） これはNVIDIAに限らず、Intelも同様の傾向があるけれど
（Intelの場合、新しい世代であっても再生支援を使って動画再生をするとカクカクした動きになることすら
あるからなおのこと始末が悪いが…）
この手の業界の連中は、ともすれば「コミュ障か！」と突っ込みたくなる傾向が強いのが最大の弱点 > Codec: H.264/AVC
> ...
> Field Encoding no
これ何かと思ったら、H264のインタレサポートが無くなってたわ
NVEncCで--tffオプション指定するとエラーになった
> interlaced output is not supported for current setting.
インタレ保持エンコができなくなるとは・・・これも時代の流れか 要するに、60pは対応するが60iは捨てられたのか
まあ面発光する表示デバイスしか無くなってるからな
有機ELはあるが
60iから60pへのip変換は出来るのかな？ >>294
nvidiaが詳細明示せずSDKやAPIで叩いて実際の挙動見ろ的なのは何時もの事なのでは？ きょーび動画がらみの機能は訴求力ない
ゲームのフレームレート至上主義や
出始めの頃は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食わせ直せば大抵完走出来る
ロゴはチャンネル不明に複数登録しときゃいい ■ このスレッドは過去ログ倉庫に格納されています
