記稿.2022/01/31
＞ ‥前記事の続きで、今回→M.E.範囲（96）
＞ CRF（12.0），qpmin（9），qcomp（0.8）
＞ 444拡大4ｋからの720ｐダウンコンバートの際、色み対策としてBT.709指定を入れておこう
‥ｂフレーム（3），ref（6），GOP（9）だと
ソースがref（4）からの変更の際に相性がよろしくないのか
イレギュラーな形でマクロブロック参照が起きるらしく
結果、ノイズのような形状を算出することがある
（だからといって、ｂフレーム（3），ref（4），GOP（5）を用いても）
（綺麗に出せるのは、どうにも‥CRF（6.0）水準らしいので）
（それをやると、1080ｐソースと変わらないぐらいに容量肥大やらかすので）
（もはや720ｐ調整としては、ｂフレーム（4），ref（8），GOP（12）の方が安定的）
‥一方、ｂフレーム（4），ref（8），GOP（12）だと
テレビUSB挿しでの際に、テレビ側の再生になんらかのトラブルが発生し
回らないソースが見られる
（のんのんびよりりぴーとOPの冒頭、蛍のアップでコマ落ちやらかす）
（原因不明‥そこだけｂフレームが長いわけでもない）
（コレは多分、機種差かもしれない、テレビ側が新型になるほど問題ないと思う）
（対策案としては、冒頭に数駒の黒画面を盛り込ませて、GOPをずらして分散させちまうぐらい）
（そうなると、始めからAviUtlからUt.video出しすることになるだろう）
（これは冒頭だから、読み込みの際の初動遅延を想定した対策案である）
（だが、このソース、初動がブラックインなので、どうやろうと相殺されちまうかも）
（参照すべきｐフレームが、常に後ろにあると、その分の読み込み待ちが痛いとか‥）
（初動の再生の際には、とくにそれだと、読み込み待機が長くなり回らないのかも‥）
（だがそれっぽいｂフレームは一枚か二枚しかない‥‥謎‥‥）
‥≒24フレームものは
４ｋサイズに拡大した効果として、CRF（12.0）にて、綺麗に回せているので
1.6倍→576ｐ（CRF（6.0））と比べて、GOP構成変更から、容量で二十数％↓を得るが
逆に、Bob処理≒60ものだと構成変更が同じなので、容量で二十数％↑する模様‥（痛い）
（つまり、1.6倍→576ｐCRF（6）と4ｋ→720ｐCRF（12）は）
（解像度容量比品質同等って感じですかね、なら、解像度高い方が好いに決まってるけど）
‥だが、一番に悩ましいのがエンコード時間である
（ぶっちゃけ、HEVCにしても差が無いのでは‥と思うぐらいになげー）
（ならば、ソースの用途向き次第では、576ｐもありという事だろう）
＞ サーチキュルキュル的に
＞ ｂフレーム（4），ref（8），GOP（12）での残念なところとは
ダンス等でのターンシーンにおいて
正面アングルならとくに、Ｉフレーム間で、顔の次が背中になるという
前と後ろしか拾わないところである
まぁそれ以外にもボチボチと間引きされるわけだが
それはそれで圧縮絡みなので許容だけど
前と後ろしか拾わないと分かっていると
サーチの際に無駄に残念な途切れだなあと思ってしまうのだぉー
（だがそれはそれで、サーチ感度が安定的と言える事象でもある）
