JP2007536796A - メディアをストリーミングするための高速起動 - Google Patents

Abstract

メディアをストリーミングするための高速起動は、予測スタートの技術と、ストリーミング中に１つ以上の配信チャネルを切り換えるための技術の一方または両方を含む。予測スタートは、メディアコンテントソースが、要求側クライアント装置がどのメディアストリームを望むかを予測し、それら予測された１つ以上のメディアストリームのクライアント装置に対するストリーミングを開始することを可能にする。配信チャネル切り換え技術は、その１つ以上のメディアコンテントソースが、１つの配信チャネルを使用して（例えば、伝送制御プロトコル（ＴＣＰ）を使用して）その１つ以上のメディアストリームのストリーミングを開始し、次いで別の配信チャネル（例えば、ユーザデータグラムプロトコル（ＵＤＰ）を使用して）が機能するか否かをチェックし、それが機能する場合はその配信チャネルに切り換えることを可能にする。

Description

本発明は、メディアのストリーミングおよびデータ転送に関し、詳細には、メディアをストリーミングするための高速起動に関する。

オーディオ、ビデオ、および／またはテキストのストリーミングのようなコンテントのストリーミングは、益々人気が高まっている。「ストリーミング」という用語は、通常、メディアを表すデータが、再生以前にそのすべてが事前配信されるのではなく、随時ネットワークを介してクライアントコンピュータに提供されることを示すために使用される。したがって、クライアントコンピュータは、「ファイル」全体が配信されるのを待つのではなく、ストリーミングコンテントがネットワークサーバから受信される際に、そのストリーミングするコンテントを表現する。

マルチメディアコンテントのストリーミングの一般に普及した可用性は、インターネットまたは他のコンピュータネットワークを介して事前に入手可能でなかった様々な情報のコンテントを使用可能にする。生放送のコンテントは、そのようなコンテンツの重要な一例である。ストリーミングマルチメディアを使用すると、注目すべきイベントのオーディオ、ビデオ、またはオーディオ／ビジュアルによる放送を、そのイベントの開始と共にインターネットを介して放送することができる。同様に、テレビ局およびラジオ局は、インターネットを介してそれらの生放送のコンテントを送信することができる。

しかし現在のストリーミング技術には、いくつかの欠点がある。それらの欠点の１つは、通常、ストリーミングメディアの再生が要求された時点と、そのストリーミングメディアの再生が始まる時点の間に、幾分長い遅延があることである。通常、メディアコンテントの再生が行われるクライアント装置とそのメディアコンテントのソースの間では、様々な通信が必要となる。クライアント装置のユーザの立場からすると、このような遅延は、クライアント装置のユーザにとっての使い易さとストリーミング過程のユーザにとっての使い易さを低下させるものである。したがって、ユーザがストリーミングメディアの再生を要求した時点と、そのストリーミングメディアの再生が始まる時点の間の遅延を短縮することは有益である。

メディアをストリーミングするための高速起動を、本明細書で説明する。メディアをストリーミングするための高速起動は、予測スタートの技術と、ストリーミング中に１つ以上の配信チャネルを切り換えるための技術の一方または両方を含む。

ある態様によれば、予測スタートの技術は、サーバ装置に予測再生要求を送信するクライアント装置を含む。予測再生要求に応えて、サーバ装置は、クライアント装置が望む１つまたは複数のメディアストリームを予測し、予測された１つまたは複数のメディアストリームをクライアント装置にストリームする。クライアント装置は、クライアント装置にストリーミングするよう予測された１つまたは複数のメディアストリームと異なる少なくとも１つのメディアストリームを選択することができる。少なくとも１つのそのようなメディアストリームが選択された場合、選択された少なくとも１つのメディアストリームの指示がサーバ装置に送信され、サーバ装置は、選択された少なくとも１つのメディアストリームをクライアント装置にストリームする。

ある態様によれば、ストリーミング中に１つ以上の配信チャネルを切り換えるための技術は、１つまたは複数のメディアストリームをクライアント装置にストリームする旨の要求をサーバ装置に送信するクライアント装置を含む。サーバ装置は、その要求を受信し、ＴＣＰ（伝送制御プロトコル）を使用して、クライアント装置に対する１つまたは複数のメディアストリームのストリーミングを開始する。サーバ装置からクライアント装置へのＴＣＰを使用した１つまたは複数のメディアストリームのストリーミング中に、サーバ装置からクライアント装置にＵＤＰ（ユーザデータグラムプロトコル）を使用してデータをストリームすることができるか否かを判定するために、プロービング（ｐｒｏｂｉｎｇ）が実行される。プロービングが、サーバ装置からクライアント装置にＵＤＰを使用してデータをストリームすることができることを示す場合、１つまたは複数のメディアストリームのストリーミングが、ＴＣＰの使用からＵＤＰの使用に切り換えられる。しかし、プロービングが、サーバ装置からクライアント装置にＵＤＰを使用してデータをストリームすることができないことを示す場合、１つまたは複数のメディアストリームのストリーミングはＴＣＰを使用し続ける。

類似の構成要素および／または特徴を参照するために、本明細書を通して同じ番号が使用される。

本明細書では、メディアをストリーミングするための高速起動を説明する。高速起動は、予測スタートの技術と、ストリーミング中に１つ以上の配信チャネルを切り換えるための技術の一方または両方を含む。予測スタートは、メディアコンテントソースが、要求側クライアント装置がどのメディアストリームを望むかを予測し、そのクライアント装置に対してその予測されたメディアストリームのストリーミングを開始することを可能にする。配信チャネル切り換え技術は、メディアコンテントソースが、１つの配信チャネルを使用して（例えば、伝送制御プロトコル（ＴＣＰ）を使用して）１つ以上のメディアストリームのストリーミングを開始し、次いで別の配信チャネル（例えば、ユーザデータグラムプロトコル（ＵＤＰ）を使用して）が機能するか否かをチェックし、それが機能する場合はその配信チャネルに切り換えることを可能にする。

図１は、本明細書に記載の、メディアをストリーミングするための高速起動をサポートするネットワーク環境１００の例を示す。環境１００で、複数の（ａ）クライアントコンピューティング装置１０２（１）、１０２（２）、．．．、１０２（ａ）が、複数の（ｂ）サーバコンピューティング装置１０４（１）、１０４（２）、．．．、１０４（ｂ）にネットワーク１０６を介して連結される。ネットワーク１０６は、様々な従来型ネットワークプロトコル（公衆および／または自社開発のプロトコルを含めて）のどれかを使用した、様々な従来型ネットワークトポロジおよびタイプ（有線および／または無線ネットワークを含めて）のどれかを表すことを意図する。ネットワーク１０６は、例えばインターネット並びに、可能ならば１つまたは複数のローカルエリアネットワーク（ＬＡＮ）の少なくとも一部を含むことができる。

コンピューティング装置１０２および１０４は、デスクトップＰＣ、ワークステーション、メインフレームコンピュータ、インターネット機器、ゲーム用コンソール、ハンドヘルドＰＣ、携帯電話、携帯情報端末（ＰＤＡ）などを含めて、様々な従来型コンピューティング装置のどれであってもよい。装置１０２および１０４の１つまたは複数は、同じタイプの装置であっても、異なるタイプの装置であってもよい。

サーバ装置１０４は、クライアント１０２にストリーミングするために使用可能な様々なデータのどれでも作成することができる。「ストリーミング」という用語は、メディアを表すデータがネットワークを介してクライアント装置に提供されること、またそのコンテントの再生を、そのコンテント全体が配信される前に開始することができること（例えば、再生前にデータ全体を事前配信するのではなく、随時ベースでデータを提供する）を示すために使用される。データは、公共で入手可能としても、制限付きとしてもよい（例えば、特定ユーザ限定で、適切な料金が支払われた場合にのみ入手可能とする、など）。データは、オーディオ、ビデオ、テキスト、アニメーションなどのような、様々な１つまたは複数のタイプのコンテントのどれであってもよい。あるいは、データは、事前に記録しても、「生放送」（例えば、コンサート中に取り込まれ、取り込み直後にストリーミング用に使用可能とされる、そのコンサートのデジタル表現）であってもよい。

クライアント装置１０２は、ストリーミングメディアコンテントをファイルとして記憶するサーバ１０４から、または何らかの別のソースからストリーミングメディアを受信するサーバ１０４から、ストリーミングメディアを受信することができる。例えば、サーバ１０４は、ストリーミングメディアコンテントをファイルとして記憶する別のサーバからストリーミングメディアを受信するか、または何らかの別のソース（例えば、「生放送」イベントを符号化するエンコーダ）からストリーミングメディアを受信することができる。

本明細書で使用するように、ストリーミングメディアは、１つの装置から別の装置に（例えば、サーバ装置１０４からクライアント装置１０２に）１つまたは複数のメディアストリームをストリーミングすることを意味する。メディアストリームは、オーディオ、ビデオ、テキストなどの１つまたは複数のような、様々なタイプのコンテントのどれでも含むことができる。

