JP4688873B2 - 予測および非予測データフレームを伝送するための方法および装置 - Google Patents

Description

本発明は、一般の通信システムに関する。具体的には、本発明は、デジタルビデオ放送（ＤＶＢ）技術等のようなデジタルブロードバンドシステムおよびこのシステムに適用するビデオ符号化に関する。

デジタルビデオ放送（ＤＶＢ）とは、衛星放送（ＤＶＢ−Ｓ）、ケーブルテレビ（ＤＶＢ−Ｃ）、または地上波放送（ＤＶＢ−Ｔ）といった配布媒体によるデジタル放送技術を定義する規格のことをいう。この規格は、ソース符号化、チャネル符号化、限定受信方式（有料放送テレビおよびそれに関連するデータスクランブリング方法）、およびその他の様々な問題を対象としたものである。１９９０年代の初めに、欧州の主要な公共および民間のテレビ業界組織によってＤＶＢプロジェクトが設立され、デジタルテレビサービスにＭＰＥＧ−２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）という音声／映像の圧縮基準を導入するための枠組みが作成された。このＤＶＢプロジェクトは、着実にその認知度を上げ、ＤＶＢは、既に世界中で採用されるようになっている。

衛星回線の場合、ＤＶＢ規格（たとえば、下記非特許文献１参照。）には、図１に示す伝送システムが定義されている。この規格は、イントラサービス１０８およびインターサービス１１２によって多重化されたベースバンド（ビデオ１０２、オーディオ１０４、および場合によってはデータ１０６を含む）信号を、複数の処理工程中に衛星チャネルへ適合させる。ここでは、これらの処理工程を総称して衛星チャネルアダプタと呼び、図面では点線１１０で示している。通常、前記ベースバンド信号には、下記非特許文献２によるソース符号化が適応されてきた。

以下の過程がデータストリームに適用される。

多重化アダプテーションおよびエネルギー拡散１１４によるトランスポート多重化アダプテーションおよびエネルギー拡散のためのランダム化、
外部コーダ１１６による外部符号化（コーディング）（すなわちリードソロモンブロックコードによる符号化）、
畳み込みインターリーバ１１８による畳み込みインターリービング、
内部コーダ１２０による内部符号化（すなわちパンクチャード畳み込みコードによる符号化）、
ベースバンド整形１２２による変調のためのベースバンド整形、
ＱＰＳＫ変調器１２４による変調。

ＤＶＢ−Ｓ伝送に関する詳細は、下記非特許文献１およびその中で引用されている文献に記載されている。

また、デジタルビデオ信号のケーブル伝送に関しては、下記非特許文献３においてＤＶＢ−Ｃの構成要素およびその特徴が記載されている。図２は、ケーブルシステムにおける送信方向への主要な機能ブロックを示している。ＢＢインターフェースブロック２０２は、同期バイトによってＭＰＥＧ−２トランスポート層のフレーム構造（固定長パケット）に入力信号を適合させる。同期反転およびランダム化２０４では、いわゆる同期１バイトの反転およびデータストリームのランダム化により、信号の中に十分な数の遷移の発生が確保され、同期化等がより容易になる。その後、ランダム化されたトランスポートパケットに対してリードソロモンＦＥＣ（前方誤り訂正）符号化２０６が実施され、エラーの検出および訂正のためのコードワードが検索される。つぎに、エラー保護されたトランスポートパケットは、畳み込みインターリーバ２０８によってインターリーブされるが、ＤＶＢ−Ｓにおけるような畳み込み符号化はおこなわれない。ステップ２１０においては、インターリーブされたバイトが、ＱＡＭ（直交振幅変調）シンボル（ｍタプル）に変換され、つぎに各シンボルにおける最上位ビット（ＭＳＢ）に対して差分符号化２１２がおこなわれる。ベースバンド整形２１４においては、ｍタプルのＩ軸およびＱ軸へのマッピングと、つぎにルート余弦（コサイン）フィルタ処理と、がおこなわれる。最終段階としての信号のＱＡＭ変調２１６においては、信号空間ダイヤグラム中に１６、３２、６４、１２８、または２５６の点を有する。変調された信号は、つぎに、物理インターフェースに送られるが、この場合の物理インターフェースは、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）ケーブルチャネルである。

第３の例として、図３にＤＶＢ−Ｔシステムの概略を示す。多重化アダプテーション／エネルギー拡散３０２ブロックにおいては、信号がパケット化され（同期１バイト、ＭＰＥＧ−２データ１８７バイト）、エネルギー拡散のためのランダム化がおこなわれる。つぎに、外部符号化ブロック３０４においては、エラー保護のために、入力パケットに対してリードソロモン符号化がおこなわれる。ついで、外部インターリービング３０６がエラー保護されたパケットに対しておこなわれる。つぎに、インターリーブされたデータは、畳み込みコーダとしての内部コーダ３０８に任意の想定範囲内のパンクチャレートで送られる。内部インターリービング３１０の段階においては、１つまたは２つのビットストリームの入力に対するビット単位および（ＯＦＤＭ）シンボル単位の、両方のインターリービング段階を含んでいる（点線矢印を参照）。さらなる情報に関しては、非特許文献４における「階級モード」に記載されている。マッピング３１２において、データストリームは、信号空間にマッピングされる。フレーム適合３１４がおこなわれると、信号は、６８のＯＦＤＭシンボルからなるフレームに編成される。ＯＦＤＭフレームは、データの他に、フレーム同期化やチャネル評価等に対するパイロットおよびＴＰＳ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐａｒａｍｅｔｅｒ Ｓｉｇｎａｌｉｎｇ、送信パラメータシグナリング）信号３２０を含む。最後に、信号は、（複数のキャリアによって）ＯＦＤＭ変調３１６されるとともにＤ／Ａ変換されてアナログ形態とされ、その後アナログ信号はフロントエンド３１８を介してエアインターフェースに導かれる。

