JP2014520422A - 受信ビットレートの動的適応方法および関連する受信機 - Google Patents

Abstract

ネットワーク上を複数の部分で送信されるオーディオビジュアル・プログラムを受信する方法であって、この方法は、サーバとレシーバとの間でリアルタイム送信プロトコルとリアルタイム制御プロトコルとを使用し、オーディオビジュアル・プログラムは、種々の解像度で符号化されたプログラムに対応し、かつ、レシーバの要求に従って種々のビットレートでその送信を可能にする複数のバージョンで、サーバ上で入手可能である。この方法は、ネットワークの状態に従って送信ビットレートを調節するために、レシーバによるネットワークの帯域幅の定期的な測定を含む。

Description

本発明は、オーディオビジュアル・プログラム受信機の分野に関し、更に詳しくは、ストリーミングでの送信のためにリアルタイム送信プロトコルとこのリアルタイム送信プロトコルに関連付けられたリアルタイム・サーバ制御プロトコルとを用いる、プログラムの送信期間中にネットワークで利用可能な帯域幅に従う、プログラムの動的適応に関する。

表示用にプログラムをダウンロードするには、リカバリの前に、そのオーディオビジュアル・プログラムを受信機に完全に転送する必要がある。これに付随する種々の制約、例えば、ダウンロードの終了を待つ必要がある、又は、プログラム全体に対する十分な記憶スペースを確保する必要があるといった制約を回避するために、ストリーミング（視聴中のプログラムの連続的な送信）の使用が広く行われている。

既知のストリーミング・プロトコルには、サーバ制御プロトコル（ＲＦＣ２３２６）とＭＰＥＧ ＴＳ／ＵＤＰ（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ／Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）とに関連するＲＴＰ（ＲＦＣ３５５０、及び、送信データのフォーマットにしたがって対応付けられたＲＦＣ）が含まれており、ダウンロードには、一般的に、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルが使用される。

最新の通信ネットワークでは、ストリーミングでのオーディオビジュアル・プログラムの送信を可能にする帯域幅容量が提供されている。この送信は、例えばインターネットのようなネットワークを介して、サーバとクライアントとの間で行われ得る。ストリーミングとは、送信されるオーディオビジュアル・プログラムが、送信とリカバリとの全体を通して、ネットワークで連続的に送信される複数の時間的部分（順次描画される複数の連続した部分）に分解される送信方法である。送信とリカバリとは同時に行われるが、受信機でのバッファ・メモリを使用するため僅かな時間差が生じる。

標準規格の３ＧＰＰ（３ＧＰＰ、ＴＳＧＳ−ＳＡ、トランスペアレント・エンドトゥエンド・パケット交換ストリーミング・サービス（ＰＳＳ）、３ＧＰＰファイル・フォーマット（３ＧＰ）、ＴＳ２６.２４４、Ｖ６.３.０、２００５−０３）は、種々のビットレートに対応している同一プログラムの幾つかのバージョンを含む、データ及び記憶の組織化用のフォーマットを定義している。このフォーマットは、プログラム・サーバ上の制御ロジックに関連付けられており、ネットワーク使用に関する帯域幅における諸条件、特に変動に対する適応を可能にする。しかしながら、サーバ上で実施されるこの制御ロジックは、３ＧＰＰ規格では規定されていない。

３ＧＰＰフォーマットにおいて、データは、固定ビットレートについて、送信リンク上のビットレート制約条件に適合するように符号化され、そのデータが画像である場合、その符号化は、より広い、又は、より狭い帯域幅でのリンク上における画像送信を可能にするように、画像の解像度を適応化することにある。しかしながら、３ＧＰＰには、帯域幅における変動にデータの受信を適応させるために送信画像の解像度の調整を可能にする切替手段が規定されていない。この問題を解決するいくつかの方法が知られており、それらの方法は、ＲＴＣＰ（Ｒｅａｌ−Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）プロトコルに定義されたＲＲｓ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔｓ）のような、クライアントからサーバに送信されるデータに依存し、しかも、送信を別のビットレートで行うべきか否かを明確にするために、サーバによる処理及び解釈についての複数のステップを必要とする。

ＨＴＴＰストリーミング技術が、近年、ｉＰｈｏｎｅについてアップルにより、及び、Ｓｍｏｏｔｈｓｔｒｅａｍｉｎｇについてマイクロソフトにより、世間一般の注目を浴びるようになった。ＨＴＴＰストリーミング技術は、機能がＲＴＰプロトコル及びＲＴＳＰプロトコルに依拠するＩＰＴＶ受信機においてのみ使用される。

現在ＩＰＴＶで使用される送信方法では、特定のサーバを使用することなく、ネットワークで利用可能な帯域幅に従ってビットレートの動的適応を可能にすることはできない。また、サーバに対するアクセス状態が悪化すると、受信機においてサービスが中断するリスクが生じる。

例えば、リアルタイム転送プロトコルＲＴＰは、オーディオビジュアル・プログラムを符号化する、データのカプセル化とリアルタイム送信とに使用されるプロトコルである。データについて使用される符号化は、一般的に、ＭＰＥＧ−ＴＳタイプ、又は、それと同等のフォーマットのものである。

ＲＴＳＰは、リモート・メディア・サーバの制御を可能にする通信プロトコルの一例である。このようなプロトコルによって、例えば「ＰＬＡＹ（再生）」及び「ＰＡＵＳＥ（一時停止）」のようなビデオ・プレーヤに特有の機能が提供され、オーディオビジュアル・プログラムの一部分を、そのプログラムにおける当該プログラム部分の時間的位置（例えば、ファイルにおけるタイム・インデックス、又は、それに対応する位置）から、再生することが可能になる。

例えば、ＲＴＰ及びＲＴＳＰのようなプロトコルを用いて、オーディオビジュアル・プログラムをストリーミングで送信する際、ネットワークの利用可能性の大幅な変更は、プログラムのリカバリについて非常に重大な出来事である。ビットレートが、送信の始めと終わりとの間で動的に調節されない場合、中断が生じ、これは、ユーザにとって著しく不都合である。

