いくつかQSVEncCのほうに機能の追加。
[共通]HEVCエンコードが2.32からできなかった問題を修正。
[QSVEncC]・映像と音声の同期を保つためのオプションを追加。(--avsync forcecfr)
その名の通り、QSVEncが仮定している固定フレームレートを強制的に維持し、音ずれを防ぐオプション。具体的には、入力フレームの時刻が固定フレームレートによるフレームの表示時刻とずれてきたらフレームの間引き・水増しを行って調整する。
これによって最低限音ずれを防げるはず。(RFF, vfrでも…) ただ、処理の関係でメモリ使用量がそれなりに増えるので、固定フレームレートだとわかっている場合など、必要ない場合は使用しないでください。
このオプションはその名の通り、「映像と音声の同期を保つためのオプション」であって、「RFFを正しく処理する」ものではないことに注意。RFFを正しく処理するには、単なるフレームの水増しではなく、RFFフラグを見て、フィールドの入れ替え等の処理が必要になる。Media SDKには、MFX_PICSTRUCT_FIELD_REPEATEDという、いかにもRFFを意味するフラグが存在するが、QSVデコードされたフレームにこれは設定されておらず、RFFには全く対応していないように見える。RFFをちゃんと処理するには、QSVがRFFを解釈して、適切にフィールドを処理してくれるようにならなければどうにもならないと思う。…なんか方法があるのだろうか…?。
・QSVの処理速度に上限を設けたいときの設定を追加。(--max-procfps <int>)
デフォルトは0 (制限なし)。
例えば--max-procfps 90などとすると、そのストリームは最大でも90fpsでしか処理を行わないようになる。複数ストリームをQSVエンコードをしている際に、ひとつのストリームにCPU/GPUの全力を奪われたくないというときのためのオプション。
QSVEncはデフォルトでは(特に)エンコード開始時にフルパワーを使おうとするので、エンコードを開始したストリームがGPUを占有してしまい、他のストリームのエンコードを妨害してしまう。これに対して、このオプションで速度上限を設定しておけば、余力を確保でき、他のストリームも安定して処理することができる。
・シークしてからエンコードを開始するオプションを追加。(--seek [<int>:][<int>:]<int>[.<int>])
高速だが不正確なシーク機能。正確な範囲指定を行いたい場合は従来通り--trimで行ってください。
書式は、hh:mm:ss.ms。"hh"や"mm"は省略可。
・コマンドラインでエラーとなった時の情報表示を強化。もう少し親切に。
・入力fps判定をさらに改善。RFFでも誤判定しないように。・主に低解像度向け処理を高速化。
QSVEnc ダウンロード>>ダウンロード (ミラー) >>OneDriveの調子がいまいちの時はミラー(dropbox)からどうぞ。同じものです。QSVEncBenchmark.zipはベンチマーク用です。(約220MBと重いので注意)。run_benchmark.batをダブルクリックで実行です。
QSVEncCのオプションについてはこちら。
QSVEncCオプション一覧>
スポンサーサイト
更新ありがとうございます
早速--avsync forcecfrを使ってWOWOWを視聴してみたところ、音ずれなく視聴できることが確認できました。
ただ、メモリ使用量についてですが、--avsync forcecfrを付けても付けなくても際限なく増えているように見えます。
10分ほど視聴したところ、--avsync forcecfrを付けなくても1.5GBほど消費していて、更に使用量の上昇は止まっていませんでした。
すいません、更に長時間視聴したところ、--avsync forcecfrを付けない場合は使用量1.6GBほどで頭打ちになりました。
--avsync forcecfrを付けても1.7GBほどで頭打ちでした。
また、音ずれに関しても最初に見たWOWOWの番組がずれてなかっただけみたいで、その後もう一度確認したところ音ずれが発生してました。
ただ、徐々に音ずれが大きくなっていくのではなく、最初から一定の音ずれが発生している感じです。
libavformatでav_read_frame()使ってるなら普通にAVCodecParserContextから取得したrepeat_pict及びfield_orderじゃ駄目なの？
コンテナによるけど、ものによっては、例えばMPEG-2 TSならパケットからコーデックのビットストリームを結合するためにlibavformatは必ずparserを通すからAVCodecContextにぶら下がってる内部AVCodecParserContextから取得できるよ。
まぁ、なんか信用できない時あったから(結合処理のタイミングで出てくるパケットより後のパケットに含まれるであろうピクチャの情報が入ってる？)、私は外部でAVCodecParserContextを開きPARSER_FLAG_COMPLETE_FRAMESフラグ立てて(ピクチャパケット構築のための余計な結合処理を省くため)、av_read_frame()から取得したパケットを投げ込んで取得しているよ。
>使用量1.6GB
-i udp://127.0.0.1:%UDPPORT%?pkt_size=262144^&fifo_size=8000000
の部分で、当初こちらで適当に8000000などと書いてしまったのが原因と思います。すみません。
fifo_size=8000000 → fifo_size=1000000
としていただければ、600MBほどでおさまるようになります。
>最初から一定の音ずれ
手元では修正できており、現在公開前のテスト中ですので、もうしばらくお待ちください。
なるほど、AVCodecParserContextというのを使えばQSVに頼らずともそういった情報が取得できるのですね。教えていただきありがとうございます。ちょっと使い方を調べてみます。
field_orderがわかると、デコーダの入力packetと出力フレームの関係が分かりやすくなりそうです。
本当はフレームのptsぐらいはQSVデコーダがちゃんと返してくれるとよいのですが、入力によってはよくわからないptsを出してくるので謎です。初期化方法とかに間違いはないはずなのですが…。なにか忘れているのか…。
QSVのエンコード/デコードはCFR前提だから、VFRっぽいPTSをぶちこむとなんかおかしくなったと思う。そうじゃないなら、よくわかりませんが。いずれにせよ、MPEG-2 Video, VC-1なら入力PTSをキャッシュに入れておけば、フレームタイプから出力される順番がわかるし、AVC, HEVCはreorderingによる規格上の最大遅延の16フレーム分のキャッシュを以ってPOC見れば順番わかるから、そこから適当なPTSとDTSを生成できるでしょう。
そうですね、いままではパケットがフィールドかどうかわからなかったので、パケットのptsをキャッシュしていてもフレームとの対応関係が分かりませんでしたが、AVCodecParserContextを使えば、そのパケットがfieldかどうかもわかるということですので、そうであればおっしゃるようにQSVデコーダに頼らずptsの取得ができると思います。
＞もさ様
テストが完了したので、2.35を公開しました。最初から少し音ずれする問題が解消するかと思います。
http://rigaya34589.blog135.fc2.com/blog-entry-752.html
素晴らしいソフトをありがとうございます。
TvRemoteViewer_VBとコマンドラインの両方で試してみましたが新機能の--seekが機能していないようです。
確認していただけないでしょうか。
こちらでは下記のようなコマンドでテストしていまして、
QSVEncC.exe -i test.ts -o test.mp4 --seek 0:00:30 --audio-copy
のようにするとファイルの頭から約30秒飛ばしたところからエンコードされているのですが、どのようなコマンドの場合にうまく動作しないか教えていただけないでしょうか?
お返事ありがとうございます。
全く同じコマンドで試しましたが駄目でした。
エンコードは終了しtest.mp4も視聴できましたが0秒から出力されていました。
ログ↓にはseek: 0:00::30.000と表示されています。
http://www1.axfc.net/u/3623852?key=qsv
もしかするとQSVEncCのインストールがうまくいっていない可能性もあるでしょうか
qsvenccを久しぶりにアップデートしたら
以前出来ていたx264へのtsのデコード、パイプライン渡しが出来なくなりました。
2.26では正常に実行出来ています。
調べてみると2.27からエラー終了するようです。
コマンドラインは以下の様に実行しています。
--avqsv --tff --vpp-deinterlace normal --output-res 1280x720 --vpp-delogo "d:\test\logo.ldp2" --vpp-delogo-select "CX" --trim 2027:4573,5923:6971
-i d:\test\test.ts -o - -c raw 2>qsvenc.log | x264.r2597kMod.exe --demuxer y4m --threads auto --thread-input --preset veryfast --b-adapt 2 --vbv-maxrate 8000 --vbv-bufsize 30
00 --profile high -v --crf 23 --log-level info -o "d:\test\test.h264" -
出力ログは以下の通りです。
QSVEncC (x86) 2.27 by rigaya, Jan 17 2016 08:50:05 (VC 1900/Win/avx2)
OS Windows 7 (x64)
CPU Info Intel Core i5-3570T @ 2.30GHz [TB: 3.00GHz] (4C/4T) <IvyBridge>
GPU Info Intel HD Graphics 2500 (6EU) 350-1150MHz [45W] (10.18.10.3958)
Media SDK QuickSyncVideo (hardware encoder), 1st GPU, API v1.11
Async Depth 8 frames
Buffer Memory system, 1 input buffer, 22 work buffer
Input Info avcodec video: MPEG2, 1440x1080, 30000/1001 fps
VPP Enabled delogo[AVX], CX
Deinterlace (normal)
Resizer, 1440x1080 -> 1280x720
Trim 2027-4573 5923-6971 [offset: 0]
Output 1280x720p 0:0 29.970fps (30000/1001fps)
Failed to get free surface for vpp pre.
[18.3%] 1 frames: 0.29 fps, 331444.56 kb/s, remain 0:00:15
Failed to SynchronizeFirstTask : failed to lock the memory block.
Error in encoding pipeline. : failed to lock the memory block.
error at encode thread.
encoded 5 frames, 0.37 fps, 331444.56 kbps, 6.59 MB
encode time 0:00:13, CPULoad: 6.08, GPULoad: 33.04, GPUClockAvg: 650MHz
frame type IDR 5
frame type I 5, total size 6.59 MB
QSVEncC.exe finished with error!
回避策はないでしょうか？
ログの情報など、いただきましてありがとうございました。
わたしのほうでもうまく動かない例を見つけ、2.36で修正できていると思います。
http://rigaya34589.blog135.fc2.com/blog-entry-753.html
2.27では、いろいろいじってしまったため、そのあたりに原因ではないかと思っています。しかしながら、いただいたコマンドラインで同様のエンコードを行いましたが、こちらでは正常に終了してしまい、具体的な原因を特定できておりません。
環境は以下の通りです。
i7 4770K <Haswell> / Win 8.1 x64 / 4332ドライバ / API 1.16
i7 6700K <Skylake> / Win 8.1 x64 / 4352ドライバ / API 1.17
報告いただいている環境とはかなり違いますので、そのあたりが原因かもしれません。どう調べたらよいか…考えてみます。
更新ありがとうございました。
ばっちりシークできました。
やっと原因と思われるところを見つけました。
こちらでは現象を再現できていないため、修正できたと断言はできませんが、2.37にて修正できているのではないかと思います。よろしければお試しいただければと思います。
http://rigaya34589.blog135.fc2.com/blog-entry-755.html
