JP2005124193A - 高速チャネル変更 - Google Patents

Abstract

【課題】 デジタルマルチキャストネットワークで、あるビデオチャネルから別のビデオチャネルに変更する際のビデオ提示の待ち時間を低減すること。
【解決手段】 例示的なサーバの実施例では、サーバは、マルチキャスト通信を使用して配信される複数のビデオチャネルの各ビデオチャネルについて少なくとも１つの独立フレームを保持するように構成され、また、要求されるビデオチャネルの保持された少なくとも１つの独立フレームを、ユニキャスト通信を使用して、要求元のクライアントに送信することにより、クライアントからのチャネル変更要求に応じるように適合される。例示的な方法の実施例では、マルチキャストのビデオ配信アーキテクチャにおける高速チャネル変更の方法は、あるマルチキャストグループに対応する要求されるチャネルを指示するチャネル変更要求を検出することと、要求されるチャネルの保持されたイントラフレームをユニキャスト通信として送信することと、を含む。
【選択図】 図１

Description

本開示は、一般にはデジタルビデオ環境におけるチャネルの変更に関し、詳細には、限定ではなく例示として、デジタルマルチキャストネットワークで、あるビデオチャネルから別のビデオチャネルに変更する際のビデオ提示の待ち時間を低減することに関する。

テレビジョンを使用した娯楽システムは、提供する番組とサービスを拡大している。放送網および従来のケーブルネットワークに見られるテレビ番組内容に加えて、テレビジョンサービスの提供業者は、オンデマンドビデオや、他の対話型のサービス、機能、およびアプリケーションを追加している。こうした独自のサービス、機能、アプリケーションが存在することと、利用可能な一般的な番組内容の幅が広がり続けていることにより、テレビジョンを用いた娯楽システムにデジタルネットワーク技術を採用することが推進されている。

デジタル技術を用いると、衛星およびケーブルの事業者は、契約者に提供するサービスの数と種類、そしてひいては１契約者あたりの平均収益を増すことができる。不都合な点として、デジタル技術は従来のアナログネットワークに比べて多くの利点を契約者に提供するが、いくつかの欠点もある。例えば、デジタルテレビジョンサービスでチャネルを変更するには、通例、アナログのテレビジョンサービスよりも時間がかかる。このチャネル変更に伴う待ち時間は、デジタルテレビジョンサービスの利用者にとって不快であり、苛立ちを生じさせる。

このチャネル変更の待ち時間とデジタル技術の他の欠点の結果、契約者の解約率が高くなり、すなわち、デジタルテレビジョンサービスを試す契約者の多くが短い期間のうちに従来のアナログサービスに戻ってしまう。契約者をアナログサービスからデジタルサービスに切り替えさせるには、幅広い一般的な営業費用から個々のインセンティブと設置費用にわたる経費がネットワーク事業者にかかることを意味する。さらに、ネットワーク事業者は通常、デジタルネットワークサービスと併せて追加サービス（例えば特別チャネル、ペイパービューなど）を販売する機会および／または能力をより多く有する。その結果、契約者の解約を低減することは、衛星およびケーブル事業者にとって財政的な利益となる。

したがって、例えばテレビジョンを使用した娯楽システムで、デジタルテレビジョンサービスでチャネルの変更により多くの時間がかかることに契約者が不満を抱く結果生じる、デジタルサービスから従来のアナログサービスへの解約を低減する方式および／または技術が必要とされる。

例示的なサーバの実施例では、サーバは、マルチキャスト通信を使用して配信される複数のビデオチャネルの各ビデオチャネルについて少なくとも１つの独立フレームを保持するように構成され、また、要求されるビデオチャネルの保持された少なくとも１つの独立フレームを、ユニキャスト通信を使用して、要求元のクライアントに送信することにより、クライアントからのチャネル変更要求に応じるように適合される。例示的な方法の実施例では、マルチキャストのビデオ配信アーキテクチャにおける高速チャネル変更の方法は、あるマルチキャストグループに対応する要求されるチャネルを指示するチャネル変更要求を検出することと、要求されるチャネルの保持されたイントラフレームをユニキャスト通信として送信することと、を含む。

他の方法、システム、方式、装置、サーバ、デバイス、媒体、手順、構成などの実施例については本明細書に記載する。

図面中では、同様かつ／または対応する態様、特徴、およびコンポーネントは、同じ符号を使用して参照する。

図１に、マルチキャストとユニキャスト両方の通信が可能なネットワーク１０４を含む例示的なビデオ配信アーキテクチャ１００を示す。ネットワーク１０４は、複数のネットワーク要素（図１には個別には図示せず）とともに実施される。各ネットワーク要素は、マルチキャストとユニキャスト通信の両方に対応することが可能であっても、または、各ネットワーク要素は、マルチキャスト通信かユニキャスト通信のどちらかに対応することが可能であってもよい。さらに、ネットワーク１０４は、マルチキャスト通信とユニキャスト通信の両方に関係するネットワーク要素と、マルチキャスト通信かユニキャスト通信のいずれかに関係する他のネットワーク要素を含むことができる（必ずしもこの両方を含まなくともよい）。

図に示すように、ビデオプロバイダ１０２、チャネル変更サーバ１０８、および１つまたは複数のクライアント１０６（１）、１０６（２）、．．．、１０６（ｎ）が、ネットワーク１０４に結合される。ビデオプロバイダ１０２は、マルチキャスト方式を利用してネットワーク１０４を通じて複数のチャネルのビデオをクライアント１０６に提供することができる。同様に、クライアント１０６は、ネットワーク１０４を通じ、マルチキャスト方式を介して、ビデオプロバイダ１０２から複数のチャネルについてのビデオを受信することができる。本発明で使用されるビデオは、任意で、オーディオ、および／またはそれに関連付けられたオーディオおよび／またはビデオの提示制御情報を含むことができる。

ここに記載された一実施例では、ビデオプロバイダ１０２は、所与の特定のチャネルについての図のビデオストリーム１１０で表される複数のチャネルのビデオ情報を受信、格納、および／またはその他の形でアクセスする。各ビデオストリーム１１０は、独立（independent）フレーム１１０（Ｉ）、および依存（dependent）フレーム１１０（Ｄ）からなる。独立フレーム１００（Ｉ）は、他のビデオフレームを参照せずに復号することができる。独立フレーム１１０（Ｉ）には、例えばイントラ（intra）（Ｉ）フレームがある。対照的に、依存フレーム１１０（Ｄ）は、１つまたは複数の他のビデオフレームを参照して復号される。依存フレーム１１０（Ｄ）には、例えば、予測（predicted）（Ｐ）フレームおよび双方向（bidirectional）（Ｂ）フレームがある。この結果、独立フレーム１１０（Ｉ）は、後続のフレームを待たずに復号することができるので、独立フレーム１１０（Ｉ）は、少なくともリアルタイムで受信されるビデオストリーム１１０については、依存フレーム１１０（Ｄ）より迅速に、かつ／またはより早く復号することができる。

