モーションイメージリー配信 — 圧縮済み動画を宇宙リンク上でストリーミングするプロトコル設計

この回で学ぶこと

前回は、動画そのものをどう圧縮するかを学びました。動き補償予測によってフレーム間の時間的冗長性を取り除き、Iフレーム・Pフレーム・Bフレームという3種類のフレームタイプの間で圧縮率と誤り耐性がトレードオフの関係にあること、そして宇宙用途ではBフレームのような複雑な依存構造を避け、Iフレーム中心のシンプルな構造が好まれる傾向にあることを見ました。これは、探査機の搭載コンピュータが動画データそのものをどう生成するかという、符号化アルゴリズムのレイヤーの話でした。

しかし、圧縮が終わってビット列ができあがったからといって、それが自動的に地球まで届くわけではありません。圧縮された動画データは、CCSDS宇宙データリンクプロトコルの回で学んだフレーム・仮想チャンネル(VC)の仕組みに乗せてリンク上に送り出す必要があり、しかもその乗せ方には「ファイル転送のように届けるか」「ストリーミングのように届けるか」という設計上の大きな分岐があります。この回で扱うのは、まさにこのプロトコルレベルの話――圧縮済みの動画データを、宇宙リンクの上でどうパケット化し、どう配信し、受信側でどう滑らかな再生に組み立て直すか――です。前回が「データをどう小さくするか」だったのに対し、今回は「そのデータをどう運ぶか」であり、扱うレイヤーがはっきり異なることをまず意識してください。

この回の中心的な問いは、CFDPの回で学んだファイル転送の設計思想と対比させることで見えてきます。CFDPは「1バイトも欠けてはならない」という完全性優先の思想のもとに、欠損があれば往復してでも選択的に再送する仕組みでした。ところが動画のストリーミング配信では、多少のデータ欠損があっても再生を止めずに進めることの方が価値を持つ場面が多くあります。このタイムリーさ優先という正反対の設計思想が、CCSDSのモーションイメージリー規格やジッタバッファといった仕組みにどう具体化されているかを、この回では数式を交えて理解します。

直感的導入: なぜ「完全性」ではなく「タイムリーさ」なのか

具体例で考えてみましょう。ISSの船外活動(EVA)を地上の管制官がライブ映像で見ているとします。ある瞬間の1フレームがリンク上のノイズで欠損したとき、どう振る舞うのが望ましいでしょうか。

CFDP的な「完全性優先」の発想を素直に当てはめるなら、欠損したフレームをNAKで報告し、再送してもらい、それが届くまで再生を止めて待つ、という動作になります。しかし、これは動画の視聴体験としては最悪です。1フレームのために映像全体が数秒間フリーズしてしまえば、視聴している側にとっては「今何が起きているか」というリアルタイム性そのものが損なわれます。むしろ、欠けたフレームは諦めて(あるいは前フレームを引き延ばして誤魔化して)、次に届くフレームから再生を続行する方が、動画という情報の使われ方には合っています。

これが、ストリーミングという配信方式の核心にある発想です。ファイル転送(CFDP)は「最終的に完全な1つの成果物を作ること」がゴールであり、途中経過にはこだわらず、時間をかけてでも完全性を達成しようとします。一方ストリーミングは「今この瞬間に、視聴者(あるいは監視者)が状況を把握し続けられること」がゴールであり、多少の欠損は許容してでも、データの流れを止めないことを優先します。 同じ「宇宙リンク上でデータを届ける」という作業でも、何を最適化するかがまったく違うのです。

この違いは、単なる運用ポリシーの選択ではなく、下位のプロトコル設計そのものに影響します。以下、この設計思想の違いを軸に、CCSDSにおけるモーションイメージリー伝送の枠組み、ジッタバッファ、そして誤り対策の考え方を順に定式化していきます。

定式化1: 完全性とタイムリーさ、2つの最適化問題

CFDPと動画ストリーミングの違いを、もう少し形式的に整理しておきましょう。CFDPが解いている最適化問題は、大まかに次のように書けます。

$$\text{CFDPの目標:} \quad \min_{\text{再送回数}} \ \mathbb{E}[\text{完了までの時間}] \quad \text{subject to} \quad P(\text{最終的に完全) } = 1$$