図２は、本明細書に記載の、メディアをストリーミングするための高速起動を使用してメディアコンテントをストリームすることのできる、クライアント装置とサーバ装置の例を示す。サーバ装置１０４からクライアント装置１０２にメディアコンテントをストリームするために、通常、クライアント装置１０２とサーバ装置１０４の両方で、複数の異なるプロトコルに従う。これらの異なるプロトコルは、ストリーミングプロセスの異なる態様を担うことができる。図２には示さないが、１つまたは複数の追加装置（例えば、ファイアウォール、ルータ、ゲートウェイ、ブリッジなど）を、クライアント装置１０２とサーバ装置１０４の間に配置することができる。

図２の例では、アプリケーションレベルプロトコル１５０、転送プロトコル１５２、および１つまたは複数の配信チャネルプロトコル１５４が、ストリーミングプロセスの一部として使用される。図２に示さない追加プロトコルを使用することもできる（例えば、アプリケーションレベルプロトコル１５０と転送プロトコル１５２の間に１つ以上の追加プロトコルがある場合がある）。アプリケーションレベルプロトコル１５０は、リアルタイムプロパティによりデータの配信を制御するためのアプリケーションレベルでのプロトコルである。アプリケーションレベルプロトコル１５０は、オーディオおよびビデオコンテントのストリーミングのような、リアルタイムデータの制御されたオンデマンド配信を可能にするように任意選択で拡張可能な、フレームワークを提供する。アプリケーションレベルプロトコル１５０は、メディアサーバからのマルチメディアのストリーミングの配信を開始し、方向付けるための、制御プロトコルである。アプリケーションレベルプロトコル１５０の例には、ネットワーク作業部会のコメント求む（Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）（ＲＦＣ）２３２６、１９９８年４月に記載されているリアルタイムストリーミングプロトコル（ＲＴＳＰ）、およびネットワーク作業部会のコメント求む（Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）（ＲＦＣ）１９４５年、１９９６年５月またはネットワーク作業部会のコメント要求（ＲＦＣ）２０６８、１９９７年１月に記載されているハイパーテキスト転送プロトコル（ＨＴＴＰ）が含まれる。

アプリケーションレベルプロトコル１５０は、オーディオおよびビデオのストリーミングのような、リアルタイムデータの配信のために転送プロトコル１５２を使用する。転送プロトコル１５２は、メディアストリームのためのパケット形式を定義する。転送プロトコル１５２は、オーディオ、ビデオまたはシミュレーションデータのようなリアルタイムデータを、マルチキャストまたはユニキャストネットワークサービスを介して伝送するアプリケーションに適した、端末相互間ネットワーク転送機能を提供する。転送プロトコル１５２の例には、ネットワーク作業部会のコメント求む（Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）（ＲＦＣ）３５５０、２００３年７月に記載されているリアルタイム転送プロトコル（ＲＴＰ）およびリアルタイム制御プロトコル（ＲＴＣＰ）が含まれる。ＲＴＰは、資源確保に対処せず、リアルタイムサービスのためにサービス品質を保証しない。データ転送は、大規模マルチキャストネットワークにスケーラブルな方法でデータ配信の監視を可能にするために、また一部の制御および識別機能を提供するために、制御プロトコル（ＲＴＣＰ）により増大される。

転送プロトコル１５２は、転送接続のために１つ以上の配信チャネルプロトコル１５４を使用する。１つ以上の配信チャネルプロトコル１５４は、データのパケットをサーバ装置１０４からクライアント装置１０２に転送するために、１つまたは複数のチャネルを含む。通常は、単一メディアストリーム用のデータパケットを送信するために各チャネルが使用されるが、別の実施形態では、複数のメディアストリーム用のデータパケットを送信するために単一チャネルを使用することができる。配信チャネルプロトコル１５４の例には、伝送制御プロトコル（ＴＣＰ）パケットと、ユーザデータグラムプロトコル（ＵＤＰ）パケットが含まれる。ＴＣＰはデータパケットの配信を保証にするが、ＵＤＰはデータパケットの配信を保証しない。通常、ＴＣＰを使用したデータパケットの配信の方が、ＵＤＰを使用したデータパケットの配信よりも信頼性は高いが、より多くの時間を消費する。

図３は、クライアント装置およびサーバ装置と予測スタート技術を、さらに詳細に示すブロック図である。ある実施形態では、図２のプロトコル１５０、１５２および１５４は、図３のクライアント装置とサーバ装置に含まれるが、これは図示していない。さらに、図３には示さないが、１つまたは複数の追加装置（例えば、ファイアウォール、ルータ、ゲートウェイ、ブリッジなど）を、クライアント装置１０２とサーバ装置１０４の間に配置することができる。

クライアント装置１０２は、予測再生要求１８２をサーバ装置１０４に送信することによって予測スタートプロセスを開始する。予測再生要求１８２は、クライアント装置１０２がどのメディアストリームを望むかを予測する際に、サーバ装置１０４を支援するために、様々な情報を含むことができる。この情報は、例えばクライアント装置１０２に関する情報、クライアント装置１０２の１人以上のユーザに関する情報、および／またはサーバ装置１０４とクライアント装置１０２の間の接続に関する情報を含むことができる。サーバ装置１０４は、予測再生要求を受信し、クライアント装置１０２がどのメディアストリームを望むかを予測する。この予測は、通常、予測再生要求に含まれる情報の少なくとも一部に基づく。

サーバ装置１０４は次いで、クライアント装置１０２が望むと予測した１つ以上のメディアストリームを、クライアント装置１０２にストリームすることを開始する。したがって、図３の例では、サーバ装置１０４からクライアント装置１０２へのメディアコンテントのストリーミングは、サーバ装置１０４で受信したクライアント装置１０２からの第１の要求に応じて開始される。予測された１つ以上のストリーム１８４のストリーミングの一部として、サーバ装置１０４は、クライアント装置１０２に入手可能な様々なメディアストリームの説明を含む。これらの様々なメディアストリームは、通常、サーバ装置１０４によって予測されたストリーム並びに１つまたは複数の追加ストリームを含む。

クライアント装置１０２は、サーバ装置１０４からストリーミングメディアを受信し、ストリーミングメディアを処理する。この処理は、例えばクライアント装置１０２でユーザに公開するためにストリーミングメディアをバッファすることを含むことができる。さらに、クライアント装置１０２は、サーバ装置１０４から受信した、クライアント装置１０２に入手可能な様々なメディアストリームの説明をチェックし、クライアント装置１０２に現在ストリーミングされている予測されたストリームが、本当にクライアント装置１０２の望むストリームか否かを判定する。それらが望まれるストリームである場合、クライアント装置１０２は、さらなるアクションを取る必要はない。しかしそれらが望まれるストリームでない場合、クライアント装置１０２はサーバ装置１０４にストリーム選択１８６を送信する。ストリーム選択１８６は、クライアント装置１０２が望むストリームを示す。

サーバ装置１０４は、ストリーム選択１８６を受信し、１つ以上の選択されたストリーム１８８をクライアント装置１０２にストリームする。ストリーム選択１８６は、１つまたは複数のストリームを示すことができ、予測されたすトリームと交換すべきストリームまたは予測されたストリームに加えてストリームすべきストリームを示すことができる。示されたストリームが予測されたストリームと交換されるべき場合、予測されたストリームのストリーミングがサーバ装置１０４によって中止される。しかし示されたストリームが予測されたストリームに追加されるべき場合、その予測されたストリームのストリーミングはサーバ装置１０４によって中止されない。

予測再生要求１８２、予測された１つ以上のデータストリームによる応答１８４、ストリーム選択１８６、および１つ以上の選択されたデータストリームによる応答１８８の実施形態を、以下のパラグラフでさらに詳細に説明する。

予測再生要求１８２は、ユニフォーム資源ロケータ（ＵＲＬ）のような資源ロケータを含む。この資源ロケータは、クライアント装置１０２が望むメディアコンテントを示す。しかし、メディアコンテントには様々な選択肢がある場合がある。例えば、メディアコンテントは、（異なる接続速度を有するクライアント装置のために）異なるビットレートで符号化された複数のビデオストリーム、異なる言語のための複数のビデオストリーム、異なる言語のための複数のオーディオストリーム、異なる言語の複数のサブタイトルメディアストリームなどを有することができる。しかし、クライアント装置１０２は、それらの様々な選択肢をまだ知らないので、メディアコンテントについて様々な使用可能な選択肢の特定の１つを選択することはまだできない。

予測再生要求１８２は、クライアント装置１０２がどのメディアストリームを望むかを予測する際にサーバ装置１０４が使用する情報を含む、１つまたは複数の名前−値の対も含むことができる。これらの名前−値の対は、識別された情報のタイプを示す名前部分と、識別された特定情報を示す値部分とを含む。あるいは、この情報は、所定の順番で表示される一連の値のような（したがって、名前部分に対する要求が緩和される）、名前−値の対以外の方法で識別することができる。さらに場合によっては、予測再生要求１８２は、名前−値の対またはその他に、このようないかなる情報をも含まない場合がある。

再生要求１８２に含まれる情報は様々であってよい。ある実施形態では、再生要求１８２は、クライアント装置１０２とサーバ装置１０４の間の接続速度またはリンク帯域幅の識別と、さらにクライアント装置１０２が望む言語の識別を含む。別の実施形態では、リンク帯域幅および／または言語に加えて、またはこの代わりに、どのタイプのメディアストリームが望まれるか（例えば、オーディオのみ、ビデオのみ、ビデオとオーディオなど）、クライアント装置１０２ではどのコード（例えば、オーディオコード、ビデオコードなど）が使用可能か、ビデオデータにどの言語を入れるべきか（例えば、ビデオ中の人物の口元がオーディオと合うように）などのような、他の情報を含むことができる。