近年、１９９０年代におけるインターネットの驚異的な発展により、ＩＰ（インターネットプロコトル）ネットワーク上でＤＶＢサービスを提供する追加モデルが開発された。この点については非特許文献５に記載されている。これは明らかに、新たなハードウェア等にさらなる投資をする必要がなく、既存のネットワークを利用してＤＶＢデータを伝送するという魅力的なアイデアであった。ＩＰ上に提供されるＤＶＢサービスについて、図４において示す一般的なタイプの層モデルを参照して説明する。点線は、異なるドメイン同士（水平分離）および異なる層同士（垂直分離）の間のインターフェースを示す。図４における陰影をつけた背景部分、すなわち管理プレーンは、総括的な管理と制御の目的で使用することができる。コンテンツプロバイダは、クライアント（加入者）に情報フローを提供する１つの事業体、もしくは複数の事業体であり、ＩＰトラフィックが透過的な配信ネットワーク上でサービスプロバイダによって実際に物理的に転送される情報フローを視覚化するためのパターンを通知する。コンテンツプロバイダのタスクには、たとえば、認証／承認サービス、サービスポータルメンテナンス、サービスの提供、サービス検索機構、メタデータサービス、実際のコンテンツサービス等がある。また、サービスプロバイダ（たとえば、ＩＳＰサービスプロバイダ）のタスクには、アドレッシングサービス、認証／承認サービス、ネーミングサービス（ＤＮＳ等）、基本ＩＰ接続サービス、セッション制御手段、サービス課金、およびファイアーウォールのような様々な付加価値サービス、キャッシュ等がある。しかし、実際のところ、１つのみの事業体がコンテンツおよびサービス面を提供して技術的に実行することも十分に可能である。ホームドメインは、ＤＶＢサービスが消費されるドメインである。これは、単一のネットワークにおける１つ以上の端末装置を示すこともあれば、複数の装置を含む複数のネットワークを示すこともある。

つぎに、図４のそれぞれの層に関して説明する。物理層４０８は、通信リンクの端末同士でデータをやり取りするための最下層インターフェース手段を含んでいる。この層では、たとえば、コネクタの形状およびサイズ、「ビット」の定義、および同期アスペクト等を、たとえば、電圧レベルやそれぞれの持続時間、またはその他の物理的な大きさ等に関することを決定する。また、参照番号４０８は、リンク層に対しても用いられており、このリンク層は、アドレッシングのようなメディアアクセス制御機能、そして場合によりエラー制御、フロー制御、および誤って受信されたデータパケットの再伝送を取り扱う層である。ネットワーク層４０６は、ルーティング、パケット分割／再結合等を扱う層であり、対象とする端末間の接続全体に関して機能する。ルーティングとは、ＩＰネットワークの場合、必要なＩＰアドレスを追加してパケットを送信することを意味する。原則として、ネットワーク層４０６は、より下位レベルの物理／リンク層４０８を意識する必要はない。同様に、総称的に参照番号４０６で示すトランスポート層は、端末間のフローおよびエラー制御機能を実行するとともに、たとえば、単一のＩＰリンクを使用する複数の異なるサービスを多重化する。多重化は、複数の異なるポート番号によって実現することができる。トランスポート層プロトコルに対して、特にＩＰネットワークにおいてよく選ばれるのは、ＵＤＰ（ユーザデータグラムプロトコル）およびＴＣＰ（伝送制御プロトコル）であるが、ＴＣＰは、また、単なる多重化に加えてエラー検出／制御を提供する。セッション層４０４は、アプリケーションで使用される接続のセットアップおよび解除をおこなう。アプリケーション層４０２は、アプリケーションと、それらをインターフェースするＡＰＩと、を含む。ＤＶＢにおいては、アプリケーション層４０２は、特にＭＨＰ（マルチメディアホームプラットフォーム）と呼ばれている。ホームドメインにおいて、ＤＶＢサービスに対するＩＰトラフィックは、たとえば共通のイーサネット（たとえば、１００ＢＡＳＥ−Ｔ）（たとえば、非特許文献６参照。）またはＩＥＥＥ１３９４（たとえば、非特許文献７参照。）の物理／ネットワーク層技術を用いて実行することができる。

ＩＰパケット中に含まれるＤＶＢデータは、サービスに応じて加入者に対するマルチキャストまたはユニキャストとすることができる。たとえば、ＩＰマルチキャストは、有料放送テレビタイプの伝送に使用でき、ＩＰユニキャストは、オンデマンド形式サービスのビデオ／オーディオに使用できる。ＩＰネットワークにおけるＤＶＢについての詳細は、非特許文献５およびその中で参照されている出版物に記載されている。

同時におこなわれる最も重要な決定の１つは、選択されるソース符号化方法に関する。ＭＰＥＧ−２は、非常に高い圧縮比による多くの異なる圧縮技術を使用するビデオおよびオーディオ符号化方法を一体化させた有力な方法であるが、１つ大きな弱点がある。弱点とは、使用される圧縮方法が不可逆である、すなわち、符号化処理中に取消不能な形態で消失するデータが存在することである。このような犠牲を払わなければ、達成できる圧縮比（昨今は１：６から１：３０等が典型的）は、特に優れたものにはならない。ＭＰＥＧ−２符号化には、相当量の処理が必要であるが、このことは一般的には、近年の高性能プロセッサにとって問題にはならない。

図５は、標準化されたＭＰＥＧ−２ストリームを出力として生成するＭＰＥＧ−２準拠のエンコーダ５０４を用いて、オーディオ／ビデオ信号５０２を符号化する一般的な手順を示している。オーディオ／ビデオサーバ５０６は、符号化されたデータストリームを受信して格納し、つぎに、該データストリームを伝送ネットワーク５０８を介して、たとえば、テレビに接続されたＤＶＢセットトップボックスまたはカードがインストールされたＤＶＢ ＩＲＤ（Ｉｎｔｅｇｒａｔｅｄ Ｒｅｃｅｉｖｅｒ Ｄｅｃｏｄｅｒ）等のレシーバ５１０に伝送する。レシーバ５１０は、データストリームを利用するための復号化に必要なソフトウェア／ハードウェア手段を有している。

ＭＰＥＧタイプの符号化は、一般的な静止画圧縮フォーマットであるＪＰＥＧと共通する部分がいくつかある。ＪＰＥＧは、人間の視覚の特徴を利用して、符号化プロセス中に、通常では不可視でありその意味で不必要な情報を原画から抽出する。符号化段階では、たとえば、離散余弦変換（時間から周波数への変換）と、エントロピー符号化と、を利用する。人間の肉眼で感知しやすい高周波輝度（明度）変化に比べて、画像の色における高周波変化は、符号化信号から省くことができる。フレーム内（図形内）の特徴に加え、ＭＰＥＧは、一時的な冗長性を利用する。すなわち、ＭＰＥＧでは連続したビデオフレームにおいて動きがない部分については、すべてをフレーム毎に符号化する必要はない。任意の領域内でコンテンツが変化した段階で、フレームを符号化して送出する。

