JP6425649B2 - Ｈｔｔｐ疑似ストリーミング用の一体型コントローラベースのペーシング - Google Patents

Description

本発明は、概ね、通信ネットワークに関し、より具体的には、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）疑似ストリーミングのための一体型コントローラベースのペーシングに関する。

ダウンロードに対するストリーミングの最大の利点は、プレーヤーにまだダウンロードされていない位置をタイムライン中で検索できることである。これは、訪問者が望む場合、２時間の映画の最後のシーンを検索することができるため、ノーカット映画に最も所望である。ＨＴＴＰ疑似ストリーミングは、純粋なＨＴＴＰダウンロードの利点（例えば、それは、あらゆるファイアウォールを通過する、接続不良にある視聴者はただダウンロードを待つことができる）と、ダウンロードされない部分を検索する能力とを兼ね備える。

ＨＴＴＰ疑似ストリーミングは、伝送プロトコルとして、バルクデータ転送のために本来設計された伝送制御プロトコル（ＴＣＰ）を使用する。同様に、ＴＣＰは、ペイロード内のメディアのタイミング情報を明示的に示さない。ＴＣＰは、単に、メディアクリップ（例えば、．ｆｌｖまたは．ｍｐ４ファイルなど）を転送するために使用される。メディア時間情報は、無条件にメディアクリップ形式で送信され、プレーヤーは、その一部分がダウンロードされるように、単純にクリップを再生する。

ＨＴＴＰ疑似ストリーミングは、ＴＣＰ上のストリーミングメディアのダウンロードを制御するためにＨＴＴＰを使用する。ストリーミングクライアントは、多くの場合、ＨＴＴＰによって疑似ストリーミングサーバに渡されるＨＴＴＰ要求内のＵＲＬのオプションとして、所望のメディア検索位置情報を提供する。疑似ストリーミングサーバは、所望の検索位置から再生するメディアクリップを準備して、ＨＴＴＰ経由で伝送するためにその情報を使用する。

専らＴＣＰ上のストリーミングメディアの伝送に依存するＨＴＴＰ疑似ストリーミングは、所望の目標ストリーミングビットレートを維持することができないが、多くの場合、目標ビットレートよりもはるかに高い利用可能なリンク速度で、多くの場合、クライアントにメディアを配信する。これは、視聴者がメディアへの関心を失い、伝送を停止するとき、帯域幅の浪費をもたらす可能性がある。このように、所望のビットレートにメディアの伝送速度を制御するための伝送ペーシング機構は、ＨＴＴＰ疑似ストリーミングに非常に望ましい。

一般に、速度制御は、パケットネットワーク上でのメディアストリーミングのために不可欠である。容量が制限された、共有リンクを介したマルチメディアのように帯域幅集約型コンテンツの配信における課題は、ユーザの視聴体験を最適化するように、ビットレートおよびメディア符号化方式を調整することによってネットワーク状態の変化に迅速に対応することである。具体的には、必要な処理能力を提供することができない接続を介してメディアストリームを転送するとき、いくつかの所望でない影響が生じる。例えば、ネットワークバッファがオーバーフローし、不明瞭なビデオまたはオーディオの再生を引き起こすパケットロスをもたらし得る、またはメディアプレーヤーバッファがアンダーフローし、再生の失速をもたらし得る。

以下に、本発明のいくつかの態様の基本的な理解を提供するために技術革新の簡略化した概要を提示する。本要約は、本発明の広範な概要ではない。本発明の主要なまたは重要な要素を特定することも、本発明の範囲を線引きすることも意図されていない。その唯一の目的は、後ほど提示されるより詳細な説明の前置きとして、簡略化された形態で本発明のいくつかの概念を提示することである。

本発明は、ＨＴＴＰ疑似ストリーミングのための一体型コントローラベースのペーシングのためのコンピュータプログラム製品を含む方法および装置を提供する。

