rigayaの日記兼メモ帳 NVEnc 5.00

NVEnc 5.00

English version of changelog>>

[NVEnc.auo]
・NVEnc.auoにNVEncCの内部エンコーダを使用するモードを追加。
QSVEnc 4.00と同じ変更。

こちらの動作をデフォルトにし、外部エンコーダを使うほうはオプションに。

これまでNVEnc.auoで出力する場合、音声エンコーダは別途外部エンコーダでエンコードしていた。(nero, qaac, ffmpeg等)

しかし、NVEncCでもlibavcodecによる音声エンコーダが使えるので、こちらを使って音声エンコード、muxまで一括して行うように拡張した。これで音声エンコーダやmuxerなどを別途用意する必要がなくなり、NVEncCのみ使用するようになるので、音声周りの設定が簡単になると思う。あとは、一時ファイルなども必要なくなるので、予期せずエラーも減るかも?

内部エンコーダ・muxerで使える音声のコーデックはlibavcodecで利用可能なコーデックひととおり(aac, libmp3lame, libopus等)と例外としてfaw2aac.auoからの出力にも内部muxerで対応できるように実装した。

[NVEncC]
・動画を回転/転置するフィルタを追加。( --vpp-rotate, --vpp-transform)
要望の反映。

・エンコード遅延を抑制するオプションを追加。( --lowlatency )
エンコードのパフォーマンス(スループット)は落ちるので、使い道はあまりないかも?

・hdr10plusのメタ情報をそのままコピーするオプションを追加。(--dhdr10-info copy)
現状制限事項が多いので注意。
- avsw/avhwのみ。
- avhwはraw streamなどtimestampが取得できない場合、正常に動作しない。

・音声デコーダやエンコーダへのオプション指定が誤っていた場合に、エラーで異常終了するのではなく、警告を出して継続するよう変更。

・--chapterがavsw/avhw利用時にしか効かなかったのを修正。

※ NVEnc 4.xx以前のプロファイルは設定しなおす必要があるかもしれません。
ダウンロード>>
ダウンロード (ミラー) >>
OneDriveの調子がいまいちの時はミラー(GDrive)からどうぞ。同じものです。

NVEncCのオプションについてはこちら。
NVEncCオプション一覧>

ソースはこちら>>

スポンサーサイト

2020-04-18(20:24) :
NVEnc :
コメント 20 :
トラックバック 0

このページのトップへ

前の記事 « ホーム » 次の記事

トラックバック

この記事にトラックバックする(FC2ブログユーザー)

このページのトップへ

コメントの投稿

No title

v5.00のファイルは待ってればそのうち出てくるんですか？
今見ると、OneDriveもGoogleもどっちも4.96迄しか見えないんですが。

2020-04-18(20:58) :
URL :
編集

Re: No title

> v5.00のファイルは待ってればそのうち出てくるんですか？
はい。もう出ているかと。

2020-04-18(21:28) :
rigaya URL :
編集

初歩的な質問ですが…

質問をさせていただきます。
ある動画を出力したところ
x264では22分33秒のところNVEncで出力すると22分9秒になりました。
ハードウェアーエンコードでとても速くなると勝手に思っていたのですが、
これぐらいが普通なのでしょうか。

またauo[info]のNVEncが0.12%となっていました。
この数字は何をさしているのでしょうか。
また、この数字は正常に動作しているのでしょうか。

質問させていただいたのもタスクマネージャーでCPUの使用率は高いもののGPUの使用率が低くちゃんと動作しているのか不安になったからです。

大変初歩的な質問で申し訳ありません。

追記：
CPU: i7-8700 GPU: GTX 1660Ti
NVEncのインストールは正常におこなえていると思います。

2020-04-19(19:27) :
uitl URL :
編集

Re: 初歩的な質問ですが…

結論から述べると、NVEncではログの"VE"の値がNVENCのエンコードエンジンの使用率にあたります。ここにそれなりの値が出ていれば、一応ちゃんと動作はしています。

> auo[info]のNVEncが0.12%
エンコーダのプロセスであるNVEncCのCPU使用率なので、低くなっていて問題ありません。今回非常に低いのはAviutl側のデコード・フィルタ処理等が重くて、エンコーダに十分な速度でフレームを渡せていないからだと思います。

一応、私の環境で1920x1080での出力を行ったときの結果をご参考までにお見せします。

環境
OS Version Windows 10 x64 (18363)
CPU Intel Core i9-7980XE @ 2.60GHz [TB: 4.10GHz] (18C/36T)
GPU #0: GeForce RTX 2070 (2304 cores, 1710 MHz)[PCIe3x16][445.75]

