2022年01月26日

【エンコードレシピ】AVC-Q(金色立ちの二度揚げカツ版)

↓12)記稿.2021/09/19


金色立ちの二度揚げカツや春の風 夢はコックと駆け出しにけり
 

※ 金色立ち(きわだち)

> なんて美味しそうなきつね色なんだろう、それでいて衣はカラッと、中はジューシー
> あの味を自分でも手掛けてみたくてコックを目指した
> (もとい毎日食えるとしたらコックだろう‥とした食いしん坊発でもあったわけだけど)



 ‥今回レシピでとりあつかうソース解像度は、1080p,1080iになります
 とりあつかうダウンコンバート解像度は、576pのみです
 (720pや1080pへの応用にもなるので、ここらで576pでのきわまりとやらをまとめ置きます)


> では一次処理です


 ※ 一次処理の際、1080pは、23.976フレームが対象です
 (24pや29.97pものは、ここでは対象としません)
 インターレースは、29.97iをBob処理して、59.94フレームで扱います


 ‥XMedia Recodeにてmkvを選択
 Ut.video(コーデック)を選択
 1080pならフレームレートをオリジナルそのまま
 1080iならフレームレートをオリジナルから59.94に変更

 カラーモードを双方共に、YUV4:4:4Planar24bppに変更
 (※ここでGBRを選んではいけません、再エンコードなら特に、色ずれの原因と化します)


 ‥音声トラックは、好きにやって下さい
 (まぁこの段階なら無難にコピーでしょう)

 ‥クロップ/プレビューにて

 幅:3072‥(1920×1.6)
 縦:1728‥(1080×1.6)
(1.6倍は576pダウンコン専用なので、720p、1080pの際には別の拡大比を選びます)

 スケーリング:双三次スプライン
 ディザリング:自動
 アスペクト比:オリジナル


 ‥1080iならインタレース解除します(目のチェックを外す)

 使用するフィルター:Yadif
 モード:時間軸&空間軸のチェック(Bob)
 (※Bob指定そのものが、≒60フレーム化とセットです)
 順序:自動.


> 一次処理における444拡大とした目的は
> ソース解像度のままやりだすと、Bフレームの劣化になるのでそれの回避です


 ‥ここでの手法は、420jpg画像→420webPの際に、色劣化を避ける有効な技でもあります
 (その場合、ソース画像の解像度により、有効な444拡大比が多少変わってきます)


> 静止画とは違って、動画なので
> 一次ファイル作成時には、それなりに空きHDD容量が必須です
> そういう意味では、プロ仕様と申し上げても差し支えなく、手間暇が猛烈に掛かります


 (尚、一次処理したファイルは、VLCプレイヤーでの再生ができません)
 (なので、映像の状態を確認したい場合は、AviUtlに読み込ませるのが適当です)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 20:20 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年01月25日

【エンコード日記】マクロブロック全正方形化における弱点

記稿.2022/01/25

> マクロブロック全正方形化とは
> BDtsソース映像をシークバー移動させる際に、顕わになる正方形乱れのように
> 長方形パターンが現れない理想的なエンコード状態を指す


 ‥一般に、エンコードの理論上、長方形パターンのマクロブロックも使用される
 だが、ドット画の延長として論ずると、正方形パターンで固まっている方が美麗だ

 (IフレームからBフレームへと格子パターンを明け渡すにも無理が無く理想的だ)
 (明度とした観点からも、白黒でのトーンが、各々に異なっていて綺麗な印象の想定だ)
 (それのイメージに見せられるのも、タイル画に慣れ親しんできた遺伝子ゆえだろう)

 だが、普通に動画エンコードしてもそうにはならない
 そうする上での調整が欠かせないのだった


> ダウンコンバートの際のそれの調整法に辿り着いて知り得たのは
> BDtsソースにも稀に見られる‥32×32ぐらいの正方形での単色ブロック発生の理屈だった


 (いやいやいや、それは64×64かも知れない、表現上32×32としておく)

 単純に動かない映像ならそれは目立たない
 だが、激しく動いているほどそいつは目立つ
 演算の果てに起こりえた偶然とした大正方形ブロックの発生は
 全体の圧縮がギリギリであったなら、もはや調整が付かずそのままにせざるを得ない


