【テレビ設定】目の疲れにくい好逸オート（TN風TXT専用）

記稿.2021/02/19

＞　テキスト打ち仕事に液晶テレビをモニターにするには明るくありすぎる
＞　と言うことで用途不明のオートモードに辿り着きました
＞　但し、このモードでの映像視聴をオススメしません（慣れると又違って見えちゃうんだけど）


◇◆テレビ項目設定◆◇
映像メニュー：オート（限定）

バックライト：−２４‥※すべて±３０からの差分になります
ピクチャー　：−２０‥※±の幅が違う場合は比率を割り出して試してみましょう
黒レベル　　：−１６
色の濃さ　　：　　８
色合い　　　：　　４
シャープネス：　　０

液晶ＡＩ　　：オン（10月頃~2月頃にoffにするよりはオンのままで良いらしい）
色温度　　　：低−中
ビビッド　　：オフ
超解度　　　：オフ（操作不能）
ＮＲ　　　　：オフ
ＨＤオプティマイザー：オフ
明るさオート：オン（操作不能）
テクニカル　：切（操作不能）

【エンコード日記】テクスチャーを99％らしく保持してビットレートを半分に（1080ｐ）

記稿.2020/12/17

＞　これより先は[AviUtl]と[XMedia Recode]の二刀流になります


　‥ちまたに転がるアニメのリップファイル（1080ｐ、≒24フレーム）には、高品質なのも見られますが
　所詮は、Ｂフレーム重視×低低ビットレート（10000以下）域タイプです
　その結果、Ｐフレームが外されて輪郭が目減りしており、ボケ気味です

　それらのリップファイルの輪郭をどうにかしようとすれば増量させざるを得ません
　「それに意味はあるのか？」の問いは勿論ありますが
　それらを程度どうにかできるということは
　それと同じ容量程度で逆のこともできるはず‥


　つまり、BDtsのテクスチャーを保持しつつビットレートを半分にできるはず‥ということです
　（それができれば、720ｐとはおさらばです）

　映像のボケを直すには、シャープフィルターありきです
　シャープフィルターを優先して利用します
　逆のことをやろうとするなら扱いを逆にすべきが理屈です


＞　つまり、敢えて適正にぼかした映像に改造‥下処理してから、再エンコードしよう作戦です
＞　‥720ｐにてテクスチャ崩壊しちまうよりはずっとマシな選択です
＞　‥解像度維持にて、単にビットレートを減らすだけでも、部分崩壊やらかしますからね


　（ＣＧ処理という奴は、人の目で判断できないことを判断できてしまうので）
　（下処理でぼかすにしても、それの適正値さえ得られればこっちのもんです）

　‥まず、BDtsをAviUtlに、16ビット設定（プラグイン利用）で読み込ませます
　ぼかしフィルターの順位をシャープフィルターより一つ上位に設定します

　（10ビットソースの場合は、10ビットで読み込ませます）
　（8ビットソースの場合は、丁度二倍にできるので16ビットでやります）


　標準実装のぼかしフィルターの値を
　強さ：168
　範囲：2
　下限値：2
　上限値：1008

　標準実装のシャープフィルターの値を
　強さ：252
　範囲：2
　下限値：2
　上限値：1008

　に設定します

　その状態で、ut.videoで、BT.709，422を選択して出力します
　（色の設定は入力・出力ともに自動にしておきます）

　抽出されたノンレスファイルを（ソースから見れば、もはやノンレスではありません）
　XMedia Recodeにて、19008000ビットレート、partitions all、レベル6でエンコードします
　その他の数値はとろ重に倣ってください


＞　人間の感覚では、ぼかしの強さの方を強くすべきに思うところですが
＞　それだと720ｐに似通った間引きになるようです
＞　同量にしても単にビットレートを減らしただけと同じ傾向です
＞　なので、後から当てるシャープフィルターを強くした方が良いと言う意外な結果を得ています


　（まだテスト確認中なので速報扱いになります）

【エンコード日記】動画再生支援機能の罠

記稿.2020/12/15

＞　VLCプレイヤーにおいて、ハードウェアによる動画再生支援にすると
＞　どんな低ビットレートでも、そつなく綺麗にされて見えちゃってまーす


　つまり、バリバリに瞬時に補正を掛けまくっているということです
　（AviUtlで綺麗に見える‥なんてのも同じことかと‥）
　そんな糞リップの中身を、ソフトウェアデコードに切り替えて視聴すると
　途端に、とても見られたもんじゃない無残な姿を晒します

