2020年11月09日

【エンコード日記】鮪丼(720p)再開しました

記稿.2020/11/09

> 結論から述べると


 実写には1080p(16x16のマクロブロック)が適切だった
 そのまま低ビットレート(25000以下)に落としても特に問題は見られない
 むしろ、鮪丼にしない方が発色が良い

 ところが

 アニメの場合、解像度やらビットレートを下げると16x16のマクロブロックだけでは破綻する
 どうしても横筋ノイズの発生が避けられない(設定がまずいと縦筋ノイズも発生する)
 それが平均ビットレート時の難しさになる


> それを避ける為の扉がなんと、可変ビットレート(0)だった


 ‥可変ビットレート(0)にすると
 Level6での4x4のマクロブロックにまで均等にビットレートが回されて画質がUPする

 (UPすると言っても、横筋ノイズの発生をシャットアウトできるとした範疇になる)

 なので、ビットレートがBD並に十分にあるとその差はほどんどわからない
 その様な場合は、やはり16x16のマクロブロックで十分と言えそうだ

(‥違ってくるとしたらアニメのインターレースものぐらいだろう)
(但し、インターレースの鮪丼の場合、4x4にもキッチリとビットレートが盛られてるっぽいので)
(増量感が半端ない‥どうにもインターレースの隙間にも同程度のビットレートが入るとしか‥)
(そうしないと品質が上がらないが、グデグデなのでやはりインターレース解除の方が早道だろう)


> なので、鮪丼が必要になるのは
> アニメにおいてのダウンコンバート時ノイズ防止用途だけになる


 一方で、解像度1080(アニメ)のまま変えずに、低ビットレートだけを割り当てるやり方では
 鮪丼をやろうとも不適切なビットレート割り当てがそれなりに発生した状況で変わらない

 (この辺はアニメと実写とでは、まったく異なっているので注意が必要だ)

 ‥一方、1080から解像度を下げるとテクスチャー破綻を避けられないが
 マクロブロックへのビットレート割り当て不足からの部分箇所での破綻を容認するよりは
 解像度減分のテクスチャー破綻を選ばざるを得ない

 なぜなら、Level6での鮪丼を回すにはそれに適ったGパワーが必要になるからだ
 テレビUSBではそちらを耐えても、瞬間帯域の不足の方が悩ましく
 その辺の算盤勘定を整えると、どうしても720pの方が適切になる


> 但しそれでもビットレートの割り当てには慎重にならざるを得ない
> それでなくてもLevel6での鮪丼では、格子欠けの発生が気がかりでしょうがない


 そこでDVD並の11250(ビットレート)を割り振ってみたところ無事に回った
 でもなんだか発色がそれなりに浅黒く感じられる(実写になるとてきめんだ)
 さらに、スタンダードモードでは明るさが足りていない

 つまり、スタンダードモードで適切に視聴できるようにするには
 ダイナミックモードより多くのビットレートを必要とするらしい(推定2倍差)


 ‥で、11250(ビットレート)でのエンコードでは
 アニメOPあたり130MB程度、25分あたり2GBちょい程度になる
 なので、発色を納得できる程度にするのに求められる値にしても
 平均ビットレートなので1.5倍にすれば、そのまんま16875(ビットレート)で3GBコースだろう

 ‥16875(ビットレート)あたりでも格子欠けせずに回るらしい(調査中)



posted by 木田舎滝ゆる里 at 08:02 | Comment(0) | 月下涙焉 | 更新情報をチェックする

2020年11月07日

【メモ】数値マーキング(2乗と倍数)

記稿.2020/11/07

> 十進ベーシックホームページ

DIM zxb(250,50)
FOR z=1 TO 250
LET zxb(z,1)=z^2
FOR b=2 TO 50
LET zxb(z,b)=b*zxb(z,1)
NEXT b
NEXT z
FOR z=1 TO 250
PRINT z;zxb(z,1)
FOR b=1 TO 50
IF zxb(z,b)>6000 AND zxb(z,b) <40000 THEN PRINT zxb(z,b);
NEXT b
PRINT
PRINT
NEXT z
END


※今回は配列を使ってみました
 配列は0から始まりますが、細かい差分処理はどうでもいいので端折ってます

 ‥で、なんでこんな数値を弾き出したのかというと
 {平均ビットレート:最大ビットレート}={1:1}にすると
 いやんなシミが≒100%の確率で相殺されて消えてしまう事を発見したからです
 (2.25倍でもイケるようですが、さすがにそれは無理)


 ‥思えば、平均と最大のそもそもも、時間軸の間引きを前提にした観察です
 ヒトの感覚でのそれは、複雑な画になるとビットレートを多く必要とするから‥
 して思い込んでいるようですが、エンコードの方はそうは考えていないようです

 なので、時間軸観察の入れ子式構造がどうにもそのへんの誤差を発生させるらしい
 結果、いやんなシミがソースファイルからして発生しまっくていたりするらしい


 それのシミを剥がして綺麗にするのに
 ただ単に{平均:最大}={1:1}にすれば良いかというと
 それはそれでBフレームへのビットレート割り当てが減ると残念な結果になるので
 ソースに合ったビットレート数値が欠かせません

 その時の参考として、2乗の倍数がわりかし手頃
 ということで2乗の倍数値をレベル4.1の範囲で算出させてみました


