JP2008187723A - コンテンツのストリーミングに使用するための改善された起動方法および装置 - Google Patents

Abstract

【課題】エンドユーザが体験する起動時間を大幅に短縮させることができる改善されたストリーミングメディアの方法および装置を提供する。
【解決手段】サーバ装置からクライアント装置に対してメディアコンテンツを送信する方法。当該方法は、（ａ）クライアント装置による起動要求によってメディアコンテンツを前記サーバ装置が送信可能か否かを判定するステップと、（ｂ）ステップ（ａ）の結果が肯定的なものである場合に、クライアント装置が、メディアコンテンツを送信するための通信条件のパラメータ値を決定するステップと、（ｃ）高速起動によってメディアコンテンツを送信する起動要求を送信するステップと、（ｄ）起動要求に応答して、サーバ装置からクライアント装置に対して高速起動によってメディアコンテンツを送信するステップとを含み、この起動要求は、クライアント装置からサーバ装置へのパラメータの値がステップ（ｂ）において決定されるパラメータを含む。
【選択図】図２

Description

本発明は、概してストリーミングメディア装置に関し、より詳細には、コンテンツをストリーミングする際に改善されたエンドユーザ起動時間を提供するための方法および装置に関する。

本出願は、「Ｆａｓｔ Ｄｙｎａｍｉｃ Ｍｅａｓｕｒｅｍｅｎｔ ｏｆ Ｃｏｎｎｅｃｔｉｏｎ Ｂａｎｄｗｉｄｔｈ」と題する同時係属の米国特許出願第０９／６３６，００４号（２０００年８月９日提出）に関連しており、参照により本明細書に組み込むものとする。

今日、ほとんどすべてのコンピュータユーザはテレビ放送メディアに十分に慣れている。新たなテレビジョンチャンネルを要求すると、一般的にその新たなチャンネルが極めて迅速に表示される（レンダリングされる）。従来のラジオ放送局に対しても同じことが言える。

しかしながら、従来型のインターネットストリーミング対象コンテンツではこの同じことが言えない。ストリーミングメディアは、典型的には、インターネットやその他同様のネットワークを介してサーバ装置からクライアント装置に提供される。さまざまな技術的理由のため、こうしたエンドユーザの体験は、たとえば、レンダリングにおけるデータの到着遅れ／再送信により体験されるようなポーズにより格下げとなっている可能性がある。しかし、こうしたポーズはランダムに起きる傾向にあり、またある種の構成では極めて稀にしか起こらない。しかし、ほとんどのエンドユーザがストリーミングメディアプログラムを選択するたびごとに体験しているようなポーズ、すなわち起動時間の遅れ、がある。

この不首尾な起動の体験により、ストリーミングメディアの多くの市場分野での採用が抑制される傾向にある。さらに、エンドユーザはこのテクノロジーを使用したいと考える時間の長さを短縮させる傾向にある。したがって、チャンネルの「サーフィン（surfing）」は、従来のストリーミング技法ではほとんど受容しがたいものである。

米国特許出願第０９／６３６，００４号明細書

このため、エンドユーザが体験する起動時間を大幅に短縮させることができる改善されたストリーミングメディアの方法および装置が必要とされている。

本発明のある態様によれば、エンドユーザが体験する起動時間を大幅に短縮させた改善されたストリーミングメディアの方法および装置を提供する。

一例として、上述の必要性その他は、本発明のある種の実施態様に従ったシステムにより満足される。このシステムは、通信リンクを介して動作可能に接続されたクライアント装置とサーバ装置を含んでいる。クライアント装置は、通信リンクを介してサーバ装置に少なくとも１つの起動要求を送信するように構成されている。この起動要求は、クライアント装置に提供されるストリーミング可能なメディアコンテンツ、この通信リンクと関連付けられた通信リンクバンド幅、および符号化ビットレートを超えるビットレートであるがほぼ該通信リンクバンド幅を超えないようにして提供される所望のストリーミング可能なメディアコンテンツの量を識別させている。サーバ装置は、少なくとも該量のストリーミング可能なメディアコンテンツをバッファリングし、かつ該量のバッファリングしたストリーミング可能なメディアコンテンツをこれより大きなビットレートで送信するように構成されている。該量のバッファリングしたストリーミング可能なメディアコンテンツを送信した後、サーバ装置は、ストリーミング可能なメディアコンテンツの後続する部分を符号化ビットレートとほぼ等しいビットレートでクライアント装置に送信する。クライアント装置は受信したストリーミング可能なメディアコンテンツをバッファリングすること、およびこのバッファリングしたストリーミング対象メディアコンテンツを引き続きレンダリングすること、を行うように構成されている。

ある種の実施態様によれば、そのサーバ装置は、該量のバッファリングしたストリーミング可能なメディアコンテンツ内で離散的レンダリング点を位置特定し、かつこの離散的レンダリング点を始点とする送信を開始する。

ある種の別の実施態様によれば、クライアント装置によりその通信リンクバンド幅が決定される。

本発明のさまざまな方法および装置は、添付の図面に関連して取り上げている以下の詳細な説明を参照することによってさらに完全に理解されよう。

図面を見ると、同じ参照番号は同じ要素を表しており、本発明を適当なコンピュータ環境で実施されるようにして図示している。必須ではないが、本発明の各種部分を、コンピュータその他同様の装置（たとえば、パーソナルコンピュータ（ＰＣ）、ワークステーション、ポータブル式コンピュータ、サーバ、複数のプロセッサ、メインフレームコンピュータ、ワイヤレス通信基地局、ハンドへルド型通信デバイス、ストリーミング対象メディアプレーヤ、セットトップボックス、などの形態をとることができる）により実行されるような、プログラムモジュールなどコンピュータ実行可能な命令に関する概括的コンテクストで記述している。

