2020年02月26日

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

↓3)記稿.2020/02/26

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


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

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


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


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

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


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


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


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

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


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


 1080pでの一般的な設定は、I4x4までです
 それも、BDなら1秒に1枚あるかないかの配置ペースです
 さもFHDと囃し立てたところで、その中身は、実質8x8単位までの細かさです

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


 ‥そこはさておき
 その数が1920x1080 → 240枚×135枚
 これに対してP4x4までを効かせたBフレーム無しの540pの場合、同等になります

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

 ‥ところが、720pになるとこれが崩れます
 1280x720 → 160枚×90枚(8x8)、320枚×180枚(4x4)
 (P4x4まで効かせれば、動きの質はFHDより上に思えなくもないのだが‥)


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

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


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

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



1-3)1

> DVDを540pでリップするのは非常にムズかしくありました
> そもそもの540pの扱いがしづらく敬遠されてきました


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

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

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

 その逆も然りです(1080p→540p)

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

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


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


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

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

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


> 次に、デブロックです


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

 (ONにしておくにこしたことはない作りにあるようです)


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

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

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


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



1-3)2

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


 CRF(13.5)まではレシプロ機の世界
 CRF(12.0)になるとジェット機の世界で、3分の1程の増量差に達します
 これより先の膨張量はとんでもなく不可解の領域です

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

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


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


 ‥(psy_rd(1.00:0.00)に設定時)1080pに4x4ブロックを効かせ渡らせると
 映像が無駄に細かくなって拡大時でのソース比較がかなり違ってきます

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

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


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


> つまりAVCのそもそものコンセプトとして
> 4x4ブロックでの細かさと動きを追求した造りにはなっていない‥らしい


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



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)でも激しい動きに対して不足していたりする

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

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


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

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


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


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


a)720p&CRF(12.6)&p4x4‥bより30%増量するがエンコ速い、さらに程度微細化する
b)720p&CRF(14.4)&b8x8‥Cより10%増量で収まるが時間が掛かる、なかなかの微細
c)520p&CRF(12.8)&p4x4‥エンコ速いが、4k倍時ややぼけるかキツく見える傾向あり


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

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



posted by 木田舎滝ゆる里 at 23:46 | Comment(0) | 黄岐の果ての黄嶺 | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。