【エンコード日記】ｉ解除に悩ましい要素を突きつけられてしまったｚ

記稿.2024/09/14

＞　ビットレート謎比が、↓とした解釈で落ち着きそうである


　デジタルソース16:9には、｛1：６：10：16.666666‥｝

　アナログソース4:3には、｛1：6.666666‥：11.111111‥：18.5185185185‥｝

　‥まぁ早い話が
　　VAV最大ビットレート×0.6＝VAVバッファ
　　VAVバッファ×0.6＝平均ビットレート
　　平均ビットレート＝マクロブロック基本数×６倍値もしくは6.666666倍値‥になる

　　（つまり、0.6の逆数が、1.666666‥なのさ）

　‥全部を6.666666倍値にしては、4GB以内に収まらない＆値が割り切れず
　　そもそもの６倍と6.666666‥倍の違いとは、アナログソース特有のノイズ分とした解釈だ
　　L4.1とL4.2としたマクロブロックの差を鑑みるにその様に扱う方が適切だと理解せり
　　（但し、2passエンコードにおいての内容になる）


＞　というところで、720×528と960×720が、有りになりました
＞　（黒帯を付けて六倍値を宛がうより、ずっと気が利いているどえす）


レベル５.2
　｛_8910：14850：24750｝　→　｛_9900：16500：27500｝
　｛11880：19800：33000｝
　｛16200：27000：45000｝　→　｛18000：30000：50000｝
　｛21600：36000：60000｝


＞　とまぁこれで完成だろうと煮詰まった所で、ｉ解除に悩ましい問題が持ち上がったｚ
＞　シールドシフトのみだと66.666％程度の解除率しか見せず
＞　エンコードが、とくに動きの激しいと判断した箇所は、櫛ノイズのままに見舞われている


　‥それを近くで見ずに、少し離れて確認すると
　　60枚構成とした其れが、錯覚にてインターレース解除に見えるのだ

　　スマホやタブレット等、画像が小さくなるのも同じ効果なのだから、それはそれだが
　　それにしても、それでさえ、88.888％ぐらいの解除率止まりで完全とは行かない
　　（但し、ソースの適正により問題なしとするケースも有り）

　　あと残りの頑固な櫛ノイズを抑え込もうとしたらそれこそ、ｉ解除フィルターを用いざるを得ず
　　だがしかし、折角にクッキリしてるのがボケてしまうのだ


　‥そりゃまぁ従来比で較べたらピカイチで良好な出来映えとしか言いようがないのだが
　　シールドシフトのみとした其れには、ソースのインターレース状態に近い写し取り状況があり
　　如何なる特殊効果が為されているかとしたお勉強には最適な状態なのら

　　（まぁそんなの関係ねぇジャンルの際には、併せてメディアンを用いるのが妥当です）

　　それのそもそもとして、キーフレームの入り方が全くに異なっている
　　シールドシフトのみとした其れの方が「倍増」なのら（どんだけ〜）

　　（半解除とした成り行きこそ、キー選択の際にかち合って、キーが倍増するらしい）
　　（結果的に、動きがよりクッキリと良さげに見えるのだ）


＞　ちなみに、「リニア混合」と「メディアン」との差だが


　‥アニメにおいては、誤差の範囲でその違いに気がつけるかと行ったら拡大ありきになる
　　細かいことを言うと
　　「リニア混合」は、横筋のトレースに有位を見せ
　　「メディアン」は、縦筋のトレースに有位を見せる

　‥一方の実写の場合、時折、YUVが横にずれたような印象の映像を見かける
　　そのようなｉ映像に対して、「リニア混合」を用いると途端にボケまくる
　　そういう意味では「メディアン」の方が安定的と言える

【エンコード日記】L41ｖｓL42としたマクロブロック差の適合性におったまげた件

記稿.2024/09/12

＞　PS5での再生は、レベル5.2まで＆音声AAC
＞　Android系の再生は、レベル4.2まで＆音声AAC


　‥そんなこんなで互換性云々にチャレンジしてみましたｚ

　まず、Baseline ProfileとMain Profileでは画質が整わん、無理ッ
　なので、High Profileのみになります

　当然、同じビットレートを割り振っても面白くないのだから縮めるべし


＞　そこで得たビットレート謎比が↓である


　｛１：３.6：６：１０｝
　｛1485：5346：8910：14850｝
　｛1980：7128：11880：19800｝
　｛2700：9720：16200：27000｝
　｛3600：12960：21600：36000｝‥25分モノで2.5GBぐらい


　フレームレートはオリジナル
　GOP長（60）
　参照枚数は（４）と（９）
　M.E.範囲は（８１）と（４９）
　ｐの重み付けは、スマート解析
　psy_rdは｛0.99：0.44｝と｛1.00：0.25｝


　‥で、奇怪な事に
　レベル4.1の一枚あたりマクロブロック数の最大（8192），秒間（245,760）
　レベル4.1の一枚あたりマクロブロック数の最大（8704），秒間（522,240）


＞　「一枚あたりのちっぱい差が何なのか？」とても謎だったのだが、違いを垣間見てしまったｚ


　‥大ざっぱな感触では
　　レベル4.1は、16：９制作のデジタル向きで
　　レベル4.2は、４：３のアナログ向きらしい（多分、アナログ・ノイズの増分に適正草）

　　‥４：３のアナログソースの際に激しいバンディングに見舞われるようなら
　　　そのちっぱいマクロブロック数の差がとても有効に作用してしまうのら

