2022年08月16日

【インターレース】デジタルとアナログでコーミングノイズが違うんじゃが(アニメ)

↓3)記稿.2022/08/16

> デジタルのインターレースとアナログのインターレースって違うんですよ(アニメ)


 デジタルのインターレースをモニター上で縮小再生すると(デインターレース無効)
 インターレース部分が浪波になるのに

 アナログのインターレースで同じことをやると
 お約束のシマシマ&がっつりコーミングノイズになるっす

 (昔のビデオデッキカタログには、くし形フィルター搭載なんてのが目玉だったりしたのですが)
 (当時はなんのことかサッパリだったのですが、インターレース解除の補正さだったわけですね)


 ‥なにが言いたいのかというと
 編集の際には、どちらとも同じ解像度で編集されるわけですが
 人の眼には同じに見えていても
 デジタルとアナログのデータ構造がまったく異なるからこその↑の様相になると‥

 (なので、フィルムをスキャンしただけでは、デジタルデータとしては不十分)



1-3)1

> ついでなので、2-3プルダウン(30i)→24pにする際の屁理屈を一つ
> 手っ取り早く説明するために↓の図をご覧下さい(拾いものでm(_ _)m)


2-3 プルダウン.png
<参照元>:https://steinberg.help/nuendo/v8/ja/cubase_nuendo/topics/film_transfers/video_telecine_process_three_two_pull_down_c.html


 4枚の駒を5枚に拡張するのが
 2-3プルダウンと称されるフィルム映像向けのインターレースです

 これをよく見ると、24駒に戻せそうに思えてきます(逆テレシネ)

 例えば、一つ目のフィールドで一コマ(A)
 二つ目のフィールドもそのままに一コマ(B)
 五つ目のフィールドもそのままに一コマ(D)として素直に抽出できそうです

 では、元のCを抽出するにはどうするのか?
 B3-C1のフィールドのボトムからC1を
 C2-D1のフィールドのトップからC2を
 それぞれC2+C1の組み合わせ(ひっくり返し)でイケそうに見えています

 ところがです、ソース側エンコードの状態が問題です

 フィールド毎にビットレートが同じなわけが無く
 さらにマクロブロック単位においては、どこに元になるデータが収録されてあるのかが謎です

 なので、C2+C1の組み合わせどころか、B1とB3,D1とD3でさえ同じとは限りません
 (思い切りよく、間を間引いても、噛み合わず、カク付いたりするわけです)


> 所謂、心理的エンハンスト効果って奴で、違和感ないようにi補正されてあるからでしょう


 ‥ようは、参照フレーム数やら、参照フレームMixやら、bフレーム云々やらで
 フィールド単位を飛び越えて、量子化やらかして
 マクロブロック参照の位置が複雑怪奇になるからです

 (ソースがオープンGOPを採用していようものなら、そりゃもう謎でっせ、無理)
 (DCTありでエンコードされていたりするのも、十分に怪しい)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 02:02 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年08月15日

【エンコード日記】BD映画版の収録長さによる都合と品質

記稿.2022/08/15

> 一般にDVDなら120分、BDも120分
> 既定品質で収録可能になっているわけですが


 DVDの場合なら、片面で120分以内なら既定品質なわけですが
 どうにもBDの場合は、色々と違っていることを思い知りましたん


 BD映画版ともなると、まず、おまけ映像ありきになっているせいか
 タイトル本体だけの収録としたサービスは、あまり見ないようです

 なので、アニメで90分程度が、25分モノをちょいと上回る気配の品質を醸しだし

 それ以上になると、段々と品質が下がるらしく
 らしく上下カットせざるを得ない状況にあるらしい(&予算絡みでしょう)

 (TV版のまんま映画版で120分近くなら、25分モノより、品質劣化の可能性を疑わざるを得ない)


