【エンコード日記】キュルキュルの正体こそ４ｘ４マクロブロックであるのを再確認した件

記稿.2023/10/11

＞　BDのプログレッシブtsは、秒間２４枚（23.976）だ
＞　優恋里小扉の先読み方式：24×2×0.999×16.666666…＝799.2≒（800）だと切り上げになる
＞　そこで：24×5×0.999×16.666666…＝1998枚で試してみた
＞　但しGOPの最大枚数（119）だ‥この組み合わせだと、読み取り誤差が少ないと言える


　‥確かに誤差はちびっと減った
　そこでこう思った‥これとM.E.範囲（４）を当てにすれば
　４×４マクロブロック切ってもイケるんじゃねぇ？（Ｉ４×４の代替化みたいな）
　負荷軽減策として有りなんじゃんねぇ？（早速やらかしてみた）

　画質はそれほどにオチもしないし、箇所によっては差し引きトントンなんだけど
　奇妙なことになった

　カメラアングルを海に向かって固定
　海に向かって走る場面があるとすると、突然にインしてきた人物の影は
　次第に小さくなって水平線に消える‥まぁそんな場面
　動きが小さくなるのは分かるけど、なぜかそのシーンの長さが５秒以内に収まる事から
　キーフレームが、最初の一枚目にしか発生しなかった
　（ちなみにこの場面では、そんなこんなで、４×４を効かせてもキー枚数発生がめちゃ少ない）


＞　他はほとんど変わりがない
＞　狙い通りに、負荷が小さくなった分、動きが通常のスマートに戻った感じにはある‥
＞　（まだまだ今後の検証が必要だ）


　‥ところが、それに
　ｂフレーム（３）を盛り込んで、マクロブロックの引き継ぎをし易くする為に
　先に同じく、すべてを８×８マクロブロック止まりにすると、あら不思議
　すべてが、GOPの最大枚数（119）切り出しと相成った

　シーン変更感度（８９）たるキュルキュルサーチ職人も名折れに落ちたのだった
　それはもう、HEVCの挙動そのものに落ちたのだった
　（シーン変更感度たる名称の役目になっていない）


＞　まぁｂフレームへのツケ劣化方向には及びにくい様だけど（HEVCもそういう事らしい）
＞　それにしたって、ref値次第だからもう無理
＞　参照フレームMixまで外すと、ビットレート量に関係なくグデグデになる


　で、無理にビットレート下げを狙うと、光表現での矛盾が発生するどえす
　平然とした目で、輝度を殺しつつ突っつき回さないと無理（いやーんな方向性どえむ）

【エンコード日記】フレーム枚数が同じ且つ同じビットレートの２パスでも出来上がり容量が異なる

↓2)記稿.2023/10/10

＞　基本的に白画像と黒画像とでは、白画像の方にビットレートがかさむ
＞　（これが、YUV4:2:0の特徴なのだろうと思わざるを得ず）


　つまり、白地のパンは増量促進中オチになるので、多様は禁物だ
　ホワイトイン＆アウトでも同じ事、悩ましい限りだなあ

　それは、白黒画面演出でも同じ事（セピア色の方が無難でしょう）


＞　優恋里小扉エンコードの場合


　ソースのビットレートが多いとそりゃまぁ予想を裏切る所無く大きくなるわけだが

　参照フレームMixを使っていないのかと思うほどに、参照枚数が少ないソースだと
　やたらと出来上がりサイズが小さい傾向を見せる
　（まさかのソースより縮むとかあり得ねぇ‥ビットレート(441000)なんだｚ‥）

　逆に、バリバリに参照フレームMixが効いてるようなソースだと肥大化する
　（OP&EDなんて概ねお約束の容量なのに、２パターンとで100MB以上の開きを見せるとマジ驚く）

　まぁそれらは順当に、Ｂフレームレベルでの圧縮の詰め込み度合いの差になるのだろう
　（OP&EDなんて切換シーン多めなわけで、多いなりの工夫があるだろうから）
　（単に複雑すぎていないか否かの差とも言えそうだ）
　（でも、これもそうなの？‥というソースも見られるのだからよく分からない）
↓/続きを読む/↓

