変調・符号化#127

宇宙向け動画圧縮 — 動き補償予測とフレーム構造のトレードオフ

静止画の空間的冗長性の圧縮から一歩進み、動画のフレーム間の類似性(時間的冗長性)を使う動き補償予測を学ぶ。I/P/Bフレーム構造の圧縮率・誤り耐性トレードオフと、宇宙リンクではなぜシンプルな構造が好まれるかを考える。

前提知識: CCSDS画像圧縮標準 — ウェーブレット変換とビットプレーン符号化でデータ量を減らす

動画圧縮動き補償CCSDSフレーム構造深宇宙通信

この回で学ぶこと

前回の CCSDS画像圧縮標準 では、1枚の静止画像の中にある空間的な冗長性――隣接する画素同士がよく似ているという性質――を、離散ウェーブレット変換とビットプレーン符号化によって取り除く方法を学びました。これは画像1枚を単独で圧縮する話であり、画像が何枚あっても、それぞれは独立に圧縮されていました。

しかし探査機が撮影するのが「1枚の静止画」ではなく「連続する動画のフレーム列」だったらどうでしょうか。たとえば着陸機が降下中に撮影する連続画像や、将来の有人ミッションでの船外活動(EVA)の映像を考えてみてください。動画を構成する連続フレームは、前のフレームと次のフレームでほとんどの部分が変化しません。カメラが静止していれば背景はまったく同じですし、カメラが動いていても、多くの物体はフレーム間でわずかに位置がずれるだけで、形や明るさそのものはほぼ保たれます。

この回で扱うのは、この時間方向の冗長性――連続するフレーム同士が似ているという性質――を利用して、動画をさらに圧縮する技術です。中心となるのは動き補償予測(Motion Compensation, MC)という考え方で、これは「今のフレームをゼロから符号化する」のではなく「直前のフレームを、物体の動きに合わせてずらしたものを予測値とし、その予測が外れた分(残差)だけを符号化する」という発想です。この発想から、Iフレーム・Pフレーム・Bフレームという3種類のフレームタイプが生まれ、それぞれ圧縮率とエラー耐性のあいだに異なるトレードオフを持ちます。そして最後に、地上の動画配信とは事情がまったく異なる宇宙リンク特有の制約――パケットロスに対する脆弱性、そして光速そのものが生む伝搬遅延――が、宇宙用途での動画圧縮の設計判断にどう効いてくるかを見ていきます。

直感的導入: 空間的冗長性から時間的冗長性へ

前回学んだ空間的冗長性の除去を、もう一度別の角度から言い換えてみましょう。1枚の画像の中では、ある画素の値は隣の画素の値からだいたい予測できます。ウェーブレット変換は、この「予測できてしまう部分(低周波成分)」と「予測できない部分(高周波成分、エッジなど)」を分離し、予測できない部分だけに符号化のビットを集中投下する仕組みでした。

動画の場合、この「予測できてしまう部分」は空間方向だけでなく時間方向にも大量に存在します。時刻 t1t-1 のフレーム I(x,y,t1)I(x, y, t-1) が分かっていれば、時刻 tt のフレーム I(x,y,t)I(x, y, t) の大部分は、実は I(,,t1)I(\cdot, \cdot, t-1) とほとんど同じ値です。厳密に言えば「同じ場所に同じ値」ではなく「近くの場所に同じ値」であることが多い――物体が画面上をわずかに移動しているからです。

そこで動画圧縮のアイデアは単純です。フレームをそのまま符号化するのではなく、直前のフレームからの「差分」だけを符号化する。ただし単純な差分 I(x,y,t)I(x,y,t1)I(x,y,t) - I(x,y,t-1) を取るだけでは、物体が動いている領域で大きな差分(≈予測失敗)が出てしまいます。そこで、差分を取る前に「物体がどの方向にどれだけ動いたか」を推定し、その動きの分だけ直前のフレームをずらしてから差分を取る。これが動き補償予測です。ずらす量(動きベクトル)さえ正しく推定できれば、静止した背景はもちろん、動いている物体についても差分(残差)はほぼゼロに近くなり、符号化すべき情報量が劇的に減ります。

動き補償予測の数式的定式化

