【エンコード日記】いやんなシミの正体

記稿.2021/05/08

＞　動画エンコード上の「いやんなシミ」とは
＞　どのような映像の中にもなぜか出現してしまうもやもやとした浮遊物体のことを指す


　‥この正体は
　ビットレート不足による、強制的なＢフレーム内の時間軸で圧縮された箇所らしい

　一番に多く発生するのが「パン」シーンの最中である事から
　そのように断定しておくのが適当に思われる

　（‥只でさえＢフレームへのビットレート配分は少ない）
　（それはＰフレームに対して1.3倍減程度を規格の想定としているにせよ）
　（実際は自動処理される設定に成りがちなので、不明と言わざるを得ない）
　（さらに減らしていると知れるとやばいので‥生活保護にも秘守してあるとしか思えない‥）


　‥そこは、自信をもってＢフレームが極端に少ない場合があっても当たり前と胸を張ったにせよ
　‥なら逆に、一番にカク付きしやすいパンシーンに対して
　配分比率を高めに備えられてるだろうか？

　‥ＤＶＤなら、可変フレームレート技を施してある場合も見られるが
　‥ＢＤの場合には、そんな設定は出てこない（せいぜいがインターレースありきだろう）


＞　‥という事で
＞　Ｂ-フレームモード内で時間軸圧縮が選択されたソース映像からは
＞　リピート的に残像を漉き込むオチになる


　‥この残像の漉きこみ部分こそが、不自然に浮遊するもやもやとして登場するのだ
　通常、ただでさえそれだけでパンは激しい動きの部類に入るというのに

　より激しい動きが追加されてると、どこかを端折ろうとしてエンコーダーが頑張っちゃうので
　結果として、時間軸を介したすり込み箇所を見つけ出すらしい（オフにしろよもとい使うなッ）
　結果として、動きが激しければ激しいほどに、残像の時間も長かったりするらしく糞ッ


　‥ビットレートをケチってるというよりは
　追いつかないというか
　そういうグデグデになっていると、その手の映像は
　シミがあるどころか、パンのカク付きも酷くて
　どちらかといえばこれのDVD版の方がスッキリしていたと思っちゃったりのデキだったりする

　（なんでDVDの方がすっきりしていた印象になるんだ？）
　（それこそが３枚単位にしてあるDVDの特徴なんだろう‥あと可変フレームレート技もあるし）

　‥その点BDは‥容赦なく２３枚構成をデフォルトにしたGOPになっている
　さらに（シーン変更感度：４０）では、体良く短くになんて緩急をやらかさない
　とにかくもう‥「ご愁傷様」と言うより他は無い


＞　‥でも、DVDにだってそりゃシミは見られるし、カク付きの酷いのも見られる
＞　‥だからこそ、シミの無い＆カク付きも見当たらないタイトルにぶつかると
＞　そりゃもう信頼度は上がる
＞　その会社のBDの品質もまんざらでは無いとさえ思うだろう
＞　だがしかし、動きの少ない作品と激しすぎる作品とを比べたって意味は無い


　（円盤にmade in korea表記がされてあるのを見たそんときは、うなだれるより他は無い）
　（そんな円盤が時間経過と共に読み込みにくくなっていたりすると、さらにorzだよ‥）
　（HDDに移動しておいて何が悪いって話にもなってくる）

　‥そんな業界のやっつけな積み重ねの結果が
　染みつきパンツ‥もとい染みつきリップなんだからな
　そういう意味では‥ビデオテープやLDの時代の方が安定していた


　‥それにしてもなんでテレビ放送の時はその手のシミを見られないのかが
　その差がどうにも不可解でどうしようもない

　テレビ放送には厳しい制限があるけど、BDはご自由にとした空気だからだろうけど

　じゃどうしてそれの制限を設けてるNHKは、そこん所の紹介を一切やらないの？
　税金投入してるも同然なんだぜ、秘守義務なんて通用しないだろうがっ
　その手のしっかりとした本ぐらい出せよ、何様のつもりだろうや


＞　近年はＮＨＫ自体が基盤だパンツのシミくさいからな
＞　それぐらいの後押しサービスもできない連中なのだろう
＞　放送文化も糞も無い、ただのどや顔したいだけの連中なのだろう
＞　（ＶＶＣの登場で今度はいよいよ１６ｋでーす‥もちろん染みつきパンツでーす‥とかなんとか）

