【エンコード日記】｛CRF：qpmin｝＝｛10：15｝の調査経過

記稿.2021/12/17

＞　｛CRF：qpmin｝＝10：15


　‥エンコードをしていて気がついたのは
　輪郭が妙にきついケースが目立つ点だった（とくに文字はくっきりしとしすぎる）

　だがこれは、１９型と２６型での比較になると、途端にどうでも良くなった
　（２６型ぐらいだと丁度良い）


　‥なんだかんだと、いろいろと値をいじったところ
　CRF値を下げるとファイル容量が膨らむ、qpmin値を上げるとファイル容量が縮む
　CRF値を下げるとくっきりする、qpmin値を上げると平板さが増す

　品質と量子化最小値の差を広げすぎると、テクスチャーがごそっと部分脱落する件が発生する
　品質と量子化最小値の差を狭めると、テクスチャーのパターンが濃くなる（ごちゃつく感じ）


＞　結論からして
＞｛CRF：qpmin｝＝10：15は、あなどりがたきバランスを得ていた


　‥量子化最小値が無視されているようでいて、考えられる要素としては
　CRF値を下げると割り当てビットレートが増える（規格想定からかなり下げている）
　その割り当て分が、多量なマクロブロックの割り当てに回ったことで
　不足分の品質を改善し（既定の倍）、さらに、量子化最小値の扱いに有り余る余地が起きていた
　結果、多量なマクロブロック間のバランスを得る為の平板さを逆に欠いていた
　‥つまり、デフォルトのqpmin（１０）は
　非量子化ソースでのレベル4.1のマクロブロック量を前提としていたのかも知れない
　（量子化されたソースでは複雑さが倍になり、必要とするｑｐ幅に変化が起きるのかも）


　‥ちなみに、輪郭がきつくなる改善案としてGOPの長さをいじってみたところ
　デフォルト値（２３）だと１９型では丁度良さげに見えても、２６型ではほどほどにボケて見えた
　（なかなかどうして、モニターのサイズ次第のところもある結果を得た）

　‥ちなみに、GOP（5）とGOP（23）の違いで、圧縮率の差が20％ぐらいに及んでいる
　だがしかし、テレビUSB挿しでのキュルキュル感はかえがたいのである
　（でもまぁ4ＧＢ超過ケースでの代替案としては、差し支えないだろう）


＞　さらに、2880×1620の一次ファイルのまま
＞　わさｂ抜き方式にて1080ｐサイズ・エンコードを行うと
＞　BDtsソースから直に720ｐをやらかしてきた内容想定を裏切らない
＞　（その場合には、レベル６を忘れずに）


　ちなみに、算出されるファイル容量は、BDtsとトントンてな感じっぽ
　Ｉフレーム増量で画質もテクスチャーもトントンなんだから
　2.25倍からやらかせば、Ｂフレームも安定して使えてさらに圧縮されるのだろう
　（これはある意味で発見だが、コスト面で無謀すぎ）

【エンコードレシピ】ＡＶＣ-Q（pro-720p最適化版）

↓12)記稿.2021/12/14

＞　まずは一次処理します


　‥BDts（1080ｐ）→　2880×1620、YUV444ファイル（ut.video）に置き換えます
　1280×720からすると2.25倍です。
　（Ｂフレーム劣化を防ぐのに720ｐへのダウンコンバートなら、2880×1620で十分なようです）

　‥ということは、1080ｐなら、4ｋ倍では足りていないかも知れません
　（4320×2430が狙い目という事になりますが‥やりたくねぇ‥）
　（ut.videoで対応していなかったり、メモリー不足だったりとありそうです）
　（一番に悩ましいのが、一次ファイル容量なのでかなり泣きが入ってきます）

1-12)1　一般

＞　↓より、二次処理時の設定になります


モード：変換
コーデック：MPEG-4 AVC/H.264
言語：なし
フレームレート：オリジナルを保持
カラーモード：YUV 4:2:0 Planar 12bpp‥（再リップならこれで攻めたい）

レート調整モード：品質１０‥（量子化圧縮と鎖動有り）

プロファイル：High
レベル：5.1（≒24フレーム用途）
　　　：5.2（≒30フレーム用途）

プリセット：標準
Tune：無効
フレーム-パッキング：なし
Open GOP：□
キーフレーム間隔：５‥（スローサーチ鎖動）
最小GOPサイズ：１
表示モード：プログレッシブ
スレッド：0
強制的に固定フレームレートのタイムスタンプを生成：オン
↓/続きを読む/↓