一般に、一態様では、本発明は、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）ストリーミングのための一体型コントローラベースペーシングマネージャおよびコンテンツサーバにリンクされたユーザ機器を含むネットワーク内で、ユーザ機器内に存在するメディアプレーヤーからコンテンツサーバ内に存在するマルチメディアクリップの要求部分を受信することと、ネットワーク内の制御ノイズの存在下で目標ビットレートを維持しつつ、メディアプレーヤーにマルチメディアクリップの要求された部分を配信することとを含む方法を特徴とする。マルチメディアクリップの要求された部分を配信することは、目標伝送速度を推定することと、目標弾性バッファを判定することと、現在の伝送エポック中に送信するためのバイト数を推定することとを含み得る。

本発明の他の特徴および利点は、以下の説明および特許請求の範囲から明らかである。

本発明は、以下の図面と併せて、詳細な説明を参照することによって更に十分に理解されるであろう。

ブロック図である。 ブロック図である。 フロー図である。

主題の技術革新は、図面を参照してここに説明され、同様の参照番号は、全体を通して同様の要素を参照するように使用される。以下の記載において、説明の目的で、多数の特定の詳細が本発明の完全な理解を提供するために記載される。しかしながら、本発明がこれらの特定の詳細を伴わずに実施され得ることは明らかであり得る。他の例において、よく知られた構造およびデバイスが、本発明の説明を容易にするためにブロック図形態で示される。

本出願で使用されるとき、「構成要素」、「システム」、「プラットフォーム」などの用語は、コンピュータに関連する実体または１つ以上の特定の機能を有する動作可能機械に関連する実体を指し得る。本明細書に開示された実体は、ハードウェア、ハードウェアおよびソフトウェアの組み合わせ、ソフトウェア、または実行中のソフトウェアのいずれかであり得る。例えば、構成要素は、プロセッサ上で実行されるプロセス、プロセッサ、オブジェクト、実行ファイル、実行のスレッド、プログラム、および／またはコンピュータであり得るが、これらに限定されない。例示として、サーバ上で実行されるアプリケーションおよびそのサーバの両方が、構成要素であり得る。１つ以上の構成要素が実行のプロセスおよび／またはスレッド内に存在し得、構成要素が１つのコンピュータ上で局在化され得、および／または２つ以上のコンピュータ間に分散され得る。また、これらの構成要素は、中に記憶された様々なデータ構造を有する様々なコンピュータ可読媒体から実行することができる。構成要素は、１つ以上のデータパケット（例えば、ローカルシステム内の別の構成要素、分散システム、および／またはシグナルを介して他のシステムを有するインターネットなどのネットワーク全体と相互作用する１つの構成要素からのデータ）を有するシグナルに従って、ローカルおよび／またはリモートプロセスを介して通信し得る。

加えて、「または」という用語は排他的な「または」より包括的な「または」を意味するように意図される。すなわち、特に指定がない、または文脈から明らかでない限り、「Ｘは、ＡまたはＢを使用する」は任意の自然な包括的順列を意味することが意図される。すなわち、ＸがＡを使用する、ＸがＢを使用する、あるいはＸがＡおよびＢの両方を使用する場合、「ＸはＡまたはＢを使用する」は、前述の例のいずれかの下で満たされる。更に、主題の明細書および添付される図面で使用される冠詞「ａ」および「ａｎ」は、特に単数形を対象とするとの指定がない、または文脈から明らかでない限り、一般に、「１つ以上」を意味すると解釈されるべきである。

