【エンコード日記】解像度×マクロブロック（16×16）数×ビットレート謎比のベストマッチとは‥

↓4)記稿.2024/07/12

＞　エンコーダの違いにより圧縮率は変わります
＞　GOP長とした構成の違いによっても圧縮率は変わります
＞　そして、ハード性能による限界をどうにかするのも技術です


　‥されど、素敵に割り切れる値とした数学上の中身に変化無し
　これはそういう角度からの着眼どえす


　‥普通に静止画の出来映えが綺麗なら圧縮率換算として同等としている誤解もありますが
　見落としがちなのが、動き再現性とした同等さの担保ありきどえす

　　パンがカク付いてたら意味ねぇ
　　ズームがスムーズになかったら意味ねぇ
　　プレイヤーのデコード処理違いから再現時にマクロブロックの不一致でエラーってたら意味ねぇ

　（挙げ句の果てに、キーサーチが効かずにオープンGOP状態なんざスムーズ確認し難いだけだｚ）


　　‥そりゃまぁエンコーダ開発陣はそこん所の差を把握して、規格するんでしょうけど
　　下ほどに、諸々と、押し込むしかねぇ現場事情に晒されるわけで（詳細知らなきゃ当然）
　　見映え重視とばかりに、動きとした再現性に手落ちをやらかしたりするどえす


＞　そんなこんなの不都合を吹き飛ばしてくれるビットレート謎比解釈とやらは有るのか無いのか？
＞　（まぁＱＰ値換算の方が理解しやすいんでしょうけど）


　‥そもそもの動画エンコーダの規格と適正とする解像度はセットです
　なので、圧縮比率とした中身を考慮すべき内訳をここでは端折ります

　　‥とはいえGOPの構成は確実に絡むでしょう
　　‥とはいえどのようなGOP構成を前提にすべきかを誰も知らん
　　（規格側にしたとて、想定した範囲でしかねぇ）
　　そんなこんなで、諸処多様に、勝手気ままにてめえの好むスタンスをぶつけるだけである

　それでも、マクロブロック辺りにどのぐらいの比率でビットレートを割り当てるべきか？
　とした悩ましき課題は共通である


＞　ズバリ、６倍でしょう（正確には６キロビット倍？）
＞　（まず６倍もあればフレームレート差なんか関係ねぇ‥何やっても整うみたいな）


　｛16×16マクロブロック分解数：ビットレート：VAVバッファサイズ：VAV最大ビットレート｝
　＝｛１：６：１０：６０｝

　そこからの↓予想どえす

　≒｛Ｍ：Ｍ×Ｂ：Ｍ×１０：１０×Ｂ｝‥‥（Ｂ値の下限なんぞ知らん）


　　‥‥但し、ここでの検証ＧＯＰ構成は
　　Level６.1×フレームレート（59.94）×GOP長（６）×わさb抜き×マクロブロック（4ｘ4）

　　それでＢ値（３）〜（６）の静止画画質とした見映え差は、感性が鈍っていると同じに見えます
　　でも（６）の方が、動きのスムーズさ比較では安定してます

　　なので（６）以上を盛る意味は薄いので、解像度を上げてみようの流れになるでしょう

　　でも、解像度を上げて（３）倍を選ぶよりは
　　下の解像度に甘んじて（６）倍を選んだ方が無理が少ないでしょう


＞　又、テレビUSB挿しにおいては、（6）倍の方が
＞　三つの映像メニューにおいて、より安定発色します（これはもう決定的な‥‥）


　好逸スタンダード‥ＰＣ画面編集印象な浅昏さに整って見える（TFT風？）
　好逸ダイナミック‥ブラウン管からノイズを廃して液晶にしたような異次元インパクトが中毒に
　好逸リビング‥‥今風ノートパソコン画面印象でフラットな明るさに整って見える

1-4)1

＞　720×480（？？？？？）→　45×30　→基本数（1350）
　｛8100：13500：81000｝