オプション
-c hevc -u quality --interlace tff --output-res 1920x1080 --vbrhq 0 --vbr-quality 25.00 --qp-init 20:23:25 --qp-max 32:36:40 --lookahead 32 --gop-len auto --weightp --aq --aq-temporal --dar 16:9 --level 5.1 --profile main10 --ref 4 --bref-mode each --output-depth 10 --audio-source "\\.\pipe\Aviutl00003ba0_AuoAudioPipe0":copy --chapter "C:\ProgramEx\aviutl\chapter.txt" --no-mp4opt --colormatrix bt709 --colorprim bt709 --transfer bt709 --videoformat ntsc --vpp-afs drop=true,smooth=true,24fps=true --vpp-smooth quality=5 --vpp-edgelevel black=3 --vpp-deband range=31 --ssim --psnr

ログ抜粋
encoded 34038 frames, 120.37 fps, 3090.33 kbps, 523.00 MB
(A) encode time 0:04:42, CPU: 2.2, GPU: 59.8, VE: 76.2, VD: 8.2, GPUClock: 1893MHz, VEClock: 1758MHz
frame type IDR 301
frame type I 301, avgQP 19.51, total size 35.77 MB
frame type P 9163, avgQP 19.71, total size 349.82 MB
frame type B 24574, avgQP 21.45, total size 137.41 MB
(B) auo [info]: CPU使用率: Aviutl: 5.55% / NVEnc: 2.18%
(C) auo [info]: Aviutl 平均フレーム取得時間: 5.912 ms

各行の意味を説明しますと、下記のような感じです。

(A)の行
エンコーダのプロセスであるNVEncCのCPU使用率が2.2%、GPU使用率が59.8%、Video Encode(VE)の使用率が76.2%、Video Decode(VD)の使用率が8.2%とわかります。基本的にNVENCではCPUを使わずにVideo Encodeでエンコードするので、VEの値が高くなっていれば正常にNVENCを使用できており、逆にCPUは多くの場合で低くなります。GPUやVDの使用率は設定によって異なり、ここでは高いですがほぼゼロの場合もあります。

(B)の行
Aviutl本体とエンコーダのプロセスであるNVEncのそれぞれのCPU使用率が表示されています。NVEncのほうは(A)の行の"CPU"と対応しているはずです。

(C)の行
Aviutlでのデコードやフィルタ処理にかかった時間が表示されています。この時間が長すぎると、エンコーダに十分な速度でフレームを渡せず、エンコーダの力を十分発揮できません。

2020-04-19(20:03) :
rigaya URL :
編集

No title

わざわざ丁寧な説明ありがとうございます。
大変わかりやすかったです。
ちなみにさきほどの動画の数値を書いておくと
COU:0.1 GPU:0.1 VE:0.4 VD:0.0でした。

カメラ制御やエフェクトを多用したので、
デコード・フィルタ処理に時間がかかって
エンコードのNVEncが有効活用されていないということですか！
分かりました！

ないのを承知で聞くのですが　デコード・エフェクト処理の時間を短縮する方法ってないんですかね？
（動画を出力するのに1・２時間かかったりするので…）

2020-04-19(21:27) :
uitl URL :
編集

テストをしてみたので…

テストで
エフェクトを一切かけず動画をつなぎ合わせただけの動画を出力したのでここに追記しておきます。
NVEnc
encode time 0:01:34, CPU: 1.7, GPU: 5.9, VE: 25.9
Aviutl 平均フレーム取得時間: 6.909 ms

x264
エンコード時間 : 0時間10分20.8秒
Aviutl 平均フレーム取得時間: 8.807 ms

時間にして８分、そして約７割ほど時間が短くなりました！
動画をつなぎあわせるだけの場合も多いので
重宝させていただきたいと思います。

丁寧に説明して下さり、またこのプラグインを作ってくださった
rigayaさんに感謝いたします。

2020-04-19(21:36) :
uitl URL :
編集

No title

お試しいただいたように、最初の例ではエフェクト等の処理によりエンコードのNVEncの力をフルに発揮できたいなかったのだと思います。

活用できる場面があるとのことでお役に立ててよかったです。

> デコード・エフェクト処理の時間を短縮する方法
そのあたりはあまり詳しくなく、申し訳ないです。。

2020-04-19(21:57) :
rigaya URL :
編集

No title

いつも便利に使わせていただいています。
60Pや30Pをフレームを間引いて24Pにしたい時がありまして、ffmpegでいうところのdecimateのようなフィルタがあると便利かなと思うのですが、そういう機能を持たせるお考えはありますか？

2020-04-20(21:30) :
URL :
編集

フレームレート変換

