【エンコード日記】ＤＶＤソース側のＧＯＰ構造でやらかせる再リップの都合と許容が変わる

記稿.2021/05/19

＞　まず、DVD内部16：9のM.E.範囲を（30）で確認しています
＞　という感じで誤差の度合いを疑うところからやり直しているのですが


　TFFが長く続くソースや
　何やらシーン毎に区切って
　openGOPでエンコードだししたモノを繋げてあるソースの場合などには
　GOP（６）ref（１）が都合良かったりの一面も見られるのですが

　ref（１）のような極端な場合
　DVDの標準的なM３N15とした３枚倍数構成には無理発生し
　例えば、テロップ文字の隙間を拾えきれないとしたエラーが出たりとします
　（内部的にも、どんな形と形の間の隙間落ちが発生しているかも知れない事を思うと）
　（スローサーチよりな構成はバイアスって事であきらめざるを得ません）


＞　ちなみに、DVD内部16：9に対してM.E.範囲（30）を用いると
＞　輪郭の間が二重になってるくささが薄れる代わりに
＞　全体が一回り丸くなったというか濃くなったというか‥かような変化を感じます


　‥それが正解なのかどうかは、まだ判定できていません
　まぁ基本的に、内部１６：９の４８０ｉをＦＨＤサイズに拡大する比率として
　動き判定誤差の小さいのは、（２０）か（３０）のどちらかの判断になってます

　細かく計算すると誤差を丸めて横幅寄りの（２４）‥程度になる感じに思うのですが‥
　やってみるとカク付くんで没になってます
　（ちなみに、７０４×４８０云々は織り込んでいません）

（テレビUSB挿しなら、挿しさえすれば自動認識するに違いないと思っているのと）
（テレビをモニターに使ってるって事は（HDMI）、パソコン用モニター解像度比とは違うので）
（それでなくてもHDテレビの場合、疑似解像度なので、テレビの比率で考えて良いのでは？）
（‥と思い立っているからです）
（‥テキスト書きの文字からして、きちんとした解像度では無く潰れちまってますんで‥）
（この状況を鵜呑みにしたままに、704信者に奔るのもどうかと‥）

【エンコード日記】ようやく片づくDVDアニメ？（AVC-Q：480i保持パターン）

↓3)記稿.2021/05/18

＞　自動フィールドシフトがDVDアニメで敗北したので
＞　XMedia Recodeでの一発だし（480i保持）を余儀なくされました‥orz


　‥ビットレート値をどうするか？（増量なんか有り得ないッ）
　‥カク付き問題をどうするか？
（複数アプリを跨がずに、この二体怪獣をどうにかしなくてはなりません）

　まず、ビットレートですが
　AVC-Qとした意味合い上、ビットレート値の候補として真っ先に挙がるのが
　720×480÷256×30÷5＝8100‥です
（まずはこれで試していきましょう）
（※インターレースなので、÷1.024云々無しでエッジ強化するのが良いようです）


　‥次にカク付きですが
　720×480という3：2の比率の中に16：9やら4：3とした比率の映像を詰め込んである都合から
　展開マクロブロック比を織り込んでいないと、M.E.範囲で誤差を拾ってしまうと云うグデグデを
　どうにかするための最適値を見つける方法として
　GOP（30）ref（15）にて繰り返しやってみることにしました

　長めのGOPと多めの参照枚数による実験だしは、M.E.範囲の正確さを示す上での耐久レースです
（※以前に紹介した59.94フレーム化は無意味だった判定に至ってます‥すんませんm(_ _)m）


＞　M.E.範囲（20）‥DVD内部16：9比
＞　M.E.範囲（18）‥DVD内部4：3比


　‥とした結果になりました（拾われずに悩ましかった色が拾えていたりと留意下がったりっす）
　‥で、戻りましてビットレートの調整です


10125：DVDりっぷプラセボMAX（大画面での見映え期待向け‥対応するかは知らん）
10125＝3^4,5^2（DVD16ｘ16ブロック数（1350）の30枚÷4）（20250の2分の1）

8100：ほぼ正確にトレース？
8100＝2^2,3^4,5^2（10125の0.8倍＝16ｘ16ブロック数（1350）の30枚÷5）

