【テレビUSB挿し】4GBまでしか回せない件 & Ｂフレームとマクロブロックの件

↓1)記稿.2020/05/05

＞　4ＧＢ超えの２５分ものアニメ‥テレビＵＳＢサーチ途中で落ちましたん‥OTL


　‥そういえば、そんなのあったっけ
　‥テレビ録画からして最長録画時間に制限が有るっすから（有って当然、永遠に変わらぬ苦闘）
　‥映画ものを美麗キュルキュルサーチは‥はじめから無理だった（なんてこったい）

　（思えば、以前にギリで４GB超えしてたシンゴジラ‥スタッフロールで落ちていた気がする）
　（たまたまのタイミングのせいで、気にしなくて良いなどと思い込んじまってたｚ）


　‥ということで
　25分ものないし45分ものに関しては
　サーチキュルキュルを維持しつつ、画質において妥協点を模索する羽目になりました

　つまり、５４０ｐのBT709→BT601を受け入れざるを得ません

　‥やらかしてみると、結構色々とした発見があって
　それはそれで有りなのだろうと思い始めた‥にしても
　Ｂフレームが長くなることの確実なデメリットを理解してしまったん


＞　ＢＤレベル4.1の段階で、16ｘ16のマクロブロックを中核とした構成だ
＞　つまり、ＢＤにおいてＩ＆Ｐフレームだけが８ｘ８を新しく割り当てされる程度だった


　Ｂ８ｘ８も使えるとしても、マクロブロック制限から見れば明らかに厳しく
　Ｉ＆Ｐフレームで使用していた場合の、ほぼコピー用途扱いでしかないと理解した方が良い

　‥具体的には
　１〜２枚程度ならＢフレームの領域をＢフレームで書き換えても
　それほど瞬間的には８ｘ８のブロックが崩れることは無い
　しかし、３枚以上になると確実に該当域全部をＢフレームが書き換えるだろう

　その時、Ｂフレームに新しく割り当てできるマクロブロック枠はほぼ不足がちである
　なので、より１６ｘ１６のみでの構成だ
　そこにさらに、割り当てられるビットレートが不足すれば
　その区間のＢフレームの品質は、どうしたって劣化の道を歩まざるを得ない
　それのよくわかるのがパン映像である

　（それが、映像中にパンが多いと悩ましいことになる理由だ）


＞　それから、deblockである


　‥Ｂフレームの連続枚数を伸ばすほどに劣化するわけではないにしても
　動きの激しい箇所では確実に劣化せざるを得ない
　なのでマクロブロックの不足を欠いたままに、レベル4.0なんてありえない

　なのに大抵は、レベル4.0辺りが圧縮する上でのポピュラーらしく
　さらに、deblockをマイナスに寄せるのが通例手法として見られる

　‥だが、それでやらかしていることとは
　Ｂフレームの連続（距離絡み）にてまず間引きをし
　間引きされすぎを‥回復させる為の復活としてdeblockをマイナスに寄せているわけである

　‥そして

　そこそこのビットレート量で仕上げようってのが、圧縮前提でのそれらの流れだ
　単に、線の細い画が好きなだけ脳の延長線のまんまでしかない

　（そんな劣化慣れで４ｋ８ｋ言ってんじゃねぇよ）

　‥どうして単純に同じ解像度のままに
　塗り絵の塗り具合の度合いを薄めるだけの発想なんだよ
　そんなの漆塗りの労力と比べたら杜撰すぎの文化色だっちゅうの
　過去の伝統美からすれば、到底足もとに及ぶことなきダメダメの視界っすから

　（そんなダメの日用文化に満足する民族に、その先の映像美理解なんざやって来るわけが無いん）
　（もっと、動きの忠実性に貪欲になるべきっすからッ）
↓/続きを読む/↓

【エンコード日記】テクスチャ剥がれに悶絶してしまう件

記稿.2020/05/03

＞　紅伝説にて、こめっこ登場場面での格子ガラス戸越しシーン
＞　ガラス越しの人影がこめっこで、引き戸の玄関を開けようとしているわけだが
＞　格子ガラス戸と人影の言わば二重取り表現と言えるわけだが


