2021年02月19日

【テレビ設定】目の疲れにくい好逸オート(TN風TXT専用)

記稿.2021/02/19

> テキスト打ち仕事に液晶テレビをモニターにするには明るくありすぎる
> と言うことで用途不明のオートモードに辿り着きました
> 但し、このモードでの映像視聴をオススメしません(慣れると又違って見えちゃうんだけど)


◇◆テレビ項目設定◆◇
映像メニュー:オート(限定)

バックライト:−24‥※すべて±30からの差分になります
ピクチャー :−20‥※±の幅が違う場合は比率を割り出して試してみましょう
黒レベル  :−16
色の濃さ  :  8
色合い   :  4
シャープネス:  0

液晶AI  :オン(10月頃~2月頃にoffにするよりはオンのままで良いらしい)
色温度   :低−中
ビビッド  :オフ
超解度   :オフ(操作不能)
NR    :オフ
HDオプティマイザー:オフ
明るさオート:オン(操作不能)
テクニカル :切(操作不能)



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

2020年12月17日

【エンコード日記】テクスチャーを99%らしく保持してビットレートを半分に(1080p)

記稿.2020/12/17

> これより先は[AviUtl]と[XMedia Recode]の二刀流になります


 ‥ちまたに転がるアニメのリップファイル(1080p、≒24フレーム)には、高品質なのも見られますが
 所詮は、Bフレーム重視×低低ビットレート(10000以下)域タイプです
 その結果、Pフレームが外されて輪郭が目減りしており、ボケ気味です

 それらのリップファイルの輪郭をどうにかしようとすれば増量させざるを得ません
 「それに意味はあるのか?」の問いは勿論ありますが
 それらを程度どうにかできるということは
 それと同じ容量程度で逆のこともできるはず‥


 つまり、BDtsのテクスチャーを保持しつつビットレートを半分にできるはず‥ということです
 (それができれば、720pとはおさらばです)

 映像のボケを直すには、シャープフィルターありきです
 シャープフィルターを優先して利用します
 逆のことをやろうとするなら扱いを逆にすべきが理屈です


> つまり、敢えて適正にぼかした映像に改造‥下処理してから、再エンコードしよう作戦です
> ‥720pにてテクスチャ崩壊しちまうよりはずっとマシな選択です
> ‥解像度維持にて、単にビットレートを減らすだけでも、部分崩壊やらかしますからね


 (CG処理という奴は、人の目で判断できないことを判断できてしまうので)
 (下処理でぼかすにしても、それの適正値さえ得られればこっちのもんです)

 ‥まず、BDtsをAviUtlに、16ビット設定(プラグイン利用)で読み込ませます
 ぼかしフィルターの順位をシャープフィルターより一つ上位に設定します

 (10ビットソースの場合は、10ビットで読み込ませます)
 (8ビットソースの場合は、丁度二倍にできるので16ビットでやります)


 標準実装のぼかしフィルターの値を
 強さ:168
 範囲:2
 下限値:2
 上限値:1008

 標準実装のシャープフィルターの値を
 強さ:252
 範囲:2
 下限値:2
 上限値:1008

 に設定します

 その状態で、ut.videoで、BT.709,422を選択して出力します
 (色の設定は入力・出力ともに自動にしておきます)

 抽出されたノンレスファイルを(ソースから見れば、もはやノンレスではありません)
 XMedia Recodeにて、19008000ビットレート、partitions all、レベル6でエンコードします
 その他の数値はとろ重に倣ってください


> 人間の感覚では、ぼかしの強さの方を強くすべきに思うところですが
> それだと720pに似通った間引きになるようです
> 同量にしても単にビットレートを減らしただけと同じ傾向です
> なので、後から当てるシャープフィルターを強くした方が良いと言う意外な結果を得ています


 (まだテスト確認中なので速報扱いになります)



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

2020年12月15日

【エンコード日記】動画再生支援機能の罠

記稿.2020/12/15

> VLCプレイヤーにおいて、ハードウェアによる動画再生支援にすると
> どんな低ビットレートでも、そつなく綺麗にされて見えちゃってまーす


 つまり、バリバリに瞬時に補正を掛けまくっているということです
 (AviUtlで綺麗に見える‥なんてのも同じことかと‥)
 そんな糞リップの中身を、ソフトウェアデコードに切り替えて視聴すると
 途端に、とても見られたもんじゃない無残な姿を晒します

 (え☆こんなにヒドかったん???)

 で、動画再生支援に固定しとけば良いと思うも
 CPUにもよると思うが(否、それにしたってx264での対応はレベル5.2までかも)
 レベル6を想定していない場合には、レベル6エンコード内容にて格子落ちが発生します

 この格子落ちを相殺するには、ソフトウェアデコードを用いることで解決するようですが
 まぁ若干、ハードウェアの方が発色が良いのかなぁと思う差があるような感じです


