JP2010514346A - Ｉｐｔｖの低ビットレートのストリームを使用したビデオデータ損失回復システム - Google Patents

Abstract

【課題】
データ損失から回復するシステムおよび方法が記載されている。
【解決手段】
本発明は、フレームの損失および障害のうちの１つがあるかどうかを判断するために第１のビットレートのビデオデータビットストリームをモニタすることと、フレームの損失および障害のうちの１つがある場合、第２のビットレートのビデオデータビットストリームのデコード・パラメータ、前記第２のビットレートのビデオデータビットストリーム、および前記第１のビットレートのビデオデータビットストリームを多重通信することと、前記第１のビットレートのビデオデータビットストリーム、および前記第２のビットレートのビデオデータビットストリームをデマルチプレクスすることと、前記第１のビットレートのビデオデータビットストリームをデコードすることと、前記第１のビットレートのビデオデータビットストリームから障害を受けたフレームを取り除くことと、前記第２のビットレートのビデオデータビットストリームをデコードすることと、前記処理された第２のビットレートのビデオデータビットストリームが前記処理された第１のビットレートのビデオデータビットストリームより低い解像度を有する場合、前記処理された第２のビットレートのビデオデータビットストリームからのフレームをアップサンプリングすることと、前記処理された第２のビットレートのビデオデータビットストリーム、および前記処理された第１のビットレートのビデオデータビットストリームからのフレームをマージすることと、を有する。

Description

本発明は、一般に、インターネット・プロトコル・テレビ（ＩＰＴＶ）に関する。より詳細には、低ビットレートのビットストリームの使用におけるＰＴＶシステムのビデオデータ損失からの回復に関する。

［国家ライセンシング権（ＧＯＶＥＲＮＭＥＮＴ ＬＩＣＥＮＳＥ ＲＩＧＨＴＳ）］
アメリカ政府は、この発明に対してライセンス料を支払っており、限定的な状況において特許権者は、米国標準技術研究所（Ｎａｔｉｏｎａｌ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｓｔａｎｄａｒｄｓ Ａｎｄ Ｔｅｃｈｎｏｌｏｇｙ）が取り交わした契約番号７０ＮＡＮＢ３Ｈ３０５３に規定するリーズナブルな条件で、他の者に、ライセンスを与える。

例えばＭＰＥＧ２（ｍｏｔｉｏｎ ｐｉｃｔｕｒｅ ｅｘｐｅｒｔｓ ｇｒｏｕｐ）またはＨ．２６４といった高度なビデオ・コーダー・デコーダ（ＣＯＤＥＣ）は、高圧縮率を得るためにイントラ符号化およびインター符号化が利用される。インター符号化画像は、圧縮のための他の画像からの情報を使用する。したがって、圧縮された画像のパケット／フレームの損失は、画像自体の品質を劣化させるだけでなく、インター符号化予測のためにその画像を参照している全ての画像の品質に影響を及ぼす。例えば、Ｉフレームのパケット損失は、グループオブピクチャ（ＧＯＰ）の全ての画像に潜在的な悪影響を及ぼす。

図１ａに示すように、商業的なデジタルＴＶ同報通信システムにおいて、ビデオ・データストリームは、ヘッドエンドのストリーミングサーバからバックボーン・ネットワークを介して多くのマルチキャストスイッチに送られ、そこから、ビデオ・データストリームは多数の住居のセットトップボックスにマルチキャストされる。バックボーンの転送におけるデータの完全性は、非常に重要である。バックボーンの転送のいかなるパケット損失も、図１ｂに示すように全てのダウンストリームのセットトップボックスに広がる。

リアルタイム・ストリーミングにおいては、ユーザーデータグラム・プロトコル（ＵＤＰ）が、トランスポートストリームにしばしば使われる。ＵＤＰそれ自体には、サービス品質が保証されていない。前向き誤り訂正（ＦＥＣ）または選択的な再送技術はパケット損失率をかなり減少させる。高品質の商業ビデオ・サービス（例えばエラーのない時間の割合が９９．９９９％）を提供するために、バックボーン・ネットワークにおいてパケット損失率は非常に低くなければならない（１×１０Ｅ−６未満）。これは、ＩＴＵのＹ．１５４１においてクラス０で定められるネットワークサービス（最高）の１×１０Ｅ−３のパケット損失率よりもはるかに小さい値である。しかし、現実のシステムでのパケット損失は、さまざまな理由のためにまだ生ずることがある。

パケット損失が生じた場合、エンドユーザに示される主観的なビデオアーチファクトを減少させることが重要である。エラーコンシールメント技術が、このため通常用いられる。エラーコンシールメント技術は、損なわれた領域またはフレームのエラーを隠すために、時間的あるいは空間的に近い情報を利用する。しかしながら、失われたパケットが参照フレーム（ＩまたはＰ）データを含むとき、または、多数の連続フレームが完全に失われたときには、エラーコンシールメントは一般に良好なパフォーマンスを示さない。

