JP5610743B2 - コンテンツ受信方法及び装置 - Google Patents

Description

本発明は、一般に通信ネットワークに関し、より詳細にはコンテンツの受信に関する。

技術進歩によって、テレビブロードキャスト／マルチキャストやビデオブロードキャスト／マルチキャストなどのメディアプログラムが、ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）パケット、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）セル、同様のパケットタイプなどのデータパケットを使用することによって、エンドユーザに配信されている。

メディアファイルやメディアクリップ全体がダウンロードされた後にエンドユーザによりデジタルメディアコンテンツを再生する従来の方法とは異なり、メディアファイル又はメディアクリップのコンテンツは、マルチキャスト／ブロードキャスト又はユニキャストモードを利用してエンドユーザにストリーミングされ、メディアコンテンツは、当該メディアコンテンツの所定量のデータストリームが受信機にバッファリングされた後に復号化及び再生される。ここでは、データストリームは、情報を送信し、又は送信される情報を受信するのに利用されるデジタル符号化されたコヒーレント信号のシーケンスである。例えば、Ｈ．２６４では、デジタル符号化されたコヒーレント信号がアクセス単位（ピクチャの符号化データ）となる。データストリームの１つの特徴は、アクセス単位に関して時間の制約があることであり、これは、データストリームの各アクセス単位が各自のタイムスタンプに従って次々に送信され、後のアクセス単位が前のアクセス単位の後に送信されることを意味する。

伝送環境により、コンテンツのデータストリームは安定的なビットレートによりエンドユーザに送信されないかもしれない。これは、コンテンツの再生を断続的なものにする。このため、コンテンツのスムースな再生を取得するため、所定のサイズのバッファが、その再生開始前にコンテンツの一部のデータストリームをバッファリングすることによって、不安定なネットワークを介したコンテンツの予測不可能な配信を補償するのに利用される。通常、バッファのサイズはネットワーク伝送品質に応じて変更される。一般に、ネットワークの伝送品質が悪化するに従って、より大きなバッファサイズが必要となる。さらに、バッファサイズは、伝送品質が時間可変的である無線ネットワーク及び他のネットワークにおいては通常は大きなものとなる。しかしながら、バッファサイズが大きくなるに従って、メディアコンテンツへの切り換え時にコンテンツのデータストリームをバッファリングするのにより大きな時間を必要とする。コンテンツへの切り換え時にストリームデータをバッファリングすることによって生じる遅延を低減させることが望まれる。

ＵＳ２００８／０３７５２７ ＥＰ１６４３７１６

"Ｒｏｂｕｓｔ ｖｉｄｅｏ−ｏｎ−ｄｅｍａｎｄ ｓｔｒｅａｍｉｎｇ ｉｎ ｐｅｅｒ−ｔｏ−ｐｅｅｒ ｅｎｖｉｒｏｎｍｅｎｔｓ"（Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，Ｅｌｓｅｖｉｅｒ Ｓｃｉｅｎｃｅ Ｐｕｂｌｉｓｈｅｒｓ ＢＶ，Ａｍｓｔｅｒｄａｍ，ＮＬ，ｖｏｌ．３１，ｎｏ．３） "Ｍｕｌｔｉｐｌｅ Ｓｅｎｄｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｖｉｄｅｏ Ｓｔｒｅｍａｉｎｇ"（ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｍｕｌｔｉｍｅｄｉａ，ＩＥＥＥ Ｓｅｒｖｉｃｅ Ｃｅｎｔｅｒ，Ｐｉｓｃａｔａｗａｙ，ＮＪ，ＵＳ，ｖｏｌ．６，ｎｏ．２）

本発明の課題は、上記問題点に鑑み、他のコンテンツへの変更時の遅延を低減するためのコンテンツの受信技術に関する。

上記課題を解決するため、本発明の一特徴は、クライアント装置がコンテンツを受信するための方法であって、前記コンテンツに対するリクエストを送信するステップと、前記リクエストに応答して、第１装置からデータストリームにより搬送される前記コンテンツの所与の時間ポジションにスタートする前記コンテンツのデータを受信し、少なくとも１つの第２装置から前記コンテンツの前記所与の時間ポジションより前の時間ポジションに対応する前記コンテンツのデータを受信するステップとを有する方法に関する。

さらに、本発明の他の特徴は、コンテンツを受信するクライアント装置であって、第１装置からデータストリームにより搬送されたデータを受信し、少なくとも１つの第２装置からデータを受信するよう構成される受信モジュールと、前記少なくとも１つの第２装置から前記コンテンツをリクエストするため、時間ポジションを含むメッセージを送信するよう構成される処理モジュールとを有し、前記送信されたメッセージに応答して、前記時間ポジション以前のデータが、前記少なくとも１つの第２装置から受信されるクライアント装置に関する。

