【エンコード日記】crf値÷謎定数Ｘ＝qcomp値（但し1以上はその逆数とする）

記稿.2022/05/15

＞　謎定数Ｘそれは、15÷8＝1.875に絡んだ値を行き交っていたらしい
＞　720×480，1920×1080の場合、15と8で割り切れる
＞　‥だからだろうか‥インターレースとの相性が良い（らしい）


謎定数Ｘ＝18.75とした場合

crf値＿＿qcomp値
6.0＿＿0.32
11.25＿＿0.6
12.0＿＿0.72
12.5＿＿0.6666666　‥ＢＤ版480ｉ相当（仮）
13.3333333＿＿0.7111111　‥（＊）
13.5＿＿0.72
15.0＿＿0.8　‥映画版相当（仮）
16.0＿＿0.8533333
16.6666666＿＿0.8888888　‥許容限度（仮）
18.0＿＿0.96


　‥（＊）を480ｉのインタレース保持に用いると、意外にも見やすい印象にあったが
　1080のダウンコンバートに用いると、映像の流れに特異な斑が生ずるらしく
　走査線斜線くさい残像が気持ち悪く目に焼きついて、一時的に視界が怪しくなるので
　其の手の別パターンもありうるだろうから、それぞれの選択の際にも注意を払うべし


＞　だが、1280×720では、何かと噛み合いきらないところが見られた‥orz


　‥それはつまり、「15」では割り切れないがゆえに
　720ｉとした規格が存在しないことに通ずるところなのだろう

　‥つまり、1280×720での謎定数Ｘを、謎定数Ｙとして、別にして探さざるを得ず
　詰まるところの（11.25）（0.8888888）から思案したところ

　11.25÷0.8888888から（12.65625）を用いて
　1265625＝3^4×5＾6＝1125＾2‥（いつぞやにやらかした平方根値回帰っぽ）


謎定数Ｙ＝12.65625とした場合

crf値＿＿qcomp値
11.25＿＿0.8888888　‥映画版対応｛4-8-12，48(96)｝
14.0625＿＿0.9（逆数）　‥25分アニメ対応｛4-8-12，48(96)｝

　とした値を得た


　‥（14.0625）（0.9）は
　（11.25）（0.8888888）より、40%↓のファイル容量想定にありながら
　25分アニメの場合、主体となる輪郭がクッキリしている

　‥細かいことを言えば、より低いCRF値を用いた方が
　フワッとした動きや激しい動きの細部に至るまで、斑の少ないインパクトを得やすい傾向を得るが
　全体的にビットレートの割り当てが多めになってくるのか
　良すぎも悪くもせずに、微にこもった印象になっていたりと見かける
　（その辺の足し引きの微差は、25分ソースの状態も絡んで、どうしようもなく起こり得る）


　‥キュルキュル感で言うと
　（14.0625）（0.9）は、≒24フレームなら、最低でも0.5秒間隔を保持するも
　（11.25）（0.8888888）よりは間引かれてある

　‥その間引きの差が、40%↓の減量に向かっているにせよ
　それゆえに重要視されなかった格子への割り当ても減るのだから
　フワッとした動きや激しい動きの細部とやらが、若干の犠牲になってしまうっぽい‥

　（だがしかし、qcomp値の打ち直しをせずに済むのは助かる‥のだった）
　（映画版でのqcomp値の打ち直しはどうでもいい‥時間コストの絡みで複数登録しないし‥）

　（何はともあれ、ＶＬＣプレイヤーでのテクスチャー剥がれの起こらないにこしたこたぁない）
　（‥ちなみに、古い再生支援機能だと問題がでるのでオフで）
　（‥ＣＰＵパワーが其を上回っていないと意味ないですけど）


＞　つまり、謎定数に対してqcomp値が1.0を超えて逆数を得ると
＞　キーフレームが減る傾向にあるとした珍発見なのでーす（但し、24pアニメだけくさっ）


　0.6÷1.3333333÷1.125÷1.1111111＝0.6（なんというリワインド）

【エンコード日記】0.6×1.1111111×1.125×1.3333333＝1.0

記稿.2022/05/12

＞　0.6×1.1111111×1.125×1.3333333＝1.0