　（え☆こんなにヒドかったん？？？）

　で、動画再生支援に固定しとけば良いと思うも
　CPUにもよると思うが（否、それにしたってｘ264での対応はレベル5.2までかも）
　レベル６を想定していない場合には、レベル６エンコード内容にて格子落ちが発生します

　この格子落ちを相殺するには、ソフトウェアデコードを用いることで解決するようですが
　まぁ若干、ハードウェアの方が発色が良いのかなぁと思う差があるような感じです


＞　ということで
＞　ハードウェアによるエンコードをやると綺麗にならない仕組みとは


　ハードウェアのデコード上限イコール能力で、超高速に低低ビットレートなエンコードしてたら
　そりゃデコードの際に、補正分の余地がなさすぎて、効かないってことになると思います

　なので、ソフトウェアエンコードで低低ビットレートをやると
　その分、補正を掛けられる余地が速度的に発生するから
　ということなのかなぁなどと思っちまいました（所有してないから具体的な状況など知らん）

　（そもそもからして、低低ビットレートでの静止画画質に期待などできるわけがない）
　（どうにも低ビットなjpg群が、加速して補正されながら再生されると綺麗っぽく見える仕掛け）

　どちらにしても、低低ビットレートの状態の内訳を
　プレイヤーのソフトウェアデコードで視聴した場合、ガチで糞リップである可能性が高くなるっぽ


＞　VLC＞ツール＞設定＞入力/コーデック＞ハードウェアアクセラレーションによるデコード
＞　DitectXビデオアクセラレーション(DXVA)2.0


　‥の状態にしておくと、BD再生時適応と同じであるらしく
　サーチ時に、BDソース再生時独特の格子模様を味わえる


＞　VLC＞ツール＞設定＞ビデオ＞出力(U)
＞　Windows用OpenGLビデオ出力


　‥の状態にすると（＊ハードウェア再生支援を無効にしておく）
　比較的ハードウェア再生支援に近い発色を得ているように思われるっす
　（VLCを再起動して確認の用あり）


＞　‥ということで
＞　レベル６格子落ちしないで見られる条件が判ったという事です


　マシンスペックの最低条件は？‥などという解には興味が無い

　ソフトウェアデコードで
　どのぐらいの低ビットレートだと糞リップな格子再生をやらかすかの端境に興味はあるが‥
　（調べる気無し）

【エンコード日記】DVD→1080ｐ化の際の黒帯をどうすりゃいいのか？（今更‥）

記稿.2020/12/08

＞　1920×1080ｐ（≒24フレーム）の時
＞　BD規格でのビットレートが概ね38000（ビットレート）


　‥なので
　1920×1080ｐ（≒30フレーム）の時
　同じ画質を得ようとすると1.25倍の47500（ビットレート）が必要と考えられるが
　誰もそこまでを望んじゃいないという不可解がある


　‥一方で
　DVD→1080ｐ化をした映像になると
　不思議とBDより丸まっているので半分のビットレートで済むらしい
　つまり1.25倍の適正実験がしやすい

　47500÷２＝23750
　（やってみると、Level6×partitions allの効きを十分に発揮するようだ）


　‥こうなると、
　DVD→1080ｐ化の際のLevel6×partitions allの適性が
　それぞれの半分ということで

　1920×1080ｐ（≒24フレーム）：38000（ビットレート）　→　19000（ビットレート）
　1440×1080ｐ（≒24フレーム）：28500（ビットレート）　→　14250（ビットレート）
　1920×1080ｐ（≒30フレーム）：47500（ビットレート）　→　23750（ビットレート）

　で、イケるということなのだろう


　‥ちなみに
　1280×720ｐ（≒24フレーム）換算にすると
　38000÷2.25＝16888.888…88
　なので、16875（ビットレート）にほぼ近い
　この差がｂ８×８が効くか効かないかの境と考えられるわけだが
　（720ｐ化には独特のややっこしさが付きまとうということなのだろう）


＞　ところで、双方共に、非解除3：2状態の時とは違い
＞　テレビUSB挿しでのテレビ側の自動調整は発生しない
＞　（というより1080ｐ化でやらかすならＰＣ再生前提だ）


　‥つまり、自動調整で起きているそれぞれを、自前で事前に処理する必要がある

