【エンコードレシピ】AVC-9801 Trellis（優恋里小扉のトレリス使いだほぃ）

↓13)記稿.2023/12/22

｜唐草も格子も垣も柿落葉 掃いて清めて狙いに美あり
｜ありがちな格子に染まる秋夕垣 通りすがりの景色ぞ赤き
｜赤き映ゆ暮れ染む空とコスモスと旅路の雲も風に躍りぬ
｜縫うように折り込めたくて秋の旅 味覚の旅に変貌しつつ

｜見上げても飄々と柿落葉 歩み来て淋しき影法師
｜詩得られず小さな秋のゆくえ追う 積もり積もりて雪の足跡
｜後戻り利かぬ吹雪の道の先 踏ん張らずんば死を詠みにけり
｜理不尽に尽きること無き春の音 巡るめくるに慈悲ぞ宿らめ

※2023/12/29修正情報：BD（480i）の下処理を誤っていたので修正しました。

---

＞　用意して頂くアプリは、XMedia Recode 64bitの最新版でＯＫでしょう。
＞　但し、インストール版を推奨します。
＞　（DDR4以上のマシンと強力な２Ｄ性能を伴うグラボがポチぃでしょう）


　‥今回対象になるのは
　480i　→　解除60枚構成576ｐアプコン
　1080i　→　解除60枚構成1080p
　1080p　→　60枚構成1080p
　1080　→　解除を含む60枚構成720p or 576pダウンコン‥になります


※　1472×1080pタイプからのダウンコンは、720pを諦めて「720×576ｐ」になります。

※　その昔のブラウン管テレビは、同じ色を再現できないなどと揶揄されていました。
　デジタルの世界にも、そんな状況を編み出してこそ「真空管捻り込み」と表現して良さげでしょう。
　‥ヱ‥なんのことかって、まぁそのですね
　同じ設定で繰り返しエンコードしても同じ結果を得られないんです。
　同じ設定なら、同じ値のファイルサイズを示すはずなのに、同じに成らないんです。‥あれれ？‥

＞　これはきっとエンコード内部に真空管現象を発生してシュミュレートしてるんだぁ

＞　いやいやいや、バグでしょ
＞　バグです
＞　バグです

＞　何を言うか、バグが揺らぐように常に異なるファイルサイズを示して
＞　丁寧に処理した後に安定的に終了するわけがないん
＞　これこそがまさしく「真空管捻り込み」である！

＞　いやいやいや、バグです


　‥てなところで‥レシピにしてみました。
↓/続きを読む/↓

【エンコード日記】Psy-Trellis強度はアプコンとダウンコンで快適値が異なるンゴ！！

↓2)記稿.2023/12/18

＞　等倍＆アプコン時‥VAV4÷VAV1＝1.77777‥　1.77777‥×Psy-Trellis強度（0.81）＝1.44
＞　ダウンコン時‥VAV4÷VAV1＝2.25　2.25×Psy-Trellis強度（0.64）＝1.44


　‥等倍＆アプコン時には（0.81）→９の倍数絡み
　‥ダウンコン時には（0.64）→８の倍数絡み


　‥これを三角関数やらピタゴラスの定理風に考えると
　横辺と縦辺を取り持つのが謎比（1.44）で、角度を変えても半径の長さは変わらないみたいな
　半径を軸にした三角形の横比と縦比の関係を示しているみたいな
　なんらかの因果関係がありそうだが‥きれいめに整うのは、８比と９比の絡みだけ草

　（意外というか、さすが数学とした中身というべきか）
　（世の中にしたって、右肩上がりと右肩下がりで対処も対応も変わりンゴ！）
　（とくに下がり事象の際は、対応からして平時と同じなわけがねぇって事らしい）

　（人員整理の如くバッファを控え目に‥みたいな）

　（＆‥拡大するにも、圧縮するにも追加の技が必要だ‥‥其は間違いなし、思い知りましたｚ）
　（あと、解像度ごとに宛がわれる適切なビットレートに添わざるを得まいて）


＞　‥てなところで、使えるダウンコンのポジションがかなり少ない


・無理矢理ダウンコン（実験的）‥解除した其を今度はMBAFFとか無駄な耐久テスト
　60枚構成720×480MBAFF（1.36296296‥）,（16：9）
　TFF、SMPTE 170M、GOP（30）、ブロッキング軽減（有）、マクロブロック4×4、pw0

