2021年05月10日

【エンコード日記】割り切れる数値でAQ差を脳内識別できてるならロボットと変わらんぜ

記稿.2021/05/10

> AVC-QでのHDサイズ出しを
> 17280(÷_5)/21600(÷_5)で確認していくと
> どことなーく違和感が付きまとうと同時に、音質の不足ですよとした何かが脳を叩いてくる


 ‥音質が不足しているようにも思うし
 ‥でかい画面で視聴したい欲求にも駆られてくる(何かがおかしい)


 ‥どうにも調べていくと
 15360(÷_5.625)/19200(÷_5.625)‥だと劣化を感じ
 16000(÷5.4)/20000(÷5.4)‥だと音質共にしっくりくる

 ‥このような変化は
 つまり、可変ビットレート(89)による変化という事だろうか?

 (配分の妙で、その辺りに変化をもたらしているとかなんとか)


 19200÷21600=0.888888888888888‥(逆数1.125)
 19200÷20000=0.96
 20000÷21600=0.9259259259259259‥(逆数1.08)

 20000でのAQを(1.08)に設定したものが21600に等し
 19200でのAQを(1.125)に設定したものが21600に等し
 それを逆にすると
 21600でのAQを(0.9259259259259259‥)に設定したものが20000に等し
 21600でのAQを(0.888888888888888‥)に設定したものが19200に等し
 20000でのAQを(0.96)に設定したものが19200に等し


 ‥つまり
 17280(÷_5)/21600(÷_5)で確認している時の違和感とは
 エッジがキツいということになる(え☆そうなん??)


> AQ調整もそんな感じだからそういう事に思われるわけだが
> そんな感じでの差しか無いなら
> 今後のビットレート調整は、是をお手本にするべきになる‥
>(にしても、0.01刻みというのは、人間技としてはちと厳しいと思うぞ)


 ‥それにしても
 ものの見事に割り切れる数値での差を垣間見るに
 極めていくと、割り切れる数値にしか脳が反応しないって事なのか?
 それが人間の感性でしかないとすると、ロボット依存妄想にもなるっすね

 ‥人間自体が造られた何か?
 ‥もとい宇宙自体がその類とかなんとか
 (だからって、割り切れない数値を選びたいと思うほどにはみ出したいとは思わない)
 (あ、でも人生の多くで、割り切りたいとは思ってなかったりするっス)


> だがしかし、これがFHDモニターとHDモニターの差かもしれないことを
> こちらでは確認できないのであしからず
>(だってそれぐらいの差でしかないなら、ハード対応で吸収するしないの世界でしょ)



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

2021年05月09日

【エンコード日記】DVDを4kサイズに一次処理してからのありえない比率

改稿.2021/05/15...20210509...

> 16:9の切り捨てせずの計算、ミスしてました‥すんません‥m(_ _)m


> 720×480(DVD規格のサイズ)
> 704×480(実際の有効表示面積)


 ‥という意図不明な規格になっている
 なので、480i&480pを4k倍に一次処理するにしろ
 規格面積フル利用 or 有効表示面積‥とした選択を迫られる


> まず、誤差を出さない為の値を求めると次のようになる


 720÷704=1.022727272727273
 720×1.022727272727273=736.3636363636364
 720×1.125÷1.1=736.3636363636364

 720÷16=45
 704÷16=44

 45÷44=1.022727272727273
 9÷8÷1.1=1.022727272727273

 88×1.125÷1.1=99÷1.1=90
 __88 __99 __90‥(横16のマクロブロック数)
 _176 _198 _180‥(二倍した横16のマクロブロック数)
 2816 3168 2880‥(求めるべきピクセルサイズ)


> つまり、740→2880とは
> 規格面積フル利用時の最大横幅736.3636363636364→3168を切り捨てずに
> 有効表示面積704→2816を含めて保持した状態を意味する


 ‥尚、この状態は正しい4:3比率では無い
 32+2816+32とした内部構造になっている

 なので、これを正しい表示有効面積に引き延ばして
 さらに、16:9に換算した黒帯を付けるとすれば
 3840−2880=960
 960÷2=330
 330−32=298(左右)となる