　そこでまず、ＢＤts（4：3）ｉで縦解像度に帯が付いてカットされているソースから確認してみた
　結果、黒帯を取り除く事で、うんざりだった要素が解消するらしい

　参考：1416×1062、1408×1056　→　1440×1080化

（上下で16ドット分の黒帯がある時、８で割り切れても４：３では割り切れない）
（この割り切れない不都合が、パンシーンでのガクガクと化していた）
（黒帯だけしか取らないと比率が合わないので、合うように上下１ドット分カットせざるを得ない）
（このパターンの場合のみ‥≒24フレーム化ありきのような気がする‥）

（又、実写フィルムの場合、太陽光やらの露光影が発生するからか‥左右の黒帯に位置差が見られる）
（位置差の分まで削ろうとすると、全体を通してみた場合かなり削ってしまうことになる）
　（デジタル撮影では補正されてるってことかな？？？）


＞　‥で、改めてDVDソースを確認してみると
＞　「黒帯を‥どう切りゃ良いの？」


　調べてみると
　DVD規格の大前提として
　「DVDプレイヤーは必ずピクセルアスペクト比 10：11 または 40：33 で再生すること」
　というのがあり

　どちらにしても、704×480とした解像度に黒帯追加とした都合になる話なのだが
　中途にデータが盛られていると、そのままに切って1080ｐ化やらかしても違和感にしかならない

　そもそもなんで、DVD作品は横幅720で詰め込んでんだ？
　DVD再生機で再生する際には、横幅カットして再生するんだろう‥（意味ねぇじゃん）


＞　色々と確認するに


　‥とくにフィルムスキャンした状態の端が、どのような塩梅になるかは出してみないと判らない
　状態によっては、右端やら左端やらの片方を16ドット削った方が良い場合なども起こるらしい
　（なので、愚直に両端を８ドット分削りゃ良いという話にはならない）
　（これは４：３フィルムの場合になる）
　（状態が悪い側ほど段々のグラデ状だったりする‥ソース毎に注意して見ないと判断付かない）

　‥デジタル実写の場合は、どうせ平均ビットレートで出すともなれば
　黒帯にしようが、データを載せとこうがさして変わらない
　せっかくだから左右４ドットほどに体裁を整えた加工を施し
　残りの左右４ドット分に対しては、そのままを盛り付けてるらしい
　（デジタルとはいえ、撮影がインターレースともなると余白事情が絡むということだろうか？）
　その割には、上下どちらかの２ドットを削る編集も見られる
　（アナログに見られる手ぶれ分の誤差が少なきゃ、乱れてる側だけを削るのが流れなのだろう）
　（アニメでもそれが見られるのは、倣ってデータ枠を足し引きしてあるということだろうか？）


＞　‥なので、それぞれで黒帯域の付け方の定義が違っているとしか思えない‥
＞　（何ら手を加えないままだと、微に縦に細長い感じだ）


　個人で編集する分には、愚直に704×480に変換して後から黒帯を足すだけでも差し支えが無い
　商業になると、黒帯のままでは煙たがられるという作り込みの差ありきなのだろう

　（ズバリ、そんなこだわり編集に意味があるのだろうか？）
　（はじめから７０４×４８０の規格でええやん、ビットレートが勿体ない）
　（なんでそんな無駄をやらかす事になったかの黒歴史が登場しない点は解せん）


＞　話は変わるが、インターレース保持でのテレビUSB挿しで上手く行かないパターンの場合
＞　自動フィールドシフトでも標準的では無い結果をもたらす点を確認した
＞　（これも今更な話ではある）


　具体的に言うと、フレームレートを可変と書かずに偽装しちゃってるらしい
　（なにをやらかしているのかは不明）
　（その様な場合の対処に、自動フィールドシフトには３０フレーム固定ボタンが備わる）

【エンコード日記】これはどうにも妥協くさい‥orz

記稿.2020/12/04

＞　いきなりですが抜粋です（ソース）


（ｂ）高域成分を低域より圧縮することによる損失
　人間の目の性質から、低域は視覚的に敏感であるため画質をよくするため多くのビットを割り当て、視覚的に鈍感でしかもデータ量の多い高域を粗く量子化することにより、効率的な圧縮ができる、また、この反面、情報量を失った高域部分の影響で、デーコードされた再生画像は、高域の量子化雑音の発生で高域のざわざわしたモスキートノイズを生ずる。