【エンコードレシピ】ＡＶＣ-Q（professional版）

↓12)記稿.2021/09/19

＞　まずは一次処理します
＞　BDts（1080ｐ）→　4ｋサイズにしつつ、YUV444ファイル（ut.video）に置き換える


　‥領域確保に、専用の空きドライブを用意する必要があります。
　（8000駒あたりで100GBを超えてきます）
　（映画版や、一話切れしてないtsにもなると、切るしかねぇ都合も‥）
　‥又、一次処理したファイルは、VLCプレイヤーでの再生ができません。
　なので、ごちゃ対策で、先にわかりやすい名前を付けておきましょう。

　‥一次処理したファイルの特徴として、YUVの要素を擬似的に補間しています。
　あくまで擬似的にありますが、そのように扱うべき特質まで復活するらしい‥

　（具体的には、CRF（10.0）に固定して、不足分に、MB-Treeを利用して追加する要領です）
　（qpmin（10.0）なのに、CRF値をそれ以上に下げるだけでは、効率が悪いと判断‥）
　（そこから先は、平均的に割り振るより、優先度を付けた方が細部の具合が良いと判断‥）


＞　基本的にBDtsの420のままにやっても、Ｂフレーム品質が劣化するので、狙った想定に及ばない
＞　そこで10ビットの444にしたりするわけだが‥（444では互換性に欠く）


　‥わざわざ４ｋ倍一次処理した方が、qcompの効きがまるで違う。
　（できあがる容量と品質には、雲泥の差がでる）

　‥マクロブロック単位で
　（0.0）エッジ感が遠のく←　qcomp（0.60）　→エッジ感が強く見える（1.0）
　割り当てられたブロックごとのビット内での処理に成るので
　平板ビットに不足があると、色みに違和感が発生しだしたりする。
　（色みが変わるほどなら全体的に、ビットレート不足且つQP値が高い）
　（いやんなシミのダマ感も、それのなれの果てだった草‥）
　逆に、平板の割り振りが飽和しすぎていても、動きの細部で部分的な違和感を発生させる。
　（単純に言えば、ボケ寄り感増し増しで動きやらかす）


＞　me_rangeの値を
＞　ダウンコンバート比に合わせていないと、根本的なピンボケをやらかしている
＞　ここを無視したり、忘れていると、qcompの効きからして‥その差を判断しがたくて詰まる


　‥正しくして、確認していくと
　qcomp値の値にコンマ桁を追加すればするほどに、全体的に不統一さを醸し出す。
　（ブロックごとで誤差が異なるらしく、傾がって見えたりする違和感に苛まれる）
　なので、qcomp（0.6）デフォルトにこだって、CRF値を微に変更した方がよさげっぽ‥

　つまり、10÷1.024＝9.765625
　CRF（10.0）×qcomp（0.57）からの
　CRF（9.765625）×qcomp（0.6）とした見立て‥

　‥これの差は、そもそものFHD420自体の減衰分の程度を意味する。
　なので、4ｋ444にて一次ファイルしようと、データ減衰分を織り込んでくる。
　なので、なんらかの処置を求める。
　（その割には‥4ｋサイズからのダウンコンバートなので、増分しがちな箇所も見られる）


＞　ちなみに、4Kサイズからダウンコンバートするにあたり
＞　レベル６における4x4マクロブロック量が、再生プレイヤーの許容を超えるらしく（格子落ち）
＞　レベル5.1もしくは5.2に下げざるを得ない（どこで発生するかなんて解ったもんじゃない）


　（裏を返せば、それの分の調整用途としても、MB-Tree＆qcompが復活した）

　‥なんだかんだと
　進行軸上にＩフレーム情報を確保していないMKVでは
　その都度、一度通しで、Ｉフレーム情報を読み込まなくては、クリックサーチが不適になった。

　そういう意味では、MP4へのコンテナをオススメする（MP4は、その分サイズを微に増す）
　（これは、MKVからMP4にコンテナし直しても駄目で、一次ファイルからの再リップのみ有効‥）
　（普通に視通すだけ＆倍速視目的なら、MKVでも支障は無い）

　（ちなみに、FLACの圧縮は、標準の５より４の方が音質面で安定的だと思う）
　（０ならwavと同じってか‥）
↓/続きを読む/↓