　量子化圧縮（0.6）‥デフォルト
　量子化最小値（10）‥デフォルト
　ということから、この２つと割り切れる数値の組み合わせがこの辺に在るらしい


0.6＝A，1.1111111＝B，1.125＝Ｃ，1.3333333＝Ｄ

0.6
0.6666666 ＝ＡＢ
0.675 ＝ＡＣ
0.75 ＝ＡＢＣ▲
0.8 ＝ＡＤ
0.8888888 ＝ＡＢＤ▲
0.9 ＝ＡＣＤ▲
1.0 ＝ＡＢＣＤ■
1.1111111
1.125
1.25 ＝ＢＣ
1.3333333
1.481481481 ＝ＢＤ
1.5 ＝ＣＤ
1.6666666 ＝ＢＣＤ▲


＞　さらに、ＧＯＰの最大長は、１２０で割り切れる数値である方が都合良いらしい（小数点許容せず）


　‥デフォルトは（23）なんだけど‥
　‥マクロブロックが足りていないと、（24）だとうまく行かない都合があるらしいけど‥
　‥（まぁここではマスタ−データに見る非量子ファイルは取り扱わないので、デフォルトを否定する意は無い）


　‥ダウンコンバートとは違い同じサイズでの再エンコードともなると
　ソース側が2pass構成だったりすると、CRF値算出とは違って、ビットレート割り当てに斑がある

　それは、ソース毎に異なるのだから
　ダウンコンバートのような一律とした最適値に丸めてから拾えるような状況には無い


＞　なので、↓はあくまで覚え書き程度の参考となる


　1080ｐ→720ｐ｛2-4-6-24(48)｝，（11.25）（0.6）‥25分アニメキュルキュル用途向き
　に近しいのが
　1080ｐ→1080ｐ｛5-10-15-40(80)｝，（16.6666666）（0.8888888）

　1080ｐ→720ｐ｛4-8-12-48(96)｝，（11.25）（0.8888888）‥映画版アニメ画質向き　
　に近しいのが
　1080ｐ→1080ｐ｛5-10-15-40(80)｝，（15.0）（0.8）


　‥レベルは、1080ｐの≒24フレームには、概ねL5.1になるのだが
　モノによってはL4.1でも差が見られない場合もあり
　ソースによっては、色々と試してみないとなんとも言いがたい部分がある‥

　（只でさえ時間コストが、720ｐと比べて倍になるので、逐一調べざるを得ないのは痛い）
　（カット数が多ければ、容量の点で逆転するくさいし‥）
　（テレビUSB挿しを予定するなら、確実に720ｐでしょう）


＞　尚ここでの数値は、単純に、画像の拡大・縮小比にも用いられている部分もあるのだから
＞　まぁ数値のマジックという奴は、ご近所感覚にあるらしい
＞　（３Ｄにすると、歯車のかみ合わせと同じって事っすね）

【エンコードレシピ】強化版じっくりコトコトびっくら煮（1080→720ｐ）

↓12)記稿.2022/05/11

＞　用意して頂くアプリは
＞　XMedia Recode 64bitのバージョン3545です。
＞　最新版から、x264.dllを抜き出して、3545側のと差し替えます。
＞　‥最新版だと解像度変更の際に、アプリ落ちするのでそれの代替です
＞　‥落ちる原因は不明です（マシン構成絡みかもしれません、問題なしなら最新版で構いません）


＞　先にお断りしておきますが
＞　テレビUSB挿しにおいて、なぜか、魔の五秒間が発生するようになりました‥orz


　‥この五秒間とは
　テレビUSB挿しファイルを再生する際に、開始時操作窓が自動で消えるまでを指します。

（開始時のバッファ蓄積が間に合っていないものと予測され、特定条件下でタイミング不良します）

　‥その条件とは
　白地画面orホワイトイン、縦パン横パンのパン表現から始まるケースです。
　なので、ホワイトインが入ったパンスタートだったりするとボロクソ最悪です。
　（例えば、ウマ娘（1期）のOP＆EDです‥何をやってもどうにもなりませんｚ）
　（尚‥VLCプレイヤーでは、この問題は起こりません）


　‥この問題を緩和する策として、微に有効なのは
　720ｐ｛4-8-12-48(96)｝から
　Ｂピラミッドを無効にして、720ｐ｛2-4-6-24(48)｝に変更することです。
　（但し、平均想定で20％程増量します）