＞　720×528（1.363636）→　45×33　→基本数（1485）‥DVD4：3全部盛り
　｛8910：14850：89100｝
＞　960×528（1.8181818）→60×33　→基本数（1980）‥DVD16：9全部盛り
　｛11880：19800：118800｝

＞　1080×792（1.363636）→67.5×49.5≒68×50　→基本数（3400）‥BD480全部盛り
　｛20400：34000：204000｝
＞　1440×792（1.8181818）→90×49.5≒90×50　→基本数（4500）‥DVD16：9用途（没）
　｛27000：45000：270000｝


＞　1056×792（4：3）→66×49.5≒66×50　　→基本数（3300）
　｛19800：33000：198000｝



＞　960×720（4：3）→60×45　　→基本数（2700）
　｛16200：27000：162000｝

＞　1024×576（16：9）　　→　64×36　→基本数（2304）
　｛13824：23040：138240｝
＞　1280×720（16：9）　　→　80×45　→基本数（3600）
　｛21600：36000：216000｝

＞　1440×1080（4：3）　　→90×67.5≒90×68　→基本数（6120）
　｛36720：61200：367200｝

＞　1920×1080（16：9）　→　120×67.5≒120×68　→基本数（8160）
　｛40800：81600：408000｝　←ハード性能許容内（５倍）
　｛48960：81600：489600｝　←ハード性質の限度超（ハイスペック限定）

1-4)2

＞　BD480ｉの秘めたる中身が、予想を遥かに凌駕してた件


　‥短いGOP長にすればするほど、BD480ｉの発色がソースと噛み合わなくなるどえす

　ソースと色が違う部分が顕著に気になるので（なんでわぴこのピンク頭だけ色に差がでるんや？）
　｛１：６：１０：６０｝と｛1080×792｝を組み合わせた所
　漸くに、発色がソースに沿うようになったｊ

　　（BD480ｉには、｛1080×792｝以外の解像度での爆Ｑエンコードは非推奨どえす）
　　（480ｉなのに、中身はＢＤ規格としたそれだった‥と言えそうですが‥‥）


＞　ビットレート増量確実となり、うれしいようなうれしくないような戸惑いありきどえす
＞　（だが、テレビUSB挿しで回す際に、発光発色印象がとても良くなるのだから‥雑作無し）

1-4)3

＞　DVD（16：9）の全部盛りにしないと怪しいケースが発生
＞　（これも短いGOP長とした定めだからくせぇｚ）


　‥DVD（16：9）をどのように加工してアレな解像度に落とすのか
　とても謎めいて見えるのが、ソース毎にバラバラな黒帯の有り様です

　　有効解像度704×480としたうんちくは理解できるにせよ
　　デジタルソースとしては、余白が勿体ないからと、データを詰め込んである理屈って何？


　‥真っ先に思いつくのが、1080解像度を1088に拡大したそれをアレな解像度に落とす策です
　（インタレースの取り扱い上、32×32のマクロブロック解像度幅に強制制限されます）

　　すると横解像度が1920→1934.222222‥となり
　　それを2.727272‥で割ると、709.21481481‥を得ます
　　左右で（5）ないし（6）とした黒帯を見せるのがスタンダードにあるようです
　　この見た目の悪さに区切りを付ける採用案が、1920×1080←→704×480になってます

　　　だがしかし、704×480を再生する際には‥へぇそうなの‥との思いはすれど
　　　圧縮する際には「縦解像度が違うでしょう」「誤差出るじゃん」と誰しもツッコむ所らしく
　　　業界的にはガン無視のご様子どえす

　　又、インターレース化する際に、エンコーダ側が誤差をどう処理してくるかの差が起こるらしく
　　左右で（5）ないし（6）とした黒帯が、キッチリ固定してなかったりと出てきます
　　そんなこんなで、左右端（8）で切り落とすべきが規格の有り様だとしても

　　　再生プレイヤー側の対応は、とても怪しいｚ
　　　　（普通に収納映像全部を、4：3と16：9で再生してるっぽ）
　　　　（704×480な意味なんて知らねぇよ‥と言わんばかりどえす）