ＭＰＥＧにおいては、図形中の各ピクセルは輝度／明度値（Ｙ）と、２つのカラーベクトル（Ｕ，Ｖ）と、によってパラメータ化される。つぎに、ピクセルは、ブロックと、マクロブロックと呼ばれるブロック群と、にグループ化される。ブロックは、一般的なフーリエ変換に幾分類似したＤＣＴを利用して、周波数領域に変換される。ＤＣＴによって、周波数が増加したブロックから形成された余弦関数を表す多数の係数が得られる。このような係数から、ブロックの有する空間的な情報は、後に復号化手段によって解読可能である。ＤＣＴ変換出力は、つぎに、効率的に量子化されてホフマン符号化される。ホフマン符号化においては、符号が異なれば消費するビット数も異なる。使用頻度の高い符号は、より少ないビット数を使用し、使用頻度の低い符号は、多くのビットを使用する。

ＭＰＥＧ符号化における、つぎの任意の時間相について考えると、一連の画像を含むビデオ信号（以下「フレーム」とする）において、所定のブロック中に含まれるデータが、その後にフレームが複数続くまでの少なくとも短時間の間、比較的不変のままであることは明らかである。このことは、ソース信号の特徴によるものである。たとえば、ニュース放送は、ニュースキャスターがデスクにつき、国内経済に関して最近起こった事柄について発言するクリップを含んでいる。後続のフレームでは、可能性として、ナレーターの顔領域付近のブロックに最も変化が生じているものの、絵画やポスター等の貼られた壁を含む背景部分には、変化が生じないということがある。おそらく、このような情報番組では、カメラの動きはわずかであろう。一方、最近のアクション映画における戦闘シーンの場合、連続する多数のフレームには、変化の生じない部分がほとんど含まれない。

したがって、ブロックの中には、先行フレームにおけるブロックを元に予測できるものもある。このような予測されるブロックを含むフレームをＰフレームと呼ぶ。しかし、伝送エラーの悪影響を低減し、符号化信号に（再）同期化させるために、その他のフレームからの情報に依存しない完全なフレームが定期的に伝送される（１秒間に数回）。多くの点で重要なスタンドアロンフレームは、内部符号化フレームまたはＩフレームと呼ばれている。Ｉフレームは、たとえば、サービスの加入者が最初にまたは少なくとも一時中断後に、サービスストリームを受信し始める時や、単なる差異データを元に妥当な復号化フレームを構成するのに必要なデータ履歴を受信側が持たない場合に必要となる。先行および後続フレームの両方からの情報を使用する双方向間予測フレームは、Ｂフレームと呼ばれる。

上記の手順は、さらに、ビデオ画像の先行フレームにおける他の位置から、画像の動きのあった部分のみを借用できるように動きベクトルを符号化することによって実行される。４つの８×８ピクセルブロックをグループ化して、１６×１６のマクロブロックにする。変化しないマクロブロックは、後続フレームにおいて再符号化されない。Ｐフレームの場合、エンコーダは、先行フレーム（Ｂフレームの場合は、先行フレームと後続フレーム）について、半ピクセル毎に、現在のマクロブロックに含まれる情報と適切に一致する他のマクロブロック位置を検索する。適切に一致するマクロブロックが近隣領域に見つからない場合には、マクロブロックは、内部符号化され、ＤＣＴ係数は、完全に符号化される。検索領域において適切に一致するマクロブロックが見つかった場合には、すべての係数を伝送せずに、動きベクトルを使用して類似ブロックを示す。

図６に、ＭＰＥＧ符号化の空間的側面および時間的側面を示す。ここでは、イメージ的に２つの連続するフレームを、ＭＰＥＧビデオエンコーダを備えたコンピュータで符号化する。１つのソースの同一位置に対応するマクロブロック６０２およびマクロブロック６０６は、両フレームにおいてほとんど同じデータを含むため、符号化は省略できる（Ｐフレーム）。一方、マクロブロック６０４およびマクロブロック６０８では、会議の場面には変化がないものの、男性が歩くことで変化する要素が生じており、再符号化の必要がある。ただし、符号化をおこなう必要のある要素として、歩いている男性は動いているだけでその形状は変わっていないため、左側の先行フレームにおけるマクロブロックとの一致度を右端の最新フレームにおいて判断するために、動きベクトルを利用することができる（図面中、点線矢印で強調表示している）。

また、ＭＰＥＧオーディオ符号化は、聴覚マスキング効果のような人間の聴覚における、ある独特な特性を利用する。時間的側面および（周波数面での）空間的側面の両方に関して、復号化された信号において、知覚されるとしても最小の劣化を伴うだけで、１：１０という優れた圧縮比を達成できると考えられる。ＭＰＥＧ−２は、指向性オーディオに対する５つのチャネルと、特別な低周波チャネルと、を有する。さらに符号化信号は、また、複数の代替言語チャネルを含むことができる。

莫大なＭＰＥＧ−２規格は、複数の異なるビデオモードおよびオーディオモードを含むため、特にＤＶＢサービスの場合に、好適なレベルの採用については、様々な状況において必然的に生じる比較の問題に関して、非特許文献８の中で定められており、ハードウェア製造業者の作業の簡便化が図られている。

ＤＶＢサービスの加入者に対する、サービスの配信に実際に影響を与えるオプション（サービスの加入／選択、サービスのパラメータの調整等）を提供するために、これらの作業を実行するリターンチャネルを設ける必要がある。ＤＶＢにおいては対話（インタラクティブ）機能に関する仕様は、一般に２つの仕様に分けられていた。１つは、ネットワークに依存しないものであり、ＩＳＯ／ＯＳＩ層を介しておよそ２つから３つ（たとえば、非特許文献９参照。）上位に存在するプロトコルスタックとみなすことができる。一方、ＤＶＢ仕様の２つ目は、ＩＳＯ／ＯＳＩモデルより下位（およそ１つから２つ）の層に関するものであり、対話機能のためにネットワークに依存したツールを特定する。たとえば、ケーブルを介したＤＶＢリターンチャネル仕様（ＤＶＣ−ＲＣＣ）（たとえば、非特許文献１０参照。）は、この目的だけではなく固定電話／携帯電話による対話システムおよび衛星の対話システムに対しても利用可能である。ＩＰネットワークの場合、標準的なＩＰユニキャストは、サービス／コンテンツプロバイダとの対話機能のために使用することができる。ＤＶＢプロジェクトのウェブサイト＜ｈｔｔｐ：／／ｗｗｗ．ｄｖｂ．ｏｒｇ／＞を閲覧すれば、利用できるＤＶＢ関連資料に関するリストを見ることができる。