【WebP】JPEG420→16ビット増色化→PNG→の方が色保持性と圧縮率が高い

記稿.2021/08/10

＞　例えば、WebPの圧縮率を75％にロス設定すると
＞（但し、ソースデータ（解像度）が十分にある場合）


　JPEG420から直に圧縮すると65％程度ぐらいにしか縮まらないのに
　タイトル通りの手順を踏むと、95％程度の圧縮が想定になる（一例）


＞　仕様アプリ：WebPconv＆Corel PaintShop Pro


　これの要素を動画エンコードにも活用すると

　つまり、BDts420をその都度YUV444だししてから再エンコードすると
　わさｂ抜き420において、まとまりの良い画質を得られると同時に想定の容量を得る


　但し、これを調子こいて444Hi10で再エンコードやると
　サイズは縮めど違和感のある映像になってくる
　444Hi10でやるなら、普通の手順で十分にあるようだ

（動画エンコードと静止画エンコードでの補正特性は、そりゃ異なる）


　‥という感じなので
　アプコン、ダウンコンのパターンによっては、その都度の確認＆調整ありきでーす

【エンコード日記】x264（r3065）がGoodな件

記稿.2021/08/05

＞　Hi10の印象が従来と異なって改善されてるっぽ
＞　これは、可変ビットレート（100）でやらかしているせいだろうか？


　（といっても422が増量しがちなのは相変わらずなので、もっぱら444しか使わない‥）


＞　CRF（0）の挙動が改善されている‥（いつからかは知らん）
＞　以前は、subme=9までと制限されてたのが、subme=11のままでいける


　‥これらに引き込まれるかのように、Bフレームの挙動が改善されるっぽ
　partitions all指定でもしっかりしていて、テクスチャーレベルでも安定している
　（ mbtree（0）でも、劣化をやらかすようには見られない）

　だがしかし

　ソースによっては、わさｂ抜きの方が圧縮率が良かったりするんだからクレイジーだ
　それどころではない
　ＧＯＰを長くしても圧縮率が改善しないどころか、どんどん肥大化してしまったりする
　（どうにもそのような場合の多くは、Ｉフレームが増量気味にあるらしいが謎）
　（可変ビットレート（100）での平均が高く推移するのかも知れない）

　（まぁどうにも、CRF（0）指定にケチを付けても論外ではあるのだが‥）


＞　だがしかし、再エンコードであるがゆえに、ぶっ飛ぶテクスチャーはふっとびます
＞　それはまぁ‥qpmin（10）指定を否めないが、（0）にしても似たようなもんだろう
＞　あと、partitions allだし‥同じになんてなるわけもない


　‥ふっとぶ度合いに、一回り確実な改善が見られたお話でした
　（といってもファイル容量的に実用向けではありません）

　（ちなみに、me_rangeの最大値が、いつの間にやら1024に変更されている）


＞　とにもかくにも、シークバー挙動がおかしい
＞　倍速再生はほぼ４倍までイケてるので、やはりVLC側のなにかしらの制限に思われる
＞　（前回バージョンでは４４４が回らなかったりしているので‥まぁそれっぽ‥）

【再エンコード】bt709とbt601とでノウハウが違うらしい

記稿.2021/08/03

＞　JPEG画像をWebPに再圧縮する際、ソースが420非可逆だった場合は、色劣化をやらかす
＞　ということで可逆圧縮ソースJPEGに無いとWebpでも用を満たさないと言う点に疑問を持った


　‥ちなみにWebpのそれは、VP8機能を静止画に利用している
（420非可逆でも、色増化編集して444に見せかけてからWebP化すると、色劣化しない）

　つまり

　BDts映像をどんなに420→420でやっても、同じ色規格内解像度ならグデグデありきだ
　ところが、色規格を下げるとグデグデの程度が色規格程度に緩和されて良い塩梅に見えるらしい

　‥さらに、1024×576に変換する際のいろいろとしたノウハウのまま
　720ｐ＆1080ｐに取り組んでみても
　動きの関係から間引きされる箇所は、決まって間引きされてしまう


　‥この二つの傾向から察するに、同じ色規格内での解像度の場合（再エンコード時）
　444でやらざるを得ず、さらには10ビット化を要求するくさい
　そうしないと、同じ色規格内での解像度再エンコードは、細かいところ程激しく異なってくる


＞　とくに可変ビットレート値は、ピクセルが増えていることから
＞　（89）では間に合っていないらしく、（100）でやるのが良いらしい