7200：シミ抜き職人の才あり◎
7200＝2^5,3^2,5^2（7200×1.125＝8100）

6075：満足度の端境？（AVC-Qでのｉ減量効果期待ってこれぐらいで目一杯？）
6075＝3^5,5^2（6075×1.333333‥＝8100）

5625：光効果やらの表現でインパクト不足
（テレビUSB挿しによる減発色は明らかで、これより下げてもAVC-Qでは品質を満たさない）
5625＝3^2,5^4（16875の3分の1）
↓/続きを読む/↓

【エンコード日記】DVDアニメの再エンコードでカク付く根本原因が判明

記稿.2021/05/17

＞　即決で論を語ると


　720×480という3：2の比率の中に
　16：9やら4：3とした比率の映像を詰め込むと
　M.E.範囲の設定比が正方形に固定されているので
　縦解像度に合わせば、横解像度で誤差を広い
　横解像度に合わせれば、縦解像度で誤差を拾ってしまうと云う
　M.E.範囲の設定比を縦と横で可変にできない仕様からの不都合だった

　これは、デジタル放送でも同じで
　16：9のはずが4：3だったりするのも
　再エンコードが上手く行かない理由の一つと言う事になります

　これではまるで、技術陣のしてやったりの確信犯
　もといプロテクト要素扱いだったのではと思わざるを得ませんね
　（そこまで自信を持ってやっていたとも思えませんが）
　（４ｋにする段階で録画をごねたのは、中には心得のあった技術者も居たのでしょう）
　（とするなら、ＨＤＲなんてのは目線の先をすり替えるための新たなプロテクト要素だったりかも）

　つまり

　‥展開拡大させる時の正しい比率データの位置をきちんと拾えていないと、カク付くんですわ
　‥展開拡大させる時の正しい比率データの位置をきちんと拾えていないと、カク付くんですわ


＞　でも、自動フィールドシフトあるから大丈夫なんでしょ？
＞　‥それがその、DVDアニメにおいてはどうにも
＞　自動フィールドシフト破れたり‥状態にハマっちまいました‥


　‥とにかくおかしいのが
　アニメのDVDをAviUtlで読み込む段階で
　フレームレートが狂うパターンがあるという事です

　可変フレームレートと断ってあれば、解りもしますが、無い場合はちんぷんかんぷんです

　‥で、それのもたらすエラーが音ずれです
　その音ずれがまた異常で、途中で回復を見せたりするという厄介者でして

　つまり、どうにも‥
　自動フィールドシフトのタイミング割りが、音声を直に参考にできない事から生ずる
　タイミングずれらしい

　‥繰り返しますが
　これは、音がずれているのでは無く
　フィールドシフト側のフレームレート可変要素の対処が不十分に因るものだと思われます

　（これの音ずれは、読み込み時のフレームレートを変えても同じでどうにもならないようです）


＞　そこで、インターレース解除をあきらめ
＞　3：2のそのまんまでやらかす事にせざるを得なくなりましたん‥orz


（自動フィールドシフトで音ずれしないインターレースタイプの場合は、問題ありません）

【エンコード日記】4ｋ倍自動フィールドシフト×Ut.video（444）での課題点

記稿.2021/05/13

＞　‥昭和テレビドラマ（実写45分物）のm2tsを自動フィールドシフトしてみたら
＞　309GB（44分45秒）に達した上に
＞　容量制限なのかどうか知らんが、音声を含まないファイルとして作成された


　‥２時間以上のインターレース実写映像なら、どうなるかなんてまるでわからない
　（一分当たり6.9GBになるなら、120分なら828GB予想だ）
　（そんなん出して、断片化解消したりしたら一日作業で、エンコードを含めるとさらに二日かも‥）


　‥それでいて
　実写にもなると品質劣化の程度がハッキリ示されて、前もって覚悟しておかないと愕然とする

　例えるなら、ＨＤにダウンコンバート（AVC-Q）した印象で
　ビデオテープの上書き２〜３回目程度かなっと‥（発色）
　（ビットレート配分を（89）にしてあるので、それによる程度差かもしれない）
　（特定の場面で多少気になる箇所がでるかもしれないが、バランスは申し分ないはずである）