しかし、ＤＶＢサービスまたはコントロールデータを配信するための多様な既存のデータ転送構成があるにもかかわらず、許容可能な転送時間を実現するためには、現在利用できるリソースではまだ不十分である。たとえば、リアルタイムゲームのようなサービスは、加入者にリアルタイムゲームを体験させるには、応答時間を短くすることが必要である。図７に、ゲームのシナリオを示すが、図７においては、サービスプロバイダは、配信ネットワークとして動作するＤＳＬまたはケーブルネットワーク７０４を介して、１人以上の加入者にゲーム情報を伝送するゲームサーバ７０２を有している。受信側においては、セットトップボックス７０８がサービスデータを受信し、復号化する。デコーダ７０９は、たとえば、専用のビデオ処理チップ、または複数の異なるタスクを割り当てられた一般的な処理装置である。つぎに、セットトップボックス７０８は、復号化したサービスデータをＴＶ受像機もしくはモニタ７０６に視覚化のために伝送する。リモコン７１０を使用すれば、ローカルデバイスを制御したり、前記配信ネットワーク７０４上、もしくはこのような目的のために利用可能なその他の任意の転送路上で、サーバ７０２に対してサービスに関連した制御命令／リクエスト／フィードバックを送ったり（矢印を参照）することができる。サービス利用中に加入者が感じる全体的な遅延は、複数の問題を含んでいる。その中で明らかな問題を挙げると、データを符号化する時間、伝送遅延（使用される接続のタイプによって転送方向に対して非対称であり得る）、復号化遅延、追加的な安全バッファの遅延等がある。上述したように、符号化したＭＰＥＧ−２ストリームは、一般に、複数の異なるフレームタイプを含んでおり、異なる特徴のないフレーム（Ｉフレーム）は、当然、予測フレーム（Ｐフレーム）よりサイズが大きい。フレームサイズが増大することで、伝送遅延および後続のバッファ遅延も増大する。相応するＰフレームの３倍のサイズを有するＩフレームは、ネットワークを介して伝送するのに３倍の時間がかかる。フレーム間で伝送時間が変化することは、対話機能サービスの有用性に不利な影響を及ぼす。Ｉフレームによって生じる伝送遅延を低減するための１つの解決手段は、符号化されたフレームにおいて画像品質を低減することによって（量子化等の増大によって）、フレームサイズを縮小することである。しかしこの解決手段は、ユーザがある程度十分であったにしてもサービスの品質全体が低下するため、ユーザが低減した画像品質に気づく可能性があり、一般的に適切な選択ではない。

欧州通信規格協会による欧州規格（ＥＴＳＩ ＥＮ）３００ ４２１ Ｖ．１．１．２ デジタルビデオ放送（ＤＶＢ）；フレーム構造、チャネル符号化および変調１１／１２ＧＨｚ衛星サービス 国際標準化機構／国際電気標準会議（ＩＳＯ／ＩＥＣ） ＤＩＳ１３８１８−１（１９９４年６月）；動画および関連する音声の符号化（ＭＰＥＧ−２） ＥＴＳＩ ＥＮ３００ ４２９ Ｖ１．２．１ デジタルビデオ放送（ＤＶＢ）；ケーブルシステムのためのフレーム構造、チャネル符号化および変調 ＥＴＳＩ ＥＮ３００ ７４４ Ｖ１．４．１ デジタルビデオ放送（ＤＶＢ）；地上デジタルテレビのためのフレーム構造、チャネル符号化および変調 ＥＴＳＩ ＴＲ１０２ ０３３ Ｖ１．１．１ デジタルビデオ放送（ＤＶＢ）；ＩＰベースネットワーク上でのＤＶＢサービスの配信のための構造フレームワーク ＥＴＳＩ ＴＳ１０２ ８１４ Ｖ１．２．１ デジタルビデオ放送（ＤＶＢ）；イーサネットホームネットワークセグメント ＥＴＳＩ ＴＳ１０２ ８１３ Ｖ１．１．１ デジタルビデオ放送（ＤＶＢ）；ＩＥＥＥ１３９４ホームネットワークセグメント ＥＴＳＩ ＥＴＲ１５４ デジタルビデオ放送（ＤＶＢ）；衛星、ケーブル、および地上波放送における映像および音声に関するＭＰＥＧ−２システムの使用のための実行ガイドライン ｐｒＥＴＳ３００ ８０２デジタルビデオ放送（ＤＶＢ）；ＤＶＢ双方向サービスに関するネットワーク非依存プロトコル ＥＴＳＩ ＥＳ２００ ８００Ｖ１．３．１ ケーブルテレビ配給システム（ＣＡＴＶ）のための双方向チャネル

本発明の目的は、ユーザの観点からの相互サービスの伝送遅延に関して、従来技術において生じる問題を軽減することである。この目的は、"完全な"、一時的な非予測データフレームの伝送を変化させることにより達成される。これらにおいて特に重要な完全なデータフレームは、画像を構築するのに必要なすべてのデータ、または、要求に基づくための先行フレームまたはその先のフレームに用いる予測成分がない受信装置における他のデータ要素を十分に含んでいる。たとえば、ユーザがサービスデータの受信を開始するサービス開始時に、１つの非予測フレームが、デコーダを初期化し、履歴情報がなくても復号化を首尾良くおこなうために、受取人に伝送される。さらに、非予測フレームの伝送に対する類似の必要性は、様々なエラー状況の場合に発生し得る。すなわち、受信機が伝送エラーまたはバッファエラー等のため受信端でデータを適切に再生できない場合である。本発明の基本概念によれば、受信機は、受信されたサービスデータストリームを分析し、前記のエラー状況が発生した場合には、ゲームサーバのようなデータプロバイダに、リターンチャネルを介して新たな非予測フレームの受信が必要であることを通知する。

特に、上記構成は、サーバのようなデータソースが実質的にリアルタイムで単一の受取人に対するサービスデータを符号化する場合に最も有用である。おそらくは数十万または数百万のユーザが同時に存在する伝統的なＤＶＢサービス（通常のテレビジョン放送など）の典型的な使用例を考慮すると、Ｉフレームのような非予測的フレームは、本発明によってはうまく供給することができない。なぜなら、所定のチャネルにちょうどエントリーし、サービス受信を開始した加入者に非予測フレームをできるだけ高速に供給し、信号への高速同期化を保証しなければならず、また、そのために、許容可能なサービススタートアップ時間を保証しなければならないからである。したがって、低減された遅延を要求するユニキャスト形式の相互サービスデータの伝送は、提示された解決方法によって、最も利益を得ることができるであろう。たとえば、リアルタイムアクションゲームを含むこのようなサービスにおいては、最悪の場合でも２経路の伝送遅延が数１０ｍｓしか許容されない。