本発明によると、コンテンツの受信について他のコンテンツへの変更時の遅延を低減するためことが可能になる。

図１は、本発明の実施例によるチャネル変更方法を示すフローチャートである。 図２は、本発明の実施例によるシステムを示す概略図である。 図３は、本発明の実施例によるチャネルを変更するためのクライアント装置のブロック図である。

以下、図面を参照して本発明の実施例が詳細に説明される。以下の説明では、既知の機能及び構成の詳細な説明は、簡単化のため省略されるかもしれない。

本発明の実施例によると、典型的なネットワークは、少なくとも１つのビデオサーバと、少なくとも１つのキャッシュサーバと、少なくとも１つのクライアント装置とを有する。クライアント装置は、ビデオデータを受信するよう構成される。ビデオサーバは、ビデオデータを提供するよう構成される。ビデオデータは、ビデオサーバ又はビデオサーバに通信接続される他の装置においてストリーミングされる。キャッシュサーバは、ビデオサーバからのビデオデータをキャッシュ処理するよう構成され、さらにクライアント装置からのキャッシュされたデータに対するリクエストに応答して、キャッシュされたビデオデータを提供するよう構成される。

図１は、本発明の実施例によるマルチキャスト環境におけるチャネル変更処理を示すフローチャートである。

ステップ１０１において、クライアント装置は、テレビチャネルなどのビデオコンテンツへのチューニングを示すリクエストを送信する。通常、このリクエストは、クライアント装置がオンされるか、又はあるビデオコンテンツから他のものにスイッチされるとき、クライアント装置により送信される。

ステップ１０２において、クライアント装置からのビデオコンテンツに対するリクエストに応答して、クライアント装置は、ビデオサーバからリクエストされたビデオコンテンツのビデオデータをデータストリームにより受信し、データストリームにより搬送されたビデオデータ（以下において、「以降のビデオデータ」と呼ぶ）が、リクエストされたビデオコンテンツの現在の再生ポジションＴから受信される。ビデオマルチキャストサービスのようなアプリケーションでは、ビデオコンテンツはデータストリームの形式により送信されるという事実のため、クライアント装置は、マルチキャストストリームを通じて時間軸に関してポジションＴの後のビデオデータしか受信できない。

ステップ１０３において、クライアント装置は、少なくとも１つのキャッシュサーバから、時間軸に関してポジションＴの前のリクエストされたビデオコンテンツのビデオデータ（以下において、「以前のビデオデータ」と呼ぶ）を受信する。この少なくとも１つのキャッシュサーバは、時間軸に関してポジションＴの前のリクエストされたビデオコンテンツのビデオデータを提供することが可能である。キャッシュサーバは、リクエストされたビデオコンテンツのデータストリームを受信し続け、受信したデータストリームに含まれるビデオデータを格納する専用のサーバ、又はリクエストされたビデオコンテンツのデータストリームを受信を開始するようある時点で指示され、ビデオデータを格納する専用のサーバとすることが可能である。以下の方法は、以前のビデオデータを受信するため、クライアント装置により利用可能である。クライアント装置は、キャッシュサーバにポジションＴから後方の以前のビデオデータを受信するよう指示する。これは、以前のビデオデータが、ポジションＴからリクエストされたビデオコンテンツのスタートポジションへの方向に送信されることを意味する。以前のビデオデータが後方に送信されるため、クライアント装置又はキャッシュ装置は、以前のビデオデータがどの程度送信される必要があるか計算し、キャッシュサーバに通知する必要がない。このため、このような計算のための時間を節約し、キャッシュ装置とクライアント装置との間の信号のやりとりを回避することができる。ここでは、キャッシュされている以前のビデオデータは、ネットワークリソースが可能な程度の速さによりチャンクにより送信可能である。

ステップ１０４において、ビデオサーバ及び少なくとも１つのキャッシュサーバから受信され、クライアント装置にバッファリングされているビデオデータが所定の閾値に達したと判断された場合、クライアント装置は、ビデオサーバ及び少なくとも１つのキャッシュサーバからのビデオデータの組み合わせに基づき、ビデオを復号化及び表示する。ここで、当該閾値は、クライアント装置がビデオコンテンツをスムースに復号化及び表示することを可能にする値に設定される。ポジションＴからのビデオデータと、ポジションＴの前のビデオデータとが受信されるため、ビデオデータは、以下の方法を用いてポジションＴにおいて一貫的に合成可能である。アクセス単位などのビデオデータは、一般に送信される前にＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）によりカプセル化されるため、ビデオデータは、ＲＴＰヘッダの“ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ”フィールドに基づき、ビデオサーバ及び少なくとも１つのキャッシュサーバから受信したビデオデータをソート又は並び替えることにより、合成することができる。