制約条件は「最終的に完全であること」であり、その制約を満たす限り、完了までにどれだけ時間がかかってもよい(往復を繰り返してでもよい)、というのがCFDPの回で見た選択的再送の設計思想でした。

これに対して、ストリーミング配信が解いている問題は、次のような形になります。

$$\text{ストリーミングの目標:} \quad \max_{\text{配信方式}} \ Q(\text{再生品質}) \quad \text{subject to} \quad t_i^{\text{play}} \le t_i^{\text{deadline}} \ \ (\forall i)$$

ここで $t_i^{\text{play}}$ はフレーム $i$ が実際に再生される時刻、$t_i^{\text{deadline}}$ はそのフレームが再生されるべき締め切り時刻です。制約はもはや「完全性」ではなく「締め切りに間に合うこと」であり、締め切りに間に合わなかったデータは、たとえ後から届いたとしてももはや価値を持たないという前提に立ちます。この「締め切りを過ぎたデータは無価値」という一点が、ストリーミング配信のプロトコル設計を、ファイル転送とはまったく異なる方向に導いていきます。

定式化2: ジッタバッファ — 揺らぐ到着タイミングを吸収する

送信側は動画のフレームを、本来は一定の間隔(たとえばフレームレート30 fpsなら $T_f = 1/30$ 秒ごと)で生成しています。しかし、それがリンクを通って受信側に届くまでの遅延は、フレームごとに揺らぎます。この到着タイミングの揺らぎを**ジッタ(jitter)**と呼びます。

ジッタが生じる主な要因は、宇宙リンク特有の事情から来ています。

• フレームサイズの変動。 前回学んだ通り、Iフレームはそのフレーム単体の情報量が大きく、Pフレームは残差だけなので情報量が小さい傾向にあります。物理チャンネルのビットレート $R$ が一定だとすると、サイズ $L_i$ ビットのフレーム $i$ を送り出すのに要する時間はおよそ $L_i / R$ であり、$L_i$ がフレームごとに変動するぶん、送出にかかる時間も変動します。
• 仮想チャンネルの帯域競合。 宇宙データリンクプロトコルの回で見た通り、1本の物理リンクの上には複数のVC(リアルタイムテレメトリ、プレイバックデータ、科学データなど)が時分割で相乗りしています。動画用のVCのフレームが、優先度の高い他のVCのフレームの後ろに一時的に並んでしまえば、その分だけ到着が遅れます。

受信側でこの揺らぎを吸収する仕組みがジッタバッファです。基本的な考え方は単純で、受信したフレームをすぐに再生せず、いったん一定時間 $D$ だけバッファに溜めてから再生することで、多少遅れて届いたフレームでも「まだ再生時刻に間に合っている」状態を作り出します。フレーム $i$ の生成時刻を $t_i^{\text{gen}}$、受信時刻を $t_i^{\text{rx}}$ とすると、再生時刻は

$$t_i^{\text{play}} = t_i^{\text{gen}} + D$$

と設定されます。このとき、あるフレームが再生に間に合うための条件は

$$t_i^{\text{rx}} \le t_i^{\text{play}} = t_i^{\text{gen}} + D \quad \Longleftrightarrow \quad \delta_i \le D, \qquad \delta_i \equiv t_i^{\text{rx}} - t_i^{\text{gen}}$$

と書けます。$\delta_i$ はフレーム $i$ の伝送遅延(伝搬遅延+ジッタ由来の変動分)です。$\delta_i$ を何らかの確率分布に従う確率変数とみなすと、バッファ深さ $D$ を大きくとるほど「間に合わない(アンダーラン)」確率

$$P(\text{アンダーラン}) = P(\delta_i > D)$$

は小さくなります。しかしバッファ深さ $D$ を大きくすることは、生成から再生までのエンドツーエンド遅延がそのまま $D$ だけ増えることも意味します。ここに、再生の滑らかさ(アンダーラン確率を下げたい)と、リアルタイム性(遅延を短くしたい)のトレードオフが現れます。地上のインターネット動画配信では $D$ はたかだか数百ミリ秒〜数秒程度に抑えられますが、これは地上の伝搬遅延・ジッタがそもそも小さいために可能なことです。宇宙リンクでは、この後の節で見るように、この前提が大きく崩れます。