　800000÷144＝5555.555555‥の平方根≒（74）
　｛1：64：144｝0.64
　5476（74^2）：350464（592^2）：788544（888^2）


・ぎりぎりダウンコン‥‥（ほとんど需要は無いが、UHDからの過去風映像出し用途に再調整）
　60枚構成1024×576p（16：9），720×576p（1.36296296‥）
　SMPTE 170M、GOP（30）、ブロッキング軽減（有）、マクロブロック4×4
　1080ｐ→pw1；1080i→pw2

　800000÷81＝9876.543209876543‥‥の平方根≒（99）‥‥脳内ブラウン管テレビに相当？
　｛1：36：81｝0.64
　9801（99^2）：352836（594^2）：793881（891^2）


・ダウンコン‥‥（ノウハウ確保の為の確認どえす）
　60枚構成1280×720p（16：9）‥（1472×1080からものは悩ましい）
　BT.709、GOP（30）、ブロッキング軽減（有）、マクロブロック4×4
　1080ｐ→pw1；1080i→pw2

　800000÷36＝22222.222222‥の平方根≒（149）‥‥脳内トリニトロンテレビに相当？
　｛1：16：36｝0.64
　22201（149^2）：355216（596^2）：799236（894^2）


＞　もはや優恋里小扉まされりこぴは「Trellis使い」と化したり
↓/続きを読む/↓

【エンコード日記】ビットレート謎比再調整�U（一覧）

↓2)記稿.2023/12/16

＞　｛2pass平均ビットレート：VAVバッファサイズ：VBV最大ビットレート｝；Psy-Trellis強度


　まず、2pass平均ビットレート比＝1‥なのはそのままだが
　ＶＢＶバッファサイズとＶＢＶ最大ビットレートの関係を｛1：4｝に整える必要があった

　すると

　‥2pass平均ビットレート×？＝VAV×1　→　｛VAV×1：VBV×4｝を得る
　VAVの比率をどれも4倍差にするので
　次に、Psy-Trellis強度の値を掛けて1.44を得る値に集約させる‥つまり（0.36）である

　↑前回のこの値（1.44）を算出するに、同値となる構成（パターン）がもう一つある
　それは、VAVの比率をどれも1.777777‥倍差にすることである


＞　（4×0.36＝1.44）と（1.777777‥×0.81＝1.44）を得る
＞　それは単純に、｛1：4：16｝0.36　と　｛1：9：16｝0.81　である


　※　VAVバッファの多い方が激しい動きやパンに強い傾向を見せる
　但し、全体的に色が微に濃いめに出るとした違いもソースに依っては付き纏うかも知れない
　‥となると、P-フレーム予測の重みを
　「ブラインドオフセット」→「スマート解析」に切り替えてみる？

　　‥ざっと試してみたところ
　　Psy-Trellis強度を効かすと、スマート解析がきちんと追随してくるか否かは
　　まんまプログレッシブとインターレース解除とで違うらしい（制作会社の違いかも？）
　　（P-フレーム予測の重みだけオールインワンとはいかんかも‥）

　　どちらにしても、｛1：9：16｝0.81の方が良さげに‥‥見えるん


＞　↓はその一覧である
↓/続きを読む/↓

【エンコード日記】ビットレート謎比の再調整の結果、基本形を得たっぽい

↓5)記稿.2023/12/15

＞　｛2pass平均ビットレート：VAVバッファサイズ：VBV最大ビットレート｝；Psy-Trellis強度


　まず、2pass平均ビットレート比＝1‥なのはそのままだが
　ＶＢＶバッファサイズとＶＢＶ最大ビットレートの関係を｛1：4｝に整える必要があった

　すると

　‥2pass平均ビットレート×？＝VAV×1　→　｛VAV×1：VBV×4｝を得る
　VAVの比率をどれも4倍差にするので
　次に、Psy-Trellis強度の値を掛けて1.44を得る値に集約させる‥つまり（0.36）である
　　（思いこみにも１で割り切れ整う0.25の方が良さげに思ったのだが‥違った）
　　（4×0.25＝1‥だとデータの保持に欠くのか、パンが不自然に出たりする）

　‥とした感じで整いを見せる（本職側の数学的にどうかなんて知らんがな）


＞　あとは、サイズとの適合だ
＞　ちなみに、8ビット量子化済みソースを10ビットに置き換えるので
＞　その分の違いとやらが投影された像になるどえむ（10ビット対応モニターでの確認が必要だ）