クライアント装置１０２は、別の方法で予測再生要求１８２に含まれるべき情報を取得することができる。通常、資源ロケータは、ユーザ入力（例えば、特定のメディアコンテントのユーザ選択）により、またはプログラム入力（例えば、クライアント装置１０２で実行中のプログラムが特定のメディアコンテントを選択する）により取得される。サーバ装置１０４が予測をする際に使用する情報は、予測再生要求１８２を送信中のアプリケーションに事前にプログラムしておくことができる（例えば、開発業者または設計者により、または好みに関するユーザ設定により）。例えば、アプリケーションがメディアプレーヤアプリケーションの場合、メディアプレーヤアプリケーションのユーザは、ユーザが好む言語を識別するために、メディアプレーヤアプリケーションの好みまたは選択肢を設定することができる場合がある。接続速度またはリンク帯域幅に関する情報は、例えばクライアント装置１０２で帯域幅をテストするアプリケーションにより、使用可能な帯域幅のユーザ入力に基づいて、また、クライアント装置１０２にメディアが以前ストリームされた速度を監視することなどにより入手可能である。あるいは、サーバ装置１０４が予測をする際に使用する情報は、サーバ装置１０４に事前にプログラミングしておくこともできる（例えば、すべてのクライアントが同じタイプであると認識され、または予測される状態に）。

予測再生要求１８２は、様々な異なる形式を取ることができる。ある実施形態では、予測再生要求１８２はＨＴＴＰ ｇｅｔコマンドである。あるいは、他の形式を使用することもできる（例えば、異なる構文、ＨＴＴＰ ｐｏｓｔコマンド、ＲＴＳＰコマンドなど）。予測再生要求は、要求を予測再生要求であると識別する識別子を含む。ある実施形態では、ある要求を予測再生要求であると識別するために１つまたは複数のヘッダーが使用されるが、その代わりに、その要求が予測再生要求であると識別する情報をメッセージ本体に含めることもできる。さらに、ある実施態様では、１つまたは複数のそのようなヘッダーが要求に存在することにより、その要求が予測再生要求であると識別される。ある要求が予測再生要求であると識別するために使用することのできる予測スタートヘッダーの例は、予測再生が要求されていることを示すパラメータとして値「１」を使用して、「Ｐｒａｇｍａ：ＰｒｅｄＳｔｔａｒｔ＝１」である。

サーバ装置１０４は、予測再生要求１８２を受信し、要求１８２に関連付けられたメディアストリームを識別する。要求１８２は、クライアント装置１０２にストリームすることのできる１つまたは複数のメディアストリームをそれぞれが含む、１つまたは複数のファイルである場合のある資源を識別する。資源にはそれらのメディアストリームの識別が関連付けられており、通常、それらのメディアストリームを説明する情報（例えば、それらが符号化されたビットレート、それらがオーディオ、ビデオ、テキストなどのどれなのか、それらがどの言語か）が関連付けられている。この識別は、資源の一部であってよく（例えば、ＡＳＦ（高度ストリーミングフォーマット（Ａｄｖａｎｃｅｄ Ｓｔｒｅａｍｉｎｇ Ｆｏｒｍａｔ）または高度システムフォーマット（Ａｄｖａｎｃｅｄ Ｓｙｓｔｅｍｓ Ｆｏｒｍａｔ））ファイル内のＡＳＦのように、資源のヘッダーファイルに含まれてもよい）、あるいは別個に維持されてもよい。

サーバ装置１０４は、クライアント装置１０２がどのメディアストリームを望むかを予測するために、予測再生要求１８２に含まれる情報と、要求された資源に対してどのメディアストリームが使用可能であるかに関する情報を使用する。サーバ装置１０４は、サーバ装置１０４の管理者またはユーザによって供給されるディフォルト値、他のクライアント装置１０２に（および／またはこのクライアント装置１０４に）既にストリームされた１つ以上のメディアストリームなどのような、追加情報も使用することができる。クライアント装置１０２が望む１つ以上のストリームが予測される方法自体は、サーバ装置１０４に使用可能な情報に基づいて様々に異なる場合がある。

一例として、クライアント装置１０２にストリームされるべき映画に対する予測再生要求を、クライアント装置１０２が送信すると仮定する。クライアント装置１０２は、そのビデオコンテントはどれだけの様々なビットレートで符号化されているか、そのオーディオコンテントはどの言語で入手可能か、どの言語のサブタイトルが入手可能であるかなどのように、その映画に関してどのメディアストリームが入手可能かを知らない。しかし、クライアント装置１０２は、そのクライアント装置１０２のディフォルト言語が英語であり、秒速５００キロビット（ｋｂｐｓ）の接続速度を有することは知っていると仮定する。したがって、クライアント装置１０２は、その映画に関する予測再生要求をサーバ装置１０４に送信し、そのディフォルト言語が英語であり、そのディフォルト接続速度が５００ｋｂｐｓであるという指示を予測再生要求に含める。

サーバ装置１０４は、予測再生要求を受信し、要求された映画を説明する、要求された映画に関連付けられた情報にアクセスする。映画は、１００ｋｂｐｓで符号化されたビデオストリームと、３００ｋｂｐｓで符号化されたビデオストリームと、５００ｋｂｐｓで符号化されたビデオストリームの、３つのビデオストリームを有すると仮定する。さらに、その映画は、１００ｋｂｐｓで符号化された英語のオーディオストリームと、１００ｋｂｐｓで符号化されたスペイン語のオーディオストリームとを有し、さらにその映画は１０ｋｂｐｓで符号化されたフランス語のサブタイトルストリームと、１０ｋｂｐｓで符号化された日本語のサブタイトルのストリームとを有すると仮定する。また、その映画に関連付けられた情報は、そのビデオストリームが相互排除的であり（クライアント装置１０２には、一度にこれら３つのうち１つしかストリームできない）、オーディオストリームは相互排除的であり（クライアント装置１０２には、一度にこれら２つのうち１つしかストリームできない）、オーディオはビデオよりも優先されることを示すと仮定する。

オーディオがビデオよりも優先されるので、サーバ装置１０４は、２つのオーディオストリームのうちの１つをクライアント装置１０２にストリームすることになる。さらに、予測再生要求は、クライアント装置１０２のディフォルト言語が英語であるという指示を含むので、サーバ装置１０４は、クライアント装置１０２は英語のオーディオストリームを望むと予測する。

英語のオーディオストリームは１００ｋｂｐｓで符号化されており、クライアント装置１０２に対するディフォルトの接続速度は５００ｋｂｐｓなので、サーバ装置１０４は、クライアント装置１０２が３００ｋｂｐｓで符号化されたビデオストリームを望むと予測する（オーディオストリームは１００ｋｂｐｓで符号化されているので、サーバ装置１０４は、５００ｋｂｐｓのストリームをストリームするには帯域幅が不十分であると予測する）。

予測再生要求はサブタイトルのストリームに関するいかなる情報も含まないので、サーバ装置１０４は、サブタイトルのストリームが望まれると予測するか否かを判定するために各所を見る。残りの帯域幅があるので（５００ｋｂｐｓのうち、４００ｋｌｂｐｓしか使用されていない）、サーバ装置１０４は、サブタイトルのストリームのうちの１つが望まれると予測することができる。映画に関連付けられた、他よりも優先度が高いという情報において、サブタイトルのストリームのうちの１つが識別される場合、そのサブタイトルのストリームは、クライアント装置１０２が望むサブタイトルのストリームであると予測される。そうでない場合、サブタイトルのストリームのうちの１つは、他の方法で（例えば、ランダムに、またはその映画に関連付けられた情報内で参照される順番により）クライアント装置１０２が望むサブタイトルのストリームであると予測される。

あるいは、サーバ装置１０４は、様々なメディアストリームがクライアント装置によってどれだけ頻繁に望まれるかを記録することができる。この記録が、そのサブタイトルのストリームがクライアント装置によってまれにしか望まれないことを示す場合（例えば、５０％より低い回数）、サーバ装置１０４は、クライアント装置１０２が望むサブタイトルのストリームはないと予測することができ、クライアント装置１０２にサブタイトルのストリームをストリームしない。

クライアント装置１０２が望むとサーバ装置１０４が予測したメディアストリームは、あくまでも予測に過ぎないことに留意されたい。これらのメディアストリームが、本当にクライアント装置１０２の望むメディアストリームであるという保証はない。しかし予測を行うことにより、サーバ装置１０４は、希望するメディアストリームの選択をクライアント装置１０２が行うのを待つことを必要とせず、クライアント装置１０２に対してそのメディアストリームのストリーミングを即座に開始することができる。