バッファは、ビデオサーバからのビデオデータの他に、少なくとも１つのキャッシュサーバからの後方の以前のビデオデータにより充填されるため、チャネル変更を迅速にするため、バッファを所定の閾値まで充填するのにより短い時間しか使用されなくなる。バッファリングされたビデオデータが所定の閾値に達すると、クライアント装置は、合成されたビデオデータを復号化し、少なくとも“ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ”を有するビデオデータから始まるビデオコンテンツを表示する。さらに、バッファリングされているデータが所定の閾値に達した後、クライアント装置は、キャッシュサーバに以前のビデオデータを送信することを中止するか、又は以降に受信する以前のビデオデータを破棄するよう指示することができる。

さらに、閾値は、ビデオコンテンツの要求、符号化されたビデオコンテンツの特徴及び／又はネットワーク状態に従って静的な値又は動的な値とすることができる。閾値が動的に決定されるとき、それは、ＭＰＥＧ−４ Ｐａｒｔ ２のＶＢＶ（Ｖｉｒｔｕａｌ Ｂｕｆｆｅｒ Ｖｅｒｉｆｉｃａｔｉｏｎ）やＭＰＥＧ−４ ＡＶＳ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｓｔａｎｄａｒｄ）／Ｈ．２６４のＨＲＤ（Ｈｙｐｏｔｈｅｔｉｃａｌ Ｒｅｆｅｒｅｎｃｅ Ｄｅｃｏｄｅｒ）情報など、ビデオコンテンツの制御情報に基づき決定可能である。通常、制御情報は、ＨＲＤ又はＶＢＶ、タイムスタンプなどを有する。さらに、制御情報は、クライアント装置が特定のビデオフレームを正確にピッチするのを支援するのに利用可能である。例えば、復号化中、ＨＲＤによるｃｐｂ＿ｒｅｍｏｖａｌ＿ｄｅｌａｙと当初のｒｅｍｏｖａｌ＿ｄｅｌａｙとが、復号化フレーム番号をチェックするのに適用可能である。ＨＲＤからのｄｐｂ＿ｏｕｔｐｕｔ＿ｄｅｌａｙは、何れのフレームが表示されるべきか求めるため、取得したフレーム番号と組み合わせ可能である。

本実施例の変形によると、クライアント装置は、ルータなど、ビデオサーバとクライアント装置との間に通信接続される他の中間装置から、リクエストされたビデオコンテンツを受信するようにしてもよい。この中間装置は、ビデオサーバから受信したリクエストされたビデオコンテンツを中継可能である。

本実施例の変形によると、送信帯域幅などのネットワークリソースが制限され、以降のビデオデータを搬送する接続と以前のビデオデータを搬送する接続との間に、このようなネットワークリソースの競合が存在する場合、以降のビデオデータを搬送する接続により高い優先度が与えられる。

本実施例によると、リクエストされたビデオコンテンツの送信接続の確立は、ステップ１０２とステップ１０３において別々にビデオサーバとキャッシュサーバにより実行される。しかしながら、本実施例の変形によると、何れのコンテンツが現在利用可能であるかなど、ビデオサーバ及びキャッシュサーバに関するすべての状態情報を所持する中央制御装置が、設けられる。クライアントが他のビデオコンテンツに変更することを意図すると、リクエストが中央制御装置に送信され、中央制御装置は、リクエストされたビデオコンテンツを有するビデオサーバと、リクエストされたビデオコンテンツのキャッシュされている以前のビデオデータを有するキャッシュサーバとに、クライアント装置との送信接続を実行するよう指示する。

本実施例の変形によると、ステップ１０２とステップ１０３の実行は、交換可能であるか、又は同時的なものとすることが可能である。

本実施例の変形によると、それはまた、ブロードキャスト及びユニキャスト環境に適用可能である。本実施例のマルチキャスト環境におけるステップ１０２に関して、クライアント装置は、リクエストされたビデオコンテンツの既存のマルチキャストグループに加わるか、又はリクエストされたビデオコンテンツの新たなマルチキャストグループに申込、その後に加入する必要がある。しかしながら、ブロードキャスト環境では、クライアント装置は、単に既存のブロードキャストチャネルによりリクエストされたビデオコンテンツを受信する。ユニキャスト環境では、リクエストされたビデオコンテンツのデータストリームを送信するためのユニキャスト送信接続が、クライアント装置とビデオサーバとの間で確立されるべきである。