　‥普通に見比べると、常に、ソースの方が微にエッジ感強めに見えるん（抜き取り静止画拡大時）
　其をどうにかしようとしても、もはや目一杯だ（弄った所で歪さにしかならん）

　‥ちなみに、最終的な10ビット→8ビット置き直し再生を調整するのはグラボ×ドライバーどえす
　HDMIを介して、モニター側とダイレクトにやりとりする仕組みだ‥そうです
　（なので、グラボによっては、モニターの違い以上に‥無残に見えるかも知れん‥）
↓/続きを読む/↓

【エンコード日記】インターレースには、32×32マクロブロックとしたお作法がある？

↓2)記稿.2023/12/11

＞　インタレースとした放送規格は、縦解像度を重視します
＞　その規範にあるのが、32×32マクロブロックお作法どえす（変換元解像度）


　4：3映像なら、1472×1088　→　46×34になる（黒帯込みなのでとくに悩む必要なし）
　16：9映像なら、1920×1088　→　60×34になる（480iに刻まれる黒帯分の処理が謎??）

　普通に1920→704なら、2.727272‥倍差です
　なのに480i（16：9）の場合、多くに黒帯が左右に（＋2）計（＋4）付いていたりします
　これは一体全体なんなのでしょうか？

　さらに上下のどちらかに（＋2）の黒帯があったりします
　こちらも一体全体なんなのでしょうか？


＞　‥では、480i（16：9）に見られがちな上下の黒帯はどのように附されるのか？
＞　上下に帯無しソースとの違いとは？‥を計算してみましょう（正解か否かなど知らん）


　‥まず、1080解像度でデータを用意するか、1088解像度で用意するかの差になってるくさっ

　その差を8÷2.727272‥すると（2.933333‥）です
　8÷2.25なら（3.555555‥）、8÷2.266666‥なら（3.529411‥）です

　是でイメージとしては、染まらないドットが２つ確実で
　残りの２ドットがグラデを伴った中間色に染まりあがるイメージを醸すのでしょう

　なので黒帯を外したかったら、始めから1088解像度にぎっしりと描き込むか
　1080→1088に引っ張ってから、480ｉエンコードに掛けるかのどちらかくさいどえす
　（それっぽいソースもチラホラしてるどえす）


　‥というわけで、1088×1.777777‥＝1934.422222‥です
　当然、32×32のお作法がありますので、問答無用で‥61×32＝1952に丸まります

　1952÷2.727272‥＝715.733333‥≒716です
　つまり、720−716＝4を得ます（480iに変換した後の横の黒帯幅）

　整えると、1952×1088の周りに、左右計算1952−1920＝32、上下計算1088−1080＝8
　の黒帯を附して、480iエンコードをしているらしいどえす

　すると、480i（16：9）の際に
　左右に（2）ずつ、上下のどちらかに（2）とした黒帯がまとわりつく仕上がりになるっぽ


＞　‥だども、もともとの1920横解像度が
＞　1952÷720＝2.711111‥の1920÷2.711111‥＝708.196721‥≒708とした扱いになります
＞　どうにも規定の704なんざ無視しているクサい仕上がりに？？


　1952÷1920＝61÷60＝1.016666‥
　2.727272‥×1.016666‥＝2.77272727‥
　1952÷2.77272727‥＝704

　1952÷16＝122、704÷16＝44
　122÷44＝2.77272727‥（なんとマクロブロック的にも割り切れるっぽ）

　‥え☆じゃ‥上下どちらかに振られている黒帯（2）を削らないと駄目なんじゃねぇの？
　　　でもまぁお作法の結果丸まっちまっているわけでして

　　　ただでさえ、元左右両端に足した黒帯分の半分が中間色に染まり埋まっちまってるわけでして
　　　上か下に置かれた其にしたって、どんな計算結果のなれの果てかなんて分かったもんじゃねぇ
　　　（ただでさえデジタルソースにはキラキラ表現てんこ盛りなんですから無理ッ）
　　　（そもそも、削れる余地なんて無ぇって感じでしょう）

　　‥なので、内部計算比オリジナルのままだと
　　どんな計算値になっているのかなんて素人には判らないのだから
　　誤差障害を避ける意味と改めて、16：9を附しつつ‥ｉ解除エンコードせざるを得ないどえむ


