【エンコード日記】DVD二度揚げ再没、帰ってたCRF（12.x）とんで‥ｂ8ｘ8もありの件

↓3)記稿.2020/02/26

＞　DVD一度揚げの品質をより良くしていくと
＞　なんと、解像度を落としても自動的インターレース解除しなくなるっす‥orz


　‥ＢＤの自動的インターレース解除の場合には、今のところそのような傾向は見られない
　これは、補間に耐えうるデータ量があるかないかの差に思われる

　‥ついでに、ＢＤインターレース解除の場合、質さえ良ければ
　二重化を用いた1080ｐでのインターレース解除でも、それ程ぼけたようには見えない
　（その他要素も加味するかも知れないが、ＤＶＤほどにぼけることは無い）


＞　‥ということで、DVD二度揚げはどうにも没になりました（時間の掛け方はいくらでもある）


　というわけで、DVDを再エンコードやらかすにあたり
　1080ｐを望む声は多くないでしょうから、540ｐか720ｐかの選択になると思います

　ところが、元々のベースが1080ｐからの縮小です
　DVDの容量に収める為に、泣く泣く黒枠を設けたり、端を削ったりしてやり繰りしていたりします
　さらに、プレイヤーとエンコーダーでの差も絡むことを確認しました


（XMedia Recodeの場合、ピクセル管理は２ｘ２からになっています）
（解像度の奇数設定を始めから無効化してある作りっす）
（一方、VLCプレイヤーは、DVDの端数値853ドットを許容します）
（この差が頭から発生してあるので、正確も糞も無かった‥orz）


＞　853ドットを854ドットから計算すりゃそりゃ比率違うから
＞　その点、デコーダー側は、表示の問題だから端数だろうと都合を付けられるのだろう


　‥これはマクロブロックの数の問題に直結してきます
　ブロック計算に端数はありえません

（じゃ、DVDの中身はどうなってんだ？、mpeg2の勉強なんてやる気ねぇから知らん）


＞　‥ということで、マクロブロックの数を確認してみましょう


　1080ｐでの一般的な設定は、Ｉ４ｘ４までです
　それも、BDなら１秒に１枚あるかないかの配置ペースです
　さもＦＨＤと囃し立てたところで、その中身は、実質８ｘ８単位までの細かさです

　‥なら、どうしてＩ４ｘ４は残ったのでしょうか？
　（そりゃ、ピンナップ用途で欲しかったからとかなんとか）
　（撮影用途（インターレース）での都合から、用があったかもしれないとかなんとか）


　‥そこはさておき
　その数が１９２０ｘ１０８０　→　２４０枚×１３５枚
　これに対してＰ４ｘ４までを効かせたＢフレーム無しの５４０ｐの場合、同等になります

　ゆえに、マクロブロックのイメージを損ねることなく、半分に縮小できる算段になります

　‥ところが、７２０ｐになるとこれが崩れます
　１２８０ｘ７２０　→　１６０枚×９０枚（８ｘ８）、３２０枚×１８０枚（４ｘ４）
　（Ｐ４ｘ４まで効かせれば、動きの質はＦＨＤより上に思えなくもないのだが‥）


　‥黒枠の境がピタリと（８）や（４）で整っていれば誤差も少なくなるのでしょうが
　現場の判断でどうなるかは不明です
　１２ドット幅なんてことになると、どうしたって、黒枠を抱えたブロックが登場したりします
　中には、はじめから端数を嫌って、意図的に左右対象幅に整えっていなかったり
　容量の都合から、泣く泣く端を削ってあるようなソースも見受けられるのです

　‥そこを何も考えずに問答無用で黒枠嫌い爆発で
　わざわざ好んで黒枠を剥がしてエンコードなんてのは論外です
　それはその分、画質ぼけの追加要素に奔走しちまっています
　比率の変更されちまった画なんて、ただただ残念なだけでしょう


　‥で、その変更が
　エンコーダとデコーダーの間に存在しちまうのがＤＶＤ規格でのどうしようもねえ状態だった‥orz

　（そもそものmpeg2自体に、再現性誤差がある造りというのは、規格側でも確認されている）
　（外野が今更、ガックリすることでも何でもねぇ、そういう中身だってことっすから）

1-3)1

＞　ＤＶＤを５４０ｐでリップするのは非常にムズかしくありました
＞　そもそもの５４０ｐの扱いがしづらく敬遠されてきました