　（ちっぱいビットレートだと、60枚構成にしても改善効果はほぼ無きに等しいのに）
　（オリジナルフレームレートだと効果絶大って？？？‥‥なんとも云いようがないオチですな）
　（しかも黒帯を落とさずに付けたままの方が、微々たる差だが画質安定と圧縮効果を期待できる）


＞　そこで閃いてしまったのら、4：3の480ｉに黒帯を追加したらどうだろうか？
＞　（パディングで左右に120を追加）やってみたら、画質が上がるらしい


　‥なら
　｛1980：7128：11880：19800｝と｛3600：12960：21600：36000｝の二つで好いよね


　‥でも、折角、アナログ放送時の1.1倍にしたのに
　　16：9での全部盛りだから、わざわざ縦を縮めるようなオチなんだなぁこれが
　　なのに画質が上がってるって？？？‥‥謎すぎるのら‥（黒帯分からの割り当て増しは確実っぽ）

　　（×６倍ぐらいになると、そんなの関係ねぇ差だったのら）
　　（むしろ盛りすぎだったのら‥‥で↓に見舞われた草）

　しかも、ＶＬＣ再生時のｉ解除したように見えない問題までを一気に解決！（マジか★）
　（何らかの要素を加味すれば、×６倍時でもどうにかなりそうどえす）


　‥だがしかし、レベル4.2程度で60枚構成キュルキュル映像なんてとても無理ぅ
　　（AVCでのビットレート謎比には、マクロブロック間のバランスを整える効果があるのだぁ）
　　（それには、ある程度の距離感が求められるどえす）


＞　ちなみに音声のAACですが、Fraunhofer FDK AACが改善しており
＞　謎ALAC変換なんぞせずとも一発ＯＫに！‥‥（３８４）ぐらい‥
＞　でも、音質としては、ＡＣ３の方が好ましい（基本が32bitっすもん）

【エンコード日記】量子化DTCを用いると、weightp（2）と（1）とで、性格が全くに異なる

↓1)記稿.2024/09/06

＞　M.E.範囲（16）には、それだけでは欠陥を伴う課題点が付き纏う
＞　どうしたって、量子化済みソースに対する判定が覚束ないのら
＞　なので、それへの諸々とした対処に用意してあるのが、weightp（2）らしい


　‥weightp（2）を用いると、ノイズ感が減衰すると共に、
　　Psy-Trelli（1.00）でのまとまりが程良くなる‥（方向性であって完全無比に非ず）

　　weightp（1）でのPsy-RDとPsy-Trelliの比率にて見られた
　　大きすぎる値を用いずとも、想定内の値にて整然と収まる
　　（そのような想定に収まるように改善したのがスマート解析らしい）
　　（但し、量子化DTCを切ってしまっていては、効果の違いなど不明瞭なのら）


＞　とはいえ、M.E.範囲（49）もしくは、M.E.範囲（81）を併せて用いると
＞　M.E.範囲（16）では遠く及ばず、時短は無理と判明せり


　‥画質UPには繋がったので、そこはまぁ‥調査の甲斐は成った


＞　weightp（2）,可変ビットレート（100.0）
＞　Psy-RD：Psy-Trelli‥‥ｉ解除ソース向き｛4：1｝、プログレッシブソース向き｛2.25：1｝
＞　｛マクロブロック基本数：ビットレート：VAVバッファ：VAV最大値ビットレート｝
＞　GOP長：参照枚数


　1.00：0.25（ｉ解除ソース向き）　←→　0.99：0.44（プログレッシブソース向き）

　｛1：6：10：60｝
　｛1485：8910：14850：89100｝720×528
　｛1980：11880：19800：118800｝960×528
　｛2700：16200：27000：162000｝960×720
　｛3600：21600：36000：216000｝1280×720

　１５：9（ｉ解除ソース向き）　←→　６：４（プログレッシブソース向き）

---

　※　（1.00）を2.25で割ると割り切れないので、｛0.99:0.44｝とした
　　　気張って｛1.00：0.4444444｝として即打ち予約しても
　　　ビットレート的には（0.99）の方が、ぷち節約できて誤差も小さく都合が良いらしい


　※　×４の際の選択肢には二つある
　　　Psy-RD：Psy-Trelliのそれぞれ値を減らす方向と、GOP長を伸ばす方向だ
　　　ちなみに、Psy-RD：Psy-Trelliのそれぞれ値を減らして、適正におもぼしきは
　　　それぞれ｛0.72：0.18｝と｛0.72：0.32｝だが
　　　鬆が入って見えるマクロブロックが雑ざってきて輪郭感が下がる

　　　なので、GOP長（59）にせざるを得ぬ、参照枚数については双方そのままと判断した

　　HDテレビは、60i対応だけど60pは非対応で、720サイズの59.94p限度扱いどえす
　　なので、GOP長（60）ではちょっと怪しい‥一秒ごとにコマ落ちトラブルしたのでは堪らん‥

---

　1.00：0.25（ｉ解除ソース向き）　←→　0.99：0.44（プログレッシブソース向き）

　｛1：4：10：40｝
　｛1485：5940：14850：59400｝720×528
　｛1980：7920：19200：79200｝960×528
　｛2700：10800：27000：108000｝960×720
　｛3600：14400：36000：144000｝1280×720

　５９：9（ｉ解除ソース向き）　←→　５９：４（プログレッシブソース向き）