一般に、プログラムモジュールは、特定のタスクを実行するかまたは特定の抽象的データタイプを実施させているような、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含んでいる。本発明のさまざまな例示的な実施態様はまた、通信ネットワークを介してリンクさせたリモート処理装置によりタスクを実行させている分散型コンピュータ環境で実施することもできる。分散型コンピュータ環境では、プログラムモジュールをローカルとリモートの両方のメモリ記憶デバイス内に配置することができる。

本明細書で用いる際には、「ロジック（logic）」という語は、たとえば、ソフトウェア、ファームウェア、ハードウェアおよび／またはこれらの任意の組合せを含む任意の形態のロジックおよび必要なサポート要素に当てはめるとする意図である。

図１は、適当なコンピュータ環境１２０の一例を表しており、引き続き記載する方法および装置の各部分はこの環境上で実施することができる。

例示的なコンピュータ環境１２０は、適当なコンピュータ環境の単なる一例に過ぎず、本明細書に記載した改善された方法および装置の使用や機能性の範囲に対する限定の示唆を意図するものでは全くない。さらにまた、コンピュータ環境１２０は、コンピュータ環境１２０で図示している任意の一構成要素または構成要素の任意の組合せに関連する任意の依存関係や要件を有するものと解釈すべきでもない。

本明細書に示す改善された方法および装置は、その他多くの汎用型および／または専用型コンピュータのシステム環境または構成を用いて使用可能である。

図１に示すように、コンピュータ環境１２０は、コンピュータ１３０の形態をした汎用コンピュータ装置を含んでいる。コンピュータ１３０の構成要素には、１つまたは複数のプロセッサまたは処理装置１３２、システムメモリ１３４、およびシステムメモリ１３４を含めさまざまなシステムコンポーネントをプロセッサ１３２と結合させているバス１３６を含むことがある。

バス１３６は、メモリバスまたはメモリコントローラ、周辺バス、高速グラフィックス（accelerated graphics）ポート、およびさまざまなバスアーキテクチャの任意のものを用いたプロセッサまたはローカルバスを含め、任意の幾つかのタイプのバス構造のうちの１つまたは複数個を表している。限定ではなく一例として、こうしたアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャンネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ベザ（Video Electronics Standards Association：ＶＥＳＡ）ローカルバス、およびメザニン（Mezzanine）バスとも呼ばれる周辺コンポーネント相互接続（ＰＣＩ）バスが含まれる。

コンピュータ１３０は、典型的にはさまざまなコンピュータ可読メディアを含む。こうしたメディアは、コンピュータ１３０がアクセスできる利用可能な任意のメディアとすることができ、またこうしたメディアには、揮発性および不揮発性の両メディア、取外し可能なメディアおよび取外し不可能なメディアが含まれる。

図１では、システムメモリ１３４は、ランダムアクセスメモリ（ＲＡＭ）１４０などの揮発性メモリ、および／または読出し専用メモリ（ＲＯＭ）１３８などの不揮発メモリの形態をしたコンピュータ可読メディアを含んでいる。基本入出力システム（ＢＩＯＳ）１４２は（たとえば、起動時における）コンピュータ１３０内の構成要素間での情報の転送を支援する基本ルーチンを含んでおり、ＲＯＭ１３８内に格納されている。ＲＡＭ１４０は、典型的には、プロセッサ１３２により即座にアクセスできる、かつ／またはプロセッサ１３２による現在の動作の基本となっているような、データおよび／またはプログラムモジュールを含んでいる。

コンピュータ１３０はさらに、取外し可能／取外し不可能で、揮発性／不揮発性のその他のコンピュータ記憶メディアを含むことができる。たとえば、図１は、取外し不可能で不揮発性の磁気メディアに対する読出しと書込みをするためのハードディスクドライブ１４４（図示せず、典型的には「ハードドライブ（hard drive）」と呼ぶ）と、取外し可能で不揮発性の磁気ディスク１４８に対する読出しと書込みをするための磁気ディスクドライブ１４６（たとえば、「フロッピー（登録商標）ディスク」）と、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭあるいはその他の光学メディアなど取外し可能で不揮発性の光ディスク１５２に対する読出しや書込みをするための光ディスクドライブ１５０とを図示している。ハードディスクドライブ１４４、磁気ディスクドライブ１４６、および光ディスクドライブ１５０はそれぞれ、１つまたは複数のインタフェース１５４によりバス１３６に接続されている。

ドライブ類や関連するコンピュータ可読メディアにより、コンピュータ読取り可能な命令、データ構造、プログラムモジュール、およびその他のデータに対する不揮発性記憶がコンピュータ１３０に提供される。本明細書に記載した例示的な環境は、ハードディスク、取外し可能な磁気ディスク１４８および取外し可能な光ディスク１５２を利用しているが、当業者であれば、磁気カセット、フラッシュメモリカード、ディジタル式ビデオディスク、ランダムアクセス記憶装置（ＲＡＭ）、読取り専用記憶装置（ＲＯＭ）、その他など、コンピュータによりアクセス可能なデータを格納することができる別の種類のコンピュータ可読メディアもこの例示的な動作環境で使用できることを理解することとなろう。

ハードディスク、磁気ディスク１４８、光ディスク１５２、ＲＯＭ１３８、またはＲＡＭ１４０には、たとえば、オペレーティングシステム１５８、１つまたは複数のアプリケーションプログラム１６０、その他のプログラムモジュール１６２、およびプログラムデータ１６４を含めいくつかのプログラムモジュールを格納することができる。