本発明によれば、サービスデータの伝送遅延の平均が低減されるため、受信端でのユーザ体験を高めることができる。データ符号化技術を用いることで、予測符号化を非予測符号化以上に強調することによって、符号化／復号化遅延さえもカットダウンすることができる。そして、非予測符号化は、少なくとも時折、所定の場合、より多くの処理力を必要とし、直接的に処理時間および遅延に影響する。この方法は、あるにしてもわずかな変化のシナリオに適用される。この変化は、連続フレーム間に存在し、種々異なる符号化フレームを形成するために要求される処理は、隣接するフレーム間の類似性を用いて、依存され、典型的に低減される。また、いくつかの伝送能力は別の目的のために用いられる。特にＤＶＢ技術／装置、具体的には、ＤＶＢ−ＣおよびＩＰ上でのＤＶＢ（両者ともＭＰＥＧ−２ソース符号化を使用する）を利用する双方向サービスの提供に関して本発明を説明するが、ほぼ同様の特徴を有するその他のデジタルブロードバンドやブロードキャストシステムにおいても、本発明を使用することで有利となる。たとえば、ＭＰＥＧ−１、ＭＰＥＧ−４、Ｈ．２６３およびＨ．２６４のような符号化方法は、ＭＰＥＧ−２の符号化方法に多少類似したＩ／Ｐフレーム概念を使用することから、平均的な技能を有する者にとっては、上記符号化方法または対応する符号化方法のうちの１つを利用するシステムにおいて本発明を使用できることが明らかである。

本発明にかかる方法によれば、圧縮サービスデータを配信ネットワークを介して端末装置に伝送する方法であって、サービスデータストリームは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、前記方法は、監視期間中に受領確認メッセージが受信されない場合を含む、予め定められた事象の発生を監視し（１００４）、該事象が発生した場合、非予測データフレームを端末装置へ伝送し、端末装置をデータストリームに同期させ（１００６、１０１４）、前記事象が発生しない場合、サービスデータストリームの中において前記共通のデータタイプからなる予測データフレームだけを端末装置に伝送すること（１００８）、を含むことを特徴とする。

上記サービスデータは、たとえば、上述のデジタルテレビジョンサービス（ＤＶＢ）に基づくＭＰＥＧ−２または他のデータであり、端末装置とは、より具体的には、たとえば、ＤＶＢ ＩＲＤまたは「ＤＶＢセットトップボックス」といったものを示す。データタイプとは、たとえば、ビデオ（画像）フレームデータまたはオーディオデータといったデータの種類を示す。

また、本発明にかかる方法は、データソースによって配信ネットワークを介して伝送された圧縮サービスデータを受信する方法であって、サービスデータストリームは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、前記方法は、データストリームの適切な復号化が実行不可能であるか否かを検証し（１０１６）、実行不可能である場合には、データソースに新たな非予測データフレームの受信が必要であることを示し（１０１８、１０２０）、新たな非予測データフレームの受信が必要であることを示す方法は、通常の受領確認メッセージの送信を行わないことを含むことを特徴とする。

本発明にかかる装置は、データソースによって配信ネットワークを介して送信されたサービスデータを受信し、前記データソースにデータを伝送する装置（１２０８）であって、サービスデータストリームは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、前記装置は、指示を処理する処理手段（１２０２）と、データを格納するメモリ手段（１２０４）と、を備え、前記装置は、サービスデータストリームの適切な復号化が実行不可能であるか否かを検査し、実行不可能である場合には、前記データソースに新たな非予測データフレームの受信が必要であることを示し、新たな非予測データフレームの受信が必要であることを示す方法は、通常の受領確認メッセージの送信を行わないことを含むことを特徴とする。

また、本発明にかかる装置は、配信ネットワークを介して端末装置にサービスデータを伝送し、前記サービスに関する端末装置によって送信されたコントロール情報を受信する装置（１１０８）であって、サービスデータは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、前記装置は、指示を処理する処理手段（１１０２）と、データを格納するメモリ手段（１１０４）と、を備え、前記装置は、監視期間中に受領確認メッセージが受信されない場合を含む、予め定められた事象の発生を監視し、該事象が発生した場合、前記非予測データフレームを端末装置に伝送し、端末装置をデータストリームに同期させる構成であり、前記事象が発生しない場合、サービスデータストリームの中において前記予測フレームだけを端末装置に伝送する構成であることを特徴とする。

以下、添付図面を参照しながら、本発明をより具体的に説明する。

図１から図７については、関連する従来技術とともに上記の記載で既に説明済みである。

図８−１は、連続したＭＰＥＧ−２ビデオ画像フレームの配列を含む本発明の方法をさらに容易に理解するためのシナリオを示している。図８−１においては、ＭＰＥＧ−２ビデオ画像フレームのいくつかは非予測的Ｉフレーム８０２、８０６であり、残りの参照番号８０４は、予測Ｐフレームを示している。データストリームは、３つのＰフレームからなる各ブロックの後に、１つのＩフレームを挿入することによって形成される。Ｉフレームは、ユーザ装置による明示的な受信要求に対する応答として送信される。図８−１においては、Ｐフレームの異なる性質を表す矢印を含んでいる。すなわち、現在のビデオ画像フレームと、先行のビデオ画像フレームと、の差分が検出され、パラメータ化され、Ｐフレームとして配信ネットワークを介して伝送される。受信機は、履歴情報を含んでおり、たとえば、ステートマシンであり、これを使用することにより伝送段階において、データの欠損がない場合やデータに伝送エラーが入り込まない場合、ディスプレイ上に可視化するために、パラメータ化された差分フレームを復号化し、再び有効なビデオ画像フレームに変換することができる。しかし、Ｉフレームの伝送がいずれの方法においても調整できず、Ｉフレームが自動的に、たとえば、周期的に伝送される場合、このシナリオは、平均伝送遅延を低減するという利点を有しない。これは、たとえば、サービスデータストリームの監視機能と、Ｉフレーム伝送の要求をデータソースに供給する機能と、を有していてもそうである。なぜなら、規則的に伝送されるＩフレームは、連続的に伝送（および受信）処理を遅くするからである。一例として、ＩフレームおよびＰフレームのサイズを、対応するフレームの図の下方に示す。伝送遅延は、フレームサイズとともに増大する。