更に、「ユーザ機器」、「携帯局」、「携帯」、「加入者局」、「通信デバイス」、「アクセス端末」、「端末」、「ハンドセット」、および類似の用語などの用語は、データ、制御、音声、ビデオ、音響、ゲーム、または実質的に任意のデータストリームもしくはシグナリングストリームを受信または伝達するために無線通信サービスの加入者またはユーザによって利用される無線デバイス（例えば、携帯電話、スマートフォン、コンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、セットトップボックス、インターネットプロトコルテレビジョン（ＩＰＴＶ）、電子ゲーム機、プリンタなど）を指す。前述の用語は、主題の明細書および関連する図面において同義的に利用される。同様に、「アクセスポイント」、「基地局」、「ノードＢ」、「進化ノードＢ」、「ホームノードＢ（ＨＮＢ）」などの用語は、主題の出願において同義的に使用され、データ、制御、音声、ビデオ、音響、ゲーム、または１組の加入者局からの実質的に任意のデータストリームもしくはシグナリングストリームを送り、受信する無線ネットワーク構成要素または器具を指す。データおよびシグナリングストリームは、パケット化されたまたはフレームベースのフローであり得る。

更に、「ユーザ」、「加入者」、「顧客」などの用語は、文脈が用語間で特に区別（複数可）を必要としない限り、主題の明細書全体を通して同義的に使用される。

図１に示すように、例示的なシステム１００として、とりわけ、端末１０２、ゲートウェイ１０４、１つ以上のネットワーク１０６、１１０、一体型コントローラベースのペーシングマネージャ１０８、および１つ以上のコンテンツサーバ１１２〜１１４が挙げられる。

端末１０２は、端末１０２が通信し、ストリーミングメディアに対応するパケットを受信することを可能にするソフトウェアアプリケーションを含むハードウェア構成要素である。端末１０２は、端末１０２のユーザにストリーミングメディアを表示するためのディスプレイ、およびメディアプレーヤーなどの１つ以上のソフトウェアアプリケーションを提供する。更に、端末１０２は、ストリーミングメディアのデータパケットなどのデータパケットを要求して、インターネットから受信する能力を有する。例えば、端末１０２は、そのユニバーサルリソースロケータ（ＵＲＬ）によって特定のファイルまたはウェブページの対象データについてコンテンツサーバ１１２〜１１４に要求データを送信することができ、ウェブページのコンテンツサーバは、データベース内の対象データを照会し、端末１０２に対応する応答データを送信することができる。いくつかの実施形態において、応答データが、一体型コントローラベースのペーシングマネージャ１０８を介してルーティングされ得る。

端末１０２は有線端末であり得るが、一方、携帯端末は、一体型コントローラベースのペーシングマネージャ１０８からより多くの利益を得るであろうネットワーク内にある可能性がより高いため、本発明の実施形態は、携帯端末を使用することを含み得る。携帯ネットワーク内のネットワーク接続は、例えば、携帯端末の変動する位置のために、有線ネットワーク接続と比較してより不安定である傾向があり、携帯端末とネットワークとの間のデータ速度伝送は、場合によっては非常に劇的に変動し得る。

ゲートウェイ１０４は、あるタイプのネットワーク内で提供されるフォーマットされたデータを別のタイプのネットワークに必要な特定のフォーマットに変換するデバイスである。ゲートウェイ１０６は、例えば、サーバ、ルータ、ファイアウォールサーバ、ホスト、またはプロキシサーバであり得る。ゲートウェイ１０４は、端末１０２から受信したシグナルをネットワーク１０６が理解できるシグナルへ変換する、かつその逆も行う能力を有する。ゲートウェイ１０４は、オーディオ、ビデオ、Ｔ．１２０伝送を単独または任意の組み合わせで処理することが可能であり得、また全二重メディア翻訳が可能である。

ネットワーク１０６および１１０は、インターネット通信等のパケット型通信（例えば、ＧＳＭ（登録商標）、ＣＤＭＡ、ＬＴＥ、ＷｉＭＡＸなど）に好適な広域ネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、または無線ネットワークの任意の組み合わせを含むことができる。更に、ネットワーク１０６および１１０は、パケットを記憶した後、それらの意図された伝送先にそれらを伝送するためのバッファを含むことができる。