　｛6120：24480：61200：244800｝1440×1080
　｛8160：32640：81600：326400｝1920×1080　
↓/続きを読む/↓

【エンコード日記】謎比×Psy-RD×Psy-Trelliだけでｘ4倍,ｘ6倍の選択が可能に（調査中）

↓1)記稿.2024/09/04

＞　ｉ解除ソースは‥×４，×４.666666‥，×５.333333‥，×６の四段階
＞　プログレッシブソースは‥×４，×５，×６の三段階でのビットレート変更ができそうである


　‥容量低減としては、塩加減の差でしかないのだが、ノウハウは面白いかと
　‥静止画拡大してもほぼ似た処理度合いに仕上がる（誤差がまったくでないわけではない）

　※　先にお断りしておくが、この件の確認は「2passエンコード」時のみどえす
　　　「品質エンコード」ではとても難しいどえむ（やはり構造が違うのら）


＞　突然ですが、速報です
＞　インターレース解除がフィールドシフト一本でＯＫでしたん（マジか☆ぁ）


　‥インターレース解除のフィルターは、目障りに見えようと剥がせません
　　というバイアスからの必要なのかぁ‥でしたが、そのまんまにバイアスでした
　　まぁ確かに解除フィルターの選択の違いから多少の差を見せつけるのですが、それ程の差が無く
　　不思議に思っていましたが、不用でしたん（使わんとて解除できとるん）

　‥ああ、そうなると、（9801）なのか（99）なのかを再確認せなならん
　　でも、ざっくり（100）で打ち止め、（100）上等みたいな
　　再調整されてあるのか、DCTの様相なのか、100以上はプラシーボで誤差の範囲（マジか★ぁ）

　（まぁ容量の差とした反応はでますけどね、でも今や同じ値で打っても同じ容量になりゃしねぇし)
　（拡大で見ても、違うと言えば違うし、気のせいとして扱える誤差と言えばそれまでどえす）


＞　では、話を戻しましょう


Psy-RD：Psy-Trelli
｛マクロブロック基本数：ビットレート：VAVバッファ：VAV最大値ビットレート｝

1.00：0.25（ｉ解除ソース向き）　←→　0.81：0.36（プログレッシブソース向き）
｛1：4：10：40｝
｛1485：5940：14850：59400｝720×528
｛1980：7920：19200：79200｝960×528
｛2700：10800：27000：108000｝960×720
｛3600：14400：36000：144000｝1280×720

---

1.44：0.36（ｉ解除ソース向き）
｛1：4.666666‥：10：46.666666‥｝
｛1485：6930：14850：69300｝720×528
｛1980：9240：19200：92400｝960×528
｛2700：12600：27000：126000｝960×720
｛3600：16800：36000：168000｝1280×720

---

1.44：0.64（プログレッシブソース向き）
｛1：5：10：50｝
｛1485：7425：14850：74250｝720×528
｛1980：9900：19200：99000｝960×528
｛2700：13500：27000：135000｝960×720
｛3600：18000：36000：180000｝1280×720

---

1.96：0.49（ｉ解除ソース向き）
｛1：5.333333‥：10：53.333333‥｝
｛1485：7920：14850：79200｝720×528
｛1980：10560：19200：105600｝960×528
｛2700：14400：27000：144000｝960×720
｛3600：19200：36000：192000｝1280×720

---

2.56：0.64（ｉ解除ソース向き）　←→　2.25：1.00（プログレッシブソース向き）
｛1：6：10：60｝
｛1485：8910：14850：89100｝720×528
｛1980：11880：19800：118800｝960×528
｛2700：16200：27000：162000｝960×720
｛3600：21600：36000：216000｝1280×720


＞　ご覧の通り、Psy-RDとPsy-Trelliの値は、どちらもべき乗値です
＞　ｉ解除ソース向きは、｛4：1｝
＞　プログレッシブソース向きは｛2.25：1｝


　‥この二つの差は、インターレースの32×32マクロブロックの縛りにあるか否かにあるくさい
　　プログレッシブの場合は、1.5倍絡みの解像度を取るので、そのべき乗値適正なのだろうか‥
　　　　　　　　　　　　　　FHDの際にどう影響するのかは未確認
　　　　　　　　　　　　　　UHDに及ぶと、CUの用い方次第で中身が異なるようにも思われる

　‥うまい具合にべき乗値の差の間にハマっていることに気が付いて試してみたら
　　面白いほどにスマートにまるまる‥が、比率と値をずらすと癖が違って出る

　　映像の内容次第では、五段階も可能かも知れんが、所詮は塩加減の差しかねぇ
　　なのだから、ｘ4とｘ6のどちらかでしかないと思う


　‥VAVバッファがすべて10倍なのは、4×4マクロブロックをフル活用しているからであり
　　実質的には、多くても９倍ちょいも有れば良さげなのだが
　　ビットレートを下げてもそれ程に用途代わりしないくさいので
　　VAV最大値の算出も面倒くさいので、ザックリと10倍にしとります（覚えやすくて良い）


＞　M.E.範囲（16）×量子化DTCを用いると、一気にこうなりましたん（あれ？？？ェ）
＞　GOPの変更も、ｂフレームも要らんのやで（あれ？？？ェ）
＞　明らかに一昔前のAVCエンコーダーとは違ぇ‥と言わざるを得ず‥‥


　　((〇┓！あざ━━━━━す！┏○))
↓/続きを読む/↓

