【エンコード日記】Ｂ繰羅の正体を見たり‥其の二

↓3)記稿.2024/07/02

＞　まず、DVDのブロッキング軽減を[有り]とすべきか？、[無し]とすべきか？の件について


　‥結論から言うと
　ブレ無しｉ解除してしまうとしたそれが好影響するのか‥しないのか‥[有り]でＯＫと言える
　それ以前に、オフしても‥deblock=1:0:0‥となり、後からの判定不能にあるようだ‥‥

　‥だがしかし
　DVDとしたデータ量の覚束なさに差は無いのだから、長いGOPを用いるにも
　長いｂフレームを用いるにも同じく無理がでる、それの変わる所無し

　（とくに短めの発光表現を含んでGOPを長くするほどに、それの影響は敏感で潰れやく悩ましい）


＞　このDVDのデータ量とした不都合が毒の如く押し寄せるのが、オープンGOPタイプのソースで
＞　ｂピラミッドを用いた再エンコードの際に
＞　一話一話の端境に、うまい具合にキーが入らずにズレる確率が上昇してしまうのだ


　（※　諸々、GOP構成同じでも８bitと10bitで、キーの入りが微に異なる）
　（なのだから、わさb抜きだとて、焦点を合わせんことにはうまく切れんのだ）


　‥この致命的且つ面倒くさい課題を解決するには
　始めこそ、ビットレート量を増やすとした流れでほぼ対応可能としか考えていなかった
　（※　Psy-Trellis強度を効かしていると、ビットレート量の割り振りが多くなるとキーが増える）

　HDサイズ×フレームレート（59.94）にすりゃ大丈夫ぐらいに高を括っていた‥‥orz

　　‥でも、なんだか知らないうちに
　　ここの駒増数があら１枚多いとか‥BDソースからして従来と同じに60駒増幅されていない草
　　（もしかしたらAVCのバージョンアップ絡みだろうか？）

　　（この問題は、謎で注意しつつ‥より詳しい調査が必要だ‥）


＞　‥とくに注意すべきは口パクである‥


　　セルアニメの時代は、デジタルとは違うのだから口パクのずれは時代色でもあった
　　なので、昭和40年代ものともなれば、多少なりとズレていたりするものだ
　　（BD化する際に手直しするかも知れないが、DVDぐらいだと‥するとは思えね）

　　それが、60駒に自動構成されてまんまなら‥そのズレはもはや許容できね
　　なら、疑わしきは扱わずとして、ｉ解除を30駒固定にしないと面倒くさいことになる‥？？

　　‥だが調べてみると、ブレ無しｉ解除したそれは
　　ソースよりタイムコードが微微に短くなる‥‥
　　（これでは、どのフレームレートを選ぼうと同じだ‥orz）

　　　‥フィールドマッチングして解除せるものすべてがそんな感じくせぇ
　　　（2−3プルダウンとした中身はどこさ行っただぁ？？）
　　　（120駒に並べてから、重要な動きを違和感なく拾って、再構成するアレだろうか？？）

　　‥タイムスタンプの強制をオフにしたって、タイムコードの長さに変化なし
　　だが、ファイル容量に変化有り‥のなんという盲点‥‥orz（もはやオフで十分に‥）


＞　全く以て、想定外な確認し直しが増えていく‥‥
＞　ブレ無しｉ解除30駒と60駒のキーの入り方の差とか‥調査予定に無かったｙ
＞　（もはや、ブレ無しｉ解除24駒は、とても怪しいのだから扱えず）

1-3)1

＞　なんだかんだと‥FHD（16：9）ピクセル化（2×2）は全滅した
＞　比較も進んで目がこなれてくると、実験観察×参考程度だった


　‥HDサイズでのピクセル化（2×2）ともなると
　インターレース櫛とは違う櫛っぽい奴が、以外と邪魔して、感情移入できない程に及ぶ
　致命的なので没にした‥（めちゃ爆速にてエンコードを終える気分とやらを味わったｊ）

　　（まぁ、UHDソースのダウンコンの際にも同じく実験やらかすであろう）
　　（確かに解像度的にはHDサイズの９倍なんだから３×３としたサイズでピッタリに見える）
　　（だが今回の知見を思うに、線ベクトル面ベクトルとした輪郭ベクトル的には違うらしい）
　　（同じぼかすにしても、アプローチが違うらしい）


＞　４：３の塩サイズにこだわる意味は有るだろうか？