> ということで
> ハードウェアによるエンコードをやると綺麗にならない仕組みとは


 ハードウェアのデコード上限イコール能力で、超高速に低低ビットレートなエンコードしてたら
 そりゃデコードの際に、補正分の余地がなさすぎて、効かないってことになると思います

 なので、ソフトウェアエンコードで低低ビットレートをやると
 その分、補正を掛けられる余地が速度的に発生するから
 ということなのかなぁなどと思っちまいました(所有してないから具体的な状況など知らん)

 (そもそもからして、低低ビットレートでの静止画画質に期待などできるわけがない)
 (どうにも低ビットなjpg群が、加速して補正されながら再生されると綺麗っぽく見える仕掛け)

 どちらにしても、低低ビットレートの状態の内訳を
 プレイヤーのソフトウェアデコードで視聴した場合、ガチで糞リップである可能性が高くなるっぽ


> VLC>ツール>設定>入力/コーデック>ハードウェアアクセラレーションによるデコード
> DitectXビデオアクセラレーション(DXVA)2.0


 ‥の状態にしておくと、BD再生時適応と同じであるらしく
 サーチ時に、BDソース再生時独特の格子模様を味わえる


> VLC>ツール>設定>ビデオ>出力(U)
> Windows用OpenGLビデオ出力


 ‥の状態にすると(*ハードウェア再生支援を無効にしておく)
 比較的ハードウェア再生支援に近い発色を得ているように思われるっす
 (VLCを再起動して確認の用あり)


> ‥ということで
> レベル6格子落ちしないで見られる条件が判ったという事です


 マシンスペックの最低条件は?‥などという解には興味が無い

 ソフトウェアデコードで
 どのぐらいの低ビットレートだと糞リップな格子再生をやらかすかの端境に興味はあるが‥
 (調べる気無し)



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

2020年12月08日

【エンコード日記】DVD→1080p化の際の黒帯をどうすりゃいいのか?(今更‥)

記稿.2020/12/08

> 1920×1080p(≒24フレーム)の時
> BD規格でのビットレートが概ね38000(ビットレート)


 ‥なので
 1920×1080p(≒30フレーム)の時
 同じ画質を得ようとすると1.25倍の47500(ビットレート)が必要と考えられるが
 誰もそこまでを望んじゃいないという不可解がある


 ‥一方で
 DVD→1080p化をした映像になると
 不思議とBDより丸まっているので半分のビットレートで済むらしい
 つまり1.25倍の適正実験がしやすい

 47500÷2=23750
 (やってみると、Level6×partitions allの効きを十分に発揮するようだ)


 ‥こうなると、
 DVD→1080p化の際のLevel6×partitions allの適性が
 それぞれの半分ということで

 1920×1080p(≒24フレーム):38000(ビットレート) → 19000(ビットレート)
 1440×1080p(≒24フレーム):28500(ビットレート) → 14250(ビットレート)
 1920×1080p(≒30フレーム):47500(ビットレート) → 23750(ビットレート)

 で、イケるということなのだろう


 ‥ちなみに
 1280×720p(≒24フレーム)換算にすると
 38000÷2.25=16888.888…88
 なので、16875(ビットレート)にほぼ近い
 この差がb8×8が効くか効かないかの境と考えられるわけだが
 (720p化には独特のややっこしさが付きまとうということなのだろう)


> ところで、双方共に、非解除3:2状態の時とは違い
> テレビUSB挿しでのテレビ側の自動調整は発生しない
> (というより1080p化でやらかすならPC再生前提だ)


 ‥つまり、自動調整で起きているそれぞれを、自前で事前に処理する必要がある

 そこでまず、BDts(4:3)iで縦解像度に帯が付いてカットされているソースから確認してみた
 結果、黒帯を取り除く事で、うんざりだった要素が解消するらしい

 参考:1416×1062、1408×1056 → 1440×1080化

(上下で16ドット分の黒帯がある時、8で割り切れても4:3では割り切れない)
(この割り切れない不都合が、パンシーンでのガクガクと化していた)
(黒帯だけしか取らないと比率が合わないので、合うように上下1ドット分カットせざるを得ない)
(このパターンの場合のみ‥≒24フレーム化ありきのような気がする‥)