本実施例の変形によると、キャッシュサーバは、ビデオサーバに設けられたモジュール、ネットワークにおける独立した装置、又はデータストリームによりリクエストされたビデオコンテンツを受信しながら受信したビデオコンテンツをバッファリングする他のクライアント装置のバッファとすることが可能である。

図２は、本実施例によるチャネル変更のためのシステムを示す概略図である。図２に示されるように、システムは、ビデオサーバ２０１と、キャッシュサーバＡ２０２と、キャッシュサーバＢ２０３と、テレビ２０８に接続されるＳＴＢ（Ｓｅｔ Ｔｏｐ Ｂｏｘ）、ラップトップ２０５、ＡＰ（Ａｃｃｅｓｓ Ｐｏｉｎｔ）２０６に接続されるデスクトップＰＣ２０７など、ビデオデータを復号化する機能を備えた各種クライアント装置とを有する。ビデオサーバが各ビデオチャネルがビデオコンテンツを有するビデオチャネル１〜１０を有し、キャッシュサーバＡがチャネル１〜５をキャッシュ処理するのに使用され、キャッシュサーバＢがチャネル６〜１０をキャッシュ処理するのに使用されると仮定する。ラップトップ２０５のユーザは、チャネル１を視聴中で、突然チャネル６にスイッチする。このため、ラップトップ２０５は、データストリームの現在の再生ポジション以降のチャネル６のビデオデータをビデオサーバ２０１から受信し、現在の再生ポジションからの後方の以前のビデオデータをキャッシュサーバＢ２０３から受信する。さらに、例えば、テレビ２０８のユーザはＳＴＢ２０４を介し現在チャネル６を視聴しており、ＳＴＢ２０４は、ビデオサーバから受信したビデオデータを格納するのに用いられるバッファを有することが可能である。このため、ラップトップ２０５は、後方のバッファリングされているビデオデータを取得するため、ＳＴＢ２０４との接続を確立することができる。この結果、チャネル変更処理における遅延が低減される。さらに、以前のビデオデータが複数のキャッシュサーバから受信される場合、調整機構が導入されるべきであることが理解される。１つのシンプルな機構は、クライアント装置が複数のキャッシュサーバから後方の以前のビデオデータを受信し、以降に受信される同一のビデオデータを破棄することである。

図３は、本発明の実施例によるクライアント装置のブロック図である。クライアント装置３００は、第１受信モジュール３０１と、第２受信モジュール３０２と、バッファ３０３と、デコーダモジュール３０４と、表示モジュール３０５と、処理モジュール３０６とを有する。第１受信モジュール３０１は、データストリームを介しリクエストされたビデオチャネルの以降のビデオデータを受信するのに使用される。第２受信モジュール３０２は、少なくとも１つのキャッシュサーバから、リクエストされたビデオチャネルの後方の以前のビデオデータを受信するのに使用される。また、受信モジュール３０２は、処理モジュール３０６によって、バッファ３０３にバッファリングされているデータが所定の閾値に達した後、受信された以前のビデオデータを破棄するよう指示される。バッファ３０３は、第１受信モジュール３０１と第２受信モジュール３０２により受信されたビデオデータをバッファリングするのに使用される。デコーダモジュール３０４は、表示モジュール３０５が表示する復号化されたビデオデータを生成するため、バッファ３０３のビデオデータを復号化するのに使用される。処理モジュール３０６は、他のチャネルへの変更時又はクライアント装置のオン時にチャネルにチューニングするためのリクエストを送信し、第１受信モジュール３０１にリクエストされたチャネルのコンテンツの時間ポジションからスタートするリクエストされたチャネルの以降のビデオデータを受信するよう指示し、例えば、時間ポジションを示すインデックスを含むメッセージを送信するなどによって、第２受信モジュール３０２に当該時間ポジション前のリクエストされたチャネルの以前のビデオデータを後方受信するよう指示し、デコーダモジュール３０４に、バッファ３０３にバッファリングされているビデオデータが所定の閾値に達したと判断されたとき、第１受信モジュール３０１と第２受信モジュール３０２とにより受信されるビデオデータの組み合わせを復号化するよう指示するのに使用される。さらに、処理モジュール３０６は、バッファのビデオデータが所定の閾値に達した場合、キャッシュサーバに以前のビデオデータの送信中止を指示するよう構成することが可能である。クライアント装置は、上述したすべてのモジュールを有する必要はないことは理解されるであろう。例えば、表示モジュール３０５はＳＴＢに対して冗長であり、また表示装置が復号化機能を有する場合には、デコーダモジュール３０４は冗長である。さらに、各モジュールは、所与の実現形態において合成又は分割されてもよい。