（ｃ）量子化マトリクスを適応化することによる損失
　量子化の目的は、圧縮効果を得ることであるが、画像データブロックの性質により同様に圧縮しても劣化が目立つものと目立たないものがある、これをブロック毎に分析して適応的に量子化する。
　この場合の適応には、周波数成分によるものと画像の局所的な特徴によるものがある。
　高周波による適応は前期のようにDCT係数の低次に多く高次に少ないビットを割り付ける量子化を行い、局所的に特徴量に対しては、ブロック内の分散を検出して、変化の少ないところにビットを多く配分する。適応的量子化で全ての画像を完全に分析して適応化することは難しく、画像データブロックの特徴の分析にミスが生ずるとかえって劣化を招くことになる。


＞　‥具体的に噛み砕くと


　ビットレート不足からの劣化はどう考えたって回復不能
　ノイズ感が多いと思ったら、ビットレートを多く盛りましょう

　動きのあるテクスチャーは、比較的正確に検出できるが
　動きの小さいかまるで無いテクスチャーは、動きが無いと判断されればされただけ間引かれる
　ということなので
　リップのリップとした繰り返しをやると動きの無いと判断されたところほど
　それはもう入れ子式算に劣化をやらかすことになる

　（まぁそういう傾向があるというのが、解決不能だったと言うことだけがはっきりしたった）


＞　‥そこを踏まえて、とろ重（1080ｐ）の塩梅は如何に？


　ビットレートの適性範囲が、どうにも、38000000ビットレート（アニメ）
　≒24フレームと≒30フレームの差として

　≒24フレーム：GOP（8）、ｒｅｆ（4）、partitions all
　≒30フレーム：GOP（10）、ｒｅｆ（4）、ｂ8ｘ8を使わない

　とした720ｐとは異なり、幾分画質重視にしないと、全然ダメ
　1080ｐの≒30フレームの場合、ｂ8ｘ8を十分に満たす許容が全くの不明
　どうせ増えすぎたって忌み嫌われるだろうから
　≒24フレームと同じビットレートでやり繰りする範囲として、使わない選択になった

　（普通に1.25倍にすりゃ良いなら47500000ビットレートになるが‥そりゃあかんでしょ）
　（ただでさえ、2PASS平均ビットレートにしないとLevel6格子が安定しないんだからそんな感じ）


＞　まぁ、BDtsソースが36000000ビットレートならそれに従うのがベターでしょう
＞　（まだまだ確認中です）


　‥あと、デコードについては、ある程度の自由さを了承しているとの事で
　折角あれこれ悩んだリップも
　デコード次第（プレイヤー次第）では、ぶち壊しになったりそうで無かったりと
　得手不得手をやらかしてくれるという規格内容になっている


　（実際にも、VLCプレイヤーとテレビＵＳＢ挿しとでの差の出るソースを確認している）
　（ということは、ＨＤテレビとＦＨＤテレビとも違うというで、orz）


　なので、確認している静止画が必ずしもどのプレイヤーでも同じとは限らない

　つまり、一つの優秀と思い込んだアプリ頼みでやってると
　気づくのが遅くなったりする事にだってなる


　（あーもう面倒くせー、なにを信じりゃ良いんだよ！！！）

【エンコード日記】テレビＵＳＢ挿しインターレース自動的解除の決定的な弱点

記稿.2020/11/19

＞　業を煮やして、エンコード設定を「とろ重」から
＞　2-3プルダウンに特化した、GOP（5）、Bフレーム（0）、ＲＥＦ（4）にしても
＞　リバウンドを繰り返す箇所がどうにもならない事から


　インターレース処理のなんらかが
　リバウンドを繰り返すような短いＧＯＰならではのその間にすっぽり収まると
　どうにも解消できないというのをようやくに理解した

　つまり

　はじまりのブレ駒はいつだって２枚、３枚でしか参照できないので
　きっちりと４枚分参照できる状態にないと、ブレを解消する為のデータ不足で
　リバウンド現象にハマったりもするという事らしい

　‥このようなグデグデを解消するには
　2-3プルダウンからテレシネしたGOPの頭から二枚目と三枚目だけは
　後方を足して合わせて４枚参照できる構造が求められる

（というか普通にそういう構造にしないと、平均的な圧縮率の追求としては不足していると思う）


＞　話は変わるが


