ffmpeg の -probesize オプションに相当するオプションを実装してほしい

QSV/NV/VCEEncC を TVRemotePlus にて使わせていただいています。ありがとうございます。

さて、TVRemotePlus のライブ配信は TSTask から受け取った UDP の MPEG2-TS ストリーム（放送波）の映像を H.264 に再エンコードし、HLS (m3u8+TS) 形式に変換してそれをブラウザで再生する事で実現しています。しかし、ffmpeg と、ffmpeg をベースに使用している QSV/NV/VCEEncC では受け取った TS ストリームを認識するまでに時間がかかり、その影響でブラウザ上で再生が開始されるまでに時間がかかってしまっています。

TSTask が物理チューナーを開く時間
TSTask がチャンネルを切り替える時間
ffmpeg・QSV/NV/VCEEncC が UDP で受け取った TS ストリームを認識するまでの時間
ffmpeg・QSV/NV/VCEEncC でエンコードする時間
ブラウザで HLS のマニフェストをダウンロード・解析する時間
ブラウザで HLS のセグメントをダウンロード・再生する時間

ストリームを開始してからブラウザ上で再生が開始されるまでにかかる時間は上記のように積み重なっていますが、このうち 3 番の「ffmpeg・QSV/NV/VCEEncC が UDP で受け取った TS ストリームを認識するまでの時間」にボトルネックがあることがわかりました。UDP が問題なのかとも思い TCP やパイプで渡してみたりもしたのですが、同様の状態でした。

ところが最近、ffmpeg にて試しに -i オプションの前に -f mpegts -probesize 8192 -analyzeduration 0 を指定してみたところ、 3 番にかかる時間が大幅に短縮され、結果的にブラウザ上で再生が開始されるまでの時間を2～3秒も短縮することができました。 -probesize と -analyzeduration はいずれも入力ストリームの解析を行う上限のバイト数と時間(秒)を指定するもののようですが、これをあえて低い値にすることで入力の解析時間を短縮し、それが全体の時間短縮に繋がっているものと考えられます。入力がパイプで出力が MPEGTS (H.264) の場合は -probesize を最小の 32 にまで小さくすることもできるようですが、UDP で HLS 出力という関係か、8192 が実用上の限界でした。それでも 2 秒も短縮されるのは大きいです。

しかし、QSV/NV/VCEEncC には ffmpeg の -probesize に相当するオプションがありません（少なくともオプションを確認した限りはそう見えます）。 -f に相当するオプションは --input-format、-analyzeduration に相当するオプションは --input-analyze として存在するようですが、-probesize に相当するオプションが今のところないため、QSV/NV/VCEEncC では再生開始までの時間を短縮できていません。

そこで、QSV/NV/VCEEncC にも -probesize に相当するオプションを実装していただけないでしょうか？試しに QSVEncC・NVEncC で --input-format mpegts --input-analyze 0 のように ffmpeg の -probesize 以外の相当するオプションを追加してやってみましたが、明らかな短縮効果は感じられませんでした。-probesize と組み合わせて初めて短縮効果が出るみたいです。