　‥初動で動いているのは人影の方なので
　格子ガラス戸表現のガラス戸の色をテクスチャと呼称するなら
　テクスチャを前側にて重ねつつ、人影を割合比較的くっきりと見せる表現なのだが
　是を高いCRF値で動画エンコードすると、途端に、剥がれ落ちてしまうのである。

　つまり、窓ガラスに見えるように、テクスチャを保てないようでは失敗の扱いだ。

　それでなくても、格子枠の木目が先に剥がれ落ちてしまうってんだから厄介だ。
　是に対処すべく、大ざっぱにも、CRF(10.0)×qcomp(0.9)×deblock=1:1:1を盛ってみた。

　（テクスチャの正確さ配慮としてのデブロック値の差はかなり大きい‥認識が覆った‥）
　（但し、1080ｐにて出してみて比べると、そこまで大きく影響する程には思えない）


＞　で、そのCRF(10.0)×qcomp(0.9)×deblock=1:1:1なのだが


　灰みで構成された絵面において（アニメ）
　時折、気のせいほどの差が出るか出ないか程度の差が見られるのだ。
　静止画拡大比較で確認してみても、気のせい扱いの誤差の範囲でしかなく
　暗め場面でのパターンなだけに、よくよく見ると違いがあるといえばどうにか得られる程度だ。

　「これだけの差が、ここだけこんなに違って見えるのか」と逆に驚く。

　‥どうにも失敗と判定せざるを得ず‥それでなくても、容量が息苦しい。

　容量的に比較的圧縮の効くアニメで、25分もの音声込みで2.5ＧＢが目安になる。
　それだけならまだ許容しても良いだろう。
　だが、それなりに複雑な演出が組み合わさってくると、無残にもソース超えの容量と化する。

　（ちゃぶ台をひっくり返したくなるオチである）


＞　そこで、もう少しより細かいところまで比較観察して見たところ
＞　CRF(10.4)×qcomp(0.9)×deblock=1:1:1が良さげである


　‥それにしてもアニメのＯＰ＆ＥＤ比較で、10と10.4とで５％程度の差だ。
　一方で、画質はビックリするほどに仕上がってきているが、まだ確認中である。

　（それにしても、USB2.0の帯域を瞬間的に超えてしまうデッドポイントが発生しうる段階だ）
　（別の意味でお手上げ感が漂いはじめてるってオチに悶絶中でもある）


＞　HDMI挿しで良いなら、サーチキュルキュルなんて要らねぇし
＞　それだったら‥投げて、視聴だけの方がずっと気が利いている（悩ましい）

【エンコード日記】AQ強度は、サイズ変更時の対応扱い込みだった件

記稿.2020/05/02

＞　‥いきなり本筋外れましてフレームレートの計算方法が発覚しました


　２４×0.999＝23.976
　３０×0.999＝29.97
　６０×0.999＝59.94

　‥なるほど、0.999をひっくり返すと、0.666とかなんとか（ラジオの周波数と同じ類ってか？）
　（これでど忘れしても大丈夫）


＞　では、本題です


　1080ｐ　→　1080ｐ：ＡＱ強度（1.00）、1：1
　1080ｐ　→　720ｐ：ＡＱ強度（0.6666666）、1：３分の２
　720ｐ　→　720ｐ：ＡＱ強度（1.00）、1：1

　※　ただし、色規格の枠を超えた利用において効果があるかどうかは不明。
　　（対応した4ｋモニターどころかＦＨＤモニターすら無いので、確認できかねます）
　　（静止画拡大比較での確認のレベルっすから）


＞　で、実際のところの変化を挙げておきます


　‥今やプリキュアの変身アイテム表現にティアラは欠かせません。
　ティアラ系アイテムに飾られる宝石類のキラキラとした角度がもたらす明暗の右と左
　つまり中央となる軸線がブレちまってるようなエンコードは糞です。
　（絵面のサイズ次第では、無残な形状をやらかしていたりして、「何コレ」状態です）