今までの努力は、マルチキャスト・バックボーン・ネットワークのパケット損失率を減らすためのものであった。ＦＥＣは、サービス品質（ＱｏＳ）を非常に向上させる有力な方法である。一部の最近の研究は、ＦＥＣアルゴリズムを改善することに集中している。しかしながら、強いＦＥＣはしばしば高い計算パワーを必要とし、かつビデオ・データストリームの転送に対して重大で付加的な待ち時間が発生してしまう。なお、弱いＦＥＣは通常、長期にわたる停止期間（例えば＞２秒）のため、十分なパフォーマンスを有しない。適応ＦＥＣは動的にＥＦＣの強さを調整するために双方向通信を使用する。しかしながら、システムの複雑度が非常に高くなる。

一部のＩＰＴＶシステム（例えばＭＳＴＶ：ｍａｘｉｍｕｍ ｓｅｒｖｉｃｅ ｔｅｌｅｖｉｓｉｏｎ）は、損失からの回復に再転送を実行する。２種類のマルチキャスト・データ損失回復方式が存在する。ソースベース回復と分散回復である。効率および回復待ち時間に関して、分散マルチキャスト・データ損失回復方式は、ソースベースビデオ・データ損失回復方式を通常上回る。効率および回復待ち時間の両者は、大規模なビデオ・マルチキャストのために重要である。しかし、分散損失回復方式は、階層的なネットワークトポロジの異なるレベルの複数ノードに配置されるアクティブな損失回復コンポーネントを必要とする。ソースベース回復方式はインプリメントするのがより容易で、かつネットワークにおいて、より少ないアクティブコンポーネントしか必要としない。しかし、大規模な配備に対しては効率的でない。また、サーバに多数の再送要求、すなわち否定応答（ＮＡＫ）があふれるという、内破的な課題がある。

厳しいＱｏＳレベルを要求する一部の商業システムにおいては、バックボーンの転送のための冗長な経路を使用する。１つが主要な経路のために使われ、もう一つがバックアップ・パスとして使われる。この種のシステムは非常に高い信頼性を有するが、ネットワーク転送にかかるコストはほぼ２倍になる。

本発明は、上記の課題に対処する。

本発明において、ビデオ・データ・フレームは、低ビットレート、および、普通の／通常のビットレートでビデオデータビットストリームにエンコードされる。ここで使用している「／」は、同じ構成要素またはコンセプトの代わりの名前を示すために用いる。これらの２つのストリームはビデオサーバによって２つの別々のマルチキャストグループのバックボーン・ネットワークを介してプロクシサーバに転送される。プロクシサーバは、一つ以上のマルチキャストスイッチに接続する。マルチキャストスイッチから、ビデオデータビットストリームは、多数のビデオ端末（例えばセットトップボックス）に選択的にマルチキャストされる。標準状態の下では、低ビットレートのビデオデータビットストリームは、スイッチ、およびセットトップボックスの間をマルチキャストで接続しているパスのいかなるバンド幅も消費しない。

プロクシサーバは、通常のビデオデータビットストリームのパケット損失をモニタする。パケット損失イベントが検出された場合、プロクシサーバは、低ビットレートのビデオデータビットストリームのデコード・パラメータ（例えばシーケンス・パラメータ・セット（ＳＰＳ）、および、画像パラメータ・セット（ＰＰＳ））および通常のビットレートのビデオデータビットストリームの不足している部分に対応する低ビットレートのビデオデータビットストリームを通常のビデオデータビットストリームのマルチキャストグループに多重送信する。受信したセットトップボックスは、低ビットレート、および、通常のビットレートのビデオデータビットストリームをデマルチプレックスし、かつ通常のビットレートのビデオ・データストリームにおいて損失されまたはダメージを受けたフレームを隠すために、低ビットレートのビデオデータビットストリームからデコードされたフレームを使用する。同じ低ビットレートのビデオデータビットストリームを、速いチャネル切り替え、および、ピクチャーインピクチャまたはモザイク表示のために使うことができる。モザイク表示とは、写真のサムネイルのようなものである。これは、１つのスクリーン上に同時に多数のビデオの（例えば１２）チャンネルを示すものである。