本実施例の変形によると、クライアント装置はさらに、データ提供モジュールを有する。データ提供モジュールは、バッファ３０３にバッファリングされている現在のビデオチャネルのビデオデータを、当該ビデオチャネルにスイッチした他のクライアント装置に提供するのに使用される。

本実施例の変形によると、本実施例による上述された方法、システム及び装置は、リソースが音声ストリームなどのストリームにより配信される他のリアルタイムリソース配信システムにおいて適用可能である。

いくつかの実現形態が説明された。しかしながら、各種変更が可能であることが理解されるであろう。例えば、異なる実現形態の各要素は、他の実現形態を生成するため、合成、補完、変更又は削除されるかもしれない。さらに、当業者は、他の構成及び処理が開示されたものについて置換可能であり、結果として得られる実現形態が少なくとも実質的に同一の機能を少なくとも実質的に同一の方法により実行し、開示されるような実現形態と少なくとも実質的に同一の結果を達成することを理解するであろう。

２０１ ビデオサーバ
２０２，２０３ キャッシュサーバ
３００ クライアント装置
３０１，３０２ 受信モジュール
３０３ バッファ

Claims (7)

1. クライアント装置がコンテンツを受信するための方法であって、
   前記コンテンツが第１装置によってデータストリームの形式により前記コンテンツの所与の時間ポジションにおいて送信されているときに前記コンテンツを要求するためのリクエストを前記第１装置に送信し、前記所与の時間ポジションを含むリクエストを少なくとも１つの第２装置に送信するステップと、
   前記リクエストに応答して、前記第１装置からデータストリームにより搬送される前記コンテンツの前記所与の時間ポジションにスタートする前記コンテンツのデータを受信し、前記少なくとも１つの第２装置から前記コンテンツの前記所与の時間ポジションより前の時間ポジションに対応する前記コンテンツのデータを受信するステップであって、前記コンテンツの前記所与の時間ポジションより前の時間ポジションに対応する前記コンテンツのデータは、前記少なくとも１つの第２装置から、前記所与の時間ポジションからスタートして前記コンテンツの開始ポジションへの方向で受信される、受信するステップと、
   を有する方法。
2. 前記第１装置と前記少なくとも１つの第２装置との双方から受信したデータ量が所定の閾値に達したと判断した場合、前記第１装置と前記少なくとも１つの第２装置から受信したデータに基づき前記コンテンツを表示するステップをさらに有する、請求項１記載の方法。
3. 前記第１装置から受信したデータと前記少なくとも１つの第２装置から受信したデータは、各データに係るシーケンス情報に基づき合成される、請求項１又は２記載の方法。
4. 前記第１装置と前記少なくとも１つの第２装置から受信したデータが所定の閾値に達したことに応答して、前記所与の時間ポジションの前の時間に対応する前記データの送信中止を示すメッセージを前記少なくとも１つの第２装置に送信するか、又は前記少なくとも１つの第２装置から受信したさらなるデータを破棄するステップをさらに有する、請求項１又は２記載の方法。
5. 前記所与の時間ポジションにスタートするデータは、ユニキャスト、マルチキャスト又はブロードキャストの何れかのモードによってデータストリームにより送信される、請求項１又は２記載の方法。
6. コンテンツを受信するクライアント装置であって、
   第１装置からデータストリームにより搬送された前記コンテンツの所与の時間ポジションにおいてスタートする前記コンテンツのデータを受信し、少なくとも１つの第２装置から前記コンテンツのデータを受信するよう構成される受信モジュールと、
   前記コンテンツが前記第１装置によってデータストリームの形式により前記コンテンツの前記所与の時間ポジションにおいて送信されているときに前記コンテンツを要求するためのリクエストを前記第１装置に送信し、前記少なくとも１つの第２装置からの前記コンテンツのデータを要求するための前記所与の時間ポジションを含むメッセージを送信するよう構成される処理モジュールであって、前記送信されたメッセージに応答して、前記所与の時間ポジションより前の前記コンテンツのデータが、前記少なくとも１つの第２装置から、前記所与の時間ポジションからスタートして前記コンテンツの開始ポジションへの方向で受信される、処理モジュールと、
   を有するクライアント装置。
7. 前記第１装置と前記少なくとも１つの第２装置から受信した前記コンテンツのデータをバッファリングするよう構成されるバッファをさらに有し、
   前記第１装置と前記少なくとも１つの第２装置から受信した前記コンテンツのデータが、各データに係るシーケンス情報に基づき合成される、請求項６記載のクライアント装置。

Images