> とくに、アナログ版収録の場合


 パン部分のブレブレがあったりすると
 作業をした人の器量やら状況がそれだったりするので
 作品全体でのブレブレ傾向を見せ、パンでのカク付きが気になりがちだったりします

 (BDでそれなら、DVDなんざ問うまでもない)


 ‥そういう作品タイトルは、4k版になるとパン動作で安定を見せる傾向にあるようです
 (HEVCの33方向なんちゃらってのが、誤差補正に猛烈に効くっぽい)
 (まぁその代わりに、テクスチャーパターンが削れやすいとかなんとか‥)
 (どちらかというとHEVCは、実写向きの構成に思われるわけですが‥謎)

 (AVCに見慣れてると、HEVCでのそれの差に、困惑するんすよ)


> 諸々サービス抜きでも、多言語化等‥音声にこだわるとビットレート持って行かれるので
> 瞬間帯域の制限はどうにもならないので、UHD期待ありきでしょう


 ‥そもそも、BD規格初期の段階に、7.1CHなんざ想定してなかったはず
 BDにガチ載せしたら、映像の品質を下げにてこ入れせざるを得ないのは明白‥無理無理‥
 映像のマルチチャンネル化でさえ、画質低下でスルーされたのに‥謎

 (なんだかんだとUHDにしたって、機能拡張していけば、ザルになるに違いない)


 ‥そこで富裕層対象とした、専用デッキのみ再生可とする方向ってか?
 富裕層なら、いくらでも上位規格への買い換えをして頂けると
 毎年に順次拡張していっても商売できるとかなんとか(制作環境無視情勢)

 (だったら、拡張カード式にしないと誰もついてこないんちゃう‥差し替え式とか‥)
 (只でさえ、半導体不足なんだし‥その内大丈夫になるなんてありえへん‥)



posted by 木田舎滝ゆる里 at 14:35 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年08月06日

【エンコード日記】Big/SignedとLittle/Signedの違いとは???

記稿.2022/08/06

> BDのPCM音声をwavに再変換すると
> 設定:Big/Signed → Little/Signedに、問答無用で変更される


 ‥この差が気になる音声にぶち当たってしまい、とても困惑
 ‥この差が気になる音声にぶち当たってしまい、とても困惑

 Big/Signedのままの方が、伸びが細かいように感じられるンニャニャァァア‥


 (なにがどう技術的に異なるのかがまるでわからないニャー)
 (今まで気になったことは無かったニャー)


> らしそうな検索ヒットが
> ビッグエンディアンとリトルエンディアンに思われるのだが


 ・ビッグエンディアン
  データをバイト単位で配置する際のやり方のひとつで
 「最初のバイトからデータを並べる」やり方


 ・リトルエンディアン
  データをバイト単位で配置する際のやり方のひとつで
 「最後のバイトからデータを並べる」やり方


 (それだけのことで、違いが明確に発生するだなんてとても思えニャイニャ)


> だがしかし、劣化が多少は認められるから
> フリーでの取り回しをやらかせできている‥ブツブツ‥(やっぱ、わかんニャイニャ)


 ‥ちなみにソースは
 □□版□☆□☆□□■■■■篇□○□のエンドロール曲っす

 (昭和と平成の境辺りの昔には、DATという20ビット録音がもて囃されておりまして)
 (その手のアプコンで発生するっぽい気配に思われるわけですが)
 (その手のソースは、DVDだと16ビットに抑えられているわけですが)
 (今まで、とくに気になったことは無く‥まぁAC3にしちまうからかな‥)


 ‥でも、今回の件で言うなら
 BDで24ビットにアプコンされた結果、何かが違ってしまっているというのだろうか?
 (その差がたまたまLittle/Signedの際に引っ掛かるなにかがあったとかなんとか)
 (‥ああ、面倒くせー)

 (たまたまDVD版(16bit音声)との比較もできて、こちらの方が幾分都合良く聞こえるような‥)
 (もとい、勢い余ってハイレゾ加工する際に、都合の良い素材化しているような)
 (PCM16bit48KHz→flac24bit96000KHz→wav32bitfpLE48KHz‥てな感じに‥)

 (無論、BD版Big/Signedまんまの方が伸びが良いに決まってる歴然たる差はあるっすけど‥)

 (ちなみに、扱いの異なる32ビットにするとMediaInfoで認識不能に陥るっす‥)
 (いろいろと認識度が低いので、wav32bitfpLE48KHzはやりすぎっすけどね)