ＲＴＰ送信プロトコルはＵＤＰプロトコルに依拠し、ＨＴＴＰプロトコルはコネクトされたＴＣＰプロトコルに依拠する。

ＴＣＰは、信頼性の制約条件に対処する「コネクトされた」プロトコルとして知られており、データをサーバから受信機にパケット・エラーなしで伝送することを可能にする。このためには、受信機が、サーバと通信を行い、サーバに対してデータが受信されたことを通知する。平均ビットレートは、脱落データ及び再送信データに依存することに加えて、受信通知のルーティングにも関連している。ルーティング時間が速ければ速いほど、それだけ最大ビットレートはますます減少する。

ＵＤＰは、同様の信頼性制約条件に対処しないプロトコルである。ＵＤＰは、いうなれば、「信頼性なし」かつ「接続なし」である。ＵＤＰは、受信通知システムを備えておらず、その平均ビットレートはサーバと受信機との間の距離に関連していない。これが理由で、ＩＰＴＶの用途ではＵＤＰプロトコルはＲＴＰと共に使用される。

本発明の目的の１つは、ビットレートをネットワーク状態に動的に適応させることを可能にしつつ、ＵＤＰの複数の利点を組み合わせることである。

本発明の目的は、従来技術の欠点の少なくとも１つを解消することであり、更に具体的には、オーディオビジュアル・プログラムの送信期間中に、いくつかのリアルタイム転送／制御プロトコル、例えば、ＲＴＰプロトコル及びＲＴＳＰプロトコルを使用する標準規格のＩＰＴＶのインフラストラクチャに使用される帯域幅の動的制御を可能にすることである。

本発明に従って適応されるリアルタイム・サーバ制御プロトコルの使用によって、受信機が、サーバに対して、オーディオビジュアル・プログラムを連続する複数の部分の状態で送信するように要求することが可能になる。受信機は、送信された複数の部分の各々について、ネットワークの送信状態を測定し、その結果として送信ビットレートを調節する。この送信ビットレートの調節は、受信機が、サーバに対して連続的に要求されたプログラムの各々の部分について、種々のビットレートに符号化され、かつ、サーバ上で入手可能ないくつかのプログラム・バージョンの中から１つのバージョンを選択することによって行われる。受信機によるバージョンの選択は、先行する部分の送信期間中に測定された送信ビットレートに従って行われる。このように、ビットレートの調節は、プログラム・サーバの変更を必要としない。

本発明は、サーバ上に記憶されたオーディオビジュアル・プログラムをレシーバに接続された表示装置上に再生するために受信する方法に関し、オーディオビジュアル・プログラムはサーバ上で少なくとも２つのバージョンで入手可能であり、バージョンの各々が、プログラムの部分を符号化した時間的に連続したデータ・ブロック（従って、連続的に描画されるべき連続したデータ・ブロック）を有しており、バージョンは、各々、同数のブロックを有しており、ブロックは、各々、前の画像を参照することなく符号化された画像から始まっている。本発明によれば、この方法は、レシーバ・レベルにおいて、サーバによって第１のビットレートで送信されたバージョンのうちの第１のバージョンから得られる少なくとも１つのブロックを有するオーディオビジュアル・プログラムの第１の部分を、リアルタイム送信プロトコルに従って受信するステップと、サーバによって第１のビットレートで送信されたオーディオビジュアル・プログラムの第１の部分の受信後に帯域幅を特定するステップと、リアルタイム・サーバ制御プロトコルに従って、サーバに要求を送信するステップとを含み、この要求は、サーバとレシーバとの間の帯域幅の特定された値に従う、オーディオビジュアル・プログラムのバージョンのうちの１つでのオーディオビジュアル・プログラムの第２の部分の識別情報と送信速度パラメータとを含み、識別情報は第２の部分の開始及び終了の時間マーカを含んでいる。

本発明の一態様によれば、前記レシーバによる、受信するステップ、帯域幅を特定するステップ、及び、要求を送信する送信ステップは、オーディオビジュアル・プログラムの受信期間中に繰り返して実行される。

本発明の一態様によれば、オーディオビジュアル・プログラムのバージョンがサーバ上に記憶された単一のファイル内に含まれている。

本発明の一態様によれば、オーディオビジュアル・プログラムが、サーバ上で、同一ファイル内におけるオーディオビジュアル・プログラムのバージョンの位置特定に関する情報を含む記述ファイルに対応付けられている。

本発明の一態様によれば、サーバとレシーバとの間の利用可能な帯域幅の特定には、第１のビットレートで受信されたオーディオビジュアル・プログラムの部分の少なくとも１つの特徴の分析が含まれている。

本発明の一態様によれば、上記部分の少なくとも１つの特徴は送信されたビットの数である。

本発明の一態様によれば、要求を送信するステップはＲＳＴＰプロトコルのコマンドＰＬＡＹを使用する。

本発明は、また、サーバによって拡散されたオーディオビジュアル・プログラムを受信する装置に関し、オーディオビジュアル・プログラムはサーバ上で少なくとも２つのバージョンで入手可能であり、これらのバージョンの各々が、オーディオビジュアル・プログラムの画像解像度に対応しており、かつ、連続する複数の部分を有しており、バージョンは、各々、同数の部分を有しており、これらの部分は、各々、イントラ画像から始まっている。本発明によれば、この装置は、サーバによって第１のビットレートで送信されたバージョンのうちの第１のバージョンのオーディオビジュアル・プログラムの第１の部分を、リアルタイム送信プロトコルに従って受信する手段と、サーバによって第１のビットレートで送信されたオーディオビジュアル・プログラムの第１の部分の受信後に帯域幅を特定する手段と、リアル制御プロトコルに従って、サーバに要求を送信する手段とを有し、この要求は、サーバとレシーバとの間の帯域幅の特定された値に従う、オーディオビジュアル・プログラムのバージョンのうちの１つでのオーディオビジュアル・プログラムの第２の部分の識別情報と送信速度パラメータとを含んでおり、識別情報は第２の部分の開始及び終了の時間マーカを含んでいる。

