【エンコード日記】2pass時の最適なビットレート

↓5)記稿.2022/05/24

◇　Bob化ｉ解除して増えた低周波領域を、再び間引く為の２passエンコード

｛平均ビットレート：最大ビットレート｝
＝｛3：5｝
＝｛0.6：１｝＝｛１：1.6666666｝


＞　Ａ｜480ｉ→アプコン全部盛り1080ｐ[Bob]→576ｐ[二度揚げ]
＞　Ｂ｜1080ｉ→576ｐ[Bob]

Ａ
　平均：5760＝2304×１×2.5
　最大：9600＝平均（5760）×1.6666666
Ａ
　平均：11520＝2304×２×2.5
　最大：19200＝平均（11520）×1.6666666
Ｂ
　平均：17280＝2304×３×2.5
　最大：28800＝平均（17280）×1.6666666


↑BT.601
↓BT.709


＞　1080ｉ→720ｐ[29.97ｉ→30ｐ(Yadif)]

　平均：13500＝3600×３×1.25
　最大：22500＝平均（13500）×1.6666666

＞　1080ｉ→720ｐ[Bob]
　平均：27000＝3600×３×2.5
　最大：45000＝平均（27000）×1.6666666


＞　1080ｉ→1080ｐ[Bob]　あくまで参考です

　平均：40800＝8160×２×2.5
　最大：68000＝平均（40800）×1.6666666

　平均：61200＝8160×３×2.5
　最大：102000＝平均（61200）×1.6666666


※　基本はそれぞれ、Ａは×２、Ｂは×３、720ｐは×３、1080ｐは×３との見立てですが‥
　中には、下げることでＩフレームが増化するなんてケースも見られます。（謎）

※　Bob化の利点と欠点
　きれいめだけど多重化（解除）にありがちなダブりの見苦しさが消失する一方で
　Bob化演算による誤差を持つ駒が増発されます。（29.97i→59.94p）

　（ビットレートを多くすれば良いという話でも無い）

　‥ソースによっては、誤差がグデグデとどうしようもなかったりします。
　とくにOP＆EDでの高品質バージョンにて、グデグデ発生する場合が見られますが
　だからといって、本編側でもそうなるとは限らず、ニンマリできたりします。


＞　グデグデの大半は、局部的ビットレート不足なので、その際は、妥協ありきでせう
＞　インターレースの圧縮力は、どうにも摩訶不思議で、どうしようもない（実写等での解除増量感）

1-5)1

◇　プログレッシブ映像での低周波領域をクッキリとさせる為の２passエンコード

｛平均ビットレート：最大ビットレート｝
＝｛１：１｝


＞　1080ｐ→576ｐ
　平均：11520＝2304×５
　最大：平均（11520）


↑BT.601
↓BT.709


＞　1080ｐ→720ｐ
　平均：18000＝3600×５
　最大：平均（18000）

＞　1080ｐ→1080ｐ
　平均：40800＝8160×５
　最大：平均（40800）


※　ここでのプログレッシブ映像とは、すでに量子化済み映像という事になりますが
　その映像の中での低周波域の比率は、すでに一杯一杯の状態です。

　なので、無理に比率を変えようとすれば、ボケボケとした映像に成り下がるばかりでしょう。

　思いこみにも、高周波を優先しがちでしょうけど、それではダメです。
　その発想はインターレース時の解釈です。

　（プログレッシブでは異なるので注意しましょう）


＞　放って置いても平均化する際に、エンコード側はコソッと低周波を削ってくるのです。
＞　（なので、どんなにビットレートを割り振ってみようと同じに至らない）
＞　（低周波域を想定外に削ってしまう謎が、最大ビットレート値にあるというわけです）


　‥それよりも大事なのは、メリハリのある演出の仕方です。
　演出家なら、ビットレートの消費率を思い描きながら演出を決めるようにすべきです。
　ラノベ作家だろうと‥もはやそういう前提にある時代なのだと心得るべきです。

　‥でも裏技として、帯域超過しない範囲で後半部のケツに黒映像を足しておき
　あとからそのケツ部分を削除すれば同じことになります。
　（平均ビットレートの数値が同じなのに、画質が上がるだろう予想です）
　（代わりに、再エンコードの際の鬼門になるでしょうけれど）