posted by 木田舎滝ゆる里 at 00:10 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年07月26日

【エンコード日記】新しいアイデアが降りてきて‥まだまだ終わらない件

記稿.2022/07/26

> {バッファ:最大ビットレート}の値を{1:1}にすると高周波域が優先される
> Bフレームを使用すると高周波域が優先される
> そして、これは一般にスタンダードなエンコード設定だったりだろう


 ‥ん?、じゃどこかでぼかし調整をやらかせば好いんじゃねぇ?
 候補に上がったのが「AQ強度値」‥(まぁどこでも同じに思われる)
 (当然ながら、この方向のレシピは、1080→1080pという事になる)


 ‥それにしても、XMedia Recodeの最新版で
 解像度変更で落ちる原因が未だに不明で、解像度変更無しでもどうにかやれんと後で困るし
 で、いつの間にか設定のてこ入れがされて、ブロッキング軽減の初期設定が遂に外されちまってる
 (オフにすると、全体的に微ボケが入る感じに思うのだが、FHDモニターにも無いので何とも‥)


 ‥さらに
 AC3が二つに増えてるのだが、バグなのか、選択支の意味が無い状態になっちまっちいる
 これは何とかして欲しい(俺的には選択支の多すぎるのは困る、しょうがないのでE-AC3を代用)
 (選択肢が多くなっても、それの違いを推し量る環境には無いし、要素の基本的意味もわからん)

 (まぁもはや1080→1080pでは、テレビUSB挿しも爆Qるンも前提にしないのだけど‥)


> 話を戻すと、どのようにAQ強度値を弄るのかと言う事になるわけだが
> 弄ったのなら、弄った意図に沿うようにビットレート変更もきっちりする必要がある
> というのが、継続した思考に沿った方向だ


 0.5625=1.00÷1.3333…^2 でやってみたところ、実写の動きの激しい部分で問題発生
 0.64=1.00÷1.25^2 に落としても、まだまだボケ感が残るくさい
 0.81=1.00÷1.1111…^2 にしたら、アニメでもFHDらしさを覗かせて好い感じになるっぽ

 だがしかし、量子化済みソースにあるせいか、ノイズをひっぱて来るだけにしか無い状態らしく
 残念ながら‥参照フレームMixを(□)に
 当然ながら、bフレームの安定を狙うならp4×4も(□)に

 さらに、I4×4は、演算上の誤差修正の参考程度に添えられてる程度で
 画質向上要素として、積極的に盛られているわけでは無いと判明
 ということで、≒24pなら‥レベル5.1で十分らしい

 (つまり、1080→1080pでは、爆Qるンを求めず、より画質の安定を狙う方向になるっぽ‥)


> で、ビットレートになるわけだが


0.81=1.00÷1.23456790123456790… ※(1.1111…^2)

1920÷1.1111…=1728
1080÷1.1111…=972
16×9=144
1728×972÷144=11664

 1.111111…で、1920×1080解像度が割り切れてしまうことに驚いたが
 それの(1728×972)を想定したぼかし具合というのが
 大抵の数値で端数を導いてしまうので
 1.111111…^2=1.234567890123456790‥で割り切れるところが
 1.234567890123456790‥×1.44=1.777777…
 1.777777…×2.25=4

 なので、{平均:バッファ:最大}={1:4:4}

 34492=972×36=11664×3
 {36:144}={34992:139968


> ところが、aq(3:0.81)だと、ソースによってはまだまだノイズが乗ってしまうところが有り
> 少しばかりぼかしてやる意味で、aq(3:0.80)且つビットレート計算を(0.81)とする
> (解像度1088と1080の誤差折り込みみたいな)


 ‥いやいやこれが何というのか
 通常なら、高周波域の大部分をそのままに一番に低周波域をちょびっとぼかして終了しがちなのが
 全体を平滑&平均的に間引きしつつ、画像印象ほぼそのままに
 まぁ微々たる欠落が想定位置で見られるのは、相も変わらずだが

 {Bフレーム:ref:GOP長}={4:8:12}のままにて、想定ビットレートの削減に成功

 とはいえ、平均(34992)なので、25分想定は‥6.48GBと言ったところで参考程度だ
 (まぁ実写なら、0.5秒置きにキーフレームがあれば、キュルキュル感は十分だろう)


> ちなみに、心理的エンハンストは触りません(I4×4に前提鎖動してるくさっ)



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

2022年07月25日

【エンコードレシピ】有言実行の爆QるンCランチ(480i→1080p(Bob)→720p)圧倒的版

↓一次処理+二次処理12)記稿.2022/07/25


