QSVEnc 6.03

English change log and binaries>>

起動速度をわずかに高速化したり、そのほか不具合の修正など。



・起動速度をわずかに高速化。

・--caption2assが使用できなかったのを修正。

・OpenCLの情報を表示するオプションを追加。(--check-clinfo)
OpenCLによるGPUの認識状況の確認用。

・--vpp-smoothでquality=0のときにはprec=fp16を使用できないので、自動的にprec=fp32に切り替え。

・ログの各行に時刻を表示するオプションを追加。(--log-opt addtime)



QSVEnc ダウンロード>>
ダウンロード (ミラー) >>
OneDriveの調子がいまいちの時はミラー(GDrive)からどうぞ。同じものです。

QSVEncBenchmark.zipはベンチマーク用です。(重いので注意)。run_benchmark.batをダブルクリックで実行です。

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

ソースはこちら



起動速度の高速化



QSVEnc 6.00以降、こころなしか起動が遅くなってそうだったのでちょっと調べてみた。

試したオプションはこんな感じで、起動・初期化の時間がわかりやすいように、10フレームだけエンコードしてすぐ終了するようにした。なお、初回実行時は実行ファイルやモジュール(dll)のディスクからのロード時間が影響するので、2回目以降で計測。
-i input.ts -o test.mp4 --tff --vpp-deinterlace normal --vbr 6000 --max-bitrate 15000 --output-res 1280x720 --audio-codec aac --audio-stream stereo --trim 0:10



i7 11700K上でIntel VTuneで調べるとこんな感じ。初期化(Init)に1.526s。ちょっと長いかなあ…

QSVEnc_20210925_initsession_before_r015hs_whole.png



Initの内訳を展開していって確認すると、4か所あるInitSession~系の関数がそれぞれ0.2~0.5s前後喰っていて、これが遅いことがわかる。

・情報取得用
・デコード用
・エンコード用
・フィルタ用
のsession初期化があるので、4回呼ぶのはまあよいのだけど、にしても遅い。

QSVEnc_20210925_initsession_before_r015hs.png



さらに展開していって、中でなにやってるの? を見たのがこちら。

どうもLoaderCtxVPL::FullLoadAndQueryというのが遅いらしい。4回のInitSessionで毎回呼ばれていた。

QSVEnc_20210925_initsession_before_r015hs_detail.png



そもそもsessionの初期化というのはどうやって行うかというと、下のようにVPLの関数を呼ぶ。これをsession初期化のたびに行っていた。


mfxLoader loader = MFXLoad(); // まずloaderを作る
auto cfg = MFXCreateConfig(loader); // このcfgを介して起動するsessionの設定ができる

mfxSession session;
MFXCreateSession(loader, 0, &session); // 実際のsessionの初期化


LoaderCtxVPL::FullLoadAndQueryというのはVPLの関数で、なんかデバイスのいろんな情報の取得をやっているみたい。

VPLの周辺のコードを確認して、なんとかLoaderCtxVPL::FullLoadAndQueryを呼ばないようにしたり、その回数を抑えたりできないか調べたら、毎回MFXLoad()でmfxLoaderを作るのではなくて、これを使いまわすことでFullLoadAndQueryは初回のみの実行で済み、以降は実行されないようにできることがわかった。



というわけでmfxLoaderを使いまわすように変更したQSVEnc 6.03のVtuneでの分析結果がこちら。

初期化にかかる時間が1.526s → 0.469sと大きく高速化された。

QSVEnc_20210925_initsession_after_r014hs_whole.png



内訳を確認するとこんな感じ。一番上のInitSessionを除き、他の3回のInitSessionに要する時間が大幅に削減されていて、ほとんど気にならないぐらいの時間となっていて、これが高速化につながっているとわかる。

QSVEnc_20210925_initsession_after_r014hs.png



InitSessionの内訳も確認。

最初の時間がかかっているほうのInitSessionではLoaderCtxVPL::FullLoadAndQueryが初回の呼ばれているが、その次のInitSessionではLoaderCtxVPL::FullLoadAndQueryが呼ばれなくなっていて、そのぶんの時間がごっそり無くなって速くなっている。

QSVEnc_20210925_initsession_after_r014hs_detail.png



というわけでQSVEnc 6.03では起動を1秒弱と、まあ実感できるか怪しいぐらいのたいしたことは時間でしかないけど高速化することができた。

VTuneを使うと、どこで時間がかかっているのかを分析してくれるので、なんか遅いなとか、速くしたいなと思ったときに、どこをターゲットにしていけばよいのか絞り込みやすく、なかなか重宝する。あとGUIでわかりやすくすぐ表示してくれるのもありがたい。gprofとかのCUI系のツールは慣れてないせいか見るのちょっとしんどい…