【エンコード日記】妖精さんにM.E.範囲（16）での画質UP魔法を教わりました（打ちミス由来）

記稿.2024/08/31

＞　45分ものドラマをどうにか4GBに押し込みたく
＞　｛1：6：10：60｝から
＞　｛1：４：６.666666：２６.666666｝とした変換比を思いついた


　‥↓計算すると、なんともすっきりと割り切れる値群だった

　　720×528｛1485：5940：9900：39600｝
　　960×528｛1980：7920：13200：52800｝
　　960×720｛2700：10800：18000：52800｝
　　1280×720｛3600：14400：24000：96000｝
　　1920×1080｛8160：32640：54400：218600｝
　　3840×2160｛32400：129600：216000：864000｝

　※ 塩HDは中止になりました


＞　使えそうだが、使えるかはまだ不明、それどころになくなった（↑調査中断）


　‥述べるまでもなく、M.E.範囲（81）は激重すぎるのでどうにかしたい
　　どうせｂフレームを試すのだから（36）ぐらいでええやろう試してみたら

　　‥短いGOP長において、量子化DTCを用いると
　　　ｂフレームも要らない子に成り下がってましたん（partitions allを含めど容量にて優れず）

　　ところが、脆弱化傾向なｂフレームの画質が、急に良に変わったので値を確認すると
　　Psy-Trellis強度（10.00）になってたん‥‥（どう打てばこうなる？？？）


＞　調べた結果、M.E.範囲とPsy-Trellis強度が反比例くさい関係を示すらしい
＞　（なんだかなんだと明度（Ｙ値）優先の造りなので、Psy-Trellis強度の方に影響が及ぶ草）


　‥M.E.範囲の値を上げると、明度がクッキリとする（白く飛んだような方向感）
　‥Psy-Trellis強度を有り得ねぇほど釣り上げると彩度がクッキリとする（色合いが濃くなる）

　　‥そんなこんなで、M.E.範囲の値を上げて、多重撮り箇所がクッキリしたのは
　　　明度が上がったからであり、其はとくに、白黒としたうっすら線画に対してのくっきりだった
　　　彩度に関しては効果が弱いままなのだから、映像全体としては今一つだったと判明せり


＞　クッキリとする印象としては、どちらも相互的に同じ効果を得るように見えるも
＞　其の中身は、全く異なるのだった‥‥orz


　　そして、Psy-Trellis強度の上限は（10.00）だった（これが打ちミスと化した理由らしい）
　　そんなこんなで、常識オーバーな値を（ヱ☆まじ大丈夫なの？？？）調査してみた

　‥Psy-RD強度（1.00）のままに、Psy-Trellis強度を釣り上げてもソースにより効果はまばらだ
　‥M.E.範囲（36）（25）（16）を比較すると
　　ソースに依っては、M.E.範囲（36）ではプチノイズが出やすく
　　M.E.範囲（25）では線ノイズ？‥としたよく判らない違いがポツポツとあり
　　やはりというかM.E.範囲（16）の方が安定的なのだが、丸くなりやすい嫌いがどうにも好かん
　‥Psy-Trellis強度（6.00）ぐらいが安定的に見えるも納得しかねる

　そこで品質モードに切り替えて調べてみると
　確かに、Psy-Trellis強度をオーバーな値にて使うと、CRF（10）が、CRF（0）ぐらいに見える
　CRF（12）でも、まだまだCRF（0）気分でイケそうだ（スゲーどうなってんだよ？？？）

　　だがしかし、CRF（18）のツラを見てピーンときてしまった
　　そこに生じた様々な歪みを綺麗にらしく取り払って取り繕ったのが2passでのそれだと

　そうなるともう、Psy-RD強度もオーバーにしてみようと食指が動く
　すると、Psy-RD強度とPsy-Trellis強度の｛1：1｝比は、それほどでもないと理解した‥orz
　さらに、Psy-RD強度の値を、Psy-Trellis強度の値が上回ると何かしらの歪みを得やすくなる

　　そうなるとあれだ、べき乗比としての｛9.00：4.00｝しかねぇ
　　やってみると、ビットレート効率が上がる傾向を見せり（画質も歪み感が減ったように思える）

　ところが、2passでは、あっという間に画質がCRF（18）染みて落ちる
　つまり、ビットレートの不均衡に見舞われるのだろう（さすがにそこは品質とは異なる草）
　其処で比率をそのままに｛2.25：1.00｝にしてみた‥‥まぁ常識的な域だろう‥‥


＞　ようやくにしてM.E.範囲（16）をモノにできそうである


　※　ｉ解除DVDソースの場合
　　M.E.範囲（25）と（16）の差は、DVD映像ではさすがにデータ量に無理があるのか
　（25）を用いると、特定の色合いが途端に削げる傾向を見せり（とくに黄色系発光色）

　※　ｉ解除BDソースの場合
　　トリニトロン管の映像が白く飛んでいたというかそういう色調だったので
　　M.E.範囲（25）に引きずられる（そういう違いに反応してたんだなぁと思わざるを得ず）


＞　まったくもって一生掛かっても気が付くことなき「そんな馬鹿な」な値を知ったのら
＞　ビットレート謎比の最大に合わせると‥そのぐらいでも釣り合うと言うことなのだろうか？？
＞　（まぁ平均FPSが息を吹き返したので、その辺どうでも好いです‥打ちミス妖精さん万歳!!!）