定式化3: なぜストリーミングでは再送(ARQ)ではなくFECが好まれるか

CFDPの回では、欠損したデータをNAKで報告し、その部分だけを選択的に再送するARQ(Automatic Repeat reQuest、自動再送要求)方式が、対数オーダーの往復回数で効率的に完全性を達成できることを見ました。ここで自然な疑問が浮かびます。ストリーミングでも同じように、欠けたフレームをNAKで報告して再送してもらえばよいのではないか。

答えは「場合による」であり、その分かれ目はジッタバッファの深さ $D$ と、リンクの往復伝搬遅延(RTLT)の大小関係にあります。ARQによる再送が意味を持つのは、再送を要求してから再送データが届くまでの時間が、まだ再生締め切りに間に合う場合、つまり

$$\text{RTLT} \lesssim D$$

が成り立つ場合に限られます。地上のインターネットでは、典型的なRTTは数十ミリ秒程度なので、ジッタバッファを数百ミリ秒程度に取れば、1回の再送要求ならぎりぎり間に合わせられる場合があります(実際、一部の映像会議システムはこの原理でNACKベースの部分再送を行っています)。

しかし宇宙リンクではこの前提が根本から崩れます。CFDPの回で見たように、火星との往復光時間(RTLT)は約8分から48分、木星以遠ではさらに長くなります。ジッタバッファの深さをこの時間スケールまで引き伸ばすことは、事実上「ライブ視聴」であることを放棄するのと同じです。つまり、火星のような長遅延リンクでは、ARQによる再送はストリーミングの再生締め切りに原理的に間に合わない――これは前回学んだ「火星でのリアルタイム動画通話は光速という物理法則によって不可能」という結論の、プロトコル設計への直接の帰結です。

この制約のもとで、ストリーミング用途が代わりに頼るのが**FEC(Forward Error Correction、前方誤り訂正)です。ARQが「欠損を検出してから、事後的に再送を要求する」という反応的(リアクティブ)な誤り対策であるのに対し、FECは「あらかじめ冗長な情報を付加しておき、多少の欠損があっても受信側だけで訂正できるようにする」という予防的(プロアクティブ)**な誤り対策です。往復のやり取りを一切必要としないため、RTLTがどれだけ長くても原理的に機能します。宇宙データリンク層ではすでに畳み込み符号やLDPC符号、Reed-Solomon符号といったFECが標準的に使われていますが、モーションイメージリー配信ではさらに、動画の符号化構造そのものをFEC的に振る舞わせる工夫が加わります。

定式化4: パケット化戦略とIフレーム中心設計の再接続

前回、宇宙用途の動画符号化ではBフレームのような複雑な依存構造を避け、Iフレーム中心の構造が好まれると学びました。この判断は符号化アルゴリズムのレイヤーでの話でしたが、プロトコルのレイヤーでも同じ発想がもう一段具体化されます。

ストリーミング用のパケット化では、次の2つの設計原則が組み合わされます。

1. フレーム境界とパケット境界をできるだけ一致させる。 1つのフレームのデータが複数のパケットにまたがる場合でも、あるパケットの欠損の影響が、そのフレーム(とそれに依存する後続フレーム)の範囲を超えて広がらないように、パケット化の単位をフレーム(あるいはフレーム内の独立に復号可能な小さな領域、スライス)に揃えます。
2. 周期的なIフレームを「再同期点」として機能させる。 Pフレームの中でどこかのパケットが欠損すると、そのPフレームは正しく復元できず、それを参照する後続のPフレームにも誤りが伝搬します(前回の「誤り伝搬」の議論そのものです)。しかし、一定間隔で挿入されるIフレームは他のフレームに依存しないため、そのIフレームから正しく届けば、そこで誤り伝搬の連鎖が断ち切られ、映像は自動的に「立て直り」ます。

この2つを合わせると、ストリーミング配信全体の劣化の振る舞いは、次のように描写できます。あるパケットが欠損すると、その影響は次の(独立に復号可能な)Iフレームが届くまでの間だけ残り、Iフレームの到着とともにリセットされます。Iフレームの挿入間隔を $T_{GOP}$(GOP長に相当する時間)とすると、パケット欠損1回あたりの映像劣化の持続時間はおおむね $T_{GOP}$ 以下に収まります。$T_{GOP}$ を短くするほど劣化からの復帰は速くなりますが、Iフレームはデータ量が大きいぶん、全体のビットレートは増加します。これは前回見た圧縮率と誤り耐性のトレードオフが、GOP長というパラメータを通じて、ストリーミング配信の「劣化からの回復速度」というプロトコルレベルの指標に姿を変えて再登場したものだと理解できます。

