2024年01月25日

【フィルターレシピ】B管風にじませ8段活性嘆フィルター(検証経過中途)

↓7)記稿.2024/01/25

> XMedia Recodeに付随するフィルターの精度が頼もしかったのでトライ&エラーしてみた。
> (年末にも年始にも成し遂げられず‥2024に突入し‥一月も終わりだぉおおおう)


 ‥ブラウン管の滲みとは
 アナログテレビに横の解像度概念に乏しかった理由として
 ドット的に格子が表現できていたわけではない点が挙がる。
 近寄ってブラウン管の格子を確認したことがあるなら知ってるだろうが
 赤緑青とした順に並んでおり(逆だったかもしれんが)それが更に

  赤緑青赤緑青赤緑青赤緑青赤緑青
 赤緑青赤緑青赤緑青赤緑青赤緑青
  赤緑青赤緑青赤緑青赤緑青赤緑青
 赤緑青赤緑青赤緑青赤緑青赤緑青

 ‥という具合に六角格子模様にズレて配置されていたものだ。(ドット単位管理に無かった)
 当然、隣合う上下左右斜に干渉し合って、滲みあうどえむ。(滲まないわけがナインッ)
 しかも、奇数ラインと偶数ラインを時間差で描き込む‥その先から消え出す誤差も含まれ
 滲んでいるようでいて、色情報を補い合って発色が足し増しされていたのだった。

 (ちなみに、その手の技法をアンシャープと言う‥だがアナログテレビへのそうした見解は疎い)
 (当時の誰しもが、滲むのに逆に発色が上がるとしたテレビの日常に気が付いていなかったん)
 (いやぁだってブラウン管だったし、ブラウン管バイアスだったz)


> ‥足し増しされていたのだった‥というのは、今回トライ&エラーしてみての感想である。
> つまり、当時の映像観により近づくには、器用に滲まして発色を上げるしかないのだ。


  (繰り返す、その手の技術をアンシャープと言う)

   今どきモニターだって隣り合う分には干渉し合うわけだけど
   直線に並んでいるので、干渉面積は小さくなっている。
   しかも、似たような色がドット単位に隣り合うのだから、滲むとした感度には程遠い。
   (あとマクロブロック単位で明度管理されている‥420とかYUVなど)

   更には、制作サイドが、ドットレベル相当での其をきちんと表現したいと思っていれば 
   滲まない・濁らないような色使いやらエンコードの際の工夫がやり繰りされるだろう。
   (そうなってはもう、ブラウン管発色からどんどん遠ざかりギラテカすることは無い)


> そして、そこにおいても皆で同じバイアスを繰り返す。
> その名を「フィルムグレイン」と呼ぶ。


  ‥だがしかし、今回思ったのは、それはもはや「量子化グレイン」だった。
  量子化される前なら、フィルムグレインを唱えても問題ないだろうけど
  量子化された映像の場合のそれは、どう考えたって「量子化グレイン」だった。

 【グレイン】‥穀物のような粒々としたノイズ‥の意である。

 ‥量子化された映像に生ずるjpegノイズにも見えるグレインは
  AQの調整値の結果のそれなので、具合の良い状態に合わせるとノイズとして感じられなくなる。
  だが、単純に量子化グレインが全部見えなくなる程に丸めると輪郭や遠近感がそぞろに陥る。

  とはいえ、DCT有りのような‥強引な無かった扱い処理をせずに、残しておく限りにおいて
  いくらでも復活するし、その様な状態に戻して再調整が可能である。(要ビットレート必須)
  (という事実を今回思い知ったのだった‥‥へぇ〜そうだったんだぁ‥‥)


> ビットレートを下げすぎてもいないのに多少なりとぼんやりしてしまう場合のそれは
> シャープさをどうにか調整してやって微に戻してやれば、問題を小さくできるちゃ‥できる‥
> (だが、シャープを掛けるがゆえに、線境の強調しすぎ回避の制御は険しい)


 ‥それは、知れば知るほど
 エグいほどに、輝度と彩度の調整感度バトルなのだった。(人の目で追える範囲外だ)
 その二つを適正にずらして整えてやるだけでピタリとボケが消え去る焦点があるのを思い知った。
 (ボケは消え去るものの、480i→60枚構成i解除の際のズームに課題を突きつけられている)


