JP5027657B2 - デコーダにデータを供給する方法および装置 - Google Patents

Description

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一般的に、受け付けた符号化静止ビデオ信号を復号化するように構成されるセットトップボックス内のデコーダチップ７０９は、幾分か安定した入力レートのソースデータストリームによって作用するように設計されている。したがって、伝送エラーや可変的な伝送遅延があった時に、復号化されるソースビデオストリームの入力レートを均一に保持するために、実際のデコーダ７０９に送られる前に、受信されたデータをバッファに格納する。

ほとんどのブロードキャスト／マルチキャストタイプのサービスでは、ゲームのような特定の双方向サービスとは対照的に、少量のバッファリング機能しか無く、サービスデータまたはフィードバックの提供で生じる種々の付加的な遅延は、遅延の大きさにかかわらず問題であると考えられる。応答時間をほぼ常時最少化して、適用される伝送技術に関係なく、最大限に透過的な使用体験をサービスユーザに提供することが必要である。したがって、ＭＰＥＧ−２サービスデータの場合に、たとえば、後続のＩフレームまたはＰフレームを複数含む受信側ＦＩＦＯ（先入れ先出し）バッファには、問題があることは明らかであるが、一方、標準的なビデオ復号化手段を備えた現代のシステムにおいては必要な要素でもある。その上、ビデオデコーダチップは、入力データを適時に利用できないというバッファアンダーフロー状況を処理することができないため、可視化された復号化画像においてエラーが知覚されることとなり、また、次のＩフレームが受信されるまで後続フレームの適切な復号化が遅延することとなる。デコーダチップの中には、データ損失という状況を切り抜けて、通常の機能を継続することができないものもある。

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

本発明の目的は、符号化データの受信速度が不安定であることと、復号化におけるエラーを克服するために受信装置に付加的なバッファ機能が導入されることと、の両方が原因となって生じる、従来技術における問題を軽減することである。この目的は、セットトップボックスまたはその他の受信装置において生じる受信バッファアンダーフローを認識し、特定フレームを供給することで達成される。ここで特定フレームは、好ましくは「変更が無い」タイプ（たとえば、ＭＰＥＧ−２の場合には適切なパラメータ値を有する予測Ｐフレーム）であることとともに、有利に内部に格納されたフレームである。前記フレームは、適切に受信されて復号化された先行フレームに対して、それが概してどのようなものであったとしても、何ら変化を導入しないフレームとする。この特定フレームは、適切なパラメータ値を持たせてサービスプロバイダまたは対応するサーバにおいてパケット化され、たとえば、サービスデータ配信の起動時にセットトップボックスに一旦伝送されることができる。セットトップボックスは、つぎに、これから先アンダーフロー状況になった際に使用するために、この特定フレームを格納する。さらにセットトップボックスは、格納される特定の「変更が無い」タイプのフレームを、一般的な状況に少なくとも部分的に適合させる必要がある。すなわち、現行のサービスデータストリームにより合うように、フレームのパラメータ値の一部を（再）決定／調整しなければならない。いずれにせよ、たとえば、ＭＰＥＧ−１およびＭＰＥＧ−２の符号化技術の場合には、適合は最小限のものでよいため、一般の処理能力を有するセットトップボックスにおいて実行可能である。

本発明によれば、関連する多くの問題が解決される。まず予期されるバッファアンダーフローの状態を検出し、これを処理することができるため、受信バッファのサイズを最小化でき、サービスデータ配信による遅延を短くすることができる。第２に、場合によっては、フレーム損失が発生するにもかかわらず、変更が無いタイプの特別なフレームによって、デコーダが復号化手順を連続しておこなうことができる。第３には、受信バッファのアンダーフロー状況が発生した場合でも、サービス応答時間を最少化して、知覚される画像エラー、もしくはその他のサービスデータエラーを削減することによって、全体としての使用感が向上する。さらに、本発明の方法が適用されれば、デコーダは、フレームが損失しても機能／復号化を一時的に停止しないため、後続のＩフレーム伝送間の時間を延長して、伝送能力を保持することができる。