QSVEncの起動速度は、今回よりももっと遅くなるケースがあって、OpenCLのフィルタとかを使うとあちこちでOpenCLのkernelのコンパイルを行ってこれが結構時間がかかってしまう。これはどうしたらいいのか…。

スレッドを別に立てて、バックグラウンドでコンパイルすればいいのかもだけどちょっと実装が面倒そう…(特にエラー処理が)。
スポンサーサイト



コメントの投稿

非公開コメント

No title

便利なソフトを公開いただいてありがとうございます。
以前と比べフィルタ類がかなり早くなってありがたいです。
ここから質問ですが、以下のURLのファイルに対してQsvEncCのオプション-c hevc --output-depth 10 --icq 22でエンコードすると
特に1分10秒あたりで黒や白のポツポツが見えるファイルが生成されます。
これは6.03に限った話ではなく5.05でも同じようですが、output-depthを指定しなければ見た目上問題は発生しないようです。
再生側はvlc-3.0.16やMPC-BE.1.5.7.6180.x64を使ってみましたが同じように見えます。
エンコード・デコードどちらに問題があると考えられますか?
CPUはi5-11400、ドライバは30.0.100.9864です。
https://commons.wikimedia.org/wiki/File:PIA23807-PlanetJupiter-FlyOver-Animation-20200602.webm

Re: No title

コメントありがとうございます。

こちらでもいろいろ試したのですが、いまのところ再生時のHWデコードが関係しているのかなと思っています。

エンコード後の同じファイルを再生する場合でも、mpc-beのデコードをSWデコードに変更する(DXVAを切る)と黒ボツボツが見えなくなるように思います(見落としだったらすみません)

No title

検証ありがとうございます。こちらでもハードウェア支援を切れば発生しなくなることを確認しました。
この場合直る見込みがあるとすればドライバ更新になるのですかね。ともかくありがとうございました。

拡張QSV出力(AviUtl) 及び QSVEncCの自動フィールドシフトについて

ありがとうございます
便利に使わせていただいてます。
自分の環境のせいなのか判断できない為、報告します

使用環境

windows10 (ver 21H1 ・ ビルド19043.1237)

CPU i5-11500
UHD750 (ドライバver 30.0.100.9894)

QSVEnc 6.0.3
QSVEncC 6.0.3 64bit版

L-SMASH Works File Reader r940 mod1

29.970fps(60フィールド)のインターレース動画(.m2v)です


(1)AviUtl ver1.10にて
拡張QSV出力を使うと、どのプリセットを選んでも出力ログに
Error: Unknown option: --loglevel

Did you mean option(s) below?
--log-level
QSVEncC.exe finished with error!
auo [error]: QSVEncCが予期せず途中終了しました。QSVEncCに不正なパラメータ(オプション)が渡された可能性があります。
auo [error]: QSVEncCが予期せず途中終了しました。QSVEncCに不正なパラメータ(オプション)が渡された可能性があります。

という内容が表示されて正常にエンコードが開始されません。


(2)Avisynth+(ver 3.7.1 r3426 64bit) にて

・インターレース解除

① 自動フィールドシフト --vpp-afs について、
「判定に使用する領域から除外する範囲の指定パラメータ」 top bottom left right がそれぞれ機能していないように思えます。
調整モードのtune=trueにしても常に全画面が判定領域になっているようです。

また、
② 同インターレース解除 設定において
動き、縞、新方式判定 含め、 最大限検出できるように数値を設定しても、
黒背景に白い文字が流れるような部分(エンドロール等)だと一切検出されていないようです
調整モードも使い確認しました。
(RFFあり/なし 両方同じ結果でした)

よろしければご検証の程、お願い致します。














No title

エンコード中のファイルを再生するのに、FFmpegの-movflags faststartのようなオプションはどうするのでしょうか?

教えて下さい(ssimの値が食い違う)

ハードディクスの整理に利用させて貰おうと考え、どの辺りの設定が良いかを試行錯誤中のものです。

取り敢えず、h265 -icq 23 辺りでも、40~50%圧縮されるので、この辺りで試しているのですが、ssimの値に疑問を持ち投稿させて頂きました。

QSVEncC64 --avsw --icq 25 -c hevc --audio-codec aac --audio-bitrate 192 --ssim -i test_org.mp4 -o test_ICQ23.mp4

こんなコマンドで変換をかけるとこんな結果が出ました。

SSIM YUV: 0.988054 (19.227825), 0.991399 (20.654258), 0.990307 (20.135309), All: 0.988987 (19.580931), (Frames: 228649)

なかなか良い画質の様だと思い念の為に、

ffmpeg -i test_org.mp4 -i test_ICQ23.mp4 -filter_complex ssim -f null -
とやってみると、