データ損失から回復するシステム、および方法が記載されており、これらは、フレームの損失および障害のうちの１つがあるかどうかを判断するために第１のビットレートのビデオデータビットストリームをモニタすることと、フレームの損失および障害のうちの１つがある場合、第２のビットレートのビデオデータビットストリームのデコード・パラメータ、前記第２のビットレートのビデオデータビットストリーム、および前記第１のビットレートのビデオデータビットストリームを多重通信することと、前記第１のビットレートのビデオデータビットストリーム、および前記第２のビットレートのビデオデータビットストリームをデマルチプレクスすることと、前記第１のビットレートのビデオデータビットストリームをデコードすることと、前記第１のビットレートのビデオデータビットストリームから障害を受けたフレームを取り除くことと、前記第２のビットレートのビデオデータビットストリームをデコードすることと、前記処理された第２のビットレートのビデオデータビットストリームが前記処理された第１のビットレートのビデオデータビットストリームより低い解像度を有する場合、前記処理された第２のビットレートのビデオデータビットストリームからのフレームをアップサンプリングすることと、前記処理された第２のビットレートのビデオデータビットストリーム、および前記処理された第１のビットレートのビデオデータビットストリームからのフレームをマージすることと、を有する。

本発明は添付の図面とともに以下の詳細な説明を読むことによって最も理解される。

従来のマルチキャストＩＰＴＶシステムの概要図である。 速いチャネル切り替えのために使用する低ビットレートのビデオデータビットストリームの実施例である。 通常の（一般的な）ビットレートのビデオデータビットストリームのデータ損失を回復するために使用する低ビットレートのビットストリームの概要図である。 ビデオ／データの悪化の開始および終了のマーキングを示す図である。 プロクシサーバによって実行される損失検出方法のフローチャートである。 ストリーム受信、デマルチプレクス、デコーディング、および、フレーム回復を実行するセットトップボックスの詳細を示す図である。 従来のデータ回復と本発明のビデオ回復を比較する詳細な図である。 低ビットレートのビットストリームのより短い画像グループを使用することの有利な効果を示す図である。

本発明においては、低ビットレート（例えば２００Ｋｂｐｓ）、および、短いＧＯＰサイズ（例えば０．５秒）のビデオ・データストリームがエンコードされ、かつ通常のビデオ・データストリームによって転送される。低ビットレートのビデオストリームは、通常のビデオストリームよりもより低い解像度（例えばＣＩＦ）または同じ解像度でより低いビデオ品質でありうる。図２Ａは、チャネル切り替えの間における、通常のビデオデータビットストリームおよび低ビットレートのビデオデータビットストリームの転送を示している。図２Ｂは、チャネル切り替えの後の、通常のビデオデータビットストリームを示している（低ビットレートのビデオ・データストリームの転送は無い）。また、図２Ａは、低ビットレートのビデオデータビットストリームからデコードされ表示されるフレームを示している。通常および低いビデオ・データ・ビットレートにおける転送は、タイムシフトがゼロの同報または、固定または設定可能な時間間隔（例えば２秒）の時間差のある同報（ｓｔａｇｇｅｒｃａｓｔ）である。時間差のある同報（Ｓｔａｇｇｅｒｃａｓｔｉｎｇ）は、１つのネットワーク不具合によって、同じメディア時間に両方のストリームのパケット損失が生じる可能性を最小化するため好適な方法である。時間差のある同報のシナリオにおいて、低ビットレートのビデオ・データ・ビットレートストリームは、通常のストリームに対して、ある時間間隔（例えば２秒）遅れるか、早くなってもよい。

標準状態の下で、２つのビデオデータビットストリームは、２つの別のマルチキャストグループに送られるため、各々のビデオデータビットストリームは別々に接続されることができ、エンドユーザによって使われても、使われなくてもよい。このことはネットワークの最後のセグメントのバンド幅を減らすことになる。それはマルチキャストスイッチと、セットトップボックスとの間である。デジタル加入者線（ＤＳＬ）設備においては、最後のセグメントは、ＤＳＬアクセス・マルチプレクサ（ＤＳＬＡＭ）と、セットトップボックスとの間の加入回線（local loop）である。そして、これはしばしばＩＰＴＶシステムのバンド幅のボトルネックとなっている。したがって、ＤＳＬＡＭバンド幅の使用を減らすことが重要である。

本発明の有利な効果は、低ビットレートのビデオデータビットストリームがピクチャインピクチャ（ＰＩＰ）の表示または速いチャネル切り替えのために使うことができるということである。それらのアプリケーションにおいて、低ビットレートのビデオデータビットストリームは、セットトップボックス（ＳＴＢ）によって要請されるときにのみＳＴＢにキャストされる。図２は、チャネル切り替えアプリケーションのストリーミングである。