> 例:アニメ「A.I.C.O. Incarnation」OP


 ‥OPの冒頭シーンにおいて、光の波が中央から押し寄せてくる演出があるのだが
 その中になぜか、明らかに単色ブロックと化した一つのブロックが押し流されてくる(左上部)

 (つまり、全体が正方形でしか表現されない演算値の場合)
 (奇遇にも隣り合う四隅同士が同じ色で表現された場合には避けられない結果になる)
 (それでなくても、BDの圧縮を稼ぐのにそれの確率を高めてしまう技術がある)

 (それが、Bフレームモードの空間軸×参照フレームMixだ)
 (つまり、Bフレームモードの時間軸とは、それを緩和させる上での打開案だったかも‥)
 (だが時間軸は、GOPやBフレーム枚数が長くなるほどに副作用ですり込み残像をやらかす)


 ※ ちなみに、このソースは、BDにも関わらずGOPを三枚で構成してあったりするので
 ビットレート不足かと思っていたのだが、それを否定する別のソースを発見した


> 例:アニメ化物語OP「帰り道」


 ‥このOPの中途に、八九寺 真宵が傘をさして歩いているところに
 雨雲が切れて光が射すのを見上げるカットがあるのだが(真横アングル)

 その場面の右上全体で、どうにも
 32×32のブロックの単色とした塊が群れをなしていたことが判明

 普通にエンコードしているだけではよく分からなかったのだが
 正方形化になるように調整を得た途端に

 ソースの状態を踏襲し、576pとした解像度ゆえに
 32×32としたマクロブロックがデカデカと目立ち
 それが、雲間から光が射すとした演出上
 カクカクとしたフェード調に動いてくれちゃってるのだ

 (どのように調整しようとも如何ともし難く‥なんというジレンマ‥)
 (Bフレームモードを切ってあるのにこの始末だよ)
 (だが、サクッと再生支援機能を用いた再生をすると許容の範囲に落ち着く)
 (テレビUSB挿しだと、もうちょっと綺麗めに調整されて、気にする程には無いらしい)


 ‥つまり、今までの実験エンコードでは、単色の幅がより大きく拡がっただけで
 動かないレベルになっていただけだった可能性が高い(ほへ〜)


 ※ ちなみにこのソースは、ref(2)であるので
 ref(4)にする際の参照が変わるので、動きとしてのそれがより誇張されてしまうのだろう
 だが、ref(2)でやろうと、ref(3)でやろうと、改善することは無いのだった
 ぶっちゃけ、ref(4)が一番に無難に見える


> ということが起こり得るのが、マクロブロック全正方形化による弱点ということである



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

2022年01月24日

【エンコード日記】4kのHDR技術は、インターレースの代替と考えられるという事で‥

記稿.2022/01/24

> インターレース映像の特色は、より多くの高周波を残すことだ


 ‥ゆえに、1080i映像をインターレース解除して
 プログレッシブ化の際に、GOPを少しばかり伸ばしても
 それほどに色の高輝度発色とした面での劣化を感じないが

 1080pに対しても同じようにやらかすと、途端に色の発色の劣化を感じる

 ‥単純に、HEVCの場合
 GOPを伸ばして圧縮を稼いでるところがあるので
 HDRとした技術対応が求められた‥という事に思われる


> ‥これを逆算して語ると
> 4k≒24フレームをFHDにダウンコンバートする場合には
> インターレースにしてしまった方が、発色とした面では有利という事だろう


 なので、bフレーム(4)、ref(8)、GOP(12)とした形も
 Bob処理した≒60フレームには有効だが

 ‥其を真似て
 bフレーム(3)、ref(6)、GOP(9)とした構成で
 ≒24フレームソースを再エンコードしても
 bフレーム(3)、ref(4)、GOP(5)とした型ハメより、発色の劣化を見るのがオチだった


> と言うところで、上の二つを比べると


 ‥bフレーム(3)、ref(4)、GOP(5)にしても
 すべてのpフレームが、Iフレームを参照しやすいようにしてあるという点には有利でも
 bフレームへの橋渡しとした面では、多少なりとも調整の余地があったように思えた

 ‥で、アイデアとしてぶち込んだ
 576p→qcomp(0.32)
 720p→qcomp(0.4)とした内容が、その際に役不足になる事が分かった

 そこで導き出した計算が
 qcomp値を、1080解像度から444拡大した比率から
 直に、1080→576比,1080→720比で割ってしまう案である

 0.6×1.6÷1.875=0.512
 0.6×1.333‥÷1.5=0.5333333