本明細書に記載した改善された方法および装置は、オペレーティングシステム１５８、１つまたは複数のアプリケーションプログラム１６０、その他のプログラムモジュール１６２、および／またはプログラムデータ１６４内で実施することができる。

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

さらに、モニタ１７２やその他の種類のディスプレイ装置は、ビデオアダプタ１７４などのインタフェースを介してバス１３６と接続されている。モニタ１７２のほかに、パーソナルコンピュータは、典型的には、出力周辺インタフェース１７５を介して接続することができるスピーカやプリンタなどその他の周辺出力装置（図示せず）を含んでいる。

コンピュータ１３０は、リモートコンピュータ１８２など１つまたは複数のリモートコンピュータとの論理接続を用いてネットワーク環境で動作させることができる。リモートコンピュータ１８２は、コンピュータ１３０に関して本明細書に記載した要素および特徴のうちの多くまたはすべてを含むことができる。

図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７７および一般のワイドエリアネットワーク（ＷＡＮ）１７９である。こうしたネットワーク環境は、オフィス、全企業規模のコンピュータネットワーク、イントラネット、インターネットにおいてごく一般的である。

ＬＡＮネットワーク環境で使用する場合、コンピュータ１３０はネットワークインタフェースまたはアダプタ１８６を介してＬＡＮ１７７に接続されている。ＷＡＮネットワーク環境で使用する場合、そのコンピュータは、典型的には、モデム１７８、またはＷＡＮ１７９を介して通信を確立するためのその他の手段、を含んでいる。モデム１７８は、内蔵の場合や外付けの場合があるが、ユーザ入力インタフェース１７０やその他の適当な機構を介してシステムバス１３６と接続させることができる。

図１には、インターネットを介したＷＡＮの具体的な実施態様を表している。図１では、コンピュータ１３０は、インターネット１８０を介して少なくとも１つのリモートコンピュータ１８２との通信を確立させるためにモデム１７８を利用している。

ネットワーク環境では、コンピュータ１３０に関して表したプログラムモジュール、またはその一部分は、遠隔のメモリ記憶デバイス内に格納することができる。したがって、たとえば図１に示すように、リモートアプリケーションプログラム１８９はリモートコンピュータ１８２のメモリ装置上に置くことができる。図示しかつ説明しているネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する別の手段も使用できることを理解されたい。

ここで、ネットワーク２０４に動作可能に結合されると共に、そこから同じくネットワーク２０４に動作可能に結合されているクライアント装置２０６までメディアをストリーミングさせるように構成されているサーバ装置２０２を有している例示的なストリーミングメディアシステム２００の１つを表している図２を参照する。

ストリーミングメディアシステム２００は、クライアント中心の構成で配置されており、この配置において、クライアント装置２０６はサーバ装置２０２上のストリーミングメディアプログラムを選択し、ある具体的な高速起動を所望することを指定し、かつストリーミングメディアを搬送するための通信リンクに関する情報をサーバ装置２０２に提供している。この方式により、クライアント装置２０６はストリーミングメディア処理およびサーバ装置２０２を制御することができる。より詳細には以下で記載するが、ストリーミングメディアを制御する際に、クライアント装置２０６はサーバ装置２０２に対して、最初の時間期間中にそのメディアの符号化ビットレートを超えるデータビットレートでメディアをストリーミングさせている。これにより、クライアント装置２０６はデータを迅速に受信して、より早くレンダリング処理を開始することが可能となる。

このことは、たとえば、Ｎａｔｈａｎｉｅｌ Ｐｏｌｉｓｈに対して公布された米国特許第５，９６３，２０２号に提示されているシステムおよび方法などビデオオンデマンドを提供するために使用される従来のサーバ中心のソリューションではなかったことである。こうしたサーバ中心のシステムでは、クライアント装置ではなくサーバ装置がビデオデータ転送を制御している。したがって、たとえば、サーバは、その通信リンクを介してどれだけの量のビデオデータを転送できるのか、および累進的ダウンロード（progressive download）の間のどの時点で転送をすべきであるかを判定することが必要となる。サーバ中心のシステムの欠点のうちの１つは、各クライアント装置ごとに、そのクライアント装置内の通信リンクおよびデータバッファの状態をサーバにより監視する必要があることである。累進的ビデオダウンロード技法は家庭内やホテルのビデオオンデマンドシステムのためには効果的であることもあるが、この技法は、たとえば、インターネット、企業内イントラネット、ワイドエリアネットワーク、ワイヤレスネットワークなど、さらに大きなネットワーク環境では恐らく非効率と判定されることとなろう。

図２に戻ると、図示したように、サーバ２０２はメディアサーバ２０８を含んでいる。メディアサーバ２０８は、高速起動ロジック２１０を含むと共に、バッファ２１２に動作可能に結合されている。図示のように、この例では、メディアサーバは、メディア記憶デバイス２１６へのアクセスを提供している第１のインタフェース２１４に動作可能に結合されている。メディアサーバ２０８はさらに、放送メディア装置２２０（ビデオカメラで表している）へのアクセスを提供している第２のインタフェース２１８に動作可能に結合されている。メディアサーバ２０８は第３のインタフェース２２２を介してネットワーク２０４に動作可能に結合されている。別の実施態様では、インタフェース２１４、２１８および／または２２２を何らかの方法で組み合わせることがあることを理解されたい。

その名称が示唆するように、メディアサーバ２０８は、クライアント装置２０６にストリーミングメディアを処理するか、さもなければ提供するように構成されている。このタスクを達成させるには、メディアサーバ２０８はインタフェース２２２およびネットワーク２０４を介してクライアント装置２０６と情報をやり取りしている。サーバ装置２０２とクライアント装置２０６の間で通信を提供するために使用する技法およびプロトコルはよく知られており、したがって、詳細に至るまで記載していない。