> アナログ式4:3映像の場合は、切り捨てずに左右黒帯の横幅を減らすだけで済むわけだが
> デジタル式16:9映像の場合は、切り捨てるか、上下黒帯を設けるかの二択になる


 ‥切り捨てる場合は
 サクッと740→704と削ってから3840にするのが一番に簡単だ
 但し、DVD映像にも左右黒帯が備わるので、実際の比率がどうかとなると
 その正否はもどかしい、制作元にしか判らない

 ‥なので、すべて内包する方が無難に思われるにせよ
 その正否は不明である事を許容しなければならない
 (嫌なら‥そのまんま720×480に戻して3:2である云々を許容する選択になる)


 ‥まず、有効面積である2816を元に16:9を求めると
 2816×1584を得る
 ‥なので
 求められる横解像度は、2880→引き延ばし3840

 求められる縦解像度は、2160→1584(縮小)+288(上下黒帯)
 横解像度の広がり比が1.333333‥倍になるので
 1584にもそれを掛けてやると2112が得られる
 2160→2112+24(上下黒帯)‥とした形になる

 (いやぁやっちまいました計算ミス‥恥ずかしい‥)
 (エンコード出ししてから記事を書けばよかったz)



> ‥エぇぇえ☆★‥
> 上下288の黒帯って、マジっすか??


 ‥そんなんシネスコサイズみたいなの
 ‥BD版とは又違ったバージョンの派生同然じゃねぇっすか
 (ちなみに、HDサイズなら96(上下黒帯)、FHDサイズなら144(上下黒帯)になる)

 (‥別の意味で無駄に興味がわいちゃうz‥)



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

2021年05月08日

【エンコードレシピ】進撃のAVC-Q規格(HDサイズ推奨)

↓12)微修正2021/05/09...20210508...

> i一次処理4k時、M.E. 範囲(32)を書き忘れてました


> AVC-Q規格の「Q」とは、サーチキュルキュルの意でーす
> まずは個々でエンコードだしやってみようの段階でーす(あしからず)


 ‥そもそものBD規格の核であるAVCの中身が、永遠のDDR2規格のままで言い分けが無い
 ‥貴様にはまだまだ可能性があるはずだッ

 ‥FHD規格縦1080のサイズは、16x16のマクロブロックでは割り切れない
 なので、内部1088でのビットレート配分計算を予想する必要があった
 実際、そのように表記されている(縦8ドット分が未表示ってのが本当の実体に思われる)

 1920×1088÷256=8160
 8160(16x16),32640(8x8),130560(4x4)

 195840(×24フレーム)/244800(×30フレーム)
 13056(÷15)/16320(÷15)
 16320(÷12)/20400(÷12)
 19584(÷10)/24480(÷10)
 24480(÷_8)/30600(÷_8)
 30720(÷6.375)/38400(÷6.375)‥許容限度ビットレート域
 38400(÷5.1)/48000(÷5.1)
 39168(÷_5)/48960(÷_5)‥帯域限度ビットレート域(USB2.0)
 48960(÷_4)/61200(÷_4)


> 驚くことに、帯域限度ビットレート域で再エンコードしても
> 拡大静止画での見た目は、どうにもm2tsソースよりは微にボケてしまうものらしい


 もっとも、フレームに絡みついているJPEGノイズ分が綺麗に吹き飛ぶので
 その点は良好ではあるのだが‥(それを繰り返しちゃったらどうなるの??)

 その分だけ微にピンボケてしまう印象に変わりは無く、それ以上はままならない‥
 驚くべきは、(÷5.1)で確認すると
 その段階ですでに、許容できないボケ差を確認できてしまったことだった‥orz

 但し是は、4kテレビで見た場合の許容とした予想であって
 30型に満たない制作用PCモニターからでは、許容内に思われる


 ‥それでもこれの不満をAQを弄って調整しようと試みるなら
 AQ(1.25)程度欲しいと云ったところだろう
 そして其を、通常の平均ビットレート値に換算し直したとき
 (÷_4)の値を要求する予測に及ぶことになる‥

 只でさえ(÷_5)の30フレーム25分ものでの再エンコードファイルサイズ想定が
 8GBを超えてしまうのに、誰が好き好んでそれ以上を試みたいと思うだろうや‥

 ‥そこでなんだかんだと、それでもFHDにこだわりたいなら(÷6.375)までが許容だろう‥
 (17280×1.777777‥=30720)
 (1.333333‥×1.333333‥=1.777777‥)
 (1.125×1.333333=1.5)


