少し機能追加。
[QSVEnc.auo / QSVEncC 共通]・aud / pic_structを付加するオプションを追加。QSVEnc.auoでは場所がないので2枚目のタブです。
[QSVEncC]・SkylakeのHW HEVC 10bitデコードに対応。・ffmpegのdllを更新。
QSVEnc ダウンロード>>ダウンロード (ミラー) >>OneDriveの調子がいまいちの時はミラー(GDrive)からどうぞ。同じものです。QSVEncBenchmark.zipはベンチマーク用です。(約234MBと重いので注意)。run_benchmark.batをダブルクリックで実行です。
QSVEncCのオプションについてはこちら。
QSVEncCオプション一覧>ソースはこちら
スポンサーサイト
早速の対応有難うございました。
今後とも宜しくお願いいたします。
先程、ｔｓファイルをＱＳＶでエンコード(ａｕｄ付加チェック)してみましたが、何故が倍率が変えられません。
--audをつけて出力したtest.mp4から
mp4box.exe -raw 1 test.mp4
h264_parse.exe test_track1.h264
として、H.264 rawを取り出して調べた場合、
・QSVEncCで直接出力したMP4
・x264で直接出力したMP4
だとaud（ref 0 type 9 Access unit delimeter）が
見つかるのですが、
・一度raw出力してからL-SMASHのmuxer.exeや
MP4BoxでmuxしたMP4
（QSVEncのGUIからの出力もこれ）
だと、audが見つからないようです。
後者は一見するとmuxによって
audが消えているようにも見えるのですが、
これはそういうものであって、
特に問題はないのでしょうか？
よくわかってないので、調べ方や解釈がおかしかったり
変なことを言っていたらすみません。
何度もすみません。
"ニコ動の新しい動画エンコード方式について (終)"コメントでは、
fawファイルで確認とありますが、何度試してもmp4だとダメです。
TvtPlay(aud付加なしVer)1式アップロードしましょうか？
お忙しいとは思いますが、宜しくお願いいたします。
fawじゃなくてrawでは。
mp4コンテナにいれる場合、audは不要になることからmux時に落としてしまうのかもしれません。
Tac様がおっしゃっているように、raw形式まではaud付加されていますので、オプション自体は正常に動作しています。
編集不要ならQSVEncCで直接mp4で出してしまえば楽なのですが、編集したい場合などはそれも難しいですね…
>fawじゃなくてrawでは。
そうです 間違いました。
rigayaさまへ
"L-SMASH muxer (r1405) でmuxを行います。"
上記は「拡張x264出力(GUI)Ex」「拡張QSV出力」も同じ処理してますが、拡張x264出力(GUI)Exではaud付加出来て、拡張QSV出力は出来ないのでしょうか？
素人考えの質問で恐縮です。
見た目は一緒ですし、muxerへのコマンドも同じなのですが、muxer側ではこれらは「同じ処理」ではなく「異なる処理」になります。
x264guiExはx264からmp4で出力できるので、mp4(映像) + m4a(音声) → mp4(映像+音声)のようなmux処理になります。
一方、QSVEncからはraw出力しかできないので、raw(映像) + m4a(音声) → mp4(映像+音声)のようなmux処理になっています。QSVEncからのmp4出力は、実装していないので、x264と同様の処理は難しいのです。
コマンド版のQSVEncCはmp4出力が可能なのですが…。
muxerの処理方法理解できました。
無理をお願いしたようです。
お騒がせ致しました。
いつも有りがたく利用させて頂いています。
早速ですが
● Haswell QSV
● 15.40.22.4424 x64ドライバ
● Windows 10 Pro x64
● AuoLink 利用
この環境において
QSVEnc.auo 2.55 を使用すると
「 OUTPUT_PLUGIN_TABLE::func_output() 」エラーを吐いて、エンコード開始直後に停止してしまうようになりました。
2.54 に戻すと正常にQSVエンコード可能なことから
2.55 において拡張された箇所が影響しているように思うのですが、そういった事は有り得ますでしょうか？
※
Intel HD Graphics ドライバが
15.40.22.4424 なのは
この後リリースされた
15.40.24.4454 や
15.40.25.4463 をインストールすると
QSVEnc.auo でのエンコードが何故か行えなくなるようになってしまったため、こちらの環境では 15.40.22.4424 を使用しています。
AuoLinkを使用されている場合、QSVEncではmuxその他の処理のため、libavcodec-**.dll等のdllを使用します。
QSVEnc 2.55では、一部でこれらのdllの新しい呼び出し方法を使用するように変更しました。そのため、これらdllの更新が必要となります。
そこで、QSVEncC/x86フォルダに入っている新しい32bit版のdllがAviutlフォルダにコピーされているかご確認いただけますでしょうか。されていない場合、QSVEncC/x86フォルダのdllをすべてAviutlフォルダにコピーしていただければと思います。
新しいdllをすでにコピーしてあるということですと、QSVEncの不具合の可能性が高いかと思います…すみません…
教えて頂いた
QSVEncC/x86/ の .dll 6個を
aviutl/ へ上書きしたところ、2.55において正常にQSVエンコードが始まるようになりました。
初歩的なことで躓いてお手数をお掛けしてしまい、申し訳なく思う次第です。
15.40.22.4424 より後の Intel HD Graphics ドライバでも QSVEnc.auo with AuoLink エンコードが上手く行くかもしれないので、この週末にでも時間を確保して試してみたいと思います。
AviUtl 1.00＋L-SMASH Works r877＋拡張QSV出力2.55で、
AuoLinkを使ってQSV出力すると、出力フレームレートが
29.97fpsに固定されてしまうようです。
入力ソースはx264guiEx2.40＋x264 r2705kmod＋L-SMASH r1384で
24000/1001fpsで出力したものを使いました。
他に8000/1001、24/1、1/1fpsでも同様の結果です。
なお、QSVEncC.exe --avqsvでのエンコードでは
きちんとソースフレームレートが維持されます。
・AviUtlでAuoLinkを使ってQSV出力した際のログ
http://pastebin.com/WSL9Wuy3
・QSVEncC --avqsv --log-level debugのログ
http://pastebin.com/b6jSBy8C
v2.54およびv2.24(AuoLink実装)でも同様でしたので、
当方の環境あるいは何らかの制約由来でなければ、
実装初期からの問題なのかもしれません。
TvRemoteViewer_VBでQSVEnc2.53を使って録画したテレビ番組を遠隔で視聴しているのですが
長めの動画の場合、途中でエンコードが終了してしまい、最後まで再生できないという症状が出てしまいます。
感覚としては再生している地点より10分前後先までエンコードが実施されると、そこでエンコードが終了してしまい、最後まで再生できなくなってしまうようです。
ただ、エラーで落ちているのではなく、ファイルのエンコードが全て終了した時と同じような動作をしているみたいです。
続きを再生するためには、一旦配信を終了させてから、エンコードが終わった地点から再度配信するようにしないとダメでした。
ffmpegを使えば上記のような症状は出ないそうなので、QSVEnc側の問題みたいなのですが、これに関してバッファのような設定などあるのでしょうか？
>Tac様
> AuoLinkを使ったQSV出力が29.97fps固定になってしまう
詳細に報告いただきありがとうございました。QSVEnc 2.56で修正しました。
http://rigaya34589.blog135.fc2.com/blog-entry-830.html
>もさ様
ファイル再生のほうは、ほとんど試してみたことがないので、まだよくわかっていません。挙動の確認をしてみます。
rigayaさま
下記のようなエラーが出て終了している事がわかりました
Failed to get free surface for vpp.
Error in encoding pipeline. : failed to allocate memory.
error at encode thread.
エラーがどういう内容かわからないので関係あるかどうかわからないですが、とりあえずメモリに関しては8GB積んでいて、エラーが出た時点でも使用率は35％くらいで、
QSVEnc自体のメモリ使用量は300MBちょっとでした。
入力ファイルによってはavsync forcecfrを使用すると"Failed to get free surface for vpp. "と出てしまう場合があります。実際にはメモリ不足ではなく、入力ファイルとavsync forcecfrの相性の可能性が高いです。
＞実際にはメモリ不足ではなく、入力ファイルとavsync forcecfrの相性の可能性が高いです。
なるほど、相性の問題ですか…
forcecfrは無いと困るので、エンコードが途中で終わってしまった場合は、再度そこからエンコードし直して何とかするしかなさそうですね。
ありがとうございました。
本当はそういった入力ファイルに対しても正常に動作するべきなのですが、いまのところ原因がよくわかっておらず、すみません。