|MPEG-2爆Qるンやあのサーチ 同じくしたき今ここにAVC-Q
 
|窮すれば美学に奔る冬の角 命の価値を問うてをり‥(いざ天誅)
|をる影を未だ照らさず秋深し 格差はいつも他人の素振り‥(いざ粛正)
|素振りから計れぬ未熟落ち椿 殺意が「誠」と抜かす無念
|無念よりこぼるる雫花朧 命の是非や夢のまた夢



> 用意して頂くアプリは
> XMedia Recode 64bitのバージョン3545です。
> 最新版から、x264.dllを抜き出して、3545側のと差し替えます。(略)


 ‥取り扱うランチの種類は(略)
 今回レシピは、Cランチ(わさb抜き圧倒的版)のみになってます。
 Cランチのみ「二度揚げ」手法を用います。
 (HDDの空きを大きく用意しないと作業完遂不能‥これは痛い‥)


一次処理> 480i→全部盛り1080p[Bob]

> 一次処理の用とは、とくにDVDの480i映像は可変フレームレートだったりと
> 頭に描くようなお手本としたインターレース構造になってません‥(謎)
> あと、ここでは全部盛りなので、全部盛りの解像度を、一旦、正しく捉える用があります。


 ‥480i映像の有効解像度は、704×480です。
 ‥引き延ばして調整する規格にありますが、720×480まで盛られています。
 ‥盛られてある向きは、4:3映像に見られるフィルム揺れを盛り込んであるからです。
 ‥なので、4:3DVDソースを単純に704に切り取れるかというと、そうはなりません。
 (又、ビットレート不足から横端を断ち切ってある様子なら、正しく4:3展開など無理な話です)

 ‥16:9ソースでは、その空白地帯をも利用して、細かい端数計算をやってるので
 ‥制作会社ごとに黒帯の置き方が異なります。
 (どのソースがどのような構成をしているかなんて‥根気の無駄づかいなだけでやんす)


> ‥ということで、正しい比率で全部盛り拡大 → 16:9に再構成 → 統一です。
> ところどころで誤差計算が気になるわけですが、そこはまぁ手順を踏むことで良しとします。


◆ XMedia Recodeにてmkvを選択

・ Ut.video(コーデック)を選択
・ フレームレートをオリジナル→[59.94]に変更‥(Bobの鎖動条件なので忘れずに)
・ カラーモードを[YUV4:4:4Planar24bpp]に変更

 ※ここでGBR(RGB)を選んではいけません。再エンコードするたびに色ずれの因と化します。
 ※全部盛り→16:9再構成なので、割り切れない解像度変更がもう一度待機しています。
 なので、確実に各ビット別に計算できる「4:4:4」を選択しましょう。

 ※ちなみに、VLCプレイヤーは、Ut.videoの4:4:4映像をサポートしていません。
 ソース状態を確認したかったら、AviUtl等のアプリで確認するようにしましょう。


◆ 音声トラックは、好きにやって下さい
◆ インタレース解除項目の目のチェックを外す

 使用するフィルター:Yadif
 モード:時間軸&空間軸のチェック(Bob)をスキップ

 (※Bob指定そのものが、≒30→≒60フレームレート変更(手動)と鎖動です)
 (※スキップ指定しないと、i映像の輝度が解除演算にて削られて、画質が決定的に劣化します)

 順序:自動.