一般に、ビデオストリーム１１０は、マルチキャスト方式を使用して、ビデオプロバイダ１０２からネットワーク１０４を通じて、選択されたクライアント１０６に配信される。例えば、ビデオプロバイダ１０２がマルチキャストソースに対応することができ、ネットワーク１０４は複数のマルチキャスト複製ポイントを含むことができ、クライアント１０６は、複数のマルチキャスト受信者に対応することができる。さらに、マルチキャストのビデオ配信方式では、特定のビデオチャネルの各ビデオストリーム１１０は、マルチキャストストリームに対応することができる。

実際の動作では、特定のビデオチャネルの受信を要求する所与のクライアント１０６の各々が、その特定のビデオチャネルに対応するマルチキャストグループに加えられる。その後、ネットワーク１０４は、所与のクライアント１０６が加えられたマルチキャストグループに対応する特定のビデオチャネルについての関連付けられたビデオストリーム１１０の複製を転送する。ネットワーク１０４は、ビデオストリーム１１０の複製を、１つまたは複数の複製ポイント（図１には個別には図示せず）を介して、選択されたクライアント１０６に転送する。

所与のクライアント１０６（例えばクライアント１０６（１））がチャネルを変更したいとき、クライアント１０６（１）は、ビデオ配信ヘッドエンドまたは同様のサーバまたはシステムにチャネル変更要求（ＣＣＲ）１１２を送信する。チャネル変更要求１１２は、クライアント１０６（１）の識別子に加えて、要求されるビデオチャネルの指示を含む。図示するように、ビデオプロバイダ１０２とチャネル変更サーバ１０８は、個別にまたは共同でビデオ配信ヘッドエンドを備える。チャネル変更要求１１２は、要求されるビデオチャネルに対応するマルチキャストグループに対するマルチキャストグループの変更を誘発する。

マルチキャストグループを変更すると、ビデオストリーム１１０を要求元のクライアント１０６（１）に誘導することができる。しかし、クライアント１０６（１）が、独立して復号することができない依存フレーム１１０（Ｄ）の期間中にビデオストリーム１１０の受信を開始した場合、クライアント１０６（１）のユーザは、長いチャネル変更待ち時間を経験する可能性がある。クライアント１０６（１）は、次の独立フレーム１１０（Ｉ）がクライアント１０６（１）によって受信されるまで、ビデオの復号を待つ。

記載された一実施例では、チャネル変更サーバ１０８は、チャネル変更要求１１２に応答してこのチャネル変更の待ち時間を改善する。詳細には、チャネル変更サーバ１０８は、要求されるビデオチャネルの独立フレーム１１０（Ｉ）をクライアント１０６（１）にユニキャストするように適合される。より詳細には、チャネル変更サーバ１０８は、要求されるビデオチャネルに関連付けられたビデオストリーム１１０の保持された独立フレーム１１０（Ｉ）を、ユニキャスト通信でクライアント１０６（１）に送信するように適合される。そして、この保持された独立フレーム１１０（Ｉ）は、他のフレーム１１０（ＩまたはＤ）と無関係に、かつ次の独立フレーム１１０（Ｉ）を待つ必要なく、比較的迅速に復号（および表示）することができる。

チャネル変更サーバ１０８は、保持された独立フレームをユニキャストする際に、３つの例示的モードの１つまたは複数で動作することができる。第１のモードでは、保持された独立フレームは、キャッシュされた先行する独立フレームからなる。この第１のモードについては、図２を参照して下記でさらに説明する。第２のモードでは、保持された独立フレームは、キャッシュされた（あるいは可能性としてはバッファリングされた）先行する独立フレームからなる。この第２のモードについては、図３Ａを参照して下記でさらに説明する。第３のモードでは、保持された独立フレームはバッファリングされた独立フレームからなる。この第３のモードについては、図３Ｂを参照して下記でさらに説明する。第２および第３のモードは、関連するマルチキャストグループへの同期したクライアントの加入を伴うことも可能な実施例である。

図２に、ユニキャストメッセージ２０８でイントラフレームを提供することができる例示的なチャネル変更サーバ１０８を含むビデオ配信アーキテクチャ２００を示す。（図１の）ビデオ配信アーキテクチャ１００に対して、ビデオプロバイダ１０２、チャネル変更サーバ１０８、およびクライアント１０６（１、２、．．．、ｎ）は、同じくネットワーク１０４に接続されている。しかし、ネットワーク１０４に関する追加的な詳細を図示している。

図示するように、ネットワーク１０４は、少なくとも１つの複製ポイント２０２を含む。ネットワーク１０４は通常、そのような複製ポイント２０２を多数含む。実際、複数の複製ポイント２０２は、通例、マルチキャストソース（例えばビデオプロバイダ１０２および／またはチャネル変更サーバ１０８）と、マルチキャスト受信者（例えばクライアント１０６のうち任意のクライアント）との間に位置する。すなわち、図には１つのみの複製ポイント２０２を明示的に示すが、ビデオストリーム１１０は、ビデオプロバイダ１０２とクライアント１０６との間にある複数の複製ポイント２０２によって通信（例えば転送および／または複製する）ことができる。

記載された一実施例では、複製ポイント２０２は、多くの異なるタイプのネットワーク要素またはノードのいずれかとして実現される。複製ポイント２０２は、例えば、ルータ、スイッチなどである。マルチキャスト対応ノードとして、複製ポイント２０２は、グループのメンバーシップを容易にする、マルチキャスト通信を複製／転送する、ソースおよびグループアドレス（Ｓ、Ｇ）によって識別されるマルチキャストストリームを処理する、他のマルチキャストに関連する機能、その何らかの組合せまたはサブセットを行うよう等に適応される。例えば、複製ポイント２０２は、マルチキャストルーティングプロトコル（例えばプロトコル非依存マルチキャストスパースモード（ＰＩＭ−ＳＭ））、グループ管理プロトコル（例えばインターネットグループ管理プロトコル（ＩＧＭＰ））等に従って通信を実施することができる。

ＩＧＭＰは、条件およびグループメンバーシップの変更について互いに通知するために、受信者ホスト（例えば少なくともクライアント１０６）および複製ポイント２０２によって使用される。ＰＩＭ−ＳＭは、複製ポイント２０２間で転送状態情報を伝搬するために使用される。ＩＧＭＰは、クライアント１０６をあるグループに加えるため、およびクライアント１０６がグループから離脱することを複製ポイント２０２に通知するために使用されるメッセージを定義する。主としてＩＧＭＰとの関連で実施例を説明するが、代わりに他のマルチキャストプロトコルも用いることができる。