> まず、プログレッシブソースを、3072×1728→1024×576で試してみたところ
> ちなみに、{CRF:qpmin}は、容量的に{6:9}である


 ‥それの静止画を取り出して拡大すると
 長方形のマクロブロックパターンが、ぱっと見で見られなくなり
 変わって、正方形としたマクロブロックパターンだらけが目に付くようになった
 (この変化には驚きだ)
 ‥それは、まるでBDのプログレッシブ映像を止めて、シークバー移動した際に生じる
 正方形とした格子乱れのアレのような有り様になっていた
 (まさに求めていた格子の有り様じゃなイカ)

 ‥して、どうにもこのような正方形だらけの格子の形状を得るようになって
 ようやくに、完全なるシネマ対応になるらしい(なんだか別物に見えるんスよね)

 (そういう事なのかよ、おいッ)



posted by 木田舎滝ゆる里 at 15:11 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年01月23日

【インターレース解除】Bob≒60フレームのGOP構成を見直した結果、驚き画質を得た件

記稿.2022/01/23

> プログレッシブ≒24フレームのbフレームを増やすと
> テレビUSB挿し時に、部分的に回らないソースがあるので使えないのだが
> Bob≒60フレームの場合は、思いのほか何でもない


 ‥これは、すでに≒60フレームに構成済みの分
 再生中に再構成をやらなくて良いとした差に思える

 ‥で、bフレームを
 3の倍数分増やすと良いなどと言う情報が一人歩きしているようなのだが
 6枚にしてみても、キュルキュルとしての位置決定に悩ましいだけだし

 refの枚数にしても、一番に激しい動きを見せるパンでさえ
 GOP幅を12枚指定で固定していると、pフレーム7枚程度が良いところで
 せいぜい8枚と言ったところだ


> なので、bフレーム(4)、ref(8)、GOP(12)とした形が良いのでは‥


 ‥3の倍数やらが気になったのでググってみたら、ここだった
 目を通すと、bフレームとref値の比率についても述べている
 ちょうど、1対2が良いとある
 (どちらかというと、3の倍数の方がやっつけくさい発言だった)


> なら、プログレッシブ≒24フレームでは
> bフレーム(3)、ref(6)、GOP(9)とした構成も有りだな


 ‥で、他の意見での裏付けを得たところで
 まだ試してみたいアイデアがあったので組み込んでみた

 qcompの値について、1080解像度でのデフォルトが(0.6)で
 それを、1.6倍して、3分の1にするんだから
 密度としては、0.6×1.6÷3=0.32‥としたところなのではないだろうか?
 なら、0.6×1.333‥÷2=0.4としたところにもなる

 576p→qcomp(0.32)
 720p→qcomp(0.4)


> だがしかし、最適なCRF値については不明なのでそこはまぁ出してみるしかない


 ‥とりあえず、1080i→576pで試してみたところ
 今までのエンコードを置き去りにして、一目瞭然たるぶっちぎりの画質を得た


 ‥アニメの場合は、圧倒的に2:3なのだが
 ‥実写の場合は、6:9で間に合う
 (というか実写で、2:3だとソース容量にほぼ拮抗する傾向だ)
 (6:9にすれば、3割減は余裕だ‥Bob≒60フレームなのに随分と縮む)
 (デジタル実写の1080iからだと、2:3と6:9の差なんてほとんど分からない)
 (違いが出たのは、BD北の国からだった‥やはりというかDVDのアプコンくさい)
 (同じ技術要領のままにやらかしてりゃ、似たような仕上がりと言うことかも知れないな)

 ‥仕上がった1080i→576p実写映像をコマ出しして抜き出すと
 絵画の筆遣いの参考に成るぐらいにクッキリと量子化されてある
 (されすぎてるのではと思うところもあるが、まぁ576pだし、そのぐらいで丁度良いのだろう)


> ここに来て画質が猛烈に上がるとは、不覚としか言いようがないz‥
> (申し訳ございませんでした)m(_ _)m



posted by 木田舎滝ゆる里 at 21:41 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年01月21日