　‥そもそもは、マクロブロックの問題に始まります
　‥次に、qcomp値の固定的使用が思い込みで誤っていました（解像度毎に適値が異なります）
　‥そして次に色の指定があがります

　‥ＤＶＤの場合、SMPTE170M（BT.601PAL）の指定が欠かせません
　これは720ｐよりサイズを大きくする場合、指定さえしておけば、BT.601を維持します
　維持しないと色が痩せて潰れてしまう場面がぞろぞろと出現しちゃいます

‥なら、DVD自体の色だってそうに違いないと思うところですが
‥どうにもそこがインターレースの不思議という奴で、高周波を多く残すことに利があったようです

　その逆も然りです（1080ｐ→540ｐ）

　BDからのリップの場合、BT.709をきっちり指定しておかないと
　540ｐ時に色痩せしてしまいます
　プログレッシブのソースからなら尚更で、高周波をより多く透過させる等の作用を期待できません

（色は規格できっちり切り替わる扱いに有りますが、強制指定は認められているようです）
（但し、物理的な仕様の違いもあり、ＳＤＲとＨＤＲの壁は超えられません）


＞　基本的にＤＶＤでパンがカクつく映像の場合、絶対的なビットレート量が不足しています


　‥これの症状は（どのような解像度）どのようなソースにも言えることですが
　動きの激しい部分でカクついているように思えたら、ビットレート量が不足している証しです

　それの対処方法として、色々と試行錯誤が巡りますが
　他のビットレート量が十分なのに、カクつくところだけどうにかしたいと思ったら
　基本的に可変フレームレートが有効です

　‥お肌な映像では、とくに可変フレームレートタイプが繁茂しているようですが
　同じような色合いが続いているはずなのに、意外にも圧縮率が最悪にあるようです
　つまり、セックスほど動的な判断が多いということになるのでしょう
　圧縮率あがりそうに思えるのに、セルアニメ同様の「なぜ？」に唖然とします


＞　次に、デブロックです


　‥deblock（1:0:0）がデフォルトですが、これをオフにしてP4X4を効かせると
　やたらとフラットに見えますが、使用するCRF値によってはプチノイズを拾うようです
　それ以前の話、やたらとフラットなので、遠目で視聴する場合に、インパクトを欠く事でしょう

　（ＯＮにしておくにこしたことはない作りにあるようです）


　‥で、DVDやらdeblock（1:1:1）に寄せられたソースの場合

　deblock（1:-1:-1）にすることで
　ぼけや重み付けのやり直し等にそれなりの効果を期待できるでしょう

　（基本的に（1:0:0）の段階で、すでに補正強調が微に絡んであるようです）


　‥それでも重み付けの不足に不満を覚えたら
　ＣＲＦ値：psy_rd値＝1：1　もしくは　1：1.125にしてみると多少はマシに見えるでしょう
　（ref値やqcomp値だけではどうにもならない、若しくはいじりたくない場合の判断です）

1-3)2

＞　‥psy_rd（1.00:1.00）とＰ４Ｘ４を効かせた再エンコードにおいて
＞　そこでは、なぜか高いＣＲＦ値でのJPEGノイズ発生に悩まされます
＞　結果、より低いＣＲＦ値を追いかけている始末っす（迷走甚だしい）


　ＣＲＦ（13.5）まではレシプロ機の世界
　ＣＲＦ（12.0）になるとジェット機の世界で、３分の１程の増量差に達します
　これより先の膨張量はとんでもなく不可解の領域です

　‥JPEGノイズで言うと（540ｐ時）
　ＣＲＦ（13.5）でさえ、DVDに見られる残念な程度にまとわりつき
　ＣＲＦ（12.0）辺りになって、漸くにBD程度にまで減衰するも
　BD由来のJPEGノイズを、高周波要素として拾っちまう傾向は否めず、解像度を上げざるを得ない

　‥結局、何だかんだで、こだわっていくと
　540ｐなら、CRF（12.8）が上限に
　720ｐなら、CRF（12.6）ということになるようです
（＊‥qpstep値でコンマ一桁までに割りきれる値が適当である傾向が見られる）


＞　結論としては
＞　規格想定を超えて、大量にマクロブロックの使用×Psy-Trellis強度（1.0）の構成にすると
＞　JPEGノイズに対しても、微に強調してしまう傾向に繋がりやすいようです
＞　4ｘ4にデータを詰め込む無理の当然に思われますが
＞　その分、動きのインパクトがＢＤに近づく傾向には、それはそれで驚きます


