【エンコード日記】スライスとは何か？

↓5)記稿.2024/08/15

＞　それでは、動画エンコードにおける「スライス」とは何か？
＞　（論文主張に非ず、それこそ素人の日記としてお読み下され）


　‥今まで参照枚数と思っていたのが
　実は、｛参照枚数｝＝｛参照枚数改め、参照距離×諸々としたスライス枚数｝だった？？
　（参照MIXなどを介することで、発動するIDRとした許容を含めると参照距離はさらに伸びる？？）


　　其を具体的に語るなら、走査線とした概念のデジタル解釈な置き換えであり
　　１つの走査線として扱う厚みとして、16×16マクロブロックとした水平サイズがAVCの扱いだ
　　HEVCになると、これが64×64にて扱える

　　（実構造な意味で言うと、この差がとてつもなくスゴイのら）

　　なぜなら、スライスのお約束には
　「同じ水平ラインにて完結すべき‥最低一つからなる複数のマクロブロック群を指す」‥とある。
　　なので、その最大は、行幅分のマクロブロック数を意味するが
　　それでどうやって形を認識して取り扱わせているのか？‥がとても謎

　　もとい、試しエンコードの失敗を重ねて理解したのは、↑の論文文は誤りであり
　　（最低一つに非ず一行だったのさ、複数に非ず複数行だったのさ‥）
　　（言葉のあやなのか‥技術向上の結果の再調整なのか‥そんなん知る由もなし）　


　実際的には、１枚のフレームを、指定したスライス値で縦ラインを割るのだから
　水平ラインを中途に分割するようなことをせずに、四捨五入して分割位置を決めている。

　　例えば、720ｐを128ドットで割ると（5.625）行分割とした言いようにもなるが
　　　　　「中途は駄目よ」なので四捨五入してスライス（6）になる。
　　　　　　HEVCでのCU64を一段だけごとにスライスしても面白くないのなら
　　　　　　縦128ドット幅は一つのスタンダードとした解釈になるっぽ（実際は知らん）

　　すると、最下段で割り切れずに行分の端数が起こるので、取り扱い上の調整が入る（ここが肝）

　　　さらに、割り切れない値ながらの、割り切れない要素を利用して
　　　スライス行幅を固定にせずに、変動調整で扱うのだろうか？
　　　そうだとすると、自動でおまかせの方が圧倒的に良いに決まってる‥と思わざるを得ず。謎。


＞　素人からするとスライスの幅が、指定枚数からの固定幅なのか？変動調整なのか？‥知らんわ

1-5)1

＞　では一体、スライスにはどんな効果があるのか？


　‥単純に丸めて語ると
　ｂピラミッドは、連続するｂフレームから見たら共有利用可能なスライスだ

　　だがその裏では、参照枚数にｂピラミッドの１枚分増えただけで「再生遅延」を騒ぐほどだ
　　なのだから、それをｐフレームでもやらかそうって話になると悶絶することにならん
　　何枚まで大丈夫なのか？、何枚分割で想定十分になるのか？‥なんてトライアンドエラーだ‥


　‥そもそもAVCにしても、HEVCにしても放送規格であり、放送帯域に制限を受ける
　そういう作りなので、Ｉフレームを重視していない

　なので、Ｉフレームからのスライスにはそれ程に期待しない想定になっていて
　その代わりに、HEVCでは、大きなサイズのマクロブロックを用いる事で
　Ｐフレームにもイントラの役割を担わせやすくしたっぽい

　つまり、Ｐフレームの中身に
　イントラのスライスと、インターのスライスが隠れているのら（ここ重要）

　　（要は、一枚のＰフレームの中に、イントラのスライスとインターのスライスが混在するのだ）
　　（でもなぜか技術論文からして、そういう風に、具体的に説くことがまず無い）
　　（素人は、どうしたって、イントラ＝Ｉフレーム＝キーフレームと思い込んでいる）


＞　無論、完全なるイントラの役割をＰフレーム自体に担わせるには無理があるのだから
＞　そこの差を意識させる呼称に「スライス」を盛り込んで、臭わせてあるぐらいだ


　‥つまり、多少わかったように見えても
　　ｐフレーム間同士でやりくりする「スライス」と呼ばれる其れを
　　ｂピラミッドと似た概念に思いこみ‥不特定な形でもかまわないブロック群単位にも見える‥


