【エンコード日記】わさｂ盛りベスト品位なGOP構造とは‥

↓5)記稿.2024/06/13

＞　先に結論を述べてしまうと
＞　爆Ｑ用途に、ｂフレームは再び要らない子に出戻りましたん（あれ〜）


　‥前回のレシピをCRF（０）にして、わさｂ有り無しを比較した所
　画質保持とした際のAVCでの圧縮減の率は、２２％前後程度らしい（今回のテーマ）
　そして、わさｂ盛りとした際の時間コストは倍に及ぶのだ（悩ましい）


　‥さらに悩ましいのは、量子化済みソースに対して、わさｂ盛り2passエンコードを頑張っても
　わさb抜きから11.25％減‥に落とせる程度にあることだ（艶品位画質の保持）
　（時間コストも馬鹿にならねぇし、旨味が薄いｚ）

　‥その際の艶品位と言っても、高品位に出来上がっているとは限らない
　（ビットレートの手抜きなどあり得ないとした台所事情を抱え込んである）

　GOP構造の選択をケチろうものなら、動いて見えるべき箇所で動いて見えざる場合も起こりうる
　それはそれで目の錯覚ありき特殊ケースなのだが、動画エンコードにおいてとても重要な見方だ

　　（‥局所瞬時なマクロブロック間での‥ビットレート割り当ての厚みもしくはQP均一性が重要）
　　（ということで、QP均一性とした特徴に顕著なのがCRFエンコードになっている）
　　（‥その際、爆Ｑ構造のままにCRF値を下げては、増量しすぎるのだから）
　　（そちら都合は2passエンコードとした見方になる）


＞　まずはそんなこんなのGOP内部理解をしてまいりましょう

1-5)1

　‥同じ画が続いているようでいても、マクロブロックとした差では、全くの別物だったりとする
　静止画確認では動いては見えれども
　動画確認すると、どうにも動いていないように見えてしまうとしたオチをやらかしかねないのが
　マクロブロック間での動き印象とした厚み不足なのだぁあああ（光×フェード表現などでの不良）

　　‥ｂよりｐの方が、ｐよりＩの方が印象が強くなる（印象の強い方に掻き消されるみたいな）
　　量子化前ソースなら、全体の粒が揃っているのだから、Ｉもｐもｂもクソも関係ねぇ
　　非量子状態にて粒が揃っているなら、どこと組み合わせたって誤差は無いとして良い

　　ところが、量子化済みソースともなると
　　それはすでに劣化した状態なのだから、勝手都合で丸めようとしてもうまく行くことは少ない
　　それこそが、YUV４２０とした内部事情なのだ

　　量子化済みの近似を、設定勢いにて更に丸めては、動きとしての見映えが変わってしまうのだ
　　だからといって、量子化前の設定を踏襲しても用を満たさない（ここ重要）


　‥最も悩ましきは
　再エンコードする際のＩ，ｐ，ｂ間でのマクロブロックサイズの不一致とした影響だ
　ｂフレームが４×４サイズを使えず、８×８止まりなので、創意工夫が欠かせない

　　そもそもの圧縮の際に、似たマクロブロック同士をすり合わせるのだが
　　あちらでもこちらでも、無味に、すり合わせを重ねやらかしては、元の形が不明になりがちだ
　　量子化前と後ではそこが徹底的に違うのだ


＞　なので、量子化前ソースの適合都合と、量子化済みソースとの適合都合は、解釈が大きく異なる
＞　そこの辺りをイメージできていないのでは、次に進むこと能わず

1-5)2

＞　まず、適切な先読み値をどれぐらいにするべきだろうか？
＞　先に結論を述べてしまうと、わさｂ盛りの際には
＞　フレームレート（23.976）でも、先読み（999）で適切らしい


　１÷２４＝0.041666666‥
　999÷0.041666666‥＝23.976（１枚単位の端数誤差が９９９枚で割り切れる勘定になるっぽ）


＞　では、GOP長は、如何ほどに伸ばすのが程良いのだろうか？


　‥GOP長を伸ばしやらかしても良いことは無い
　なぜなら、フレームレートを超えてGOP長を指定すると参照フレームMixが仇になる