＞　1080→1088解像度に詰め直さなかった時点で、正確さなんてもう無理ッみたいな（残念！）


　‥通常はビットレート不足の際に、左右両端の数ドットを落として黒帯に置き換えるぽいのですが
　中には同じタイトルBDソース比較で、上下完全カットソースも見られます（どうなってんだよ？）
　（ビットレート不足で、全体の構成自体を差し替えてあるぽい‥謎）
↓/続きを読む/↓

【エンコード日記】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マクロブロックしかなさそうである


＞　‥その両方を併せて試してみたところ
↓/続きを読む/↓

【エンコード日記】空間軸圧縮が何をしているのかがよく分かるサンプル

)記稿.2023/12/07

＞　空間軸圧縮とは、マクロブロックサイズで、似たような形状を探し出して
＞　どうにかこうにか当てはめるパズルのような応用である


↓は、それがとてもわかりやすいサンプルどえす

では問題です
↓の絵の中に目玉に見えるマクロブロックはいくつあるでしょうか？




‥目玉に見える数ですよ

歯に付いてる影なんてどうですか？
その上にある、頬皺なんてどうですか？
そのちょっと上に髪の毛の影が二つほどありますが、その辺りなんてどうですか？

そんな感じで、右目の形を模したマクロブロックがチラホラしています
左目のもいくつか見られますが

そんな感じに、似たような形を探し出して使い回すのが空間軸圧縮どえす

（でもここまで露骨に目の形を使い回すとは、来てますよね）


‥という次第なので
解像度を上げた際にも、似たようなモノを探し出して
ビットレートを割り振るどえす

ド素人が考えるように品質が上がるという次第ではありません
品質を上げたいなら、量子化前のマスターデータ必須なんですよ


‥空間軸でさえこれですからね
さらに時間軸を掛け合わせると
その秒間にいくつの目玉が散らばるかと思うと、もう、うんざりしますよね


＞　なぜか、480→528サイズでキャプチャーされてる‥？？
＞　ということで、駄目押しで1472×1080サイズをどうぞ↓

【エンコード日記】解像度が異なると限界となるビットレート謎比が異なる‥規格上限を得る件

記稿.2023/12/06

＞　AVCのレベル6.2のVBV最大ビットレートの限度値は（800,000）kbits/s‥である
＞　その限界に近づけるほどに輝度を増す（艶を得る）ことが判明どえす


　‥ゴレンジャーの後期OP（キレンジャーの役者交代版）だと
　まだまだ輝度が不足していて色が出て来ないというパターンが
　時期的に重なる作品に多々見られる‥（何らかのどうしようもねぇ物理的な変更期だった草）

　其を改善する為の秘策＆着想こそ
　Psy-Trellis強度（1.00）に最適化する為のビットレート謎比とした値の調整だ
　1080解像度だと物理的に無理だが、480解像度でならギリギリで満たせる
　その数値こそ‥


＞　レベル6.2の上限800000→≒べき乗値の上限（894^2）→（891^2）
＞　9801（99^2）：627264（792^2）：793881（891^2）＆（1.00）‥こそベスポジだった
＞　とどのつまり｛1：64（8^2）：81（9^2）｝＆100（10^2）‥だった


　ザックリ↓のイメージになる


　7744（88^2）：_69696（264^2）：123904（352^2）0.25
　7744（88^2）：123904（352^2）：193600（440^2）0.36
　7744（88^2）：193600（440^2）：278784（528^2）0.49
　7744（88^2）：278784（528^2）：379456（616^2）0.64
　7744（88^2）：379456（616^2）：495616（704^2）0.81
　↓
　7744（88^2）：495616（704^2）：627264（792^2）1.00‥‥ビットレート不足っぽ
　8100（90^2）：518400（720^2）：656100（810^2）1.00‥‥ビットレート不足っぽ


　要約すると↓を得る

　｛1：_9（3^2）：16（4^2）｝＆25（5^2）
　｛1：16（4^2）：25（5^2）｝＆36（6^2）
　｛1：25（5^2）：36（6^2）｝＆49（7^2）
　｛1：36（6^2）：49（7^2）｝＆64（8^2）
　｛1：49（7^2）：64（8^2）｝＆81（9^2）
　｛1：64（8^2）：81（9^2）｝＆100（10^2）


＞　ちなみに‥｛640：704：720｝＝｛1：1.1：1.125｝＝｛88：90：99｝だった
＞　‥其を踏襲してやりゃバッチリだったのである‥