ビデオストリーム１１０は、Ｉ、Ｐ、およびＢフレームからなる例示的ストリームとして図示する。ビデオストリーム１１０は、ＭＰＥＧ−４（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔ Ｇｒｏｕｐ ４：ＩＳＯ／ＩＥＣ １４４９６−１／２／３）標準などの任意のビデオ圧縮アルゴリズムまたは技術を使用して符号化することができる。図２に示すビデオフレームの連続は、「ＩＢＢＰＢＢＰＢＢＰＢＢＩ」であるが、任意のビデオフレームの連続が存在することが可能である。実際には、ビデオストリーム１１０のフレームの連続は、未知の情勢（fashion）および／または予測不能な情勢で常に変化している可能性がある。

チャネル変更サーバ１０８は、１つまたは複数のプロセッサ２０６および少なくとも１つのメモリ２０４を含む。メモリ２０４は、プロセッサ２０６によって実行されるプロセッサ実行可能命令を含み、下記でさらに述べる機能を実行することができる。これらのプロセッサ実行可能命令は、ハードウェア、ファームウェア、ソフトウェア、それらのいずれかの組合せなどからなることができる。メモリ２０４の一部として記憶されるプロセッサ実行可能命令を有するモジュールには、Ｉフレームキャッシャ（ｃａｃｈｅｒ）２１４、キャッシュされたＩフレーム２１６、チャネル変更要求ディテクタ２１８、およびチャネル変更要求ハンドラ２２０が含まれる。これらのモジュールについては、さらに下記で説明する。

ビデオストリーム１１０を参照して上記で大まかに述べたように、Ｉフレームは独立して復号することができるが、ＰおよびＢフレームは通常は独立して復号することができない。Ｐフレームは、１つまでの他のフレームを参照し、Ｂフレームは、２つまでの他のフレームを参照する。特定のクライアント１０６が、異なるビデオチャネルに対応する新しいマルチキャストグループに加わる際、当該特定のクライアント１０６は、Ｉフレームが受信されるまで、ビデオストリーム１１０の復号（あるいはユーザに対するビデオの表示）を開始することができない。ＭＰＥＧ−４のビデオ符号化パラダイムでは、通常のストリームフローにおけるチャネル変更要求１１２からＩフレームの受信までの平均遅延は、１〜２秒間である。この遅延は、次世代の符号化パラダイムでは５〜１０秒間に延びる可能性がある。チャネル変更サーバ１０８は、この平均遅延を短縮し、それにより、長いチャネル変更遅延から生じるユーザのフラストレーションを緩和することができる。

記載された一実施例では、クライアント１０６（１）は、初めに、ビデオチャネルの変更が（例えばユーザ入力の結果として）求められる、かつ／または要求されていることを判定する。クライアント１０６（１）は、要求されるチャネルを指示し、（恐らくは暗示的に）クライアント１０６（１）を識別するチャネル変更要求１１２を作成する。チャネル変更要求１１２は、１つまたは複数の複製ポイント２０２を通じてアップストリームに（例えばユニキャストメッセージとして）送信される。

チャネル変更要求ディテクタ２１８はチャネル変更サーバ１０８を構成し、チャネル変更要求１１２についてネットワーク１０４を監視する。クライアント１０６（１）からのチャネル変更要求１１２が検出されると、チャネル変更要求ハンドラ２２０が起動されてその要求に応答する。詳細には、チャネル変更要求ハンドラ２２０は、要求されるチャネルの先行するＩフレームをユニキャストメッセージとしてクライアント１０６（１）に送信することにより応答する。

要求されるチャネルの先行するＩフレームをクライアント１０６に送信できるように、チャネル変更サーバ１０８は、そのような先行するＩフレームを少なくとも一時的に保持することにより、そのような先行Ｉフレームへのアクセスを確保する。詳細には、Ｉフレームキャッシャ２１４が、各ビデオチャネルに関連付けられた各ビデオストリーム１１０を追跡し、少なくとも各ビデオストリーム１１０の一番新しいＩフレームを格納する。この最も新しい先行Ｉフレームは、キャッシュされたＩフレーム２１６として格納される。

図２に示すように、チャネル変更要求１１２の活動化時間が、ビデオストリーム１１０に沿ってＣＣＲの時間２１２として示される。このＣＣＲの時間２１２は、２つのＩフレームの間にあたる。したがって、このモードではキャッシュされたＩフレーム、すなわち先行するＩフレームからなる保持されたフレーム２１０は、すでにＩフレームキャッシャ２１４によりキャッシュされたＩフレーム２１６に記憶されている。チャネル変更要求ハンドラ２２０は、キャッシュされたＩフレーム２１６から保持されたＩフレーム２１０を抽出する。チャネル変更要求ハンドラ２２０は、保持されたＩフレーム２１０を含むユニキャストメッセージ（ＵＭ）も作成し、そのメッセージを、保持ＩフレームＵＭ２０８としてクライアント１０６（１）に送信する。

クライアント１０６（１）は、保持ＩフレームＵＭ２０８を受信し、要求されるチャネルに関連付けられたビデオストリーム１１０の次のＩフレームを待つ間に、保持されたＩフレーム２１０を復号し、表示することができる。保持されたＩフレームＵＭ２０８がより早くクライアント１０６（１）によって受信されるほど、ユーザがチャネル変更要求を要求してから、完全な（最初は静的な）ビデオフレームが表示されるまでの遅延が短くなり、また、保持ＩフレームＵＭ２０８としての保持Ｉフレーム２１０の送信が、現在の、そして恐らくはより関連性の高い（例えばより新しい）ビデオストリーム１１０のフレームの受信を阻害する可能性が低くなる。したがって、少なくともクライアント１０６（１）とそのクライアントに最も近い複製ポイント２０２との間の送信帯域幅が問題となる可能性がある。この送信帯域幅問題の対処について、以下で図３Ａおよび３Ｂを参照して説明する。

図３Ａに、ｊｏｉｎコマンドを使用したクライアント１０６（１）のマルチキャストグループへの加入を同期することが可能な例示的チャネル変更サーバ１０８を含むビデオ配信アーキテクチャ３００Ａを示す。（図２の）ビデオ配信アーキテクチャ２００に対して、ビデオプロバイダ１０２、チャネル変更サーバ１０８、およびクライアント１０６（１、２、．．．、ｎ）は、同じくネットワーク１０４に接続されている。しかし、ビデオプロバイダ１０２は、チャネル変更サーバ１０８を介してビデオストリーム１１０を提供する。図では別個に示しているが、（例えば図１〜３Ｂの）ビデオプロバイダ１０２とチャネル変更サーバ１０８は、同じ場所に配置しても、かつ／または１つのサーバまたはシステムとして組み合わせてもよい。

記載された一実施例では、チャネル変更サーバ１０８は、ビデオストリーム１１０をマルチキャストストリーミングで配信する前に、ビデオストリーム１１０をバッファリングして時間的に遅らせるように適合される。チャネル変更サーバ１０８は、次のＩフレームの発生を「予測」することにより、新しいチャネルへの加入を、その新しいチャネルに関連付けられたビデオストリーム１１０の新しいＩフレームの直前に同期することができる。この擬似予測は、ビデオストリーム１１０のバッファリングされた部分の時間遅延の状況（aspect）を使用して達成される。