　‥そして知ってしまった、量子化DTCを用いると
　ｉ解除ソースとプログレッシブソースとでは、適正なGOP構成にも差があったのだった

　　ｉ解除ソース：GOP長（15）,参照枚数（９）
　　プログレッシブソース：GOP長（６）,参照枚数（４）


　‥更にHi10の適性が、それなりの長さのGOP構成に向いているのを確認した
　　そんなこんなで、優恋里小扉とも異なり
　　テレビUSB挿し×キュルキュルには、８ビットで十分だと理解したｚ

　　（まぁM.E.範囲（16）にしたので、GOPが短かろうと普通にHi10でも使えそうですけどね）

【エンコード日記】量子化DTCのここがこそ痛いッ

記稿.2024/08/27

＞　avidemuxにファイルを投げて、キュルキュルのベストな状態を確認したとて
＞　テレビUSB挿し側のサーチでは、必ずしもそのキーフレーム順を踏襲せずと判明す


　‥そのどうにも怪しい理由として、まずは指定してあるGOP長に合わせるくせぇ
　　GOP長より短すぎる構成の際は飛ばし
　　足し算するかのように、GOP長以上の位置にあるだろう次のキーフレームを選択するくせぇ
　　お陰で、テレビUSB挿しでのキュルキュル構成のはずがガタガタになる

　　（どちらかというと、30枚構成の際に、0.25秒か0.5秒刻みに固定した方が）
　　（第一速度にて、そのGOP長の間がスローな感じに再生される気がする）
　　（30枚構成なら、第二速度の度合いもまぁまぁイケるけど、24枚構成だとキツい）


　‥でも、AVCのソフトウェアエンコードでは、固定枚数は無理
　　（量子化DTC×ｂピラミッドならもしかしたら固定的になるのかも知れないが‥‥）
　　（どちらにしても、走る場面でのキュルキュル感はムズいだろう）

　　結果、GOP長（10）×参照枚数（4）だとキュルキュル感が、大幅に崩れてしまうのだ

　　只でさえキー爆ソース有りで、ビットレート割り当てがカツカツで怪しいのに
　　GOP長をより短くせなならんなどとは、もはやPsy-Trellis強度（1.00）を保持できねぇ
　　致し方ないので下げざるを得ず
　　（どんなGOP構成でも、キッチリ場面切れをこなしてしまう特性とやらも悩ましい限りだｙ）


＞　また別の話で‥GOP長（10）とした短いGOP構成に対して量子化DTCを有効にすると
＞　参照フレームMixが不要に成り下がる（唖然‥呆然‥そうなんだ‥‥）


　‥なので、より短く刻むとなると、もはや時間コストの無駄で、参照フレームMixは切って良し
　　（常に場面の端境で切れるから、画質感にムラ気がでねぇ趣で安定的なのだ）
　　（勿論、ビットレート不足は御法度です）

　　（いやはや、どうしてこうなった？？‥時間コスト半分だｚ半分ッ）

　　（どちらかがFHDサイズ補強仕様で‥HD、SDだと、どちらか片方で十分とか？？？）
　　（もしくは、精度が上がってきたので、もはや片方で十分に至ったとか？？？）

　‥こうなっては、後はもう‥Psy-Trellis強度のスライド感に委ねざるを得ず


＞　‥結果
＞　ｉ解除ソース：GOP長（６）×参照枚数（４）×Psy-Trellis強度（0.04）
＞　プログレッシブ：GOP長（６）×参照枚数（４）×Psy-Trellis強度（0.40）‥10倍？？？差‥


　※　Psy-RD強度は当然ながら（1.00）である

　‥Psy-Trellis強度（0.04）なんて、TFT液晶時代に判別できなかったに決まってる
　　なので、サクッと（0.00）になった草
　　（今どきは改善していて、ソースに依っては弄ってみるのもあり‥みたいな）

　　‥ちなみに、Psy-Trellis強度値は、４で割れる値の方が無難にまとまる傾向を見せり
　　　あとは、DTCの都合なのかは知らんが、べき乗と＋0.1単位になるっぽ
　　（べき乗の方はノイズ感も含めクッキリ寄りで、＋0.1単位の方はまるとする傾向を見せり）


　‥サクッと‥ｉ解除ソースとプログレッシブソースとで反応が異なる
　　放送規格とDVD規格は踏襲せる方針で似かよるけど、BDのプログレッシブとでは違うらしい
　　低周波の間引き方が違うことで、Psy-Trellis強度値の反応が随分と異なる
　‥それでなくてもｉ解除の場合は、フィールドシフトしちまってるから本体とは異なる
　　そこの違いが、どうにもテレビUSB挿しでのキュルキュル感に影響してるような気もするｚ

　　‥そもそも、十分にビットレートがあるだろう想定にてPsy-Trellis強度（1.00）を用いても
　　　フィルムグレインお残しが、解像度割り切れてる箇所優先に点在するのはどうにも萎えるｚ
　　（FHDとの印象差を縮めるためとは言え、プログレッシブソースのなんでそこだけ？‥みたいな）
　　（どうせなら、均等に潰れてしまう方がサッパリとした映像に見えるのだろう）
　　（そもそものテレビ放送の印象は、其処に位置するのだから‥‥）

---