＞　無論、水平ライン単位扱いなのがスライスの基本概念のはずなのだから
＞　HEVCの四分木説明は、そうには見えてこないので、とても謎


　‥エンコーダーが圧縮目的で、利用しやすいように処理するのだから
　　そのブロック群形状が、人間の想定するような形状ばかりとは限らない
　　（実はそうならないように事前対策済みなのも、水平ライン単位扱いなのだろう）

　　それを四分木と掛け合わせて説明してくるので、複雑すぎて解りづらくなる
　　（どう考えたって、スプライト機能じゃあるめぇし、形単位でのスライスなんかじゃない）


　‥巷の多くが、単純にｂフレームをより多く連続させた方が良さげに思い込んだ
　　それが以前の段階だった（実験的にもｂピラミッドは画質を上げることが知られた）

　　そして今度は、其れをｐフレーム群でもやる段階なのだから
　　ｐフレーム間のスライス連携で画質が上がるなら、優先順位は自ずと見えている
　　（その時に、ｂフレームの最大メリットは、後方参照できる点のみになる）

　（ｂピラミッドも絡むというのに、ｂフレームの後方参照を折り込むと、とても頭が痛い）
　（結果として、場面切れの用を忘れつつ、後方参照活用にてGOPの尻に引っ付くのが相場になる）

　　‥そんなことからも、組立管理上、長すぎるｂフレームは扱いづらくなるのは当然で
　　　誤差に対する品質を負えないとして想定枚数とやらが規格の水準に留まるらしい
　　‥一方で、長すぎるGOPには、警戒せずが、規格側のスタンスくせぇ
　　　始めにオープンGOPを開発してるんだから其は当然だ
　　　何はともあれ、最終的には、放送帯域に押し込めれば、それで良いみたいな

1-5)2

＞　ところが残念な事に、スライス枚数を増やせば増やすほどに
＞　画質が上がるかどうかはほぼプラシーボで、どちらかといえば増量する（わさｂ抜き確認）


　‥じゃ、何の意味があるの？
　そりゃまぁ画面サイズがでかくなるほどに、一枚の画面を構成する際の遅延が気になりだす

　　なので、並列処理宜しくに、スライス単位でイントラを完成させておけば
　　あとはインター側を上書きして組み立てれば良いわけで、効率的に組み立てることが可能だろう

　　‥そういう意味では、AVC以前から概念はあっても、実用に足る並列処理は存在しなかった
　　HEVCにおいては、メモリー速度が上がったがゆえに処理速度が上昇し
　　結果として、スライス的並列処理を想定以上に要求する状況から遠のいたっぽい
　　VVCとて、そろそろ想定以上の頃合いな空気が漂うようなそうでもなさそうな度合いに思われる
　　（結局の所なぜか増量しちゃうんだから、お呼びでない‥みたいな）


＞　で、それで、上手にスライスするコツや判断って何？
＞　そんなん、どのようにすると効率が良いのかなんてそれこそトライアンドエラーだ
＞　どうして‥詳しくドヤ顔で教えてくれると思えるんだ？（四分木な説明は普通に大味なのどえす）


　‥その中身は、アナログ放送とデジタル放送の違いを語らず以上に奥深い秘伝に思われる。

1-5)3

＞　では次に、↓ソフトウェアエンコードの項目を確認してみよう（AVCの場合）


◆◇◆　切り出し　◆◇◆
フレームあたりの切り出し数：値が想定よりちょっとでも上回ると、再生支援から先に映像にならず
切り出し最大サイズ（bytes）：表向きの最大値（２５０）
切り出し最大値（mbs）：表向きの最大値（１００）
slice min mbs：表向きの最大値（５０）


　‥項目は、たったの4つのみどえす。（あとBD互換としたなんちゃらもありますが触れません）
　まず最初の「フレームあたりの切り出し数」とあるが
　数がちょっとでも多くなると、再生支援から先に映像にならない
　その次に、テレビUSB挿しにて、スローモーションの如しに流れる

　一方で、ＣＰＵ再生の方は、並列処理がパワフルなせいか、とても余裕
　（ずばり巷の動画再生支援に、スライスを十分に並列処理やらかす能力はねぇ）