　でしたが、720ｐ：ＡＱ強度（0.6666666）を放り込んだ結果

　今まで散々ぼやぼやでどこに中心線があるのかさえわからなかったリップのティアラ画像が
　すっきりと中央の境をキープ（4ｋサイズ拡大時）、でもCRF（14.0）程度ではまだまだ怪しい。


　‥ウルトラマン第１話において
　ハヤタ隊員がボートで登場するシーン辺り、ムラマツ隊長との通信でバックの木の枝群が
　気持ちよさそうな風で揺れまくるのですが
　設定が不適切で、ちっとも最後までしっかりと動いてくれていませんでした。
　でも、ついに克服したんです。

　（実写だから１.00前提だなんて定説は、どうやらお門違いらしい）


　‥ドラゴンボール超 129話において
　悟空が身勝手の極意を極めた発動にて、瞬間移動で、ジレンの背後に現れる場面で
　解像度の違いのせいかどうかは定かにありませんが、ＢＤソースからしてわかりにくいのですが
　ジレンが悟空の後ろに視線をそらせる雰囲気をフェードで表現しているのですが

　ジレンの方の動きのピント（ボケていく）
　悟空の方の動きのピント（輪郭が明確になる）が連動し切れていない‥

　ずっと悩ましくわかりづらかったのがすっきりしました。


＞　という具合です
＞　ではありますが、DVDの場合は半々です


　‥４：３の場合の540ｐ：ＡＱ強度（1.125）は効果がわかりづらい
　‥16：9の場合の540ｐ：ＡＱ強度（1.125）はそれなりに有効
　ドラゴンボール超 129話と同じように、わかりづらいフェード表現がすっきりしたりする傾向。


＞　つまり、強引圧縮で、1080pのまま、ＡＱを弄ってあるリップは
＞　実質、弄ってある分の解像度情報に制限しちまったやらかしになる
＞　とした仮説がなりたちます（まぁ十分にその程度でしょう）


　‥それのケースのほとんどはＢフレームです
　その多くはｂ8ｘ8に制限されています。
　でも、1080ｐのＢフレームは許容幅が結構あるので、その辺をどう解釈しているかでしょう。

　（まぁいくらＢフレームで気張ってみても、Ｐフレームがグテグテだとどうにもならん）
　（Ｐフレームのできにこだわると、結局はＢＤ規格に及ぶって事ッすから）
　（つまり、1080ｐ：ＡＱ強度（1.00）でーす）

【エンコード日記】Chroma M.E.のオンオフを誤っていた件２

記稿.2020/04/30

＞　なんだかんだでまた「Chroma M.E.」の解釈に戻って来ちまいやした
＞　http://agehatype0.blog50.fc2.com/blog-entry-525.html


　彩度情報の動き予測を使わない。
　彩度情報の動き予測（＊Chroma ME＊）は
　サブピクセル精度の動き予測で使われるもので基本的には使うべき。
　彩度情報の動き予測を使うにはこのオプションを使わず、--subme 5以上にする事。


＞　解釈がすげーわかりにくいのですが


　予測を使わない。ＯＮ？
　基本的には使うべき。ＯＦＦ？？？

　動き予測を使うにはこのオプションを使わずにsubme 5以上‥？？？？？

　文章に沿って解釈する限り、subme 11ともなればＯＦＦでイケちゃう？？？


＞　と思っていたのだが、どうにも使った方が
＞　微に圧縮率は上がるし、微々だけど輪郭がくっきりするみたいだし
＞　なによりも，インターレース解除の光キラキラバック表現の光の伸びがワンランク上の仕上がり


　（以前に潰れちまうってケースは、他の数値変更ですっかり乗り切ってるっぽいし）


　‥どういうこと？
　「このオプションを使わず」の解釈が間違っているとしか思えないのだが

　原文：For chroma ME to be enabled, this switch must not be used,
　and --subme must be 5 or higher.

　グーグル翻訳：クロマMEを有効にするには、このスイッチを使用せず
　-submeを5以上にする必要があります。