> だが著生は、そうではない


 ‥進撃したいんだから、「HDサイズ上等」なのだよ
 それにしたって、25分もの一話あたり3GB〜4GBに及ぶのだから
 それはそれで、大容量型のUSB期待にあるわけだが、どうにもその様な時代はまだまだ先らしく
 だからといって、USBメモリーをTVに挿しっぱのままは、熱が直にテレビに伝わってやばいので
 そんなのは大容量になろうと同じっぽいので
 そうなると、どれだけHDD一台にぶち込めるかという使い勝手の差になってくる

 ‥そこで、タブレットやスマホに挿して視聴すると仮定しても中途半端なサイズ感は否めない
 だが、USBコネクターに複数個ぶっ挿すとすれば、そりゃ大容量のUSB期待のままに変わりは無い
 (挿した事無いので、それで認識するのかどうかは知らんけど)


 1280×720÷256
 3600(16x16),14400(8x8),57600(4x4)

 86400(24フレーム)/108000(30フレーム)
 5400(÷16)/_6750(÷16)
 5760(÷15)/_7200(÷15)
 7200(÷12)/_9000(÷12)
 8640(÷10)/10800(÷10)
 10800(÷_8)/13500(÷_8)
_11250×1.024=11520
 11520(÷7.5)/14400(÷7.5)
 14400(÷_6)/18000(÷_6)
_15000×1.024=15360
 15360(÷_5.625)/19200(÷_5.625)
 16000(÷5.4)/20000(÷5.4)‥推しビットレート(からにスマートな質に感じられるがパンチは弱い)
_16875×1.024=17280
 17280(÷_5)/21600(÷_5)‥推しビットレート(エッジが微にキツくなる傾向)
 21600(÷_4)/27000(÷_4)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 23:55 | Comment(0) | 月下涙焉 | 更新情報をチェックする

【自動フィールドシフト】鱧(はも)の小骨を食らわんと(プチ修正)

↓6)改稿.2021/05/08...20201130..20201128...

> [判定比]をデフォルト値に戻しました
> 理由は、パンで妙なカク付きが発生しちゃってるから(もっと早く気がつくべきでした、すんまへんm(_ _)m)



> 自動フィールドシフトでもインターレース解除しかねるダメなパターンに遭遇


 実写ソース:PV|動物と乗り物がいっぱい|ウルトラマンボーイ

 ‥ウルトラマンボーイがポニーの牽く前席だけのオープン馬車に乗って手を振っているカット
 その遠くに見える牧場の柵がちょうど細長のシマシマ状態となり
 そこにまんま、バリバリの細長いインターレースが、どハマりになっており
 解除するにたるデータ不足に陥るらしい

 つまり

 細長いシマシマ模様で、かつ、中間色の色幅に乏しい色調の組み合わせだった場合
 そこにインタレースが被ると詰みになると考えられる

 (このパターンは鬼門で、グラボによるハードパワーを用いても完全解除は厳しいだろう)
 (※ 解除精度が上がると、縞(しま)の外側から成功率が上がるっぽ)


> あと、自動フィールドシフトの想定外に位置するインターレースというのがある
> なので、常時確認をする事が大事なのら(単に経験不足)


 ‥如何にも2-3プルダウンにしか見えないのに
 解除しようとしまいと、5コマ置きに一枚だけブレ駒があったりなかったりという
 ソース:DVD|原作単行本第4巻限定版|未確認で進行形

 そのような場合には、トップとボトムを入れ替えてみよう(一晩悩んじまったz)


> では、まずは必要最低限度の調達です(もとい、お借り致します。m(_ _)m)


AviUtlのお部屋
aviutl110.zip
exedit93rc1.zip
bmp_output.zip

UtVideo
バージョン 22.3.0(2021-04-24)

L-SMASH Works r940 release1 / mod1
r940 mod1

rigayaの日記兼メモ帳
AviutlColor
自動フィールドシフト