＞　‥まず「切り出し最大サイズ」とは何か？‥を解かんとあかんどえす


　‥バイトサイズで指定せよ‥？？？‥これでは勘違いするどえす
　先に説明した通り、縦幅128ドットで割った場合の余りとの差が‥当てはまるとするなら‥

　つまり、スライス１枚の大きさを、横解像度×128ドットに指定したいとすると
　1280×720解像度の編集サイズなら、
　そのスライス枚数は（5.625）で、四捨五入すると（６）を得る
　その際、最下段（0.625）枚比で端数となり、最大サイズとの差が生ずる

　　其の切り出し方針なら、1280×128÷8＝2048　2048バイトになるのかも知れない


＞　だが、次の「切り出し最大値」とやらがよく解らない


　水平ラインとしてのマクロブロック数の最大値なのか？
　切り出すスライス幅でのマクロブロック数の最大値なのか？‥とした二通りの見方になる
　（やってみないと判らニャい、全滅ならお手上げニャん）

　ところが、続いて「切り出し最小値」を示せとある

　仮に、どちらも水平ライン内での分割を意味したなら
　　最小は（１）だろう
　　対して、最大は横の解像度を１６で割れば良いだけなら、自動でやれよってツッコミにもなる
　そうではなく指定になっていると言うことは
　スライス枚数を四捨五入する前段階の内訳を示せって事かも知れない

　すると、最大は（６４０）、最小は（４００）なのかも知れない

　‥1280×720を参考にしてもそれだけの数値を得ることになるなら
　「じゃ初期値って何？」「どうしてそんなにちっぱいサイズだったの？」
　とした疑問が生ずるばかりだろう（そもそもの内計算スタンダードは、1980×1088だろうがッ）


＞　そこで、初期値想定に近しくなるように計算してみた


　21.6メガバイト／ｓ＝216,000バイト
　一秒間60枚×3600マクロブロックとすると216000個になる。
　つまり、一つのマクロブロックの想定平均は、たったの１バイト程度だ、10倍でも１０バイトだ

　そこで、曖昧ながらにも

　横の水平解像度が1280なら、80マクロブロックなので
　最低は１バイトで80バイトが切り出しすべき平均的な最大予想になる。10倍しても800バイトだ。

　その計算で頑張ってみた結果
　頑張っても、上手に回せたのは、ＤＶＤの４：３ソースだけだった
　あとはもう、なんとかまともに映像として回るのはＣＰＵ再生でのみだった
　（全部を確認したわけではないので、回せたとて失敗フレームありきかも知れん）


＞　取りあえず、触りだけ齧って、匙を投げましたｚ

1-5)4

＞　で、今度はAMDエンコードでの反応どえむ


◇◆◇　量子化設定　◇◆◇
フレームあたりの切り出し数：３２（1980×1080サイズでの再生支援対応上限値）
　　　　　　　　　　　　※　但し、HDテレビでは回りません
　　　　　　　　　　　　※　これは、機能的上限値（３２）とした意味どえす

最大アクセス単位（ビット）：縦解像度×横解像度スライス幅の想定では改善し切らず

　　　‥水平ラインとした考え方が、スライス１枚あたりのマクロブロックを
　　　　地続き扱いしてるっぽいので、其の規模を以て、１枚と疑わざるを得ず
　　　　基本が画面一枚からなら、画面の水平ラインが全部地続きの水平ラインみたいな

　　　‥するとどう考えたって、単位ビット＝単位ドット数だろうと思わざるを得ず

　　　‥だが、表向きの最大アクセス単位の最大値が（６００）しかねぇ
　　　　じゃ、マクロブロックの数指定をビット数に見立てているの？
　　　　其れでやってみても、縦解像度×横解像度スライス幅の想定の方がまだマシなのら
　　　（ちなみに、切り出し単位が十の後半になりだすと、テレビUSB挿しの際に怪しくなる）


＞　どうにも、少ないビットレートの上昇で、画質アップを狙った造りに見えてしまうのだが？？？
＞（ｂピラミッドは、ｂフレームの符合を担保するので、確実にビットレート削るけど）
＞（スライスはマクロブロックをくくる枠組だけなので、まずは、組立符合の増分との相殺が絡む）
＞（その際に、画質アップ効果を上乗せするスタイルなら、どうしたって増量するくさい）　
＞（HEVCならそれな符合増量を避けるためのCU32の仲介があるのだろうけど、AVCにはねぇズラ）