◆ クロップ/プレビューにて

内部4:3の場合
 幅:1472 [2](解像度に奇数値を取り扱わず)
 高さ:1080 [2]
 スケーリング:双三次スプライン
 ディザリング:自動
 アスペクト比:カスタム【1.363636】‥(手動で打ち込み)
 アスペクト誤差:-2.2727…(自動調整値)‥に整っていなかったら打ち間違いあり‥
        :0.0000(BD収録タイプで、もともとが1.363636で編集されてある場合)
 拡大:なし
 □ アスペクト比を保持
 720×480


※ 1440:704=x:720 を解くと、x=1472.727272…
 並びに、1472.727272…÷1080=1.363636…



内部16:9の場合
 幅:1964 [2](解像度に奇数値を取り扱わず)
 高さ:1080 [2]
 スケーリング:双三次スプライン
 ディザリング:自動
 アスペクト比:カスタム【1.818181】‥(手動で打ち込み)→(1.818182に自動的に書換あり)
 アスペクト誤差:−2.2727…(自動調整値)‥に整っていなかったら打ち間違いあり‥
 拡大:なし
 □ アスペクト比を保持
 720×480


※ 1920:704=x:720 を解くと、x=1963.636363…
 並びに、1963.636363…÷1080=1.818181…
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 16:53 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年07月22日

【エンコードレシピ】有言実行の爆QるンBランチ(1080i→720p)圧倒的版

↓12)記稿.2022/07/22


|この服の爆Qるンやいざ試着 ステッキぽちいリボンぽちい

|欲しがれど厭き憑くほどに影法師 何十億ものうつむく眼
|目を覆う無力万感 梅雨の家事 膝を折れどもぼっちの暮らし
|暮らし向き水平線や冬の音 負け組だもの満身創痍




> 用意して頂くアプリは
> XMedia Recode 64bitのバージョン3545です。


 最新版から、x264.dllを抜き出して、3545側のと差し替えます。
 (最新版だと解像度変更の際に、アプリ落ちするのでそれの代替です)
 (落ちる原因は不明です‥マシン構成絡みかもしれません問題なしなら最新版で構いません‥)


 ‥取り扱うランチの種類は
 Aランチ(1080p→720p)
 Bランチ(1080i→720p)
 Cランチ(480i→全部盛りBob→720p)とした三つです。


> 今回レシピは、Bランチ(わさb抜き圧倒的版)のみになってます。


 ‥VLCプレイヤー使用時
 古い再生支援機能だと映像に乱れが生ずる場合もあるので、そんときゃoffに‥
 >ツール>設定>入力/コーデック>ハードウェアアクセラレーションによるデコード>無効
 (設定をクリックした後、VLCプレイヤーを再起動)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 16:53 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年07月21日

【エンコードレシピ】有言実行の爆QるンAランチ(1080p→720p)圧倒的版

↓12)記稿2022/07/21

|トロまぐろ爆Qるンやトイレ駆け 頬張りたくて再びの席

|席問えば二択を迫る花霞 価値同じしも見映え天と地
|天と地に跪いても豊の秋 ここぞ故郷ここぞ踏ん張り
|踏ん張って湧き来たる悦 意気軒昂 垂れ出しゆくは糞か銭か




> 用意して頂くアプリは
> XMedia Recode 64bitのバージョン3545です。


 最新版から、x264.dllを抜き出して、3545側のと差し替えます。
 (最新版だと解像度変更の際に、アプリ落ちするのでそれの代替です)
 (落ちる原因は不明です‥マシン構成絡みかもしれません問題なしなら最新版で構いません‥)


 ‥取り扱うランチの種類は
 Aランチ(1080p→720p)
 Bランチ(1080i→720p)
 Cランチ(480i→全部盛りBob→720p)とした三つです。


> 今回レシピは、Aランチ(わさb抜き圧倒的版)のみになってます。
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 20:06 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年07月19日

【エンコード日記】{平均:バッファ:最大}={36:81:100,144}だった件