アクションゲームのようなリアルタイムアプリケーションにおいては、受信されたデータストリームを、映画再生などのような単純な放送サービスの場合と同じように、スムーズな再生を保証しながらバッファすることができない。これは、コントロールが応答しないなどによってユーザの不満足度が容易に増大するためである。Ｉフレームのような非予測フレームが規則的に伝送される場合、受信バッファは、サイズが比較的小さく、伝送遅延が低減されるＰフレームのような純粋な予測フレームの場合よりも長くなければならない。

付加的なバッファリングの不利な作用、または受信側での連続的に変化するフレームレートは、受信フレームのサイズが急激な変化を克服するために、図８−２は、本発明の他の実施例を示している。この実施例では、大きなＩフレーム８１２は、破線の垂直線８１０で示したトリガとなる事象が発生した場合、換言すると「要求に応じた」場合のみ伝送される。他の時間は、サイズの比較的小さい予測フレーム８０８が伝送される。

図９は、テレビセット９１６に外付け、または一体化されているセットトップボックス９０６が、波線矢印９１８で示した入力されるサービスデータストリームを、ソフトウェアおよび／またはハードウェアによって検証および分析するための手段を有する本発明の実施例を示している。この検証および分析は、サービスデータストリームを適切に復号化することができるか否か、またはこれが回復不能なエラーを含んでいるか否か、またはＰフレームのようにいくつかの必要な部分を完全に損失しているか否か、についておこなわれる。エラーまたは損失したフレームに続くＰフレームは、一般的に、もはやうまく復号化されることができない。前記検証は、受信データから検証フレーム構造を直接考察することによって、および受信データに含まれる所定のパラメータ（タイムコードまたは他のインデクス情報）を任意に再調査することによって実行することができる。所定のパラメータは、それ自体として受信データに含まれるか、または受信データに基づいて計算されるかする。また、前記検証は、局所的に生じたチェックサムデータを、受信され埋め込まれた値と比較／検出することにより実行することができる。さらに、受信バッファの検査でも新たな非予測的Ｉフレームに対する要求の必要性を指示することができる。たとえば、受信バッファにおけるバッファアンダーフローは、ネットワーク９０４を介してＩフレーム要求９２２を、データソースとして動作するサーバ９０２に送信するためのトリガとして使用することができる。ネットワーク９０４は、たとえば、ワイヤレス、ケーブル、またはＩＰネットワークである。さらに、データ受信タイマの満了は、伝送経路におけるデータ損失を示すことができる。プロセシングユニット９１２は、セットトップボックス９０６の動作全体を制御することができる。一方、デコーダ回路／ソフトウェア９１４は、受信ストリームを分析し、データのさらなる受信およびＩフレーム要求の伝送などのために必要な情報９２０を、プロセシングユニット９１２に供給する。

一方、サーバ９０２は、ソフトウェアおよび／またはハードウェアによってＩフレーム要求またはその指示を受信するための手段と、引き続きＩフレームをセットトップボックスに伝送するための手段と、を有する。対話型アプリケーション９０８は、サーバ９０２自体に常駐するか、または少なくともサーバに接続されており、符号化され（９１０）、セットトップボックス９０６に配信されたデータをプロセシングユニットに供給する。相応にして、データの符号化は、サーバ９０２に接続された外部符号化装置においておこなうこともできる。新たなＩフレームの伝送が必要であるとの指示９２２の受信に基づき、このようなフレームがデータから計算され、所要のネットワーク伝送ユニットでカプセル化され、セットトップボックス９０６に送信される（９２４）。

前述したフレーム損失またはエラーフレームに関連する特別のシナリオの場合を除いたサービスデータストリーム伝送において、短縮予測フレームだけを使用することにより、受信バッファを最小化することができ、インタラクティブサービス状態におけるライブ画像、たとえば、ゲームシーンが、少ない遅延でディスプレイに描写されることができる。このような特別のシナリオの場合、遅延は一時的に増大し、サービスユーザは、サービス品質が間欠的に劣化すると感じるかもしれない。しかし、このことはいずれにしろこのようなシナリオでは発生してしまうものであり、新たなＩフレームは、状況を補正し、セットトップボックスを後続の予測Ｐフレームに関連して同期させる。現在のサービス状態に基づいてＩフレームを送信した後、サーバ９０２は、必然的に実際のリアルタイム状況から論理的に継続されるＰフレームの送信を、有利には継続する。したがって、いずれの補正タイプのフレームも、サーバ９０２と、セットトップボックス９０６と、の間で有利には送信されず、全体的な平均遅延の拡大が回避される。

Ｉフレーム要求９２２は、実際は明示的である必要はなく、この目的のためには、他の形式のメッセージでも可能である。基本的に、サーバ９０２からのどんな指示でも、Ｉフレーム送信に対する必要性を低減することができ、また、十分であるとみなすことができる。この指示は、コントロールメッセージまたはフィードバックメッセージとすることができ、また、明示的なまたは暗示的なパラメータとしてこれらに含むことができる。他の方法としては、遠端においてデータ受信が成功したことについての特定の確認応答が受信されないことを、指示としてみなすことができる。たとえば、監視期間に関連する所定の満了時間を備えるタイマを、新たなＩフレーム伝送を呼び出すための意思決定手続をトリガとして用いることができる。さらに、この指示は、セットトップボックス９０６からではなく別の構成要素から同様に受信されることもできる。たとえば、データを配信ネットワーク９０４に送信するネットワーク構成要素が、バッファのオーバーフローによってデータ損失／変質を受けた場合、この構成要素は、セットトップボックス９０６がこの状況に応答する前に、送信者にエラーを示すことができる。

図１０は、本発明の方法のステップを実行するための一例を示したフローチャートである。方法の開始ステップ１００２においては、データソースとして機能する上述のサーバ等の装置が自装置のメモリに、符号化、データ転送、および制御アプリケーションをロードし、必要なメモリ領域および変数を初期化し、たとえば、受信サービス要求等に基づいて必要な接続を確立し、符号化されたデータフレームを含むサービスデータの配信を始める。