　離れすぎたマクロブロックの再利用が、遅延をもたらし、それとした再生を不良と化する
　編集上問題なさげでも、もはや壊れているレベルだ（是は避けたい）

　只でさえGOP長が、フレームレートと同じに被っていると、その都度、フレーム遅延地雷と化する

　と言うことからも、フレームレートを超えたGOP長の指定は避けたいのだが
　ｂフレームを用いて再エンコードを試みるなら、その許容となる蘊蓄を知っておくべきでもある


　１÷２４＝0.041666666‥
　１÷６０＝0.016666666‥

　単純に是の差は2.5倍なのだから、５の倍数が良さげに見える
　すると、５０、６０、１００、１２０、１５０、１８０、２００枚としたGOP長が良さげに見える

　なので、CRF（０）にて、わさｂ抜きとわさｂ盛りとの比較をして
　複雑怪奇なソースにて、劣化差の無くなる枚数が都合に思われる
　　（それにしてもシークが効かなくなるのは苦痛でしょうがないのだが、ヤムナシだろう）

　　‥併せて、参照フレームMixとｂピラミッドの効果も組み替えて調べると
　　ちんまりとした効果の追加と、トラブル含みとした隣り合わせとを較べ鑑みるに
　　双方ともに切ってしまっても差し支えないのだから悶絶ものである（え、そんなもんなの？）


　　‥だったら‥｛2pass×わさb抜き×参照フレームMix｝でしょうと思わざるを得ず


＞　ちなみに、今から論説するGOP構成では
＞　フレームレート（23.976）では、GOP長（１２０）以上
＞　フレームレート（59.94）では、GOP長（２００）以上が良いらしい
＞　※　FHDサイズでは未確認（時間コストパネェ）


　‥と言っても、CRF（０）比較だから、値を上げた時の効果の程は黙殺だろうｚ
　‥と言っても、CRF（０）の際に効果なきGOP長なんざ‥可能性に乏しすぎでクソっ‥みたいな
　（今回は説得力高すぎて困ゆぅうう）

1-5)3

＞　それでは、ｂフレームを用いた際の決定的な間引きと為せる形を考えてみよう


　‥例えば、黒像地帯の圧縮だ
　どんなにｂフレームとした数を割り当てても、最大値が盛られる率は低い
　どうにも（−１）とした取り扱いに見舞われるだろう
　とはいえ、ＧＯＰ長（２３）としたスタンダードで解釈するならその理想を
　Ｉbbb bbb bbb bｐbbb bbb bbb bｐ‥と想像する所だが

　（実際には、そのままに続くのは稀で、GOP長が１枚２枚と減りながら連続していく感じか‥）

　‥また、連続したｐフレームの後に、黒像地帯がくっついてｂばかりが並ぶとしたら
　Ｉppp ppp ppp pp bbb bbb bbb bbｐ‥と想像できる

　（黒像のｂはすべて、後方の黒像ｐを参照すれば済む、わざわざ切り離してＩを振る意味も無し）


＞　ゆえに、ｂフレーム（１２）×ｒｅｆ（１２）とした姿にならざるを得ず
＞　つまり、｛GOP長：ｂフレーム長：ref｝＝｛１：半分：半分｝こそが理想にならん


　‥すると、今まで悩んでいたのは、なんだったのかと思えるぐらいに整って見えてしまうのだ
　（ビットレートを足すことでの違いも推し量りやすくなっている）
　（そりゃまぁほとんど限界エンコードだもんなぁ‥そうで無ければ困るｚ‥）

　　　‥ちなみに、2passエンコードにて、ref（１６）を久しぶりに試したら
　　　AMDドライバーが、またもやエラーを吐いて、セーフモードに移行せり（ちゃんちゃん）

1-5)4

＞　では、他はどうだろうか？
＞　とくに光表現での動きに差が出やすい、Ｐフレーム予測の重みの１と２のどちらが良いのか？


　‥まず、Ｉ４×４を効かすには、Ｐフレーム予測の重み（ブラインドオフセット）が必要だ
　すると、ＹＵＶのＹのマクロブロックを小さく扱えることからも品質が上がったように見える草

　だがしかし、ビットレートの割り当てやら構成に平滑性が伴わないようだと、効果を伴わず
　　‥単にＩ４×４がスタンダードだからと言うだけでなしに
　　ビットレートの盛り合わせ加減こそが、味噌になっている