＞　そう言えば、ＯＰ＆ＥＤのtsのケツには、無駄とも言えるそれがありますなぁ（‥ンゴ！？‥）
＞　映画版なんかスタッフロールの長いのが、画質UPとした流れだったわけですなぁ（謎解明）
↓/続きを読む/↓

【エンコード日記】2pass回帰×参照フレームMix（オン）にしてみた件

記稿.2022/05/22

＞　結論から言うと、キュルキュル感が増幅した（謎）
＞　とくに巻き戻しする際のキュルキュル感が今までになく良好になるので使用感に不満は無い（謎）
＞　品質方式（CRF）でのテレビUSB挿しに付きまとう魔の五秒間ともおさらばできる


　‥だがしかし
　1080ｐ→720ｐを４GB（音声込み）に収めようとすると
　平均ビットレート（21600）が限界となり
　それは19型モニター程度なら気にならないが
　まぁよくて24型ぐらいで丁度良ざげで、32型で見ようとすれば少々物足りないかも知れない


＞　平均ビットレートと最大ビットレートの比率扱いは
＞　インターレース（解除）とプログレッシブとは、異なっている模様


　‥想定されるうんちくを垂れておくと

　インターレース映像のそもそもは低周波領域を潰して、高周波領域を強調優先してあるのだから
　解除しようとその状態を保持してあるので、高周波を優先する必要がある
　つまり、最大ビットレートとの差を
　｛平均ビットレート：最大ビットレート｝＝｛3：5｝＝｛0.6：１｝＝｛１：1.6666666｝
　として盛り付けるべきとなる‥そうすると、塩梅宜しく高周波を優先して調整する‥

　（さらにそれにお墨付きを得るかのように、SSIM値では高周波を優先して吐き出す計算らしい）


　‥だがしかし、プログレッシブでもそれではダメだ
　プログレッシブでもインターレース（解除）と同じにやっては、低周波が余計に根こそぎ落ちる
　その結果として、見映えとしての物足りなさに繋がってしまうのだ



＞　そこで、プログレッシブソースでは
＞　｛平均ビットレート：最大ビットレート｝＝｛１：１｝にしてやると
＞　見た目としてのバランスを保持してくれる


　‥なんともまぁ、思いこみにも通常はそれの逆を行き
　庶民を追いやりがちな結果に酷似してしまう辻褄がそこに見られるのだった
　（しかも、SSIM値に頼っても、それの違いを差に織り込むことは無い）
　（まるで、経済数値のインチキたる鏡似性の曝露がそこにあるかのようだった‥痛ァアアア‥）


　‥とまぁよくよく考えてみれば、Ｂフレームモードと同じ辻褄にあるようだ
　ただでさえ割り当ての低くなるＢフレームに対して
　さらにその少ない中でやりくりしろって、庶民に酷に迫るような手法なんだから削りゃ質が落ちる
　それが逆にＰフレームに影響を及ぼして、全体の質を落とすのだ（無理な暮らしのアンバランス）

　（考えてみりゃ、Ｂピラミッドにて重複する箇所もあるわけですね）
　（ＢフレームモードとＢピラミッドの両方を用いるのは、二重課税だ）

　（又、量子化前のマスターデータなら、劣化しているわけでは無い、データはきっちりしてる）
　（どれだけ落とそうがＰフレームへのダメージには繋がらない）
　（まぁ演出箇所によっては、モワレやらバンディングに見舞われるだろうけど）


　‥一方で、劣化してある量子化済みソースになると、そもそもの低周波箇所はすでに素寒貧だ
　さらに削り落としちゃ、元も子もなく画質としてのインパクトを落とす
　そこはインターレースに見られた高周波重視（貴族風）と決定的に異なるということだった

　プログレッシブソースの再エンコードにおいて
　まずは、全体としてグレードを落とす必要があるにしても、優先して削るべきは、高周波だった
　（これはつまり、金持ちから税金を取るのもモチベーション落ちるなら、消費税廃止しろって話だ）
　（減量意図の辻褄が不景気のそれなので、高周波（金持ち）に回しても対策にならないのだった）