特にＤＶＢ技術／装置、具体的には、ＤＶＢ−ＣおよびＩＰ上でのＤＶＢ（両者ともＭＰＥＧ−２ソース符号化を使用する）を利用する双方向サービスの提供に関して本発明を説明するが、ほぼ同様の特徴を有するその他のデジタルブロードバンドやブロードキャストシステムにおいても、本発明を使用することで有利となる。たとえば、ＭＰＥＧ−１、ＭＰＥＧ−４、Ｈ．２６３およびＨ．２６４のような符号化方法は、ＭＰＥＧ−２の符号化方法に多少類似したＩ／Ｐフレーム概念を使用することから、平均的な技能を有する者にとっては、上記符号化方法または対応する符号化方法のうちの１つを利用するシステムにおいて本発明を使用できることが明らかである。端末装置とは、より具体的には、たとえば、ＤＶＢ ＩＲＤまたは「ＤＶＢセットトップボックス」といったものを示す。データタイプとは、たとえば、ビデオ（画像）フレームデータまたはオーディオデータといったデータの種類を示す。

本発明にかかる方法は、受信端に配置されたデコーダに対して配信ネットワーク上で伝送される圧縮サービスデータを供給する方法であって、サービスデータストリームは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、前記方法は、所定の特定フレームまたは前記特定フレームに関する情報を前記受信端に格納するステップと、前記受信端において所定の基準によってサービスデータのデータバッファが、少なくともアンダーフロー状態に近い状態であるか否かを監視するステップと、少なくともアンダーフロー状態に近い状態である場合には、前記デコーダに前記特定フレームを供給して、入力データが適時に供給されないことによって発生する前記デコーダの障害を防ぐステップと、を含み、前記特定フレームは、以前に供給されたと想定されるサービスデータフレームに関連する前記サービスデータにおいて、実質的な変更が無いことを示すタイプの予測フレームであり、前記所定の基準は、前記バッファ中のデータ量に対する閾値または最後にフレームが受信された時からの経過時間のいずれかを含み、前記特定フレームまたは前記特定フレームに関する情報は、前記サービスデータ配信の開始時に、または前記特定フレームの要求の送信に応じた時に、供給元のサーバから前記受信端に供給され、前記特定フレームに関する情報はパラメータを有し、前記パラメータは現行のサービスデータストリームに合わせて調整されることを特徴とする。

上記方法における特定フレームは、たとえば、サービスデータ配信開始／起動時に、または定期的に、またはその他の所定の事象が生じた時に、リモートサーバまたは任意の中間装置のような送信手段によって最初に受信装置に提供されてもよい。受信装置は、リクエスト、特定のメッセージ、または既存のメッセージにおけるパラメータ／パラメータ値を送信手段に送り、新たな特定フレームを受信することができる。デコーダを有する装置のユーザは、特定フレームの構成に必要な情報を手入力すること、またはフロッピーディスク、もしくはＣＤ−ＲＯＭ等のキャリア媒体から特定フレームをロードすること、のいずれかによって特定フレームを局所的に提供することができる。

アンダーフロー状況の基準は、一般的なシナリオに最も適した方法で決定されることができる。この基準は、たとえば、空の入力バッファの場合には、デコーダに符号化サービスデータを供給するスケジュールにおける次の供給に対して許可された最少の継続時間とすることが可能である。特定フレームは、構成および蓄積される準備が整っており、さらなる適合をおこなう必要の無い場合には、フレームをデコーダに供給することに対して、時間のかかる適合のための処理をさらにおこなう必要がほとんど無いため、上記継続時間を短くすることができる。一方、より良く適合させることが必要な場合には、より多くの時間がかかるため、それに伴って許容された最小の継続時間の基準を長くする必要がある。

データバッファは、少なくとも１つの復号化されるサービスデータフレームに関連した情報を維持するのに必要な格納スペースを含むが、場合によっては、長くすることもできる。