【エンコード日記】4：3映像にi4x4を用いても基本的に誤差しかもたらさないので‥

記稿.2021/05/06

＞　1920×1088÷256＝8160
＞　1440×1088÷256＝6120


　8160は16の倍数だが
　6120で、2のべき乗べき乗で割り切れるのは4までなので

　4：3映像に、i4x4を宛がおうとしても斑にしかならないということになる

（ＩフレームとＰフレームの間の輪郭強調の為の錯覚利用が上手く作用しない意）
（誤差しか無いなら、違和感にしか成らない‥ということでi8x8止まりらしい）


　なので、基本則として、黒帯を追加して16：9映像にしてからエンコードすると
　i4x4までを綺麗に演算できるとの予想が立つ


　‥これは、放送上の都合とかでは無く
　綺麗にエンコードを仕上げるための都合だった（痛ぁあああ）

　（ＨＥＶＣで4：3出しとか、無知の極みッってことっすね）


＞　i4x4にまで均割にビットレートを入れられると
＞　その分だけ‥いやんなシミが落ち着く程度になるらしいが‥
＞　4：3映像が悩ましいと思ったら、黒帯追加16：9でもやってみるべし


　‥なにげにインターレース解除は、概ね16：9にせざるを得ないってことですね
　（適切なビットレート値を見つけないと、それこそ只の増量っす）

【エンコード日記】シミと動きをどうにかするポイントを２つほど発見

記稿.2021/05/05

＞　以前にHDサイズのエンコード用に使っていた
＞　ビットレート（16875）が
＞　ｂフレームを抜いたそのまんまの設定でも、ものの見事にシミが消失近くなるのを確認ッ


　‥☆なるほど、そうだったのか


＞　つまり、２４フレームにおいて
＞　GOP（８）ref（４）って事で


　それを２４フレームタイプわさＢ抜きにあてると
　M=1，N=5の形に置き換わるケースが概ね安定らしく

　さらに３０フレームタイプわさＢ抜きには
　GOP（１０）ref（５）をあてると
　M=1，N=６の形に置き換わるケースが概ね安定らしい


＞　シーン変更感度：８９　の時
＞　ref＝（GOPの半分値）
＞　GOP＝（フレームレートの３分の１値）
＞　M＝１，N＝（ref＋１）


　‥つまり、GOPの設定には
　遊びとなる余裕を設けてやらないとうまくいかんと云う事らしい
　（遊びの分も計算した結果、長すぎたＧＯＰの発色の差を嫌って捨てるという事かも）


　‥それにしてもこんな風に、マクロブロックの塩梅とGOPの様相が固まっちまうと
　ビットレートとは、まさに発色の濃さの演出でしかないと言わざるを得ない

　なので、テレビの発色を統一していないと
　自分のテレビの発色如何で適切なビットレート値が全然違ってくる事になる

　（なら、業界の自慢げな大型モニターでは、シミが気にならない設定だったって事ですね）
　（概ね手狭な部屋の庶民のモニターでは当然そうでは無かった‥）


＞　にしても


　‥縦解像度が同じでも
　横比率が違ったり、フレーム数が違ったり、もちろん画面サイズが違うと
　シミの薄れる適切なビットレートが違ってくるのでまだまだ先は長そうです

　‥鍵はどうやら、ビット/(ピクセル*フレーム) の値で
　それを特定値にしてしまう操りができれば
　シミの消失点を、どんなモニターでも自在に消失させられる可能性が有るものと予想する

　ちなみに‥（0.764）辺りが良好らしいがまぁ参考に

　‥計算式があるだろうから、計算方法を理解しているなら
　計算しながら近づけるのが早道に思われる（知らんがな）

【エンコード日記】わさｂ抜きにはGOP（6）ref（5）らしい

記稿.2021/05/05

＞　いやんなシミが濃くなる理由として


　...GOP（3）ref（2）だと
　GOP（2）ref（1）に置き換えられてしまうパターンがかなり起こる

　ソース程度の濃さに落ち着かせるには
　Ｂフレーム（3）に似かよらせる必要があるので‥Ibbbp‥
　GOP（6）ref（5）にするのが対処で
　GOP（5）ref（4）‥IpppP‥とした引き算パターンを狙うのがよさげ