　ＶＬＣプレイヤーの設定を解除オフにしたまま使っていて
　いつの間にやら、解除オンが効かなくなっちまっていたのだが
　今回、試しに弄ってみたら、普通に機能するようになったのだが‥

　（これって更新時にオフにしておくと、そのまま機能しないオチだったのだろうか？）
　（それとも妖精さんのイタズラだったのだろうか？）

　１５年近い歳月を無為に、インターレース解除できねぇ不満を抱えていたような‥
　否否、ＶＬＣプレイヤーの性能がどっかでボケて、どっかで復活していたとか
　（繰り返し機能だって、使えねぇ状態に陥るからな）
　その辺の波のままに思い込んでいただけだったとか‥

　（なんかこう、そこはすっきりしないのだが）
　（ソースのそのままの解除画質を確認できたので、その点はすっきりできた）

　ＢＤに関して言うと、無理に解除リップせずとも綺麗だったりで‥orz
　ＤＶＤの方は、手の入れようがあるとだけ理解した


＞　そんなこんなで


　‥インターレース解除には
　アナログフィルム時代ならではの2-3プルダウンされているタイプと
　そうでないデジタル時代ならではの概ね２枚でセットでやらかしているタイプと
　さらにそれを特化して、部分的なインターレース状態というのがあるのを混同していて

　DVDのGOPがM=3, N=15だったりで
　奇数でもいいんだと思っていたが、それだと
　トップとボトムの入れ替わるケースが頻繁にでちまう臭いことに、今頃になって気がついた

　そして

　テレビUSB挿し頼みの自動的解除の更なる弱みとして
　テレビ放送の規格外のインターレース処理に関しては脆いというオチがついて回る事を
　ようやくに理解した


＞　つまり、自動的解除できるのとできないのが出てくるのは、当然の結果だった
＞　さらに、再リップ時の劣化が大きすぎるとダメになるパターンとそれの逆のパターンとがある


　どうにも煮え切らない作業はクリエイティブでないので詰まらないので
　もう少し、職人芸を楽しめそうな作業をしたいので
　AviUtlプラグインの「自動フィールドシフト インタレース解除」を試してみた

　なんか自動と手動を両方入れないとどうたらと書いてあったので両方入れたのだが
　機能がダブっているようで今ひとつよく分からないところはあるが
　なんとか使える状態が分かってきて思ったのが
　普通にトップとボトムを合わせるだけでは違うらしい（へぇ~）

　（GOPの関係で入れ替わったりすりゃ当然だ、今理解したｚ）

　そこの塩梅のうんちくはさっぱりだが、エッジやらコーミングやらを
　すべて取り除こうとするのは野暮ってもんで、上手に利用しようとの空気を理解した


＞　世界観がまったく違ってたンゴ！！！

【エンコードレシピ】絶対無敵！月下のとろまぐろ重

↓12)改稿.2020/12/02...20201117...

｜十三夜 泪のような部屋明かり ビットレートにまで透けにけり

　‥本日の十三夜の月明かりが部屋の窓辺に泪のようだ
　泪のように美しいのか、泪を流すように儚いのか
　トライ・アンド・エラーの動画エンコードとは
　まるでそんな涙の量を重ねてしまった果てのビットレートの増量傾向に似ていて
　どうにも「月下涙焉（げっかるいえん）」だなあ

　‥これはガチで勝負エンコードだあと思いつつも
　また次の満月がやって来るように終わり無く、切り無く
　ただ、それの姿を移ろいてでも見てみたいとした欲がもたげちゃっただけかもなあ


＞　すべての諸悪その名は「Ｂフレーム動きベクトル」‥（誤差が大きすぎて使えねぇクズ！）
＞　すべての問題を丸く収めてしまう2pass平均ビットレート方式
＞　だがしかし‥カラー優先度をはじめとした三点盛りを無用の長物へと葬り去る権化だった
↓/続きを読む/↓

【エンコード日記】行列係数と伝送特性を付けてるとBフレームが‥だった件

記稿.2020/11/15

＞　可変ビットレート（０）にして、鮪丼に、よりビットレートが均等に割り振られる云々よりも
＞　行列係数と伝送特性を付けていると
＞　低いビットレートにおいては、Ｂフレームの割り当てが悪くなってしまうらしい


　‥さらに
　それ以前の中身として、ＧＯＰ（８）にしていると
　Ｐフレームの重み付けが解除されてオフの扱いになっていた

　つまり、すべてのＰフレームが