また、本発明にかかる方法は、受信端に配置されたデコーダに対して配信ネットワーク上で伝送される圧縮サービスデータを転送する方法であって、サービスデータストリームは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、前記方法は、所定の事象の発生を監視するステップを含み、前記受信端に対して所定の特定フレームまたは前記特定フレームに関する情報を前記サービスデータ配信の開始時、または前記特定フレームの要求の送信に応じた時に、伝送することにより、サービスデータバッファのアンダーフロー時に前記受信端が前記特定フレームを前記デコーダに供給することが可能となり、前記バッファ中のデータ量に対する閾値、データ受信速度、及び最後にフレームが受信された時からの経過時間の少なくとも１つを含む所定の基準に従い、前記サービスデータバッファのアンダーフローを監視し、前記特定フレームは、以前のサービスデータフレームに関連する前記サービスデータにおいて、実質的な変更が無いことを示すタイプの予測フレームであり、前記特定フレームに関する情報はパラメータを有し、前記パラメータは現行のサービスデータストリームに合わせて調整されることを特徴とする。

前記所定の事象は、サービスデータ配信起動／開始、フレーム要求の受信、設定時間の終了等であり得る。

本発明にかかる装置は、配信ネットワーク上でデータソースによって送信されるサービスデータを受信するとともに、データを伝送する装置であって、サービスデータストリームは、共通のデータタイプからなる予測フレームおよび非予測フレームの両方を含み、前記装置は、指示を処理する処理手段と、データを格納するメモリ手段と、を備え、前記装置は、前記サービスデータ配信の開始時、または前記特定フレームの要求の送信に応じた時に、受信した所定の特定フレームまたは前記特定フレームに関する情報を受信端に格納し、所定の基準によってサービスデータ受信バッファが少なくともアンダーフロー状態に近い状態であるかどうかを前記受信端において監視し、前記所定の基準は、前記バッファ中のデータ量に対する閾値または最後にフレームが受信された時からの経過時間のいずれかを含み、前記バッファが少なくともアンダーフロー状態に近い状態である場合には、前記特定フレームをデコーダに供給するように構成されることによって、入力データが適時に供給されないことによる前記デコーダの障害を防ぎ、前記特定フレームは、以前に供給されたと想定されるサービスデータフレームに関連する前記サービスデータにおいて、実質的な変更が無いことを示すタイプの予測フレームであり、前記特定フレームに関する情報はパラメータを有し、前記パラメータは現行のサービスデータストリームに合わせて調整されることを特徴とする。

また、本発明にかかる装置は、端末装置に配信ネットワーク上でサービスデータを伝送し、前記サービスに関連した前記端末装置によって送信される制御情報を受信することができる装置であって、前記サービスデータは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、前記装置は、指示を処理する処理手段と、データを格納するメモリ手段と、を含み、前記装置は、所定の事象の発生を監視するように構成されるとともに、所定の特定フレームまたは前記特定フレームに関する情報を前記サービスデータ配信の開始時、または前記特定フレームの要求の送信に応じた時に、受信端に伝送するように構成されることで、サービスデータバッファのアンダーフロー時に前記受信端が前記特定フレームをデコーダに供給することができ、前記バッファ中のデータ量に対する閾値、データ受信速度、及び最後にフレームが受信された時からの経過時間の少なくとも１つを含む所定の基準に従い、前記サービスデータバッファのアンダーフローを監視し、前記特定フレームは、以前にあったと想定されるサービスデータフレームに関連する前記サービスデータにおいて、実質的な変更が無いことを示すタイプの予測フレームであり、前記特定フレームに関する情報はパラメータを有し、前記パラメータは現行のサービスデータストリームに合わせて調整されることを特徴とする。

上記装置では、異なる機能ブロック／モジュールを単一の筐体に設けても、あるいは本発明の装置を形成するべく少なくとも機能的に接続された複数の筐体に設けてもよい。

本発明にかかるシステムは、配信ネットワーク上でサービスデータを転送することができるシステムであって、前記サービスデータは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、前記システムは、サービスデータを伝送し制御情報を受信することができる第１の装置と、サービスデータを受信して制御情報を伝送することができる第２の装置と、を含み、前記第１の装置および前記第２の装置の両装置は、指示を処理する処理手段と、データを格納するメモリ手段と、を備え、前記第１の装置は、所定の事象の発生を監視するように構成されるとともに、前記サービスデータ配信の開始時、または前記特定フレームの要求の送信に応じた時に、所定の特定フレームまたは前記特定フレームに関する情報を前記第２の装置に伝送する伝送手段をさらに備え、前記特定フレームは、以前にあったと想定されるサービスデータフレームに対して当該サービスデータにおける実質的な変更が無いことを示すタイプの予測フレームであり、前記特定フレームに関する情報はパラメータを有し、前記パラメータは現行のサービスデータストリームに合わせて調整され、前記第２の装置は、前記サービスデータ配信の開始時に前記所定の特定フレームまたは前記特定フレームに関する情報を受信して格納し、サービスデータ受信バッファが所定の基準によって少なくともアンダーフロー状態に近い状態であるかどうかを監視し、前記所定の基準は、前記バッファ中のデータ量に対する閾値または最後にフレームが受信された時からの経過時間のいずれかを含み、少なくともアンダーフロー状態に近い状態である場合には、前記特定フレームを前記デコーダに供給することによって、入力データが適時に供給されないことによるデコーダの障害を防ぐように構成されることを特徴とする。