　‥別案の強策としては
　同じ構成にてエンコードした五秒間の黒画面ファイルとを、つないで合体しておくことです
　（用意するのが手間ですが、そういう辻褄なんだと思います）
　（ちなみに、ブラックイン＆パン表現とした開始ケースでは、この問題は起こらないらしい‥）
　（なので、五秒は必要ないかもです‥）



＞　今回の強化版（映画版対応）として
＞　量子化圧縮値変更→（0.8888888）を追加しました。
＞　尚、1080→720ｐの際のCRF（11.25）に変更はありません。


　この量子化圧縮値変更を‥1080→1080ｐ｛5-10-15-40(80)｝に対して‥
　CRF値（16.6666666）として再調整してみたところ
　やはりというか圧縮率にアタリとハズレが付きまとうわけですが

　その中身がどうにも、ＩフレームとＰフレームの増量とした内訳になっていまして

　つまり、キュルキュル感が変わるだけという何やら腑に落ちない結果を得ています。
　なんだかんだと1080→720ｐにおいても同じ傾向です。（どうなってんだ？）
　なので、激しい動きが多かったり、カット数が多い作品に対しては（0.6）の方が塩梅良く
　さらに、始めからキュルキュル重視にある720ｐ｛2-4-6-24(48)｝の場合も同じになってきます。

　‥とはいえ、Ｂピラミッドによるキーフレーム位置次第では、動きに違和感を伴う事から
　25分アニメでの圧縮重視は悩ましいところでしょう（おもにテレビUSB挿し時）　
　と言うところで、アニメは、映画版と同じにするか否かの二択でしょう。


＞　1080→720ｐ｛2-4-6-24(48)｝，（0.6）‥25分アニメキュルキュル用途向き
＞　1080→720ｐ｛4-8-12-48(96)｝，（0.6）‥実写＆インターレース解除Bob向き
＞　1080→720ｐ｛4-8-12-48(96)｝，（0.8888888）‥映画版アニメ画質向き


　‥尚、「Ｂピラミッド厳密の方が画質が良いのでは？」とした見方についてですが
　キュルキュル重視そのものがＩフレームからの距離が近いというところで成り立っているので
　ゆえに色劣化としては問題が小さいので
　Ｂピラミッドの方が、其を代替していると考えられ、内容に差があるようには思えません。
　（‥まぁ何というのか、キーフレーム位置をないがしろにしないで済むということですね）


　‥ちなみに、1080→1080ｐ｛5-10-15-40(80)｝になると
　CRF値を上げたところで、HDテレビでのテレビUSB挿しでは、スムーズに回り切らないようです。

　‥まぁ画質としては
　４ｋ倍に拡大して比べると、圧倒的に1080ｐ｛5-10-15-40(80)｝でしょう。

　‥但し、1080→1080ｐ｛5-10-15-40(80)｝，（0.8888888）において
　VLCプレイヤーの側に問題があるとしか思えないのだが
　マクロブロック崩壊とまでしないものの、時としてテクスチャー剥がれが生ずる‥

　例えば、A.I.C.O. IncarnationのEDに冒頭がブラックインからの長い縦パンシーンがあるのだが
　ツヤツヤタイルの上を歩く人影が反射しているのだが
　そのツヤツヤタイルのテクスチャーが、３〜４回ほどごそりと剥がれるコマが出る。
　エンコードミスでは無いのは、AviUtlとavidemuxのコマ送りで確認できるし
　それぞれで再生しても問題ない。（どういうこと？）
　（レベルを4.1にして、マクロブロック数を抑制しようとお手上げなのでバグかと‥）


＞　まぁそんなこんなで、今回レシピは、1080→720ｐ用途に留めるとします。
＞　お後の見直し要素としては、Fast P-Skip（□）になっとります。
↓/続きを読む/↓

【エンコードレシピ】Ｂピラミッド厳密ぶち込みじっくりコトコトびっくら煮

↓12)記稿.2022/04/28