ステップ１００４においては、この装置は、以前の監視期間からＩフレームの伝送のトリガとなる事象が発生したか、していないかを監視する。この監視は、たとえば、所定間隔においてのみ実行しても、連続的にその他の機能と同時に実行してもよい。このような事象は、たとえば、新たに形成された接続のパラメータ値／メッセージ指示である。なぜなら、少なくとも１つのＩフレームが、初期化のためおよび将来のインターフレーム同期化のために受取人に送信されるはずであるからである。他の方法としては、遠端において新たなＩフレームの受信に必要な指示のメッセージを受信した場合、所望の形式の事象であるとみなすことができる。これが実際の場合、新たなＩフレームを予測Ｐフレームの代わりに伝送しなければならない。このことは、ステップ１００６において判断され、ステップ１０１４においてＩフレームの伝送動作が実行される。他の方法としては、ステップ１００８においてＰフレームが伝送される。符号化して送信すべきデータが１０１０で存在する限り、フレームに関連する事象の発生と伝送の判断ステップは、送信すべきデータがなくなるまで繰り返され、ステップ１０１２において、方法の実行が終了する。

上記事象は、監視ステップ１００４の後でその発生が認識され得るという点において、所定のものである（その発生を監視対象とされる事象は、リスト等にして格納しておくことができる）。当然のことながら、一般的に実際の発生は、予め決まっているものではないが、事象が発生することによって起こり得る問題／エラー／サービスの開始または起動といった状況は、事前に把握しておくことができる。

破線１０２４は、セットトップボックスのような受信端の装置によって実行される方法ステップを囲んでいる。この装置は、サービスに関連する符号化データを受信する（１０２２）。受信された符号化データまたは受信すべきであるが失われてしまったデータに基づいて、具体的には、デコーダ状態に基づいて、現在の復号化状態についての分析が実行される（１０１６）。ステップ１０１８において判断され、データを適切に復号化するために新たなＩフレームの受信が必要とされる場合、ステップ１０２０においてこの必要性が指示される。指示は、たとえば、特定メッセージの送信、またはデータソースに配信ネットワークまたは他の使用可能な接続を介して送信される一般的なメッセージに特定のパラメータ／パラメータ値が含まれていることを意味する。指示は、また、通常の受領確認メッセージなどの送信、または上述した他の受動的な手段の脱落、としてもよい。

図１１は、予測フレームおよび非予測フレームの両フレームを有する符号化データを配信するためのサーバ／データソースとして作用可能なコンピュータ等の装置１１０１の基本要素のブロック図を示している。処理手段１１０２は、たとえば、メモリ１１０４に格納されたデータ符号化ルーチンを含むアプリケーションの形態の指示１１０５によって、動作の実行を制御する。メモリ１１０４は、必要な設定およびその他の補足的な情報に加えて、まだ符号化されていないデータフレームと、既に符号化されたデータフレームと、の両方を含んでいてもよい。データ伝送手段１１０８は、無線／赤外線トランシーバのようなワイヤレス手段１１１４と、ワイヤレスネットワーク（ＷＬＡＮ等）アダプタと、の両方を含んでいてもよい。また、データ伝送手段１１０８は、たとえば、従来のネットワークアダプタのような固定（有線）手段１１１２を含んでいてもよい。キーボード、もしくはその他のデータ入力手段１１１０、およびディスプレイ１１０６は、装置を管理および制御するインターフェースをユーザに提供するためにある。データエンコーダは、単なるソフトウェア手段であってもよいし、装置の他の部分に接続された特定のエンコーダチップを介して実行可能であってもよい。

同様に、図１２は、符号化されたサービスデータストリームを受信するために本発明にかかる装置１２０１を示している。装置１２０１は、処理手段１２０２と、デコーダ１２０５と、を有するメモリ手段１２０４と、データ伝送手段１２０８と、を含んでいる。装置は、配信ネットワークおよびリターンチャネルの両方にワイヤレス手段または固定手段の少なくとも一方で接続されて、データ伝送手段１２０８は、非予測フレームの要求の伝送のために用いることができる。装置は、十分なユーザインターフェースを実行するために、キーパッド１２１０に加えてディスプレイ１２０６を任意に含んでいてもよい。データデコーダ１２０５は、単なるソフトウェア手段であってもよいし、装置の他の部分に接続された特定のデコーダチップを介して実行可能であってもよい。

一般に、本発明およびその方法ステップを実行するためのソフトェアは、フロッピー、ＣＤ−ＲＯＭ、メモリカード、ハードディスク等の持ち運び可能なメディアで配布可能である。

本発明によるサービスデータ転送において使用されるプロトコルおよびプロトコルスタックは、特に複雑または特別ではなく、本発明を実行するために必要とされる転送能力を備える既存のものから選択することができ、このことも本発明の１つの利点と考えることができる。本発明は、装置に備わるものとして、もしくは少なくとも接続された追加のソフトウェア／ハードウェアモジュールとして、またはそれらを組み合わせたものとして実行可能である。

以上のことから、当業者においては分かるように、特許請求の範囲により規定される本発明の範囲を逸脱しなければ、様々な変更をおこなうことが可能である。同様に、使用される装置、方法ステップおよびそれらの順序、データフォーマット等は、本発明の基本的理念に基づく範囲で多様に変化させることが可能である。

ＤＶＢ−Ｓ仕様に準拠するＤＶＢ伝送システムを示す説明図である。 ＤＶＢ−Ｃ仕様に準拠するＤＶＢ伝送システムを示す説明図である。 ＤＶＢ−Ｔ仕様に準拠するＤＶＢ伝送システムを示す説明図である。 ＩＰネットワークの、ＤＶＢサービスデータの配信ネットワークとしての使用を示す説明図である。 典型的なＭＰＥＧ−２伝送システムを示す説明図である。 ＭＰＥＧ−２ソース符号化を空間的および時間的に示す説明図である。 サービスデータソースにフィードバック／制御情報を提供可能なＤＶＢセットトップボックスへのＤＳＬ／ケーブルネットワーク上でのサービス配信を示す説明図である。 非予測フレームが周期的に配信ネットワークを介して伝送されるシナリオを示す説明図である。 非予測フレームが要求された場合だけ送信され、一方、それ以外の場合は予測フレームだけが形成される本発明の択一的シナリオを示す説明図である。 本発明の（具体的な）方法を適用した際の受信側セットトップボックスの内部を示す説明図である。 本発明にかかる方法のフローチャートである。 本発明のサービスデータソースとして作用可能な装置のブロック図である。 本発明のサービスデータの受け手として作用可能な装置のブロック図である。

Claims (26)

1. 圧縮サービスデータを配信ネットワークを介して端末装置に伝送する方法であって、
   サービスデータストリームは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、
   前記方法は、
   監視期間中に受領確認メッセージが受信されない場合を含む、予め定められた事象の発生を監視し（１００４）、
   該事象が発生した場合、非予測データフレームを端末装置へ伝送し、端末装置をデータストリームに同期させ（１００６、１０１４）、
   前記事象が発生しない場合、サービスデータストリームの中の予測データフレームだけを端末装置に伝送すること（１００８）、
   を含むことを特徴とする方法。