＞　‥俺解釈
＞　‥クロマMEを有効にしましょう
＞　‥その為には、このスイッチを使うだけではダメです、合わせて--subme 5以上にする事。


　よくよく考えてみれば
　技術的に項目を用意しておきながら、こちらは使わずに
　サブピクセル動き予測のレベルの方だけで十分に機能します‥なんてありえない。
　説明文が糞だった可能性の方が高い。デフォルトＯＮだし。


＞　‥はぁまったく、英語の「must」は鬼門だｚ


　アインシュタインにしたって文系は苦手だったって事だし
　この説明文を書いた理系ちゃんが説明文を担当して四苦八苦だったって可能性は０％じゃねぇし
　それでなくても、マニュアル説明のわかりやすい難いは日常茶飯事だからな‥

　誰かここでの「must」解釈に引導を！

【エンコード日記】やはり、qpstep（4）に泣かされちまう件（720ｐ）

記稿.2020/04/29

＞　720ｐにおいて、qpstep（4）はやはり鬼門だった（540ｐでも同じだろう）
＞　Ｂフレームを多用するには正解でも、キュルキュルサーチを目指すなら不正解だった


　‥まずＢフレーム（3）において
　キュルキュルサーチ不適応に陥る件が
　インターレースソースにおいて発生した。

　次に、720ｐでのqpstep（4）だと
　ＡＶＣの苦手とする形状において、輪郭部分での欠損がどうにもまぬがれない。（致命的エラーだ）
　これは、me_rangeを弄っても同じでうんざりするほどどうしようもない。


＞　そこで、qpstep（6）に戻すことになった（こちらの方が無難）
＞　そこで、打つ手なしに打開策を求めてＡＱ強度を弄ってみた


　‥よくよく考えてみれば、AQ強度を弄ることは
　アンシャープ×シャープをやらかすことと同じだ。
　単に、マクロブロック単位で扱うか画面全体に一律に扱うかの差になる。


　‥ところが状況はかなり違っていた。


　インターレースソースにおいて強度を上げてゆくと、意外にも（2.0）で反応が止まった
　それ以上に上げても変化を得ないらしい。

　インターレースなだけに、複雑な部分でのエッジの改善は想定内にあるが
　プログレッシブソースでのＡＶＣが苦手とする形状には全く役に立たない。

　そこで、ＡＱ強度を下げてみることにした（プログレッシブソース）

　なにやら３分の２が良いらしい、これは1080ｐ×qpstep（4）においても同じ傾向だ。
　‥当然、deblock（1:1:1）→　deblock（1:0:0）になる。

　その３分の２をどのように扱うかで試してみた結果
　コンマ７桁まで識別した。
　つまりＡＱ（1:0.6666666）である。

　‥記録される値はＡＱ（1:0.67）でしか表示されないが、容量の変化は確認できているので
　‥コンマ指定できるほとんどはコンマ７桁まで扱えそうである。

（でも、XMedia Recodeの場合、裏技的な強制指定としては、一箇所しか指定できない）


　‥画質がどうなっていくかというと
　やはり誤差は小さい方が良いに決まっている予想通りを得ているが
　様々な箇所でも同じように扱えていないので、それなりに誤差が残ってる感じだ。
　そのどうしようもねえ一つが、重み付けのqcompである。


＞　qcomp値の度合いはもう少し上げても良さそうなので
＞　CRF（14.0）×qcomp（0.80）でやらかしてみている


　CRF（14.0）×qcomp（0.80）の比率は
　CRF（18.0）×qcomp（0.623）に沿っている。
　正確にはちょいはみ出て（0.801）を示す。

　ちなみにCRF（14.0）は

　18×0.88888888888≒16.0
　18×0.77777777777≒14.0
　18×0.66666666666≒12.0
　18×0.55555555555≒10.0

　を参考にした。


＞　なにがどうなっているのかようわからんぐらいに
＞　こないだまでの荒れた感が、嘘のように遠のいた