このようにして、送信ビットレートをネットワーク上で利用可能な帯域幅に適応するように調節して、オーディオビジュアル・プログラムのリカバリ期間中の中断を回避する（たとえ、これがそのプログラムをより低いレベルの品質でリカバリすることを意味していても）。

明らかに、本発明は、ＲＴＰプロトコル及びＲＴＳＰプロトコルの使用には限定されず、ＲＴＰ及びＲＴＳＰにそれぞれ類似した特徴を有する任意のリアルタイム転送プロトコル及びそれに対応するサーバ制御プロトコルに関し、特に、再生（描画）されるオーディオビジュアル・プログラムの部分について、バージョン、開始時間、及び、長さ（あるいは停止時間）を選択することを可能にするパラメータを有する例えばＰＬＡＹコマンドのような制御コマンドを提供する任意のリアルタイム転送プロトコル及びそれに対応するサーバ制御プロトコルに関する。

次に述べる添付図面を参照する以下の説明によって、本発明がより良く理解でき、その他の固有の特徴と利点が明らかになるであろう。

本発明の一実施形態による、レシーバ／デコーダを用いたオーディオビジュアル・プログラムの受信用のシステムを示す図である。 同一プログラムのいくつかのバージョンを含むファイルの作成を可能にする符号化の方法を示す図である。 本発明の一実施形態による、種々のビットレートで符号化されて拡散される同一のオーディオビジュアル・プログラムのいくつかのバージョンを含むサーバのファイルを示す図である。 ＲＴＰ送信プロトコルに従う、ストリームの送信に関するレシーバとサーバとの間の初期化メッセージのシーケンスを概略的に示す図である。 本発明の一実施形態による、ストリームの送信に関するレシーバとサーバとの間の初期化メッセージのシーケンスを示す図である。 ネットワークの帯域幅の定期的な評価と、ネットワークの状態に適応したビットレート・パラメータ及び送信速度パラメータを含む要求の送信と含む、レシーバにおいて実施される方法を示す図である。 本発明の一実施形態によるレシーバの機能図である。 図７に示されたレシーバの制御ユニットを示す機能図である。

本発明は、概ね、しかし限定的ではなく、オーディオビジュアル・プログラムをストリーミングで受信する方法に関し、帯域幅の定期的な測定によって特定されたネットワークの輻輳状態に従って、プログラムの送信に使用されるビットレートの動的適応を可能にする。

図１には、レシーバ２がネットワーク３を介してオーディオビジュアル・プログラムを受信するシステムが示されている。受信期間中、レシーバは、オーディオビジュアル・プログラムを処理して、その表示のために信号を表示装置４に送信する。プログラムは、符号化されており、プログラム・サーバ１上で入手可能である。プログラムは、デジタル・ファイルの形態で記憶されている。リカバリ期間中に可変ビットレートでプログラムを送信することを可能にする送信技術では、オーディオビジュアル・プログラムを符号化するデータの送信期間中に、種々のビットレートに対応している種々のバージョンのプログラムをサーバ上で入手可能にするために、特殊な符号化処理が必要である。同一のオーディオビジュアル・プログラムの種々のバージョンは、プログラム・サーバ１上に記憶される。種々のバージョンは、個別のファイル内に記憶でき、又は、単一ファイル上にまとめることができ、ファイル内の各々の位置によって識別できる。各々のプログラムに関連付けられた記述ファイルには、上記の種々のバージョンと、それらの各々のビットレートと、それらの記憶位置とに関する情報が含まれている。この情報は、サーバからレシーバへのプログラム送信の初期化段階の期間中にレシーバに送信される。

図２には、ビットレートをネットワーク上の送信条件に従って調節して、オーディオビジュアル・プログラムを送信するための、オーディオビジュアル・プログラムの符号化処理が示されている。オーディオビジュアル・プログラムは、いくつかのバージョンに符号化される。これらのバージョンの各々は、画像解像度に対応し、したがって送信ビットレートに対応する。これらのバージョンの各々において、プログラムは、連続した複数のブロック、又は、連続した複数の画像グループによって構成されている。これらのブロックの全ては、プログラムの基本リカバリ（又は再生）期間に対応しており、例えば２秒である。これらの基本ブロックは、例えばＨＴＴＰ適応ストリーミング技術の場合において、一般的にチャンク（ｃｈｕｎｋ）と呼ばれている。各々のブロックの最初の画像は、イントラ画像である。イントラ画像は、先行する画像を参照せずに符号化されるものと定義されている。ブロックの始まりにおけるイントラ画像の位置は、各々のバージョンにおいて同じである。したがって、レシーバが、サーバに対して、視聴コンテンツに関して、プログラムの連続性における次のブロックを、別のバージョンで、よって、別の送信ビットレートで配信することを要求する場合、レシーバに内蔵されたデコーダが、先行する画像を参照するという課題もなく、そのブロックの復号処理を実行できる。図２には、５００キロビット／秒、１メガビット／秒、１．５メガビット／秒、及び、２メガビット／秒の受信における（従って送信における）ビットレートにそれぞれ対応するバージョンでプログラムを符号化することが示されている。

図３には、例えば、図２に示された符号化方法から得られる同一のオーディオビジュアル・プログラムのいくつかのバージョン３１，３２，３３，３４を含むファイル３０が示されている。これらの種々のバージョンは、同一のファイル内において、相異なるインデックスで配置されている。従って、プログラムの送信期間中における１つのバージョンから他のバージョンへの移行は、再生ポインタへのインデックスの付加に対応する。オーディオビジュアル・プログラムのバージョンは、ポインタに付加される得る各々のインデックス値に対応する。ポインタは、リカバリ処理されるプログラムの部分の時間的位置を特定する。