【エンコード日記】ダウンコン720p最適化444拡大解像度がなんと‥

記稿.2022/01/21

> それは、1920×1080の縦横比1.333‥倍である
> 2560×1440だった


 ‥HDテレビの解像度は、1366×768である
 これは、576pと相性が良い
 当然、ダウンコン576p最適化444拡大解像度である
 3072×1728とも相性が良い

 ‥ところが、720pともなると
 1080pの縮小表示とは異なり、ぷち拡大とした768pへの置き換えである
 (どう考えたってうまく行きそうになかったのだ)


 ‥でも、どちらともに、1080pとの相性は良いので、1.5倍がダメなら
 (10ビットは、10ビット対応モニターにないと正しく評価できません)
 その下はどうなのか?ということで、1.333‥倍を試してみた

 すると、me_range(32)を得る

 1920×1080 → me_range(16)‥FHD
 2560×1440 → me_range(32)‥ダウンコンHD
 3072×1728 → me_range(48)‥ダウンコン576

 ‥としたバランスが良いらしい(なんという奇遇の並び)


> いろいろといじってみても、画質としては安定的だ


 ‥だがしかし、今まで積み重ねてきた内容を盛り込むと、半端なく増量する
 25分モノ4GB限度ギリギリまで下げたつもりでも
 レベル6で、VLCでの再生中に、マクロブロック落ちが発生し(≒24フレームソース)
 テレビUSB挿しで、帯域超過によるコマ落ちが発生し(Bob処理≒60フレームソース)
 i実写ソースなんか、問答無用で増量する

 (これはこれで、720pに見られるエンコードらしき確かな手応えなのだが)

 もはやキュルキュル規格として成り立つのは、576pしかない
 もはやキュルキュル規格として成り立つのは、576pしかない


> めんどくせえから2パスという案にしても
> ≒60フレームものに、どれだけ割り当てりゃヱヱんじゃ?



posted by 木田舎滝ゆる里 at 21:35 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年01月19日

【エンコード日記】Uncompressed44410bitを試してみた件

記稿.2022/01/19

> 576pにダウンコンバートすると、BT.709→BT.601に色構成が変更されるわけだが
> それは、それを意識して色選択してあるアニメでは、それ程の変化は無い
> だが、そうでないタイトルの場合は、変わるところが出てしまうのは避けられない


 ‥なにぶんにも、1080解像度の1.5倍444で、不足するとした課題を解決すべく
 576pに特化して3072×1728とした解像度にしてみたわけだが

 (ここで新たに)

 XMedia Recodeのmkvのエンコーダー選択の中に
 Uncompressed 4:4:4 10bitとなるものの備えを見つけた

 8ビット→10ビットで1次出しすれば、1.25倍の情報増を期待できる
 つまりそれは
 2880×1620→3600×2025に比類するかもしれない
 (3600×2025は、720pに特化した時の2.28125倍であり)
 (2880×1620からの1.25倍でもある)
 (なので、BT.709とBT.2020の端境とした怪しさを避ける意味でも)
 (それの代替として、1.5倍444を10ビットにして試してみる事にした)


> ところが、このUncompressed 4:4:4 10bitの解像度変更がおかしい!!!
> 具体的には縦解像度指定がずれて登録されてしまう(まぁバグだろう)


 ‥このジレンマを解決すべく手法が
 まずUt.videoにて、エンコード設定して、リストに登録
 その後、Uncompressed 4:4:4 10bitに切り替えて、設定後、リストに登録
 先に登録したUt.video指定をリストから削除

 (で、どうにか縦解像度の指定値のそっぽをなだめすかすことができる)
 (逐一それの繰り返しなので、悶絶ッすね‥使えないよりは良し‥)


 ‥で、まぁ、悩ましいのが
 Ut.videoでの8ビット出しより、一次ファイルがほぼ倍になる点である
 (作業専用の大容量HDDが必須だ)
 (1080iをBob処理したアニメOP&EDの90秒で、概ね100GB平均だ)
 (Ut.videoと違って、黒帯があるからその分縮むとか関係ねぇ)