サーバ装置１０４は次いで、クライアント装置１０２に予測された１つ以上のメディアストリームをストリームする。サーバ装置１０４は、要求された資源にどのメディアストリームが使用可能であるかと、クライアント装置１０２が望んでいると予測されたのはどのストリームかの識別を含む情報も伝達する。この情報は、予測された１つ以上のメディアストリームと共に含めることができ、したがってクライアント装置１０２にストリームすることができるか、あるいは、非ストリーミング方法のような何らかの他の方法で伝達することができる（例えば、ＨＴＴＰベースの制御プロトコルを介して）。ある実施形態では、この情報は、セッション記述プロトコル（ＳＤＰ）、ネットワーク作業部会のコメント求む（Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐ Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）（ＲＦＣ）２３２７、１９９８年４月に従い、セッション記述メッセージに含まれる。

クライアント装置１０２は、要求された資源にどのメディアストリームが使用可能であるかと、クライアント装置１０２が望んでいると予測されたのはどのストリームかの識別も含めて、予測されたメディアストリームを受信する。クライアント装置１０２は次いで、要求された資源にどのメディアストリームが使用可能であるかを分析し、予測されたメディアストリームとは異なるメディアストリームを選択することができる。異なるストリームの選択は任意選択である。クライアント装置１０２が、サーバ装置１０４の予測するメディアストリームを望む場合、クライアント装置１０２による他のメディアストリームの選択は必要ない。

選択されたメディアストリームを、予測されたメディアストリームに追加することができる（例えば、前例では、クライアント装置１０２が望んでいるとサーバ装置１０４が予測することのできるサブタイトルのストリームはないが、クライアント装置１０２はサブタイトルのストリームを選択することができる）。あるいは、選択されたメディアストリームを、予測されたメディアストリームの代わりとすることもできる（例えば、クライアント装置１０２は、英語のオーディオストリームではなく、スペイン語のオーディオストリームを選択することができる）。

クライアント装置１０２での選択は、様々な方法で行うことができる。例えば、この選択を行うために、アプリケーション（例えば、メディアプレーヤアプリケーション）をプログラムすることができる。別の例として、入手可能な様々なメディアストリームをクライアント装置のユーザに公開することができ、そのユーザに、自分が望む１つ以上のメディアストリームの選択を許可することができる。この場合、クライアント装置１０２が行う選択はどれも、サーバ装置１０４に送信される。

ある実施形態では、メディアをストリーミングするためにＨＴＴＰを使用する場合など、ストリーミングセッションの識別子が使用される。この識別子は、異なる要求が相互に関連付けられることを可能にする。例えば、予測再生要求は、クライアント装置１０２とサーバ装置１０４の間の１つの接続を介して送信することができ、選択されたメディアストリームを識別する要求は、クライアント装置１０２とサーバ装置１０４の間の別の接続を介して送信される。２つの要求が相互に関連付けられていることをサーバ装置１０４が知るために、ストリーミングセッションの識別子が使用される。ある実施形態では、サーバ装置１０４は、予測再生要求に応じて識別子を返す。この識別子は次いで、クライアント装置１０２が、選択されたメディアストリームを識別する要求が予測再生要求に関連付けられていることをサーバ装置１０４に通知するために、選択されたメディアストリームを識別する要求をサーバ装置１０４に送信する際に、使用することができる。

選択されたメディアストリームを識別する要求は、様々な異なる形式のどれであってもよい。ある実施形態では、この要求は、例えばＨＴＴＰ ＰｏｓｔコマンドまたはＨＴＴＰ Ｇｅｔコマンドとしてサーバ装置１０４に送信することのできるＳｅｌｅｃｔ要求である。あるいは、この要求は、ＲＴＳＰコマンドを使用するなどのような、他の方法で配信することができる。Ｓｅｌｅｃｔ要求は、Ｓｅｌｅｃｔ要求、０またはそれ以上のヘッダー、および任意選択でメッセージ本体として要求を識別する識別子を含む。ある実施形態では、選択されたメディアストリームを識別する情報は、Ｓｅｌｅｃｔ要求の１つまたは複数のヘッダーに含まれるが、選択されたメディアストリームを識別する情報は、別法としてメッセージ本体に含めることができる。あるいは、ある実施形態では、要求に１つまたは複数のこのようなヘッダーが存在することによって、その要求がＳｅｌｅｃｔ要求であると識別される。表Ｉは、Ｓｅｌｅｃｔ要求に含めることのできるヘッダーの一例を示す。

選択されたメディアストリームを説明する情報は、選択されたメディアストリームを様々な方法で説明することができる。選択されたメディアストリームの説明の一部に、メディアストリームのどれだけデータがクライアント装置１０２にストリームされるべきかを示す（例えば、すべてのフレーム、キーフレームのみなど）「ｔｈｉｎｎｉｎｇ ｌｅｖｅｌ」を含めることができる。一例として、この説明は、サーバ装置１０４がどのストリームを予測したかには関係なく、クライアント装置１０２が望む１つ以上のメディアストリームのリストであってよい。別の例として、この説明は、サーバ装置１０４が予測したストリームに付加される、クライアント装置１０２が望む１つ以上のメディアストリームのリストであってよい。さらに別の例として、この説明は、予測したストリームと、予測したストリームに代わるべき選択されたストリームとをそれぞれが識別する、１つまたは複数のストリーム対の値を含むことができる。さらにまた別の例として、この説明は、１つ以上のメディアストリームのすべてと、そのメディアストリームがクライアント装置１０２に対するストリーミングに選択されているか否かの識別とのリストであってよい。また別の例として、この説明は、「否定的な」説明であってよい（例えば、クライアント装置１０２が望まない１つ以上のメディアストリームのすべてのメディアストリームのリストであり、したがって、クライアント装置１０２が望まない１つ以上のメディアストリームを本質的に識別するリスト）。

サーバ装置１０４は、Ｓｅｌｅｃｔ要求を受信し、クライアント装置１０２に対して選択されたストリームのストリーミングを開始する。サーバ装置１０４は、選択されたストリームと交換された予測される１つ以上のストリームの、クライアント装置１０２に対するストリーミングは中止するが、選択されたストリームと交換されなかった予測される１つ以上のストリームのストリーミングは行う。

予測再生要求によって識別された資源を、単一メディアまたはマルチメディアの公開か、または複数のそのような公開に関連付けることができる。例えば、資源は、複数のビデオ、オーディオおよび／またはサブタイトルのストリームを有する場合があるとしても、単一のマルチメディアの公開である映画を識別することができる。別の例として、資源は、映画と、別の映画のコマーシャルおよび予告編とを識別することができる。この例では、映画は、１つのマルチメディアの公開であり、コマーシャルは第２のマルチメディアの公開であり、予告編は第３のマルチメディアの公開である。

資源が複数のマルチメディアの公開に関連付けられている場合、サーバ装置１０４は、クライアント装置１０２がどの公開を望むかを予測し、またクライアント装置１０２がそれらの公開の中でどのメディアストリームを望むかを予測することができる。例えば、１つの資源に関連付けられた２つの異なるコマーシャル、すなわちラテンアメリカ系の聴衆向けのコマーシャルと、中国人聴衆向けのコマーシャルがあると仮定する。予測再生要求がディフォルト言語をスペイン語と示している場合、サーバ装置１０４は、クライアント装置１０２はラテンアメリカ系の聴衆向けのコマーシャルを望むのであって、中国人聴衆向けのコマーシャルではないと予測することができる。

状況によっては、サーバ装置１０４が予測を行わないことを選ぶ場合があることに留意されたい。このような状況は、例えば不正確な予測を行う可能性が大きすぎる場合に発生する場合がある。このような状況では、サーバ装置１０４は、要求された資源にどのメディアストリームが使用可能であるかの識別は送信するが、いかなる予測された１つ以上のメディアストリームのストリーミングをも開始しない。それよりも、サーバ装置１０４は、使用可能なメディアストリームの１つまたは複数の選択をクライアント装置が行うまで待機し、選択された１つ以上のメディアストリームを再生するための要求が受信されたときに、その選択された１つ以上のメディアストリームのストリーミングを開始する。

図４は、予測スタートプロセス２００の一例を示す流れ図である。図４は、クライアント装置１０２（例えば、図１、２および３の）およびサーバ装置１０４（例えば、図１、２および３の）の両方によって実行される動作を示す。クライアント装置１０２によって実行される動作は図４の左側に示され、サーバ装置１０４によって実行される動作は図４の右側に示される。

最初に、クライアント装置１０２は、予測再生要求を生成する（動作２０２）。予測再生要求は、クライアント装置１０２にストリームされるよう望まれる、サーバ装置１０４の資源として表される、１つまたは複数のメディアまたはマルチメディアの公開を識別する。クライアント装置１０２は、予測再生要求をサーバ装置１０４に送信し（動作２０４）、サーバ装置１０４は、予測再生要求を受信する（動作２０６）。

予測再生要求に応答して、サーバ装置１０４は、クライアント装置１０２が望む１つまたは複数のメディアストリームを予測する（動作２０８）。上記のように、この予測は、予測再生要求に含まれる情報、サーバ装置１０４でのディフォルト設定、要求された資源に関連付けられた情報、メディアのストリーミングするための以前の要求などのような、様々な要因に基づくことができる。予測された１つ以上のメディアストリームは次いで、クライアント装置１０２にストリームされる（動作２１０）。動作２１０でのこのストリーミングの一部として、予測された１つ以上のメディアストリームと、要求された資源に使用可能な１つ以上のメディアストリームの識別も、クライアント装置１０２に送信される。あるいは、上記のように、予測された１つ以上のメディアスストリームと、要求された資源に使用可能なメディアストリームの識別は、非ストリーミング方法を含めて他の方法でクライアント装置１０２に伝達することができる。