　1080ｐの場合、ｐ4ｘ4の影響か、ソースに比べるとエッジ感が多少弱い向きが見られる。
　それは720ｐでも同じなのだが
　だからといって今のところdeblock（1:-1:-1）にする気は無い。

　（液晶のバックライトの加減で、特定の色みに影響が出るとか出ないとか気になる）


＞　それにしても、まだまだ終わりそうに無いので予定が狂うｚ
＞　美麗キュルキュルサーチの道のりは半端ねぇ

【エンコード日記】me_rangeが重み付けの度合いに大きく影響している件

記稿.2020/04/28

＞　まず、qpstep（4）にしたことでの変化ですが
＞　アニメにおいて、deblock=1:1:1 が欠かせなくなりました（規格側の推奨値）


　‥思っていた以上に、エッジが強くなる造りだったと云うことでしょうか（わからん）

　で、b_adapt（適応型Ｂ-フレーム）を疑う事なく（2）にしているせいか
　bframes（３）がドツボで画質良好になっちまうようです。（意外だった）

　適応型Ｂ-フレーム（最適）にて推奨される連続Ｂフレーム枚数は３〜５だそうです。
　この３〜５の意味する内訳は
　著生の経験から踏まえると、720ｐなら３枚、1080ｐなら５枚まではイケるだろうに思われます。

　（ただし５枚の適応を確実にしたいなら、各所の調整が必要に思われます）

　※　著生の0.5秒調整の場合‥GOPの短さが影響し、３枚発生の度合いは低い。


＞　ここで気になるのが
＞　Ｂフレーム枚数の変動で重み付けの度合いに変化は起こらないのか？
＞　‥あったとしたら、どう調整すべきか？‥


　目に付いたのが、me_range（M.E. 範囲）です。
　以前にme_range（３２）×qcomp（0.6）でやっていた経緯を思い浮かべるに
　me_range（１６）におけるqcomp値に求められる度合いに
　どうしたって「あれ？」って思うところがあるのです。

　つまり

　me_range（３２）×qcomp（0.6）の固定との差こそ
　me_range（１６）にて、重み付けの割合を多く必要とする部位において
　先に強引にやってのけちまう特性が有ったということです。


＞　つまり


　me_range（M.E. 範囲）の値を上げると、重み付けの度合いに大きく影響するということです。
　‥ちなみに、（M.E. 範囲）のデフォルトは（16）です‥
　‥ちなみに、ＡＶＣの造りは、ＦＨＤサイズを前提にしています‥


　‥それでなくても、今から思えば‥me_range（３２）は大味でした。
　容量を削る上でのやっつけでもありました。（数値を増やすとそれだけでも削れちゃいますから）
　細かい所でどうしたって正確性に適っているかどうかは怪しいと云わざるを得ません。

　（まぁそこはともかく）

　数値を上げることで、me_range（１６）では得がたかった重み付け部分をサクッと
　表現し得ているのは、色々とした調整弁としての考慮の余地を残しています。

　（いやはや奥が深い）


＞　例えば、ref（２）のソースの場合です
＞　重み付けをどうするべきか？‥そこが問題です‥ref（４）とは明らかに違うでしょう


　‥ref値の変更でも、重み付けの度合いは大きく変わります。（とくにフェード場面）
　そりゃもう、qcomp値での増減さを押しのけてやらかします。

　ref（5）なら、me_range（16）のref（４）に対してqcomp値を80％にしてみる‥
　ref（3）なら、me_range（16）のref（４）に対してqcomp値を133.3333％にしてみる‥
　ref（2）なら、me_range（16）のref（４）に対してqcomp値を200%にしてみる‥

　（正しいかどうかは分かりません）


　‥なんて予想に対して
　もしかしてme_rangeなら、調整弁にできるかも知れない‥とかなんとか


　（HEVCでのデフォルトにもなると、一気に（５７）っすからね）
　（そこの違いをどう解釈すべきか‥実にもどかしい‥）

【エンコード日記】正しかった仮説と間違っていた仮説の件

記稿.2020/04/27

＞　まず、CRF値とqcomp値の比バランス対応一覧（仮説）ですが