［好適な実施例の詳細な説明］
本発明は、バックボーン・ネットワーク、および、マルチキャストスイッチの間に設置されるプロクシサーバを提供する。通常のビットレートのビデオデータビットストリーム、および、低ビットレートのビデオデータビットストリームの両者は、プロクシサーバによって受信され、特定の期間（例えば５秒）バッファリングされ／格納される（メモリ格納デバイス）。また、デコード・パラメータ（例えばＳＰＳ、Ｈ．２６４ストリームのためのＰＰＳ）は、プロクシサーバに保存される。プロクシサーバは、通常のビットレートのビデオデータビットストリームのいかなるパケット損失（ＱＯＳ）もモニタする。それがパケット損失または障害のあるパケットを検出した場合、プロクシサーバは、まずメディアプレゼンテーションタイムスタンプを検出する。メディアプレゼンテーションタイムスタンプは、ビデオ悪化イベントの始まり（Ｔｂ）に対応する。Ｈ．２６４ベースラインプロファイルエンコーディングのような、Ｂピクチャを持たないビデオエンコーディングにおいては、Ｔｂは、最後に良好に受信されたフレームのメディアプレゼンテーションタイムである。Ｂピクチャを持つビデオエンコーディングにおいては、Ｔｂは、オープンＧＯＰでエンコードされている場合には、最後に良好に受信されたＢフレームのメディアプレゼンテーションタイムである。また、クローズドＧＯＰでエンコーディングされている場合には、最後に良好に受信されたＢまたはＩフレームのメディアプレゼンテーションタイムである。タイムスタンプＴｂは、パケット損失イベントの始まりをマークしている。その後プロクシサーバは、そのローカルバッファに格納されている低ビットレートのビデオデータビットストリームおよび受信されたストリームを検索し、ちょうどＴｂの前にあるタイムスタンプを持つＩフレームを検索する。プロクシサーバのバッファサイズは、このＩフレームがほとんどの場合見つかるような容量に設定される。その後、プロクシサーバは、低ビットレートのビデオデータビットストリームのデコード・パラメータを送り、その後、Ｉフレームからはじまる低ビットレートのビデオデータビットストリームを、通常のビットレートのビデオデータビットストリームのマルチキャストグループに、別のプログラムとして配信する（図３）。なお、低ビットレートのビデオデータビットストリーム・パケットのこの「パッチング」は、通常のビットレートのビデオデータビットストリームと統合されるのではなく、通常のビットレートのビデオデータビットストリームのマルチキャストトランスポートグループの中で、別個のストリームとして転送されるという点に留意されたい。通常のビットレートのビデオデータビットストリームに、低ビットレートのビデオデータビットストリームを実際に「パッチング」しマージするのは、セットトップボックスで実行される。

それからプロクシサーバは、ビデオ悪化のイベントの終わりを検索する。ビデオ悪化イベントの終わりに対応するプレゼンテーションタイムスタンプは、プロクシサーバによってＴｅとして記録される。プロクシサーバは、低ビットレートのＩフレームのプレゼンテーションタイムスタンプがＴｅよりちょうど大きくなるＩフレームを検出するまで、全ての低ビットレートのビデオデータビットストリーム・パケットを伝送する。これによって、プレゼンテーションタイムスタンプがＴｅより小さい全ての低ビットレートのビデオデータビットストリーム・パケットがプロクシサーバによって転送されることを確実にする。したがって、多重化された低ビットレートのビデオデータビットストリーム・パケットは通常のビットレートのビデオデータビットストリームの全ての失われた部分をカバーすることになる。

パケット損失が終わっても、一般に、これがビデオ悪化の終わりを意味しない。なぜなら、失われたり障害を受けたりした画像は、後続の画像により参照用画像として使われるからである。一般に、通常のビットレートで、次に受信した良好なＩフレーム（ＰＥＧ２、および、Ｈ．２６４）または、中間データレート（ＩＤＲ）フレーム（Ｈ．２６４）が、ビデオ悪化イベントの終わりであると見なされる。図４は、ビデオ悪化の終わりのタイムスタンプを示している。詳細には、ケースＡの場合には、Ｂフレームは通常のビットレートのビデオデータビットストリームにおいてエンコードされないケースである。この場合、ビデオ悪化イベントＴｂの始まりは、失われたＰフレームの直後に後続するＰフレームの直前にＴｂがマーキングされる。これに対応して、ビデオ悪化イベントの終わりＴｅは、次のＩフレームの直前にマーキングされる。

ケースＢは、Ｂフレームが通常のビットレートのビデオデータビットストリームに存在する場合である。ビデオ・フレームは、デコードされた順に転送される。失われた通常のビットレートのビデオデータビットストリームフレームは１８、２０、２２、３２、および、２６であり、これらはデコードの順番としては連続している。ビデオ悪化イベントＴｂの始まりは、失われたと認識されたＰフレームが直後に後続するＢフレームの直前にマーキングされる。これに対応して、ビデオ悪化イベントの終わりＴｅは、次のＩフレームの直前にマーキングされる。ビデオ・フレームは、低ビットレートのフレームとともに、番号順に表示され、低ビットレートのビデオデータビットストリームが、表示順の中に埋め込まれる（デコード順の連続する順番ではない）。