SSIM Y:0.923742 (11.177146) U:0.984625 (18.131742) V:0.979390 (16.859133) All:0.943164 (12.453743)

かなり悪い結果となりました。
この差は、なぜ発生するのでしょうか?
どちらの値を信用すれば良いのでしょうか?





No title

> 拡張QSV出力
loglevelあたりがおかしいです。すみません…。

ひとまず「その他の設定」の「ログ出力」の項目をデフォルトの「通常」に戻していただければと思います。

> vpp-afs
こちらでも試してみました。

① 判定に使用する領域から除外する範囲の指定パラメータ
説明が不明確で申し訳ありません。

フィールドシフトの判定に使用する領域」の除外なので、「縞・動きの判定」自体は常に有効であり、調整モードで全領域の縞・動きが表示されるのは期待される動作です。

なお、コードを確認しましたが、フィールドシフトの判定に対しては、このパラメータにより適切に除外されていると考えています。

② 一切検出されていないようです
デフォルトのパラメータで黒背景に白い文字が流れるような部分について再確認しましたが、不安定ながら一応縞・動き検出されているのを確認しました。あまりに文字が細かいと検出されないケースもあるかと思いまうが、HD映像なら一定程度の検出はされると思います。入力次第なところもあるかもしれませんが…。

RFFについては試していませんが、こちらは縞検出はされないと思います。(されているとむしろまずいです)

> movflags faststart
QSVEncCでは、mp4/mov出力の場合には常にmovflags faststart相当の出力となっています。

ただ、mp4はエンコード中には再生できないと思いますが…。

> ssimの値が食い違う
QSVEncC 6.03 で -c hevc --icq 23で同様のテストをしてみましたが、このぐらいは一致するはずです。(微妙にずれているので、まだQSVEncC側の実装に問題がある可能性がありますが…)

QSVEncC:
ssim/psnr: SSIM YUV: 0.977291 (16.437963), 0.989182 (19.658709), 0.989946 (19.976769), All: 0.981382 (17.300655), (Frames: 5203)

ffmpeg:
[Parsed_ssim_0 @ 000001fd0d436f00] SSIM Y:0.977295 (16.438829) U:0.989182 (19.658728) V:0.989946 (19.976773) All:0.981385 (17.301362)

なのでそこまで大きくずれる原因はよくわかりません。また、入力ファイルにもよりますが、--icq 23ですと、このように0.97~0.99前後は出るはずで、0.923とかにはならないように思います。

どちらが正しいかというご質問ですが、お手数ですが実際の映像出力を確認いただきたく思います。SSIMで0.988と0.923というと大きな差で、ぱっと見でわかる違いと言え、0.923はかなり悪い画質になります。実際の映像出力はいかがでしょうか。ぱっと見でひどく劣化しているとわかれば、0.923のほうが確からしいことになりますし、ぱっと見で劣化が少なければ、0.988のほうが確からしいと言えると思います。

ssimの件

rigaya様

早速の回答ありがとうございます。
質問した後、自分なりに少し試してみました。

今回の例は、Mpeg-4からHEVCへの変換でした。
試しに、-c hevc --icq 1
で変換したファイルと、ICQ23で変換したファイルをffmpegで比較すると、QSVEncC64で変換時に計算されたssim値と近い値が出ました。

一方、元ファイルとICQ1で変換したssim値は、同様に悪いです。

ICQ1で変換したファイルのビットレートは、元ファイルよりかなり大きいので、この変換で画質劣化しているとは考えられません。

また、変換する元動画によっては、QSVEncC64で変換時に計算されるssim値とffmpegで計算したssim値が近い値になります。

よって、状況から判断するに、
・QSVEncC64で変換時に計算されたssim値は正しい。
・Mpeg-4からHEVCに変換すると、動画によっては、ssim値を大きく下げるケースがある。

という事なのかと想像しています。
(能力がないので、原因を見つける事は出来ないのですが・・・)

ssimの件 続き (データ)

上の投稿で書いたデータを載せておきます。


元ファイル MPEG-4 ビットレート 6,026 Kbps
ICQ1 HEVC ビットレート 29.4 Mbps
ICQ23 HEVC ビットレート 1,856 Kbps

①ICQ1に変換時 ssim (QSVEncC64の表示)
SSIM YUV: 0.997718 (26.416617), 0.997839 (26.652482), 0.997698 (26.378125), All: 0.997735 (26.448553)

②ICQ23に変換時のssim (QSVEncC64の表示)
SSIM YUV: 0.988054 (19.227825), 0.991399 (20.654258), 0.990307 (20.135309), All: 0.988987 (19.580931)

③ICQ1 vs ICQ23 のssim (ffmpegで計算)
SSIM Y:0.987390 (18.992772) U:0.990565 (20.252638) V:0.989458 (19.770957) All:0.988264 (19.304717)