記稿.2022/07/19

※ 36を64と誤記しておりました‥m(_ _)m
※ 225を255と誤記しておりました‥m(_ _)m


> 約すと{平均:バッファ:最大}={36:81:100,144}だった
> (なんて美しい配比に見えちまうんだろうや‥)


 ‥ちなみに、前記事の実写特化型だと
 {16:81:100,144}と{36:225:−,400}になる

 (端数値の打ち込みストレス減で良いですね)
 (計算値をこまめにできちゃうってのは、無駄に調整トライしたくなっちゃうz)


> という事で、更なるとある発見をしたような話なのですが
> 丸めて言うと、巷に転がる丸まりすぎたb狂リップの遠近感を
> なんちゃってながらに、錯覚視で回復できちゃうみたいな内容です
> (まぁその多くが「解像度減×増量」前提たるんですけどね)


 ‥だまし絵の多くは、遠近を騙すという塩梅を見せますが
 ここでは、主にその遠近を騙しているみたいな解釈になりますが(主にアニメ)
 丸まりすぎた動画に対して、均一に微々な間引きを加え散らせることで
 細かく言うと、絵面を超微にざらつかせることで
 それだけのことで、遠近感が復元されたかのような塩梅を得ちゃうみたいな

 (ビットレートを適切に割り振ると、ざらつき感が消え失すみたいな‥)


‥729=1.6875^2×256
729×16=11664
729×64=46656
729×81=59049
81÷16=(81÷64)×(64÷16)
5.0625=(4)×(1.265625)
2.25^2=(2^2)×(1.125^2)

 ‥てな感じの数値からの発見だったのですが
 こちらは、{16:64:81,未確認}={4^2:8^2:9^2,未確認}の並びを得ています
 5.0625=4×1.265625


 ※ 技術的な要素を述べておくと
 平均の正方形とバッファの正方形が離れるほど、辞書用マクロブロックが増えて精細さを得
 バッファの正方形と最大の正方形が離れるほど、低周波域が間引かれずにノイズやらかしを得る

 つまり、{16:64:81,未確認}は、{36:81:100,144}に対して
 精細さを加えつつ、且つ、プチノイズやらかしを加えつつとした形っす

 ちなみに、{バッファ:最大}={1:1}は、猛烈に低周波域を剥ぎ取って輪郭強調やらかします



> b狂リップの他に丸まりすぎた映像というと


 一層4時間ものどへんたいDVDは難しいだろうにせよ
 一層五話DVDアニメやら
 狂うほどにケチな平均ビットレートの「DVDアルプスの少女ハイジ」なんか該当しそうです
 (「DVDまんが日本昔ばなし」の方がビットレート盛り盛りなんすからねぇ‥納得できん‥)


 ‥無論、丸まりすぎてるように見えても
 {36:81:100,144}の方が適当だったりするソースも有るわけです
 (その辺は、てめえで悩んでちょ)
 (まぁその時の概ねは、5400×2 or 5400×3 辺りだったりとするっぽ)

 (基本、b狂リップは、丸まりすぎてるんで、DVD以上の無理やりありきってもんですな)


 ‥720pの限界としては
 ビットレートを減らしすぎると、プチプチとしたjpgノイズに見舞われます
 それらプチプチは、再生支援を用いても解消せずに発生しちまう内訳です
 (具体的には、5400×2を下回ると怪しくなってきます)

 でもなぜか、1080解像度での無理矢理に対しては、しっかりと再生支援してますな
 (‥との要素違いのある次第をまず理解しときませう‥無論、爆Q構成比との話っす)



posted by 木田舎滝ゆる里 at 16:01 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年07月18日

【エンコード日記】実写の低周波域をさらに削るための数値比(6.25)

記稿.2022/07/18