　‥なので、スライス値を上げるごとに、ビットレート増加減の端境を見るらん。
　‥切り替わった端境が画質アップの目安かもなんでしょうけど
　　稀に「ぐでフレーム」の発生するような状況では、蛇の生殺しどえす。


　‥「ぐでフレーム」とは
　キーフレームにしちゃいけないフレームが「なぜ起こるのか？」はさておき
　スライスの分割境で、ドットずれのような崩れのような雪崩症状を起こし
　それがGOPの開始に起こるもんだから、そのGOPの枚数分に波及して失敗GOPに堕ちるどえむ

　（そういう変なキーフレームが稀に発生するどえむ）
　（とくに動きの激しさ絡みのようなよすがになし）

　　‥avidemuxに放り込んで、該当する失敗GOPをコマ送りすると
　　雪崩を起こしている部分に上書きする様子を確認できる（これっぽちかよ‥みたいな描換感）

　　‥該当キーフレームの一つ前のGOPのキーからコマ送りすると
　　何ごとも無かったかのように表示されるも、よく見ると、該当スライスの開始位置にズレあり


　‥そのタイトル全話が無事に貫通すればラッキーと思えって率どえす
　　（宝くじよりは、成功する確率はありそうですけどね、逐一のチェックが欠かせません）
　　（エンコードを爆速にて終えても、チェックせずして完成得ずとか‥やり直し悶絶とか‥orz）


＞　こちらも匙を投げざるを得ず

1-5)5

＞　↓は、諸々計算値痕跡どえす


1920×1080の場合


1920×1088
1088÷16＝68

1920÷16÷3.333333‥＝36＿＿（36）は下層段にて、再生支援で視聴不良発生
1920÷16÷3.6363636‥＝33＿＿（33）は最下段にて、再生支援で視聴不良発生
1920÷16÷3.75‥＝32＿＿（32）までが実用に耐える想定枠？

8160マクロブロックを一続きの水平ラインとして扱う最大値解釈だとすると
8160÷32＝255‥‥どうにもプログラム上の都合くさそうな１スライス辺りの分解能上限みたいな。
　　　　　　　　‥となると「それぞれ分解数の割り当ての上限をカスタマイズせよ‥」
　　　　　　　　　とした意図がありそうに思える

　　　　　　　　　そりゃまぁそれなりに自由度を用意しておかないと後で困るのは確かどえす

　　　　　　　　　それはそれで、スライス幅の常時可変変動に対応したつくりにあるとは思えない
　　　　　　　　　HEVCは考慮されてるかも知れないが、AVCは怪しい

　　　　　　　そもそもの「AMD AMF」の項目が、HEVC版もAVC版も同じだｙ
　　　　　　　扱いは同じでも、内部的に細かい点で違うとか？
　　　　　　　（ちなみに、HEVCハードに対応せずとも、とりあえずどちらも動いた）
　　　　　　　（それはそれで、HEVC刻印あれど怪しいｚ）　



1280×720
720÷16＝45
80×3＝240

21600
スライス（3），1280×15×16＝307200
スライス（5），1280×_9×16＝184320
スライス（9），1280×_5×16＝102400‥まぁこの辺
スライス（15），1280×3×16＝_61440


792÷16＝49.5　（50）

19800
スライス（2），1056×25×16＝422400
スライス（5），1056×10×16＝168960
スライス（10），1056×5×16＝_84480
スライス（25），1056×2×16＝_33792


20400
スライス（2），1080×25×16＝432000
スライス（5），1080×10×16＝172800
スライス（10），1080×5×16＝864000
スライス（25），1080×2×16＝_34560


960×720
60×45＝2700　2700×6＝16200
16200
スライス（3），960×15×16＝230400
スライス（5），960×_9×16＝138240
スライス（9），960×_5×16＝_76800‥まぁこの辺
スライス（15），960×3×16＝_46080


528÷16＝33

8910
スライス（3），720×11×16＝126720
スライス（11），720×3×16＝_34560‥まぁこちら

11880
スライス（3），960×11×16＝168960
スライス（11），960×3×16＝_46080‥まぁこちら