(又、実写フィルムの場合、太陽光やらの露光影が発生するからか‥左右の黒帯に位置差が見られる)
(位置差の分まで削ろうとすると、全体を通してみた場合かなり削ってしまうことになる)
 (デジタル撮影では補正されてるってことかな???)


> ‥で、改めてDVDソースを確認してみると
> 「黒帯を‥どう切りゃ良いの?」


 調べてみると
 DVD規格の大前提として
 「DVDプレイヤーは必ずピクセルアスペクト比 10:11 または 40:33 で再生すること」
 というのがあり

 どちらにしても、704×480とした解像度に黒帯追加とした都合になる話なのだが
 中途にデータが盛られていると、そのままに切って1080p化やらかしても違和感にしかならない

 そもそもなんで、DVD作品は横幅720で詰め込んでんだ?
 DVD再生機で再生する際には、横幅カットして再生するんだろう‥(意味ねぇじゃん)


> 色々と確認するに


 ‥とくにフィルムスキャンした状態の端が、どのような塩梅になるかは出してみないと判らない
 状態によっては、右端やら左端やらの片方を16ドット削った方が良い場合なども起こるらしい
 (なので、愚直に両端を8ドット分削りゃ良いという話にはならない)
 (これは4:3フィルムの場合になる)
 (状態が悪い側ほど段々のグラデ状だったりする‥ソース毎に注意して見ないと判断付かない)

 ‥デジタル実写の場合は、どうせ平均ビットレートで出すともなれば
 黒帯にしようが、データを載せとこうがさして変わらない
 せっかくだから左右4ドットほどに体裁を整えた加工を施し
 残りの左右4ドット分に対しては、そのままを盛り付けてるらしい
 (デジタルとはいえ、撮影がインターレースともなると余白事情が絡むということだろうか?)
 その割には、上下どちらかの2ドットを削る編集も見られる
 (アナログに見られる手ぶれ分の誤差が少なきゃ、乱れてる側だけを削るのが流れなのだろう)
 (アニメでもそれが見られるのは、倣ってデータ枠を足し引きしてあるということだろうか?)


> ‥なので、それぞれで黒帯域の付け方の定義が違っているとしか思えない‥
> (何ら手を加えないままだと、微に縦に細長い感じだ)


 個人で編集する分には、愚直に704×480に変換して後から黒帯を足すだけでも差し支えが無い
 商業になると、黒帯のままでは煙たがられるという作り込みの差ありきなのだろう

 (ズバリ、そんなこだわり編集に意味があるのだろうか?)
 (はじめから704×480の規格でええやん、ビットレートが勿体ない)
 (なんでそんな無駄をやらかす事になったかの黒歴史が登場しない点は解せん)


> 話は変わるが、インターレース保持でのテレビUSB挿しで上手く行かないパターンの場合
> 自動フィールドシフトでも標準的では無い結果をもたらす点を確認した
> (これも今更な話ではある)


 具体的に言うと、フレームレートを可変と書かずに偽装しちゃってるらしい
 (なにをやらかしているのかは不明)
 (その様な場合の対処に、自動フィールドシフトには30フレーム固定ボタンが備わる)



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

2020年12月04日

【エンコード日記】これはどうにも妥協くさい‥orz

記稿.2020/12/04