> 結果、720pが息を吹き返すのは良いのだが‥


 ‥CRF値に対して、qcomp値のバランスの加減がムズくなっている
 十分なCRF値にあっても、10ビットから8ビットに置き換わる時に
 変な間引きが入ってくると、階調ずれが発生するらしく

 タイルが剥がれているかのような、色はがれが発生していたりする
 その反対に、過大な割り当てには、色太りらしきも発生する

 なので、安全策として
 qcomp(0.6)〜(0.7)の範囲でしか使えないっぽ


 ‥さらに
 折角なので、Hi10 420を試みたところ
 その場合には、ますます‥qcomp(0.6)の方が良いみたい


 ‥それの短い576pのHi10リップを、テレビUSB挿ししたら
 ものすごい三色カラーずれを起こしつつ回った
 あすこが4x4くさくて、あすこが8x8なんだ‥というのが一目瞭然で唖然とした

 見る限り、4x4にしても8x8にしても%制限が掛けられているみたいな感じなんだな
 特定要件を満たさないと16x16のままって感じなんだな

 (いやいやいや、4KテレビならHi10でも回りそう)
 (Mp10回してんだから、回るに決まってる)


> ‥となると、こちらは、そういう需要向けになりそうである



posted by 木田舎滝ゆる里 at 21:48 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年01月18日

【エンコード日記】CRF値を下げてもビットレートが増えるとは限らない件

記稿.2022/01/18

> ↓の表図をご覧下さい
> 行はqcomp値、列はCRF値になっとります
> mbtree(ON)、但しcomp(1.0)は自動的に(off)
> 基準点とは、所謂、デフォルトとされる量子化具合と同じだろうと思われる想定です


  (00)(01)(02)(03)(04)(05)(06)(07)(08)(09)(10)
18  −   −   −   −   −   −  基準点  ↓   ↓   ↓   ↓
16  −   −   −   −   −  基準点  ↓   ↓   ↓   ↓   ↓
14  −   −   −   −  基準点  ↓   ↓   ↓   ↓   ↓   ↓
12  −   −   −  基準点  ↓   ↓   ↓   ↓   ↓   ↓   ↓
10  −   −  基準点  ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓
08  −  基準点  ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓
06 基準点  ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓
04  ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓
02 DVD  ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓   ↓



 ‥DVDというのは
 キュルキュル576pにして、DVD再エンコードの際に、似せる為のポジションです
 単純に、解像度が小さいほど、量子化の度合いがそれぐらいになるという事です

 (言わずとも)

 ‥qcomp値を下げるとボケます
 ‥CRF値を下げると、ビットレートの割り振りが上がるので、量子化がその分密になります
 その時、ビットレートが上がるので、色がしっかりと強く出るという事でもあります

 (ちなみに)

 qcomp(0.8)とqcomp(1.0)には、風合いの多くに、差が無かったりします
 qcomp(0.1)〜(0.4)は大抵、スカな状態の量子がチラホラしてたりします
 qcomp(0.9)は、分かりにくいので、ほぼ使われていないように思われます

 (なので)

 mbtree(ON)で使えるqcomp値は、(0.5)〜(0.8)の間です
 さらに、(暗いシーンのバイアスを自動分散)を使用する場合
 コンマ2桁目以降を打ち込んでも良いことは無いでしょう


> で、話を戻しますと
> 基準点の並ぶように斜め左下に移動させると、ビットレートが減る傾向にあります


 (いやぁ減るんですよね、不思議ですよね、知らないだなんて大損だと思います)
 (qcomp値の割り振りの方が大きいのかも知れませんが、今のところ謎めいています)


> でさらに


 わさb抜きでの量子化の良く出るところと、そうで無いところとがあり
 条件を変えるとまったく違ってきたりします
 その条件の一つに、拡大444をやらかす比率がそれになります

 拡大する比率を変えるとレシピが変わってくるんです
 さらに、エンコード指定する解像度によっても変わってくるんです
 (いやはやもう大変です)

 拡大444の比率が違うと、インターレースとプログレッシブでの適値が変わったりします
 どちらかというとインターレース解除に見合う値は、プログレッシブでもイケるようですが
 増量感に耐えられなかったりします

 (CRF値を上げたのに増量しちゃった‥などというジレンマ‥謎っす)
 (そりゃもう、444拡大比を変えてみるより他ないと)



posted by 木田舎滝ゆる里 at 21:40 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年01月17日

【エンコード日記】暗いシーンのバイアスを自動分散について