メディアサーバ２０８はストリーミングメディアプログラムのクライアント装置２０６への利用可能性を識別する。この例では、メディアサーバ２０８は、２つのソースからの、すなわちメディア記憶デバイス２１６と放送メディア装置２２０からの、ストリーミングメディアプログラムにアクセスし／受け取っている。メディア記憶デバイス２１６は、たとえば、１つまたは複数の磁気ディスクドライブ、１つまたは複数の光ディスクドライブ、その他などのデータ記憶デバイスを表している。ここで、メディア記憶デバイス２１６は、メディアサーバ２０８がメディアを「オンデマンドで」クライアント装置２０６にストリーミングできるように構成されている。本明細書で使用する場合、「オンデマンド（on-demand）」とは、そのメディアがメディア記憶デバイス２１６内に格納され、それ以降ストリーミングで利用可能の状態となり後続の時刻において再生できることを意味している。したがって、たとえば、以前のニュースプログラムはメディア記憶デバイス２１６上にその全体を記録かつ格納しておき、引き続いてオンデマンドで利用可能とすることができる。

これと反対に、放送メディア装置２２０は、大量には格納されておらず、その全体が格納されていないことが確実なメディアを表している。一例として、リアルタイムまたは概してリアルタイムで放送されているニュースプログラムが挙げられる。したがって、こうしたメディアプログラムはオンデマンドで利用可能とはならない。クライアント装置２０６がこの放送メディアのストリームを選択した場合には、ストリーミングメディアはニュースプログラム内でほぼ放送中にある点に「ジャンプ（jump）」することになる。

バッファ２１２は、メディアサーバ２０８がストリーミング処理の支援のためにメディアデータを一時的に格納するために使用している。バッファ２０８は、典型的には、ランダムアクセスメモリを含むことになる。

図のように、クライアント装置２０６はメディアクライアント２２４を含んでいる。メディアクライアント２２４は、インタフェース２３２およびネットワーク２０４を介したサーバ装置２０２からのストリーミングメディアの選択、受信、およびレンダリングを支援するように構成されている。このタスクをさらに達成させるために、メディアクライアント２２４は高速起動ロジック２２６およびレンダリング装置２２８を含んでいる。メディアクライアント２２４はさらに、バッファ２３０に動作可能に結合されている。バッファ２３０は、典型的には、ランダムアクセスメモリを含んでいる。レンダリング装置２２８は、ストリーミング対象メディアデータを処理すること、およびこのデータをクライアント装置２０６や受信したメディアで適用可能となるようにレンダリングするように構成されている。レンダリング処理はよく知られており、この詳細については本発明の範囲を超えている。

この例示的なストリーミングメディアシステムを念頭に置きながら、ここで、この詳細な説明はメディアクライアント２２４、およびサーバ装置２０２内の高速起動ロジック２１０および対応するクライアント装置２０６内の高速起動ロジック２２６の機能に焦点を当てることにする。

メディアクライアント２２４では、さまざまな理由からストリーミングデータのバッファリングが必要となる。たとえば、バッファリングによりクライアント装置２０６は、コンテンツのパケットが紛失したときに連続再生に影響を与えることなく再送の要求および首尾よい取得が可能となる。バッファリングによりさらに、ジッタを有していたり、バンド幅レスポンスが一貫していないようなネットワーク上での再生をスムーズにすることができる。極めて高効率の圧縮テクノロジーでは、復元を開始できるようになるまでに、クライアント上にかなりの長さのコンテンツ（たとえば、１つのフレーム全体または複数のフレーム全体）を存在させることが必要となることが多い。こうした問題点のすべてが、メディアクライアント２２４によりコンテンツをバッファリングする必要性に寄与している。

圧縮テクノロジーおよびコンテンツの種類に応じて、バッファリングは１秒未満から数十秒までのいずれにも変更することができる。従来のある種のメディアプレーヤでは、たとえば、コンテンツの概して５秒分をバッファリングしてからレンダリングの開始が可能となる。従来のストリーミングメディアサーバはコンテンツを符号化ビットレートで伝達するように設計されているため、エンドユーザはバッファを満たしてレンダリングを開始するのに少なくとも５秒間待つ必要がある。

ほとんどのクライアント装置では接続したときに放送メディアがすでに起動しているのが典型的であるため、クライアント装置は、バッファリング処理の開始前でさえ待機を要することがある。たとえば、現在使用されている典型的な圧縮テクノロジーでは、そのストリーム内のある離散点でバッファリングを開始することが必要である。クライアント装置が個別に従来の放送ストリームに加入している場合、そのクライアント装置はバッファリング処理の開始前であってもストリームの形で現れるのをこうした離散点のうちの１つで待機することが必要となる。離散点の頻度は、使用する圧縮テクノロジー、コンテンツの種類、またさらにコンテンツの特性に応じて劇的に変動することがある。こうした離散的なバッファリング点の頻度は、１秒当たり数回から１６秒以下の各秒数ごとに一度程度まで変動することがある。

従来のストリーミングメディアクライアントが先ず離散的エントリー点を発見するために待機し、次いでバッファが満たされるために待機しなければならないとすると、ストリーミングメディア放送をレンダリングしようと試みる際にユーザはかなりの遅延を体験することが多い。本発明のある種の態様では、クライアント装置のバッファ（複数のこともある）を満たすのに要する時間を大幅に短縮させ、かつ最終的に放送およびオンデマンドの両方のコンテンツでレンダリングを高速で開始できる傾向にあるような方法および装置を提供する。したがって、たとえば、ある例示的な実施態様では、利用可能な追加のネットワークバンド幅を利用してコンテンツのストリーミングを加速させ、これに応じてクライアント装置のバッファ（複数のこともある）をより高速で満たしている。このことから、「高速起動（fast startup）」という用語となる。