＞　今回レシピは二度揚げしません、BDの1080解像度のみ対象です
＞　但し、25分モノに関しては、テレビUSB挿し前提の720ｐダウンコンのオススメになりますが
＞　品質が上になってくる映画モノに関しては、1080ｐエンコードとせざるを得ないでしょう
＞（まぁそれだけ、Ｂピラミッド込みでマグロ丼踏襲がキワモノと言うことらしい）


　‥今回用意して頂くアプリは
　XMedia Recode 64bitのバージョン3545です。
　最新版から、x264.dllを抜き出して、3545側のと差し替えます。
　（最新版だと解像度変更の際に、アプリ落ちするのでそれの代替です）
　（落ちる原因は不明です‥マシン構成絡みかもしれません、問題なしならそのままで構いません）


　‥Ｂピラミッド（厳密）の効果は凄まじく、ＢＤでの576ｐダウンコンを無用たらしめます。
　CRF値は、（11.25）です。
　量子化最小値（10）と、8：9比に調整してみたところ良い感じにあるようです。

　（ちなみに、テレビ画面の設定を倍値にした効果なのか）
　（量子化最小値（9）は微に明るすぎ、（11）以降になると次第に暗くなるのが判るほどです）
　（ぼやかしている程度の差とかそういうのとは明らかに違うことが理解できました）


　‥Ｂピラミッド（厳密）を用いているせいなのか
　バンディング箇所の見られるソースの場合
　改善に到るか、粗さ強調に到るかは、やってみないとわかりません。（ダウンコン時）

　（これには、マクロブロックを増し増しにすることによる割り当て比が絡むように思われます）
　（単純に、秒間あたりのＩフレームやらＰフレームの構成比にもよると思います）
　（品質設定だとしても、そんなこんなの過不足が起こるらしい‥）

　‥なので、ソース品質が上になる映画モノを720ｐダウンコンの際には
　バンディング部位での悪化が懸念されてきます。
　‥なので、1080ｐ再エンコードでも、レベル設定を気にするべきになります。


＞　という事情から、720ｐダウンコンは、レベル6
＞　1080ｐは、レベル5.1（≒24ｐ）レベル5.2（≒60ｐ）を基本とします


　‥1080ｐ再エンコードでは、圧縮率を稼ぎたいが為
　｛Ｂフレーム：ｒｅｆ値：最大ＧＯＰ値｝＝｛1：2：3｝の構成を｛5：10：15｝にします。
　この段階にて、ＵＳＢ2.0帯域を多少上回る程度に収まってくるようです。
　（難点としては、大きな正方形のだまと化すブロックが、微に発生しやすいくささを見せてきます）

　‥また、Ｂピラミッド（厳密）を用いると
　通常とは異なり、キュルキュル感を踏襲できるのは良いのですが
　指定したref値とは違い、遅延対応なのか、１引いた値が採用されるらしい‥
　（でも画質は、Ｂピラミッド無しより確実に上なので、気にする必要になさげです）


＞　720ｐダウンコンと1080ｐとでは、M.E.範囲の値が異なります
＞　その違いから、Ｂピラミッドを用いる際、８又は１６の倍数値でないと
＞　正常な量子化にならず、ブロック破綻を起こす症状に見舞われる事が判明‥


　なので、７２０ｐダウンコンでは、｛5：10：15｝の構成を使えません
　まぁ｛４：８：１２｝でも圧縮率は高いし、キュルキュル感保持も高めで許容でしょう。

　‥ちなみに、｛5：10：15｝からは、（≒24p）でのキュルキュル感が激減します。
　並びに、｛４：８：１２｝でのキュルキュル感の減損は、ソース次第のところが見られます。

　（いやぁまぁ、画質優先というところでまとまっているといえばそうなるのでしょうが）
　（歩行シーンでの手の振り足の振りは、さすがに目を当てられない趣です）
　（そういう意味では、インターレースBob化万歳とした空気もありげかなと‥）
↓/続きを読む/↓

【エンコード日記】チャプターをどう切るか？

記稿.2022/02/27

＞　25分ものアニメ等のチャプターの切り方は
＞　概ね‥OP,前半,後半,EDをベースにやらかすのが暗黙の了解になっている
＞　だが、映画ものになると途端に、「コレだ」と言えるような案が無い


　（ものによっては、残念なぐらいに適当だったりするDVD＆BDも見られる）

　‥そもそもチャプターを多くしても混乱するわけだが
　解釈の仕方によっては、多く切りたくもなるわけだが