④元ファイル vs ICQ1 (ffmpegで計算)
SSIM Y:0.922056 (11.082149) U:0.986376 (18.657112) V:0.981345 (17.292139) All:0.942657 (12.415223)

⑤元ファイル vs ICQ23 (ffmpegで計算)
SSIM Y:0.923266 (11.150117) U:0.984254 (18.028309) V:0.978946 (16.766705) All:0.942711 (12.419262)


②と③が殆ど同じ値である事。
④と⑤が供に低い数値である事。

から、MPEG-4からHEVCに変換する時に、ssim値が極端に下がる動画がある。
⇒ 元ファイルの動画に何らかの問題がある。

という風に考えました。

ありがとうございます

拡張QSV出力について、後日別ファイルでエンコードしたら正常に動作開始しました。
こちらの使用環境によるものだったようです。

vpp-afsについて、判定領域について理解しました。
説明いただいた事を参考に、
動画とフィルターの効果的な動作を自分なりに工夫してみます。

お手数お掛けいたしました。

プロフィール

rigaya

Author:rigaya
アニメとか見たり、エンコードしたり。
連絡先: rigaya34589@live.jp
github twitter

最新記事
最新コメント
カテゴリ
月別アーカイブ
カウンター
検索フォーム
いろいろ
公開中のAviutlプラグインとかのダウンロード

○Aviutl 出力プラグイン
x264guiEx 3.xx
- x264を使用したH264出力
- x264guiExの導入紹介動画>
- x264guiExの導入
- x264guiExのエラーと対処方法>
- x264.exeはこちら>

x265guiEx
- x265を使用したH.265/HEVC出力
- x265guiExの導入>
- x265.exeはこちら>

QSVEnc + QSVEncC
- QuickSyncVideoによるHWエンコード
- QSVEnc 導入/使用方法>
- QSVEncCオプション一覧>

NVEnc + NVEncC
- NVIDIAのNVEncによるHWエンコード
- NVEnc 導入/使用方法>
- NVEncCオプション一覧>

VCEEnc + VCEEncC
- AMDのVCE/VCNによるHWエンコード
- VCEEnc 導入/使用方法>
- VCEEncCオプション一覧>

svtAV1guiEx
- SVT-AV1によるAV1出力
- svtAV1guiExの導入>
- SVT-AV1単体はこちら>

VVenCguiEx
- VVenCによるVVC出力
- VVenCguiExの導入>

ffmpegOut
- ffmpegを使用した出力
- ffmpegOutの導入>


○Aviutl フィルタプラグイン
自動フィールドシフト (ミラー)
- SSE2~AVX512による高速化版
- オリジナル: aji様

clfilters 
- OpenCLベースの複数のGPUフィルタ集
- 対応フィルタの一覧等はこちら

エッジレベル調整MT (ミラー)
- エッジレベル調整の並列化/高速化
- SSE2~AVX512対応
- オリジナル: まじぽか太郎様

バンディング低減MT (ミラー)
- SSE2~AVX512による高速化版
- オリジナル: まじぽか太郎様

PMD_MT
- SSE2~AVX512による高速化版
- オリジナル: スレ48≫989氏

透過性ロゴ (ミラー)
- SSE2~FMA3によるSIMD版
- オリジナル: MakKi氏

AviutlColor (ミラー)
- BT.2020nc向け色変換プラグイン
- BT.709/BT.601向けも同梱

○その他
Amatsukaze改造版
- AmatsukazeのAV1対応版

rkmppenc
- Rockchip系SoCのhwエンコーダ

x264afs (ミラー)
- x264のafs対応版

aui_indexer (ミラー使い方>)
- lsmashinput.aui/m2v.auiの
 インデックス事前・一括生成

auc_export (ミラー使い方>)
- Aviutl Controlの
 エクスポートプラグイン版
 エクスポートをコマンドから

aup_reseter (ミラー)
- aupプロジェクトファイルの
 終了フラグを一括リセット

CheckBitrate (ミラー, 使い方, ソース)
- ビットレート分布の分析(HEVC対応)

チャプター変換 (使い方>)
- nero/appleチャプター形式変換

エッジレベル調整 (avisynth)
- Avisynth用エッジレベル調整

メモリ・キャッシュ速度測定
- スレッド数を変えて測定
- これまでの測定結果はこちら

○ビルドしたものとか
L-SMASH (ミラー)
x264 (ミラー)
x265 (ミラー)
SVT-AV1 (ミラー)

○その他
サンプル動画
その他

○読みもの (ミラー)
Aviutl/x264guiExの色変換
動画関連ダウンロードリンク集
簡易インストーラの概要

○更新停止・公開終了
改造版x264gui
x264guiEx 0.xx
RSSリンクの表示
リンク
QRコード
QR