一体型コントローラベースのペーシングマネージャ１０８（Integral controller based pacing manager：ペーシングマネージャに基づく一体型のコントローラ）は、ゲートウェイ１０４とコンテンツサーバ１１２〜１１４との間の通信を提供するサーバである。一体型コントローラベースのペーシングマネージャ１０８は、コンテンツサーバ１１２〜１１４における一時的なネットワークの輻輳または一貫性のないパケットスケジューリングのエポックなどの制御ノイズの存在下で平均目標ビットレートを維持する。特定の一実施形態において、一体型コントローラベースのペーシングマネージャ１０８は、マサチューセッツ州アクトンのＡｆｆｉｒｍｅｄ Ｎｅｔｗｏｒｋｓ， Ｉｎｃ．製のＡＮ−３０００ Ｐｒｏｘｙ Ｃａｃｈｅに実装されている。

コンテンツサーバ１１２〜１１４は、端末１０２から要求データを受信し、それに応じて要求データを処理し、いくつかの実施形態において、一体型コントローラベースのペーシングマネージャ１０８を介して端末１０２に応答データを返すサーバである。例えば、コンテンツサーバ１１２〜１１４は、ウェブサーバ、企業サーバ、または任意の他のタイプのサーバであり得る。コンテンツサーバ１１２〜１１４は、端末１０２からの要求（例えば、ＨＴＴＰ、ＲＴＳＰ、またはメディアセッションを開始することができる他のプロトコル）を受信し、端末１０２にストリーミングメディアを送る役割を担うコンピュータまたはコンピュータプログラムであり得る。

図２に示すように、端末１０２は、とりわけ、メディアプレーヤー２０２およびバッファ２０４を含み得る。一体型コントローラベースのペーシングマネージャ１０８は、とりわけ、プロセッサ２１０およびメモリ２１２を含むことができる。メモリ２１２は、Ｌｉｎｕｘ（登録商標）、Ｕｎｉｘ（登録商標）、またはＷｉｎｄｏｗｓ（登録商標）などのオペレーティングシステム２１４、およびＨＴＴＰ疑似ストリーミングプロセス３００のための一体型コントローラベースのペーシング（pacing：調節）を含むことができる。

メディアプレーヤー２０２は、ビデオおよび／またはオーディオメディアファイルを含むマルチメディアファイル（例えば、ストリーミングメディアなど）を再生するためのコンピュータソフトウェアである。メディアプレーヤー２０２の例としては、Ｍｉｃｒｏｓｏｆｔ（登録商標）ウィンドウズメディアプレーヤー、Ａｐｐｌｅ（登録商標）Ｑｕｉｃｋｔｉｍｅ（登録商標）プレーヤー、ＲｅａｌＯｎｅ（登録商標）プレーヤー、およびウェブに埋め込まれたビデオのためのＡｄｏｂｅ（登録商標）フラッシュプラグインが挙げられる。いくつかの実施形態において、メディアプレーヤー２０２は、コーデックを使用してストリーミングビデオまたはオーディオを解凍し、端末１０２のディスプレイ上でそれを再生する。メディアプレーヤー２０２は、スタンドアロン型アプリケーションとして使用することができる、またはＨＴＭＬコンテンツと相互作用するビデオアプリケーションを作成するためにウェブページに埋め込むことができる。更に、メディアプレーヤー２０２は、メディア受信機レポートの形態で、一体型コントローラベースのペーシングマネージャ１０８にメディア受信についてフィードバックを提供することができる。メディア受信機レポートは、ＲＴＰストリーミングセッションのためのＲＴＣＰパケット、または疑似ストリーミングセッションのためのＴＣＰ ＡＣＫを含み得る。