> 最後工程をXMedia Recodeでやらかすおいらは、とりあえずこれで足りるっす


 ‥で、ここからが初心者の第一の関門
 「自在にファイルを読み込ませられるまで」
 キーワードは「exedit.ini」でーす(ググって勉強しましょう)


 ‥ちなみに
 DVDのインターレース解除に、[自動フィールドシフト]×[UtVideo]を使用した場合
 AC3ソース → 32ビット×3072Kbps‥とした見たことない高ビットレート出力になる
 (うれしいような‥うれしくないような‥)

(そのままは無理だし、さらに変換しては野暮なので、やはりコピペでしょう)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 12:22 | Comment(0) | 月下涙焉 | 更新情報をチェックする

【エンコード日記】いやんなシミの正体

記稿.2021/05/08

> 動画エンコード上の「いやんなシミ」とは
> どのような映像の中にもなぜか出現してしまうもやもやとした浮遊物体のことを指す


 ‥この正体は
 ビットレート不足による、強制的なBフレーム内の時間軸で圧縮された箇所らしい

 一番に多く発生するのが「パン」シーンの最中である事から
 そのように断定しておくのが適当に思われる

 (‥只でさえBフレームへのビットレート配分は少ない)
 (それはPフレームに対して1.3倍減程度を規格の想定としているにせよ)
 (実際は自動処理される設定に成りがちなので、不明と言わざるを得ない)
 (さらに減らしていると知れるとやばいので‥生活保護にも秘守してあるとしか思えない‥)


 ‥そこは、自信をもってBフレームが極端に少ない場合があっても当たり前と胸を張ったにせよ
 ‥なら逆に、一番にカク付きしやすいパンシーンに対して
 配分比率を高めに備えられてるだろうか?

 ‥DVDなら、可変フレームレート技を施してある場合も見られるが
 ‥BDの場合には、そんな設定は出てこない(せいぜいがインターレースありきだろう)


> ‥という事で
> B-フレームモード内で時間軸圧縮が選択されたソース映像からは
> リピート的に残像を漉き込むオチになる


 ‥この残像の漉きこみ部分こそが、不自然に浮遊するもやもやとして登場するのだ
 通常、ただでさえそれだけでパンは激しい動きの部類に入るというのに

 より激しい動きが追加されてると、どこかを端折ろうとしてエンコーダーが頑張っちゃうので
 結果として、時間軸を介したすり込み箇所を見つけ出すらしい(オフにしろよもとい使うなッ)
 結果として、動きが激しければ激しいほどに、残像の時間も長かったりするらしく糞ッ


 ‥ビットレートをケチってるというよりは
 追いつかないというか
 そういうグデグデになっていると、その手の映像は
 シミがあるどころか、パンのカク付きも酷くて
 どちらかといえばこれのDVD版の方がスッキリしていたと思っちゃったりのデキだったりする

 (なんでDVDの方がすっきりしていた印象になるんだ?)
 (それこそが3枚単位にしてあるDVDの特徴なんだろう‥あと可変フレームレート技もあるし)

 ‥その点BDは‥容赦なく23枚構成をデフォルトにしたGOPになっている
 さらに(シーン変更感度:40)では、体良く短くになんて緩急をやらかさない
 とにかくもう‥「ご愁傷様」と言うより他は無い


> ‥でも、DVDにだってそりゃシミは見られるし、カク付きの酷いのも見られる
> ‥だからこそ、シミの無い&カク付きも見当たらないタイトルにぶつかると
> そりゃもう信頼度は上がる
> その会社のBDの品質もまんざらでは無いとさえ思うだろう
> だがしかし、動きの少ない作品と激しすぎる作品とを比べたって意味は無い


 (円盤にmade in korea表記がされてあるのを見たそんときは、うなだれるより他は無い)
 (そんな円盤が時間経過と共に読み込みにくくなっていたりすると、さらにorzだよ‥)
 (HDDに移動しておいて何が悪いって話にもなってくる)

 ‥そんな業界のやっつけな積み重ねの結果が
 染みつきパンツ‥もとい染みつきリップなんだからな
 そういう意味では‥ビデオテープやLDの時代の方が安定していた


 ‥それにしてもなんでテレビ放送の時はその手のシミを見られないのかが
 その差がどうにも不可解でどうしようもない

 テレビ放送には厳しい制限があるけど、BDはご自由にとした空気だからだろうけど

 じゃどうしてそれの制限を設けてるNHKは、そこん所の紹介を一切やらないの?
 税金投入してるも同然なんだぜ、秘守義務なんて通用しないだろうがっ
 その手のしっかりとした本ぐらい出せよ、何様のつもりだろうや