（これは、帯域限度ビットレート程度に追加したところで、エッジ強化には至らない‥むしろ斑‥）
（帯域限度比から削ってある微差を考えるに、ＦＨＤにすれば多少マシになるかも知れないが）
（ＦＨＤについては、対象モニターが無いので正確には語れません）
（というよりエンコード時間が1.5倍程度に増えるので、作業全体の時間を考えると悩ましい）


　‥ということなので
　長時間物インターレースを４ｋ倍自動フィールドシフトするなら
　分断作業して、最終工程にエンコードしたそれらを繋げる作業を検討する案もありきでしょう


＞　一次4ｋ倍からの置き換えにする事でのメリットは
＞　昭和実写モノにありがちな、手書き風スタッフ名なんちゃらが変になる現象を無くせるのと
＞　ギザエッジのどうしようもない残り箇所を、ケースバイケースで緩和してくれる点です


　‥あと、インターレースによるせいで判りづらい激しい動きでの遠近の掴みがスッキリします
　（車の正面から見えてるフロントガラス越し×車内×バックガラス越しに動いてる風景やら‥）
　（電車の車窓から見える風景の手前から遠方の動きや輪郭やらが‥まったく別物になります）
　（ダウンコンバートによるつぶれが無いとした意味ですが‥）


　‥これはインターレースのままの発色を維持するべきか
　その辺のトラブルを解消してまでプログレッシブに起こして視聴したいかの差でしょう

　（24フレーム化にまで耐えられるかは不明）
　（24フレーム化の際に他のシーンで、欠損的にガク付く可能性があるのでオススメしない）
　（そんなん確認までしないとならんのは、作業用ＨＤＤの都合を考えると無理ッ）

【エンコード日記】ｉ解除一次処理4ｋをRGB出ししてからダウンコンバートしたら‥

記稿.2021/05/11

＞　4ｋ→1080ｐでは、色みになんら変化無し
＞　4ｋ→720ｐとすると、色が濃くなる向きで変化有り


　‥ん？どういうこと
　これは480ｉ→ｉ解除一次処理4ｋ出しにおいても同様だ
　カラー優先度を追加したって変化無し

　‥以前に4ｋ白黒映像を720ｐ化やってみた際は
　階調つぶれが発生して、見てくれがおかしくなったのだが
　やはりそれと同様になるに変わりは無いということか？


　720ｐにする前提なら、422だしすべきで
　1080ｐにするなら、ＲＧＢでも問題なしと理解せざるを得ないが腑に落ちない


　ＲＧＢには明度情報が直に無いのでこういうざまになる
　ならば同じに見えてる1080ｐだって、それの明度情報からして怪しいと疑うべきだが
　その差を確認できないのはＨＤモニターだからだろうか？
　それにしたって４ｋ倍で静止画比較して、同じ色みに見えるんだったら問題ないだろう
　（それとも、やはり違うのか？）


　‥そこで試しに７２０ｘ４８０にまでダウンコンバートして出してみた
　で、それぞれを再生比べしてみると
　そしたら、１０８０ｐの色みは、概ね同じだけど特定系で違っていた
　その特定系が７２０ｐではさらに特化されて広がりを見せているらしい
　だがなぜか、７２０ｘ４８０になると色みが復活しているらしき不思議にかち合ってしまった
　（これまたどういうこと？）


　‥ついでなので、一次出しを４４４でも出してみたところ
　以前と違ってきちんとエンコードされてて、さらに
　720ｐの4ｋ倍拡大比較でもエッジ負けしていない（こんなに違うのかよ）


＞　ということらしいので、一次出し４４４でやらかす事にするっす‥


　‥でもこれってつまり
　ちゃんとした明度情報が受け渡されない処理で
　AviUtl 大好きで一括だったりすると、なんちゃってYUVになってそうだな

　ソースが自作で量子化させてないデータの扱いでも
　最終処理で一旦４４４で出して再読み込みしないとダメなんちゃう？？

【エンコード日記】どうにも「16875」が絶対無敵だった件

記稿.2021/05/10

＞　BDts1080ｐ→720ｐ再エンコードにおいて
＞　ビットレート（16875）はどうにも絶対無敵でした


　‥可変ビットレート（89）を得た事で、それはさらに最強になってましたん
　（なんか無駄に他値でエンコード出ししちまったのが時間勿体なかったかなと‥orz）