　（設定によるＩフレーム爆発から）何らかのＩフレームを参照する状態に置かれているので
　重み付けをする必要が無いほどに想定内品質にあることから
　逆に、Ｂフレームとの品質差が大きいらしい

　（その理由としてか、Ｂフレーム側の重み付けは据えおかれているかのようでもある）
　（まぁ３枚有効だからだろう‥ＢＤだって多くは２枚程度だからな‥）


　‥またそれに関連してだろう
　Ｂフレーム無しにすると、ＧＯＰ（８）から
　Ｐフレームの重み付けが解除されてしまう成り行きで
　想定外のＩフレームの連続帯が生じてしまうものと思われる


　つまり


　Ｂフレームのマクロブロックをより細かくしては
　割り当てに因る品質差がより大きくなってしまうので
　Ｉ４ｘ４、Ｐ４ｘ４、Ｂ１６ｘ１６の構成が、鮪丼としては具合が良いらしい
　（なにはともあれＩＰ（1.4）、ＰＢ（1.3）の差はどうしようもない）

　結果的に、行列係数と伝送特性の指定は「無し」×可変ビットレート（１）で丁度良いぐらいっぽ


＞　いやぁもう‥はじめから全部確認のし直しです‥orz

【エンコード日記】インターレースの深淵に「Ｋ.Ｏ.」したった件

記稿.2020/11/12

＞　DVD4：3は、11250（ビットレート）でも頑強のようだが
＞　DVD16：9は、品質を90年代アニメに適うようにMAXに上げた結果
＞　テレビUSB挿しにおいて、インターレース縞の誤検知が発生してしまうらしい


　‥つまり、今度は誤検知が起きない程度に
　MAXに上げた品質から下げる必要に迫られてしまった（ンゴ！！！）


　‥例えば「獣の奏者エリンOP」では
　母と娘が手を繋いで歩いているシーンが、右側に小さくあったりするカットで
　インタレース解除が上手くできていないと思って、ちょいと逆サーチしてから再再生確認すると
　問題なく解除されている状態を繰り返す

　それと似たような箇所が他にもあり、タイトル全体で考えると悩ましい

　これは完全に誤検知が発生しているとしか思えないケースだろう


　‥例えば「かなめもOP」では
　踊るタイトル文字表示の箇所から以降、タイミングずれが訂正しきらずにそのままになる

　AviUtlでコマ送りしてみたら
　激しいパンでカク付かないように
　なんとインターレース映像の二重撮りを含ませてあった（ンゴ）
　お陰で最大５枚連続のブレ駒が続いており、その前には４枚箇所がいくつか見られ
　完全にその影響からだろう‥タイミングずれが訂正しきらないままの状況に陥るらしい

　他にも普通に二枚連続の箇所にも、インターレースの二重盛りがされていたりしている
　タイトル全体で考えると卒倒しそうなこだわりを見せているようだ

　つまり是などは、完全に誤検知されないように品質を落とさなくてはならない


＞　DVDのタイトル毎にそんなこだわりを噛ましてあるんじゃないかと思うとうんざりだ
＞　（縦縞タイプのインターレースを見た事あるけど、これなんかどうなるんだろうね？）
＞　さらに悩ましいのがBDインターレースの場合だ


　DVDとBDとの差を嫌ったのかどうかまでは知らんが
　ここまでやって見せているとなるとそういう事だと思うのだが
　BT.601で読み込んで、なんちゃってBT.709をやらかしている1080ｉが存在していた

　フレッシュプリキュア！ＯＰではまるで気が付かなかったが
　フレッシュプリキュア！ＥＤでそれが発覚した

　（まさか‥ＯＰとＥＤで違うのか‥組み合わせてあったりすると一発出しは完全にお手上げだ）

　つまり、なんちゃってなのでBT.709でも色がおかしくならないように
　平均ビットレートを下げている
　（他のBDインターレースと比べると平均ビットレートが低すぎる）
　（少ない割りにはどんなに盛り込んで再リップしようとソースより品質が良くならない）
　（なんちゃってBT709とインターレースに、エンコーダーが右往左往しているとしか思えない）
　（もはや解除してからエンコードするほか無い）


　‥実際、同じことを1080ｐ→16875（平均ビットレート）720ｐでやってみても
　ビットレートが規定とされる25000を下回っているので、ほぼ安定的だ
　（AviUtlからBT601を介してなんちゃってBT.709でも余裕らしい）

