2021年06月16日

【エンコードレシピ】真打ち(雨後四葩修正版)‥BT601の限界美を鑑よう‥

↓12)記稿.2021/06/16

> AVC-Qのオススメはどれか?(プログレッシブ)


‥どうせならテレビUSB挿しでの25分もの4GBギリギリ枠のところにうんちくがありそうだが
‥まぁそうなると720pは無理なので、576pに白羽の矢が立つわけだが
‥誰もそこまで期待しちゃいないと思われるも
‥是が、ビットレートをもう一息吹き込んでみたら、意外や意外
‥「BT.709なら1080p一択っ」と云わんばかりの様相に等しく
‥BT.601許容につっこめるだけ突っ込んでも似たような有り様を垣間見せましたとさ


 ‥576pのくせに絶にクッキリ!
 「お前ってそこまでやる奴だったんだ」‥とかなんとか


> とはいえHDテレビでしか確認できていないので
> FHDテレビやら4Kテレビを前提にしたオススメまでには及びません(あしからず)
> (画面サイズが27型程度なら十分にイケる前提です)



 ‥量子化最小値をデフォルトにすると
 テレビUSB挿しでのサーチ負荷が軽減されてサーチ速度1でのスロー枚数が割増になるのですが
 「これぞ真打ち」と呼ぶに相応しい塩梅になるのですが
 OP&EDぐらいの長さのリップでは問題ないのですが
 25分にもなると、開始早早に逆サーチを始めると超絶に効きが悪いケースがほとんどのようです。

 一方で再生している最中のチョイ戻し要求には、なんなく対応できています。

 これはつまり、テレビ側の再生用バッファに
 情報が残っているか残っていないかの差という事でしょうか?
 そうなら、テレビの再生用バッファは
 思っている以上には大きいけれど、サーチ用途前提にはまるで作られていないと予想できます。

 是の負荷をさらに軽減しようと考えると、あとはLevelを下げるだけでしょう。

 その時の選択支は、当然(4.1)になると思いますが
 今回レシピでは、ビットレートを限界と思われるぐらいに盛り盛りなので
 大は小を兼ねるパターンに当てはまっているのか‥
 マクロブロック大盛りとの差がそれほどに感じられない程度になっちまっています。

 なので、タブレットやスマホでの互換性やバッテリー負荷軽減の都合を考えれば
 そういう選択肢も範囲かなと‥


 ‥はっきりと画質差の出てくるのは、キラキラ表現、Iフレーム増量箇所‥
 を含むソースに当たるとそれに足をしっぱられたぼかし方になり、差として現れます。

 ‥とくに、映画などの長いソースの場合、現場では勤務時間と確認作業の折り合いから
 一気に全部をエンコードしないので、同じ2パスでも配分が違ってきます。
 ‥個人の趣味の範囲では、問答無用で一気にやっちまうので
 全体の動きの激しい場面比増増になり、動きの平板な箇所からビットを削ってきます。
 その差から、シワ寄せを受けてぼかしがより強くなっちまう箇所の発生を予想するに
 長いソースになるほど、Level5.1の方が安定的でしょう。



1-12)1 一般

モード:変換
コーデック:MPEG-4 AVC/H.264
言語:なし
フレームレート:オリジナルを保持
カラーモード:YUV 4:2:0 Planar 12bpp‥(再リップならこれで十分)

レート調整モード:2pass平均ビットレート‥(帯域内に収めるためのお約束な必須)

プロファイル:High‥(Hi10に用得ず)

レベル:
4.1‥(ファミリー)バッテリー確保優先
5.1‥(マニア)画質安定重視

ビットレート:20400
※ 今回レシピは、1080p→1024×576pのみの取り扱いになります。
 {1024×576→64×36→2304×24フレーム→55296→÷5=11059.2}
 {1080÷576=1.875→11059.2×1.875=20736→55296÷2.666‥}
 としてみたが、是だとすこし多いらしいというか、÷5基準では微にそぐわないらしい
{1088÷1080=1.00740740‥}
{5×1.024=5.12}
 {1920×1088→120×68→8160×24=195840→÷5.12→38250÷1.00740740‥=37968.75}
 {38250÷1.5=25500→÷1.00740740‥=25312.5}
 {38250÷1.875=20400→÷1.00740740‥=20250}偶然にも割り切れる値を得た‥
 {38250÷2.25=17000→÷1.00740740‥=16875}再び登場&割り切れる流れ‥