図示するように、チャネル変更サーバ１０８は、プロセッサ実行可能命令を有するメモリ２０４を含み、プロセッサ２０６によって実行されて下記でさらに述べる機能を行うことができる。メモリ２０４の一部として記憶されるプロセッサ実行可能命令を有するモジュールには、ビデオストリームバッファラ３０４、バッファリングされたビデオストリーム３０６、ｊｏｉｎコマンドイシュア３０８、および同期ディターミナ３１０が含まれる。モジュール３０４、３０６、３０８、および３１０の機能は、（図２の）モジュール２１４、２１６、２１８、および２２０の機能と併せて実施しても、それらの機能とは別個に実施してもよい。

チャネル変更サーバ１０８は、ビデオプロバイダ１０２から（各ビデオチャネルの）ビデオストリーム１１０を受け付ける。ビデオストリームバッファラ３０４は、受信ポイント（ＲＰ）から送信ポイント（ＳＰ）までのビデオストリーム１１０のバッファ部分３１２（Ｔ）を作成する。現在バッファリングされている各バッファ部分３１２は、バッファリングされたビデオストリーム３０６として記憶される。バッファ部分３１２（Ｔ）は、現在の時間「Ｔ」に対応する。受信ポイントは、チャネル変更サーバ１０８が現在ビデオプロバイダ１０２から受信しているビデオストリーム１１０の時点（point）に対応する。送信ポイントは、チャネル変更サーバ１０８が現在クライアント１０６に送信しているビデオストリーム１１０の時点に対応する。

記載された一実施例では、クライアント１０６（１）は、可能性としてはアップストリーム経路に応じて１つまたは複数の複製ポイント２０２を通じて、アップストリームのチャネル変更要求１１２を（例えばユニキャストメッセージとして）送信する。ＣＣＲの活動化時間（activation time）２１２は、ビデオストリーム１１０およびバッファリングされた部分３１２（Ｔ）を基準として示される。保持Ｉフレーム２１０は、チャネル変更要求ハンドラ２２０（図２を参照して上記で説明）により、保持ＩフレームＵＭ２０８として送信することができる。このモードでは、保持Ｉフレーム２１０は、キャッシュまたはバッファリングされたＩフレームからなる。保持されたＩフレーム２１０がバッファ部分３１２（Ｔ）中に現れる場合は、送信ポイントＳＰで送信されるまでＩフレームがキャッシュされないのであれば、可能性としてはキャッシュＩフレーム２１６の一部としてキャッシュされる前であっても、バッファリングされたビデオストリーム３０６から保持されたＩフレームを直接取り出すことができる。

トゥルーモーションビデオの完全な復号は、次のＩフレームが受信されるまで開始しないので、次のＩフレームまでの間にあるＰフレームおよび／またはＢフレームの送信は、不必要な帯域幅使用と考えることができる。そのような帯域幅の浪費を回避し、保持ＩフレームＵＭ２０８がクライアント１０６（１）によって受信される際の可能な速度を高めるために、同期ディターミナ３１０は、次の復号可能なフレームを受信するのにちょうど間に合うように、要求されるチャネルに対応するマルチキャストグループにクライアント１０６（１）を加えることができる。これは、例えば、次のＩフレームの前の数パケットを送信した場合の「余分な帯域幅」利用量から、複数フレームを送信した場合の「余分な帯域幅」の間の量になる可能性がある。このモードでは、次の復号可能なフレームは、別のＩフレームである。

詳細には、同期ディターミナ３１０は、次のＩフレームが、ビデオストリーム１１０の現在のバッファ部分３１２中にあるかどうかを確かめる。ＣＣＲの時間２１２には、次の復号可能なフレーム３１４は、バッファ部分３１２（Ｔ）にない。しかし、「Ｘ」単位の時間の後、次の復号可能なフレーム３１４は、バッファリングされた部分３１２（Ｔ＋Ｘ）にある。次の復号可能フレーム３１４が現在のバッファ部分３１２中にあることを確認すると、同期ディターミナ３１０は、ｊｏｉｎコマンドを発行する時であると判断し、したがってｊｏｉｎコマンドイシュア３０８を起動または促す。

ｊｏｉｎコマンドイシュア３０８は、起動されると、ネットワーク１０４（図を見やすくするために図３Ａには明示的には図示せず）を通じてｊｏｉｎコマンドを発行する。このｊｏｉｎコマンドにより、ｊｏｉｎメッセージ３０２が複製ポイント２０２で受信される。ｊｏｉｎメッセージ３０２は、そのマルチキャストストリームについてのマルチキャストグループにクライアント１０６（１）を加えることにより、クライアント１０６（１）が、要求されるチャネルに対応するマルチキャストストリームの受信を開始しようとしていることを複製ポイント２０２に通知する。このｊｏｉｎメッセージ３０２は、クライアント１０６（１）から、またはチャネル変更サーバ１０８のｊｏｉｎコマンドイシュア３０８から送信することができる。前者については図４Ａを参照して下記でさらに説明し、後者については図４Ｂを参照して下記でさらに説明する。後者の実施例では、ｊｏｉｎコマンドイシュア３０８によって発行されるｊｏｉｎコマンドは、ｊｏｉｎメッセージ３０２からなることができる。

記載された一実施例では、バッファ部分３１２のサイズは、クライアント１０６をあるマルチキャストチャネルのマルチキャストグループに加える際に費やされる予測される時間（既知の時間を含む）に関連する。この時間は、グループからの離脱動作を実行するためにかかる時間を含むことができる。例として、バッファ部分３１２は、関連するクライアント１０６について加入動作を実行する際の最悪の事例（例えば絶対的な、あるいは妥当な最悪の事例）に対応することができる。あるいは、バッファ部分３１２のサイズは、マルチキャストの加入動作を実行する平均時間に対応してもよく、ネットワーク１０４の条件が空間的または時間的に変化する場合は、個々のクライアント１０６または指示されたクライアント１０６のセットについて調整することもできる。

図３Ｂに、ｊｏｉｎコマンドを使用したクライアント１０６（１）のマルチキャストグループへの加入を同期することができ、より円滑な最初のビデオ提示エクスペリエンスを提供することが可能な例示的チャネル変更サーバ１０８を含むビデオ配信アーキテクチャ３００Ｂを示す。ビデオ配信アーキテクチャ３００Ａは、クライアント１０６のユーザによって体験されるビデオの断絶あるいは不連続性を生じさせる可能性がある。このビデオの断絶／不連続性は、間にある複数の表示されない非Ｉフレームを有する、２つの連続しないＩフレームが連続的に表示される結果生じる。ビデオ配信アーキテクチャ３００Ｂは、下記の要領でビデオ提示を円滑にすることにより、このビデオの断絶／不連続性を緩和する。

