rigayaの日記兼メモ帳

---

---

上限確認付き品質基準VBR(crf)を選ぶと、まず設定されたcrfでエンコードを行う。


--------------------------------------
[S:\test_crf.mp4]
--------------------------------------
auo [info]: converting YUY2 -> nv12p, using SSE2
auo [info]: x264 options...
--preset slow --crf 26 ～(中略)～ -o "S:\test_crf.mp4" "-"
auo [info]: NeroAacEnc で音声エンコードを行います。
　 　　　　 AAC-LC ビットレート指定, 128kbps, 2pass


で、crfでのエンコードが終わると、上限を確認する。上限ファイルサイズ100MBと設定したとすると、100MB以内に収まっていれば、


auo [info]: 出力ファイルサイズ 89.45 MB,
　 　　　　 ファイルビットレート 1389.34 kbps
auo [info]: 指定された上限を下回っていることを確認しました。
auo [info]: 総エンコード時間 : 0時間 3分35.7秒


と出て、終了。

---

もう少しcrfを下げ、画質をあげようとしてみると、そのままでは100MBをオーバーしてしまう。


--------------------------------------
[S:\test_crf2.mp4]
--------------------------------------
auo [info]: converting YUY2 -> nv12p, using SSE2
auo [info]: x264 options...
--preset slow --crf 25.5 ～(中略)～ -o "S:\test_crf2.mp4" "-"
auo [info]: NeroAacEnc で音声エンコードを行います。
　　 　　　 AAC-LC ビットレート指定, 128kbps, 2pass

～(中略)～

auo [warning]: 出力ファイルサイズ 102.61 MB,
　　　　 　　　 ファイルビットレート 1593.72 kbps
auo [warning]: 上限ファイルサイズ 100.00 MB を上回ってしまいました。

で、こんなかんじでcrfでのエンコードが終わって、上限を上回ってしまった場合は、自動的に自動マルチパスモードに移行する。目標ビットレートは上限設定から自動的に計算。

--------------------------------------
[S:\test_crf2.mp4] (1 / 2 pass)
--------------------------------------
auo [warning]: 目標ビットレートを 1423 kbpsに設定します。
auo [info]: converting YUY2 -> nv12p, using SSE2
auo [info]: x264 options...
--preset slow --bitrate 1423 --pass 1 --stats "S:\test_crf2.stats"
～(中略)～ -o "nul" "-"

～(中略)～

--------------------------------------
[S:\test_crf2.mp4] (2 / 2 pass)
--------------------------------------
auo [info]: converting YUY2 -> nv12p, using SSE2
auo [info]: x264 options...
--preset slow --bitrate 1423 --pass 3 --stats "S:\test_crf2.stats" ～(中略)～ -o "S:\test_crf2.mp4" "-"

～(中略)～

auo [info]: 出力ファイルサイズ 99.72 MB,
　 　　　　 ファイルビットレート 1548.91 kbps
auo [info]: 指定された上限を下回っていることを確認しました。
auo [info]: 総エンコード時間 : 0時間 7分44.1秒


ここまで行けば終了。


この流れは、図にすると



こんな感じ。

---

x264guiEx 1.70では、音声によるビットレート再調整も行えるようにしたけど、上限確認付き品質基準VBR(crf)で上限をオーバーする場合はたいてい上限を大幅に上回ってしまう。そのため、音声での再調整はできずに上に書いたような自動マルチパスを使った再調整になると思う。

(音声のビットレートはそもそも小さいことが多く、音声側による調整には限界がある。)

ニコ動プレミアム用の動画を作る場合、現在上限は100MB。3分とかの短い動画ならcrfでオーバーすることはほとんどなく、crfでぱぱっとやってしまうのがいいんじゃないかなと思う。

プリセットの方は6分以内のほうを「上限確認付き品質基準VBR(crf)」、6分以上を「自動マルチパス」で作ってあるけど…まあエンコ対象によって結構違うので、6分というのはおおまかな値。

---

自動マルチパス関係の拡張

---

