【エンコード日記】マクロブロック全正方形化における弱点

記稿.2022/01/25

＞　マクロブロック全正方形化とは
＞　BDtsソース映像をシークバー移動させる際に、顕わになる正方形乱れのように
＞　長方形パターンが現れない理想的なエンコード状態を指す


　‥一般に、エンコードの理論上、長方形パターンのマクロブロックも使用される
　だが、ドット画の延長として論ずると、正方形パターンで固まっている方が美麗だ

　（ＩフレームからＢフレームへと格子パターンを明け渡すにも無理が無く理想的だ）
　（明度とした観点からも、白黒でのトーンが、各々に異なっていて綺麗な印象の想定だ）
　（それのイメージに見せられるのも、タイル画に慣れ親しんできた遺伝子ゆえだろう）

　だが、普通に動画エンコードしてもそうにはならない
　そうする上での調整が欠かせないのだった


＞　ダウンコンバートの際のそれの調整法に辿り着いて知り得たのは
＞　BDtsソースにも稀に見られる‥32×32ぐらいの正方形での単色ブロック発生の理屈だった


　（いやいやいや、それは64×64かも知れない、表現上32×32としておく）

　単純に動かない映像ならそれは目立たない
　だが、激しく動いているほどそいつは目立つ
　演算の果てに起こりえた偶然とした大正方形ブロックの発生は
　全体の圧縮がギリギリであったなら、もはや調整が付かずそのままにせざるを得ない


＞　例：アニメ「A.I.C.O. Incarnation」OP


　‥OPの冒頭シーンにおいて、光の波が中央から押し寄せてくる演出があるのだが
　その中になぜか、明らかに単色ブロックと化した一つのブロックが押し流されてくる（左上部）

　（つまり、全体が正方形でしか表現されない演算値の場合）
　（奇遇にも隣り合う四隅同士が同じ色で表現された場合には避けられない結果になる）
　（それでなくても、ＢＤの圧縮を稼ぐのにそれの確率を高めてしまう技術がある）

　（それが、Ｂフレームモードの空間軸×参照フレームMixだ）
　（つまり、Ｂフレームモードの時間軸とは、それを緩和させる上での打開案だったかも‥）
　（だが時間軸は、ＧＯＰやＢフレーム枚数が長くなるほどに副作用ですり込み残像をやらかす）


　※　ちなみに、このソースは、BDにも関わらずGOPを三枚で構成してあったりするので
　ビットレート不足かと思っていたのだが、それを否定する別のソースを発見した


＞　例：アニメ化物語OP「帰り道」


　‥このOPの中途に、八九寺 真宵が傘をさして歩いているところに
　雨雲が切れて光が射すのを見上げるカットがあるのだが（真横アングル）

　その場面の右上全体で、どうにも
　32×32のブロックの単色とした塊が群れをなしていたことが判明

　普通にエンコードしているだけではよく分からなかったのだが
　正方形化になるように調整を得た途端に

　ソースの状態を踏襲し、576ｐとした解像度ゆえに
　32×32としたマクロブロックがデカデカと目立ち
　それが、雲間から光が射すとした演出上
　カクカクとしたフェード調に動いてくれちゃってるのだ

　（どのように調整しようとも如何ともし難く‥なんというジレンマ‥）
　（Ｂフレームモードを切ってあるのにこの始末だよ）
　（だが、サクッと再生支援機能を用いた再生をすると許容の範囲に落ち着く）
　（テレビUSB挿しだと、もうちょっと綺麗めに調整されて、気にする程には無いらしい）


　‥つまり、今までの実験エンコードでは、単色の幅がより大きく拡がっただけで
　動かないレベルになっていただけだった可能性が高い（ほへ〜）


　※　ちなみにこのソースは、ref（2）であるので
　ref（4）にする際の参照が変わるので、動きとしてのそれがより誇張されてしまうのだろう
　だが、ref（2）でやろうと、ref（3）でやろうと、改善することは無いのだった
　ぶっちゃけ、ref（4）が一番に無難に見える


＞　ということが起こり得るのが、マクロブロック全正方形化による弱点ということである