　チャプターとした考え方自体に、多視点化とした概念が無いということに気がついた


＞　映像や音声の多視点切り替えを考えておきながら
＞　容量と品質の関係から頓挫したままなのだから
＞　せめて、チャプターによる多視点化で代用するとした案があっても好かった


　‥例えば

　キャラクター毎の視点でのチャプターチャンネル
　演出上の伏線となる部分での絡みを強調したチャプターチャンネル
　注入歌等音楽の入りとなる部分を集めたチャプターチャンネル
　時間軸を整理してくれるような、前から順であるルールを無視できちゃうチャプターチャンネル

　考えてみれば

　あとから編集する際にも、サクッと頭出しできるわけで
　コメントする際にも、対応するチャプターチャンネルで説明がされてあると通りが良くなるはずだ


＞　そう考えれば考えるほどに
＞　チャプターの多視点化（チャンネル化）をできないままというのは勿体ない


　これは編集側の要望であるべきで、プロの現場でなら
　チャプターチャンネルとした概念を持ち出すことで、あとから憶えていれば
　どのチャプターチャンネルの何番目で切って、どこと繋げるなどの指示を出しやすくなる

　（CMやらPVやらを構成する際にも重宝するはずだ）
　（お高いツール機能としては有るのだろうと思うけど）

【エンコード日記】XMedia Recode(3553)で解像度変更できない件

記稿.2022/02/13

＞　x264で、解像度変更しようとすると、エラー吐いて止まる
＞　スケーリングの記録がされず、バイリニア固定になる
＞　自動的に、行列係数をGBRに変更やらかして設定記録される
＞　（まだ何もしてないのに、再起動時にそれの強制モード感はどうみてもバグ）


　‥行列係数がGBRに変更されてしまうのは、かなり以前からですが
　とにかく連続して、再コンテナするだけで発生します

　（多くの方がやらかしていることでしょう）

　極端なことを言うと、一度この症状が発生すると
　何もせずに下の行のファイルを確認移動するだけで
　感染したかのように、GBRがくっつきます

　‥それに気がつかないで再コンテナしまくっていると
　identityと刻印されており、いやんな感じに仕上がります（微に数バイト増量するし）


＞　このようなエラーくささを回避しつつ、再コンテナを成功させるには
＞　１ファイル毎に、XMedia Recodeの再起動を繰り返す必要があります（超面倒くさい）


　‥再起動せずにやらかしていると
　クロップ/プレビューの解像度指定が、なぜか1920×1088に変更されています
　（サイズが書かれてあればまだ良い方ですが、空白になったりもします）
　さらに
　アスペクト比が、ぶっとんで空白だったり
　スケーリングが、バイリニアに変更されます


＞　このような状態に成ってしまっていると
＞　指定した通りに、きちんとエンコードされるのかがとても怪しいです


　‥多コア対応のせいなのか、Windows側の対応のせいなのか分かりませんが
　XMedia Recodeでも、同時に複数起動できるように変更された頃からに思われます

　‥まぁそれの影響を思いっきり喰らってるようなトラブルに思われます
　（単にバグなのか、規制もどきなのか、作り手のお好み設定優先にあるのかは謎）


＞　あと、エンコードを一時停止させたまま、手動終了すると
＞　解放されずにフリーズ状態で固まる


　‥やっちまったそんときゃ
　タスクマネージャーから強制終了すりゃ良いわけですが
　設定の保存が吹っ飛ぶので、できればちゃんと終了するようにして欲しいっす

【エンコード日記】TrueHD音声の正しいコンテナ移動

記稿.2022/02/09

＞　TrueHD音声までを
＞　FLACにしてしまえば良いと思っているのは素人だ


　‥ロスレスのTrueHD音声の構造は、かなり特殊で理解しがたい造りになっている

　MediaInfoのTrueHD情報に
　24ビットロスレスと書かれてあろうと
　必ず、AC3（32ビット）のセットで、本来のロスレス音声を完成する仕組みに成っている

　（ここの理解が煩わしい）


＞　どうやらかしてあれば、その正しい完成形とした再生をするんだよ？


　（どこにもその手の説明が無い）
　という事で、遂にそれの状態である文言を確認した
　「Service kind : Complete Main」
　という表記がAC3側に示されてあると、完成形とした再生をしてくれる