自動マルチパス関係の機能をさらに拡張して、便利になればいいな…という。以前から自分で考えていたものとか、要望としてもらっていたものとかの実装。


上限確認付 品質基準VBRモード(crf)を追加。

このモードは、まず品質基準(crf)でエンコードを行った後、設定した上限を上回っていないか確認する。

もし、上限を上回っていたら、マルチパスビットレート指定で自動的に再エンコードを行う。

使う場合は、設定画面の…




「上限確認付き品質基準VBR」を選択して、ファイルサイズ・ビットレートの上限値を設定。



・上限確認で、音声再エンコードによるビットレート調整。

細かく書くと、上限確認で、オーバーした容量がある一定以下の時、音声エンコをビットレート指定モードで行なっていたら、音声再エンコードでビットレートを調整できるようにした。

普通、音声エンコのほうが時間がかからないので、効率的かなと。


・自動マルチパスの余裕のデフォルトを10→5に。
自動的に目標ビットレートを調整する場合の余裕を少し減らした。やはりぎりぎりを目指したい人も多いようなので。

---

結局どういうこっちゃ?

---

今回の拡張をまとめるとこんな感じ。

これまでは、こんなかんじのが上限確認付き自動マルチパスだった。




x264guiEx 1.70で、
・上限確認付き品質基準VBR
・音声再エンコードによるビットレート調整
を追加して、



こんなかんじに。

ニコ動のプレミアム会員で、短い時間の動画の場合は、この「上限確認付き品質基準VBR」のほうがいいかなあ…ということで、プリセットを作りなおしておいた。

この手の2pass…というか上限が決まっているエンコードはわたし自身はほとんどしないのだけど、使いやすくなってればいいな…と思う。

---

ダウンロード>>

x264guiExの導入>

---

---

---

今回の修正・変更点について

---

インタレ保持エンコード時に周期的に破綻するフレームが出たのは、0.15以降GOP周りのオプションの取り扱いを微妙に変えたためだったようで、0.17ではそのへんを回避するようにした。

具体的にどんな感じで壊れるか、というサンプル動画。

QSVEnc 0.15
720x480i, 品質　quality, インタレ保持
CQP, 連続Bフレーム数 2, GOP長 30

サンプル動画 ダウンロード>>

これはIntel Media SDKで、インタレ保持とMFX_GOP_STRICT(Intel Media SDKにあるオプション)を同時に指定すると発生する。

根本的には、Intel Media SDK側のパラメータの食い合せの問題で、ドライバで何とかなってくれるといいのだけど、MFX_GOP_STRICTを指定する必要性はないので、0.17以降はMFX_GOP_STRICTを使わないようにした。

---

あと、シーンチェンジ検出・可変QP調整計算を高速化。具体的にはフレームスキャンを行う際のメモリからのロードに _mm_stream_load_si128 (movntdqa, SSE4.1)を使用することでだいぶ速くなった。これで、このへんのオプションを使用してもさほどエンコ速度に影響しなくなってきていると思う。

---

シーンチェンジ検出・VQPについてもうちょっと

---

シーンチェンジ検出はそこそこ安定して効果があると思う。例えばCQP 20:23:25でシーンチェンジ検出をすると、Iフレームが増える一方で容量は0～2%ぐらい縮むことが多い。画質もわずかに向上、特にアニメ等では有効かなと思う。

VQPは、IフレームのQPは設定値そのままで、PフレームとBフレームのQPを設定されたQP値から -2～+8ぐらいの範囲で調整している。静止画っぽいところではQPを下げ、大きく動いているらしいところではQPを上げて、ビットレート配分を変更している。動き部分での画質は確実に悪化するので、それが気になる人はやはりCQP推奨。

動画全体の容量は、多くの場合減少するけど、静止画ばかりの動画ではずっとQP値を下げ続けることになるので容量が膨れる場合もある。

VQPを使う場合には、シーンチェンジ検出にもチェックを入れてもらえればと。そのほうは画質が良くなると思う。

---

---

・タイマー精度を向上させる設定

これはスレの方にあった話。具体的には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はシーンチェンジ検出時、中断できない問題の修正です。

---