> 近年はNHK自体が基盤だパンツのシミくさいからな
> それぐらいの後押しサービスもできない連中なのだろう
> 放送文化も糞も無い、ただのどや顔したいだけの連中なのだろう
> (VVCの登場で今度はいよいよ16kでーす‥もちろん染みつきパンツでーす‥とかなんとか)



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

2021年05月06日

【エンコード日記】4:3映像にi4x4を用いても基本的に誤差しかもたらさないので‥

記稿.2021/05/06

> 1920×1088÷256=8160
> 1440×1088÷256=6120


 8160は16の倍数だが
 6120で、2のべき乗べき乗で割り切れるのは4までなので

 4:3映像に、i4x4を宛がおうとしても斑にしかならないということになる

(IフレームとPフレームの間の輪郭強調の為の錯覚利用が上手く作用しない意)
(誤差しか無いなら、違和感にしか成らない‥ということでi8x8止まりらしい)


 なので、基本則として、黒帯を追加して16:9映像にしてからエンコードすると
 i4x4までを綺麗に演算できるとの予想が立つ


 ‥これは、放送上の都合とかでは無く
 綺麗にエンコードを仕上げるための都合だった(痛ぁあああ)

 (HEVCで4:3出しとか、無知の極みッってことっすね)


> i4x4にまで均割にビットレートを入れられると
> その分だけ‥いやんなシミが落ち着く程度になるらしいが‥
> 4:3映像が悩ましいと思ったら、黒帯追加16:9でもやってみるべし


 ‥なにげにインターレース解除は、概ね16:9にせざるを得ないってことですね
 (適切なビットレート値を見つけないと、それこそ只の増量っす)



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

2021年05月05日

【エンコード日記】シミと動きをどうにかするポイントを2つほど発見

記稿.2021/05/05

> 以前にHDサイズのエンコード用に使っていた
> ビットレート(16875)が
> bフレームを抜いたそのまんまの設定でも、ものの見事にシミが消失近くなるのを確認ッ


 ‥☆なるほど、そうだったのか


> つまり、24フレームにおいて
> GOP(8)ref(4)って事で


 それを24フレームタイプわさB抜きにあてると
 M=1,N=5の形に置き換わるケースが概ね安定らしく

 さらに30フレームタイプわさB抜きには
 GOP(10)ref(5)をあてると
 M=1,N=6の形に置き換わるケースが概ね安定らしい


> シーン変更感度:89 の時
> ref=(GOPの半分値)
> GOP=(フレームレートの3分の1値)
> M=1,N=(ref+1)


 ‥つまり、GOPの設定には
 遊びとなる余裕を設けてやらないとうまくいかんと云う事らしい
 (遊びの分も計算した結果、長すぎたGOPの発色の差を嫌って捨てるという事かも)


 ‥それにしてもこんな風に、マクロブロックの塩梅とGOPの様相が固まっちまうと
 ビットレートとは、まさに発色の濃さの演出でしかないと言わざるを得ない

 なので、テレビの発色を統一していないと
 自分のテレビの発色如何で適切なビットレート値が全然違ってくる事になる

 (なら、業界の自慢げな大型モニターでは、シミが気にならない設定だったって事ですね)
 (概ね手狭な部屋の庶民のモニターでは当然そうでは無かった‥)


> にしても


 ‥縦解像度が同じでも
 横比率が違ったり、フレーム数が違ったり、もちろん画面サイズが違うと
 シミの薄れる適切なビットレートが違ってくるのでまだまだ先は長そうです

 ‥鍵はどうやら、ビット/(ピクセル*フレーム) の値で
 それを特定値にしてしまう操りができれば
 シミの消失点を、どんなモニターでも自在に消失させられる可能性が有るものと予想する

 ちなみに‥(0.764)辺りが良好らしいがまぁ参考に

 ‥計算式があるだろうから、計算方法を理解しているなら
 計算しながら近づけるのが早道に思われる(知らんがな)



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

【エンコード日記】わさb抜きにはGOP(6)ref(5)らしい

記稿.2021/05/05