> 但し、AVCのエンコードの方で宛がった数値が適切で無いと判断した場合、変更されちまいます


 ‥といことは大体でも良いのかというと
 特にDVDタイプでは、50の差が見映えの端境においては、大きかったりするようです
 (では、変更された値を放り込んでやれば良いかというと、そういう事でも無いらしい)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 11:23 | Comment(0) | 月下涙焉 | 更新情報をチェックする

2020年11月04日

【メモ】数値マーキング

1)記稿.2020/11/04

> 十進ベーシックホームページ


FOR heikin=6000 TO 62500
LET saidai=heikin*1.31308230323827
LET syousuuten=FP(saidai)
IF syousuuten<1 THEN LET kiriage=IP(saidai)+1
IF syousuuten=0 THEN LET kiriage=IP(saidai)
LET hiritu=kiriage/heikin
PRINT saidai,kiriage,heikin,hiritu
NEXT heikin
END


DVDのビットレート最大と平均(大体この辺のどれか)

[25000−12500] 1.31312 (25x25)
[24300−12150] 1.31308641975309 (45x45)
[24000−12000] 1.31308333333333 (20x20)
[22400−11200] 1.313125 (80x80)
[20480−10240] 1.3130859375 (32x32)
[20250−10125] 1.31308641975309 (45x45)
[19200− 9600] 1.313125 (80x80)
[16000− 8000] 1.313125 (80x80)
[12800− 6400] 1.313125 (80x80)


576p用途候補想定
[30720−15360] 1.3130859375 (32x32)


BDプログレッシブ用途のほぼ最適候補
[61440−30720] 1.3130859375 (32x32)


AVCレベル4.1のHiPの最大値が62500kbit/s
BDの帯域許容が52000kbit/s
BD動画部の一般的な最大が40000kbit/s
BDアニメ動画部の一般的な平均が38000kbit/s〜36000kbit/s(音声との排他利用絡み)
BT.709とBT.601の端境が25000kbit/s(アニメではその差が妙実に出る)
最大と平均を2倍差にすると、いやんなシミやらバンディングやらカク付きが一気に減衰してくれる
平均ビットレート同士だと、平均ビットレートの差分でしか減量しない
なので、平均ビットレートになるとHDサイズが要らない子に成り下がっちまっております(ンゴ!)

結果、サイズ1080解像度で、BDソースより微減して、サーチキュルキュルで‥
というのがこだり抜いた最適解のなれの果てになりそうれす‥(どうにも微妙な選択)

あと、リップの頭にマムシの出るソースと出ないソースの差が有るわけですが
4kテレビUSB挿しでならほぼ問題ない範囲‥(どうにも煮え切らない選択)

576pなら確実に半分に減量できるわけだが、カラーなりすまし作戦までを考えると手間が痛い
その分の時間コストを天秤に掛けると、どうしたって解像度1080一択の方が楽チン(ンゴ!)

↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 20:21 | Comment(0) | 月下涙焉 | 更新情報をチェックする

2020年11月02日

【エンコード日記】DVD様の御姿が[最大25000平均12500]らしい件

記稿.2020/11/02

> なんと、DVDの置き換えエンコードが
> ついにアニメ一話あたり2.5GBレベルに突入でーす
> ノンテロップOPで140~150MBに及びます


 ‥2.25分の1では険しすぎるので、さらに調べたところ
 規格にありがちな数値に1.313125が絡む事が判明
 その数は1600(40の二乗)の倍数だった

 ‥DVDの1.313086419753086を解析してみたところ
 2025(225の二乗)の倍数だった
 (2.25の点を0にしたったってこと‥偶然にしては‥)

 ‥ベーシックを使って、計算値一覧だしてみたら
 割り切れる数値の方が綺麗に仕上がるというか規格で見たような数が多い
 それのたいていが何からの10の絡む二乗の倍数になるらしい


 ‥BDの「北の国」からとBDインターレース解除くさい「ウルトラマン」は
 DVDと同じ最大&平均でも
 FHDサイズにて綺麗に仕上がることが判明

 (最大14707ー平均11200、4:3)

 (なんでエンコード時間までファイル容量ともに、HDサイズ程度になってんねん???謎)


 ‥最大=平均×1.3130825想定では不足だったのが「獣の奏者エリン」のOPで判明
 ‥以前に実験出しした最大=平均×4.5ではエラーは見られなかったので倍率の変更を検討
 ‥BT.601の上限が25000であることから、最大を25000に固定
 ‥1.313125よりさらに精度の高い1.31312で割りきれる12500を平均に指定(丁度2倍値)

 (ただし、1.31312の倍率出しでは、エッジはMAX良いけどエラー率で×だった)


> 結果


 最大25000ー平均12500にて
 エラー率の発生が抑えられ、DVDの最高パフォーマンスを得られるらしきを確認

 (これから再度、あれやこれやの確認リップのやり直しになりましたん)


 ※ ちなみに
 HEVCでは、どんなかなとさらりとした平均ビットレートのそこん所を確認してみたところ(MP12)
 なにやら、Iフレームの位置出しの分、AVCの方が1割程度有利になるらしいことが判明
 サーチキュルキュル的には、HEVCさんは用済みの扱いになっちまったようです‥(ほへ☆)

 (じゃ、腹を括ってDVDの置き換え分の増量を覚悟しないとな)



posted by 木田舎滝ゆる里 at 20:34 | Comment(0) | 月下涙焉 | 更新情報をチェックする