　‥映画館でさえフィルムグレインなんて気にしたことねぇのに
　　いざフィルム映像をエンコードしようとすると、化学斑が無駄に気になるとか
　　或る意味で勘違いな論点なのかも知れないｚ
　‥一方で解像度を上げたくなるのは、フィルムグレインとかフィルム感とか関係ねぇし
　　ディテール感にしたって、如何にして間引くかにおいて結局は潰れるし、潰す方策になるし
　　クリアーにし過ぎてもそれはそれで、解像度任せの演算斑でしかねぇわけで
　　それでなくてもJPEGノイズは付き纏うのだから、ビットレートを気にせざるを得ず

---

＞　だがそれでも、テレビUSB挿しのキュルキュルはベストを示さず
＞　（場面に依っては、痛いままだｚ‥失敗してる恥ずかしい‥みたいな）


　‥まぁ、場面と場面を切り離して再構成編集する需要用途には、俄然問題なし
　　そっち向けだと‥より短いGOP長は有りなのら

　　‥何はともあれ量子化DTCを用いると
　　　GOP長が長くなればなるほど×参照枚数が増えるほど＝時間コスト膨大に‥
　　　なので、どうにか4GBに押し込みたい用途は別にして、GOP長の短いにこしたぁねのら

【エンコード日記】量子化DCTを効かすとGOP構成に再調整の用有り

記稿.2024/08/24

＞　量子化DCTを効かすとフィルムグレインお残し臭さが気になる（Level5.1ダウンコンHD）
＞　更に、GOP長が短すぎるとフィルムグレインお残し臭さがモヤッとして見苦しい（Level5.1同）


　‥そんなこんなで
　Level6.1としてマクロブロック分解能を上げると、フィルムグレインお残し臭さが遠のく
　（これは、マクロブロック分解能としては、Level5.1FHDサイズと等価に思うも‥‥）
　（釣り合わせるに適切なビットレート量がどのぐらいなのかについてはなんとも言えない）　


＞　GOP構成としては
＞　60枚構成に対して、GOP長（10）、参照枚数（4）が適正に落ち着く


　‥これは、量子化DCTの有効にて
　AMDエンコードの仕様に思われるシーン変更感度（40）と
　シンＱ郎でのシーン変更感度（89）との差が、参照枚数に現れた様にも思える（知らん）

　　AMDエンコードにて、キュルキュル寄せとなる「GOP長×0.6＝参照枚数」だと
　　どうしてもＩフレーム差の許容が広すぎてというか圧縮重視に傾き
　　GOPの尻に追加で詰め込む傾向が頑固でどうしようもねぇ

　　その点、シーン変更感度（89）はＩフレーム構成にそぐわないとスパッと切り落とす
　　結果的に、シーン変更感度（89）の方がシーン割り出しが適正だ
　　（といっても送り込めるキーフレームには、Levelにより適正枚数に上限があるらしい？？）


　‥更に、シーン変更感度（89）のまま、GOP長（15）と伸ばした場合
　　口パクに対する反応が減り、並びに、繰り返す場面においての間引きが顕著にでる
　　だが、流してあるだけの一過性な動き場面だと
　　Ｉフレーム分解能としての変わりばえは、ほぼ無いに等しい
　　（これは、わさb抜き×60枚増幅構成×2passの効果によるところが大に思われる）

　　‥ところが、GOP長（10）×参照枚数（4）×シーン変更感度（40）にすると
　　　似ていて非なるキー間引きを、まばらにしてくれゆぅうう‥‥orz


＞　やはりキュルキュルにするなら、シーン変更感度（89）なのら
＞　（だども、4：3アニメだと、10枚指定では、キュルっとせぬ箇所もあり‥orz）

---

＞　量子化DTCを用いると
＞　カラー優先度、行列係数、伝送特性の指定を剥がしても効果を見せずに復活する（仕様らしい）


　‥なので、サイズ変更等で併せてカラーの変更をしたい場合には、量子化DTCを切るしかない
　　それはそれで、GOP構成の変更の用を意味する
　　（ど忘れしそうで‥もどかしい、再確認の用有り‥‥時間コスト辛ぇｚ）

---

＞　量子化DCTを用いると
＞　場面切れの改善に難儀してたのがウソみたいに切れまくる


　‥そうなると、GOP構成を変えても場面切れからのカウント発生しかないので
　　短いGOP長のキーフレームとして手堅い場面切れ扱いもカウントされる所となり
　　もはやキー枚数を間引こうとしても、逆に難儀する傾向を見せり

　（こうなっては‥固定枚数なGOP‥とした考え方も自然体なんだなぁと思えり）


　‥更に量子化DTCを用いると
　　参照枚数を重ねるほどにエンコード時間が増し増しになる
　‥直感的に遮断して参照枚数実験をしていたのは或る意味で正解だったかも知れないが
　　場面切れとした課題は、不特定的で悩ましかったのだから、今となっては、なんとも言えない

　（Psy-Trellis強度＝1.00を効かせてあるのも絡んでいるように思えるも‥悩ましい限りだ）
　（画質の補正はテレビUSB挿しでカバーできるけど、五段階サーチはカバーしねぇからな）

【エンコード日記】巷に根強きGOP長（250）の数学的な裏付けとは？

↓2)記稿.2024/08/23

＞　24枚フィルムの一枚あたりの単純なカウントは、１÷２４＝0.041666‥である