バッファ２０４（端末バッファ２０４としても知られる）は、ソフトウェアプログラムおよび／またはメディアプレーヤー２０２にマルチメディアパケットを提供する前に、マルチメディアパケットを一時的に記憶するハードウェアデバイスである。いくつかの実施形態において、バッファ２０４は、ネットワーク１０６を介して、一体型コントローラベースのペーシングマネージャ１０８からマルチメディアパケットを受信する。いくつかの実施形態において、バッファ２０４は、一体型コントローラベースのペーシングマネージャ１０８以外のデバイスからマルチメディアパケットを受信する。一旦バッファ２０４がマルチメディアのパケット（または疑似ストリーミングの場合、メディアクリップの一部分）を受信すると、それは、記憶されたマルチメディアのパケットをメディアプレーヤー２０２に提供することができる。端末バッファ２０４およびメディアプレーヤー２０２は、別個の構成要素として示されているが、他の実装においては、端末バッファ２０４は、メディアプレーヤー２０２の一部であり得る。更に、単一のバッファのみでありながら、実装は、複数のバッファ、例えば、オーディオメディアパケットのための１つ以上のバッファおよびビデオメディアパケットのための１つ以上のバッファを含み得る。

ＨＴＴＰ疑似ストリーミングは、コンテンツ全体の前に再生することができるオーディオ／ビデオコンテンツが、単一のＨＴＴＰオブジェクトとして伝送される伝送技術を指す。エアリンクリソースが高価であるため、かつユーザがプレゼンテーションの終了前にコンテンツに興味を失うと、メディアプレゼンテーションがユーザによって中止され得る可能性があるので、特に無線ネットワークのための最初のメディアバッファリング期間後にメディアの符号化ビットレートに近い一定のビットレートでメディア伝送を調整することが望ましい。

ＨＴＴＰ疑似ストリーミングプロセス３００ための一体型コントローラベースのペーシングは、パケット伝送ペーシング技術であり、該技術は、サーバにおける一時的なネットワークの輻輳または一貫性のないパケットスケジュールエポックなどの制御ノイズの存在下で平均目標ビットレートを維持するように、メディアサーバまたはプロキシによって使用され得る。

図３に示すように、プロセス３００は、目標伝送速度を推定（３１０）することを含む。目標伝送速度の推定は、メディアコンテナ（media container：メディア収容部）を解析することによって得ることができるマルチメディアコンテンツのサイズおよび持続時間に関する情報を必要とする。サイズまたは持続時間が、（ライブコンテンツにおいて）利用できない場合、コンテナヘッダ（container header:収容部のヘッダー）内で通知されたメディア符号化ビットレートは、目標伝送速度として使用され得る。目標伝送速度は、不安定なネットワーク状態によるメディアプレゼンテーションの停止を回避するために、メディアの伝送をプレゼンテーション速度よりもわずかに速くするように１を超える因数を適用することによって較正され得る。

プロセス３００は、目標弾性バッファ（target elasticity buffer：目標のエラスティックバッファ）を判定（３１２）する。クライアントによって承認された表示時間からそれを配信するために必要な実測時間を差し引いた時間中に測定されるコンテンツの量は、ディスプレイ弾性バッファと考えることができる。この場合、常に２つの目標、つまり、伝送速度目標および受信機弾性目標が存在する。最初のバッファ充填の間に、伝送速度目標は、典型的には、弾性標的が最初に満たされるときより高くなる。

目標弾性バッファは、受信デバイスのタイプおよび加入者のタイプなどの様々なパラメータに基づいて設定され得る。更に、伝送チャネルは、その配信安定性において特徴づけられ得る。チャネルがより不安定である場合、特定の受信機のための目標弾性バッファが増大され得る。伝送処理能力の傾向の定期的な試料の比較が開発され、目標弾性バッファリングを調整するために使用され得る。例えば、見掛けの受信機の弾力性が減少している場合、伝送速度は、わずかに増加され得る。伝送速度を増加させることは、弾力性を改善しない（または少なくともその低下を遅らせる）場合、更なる伝送速度増加のための理由が存在しない場合がある。

一旦目標伝送ビットレート（ｔａｒｇｅｔ＿ｂｉｔｒａｔｅ）が判定されると、プロセス３００は、以下のように一体型コントローラを使用して、現在の伝送エポック中に送信するためのバイト数を推定する（３１４）。