図５は、プロクシサーバによって通常のビットレートのビデオデータビットストリームにおけるフレーム中で実行される損失検出方法のフローチャートである。失われたフレームが検出され、ビデオ悪化イベント（Ｔｂ、Ｔｅ）がマーキングされると、低ビットレートのビデオデータビットストリームフレームは通常のビットレートのビデオデータビットストリーム中に多重送信される。５０５で、パケット／フレーム損失が検出されたかどうかを判断するために、テストが実行される。パケット／フレーム損失が検出されなかった場合、この処理が繰り返される。損失のあるパケット／フレームが検出された場合、５１０においてビデオ悪化イベントＴｂの始まりがマーキングされ、かつ記録される。５１５で、後ろ向き検索が実行される。後ろ向き検索は、バッファを検査し、低ビットレートのビデオデータビットストリームの、タイムスタンプがＴｂと等しいか小さい最初のＩフレームを探す。５２０で、低ビットレートのビデオデータビットストリームのＩフレームの位置が見つかったかが検査される。Ｉフレームがない場合、受信されつつある低ビットレートのビデオデータビットストリームが検索され、Ｔｂと等しいか小さいＩフレームを５２５において探す。５３０で、低ビットレートのビデオデータビットストリームのＩフレームが存在するかの検査が実行される。もしＩフレームが存在しない（発見されない）場合、検査がタイムアウトとなるかどうかが５３５で判断される。タイムアウトとなっていない場合、５２５の検査が繰り返される。タイムアウトとなった場合、処理５０５が繰り返される。５２０で低ビットレートのビデオデータストリームにＩフレームが存在する場合、低ビットレートのビデオデータビットストリームフレームは、５４０で通常のビットレートのビデオデータビットストリームに多重送信される。５４５で、ビデオ悪化損失の終わりが検出されたかどうかの判断が実行される。ビデオ悪化損失の終わりが検出されなかった場合、５４０が繰り返される。ビデオ悪化損失の終わりが検出された場合、ビデオ悪化損失の終わりのタイムスタンプＴｅの特定が５５０で行われ、低ビットレートのビデオ・データストリームの最後のＩフレームのタイムスタンプがＴｅより大きいかどうかの判断が５５５で実行される。タイムスタンプがＴｅより大きくない場合、５６０で通常のビットレートのビデオデータビットストリームに低ビットレートのビデオデータビットストリームのパケットを多重送信し続ける。タイムスタンプがＴｅより大きい場合、多重化を停止して、かつ処理５０５を繰り返す。

通常のビットレートのビデオデータビットストリーム・マルチキャストグループへの低ビットレートのビデオデータビットストリームの多重化は、重要である。このことによって、ＳＴＢがアクティブにこれを要求することなく低ビットレートのビデオデータビットストリームを受信することが可能となる。そうでないと、マルチキャスト結合（Ｊｏｉｎ）コマンド（例えばネットワーク間のグループ管理プロトコル（ＩＧＭＰ）ジョイン）が、低ビットレートのビデオデータビットストリームを受信するために、ＳＴＢによって送信されなければならないことになる。パケット損失イベントによって、このプログラムに同調している全てのＳＴＢは、マルチキャストスイッチに対して、同時にマルチキャスト結合コマンドを送信することになり、その結果、このコマンドであふれることになる。本発明において、ＳＴＢは、通常のチャネルからデータを受け取るだけである。プロクシサーバは、通常のビットレートのビデオデータビットストリームの損失または障害が検出された場合、アクティブに、通常のビットレートのビデオデータビットストリームとともに通常のチャネルに低ビットレートのビデオデータビットストリームを（なお、別のプログラムとして）送信する。図６に示すように、ＳＴＢは、両方のプログラムを通常のチャネルから受け取って、プログラム番号に基づいて、２つのプログラムをデマルチプレックスし、それらを別々にデコードする。通常のビットレートのビデオデータビットストリームのためのデコーダは、ビデオストリームをデコードし、かつ障害を受けたビデオ・フレームを除去する。エラー修正モジュールは、デコードされた低ビットレートのビデオデータビットストリームフレームをデコードされた通常のビットレートのビデオデータビットストリームにマージする。低ビットレートのビデオデータビットストリームが通常のビットレートのビデオデータビットストリームより低い解像度を有する場合、エラー修正モジュールは、それらが、デコードされた通常のビットレートのビデオデータビットストリームフレームと同じ解像度を有するよう、デコードされた低ビットレートのビデオデータビットストリームフレームをアップサンプリングする。