画像の輝度を、位置 (x,y)(x, y) と時刻(フレーム番号)tt の関数 I(x,y,t)I(x, y, t) として表します。動き補償予測の基本的な仮定は、フレーム間で物体の見た目(輝度パターン)は変わらず、位置だけが平行移動する、という**輝度一定の仮定(brightness constancy assumption)**です。

I(x,y,t)I(xvx,yvy,t1)I(x, y, t) \approx I(x - v_x, y - v_y, t-1)

ここで (vx,vy)(v_x, v_y) が、位置 (x,y)(x, y) にある画素(あるいはその画素を含むブロック)が、時刻 t1t-1 から tt にかけて移動した量を表す動きベクトルです。実際の符号化では、画像全体を N×NN \times N 画素程度の小さなブロックに分割し、ブロックごとに1つの動きベクトルを推定します(これをブロックマッチングと呼びます)。あるブロック BB について、直前フレーム内で最もよく一致する位置を探索し、

(vx,vy)=arg min(vx,vy)S(x,y)BI(x,y,t)I(xvx,yvy,t1)(v_x, v_y) = \operatorname*{arg\,min}_{(v_x, v_y) \in S} \sum_{(x,y) \in B} \big| I(x, y, t) - I(x - v_x, y - v_y, t-1) \big|

のように、絶対誤差和(Sum of Absolute Differences, SAD)を最小にする (vx,vy)(v_x, v_y) を、探索範囲 SS の中から選びます。この最適化はブロックごとに独立に行われるため、動画全体では画面上の位置ごとに異なる動きベクトルの場(モーションフィールド)が得られます。

動き補償予測が得られたら、実際に符号化して送るのは元のフレーム I(x,y,t)I(x,y,t) そのものではなく、予測値との**残差(予測誤差)**です。

e(x,y,t)=I(x,y,t)I(xvx,yvy,t1)e(x, y, t) = I(x, y, t) - I(x - v_x, y - v_y, t-1)

予測がうまくいっている(=推定した動きベクトルが実際の動きをよく捉えている)領域では、e(x,y,t)e(x,y,t) はほぼ0に近い値ばかりが並ぶ、非常にスパース(疎)な信号になります。そして、この残差 e(x,y,t)e(x,y,t) こそが、前回学んだ空間符号化の技術(ウェーブレット変換やDCT、ビットプレーン符号化など)の入力になります。つまり動き補償予測は、空間符号化を置き換えるものではなく、空間符号化にかける前段階として、時間方向の冗長性をあらかじめ絞り込んでおく前処理だと理解するのが正確です。実際に送信されるデータは、大まかに次の3つの要素から構成されます。

符号化データ={(vx,vy)}各ブロック動きベクトル場 + Encode(e(x,y,t))残差の空間符号化\text{符号化データ} = \underbrace{\{(v_x, v_y)\}_{\text{各ブロック}}}_{\text{動きベクトル場}} \ + \ \underbrace{\text{Encode}\big(e(x,y,t)\big)}_{\text{残差の空間符号化}}

動きベクトル場自体もデータ量を持ちますが、典型的なブロックサイズ(たとえば16×16画素)であれば、1ブロックあたり数ビット〜十数ビット程度の動きベクトル情報で済み、そのブロックに含まれる数百画素分の残差符号化ビット数を大幅に減らせるなら、全体として大きな圧縮効果が得られます。

なお、輝度一定の仮定はあくまで近似です。照明条件の変化、物体の回転や変形、オクルージョン(ある物体が別の物体に隠れる/現れる)が起きる領域では、どれだけ動きベクトルを工夫しても予測は外れ、残差 e(x,y,t)e(x,y,t) は大きな値を持ちます。そのような領域は結局、空間符号化の側で多くのビットを使わざるを得ません。動き補償予測がもたらす圧縮効果は、あくまで「シーンの中でどれだけの割合が単純な平行移動でうまく予測できるか」に依存する、というのは覚えておくべき限界です。

フレームタイプ: I・P・Bフレームとその構造

動き補償予測を使うかどうか、使うとしてどのフレームを参照するかによって、動画符号化では大きく3種類のフレームタイプが定義されます。