　‥GOP距離の一枚引き算されなかったら
　GOP（5）ref（4）に設定し直してやってみるのも有りかも知れないけど
　それで今度はGOP（4）ref（3）に引き算されちまわないとも限らないので
　その辺は時間コストで妥協せざるを得ない部分になってくる

　もしくは
　シーン変更感度をデフォルトの（40）に戻してしまう選択肢もありだが
　そうすると概ね指定したGOPの長さになりがちになるので
　GOP長に変化が生じがたい傾向になるわけだが（HEVCだとほぼそれだけど）

　まぁどちらにせよ、テレビUSB挿しにおいて
　Ｂフレーム（3）に似かよらせる構成では、わずかながら
　キュルキュル感の減りに残念さが伴うに変わりは無い...


＞　あと、自動フィールドシフトの件だが


　‥自動フィールドシフトのそもそもが120フレーム対応なので
　30フレーム出力だと、器用に間引きされてしまっているので
　ソースに忠実な駒状態としての再現性は正確とは言えない

　（だからといってトップとボトムをつなぎ合わせるだけだとカク付いて見えがちだったりする）
　（人間技だとトップとボトムでしか思考が追いつかないわけだが）
　（機械的な判断にやらせると、超えた判定にて駒の繋がりに様がわるのも一興と思わざるを得ず）

　（‥24フレーム化する手もあるが）
　（キラキラ表現のある映像では、フレーム構成が崩れる事で）
　（キラキラの構成からして崩れてしまう傾向を見るのがオチだろう）
　（これはマクロブロック構成の都合なので、自動フィールドシフトとてどうにもならない）
　（参照対象の基本情報を持ったブロックが削られるとおかしくなるという事らしい）


　‥是の値の調整は「判定比」で行われているわけだが
　０にすると切れるにしても
　１にスライドするだけで、自動フィールドシフト状態に突入するので
　その間の加減を確認できるのは、ほぼ１２０フレーム選択時だけに思われる
　とはいえ、肝心のAviUtl自体に１２０フレーム選択が無いのだからどうしようもない

　（自動フィールドシフトの作者は、AviUtlのそこを改造したバージョンを使用しているのだろう）
　（となるとメモリー周りが違うだろうから、６４ビットのβ版の存在がチラつくわけだが‥）

【エンコード日記】わさｂ抜き限界盛りマグロ丼の「なるほど」

↓4)記稿.2021/05/04

＞　（なんだかんだと）すじノイズの発生はＢフレームの影響大なり


　‥そもそもこちらは、サーチキュルキュルにしたいのに
　Ｂフレームを使用していては
　Ｉフレーム選択位置に影響するのだから、わさＢ抜きに踏み込まざるを得ない


　‥そこで、再びレベル設定の仕様書の確認を
　今回は（ストアされる最大フレーム数）とやらに注目

　レベル4.1には
　1920×1080 @30.1 (4)とある
　つまり、先読みしてバッファにキャッシュしておける枚数の最大が４枚と言う事だろうか？

　レベル5.1には
　1,920×1,080 @120.5 (16)とある
　つまり、ref値の最大を16に指定できると言う枠組らしい‥（16）以上は表記に出てこない‥


＞　ｒｅｆ（４）は絶対では無いというのだろうか？（先ずは確認）


　≒２４フレームには、ＧＯＰ（８）にてＲＥＦ（７）を
　≒３０フレームには、ＧＯＰ（１０）にてＲＥＦ（９）を、放り込んで見た


＞　そこで、問題点が２点ほど発覚した


　‥パソコンからでもどことなくもたついてるシーンが見られると思いきや
　肝心のテレビUSB挿しでは、とんでもなくもたついた
　（基本的に使えない、ＤＤＲ５程度のメモリー規格で漸くに成立する予約プログラムっぽい）
　（ということはBD規格ってのは永遠のDDR2程度を前提にした品質って事なんですね）orz


　‥そして、それ以上に課題になるのが発色だ
　Ｂフレームの効果として後方参照がある
　前ばかりを参照していると、どうにも‥手綱捌きを要求されるっぽ‥

　Ｉフレームの映像を参照しがたい場合には、其より後ろ位置のＰフレームを参照する事になる
　今更述べるまでも無く、Ｐフレームからしか参照できないＧＯＰ間での後ろの枚数が多いと
　そいつらの出来合いには、どこかしらの発色が弱くなるパターンが発生してしまう