　　　（何故に切換ボタンを用意せんのか？‥ちょとした気遣いの差ですよね）
　　　（何十年経ったらそれに対応するのだろうか‥？？？）
　　　（もしかしたら、ハードウェア処理の方で未対応？？？‥‥利権絡んでいそうで草‥）


＞　最もよく判らないのは
＞　左右にぎっしり詰まっているのに、上下どちらかにちょびっと黒帯が入るそれの意味とは？？


　　容量都合から、削ってあるとしか思えないにせよ、左右にはぎっしりなんですよ
　　それとも、フィルム絡みの上か下でのチラチラ排除なんでしょうかね？？
　　中には、上下左右ともに全部詰まっちゃってるうれしい作り込みの480ｉも見られます

　そんなこんなで、端切りをすると、そこのマクロブロックデータを紛失します

　長いＧＯＰなら、どこかで摺り合わせて、仕切り直しも有り得ますが
　短いＧＯＰ構成ともなると、データの紛失の結果、マクロブロック間の噛み合わせを悪くします
　必ずしも悪くなると言うことでもありませんが、確率が上昇します

　編集画面上では問題無いのに、ハードウェア処理をせずに回すＶＬＣの際にエラーが出るらしい
　（なんでそこだけ？‥としたそれは納得しがたいのです）
　（手持ちのソースで都合良く駄目なパターンが出てしまうともなると‥そりゃまぁ改善せな‥）


＞　で、DVD16：9のそれ回避策として計算し直したのが
＞　960×528（1.8181818）と1440×792（1.8181818）とした全部盛りの二案です


　‥960×528は、｛720：704｝としたカット位置では割り切れていません
　‥1440×792は、カット位置でも割り切れるのですが、マクロブロックも割り切れるのに
　なぜか稀にソースに無いバンディングノイズが入る可能性があるようです
　　（手持ちのソースで、運良く？そんなん直ぐに見つかるなんざ‥使えねぇ）


　　‥そんなこんなで、まさかの｛960×528｝しか選択支がねぇ‥みたいな
　　まぁ全部盛りなんだし、カット位置の割り切れるか否かなんてこの際‥目を瞑ろう（そうしよう）

　（これが以外にも好い感じに仕上がる）
　（19型画面だと、上下のそれは別としても、左右に黒帯分があるととても気になる‥）
　（画面が小さくなったなぁと思わざるを得ず）
　（更に‥25分もの2GB以内想定（10800）と較べると（11880）は、ちょっと痛い）

1-4)4

＞　参考までに、｛１：６：１０：６０｝にすると、駒違いでキーが入りやすくなります
＞　※　わさb抜き×60駒構成前提
＞　※　更になぜか、CRFと同じくキーが増えた分だけ増量するっぽい？？（1.111‥倍ぐらい？？）


　‥短いGOPとした指定都合からの、圧縮効率を取捨した結果なんでしょうけど
　場面の端境でキッチリカットはするけど、これでは場面の端と端でカットしているとは言い難い
　とはいえ、概ねでコマ送り間隔にキーが入るなら、理想的に至った感有りでしょう


　‥とはいえ、｛１：６：１０：６０｝だけでは足りてません
　そこはさらに、４×４マクロブロックを効かすとなぜか、キーが増えます
　さらに、Psy-Trellis強度を（1.00）に上げると、ビットレート量に沿ってキーが増えます

　　‥おや、いつの間にやら、それな値をケチってたのが
　　キーフレーム枚数を落とす為の中身だった‥だけになっとるどえす‥

　　それが、AVCのバージョンアップの結果なのか否かは判りませんが
　　コマ送りレベルでキーが入る方向に至ったのは有り難いことです‥‥m(_ _)m


＞　走ってくる場面での腕の振りからして、らしくキーが入ると
＞　キュルキュル回しても、普通に再生するにしても違って見えるもんですよ


　（但し、量子化前の粒ぞろいにそんなの関係ねぇ‥みたいな）
　（其の差とした見立て違いに理解を示せるか否か‥そこが分かれ目どえす）


　‥いやぁそれにしてもまだまだ確認中どえす‥