　0.041666‥×1＝0.041666‥
　0.041666‥×2＝0.083333‥
　0.041666‥×3＝0.125
　0.041666‥×4＝0.16666‥
　0.041666‥×5＝0.208333‥
　0.041666‥×6＝0.245
　0.041666‥×7＝0.291666‥
　0.041666‥×8＝0.333333‥
　0.041666‥×9＝0.375
　0.041666‥×10＝0.416666‥
　0.041666‥×11＝0.458333‥
　0.041666‥×12＝0.5
　0.041666‥×13＝0.541666‥
　0.041666‥×14＝0.583333‥
　0.041666‥×15＝0.625
　0.041666‥×16＝0.666666‥
　0.041666‥×17＝0.708333‥
　0.041666‥×18＝0.75
　0.041666‥×19＝0.791666‥
　0.041666‥×20＝0.833333‥
　0.041666‥×21＝0.875
　0.041666‥×22＝0.916666‥
　0.041666‥×23＝0.958333‥
　0.041666‥×24＝1.0


＞　30枚フィルムの一枚あたりの単純なカウントは、１÷３０＝0.033333‥である


　0.033333‥1×30＝0.033333‥
　0.033333‥2×30＝0.066666‥
　0.033333‥3×30＝0.1
　0.033333‥4×30＝0.133333‥
　0.033333‥5×30＝0.166666‥
　0.033333‥6×30＝0.2
　0.033333‥7×30＝0.233333‥
　0.033333‥8×30＝0.266666‥
　0.033333‥9×30＝0.3
　0.033333‥10×30＝0.333333‥
　0.033333‥11×30＝0.366666‥
　0.033333‥12×30＝0.4
　0.033333‥13×30＝0.433333‥
　0.033333‥14×30＝0.466666‥
　0.033333‥15×30＝0.5
　0.033333‥16×30＝0.533333‥
　0.033333‥17×30＝0.566666‥
　0.033333‥18×30＝0.6
　0.033333‥19×30＝0.633333‥
　0.033333‥20×30＝0.666666‥
　0.033333‥21×30＝0.7
　0.033333‥22×30＝0.733333‥
　0.033333‥23×30＝0.766666‥
　0.033333‥24×30＝0.8
　0.033333‥25×30＝0.833333‥
　0.033333‥26×30＝0.866666‥
　0.033333‥27×30＝0.9
　0.033333‥28×30＝0.933333‥
　0.033333‥29×30＝0.966666‥
　0.033333‥30×30＝1.0


＞　↑こうして並べてみると、単純に３枚置きとした何かに人の感性が反応するくせぇ
＞　問答無用で、値の割り切れる方が、綺麗に見えやすいと言うことなのだろう


　そこで24枚構成での４枚に注目すると（0.1666‥）であり
　GOP長（10）参照枚数（4）だと、2.5倍差というところでピンと来ないのだが
　0.666‥と1.666‥が2.5倍差を示す
　で、1.666‥のべき乗が2.777‥であり、0.666‥で÷と4.1666‥倍を示す

　24枚構成の一枚の単純なカウントが0.041666‥秒であるのに対して
　いつの間にか割り切れる関係値を叩き出す
　それは24枚構成としては25枚目を指す（コンマ秒タイミングとしての実に100倍だ）


＞　なので、単純に更にその10倍である250枚目は、割り切れる立ち位置を得るのだ


　ちなみに、250÷2.777‥＝90を得る
　つまり、60枚構成×GOP長（25）×参照枚数（9）でも美麗にキュルキュルする可能性がある臭い


　‥偶然発見した適応タイトルが「映画 この素晴らしい世界に祝福を！紅伝説」だったりする

　　但し、AMDエンコードでの発見なので、GOP長固定枚数とした限定どえす
　　神業を見るかのように、欲しいキーカットが、常に欲しい所でドーンと入りけるのは気持ちいい

　　（だが残念な事に、幽霊キーが数枚ほど発生してしまうのが痛いッ）
↓/続きを読む/↓

【残暑見舞レシピ】爆速！バグ厭!!AMD幽霊フラッシュ!!!

↓2)記稿.2024/08/18

第一印象
｜トラウマを解消したき晩夏かな「爆速！爆誕!!AMDフラッシュ!!!」
｜あの日々が今や空蝉まっさらけ？？？‥AMDエンコードで涼新た？？？‥
｜夕焼けに爆Ｑぼっちの青春叫「まだまだ負げぢゃいねぇッ」
｜走り出すキュルキュル追いし「シンＱ郎」折れるも青春，伸ばすも青春

第二印象
｜試すほどフリーズキーのお化け居り「欠損フレームをキーにするべからず」
｜幽霊を退治するにもまずGOP「構成に主導権握りしはトライアンドエラーなり」
｜西日苦や成仏ソースを手にまほし「地雷フレームなぜにあるん？」
｜清浄を保つ道のり雲の峰「バグが売りなの？欠陥憑きが自慢なの？」

第三印象
｜可変にも量子化にもお化け居り「短いGOPには不向きどえむ」
｜お化け駆除、日の目を見るのもソース次第「どうしてこげなホラーを許すん？」
｜我慢して絵コンテ風なキー送り「それもありかな‥やっぱ嫌だ‥‥」
｜駆除るまで封印だからこの館「爆速！バグ厭!!AMD幽霊フラッシュ!!!」

　‥ダウンコンHDに糞時間が掛かるので
　トラウマになりそうなので、気分を変えてAMDエンコードを弄りだすとその度に「あら爆速！」

　　うれしくもあり、くやしくもあり。（ところが、こちらでも別のトラウマ要素と対峙せり）