プロセス３００は、現在の伝送エポック中に送信するためのバイト数（ｂｙｔｅｓ＿ｔｏ＿ｓｅｎｄ＿ｅｐｏｃｈ）を、目標ビットレートに、前記伝送エポックの長さを乗算することによって取得される値へと初期化し、伝送の開始をする（３１６）。各伝送エポック中で

（ａ）平均伝送ビットレートは、伝送された総バイト数を当該総バイト数の伝送にかかる経過時間で除算したものとして算出される（ａｖｅｒａｇｅ＿ｂｉｔｒａｔｅ）である。

（ｂ）一体型制御（integral control）のために、下記のように現在のエポック中に送信するバイト数を更新する：

ｂｙｔｅｓ＿ｔｏ＿ｓｅｎｄ＿ｅｐｏｃｈ＋＝ＩＮＴＥＧＲＡＬ＿ＣＯＮＳＴ（ｔａｒｇｅｔ＿ｂｉｔｒａｔｅ−ａｖｅｒａｇｅ＿ｂｉｔｒａｔｅ）

（ｂｙｔｅｓ＿ｔｏ＿ｓｅｎｄ＿ｅｐｏｃｈ＞ＢＹＴＥＳ＿ＥＰＯＣＨ＿ＭＡＸ）の場合、

ｂｙｔｅｓ＿ｔｏ＿ｓｅｎｄ＿ｅｐｏｃｈ＝ＢＹＴＥＳ＿ＥＰＯＣＨ＿ＭＡＸ

（ｂｙｔｅｓ＿ｔｏ＿ｓｅｎｄ＿ｅｐｏｃｈ＜ＢＹＴＥＳ＿ＥＰＯＣＨ＿ＭＩＮ）の場合、

ｂｙｔｅｓ＿ｔｏ＿ｓｅｎｄ＿ｅｐｏｃｈ＝ＢＹＴＥＳ＿ＥＰＯＣＨ＿ＭＩＮ

ＢＹＴＥＳ＿ＥＰＯＣＨ＿ＭＡＸは、最初のｂｙｔｅｓ＿ｔｏ＿ｓｅｎｄ＿ｅｐｏｃｈに１を超える因数を乗算して設定され、ＢＹＴＥＳ＿ＥＰＯＣＨ＿ＭＩＮは、最初のｂｙｔｅｓ＿ｔｏ＿ｓｅｎｄ＿ｅｐｏｃｈに１を超える因数を乗算して設定される。

（ｃ）更新されたｂｙｔｅｓ＿ｔｏ＿ｓｅｎｄ＿ｅｐｏｃｈの量のコンテンツを伝送する。

プロセス３００は、１つ以上の以下の利点を含む。プロセス３００は、ＴＣＰのようなネットワークレベルのスロットルが存在しないとき、有用である。プロセス３００の１つの長所は、平均目標ビットレートを達成するために、それが、サーバまたはネットワークからのあらゆる小さな制御ノイズに対して回復力があるということである。

プロセス３００は、一時的なエアリンクの輻輳が一般的である無線ネットワークが直面するメディアサーバ／プロキシに有用である。

本明細書に記載されたシステムおよび技術の様々な実装は、デジタル電子回路、集積回路、特別に設計されたＡＳＩＣ（特定用途向け集積回路）、コンピュータハードウェア、ファームウェア、ソフトウェア、および／またはそれらの組み合わせにおいて実現することができる。これらの様々な実装は、少なくとも１つのプログラマブルプロセッサを含むプログラマブルシステム上で実行可能および／または解釈可能である１つ以上のコンピュータプログラムでの実装を含むことができ、該プログラマブルプロセッサは、特殊用途または汎用であり得、少なくとも１つの入力デバイスにおいておよび少なくとも１つの出力デバイスにおいて、データおよび命令を受信するように、ならびにストレージシステムにデータおよび命令を伝送するように結合され得る。