改稿.2022/01/18...20220117...

> シネマモード対応にエンコードするには
> AQ設定「暗いシーンのバイアスを自動分散」を正しく使う必要があります


 ‥これがとてもクセが強い
 一般に、ケチケチしたビットレートでは、その威力を発揮しません
 (そんなエンコードでは、ダイナミックモード視聴の一択でしょう)


 ‥そこでビットレートを上げようとも
 まだケチケチと、GOPを長くしたり、Bフレームを多くしたりと
 工夫を諦めずにやらかしてしまうわけですが


> どうにも特定の推奨値を満たさないことには、業界の要望する明度適応を得られないようです


 ‥≒24フレーム576pで云えば、ref(4)に対して、GOP構成はkeyint(5)まで
 (そこから、多くしようとも、視るに堪えない始末にハマる)

 ‥さらに、{CRF:qpmin}=10:15の最適解が
 {6.6666666:10}からはみ出せない&量子化圧縮(0.6),MB-Tree(オン),わさb入り
 {6:9}からはみ出せない&量子化圧縮(0.5),MB-Tree(オン),わさb入り

 ‥なので、576pにてキュルキュルとシネマモード対応に仕上げるなら一択でしかない
 (他にもあるかもだが、知らん‥というか無理っぽ‥)
 (ほぼMAX攻めでも、なんとか及第点みたいな)

 ‥やはり、スタンダードな放送規格に沿うのが解みたいだな(そこだけはさすがNHK)
 (ぶっちゃけ、圧縮率上げたかったら、1440×1080iの方が無難とか何とか)
 (なので、576p25分モノで、4GBを超えちゃったら、しれっと720×576しかねぇ)


> 正しいレベルで、シネマモード対応になると、ダイナミックモードでも画質が上がる
> (条件を満たすのが手厳しいスキルGETみたいな)


 ‥どのような差が起こるのかというと
 ソースでさえカク付いていて
 どうやろうともカク付いていたパンシーンで、カク付きが見られなくなる(ケースバイケース)
 (もともとの割り当てが多いのだとしても、おののくz)

 10ビット化すると明るくなると言われているぐらいに
 明るい箇所でも、さらにクッキリと仕上がる
 (これについてはどちらかというと、{6.6666666:10}{6:9}とのコンボ効果らしい)

 発光表現の輝度差に、色の端境が潰れがちな箇所の動きが、すっきりと明瞭になる


 ‥アニメの主線など、576pでは、4k拡大するとぼやけてしまいがちだが
 きっちりエッジ強調されて、ボケずに頑張るように変わる
 (この場合、{6.6666666:10}{6:9}の効果が合わせ技になっている)

 ‥大抵は周囲の色を巻き込んでボケてしまいがちだが
 比率が正しいと周囲の色がボケない、褪せずに同色を保つ
 色としての面がまずボケないというのが重要で
 ここが整ってないと主線だけ頑張っても意味が無い


 ‥実写の1080iをリップして、拡大して覗くと雲泥の差におののく
 (なので、諸々と理解してしまうと、もはや外すとした選択肢が1ミリも浮かばない)


> 効かすことでの増量は、平均で.8%増ぐらい
> 但し、暗がりの多い場面の他に、動かす物体が多いのもアウトで
> それでの増量は、12%増ぐらいなる(ジブリなんかクソ怪しいz)
> その一方で、ガンダムシリーズは、謎の値を示す(ほぼ影響しないくさい)


 ‥これの差を、AQ強度の調整でやらかしてきたという事実に驚く
 (どうにも、Psy-Trelis強度の代替技術に思える)

 ‥全体の明度を最適化するのに
 マクロブロック単位で分散調整するという事は、全体にそれ用のフィルターを掛けてるはず‥
 そこから得た段階毎に、AQ強度の値をマクロブロック毎に自動分散するという事なのだろう

 (明るいところの平板さと、暗いところの平板さの比率が異なっているとした着目らしい)
 (つまりそれって、使えるマクロブロック数の多いにこしたこたぁないって話だな)
 (Bフレームのモードにしたって、使わない方が安定的って事だよな)