　‥（psy_rd（1.00:0.00）に設定時）１０８０ｐに４ｘ４ブロックを効かせ渡らせると
　映像が無駄に細かくなって拡大時でのソース比較がかなり違ってきます

　‥それが良いことなのかどうかはさておき
　psy_rd（1.00:0.00）＆８ｘ８までとを比較してみた時
　psy_rd（1.00:1.00）＆４ｘ４における作用が
　ソース寄りにディティール回復を目指してしまうことから差が無くなって見えています

　1080pにおいて、若しくは、同解像での再エンコードにおいて
　Psy-Trellis強度への過度な期待はすべきではないらしい


　‥さらに言ってしまうと
　４ｘ４ブロックの効果期待も７２０ｐまでっぽい
　それにしても、動きのキレに納得するには、それだけのビットレート量が欠かせない傾向は否めず
　容量比で効果的だと思える許容になると、５４０ｐまでのオチになるようです


＞　つまりＡＶＣのそもそものコンセプトとして
＞　４ｘ４ブロックでの細かさと動きを追求した造りにはなっていない‥らしい


　‥今更だが、低解像度でのそれを置き去りにしていく傾向は否めないようである
　（画質は上がっても、圧縮比としてとなると癖が付きまとう）
　（というか‥ユーザー側の期待が大きすぎるのだろう）

1-3)3

＞　‥ここでのqcomp値は、（0.63）の一本化で良さげです
＞　ですが、CRF値を選ぶ傾向です（これはデフォルトの（0.60）でも同様に思われます）
＞　でも不思議と（0.63）には、無駄すぎる低いCRF値に適応する傾向が見られます


　‥それにしても、psy_rd（1.00:1.00）を使用している状況での
　qcomp値の効きが、普通に、フラットかエッジかの割り振りに置き換わるっす
　左に振ればフラットに、右に振ればエッジ強調に

　但し、ソース自体の状況では、効果は現れない（画像処理系のフラット＆エッジ処理とは異なる）


　‥動画エンコード処理の都合上
　それは重み付けにも関連してくることだが
　（0.5）〜（0.6）の間に設定すると、ビットレート量の割り当てが随分と減る
　と同時に、重み付けが乏しくなり、CRF（15.0）でも激しい動きに対して不足していたりする

　その点、どうにもＢフレームがあった方が多少なりとも有利らしい

　‥と言っても、調子こいてビットレートを落としても
　動きでカクつくケースが発生するので、（0.60）はインターレース用途を含む設定に思われます
　で、少ないマクロブロックやらでやり繰りして、体良くぼかしてうまくやっているようです


　‥でも、１０８０ｐ以外は、ビデオテープ基準らしく
　なにかこうぼけすぎていて、納得できかねていたわけですが
　そこの制限となっていたマクロブロックのリミットを外して追加できる状態にすると
　そのまんまファイル容量が増量してしまうので、悩ましい選択肢になっています

　‥そこは業界の都合、経費削減ということになるでしょうが
　‥個人の物好きをそこに合わせる必要なんてねえとしたいところですが
　‥結局は時間を掛けてＢフレーム付きでエンコードせざるを得ないらしい


＞　結局の所、動きや輝きにインパクトを得ようとすると
＞　細かすぎるブロックは邪魔になるらしいので、意図的に８ｘ８にシフトしておくのもあり
＞　（その分、動きで負けないだけの適量なビットレートの割り当ては外せません）


　‥なので、エンコード時間短縮以外の用途で
　Ｂフレーム抜きダウンコンバート＆４ｘ４ブロックを効かせ放題にする旨味は薄いっぽ‥orz


ａ）720ｐ＆CRF（12.6）＆ｐ4ｘ4‥ｂより30％増量するがエンコ速い、さらに程度微細化する
ｂ）720ｐ＆CRF（14.4）＆ｂ8ｘ8‥Cより10％増量で収まるが時間が掛かる、なかなかの微細
ｃ）520ｐ＆CRF（12.8）＆ｐ4ｘ4‥エンコ速いが、４ｋ倍時ややぼけるかキツく見える傾向あり


　‥基本的にテレビＵＳＢ挿しを前提にすると
　ａは、ＵＳＢ2.0だと秒間転送量で心許ないソースがちらほらしてきます
　ｂでも負荷の大きい場面では余裕があるとは言えず、やってみないと分からない点は否めません
　その点、ｃは何も考えずともうまく行くでしょう（キュルキュル快速用途なら俄然こちらです）

　ですが、ｃでも容量問題に悩ましきソースがある点は否めません