（プログラム、ソフトウェア、ソフトウェアアプリケーション、またはコードとしても知られる）これらのコンピュータプログラムは、プログラマブルプロセッサ用の機械命令を含み、高レベルの手続き型および／またはオブジェクト指向プログラミング言語、および／またはアセンブリ言語／機械語で実装され得る。本明細書で使用されるとき、「機械可読媒体」、「コンピュータ可読媒体」という用語は、プログラマブルプロセッサに機械命令および／またはデータを提供するために使用される任意のコンピュータプログラム製品、装置、および／またはデバイス（例えば、磁気ディスク、光ディスク、メモリ、プログラマブルロジックデバイス（ＰＬＤ））を指し、機械可読シグナルとして機械語命令を受信する機械可読媒体を含む。「機械可読シグナル」という用語は、プログラマブルプロセッサに機械命令および／またはデータを提供するために使用される任意のシグナルを指す。

ユーザとの相互作用を提供するために、本明細書に記載されるシステムおよび技術は、ユーザに情報を表示するための表示デバイス（例えば、ＣＲＴ（陰極線管）またはＬＣＤ（液晶ディスプレイ）モニタ）、ユーザがコンピュータに入力を提供することができるキーボードおよびポインティングデバイス（例えば、マウスまたはトラックボール）を有するコンピュータ上で実装することができる。他の種類のデバイスも同様にユーザとの相互作用を提供するために使用され得、例えば、ユーザに提供されるフィードバックは、感覚フィードバック（例えば、視覚フィードバック、聴覚フィードバック、または触覚フィードバック）の任意の形態であり得、ユーザからの入力は、音響、音声、または触覚入力を含む任意の形態で受信することができる。

本明細書で説明されるシステムおよび技術は、バックエンド構成要素（例えばデータサーバ）を含む、またはミドルウェア構成要素（例えば、アプリケーションサーバ）を含む、またはフロントエンド構成要素（例えば、ユーザが、本明細書に記載されるシステムおよび技術の実装と相互作用することができるグラフィカルユーザインタフェースまたはウェブブラウザを有するクライアントコンピュータ）またはバックエンド、ミドルウェア、もしくはフロントエンド構成要素のあらゆる組み合わせを含むコンピューティングシステム内で実施され得る。システムの構成要素は、任意の形式またはデジタルデータ通信（例えば、通信ネットワーク）の媒体によって相互接続することができる。通信ネットワークの例として、ローカルエリアネットワーク（「ＬＡＮ」）、広域ネットワーク（「ＷＡＮ」）、およびインターネットが挙げられる。

コンピューティングシステムは、クライアントおよびサーバを含むことができる。クライアントおよびサーバは、一般的に、互いに遠隔であり、典型的に、通信ネットワークを介して相互作用する。クライアントおよびサーバの関係は、コンピュータプログラムがそれぞれのコンピュータ上で動作し、互いにクライアント・サーバ関係を有することによって生じる。

前述の説明は、本開示と一致する全ての可能な実装、または記載される実装の全ての可能な変形の網羅的な一覧を表さない。多くの実装を説明してきた。それにもかかわらず、種々の修正が、本明細書に記載されたシステム、デバイス、方法、および技術の趣旨および範囲から逸脱することなく行われ得ることが理解されるであろう。例えば、上に示したフローの種々の形態は、再順序付けされる、追加される、または除去されるステップで使用され得る。従って、他の実装は、以下の特許請求の範囲内にある。

Claims (9)