　‥もっとも（100）になると
　（1）と分解の割合が100等分で、計算値に大きな差が無いので見た目の印象はさほど変わらない

　‥それよりも、CRF値の多すぎ少なすぎの方の影響が大きい
　くしくも、同じように間引かれてどうしようもないとしたポイントが適切らしく
　それは、1024×576でのノウハウと同質にあるようだ

　つまり、1920×1080（24フレーム）なら
　10÷1.024＝9.765625
　1280×720（24フレーム）なら
　10÷1.024÷1.5＝6.5104166‥

（確認しておくと、こんなことになっているのもqpmin（10）×CRFにあるからだ）


＞　それにしても多少重いらしく
＞　断片化してるとシーク感覚でグデグデやらかす（エンコ後のデフラグ必須）
＞　デフラグしてダメならスペック不足（AVC-Qの甲斐がねぇ）‥VLCの444時仕様くさいかと‥


　それにしても色が濃ゆい、つまりこれがBT.709だったということか‥
　やっぱ、こっから先は、大画面に無いと1080サイズ確認に意味ねぇってか‥

【エンコード日記】自動フィールドシフトに潜む大きな勘違い

記稿.2021/06/30

＞　24ｐを120ｐにしてから30ｐを誰も試してはいない
＞　なのに、30ｉを120ｐにしてからの24ｐ化をうまく行くと思う目指し方は不可解しい


　‥前者がうまくいかないなら、後者もうまくいくわけがない
　‥仮に前者がうまくいかないとしたら、それは脳が受け付けない何かがあるからかも知れない
　‥若しくは、その誤差を手作業で修復しなければならない

　‥後者に満足できないとしたら、この誤差に対する感覚は釣り合っていて等しい
　‥後者に満足できるとしたら、前者にも満足たり得る条件をクリアーできてるに等しい


＞　‥今更ながらに気がついてしまいましたん

【エンコード日記】Bob化を調査しておこうとなりまして

記稿.2021/06/28

＞　インターレース概念の核、フィールド
＞　今ひとつよく解らないところがあるのだが


　‥それは、１枚目と最後にはフィールドが存在しないというかそんな感じなのだが
　そうするとBob化する場合に困ることにならないのだろうか？
　（まぁ最初と最後ぐらいやっつけありきは仕方がない要素だろうけど）


　‥そもそも２枚目、３枚目とした感覚で取り扱わないから
　フィールドなる呼称が付いているわけだが（実に不思議な感覚だ）
　半分ずつに分かれた画像をそれぞれが２つずつ持っている

　素直に一枚分でないのがインターレースであって
　実際的には、一枚分のデータを持っているに等しいのに一枚では無い（実に不思議な感覚だ）


　‥これを借金と経営に例えると
　現金と手形で運用されているのがインターレースで
　現金と支払期限だけで運用するのがプログレッシブに相当する

　手形の多くが、私の支払い責任ではないとした印象がどうにもブレ駒評くさい‥

　されど、経営の本質とした現金とて、その多くは、売上見込みの金額でしかないので
　そこはなんというか‥エンコード特有の予測された情報群とした意味合いそのものだ


＞　そんなよくわからないインターレースから二枚半分ずつの情報を補正すると
＞　コマ数があれよあれよと二倍に増幅するとした辻褄が発生するアイデアをBob化と呼ぶ


　‥この駒数二倍化の結果
　24駒を2-3プルダウンで30駒に増やしてあるタイプに限り、忠実に一枚一枚に分離できる
　実写の場合は、とくにデジタルのインターレースでの撮影などの場合は
　うまい具合にそういう風になるとは限らない
　（露光タイミングの異なる半分ずつを持ち合わせてもピッタリさせるには補正ありきだ）
　（そもそもタイミングが違うから動きに対して追随性が高まるのだから）
　（其をないがしろにした補正はありえない、その点、2-3プルダウン式はそこまで考える用が無い）


　‥ということで、やってみたところ、その通りを得た
　但し、アプコン×ノンレス444での解除が一番の品質になる
　（エンコードしながらの解除なんざ、どうにも半端な結果にしかならない）


＞　コマ数が増えるので、一次処理ファイルの肥大化は、当然に半端ない
＞　ざっと、DVDアニメ４話分まとめてなら‥1.3TBの空きを確保しておく必要がある
＞　BDのインターレースなら、4ｋ倍化してなんぼなので‥一話あたりで1.3TBということになる


