メディアストリームから得られるメディアの提示を行う方法およびシステム
【課題】メディアストリームから得られるメディアの提示を行う方法およびシステムを提供する。
【解決手段】本明細書で説明する一実施形態は、新規のメディアストリームの迅速始動を容易にし、同時にその新規メディアストリームの提示の一時的な中断（すなわち、「スタッター」）を軽減するか、または実施形態によっては、それを回避する。本明細書に説明する少なくとも１つの実施形態は、マルチメディアストリームを利用者に提示するように構成された下流構成要素においてマルチメディアが受信されている速度を測定するとともに、少なくとも部分的には前記測定速度を使用して、受信マルチメディアを提示する前に、それをバッファリングするための持続時間を確認する。
【解決手段】本明細書で説明する一実施形態は、新規のメディアストリームの迅速始動を容易にし、同時にその新規メディアストリームの提示の一時的な中断（すなわち、「スタッター」）を軽減するか、または実施形態によっては、それを回避する。本明細書に説明する少なくとも１つの実施形態は、マルチメディアストリームを利用者に提示するように構成された下流構成要素においてマルチメディアが受信されている速度を測定するとともに、少なくとも部分的には前記測定速度を使用して、受信マルチメディアを提示する前に、それをバッファリングするための持続時間を確認する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般には、データ信号の伝送技術に関し、より詳細には、メディアストリームから得られるメディアの提示を行う方法およびシステムに関する。
【背景技術】
【０００２】
（導入）
ディジタルメディアストリーミング技術によって、利用者は、メディア送信装置などの遠隔位置から受信したディジタルメディアを見ることおよび／または聞くことができる。クライアント装置または受信装置の利用者は、見るためのファイルを選択することができる。代替選択肢として、利用者は、見るためのリアルタイムエンコーダからのデータを選択することができる。選択されたファイル／エンコーダからのメディアまたはデータは、メディアストリームとして受信装置に送り、そこでそれを再生するか、または別の方法で利用者に提示することができる。ファイルを選択するのには、様々なシナリオがある。例えば、利用者は、ウエブサイトのムービートレーラー（ｍｏｖｉｅ ｔｒａｉｌｅｒ）をチェックするか、またはインターネットプロバイダを介してＴＶを見ているときにチャネルを変えることができる。メディアは聴覚作用および視覚作用の両方を生成するデータを含むことが多いので、これは「マルチメディア」データまたはコンテンツと呼ぶことができる。
【０００３】
そのようなマルチメディアを正確に表すのに必要なデータ量のせいで、それは、クライアント装置に送られる前に、エンコーダにおいて圧縮、エンコードされることがある。提示のためにオリジナルメディアを再生するには、一般に、そのメディアは、提示される前に圧縮解除、デコードされる。エンコーダとデコーダとの両方にバッファーを使用して、コンテンツのビット率における変動性を補償することができる。プロセスは、リーキーバケット（ｌｅａｋｙ ｂｕｃｋｅｔ）モデルになぞらえられることがあり、その場合には、エンコーダはリーキーバケットを用いてエンコードを行っており、クライアント装置は、アンダーフローを回避するために、同等の大きさのバケツを有する。このことは、コンテンツのビット率にはいくぶん変動性があるために起こるものであり、バケツの大きさは、基本的には、ビット率の最大変動率の測度である。
【０００４】
（メディアストリームの伝送）
実際的な目的で、メディアストリームエンコーダからの音声および／またはビデオを運ぶメディアストリームは通常、連続的ではなく、複数の伝送パケットに分割されている。フォーマットによっては、そのようなパケットは、キーフレームとも呼ばれることのある、１つまたは複数のイントラフレームまたはＩフレームを含む。Ｉフレームは、過去または将来のフレームを参照することなく、単一画像としてエンコードされる。
【０００５】
（アンダーフロー）
受信装置においてデコード（または提示）すべきデータが不足すると、これは「アンダーフロー」と呼ばれる。アンダーフローは、受信装置は次のフレームをデコード（または提示）する準備ができているが、受信装置はそのフレームのデータのすべてをまだ受信（またはデコード）していないときに発生する。
【０００６】
アンダーフローの実際的で顕著な現れは、円滑に再生される動画ビデオとしての所望の効果ではない、動画ビデオ提示における一時的な中断（すなわち、「ヒッカップ（ｈｉｃｃｕｐ）」または「スタッター（ｓｔｕｔｔｅｒ）」）である。例えば、動画ビデオを固定周波数（例えば、１５フレーム／秒）で示すのではなく、アンダーフロー状態にある受信装置は、次のフレームまたはその後のフレームを表示する前に、目に見えてわかる遅延が続くビデオストリームのフレームを示すことになる。これは、数秒または数分間、続くことがある。
【０００７】
アンダーフローのための条件は、新規ファイルまたはエンコードコンテンツが選択されるとき、すなわちチャネルを変更するときに、特に機が熟する。受信装置が新規チャネルの入力メディアストリームを受信してデコードするや否や、すぐにフレームを提示する場合には、アンダーフロー条件が発生しやすい。
【０００８】
その代わりに、マルチメディアデータの提示を、クライアント側バッファーを充填するのに十分な時間だけ遅延させるのが一般的である。マルチメディアデータがデコードされ、提示されるときに、受信装置は、そのバッファーに格納されたデータを空にする。しかしながら、受信装置がデコードされたデータを提示する間に、さらなるエンコードデータがダウンロードされてバッファーが再充填される。バッファーが完全に空にならないように、データが再生されるのと少なくとも同じ速さでデータがダウンロードされる限り、ファイルは円滑に再生されるはずである。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
アンダーフローを防止するように設計された、上述の従来の方法は、利用者の選択と、その選択の利用者への実際の提示との間に煩わしい遅延を生成する可能性がある。
【００１０】
本明細書において説明する様々な実施形態は、メディアストリームから取得されるメディアを提示するための方法およびシステムを提供する。
【課題を解決するための手段】
【００１１】
本明細書において説明する、少なくとも１つの実施形態は、マルチメディアを利用者に提示するように構成された下流構成要素においてマルチメディアストリームが受信される速度（測定速度）を測定し、少なくとも部分的にその測定速度を使用して、受信マルチメディアをその提示の前にバッファリングするための持続時間（測定時間）を確認する。
【００１２】
同一の数字を、すべての図面を通して使用し、同一の要素および機能を参照する。
【発明を実施するための最良の形態】
【００１３】
（概観）
以下のシステムおよび方法は、スタッタリングを軽減しながら、同時にマルチメディア提示のバッファー遅延を減少させる。いくつかの実施形態では、提示のスタッタリングを完全に回避しながら、バッファリング遅延を低減することができる。送信装置は、選択されたファイルまたは生のエンコードセッションからのメディアをクライアント装置に流す（以下では、ファイルまたはセッション、あるいはその等価物を参照するのに「ソース（ｓｏｕｒｃｅ）」という用語を使用する）。「ストリーミング速度（ｓｔｒｅａｍｉｎｇ ｒａｔｅ）」という用語は、送信装置からクライアント装置にメディアを流す速度を識別するのに使用する。受信すると、クライアント装置は、その流されたメディアをクライアントまたは利用者にすぐさま、またはその後に提示することができる。データが提示のために使用される速度は、提示速度と呼ばれる。平均提示速度は、平均ストリーミング速度とほぼ等しくすることができるが、瞬時においては、ストリーミング速度と提示速度は異なっていてもよい。
【００１４】
メディアをストリーミングする前に、送信装置は、メディアに関係する助言データ（ａｄｖｉｓｏｒｙ ｄａｔａ）をクライアント装置に送る。助言データについて以下により詳細に説明するが、これには特に、送信装置がメディアを流す加速率（ａｃｃｅｌｅｒａｔｉｏｎ ｒａｔｅ）、加速間隔、様々なバッファー値、開始プロファイル、および／または推奨または推定バッファー持続時間（ｅｓｔｉｍａｔｅｄ ｂｕｆｆｅｒ ｄｕｒａｔｉｏｎ）などの様々な構成要素を含めることができる。加速率は、提示速度に対して表された、送信装置がデータを送ろうとするストリーミング速度であるか、または絶対値としてビット／秒またはバイト／秒で表すこともできる。送信装置は、提示速度の２倍（２×）などの加速率で、加速間隔と呼ばれる持続時間の間、ストリーミングを開始することができる。代表的な加速率しては、１０×、１２×、１５×、および３０×の範囲としてもよいが、これらは単に例示であり、送信装置および送信装置とクライアント装置の間のネットワークの特性に応じて、その他任意の値であってもよい。
【００１５】
クライアント装置は、提示中のアンダーフロー状態を避けるために、十分なデータを保持するためにデータをバッファリングすることができる。クライアント装置は、少なくとも２つの方法でバッファーにデータを追加することができる。第１には、クライアント装置は、マルチメディアの提示を開始する前に、最初にバッファリングをすることができる。そのような場合には、受信データのすべてがバッファリングされる。しかしながら、そのようなバッファリングは、始動遅延を生じる結果となり、始動遅延は、例えば、利用者が再生ボタンを押してから実際にマルチメディア提示を見るか、または聞くまでの間の期間である。第２に、クライアント装置は、メディアを提示する間の加速間隔中にバッファリングすることも可能であり、これは、クライアント装置は、データを提示するよりも高い速度でデータを受け取っているからである。後者の一例では、提示速度は、１メガビット／秒（Ｍｂｐｓ）とすることができる。送信装置は、加速間隔中に２×または２Ｍｂｐｓでメディアを流すことができる。クライアント装置は、加速間隔の持続時間中に、過剰データをバッファーに入れ、一方で同時にデータを提示に使用することができる。
【００１６】
助言データには、実装方法によっては、始動プロファイル（ｓｔａｒｔ−ｕｐ ｐｒｏｆｉｌｅ）（複数を含む）を含めることができる。一般に、始動プロファイルには、アンダーフローを避けるために、提示における１つまたは複数の時点において要求または推奨されるバッファー量に関係づけることができる。送信装置は、メディアストリームを送信する前に、推定始動プロファイルをコンパイルすることができる。様々な実装方法において、推定または最初の始動時間が計算され、これは推定加速率における始動プロファイルを満足する。始動時間は、クライアント装置がメディアストリームを受信し始めてからメディアを提示し始めるまでにクライアントが蓄積すべきバッファー量の測度である。バッファー量は、ビット単位または時間単位で測定することが可能であり、ここで時間の単位は、ビット値を平均ビット率で除した値である。
【００１７】
クライアント装置がメディアストリームを受信し始めると、始動時間を検証、または再計算することができる。いくつかの実施形態においては、始動時間またはバッファー持続時間を、クライアント装置がメディアストリームを受信する測定加速率を使用して、再計算することができる。加速間隔中にバッファリングされるデータの量の実際の測定値とともに、始動プロファイルを使用すると、より正確な、第２の、または測定された始動持続時間を計算することが可能となる。その他の実装方法では、単に測定加速率を使用して、マルチメディアの提示を開始する前に、推定始動持続時間の精度を検証することができる。
【００１８】
実装方法によっては、本方法は、測定加速率と先に推定された加速率を比較して、相応に動作することができる。比較によって、測定加速率が推定加速率よりも遅いことが分かった場合には、本方法では、バッファー時間を再計算して長くバッファリングすることができる。データが、推定速度を超える速度で受信される場合には、本方法はバッファー時間を短縮することができる。方法で計算される始動前バッファリングの量は、既存技術と比較して実質的に減少させることができる。始動プロファイルの再計算は、クライアントがデータを受信し始めた後、任意の時点で行うことできる。それは例えば、１００ｍｓの規則的な時間間隔で行ったり、または初期推定始動時間の一定割合で、例えば初期計算バッファー時間の５０％で行ったりすることもできる。
【００１９】
クライアント装置は、利用者へのファイルの提示に最も近いデバイスであり、言い換えると、クライアント装置は最下流のデバイスである。様々な遅延、ボトルネックおよび／またはその他のメディア経路に沿った介入条件の結果として、クライアント装置は、始動計算を行うのに上流構成要素よりも有利な位置にある。
【００２０】
その他の利点の中で、クライアント装置が、始動前にバッファリングする長さを決定することを可能にすることで、そうでなければ介入事象から生じる可能性のある、バッファー時間における不正確さを低減することができる。例えば、上流送信装置は、それがメディアをクライアント装置に流そうと意図する推定伝送速度に対する、バッファー持続時間を計算することができる。クライアント装置は、実際に、異なる速度、例えば高い速度または低い速度でメディアストリームを受信することができる。したがって、クライアント装置が行う計算は、送信装置において行われる計算よりも精度が高い。クライアンと装置は、それがデータを受信する速度について最も正確に見ることが可能であり、アンダーフローを避けるためにバッファリングしなくてはならない時間量を最も正確に計算することができる。
【００２１】
（例示的実施形態）
以下の説明は、添付の特許請求の範囲に記載された要素を組み入れた、メディアストリームから取得したメディアの提示のための方法およびシステムの１つまたは複数の例示的な実装方法を示す。これらの実装方法を、法的な書面による説明、機能付与、および最良の形態要件に合致するために、具体的に説明する。しかしながら、説明自体は、本発明の範囲を限定することを意図するものではない。
【００２２】
（メディアストリームのネットワークトポロジー）
図１および図１Ａは、例示的なメディアストリームのネットワークトポロジー１００の高いレベルの表現を例示しており、本明細書において説明する他の観点を（部分的にまたは完全に）実装することができる。
【００２３】
例示的なトポロジー１００は、サーバのような、１つまたは複数のメディアストリーム送信装置１１０を含み、これは、伝送手段１３０を介して受信装置またはクライアント装置１２０に通信可能に結合されている。受信装置１２０には、とりわけ、パーソナルコンピュータ（ＰＣ）、セル電話またはセットトップボックス（ｓｅｔ−ｔｏｐ ｂｏｘ）を含めることができる。実施形態においては、受信装置１２０は、さらに、表示スクリーンおよび１つまたは複数のスピーカーを含む、表示または提示デバイス１４０をさらに含む。送信装置の機能は、単一構成要素または複数の構成要素によって達成することが可能であり、同様にクライアント装置の機能は、単一構成要素または複数の構成要素によって達成することが可能である。
【００２４】
送信装置１１０は、受信装置１２０への伝送のための、ファイルなどのソースを格納すること、および／またはネットワーク１５０を介してソースにアクセスすることが可能である。様々な実施形態において、ネットワーク１５０は限定アクセスネットワークとするか、または他の構成の中で、インターネットを含めることができる。ネットワーク１５０は、送信装置１１０がアクセスするマルチメディアデータまたはコンテンツをエンコードおよび圧縮するための、エンコーダ１６０に結合してもよい。代替的に、送信装置１１０は、メディアを伝送手段１３０上でクライアント装置１２０に流す前にそれをエンコードすることが可能であり、クライアント装置１２０は、提示に先立って、そのメディアをデコードすることができる。
【００２５】
トポロジー１００は、利用者従事クライアント装置１２０が、提示のための、ファイルなどのソースを選択することを可能にする。クライアント装置１２０は、送信装置１１０にメディアをファイルからクライアント装置に流すことを要求することができる。伝送手段１３０には、イーサネット（登録商標）、ブロードバンド、ダイアルアップ、および無線などの任意適当な伝送手段を含めることができる。クライアント装置１２０および提示デバイス１４０は、ここでは異なる構成要素として説明してあるが、その他の実装方法では、それらの機能を単一装置に統合することができる。
【００２６】
（第１の例示的方法および実装）
図２は、メディアストリームから得られるメディアの提示のための一方法にかかる動作を表すフローチャートである。
【００２７】
動作２０２は、マルチメディアストリームを受信することを要求する。そのような要求は、クライアント装置上での選択として利用者が開始することができる。例えば、利用者は、ウエブブラウザ内のコンテンツをクリックするか、またはインターネットプロバイダ上でＴＶを見ている間にチャネルを切り替えることができる。要求は、単にファイルなどの選択されたソースを流すことであるか、またはもっと具体的にすることができる。例えば、要求は、選択されたファイルに２０秒入った位置で始まる１０秒の提示時間に対応するコンテンツを流すことである。要求によって、再生要求に対応するファイルが、例えば送信装置によってアクセスされるようにすることができる。
【００２８】
少なくとも部分的にソースにアクセスすることによって、ソースのデータの提示に対応する助言データを得ることができる。助言データには、最初にそのファイルを作成したプログラムによってファイルのヘッダー内に格納された情報を含めることができる。プログラムは、ファイルを試験して、ファイル内の任意の箇所に対する最大または推奨バッファー量を決定する。バッファーデータは、ファイルヘッダー中に書き込み、そこでは、そのバッファーデータに送信装置がアクセスすることができる。
【００２９】
送信装置は、単に助言データを収集して、それをクライアント装置に送ることができる。別の実装方法においては、送信装置は、バッファーデータなどの助言データの様々な構成要素を、それをクライアント装置に送る前に処理することができる。いくつかの例においては、送信装置は、それがクライアント装置に送る、１つまたは複数の推定始動プロファイルを計算する。始動プロファイルは、クライアント装置が提示の様々な時点で取得すべきデータの量に関係づけることができる。例えば、始動プロファイルには、アンダーフローの最大量、アンダーフローが発生する時間、およびアンダーフローを計算するのに使用される加速率を示す、１組の値を含めることができる。以下に説明するいくつかの実装方法においては、複数の加速率に関係するデータを、単一始動プロファイルに含めることができる。その他の実装方法では、個々の加速率に対する個別の始動プロファイルを生成することができる。
【００３０】
１つの実装方法において、始動プロファイルは、各提示時間におけるパケットサイズを加えることによって計算され、ファイルの提示中の様々な時間における提示要件が決定される。様々な具体的な加速率に基づいて、方法では、各提示時間における加速されたストリーミングのために受信しているはずであるデータ量の推定値を計算することができる。方法では、クライアントバッファーをアンダーフローさせること（データが不足すること）を避けるために、提示の開始に先立って、推定バッファー持続時間を提供することができる。
【００３１】
始動プロファイルには、様々な形態を含めることができる。一例においては、始動プロファイルはデータ配列を含む。配列要素は、特定の加速率に関係づけることができる。例えば、各加速率に対して、配列はアンダーフローバイト値と、アンダーフローが発生する時間とを含む。
【００３２】
いくつかの実施形態においては、始動プロファイルは、所与の加速率に対して、２つのバッファリング条件に関係する。第１のバッファリング条件は、ファイルの提示前の、推奨または推定バッファーサイズに関係する。第２のバッファリング条件は、加速間隔の終わりにおける推奨バッファーサイズに関係づけることができる。これらの２つの条件について、以下により詳細に説明する。
【００３３】
第１のバッファー条件は、クライアント装置が、各アンダーフロー時間によって、スタッタリングを低減および／または回避するのに適当なバイト数を少なくとも有するように、クライアント装置が初期にバッファリングすべき長さを計算するのに使用することができる。第２のバッファー条件は、クライアント装置が加速期間を終了するときに、それが提示における任意の時点に対する十分な量のバッファーを有することを保証するための、最悪バッファーシナリオの計算に関係する。最悪バッファーシナリオは、エンコードプロセスによって書き込まれたヘッダー値とすることができ、ヘッダー値は、クライアントが最悪事態またはコンテンツの最も「要処理（ａｃｔｉｏｎ）」な部分に対するアンダーフローを避けるために持つべき、推奨バッファー量を示す。第２の計算は、クライアント装置は、加速間隔中にそのバッファー量を増大させることだけに頼るべきであるという前提に基づいている。いくつかの実施形態においては、送信デバイスは、助言データに入れて、推奨バッファー量に関係するヘッダー値を送信する。その他の実施形態においては、送信デバイスは、助言データの一部として、加速間隔の終わりまでに達成すべきクライアントデバイスに対する推奨全バッファー値を、特に提供することができる。
【００３４】
そのような実施形態においては、方法により、クライアント装置が加速間隔から出る前に達成すべき、全提示に対して十分なバッファリングされたデータ量を決定する。クライアント装置がストリーミングメディアの受信を続けるときに、新規データは、もちろんのこと、提示中にバッファーに追加されるが、新規データは、データが提示のためにデコードされる速度に近い速度で追加される。したがって、全バッファーサイズは、大幅に増加することを当てにすべきではない。方法の実施形態では、送信装置がメディアを流そうとする推定加速率において、これらの２つのバッファー値を満足するために、提示前のバッファー持続時間が計算される。
【００３５】
さらに別の実装においては、送信装置は、バッファー計算を実施して、単に、クライアント装置がバッファリングすべき時間量に対する単一の値をクライアント装置に渡してもよい。代替手法として、送信装置は、異なる加速率に対するバッファー時間の配列をクライアント装置に渡し、クライアント装置は、単にそれ自体の測定加速率に最も近い時間を選ぶか、またはより正確な値を補間することができる。当業者であれば、これらは、その構成要素がアルゴリズム（複数を含む）を実行する例にすぎないことを認識するはずである。例えば、いくつかの実施形態においては、計算の大部分または全部を、送信装置によって実行することができる。さらに別の実装においては、計算の大部分または全部をクライアント装置で実行することができる。
【００３６】
（例示的送信装置のアルゴリズム）
一実施形態において、送信装置が使用する例示的アルゴリズムのより詳細な例について説明する。アルゴリズムは、様々なクライアント要求によって機能するように構成されている。そのような一例においては、クライアントは、ＴＶプログラムなどのすでに実行中の放送公開点に参加することを要求する。別のそのような例においては、クライアントは、ウエブサイト上で参照することのできるオンデマンド公開点からのファイルを再生することを要求する。
【００３７】
放送公開点例に対して、方法では、それがクライアント装置に流すメディアの開始点となるＩフレームを発見する。以下のアルゴリズムは、クライアント装置に送信されるデータの組、すなわちそのＩフレームから前方に作用する。前記オンデマンド例においては、計算は、提示における第１のパケットから単に開始される。代替的には、利用者は、ファイル内の任意の箇所を探索することができる。その場合には、方法は、その探索箇所に近いＩフレームを発見して、その箇所からデータの送信を開始する。計算は、そのＩフレームから開始される。
【００３８】
リアルタイムエンコードコンテンツの場合には、クライアント装置に流される実際のファイルはない。しかしながら、送信装置は、ある量のリアルタイムコンテンツをバッファーに入れて、そのバッファーからのデータをクライアント装置に送信することができる。そのバッファーは、始動プロファイルの目的に対して、論理的には、多くの点においてファイルと同等である。そのバッファーは円形方式で配設してもよく、その場合には、新規データが追加されると、古いデータは終点から削除される。リアルタイムエンコードコンテンツに対して、送信装置からクライアント装置への加速を与えるためには、送信装置は、単に、バッファリングされた量の一部を、実際の再生速度よりも迅速にクライアントに送信する。
【００３９】
特定の実施形態においては、送信装置は、一般に、メディアストリームの特定の期間にわたってクライアント装置バッファー要求におけるピークを発見するのに使用される、プロファイリングプロセスを実行する。特定の実施形態では、先のパケットサイズを合計することによって、各提示時間に対するデータが計算される。あらゆる特定の提示に対するデータは、短い提示時間を有するパケット全部の合計である。値は、クライアント装置が、アンダーフローを避けるために保有すべきデータの量の測度である。
【００４０】
実施形態においては、ストリームの平均ビット率が、その時点までにクライアント装置に送られたバイト数、すなわち提示時間をとって、それを送信時間における差で除することによって計算される。この値は、局所的な実際平均ビット率であって、それは、ストリームの複数部分に対してファイルヘッダーに記憶されている平均ビット率値とは異なる可能性がある。特定の実施形態では、この値は試験されているファイルの部分に対して精度が高いので、ファイルヘッダーからの平均値ではなく、この値が使用される。
【００４１】
実施形態では、上述の計算された平均値を使用して、同一の提示時間値においてクライアント装置に送信される、ストリームデータの量が計算される。方法では、いくつかの加速率に対して計算を行うことができる。
【００４２】
実施形態では、各間隔におけるクライアントバッファーの推定過剰量を、各加速率に対して、第１の数から第２の数を差し引くこと（必要データ−ストリームデータ）によって計算することができる。この数が負である限り、クラアントには、それが必要とするより大量のデータが流され、クライアントがアンダーフローすることがないことになる。しかしながら、この値が提示におけるいずれかの時点において正である場合には、クライアント装置においてアンダーフロー条件が存在することになる。
【００４３】
また、方法では、各加速率に対して、クライアントバッファーの最大アンダーフロー値および最大アンダーフローが発生する提示時間を追跡する。クライアントのバッファー要求が最大になる、提示時間における位置は、加速率が変化するときに変る可能性がある。そのような環境において、方法では、いくつかの加速率においてアンダーフロー値が計算される。
【００４４】
これによって、各加速率に対して、データ量などの１つのアンダーフロー値およびそのアンダーフロー値の提示時間が与えられる。アンダーフロー値は、各加速率に対して異なることが多いが、この理由は、データがクライアントに配布される速度は、異なる加速率のために相異することになるからである。しかしながら、各アンダーフローに対する提示時間値は、いくつかの加速率に対して同一であるか、またはそれは異なっている可能性がある。推定データ配信対時間曲線の形状に応じて、加速率が異なると、異なる時間にアンダーフローを生ずる可能性がある。
【００４５】
実施形態では、次いで、これらの計算されたアンダーフローバッファー値およびそれらが発生する時間、それらを計算するのに使用される加速率、および提示におけるその時点までの平均ビット率を、クライアント装置に送信することができる。いくつかの場合には、上述のコンパイルされた助言データは、クライアント装置に、そのクライアント装置のための始動プロファイルとして送信することが可能であり、始動プロファイルは、送信装置によって計算される推定バッファー持続時間を含む。例えば、送信装置は、１つまたは複数の加速率に対して使用されるバッファーの量を送信してもよく、その１つは、送信装置がデータを流そうとする推定加速率としてもよい。少なくとも部分的にバッファーデータに基づいて、続いてクライアント装置は、以下により詳細に示すように、その加速率をより正確に知ることによって、使用する最適の値を、補間またはその他の方法で計算することができる。その他の実施形態では、その計算のさらに多くの部分を送信装置によって行うことができる。例えば、送信装置は、それがクライアント装置に送信したデータ量を監視し、次いでクライアントに信号を送って、バッファリングを終了して提示を始めることもできる。
【００４６】
そのような始動プロファイルの一例を以下に示す。
【００４７】
【表１】
【００４８】
動作２０４では、マルチメディアストリームに関係する助言データを受信する。上述のように、助言データは、１つまたは複数の加速率における始動プロファイルと関係づけることが可能であり、始動プロファイルは、送信装置が使用することが可能であるとともに、ネットワーク自体が送信装置とクライアント装置との間の達成可能なビット率における限定要因であるので、仲介ネットワークまたは伝送手段によってサポートされている。
【００４９】
以下に示すのは、どの機能がそれぞれのデバイスによってサポートされているかを伝えるために、送信装置およびクライアント装置が使用するヘッダーの一例である。特定の例においては、送信装置およびクライアント装置は、以下のように始動プロファイル（複数を含む）の形態で助言データをサポートすることができる。
Supported:com.microsoft.wm.startupprofile
【００５０】
いくつかの実施形態においては、クライアント装置が、いくらかの対話能力またはアルゴリズム能力を有し、助言データに基づいて、送信装置を制御することが可能となる。例えば、クライアント装置は、加速率および助言データに基づく加速間隔を選択して、それに応じてメディアを流すことを送信装置に要求してもよい。別の例においては、送信装置は、加速率を決定することができるが、クライアント装置は加速間隔を要求することができるようにすることができる。以下により詳細に述べるように、任意の加速率において、クライアント装置は、加速間隔の終点におけるフルバッファー値による追加の始動ディスプレイを避けるための、送信装置の加速の長さを計算することができる。したがって、助言データ、特に送信装置からの推定加速率を受信すると、クライアント装置は、対応する加速間隔を計算して要求することができる。代替的に、クライアント装置は、実際に助言データを受信する前に、対応する加速間隔を計算して要求することができる。クライアント装置は、メディアストリームを受信するための最初の要求中に、要求加速間隔を送信装置に渡すことができる。
【００５１】
その他の実施形態において、送信装置は、クライアント装置に対する遅延処理なしにメディアストリームに関する決定を行うことができる。そのような一実施形態においては、送信装置は、単に、助言データ内で、推定加速率および加速間隔をクライアントに通知して、メディアを流す。ここで留意すべきことは、ネットワークトポロジーによっては、加速間隔は、送信装置によって正確に制御可能であるのに対して、加速率は、仲介ネットワークの特性とともに、送信装置が送信する速度に依存することである。
【００５２】
助言データが推定加速率およびその結果として得られる推定バッファー持続時間を含む場合には、方法は、動作２０６に進むことができる。代替的あるいは追加的に、クライアント装置は、動作２０６に進む前に、推定加速率および／または対応する推定バッファー持続時間を決定してもよい。例えば、クライアント装置は、将来ストリームの加速率をパケット対またはランタイムパケット対を使用して推定することができる。別の例においては、クライアントは、"?wmbitrate=xxx"などのＵＲＬ修飾子を介して推定速度を決定することができる。
【００５３】
推定バッファー持続時間を計算する一例は、以下のシナリオに見ることができる。この場合に、加速間隔は１０秒であり、平均提示速度は１０Ｍｂｐｓであり、最悪バッファー需要は２．５メガビットのデータである。推定加速率は３Ｍｂｐｓである。したがって、ストリーミングが始まるとすぐに再生が行われる場合には、２．０メガビットのデータを加速間隔中にバッファリングすることが可能であり、提示に先立って０．５メガビットをバッファリングすることが必要と思われる。しかしながら、再生の前にいくらかのバッファリングがあるので、クライアントは、再生が開始してから丸１秒間は加速を受けないが、その理由は、その加速時間の一部は、再生が開始される前にバッファリングに費やされることになるからである。特定の場合には、クライアントが１／２秒間、バッファリングすると、クライアントは３／２＝１．５Ｍｂｉｔのデータを取得することになる。次いで、クライアントは、１／２秒間、再生し、その時間の間に送信装置は、まだ３Ｍｂｐｓで加速しているが、１Ｍｂｐｓが再生で消費され、したがって２Ｍｐｂｓがバッファリングに利用可能である。このことが１／２秒間続くので、１／２×２＝１Ｍｂｉｔのデータが、再生中にバッファリングされる。結果として、加速間隔の終わりにおいて、バッファー内には１．５＋１＝２．５メガビットのデータが生し、これはスタッタリングを回避するのに十分である。バッファリングすべき２．５メガビットは、２つの部分に分割されて、１．５Ｍｂｉｔは提示が開始される前にバッファリングされ、１．０Ｍｂｉｔは提示が開始された後にバッファリングされる。
【００５４】
動作２０６では、マルチメディアストリームを受信およびバッファリングし始める。メディアストリームの受信は、クライアント装置が送信装置から行うことができる。バッファリングは、上述の推定バッファリング持続時間に基づいて開始することができる。
【００５５】
動作２０８では、マルチメディアストリームが受信されている測定速度が確認される。クライアント装置は、速度自体を測定するか、または第３者構成要素から受信速度を確認することができる。当業者であれば、クライアント装置においてメディアストリームが受信されている速度を測定する適切な方法論を認識するはずである。
【００５６】
動作２１０では、少なくとも部分的に測定速度に基づいて、メディアストリームをバッファリングするための持続時間が計算される。以下では持続時間を、上述の推定バッファー持続時間と区別するために、測定バッファー持続時間または測定持続時間と呼び、これは、持続時間はそれ自体測定されることを意図するのではなく、測定バッファー持続時間は測定加速率を使用して計算されることを意図している。測定バッファー持続時間は、全マルチメディアコンテンツファイルの最悪バッファー要件に基づいて、推定持続時間よりも精度が高くすることが可能であり、方法によってスタッターの起こりやすさを低減しながら、同時に始動時間を低減することを可能にする。
【００５７】
この例においては、クライアント装置は、実際には、ストリーミングメディアを推定速度で受信していないことがある。その結果として、推定バッファー持続時間は、実際には必要とされるよりも短すぎるか、または長すぎる可能性がある。方法が推定バッファー持続時間に接近すると、クライアント装置によって測定加速率が使用されて、実際に、クライアント装置が、測定加速率において適当なデータをバッファリングするのに十分長くバッファリングしたかどうかを見るために、始動プロファイル計算が再計算される。
【００５８】
その計算によって、クライアント装置が、十分に長くバッファリングしていないことが分かった場合には、クライアント装置は、増分量をバッファリングすることになる。例えば、クライアント装置は、バッファー計算を、その量が推定バッファー持続時間と測定バッファー持続時間との差の半分である場合に、再検査することを選ぶことができる。クライアントは、小さな時間間隔で反復して計算を実施することを避けるために、この差に最大限度、例えば１００ｍｓ、を設定したいと思うことがある。追加バッファー持続時間が達成されると、クライアントは、現在測定加速値を用いて始動プロライル計算を再び実施する。加速値はいくぶん変化する可能性があるので、現時点でその値は高くなっており、この時点でクライアントはバッファリング状態から出ることができる可能性がある。新旧の間の差の半分である新規のバッファリング時間を選ぶ１つの理由は、クライアント装置に、できる限り迅速にバッファリングを終了する機会を与えることにある。
【００５９】
（例示的クライアントのアルゴリズム）
特定の実施形態においては、上述のように送信装置によって供給される、始動プロファイルのデータ配列を使用する。始動プロファイルデータには、送信装置上にプロファイルされた提示時間の合計量の測度とともに、音声がビデオの後に送られる場合には、音声とビデオとの最大差が含まれる。音声およびビデオ送信時間については、以下に、さらに詳細に説明する。
【００６０】
特定の場合には、各加速率に対する配列の個別要素は、アンダーフロー値、アンダーフローが発生する時間、計算に使用される加速率、およびその時点までのファイルの平均ビット／バイト速度を含む。送信装置の始動プロファイルは、クライアントが、アンダーフローを回避するために特定の時間に保有すべき、（加速を乗じた平均ストリーミング速度を超えて）将来における追加バイト数を示す。上述のように、クライアント装置は、それらの追加バイトを、２つの方法、初期バッファリングによる方法およびストリーミング時間中の加速による方法よって取得する。クライアント装置は、それによって各アンダーフロー時間Ｔまでに、少なくともアンダーフローを回避するのに適正なバイト数を有するように、最初にどの程度長くバッファリングする必要があるかを計算する。
【００６１】
データ配列は、特定の加速値に結び付けられたアンダーフロー値を提供する。すなわち、送信装置は、クライアント装置に、特定の加速値に対してある時点Ｔにおいて発生するアンダーフローの量を告げている。クライアント装置がメディアストリームを受信する測定加速率が、送信装置の推定加速率と正確に一致することは非常にまれである。したがって、データ配列の初期バッファー持続時間によって、クライアント装置が多すぎるか、または少なすぎるバッファリングを行う結果となる可能性がある。クライアントは、それ自体の測定加速値を使用してバッファーの量を再計算する。特定の実施形態において、クライアント装置は、次いで、それが達成する測定加速率におけるアンダーフローに対して、それ自体の値を補間する。
【００６２】
例示的クライアント計算は次のように進行する。
【００６３】
クライアントは、加速率を推定するか、または送信装置からの推定を信頼して、推定バッファー持続時間を決定する。
【００６４】
クライアント装置がメディアストリームを受信し始めるとともに、それがメディアストリームを受信している測定速度を確認すると、クライアント装置は、測定速度を使用して、送信装置によって渡されるアンダーフロー／時間対のそれぞれに対して、送信装置のコンテンツの平均ビット率を使用して、測定バッファー持続時間を計算することができる。
【００６５】
実施形態において、送信装置は、助言データ内に、最大加速パラメータを先に送信している場合があり、最大加速パラメータは、クライアントに、送信装置は特定の量より速くはデータを送信することはないことを告げる。クライアント装置は、この量を、その計算において加速パラメータに対する上限として使用する。測定加速率を知ることによって、クライアント装置は、提示を開始した後のあらゆる特定の時間までに、（加速により）得ることになる過剰バイト数を計算することができる。
【００６６】
次いでクライアント装置は、送信装置によって渡されたアンダーフローバイト値から、計算されたバイト値を減ずる。結果が正である場合には、クライアント装置は、その追加バイト数を蓄積するのに十分なだけ長くバッファリングする必要がある。クライアント装置は、その計算において、送信装置からのアンダーフロー／時間値対のそれぞれを使用することによって、バッファーバイトの最大値を追跡する。クライアントは、送信装置からの各アンダーフロー値を、その値を計算に使用する前にそれ自体の測定加速率に補間する。バッファーバイトを追跡する代わりに、クライアントは、時間空間における計算を、送信装置から渡された平均ビット率値でバイト値を除することによって同等に実施することができる。（取得バイトよりも）提示または送信時間を、受信したデータの量およびバッファリングから出て再生を開始するときの測度として使用する、いくつかのクライアントに対しては、バイトよりも時間を使用することがより便利であることがある。
【００６７】
代替的な実施形態においては、クライアント装置は、すべてのアンダーフロー／時間対に対して計算を実行するのではなく、それ自体の測定加速値に最も緊密に一致する、それ自体に渡されたアンダーフロー／時間対に対してだけ、測定バッファー持続時間を計算する。クライアント装置は、それ自体の測定加速値に最も近い２つの対などの、アンダーフロー／時間対の別のサブセットを使用することもできる。
【００６８】
（追加要因）
（チャンクサイズ送信）
上述のように、ストリーミングメディアは、通常、連続的ではなく間隔を空けて送信されるグループ化されたパケットを含む。プロセスを認識して、いくつかの実施形態では、送信装置からの送信間の間隔である、送信装置バンド幅変動の推定値を追加してもよい。例えば、ある送信装置構成では、送信装置は、１秒チャンクでデータを送信する。コンテンツと対して速度の高いリンク上では、大きなチャンクでデータを送信すると、チャンクサイズを考慮しない場合には、クライアントが、バッファリングを早く終了しすぎる可能性がある。
【００６９】
そのようなことが発生する理由は、それぞれの大きなチャンク送信に続いて、送信装置からデータが到着しない、長い期間（ほとんど１秒）がある可能性がある。しかしながら、構成によっては、クライアント計算は、データの到着は加速率で直線的であることを仮定している。クライアントが、１秒送信からバッファー要件を満たすのに十分なバッファーデータを得ない場合には、次の１秒送信が発生する前に、データが不足する可能性があるが、その理由は、クライアントが平均加速率において直線的にデータを受け取ったと仮定しているからである。
【００７０】
問題を回避するために、送信装置は、その送信チャンクサイズの指示をクライアント装置に送り、クライアント装置は、この量をそのバッファー時間に加えることができる。送信装置が（１２Ｍｂｉｔコンテンツに対して）１５０ｍｓチャンクを送信する、そのような一例においては、クライアントは、それに応答して、チャンク効果を回避するために、１５０〜２００ｍｓをその始動計算に加えることができる。
【００７１】
（音声ビデオ分離）
実施形態によっては、動作２０４において受信される助言データには、メディアストリーム中の音声およびビデオの対応する部分のいずれかの分離に関係する情報を含めることができる。あるファイルフォーマットにおいては、対応するビデオおよび音声データは一緒に送信されないことがある。例えば、時間１秒で提示するためのビデオは、ファイル内で１０００バイトであり、同じ１秒提示時間に対して音声は、ファイル内で２０００バイトである場合には、クライアント装置は、ファイルのこの部分を提示する前に、音声を待つ必要がある。クライアント装置が対応する音声およびビデオの両方を有するまでは、提示を開始するのは不適当であるので、因子は、その他の迅速始動バッファーについての考慮よりも重要である。例えば、音声がビデオよりも３秒遅れている場合には、方法は、それが再生を開始してスタッタリングを回避するのに十分なバッファーを備えている場合でも、その３秒の持続時間の間、待つことができる。そのような一実施形態において、送信装置は、情報をクライアント装置にヘッダーとして送信する。所与の加速率に対して、音声ビデオ関係について１つのヘッダー、始動プロファイルバッファー時間について１つのヘッダーである。
【００７２】
そのような一実施形態において、送信装置は、ファイル中の音声およびビデオパケットの提示時間における差を観察することによって、ビデオに対する音声の遅れの定量化を試みる。
【００７３】
特定の実施形態において、音声パケットに遭遇する度に、方法は、最新のビデオパケットと音声パケットの間の提示時間の差を計算する。この値が正である（ビデオ提示時間が音声提示時間よりも大きい）ときには、ビデオサンプルに対応する音声データは、ファイルのより内部のある箇所、すなわち将来のある時点にあり、クライアント装置は、音声とビデオを同期させられるために、その音声を待たなければならない。方法は、第１ステップで計算される値の最大値を、音声がビデオに対してどのくらい遅れているかの最悪測度として、保管することができる。次いで、方法では、音声遅れの最大値をクライアント装置に送ることができる。
【００７４】
特定の実施形態では、音声サンプルを識別する度に、この計算を反復して、サンプルはその時間量だけ遅れて送信されて音声の遅れにさらに寄与することになるので、次いで、計算値に送信時間における差を加えることができる。
【００７５】
別の実施形態においては、ビデオサンプルは、音声サンプルが散在するいくつかのパケットにわたって広がっている。この計算によって、所与の提示時間における最後のビデオパケットを発見して、それを音声提示時間と比較することができる。
【００７６】
動作２１２では、測定バッファー持続時間に基づいてマルチメディアの提示を開始する。提示は、短縮した時間で開始し、同時に提示中のスタッターを軽減および／または回避することができる。
【００７７】
（第２の例示的方法および実装）
図３は、メディアストリームから得られるメディアの提示の一方法による、動作のフローチャートである。
【００７８】
動作３０２において、マルチメディアを提示するように構成された下流構成要素においてマルチメディアが受信される速度（測定速度）が測定される。マルチメディアが受信される速度の測定は、任意適当な手段を用いて達成することができる。比較位置において受信速度を測定することによって、仲介事象または条件によって発生するものなどの、不一致を低減することが可能となり、これらの不一致は、さらに上流でそのような速度を推定する試みの精度を低下させる可能性がある。
【００７９】
動作３０４では、提示の前に受信メディアをバッファリングするための持続時間が求められる。一実施形態においては、方法は、ストリーミングメディアのバッファリングを開始して、再生を開始する前に、測定受信速度に基づいてバッファリングするための持続時間を計算する。バッファー保持時間計算における測定速度を使用すると、始動時間が減少するとともに、提示のスタッタリングを回避することもできる。動作３０２および３０４を、メディアの提示を開始する前に、複数回、反復することによって、バッファー持続時間をさらに正確に求めることができる。
【００８０】
（コンピュータ処理環境）
本明細書に記載する、１つまたは複数の実施形態は、その他多数の汎用または専用のコンピュータ処理システム環境または構成によって実施することができる。使用に適する周知のコンピュータ処理システム、環境、および／または構成の例としては、それに限定はされないが、パーソナルコンピュータ、サーバコンピュータ、シンクライアント（ｔｈｉｎ ｃｌｉｅｎｔ）、シッククライアント（ｔｈｉｃｋ ｃｌｉｅｎｔ）、ハンドヘルドまたはラップトップデバイス、セルフォン、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能大衆消費電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上述の任意のシステムまたはデバイスを含む分散コンピュータ処理環境、その他がある。
【００８１】
本明細書に記載する、１つまたは複数の実施形態は、タスクが通信ネットワークを介して連結されたリモート処理デバイスで実施される、分散コンピュータ処理環境において実施することもできる。分散コンピュータ処理環境において、プログラムモジュールは、記憶装置を含む、局所および遠隔のコンピュータ記憶媒体の両方に配置することができる。
【００８２】
本明細書に記載する、１つまたは複数の実施形態は、プログラムモジュールなどの、プロセッサまたはコンピュータによって実行されるプロセッサ実行可能命令の一般文脈で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データタイプおよびファンクションを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、などを含む。通常、プログラムモジュールの機能は、組み合わせるか、または必要に応じて様々な実施形態に分散させることができる。
【００８３】
（結論）
上述の実施形態によって、メディアコンテンツを実際に利用者に提示するように構成された装置は、メディアを利用者に提示する前に、メディアストリームをバッファリングする持続時間に関する最終決定を行うことができる。そのような構成によって、バッファー持続時間を低減するとともに、同時に提示中のスタッタリングを軽減および／または回避することができる。
【００８４】
発明の概念を構造特徴および／または手順動作に固有の言語で説明したが、添付のクレームに説明された発明の概念は、説明した特定の機構または動作に必ずしも限定されるものではないことを理解すべきである。そうではなく、特定の機構および動作は、請求した発明の概念を実施する例示的な形態として開示したものである。
【図面の簡単な説明】
【００８５】
【図１】本明細書において説明する少なくとも１つの実施形態を（完全または部分的に）実施することができる例示的メディアストリームのネットワークトポロジーを例示する概略の図である。
【図１Ａ】本明細書において説明する少なくとも１つの実施形態を（完全または部分的に）実施することができる例示的メディアストリームのネットワークトポロジーを例示する概略の図である。
【図２】本明細書において説明する手順の実施形態を例示するフローチャートである。
【図３】本明細書において説明する手順の実施形態を例示するフローチャートである。
【技術分野】
【０００１】
本発明は、一般には、データ信号の伝送技術に関し、より詳細には、メディアストリームから得られるメディアの提示を行う方法およびシステムに関する。
【背景技術】
【０００２】
（導入）
ディジタルメディアストリーミング技術によって、利用者は、メディア送信装置などの遠隔位置から受信したディジタルメディアを見ることおよび／または聞くことができる。クライアント装置または受信装置の利用者は、見るためのファイルを選択することができる。代替選択肢として、利用者は、見るためのリアルタイムエンコーダからのデータを選択することができる。選択されたファイル／エンコーダからのメディアまたはデータは、メディアストリームとして受信装置に送り、そこでそれを再生するか、または別の方法で利用者に提示することができる。ファイルを選択するのには、様々なシナリオがある。例えば、利用者は、ウエブサイトのムービートレーラー（ｍｏｖｉｅ ｔｒａｉｌｅｒ）をチェックするか、またはインターネットプロバイダを介してＴＶを見ているときにチャネルを変えることができる。メディアは聴覚作用および視覚作用の両方を生成するデータを含むことが多いので、これは「マルチメディア」データまたはコンテンツと呼ぶことができる。
【０００３】
そのようなマルチメディアを正確に表すのに必要なデータ量のせいで、それは、クライアント装置に送られる前に、エンコーダにおいて圧縮、エンコードされることがある。提示のためにオリジナルメディアを再生するには、一般に、そのメディアは、提示される前に圧縮解除、デコードされる。エンコーダとデコーダとの両方にバッファーを使用して、コンテンツのビット率における変動性を補償することができる。プロセスは、リーキーバケット（ｌｅａｋｙ ｂｕｃｋｅｔ）モデルになぞらえられることがあり、その場合には、エンコーダはリーキーバケットを用いてエンコードを行っており、クライアント装置は、アンダーフローを回避するために、同等の大きさのバケツを有する。このことは、コンテンツのビット率にはいくぶん変動性があるために起こるものであり、バケツの大きさは、基本的には、ビット率の最大変動率の測度である。
【０００４】
（メディアストリームの伝送）
実際的な目的で、メディアストリームエンコーダからの音声および／またはビデオを運ぶメディアストリームは通常、連続的ではなく、複数の伝送パケットに分割されている。フォーマットによっては、そのようなパケットは、キーフレームとも呼ばれることのある、１つまたは複数のイントラフレームまたはＩフレームを含む。Ｉフレームは、過去または将来のフレームを参照することなく、単一画像としてエンコードされる。
【０００５】
（アンダーフロー）
受信装置においてデコード（または提示）すべきデータが不足すると、これは「アンダーフロー」と呼ばれる。アンダーフローは、受信装置は次のフレームをデコード（または提示）する準備ができているが、受信装置はそのフレームのデータのすべてをまだ受信（またはデコード）していないときに発生する。
【０００６】
アンダーフローの実際的で顕著な現れは、円滑に再生される動画ビデオとしての所望の効果ではない、動画ビデオ提示における一時的な中断（すなわち、「ヒッカップ（ｈｉｃｃｕｐ）」または「スタッター（ｓｔｕｔｔｅｒ）」）である。例えば、動画ビデオを固定周波数（例えば、１５フレーム／秒）で示すのではなく、アンダーフロー状態にある受信装置は、次のフレームまたはその後のフレームを表示する前に、目に見えてわかる遅延が続くビデオストリームのフレームを示すことになる。これは、数秒または数分間、続くことがある。
【０００７】
アンダーフローのための条件は、新規ファイルまたはエンコードコンテンツが選択されるとき、すなわちチャネルを変更するときに、特に機が熟する。受信装置が新規チャネルの入力メディアストリームを受信してデコードするや否や、すぐにフレームを提示する場合には、アンダーフロー条件が発生しやすい。
【０００８】
その代わりに、マルチメディアデータの提示を、クライアント側バッファーを充填するのに十分な時間だけ遅延させるのが一般的である。マルチメディアデータがデコードされ、提示されるときに、受信装置は、そのバッファーに格納されたデータを空にする。しかしながら、受信装置がデコードされたデータを提示する間に、さらなるエンコードデータがダウンロードされてバッファーが再充填される。バッファーが完全に空にならないように、データが再生されるのと少なくとも同じ速さでデータがダウンロードされる限り、ファイルは円滑に再生されるはずである。
【発明の開示】
【発明が解決しようとする課題】
【０００９】
アンダーフローを防止するように設計された、上述の従来の方法は、利用者の選択と、その選択の利用者への実際の提示との間に煩わしい遅延を生成する可能性がある。
【００１０】
本明細書において説明する様々な実施形態は、メディアストリームから取得されるメディアを提示するための方法およびシステムを提供する。
【課題を解決するための手段】
【００１１】
本明細書において説明する、少なくとも１つの実施形態は、マルチメディアを利用者に提示するように構成された下流構成要素においてマルチメディアストリームが受信される速度（測定速度）を測定し、少なくとも部分的にその測定速度を使用して、受信マルチメディアをその提示の前にバッファリングするための持続時間（測定時間）を確認する。
【００１２】
同一の数字を、すべての図面を通して使用し、同一の要素および機能を参照する。
【発明を実施するための最良の形態】
【００１３】
（概観）
以下のシステムおよび方法は、スタッタリングを軽減しながら、同時にマルチメディア提示のバッファー遅延を減少させる。いくつかの実施形態では、提示のスタッタリングを完全に回避しながら、バッファリング遅延を低減することができる。送信装置は、選択されたファイルまたは生のエンコードセッションからのメディアをクライアント装置に流す（以下では、ファイルまたはセッション、あるいはその等価物を参照するのに「ソース（ｓｏｕｒｃｅ）」という用語を使用する）。「ストリーミング速度（ｓｔｒｅａｍｉｎｇ ｒａｔｅ）」という用語は、送信装置からクライアント装置にメディアを流す速度を識別するのに使用する。受信すると、クライアント装置は、その流されたメディアをクライアントまたは利用者にすぐさま、またはその後に提示することができる。データが提示のために使用される速度は、提示速度と呼ばれる。平均提示速度は、平均ストリーミング速度とほぼ等しくすることができるが、瞬時においては、ストリーミング速度と提示速度は異なっていてもよい。
【００１４】
メディアをストリーミングする前に、送信装置は、メディアに関係する助言データ（ａｄｖｉｓｏｒｙ ｄａｔａ）をクライアント装置に送る。助言データについて以下により詳細に説明するが、これには特に、送信装置がメディアを流す加速率（ａｃｃｅｌｅｒａｔｉｏｎ ｒａｔｅ）、加速間隔、様々なバッファー値、開始プロファイル、および／または推奨または推定バッファー持続時間（ｅｓｔｉｍａｔｅｄ ｂｕｆｆｅｒ ｄｕｒａｔｉｏｎ）などの様々な構成要素を含めることができる。加速率は、提示速度に対して表された、送信装置がデータを送ろうとするストリーミング速度であるか、または絶対値としてビット／秒またはバイト／秒で表すこともできる。送信装置は、提示速度の２倍（２×）などの加速率で、加速間隔と呼ばれる持続時間の間、ストリーミングを開始することができる。代表的な加速率しては、１０×、１２×、１５×、および３０×の範囲としてもよいが、これらは単に例示であり、送信装置および送信装置とクライアント装置の間のネットワークの特性に応じて、その他任意の値であってもよい。
【００１５】
クライアント装置は、提示中のアンダーフロー状態を避けるために、十分なデータを保持するためにデータをバッファリングすることができる。クライアント装置は、少なくとも２つの方法でバッファーにデータを追加することができる。第１には、クライアント装置は、マルチメディアの提示を開始する前に、最初にバッファリングをすることができる。そのような場合には、受信データのすべてがバッファリングされる。しかしながら、そのようなバッファリングは、始動遅延を生じる結果となり、始動遅延は、例えば、利用者が再生ボタンを押してから実際にマルチメディア提示を見るか、または聞くまでの間の期間である。第２に、クライアント装置は、メディアを提示する間の加速間隔中にバッファリングすることも可能であり、これは、クライアント装置は、データを提示するよりも高い速度でデータを受け取っているからである。後者の一例では、提示速度は、１メガビット／秒（Ｍｂｐｓ）とすることができる。送信装置は、加速間隔中に２×または２Ｍｂｐｓでメディアを流すことができる。クライアント装置は、加速間隔の持続時間中に、過剰データをバッファーに入れ、一方で同時にデータを提示に使用することができる。
【００１６】
助言データには、実装方法によっては、始動プロファイル（ｓｔａｒｔ−ｕｐ ｐｒｏｆｉｌｅ）（複数を含む）を含めることができる。一般に、始動プロファイルには、アンダーフローを避けるために、提示における１つまたは複数の時点において要求または推奨されるバッファー量に関係づけることができる。送信装置は、メディアストリームを送信する前に、推定始動プロファイルをコンパイルすることができる。様々な実装方法において、推定または最初の始動時間が計算され、これは推定加速率における始動プロファイルを満足する。始動時間は、クライアント装置がメディアストリームを受信し始めてからメディアを提示し始めるまでにクライアントが蓄積すべきバッファー量の測度である。バッファー量は、ビット単位または時間単位で測定することが可能であり、ここで時間の単位は、ビット値を平均ビット率で除した値である。
【００１７】
クライアント装置がメディアストリームを受信し始めると、始動時間を検証、または再計算することができる。いくつかの実施形態においては、始動時間またはバッファー持続時間を、クライアント装置がメディアストリームを受信する測定加速率を使用して、再計算することができる。加速間隔中にバッファリングされるデータの量の実際の測定値とともに、始動プロファイルを使用すると、より正確な、第２の、または測定された始動持続時間を計算することが可能となる。その他の実装方法では、単に測定加速率を使用して、マルチメディアの提示を開始する前に、推定始動持続時間の精度を検証することができる。
【００１８】
実装方法によっては、本方法は、測定加速率と先に推定された加速率を比較して、相応に動作することができる。比較によって、測定加速率が推定加速率よりも遅いことが分かった場合には、本方法では、バッファー時間を再計算して長くバッファリングすることができる。データが、推定速度を超える速度で受信される場合には、本方法はバッファー時間を短縮することができる。方法で計算される始動前バッファリングの量は、既存技術と比較して実質的に減少させることができる。始動プロファイルの再計算は、クライアントがデータを受信し始めた後、任意の時点で行うことできる。それは例えば、１００ｍｓの規則的な時間間隔で行ったり、または初期推定始動時間の一定割合で、例えば初期計算バッファー時間の５０％で行ったりすることもできる。
【００１９】
クライアント装置は、利用者へのファイルの提示に最も近いデバイスであり、言い換えると、クライアント装置は最下流のデバイスである。様々な遅延、ボトルネックおよび／またはその他のメディア経路に沿った介入条件の結果として、クライアント装置は、始動計算を行うのに上流構成要素よりも有利な位置にある。
【００２０】
その他の利点の中で、クライアント装置が、始動前にバッファリングする長さを決定することを可能にすることで、そうでなければ介入事象から生じる可能性のある、バッファー時間における不正確さを低減することができる。例えば、上流送信装置は、それがメディアをクライアント装置に流そうと意図する推定伝送速度に対する、バッファー持続時間を計算することができる。クライアント装置は、実際に、異なる速度、例えば高い速度または低い速度でメディアストリームを受信することができる。したがって、クライアント装置が行う計算は、送信装置において行われる計算よりも精度が高い。クライアンと装置は、それがデータを受信する速度について最も正確に見ることが可能であり、アンダーフローを避けるためにバッファリングしなくてはならない時間量を最も正確に計算することができる。
【００２１】
（例示的実施形態）
以下の説明は、添付の特許請求の範囲に記載された要素を組み入れた、メディアストリームから取得したメディアの提示のための方法およびシステムの１つまたは複数の例示的な実装方法を示す。これらの実装方法を、法的な書面による説明、機能付与、および最良の形態要件に合致するために、具体的に説明する。しかしながら、説明自体は、本発明の範囲を限定することを意図するものではない。
【００２２】
（メディアストリームのネットワークトポロジー）
図１および図１Ａは、例示的なメディアストリームのネットワークトポロジー１００の高いレベルの表現を例示しており、本明細書において説明する他の観点を（部分的にまたは完全に）実装することができる。
【００２３】
例示的なトポロジー１００は、サーバのような、１つまたは複数のメディアストリーム送信装置１１０を含み、これは、伝送手段１３０を介して受信装置またはクライアント装置１２０に通信可能に結合されている。受信装置１２０には、とりわけ、パーソナルコンピュータ（ＰＣ）、セル電話またはセットトップボックス（ｓｅｔ−ｔｏｐ ｂｏｘ）を含めることができる。実施形態においては、受信装置１２０は、さらに、表示スクリーンおよび１つまたは複数のスピーカーを含む、表示または提示デバイス１４０をさらに含む。送信装置の機能は、単一構成要素または複数の構成要素によって達成することが可能であり、同様にクライアント装置の機能は、単一構成要素または複数の構成要素によって達成することが可能である。
【００２４】
送信装置１１０は、受信装置１２０への伝送のための、ファイルなどのソースを格納すること、および／またはネットワーク１５０を介してソースにアクセスすることが可能である。様々な実施形態において、ネットワーク１５０は限定アクセスネットワークとするか、または他の構成の中で、インターネットを含めることができる。ネットワーク１５０は、送信装置１１０がアクセスするマルチメディアデータまたはコンテンツをエンコードおよび圧縮するための、エンコーダ１６０に結合してもよい。代替的に、送信装置１１０は、メディアを伝送手段１３０上でクライアント装置１２０に流す前にそれをエンコードすることが可能であり、クライアント装置１２０は、提示に先立って、そのメディアをデコードすることができる。
【００２５】
トポロジー１００は、利用者従事クライアント装置１２０が、提示のための、ファイルなどのソースを選択することを可能にする。クライアント装置１２０は、送信装置１１０にメディアをファイルからクライアント装置に流すことを要求することができる。伝送手段１３０には、イーサネット（登録商標）、ブロードバンド、ダイアルアップ、および無線などの任意適当な伝送手段を含めることができる。クライアント装置１２０および提示デバイス１４０は、ここでは異なる構成要素として説明してあるが、その他の実装方法では、それらの機能を単一装置に統合することができる。
【００２６】
（第１の例示的方法および実装）
図２は、メディアストリームから得られるメディアの提示のための一方法にかかる動作を表すフローチャートである。
【００２７】
動作２０２は、マルチメディアストリームを受信することを要求する。そのような要求は、クライアント装置上での選択として利用者が開始することができる。例えば、利用者は、ウエブブラウザ内のコンテンツをクリックするか、またはインターネットプロバイダ上でＴＶを見ている間にチャネルを切り替えることができる。要求は、単にファイルなどの選択されたソースを流すことであるか、またはもっと具体的にすることができる。例えば、要求は、選択されたファイルに２０秒入った位置で始まる１０秒の提示時間に対応するコンテンツを流すことである。要求によって、再生要求に対応するファイルが、例えば送信装置によってアクセスされるようにすることができる。
【００２８】
少なくとも部分的にソースにアクセスすることによって、ソースのデータの提示に対応する助言データを得ることができる。助言データには、最初にそのファイルを作成したプログラムによってファイルのヘッダー内に格納された情報を含めることができる。プログラムは、ファイルを試験して、ファイル内の任意の箇所に対する最大または推奨バッファー量を決定する。バッファーデータは、ファイルヘッダー中に書き込み、そこでは、そのバッファーデータに送信装置がアクセスすることができる。
【００２９】
送信装置は、単に助言データを収集して、それをクライアント装置に送ることができる。別の実装方法においては、送信装置は、バッファーデータなどの助言データの様々な構成要素を、それをクライアント装置に送る前に処理することができる。いくつかの例においては、送信装置は、それがクライアント装置に送る、１つまたは複数の推定始動プロファイルを計算する。始動プロファイルは、クライアント装置が提示の様々な時点で取得すべきデータの量に関係づけることができる。例えば、始動プロファイルには、アンダーフローの最大量、アンダーフローが発生する時間、およびアンダーフローを計算するのに使用される加速率を示す、１組の値を含めることができる。以下に説明するいくつかの実装方法においては、複数の加速率に関係するデータを、単一始動プロファイルに含めることができる。その他の実装方法では、個々の加速率に対する個別の始動プロファイルを生成することができる。
【００３０】
１つの実装方法において、始動プロファイルは、各提示時間におけるパケットサイズを加えることによって計算され、ファイルの提示中の様々な時間における提示要件が決定される。様々な具体的な加速率に基づいて、方法では、各提示時間における加速されたストリーミングのために受信しているはずであるデータ量の推定値を計算することができる。方法では、クライアントバッファーをアンダーフローさせること（データが不足すること）を避けるために、提示の開始に先立って、推定バッファー持続時間を提供することができる。
【００３１】
始動プロファイルには、様々な形態を含めることができる。一例においては、始動プロファイルはデータ配列を含む。配列要素は、特定の加速率に関係づけることができる。例えば、各加速率に対して、配列はアンダーフローバイト値と、アンダーフローが発生する時間とを含む。
【００３２】
いくつかの実施形態においては、始動プロファイルは、所与の加速率に対して、２つのバッファリング条件に関係する。第１のバッファリング条件は、ファイルの提示前の、推奨または推定バッファーサイズに関係する。第２のバッファリング条件は、加速間隔の終わりにおける推奨バッファーサイズに関係づけることができる。これらの２つの条件について、以下により詳細に説明する。
【００３３】
第１のバッファー条件は、クライアント装置が、各アンダーフロー時間によって、スタッタリングを低減および／または回避するのに適当なバイト数を少なくとも有するように、クライアント装置が初期にバッファリングすべき長さを計算するのに使用することができる。第２のバッファー条件は、クライアント装置が加速期間を終了するときに、それが提示における任意の時点に対する十分な量のバッファーを有することを保証するための、最悪バッファーシナリオの計算に関係する。最悪バッファーシナリオは、エンコードプロセスによって書き込まれたヘッダー値とすることができ、ヘッダー値は、クライアントが最悪事態またはコンテンツの最も「要処理（ａｃｔｉｏｎ）」な部分に対するアンダーフローを避けるために持つべき、推奨バッファー量を示す。第２の計算は、クライアント装置は、加速間隔中にそのバッファー量を増大させることだけに頼るべきであるという前提に基づいている。いくつかの実施形態においては、送信デバイスは、助言データに入れて、推奨バッファー量に関係するヘッダー値を送信する。その他の実施形態においては、送信デバイスは、助言データの一部として、加速間隔の終わりまでに達成すべきクライアントデバイスに対する推奨全バッファー値を、特に提供することができる。
【００３４】
そのような実施形態においては、方法により、クライアント装置が加速間隔から出る前に達成すべき、全提示に対して十分なバッファリングされたデータ量を決定する。クライアント装置がストリーミングメディアの受信を続けるときに、新規データは、もちろんのこと、提示中にバッファーに追加されるが、新規データは、データが提示のためにデコードされる速度に近い速度で追加される。したがって、全バッファーサイズは、大幅に増加することを当てにすべきではない。方法の実施形態では、送信装置がメディアを流そうとする推定加速率において、これらの２つのバッファー値を満足するために、提示前のバッファー持続時間が計算される。
【００３５】
さらに別の実装においては、送信装置は、バッファー計算を実施して、単に、クライアント装置がバッファリングすべき時間量に対する単一の値をクライアント装置に渡してもよい。代替手法として、送信装置は、異なる加速率に対するバッファー時間の配列をクライアント装置に渡し、クライアント装置は、単にそれ自体の測定加速率に最も近い時間を選ぶか、またはより正確な値を補間することができる。当業者であれば、これらは、その構成要素がアルゴリズム（複数を含む）を実行する例にすぎないことを認識するはずである。例えば、いくつかの実施形態においては、計算の大部分または全部を、送信装置によって実行することができる。さらに別の実装においては、計算の大部分または全部をクライアント装置で実行することができる。
【００３６】
（例示的送信装置のアルゴリズム）
一実施形態において、送信装置が使用する例示的アルゴリズムのより詳細な例について説明する。アルゴリズムは、様々なクライアント要求によって機能するように構成されている。そのような一例においては、クライアントは、ＴＶプログラムなどのすでに実行中の放送公開点に参加することを要求する。別のそのような例においては、クライアントは、ウエブサイト上で参照することのできるオンデマンド公開点からのファイルを再生することを要求する。
【００３７】
放送公開点例に対して、方法では、それがクライアント装置に流すメディアの開始点となるＩフレームを発見する。以下のアルゴリズムは、クライアント装置に送信されるデータの組、すなわちそのＩフレームから前方に作用する。前記オンデマンド例においては、計算は、提示における第１のパケットから単に開始される。代替的には、利用者は、ファイル内の任意の箇所を探索することができる。その場合には、方法は、その探索箇所に近いＩフレームを発見して、その箇所からデータの送信を開始する。計算は、そのＩフレームから開始される。
【００３８】
リアルタイムエンコードコンテンツの場合には、クライアント装置に流される実際のファイルはない。しかしながら、送信装置は、ある量のリアルタイムコンテンツをバッファーに入れて、そのバッファーからのデータをクライアント装置に送信することができる。そのバッファーは、始動プロファイルの目的に対して、論理的には、多くの点においてファイルと同等である。そのバッファーは円形方式で配設してもよく、その場合には、新規データが追加されると、古いデータは終点から削除される。リアルタイムエンコードコンテンツに対して、送信装置からクライアント装置への加速を与えるためには、送信装置は、単に、バッファリングされた量の一部を、実際の再生速度よりも迅速にクライアントに送信する。
【００３９】
特定の実施形態においては、送信装置は、一般に、メディアストリームの特定の期間にわたってクライアント装置バッファー要求におけるピークを発見するのに使用される、プロファイリングプロセスを実行する。特定の実施形態では、先のパケットサイズを合計することによって、各提示時間に対するデータが計算される。あらゆる特定の提示に対するデータは、短い提示時間を有するパケット全部の合計である。値は、クライアント装置が、アンダーフローを避けるために保有すべきデータの量の測度である。
【００４０】
実施形態においては、ストリームの平均ビット率が、その時点までにクライアント装置に送られたバイト数、すなわち提示時間をとって、それを送信時間における差で除することによって計算される。この値は、局所的な実際平均ビット率であって、それは、ストリームの複数部分に対してファイルヘッダーに記憶されている平均ビット率値とは異なる可能性がある。特定の実施形態では、この値は試験されているファイルの部分に対して精度が高いので、ファイルヘッダーからの平均値ではなく、この値が使用される。
【００４１】
実施形態では、上述の計算された平均値を使用して、同一の提示時間値においてクライアント装置に送信される、ストリームデータの量が計算される。方法では、いくつかの加速率に対して計算を行うことができる。
【００４２】
実施形態では、各間隔におけるクライアントバッファーの推定過剰量を、各加速率に対して、第１の数から第２の数を差し引くこと（必要データ−ストリームデータ）によって計算することができる。この数が負である限り、クラアントには、それが必要とするより大量のデータが流され、クライアントがアンダーフローすることがないことになる。しかしながら、この値が提示におけるいずれかの時点において正である場合には、クライアント装置においてアンダーフロー条件が存在することになる。
【００４３】
また、方法では、各加速率に対して、クライアントバッファーの最大アンダーフロー値および最大アンダーフローが発生する提示時間を追跡する。クライアントのバッファー要求が最大になる、提示時間における位置は、加速率が変化するときに変る可能性がある。そのような環境において、方法では、いくつかの加速率においてアンダーフロー値が計算される。
【００４４】
これによって、各加速率に対して、データ量などの１つのアンダーフロー値およびそのアンダーフロー値の提示時間が与えられる。アンダーフロー値は、各加速率に対して異なることが多いが、この理由は、データがクライアントに配布される速度は、異なる加速率のために相異することになるからである。しかしながら、各アンダーフローに対する提示時間値は、いくつかの加速率に対して同一であるか、またはそれは異なっている可能性がある。推定データ配信対時間曲線の形状に応じて、加速率が異なると、異なる時間にアンダーフローを生ずる可能性がある。
【００４５】
実施形態では、次いで、これらの計算されたアンダーフローバッファー値およびそれらが発生する時間、それらを計算するのに使用される加速率、および提示におけるその時点までの平均ビット率を、クライアント装置に送信することができる。いくつかの場合には、上述のコンパイルされた助言データは、クライアント装置に、そのクライアント装置のための始動プロファイルとして送信することが可能であり、始動プロファイルは、送信装置によって計算される推定バッファー持続時間を含む。例えば、送信装置は、１つまたは複数の加速率に対して使用されるバッファーの量を送信してもよく、その１つは、送信装置がデータを流そうとする推定加速率としてもよい。少なくとも部分的にバッファーデータに基づいて、続いてクライアント装置は、以下により詳細に示すように、その加速率をより正確に知ることによって、使用する最適の値を、補間またはその他の方法で計算することができる。その他の実施形態では、その計算のさらに多くの部分を送信装置によって行うことができる。例えば、送信装置は、それがクライアント装置に送信したデータ量を監視し、次いでクライアントに信号を送って、バッファリングを終了して提示を始めることもできる。
【００４６】
そのような始動プロファイルの一例を以下に示す。
【００４７】
【表１】
【００４８】
動作２０４では、マルチメディアストリームに関係する助言データを受信する。上述のように、助言データは、１つまたは複数の加速率における始動プロファイルと関係づけることが可能であり、始動プロファイルは、送信装置が使用することが可能であるとともに、ネットワーク自体が送信装置とクライアント装置との間の達成可能なビット率における限定要因であるので、仲介ネットワークまたは伝送手段によってサポートされている。
【００４９】
以下に示すのは、どの機能がそれぞれのデバイスによってサポートされているかを伝えるために、送信装置およびクライアント装置が使用するヘッダーの一例である。特定の例においては、送信装置およびクライアント装置は、以下のように始動プロファイル（複数を含む）の形態で助言データをサポートすることができる。
Supported:com.microsoft.wm.startupprofile
【００５０】
いくつかの実施形態においては、クライアント装置が、いくらかの対話能力またはアルゴリズム能力を有し、助言データに基づいて、送信装置を制御することが可能となる。例えば、クライアント装置は、加速率および助言データに基づく加速間隔を選択して、それに応じてメディアを流すことを送信装置に要求してもよい。別の例においては、送信装置は、加速率を決定することができるが、クライアント装置は加速間隔を要求することができるようにすることができる。以下により詳細に述べるように、任意の加速率において、クライアント装置は、加速間隔の終点におけるフルバッファー値による追加の始動ディスプレイを避けるための、送信装置の加速の長さを計算することができる。したがって、助言データ、特に送信装置からの推定加速率を受信すると、クライアント装置は、対応する加速間隔を計算して要求することができる。代替的に、クライアント装置は、実際に助言データを受信する前に、対応する加速間隔を計算して要求することができる。クライアント装置は、メディアストリームを受信するための最初の要求中に、要求加速間隔を送信装置に渡すことができる。
【００５１】
その他の実施形態において、送信装置は、クライアント装置に対する遅延処理なしにメディアストリームに関する決定を行うことができる。そのような一実施形態においては、送信装置は、単に、助言データ内で、推定加速率および加速間隔をクライアントに通知して、メディアを流す。ここで留意すべきことは、ネットワークトポロジーによっては、加速間隔は、送信装置によって正確に制御可能であるのに対して、加速率は、仲介ネットワークの特性とともに、送信装置が送信する速度に依存することである。
【００５２】
助言データが推定加速率およびその結果として得られる推定バッファー持続時間を含む場合には、方法は、動作２０６に進むことができる。代替的あるいは追加的に、クライアント装置は、動作２０６に進む前に、推定加速率および／または対応する推定バッファー持続時間を決定してもよい。例えば、クライアント装置は、将来ストリームの加速率をパケット対またはランタイムパケット対を使用して推定することができる。別の例においては、クライアントは、"?wmbitrate=xxx"などのＵＲＬ修飾子を介して推定速度を決定することができる。
【００５３】
推定バッファー持続時間を計算する一例は、以下のシナリオに見ることができる。この場合に、加速間隔は１０秒であり、平均提示速度は１０Ｍｂｐｓであり、最悪バッファー需要は２．５メガビットのデータである。推定加速率は３Ｍｂｐｓである。したがって、ストリーミングが始まるとすぐに再生が行われる場合には、２．０メガビットのデータを加速間隔中にバッファリングすることが可能であり、提示に先立って０．５メガビットをバッファリングすることが必要と思われる。しかしながら、再生の前にいくらかのバッファリングがあるので、クライアントは、再生が開始してから丸１秒間は加速を受けないが、その理由は、その加速時間の一部は、再生が開始される前にバッファリングに費やされることになるからである。特定の場合には、クライアントが１／２秒間、バッファリングすると、クライアントは３／２＝１．５Ｍｂｉｔのデータを取得することになる。次いで、クライアントは、１／２秒間、再生し、その時間の間に送信装置は、まだ３Ｍｂｐｓで加速しているが、１Ｍｂｐｓが再生で消費され、したがって２Ｍｐｂｓがバッファリングに利用可能である。このことが１／２秒間続くので、１／２×２＝１Ｍｂｉｔのデータが、再生中にバッファリングされる。結果として、加速間隔の終わりにおいて、バッファー内には１．５＋１＝２．５メガビットのデータが生し、これはスタッタリングを回避するのに十分である。バッファリングすべき２．５メガビットは、２つの部分に分割されて、１．５Ｍｂｉｔは提示が開始される前にバッファリングされ、１．０Ｍｂｉｔは提示が開始された後にバッファリングされる。
【００５４】
動作２０６では、マルチメディアストリームを受信およびバッファリングし始める。メディアストリームの受信は、クライアント装置が送信装置から行うことができる。バッファリングは、上述の推定バッファリング持続時間に基づいて開始することができる。
【００５５】
動作２０８では、マルチメディアストリームが受信されている測定速度が確認される。クライアント装置は、速度自体を測定するか、または第３者構成要素から受信速度を確認することができる。当業者であれば、クライアント装置においてメディアストリームが受信されている速度を測定する適切な方法論を認識するはずである。
【００５６】
動作２１０では、少なくとも部分的に測定速度に基づいて、メディアストリームをバッファリングするための持続時間が計算される。以下では持続時間を、上述の推定バッファー持続時間と区別するために、測定バッファー持続時間または測定持続時間と呼び、これは、持続時間はそれ自体測定されることを意図するのではなく、測定バッファー持続時間は測定加速率を使用して計算されることを意図している。測定バッファー持続時間は、全マルチメディアコンテンツファイルの最悪バッファー要件に基づいて、推定持続時間よりも精度が高くすることが可能であり、方法によってスタッターの起こりやすさを低減しながら、同時に始動時間を低減することを可能にする。
【００５７】
この例においては、クライアント装置は、実際には、ストリーミングメディアを推定速度で受信していないことがある。その結果として、推定バッファー持続時間は、実際には必要とされるよりも短すぎるか、または長すぎる可能性がある。方法が推定バッファー持続時間に接近すると、クライアント装置によって測定加速率が使用されて、実際に、クライアント装置が、測定加速率において適当なデータをバッファリングするのに十分長くバッファリングしたかどうかを見るために、始動プロファイル計算が再計算される。
【００５８】
その計算によって、クライアント装置が、十分に長くバッファリングしていないことが分かった場合には、クライアント装置は、増分量をバッファリングすることになる。例えば、クライアント装置は、バッファー計算を、その量が推定バッファー持続時間と測定バッファー持続時間との差の半分である場合に、再検査することを選ぶことができる。クライアントは、小さな時間間隔で反復して計算を実施することを避けるために、この差に最大限度、例えば１００ｍｓ、を設定したいと思うことがある。追加バッファー持続時間が達成されると、クライアントは、現在測定加速値を用いて始動プロライル計算を再び実施する。加速値はいくぶん変化する可能性があるので、現時点でその値は高くなっており、この時点でクライアントはバッファリング状態から出ることができる可能性がある。新旧の間の差の半分である新規のバッファリング時間を選ぶ１つの理由は、クライアント装置に、できる限り迅速にバッファリングを終了する機会を与えることにある。
【００５９】
（例示的クライアントのアルゴリズム）
特定の実施形態においては、上述のように送信装置によって供給される、始動プロファイルのデータ配列を使用する。始動プロファイルデータには、送信装置上にプロファイルされた提示時間の合計量の測度とともに、音声がビデオの後に送られる場合には、音声とビデオとの最大差が含まれる。音声およびビデオ送信時間については、以下に、さらに詳細に説明する。
【００６０】
特定の場合には、各加速率に対する配列の個別要素は、アンダーフロー値、アンダーフローが発生する時間、計算に使用される加速率、およびその時点までのファイルの平均ビット／バイト速度を含む。送信装置の始動プロファイルは、クライアントが、アンダーフローを回避するために特定の時間に保有すべき、（加速を乗じた平均ストリーミング速度を超えて）将来における追加バイト数を示す。上述のように、クライアント装置は、それらの追加バイトを、２つの方法、初期バッファリングによる方法およびストリーミング時間中の加速による方法よって取得する。クライアント装置は、それによって各アンダーフロー時間Ｔまでに、少なくともアンダーフローを回避するのに適正なバイト数を有するように、最初にどの程度長くバッファリングする必要があるかを計算する。
【００６１】
データ配列は、特定の加速値に結び付けられたアンダーフロー値を提供する。すなわち、送信装置は、クライアント装置に、特定の加速値に対してある時点Ｔにおいて発生するアンダーフローの量を告げている。クライアント装置がメディアストリームを受信する測定加速率が、送信装置の推定加速率と正確に一致することは非常にまれである。したがって、データ配列の初期バッファー持続時間によって、クライアント装置が多すぎるか、または少なすぎるバッファリングを行う結果となる可能性がある。クライアントは、それ自体の測定加速値を使用してバッファーの量を再計算する。特定の実施形態において、クライアント装置は、次いで、それが達成する測定加速率におけるアンダーフローに対して、それ自体の値を補間する。
【００６２】
例示的クライアント計算は次のように進行する。
【００６３】
クライアントは、加速率を推定するか、または送信装置からの推定を信頼して、推定バッファー持続時間を決定する。
【００６４】
クライアント装置がメディアストリームを受信し始めるとともに、それがメディアストリームを受信している測定速度を確認すると、クライアント装置は、測定速度を使用して、送信装置によって渡されるアンダーフロー／時間対のそれぞれに対して、送信装置のコンテンツの平均ビット率を使用して、測定バッファー持続時間を計算することができる。
【００６５】
実施形態において、送信装置は、助言データ内に、最大加速パラメータを先に送信している場合があり、最大加速パラメータは、クライアントに、送信装置は特定の量より速くはデータを送信することはないことを告げる。クライアント装置は、この量を、その計算において加速パラメータに対する上限として使用する。測定加速率を知ることによって、クライアント装置は、提示を開始した後のあらゆる特定の時間までに、（加速により）得ることになる過剰バイト数を計算することができる。
【００６６】
次いでクライアント装置は、送信装置によって渡されたアンダーフローバイト値から、計算されたバイト値を減ずる。結果が正である場合には、クライアント装置は、その追加バイト数を蓄積するのに十分なだけ長くバッファリングする必要がある。クライアント装置は、その計算において、送信装置からのアンダーフロー／時間値対のそれぞれを使用することによって、バッファーバイトの最大値を追跡する。クライアントは、送信装置からの各アンダーフロー値を、その値を計算に使用する前にそれ自体の測定加速率に補間する。バッファーバイトを追跡する代わりに、クライアントは、時間空間における計算を、送信装置から渡された平均ビット率値でバイト値を除することによって同等に実施することができる。（取得バイトよりも）提示または送信時間を、受信したデータの量およびバッファリングから出て再生を開始するときの測度として使用する、いくつかのクライアントに対しては、バイトよりも時間を使用することがより便利であることがある。
【００６７】
代替的な実施形態においては、クライアント装置は、すべてのアンダーフロー／時間対に対して計算を実行するのではなく、それ自体の測定加速値に最も緊密に一致する、それ自体に渡されたアンダーフロー／時間対に対してだけ、測定バッファー持続時間を計算する。クライアント装置は、それ自体の測定加速値に最も近い２つの対などの、アンダーフロー／時間対の別のサブセットを使用することもできる。
【００６８】
（追加要因）
（チャンクサイズ送信）
上述のように、ストリーミングメディアは、通常、連続的ではなく間隔を空けて送信されるグループ化されたパケットを含む。プロセスを認識して、いくつかの実施形態では、送信装置からの送信間の間隔である、送信装置バンド幅変動の推定値を追加してもよい。例えば、ある送信装置構成では、送信装置は、１秒チャンクでデータを送信する。コンテンツと対して速度の高いリンク上では、大きなチャンクでデータを送信すると、チャンクサイズを考慮しない場合には、クライアントが、バッファリングを早く終了しすぎる可能性がある。
【００６９】
そのようなことが発生する理由は、それぞれの大きなチャンク送信に続いて、送信装置からデータが到着しない、長い期間（ほとんど１秒）がある可能性がある。しかしながら、構成によっては、クライアント計算は、データの到着は加速率で直線的であることを仮定している。クライアントが、１秒送信からバッファー要件を満たすのに十分なバッファーデータを得ない場合には、次の１秒送信が発生する前に、データが不足する可能性があるが、その理由は、クライアントが平均加速率において直線的にデータを受け取ったと仮定しているからである。
【００７０】
問題を回避するために、送信装置は、その送信チャンクサイズの指示をクライアント装置に送り、クライアント装置は、この量をそのバッファー時間に加えることができる。送信装置が（１２Ｍｂｉｔコンテンツに対して）１５０ｍｓチャンクを送信する、そのような一例においては、クライアントは、それに応答して、チャンク効果を回避するために、１５０〜２００ｍｓをその始動計算に加えることができる。
【００７１】
（音声ビデオ分離）
実施形態によっては、動作２０４において受信される助言データには、メディアストリーム中の音声およびビデオの対応する部分のいずれかの分離に関係する情報を含めることができる。あるファイルフォーマットにおいては、対応するビデオおよび音声データは一緒に送信されないことがある。例えば、時間１秒で提示するためのビデオは、ファイル内で１０００バイトであり、同じ１秒提示時間に対して音声は、ファイル内で２０００バイトである場合には、クライアント装置は、ファイルのこの部分を提示する前に、音声を待つ必要がある。クライアント装置が対応する音声およびビデオの両方を有するまでは、提示を開始するのは不適当であるので、因子は、その他の迅速始動バッファーについての考慮よりも重要である。例えば、音声がビデオよりも３秒遅れている場合には、方法は、それが再生を開始してスタッタリングを回避するのに十分なバッファーを備えている場合でも、その３秒の持続時間の間、待つことができる。そのような一実施形態において、送信装置は、情報をクライアント装置にヘッダーとして送信する。所与の加速率に対して、音声ビデオ関係について１つのヘッダー、始動プロファイルバッファー時間について１つのヘッダーである。
【００７２】
そのような一実施形態において、送信装置は、ファイル中の音声およびビデオパケットの提示時間における差を観察することによって、ビデオに対する音声の遅れの定量化を試みる。
【００７３】
特定の実施形態において、音声パケットに遭遇する度に、方法は、最新のビデオパケットと音声パケットの間の提示時間の差を計算する。この値が正である（ビデオ提示時間が音声提示時間よりも大きい）ときには、ビデオサンプルに対応する音声データは、ファイルのより内部のある箇所、すなわち将来のある時点にあり、クライアント装置は、音声とビデオを同期させられるために、その音声を待たなければならない。方法は、第１ステップで計算される値の最大値を、音声がビデオに対してどのくらい遅れているかの最悪測度として、保管することができる。次いで、方法では、音声遅れの最大値をクライアント装置に送ることができる。
【００７４】
特定の実施形態では、音声サンプルを識別する度に、この計算を反復して、サンプルはその時間量だけ遅れて送信されて音声の遅れにさらに寄与することになるので、次いで、計算値に送信時間における差を加えることができる。
【００７５】
別の実施形態においては、ビデオサンプルは、音声サンプルが散在するいくつかのパケットにわたって広がっている。この計算によって、所与の提示時間における最後のビデオパケットを発見して、それを音声提示時間と比較することができる。
【００７６】
動作２１２では、測定バッファー持続時間に基づいてマルチメディアの提示を開始する。提示は、短縮した時間で開始し、同時に提示中のスタッターを軽減および／または回避することができる。
【００７７】
（第２の例示的方法および実装）
図３は、メディアストリームから得られるメディアの提示の一方法による、動作のフローチャートである。
【００７８】
動作３０２において、マルチメディアを提示するように構成された下流構成要素においてマルチメディアが受信される速度（測定速度）が測定される。マルチメディアが受信される速度の測定は、任意適当な手段を用いて達成することができる。比較位置において受信速度を測定することによって、仲介事象または条件によって発生するものなどの、不一致を低減することが可能となり、これらの不一致は、さらに上流でそのような速度を推定する試みの精度を低下させる可能性がある。
【００７９】
動作３０４では、提示の前に受信メディアをバッファリングするための持続時間が求められる。一実施形態においては、方法は、ストリーミングメディアのバッファリングを開始して、再生を開始する前に、測定受信速度に基づいてバッファリングするための持続時間を計算する。バッファー保持時間計算における測定速度を使用すると、始動時間が減少するとともに、提示のスタッタリングを回避することもできる。動作３０２および３０４を、メディアの提示を開始する前に、複数回、反復することによって、バッファー持続時間をさらに正確に求めることができる。
【００８０】
（コンピュータ処理環境）
本明細書に記載する、１つまたは複数の実施形態は、その他多数の汎用または専用のコンピュータ処理システム環境または構成によって実施することができる。使用に適する周知のコンピュータ処理システム、環境、および／または構成の例としては、それに限定はされないが、パーソナルコンピュータ、サーバコンピュータ、シンクライアント（ｔｈｉｎ ｃｌｉｅｎｔ）、シッククライアント（ｔｈｉｃｋ ｃｌｉｅｎｔ）、ハンドヘルドまたはラップトップデバイス、セルフォン、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能大衆消費電子製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上述の任意のシステムまたはデバイスを含む分散コンピュータ処理環境、その他がある。
【００８１】
本明細書に記載する、１つまたは複数の実施形態は、タスクが通信ネットワークを介して連結されたリモート処理デバイスで実施される、分散コンピュータ処理環境において実施することもできる。分散コンピュータ処理環境において、プログラムモジュールは、記憶装置を含む、局所および遠隔のコンピュータ記憶媒体の両方に配置することができる。
【００８２】
本明細書に記載する、１つまたは複数の実施形態は、プログラムモジュールなどの、プロセッサまたはコンピュータによって実行されるプロセッサ実行可能命令の一般文脈で説明することができる。一般に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データタイプおよびファンクションを実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、などを含む。通常、プログラムモジュールの機能は、組み合わせるか、または必要に応じて様々な実施形態に分散させることができる。
【００８３】
（結論）
上述の実施形態によって、メディアコンテンツを実際に利用者に提示するように構成された装置は、メディアを利用者に提示する前に、メディアストリームをバッファリングする持続時間に関する最終決定を行うことができる。そのような構成によって、バッファー持続時間を低減するとともに、同時に提示中のスタッタリングを軽減および／または回避することができる。
【００８４】
発明の概念を構造特徴および／または手順動作に固有の言語で説明したが、添付のクレームに説明された発明の概念は、説明した特定の機構または動作に必ずしも限定されるものではないことを理解すべきである。そうではなく、特定の機構および動作は、請求した発明の概念を実施する例示的な形態として開示したものである。
【図面の簡単な説明】
【００８５】
【図１】本明細書において説明する少なくとも１つの実施形態を（完全または部分的に）実施することができる例示的メディアストリームのネットワークトポロジーを例示する概略の図である。
【図１Ａ】本明細書において説明する少なくとも１つの実施形態を（完全または部分的に）実施することができる例示的メディアストリームのネットワークトポロジーを例示する概略の図である。
【図２】本明細書において説明する手順の実施形態を例示するフローチャートである。
【図３】本明細書において説明する手順の実施形態を例示するフローチャートである。
【特許請求の範囲】
【請求項１】
プロセッサ実行可能命令を有するコンピュータ読取可能な媒体であって、プロセッサにより実行されると、
マルチメディアを利用者に提示するように構成された下流構成要素においてマルチメディアストリームが受信される速度（測定速度）を測定する動作と、
少なくとも部分的に前記測定速度を使用して、マルチメディアの提示前に前記受信されるマルチメディアをバッファリングする持続時間（測定持続時間）を確認する動作と
を備えた方法を実行することを特徴とするコンピュータ読取可能な媒体。
【請求項２】
前記測定する動作前に、推定加速率における提示のための蓄積バッファー量を提供する助言データを受信する動作をさらに備えたことを特徴とする請求項１に記載のコンピュータ読取可能な媒体。
【請求項３】
少なくとも部分的には前記推定加速率および前記蓄積バッファー量によって、提示前に前記受信されるマルチメディアをバッファリングするための推定持続時間を決定する動作をさらに備えたことを特徴とする請求項２に記載のコンピュータ読取可能な媒体。
【請求項４】
前記測定する動作前に、１つまたは複数の加速率にデータ配列を提供する助言データを受信する動作をさらに備え、および個々の加速率に対して、前記データ配列が、対応するアンダーフローバイト値と、前記アンダーフローバイト値が発生する場合の提示における時間と、前記ストリーム中の所与の時点に対する平均データ速度とを含むことを特徴とする請求項１に記載のコンピュータ読取可能な媒体。
【請求項５】
前記データ配列の加速率の各々に対して、提示前に前記受信されるマルチメディアをバッファリングするための推定持続時間を決定する動作をさらに備えたことを特徴とする請求項４に記載のコンピュータ読取可能な媒体。
【請求項６】
前記測定持続時間を決定する動作が、高いデータ配列加速率と低いデータ配列加速率との間で前記測定速度を補間する動作を含むことを特徴とする請求項５に記載のコンピュータ読取可能な媒体。
【請求項７】
請求項１に記載の媒体を備えることを特徴とするコンピュータ処理装置。
【請求項８】
ソースと関連付けられた新規マルチメディアストリームの迅速始動を容易にする方法であって、
マルチメディアストリームの受信を要求するステップと、
前記マルチメディアストリームに関係する助言データを受信するステップと、
前記マルチメディアストリームの受信およびバッファリングを開始するステップと、
前記マルチメディアストリームが受信されている速度（測定速度）を確認するステップと、
少なくとも部分的には前記測定速度によって、前記マルチメディアストリームをバッファリングする持続時間（測定持続時間）を計算するステップと、
前記測定持続時間によって、前記マルチメディアの提示を始動させるステップと
を備えたことを特徴とする方法。
【請求項９】
前記受信するステップが、前記マルチメディアの提示の開始前に、上流構成要素がマルチメディアを流そうと意図する推定加速率に対する推定バッファー持続時間を含む助言データを受信するステップを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記受信するステップが、加速率のデータ配列を含む助言データを受信するステップを含み、個々の加速率が、提示に対する蓄積バッファー量に関連付けられ、および前記データ配列は、上流構成要素がマルチメディアを流そうと意図する推定加速率と、前記上流構成要素が前記推定加速率を維持しようとする加速間隔とをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１１】
前記開始前に、前記データ配列の加速率に対して、前記マルチメディアの提示を開始する前の推定バッファー保持時間を、少なくとも部分的に前記助言データから決定するステップをさらに備えたことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記受信するステップが、複数の加速率に関係する始動プロファイルを含む助言データを受信するステップを含み、および前記計算するステップが、
前記測定速度よりも高い値を有する複数の加速率の第１と、前記測定速度よりも低い値を有する複数の加速率の第２との間で測定速度を補間するステップと、
前記第１および第２の加速率の両方を満足するための前記測定持続時間を選択するステップと
を含むことを特徴とする請求項８に記載の方法。
【請求項１３】
前記計算するステップが、
第１の測定持続時間を計算するステップと、
第１の測定持続時間に到達する前に、第２のその後の測定速度を確認し、および第２の測定持続時間を計算するステップと
を含み、前記始動させるステップが、前記第２の測定持続時間によって行われることを特徴とする請求項８に記載の方法。
【請求項１４】
請求項８に記載の方法を実行するように構成されたことを特徴とするコンピュータ処理装置。
【請求項１５】
マルチメディアストリームのバッファリングの持続時間を、マルチメディアを提示する前に決定するステップと、
前記マルチメディアを受信し始める後であるが、前記マルチメディアを提示し始める前に、前記持続時間を検証するステップと
を備えた、コンピュータで実行される方法。
【請求項１６】
前記検証するステップが、
前記マルチメディアが受信されている速度（測定速度）を測定するステップと、
前記測定速度を、前記マルチメディアが受信される推定速度と比較するステップと
を含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記決定するステップおよび検証するステップが、単一の構成要素によって達成されることを特徴とする請求項１５に記載の方法。
【請求項１８】
マルチメディアを伝送するように構成された送信装置と、
前記マルチメディアを受信して前記マルチメディアを利用者に提示するように構成され、マルチメディアを受信している測定速度を確認し、少なくとも部分的には前記測定速度によって、前記マルチメディアを提示し始める前に前記マルチメディアをバッファリングすべき長さを計算するように構成された受信装置と
を備えたシステム。
【請求項１９】
前記送信装置が、サーバを含むことを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記送信装置は、エンコードされたマルチメディアにアクセスして、前記エンコードされたマルチメディアを前記受信装置に伝送するように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２１】
前記送信装置は、前記エンコードマルチメディアを前記受信装置に伝送する前に、前記マルチメディアをエンコードするように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２２】
前記送信装置は、ライブエンコードセッションからの前記マルチメディアにアクセスするように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２３】
前記送信装置は、ファイルからの前記マルチメディアにアクセスするように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２４】
前記受信装置は、パーソナルコンピュータを含むことを特徴とする請求項１８に記載のシステム。
【請求項２５】
前記受信装置は、セットトップボックスを含むことを特徴とする請求項１８に記載のシステム。
【請求項２６】
前記受信装置は、セルラー電話を含むことを特徴とする請求項１８に記載のシステム。
【請求項２７】
前記受信装置は、前記送信装置から受信される前記マルチメディアをデコードするように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２８】
前記送信装置は、前記マルチメディアの提示と関連付けられたバッファー値に関する情報を送信するように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２９】
前記送信装置は、ファイルに含まれた前記マルチメディアの提示に関連付けられたヘッダー情報にアクセスして、前記情報の要約を前記受信装置に送信するように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項３０】
前記要約は、少なくとも１つの加速率と前記マルチメディアの前記提示に関連付けられた要約されたバッファー値とを含んでいる少なくとも１つのデータ配列を含むことを特徴とする請求項２９に記載のシステム。
【請求項３１】
前記要約は、１つまたは複数の加速率と、前記マルチメディアの前記提示に関連する関連バッファー値と、または前記バッファー値と関連付けられた前記提示における時間とを含んでいる少なくとも１つのデータ配列を含むことを特徴とする請求項２９に記載のシステム。
【請求項３２】
前記送信装置は、前記マルチメディアデータを伝送しようとする推定加速率と、前記推定加速率で伝送することを計画する保持時間とを送信するように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項３３】
前記送信装置と前記受信装置とを結合させ、前記送信手段からの伝送速度を前記受信装置における測定速度よりも大きくさせることができる伝送手段をさらに備えたことを特徴とする請求項１８に記載のシステム。
【請求項３４】
マルチメディアストリームを受信してバッファリングし、および前記マルチメディアのある量の装置をバッファリングした後に、利用者に対して前記マルチメディアの提示を開始するように構成された下流構成要素と、
前記マルチメディアにアクセスして、前記マルチメディアを前記下流構成要素に流すように構成され、アンダーフロー条件を軽減するために前記提示の１つまたは複数の時点における推奨バッファー量に関係する少なくとも１つの始動プロファイルを取得するように構成された上流構成要素と
を備えたシステム。
【請求項３５】
前記少なくとも１つの始動プロファイルは、前記マルチメディアストリームの潜在的ストリーミング速度に関係する複数の始動プロファイルを含むことを特徴とする請求項３４に記載のシステム。
【請求項３６】
前記上流構成要素は、前記少なくとも１つの始動ファイルを含むことを特徴とする請求項３４に記載のシステム。
【請求項３７】
前記上流構成要素は、少なくとも部分的には前記少なくとも１つの始動プロファイルによって、前記量の装置をバッファリングするための推定バッファー時間を計算することを特徴とする請求項３４に記載のシステム。
【請求項３８】
前記上流構成要素は、少なくとも部分的には前記少なくとも１つの始動プロファイルによって、前記量の装置をバッファリングするための推定バッファー時間を計算し、および前記推定バッファー時間を前記下流構成要素に渡し、前記下流構成要素は、前記推定バッファー時間に従って、前記推定バッファー時間をさらに計算するまたは検証することなくバッファリングすることを特徴とする請求項３４に記載のシステム。
【請求項３９】
前記上流構成要素は、少なくとも部分的には前記少なくとも１つの始動プロファイルによって、前記量の装置をバッファリングするための推定バッファー時間を計算し、および前記推定バッファー時間を、前記推定バッファー時間に従ってバッファリングを開始する前記下流構成要素に渡し、前記下流構成要素は、提示を開始する前に、前記推定バッファー時間を検証することを特徴とする請求項３４に記載のシステム。
【請求項４０】
前記下流構成要素は、少なくとも部分的には前記少なくとも１つの始動プロファイルによって、前記量の装置をバッファリングするための推定バッファー時間を計算することを特徴とする請求項３４に記載のシステム。
【請求項４１】
前記下流構成要素は、少なくとも部分的には前記マルチメディアストリームを受信している測定速度によって、前記装置量をバッファリングするための第２のバッファー時間を計算することによって、前記推定バッファー時間を検証するように構成されていることを特徴とする請求項４０に記載のシステム。
【請求項４２】
前記下流構成要素は、前記マルチメディアストリームの特性によって、前記第２のバッファー時間を越えて、前記提示の開始を遅らせるように構成されていることを特徴とする請求項４１に記載のシステム。
【請求項４３】
前記特性は、１つまたは複数の送信チャンクサイズ、または音声およびビデオの少なくとも一方の分離を含むことを特徴とする請求項４２に記載のシステム。
【請求項１】
プロセッサ実行可能命令を有するコンピュータ読取可能な媒体であって、プロセッサにより実行されると、
マルチメディアを利用者に提示するように構成された下流構成要素においてマルチメディアストリームが受信される速度（測定速度）を測定する動作と、
少なくとも部分的に前記測定速度を使用して、マルチメディアの提示前に前記受信されるマルチメディアをバッファリングする持続時間（測定持続時間）を確認する動作と
を備えた方法を実行することを特徴とするコンピュータ読取可能な媒体。
【請求項２】
前記測定する動作前に、推定加速率における提示のための蓄積バッファー量を提供する助言データを受信する動作をさらに備えたことを特徴とする請求項１に記載のコンピュータ読取可能な媒体。
【請求項３】
少なくとも部分的には前記推定加速率および前記蓄積バッファー量によって、提示前に前記受信されるマルチメディアをバッファリングするための推定持続時間を決定する動作をさらに備えたことを特徴とする請求項２に記載のコンピュータ読取可能な媒体。
【請求項４】
前記測定する動作前に、１つまたは複数の加速率にデータ配列を提供する助言データを受信する動作をさらに備え、および個々の加速率に対して、前記データ配列が、対応するアンダーフローバイト値と、前記アンダーフローバイト値が発生する場合の提示における時間と、前記ストリーム中の所与の時点に対する平均データ速度とを含むことを特徴とする請求項１に記載のコンピュータ読取可能な媒体。
【請求項５】
前記データ配列の加速率の各々に対して、提示前に前記受信されるマルチメディアをバッファリングするための推定持続時間を決定する動作をさらに備えたことを特徴とする請求項４に記載のコンピュータ読取可能な媒体。
【請求項６】
前記測定持続時間を決定する動作が、高いデータ配列加速率と低いデータ配列加速率との間で前記測定速度を補間する動作を含むことを特徴とする請求項５に記載のコンピュータ読取可能な媒体。
【請求項７】
請求項１に記載の媒体を備えることを特徴とするコンピュータ処理装置。
【請求項８】
ソースと関連付けられた新規マルチメディアストリームの迅速始動を容易にする方法であって、
マルチメディアストリームの受信を要求するステップと、
前記マルチメディアストリームに関係する助言データを受信するステップと、
前記マルチメディアストリームの受信およびバッファリングを開始するステップと、
前記マルチメディアストリームが受信されている速度（測定速度）を確認するステップと、
少なくとも部分的には前記測定速度によって、前記マルチメディアストリームをバッファリングする持続時間（測定持続時間）を計算するステップと、
前記測定持続時間によって、前記マルチメディアの提示を始動させるステップと
を備えたことを特徴とする方法。
【請求項９】
前記受信するステップが、前記マルチメディアの提示の開始前に、上流構成要素がマルチメディアを流そうと意図する推定加速率に対する推定バッファー持続時間を含む助言データを受信するステップを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記受信するステップが、加速率のデータ配列を含む助言データを受信するステップを含み、個々の加速率が、提示に対する蓄積バッファー量に関連付けられ、および前記データ配列は、上流構成要素がマルチメディアを流そうと意図する推定加速率と、前記上流構成要素が前記推定加速率を維持しようとする加速間隔とをさらに含むことを特徴とする請求項８に記載の方法。
【請求項１１】
前記開始前に、前記データ配列の加速率に対して、前記マルチメディアの提示を開始する前の推定バッファー保持時間を、少なくとも部分的に前記助言データから決定するステップをさらに備えたことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記受信するステップが、複数の加速率に関係する始動プロファイルを含む助言データを受信するステップを含み、および前記計算するステップが、
前記測定速度よりも高い値を有する複数の加速率の第１と、前記測定速度よりも低い値を有する複数の加速率の第２との間で測定速度を補間するステップと、
前記第１および第２の加速率の両方を満足するための前記測定持続時間を選択するステップと
を含むことを特徴とする請求項８に記載の方法。
【請求項１３】
前記計算するステップが、
第１の測定持続時間を計算するステップと、
第１の測定持続時間に到達する前に、第２のその後の測定速度を確認し、および第２の測定持続時間を計算するステップと
を含み、前記始動させるステップが、前記第２の測定持続時間によって行われることを特徴とする請求項８に記載の方法。
【請求項１４】
請求項８に記載の方法を実行するように構成されたことを特徴とするコンピュータ処理装置。
【請求項１５】
マルチメディアストリームのバッファリングの持続時間を、マルチメディアを提示する前に決定するステップと、
前記マルチメディアを受信し始める後であるが、前記マルチメディアを提示し始める前に、前記持続時間を検証するステップと
を備えた、コンピュータで実行される方法。
【請求項１６】
前記検証するステップが、
前記マルチメディアが受信されている速度（測定速度）を測定するステップと、
前記測定速度を、前記マルチメディアが受信される推定速度と比較するステップと
を含むことを特徴とする請求項１５に記載の方法。
【請求項１７】
前記決定するステップおよび検証するステップが、単一の構成要素によって達成されることを特徴とする請求項１５に記載の方法。
【請求項１８】
マルチメディアを伝送するように構成された送信装置と、
前記マルチメディアを受信して前記マルチメディアを利用者に提示するように構成され、マルチメディアを受信している測定速度を確認し、少なくとも部分的には前記測定速度によって、前記マルチメディアを提示し始める前に前記マルチメディアをバッファリングすべき長さを計算するように構成された受信装置と
を備えたシステム。
【請求項１９】
前記送信装置が、サーバを含むことを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記送信装置は、エンコードされたマルチメディアにアクセスして、前記エンコードされたマルチメディアを前記受信装置に伝送するように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２１】
前記送信装置は、前記エンコードマルチメディアを前記受信装置に伝送する前に、前記マルチメディアをエンコードするように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２２】
前記送信装置は、ライブエンコードセッションからの前記マルチメディアにアクセスするように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２３】
前記送信装置は、ファイルからの前記マルチメディアにアクセスするように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２４】
前記受信装置は、パーソナルコンピュータを含むことを特徴とする請求項１８に記載のシステム。
【請求項２５】
前記受信装置は、セットトップボックスを含むことを特徴とする請求項１８に記載のシステム。
【請求項２６】
前記受信装置は、セルラー電話を含むことを特徴とする請求項１８に記載のシステム。
【請求項２７】
前記受信装置は、前記送信装置から受信される前記マルチメディアをデコードするように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２８】
前記送信装置は、前記マルチメディアの提示と関連付けられたバッファー値に関する情報を送信するように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項２９】
前記送信装置は、ファイルに含まれた前記マルチメディアの提示に関連付けられたヘッダー情報にアクセスして、前記情報の要約を前記受信装置に送信するように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項３０】
前記要約は、少なくとも１つの加速率と前記マルチメディアの前記提示に関連付けられた要約されたバッファー値とを含んでいる少なくとも１つのデータ配列を含むことを特徴とする請求項２９に記載のシステム。
【請求項３１】
前記要約は、１つまたは複数の加速率と、前記マルチメディアの前記提示に関連する関連バッファー値と、または前記バッファー値と関連付けられた前記提示における時間とを含んでいる少なくとも１つのデータ配列を含むことを特徴とする請求項２９に記載のシステム。
【請求項３２】
前記送信装置は、前記マルチメディアデータを伝送しようとする推定加速率と、前記推定加速率で伝送することを計画する保持時間とを送信するように構成されていることを特徴とする請求項１８に記載のシステム。
【請求項３３】
前記送信装置と前記受信装置とを結合させ、前記送信手段からの伝送速度を前記受信装置における測定速度よりも大きくさせることができる伝送手段をさらに備えたことを特徴とする請求項１８に記載のシステム。
【請求項３４】
マルチメディアストリームを受信してバッファリングし、および前記マルチメディアのある量の装置をバッファリングした後に、利用者に対して前記マルチメディアの提示を開始するように構成された下流構成要素と、
前記マルチメディアにアクセスして、前記マルチメディアを前記下流構成要素に流すように構成され、アンダーフロー条件を軽減するために前記提示の１つまたは複数の時点における推奨バッファー量に関係する少なくとも１つの始動プロファイルを取得するように構成された上流構成要素と
を備えたシステム。
【請求項３５】
前記少なくとも１つの始動プロファイルは、前記マルチメディアストリームの潜在的ストリーミング速度に関係する複数の始動プロファイルを含むことを特徴とする請求項３４に記載のシステム。
【請求項３６】
前記上流構成要素は、前記少なくとも１つの始動ファイルを含むことを特徴とする請求項３４に記載のシステム。
【請求項３７】
前記上流構成要素は、少なくとも部分的には前記少なくとも１つの始動プロファイルによって、前記量の装置をバッファリングするための推定バッファー時間を計算することを特徴とする請求項３４に記載のシステム。
【請求項３８】
前記上流構成要素は、少なくとも部分的には前記少なくとも１つの始動プロファイルによって、前記量の装置をバッファリングするための推定バッファー時間を計算し、および前記推定バッファー時間を前記下流構成要素に渡し、前記下流構成要素は、前記推定バッファー時間に従って、前記推定バッファー時間をさらに計算するまたは検証することなくバッファリングすることを特徴とする請求項３４に記載のシステム。
【請求項３９】
前記上流構成要素は、少なくとも部分的には前記少なくとも１つの始動プロファイルによって、前記量の装置をバッファリングするための推定バッファー時間を計算し、および前記推定バッファー時間を、前記推定バッファー時間に従ってバッファリングを開始する前記下流構成要素に渡し、前記下流構成要素は、提示を開始する前に、前記推定バッファー時間を検証することを特徴とする請求項３４に記載のシステム。
【請求項４０】
前記下流構成要素は、少なくとも部分的には前記少なくとも１つの始動プロファイルによって、前記量の装置をバッファリングするための推定バッファー時間を計算することを特徴とする請求項３４に記載のシステム。
【請求項４１】
前記下流構成要素は、少なくとも部分的には前記マルチメディアストリームを受信している測定速度によって、前記装置量をバッファリングするための第２のバッファー時間を計算することによって、前記推定バッファー時間を検証するように構成されていることを特徴とする請求項４０に記載のシステム。
【請求項４２】
前記下流構成要素は、前記マルチメディアストリームの特性によって、前記第２のバッファー時間を越えて、前記提示の開始を遅らせるように構成されていることを特徴とする請求項４１に記載のシステム。
【請求項４３】
前記特性は、１つまたは複数の送信チャンクサイズ、または音声およびビデオの少なくとも一方の分離を含むことを特徴とする請求項４２に記載のシステム。
【図１】
【図１Ａ】
【図２】
【図３】
【図１Ａ】
【図２】
【図３】
【公開番号】特開２００６−１１５４７７（Ｐ２００６−１１５４７７Ａ）
【公開日】平成１８年４月２７日（２００６．４．２７）
【国際特許分類】
【外国語出願】
【出願番号】特願２００５−２５９１０９（Ｐ２００５−２５９１０９）
【出願日】平成１７年９月７日（２００５．９．７）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成１８年４月２７日（２００６．４．２７）
【国際特許分類】
【出願番号】特願２００５−２５９１０９（Ｐ２００５−２５９１０９）
【出願日】平成１７年９月７日（２００５．９．７）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]