CCSDSにおけるモーションイメージリー規格の位置づけ

以上の設計思想は、CCSDSにおいてもモーションイメージリー(Motion Imagery)関連の一連の勧告書として具体化されています。中心となるのが CCSDS 766.1-B, Video Coding(動画符号化そのものを規定するブルーブック、前回の内容に対応する層)と、その配信・応用面での考え方を整理した CCSDS 766.2-G, Motion Imagery and Applications(グリーンブック、情報提供文書)です。

これらの規格は、動画・音声のようなストリーミング指向のデータを、宇宙データリンクプロトコルの回で学んだ仮想チャンネル(VC)の枠組みの中に位置づけます。具体的には、動画データ専用のVCを1本(あるいは映像・音声で別々に)割り当て、そのVCの中でIフレーム中心のGOP構造に沿ってパケット化されたデータを、途切れることなく連続的に送り続ける、という運用形態が取られます。これは、宇宙データリンクプロトコルの回で見た「リアルタイムテレメトリ用VC」「プレイバックデータ用VC」と並ぶ、もう1つのVCの使い道です。ただし優先度づけの観点では、動画VCは多くの場合、姿勢制御や機体健全性に関わるハウスキーピングテレメトリよりも優先度は低く設計されます。動画が一時的に乱れても運用上致命的にはなりませんが、姿勢テレメトリの欠落は探査機の安全に直結しうるためです。

地上での対応物としては、動画・音声のリアルタイム配信を担う RTP (Real-time Transport Protocol, RFC 3550) があります。RTPも、シーケンス番号による並べ替えとタイムスタンプによる再生タイミング制御を提供しつつ、欠損したパケットの再送そのものは基本的に行わない(必要なら上位のアプリケーションやNACKベースの拡張に委ねる)という設計になっており、この回で見た「タイムリーさ優先」の思想を地上のインターネットの文脈で体現したプロトコルだと言えます。CCSDSのモーションイメージリー関連規格は、この地上での設計思想を、宇宙リンク特有の長遅延・低信頼性という制約のもとで再構成したものだと捉えると理解しやすいでしょう。

実務での使われ方

国際宇宙ステーション(ISS)。 前回見た通り、ISSは低軌道にあり往復伝搬遅延がミリ秒〜1秒程度と小さいため、TDRSS経由でほぼリアルタイムに近い映像伝送が可能です。この小さいRTTのおかげで、ISSの動画配信システムはジッタバッファを比較的浅く(コンマ秒〜数秒程度)保ったまま運用でき、地上の映像会議に近い、双方向性のある「ライブに近い」体験を実現しています。プロトコルスタックとしては、圧縮された映像・音声ストリームがモーションイメージリー系の枠組みでパケット化され、専用のVCに乗せられて、地上のNASA施設や関連機関のネットワークへ配信されるという構成が取られています。

将来の月面ミッション。 月との往復伝搬遅延は約2.6秒程度と、ISSに比べれば大きいものの、依然として「秒」のオーダーです。ジッタバッファを数秒程度まで広げれば実用上ほぼ問題なく動画配信ができ、アルテミス計画などで検討されている月面活動のほぼリアルタイムな映像伝送は、この規模の遅延を前提にした設計で十分に実現可能だと考えられています。ただし、双方向の対話的なやり取り(たとえば管制官がリアルタイムで細かい指示を映像を見ながら出す)には、数秒の遅延が積み重なることで、地上の電話会議のような滑らかさは失われます。