> いやんなシミが濃くなる理由として


 ...GOP(3)ref(2)だと
 GOP(2)ref(1)に置き換えられてしまうパターンがかなり起こる

 ソース程度の濃さに落ち着かせるには
 Bフレーム(3)に似かよらせる必要があるので‥Ibbbp‥
 GOP(6)ref(5)にするのが対処で
 GOP(5)ref(4)‥IpppP‥とした引き算パターンを狙うのがよさげ


 ‥GOP距離の一枚引き算されなかったら
 GOP(5)ref(4)に設定し直してやってみるのも有りかも知れないけど
 それで今度はGOP(4)ref(3)に引き算されちまわないとも限らないので
 その辺は時間コストで妥協せざるを得ない部分になってくる

 もしくは
 シーン変更感度をデフォルトの(40)に戻してしまう選択肢もありだが
 そうすると概ね指定したGOPの長さになりがちになるので
 GOP長に変化が生じがたい傾向になるわけだが(HEVCだとほぼそれだけど)

 まぁどちらにせよ、テレビUSB挿しにおいて
 Bフレーム(3)に似かよらせる構成では、わずかながら
 キュルキュル感の減りに残念さが伴うに変わりは無い
...


> あと、自動フィールドシフトの件だが


 ‥自動フィールドシフトのそもそもが120フレーム対応なので
 30フレーム出力だと、器用に間引きされてしまっているので
 ソースに忠実な駒状態としての再現性は正確とは言えない

 (だからといってトップとボトムをつなぎ合わせるだけだとカク付いて見えがちだったりする)
 (人間技だとトップとボトムでしか思考が追いつかないわけだが)
 (機械的な判断にやらせると、超えた判定にて駒の繋がりに様がわるのも一興と思わざるを得ず)

 (‥24フレーム化する手もあるが)
 (キラキラ表現のある映像では、フレーム構成が崩れる事で)
 (キラキラの構成からして崩れてしまう傾向を見るのがオチだろう)
 (これはマクロブロック構成の都合なので、自動フィールドシフトとてどうにもならない)
 (参照対象の基本情報を持ったブロックが削られるとおかしくなるという事らしい)


 ‥是の値の調整は「判定比」で行われているわけだが
 0にすると切れるにしても
 1にスライドするだけで、自動フィールドシフト状態に突入するので
 その間の加減を確認できるのは、ほぼ120フレーム選択時だけに思われる
 とはいえ、肝心のAviUtl自体に120フレーム選択が無いのだからどうしようもない

 (自動フィールドシフトの作者は、AviUtlのそこを改造したバージョンを使用しているのだろう)
 (となるとメモリー周りが違うだろうから、64ビットのβ版の存在がチラつくわけだが‥)



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

2021年05月04日

【エンコード日記】わさb抜き限界盛りマグロ丼の「なるほど」

↓4)記稿.2021/05/04

> (なんだかんだと)すじノイズの発生はBフレームの影響大なり


 ‥そもそもこちらは、サーチキュルキュルにしたいのに
 Bフレームを使用していては
 Iフレーム選択位置に影響するのだから、わさB抜きに踏み込まざるを得ない


 ‥そこで、再びレベル設定の仕様書の確認を
 今回は(ストアされる最大フレーム数)とやらに注目

 レベル4.1には
 1920×1080 @30.1 (4)とある
 つまり、先読みしてバッファにキャッシュしておける枚数の最大が4枚と言う事だろうか?

 レベル5.1には
 1,920×1,080 @120.5 (16)とある
 つまり、ref値の最大を16に指定できると言う枠組らしい‥(16)以上は表記に出てこない‥


> ref(4)は絶対では無いというのだろうか?(先ずは確認)


 ≒24フレームには、GOP(8)にてREF(7)を
 ≒30フレームには、GOP(10)にてREF(9)を、放り込んで見た