1. 方法であって、
   ａ．ハイパーテキストトランスファープロトコル（ＨＴＴＰ）ストリーミングのためのペーシングマネージャおよびコンテンツサーバにリンクされたユーザ機器を備えるネットワーク内で、前記ユーザ機器内に存在するメディアプレーヤーから前記コンテンツサーバ内に存在するマルチメディアクリップの複数の部分の要求を受信することと、
   ｂ．前記ペーシングマネージャによって、目標伝送速度を推定することと、
   ｃ．現在の伝送エポック中に送信するためのバイト数を、前記目標伝送速度に、前記伝送エポックの長さを乗算することによって取得される値へと初期化することと、
   ｄ．前記ペーシングマネージャによって、平均伝送速度は、前記現在の伝送エポックに送信された伝送バイトの総数を、伝送にかかる経過時間で除算したものとして、推定されることと、
   ｅ．前記ペーシングマネージャによって、後続の伝送エポックで送信するバイト数を調整することであって、前記バイト数を調整することは、
   １．前記ペーシングマネージャによって、前記目標伝送速度と前記推定された平均伝送速度の間の差によって乗算された定数に基づいて、調整値を決定することと、
   ２．前記後続の伝送エポックにおいて、前記調整値によって送信するバイト数を調整することを含み、
   ｆ．前記調整されたバイト数に従って、前記メディアプレーヤーに前記マルチメディアクリップの前記部分の１つを送信することと、
   ｇ．前記マルチメディアクリップの複数の部分が送信されるまで、ｄ．からｆ．の工程を繰り返すこと
   を含む、方法。
2. 前記メディアプレーヤーが、前記マルチメディアクリップの前記部分を再生するように設計される、請求項１に記載の方法。
3. 前記ネットワークが、広域ネットワーク（ＷＡＮ）、ローカルエリアネットワーク（ＬＡＮ）、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ（登録商標））ネットワーク、符号分割多重接続（ＣＤＭＡ）ネットワーク、ロングタームエボリューション（ＬＴＥ）ネットワーク、およびワールドワイドインターオペラビリティフォーマイクロウェーブアクセス（ＷｉＭＡＸ）ネットワークのうち、少なくとも１つを含む、請求項１に記載の方法。
4. 前記ユーザ機器が、スマートフォン、携帯電話、コンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、セットトップボックス、インターネットプロトコルテレビジョン（ＩＰＴＶ）、電子ゲーム機、及びタブレットのうち、少なくとも１つを含む、請求項１に記載の方法。
5. 前記目標伝送速度を推定することが、マルチメディアコンテンツの前記部分のサイズおよび持続時間に関する情報を取得するためにメディアコンテナを解析することを含む、請求項１に記載の方法。
6. 前記目標伝送速度を推定することが、コンテナヘッダ内で通知されたメディア符号化ビットレートを使用することを含む、請求項１に記載の方法。
7. ペーシングサーバであって、
   プロセッサと、
   ハイパーテキストトランスファープロトコル（ＨＴＴＰ）ストリーミングプロセスのためのペーシングマネージャへの命令を含む記録を有する非一時的コンピュータ可読媒体と、を備え、
   前記ＨＴＴＰストリーミングプロセスが、前記プロセッサによって実行されると、前記ペーシングサーバに、
   ａ．目標伝送速度を推定させ、
   ｂ．現在の伝送エポック中に送信するためのバイト数を、前記目標伝送速度に、前記伝送エポックの長さを乗算することによって取得される値へと初期化させ、
   ｃ．平均伝送速度は、前記現在の伝送エポックに送信された伝送バイトの総数を、伝送にかかる経過時間で除算したものとして、推定させ、
   ｄ．後続の伝送エポックで送信するバイト数を調整することであって、前記バイト数を調整することは、
   １．前記ペーシングマネージャによって、前記目標伝送速度と前記推定された平均伝送速度の間の差によって乗算された定数に基づいて、調整値を決定することと、
   ２．前記後続の伝送エポックにおいて、前記調整値によって送信するバイト数を調整することを含み、
   ｅ．前記調整されたバイト数に従って、メディアプレーヤーにマルチメディアクリップの一部分を伝送させ、
   ｆ．前記マルチメディアクリップの複数の部分が送信されるまで、ｃ．からｅ．の工程を繰り返すことを含むサーバ。
8. 前記目標伝送速度を推定することが、マルチメディアコンテンツの前記部分のサイズおよび持続時間に関する情報を取得するためにメディアコンテナを解析することを含む、請求項７に記載のサーバ。
9. 前記目標伝送速度を推定することが、コンテナヘッダ内で通知されたメディア符号化ビットレートを使用することを含む、請求項７に記載のサーバ。