> 720p{平均:バッファ:最大}で、快適なビットレート(21600)を得るわけですが
> なぜ‥ビットレート(21600)でピタリとするのかというと
> 2.25×2.777777‥=6.25 → 6.25×4=25 → 5400÷25=216
> 2.25×4=9 → 9×4=36 → 36÷25=1.44 → 1.7777777…÷1.23456790…=1.44
> さらに(13500)の場合、5400×2.5
> ちなみに(216000)の場合、5400×4
> 4÷2.5=1.6 で、この(1.6)の逆数が(0.625)


 ‥という次第から(6.25)に注目
 ‥すると

 2.5^2=6.25
 1.5^2=2.25 → 2.25^2=5.0625
 1.111111…^2=1.2345679012345670…
 1.333333^2=1.777777…
 1.666666^2=2.777777…

 5.0625×1.2345679012345670…=6.25 ‥≒24フレームレート用途(BD実写用)
 5.0625×1.777777…=9 ‥≒60フレーム用途(DVD実写用)

 6.25×1.777777‥=11.111111… ≒60フレーム用途(一部BD実写用)
 を得た


> 2.25×1.2345679012345670…=2.777777…, 2.25×1.777777‥=4
> それぞれの対比と同じになってます
> つまり、24フレームレートと60フレームレート(Bob)の比差が
> ref(8)と(9)の差込みで、{1.111111…^2:1.333333^2}程度に丸まっちまうらしい



 ≒24フレームレート用途(BD実写用)5.0625×…=6.25の時
 {13500:68343.75:84375,121500}‥×2.5
 では、バッファ値が割り切れていないので
 ↓↓↓↓↓
 {13824:69984:86400}‥×2.56 の代替となります(ちなみに、1.024倍差です)

 ↑で、2.25×…=2.777777…比の
 {21600:48600:60000,86400}‥×4の見た目とほぼ同等になるようです(Pタイプ実写)
 (‥概ね36.0%減比を得ます)


> {平均:最大}={1:2.777777…,4}は、アニメにはとくに適当ですが
> DVD実写の場合、気になるレベルのノイズやら粗さがまだまだチラホラ残ります
> そこで、5.0625×…=9を採用すると


 つまり、{13824:69984:124416}‥×2.56(DVD実写用)を盛ると
 気にならないレベルまで、ノイズ感の減衰を見せ、落ち着いてきます

 (テレビ設定のノイズ除去機能をオフにしたまま安定的に見られます、そのまんま☆☆☆でしょう)
 (DVD特撮なら、時代を経る毎にBD画質との差が無くなってくるのがわかるでしょう)
 (ホームビデオも美麗に甦るのでは‥)


> 6.25×…=11.111111… ≒60フレーム用途(一部BD実写用)は
> BD「北の国から」45分モノ実写映像を4GBに収めるための模索です
> (5.0625×…=9 でも、まだまだ不十分だったので検討しました)


 {13500:84375:150000}
 11520:72000:128000
 {10800:67500:120000}‥※奥行きの潰れ感が気になりだす端境
 {8100:50625:90000}‥てな感じの数値が並びます

 ビットレート(11520)が上限の4GB想定なので
 どことなく妥協せざるを得ない様にも見えますが、まぁそこは実写なので、色が出るようです

 ‥これを調子こいて
 {21600:135000:240000}として目一杯を、2-3プルダウンアニメでやっても
 明度はしっかりするも、色の噛み合っていないブロック使い回しの無理が、不思議と出やります

 (という事で、アニメの圧縮と実写の圧縮は性質が違うのがよく解ります)
 (まぁ予想ですが、量子化前のマスターレベルなら、ブロック使い回しの無理も低減するかと‥)
 (そうならば‥BD規格としては外れるとしても、インターレースの代替として使えるかも‥)


> ちなみに、576pで出すと、イレギュラーな位置でのIフレーム増し増し追加が発生し
> これはなぜか1080pでも同じで
> 余計なビットレートを持って行かれて、既知な値に沿わず、計算し難く
> なんだかんだと、適切な爆Qるンになるのは、720pサイズ限定の様相です


 (720pの爆Qるンの段階で、すでにDVDのキーフレーム量を上回る勢いです)
 (ときにはながながとしたイントラ地帯も出現するので、おったまげっす)