Iフレーム(Intra-coded frame, 独立符号化フレーム) は、他のどのフレームも参照せず、そのフレーム単体の空間的冗長性のみを使って圧縮されるフレームです。これはまさに前回学んだ静止画圧縮(CCSDS 122.0-B的なウェーブレット圧縮、あるいはJPEG的なブロックDCT圧縮)そのものであり、動き補償予測は一切使いません。数式で言えば、単純に

符号化データI=Encode(I(x,y,t))\text{符号化データ}_I = \text{Encode}\big(I(x, y, t)\big)

です。他のフレームに依存しないため圧縮率は相対的に低い(=データ量が大きい)一方、そのフレーム単独で完全に復元できるという強い独立性を持ちます。

Pフレーム(Predictive-coded frame, 順方向予測フレーム) は、前節で見た動き補償予測を使い、過去の1枚のフレーム(直前のIフレームまたはPフレーム)だけを参照して予測するフレームです。

符号化データP={(vx,vy)}+Encode(e(x,y,t)),e(x,y,t)=I(x,y,t)I(xvx,yvy,t1)\text{符号化データ}_P = \{(v_x, v_y)\} + \text{Encode}\big(e(x,y,t)\big), \qquad e(x,y,t) = I(x,y,t) - I(x - v_x, y - v_y, t-1)

前フレームとの類似性が高いシーンほど残差が小さくなり、Iフレームよりもはるかに少ないデータ量で符号化できます。ただしPフレームは、参照する過去フレームが正しく復元されていることが前提になるため、その過去フレームにエラーがあれば、そのエラーがPフレームにもそのまま伝わってしまいます(誤り伝搬)。

Bフレーム(Bidirectionally predictive-coded frame, 双方向予測フレーム) は、Pフレームをさらに発展させ、過去と未来の両方のフレームを参照して予測します。

e(x,y,t)=I(x,y,t)[αI(xvx(),yvy(),tpast)+(1α)I(xvx(+),yvy(+),tfuture)]e(x,y,t) = I(x,y,t) - \Big[\alpha \, I(x - v_x^{(-)}, y - v_y^{(-)}, t_{\text{past}}) + (1-\alpha)\, I(x - v_x^{(+)}, y - v_y^{(+)}, t_{\text{future}})\Big]

過去方向の動きベクトル (vx(),vy())(v_x^{(-)}, v_y^{(-)}) と未来方向の動きベクトル (vx(+),vy(+))(v_x^{(+)}, v_y^{(+)}) をそれぞれ推定し、両者を(単純平均、あるいは重み α\alpha による加重平均で)ブレンドした予測値との残差を符号化します。未来のフレームを参照するには「未来のフレームが先に符号化されている」必要があるため、実際の符号化順序は時間的な表示順序とは異なり、未来側の参照フレーム(多くはPフレーム)を先に符号化してから、それに挟まれたBフレームを後で符号化する、という並べ替えが発生します。Bフレームは前後2方向の情報を使えるぶん、一般にPフレームよりもさらに残差を小さくでき、圧縮率が最も高いフレームタイプです。しかし、その分だけ依存関係が複雑になり(過去フレームと未来フレームの両方が正しく届いていないと復元できない)、誤り耐性は3種類の中で最も低くなります。

まとめると、3種類のフレームタイプは次のようなトレードオフの上に並んでいます。

フレームタイプ参照するフレーム圧縮率誤り伝搬への耐性
Iフレームなし(独立)低い高い(単独で自己完結)
Pフレーム過去1枚中程度中程度(過去フレームの誤りが伝搬)
Bフレーム過去・未来高い低い(2方向の依存が誤りを増幅)

地上の動画配信(ストリーミング、放送、Blu-rayなど)では、この3種類を組み合わせたGOP(Group of Pictures)構造――たとえば I, B, B, P, B, B, P, … のような周期的パターン――を採用し、圧縮率を最大化するのが一般的です。

宇宙リンク特有の制約: なぜシンプルな構造が好まれるか

ここまでの議論は、地上のネットワークでも宇宙リンクでも数学的には同じです。しかし、どのフレーム構造を実際に選ぶかという設計判断になると、宇宙リンクには地上の動画配信とは大きく異なる事情があります。