　‥だが残念な事に
　テレビＵＳＢ挿しで発生するマムシ沙汰にコマ落ちソースのパターンは、挿してみるまで判らない
　そんときゃ、AviUtlからBMP介してut.videoにしてからエンコードするとマムシを退治できる

　とは云え、タイトル毎でBT.601からのなんちゃってBT.709にしてある場合もあるので
　プログレッシブだろうと、色が怪しいと思ったらそういうことだと思った方が良い


　‥しかしそうなると
　AviUtlでの色をBt.601で読み込ませるべきかBt.709で読み込ませるべきか
　はたまたAviUtl独自のLWなんとかで読み込ませるべきかはソース次第ということになってくる


＞　なので、これなら一発楽勝ですとの案内はもはや無理ッ‥orz
＞　自分でちゃんと色を比較確認してチェックしないとTIGEEってことになる


　（せっかくそろそろレシピにまとめられるかなと思っていたのに、空振りだった）

【エンコード日記】鮪丼（720ｐ）再開しました

記稿.2020/11/09

＞　結論から述べると


　実写には1080ｐ（16ｘ16のマクロブロック）が適切だった
　そのまま低ビットレート（25000以下）に落としても特に問題は見られない
　むしろ、鮪丼にしない方が発色が良い

　ところが

　アニメの場合、解像度やらビットレートを下げると16ｘ16のマクロブロックだけでは破綻する
　どうしても横筋ノイズの発生が避けられない（設定がまずいと縦筋ノイズも発生する）
　それが平均ビットレート時の難しさになる


＞　それを避ける為の扉がなんと、可変ビットレート（0）だった


　‥可変ビットレート（0）にすると
　Level6での4ｘ4のマクロブロックにまで均等にビットレートが回されて画質がUPする

　（UPすると言っても、横筋ノイズの発生をシャットアウトできるとした範疇になる）

　なので、ビットレートがＢＤ並に十分にあるとその差はほどんどわからない
　その様な場合は、やはり16ｘ16のマクロブロックで十分と言えそうだ

（‥違ってくるとしたらアニメのインターレースものぐらいだろう）
（但し、インターレースの鮪丼の場合、4ｘ4にもキッチリとビットレートが盛られてるっぽいので）
（増量感が半端ない‥どうにもインターレースの隙間にも同程度のビットレートが入るとしか‥）
（そうしないと品質が上がらないが、グデグデなのでやはりインターレース解除の方が早道だろう）


＞　なので、鮪丼が必要になるのは
＞　アニメにおいてのダウンコンバート時ノイズ防止用途だけになる


　一方で、解像度1080（アニメ）のまま変えずに、低ビットレートだけを割り当てるやり方では
　鮪丼をやろうとも不適切なビットレート割り当てがそれなりに発生した状況で変わらない

　（この辺はアニメと実写とでは、まったく異なっているので注意が必要だ）

　‥一方、1080から解像度を下げるとテクスチャー破綻を避けられないが
　マクロブロックへのビットレート割り当て不足からの部分箇所での破綻を容認するよりは
　解像度減分のテクスチャー破綻を選ばざるを得ない

　なぜなら、Level6での鮪丼を回すにはそれに適ったGパワーが必要になるからだ
　テレビUSBではそちらを耐えても、瞬間帯域の不足の方が悩ましく
　その辺の算盤勘定を整えると、どうしても720ｐの方が適切になる


＞　但しそれでもビットレートの割り当てには慎重にならざるを得ない
＞　それでなくてもLevel6での鮪丼では、格子欠けの発生が気がかりでしょうがない


　そこでDVD並の11250（ビットレート）を割り振ってみたところ無事に回った
　でもなんだか発色がそれなりに浅黒く感じられる（実写になるとてきめんだ）
　さらに、スタンダードモードでは明るさが足りていない

　つまり、スタンダードモードで適切に視聴できるようにするには
　ダイナミックモードより多くのビットレートを必要とするらしい（推定２倍差）


　‥で、11250（ビットレート）でのエンコードでは
　アニメOPあたり130MB程度、２５分あたり２GBちょい程度になる
　なので、発色を納得できる程度にするのに求められる値にしても
　平均ビットレートなので1.5倍にすれば、そのまんま16875（ビットレート）で3GBコースだろう

　‥16875（ビットレート）あたりでも格子欠けせずに回るらしい（調査中）