図４には、ＲＴＰ送信規格を使用する本発明の一実施形態による、レシーバと拡散サーバとの間の通信の確立が示されている。ＲＴＰプロトコルを使用する拡散の初期化の期間中に、レシーバは、このレシーバに接続された表示装置上で視聴されるプログラムに関する情報をサーバから得るために、ＵＲＬを含むＲＴＳＰ ＤＥＳＣＲＩＢＥという表題の第１のメッセージをサーバ宛てに送信する。ここで、ＵＲＬ（ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ）という用語は、視聴されるプログラムを指し示すネットワーク・アドレスを表している。このアドレスは、例えば、「ｍｕｌｔｉｍｅｄｉａ.ｅｘｅｍｐｌｅ.ｃｏｍ」というシンタクスを有している。サーバは、レシーバ宛にＲＴＳＰ ＤＥＳＣＲＩＢＥ ＲＥＳＰＯＮＳＥという表題の応答メッセージで情報を送信する。このメッセージＲＴＳＰ ＤＥＳＣＲＩＢＥ ＲＥＳＰＯＮＳＥは、複数のプログラム・バージョンが、サーバ上で、個別のファイルに記憶されているか、又は、単一のファイル内に連結されているかをレシーバに示す。次に、プログラムのストリーミング・セッションの準備のために、ＲＴＳＰ ＳＥＴＵＰという表題の第２の要求が、レシーバを介してサーバ宛てに送信される。プログラムの種々のバージョンがサーバ上で個別のファイル内に記憶されている場合、レシーバは、サーバと共に、使用可能なバージョンと同数の送信セッションを初期化する。種々のバージョンがサーバ上の同一ファイル内で連結されている場合、レシーバは、単一の送信セッションを開始する。プログラムの種々のバージョンが同一ファイル内で連結されている場合、レシーバは、再生ポインタにインデックスを付加して、プログラムのある１つのバージョンから別のバージョンに移行させ、これにより、再生されるプログラム部分の送信ビットレートを調節する。レシーバによるセッションの初期化要求ごとに、サーバは、ＲＴＳＰ ＳＥＴＵＰ ＲＥＳＰＯＮＳＥという表題のメッセージによって応答する。レシーバによって送信されたＲＴＳＰ ＰＬＡＹという表題の第３のメッセージによって、サーバが、プログラムの送信を開始する。メッセージＲＴＳＰ ＰＬＡＹは、引き続き要求と見なされ、リカバリの目的で送信されるプログラムの部分の時間マーカ・パラメータを含む。また、このＰＬＡＹメッセージには、送信されるプログラム部分に対応するデータを送信する速度をサーバに示す速度パラメータも含まれている。

本発明の一実施形態によれば、オーディオビジュアル・プログラムのコンテンツは、ビデオについてはＨ.２６４コーデックに従って、オーディオについてはＡＡＣコーデックに従って符号化され、イントラ画像で始まる基本データのブロックのサイズは、リカバリにおいて２秒の期間に対応し、データのカプセル化は、ＭＰＥＧ送信ストリーム・フォーマットに従って行われ、種々のバージョンに対応付けられたビットレートは、５００キロビット／秒、１メガビット／秒、１．５メガビット／秒、及び、２メガビット／秒である。サーバ上でオーディオビジュアル・プログラムのコンテンツ・ファイルに関連付けられ、かつ、そのプログラムの種々のバージョンの情報と、種々の関連付けられたビットレートの情報とを含む記述ファイルは、例えば次の形態を有するＳＤＰフォーマット・ファイルである。
ｖ＝０
ｏ＝ − １１ ＩＮ ＩＰ４ １９２．１６８．１．３３
ｓ＝ Ｅｘａｍｐｌｅ ｏｆ ｍｕｌｔｉｍｅｄｉａ ｓｔｒｅａｍ
ｂ＝ＲＲ：０
ａ＝Ｘ−ｋｅｙｆｒａｍｅ−ｐｅｒｉｏｄ＝２
ａ＝ｃｏｎｔｒｏｌ：＊
ａ＝ｒａｎｇｅ：ｎｐｔ＝０−３００
ｍ＝ｖｉｄｅｏ ０ ＲＴＰ／ＡＶＰ ３３
ｂ＝ＴＩＡＳ：５０００００
ａ＝ｃｏｎｔｒｏｌ：ｔｒａｃｋＩＤ＝０
ｍ＝ｖｉｄｅｏ ０ ＲＴＰ／ＡＶＰ ３３
ｂ＝ＴＩＡＳ：１００００００
ａ＝ｃｏｎｔｒｏｌ：ｔｒａｃｋＩＤ＝１
ｍ＝ｖｉｄｅｏ ０ ＲＴＰ／ＡＶＰ ３３
ｂ＝ＴＩＡＳ：１５０００００
ａ＝ｃｏｎｔｒｏｌ：ｔｒａｃｋＩＤ＝２
ｍ＝ｖｉｄｅｏ ０ ＲＴＰ／ＡＶＰ ３３
ｂ＝ＴＩＡＳ：２００００００
ａ＝ｃｏｎｔｒｏｌ：ｔｒａｃｋＩＤ＝３

このＳＤＰファイルの例では、４つのストリーム（ＭＰＥＧ送信ストリーム）が示されており、Ｍｂｉｔ／ｓ（メガビット／秒）で表されるビットレートに対応するパラメータｂ＝ＴＩＡＳを用いてそれらの各々のビットレートに関連付けられている。

図５には、本発明の一実施形態による、レシーバと拡散サーバとの間の通信の確立が示されており、また、視聴されるプログラムの種々のバージョンが、いつ、サーバ上で個別のファイルに記憶されるかが示されている。レシーバは、種々のストリームからリカバリされるオーディオビジュアル・プログラム部分の受信の初期化を行う。復元期間中に、レシーバは、連続的に要求されるプログラム部分ごとに、サーバに対して、ネットワーク上の帯域幅条件に適合したバージョンを示し、それに対応するストリームのデータを受信する。各々のストリームは、同一バージョンのデータの送信に対応する。一実施形態によれば、レシーバは、この送信の前に、利用可能なバージョンと同数の初期化メッセージを送信する。