> いきなりですが抜粋です(ソース


(b)高域成分を低域より圧縮することによる損失
 人間の目の性質から、低域は視覚的に敏感であるため画質をよくするため多くのビットを割り当て、視覚的に鈍感でしかもデータ量の多い高域を粗く量子化することにより、効率的な圧縮ができる、また、この反面、情報量を失った高域部分の影響で、デーコードされた再生画像は、高域の量子化雑音の発生で高域のざわざわしたモスキートノイズを生ずる。

(c)量子化マトリクスを適応化することによる損失
 量子化の目的は、圧縮効果を得ることであるが、画像データブロックの性質により同様に圧縮しても劣化が目立つものと目立たないものがある、これをブロック毎に分析して適応的に量子化する。
 この場合の適応には、周波数成分によるものと画像の局所的な特徴によるものがある。
 高周波による適応は前期のようにDCT係数の低次に多く高次に少ないビットを割り付ける量子化を行い、局所的に特徴量に対しては、ブロック内の分散を検出して、変化の少ないところにビットを多く配分する。適応的量子化で全ての画像を完全に分析して適応化することは難しく、画像データブロックの特徴の分析にミスが生ずるとかえって劣化を招くことになる。


> ‥具体的に噛み砕くと


 ビットレート不足からの劣化はどう考えたって回復不能
 ノイズ感が多いと思ったら、ビットレートを多く盛りましょう

 動きのあるテクスチャーは、比較的正確に検出できるが
 動きの小さいかまるで無いテクスチャーは、動きが無いと判断されればされただけ間引かれる
 ということなので
 リップのリップとした繰り返しをやると動きの無いと判断されたところほど
 それはもう入れ子式算に劣化をやらかすことになる

 (まぁそういう傾向があるというのが、解決不能だったと言うことだけがはっきりしたった)


> ‥そこを踏まえて、とろ重(1080p)の塩梅は如何に?


 ビットレートの適性範囲が、どうにも、38000000ビットレート(アニメ)
 ≒24フレームと≒30フレームの差として

 ≒24フレーム:GOP(8)、ref(4)、partitions all
 ≒30フレーム:GOP(10)、ref(4)、b8x8を使わない

 とした720pとは異なり、幾分画質重視にしないと、全然ダメ
 1080pの≒30フレームの場合、b8x8を十分に満たす許容が全くの不明
 どうせ増えすぎたって忌み嫌われるだろうから
 ≒24フレームと同じビットレートでやり繰りする範囲として、使わない選択になった

 (普通に1.25倍にすりゃ良いなら47500000ビットレートになるが‥そりゃあかんでしょ)
 (ただでさえ、2PASS平均ビットレートにしないとLevel6格子が安定しないんだからそんな感じ)


> まぁ、BDtsソースが36000000ビットレートならそれに従うのがベターでしょう
> (まだまだ確認中です)


 ‥あと、デコードについては、ある程度の自由さを了承しているとの事で
 折角あれこれ悩んだリップも
 デコード次第(プレイヤー次第)では、ぶち壊しになったりそうで無かったりと
 得手不得手をやらかしてくれるという規格内容になっている


 (実際にも、VLCプレイヤーとテレビUSB挿しとでの差の出るソースを確認している)
 (ということは、HDテレビとFHDテレビとも違うというで、orz)


 なので、確認している静止画が必ずしもどのプレイヤーでも同じとは限らない

 つまり、一つの優秀と思い込んだアプリ頼みでやってると
 気づくのが遅くなったりする事にだってなる


 (あーもう面倒くせー、なにを信じりゃ良いんだよ!!!)



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

2020年11月28日

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

↓6)改稿.2020/11/30...20201128...

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


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

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

 つまり

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

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


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


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

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


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


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

UtVideo
バージョン 22.2.0(2020-10-2)

L-SMASH Works r940 release1 / mod1
r940 mod1

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


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


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


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

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

2020年11月19日

【エンコード日記】テレビUSB挿しインターレース自動的解除の決定的な弱点

記稿.2020/11/19

> 業を煮やして、エンコード設定を「とろ重」から
> 2-3プルダウンに特化した、GOP(5)、Bフレーム(0)、REF(4)にしても
> リバウンドを繰り返す箇所がどうにもならない事から


 インターレース処理のなんらかが
 リバウンドを繰り返すような短いGOPならではのその間にすっぽり収まると
 どうにも解消できないというのをようやくに理解した

 つまり

 はじまりのブレ駒はいつだって2枚、3枚でしか参照できないので
 きっちりと4枚分参照できる状態にないと、ブレを解消する為のデータ不足で
 リバウンド現象にハマったりもするという事らしい

 ‥このようなグデグデを解消するには
 2-3プルダウンからテレシネしたGOPの頭から二枚目と三枚目だけは
 後方を足して合わせて4枚参照できる構造が求められる

(というか普通にそういう構造にしないと、平均的な圧縮率の追求としては不足していると思う)


> 話は変わるが


 VLCプレイヤーの設定を解除オフにしたまま使っていて
 いつの間にやら、解除オンが効かなくなっちまっていたのだが
 今回、試しに弄ってみたら、普通に機能するようになったのだが‥

 (これって更新時にオフにしておくと、そのまま機能しないオチだったのだろうか?)
 (それとも妖精さんのイタズラだったのだろうか?)

 15年近い歳月を無為に、インターレース解除できねぇ不満を抱えていたような‥
 否否、VLCプレイヤーの性能がどっかでボケて、どっかで復活していたとか
 (繰り返し機能だって、使えねぇ状態に陥るからな)
 その辺の波のままに思い込んでいただけだったとか‥

 (なんかこう、そこはすっきりしないのだが)
 (ソースのそのままの解除画質を確認できたので、その点はすっきりできた)

 BDに関して言うと、無理に解除リップせずとも綺麗だったりで‥orz
 DVDの方は、手の入れようがあるとだけ理解した