　‥うんちくを無理矢理垂れてみると
　マクロブロック数の倍倍を十分に満たすVBVバッファサイズを組み込んでやるのが
　一つの条件らしく‥そこから・・・・で、均一性を保った輝度の改善を得るっぽい

　つまり、バッファ値を64倍にすることで、十分に4×4マクロブロックの代役を満たすっぽい

　ならば、FHDでの4×4なんざ、ほんの気分程度しかないから、8×8に丸め込めるくさっ
　という関係性に思われる

　とはいえもう一つの物理的な限度値（208^2）が立ちはだかるので
　FHD規格での輝度上限値は、DVDもとい従来のテレビ規格より下回る流れになった草っ


＞　1：9：16＆25
＞　39204（198^2）：352836（594^2）：627264（792^2）＆（0.25）
＞　43264（208^2）：389376（624^2）：692224（832^2）＆（0.25）


　‥800000÷25＝32000　→　≒平方根の最大値（178）　→　99からのべき乗値比確保（176）
　176÷99＝1.777777‥（1.333333‥^2）

　ということから

　1：16：25＆36
　30976（176^2）：495616（704^2）：774400（880^2）＆（0.36）

　が、60枚構成1280×720pでの均一性を保つだろう輝度発色を期待できるのでは？

　　‥ソースに依っては、60枚構成1920×1080pでもイケそうに思われるも
　　それなら縮める用が無い分↓の方が良さげである
　　31684（178^2）：506944（712^2）：792100（890^2）＆（0.36）


　793881÷800000＝0.99235125％　←ビットレート（99^2）
　792100÷800000＝0.990125％　←ビットレート（178^2）
　774400÷800000＝0.968％　←ビットレート（176^2）
　692224÷800000＝0.86528％　←ビットレート（208^2）
　627264÷800000＝0.78408％　←ビットレート（198^2）


＞　ということで‥再びの全部確認やり直し‥ンゴ！!
＞　しかも確認すべき量が倍になってる（年内に終わらねぇくさっ）

【エンコード日記】ビットレート謎比｛1：9：16｝にしたらダウンコン720pが安定的に

記稿.2023/12/05

＞　ビットレート謎比｛1：4：9｝から｛1：9：16｝に切り替えたところ
＞　1920×1080→60枚構成1920×720pへのダウンコンが安定的になった


　‥そこで、これまで及び腰だったPsy-Trellis強度の耐久テストをしてみたところ
　（1.00）までこれとした副作用を発生せずに耐久力を発揮するものの
　さすがに、ビットレートを持って行かれるのか、細かいテクスチャーが全部剥がれ気味に陥る
　（そこまで行くと1024×576ｐと大した差を感じない）

　‥そんなこんなで、静止画拡大比較した際の見た目の良さげなのが（0.25）らしい（確認中）

　テクスチャーが剥がれまくっても良さげに見える次点が（0.81）になるが
　（0.25）に比べると概ねボケて見えるのでどちらにしても使えない
　（ビットレートをさらに盛り付けたし考えなど有るはずも無し）


＞　基本的に、Psy-Trellis強度が何をしているのかなんて知らんがな


　‥が、ダウンコンの色の取り出しの際には、潰れた解像度の色の中間を心理的に確保するのだろう
　あとは、輝度を優先にする度合いとか‥

　それのビットレート割り当ての度合いに思われるが
　通常概念とした設定だと
　値を増加するほどにビットレートを持って行かれてボケるとか‥そんなの気にする以前に
　壊れたテクスチャーとした副作用が発生して使えなかったわけで
　そこが優恋里小扉だと‥作用そのものが異なっているのだから不思議だ（10ビットを条件とする）


　‥ダウンコンのくせにインターレースを用いない代わりに
　Psy-Trellis強度を試しているわけだが（そもそもの720解像度にインタレースとした仕様が無い）

　その差の違いなのか、盛り付ける値によっては
　解像度潰れとした中身の色をどうにか引き出そうとしたノイズ感を見せる諸々傾向がある

　とくに、（1.00）まで上げると
　部分的な輝度を優先して‥無駄にビットレートのやり繰りをするのか
　妙にそこだけ色が派手で、ノイズにしか見えなかったりとする（静止画だし拡大時）

　それが部分的で無く、線状として現れる場合もある
　大抵は横筋だが、縦筋としたパターンを見せる値もある（静止画だし拡大時）