各々のバージョンについて初期化段階（ＳＥＴＵＰ）が完了すると、レシーバは、必要とされるブロックと送信速度とに対応するバージョン及び時区間（時間マーカを使用する）を指定するＰＬＡＹ要求を送信することによって、ある１つのバージョンから別のバージョンに移行できる。他の実施形態によれば、レシーバは、送信期間中に、あるバージョンへの最初のアクセスの前に、ＳＥＴＵＰ初期化要求を送信できる。

図６は、本発明の一実施形態による、レシーバによって使用される方法を示すブロック図である。ステップＳ１は、レシーバがストリーミングでのプログラムの受信の初期化をまだ行っていない最初のステップである。このステップにおいて、レシーバは、レシーバを制御しているユーザからのコマンドについて待機中である。ステップＳ２において、レシーバは、ストリーミング拡散セッションの初期化を行う。レシーバは、サーバから受信して復元すべきオーディオビジュアル・プログラムの対象ＵＲＬアドレスを指定する第１のＲＴＳＰ ＤＥＳＣＲＩＢＥメッセージを送る。このＵＲＬアドレスは、例えば、ｒｔｓｐ://ｅｘｅｍｐｌｅ.ｃｏｍ/ｍｏｖｉｅ/であってもよい。この対象アドレスは、拡散の制御についてのリファレンスとして機能する。サーバは、種々のビットレートで符号化されて拡散されるオーディオビジュアル・プログラムの種々のバージョンに対応する送信ストリーム特性をレシーバに示すＲＴＳＰ ＤＥＳＣＲＩＢＥ ＲＥＳＰＯＮＳＥタイプ・メッセージを送信する。この情報は、バージョン数、それらのバージョンの各々の識別子、符号化ビットレート、及び、データのブロックのサイズを含む。次のメッセージ交換である、レシーバから送信されるＲＴＳＰ ＳＥＴＵＰと、サーバから送信されるＲＴＳＰ ＳＥＴＵＰ ＲＥＳＰＯＮＳＥとによって、ストリーミング拡散セッションが準備される。レシーバは、初期化段階Ｓ２において受信された情報を記憶して、オーディオビジュアル・プログラムの部分（１つ又は複数のデータ・ブロックを構成する）の拡散と受信とについての連続するＲＴＳＰ ＰＬＡＹ要求を送信できる。ステップＳ３において、レシーバは、受信すべき（従って、サーバによって拡散されるべき）プログラムの部分の拡散に固有のパラメータを含むＲＴＳＰ ＰＬＡＹ要求を送信する。

本発明の一実施形態によるＲＴＳＰ ＰＬＡＹ要求の構造は、次の通りである。
ＰＬＡＹ ｒｔｓｐ：／／ｍｕｌｔｉｍｅｄｉａ．ｅｘｅｍｐｌｅ．ｃｏｍ／ｓｔｒｅａｍ／ｔｒａｃｋＩＤ＝１ ＲＴＳＰ／１．０
Ｃｓｅｑ： ８３３
Ｒａｎｇｅ： ｎｐｔ＝０−２
Ｓｐｅｅｄ： １

ここで、ＰＬＡＹは、要求が、復元を目的とする、データ・ブロックの拡散を要求するメッセージであることを示す。

Ｃｓｅｑは、初期化ステップＳ２においてサーバによって示される順序番号を示し、Ｒａｎｇｅは、拡散の開始から０〜２秒の時間的位置に対応するプログラム部分を示し、Ｓｐｅｅｄは、拡散速度を示す。

オーディオビジュアル・プログラムの復元期間中の中断を回避するために、レシーバは、受信バッファにおいて十分な量のデータを維持できるように、予期する次のプログラム部分についてのＲＴＳＰ ＰＬＡＹ要求を送信する。望ましくは、受信バッファは、復号処理の前に、２秒間の利用可能な受信プログラムを保持する。利点として、また、ネットワーク上の利用可能な帯域幅の変動を吸収するために、受信バッファは、送信されたオーディオビジュアル・プログラムの数秒間の復元に対応する多くのデータ項目を保持できる。

本発明の一実施形態によれば、また、簡素化のために、種々のバージョンから得られるデータ・ブロックの拡散は、単一のＲＴＳＰセッション期間中に行われる。従って、サーバ上の単一ファイル内において符号化されたプログラムの種々のバージョンを連結することは好都合である。

継続時間ｄのオーディオビジュアル・プログラムがビットレートＢ０＝５００Ｋｂｐｓ、Ｂ１＝１Ｍｂｐｓ、Ｂ２＝１．５Ｍｂｐｓ、及び、Ｂ３＝２Ｍｂｐｓで符号化され、かつ、ビットレートＢｉで符号化されたプログラムのｉ番目のバージョンに時間的位置ｔからアクセスすると仮定すると、対応するＲＴＳＰ ＰＬＡＹ要求のＲａｎｇｅパラメータは、次のように定義される。
Ｒａｎｇｅ＝ｉ×ｄ＋ｔ

ステップＳ４において、レシーバは、サーバ上で対象となったプログラムの部分を符号化しているデータ・ブロックを受信する。レシーバはこのデータ・ブロックを受信バッファに記憶し、この受信バッファでデータ・ブロックがレシーバのオーディオ／ビデオ復号モジュールによって読み取られる。

ステップＳ５は、Ｓ４で受信された部分がプログラムの最後のものであるか否かを判定し、最後のものであるならば、拡散は終了する。

ステップＳ６において、Ｓ４で受信されたデータの部分が時間的位置に関してオーディオビジュアル・プログラムの最後のものでない場合、レシーバは、ネットワーク上で利用可能な帯域幅の推定を実行する。

本発明の一実施形態によれば、帯域幅の推定には、サーバから得られる実行可能な拡散ビットレートを特定するステップと、所定期間にわたってビットレートを測定するステップとが含まれる。利点として、帯域幅の推定には、重み付けステップが含まれ得る。本発明の一実施形態によれば、この重み付けステップには、平均値を、この値付近の帯域幅の急速な変動を克服して得ることを可能にする平滑化又は積分のステップが含まれる。レシーバは、ネットワーク帯域幅における急速な変動を吸収できるバッファ・メモリ（受信バッファ）を備えている。