図を見やすくするために、図３Ｂにはビデオストリームバッファラ３０４、ｊｏｉｎコマンドイシュア３０８、および同期ディターミナ３１０は図示していない。しかし、図２および３Ａより長いビデオストリーム１１０のセグメントを図示している。バッファ部分３１２（Ｔ^＊）は、（図３Ａ）のバッファ部分３１２（Ｔ）より長い。バッファ部分３１２（Ｔ^＊）は、下記のように加入時間３１６とＩフレームの間隔時間３１８を含む。

この第３のモードの記載された実施例では、チャネル変更サーバ１０８は、ビデオストリーム１１０をマルチキャストストリーミング配信する前に、少なくとも、Ｉフレーム間の最大の距離と、クライアント１０６（１）が要求されるチャネルに対応するグループに加入された状態になるのにかかる最大の加入時間とを合計した時間だけ、ビデオストリーム１１０をバッファリングして時間的に遅らせるように適合される。チャネル変更サーバ１０８は、Ｉフレームの発生を「予測」することにより、新しいチャネルへの加入を、当該新しいチャネルに関連付けられたビデオストリーム１１０の新しいＩフレームの直後に同期することができる。この擬似同期は、ビデオストリーム１１０のバッファ部分３１２（Ｔ^＊）の時間遅延の状況（例えば遅延ウィンドウ）を使用して達成される。

チャネル変更サーバ１０８は、バッファ部分３１２（Ｔ^＊）中にＩフレームを保持するように適合される。保持されたＩフレームは、Ｉフレームキャッシャ２１４により、キャッシュされたＩフレーム２１６として、または、バッファリングされたウィンドウ中のＩフレームへの記録されたポインタ／索引として保持することができる。あるいは、保持されたＩフレームは、Ｉフレームキャッシャ２１４を使用せずにバッファ部分３１２（Ｔ^＊）に保持することもできる。このモードについての記載された一実施例では、保持されたＩフレーム２１０は、バッファリングされたＩフレームである。

クライアント１０６（１）がＣＣＲ１１２を介してチャネルの変更を要求すると、チャネル変更サーバ１０８は、保持されたＩフレームＵＭ２０８を受信し、最も古い保持Ｉフレーム２１０のすぐ後のフレームを受信するのに間に合うようにマルチキャストグループに加わるための時間がまだあるクライアント１０６（１）に対し、バッファ部分３１２（Ｔ^＊）の遅延ウィンドウ中で最も古い保持Ｉフレーム２１０を提供する。このようにして、クライアント１０６（１）は、連続したフレームのセットを受信し、最初のフレームは、保持ＩフレームＵＭ２０８を介して到着する保持されたＩフレーム２１０であり、（最初の）次のフレームは、マルチキャストグループを介して到着する非Ｉフレームとなる。保持されたＩフレーム２１０は「早めに」送信されるので、クライアント１０６（１）は保持されたＩフレーム２１０で一時停止し、クライアント１０６（１）は次いで、遅延させたマルチキャストストリームから得られる１つ後のフレームを再生する時間になると、フルモーションビデオを開始する。

加入時間３１６は、上記で図３Ａを参照して説明したように、クライアント１０６をマルチキャストグループに加入する際に費やされる時間に相当する。Ｉフレーム間隔時間３１８は、所与の符号化方式で、連続したＩフレーム間の可能な最大の時間に相当する。図示するように、最初のＣＣＲの時間２１２’は、加入時間３１６がちょうど開始する時に到着している。したがって、この第３のモードの実施例ではバッファリングされたＩフレームである最初の保持されたＩフレーム２１０’と、最初の次の復号可能なフレーム３１４’が、クライアント１０６が受信してビデオの復号を開始する最初の２フレームになる。２番目のＣＣＲの時間２１２”は、図では、保持Ｉフレーム２１０’についての加入時間３１６が終了した後、しかし保持Ｉフレーム２１０”についての加入時間３１６（明示的には図示せず）が終了する前に到着している。この結果、２番目の保持Ｉフレーム２１０”と、２番目の次に復号可能なフレーム３１４”が、２番目のＣＣＲの時間２１２”についてクライアント１０６が受信してビデオの復号を開始する最初の２フレームとなる。

図４Ａに、ｊｏｉｎコマンドを実施する第１の例示的機構３０８^＊Ａを示す。例示的機構３０８^＊Ａは、チャネル変更サーバ１０８および複製ポイント２０２のみならずクライアント１０６による関与（participation）を含む。詳細には、チャネル変更サーバ１０８は、複製ポイント２０２を介してクライアント１０６にｊｏｉｎ命令ＵＭ４０２を送信する。ｊｏｉｎ命令ＵＭ４０２は、チャネル変更サーバ１０８の（図３Ａおよび３Ｂの）同期ディターミナ３１０によって行われる判定に応答して、いつそのｊｏｉｎメッセージを送信すべきかをクライアント１０６に規定する。指定された規定時間に、クライアント１０６は、複製ポイント２０２にｊｏｉｎメッセージ３０２Ａを送信し、クライアント１０６は、次の復号可能なフレーム３１４を受信するのに間に合うように、そしてそのフレームより前の非Ｉフレーム（またはイントラフレーム）あるいはその他の理由で復号不可能なフレームを多量に受信することなく、要求されるチャネルに対応するマルチキャストグループに加えられる。

このマルチキャストストリームの加入の遅延により、（図２、３Ａ、および３Ｂの）保持されたＩフレーム２１０をユニキャストで配信するための帯域幅の利用可能性が促進される。複製ポイント２０２は、例えば、クライアント１０６に最も近く、所望のビデオストリーム１１０をマルチキャストすることが可能な複製ポイント２０２である。

加入動作がクライアント１０６から送信されるｊｏｉｎメッセージ３０２Ａによって誘発される範囲内では、例示的機構３０８^＊Ａは、より典型的なマルチキャスト加入手順に一致する。しかし、ｊｏｉｎメッセージを誘発させるには３つのネットワーク要素が関連し、また、それに付随して時間の制約（例えばバッファ部分３１２のサイズに反映される）の設定が最悪ケースについての分析ではより難しくかつ／またはより極端になるので、少なからぬロジスティクスが必要となる。加入手順は、クライアント１０６が関与する必要がなければ、より単純かつより確実にすることができる。

図４Ｂに、ｊｏｉｎコマンドを実施する第２の例示的機構３０８^＊Ｂを示す。例示的機構３０８^＊Ｂは、チャネル変更サーバ１０８および複製ポイント２０２の関与を必要とする。詳細には、チャネル変更サーバ１０８は、複製ポイント２０２にｊｏｉｎメッセージ３０２Ｂを送信する。ｊｏｉｎメッセージ３０２Ｂは、同期ディターミナ３１０によって行われる判定に応答して送信され、次の復号可能フレーム３１４を受信するための十分な余裕をもって加入動作を実行するリードタイムが、恐らくはより短い。ｊｏｉｎメッセージ３０２Ｂは、要求されるチャネルに対応するマルチキャストグループにクライアント１０６が加えられることを、複製ポイント２０２に通知する。例示的機構３０８^＊Ｂは、送信者／ソースホストなどの非受信者のホストが、受信者ホストに代わって加入動作を誘発できるようにすることを伴う。