本発明の幾つかの好適な実施形態は、従属請求項において開示される。

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

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

図８は、本発明の方法をさらに容易に理解できるようにするための説明図を示している。図８においては、テレビセット８１６に外付けまたは一体化されているセットトップボックス８０６は、分析／処理手段８１２を含んでいる。該手段８１２は、ソフトウェアおよび／またはハードウェアであり、入力されるサービスデータストリームに関する多数のパラメータを分析する。サービスデータストリームは、矢印８２４で示され、たとえば入力データバッファ格納率／格納度を示す。また、バッファの状態は、たとえば、本発明の方法を実行させる要因となる閾値と比較してバッファ内の現在のデータ量を調べることによって、チェックすることができる。この閾値が現在のデータ量と合わない、すなわち現在のデータ量がこの閾値を超えると、バッファは、アンダーフロー状態であると考えられ、セットトップボックス８０６に好ましくは局所的に格納される特定フレームがデコーダ８１４に供給されることで、データの消失によってデコーダが機能不良になる可能性が回避される。デコーダ８１４は、制御またはその他の情報８２０を該手段８１２に提供することができる。

ソフトウェアおよび／またはハードウェアであるサーバ８０２は、たとえば、セットトップボックス８０６によって受信要求８２２が送信された時に、または定期的に、またはサービスデータ配信の開始／起動時に、たとえば、特定フレームとして評価されたＰフレームのような「変更が無い」タイプの特定フレーム８１８を生成し伝送する手段を含んでいる。実際には、所定の事象の発生をうけて、特定フレームを伝送することができる。サーバ８０２自体の中に備わる対話型アプリケーション８０８または少なくともサーバ８０２に接続されている対話型アプリケーション８０８は、エンコーダ８１０で符号化されてセットトップボックス８０６へ伝送８２４されるサービスデータを処理手段に提供する。データの符号化は、サーバ８０２が接続される外部の符号化装置においておこなわれてもよい。

図９は、セットトップボックス９０６の内部の機能ブロックを示している。ネットワークデータは、関連するインタフェースを介して受信され、バッファ９０８の適切な位置に入力される。ネットワーク上で配信され、上位のサービスおよびアプリケーションに関連するデータは、一般的には下位（ネットワーク）レベルの伝送パケットに入れられて受信されるため、バッファ９０８がデコーダ９１４によって復号化される構造的に同じサービスデータのものである場合には、バッファ９０８には標準的な伝送パケットの復号化機能を持たせることができる。他の方法としては、デコーダ９１４だけを対象とするデータ入力バッファを論理上デコーダブロック９１４自体の中に設けて、データ受信ブロック９０８には全体的な受信手段の役割を持たせ、たとえば、複数の他のアプリケーションに対する受信データのルーティングをおこなわせてもよい。ソフトウェアアプリケーションまたはプログラムで制御できるアプリケーションの特定論理を介して実行される決定論理９１０は、たとえば、バッファの状態をポーリングすることによって、またはデータ受信ブロック９０８もしくはデコーダ９１４から対応する状態表示を受信することによって、包括的バッファまたはデコーダ固有のバッファの少なくとも一方における入力データを把握する。データの消失またはデータの誤受信が発生すると、決定論理９１０は、フレームパラメータ調整ブロック９１２を介して、内部に格納されている「変更が無い」タイプの特定フレームをデコーダ９１４に供給することができる。フレームパラメータ調整ブロック９１２は、たとえば、サービスデータフレームのタイムスタンプおよびシリアルナンバーを設定することができる。

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