本発明によれば、帯域幅の推定は、基本データ・ブロック毎に、又は、所定数の基本データ・ブロックを含むプログラム部分について、繰り返すことができる。

本発明の一実施形態によれば、レシーバは、ＲＴＳＰ ＰＬＡＹ要求に応答してサーバによって送信された情報を用いて帯域幅推定を実行する。

ＲＴＳＰ ＰＬＡＹ要求に対する、サーバによって送信される応答は、次の形態を有する。
ＲＴＳＰ／１．０ ２００ ＯＫ
Ｃｓｅｑ： ８３４
Ｒａｎｇｅ： ｎｐｔ＝０−２
ＲＴＰ−Ｉｎｆｏ： ｕｒｌ＝ｒｔｓｐ：／／ｍｕｌｔｉｍｅｄｉａ．ｅｘｅｍｐｌｅ．ｃｏｍ／ｓｔｒｅａｍ／ｔｒａｃｋＩＤ＝１； ｓｅｑ＝４５１０２； ｒｔｐｔｉｍｅ＝１２３４５６７８

ここで、ｒｔｐｔｉｍｅは、間隔ｎｐｔによって示されたプログラム部分の開始を示す時間マーカである。

例えば、ＭＰＥＧ―２ ＴＳフォーマットで符号化され、送信セッションの初期化ステップでレシーバに送られる、９０００の値を有するストリームのクロック・プログラムを考えた場合、レシーバは、データ・ブロックの受信時に対応する次の時間間隔ｒａｎｇｅｄｕｒａｔｉｏｎを計算できる。
ｒａｎｇｅｄｕｒａｔｉｏｎ＝ｒｔｐｔｉｍｅ ｅｎｄ−ｒｔｐｔｉｍｅ ｓｔａｒｔ

ここで、ｒｔｐｔｉｍｅ ｓｔａｒｔは、サーバの応答の情報フィールドＲＴＰ−Ｉｎｆｏ内に示されたパラメータｒｔｐｔｉｍｅの値であり、
ｒｔｐｔｉｍｅ ｅｎｄ＝フィールドＲＴＰ―Ｉｎｆｏのｒｔｐｔｉｍｅ＋９００００
である。

ここで、９００００は、拡散セッションの初期化段階の期間中に示されるクロックＲＴＰである。

次に、データ・ブロックの受信期間にわたる瞬間ビットレートは、その時間間隔にわたって受信されるデータのバイト数（ＲＴＰプロトコルに従って拡散するデータのパケットを構成するバイト数）を加算し、そのバイト数に８を乗算してビット数（２進要素）を得て、その積の結果を受信継続時間で除算することによって、計算される。

すなわち、瞬間ビットレートの表現式は、次のようになる。
Ｂｉ＝バイト数×８／ｒａｎｇｅｄｕｒａｔｉｏｎ

本発明の一実施形態によれば、このようにして計算された瞬間ビットレートの値を次に平滑化アルゴリズムに用いて、より正確なビットレート値を定める。

このアルゴリズムは、繰り返しプロセスを使用することによって、前の複数の繰り返しにおいて計算された瞬間ビットレートの値を考慮して取得し得るビットレートを特定する。

なお、ｉは、受信データの送信期間中における、有効ビットレートおよびその分散（バリアンス）の計算のｉ番目の繰り返しを指し示すインデックスである。

次の繰り返しについての将来ビットレートの推定は、次のように計算される。
ａｖｇ_ｉ＋１＝（１−α）×ａｖｇ_ｉ＋α×Ｂ_ｉ

ここで、Ｂ_ｉは測定されたビットレートであり、ａｖｇ_ｉは現在の繰り返しについて計算された平均値であり、αは瞬間ビットレートの測定値に起因する重み付け係数である。

好ましくは、αの値は、１／１６に等しい。

重み付けされた平均値に加えて、本発明によって使用されるアルゴリズムは、ビットレートについての分散を推定する。分散は、ビットレートと同様に平滑化される。すなわち、
Δ_ｉ＝｜Ｂ_ｉ−ａｖｇ_ｉ｜
ｖａｒ_ｉ＋１＝（１−β）×ｖａｒ_ｉ＋β×Δ_ｉ

ここで、Δ_ｉは、計算の現在の繰り返しについての、測定されたビットレートと平均ビットレートとの間の差分であり、ｖａｒ_ｉは現在の繰り返しについて計算された分散（バリアンス）であり、βは、現在の推定の分散値についての重み付け係数である。

好ましくは、βの値は、１／８に等しい。

アルゴリズムの繰り返しごとに、オーディオビジュアル・プログラムの拡散について取得し得るビットレートの推定は、次のように計算される。
Ｂ_ｉｍａｘ＝ａｖｇ_ｉ−４×ｖａｒ_ｉ

これにより、もし分散が大きければ、それは、レシーバが平均の利用可能な帯域幅よりも狭い帯域幅を使用することを意味する。また、帯域幅が安定し、かつ、分散が小さい場合、レシーバは、サーバと自身との間で利用可能な帯域幅の全てを使用する。

利点として、レシーバが全ての利用可能な帯域幅を使用する場合、レシーバは、受信するいくつかのプログラム基本部分のグループ化を目的とするＲＴＳＰ ＰＬＡＹ要求をサーバ宛に送信し、これによって、サーバが極めて定期的な要求でオーバーロード状態になることを回避する。レシーバは、例えば、同じ要求で、サーバに対して２つ又は４つの基本データ・ブロックを要求できる。

本発明の一実施形態によれば、分散が大き過ぎる場合、例えば、その値がビットレートの値の半分より大きい場合、ビットレートと分散との推定は、次のように計算される。
ａｖｇ_ｉ＋１＝（ａｖｇ_ｉ＋Ｂ_ｉ）／２、および
ｖａｒ_ｉ＋１＝ａｖｇ_ｉ＋１／１０

