【エンコード日記】480i→解除用途に限定で4×4マグロ丼が復活っぽ

↓2)記稿.2023/12/09

＞　前回、ベスポジに思えた↓だが
＞　9801（99^2）：627264（792^2）：793881（891^2）；（1.00）0.99235125％


　‥どうにも480i（16:9）の場合にそぐわないと判断
　704×480→1024×576という変換もさることながら、そもそものビットレートが足りんらしい
　（どちらかという（90^2）の方に輝度バランスの分が見られる）


　‥480i（4：3）の場合でも、パン場面において悩ましい不足を明らかに感じる
　（とくにアニメの場合は、あと少しとした感じが常にどうしようもねぇって感じ）

　（こうなっては、4×4を試してみようかなぁ‥みたいな）


＞　とはいえ、どうにも1080解像度出しして、比べてみないとなんとも言えないのである
＞　そんなこんなで計算し直した結果が↓になる


640×1.125＝720
88×1.125＝99　※（4：3）の場合、どうやら7744ではパンチ不足だったらしい

99×1.333333‥＝132（参考：99×1.5＝148.5，99×2.25＝222.75）
99×1.777777‥＝176
88×2.25＝88×（1.125^2）×（1.3333333‥^2）＝99×1.125×1.777777‥＝99×2＝198


_17424（132^2）：435600（660^2）：627264（792^2）；（0.49）0.78408％
_30976（176^2）：495616（704^2）：774400（880^2）；（0.36）0.968％
_39204（198^2）：352836（594^2）：627264（792^2）；（0.25）0.78408％


99×1.111111‥‥＝110
_12100（110^2）：592900（770^2）：774400（880^2）；（0.81）0.968％
_30976（176^2）：495616（704^2）：774400（880^2）；（0.36）0.968％
_48400（220^2）：435600（660^2）：774400（880^2）；（0.25）0.968％

（↑は、774400÷800000＝0.968％に揃えた様相である）


＞　共通解として垣間見えたのが
＞　30976（176^2）：495616（704^2）：774400（880^2）；（0.36）0.968％である


　‥そんなこんなで出してみたところ
　480i（4：3）→解除60枚構成1472×1080（1.36296296‥）
　480i（16:9）→704×480→解除60枚構成1920×1080（16：9）

　（ちなみに、23分半ぐらいで5.2GBに及ぶ）
　（さらに、再生支援機能で視聴した方が‥輝度解釈として補正が入るのか‥画質が安定的になる）


＞　それにしてもエンコード時間をもっとどうにかならないか？


　‥480i（16:9）に関しては
　（176^2）を1080解像度にできるんだから
　（110^2）を720解像度にできそうに思える‥

　‥480i（4：3）に関しては
　発色にこれとした問題は無さそうでも、どうにも動きにガタつきさが見られるのが惜しい
　この点を改善するには、4×4マクロブロックしかなさそうである


＞　‥その両方を併せて試してみたところ

1-2)1

＞　480i（16:9）→704×480→解除60枚構成1280×720（16：9）；BT.720
＞　12100_（110^2）：592900（770^2）：774400（880^2）；（0.81）0.968％


　‥においては、4×4マグロ丼とした本領を発揮してるっぽ
　そうなると

　480i（4：3）→解除60枚構成720×480（1.36296296）；SMPTE 170M
　9801__（99^2）：627264（792^2）：793881（891^2）；（1.00）1.00％

　を差し置いて
　480i（4：3）もHDにしてみよう‥などと欲が出るわけである
　だが、誤差をどうするべきだろうか？
　そこに、解決策として考えたのが、どうせ横解像度の扱いは大ざっぱなんだから
　3：2である見た目比率をそのまんま、16：9に置き換えるだけで良いと思う

　480i（4：3）→解除60枚構成1280×720（1.36296296）；BT.720
　12100_（110^2）：592900（770^2）：774400（880^2）；（0.81）0.968％


　1280×720　→　3600＝80×45
　720×480　→　1350＝45×30

　3600÷1350＝2.666666‥
　1280÷720＝1.777777‥；720÷480＝1.5；1.777777‥×1.5＝2.666666‥

　‥とまぁ符合は整っているのだが
　480i（16：9）のそれは‥端を切り落としているのだから、その分の差が気になる
　ノイズの悩ましさありきが‥480i（4：3）でもあるもんな

　なので、それの不足分を1.1倍として110×1.1＝121にすると↓を得る


＞　480i（4：3）→解除60枚構成1280×720（1.36296296）；BT.720
＞　14641_（121^2）：527076（726^2）：717409（847^2）；（0.64）0.89676125％


　‥単純に、0.89676125×1.1＝0.986437375‥である
　‥VLCにてキャプチャーしたら、1280×939になったん
　（939×1.36296296296‥＝1279.822222‥だそうですヨ）

　‥avidemuxに放ると普通に横長だぎゃ‥キュルキュル原画習いがちょっとやりづらいけど
　出したファイルのエンコード内容にも、1280×720の4：3と刻まれている

　（‥再生とした方針の違いらしい‥何はともあれ4：3で切り取れるなら御の字である）

1-2)2

＞　基本的に解像度の高い方が輝度を得やすい
＞　ビットレートの多い方が輝度を得やすい


　※　当然ながら、高圧縮ノウハウが欠かせない
　とはいえ、それぞれのノウハウには想定とした領分がある（オールマイティなどでは無い）

　高発色を求めればそれなりに、高圧縮を求めればそれなりに
　適応するノウハウも違ってくるという悩ましさこそ、デジタルくさっ
　（中身は数学だから、もといお好みだから‥解法も解も一つには断定しがたい‥みたいな）


＞　ビットレートの配分バランスの拙さから誤差差が大きいと
＞　発色は良いけど、動きの印象が不均一に陥る


　※　ここでの動きとは、光の強弱さとした動きの印象であって、物体の見映え輪郭を指していない
　（ビットレートが多ければ、静止状態の像は放っておいても品質が上がる）
　（そもそも‥静止状態の像からして、色みが整ってこないエンコードなど論外である）


＞　どうして、1.111111‥倍にすると割りとすんなりと足りてしまうのか？


　1.111111‥×1.125＝1.25
　1.111111‥×1.2＝1.333333‥
　1.111111‥×1.5＝1.666666‥

　0.1÷1.111111‥＝0.09
　0.4÷1.111111‥＝0.36
　0.9÷1.111111‥＝0.81
　0.16÷1.111111‥＝0.144
　0.25÷1.111111‥＝0.225
　0.36÷1.111111‥＝0.324
　0.49÷1.111111‥＝0.441
　0.64÷1.111111‥＝0.576
　0.81÷1.111111‥＝0.729

　とまぁ‥べき乗が絡んだ計算の際に‥とても都合が良いらしい
　ちなみに、1.111111‥^2＝1.23456790123456790‥である
　（何とも珍妙な様相だ、誤差が偏るところを知らずに散らばりそう‥みたいな）


＞　ちなみに、（208^2）にも隠れた1.111111‥倍率が存在した


　（208^2）＝43264
　（110^2）＝12100
　（_99^2）＝_9801

　（43264÷12100）の平方根＝1.8909090909‥
　（43264÷9801）の平方根＝2.10101010‥
　2.10101010‥÷1.8909090909‥＝1.111111‥を得る（ヱ☆珍妙な）