> そんなこんなで


 ‥インターレース解除には
 アナログフィルム時代ならではの2-3プルダウンされているタイプと
 そうでないデジタル時代ならではの概ね2枚でセットでやらかしているタイプと
 さらにそれを特化して、部分的なインターレース状態というのがあるのを混同していて

 DVDのGOPがM=3, N=15だったりで
 奇数でもいいんだと思っていたが、それだと
 トップとボトムの入れ替わるケースが頻繁にでちまう臭いことに、今頃になって気がついた

 そして

 テレビUSB挿し頼みの自動的解除の更なる弱みとして
 テレビ放送の規格外のインターレース処理に関しては脆いというオチがついて回る事を
 ようやくに理解した


> つまり、自動的解除できるのとできないのが出てくるのは、当然の結果だった
> さらに、再リップ時の劣化が大きすぎるとダメになるパターンとそれの逆のパターンとがある


 どうにも煮え切らない作業はクリエイティブでないので詰まらないので
 もう少し、職人芸を楽しめそうな作業をしたいので
 AviUtlプラグインの「自動フィールドシフト インタレース解除」を試してみた

 なんか自動と手動を両方入れないとどうたらと書いてあったので両方入れたのだが
 機能がダブっているようで今ひとつよく分からないところはあるが
 なんとか使える状態が分かってきて思ったのが
 普通にトップとボトムを合わせるだけでは違うらしい(へぇ~)

 (GOPの関係で入れ替わったりすりゃ当然だ、今理解したz)

 そこの塩梅のうんちくはさっぱりだが、エッジやらコーミングやらを
 すべて取り除こうとするのは野暮ってもんで、上手に利用しようとの空気を理解した


> 世界観がまったく違ってたンゴ!!!



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

2020年11月17日

【エンコードレシピ】絶対無敵!月下のとろまぐろ重

↓12)改稿.2020/12/02...20201117...


|十三夜 泪のような部屋明かり ビットレートにまで透けにけり


 ‥本日の十三夜の月明かりが部屋の窓辺に泪のようだ
 泪のように美しいのか、泪を流すように儚いのか
 トライ・アンド・エラーの動画エンコードとは
 まるでそんな涙の量を重ねてしまった果てのビットレートの増量傾向に似ていて
 どうにも「月下涙焉(げっかるいえん)」だなあ

 ‥これはガチで勝負エンコードだあと思いつつも
 また次の満月がやって来るように終わり無く、切り無く
 ただ、それの姿を移ろいてでも見てみたいとした欲がもたげちゃっただけかもなあ


> すべての諸悪その名は「Bフレーム動きベクトル」‥(誤差が大きすぎて使えねぇクズ!)
> すべての問題を丸く収めてしまう2pass平均ビットレート方式
> だがしかし‥カラー優先度をはじめとした三点盛りを無用の長物へと葬り去る権化だった
↓/続きを読む/↓
posted by 木田舎滝ゆる里 at 20:51 | Comment(0) | 月下涙焉 | 更新情報をチェックする

2020年11月15日

【エンコード日記】行列係数と伝送特性を付けてるとBフレームが‥だった件

記稿.2020/11/15

> 可変ビットレート(0)にして、鮪丼に、よりビットレートが均等に割り振られる云々よりも
> 行列係数と伝送特性を付けていると
> 低いビットレートにおいては、Bフレームの割り当てが悪くなってしまうらしい


 ‥さらに
 それ以前の中身として、GOP(8)にしていると
 Pフレームの重み付けが解除されてオフの扱いになっていた

 つまり、すべてのPフレームが

 (設定によるIフレーム爆発から)何らかのIフレームを参照する状態に置かれているので
 重み付けをする必要が無いほどに想定内品質にあることから
 逆に、Bフレームとの品質差が大きいらしい

 (その理由としてか、Bフレーム側の重み付けは据えおかれているかのようでもある)
 (まぁ3枚有効だからだろう‥BDだって多くは2枚程度だからな‥)


 ‥またそれに関連してだろう
 Bフレーム無しにすると、GOP(8)から
 Pフレームの重み付けが解除されてしまう成り行きで
 想定外のIフレームの連続帯が生じてしまうものと思われる


 つまり


 Bフレームのマクロブロックをより細かくしては
 割り当てに因る品質差がより大きくなってしまうので
 I4x4、P4x4、B16x16の構成が、鮪丼としては具合が良いらしい
 (なにはともあれIP(1.4)、PB(1.3)の差はどうしようもない)

 結果的に、行列係数と伝送特性の指定は「無し」×可変ビットレート(1)で丁度良いぐらいっぽ