本発明の変形例によれば、レシーバは、オーディオビジュアル・プログラムの同一バージョンをポインティングし、かつ、ＲＴＳＰ制御プロトコルにおいて規定された速度パラメータを変更することによって、ネットワークが現在のビットレートより大きいビットレートでの拡散を許すか否かを判定する。例えば、現在のビットレートが１.５メガビット／秒である場合、レシーバは、「速度」パラメータを速度＝１.３４という値で指定する要求をサーバに送信することによって、ネットワークの容量を２メガビット／秒での送信が可能であると評価する。

ＵＲＬ「ｍｕｌｔｉｍｅｄｉａ.ｅｘｅｍｐｌｅ.ｃｏｍ／ｓｔｒｅａｍ」によって所在が特定されるオーディオビジュアル・プログラムの２秒目と４秒目との間の時間間隔に対応し、かつ、１.５メガビット／秒の現在の拡散ビットレートに対して２メガビット／秒のビットレートを有するデータ・ブロックを受信するために送信されるＲＴＳＰ要求は、例えば次の形態を有する。
ＰＬＡＹ ｒｔｓｐ：／／ｍｕｌｔｉｍｅｄｉａ．ｅｘｅｍｐｌｅ．ｃｏｍ／ｓｔｒｅａｍ／ｔｒａｃｋＩＤ＝１ ＲＴＳＰ／１．０
Ｃｓｅｑ： ８３３
Ｒａｎｇｅ： ｎｐｔ＝２−４
Ｓｐｅｅｄ： １．３４

ステップＳ７において、レシーバは、利用可能な帯域幅と帯域幅の変動との計算結果を考慮して、サーバ宛に送信すべき要求のパラメータを定める。本発明の一実施形態によれば、レシーバは、帯域幅と分散との計算値の組み合わせに応じて、ＲＴＳＰ要求の速度パラメータを変更する。例えば、本発明の変形例によれば、送信速度の低下のみならずデータの喪失にも至る可能性があるネットワークの輻輳の場合に、レシーバは、対応するバージョンにおいて失われたデータを、より低いビットレートと増大した送信速度とで受信するために、新たな要求を実行する。より低いビットレートと増大した送信速度とを使用することによって、一方では、サーバとレシーバとの間を通過するデータの量を低減でき、また、サーバによって先に送信されたデータの喪失に起因する時間の喪失を迅速に補償する。本発明の一実施形態によれば、プログラムの部分の送信期間中のデータの喪失を検出するために、レシーバは、データを搬送するＲＴＰパケットのヘッダの順序番号を使用する。データの喪失とデータを再送信する義務とにより、プログラムの復元期間中に、受信バッファのフィリング・レート（ｆｉｌｌｉｎｇ ｒａｔｅ）が低下し、かつ、バッファにおけるデータの喪失に関連するアーティファクトのリスクが増大する結果となる。利点として、レシーバは、前述のアルゴリズムを再び実施する前に、より低いビットレートと１より大きい速度パラメータとを示すＲＴＳＰ ＰＬＡＹ要求を送信する。

図７には、本発明の一実施形態による、オーディオビジュアル・プログラムを受信して表示するレシーバ２が示されている。双方向性ネットワーク・インタフェース２０１が、リカバリ（復元）すべきオーディオビジュアル・プログラムを符号化したデータの受信を可能にする。インタフェース２０１は、また、拡散サーバとの間での制御メッセージの送受信も可能にする。デマルチプレクサ２０２が、受信フラックス（ｒｅｃｅｐｔｉｏｎ ｆｌｕｘ）からのプログラムの受信に関連するデータと制御メッセージとをフィルタリングし、それらを受信バッファ２０３に記憶する。オーディオビジュアル・プログラムを符号化したデータは、オーディオ／ビデオ復号器２０４によって読み出され、このオーディオ／ビデオ復号器２０４は、これらのデータを復号して、これらに対応する信号を出力インタフェース２０５に送る。出力インタフェース２０５に接続された表示装置（不図示）が、ユーザに対するプログラムの表示を可能にする。構成要素２０１，２０２，２０３，２０４及び２０５のセットは制御ユニット２００によって制御され、この制御ユニット２００には、本発明の一実施形態によれば、ソフトウェア・ルーチンの実行とデータの処理とを可能にするマイクロコントローラと、これに対応付けられたメモリとが含まれている。制御ユニット２００は、更に、サーバから受信された制御メッセージを解析し、サーバに送信される制御メッセージを生成する。

図８には、本発明の一実施形態による制御ユニット２００が示されている。この制御ユニットには、ソフトウェア・アプリケーションの実行を担っているマイクロコントローラ２１０が含まれている。アプリケーションの実行可能コードは、レシーバ２の起動時に不揮発性メモリ２１１に記憶され、レシーバ２が稼動している時に、ワーキング・メモリ２１２にコピーできる。ワーキング・メモリ２１２には、ソフトウェア・アプリケーションの実行用データと受信されたデータとを記憶するランダム・アクセス・メモリが含まれている。制御ユニット２００には、帯域幅推定用のモジュール２１３も含まれている。この帯域幅推定モジュール２１３は、受信バッファから読み出されたデータを用いて、サーバとレシーバ２との間のリンク上での利用可能な帯域幅を計算する。ＲＴＳＰ制御モジュール２１４が、推定モジュール２１３において計算された利用可能な帯域幅の値に応じて、ＲＴＳＰ要求を作成する。このＲＴＳＰ制御モジュールは、受信バッファ内のＲＴＳＰ ＰＬＡＹ要求に対する応答を構成するデータを読み出して、時間マーカｒｔｐｔｉｍｅを推定モジュール２１３に送る。制御ユニット２００の種々のモジュール相互間で交換されるデータは、内部バス２１６を通過する。レシーバの他の機能モジュールとの一連のデータ交換は、インタフェース・モジュール２１５を介して行われる。

