x264(constrained-intra)

このページの全ては誤っているかもしれません。x264関連の記事に関してを読んでください。

x264(constrained-intra)

r1279でコミットされた--constrained-intra（制約付きintra）の概説。

どうやら巷にはconstrained-intraの日本語解説が殆ど無いようで、当サイトのchangelog日本語訳に書いてあるものを検索で引っかけてくる人が時々いる。一般ユーザにとってそれほど重要な項目ではないが大雑把に解説してみたい。

実際のところ、記事の大部分がSVCとスケーラビリティの説明になっているが気にしない。

 一般ユーザ向けの結論

使用すべきではない。使用した場合には、圧縮率が悪くなる。以上。

もう少し述べるなら、constrained-intraを使用すると、intra予測の一部（interブロックを参照するintra予測）が無効になり、そのため圧縮率が低下する。そしてconstrained-intraが使用されているというフラグがPPSに立つ。内部的にはそれだけのことだ。

オプションの目的は、SVC(Scalable Video Coding)という、主にストリーミング配信用のH.264/AVCの拡張規格に必要な制限を行うことにある。しかしこのオプションだけでx264がSVC準拠のスケーラブルな出力をするわけでもないので、x264をベースにSVCの実装を考えようという研究者・開発者以外には無意味だ。

以下、SVCとは何であって、そのためになぜconstrained-intraが必要なのか、を解説する。キレイに小さくエンコードできればそれでいい人には関係ない話で、映像圧縮技術オタクの好奇心を満たす意味しかないので注意。

 SVC(Scalable Video Coding)とは

まずはSVCについて知らなければ、なぜconstrained-intraの様なあまりメリットのないオプションが追加されたのか、理解できないだろう。

SVCは文字通りスケーラブルな映像圧縮を行うための規格で、その呼び名はHigh profileになる前のFRExt(Fidelity Range Extensions)のようなものだ。基本的にはH.264/AVCの機能をそのまま使用するのだが、数多くある機能の中でスケーラビリティに影響を及ぼす項目を整理し、必要な制約やフォーマットを追加の規格として定める目的がある。

コンセプトとしては、ビットストリームを情報深度別に「レイヤ」に分割し、それらのサブセットビットストリームのパケットを取捨選択することで、容易にスケーラビリティを実現できる規格になっているらしい。骨格情報を収めるサブセットをbase layer（基本レイヤ）、追加情報を収めるサブセットをenhancement layer（強化レイヤ）と呼ぶようだ。

「スケーラブル」とは

SVC自体の意味は、上記の説明で、分かる方には分かると思われる。分かったような分からないような説明だと思う方は、恐らく「スケーラブル」とはどういうことかがイメージしづらいのだろう。

英語のscaleを辞書で調べると、「基準、物差し、尺度、階級、縮尺、規模」などの意味がある。「規模」に関しては日本語の中でも「スケールが大きい」などと普通に使用されている。「スケーラブル」とはその規模、縮尺等が可変であることを指している。

映像データで規模や縮尺と呼べそうなものは、解像度、フレームレート(FPS)、データサイズや画質等がある。1つの圧縮映像データからこれらを容易に切り替えることができる機能・能力が「スケーラビリティ」と呼ばれる。

少し正確ではないが、少しデジタル動画に詳しい方に分かりやすい例を挙げるなら、音声圧縮規格のAACにはHE-AAC(aacPlus)が存在することで、スケーラブルであるといえる。HE-AACはHE-AACで使用する補完用のデータを、AACのパディング部（意味のないデータ領域で無印のAACでは無視される領域）に書き込むことで後方互換性を確保している。これを逆に理解すると、受信側の能力を見越してAACのパディング部を付ける・付けないの選択をすれば、データ量とサンプリング周波数の切り替えが実現可能ということだ。

実際にはこのHE-AACのフォーマットは後方互換性が主目的であるし、切り替えも2段階でしか行えず、スケーラビリティと呼ぶには若干貧相だ。しかし「スケーラブル」の意味は理解しやすい例だと思う。

例えばYouTubeを代表とする各動画投稿サイトでは、映像の解像度やビットレートを選択できる機能が実装されてきている。現在のこれらの機能は、それぞれの設定用に別途エンコードをしている例が殆どだろう。結果として1つの映像につき、解像度やビットレート毎に複数のファイルを持っていることになる。SVCが普及すれば、1度のエンコード、1つの完成ファイルで複数の解像度、ビットレートに対応可能になる。

SVCにおけるconstrained-intraの目的

constrained-intraの機能自体は冒頭で述べたとおりで、他には特に何もない。H.264規格書のPPSの定義ではconstrained_intra_pred_flagとしてフラグが存在するが、ざっと見たところではその目的を記述した箇所は見つけられなかった。