　‥単にブレ駒とおさらばしたいと言うだけのことをやらかすのに
　それだけの手間と機材の確保が欠かせなくなる

　そして何よりも悩ましいのが、4GBに収まらないと来たもんだ

　59.94フレーム化してのエンコードは
　単純に1.5倍に膨れあがるので、720×480ｐ（1.363636比）でやるしかない
　さらに、4：3のみの限定というのが今のところの算段になる
　ちなみにCRFは、解像度とフレーム数からの比率分を織り込んで（3.5555555）で良いらしい

　（こんなんやるのか？‥気持ちはあってもやり切れるもんじゃねぇ‥）

【エンコードレシピ】DVD二度丸煮だし濃コク増し増し光の澄みきりスープ（480i→1080p→576p）

↓15)記稿.2021/06/27

＞　DVD480iを、品質基準VBR（CRF）の置き換えに悶絶!!!
＞　量子化最小値（10）なんてやらかしてるとメタボにしかならない


　‥無駄にCRF値を低くしても色が際立って来ない珍問答を彷徨うこと
　内部4：3でCRF（6.0）
　内部16：9でCRF（4.5）としたあたりを得たのだが、どうにも格子がおかしい

　中身がスカスカってな感じでM.E.範囲を確認してみるに
　スカ←（18）→ボケとした見立てになるも納得できない


　‥そこから、品質基準での480iを投げ
　次に、704×576ｐとした変則規格を試してみたところ
　M.E.範囲（20）で良好になる次第を確認

　だがしかし、内部4：3でCRF（6.6666666）にて
　DVDアルプスの少女ハイジのEDテロップ文字がボケまくりで惨敗‥orz
（それはつまり、所々のパンでカク付くっぽさをまだ改善できるとのサイン）


　‥ビットレートをケチった704×576ｐをやらかすのは
　どうにもダメっぽいので、是も投げ

　DVDの端を切っての‥1024×576ｐと768×576ｐに切り替え（ｉ解除プラグイン利用）
　CRF値をどうするかで悩むも
　照りトロexplosionでの値に、フレームレート増分を織り込ませれば良さげ‥

　さらに、全部盛り計算してやっちゃえば、内部4：3での左右のフレーム揺れに悩まずに済む
　さらに、1024×576ｐに統一しちゃえば手違いも減る‥（全部盛り決定）


＞　結局、丸々と太らせるしかねぇオチでどうもすんません‥m(_ _)m
＞　（もはや‥DVDアプコン（576ｐ）≒BDダウンコン（576ｐ）の域に近くなってます）


　全部盛りなので、一次処理を解除ノンレス・アプコン1080ｐにてUt.video[444]（mkv）で行い
　それを今度は、16：9の576ｐに統一して、ダウンコンバートします
　（※使用するアプリは、XMedia Recode一本です）
↓/続きを読む/↓

【エンコード日記】DVDを全部盛りするにはアスペクト比の変更が欠かせない

記稿.2021/06/26

＞　いろいろとやっていて漸くに気がつきました


　‥720×480ｉを704×480ｉにせずとも
　アスペクト比を変えてやるだけで、全部盛りになる


　これを逆から問うと
　多くのＤＶＤの比率の方が間違っている（内部4：3）

　720×480（内部4：3）の場合、オリジナルの多くが1.333333
　これは、704×480（内部4：3）であれば問題ないのですが
　720×480（内部4：3）の場合は問答無用で全部表示されてしまうのだから
　アスペクト比（1.363636）としないと正しい比率になりません。


＞　1440：704＝ｘ：720　を解くと、ｘ＝1472.727272‥
＞　並びに、1472.727272‥÷1080＝1.363636‥
＞　つまりこれに等比にあるわけです


　↑にならって、720×480（内部16：9）の場合は↓


＞　1920：704＝ｘ：720　を解くと、ｘ＝1963.636363‥
＞　並びに、1963.636363‥÷1080＝1.818181‥
＞　つまりこれの等比であるのだから、アスペクト比（1.818181）→切り上げで（1.818182）


　但しこの場合、上下（縦）が縮みます
　で、オリジナルの多くが1.777777なので、普通に再生すると
　比率が違ってしまう‥なおざりだった（痛ァァアア）


　（でもまぁテレビＵＳＢ挿しで上下が縮むかは怪しいのですが‥）