　　‥まず、2passエンコードが不能なのだから、どうにもビットレート不足に落ちる草。
　　同じフレームのはずなのに、その手の判断が見られず、しっかり枚数分増量する。
　　（そんなこんなで、基本マクロブロック数×６倍からして通用しないのだ）


　‥スライスのお勉強で鬼門に落ち、半分興が冷めてるのに
　　普通にエンコードしても、幽霊キーフレームが居るんだよ。居ったとです。
　　（まさに、スライスのそれは前座だった‥‥orz）
　　（お勉強の手順としては、勘違いをやらかさずに理解が早く済んだにせよ、悩ましい）

　　‥推定できる要因に、まずビットレート量の割り当てが弱い点を指摘できる。
　　同じGOP構成のままでも、可変でビットレート量を上げると幽霊駆除に成功する場合がある。
　　そうかと思えば、低いQPを当てても改善しない場合もある。

　　問題フレームにキーフレームが宛がわれると、其のGOPだけがフリーズしたようにぶっ飛ぶ。
　　スライスの場合は、スライス位置だけで済む所だが、ここでは画面一枚に及んでぶっ飛ぶ。
　　キーフレームがぶっ飛ぶのだから、そこのGOPが丸ごと失敗に落ちる。

　　VLC再生の場合に反応を見せずとも、テレビUSB挿しの際には、見苦しいノイズに放たれます。

　　avidemuxに放り込んで、↑ボタンを押しっぱにしてサーチを掛けると
　　そのキーだけ灰表示になります。（事前に探せるっちゃ探せるのですが、見落とす場合も‥）


＞　‥どうにも犯人くせぇのは‥VAVバファが少ないからに思えるのですが‥どうなんでしょうね？
＞　（対応した有料アプリを使えば、細かくやれるらしい）
＞　（対応した有料アプリを使えば、細かくやれるらしい）


　‥追い打ちで、「AMD AMF」にて抽出した塩HDは、テレビUSB挿しでは上手に回らん。
　　画質がFHDよりに見えて好い感じなのに、構成次第で回らんのでは扱いづらいだけだ。
　　（シンＱ郎とは、明らかに内部構造を違えており、最大ビットレートの盛りすぎは使えない）


＞　では、参考までに「AMD AMF」の項目について述べておこう（要AMDのグラボ）
＞　言わずとも、五段階サーチ対応を目指して、テレビUSB挿し構成を狙う所ですが‥‥無理。


　‥ちなみに、AMD AMFのHEVC版もAVC版も項目が丸々同じどえす。
　　どうにもHEVCの内部サーチ機能を共有で利用しているみたいに思える。
　‥最終的には、HEVCはHEVC、AVCはAVCとした形式に仕上がりゃいいわけだし
　　指定したGOP長で固定した方が、配信する際の利便性は上がるだろうからな。　

　　（繰り返すが、対応した有料アプリを使えば、細かくやれるらしい）
　　（まぁそちらでも同じように幽霊屋敷だったら買い甲斐ねぇけどな）
↓/続きを読む/↓

【エンコード日記】リニア混合ｖｓメディアン

記稿.2024/08/17

＞　XMedia Recode 64bitの最新版（3.5.9.9）にしたら
＞　メディアン指定が弾かれて、リニア混合に戻される（固定か？仕様か？都合か？バグか？）


　‥しぶしぶ確認すると
　　AMDエンコードでは、裏数値が無いので
　　「メディアン指定、即、予約打ち」の手の残りにけり（問題なし）

　　‥だが「9801」打ち込み後、即予約打ちを必要とするシンＱ郎では使えず
　　　「99」に落とせ‥とでも言うのだろうか‥‥‥試してみたらそれでも行けそう（ヱ★マジ!?）


＞　さり気なく改善されてたと言うことだろうか？？？‥‥ありがとうございます‥‥m(_ _)m


　‥ついでに、AMDエンコードの画質特徴から気になったのがDCTの有効だった

　　なので、DTCをオンに切り替えたらクッキリ↑するなり‥なり‥‥なり‥‥‥（ヱ★マジ!?）
　　（そもそも、マクロブロックの対応型DTCをオンにしてるのに）
　　（量子化のDTCを切ってどうするみたいなボケだったｚ‥まったくのボケでした‥）

　　　間違っておりました、どうもすみません‥m(_ _)m‥です

　（だがしかし、画質は上がれど、時間コスト怪しいし、さらに爆Ｑ上げに貢献するし‥悩まし‥）
　（其れの爆Ｑ上げしてしまう要因に挙がるのが、Psy-Trellis強度=1.0に思われます）
　（調査手順としては、まぁ有りだったかもだけど、完全に見落としていたどえむ）


＞　更に、暑さボケから「Hi10」出ししてて「High」と比較したら、Highの方が圧縮率まさってた
＞　‥ヱ★マジ‥？？？‥‥


　（DCT有効恐るべし‥‥俺は一体どんなエンコードを試しているんだｙ）
　（まぁやはりというか、Hi10は‥広いM.E.範囲には未対応くさ）

　（もしかしてHi10とMp10との10ビット違いってそこなの、そこなんですかね？？）
　（Mp10では、その結果を、CU64とCU32に反映できるけど、Hi10では無理ッ‥みたいな）


＞　‥とかなんとか、AMDエンコードの方の調査もまだ終えていないというのに、先が長ぇｚ
＞　（AMDエンコードには幽霊が棲む！！！と叫びたい）
＞　（只今、AMDエンコード迷宮にてゴーストバスターやってます‥みたいな）