横から失礼します。
ffmpegのdecimateのような機能…とあったので、ちょっと興味がわいて調べてみました。
するとインターレース解除フィルタと組み合わせて重複フレームの削除をするフィルタだということだったので、元々60pや30pで作られた動画の24p化の場合はfpsフィルタやframerateフィルタを使うのではないかなぁと。
それでffmpegでフィルタかけてパイプ渡しでNVEncCに突っ込めばいいんじゃ？と思いfpsフィルタをかけてパイプ渡しでNVEncCでエンコードしてみたところ、ちゃんとフレームレート変換された結果を得られました。

ですので、フレームレート変換の出番があまりなく、上記手順で支障がないのであれば、NVEncCに機能をいれてもらうのを要望するよりは、上記の処理をするバッチファイルでも組んだ方がよいのではないかと思います（機能が増えればテストとメンテの手間もそれだけかかりますし、多分rigayaさんだと他のエンコーダにも組み込むと思うので、手間は単純計算すれば5倍…(^^;)）。
ちなみにパイプ渡しについては、NVEncCのオプション一覧のリンクに例があります。

また、aviutl上でするのであれば、設定>フレームレートの変更でいけます。
読み込み時にfpsを変更しないように注意して読み込んで、60p→24pなら"12fps <- 30fps"を選べばフレームレートが2/5になるので24fpsになると思います。どうやって間引くフレームを決めているのか不明なのがちょっと気味悪いですが。

上記方法は既に実行済みでそれでもNVEncCで実装してもらえたらなぁ、とか、ffmpegでフィルタかけるとめっさ遅いんでNVEncCで全部やれたらなぁ、とか、そもそもパイプ渡しだと所期の結果が得られないんで…とかいう話でしたら余計な割り込みでした。ご容赦ください。

ps.
実は、--vpp-select-everyの説明が「指定stepフレームごとに1フレームを選択してフレームを間引きます」とあったので、連続するstepフレーム中1フレームを間引くのだったら30p→24pはこれで行けるかな、と試してみたんですが、その後の説明にあるようにフレームレートが1/stepになったので、「あぁ、『1フレームを選択して（残し、他を削除して）フレームを間引きます』ということなんだな」と今更ながらに理解した次第です（「指定stepフレームごとに1フレームを選択して（その）フレームを間引きます」だと誤解し、失礼ながらフレームレートの記述が誤記なんだと思い込んでいました…orL）。

2020-04-21(16:46) :
red10 URL :
編集

No title

red10さん
意図しているところはパイプでなんとかなるのはご指摘の通りなのですが、スピードを考えるとデコードからエンコードまでGPUで完結しているNvencの方がいいかなあと思った次第です。
まあ、元々24Pのものを30Pにして配信されたファイルを処理したいという事情もあるのですが。
また、selecteveryが1/nになる件もその通りですね。avisynthのselecteveryならもう少し柔軟に選べるので希望に近い処理ができるのですが、こうなっている以上どうにもならないです。

どちらにせよ必須とまでは言えないのかもしれないですが、あったらいいなあという個人的願望です。

2020-04-22(09:15) :
04-20(21:30) URL :
編集

No title

--vpp-select-everyは単純にフレームレートを1/nにするだけなので、60p/30p→24pには使えないです。

--vpp-decimateの実装はffmpegのコードを読んでみたりして、ちょっと考えてみたいと思います。

2020-04-22(21:10) :
rigaya URL :
編集

Re: Re: 初歩的な質問ですが…

> 結論から述べると、NVEncではログの"VE"の値がNVENCのエンコードエンジンの使用率にあたります。
初めて知りました。
VE、VD がそれぞれ VEnc、VDec のように表示されるよう変更すれば慣れてないユーザーに意味が通りやすくなるのではないでしょうか。

2020-04-23(18:24) :
URL :
編集

「外部エンコーダーを使用する」で落ちます。

「外部エンコーダーを使用する」で落ちます。
以前では使えてた設定です。
[信頼性履歴の表示]のレポートは以下の通り
問題イベント名: BEX
アプリケーション名: aviutl.exe
アプリケーションのバージョン: 0.0.0.0
アプリケーションのタイムスタンプ: 51585132
障害モジュールの名前: ucrtbase.dll
障害モジュールのバージョン: 10.0.18362.815
障害モジュールのタイムスタンプ: bea5fce0
例外オフセット: 0009caa2
例外コード: c0000409
例外データ: 00000005
OS バージョン: 10.0.18363.2.0.0.768.101

2020-04-23(20:12) :
URL :
編集

No title

> VE、VD
進捗表示で文字数を減らしたいので、短縮しています。

> 「外部エンコーダーを使用する」で落ちます。
音声エンコードの処理順を「同時」以外にしてみてください。

2020-04-23(20:33) :
rigaya URL :
編集

音声エンコードの処理順を「同時」以外にしてみてください。

「前」でneroとqaac(64bit)で試したところ、ちゃんと通りました。
あれ？既知の問題だったのかな？それなら、ごめんなさい。