＞　では、それの状態を得る上でのポイントを述べておく
＞　（ここでは、XMedia Recodeで、それを説明する）


　‥XMedia Recodeで、mkv形式を選ぶと
　その音声トラックには
　強制音声ストリームと既定トラックの項目が、デフォルトで「いいえ」になっている
　そのままに放置していても、ソースの配置順に優先権が与えられるので
　操作の必要度に疑問を感じ得ない

　（映像側にはその手の設定が見られず、いいえが連なるので尚更に必要度に疑問が生ずる）
　（ちなみに、ｍｐ4形式では、それこそ必要がないとばかりに項目が消えている）


　‥だが、TrueHDでコンテナされたソースの場合（ロスレス）
　MediaInfoの表記にAC3が見当たらなくても
　ここの欄では、当然として登場するソースも見られる

　その場合には、必ずしもTrueHD側が優先順位１に置かれていなかったりする
　（一体全体どうなってんだ？）


　‥そんな謎を躱しつつ
　TrueHDの正しいコンテナ移動をやらかすには
　双方の既定トラックを「はい」に切り替える用があった

　まぁ無難にやるなら
　１をTrueHDにして、２にAC3だろう
　その双方の既定トラックを「はい」に切り替えて
　双方共に、モード：コピーを選択する

　すると、「Service kind : Complete Main」表記がAC3側に示される


＞　あとは、音質の違いを確認するだけだ
＞　たまに制作側に理解が無かった場合など、ちっとも差を感じないケースもまま見られる
＞　まぁそういうのは、TrueHD側がLossyだったりのケースだろう‥


　‥最近は、圧倒的にDTSが主流だが
　映像の圧縮比に瀕する場合などでは、TrueHD選択もされるだろう

　ちなみに、DTSとTrueHDの5.1CHは、
　（左＋右＋前面中央＋左側＋右側＋LFE）なのに
　AACとApplelosslessとPCMだと
　（左＋右＋前面中央＋左背面＋右背面＋LFE）とあり、微妙に異なっている

　さらに、AC3とFLACでは、その両方を選択できるという‥

　（いやはやはや、どういう違いがあるんだかまったくわからない）
　（制作側がその辺を勘違いしている5.1CHだったりすると、音がボケていそうだな）


　‥一番にありがちそうなのは
　現場はwavで編集中の処に、オーナーサイドがDTSを要望する場合だろう
　すると、現場のスピーカーではそれなりに対応できていて、それ程に差が無くも
　対応していない安いスピーカーあたりだと違和感が発生するとか‥
　（もっともそのような層の購入を前提とはしていないのは明らかで、とくに問題化しない）

　（だが7.1CH時代に突入しているので、それなりに表面化する）
　（JBL Pebblesだと、7.1CHには疑似対応していないらしく、聞こえてこない音がちょっとある‥）
　（つまり、5.1chでのどちらかは、音が異なって出ている可能性があるっぽ）
　（まぁ疑似対応させているのは、VLCプレイヤー側かも知れんけど‥）


＞　そんなこんなで、5.1CHが売り文句だからとて、過信はできない‥みたいな
＞　（半端なくデータ量が多い音声ファイルの場合は、処理が追いついていないとか‥）

【エンコード日記】444拡大1.5倍比だと不十分なので４ｋサイズに戻した件（720ｐ）

記稿.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）での残念なところとは


　ダンス等でのターンシーンにおいて
　正面アングルならとくに、Ｉフレーム間で、顔の次が背中になるという
　前と後ろしか拾わないところである

　まぁそれ以外にもボチボチと間引きされるわけだが
　それはそれで圧縮絡みなので許容だけど

　前と後ろしか拾わないと分かっていると
　サーチの際に無駄に残念な途切れだなあと思ってしまうのだぉー
　（だがそれはそれで、サーチ感度が安定的と言える事象でもある）

【エンコード日記】M.E.範囲に、別要素の法則性を確認

記稿.2022/01/30

＞　プログレッシブのref（4）ソースに対して
＞　ref（6）に切り替える時、M.E.範囲×1.5倍増し
＞　ref（8）に切り替える時、M.E.範囲×２倍増し