CRF／qcomp（適正値by理論）／qcomp（失敗例）
18.0／0.60　　／0.53333
16.0／0.675　 ／0.60
15.0／0.72　　／0.64
14.4／0.75　　／0.66666
13.5／0.80　　／0.71111
12.8／0.84375／0.75
12.0／0.90　　／0.80


＞　理屈は当たっていましたのでそれぞれの例を挙げておきます


　‥進撃の巨人「紅蓮の弓矢」ＯＰにて
　冒頭のタイトルにて、タイトル文字が
　炎に包まれて文字まで揺らいでいるのが正しいエンコードになります。
　重み付けが不足していると、文字の揺らぎが炎に同調せずに動いていない印象に成り下がります。
　ＤＶＤでも、なんとかか細くも確かに揺らいでいるのを確認できますが
　ＤＶＤであの程度だからと納得してしまいがちなのが落とし穴になってます。
　ＢＤでは、文字が炎に合わせてぐにゃって印象を抱かせるぐらいに揺らぐんですね。


　‥化物語まよいマイマイ「帰り道」ＯＰにて
　夏の暑さの中の駄菓子屋の前を表現するのに、ノイズラインを動かして表現しているのですが
　重み付けが不足していると、どうにもハッキリとしない絵面に成り下がります。
　ノイズラインの動きが目に飛び込んでこないのでは、暑さの表現には至りません。
　重み付けの改善で飛び込んでくるようになりました。


　‥フレッシュプリキュア!「You make me happy!」ＥＤにて
　星のキラキラバックをこれでもかって云うぐらいに多用しているのですが
　それの表現をビットレートが足りないのか、インターレース採用なんですが
　アンシャープ＆シャープのフィルターを欠けると
　星のキラキラ感をしめす光の伸びがガタガタに成り下がっていましたが
　重み付けを適正にしてやるだけで、一気に解決していました。（おでれぇた）


　‥交響詩篇エウレカセブン「DAYS」ＯＰにて
　BD版ですが‥パンの全部に激しく二枚連続のブレ駒が発生しまくっています。
　ここまで改善しがたいインターレース表現に四苦八苦すること
　手っ取り早くやっつけるには、ref（５）ということになると思いますが
　重み付けを改善してやると、同じ程度に収まった状態を得ました（と云ってもまだまだですが）


　‥北の国からＯＰにて
　雨のシーンがあるのですが
　その雨の降り方が、重み付けを改善してやったら、ハッキリと土砂降り感がでるようになりました。


＞　結論として、仮説は正しかったとして良さそうです

---

＞　次なる仮説が、qpstep値です。


　‥720Ｐでは（6）、540ｐでは（8）としていたあれです。
　デフォルトは（4）です。

　qpstep値を増やせば増やすほどに、輪郭の無きぼやぼやな映像に仕上がります。

　‥とまぁそれだけだと思っていたのですが
　（4）にしてみたところ、シャープネスフィルターが不要になった、画質が向上した
　さらにＢフレーム枚数を３枚まだ安定して使えることを確認しました。（720ｐ‥CRF（13.5））

　（つまり、Ｂフレームの枚数適正にも絡んだ設定値だったと判明！）

　（なんて遠回りな道のりを辿ってきたのだろうか‥やれやれ‥）
　（高品質すぎると差が分からないという事から無意識のうちに劣化させて比較していたオチだった）


＞　‥結果、画質がどれぐらい向上したのかというと
＞　今回の上は、以前の特上画質を超えて減量に成功です（減量程度確認中）


　‥で、特上における注意点があります。
　以前にＤＶＤの自動的インターレースで、高画質を狙うと不能になる点を述べていますが
　どうにもそれと似たような要素をＢＤでも抱えはじめるのがCRF（12.0）に見られるようです。

　自動的インターレース解除が不能になるということではなく
　ソースエンコード側の質のムラに引っ掛かる端境に到達するらしく
　設定が適切に無いと、必ずしもダウンコンバートにあろうと誤差の相殺に不安定さが付きまとう
　ということです。