x264ではr1279でconstrained-intraが適用されたわけだが、大分以前にx264のMLで言及されている。そしてその続きを読むと、IEEEの文書（なぜIEEEなのかは謎だが）らしきものが引用されている。これを見る限りは、SVCの規格としてconstrained-intraの使用が規定されているとのことで、その目的は動き補償を1パスで終了させる（負荷軽減）ことにあるらしい。これによってMPEG-2, H.263, MPEG-4 Visualのいずれのscarable profilesよりもオーバーヘッドが小さくなる、とも引用文中にある。

確かにinterブロックに依存したintra予測を行うのでは、動き補償の後にintra予測を適用する必要があり、2段構成になるが、intra予測は動き補償の範疇に入るのだろうか。SVCには通常のプロファイルと同等の複雑性と画質で…という前提もあるので、負荷軽減という目的自体は一見納得できそうではある。が、よく考えるとconstrained-intraを強制したら同等の画質にはならない。あぁ、それともサイズは増えてもよいという前提なのだろうか。しかしそれでは「同等の画質」を標榜する意味がないと思うのだが。

さらにAdvanced Concepts for Intelligent Vision Systemsによると、intraパーティションのinterパーティションへの依存が、「パケットの取捨選択等によるスケーラビリティ」への障害になる、ということらしい。そしてそれは、特にCAVLCで問題であることが指摘されている。

x264とconstrained-intraとSVC

目的や機能はともかくとしても、規格で定まっている以上、x264をSVCに対応させるには実装するしかない。しかし一般ユーザにメリットがない機能をx264の開発陣は実装しようとしないだろう。r1279のchangelogに「匿名希望のメディアストリーミング会社によるスポンサード」とあるのは、動画サイト会社が自己利用のためにDark Shikari氏にアルバイトを依頼した、ということだとも理解できる。

さらに推測をすると、特定のSVC対応ソフト・機器では、実質的にSVCを利用しない場合でも、このフラグが必要だったのかもしれない。constrained-intraへの対応自体は、SVC準拠に対する必要条件ではあっても、恐らく十分条件ではないはずだ。他にも制約が多々あるはずだし、そもそもx264はSVCのレイヤに対応したスケーラブルなビットストリームを出力しない。中途半端にconstrained-intraにだけ対応するというのは、これによってx264の出力するビットストリームに非対応であったソフト・機器になんとかしてx264の出力を食わせるためではないかと思われる。

SVCの詳細

せっかくなので、SVGの詳細を少し書いておく。基本的に英語版WikipediaのSVCの項目から引っ張ってきた。Wikipediaかよ、と思うだろうが正確性・網羅性はそれほど重要ではないと思っているのでご了承願いたい。

SVCはH.264のAnnex Gとして規定され、以下の3つの新たなプロファイルを導入する。

• Scalable Baseline Profile
  • 主にビデオ電話やモバイル通信、観察・監視カメラ向け。
  • base layerは既存のBaseline Profileに制約を加えたサブセット。
  • enhancement layerではLevelによってBスライスや重み付き予測、CABAC、8x8もサポート。
  • 空間的スケーラビリティには制限あり。
• Scalable High Profile
  • 主に放送、配信、ビデオ会議向け。
  • base layerでも既存のHigh Profileの機能が使用できる。
  • SVCの全機能が使用可能でスケーラビリティに制約なし。
• Scalable High Intra Profile
  • プロ用途向け。
  • IDRしか使用できないことを除けばScalable High Profileと同じ。

SVCの実現するスケーラビリティは以下の項目に分類される。

• Temporal(frame rate)
  • フレームレートの変更機能による時間軸のスケーラビリティ。
  • 既にH.264/AVCで実現されており、SVCは付加的な情報を提供するに過ぎない。
• Spacial
  • 解像度の変更機能による空間軸のスケーラビリティ。
  • 低解像度向けのデータを高解像度向けデータが補完することでデータ量を節約。
• SNR/Quality/Fidelity
  • ビットレートの変更機能による品質面のスケーラビリティ。
  • Spacial同様、低画質向けのデータを高画質向けデータが補完することでデータ量を節約。

Temporalは、VFR（Variable Frame Rate）に含まれる概念ではあるが、巷で言うVFRとはニュアンスが違う点に注意。世間で言うVFRは殆どの場合、元々フレームレートが一定でない映像を、静的に（総フレーム数と表示タイミングが決定した状態で）エンコードする機能のことを指している。完成したデータを再生する場合は、（処理落ちは別として）常に同じ総フレーム数が再生されることを前提としている。これに対してSVCでは、再生側の回線速度やデコード能力に応じて、送信するデータのフレーム数を動的に変更することが可能だ。SVCのTemporalに従いエンコードされたビットストリームには「削除可能フレーム」があり、そのフレームのデータを削除しても、フレームをスキップするだけで映像は破綻しない。実際のところ、b-pyramidなしでエンコードされたBフレームがこれになるのだろう。

 余談

ユーザには意味のないオプションのために4時間もかけてこの記事を書いてしまった。これだから技術オタクは…。