クライアント装置１０２は、予測された１つ以上のメディアストリームを受信し（動作２１２）、予測された１つ以上のメディアストリームと要求した資源に使用可能な１つ以上のメディアストリームの受信した識別を分析する。プロセス２００は次いで、クライアント装置１０２が、１つ以上の予測されたメディアストリームではなく１つまたは複数の異なるメディアストリームをストリームさせることを望むか否かに基づいて進む。上記のように、そのような異なる１つ以上のメディアストリームの選択は、クライアント装置１０２のアプリケーションプログラムまたはクライアント装置１０２でのユーザ入力によるなど、異なる方法で行うことができる。異なる１つ以上のメディアストリームが選択されない場合（動作２１４）、クライアント装置１０２は、サーバ装置１０４が予測した１つ以上のメディアストリームを望み、それらの受信した１つ以上のメディアストリームの処理に進む（動作２１６）。この処理は、例えば受信した１つ以上のメディアストリームのバッファおよび／またはクライアント装置１０２で受信した１つ以上のメディアストリームの公開（例えば、再生）を含むことができる。

しかし、異なる１つ以上のメディアストリームが選択される場合、クライアント装置１０２は、サーバ装置１０４にそれら選択されたメディアストリームの指示を送信する（動作２１８）。サーバ装置１０４は、選択された１つ以上のメディアストリームの指示を受信し（動作２２０）、クライアント装置１０２に送信されるべき１つ以上のメディアストリームを識別する（動作２２２）。上記のように、クライアント装置１０２が選択した１つ以上のストリームは、予測された１つ以上のメディアストリームに付加的なものとするか、または予測された１つ以上のメディアストリームの１つまたは複数のメディアストリームの代わりとすることができる。動作２２２でサーバ装置１０４が識別した１つ以上のメディアストリームは、クライアント装置１０２が選択しているように示されたストリームを含み（動作２２０で受信された）、動作２０８でサーバ装置１０４が予測した１つ以上のストリームの１つまたは複数のストリームを含むこともできる。

サーバ装置１０４は次いで、クライアント装置１０２にストリームされた、識別された１つ以上のメディアストリームをストリームする（動作２２４）。通常、識別された１つ以上のメディアストリームは、現在の再生位置からストリームされる（例えば、選択要求が受信された場合、その１つ以上のメディアストリームが現在ストリームされている一時的な位置が識別され、次いでその識別された１つ以上のメディアストリームの対応する一時的な位置が特定され、その識別された１つ以上のメディアストリームのストリーミングが特定されたその位置から開始される）。あるいは、識別された１つ以上のメディアストリームの開始のような、他の開始点を使用することができる。クライアント装置１０２は、識別された１つ以上のメディアストリームをサーバ装置１０４から受信し（動作２２６）、その受信した１つ以上のメディアストリームを処理する（動作２１６）。この処理は、例えば、１つ以上のメディアストリームのバッファと、クライアント装置１０２での１つ以上のメディアストリームの公開（例えば、再生）を含むことができる。

図２に戻ると、本明細書で説明した高速起動は、ストリーミング中に１つ以上の配信チャネルを切り換えるプロセスも含む。転送プロトコル１５２は、様々な異なる配信チャネルを使用することができる。通常、各メディアストリームがサーバ装置１０４から、別の配信チャネルを使用するクライアント装置１０２に送信される。様々なメディアストリームのこれらの配信チャネルは、通常は同じタイプだが、異なるタイプであってもよい。配信チャネルの２つの共通タイプは、ＴＣＰチャネルとＵＤＰチャネルである。ＴＣＰチャネルはＴＣＰパケットと呼ばれるパケットでデータを送信するが、ＵＤＰチャネルはＵＤＰパケットと呼ばれるパケットでデータを送信する。通常、ＴＣＰを使用したデータパケットの配信はＵＤＰを使用したデータパケットの配信よりも信頼性が高いが、より多くの時間を消費する。さらに、クライアント装置１０２が、ＵＤＰパケットは受信できないがＴＣＰパケットは受信できる場合、クライアント装置１０２とサーバ装置１０４の間にファイアウォールが置かれるような状況が発生する場合がある。

図５は、クライアント装置およびサーバ装置と配信チャネル切り換えプロセスの例を、さらに詳細に示すブロック図である。ある実施形態では、図２のプロトコル１５０、１５２および１５４は図５のクライアント装置とサーバ装置に含まれるが、図示はしていない。さらに、図５には示さないが、１つまたは複数の追加装置（例えば、ファイアウォール、ルータ、ゲートウェイ、ブリッジなど）を、クライアント装置１０２とサーバ装置１０４の間に配置することができる。本明細書で説明した配信チャネル切り換えは、メディアコンテントソースが、１つの配信チャネル（例えば、ＴＣＰ）を使用して１つ以上のメディアストリームのストリーミングを開始し、次いで別の配信チャネル（例えば、ＵＤＰ）が機能するか否かをチェックし、機能する場合はそちらの配信チャネルに切り換える。

最初、クライアント装置１０２は、１つまたは複数のメディアストリームがクライアント装置１０２にストリームされることを要求する再生要求２５２を、サーバ装置１０４に送信する。この再生要求２５２は、上記の予測再生要求、または１つまたは複数のメディアストリームがクライアント装置１０２にストリームされることを要求するいかなる他の要求（または複数の要求の組み合わせ）であってもよい。例えば、この再生要求２５２は、所望のメディアストリームを識別するＳｅｌｅｃｔ要求を伴うＨＴＴＰ Ｐｏｓｔコマンドであってよい。この再生要求に応じて、サーバ装置１０４は、要求された１つ以上のメディアストリームをクライアント装置１０２にＴＣＰを使用してストリームする。この応答は、複数のＴＣＰパケットの要求された１つ以上のメディアストリームに関するデータを含む。

ＴＣＰを使用してサーバ装置１０４からクライアント装置１０２にメディアをストリーミングしている間、クライアント装置１０２はＵＤＰプロービングパケット２５６をサーバ装置１０４に送信する。ある実施形態では、これは、ＵＤＰポートを開き、開いたＵＤＰポートの識別をストリーミングメディアと共にＴＣＰ２５４を使用してクライアント装置１０２に送信する、サーバ装置１０４によって達成される。クライアント装置１０２は、ＵＤＰポート識別を受信し、次いでＵＤＰパケットをサーバ装置１０４のそのポートに送信することができる。あるいは、サーバ装置１０４は、ＵＤＰプロービングパケットのために使用するように、良く知られたＵＤＰポートを有することができ、クライアント装置１０２は、ＵＤＰプロービングパケット２５６を、サーバ装置１０４が開いたＵＤＰポートの識別を最初にクライアント装置１０２に送信せずに、この良く知られたＵＤＰポートに送信することができる。クライアント装置１０２はまた、それ自体で識別することのできるＵＤＰポートをサーバ装置１０４に対してＵＤＰプロービングパケット２５６の一部として、ＵＤＰパケットを受信することのできるＵＤＰポートとして開く。

サーバ装置１０４は、ＵＤＰプロービングパケット２５６を受信し、ＵＤＰプロービング応答パケット２５８を生成し、これをクライアント装置１０２に送信する。ＵＤＰプロービング応答パケット２５８は、サーバ装置１０４がＵＤＰプロービングパケット２５６を受信したという、クライアント装置１０２に対する指示である。ＵＤＰプロービング応答パケット２５８は、任意選択で、ＵＤＰプロービングパケット２５６に含まれる識別子のような、ＵＤＰプロービングパケット２５６のある種の識別子を含む。あるいは、同じ接続上における応答が存在するだけで、応答パケット２５８とプロービングパケット２５６を関連付けることができる。例えば、単一応答および関連付けられた応答は、１つの接続を介して送信された２つのメッセージに過ぎず、この場合、応答２５８は、プロービングパケット２５６に対する応答と見なされることになる。

ある実施形態では、単一ＵＤＰプロービングパケット２５６がクライアント装置１０２によって送信されるが、別の実施形態では、複数のＵＤＰプロービングパケット２５６がクライアント装置１０２により送信され、それぞれのそのＵＰＤプロービングパケット２５６に対してＵＰＤプロービング応答パケット２５８がサーバ装置１０４により返されることに留意されたい。複数のＵＤＰプロービングパケット２５６は、クライアント装置１０２によって同時に送信することも、あるいは異なる時点で送信することもできる（例えば、クライアント装置１０２は、別のＵＤＰプロービングパケット２５６を送信する前に、あるＵＰＤプロービングパケット２５６に対してＵＤＰプロービング応答パケット２５８が戻されるのを待つことができる）。例えば、転送プロトコル１５２がＲＴＰプロトコルとＲＴＣＰプロトコルを含む実施形態では、ＲＴＰデータは配信チャネルまたはフローを使用して送信され、ＲＴＣＰデータは別の配信チャネルまたはフローを使用して送信される。ＵＤＰプロービングパケット２５６は、これら異なる配信チャネルまたはフローそれぞれに対して送信することができる。別の例として、別のＵＤＰプロービングパケット２５６を、クライアント装置１０２により、複数のメディアストリームのそれぞれに（例えば、クライアント装置１０２がＵＤＰを使用したストリーミングに切り換えることを希望する各メディアストリームに対して、ＴＣＰを使用してクライアント装置１０２に現在ストリーミング中の各メディアストリームに対して、など）送信することができる。これらの２つの例は、組み合わせてもよい（例えば、２つのＵＤＰプロービングパケット２５６（ＲＴＰフローに対して１つと、ＲＴＣＰフローに対して１つ）を、クライアント装置１０２により、複数のメディアストリームのそれぞれに送信することができる）。