図５は、マルチキャストとユニキャストを組み合わせたネットワークを用いて高速のチャネル変更を行う例示的方法を示す流れ図５００である。流れ図５００は、１３個のブロック５０２〜５２６を含む。流れ図５００の動作は、他の環境で各種の例えばソフトウェア方式を用いて行うことができるが、特に図２、３Ａ〜３Ｂ、および４Ａ〜４Ｂを使用してこの方法の特定の態様および例を説明する。

例えば、ブロック５０２〜５２６の動作は、可能性としてはネットワーク１０４の１つまたは複数の複製ポイント２０２と共に、チャネル変更サーバ１０８およびクライアント１０６によって行うことができる。図示するように、チャネル変更サーバ１０８がブロック５０２〜５１６を行い、クライアント１０６がブロック５１８〜５２６の動作を行う。

ブロック５０２で、ビデオストリームが受け付けられる。例えば、チャネル変更サーバ１０８が、関連付けられたビデオプロバイダ１０２から１つまたは複数のビデオストリーム１１０を受け付けることができる。ブロック５０４で、受け付けたビデオストリームの一部がバッファリングされる。例えば、ビデオストリームバッファラ３０４が、各チャネルに関連付けられた各ビデオストリーム１１０を遅延させて、各ビデオストリーム１１０のバッファ部分３１２を作成することができる。バッファ部分３１２は、受信ポイント（ＲＰ）で入り、送信ポイント（ＳＰ）に向かって「移動」するフレームを有するバッファリングビデオストリーム３０６のセットとして記憶することができる。

ブロック５０６で、少なくとも１つのＩフレームが保持される。例えば、チャネル変更サーバ１０８のＩフレームキャッシャ２１４が、各チャネルに関連付けられた各ビデオストリーム１１０の保持されたフレーム（保持されたＩフレーム２１０）を、キャッシュされたＩフレーム２１６のセット、またはバッファ部分３１２（Ｔ^＊）中のフレームへの索引／ポインタのセットとして保持することができる。あるいは、バッファ部分３１２（Ｔ^＊）の知られた場所または特定可能な場所にバッファリングすることにより、Ｉフレームを保持してもよい。点５２８から分岐する点線の矢印で表すように、ブロック５０２〜５０６の動作は、チャネル変更サーバ１０８について持続的に行われる。

ブロック５１８で、マルチキャスト通信を介してビデオが受信される。例えば、クライアント１０６が、ネットワーク１０４の１つまたは複数の複製ポイント２０２を通じて、ビデオプロバイダ１０２および／またはチャネル変更サーバ１０８から、マルチキャストストリームとしてビデオストリーム１１０を受信することができる。ブロック５２０で、チャネル変更要求がユニキャストメッセージとして送信される。例えば、クライアント１０６は、チャネル変更サーバ１０８にユニキャストメッセージとしてチャネル変更要求１１２を送信することができる。このチャネル変更要求１１２は、実際には、第１のビデオチャネルに対応する第１のマルチキャストグループから、第２のビデオチャネルに対応する第２のマルチキャストグループに切り替える要求であり、要求される第２のビデオチャネルがチャネル変更要求１１２によって指示される。

ブロック５０８で、チャネル変更要求が検出される。例えば、チャネル変更サーバ１０８のチャネル変更要求ディテクタ２１８がチャネル変更要求１１２を検出することができる。ビデオ配信アーキテクチャ２００が実施される場合、チャネル変更サーバ１０８は、チャネル変更要求１１２について、ビデオプロバイダ１０２の周辺の（vicinity）ネットワーク１０４へのリンクおよび／またはネットワーク１０４とのインターフェースを監視することができ、あるいは、ビデオプロバイダ１０２がチャネル変更要求１１２を転送する場合もある（またはチャネル変更サーバ１０８がチャネル変更要求１１２の意図された受信者である場合もある）。ビデオ配信アーキテクチャ３００Ａまたは３００Ｂが実施される場合は、チャネル変更サーバ１０８が、チャネル変更要求１１２の意図される受信者となることが可能等である。

ブロック５１０で、要求されるチャネルの保持されたＩフレームが取り出される。例えば、チャネル変更要求ハンドラ２２０は、キャッシュされたＩフレーム２１６および／またはビデオストリーム３０６のバッファ部分３１２（Ｔ^＊）にアクセスして、要求されるチャネルに関連付けられたビデオストリーム１１０の保持Ｉフレーム（２１０’および２１０”を含む保持されたＩフレーム２１０）を取り出す。ブロック５１２で、要求されるチャネルの保持されたＩフレームが、ユニキャストメッセージとして送信される。例えば、チャネル変更要求ハンドラ２２０は、適切な作成を行うと、保持されたＩフレームＵＭ２０８をクライアント１０６に送信する。

ブロック５２２で、要求されたチャネルの保持Ｉフレームがユニキャストメッセージとして受信される。例えば、クライアント１０６は、通常は標準的なビデオチャネルの受信の際にマルチキャストストリームであるビデオストリーム１１０を受信していても、ユニキャスト通信の一例である保持ＩフレームＵＭ２０８を受信することができる。ブロック５２４で、要求されたチャネルの保持Ｉフレームが表示される。例えば、クライアント１０６は、要求したチャネルの保持されたＩフレームを保持ＩフレームＵＭ２０８から抽出し、保持されたＩフレームを表示させる。次の復号可能フレーム３１４（３１４’および３１４”を含む）が到着する予定までの時間によるが、この静的なＩフレームの提示は、かなりの時間にわたり継続することができる（例えば典型的なＭＰＥＧ−４ビデオ符号化の実施では最高１〜２秒間）。

ブロック５１４で、要求されるチャネルに対応するマルチキャストグループへのクライアントの加入を、次の復号可能フレームについて同期する。例えば、ビデオ配信アーキテクチャ３００Ａおよび３００Ｂの場合、チャネル変更サーバ１０８の同期ディターミナ３１０は、次の復号可能フレーム３１４がいつクライアント１０６に送信される予定であるか（および、それにより、最悪ケースのシナリオで次の復号可能フレーム３１４がいつクライアント１０６によって受信される可能性が高いか、または受信されるか）を確定することができる。この次の復号可能フレーム３１４の確定は、要求されるチャネルに関連付けられたビデオストリーム１１０のバッファ部分３１２（バッファ部分３１２（Ｔ^＊）およびその加入時間３１６を含む）を参照して行うことができる。次の復号可能フレーム３１４のタイミングが確定されると、同期ディターミナ３１０は、要求されるチャネルに対応するマルチキャストグループにマルチキャストでクライアント１０６を加える動作の適切なタイミングを判断する。