posted by 木田舎滝ゆる里 at 17:33 | Comment(0) | AVC-Q | 更新情報をチェックする

2022年07月16日

【エンコード日記】Bフレームなどもう選択肢に無いのだから‥

記稿.2022/07/16

> 圧倒的にそのまま‥Bフレームを追加してみた‥B&Cランチでは(6:9:15)を使用


 ‥Mix無しでb8×8有りで盛ると、動きからして劣化する
 ‥Mix無し&b8×8無しで盛ると、動きはまぁそれなりに保持されるが微にボケている
 (だが、問題となっていたアプコン時の乱れは発生しない)

 (予想するに、Mix込みで安定したバッファ比が有るようにも思われる)

 (ちなみに、2.25倍比とした値だと、自由度がかなり低い)
 (それこそビットレートを適当に落とそうなら、端境をカクカクの四角い粒でやっつけてたりする)
 (五に絡んだ値の為せる融通の無さと言った感じで唖然とする)
 (こんなんでマクロブロックMixやらかそうなら、イレギュラーばかり発生しそうで使う気しない)


> だが問題は
> もはやbフレームを用いたとて、容量軽減に値する十分な画質を得られそうに無い‥
> (容量そのままでも、画質が同じ程度を保持できないならその可能性が高い)


 そんなこんなで‥2.25倍比のままb8×8までを綺麗に出すには
 同じ解像度とした条件が有ったりするのではと妄想してしまうところだが

 基本的に、bフレームとは、上手にぼかす為のノウハウなのだから
 エッジを際立てつつ、きちんとぼかし技法等まで保持してしまう
 Pフレーム特化型のわさb抜きと較べては、bフレームに期待するところはもはや無いのでは?


> ちなみに、なぜ‥ビットレート(21600)でピタリとするのかというと
> 2.25×2.777777‥=6.25 → 6.25×4=25 → 5400÷25=216
> 2.25×4=9 → 9×4=36 → 36÷25=1.44
> という割り切れる関係だったという事らしい


 (まさかのテレビUSB挿し制限超ギリギリでしかないとは‥オッタマゲ‥)
 (あとまぁ試しているのが)
 (16×16マクロブロック比の2倍3倍の平方根もまた割り切れているとして扱えるのでは?)
 (数学的にも日常的な値ですからね‥その辺の誤差修正ぐらいお手のものに思われると‥)


‥こんな感じ
1280×720→(80×45=3600)(×1.5=5400)
{21600:48600:60000,86400}‥×4
{16200:36450:45000,64800}‥×3
{10800:24300:30000,43200}‥×2
{5400:12150:15000,21600}‥×1
{13500:30375:54000}‥×2.5


1024×576→(64×36=2304)(×1.5=3456)
{17280:38880:48000,69120}‥×5(?)
{13824:31104:38400,55296}‥×4(?)
{10368:23328:28800,41472}‥×3
{6912:15552:19200,27648}‥×2
{3456:7776:9600,13824}‥×1
{8640:19440:34560}‥×2.5(?)
{10800:24300:43200}‥×2.5×1.25(?)

 ‥Cランチの場合、1024×576で、2.25比ガチ攻めすると
 発色こそbt.601だが、遜色ない模様(SMPTE 170Mを指定しないとガタガタに)

 (いつの間にか、ソースより微に縮む可能性が濃厚なんだが‥インパクトは小さいかと‥)
 (でも、注目こそ、Bob化分の増量比がゼロに相殺されるって事っすね‥)
 (バッファ比調整の潜在力に、マジにおののくであります)


> 確認は、まだこれからなのであしからず
>(寝惚けていて設定ミスって二度手間したり‥日記とレシピのタイトル付け間違えたり‥)
>(寝惚けてボケ気味失敗に見えても、起きて再確認するとしっかりと見えたり‥)
>(夏だし、そこまで入れ込まずとも、一旦、レシピ出して区切るのも有りかと‥)


posted by 木田舎滝ゆる里 at 12:03 | Comment(0) | AVC-Q | 更新情報をチェックする