(57)【要約】システム及び方法は、現実的なアーキテクチャを提供し、適応的且つ効率的な保護を実行するために必要なプロトコルを指定し、それによって、アプリケーションが異なる保護方策を動的に切り替えることが可能になる。メディアデータストリーム(202、204)から別のストリームとして保護トラック(206、208、210)を備えることにより、保護が独特に実現される。このように、保護データを変更することにより、保護レベル又は方策を変更できるが、保護手順は同じままになる。更に、その方法は、IGMP(Internet  Group  Management  Protocol)の代わりにRTSP(Real-time  Transport  Protocol)を使用し、高速な保護を実現することができ、アプリケーションに高い柔軟性を提供することができる。
2006503516.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを通じて送信装置から受信装置にビットストリームを伝送する方法であって、
チャネル符号化技術を使用して前記ビットストリームから少なくとも１つの保護ビットストリームを作る符号化段階と、
前記保護ビットストリームから少なくとも１つのヒントトラックを生成する生成段階と
を有し、
前記少なくとも１つのヒントトラックは、多対一関係で前記少なくとも１つの保護ビットストリームに関係する方法。
【請求項２】
請求項１に記載の方法であって、
前記少なくとも１つの保護ビットストリームと前記少なくとも１つのヒントトラックとを記憶媒体に格納する格納段階を更に有する方法。
【請求項３】
請求項１に記載の方法であって、
誤り保護についての誤り訂正要求を前記受信装置から受信する段階と、
前記少なくとも１つのヒントトラックの中から関連のヒントトラックに従って、前記少なくとも１つの保護ビットストリームから第１の保護ビットストリームを出力する段階と
を更に有し、
前記第１の保護ビットストリームは、前記符号化段階で作られ、
前記関連のヒントトラックは、前記生成段階で生成される方法。
【請求項４】
請求項３に記載の方法であって、
ネットワーク状態の変化に応じて、誤り保護についての変更した誤り訂正要求を前記受信装置からその後に受信する段階と、
関連のヒントトラックに従って前記符号化段階で作られた前記少なくとも１つの保護ビットストリームの中から少なくとも１つの変更した保護ビットストリームを出力する段階と、
を更に有し、
前記少なくとも１つの変更した保護ビットストリームは、前記符号化段階で作られ、
前記関連のヒントトラックは、前記生成段階で生成される方法。
【請求項５】
請求項１に記載の方法であって、
前記ビットストリームは、ソースの符号化方法に従って出力されたデータストリームである方法。
【請求項６】
請求項１に記載の方法であって、
前記少なくとも１つの保護ビットストリームは、データ保護符号化方法に従って作られたデータストリームである方法。
【請求項７】
請求項１に記載の方法であって、
前記少なくとも１つのヒントトラックは、ヒンティングアルゴリズムに従って生成されたデータストリームである方法。
【請求項８】
請求項７に記載の方法であって、
前記ヒンティングアルゴリズムは、少なくともネットワーク状態とネットワークプロトコルとネットワーク種類とに従って最適化される方法。
【請求項９】
請求項１に記載の方法であって、
前記受信装置は、クライアント装置であり、
前記送信装置は、サーバ装置である方法。
【請求項１０】
誤り保護を実行する命令を有するコンピュータ読取可能媒体であって、
前記命令は、１つ以上のプロセッサにより実行されると、請求項１に記載の方法の段階を実行するように構成されたコンピュータ読取可能媒体。
【請求項１１】
チャネル符号化技術を使用してビットストリームから少なくとも１つの保護ビットストリームを作る手段と、
前記少なくとも１つの保護ビットストリームから少なくとも１つのヒントトラックを生成する手段と
を有する誤り訂正システムであって、
前記少なくとも１つのヒントトラックは、多対一関係で前記少なくとも１つの保護ビットストリームに関係する誤り訂正システム。
【請求項１２】
請求項１１に記載の誤り訂正システムであって、
前記少なくとも１つの保護ビットストリームと前記少なくとも１つのヒントトラックとを記憶媒体に格納する手段を更に有する誤り訂正システム。
【請求項１３】
請求項１２に記載の誤り訂正システムであって、
誤り保護についての誤り訂正要求を受信装置から受信する手段と、
前記少なくとも１つのヒントトラックの中から関連のヒントトラックに従って、前記少なくとも１つの保護ビットストリームから第１の保護ビットストリームを出力する手段と
を更に有し、
前記第１の保護ビットストリームは、前記符号化段階で作られ、
前記関連のヒントトラックは、前記生成段階で生成される誤り訂正システム。
【請求項１４】
請求項１３に記載の誤り訂正システムであって、
ネットワーク状態の変化に応じて、誤り保護についての変更した誤り訂正要求を前記受信装置からその後に受信する手段と、
関連のヒントトラックに従って前記符号化段階で作られた前記少なくとも１つの保護ビットストリームの中から少なくとも１つの変更した保護ビットストリームを出力する手段と、
を更に有し、
前記変更した保護ビットストリームは、前記符号化段階で作られ、
前記関連のヒントトラックは、前記生成段階で生成される誤り訂正システム。
【請求項１５】
請求項１に記載の方法であって、
前記ビットストリームは、ソースの符号化方法に従って出力されたデータストリームである方法。
【請求項１６】
請求項１３に記載の誤り訂正システムであって、
前記少なくとも１つの保護ビットストリームは、データ保護符号化方法に従って作られたデータストリームである誤り訂正システム。
【請求項１７】
請求項１３に記載の誤り訂正システムであって、
前記少なくとも１つのヒントトラックは、ヒンティングアルゴリズムに従って生成されたデータストリームである誤り訂正システム。
【請求項１８】
請求項１３に記載の誤り訂正システムであって、
前記ヒンティングアルゴリズムは、少なくともネットワーク状態とネットワークプロトコルとネットワーク種類とに従って最適化される誤り訂正システム。
【請求項１９】
請求項１３に記載の誤り訂正システムであって、
前記受信装置は、クライアント装置であり、
前記送信装置は、サーバ装置である誤り訂正システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メディアデータ、特にスケーラブル符号化データをストリーミングする分野に関するものである。特に、本発明はそのようなデータの保護に関するものである。
【背景技術】
【０００２】
ISDNネットワーク又はインターネットのような通信ネットワーク内での映像伝送又は映像ストリーミングは、このような通信ネットワークの重要なアプリケーションになってきている。将来的に、前述のISDNネットワーク又はインターネットのような固定通信ネットワークに移動体ユーザを接続するために、GPRS(General  Packet  Radio  Service)やUMTS(Universal  Mobile  Telecommunications  Standard/System)のようなパケット指向の移動体ネットワークが一般的に使用されるようになるであろう。従って、無線ネットワークに高品質の映像ストリーミングの効率的且つインテリジェントなサポートを使用することは重要である。
【０００３】
無線チャネルでの圧縮映像の配信について関心が高まっているため、映像通信における誤り隠蔽の問題はますます重要になってきている。EGPRS(Enhanced  General  Packet  Radio  Service)又はUMTSのように次世代無線標準について複数のパケット指向の伝送モードが提案されている。これらはほとんど同じ原理に基づいている。長いメッセージブロック(一般的にはネットワークの無線部分に入るIPパケット)は、所望の長さのセグメントに分割され、固定サイズのリンクレイヤのパケットに多重化され得る。次に、パケットは無線リンクで順次伝送され、再構築され、次のネットワークエレメントに渡される。しかし、今日の固定又は有線のネットワークのかなり良好なチャネル特性と比較して、一般的に無線リンクはかなりのフェーディングや雑音や干渉条件を受け、検出及びデコードの後に比較的高い残差ビット誤り率(residual  bit  error  rate)を生じる。
【０００４】
有線及び無線ネットワークの双方で映像ストリーミングをサポートするために、２種類の誤り回復方法が一般的に使用されている。すなわち、再送信と、前方誤り訂正(FEC:forward  error  correction)である。FEC符号化は、データ通信において誤り訂正及び検出を実現する周知の技術である。FECは伝送オーバーヘッドを増加させるという欠点を有するため、ペイロードデータの使用可能帯域を減少させる。従って、一般的にそれは映像サービスで賢明に使用されている。その理由は、映像サービスは帯域に非常に要求が厳しいが、ある程度の損失を許容することができるからである。再送信方法は高い帯域稼働率という利点を有するが、長い回復遅延を受ける。その長い回復遅延は、厳しい遅延の制約を有するアプリケーションには許容できないことがある。
【０００５】
以前は、一方の方法又は他方の方法を使用する間に明確な線が存在した。アプリケーション設計は再送信とFECのいずれか一方を選択する。しかし、IPベースのネットワークは異質であり発展途上である。アプリケーションが全く異なるネットワーク環境で動作する可能性があることも考えられ、ネットワーク状態を予測しにくくしている。この状態は、全ての可能性のある動作シナリオについて正確な誤り回復方法を選択することを困難にしている。
【０００６】
誤り回復の理想的な方策は、再送信とFECを組み合わせることであり、それによって、アプリケーションがいずれか一方を動的に選択することが可能になり、更に、認知したネットワーク状態に従ってリアルタイムにそれらを組み合わせることが可能になる。
【０００７】
ハイブリッドARQ(hybrid  ARQ)と適応的FEC(adaptive  FEC)は、再送信とFECの長所を結合した２つの方法である。ハイブリッドARQでは、映像データは、リードソロモン符号化機構のような何らかのFEC符号化機構により予め符号化され、送信者と受信者は、保護を実行するために、特別に設計されたARQのようなプロトコルを使用する。適応的FECでは、FECデータは元のメディアストリームから分離され、適応的保護を実現するために、“join”/“leave”コマンドが使用される。しかし、適応的FECは二様に制限されている。第１に、join/leave動作を信号で通知するために、Internet  Group  Management  Protocol(IGMP)を使用し、それは信号処理に非常に長い待ち時間を導入することがあり、最終的には再送信のように保護の目的を無効にする。第２に、それはFEC符号化アルゴリズムを重視しているが、適応的FECの目的を実行するアーキテクチャやプロトコルを欠いている。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
適応的且つ効率的な保護を実行するために必要なプロトコルを指定し、それによって、アプリケーションが異なる保護方策を動的に切り替えることを可能にする現実的なアーキテクチャを提供することが、当該技術分野における進展になるであろう。
【課題を解決するための手段】
【０００９】
本発明の特定の態様によると、受信装置(クライアント)が保護データを受信し、受信する保護データの種類を決定することを動的に選択することを可能にする方法と装置が提供される。
【００１０】
例えば、本発明の特定の例示的な実装によると、サーバと、そのサーバと通信する対応する受信装置とで使用される方法が提供される。その方法は、フレーム予測符号化技術を使用してビットストリームから符号化下位レイヤを作る第１の符号化段階と、FGS(fine  granular  scalable)符号化技術を使用してビットストリームから符号化上位レイヤを作る第２の符号化段階と、少なくとも１つの保護ビットストリームを生成する第１の生成段階と、第１の下位レイヤのヒンティングビットストリーム(hinting  bit  stream)を生成する第２の生成段階と、第１の上位レイヤのヒンティングビットストリームを生成する第３の生成段階と、第１の保護ヒンティングビットストリームを生成する第４の生成段階とを有する。
【００１１】
その他の態様によると、本発明は、フレーム予測符号化技術を使用してビットストリームから符号化下位レイヤを作る手段と、FGS(fine  granular  scalable)符号化技術を使用してビットストリームから符号化上位レイヤを作る手段と、少なくとも１つの保護ビットストリームを生成する手段と、第１の下位レイヤのヒンティングビットストリーム(hinting  bit  stream)を生成する手段と、第１の上位レイヤのヒンティングビットストリームを生成する手段と、第１の保護ヒンティングビットストリームを生成する手段とを有するシステムである。
【発明の効果】
【００１２】
ここでオンデマンド型保護と呼ばれる提案した誤り保護方法及び装置は、従来技術に対する複数の利点を有する。その利点は以下のことを含む。(1)その方法は、有利には全体的にFGSストリーミングアーキテクチャに適合する。(2)その方法はマルチキャストアプリケーションとユニキャストアプリケーションの双方をサポートする。(3)その方法はMPEG-4ファイルフォーマットを最大限に利用し、それによって汎用MPEG-4サーバがストリーミングアプリケーションに対して適応的誤り保護を実行することが可能になる。(4)保護データは被保護データから分離される。このように、保護データを変更することにより、保護レベル又は方策を変更することができるが、保護手順は同じままになる。(5)その方法により、アプリケーションが再送信のような保護若しくはFECのような保護又はハイブリッドARQを動的に選択することが可能になり、それによって、より良い保護性能を得ることができる。(6)その方法は、Internet  Group  Management  Protocol(IGMP)の代わりにReal-time  Transport  Protocol(RTSP)を使用し、より高速な保護を実現し、アプリケーションに対してより高い柔軟性を提供することができる。
【発明を実施するための最良の形態】
【００１３】
次に図面を参照すると、同様の参照数字は図面を通じて対応する部分を表している。
【００１４】
本発明のより良い理解のため、以下の用語が定義される。
【００１５】
ストリーミングメディア−基本的に、承認ユーザのクライアント装置に重要なコンテンツ(例えば音声及び／又は映像データ)のリアルタイム配信又はほぼリアルタイム配信を行うことを意味する。クライアント装置は、クライアント装置とメディアに適した方法でストリーミングされたメディアを処理する。
【００１６】
RTPプロトコル−多くの環境における標準的なリアルタイムベースのパケット化法として使用され、UDP(User  Datagram  Protocol)/IP(Internet  Protocol)のように、プロトコルスタックにおけるトランスポートレイヤのすぐ上位に存在する。一般的に、RTPはリアルタイムデータ用の伝送プロトコルであり、タイムスタンプと、シーケンス番号と、データ損失検出と、セキュリティと、コンテンツ確認と、リアルタイムデータ配信に関する他のデータを提供する。RTPはユニキャストのコンテンツ又はマルチキャストのコンテンツで使用され得る。
【００１７】
RTSPプロトコル−アプリケーションレベルのプロトコルであり、Real  Time  Session  Protocolを表す。セッション交渉及びコンテンツ記述機構を提供するために構築されてきた。RTSPは、サーバからクライアントにコンテンツをストリーミングする方法について記述する。ストリーミングは、(中間のネットワーク特性に関して)サーバとクライアントとの伝送に従うサイズを有するパケットにコンテンツを分割することを有する。
【００１８】
FEC−前方誤り訂正は、送信装置が受信装置に追加FECデータを提供する機構を備える周知の誤り訂正技術である。その追加FECデータは、その後に受信データにおける誤りを検出して訂正するために受信装置により使用され得る。このように、FECをサポートするために、一般的に送信装置はFECエンコーダを有し、一般的に受信装置はFECデコーダを有する。FECは異なるレベルの符号化を可能にする。異なるレベルの符号化は、所定量のデータに対して生成されるFECデータの量に基づく密度比により表され得る。このように、例えば、あるシステムでデータパケット毎に１つのFECパケットの比率が存在する場合には、FEC符号化レベルは“高い”ことがある。あるシステムでは、４つのデータパケット毎に１つのFECパケットの比率が存在するように、FEC符号化レベルが“低い”ことがある。
【００１９】
以下の説明では限定ではなく説明目的で、本発明の完全な理解を提供するため、特定のアーキテクチャ、インタフェース、技術等のような特定の詳細が示されている。簡潔性と明瞭性のため、不要な詳細で本発明の説明をあいまいにしないように周知の装置や回路や方法の詳細な説明が省略されている。
【００２０】
Real-time  Transport  Protocol(RTP)及びReal  Time  Streaming  Protocol(RTSP)は周知であるため、これらのプロトコルがクライアントへのコンテンツ配信の基礎になっていることをここで仮定している。当業者に広く精通しているため、これらのプロトコルは例示目的のみのためにここで説明されており、ここで依存する信号特性を提供する如何なるプロトコルが使用されてもよいことが当業者にわかる。
【００２１】
一態様において、本発明は、関連するメディアデータストリームに関係なく、少なくとも１つのメディアデータ保護ストリームを提供し、ネットワークでのメディアデータストリームの伝送を促進する少なくとも１つのメディアデータのヒントトラック(hint  track)と、ネットワークを通じた少なくとも１つのメディアデータ保護ストリームの伝送を促進する少なくとも１つの保護データストリームとを更に提供するシステム及び関連の方法に関係する。
【００２２】
関連の態様において、本発明は、アプリケーションが自由にオンデマンドで誤り保護機構を動的に選択することを可能にするシステム及び関連の方法を対象とする。
【００２３】
以下では特にMEG-4  FGSについて記載されているが、有利には、本発明は如何なるスケーラブル符号化機構にも適用可能であることが当業者に明確である。
【００２４】
IPネットワークで誤り保護機構を提供する方法及びシステムの原理と動作は、図面及び添付の説明を参照するとよりよく理解され得る。
【００２５】
以下で説明する図１及び２と、この特許文献で本発明の原理を説明するために使用される多様な実施例は、例示にしか過ぎず、決して本発明の範囲を限定するように解釈されるべきではない。本発明の原理は如何なる適切に構成された映像エンコーダ及びデコーダにも実装され得ることが、当業者にわかるであろう。
【００２６】
本発明は、図１に示すようなネットワークで使用される適応的且つ効率的な誤り保護機構を提供する機能を備え、それによって、以下に説明するようにアプリケーションが異なる誤り保護方策を切り替えることが可能になる新規なアーキテクチャと特有のプロトコルを提供する。
【００２７】
図１は、本発明を組み込んだシステム100の一実施例の概略表示を示している。図示のように、クライアント130とサーバ118はネットワーク120で通信している。例示的なシステム100は、適切なシステムの一例にしか過ぎず、ここで説明する改善した方法及び装置の使用又は機能の範囲に関して限定を示唆するためのものではない。
【００２８】
説明目的で、音声又は映像信号がデジタルデータストリーム(メディアストリーム)に変換され、ソースノード110からサーバ118を介して宛先ノード(すなわちクライアント)130にネットワークで送信されることを、以下の説明で仮定する。一例として、デジタルデータストリーム又はペイロードがフレーム又はペイロードパケットのシーケンスに分割されることを、その説明で更に仮定する。本発明の実施例によると、映像エンコーダ(ソースノード)110は、映像フレームソース112と、下位レイヤエンコーダ114a及び上位レイヤエンコーダ114bを有する映像エンコーダと、エンコーダバッファ116とを有する。映像フレームソース112は、テレビアンテナ及び受信ユニット、ビデオカセットプレイヤ、ビデオカメラ、“生の”映像クリップを格納可能なディスク記憶装置等を含み、非圧縮映像フレームのシーケンスを生成可能な如何なる装置でもよい。映像フレームソース112から生じた非圧縮映像フレームは、所定の画像レート(又は“ストリーミングレート”)で映像エンコーダ114に入り、MPEG-4エンコーダのような何らかの既知の圧縮アルゴリズム又は装置に従って圧縮される。次に、データネットワーク120を通じてサーバ118を介した伝送に備えてバッファするために、映像エンコーダ114は圧縮映像フレームをエンコーダバッファ116に伝送する。映像エンコーダは、汎用目的サーバ118の外部で実行してもよく、汎用目的サーバ118の内部で実行してもよいことに留意すべきである。
【００２９】
データネットワーク120は、如何なる適切なネットワークでもよく、インターネットのような公衆データネットワークと、企業所有のローカルエリアネットワーク(LAN)、メトロポリタンエリアネットワーク(MAN)又は広域ネットワーク(WAN)のようなプライベートデータネットワークの双方の部分を有してもよい。
【００３０】
アプリケーションに応じて、ストリーミングメディアを受信する宛先ノード(クライアント)130は、コンピュータ、ハンドヘルド用エンターテイメント装置、セットトップボックス、テレビ、特定用途向け集積回路(ASIC)等を含み、多数の異なる方法で具体化されてもよい。宛先ノード(クライアント)130は、デコーダバッファ132と、映像デコーダ134と、映像ディスプレイ136とを有する。
【００３１】
図２は、A1-A5として示す段階1-5を有する本発明の保護機構を実装したアーキテクチャ及び関連のプロトコルを一例として示している。
【００３２】
段階1：
図２の段階1にFGS符号化した.mp4ファイルが示されている。.mp4ファイルは、FGS技術を使用して映像エンコーダ112(図１参照)等で符号化されてもよく、映像データの一部は、最初に下位レイヤ(BL)202を作るために使用される。次に、動き補償の残差画像(residual  image)を使用して上位レイヤ(EL)204が生成される。fine  granular  coding(FGS)技術を使用して、動き補償の残差画像は映像データと下位レイヤ(BL)202から生成される。当該技術分野において周知のように、FGS符号化は映像スケーラビリティのうちの１つの種類を表す。この種類のスケーラビリティで符号化された画像は進行的にデコードされ得る。すなわち、画像を符号化するために必要なデータの全てを受信する必要なく、デコーダはデコードして画像を表示し始めることができる。データを受信する毎に、完全な情報を受信してデコードして表示するまで、デコードされた画像の品質が進行的に向上する。
【００３３】
FGS下位レイヤ202と上位レイヤ204を生成することに加えて、本発明の原理によると、複数の保護データストリームが生成され、それぞれが必要に応じてクライアントによりそれぞれ動的に選択可能である。それぞれ.mp4ファイルに関連した別個の独立した保護データストリームが図示されている。例えば、FEC誤り保護の原理に従って、第１の保護トラック(protection  track)(EP1)206が作られてもよい。例えば、再送信誤り保護の原理に従って、第２の保護トラック(EP2)208が作られてもよい。例えば、FEC誤り保護と再送信誤り保護の機能を組み込んだハイブリッド機構に従って、第３の保護トラック(EP3)210が作られてもよい。３つの保護機構のそれぞれは、必要に応じてクライアントにより動的に選択可能である。
【００３４】
段階2：
マルチトラックヒンティング(multi-track  hinting)の原理は、2003年3月4日に出願され、“System  and  Method  for  transmitting  scalable  coded  video  over  an  IP  network”という題の同時係属の米国特許出願第60/451,916号に教示されており、その全てが参照として取り込まれる。そこで教示されているマルチトラックヒンティングの原理によると、現在のMPEG-4メディアファイルフォーマット標準と下位互換性のあるマルチトラックヒンティングと呼ばれる前処理方法により、変化するチャネル特性と複雑性の制約とユーザの嗜好に従って階層化映像を効率的にストリーミングするために、汎用MPEG-4ストリーミングサーバを使用することが可能になる。すなわち、主要な変更を行わずに、サーバは複数のチャネル(すなわちRTP接続)を自動的に使用することが可能であり、それにより、伝送されるスケーラブルレイヤの数を調整することにより、ネットワーク状態(例えば利用可能帯域)に適応する柔軟性をストリーミングシステムに提供することが可能になる。利用可能ネットワーク帯域が減少すると、映像ストリームのより小さい部分が減少した帯域に応じるようにスケーラブル伝送されるため、より少ないヒントトラックがサーバにより必要とされる。
【００３５】
図２に示すように、ヒント器モジュール(hinter  module)214は、ヒントトラック(すなわち、ヒント1)216aを生成し、例えばデータネットワーク120のようなデータネットワークを通じたFGS符号化下位レイヤ202の伝送を促進する。更に、ヒント器モジュール214は、それぞれ上位レイヤ(EL)204に関連する複数のヒントトラック(すなわち、ヒントトラック2-5)216b-eを生成する。
【００３６】
本発明の１つの特徴は、保護トラックのそれぞれ(すなわち、EP1、EP2、EP3)が、有利にマルチトラックヒンティング方法の原理を利用し、それによって主なネットワーク状態に従って誤り保護を提供してもよいことにある。すなわち、前述の同時係属出願60/451,916に記載されているように、.mp4の元のデータファイルについて実行されるものとほとんど同じように複数のRTP接続を介して保護トラックをストリーミングするために、複数のヒントトラックが使用されてもよい。ネットワークを通じて保護トラックをストリーミングする際の柔軟性は一例として図２に示されており、保護トラックのそれぞれ(例えばEP1-3)に関連する複数のヒントトラックが図示されている。具体的には、第１の保護トラックEP1  206について、ヒント器(hinter)214は216fと216gとして示すヒントトラック6と7を生成する。第２の保護トラックEP2  208について、ヒント器214は、それぞれ216hと216iと216jとして示すヒントトラック8と9と10を生成する。保護トラックEP3  210に関して、ヒント器214は単一のヒントトラック11、216kを生成する。
【００３７】
この文脈において、前記の同時係属出願60/451,916の教示は忠実であり続けるが、それに加えて、ヒントトラックは保護トラックを伝送し、ネットワークを通じて伝送されるデータストリームを保護するために利用される。具体的には、保護データストリームは、測定したネットワーク状態に従ってネットワークを通じてスケーラブル伝送されてもよい。しかし、映像データストリームでは当てはまるが、この文脈で注目するネットワーク状態は帯域ではなく、測定したパケット損失率である。パケット損失率が増加していると判断されると、更なる誤り保護の必要性が存在する。従って、測定したパケット損失率の増加を補うため、保護データストリームの伝送を促進するために最初に使用されている数より大きい更なるヒントトラックが利用される。
【００３８】
特定の例として、例示的な保護トラックEP2  208を参照すると、その保護トラックEP2  208は３つのヒントトラック8-10、216h-jに関連し、その３つのヒントトラック8-10はEP2  208と同時に生成されている。最初に測定したパケット損失率が、所定のパケット損失閾値を満たすために必要な保護データストリームEP2  208のスケーラブル部分を促進するために、３つのヒントトラックのサブセットのみ(例えばヒントトラック8  216h)が最初に必要とされる程度であることを仮定する。次に、ある時点でパケット損失率が増加することを仮定する。低下したネットワーク状態(すなわち、パケット損失率の増加)を補うため、保護データストリームEP2  208に関連する１つ以上の更なるヒントトラックを利用する必要がある可能性がある。例えば、ある時点で３つの全てのヒントトラック8-10  216h-jを利用し、それによって保護データストリームEP2  208の最高のスケーラブル部分を提供することが必要な可能性がある。
【００３９】
前述の説明は、本発明の１つの特徴を示すために提供されている。すなわち、親の映像ストリームはネットワーク帯域の測定した変化に従ってスケーラブルに変更されるが、保護データストリームはパケット損失率の測定した変化に従ってスケーラブルに変更されるという違いがあるが、親の映像データストリームと同じように、新規な保護データストリームがネットワークを通じてスケーラブル伝送されてもよい。前者の場合は、帯域が減少すると、少ないヒントトラックが必要になる。同様に後者の場合は、パケット損失率が減少すると、少ないヒントトラックが必要になる。
【００４０】
段階3：
本発明の原理によると、如何なる時点においてもクライアント130は保護チャネルを受信することを動的に承認又は解除してもよい。従って、クライアント130は、その受信品質を監視し、必要と考える時に積極的に保護チャネルを起動する必要がある。本発明の方法による誤り保護を起動するために、まずクライアントはサーバで利用可能な誤り保護の種類を認識しなければならない。したがって、サーバから利用可能な誤り保護の種類の可用性及び説明をクライアントに通知する機構が必要である。この機構は、クライアントとサーバとの間で最初にセッション記述プロトコル(SDP:Session  Description  Protocol)を実行することにより実行されることが好ましい。
【００４１】
一般的に、SDPは、セッション通知とセッション呼出と他の種類のマルチメディアセッションの起動の目的で、マルチメディアセッションを記述する目的のプロトコルである。それはIETFで維持管理されており、SDPに関する更なる情報は、一般的にインターネットのwww.ietf.org、具体的にはwww.ietf.org/rfc/rfc2327.txtにある。本発明はSDPの機能を拡張し、サーバから利用可能な誤り保護の可用性及び特徴に関する追加情報をクライアントに伝えるプロトコルを包含する。
【００４２】
動作中に、映像データファイル(例えば.mp4ファイル)の申込み要求を行う前に、クライアントとサーバとの間でSDPプロトコルが実行される。SDPプロトコルセッションは、セッションについての多様な情報をクライアントに利用可能にする。最も重要なことは、誤り保護に関してどのような選択肢が利用可能であるかを、クライアントが認識する。すなわち、利用可能な誤り保護の種類、トラック番号等である。クライアントはこの情報を格納し、映像ソースファイルの伝送中のある時点で誤り保護が正当であることをクライアントが決定すると、その情報が後に使用されてもよい。
【００４３】
誤り保護が正当であるという決定をクライアントが行った場合、クライアントは、まずRTSPプロトコルを使用してサーバに申し込み要求を行うことにより、誤り保護を要求する。前述のように、RTSPプロトコルはアプリケーションレベルのプロトコルであり、セッション交渉とコンテンツ記述機構を提供する。すなわち、RTSPプロトコルは、サーバからクライアントにコンテンツをストリーミングする方法について記述する。その要求は、伝送制御プロトコル(TCP)のような一般的なIPベースのパケット交換技術を使用して、IPネットワーク120を通じて伝送される。当該技術分野において周知のように、TCPプロトコルは、コンピュータ又はネットワークのオペレーティングシステムやアーキテクチャの違いに無関係のネットワークプロトコルシステムである。クライアントとサーバとの間に予め存在する通信チャネルがないことを仮定すると、サーバはクライアントの申し込み要求を受信する。例示的なクライアントの申し込み要求は以下の形式を有してもよい。
クライアント→サーバ
1.  SET_PARAMETER  rtsp://130.140.67.83/sample.mp4  RTSP/1.0
2.  CSeq:32
3.  Session:3453643
4.  Content-length:35
5.  Content-type:text/bool/integer
6.  Track11:1  //第11トラックを1(アクティブ)に設定する
7.  Range:34521-34570  //50パケットが必要になる(開始シーケンス#−終了シーケンス#)
前記の申し込み要求の特に注目する点は、6行目と7行目である。具体的には、クライアントは、パケット識別子34521-34570で示すパケットの範囲について保護トラック11をアクティブにする申し込み要求を行っている。すなわち、指定のパケットの特定の範囲が誤りであり又はドロップしたことをクライアントが決定し、保護チャネル11を介してそれらを取り出そうとしている。保護チャネル11は、FEC誤り保護、再送信誤り保護又はハイブリッド機構を含む、サーバにより提供されている如何なる数の誤り保護機構と同義でもよい。
【００４４】
図２を参照し続けると、保護チャネル11は、例えば保護トラックEP1、EP2又はEP3と同義でもよい。
【００４５】
クライアントベースの申し込み要求に応じて、サーバは以下の形式を有し得る肯定応答でクライアントに応答してもよい。
サーバ→クライアント
1.  RTSP/1.0  200OK
2.  CSeq:32
3.  Date:28  Jan  2002  15:33:10  GMT
前述の申し込み要求の６行目で強調したように、本発明の１つの特徴は、サーバから利用可能な複数の誤り保護の選択肢の中から１つの保護機構をクライアントが動的に選択することを可能にする際に備えられている柔軟性である。この柔軟性は、単一の変更できない誤り保護の方法(例えば再送信とFEC保護のうちいずれか一方)のみを選択するようにクライアントを制約する従来技術の手法と対照を成す。有利には、対応するデータストリームと異なる別の明確なデータストリームとして保護チャネルを維持することにより、必要に応じて複数の誤り保護の選択肢がクライアントで利用可能になる。更に、被保護データから保護データを分離することによって保護データを変更することにより、保護レベル又は方策を変更できるが、保護手順は同じままになる。
【００４６】
次に、サーバで利用可能になっている保護機構の中から保護機構をクライアントが選択する方法について以下に詳細に説明する。
【００４７】
一実施例によると、保護機構は、範囲パラメータ(前記の７行目、すなわち、Range:34521-34570を参照)を介してクライアントにより選択されてもよい。すなわち、範囲内の終了シーケンス番号(例えば34570)が要求の一部として無限大であるように指定される場合には常に、例えばクライアントがFEC形式の誤り保護モードを要求していることを、サーバが仮定してもよい。代替として、終了シーケンス番号が開始シーケンス番号+1と同じである場合には常に、クライアントが再送信形式の保護モードを要求していることを仮定してもよい。前記の例で示すように、その２つの選択肢のいずれもが選択されない場合(すなわち、終了シーケンス番号＞1+開始シーケンス番号、且つ無限大と等しくない場合)、クライアントがハイブリッド伝送モード(例えば、FECと再送信の組み合わせ)を要求していることを仮定する。
【００４８】
ここで明示的に記載しないが、保護機構を選択する他のモードも本発明の検討範囲内である。
【００４９】
図２を参照し続けると、クライアントの申し込み要求に応じて肯定要求を送信することに続いて、サーバは適切なヒントトラックをロードし、ヒントトラック毎にRTP接続を作る。図示の例では、RTP接続218aがヒントトラック1、216aについて生成されており、RTP218b-eがそれぞれヒントトラック216b-eについて生成されている。説明目的で、保護トラックEP1がクライアント130により選択されたことを仮定すると、ヒントトラック6と7、それぞれ216fと216gがロードされ、RTP接続218fと218gが生成される。保護データの伝送を促進するために、更なる専用のRTP接続(例えば218fと218g)が生成されることもわかる。
【００５０】
段階4：
段階4において、クライアント130は、段階3で説明したものに対して対応するRTP接続を生成し、映像データ及び対応する保護トラックデータの伝送を促進する。
【００５１】
段階5：
段階5において、伝送されたFGS符号化映像データストリーム(すなわち、BL202及びEL204)がデコードされて表示される。
【００５２】
本発明の特定の実施例の前記の説明は、例示及び説明の目的で提示されている。それらは完全であることを目的としているのではなく、また、開示された正確な形式に本発明を限定することを目的としているものではない。前述の教示を鑑みて明らかに多数の変更及び変形が可能である。本発明の原理とその実際の用途を最もよく説明するため、それによって、当業者が本発明及び検討される特定の使用に適した多様な変更を備えた実施例を利用することができるように、実施例が選択されて説明されている。本発明の範囲は、特許請求の範囲及びその均等物により定められることを意図している。
【図面の簡単な説明】
【００５３】
【図１】本発明が実現され得るストリーミングメディアのエンド・ツー・エンドの伝送を実行する例示的なネットワークである。
【図２】一例としての本発明の保護機構を実装するアーキテクチャと関連のプロトコルである。
【図１】
2006503516.tif 000003
【図２】
2006503516.tif 000004
【国際調査報告】
2006503516.tif 000005
2006503516.tif 000006
2006503516.tif 000007