ブロック５１６で、要求元のクライアントについてのｊｏｉｎコマンドが発行される。例えば、ｊｏｉｎコマンドイシュア３０８が、同期ディターミナ３１０による同期の判断に応答して、クライアント１０６についてｊｏｉｎコマンドを発行することができる。ｊｏｉｎコマンドは、指定された時間に複製ポイント２０２にｊｏｉｎメッセージ３０２Ａを送信するようにクライアント１０６を促すためにクライアント１０６に送信されるｊｏｉｎ命令ユニキャストメッセージ４０２からなることができる（例えばｊｏｉｎコマンドを実施する例示的機構３０８^＊Ａ）。あるいは、ｊｏｉｎコマンドは、クライアント１０６に代わって複製ポイント２０２に「直接」送信されるｊｏｉｎメッセージ３０２Ｂからなることもできる（例えばｊｏｉｎコマンドを実施する例示的機構３０８^＊Ｂ）。

ブロック５２６で、要求されるチャネルのビデオが、マルチキャスト通信を介して受信される。例えば、クライアント１０６は、マルチキャスト複製ポイント２０２を使用してネットワーク１０４を通じて、対応するマルチキャストストリーミンググループを介して、要求されるチャネルに関連付けられたビデオストリーム１１０を受信することができる。すなわち、ｊｏｉｎメッセージ３０２に応答して複製ポイント２０２が対応するマルチキャストストリーミンググループにクライアント１０６を加えた後に、少なくともその１つの複製ポイント２０２が（必要に応じて）ビデオストリーム１１０を複製し、クライアント１０６に転送する。

ブロック５１２および５１６の動作は、詳細には、無数の順序で行うことができる。例えば、ブロック５１６の発行は、ブロック５１２の送信の後に行ってもよく、あるいは、ブロック５１６および５１２の発行および送信は、実質的に同時に、あるいは少なくとも両方の順序を考慮せずに行ってもよい。あるいは、ブロック５１６の発行は、ｊｏｉｎコマンドを発行するのを待つことで、チャネルを変更するクライアントが次のＩフレームを受信する能力が損なわれるほど次のＩフレームが時間的に近接していなければ（所定の閾値時間よりも近くなければ）、ブロック５１２の送信の後に行ってもよい。

図１〜５の動作、態様、機能、コンポーネントなどは、複数のブロックに分割した図に示している。ただし、図１〜５を記載および／または図示した順序、相互のつながり、レイアウトなどは、限定とは解釈すべきでなく、任意の方式で任意数のブロックを組み合わせる、順序を変更する、増やす、省略するなどして、高速のチャネル変更のための１つまたは複数のシステム、方法、デバイス、手順、メディア、装置、サーバ、構成などを実施することができる。さらに、本明細書の説明は、具体的な実施例の参照を含むが、図示および／または記載された実施例は、任意の適切なハードウェア、ソフトウェア、ファームウェア、あるいはそれらの組合せとして、また適切なビデオ配信アーキテクチャ、ネットワーク要素および編成、ビデオ符号化標準、マルチキャストおよびユニキャスト方式などを使用して実施することができる。

特に図２および３Ａ〜３Ｂを参照すると、ビデオプロバイダ１０２および／またはサーバ１０８は、各種のプロセッサからアクセス可能な媒体を含むことができる。そのような媒体は、コンピューティングデバイスまたは他の（例えば電子）デバイスによるアクセスが可能な任意の利用可能媒体でよい。そのような媒体には、揮発性および不揮発性媒体、取り外し可能および取り外し不能媒体、および記憶媒体（例えばメモリ２０４）および伝送媒体（例えばネットワーク１０４のリンクまたはノード）が含まれる。この媒体は、プロセッサ実行可能命令を含むことができる。

高速チャネル変更の実施例は、プロセッサ実行可能命令に概ね即して説明することができる。一般に、プロセッサ実行可能命令には、特定のタスクを行うか、かつ／または可能にする、および／または特定の抽象データ型を実装するルーチン、プログラム、プロトコル、オブジェクト、インターフェース、コンポーネント、データ構造などが含まれる。本明細書の特定の実施例に記載された高速チャネル変更は、通信リンクおよび／またはネットワークを通じて接続された、遠隔リンクされた処理デバイスによってタスクが行われる分散処理環境で実施することもできる。分散コンピューティング環境に限ったことではないが、特に分散コンピューティング環境では、プロセッサ実行可能命令は、異なるプロセッサによって実行される複数の別個の記憶媒体に配置する、かつ／または伝送媒体を通じて伝搬することができる。

システム、媒体、デバイス、方法、手順、装置、技術、方式、手法、手順、構成、およびその他の実施について、構造的、論理的、アルゴリズム的、および機能的な特徴および／または図に固有の術語で説明したが、頭記の特許請求の範囲に定義される本発明は、ここに記載された特定の特徴および図に必ずしも限定されないことを理解されたい。これらの具体的な特徴および図は、特許権が請求される本発明を実施する例示的形態として開示される。

マルチキャスト通信およびユニキャスト通信の両方が可能なネットワークを含む例示的なビデオ配信アーキテクチャの図である。 ユニキャストメッセージとしてイントラフレームを提供することが可能な例示的チャネル変更サーバを含むビデオ配信アーキテクチャの図である。 ｊｏｉｎコマンドを使用したマルチキャストグループへのクライアントの加入を同期することが可能な例示的チャネル変更サーバを含むビデオ配信アーキテクチャの図である。 ｊｏｉｎコマンドを使用したマルチキャストグループへのクライアントの加入を同期することが可能であり、かつより円滑な最初のビデオ提示エクスペリエンスを提供することが可能な例示的チャネル変更サーバを含むビデオ配信アーキテクチャの図である。 ｊｏｉｎコマンドを実施する第１の例示的機構の図である。 ｊｏｉｎコマンドを実施する第２の例示的機構の図である。 マルチキャストとユニキャストを組み合わせたネットワークを用いた例示的な高速チャネル変更方法を説明する流れ図である。

符号の説明

１０２ ビデオプロバイダ
１０４ ネットワーク
１０６ クライアント
１０８ チャネル変更サーバ
２０２ 複製ポイント

Claims (55)

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. 前記同期ディターミナはさらに、前記同期ディターミナが、前記要求されるチャネルに関連付けられた前記ビデオストリームの前記時間遅延させたバッファ部分の加入時間に次のイントラフレームが近接していることを確定した時に、ｊｏｉｎコマンドを発行すべきであると判断するように構成されることを特徴とする請求項２９に記載のチャネル変更サーバ。
34. 前記同期ディターミナはさらに、前記要求されるチャネルに関連付けられた前記ビデオストリームの前記抽出された保持イントラフレームが前記ユニキャスト通信を使用して前記特定のクライアントに完全に配信されていなくとも、前記要求されるチャネルに関連付けられた前記ビデオストリームの時間遅延させたバッファ部分の加入時間に前記次の復号可能フレームが入っていることが確定されると、直ちにｊｏｉｎコマンドの発行を促すように適合されることを特徴とする請求項２９に記載のチャネル変更サーバ。
35. 複数のチャネルの個々のチャネルに関連付けられた複数のビデオストリームの各ビデオストリームについて少なくとも１つのイントラフレームを保持する保持手段と、
    要求されるチャネルを指示するクライアントからのチャネル変更要求を検出する手段であって、前記クライアントからのチャネル変更要求が、第１のマルチキャストグループから、前記要求されるチャネルに対応する第２のマルチキャストグループに切り替える要求を示す検出手段と、
    前記要求されるチャネルに関連付けられた個々のビデオストリームから前記保持手段によって保持される保持イントラフレームを、ユニキャスト通信を介して前記クライアントに送信することにより、前記チャネル変更要求を処理するハンドラ手段と
    を備えたことを特徴とするチャネル変更のための構成。