第一に、パケットロスの発生様式と頻度が違います。地上の光ファイバー網でのパケットロス率は極めて低く、ロスが起きても再送(TCP的な仕組み)で埋め合わせることが比較的容易です。一方、深宇宙リンクは信号電力が極めて弱く、雑音との戦いの中でビット誤りやフレーム単位のロスが避けられません。加えて、往復伝搬遅延が数分〜数十分に達する遠距離リンクでは、地上のようなリアルタイム再送はほぼ不可能です(再送を要求しても、その要求が届く頃には元の送信機会はとうに過ぎています)。

第二に、これが本質的に重要な点ですが、BフレームやPフレームの依存構造は、ロスに対する脆弱性を増幅させます。1つのIフレームが失われれば、そのフレーム単体は復元できませんが、後続のフレームが別のIフレームから正しく再スタートすれば、そこで影響は止まります。しかし、あるPフレームが失われると、そのPフレームを参照する後続のPフレーム・Bフレームすべてが芋づる式に復元不能になります。Bフレームはさらに、未来方向の参照が失われるだけでも予測が破綻するため、依存関係のネットワークとしては最も脆いフレームタイプです。地上配信であれば「次のIフレームが来るまで数秒間、映像が乱れる」程度で済むかもしれませんが、探査機の科学的・工学的に貴重な、しかも1回しか送られてこないかもしれない映像でこれが起きると、致命的なデータ損失になります。

この2つの事情から、宇宙用途の動画符号化では、地上配信ほど積極的にBフレームを使わず、Iフレームの比率を高めに保つ、あるいはPフレームまでに留めてIフレーム中心の構造にする、という設計判断がしばしば取られます。圧縮率だけを追求すればBフレームを多用したいところですが、宇宙リンクでは「多少データ量が大きくなっても、1つのロスがどこまで被害を広げるかを限定できる」ことの価値のほうが高く評価されるのです。これは、前々回までに学んだ通信路符号化(誤りに強く送る)と情報源符号化(データ量を減らす)の話とはまた別の軸で、「圧縮構造そのものが持つ誤り耐性」という設計変数が動画特有の問題として登場した、と捉えることができます。

実務での使われ方

国際宇宙ステーション(ISS) では、船内外の様子を伝える動画伝送が日常的に運用されています。ISSは低軌道(高度約400 km)にあり、往復の伝搬遅延はミリ秒〜1秒程度とごくわずかで、TDRSS(Tracking and Data Relay Satellite System、NASAの中継衛星網)などを経由して、地上との間でほぼリアルタイムに近い映像のやり取りが可能です。ISSではH.264/AVCなど地上でも広く使われる動画符号化方式が採用されており、比較的高いリンク容量を活かして、船外活動の中継や記者会見的なダウンリンクなど、地上の動画配信に近い運用が行われています。ただし、リンクの瞬断や輻輳が起きた際の映像劣化を抑えるため、GOP構造やビットレート制御には地上配信よりも保守的なマージンを取る運用がなされています。

一方、将来の月・火星有人ミッションでは、事情が大きく変わります。月であれば地球との往復伝搬遅延は約2.6秒程度で、多少の遅延はあるもののほぼリアルタイムに近い運用が可能です。NASAのアルテミス計画などでは、月面活動の様子を高精細映像でリアルタイムに近い形で地球へ伝送する需要が見込まれており、ISSと同様、地上に近い動画符号化技術(高効率なH.265/HEVCなど、より新しい規格を含む)の適用が検討されています。

しかし火星となると話はまったく違います。地球と火星の距離は、両者の軌道配置によって約5,500万km(最接近時)から約4億km(最遠時)まで変動し、電波(光速 c3×105c \approx 3 \times 10^5 km/s)の片道伝搬遅延はおよそ3分〜22分にもなります。往復では約40分に達することもあります。つまり、火星にいる宇宙飛行士や探査機からの映像を地球で「リアルタイムに見る」ことは、通信技術の性能をどれだけ向上させても、光速という物理法則そのものによって原理的に不可能です。地球側が映像を受信した時点で、それはすでに数分〜十数分前の過去の出来事であり、双方向の対話的なやり取り(たとえば地上管制官が映像を見ながらリアルタイムで指示を出す、といった運用)は成立しません。

