2022年08月26日

【エンコード日記】m2tsファイルをPっちり切っちゃう謎な切り方(XMedia Recode)

記稿.2022/08/26

> XMedia Recodeでm2tsを切り分けたい場合
> 通常のやり方だと問答無用で、後半部のそれに、ディレイ発生してしまうわけですが
> 問答無用で、Iフレームからしか切り出せないわけですが
> ケースによっては回避できてしまう謎の切り方を発見しました


 (但し、すべてのケースに対応しているわけでは無いらしい)

 ‥まず、クロップ/プレビューの映像トラックを出します
 で、そこの ||▶ボタンと [ ボタンを使用します

 切りたいIフレーム位置もしくは半端なPフレーム位置より
 一つ前のIフレーム位置を割り出して

 そこでとりあえず、 [ ボタンを押して開始時間確定します

 そこから再び、 ||▶ボタンを押して一コマ動かし
 再び、[ ボタンを押して開始時間確定します

 其の作業をを‥お目当ての画像位置まで、えっちらおっちらと繰り返します


> 是のボタン操作が謎で
> まるでコマンド打ちにでもなっちまったかのように
> 連続打ちすると、出てくる駒が、切っても切ってもIフレームに化け続くんすよ


 (押しても押してもIフレームが続くようだと、なぜかPからでもぴっちり切れる‥謎)
 (なので、この技を「Pっちり切り」と呼ぼう‥当然、コピーモード使用での話だ‥)

 (どう考えてもバグの類にしか思えないのに)
 (普通にやるとPフレーム位置のはずが、どうして頭にして切れるんだよ?‥てな感じになる)
 (で、うまく適正にあるようだと、ディレイ発生せずに切れてるって寸法だ)


 ‥バグで無いなら、ソース構造が後付けでくっつけてあるって感じのを
 XMedia Recode側が、I位置を一枚ズレて表示している可能性がある(四捨五入誤差くさい)

 (avidemuxで確認すると大抵ズレているので、どっちが正しいかは、AviUtl確認になるが)
 (まぁ逐一確認するのは面倒としか言いようが無いのだが、そこはてめえでやってちょ)


> まぁ、Pっちり切れるにこしたこたぁねぇてな感じ
> (いろいろと試してみるのも面白いでしょう)
> (ちなみに使用したバージョンは、3545っす)



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

2022年08月17日

【其は正しいか?】フィルムグレイン(化学班、化学紋、化学楔)の意味

↓2)記稿.2022/08/17

> 画像圧縮の際に、シロウトは、フィルムグレインの解釈で躓くわけだが
> それが何なのかを理解していないと、残念な圧縮にしかならない


 ‥確かに、気にせずに潰し込めば、圧縮率は上がるにしても
 大抵は、てめえが使用する目的外の利用において、要求を満たさない画質に成り下がる

 正規に映像を売る方にしたって、とくに、マンガ等の静止画など
 どのような機材に、それら画像を表示して楽しむのかを事前に説明もせずに売りつけている

 海賊版を流す方にしたってそこは同じで、お互いに欲求が違っていれば
 当然の如く、再圧縮願望を募らせることにも繋がろう


> そこは、解像度を選んで売る時代に至っていないからこその不始末をやらかしているも同然だ
> 否、お買い上げ頂いたからには、いつでも自由に別解像度を選択自由に選べなくては意味が無い
> (そのぐらいにやらないと、海賊版の排除には至るまい)


 ‥いつでも変更できるとした対価感覚での年会員制とした位置づけぐらいにはできる
 (されど、管理経費は、双方共に馬鹿にならない)
 (付け加えるなら、解像度×ビットレートの是非なんじゃが)



 まず、私たちの映像文化は、白黒写真に始まり、カラー写真にて激変した
 白黒写真は、印画紙に現像液とした兼ね合いで
 カラー写真は、フィルムを基に、印画紙と現像液を用いる

 まぁよくは知らんが、そこには化学反応が欠かせない

 結果、化学班、化学紋とした核となる粒子に、なんちゃらがまとわりつくことで
 反射を見せ、色を紡ぎ出している
 その当時、カラー化の際に色の手本とされたのは、述べるまでもなく鏡だった


> そもそもフィルム化された裏には、駒を繋げて試写できないかとした映画があった


 ‥つまり、映画が創造されて
 私たちの脳は、いつのまにやら、フィルムグレインありきにカスタマイズされたのだ

 なので、鏡と同じように再生されているとした思いこみの裏では
 フィルムグレインまでを、眼に、視野に焼き付けてきた

 だが、それをブラウン管を介して眺めだした時代、それがノイズの元だとは誰も考えもしなかった
 技術者の多くにしても、走査線や電圧差等での因果関係を思っていたぐらいだったように思われる
 (疑い始めたのは、デジタル化の際からだろう)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 15:43 | Comment(0) | AVC-Q | 更新情報をチェックする

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 | 更新情報をチェックする