　1080ｐソースを1.5倍にして（2560×1440）
　1280×720にダウンコンバートなら

　M.E.範囲（16）×1.5（拡大比）×1.5（FHD比）＝M.E.範囲（32）‥ref（4）
　M.E.範囲（16）×1.5（拡大比）×1.5（FHD比）×1.5（ref増分）＝M.E.範囲（48）‥ref（6）
　M.E.範囲（16）×1.5（拡大比）×1.5（FHD比）×2.0（ref増分）＝M.E.範囲（64）‥ref（8）


　並びに‥ｂフレーム（3），ref（6），GOP（9）
　並びに‥ｂフレーム（4），ref（8），GOP（12）

　並びに‥CRF（9.0），qpmin（9）

　（ちなみに、1080ｐでのCRF値‥は、CRF（12.0），qpmin（9）ぐらいな‥）


＞　プログレッシブのref（2）ソースなら、ref（4）の段階で２倍値
＞　なので、ソース1.6倍→576ｐ出しのref（2）→ref（4）なら、いきなりM.E.範囲（96）だｚ


　つまり、ref値変更による焦点ぼけを、M.E.範囲で調整しろって事らしい
　（いやいやいや、まさかまさかのオッタマゲ）


　‥これでようやく1080ｐ→720ｐの容量問題が解決しそうです
　＆キュルキュル感もそれほどに劣化せずに済みそうです
　（だがしかし、エンコード負荷に悶絶しそうでヤンス）

【エンコード日記】RD（レート歪み最適化）は何をしているのか？

記稿.2022/01/28

＞　デジタル圧縮 (2) RD最適化 音声・オーディオ圧縮.pdf



　‥という画像情報特論とやらに目を通していると
　「ブロックサイズが小さいほど予測効率は上がるが、オーバーヘッドが増える ⇒ RD-最適化」
　とあった

　‥これをAVCで具体的に語ろうとすると
　subme（11）を使うと、どうしてファイルが縮むのか？
　という問いの正体が見えてくる

　つまり、オーバーヘッド（負荷）を減らす為の処理を、併せてやらかすらしい

　４×４マクロブロックは用意してあるけど、できればあまり使用したくない
　というのが、技術者の間の見解くさい


　‥そうなると
　レート歪み最適化とは別に
　４×４マクロブロックの用を抑制しつつ、ビットレート量に沿うように調整をするという事らしい

　なので、４×４マクロブロックの抑制が一番にやんわりなのが
　subme（11）という事で、４×４までを効かせやすい分だけ圧縮に良さげに見える
　（勿論、適った設定をしないと画質的には何も分からんと思います）
　（ぶっちゃけそれの一番は、快適な位置でのＩフレームの増量かと‥）


＞　この解釈を逆算すると


　FHD規格では、始めから16×16のマクロブロック推しにあるわけだから
　RD最適化にしても、subme（9）〜（10）で、間に合うようにつくられている‥とかなんとか

　ところが、逆に、低解像度になると４×４が欲しくなる
　そこで用意してあるような顔をしていたのが、subme（11）だったとかなんとか

　でも、普通にレベル設定を自動まかせにしていたりすると
　そこでも、16×16のマクロブロックを主体とした構成になるので
　subme（11）に居場所がないという感じになってるっぽい


＞　なので、マグロ丼構成に必要なビットレートを始めから割り振る気が無いなら
＞　subme（11）は無用の長物となり、無理に使えば画質を悪化させかねない

　（細かいマクロブロックは、１ブロック当たりのビットレートを割比で食うからな）
　（複数箇所での適合が噛み合っていないと圧縮効果は低くなる）

＞　逆に問えば、始めから割り振る気が無いなら、subme（9）〜（10）で間に合う
＞　但し、４×４までを設定してあろうと、効果は薄くなる


　‥細かく言えば、レート歪み調整用途として
　Ｉ４×４は必要というのが‥デフォルトの意味かも‥
　（どう見たって、有っても無くてもどうでも良さげにしかＩフレームには注目してねぇのにな）



　※　ここでの解釈は、あくまで閃きやら勘の類になりまーす、あしからず
　（実際にどうかなんて知ったこっちゃない‥というか存じませんので）
　（慣れれば分かるギヤチェンジみたいな）