【エンコードレシピ】誕生！優恋里小扉(まされりこぴ)‥BDtsをアセンションしちゃうぞぃ(FHD)

↓12)記稿.2023/10/08

｜減量無理だけどキラッ☆星月夜 輝く扉はいつもAVC
｜激重なエンコードの夜長かな 待ちぼうけでもお仕事中？
｜デコードのぷち軽くなり秋ぽちい できるマシンに大ストレージ
｜秋思う♥激Ｑるンのあの場面 瞬く永遠とわをサクサクサーチ

　‥うわぁぁあああ、詠み返すほどにカウチポテト族のそれなりにぽよ腹腐女子に見えるｚ‥
　それが、優恋里小扉(まされりこぴ)‥らしいどえむ。

　（AVCの特性って‥時代の鏡似性込みだったんだなあ‥まさに３S）
　（減量したい症候群をAVCに向けてきた‥みたいなぁ）
　（まぁその点、おいらは筋肉ぽちい口だからな、筋肉を保持するにはある程度の重量が必要だ）
　（それがエンコードのそもそもに求められるビットレートとしての絶対量‥みたいな）
　（そしてそれこそがAVCとしての完成美！‥なんてな）

---

＞　今回、用意して頂くアプリは、XMedia Recode 64bitの最新版でＯＫです。
＞　但し、インストール版を推奨します。
＞　（さらにできれば、DDR4以上のマシンと強力な２Ｄ性能を伴うグラボを備えましょう）


　‥今回は、プログレッシブとインターレースを同時に扱います。
　但し、1080ｐ→1080ｐ，1080ｉ→1080ｉです。（ｉ解除エンコードを行いません）

　ｂフレーム群をｐフレーム群に置き換えて、サクサクＱるンに仕上げる次第を目的とします。
　結果、増量するソースも出てきますが、そんなこった知ったこっちゃねぇと腹を括りましょう。

　結果�@‥1080ｉは、テレビモード‥好逸ユーザーでの統一した視聴に置換わります。
　（まぁ1080ｐに関しては、ソースに依りけり次第の所も見られるでしょう）
　結果�A‥VLCプレイヤーでのデインターレースモード選択が「Film NTST」一択にまとまります。
　（まぁ完全には解除しきれていない部分も見られますので、好みの差は出ると思います）

　（ちなみに、再生支援は自動よりも‥Direct3D11ビデオアクセラセーションですかね‥）


＞　ビットレート謎めく調整比‥｛平均ビットレート：バッファ：最大ビットレート｝※AQ3必須


　1080ｐ｛36：81：144｝→｛4：9：16｝→｛1：２.25：４｝
　1080ｉ｛36：144：324｝→｛4：16：36｝→｛1：4：９｝

　1080ｐ｛40000：90000：160000｝‥200＾2（要レベル６）
　1080ｉ｛40000：160000：360000｝‥200＾2（要レベル６.1）

　1080ｐ｛44100：99225：176400｝‥210＾2（要レベル６）
　1080ｉ｛44100：176400：396900｝‥210＾2（要レベル６.1）
↓/続きを読む/↓

【エンコードレシピ】減量ついに来たれり天高し‥暫定Ａランチ（1080ｐ→1080ｐ）

↓12)記稿.2023/10/07

｜減秋やれやれの夜 雨の音 重いレシピの動画エンコード
｜減量ついに来たれり天高し ｂをリストラし画質ヨーソロー
｜激壌ああ秋深む腹の音 激敢激喚なれど激閑
｜上等見入る陳列秋の声 手頃なホタテにあらマスカット（どうなんでしょうね？）

　‥五音発音の二文字熟語を初句に置いて字余りさせずに詠んでみた
　まぁこれはこれで一つの作風みたいな（なんで今まで気が付かんかったんや）