　720×528のマクロブロック‥45×33＝1485
　1485＝165×9　｛5100：11475：20400｝←　※正確には1.111111‥倍になっている

　1024×576のマクロブロック‥64×36＝2304
　2304＝256×9　｛5400：12150：21600｝


　1080×792のマクロブロック‥67.5×49.5　→　68×50＝3400
　1280×720のマクロブロック‥80×45＝3600

　5100×2＝10200‥‥｛10200：22950：40800｝←　※こちらも1.111111‥倍
　5400×2＝10800‥‥｛10800：24300：43200｝

　3400÷3600＝0.9444444‥
　5100÷5400＝0.9444444‥

　21600÷2＝10800

　122400÷10800＝11.333333‥
　122400÷10200＝12
　11.333333‥÷12＝0.9444444‥

　‥極めつけは‥3400×3600＝12240000


＞　いつの間にやら、塩サイズとしたヘンテコが、FHDのそれと割り切れる関係になっている？？
＞　だが調べていくと、DVDソースで適ってそうな値を‥BDソースには使えないのだった
＞　（ビットレート足りなさすぎ）

1-3)2

＞　GOP長（６）×ｒｅｆ（４）×ｂフレーム（４）×ｂピラミッドの時
＞　発光発色が抜群に良くなる　且つ　映像の流れがとてもスムーズに見える


　‥ｂピラミッドを指定すると、ｂピラミッドの参照と利用に、それぞれ一枚持って行かれ
　ｒｅｆ（３）×ｂフレーム（３）とした内部構造になるくさい
　（まぁ全部にｂピラミッドの適応を見せる分けでは無いのだから、内部固定値にはならんだろう‥）

　‥とはいえ
　場面の区切れは、特定要素が絡むと曖昧になる（後述）
　どちらかというとＢＤソースの方が判定は良い（ビットレート量次第の所がある）
　一方のＤＶＤソースともなると、場面と場面の区切れの頭と尻尾が繋がりやすい（後述）

　（GOP長＝６なので、基本則で爆Ｑを得るには得るのだが、諸々と悩ましい）


＞　480ｉのアプコンＨＤの際に、ｂピラミッドの発色を活かそうとも
＞　場面の区切れも不十分だし、爆Ｑとしても不十分なところが見られる
＞　だが、ＢＤのダウンコンＨＤともなると、Ｐフレームの参照枚数を増やすより効果が高い


　‥60枚構成とした場合
　24枚からなら2.5枚平均増える算数だ
　増え方は、シーン変更感度が大きく絡むように思うも、全体での構成も加味するのだろう

　なので、動きの有り様は、一枚増だったり三枚増とした場合もあり、判断はエンコーダー任せだ


　‥ゆえに、ｂフレーム（２）とするなら
　ｂフレームが参照するｐフレームのそれのほとんどが、元の像と同じとした話になる

　‥駒増が三枚とした場合もあるわけだけど、それはそれで、GOP長にて距離修正すれば良い
　その加減が、ｉ解除30駒と、プログレッシブ24駒とで異なっていたので
　結果、GOP長（６）に統合した

　　‥それにしてもsubme（７）は、程良く丸まってくる
　　だがそれにしたって、subme（11）よりは‥うす皮一枚ほどの差で雑だった


＞　ここでの値をまとめておくと


　（60駒）GOP長（６）×ｒｅｆ（４）×ｂフレーム（４）×ｂピラミッド×マクロブロック（8x8）
　（60駒）GOP長（６）×ｒｅｆ（４）×ｂフレーム（０）×参照MIX×マクロブロック（4x4）

　※　キュルキュル度合いの完璧さを気にせぬのなら（30駒）でも良い塩梅を見せるだろう


　↑二つの値をDVDソースで比較しても、それ程の差に見えないが
　BDソースで比較すると、圧倒的にｂピラミッドの方が上手に見える

　　‥この違いの差を調べると
　　ビットレート謎比の値の適性が、わさｂ抜きとわさｂ盛りとで違っていると判明せり
　　それは、マクロブロック4×4を用いるか否かとした差にも見えてくる‥‥
　　そんなこんなで、4×4マクロブロック専に適うように再度ビットレート謎比の調整となった

　（ひっくり返ってしまった其を逆転できんのでは、subme（11）とした旨味が薄くならん）

1-3)3

＞　場面変更とする認識は、人とエンコーダーとでどうにも違える要素がある