本発明のある種の態様では、たとえば、マイクロソフトメディアサーバ（ＭＭＳ）、リアルタイムストリーミングプロトコル（ＲＴＳＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、その他など従来のストリーミングプロトコルの用法／シンタックスを拡張することにより、さまざまな高速起動の方法および装置を実施することができる。

参照により本明細書に組み込む「Ｆａｓｔ Ｄｙｎａｍｉｃ Ｍｅａｓｕｒｅｍｅｎｔ ｏｆ Ｃｏｎｎｅｃｔｉｏｎ Ｂａｎｄｗｉｄｔｈ」と題する同時係属の米国特許出願第０９／６３６，００４号（２０００年８月９日提出）には、ストリーミングメディアの実際の送達を要求する前にメディアクライアント２２４によりクライアント装置２０６とサーバ装置２０２の間に存在するバンド幅を決定することができるような技法についてより詳細に記載されている。このバンド幅はリンクバンド幅という名称で知られている。

基本的には、接続バンド幅の高速で動的な計測では、単一のパケット対を利用してクライアント装置２０６とサーバ装置２０２の間のバンド幅を計算している。この計算は、パケット対（packet-pair）技法に基づいている。このバンド幅計測は極めて迅速である。パケットがネットワーク２０４を横切る行程において、通信装置とモデムはパケットを圧縮することがある。この圧縮によりパケットのサイズが小さくなり、このためこうした縮小したパケットを用いたバンド幅計算は歪みを受けることがある。この歪みを回避するため、この接続バンド幅に対する高速で動的な計測では、圧縮不可能なパケットを利用している。より具体的には、この計測は極めてエントロピックなパケットを利用している。したがって、パケットをその行程の途中で圧縮することはできない。さらに、パケットがネットワーク２０４を横切る行程において、パケットには、ルート変更（reroute）、遅延、ルート誤り（misroute）、その他が起きることがある。これら時々刻々の遅延のために時々刻々のバンド幅計算が不良となることがある。この問題は、メディアクライアント２２４の位置において最新の計測値を追尾している履歴リスト（図示せず）を用いることにより改善される。次いで、メディアクライアント２２４は、履歴リストからその中央値を決定することができる。この中央値がリンクバンド幅を表している。

これはリンクバンド幅を決定するための例示的な一技法を表したものである。当業者であれば、他の技法を用いてもリンクバンド幅をある程度の確実性で決定することができることを理解するであろう。

メディアクライアント２２４はたとえば、セッション記述プロトコル（ＳＤＰ）など従来のプロトコルを用いてメディアサーバ２０８との通信および利用可能なストリーミングメディアの所在および特性を識別することができる。

したがってこの方式により、メディアクライアント２２４は、リンクバンド幅と、そのストリーミングメディアプログラム内の個々のストリーム（複数のストリームのこともある）のバンド幅を決定することができる。したがって、メディアクライアント２２４内の高速起動ロジック２２６は、初めにそのコンテンツの符号化ビットレートと比べてより速いレートでコンテンツをストリーミングすることを要求することができる。この高速起動の要求は、メディアサーバ２０８の高速起動ロジック２１０により処理されている。

再生速度が通常であると仮定すると、コンテンツを符号化ビットレートを超えるレートでストリーミングすることは、クライアントバッファ２３０内のデータ量の大きさが時間の経過に伴って増加することを意味する。バッファ２３０のメモリ量が限定されていると、そのコンテンツの符号化ビットレートと比べてより速いレートでコンテンツを無期限にストリーミングすることは望ましくない。その代わり、クライアントのバッファ２３０はストリーミング処理の開始時点での高速レートで十分に満たされ、引き続きこのストリーミングレートはメディアプログラム（ファイル）の符号化ビットレートに概して一致するように変更される。この設計は、追加のリンクバンド幅を利用してバッファ２３０に追加のメモリを必要とせずにクライアントバッファ２３０が迅速に満たされるという恩恵を有している。

メディアサーバ２０８内にある高速起動ロジック２１０は、コンテンツをより高速レートでストリーミングすることにより高速起動要求に応じるように構成されている。生中継ビデオフィードなどの放送メディアの場合では、高速起動ロジック２１０はストリーミング放送メディアの一部を一時的にサーババッファ２１２に格納する。この方式では、サーバ装置２０２に新たなクライアント装置を接続させた場合に、その放送ストリームの符号化ビットレートを超えるレートでコンテンツパケットの送信を受けることができる。

したがって、たとえばある実施態様で、そのコンテンツが１６ｋｂｐｓで符号化されているとすると、高速起動ロジック２１０は放送メディアの直前の１０秒分をバッファ２１２内に格納することになる。したがって、この例示的なバッファリング処理では、２０キロバイトのメモリが必要となる。このため、放送が開始となった後で接続したクライアント装置は、１６ｋｂｐｓと比べてかなり速いレートで概して最大約１０秒分のコンテンツを要求することができる。

これは単に一例に過ぎず、別の実施態様では、そのバッファリング処理で、バッファ２１２内に格納する放送メディアの量はより長いことやより短いことがある。