　‥このような不都合をＢフレームでは
　後方参照とＰＢ間での割り当てビットレート量のメリハリをやらかすことで
　そこの発色の差を‥錯覚させて復帰させる用途での効果を併せもたせてあるらしい（へぇ〜）
　（これもまた心理的エンハンスト概念という事に成るのかもしれん）


＞　そこから、結局、今や適切なビットレート量を把握してしまっている事もあり
＞　そこから、結局、今や適切なビットレート量を把握してしまっている事もあり


　....‥ＧＯＰ（３）、ＲＥＦ（２）に落ち着いた‥★☆★..
　（24フレームと30フレームとの差は、ビットレート量で調整するだけで十分に至った）

　‥ＧＯＰを短くしていくと
　ＧＯＰ距離の差に伴うＧＯＰ毎に発生するビットレートの偏りを抑制する効果を得る
　（つまり、ＧＯＰ単位で見ると、より均一にビットレート配分される傾向になる）

　‥テレビUSB挿しにおいては、制限帯域をやたらと突破されても困るので是しかない
　（FHD30フレームでは、結構なケースでギチギチの箇所が続出する‥なんてこったい‥）
　（ビットレート（48960）以上はどうにもありえない‥）
　（でもまだまだ場面によっては重いらしいので、DDR4メモリーマシンぐらい欲しいかも）


＞　‥適切なビットレート量
＞　もとい、均等な配分確率を高く期待できるビットレート値による効用って
＞　そんなにもすごいのか？？（それ以外に良好を得るようになった変化の差を判断できん）
＞　（‥AVCのバージョンも上がる度に良好にはなってるけど）
↓/続きを読む/↓

【エンコード日記】なんちゃって4ｋ化したものを再リップした場合のグデグデ課題

記稿.2021/05/03

＞　プログレッシブソースをＡＶＣでなんちゃって4ｋサイズ化したそれを
＞　後からダウンコンバートしようなどと目論んだのですが
＞　何をやってもどうやろうとも、いやんなシミの発生確率が上昇する傾向にハマるようです


　‥一次処理用途に4ｋ化して効果を発揮するのは、インターレース解除を目的としたソースのみ
　（インターレースにもいろいろとあるので、細かい調査はまだまだこれからですが‥）


　‥元々のソースに、もやもやとして動くシミ箇所があると
　アップコンバート方向の方が正確にテクスチャーパターンを保持しやすいので
　それを今度は縮小する段階で、ソースサイズでは目立たなかったシミ候補群までもが
　より強調されてシミとした斑に成り変わるということらしい


　‥いやんなシミ発生確率上昇のグデグデを避けようと思ったら、AVCでは役不足っぽい
（つまり、ＨＥＶＣに見られるテクスチャーパターンをスパッと落としてくる感とは）
（ダウンコンバート用途織り込み済みということかもしれない）
（ＨＥＶＣの心理的エンハンストにはその手の都合が含まれている‥）

　（ＮＨＫ放送では、各チャンネルへの配信から必須とした都合になるのは説明するまでも無い）
　（そして、4ｋからダウンコンバートされて放送されてる美麗映像のすべてはインターレースだ）
　（ＨＥＶＣではインターレースをサポートしていないのだから、ＡＶＣ映像のはずなのに‥）


　‥これはつまり
　プログレッシブ４ｋソースを
　ＡＶＣでプログレッシブのままにダウンコンバートする試みには、無理があると言う事だろう

　（ＨＥＶＣとはいえ、シミの見られないソースなんてほぼ無ぇ）
　（インターレース化にはそこを吹き飛ばしてしまう何かがあるとかなんとか‥）
　（とはいえ初期の頃の4ｋものダウンコンバート放送にだって粗があって酷い箇所も見られた）
　（高度な前処理をどこかに盛り込んだに違いない‥）


＞　正確に視認確認できる機材を持ち合わせていないので、これ以上は何とも申し上げられません

【エンコード日記】なんちゃって4ｋ化したものをリサイズする場合の注意点

記稿.2021/05/02

＞　M.E. 範囲：１６　→　３２


　‥まず動き推定の幅を倍にしないと
　３２ｘ３２分の動きをしっかりとした１６ｘ１６に置き換わってこない
　（これはすべてのなんんちゃって4Ｋのダウンコンバート時において必須である）