> そこで、問題点が2点ほど発覚した


 ‥パソコンからでもどことなくもたついてるシーンが見られると思いきや
 肝心のテレビUSB挿しでは、とんでもなくもたついた
 (基本的に使えない、DDR5程度のメモリー規格で漸くに成立する予約プログラムっぽい)
 (ということはBD規格ってのは永遠のDDR2程度を前提にした品質って事なんですね)orz


 ‥そして、それ以上に課題になるのが発色だ
 Bフレームの効果として後方参照がある
 前ばかりを参照していると、どうにも‥手綱捌きを要求されるっぽ‥

 Iフレームの映像を参照しがたい場合には、其より後ろ位置のPフレームを参照する事になる
 今更述べるまでも無く、Pフレームからしか参照できないGOP間での後ろの枚数が多いと
 そいつらの出来合いには、どこかしらの発色が弱くなるパターンが発生してしまう

 ‥このような不都合をBフレームでは
 後方参照とPB間での割り当てビットレート量のメリハリをやらかすことで
 そこの発色の差を‥錯覚させて復帰させる用途での効果を併せもたせてあるらしい(へぇ〜)
 (これもまた心理的エンハンスト概念という事に成るのかもしれん)


> そこから、結局、今や適切なビットレート量を把握してしまっている事もあり
> そこから、結局、今や適切なビットレート量を把握してしまっている事もあり


 ....‥GOP(3)、REF(2)に落ち着いた‥★☆★..
 (24フレームと30フレームとの差は、ビットレート量で調整するだけで十分に至った)

 ‥GOPを短くしていくと
 GOP距離の差に伴うGOP毎に発生するビットレートの偏りを抑制する効果を得る
 (つまり、GOP単位で見ると、より均一にビットレート配分される傾向になる)

 ‥テレビUSB挿しにおいては、制限帯域をやたらと突破されても困るので是しかない
 (FHD30フレームでは、結構なケースでギチギチの箇所が続出する‥なんてこったい‥)
 (ビットレート(48960)以上はどうにもありえない‥)
 (でもまだまだ場面によっては重いらしいので、DDR4メモリーマシンぐらい欲しいかも)


> ‥適切なビットレート量
> もとい、均等な配分確率を高く期待できるビットレート値による効用って
> そんなにもすごいのか??(それ以外に良好を得るようになった変化の差を判断できん)
> (‥AVCのバージョンも上がる度に良好にはなってるけど)
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 21:27 | Comment(0) | 月下涙焉 | 更新情報をチェックする

2021年05月03日

【エンコード日記】なんちゃって4k化したものを再リップした場合のグデグデ課題

記稿.2021/05/03

> プログレッシブソースをAVCでなんちゃって4kサイズ化したそれを
> 後からダウンコンバートしようなどと目論んだのですが
> 何をやってもどうやろうとも、いやんなシミの発生確率が上昇する傾向にハマるようです


 ‥一次処理用途に4k化して効果を発揮するのは、インターレース解除を目的としたソースのみ
 (インターレースにもいろいろとあるので、細かい調査はまだまだこれからですが‥)


 ‥元々のソースに、もやもやとして動くシミ箇所があると
 アップコンバート方向の方が正確にテクスチャーパターンを保持しやすいので
 それを今度は縮小する段階で、ソースサイズでは目立たなかったシミ候補群までもが
 より強調されてシミとした斑に成り変わるということらしい


 ‥いやんなシミ発生確率上昇のグデグデを避けようと思ったら、AVCでは役不足っぽい
(つまり、HEVCに見られるテクスチャーパターンをスパッと落としてくる感とは)
(ダウンコンバート用途織り込み済みということかもしれない)
(HEVCの心理的エンハンストにはその手の都合が含まれている‥)

 (NHK放送では、各チャンネルへの配信から必須とした都合になるのは説明するまでも無い)
 (そして、4kからダウンコンバートされて放送されてる美麗映像のすべてはインターレースだ)
 (HEVCではインターレースをサポートしていないのだから、AVC映像のはずなのに‥)


 ‥これはつまり
 プログレッシブ4kソースを
 AVCでプログレッシブのままにダウンコンバートする試みには、無理があると言う事だろう

 (HEVCとはいえ、シミの見られないソースなんてほぼ無ぇ)
 (インターレース化にはそこを吹き飛ばしてしまう何かがあるとかなんとか‥)
 (とはいえ初期の頃の4kものダウンコンバート放送にだって粗があって酷い箇所も見られた)
 (高度な前処理をどこかに盛り込んだに違いない‥)


> 正確に視認確認できる機材を持ち合わせていないので、これ以上は何とも申し上げられません



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