起動ロジック２１０はさらに、新たなクライアントを放送に接続した際にバッファ２１２からのコンテンツパケットの送信をどこから開始すべきかをインテリジェントに決定するように構成されている。たとえば、放送プログラムが進行中であり、かつ新たなクライアントをサーバ２０２に接続すると仮定してみる。起動ロジック２１０によりバッファ２１２内に直前の１０秒分のコンテンツがバッファリング済みであるとすると、高速起動ロジック２１０は、理論的には、ＣｏｎｎｅｃｔＴｉｍｅ_clientX−１０からＣｏｎｎｅｃｔＴｉｍｅ_clientXまでの時間から概して任意の時点でコンテンツの送信を開始することが可能である。

しかし、コンテンツのストリーミングを１０秒バッファの先頭の時点で開始することは、メディアクライアント２２４が必要とする離散的開始点がＣｏｎｎｅｃｔＴｉｍｅ_clientX−１０の時点にあるコンテンツに含まれないことがあるため問題となる可能性がある。典型的には、ある種のストリーミング対象コンテンツでは、メディアクライアント２２４は、たとえば、ある種のフレーム境界や「キーフレーム」などストリーミング対象データ内の離散点でしかコンテンツのレンダリングを開始することができない。一例として、ＭＰＥＧストリームでは、Ｉフレームはキーフレームであるが、Ｐフレームはキーフレームではない。別の例として、２つのキーフレーム３０２と複数のその他のフレーム３０４とを含んだメディアストリームの一部分３００を模式的に表している図３を参照してみる。図のように、キーフレーム３０２同士の間に長いレンダリング時間期間３０６を設けることができる。

このため、起動ロジック２１０は、バッファリングしたコンテンツを選択的にスキャンして、新たなクライアント装置に対するストリーミング処理を開始させるべき離散点の位置特定、および／またはさもなければ識別／追尾をするように、有利に構成されている。この離散点はバッファ２１２内の最も初めにある離散点とすることが好ましい。

伝搬待ち時間がバッファリングしたリストからのコンテンツの送信開始時点を決定するための別のファクタである。本質的には古い（すなわち、バッファリングしてある）コンテンツを新たなクライアント装置に送信しており、かつそのイベントが実況中継放送であることがあるため、時間シフトを導入している。高速起動ロジック２１０（および、メディアサーバ２０８）によりもたらされるこの時間シフトの大きさは、実施済みのバッファリング量、および新たなクライアント装置に送信するコンテンツに関して選択した開始点と関連を持つ。

クライアントは放送中の任意の時点でランダムに接続を行うことができ、またこの例で用いている１０秒バッファリストは「滝（waterfall）」や「引窓（sliding window）」に類似するようにして絶えず変化している。したがって、符号化ビットレートを超えるレート、およびコンテンツ送信用の開始点で送信されるコンテンツの量は、時間の経過に伴って変動することになる。さらに、各クライアント装置は異なるリンクバンド幅を有するため、加速させた送信レートも変動することがある。各クライアント装置では、クライアント側バッファの設定値が異なることさえあり得る。これらのファクタのすべてから、クライアント装置はレンダリング処理の間に同期しないことになることが含意される。

サーバ２０２に接続するクライアント装置が利用可能な追加のネットワークバンド幅を十分に有していない場合は、コンテンツバッファリスト内で利用可能な最も初めにある点の送信では、具体的な当該クライアント装置に対する伝搬待ち時間が不必要に増加することがある。したがって、サーバ装置２０２は（さらに詳細には高速起動ロジック２１０は）、起動時間を最小とする必要と伝搬時間を最小とする必要とを「バランスさせる」ように構成されている。たとえば、伝搬待ち時間と起動待ち時間を最小にするという対立する要件をバランスさせるのを手助けするため、次式と同様のロジックを利用することができる。
ＡｃｃｅｌＤｕｒａｔｉｏｎ＝ＲｅｑｕｅｓｔｅｄＡｃｃｅｌＤｕｒａｔｉｏｎ−（ＡｃｃｅｌＲａｔｅ＊ＲｅｑｕｅｓｔｅｄＡｃｃｅｌＤｕｒａｔｉｏｎ）

ＲｅｑｕｅｓｔｅｄＡｃｃｅｌＤｕｒａｔｉｏｎ：要求される加速期間
ＡｃｃｅｌＲａｔｅ：（コンテンツの符号化ビットレート）／（リンクバンド幅）の比
ＡｃｃｅｌＤｕｒａｔｉｏｎ：サーババッファから送信されるコンテンツ量

上の例示的ロジックでは、そのコンテンツの符号化ビットレートが利用可能なリンクバンド幅に近づくにつれて、サーババッファ２１２から送信される「タイムシフトさせた」コンテンツの量は本質的には低下する。

オンデマンドコンテンツでは、高速起動ロジック２１０は、クライアント装置２０６を接続したときに既存のバッファがないこと以外は、その放送台本と同様に構成される。したがって、高速起動ロジック２１０はバッファリストを迅速に構築して高速起動要求を満足させる。典型的なメディア記憶デバイス２１６ではクライアント装置２０６が要求しているものと比べてより高速のレートでオンデマンドコンテンツを転送することができるためにこのことが可能となる。

ある例示的な実施態様では、加速バッファリングを要求するためにクライアント装置２０６により使用される実際のプロトコル機構でヘッダの使用が不可欠である。一例として、ＲＴＳＰプロトコルでは、ヘッダ「Ｘ−Ａｃｃｅｌｅｒａｔｅ−Ｓｔｒｅａｍｉｎｇ」を規定し、これをＰＬＡＹコマンドと共に使用する。このヘッダは、加速の持続時間に対するクライアント要求および加速のために使用するバンド幅に関する情報を含んでいる。たとえば、典型的な「Ｘ−Ａｃｃｅｌｅｒａｔｅ−Ｓｔｒｅａｍｉｎｇ」ヘッダにはクライアントが「ＡｃｃｅｌＤｕｒａｔｉｏｎ＝１００００；ＡｃｃｅｌＢａｎｄｗｉｄｔｈ＝１０４８５７６」を含めていることがある。これにより、クライアントが１，０４８，５７６ビット毎秒のレートで加速された１０，０００ｍｓ分のコンテンツを得ることを希望する旨がサーバに伝達される。