> このような案件を
> 「バイアス‥」などと言う言葉で表現してあるのは、翻訳の不適切に思うわけだが‥


 ‥「明度に最適化自動分散」でヱヱじゃき
 でもそれもなぁ、条件次第だからなあ‥意味ありげに示すとすればバイアスってか‥
 (バイアスとは、あなた次第の加減でどうぞくせぇ)



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

【エンコード日記】1080映像の444拡大が、1.5倍では足りなかった件

記稿.2022/01/17

> 1920×1080解像度を1.5倍にすると
> 2880×1620になる


 ‥だが不思議なことに、この1.5倍の拡大サイズから
 720pと576pにダウンコンバートすると、同じにしか見えない

 それどころか、動きとしては、576pの方がしっくり来る‥


 この理由を探ってみると

 1620÷720=2.25
 1620÷576=2.8125

 2.25×16=36
 2.8125×16=45

 36×45=1620

 つまり、お互いのマクロブロックの数で、元映像を割り切れてしまうのだ
 (元々は、1920×1080なのに、実に不思議だ)
 (理想的な思い込み想像なら、同じは当然で、それが‥示されてしまったとかなんとか‥)


> そこで、720pと576pの差を得るには、もう少し拡大してやる必要があるらしい
> だが、1080pとを合わせた手頃に割り切れる拡大比はもはや4kサイズしかない


 (いやいやいや、4kサイズ作業はキツいっすから)

 そこで、まずは576p特化を狙って、どうにも1.6倍で試してみた
 3072×1728である(1024×576の三倍値だ)
 なので、M.E.範囲(48)が、マクロブロック比に丁度よい

 そしたらこれが大当たりで、動画エンコードの奥深さを思い知るに至った


> なら同じく、720pの三倍値に当たる4kサイズからのダウンコンバートなら
> もっと品質が上がるだろうと思いきや、これがどこかしっくりとこない


 ‥これがどうにも
 720pが、BT.601とBT.709の端境点にあるという事に起因するらしい

 思うに

 BT.709とBT.2020の端境点が、どこかとした情報は無いにせよ
 どうにも、1728p〜2160pの間にあるくさく
 それの割り切れなさとしたグデグデがまとわりついてくる感じなのだろう

 (カラーで考えるとそんなことがあるのかと思うわけだが)
 (白黒階調で考えると、なんとなく想像できようか‥)
 (RGBの階調が、足並み不揃いの領域みたいな‥もといYUVだったな‥)


 ‥そう考えると
 双方の最大となる豊富な色域から
 存分に拾えてくる‥1728p→576pとした変更の方が、無理がでないらしい


> 実に、これが576pなのかと思える程の変貌ぶりに
> こう言わざるを得なくなっている


 ‥720pの選択支は、死んだも同然だ‥



posted by 木田舎滝ゆる里 at 04:46 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年01月16日

【エンコード日記】480i三度揚げの件

記稿.2022/01/16

> 480iの再エンコードの手順として
> 全部盛りなどということをやらかすための数値を、著生は紹介しているわけだが


 ‥XMedia Recodeプラグインの解像度変更を利用しての
 エンコードでは、不十分だったことが判明


 ‥どうにも圧縮がたらんので
 1474×1080,1964×1080から1920×1080に仕切り直す時
 その仕切り直しをさらに、ut.videoで揚げてみたところ

 それの二度揚げから三度揚げを試みた方が、圧縮力が上がるらしい


> さすがに手間なので、先送りしている


 ‥ちょっと謎なのだが
 XMedia Recodeプラグインがまともに機能していたら
 先読みの枚数分だけメモリーをきっちり消費していないとおかしいのだから
 まぁなんとなくそこは、デフォルトの40枚構成でのエンコードだったくさっ

 (あくまで妄想の域なんだけど)
 (それが実際だとしたら、先読みが大きい方が圧縮力が高いとかなんとかの証明になりかねない)

 (いやいやいや、それにしては、別物のように圧縮力が上がるのは不可解しい)


 ‥480iぐらいの解像度だと、ちょっとやそっとの解像度変更やらかしでは
 それほどに誤差を見せないようだから、うれしいと思うべきだろうか?


> で、話は変わるが
> XMedia Recode 3.5.4.8がいろいろとバグっているのか、なんどすかあれ
> 直ぐに落ちるんですけど



posted by 木田舎滝ゆる里 at 00:29 | Comment(0) | AVC-Q | 更新情報をチェックする