クライアント装置１０２はＵＤＰプロービング応答パケット２５８を受信し、クライアント装置１０２は、ＵＤＰパケットをサーバ装置１０４からクライアント装置１０２に送信できることを知る。したがって、クライアント装置１０２は、サーバ装置１０４に、サーバ装置１０４からクライアント装置１０２へのＵＤＰ ２６０を使用した１つ以上のメディアストリームのストリーミングに切り換えるための要求を送信する。通常、クライアント装置１０２は、１つ以上のメディアストリームのすべてをＵＤＰを使用したストリーミングに切り換えるための要求を、サーバ装置１０４に送信するが、クライアント装置１０２は、要求で、ＵＤＰを使用したストリーミングに切り換えるべき１つ以上の特定のメディアストリームしか識別することができない（残りの１つ以上のメディアストリームは、依然としてＴＣＰを使用してストリームされている）。あるいは、複数の要求をクライアント装置１０２からサーバ装置１０４に送信することができ、これらの要求のそれぞれは、ＵＤＰを使用してクライアント装置１０２にストリームすべき特定の１つまたは複数のメディアストリームを識別する。

この要求に応じて、サーバ装置１０４は、再生要求２５２で要求された１つ以上のメディアストリームのストリーミングを、ＵＤＰ ２６２を使用し、クライアント装置１０２に対して開始する。ある実施形態では、ＴＣＰを使用した１つ以上のメディアストリームのストリーミングが既に開始されているので、サーバ装置１０４は、１つ以上のメディアストリームの開始時にはＵＤＰを使用したストリーミングを開始しない。そうではなく、サーバ装置１０４は、ＴＣＰを使用したデータのストリーミングを中止し、ＴＣＰを使用したストリーミングが中止した点がどこであっても、その点からＵＤＰを使用したストリーミングを開始する。あるいは、パケット間にいくつかのオーバーラップがある場合がある（例えば、ＵＤＰへの切り換えが発生する点で、ＴＣＰを使用して既に送信済みの数個のパケットを、ＵＤＰを使用して再送することができる）。

ＵＤＰ ２６０を使用したサーバ装置１０４からクライアント装置１０２への１つ以上のメディアストリームのストリーミングに切り換えるための要求は、様々な異なる形式のどれであってもよい。ある実施形態では、この要求は、ＨＴＴＰ Ｐｏｓｔコマンドをサーバ装置１０４に送信することのできるＳｅｌｅｃｔ要求である。あるいは、この要求は、ＲＴＳＰコマンドを使用するような他の方法で配信することもできる。Ｓｅｌｅｃｔ要求は、その要求をＳｅｌｅｃｔ要求であると識別する識別子、０またはそれ以上のヘッダー、および任意選択でメッセージ本体を含む。ある実施形態では、ＵＤＰを使用した１つ以上のメディアストリームのストリーミングにサーバ装置を切り換えることを要求する情報は、Ｓｅｌｅｃｔ要求の１つまたは複数のヘッダーに含まれるが、ＵＤＰを使用した１つ以上のメディアストリームのストリーミングにサーバ装置を切り換えることを要求する情報は、メッセージ本体に含めてもよく、あるいはＵＤＰを使用した１つ以上のメディアストリームのストリーミングに切り換えるための要求を、その要求固有のものとしてもよい。ある実施形態では、Ｐｒａｇｍａ：ストリーム切り換えエントリヘッダー（表Ｉを参照して説明する）および／またはＸ−Ｔｒａｎｓｐｏｒｔヘッダー（表ＩＩを参照して説明する）の存在は、その要求をＳｅｌｅｃｔ要求であると識別する識別子として働く。表ＩＩに、Ｓｅｌｅｃｔ要求に含めることのできるヘッダーの一例を示す。

ある実施形態では、メディアストリームの実際のコンテントを表すデータ（例えば、クライアント装置１０２で再生されるビデオまたはオーディオを表すデータ）が、ＵＤＰパケットを使用してサーバ装置１０４からクライアント装置１０２に送信される場合であっても、制御情報（例えば、ＲＴＣＰパケット）はＴＣＰパケットを使用してサーバ装置１０４からクライアント装置１０２に送信される。別の実施形態では、制御情報（例えば、ＲＴＣＰパケット）を含めてすべてのデータが、ＵＤＰパケットを使用してサーバ装置１０４からクライアント装置１０２に送信される。

サーバ装置１０４からクライアント装置１０２にデータをストリームするためにＵＤＰパケットを使用することができない場合、ＵＤＰプロービングパケット２５６はサーバ装置１０４に到着せず（したがって、サーバ装置１０４はＵＤＰプロービング応答パケット２５８を送信することはない）、もしくはＵＤＰプロービング応答パケット２５８はクライアント装置１０２に到着しないということに留意されたい。したがって、クライアント装置１０２がＵＤＰプロービングパケット２５６に対する応答を受信しない場合、クライアント装置１０２は、サーバ装置１０４からクライアント装置１０２にデータをストリームするためにＵＤＰパケットを使用することができないことを知る。任意選択で、クライアント装置１０２がＵＤＰプロービングパケット２５６への応答を受信しない場合、クライアント装置１０２は、サーバ装置１０４からクライアント装置１０２にデータをストリームするためにＵＤＰパケットを使用することができないことを検証するために、１つ以上のＵＤＰプロービングパケットを１回または複数回再送することができる。

さらに、複数のＵＤＰプロービングパケット２５６が送信される場合（例えば、複数のメディアストリームまたは複数のフローに）、プロービングパケット２５６の一部に応じ、その他には応ぜずに、ＵＤＰプロービング応答パケット２５８を受信することができるということに留意されたい。これは、そのＵＤＰパケットが、一部のストリームまたはフロー（ＵＤＰプロービング応答パケット２５８が受信されたストリームまたはフロー）についてはサーバ装置１０４からクライアント装置１０２にストリームすることができるが、その他のストリームまたはフロー（ＵＤＰプロービング応答パケットが受信されなかったストリームまたはフロー）に対してはそうではないことを示す。

サーバ装置１０４からクライアント装置１０２にデータをストリームするためにＵＤＰパケットを使用することができるか否かのプロービングは、要求された１つ以上のメディアストリームが、ＴＣＰ ２５４を使用してクライアント装置１０２にストリーム中に行われることにも留意されたい。したがって、クライアント装置１０２は、ＵＤＰパケットを使用してそのデータをクライアント装置１０２にストリームすることができるか否かの判定を待つことを必要とせずに、その要求された１つ以上のメディアストリームの受信を開始する。

ＵＤＰプロービングパケット２５６とＵＤＰプロービング応答パケット２５８が、様々な情報のどれでも含むことができることをさらに留意されたい。１つ以上のメディアストリームに関する情報は、ＵＤＰプロービングパケット２５６とＵＤＰプロービング応答パケット２５８を使用してクライアント装置１０２とサーバ装置１０４の間で送信する必要はない。ＵＤＰプロービングおよびＵＤＰプロービング応答パケットの重要性は、それらのパケットに含まれる１つ以上のメディアストリームに関するどのような特別な情報でもなく、単にそれらのパケットがそれらの目標とするターゲットに到着するか否かにある。

図６は、配信チャネル切り換えプロセス３００の一例を示す流れ図である。図６は、クライアント装置１０２（例えば、図１、２および５）とサーバ装置１０４（例えば、図１、２および５）の両方によって実行される動作を示す。

最初に、クライアント装置１０２は、サーバ装置１０４にストリーミングメディアに対する要求を送信する（動作３０２）。サーバ装置１０４は、その要求を受信し、ＴＣＰを使用してクライアント装置１０２に対する要求された１つ以上のメディアストリームのストリーミングを開始する（動作３０４）。サーバ装置１０４は、引き続いて、要求された１つ以上のメディアストリームを、ＴＣＰを使用してストリームし、クライアント装置１０２は、その１つ以上のメディアストリームを受信し、処理する（動作３０６）。この処理は、例えばクライアント装置１０２での１つ以上のメディアストリームのバッファリングおよび／または公開（例えば、再生）を含むことができる。

動作３０６での、ＴＣＰを使用した、要求された１つ以上のメディアストリームのストリーミングと同時に、ＵＤＰを使用してデータをサーバ装置１０４からクライアント装置１０２にストリームすることができるか否かを判定するために、クライアント装置１０２とサーバ装置１０４の間のリンクがプローブされる（動作３０８）。上記のように、このプロービングは、クライアント装置１０２とサーバ装置１０４の間で送信される情報およびパケットを必要とする場合がある。