ＨＴＴＰプロトコルでは、たとえば、クライアントの高速起動ロジック２２６はＧＥＴコマンド内で通常用いられるＰＲＡＧＭＡヘッダにおいて高速起動パラメータを指定するための指示文を利用することができる。下記のテキストは、高速起動を要求するＧＥＴ要求内のサンプルＰＲＡＧＭＡヘッダのコンテンツを表している。

「ＬｉｎｋＢＷ＝２１４７４８３６４７、ＡｃｃｅｌＢＷ＝１０４８５７６、ＡｃｃｅｌＤｕｒａｔｉｏｎ＝１００００」
この例示的な要求では、クライアント側の高速起動ロジック２２６はサーバ側の高速起動ロジック２１０に対して、そのリンクバンド幅が２，１４７，４８３，６４７ビット毎秒であるが、１０，０００ｍｓの持続時間にわたって１，０４８，５７６ビット毎秒のレートで加速されたコンテンツを希望しているのみであることを伝達している。

ここで、クライアント装置２０６で使用するのに適当な処理４００を表している流れ図である図４を参照する。ステップ４０２において、メディアクライアント２２４はメディアサーバ２０８に接続される。ステップ４０４において、高速起動ロジック２２６は、たとえば上述のようにしてリンクバンド幅を決定する。ステップ４０６において、メディアクライアント２２４はメディアサーバ２０８に対して、個々のコンテンツストリームのバンド幅を含め、利用できるストリーミング可能なコンテンツに関する情報を要求する。

ステップ４０８において、高速起動ロジック２２６は高速起動ロジック２１０にストリーミング可能なコンテンツを要求する。ステップ４１０において、高速起動ロジック２２６は最初に高速ストリーミングビットレート、さらに続いてより低速なストリーミングビットレートを選択する。高速起動ロジック２２６はさらに、最初の高速ストリーミングビットレートで送信されることになるストリーミング対象メディアの量を決定する。

たとえば、バッファ２３０の設定値、リンクバンド幅、およびコンテンツの符号化ビットレートに基づいて、高速起動ロジック２２６はバッファ２３０を迅速に満たすためにコンテンツ送信の加速要求を提出すべきか否かを判定することができる。クライアント装置２０６が高速起動を要求することに決定した場合は、サーバ装置２０２からのコンテンツの転送を開始させる最後のコマンドにカスタムヘッダシンタックスを付加することができる。

その後、ステップ４１０において、メディアクライアント２２４はメディアサーバ２０８からのストリーミング対象コンテンツの受信を開始する。ステップ４１２において、そのコンテンツの先頭部分は、符号化ビットレートを超える最初のより高速なストリーミングビットレートで受信される。続いて、ステップ４１４において、ストリーミング対象コンテンツの次の部分が符号化ビットレートにほぼ等しいより低速なストリーミングビットレートで受信される。

ここで、サーバ装置２０２で使用するのに適当な処理５００を表している流れ図である図５を参照する。ステップ５０２において、メディアサーバ２０８はクライアント接続要求を処理し、クライアントによるストリーミング可能なコンテンツに関する情報の要求に応答する。ステップ５０４において、高速起動ロジック２１０はストリーミングメディアを高速起動させるようにとのクライアント装置２０６から受信した要求に応答する。ステップ５０６において、要求されたストリーミング可能なコンテンツがオンデマンドコンテンツであれば、高速起動ロジック２１０は、メディア記憶デバイス２１６から必要なコンテンツを取り込むことによりその高速起動要求を満足させることを試みる。

別法として、要求されたストリーミング可能なコンテンツが放送コンテンツを含む場合には、ステップ５０８においてコンテンツは、高速起動ロジック２１０は高速起動ロジック２２６から受け取った高速起動パラメータを用いて、その放送コンテンツのどの点でバッファ２１２からのストリーミングを開始できるかを決定している。可能である場合、高速起動ロジック２１０は、バッファリスト内の離散的開始点でストリーミングを開始し、メディアクライアント２２４が有用なコンテンツパケットを直ちにバッファリングを開始できるようにすることが好ましい。

次に、ステップ５１０において、高速起動ロジック２１０は、適用可能なコンテンツを、先ずはより高速のストリーミングビットレートでストリーミングし、続いて、ステップ５１２において、より低速のストリーミングビットレートでストリーミングする。

ここで、要求された高速起動によるストリーミングメディアプログラムに関連付けられた例示的な送信ビットレート値６０２を表している時間軸グラフ６００である図６を参照する。時刻ｔ₀において、クライアント装置２０６はストリーミングメディアプログラムを要求する。これに応答して、サーバ装置２０２はバッファリングしたコンテンツのアクセスを開始する。時刻ｔ₁において、サーバ装置２０２は高速ストリーミングビットレートでコンテンツの送信を開始する。この例では、概して時刻ｔ₂において、クライアント装置２０６はそのコンテンツのレンダリングを開始するのに十分なストリーミング対象メディアの受信およびバッファリングを終えている。時刻ｔ₃において、サーバ装置２０２はクライアント装置２０６が要求した高速起動データの要求量を転送し終えている。したがって、ストリーミングビットレートはほぼ符号化ビットレートまで低下される。

