【NVENC/VCE】ハードウェアエンコーダーを語るスレ4【QSV】
■ このスレッドは過去ログ倉庫に格納されています
zeranoe ffmpegの最新版(ffmpeg-20200504-5767a2e-win64-static.zip)を落としたらvp9_qsvのエンコーダーが使えるようになってた
icelakeのPC持ってないから試せないけどWindowsでもQSVのVP9エンコードが出来るようになったんじゃないかな？
ちなみにffmpeg -codecs > codecs.txtのコマンドを打つと対応コーデックの一覧がcodecs.txtに出力されるから
そこでvp9_qsvを確認することが出来るよ vp9_qsvの文字はだいぶ前からあるけれども・・・icelakeなんてもってない！
あら、qsvはKebyLakeから対応してなかったっけ？それも持ってないが！
個人的には秋のRocketでNVEncから卒業するか、Ampereでやっぱり離れられないか…
>>629
30ｘ0シリーズは、とりあえずレイトレ―スが4倍性能になって、レイトレ―スなしのGTXは用意されない方向みたいだね
まだこのスレ的に魅力な言葉はないが、とりあえずXboxとPS5のAMDレイトレ―スの一歩先を搭載予定 NVENC GEN7は8k60fpsまでって北森に書いてあった。
画質面での強化も欲しい amatsukazeか自分でbat作ってNVEncに投げればいいだけでは? AV1なんて主流にならないし人気も出ないから美味しいことは何もない
そのくせ価格に反映されて高くなったら客が離れていくだけ
ハードウェアエンコードってグラボにとってはおまけの機能なんだからそこまでコスモかけられないよ コスモ石油、怒っていいんだぞ
NVIDIAにはCUDAで実用的な品質をもった超解像拡大処理やAIを駆使したインターレース解除を実用化してもらいたい
特にインターレース解除は4Kや8Kに拡大したときに荒らが目立ちすぎて嫌になる インターレースとかCMとかゲーム配信に関係ないじゃん
Nvidiaが関心持つはずもなく PCは邪悪だと拒みインターレースにこだわったのが
当の日本人（家電メーカーや放送局）ってのが面白いよな マイクソの古川が社長の時、プログレにしろって強硬に抗議したけどNHKが頑なに首を振らなかったらしい QSVEncCにも--vpp-afsが実装されたりしないかしら。 今でもインターレース放送だしな。
チャンネル変える度1080iとか480iと表示される。 インターレスは今の強力なGPU使った画像補完ができる時代こそ見直されるべきテクノロジー
NHKの先人達はそこまで見据えてインターレスに固執したんだと思う >>647
そのボケちっとも面白くない。
あえてマジレスすると、補完するなら遅延が発生してゲーム向けじゃないし ビールス(ドイツ語)
ウイルス(ラテン語)
バイラス(英語) ウイルス（ドイツ語）
ヴァイラス（英語）
ヴィールス（オランダ語？）
ビールス（スペイン語）
フォルクスヴァーゲン（ドイツ語）
ヴォルクスワーゲン（英語）
フォルクスワーゲン（日本語） 中学生の時、友達がキメ顔で
「ノゥ、ローディング…！」
って言ってたの思い出した スルー出来ない君も仲間だ同志よ！
NVENC Gen7までアオハルを満喫しよう！ NVEnc 5.01でLinux対応したんだね(NVEncC)
Ubuntu 19.10と18.04(AWS)はテスト済みみたい Ubuntuでハードエンコしたところで速度も画質も変わらないんじゃね？ エンコサーバを作りたい人向けじゃ(*´･ω･)(･ω･｀*)ﾈｰの？ NVENCCでデコード、前処理やらせてエンコードはx265に投げるのって出来ないですか？
pipe out使ってもうまく出来ない。 afsでも使いたいのでは
avisynth (avisynth)でもafs使えると便利だから
自分も方法があるならやりたい H.265だとインターレース保持はまともに使えないみたいだし、
afsで加工してから流すのも悪くないよね。
そういう意味でQSVEncCにもafsが欲しいと思う今日この頃。
IceLakeでちゃっちゃと圧縮したい時とか。 NVENCCで基本フィルタをかけつつ、
AVIsynth無しでx265に渡したいのです。
目的はGPU→CPUに一度で渡したいためです。
Avisynth経由したらCPU→GPU→CPUとなり速度が犠牲になりそうな点です。 まるでNVEncCのフィルタがCPU使ってないみたいじゃない 省いちゃいましたが、デコーダ→フィルタ→x265です。
NVENCCもCPU使うのは知ってます。
1コア監視に割いてます。 動作確認してないけど
--output-format yuv4mpegpipe --output - | x265 …
を試してみては？ Handbrakeでエンコードしております
動画は1920×1080 4GB データー速度5997kbps 総ビートレット6189kbps
のものをh265 nvidiaNVNCで
品質ではなく
平均ビートレット3500にして
エンコーダープリセットをslwにしてエンコードしたところ
容量2GBになりました かかった時間は30分
それでエンコーダープリセットをfastに変えてエンコードしたところ
それも2gbになりました かかった時間は7分
それで画質も容量も変わらないです
それはなぜなのでしょうか
時間は2倍以上違うのに
slwは画質良いが遅い
fastは画質悪いが早い
と聞いたのですが >>677
ソースにした動画によりけり
2passならウルトラファストとミドルでも大差なくなるし ああそれとハンドブレイクはnvencのh265でbフレームを使っわないからやめた方がいいよ
プロファイルもmain のみでmain10は使えないでしょ？
nvenccを使えば同じ画質で1500〜1800くらいまで圧縮できるぞ >>677
平均ビットレートを指定しているから当たり前
画質は静止画で画質比較するような人が良い悪いをいうから
動画で見たら気が付かないなんてのはよくある >>677
画質なんて主観的な部分も多いからね
例えば60点を下回る画質だと画質悪いと認識できるような人が、80点と90点の差で設定を変えても
なんだ設定変えても画質変わらないじゃん、って感想になる
fastにしたらslwよりも画質は落ちているはずだが、それを見分ける力がないだけ
別にけなしているわけではなく、多くの人があまり実用上でない範囲で画質の良し悪しを語ったりしてる
画質に拘るならAVIだよ >>682
いや容量もビートレットも全部同じなんだけど
>>681
そもそも画質の良い悪いって解像度とビートレットで判断するものだよね
どっちも同じに設定したら
fastとslowでエンコード時間が三倍違くても画質は変わらないのか 画質の良し悪しは解像度とビットレートだけで決まるのか
多分彼は違う異世界の住人ですね >>686
煽る前に他になにで違いが出るのか教えてくれ 多すぎて色々としか言いようがないが
連続bフレーム数とか動き分析とかbフレーム作るときの参照数とか
インターレースを何で解除するかとか
他にも何十項目も高画質化の機能はあるから調べなよ 静止画に近い映像ならオプションで差はまず出ない
動きがある時に、軽いpresetなら動きに追随できずノイズっぽくなったりボケたりする（x264/x265の場合）
そして軽いpresetによる構造的に発生するノイズやボケは、いくらビットレートを盛っても解消できないから
特に理由がないなら重いpresetを使うのがベター
ただ、動いてるものに対する人間の認知力は下がるから
presetによる違いは分かるかもしれないし分からないかもしれない 画質の良い悪いはソースでも変わる
エンコード後の事でいうならオプションによって画質容量比が変わるだけ、QPとか色々比較すれば分かる
やってないだろうし画質が変わらないという事はない(違いを認識できるかどうかは別)
そもそもビットレートを無駄に振りまくってたらfastとslowの違いは分からないかもしれない
ノイズが結構でるくらいのビットレートにすれば違いが分かるかも
ソースによって変わるしQPやSSIMの表記もないしそもそも数値だけでは画質の良し悪しなんて分からない(ソースに対しての良し悪しは分かる)
それとfpsの違いでも必要ビットレートかなり変わるし水増しフレームの程度(多ければ多いほど縮む)によっても変わる 画質の良し悪しが「解像度とビットレートだけ」で決まるんなら、こんなに数多くのコーデックが世の中に存在する意味は何なんだと… >>685
だから同じビットレートでもファイルサイズでもエンコードによって画質は変わってくるわけよ
例えば丁寧に計算した結果と、やっつけとまで言わないけど速度優先で効率的に近似的に計算したのとの違い
それがfastとslwの差
でもその差が見分けつかないレベルでの差であればもう差はないと言っていいということ
なので容量とビットレートが同じでも画質の差が出てくることはあるし、差があるはずなのに違いが判らない
ことも普通にある バイナリで比較しなよ。日本語分からなくても、きっと違いが分かる人になれると思うよ。 いやまて、ビットレートじゃなくビートレットを基準にしてるから、
これまでの概念を覆す多次元品質で評価してるのかもしれん。
つまり、しらんけど。 まじか
８ビートの動画はノリが良いとかそういう話だったのか Premiere ProがNVENC対応。書き出しが5倍高速に
https://pc.watch.impress.co.jp/docs/news/1253499.html
Premiere Pro バージョン14.2では、ハードウェアエンコーダ「NVENC」の統合が図られ、H.264およびH.265/HEVCコーデックの動画の書き出し速度が大幅に高速化。
高品質な映像コンテンツをよりすばやく作製できるようになる。
Premiere Proのほか、Media Encorder、After Effects、Auditionでも同様に書き出しが高速化される CPU 3700Xで
3時間で4gbの動画のエンコードに二時間もかかるんだけどこんなにかかるもんなの？？？
ちなみにRTX2060のGPUエンコードだと20分
CPUでエンコードなんてやってたら
沢山あるエッチな動画のエンコードに何ヶ月もかかってしまうのですが… >>703
そんなもんフィルターだの設定によるんだから
それだけでは何とも
RTXでやれば良くね？ >>706
CPUだと画質が良くて容量も少なくできると聞きました
グラボだと汚くなり容量もでかいと聞きました いや1本二時間もかかるなんて思わなかったんですよね
CPUエンコードだと… >>707
聞きましたじゃなくて
実際自分の目で見て、RTXエンコ済みのデータは許容範囲ならそれでいいじゃん
見て違いがわからないなら時間かけるのなんて無駄だよ
少しでも綺麗に小さくしたいのは理解できるけど
費用対効果の割に合うのか そもそもハードウェアエンコードスレでそれ言うか？
時間を優先しつつ高画質にしたいならともかく >>713
ていうよりもCPUエンコードはこんなにも時間かかるとは思っていませんでした
CPUでエロ動画をエンコードしてる人はこれが普通なんですかね
ネットとか見ても
AV エンコード とかでてこなくて… コマンドラインでやらないとなかなか設定内容なんて理解できないと思うけど・・・
エンコーダープリセットを一番左にすれば多少早くなりそうだねぃ
あとそのくらいのビットレートでFHDだと内容によっては破綻してそうだけど、気にならないならやっぱHWでいいと思う
AVエンコードは実写のやたら動きが多くて暗部・髪の毛がつぶれてやハイライトが飛びやすい動画だという感じだな、18禁指定されると閲覧者が減るからわざわざ書かないと思う
円盤でも撮影や編集時にヘボがいて破綻しているようなものも多いし気にしちゃいかんのだろうけど、ビットレートが足りないとあからさまにブロックノイズやぼやけ感が出る
衛星物は再ぼかし入れてるから余計ひどいことになってるけどな 文章とエンコード対象からにじみ出るホンモノ感が怖すぎる >>717
より低いビットレートで高画質にしようとするとCPUのが勝る
ただそれには設定等かなり詰める必要があり、RTXでのエンコード結果、画質が満足ならそれでいいと思う 数年前、昔新宿で売ってそうなVHS裏ビデオ貰ったんだけど 洗濯屋ケンちゃん とかあったような・・
多すぎて（衣装ケース３個分位）処分しちゃったわ エンコしておけばよかったかな
引っ越しするけどマンションのゴミ置き場に捨てるの恥ずかしいからあげる って コロナ渦でHDDが下がらないからエンコしなければならない >>716
4GB/3時間だからSDサイズかと思ったらフルHDなのか
普通のソースだと↓な感じだから実時間を割り込むなら早く終わったほう
https://rigaya34589.blog.fc2.com/blog-entry-1232.html ビットレート高めでエンコードするならNzvEncでもいい。
ある程度ビットレート落とすとNVEncは一気に破綻するポイントがあるが、x265はそうでもない。
そのため、品質固定でエンコードするとNvEncとx265で要領が倍以上の差になったりする。 破綻したことないけど低ビットレートを攻め過ぎなんじゃないかな
FHDで15kなら余裕の画質だぞ ■ このスレッドは過去ログ倉庫に格納されています