図７は、通常のビットレートのビデオデータビットストリームにおいて失われるデータを回復するために使用する低ビットレートのビデオデータビットストリームの使用の詳細な図である。具体的には、図７は、従来技術、および、本発明の間の比較である。低ビットレートのビデオデータビットストリームが通常のビットレートのビデオデータビットストリームより低い解像度を有する場合、デコードされた低ビットレートのビデオデータビットストリームは通常のビットレートのビデオデータビットストリームと同じになるようアップサンプリングされる。そして、図７に示すように、通常のビットレートのビデオデータビットストリーム内において失われたり障害を受けたりしたフレームを置換または回復する。置き換えられまたは回復されたフレームは、それからディスプレイ装置に送信される。従来技術においては、データ損失によって、通常のビットレートのビデオデータビットストリームのフレーム損失が生じてしまう。本発明においては、データの損失は、通常のビットレートのビデオデータビットストリームの失われたフレームを低ビットレートのビデオ・データ・フレームと置き換えることによって回復される。

冗長なデータとしてＦＥＣ、パリティまたは空間スケーラブルビデオコーディングを使用するよりも、低ビットレートのビデオデータビットストリームを使用することの効果としては、低ビットレートのビデオデータビットストリームをピクチャーインピクチャ、モザイク表示または速いチャネル切り替えストリームのために使うことができるということである。

通常のビットレートのビデオデータビットストリームで障害を受けたり失われたりしたフレームの置換がデコーディングの後で実行されるということが重要である。したがって、本発明は、どちらのストリームのデコードプロセスも中断する必要はない。また、同じＧＯＰの他のフレームの変更をせずに、通常のビットレートのビデオデータビットストリームの単一のフレームを置き換えることが可能である。

また、低ビットレートのビデオデータビットストリームのＧＯＰサイズが通常のストリームのサイズより短いことも重要である。通常のビットレートのビデオデータビットストリームの一部が失われたり障害を受けたりしたときに、プロクシサーバはＳＴＢに低ビットレートのビデオデータビットストリームの対応するＧＯＰを転送するだけでよい。図４のケースＡは、通常のビットレートのビデオデータビットストリームのＢフレームがないときの場合であり、この場合、ビデオ悪化イベントの持続時間がＧＯＰサイズより短くなる。したがって、悪化の期間をカバーするために必要とする低ビットレートのビデオデータビットストリームフレームの「パッチング」は、通常のビットレートのビデオデータビットストリームのＧＯＰサイズより短くてよい。これを図８に示す。ここで、障害を受けた通常のビットレートのビデオデータビットストリームの部分は、網掛／陰影をつけていない部分である。低ビットレートのビデオデータビットストリームのＧＯＰ４だけがエラー回復のために必要とされる。

本発明は、様々な形式のハードウェア、ソフトウェア、ファームウェア、専用プロセッサまたはこれらの組合せでインプリメントされてもよいことを理解すべきである。望ましくは、本発明は、ハードウェアおよびソフトウェアの組合せとしてインプリメントされる。さらに、プログラム記憶領域デバイスに実際に格納されたソフトウェアは、好ましくはアプリケーションプログラムとしてインプリメントされる。アプリケーションプログラムは、適切ないかなるアーキテクチュアのマシンにアップロードされ実行されてもよい。望ましくは、マシンは、ハードウェア、例えば一つ以上の中央処理装置（ＣＰＵ）、ランダムアクセスメモリ（ＲＡＭ）、および、入出力（Ｉ／Ｏ）インターフェース（ｓ）を有するコンピュータプラットフォームにインプリメントされる。コンピュータプラットフォームは、また、オペレーティングシステム、および、マイクロ命令コードを含む。本願明細書に記載されているさまざまな方法、および、機能はマイクロ命令コードの一部であってもアプリケーションプログラムの一部、またはそれらの組合せであってもよい。そして、それはオペレーティングシステムを介して実行される。加えて、さまざまな他の周辺デバイスが、コンピュータプラットフォーム、例えば追加データ記憶機構デバイス、および、プリンタに接続されてもよい。

添付の図において表されるいくつかの構成されたシステムコンポーネント、および、方法ステップは、好ましくはソフトウェアでインプリメントされるため、システムコンポーネント（または方法ステップ）と、実際の接続は、本発明がプログラムされる方式によって、異なることが有り得る点を理解すべきである。本願明細書における記述によって、関連技術の当業者は、本発明に類似した実装または構成を考案することが可能である。

Claims (24)