＞　なのだから、再エンコードの際に、Ｉ４×４を踏襲するのは罠と言ってもいい


　Ｉ４×４にて、手頃に見映えだすことで、動きとした厚みを見失いやすいどえむ
　（日用エンコ側は、マスターソース映像を知らんのだから、これで良しとする端境判断が不能だ）

　その最たる要因こそ、ｂ８×８までとしたマクロブロックサイズの不一致だ
　ソース毎に適合を違えざるを得ず判断をすべきであり、扱い方に悩ましい

　　（繰り返すが、粒の揃った量子化前ソースの段階なら、其を気にする必要はほとんど無い）
　　（気にするべきは、いつＹＵＶ４４４に切り替えるべきか‥とした編集ノウハウぐらいだろう）


　‥ｐ４×４を効かせたいにせよ、受け渡しマクロブロックサイズの一致は手厳しい
　それこそ中途なビットレート割り当てでは、光表現に持って行かれるとした斑になる
　なので、ｐ４×４を用いるなら、ビットレート割り当てをケチっては駄目なのだ


　‥そこで４×４利用を避けつつ、エンコード品質を上げたい場合には
　M.E.範囲（４）がオススメだ
　スキャンする手間だけで、潰れてしまいガチな動きの改善を図ることが可能だ
　　（‥ソースに依っては無残にも、時間コスト期待を裏切られる所だが）
　　（M.E.範囲（８）よりは、ずっと品質が上がるのだ）

　とはいえ、その分の割り当てに耐えうる
　受け皿としての適切なビットレート量が欠かせない
　　（結局の所、細かい動きの辻褄を気にするほどに、削れる量など高が知れている）
　　（ガッツリ削り落としたければ、動きの劣化に目を瞑らざるを得ず）


＞　フレームレート（59.94）とした選択も動き重視だ
＞　（それはそれで、クソ時間の掛かる話ばかりでどうしようもねぇ）

1-5)5

＞　では、今回のｂフレーム調整のまとめをしておこう
＞　（ここでの対象は、プログレッシブソースのみ）


レート調整モード：品質
品質：０.0‥（圧縮率度合い確認用）
プロファイル：Ｈｉ１０
レベル：Level５.1
フレームレート：５９.94　；　２３.976
キーフレーム間隔：２００　；　１２０‥（圧縮率は‥１１；１０ぐらい？‥９％差？）

※　FHDサイズでは未確認（時間コストパネェ）


適応型DCT：オン
I8x8：オン
I4x4：□
P8x8：オン
P4x4：□
B8x8：オン‥（忘れずに）

Ｂ-フレーム数：１５
Ｂ-フレームモード：なし
適応型Ｂ-フレーム：最適
Ｂ-Pyramid：なし
Ｂ-予測ウェイト：オン
Ｂ-フレームバイアス：２５‥（要、シーン変更感度（８９））

先読み：９９９‥（忘れずに）
Syne Lockahead：９９９‥（忘れずに）

M.E.範囲：４
シーン変更感度：８９
M.E アルゴリズム：SATD Exhaustive Search
サブピクセルリファイン：10 -ＱＰ-ＲＤ
Chroma M.E.：オン
P-フレーム予測の重み：ブラインドオフセット‥（ｉ解除ソースの際にはスマート解析？）

Trellis：常時
Psy-Trellis強度：１.００（スマート解析の際に、適応するのかはまだよくわからない）
Psy-RD強度：１.００

参照フレーム数：１５‥（お間違いなく）
参照フレームMix：□‥（お間違いなく）


ビデオ形式：指定なし
カラー優先度：BT.709‥（SDサイズへのダウンコンの際は指定無し）
行列係数　　：BT.709‥（SDサイズへのダウンコンの際は指定無し）
伝送特性　　：BT.709‥（SDサイズへのダウンコンの際は指定無し）


※　SDサイズからSDサイズに変換する際と
　　SDサイズからBT.709サイズにアプコンする際についてはまだ未確認


＞　SDサイズへのダウンコンCRF（0）が、問答無用で綺麗すぎゆぅううう
＞　（動画原画とした動きの勉強するなら、CRF（0）×わさb抜きでもええやろう‥みたいな）