この制約のもとでは、火星ミッションにおける「動画」は、地上で言うような生放送的な用途ではなく、録画してから、限られたダウンリンク機会にまとめて(あるいは圧縮を最適化した上で)地球へ転送するという運用にならざるを得ません。ここでこそ、この回で学んだIフレーム中心の構造の価値が改めて重要になります。まとめて転送する映像がリンクの途中でロスを受けても被害を局所化できるIフレーム比率の高い構造は、「多少遅れて届いても、届いた範囲は確実に見られる」という火星探査のような長遅延・低信頼リンクの運用哲学によく合致しているのです。

演習問題

  1. あるブロックについて、探索範囲 S={8,,8}×{8,,8}S = \{-8, \dots, 8\} \times \{-8, \dots, 8\}(画素単位)でSADを最小化する動きベクトルを全探索で求めるとき、1ブロックあたり何通りの候補位置を評価する必要があるか計算してください。また、画像全体が16×16画素のブロック256個からなる場合、全ブロックの動きベクトル探索に必要な候補評価の総数を求めてください。
  2. ある動画のあるフレームについて、動き補償予測を使わずに直接Iフレームとして符号化した場合の符号量が1.2 Mbit、動き補償予測を使ってPフレームとして符号化した場合の(動きベクトル場+残差の符号量の合計)が0.3 Mbitだったとします。この場合の圧縮率(Iフレーム比)は何倍か求めてください。またこの圧縮率が、ウェーブレット変換による空間的冗長性の除去(前回学んだCCSDS 122.0-B)による圧縮率と異なるメカニズムに基づいていることを、自分の言葉で説明してください。
  3. GOP構造が I, B, B, P, B, B, P, … のような地上向け動画符号化方式を、そのまま火星探査機からの動画伝送に採用した場合、どのような問題が起こり得るか、この回で学んだ「誤り伝搬」と「長遅延環境」の2つの観点から説明してください。
  4. 火星と地球の距離が最接近時で約5,500万km、最遠時で約4億kmであるとき、それぞれの場合の片道伝搬遅延を光速 c=3.0×105c = 3.0 \times 10^5 km/s を用いて計算してください(秒・分の単位で)。また、この計算結果をもとに、「火星でのリアルタイム動画通話」がなぜ通信技術の進歩によっても実現できないのかを説明してください。

まとめと次回予告

この回では、前回の静止画圧縮(空間的冗長性の除去)から一歩進み、動画のフレーム間に存在する時間的冗長性を利用する動き補償予測を学びました。直前のフレームから動きベクトルの分だけずらした予測値との残差だけを符号化するという発想が、Iフレーム(独立)・Pフレーム(過去参照)・Bフレーム(過去・未来双方参照)という3種類のフレームタイプを生み、それぞれ圧縮率と誤り耐性のあいだに異なるトレードオフを持つことを見ました。そして、地上の動画配信とは異なり、宇宙リンクではパケットロスへの脆弱性と長い伝搬遅延という2つの理由から、Bフレームのような複雑な依存構造よりもIフレーム中心のシンプルな構造が好まれる傾向があること、火星のような長遅延環境では「リアルタイム動画」自体が物理的に成立しないことを確認しました。

次回は、これまで主に電波(RF)による通信を前提に議論してきた話から視点を変え、光通信の世界に踏み出します。レーザーによる光通信は、RFよりもはるかに高い搬送波周波数を使うことで桁違いのデータレートを実現できる技術で、動画のような大容量データの伝送需要とも密接に関わってきます。その変調方式の基礎に軽く触れるところから始めます。

参考文献

  • CCSDS 121.0-B, Lossless Data Compression
  • ITU-T Recommendation H.264, Advanced Video Coding for Generic Audiovisual Services
  • ITU-T Recommendation H.265, High Efficiency Video Coding
  • I. E. Richardson, H.264 and MPEG-4 Video Compression: Video Coding for Next-generation Multimedia, Wiley
  • J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76
  • NASA, Artemis Plan: NASA’s Lunar Exploration Program Overview