> いやぁもう‥はじめから全部確認のし直しです‥orz



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

2020年11月12日

【エンコード日記】インターレースの深淵に「K.O.」したった件

記稿.2020/11/12

> DVD4:3は、11250(ビットレート)でも頑強のようだが
> DVD16:9は、品質を90年代アニメに適うようにMAXに上げた結果
> テレビUSB挿しにおいて、インターレース縞の誤検知が発生してしまうらしい


 ‥つまり、今度は誤検知が起きない程度に
 MAXに上げた品質から下げる必要に迫られてしまった(ンゴ!!!)


 ‥例えば「獣の奏者エリンOP」では
 母と娘が手を繋いで歩いているシーンが、右側に小さくあったりするカットで
 インタレース解除が上手くできていないと思って、ちょいと逆サーチしてから再再生確認すると
 問題なく解除されている状態を繰り返す

 それと似たような箇所が他にもあり、タイトル全体で考えると悩ましい

 これは完全に誤検知が発生しているとしか思えないケースだろう


 ‥例えば「かなめもOP」では
 踊るタイトル文字表示の箇所から以降、タイミングずれが訂正しきらずにそのままになる

 AviUtlでコマ送りしてみたら
 激しいパンでカク付かないように
 なんとインターレース映像の二重撮りを含ませてあった(ンゴ)
 お陰で最大5枚連続のブレ駒が続いており、その前には4枚箇所がいくつか見られ
 完全にその影響からだろう‥タイミングずれが訂正しきらないままの状況に陥るらしい

 他にも普通に二枚連続の箇所にも、インターレースの二重盛りがされていたりしている
 タイトル全体で考えると卒倒しそうなこだわりを見せているようだ

 つまり是などは、完全に誤検知されないように品質を落とさなくてはならない


> DVDのタイトル毎にそんなこだわりを噛ましてあるんじゃないかと思うとうんざりだ
> (縦縞タイプのインターレースを見た事あるけど、これなんかどうなるんだろうね?)
> さらに悩ましいのがBDインターレースの場合だ


 DVDとBDとの差を嫌ったのかどうかまでは知らんが
 ここまでやって見せているとなるとそういう事だと思うのだが
 BT.601で読み込んで、なんちゃってBT.709をやらかしている1080iが存在していた

 フレッシュプリキュア!OPではまるで気が付かなかったが
 フレッシュプリキュア!EDでそれが発覚した

 (まさか‥OPとEDで違うのか‥組み合わせてあったりすると一発出しは完全にお手上げだ)

 つまり、なんちゃってなのでBT.709でも色がおかしくならないように
 平均ビットレートを下げている
 (他のBDインターレースと比べると平均ビットレートが低すぎる)
 (少ない割りにはどんなに盛り込んで再リップしようとソースより品質が良くならない)
 (なんちゃってBT709とインターレースに、エンコーダーが右往左往しているとしか思えない)
 (もはや解除してからエンコードするほか無い)


 ‥実際、同じことを1080p→16875(平均ビットレート)720pでやってみても
 ビットレートが規定とされる25000を下回っているので、ほぼ安定的だ
 (AviUtlからBT601を介してなんちゃってBT.709でも余裕らしい)

 ‥だが残念な事に
 テレビUSB挿しで発生するマムシ沙汰にコマ落ちソースのパターンは、挿してみるまで判らない
 そんときゃ、AviUtlからBMP介してut.videoにしてからエンコードするとマムシを退治できる

 とは云え、タイトル毎でBT.601からのなんちゃってBT.709にしてある場合もあるので
 プログレッシブだろうと、色が怪しいと思ったらそういうことだと思った方が良い


 ‥しかしそうなると
 AviUtlでの色をBt.601で読み込ませるべきかBt.709で読み込ませるべきか
 はたまたAviUtl独自のLWなんとかで読み込ませるべきかはソース次第ということになってくる


> なので、これなら一発楽勝ですとの案内はもはや無理ッ‥orz
> 自分でちゃんと色を比較確認してチェックしないとTIGEEってことになる


 (せっかくそろそろレシピにまとめられるかなと思っていたのに、空振りだった)



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