　（ならば、同じ解像度のままにＢフレーム倍増案は、更なる平民意識の植え付け拡大）
　（ダウンコンバートによる最適化を目指すのは、利権解体方向とした鏡似性だったとかなんとか‥）



＞　参照フレームMix（オン）して驚いたのは
＞　マグロ丼×ref（８）×Ｂフレーム（４）×Ｂピラミッド（厳密）でもあるということで
＞　どこのフレームから類似したマクロブロックを拾ってくるのか気がかりだったそれの影響が
＞　とにかく低いらしいことだった


　‥そのくせ、Ｉフレームの量がかさ増しされる傾向らしい（謎）
　（もしかしたらＩＤＲ分の増分なのだろうか‥それにしたってその手の感は薄い‥）

　（とにもかくにも、ＢＤ規格想定のそれとの反応がまるで違うくさ）


　‥しかも、（オン）とした結果は、これまたSSIM値に算出されないのに
　方向感の定まらなかった細部の方向感が安定する傾向を得たことなどから（静止画拡大確認）

　マスターソースと量子化済みソースとの差として
　調整の正しさを誤っていると、正しく機能しないくさく
　マスターソースでは、量子化されていないとした状態そのものが調整の正しさに相当するらしく
　普通に機能してしまっていたようにも思われる（そう考えざるを得ない）

　さらに、ソースがそのような手法にて細部の再現を満たしてあるとも成ると
　最終的には、同じ手法を持ちいずして成り立つわけが無いのだった‥orz


＞　結果として、再エンコードの際には、低周波ほど再現性が低くなるとした癖を見る
＞　なので、どんなにやっても正確さを欠きやすい箇所というのは
＞　その手の判断を‥エンコーダー側がやらかしている箇所でどうしようもない‥

【エンコード日記】謎定数×qcomp（0.6）＝MAX美麗的crf（押忍、1ミリも譲れねぇっすよ）

記稿.2022/05/18

＞　二進法において十進法での半分は、単なる１ビットシフト演算なので
＞　端数や誤差を綺麗に間引くのだから‥[÷２]策こそ減量効果正義に相違なく候‥
＞　と思ってやり始めたら別の発見をしちまいまして、再びの576ｐ戻りに晒されましたん

｜ダイエット失敗しつつ極まりぬ ビットレートは案内美学

解像度→解像度：【謎定数】Level（bframes-ref-keyint,me_range）（CRF）（qcomp）

1080→1080ｐ：【18.75】L5.1＆L5.2（4-8-12,24）（11.25）（0.6）

1080→720ｐ：【12.65625】L6.0（4-8-12,24）（7.59375）（0.6）

1080→576ｐ：【11.25】L5.1＆L6.0（4-8-12,30）（6.75）（0.6）


＞　謎定数×qcomp（0.6）＝MAX美麗的crf（押忍、1ミリも譲れねぇっすよ）


　‥つまり早い話が
　容量的に再び576ｐに返り咲きかも‥ってな状況です（ンゴ）
　というところで、me_rangeを再確認してありんす

　‥どうやら読み込みソースの読み出し時に、縦か横かで割り切れずに端数が出ると
　そのまんま、縦すじノイズ、横筋ノイズになりやすいという事が判明
　（つまりそれこそが量子化済み映像からの再エンコードの難しさって事ですね）
　さらに、マクロブロックの量に対してビットレート不足だと、剥がれたようなノイズに繋がる


＞　1080→1080ｐ：【18.75】の（15.0）（0.8）を（0.4）の変則にしたら
＞　めちゃくちゃにおかしな事になって、それをヒントに４ｋ化を試みたのだが
＞　me_range（72）ぐらいでまぁまぁかなぁなんて事になって、まぁ悩んだｚ
＞　少なくともref値比換算アイデアは妄想だった（どうもすんませんでした）m(_ _)m

【エンコード日記】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が売り文句だからとて、過信はできない‥みたいな
＞　（半端なくデータ量が多い音声ファイルの場合は、処理が追いついていないとか‥）