1. データ損失から回復する方法であって：
   フレームの損失および障害のうちの１つがあるかどうかを判断するために第１のビットレートのビデオデータビットストリームをモニタするステップと；
   フレームの損失および障害のうちの１つがある場合、第２のビットレートのビデオデータビットストリームのデコード・パラメータ、前記第２のビットレートのビデオデータビットストリーム、および前記第１のビットレートのビデオデータビットストリームを多重通信するステップであって、前記第２のビットレートのビデオデータビットストリームは、前記第１のビットレートのビデオデータビットストリームより低いビットレートを有するところのステップと；
   前記第１のビットレートのビデオデータビットストリーム、および前記第２のビットレートのビデオデータビットストリームをデマルチプレクスするステップと；
   処理された第１のビットレートのビデオデータビットストリームを生成するために、前記第１のビットレートのビデオデータビットストリームをデコードするステップと；
   前記処理された第１のビットレートのビデオデータビットストリームから障害を受けたフレームを取り除くステップと；
   処理された第２のビットレートのビデオ・データストリームを生成するために、前記第２のビットレートのビデオデータビットストリームをデコードするステップであって、前記処理された第２のビットレートのビデオデータビットストリームは、前記処理された第１のビットレートのビデオデータビットストリームより低いビットレートを有するところのステップと；
   前記処理された第２のビットレートのビデオデータビットストリームが前記処理された第１のビットレートのビデオデータビットストリームより低い解像度を有する場合、前記処理された第２のビットレートのビデオデータビットストリームからのフレームをアップサンプリングするステップと；
   前記処理された第２のビットレートのビデオデータビットストリーム、および前記処理された第１のビットレートのビデオデータビットストリームからのフレームをマージするステップと；
   を有する方法。
2. 前記第１のビットレートのビデオデータビットストリーム、および、前記第２のビットレートのビデオデータビットストリームは、サイマルキャストされる、請求項１記載の方法。
3. 前記第１のビットレートのビデオデータビットストリーム、および、前記第２のビットレートのビデオデータビットストリームは、時間差をつけて同報（staggercast）される、請求項１記載の方法。
4. 前記第１のビットレートのビデオデータビットストリームを第１のマルチキャストグループに発信するステップと；
   前記第２のビットレートのビデオデータビットストリームを第２のマルチキャストグループに発信するステップと；
   をさらに有する請求項１記載の方法。
5. 前記第２のビットレートのビデオデータビットストリームは、速いチャネル切り替えを達成するために用いられる、請求項１記載の方法。
6. 前記第２のビットレートのビデオデータビットストリームは、ピクチャーインピクチャのために用いられる、請求項１記載の方法。
7. 前記第２のビットレートのビデオデータビットストリームは、モザイク表示のために用いられる、請求項１記載の方法。
8. ビデオ悪化イベントの始まりを特定するステップと；
   前記ビデオ悪化イベントの終わりを特定するステップと；
   を更に有する請求項１記載の方法。
9. 前記ビデオ悪化イベントの前記始まりの前における最初のＩフレームを検出するために、メモリ格納構成要素内を後ろ向きに検索し、かつ、受信されつつある第２のビットレートのビデオデータビットストリーム内を前向きに検索するステップと；
   前記ビデオ悪化イベントの前記終わりの後の最初のＩフレームを検出するための、前記メモリ格納構成要素、および、前記受信されつつある第２のビットレートのビデオデータビットストリームのうちの１つの中で検索するステップと；
   を更に有する請求項８記載の方法。
10. 前記多重通信するステップの処理は、前記第１のビットレートのビデオデータビットストリームで前記損失しまたは障害を受けたフレームのうちの１つに対応する前記第２のビットレートのビデオデータビットストリームのグループオブピクチャを選択的に多重送信する、請求項９記載の方法。
11. 前記第２のビットレートのビデオデータビットストリームの前記グループオブピクチャの解像度は、前記第１のビットレートのビデオデータビットストリームの前記グループオブピクチャの解像度に等しいか、または、より低いかのうちのいずれか一つである、請求項１０記載の方法。
12. データ損失から回復する方法であって：
    マルチキャストグループ内の多重化ビデオデータビットストリームを受信するステップと；
    前記受信されたビデオデータビットストリームを、第１のビットレートのビデオデータビットストリーム、および第２のビットレートのビデオデータビットストリームにデマルチプレクスするステップであって、前記第２のビットレートのビデオデータビットストリームは、前記第１のビットレートのビデオデータビットストリームで損失しまたは障害を受けたフレームのうちの１つに対応するフレームを含んでおり、前記第２のビットレートのビデオデータビットストリームは、前記第１のビットレートのビデオデータビットストリームより低いビットレートを有するところのステップと；
    前記第２のビットレートのビデオデータビットストリームからのフレームを、前記第１のビットレートのビデオデータビットストリームで損失しまたは障害を受けたフレームのうちの１つの置換および回復を行うフレームの１つにデコードするステップと；
    を有する方法。
