JP2015513840A5 - - Google Patents
Download PDFInfo
- Publication number
- JP2015513840A5 JP2015513840A5 JP2014558951A JP2014558951A JP2015513840A5 JP 2015513840 A5 JP2015513840 A5 JP 2015513840A5 JP 2014558951 A JP2014558951 A JP 2014558951A JP 2014558951 A JP2014558951 A JP 2014558951A JP 2015513840 A5 JP2015513840 A5 JP 2015513840A5
- Authority
- JP
- Japan
- Prior art keywords
- rate
- download
- time
- request
- buffer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- UIIMBOGNXHQVGW-UHFFFAOYSA-M buffer Substances [Na+].OC([O-])=O UIIMBOGNXHQVGW-UHFFFAOYSA-M 0.000 claims description 287
- 235000010384 tocopherol Nutrition 0.000 claims description 111
- 235000019731 tricalcium phosphate Nutrition 0.000 claims description 111
- 230000004044 response Effects 0.000 claims description 37
- 235000019525 fullness Nutrition 0.000 claims description 35
- 230000005055 memory storage Effects 0.000 claims description 8
- 230000001276 controlling effect Effects 0.000 claims description 4
- 238000000034 method Methods 0.000 description 165
- 230000000875 corresponding Effects 0.000 description 49
- 230000006399 behavior Effects 0.000 description 15
- 238000005259 measurement Methods 0.000 description 12
- 230000015654 memory Effects 0.000 description 11
- 230000000694 effects Effects 0.000 description 10
- 230000003044 adaptive Effects 0.000 description 9
- 230000001965 increased Effects 0.000 description 8
- 230000004301 light adaptation Effects 0.000 description 8
- 239000000203 mixture Substances 0.000 description 8
- 238000004364 calculation method Methods 0.000 description 7
- 230000003139 buffering Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 6
- 230000035484 reaction time Effects 0.000 description 6
- 238000005070 sampling Methods 0.000 description 6
- 230000001413 cellular Effects 0.000 description 5
- 238000004587 chromatography analysis Methods 0.000 description 5
- 238000001514 detection method Methods 0.000 description 5
- 239000012464 large buffer Substances 0.000 description 5
- 230000001603 reducing Effects 0.000 description 5
- 241000338137 Teratosphaeria nubilosa Species 0.000 description 4
- 241001516311 Watermelon virus A Species 0.000 description 4
- 230000001174 ascending Effects 0.000 description 4
- 238000006722 reduction reaction Methods 0.000 description 4
- 230000001427 coherent Effects 0.000 description 3
- 239000006185 dispersion Substances 0.000 description 3
- 239000012092 media component Substances 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000006011 modification reaction Methods 0.000 description 3
- 235000019832 sodium triphosphate Nutrition 0.000 description 3
- 230000002459 sustained Effects 0.000 description 3
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 3
- RZCIEJXAILMSQK-JXOAFFINSA-N 5-Methyluridine triphosphate Chemical compound O=C1NC(=O)C(C)=CN1[C@H]1[C@H](O)[C@H](O)[C@@H](COP(O)(=O)OP(O)(=O)OP(O)(O)=O)O1 RZCIEJXAILMSQK-JXOAFFINSA-N 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 230000001419 dependent Effects 0.000 description 2
- 238000009499 grossing Methods 0.000 description 2
- 238000011084 recovery Methods 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 201000007023 thrombotic thrombocytopenic purpura Diseases 0.000 description 2
- UNPLRYRWJLTVAE-UHFFFAOYSA-N 1-[2-[(4-chlorophenyl)-phenylmethoxy]ethyl]piperidin-1-ium;chloride Chemical compound Cl.C1=CC(Cl)=CC=C1C(C=1C=CC=CC=1)OCCN1CCCCC1 UNPLRYRWJLTVAE-UHFFFAOYSA-N 0.000 description 1
- 210000002784 Stomach Anatomy 0.000 description 1
- 230000003247 decreasing Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000002708 enhancing Effects 0.000 description 1
- 238000007667 floating Methods 0.000 description 1
- 230000037406 food intake Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 235000009808 lpulo Nutrition 0.000 description 1
- 230000000051 modifying Effects 0.000 description 1
- 230000003287 optical Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000002093 peripheral Effects 0.000 description 1
- 230000002028 premature Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000004043 responsiveness Effects 0.000 description 1
- 230000001340 slower Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
- 230000003936 working memory Effects 0.000 description 1
Description
関連出願の相互参照
本出願は、参照によってその内容全体がすべての目的のために本明細書に組み込まれている、2012年2月27日に出願された、「Improved DASH Client and Receiver with Rate Adaptation and Downloading for Adaptive Video」と題する米国仮出願第61/603,569号の利益を主張する。
本出願は、参照によってその内容全体がすべての目的のために本明細書に組み込まれている、2012年2月27日に出願された、「Improved DASH Client and Receiver with Rate Adaptation and Downloading for Adaptive Video」と題する米国仮出願第61/603,569号の利益を主張する。
DASHは、「動的適応ストリーミングオーバーHTTP(Dynamic Adaptive Streaming over HTTP)」を指す。DASHを使用して、コンテンツプロバイダは、コンテンツを、MPDファイルなど、関連付けられたメタデータとともに、セグメント、フラグメント、リプレゼンテーション(representations)、アダプテーション(adaptations)などにフォーマットし、それらすべてを、標準HTTPサーバまたは特殊化HTTPサーバを経由して、利用可能なファイルとして記憶する。DASHクライアントとは、これらのファイルを必要に応じて取得して、DASHクライアントのユーザにプレゼンテーションを提示する受信機である。
ユーザが通常、ネットワークが制限されている環境において、事前告知がほとんどまたはまったくなしで高品質ストリーミングを望むので、DASHクライアントは、厳しい制約を有する。したがって、改良されたDASHクライアントが望まれる。
クライアントデバイスは、ストリーミングメディアを提示し、ストリームを制御するためのストリームマネージャと、コンテンツについてのネットワーク要求を行うための要求アクセラレータと、どの要求を行うか決定するための、ストリームマネージャおよび要求アクセラレータに結合されたソースコンポーネントと、ネットワーク接続と、メディアプレーヤとを含む。要求アクセラレータは、要求をバッファリングするための要求データバッファと、アクセラレータが応答することができる各要求に完了応答を戻すための論理とを備える。ストリームマネージャ、要求アクセラレータ、およびソースコンポーネントは、プロセッサ命令またはプログラムコードとして実装されることができ、クライアントデバイスは、プログラムメモリと、ワーキングメモリと、プロセッサと、電力源とをさらに備える。クライアントデバイスはまた、ディスプレイとユーザ入力デバイスとを含み得る。クライアントタスクは、効率的にデータをストリーミングするために、ソースコンポーネント、ストリームマネージャ、および要求アクセラレータの間でパースされる。
様々な態様において、本明細書に記載するように、クライアントは、リプレゼンテーションを維持し、または別のリプレゼンテーションに切り替えるべきときを決定するなどの動作を実施し、どのフラグメントを要求するか決定し、メディアプレーヤが、ほとんどの条件において、失速(stalling)することなくストリームを継続するのに十分なデータを確実に取得できるようにすることができる。
クライアント/受信機は、ネットワーク経路によって結合されたソースと受信機との間のネットワーク経路を通じてデータをダウンロードし、受信機のプレゼンテーションバッファ内にメディアデータを記憶し、それがそこからプレゼンテーション要素によって消費される。受信機は、プレゼンテーションバッファの充満レベルを監視し、充満レベルは、プレゼンテーションバッファのどのような部分が、プレゼンテーション要素によってまだ消費されていないメディアデータを含むかを表す。受信機は、ダウンロードすべき追加のデータに関する要求を行う。充満レベルが高充満しきい値を上回る場合、受信機は、それ以上の要求を行わず、最終的には充満レベルが下落する。充満レベルが低充満しきい値を下回る場合、受信機は、ダウンロードをリスタートし、メディアデータがプレゼンテーション要素によって消費されるときに充満レベルをアップデートする。充満レベルは、メモリ記憶容量の単位(例えば、メガバイトまたはギガバイト)および/またはプレゼンテーション時間の単位(例えば、秒や分)で測定されることができる。
ダウンロードは、メディアデータダウンロードがリスタートされるときにリセットされる、推定ラウンドトリップ時間(「ERTT」)に基づき得る。ダウンロードは、複数のTCP接続を介して起こり得、使用されているいくつかのTCP接続は、メディアデータダウンロードがリスタートされるときにリセットされ得る。高充満しきい値および低充満しきい値は、時間とともに変化しうる。たとえば、しきい値は、プレゼンテーションの開始時に、より広くまたはより狭くなり、次いでレベルオフし得、またその逆も可能である。
受信機の一実装形態は、ソースからダウンロードされるダウンロードされたメディアデータを記憶するプレゼンテーションバッファと、プレゼンテーションバッファの充満レベルのためのストレージであって、充満レベルが、プレゼンテーションバッファのどのような部分が、プレゼンテーション要素によってまだ消費されていないメディアデータを含むかを表す、ストレージと、ダウンロード要求を送るためのインターフェースであって、充満レベルが高充満しきい値を上回る場合、要求は送られず、充満レベルが低充満しきい値を下回る場合、要求が送られ、充満レベルはメディアデータがプレゼンテーション要素によって消費されるときにアップデートされる、インターフェースと、を含み得る。
ネットワーク経路によって結合されたソースと受信機との間の該ネットワーク経路を介したデータダウンロードを制御するための、プロセッサによって実行するためのコンピュータ可読媒体を使用して、様々な要素が実装され得る。コンピュータ可読媒体は、非一時的コンピュータ可読媒体であり得る。
本発明の他の態様が、本記述から明らかになるはずである。
本明細書で説明されるDASHクライアントは、図2に示すように、ストリームマネージャ(SM)と、要求アクセラレータ(RA)と、ソースコンポーネント(SC)と、ネットワーク接続と、メディアプレーヤとを含む。DASHクライアントは、1つまたは複数のメディアデータバッファも含み得る。いくつかの実装形態では、RA、SCおよびメディアプレーヤはすべて、それら自体のデータバッファ、または1つの大きいデータバッファの論理区画を有し得る。他の実装形態では、おそらくRAのみが、要求をバッファリングするためのデータバッファを有し、その結果、RAは、それが応答し得るあらゆる要求に対して完了応答(complete response)を戻すことができるようになり、メディアプレーヤは、SCがセットアップしたデータバッファはどれでも使用する。SMは、決定を行うのに必要とされるメタデータを記憶するための、それ自体の(物理的または論理的)ローカルストレージを有し得る。
図1は、DASHクライアントをもつDASH展開を示す。
図2は、様々なコンポーネントをもつDASHクライアントの例示的アーキテクチャを示す。SM、RA、SCおよびメディアプレーヤは、ハードウェア、ソフトウェアまたは何らかの組合せで実装され得ることを理解されたい。したがって、機能がコンポーネントによるものである場合、機能は、プロセッサ命令、プログラムコードなどとして実装されてよく、この場合、それらの命令を実行するための必要なハードウェア(プログラムメモリ、ROM、RAM、プロセッサ、電力源、コネクタ、回路板など)が含意される。ネットワーク機能が記述される場合、ネットワーク接続は、存在するものと理解されるべきであり、ワイヤード、光学、ワイヤレスなどであってよく、ユーザインタラクションが含意される場合、ユーザインターフェース能力(ディスプレイ、キーボード、タッチパッド、スピーカ、マイクロフォンなど)も含意される。
DASHクライアントは、2つのクロック、またはそれらの論理的等価物を維持する。一方のクロックは、クライアント中で稼動するローカルクロックの時間を示すリアルタイムクロック回路またはソフトウェアであり、他方のクロックは、メディアコンテンツの開始に対する、メディアコンテンツのプレゼンテーションの時間を表すプレゼンテーション時間である。本明細書において、リアルタイムクロック時間は「r時間」と呼ばれ、「p時間」は、プレゼンテーション時間を示す記述子である。
リプレゼンテーションとは、同じコンテンツについての、異なるビットレートまたは他の違いで符号化されたメディアストリームである。したがって、ユーザは通常、1つのリプレゼンテーションを必要とするだけであるが、クライアントは、条件および/または要件が変わると、あるリプレゼンテーションから別のリプレゼンテーションに切り替えうる。たとえば、帯域幅が高い場合、ストリーミングクライアントは、高品質、高ビットレートのリプレゼンテーションを選びうる。帯域幅が低減された場合、クライアントは、より低品質のより低いビットレートリプレゼンテーションに切り替えることによって、これらの条件に適応することができる。
切替え点(またはランダムアクセスポイント)は、ストリームに先行するデータを知る必要なしに、メディアサンプルの復号がそこから始まり得る、リプレゼンテーション中のサンプルである。特に、ビデオリプレゼンテーションでは、サンプル(フレーム)は概して以前のフレームに依存するので、あらゆるサンプルがランダムアクセスポイントであるわけではない。ストリーミングクライアントは、リプレゼンテーションを切り替えたいときには、無駄な作業を避けるために、必ず切替え点において新たなリプレゼンテーションを復号し始めるべきである。いくつかのケースでは、切替え点は、ストリーミングクライアントに対してセグメントインデックス(sidx)中でシグナリングされる。
リプレゼンテーショングループ(単にグループと略記されることがある)とは、切替え可能なリプレゼンテーションのセットである。メディアプレゼンテーションは、1つよりも多くのリプレゼンテーショングループを含み得る。メディアプレゼンテーションは、たとえば、様々なビットレートでのビデオリプレゼンテーションについて1つのリプレゼンテーショングループと、オーディオビットレートについて別のリプレゼンテーショングループとを有し得る。DASH規格では、リプレゼンテーショングループは、適応セットと呼ばれることもある。
セグメントとは、複数のリプレゼンテーションのうちの1つのリプレゼンテーションの少なくとも一部分についてのメディアデータを含むファイルである。フラグメントとは、フラグメントの開始p時間からセグメント内のフラグメントのバイト範囲へのマッピングが利用可能である、セグメントの一部である。フラグメントの代わりにサブセグメントという用語が使用されることもあり、これらは等価であると見なされ得る。一部のメディアコンテンツは、フラグメントに分割されず、そのようなケースにおいて、「フラグメント」は、セグメント自体を指す場合がある。
図3は、2つの可能なリプレゼンテーション切替えプロセスを示すタイミング図である。切替えは、後方参照(backward looking)(図3Aの第1のプロセス)であることができ、この場合、switch−fromリプレゼンテーション中ですでに要求されているp時間ストレッチを見ることによって、およびこのストレッチの終了に最も近い、switch−toリプレゼンテーションから、p時間において後退する前の切替え点を選ぶことによって、switch−toリプレゼンテーションにおける切替え点が見つかる。第2のプロセス(図3B)は前方参照(forward looking)であり、switch−fromリプレゼンテーション中の、最後の要求されるp時間から始まる、switch−toリプレゼンテーション中の、p時間において前進する次の切替え点を見つける。
図4は、切替え点がアライメントされたとき、および切替え点が最後の要求フラグメントの後にすぐに続くときの、切り替えるためのプロセスを示すタイミング図である。この図は、前方参照方法と後方参照方法の両方の挙動を示すが、それは、これらの2つのプロセスが、そのような設定において同一に振る舞うからである。したがって、切替え点がアライメントされるときには、どちらのプロセスも、重複データをダウンロードする必要はない。
プレゼンテーション時間とは、メディアが、一般には通常速度で、プレイアウトまたはプレイバックすると予想される時間期間である。たとえば、30分のビデオプレゼンテーションであれば、30分間再生する。ユーザは、早送りまたは巻き戻しをする場合があるので、実際にかかる時間は変わるが、プレゼンテーションは依然として、30分のビデオプレゼンテーションであることを理解されたい。プレゼンテーション要素が、プレゼンテーション時間に、ユーザにプレゼンテーションを提示する。プレゼンテーション要素の例としては、視覚ディスプレイおよびオーディオディスプレイ、またはストリームを提示することができるデバイスにパイピングされるビデオ/オーディオストリームがある。「プレイバック」とは、メディアの消費を記述するのに使用される用語である。たとえば、スマートフォンであれば、プレゼンテーションのプレゼンテーション時間(p時間)にわたってプレゼンテーションを表すメディアデータをダウンロードまたは取得し、バッファリングすることができ、メディアプレーヤは、そのメディアを「消費する」と言われ、好ましくは、バッファが少なくともプレゼンテーション時間の終了までは完全には空にならないように消費し、そうすることによってユーザは、受信機がより多くのデータを取得するのを待っている間、プレゼンテーションの失速を受けない。当然ながら、「プレイバック」または「プレイアウト」は、メディアが一度よりも多く再生されることは含意しない。多くの事例において、メディアは一度消費されると、再度使用されることはない。
プレゼンテーションバッファとは、受信機、メディアプレーヤ内にあるか、または一方もしくは両方にとってアクセス可能なメモリ要素である。説明を簡単にするために、「プレゼンテーションバッファ」、「バッファ」、「メディアバッファ」および「プレイバックバッファ」という用語を互換的に使用するが、これは、ダウンロードされているがまだプレイアウト、すなわち消費されていないデータ、すなわち通常はメディアデータを備える論理バッファであることは理解している。プレゼンテーションバッファを成すデータが、デバイスにおいて、様々なコンポーネントの間で区分される場合があり、すなわち、ダウンロードされたデータのいくつかの部分が、1つのプロセス、たとえば、デバイス内の受信プロセスによって保持され、他の部分は、別のプロセス、たとえば、デバイス内のプレイアウトプロセスにすでに渡されている場合がある。プレゼンテーションバッファを成すデータの少なくとも一部は、異なるプロセスの異なるバッファにわたって少なくとも部分的に複製される場合もあり得る。いくつかのケースでは、ダウンロードされているがまだプレイアウトされていないデータすべてが、依然としてプレゼンテーションバッファ内にあると見なされるわけではなく、たとえば、いくつかのケースでは、メディアコンテンツは、メディアプレーヤにパスされると、もはやプレゼンテーションバッファにあると見なすことはできない。概して、メディアデータが存在する場合、ダウンロードされているがまだプレイアウトされておらず、さらにプレゼンテーションバッファ内にあると見なされないメディアデータの量は、非常に少ない。
プレゼンテーションバッファは、メディアを受信しプレイバックし、受信メディアデータを、消費されるまで記憶する際の不均一に適応する。メディアデータは、消費された後、構成に応じて、消去されることもでき、または記憶され続けることもできる。いくつかの実装形態では、プレゼンテーションバッファのサイズ(プレゼンテーションバッファに記憶することができるデータバイトの数で測ることができる)は、時間とともに変わり得る。たとえば、プレゼンテーションバッファは、必要に応じて共有メモリから動的に割り振られ得る。
本明細書において詳細に説明する多くの例では、プレゼンテーションバッファは、サイズによって特徴付けられると仮定され得る。プレゼンテーションバッファに専用の固定メモリサイズのケースでは、そのサイズは、利用可能メモリに記憶することができるバイトの数で測ることができる。プレゼンテーションバッファが動的に割り振られる場合、プレゼンテーションバッファに起因する「サイズ」は、プレゼンテーションバッファに現時点で割り振られているバイトの数、プレゼンテーションバッファに割り振ることができ得るバイトの最大数、または何らかの他の適切な測度に等しいものであり得る。プレゼンテーションバッファサイズは、プレゼンテーションバッファ中の現在利用可能なメディアのプレゼンテーション時間プレイアウト持続期間によって測定されることもある。
プレゼンテーションバッファは、別の特性、すなわちバッファの「レベル」または「充満レベル」も有する。プレゼンテーションバッファのレベルは、どれだけ多くの未消費メディアデータがプレゼンテーションバッファ中に存在するかを表し、たとえばバイトまたはプレゼンテーション持続時間で測定される。レベルは、メディアデータが受信されると上がり、メディアデータが消費されると下がると予想される。レベルは、論理的なものにすぎない可能性があり、たとえば、プレゼンテーションバッファは、メディアデータで常に満杯(full)であり得るが、メディアの一部、たとえば、すでに消費されたメディアデータは、新規メディアデータが受信されると、上書きのためにマーキングされる。
いくつかの受信機は、「空きバッファ」が、未消費のメディアデータがゼロであるコンディションであり、「満杯バッファ」が、プレゼンテーションバッファの100%が未消費メディアデータで満たされているコンディションであるようにプログラムされ得る。他の受信機は、プレゼンテーションバッファサイズの0%〜100%よりも小さい範囲にレベルが及ぶように、他の限度を有し得る。未消費メディアデータがバッファに記憶されたときに共有メモリが使われ、プレゼンテーションバッファしか割り振られたことがないケースでは、プレゼンテーションバッファは、定義により、常に満杯になるので、プレゼンテーションバッファのメモリの動的に割り振られたサイズを、レベル比を示すときの水準として使用するのは意味がない場合がある。そうではなく、プレゼンテーションバッファのレベルは、プレゼンテーションバッファ中の未消費メディアデータの量を、プレゼンテーションバッファについての最大許容サイズで除算した比として測ることができる。
いくつかの受信機は、「空きバッファ」が、未消費のメディアデータがゼロであるコンディションであり、「満杯バッファ」が、プレゼンテーションバッファの100%が未消費メディアデータで満たされているコンディションであるようにプログラムされ得る。他の受信機は、プレゼンテーションバッファサイズの0%〜100%よりも小さい範囲にレベルが及ぶように、他の限度を有し得る。未消費メディアデータがバッファに記憶されたときに共有メモリが使われ、プレゼンテーションバッファしか割り振られたことがないケースでは、プレゼンテーションバッファは、定義により、常に満杯になるので、プレゼンテーションバッファのメモリの動的に割り振られたサイズを、レベル比を示すときの水準として使用するのは意味がない場合がある。そうではなく、プレゼンテーションバッファのレベルは、プレゼンテーションバッファ中の未消費メディアデータの量を、プレゼンテーションバッファについての最大許容サイズで除算した比として測ることができる。
1. クライアントコンポーネントの概説
図1〜図2を再度参照すると、例示的クライアントの様々なコンポーネントが示されている。
図1〜図2を再度参照すると、例示的クライアントの様々なコンポーネントが示されている。
SCは、どのようなリプレゼンテーションが利用可能であるか、およびリプレゼンテーションのフラグメントが何であるかについての情報などのメタデータを追跡する。
SCは、ネットワークを介して受信されたメディアデータのバッファリング、およびメディアプレーヤへのハンドオフも担う。SMは、どのようなリプレゼンテーションがどの時点でダウンロードされるべきかを決定すること、およびレート切替え決定を行うことを担う。最終的に、RAは、SCによって与えられる正確なURLおよびバイト範囲情報を所与として、メディアフラグメントのダウンロードを担当する。
SCは、ネットワークを介して受信されたメディアデータのバッファリング、およびメディアプレーヤへのハンドオフも担う。SMは、どのようなリプレゼンテーションがどの時点でダウンロードされるべきかを決定すること、およびレート切替え決定を行うことを担う。最終的に、RAは、SCによって与えられる正確なURLおよびバイト範囲情報を所与として、メディアフラグメントのダウンロードを担当する。
SMは、レート切替え決定を担うソフトウェアコンポーネントである。SMの目標の1つは、所与の状況向けの最良のコンテンツを選び出すことである。たとえば、たくさんの帯域幅が利用可能である場合、高ダウンロードレートが達成され得るので、SMは、高レートリプレゼンテーションを選び出すべきである。ダウンロードレートが大幅に下落した場合、選ばれた高いリプレゼンテーションはそれ以上持続可能でなくなるので、SMは、条件により適した、より低いリプレゼンテーションレートに切り替えるべきである。SMは、プレイバックバッファを完全にドレインするのを避け(プレイバック失速を引き起こすので)、ただし同時にあまりに急いで、またはあまりに頻繁に切り替えようとはしないように、十分高速にレートを切り替えるべきである。さらに、ネットワークを通じてダウンロードし、失速することなくプレイバックすることができる、最も高品質のコンテンツを要求することを目指すべきである。SMは、意思決定プロセスにおいて、ダウンロード速度以外の要因を考慮に入れるように拡張することができる。可能性としては、リプレゼンテーション決定を行うときには、バッテリ寿命、ディスプレイサイズ、および他の要因などに配慮することができる。そのようなさらなる制約は、フィルタとしてSMに追加することができ、本明細書において記述する基本レート決定計算には影響しない。
典型的な高レベルのクライアント動作について、次に説明する。ユーザが、ライブのスポーツ放送、あらかじめ録画された映画、オーディオストリーム、または、ビデオおよびオーディオ以外のメディアタイプを伴い得る他のオーディオビジュアルもしくは他のコンテンツなど、特定のメディアコンテンツを要求すると想定する。クライアントは、その要求を、おそらくユーザインターフェースまたはコンピュータインターフェースを通して、SMに供給する。SMは、SCに対して要求を行い、どのリプレゼンテーションが利用可能であるか、どのp時間帯がどのフラグメントによってカバーされるか、およびリプレゼンテーション中の切替え点がどこにあるかについてのインジケーションを受信する。それに加え、SMは、後で説明するように、自由にできる短期ダウンロードレートについての何らかの情報を有することができ、RAは、このデータをSCに報告し、SCは、このデータをSMに報告または提供する。
SMは、その情報を、過去の履歴と一緒に使用して、持続可能レートを推定し、リプレゼンテーション内の適切な切替え点と、その切替え点において始まるそのリプレゼンテーションからダウンロードするべきメディアコンテンツの量とを選ぶ。ダウンロードが進行中であり、メディアコンテンツがプレイバックされるとき、SMは、供給された情報を使用して、レート切替えが順序通りであるかどうかを決定する。レート切替えが順序通りでない場合、SMは、現在のリプレゼンテーションからフラグメントをフェッチし続けるよう、SCに伝える。レート切替えが順序通りである場合、SMは、潜在的切替え点を見て、どのリプレゼンテーションにあるどのフラグメントが、所望の切替えを行うためにフェッチされる必要があるか決定する。SMは次いで、その情報をSCに渡す。SCとSMとの間のこの交換は、ダウンロードされるべきビデオの次のセクションに対する決定が行われるべきであるときはいつでも、定期的に行われる。良好な決定を行うために、SMはバッファレベルを監視し、いくつかのケースでは、SMは、バッファが十分に満杯であり、いかなるフラグメントも、ある程度の期間ダウンロードされる必要はないと決定し得る。
SMが、ダウンロードするべきフラグメントを決定すると、SCは、RAに、実際にフラグメントをダウンロードさせ、ダウンロードされたフラグメントをメディアバッファに保たせ、最終的に、メディアデータをプレイアウトする時間になったとき、メディアバッファ中のメディアデータをメディアプレーヤにハンドオーバさせるのを担当する。
SMはもはや、SCに、ダウンロードするよう伝えたフラグメントに能動的に関与していない。ただし、SMは、所与のフラグメントのダウンロードがすでに始まった後でも、考えを変え、以前発行したフラグメント要求を取り消すことができる。この機能は、ダウンロードレートが劇的に下落し、ダウンロードされているフラグメントが、メディアバッファが完全にドレインされた時間に、利用可能である見込みがなくなったケースにおいて有用である。その条件が起きた場合、SMはその条件を検出し、要求を取り消し、代わりにより適切なレートに切り替える。
SCは、SMから、フェッチするべきフラグメントハンドルを受信すると、対応するフラグメントのURLとバイト範囲とを、そのデータ構造中でルックアップし、それを使用して要求を作成し、その要求をRAにハンドオーバする。それはまた、RAから応答データを取り出し、受信メディアフラグメントを、再生可能なストリームに変換するのも担う。最終的に、SCは、MPDから取得したデータ、セグメントインデックス(sidx)ボックス、またはAppleのHTTPライブストリーミング(HLS)のケースでは、プレイリストなどのメタデータをパースし、追跡するのを担当する。
RAは、SCから受信したフラグメントおよびメタデータ要求を引き受け、対応するHTTP要求を作成し、それらをネットワーク接続を通じて送出し、対応する応答を取り出し、SCに返すコンポーネントである。ネットワーク接続は、インターネット接続、セルラーベースの接続、WiFi(登録商標)接続またはHTTP要求と応答とを扱うことが可能な他のネットワーク接続であることができる。ネットワーク接続は、単一デバイスの内部にあることができ、すなわち、デバイス内にすでにキャッシュされているメディアデータとの内部インターフェースであることができる。また、多くの組合せがあってもよく、すなわち、メディアコンテンツの一部は、ワイヤードインターネット接続から、一部はセルラーベースの接続を介して、一部はWiFi接続を介して、一部はローカルキャッシュからダウンロードすることができる。いくつかのケースでは、メディアデータがダウンロードされる接続は混合されてよく、すなわち、いくつかの部分はセルラーを介し、いくつかの部分はWiFiを介し、いくつかの部分はワイヤードを介するなどである。
特定の要求は、いくつかの事例ではHTTP以外であってよいが、メディアコンテンツをサービスするサーバがHTTPサーバである場合はHTTPが好まれる。
特定の要求は、いくつかの事例ではHTTP以外であってよいが、メディアコンテンツをサービスするサーバがHTTPサーバである場合はHTTPが好まれる。
その最も単純な形において、RAはHTTPクライアントである。ただし、RAは、一般的なHTTPクライアントより効率的であることが望ましい場合もある。RAの1つの目標は、十分に高いダウンロード速度を達成することであり、選択されたプレイバックメディアレートよりも大幅に速いダウンロードを目指すべきである。一方、未加工スループットのために適時性を損なわないように、慎重でもあるべきであり、すなわち、間もなくプレイアウトされるフラグメントは、さらに後にくる他のものよりも緊急であり、RAは、それらを時間内に受信しようと試みるべきである。したがって、適時性のためにある程度のスループットを犠牲にすることが必要となり得る。RAは、すべての妥当なネットワーク条件でうまく機能するように設計されるべきである。
RAの基本設計は、いくつかの接続と、最良の結果を取得するために、できればさらにFEC(前方誤り訂正)も使用するものである。したがって、RAは通常、2つ以上のオープンなHTTP接続を管理する必要がある。RAは、それらの接続に要求をディスパッチする。RAは、いくつかの状況において、要求を、より小さい要求のセットに分割する。対応する応答を受信すると、RAは次いで、データをコヒーレント応答にリアセンブルする。言い換えると、RAは、送出するべきHTTP要求の粒度と、どの接続に要求をディスパッチするべきかとを決定し、ソースフラグメントまたは修復セグメントのどの部分を要求するべきか決定する役目を果たす。それらの要求の粒度は、たとえばバッファレベル、要求の緊急度、利用可能な接続の数など、いくつかのことに依存し得る。
RAによって送出される各要求は、メタデータについての、またはSCによってRAにパスされたフラグメント要求の一部もしくは全部についてのHTTP要求である。
ソースメディアデータまたはソースメディアデータから生成された修復データのいずれかについての要求でありうる。SCフラグメント要求から生成されたRA要求への応答は、ほとんどの場合、RAがフラグメント要求中のメディアデータすべてを再構築するのに十分なはずであり、RAは次いで、このデータをSCに返す。したがって、RAは、メディアフラグメント要求に関連付けられたRA要求からの応答を、SCに与えられるフラグメント要求への応答に逆アセンブルするのを担う。RAによるアセンブルは、たとえばFEC修復データについてのいくつかのRA要求がある場合、FEC復号を含み得る。
ソースメディアデータまたはソースメディアデータから生成された修復データのいずれかについての要求でありうる。SCフラグメント要求から生成されたRA要求への応答は、ほとんどの場合、RAがフラグメント要求中のメディアデータすべてを再構築するのに十分なはずであり、RAは次いで、このデータをSCに返す。したがって、RAは、メディアフラグメント要求に関連付けられたRA要求からの応答を、SCに与えられるフラグメント要求への応答に逆アセンブルするのを担う。RAによるアセンブルは、たとえばFEC修復データについてのいくつかのRA要求がある場合、FEC復号を含み得る。
HTTP要求の管理に加え、RAは、短期の期間にわたる、すなわちある程度のサンプリングレートの時間スライスにわたるダウンロード速度を測定する。例示的サンプリングレートは100msであり、すなわち、RAは、100msの期間にわたってダウンロード速度を測定する。このデータは、SMによって、SMのダウンロード速度推定値を計算し、最終的にはレート決定を行うのに使用される。他のサンプリングレートも可能である。
RAは、DASHメディアプレゼンテーション記述(MPD)などのメタデータについても、セグメント構造についても知る必要はない。特定の実装形態において、RAは、HTTPスタック実装形態のいくつかの同時事例を使用して、いくつかの接続にわたって、いくつかのケースでは同様または異なるサーバへの異なるタイプの接続にもわたって、HTTP検索を実装する。
RAは、新規要求がいつ受諾され得るかをSCに知らせることを担う。SCは、SMに、要求するべき次のフラグメントを決定するよう求め、適切な要求をRAに与える。RAは、何らかのステータス情報も与える。RAは、短期ダウンロード速度と、ダウンロードに費やされる総時間とを、SCを経由してSMに定期的に与え得る。SMは、また、この情報について、SCを経由して間接的にRAをポーリングし得る。それに加え、RAは、各個々の要求がすでに完了された割合についてもSMに知らせる。この情報は、SMがそれを取り出すために呼び出すAPIを用いて同様に与えられる。
RAと、SCと、実際のメディアパイプラインとの間には、非常にタイトなデータフローがあるはずであり、RAまたはSC内にバッファリングされるデータは、(意図的なメディアバッファは別にして)可能な限り少ない。同じことが、様々な形のHTTP要求についても成り立ち、SMは、実際の対応するHTTP要求がネットワークを介して送出されるときよりも早く、わずかな時間量だけで、要求するべきフラグメントを決定しなければならないはずである。1つの理由は、SMが要求を事前に決定しなければならない程、その情報は正確でも最新でもなくなり、したがって、その決定はより低い品質となる。
SMは、発行されるべき要求を一度に1つ提出する。ただし、SMは、以前のすべての要求が完了されているわけではない場合にも新規要求を発行することができ、同時要求が許容される。SCは、SMが要求を発行した順序で、要求をRAにパスする。RAは次いで、同時処理を引き受け、受信データをSCに必ず返す。
同時要求により、RAは、HTTPパイプライン化を実装することが可能になる。実際、複数の接続を利用するRAでさえも、この方式に適合する。
1.1. ストリームマネージャ(SM)
SMは、ユーザのアクションと、ネットワーク条件と、他の要因との組合せに応じて、フラグメントをいつ要求すべきか、およびどのフラグメントを要求すべきかを決定する。ユーザがコンテンツを見始めると決定すると、SMは、ユーザによって、または提供されるサービスによって指定された、p時間から始まるそのコンテンツについて要求するべき第1のフラグメントを決定するのを担う。たとえば、いくつかのライブストリーミングサービスは、すべてのユーザが、メディアコンテンツの同じp時間部分を同じr時間に閲覧していることを要求し得るが、他のライブストリーミングおよびオンデマンドサービスは、どのp時間をどのr時間にプレイバックするかについて、柔軟性をエンドユーザまたはアプリケーションに認め得る。メディアバッファが満杯になると、SMは、さらなるフラグメント要求を与えるのを一時的にサスペンドする。SMは、ネットワーク条件およびたとえばディスプレイのサイズ、残存バッテリ寿命など、他の要因に依存して、p時間中の各時点においてコンテンツをどの品質でプレイバックするべきか決定するのを担う。
SMは、ユーザのアクションと、ネットワーク条件と、他の要因との組合せに応じて、フラグメントをいつ要求すべきか、およびどのフラグメントを要求すべきかを決定する。ユーザがコンテンツを見始めると決定すると、SMは、ユーザによって、または提供されるサービスによって指定された、p時間から始まるそのコンテンツについて要求するべき第1のフラグメントを決定するのを担う。たとえば、いくつかのライブストリーミングサービスは、すべてのユーザが、メディアコンテンツの同じp時間部分を同じr時間に閲覧していることを要求し得るが、他のライブストリーミングおよびオンデマンドサービスは、どのp時間をどのr時間にプレイバックするかについて、柔軟性をエンドユーザまたはアプリケーションに認め得る。メディアバッファが満杯になると、SMは、さらなるフラグメント要求を与えるのを一時的にサスペンドする。SMは、ネットワーク条件およびたとえばディスプレイのサイズ、残存バッテリ寿命など、他の要因に依存して、p時間中の各時点においてコンテンツをどの品質でプレイバックするべきか決定するのを担う。
SMが、フラグメント要求を提供するのが適切であると考えるとき、SMは、RAがフラグメント要求を受信および処理する準備ができている場合にしか要求を提供することができない。SCは、RAをポーリングすることによって、準備ができているときを決定し、この情報をSMにフォワーディングする。
RAが次の要求を受信する準備ができているときには、SMは、新規要求が発行されるべきかどうか決定し、要求するべき次のフラグメントを選ぶ。SMは、メディアデータについての要求を、一度に1つのフラグメントだけ行う。SMは、コンテンツの適時およびシームレスなプレイバックを可能にするフラグメントを要求するのを担う。リプレゼンテーション中のプレイバック変更は概して、切替え点においてのみ起こり得、2つの連続する切替え点の間に複数のフラグメントがあってよく、SMはその制約を尊重する。
概して、SMは、円滑なプレイバックのために時間内に受信されると信じることが妥当なフラグメントを要求することだけを試みる。ただし、ネットワーク条件が、時には非常に急速に劇的に変化しうることを考えると、このことは、すべての状況において保証されるわけではない。したがって、SMは、要求を取り消すことも可能である。SMは、輻輳が検出されるとともに、何のアクションもとられなかった場合に失速する危険性が大きい場合、要求を取り消す。失速とは、何のアクションもとられない場合、たとえば、フラグメント要求が発行された後間もなく、ネットワーク条件の悪化により、急激に、ダウンロードレートが突然下落する場合の可能性である。
SMは、最も直近の以前選ばれたフラグメントのリプレゼンテーション、すなわちRと、終了p時間、すなわちEとを追跡する。SMは通常、E’=Eという開始p時間を有する次のフラグメントを要求することを選ぶ。いくつかの変形体は、バッファレベルおよび現在のプレイバック時間から決定された開始時間を有し得る。
SMは、切替え点における潜在的重複が破棄された場合、円滑にプレイバックすることができるストリームを生成することを意図した、一連の要求を生成する。SMが要求を作り出す順序は、RAが要求を(必ずしも発行するわけではないが)優先するべき順序と同じである。この順序は、また、RAがSCに受信データを返し、SCがデータをプレイアウトするべきであるのと同じ順序でもある。
SMが、レートを切り替える必要があると決定した場合、一般的ケースでは、切替えのための2つのプロセスがある。1つのプロセスでは、SMは、E以下のp時間をもつ新規の(「switch−to」)リプレゼンテーション中の切替え点(「ランダムアクセスポイント」または「RAP」と呼ばれることもある)Pを探し、そのような点が識別されると、SMは、新規リプレゼンテーション中のフラグメントを要求し始める。第2のプロセスは、Eのものよりも後または等しいp時間をもつ切替え点Pを探すこと、およびPを超える終了時間をもつフラグメントが要求されるまで、古い(「switch−from」)リプレゼンテーション中のフラグメントを要求し続けることのうちの1つである。いずれのケースでも、切替えをSCにシグナリングすることが有用であり得る。
これらのプロセスは両方とも、いくらかの重複データがダウンロードされなければならない可能性があるという特性を有することに留意されたい。switch−fromリプレゼンテーションとswitch−toリプレゼンテーションの両方についてデータがダウンロードされる必要があり得る、p時間のストレッチがある。
これらの切替えプロセスのうちどちらが好ましいかは、状況に依存する。たとえば、ある特定の状況では、プロセスのうち一方についての重複が不当に大きく、他方については極めて短い場合がある。すべてのフラグメントが複数のリプレゼンテーションにわたってアライメントされ、すべてのフラグメントがRAPで始まる単純なケースでは、これらの切替えプロセスは、より簡単な方法に縮小し、この方法において、SMは、switch−fromリプレゼンテーションではなくswitch−toリプレゼンテーションに対して次のフラグメントを要求することによって切り替えるだけである。この場合、どの重複データもダウンロードされる必要はないことにも留意されたい。
1.1.1. SMフラグメント決定プロセス
このセクションは、どのフラグメントを要求するようSCに伝えるべきか決定するためのSMフラグメント決定プロセスについて記載する。これらの例では、単一リプレゼンテーショングループが仮定されるが、これらの例は、複数のリプレゼンテーショングループを使用するプロセスに対処するように拡張することができ、たとえば、ビデオリプレゼンテーショングループからビデオリプレゼンテーションを、およびオーディオリプレゼンテーショングループからオーディオリプレゼンテーションを選ぶ。
1.1.1. SMフラグメント決定プロセス
このセクションは、どのフラグメントを要求するようSCに伝えるべきか決定するためのSMフラグメント決定プロセスについて記載する。これらの例では、単一リプレゼンテーショングループが仮定されるが、これらの例は、複数のリプレゼンテーショングループを使用するプロセスに対処するように拡張することができ、たとえば、ビデオリプレゼンテーショングループからビデオリプレゼンテーションを、およびオーディオリプレゼンテーショングループからオーディオリプレゼンテーションを選ぶ。
SMによって選ばれる次のフラグメントは通常、前のフラグメント要求の終了p時間である開始p時間を有する。以下で、要求するべき次のフラグメントを選ぶための、SM内に実装することができるある程度の詳細な論理について説明する。
以下の例では、フラグメントが、RAPで始まり、リプレゼンテーションの間でアライメントされると仮定する。これが成り立たない場合、この記述の変形形態が可能である。それらの条件が存在する場合、SMのフラグメント決定は、レート決定に縮小し、すなわち、SMは、現在のリプレゼンテーションにとどまるべきか、それとも異なるリプレゼンテーションに切り替えるべきかを決定する。フラグメントが、複数のリプレゼンテーションにわたって必ずしもアライメントされず、RAPで始まらない、より一般的なケースでは、決定は同様であるが、切替えコストが高くなるので、このことを考慮に入れられる。
SMリプレゼンテーションプロセスは、2つの論理的に別個のプロセスを備え、第1のプロセスは、RAが与える短期サンプルから概算持続ダウンロードレートを計算するレートエスティメータであり、第2のプロセスは、この推定値を利用して切替え決定を行う決定プロセスである。
2. レート推定プロセス
適応ビットレートストリーミングクライアントは概して、正しいビットレートメディアを選ぶためのレート決定モジュールによって後で使用されるダウンロードレートエスティメータモジュールを使用する。この手法を用いると、ダウンロードレートが大きいとき、より高品質のメディアがストリーミングされ得る。ダウンロードレートの変化は、リプレゼンテーション切替えをトリガすることができる。レート推定値の品質は、ストリーミングクライアントの品質に対して大きな影響をもつ。
適応ビットレートストリーミングクライアントは概して、正しいビットレートメディアを選ぶためのレート決定モジュールによって後で使用されるダウンロードレートエスティメータモジュールを使用する。この手法を用いると、ダウンロードレートが大きいとき、より高品質のメディアがストリーミングされ得る。ダウンロードレートの変化は、リプレゼンテーション切替えをトリガすることができる。レート推定値の品質は、ストリーミングクライアントの品質に対して大きな影響をもつ。
適応ビデオストリーミングデバイスについての良好なレートエスティメータは、いくつかの特性を有するべきである。第1に、短期ダウンロードレートが大きく変わる場合であっても、分散はほとんどあるべきでない。第2に、基底チャネル(underlying channel)におけるレート変化に素早く適応するべきである。チャネルレートが大幅に下落すると、推定値は、その事実を素早く反映するべきであり、そうすることによってデバイスは、それに従って、失速することなく品質を調整することができる。それに応じて、ビデオ品質の向上が素早く観測されるはずであり、そうすることによってより良好な品質のコンテンツがフェッチされ得る。
それらの2つの要件を満足するには、トレードオフが求められる場合がある。通常、分散が小さいエスティメータは、大きい反応時間を有し、逆もまた同様である。たとえば、デバイス内で使用することができる単純なエスティメータを検討する。そのエスティメータは、何らかの固定Xについて、ダウンロードの最後のX秒にわたって移動平均をとる。大きいX、たとえば、X=30秒(s)を選び出すと、分散がほとんどない比較的平滑な推定値が得られるが、ダウンロードレート変化に対してゆっくりとしか反応しない。そのようなエスティメータがレート決定に使われた場合、結果として得られるプレーヤは、帯域幅下落に対して頻繁に失速し、またはそうすることが安全に可能であるときにより高いビットレートに適時に切り替えそこねる場合がある。これらの理由により、ある実装形態は、より小さなX、たとえばX=3sを選び出す場合がある。そのような選択は、はるかに迅速なレート調整をもたらすが、安定性を犠牲にする。レート推定値は大きく変わり、プレーヤはしたがって、ビデオプレイバックレートを非常に頻繁に変化させて、劣悪なユーザエクスペリエンスをまねきうる。
図5において、凹凸の多い曲線は、たくさんの短期ゆらぎをもつ、未加工ダウンロードレートである。レートエスティメータは、凹凸の多いダウンロードレートの平滑化バージョンである。レートが変化すると、新規持続レートに収束し、レートが変わらない限りは同様のままである。
所望の特性のうち1つは、バッファレベルがわずかな場合、調整は迅速であり、これがレートの高速適応を引き起こし、その結果、ダウンロードレートが下落中であるときには、調整前にプレゼンテーションバッファが空にならない。一方、メディアバッファ内にたくさんのメディアデータがある場合、レート推定値はより平滑であり、調整はより遅い。メディアバッファ中により多くのメディアデータがあるときには、プレイアウトレートは、ダウンロードレートが下落中であるときには、メディアバッファ中のメディアデータがより少ないときよりも、より長い時間期間、より高いままである傾向にある。
これ以降で提示するレート推定プロセスは、pker、pkerプロセス、またはpkerタイプのプロセスと呼ばれ、レート変化に迅速に反応するが、安定してもいるので、低い分散および高い反応性についての要件の両方を満足する。
2.1. pkerプロセス
このセクションは、本明細書においてpker、pkerタイプのプロセスまたは単に「pkerプロセス」と呼ばれるレート推定プロセスについて記載する。基本レートエスティメータは、その推定値を、そこからより長い移動平均を計算するためにある方法または別の方法を使用した、短期レート測定値にのみ基づかせる。上述した基本移動ウィンドウ平均(「MWA」)は、そのようなプロセスの一例である。
このセクションは、本明細書においてpker、pkerタイプのプロセスまたは単に「pkerプロセス」と呼ばれるレート推定プロセスについて記載する。基本レートエスティメータは、その推定値を、そこからより長い移動平均を計算するためにある方法または別の方法を使用した、短期レート測定値にのみ基づかせる。上述した基本移動ウィンドウ平均(「MWA」)は、そのようなプロセスの一例である。
図6〜図7は、レート選択目的で非適応(固定係数)指数加重平均を使用することの効果を示す。これらのプロットは、簡単のために、新規レート推定値が新規ダウンロード選択を直ちにトリガし(すなわち、フラグメントが比較的小さい)、新規レート選択は単にレート推定であると仮定する。
図6は、r時間態様を示す。図に示すように、x軸はダウンロード時間(リアルタイム)である。時間T1において劇的なレート増大が起こるとき、バッファは、非常に速く増大し始め、それは、ビデオデータがプレイアウトされるよりもはるかに速くそのビデオデータがダウンロードされているからである。EWMA推定値は、徐々に真のレートに収束する。
図7は、同じイベントのp時間態様を示す。図において、線702は、スクリーンに表示されるビットレートを示す。レートは、図6のr時間ピクチャにおけるよりもはるかにゆっくり適応する。r時間と比較した、p時間に対する収束の速度は、はじめはNR/ORの割合で減速される(プレーヤが、その時点で、ダウンロードの1秒当たりに約NR/OR秒分のビデオを受信したからである)。したがって、正味の効果は、メディアが、このタイプのレートエスティメータを使用するときには、多大な量のp時間についてのダウンロードレートよりもはるかに低いレートでプレイアウトできることである。
レートが、メディアをストリーミングする目的で推定される場合、エスティメータは、他の関連情報を利用することができる。特に、メディアプレーヤのバッファ、または一般的に、バッファリングされたまたはすでにプレイアウトされた各メディアセグメントをダウンロードするのにどれだけ時間がかかったかについての情報を含む、メディアプレーヤのダウンロード履歴(現在のバッファにあるものよりも過去にさかのぼる)が関心事である。
ある実装形態は、たとえば、MWAエスティメータを使用することができるが、メディアバッファに応じたウィンドウサイズを選ぶことができる。
メディアプレーヤのバッファレベルが高い場合、プレーヤは、ただちに失速する危険状態にはないので、大きいウィンドウを使用して長期推定値をとることができ、結果としてより安定した推定値になる。一方、バッファレベルが低い場合、プレーヤは急速に反応するはずであり、このことは、この場合に、より短い平均化ウィンドウがより良好な選択であることを示唆する。
したがって、レート推定プロセスの実装形態は、変化するウィンドウ幅を使用することができ、現在のメディアバッファ中のp時間の量(つまり、ダウンロードされ、まだプレイアウトされていない現在のp時間の量)に比例するr時間ウィンドウ幅を使用し得る。
別の実装形態は、メディアバッファに現在含まれるバイト数に比例するようにウィンドウ幅を選ぶことができる。
ある実装形態は、単にバッファのレベルではなく、バッファ自体のコンテンツを検査することもできる。たとえば、バッファの大部分が、その同じコンテンツのプレイバック持続期間よりもはるかに短い時間でダウンロードされたと決定した場合、このことは、ダウンロードバッファが急速に増大している最中であり、したがってレートエスティメータは、推定値が調整される必要があると結論づけ得ることを示唆する。
同様に、レートエスティメータは、バッファレベルの変更レートを追跡し、バッファレベルの高速変化を、レート推定値が急速に調整される必要があるというインジケーションとみなすこともできる。
図8〜図9は、可変ウィンドウサイズ加重移動平均(「WMA」)フィルタが使用されるときの、図6〜図7と同じシナリオにおける挙動を示す。この例では、「pker」プロセスは、そのような可変ウィンドウサイズWMAフィルタのように、プログラミングコードとして説明される。pkerプロセスは、プロセッサによって実行されるプログラム命令として実施することができる。
図8において、線802は、基底チャネルが、レートOR(古いレート)からレートNR(新規レート)への急激なレート増大を有する場合のpkerレート推定値である。レート選択が新規レートに適応するのにかかるr時間の量は、OR/NRに比例する。増大が大きい程、適応はリアルタイムで速く起こる。図に示すように、時間T2において、Buff@T2=2*Buff@T1およびTfast=OR/NR*Buff@T1である。
図9は、p時間におけるプレイバック挙動を示す。pkerエスティメータは、新規レートに適応するのに約1バッファ持続期間(レート増大が起きたとき、バッファ中にあったp時間の量)かかり、すなわち、pkerエスティメータは、メディアバッファが、p時間の持続時間Bがメディアバッファに追加された、メディアコンテンツの量を有するときには、新規レートに適応済みであり、ここでBは、新規レートまでのレート増大時におけるメディアバッファ中のメディアコンテンツのp時間の持続時間である。
上記を行う特定のプロセスについて、ここで説明する。このプロセスは、プレイバックバッファの最後のγT比分(γT-fraction)をダウンロードするのに、どれだけのr時間がかかったか決定し、ここでγTは適切に選ばれた定数である。たとえば、これは、現在のプレイバックバッファ全体(γT=1)をダウンロードするのにかかった完了時間であり得、またはプレイバックバッファの後半分(γT=0.5)をダウンロードするのにかかった時間であり得る。γT>1であることもあり得る。Tfastを、プレイバックバッファの最後のγT比分をダウンロードするのにかかったr時間の量とする。推定ダウンロードレートは、ダウンロード時間の前のTfast秒にわたるダウンロードレートを推定することによって計算されることができる。γTの他の値も可能であることに留意されたい。本明細書に記載するように、異なる値が、異なる目標に役立ち得る。
T fast幅のウィンドウにわたるこの種類のウィンドウ化平均は、レート増大を迅速に検出するという、注目すべき特性を有する。実際、Tfastを決定するために値γT<1が使用される場合、エスティメータは、メディアバッファ中のメディアコンテンツのp時間の持続時間がBである特定の瞬間においてどれだけレートが増大する場合でも、レートエスティメータが増大したレートに収束する前にバッファが最大でもBの有限倍数まで増大するという特性を有する。
より精巧なレート推定方法は、上で言及した2つの手法を組み合わせることができる。この方法は特に、バッファレベルBの最小値、および平均化ウィンドウ幅としてのTfast、すなわち、ダウンロードレートを平均すべきr時間の量を使用することができる。より一般的には、ダウンロードレートは、γB・Bの最小値およびTfastの前のr時間にわたって平均されることができ、ここでγBは、適切に選ばれた定数である。そのような選択は、失速する危険をもってレートが下落したときに迅速に反応するという特性を有しており、というのは、それらのケースにおいて、Bは最小値であり、平均化は、メディアバッファ中のメディアコンテンツのp時間の持続時間に比例するr時間にわたり、したがって、メディアバッファが半ばまでドレインするときには、レート推定値は新規レートになるからである。たとえば、レート低下時において、メディアバッファ中のメディアコンテンツ持続期間はBであり、ダウンロードレートが、ダウンロードレート低下前の、選択されたプレゼンテーションのプレイバックレートの比α<1となるように、ダウンロードレートが低下し、悲観的には、選択されたリプレゼンテーションのプレイバックレートは、レート推定値が新規ダウンロードレートに減少するまで低下しないと想定する。次いで、ダウンロードは、レート低下が起こるときを超えてxのr時間だけ継続するので、バッファレベルは、B’=B−x+α・x、すなわち、メディアバッファからx回のp時間ドレインとなり、α・xがメディアバッファにダウンロードされる。レート推定値は、x=B’であるような時点で、すなわち、p時間におけるメディアバッファレベルが、ダウンロードが新規レートであったr時間に等しくなる時点で、新規レートになる。というのは、この時点で、前のr時間のダウンロードにわたる推定値が新規レートになるからであり、それは、この時間全体にわたって、ダウンロードが新規レートで行われたからである。式x=B’=B−x+α・xをxについて解くと、x=B’=B/(2−α)となり、すなわち、バッファB’が依然として少なくともB/2であるとき、レート推定値は新規レートに達する。そうではなく、レートがどこかの時点で大幅に増大する場合、Tfastは最小値になり、前のTfast r時間にわたる平均ダウンロードレートは、前のB r時間にわたる平均よりも大幅に高くなる。
ここで、この構成に基づいて、pkerレート推定プロセスの例について詳細に説明する。このプロセスは、要求アクセラレータ(RA)などのダウンロードモジュールから取得することができる短期レート測定値と、バッファ情報とを使用して、推定値を計算する。バッファ情報は、短期レート測定値が有用な推定値になるためのウィンドウ幅を決定するのに使用される。
図10は、ダウンロードレートが急激に下落するとき、pkerレートエスティメータがどのように発展するかを示す。レートが下落するとすぐに、バッファレベルが下落し始める。レート推定値も、適応し始める。レート推定値は、遅くともバッファレベルが2分の1に下落したときには、新規レート(NR)に達する。この例では、中間レート決定が行われないので、Buffは線形に下落する。中間決定が行われる場合、Buffの降下は徐々に減速する。
pkerプロセスの設計目標は、十分に大きい平均化ウィンドウを使用して、ノイジーな数をもつのを回避し、反応するのに十分に短い数をもつことである。pkerプロセスは、動的に変化するウィンドウサイズをもつウィンドウ化平均を使用することによって、この目標を達成する。RAは、B、すなわちプレイバックバッファのレベル(p時間中)と、プロセスパラメータγBおよびγTと、Tfast、すなわちバッファの(p時間中)最後のγT比分をダウンロードするのにかかったr時間についての保存された値と、R、すなわちr時間中の最後のC持続期間のダウンロードにわたる平均ダウンロード速度とを含む、pkerプロセスによって使用するためのいくつかの変数をメモリ中に維持し、ここでC=max(STP,min(γB・B,Tfast))であり、STPは最小許容可能ウィンドウサイズであり、Cはサンプル時間期間(たとえば100msなど)を超えるはずである。いくつかの実施形態では、γB=1およびγT=0.5であるが、他の値も可能であり、結果としては、両方が正でありγT<1である限り、質的に同様の挙動となる。小さいγBは、pkerプロセスを、レート削減に対して素早く反応させ、小さいγTは、pkerプロセスをレート増大に対して素早く反応させる。
本明細書に記載するように、Cという持続期間にわたるダウンロード速度を計算するために、SMは、RAによって定期的に与えられるダウンロード速度情報を使用する。その目的のために、SMは、RAによって与えられるダウンロード速度情報の履歴を維持し得る。平均がとられる持続期間は、ほとんどのγBバッファ持続時間にあり、このことが、メディアバッファレベルに対して上限があるときに、どれだけの履歴が維持される必要があるかを効果的に制限する。
選択されたプレイアウトレートがダウンロードレートにほぼ等しい場合、ストリームをダウンロードするのには、そのストリームをプレイアウトするのと同じ時間量だけかかるとすると、Tfast=γT・Bとなるので、バッファリング値Cは、バッファ持続期間程度であることに留意されたい。r時間中のバッファレベルの程度のものを選ぶことは、ダウンロードレート推定値についての平滑化間隔に対する当然の選択である、というのは、それは、ストリーミングクライアントが、失速を避けたい場合にもたなければならない見通し量だからである。
単純な一実装形態において、平均化ウィンドウ幅は、B、すなわちビデオバッファに含まれるp時間の量に比例する。そのような選択は、失速をうまく防ぐが、欠点がある。すなわち、ダウンロードレートが、選択されたメディアのレートのk倍である場合、毎秒のダウンロードの結果、p時間のうちk秒間分のメディアがダウンロードされ、レート推定を本当にゆっくり適応させることになる。たとえば、k=10であり、10秒間分のバッファがある場合、レートエスティメータは、適応する前にp時間のうち約k・10s=100s分をダウンロードするが、これは非常に長い時間である。このことが、pker方法へのTfastパラメータの導入の理由となる。実際、平滑化に指数加重移動平均が使用される場合、そのようなフィルタは無限インパルス応答を有するので、事態はある程度悪化し得る。この理由により、pkerプロセスは、代わりに有限インパルス応答フィルタを使用する。プレーンな移動平均は機能するが、一実装形態は、また、より精巧な加重移動平均を使用し得る。
図13は、この最後の点を示す。この図は、単純(固定幅)移動ウィンドウ平均と指数加重移動平均の比較を示す。グラフは、レート変化が見られるときには、固定ウィンドウ移動平均が最初によりゆっくりと新規レートに収束し得るが、1つのウィンドウ持続期間中に収束することを示す。指数加重移動平均は、はじめは急速に動く傾向があるが、後の段階では、ゆっくりと収束するだけである。ウィンドウ化移動平均とは異なり、固定ウィンドウ内では収束しないが、代わりに、レート変化のマグニチュードの対数の時間をかけて収束する。
γ B=1およびγT=0.5なので、pkerプロセスは、様々な保証を与え得る。1つには、ダウンロード速度がどれだけ下落した場合でも、推定値は、バッファがその元の持続期間の半分に縮むのにかかる時間内に新規ダウンロード速度に調整される。もう1つには、ダウンロード速度がどれだけ増大した場合でも、追加のp時間に値する多くとも1つのバッファが、pkerプロセスが新規レートに収束する前にダウンロードされる。直接的な算出は、同様の固定比保証が、0<γBおよび0<γT<1のどの選択にも成り立つことを示す。
バッファレベル、すなわちBを計算する1つの手法は、次のようになる。Tは、メディアプレーヤの現在のプレイバックp時間とし、Fi,1,…,Fi,nは、開始時間の昇順でソートされたリプレゼンテーショングループi中の、ダウンロード済みまたはダウンロード中であって、まだプレイアウトされていないフラグメントとする。依然としてダウンロード中であるグループiのどのフラグメントもFi,1,…,Fi,nの中にある。α(Fi,j)は、すでにダウンロードされたフラグメントFi,jのバイト数を、バイトでのフラグメントFi,jのサイズで除算したものなど、ダウンロード済みのフラグメントFi,jの部分とする。様々なiおよびjについてのα(Fi,j)の値は、RAによって算出され、SMにパスされ得る。所与のグループiについて、ダウンロードされたp時間の現在の総量を、式1にあるように定義する。
式1の結果から全体的Tp値を計算するために、DASHクライアントは、MPD(メディアプレゼンテーション記述メタデータ)から決定される、各グループの重みづけ因子、すなわちw’と、リプレゼンテーショングループの数、すなわちGとを考慮し、式2の計算を実施する。バッファレベルBはこれで、B:=Tp−Tと定義される。
式2は、現在プレイアウトされているフラグメントに属するバッファの部分も取り込む。この定義は、いくつかのフラグメントが一度にダウンロードされる場合にも機能することに留意されたい。
T fastを計算するために、一般的ケースにおいて、SMは何らかの履歴を維持する。Trを、RAがメディアをダウンロードする(ダウンロードしようとする)のに費やしたr時間の総量とし、Zを、RAによってダウンロードされたバイトの総量とする。Trの値は、RAによって計算される。SMは、i=1,2,…,Kについて規則的な間隔で(たとえば、100msおきに)サンプリングされたタプル
となる。
ここで、Tfastを計算するために、Bは、上に挙げた方法ですでに計算されていると仮定する。次いで、RAは、たとえばバイナリサーチで履歴をサーチすることによって、式3の不等式が満たされるようにjを決定する。
となる。無限履歴をずっと維持する必要はなく、最大バッファ持続期間のγB分を超えて広がるTi値についてだけで十分である。
図15は、図16の拡大版とともに、pkerプロセスによって使用される値BおよびTfastが、記録された(Tp,Tr)値の履歴からどのように決定され得るかを示す。この図は、r時間およびp時間が等しく高速に進行し(ダウンロード割込みはない)、したがってプレイバック時間(p時間)が、ダウンロード時間(r時間)の45度の傾斜線であるケースを示す。(Tp,Tr)値の履歴はグラフ中にプロットすることができ、プレイバック失速が起こらない場合、厳密にプレイバックタイムラインの上にある曲線が得られる。バッファレベルBはしたがって、プレイアウト時間に対する最後の記録されたTp値の差である。Tfastの値は、現在の(最後の)Tp値を下回るγT・Bのレベルでの、(Tp,Tr)曲線までの水平距離を測定することによって、このグラフ中に見ることができる。
図11は、図15〜図16と同じ種類のプレゼンテーションを使用して、レートの急上昇に対するpkerプロセスの反応を示す。Tfastは、プレーヤがまだ反応していない急上昇を受信レートが受けたときには、比較的小さい。これは、高受信レートに対する高速反応を示す。平均化ウィンドウは、比較的狭いので、完全にグラフの高レート部分内にあることに留意されたい。したがって、この時点で、pker推定値は、より長いレートにすでに収束している。
図12はやはり、図15のプレゼンテーションを使用して、レート下落に対する可変ウィンドウサイズWMAフィルタ(たとえば、pker)反応を示す。この場合、Tfastは比較的大きくなるが、バッファがドレインするので、Bは小さくなり、ある程度のドレイン時間の後、平均化ウィンドウを、完全に低レートエリア内に収まらせる。図に示すように、平均化ウィンドウの幅、すなわちBは、BがTfastよりも小さくなるようなものであるが、推定値は依然として、バッファが完全にドレインされる前に、より低い新たなレートに収束する。
図14は、pkerレート推定プロセスのフローチャートである。
値が使用される。
となるような最も大きいjを見つけ、次いで、(2)式4にあるように平均ダウンロードレートを計算する。そのようなjが第1のステップにおいて存在しない場合、SMまたはRAは、j:=0、すなわち、最も古い既知の観察結果を設定する。jの値は、バイナリサーチによって効率的に決定することができる。
各グループは、そのグループが消費すると予想される総帯域幅の割合に対応する関連付けられた重み、すなわちwを有する。これは、好ましくは非使用可能リプレゼンテーションがフィルタ除去された後の、MPDによって与えられる情報の関数である。本明細書において、グループgの重みwの提案される定義は、w(g):=maxrate(g)+minrate(g)であり、ここで、maxrate()は、グループg中の最大プレイバックレートであり、minrate()は、最小プレイバックレートである。
重みwから、SMまたはRAは、標準化重みw’を次のように計算することができる。クライアントが、グループ1,…,Gをストリーミングしたいと想定すると、標準化重みは、式5にあるように、すべての重みの合計で除算された重みである。
標準化は、実際にストリーミングされる重みにわたって行われることを意図している。たとえば、ストリーミング中ではないグループがある場合、そのグループは考慮されるべきでない。
このpkerプロセスの動作において、いくつかの仮定が行われる。たとえば、個々のリプレゼンテーショングループのバッファレベルは、互いに比較的近く保たれるべきである。pkerプロセスは、そうすることによってより良好に機能する。たとえば、あるグループが、非常に大きいバッファを有し、別のグループは非常に小さいバッファを有し、両方が同様の重みを有すると想定する。そのようなケースでは、小さいバッファにとっては条件が変わったときに失速を避けることが必要なので、レート推定値の迅速な調整を行うことが必要となる。しかし、pkerプロセスは依然として、その推定値を、はるかに大きいバッファ向けに作用しているかのように満足に平滑化する。逆に、より大きいバッファにとっては、測定値は、バッファレベルが許容する、ある程度高い分散を有するので、ナーバスなレート決定となる。
いくつかのケースでは、バッファレベルが大きく相違するリプレゼンテーショングループを有することは不可避である。この理由により、別の実装形態は、いくつかのバッファが非常に小さいときに、より迅速にレートを調整し、したがってそのようなケースにおいてビットを失速からより良好に保護する、pker方法の変形体を使用することができる。そのような実装形態は、以前と同じようにTfastを計算することができるが、ウィンドウサイズをC=max(STP,min(Tfast,Tp,1−T,Tp,2−T,…,Tp,N−T))に設定する。
これらのダウンロードレート推定の他の変形体は、各リプレゼンテーショングループについての独立pker推定値を使用して、そのグループについて決定を行うことを含む。
3. フェッチング戦略
ストリーミングビデオプレーヤは概して、制限付きメディアバッファを有する。
したがって、通常動作において、最終的にはバッファ満杯状態に達し得ると予想される。
バッファが満杯状態に達すると、ストリーミングモジュールは、バッファのオーバーフィリング(overfilling)を避けるために、メディア入力を抑える(throttle)べきである。これを行うための容易な方法は、バッファが満杯になったときは常に、バッファが次のフラグメントを保持することができるのに十分にドレインされるまで待ち、次いで、フェッチングを再開することである。
ストリーミングビデオプレーヤは概して、制限付きメディアバッファを有する。
したがって、通常動作において、最終的にはバッファ満杯状態に達し得ると予想される。
バッファが満杯状態に達すると、ストリーミングモジュールは、バッファのオーバーフィリング(overfilling)を避けるために、メディア入力を抑える(throttle)べきである。これを行うための容易な方法は、バッファが満杯になったときは常に、バッファが次のフラグメントを保持することができるのに十分にドレインされるまで待ち、次いで、フェッチングを再開することである。
この方法の効果は、各フラグメントが個々にフェッチされ、各フラグメント要求の間に時間ギャップがある、すなわち、次のフラグメントが収まり、要求され得るように、バッファから十分ドレインするのにかかる時間量があることである。
TCPプロトコルは、そのダウンロードレートを、現在のネットワーク条件に基づいて自動調整する。TCP接続を介してダウンロードが開始されたときには、初期ダウンロードレートは、通常、非常に遅く、より高いダウンロードレートを達成することができるかどうかをTCPプロトコルが調べると増大する。どれだけ高速にTCPがダウンロードレートを増大させるか、およびTCPが概してエンドツーエンドのTCP接続のプロパティにどのように反応するかは、極めて複雑であり、固有のエンドツーエンドのネットワークレイテンシ、TCP配信および確認応答経路に沿ったネットワーク要素のバッファ容量、これらの経路に沿った競合トラフィック、TCPのどのような変形体が使用されるかなどを含む、いくつかの因子に依存する。概して、TCPは、遅いダウンロードレートで始まり、そのダウンロードレートを時間とともに増大させ、したがって、ダウンロード時間全体にわたるTCP接続の平均ダウンロードレートは、ダウンロード時間全体が相当なものであるときの持続可能TCPダウンロードレートに近づくだけである。たとえば、持続可能TCPダウンロードレートが1メガビット/秒であり、TCP接続が、事実上ゼロのダウンロードレートで始まり、時間とともに1秒間にわたって1メガビット/秒まで線形に増大した場合、最初の1秒にわたる平均ダウンロードレートは500キロビット/秒であり、平均ダウンロードレートが持続可能ダウンロードレートの95%を達成するには、10秒間のダウンロードが必要である。この理由により、要求の間の多くのダウンローディングギャップを有するフェッチング戦略は理想的ではなく、ダウンロードギャップは、あるダウンロード要求の完了と、次のダウンロード要求の開始との間の時間期間である。ダウンロード要求の間のギャップがゼロであるときでも、通常、TCPは、前の要求の完了の後、次の要求のためにダウンロードレートを増加させるのにある程度の期間かかるので、理想的ではない。各ギャップの後、持続可能スループットは再び達成されなければならない場合があり、これにより達成される全体的な平均ダウンロードレートが低減される。
そのような低減されたレートは、より小さいレート推定値をまねき、したがってより小さいメディアレートの選択をまねき得る。その結果、通常、(バイトでのサイズが)より小さいメディアフラグメントがダウンロードされることになり、これによりギャップの相対的な大きさがさらに増大し、より一層小さいプレイバックレートが選択されることになり得る。言い換えると、その効果は自己増幅型である。
したがって、DASHクライアント実装形態が、この問題の影響を最小限にするプロセスを使用することが有利である。
ある実装形態は、メディアデータを絶え間なくダウンロードし、次いで、バッファレベルを次のように定期的にドレインすることができる。要求されたがまだプレイアウトされていないp時間の量が、あらかじめ設定された高いウォーターマーク、すなわちMhを超える場合はいつでも、SMは、バッファレベルが低いウォーターマークMlを下回るまで、いかなる要求もそれ以上発行しない。特定の実装形態では、Mh=20秒およびMl=10秒であるが、他の実装形態では、それらの値はより低くてもより高くてもよい。低いウォーターマークを下回った後、通常動作が再開され、SMは、フラグメント決定を再び発し始める。
別の実装形態は、プレゼンテーション時間ではなくバイトで指定されたウォーターマークを使用して、同様の効果を達成することもできる。
バッファが定期的にドレインしているという事実は、システムの他の部分によって、有利に利用することができる。たとえば、セクション6.1.2で説明するように、RTTの最新の推定値を取得するのに利用することができる。
図17は、「ウォーターマーク」フェッチングプロセスの挙動を示す。上のグラフは、ドレイン期間とフェッチング期間の交替パターンが見られるバッファレベルグラフである。ダウンロードレートは、下のグラフに表示されている。各フェッチング期間の最初において、TCPは、持続可能最大速度になるのにある程度の時間をかけるので、(フェッチング期間中の)平均ダウンロードレートは、最大達成可能ダウンロードレートよりも小さい。低いウォーターマークと高いウォーターマークとの間の差が大きいほど、フェッチング期間が長くなり、平均レートが高くなる。
4. レート選択プロセス
メディアデータを要求し始めるとき、ストリーミングモジュール(SM)は、何らかの方法を使用して、第1のプレイアウトレート選択を行う。SMは、最も低い利用可能レートをとる場合もあり、あるいは、たとえば、ネットワーク条件の履歴を維持し、次いで、この履歴に基づいて、失速なしで持続される可能性が高い、選ぶべきプレイアウトレートの推定値を決定する場合もある。SMが、すでにデータを受信中であり、したがって自由にレート推定値R(たとえば、セクション2にある方法で計算されたレート推定値のうちの1つなど)を有するとき、SMは、そのレートのまま続けるか、それともリプレゼンテーションを変えるかの決定を行う。
メディアデータを要求し始めるとき、ストリーミングモジュール(SM)は、何らかの方法を使用して、第1のプレイアウトレート選択を行う。SMは、最も低い利用可能レートをとる場合もあり、あるいは、たとえば、ネットワーク条件の履歴を維持し、次いで、この履歴に基づいて、失速なしで持続される可能性が高い、選ぶべきプレイアウトレートの推定値を決定する場合もある。SMが、すでにデータを受信中であり、したがって自由にレート推定値R(たとえば、セクション2にある方法で計算されたレート推定値のうちの1つなど)を有するとき、SMは、そのレートのまま続けるか、それともリプレゼンテーションを変えるかの決定を行う。
単純なレート決定プロセスについて、ここで説明する。受信機は、推定ダウンロードレートRよりも低いプレイバックレートをもつ最も高い帯域幅リプレゼンテーションを決定し、データをプレイアウトする(プレイバックする)ためのリプレゼンテーションとして選び出す。直接的ではあるが、この手法には、いくつかの問題がある。第1に、その手法は、当然ながら、小さいメディアバッファを増大させないので、ダウンロードレートがほとんど変わらないときでも、失速を受けやすい。第2に、変動する推定値Rは、急速に変化するレート決定をまねき、これは、必要ではない場合があり、視覚的に邪魔になり得る。第3に、少なくともおおよそフラグメントの持続期間、したがって一般的に数秒の、スタートアップ時間につながる。
DASHクライアントはしたがって、そのレート決定を、ダウンロード推定値Rだけではなく、バッファレベルB(つまり、バッファリングされ、まだプレイアウトされていないp時間の量)、および概して2つの連続する切替え点の間のp時間の持続時間の推定値である変化レートDなどのコンテンツに依存する変数にも基づかせる、レート決定プロセスを実装することができる。
したがって、一実装形態は、決定レートとして、Rに比例する最も大きいプレイバックレートを選び出せばよく、ここで比例因子はバッファレベルの関数である。
通常、比例因子λは、バッファレベルの増加関数である。ある実装形態は、λを、たとえば、バッファレベルのアフィン関数にすることができる。
λがバッファレベルの関数である場合、ある実装形態は、バッファが空または小さいときには小さくなるようにλを選ぶことができる。そのような選択は、小さいバッファを増大させ、ダウンロードレートが正確に予測されないときに失速に対するある程度の安全性も与えるので、有利である。
より大きいバッファレベルの場合、ある実装形態は、1に近い、1に等しい、または1を超えるλの値を選ぶことができる。こうすることにより、失速する即時の危険性がないときには確実に高プレイアウトレートがダウンロードされるために選ばれることになり、定常状態において高品質メディアがストリーミングされることになる。
レート決定プロセスは、単なる単純なアフィン関数ではなく、Bの区分的アフィン関数であるλを実装することができる。区分的アフィン関数は、任意の連続関数を、任意の所望の程度の精度まで概算することができ、そうすることにより連続関数が適切な選択となる。代わりに、同じプロパティをもつ、他の任意のパラメータ化可能クラスの関数が選ばれることもできる。
別の実装形態は、λを、p時間で表されるバッファレベルではなく、バイトで表されるバッファレベルの関数にすることもできる。
さらに別の実装形態は、λを、バッファレベルBだけではなく、バッファレベルBと切替え機会の頻度の両方の関数にする。そのようにする理由は、レートを変える機会がより少ないプレーヤが、変える機会がより頻繁なものよりも、さらに今後は各決定に関わるからである。したがって、前者のケースでは、各決定は、より大きいタイムスパン、およびより高い危険性への関与である。このことは、バッファレベルBと推定ダウンロードレートRが同じであるとき、失速する危険性を小さく保つために、後者よりも前者のケースではより低いレートを選び出す方がよいであろうということを示唆する。
レート切替え機会の頻度を考慮に入れるレート選択プロセスのための具体的方法は、次のようになる。Dを、ストリーム中の2つの連続する切替え点の間のp時間の典型的な量とする。Dの値は、符号化ビデオに依存し、たとえば、2つの連続する切替え点の間のp時間中の最大距離、または2つの連続する切替え点の平均距離、または2つの連続する切替え点の90パーセンタイル距離、またはメディア中の2つの連続する切替え点のp時間距離の他の任意の適切な測度となるようにとられ得る。そのようなDを所与とすると、方法は、B/Dの区分的アフィン関数、またはその変形体、たとえばB/max(u,D)もしくはB/(D+u)などとなるようにλを選ぶことを含むことができ、ここで値uは、要求を発行する際に誘発されるオーバーヘッドを考慮に入れるために追加される。uの値は、小さい一定の時間量(たとえば100msなど)であることができる。さらなる改良として、ある実装形態は、uを、推定RTTの小さい倍数とすることができる。
上述した方法など、そのレート決定を単にλ・Rに基づかせるプロセスには、Rの比較的小さい変動でさえも、多くのレート切替えをまねき得るという欠点がある。これは、望ましくない場合がある。十分なバッファがあるときには、Rの小さな変化には直ちに反応せず、それに応じてバッファレベルを変わらせる方がよい場合がある。
そのような挙動を得るために、プロセスは、両方とも同じ量(たとえば、上で説明したように、B、B/DまたはB/max(100ms,D))の関数である値λおよびμを使用することができ、これらの値は、現在のレートとともに、新規レート決定を選び出すためのものである。これらの関数は、λ・Rが低い許容可能レート選択となり、μ・Rが高い許容可能レート選択となるように選ばれるべきである。プロセスは次いで、それら2つの値を良好なレート決定のためのガイドとして使用するように設計され得る。
そのような設定において、関数は、概してλ≦μとなるように選ばれるべきである。
レート決定プロセスは、前の選択がすでにλ・R〜μ・Rの範囲内だった場合、レートを同じに保つことを決定し得る。前の選択がλ・R未満の場合、λ・R以下の、最も大きい利用可能プレイバックレートが選択される。前の選択がμ・Rよりも大きい場合、μ・R以下の、最も大きい利用可能プレイバックレートが選択される。
ある実装形態は、関数λおよびμがハードコードされることを選ぶことができる。あるいは、状況に応じて、より入念な方法で関数を選択することもできる。具体的には、一実装形態は、クライアントが最大限で行うバッファリングの量に応じて、適切なλおよびμ関数を選択することができる。オンデマンドコンテンツの場合、クライアントは、たくさんのデータ、可能性としては数分間分のメディアデータをプリバッファリングすることを選ぶことができる。低遅延ライブコンテンツの場合、クライアントは、多くとも、おそらく数秒間のみの、エンドツーエンドのレイテンシによって規定されるメディア量をバッファリングしさえすればよい。バッファリングがほとんどないコンテンツの場合、クライアントは、よりコンサバティブ(conservative)な、すなわち、より小さい値を有する、λおよびμ関数を選び出すと決定し得る。
具体的実装形態は、たとえば、2つの極値関数λ1とλ2との間で関数を線形に補間することができ、ここで選択される補間点は、低バッファウォーターマークMl(セクション3参照)である。したがって、この実装形態は、2つのハードコードされた関数、すなわちλ1とλ2とを有し、λ1は、あるm1未満の、Mlの小さい値用に使われ、λ2は、ある値m1、m2についてMl≧m2であるときに使われ、ここでm1<m2である。m1〜m2の範囲内の値について、関数λ(x):=λ1(x)(m2−Ml)/(m2−m1)+λ2(x)(Ml−m1)/(m2−m1)が使用される。
ここで、上記記述にしたがう、レート決定プロセスの詳細な例を挙げる。このために、いくつかの表記法を採り入れる。
1)S1,S2,…,SLを、リプレゼンテーショングループの(昇順で与えられる)L個の利用可能リプレゼンテーションのストリームレートとする。
2)λ(x)を、負でないスカラーを入力としてとり、負でない実スケーリング係数を戻す区分的一次関数とする。関数λ(x)は、コンパイル時に、または構成ファイルにより設定可能であるべきである。大きいxについて、たとえば、Mlよりも大きいxについて、λ(x)は不変であるべきである。
ここで、そのような関数がどのように実装され得るかについての一例を挙げる。
端点(0,λ0),(x1,λ1),…,(xN,λN)が与えられ、ここでxiは昇順である。λ(x)を評価するために、xi≦xであるような最も大きいiを見つける。次いで、式6を使用して、受信機はこの関数を評価することができる。
端点(0,λ0),(x1,λ1),…,(xN,λN)が与えられ、ここでxiは昇順である。λ(x)を評価するために、xi≦xであるような最も大きいiを見つける。次いで、式6を使用して、受信機はこの関数を評価することができる。
そのようなλ(x)関数についての適切な例は、例示的パラメータN=1、[(0,0.5),(3,1)]によって定義されるもの、つまり、x=0において0.5に等しく、xが3に達するまで線形に増大する関数であり、xが3に達した時点で、関数は1に等しく、その後は1のままである。
3)μ(x)を、別のそのような区分的一次関数とする。そのような関数の一例は、x=0において0になり、x=3において1.5に達し、その後は一定のままであるものである。
4)Dを、(以前指定された)ある切替え点から次の切替え点までのp時間における持続期間の推定値とする。
5)x:=min{(Td−T),Ml}/max{D,1秒)とし、ここでTは現在のプレイバックp時間であり、Tdは、レート決定が行われるp時間であり、Dは、上に挙げた通りであり、Mlはバッファレベル低マーク(セクション3参照)である。
6)CURRを、現在選択されているリプレゼンテーション(すなわち、最後のフラグメント要求において使われたもの)とする。UPを、レートが最高でもλ(x)・Rである最も高いビットレートリプレゼンテーションのプレイアウトレートとし、そのようなリプレゼンテーションがない場合、UPは、最も低いビットレートリプレゼンテーションのプレイアウトレートである。DOWNを、最高でもμ(x)・Rのレートの最も高いビットレートリプレゼンテーションのプレイアウトレートとし、そのようなリプレゼンテーションがない場合、DOWNは、最も低いビットレートリプレゼンテーションのプレイアウトレートである。概してλ(x)≦μ(x)なので、概してDOWN≧UPである。
次いで、レート決定プロセスは、次のフラグメントのレートNEXTを次のように選び出す。(1)UP<CURRの場合、NEXT:=min(DOWN,CURR)であり、(2)それ以外の場合、NEXT:=UPである。
上のステップ5で単にDではなくmax{D,1秒}を使用する理由は、RTTゆえであり、1の役割は、RTTの上限として作用することである。
関数λ(x)およびμ(x)は、xに応じて増加していくことが好ましい。λおよびμ関数は、小さいxについては<1であることが好ましく、それにより確実に、選ばれたプレイアウトレートがR未満になり、小さいバッファレベルについてバッファ増大が引き起こされる。選択されたプレイバックレートは、最高でもmax(λ(B/max{D,1})、μ(B/max{D,1}))・Rに等しく、λ(B/max{D,1})とμ(B/max{D,1})の両方が1未満であるバッファレベルBすべてについてバッファ増大が保証されることに留意されたい。
より簡単なプロセスは、λ(B)・R未満のプレイバックレートをもつ最良リプレゼンテーションとなるように、新規リプレゼンテーションを直接選び出してよい。このリプレゼンテーションは、バッファが空になりそうなときに、バッファは満杯になる傾向にあるというプロパティを依然として有する。ただし、Rは大きく変動し得るので、たくさんのリプレゼンテーション切替えも引き起こす。本明細書において記述する、より洗練されたレート選択プロセスは、切替えを避けようとし、代わりに、より低いプレイバックレートに切り替える前に、バッファをある程度までドレインさせる。これが機能するためには、関数μおよびλは、中間から大までのバッファレベルについて、μがλを超えるように選ばれるべきであり、ここで、選択されたプレイバックレートがCURRであり、測定されたレートがRである場合、式7が満足される限りレート変化は起こらず、レート切替えなしで受信レートをある程度変動させることに留意されたい。
いくつかのバージョンでは、λおよびμは単に、比B/max{D,1}ではなくバッファレベルBの関数である。後者を導入する動機は、次のようになる。
αを、選択されたリプレゼンテーションのプレイバックレートと、ダウンロードレートとの比を示すものとする。良好なαを決定することが望まれる。次の切替え点までダウンロードするのに、ほぼα・Dのr時間だけかかる。受信データがバッファに追加されるすぐ前に、バッファは、B−α・Dまでドレインされている。失速を避けるために、その量を正にしたいが、セーフティクッションとして、それは、ダウンロードされると、バッファに追加されるフラグメントのプレイバック持続期間Dに比例するべきであるので、あるβ>0について、少なくともβ・Dであるべきである。要するに、B−αD≧β・Dとしたい。
αの値を求めると、B/D−β≧αが得られる。これは、リプレゼンテーション選択プロセスが、B/D−βを超えない、プレイバックとダウンロードレートの比を選ぶべきであることを示唆する。関数λ(x)およびμ(x)は、許容可能なそのような比に対する限度であるので、x−βを超えないx=B/Dの関数であるべきである。
実際には、1つのフラグメントを送信する、RTTの追加コストを考慮に入れるために、B/Dを、B/max{D,1}で置き換える。より一般的には、1は、RTTの近似のある程度の倍数、またはサーバからメディアデータのダウンロードを開始するためのプロセスの反応時間を考慮に入れる他のパラメータで置き換えることができる。
図18は、プレイバックレートを選択するのに使用され得るλ関数およびμ関数の例を示す。x軸は、Dの単位で表したバッファレベルであり、y軸は、受信比(receive fraction)、すなわち、プレイバックリプレゼンテーションレートを現在の受信またはダウンロードレートで除算したものである。線1802によって図に示すように、受信比が1未満の場合、バッファは増大し、1よりも大きい場合は縮む。3つのエリアが識別される。第1に、プレーヤは、決定点においてλ曲線1804を下回る場合、高いレートに切り替える。λ曲線1804とμ曲線1806との間である場合、選択されたレートのままである。μ曲線1806を上回る場合、低いレートに切り替える。
図19は、「コンサバティブ(conservative)」設定を使用する、(λ,μ)関数の例示的選択を示す。この設定は、利用可能な帯域幅すべてを使用するわけではないが、引き換えに、非常にまれにしか失速しないという点で「コンサバティブ」である。
図20は、「中間(moderate)」設定を使用する、(λ,μ)関数の例示的選択を示す。この設定は、コンサバティブ設定よりも多い帯域幅を使用するが、わずかに失速しやすいという点で「中間」である。
図21は、「アグレッシブ(aggressive)」設定を使用する、(λ,μ)関数の例示的選択を示す。この設定は、利用可能帯域幅をすべて積極的(aggressively)に使おうとするという点で「アグレッシブ」である。この設定は、他の2つの提示した例示的設定よりも頻繁に失速し得る。
図22は、MLBプロセス、すなわち、米メジャーリーグ(MLB)で働いている何人かの研究者によって提案されたものと同様のプロセスをある程度までエミュレートするためのプロセスを使用する、(λ,μ)関数の例示的選択を示す。(λ,μ)関数は、メディアバッファ充満度に基づいて変わるのではないことに留意されたい。
図23は、λ設定およびμ設定用の隣り合っている値の例を示す。
図24は、λ設定およびμ設定用の隣り合っている値の例を示す。
図36は、レート選択においてλおよびμに使用することができる値のテーブルを備える。
図25は、レート推定、次いでレートベースのレート選択、次いでバッファ管理ベースのレート選択のためのプロセスを示す。この例示的プロセスにおいて、本明細書において記述する手法のうち1つまたは複数が、レート推定を実施するのに使用される。その推定値に基づいて、新規プレイバックレートが選択され、バッファ管理ルールに基づいて調整されることが可能である。
5. 要求取消し
いくつかのケースでは、優れたレート選択プロセスでさえも、単独ではビデオプレイバックの失速を防止することができない。たとえば、要求が行われた後であるが完了される前に、ダウンロードレートが急激に下落した場合、選択されたビットレートは大きすぎた可能性があり、遅いダウンロードレートは、プレイバックレートを変えるための次の切替え機会に達する前であってもプレイバック失速につながり得る。
いくつかのケースでは、優れたレート選択プロセスでさえも、単独ではビデオプレイバックの失速を防止することができない。たとえば、要求が行われた後であるが完了される前に、ダウンロードレートが急激に下落した場合、選択されたビットレートは大きすぎた可能性があり、遅いダウンロードレートは、プレイバックレートを変えるための次の切替え機会に達する前であってもプレイバック失速につながり得る。
別の例として、たとえば、セルラー接続からWiFi接続への移行により、利用可能帯域幅が劇的に増大するときには、メディアバッファは、比較的低いプレイバックレートメディアで満杯になり得る。この場合、すでにダウンロードされたがまだプレイアウトされていないメディアの大部分を破棄し、破棄されたp時間部分を再度ダウンロードするが、今度はダウンロードするべきより高いプレイバックレートリプレゼンテーションを選ぶことが有利であり得る。したがって、すでにダウンロードされた低プレイバックレートメディアは取り消され、別のリプレゼンテーションからのより高いプレイバックレートのメディアが、プレイアウトされるべき場所にダウンロードされるので、より高品質のユーザエクスペリエンスがもたらされる。
この理由により、ストリーミングモジュール実装形態は、ダウンロードレートを監視するモジュールを実装することができ、いくつかの状況では以前の決定を取り消し得る。要求が取り消された場合、ストリーミングモジュールは、ダウンロードレートのより新しい、より適切な推定値に基づいて新規要求を発行するべきである。この監視モジュールを、本明細書では要求取消しプロセスと呼ぶ。
要求取消しプロセスは、様々な理由で要求を取り消すことができる。たとえば、ダウンロードレートが激しく下落し、プレイバックが、データが十分高速に受信されていないことにより、失速する危険があるという理由で、要求を取り消すことができる。取り消す別の理由は、プレイバックのために時間内により高品質のメディアが選択され、取り出され得ると決定された場合である。取り消すさらに別の理由は、受信機が何をしたか、および保留要求の完了の許容に対して取消しが失速期間を短縮するかどうかという推定にかかわらず、失速が起こると受信機が決定した場合である。受信機は次いで、可能性としてはプレイバックされるべきメディアリプレゼンテーションの品質も考慮に入れて、推定されたより短い失速とともに進むアクションを選ぶ。当然ながら、失速があるかどうか、および失速がある場合には失速の持続期間は、推定とは異なり得る。
実際の取消しは、取消しが決定された後には、要求がその上で発行されたTCP接続をクローズすることによって達成することができる。クローズは、取り消されたフラグメントについてのデータを送り続けないようサーバに伝えるという効果を有し、したがって、クローズされた接続によって使用される帯域幅が、置換えデータをフェッチするために利用可能になる。
ストリーミングモジュールは次いで、取り消された部分を置き換えるための要求を発行することができる。この目的のために新規TCP接続をオープンすることが必要な場合がある。
ある実装形態は、置換え要求を選ぶいくつかのオプションを有する。どれが最も適切なオプションであるかは、プレイアウトされているコンテンツのタイプに依存し得る。
それは、ストリームのシームレスなプレイバックを可能にする置換え要求を選び出そうとする場合がある。一般的ケースでは、このことは、置換え要求が、前のダウンロードされたフラグメントの終了時に、またはその前に、切替え点をもたなければならないことを意味する。
その場合、プレーヤは、取消しなしでダウンロードを続けるときに失速が予測され、置換えセグメントの取消しおよび選択を用いると失速を回避でき、または少なくとも失速の持続時間を短縮できることが予測される場合、取り消すべきである。プレーヤは次いで、置換え要求についてのそのプロパティをもつ最も高品質のメディア要求を選び出すことができる。
レート取消しプロセスは、失速を次のように予測することができる。このプロセスは、フラグメント中の未処理バイトの数をダウンロードレートの推定値で除算することによって、発行された要求の推定完了時間を計算することができる。その時間が、円滑なプレイバックのためにフラグメントが必要とされるデッドラインよりも後の場合、失速が予測される。
切迫した失速が予測される場合、要求取消しプロセスは、レートの切替えが事態を改善する見込みがあるかどうかを決定し、改善が見込まれるときのみ、取り消すという決定が行われる。
一実装形態は、候補置換えフラグメントのレート推定値およびサイズにのみ基づいて、置換えフラグメントをロードするのにかかる時間を推定することができる。
別の実装形態は、取消しによる追加オーバーヘッドも考慮に入れることができる。すなわち、既存の要求を取り消し、新規要求を発行するのに必要とされる時間を考慮するために、推定RTTの倍数を加算することができる。取り消された要求からネットワーク上での配信のためにキューイングされているがまだ宛先には届いていないデータは、追加遅延に寄与し得る。クライアントは、この遅延を、TCP受信ウィンドウサイズを推定レートで除算することによって推定することができる。遅延の別の推定値は、推定帯域幅遅延積に基づき得る。クライアントは、2つの推定値のうちの最大値など、2つの推定値を組み合わせることができる。
要約すれば、クライアントは、置換えフラグメント全体をダウンロードするのに必要とされる時間と、通常はRTTに比例する量と、キューイング遅延の推定値との合計を計算する。失速が予測され、その時間が現在のフラグメントをダウンロードするための推定残り時間よりも小さい場合、取消しが発行される。
要求取消しプロセスは、また、初期のレート選択が正確でなかったために、第1のフラグメントをダウンロードするのに所望されるよりも長くかかることにプレーヤが気づいたときには、スタートアップ時に取り消すこともできる。
別のレート取消し実装形態は、また、シームレスなプレイバックを認めず、いくつかのフレームをスキップすることを含意する、置換え要求を選び出すこともできる。これは、エンドツーエンドのレイテンシが小さく保たれることを要求するライブコンテンツを再生するときに必要となり得る。
フレームスキップを用いて取消しを行う実装形態は、フレームスキップが可能な限り小さくなるような方法で置換えフラグメントを選び出すことができる。
この実装形態は、置換え要求として、指定された失速持続期間またはスキップフレーム持続期間を超えることなく持続可能にダウンロードすることができる、最も高品質の要求を選ぶことができる。
すでにダウンロードされたフラグメントについては、異なる種類の取消しが実装され得る。プレーヤは、プレイアウトされる予定のいくらかのメディアをすでにバッファリングしている場合、ネットワークを通じてより高品質のリプレゼンテーションをフェッチし、それをストリーミングすることを決定することができ、以前バッファリングされた、より低品質バージョンは破棄し得る。
その取消しプロセスは、失速することなくプレイアウトすることができるように時間内により良好な品質のビデオを受信することができると決定した場合、これらの置換え動作を行うことを決定し得る。
図26は、時間T1における新規フラグメント要求の直後に起こる、ダウンロードレートの強烈な下落を示す。この要求まで、受信レートはORであり、次いで、NRに下落する。バッファレベルは今では下落している。新たに要求されたフラグメントは、約T2=T1+OR/NR*フラグメント持続期間の時間に、完全にダウンロードされる。
OR/NRが大きい場合、この値は、時間T1におけるバッファ中のメディアコンテンツのp時間の持続時間よりも大きくなり得、このことは、要求されたフラグメントは、失速なしではプレイバックされないことを意味する。pkerエスティメータは、はるかに速くレートNRに収束しているが、T1よりも前に要求が行われたので、フラグメントのダウンロードは、推定値が新規レートNRに収束する機会がないうちに行われることに留意されたい。失速を避け、訂正された推定値をもつ新規要求を発行するために、要求を取り消し、より適切なビットレートで要求を再発行することが必要である。
OR/NRが大きい場合、この値は、時間T1におけるバッファ中のメディアコンテンツのp時間の持続時間よりも大きくなり得、このことは、要求されたフラグメントは、失速なしではプレイバックされないことを意味する。pkerエスティメータは、はるかに速くレートNRに収束しているが、T1よりも前に要求が行われたので、フラグメントのダウンロードは、推定値が新規レートNRに収束する機会がないうちに行われることに留意されたい。失速を避け、訂正された推定値をもつ新規要求を発行するために、要求を取り消し、より適切なビットレートで要求を再発行することが必要である。
図27は、要求取消しのあるケースを示す。ダウンロードレートの鋭い下落(線2702)の後、バッファはドレインし始め、推定ダウンロードレート(たとえば、pkerプロセス)は、新規ダウンロードレートに収束し始める。どこかの時点で、ストリームマネージャは、失速なしでプレイバックのための時間内にフラグメントが受信されないことに気づく。その点は、図27のプロットにおいて、「取消し点」2704としてマークされている。その時点で、部分的に受信されているフラグメントは、取り消され、バッファから追い出される(したがって、バッファレベルがさらに下落する)。しかしその後、正しいレートをもつフラグメントが要求され得るので、バッファレベルはそれ以上下落しない。実際、自明でない(nontrivial)レート選択プロセスが使用される場合、レベルは再度増大し得る。
図28は、例示的要求取消しプロセスを示すフローチャートである。
図29は、要求取消し検出のためのプロセスを示す。
ここで、上記詳細に基づいて、要求取消し実装形態について説明する。
このセクションにおいて、Niは、要求されたが、まだ完全には受信されていない、リプレゼンテーショングループi中のフラグメントの数を示す。これらは、Fi,1,…,Fi,Niとして参照される。さらに、Fi,jは、開始p時間の昇順でソートされると仮定し、α(Fi,j)は、要求されたフラグメントFi,jについてすでにダウンロードされたバイトの量を、バイトで表されたフラグメントのサイズで除算したものである。変数Tは、現在のプレイバックp時間を示す。要求取消し検出プロセスは、図29の擬似コードによって示すように進行し得る。
要求取消し検出プロセスは、実行されると、ニル(nil)を返すことができ、この場合はいかなるアクションもとられることはなく、あるいは、取り消すべきグループ中のフラグメントを識別する。そのようなフラグメントが識別された場合、このことは、このフラグメント、および(p時間順で)その後にくる、同じグループ中のあらゆるものが、取り消され、バッファからフラッシュされるべきであることを意味する。SMは次いで、そのレート決定プロセスを再度呼び出し、セクション用に新規代替要求を発行するべきである。
このプロセスを説明するために、差し当たり、単一の要求のみが今のところ未処理であると仮定する。その場合、Rを、ダウンロードレートの正確な推定値とし、davailを、問題となっているフラグメントがプレイアウトされることになるまで、依然として受信することができるバイト数とする。量dneedは、そのフラグメント中で依然として欠けているバイト数である。したがって、davail<dneedの場合、プレーヤは、フラグメントFi,jを再生する前に失速すると予測する。このことは、以上のプロセス中の最初の「if」条件について説明している。
失速が予測される場合であっても、取消しにより失速を避けることになる場合、または少なくともその持続期間を短縮する場合にのみ、取り消すことに意味がある。取消しの後には、新たなフラグメントが選択され、最初からダウンロードされなければならない。ただ1つのリプレゼンテーショングループがあり、レート決定プロセスが正しいレートを選んだ場合、これには持続期間(Fi,j)のほぼλ倍の時間がかかり、ここでλは、現在の適切なラムダ因子である。一方、SMが切り替えないと決定した場合、現在のフラグメントダウンロードの終了には、dneed・R-1の時間がかかる。簡単のために、λ=1と仮定すると、他の因子をもち得る、第2の条件が得られる。
6. 要求アクセラレータ
ストリーミングメディアクライアント向けの直接的なやり方は、単一HTTP接続を用いてメディアをフェッチすることである。そのようなクライアントは、フラグメント要求を連続して処理することになる。そのような手法には、ビデオストリーミングにおいていくつかの欠点がある。第1に、一般的ネットワーキングソフトウェアはしばしば、長いダウンロードにわたる最大スループットについてのみ合わせられる。これは、大きいファイルを受信するには良いが、安定受信レートなど、他の重要なストリーミング目標とは相反する。第2に、TCPの性質により、リンクの満杯容量は、必ずしもそのようなHTTP接続とともに使用することができるわけではない。チャネルが、ある程度の遅延とパケット損失とを受ける場合、TCPは、達成され得る実際のスループットを制限し、こうすることにより、ストリーミングクライアントが、良好な品質のメディアをストリーミングするのが妨げられる場合がある。
ストリーミングメディアクライアント向けの直接的なやり方は、単一HTTP接続を用いてメディアをフェッチすることである。そのようなクライアントは、フラグメント要求を連続して処理することになる。そのような手法には、ビデオストリーミングにおいていくつかの欠点がある。第1に、一般的ネットワーキングソフトウェアはしばしば、長いダウンロードにわたる最大スループットについてのみ合わせられる。これは、大きいファイルを受信するには良いが、安定受信レートなど、他の重要なストリーミング目標とは相反する。第2に、TCPの性質により、リンクの満杯容量は、必ずしもそのようなHTTP接続とともに使用することができるわけではない。チャネルが、ある程度の遅延とパケット損失とを受ける場合、TCPは、達成され得る実際のスループットを制限し、こうすることにより、ストリーミングクライアントが、良好な品質のメディアをストリーミングするのが妨げられる場合がある。
これらの問題を避けるために、本明細書において要求アクセラレータ(RA)と呼ぶ、特殊HTTPクライアントが実装されることができる。要求アクセラレータは、前述した問題を回避または軽減するための特殊プロセスを有する。要求アクセラレータのある実装形態は、いくつかの重要な要素を利用して、その目標を達成することができる。それは、いくつかのTCP接続を使用して、データを受信することができる。それらの接続は、並行してアクティブであることができる。データ要求を、より小さいチャンク要求に分割することができ、それらのチャンク要求は、異なる接続上で個々にダウンロードされ、要求アクセラレータにおいて、1つの大きな部分に再アセンブルされ得る。それは、接続が相互に公平(fair)になるように、TCP接続パラメータ(具体的には、TCP受信ウィンドウサイズなど)を調節し、比較的安定したデータ受信を行うことができる。それは、使用するべきTCP接続の数を、測定されたネットワーク条件および目標プレイバックレートに基づいて動的に調整することができる。
使用するべきTCP接続の理想的な数は、ネットワーク条件、特に、ラウンドトリップ時間(RTT)およびパケット損失挙動に依存する。RAはしたがって、これらの量を推定するための方法を使用することができる。
RAは、HTTP要求の発行から、応答が着信し始めるまでかかる時間をサンプリングすることによって、RTTを推定することができる。一実装形態は、一定期間、たとえば最後の数秒間にわたって取得されたすべてのそのようなサンプルの最小値をとることによって得られるRTTの推定値を使用することができる。別の実装形態は、最後のN個の取得サンプルの最小値を使用することができ、ここでNは、推定値としての何らかの整数である。
TCPプロトコルは、パケット損失を扱い、連続するデータプリフィックスをアプリケーションに届けるので、TCP層より上でのパケット損失の測定値を取得することは、しばしば困難である。したがって、代わりに、パケット損失についての妥当な値をRAプロセスへの入力として固定することが有用なことがある。ある実装形態は、損失を一定であると推定し得る。いかなるパケット損失測定値ももたないので、RAは、損失を1%であると推定する場合もあり、または、RAは、損失を0.1%であると推定する場合もある。推定値は、接続のタイプによって決定されることができ、たとえば、推定値は、WiFi接続については0.1%に設定され、セルラー接続については1%に設定され得る。RTTにおける分散など、他の方法も、RAによってパケット損失を間接的に推論するために使用されることができる。あるいは、ある実装形態は、パケット損失推定値を、それに関する情報についてオペレーティングシステムカーネルを照会することによって取得することができる。
別の実装形態は、アプリケーション自体における損失を推定することができる。
そうするために、その実装形態は、ネットワークソケットからのデータが概して最大セグメントサイズの(MSS)チャンクの形で受信されるが、パケット損失は、はるかに大きいチャンクの受信、すなわち近似的にTCP受信ウィンドウ全体のサイズのバーストを引き起こす、という観察に基づいた以下の手順を使用することができる。Mを、バイトで表されたMSSとすると(良好な推測は、M=1500である)、nバイトが受信された場合、送られるパケットの数は約n/Mである。zを、k・Mバイトを超える読込みを生じたソケット読込みの数とする、ここでkは、ある小さい整数である。kは、アプリケーションの2つのネットワーク読込みの間にk個以上のパケットが到着した見込みがないように、十分に大きいように選ばれると仮定する。ソケット上でコンスタントに待機するアプリケーションについては、k=3がよい。すると、p=z・M/nが、パケット損失確率の推定値である。所望の開始点から、zとnとをカウントすることによって、この手順は、時間の任意の所望の範囲にわたるパケット損失レートを推定することができる。
そうするために、その実装形態は、ネットワークソケットからのデータが概して最大セグメントサイズの(MSS)チャンクの形で受信されるが、パケット損失は、はるかに大きいチャンクの受信、すなわち近似的にTCP受信ウィンドウ全体のサイズのバーストを引き起こす、という観察に基づいた以下の手順を使用することができる。Mを、バイトで表されたMSSとすると(良好な推測は、M=1500である)、nバイトが受信された場合、送られるパケットの数は約n/Mである。zを、k・Mバイトを超える読込みを生じたソケット読込みの数とする、ここでkは、ある小さい整数である。kは、アプリケーションの2つのネットワーク読込みの間にk個以上のパケットが到着した見込みがないように、十分に大きいように選ばれると仮定する。ソケット上でコンスタントに待機するアプリケーションについては、k=3がよい。すると、p=z・M/nが、パケット損失確率の推定値である。所望の開始点から、zとnとをカウントすることによって、この手順は、時間の任意の所望の範囲にわたるパケット損失レートを推定することができる。
RTTの推定値およびパケット損失確率が与えられると、アプリケーションは、必要とされるかなりの数の接続を計算することができる。このプロセスは特に、目標ダウンロードレートがその接続数で達成され得るように十分に大きい、接続の数を選ぶことができる。単一レートの達成可能レートは概して、達成可能スループットに関するTCP式によって制限され、この式によると、おおまかにいえば、単一のTCP接続が、T=MSS/(RTT・√p)の平均ダウンロードレートを達成することができる。したがって、このプロセスは、目標ダウンロードレートをTで除算したものに比例するように、接続の数を選べばよい。
RAは、使用するべきTCP接続の数に対して、現実的な理由により、下限と上限とを課してもよい。たとえば、RAは、RAがオープンする接続の最大数を8に、および接続の最小数を2に制限してよい。
帯域幅、損失確率、およびRTTは、変わることがある。要求アクセラレータは、それらの量を監視し、接続の数を動的に変える。
要求アクセラレータは、HTTP要求を、より小さいサブ要求に分割し、あらゆるサブ要求についての戻されたデータ応答を、元の要求に対応するコヒーレント応答に再アセンブルすることができる。要求をサブ要求に分割するのには、いくつかの利点がある。第1に、利用可能TCP接続を使用するために、それらの接続すべての上で要求を発行できることが必要である。メディアストリーミングプレーヤは、接続すべてを使用するような十分な要求を与えるわけではない場合がある。要求分割は、より多くの数のサブ要求を生じ、サブ要求は様々な接続上で発行され得るので、この問題を緩和する。第2に、要求分割はより短い要求を生じ、そうすることによって時機を逸したデータ配信の危険性が低減され、すなわち、一部のTCP接続が、他の接続よりも時間的に遅い場合、それらの一部の接続は、依然として短い要求とともに使用されることができる。それらは、速い方の接続よりも応答を配信するのが遅いが、要求が小さいので、全体的要求を完了するための追加的な相対遅延は通常、それ程大きくない場合がある。
概して、より多くの接続が使用されている場合、1つの要求につき、より多くのサブ要求を作成することが好ましい。これを達成するために、要求アクセラレータは、n個の接続があるとき、各要求を、n個のサブ要求に分割することができる。
別の実装形態は、要求サイズに応じて、1つの要求当たりのサブ要求の数を選び出す。サブ要求サイズが、ダウンロードするのに一定の時間量(たとえば、2秒)かかることが予測されるサイズとなるように選ばれた場合、要求は、より多くの接続がある場合はより多くのサブ要求に分割され、所望の効果を達成する。
分割ルールは、不必要に小さいサブ要求がないようにすべきである。たとえば、RA実装形態は、その分割プロセスにおいて最小サブ要求サイズを課し、最小値が満たされない場合はより少ないサブ要求に分割することができる。
マルチプルなTCP接続が使用されるとき、それらの接続は、帯域幅について競合する可能性がある。大きい時間スケールにおいて、各接続は、他の接続と同じ量を受信するが、2〜3秒間など、より小さいスケールでは、一部のTCP接続は、他の接続よりも著しく遅い場合がある。これは、いくつかのサブ要求が、他の要求よりもはるかに長くかかる場合があり、それがプレイバック失速につながり得ることを含意するので、ストリーミングについての問題を起こす。
これを避けるために、RAは、TCPフロー制御を使用して接続を「制御(tame)」すればよい。こうすることにより、各TCP接続の最大受信ウィンドウを十分に制限することができるので、接続は、その公平なスループット分担を超えて使用することはない。TCP接続を介して飛行中の(送られたが、まだ受信確認されていない)データの量はおおよそ、ダウンロードレートをRTTで除算したものである。したがって、TCP受信ウィンドウが、接続についての目標ダウンロードレートを推定RTTで除算したものにおおまかに、またはそれよりもわずかに大きく設定された場合、ダウンロードレートは、目標ダウンロードレートにおおまかに、またはわずかに大きく制限される。したがって、TCP受信ウィンドウサイズの設定は、調速機(governor)として作用することができ、所与のTCP接続が、他のTCP接続にはるかに低いレートでダウンロードするよう強制したような高いレートでダウンロードすることがないようにする。そのようなメカニズムが整っているので、接続は、おおよそ同じ速度でフェッチする傾向にあり、というのは、遅い接続は、公平な分担まで速度を上げるのに利用可能な帯域幅を有するが、同時に、接続は、少なくとも総目標受信レートであり、またはそれよりもわずかに高い、総ダウンロードレートを達成し得るからである。
RAは、受信バッファを調整することによって、クライアントにおける受信ウィンドウを調整することができる。RAは、連続する要求の間でこれらの設定を常に再調整する。
一実装形態は、各接続のTCP受信ウィンドウを、推定RTTと、目標ダウンロードレートを接続の数で除算したものの積よりもわずかに大きく設定し得る。
目標ダウンロードレートは、たとえば、プレイバックすることを目指すメディアレートから決定され得る。別の実装形態は、現在のプレイバックレートに基づいて(たとえば、現在のダウンロードレートの2倍)目標レートを設定し得る。
6.1 RAの実施形態
ここで、上述した要素を組み込む要求アクセラレータの実施形態について説明する。
ここで、上述した要素を組み込む要求アクセラレータの実施形態について説明する。
図30は、マルチプルなTCP接続を用いてフェッチする挙動のプロットである。図30〜図31は、様々な条件下での挙動を示す。この例において、ウェブサーバへの接続は、毎秒2メガビット(「mbps」)に制限された帯域幅であり、ラウンドトリップ時間は150msであり、0.1%のパケット損失があった。4つの接続アクティブフェッチフラグメントがあった。図30〜図31のプロットは、4つの接続の瞬間レート、ならびに総合レート、ならびにクライアントにおいて取得されたRTT推定値を示す。
図30において、接続の受信バッファは制限されていない。図31では、受信バッファは帯域幅と遅延との積の約2倍に制限されている。
図30および図31の例において、両方の方法は、安定して2mbpsの総スループットを達成する。接続が制限された受信ウィンドウを有するケース(図31)では、接続の間の配信は、いっそう一様であり、すなわち、ほとんどの時間、接続はほぼ同じレートで受信する。これは、無制限ウィンドウをもつ接続(図30)にはまったく当てはまらず、この場合、いくつかの接続は、長い時間ストレッチにわたって、他の接続よりも遅い。
不均一な接続速度は、ストリーミングアプリケーションにとって問題があり、というのは、何らかの緊急データが、(遅い接続上で)非常にゆっくりとしか着信しておらず、帯域幅は、緊急には必要とされないデータをフェッチすることができるより速い接続の方に転用されることを意味し得るからである。
無制限ウィンドウと制限受信ウィンドウとの間の別の違いは、クライアントが動作するときのRTTである。制限が整っているので、RTTは、低いままであり、伝播遅延に近い。受信ウィンドウ制限がないので、飛行中のデータの量が、基底の伝播遅延に接続の容量を乗じたものを超えると、キューイング遅延は非常に大きくなり、高RTTを引き起こし得る。多くのイベントに対するクライアントの反応時間は概してRTTの倍数であるので、高RTTは、メディアストリーミングクライアントにとって望ましくない。たとえば、新規メディアコンテンツをダウンロードさせるユーザ探究イベント、または要求取消しもしくはリプレゼンテーションの切替えを引き起こすダウンロード速度の低減に対するクライアント反応時間は概して、現在のRTTの何倍にもなり、したがってそのようなイベントに対するクライアントの一般的応答性は、RTTが大きいとき低下する。
図32は、要求アクセラレータプロセスのフローチャートである。
図33は、所与のフラグメント要求を生み出すためのいくつかのサブ要求を見つけるためのプロセスを示す。
図34は、計算されたサイズを有するソース要求の分離区間となるように選ばれた個々の要求を選択するためのプロセスを示す。このプロセスにおいて、サブ要求サイズは意図的にランダム化され、そうすることによって、接続がアイドルである時間は、接続によって変化する。こうすることにより、すべての接続が同時にアイドルになることが避けられ、その結果、より良好なチャネル使用となる。要求サイズも順序付けられ、そうすることによって、より大きい要求がより早く出され、制限されるアイドル時間の差を保つのを助ける。
図35は、時間オフセットと、時間オフセットによって決定される修復セグメントについてのフラグメント構造との例を示す。
動作に際して、要求アクセラレータは、HTTP要求(各要求は、URLおよびバイト範囲である)をSCから受信する。
要求アクセラレータは、HTTPを介して、要求されたバイト範囲をダウンロードし、データが完全に受信されると、SCにデータを返す。RAは、十分に大きいダウンロード速度を達成するが、同時に、各フラグメントがその最終期限時間前に必ず受信されるようにすることを目指す。高ダウンロード速度により、高品質のビデオリプレゼンテーションを選ぶことが可能になるとともに、期限を尊重することによって、プレイバックが失速なしで必ず進むようになる。
高ダウンロード速度という目標を達成するために、RAは、変化する数のオープンなTCP接続を管理し、これらの接続はすべて、HTTPを介してデータを受信するのに使用される。RAは、何個の接続を使用するべきか、必要な場合はそれらの接続のオープンまたは再オープン、ならびにどのように要求を接続にディスパッチするかの詳細について引き受ける。
RAは、いくつかのケースでは、ソース要求を、より小さいいわゆるRA要求に分割することを決定し、RA要求は次いで、様々な接続にディスパッチされ、その応答データは、到着すると、RAによってトランスペアレントに再アセンブルされる。たとえば、何らかのファイルの最初の64キロバイトを備えるソース要求について、RAは、2つのRA要求を作成することができ、1つはそのファイルの32キロバイトチャンクについてであり、もう1つは、第2の32キロバイトチャンクについてである。RAは次いで、それらの2つのチャンクを2つの異なる接続上で並列に要求し、2つの32キロバイトチャンクが受信されると、元の要求について、コヒーレントの64キロバイト応答を作成することができる。
RAは、ソース要求の単なるプレーンな部分的範囲以上のものであるRA要求を発行し得る。たとえば、プレーンなビデオデータに加え、フラグメントのFECデータについての要求を発行することができる。その場合、RAは、FEC情報が受信されると、その情報をトランスペアレントに復号し、最終的な復号フラグメントのみをソースに提示することになる。
RAは、RA自体を、ネットワーク条件に自動調節する。たとえば、RTTが大きい場合、RAは、要求の間のたくさんのアイドル時間を避けるように、より大きいチャンク要求を発行することを決定し得る。自動調節の別の例は、RAが、その要求の適時性を確実にするように、個々の接続の速度を同様に保とうとすることである。それらのことをできるようにするために、RAは好ましくは、その接続のソケットへの直接アクセスを有する。たとえば、Unix(登録商標)のような環境では、setsockopt()関数を使用してソケットオプションを設定することが可能である。
RAは、ネットワーク状態を測定および追跡し、これは特に、ダウンロードレートと推定ラウンドトリップ時間(RTT)とを測定することを含む。RAがこの情報を収集する理由は、第1に、接続の自動調節がそれらのアベイラビリティに依存するからであり、第2に、帯域幅情報がSMにパスされる必要があるからであり、SMは、その情報を使用してSMレート推定値を計算する。
RAがSMに(SCを経由して)フォワードする別の情報ピースは、未処理要求についての進行情報、すなわち、所与の要求のうちどの程度のデータがすでに受信されているかである。SMは、その情報を、SMレート推定値と、要求取消し決定の両方に対して使用する。
RAは、SMによって、帯域幅推定を行うのに必要とされる情報を追跡する。この情報は、ダウンロードに費やされるr時間の総量、すなわちTr、およびダウンロードされたバイトの総量、すなわちZである。これらの数は両方とも、単調に増加しており、SMによって頻繁にポーリングされる。Trタイマは、少なくとも1つの接続がアクティブである場合にのみ動作している。接続は、HTTP要求を送り出し、または応答データが着信するのを待っている場合、アクティブと見なされる。Zカウンタは、着信バイトをカウントし、すべての接続にわたって集計される。
6.1.1 RAダウンロードレート履歴
要求アクセラレータは、履歴順に記憶される、(Tr,Z)ペアの増大アレイを保つことによって、レートの何らかの履歴を追跡する。このアレイを、mapTrZと呼ぶ。mapTrZの更新は、頻繁に、少なくとも一定時間間隔で(たとえば、100msおきに)、場合によっては新規データが受信されたときにも、起こる。
要求アクセラレータは、履歴順に記憶される、(Tr,Z)ペアの増大アレイを保つことによって、レートの何らかの履歴を追跡する。このアレイを、mapTrZと呼ぶ。mapTrZの更新は、頻繁に、少なくとも一定時間間隔で(たとえば、100msおきに)、場合によっては新規データが受信されたときにも、起こる。
RAは、mapTrZを利用して、ウィンドウ化帯域幅推定値を次のように計算することができる。幅tである、関心のウィンドウを検討し、mapTrZ[last]を、mapTrZ中の最後のエントリとする。次いで、mapTrZ[i].Tr≦mapTrZ[last].Tr−tであるような、最も大きいインデックスiを見つける。
iは、バイナリサーチで効率的に見つけられ得ることに留意されたい。レート平均は次いで、式8に示すようになる。
iは、バイナリサーチで効率的に見つけられ得ることに留意されたい。レート平均は次いで、式8に示すようになる。
式8は、後続Trにおける差が、tと比較して小さいと仮定する。このことは、十分頻繁にサンプリングし、小さいウィンドウ幅tを決して選び出さないことによって保証される。
実際に、任意に増大するアレイは厄介である。過去について考察される最大持続期間は上限を定められ得るので、mapTrZを、代わりに固定サイズのリングバッファとして実装するやり方がある。これは、次のように行われ得る。mapTrZアレイがアップデートされるべきであり、mapTrZアレイが少なくとも2つのペアをすでに含むときは常に、Tr−mapTrZ[last−1].Tr<100msである場合は最後のエントリを置き換え、新規エントリを他のやり方で追加する。
6.1.2 ラウンドトリップ時間(「RTT」)推定値
RAは、帯域幅推定値を収集する。アプリオリなRTTサンプルを受け取るための簡単なやり方は、HTTP GET要求がアイドル接続上で送出され、応答が着信し始めるときの時間の差を測定することである。
RAは、帯域幅推定値を収集する。アプリオリなRTTサンプルを受け取るための簡単なやり方は、HTTP GET要求がアイドル接続上で送出され、応答が着信し始めるときの時間の差を測定することである。
ただし、そのような測定値は、キューイング遅延を実際に含む。すなわち、クライアントが他のオープンなアクティブ接続を有する場合、クライアントにデータを送る最後のホップは、クライアントへのそのリンクが、データを受信することができるレートよりも低いレートを有する場合、いくつかのパケットをバッファリングし得る。その場合、パケットは、本来よりも長い遅延で配信され得る。
我々のケースでは、クライアント自体の活動によって誘発されるキューイング遅延を無視するRTTを知ることが望ましい。その量の推定値を受け取るために、次のように進める。
各活動期間中、前述したタイミング方法を用いてRTTサンプルを収集し、各GETの結果、サンプルが得られる。すると、現在の推定値は、すべてのそれらのサンプルのうち最小である。サンプルのリストは、RAが非アクティブになるときには常にフラッシュされる。(クライアントは、たとえば、高ウォーターマークのセクション3を超え、開始されたダウンロードが終了すると、非アクティブになる)。非アクティブ期間中、またはどのRTTサンプルも受信される前のアクティブ期間中、RTT推定値は、最終的な既知の推定値である。
RTTエスティメータは、象徴的な「どのRTT推定値も既知でない」という値を戻すこともでき、この値は、たとえばクライアントスタートアップ時に使用することができる。
6.1.3 TCP接続の数の調整
TCPフロー制御の調節により、RAは、様々な接続における帯域幅を、おおよそ同じに保つことができる。いくつかの構成可能な調節定数は、kR(RTT中で測定されたレート測定値ウィンドウであって、奨励値は30)と、kN(比例因子であって、奨励値は8192バイト)と、Nmin(Ntarget下限であって、奨励値は1)と、Nmax(Ntarget上限であって、奨励値は8)とを含み得る。
TCPフロー制御の調節により、RAは、様々な接続における帯域幅を、おおよそ同じに保つことができる。いくつかの構成可能な調節定数は、kR(RTT中で測定されたレート測定値ウィンドウであって、奨励値は30)と、kN(比例因子であって、奨励値は8192バイト)と、Nmin(Ntarget下限であって、奨励値は1)と、Nmax(Ntarget上限であって、奨励値は8)とを含み得る。
推定の帯域幅遅延積(BDP:bandwidth-delay-product)は、BDP:=RTT・Rとなるように定義され、ここでRTTは推定RTT(上記のように)であり、ここでRは、最後のkR・RTT時間(ウィンドウ方法で推定される)にわたる平均受信レートである。
N targetの値は、定期的に計算し直される。現在オープンな接続の数がNtarget未満である場合、Ntargetに一致するように、新規接続が直ちにオープンされる。一方、Ntargetが、現在オープンな接続の数未満の場合、いかなる即時アクションもとられない。そうではなく、RA要求が終了されると常に、RAは、オープンである接続の数が多すぎるかどうかをチェックし、多すぎる場合、アイドルになったばかりの接続をクローズする。
に設定する。ここで、cwは、設定可能なハードコードされた定数であり、たとえばcw=3である。RAは、その接続上で次のHTTP要求を発行しようとしているときには常に接続のTCP受信ウィンドウサイズを設定する。
6.1.5 要求分割プロセス
RAに渡された各ソース要求は、おそらく2つ以上のRA要求に分割され、これらのRA要求は各々、要求された範囲の異なる部分に対応する。所与のソース要求に対応するRA要求がすべて完了されると、受信データは、RAによって完了フラグメントに再アセンブルされ、完了フラグメントは次いで、SCに戻される。
RAに渡された各ソース要求は、おそらく2つ以上のRA要求に分割され、これらのRA要求は各々、要求された範囲の異なる部分に対応する。所与のソース要求に対応するRA要求がすべて完了されると、受信データは、RAによって完了フラグメントに再アセンブルされ、完了フラグメントは次いで、SCに戻される。
所与のHTTP要求について、RAは、いくつかの調節可能値に依存するプロセスを使用して、RA要求の数nを決定する。nの値は、Twn(レート推定値ウィンドウ幅であって、奨励値は4s)、Dmin(最小フェッチ持続期間であって、奨励値は2s)、およびcs(RTT中の最小フェッチ持続期間であって、奨励値は6)という調節可能な定数に依存する。
すると、サブ要求の数nを見つけて、所与のフラグメント要求を行うためのプロセスは、図33の擬似コードに示すようになる。
個々の要求は次いで、たとえば、計算されたサイズを有する、図34に示すプロセスを使用して、ソース要求の分割間隔となるように選ばれる。
6.1.6 要求ディスパッチプロセス
要求アクセラレータは、RA要求のセットを維持する。接続が、次の要求を発行する準備ができたときには常に、キューが空いていない場合は要求がRAキューからデキューされ、アイドル接続上で発行される。キューが空の場合、新規フラグメント要求がSCから取得される。その要求は次いで、RA要求に分割され、RAキュー上でキューイングされる。キューイングは好ましくは、サブ要求の数を見つけて所与のフラグメント要求を行うためのプロセスによってスライスが戻される順序で行われる。
要求アクセラレータは、RA要求のセットを維持する。接続が、次の要求を発行する準備ができたときには常に、キューが空いていない場合は要求がRAキューからデキューされ、アイドル接続上で発行される。キューが空の場合、新規フラグメント要求がSCから取得される。その要求は次いで、RA要求に分割され、RAキュー上でキューイングされる。キューイングは好ましくは、サブ要求の数を見つけて所与のフラグメント要求を行うためのプロセスによってスライスが戻される順序で行われる。
HTTP接続は、様々な理由で、たとえば、ウェブサーバタイムアウトが起こり、または単一接続上で発行され得る要求の数を超えたことが原因で、シャットダウンを受け得る。RAは、このステータスを適切およびトランスペアレントに扱うべきである。接続がシャットダウンされるときは常に、RAは、接続を自動的にオープンし直す。要求は、クローズされた接続上で要求が進行中の場合、接続からデキューされ、未受信部分についての新規RA要求が、RAキューの前に置かれる。
この手順により、クローズされた接続は確実に、パフォーマンスに対して最小限の影響しかもたないことになる。
6.1.7 特定の実施形態におけるRAパラメータ選択
TCP接続は、そのフロー制御によって制限される。すなわち、広告される受信ウィンドウは、どの時点でも受信確認されないことが許容されるデータの量に上限を定める。したがって、Wが、受信ウィンドウのサイズを示し、bdpがその接続の帯域幅遅延積を示す場合、bdp≦W(条件1)を得る。セクション6.1.4の方法は、cw>1であるとすると、この条件(1)が満たされるような受信ウィンドウサイズを選ぶことを記述している。この方法により、個々の接続が、利用可能帯域幅のその公平比率を実質的に超える比率をとる可能性は確実になくなる。レート増大を可能にし、レート下方スパイラルを避けるために、1よりもある程度大きいcw、たとえば、cw=2またはcw=4を選ぶことが好ましい。この値が大きい程、レートはより速くなることができるが、相互に対して接続が公平でなくなる。
TCP接続は、そのフロー制御によって制限される。すなわち、広告される受信ウィンドウは、どの時点でも受信確認されないことが許容されるデータの量に上限を定める。したがって、Wが、受信ウィンドウのサイズを示し、bdpがその接続の帯域幅遅延積を示す場合、bdp≦W(条件1)を得る。セクション6.1.4の方法は、cw>1であるとすると、この条件(1)が満たされるような受信ウィンドウサイズを選ぶことを記述している。この方法により、個々の接続が、利用可能帯域幅のその公平比率を実質的に超える比率をとる可能性は確実になくなる。レート増大を可能にし、レート下方スパイラルを避けるために、1よりもある程度大きいcw、たとえば、cw=2またはcw=4を選ぶことが好ましい。この値が大きい程、レートはより速くなることができるが、相互に対して接続が公平でなくなる。
となる。したがって、この例では、式9におけるNを設定するために、セクション6.1.3において提案されたようにkN=8,192バイトと設定することにより、式11の不等式が確実に満足される。受信機は、適切に構成またはプログラムされ得る。
ここで、所与のソース要求についてのRA要求の数nを計算するための、上のセクション6.1.3のプロセスに移る。アプリオリに、小さいスライスはいくつかの利点を呈するのでスライスを可能な限り小さくしたい。そのような利点として、ある接続が他の接続に比べて遅い場合、そのことが、小さい要求に関する問題を引き起こす可能性は比較的低い、というのは、小さい要求は、遅い接続上であっても迅速に終了するからである。したがって、小さいスライス設定では、遅い接続は本質的に、比較的少ない要求をサービスする結果になる。小さいスライスの別の利点は、RAに、バッファの時間内の比較的短いセクションに対して作用させるので、RAは、最も緊急な作業エリアに対するその作業を強化する傾向があることである。
ただし、スライスを小さくすることには、代償が伴う。すなわち、第1に、各要求が、アップリンクとダウンリンクの両方においていくらかのオーバーヘッドを招く。第2に、1つの要求を終了した後、接続は、約1RTTだけ、アイドルのままである。したがって、要求分割プロセスは、理想的には、あまりにも多くのアップリンクトラフィックを引き起こすことも、各利用可能リンクの容量を実質的に利用しきれないこともない、可能な限り小さいチャンクを選ぶことを試みるべきである。好ましいプロパティはしたがって、次のようになる。
1.リアルタイムのDminごとに、1つの接続につき多くとも1つの要求を目指す。こうすることにより、アップリンクトラフィックは、最悪のケースにおけるNtargetに比例する値を限度とする。
2.cs・RTTおきに、1つの接続につき多くとも1つの要求を目指す。こうすることにより、接続の活動時間が、少なくとも約cs/(cs+1)になるようにされ、すなわち、中間のcsでは1に近づく。
D minの良好な選択は、使用ケースに依存する。所望のエンドツーエンドの遅延と同程度(ただしそれ未満)のDminを選び出すことは、一般に、フラグメントの典型的な持続期間である。エンドツーエンドの遅延が大きくなるべき場合、より大きいバッファが使用されることができ、より大きいスライスの悪影響はより小さくなる。一方、短いエンドツーエンドの遅延において、バッファは小さいので、スライスは、失速を引き起こす遅い接続を避けるように小さくあるべきである。そのシナリオにおいて、より高いコストの、より小さい要求は、バッファレベルでの、得られる安定性に値する。
使用されるパラメータは、MPD(メディアプレゼンテーション記述)中のプロファイルインジケータが、クライアントに対する、ストリーミングされるメディアのプロパティの要約なので、そのインジケータに従って調節され得る。あらゆるメディアセグメントをダウンロードし、それらをエンドユーザに見せるのではなく、クライアントは、MPD内部のプロファイルにある様々な使用ケースに基づいて、セグメントを「スキップする」ことを選ぶことができる。
c sの選択に対する下限は、次のように考えればよい。N個のオープンな接続があり、RAがアクティブである場合、平均で、約N・cs/(cs+1)個のアクティブな接続がある。すべてのN個の接続の受信ウィンドウが、全体として、総計目標レートを持続させるのに十分に大きくなるのを確実にするために、cw・cs/(cs+1)が少なくとも1であることが望ましい。
この限度はコンサバティブである。アクティブ接続の推定数N・cs/(cs+1)は、ある程度の分散がある可能性が高くても、分散を考慮に入れていない平均にすぎない。実際に、csを、上記限度によって奨励される値の約2〜3倍にすることが有利であり、たとえば、cw=3およびcs=6のとき、cw・cs/(cs+1)は少なくとも2.5である。
6.2. 前方誤り訂正をもつRA
データがいくつかのTCP接続を介して受信されるとき、これらの接続は、時間的に異なるダウンロードレートを有することがある。フラグメントの要求がいくつかのサブ要求に分割されたとき、フラグメント全体は、最後のサブ要求応答(チャンク)が受信されたときに受信されるだけである。フラグメントが緊急に受信される必要があるとき、サブ要求のうち1つが遅い接続上で扱われる場合があり、フラグメントが素早く受信されるのを妨げるので、これは問題となる場合がある。
データがいくつかのTCP接続を介して受信されるとき、これらの接続は、時間的に異なるダウンロードレートを有することがある。フラグメントの要求がいくつかのサブ要求に分割されたとき、フラグメント全体は、最後のサブ要求応答(チャンク)が受信されたときに受信されるだけである。フラグメントが緊急に受信される必要があるとき、サブ要求のうち1つが遅い接続上で扱われる場合があり、フラグメントが素早く受信されるのを妨げるので、これは問題となる場合がある。
コンテンツプロバイダは、ビデオデータに加え、各フラグメントについての追加の前方誤り訂正(「FEC」)修復データを与えることができ、クライアントはこのデータをフェッチして、元のフラグメントを再構築するのを助けることができる。たとえば、クライアントが、4つの接続を有し、4000バイトのサイズのフラグメントを緊急に受信する必要があると仮定する。クライアントの要求アクセラレータは、フラグメントを、各々が1000バイトからなる4つの範囲に分割し、4つの接続の各々において1つの要求を発行することができる。接続1は高速であり、接続4は適度に高速であるが、第2および第3の接続ははるかに遅い場合がある。したがって、総ダウンロードレートが、原則として、フラグメント全体を時間内にダウンロードするのに十分に高い場合であっても、フラグメントは、接続2および3が行き詰っているので、非常に遅れてしか届かない。
この問題を避けるために、クライアントは、それ自体のサブ要求についてデータフェッチが行われるとすぐに、接続1を使用して、接続2または3と同じデータをフェッチしようとする場合がある。これは役に立ち得るが、RAは、どの接続がより多くの助けを必要とするか、その接続が2それとも3であるか決定を行わなければならない。RAが誤った予測を行った場合、RAは、複製データを不必要にダウンロードしている場合があり、フラグメントは依然として、時間内に届くことができない。
より優れた要求アクセラレータは、代わりに接続1を使用して、何らかの修復データをフェッチすることができる。修復(FECコード化された)データは、ダウンロードに成功した場合、要求2または3からのデータが欠けているかどうかにかかわらず、欠けているデータを再構築するのに使用することができる。唯一の制約は、受信されるデータの量は、フラグメントを再構築するのに十分なことである。言い換えると、我々の例では、修復バイトの数に、受信されたフラグメントバイトの数を加えると、4000以上になるはずである。
ある実装形態では、コンテンツプロバイダは、コード化ビデオセグメント用のFEC修復データへのアクセスを与える。プロバイダは、修復データを、元のビデオデータと同様にして、利用可能にすることができる。たとえば、各メディアセグメントファイルについて、修復情報を含む追加FECファイルを与えることができる。コンテンツプロバイダは、メディアプレゼンテーション記述においてFECを使用するための、必要な情報とパラメータとを与えることができる。別の実装形態では、メディアプレゼンテーション記述は、FECについてのいかなる情報も含まないが、クライアントは、セグメントURLからFEC修復URLの名称をどのようにして導出するかについてのルールなど、一般的な協定を使用して、その情報にアクセスすることができる。
クライアント実装形態は、修復データをいつどのようにして要求するかに関するプロセスを実装することができる。要求される修復データの量は、どれだけ多くのデータが未処理であるかに依存し得る。さらに、どれだけすぐにフラグメントが利用可能になる必要があるかに依存し得る。たとえば、十分すぎる時間が残されている場合、ソースデータすべてを時間内に受信することを望むので、どの修復を要求することも、おそらく余分である。一方、フラグメントが緊急になりつつある場合、クライアントが、そのフラグメントについての十分なデータを時間内に受け取るのに失敗した場合は失速が切迫しているので、たくさんの修復データを要求したいと思うかもしれない。したがって、ある実装形態は、要求される修復データの量をβ(B)Sとなるように設定することができ、ここでSは未処理ソースデータの量であり、β(B)はバッファレベルの減少関数である。
別の実装形態は、未処理データの量を、未処理の総量ではなく、最も不完全な要求中の未処理データの量に比例させ得る。
6.2.1 修復セグメントジェネレータの実施形態
DASH規格がどのようにFECを使用するか、特に、FEC用のRaptorQを使用するかに関する、以下の算出はすべて、好ましくは、固定小数点/整数演算を使用して実施される。この算出は、リプレゼンテーションのフラグメント内のソースシンボルの数および位置を算出することを含み、修復セグメント内のフラグメント用の修復シンボルの数および位置を算出することは、固定小数点演算を使用して行われるべきである。
というのは、受信FEC修復フラグメントとソースフラグメントの組合せを使用してソースフラグメントを復号するRAプロセスとまったく同じ結果が、ソースセグメントからFEC修復フラグメントを生じる取込み(ingestion)プロセスによって達成される必要があり、したがってこれらの算出はまさに同じ出力結果をもたなければならないからである。固定小数点演算ではなく浮動小数点算出を使用すると、異なるプラットフォーム上の異なる浮動小数点実装形態の異なるコーナーケース挙動により、追跡するのが難しく、両方のエンドポイントがまさに同じ算出結果を生じなければならない規格において許容可能でない、わずかなバグのある挙動が時として生じ得る。
DASH規格がどのようにFECを使用するか、特に、FEC用のRaptorQを使用するかに関する、以下の算出はすべて、好ましくは、固定小数点/整数演算を使用して実施される。この算出は、リプレゼンテーションのフラグメント内のソースシンボルの数および位置を算出することを含み、修復セグメント内のフラグメント用の修復シンボルの数および位置を算出することは、固定小数点演算を使用して行われるべきである。
というのは、受信FEC修復フラグメントとソースフラグメントの組合せを使用してソースフラグメントを復号するRAプロセスとまったく同じ結果が、ソースセグメントからFEC修復フラグメントを生じる取込み(ingestion)プロセスによって達成される必要があり、したがってこれらの算出はまさに同じ出力結果をもたなければならないからである。固定小数点演算ではなく浮動小数点算出を使用すると、異なるプラットフォーム上の異なる浮動小数点実装形態の異なるコーナーケース挙動により、追跡するのが難しく、両方のエンドポイントがまさに同じ算出結果を生じなければならない規格において許容可能でない、わずかなバグのある挙動が時として生じ得る。
修復セグメント内のフラグメントについての修復シンボルの数と位置とを算出することを伴わない、後で説明する他のすべての算出は、取込みと、正確に同じ結果を算出するためのRAプロセスとの間に依存がないので、所望される場合、(固定小数点でも問題はないが)浮動小数点を用いて行うことができる。
修復セグメントは、sidxテーブルを含む、すでに処理されたソースセグメントに基づいて、別個のプロセスにおいて生成することができる。ソースセグメント自体に加え、プロセスへの2つの入力は、修復比(repair fragment)RおよびシンボルサイズSである。セグメント内の修復フラグメントの修復シンボルの数および位置の算出に固定小数点演算を使用することを円滑にするために、Rの値は、パーミルで表されることができ、すなわち、R=500は、比が1/2であることを意味する。
各セグメント内で、ソースセグメントの始めにおいて、時間/バイトオフセットセグメントマップを備えるセグメントインデクシング情報も存在する。時間/バイトオフセットセグメントマップは、時間/バイトオフセットペア(T(0),B(0))、(T(1),B(1))、...、(T(i),B(i))、...、(T(n),B(n))のリストであり、ここでT(i−1)は、すべてのメディアセグメントの中のメディアの初期開始時間に対する、メディアの第iのフラグメントのプレイバック用のセグメント内の開始時間を表し、T(i)は、第iのフラグメントについての終了時間(およびしたがって、次のフラグメントについての開始時間)を表し、バイトオフセットB(i−1)は、メディアの第iのフラグメントがソースセグメントの最初のものに相対して始まる、このソースセグメント内のデータの最初のものの対応するバイトインデックスであり、B(i)は、第iのフラグメントまでの、およびそのフラグメントを含むセグメント中の対応するバイト数である(したがって、B(i)は、フラグメントi+1の第1のバイトのインデックスである)。セグメントが複数のメディア成分を含む場合、T(i)およびB(i)は、絶対的な方法でセグメント中の各成分に対して与えられることができ、または、基準メディア成分をサービスする別のメディア成分に対して表されることができる。いずれの場合にも、B(0)は、セグメント中の第1のフラグメントの開始バイトインデックスであり、このインデックスは、セグメント中の第1のフラグメントに先行するsidx情報により、ゼロよりも大きいことがある。B(0)がゼロでない場合、修復セグメントの最初には、sidxに対応するいくつかの修復シンボルがある。実装形態によっては、これらの第1の修復シンボルは、第1のフラグメントの最初まで、セグメント中のデータを保護することもでき、使用されない、ゼロをパディングしたデータバイトであってもよい。
修復比Rは、修復セグメントメタデータとともにMPDに入れてシグナリングされても、他の手段(TBD)によって取得されてもよい。Rについての値の例として、R=500の場合、修復セグメントサイズは、それが生成される元のソースセグメントの対応するサイズの0.5倍として、(非常に厳密に)概算され、ソースセグメント内の、ソースフラグメントに対応する、修復セグメントの修復フラグメントのサイズのサイズも、ソースセグメントのサイズの0.5倍として(非常に粗く)概算される。たとえば、ソースセグメントが1,000キロのデータバイトを含む場合、対応する修復セグメントは、ほぼ500キロバイトの修復データを含む。
Sの値は、修復セグメントメタデータとともにMPDにおいてシグナリングされる、または他の手段によって取得されることができる。たとえば、S=64は、ソースデータおよび修復データが、FEC符号化および復号の目的のために、各々が64バイトのサイズのシンボルを備えることを示す。Sの値は、関連付けられたソースセグメントのリプレゼンテーションのストリーミングレートに比例するように選ぶことができる。たとえば、ストリーミングレートが100Kbpsの場合、S=12バイトが適切であり得、ストリーミングレートが1Mbpsの場合、S=120バイトが適切であり得、ストリーミングレートが10Mbpsの場合、S=1,200バイトが適切であり得る。1つの目標は、どの程度の粒度のフラグメントがシンボルに区分されるかと、ストリーミングレートと比較したFEC復号についての処理要件と、の間の良好なトレードオフを有することであり得る。たとえば、1Mbpsのストリーミングレート、および約500msのサイズのフラグメントにおいて、各フラグメントは約64KBのデータであり、S=120の場合、フラグメントは、ほぼ500個のソースシンボルからなり、このことは、各シンボルが、ソースブロックを回復するのに必要とされるデータの約0.2%であることを意味し、このことは、シンボル粒度により必要とされる余剰受信が、フラグメントが受信されている最中のHTTP接続の数に0.2%を乗じたものを上限とすることを意味する。たとえば、HTTP接続の数が6の場合、シンボル粒度受信オーバーヘッドは、1.2%を限度とする。
修復セグメントは、ソースセグメントについて次のように生成することができる。ソースセグメントの各フラグメントは、FEC符号化目的のためのソースブロックと見なされ、したがって各フラグメントは、修復シンボルがそこから生成されるソースブロックの一連のソースシンボルとして扱われる。第1のi個のフラグメント用に生成された修復シンボルの総数は、TNRS(i)=divceil(R*B(i),S*1000)として算出され、ここでdivceil(I,J)は、少なくともIをJで除算したものである値、すなわち、divceil(I,J)=(I+J−1)div Jをもつ、最も小さい整数を出力する関数であり、ここでdivは、結果が、最も近い整数に切り捨てられる固定小数点除算である。したがって、フラグメントiについて生成される修復シンボルの数は、NRS(i)=TNRS(i)−TNRS(i−1)である。
修復セグメントは、フラグメントについての修復シンボルの連結を備え、修復セグメント内の修復シンボルの順序は、フラグメントが生成される順序であり、フラグメント内で、修復シンボルは、それらの符号化シンボル識別子(「ESI」)の順序である。
上述したように、フラグメント用の修復シンボルの数を定義することによって、すべての前のフラグメント用の修復シンボルの総数、ならびにしたがって修復フラグメントiのシンボルについてのバイトインデックスおよびバイト範囲は、R、S、B(i−1)およびB(i)にのみ依存し、ソースセグメント内のフラグメントの前または後続構造のいずれにも依存しないことに留意されたい。これは、クライアントに、修復セグメント内の修復ブロックの開始の位置を素早く計算させ、修復ブロックがそこから生成されるソースセグメントの対応するフラグメントの構造についてのローカル情報のみを使用して、その修復ブロック内の修復シンボルの数も素早く計算させるので、有利である。したがって、クライアントは、ソースセグメントの中央からのフラグメントのダウンロードとプレイバックとを始めることを決定した場合、対応する修復セグメント内にあるフラグメントに対応する、対応する修復ブロックを素早く生成し、アクセスすることもできる。
フラグメントiに対応するソースブロック内のソースシンボルの数は、NSS(i)=divceil(B(i)−B(i−1),S)として算出される。最後のソースシンボルは、B(i)−B(i−1)がSの倍数でない場合、FEC符号化および復号の目的のために、ゼロバイトでパッドアウトされ、すなわち、最後のソースシンボルは、FEC符号化および復号の目的のためにサイズがSバイトになるように、ゼロバイトでパッドアウトされるが、これらのゼロパディングバイトは、ソースセグメントの一部として記憶されない。本実施形態では、ソースシンボルについてのESIは、0,1,...,NSS(i)−1であり、修復シンボルについてのESIは、NSS(i),…,NSS(i)+NRS(i)−1である。
本実施形態における修復セグメントについてのURLは、たとえば添字「.repair」をソースセグメントのURLに単に追加することによって、対応するソースセグメントについてのURLから生成することができる。
修復セグメントは、たとえば、末尾に付加される、対応するソースセグメントの一部でもあり得る。組み合わされたセグメントの構造は、ソースフラグメントおよび修復フラグメントが、組み合わされたセグメント内で連続し、すなわち、組み合わされたセグメントが、第1のソースフラグメント、それに続く第1の修復フラグメント、それに続く第2のソースフラグメント、それに続く第2の修復フラグメントなどを備えるようなものでもあり得る。当業者には認識されるように、上述した方法およびプロセスは、そのような組み合わされたセグメントに適用するために、容易に採用することができる。
6.2.2 修復セグメントを使用する要求アクセラレータの実施形態
修復セグメントについての修復インデクシング情報およびFEC情報は、対応するソースセグメントについてのインデクシング情報によって、RおよびSの値から暗黙的に定義され、ここでRは、パーミルを示す0と1000との間の整数として表され、Sは、バイトで表される。時間オフセットおよび修復セグメントを備えるフラグメント構造は、対応するソースセグメントの時間オフセットおよび構造によって決定される。フラグメントiに対応する修復セグメント中の修復シンボルの冒頭および末尾へのバイトオフセットは、それぞれ、RB(i−1)=S*divceil(R*B(i−1),S*1000)およびRB(i)=S*divceil(R*B(i),S*1000)として算出され得る。フラグメントiに対応する修復セグメント中のバイト数はすると、RB(i)−RB(i−1)であり、したがってフラグメントiに対応する修復シンボルの数は、NRS(i)=(RB(i)−RB(i−1))/Sとして算出される。(分子がSの倍数であることが保証されるので、ここではdivceil演算は必要ないが、divceilはここで使用することができ、結果は依然として正しくなることに留意されたい)。フラグメントiに対応するソースシンボルの数は、NSS(i)=divceil(B(i)−B(i−1),S)として算出することができ、ここで最後のソースシンボルは、必要な場合、符号化について記述したのと同じく、復号目的のためにゼロでパディングされる。したがって、修復セグメント内の修復ブロックについての修復インデクシング情報、および対応するFEC情報は、対応するソースセグメントの対応するフラグメントについてのR、Sおよびインデクシング情報から暗黙的に導出することができる。
修復セグメントについての修復インデクシング情報およびFEC情報は、対応するソースセグメントについてのインデクシング情報によって、RおよびSの値から暗黙的に定義され、ここでRは、パーミルを示す0と1000との間の整数として表され、Sは、バイトで表される。時間オフセットおよび修復セグメントを備えるフラグメント構造は、対応するソースセグメントの時間オフセットおよび構造によって決定される。フラグメントiに対応する修復セグメント中の修復シンボルの冒頭および末尾へのバイトオフセットは、それぞれ、RB(i−1)=S*divceil(R*B(i−1),S*1000)およびRB(i)=S*divceil(R*B(i),S*1000)として算出され得る。フラグメントiに対応する修復セグメント中のバイト数はすると、RB(i)−RB(i−1)であり、したがってフラグメントiに対応する修復シンボルの数は、NRS(i)=(RB(i)−RB(i−1))/Sとして算出される。(分子がSの倍数であることが保証されるので、ここではdivceil演算は必要ないが、divceilはここで使用することができ、結果は依然として正しくなることに留意されたい)。フラグメントiに対応するソースシンボルの数は、NSS(i)=divceil(B(i)−B(i−1),S)として算出することができ、ここで最後のソースシンボルは、必要な場合、符号化について記述したのと同じく、復号目的のためにゼロでパディングされる。したがって、修復セグメント内の修復ブロックについての修復インデクシング情報、および対応するFEC情報は、対応するソースセグメントの対応するフラグメントについてのR、Sおよびインデクシング情報から暗黙的に導出することができる。
一例として、バイトオフセットB(1)=6,410で始まり、バイトオフセットB(2)=6,770で終わるフラグメント2を示す、図35に示す例を検討し、すなわち、フラグメント2はサイズが6,770〜6,410バイトであり、6,770は、フラグメント3の開始バイトインデックスである。この例では、シンボルサイズはS=64バイトであり、垂直点線は、Sの倍数に対応する、ソースセグメント内のバイトオフセットを示す。ソースセグメントサイズの割合としての全体的な修復セグメントサイズは、この例ではR=500パーミルに設定される(修復は、ソースのほぼ1/2である)。フラグメント2用のソースブロック中のソースシンボルの数は、NSS(2)=divceil(6,770−6,410, 64)=(6,770−6,410+64−1)div64=6として算出され、これらの6つのソースシンボルは、それぞれESI0、...、5を有し、ここで第1のソースシンボルは、ソースセグメント内のバイトインデックス6,410で始まるフラグメント2の最初の64バイトであり、第2のソースシンボルは、ソースセグメント内のバイトインデックス6,474で始まるフラグメント2の次の64バイトであり、以下同様である。フラグメント2に対応する修復ブロックの終了バイトオフセットは、RB(2)=64*divceil(500*6,770, 64*1,000)=64*(3,385,000+64,000−1)div64,000=64*53=3,392として算出され、フラグメント2に対応する修復ブロックの開始バイトオフセットは、RB(1)=64*divceil(500*6,410, 64*1,000)=64*(3,205,000+64,000−1)div64,000=64*51=3,264として算出され、したがってこの例では、それぞれ、修復セグメント内のバイトオフセット3,264で始まり、バイトオフセット3,392で終わる、ESI6および7をもつフラグメント2に対応する修復ブロック中に2つの修復シンボルがある。
このことは、図35に示されている。図35に示すこの例において、R=500である(修復は、ソースのほぼ1/2である)とともに、フラグメント2に対応する6つのソースシンボルがあるとしても、修復シンボルの数を算出するのにソースシンボルの数を単に使用している場合に期待し得るように、修復シンボルの数は3ではなく、2となるように算定されることに留意されたい。修復シンボルの数を決定するのに、フラグメントのソースシンボルの数を単に使用するのとは反対に、ここで行われるやり方は、対応するソースセグメントの対応するソースブロックに関連付けられたインデックス情報のみから、修復セグメント内の修復ブロックの位置決めを算出することを可能にする。これを、取込みプロセスにおける、およびRAプロセス内での無矛盾の算出にするために、修復セグメント内の修復フラグメントについての修復シンボルの数および位置の算出が、固定小数点演算を使用して算出されることが重要である。さらに、ソースブロック中のソースシンボルの数、すなわちKが増大すると、対応する修復ブロックの修復シンボルの数、すなわちKRは、概して、KRは多くともdivceil(K*R, 1,000)であり、KRは、少なくともdivfloor((K−1)*R,1000)であるので、K*R/1,000によって厳密に概算され、ここでdivfloor(I,J)=I div Jである。
7. 例示した実施例
図25は、レート選択プロセスを示す。λおよびμについての設定が高い程、設定はアグレッシブになる。図23は、パラメータλについての様々な値を示す。図24は、パラメータμについての様々な値を示す。ハイブリッド設定が、2つのメインメカニズムによって、レートゆらぎを削減しようとする。第1のメカニズムは、Bが比較的大きいとき、レートを増大させることにより慎重であることによるものであり、第2のメカニズムは、Bが比較的小さいとき、より懸命に、現在のレートに留まろうとするものである。
図25は、レート選択プロセスを示す。λおよびμについての設定が高い程、設定はアグレッシブになる。図23は、パラメータλについての様々な値を示す。図24は、パラメータμについての様々な値を示す。ハイブリッド設定が、2つのメインメカニズムによって、レートゆらぎを削減しようとする。第1のメカニズムは、Bが比較的大きいとき、レートを増大させることにより慎重であることによるものであり、第2のメカニズムは、Bが比較的小さいとき、より懸命に、現在のレートに留まろうとするものである。
pker x.y:C=x*min(y*Tdl,B)についての例示的設定は、8.1、4.2、2.4、4.4または他のx.y値に設定されたx.yであり得る。
pkerの実際の平均化ウィンドウは、ダウンロード中断期間のスキップにより、Cよりも長いことに留意されたい。EWMAのスキップはなく、ダウンロード中断期間中のレートは、最後のダウンロード間隔のものと同じであると仮定する。
pkerの実際の平均化ウィンドウは、ダウンロード中断期間のスキップにより、Cよりも長いことに留意されたい。EWMAのスキップはなく、ダウンロード中断期間中のレートは、最後のダウンロード間隔のものと同じであると仮定する。
MWA(移動ウィンドウ平均)に対して、H(z)=(1/D)*((1−z-D)/(1−z-1))であり、ここでDはウィンドウサイズである。Xi=min{Rk:k≧i}であり、ここでRkは、重みWkをもつレートのEWMAであり、W1<W2<W3<…である。EWMAについて、H(z)=((1−β)/(1−βz-1))であり、ここでβは前の平均の重みである。MWAおよびEWMAは、いくつかのケースではおおよそ均等である。
適合型エスティメータは、より長い平均化ウィンドウを有する場合、ライブストリーミング用にほぼ同じ平均レートを維持したまま、レート切替え頻度を削減する。異なる設定が、異なるシナリオについてうまく機能する。アグレッシブ設定は、より安定したシナリオに対してうまく機能し、あまりアグレッシブでない設定は、より変動しやすいシナリオにより適している。帯域幅が、かなりの時間部分(たとえば、20秒間の平均がレートキャップよりも高い時間の%)に対して、特定のマージンだけ、最も高いリプレゼンテーションレートよりも高い場合、よりアグレッシブ設定で進めることが有益である。理想的には、デバイスは、シナリオタイプを検出し、適切な設定を適用することができるべきである。シナリオ検出は、無線技術タイプ、特定の単位時間内のレート変化の回数、移動速度などのような要因に基づき得る。より単純な戦略は、上記観察に基づき、すなわち、「全体的」帯域幅がレートキャップよりも高いとき、よりアグレッシブ設定を使用することができる。
8. レート選択パラメータの設定
このセクションでは、レート選択パラメータを設定する例が挙げられる。
このセクションでは、レート選択パラメータを設定する例が挙げられる。
MLBについて、EFF=1−Rv/Rdlであり、ここでRvは、選択されたリプレゼンテーションの現在のレートであり、Rdlは現在のダウンロードレートである。提案されるルールは、次の通りである。
EFF<0の場合、おそらく2つ以上のレートだけ下がる
0≦EFF<0.1の場合、1レート下がる
0.1≦EFF<0.6の場合、現在のレートに留まる
0.6≦EFF<0.8の場合、1レート上がる
0.8≦EFF≦1の場合、おそらく2つ以上のレートだけ上がる
アルファ=Rv/Rdlとする。するとこれは、おおよそ次のようになる。
アルファ≦0.4の場合、少なくとも1つのレートだけ上がる
0.4<アルファ≦0.9の場合、同じレートに留まる
0.9<アルファの場合、少なくとも1レートだけ下がる
これを、DASHクライアントレート選択プロセスのコンテキストに当てはめる。
EFF<0の場合、おそらく2つ以上のレートだけ下がる
0≦EFF<0.1の場合、1レート下がる
0.1≦EFF<0.6の場合、現在のレートに留まる
0.6≦EFF<0.8の場合、1レート上がる
0.8≦EFF≦1の場合、おそらく2つ以上のレートだけ上がる
アルファ=Rv/Rdlとする。するとこれは、おおよそ次のようになる。
アルファ≦0.4の場合、少なくとも1つのレートだけ上がる
0.4<アルファ≦0.9の場合、同じレートに留まる
0.9<アルファの場合、少なくとも1レートだけ下がる
これを、DASHクライアントレート選択プロセスのコンテキストに当てはめる。
RUPを、UPに対応するリプレゼンテーションのレートとし、RDOWNを、DOWNに対応するリプレゼンテーションのレートとし、上記のように、Rvを、現在選ばれているリプレゼンテーションのレートとする。RUPは、RUP≦ラムダ(t)*Rdlとなるように可能な限り大きくなるように選ばれ、そのRDOWNが、RDOWN≦ミュー(t)*Rdlとなるように可能な限り大きくなるように選ばれる。パラメータt=B/(D+デルタ)であり、ここでBは、メディアバッファにおける現在のプレゼンテーション時間量であり、Dは、現在の決定が行われている時点を超える、次の可能切替え点までの時間に対する限度であり、デルタは、ネットワーク待ち時間とラウンドトリップ時間とを考慮に入れる小さいパラメータであり、たとえば、デルタは、近似として1秒または2秒に設定されてもよく、デルタは、現在のRTTに対する測定された上限に従って設定されてもよい。
次のレートRNEXTの全体的選択は、次のようになる。
RUP<Rvの場合、RNEXT=min{Rv,RDOWN}であり、そうでない場合、RNEXT=RUPである。
上記MLBパラメータは、すべてのtについてラムダ(t)=0.4*Rおよびミュー(t)=0.9と設定することによって概算することができ、ここでRは、次に高いリプレゼンテーションのレートと、現在のリプレゼンテーションのレートのものとの比である。たとえば、現在のレートが500Kbpsであり、次に高いレートが750Kbpsである場合、R=1.5となり、したがってラムダ(t)=0.6となる。これは、MLBプロセスを次のように近似する。
決定点において、EFF≧0.6、すなわち、アルファ≦0.4の場合、Rv≦0.4*Rdlであり、この場合、(すべてのtについてラムダ(t)=0.4*Rであるので)RUPは少なくともRv*Rとなり、したがってRNEXT=RUPとなり、すなわち、レートはレートRv*Rにおいて次に高いリプレゼンテーションまで上がってよく、Rdlが0.4*Rvよりもはるかに大きい場合、RUPは、(リプレゼンテーションレートの粒度に依存して)Rv*Rよりも大きくなり、RUPは、EFFがたとえば0.8よりも大きい場合、Rv*Rを1レート分超えることになる。EFF<0.1の場合、Rv>0.9*Rdlであり、この場合、RDOWNは、Rv未満になり(RDOWN≦0.9*Rdlなので)、レートは下がり、すなわち、RNEXT<Rvになる。EFFが0.1と0.6との間の場合、RUP≦Rv*RおよびRDOWN≧Rvになり、この場合、RNEXTは、Rvと等しくなるように選ばれる。
9. レート選択パラメータセット
以下のテーブルは、いくつかの可能なレート選択パラメータセットを指定する。
以下のテーブルに示されていないtの中間値についてのラムダおよびミューの値は、周辺値の間を線形補間することによって算出されるべきである。以下のテーブルに示すものを超えるtの値についてのラムダおよびミューの値は、示されているtの最大値についてのラムダおよびミュー値に設定されるべきである。
以下のテーブルは、いくつかの可能なレート選択パラメータセットを指定する。
以下のテーブルに示されていないtの中間値についてのラムダおよびミューの値は、周辺値の間を線形補間することによって算出されるべきである。以下のテーブルに示すものを超えるtの値についてのラムダおよびミューの値は、示されているtの最大値についてのラムダおよびミュー値に設定されるべきである。
ミュー(t)≦tおよびラムダ(t)≦tという制約がすべてのtについて満たされる場合、理論的には、プレイバックにおける失速はないが、現実的な点からは、まったく失速しないがはるかに削減されたレートでプレイアウトし続けるよりもむしろ、プレイバックにおいて小さい失速を有することが好ましい場合があり、たとえば、1Mbpsから20Kbpsに急変するのは、その間に1秒間の休止があって1Mbpsから250Kbpsに急変するよりも悪い経験であり得る。ラムダおよびミューの最小値は、図36のテーブルにおいて設定され、ミュー(t)>tおよび/またはラムダ(t)>tの値について、失速が起こる見込みが高いことを注記しておく(ただし、失速は、ラムダ(t)およびミュー(t)の設定によらず、バッファが空であるときは、いずれの場合にも起こり得る)。
ここまで説明してきたように、クライアントデバイスは、HTTPを介した適合型ビデオストリーミングのためのレート適合プロセスとダウンロードプロセスとを提供することができる。インターネット(および他のネットワーク)を介してビデオをストリーミングするクライアントは、変動帯域幅の問題に直面する。高品質ビデオがストリーミングされる場合、リンクが十分に高速でないときがあり、プレーヤに割り込ませ、再バッファリングさせる。他のケースでは、低品質ビデオは、はるかに少ない帯域幅を使用するが、より劣ったユーザエクスペリエンスとなる。1つの解決策は、ビデオ品質を適応的に調整することであり、すなわち、スループットが高いときは、より良好な品質を選び、自動的に下方切替えすることである。
ただし、適応ビデオストリーミングは、いくつかの課題を提起する。すなわち、(1)ビデオレート(品質)を選ぶためのプロセスまたはアルゴリズムは、レート下落ならびにレート増大に適応するように、十分に素早く作用するべきである。同時に、早まった、または一貫性のない決定を避け、不必要なレート切替え決定を避けるべきである。クライアントは、高ビデオ品質が達成され得るように、十分に高いレートでデータをフェッチすることを目指すべきである。同時に、ダウンロードプロセスは、データが適時に受信されることを確実にすべきである。各フレームは、プレイアウトされる前に全体が受信されるべきである。これらの目標を、不必要に大きいプレイバックバッファを必要とせずに達成することができるべきである。大きいバッファのいくつかの問題は、ライブイベントの場合、バッファ中のビデオの量が、目標エンドツーエンド遅延によって制限され、これらのケースにおける可能プレイバックバッファを厳しく制限することである。また、大きいバッファへの依存は、バッファが、事前充満される必要があるので、プレイバック開始またはシーク時に望ましくない遅延を引き起こし得る。また、大きいプレイバックバッファは、たくさんのメモリを使い、モバイル電話および他のクライアントデバイスではメモリが乏しい場合がある。
これらの問題を解決するために、受信レート変化に素早く反応するレート推定のためのプロセス。レート推定は、ビデオをストリーミングする際の使用のために特別に調整された、適応ウィンドウ化平均(adaptive windowed average)であることができる。
レートエスティメータは、ウィンドウイング幅(およびしたがって測定値分散)を大きく保ちながら、必要な場合にレートが十分高速に調整することを保証するような形で、ビデオバッファレベルと、ビデオバッファレベルの変化とを考慮に入れる。プロセスによって与えられる保証は、(a)Bが、レート下落が起きたときのバッファ中のビデオデータの量(プレイバック時間の秒数)である場合、エスティメータが、バッファがB/2までドレインするのにかかる時間内にそのレート推定値を調整してしまうこと、および(b)Bが、レート増大が起こっている間のバッファ中のデータの量である場合、レートエスティメータが、原則として多くとも3*Bの時間内に見られ得るように、新規レートに十分に迅速に調整する(スマートなレート変更プロセスを仮定する)ことである。
レートエスティメータは、ウィンドウイング幅(およびしたがって測定値分散)を大きく保ちながら、必要な場合にレートが十分高速に調整することを保証するような形で、ビデオバッファレベルと、ビデオバッファレベルの変化とを考慮に入れる。プロセスによって与えられる保証は、(a)Bが、レート下落が起きたときのバッファ中のビデオデータの量(プレイバック時間の秒数)である場合、エスティメータが、バッファがB/2までドレインするのにかかる時間内にそのレート推定値を調整してしまうこと、および(b)Bが、レート増大が起こっている間のバッファ中のデータの量である場合、レートエスティメータが、原則として多くとも3*Bの時間内に見られ得るように、新規レートに十分に迅速に調整する(スマートなレート変更プロセスを仮定する)ことである。
レート決定プロセスは、(a)バッファが低レベルにあるときにバッファが満たされ、(b)小さいダウンロードレート推定値が観測される場合であっても、不規則に変化するレートを回避するためにバッファを使用し、(c)安定レートシナリオでは、正しい安定レートを素早く選ぶように、レート決定を行うことができる。(a)正確なレート推定を可能にし、(b)ネットワーク遅延およびパケット損失レートが高い場合であってもリンク容量を達成することが可能であり、(c)ストリームの適時配信を達成する、HTTPのためのマルチメディアダウンロード戦略が使用される。これを達成するために、マルチプルなHTTP接続を使用し、ネットワーク条件に依存して、メディア要求をより小さいチャンク要求に分解し、TCPフロー制御メカニズムを使用して接続を同期させ、データをバースト的に要求することができる。また、接続をビジーに保つために、HTTPパイプライニングプロセスを使用することもできる。
いくつかの特徴、態様および詳細について、今まで説明してきた。説明したように、様々な実施形態において、方法ステップは、対応するプログラムされた要素、プロセッサに与えられる命令、ハードウェアまたは当業者には明らかであろう他の装置によって実施することができる。同様に、要素は、プロセスまたはプログラム要素によって有効にすることができる。実施形態の要素の構造は、プロセッサによって実行されるが、本明細書では対応する方法ステップとして記述される命令セットを単に備え得る。
様々な実施形態において、ダウンロードレート加速は、使われても使われなくてもよい。ダウンロードレート加速の例は、TCP接続を介したHTTP要求を使用することによってダウンロードを加速する方法または装置である。TCP接続は、特定のウィンドウサイズを有し、TCP接続の端部にあるノードは、ウィンドウサイズについての設定を変えることができる。1つの新規性は、連続するHTTP要求用にウィンドウサイズを設定することであり、ここでサイズは、目標ダウンロードレートの関数である。したがって、目標ダウンロードレートが変わると、TCPウィンドウサイズが変わり得る。
一実施形態では、ネットワーク経路によって結合されたソースと受信機との間のネットワーク経路を介したデータダウンロードを制御するための方法および/または装置もしくはコンピュータ可読媒体が使われ、この方法は、ソースと受信機との間の複数のTCP接続の各々について、そのTCP接続用のTCP受信機ウィンドウサイズを決定することであって、ソースと受信機との間のTCP接続が直接接続または間接接続であることができる、決定することと、メディアコンテンツ用の目標ダウンロードレートを決定することであって、目標ダウンロードレートが、少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、決定することと、複数のTCP接続の各TCP接続を使用して、ダウンロードされるべきメディアコンテンツの複数のメディアデータ要素をダウンロードすることとを備え、メディアコンテンツが、複数のHTTP要求への応答の一部分または全部であり、所与のTCP接続用の決定されたTCP受信機ウィンドウサイズは、目標ダウンロードレートに少なくとも部分的に基づいて決定され、決定されたTCP受信機ウィンドウサイズは、少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる。
現在のTCP接続のための決定されたTCP受信機ウィンドウサイズは、乗数レートで乗算された、現在のTCP接続についての現在の推定ラウンドトリップ時間(「ERTT」)の積に少なくとも部分的に基づいて決定されることができ、乗数レートは、現在のTCP接続用の目標ダウンロードレートと、目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である。現在のERTTは、たとえば1秒、10秒、50秒など、直前の測定期間にわたる最小の観測されたRTTの測度によって決定されることができる。現在のERTTは、休止期間の終了における測度によって決定されることができ、休止期間は、ダウンロード期間に続く、TCP接続にわたるアクティブHTTP要求が所定の継続時間期間だけ存在していない期間である。目標ダウンロードレートは、使用されるすべてのTCP接続にわたる現在の総ダウンロードレートを、使用されるTCP接続の数で除算したものに比例し、たとえば現在の総ダウンロードレートの2倍または3倍になり得る。目標ダウンロードレートは、メディアコンテンツのプレイバックレートに比例し得、プレイバックレートは、使用されるすべてのTCP接続に及ぶ総計にわたるレートを、使用されるTCP接続の数で除算したものである。各メディアデータ要素は、所定の分散範囲内のサイズを有するいくつかのチャンクに分割され、そのようなチャンクの数は、使用されるTCP接続の数に基づく。そのようなチャンクの数は、現在のTCP接続についての現在の推定ラウンドトリップ時間(「ERTT」)、現在のダウンロードレート、および/または要求されるメディアフラグメントのサイズのうち少なくとも1つにさらに基づき得る。所定の分散範囲はゼロであってよく、したがって各チャンクは、フラグメント要求ごとに同じサイズを有し、チャンクの数は、使用されるTCP接続の数に、所定の因子を乗じたものに等しい。各チャンクは、最小バイト数以上のサイズを有し得る。後続メディアデータ要素についての後のHTTP要求が、第1の利用可能TCP接続に割り当てられ得る。
制御することはまた、ソースと受信機との間で使用するべきいくつかのTCP接続を決定することであって、その数が1よりも大きく、使用するべきTCP接続の数が、少なくとも部分的に、決定された少なくとも1つのネットワーク条件に基づいて決定される、決定することと、いくつかのTCP接続の各々を使用して、ダウンロードされるべきメディアコンテンツの複数のメディアデータ要素をダウンロードすることとを含み、メディアコンテンツは、複数のHTTP要求への応答の一部分または全部である。使用されるTCP接続の数は、TCP接続についての推定ラウンドトリップ時間(「ERTT」)、目標ダウンロードレート、および損失レートの推定値に基づき得る。損失レートは、1%または0.1%であると推定され得る。使用するべきTCP接続の数は、両端値を含む2と16の間であり、および/または(a)目標ダウンロードレート、(b)ERTT、および(c)推定損失レートの平方根の積に比例し得る。TCP接続の各々について、TCP受信機ウィンドウサイズは、そのTCP接続用に、目標ダウンロードレートに基づいて決定することができ、決定されたTCP受信機ウィンドウサイズは、少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる。
一実施形態では、プレゼンテーションバッファに注目し、バッファがどの程度大きいか/満杯であるか/空であるか、すなわち、バッファのレベルがどこにあるかに基づいて、ダウンロードレートの推定を行うダウンロードレートを推定するための方法および/または装置もしくはコンピュータ可読媒体が使用される。たとえば、有限帯域幅を有するネットワーク経路によってデータソースに結合された受信機においてダウンロードレートを推定することであって、ダウンロードレートが、受信機においてネットワーク経路を介してデータが受信され得るレートであることは、受信機のプレゼンテーションバッファを監視することであって、プレゼンテーションバッファが、少なくともメディアデータが受信される時間と、受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間メディアデータを記憶する、監視することと、ダウンロードレートの推定値がそれに基づくべき非ゼロ推定期間を決定することと、推定期間にわたるバッファレベルのインジケーションを記憶することであって、所与の時間におけるバッファレベルが、プレゼンテーションバッファのうちどの程度が、少なくとも近似的に、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによってその時間に占有されるかに対応する、決定することと、記憶されたインジケーションを、推定ダウンロードレートの測度の一部として使用することとを備え得る。
プレゼンテーション要素は、ディスプレイとオーディオ出力とを備えることができる。推定期間は、所定の比例因子による、測定されたバッファレベルに比例する持続期間を有し得る。推定期間の持続期間は、測定時間におけるプレゼンテーションバッファ中の未消費のメディアデータのバイト数に比例し、および/またはプレゼンテーションバッファにメディアが追加される追加レートの関数であり、および/またはプレゼンテーションバッファの所定の部分をダウンロードするのに使用される時間に比例するようにとられ得る。所定の持続時間は、プレゼンテーションバッファのコンテンツの所定の比率がダウンロードされた持続時間に対応して得る。推定期間は、プレゼンテーションバッファのコンテンツの所定の比率がダウンロードされた時間、およびメディアデータがプレゼンテーションバッファ中に存在するプレゼンテーション時間のうち、より短い方であることができる。
一実施形態では、プレイバックレート選択のための方法および/または装置もしくはコンピュータ可読媒体が使用され、プレイバックレートは、メガビット/秒などのメモリ単位/時間で測定される、プレゼンテーションバッファからメディアが消費されるレートである。受信機が、いくつかのメディアについての要求を行うとき、そのメディアのためのプレイバックレートがある。おそらく常にではないがしばしば、より高品質のメディアが、より高いプレイバックレートを有し、したがってトレードオフを提示する。どのプレイバックレートを使用/要求するべきかは、少なくとも時には、どれだけ多くのメディアがプレゼンテーションバッファにあるかに応じて決まる。受信機は、受信機のプレゼンテーション要素を使用してプレイアウトするためのメディアを受信することもでき、ここで、プレイアウトの結果、メディアがプレゼンテーションバッファからあるプレイバックレートで消費されることになり、受信機は、複数のプレイバックレートから選択を行うように構成され、プレゼンテーションバッファを監視することであって、プレゼンテーションバッファは、少なくともメディアデータが受信される時間と受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間メディアデータを記憶する、監視することと、バッファレベルのインジケーションを記憶することであって、バッファレベルは、プレゼンテーションバッファのどの程度が、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによって占有されるかに対応する、記憶することと、推定ダウンロードレートを決定することと、目標プレイバックレートを計算するために、記憶されたインジケーションおよび推定ダウンロードレートを使用することと、目標プレイバックレートに従って複数のプレイバックレートの中から選択をすることとを備える。
選択されたプレイバックレートは、推定ダウンロードレートの所定の乗数以下であることができ、所定の乗数は、バッファレベルの増加関数である。所定の乗数は、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間のアフィン一次関数であることができ、所定の乗数は、プレゼンテーションバッファのバッファレベルがしきい量未満であるときには、1未満であることができる。所定の乗数は、プレゼンテーションバッファ中のメディアデータのプレゼンテーション持続時間が、あらかじめ設定された最大量のプレゼンテーション時間以上であるときには、1以上であることができる。所定の乗数は、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間の区分的一次関数であることができる。選択されたプレイバックレートは、推定ダウンロードレートの所定の乗数、およびプレゼンテーションバッファ中のメディアデータのバイト数の増加関数の所定の乗数以下であり得る。プレイバックレートは、比例因子にダウンロードレート推定値を乗じたもの以下である複数のプレイバックレートのうち最も大きい利用可能プレイバックレートとなるように選択されればよく、比例因子は、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間を、レート変化に対する反応時間の推定値で除算したものの増加関数である。反応時間は、メディアデータ中の切替え点の間のプレゼンテーション時間に対する上限であり得、および/または反応時間の推定値は、メディアデータ中の切替え点の間のプレゼンテーション時間に関する平均であり得る。
反応時間の推定値は、所定の定数に推定ラウンドトリップ時間(「ERTT」)を乗じたもの以上であり得る。
反応時間の推定値は、所定の定数に推定ラウンドトリップ時間(「ERTT」)を乗じたもの以上であり得る。
受信機のプレゼンテーション要素を使用してプレイアウトするためのメディアを受信する受信機であって、プレイアウトの結果、メディアがプレゼンテーションバッファからプレイバックレートで消費され、受信機は、複数のプレイバックレートから選択するように構成され、プレゼンテーションバッファを監視することであって、プレゼンテーションバッファは、少なくともメディアデータが受信される時間と、受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間のメディアデータを記憶する、監視することと、バッファレベルのインジケーションを記憶することであって、バッファレベルが、プレゼンテーションバッファのうちどの程度が、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによって占有されるかに対応する、記憶することと、バッファレベルの許容分散を決定することと、記憶されたバッファレベルインジケーションとバッファレベルの許容分散とを使用して、目標プレイバックレートを計算することと、目標プレイバックレートに従って複数のプレイバックレートの中から選択することと、を行うための方法または装置を備え得る。
プレイバックレートは、上位比例因子(upper proportional factor)、下位比例因子(lower proportional factor)、ダウンロードレート推定値、現在のプレイバックレート、バッファレベル、およびレート変化に対する反応時間の推定値に基づいて選択することができる。上位比例因子および下位比例因子は両方とも、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間を、レート変化に対する反応時間の推定値で除算したものの増加関数および/または区分的一次関数であることができ、上位比例因子は、下位比例因子よりも大きいものまたは下位比例因子に等しいものである。プレイバックレートは、前のプレイバックレートが、下位比例因子に推定ダウンロードレートを乗じたものと、上位比例因子にダウンロードレート推定値を乗じたものとの間にあるときには、前のプレイバックレートと同じになるように選択されることができる。プレイバックレートは、前のプレイバックレートが、上位比例因子にダウンロードレート推定値を乗じたものを上回るときには、上位比例因子に推定ダウンロードレートを乗じたもの以下の最も大きい利用可能プレイバックレートになるように選択されることができる。プレイバックレートは、前のプレイバックレートが、下位比例因子にダウンロードレート推定値を乗じたものを下回るときには、下位比例因子に推定ダウンロードレートを乗じたもの以下の最も大きい利用可能プレイバックレートになるように選択されることができる。
一実施形態では、要求を行うためであるが、プロセス要求において取り消すかどうか決定するためでもある方法および/または装置もしくはコンピュータ可読媒体が使用される。受信機は、メディアのセグメント/部分/フラグメントについての要求を行い、要求に対する応答を受信し、応答からのメディアを記憶し、可能性として別の要求を行うとき、要求を取り消し、異なる要求を発行すること好ましいと決定してよい。メディアのプレイバックレートは、最もアグレッシブであるとともに、プレゼンテーションバッファ中のメディアを、消費されるときに使い果たすことなく取得することを期待する最も高いプレイバックレートを選択する受信機によって決定することもできる。ダウンロードレートが予期せぬほど下がった場合、受信機は、その現在の要求を取り消し、より低いプレイバックレートメディアについての新規要求を行うか、それとも現在の要求をプレイアウトさせるか決定する。高プレイバックレート要求を取り消し、より低いプレイバックレート要求で置き換えると、プレゼンテーションバッファのコンテンツがより長く続くことになる場合があるが、要求ミッドストリームを取り消すと、その要求についてのどの部分的に受信されたメディアの損失も引き起こす場合がある。
そのような一実施形態において、受信機は、受信機のプレゼンテーション要素を使用してプレイアウトするためのメディアを受信し、プレイアウトの結果、メディアは、プレゼンテーションバッファから一定のプレイバックレートで消費され、受信機は、複数のプレイバックレートから選択をするように構成される。要求アクションを決定することは、プレゼンテーションバッファを監視することであって、プレゼンテーションバッファが、少なくともメディアデータが受信される時間と、受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間、メディアデータを記憶する、監視することと、バッファレベルのインジケーションを記憶することであって、バッファレベルが、プレゼンテーションバッファのうちどの程度が、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによって占有されるかに対応する、記憶することと、選択された第1のメディアデータチャンクをダウンロードするために、および発行された要求が未処理のときに、発行された要求の状態を維持することと、ネットワーク条件および発行された要求の状態に基づいて、要求を続けるか、それとも要求を取り消すかを決定することとを備える。
要求を続けるか、それとも要求を取り消すかを決定することは、第1のメディアデータがプレイアウトされる前に、要求についてのダウンロードを完了するのに十分な時間があるかどうか決定することと、十分な時間がない場合、要求を取り消すこととを備えることができる。要求を続けるか、それとも要求を取り消すかを決定することは、選択された第1のチャンクまたは選択された第2のチャンクのいずれかがプレイアウトされることになる前に、より高レートの第2のチャンクをダウンロードするのに十分な時間があるかどうか決定することと、十分な時間がある場合、要求を取り消し、第2のチャンクについての要求を発行することとをさらに備えることができる。要求を続けるか、それとも要求を取り消すかを決定することは、ダウンロードレートおよびメディア消費レートに基づいて、失速が起こることを検出することと、プレゼンテーション要素が、消費されるメディアによって指示されたレートでメディアデータを消費することができない時間と、プレゼンテーション要素が、消費されるメディアによって指示されたレートでメディアデータの消費を再開することができる時間との間の失速期間を推定することと、継続または取消しが失速期間に対して与える効果を決定することと、要求の取消しが失速期間を短縮することになる場合、要求を取り消すこととをさらに備えることができる。
他の特徴は、第2のメディアデータチャンクを選択することであって、第2のメディアデータチャンクが、開始プレゼンテーション時間を有し、その開始プレゼンテーション時間が、第1のメディアデータチャンクと同じ開始プレゼンテーション時間である、選択することと、第2のメディアデータチャンクのダウンロードを要求することと、第2のメディアデータチャンクを選択することであって、第2のメディアデータチャンクが、開始プレゼンテーション時間を有し、その開始プレゼンテーション時間が、第1のメディアデータチャンクの開始プレゼンテーション時間よりも後である、選択することと、第2のメディアデータチャンクのダウンロードを要求することとを含んでもよい。第2のメディアデータチャンクは、受信機にとって利用可能な第1のチャンクの開始プレゼンテーション時間のものと比較した、その開始プレゼンテーション時間が、最も低い差となるように、および/またはそのプレイバックが、その開始プレゼンテーション時間と第1のメディアデータチャンクの開始プレゼンテーション時間との間の所定の最大ギャップをもつ最大プレイバックレートとなるように、受信機によって選ぶこともできる。
いくつかの実施形態は、第1のメディアデータチャンクのうち残っている部分のダウンロードが、プレイバック用の時間内に完了できないかどうか決定することと、第2のメディアデータチャンクのダウンロードが、プレイバック用の時間内に完了され得るかどうか決定することと、要求を続けるか、それとも第1のメディアデータチャンクについての要求を取り消し、代わりに第2のメディアデータチャンクを要求するかの決定を、第1のメディアデータチャンクのうち残っている部分のダウンロードが、プレイバック用の時間内に完了できないかどうか、および第2のメディアデータチャンクのダウンロードが、プレイバック用の時間内に完了され得るかどうかに基づかせることとを含み得る。第2のデータチャンク中のメディアデータのプレイバックレートは、受信機においてサポートされる最も高いプレイバックレートとなるように選ばれることができる。受信機は、すでにプレゼンテーションバッファ中にある少なくともいくらかのメディアデータのプレゼンテーション時間をカバーするメディアデータを要求し、要求されたメディアデータをダウンロードし、要求されたメディアデータをプレイアウトし、すでにプレゼンテーションバッファ中にある対応するメディアデータのうち少なくともいくつかを破棄してもよい。要求されたメディアデータのプレイバックレートは、プレゼンテーションバッファから破棄される対応するメディアデータの最大プレゼンテーション持続時間に対する制約を受ける、最大のプレイバックレートであり得る。要求されるメディアデータは、その開始プレゼンテーション時間が、受信機にとって利用可能な最も早い開始プレゼンテーション時間になるように選ばれ得る。
いくつかの受信機において、ダウンロードは、バッファレベルに依存し、受信機は、高ウォーターマークおよび低ウォーターマークの概念を使用する。そのような受信機において、メディアデータは、ソースからダウンロードされ、受信機のプレゼンテーションバッファに記憶される。プレゼンテーションバッファの充満レベル(または単に「レベル」)が決定され、ここで充満レベルは、プレゼンテーションバッファのどのような部分が、プレゼンテーション要素によってまだ消費されていないメディアデータを含むかを表す。充満レベルが高充満しきい値(「高ウォーターマーク」)を上回る場合、ダウンロードは停止し、充満レベルが低充満しきい値(「低いウォーターマーク」)を下回る場合、ダウンロードはリスタートする。充満レベルは、プレゼンテーション要素によってメディアデータが消費されると、アップデートされ得る。充満レベルは、メモリ記憶容量の単位および/またはプレゼンテーション時間の単位で測ることができる。ダウンロードは、推定ラウンドトリップ時間(「ERTT」)に基づくことができ、ERTTは、メディアデータダウンロードがリスタートされるとリセットされる。ダウンロードが複数のTCP接続を介して起きた場合、メディアデータダウンロードがリスタートされると、使用されるいくつかのTCP接続はリセットされ得る。高充満しきい値および低充満しきい値は、時間とともに変化しうる。
本開示を読んだ後には、当業者にはさらなる実施形態が想起され得る。他の実施形態では、上で開示された発明の組合せまたは副次的な組合せが、有利に行われ得る。コンポーネントの例示的な構成は例示を目的に示され、組合せ、追加、再構成などが、本発明の代替的な実施形態において考えられることを理解されたい。したがって、本発明は、例示的な実施形態に関して説明されてきたが、多数の修正が可能であることを当業者は認識するだろう。
たとえば、本明細書で説明される処理は、ハードウェアコンポーネント、ソフトウェアコンポーネント、および/またはこれらの任意の組合せを使用して実施され得る。
したがって、本明細書および図面は、限定的な意味ではなく例示的であると解釈されるべきである。しかしながら、特許請求の範囲において述べられるような本発明のより広い趣旨および範囲から逸脱することなく、様々な修正および変更を行うことができ、本発明は、以下の特許請求の範囲内にあるすべての修正と等価物とを包含することが意図されることは、明らかである。
以下に、出願当初の特許請求の範囲に記載された発明を付記する。
[C1]
ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御する方法であって、
前記ソースからメディアデータをダウンロードすることと、
前記メディアデータを前記受信機のプレゼンテーションバッファに記憶することと、
前記プレゼンテーションバッファの充満レベルを監視することであって、前記充満レベルは、前記プレゼンテーションバッファのどのような部分が、プレゼンテーション要素によってまだ消費されていないメディアデータを含むかを表す、監視することと、
前記充満レベルが高充満しきい値を上回る場合、前記ダウンロードを停止することと、
前記充満レベルが低充満しきい値を下回る場合、前記ダウンロードをリスタートすることと、
前記プレゼンテーション要素によってメディアデータが消費されると、前記充満レベルをアップデートすることとを備える方法。
[C2]
前記充満レベルが、メモリ記憶容量の単位で測定される、上記C1に記載の方法。
[C3]
前記充満レベルが、プレゼンテーション時間の単位で測定される、上記C1に記載の方法。
[C4]
ダウンロードが推定ラウンドトリップ時間(「ERTT」)に基づき、前記メディアデータダウンロードがリスタートされるときに前記ERTTがリセットされる、上記C1に記載の方法。
[C5]
複数のTCP接続を介してダウンロードが起こり、前記メディアデータダウンロードがリスタートされるときに使用中のいくつかのTCP接続がリセットされる、上記C1に記載の方法。
[C6]
前記高充満しきい値および前記低充満しきい値が時間とともに変わる、上記C1に記載の方法。
[C7]
ソースと受信機との間のネットワーク経路を介してデータをダウンロードする受信機であって、
前記ソースからダウンロードされる、ダウンロードされたメディアデータを記憶するプレゼンテーションバッファと、
前記プレゼンテーションバッファの充満レベルのためのストレージであって、前記充満レベルが、前記プレゼンテーションバッファのどのような部分が、プレゼンテーション要素によってまだ消費されていないメディアデータを含むかを表すストレージと、
ダウンロード要求を送るためのインターフェースであって、前記充満レベルが高充満しきい値を上回る場合、要求が送られず、前記充満レベルが低充満しきい値を下回る場合、要求が送られ、前記プレゼンテーション要素によってメディアデータが消費されると、前記充満レベルがアップデートされるインターフェースとを備える受信機。
[C8]
前記充満レベルが、メモリ記憶容量の単位で測定される、上記C7に記載の受信機。
[C9]
前記充満レベルが、プレゼンテーション時間の単位で測定される、上記C7に記載の受信機。
[C10]
ダウンロードが推定ラウンドトリップ時間(「ERTT」)に基づき、前記メディアデータダウンロードがリスタートされるときに前記ERTTがリセットされる、上記C7に記載の受信機。
[C11]
複数のTCP接続を介してダウンロードが起こる、上記C7に記載の受信機。
[C12]
前記高充満しきい値および前記低充満しきい値が時間とともに変わる、上記C7に記載の受信機。
[C13]
ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御するための、受信機のプロセッサによって実行するための非一時的コンピュータ可読媒体であって、
前記ソースからメディアデータをダウンロードするためのプログラムコードと、
前記メディアデータを、前記受信機のプレゼンテーションバッファに記憶するためのプログラムコードと、
前記プレゼンテーションバッファの充満レベルを監視するためのプログラムコードであって、前記充満レベルが、前記プレゼンテーションバッファのどのような部分が、プレゼンテーション要素によってまだ消費されていないメディアデータを含むかを表す、プログラムコードと、
前記充満レベルが高充満しきい値を上回る場合、前記ダウンロードを停止するためのプログラムコードと、
前記充満レベルが低充満しきい値を下回る場合、前記ダウンロードをリスタートするためのプログラムコードと、
前記プレゼンテーション要素によってメディアデータが消費されると、前記充満レベルをアップデートするためのプログラムコードと、を備えるプログラムコードを有する、非一時的コンピュータ可読媒体。
[C14]
前記充満レベルがメモリ記憶容量の単位、および/またはプレゼンテーション時間の単位で測定される、上記C13に記載の非一時的コンピュータ可読媒体。
[C15]
推定ラウンドトリップ時間(「ERTT」)に基づいてダウンロードするためのプログラムコードをさらに備え、前記メディアデータダウンロードがリスタートされるときに前記ERTTがリセットされる、上記C13に記載の非一時的コンピュータ可読媒体。
[C16]
複数のTCP接続を介してダウンロードするためのプログラムコードと、前記メディアデータダウンロードがリスタートされるときに、使用中のいくつかのTCP接続をリセットするためのプログラムコードとをさらに備える、上記C13に記載の非一時的コンピュータ可読媒体。
[C17]
前記高充満しきい値および前記低充満しきい値が時間とともに変わる、上記C13に記載の非一時的コンピュータ可読媒体。
したがって、本明細書および図面は、限定的な意味ではなく例示的であると解釈されるべきである。しかしながら、特許請求の範囲において述べられるような本発明のより広い趣旨および範囲から逸脱することなく、様々な修正および変更を行うことができ、本発明は、以下の特許請求の範囲内にあるすべての修正と等価物とを包含することが意図されることは、明らかである。
以下に、出願当初の特許請求の範囲に記載された発明を付記する。
[C1]
ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御する方法であって、
前記ソースからメディアデータをダウンロードすることと、
前記メディアデータを前記受信機のプレゼンテーションバッファに記憶することと、
前記プレゼンテーションバッファの充満レベルを監視することであって、前記充満レベルは、前記プレゼンテーションバッファのどのような部分が、プレゼンテーション要素によってまだ消費されていないメディアデータを含むかを表す、監視することと、
前記充満レベルが高充満しきい値を上回る場合、前記ダウンロードを停止することと、
前記充満レベルが低充満しきい値を下回る場合、前記ダウンロードをリスタートすることと、
前記プレゼンテーション要素によってメディアデータが消費されると、前記充満レベルをアップデートすることとを備える方法。
[C2]
前記充満レベルが、メモリ記憶容量の単位で測定される、上記C1に記載の方法。
[C3]
前記充満レベルが、プレゼンテーション時間の単位で測定される、上記C1に記載の方法。
[C4]
ダウンロードが推定ラウンドトリップ時間(「ERTT」)に基づき、前記メディアデータダウンロードがリスタートされるときに前記ERTTがリセットされる、上記C1に記載の方法。
[C5]
複数のTCP接続を介してダウンロードが起こり、前記メディアデータダウンロードがリスタートされるときに使用中のいくつかのTCP接続がリセットされる、上記C1に記載の方法。
[C6]
前記高充満しきい値および前記低充満しきい値が時間とともに変わる、上記C1に記載の方法。
[C7]
ソースと受信機との間のネットワーク経路を介してデータをダウンロードする受信機であって、
前記ソースからダウンロードされる、ダウンロードされたメディアデータを記憶するプレゼンテーションバッファと、
前記プレゼンテーションバッファの充満レベルのためのストレージであって、前記充満レベルが、前記プレゼンテーションバッファのどのような部分が、プレゼンテーション要素によってまだ消費されていないメディアデータを含むかを表すストレージと、
ダウンロード要求を送るためのインターフェースであって、前記充満レベルが高充満しきい値を上回る場合、要求が送られず、前記充満レベルが低充満しきい値を下回る場合、要求が送られ、前記プレゼンテーション要素によってメディアデータが消費されると、前記充満レベルがアップデートされるインターフェースとを備える受信機。
[C8]
前記充満レベルが、メモリ記憶容量の単位で測定される、上記C7に記載の受信機。
[C9]
前記充満レベルが、プレゼンテーション時間の単位で測定される、上記C7に記載の受信機。
[C10]
ダウンロードが推定ラウンドトリップ時間(「ERTT」)に基づき、前記メディアデータダウンロードがリスタートされるときに前記ERTTがリセットされる、上記C7に記載の受信機。
[C11]
複数のTCP接続を介してダウンロードが起こる、上記C7に記載の受信機。
[C12]
前記高充満しきい値および前記低充満しきい値が時間とともに変わる、上記C7に記載の受信機。
[C13]
ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御するための、受信機のプロセッサによって実行するための非一時的コンピュータ可読媒体であって、
前記ソースからメディアデータをダウンロードするためのプログラムコードと、
前記メディアデータを、前記受信機のプレゼンテーションバッファに記憶するためのプログラムコードと、
前記プレゼンテーションバッファの充満レベルを監視するためのプログラムコードであって、前記充満レベルが、前記プレゼンテーションバッファのどのような部分が、プレゼンテーション要素によってまだ消費されていないメディアデータを含むかを表す、プログラムコードと、
前記充満レベルが高充満しきい値を上回る場合、前記ダウンロードを停止するためのプログラムコードと、
前記充満レベルが低充満しきい値を下回る場合、前記ダウンロードをリスタートするためのプログラムコードと、
前記プレゼンテーション要素によってメディアデータが消費されると、前記充満レベルをアップデートするためのプログラムコードと、を備えるプログラムコードを有する、非一時的コンピュータ可読媒体。
[C14]
前記充満レベルがメモリ記憶容量の単位、および/またはプレゼンテーション時間の単位で測定される、上記C13に記載の非一時的コンピュータ可読媒体。
[C15]
推定ラウンドトリップ時間(「ERTT」)に基づいてダウンロードするためのプログラムコードをさらに備え、前記メディアデータダウンロードがリスタートされるときに前記ERTTがリセットされる、上記C13に記載の非一時的コンピュータ可読媒体。
[C16]
複数のTCP接続を介してダウンロードするためのプログラムコードと、前記メディアデータダウンロードがリスタートされるときに、使用中のいくつかのTCP接続をリセットするためのプログラムコードとをさらに備える、上記C13に記載の非一時的コンピュータ可読媒体。
[C17]
前記高充満しきい値および前記低充満しきい値が時間とともに変わる、上記C13に記載の非一時的コンピュータ可読媒体。
Claims (11)
- ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御する方法であって、
前記ソースからメディアデータをダウンロードすることであって、ダウンロードは、帯域幅遅延積に応じて決定されたある数のTCP接続を介して起こり、前記帯域幅遅延積は、推定ラウンドトリップ時間(ERTT)と受信レートとの積を含み、前記ERTTは、前記メディアデータについての要求の送信と前記要求に対する応答の受信との間の時間の差を含み、前記受信レートは、ERTT時間の最後の整数の倍数にわたって推定された平均受信レートを含む、ダウンロードすることと、
前記メディアデータを前記受信機のプレゼンテーションバッファに記憶することと、
前記プレゼンテーションバッファの充満レベルを監視することであって、前記充満レベルは、プレゼンテーション要素によってまだ消費されていないメディアデータを含む前記プレゼンテーションバッファの一部分を表す、監視することと、
前記充満レベルが高充満しきい値を上回る場合、前記ダウンロードを停止することと、
前記充満レベルが低充満しきい値を下回る場合、前記ダウンロードをリスタートすることであって、前記ダウンロードをリスタートすることは、前記メディアデータダウンロードがリスタートされるときに使用すべきTCP接続の前記数および前記ERTTをリセットすることを含み、使用すべきTCP接続の前記数をリセットすることは、前記帯域幅遅延積に基づいて、使用すべきTCP接続の前記数を調整することを備える、リスタートすることと、
前記プレゼンテーション要素によってメディアデータが消費されると、前記充満レベルをアップデートすることと、
を備える、方法。 - 前記充満レベルが、メモリ記憶容量の単位で測定される、請求項1に記載の方法。
- 前記充満レベルが、プレゼンテーション時間の単位で測定される、請求項1に記載の方法。
- 前記高充満しきい値および前記低充満しきい値が時間とともに変わる、請求項1に記載の方法。
- ソースと受信機との間のネットワーク経路を介してデータをダウンロードする受信機であって、
前記ソースからダウンロードされる、ダウンロードされたメディアデータを記憶するように構成されたプレゼンテーションバッファであって、前記メディアデータのダウンロードは、帯域幅遅延積に応じて決定されたある数のTCP接続を介して起こり、前記帯域幅遅延積は、推定ラウンドトリップ時間(ERTT)と受信レートとの積を含み、前記ERTTは、前記メディアデータについての要求の送信と前記要求に対する応答の受信との間の時間の差を含み、前記受信レートは、ERTT時間の最後の整数の倍数にわたって推定された平均受信レートを含む、プレゼンテーションバッファと、
前記プレゼンテーションバッファの充満レベルを監視するように構成されたプレゼンテーションバッファモニタであって、前記充満レベルが、プレゼンテーション要素によってまだ消費されていないメディアデータを含む前記プレゼンテーションバッファの一部分を表す、プレゼンテーションバッファモニタと、
ダウンロード要求を送るように構成されたインターフェースであって、前記充満レベルが高充満しきい値を上回る場合、メディアデータのダウンロードを停止し、前記充満レベルが低充満しきい値を下回る場合、前記メディアデータの前記ダウンロードをリスタートし、前記ダウンロードをリスタートすることは、前記メディアデータダウンロードがリスタートされるときに使用すべきTCP接続の前記数および前記ERTTをリセットすることを含み、使用すべきTCP接続の前記数をリセットすることは、前記帯域幅遅延積に基づいて、使用すべきTCP接続の前記数を調整することを備え、前記プレゼンテーション要素によってメディアデータが消費されると、前記充満レベルがアップデートされるインターフェースと、
を備える、受信機。 - 前記充満レベルが、メモリ記憶容量の単位で測定される、請求項5に記載の受信機。
- 前記充満レベルが、プレゼンテーション時間の単位で測定される、請求項5に記載の受信機。
- 前記高充満しきい値および前記低充満しきい値が時間とともに変わる、請求項5に記載の受信機。
- その上にプログラムコードを有する、ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御するための受信機のプロセッサによって実行するための非一時的コンピュータ可読媒体であって、前記プログラムコードは、
前記ソースからメディアデータをダウンロードするためのプログラムコードであって、ダウンロードは、帯域幅遅延積に応じて決定されたある数のTCP接続を介して起こり、前記帯域幅遅延積は、推定ラウンドトリップ時間(ERTT)と受信レートとの積を含み、前記ERTTは、前記メディアデータについての要求の送信と前記要求に対する応答の受信との間の時間の差を含み、前記受信レートは、ERTT時間の最後の整数の倍数にわたって推定された平均受信レートを含む、ダウンロードするためのプログラムコードと、
前記メディアデータを前記受信機のプレゼンテーションバッファに記憶するためのプログラムコードと、
前記プレゼンテーションバッファの充満レベルを監視するためのプログラムコードであって、前記充満レベルは、プレゼンテーション要素によってまだ消費されていないメディアデータを含む前記プレゼンテーションバッファの一部分を表す、監視するためのプログラムコードと、
前記充満レベルが高充満しきい値を上回る場合、前記ダウンロードを停止するためのプログラムコードと、
前記充満レベルが低充満しきい値を下回る場合、前記ダウンロードをリスタートするためのプログラムコードであって、前記ダウンロードをリスタートすることは、前記メディアデータダウンロードがリスタートされるときに使用すべきTCP接続の前記数および前記ERTTをリセットすることを含み、使用すべきTCP接続の前記数をリセットすることは、前記帯域幅遅延積に基づいて、使用すべきTCP接続の前記数を調整することを備える、前記ダウンロードをリスタートするためのプログラムコードと、
前記プレゼンテーション要素によってメディアデータが消費されると、前記充満レベルをアップデートするためのプログラムコードと、
を備える、非一時的コンピュータ可読媒体。 - 前記充満レベルは、メモリ記憶容量の単位および/またはプレゼンテーション時間の単位で測定される、請求項9に記載の非一時的コンピュータ可読媒体。
- 前記高充満しきい値および前記低充満しきい値が時間とともに変わる、請求項9に記載の非一時的コンピュータ可読媒体。
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261603569P | 2012-02-27 | 2012-02-27 | |
US61/603,569 | 2012-02-27 | ||
US13/745,811 | 2013-01-20 | ||
US13/745,811 US9503490B2 (en) | 2012-02-27 | 2013-01-20 | Dash client and receiver with buffer water-level decision-making |
PCT/US2013/027813 WO2013130477A1 (en) | 2012-02-27 | 2013-02-26 | Improved dash client and receiver with buffer water-level decision-making |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2015513840A JP2015513840A (ja) | 2015-05-14 |
JP2015513840A5 true JP2015513840A5 (ja) | 2017-02-16 |
Family
ID=49004504
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014558950A Expired - Fee Related JP6271445B2 (ja) | 2012-02-27 | 2013-02-26 | 要求取消し機能を備えた改良されたdashクライアントおよび受信機 |
JP2014558951A Pending JP2015513840A (ja) | 2012-02-27 | 2013-02-26 | バッファ水位決定を伴う改良されたdashクライアントおよび受信機 |
JP2014558949A Expired - Fee Related JP6054427B2 (ja) | 2012-02-27 | 2013-02-26 | プレイバックレート選択を伴う改良されたdashクライアントおよび受信機 |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014558950A Expired - Fee Related JP6271445B2 (ja) | 2012-02-27 | 2013-02-26 | 要求取消し機能を備えた改良されたdashクライアントおよび受信機 |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014558949A Expired - Fee Related JP6054427B2 (ja) | 2012-02-27 | 2013-02-26 | プレイバックレート選択を伴う改良されたdashクライアントおよび受信機 |
Country Status (6)
Country | Link |
---|---|
US (3) | US9450997B2 (ja) |
EP (3) | EP2820823B1 (ja) |
JP (3) | JP6271445B2 (ja) |
KR (3) | KR20140130211A (ja) |
CN (3) | CN104205770B (ja) |
WO (3) | WO2013130475A1 (ja) |
Families Citing this family (108)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP5200204B2 (ja) | 2006-03-14 | 2013-06-05 | ディブエックス リミテッド ライアビリティー カンパニー | 高信頼性システムを含む連合型デジタル権限管理機構 |
JP5681641B2 (ja) | 2009-01-07 | 2015-03-11 | ソニック アイピー, インコーポレイテッド | オンラインコンテンツのためのメディアガイドの特異的、収集的および自動的な生成 |
EP2507995A4 (en) | 2009-12-04 | 2014-07-09 | Sonic Ip Inc | SYSTEMS AND METHODS FOR TRANSPORTING ELEMENTARY BIT TRAIN CRYPTOGRAPHIC MATERIAL |
US9247312B2 (en) | 2011-01-05 | 2016-01-26 | Sonic Ip, Inc. | Systems and methods for encoding source media in matroska container files for adaptive bitrate streaming using hypertext transfer protocol |
US9467708B2 (en) | 2011-08-30 | 2016-10-11 | Sonic Ip, Inc. | Selection of resolutions for seamless resolution switching of multimedia content |
US8909922B2 (en) | 2011-09-01 | 2014-12-09 | Sonic Ip, Inc. | Systems and methods for playing back alternative streams of protected content protected using common cryptographic information |
US8964977B2 (en) | 2011-09-01 | 2015-02-24 | Sonic Ip, Inc. | Systems and methods for saving encoded media streamed using adaptive bitrate streaming |
WO2013044997A1 (en) * | 2011-09-28 | 2013-04-04 | Telefonica, S.A. | A method to measure quality of experience of a video service |
US8897753B2 (en) | 2011-10-12 | 2014-11-25 | Motorola Mobility Llc | Method for retrieving content by a wireless communication device having first and second radio access interfaces, wireless communication device and communication system |
US20130227158A1 (en) * | 2012-02-24 | 2013-08-29 | Stmicroelectronics S.R.L. | Media-quality adaptation mechanisms for dynamic adaptive streaming |
US9450997B2 (en) | 2012-02-27 | 2016-09-20 | Qualcomm Incorporated | Dash client and receiver with request cancellation capabilities |
US9374406B2 (en) | 2012-02-27 | 2016-06-21 | Qualcomm Incorporated | Dash client and receiver with a download rate estimator |
US20130227102A1 (en) * | 2012-02-29 | 2013-08-29 | Alcatel-Lucent Usa Inc | Chunk Request Scheduler for HTTP Adaptive Streaming |
US9526091B2 (en) | 2012-03-16 | 2016-12-20 | Intel Corporation | Method and apparatus for coordination of self-optimization functions in a wireless network |
US9276989B2 (en) * | 2012-03-30 | 2016-03-01 | Adobe Systems Incorporated | Buffering in HTTP streaming client |
US9438883B2 (en) * | 2012-04-09 | 2016-09-06 | Intel Corporation | Quality of experience reporting for combined unicast-multicast/broadcast streaming of media content |
US20130311614A1 (en) * | 2012-05-21 | 2013-11-21 | Motorola Mobility, Inc. | Method for retrieving content and wireless communication device for performing same |
US9083649B2 (en) * | 2012-07-02 | 2015-07-14 | Cox Communications, Inc. | Systems and methods for managing network bandwidth via content buffering |
AU2013288859B2 (en) | 2012-07-09 | 2016-05-19 | Vid Scale, Inc. | Power aware video decoding and streaming |
US9462021B2 (en) | 2012-09-24 | 2016-10-04 | Google Technology Holdings LLC | Methods and devices for efficient adaptive bitrate streaming |
CN103702237A (zh) * | 2012-09-28 | 2014-04-02 | 北京大学 | Http流媒体的速率自适方法及装置 |
US9313510B2 (en) | 2012-12-31 | 2016-04-12 | Sonic Ip, Inc. | Use of objective quality measures of streamed content to reduce streaming bandwidth |
US9191457B2 (en) * | 2012-12-31 | 2015-11-17 | Sonic Ip, Inc. | Systems, methods, and media for controlling delivery of content |
WO2014124555A1 (zh) * | 2013-02-17 | 2014-08-21 | 华为技术有限公司 | 流媒体数据传输的调节方法及装置 |
US10397292B2 (en) | 2013-03-15 | 2019-08-27 | Divx, Llc | Systems, methods, and media for delivery of content |
US9503491B2 (en) * | 2013-03-15 | 2016-11-22 | Echostar Technologies L.L.C. | Playback stall avoidance in adaptive media streaming |
US9906785B2 (en) | 2013-03-15 | 2018-02-27 | Sonic Ip, Inc. | Systems, methods, and media for transcoding video data according to encoding parameters indicated by received metadata |
US9094737B2 (en) | 2013-05-30 | 2015-07-28 | Sonic Ip, Inc. | Network video streaming with trick play based on separate trick play files |
US9967305B2 (en) | 2013-06-28 | 2018-05-08 | Divx, Llc | Systems, methods, and media for streaming media content |
CN105359536B (zh) * | 2013-07-17 | 2020-07-24 | 索尼公司 | 内容供给装置及方法、终端装置、以及内容供给系统 |
US8718445B1 (en) | 2013-09-03 | 2014-05-06 | Penthera Partners, Inc. | Commercials on mobile devices |
US9244916B2 (en) * | 2013-10-01 | 2016-01-26 | Penthera Partners, Inc. | Downloading media objects |
US9756102B2 (en) | 2013-10-07 | 2017-09-05 | Qualcomm Incorporated | Request cancellation method for media streaming |
DE102013220901A1 (de) * | 2013-10-15 | 2015-04-16 | Continental Automotive Gmbh | Verfahren zur Übertragung von digitalen Audio- und/oder Videodaten |
RU2016121189A (ru) * | 2013-11-25 | 2018-01-09 | Лэ Ши Чжи Синь Электроник Технолоджи (Тяньцзинь) Лимитэд | Способ воспроизведения видео, устройство и интеллектуальный терминал |
US9197717B2 (en) | 2013-11-27 | 2015-11-24 | At&T Intellectual Property I, Lp | Server-side scheduling for media transmissions according to client device states |
JP6053176B2 (ja) * | 2013-12-03 | 2016-12-27 | 日本電信電話株式会社 | 映像再生状態推定装置、映像再生状態推定方法、及びプログラム |
JP6053180B2 (ja) * | 2014-02-18 | 2016-12-27 | 日本電信電話株式会社 | 映像再生状態推定装置、映像再生状態推定方法、及びプログラム |
CN106031221B (zh) * | 2014-02-21 | 2019-08-16 | 瑞典爱立信有限公司 | 通信网络中的服务递送 |
US9596323B2 (en) | 2014-03-18 | 2017-03-14 | Qualcomm Incorporated | Transport accelerator implementing client side transmission functionality |
US20150271231A1 (en) * | 2014-03-18 | 2015-09-24 | Qualcomm Incorporated | Transport accelerator implementing enhanced signaling |
US9596281B2 (en) * | 2014-03-18 | 2017-03-14 | Qualcomm Incorporated | Transport accelerator implementing request manager and connection manager functionality |
US9350484B2 (en) | 2014-03-18 | 2016-05-24 | Qualcomm Incorporated | Transport accelerator implementing selective utilization of redundant encoded content data functionality |
US20150271226A1 (en) * | 2014-03-18 | 2015-09-24 | Qualcomm Incorporated | Transport accelerator implementing a multiple interface architecture |
US20150271225A1 (en) * | 2014-03-18 | 2015-09-24 | Qualcomm Incorporated | Transport accelerator implementing extended transmission control functionality |
IL231685A (en) * | 2014-03-24 | 2015-09-24 | Giraffic Technologies Ltd | A system and method for predicting memory reduction and network design |
EP3123776B1 (en) * | 2014-03-26 | 2019-05-08 | Telefonaktiebolaget LM Ericsson (publ) | Methods and equipment for management of playback buffers |
US20150281303A1 (en) * | 2014-03-26 | 2015-10-01 | Mohamed Yousef | Adaptive media streaming |
GB2524958A (en) | 2014-04-03 | 2015-10-14 | Orbital Multi Media Holdings Corp | Data flow control method |
GB2539335B (en) * | 2014-04-03 | 2018-03-14 | Orbital Multi Media Holdings Corp | Data flow control method and system |
US9866878B2 (en) | 2014-04-05 | 2018-01-09 | Sonic Ip, Inc. | Systems and methods for encoding and playing back video at different frame rates using enhancement layers |
US9813470B2 (en) * | 2014-04-07 | 2017-11-07 | Ericsson Ab | Unicast ABR streaming |
US20150350369A1 (en) * | 2014-05-30 | 2015-12-03 | Qualcomm Incorporated | Method For Reducing Pre-Fetching Of Multimedia Streaming Data With Minimal Impact On Playback User Experience |
US10149009B2 (en) * | 2014-07-09 | 2018-12-04 | Platypus Ip Llc | Indexing and compiling recordings in dwindling memory |
US20160036883A1 (en) * | 2014-07-30 | 2016-02-04 | Qualcomm Incorporated | Systems and methods for selective transport accelerator operation |
US9769043B2 (en) * | 2014-09-22 | 2017-09-19 | Avaya Inc. | Adaptive management of a media buffer |
EP3001693A1 (en) * | 2014-09-26 | 2016-03-30 | Alcatel Lucent | Server, client, method and computer program product for adaptive streaming of scalable video and/or audio to a client |
EP3001633B1 (en) * | 2014-09-26 | 2017-08-16 | Alcatel Lucent | Server, client, method and computer program product for adaptive streaming of media content to a client |
US20160094608A1 (en) * | 2014-09-30 | 2016-03-31 | Qualcomm Incorporated | Proactive TCP Connection Stall Recovery for HTTP Streaming Content Requests |
US10749918B2 (en) | 2014-11-10 | 2020-08-18 | Avago Technologies International Sales Pte. Limited | Adaptive streaming with early client indication |
US20160134672A1 (en) * | 2014-11-11 | 2016-05-12 | Qualcomm Incorporated | Delivering partially received segments of streamed media data |
US9270563B1 (en) * | 2014-11-24 | 2016-02-23 | Roku, Inc. | Apparatus and method for content playback utilizing crowd sourced statistics |
CN105744308A (zh) * | 2014-12-08 | 2016-07-06 | 深圳Tcl数字技术有限公司 | 流媒体数据的下载方法及装置 |
US20160212069A1 (en) * | 2015-01-21 | 2016-07-21 | Qualcomm Incorporated | Cooperative management of client device cache memory in an http session |
US9467387B2 (en) * | 2015-02-10 | 2016-10-11 | Ericsson Ab | System and method for managing bandwidth responsive to the duty cycle of an ABR client |
US20160277522A1 (en) * | 2015-03-20 | 2016-09-22 | Qualcomm Incorporated | Detecting playback buffer underrun at sink device to improve streaming media quality over bluetooth |
CN104967884B (zh) * | 2015-04-17 | 2018-01-26 | 北京奇艺世纪科技有限公司 | 一种码流切换方法和装置 |
US10051031B2 (en) * | 2015-04-20 | 2018-08-14 | Qualcomm Incorporated | Further device timing adjustments and methods for supporting DASH over broadcast |
US10212551B2 (en) * | 2015-07-10 | 2019-02-19 | Verizon Patent And Licensing Inc. | Location-based buffer management systems and methods |
US9826261B2 (en) * | 2015-09-09 | 2017-11-21 | Ericsson Ab | Fast channel change in a multicast adaptive bitrate (MABR) streaming network using multicast repeat segment bursts in a dedicated bandwidth pipe |
US9826262B2 (en) * | 2015-09-09 | 2017-11-21 | Ericsson Ab | Fast channel change in a multicast adaptive bitrate (MABR) streaming network using multicast repeat segment bursts in a shared progressive ABR download pipe |
JP6178370B2 (ja) * | 2015-09-09 | 2017-08-09 | 株式会社メディアリンクス | 映像伝送システム及び映像受信装置 |
US10178143B2 (en) * | 2015-09-29 | 2019-01-08 | International Business Machines Corporation | Selecting bitrate to stream encoded media based on tagging of important media segments |
WO2017063189A1 (en) * | 2015-10-16 | 2017-04-20 | Qualcomm Incorporated | Deadline signaling for streaming of media data |
US10433023B1 (en) * | 2015-10-27 | 2019-10-01 | Amazon Technologies, Inc. | Heuristics for streaming live content |
US10498368B2 (en) * | 2015-11-02 | 2019-12-03 | Mk Systems Usa Inc. | Dynamic client-side selection of FEC information |
KR102209292B1 (ko) * | 2015-11-04 | 2021-01-29 | 삼성전자 주식회사 | 멀티미디어 시스템에서 데이터 제공 방법 및 장치 |
US10791162B2 (en) * | 2015-12-31 | 2020-09-29 | Hughes Network Systems, Llc | Maximizing quality of service for QoS adaptive video streaming via dynamic application-layer throughput rate shaping |
KR102547320B1 (ko) | 2016-02-01 | 2023-06-23 | 삼성전자주식회사 | 전자 장치 및 전자 장치의 제어 방법 |
EP3200429B1 (de) * | 2016-02-01 | 2019-04-17 | Volkswagen Aktiengesellschaft | Verfahren zum abrufen eines datenstroms von einem server sowie fahrzeug mit einem netzwerkzugriffspunkt |
JP6466870B2 (ja) * | 2016-02-29 | 2019-02-06 | Kddi株式会社 | クライアント装置および方法 |
JP2017157903A (ja) * | 2016-02-29 | 2017-09-07 | 富士ゼロックス株式会社 | 情報処理装置 |
US10129574B2 (en) * | 2016-05-24 | 2018-11-13 | Divx, Llc | Systems and methods for providing variable speeds in a trick-play mode |
US10771833B2 (en) | 2016-05-31 | 2020-09-08 | The Trustees Of Princeton University | System and method for improving streaming video via better buffer management |
CN106899863B (zh) | 2016-06-28 | 2019-10-25 | 阿里巴巴集团控股有限公司 | 一种数据处理方法及装置 |
US10425458B2 (en) * | 2016-10-14 | 2019-09-24 | Cisco Technology, Inc. | Adaptive bit rate streaming with multi-interface reception |
US10348796B2 (en) | 2016-12-09 | 2019-07-09 | At&T Intellectual Property I, L.P. | Adaptive video streaming over preference-aware multipath |
US20180181186A1 (en) * | 2016-12-27 | 2018-06-28 | Paul S. Diefenbaugh | Buffering data from high-speed i/o to enable longer reduced power consumption state residency |
CN106658049B (zh) * | 2016-12-31 | 2019-08-30 | 深圳市优必选科技有限公司 | 一种视频播放缓冲方法及系统 |
US10498795B2 (en) | 2017-02-17 | 2019-12-03 | Divx, Llc | Systems and methods for adaptive switching between multiple content delivery networks during adaptive bitrate streaming |
CN108810522B (zh) * | 2017-04-26 | 2021-07-09 | 腾讯科技(深圳)有限公司 | 一种流媒体数据的评估方法及装置 |
US10397286B2 (en) | 2017-05-05 | 2019-08-27 | At&T Intellectual Property I, L.P. | Estimating network data streaming rate |
US10382517B2 (en) | 2017-06-09 | 2019-08-13 | At&T Intellectual Property I, L.P. | Estimating network data encoding rate |
US10873781B2 (en) * | 2017-06-13 | 2020-12-22 | Comcast Cable Communications, Llc | Video fragment file processing |
US10425456B2 (en) * | 2017-11-29 | 2019-09-24 | Bank Of America Corporation | Request processing system using a splitting engine |
TW201939961A (zh) * | 2018-03-14 | 2019-10-01 | 晨星半導體股份有限公司 | 應用於顯示裝置的電路及相關的控制方法 |
US11303947B2 (en) | 2018-04-24 | 2022-04-12 | Google Llc | Methods, systems, and media for adjusting quality level during synchronized media content playback on multiple devices |
EP3664456A1 (en) * | 2018-12-03 | 2020-06-10 | Nokia Solutions and Networks Oy | Apparatus and method for playing streamed media |
TWI690202B (zh) * | 2018-12-28 | 2020-04-01 | 瑞昱半導體股份有限公司 | 用於控制媒體播放器中之串流緩衝器的方法與相關的緩衝裝置 |
CN111510790B (zh) * | 2019-01-30 | 2021-10-15 | 上海哔哩哔哩科技有限公司 | 视频请求方法、系统、计算机设备及计算机可读存储介质 |
CN111866549B (zh) * | 2019-04-29 | 2023-03-24 | 腾讯科技(深圳)有限公司 | 一种视频处理方法及装置、终端、存储介质 |
GB201909348D0 (en) * | 2019-06-28 | 2019-08-14 | Nordic Semiconductor Asa | Reception of digital radio signals |
CN111107386A (zh) * | 2019-12-27 | 2020-05-05 | 北京达佳互联信息技术有限公司 | 直播视频的回看方法、装置、电子设备、系统及存储介质 |
CN111405319B (zh) * | 2020-03-31 | 2021-07-23 | 北京达佳互联信息技术有限公司 | 带宽确定方法、装置、电子设备和存储介质 |
GB202015327D0 (en) * | 2020-09-28 | 2020-11-11 | British Telecomm | Adaptive bit rate streaming |
US11381855B2 (en) | 2020-11-18 | 2022-07-05 | Roku, Inc. | Content-modification system with multiple video buffers feature |
CN112631958A (zh) * | 2020-12-29 | 2021-04-09 | 浙江工商大学 | 基于过滤表的dram行缓冲器混合管理方法 |
JP2022130167A (ja) | 2021-02-25 | 2022-09-06 | 富士通株式会社 | データ処理プログラム、データ処理方法、およびデータ処理システム |
Family Cites Families (64)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6058109A (en) | 1997-02-04 | 2000-05-02 | The Kohl Group, Inc. | Combined uniform rate and burst rate transmission system |
US9098297B2 (en) | 1997-05-08 | 2015-08-04 | Nvidia Corporation | Hardware accelerator for an object-oriented programming language |
JPH10336626A (ja) * | 1997-05-30 | 1998-12-18 | Nec Software Ltd | 映像データの転送方法および転送装置 |
US6247072B1 (en) | 1998-01-27 | 2001-06-12 | Cisco Technology, Inc. | Real-time data rate matching across a medium |
US6674717B1 (en) | 2000-03-30 | 2004-01-06 | Network Physics, Inc. | Method for reducing packet loss and increasing internet flow by feedback control |
US6978306B2 (en) | 2000-08-10 | 2005-12-20 | Pts Corporation | Multi-tier video delivery network |
US7061856B2 (en) | 2001-02-05 | 2006-06-13 | The Board Of Trustees Of The Leland Stanford Junior University | Data throughput over lossy communication links |
US7136353B2 (en) | 2001-05-18 | 2006-11-14 | Bytemobile, Inc. | Quality of service management for multiple connections within a network communication system |
WO2002103480A2 (en) | 2001-06-15 | 2002-12-27 | Iquest Networks, Inc. | System for communication of streaming digital data |
US6910079B2 (en) | 2002-01-25 | 2005-06-21 | University Of Southern California | Multi-threshold smoothing |
US7542471B2 (en) | 2002-10-30 | 2009-06-02 | Citrix Systems, Inc. | Method of determining path maximum transmission unit |
US8503294B2 (en) | 2003-07-11 | 2013-08-06 | Nec Corporation | Transport layer relay method, transport layer relay device, and program |
US7516238B2 (en) | 2003-09-30 | 2009-04-07 | Microsoft Corporation | Background transport service |
TWI229528B (en) * | 2003-10-31 | 2005-03-11 | Benq Corp | Method of controlling dataflow for a media player system |
US20050223141A1 (en) | 2004-03-31 | 2005-10-06 | Pak-Lung Seto | Data flow control in a data storage system |
US7889697B2 (en) | 2004-05-04 | 2011-02-15 | Qualcomm Incorporated | Method and apparatus for content delivery to a mobile device |
GB0412342D0 (en) | 2004-06-03 | 2004-07-07 | Ibm | Convergent playback of buffered content to real-time content play |
US7721315B2 (en) | 2004-12-17 | 2010-05-18 | Vibe Solutions Group, Inc. | Method and system for on-demand delivery of personalized internet-based content to television viewers |
US7675856B2 (en) | 2005-03-24 | 2010-03-09 | Microsoft Corporation | Bandwidth estimation in broadband access networks |
DE602005009755D1 (de) * | 2005-04-11 | 2008-10-23 | Ericsson Telefon Ab L M | Technik zur steuerung von datenpaketübermittlungen von daten mit variabler bitrate |
US7743183B2 (en) | 2005-05-23 | 2010-06-22 | Microsoft Corporation | Flow control for media streaming |
AU2006280105B9 (en) * | 2005-08-12 | 2011-08-18 | Nokia Solutions And Networks Gmbh & Co. Kg | A multi-source and resilient video on demand streaming system for a peer-to-peer subscriber community |
US20070067480A1 (en) * | 2005-09-19 | 2007-03-22 | Sharp Laboratories Of America, Inc. | Adaptive media playout by server media processing for robust streaming |
US8150995B2 (en) | 2005-09-30 | 2012-04-03 | Microsoft Corporation | Receive window auto-tuning |
US7701853B2 (en) | 2005-09-30 | 2010-04-20 | Alcatel-Lucent Usa Inc. | Method for policing-based adjustments to transmission window size |
US7577980B2 (en) | 2006-01-19 | 2009-08-18 | International Business Machines Corporation | Bit-rate constrained trick play through stream switching and adaptive streaming |
US7711841B2 (en) * | 2006-02-28 | 2010-05-04 | Sharp Laboratories Of America, Inc. | Systems and methods for reducing the effects of variations on the playback of streaming media |
US9432433B2 (en) * | 2006-06-09 | 2016-08-30 | Qualcomm Incorporated | Enhanced block-request streaming system using signaling or block creation |
US7783773B2 (en) | 2006-07-24 | 2010-08-24 | Microsoft Corporation | Glitch-free media streaming |
JP2008177900A (ja) | 2007-01-19 | 2008-07-31 | Fujitsu Ltd | データ通信装置、設定情報更新方法および設定情報更新プログラム |
US8462684B1 (en) | 2008-05-19 | 2013-06-11 | Marvell International Ltd. | Power saving technique for a wireless device |
US7821937B1 (en) | 2007-06-29 | 2010-10-26 | Symantec Corporation | Network protocol with damage loss resilient congestion control algorithm |
US8346959B2 (en) | 2007-09-28 | 2013-01-01 | Sharp Laboratories Of America, Inc. | Client-controlled adaptive streaming |
US7895629B1 (en) | 2007-11-07 | 2011-02-22 | At&T Mobility Ii Llc | Video service buffer management in a mobile rate control enabled network |
EP2255535B1 (en) | 2008-03-12 | 2015-01-14 | Telefonaktiebolaget L M Ericsson (publ) | Device and method for adaptation of target rate of video signals |
KR20100009903A (ko) | 2008-07-21 | 2010-01-29 | 엘지전자 주식회사 | 콘텐츠 재생방법 및 장치, 그리고 그의 휴대 단말장치 |
US7886073B2 (en) | 2008-08-08 | 2011-02-08 | Cisco Technology, Inc. | Systems and methods of reducing media stream delay |
US20100054123A1 (en) | 2008-08-30 | 2010-03-04 | Liu Yong | Method and device for hign utilization and efficient flow control over networks with long transmission latency |
JP4735697B2 (ja) * | 2008-09-29 | 2011-07-27 | ソニー株式会社 | 電子機器、コンテンツ再生方法及びプログラム |
US8375140B2 (en) * | 2008-12-04 | 2013-02-12 | Google Inc. | Adaptive playback rate with look-ahead |
WO2010111261A1 (en) | 2009-03-23 | 2010-09-30 | Azuki Systems, Inc. | Method and system for efficient streaming video dynamic rate adaptation |
JP5673538B2 (ja) * | 2009-08-10 | 2015-02-18 | 日本電気株式会社 | 配信システム |
US20110090795A1 (en) | 2009-09-11 | 2011-04-21 | Victor On Kwok Li | Differentiation among occurrences of packet reordering, congestive packet loss, or random packet loss in communication networks |
US20110096828A1 (en) * | 2009-09-22 | 2011-04-28 | Qualcomm Incorporated | Enhanced block-request streaming using scalable encoding |
JP2011091709A (ja) * | 2009-10-23 | 2011-05-06 | Funai Electric Co Ltd | ネットワーク機器 |
KR20110065100A (ko) | 2009-12-09 | 2011-06-15 | 삼성전자주식회사 | 멀티미디어 스트리밍 서비스를 지원하는 방법 및 장치 |
EP2360924A1 (en) | 2010-01-18 | 2011-08-24 | Alcatel-Lucent España, S.A. | A digital multimedia data transmission device and method |
US9510029B2 (en) | 2010-02-11 | 2016-11-29 | Echostar Advanced Technologies L.L.C. | Systems and methods to provide trick play during streaming playback |
JP5534006B2 (ja) | 2010-04-15 | 2014-06-25 | 日本電気株式会社 | 伝送装置、伝送方法及びコンピュータプログラム |
EP2398273B1 (en) | 2010-06-18 | 2018-02-14 | Acer Incorporated | Method of handling buffer status report and communication device thereof |
KR20120010089A (ko) | 2010-07-20 | 2012-02-02 | 삼성전자주식회사 | Http 기반의 멀티미디어 스트리밍 서비스의 품질 향상을 위한 방법 및 장치 |
US8589583B2 (en) * | 2010-09-08 | 2013-11-19 | Hulu, Inc. | Method and apparatus for adaptive bit rate switching |
CN101964902A (zh) * | 2010-09-26 | 2011-02-02 | 中兴通讯股份有限公司 | 网络视频流的播放方法及连接设备 |
US8639835B2 (en) | 2010-11-29 | 2014-01-28 | Verizon Patent And Licensing Inc. | TCP window size performance optimization in wireless networks |
US8873385B2 (en) | 2010-12-07 | 2014-10-28 | Microsoft Corporation | Incast congestion control in a network |
US9020039B2 (en) | 2011-01-06 | 2015-04-28 | Sonic Ip, Inc. | Systems and methods for encoding alternative streams of video for use in adaptive bitrate streaming |
US20120263058A1 (en) | 2011-04-15 | 2012-10-18 | Jds Uniphase Corporation | Testing shaped tcp traffic |
WO2012162882A1 (en) | 2011-05-31 | 2012-12-06 | Technicolor (China) Technology Co., Ltd. | Method and apparatus for streaming multimedia contents |
US8903952B2 (en) | 2011-08-16 | 2014-12-02 | Arris Enterprises, Inc. | Video streaming using adaptive TCP window size |
US20150032899A1 (en) | 2011-11-14 | 2015-01-29 | Telefonaktiebolaget L M Ericsson (Publ) | Media Streaming in Mobile Networks with Improved Efficiency |
US20130227158A1 (en) | 2012-02-24 | 2013-08-29 | Stmicroelectronics S.R.L. | Media-quality adaptation mechanisms for dynamic adaptive streaming |
US9374406B2 (en) | 2012-02-27 | 2016-06-21 | Qualcomm Incorporated | Dash client and receiver with a download rate estimator |
US9450997B2 (en) | 2012-02-27 | 2016-09-20 | Qualcomm Incorporated | Dash client and receiver with request cancellation capabilities |
US20140136653A1 (en) | 2012-02-27 | 2014-05-15 | Qualcomm Incorporated | Dash client and receiver with download rate acceleration |
-
2013
- 2013-01-20 US US13/745,810 patent/US9450997B2/en active Active
- 2013-01-20 US US13/745,811 patent/US9503490B2/en active Active
- 2013-01-20 US US13/745,809 patent/US9386058B2/en active Active
- 2013-02-26 WO PCT/US2013/027810 patent/WO2013130475A1/en active Application Filing
- 2013-02-26 JP JP2014558950A patent/JP6271445B2/ja not_active Expired - Fee Related
- 2013-02-26 CN CN201380016035.8A patent/CN104205770B/zh not_active Expired - Fee Related
- 2013-02-26 CN CN201380016181.0A patent/CN104205772B/zh not_active Expired - Fee Related
- 2013-02-26 WO PCT/US2013/027813 patent/WO2013130477A1/en active Application Filing
- 2013-02-26 JP JP2014558951A patent/JP2015513840A/ja active Pending
- 2013-02-26 JP JP2014558949A patent/JP6054427B2/ja not_active Expired - Fee Related
- 2013-02-26 KR KR1020147027019A patent/KR20140130211A/ko not_active Application Discontinuation
- 2013-02-26 EP EP13710662.1A patent/EP2820823B1/en active Active
- 2013-02-26 EP EP13710175.4A patent/EP2820819B1/en active Active
- 2013-02-26 KR KR1020147027003A patent/KR101699870B1/ko active IP Right Grant
- 2013-02-26 KR KR1020147027017A patent/KR20140130210A/ko active IP Right Grant
- 2013-02-26 WO PCT/US2013/027809 patent/WO2013130474A1/en active Application Filing
- 2013-02-26 CN CN201380016000.4A patent/CN104205769B/zh not_active Expired - Fee Related
- 2013-02-26 EP EP13710176.2A patent/EP2820820A1/en not_active Withdrawn
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6054427B2 (ja) | プレイバックレート選択を伴う改良されたdashクライアントおよび受信機 | |
JP2015513840A5 (ja) | ||
JP2015511782A (ja) | ダウンロードレートエスティメータを備えた改良されたdashクライアントおよび受信機 | |
JP2015515173A (ja) | マルチプルなtcp接続を介したソースと受信機との間のhttpストリーミングの制御 | |
EP3022884B1 (en) | Quality optimization with buffer and horizon constraints in adaptive streaming | |
US8930559B2 (en) | Adaptive hypertext transfer protocol (“HTTP”) media streaming systems and methods | |
KR101582371B1 (ko) | 잉여 네트워크 용량을 사용한 점진적 다운로드 시스템 및 방법 | |
US20150271231A1 (en) | Transport accelerator implementing enhanced signaling | |
WO2014143631A1 (en) | Playback stall avoidance in adaptive media streaming | |
US20160072864A1 (en) | Method and client terminal for receiving a multimedia content split into at least two successive segments, and corresponding computer program product and computer readable mediium |