将来の火星ミッション。 前回確認した通り、火星との通信では片道で数分〜22分、往復で最大約48分もの伝搬遅延があり、「ライブ視聴」は光速という物理法則によって原理的に不可能です。ここでの現実的な設計は、この回で見た2つの技術要素を組み合わせた**「ほぼリアルタイム」配信**です。すなわち、(1) FECによる誤り対策で、往復再送に頼らずとも受信側単独である程度の欠損を訂正・隠蔽できるようにし、(2) Iフレーム中心のパケット化戦略で、訂正しきれない欠損があっても被害をGOP単位に限定する。そのうえで、探査機側で録画してから可視パスでまとめて(あるいは継続的に)地球へ転送し、地上側は受信した範囲から順次再生を開始する、というファイル転送とストリーミングの中間的な運用形態が取られます。これはCFDPのような厳密な完全性保証(1バイトも欠けないことを往復して確認する)とは異なり、多少の乱れは許容しつつ、転送が完了するのを待たずに視聴を始められるという、ストリーミングの発想を非リアルタイムな文脈に応用した設計だと言えます。

演習問題

1. あるミッションのジッタバッファ深さが $D = 2$ 秒に設定されているとします。ISS(往復伝搬遅延ミリ秒〜1秒程度)、月(往復伝搬遅延 約2.6秒)、火星(往復伝搬遅延 約8分〜48分)のそれぞれについて、$\text{RTLT} \lesssim D$ の条件が成り立つかどうかを判定し、ARQ的な再送がジッタバッファの範囲内で間に合うかどうかを論じてください。
2. GOP長 $T_{GOP} = 2$ 秒(Iフレーム挿入間隔)で運用されている動画ストリームで、ランダムなタイミングでパケット欠損が1回発生したとします。この欠損によって映像が乱れる持続時間のおおまかな上限を見積もり、$T_{GOP}$ を半分にした場合とビットレートのトレードオフがどう変化するか、前回の内容を踏まえて説明してください。
3. CFDPの選択的再送(ARQ、NAKベース)と、この回で学んだFECベースの誤り対策を、(a) 往復のやり取りを必要とするか、(b) 長い伝搬遅延への耐性、(c) 追加の冗長データ量、という3つの観点で比較してください。また、なぜCFDPのようなファイル転送にはARQが、動画ストリーミングにはFECがそれぞれ適しているのか、この回の「完全性優先 vs タイムリーさ優先」という枠組みを使って説明してください。
4. 火星ミッションにおける動画配信を、(a) CFDPを使ってファイルとして完全に転送してから再生する方式、(b) この回で学んだストリーミング的な「受信できた範囲から順次再生する」方式、の2通りで比較してください。それぞれの方式で、可視パスの終わり際に一部のデータが欠損した場合に何が起こるかを具体的に説明し、どちらの方式が火星探査の運用によりよく合致するかを論じてください。

まとめと次回予告

この回では、前回学んだ動画圧縮というデータ生成側の話から視点を移し、圧縮済みの動画データを宇宙リンク上でどう配信するかというプロトコルレベルの設計を学びました。中心にあったのは、CFDPの回で見た「完全性優先」の設計思想と、ストリーミングの「タイムリーさ優先」の設計思想の対比です。この違いが、ジッタバッファによる到着タイミングの吸収、ARQではなくFECを基本とする誤り対策、そして前回学んだIフレーム中心の符号化構造を再同期点として活用するパケット化戦略という、具体的な設計判断に一貫して現れていることを確認しました。そして、この設計思想が火星のような長遅延リンクにおいて、「ライブ視聴の放棄」と「ほぼリアルタイムな、しかし完全性は厳密には保証しない配信」という、現実的な妥協点をどう形作っているかを見ました。

次回は、これまで学んできたデータリンクやアプリケーション層のプロトコル群から少し視野を広げ、地上ネットワーク側に目を向けます。探査機との通信は宇宙区間だけで完結せず、地上局からミッション運用センターまでの地上ネットワークを経由して初めてデータが利用可能になります。この地上ネットワークが抱えるサイバーセキュリティの課題について、軽く触れるところから始めます。

参考文献

• CCSDS 766.1-B, Video Coding
• CCSDS 766.2-G, Motion Imagery and Applications
• CCSDS 132.0-B, TM Space Data Link Protocol
• CCSDS 727.0-B, CCSDS File Delivery Protocol (CFDP)
• RFC 3550, RTP: A Transport Protocol for Real-Time Applications
• J. H. Yuen (ed.), Deep Space Telecommunications Systems Engineering, JPL Publication 82-76
• NASA, Artemis Plan: NASA’s Lunar Exploration Program Overview