＞　今回、用意して頂くアプリは、XMedia Recode 64bitの最新版でＯＫです。
＞　但し、インストール版どえす。


　‥ちなみに、解像度の変更できる以前なポータブル版で試していたら
　グラボのドライバーがエラーを吐いて、送信してね窓を開きました。（只今セーフモード中）
　無視してそのままエンコードを試し続けたのを一枚出ししてアップ確認したら
　そのエンコードにエラー停止せずとも、ここだけ格子が随分と異なるんだけどエラー出てました‥
　（ポータブル版では、スタンバイに入らないし‥ここでは使えない子だと判明したどえむ‥orz）

　‥グラボドライバーセーフモード落ちの解除に、まるまるPC再起動せなあかんなんて糞すぎる〜

　‥ちなみに、そのドライバーは、AMDの（23.Q3）版です。
　グラボは、玄人志向　RD-RX550-E4GBです。


＞　それにしてもエンコが重いｚ‥負荷の掛かるOP&ED群の1分30秒に平均で15分‥ないわぁ‥
＞　デコードにしても‥ソースによっては難を垣間見るという‥蛇の生殺し状態どえむ‥OTL
＞　まずは、５倍は速いマシンの用意からどえす（AVCの奥深さを見せつけられている）

｜ああポチい五倍は速きヒツジ雲 見上げる空に高輝度アプコン

　‥まずは、技術理解から　→　一度は目を通そう＜読んでね＞

　無論、今回もわさｂ抜きで攻めて行きます。（1080ｐ→1080p）

　一生懸命にｂフレームでやらかされてあるソース群に対して
　物申したいわけでも無いのですが、まぁｂフレームはリストラしちゃいます。
　マスターデータとは中身の事情が異なるんですから
　ｂフレームを採用したままではとても品質保持なんて無理という見解ゆえです。m(_ _)m


　‥まぁｂフレーム群をｐフレーム群に置き換えるだけでも
　その圧縮効果は、｛ｐ：ｂ｝＝｛1：1.3｝として単純に見積もるだけでも‥23％減です
　（えっなんですって？、それで同じビットレートだったら圧縮になってねぇって）
　（しかもｂフレームの割り当ては、都合変動に晒されるからそんなのアテにならねぇって‥）


＞　いやぁまぁ率直に申し上げますと‥そういうオチなんですけどね（トホホ）


　‥↓がそれの経過どえむ
　1080ｐ様Ａランチ｛平均：バッファ：最大｝
　｛36：81：144｝→｛4：9：16｝→｛1：２.25：４｝

　L5｛22500：50625：90000｝‥150^2　←再生支援ありでＨＤの高画質程度
　L5.1｛25600：57600：102400｝‥160^2　←再生支援ありき
　L5.1｛28900：65025：115600｝‥170^2　←再生支援ありき
　L5.1｛32400：72900：129600｝‥180^2　←今回レシピでの目標値（25分もの６ＧＢ想定）
　L5.1｛36100：81225：144400｝‥190^2　←まだまだソース次第くささあり
　L6｛40000：90000：160000｝‥200^2　←業界的過去作のサクッと確認に欲しくなる手頃感


　‥相変わらずに謎めく調整比ですが、マクロブロックのＡＱ品質に決定的に影響してるどえす。
　ここを間違うと、光表現で悩ましい状況に陥るどえむ。（入力失敗体験済み）


＞　その正体の鍵を握るのは、なんと‥AQ3絡み‥くさっ


　‥180^2では、完コピ度ちょびっと足りてません（残念）
　‥190^2でも、ちょちょびっと足りてません（このソース、偶然にもビットレート同じやん‥orz）


＞　もうダメやん‥今回タイトルにケチが付きましたん‥
＞　‥詠み直そうにも、まだまだ感動のグラデーションが満ちていない‥


　‥200^2で、業界人もマニアもニンマリしだすバックアップとしての垂涎的必須‥みたいな
　（これぞHDRの入口０丁目ぐらいかも‥どうにもそれは高輝度なアプコンへの変貌と化している）