プリセット:標準
Tune:無効
フレーム-パッキング:なし
Open GOP:□
キーフレーム間隔:‥(スローサーチ鎖動)
最小GOPサイズ:1
表示モード:プログレッシブ
スレッド:0
強制的に固定フレームレートのタイムスタンプを生成:オン



1-12)2 ブロッキング軽減

ブロッキング:オン
ブロッキング軽減 - 強度:0
ブロッキング軽減 - 閾値:0



1-12)3 B-フレーム

B-フレーム数:0
B-フレームモード:―
適応型B-フレーム:―
B-Pyramid:―
B-予測ウェイト:―
B-フレームバイアス:―



1-12)4 マクロブロック区分

適応型DCT:オン
I8x8:オン
I4x4:オン
P8x8:オン
P4x4:オン
B8x8:□



1-12)5 レート制御

VBVバッファサイズ:0(自動設定)
VBV最大ビットレート:平均ビットレートの設定値と同じにする(イヤンなシミ対策)
VBV初期バッファ:0.9
可変ビットレート:89.0(最大値100.0)‥(ビット量配分最適化&イントラ連続サーチ誤作動防止?)
量子化圧縮:0.0‥(時間軸間引きを斬る)
先読み:240‥(最大値250)
Lookahead Threads:0
Syne Lockahead:240‥(最大値250)
MB-Tree:‥(時間軸間引きを斬る)


※ Syne Lockaheadの規定値は(-1)のようですが、それが何を意味しているのかは不明。
(最大値が同じにあることから、先読みの値と同じに思われます)


※ 先読みは多ければ多いほど、メモリーを必要分多く使用します。
 (複数アプリ起動時には注意)

  AVC-Qにおいて、(240)もの先読みの用とは
  見映えの好い動きをするGOP構成を狙った用になっています。
  それが、シーン変更感度(89)の特性らしい‥(どうせなら(30x10)まで欲しいz)


※ これは予想ですが、すでに量子化されてある映像に対して
 さらに量子化圧縮の優先ポイントをやり直すのは、無駄な選択に思われます。

 例えるなら、ライン引きの終えてあるグランドのラインを消して引き直すのに相当するでしょう。
 (但しそのグランドは真っ平らでは無く、砂だらけのグデグデ状態です‥なので誤差でまくり‥)

 ‥代わりにやらかす用としてあるのが、先読みの大量化でしょう。
 これは、緯度経度計測に似た感覚だと思います。
 (計測ポイントは多いほど正確さを増す)‥そのように思っております‥



1-12)6 動き推定

M.E.範囲:30(1080p→576p用途)
シーン変更感度:89‥(キュルキュルサーチ位置職人&スローサーチ鎖動)
M.E アルゴリズム:SATD Exhaustive Search‥(テクスチャー崩れ抑制効果有り)
サブピクセルリファイン:FUll RD
Chroma M.E.:オン
P-フレーム予測の重み:スマート解析



1-12)7 量子化

量子化最小値:10‥(固定:デフォルトが一番‥但し‥)

※ 量子化最小値を中途にいじると、ありとあらゆる動きの感触が歪さを纏いだして不可解になる。
 とくにフェードがあちらこちらで通常とは異なる箇所出まくりになるので痛い。
 なのになぜかデフォルトにすると画が密になって感じられ、整いを見せるのだから不思議だ。
 なんらかの計算が裏付けにあるように思われる。

 次点が(0)という事に成ると思うが、液晶特有の白飛びをやらかしているので調整された模様だ。
 (白飛び抑制をハードでは無く、ソフトでもやっちゃってるってのは不思議な感覚だ)

 ‥ところが量子化最小値は、ビットレート鎖動にあるようで
 想定された水準を満たしていないと、途端に発色が悪いとした結果しか弾き出さないくさいので
 ケチケチリップには不向きとしか言いようがない。
 (÷5でケチケチだってんだから、頭おかしい‥)


※ ちなみに、量子化最小値をいじってもエンコード記録に反映されてません。
 (XMedia Recode側のバグに思われます)
 (ついでに、可変ビットレート値の変更も反映せず‥)


量子化最大値:69
量子化最大値(Delta):4
IP比率:1.4
PB比率:1.3
彩度QPオフセット:0
輝度量子化のデッドゾーン(Inter):21
輝度量子化のデッドゾーン(Intra):11
AQモード:可変AQ
AQ強度:1.0‥(固定:デフォルトが一番)



1-12)8 量子化設定

Trellis:常時
Psy-Trellis強度:0.00
Psy-RD強度:1.00‥(固定:デフォルトが一番)
参照フレーム数:‥(スローサーチ鎖動)
ノイズ減少:0
参照フレームMix:□
CABAC:オン