たとえば、クライアント装置のリンクバンド幅が約７００ｋｂｐｓであっても、コンテンツパケットが通常約５６ｋｂｐｓの固定レートでストリーミングされるものと仮定してみる。上述した高速起動の状況では、要求に応じて、そのメディアの最初の約１０秒間を含んだコンテンツパケットは概してリンクバンド幅レートでストリーミングすることができる。この時点で、これに概して０．８秒の時間がかかっていることになる。その後、残りのコンテンツパケットをより低速の符号化ビットレートでストリーミングする。

この例では、その一巡時間が持続時間内で適度に短ければ、メディアサーバ２０８は、要求が出された後概して０．１秒で高速起動ストリームを開始させることになる。メディアクライアント２２４は最初の要求に続く約０．５秒の時点で約５秒間分のストリーミングメディアプログラムを受信し終えていることになり、ほぼ当該時点でレンダリングを開始することができる。要求される１０秒間分の高速起動ストリーミング対象メディアは、最初の要求に続く約０．９秒の時点で受信し終えていることになる。この時点で、レンダリング装置２２８は約０．４秒間分のコンテンツをレンダリングし終えていることになり、また、約９．６秒間分のコンテンツがバッファ２３０内に格納されていることになる。

したがって、この例では、その起動時間が５秒以上から約１秒未満まで短縮された。さらに、クライアント装置２０６は約１０秒間分のバッファリングしたコンテンツを保持することが可能となる。この追加のバッファリングによりクライアント装置２０６は、たとえばジッタやその他ネットワークの一時的休止（brownout）の潜在的な延長などによる短いポーズを回避することができる。

本発明のさまざまな方法および装置に関するいくつかの好ましい実施態様について添付の図面で図示すると共に上述した詳細な説明において説明したが、本発明は開示した例示的な実施態様に限定されるものではなく、むしろ特許請求の範囲に列挙し規定した本発明の精神を逸脱することなく多くの配置変更、修正および代替が可能であることを理解されたい。

本発明のいくつかの実施態様による、ストリーミング対象メディアの提供、受信、および／または、さもなければ通信に使用するのに適した、コンピュータの形態をした例示的装置を表したブロック図である。 本発明のいくつかの実施態様による、サーバ装置およびクライアント装置を有する例示的なストリーミングメディアシステムを表したブロック図である。 本発明のいくつかの実施態様による、図２のストリーミングメディアシステムでのストリーミングに適した例示的なコンテンツストリームを表した概要図である。 本発明のいくつかの実施態様による、図２のクライアント装置において使用するのに適した例示的なクライアント中心のメディアストリーミング処理の流れ図である。 本発明のいくつかの実施態様による、図２のサーバ装置において使用するのに適した例示的な高速起動メディアストリーミング処理の流れ図である。 本発明のいくつかの実施態様による、図２のストリーミングメディアシステムに関連付けられた例示的な高速起動ストリーミングメディア送信に関する送信データビットレートを表している時間軸図表である。

符号の説明

１２０ 適当なコンピュータ環境
１３０ コンピュータ
１３２ プロセッサ、処理装置
１３４ システムメモリ
１３６ バス
１３８ 読出し専用メモリ（ＲＯＭ）
１４０ ランダムアクセスメモリ（ＲＡＭ）
１４２ 基本入出力システム（ＢＩＯＳ）
１４４ ハードディスクドライブ
１４６ 磁気ディスクドライブ
１４８ 磁気ディスク
１５０ 光ディスクドライブ
１５２ 光ディスク
１５４ インタフェース
１５８ オペレーティングシステム
１６０ アプリケーションプログラム
１６２ その他のプログラムモジュール
１６４ プログラムデータ
１６６ キーボード
１６８ ポインティングデバイス
１７０ ユーザ入力インタフェース
１７２ モニタ
１７４ ビデオアダプタ
１７５ 出力周辺インタフェース
１７７ ローカルエリアネットワーク（ＬＡＮ）
１７８ モデム
１７９ ワイドエリアネットワーク（ＷＡＮ）
１８０ インターネット
１８２ リモートコンピュータ
１８６ ネットワークインタフェース、ネットワークアダプタ
１８９ リモートアプリケーションプログラム
２００ ストリーミングメディアシステム
２０２ サーバ装置
２０４ ネットワーク
２０６ クライアント装置
２０８ メディアサーバ
２１０ 高速起動ロジック
２１２ バッファ
２１４ 第１のインタフェース
２１６ メディア記憶デバイス
２１８ 第２のインタフェース
２２０ 放送メディア装置
２２２ インタフェース
２２４ メディアクライアント
２２６ 高速起動ロジック
２２８ レンダリング装置
２３０ バッファ

Claims (1)

1. サーバ装置からクライアント装置に対してメディアコンテンツを送信する方法であって、
   前記方法は、
   （ａ）前記クライアント装置による起動要求によって前記メディアコンテンツを前記サーバ装置が送信可能か否かを判定するステップと、
   （ｂ）前記ステップ（ａ）の結果が肯定的なものである場合に、前記クライアント装置が、前記メディアコンテンツを送信するための通信条件のパラメータ値を決定するステップと、
   （ｃ）高速起動によって前記メディアコンテンツを送信する前記起動要求を送信するステップと、
   （ｄ）前記起動要求に応答して、前記サーバ装置から前記クライアント装置に対して前記高速起動によって前記メディアコンテンツを送信するステップと
   を含み、
   前記起動要求は、前記クライアント装置から前記サーバ装置へのパラメータの値が前記ステップ（ｂ）において決定されるパラメータを含むことを特徴とする方法。

Images