2023年10月20日

【エンコード日記】十分なビットレートの場合、重み付けなど要らんかった件

改稿.2023/10/21...20231020...

> 優恋里小扉としたノウハウをHEVCでも試してみたところ
> 設定した内容が2pasの際にほぼ無視される(オープンGOPで250枚でbフレーム4枚)


 (一番に気になったのは、初期設定で)
 (VBVバッファサイズがVBV最大ビットレートの桁倍とか‥謎)
 (どう考えたってAQがおかしくなると思うのだが‥謎)
 (VBVバッファサイズの取り扱いってエンコード専用なのかよ???)


 ‥で、重み付け無しという内訳だった
 それで大体‥ビットレート(170^2)が目一杯くさかった(ざっくり33%減超)

 ‥で、そこからの感想が
 HEVCのbフレーム品質≧AVCのpフレーム品質‥みたいだった
 HEVCではpフレーム群を想定せずに、あくまでbフレーム品質に特化している
 なので、pフレームとbフレームの割り当て比としてのざっくり33%減超という事らしい
 (Iフレームの分もザックリ減りますが、そこはbフレーム比が1.3に固定くさいので相殺??)

 ※ HEVCでは参照フレームMix機能を廃してるらしく、pフレーム群の品質が上がりません
 (bフレームと連動した時間軸云々に一本化している模様どえむ)
 (長いREFについても挙動が全然違うっぽ‥駄目だねこりゃ‥キュルキュルなんて無理ッ)
 (GOP3枚固定にしたって、パンでビットレートを持ってかれるわけで‥お手上げになる)


 ※ さらにおったまげたのは、先読み量が多い事もあり
 処理項目を増やすとそれだけメモリーを消費するらしく開始エラーを吐くっす
 もはや、庶民の扱える領域には無いのでしょう
 (庶民は、AVCから毛の生えた部分だけ齧ってんさい‥みたいな)


> ‥で、気がついてしまった
> 十分なビットレートの場合、重み付けなど要らんのでは?


 ‥さっそくAVCに戻ってやってみた
 (と、その前に重み付けについてお復習いググってみた

 そしたら、インターレース映像のPフレームに重み付けは無効ルールだった‥orz


> 今まで間違った解釈のままにやらかしてきたことをここにお詫びします‥m(_ _)m


 ↓さらに勘違いしてた
 P-フレーム予測の重みを変更すべきを格子を変更してた(まぁ参考に)


 (一番に異なるのは、エンコード時間が倍縮する点どえす‥ンゴ!)
 (そして、subme=11 → subme=9 に強制変更されるどえす)
 (え★subme=9‥bフレーム必須なんじゃねぇの???‥pのままで通ってるz‥)

 ‥デーコード負荷もちょびっと減るみたいっすけど
 マクロブロック4×4を利かせてやると
 ビットレート(200^2)〜(210^2)の間ぐらいが画質としての十分さらしく
 ビットレート(200^2)だとちょっと不足感があからさまだけど、デコードはスムーズで
 ビットレート(210^2)だと十分すぎる分、デコードがそれなりに重くなる感じですかね

 これを8×8の10ビットで出すと
 ビットレート(200^2)での映像印象(エッジ感)が一気にパンチ不足するのだから悩ましい


> で、久々に割り切れる数値出しに「十進BASIC」書いてみた
> (FOR〜NEXTの構文すらすってんてんに忘れてたz)


LET I=0
FOR I=200 TO 210 STEP 2
LET A=I^2
LET AA=SQR(A)
LET B=I^2*2.25
LET BB=SQR(B)
LET C=I^2*4
LET CC=SQR(C)
LET D=I^2*9
LET DD=SQR(D)
PRINT A,AA,B,BB,C,CC,D,DD
NEXT I

END

(で、計算値をまとめたものが↓)

40000(200^2):90000(300^2):160000(400^2):360000(600^2)
40804(202^2):91809(303^2):163216(404^2):367236(606^2)
41616(204^2):93636(306^2):166464(408^2):374544(612^2)
42436(206^2):95481(309^2):169744(412^2):381924(618^2)
43264(208^2):97344(312^2):173056(416^2):389376(624^2)
44100(210^2):99225(315^2):176400(420^2):396900(630^2)


 ※ 8ビット4×4有りでビットレートの量の指定を減らそうとしても
 デコード負荷の度合いの調整で見ると(208^2)ぐらいの差でしかなく
 代わりに、仕上がるファイル容量が減るとは限らないという謎‥
 (マクロブロック4×4の度合いをプチ減らしただけのような気もする)

 (マシンパワーが足りんので、それ以上の判定は無理)


> しゃあないので、そこから、partitions allにして
> bフレーム(3),なし,最適,厳密,□,0にしたら
> ビットレートが、減るのと減らないのとがある‥(強制subme=9‥感慨深いどえす)


 ‥キュルキュルには遠くなるが、細部がガチ崩れない様子にあるのはうれしい誤算でしょう
 ‥キュルキュルには遠くなるが、細部がガチ崩れない様子にあるのはうれしい誤算でしょう
 (あれれ☆)これレシピにしちゃうとヤバイ感じじゃん


 ※インターレースの場合、どうせキュルキュルにはならんので
 bフレームにしてしまった方が、解除の噛み合わせ負荷が抜群に減って噛み合っている
 (二枚連続ブレ駒のパン地帯だろうと難無く噛み合っている‥しゅごい)
 (というかその為のインターレースで、bフレームだったのかなっと‥‥)

 (でも、そげなパン地雷だらけだとビットレートを持って行かれるので、どこかに無理が出るっぽ)
 (安心する為のマシンパワーの用有りは変わんねぇ)
 (タイトルによっては、bピラミッドが地雷になるのか‥踏むとぶれぶれを見せるどえむ)

 ‥こうなるとp4×4まで外さないと‥‥てな流れくさっ



posted by 木田舎滝ゆる里 at 19:54 | Comment(0) | AVC-優恋里小扉 | 更新情報をチェックする