QSVEnc 0.15
機能の追加と問題の修正。
[共通]
・実験1 シーンチェンジ検出によるIフレーム挿入機能を追加。
・実験2 可変QPモードを追加。
両方とも入力がプログレッシブ(非インタレ)の時のみ有効。
・エンコード後、フレームタイプごとの総サイズを表示。
[QSVEnc]
・自動フィールドシフト使用時に不安定だった問題を修正。
・その他の設定にタイマー精度を向上させる設定を追加。
・エンコ前後バッチ処理を最小化で実行する設定を追加。
その他の設定から。
・タイマー精度を向上させる設定
これはスレの方にあった話。具体的にはtimeBeginPeriod(1)によってタイマー精度を向上させると、高速化するという。とりあえず、その他の設定の「エンコ中、タイマー精度を向上させる」にチェックを入れておくと、エンコ開始時にtimeBeginPeriod(1)、エンコ終了後timeEndPeriod(1)するようにした。
このtimeBeginPeriod、一時期某チューナボードの問題で有名になってたと思う。
メリットとしては、Sleepなどの精度が上がり、必要なときにスレッドがすぐ復帰するようになること。
一方、デメリットとしてはtimeBeginPeriodがOS全体に作用するため、スレッド切り替えが増え、そのオーバーヘッドが増大すること。OSは大量のスレッドをバックグラウンドで動かしているため、その切り替えが大量に発生すれば、そのコストが…ということだ。ほかには消費電力が増えるらしいけど、そんなことははぶっちゃけどうでもいい。あとはタイマー精度が悪いことを期待しているプログラムとかに影響が出るかも…ぐらいかな。まあそんなのないか。
メリットの効果がデメリットの効果を上回れば高速化すると思う。多くの場合、QSVEnc実行中はCPU使用率は低めなので、デメリットが強く出ることはないと思う。
ちなみにわたしの環境ではなにも変わらなかったが、もうすでにtimeBeginPeriod(1)がどこかで使われているのかな?
・実験1 シーンチェンジ検出によるキーフレーム挿入
※ここでいうキーフレームはH.264のIDRフレームのこと。
QSVへの入力がプログレッシブの時専用。
以前話したように、Intel Media SDKにはキーフレームを自動で挿入する機能が付いている…はずなのだが、これがハードウェアエンコード(QSV)では動作しない、そしてその見込もない、という残念なことになっていて、そのため、GOP構造は常に固定である。
一方、Intel Media SDKには、「指定した任意のフレームをキーフレームにする機能(API)」が用意されている。しかし、当然ではあるがこれはどこをキーフレームにするかはこちらで指定してやらないといけない。そこで、自前でシーンチェンジ検出を行って、シーンチェンジだと推定できたら、そのフレームをキーフレームに指定するような機能を追加した。
一般的にはシーンチェンジの際にキーフレームを投入すると、画質が向上する、と言われている。まあ画質の悪い静止画動画なんかで、シーンチェンジの際にキーフレームをちゃんと入れてやらないと、微妙にボケたり、ひどいときにはゴミが残ったりすることからもわかると思う。
実際やってみると、エンコする動画にもよるけど、わずかに画質が向上し、わずかに圧縮率が向上することが多い。
ただ、どうしても速度が落ちる。まあ、いままでやってなかった計算を追加するわけだし、あとはまだコードも悪いのかもしれないし。最初適当に書いたら150fps近かったエンコ速度が15fpsぐらいまで落ちて途方に暮れたりした。さすがにこれだと遅すぎて使えないので、SIMD化・分割並列化・パイプライン並列化などを使って速度上げたけど、それでもまだ5%ぐらい遅くなる。
検出方法も相当適当なんで、ひかえめに入れているはず。なので検出漏れとか、誤爆してるところとかもあるけど…「まあまあ」「そこそこ」な精度だと思う。
・実験2 可変QPモードの追加
QSVへの入力がプログレッシブの時専用。
どう可変にするかというと、CQPをベースに、ややCBRよりに近づける感じ。CQPだとレート変動が激しすぎるので、それを若干抑えこんだようなモードがあってもいいかな、ということ。
動きの激しいところはもともと画像が破綻している場合がある。そんなところを生真面目にエンコードしてもしょうがないかな…ということで、この可変QPモードはそういうもともと汚いところからビットレートを少し取り上げて、動きの少ないところへビットレートを配分する。なので、CQPと比べるとあまり動かないところの画質がやや向上して、動きの激しい部分の画質がやや低下する。
具体的には、CQPモードでこんなかんじの動画を、
VQPではこんなかんじのビットレート配分にする。
Intel Media SDKに「フレームごとにQP値を指定する」機能(API)があるので、それを使ってPフレームとBフレームのQP値を上下することで調整している。調整の量はエンコ速度優先なこともあり、わりと適当に決めている。
・自動フィールドシフト使用時に不安定だった問題を修正。
たまに不安定になっていた原因と思うものをひとつ発見し、修正。なんか不安定…だった方いたら申し訳なかったです。
・エンコ前後バッチ処理を最小化で実行する設定を追加。
その他の設定から。x264guiEx 1.68の追加機能の反映。
お願い: 保存したQSVEncの設定をロードする際に、データ保持の関係上、シーンチェンジ検出にチェックが入ってしまう場合があります。もし不要な場合にはチェックを外すようお願いします。
QSVEnc ダウンロード>>
※v2はシーンチェンジ検出時、中断できない問題の修正です。
[共通]
・実験1 シーンチェンジ検出によるIフレーム挿入機能を追加。
・実験2 可変QPモードを追加。
両方とも入力がプログレッシブ(非インタレ)の時のみ有効。
・エンコード後、フレームタイプごとの総サイズを表示。
[QSVEnc]
・自動フィールドシフト使用時に不安定だった問題を修正。
・その他の設定にタイマー精度を向上させる設定を追加。
・エンコ前後バッチ処理を最小化で実行する設定を追加。
その他の設定から。
・タイマー精度を向上させる設定
これはスレの方にあった話。具体的にはtimeBeginPeriod(1)によってタイマー精度を向上させると、高速化するという。とりあえず、その他の設定の「エンコ中、タイマー精度を向上させる」にチェックを入れておくと、エンコ開始時にtimeBeginPeriod(1)、エンコ終了後timeEndPeriod(1)するようにした。
このtimeBeginPeriod、一時期某チューナボードの問題で有名になってたと思う。
メリットとしては、Sleepなどの精度が上がり、必要なときにスレッドがすぐ復帰するようになること。
一方、デメリットとしてはtimeBeginPeriodがOS全体に作用するため、スレッド切り替えが増え、そのオーバーヘッドが増大すること。OSは大量のスレッドをバックグラウンドで動かしているため、その切り替えが大量に発生すれば、そのコストが…ということだ。ほかには消費電力が増えるらしいけど、そんなことははぶっちゃけどうでもいい。あとはタイマー精度が悪いことを期待しているプログラムとかに影響が出るかも…ぐらいかな。まあそんなのないか。
メリットの効果がデメリットの効果を上回れば高速化すると思う。多くの場合、QSVEnc実行中はCPU使用率は低めなので、デメリットが強く出ることはないと思う。
ちなみにわたしの環境ではなにも変わらなかったが、もうすでにtimeBeginPeriod(1)がどこかで使われているのかな?
・実験1 シーンチェンジ検出によるキーフレーム挿入
※ここでいうキーフレームはH.264のIDRフレームのこと。
QSVへの入力がプログレッシブの時専用。
以前話したように、Intel Media SDKにはキーフレームを自動で挿入する機能が付いている…はずなのだが、これがハードウェアエンコード(QSV)では動作しない、そしてその見込もない、という残念なことになっていて、そのため、GOP構造は常に固定である。
一方、Intel Media SDKには、「指定した任意のフレームをキーフレームにする機能(API)」が用意されている。しかし、当然ではあるがこれはどこをキーフレームにするかはこちらで指定してやらないといけない。そこで、自前でシーンチェンジ検出を行って、シーンチェンジだと推定できたら、そのフレームをキーフレームに指定するような機能を追加した。
一般的にはシーンチェンジの際にキーフレームを投入すると、画質が向上する、と言われている。まあ画質の悪い静止画動画なんかで、シーンチェンジの際にキーフレームをちゃんと入れてやらないと、微妙にボケたり、ひどいときにはゴミが残ったりすることからもわかると思う。
実際やってみると、エンコする動画にもよるけど、わずかに画質が向上し、わずかに圧縮率が向上することが多い。
ただ、どうしても速度が落ちる。まあ、いままでやってなかった計算を追加するわけだし、あとはまだコードも悪いのかもしれないし。最初適当に書いたら150fps近かったエンコ速度が15fpsぐらいまで落ちて途方に暮れたりした。さすがにこれだと遅すぎて使えないので、SIMD化・分割並列化・パイプライン並列化などを使って速度上げたけど、それでもまだ5%ぐらい遅くなる。
検出方法も相当適当なんで、ひかえめに入れているはず。なので検出漏れとか、誤爆してるところとかもあるけど…「まあまあ」「そこそこ」な精度だと思う。
・実験2 可変QPモードの追加
QSVへの入力がプログレッシブの時専用。
どう可変にするかというと、CQPをベースに、ややCBRよりに近づける感じ。CQPだとレート変動が激しすぎるので、それを若干抑えこんだようなモードがあってもいいかな、ということ。
動きの激しいところはもともと画像が破綻している場合がある。そんなところを生真面目にエンコードしてもしょうがないかな…ということで、この可変QPモードはそういうもともと汚いところからビットレートを少し取り上げて、動きの少ないところへビットレートを配分する。なので、CQPと比べるとあまり動かないところの画質がやや向上して、動きの激しい部分の画質がやや低下する。
具体的には、CQPモードでこんなかんじの動画を、
VQPではこんなかんじのビットレート配分にする。
Intel Media SDKに「フレームごとにQP値を指定する」機能(API)があるので、それを使ってPフレームとBフレームのQP値を上下することで調整している。調整の量はエンコ速度優先なこともあり、わりと適当に決めている。
・自動フィールドシフト使用時に不安定だった問題を修正。
たまに不安定になっていた原因と思うものをひとつ発見し、修正。なんか不安定…だった方いたら申し訳なかったです。
・エンコ前後バッチ処理を最小化で実行する設定を追加。
その他の設定から。x264guiEx 1.68の追加機能の反映。
お願い: 保存したQSVEncの設定をロードする際に、データ保持の関係上、シーンチェンジ検出にチェックが入ってしまう場合があります。もし不要な場合にはチェックを外すようお願いします。
QSVEnc ダウンロード>>
※v2はシーンチェンジ検出時、中断できない問題の修正です。
スポンサーサイト