この手法を教えて頂いた方いわく、QSV/NV/VCEEncC の -probesize は 0.5GB で固定になっているとのことでした ( https://github.com/rigaya/QSVEnc/blob/8ca51bb13bd6052def2b9372fbba4d76098eaf93/QSVPipeline/rgy_input_avcodec.cpp#L1207-L1214 )。avformat_find_stream_info に probesize を指定する事は難しくないんじゃないかとも ( https://programmersought.com/article/430134736/ )。私は C++ も libav も分からないのでさっぱり理解できていませんが…

私がメインで使わせて頂いているのが NVEncC なのでこちらのリポジトリに投稿させていただきましたが、もし可能であれば他の QSVEncC・VCEEncC にも実装していただけると大変助かります。お忙しいとは思いますが、ぜひご検討をよろしくお願いします。

要望とその背景を説明いただきありがとうございます。

ご指摘の通り、probesizeを指定できるようにすること自体は比較的難しくないので、--input-probesizeとしてオプションを追加したものを添付しました。(→ NVEncC64_5.31beta1.zip)

また、このバージョンではわずかですがいくつか初期化処理の高速化を図りました。

冗長な処理のスキップ
内部バッファ削減(16→1)による遅延削減
--input-analyzeを小数点で指定できるように
--input-analyzeが1秒以下の時、通常48フレーム読み込んで行うフレームレート推定処理をスキップ

ただ残念ながら"--input-format mpegts --input-analyze 0 --input-probesize 8192"での動作は難しいです。

avformat_find_stream_info は映像/音声のヘッダーを認識してその情報を取得するとともに、フレームレートを推定する重要な処理となっています。

しかし、ts ではデータの先頭がGOPの先頭とは限らないことから、analyzeduration や probesize が小さすぎるとGOPの先頭にあるヘッダーにたどり着けないことがあります。その結果、デコードに必要なヘッダー情報やエンコードに必要な映像の情報(解像度、フレームレート等)が取得できなくなってしまいます。

たとえば、ffmpegでも"-f mpegts -probesize 8192 -analyzeduration 0"とすると一部tsファイルでは下記にようにエラーメッセージがでてしまいます。

[mpegts @ 00000248751fe0c0] Stream #2: not enough frames to estimate rate; consider increasing probesize [mpegts @ 00000248751fe0c0] decoding for stream 2 failed [mpegts @ 00000248751fe0c0] start time for stream 1 is not set in estimate_timings_from_pts [mpegts @ 00000248751fe0c0] start time for stream 3 is not set in estimate_timings_from_pts [mpegts @ 00000248751fe0c0] PES packet size mismatch [mpegts @ 00000248751fe0c0] Packet corrupt (stream = 0, dts = 4864449098). [mpegts @ 00000248751fe0c0] Could not find codec parameters for stream 2 (Video: mpeg2video ([2][0][0][0] / 0x0002), none(tv)): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options

太字部分が問題で、この状態では、エンコードに必要な映像の情報が取得できず、エンコードを開始することができません。(NVEncCではエラー終了するようになっています)

ffmpegはこの状態でもなんとかしているのだとは思うのですが、いったいどうやっているのか、すみません、よくわかりません。ffmpegと同様の動作にはできていないのかと思います。

個人的に少し試した感じでは、現状のNVEncCの実装ですといまのところ下記オプションぐらいが限界のように感じていて、probesize等でそれ以上削るのは難しいかもしれません。

--input-format mpegts --input-analyze 0.66

ただ、初期化時の遅延についてもある程度は改善できているので、まずは添付した添付した5.31beta1(→ NVEncC64_5.31beta1.zip)をお試しいただき、ご意見いただければ幸いです。

よろしくお願いいたします。

早速の実装ありがとうございます！こちら側で試してみます。

色々試してはいるのですが、正直 ffmpeg ほどうまくいっていない感じです。 --input-analyze を 0.66 まで縮めると、UDP送信が開始された後も延々とエンコードが開始されないことがありました。エラーは出ていません。1.0 でもそんなに変わらない？ようです。 …というよりも、どういう訳か番組内容？タイミング？によってUDP送信開始からストリーム認識までの時間がかなり変わるようで、それが元々遅い番組だと --input-analyze 0.66 だと認識までの時間がさらに伸びてしまう（TVRPの場合、一定時間以上エンコードが開始されなかったら強制終了になるのでどのくらい時間を掛けたら認識するのかは不明）ことがあるみたいです。まだ完全に挙動を検証できていないので本当に合っているかどうかは微妙ですが、取り急ぎ報告まで。

状況のご連絡ありがとうございます。

まだNVEncC側の改善が必要そうですね。

GWの時間を利用してffmpegの挙動と比較するなどして、もう少し改良できないか見てみたいと思います。

ありがとうございます。

こちらでも色々試してはいるのですが、どうも挙動がはっきりとわからなくて、なんとも言えないもどかしい状態です。 UDPで受信しているのを標準入力からに変えたらまた変わってくるのか、エンコーダーを立ち上げてから実際にストリームが到着するまでに時間がかかるというのもあるんだろうか…など。

こちらの環境が悪いのかもしれませんが、番組やタイミングによってストリームの認識にかかる時間がかなり変わる？ようで、一定ではなく、早かったり遅かったりするみたいです。同時間に放送されているチャンネルでも、明らかにストリームの認識が早いチャンネルと遅いチャンネルが存在します。しかもチャンネルによって固定というわけでもないので、ますますよくわかりません。本当にひどいときだとUDP送信はとっくに始まっているのに、ストリームの認識に10秒以上待たされる事もありました。

ストリームの認識が早いチャンネル/番組、遅いチャンネル/番組はたしかにあるようなんですが、タイミングによっても？早い遅いは変化するようで、これも一定ではありません。それもあってよくわからないでいます。 TVRemotePlus にはすでに視聴中の場合でチャンネルを切り替える場合に TSTask を使い回す（=チューナーのオープンからやり直さず、チャンネルの切り替えだけを行う）機能があり、その場合だとエンコーダーが起動した時点でUDP送信が開始されている状態がほとんどでブラウザで再生が開始されるのもチューナーのオープンがない分早くなる（特にチューナーオープンが遅いPLEX製品、PT3はチューナーのオープン自体がかなり速いのでそこまで差を感じられない）のですが、その場合でもストリームの遅いチャンネルは本当に遅いです。これに関しては同時に別々のチャンネルを同時にストリーム開始して確認しました。確認当時は tvk の試験放送が認識に13秒程度かかっていました。

これは今回の beta 版の更新による問題ではなく、以前からこのような状態だったようです。エンコーダーが違うからか完全に同じ認識秒数というわけでもないようですが、QSVEncC でも同様の傾向がありました。NVEncC で認識が遅いチャンネルは QSVEncC でも遅いし、その逆も然り。

そして、ffmpeg + -f mpegts -probesize 8192 -analyzeduration 0 だと、どのチャンネルも同じくらいの認識秒数（TSTaskとffmpegの挙動を見る限り、UDP送信開始直後にエンコードが開始されているのでほぼ待機なし）で安定しています。ブラウザで再生が始まるまでの秒数はトータルで8～10秒程度でしょうか。QSVEncC/NVEncC だと早いときでも10秒～12秒くらいはかかってる気がします（目測なので精度は微妙）。先程例として挙げた tvk の試験放送も、QSVEncC・NVEncC 両方ともかなり認識に時間がかかっていましたが、ffmpeg だと他のチャンネルとほぼ変わりません。チャンネル切り替えはチューナーのオープンを伴わず、前述したように認識にほとんど時間がかからないため爆速で、トータル4秒程度で再生が始まります。このあたりはHLS側の再生バッファも絡んでくるので、それがなければ2秒程度までなるんじゃないかという印象です。

というわけで、現時点では ffmpeg だとチャンネルによって認識時間が変わったりもせずほぼ一定で素早くストリームを認識してくれるけど、QSVEncC・NVEncC（環境がないのでわからないけど、おそらく VCEEncC も）ではどういうわけかチャンネルによって認識時間が変わったりがあるし、--input-probesize や --input-analyze を付与してもうまくいかない状態です。

1. NVEncCの改善

実際にTVRemotePlusを導入し、いろいろなチャンネルで動作確認を行いました。たしかに、エンコード開始に非常に時間のかかってしまうタイミングやチャンネルがありました。

私は従来avformat_find_stream_infoを呼ぶ時に時間がかかる想定でいたのですが、実はavformat_open_inputを呼ぶ時にも時間がかかっていることがわかりました。

より詳細に調べると、ご指摘のように--input-analyzeはどのように指定しようが、ストリームの認識が遅い場合があり、これを防ぐには--input-probesizeをavformat_open_inputを呼ぶ前に設定して防ぐ必要があることがわかりました。このあたりの実装見直しを行ったNVEncC 5.31 beta2を添付しました。NVEncC64_5.31beta2.zip

このとき、--input-probesize 8192のような設定では、0.5秒に1回程度やってくるGOPの先頭についている映像のヘッダを認識できずエラーとなってしまいます。これを防ぐため、--input-probesizeを適切に指定する必要があります。--log-level debugで詳細なログを見ると、avformat_open_inputを呼ぶ時と、avformat_find_stream_infoを呼ぶ時のそれぞれで、probesize分のデータが読まれることがわかりますので、

probesize * 2 > 余裕をもって0.6秒ぐらい * 各チャンネルのtsのビットレート

となるように設定する必要があります。

チャンネルごとにビットレート(スロット数)が違うので厄介ですが、BSの最大ビットレートを24Mbps(=3MB/s)とす仮定すると、probesize=900K程度がよさそうです。

まずは添付の実行ファイルNVEncC64_5.31beta2.zipをお使いいただき、 --input-format mpegts --fps 30000/1001 --input-analyze 0.67 --input-probesize 900k でお試しいただけないでしょうか。ffmpegほど早くなってはいないと思いますが、長く待たされる、ということはかなり減ったのではないかと思います。

2. ffmpegの挙動の確認

次に、ffmpegの-f mpegts -probesize 8192 -analyzeduration 0を使用した場合の挙動を確認しました。

このとき、mpegtsの構造認識は終わっているものの、映像のヘッダ情報をとれていないという状態のまま、次に進んでいるようです。まあたしかに、これならavformat_find_stream_infoはすぐ終わります。

[mpegts @ 000002c737f785c0] Probe buffer size limit of 8192 bytes reached
[mpegts @ 000002c737f785c0] Stream #1: not enough frames to estimate rate; consider increasing probesize
[mpegts @ 000002c737f785c0] decoding for stream 1 failed
[mpegts @ 000002c737f785c0] Could not find codec parameters for stream 1 (Video: mpeg2video, 1 reference frame
 ([2][0][0][0] / 0x0002), none(tv)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options

ただその後、ヘッダーがない状態でデコーダを起動しているので、しばらくデコードエラーが出ていますが、

[mpeg2video @ 000002c737fb4b00] Invalid frame dimensions 0x0.
Error while decoding stream #0:1: Invalid data found when processing input
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
    Last message repeated 1 times

途中で(おそらくGOPが切り替わりヘッダを認識したところで)回復しています。

[mpeg2video @ 000002c737fb4b00] Format yuv420p chosen by get_format().
[mpeg2video @ 000002c737fb4b00] video_delay is larger in decoder than demuxer 1 > 0.
If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
    Last message repeated 1 times
[mpeg2video @ 000002c737fb4b00] Skipping B slice due to open GOP
    Last message repeated 67 times
[mpeg2video @ 000002c737fb4b00] video_delay is larger in decoder than demuxer 1 > 0.
If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
    Last message repeated 2 times
[mpeg2video @ 000002c737fb4b00] Skipping B slice due to open GOP
    Last message repeated 67 times
[mpeg2video @ 000002c737fb4b00] video_delay is larger in decoder than demuxer 1 > 0.
If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
    Last message repeated 1 times
[mpeg2video @ 000002c737fb4b00] video_delay is larger in decoder than demuxer 1 > 0.
If you want to help, upload a sample of this file to ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list. (ffmpeg-devel@ffmpeg.org)

このように、ffmpegはとりあえずデコーダ・エンコーダを起動してしまい、デコードできるようになってから処理できるようになっているようです。

現状NVEncCはffmpegのようにデコーダのエラーを許容するようになっていないので、これとまったく同様の動作の再現は現状では難しいです。

まずは上記1.で示したような対応方法をお試しいただけないでしょうか。1.の方法でも遅いようですと、さらにNVEncCの実装見直しが必要になりそうです。

よろしくお願いいたします。

わざわざ導入までしていただいての素早いご対応に感謝します。ありがとうございます。

全体的にストリーム開始までの時間が（ffmpeg ほどとまではいきませんが）いくらか短縮され、またまちまちだったストリームの認識時間もあまり変わらなくなっていると思います。少なくとも、ストリームの認識に10秒以上かかることはなくなりました。おっしゃる通り ffmpeg での -probesize 8192 はかなり無理をしているようで、失敗することはないもののエラーログがドバドバ出ながらエンコードしている感じですね。（修正できるレベルのものかどうか分かりませんが）ちょっと気になった事としては、コンソール上でエンコードが開始されているように見えるのにも関わらず、実際の m3u8+ts 出力が行われておらず（？）、エンコード開始から5秒以上経ってからようやく一気にファイルが出力される（？）ような現象がたまにあります。

avcuvid: Input video info not parsed yet [0x0]!
avcuvid: Consider increasing the value for the --input-analyze and/or --input-probesize!
failed to initialize file reader(s).
Failed to open input file.

あとはごくまれに上記のようなエラーが出てエンコーダーが落ちてしまうことがあったくらいでしょうか。これに関してはちょっと probesize 諸々縮めすぎって事なんでしょうけど…

早速お試しいただきありがとうございます。一定の効果が得られていてよかったです。

あとはごくまれに上記のようなエラーが出てエンコーダーが落ちてしまうことがあったくらいでしょうか。これに関してはちょっと probesize 諸々縮めすぎって事なんでしょうけど…

おっしゃる通りprobesize を縮めすぎということになるのですが、このエラーでエンコーダが落ちてしまうとストリームの立ち上がりがだいぶ遅くなってしまうので、こちらの問題への対策として、新たに--input-retry <int>というオプションを追加しました。NVEncC64_5.31beta3.zip

avcuvid: Input video info not parsed yet [0x0]!の問題が発生したことを検知した場合に、エラーで落とすのではなく、--input-probesizeと--input-analyzeを前回の1.5倍にしたうえでストリームのオープンをやり直す機能です。指定する値はやり直しの最大回数で、適当に--input-retry 15などにしておけばよいように思います。やり直しなしの時と比べて時間はどうしてもかかりますが、エンコーダが落ちてしまうのに比べればよくなったように思います。

（修正できるレベルのものかどうか分かりませんが）ちょっと気になった事としては、コンソール上でエンコードが開始されているように見えるのにも関わらず、実際の m3u8+ts 出力が行われておらず（？）、エンコード開始から5秒以上経ってからようやく一気にファイルが出力される（？）ような現象がたまにあります。

--log-level debugをつけるとファイル出力のタイミングがログに出ますが、わたしのほうではあまりラグがあるようには見受けられませんでした。なにか条件などがあるのかもしれませんが…

返信ありがとうございます。

以前書いた tvk の放送休止の番組（カラーバーとビープ音が延々と流れるやつ）は、5.31beta3 でも残念ながらストリームの認識が遅いです。ffmpeg（字幕なし）では他の番組同様速いです。もちろん放送休止の番組が早く見れる事自体に意味はありませんが、他の番組でもそういう認識が遅くなるケースがあるのではないかと少々気になります。今のところその番組よりストリーム認識が遅い番組は見つけていませんが。ただし、その番組以外では概ね早めに認識できていそうなので、よくわかりません。取り急ぎ報告まで。

少し話がそれてしまいますが、エンコーダーのストリーム認識時間の件と同時並行で、arib-subtitle-timedmetadater を TVRemotePlus に導入する準備をしています。develop ブランチにてテスト中です。

arib-subtitle-timedmetadater は monyone 氏が~~謎の技術で~~作成されたツールで、ARIB 字幕を timed_id3 (ID3) メタデータに変換します（具体的には ARIB 字幕のバイナリをそのまま BASE64 エンコードしているらしい）。その ID3 メタデータをブラウザ側で aribb24.js の CanvasID3Renderer() を使って読み取ることで、ARIB 字幕を直接 HLS でエンコード後の TS 内にコピーしなくても timed_id3 ストリームが HLS でエンコード後の TS 内に入っていれば字幕を描画できるようになるというものです。

元々 ARIB 字幕を再生するような仕様が HLS にある訳がありませんから、従来の手法の場合、HLS の再生には hls-b24.js のような TS から ARIB 字幕を取り出せるようにパッチを当てた hls.js（HLS 再生ライブラリ）を使う必要がありました。また、iOS Safari の制限で hls.js を使うことができない（内蔵 HLS プレイヤーを使うほかない）iOS では字幕を TS から取り出せないので、字幕を描画できないという問題がありました。

さらに、ffmpeg 4.2.0 以降は ARIB 字幕が arib_caption と字幕の一形式として認識されるようになりました。ffmpeg の HLS エンコーダーは字幕ストリームを強制的に webvtt に変換しようとしますが、arib_caption から webvtt に変換するエンコーダーはないためエラーで落ちてしまいます。monyone 氏開発の arib-subtitle-unrecognizer という arib_caption として認識させなくする~~またもや謎の技術~~ツールを噛ませばなんとかなるようですが…。

一方、ID3 メタデータが HLS の TS 内に入っている状態は HLS の仕様で規定されているようで、そのため TS セグメント内の ID3 メタデータであれば hls.js でも iOS Safari の内蔵 HLS プレイヤーでも標準で読み取る事が可能です。この新方式では従来の方法では不可能だった iOS Safari でも字幕を表示できるようになるので、今試しに実装してみています。

前置きが長くなりました。

さて、arib-subtitle-timedmetadater は TSTask から送信されてくるストリーム入力とエンコーダーとの間に入りそこで ARIB 字幕 → ID3 メタデータへ変換したTSを出力するため、必然的にエンコーダーではなく arib-subtitle-timedmetadater にて UDP 受信を行い、変換結果をパイプで NVEncC を含め各種エンコーダーに渡すような形態になります。

なのですが、先ほど実装いただいた --input-retry オプションをつけると、（意図的にリトライさせるために --input-probesize を 300K くらいに縮めた場合で）arib-subtitle-timedmetadater がエラーで異常終了してしまいます。さらに標準出力に出力されたエラーメッセージを NVEncC が受け取ってしまい結果 NVEncC がフリーズするという最悪な事になってしまうので、今のところ --input-retry は機能していません…。

avcuvid: Failed to get video stream information, retry opening input (1/15)!
events.js:183
      throw er; // Unhandled 'error' event
      ^

Error: EPIPE: broken pipe, write
    at Socket._write (internal/net.js:23:7)
    at doWrite (_stream_writable.js:396:12)
    at writeOrBuffer (_stream_writable.js:382:5)
    at Socket.Writable.write (_stream_writable.js:290:11)
    at Socket.write (net.js:711:40)
    at MetadataTransform.ondata (_stream_readable.js:639:20)
    at emitOne (events.js:116:13)
    at MetadataTransform.emit (events.js:211:7)
    at addChunk (_stream_readable.js:263:12)
    at readableAddChunk (_stream_readable.js:250:11)

arib-subtitle-timedmetadater のエラー内容は上記の通りで、monyone 氏に問い合わせたところ「GitHub に上げられてないので差分が全く分からない…」「どのみち broken pipe になった時点でできる事ないし、入力を閉じないでくれというしかないですね」とのことでした。エラーからして、arib-subtitle-timedmetadater は標準出力に出力しようとしたが、NVEncC の入力は閉じられているので（？）出力に失敗したって所なのかなと想像してます。リトライした時に入力を開けたままにすることができれば arib-subtitle-timedmetadater が broken pipe で落ちることもないはずなので、もし可能であればそのあたりの対応をお願いします（大雑把な要望で本当にすみません…）。

次に、この手法の場合、あらかじめ arib-subtitle-timedmetadater によって挿入された timed_id3 ストリーム（注：ARIB 字幕のストリームを上書きするわけではなく、その隣のストリームとして挿入されるっぽい）をエンコーダーにコピーしてもらう必要があります。 ffmpeg では -map 0 -ignore_unknown もしくは -map 0:v -map 0:a -map 0:d で timed_id3 ストリームをコピーすることができます。ARIB 字幕をそのままコピーする時と同じです。 ffmpeg では timed_id3 ストリームだけを指定してコピーできないので、ARIB 字幕の bin_data ストリームと timed_id3 ストリーム両方が同じデータストリームとして HLS エンコード後の TS セグメントに入る感じになります。 NVEncC ではてっきり --metadata オプションあたりでいけるかと思ったのですが、timed_id3 ストリームは「Timed」なので普通のメタデータとは異なりデータストリーム扱いになっているらしく、現状の NVEncC のオプションではコピーする事ができなさそうでした（私が見落としているだけかもしれませんが）。

そこで、timed_id3 ストリーム（もしくはデータストリーム全体）をコピーするオプションを実装していただけないでしょうか？ timed_id3 ストリームが HLS エンコード後のストリームにコピーできれば、NVEncC でも（ストリームの認識時間はさておき）新方式で字幕を表示できるようになります。ffmpeg で -map 0:v -map 0:a -map 0:d を使い新方式で字幕が表示できることは確認しています。

正直 arib-subtitle-timedmetadater を使った新方式は、ほかにも

現状 arib-subtitle-timedmetadater でパケットロスなく TSTask の TCP or UDP ストリームを受信できない
- ffmpeg で UDP 受信する場合と異なり、エンコード当初になぜか大きめのパケットロスが起きる
- TCP 受信では継続的に小さめのパケットロスが起きる
ffmpeg で -map オプションを使うと -probesize や -analyzeduration を指定した場合でも HLS のエンコード開始がなぜか8～10秒程度遅れてしまい字幕と速度がトレードオフになってしまう
- ストリームの認識はしている
- ARIB 字幕をそのままコピーしていた頃からこうなので（そもそもコマンドがほぼ変わっていない）以前からの課題

などの面倒な課題を抱えていて一筋縄ではいきそうにないのですが、NVEncC (QSVEncC/VCEEncC) 側で対応していただければゴールが見えてきそうです。

…かなり長文になってしまいました。次々と無理なお願いをしてしまい心苦しいのですが、もし余裕があればお願いしたいです。

現状と今後の開発予定について詳細にお知らせいただき、ありがとうございます。

1. input-retryについて

なるほど、標準出力をNVEncCで受ける形を検討されているのですね。--input-retryを作成したときは、NVEncCがUDPを受ける形を想定していたので、このような形態は考慮しておりませんでした。--input-retryの実装はUDPから流れてきていることを想定しているので、ファイルクローズ→ファイルオープンによる再初期化を行うようになっています( 527b62a )。

さらに標準出力に出力されたエラーメッセージを NVEncC が受け取ってしまい結果 NVEncC がフリーズするという最悪な事になってしまうので、今のところ --input-retry は機能していません…。

エラーメッセージだけの問題ならエラーメッセージは標準出力でなくエラー出力に出せばよいだけですが、それだけでは解決しなそうですね。ファイルオープンしたままの再初期化は難しく、すみませんがいまのところこれ以上の改善案が浮かびません。現状のように、お手数ですがTVRemotePlus側でのプロセス再起動が妥当な対策と思います。

2. timed_id3 の転送

ご指摘のようにtimed_id3はデータストリーム扱いのため、NVEncCでは--data-copy をご利用ください。また、NVEncC64_5.31beta4.zipではコーデックを選択してのコピーを可能としました。その場合は、--data-copy timed_id3 と指定してください。

3. arib-subtitle-timedmetadater について

developブランチを使用させていただき、arib-subtitle-timedmetadater を使用してテストしてみましたが、正常に処理できなさそうでした。私の使い方の問題かもしれませんが、どうも timed_id3 ストリームのタイムスタンプがずれてしまっているように見受けられました。

本日のNHKを処理したときのNVEncCの受け取ったパケットのタイムスタンプを出力しました。(NVEncC64_5.31beta4.zipで--log-packetsを指定するとstream1.m3u8と同じフォルダにstream1.m3u8.packets.csvとして出力されます)

stream1.m3u8.packets.csv.txt の一部を抜粋します。一番右の列がタイムスタンプです。

stream  0,   mpeg2video, pts, 3655619432
stream 12,          epg, pts, Unknown
stream  1,          aac, pts, 3655604920
stream  0,   mpeg2video, pts, 3655613426
stream  1,          aac, pts, 3655606840
stream  3,    timed_id3, pts, 7950612296 <<<< 周りのタイムスタンプと比べると大きくずれている
stream  2, arib_caption, pts, 3655645000
stream  1,          aac, pts, 3655608760

このように、timed_id3 ストリームのみタイムスタンプが大きくずれてしまっており、正常に処理することが難しいです。ただ、すみません、原因や問題が発生する条件などはわからなかったです (なにか私のほうで導入ミスをしたかもしれませんが…)

4. 字幕mux時の8～10秒程度の遅延

これはffmpegに限らず、NVEncC等でも発生する遅延で、muxキューによる遅延と考えらます。

出力tsに映像と音声と字幕の各トラックをmuxして出力する際、各トラックの処理にかかる遅延はトラックごとに異なるので、データが常に同時にやってくるとは限りません。mux処理では、こうしたずれを調整し、各トラックのデータパケットの時刻(=タイムスタンプ)を同期して、同時刻のデータは近くに出力するよう調整する必要があります。

このとき、字幕データの扱いは難しく、継続的にデータが流れてくる映像や音声と異なり、字幕に関しては字幕のない時間というのが存在しますので、ある時刻に字幕データがあったりなかったりします。

mux処理では、字幕がない箇所では、字幕データがないことを確認するために、一定の時間(デフォルト=10秒分)映像や音声のデータをmuxキューにためて、その間字幕データがなければ字幕データがないと判断するようになっています。字幕を出力する際に10秒遅延が増加するのはこのためです。

今回のようなリアルタイムエンコードでは、10秒も待たなくてよいのではないかと思います。muxキューが待機する長さは下記オプションで調整可能です。下記では5秒にする例を示しました。

ffmpeg: -max_interleave_delta 5M NVEncC: -m max_interleave_delta:5M

なお、あまり短くしすぎると、字幕や音声のタイミングずれにつながりますのでご注意いただければと思います。

1. input-retryについて

そうでしたか… わかりました。折角実装していただいたのに本当に申し訳ないです。

本来は些細な事で止まりがちなエンコーダーを監視するバックグラウンドプロセスを立ち上げて、その中でエンコーダーなどの出力を管理する（エンコーダープロセスの立ち上げ、ログの監視、エンコーダーが停止したら再起動、エンコード停止命令があればプロセスをKillする）のがベストだと思うのですが、元々軽い気持ちで試しに作ってみたツールに積み木のように後先考えず機能追加を繰り返していった結果コードが最悪な事になってしまっていて、そのような大幅な変更は現状難しいです。現状では start コマンドでエンコードプロセスを PHP 側から非同期で開始し、終了するときはコマンド列に含まれる 8201 のような UDP 受信用のポート番号から該当のエンコーダーや TSTask を割り出して taskkill するという相当強引な実装になっています…。今もリトライ機能こそありますが、m3u8 が30秒以内に更新されているかどうかだけで見ているのでエンコーダーが落ちた場合に把握できないなど、かなりアバウトです。

ただ、いつになるかは分かりませんが TVRemotePlus の後継ソフト（機能的には似たようなソフトだが、Python（PHP では Windows 固有の問題に対処する事が難しいため）で一から作り直しもっと使いやすくする）を作る計画を練っていて、その時にはちゃんと実装するつもりでいます。今回の arib-subtitle-timedmetadater の導入に関しても、正直私自体は iOS 端末をあまり使っていないので対応するメリットは薄いのですが、受信→エンコード→配信周りはロケフリソフトの肝であり最も難しい部分なので、先にそのあたりの技術を概ね確立しておいて、後継ソフトの開発に着手したときに比較的スムーズに実装できるようにしたいという目論見もあったりします。

2. timed_id3 の転送

最新の develop ブランチにおいて NVEncC で --data-copy timed_id3 を使うようにしました。ストリームのコピーに関しては特に問題は発生していないように感じます。

このあたりを調査している時に音声多重放送+字幕放送の場合に副音声で再生されてしまうケースがあったため、そのあたりのエンコードコマンドを調整しました（音声多重放送の番組を見ないので知らなかったけど、この件と関係なく前からだったかもしれない…）。音声多重放送の副音声の方に切り替える機能は、需要がそこまでない上に余計にややこしくなるのが目に見えていたので今回は考えない事にします。後継ソフトの開発時には考慮したいですね。

3. arib-subtitle-timedmetadater について

前回のレスで報告した時に挙動確認を怠った私のミスなのですが、その時点での arib-subtitle-timedmetadater には不具合があり、ビット演算が JS だと丸められてしまう（？）とかで正しくない PTS が出力されてしまっていたみたいです。最新の develop ブランチの更新された arib-subtitle-timedmetadater では正しい PTS が出力されるようになっているとのこと。

実際、ffmpeg でも字幕の PTS タイムスタンプが不正なため、字幕が映像より10秒近く早く描画されてしまう（音声と字幕のタイミングが一致しない）事がありました。arib-subtitle-timedmetadater の更新後は ffmpeg であっても、NVEncC でもあっても字幕が音声と同じタイミングで表示されていました。ぜひご確認いただければと思います。

…ただ、なぜか「NVEncC でのみ」字幕のタイミングがずれる番組を一部で確認しました。同じ番組を ffmpeg でエンコードすると 100% 問題なく再生できているので、NVEncC 側の処理に何かしら問題があるとみています。ちょっと厄介なのが、全ての番組がそうなるわけではなく、むしろ NVEncC でエンコードした場合でも通常通り字幕が正しいタイミングで描画される番組の方が多そうだということです。ただ「稀」と言えるほど低頻度でもないので、NVEncC 側で対応できる問題であればぜひ改善していただければと思います。

arib-subtitle-timedmetadater に関しては monyone 氏いわくまだ不具合があるかもとの事で、実際に一部の字幕がなぜか描画されない（これに関しては ffmpeg・NVEncC 共通）などの問題が残されています。もしかすると arib-subtitle-timedmetadater 側の問題なのかもしれませんが…。

4. 字幕mux時の8～10秒程度の遅延

これはffmpegに限らず、NVEncC等でも発生する遅延で、muxキューによる遅延と考えらます。

mux処理では、字幕がない箇所では、字幕データがないことを確認するために、一定の時間(デフォルト=10秒分)映像や音声のデータをmuxキューにためて、その間字幕データがなければ字幕データがないと判断するようになっています。字幕を出力する際に10秒遅延が増加するのはこのためです。

てっきり ffmpeg のバグかと思っていましたが、そういうことだったんですね…！！確かに 10 秒ほど遅延するのも説明がつきます。納得です。

muxキューが待機する長さは下記オプションで調整可能です。下記では5秒にする例を示しました。

このオプションを ffmpeg と NVEncC それぞれに付与した所、字幕ありの場合でのエンコード開始までの時間が大幅に短縮されたように感じます。まさかこのオプション1つで解決してしまうとはびっくりです。私だけでは ffmpeg の大量のオプションの中からこのオプションを見つけ出すことはできなかったので、本当に助かりました。

字幕あり (ID3ストリームをコピーするオプションを付与) の場合、字幕なし (ID3ストリームをコピーしない) の場合で比較してみましたが、このオプションを付与するだけで再生が始まるまでの差がほとんどなくなったように感じます。番組にもよるかもしれませんが。

あまり短くしすぎると、字幕や音声のタイミングずれにつながりますので

懸念していた音声のズレに関しては ffmpeg・NVEncC とも特になく普通に再生できたので、-max_interleave_delta 1M と待機時間を 1 秒に設定してみました。そもそも 5 秒に設定した時点で 5 秒以上の短縮効果が得られている（？）ようで、5M のときと顕著な差は確認できませんでした。先ほどの NVEncC でのみ字幕のタイミングがずれる問題に関しては、-max_interleave_delta の値を大きくしたり小さくしたり、値自体を外したり、--input-probesize を外したりしても同じ結果だったので、この値を小さくしたのが原因という訳ではないと考えられます。

ということで、現在の arib-subtitle-timedmetadater 対応の課題は下記のようになります。

現状 arib-subtitle-timedmetadater でパケットロスなく TSTask の TCP or UDP ストリームを受信できない（保留）
一部の字幕が描画されず、描画されなかった字幕の前の字幕が次の字幕が描画されるまで延々と表示されたままになる
NVEncC でエンコードした場合のみ、字幕の描画タイミングがずれる番組が一部存在する

せっかくのGWに色々対応していただいていて感謝です。また長くなってしまいましたが、それではよろしくお願いします。

いろいろテスト、コメントいただきありがとうございます。muxキューによる遅延の件は、お役に立ててよかったです。

iOSはいろいろややこしそうですね…林檎がハード周りで独自仕様で面倒なのは知っていましたが、web周りでも独自仕様なのですね。

さて、こちらでも arib-subtitle-timedmetadater を更新させていただき、ご指摘いただいた NVEncC 使用時に字幕の描画タイミングがずれる問題について調査いたしました。原因は少し見えてきましたので、状況をご説明したのち1点質問させてください。

まず、原因としてはtimestampが認識できないtimed_id3のパケットが arib-subtitle-timedmetadater から送出されており、こうしたtimestampの設定されていないパケットを NVEncC が正常に処理できないためのようです。

本日テストしたときのパケット情報(stream1.m3u8.packets.csv.txt) から一部を抜粋します。

stream  1,   mpeg2video, pts, 7109486765
stream  2,          aac, pts, 7109463917
stream  2,          aac, pts, 7109465837
stream  1,   mpeg2video, pts, 7109498777
stream  2,          aac, pts, 7109467757
stream  1,   mpeg2video, pts, 7109492771
stream  2,          aac, pts, 7109469677
stream  2,          aac, pts, 7109471597
stream  4,    timed_id3, pts, 7109531841  <<<<<< こちらは問題なさそうだが
stream  3, arib_caption, pts, 7109531841
stream  1,   mpeg2video, pts, 7109495774
stream  2,          aac, pts, 7109473517
stream  1,   mpeg2video, pts, 7109507786
stream  1,   mpeg2video, pts, 7109501780
stream  2,          aac, pts, 7109475437
stream  2,          aac, pts, 7109477357
stream  4,    timed_id3, pts, Unknown     <<<<<< timestampが設定されていない
stream  1,   mpeg2video, pts, 7109504783
stream  2,          aac, pts, 7109479277

パケットのtimestampが認識できないのは、NVEncCだけの問題ということではなく、ffmpegでも同様でした。同じ番組に対して、ffmpegに-debug_tsを付けた時のログの一部を記載します。ist_index:3というのが、timed_id3ストリームを示します。ここで重要なのは pkt_pts / pkt_dts ですが、これがNOPTS になっており、timestampが認識できていないことを示します。

demuxer -> ist_index:3 type:data next_dts:30128911 next_dts_time:30.1289 next_pts:30128911 next_pts_time:30.1289 pkt_pts:NOPTS pkt_pts_time:NOPTS pkt_dts:NOPTS pkt_dts_time:NOPTS off:-79163067522 off_time:-79163.1
demuxer+ffmpeg -> ist_index:3 type:data pkt_pts:NOPTS pkt_pts_time:NOPTS pkt_dts:NOPTS pkt_dts_time:NOPTS off:-79163067522 off_time:-79163.1

ffmpegはこうした状況でも(どうやってか)処理を継続できるようですが、NVEncCではこうしたtimestampを認識できないパケットのところでパケットの時刻が判断できないために以降のtimed_id3パケットの処理が停止してしまい、字幕表示の大幅な遅延につながるようです。

こうした状況が発生する条件はよくわからないのですが、番組によってはこうしたtimestampの認識できないパケットが多発しておりました。

ここで質問させていただきたいのですが、このような timed_id3 ストリームにtimestampが設定されないことがあるのはこういうもの(仕様)でしょうか、それとも「まだ不具合があるかも」のほうでしょうか? このあたりの字幕の仕様があまり理解できておらずすみません。

意図されていないものでしたら、可能であれば修正を monyone 氏にお願いいただけますと幸いです。

また、そうではなく仕様ということですと、NVEncCにパケットのtimestampが設定されていない場合の例外処理を加えないといけないかなと思っています。ただ、その場合は周囲のtimestampから適当に補完するぐらいしか思いつかないので、若干本来の時刻からずれてしまうかもしれません。

よろしくお願いいたします。

ありがとうございます。

私の方で調べたところ、NVEncC で字幕がずれるのはどうやら日テレ・テレ朝・TBS・フジテレビのみのようで、局によるようでした。 monyone 氏に問い合わせした所、どうも timed_id3 の PID を subtitle の PID + 1 にしていたら、これが一部の局で文字スーパと被っていた（？）のが原因らしいです。改良版に更新してみた所、字幕のずれがなくなりました。ライブ放送等でのリアルタイム字幕だと元がずれてるので音声と一致しないのはしょうがないですが、それでも TVTest と表示タイミングが一致していたので、問題ないと思います。現在の develop ブランチで更新版を push しました。一部の字幕が描画されない件もこの PTS がおかしくなるのに関連していたようで、更新と同時に直ったような気がします。しばらく運用してみないとなんとも言えませんが…。

ということで、あとは arib-subtitle-timedmetadater でパケットロスが発生して画面にブロックノイズが入ってしまう問題が解決すれば、ついに正式対応できそうです。わざわざ長いことお付き合いいただきありがとうございました！また何かあれば報告します。

字幕がずれる件、確認いただきありがとうございました。問題が解決したとのことで安心しました。

それでは今後、今回NVEncCに行った更新をQSVEncC/VCEEncCに展開して、それぞれで同様に使えるようにしていきたいと思います。

ありがとうございます！トラブル続きで諦めかけていましたが、なんとか使える状態に持って行けて私も一安心です。

@rigaya 様々な対応をしていただき、本当にありがとうございます。 arib-subtitile-timedmetadater の作者の monyone と申します。この度は、aribb24.js のバージョンアップに伴う iOS 対応で rigaya さんにご迷惑おかけして申し訳ありません。 arib-subtitle-timedmetadater のバグで貴重なお時間をお取りしてしまいした。何度頭を下げても足りないくらいです。本当にありがとうございました。

PTS の値がずれているというのは、JavaScript では基本的に double で数値を扱うのですがビット演算の場合は、符号付き 32bit 整数として評価してから bit 演算するという仕様があったのを見落としていたためです。 PTS は 33bit なので、& を取ったり、シフトしたりすると符号付き 32 bit として扱われます。このため、PTS がおかしな負の値になる場合があり、この時に 33bit 目が常に立っていて、本来 PTS の 33bit 目が立っていない番組では合わなくなってしまいました。このような不手際を発見して頂き、本当にありがとうございました。こちらがプログラマとして非常に未熟でした。

noPTS が混ざっていたのは、前者で PMT の再構成の際に ARIB字幕の PID+ 1 を timed-id3 に無確認で割り当てたためです。一部の局は、字幕と文字スーパーの PID が隣接していないのですが、そうなってない局があるというのを知りませんでした。同じ PID では文字スーパーが入るため、文字スーパーは PTS/DTS が無いので、noPTS になります。この点、オプションなどを新設して頂き、バグ究明の役に非常に立ちましたので、非常にありがたかったです。 (ただ、NCEnvC が自分の環境では動かす環境がないため、ffmpeg のオプションで調査いたしました) この件も、調査せずに数値を決め打ちした点が、非常に思慮が足りなかったため、反省しています。

表示されない場合があったのは、timed-id3 PES の private_data に TS パケットに合うようパディングを入れていたためです。 private_data に値を入れるとどうも 5byte (PTS) 分がずれたりずれなかったりして安定しないようです。これは、id3 自体に TS パケットで必要な分の無効なバイト列を追加することで、今の所対処出来ている気がします。問題が ffmpeg (libavformat) の問題なのか、hls.js / Safari native の問題かはわかっていません。 (気がしますと書いているのは、確定で 5byte ずれるようになったので、id3 の先頭に 5byte 無効なデータを入れてるためです) ツールが悪いのではないか調査頂いたようでして、この件も申し訳ありません。自分の仕様を読む力が足りない事、ffmpeg や hls.js, Safari の気持ちが分からない未熟さを猛省しております。

最後に、一応、なぜ、このようなものが必要になっているかについて、説明いたします。なぜ作っていて利用したいのか、という点の説明がないと、作業して頂いた理由が分からないと思いますので。

arib-subtitle-timedmetadater とは

このツールは名前の通り、ARIB 字幕を timed-id3 に重畳しなおすツールです。 ARIB字幕を様々なプラットフォームで Apple が定めた HLS の仕様内で重畳するために作っています。

このツールの目的

ARIB字幕と同じ PTS で TXXX フレームに ARIB 字幕のバイナリデータを base64 して mpegts に重畳することで Apple の HLS の規格に沿う in-band なメタデータ伝送で ARIB 字幕を伝送するというのが、このツールの目的になります。これにより、iOS Safari などがサポートする標準的な in-band メタデータ伝送で ARIB 字幕を載せる事が可能になります。

このツールの利点

このツールで timed-id3 に ARIB 字幕を変換する利点は以下の通りです。

ffmpeg (libavformet) で解釈可能なため、独自の改造が要らずに mpegts を HLS に変換可能
様々な映像再生フレームワークでの対応が既に存在する
- hls.js, video.js, shaka-player
- Safari, iOS Safari のネイティブのプレイヤー
- Android の ExoPlayer
- iOS の AVPlayer

このため、非MSE環境、様々な OS であっても、このツールで変換すれば原理的にはクライアントは受け取る事ができます。

このツールの動作

以下の機能から構成されています。

PMT を再編集して timed_id3 を追加し、CRC などを変更した PMT を TSパケットに分解して remux します。
字幕PESが来た際に、同じ PTS で TXXX に字幕PESを base64 を入れた id3 PES をTSパケットに分解して remux します。

つまるところ、PMT (Seciton) と字幕 (PES) を置き換えて remux する、という動作をしています。 Section, PES をばらして再編集して、再編集したものを TS パケットに戻して重畳しなおす簡単なプログラムです。

このツールの記述言語

現時点では node.js 製の物をつくっております。node.js の Transform で変換処理を pipe として記述できます。そのうち、ネイティブ対応のできる Go か Rust でのコマンドラインプログラムを作る事を考えています。

このツールの利用方法

ffmpeg が現時点で arib subtitle の descriptor を落としてしまうため、ffmpeg より前段において動作する事を想定しています。

(チューナー) | arib-subtitle-timedmetadater | ffmpeg (HLS 変換) といった具合です。一応、UDP/TCP 入力は入れていますが、UDP/TCP 出力は入れていません。

node.js 製なので、node.js であれば変換部分だけをプログラム内で利用可能です。

@tsukumijima こちらこそ、いろいろ要望・コメントいただき、ありがとうございました。

普段のNVEncCの実装では、処理遅延は許容してスループットを最大化する方向に振ることが多いのですが、今回は普段あまり意識しない処理遅延などについて注目したり、またはffmpegと挙動を比較したりしたことでいろいろ発見もあり、TVRemotePlusで使用する際のNVEncCの挙動改善につなげられたかと思います。

@monyone arib-subtitile-timedmetadater を作成された背景と目的、ならびに今回修正いただいた内容について、ご説明くださりありがとうございます。

今回PTSに関して発生していた現象についても理解できました。やはりプログラムが意図しない動作をしてしまったり、想定外の入力が来たりするというのは、どうしてもあるものだと思いますので、今回の私の行った調査がそうした点の発見の一助となっていましたら幸いです。

@rigaya 関係者外から失礼いたします。要望だと思いますが、PTS 無しのパケットを支援することは可能でしょうか。

前述の通り、ARIB の文字スーパーは受信機が受信した後、すぐ表示するように想定されているため、mpegts のストリームで private_stream_2 を利用する、timestamp の無い Private PES で伝送されています。

背景としては、FFmpeg から出力された mpegts のストリームを mpegts.js + aribb24.js によって低遅延再生する際に、ARIB 字幕とARIB 文字スーパーを同時に表示できるようにしていました。https://twitter.com/magicxqq/status/1381786681926246402

EPGStation では既に mpegts.js が導入され、文字スーパーもまもなく対応するように進んでいます。@tsukumijima によると、TVRemotePlus も将来に mpegts.js を導入する予定があると聞いています。

FFmpeg の場合は、文字スーパーのパケットに対し warning が出ていますが、エラーになっていないので無事抽出できています。

もし NVEnc も PTS 無しのパケットを対応できるようになれば、文字スーパーの表示に大変助かると思います。

@xqq PTS 無しのパケットを処理できたほうが良いこと、承知しました。

次回の更新では、データストリームについてPTS 無しのパケットをそのまま転送できるよう、変更したいと思います。

NVEnc 5.31に更新し、要望いただいたデータストリームについてPTS 無しのパケットについて、そのまま転送できるよう変更しました。

文字スーパーも含めて転送する場合は、--data-copy timed_id3でなく、単に--data-copyとしていただければ転送されるはずですので、将来的にもし文字スーパーへ対応される際はご活用ください。

ありがとうございます！！使わせていただきます。

（本来は QSVEncC の方に書くべきでしょうが、話題が同じなのでここで） NVEncC 5.31 と同等の機能が実装された QSVEncC 5.01 を試したのですが、5.00 の大型更新によるものなのか、私の環境だとエラーが出て、1セグメントだけエンコードした後すぐエラー終了してしまいます…。

1秒だけですが字幕は表示できていたのでそのあたりは問題ありません。字幕あり/なしは関係ありませんでした。エラーからして、そもそも QSV のデバイス自体がうまく使えていない？ような気がします。

以下に --log-level debug でデバッグ出力したログを記します（かなり長いです）。

--------------------------------------------------------------------------------
stream1.m3u8
--------------------------------------------------------------------------------
QSVEncC    5.01 (x64)
OS        Windows 7 x64 (7601) [CP932]
CPU Info  Intel Core i7-2600K @ 3.40GHz [TB: 3.44GHz] (4C/8T) <SandyBridge>
GPU Info   850-1350MHz
Locale    Japanese_Japan.932
InitSessionInitParam: Success.
D3D9Device: Init...
D3D9Device: Direct3DCreate9Ex Success.
D3D9Device: Set Init() m_D3DPresentPrm.BackBuffer.
D3D9Device: CreateDeviceEx Success.
D3D9Device: DXVA2CreateDirect3DDeviceManager9 Success.
D3D9Device: ResetDevice Success.
D3D9Device: Closed.
avhw reader selected.
InitInput: input selected : 7.
avqsv: select audio track #1, codec aacbitrate 192
avqsv: select audio track all, codec 
avqsv: set probesize: 921.600K
avqsv: set analyzeduration: 0.67 sec
avqsv: input source set to stdin.
[mpegts @ 00000000004bb4c0] stream=1 stream_type=2 pid=100 prog_reg_desc=
[mpegts @ 00000000004bb4c0] stream=2 stream_type=f pid=110 prog_reg_desc=
[mpegts @ 00000000004bb4c0] stream=3 stream_type=6 pid=130 prog_reg_desc=
[mpegts @ 00000000004bb4c0] stream=4 stream_type=15 pid=131 prog_reg_desc=
[mpegts @ 00000000004bb4c0] stream=5 stream_type=6 pid=138 prog_reg_desc=
[mpegts @ 00000000004bb4c0] stream=6 stream_type=d pid=140 prog_reg_desc=
[mpegts @ 00000000004bb4c0] stream=7 stream_type=d pid=160 prog_reg_desc=
[mpegts @ 00000000004bb4c0] stream=8 stream_type=d pid=161 prog_reg_desc=
[mpegts @ 00000000004bb4c0] stream=9 stream_type=d pid=162 prog_reg_desc=
[mpegts @ 00000000004bb4c0] stream=10 stream_type=d pid=170 prog_reg_desc=
[mpegts @ 00000000004bb4c0] stream=11 stream_type=d pid=171 prog_reg_desc=
[mpegts @ 00000000004bb4c0] stream=12 stream_type=d pid=172 prog_reg_desc=
avqsv: opened file "pipe:0".
[mpegts @ 00000000004bb4c0] Before avformat_find_stream_info() pos: 0 bytes read:921600 seeks:0 nb_streams:13
[mpegts @ 00000000004bb4c0] parser not found for codec arib_caption, packets or times may be invalid.
[libaribb24 @ 00000000082d9a00] arib parser was created
[libaribb24 @ 00000000082d9a00] arib decoder was created
[mpegts @ 00000000004bb4c0] parser not found for codec timed_id3, packets or times may be invalid.
[mpegts @ 00000000004bb4c0] parser not found for codec none, packets or times may be invalid.
[mpegts @ 00000000004bb4c0] parser not found for codec none, packets or times may be invalid.
[mpegts @ 00000000004bb4c0] parser not found for codec none, packets or times may be invalid.
[mpegts @ 00000000004bb4c0] parser not found for codec none, packets or times may be invalid.
[mpegts @ 00000000004bb4c0] parser not found for codec none, packets or times may be invalid.
[mpegts @ 00000000004bb4c0] parser not found for codec none, packets or times may be invalid.
[mpegts @ 00000000004bb4c0] parser not found for codec none, packets or times may be invalid.
[mpegts @ 00000000004bb4c0] probing stream 2 pp:2500
[mpegts @ 00000000004bb4c0] Probe with size=680, packets=1 detected flac with score=13
[mpegts @ 00000000004bb4c0] probing stream 2 pp:2499
[mpegts @ 00000000004bb4c0] Probe with size=1276, packets=2 detected flac with score=13
[mpegts @ 00000000004bb4c0] probing stream 2 pp:2498
[mpegts @ 00000000004bb4c0] probing stream 2 pp:2497
[mpegts @ 00000000004bb4c0] Probe with size=2490, packets=4 detected aac with score=51
[mpegts @ 00000000004bb4c0] probed stream 2
[mpeg2video @ 00000000082d5740] Invalid frame dimensions 0x0.
[mpeg2video @ 00000000082d5740] Format yuv420p chosen by get_format().
[mpegts @ 00000000004bb4c0] probing stream 5 pp:2500
[mpegts @ 00000000004bb4c0] probing stream 5 pp:2499
[mpegts @ 00000000004bb4c0] probing stream 5 pp:2498
[mpegts @ 00000000004bb4c0] probing stream 5 pp:2497
[mpegts @ 00000000004bb4c0] probed stream 5
[mpegts @ 00000000004bb4c0] parser not found for codec bin_data, packets or times may be invalid.
[mpegts @ 00000000004bb4c0] Probe buffer size limit of 921600 bytes reached
[mpegts @ 00000000004bb4c0] Could not find codec parameters for stream 6 (Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' (670000) and 'probesize' (921600) options
[mpegts @ 00000000004bb4c0] Could not find codec parameters for stream 7 (Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' (670000) and 'probesize' (921600) options
[mpegts @ 00000000004bb4c0] Could not find codec parameters for stream 8 (Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' (670000) and 'probesize' (921600) options
[mpegts @ 00000000004bb4c0] Could not find codec parameters for stream 9 (Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' (670000) and 'probesize' (921600) options
[mpegts @ 00000000004bb4c0] Could not find codec parameters for stream 10 (Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' (670000) and 'probesize' (921600) options
[mpegts @ 00000000004bb4c0] Could not find codec parameters for stream 11 (Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' (670000) and 'probesize' (921600) options
[mpegts @ 00000000004bb4c0] Could not find codec parameters for stream 12 (Unknown: none ([13][0][0][0] / 0x000D)): unknown codec
Consider increasing the value for the 'analyzeduration' (670000) and 'probesize' (921600) options
[libaribb24 @ 00000000082d9a00] arib decoder destroyed
[libaribb24 @ 00000000082d9a00] arib parser was destroyed
[mpegts @ 00000000004bb4c0] After avformat_find_stream_info() pos: 3127192 bytes read:3129344 seeks:0 frames:60
avqsv: got stream information.
Input #0, mpegts, from 'pipe:0':
  Duration: N/A, start: 17386.630311, bitrate: N/A
  Program 1024 
    Metadata:
      service_name    : ﾎﾈﾋAm9gｱｿEl5~
      service_provider: 
    Stream #0:1[0x100], 17, 1/90000: Video: mpeg2video (Main), 1 reference frame ([2][0][0][0] / 0x0002), yuv420p(tv, bt709, top first, left), 1440x1080 [SAR 4:3 DAR 16:9], 0/1, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
    Side data:
      cpb: bitrate max/min/avg: 20000000/0/0 buffer size: 9781248 vbv_delay: N/A
    Stream #0:2[0x110], 34, 1/90000: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 250 kb/s
    Stream #0:3[0x130], 0, 1/90000: Subtitle: arib_caption (Profile A) ([6][0][0][0] / 0x0006)
    Stream #0:4[0x131], 0, 1/90000: Data: timed_id3 (ID3  / 0x20334449), 0/1
    Stream #0:5[0x138], 1, 1/90000: Data: bin_data ([6][0][0][0] / 0x0006), 0/1
    Stream #0:6[0x140], 0, 1/90000: Unknown: none ([13][0][0][0] / 0x000D)
    Stream #0:7[0x160], 0, 1/90000: Unknown: none ([13][0][0][0] / 0x000D)
    Stream #0:8[0x161], 0, 1/90000: Unknown: none ([13][0][0][0] / 0x000D)
    Stream #0:9[0x162], 0, 1/90000: Unknown: none ([13][0][0][0] / 0x000D)
    Stream #0:10[0x170], 0, 1/90000: Unknown: none ([13][0][0][0] / 0x000D)
    Stream #0:11[0x171], 0, 1/90000: Unknown: none ([13][0][0][0] / 0x000D)
    Stream #0:12[0x172], 0, 1/90000: Unknown: none ([13][0][0][0] / 0x000D)
  Program 1025 
    Metadata:
      service_name    : ﾎﾈﾋAm9gｲｿEl5~
      service_provider: 
  Program 1408 
    Metadata:
      service_name    : ﾎﾈﾋ7HBSﾇｿEl5~
      service_provider: 
  No Program
    Stream #0:0[0x12], 8, 1/90000: Data: epg, 0/1
avqsv: found video stream, stream idx 1
avqsv: found audio stream, stream idx 2, trackID 1.0, aac, frame_size 1024, timebase 1/90000, delay 0 ms
avqsv: found data stream, stream idx 4, trackID 1.0, timed_id3, frame_size 0, timebase 1/90000, delay 0 ms
avqsv: use video stream #1 for input, codec mpeg2video, stream time_base 1/90000, codec_timebase 1001/60000.
avqsv: hdr10plusMetadataCopy: off
avqsv: can be decoded by qsv.
avqsv: start predecode.
avqsv: GetHeader: 162 bytes.
avqsv: initialized mpeg2video codec context for parser: time_base: 1001/60000, pkt_timebase: 1/90000.
avqsv: fps decoder 30000/1001, invalid: false
avqsv: maxCheckFrames 1, maxCheckSec: 1.000e+99
avqsv: found first key frame: timestamp 1564821290 (17386.9), offset 1
avqsv: read 1 packets.
avqsv: checking 0 frame samples.
avqsv: final AvgFps (round): 30000/1001
avqsv: checking for stream #2
avqsv: adjust trim by offset 1.
avqsv: avqsv: MPEG2, 1440x1080, 30000/1001 fps
avqsv: streamFirstKeyPts: 1564821290
avqsv: matrix:bt709,colorprim:bt709,transfer:bt709,range:limited,chromaloc:left
avqsv: sar 4:3, bitdepth 8
initReaders: Success.
Input: trim options
0-2147483647  (offset: 1)
timestamp check: 0x1
InitInput: Success.
CheckParam: Success.
InitSession: Start initilaizing... memType: d3d11+d3d9
InitSession: OS is Win7, do not check for d3d11 mode.
InitSession: initialized using d3d9 memory.
InitSession: mfx lib version: 1.4, impl 0x202
InitSession: Success.
CreateAllocator: MemType: d3d9
HWDevice: d3d9 - initializing...
D3D9Device: Init...
D3D9Device: Direct3DCreate9Ex Success.
D3D9Device: Set Init() m_D3DPresentPrm.BackBuffer.
D3D9Device: CreateDeviceEx Success.
D3D9Device: DXVA2CreateDirect3DDeviceManager9 Success.
D3D9Device: ResetDevice Success.
HWDevice: initializing device success.
CreateAllocator: CreateHWDevice success.
CreateAllocator: HW device GetHandle success.
CreateAllocator: set HW device handle to encode session.
CreateAllocator: Create d3d9 allocator.
CreateAllocator: d3d9...
CreateAllocator: frame allocator set to session.
CreateAllocator: frame allocator initialized.
Skip OpenCL init as OpenCL is not supported in SandyBridge platform.
InitMfxDecParams: QSVDec prm: MPEG2, Level 4, Profile 64
InitMfxDecParams: Frame: nv12, 1440x1088p [0,0,1440,1080] 4:3
InitMfxDecParams: color format nv12, chroma yuv420, bitdepth 0, shift 0, picstruct unknown
MFXVPP: InitSession: mfx lib version: 1.4, impl 0x202
MFXVPP: Got HW device handle: 00000000083D3A38.
MFXVPP: set HW device handle 00000000083D3A38 to encode session.
MFXVPP: SetMFXFrameIn: vpp input frame 1440x1088 (0,0,1440,1080)
MFXVPP: SetMFXFrameIn: vpp input color format nv12, chroma yuv420, bitdepth 0, shift 0, picstruct tff
MFXVPP: InitMfxVppParams: vpp deinterlace enabled.
MFXVPP: SetMFXFrameOut: vpp output frame 1440x1088 (0,0,1440,1080)
MFXVPP: SetMFXFrameOut: vpp output color format nv12, chroma yuv420, bitdepth 0, shift 0, picstruct prog
MFXVPP: SetMFXFrameOut: set all vpp params.
MFXVPP: CreateVppExtBuffers: set DoNotUse PAMP.
MFXVPP: CreateVppExtBuffers: set DoNotUse DET .
MFXVPP: CreateVppExtBuffers: set DoNotUse DNIS.
MFXVPP: CreateVppExtBuffers: set DoNotUse SCLY.
MFXVPP: Vpp SetParam success.
encodeBitDepth: 8, codecMaxQP: 51.
Detected avaliable features for hw API v1.4, H.264/AVC, Bitrate Mode - VBR
RC mode       o    
10bit depth   x    
Fixed Func    x    
Interlace     o    
VUI info      o    
Trellis       x    
Adaptive_I    x    
Adaptive_B    x    
WeightP       x    
WeightB       x    
FadeDetect    x    
B_Pyramid     x    
 +ManyBframes x    
PyramQPOffset x    
MBBRC         x    
ExtBRC        x    
Adaptive_LTR  x    
LA Quality    x    
QP Min/Max    x    
IntraRefresh  x    
No Deblock    x    
No GPB        x    
Windowed BRC  x    
PerMBQP(CQP)  x    
DirectBiasAdj x    
MVCostScaling x    
SAO           x    
Max CTU Size  x    
TSkip         x    

Min/Max QP is not supported on current platform, disabled.
InitMfxEncParams: Output FPS 30000/1001
InitMfxEncParams: set ext param CDOP.
InitMfxEncParams: enc input frame 1440x1088 (0,0,1440,1080)
InitMfxEncParams: enc input color format nv12, chroma yuv420, bitdepth 8, shift 0, picstruct prog
InitMfxEncParams: set all enc params.
Performace Monitor: none
Performace Plot   : none
Output: Using avformat writer.
Output: Audio/Subtitle muxing enabled.
Output: CopyAll=true
Output: Added audio track#4097 (stream idx 2) for mux, bitrate 192, codec: aac  , bsf: <none>, disposition: <copy>, metadata <copy>
Output: Added data track#8193 (stream idx 4) for mux, bitrate 0, codec: copy  , bsf: <none>, disposition: <copy>, metadata <copy>
avout: output filename: "stream1.m3u8"
avout: Opened file "stream1.m3u8".
avout: output video stream fps: 30000/1001
avout: opened video avcodec
avout: output video stream timebase: 1001/120000
avout: bDtsUnavailable: on
avout: Initialized video output.
avout: start initializing audio ouput...
avout: output stream index 2, trackId 1.0
avout: samplerate 48000, stream pkt_timebase 1/90000
avout: Audio Decoder opened
avout: Audio Decode Info: aac, 2ch[0x03], 48.0kHz, fltp, 1/90000 dual_mono_mode=main
avout: found encoder for codec aac selected for audio track 1
avout: Audio Encoder Param: aac, 2ch[0x03], 48.0kHz, fltp, -99 (default), 1/48000, default
[Parsed_volume_0 @ 00000000004bbec0] Setting 'volume' to value '2'
[Parsed_aformat_1 @ 00000000084bf580] Setting 'sample_fmts' to value 'fltp'
[Parsed_aformat_1 @ 00000000084bf580] Setting 'sample_rates' to value '48000'
[Parsed_aformat_1 @ 00000000084bf580] Setting 'channel_layouts' to value '0x3'
avout: Parsed filter: volume=2
[in_track_1.0 @ 0000000005c5e6c0] Setting 'time_base' to value '1/48000'
[in_track_1.0 @ 0000000005c5e6c0] Setting 'sample_rate' to value '48000'
[in_track_1.0 @ 0000000005c5e6c0] Setting 'sample_fmt' to value 'fltp'
[in_track_1.0 @ 0000000005c5e6c0] Setting 'channel_layout' to value '0x3'
[in_track_1.0 @ 0000000005c5e6c0] tb:1/48000 samplefmt:fltp samplerate:48000 chlayout:0x3
avout: filter linked with src buffer.
avout: filter linked with sink buffer.
[AVFilterGraph @ 00000000083d1f80] query_formats: 4 queried, 9 merged, 0 already done, 0 delayed
[in_track_1.0 @ 0000000005c5e6c0] tb:0.000021 sample_rate:48000.000000 nb_channels:2.000000
[Parsed_volume_0 @ 00000000004bbec0] n:nan t:nan pts:nan precision:float volume:2.000000 volume_dB:6.020600
avout: filter config done, filter ready.
avout: Copy Disposition: unset
avout: Initialized audio output - #0: track 1, substream 0.
avout: start initializing data ouput...
avout: output stream index 4, pkt_timebase 1/90000, trackId 1
avout: Copy Disposition: unset
avout: Initialized data output - 0.
avout: set mux opt: hls_time = 1.
avout: set mux opt: hls_list_size = 12.
avout: set mux opt: hls_allow_cache = 0.
avout: set mux opt: hls_flags = delete_segments.
avout: set mux opt: hls_segment_filename = stream1-05082315_1071534888.ts.
avout: set mux opt: max_interleave_delta = 1M.
avout: avwriter: h264,
avout:  #1:aac/stereo:stereo:volume -> aac/stereo/192kbps, data#1
avout:  => hls
Output: Initialized avformat writer.
pipeline element count: 3
async depth automatically set to 6
timeBeginPeriod(1)
ResetMFXComponents: Start...
ResetMFXComponents: Enc closed.
MFXVPP: Vpp Closed.
ResetMFXComponents: Vpp closed.
ResetMFXComponents: Dec closed.
MFXVPP: InitSession: mfx lib version: 1.4, impl 0x202
MFXVPP: Got HW device handle: 00000000083D3A38.
MFXVPP: set HW device handle 00000000083D3A38 to encode session.
Created pipeline.
  MFXDEC
  AUDIO
  TRIM
  CHECKPTS
  MFXVPP
  MFXENCODE

allocFrames: m_nAsyncDepth - 6 frames
AllocFrames: MFXDEC-CHECKPTS
MFXDEC:   MFXDEC required buffer: 21 [external,dxvadec,dec]
CHECKPTS:   CHECKPTS required buffer in: 5 [external,dxvaproc,vppin], out 21 [external,dxvaproc,vppout]
AllocFrames: MFXDEC-CHECKPTS, type: external,dxvadec,dec, nv12 1440x1088 [0,0,1440,1080], request 33 frames
MFXDEC: allocWorkSurfaces:   cleared old surfaces: no error..
QSVAllocator: FrameAlloc: external,dxvadec,dec, 33 frames.
QSVAllocator: Allocate type external.
QSVAllocatorD3D9::AllocImpl select DXVA2_VideoDecoderRenderTarget.
QSVAllocatorD3D9::AllocImpl GetVideoService Success.
QSVAllocatorD3D9::AllocImpl allocate surface...
QSVAllocatorD3D9::AllocImpl Success.
QSVAllocator: FrameAlloc success.
MFXDEC: allocWorkSurfaces:   allocated 33 frames.
AllocFrames: CHECKPTS-MFXVPP
CHECKPTS:   CHECKPTS required buffer in: 5 [external,dxvaproc,vppin], out 21 [external,dxvaproc,vppout]
MFXVPP:   MFXVPP required buffer in: 7 [external,dxvaproc,vppin], out 5 [external,dxvaproc,vppout]
AllocFrames: CHECKPTS-MFXVPP, type: external,dxvaproc,vppin, nv12 1440x1088 [0,0,1440,1080], request 35 frames
CHECKPTS: allocWorkSurfaces:   cleared old surfaces: no error..
QSVAllocator: FrameAlloc: external,dxvaproc,vppin, 35 frames.
QSVAllocator: Allocate type internal.
QSVAllocatorD3D9::AllocImpl select DXVA2_VideoProcessorRenderTarget.
QSVAllocatorD3D9::AllocImpl GetVideoService Success.
QSVAllocatorD3D9::AllocImpl allocate surface...
QSVAllocatorD3D9::AllocImpl Success.
QSVAllocator: FrameAlloc success.
CHECKPTS: allocWorkSurfaces:   allocated 35 frames.
AllocFrames: MFXVPP-MFXENCODE
MFXVPP:   MFXVPP required buffer in: 7 [external,dxvaproc,vppin], out 5 [external,dxvaproc,vppout]
MFXENCODE:   MFXENCODE required buffer: 6 [external,dxvadec,enc]
AllocFrames: MFXVPP-MFXENCODE, type: external,dxvadec,enc,vppout, nv12 1440x1088 [0,0,1440,1080], request 18 frames
MFXVPP: allocWorkSurfaces:   cleared old surfaces: no error..
QSVAllocator: FrameAlloc: external,dxvadec,enc,vppout, 18 frames.
QSVAllocator: Allocate type internal.
QSVAllocatorD3D9::AllocImpl select DXVA2_VideoDecoderRenderTarget.
QSVAllocatorD3D9::AllocImpl GetVideoService Success.
QSVAllocatorD3D9::AllocImpl allocate surface...
QSVAllocatorD3D9::AllocImpl Success.
QSVAllocator: FrameAlloc success.
MFXVPP: allocWorkSurfaces:   allocated 18 frames.
ResetMFXComponents: there might be error below, but it might be internal error which could be ignored.
QSVAllocator: FrameAlloc: internal,dxvadec,enc, 5 frames.
QSVAllocator: Allocate type internal.
QSVAllocatorD3D9::AllocImpl select DXVA2_VideoDecoderRenderTarget.
QSVAllocatorD3D9::AllocImpl GetVideoService Success.
QSVAllocatorD3D9::AllocImpl allocate surface...
QSVAllocatorD3D9::AllocImpl Success.
QSVAllocator: FrameAlloc success.
QSVAllocator: FrameAlloc: internal,dxvadec,enc, 3 frames.
QSVAllocator: Allocate type internal.
QSVAllocatorD3D9::AllocImpl select DXVA2_VideoDecoderRenderTarget.
QSVAllocatorD3D9::AllocImpl GetVideoService Success.
QSVAllocatorD3D9::AllocImpl allocate surface...
QSVAllocatorD3D9::AllocImpl Success.
QSVAllocator: FrameAlloc success.
Encoder initialized.
MFXVPP: There might be error below, but it might be internal error which could be ignored.
QSVAllocator: FrameAlloc: internal,system,vppin, 1 frames.
QSVAllocator: Failed CheckRequestType: undeveloped feature.
QSVAllocator: FrameAlloc: internal,system,vppin, 1 frames.
QSVAllocator: Failed CheckRequestType: undeveloped feature.
QSVAllocator: FrameAlloc: internal,system,vppin, 7 frames.
QSVAllocator: Failed CheckRequestType: undeveloped feature.
QSVAllocator: FrameAlloc: internal,system,vppout, 5 frames.
QSVAllocator: Failed CheckRequestType: undeveloped feature.
MFXVPP: Vpp initialized.
MFXVPP: There might be error below, but it might be internal error which could be ignored.
QSVAllocator: FrameAlloc: internal,system,vppin, 5 frames.
QSVAllocator: Failed CheckRequestType: undeveloped feature.
QSVAllocator: FrameAlloc: internal,system,vppout, 5 frames.
QSVAllocator: Failed CheckRequestType: undeveloped feature.
MFXVPP: Vpp initialized.
ResetMFXComponents: there might be error below, but it might be internal error which could be ignored.
QSVAllocator: FrameAlloc: external,dxvadec,dec, 21 frames.
QSVAllocator: Allocate type external.
QSVAllocator: FrameAlloc success.
Dec initialized.
vidprm.AsyncDepth value changed 0 -> 3 by driver
vidprm.mfx.BRCParamMultiplier value changed 0 -> 1 by driver
vidprm.mfx.CodecLevel value changed auto -> 4 by driver
vidprm.mfx.NumSlice value changed 0 -> 1 by driver
vidprm.mfx.NumRefFrame value changed 0 -> 2 by driver
cop.RateDistortionOpt value changed auto -> off by driver
cop.EndOfSequence value changed auto -> off by driver
cop.CAVLC value changed auto -> off by driver
cop.ViewOutput value changed auto -> off by driver
cop.VuiVclHrdParameters value changed auto -> off by driver
cop.RefPicListReordering value changed auto -> off by driver
cop.ResetRefList value changed auto -> off by driver
cop.MaxDecFrameBuffering value changed 0 -> 2 by driver
cop.EndOfStream value changed auto -> off by driver
cop.RefPicMarkRep value changed auto -> off by driver
cop.FieldOutput value changed auto -> off by driver
cop.NalHrdConformance value changed auto -> on by driver
cop.SingleSeiNalUnit value changed auto -> on by driver
cop.VuiNalHrdParameters value changed auto -> on by driver
QSVEncC (x64) 5.01 (r2279) by rigaya, May  8 2021 19:58:15 (VC 1928/Win/avx2)
OS             Windows 7 x64 (7601) [CP932]
CPU Info       Intel Core i7-2600K @ 3.40GHz [TB: 3.44GHz] (4C/8T) <SandyBridge>
GPU Info        850-1350MHz
Media SDK      QuickSyncVideo (hardware encoder), 1st GPU, API v1.4
Async Depth    6 frames
Buffer Memory  d3d9, 86 work buffer
Input Info     avqsv: MPEG2, 1440x1080, 30000/1001 fps
VPP            Deinterlace (normal)
AVSync         forcecfr
Output         H.264/AVC(yuv420) Main @ Level 4
               1440x1080p 4:3 29.970fps (30000/1001fps)
               avwriter: h264,
                #1:aac/stereo:stereo:volume -> aac/stereo/192kbps, data#1
                => hls
Target usage   7 - fastest
Encode Mode    Bitrate Mode - VBR
Bitrate        6500 kbps
Max Bitrate    15000 kbps
VBV Bufsize    30000 kbps
Ref frames     2 frames
Bframes        3 frames
Max GOP Length 30 frames
Encode Thread: RunEncode2...
MFXDEC: DecodeFrameAsync: removing 11412 bytes from input bitstream not read by decoder.
CHECKPTS: Big Gap was found between 2 frames, avsync might be corrupted.
[mpegts @ 000000000448a140] service 1 using PCR in pid=256, pcr_period=0ms
[mpegts @ 000000000448a140] muxrate VBR, sdt every 1073741822000 ms, pat/pmt every 1073741822000 ms
Output #0, hls, to 'stream1.m3u8':
  Metadata:
    encoding_tool   : QSVEncC (x64) 5.01
    encoder         : Lavf58.49.100
    Stream #0:0, 0, 1/90000: Video: h264 (Main), 1 reference frame, nv12(progressive), 1440x1080 (0x0) [SAR 4:3 DAR 16:9], 0/1, q=2-31, 200 kb/s, 29.97 fps, 90k tbn
    Stream #0:1, 0, 1/90000: Audio: aac (LC), 48000 Hz, stereo, fltp, delay 1024, 192 kb/s
    Stream #0:2, 0, 1/90000: Data: timed_id3 (ID3  / 0x20334449), 0/1
avout: audio track #1: aac frame_size 1024 sample/byte -> aac frame_size 1024 sample/byte
avout: calc dts, first dts -2 x (timebase).
[mpegts @ 00000000004bb4c0] parser not found for codec arib_caption, packets or times may be invalid.
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1017911 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1029945 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1008611 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1020644 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1032678 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1011344 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1023378 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1002045 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1014077 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1026111 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1004778 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1016811 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1028844 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1007511 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1019544 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1031578 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1010245 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1022277 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1000944 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1012978 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1025011 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1003678 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1015711 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1027744 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1006411 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1018445 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1030477 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1009144 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1021178 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1033211 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1011878 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1023911 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1002577 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1014611 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1026645 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1005311 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1017344 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1029378 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1008044 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1020078 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1032111 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1010777 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1022811 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001478 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1013511 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Opening 'stream1-05082315_00000.ts' for writing
[file @ 0000000004334680] Setting default whitelist 'file,crypto,data'
[AVIOContext @ 000000000468d9c0] Statistics: 0 seeks, 1 writeouts
[hls @ 00000000084b8140] Opening 'stream1.m3u8.tmp' for writing
[file @ 000000000468a980] Setting default whitelist 'file,crypto,data'
EXT-X-MEDIA-SEQUENCE:0
[AVIOContext @ 000000000468d9c0] Statistics: 0 seeks, 1 writeouts
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1025544 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1004211 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1016244 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1028278 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1006945 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1018977 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1031011 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1009678 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1021711 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1000378 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1012411 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1024444 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1003111 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1015145 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1027177 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1005844 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1017878 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1029911 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1008578 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1020611 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1032644 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1011311 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[mpegts @ 00000000004bb4c0] Continuity check failed for pid 256 expected 10 got 7
[mpegts @ 00000000004bb4c0] Continuity check failed for pid 272 expected 2 got 5
[mpegts @ 00000000004bb4c0] PES packet size mismatch
[mpegts @ 00000000004bb4c0] Packet corrupt (stream = 2, dts = 1565077048).
[mpegts @ 00000000004bb4c0] Continuity check failed for pid 2305 expected 14 got 11
[mpegts @ 00000000004bb4c0] Packet corrupt (stream = 1, dts = 1565082551).
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1023345 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1002011 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1014044 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1026078 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1004744 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[mpegts @ 00000000004bb4c0] Continuity check failed for pid 0 expected 1 got 15
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1016778 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1028811 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1007477 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[mpegts @ 00000000004bb4c0] Continuity check failed for pid 18 expected 3 got 7
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1019511 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1031545 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1010211 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1022244 > 1000000: forcing output
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1001000 > 1000000: forcing output
[hls @ 00000000084b8140] pkt->duration = 0, maybe the hls segment duration will not precise
[hls @ 00000000084b8140] Delay between the first packet and last packet in the muxing queue is 1000911 > 1000000: forcing output
Clear vpp filters...
Clear vpp filter (copy)...

デバッグ出力を切った場合は以下の通りになります。

--------------------------------------------------------------------------------
stream1.m3u8
--------------------------------------------------------------------------------
Min/Max QP is not supported on current platform, disabled.
Error (clGetDeviceIDs): device not found.
QSVEncC (x64) 5.01 (r2279) by rigaya, May  8 2021 19:58:15 (VC 1928/Win/avx2)
OS             Windows 7 x64 (7601) [CP932]
CPU Info       Intel Core i7-2600K @ 3.40GHz [TB: 3.52GHz] (4C/8T) <SandyBridge>
GPU Info        850-1350MHz
Media SDK      QuickSyncVideo (hardware encoder), 1st GPU, API v1.4
Async Depth    6 frames
Buffer Memory  d3d9, 86 work buffer
Input Info     avqsv: MPEG2, 1440x1080, 30000/1001 fps
VPP            Deinterlace (normal)
AVSync         forcecfr
Output         H.264/AVC(yuv420) Main @ Level 4
               1440x1080p 4:3 29.970fps (30000/1001fps)
               avwriter: h264,
                #1:aac/stereo:stereo:volume -> aac/stereo/192kbps, data#1
                => hls
Target usage   7 - fastest
Encode Mode    Bitrate Mode - VBR
Bitrate        6500 kbps
Max Bitrate    15000 kbps
VBV Bufsize    30000 kbps
Ref frames     2 frames
Bframes        3 frames
Max GOP Length 30 frames
MFXDEC: DecodeFrameAsync: removing 26688 bytes from input bitstream not read by decoder.
CHECKPTS: Big Gap was found between 2 frames, avsync might be corrupted.
70 frames: 69.86 fps, 6893 kb/s                                                
MFXDEC: DecodeFrameAsync error: device operation failure..

encoded 74 frames, 69.03 fps, 6794.58 kbps, 2.00 MB
encode time 0:00:01, CPULoad: 3.3
frame type IDR  3
frame type I    3,  total size  0.17 MB
frame type P   20,  total size  0.75 MB
frame type B   51,  total size  1.08 MB

[mpeg2video @ 00000000004de680] Invalid frame dimensions 0x0.
[mpeg2video @ 00000000004de680] Invalid frame dimensions 0x0.

個人的には Error (clGetDeviceIDs): device not found. が気になります。以前の QSVEncC では普通に実行できていたと思うので、5.00 以降の問題じゃないかと踏んでいます。

もっとも今どき Windows7 で SandyBridge なボロ PC を使うなって話なんですが、録画 PC がこれなので中々変えられず…

エラーからしてこちらではどうしようもできなさそうなので取り急ぎ報告まで。私の方でも他の QSV 環境でこうなるかどうか試してみます。

QSVEncC 5.01 と、手元にあった QSVEncC 4.04 でスタンダードに QSVEncC64.exe --avhw --interlace tff -i input.ts --audio-codec aac -o out.mp4 のように適当に録画した 30 秒程度の TS をエンコードさせてみたところ、4.04 では通常通りエンコードできているのに対し、5.01 では緑っぽくランダムにモザイクがかかるような感じになってしまいました。

ただし、HLS でないからか普通にエンコード自体は終わりました。途中でエンコードが終わっているといったこともありません。音声は両者とも問題ないように見えます。

https://user-images.githubusercontent.com/39271166/117544059-7f0c7480-b05a-11eb-80fd-709f883015ee.mp4

これが QSVEncC 4.04 でエンコードしたもの、

https://user-images.githubusercontent.com/39271166/117544096-af541300-b05a-11eb-99e5-aa2b0e4b9aed.mp4

こっちが QSVEncC 5.01 でエンコードしたものです。何回か試しましたがこれはまだマシな方らしく、場合によっては画面全体が緑っぽくなってしまうこともありました。

https://user-images.githubusercontent.com/39271166/117544227-6f416000-b05b-11eb-95bc-e8ded69fa008.mp4

なんとなくデコードがうまく行っていないような気がしたので --avsw リーダーでソフトウェアデコーダーを使うようにしてみたら、上の通りあっさり正常にエンコードできました。おそらく問題はデコード側にあると思います。

QSVEnc 5.01でデコードがうまくいかないとのことですが、おそらく5.00で行った大規模更新に伴い、場合によってはSandyBridge環境に対応しなくなったものと思われます。

まずはじめに、ご留意いただきたい点として、QSVEnc(NVEncもVCEEncもそうですが)の想定動作環境は以下の通りとなっております。

Windows 10 (x86/x64) Aviutl 1.00 or later (QSVEnc.auo)

ハードウェアエンコード関連はデバイスによる差異が大きく、Windows10が標準でサポートしない過去の環境についてサポートを私個人で継続していくことは作業量の増大を招くため難しいので、大変勝手ながらこのようにさせていただいています。

さて、こちらでも確認のため適当なtsで QSVEncC64.exe --avhw --interlace tff -i input.ts --audio-codec aac -o out.mp4 でQSVEnc 5.01で確認しましたが、下記環境の全てで緑の絵が出ることなく問題なく動作することを確認しており、ご指摘いただいた問題は発生しませんでした。

CPU	世代	ドライバ	Windows
i5 2410M	SandyBridge	4229	8.1
i3 4170	Haswell	5107	10 20H2
i5 5500U	Broadwell	5126	10 20H2
i7 7700K	Kabylake	9316	10 20H2
i5 1035G7	Icelake	8681	10 20H2
i7 11700K	Rocketlake	9466	10 20H2

思いつく有効と思われる対応策・回避策として下記をお試しいただけますでしょうか?

(もし更新されていなければ)Intelドライバを最新(4229)に更新する https://downloadcenter.intel.com/ja/download/24970/Windows-15-28-Graphics-Driver
QSVの使用するビデオメモリモードを変更する(--d3d11をつけて実行する (デフォルトはより高速なd3d9))

お手数をおかけしますがよろしくお願いいたします。

なお、ご指摘いただいた下記エラーメッセージについてですが、

Error (clGetDeviceIDs): device not found

これはSandyBridgeがOpenCLをサポートしないため表示されますが、その後OpenCL抜きで動作するよう回復処理が行われるようになっており、特に問題はありません。

--input-probesizeの追加を上記QSVEnc 5.01に続き, VCEEnc 6.11でも行いましたので、ご連絡します。

よろしくお願いいたします。

--input-probesizeの追加を上記QSVEnc 5.01に続き, VCEEnc 6.11でも行いましたので、ご連絡します。

了解です。更新しておきます。

(もし更新されていなければ)Intelドライバを最新(4229)に更新する

ドライバのバージョンは 9.17.10.4229 (2015/05/26) で、おそらく最新のものになっていました。

QSVの使用するビデオメモリモードを変更する(--d3d11をつけて実行する (デフォルトはより高速なd3d9))

--d3d11 モードで実行してみましたが、やはり以前上げたような緑のモザイクがダーと入るような映像になってしまいます。念のため --d3d9 モードでもやってみましたが、こちらも結果は変わりませんでした。 d3d9・d3d11 両者とも QSVEncC 5.01 の場合ファイルサイズが通常版が 350KB に対し 6MB 前後だったりと大きくなります（デコードがうまく行っていないもののエンコードは普通にできるらしく、そう考えるとモザイクの入ったデコード済み映像をエンコードしている訳で納得はいく）。

何回かエンコードさせてみましたが残念ながら状態は変わりません。モザイクの模様自体は毎回変わりますが、同じエンコードしたファイル内であれば点滅するモザイクの柄（？）は同じように見えます。

ハードウェアエンコード関連はデバイスによる差異が大きく、Windows10が標準でサポートしない過去の環境についてサポートを私個人で継続していくことは作業量の増大を招くため難しいので、大変勝手ながらこのようにさせていただいています。

Windows 10 に対応しているとは言っても新旧多種多様な QSV 環境がある中で、さらに Windows / Linux と 2 つの OS でちゃんと動く状態を維持できているのは本当に素晴らしいですし、頭が下がる思いです。

個人的な話になりますがこの録画 PC 自体かなり古いもので、新しい PC に替えたりせめて OS を更新したいとは1年以上前から考えています。ただまず Intel Graphics 3000 が Windows 10 にどうやら対応していない事、PC を交換するにしても（資金的な都合で）筐体や電源を流用する事になるが、そうなると作業に最低でも1～2日かかり、録画 PC という関係上その間録画できなくなるのが… といった具合でなかなか換装に踏み切れず、結局ずるずる今の環境を引きずってしまっているのが現状です…。

エンコード用として GTX1660Ti を挿しておりメインで NVEncC を使っている（それでこの NVEncC の方に Issue を立てた）ため、通常利用ではさほど問題はありません。ただ、デバッグ用や NVEnc の同時エンコード数制限 (2) に引っかかった時に活用していた QSVEncC が使えなくなるのは正直痛いです。古いので仕方ないですが…。

QSVで2点確認いただきありがとうございました。d3d11でもダメでしたか…。

録画PC

たしかに録画環境を変えるのは勇気がいりますよね。私も最近はあまり変更してないです。

エンコード用として GTX1660Ti を挿しており

Win7のQSVの場合、Intel iGPU以外のGPUの有無で挙動が変わって難しかった記憶があります(もう6年ぐらい前なのでかすかな記憶ですが)。こちらで問題なく動作しているi5 2410Mの環境とはOSのバージョンに加え、そのあたりが違うのかなと思います。i5 2410MのPCはノートPCなので、GPUをつけてのテストは難しいのでテストも困難で、問題を再現できず申し訳ありません。

とりあえず、いただいた情報からデコード周りが原因なのは間違いないと思います。そこでデコード周りのコード上の差異を確認して、初期化のところで4.13→5.00で論理的に変えたところのうち、比較的戻しやすい変更箇所を戻したバージョンを2つほど作成してみました。それぞれ違う変更をしています。

大変お手数ですがそれぞれお試しいただけないでしょうか。--d3d11のほうがよいかもです。

正直に申し上げるとどちらもだめかもしれないような気がするのですが、ちょっとこれ以外だと難しそうです…。

NVEnc の同時エンコード数制限 (2)

ご参考までに、Max # of concurrent sessions が 2020年6月ごろ緩和され 2→3 になっています。最近のドライバでは3までいけるようです。 https://developer.nvidia.com/video-encode-and-decode-gpu-support-matrix-new

beta1・beta2 どちらも試してみましたが、残念ながら変わらず…でした。

ただその過程で気づいたのですが、どうやら --d3d11 オプションを設定したにもかかわらず、コンソールには Buffer Memory d3d9, 33 work buffer とあり、何らかの理由で DirectX 11 が使われていないものと思われます。https://www.microsoft.com/ja-jp/download/details.aspx?id=35 にあったインストーラーでインストールしてみても変わりませんし、dxdiag で DirectX 11 がインストールされていることは確認しています。

これは QSVEncC 4.13 でも同様で、--d3d11 オプションを指定したにも関わらずコンソールには Buffer Memory d3d9, 1 input buffer, 29 work buffer とあり、DirectX 11 が使用されていない事が伺えます。また、QSVEncC 4.13 では Buffer Memory d3d9, 1 input buffer, 29 work buffer なのに、QSVEncC 5.02beta1&2 では Buffer Memory d3d9, 33 work buffer と異なっているのも気になります。

以下に QSVEncC 4.13・5.02beta1・5.02beta2 のコンソール出力を貼っておきます。

QSVEncC (x64) 4.13 (r2009) by rigaya, Feb 17 2021 22:36:00 (VC 1928/Win/avx2)
OS             Windows 7 x64 (7601) [CP932]
CPU Info       Intel Core i7-2600K @ 3.40GHz [TB: 3.81GHz] (4C/8T) <SandyBridge>
GPU Info       Intel HD Graphics 850-1350MHz
Media SDK      QuickSyncVideo (hardware encoder), 1st GPU, API v1.4
Async Depth    5 frames
Buffer Memory  d3d9, 1 input buffer, 29 work buffer
Input Info     avqsv: MPEG2, 1440x1080, 30000/1001 fps
AVSync         cfr
Output         H.264/AVC High @ Level 4
               1440x1080p 4:3 29.970fps (30000/1001fps)
               avwriter: h264, #1:aac/stereo -> aac/stereo/192kbps => mp4
Target usage   4 - balanced
Encode Mode    Constant QP (CQP)
CQP Value      I:24  P:26  B:27
Ref frames     2 frames
Bframes        3 frames
Max GOP Length 300 frames

QSVEncC (x64) 5.02 beta1 (r2275) by rigaya, May  9 2021 22:54:28 (VC 1928/Win/avx2)
OS             Windows 7 x64 (7601) [CP932]
CPU Info       Intel Core i7-2600K @ 3.40GHz [TB: 3.82GHz] (4C/8T) <SandyBridge>
GPU Info        850-1350MHz
Media SDK      QuickSyncVideo (hardware encoder), 1st GPU, API v1.4
Async Depth    5 frames
Buffer Memory  d3d9, 33 work buffer
Input Info     avqsv: MPEG2, 1440x1080, 30000/1001 fps
AVSync         cfr
Output         H.264/AVC(yuv420) High @ Level 4
               1440x1080p 4:3 29.970fps (30000/1001fps)
               avwriter: h264, #1:aac/stereo -> aac/stereo/192kbps => mp4
Target usage   4 - balanced
Encode Mode    Constant QP (CQP)
CQP Value      I:24  P:26  B:27
Ref frames     2 frames
Bframes        3 frames
Max GOP Length 300 frames

QSVEncC (x64) 5.02 beta2 (r2275) by rigaya, May  9 2021 22:57:50 (VC 1928/Win/avx2)
OS             Windows 7 x64 (7601) [CP932]
CPU Info       Intel Core i7-2600K @ 3.40GHz [TB: 3.72GHz] (4C/8T) <SandyBridge>
GPU Info        850-1350MHz
Media SDK      QuickSyncVideo (hardware encoder), 1st GPU, API v1.4
Async Depth    5 frames
Buffer Memory  d3d9, 33 work buffer
Input Info     avqsv: MPEG2, 1440x1080, 30000/1001 fps
AVSync         cfr
Output         H.264/AVC(yuv420) High @ Level 4
               1440x1080p 4:3 29.970fps (30000/1001fps)
               avwriter: h264, #1:aac/stereo -> aac/stereo/192kbps => mp4
Target usage   4 - balanced
Encode Mode    Constant QP (CQP)
CQP Value      I:24  P:26  B:27
Ref frames     2 frames
Bframes        3 frames
Max GOP Length 300 frames

ご参考までに、Max # of concurrent sessions が 2020年6月ごろ緩和され 2→3 になっています。最近のドライバでは3までいけるようです。

そうなんですね…！それっぽい話は知っていましたが、既存の機種にも対応しているとは知りませんでした（ということは同時エンコード数制限はソフトウェア的なものなんですね…）。ドライバを更新してみます。

d3d11が効いていない旨、ご知らせいただきありがとうございます。

Win7でd3d11を使うとデスクトップコンポジションが切れる場合があるという報告があり、Win7の例外処理としてd3d11が有効にならないようにしていました…。手元の環境はWin8.1というのもあり、すっかり忘れていました。申し訳ありません。 https://rigaya34589.blog.fc2.com/blog-entry-392.html (2013/8/21)

該当部分の制限を解除したバージョンを添付しました。Win7環境がないので未テストですが、おそらくd3d11が効くようになっております。お手数ですが、お試しいただけますでしょうか。 QSVEncC64_5.01beta3.zip

また、QSVEncC 4.13 では Buffer Memory d3d9, 1 input buffer, 29 work buffer なのに、QSVEncC 5.02beta1&2 では Buffer Memory d3d9, 33 work buffer と異なっているのも気になります。

これはQSVEnc 5.00でメモリの確保方法を変更したので、input bufferとwork bufferの区別をなくしたため表示が変わっているものです。特に問題はございません。

該当部分の制限を解除したバージョンを添付しました。Win7環境がないので未テストですが、おそらくd3d11が効くようになっております。お手数ですが、お試しいただけますでしょうか。

https://user-images.githubusercontent.com/39271166/117678360-47cccd80-b1ea-11eb-982c-afcf30b8186c.mp4

なぜかはわかりませんが、QSVEncC64beta3.exe --avhw --d3d11 -i input.ts --audio-codec aac -o out_5.01beta3.mp4 のように指定しても、Buffer Memory d3d9, 33 work buffer と指定され、出力結果も相変わらず上のような感じです…。DirectX 11 が効いていないと思われます。

d3d11が有効にならないこと、ご確認いただきありがとうございます。

再度確認したところ、QSVのDirectX11対応はWindows7では使用できないとのことで、d3d11はWin7では使用できないということでした。いろいろ忘れてしまっており、大変失礼いたしました。

もうあまり思いつく対応策は残っていないのですが、本日コード差分を見ていたらd3d9メモリに確保方法をかえた箇所があったのを見つけました。もしかするとここかも、ということでこれを戻したものを作成しました。

最後の試みということで、何度もお願いして恐縮ですが、お試しいただけますでしょうか。 QSVEncC64_5.01beta4.zip

再度確認したところ、QSVのDirectX11対応はWindows7では使用できないとのことで、d3d11はWin7では使用できないということでした。いろいろ忘れてしまっており、大変失礼いたしました。

こちらこそもとを正せば未だに Win7 のﾎﾞﾛ PC 使ってるのが悪いのに、何度も確認していただいてすみません…

https://user-images.githubusercontent.com/39271166/117844115-639fa480-b2ba-11eb-8ade-ddb5764ce9f9.mp4

QSVEncC 5.02beta4 で試したところ、なんとノイズなく正常にエンコードすることができました…！！！

https://user-images.githubusercontent.com/39271166/117833112-081ce900-b2b1-11eb-8d9f-432ff6e4790d.mp4

QSVEncC 4.13 でエンコードした mp4 と比較してみても、ファイルサイズは 6 バイト増える程度でほとんど変わっていません。エンコード品質も相違ないように見えます。MediaInfo の内容も一致していました。

エンコードができるようになったので TVRemotePlus の方でも使ってみたのですが、エンコード自体は問題ないものの、最初の 1 セグメントだけのエンコードで終了してしまい、HLS セグメントを連続してエンコードすることができていません。

ログは下記の通りです。てっきりエンコードができるようになればこの問題も直るだろうと思っていましたが（1セグメント目でエンコードが止まってしまう問題は QSVEncC 5.01 にした時点であった）、そう簡単にはいかないようです…。

--------------------------------------------------------------------------------
stream1.m3u8
--------------------------------------------------------------------------------
Min/Max QP is not supported on current platform, disabled.
Error (clGetDeviceIDs): device not found.
QSVEncC (x64) 5.01 beta4 (r2283) by rigaya, May 11 2021 21:26:32 (VC 1928/Win/avx2)
OS             Windows 7 x64 (7601) [CP932]
CPU Info       Intel Core i7-2600K @ 3.40GHz [TB: 3.62GHz] (4C/8T) <SandyBridge>
GPU Info        850-1350MHz
Media SDK      QuickSyncVideo (hardware encoder), 1st GPU, API v1.4
Async Depth    6 frames
Buffer Memory  d3d9, 86 work buffer
Input Info     avqsv: MPEG2, 1440x1080, 30000/1001 fps
VPP            Deinterlace (normal)
AVSync         forcecfr
Output         H.264/AVC(yuv420) Main @ Level 4
               1440x1080p 4:3 29.970fps (30000/1001fps)
               avwriter: h264,
                #1:aac/stereo:stereo:volume -> aac/stereo/192kbps, data#1
                => hls
Target usage   7 - fastest
Encode Mode    Bitrate Mode - VBR
Bitrate        6500 kbps
Max Bitrate    15000 kbps
VBV Bufsize    30000 kbps
Ref frames     2 frames
Bframes        3 frames
Max GOP Length 30 frames
MFXDEC: DecodeFrameAsync: removing 18996 bytes from input bitstream not read by decoder.
CHECKPTS: Big Gap was found between 2 frames, avsync might be corrupted.
MFXDEC: DecodeFrameAsync error: device operation failure..

encoded 18 frames, 12.59 fps, 3271.40 kbps, 0.23 MB
encode time 0:00:01, CPULoad: 1.6
frame type IDR  1
frame type I    1,  total size  0.10 MB
frame type P    5,  total size  0.07 MB
frame type B   12,  total size  0.07 MB

[mpeg2video @ 000000000055f600] Invalid frame dimensions 0x0.
[mpeg2video @ 000000000055f600] Invalid frame dimensions 0x0.
[mpeg2video @ 000000000055f600] Invalid frame dimensions 0x0.

さらに、--avsw だと下記のようにログのヘッダー部分すら出力されずに終了してしまい、エンコードまでいきません。 --avhw ではログのヘッダー部分こそ必ず出力されるようですが、最初の 1 セグメントのエンコードまで到達せずに終了してしまうこともありました。

--------------------------------------------------------------------------------
stream1.m3u8
--------------------------------------------------------------------------------
Min/Max QP is not supported on current platform, disabled.
CHECKPTS:   Failed to get required buffer size for CHECKPTS: invalid video parameters.
QSVAllocator: Failed CheckRequestType: undeveloped feature.
INPUT: allocWorkSurfaces:   Failed to allocate frames: undeveloped feature..
AllocFrames:   Failed to allocate frames for INPUT-CHECKPTS: undeveloped feature..

QSVEncC.exe finished with error!
[mpeg2video @ 000000000014f600] Invalid frame dimensions 0x0.
[mpeg2video @ 000000000014f600] Invalid frame dimensions 0x0.
[mpeg2video @ 000000000014f600] Invalid frame dimensions 0x0.
[mpeg2video @ 000000000014f600] Invalid frame dimensions 0x0.
[mpeg2video @ 000000000014f600] Invalid frame dimensions 0x0.
[mpeg2video @ 000000000014f600] Invalid frame dimensions 0x0.
[mpeg2video @ 000000000014f600] Invalid frame dimensions 0x0.
[mpeg2video @ 000000000014f600] Invalid frame dimensions 0x0.

--input-probesize や --input-analyze 、-m max_interleave_delta のストリーム認識時間の高速化コマンドを外して試してもみましたが、効果はありませんでした。今のところ他の環境では確認できていませんが、症状からして他の環境でも再現するような気がしています。

何回も何回もやりとりする事になってしまい申し訳ありません。それではよろしくお願いします。

QSVEncC 5.02beta4 で試したところ、なんとノイズなく正常にエンコードすることができました…！！！

確認いただきありがとうございました。もう解決できないかと思っていたので、無事動作してよかったです！

エンコードができるようになったので TVRemotePlus の方でも使ってみたのですが、エンコード自体は問題ないものの、最初の 1 セグメントだけのエンコードで終了してしまい、HLS セグメントを連続してエンコードすることができていません。

あまり時間がなくまだざっくりしか調べていませんが、QSVEnc 5.00からの--avsync forcecfrの実装に問題があり、これが原因で途中で処理が止まってしまっておりました。なお、--avsync vfr では問題なさそうでした。今回の--avsync forcecfrはちょっと厄介そうな問題で、どう修正するかも含めて考える必要があり、修正には時間がかかりそうです。申し訳ありません。

ちなみに、--avsync vfrでなく--avsync forcecfrをTVRemotePlusで使用しているのは、なにか理由がありましたでしょうか? 固定フレームレートが必須なければ、--avsync vfrのほうが安定するかもしれません。

もう解決できないかと思っていたので、無事動作してよかったです！

こちらこそありがとうございました！

QSVEnc 5.00からの--avsync forcecfrの実装に問題があり、これが原因で途中で処理が止まってしまっておりました。なお、--avsync vfr では問題なさそうでした。今回の--avsync forcecfrはちょっと厄介そうな問題で、どう修正するかも含めて考える必要があり、修正には時間がかかりそうです。申し訳ありません。

まさか --avsync forcecfr に問題があったとは…想定外でした。時間がかかるとのこと、了解です。ひとまずオプションの変更で対応します。

ちなみに、--avsync vfrでなく--avsync forcecfrをTVRemotePlusで使用しているのは、なにか理由がありましたでしょうか? 固定フレームレートが必須なければ、--avsync vfrのほうが安定するかもしれません。

TVRemotePlus で使っている QSV/NV/VCEEncC のコマンドの大元は TVRemoteViewer_VB で使われているプリセットから引っ張ってきています。あのプリセットは TVRemoteViewer_VB の開発者の方が長年試行錯誤して編み出したものでしょうから、それを使うのが手っ取り早かったのもあります。そのコマンドで安定してエンコードできているのでずっとそのままになっていました。

なので --avsync forcecfr に深い意味はありません。TVRV で指定されているからには何か理由があるのだろうと思いそのままにしていただけです。不安定になったりエンコードが遅くなる、あとは音ズレが起きるとかがないのなら --avsync vfr でも問題ないので、一度試してみます。

私自身エンコードや映像技術に関してさほど詳しい訳ではなく、今使っているエンコードコマンドがベストプラクティスかというとかなり微妙です。もし --avsync forcecfr 以外にも変更した方がいいオプションがあればむしろ教えて頂きたいくらいです。（たとえば画質（ビットレート）周りは上げすぎるとセグメントのサイズが増えてDLが再生に追いつかなくなり結果再生がカクカクしてしまうが、今の 6000K でもパーティクルのような情報量の多いシーンだと一時的にセグメントのサイズが増える事でカクついてしまうことがあり、一定以上のビットレートにならないようにできたら… などなど）

さて、--avsync vfr を試してみましたが、NVEncC では問題ないものの、私の環境の QSVEncC では改善していないようです。完璧に検証できていないので完全に正しいかどうかはわかりませんが、以下が検証結果になります。

--avsync vfr では、字幕オン/オフに関係なく・MFXDEC: DecodeFrameAsync error: device operation failure.. ・CHECKPTS: check_pts(22): timestamp of video frame is smaller than previous frame, changing pts: 8503681502 -> 8503714910 (previous pts 8503714535). ・エラーメッセージは audio decode error 以外は出ないが永遠にエンコードが始まらないこの3つの症状のうちいずれかが発生し、エンコードが1セグメントだけか全く始まらずに終了する
--avsync cfr で字幕オンにした場合は高確率先ほど上げた3つの症状のうちいずれかが発生し、エンコードが1セグメントだけか全く始まらずに終了する場合が多い
- 稀にうまくいく場合もあるようだが、その場合は字幕オフ時同様に音ズレする
--avsync cfr で字幕オフにした場合は2セグメント以降もエンコードが正常通り継続されるようだが、100%ではなさそうな上に、若干の音ズレがある
- リップシンクが微妙にずれて吹き替えみたいになってしまう

--avsync forcecfr でもやってみましたが、エラーメッセージこそ異なる (CHECKPTS: Big Gap was found between 2 frames, avsync might be corrupted.) もののエンコードが止まる事に関しては vfr と共通しています。 --input-probesize とか max_interleave_delta あたりは外してもあまり関係していなさそうでした。

全く同じ挙動にならないので検証がかなりやりにくいのですが、いずれにせよ非常に不安定で、私の環境では現状実用的でないと言わざるを得ません…。

…これでいける…！と思いきやうまくいかなかったりの繰り返しって結構しんどいですね… さすがに3週間もやってると…

うーん、こちらでは開発環境のあるWin10+i7 11700K(Rocketlake)のPCにTVRemotePlusをインストールしてQSVEncCを試していますが、問題なく--avsync vfrで動作していますね…。音ずれ等も起きていません。

QSVEnc 5.01beta4で昨日に続き多数のチャンネルでだいぶ試しましたが、こちらでの--avsync vfrの検証結果は以下の通りです。

QSVEncC	TVRemotePlus	動作状況
5.01beta4	2.5.0	特に警告もなく、問題なく動作する。
5.01beta4	開発版字幕あり	下記警告が表示されることがあるが、ほぼ問題なく動作する。・check_pts(N): timestamp of video frame is smaller than previous frame, changing pts ・audio decode error ・稀にApplication provided invalid, non monotonically increasing dts to muxerでエラー終了

少なくともおっしゃるような全滅に近い状況にはなっていないです(そのため昨日--avsync vfrを提案させていただきました)。

これは環境の違いでしょうか…。

check_pts(N): timestamp of video frame is smaller than previous frame の警告メッセージは、デコーダが異常なタイムスタンプ(前のフレームよりも早い時刻のタイムスタンプのフレームが出てきた)を返したため、強制的にタイムスタンプを修正したことを意味します。これ自体は致命的なエラーではないので、こちらの環境では処理継続できていますが、なぜ、こうしたタイムスタンプが出てしまうのかはいまのところ不明です。ただ、---log-level debugをつけると、最初のセグメント付近で[mpegts @ 0000008a6e8f00c0] Packet corruptという読み込んだパケットが壊れている旨を知らせるエラーが出ており、タイムスタンプの問題に関しては、このあたりが原因の可能性がありますが、詳細まではつかみ切れていません。

TVRemotePlusの開発版でNVEncCを使うと最初のセグメントだけ映像が乱れる旨おっしゃっていましたが、それとも関係あるのかもしれないです。

--avsync cfrはタイムスタンプが不安定な場合、ご指摘の通り音ずれの可能性がありますので、現実的ではないと思います。

check_pts(N): timestamp of video frame is smaller than previous frameは通常のtsをファイルから読み込ませた場合には出てこないので、ちょっと分析に苦戦しています。全体的に長々とお時間いただいてしまっていて申し訳ありません…。

TVRemotePlus で使っている QSV/NV/VCEEncC のコマンドの大元は TVRemoteViewer_VB で使われているプリセットから引っ張ってきています。

ああ、なるほど、そういうことですね。当時は、--avsync vfrがなかったので、--avsync forcecfrを使用していただいておりました。

たとえば画質（ビットレート）周りは上げすぎるとセグメントのサイズが増えてDLが再生に追いつかなくなり結果再生がカクカクしてしまうが、今の 6000K でもパーティクルのような情報量の多いシーンだと一時的にセグメントのサイズが増える事でカクついてしまうことがあり、一定以上のビットレートにならないようにできたら… などなど

--qp-max 24:26:28を使用しておられるので、ビットレートの変動を許容してでも画質を維持しようとされているのだと思っておりました。

フレームを圧縮する際に圧縮の段階(のようなもの)を決めるのですが、これを量子化量(QP)と呼びます。これは、1～51の値をとり、1のほうが高画質だが低圧縮、51のほうが低画質だが高圧縮というふうになります。--qp-maxは、この量子化量の上限を決めるものです。--qp-max 24:26:28はQP上限としては低めな印象で、情報量の多いフレームでQPを落とせない(=高圧縮よりにできない)ことにより、ビットレートが上振れしやすくなってしまうと思います。

転送量の振れ幅を抑え、カクツキを減らすには、ビットレートの上限を抑える --max-bitrate を使用すると良いかもしれません。例えば、1080pのプリセットは、--vbr 6800とされていますが、--qp-maxのほうは削除し、例えば--max-bitrate 9000など指定されるといかがでしょうか。もちろん、--max-bitrateを抑えると情報量の多いフレームで画質が低下しますが、そのあたりはトレードオフということになります。

もし --avsync forcecfr 以外にも変更した方がいいオプションがあればむしろ教えて頂きたいくらいです。

やや気になったのが、プリセット関係(--preset)でしょうか。個人的には標準のままを使われるのがよいかと思います。標準で十分高速で圧縮率とのバランスがとれています。最高速のプリセットはかなり低圧縮なのでビットレートが膨れやすく、転送起因のカクツキの原因になるかもしれないと懸念しています。

もちろんこれはエンコーダ開発の立場からのご提案ですので、的外れな話だと思われましたら、申し訳ありません。

転送量の振れ幅を抑え、カクツキを減らすには、ビットレートの上限を抑える --max-bitrate を使用すると良いかもしれません。

大変参考になりました。本当にありがたいです。私としては --qp-max はむしろビットレートが上がりすぎないように制限するオプションだとばかり思い込んでいましたが、どうやら完全に逆だったようですね…（その用途なら --qp-min を使うべきだったか）

https://github.com/tsukumijima/TVRemotePlus/commit/7785f237852b0e4d3ac73818ddd6f7eb3c3184db にて最大ビットレートを ffmpeg なら -maxrate 、QSV/NV/VCEEncC なら --max-bitrate で指定するようにしてみました。今のところ問題なくエンコードできています（動きが激しかったりで情報量の多いシーンがやってこないと効果があるかわからないけど）。最大ビットレートの値は画質ごとに --vbr が 6800K のときに 9000K くらいになる、だいたい 1.38 倍程度に設定してあります。下げすぎると動きの激しいシーン以外でも画質が落ちそうですし。

ストリーミングなので、理想は動きの少ないシーンではデータ量（通信量）を減らしつつ、動きの多いシーンでは最大ビットレートを制限してデータ量（通信量）が増えすぎるのを防げている状態です。今回の設定変更でだいたい実現できたと思っています。

やや気になったのが、プリセット関係(--preset)でしょうか。個人的には標準のままを使われるのがよいかと思います。標準で十分高速で圧縮率とのバランスがとれています。最高速のプリセットはかなり低圧縮なのでビットレートが膨れやすく、転送起因のカクツキの原因になるかもしれないと懸念しています。

その話は初耳でした。できるだけ早くエンコードしたいなら一番早くエンコードできるプリセットを選択すべきだと思っていましたが、そういう訳でもないんですね… 同じビットレートでも、低速なプリセットにするほど時間をかけて圧縮できるので圧縮率が上がり、高速なプリセットにするほど素早くエンコードするので圧縮に時間を割けず圧縮率が下がる、という理解で良いでしょうか？

https://github.com/tsukumijima/TVRemotePlus/commit/8928d4c244845ccfae970f6bd182026edccb41d0 にて、ライブ配信用のプリセットを QSVEncC は --quality balanced に、NV/VCEEncC では --preset default に変更してみました。確か以前試した時も顕著にエンコード速度が上がっているようには感じられなかったので、この設定でやってみます。（単にプリセットのオプションを削除するでも目的は達成できるけど、後で分からなくなりそうだし明示的に指定しておきたかった）

まず私だけでは気づけなかったポイントで大変助かりました。ありがとうございました！

うーん、こちらでは開発環境のあるWin10+i7 11700K(Rocketlake)のPCにTVRemotePlusをインストールしてQSVEncCを試していますが、問題なく--avsync vfrで動作していますね…。音ずれ等も起きていません。

そうでしたか… QSV が利用可能な PC 自体はいくつか持っているので、今度私の方でも別環境にて検証してみます。メインの開発 PC（ノート）は Intel Graphics 620 で Coffee Lake のものです。

TVRemotePlusの開発版でNVEncCを使うと最初のセグメントだけ映像が乱れる旨おっしゃっていましたが、それとも関係あるのかもしれないです。

ライブ配信の場合、以前は QSVEncC などのエンコーダー側で受信していた TSTask からの UDP ストリームを arib-subtitle-timedmetadater の方で受信するように切り替えたことで、「エンコーダーではパケットロスなしに UDP ストリームを受信できていたのに、arib-subtitle-timedmetadater で UDP ストリームを受信すると最初に大きくパケットロス（ブロックノイズ）が発生し、その後もちょくちょく小さいパケットロスが起きる」という症状に長らく悩まされていました。 BonDriver_UDP で受信するとパケットロスなく再生できるので、TSTask ではなく受信側の問題なのはほぼ確実です。結果的に recvBufferSize (SO_RCVBUF) に 1000000 を指定することで少なくとも表面上は解決したのですが、映像の写りとしては問題ないけど何かしらのパケットが壊れている、という可能性が無きにしもあらず…かもしれません。

2.5.0 と開発版のエンコード周りでの最大の違いは arib-subtitle-timedmetadater の有無なので、QSVEncC 5.01beta4 + 開発版に arib-subtitle-timedmetadater を使わずエンコーダーで直接 UDP ストリームを受信するよう変更を加えた TVRP で試して、それでエラーメッセージが出なくなれば何かしら arib-subtitle-timedmetadater が関連していると考えられます。逆にエラーメッセージが出続ける場合はストリーム認識の短縮など、別の変更箇所に原因がありそうです。とはいえ仮に arib-subtitile-timedmetadater に問題があったとしても NVEncC では問題なくエンコードできているので、ストリームを受け取る側で対処できる問題なのかな…とも。

NVEnc・VCEEncC と違い、ドライバーも GPU の機種もまちまちとなると色々環境依存が出てくるんでしょうかね… エンコードがうまくいかない件は最悪私の環境でだけ --avsw に変えるつもりでいましたが、今回はそうもいかないし悩みもの。

Core i5-8250U・Intel Graphics 620 (Coffee lake) の環境（メインの開発 PC ）で現在最新の開発版 TVRP を入れて試してみましたが、こちらでもあまり安定しなさそうな感じでした。

Sandy Bridge の録画 PC ほどではないですが、1/3 ～ 1/4 の確率で下記のようなエラーが発生し、エンコードが1セグメント目だけで止まってしまいます。チャンネルは関係なさそうでした。字幕の有無が確率に影響するかは微妙で、必ずしも字幕オンで失敗するという訳でもなさそうです。

エンコードが止まる確率が録画 PC より低いので、ストリーム再起動1回だけで復帰できるケースが多数でした。 …とはいえ、3 回に 1 回の確率でエンコードに失敗するのはちょっと厳しいものがあります。エンコード失敗→ストリーム再起動でトータル 30 秒くらいロスしてしまいますし。

avout: failed to send packet to audio decoder: Invalid data found when processing input.
avout: avcodec writer: ignore error(1) on audio #1 decode at 6778405266(75315.6)
avout: failed to send packet to audio decoder: Invalid data found when processing input.
avout: avcodec writer: ignore error(2) on audio #1 decode at 6778407186(75315.6)
avout: Error: Failed to write video frame: Invalid argument.

encoded 74 frames, 50.48 fps, 5636.26 kbps, 1.66 MB
encode time 0:00:01, CPULoad: 19.4
frame type IDR  3
frame type I    3,  total size  0.28 MB
frame type P   20,  total size  0.79 MB
frame type B   51,  total size  0.59 MB

[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
[aac @ 0000026942155500] error in spectral data, ESC overflow
[aac @ 0000026942155500] Reserved bit set.
[aac @ 0000026942155500] Number of bands (17) exceeds limit (15).
[hls @ 00000269421fc480] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 381381 >= 195195

avout: failed to send packet to audio decoder: Operation not permitted.
avout: avcodec writer: ignore error(1) on audio #1 decode at 4926207838(54735.6)
avout: failed to send packet to audio decoder: Operation not permitted.
avout: avcodec writer: ignore error(2) on audio #1 decode at 4926280798(54736.5)
avout: failed to send packet to audio decoder: Invalid data found when processing input.
avout: avcodec writer: ignore error(1) on audio #1 decode at 4926282718(54736.5)
avout: failed to send packet to audio decoder: Invalid data found when processing input.
avout: avcodec writer: ignore error(2) on audio #1 decode at 4926286558(54736.5)
avout: Error: Failed to write video frame: Invalid argument.

encoded 45 frames, 24.14 fps, 5289.00 kbps, 0.95 MB
encode time 0:00:01, CPULoad: 8.6
frame type IDR  2
frame type I    2,  total size  0.26 MB
frame type P   12,  total size  0.49 MB
frame type B   31,  total size  0.19 MB

[mpeg2video @ 000001e49706d100] Invalid frame dimensions 0x0.
[mpeg2video @ 000001e49706d100] Invalid frame dimensions 0x0.
[mpeg2video @ 000001e49706d100] Invalid frame dimensions 0x0.
[mpeg2video @ 000001e49706d100] Invalid frame dimensions 0x0.
[aac @ 000001e497083fc0] decode_pce: Input buffer exhausted before END element found
[aac @ 000001e497083fc0] decode_pce: Input buffer exhausted before END element found
[aac @ 000001e497083fc0] TYPE_FIL: Input buffer exhausted before END element found
[aac @ 000001e497083fc0] channel element 2.14 is not allocated
[hls @ 000001e497c38380] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 183183 >= 117117

微妙にログが違ったので2つとも載せていますが、どちらとも [hls @ 000001e497c38380] Application provided invalid, non monotonically increasing dts to muxer in stream 0: というエラーメッセージで終了しています。

そちらの第11世代では「稀に」とのことでしたが、私の環境ではお世辞にも稀とはいい難い確率でした。録画 PC から BonDriver_Proxy (BonDriverProxyEx) でリモート受信していますが、それが影響するとも思えません。

また気になる点として、録画 PC で使っている NVEncC では発生しなくなった最初のブロックノイズ（パケットロス）が開発 PC の方ではたびたび発生してしまうことが上げられます。パケットロスしすぎて正常にエンコードできなくなり QSVEncC が落ちてしまう、という可能性もありそうな気はしています。

同じ開発 PC で ffmpeg を使う場合は、字幕オン/オフに関係なく 1 セグメントだけでエンコードが止まるような事は発生しませんでした。ただし、パケットロスは発生するように見えます。

http://poepoemix.blogspot.com/2012/06/flvffmpeg.html いわく、

Application provided invalid, non monotonically increasing dts to muxer in stream 0: 数値 < 数値というエラーがでて、動作しないことがあるらしい。なにかというと、データ内部のパケットが順番にきちんと並んでいない場合に発生するエラーらしいです。

とのことなので、順当に見れば受信したデータが不正なのが悪い、という事になりそうです。そうすると NVEncC では問題ないのがよくわからなくなりますが… もう少し検証してみます。

また、録画PC (Sandy Bridge) でファイル再生を QSVEncC で行おうとすると、ログのヘッダーが出力された後は何も出力されず、プロセスはずっと立ち上がっているが一向にエンコードが始まらないという状態に陥るようです。同じ録画ファイルを ffmpeg と NVEncC でエンコードするとうまくいくのは確認しています。

これに関しては arib-subtitle-timedmetadater を使わず -i に直接ファイルパスを指定しても同様の結果になったので、ファイル再生のこの症状に関しては QSVEncC 側に原因があるとみて間違いありません。同じ状態でも NVEncC では正常にエンコードできています。

ただし、この症状は先ほどの開発 PC では発生しませんでした。ファイル再生では非常に安定して再生でき、字幕も問題ありません。どの症状が何が原因でどれが環境依存なのか中々分からずしんどいところ…

こちらではRocketlake環境に加え、Haswell環境で検証しています。

こちらでは前回

Application provided invalid, non monotonically

の致命的なエラーは稀と述べましたが、ご指摘のようにもう少し多いようです。

やはりどうもhwデコーダの返すタイムスタンプが大きく飛んでいる(なんと0.7秒分いきなりタイムスタンプが飛んだりする)など、最初のセグメント付近でおかしな挙動を示しています。29.97fpsなのにいきなり0.7秒分も飛んでいると、--avsync vfrでの対処は難しそうです。

この問題をQSVEncC側でなんとか吸収するには、5.01でバグらせてしまった--avsync forcecfrを正常動作させるしかないと考え、現在作業中です。メインループを大きく書き換えたのち、こちらで検証を行ってよさそうならまた実行ファイルを共有しますので、もう少々お待ちください。

-i に直接ファイルパスを指定しても同様の結果になったので、ファイル再生のこの症状に関しては QSVEncC 側に原因があるとみて間違いありません。同じ状態でも NVEncC では正常にエンコードできています。

すみません、いろいろやり取りする中で混乱してきてしまいました。以前、ファイル入力にしたときは、SandyBridgeでは緑色の絵が出ていて、それが5.01beta4で解決したとおっしゃていたと認識していましたが、これが今度はエンコードが止まるようになったということでしょうか ?

こちらでは前回 Application provided invalid, non monotonically の致命的なエラーは稀と述べましたが、ご指摘のようにもう少し多いようです。

やはりそうでしたかー… 第11世代でエラーになりにくいのは単に性能向上が関係していたりするんでしょうか。謎です。

やはりどうもhwデコーダの返すタイムスタンプが大きく飛んでいる(なんと0.7秒分いきなりタイムスタンプが飛んだりする)など、最初のセグメント付近でおかしな挙動を示しています。29.97fpsなのにいきなり0.7秒分も飛んでいると、--avsync vfrでの対処は難しそうです。

これは QSVEncC（または Intel Graphics ハードウェア）側でうまくデコードできていないという状態ですか？それとも大本の標準入力から流れて来たストリームが既に壊れていてどうしようもないって所でしょうか？ --avsync forcecfr を正常動作できるようにしていただけるとのことなので、気長に待ちたいと思います。

すみません、いろいろやり取りする中で混乱してきてしまいました。以前、ファイル入力にしたときは、SandyBridgeでは緑色の絵が出ていて、それが5.01beta4で解決したとおっしゃていたと認識していましたが、これが今度はエンコードが止まるようになったということでしょうか ?

こちらこそ伝えている情報と伝えていない情報でごちゃごちゃになってしまっていてすみません… 正確には、HLS へのエンコードのみそのような問題が発生するという話ですね（おそらくは）。HLS (m3u8+ts) ではなく普通に mp4 などにエンコードする場合は問題なくエンコードできています。ちなみに、この問題はファイル再生だけでなくライブ配信でも起きています。

開発 PC (Coffee lake) の方で試しにライブ配信に arib-subtitle-timedmetadater を使用せず、直接 QSVEncC で UDP 受信するようにしてみたところ、いつも出ていた下記のエラーが無くなりました。また最初のパケットロス（ブロックノイズ）もなくなりました。ffmpeg でも開発 PC ではパケットロスによるものか最初にドカっとブロックノイズが載っていたのですが、これもなくなりました。

avout: failed to send packet to audio decoder: Invalid data found when processing input.
avout: avcodec writer: ignore error(1) on audio #1 decode at 3984589016(44273.2)
avout: failed to send packet to audio decoder: Invalid data found when processing input.
avout: avcodec writer: ignore error(2) on audio #1 decode at 3984700376(44274.4)

さらに、1 セグメント目でエラー終了してしまう問題も起きなくなったように感じます。つまり、少なくともこれのエラーの要因はエンコーダーと異なり UDP 受信がうまくできていない事にあるみたいです（あとは考えにくいけど --data-copy がうまく機能していないとか…？）。パイプ渡しだとエンコーダーの挙動が違うとかがあるのならまた話が変わってきますが。

NVEncC ではうまくいっているのが謎ですが、HW 側がエラーを吸収できる/できないの差なのでしょうか。

これは QSVEncC（または Intel Graphics ハードウェア）側でうまくデコードできていないという状態ですか？それとも大本の標準入力から流れて来たストリームが既に壊れていてどうしようもないって所でしょうか？

私のほうでmpeg2videoのデータが正常かどうかまではわからないのですが、いろいろ試した限りでは、どうも流れてきた先頭付近のパケットが壊れていて、そのあたりのフレームが丸ごとHWデコーダから出てこず脱落しているように見受けられます。それで一気に時間が飛んでしまっている気がします。

ざっと様子を見ただけですが、VCEEncCもQSVEncC同様TVRemotePlus開発版ではエラー終了が多発してしまいます(QSVEncCより多め)。一方、こちらもTVRemotePlus 2.5.0でUDPを直接受信すると問題なかったです。こうなってくると、NVEncCではうまくいくのは、たしかに謎ですね。おっしゃるようにHWデコードのエラー耐性が違うのかもしれません。

私としては、QSVのHWデコードのエラー耐性を高める、といったところまでは手が出ないので、--avsync forcecfrを動作できるようにし、フレーム間が大きく空いてしまっても対応できるようにしたいと思います。

正確には、HLS へのエンコードのみそのような問題が発生するという話ですね（おそらくは）。HLS (m3u8+ts) ではなく普通に mp4 などにエンコードする場合は問題なくエンコードできています。

なるほど、状況理解しました。ただ、この問題は、こちらでテストした限りHaswell/Kabylake/Rocketlakeで発生していないので、ちょっとまた別の環境固有の問題のように感じます。こちらの調査はすみませんが後ほどとさせてください。

--data-copy がうまく機能していないとか

たしかに差異としてはそうなりますが、これが影響するとしてもmux側で、動画・音声のデコードに影響を与えるとは考えにくいです。

すみません、試しに TSTask を TCP で送信し、arib-subtitle-timedmetadater で TCP 受信するように変えてみたら、エンコーダー側で UDP 受信するとき同様に ffmpeg・NVEncC にてエラーが出なくなりました…。検証不足でした…。 https://github.com/tsukumijima/TVRemotePlus/commit/68f4982d2618e8e0b7647e3ef3e8b6c9512336ec にて TSTask で TCP 送信、arib-subtitle-timedmetadater で TCP 受信するようにしてみました。

やはり UDP 受信で（映像には影響ないものの）何かしらのパケットロスが発生していて、ffmpeg と NVEncC 以外はその不正なデータの耐性が弱いために落ちてしまうって感じなのではないかと予想します。

ただし、開発 PC の方では QSVEncC が復活して普通に動くものの、録画 PC の方では依然としてうまくいきません。なぜか ffmpeg と NVEncC では表示されなくなった上記の failed to send packet to audio decoder: Invalid data found when processing input. が未だに出るし（必ずではない）、エンコードも始まりません。これに関しては確かに別問題のようですね…

でもだいぶ切り分けができた気がします。取り急ぎ報告まで。

録画 PC (Sandy Bridge) 環境で QSVEncC のエンコードが 100% の確率で始まらない件ですが、以前アドバイスいただいた時に QSVEncC のコマンドオプションを --avsync vfr に変えたのが原因だったようで、--avsync forcecfr に戻すとエンコードが始まるようになりました…！！！字幕も遅れなく表示されます。

もちろん以前仰られていた forcecfr の不具合の関係か1セグメントだけで落ちてしまうこともありますが、必ずしもそうなるわけではないようで、運が良ければ字幕が表示された状態でストリーミングを継続できることもありました。QSVEncC が落ちる確率はそこまで高くなさそうな感じです。1/2 くらいなんだろうか…？ただ開発 PC (Coffee Lake) では vfr でも何の問題なくエンコードので、このあたりはおそらく世代差によるものなのでしょう。

録画 PC だとなぜか QSVEncC だけ TCP 送信でも最初だけはブロックノイズが入ってしまうことがある（毎回ではない）が、これが TCP 受信がうまくいっていない事によるデータの破損が原因かはわかりません。パケットロスした場合はログにはいつもの failed to send packet to audio decoder: Invalid data found when processing input. が出るほか、パケットロスするしないに関わらず Big Gap was found between 2 frames, avsync might be corrupted. も出ることが多いです。もしかすると forcecfr の不具合が関連しているかも…？

ちなみに TCP 受信の場合の録画 PC の NVEncC では 30 分番組を見ていても一切ブロックノイズは入りませんし、ログに failed to send packet to audio decoder: Invalid data found when processing input. も出ていません。おそらくパケットロスは起こっていないものと思われます。ffmpeg でも検証する限りはパケットロスは出ていません（UDP受信していた頃は、ffmpeg の字幕ありの場合でたまにパケットロスが連続的に続いて見るに耐えない事が）。

…ということで、もしかするとですが、forcecfr の一件が直れば万事解決できるかもしれません。

一方開発 PC の場合、TCP 受信で QSVEncC を字幕あり/なしそれぞれで使っても、パケットロスも発生せずスムーズに再生できています（TCP 受信に変更するコードは TVRP の master にあげてあります）。何回か試した限りでは開発 PC だと Application provided invalid, non monotonicall が出るどころかエンコードがエラーで止まる事自体がありませんでした。ログにもエラーは出ていないように見えます。結局諸々の元凶は UDP 受信で発生する壊れたデータと --avsync forcecfr にあったみたいですね…。

ファイル再生では字幕ありの番組、字幕なしの番組に関係なく、録画 PC でも開発 PC でも問題ない？と思われます。TCP 送受信を行わず arib-subtitle-timedmetadater 側でファイルを読み取る形になるので、パケットロスは原理的に発生しないと思われます。また、ライブ配信とは異なり、エンコーダーが何らかのエラーで落ちるといった事が今のところ起きていません。開発 PC は全くエラーログがなく、録画 PC も CHECKPTS: Big Gap was found between 2 frames, avsync might be corrupted. という謎のエラー（ただしエンコード後の映像には影響していないと思われる）が出る以外は問題なさそうです。

一部の録画で開発 PC・録画 PC に関わらず avqsv: corrupt packet in stream 5: 1696525186 (18850.3) のようにログが出ることはありますが、たとえばこのログが出た録画（字幕放送）では映像・音声・字幕・字幕スーパー(？)の4つが stream 1～4 を占めていることから、stream 5 は timed_id3 だと推定されます。字幕なし番組→字幕あり番組に切り替わった時（=エンコード途中から字幕が追加される場合）に字幕が表示されない事を防ぐため、arib-subtitle-timedmetadater 4.0.0 では字幕ストリームの有無を問わず timed_id3 ストリームを追加するようにしていただきました。おそらくその関係の何かだとは思いますが、字幕の遅延が起きているわけでもエンコードに支障が出ているわけでもないので、今のところは気にしなくてもいいかなーと思っています。

いろいろかなりこちらの検証不足だったようで、大変申し訳ない限りです……。

余談ですが、私の開発 PC は正確には Coffee Lake ではなく Kaby Lake-R だったみたいです（ QSVEncC のログにありました）。 Wiki いわくそのあたりの機種は明確にスペックが別れているわけではないようなので、そこまで気にする必要もないとは思っていますが…

状況のご連絡、arib-subtitle-timedmetadater の更新、それによるTVRemotePlus側の実装によりパケットロスへの対策いただき、ありがとうございます。

こちらではQSVEnc 5.02に更新しました。大型更新に伴い発生した不具合の修正に加え、本件で重要な--avsync frocecfrの改善を行っています。

TCP受信に変更いただいた最新のTVRemotePlusとQSVEnc 5.02を組み合わせて、私のQSV開発PC(Rocketlake)と録画PC(i5 7500 [Kabylake]、お持ちの開発 PCと同じ世代です)、さらにi3 4330(Haswell)で試しました。相変わらずAACのエラーは出ますが、パケットロスに対策いただいたおかげでエラー終了は(試した限りでは)起こらずチャンネル切り替えできるようになりました。TCP受信の効果は抜群のようです！

さて、QSVEnc 5.01の--avsync frocecfrの問題は、当初フレーム間が大きく空いてしまうことを想定しておらず、具体的には連続16フレーム以上の挿入は行えない仕様となっており、それ以上の挿入でエラー終了が発生してしまうという問題でした。さらに不具合により、連続10フレーム程度でもエラー終了が発生してしまう場合があるようでした。以前ご報告したように、パケットロスにより0.7秒程度の連続フレーム挿入が必要となり、この問題が多数発生し、エラー終了していたものと思います。 QSVEnc 5.01で--avsync frocecfrがこのような実装となっていたことで、--avsync vfrをお試しいただくこととなってしまい、結果的に迷走させてしまいました。申し訳ありませんでした。

QSVEnc 5.02では、実装を丸ごと見直すことで、連続フレーム挿入を無制限(実際には18000フレームの制限付き)に可能となりました。

QSVEnc 5.02への更新と--avsync frocecfrにしていただくことで、下記問題が解決されると思います。

CHECKPTS: Big Gap was found between 2 frames, avsync might be corrupted
Application provided invalid, non monotonically increasing dts to muxer

下記警告は引き続き表示される場合がありますが、エンコード開始時のみであれば、エンコード開始時に必要なデータが集まりきっていないだけなので、特に問題ございません。

[mpeg2video @ 0000026942148a00] Invalid frame dimensions 0x0.
failed to send packet to audio decoder: Invalid data found when processing input.
avcodec writer: ignore error(x) on audio #1 decode at xxxxxxx.

下記警告は引き続き表示されますが、特に問題ないようです。

AAC bitstream not in ADTS format and extradata missing

すみませんが、Sandybridge環境における下記エラーは未解決な可能性が高いです。他環境で再現性がなく、デバイス固有のものと思われます。

MFXDEC: DecodeFrameAsync error: device operation failure.
1セグメント目で落ちる問題(?)

QSVEncC 5.02 のリリースありがとうございます！早速試したところ、開発 PC では NVEncC などと同様に全く問題なくエンコードできています！これでようやく一件落着といったところです。

下記警告は引き続き表示されますが、特に問題ないようです。

AAC bitstream not in ADTS format and extradata missing に関してはほぼ 100%（デュアルモノでない）音声多重放送（二ヶ国語放送・解説放送）の番組でのみ発生する警告のようです。こちらでも特に問題ありません。ffmpeg でも音声多重放送の場合はそうなりますし、（ログがめちゃくちゃいっぱい出て目障りですが）気にしなくてよいと思います。

すみませんが、Sandybridge環境における下記エラーは未解決な可能性が高いです。他環境で再現性がなく、デバイス固有のものと思われます。

仰る通り、録画 PC でたまに MFXDEC: DecodeFrameAsync error: device operation failure. が発生する問題は残念ながら解決していません。また、1 セグメント目で落ちる問題はこのエラーログと同じタイミングで発生しているので、同じ1つの問題だと考えられます。また、開発 PC では表示されなくなった CHECKPTS: Big Gap was found between 2 frames, avsync might be corrupted というログも、録画 PC だと毎回表示されています。

試しに --avsw でデコードをソフトウェアデコーダーに変更してみると MFXDEC: DecodeFrameAsync error: device operation failure. も、CHECKPTS: Big Gap was found between 2 frames, avsync might be corrupted も、1 セグメント目で落ちる問題も発生しなくなり、問題なくエンコードできるようになりました。

ただし、そこそこの頻度で再生の最初にブロックノイズが発生する問題に関しては、--avsw の場合でも TCP 受信なのにも関わらず発生します。したがって、ブロックノイズに関しては HW デコード側の問題ではなさそうです。（ブロックノイズが発生するタイミングで failed to send packet to audio decoder: Invalid data found when processing input. と avcodec writer: ignore error(x) on audio #1 decode at xxxxxxx. が表示されることが多いので、何らかの原因でパケットロスしていると思われる・出ない時は映像しかパケロスしてないとか…？）

ただこれも開発 PC の ffmpeg と QSVEncC 、録画 PC の ffmpeg や NVEncC ではブロックノイズが出ないので、HW エンコードなり他の部分の何かしらの環境依存が影響していると考えられます。

もしかすると arib-subtitle-timedmetadater で TCP 受信・変換を行っているのがブロックノイズ等の問題の原因なのではないかという仮説を立て、arib-subtitle-timedmetadater を通さず QSVEncC 側で直接 TCP 受信するように（-i "tcp://127.0.0.1:'.$stream_port.'?listen=1&recv_buffer_size=1000000"）変更してみました。しかし、結果は予想に反して MFXDEC: DecodeFrameAsync error: device operation failure. も、CHECKPTS: Big Gap was found between 2 frames, avsync might be corrupted も、1 セグメント目で落ちる問題も、ブロックノイズが出てしまう問題も解消されず、引き続き同じ症状となりました。改善された点は何一つありませんでした…。

TCP 受信を QSVEncC で直接やったのは初めてだったので、TCP 受信のパラメータが良くない or libav の TCP 受信機能が悪い可能性も考え、同様の条件で NVEncC でも直接 TCP 受信するようにして試してみたのですが、NVEncC ではブロックノイズが出ることはありませんでした。 QSVEncC も NVEncC も同じチャンネルで 5 回以上試してこうだったので、まぐれでブロックノイズが出なかった、ということも考えづらいです。

したがって、このブロックノイズが出る（おそらくどこかでパケットロスしている）問題は arib-subtitle-timedmetadater で受信→標準入力しているのが原因ではなく、UDP 受信時でも同じ問題が発生していた事、NVEncC ではブロックノイズが出ない事から TCP 受信による問題でもない（UDP と TCP 両方で発生する）と考えられます。

さらに、開発 PC やそちらの環境でも発生しない事から少なくとも Sandy Bridge より上の世代の GPU では発生しない問題で、ファイル再生では上記問題全て発生しない事からライブ配信（＝リアルタイムでストリームが流れてくる形態）に特有の問題で、追加した --input-probesize や max_interleave_delta 諸々を外しても変わらず上記の問題が発生する事からそれらのストリーム認識速度を短縮するためのコマンドはこの問題に影響しておらず、 --avsw（ソフトウェアデコード）でも --avhw（ハードウェアデコード）とほぼ変わらない頻度でほぼ同じような量のブロックノイズが入る事から、HW デコードによる問題でもない事が考えられます。

これらの結果から、私的には QSVEncC の何らかの処理に、リアルタイムでストリームを受信する場合のみ環境依存 (Sandy Bridge のみ？) で HW デコードより前の段階でパケットロスしうる原因があるのではないかと思っています。

そこそこの頻度で 1 セグメントまたは 0 セグメントでエンコードが終了してしまう問題も、HW デコードよりも前の段階でパケットロスが発生し、そのパケットロスが大きすぎると HW デコーダーが処理し切れずに（回復できずに）エラーを吐いて終了してしまう、と考えれば説明がつく気がします。

0セグメント：場合によってはセグメントが全く書き出されずに終了することもあった

SW デコーダーはパケットロスに強いので落ちる事こそないが、デコードの前段階で既にパケットロス（データ破損）が起きているためにエンコード結果としてはパケットロスによってブロックノイズの載ったものになる、と考えてもつじつまが合いそうです。 QSVEncC 固有の問題だとすると、ffmpeg や NVEncC で直接 TCP 受信してもブロックノイズが入らない件についても説明がつきます。

この予想が正しいとして、このブロックノイズの問題を修正できれば、1 セグメントで落ちる問題も同時に解決できるのではないかと踏んでいます（もちろん映像技術に詳しくない者の推測なので、誤っている可能性も当然あります）。少なくとも、漠然としたものよりかはこの問題が発生する条件がかなり絞り込めたのではないでしょうか。

手元で再現しない以上特定しにくいのは重々承知していますが、HW デコードだけでなく SW デコードでも発生するというのが気になっていて、もし思い当たる節等あれば確認していただけないでしょうか。よろしくお願いいたします。

録画 PC にて QSVEncC 4.13 にダウングレードしてみました。もちろん追加されたオプションは機能しないので、--input-probesize は削除、--data-copy timed_id3 は --data-copy に変更していますが、それ以外はそのままの状態です。

すると、MFXDEC: DecodeFrameAsync error: device operation failure. も、CHECKPTS: Big Gap was found between 2 frames, avsync might be corrupted も、1 セグメント目で落ちる問題も全て解決しました。よって、これらの問題は QSVEncC 5.00 以降の変更によって起きたものであることが考えられます。

ただし、ブロックノイズが入る問題に関しては QSVEncC 4.13 でも同様に発生していました。もしかすると、先ほどの予想とは異なり、QSVEncC 4.13 で解決した問題とブロックノイズが入る問題との因果関係はないのかもしれません。

arib-subtitle-timedmetadater を通さずエンコーダーで直接 UDP 受信した状態でブロックノイズが入るかどうかはまだ確認していないので、それでもしブロックノイズが入らないのであれば、（エンコーダーで直接受信・arib-subtitle-timedmetadater 経由とに関わらず）TCP 受信する場合のみ発生する問題なのかも…？よくわからなくなってきた…

前回の検証で arib-subtitle-timedmetadater で UDP 受信するとパケットロスが発生し、それが各環境でのエラーの原因になっていた事が分かっているので、arib-subtitle-timedmetadater での UDP 受信時のブロックノイズは同じパケットロスでも arib-subtitle-timedmetadater の受信が原因で別問題であると考えた方がよいかもしれません。

rigaya / NVEnc