　‥とはいえ、静止画での拡大にて判別つく度合いでしかないので副作用の範疇では無い
　‥とはいえ、逆に値が小さくても、モヤモヤした感じ傾向を見せてよろしくない
　　（通常はそこの差を、ブロッキングで調整するような案件なんだろうけど）
　　（優恋里小扉では、そこで、何が起きているのかなんて知らんｚ）


＞　｛1：4：9｝｛Psy-Trellis強度（0.09）｝から
＞　｛1：9：16｝｛Psy-Trellis強度（0.25）｝にビットレート謎比を変更した結果


　‥その画質差としては
　初期型の端丸カラーテレビ　→　端角カラーテレビに変わった感ぐらい
　モヤッとしていたのが消えてクッキリしている
　（アニメだと記憶差で気になる場面との違いぐらいでしか判断付かないが、特撮だとよく分かる）
　（とはいえ、ソース次第にある点は変わらないが、取りあえずの目標に到達した感はあるだろう）


　‥確認作業はまだまだ続く（結局、暫定でのレシピ揚げくさっ）

　（ビットレートの割り当て余裕が思っている以上にあるようなのが謎）
　（そこが８ビットと10ビットの差という事なのだろうか？？）

【エンコード日記】ビットレート謎比｛1：9：16｝を一覧にしてみた

↓2)記稿.2023/12/05

＞　ビットレート謎比｛平均ビットレート：バッファ：最大ビットレート｝
＞　これを｛1：4：9｝から｛1：9：16｝にしても
＞　メインとなるビットレート値は変わりません‥変わるのはPsy-Trellis強度どえす（なんでやねん）



＞　好逸ユーザー（シャープネス24）組


　480i（4：3）→解除60枚構成720×480ｐアスペクト比1.36296296‥‥SMPTE170M
　7744(88^2)：69696(264^2)：123904(352^2)‥‥扱いレベル5.2

　480i（4：3）→解除60枚構成アプコン1472×1080ｐアスペクト比1.36296296‥‥BT.709
　26244(162^2)：236196(486^2)：419904(648^2)

　※　(162^2)は参考までで、画質アップの体を満たしません（480iからアプコンする意味が無い）
　　とくにアニメの場合は、作品によってはBT.709ボケを見せたりします
　　エンコード時間も馬鹿にならないので、画質的にも容量増的にも720×480をオススメします


　i解除＆Ｐ（4：3ソース）→60枚構成1472×1080ｐアスペクト比1.36296296‥‥BT.709
　39204(198^2)：352836(594^2)：627264(792^2)‥扱いレベル6.2



＞　好逸リビング（シャープネス24）組


　480i（16：9）→解除704×480→60枚構成1024×576（16:9）‥‥SMPTE170M
　i解除＆Ｐ（16：9）→60枚構成ダウンコン1024×576ｐ（16:9）‥‥SMPTE170M
　8100(90^2)：72900(270^2)：129600(360^2)‥‥扱いレベル5.2

　480i（16：9）→解除704×480→60枚構成アプコン1920×1080（16:9）‥‥BT.709
　i解除＆Ｐ（16：9）→60枚構成ダウンコン1280×720ｐ（16:9）‥‥BT.709
　28900(170^2)：260100(510^2)：462400(680^2)‥扱いレベル6.2

　※　こちらはアプコンする用を満たしますが
　　　480→アプコン1080なのに対して、1080→ダウンコン720になっとります
　　　（それだけ量子化済みの1080ソースは中身が複雑どえす、舐めてはいけません）
　　　‥細かいことを言うと
　　　　1080i→576pダウンコンする際にも此処のポジジョンしか無いので同じなら720pでしょう
　　　　1080p→720pダウンコンなら（135^2）も候補に上がりますが、確認し切れていません


　i解除＆Ｐ（16：9）→60枚構成1920×1080ｐ（16:9）‥‥BT.709
　43264(208^2)：389376(624^2)：692224(832^2)‥扱いレベル6.2



＞　81×81×4＝26244(162^2)
＞　81×81×4.444444‥＝29160≒28900(170^2)

＞　99×99×4＝39204(198^2)
＞　99×99×4.444444‥＝43560≒43264(208^2)

＞　｛90：170｝＝｛135：255｝
＞　135÷90＝1.5，255÷170＝1.5‥‥（参考値）
↓/続きを読む/↓