　‥なぜ、どうして‥HDサイズ変換時にビットレート（16875）とした時だけ
　99％の率でシミが消失してしまうのか？（頑固なシミはケースバイケースでちっぱく存在します）


　‥（÷_5）値である17280÷1.024＝16875なので
　これをFHDの24フレームでの算出期待値とするなら
　39168÷1.024＝38250になりますが

　それぞれの因数分解で比較すると
　16875＝3x3x3x5x5x5x5
　38250＝2x3x3x5x5x5x7
　ということで、Ａ×Ｂ×Ｂ×ＣC×ＣCとした形とは大分違ってきます
　（‥でもまぁ、癖の出にくい算出期待値としては確かなようです‥）


＞　巷に転がるHEVC-Mp10＆Bフレーム増し増し映像の場合には
＞　どうにもシミ除去ほどの効果までを見込めない事から
＞　ｉ解除時に16ビットに置き換えてやらかすのを怪しく思い、8ビットに戻してやり直したところ


　‥線と線の境界というか
　ものの形の輪郭を算定して、そこの境をぼかしすぎないようにする器用さが伴わない事から
　境界とする線の間に中間色が混ざっていたりすると
　途端に輪郭を見失ったかのように、ボケ感増し増しだった‥
　（AviUtlでの読み込み時16ビット変換利用は使えんということです）
　（又JPEGノイズ分の飛ばしすぎが気に入らないと思ったら、読み込み選択支は８ビットのみです）

　‥で、XMedia RecodeでRGB出しのut.videoファイルの扱いですが
　以前に対応してなかったと記憶してたのに、対応してたので、今後はRGB出しで行きます
　（確認すると‥やっぱりRGBにこだわりゃよかった‥なんてこったい）


　‥ちなみに、DVDやBDのソースファイルをRGB設定で読み込んではいけません
　１０ビットは１０ビットで、８ビットは８ビットで、YUVはYUY2で、サイズは同サイズで
　（L-SMASHの設定を起動前にやらかせないのは手間ですが、忘れずに）
（面倒くさいと思ったら、設定毎に違うAviUtlフォルダーを設けて使うのが利便です）
（フォルダー毎の設定違いもまた手間ですが、戻し忘れのお陰で違いに気がつく結果にも繋がると‥）


＞　‥まず30フレームの場合は
＞　サーチ時の動きを的確に捉えるために、GOP（6）ref（5）を用いるので
＞　その辺で違ってきているように思われます‥そこで‥


　24÷5＝4.8、30÷6＝5、4.8÷5＝0.96
　算出期待値から×0.96分ビットレートを落とすぐらいが丁度良いのでは？
　（わさＢ抜き時の全ＰフレームがＩフレームをきちんと参照する前提なら）
　（シーン変更感度（40）のデフォルト値では、そんな器用をやりませんが）
　（（89）の値なら、設定如何で器用にやらかすようです）
　（その分フレーム枚数が多かろうと、ＧＯＰが伸びる分相殺されるものと考えられるのです）

　‥すると
　21600÷1.024×0.96＝20250（2x3x3x3x3x5x5x5）
　48960÷1.024×0.96＝45900（2x2x3x3x3x5x5x17）で出す事になります


　‥こちらでは、1080pでの正しい視認を確認できないので
　HDモニターとの差を推し量りかねますが
　ソース比較による‥エッジの強すぎるのと、パンチの弱くなる傾向ぐらいは同じでしょうから
　理屈で攻めて揃えていくと、その辺りが同じ具合の程度に成るのかなあと思うところです

　（というかこれでダメなら万歳するしかねぇっす‥）

【エンコード日記】割り切れる数値で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でのＡＱを（1.08）に設定したものが21600に等し
　19200でのＡＱを（1.125）に設定したものが21600に等し
　それを逆にすると
　21600でのＡＱを（0.9259259259259259‥）に設定したものが20000に等し
　21600でのＡＱを（0.888888888888888‥）に設定したものが19200に等し
　20000でのＡＱを（0.96）に設定したものが19200に等し


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


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


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

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


＞　だがしかし、これがＦＨＤモニターとＨＤモニターの差かもしれないことを
＞　こちらでは確認できないのであしからず
＞（だってそれぐらいの差でしかないなら、ハード対応で吸収するしないの世界でしょ）

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

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

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

