↓2)記稿.2025/08/22
＞ エンタメ作品なビッグタイトルにも成ると、話数が多すぎて、480ｐでも良いらしい
＞ （ヱヱ☆そうなの‥‥）
‥思った通り、カク付きパンなソースだった
気にいらんので再エンコードに挑戦してみた
＞ 640×480（1200） → 640×480
＞ ×9｛10800：30000：24300（2.25）｝30齣GOP長（15）
＞ 先読み，Syne Lockaheadともに（1000）
‥で、そのソースの場合だから知らんけど、1.666666‥倍ぐらいのファイルになるらしい
ソースは30フレームレートであり、29.97フレームレートに非ず
変更してしまうと、タイムスタンプが全部狂うのら（なんじゃそりゃ？？）
‥まぁそういうオチなので、同じ解像度、同じフレームレートを踏襲しつつ
カク付きパンを防止せなぁならん
どんなに頑張っても次に誤差の少ない解像度というたら、720ｐになる‥‥（無理）
とりま、お約束のREF（9）で、その辺は完結してるっぽい
あとは誤差を減らす作業なのだが
ソースが（2000）しかねぇのに、基本数の9倍は必要あるだろうか？
うんちく垂れると、多少長くなるのであとにするとして
‥それでも、その手の疑問は付き纏うのだが
大きく振っても、始めから満たないソースは満たないし
増やした分だけ追随してくるソースは始めからそういう作りにあるらしい
否、むしろ、特定場面に対してのみ有効だったりするのら
（なので、多めに設定しておいても問題は無いと考える）
（AMZNなんて、10000固定でざらに半分も満たないし‥‥不可解しいだろうアレ‥‥）
（まぁ著生の初期なビットレート謎比の方が、ずっと怪しかったけどな）
＞ 640×480プログレッシブは、他のソースとは中身が圧倒的に異なる
＞ それは、インターレースにありがちな内部1088拡張からの縮小にない点である
‥つまり、そのまんま1080ｐからの2.25分の一での480ｐなのら
解像度誤差を折り込んでいない状態こそが、640×480（4：3）縮小なのら
（1080と1088の間に巻き起こる誤差のことである）
なので、｛1：2.777777‥：2.25｝になる
VAV最大値を2.2666666‥比にしてしまうと、細かい部分での動きが全然変わっちゃうのら
（え、そんなに‥‥ほんのちょ微の違いに唖然とするのら‥‥）
（そんなちょ微で変わってしまう場面が生ずるともなると‥‥ビビるのら）
‥だがしかし、30ｐフレームレートでも、24枚構成からの30枚拡張がゆえに
拡張地点の齣に、稀に、部分的に、ほんのちょ微っと櫛ノイズが発生したりする
（だから、ビットレートが少ないとそうなるで草）
（ソースでそれだと、あとは踏襲するしかねぇ‥‥無理やると全体に影響する‥‥）
‥VLCプレイヤーだと解除し難いらしいが
テレビUSB挿しで見ると、櫛ノイズフィルターが効いて、無かった然なのら（ギリセーフ）
（もとい、やってる確認作業自体は、ほぼアウトなんだけど‥‥）
1-2)1
＞ ×9倍にすると、×8倍止まりソースとそうで無いのとが発覚する
＞ （そんなにもギリギリだったなら、ビットレート最大値で差が伴うで御座）
‥BD1080→480を試してみたところ
やたらとした誤差をどう折り込むか‥色々とやらかしたのだが
×9倍が限度と判断せり
その理由として、インタレースにて一気に高周波を残す場合と
再エンコードで再度取捨する場合との違いという奴で、低周波の残り具合のバランスが
BT.709とBT.601との端境が絡むのか、そこで、灰み黒みがすっ飛ぶらしい
（高輝度とした発色は良いのだけど、其れを支えるべき黒みが薄いので失敗するのら）
（解像度の隙間に灰みやら黒みを折り込めていない‥それが再度の際の縮小‥みたいな）
（それで720ｐ止まりとしたBT.709規格に及んだと云うことなのだろう）
（なら、BT.2020でも同じ様な解釈になり、今度は釣り合うモニターサイズが‥‥どんだけ‥）
＞ そこで、ある事に気が付いた
‥BD480にしたって、｛1：1.666666‥：1.5111111‥｝でやる方が良いのでは？
×9倍にすることで、GOP長を短くすれば辻褄が合うのでは？
だって、4：3ソースだけなんだし‥‥概ね、インターレースだし‥
試してみると、其れで十分に思えた
＞ 720×480（1350） → 720×528（1485），960×528（1980）
＞ ×9｛13365：22275：20196｝解除60齣GOP長（10），（15）
‥アナログ系はBT.601、デジタル系はBT.709とした差で
BT.601は長いGOP長には向かないが、BT.709はある程度長めのGOP長でもへっちゃら
とした差がどうにも付き纏う様である（解除60齣での話）
1-2)2
＞ 余談になるが
‥GOP長を短くする分キュルキュルするけど、テレビUSB挿しでは無理だった
どうにも、参照フレームMixを用いると、対象となるマクロブロック位置参照で崩れるっぽい
（アナログ系ソースには、其れが付き纏う）
ぶっちゃけ、カメラレンズの性能も含まれているせいもあるのだろう
昭和のカメラレンズの性能がどの程度だったかという所の理解云々くせぇのら
‥デジタルカメラの当初期の画素数からして大したことなかった
そこから画素数盛り盛り開発が目白押しとなり
その小さいレンズの性能を上げろとした競争だったわけだけど
当時の技術の水準は、大きなレンズからして４ｋにも及んじゃいねぇ感じで御座
（それが４ｋ映像のインパクトだよ）
映画撮影のお高いレンズでどうにか匹敵するのもあったかも‥ぐらいで
平均的なアニメスタジオのレンズぐらいになると、相当に落ちざるを得まい
（実写撮影との違いもあるかも知れん）
それでいて、フィルムの品質誤差やら劣化にまみれるとなっては
同じ様な齣に見えていても、中身は全然違った判定をするのがエンコードでござ
‥何が言いたいのかというと（レンズの個性もあるだろうけど‥抜きにして）
基本的なレンズ性能が
GOP長を長くする際のマクロブロックの共有効率に比例する‥‥とした予想なのら
レンズの性能差で、具合の良いマクロブロックが何処にあるのかに差が出るので
参照フレームMixが、比例した効果を発揮する‥‥予想でもある
＞ 極端な言い方をすると
‥あのスタジオではこれこれこの様なレンズだったので
エンコードの際にこんな具合とした癖がある‥‥みたいな説に及ぶのら
だがしかし、フィルムとの兼ね合いもあるので、レンズだけでの判断なんか無理
‥その点、デジタルアニメは、レンズなんか使わんのだから
マクロブロックの参照の仕方も、圧縮効率＆設定の次第で、マッチングも変わるわけで
100％場面で切れる構成なら、スローにキュルキュルできる可能性を有する
（それがなぜかは、レンズに付き纏うムラけが、はじめから０だからと予想する）
この予想から思うのは
だから、アナログ系アニメの場合はとくに、テレビUSB挿しでのキュルキュルサーチの際に
処理性能不足もろもろとムラが出て乱れやすい（どうにもなんねぇ‥みたいな）
‥あと、其れに準じた何らかの編集を加えている場合やら
ビットレートを盛れば盛るほどに膨らむ構成ソースの場合やら
とくに、場面毎の構成パーツの点数の差が激しかったりすぎるともなると
マクロブロックのMIX選択にリズムが乱れて
バランスの良いキュルキュルサーチには及ばない‥‥とした予想にもなろう
＞ まぁ、昔ビデオのジョグシャトルのような鑑賞までを目的に、制作かましてらんねぇけどな
