↓8)記稿.2020/02/16
> CRF(18)でも、JPEGノイズをなだめやらかしたいというとこで、試しに
> Bフレームを抜いてみたら、それだけでもJPEGノイズが微に減衰する傾向(え☆マジっ)
‥ということは、全部レベル5.2で固定だな
でもまずは試しと、長いGOPにしてみた(72)or(90)&ref(1)
すると
I4x4とP4x4が効きまくりなのか、Iフレーム入れ食い状態だった
これなら、テレビUSB挿しも十分にキュルキュルするだろうと思って確認したら
もはや短いGOPのキュルキュルには適わない事が判明
(サーチ位置を計算する用が依然あるらしく‥それのもたつき感がもはや使えねえ状態だった)
(シーン切り替え位置は、その都度ピタリなだけにちょっぴり残念)
※ レベル5.1と5.2の間にすげー差があって、FHDの30フレームでも余裕の想定
DVD(VFRタイプ)のFHDサイズ60フレーム化でもそもそものデータ量が小さいからイケる想定
でも、FHD60フレームで撮影されたソースを、短いGOPで再エンコードするまでは無理っぽ
https://ja.wikipedia.org/wiki/H.264
https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels
> BフレームがPフレームを参照する
> PフレームがBフレームに参照される
この関係を‥Bフレームの品質がPフレームにより引き揚げられてそれほどに劣化しないだろう
(なんて期待半分)どこかでそんな風に思い込んでいたのだろう
しかし実際は、Pフレームの方がBフレームに合わせざるを得ない状況だった
‥それが劣化の要因だった‥
(会社経営での上司と部下のグダグダと同じらしい)
仕方がないのでサクッとBフレームのリストラを断行!
もとい昇格!(ビットレート倍増だっ大盤振る舞いだっ)
> 理屈で考えても、B4x4が無いんだからしょうがない
> Bフレームのその分の分解調整をPフレームが担ってたって話だ
>(中間管理職は大変だってそのまんまの流れである)
‥I4x4、P4x4が効きだすと
それだけで、Bフレームが無くても動きが良くなったように見える
(マジにそうなら、B4x4の用意されていないAVCのBフレームには、なんの魅力も無い)
> しかし、それだけでJPEGノイズが根本的にどうにかなるものでもない
> 細部の劣化をどうにかする為の創意工夫が要求される
1-8)1
> CRF(18)の枠で、JPEGノイズをどうにかしようとして考えた末
> 結局、AQ強度に着目せざるを得なくなった
‥理屈としてはこうだ
平板の品質をもう少し上げないと、psy_rd(1.00:1.00)の効果に十分さが得られないらしい
どうにも、平板の品質に見合った程度でしか高周波ディティール補強をしてくれていない
‥だからといってCRF値を下げれば
基本となるビットレート配分が大幅に増えるばかりだ(演算時間も増大だ)
‥そこで、AQ強度の値を下げて、低周波ディティールにビットレートを回すという発想に至った
そうすると格子枠単位で、輪郭側がスカスカになるわけだから
そもそものJPEGノイズの発生箇所も細かいところほど多いのだからリセットできるはず‥
うまくいけば、psy_rd(1.00:1.00)が効いて、ノイズの減った画像に仕上がるはずである
(それでも結局は、再エンコード分のJPEGノイズは乗ってしまうわけだが)
(何の手立ても打たずにJPEGノイズにJPEGノイズを倍掛けの状況よりはキレイになる想定だ)
‥とはいえ、XMedia Recodeの仕様から
コンマ二桁指定を維持できない数値に対して、コンマ二桁を押し込めるのは一箇所に限られる
ということで、AQ強度にコンマ二桁をあてがうとなると
CRF(15)×qcomp(0.5)
CRF(18)×qcomp(0.6)
CRF(21)×qcomp(0.7)といった構成に絞られる
> ‥まずは、AQ(1:0.5)、psy_rd(1.00:1.00)でやってみた
> すると、どれもこれもすっきりとしてはいるが、平たくありパンチを欠いた映像に仕上がる
‥すっきりとした映像に仕上がることは確認できた(方向性は悪くない)
だが、見やすいだけの映像なら、ここでは用を満たさない
求めているのはBD並のパンチを宿した720p映像である
さらに模索すること、AQ強度をいじった結果の副作用に気づいた
それは、CRF(18)未満での「CRF値=qcomp値×10×3」のバランスが怪しくなる事だ
思っている以上に、エッジが立ちまくるようになって、画としてキツくなってしまう傾向だ
(こうなっては、複雑なぼかし表現のソースほど扱いが難しくなる)
> つまり、テレビ規格の想定するCRF値の幅が、それの織り込み済みだったらしい(へぇ〜)
> ということで、CRF(18)×qcomp(0.6)の一択になった
‥こうなっては、残された打つ手は、誰もやらない数値を盛らざるを得ない状況だ‥
そんなこんなで、とある数値の一致の発見におののいた
それは‥「0.75×3=2.25」と「1.00×1.125×2=2.25」‥だった
もはや、問答無用でこれを盛ってみろと言わんばかりである
‥なにしろ、ここで割り切れない値を用いては
低周波と高周波の間の要素に、誤差を無駄に発生させかねない恐れがある
(AVCにはバイアス付きしかないが、その点、HEVCには自動分散なんて項目が追加されてる)
(やらんとしている方向性は同じだと思うが、その辺の造り込み概念なんざ知らん)
1-8)2
つまり、「AQ(1:0.75)、psy_rd(2.25:2.25)」‥である
> ‥誰も信じねぇぞこんな値‥
‥確認していくと
BDインターレース自動的解除用途ではバッチリに思えるのだが
BDプログレッシブ・ソースの再エンコードにおいて、まだまだインパクトさの不足が感じられる
&、ぼかし技法の動きがどこか覚束ない
‥これは、そのままにインターレースの方でも同じことが起きているはずである
とはいっても、インターレース映像を解除映像と比較してもその辺は推し量りかねる
> ‥この間、色々とした傾向を確認
AQ(1:0.75)のまま
(1.00:1.00)
(1.25:1.25)
(1.50:1.50)
(1.75:1.75)
(2.00:2.00)
と、値を変えてみると、動きの大きい部位から、エッジ強調の波紋が強くなる傾向だ
&、問答無用で増量傾向となる
エッジが的確に抽出されるならそれも有りだが、不正確さが混じるなら容認できない
‥基本的に、psy_rdの二つの値は1:1が良いらしい
これの値を上げてゆくと、エッジが強くなる
強くなると言っても、輪郭強調のようには作用しない
高周波のデータがある範囲で、エッジが強くなるということである
データが有りもしないのに、より高い値を盛ると誤差が大きくなる
DVDあたりで、(3.00:3.00)以上は無理ッ
> (繰り返すが)CRF値を下げないで、データの漏れを補強するので増時間にならない
> うまく行けば、盛りすぎやら足りなすぎやらに悩まなくて済む
‥それの違いを理解するには、低いCRF値の映像がどういうものかを知らないとお話にならない
(今までの失敗は、それの蓄積を脳内に刻みつける為だったと言うことらしい)
1-8)3
> ‥悩むことふと閃いた
> FHDサイズとHDサイズのマクロブロックの割合である
‥FHDサイズの方がマクロブロックの数は多い
それは同じ面積あたりの割合が多いと言うことだ
それは丁度1.5x1.5倍である
これの差を埋める為のアイデアが必要だ
> すでに、エッジの強さは
> AQ(1:0.75)、psy_rd(2.25:2.25)で十分に確保できていると考えると
> どこかをぼかすことで辻褄をつけてやれば良い
‥巷でやらかしているアイデアとしては、ref(5)なんてのが手頃感高い
先読み枚数を増やすと、動的な部分の優先される部位とそうで無い部位との部類分けが強化される
だが、確認してみると、ムラが大きく付け焼き刃の域を脱していない
(部類分けの水準が、どうにもそこまでの想定には無いらしい)
それでなくても、参照枚数の増加は、増時間と色ぼけに繋がる
一般的な(4)より増やす用を感じ得ない
‥ではあるが、720pの場合、(4)ではまだ、ぼかし表現での動きが出きっていないのだ‥
> そこで、「qpstep(最大QP変動幅)」である‥(もはやこいつしかねぇ)
> 連続フレーム間における量子化値の最大変動幅
‥FHDでの規定値(4)×1.5=(6)
ここを大きくするとボケることになるが、エッジがきつくなる分の相殺でやんわりすれば
FHDサイズからダウンコンバートの際の不足分も織り込まるはず‥
それだけ、ぼかし表現での動きも良くなるはず‥
情報量をエッジに向けるのでは無く、動きに換算させれば良い想定
1-8)4
そして、「AQ(1:0.75)、psy_rd(2.25:2.25)、qpstep(6)」‥を得た
> ‥益々以て、誰も信じねぇぞこんな値‥
‥qpstep(3)か(4)かで悩んでいたのに、真打ち登場かよ
といってもHDサイズ用とした扱いに思われる
‥ということなので、またまた色々と調べ直すことになったった
> これで良いなら、どうしてqpstep(3)に填まっていたのだろうか?
‥960÷720=1.333333333333333
‥4÷3=1.333333333333333
DVD4:3映像のアップコンバート時の比率が、FHDからのダウンコンバートの逆方向と考えると
まぁそういう見方になるのかなあと思うも、だからといってDVD16:9には該当しない
(4:3ではエッジ効果を得ているように見えた、今度はその逆をやろうということらしい)
1-8)5
> 無論、ソースが4:3DVDだろうと、720pでqpstep(6)を確認するわけだが
‥まず、プログレッシブにおいて
ビットレートの盛りすぎ感や不足感は感じられない
ただし、不思議なことに、CRF値を低くしても画質にそれほどの差を感じられない
同じ構成で解像度をFHDにしても同じである
静止画で確認しても、それなりに差があるようでもあり、気にするほどの差を得ていない
(そりゃまぁ拡大すれば解像度差は一目瞭然だが、差があるようなインパクトさを欠く)
(というより、やはりFHD向きではない様相を呈している)
‥やはり、FHDサイズでエンコードするなら
AQ強度(1.0)、psy_rd(1.00:1.00)、qpstep(4)とするのが想定なのだろう
> ‥という普通では無い挙動を見せる中でも
> とくに気になるのが、JPEGノイズのプチパターンである
‥たとえ全体としては気にならない程度の水準に落ち着いていようとも
ありえないまさかの箇所にプチノイズがあったならどうしたって不満だ
それがCRF値を下げることによって地雷のように発生する
まったく以て、どこに発生するわからない状況だ
通常なら品質の改善に推移して目立たなくなるはずである(なのにそのようにはならない)
(これが要するに、ありえない数値のもたらすイレギュラーなのだろう)
‥ということで、なんだかんだと
720pのCRF(18)で十分とした誘導を突きつける
(それはそれで願っても無い変化だが、それはそれで扱いにはやはり注意がともなうのである)
1-8)6
‥インターレース解除の場合、とくに実写では、ジッター部分が目立たなくなる傾向だ
実写の場合、データ量が多いので
アニメほどに細部で形が潰れたり、色が変わるなんてことは余程で無いと分からないのだが
アニメで起きてしまうJPEGノイズ由来の細部のぐたぐたもそれなりに改善を得られたのだが
DVDソースでは、どうにも、ぼけすぎてしまう箇所が出てしまっている(許容できない)
> そこで、DVD480iに対しても
> BD1080iと同じく、自動的解除を試してみることにした
{インターレース解除フィルターによるぼけ} > {二度揚げによるぼけ}
‥ということである
‥やってみると、インターレースを保持したままの拡大がうまくできなかったので
しぶしぶ、BDと同じく縦解像度を320pと減らしてから、縦解像度増の二度揚げにするしかない
この時、一度揚げの調整を適切に処理できていないと、二度揚げでも適切な状態にならない
‥とりあえず、ここまでの経験と追加の確認から
DVD一度揚げのCRF値は(12.0)、qcomp(0.4)
AQ強度(1.0)、psy_rd(1.00:1.00)を用いる
> ここで肝心なのは、qpstepと横解像度の値‥である
4:3ソースの場合、2160×320=960×720
16:9ソースの場合、2880×320=1280×720
(どうにも変態すぎる構成である‥益々以て‥誰も付いてこない洗逸値に見えてしまうところだが)
(一度揚げの縦解像度を二度揚げ時に2.25倍、横解像度を2.25分の1にする値である)
(これのバランスから、qpstep(6)でイケそうである)
1-8)7
> で、二度揚げの塩梅を確認しているうちに気が付いてしまった
> qpstepに秘せられていた黄金比
480p‥qpstep(9)
540p‥qpstep(8)
720p‥qpstep(6)
1080p‥qpstep(4)
‥という事だったらしい
じゃ4kは?(そこは64CUのマクロブロックやらで対応できているように思われる)
(偶数倍だからそういう事になると思う)
> しかし是を用いると困った事実が発覚する
‥二度揚げでどうするかと言うことになって
もはや、AQ強度(1.0)、psy_rd(1.00:1.00)で好いじゃんと思い立ち
プログレッシブ・ソースでも同じようにやらかすと
CRF(12)の540p ≒ CRF(15)の720p ≒ CRF(18)の1080p
といった感じのファイル容量になる傾向にあるらしい
(当然‥増量しちまうんで‥「ありえない値」も捨てがたい)
‥ともに合わせてまだまだ確認の用あり‥
> とりあえずDVD一度揚げの塩梅が良すぎる
> 二度揚げして微にぼけが入るのが勿体ない
‥とくに720pにすると強制的にbt709に変更するので
色が変わることでの、見づらい箇所の発生を確認した
例えば、スレイヤーズNEXT OPのタイトル画面バックの複数リングの色
これがやせ細っちまってまったくダメになる
ということなんで、540p復活でーす
(さすがにここまでやって、DVDオリジナル3:2はありえない)
1-8)8
> お話変わって、「XMedia Recode 3.4.9.2」ですが
‥x264 (2991) Codecになって画質上がったかもなんてうれしい反面
ソースファイルを登録欄に放り込んだ途端にフレーズ状態に陥るケースが多発
固まる傾向の高いソースとそうでもないのとに分かれるようだが
バッファかなにかの都合で、安全圏だと思っていたソースでも固まる事がある
‥タスクマネージャーで確認すると、なにやらバックで演算をやらかしてるのだが
初期確認でのそれならまだ我慢して待つのもしょうがないところだが
その都度、ファイル指定の欄をクリックする度、
解像度を変更する欄をクリックする度に、確認らしき演算が始まるのは耐えがたい
(テンポラリー化等で、確認情報を保持しないのは、どうにもありえない)
> どうにかして欲しいのですが、よろしくお願い致します
【黄岐の果ての黄嶺の最新記事】
- 【テレビUSB挿し】4GBまでしか回せな..
- 【エンコード日記】テクスチャ剥がれに悶絶..
- 【エンコード日記】AQ強度は、サイズ変更..
- 【エンコード日記】Chroma M.E...
- 【エンコード日記】やはり、qpstep(..
- 【エンコード日記】me_rangeが重み..
- 【エンコード日記】正しかった仮説と間違っ..
- 【エンコード日記】CRF値とqcomp値..
- 【エンコードレシピ】最果ての720p解閃..
- 【エンコード日記】心理的エンハンスとGO..
- 【エンコード日記】CRF(12.0)×q..
- 【エンコード日記】短いGOPに最適な先読..
- 【エンコード日記】アンシャープとシャープ..
- 【エンコード日記】アンシャープ(0.1)..
- 【エンコード日記】テレビUSB挿しで弾か..
- 【エンコード日記】CRF値にもお約束な比..
- 【エンコード日記】アンシャープ(0.1)..
- 【エンコード日記】アンシャープに減量効果..
- 【エンコード観】アニメにテキスチャーの保..
- 【エンコードレシピ】最果てのマクロブロッ..