ここでは、本発明をＲＴＰプロトコルとＲＴＳＰプロトコルとに基づく実施形態について説明したが、本発明がこのＲＴＰプロトコルとＲＴＳＰプロトコルの使用に限定されないことは明らかである。本発明は、また、ＲＴＰ及びＲＴＳＰにそれぞれ類似した特徴を有し、かつ、特に、再生（描画）されるオーディオビジュアル・プログラムの部分について、バージョン、開始時間、及び、長さ（あるいは停止時間）を規定（選択）することを可能にするパラメータを有する例えばＰＬＡＹコマンドのような制御コマンドを提供する、任意のリアルタイム転送プロトコル及びそれに対応するサーバ制御プロトコルに関する。

Claims (12)

1. サーバ上に記憶されたオーディオビジュアル・プログラムをレシーバに接続された表示装置上に再生するために受信する方法であって、前記オーディオビジュアル・プログラムは前記サーバ上で少なくとも２つのバージョンで入手可能であり、前記バージョンの各々が、連続的に描画されるべき前記オーディオビジュアル・プログラムの部分をそれぞれ表す連続したデータ・ブロックを有しており、前記バージョンは、各々、同数のブロックを有しており、前記ブロックは、各々、前の画像を参照することなく符号化された画像から始まっており、前記方法は、レシーバ・レベルにおいて、
   前記サーバによって第１のビットレートで送信された前記バージョンのうちの第１のバージョンから得られる少なくとも１つのブロックを有する前記オーディオビジュアル・プログラムの第１の部分を、送信プロトコルに従って受信するステップであって、前記第１の部分は前記サーバ上のファイルのサブセットであり、前記ファイルは複数の部分を含んでおり、前記複数の部分の各々の部分の位置が、前記ファイル内にインデックス付けによって示されている、該ステップと、
   前記サーバによって前記第１のビットレートで送信された前記オーディオビジュアル・プログラムの前記第１の部分の受信後に帯域幅を特定するステップと、
   制御プロトコルに従って、前記サーバに要求を送信するステップであって、前記制御プロトコルは、コマンドの使用によってコンテンツのリアルタイム送信を制御するようにされており、かつ、いくつかのデータ部分の中から送信されるべきデータ部分をファイル内で識別するようにされており、前記識別はインデックス付けによって実現されており、前記要求は、前記サーバと前記レシーバとの間の帯域幅の特定された値に従う、前記オーディオビジュアル・プログラムの前記バージョンのうちの１つでの前記オーディオビジュアル・プログラムの第２の部分の識別情報を含んでおり、前記識別情報は前記第２の部分の開始及び終了の時間マーカを含んでいる、該ステップと、
   を含んでいることを特徴とする、前記方法。
2. 前記要求は送信速度パラメータを更に含んでいることを特徴とする、請求項１に記載の方法。
3. 前記受信するステップはＲＴＰ送信プロトコルを使用することを特徴とする、請求項１又は２に記載の、オーディオビジュアル・プログラムを受信する方法。
4. 要求を送信する前記ステップはＲＳＴＰ制御プロトコルを使用することを特徴とする、請求項１から３のいずれか１項に記載の、オーディオビジュアル・プログラムを受信する方法。
5. 前記オーディオビジュアル・プログラムの前記バージョンが前記サーバ上に記憶された同一ファイル内に含まれていることを特徴とする、請求項１から４のうちの１項に記載の方法。
6. 前記オーディオビジュアル・プログラムが、前記サーバ上で、前記同一ファイル内における前記オーディオビジュアル・プログラムの前記バージョンの位置特定に関する情報を含む記述ファイルに対応付けられていることを特徴とする、請求項１から５のいずれか１項に記載の方法。
7. 前記サーバと前記レシーバとの間の利用可能な帯域幅の特定には、前記第１のビットレートで受信された前記オーディオビジュアル・プログラムの前記部分の少なくとも１つの特徴の分析が含まれていることを特徴とする、請求項１から６のいずれか１項に記載の方法。
8. 前記部分の前記少なくとも１つの特徴は送信されたビットの数であることを特徴とする、請求項７に記載の方法。
9. 要求を送信する前記ステップはＲＳＴＰプロトコルのＰＬＡＹコマンドを使用することを特徴とする、請求項１から８のいずれか１項に記載の方法。
10. 前記サーバと前記レシーバとの間の帯域幅を特定する前記ステップはＲＳＴＰプロトコルのＰＬＡＹコマンドに対する前記サーバの応答を使用することを特徴とする、請求項１から９のいずれか１項に記載の方法。
11. サーバによって拡散されたオーディオビジュアル・プログラムを受信する装置であって、前記オーディオビジュアル・プログラムは前記サーバ上で少なくとも２つのバージョンで入手可能であり、前記バージョンの各々が、前記オーディオビジュアル・プログラムの画像解像度に対応しており、かつ、連続する複数の部分を有しており、前記バージョンは、各々、イントラ画像から始まっており、前記装置は、
    前記サーバによって第１のビットレートで拡散された前記バージョンのうちの第１のバージョンの前記オーディオビジュアル・プログラムの第１の部分を、送信プロトコルに従って受信する手段と、
    前記サーバによって前記第１のビットレートで拡散された前記オーディオビジュアル・プログラムの前記第１の部分の受信後に帯域幅を特定する手段と、
    制御プロトコルに従って、前記サーバに要求を送信する手段であって、前記制御プロトコルは、コマンドの使用によってコンテンツのリアルタイム送信を制御するようにされており、かつ、いくつかのデータ部分の中から送信されるべきデータ部分をファイル内で識別するようにされており、前記識別はインデックス付けによって実現されており、前記要求は、前記サーバと前記レシーバとの間の帯域幅の特定された値に従う、前記オーディオビジュアル・プログラムの前記バージョンのうちの１つでの前記オーディオビジュアル・プログラムの第２の部分の識別情報を含んでおり、前記識別情報は前記第２の部分の開始及び終了の時間マーカを含んでいる、該手段と、
    を有していることを特徴とする、前記装置。
12. 前記要求は送信速度パラメータを更に含んでいることを特徴とする、請求項１１に記載の装置。

Images