...
＞　マクロブロック16ｘ16のみのパターン


　‥なんちゃって4ｋを理想的で十分なビットレート値にて
　FHDサイズにダウンコンバートする場合でも
　なんだかんだとマクロブロックへのビットレートの割り当てが田分け状態に陥ってしまい
　シボシボした色合いになっちまうので、マクロブロック16ｘ16のみを用いる

　（‥するとレベル4.1でも行けそうに思えるのだが）
　（基本的な動き推定が‥対応している仕様なのかどうかが怪しい）
　（他との兼ね合いもあるので、うっかりミスをやらかさないためにもレベル5.1固定が望ましい）
　（有料アプリだと、お仕事義務としてレベル4.1までだったりするので、できると思うが知らん）


＞　マクロブロック8ｘ8までを用いるパターン


　HDサイズにダウンコンバートする場合には
　すじノイズ防止を兼ねて8ｘ8までのパターンを用いる
　併せて、ブロッキング軽減（1，1）を用いる

‥いろいろと用意されている重要度選別圧縮は、いやんなシミの要因になるだけなので使えない‥

　とはいえ、肝心のなんちゃって4ｋの状態を正確に判断するための機材が無いので
　プログレッシブのそれは、二度揚げ同然で、どうにも怪しいので
　インターレース解除のそれと同じやり方に統一しないとダメっぽい


　...‥驚くべきは、ＦＨＤを無理矢理半分のビットレートでやると
　その品質方向が、さらに1.125で割ったビットレートでのＨＤと同程度の品質だって事だった
　つまり9：8って事っすね...計算間違ってましたすんません

　（だがしかし、十分な品質になるようにビットレートを割り振った方がずっとFHDでの画質は良い）
　（ここの差を識別できないようだと、動画エンコードに向いていないって事になる）
　（そこを理解すればするほどに、悩ましくてしょうがない）
...

【エンコード日記】4ｋサイズに自動フィールドシフトしたら決まりましたん

改稿.2021/05/02...2021/05/01...

＞　まずプログレッシブ・ソースのなんちゃって4ｋ化をやってみた


　‥狙いは、FHDサイズでマクロブロックを16ｘ16だけに制限すると物足りなくなる
　だが、これに8ｘ8のマクロブロックを追加するのは
　4ｋサイズでの16ｘ16のみとで比べれば、マクロブロック的には同質だ
　サイズが４倍になる事でさらに微細化させると何が起こるのか？

　結果、FHDサイズではどうしても潰れてしまっていたテクスチャーがそのままに出力された
　（‥より均等にビットレートが割り振られるようになった結果に思われる）


　‥だが、HDテレビUSB挿しにおいては、サイズの関係上ファイル認識から弾かれる

　（今思い返したらmkvだった‥ｍｐ4で出さないとダメなのを忘れてたのでやり直し）
　（やっぱりダメだった‥orz）

　４ｋテレビでなら認識すると思うが、そちらのニーズとしては
　キュルキュル化＆４ｋサイズと言う事なら願ったり叶ったりに違いないが
　心理的エンハンストの値が（1.0）のままだと
　4ｋテレビで見ようとも、BDソースのそれと見映えに差は起こらない範囲だろう


（まぁ4ｋサイズ化して、さらにキュルキュルしたい向きには問題ないはずだ）
（まぁ4ｋサイズ化して、さらにキュルキュルしたい向きには問題ないはずだ）
（まぁ4ｋサイズ化して、さらにキュルキュルしたい向きには問題ないはずだ）


＞　と言う確認をした後に、インターレース・ソースを試してみたところ‥


　鱧の小骨を食らわんとモードでのそれをいきなり４ｋサイズにしてから
　ＦＨＤサイズにリサイズを繰り返すやり方が適切だった

　（AviUtlでの色の読み込みはどちらも自動の設定だ）
　（で、４２２のBt.709でut.video出しする）
　（あくまでなんちゃって4ｋ化なのでbt.2020等や10ビット化は無視して忠実再現を目指す）


＞　ビットレート設定は暫定のそれを用いる
＞　まぁ↓の感じ


レベル5.1（マクロブロック16ｘ16のみを利用）
3840x2160（FHDプログレッシブソース）
ビットレート：39168（24フレーム）
2880x2160（FHDプログレッシブソース）
ビットレート：29376（24フレーム）