13. データ損失から回復するシステムであって：
    フレームの損失および障害のうちの１つがあるかどうかを判断するために第１のビットレートのビデオデータビットストリームをモニタする手段と；
    フレームの損失および障害のうちの１つがある場合、第２のビットレートのビデオデータビットストリームのデコード・パラメータ、前記第２のビットレートのビデオデータビットストリーム、および前記第１のビットレートのビデオデータビットストリームを多重通信する手段であって、前記第２のビットレートのビデオデータビットストリームは、前記第１のビットレートのビデオデータビットストリームより低いビットレートを有するところの手段と；
    前記第１のビットレートのビデオデータビットストリーム、および前記第２のビットレートのビデオデータビットストリームをデマルチプレクスする手段と；
    処理された第１のビットレートのビデオデータビットストリームを生成するために、前記第１のビットレートのビデオデータビットストリームをデコードする手段と；
    前記処理された第１のビットレートのビデオデータビットストリームから障害を受けたフレームを取り除く手段と；
    処理された第２のビットレートのビデオ・データストリームを生成するために、前記第２のビットレートのビデオデータビットストリームをデコードする手段であって、前記処理された第２のビットレートのビデオデータビットストリームは、前記処理された第１のビットレートのビデオデータビットストリームより低いビットレートを有するところの手段と；
    前記処理された第２のビットレートのビデオデータビットストリームが前記処理された第１のビットレートのビデオデータビットストリームより低い解像度を有する場合、前記処理された第２のビットレートのビデオデータビットストリームからのフレームをアップサンプリングする手段と；
    前記処理された第２のビットレートのビデオデータビットストリーム、および前記処理された第１のビットレートのビデオデータビットストリームからのフレームをマージする手段と；
    を有するシステム。
14. 前記第１のビットレートのビデオデータビットストリーム、および、前記第２のビットレートのビデオデータビットストリームは、サイマルキャストされる、請求項１３記載のシステム。
15. 前記第１のビットレートのビデオデータビットストリーム、および、前記第２のビットレートのビデオデータビットストリームは、時間差をつけて同報（staggercast）される、請求項１３記載のシステム。
16. 前記第１のビットレートのビデオデータビットストリームを第１のマルチキャストグループに発信する手段と；
    前記第２のビットレートのビデオデータビットストリームを第２のマルチキャストグループに発信する手段と；
    を更に有する請求項１３記載のシステム。
17. 前記第２のビットレートのビデオデータビットストリームは、速いチャネル切り替えを達成するために用いられる、請求項１３記載のシステム。
18. 前記第２のビットレートのビデオデータビットストリームは、ピクチャーインピクチャのために用いられる、請求項１３記載のシステム。
19. 前記第２のビットレートのビデオデータビットストリームは、モザイク表示のために用いられる、請求項１３記載のシステム。
20. ビデオ悪化イベントの始まりを特定する手段と；
    前記ビデオ悪化イベントの終わりを特定する手段と；
    を更に有する請求項１３記載のシステム。
21. 前記ビデオ悪化イベントの前記始まりの前における最初のＩフレームを検出するために、メモリ格納構成要素内を後ろ向きに検索し、かつ、受信されつつある第２のビットレートのビデオデータビットストリーム内を前向きに検索する手段と；
    前記ビデオ悪化イベントの前記終わりの後の最初のＩフレームを検出するための、前記メモリ格納構成要素、および、前記受信されつつある第２のビットレートのビデオデータビットストリームのうちの１つの中で検索する手段と；
    を更に有する請求項２０記載のシステム。
22. 前記多重通信するステップの処理は、前記第１のビットレートのビデオデータビットストリームで前記損失しまたは障害を受けたフレームのうちの１つに対応する前記第２のビットレートのビデオデータビットストリームのグループオブピクチャを選択的に多重送信する、請求項２１記載のシステム。
23. 前記第２のビットレートのビデオデータビットストリームの前記グループオブピクチャの解像度は、前記第１のビットレートのビデオデータビットストリームの前記グループオブピクチャの解像度に等しいか、または、より低いかのうちのいずれか一つである、請求項２２記載のシステム。
24. データ損失から回復する装置であって：
    マルチキャストグループ内の多重化ビデオデータビットストリームを受信する手段と；
    前記受信されたビデオデータビットストリームを、第１のビットレートのビデオデータビットストリーム、および第２のビットレートのビデオデータビットストリームにデマルチプレクスする手段であって、前記第２のビットレートのビデオデータビットストリームは、前記第１のビットレートのビデオデータビットストリームで損失しまたは障害を受けたフレームのうちの１つに対応するフレームを含んでおり、前記第２のビットレートのビデオデータビットストリームは、前記第１のビットレートのビデオデータビットストリームより低いビットレートを有するところの手段と；
    前記第２のビットレートのビデオデータビットストリームからのフレームを、前記第１のビットレートのビデオデータビットストリームで損失しまたは障害を受けたフレームのうちの１つと置き換えるためにデコードする手段と；
    を有する装置。

Images