＞　いやぁもうこれの案内が無かったなら‥映像業界はゾッとする事になるッスから‥


　‥結局、BDの最高品位25分もの７.2GBで底打ちみたいな
　‥そこから下は、ｂフレーム前提の次元どえす（良かったねｂフレーム群）
↓/続きを読む/↓

【BDアニメ】AVCエンコード（1080p）には難所が二つある件

↓1)記稿.2023/10/06

＞　基本的にAVCは、HEVCに比べるとパン処理が弱い
＞　構造物表現が細かくなるほどにビットレートを持って行かれて
＞　カクカクしがちに成りやすいそれをどうにかするには、どうしたってGOPを伸ばすほかない


　一般にGOPの最大値を、キーフレーム間隔（rc_lookahead）と呼ぶが
　それは、シーン変更感度（scenecut）の値を（40）の固定とする

　｛ rc_lookahead＝23，scenecut＝40 ｝‥デフォルト

　この場合、場面変更を検知せずとも問答無用で１秒に区切られる
　デフォルト値の４０には、場面検知よりも秒刻みの方を優先した意味も込められている

　‥構成できるマクロブロックには制限がある
　Ｉフレームには、よりブロックを詳細に集中させないと品質は上がらない
　ビットレートばかり上げても、その辺で、Ｉフレーム品質は頭打ちするのだ

　さらに、この手の場面切換想定は、20世紀映像の想定だ
　（21世紀映像に見られる様なデジタル時代ゆえの場面切り替えの早い想定をしていない）
　なので、本質的な意味において「シーン変更感度」とした呼称にはやや語弊を含む
　（シーン変更感度とした本来の意味でなら（８９）がオススメだ）


　‥その動画エンコードの通常概念として
　１秒ごとのマクロブロックの最大数が、レベル概念を通して決められている

　つまり、圧縮率を高めるには、その壁を超えてやるルール採用が必要になる
　それがつまり、参照フレームMix（mixed_ref）だ

　但し、この参照フレームMixの挙動には注意が必要だ

　一般には、エンコードの都度の都合があるので、IDRとした特別なＩフレームが用意される
　（IDRフレームより前にあるブロックを参照しないとした区切りルールだ）
　（オープンGOPでは定期枚数に発生するが、参照フレームMixでは必ずしもそうとは限らない‥謎）


＞　とにもかくにも、それの壁超え最大可能延長フレーム数についての余幅言及を聞いた例しがない


　‥それの予想としては、いくつか考えられる
　一つは、理論上のｐフレームの最大参照枚数×ｂフレーム数の最大数だろうと思うにせよ
　実質的には、BD品質とした参照フレーム（４）と、美麗とされるｂフレーム（３）の都合がある

　すると‥１３枚を基本的な長さに見立て、それの３倍程度とした所だろう
　あまりに遠くから拾っても、マクロブロックの型が噛み合うものではない（アニメなら尚更だ）

　（まぁ要するに２秒以内がBD品質でのスタンダードな想定に思われる）


＞　なので、GOPを伸ばすにしても２秒としたキーフレーム間隔の延長が手頃になる
＞　rc_lookahead＝47，mixed_ref＝1


　※　だが当然として、エンコードの際に「先読み」の枚数を増やしておかないのでは話にならない
　簡潔にデフォルトの２倍ぐらいに思ってるんだろうが‥実質的には
　作品タイトル毎のパンの最大長を満たしていないのではお話にならない
　アクション実写映画なんかだと、諸々２秒に収まらないパン・シーンなんざいくらでもあるだろう
　そういう想定ともなると実に悩ましくなるものだ

　（だがしかし、先読みをべらぼうに伸ばすだけでカク付き解消してしまうケースも有るはずだ）
　（もっとも、十分なビットレート量こそ第一条件である）


＞　ところが、これで良いと思っていると足元を掬われる要素に悩まされる事になる
↓/続きを読む/↓