レベル5.1（マクロブロック16ｘ16~8ｘ8までを利用）
1920×1080（4ｋ化インタレース解除ソース）
ビットレート：48960（30フレーム）
1440×1080（4ｋ化インタレース解除ソース）
ビットレート：36720（30フレーム）


※インターレース解除した4ｋのまま4ｋエンコードするとビットレートが不足するに違いない
　FHDサイズ指定で一杯一杯くさいし
　それでなくても、ソースのビットレートより多めの場合には、ノイズ感がその分弾かれるので
　敢えて、ソース寄りのノイズ感までの忠実再現に意味を見出そうとするまでのメリットを感じない


　‥ディテールとしてはFHDに落とす事で一致するが
　4ｋサイズのままだとピンボケた印象になるのは
　インタレース化に因るデータ損失分が絡むのでどうしようもないっぽ

　（それでもエッジ感を強くしたいと思ったら、鱧の小骨を食らわんとの値を変更する策になる）

　‥だが、DVDとの設定と違ってくるとミスるパターンの発生を避けられないので
　それはそれでより詳細な確認が必要になる（効果大ならそりゃやらざるを得ないわけだけど）

---

‥↓はまだ未確認
...レベル5.0...（マクロブロック16ｘ16~8ｘ8までを利用）
DVDソースをいきなり4ｋサイズ化解除してから、720ｐサイズに落とす想定
もしくはBD（プログレッシブ）を4ｋ化したそれを720ｐにダウンコンバートし直す想定

1280x720
...13056（24フレーム）／16320（30フレーム）...
960x720
...9792（24フレーム）／12240（30フレーム）...

よくよく考えると4ｋからのHD変換は
16ｘ16の9個の点を
8ｘ8の8個の点に置き換える事に等しいので
半分で割って、さらに1.125で割るのが適当か？

さらにレベル5.0では、3,840×2,160の30フレームまでを扱えない仕様だった
それの不足からいやんなシミが発生するし
フェードのタイミングまで違ってくるのでレベル5.1固定で良い

↓

レベル5.1（マクロブロック16ｘ16~8ｘ8までを利用）
1280x720
17408（24フレーム）／21760（30フレーム）
960x720
13056（24フレーム）／16320（30フレーム）


＞　いやはや、容量減らない再エンコードに意味を見いだすってのは大変でーす

【動画エンコード】ビットレート配分とマクロブロックと心理的エンハンストの基本理解

↓2)記稿.2021/04/23

　‥動画エンコードの説明では
　Ｉフレーム、Ｐフレーム、Ｂフレームに分解する説明だけはよくされている
　だが、圧縮の品質に付いての説明は、それだけでは不十分なのに
　なぜか、そこから先の説明に関しては、口を濁して自信喪失している記事が多い


　‥圧縮の品質を上げるには
　ビットレートを増やす事が最重要ではあるにしても
　折角増やしたビットレートが、どのように割り振られているかを理解しておく必要がある


＞　まず、映像の一枚一枚を
＞　ピクセル単位からマクロブロック単位に置き換える
＞　（是により、マクロブロック単位で割り切れない端数すぎる解像度を使用できない）


　最終的にビットレートの配分は、マクロブロック単位へと切り分けられる（ＱＰ）
　この時、特定のマクロブロック単位へのビットレート配分が少なすぎていると
　問答無用で、所々で形を有していないピンボケ状態の格子に堕ちる

　でもだからといって
　全体により多くのビットレートの割り振りをするのは非効率である
　ということから、マクロブロック単位内での再度割り振りをやらかす仕組みが（ＡＱ）だ

　これはどんなにビットレートを割り振ろうと
　それぞれのマクロブロック内でピッタリとした細かさの構成は難しいのだから
　過不足の発生はやむを得ないのだから、ＡＱをオフにしては損だとしたアルゴリズム理解だ


＞　この時、平均的なＱＰ配分だけに縛られていると
＞　ＡＱ内割り振りの段階で、無駄に多すぎるパターンが発生しがちのままになる
＞　そこで、この無駄とされる部分を如何に減らして
＞　その分をより必要とする動きや複雑さにビットレート配分を回せるか‥
＞　とした技術的な課題が付きまとう


　‥一見これの理屈にどハマりすると
　ＡＱ効果をより発生させずにＱＰ配分を器用にやらかしたい
　とした問答に映らなくもないのだが‥
　（始めっからそんなの無理、それが非可逆圧縮だ）