36. 前記複数のビデオストリームの各個々のビデオストリームをバッファリングして、各個々のビデオストリームの個々のバッファ部分を確立するバッファ手段と、
    前記第２のマルチキャストグループへの前記クライアントの加入を、（ｉ）前記要求されるチャネルに関連付けられた前記個々のビデオストリームの個々のバッファ部分を参照して、かつ（ｉｉ）前記要求されるチャネルに関連付けられた前記個々のビデオストリームの次の復号可能フレームに関して、同期する同期手段と
    をさらに備えることを特徴とする請求項３５に記載の構成。
37. 前記同期手段に応答してｊｏｉｎコマンドを発行する発行手段
    をさらに備えることを特徴とする請求項３６に記載の構成。
38. 前記保持手段は、
    （ｉ）前記複数のビデオストリームの各ビデオストリームについて前記少なくとも１つのイントラフレームをバッファリングするバッファリング手段、および（ｉｉ）前記複数のビデオストリームの各ビデオストリームについて少なくとも１つのイントラフレームをキャッシュするキャッシュ手段、の少なくとも１つを備えることを特徴とする請求項３５に記載の構成。
39. 前記構成は、少なくとも１つのサーバを備えることを特徴とする請求項３５に記載の構成。
40. 前記構成は、１つまたは複数のプロセッサアクセス可能媒体を備えることを特徴とする請求項３５に記載の構成。
41. マルチキャスト通信を使用して配信される複数のビデオチャネルの各ビデオチャネルについて少なくとも１つの独立フレームを保持するように構成され、かつ、要求されるビデオチャネルの前記保持された少なくとも１つの独立フレームを、ユニキャスト通信を使用して、要求元のクライアントに送信することにより、クライアントからのチャネル変更要求に応じるように適合されることを特徴とするサーバ。
42. 前記サーバは、前記複数のビデオチャネルを前記クライアントにマルチキャストすることが可能であることを特徴とする請求項４１に記載のサーバ。
43. 前記サーバは、前記要求元クライアントのマルチキャスト加入動作を、前記要求されるビデオチャネルの次の復号可能フレームに関して同期することが可能であることを特徴とする請求項４１に記載のサーバ。
44. 前記要求されるビデオチャネルの前記次の復号可能フレームは、次の独立フレームからなることを特徴とする請求項４３に記載のサーバ。
45. 前記要求されるビデオチャネルの前記次の復号可能フレームは、次の依存フレームからなることを特徴とする請求項４３に記載のサーバ。
46. 前記サーバは、前記要求元クライアントのマルチキャスト加入動作を、前記要求されるビデオチャネルの次の復号可能フレームに関して同期することができ、前記サーバはさらに、前記保持された少なくとも１つの独立フレームの送信が、前記要求されるビデオチャネルの前記次の復号可能フレームの適時の受信を損なう場合は、前記要求されるビデオチャネルの前記保持された少なくとも１つの独立フレームを前記要求元クライアントに送信することを控えるように適合されることを特徴とする請求項４１に記載のサーバ。
47. 前記サーバはさらに、前記要求されるビデオチャネルの前記保持された少なくとも１つの独立フレームが前記要求元クライアントに完全に配信されているか、不完全に配信されているかに関係なく、ｊｏｉｎコマンドを発行するように適合されることを特徴とする請求項４１に記載のサーバ。
48. 少なくとも１つのプロセッサと、
    前記少なくとも１つのプロセッサにより実行することが可能なプロセッサ実行可能命令を含む１つまたは複数の媒体と
    を備えるシステムであって、前記プロセッサ実行可能命令は、
    複数のチャネルをマルチキャストする動作と、
    前記複数のチャネルの各チャネルについて少なくとも１つのイントラフレームを保持する動作と、
    チャネル変更要求に応答して、要求されるチャネルの保持されたイントラフレームをユニキャスト通信として送信する動作と
    からなる動作を行うように前記システムに指示するように適合されることを特徴とするシステム。
49. 前記システムは、ビデオプロバイダおよびチャネル変更サーバを備えることを特徴とする請求項４８に記載のシステム。
50. 前記システムは、同一の場所に位置するビデオプロバイダとチャネル変更サーバを備えることを特徴とする請求項４８に記載のシステム。
51. 前記システムは、ビデオプロバイダから前記複数のチャネルを受信するチャネル変更サーバを備え、前記チャネル変更サーバは、前記複数のチャネルをマルチキャストする動作を行うことを特徴とする請求項４８に記載のシステム。
52. 前記プロセッサ実行可能命令は、
    前記要求されるチャネルに対応するマルチキャストグループへのマルチキャスト加入動作を、前記要求されるチャネルの次の復号可能フレームに関して同期する動作
    をさらに前記システムに行わせるように適合されることを特徴とする請求項４８に記載のシステム。
53. 前記プロセッサ実行可能命令は、
    前記要求されるチャネルに関連付けられたビデオストリームの一部分をバッファリングする動作
    をさらに前記システムに行わせるように適合され、
    前記同期の動作は、前記要求されるチャネルに関連付けられた前記ビデオストリームの前記バッファリングされたビデオストリーム部分中に前記次の復号可能フレームが存在する時にその事を判定する動作を備え、前記次の復号可能フレームは、次のイントラフレームからなることを特徴とする請求項５２に記載のシステム。
54. 前記プロセッサ実行可能命令は、
    前記要求されるチャネルに関連付けられたビデオストリームのビデオストリーム部分を、少なくともマルチキャスト加入時間とイントラフレームの間隔時間との合計に等しい長さにわたりバッファリングする動作
    をさらに前記システムに行わせるように適合され、
    前記同期の動作は、前記ビデオストリームの前記バッファリングされたビデオストリーム部分の前記マルチキャスト加入時間の部分に前記次の復号可能フレームが入ろうとする時にその事を判定する動作を備え、前記次の復号可能フレームは、次の非イントラフレームからなることを特徴とする請求項５２に記載のシステム。
55. 前記プロセッサ実行可能命令は、
    前記同期に応答してｊｏｉｎコマンドを発行する動作
    をさらに前記システムに行わせるように適合されることを特徴とする請求項５２に記載のシステム。

Images