プロセス３００は次いで、そのプロービングが、ＵＤＰを使用してサーバ装置１０４からクライアント装置１０２にデータをストリームすることができることを示すか否かに基づいて進む（動作３１０）。ＵＤＰを使用してサーバ装置１０４からクライアント装置１０２にデータをストリームすることができない場合、サーバ装置１０４は、要求された１つ以上のメディアストリームを、ＴＣＰを使用してストリームし、クライアント装置１０２は、その１つ以上のメディアストリームを受信し、ＴＣＰを使用して受信したその１つ以上のメディアストリームを処理する（動作３０６）。しかし、ＵＤＰを使用してサーバ装置１０４からクライアント装置１０２にデータをストリームすることができる場合、サーバ装置１０４は、要求された１つ以上のメディアストリームを、ＴＣＰではなくＵＤＰを使用したストリーミングに切り換え、クライアント装置１０２は、その１つ以上のメディアストリームを受信し、ＵＤＰを使用して受信したその１つ以上のメディアストリームを処理する（動作３１２）。通常、サーバ装置１０４は、クライアント装置１０２から送信されたＵＤＰへの切り換えを求める要求（例えば、Ｓｅｌｅｃｔ要求）に応じて、要求された１つ以上のメディアストリームを、ＴＣＰではなくＵＤＰを使用したストリームすることに切り換える。さらに、すべてのストリームを、ＵＤＰを使用したストリーミングに切り換える必要はないことに留意されたい。そうではなく、クライアント装置１０２は、特定の１つまたは複数のメディアストリームだけをＵＤＰを使用したストリーミングに切り換えて、１つまたは複数の他のメディアストリームはＴＣＰを使用してストリームし続けるよう要求することができる。

本明細書に記載の高速起動は、予測スタート技術および／または配信チャネル切り換え技術を含むことができる。上記の図３および４は、予測スタート技術の実施形態を説明する。上記の図５および６は、配信チャネル切り換え技術の実施形態を説明する。

図７は、予測スタートおよび配信チャネル切り換えの両方を含めて、高速起動プロセス３５０の一例を示す流れ図である。図７は、クライアント装置１０２（例えば、図１、２および５）とサーバ装置１０４（例えば、図１、２および５）の両方によって実行される動作を示す。

最初に、クライアント装置１０２は、予測再生要求をサーバ装置１０４に送信する（動作３５２）。サーバ装置１０４は、予測再生要求を受信し、クライアント装置１０２が望む１つ以上のメディアストリームを予測する（動作３５４）。サーバ装置１０４は次いで、ＴＣＰを使用した、クライアント装置１０２への予測された１つ以上のメディアストリームのストリーミングを開始する（動作３５６）。

クライアント装置１０２とサーバ装置１０４の間のリンクは次いで、ＵＤＰを使用してデータをサーバ装置１０４からクライアント装置１０２にストリームすることができるか否かを判定するために、プローブされる（動作３５８）。このプロービングが、ＵＤＰを使用してデータをサーバ装置１０４からクライアント装置１０２にストリームすることができることを示す場合、サーバ装置１０４は、ＴＣＰではなくＵＤＰを使用した１つ以上のメディアストリームのストリーミングに切り換え（動作３６０）、そうでない場合、サーバ装置１０４は、ＴＣＰを使用した１つ以上のメディアストリームのストリーミングに進む。通常、サーバ装置１０４は、ＵＤＰへの切り換えを要求するクライアント装置１０２から送信される要求（例えば、Ｓｅｌｅｃｔ要求）に応じて、要求された１つ以上のメディアストリームをＴＣＰではなくＵＤＰを使用したストリーミングに切り換える。さらに、すべてのストリームが、ＵＤＰを使用したストリーミングに切り換えられる必要はないということに留意されたい。そうではなく、クライアント装置１０２は、特定の１つまたは複数のメディアストリームだけをＵＤＰを使用したストリーミングに切り換えて、１つまたは複数の他のメディアストリームはＴＣＰを使用してストリームし続けるよう要求することができる。

さらに、ＴＣＰを使用した、予測された１つ以上のメディアストリームのストリーミングが動作３５６で開始された後、クライアント装置１０２は、その予測された１つ以上のメディアストリーム以外の１つ以上のメディアストリームを望むか否かを判定する（動作３６２）。望む場合、（予測されたメディアストリームに加えて、かつ／またはそれらの代わりに）予測された１つ以上のメディアストリーム以外の１つまたは複数のメディアストリームが選択され、クライアント装置１０２は、１つ以上の選択されたメディアストリームの指示をサーバ装置１０４に送信する（動作３６４）。サーバ装置１０４は、クライアント装置１０２からこの指示を受信し、１つ以上の選択されたメディアストリームをクライアント装置１０２にストリームする（動作３６６）。

動作３６０でストリーム中の１つ以上のメディアストリームは、動作３５４で予測された１つ以上のメディアストリーム、および／または動作３６４で選択された１つ以上のメディアストリームを含むことができるということに留意されたい。動作３６０でストリーム中の１つ以上のメディアストリームは、動作３５４で予測された１つ以上のメディアストリームであり、かつ／または動作３６４で選択された１つ以上のメディアストリームであるかは、１つ以上のメディアストリームが動作３６４で選択されたか否か、並びに動作３６０の切り換え前または後に、動作３６６で選択された１つ以上のメディアストリームのストリーミングをサーバ１０４が開始するか否かにより異なる。

ある実施形態では、動作３５８および３６０の配信チャネル切り換えは、動作３６２、３６４および３６６のメディアストリーム選択と同時に実行される。別の実施形態では、動作３５８および３６０の配信チャネル切り換えは、動作３６２、３６４および３６６のメディアストリーム選択の後、または前に実行することができる。

図８は、本明細書に記載の技術を実施するために使用することのできる、汎用コンピュータ環境４００を示す。コンピュータ環境４００は、コンピューティング環境の一例に過ぎず、コンピュータおよびネットワークアーキテクチャの用途または機能の範囲に関して、いかなる制限をも示唆することを意図するものではない。また、コンピュータ環境４００は、コンピュータ環境４００例に示されるどの構成要素、またはそれら構成要素のどのような組み合わせにも、依存せず、もしくはこれらを必要とはしない。

コンピュータ環境４００は、コンピュータ４０２の形式の汎用コンピューティング装置を含む。コンピュータ４０２は、例えば、図１、２、３および５のクライアント装置１０２またはサーバ装置１０４であってよい。コンピュータ４０２は、マルチメディア公開のソースであるエンコーダ装置であってもよい。コンピュータ４０２の構成要素は、限定ではないが、１つまたは複数のプロセッサまたは処理装置４０４、システムメモリ４０６、およびプロセッサ４０４を含めて様々なシステム構成要素をシステムメモリ４０６に結合するシステムバス４０８を含むことができる。

システムバス４０８は、メモリバスまたはメモリコントローラ、周辺バス、加速グラフィックスポート、および様々なバスアーキテクチャのどれかを使用するプロセッサまたはローカルバスを含めて、各種バス構造のどれか１つまたは複数を表す。一例として、このようなアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子標準協会（ＶＥＳＡ）ローカルバス、およびＭｅｚｚａｎｉｎｅバスとしても知られる周辺装置相互接続（ＰＣＩ）バスを含むことができる。

コンピュータ４０２は、通常、様々なコンピュータ可読媒体を含む。このような媒体は、コンピュータ４０２によってアクセス可能ないかなる入手可能な媒体であってもよく、揮発性および不揮発性媒体と、取り外し可能および取り外し不可能な媒体の両方を含む。

システムメモリ４０６は、ランダムアクセスメモリ（ＲＡＭ）４１０のような揮発性メモリ、および／または読み出し専用メモリ（ＲＯＭ）４１２のような不揮発性メモリの形式のコンピュータ可読媒体を含む。基本入出力システム（ＢＩＯＳ）４１４は、起動時などにコンピュータ４０２内の素子間での情報転送に役立つ基本ルーチンを含み、ＲＯＭ ４１２に記憶される。ＲＡＭ ４１０は、通常、処理装置４０４によって直接アクセス可能、かつ／または現在処理装置４０４による操作を受けている、データおよび／またはプログラムモジュールを含む。

コンピュータ４０２は、他の取り外し可能／取り外し不可能な、揮発性／不揮発性コンピュータ記憶媒体も含むことができる。一例として、図８は、取り外し不可能な不揮発性磁気媒体（図示せず）から読み取り／に書き込むためのハードディスクドライブ４１６、取り外し可能な不揮発性磁気ディスク４２０（例えば、「フロッピーフロッピー（登録商標）ディスク」）から読み取り／に書き込むための磁気ディスクディスクドライブ４１８、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭまたは他の光媒体のような取り外し可能な不揮発性光ディスク４２４から読み取り／に書き込むための光ディスクドライブ４２２を示す。ハードディスクドライブ４１６、磁気ディスクドライブ４１８および光ディスクドライブ４２２は、それぞれに１つまたは複数のデータ媒体インターフェース４２６によってシステムバス４０８に接続される。あるいは、ハードディスクドライブ４１６、磁気ディスクドライブ４１８および光ディスクドライブ４２２は、１つまたは複数のインターフェースによってシステムバス４０８（図示せず）に接続することができる。