2020-04-23(20:58) :
URL :
編集

フレームレート変換(パイプ渡しの有意性)

やはりスピードがネックというお考えでしたか。
ffmpegをプリプロとして使うとはいえ、エンコードをNVEncCで出来るだけでも随分と違うのではないかなぁ、と外野な自分は思ったりしましたんで(^^;)、定量的な比較なんぞしてみた方がいいんじゃないか、と、ちと試してみました。
以下自己満足みたいなもんでお目汚しとは思いますがご容赦を。

内容はNVEncCでvppオプションを使ってエンコードした時と、それと同等と思われるffmpegのフィルタをかませてパイプ渡しでNVEncCでエンコードした時の差を見る、というものです。

環境
　CPU core i7 6700 (skylake)
　GPU GeForce GTX1660(無印)
　OS Windows10 Home 64 build1909
　使用エンコーダ
　　NVEncC64: 4.53
　　ffmpeg : git-2020-04-22-2e38c63

　ソース 1440x1080 23,976fps HEVC 2時間１分のmp4ファイル
　　（手元に30pの手頃なファイルがなかったもんで(^^;)）

　NVEncCのvppオプションは、フレームの間引きという今回の話題からvpp-select-everyを。
　ffmpegでは同等のフレームレート変換じゃないかなぁ、ということで -rオプションを使ってみました。
　ffmpegについては（も？）よく知らないので妥当な選択ではないかもしれません。　

　1 NVEncCでvpp-select-every 5を指定してx264にエンコード
　　NVEncC64.exe -i "testi.mp4" --vpp-select-every 5 -o testo.264
　　結果:1分35秒(95秒)
　
　2 ffmpegで上記と同じフレームレートになるようにフィルタをかませて、NVEncCにパイプで渡してエンコード
　　ffmpeg.exe -y -hwaccel nvdec -i testi.mp4 -an -r ((24000/1001)/5) -pix_fmt yuv420p -f yuv4mpegpipe - | NVEncC64.exe" --y4m -i - -o testo.264
　　結果:7分12秒(432秒)

とまぁ、さっと4.5倍パイプ渡しの方が遅いという結果に。
実行時間の差がソースの長さに比べて有意であるか、という判断は人それぞれですが、NVEncCで出来ないことを外でやって、エンコード自体はパイプ渡しでNVEncCでやる、という事の有意性はある程度あるんじゃないかな、というのが個人的な感想…だったんですが、ここで、ffmpegだけで完結した場合も試してみました。

　ffmpeg.exe -y -hwaccel nvdec -i "testi.mp4" -an -r ((24000/1001)/5) -c:v h264_nvenc testo2.264
　結果:5分51秒(351秒)

　ffmpegもHWデコード／エンコードを使わないとNVEncCと比べるのにアンフェアだよなぁ、と上記コマンドでやってみたんですが、単独の方が若干速いという結果に。どうやらこのケースでは、速度、という点でのパイプ渡しの有意性はない、ということになりそうです。もちろん、NVEncC側の固有の機能／設定を使うのでない限り、ということですが。

ps
decimateの実装、ちょっと期待しています。
習わぬ経読むなんとやら…を地で行くようで恐縮ですが、二コラボのサイトにある
yadif=0:-1:1,decimate,setpts=N/(24000/1001)/TB
のようなインタレ解除／24fps化が出来たりするようになると嬉しいかも(^^;)

2020-04-24(21:11) :
red10 URL :
編集

Re: フレームレート変換(パイプ渡しの有意性)

パイプ渡しすると結構速度に影響あるのですね…。やはり比較的軽量なフィルタはNVEncCに実装する意味がありそうな感じですね。

ほかにやることがあるので、すぐにdecimateの実装に取り掛かれる感じではないのですが、今やっていることが終わったら取り組んでみようかと思います。

2020-04-27(22:32) :
rigaya URL :
編集

No title

Windows7はできないのですか？
auo_setup.exeをクリックして導入しようと思ったのですが

「簡易インストーラはWindows7以前のOSはサポートしていません。」

と出てきました。

2020-04-28(21:55) :
URL :
編集

Re: No title

メッセージの通りですが…。

Windows 7はサポートが終了しており、こちらで配布している各ソフトもWindows7以前は対象外となります。
https://www.microsoft.com/ja-jp/windows/windows-7-end-of-life-support-information

2020-04-28(22:06) :
rigaya URL :
編集

decimateフィルタの実装

NVEnc 5.01で実装しました！

30p→24pが可能なことを確認していますので、お時間あるときにでもお試しください。
https://rigaya34589.blog.fc2.com/blog-entry-1246.html

2020-05-07(23:28) :
rigaya URL :
編集

このページのトップへ

« 前の記事ホーム次の記事 »

このページのトップへ