（そこで存在していたのが２パスの立ち位置だったということになるらしい‥）

（だが庶民の視覚能力はスカポンタンだったのでそうにはならなかった‥）
（というか技術者側の生活保護にも黙りを決め込んでいたオチだろう）
（技術者が自分たちの生活保護のために技術公開を黙秘しすぎるのは問題がある）
↓/続きを読む/↓

【エンコードレシピ】暫定整理（X264FHD最適ビットレート,Level5.1,i8,p8,b8）

↓12)改稿.2021/04/06

＞　縦1080のサイズは、16x16のマクロブロックでは割り切れない
＞　なので、内部1088計算でのビットレート割り振りを予想する必要があった


1920×1088÷256
195840（24フレーム）／244800（30フレーム）
12240（÷16）／15300（÷16）
13056（÷15）／16320（÷15）
16320（÷12）／20400（÷12）
19584（÷10）／24480（÷10）
24480（÷_8）／30600（÷_8）
32640（÷_6）／40800（÷_6）
39168（÷_5）／48960（÷_5）
48960（÷_4）／61200（÷_4）


　‥↑で確認すると
　以前からのマクロブロックi4,p4を効かせて、b8を切るやり方だと
　なぜか、発光色が画面から浮いて見えてしまう傾向を得る（39168時）
　I,pにビットレート多めである要素が、逆に、bフレーム側に動きのアンバランスをもたらすらしい
　（平均的では無い事からの動きムラ‥ｂフレーム側割り当て不足の発生は他にもありそう）

　‥そこで、（39168時）Level5.1,i8,p8,b8までとしてみたところ
　動きの印象としては、より平均的に落ち着いて見える傾向を得る
　（tsソースより増量してしまうだろう点はあしからず）

　‥基本的にマクロブロックを多くすると、その分の符合量が増すわけだが
　Level5.1,i8,p8,b8までと、Level6,i4,p4,b8は同じ符合量らしい、なので増減差は無い模様
　（演算は、8ｘ8のマクロブロックまでの扱いの方が速い）


L5.1--i8,p8,b8
1920×1088÷256
195840（24フレーム数）／244800（30フレーム数）
13056（÷15）／16320（÷15）：480
19584（÷10）／24480（÷10）：480→1080
39168（÷_5）／48960（÷_5）：1080

1440×1088÷256
146880（24フレーム数）／183600（30フレーム数）
_9792（÷15）／12240（÷15）：480
14688（÷10）／18360（÷10）：480→1080
29376（÷_5）／36720（÷_5）：1080


　‥ビットレート割り振りが合致し得ない値だと
　ｂ8への相対的なビットレート配分の低下から、イヤンなシミがわずかに残る傾向を見せる

　（つまり、ｂ8x8のビットレート配分の予測は、ヒト側の考えより遥かに低品質に落ち込むらしい）
　（だからといって切ってしまっても良いかというと、より平均的な印象を得るには欠かせない）
　（すると問答無用で、高ビットレートの割り振りを要求する）

　（‥Ipb間での配分バランスが不均等だと、Bフレームの品質にムラ気がでる傾向だ）
　（だが通常は、ｂ16x16がほとんどだろうから誰も気がついちゃいない）
　（というか需要は品質向上云々よりもディスク規格に収める事だから、妥協せざるを得ない）
　（というかマスターからのエンコードの方が圧倒的にくっきりしているので16ｘ16でも十分っぽ）

※　ということから、HDR映像の発光効果を安定させるにしても
　尋常ならざるビットレートにおいてさえ、平均的な割り振りが欠かせないのかも知れない
　（もとい、若しくはその逆で、片寄りこそが発光感をもたらしているオチかも知れない）
　（とはいえ、HEVCはBフレーム中心だから‥平均的な割り振りの用に思われる）


※参考：720÷1088＝0.6617647058823529（とりあえず割り切れるらしい）
1080→720（1920）：25920（24フレーム数）／32400（30フレーム数）
1080→720（1440）：19440（24フレーム数）／24300（30フレーム数）
（こんなにビットレートを要求する720ｐなんて誰も使うまい）


　‥ちなみに、各ビットレートの値は経験に基づく予想値です
　すべての値での検証はまだ行っておりません（あしからず）
↓/続きを読む/↓