ステップ１００４において、この装置は通常の方法でサービスデータを伝送し、特定フレームを伝送する引き金となる事象が、これまでの監視期間に発生したかどうかを監視する。特定フレームは、具体的には、たとえば、先行フレームに関連した、データ中に変更が無いことを示すＰフレームである。また、この監視は、たとえば、所定間隔においてのみ実行しても、連続的にその他の機能と同時に実行してもよい。ステップ１００６においてサービスデータの配信開始等の事象が発生した後には、システムによる「変更が無い」タイプの特定Ｐフレームまたは対応するフレームがステップ１０１２で送信される。ステップ１００８では、いずれの場合にもサービスデータ配信を継続しておこなうべきかどうかがチェックされ、継続して配信をおこなうべき場合には、この方法は、ステップ１００４から再スタートする。そうでない場合には、方法はステップ１０１０で終了する。

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

点線１０２２は、セットトップボックス等の受信端としての装置によって実行される方法ステップを示している。方法の開始ステップおよび終了ステップについては、明確さを期すために、この図では省略した。データ受信ステップ１０２０を点線で示しているのは、このステップが本発明の方法に関連したものであることは確かであるが、このステップが欠落／失敗してもそれが引き金となってさらなる方法ステップが実行されるため、このステップは、以下に説明する残りのステップを実行するための絶対的な条件ではないためである。データ受信ステップ１０２０においては、標準的なサービスデータフレームと、局所的に格納される「変更が無い」タイプの特定フレームと、の両方を受信可能である。

さらに、必ずしもフレーム自体またはフレームに含まれるすべての情報が必要ではない「変更が無い」タイプの特定フレームに関連する必要な情報のみがサーバから伝送され、セットトップボックスにより受信される。つぎに、セットトップボックスは、受信した情報に基づいて、それを使用するのが望ましい実時間にフレームの残りの部分を構成するか、またはこれから先に使用する可能性に備えて受信した情報を内部に直接格納するか、のいずれかをおこなうことができる。この情報は、フレーム全体を構成するルールを含む場合もあれば、特定フレームの局所的に利用できる部分を調整するために添付、もしくは使用される幾つかのパラメータを含むだけの場合もある。

ステップ１０１４においては、バッファ中のデータ量に対する閾値、データ受信速度、最後にフレームが（適切に）受信された時からの経過時間等、多くの所定の基準によって、装置は、復号化に対するデータバッファがアンダーフローに近い状態にあるかどうかを監視する。ステップ１０１６において、このようなアンダーフローに関する基準が満たされた時にはいつでも、ステップ１０１８において、特定の予測フレームが、デコーダに供給される。特定の予測フレームは、ＭＰＥＧ−２の場合には、本明細書の前半で述べた所定のパラメータのような動的に適合する可能性のある部分を有するＰフレーム等である。

図１３は、格納される予測フレームの使用について示している。問題とされる「変更が無い」タイプの特定の予測フレームは、サービスデータサーバのような外部ソースから受信された後、内部の格納部１３０２において格納される。他の方法としては、「変更が無い」タイプの特定の予測フレームは、装置内に早期に（事前に）プログラム化されてもよく、またリムーバブルメディアから供給されてもよい。異なるパターンのスロットは、それぞれフレームのパラメータおよびデータフィールドを示している。引き金となる事象の発生が検知されると、フレームが格納部から検索され、フレームに動的パラメータが存在する場合には、それらが全体のデータストリームにはめ込むような適合処理がおこなわれる。すなわち、復号化のために適切に受信されたものの何らかの理由から復号化されない通常のサービスデータフレームは、単純な方法でエミュレートされ、データ損失の状況によるデコーダの障害を防ぐ。図１３においては、パラメータ１３０４および１３０６が、現行のシナリオに基づいて適合される。関連する双方向サービスによって、格納されるフレームは、局所的に調整可能な多くのパラメータを有する単なるスケルトンだけからなるタイプである場合もあれば、その全く反対のタイプからなる場合もある。このような格納フレームを直接使用することで、何ら調整することなく符号化をおこなうことができる。いずれにせよ、任意に適合されたフレームは、最終的に伝送されて符号化される。

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

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

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

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

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