　‥ということですから
　例えソースがプログレッシブだろうと過信は禁物でーす。（頭の隅に入れておきましょう）

【エンコード日記】CRF値とqcomp値の比バランス対応一覧（仮説）

記稿.2020/04/26

＞　減量できないかと‥理屈を探って並べてみたら
＞　CRF（12.0）×qcqmp（0.8）では、まだまだ踏み込みが甘かったらしい


CRF／qcomp（理論？）／qcomp（失敗？）
18.0／0.60　　／0.53333
16.0／0.675　 ／0.60
15.0／0.72　　／0.64
14.4／0.75　　／0.66666
13.5／0.80　　／0.71111
12.8／0.84375／0.75
12.0／0.90　　／0.80


　‥↑の一覧を見てみると
　CRF（16.0）×CRF（0.6）では、重み付けが不足するのは分かっているので
　それと同じ比率に相当するCRF（12.0）×qcqmp（0.8）だと
　大型画面で不満がでると予想が立つ

　ということで

　特上 CRF（12.0）×qcqmp（0.9）‥輪郭全体のバランスまで文句ないが容量禍に晒される
　上 CRF（13.5）×qcqmp（0.8）‥輪郭全体で微に丸まるも、容量・バランス共に得やすい
　並 CRF（14.4）×qcqmp（0.75）‥DVD比較ならこの辺か？（未確認）


　※　あくまで720ｐ用途でのランクづけです（1080ｐなら、また変わるでしょう）
　※　GOPの距離を0.5秒の構成で確認しています
　23.976fps　psy_rd（0.50:0.00）　keyint（12）　keyint_min（1）

　※　特上と上で、概ね３〜４割ほどの容量差が見られます（でもまだ多い‥orz）

【エンコードレシピ】最果ての720ｐ解閃丼（BDtsプログレッシブアニメ版）

↓11)記稿.2020/04/26

＞　テレビＵＳＢ挿し勝手の極意とかなんとか
＞　キュルキュルサーチできてこそのテレビＵＳＢ挿し


　‥BDts→540ｐ変換において問題が発生するので720ｐに変更中です。
　今のところプログレッシブのアニメのソースのみでの確認という半端ですが
　そろそろひとまとめしておける段階に至ったのでレシピに起こしておきます。

　それにしても

　機動武闘伝Gガンダムの後半のＯＰに東方不敗とマスク男が手合わせする場面があるのですが
　そこの場面で、東方不敗がぱっちり二重に見えちまうってんですから、540ｐはもはや没です。
　そんな細かい部分の不安を抱えたままで1080ｐ→540ｐなんかやってられまへん。


＞　‥つうことで、再調整をしまくりました（もはや別次元です）
＞　CRF(12.0)×qcomp(0.8)×GOP(12)×scenecut（89）ということで（容量もハンバねぇ）
＞　シャープネスフィルターの合わせ技が隠し味になっとります
↓/続きを読む/↓

【エンコード日記】心理的エンハンスとＧＯＰが連動していた件

記稿.2020/04/25

＞　心理的エンハンスの基準値：psy=1 / psy_rd=1.00:0.00の場合
＞　適正なGOPは１秒分の枚数にぼかし方が調整される
＞　そこから外れているとエッジがきつかったり、ぼかしすぎたりしてしまう


　‥なので例えば≒24フレームでkeyint（８）なら
　psy=1 / psy_rd=0.33333:0.00　を打ち込めば安定した画質を得られる

　≒24フレームでkeyint（9）ならpsy=1 / psy_rd=0.375:0.00
　≒24フレームでkeyint（12）ならpsy=1 / psy_rd=0.5:0.00
　≒24フレームでkeyint（18）ならpsy=1 / psy_rd=0.75:0.00

　まぁ当然、打ち間違い防止を考えれば
　コンマ二桁までで割り切れる数値に合わせるのが能率アップでしょう

　ちなみに先読み枚数は、指定したGOPの４倍値がさらに安定する傾向です


＞　まだまだ調査中なので速報の扱いです（あしからず）