2018年04月15日

【エンコードレシピ】満足の境は「CRF16.5」だった

↓2)記稿.2018/04/15

 ‥AviUtl備え付けの
 ノイズ除去フィルタ2種類やら、シャープやらを使ってみても
 得られるQP値変化は±0.2の範囲にすぎない
 CRF16.6を基準に、あれこれエンコードして気がついたのは、
 QP値があと−0.2ほど全体に波及すれば、十分に満足できるだろう辻褄だった‥そこで

 CRF16.5に変更したところ、すんなり納得できた
 (余計なフィルタは不用だった‥エンコード設定からして限界攻めてるし‥)


 ‥ただしこれは
 720x540(23.976 fps)での話である

 ※ ここでは主に‥MP4ファイルをUSBメモリー×テレビで美麗に視聴することを目的とする

   ‥手持ちのテレビは、最新のHEVC対応には無いので、USB2.0が前提になる
   USB2.0の帯域では、秒間毎のエンコード最大ビットレートに注意せざるを得ない
   よって、選択支は
   960x540,720x540のサイズが適当に思われる


> ↓が「スマートCRF16.5」レシピである


SmartCRF16.5_Recipe01.png

SmartCRF16.5_Recipe02.png

SmartCRF16.5_Recipe03.png

SmartCRF16.5_Recipe04.png



1-2)1

> レート制御先行探査フレーム数: 48
> シーンカット閾値: 100
> 動き探査範囲: 64
> 最大QP変動幅: 3


 ‥やり過ぎ感漂う↑の設定は
 Bicubic Spline(ビデオスケーラ)を用いた場合の能力に適った値である(必須)
 おそろしいほどにBilinearやらBicubicとはモノが違う

 さらに

 L-SMASH Works(AviUtlのプラグイン)では
 内部で各16ビット深度処理をしているような表記がされている
 (よく分からんが10ビット深度どころの話では無い‥RGB24ビット処理ならこちらだ)


■レート制御先行探査フレーム数48
 秒間24フレームの扱いなら2秒間というのが良いようだ
 (よって、秒間30フレームの扱いなら60と言うことになるだろうか‥)

 * エンコード時の処理の段取りとして
   システム設定のキャッシュフレーム数の方も見落とさずに合わせておきたい
  (秒間60フレームの再生も兼ねて、60固定で良いと思う)


■シーンカット閾値100
 ‥これにはビックリだろう
 ここでのIフレーム数増大の心配は、CRFの数値に反比例する
 つまり、CRFで割り当てる容量を増やすと、それに乗じてIフレームが増大する
 だから、CRF値が同じままなら、知れたパターンの映像は想定内にしか増加しない

 それよりも見逃せないのは

 シーンカット閾値100には
 2PASS並にビットレート割り当てを最適化してしまう効果を得る点である
 ゆえに、Iフレームだろうと100枚枠の増分ぐらいなら相殺してしまうようだ‥
 又
 GOPを用いて容量が肥大化することと比べれば、気にせずサーチポイントを増やすことができる
 テレビでの再生が前提なら、サーチポイントを適正に増やせる点はおいしい


■動き探査範囲64 × 最大QP変動幅3
 ‥これが一番にやり過ぎ感漂うところだが
 おそろしいほどに輪郭が極まる

 (最大QP変動幅3とのセットが良いように思うが、細かくは調べていない)

 ちなみに最大QP変動幅3は、視覚心理最適化あたりをいじると
 最大QP変動幅4と比べて、隙間が生じるのか、変化の異常がはっきり出やすい傾向にある



1-2)2

> テレビ再生時に気になるのは負荷である
> 録画機能を備えていれば、それなりの負荷には耐えるだろうが
> USBメモリー側の処理チップ類の発熱を考慮せざるを得ない


 ‥そこで、負荷を下げるためのポイントが
 「参照距離」×「Bフレームの連続数」×「重み付け」である

 テレビで「早送り×巻き戻し」をヌルヌルやるには、クローズGOPでのエンコードが優位になる
 しかし、ファイル容量の肥大化との引き替えである
 2パスエンコードも悪くないが、どちら共に画質との引き替えである

 だから

 GOPに無い状態でも、如何にサーチしやすい構造にしておくかが欠かせない
 一番にサーチの障害になってくるのが重み付けである(サブピクセル動き予測の選択の必須条件に絡む)


 ‥重み付けの処理を、さらに鈍重にするのが
 「参照距離」×「Bフレームの連続数」の肥大化である


 ぶちゃけ、IB、PB、PPの3パターンで演算させた方が処理が速い
 人間の頭で大ざっぱに最適を分別するにしても、3つなら早く事を進められるが
 10、20のパターンへの適宜分けなど負荷そのものだ


> 参照距離: 3
> 最大連続Bフレーム数: 1


 ‥数が不釣り合いに見えるが問題ない
 エンコードファイルの再エンコード時にでやすい青色のブロックノイズを抑止する効果として
 参照距離を+1して増やしておくのが効果的にある

 その分の負荷はもちろん重み付けに反映されるにせよ
 IB、PB、PPの3パターンにしかないならそれ以上にはならない

 それよりも

 Pフレームの肥大化とシーンカット閾値100との組み合わせが
 うまい具合に、参照用途のIフレームを誘発する傾向にもあるらしい
 (サーチポイントを増やしておきたい狙いには好都合だ)


 ‥そして、一番にうれしいのが
 サーチが早い=エンコードも軽い=エンコード時間短縮である


 ※ 「参照距離×Bフレーム数」でファイル容量を縮めようなんて常識は
   サブピクセル動き予測の選択を下げてやらざるを得ないエンコード条件下での内容で
   視聴画質重視にも適宜に重厚エンコードを許すなら、お門違いの認識だった

  (‥再生負荷軽減を忘れて良いなら、Bピラミッドも捨てがたい処もあるが‥)
posted by 木田舎滝ゆる里 at 11:21 | Comment(0) | エンコードが始まらない | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。