2. 前記事象は、非予測データフレームの要求または指示の受信と、非予測データフレームの伝送を必要とすることを示す所定のパラメータを有するメッセージの受信と、非予測データフレームを伝送する必要があることを示すパラメータ値を有するメッセージの受信と、データ伝送接続の形成または初期化と、のうちの少なくともいずれか一つであることを特徴とする請求項１に記載の方法。
3. 前記サービスは、デジタルブロードバンドサービス、デジタルブロードキャストサービス、およびＤＶＢ（デジタルビデオ放送）サービスのうちの少なくともいずれか一つであることを特徴とする請求項１に記載の方法。
4. 前記圧縮サービスデータは、ビデオピクチャデータを含むことを特徴とする請求項１〜３のいずれか一つに記載の方法。
5. 前記ビデオピクチャデータは、ＭＰＥＧ−２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）によって符号化されることを特徴とする請求項４に記載の方法。
6. 前記非予測データフレームは、Ｉフレームであることを特徴とする請求項５に記載の方法。
7. 前記予測データフレームは、Ｐフレームであることを特徴とする請求項５に記載の方法。
8. データソースによって配信ネットワークを介して伝送された圧縮サービスデータを受信する方法であって、
   サービスデータストリームは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、
   前記方法は、
   データストリームの適切な復号化が実行不可能であるか否かを検証し（１０１６）、
   実行不可能である場合には、データソースに新たな非予測データフレームの受信が必要であることを示し（１０１８、１０２０）、
   新たな非予測データフレームの受信が必要であることを示す方法は、通常の受領確認メッセージの送信を行わないことを含む
   ことを特徴とする方法。
9. 前記検証は、バッファ状態の検証と、タイマ満了の検証と、チェックサム値の計算と、受信されたデータ構造の検証と、受信データに含まれるか、または受信データに基づいて決定されたパラメータ値の検証と、のうちの少なくともいずれか一つであることを特徴とする請求項８に記載の方法。
10. 前記サービスは、デジタルブロードバンドサービス、デジタルブロードキャストサービス、およびＤＶＢ（デジタルビデオ放送）サービスのうちの少なくともいずれか一つであることを特徴とする請求項８に記載の方法。
11. 前記圧縮サービスデータは、ビデオピクチャデータを含むことを特徴とする請求項８〜１０のいずれか一つに記載の方法。
12. 前記ビデオピクチャデータは、ＭＰＥＧ−２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）によって符号化されていることを特徴とする請求項１１に記載の方法。
13. データソースによって配信ネットワークを介して送信されたサービスデータを受信し、前記データソースにデータを伝送する装置（１２０８）であって、
    サービスデータストリームは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、
    前記装置は、
    指示を処理する処理手段（１２０２）と、
    データを格納するメモリ手段（１２０４）と、を備え、
    前記装置は、サービスデータストリームの適切な復号化が実行不可能であるか否かを検査し、実行不可能である場合には、前記データソースに新たな非予測データフレームの受信が必要であることを示し、
    新たな非予測データフレームの受信が必要であることを示す方法は、通常の受領確認メッセージの送信を行わないことを含む
    ことを特徴とする装置。
14. 前記検証は、バッファ状態の検証と、タイマ満了の検証と、チェックサム値の計算と、受信されたデータ構造の検証と、受信データに含まれるか、または受信データに基づいて決定されたパラメータ値の検証と、のうちの少なくともいずれか一つであることを特徴とする請求項１３に記載の装置。
15. 前記サービスは、デジタルブロードバンドサービス、デジタルブロードキャストサービス、およびＤＶＢ（デジタルビデオ放送）サービスのうちの少なくともいずれか一つであることを特徴とする請求項１３に記載の装置。
16. 前記サービスデータは、ビデオピクチャデータを含むことを特徴とする請求項１３〜１５のいずれか一つに記載の装置。
17. 前記ビデオピクチャデータは、ＭＰＥＧ−２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）によって符号化されていることを特徴とする請求項１６に記載の装置。
18. 前記装置は、ＩＲＤ（Ｉｎｔｅｇｒａｔｅｄ Ｒｅｃｅｉｖｅｒ Ｄｅｃｏｄｅｒ）およびテレビセットトップボックスのうちの少なくともいずれか一つであることを特徴とする請求項１３に記載の装置。
19. 配信ネットワークを介して端末装置にサービスデータを伝送し、前記サービスに関する端末装置によって送信されたコントロール情報を受信する装置（１１０８）であって、
    サービスデータは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、
    前記装置は、
    指示を処理する処理手段（１１０２）と、
    データを格納するメモリ手段（１１０４）と、を備え、
    前記装置は、監視期間中に受領確認メッセージが受信されない場合を含む、予め定められた事象の発生を監視し、該事象が発生した場合、前記非予測データフレームを端末装置に伝送し、端末装置をデータストリームに同期させる構成であり、前記事象が発生しない場合、サービスデータストリームの中において前記予測データフレームだけを端末装置に伝送する構成であることを特徴とする装置。
20. 前記事象は、非予測データフレームの要求または指示の受信と、非予測データフレームの伝送を必要とすることを示す所定のパラメータを有するメッセージの受信と、非予測データフレームを伝送する必要があることを示すパラメータ値を有するメッセージの受信と、データ伝送接続の形成または初期化と、
    のうちの少なくともいずれか一つであることを特徴とする請求項１９に記載の装置。
21. 前記サービスは、デジタルブロードバンドサービス、デジタルブロードキャストサービス、およびＤＶＢ（デジタルビデオ放送）サービスのうちの少なくともいずれか一つであることを特徴とする請求項１９に記載の装置。
22. 前記サービスデータは、ビデオピクチャデータを含むことを特徴とする請求項１９〜２１のいずれか一つに記載の装置。
23. 前記ビデオピクチャデータは、ＭＰＥＧ−２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）によって符号化されていることを特徴とする請求項２２に記載の装置。
24. 前記装置は、サーバであることを特徴とする請求項１９〜２３のいずれか一つに記載の装置。
25. 請求項１〜８のいずれか一つに記載の方法ステップを実行する符号化手段を含むコンピュータプログラム。
26. 請求項２５に記載のコンピュータで実行可能なプログラムを有する持ち運び可能なメディア。

Images