【HEVCと洗逸と受難】イントラとインターのそこんところ

記稿.2019/01/20

＞　ＡＶＣに比べると、ＨＥＶＣでは、圧倒的に「イントラ」と「インター」を用いた説明が入る


　‥早い話が
　キーフレームとそのあとに続くフレームとの違いを意味しているのだが
　HEVCの場合は、特にイントラとインターにおいて四分木の扱いが異なっている事によるのだろう

　例えば、レベル5.1以上を選ぶ場合
　イントラ深度は、強制的にCU（64）とCU（32）の二段階に制限されるという
　すると、四分木としてイントラ深度（4）までを扱えるのは、レベル4.2までで、最適解像度で云えばFHDサイズだ

（どうしてこんな事になっているのかというと、思うに、デコードまでが大変になるから）
（もともと送信量を減らすことを考慮して造られたのがHEVCでもあるわけだし、そのように思われる）
（これが５Ｇ時代に突入すると、事情は異なってくるかも知れない）


　‥イントラは、オープンGOPやオールイントラにでもなければ、他の画像からの格子を参照しない‥
　（※IDRフレームという区分がキーフレームになる）

　つまり参照される側だから、圧縮においてのそれは、単に参照されやすいようにマス目を引くだけになる
　この段階でわざわざ矩形の形までを採用すると非常に複雑な計算をせざるを得ない
　なので、ザックリと　CU（64）（32）（16）（8）という正方形要素だけでマス目を引く扱いらしい

　ただし、CU（64）からのイントラ深度（4）を用いたとて、必ずしも望む効果を得られるかは不明だ

　そこで最大CUを下げると、下げた分だけイントラ深度の値も下げることになる
　最小CUを上げても、上げた分だけイントラ深度の値を下げることになる

　…このことから
　イントラ深度（1）を選択する場合には、最大CUと最小CUの値を揃えることを意味するのだろう
　果たして最大と最小のどちらを用いるのだろうか？
　最大CU（64）、最小CU（8）に選択していたなら、自動で一番に効率の良いところを選ぶのだろうか？

（まぁその辺の細かい解説は今のところ目にした例しがない）
（気になるようなら、始めから最大CUと最小CUの値を揃えて指定してしまうのが時間的効率かも知れない‥）　
（HEVCの場合、小サイズでのエンコードなら、最大CU（16），最小CU（8），イントラ深度（2）だろう）


＞　ではインターの場合はどうだろうか？


　‥文献でも細かい解説が見られないので、あくまで想像の域を超えないが
　再帰的というぐらいだから、インターとて
　イントラの定義に則って、基本的な正方形格子を用いて区切るのだろう

　そうで有るならば、イントラがキーフレームとして適切に値しない場合は
　インター自身の分解に任せる仕様に思われる（そうとしか思えない）


　‥イントラが、キーフレームとして適切である場合
　インターは、イントラの格子をそのままに活用して、インターとしての四分木を切ることができる
　で、その時の最大TUというのが、最大CUサイズからの矩形を意味しており
　矩形をさらに分解するという事では無いらしい

　矩形に分解されれば、それより先の分解を進めず、基本は正方形格子による入れ子式に折りたたまれる
　ということで、4ｘ4の分解マス目は、CU（4）としての扱いをせずに矩形の一つに区分されている（へぇ〜）


　では、最大CU最小CU最大TUともに（16）で且つイントラ深度インター深度ともに（1）なら
　そのマス目の分解能は16×16と16ｘｎサイズのTUだけという事になるのだろうか？

（誰もそんなのを想定していないとばかりに説明不足はどうにも不可解である）


＞　‥イントラのマス目が、インターのマス目たり得るなら、品質も圧縮効率も向上する
＞　‥インターのマス目たり得ないなら、Ｐフレームに制限されるようなビットレートでやり繰りしなければならない
＞　その時の品質と圧縮効率の兼ね合いは決して満足できる状況には無い
＞　ただし、オールイントラの場合には、容量が嵩むだけで、品質に差は見られないだろう


　‥ＨＥＶＣのスライス能力は、優秀にあることから、増量を気に留めないなら
　それの差の見分けが付かないことから、キーフレームがどこだろうと気にする必要はほとんど無い

　しかしそれで良いのだろうか？

　見分けが付かないほどに優秀なスライス能力を手に入れたなら
　次は編集のしやすさとしてのキーフレームの的確さということになるはずだが
　未だに「一に縮小、二に縮小、兎に角まだまだ縮小せよ」としか頭に無いらしい

　キーフレームが適切にあればあるほど、圧縮率が上がる以上に
　編集がしやすくなる、倍速がより美麗且つ適正に見えるとしたメリットを得るのだが
　どうにもそこまでの意図を持って取り組んでいる様子は伺えない


＞　多分、本気で取り込もうとすると、ＡＩを活用せざるを得ないのだろう
＞　すると、オープンソースとしてのスタイルを維持することが難しくなる
＞　その時の打開策としては、特定ハードに対応させることでオープンソース化は維持できるにせよ
＞　コスト次第では、エンコード上のネックになりかねない（プロ向けのオプションの類に陥る）