---

＞　７２０×４８０（DVD規格のサイズ）
＞　７０４×４８０（実際の有効表示面積）


　‥という意図不明な規格になっている
　なので、４８０ｉ＆４８０ｐを４ｋ倍に一次処理するにしろ
　規格面積フル利用　ｏｒ　有効表示面積‥とした選択を迫られる


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


　７２０÷７０４＝1.022727272727273
　７２０×1.022727272727273＝736.3636363636364
　７２０×1.125÷1.1＝736.3636363636364

　７２０÷１６＝４５
　７０４÷１６＝４４

　４５÷４４＝1.022727272727273
　９÷８÷1.1＝1.022727272727273

　88×1.125÷1.1＝99÷1.1＝90
　＿＿８８　＿＿９９　＿＿９０‥（横１６のマクロブロック数）
　＿１７６　＿１９８　＿１８０‥（二倍した横１６のマクロブロック数）
　２８１６　３１６８　２８８０‥（求めるべきピクセルサイズ）


＞　つまり、７４０→２８８０とは
＞　規格面積フル利用時の最大横幅736.3636363636364→３１６８を切り捨てずに
＞　有効表示面積７０４→２８１６を含めて保持した状態を意味する


　‥尚、この状態は正しい４：３比率では無い
　３２＋２８１６＋３２とした内部構造になっている

　なので、これを正しい表示有効面積に引き延ばして
　さらに、１６：９に換算した黒帯を付けるとすれば
　３８４０−２８８０＝９６０
　９６０÷２＝３３０
　３３０−３２＝２９８（左右）となる


＞　アナログ式４：３映像の場合は、切り捨てずに左右黒帯の横幅を減らすだけで済むわけだが
＞　デジタル式１６：９映像の場合は、切り捨てるか、上下黒帯を設けるかの二択になる


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

　‥なので、すべて内包する方が無難に思われるにせよ
　その正否は不明である事を許容しなければならない
　（嫌なら‥そのまんま７２０×４８０に戻して３：２である云々を許容する選択になる）


　‥まず、有効面積である２８１６を元に１６：９を求めると
　２８１６×１５８４を得る
　‥なので
　求められる横解像度は、２８８０→引き延ばし３８４０

　求められる縦解像度は、２１６０→１５８４（縮小）＋２８８（上下黒帯）
　横解像度の広がり比が1.333333‥倍になるので
　１５８４にもそれを掛けてやると２１１２が得られる
　２１６０→２１１２＋２４（上下黒帯）‥とした形になる

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



＞　‥エぇぇえ☆★‥
＞　上下２８８の黒帯って、マジっすか？？


　‥そんなんシネスコサイズみたいなの
　‥ＢＤ版とは又違ったバージョンの派生同然じゃねぇっすか
　（ちなみに、ＨＤサイズなら９６（上下黒帯）、ＦＨＤサイズなら１４４（上下黒帯）になる）

　（‥別の意味で無駄に興味がわいちゃうｚ‥）

【エンコードレシピ】進撃のＡＶＣ-Ｑ規格（HDサイズ推奨）

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

＞　ｉ一次処理４ｋ時、M.E. 範囲（３２）を書き忘れてました

---

＞　ＡＶＣ-Ｑ規格の「Ｑ」とは、サーチキュルキュルの意でーす
＞　まずは個々でエンコードだしやってみようの段階でーす（あしからず）


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

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

　1920×1088÷256＝8160
　8160（16ｘ16）,32640（8ｘ8）,130560（4ｘ4）

　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

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


　‥それでもこれの不満をＡＱを弄って調整しようと試みるなら
　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（16ｘ16）,14400（8ｘ8）,57600（4ｘ4）

　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）
↓/続きを読む/↓

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

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

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

---

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


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

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

　つまり

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

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


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


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

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


＞　では、まずは必要最低限度の調達です（もとい、お借り致します。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ソース　→　３２ビット×３０７２Kbps‥とした見たことない高ビットレート出力になる
　（うれしいような‥うれしくないような‥）

（そのままは無理だし、さらに変換しては野暮なので、やはりコピペでしょう）
↓/続きを読む/↓