DCTなし:オン
‥(DCTありとは、折角計算した細かい端数値をなかったことにする判断)
‥(結局、平均ビットレートともなるとどこかで平均的に間引かれちまうわけですが)
‥(2passともなると尚更ですが、ここで無理に誤差誘導する必要も無いかなって感じ)

Fast P-Skipなし:オン
‥(Fast P-Skipありとは、Pフレーム間での細かい近似計算をパスして手抜きする判断)
‥(HEVCになると名を変えてデフォルト採用にてどや顔やらかしてます)
‥(その結果、青み成分が多い場合、バンディング系の失敗をやらかしがち‥とかなんとか)
‥(だがバンディング発生の本質は、ビット×ブロック不足による複雑化計算のなれの果て‥)

心理的エンハンスなし:□
PSNR算定:□
SSIM算定:□



1-12)9/ビデオユーザビリティ

ビデオ形式:指定なし
カラー優先度:指定なし
行列係数  :指定なし
伝送特性  :指定なし

※ エンコーダーの挙動が変わったのか、指定してもダブる傾向に無くなった模様です。
 とはいえ、1024×576pの≒24フレームは規格外なので、あえて指定するまでの用は無いかと




> ソースの状態を忠実的に確認したいなら【テレビ設定】好逸スタンダードでの視聴がオススメです。
> 派手な発色が良いなら、【テレビ設定】好逸ダイナミックがオススメです。


 ‥色が出てこないと思ったら、「エコナビ」のオンオフを確認しましょう。
 (オフの方が適切ですが、パネルサイズで変わる場合もあり得るかも)



1-12)10/クロップ/プレビュー

クロップ/プレビュー

##インターレース解除##


##クロップ##
P4x4をきちんと効かす為には、16:9である用があります。
(1440のマクロブロック数(90)が4で割り切れない事に因る)
なのでAVC-Qでは、4:3とした解像度比を扱いません。


##パディング##
‥ソースが4:3のものは、その都度、黒帯付き16:9にするべし
‥1440→左右(240)
‥始めから付加されているものは、操作せずにそのままになります


##解像度##
幅:1024
高さ:576
スケーリング:双三次スプライン
ディザリング:自動
アスペクト比:オリジナルを保持


 ※スタンダードなバイリニア方式は、同じ解像度でのリップ前提です。
 解像度変更しようってのに、バイリニア系方式を使用しては
 それだけで、色みを即誤差劣化されちまいまーす。

(DVDリップで明らかに色が怪しい昭和アニメなど、当時見てない世代だと判断つかないらしい)
(ブラウン管TVは、メーカー毎で色みに差があったというのも有るかも知れませんが‥)
(BT.601とBT.709とで色が変わりますが、それ以上に違ってしまうのでーす)



1-12)11

 ‥クロップ/プレビューには
 Video項目の隣にAudio項目があります。
(作品ごとに音量の差はあるので、常に一定に整えたい用途にはお好みでどうぞ)

 AC3でコンテナする場合の参考
 (テレビUSB挿しでは、AC3の5.1chを弾きません)

‥選択できる字幕を付けたければ、そこはmkvにコンテナするしかありません。
4Kテレビなら、詳細まちまちながら、mkvの再生に対応しています。
でもまちまちなので、その4Kテレビで選択字幕を表示できるかまでは不明です。
(wavに対応した4Kテレビもあるようですが、どこまで対応しているのやら‥)



1-12)12

 ‥その昔、30分ビデオテープというのがあった。
 通常は60分テープか120分テープを3倍モード利用するのが相場だったので
 まさしく30分モノの重要とは、25分アニメや特撮を通常モードで録画する用途だった。

 まぁそんな猛者の人口比は圧倒的に少数だったわけだが

 25分モノを1024×576p(3.4〜3.8GB)でやろうってのはそれと同じで
 「DVDに1話しか入らねーじゃねーかっ」て話に部類される。


 ‥一方、128GBのUSBメモリーで考えると
 1話あたりのボリュームがそのぐらいでないと無駄に余ってしまい持て余すことにもなるので
 なんだかんだと‥それもあり‥なのかなぁと思わなくもないが

 エンコード時間が長くなる傾向や、コピー移動に費やす時間も長くなるのはやはり痛い。
 (そりゃ、ビデオコピーやDVDに焼く手間やら管理とを比べたらずっと手軽に見えるが‥)
 (その当時のコンテンツ量とを比べたら、どうしたって現代はコンテンツの無間地獄やっ)



posted by 木田舎滝ゆる里 at 14:00 | Comment(0) | AVC-Q | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

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