ディスクドライブおよびそれらの関連付けられたコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの不揮発性記憶域をコンピュータ４０２に提供する。この例は、ハードディスク４１６、取り外し可能な磁気ディスク４２０、および取り外し可能な光ディスク４２４を示しているが、磁気カセットまたは他の磁気記憶装置、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光記憶ストレージ、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、電子的消去可能および書込み可能な読み出し専用メモリ（ＥＥＰＲＯＭ）などのような、コンピュータによってアクセス可能な、データを記憶することのできる他のタイプのコンピュータ可読媒体も、このコンピュータシステムおよび環境の例を実施するために使用することができることを理解されたい。

ハードディスク４１６、磁気ディスク４２０、光ディスク４２４、ＲＯＭ ４１２および／またはＲＡＭ ４１０に、一例としてオペレーティングシステム４２６、１つまたは複数のアプリケーションプログラム４２８、他のプログラムモジュールおよびプログラムデータ４２３を含めて、プログラムモジュールをいくつでも記憶することができる。このようなオペレーティングシステム４２６、１つまたは複数のアプリケーションプログラム４２８、他のプログラムモジュール４３０、およびプログラムデータ４３２（またはそれらの組み合わせ）のそれぞれは、分散型ファイルシステムをサポートする常駐構成要素のすべてまたは一部を実施することができる。

ユーザは、キーボード４３４およびポインティング装置４３６（例えば、「マウス」）のような入力装置を介してコマンドおよび情報をコンピュータ４０２に入力することができる。他の入力装置４３８（特に図示せず）は、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送用受信アンテナ、シリアルポート、スキャナなどを含むことができる。これらまたは他の入力装置は、システムバス４０８に結合された入出力インターフェース４４０を介して処理装置４０４に接続されるが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）のような他のインターフェースおよびバス構造によって接続することもできる。

モニタ４４２または他のタイプの表示装置も、ビデオアダプタ４４４のようなインターフェースを介してシステムバス４０８に接続することができる。モニタ４４２に加え、他の出力周辺装置は、入出力インターフェース４４０を介してコンピュータ４０２に接続することのできるスピーカー（図示せず）およびプリンタ４４６のような構成要素を含むことができる。

コンピュータ４０２は、遠隔コンピューティング装置４４８のような１つまたは複数の遠隔コンピュータに対する論理接続を使用して、ネットワーク接続環境で動作することができる。一例として、遠隔コンピューティング装置４４８は、パーソナルコンピュータ、ポータブルコンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイスまたは他の共通ネットワークノードなどであってよい。遠隔コンピューティング装置４４８は、コンピュータ４０２に関して本明細書に記載した要素および特徴の多くまたはすべてを含むことのできる、ポータブルコンピュータとして示されている。

コンピュータ４０２と遠隔コンピュータ４４８の間の論理接続を、ローカルエリアネットワーク（ＬＡＮ）４５０および汎用広域ネットワーク（ＷＡＮ）４５２として示す。このようなネットワーク接続環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、およびインターネットでは一般的なものである。

ＬＡＮネットワーク接続環境で実施される場合、コンピュータ４０２は、ネットワークインターフェースまたはアダプタ４５４を介してローカルネットワーク４５０に接続される。ＷＡＮネットワーク接続環境で実施される場合、コンピュータ４０２は、通常、モデム４５６または広域ネットワーク４５２を介して通信を確立するための他の手段を含む。コンピュータ４０２に内蔵であっても外付けであってもよいモデム４５６は、入出力インターフェース４４０または他の適切な機構を介してシステムバス４０８に接続することができる。図示したネットワーク接続は一例であり、コンピュータ４０２と４４８の間に１つ以上の通信リンクを確立する他の手段を利用することができるということを理解されたい。

コンピューティング環境４００により示したようなネットワーク接続環境では、コンピュータ４０２に関して示したプログラムモジュールまたはその一部を、遠隔メモリストレージ装置に記憶することができる。一例として、遠隔アプリケーションプログラム４５８は、遠隔コンピュータ４４８のメモリデバイスに常駐する。説明のために、アプリケーションプログラムと、オペレーティングシステムのような他の実行可能なプログラム構成要素とを、本明細書では別々のブロックで示したが、このようなプログラムおよび構成要素は、コンピューティング装置４０２の様々な記憶構成要素に様々な時点で常駐し、コンピュータの１つ以上のデータプロセッサによって実行される。

様々なモジュールおよび技術は、本明細書では、１つまたは複数のコンピュータまたは他のデバイスによって実行される、プログラムモジュールのようなコンピュータ実行可能命令の一般的な状況で説明する場合がある。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データタイプを実施する、ルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。通常、プログラムモジュールの機能は、様々な実施形態で所望に応じ、組み合わせても分散してもよい。

これらのモジュールおよび技術の実施態様は、コンピュータ可読媒体のいくつかの形式に亘って記憶され、または送信されることができる。コンピュータ可読媒体は、コンピュータによってアクセス可能な、いかなる入手可能な媒体であってもよい。限定ではなく一例として、コンピュータ可読媒体は、「コンピュータ記憶媒体」および「通信媒体」を含むことができる。

「コンピュータ記憶媒体」は、コンピュータ可読命令、データ構造、プログラムモジュールまたは他のデータのような情報の記憶のために、いかなる方法または技術でも実施される、揮発性および不揮発性の取り外し可能および取り外し不可能な媒体を含む。コンピュータ記憶媒体は、限定ではないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気記憶装置、または所望の情報を記憶するために使用することができ、コンピュータによりアクセス可能ないかなる他の媒体をも含む。

「通信媒体」は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波または他の転送機構のような変調されたデータ信号形式の他のデータを実施する。通信媒体は、いかなる情報配信媒体をも含む。「変調されたデータ信号」という用語は、その文字セットの１つまたは複数を有するか、または情報を信号に符号化するような方法で変更された信号を意味する。限定ではなく一例として、通信媒体は、有線ネットワークまたは直接配線接続のような有線媒体と、アコースティック、ＲＦ、赤外線および他の無線媒体のような無線媒体とを含む。上記のどれとどれの組み合わせでも、コンピュータ可読媒体の範囲に含まれる。

上記の説明は構造上の特徴および／または方法上の動作に特有の用語を使用するが、首記の特許請求の範囲で定義される本発明は、記載した具体的な特徴または動作に限定されないことを理解されたい。むしろ、これら具体的な特徴および動作は、本発明を実施する形式の一例として開示されている。

本明細書に記載の、メディアをストリーミングするための高速起動をサポートするネットワーク環境例を示す図である。 本明細書に記載の、メディアをストリーミングするための高速起動を使用してメディアコンテントをストリームすることのできる、クライアント装置とサーバ装置の例を示す図である。 クライアント装置およびサーバ装置と予測スタート技術を、さらに詳細に示すブロック図である。 予測スタートプロセスの一例を示す流れ図である。 クライアント装置およびサーバ装置と配信チャネル切り換えプロセスの例を、さらに詳細に示すブロック図である。 配信チャネル切り換えプロセスの一例を示す流れ図である。 予測スタートと配信チャネル切り換えの両方を含めて、高速起動プロセスの一例を示す流れ図である。 本明細書に記載の技術を実施するために使用することのできる、汎用コンピュータ環境を示す図である。

Claims (43)

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. クライアント装置からサーバ装置に、予測再生要求を送信するステップと、
    前記サーバ装置で、前記予測再生要求に応じて、前記クライアント装置が望む１つまたは複数のメディアストリームを予測するステップと、
    前記サーバ装置から前記クライアント装置に、少なくとも前記予測された１つまたは複数のメディアストリームをストリーミングするステップと、
    前記クライアント装置で、前記予測された１つまたは複数のメディアストリームと異なる少なくとも１つのメディアストリームが、前記クライアント装置にストリーミングするように選択されるか否かを判定するステップと、
    前記予測された１つまたは複数のメディアストリームと異なる前記少なくとも１つのメディアストリームが、前記クライアント装置にストリーミングするように選択された場合、前記選択された少なくとも１つのメディアストリームの指示を前記サーバ装置に送信し、前記サーバ装置から前記クライアント装置に、前記予測された１つまたは複数のメディアストリームの少なくとも１つではなく、前記選択された少なくとも１つのメディアストリームをストリームするステップと、
    ＴＣＰ（伝送制御プロトコル）を使用して前記サーバ装置から前記クライアント装置に対する前記１つまたは複数のメディアストリームのストリーミングを開始するステップと、
    前記サーバ装置から前記クライアント装置に前記１つまたは複数のメディアストリームをストリーミング中に、ＵＤＰ（ユーザデータグラムプロトコル）を使用して前記サーバ装置から前記クライアント装置にデータをストリームすることができるか否かをプローブするステップと、
    前記プロービングが、ＵＤＰを使用して前記サーバ装置から前記クライアント装置にデータをストリームすることができることを示す場合、前記１つまたは複数のメディアストリームのストリーミングを、前記サーバ装置から前記クライアント装置に対するＵＤＰを使用したストリーミングに切り換え、そうでない場合、ＴＣＰを使用して前記サーバ装置から前記クライアント装置に前記１つまたは複数のメディアストリームをストリームし続けるステップと
    を含むことを特徴とする方法。
    

Images