ＤＶＢ−Ｓ仕様に準拠するＤＶＢ伝送システムを示す説明図である。 ＤＶＢ−Ｃ仕様に準拠するＤＶＢ伝送システムを示す説明図である。 ＤＶＢ−Ｔ仕様に準拠するＤＶＢ伝送システムを示す説明図である。 ＩＰネットワークの、ＤＶＢサービスデータの配信ネットワークとしての使用を示す説明図である。 典型的なＭＰＥＧ−２伝送システムを示す説明図である。 ＭＰＥＧ−２ソース符号化を空間的および時間的に示す説明図である。 サービスデータソースにフィードバック／制御情報を提供可能なＤＶＢセットトップボックスへのＤＳＬ／ケーブルネットワーク上でのサービス配信を示す説明図である。 局所的に格納された予測フレームを用いて、受信側セットトップボックスにおいて以前に受信されたデータフレームとこれから受信されるデータフレームとの違いを補填するシナリオを示す説明図である。 本発明の方法を適用した際の受信側セットトップボックスの内部を示す説明図である。 本発明にかかる方法のフローチャートである。 本発明のサービスデータソースとして作用可能な装置のブロック図である。 本発明のサービスデータの受け手として作用可能な装置のブロック図である。 格納される予測フレームの使用について示す説明図である。

Claims (33)

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. 前記事象は、特定フレームの要求の受信またはその表示と、前記特定フレームを伝送する必要があることを示すパラメータを有するメッセージの受信と、前記特定フレームを伝送する必要があることを示すパラメータ値を有するメッセージの受信と、データ転送接続の確立または開始と、のうちの少なくともいずれか一つであることを特徴とする請求項２５に記載の装置。
27. 前記サービスは、デジタルブロードバンドサービス、デジタルブロードキャストサービス、およびＤＶＢ（デジタルビデオ放送）サービスのうちの少なくともいずれか一つであることを特徴とする請求項２５に記載の装置。
28. 前記圧縮サービスデータは、ビデオピクチャデータを含むことを特徴とする請求項２５〜２７のいずれか一つに記載の装置。
29. 前記ビデオピクチャデータは、ＭＰＥＧ−２（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）によって符号化されることを特徴とする請求項２８に記載の装置。
30. 前記装置は、サーバであることを特徴とする請求項２５〜２９のいずれか一つに記載の装置。
31. 配信ネットワーク上でサービスデータを転送することができるシステムであって、
    前記サービスデータは、共通のデータタイプからなる予測データフレームおよび非予測データフレームの両方を含み、
    前記システムは、サービスデータを伝送し制御情報を受信することができる第１の装置と、サービスデータを受信して制御情報を伝送することができる第２の装置と、を含み、
    前記第１の装置および前記第２の装置の両装置は、指示を処理する処理手段と、データを格納するメモリ手段と、を備え、
    前記第１の装置は、所定の事象の発生を監視するように構成されるとともに、前記サービスデータ配信の開始時、または前記特定フレームの要求の送信に応じた時に、所定の特定フレームまたは前記特定フレームに関する情報を前記第２の装置に伝送する伝送手段をさらに備え、
    前記特定フレームは、以前にあったと想定されるサービスデータフレームに対して当該サービスデータにおける実質的な変更が無いことを示す予測フレームであり、
    前記特定フレームに関する情報はパラメータを有し、前記パラメータは現行のサービスデータストリームに合わせて調整され、
    前記第２の装置は、前記サービスデータ配信の開始時に前記所定の特定フレームまたは前記特定フレームに関する情報を受信して格納し、サービスデータ受信バッファが所定の基準によって少なくともアンダーフロー状態に近い状態であるかどうかを監視し、前記所定の基準は、前記バッファ中のデータ量に対する閾値または最後にフレームが受信された時からの経過時間のいずれかを含み、少なくともアンダーフロー状態に近い状態である場合には、前記特定フレームを前記デコーダに供給することによって、入力データが適時に供給されないことによるデコーダの障害を防ぐように構成されることを特徴とするシステム。
32. 請求項１〜１４のいずれか一つに記載の方法ステップを実行するためのコンピュータプログラム。
33. 請求項３２に記載のコンピュータで実行可能なプログラムを記録した持ち運び可能なメディア。

Images