　‥まず、人の側とて、フェードの絡むパンの境目をどこにすべきかは悩ましい
　黒や白ならまだしも、場面と場面を噛ましたフェード、更にパンしていたりすると、お手上げだ
　今どきのＣＧ制作ともなると、光表現×フェード×重なりつつ動いていたりするのだから尚更だ


　‥そりゃまぁつくる側としては
　フェードとして捌く為にも、真ん中になる位置を決めないと動かしにくいわけだから
　そういう痕跡が残っている
　そこをエンコーダーが場面の区切りとして扱うか否かは、ビットレート次第の所もあるが
　きちんと区切ってくるか否かは、悩ましい話だ


　　‥とくに、ズームアップ目に入って
　　フレーム内をなめるように奥へと滑り込ませるようなアクションの場合など
　　エンコーダーは、その手のアップ画を、場面の切換としてほぼ扱わず

　　更に、静止状態（止め）から動き出す場面の際も
　　いつ動き出すのか不明瞭なのだから‥その間を場面切換としては必ずしも扱わず‥
　　GOP構成上の都合で先頭部分を千切って、前のGOPに割り振るなんて事は日常茶飯事だ


　　‥それの切換と見なさなかったアップ画等を、手前のGOPの尻に付けるわけだけど
　　フェードにしても、ズームにしても、パンにしても
　　その手の入り口を、そのように処理してくれちゃうことが多い

　（CG制作とした都合もあり、ボケから入って‥輪郭を顕わにする‥間が好まれていたりとするが）
　（エンコーダーは、それらを場面として繋がっているとは判定せず）
　　（‥まぁ、サーチする際にも、飛ばしてくれた方が助かる扱いではあるのだが‥）
　　（どうすりゃキーが入るんじゃい？‥とした好奇心×チャレンジ意欲は尽きん）


＞　そんなこんなで単に短いGOP長であれば、それで良いなどとした見方は無粋である
＞　（まぁ長いGOPを用いるだけなら、放置プレイにも無視して良い話ではある‥‥）
＞　（どこからスライスしても綺麗に仕上がるべきである‥とした見方も技術のそれだ）


　　‥結果として、フェードとフェードの端境‥つまり人の側がつくる際に決めた真ん中位置を
　　まんま真ん中にするかのようにして、それぞれの尻尾と頭を繋げたGOPに仕上がっていたりと

　　　ビットレートが不足すると、それの度合いが多くなり深刻化してくる
　　　（場面の頭出しをきちんとできない状態だらけともなると）
　　　（その様な場合の静止画画質は、見るも残念なグデグデに陥りにけり）

　　（あとは、ちょっとしたビットレートの盛り具合の差で、途端にキーが増えたりする場面もある）
　　（かと思えば、ビットレートを盛っても変わらずの場面もある）


　‥悩ましきは、歩行場面のキーの入り具合である

　　原画を起こすようにはなかなかに入らずにブレの出ることの方が多い
　　描く方が同じ枚数で繰り返していない場合や、途中に動きが追加してあったりする際に
　　スムーズなキーの入り方をほぼしない

　一人とした歩行表現でさえもそれなのだから、横に並んで歩く場面なんて事にもなると
　どうしたってキーの入りはぎこちなくなる（まぁそれが圧縮上の都合ではある）

　　（このような傾向なのだから、三駒撮りだから圧縮が効くはず‥なんてのも妄想だ）
　　（どうにもセル塵の度合いによっても、別の駒扱いに見なしてくれちゃうのだｙ）
　　（なかなか綺麗に染み×塵を処理してあってもお残しがあると反って別の駒扱いとか）
　　（短いGOP長とした構成上の宿命なのか、それはもう悩ましい‥orz）


　‥ダンス系のターンの場面なども悩ましい
　人物がくるりとターン回転するそれを、前と後ろだけ拾って間が無いなんてざら
　そこはもう、GOPを短くせざるを得ず（それはもう其処のためだけに‥みたいな）
　そもそもに頑張ってみようとて、ターン回転系の絵面枚数からして少ないことの方が多い


＞　結果的に、場面カットなんてケチい発想では駄目で
＞　コマ送りでキーを入れるべき段階を要求する


　‥わざわざ60駒に増やして、同じとした枚数分を場面として誤認させるのだ
　（其を場面解釈の無駄に思おうと、それをやってのけるノウハウを誰も知らん）

　　‥そしてそれができれば、それはそれで、ｐフレームとｂフレームとした意図と同質に重なろう
　　結果として、それぞれのＩフレームのQP値で調整すれば済む話にも見えてくる‥‥