> だが、どう見比べても、インターレース解除のそれと、プログレッシブとしたそれとでは
> 再エンコード時の滲ませ結果が違うどえす。


  インターレース内容だから滲むけど、端からプログレッシブだと滲まないくさい‥
  (もといプログレッシブとて、特定の面積比に特定の色合いの粒々にハマると滲むくさい)
  (ソースと違うと思ったら、それはもしかしたら‥滲み?かも‥程度どえむ)

    ‥其を具体的に述べると
    超高層ビル群の赤いライト(航空障害灯)表現の色合いやら星粒の色合い
   (キラキラ表現全般に影響するわけでも無い所が謎)
 (輝度に引っ張られていると発色が上がり、そうで無い場合には赤みからして昏く仕上がる)
 (どの作品を見ても同じ色で表現されがちな航空障害灯に変化が欲しい場合にはありだけど‥)
   (つまり、ここのこの部分だけ滲んでおりますフィルター案になるどえす)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 17:22 | Comment(0) | AVC-優恋里小扉 | 更新情報をチェックする

2023年12月29日

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

↓13)記稿.2023/12/22


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

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



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




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


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


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

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

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

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

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

> いやいやいや、バグです


 ‥てなところで‥レシピにしてみました。
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 10:06 | Comment(0) | AVC-優恋里小扉 | 更新情報をチェックする

2023年12月18日

【エンコード日記】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)→9の倍数絡み
 ‥ダウンコン時には(0.64)→8の倍数絡み


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

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

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

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


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


・無理矢理ダウンコン(実験的)‥解除した其を今度は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
 1080p→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
 1080p→pw1;1080i→pw2

 800000÷36=22222.222222‥の平方根≒(149)‥‥脳内トリニトロンテレビに相当?
 {1:16:36}0.64
 22201(149^2):355216(596^2):799236(894^2)



> もはや優恋里小扉まされりこぴは「Trellis使い」と化したり
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 22:13 | Comment(0) | AVC-優恋里小扉 | 更新情報をチェックする

2023年12月16日

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

↓2)記稿.2023/12/16

> {2pass平均ビットレート:VAVバッファサイズ:VBV最大ビットレート};Psy-Trellis強度


 まず、2pass平均ビットレート比=1‥なのはそのままだが
 VBVバッファサイズとVBV最大ビットレートの関係を{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の方が良さげに‥‥見えるん


> ↓はその一覧である
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 14:10 | Comment(0) | AVC-優恋里小扉 | 更新情報をチェックする

2023年12月15日

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

↓5)記稿.2023/12/15

> {2pass平均ビットレート:VAVバッファサイズ:VBV最大ビットレート};Psy-Trellis強度


 まず、2pass平均ビットレート比=1‥なのはそのままだが
 VBVバッファサイズとVBV最大ビットレートの関係を{1:4}に整える必要があった

 すると

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

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


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


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

 ‥ちなみに、最終的な10ビット→8ビット置き直し再生を調整するのはグラボ×ドライバーどえす
 HDMIを介して、モニター側とダイレクトにやりとりする仕組みだ‥そうです
 (なので、グラボによっては、モニターの違い以上に‥無残に見えるかも知れん‥)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 21:37 | Comment(0) | AVC-優恋里小扉 | 更新情報をチェックする

2023年12月11日

【エンコード日記】インターレースには、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‥)です

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

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


 ‥というわけで、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を附しつつ‥i解除エンコードせざるを得ないどえむ


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


 ‥通常はビットレート不足の際に、左右両端の数ドットを落として黒帯に置き換えるぽいのですが
 中には同じタイトルBDソース比較で、上下完全カットソースも見られます(どうなってんだよ?)
 (ビットレート不足で、全体の構成自体を差し替えてあるぽい‥謎)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 17:22 | Comment(0) | AVC-優恋里小扉 | 更新情報をチェックする

2023年12月09日

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


> ‥その両方を併せて試してみたところ
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 17:40 | Comment(0) | AVC-優恋里小扉 | 更新情報をチェックする

2023年12月07日

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

)記稿.2023/12/07

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


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

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

kuukannziku-sample.png


‥目玉に見える数ですよ

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

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

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

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


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

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


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


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


kuukannziku-sample_1472x1080.png
posted by 木田舎滝ゆる里 at 18:29 | Comment(0) | AVC-優恋里小扉 | 更新情報をチェックする

2023年12月06日

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

記稿.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)


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



posted by 木田舎滝ゆる里 at 14:13 | Comment(0) | AVC-優恋里小扉 | 更新情報をチェックする

2023年12月05日

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

記稿.2023/12/05

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


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

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

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


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


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

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


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

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

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

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


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


> {1:4:9}{Psy-Trellis強度(0.09)}から
> {1:9:16}{Psy-Trellis強度(0.25)}にビットレート謎比を変更した結果


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


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

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



posted by 木田舎滝ゆる里 at 19:37 | Comment(0) | AVC-優恋里小扉 | 更新情報をチェックする