JP2015515173A - マルチプルなtcp接続を介したソースと受信機との間のhttpストリーミングの制御 - Google Patents
マルチプルなtcp接続を介したソースと受信機との間のhttpストリーミングの制御 Download PDFInfo
- Publication number
- JP2015515173A JP2015515173A JP2014558947A JP2014558947A JP2015515173A JP 2015515173 A JP2015515173 A JP 2015515173A JP 2014558947 A JP2014558947 A JP 2014558947A JP 2014558947 A JP2014558947 A JP 2014558947A JP 2015515173 A JP2015515173 A JP 2015515173A
- Authority
- JP
- Japan
- Prior art keywords
- rate
- tcp
- receiver
- request
- download
- 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.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 claims description 217
- 239000012634 fragment Substances 0.000 claims description 213
- 230000008569 process Effects 0.000 claims description 163
- 230000004044 response Effects 0.000 claims description 42
- 238000005259 measurement Methods 0.000 claims description 16
- 230000015654 memory Effects 0.000 claims description 13
- 239000000872 buffer Substances 0.000 description 263
- 230000008439 repair process Effects 0.000 description 96
- 230000006870 function Effects 0.000 description 62
- 230000008859 change Effects 0.000 description 31
- 230000006399 behavior Effects 0.000 description 16
- 230000003044 adaptive effect Effects 0.000 description 11
- 238000004364 calculation method Methods 0.000 description 11
- 230000000694 effects Effects 0.000 description 11
- 238000012935 Averaging Methods 0.000 description 10
- 238000013459 approach Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 8
- 230000009471 action Effects 0.000 description 7
- PXFBZOLANLWPMH-UHFFFAOYSA-N 16-Epiaffinine Natural products C1C(C2=CC=CC=C2N2)=C2C(=O)CC2C(=CC)CN(C)C1C2CO PXFBZOLANLWPMH-UHFFFAOYSA-N 0.000 description 6
- 230000006978 adaptation Effects 0.000 description 6
- 230000008901 benefit Effects 0.000 description 6
- 230000003139 buffering effect Effects 0.000 description 6
- 230000007423 decrease Effects 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 6
- 238000012544 monitoring process Methods 0.000 description 6
- 230000001413 cellular effect Effects 0.000 description 5
- 238000001514 detection method Methods 0.000 description 5
- 238000012886 linear function Methods 0.000 description 5
- 230000035484 reaction time Effects 0.000 description 5
- 238000005070 sampling Methods 0.000 description 5
- 230000001174 ascending effect Effects 0.000 description 4
- 239000012464 large buffer Substances 0.000 description 4
- 230000001133 acceleration Effects 0.000 description 3
- 230000001427 coherent effect Effects 0.000 description 3
- 238000012937 correction Methods 0.000 description 3
- 230000001934 delay Effects 0.000 description 3
- 239000006185 dispersion Substances 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 239000012092 media component Substances 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 230000009467 reduction Effects 0.000 description 3
- 230000002459 sustained effect Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 2
- 238000009499 grossing Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000000926 separation method Methods 0.000 description 2
- 238000007792 addition Methods 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000037406 food intake Effects 0.000 description 1
- 230000009474 immediate action Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 230000008450 motivation Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000002028 premature Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000009257 reactivity Effects 0.000 description 1
- 238000007430 reference method Methods 0.000 description 1
- 230000004043 responsiveness Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 230000003936 working memory Effects 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1083—In-session procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/40—Support for services or applications
- H04L65/401—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference
- H04L65/4015—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference where at least one of the additional parallel sessions is real time or time sensitive, e.g. white board sharing, collaboration or spawning of a subconference
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1832—Details of sliding window management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/27—Evaluation or update of window size, e.g. using information derived from acknowledged [ACK] packets
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
- H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
クライアントデバイスは、ストリーミングメディアを提示し、ストリームを制御するためのストリームマネージャと、コンテンツについてのネットワーク要求を行うための要求アクセラレータと、ストリームマネージャおよび要求アクセラレータに結合された、どの要求を行うか決定するためのソースコンポーネントと、ネットワーク接続と、メディアプレーヤとを含む。要求アクセラレータは、複数のTCP接続を使用してダウンロードレートを加速させることができる。目標ダウンロードレートは、HTTP要求の間で変わり得る。所与のTCP接続用のTCP受信機ウィンドウサイズは、そのTCP接続用の目標ダウンロードレートおよび/または現在のTCP接続用の現在の推定ラウンドトリップ時間を、乗数レートで乗算したものに基づくことができ、乗数レートは、現在のTCP接続用の目標ダウンロードレートと、目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である。
Description
関連出願の相互参照
[0001]本出願は、参照によってその内容全体がすべての目的のために本明細書に組み込まれている、2012年2月27日に出願された、「Improved DASH Client and Receiver with Rate Adaptation and Downloading for Adaptive Video」と題する米国仮出願第61/603,569号の利益を主張する。
[0001]本出願は、参照によってその内容全体がすべての目的のために本明細書に組み込まれている、2012年2月27日に出願された、「Improved DASH Client and Receiver with Rate Adaptation and Downloading for Adaptive Video」と題する米国仮出願第61/603,569号の利益を主張する。
[0002]DASHは、「動的適応ストリーミングオーバーHTTP(Dynamic Adaptive Streaming over HTTP)」を指す。DASHを使用して、コンテンツプロバイダは、コンテンツを、MPDファイルなど、関連付けられたメタデータとともに、セグメント、フラグメント、リプレゼンテーション(representations)、アダプテーション(adaptations)などにフォーマットし、それらすべてを、標準HTTPサーバまたは特殊化HTTPサーバを経由して、利用可能なファイルとして記憶する。DASHクライアントとは、これらのファイルを必要に応じて取得して、DASHクライアントのユーザにプレゼンテーションを提示する受信機である。
[0003]ユーザが通常、ネットワークが制限されている環境において、事前告知がほとんどまたはまったくなしで高品質ストリーミングを望むので、DASHクライアントは、厳しい制約を有する。したがって、改良されたDASHクライアントが望まれる。
[0004]クライアントデバイスは、ストリーミングメディアを提示し、ストリームを制御するためのストリームマネージャと、コンテンツについてのネットワーク要求を行うための要求アクセラレータと、どの要求を行うか決定するための、ストリームマネージャおよび要求アクセラレータに結合されたソースコンポーネントと、ネットワーク接続と、メディアプレーヤとを含む。要求アクセラレータは、要求をバッファリングするための要求データバッファと、アクセラレータが応答することができる各要求に完了応答を戻すための論理とを備える。ストリームマネージャ、要求アクセラレータ、およびソースコンポーネントは、プロセッサ命令またはプログラムコードとして実装されることができ、クライアントデバイスは、プログラムメモリと、ワーキングメモリと、プロセッサと、電力源とをさらに備える。クライアントデバイスはまた、ディスプレイとユーザ入力デバイスとを含み得る。クライアントタスクは、効率的にデータをストリーミングするために、ソースコンポーネント、ストリームマネージャ、および要求アクセラレータの間でパースされる。
[0005]様々な態様において、本明細書に記載するように、クライアントは、リプレゼンテーションを維持し、または別のリプレゼンテーションに切り替えるべきときを決定するなどの動作を実施し、どのフラグメントを要求するか決定し、メディアプレーヤが、ほとんどの条件において、失速(stalling)することなくストリームを継続するのに十分なデータを確実に取得できるようにすることができる。
[0006]ソースと受信機との間の複数のTCP接続を有すること、そして、それら接続の各々について、そのTCP接続用のTCP受信機ウィンドウサイズを決定することであって、ソースと受信機との間のTCP接続が直接接続または間接接続であることができる、決定すること、および複数のTCP接続の各々について、メディアコンテンツ用の目標ダウンロードレートを決定することであって、目標ダウンロードレートが、少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、決定すること、ダウンロードされるべきメディアコンテンツの複数のメディアデータ要素をダウンロードするために、複数のTCP接続の各TCP接続を使用することであって、メディアコンテンツが、複数のHTTP要求への応答の一部分または全部であり、所与のTCP接続用の決定されたTCP受信機ウィンドウサイズが、そのTCP接続用の目標ダウンロードレートに少なくとも部分的に基づいて決定され、決定されたTCP受信機ウィンドウサイズが、少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、使用することによって、ダウンロードレートが、ソースと受信機との間でネットワーク経路を通じて加速され得る。ダウンロードレート加速のための方法および装置が提供される。
[0007]決定されたTCP受信機ウィンドウサイズは、乗数レート(multiplier rate)で乗算された、現在のTCP接続についての現在の推定ラウンドトリップ時間(「ERTT」(estimated round-trip time))に基づいて決定されることができ、乗数レートは、現在のTCP接続用の目標ダウンロードレート、および目標ダウンロードレートよりも所定の量だけ高いレートによって制限される範囲内である。現在のERTTは、履歴により、おそらくはTCP接続を介したアクティブHTTP要求が所定の継続時間期間にわたって存在していなかった休止期間の終了時の測度に基づいて、決定され得る。TCP接続についての目標ダウンロードレートは、使用中のすべてのTCP接続を通じた現在の総ダウンロードレートを、使用中のTCP接続の数で除算したものに比例するものであることができ、たとえば、TCP接続についての目標ダウンロードレートは、使用中のすべてのTCP接続にわたる現在の総ダウンロードレートを、使用中のTCP接続の数で除算したものの2倍である。目標ダウンロードレートは、メディアコンテンツのプレイバックレートに比例してよく、プレイバックレートは、使用中のすべてのTCP接続に及ぶ総計にわたるレートを、使用中のTCP接続の数で除算したものである。各メディアデータ要素は、所定の分散範囲内のサイズを有するいくつかのチャンクへと分けられてもよく、そのようなチャンクの数は、使用中のTCP接続の数、現在のTCP接続についての現在のERTT、現在のダウンロードレート、および/または要求されているメディアフラグメントのサイズに基づく。所定の分散範囲はゼロであり得、および/または各チャンクは、最小バイト数以上のサイズを有し得る。後続メディアデータ要素についての後のHTTP要求が、第1の利用可能TCP接続に割り当てられることができる。
[0008]いくつかの実施形態では、ソースと受信機との間のネットワーク経路を介したダウンロードは、メディアコンテンツ用の目標ダウンロードレートを決定することと、ネットワーク経路に関するネットワーク条件を決定することと、ネットワーク条件に基づいて、ソースと受信機との間で使用すべきいくつかのTCP接続を決定することと、複数のHTTP要求への応答の一部分または全部として、複数のメディアデータ要素をダウンロードするために、TCP接続の各々を使用することとを備える。TCP接続の数は、2と16との間であり、および/または目標ダウンロードレート、ERTT、および推定損失レートの平方根の積に比例し得る。TCP受信機ウィンドウサイズは、目標ダウンロードレートに基づいてすることもできる。
[0009]受信機は、ネットワークからデータを受信するための受信機回路と、プロセスを実行するためのプロセッサと、データを記憶するためのメモリと、TCP接続についてのTCP受信機ウィンドウサイズを含む、ソースと受信機との間の複数のTCP接続に関連したデータ用のストレージであって、ソースと受信機との間のTCP接続が直接接続または間接接続であることができるストレージと、メディアコンテンツ用の目標ダウンロードレートを決定するための論理(ハードウェア、ソフトウェア、または組合せ)と、メディアコンテンツの複数のメディアデータ要素をダウンロードした結果のためストレージとを含むことができ、メディアコンテンツは、複数のHTTP要求への応答の一部分または全部であり、所与のTCP接続についての決定されたTCP受信機ウィンドウサイズは、目標ダウンロードレートに少なくとも部分的に基づくサイズであり、決定されたTCP受信機ウィンドウサイズは、少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる。
[0010]現在のTCP接続についてのTCP受信機ウィンドウサイズは、乗数レートで乗算された、現在のTCP接続についての現在の推定ラウンドトリップ時間(「ERTT」)の積であってもよく、乗数レートは、現在のTCP接続についての目標ダウンロードレートと、目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である。
[0011]受信機は、マルチプルなHTTP接続を使用し、メディア要求をより小さいチャンク要求に分解し、TCPフロー制御メカニズムを使用して接続を同期させ、データをバースト的に(in bursts)要求することもできる。さらに、受信機は、HTTPパイプライン化プロセスを使用して、接続をビジーに保つことができる。
[0012]様々な要素は、ネットワーク経路によって結合されたソースと受信機との間のネットワーク経路を介したデータダウンロードを制御するためのプロセッサによって実行されるコンピュータ可読媒体を使用して実装されることもできる。コンピュータ可読媒体は、非一時的コンピュータ可読媒体でありうる。
[0013]本発明の他の態様が、本記述から明らかになるはずである。
[0050]本明細書で説明されるDASHクライアントは、図2に示すように、ストリームマネージャ(SM)と、要求アクセラレータ(RA)と、ソースコンポーネント(SC)と、ネットワーク接続と、メディアプレーヤとを含む。DASHクライアントは、1つまたは複数のメディアデータバッファも含み得る。いくつかの実装形態では、RA、SCおよびメディアプレーヤはすべて、それら自体のデータバッファ、または1つの大きいデータバッファの論理区画を有し得る。他の実装形態では、おそらくRAのみが、要求をバッファリングするためのデータバッファを有し、その結果、RAは、それが応答し得るあらゆる要求に対して完了応答(complete response)を戻すことができるようになり、メディアプレーヤは、SCがセットアップしたデータバッファはどれでも使用する。SMは、決定を行うのに必要とされるメタデータを記憶するための、それ自体の(物理的または論理的)ローカルストレージを有し得る。
[0051]図1は、DASHクライアントをもつDASH展開を示す。
[0052]図2は、様々なコンポーネントをもつDASHクライアントの例示的アーキテクチャを示す。SM、RA、SCおよびメディアプレーヤは、ハードウェア、ソフトウェアまたは何らかの組合せで実装され得ることを理解されたい。したがって、機能がコンポーネントによるものである場合、機能は、プロセッサ命令、プログラムコードなどとして実装されてよく、この場合、それらの命令を実行するための必要なハードウェア(プログラムメモリ、ROM、RAM、プロセッサ、電力源、コネクタ、回路板など)が含意される。ネットワーク機能が記述される場合、ネットワーク接続は、存在するものと理解されるべきであり、ワイヤード、光学、ワイヤレスなどであってよく、ユーザインタラクションが含意される場合、ユーザインターフェース能力(ディスプレイ、キーボード、タッチパッド、スピーカ、マイクロフォンなど)も含意される。
[0053]DASHクライアントは、2つのクロック、またはそれらの論理的等価物を維持する。一方のクロックは、クライアント中で稼動するローカルクロックの時間を示すリアルタイムクロック回路またはソフトウェアであり、他方のクロックは、メディアコンテンツの開始に対する、メディアコンテンツのプレゼンテーションの時間を表すプレゼンテーション時間である。本明細書において、リアルタイムクロック時間は「r時間」と呼ばれ、「p時間」は、プレゼンテーション時間を示す記述子である。
[0054]リプレゼンテーションとは、同じコンテンツについての、異なるビットレートまたは他の違いで符号化されたメディアストリームである。したがって、ユーザは通常、1つのリプレゼンテーションを必要とするだけであるが、クライアントは、条件および/または要件が変わると、あるリプレゼンテーションから別のリプレゼンテーションに切り替えうる。たとえば、帯域幅が高い場合、ストリーミングクライアントは、高品質、高ビットレートのリプレゼンテーションを選びうる。帯域幅が低減された場合、クライアントは、より低品質のより低いビットレートリプレゼンテーションに切り替えることによって、これらの条件に適応することができる。
[0055]切替え点(またはランダムアクセスポイント)は、ストリームに先行するデータを知る必要なしに、メディアサンプルの復号がそこから始まり得る、リプレゼンテーション中のサンプルである。特に、ビデオリプレゼンテーションでは、サンプル(フレーム)は概して以前のフレームに依存するので、あらゆるサンプルがランダムアクセスポイントであるわけではない。ストリーミングクライアントは、リプレゼンテーションを切り替えたいときには、無駄な作業を避けるために、必ず切替え点において新たなリプレゼンテーションを復号し始めるべきである。いくつかのケースでは、切替え点は、ストリーミングクライアントに対してセグメントインデックス(sidx)中でシグナリングされる。
[0056]リプレゼンテーショングループ(単にグループと略記されることがある)とは、切替え可能なリプレゼンテーションのセットである。メディアプレゼンテーションは、1つよりも多くのリプレゼンテーショングループを含み得る。メディアプレゼンテーションは、たとえば、様々なビットレートでのビデオリプレゼンテーションについて1つのリプレゼンテーショングループと、オーディオビットレートについて別のリプレゼンテーショングループとを有し得る。DASH規格では、リプレゼンテーショングループは、適応セットと呼ばれることもある。
[0057]セグメントとは、複数のリプレゼンテーションのうちの1つのリプレゼンテーションの少なくとも一部分についてのメディアデータを含むファイルである。フラグメントとは、フラグメントの開始p時間からセグメント内のフラグメントのバイト範囲へのマッピングが利用可能である、セグメントの一部である。フラグメントの代わりにサブセグメントという用語が使用されることもあり、これらは等価であると見なされ得る。一部のメディアコンテンツは、フラグメントに分割されず、そのようなケースにおいて、「フラグメント」は、セグメント自体を指す場合がある。
[0058]図3は、2つの可能なリプレゼンテーション切替えプロセスを示すタイミング図である。切替えは、後方参照(backward looking)(図3Aの第1のプロセス)であることができ、この場合、switch−fromリプレゼンテーション中ですでに要求されているp時間ストレッチを見ることによって、およびこのストレッチの終了に最も近い、switch−toリプレゼンテーションから、p時間において後退する前の切替え点を選ぶことによって、switch−toリプレゼンテーションにおける切替え点が見つかる。第2のプロセス(図3B)は前方参照(forward looking)であり、switch−fromリプレゼンテーション中の、最後の要求されるp時間から始まる、switch−toリプレゼンテーション中の、p時間において前進する次の切替え点を見つける。
[0059]図4は、切替え点がアライメントされたとき、および切替え点が最後の要求フラグメントの後にすぐに続くときの、切り替えるためのプロセスを示すタイミング図である。この図は、前方参照方法と後方参照方法の両方の挙動を示すが、それは、これらの2つのプロセスが、そのような設定において同一に振る舞うからである。したがって、切替え点がアライメントされるときには、どちらのプロセスも、重複データをダウンロードする必要はない。
[0060]プレゼンテーション時間とは、メディアが、一般には通常速度で、プレイアウトまたはプレイバックすると予想される時間期間である。たとえば、30分のビデオプレゼンテーションであれば、30分間再生する。ユーザは、早送りまたは巻き戻しをする場合があるので、実際にかかる時間は変わるが、プレゼンテーションは依然として、30分のビデオプレゼンテーションであることを理解されたい。プレゼンテーション要素が、プレゼンテーション時間に、ユーザにプレゼンテーションを提示する。プレゼンテーション要素の例としては、視覚ディスプレイおよびオーディオディスプレイ、またはストリームを提示することができるデバイスにパイピングされるビデオ/オーディオストリームがある。「プレイバック」とは、メディアの消費を記述するのに使用される用語である。たとえば、スマートフォンであれば、プレゼンテーションのプレゼンテーション時間(p時間)にわたってプレゼンテーションを表すメディアデータをダウンロードまたは取得し、バッファリングすることができ、メディアプレーヤは、そのメディアを「消費する」と言われ、好ましくは、バッファが少なくともプレゼンテーション時間の終了までは完全には空にならないように消費し、そうすることによってユーザは、受信機がより多くのデータを取得するのを待っている間、プレゼンテーションの失速を受けない。当然ながら、「プレイバック」または「プレイアウト」は、メディアが一度よりも多く再生されることは含意しない。多くの事例において、メディアは一度消費されると、再度使用されることはない。
[0061]プレゼンテーションバッファとは、受信機、メディアプレーヤ内にあるか、または一方もしくは両方にとってアクセス可能なメモリ要素である。説明を簡単にするために、「プレゼンテーションバッファ」、「バッファ」、「メディアバッファ」および「プレイバックバッファ」という用語を互換的に使用するが、これは、ダウンロードされているがまだプレイアウト、すなわち消費されていないデータ、すなわち通常はメディアデータを備える論理バッファであることは理解している。プレゼンテーションバッファを成すデータが、デバイスにおいて、様々なコンポーネントの間で区分される場合があり、すなわち、ダウンロードされたデータのいくつかの部分が、1つのプロセス、たとえば、デバイス内の受信プロセスによって保持され、他の部分は、別のプロセス、たとえば、デバイス内のプレイアウトプロセスにすでに渡されている場合がある。プレゼンテーションバッファを成すデータの少なくとも一部は、異なるプロセスの異なるバッファにわたって少なくとも部分的に複製される場合もあり得る。いくつかのケースでは、ダウンロードされているがまだプレイアウトされていないデータすべてが、依然としてプレゼンテーションバッファ内にあると見なされるわけではなく、たとえば、いくつかのケースでは、メディアコンテンツは、メディアプレーヤにパスされると、もはやプレゼンテーションバッファにあると見なすことはできない。概して、メディアデータが存在する場合、ダウンロードされているがまだプレイアウトされておらず、さらにプレゼンテーションバッファ内にあると見なされないメディアデータの量は、非常に少ない。
[0062]プレゼンテーションバッファは、メディアを受信しプレイバックし、受信メディアデータを、消費されるまで記憶する際の不均一に適応する。メディアデータは、消費された後、構成に応じて、消去されることもでき、または記憶され続けることもできる。いくつかの実装形態では、プレゼンテーションバッファのサイズ(プレゼンテーションバッファに記憶することができるデータバイトの数で測ることができる)は、時間とともに変わり得る。たとえば、プレゼンテーションバッファは、必要に応じて共有メモリから動的に割り振られ得る。
[0063]本明細書において詳細に説明する多くの例では、プレゼンテーションバッファは、サイズによって特徴付けられると仮定され得る。プレゼンテーションバッファに専用の固定メモリサイズのケースでは、そのサイズは、利用可能メモリに記憶することができるバイトの数で測ることができる。プレゼンテーションバッファが動的に割り振られる場合、プレゼンテーションバッファに起因する「サイズ」は、プレゼンテーションバッファに現時点で割り振られているバイトの数、プレゼンテーションバッファに割り振ることができ得るバイトの最大数、または何らかの他の適切な測度に等しいものであり得る。プレゼンテーションバッファサイズは、プレゼンテーションバッファ中の現在利用可能なメディアのプレゼンテーション時間プレイアウト持続期間によって測定されることもある。
[0064]プレゼンテーションバッファは、別の特性、すなわちバッファの「レベル」または「充満レベル」も有する。プレゼンテーションバッファのレベルは、どれだけ多くの未消費メディアデータがプレゼンテーションバッファ中に存在するかを表し、たとえばバイトまたはプレゼンテーション持続時間で測定される。レベルは、メディアデータが受信されると上がり、メディアデータが消費されると下がると予想される。レベルは、論理的なものにすぎない可能性があり、たとえば、プレゼンテーションバッファは、メディアデータで常に満杯(full)であり得るが、メディアの一部、たとえば、すでに消費されたメディアデータは、新規メディアデータが受信されると、上書きのためにマーキングされる。いくつかの受信機は、「空きバッファ」が、未消費のメディアデータがゼロであるコンディションであり、「満杯バッファ」が、プレゼンテーションバッファの100%が未消費メディアデータで満たされているコンディションであるようにプログラムされ得る。他の受信機は、プレゼンテーションバッファサイズの0%〜100%よりも小さい範囲にレベルが及ぶように、他の限度を有し得る。未消費メディアデータがバッファに記憶されたときに共有メモリが使われ、プレゼンテーションバッファしか割り振られたことがないケースでは、プレゼンテーションバッファは、定義により、常に満杯になるので、プレゼンテーションバッファのメモリの動的に割り振られたサイズを、レベル比を示すときの水準として使用するのは意味がない場合がある。そうではなく、プレゼンテーションバッファのレベルは、プレゼンテーションバッファ中の未消費メディアデータの量を、プレゼンテーションバッファについての最大許容サイズで除算した比として測ることができる。
1. クライアントコンポーネントの概説
[0065]図1〜図2を再度参照すると、例示的クライアントの様々なコンポーネントが示されている。
[0065]図1〜図2を再度参照すると、例示的クライアントの様々なコンポーネントが示されている。
[0066]SCは、どのようなリプレゼンテーションが利用可能であるか、およびリプレゼンテーションのフラグメントが何であるかについての情報などのメタデータを追跡する。SCは、ネットワークを介して受信されたメディアデータのバッファリング、およびメディアプレーヤへのハンドオフも担う。SMは、どのようなリプレゼンテーションがどの時点でダウンロードされるべきかを決定すること、およびレート切替え決定を行うことを担う。最終的に、RAは、SCによって与えられる正確なURLおよびバイト範囲情報を所与として、メディアフラグメントのダウンロードを担当する。
[0067]SMは、レート切替え決定を担うソフトウェアコンポーネントである。SMの目標の1つは、所与の状況向けの最良のコンテンツを選び出すことである。たとえば、たくさんの帯域幅が利用可能である場合、高ダウンロードレートが達成され得るので、SMは、高レートリプレゼンテーションを選び出すべきである。ダウンロードレートが大幅に下落した場合、選ばれた高いリプレゼンテーションはそれ以上持続可能でなくなるので、SMは、条件により適した、より低いリプレゼンテーションレートに切り替えるべきである。SMは、プレイバックバッファを完全にドレインするのを避け(プレイバック失速を引き起こすので)、ただし同時にあまりに急いで、またはあまりに頻繁に切り替えようとはしないように、十分高速にレートを切り替えるべきである。さらに、ネットワークを通じてダウンロードし、失速することなくプレイバックすることができる、最も高品質のコンテンツを要求することを目指すべきである。SMは、意思決定プロセスにおいて、ダウンロード速度以外の要因を考慮に入れるように拡張することができる。可能性としては、リプレゼンテーション決定を行うときには、バッテリ寿命、ディスプレイサイズ、および他の要因などに配慮することができる。そのようなさらなる制約は、フィルタとしてSMに追加することができ、本明細書において記述する基本レート決定計算には影響しない。
[0068]典型的な高レベルのクライアント動作について、次に説明する。ユーザが、ライブのスポーツ放送、あらかじめ録画された映画、オーディオストリーム、または、ビデオおよびオーディオ以外のメディアタイプを伴い得る他のオーディオビジュアルもしくは他のコンテンツなど、特定のメディアコンテンツを要求すると想定する。クライアントは、その要求を、おそらくユーザインターフェースまたはコンピュータインターフェースを通して、SMに供給する。SMは、SCに対して要求を行い、どのリプレゼンテーションが利用可能であるか、どのp時間帯がどのフラグメントによってカバーされるか、およびリプレゼンテーション中の切替え点がどこにあるかについてのインジケーションを受信する。それに加え、SMは、後で説明するように、自由にできる短期ダウンロードレートについての何らかの情報を有することができ、RAは、このデータをSCに報告し、SCは、このデータをSMに報告または提供する。
[0069]SMは、その情報を、過去の履歴と一緒に使用して、持続可能レートを推定し、リプレゼンテーション内の適切な切替え点と、その切替え点において始まるそのリプレゼンテーションからダウンロードするべきメディアコンテンツの量とを選ぶ。ダウンロードが進行中であり、メディアコンテンツがプレイバックされるとき、SMは、供給された情報を使用して、レート切替えが順序通りであるかどうかを決定する。レート切替えが順序通りでない場合、SMは、現在のリプレゼンテーションからフラグメントをフェッチし続けるよう、SCに伝える。レート切替えが順序通りである場合、SMは、潜在的切替え点を見て、どのリプレゼンテーションにあるどのフラグメントが、所望の切替えを行うためにフェッチされる必要があるか決定する。SMは次いで、その情報をSCに渡す。SCとSMとの間のこの交換は、ダウンロードされるべきビデオの次のセクションに対する決定が行われるべきであるときはいつでも、定期的に行われる。良好な決定を行うために、SMはバッファレベルを監視し、いくつかのケースでは、SMは、バッファが十分に満杯であり、いかなるフラグメントも、ある程度の期間ダウンロードされる必要はないと決定し得る。
[0070]SMが、ダウンロードするべきフラグメントを決定すると、SCは、RAに、実際にフラグメントをダウンロードさせ、ダウンロードされたフラグメントをメディアバッファに保たせ、最終的に、メディアデータをプレイアウトする時間になったとき、メディアバッファ中のメディアデータをメディアプレーヤにハンドオーバさせるのを担当する。
[0071]SMはもはや、SCに、ダウンロードするよう伝えたフラグメントに能動的に関与していない。ただし、SMは、所与のフラグメントのダウンロードがすでに始まった後でも、考えを変え、以前発行したフラグメント要求を取り消すことができる。この機能は、ダウンロードレートが劇的に下落し、ダウンロードされているフラグメントが、メディアバッファが完全にドレインされた時間に、利用可能である見込みがなくなったケースにおいて有用である。その条件が起きた場合、SMはその条件を検出し、要求を取り消し、代わりにより適切なレートに切り替える。
[0072]SCは、SMから、フェッチするべきフラグメントハンドルを受信すると、対応するフラグメントのURLとバイト範囲とを、そのデータ構造中でルックアップし、それを使用して要求を作成し、その要求をRAにハンドオーバする。それはまた、RAから応答データを取り出し、受信メディアフラグメントを、再生可能なストリームに変換するのも担う。最終的に、SCは、MPDから取得したデータ、セグメントインデックス(sidx)ボックス、またはAppleのHTTPライブストリーミング(HLS)のケースでは、プレイリストなどのメタデータをパースし、追跡するのを担当する。
[0073]RAは、SCから受信したフラグメントおよびメタデータ要求を引き受け、対応するHTTP要求を作成し、それらをネットワーク接続を通じて送出し、対応する応答を取り出し、SCに返すコンポーネントである。ネットワーク接続は、インターネット接続、セルラーベースの接続、WiFi(登録商標)接続またはHTTP要求と応答とを扱うことが可能な他のネットワーク接続であることができる。ネットワーク接続は、単一デバイスの内部にあることができ、すなわち、デバイス内にすでにキャッシュされているメディアデータとの内部インターフェースであることができる。また、多くの組合せがあってもよく、すなわち、メディアコンテンツの一部は、ワイヤードインターネット接続から、一部はセルラーベースの接続を介して、一部はWiFi接続を介して、一部はローカルキャッシュからダウンロードすることができる。いくつかのケースでは、メディアデータがダウンロードされる接続は混合されてよく、すなわち、いくつかの部分はセルラーを介し、いくつかの部分はWiFiを介し、いくつかの部分はワイヤードを介するなどである。特定の要求は、いくつかの事例ではHTTP以外であってよいが、メディアコンテンツをサービスするサーバがHTTPサーバである場合はHTTPが好まれる。
[0074]その最も単純な形において、RAはHTTPクライアントである。ただし、RAは、一般的なHTTPクライアントより効率的であることが望ましい場合もある。RAの1つの目標は、十分に高いダウンロード速度を達成することであり、選択されたプレイバックメディアレートよりも大幅に速いダウンロードを目指すべきである。一方、未加工スループットのために適時性を損なわないように、慎重でもあるべきであり、すなわち、間もなくプレイアウトされるフラグメントは、さらに後にくる他のものよりも緊急であり、RAは、それらを時間内に受信しようと試みるべきである。したがって、適時性のためにある程度のスループットを犠牲にすることが必要となり得る。RAは、すべての妥当なネットワーク条件でうまく機能するように設計されるべきである。
[0075]RAの基本設計は、いくつかの接続と、最良の結果を取得するために、できればさらにFEC(前方誤り訂正)も使用するものである。したがって、RAは通常、2つ以上のオープンなHTTP接続を管理する必要がある。RAは、それらの接続に要求をディスパッチする。RAは、いくつかの状況において、要求を、より小さい要求のセットに分割する。対応する応答を受信すると、RAは次いで、データをコヒーレント応答にリアセンブルする。言い換えると、RAは、送出するべきHTTP要求の粒度と、どの接続に要求をディスパッチするべきかとを決定し、ソースフラグメントまたは修復セグメントのどの部分を要求するべきか決定する役目を果たす。それらの要求の粒度は、たとえばバッファレベル、要求の緊急度、利用可能な接続の数など、いくつかのことに依存し得る。
[0076]RAによって送出される各要求は、メタデータについての、またはSCによってRAにパスされたフラグメント要求の一部もしくは全部についてのHTTP要求である。ソースメディアデータまたはソースメディアデータから生成された修復データのいずれかについての要求でありうる。SCフラグメント要求から生成されたRA要求への応答は、ほとんどの場合、RAがフラグメント要求中のメディアデータすべてを再構築するのに十分なはずであり、RAは次いで、このデータをSCに返す。したがって、RAは、メディアフラグメント要求に関連付けられたRA要求からの応答を、SCに与えられるフラグメント要求への応答に逆アセンブルするのを担う。RAによるアセンブルは、たとえばFEC修復データについてのいくつかのRA要求がある場合、FEC復号を含み得る。
[0077]HTTP要求の管理に加え、RAは、短期の期間にわたる、すなわちある程度のサンプリングレートの時間スライスにわたるダウンロード速度を測定する。例示的サンプリングレートは100msであり、すなわち、RAは、100msの期間にわたってダウンロード速度を測定する。このデータは、SMによって、SMのダウンロード速度推定値を計算し、最終的にはレート決定を行うのに使用される。他のサンプリングレートも可能である。
[0078]RAは、DASHメディアプレゼンテーション記述(MPD)などのメタデータについても、セグメント構造についても知る必要はない。特定の実装形態において、RAは、HTTPスタック実装形態のいくつかの同時事例を使用して、いくつかの接続にわたって、いくつかのケースでは同様または異なるサーバへの異なるタイプの接続にもわたって、HTTP検索を実装する。
[0079]RAは、新規要求がいつ受諾され得るかをSCに知らせることを担う。SCは、SMに、要求するべき次のフラグメントを決定するよう求め、適切な要求をRAに与える。RAは、何らかのステータス情報も与える。RAは、短期ダウンロード速度と、ダウンロードに費やされる総時間とを、SCを経由してSMに定期的に与え得る。SMは、また、この情報について、SCを経由して間接的にRAをポーリングし得る。それに加え、RAは、各個々の要求がすでに完了された割合についてもSMに知らせる。この情報は、SMがそれを取り出すために呼び出すAPIを用いて同様に与えられる。
[0080]RAと、SCと、実際のメディアパイプラインとの間には、非常にタイトなデータフローがあるはずであり、RAまたはSC内にバッファリングされるデータは、(意図的なメディアバッファは別にして)可能な限り少ない。同じことが、様々な形のHTTP要求についても成り立ち、SMは、実際の対応するHTTP要求がネットワークを介して送出されるときよりも早く、わずかな時間量だけで、要求するべきフラグメントを決定しなければならないはずである。1つの理由は、SMが要求を事前に決定しなければならない程、その情報は正確でも最新でもなくなり、したがって、その決定はより低い品質となる。
[0081]SMは、発行されるべき要求を一度に1つ提出する。ただし、SMは、以前のすべての要求が完了されているわけではない場合にも新規要求を発行することができ、同時要求が許容される。SCは、SMが要求を発行した順序で、要求をRAにパスする。RAは次いで、同時処理を引き受け、受信データをSCに必ず返す。
[0082]同時要求により、RAは、HTTPパイプライン化を実装することが可能になる。実際、複数の接続を利用するRAでさえも、この方式に適合する。
1.1. ストリームマネージャ(SM)
[0083]SMは、ユーザのアクションと、ネットワーク条件と、他の要因との組合せに応じて、フラグメントをいつ要求すべきか、およびどのフラグメントを要求すべきかを決定する。ユーザがコンテンツを見始めると決定すると、SMは、ユーザによって、または提供されるサービスによって指定された、p時間から始まるそのコンテンツについて要求するべき第1のフラグメントを決定するのを担う。たとえば、いくつかのライブストリーミングサービスは、すべてのユーザが、メディアコンテンツの同じp時間部分を同じr時間に閲覧していることを要求し得るが、他のライブストリーミングおよびオンデマンドサービスは、どのp時間をどのr時間にプレイバックするかについて、柔軟性をエンドユーザまたはアプリケーションに認め得る。メディアバッファが満杯になると、SMは、さらなるフラグメント要求を与えるのを一時的にサスペンドする。SMは、ネットワーク条件およびたとえばディスプレイのサイズ、残存バッテリ寿命など、他の要因に依存して、p時間中の各時点においてコンテンツをどの品質でプレイバックするべきか決定するのを担う。
[0083]SMは、ユーザのアクションと、ネットワーク条件と、他の要因との組合せに応じて、フラグメントをいつ要求すべきか、およびどのフラグメントを要求すべきかを決定する。ユーザがコンテンツを見始めると決定すると、SMは、ユーザによって、または提供されるサービスによって指定された、p時間から始まるそのコンテンツについて要求するべき第1のフラグメントを決定するのを担う。たとえば、いくつかのライブストリーミングサービスは、すべてのユーザが、メディアコンテンツの同じp時間部分を同じr時間に閲覧していることを要求し得るが、他のライブストリーミングおよびオンデマンドサービスは、どのp時間をどのr時間にプレイバックするかについて、柔軟性をエンドユーザまたはアプリケーションに認め得る。メディアバッファが満杯になると、SMは、さらなるフラグメント要求を与えるのを一時的にサスペンドする。SMは、ネットワーク条件およびたとえばディスプレイのサイズ、残存バッテリ寿命など、他の要因に依存して、p時間中の各時点においてコンテンツをどの品質でプレイバックするべきか決定するのを担う。
[0084]SMが、フラグメント要求を提供するのが適切であると考えるとき、SMは、RAがフラグメント要求を受信および処理する準備ができている場合にしか要求を提供することができない。SCは、RAをポーリングすることによって、準備ができているときを決定し、この情報をSMにフォワーディングする。
[0085]RAが次の要求を受信する準備ができているときには、SMは、新規要求が発行されるべきかどうか決定し、要求するべき次のフラグメントを選ぶ。SMは、メディアデータについての要求を、一度に1つのフラグメントだけ行う。SMは、コンテンツの適時およびシームレスなプレイバックを可能にするフラグメントを要求するのを担う。リプレゼンテーション中のプレイバック変更は概して、切替え点においてのみ起こり得、2つの連続する切替え点の間に複数のフラグメントがあってよく、SMはその制約を尊重する。
[0086]概して、SMは、円滑なプレイバックのために時間内に受信されると信じることが妥当なフラグメントを要求することだけを試みる。ただし、ネットワーク条件が、時には非常に急速に劇的に変化しうることを考えると、このことは、すべての状況において保証されるわけではない。したがって、SMは、要求を取り消すことも可能である。SMは、輻輳が検出されるとともに、何のアクションもとられなかった場合に失速する危険性が大きい場合、要求を取り消す。失速とは、何のアクションもとられない場合、たとえば、フラグメント要求が発行された後間もなく、ネットワーク条件の悪化により、急激に、ダウンロードレートが突然下落する場合の可能性である。
[0087]SMは、最も直近の以前選ばれたフラグメントのリプレゼンテーション、すなわちRと、終了p時間、すなわちEとを追跡する。SMは通常、E’=Eという開始p時間を有する次のフラグメントを要求することを選ぶ。いくつかの変形体は、バッファレベルおよび現在のプレイバック時間から決定された開始時間を有し得る。
[0088]SMは、切替え点における潜在的重複が破棄された場合、円滑にプレイバックすることができるストリームを生成することを意図した、一連の要求を生成する。SMが要求を作り出す順序は、RAが要求を(必ずしも発行するわけではないが)優先するべき順序と同じである。この順序は、また、RAがSCに受信データを返し、SCがデータをプレイアウトするべきであるのと同じ順序でもある。
[0089]SMが、レートを切り替える必要があると決定した場合、一般的ケースでは、切替えのための2つのプロセスがある。1つのプロセスでは、SMは、E以下のp時間をもつ新規の(「switch−to」)リプレゼンテーション中の切替え点(「ランダムアクセスポイント」または「RAP」と呼ばれることもある)Pを探し、そのような点が識別されると、SMは、新規リプレゼンテーション中のフラグメントを要求し始める。第2のプロセスは、Eのものよりも後または等しいp時間をもつ切替え点Pを探すこと、およびPを超える終了時間をもつフラグメントが要求されるまで、古い(「switch−from」)リプレゼンテーション中のフラグメントを要求し続けることのうちの1つである。いずれのケースでも、切替えをSCにシグナリングすることが有用であり得る。
[0090]これらのプロセスは両方とも、いくらかの重複データがダウンロードされなければならない可能性があるという特性を有することに留意されたい。switch−fromリプレゼンテーションとswitch−toリプレゼンテーションの両方についてデータがダウンロードされる必要があり得る、p時間のストレッチがある。
[0091]これらの切替えプロセスのうちどちらが好ましいかは、状況に依存する。たとえば、ある特定の状況では、プロセスのうち一方についての重複が不当に大きく、他方については極めて短い場合がある。すべてのフラグメントが複数のリプレゼンテーションにわたってアライメントされ、すべてのフラグメントがRAPで始まる単純なケースでは、これらの切替えプロセスは、より簡単な方法に縮小し、この方法において、SMは、switch−fromリプレゼンテーションではなくswitch−toリプレゼンテーションに対して次のフラグメントを要求することによって切り替えるだけである。この場合、どの重複データもダウンロードされる必要はないことにも留意されたい。
1.1.1. SMフラグメント決定プロセス
[0092]このセクションは、どのフラグメントを要求するようSCに伝えるべきか決定するためのSMフラグメント決定プロセスについて記載する。これらの例では、単一リプレゼンテーショングループが仮定されるが、これらの例は、複数のリプレゼンテーショングループを使用するプロセスに対処するように拡張することができ、たとえば、ビデオリプレゼンテーショングループからビデオリプレゼンテーションを、およびオーディオリプレゼンテーショングループからオーディオリプレゼンテーションを選ぶ。
1.1.1. SMフラグメント決定プロセス
[0092]このセクションは、どのフラグメントを要求するようSCに伝えるべきか決定するためのSMフラグメント決定プロセスについて記載する。これらの例では、単一リプレゼンテーショングループが仮定されるが、これらの例は、複数のリプレゼンテーショングループを使用するプロセスに対処するように拡張することができ、たとえば、ビデオリプレゼンテーショングループからビデオリプレゼンテーションを、およびオーディオリプレゼンテーショングループからオーディオリプレゼンテーションを選ぶ。
[0093]SMによって選ばれる次のフラグメントは通常、前のフラグメント要求の終了p時間である開始p時間を有する。以下で、要求するべき次のフラグメントを選ぶための、SM内に実装することができるある程度の詳細な論理について説明する。
[0094]以下の例では、フラグメントが、RAPで始まり、リプレゼンテーションの間でアライメントされると仮定する。これが成り立たない場合、この記述の変形形態が可能である。それらの条件が存在する場合、SMのフラグメント決定は、レート決定に縮小し、すなわち、SMは、現在のリプレゼンテーションにとどまるべきか、それとも異なるリプレゼンテーションに切り替えるべきかを決定する。フラグメントが、複数のリプレゼンテーションにわたって必ずしもアライメントされず、RAPで始まらない、より一般的なケースでは、決定は同様であるが、切替えコストが高くなるので、このことを考慮に入れられる。
[0095]SMリプレゼンテーションプロセスは、2つの論理的に別個のプロセスを備え、第1のプロセスは、RAが与える短期サンプルから概算持続ダウンロードレートを計算するレートエスティメータであり、第2のプロセスは、この推定値を利用して切替え決定を行う決定プロセスである。
2. レート推定プロセス
[0096]適応ビットレートストリーミングクライアントは概して、正しいビットレートメディアを選ぶためのレート決定モジュールによって後で使用されるダウンロードレートエスティメータモジュールを使用する。この手法を用いると、ダウンロードレートが大きいとき、より高品質のメディアがストリーミングされ得る。ダウンロードレートの変化は、リプレゼンテーション切替えをトリガすることができる。レート推定値の品質は、ストリーミングクライアントの品質に対して大きな影響をもつ。
[0096]適応ビットレートストリーミングクライアントは概して、正しいビットレートメディアを選ぶためのレート決定モジュールによって後で使用されるダウンロードレートエスティメータモジュールを使用する。この手法を用いると、ダウンロードレートが大きいとき、より高品質のメディアがストリーミングされ得る。ダウンロードレートの変化は、リプレゼンテーション切替えをトリガすることができる。レート推定値の品質は、ストリーミングクライアントの品質に対して大きな影響をもつ。
[0097]適応ビデオストリーミングデバイスについての良好なレートエスティメータは、いくつかの特性を有するべきである。第1に、短期ダウンロードレートが大きく変わる場合であっても、分散はほとんどあるべきでない。第2に、基底チャネル(underlying channel)におけるレート変化に素早く適応するべきである。チャネルレートが大幅に下落すると、推定値は、その事実を素早く反映するべきであり、そうすることによってデバイスは、それに従って、失速することなく品質を調整することができる。それに応じて、ビデオ品質の向上が素早く観測されるはずであり、そうすることによってより良好な品質のコンテンツがフェッチされ得る。
[0098]それらの2つの要件を満足するには、トレードオフが求められる場合がある。通常、分散が小さいエスティメータは、大きい反応時間を有し、逆もまた同様である。たとえば、デバイス内で使用することができる単純なエスティメータを検討する。そのエスティメータは、何らかの固定Xについて、ダウンロードの最後のX秒にわたって移動平均をとる。大きいX、たとえば、X=30秒(s)を選び出すと、分散がほとんどない比較的平滑な推定値が得られるが、ダウンロードレート変化に対してゆっくりとしか反応しない。そのようなエスティメータがレート決定に使われた場合、結果として得られるプレーヤは、帯域幅下落に対して頻繁に失速し、またはそうすることが安全に可能であるときにより高いビットレートに適時に切り替えそこねる場合がある。これらの理由により、ある実装形態は、より小さなX、たとえばX=3sを選び出す場合がある。そのような選択は、はるかに迅速なレート調整をもたらすが、安定性を犠牲にする。レート推定値は大きく変わり、プレーヤはしたがって、ビデオプレイバックレートを非常に頻繁に変化させて、劣悪なユーザエクスペリエンスをまねきうる。
[0099]図5において、凹凸の多い曲線は、たくさんの短期ゆらぎをもつ、未加工ダウンロードレートである。レートエスティメータは、凹凸の多いダウンロードレートの平滑化バージョンである。レートが変化すると、新規持続レートに収束し、レートが変わらない限りは同様のままである。
[0100]所望の特性のうち1つは、バッファレベルがわずかな場合、調整は迅速であり、これがレートの高速適応を引き起こし、その結果、ダウンロードレートが下落中であるときには、調整前にプレゼンテーションバッファが空にならない。一方、メディアバッファ内にたくさんのメディアデータがある場合、レート推定値はより平滑であり、調整はより遅い。メディアバッファ中により多くのメディアデータがあるときには、プレイアウトレートは、ダウンロードレートが下落中であるときには、メディアバッファ中のメディアデータがより少ないときよりも、より長い時間期間、より高いままである傾向にある。
[0101]これ以降で提示するレート推定プロセスは、pker、pkerプロセス、またはpkerタイプのプロセスと呼ばれ、レート変化に迅速に反応するが、安定してもいるので、低い分散および高い反応性についての要件の両方を満足する。
2.1. pkerプロセス
[0102]このセクションは、本明細書においてpker、pkerタイプのプロセスまたは単に「pkerプロセス」と呼ばれるレート推定プロセスについて記載する。基本レートエスティメータは、その推定値を、そこからより長い移動平均を計算するためにある方法または別の方法を使用した、短期レート測定値にのみ基づかせる。上述した基本移動ウィンドウ平均(「MWA」)は、そのようなプロセスの一例である。
[0102]このセクションは、本明細書においてpker、pkerタイプのプロセスまたは単に「pkerプロセス」と呼ばれるレート推定プロセスについて記載する。基本レートエスティメータは、その推定値を、そこからより長い移動平均を計算するためにある方法または別の方法を使用した、短期レート測定値にのみ基づかせる。上述した基本移動ウィンドウ平均(「MWA」)は、そのようなプロセスの一例である。
[0103]図6〜図7は、レート選択目的で非適応(固定係数)指数加重平均を使用することの効果を示す。これらのプロットは、簡単のために、新規レート推定値が新規ダウンロード選択を直ちにトリガし(すなわち、フラグメントが比較的小さい)、新規レート選択は単にレート推定であると仮定する。
[0104]図6は、r時間態様を示す。図に示すように、x軸はダウンロード時間(リアルタイム)である。時間T1において劇的なレート増大が起こるとき、バッファは、非常に速く増大し始め、それは、ビデオデータがプレイアウトされるよりもはるかに速くそのビデオデータがダウンロードされているからである。EWMA推定値は、徐々に真のレートに収束する。
[0105]図7は、同じイベントのp時間態様を示す。図において、線702は、スクリーンに表示されるビットレートを示す。レートは、図6のr時間ピクチャにおけるよりもはるかにゆっくり適応する。r時間と比較した、p時間に対する収束の速度は、はじめはNR/ORの割合で減速される(プレーヤが、その時点で、ダウンロードの1秒当たりに約NR/OR秒分のビデオを受信したからである)。したがって、正味の効果は、メディアが、このタイプのレートエスティメータを使用するときには、多大な量のp時間についてのダウンロードレートよりもはるかに低いレートでプレイアウトできることである。
[0106]レートが、メディアをストリーミングする目的で推定される場合、エスティメータは、他の関連情報を利用することができる。特に、メディアプレーヤのバッファ、または一般的に、バッファリングされたまたはすでにプレイアウトされた各メディアセグメントをダウンロードするのにどれだけ時間がかかったかについての情報を含む、メディアプレーヤのダウンロード履歴(現在のバッファにあるものよりも過去にさかのぼる)が関心事である。
[0107]ある実装形態は、たとえば、MWAエスティメータを使用することができるが、メディアバッファに応じたウィンドウサイズを選ぶことができる。
[0108]メディアプレーヤのバッファレベルが高い場合、プレーヤは、ただちに失速する危険状態にはないので、大きいウィンドウを使用して長期推定値をとることができ、結果としてより安定した推定値になる。一方、バッファレベルが低い場合、プレーヤは急速に反応するはずであり、このことは、この場合に、より短い平均化ウィンドウがより良好な選択であることを示唆する。
[0109]したがって、レート推定プロセスの実装形態は、変化するウィンドウ幅を使用することができ、現在のメディアバッファ中のp時間の量(つまり、ダウンロードされ、まだプレイアウトされていない現在のp時間の量)に比例するr時間ウィンドウ幅を使用し得る。
[0110]別の実装形態は、メディアバッファに現在含まれるバイト数に比例するようにウィンドウ幅を選ぶことができる。
[0111]ある実装形態は、単にバッファのレベルではなく、バッファ自体のコンテンツを検査することもできる。たとえば、バッファの大部分が、その同じコンテンツのプレイバック持続期間よりもはるかに短い時間でダウンロードされたと決定した場合、このことは、ダウンロードバッファが急速に増大している最中であり、したがってレートエスティメータは、推定値が調整される必要があると結論づけ得ることを示唆する。
[0112]同様に、レートエスティメータは、バッファレベルの変更レートを追跡し、バッファレベルの高速変化を、レート推定値が急速に調整される必要があるというインジケーションとみなすこともできる。
[0113]図8〜図9は、可変ウィンドウサイズ加重移動平均(「WMA」)フィルタが使用されるときの、図6〜図7と同じシナリオにおける挙動を示す。この例では、「pker」プロセスは、そのような可変ウィンドウサイズWMAフィルタのように、プログラミングコードとして説明される。pkerプロセスは、プロセッサによって実行されるプログラム命令として実施することができる。
[0114]図8において、線802は、基底チャネルが、レートOR(古いレート)からレートNR(新規レート)への急激なレート増大を有する場合のpkerレート推定値である。レート選択が新規レートに適応するのにかかるr時間の量は、OR/NRに比例する。増大が大きい程、適応はリアルタイムで速く起こる。図に示すように、時間T2において、Buff@T2=2*Buff@T1およびTfast=OR/NR*Buff@T1である。
[0115]図9は、p時間におけるプレイバック挙動を示す。pkerエスティメータは、新規レートに適応するのに約1バッファ持続期間(レート増大が起きたとき、バッファ中にあったp時間の量)かかり、すなわち、pkerエスティメータは、メディアバッファが、p時間の持続時間Bがメディアバッファに追加された、メディアコンテンツの量を有するときには、新規レートに適応済みであり、ここでBは、新規レートまでのレート増大時におけるメディアバッファ中のメディアコンテンツのp時間の持続時間である。
[0116]上記を行う特定のプロセスについて、ここで説明する。このプロセスは、プレイバックバッファの最後のγT比分(γT-fraction)をダウンロードするのに、どれだけのr時間がかかったか決定し、ここでγTは適切に選ばれた定数である。たとえば、これは、現在のプレイバックバッファ全体(γT=1)をダウンロードするのにかかった完了時間であり得、またはプレイバックバッファの後半分(γT=0.5)をダウンロードするのにかかった時間であり得る。γT>1であることもあり得る。Tfastを、プレイバックバッファの最後のγT比分をダウンロードするのにかかったr時間の量とする。推定ダウンロードレートは、ダウンロード時間の前のTfast秒にわたるダウンロードレートを推定することによって計算されることができる。γTの他の値も可能であることに留意されたい。本明細書に記載するように、異なる値が、異なる目標に役立ち得る。
[0117]Tfast幅のウィンドウにわたるこの種類のウィンドウ化平均は、レート増大を迅速に検出するという、注目すべき特性を有する。実際、Tfastを決定するために値γT<1が使用される場合、エスティメータは、メディアバッファ中のメディアコンテンツのp時間の持続時間がBである特定の瞬間においてどれだけレートが増大する場合でも、レートエスティメータが増大したレートに収束する前にバッファが最大でもBの有限倍数まで増大するという特性を有する。
[0118]より精巧なレート推定方法は、上で言及した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時間にわたる平均よりも大幅に高くなる。
[0119]ここで、この構成に基づいて、pkerレート推定プロセスの例について詳細に説明する。このプロセスは、要求アクセラレータ(RA)などのダウンロードモジュールから取得することができる短期レート測定値と、バッファ情報とを使用して、推定値を計算する。バッファ情報は、短期レート測定値が有用な推定値になるためのウィンドウ幅を決定するのに使用される。
[0120]図10は、ダウンロードレートが急激に下落するとき、pkerレートエスティメータがどのように発展するかを示す。レートが下落するとすぐに、バッファレベルが下落し始める。レート推定値も、適応し始める。レート推定値は、遅くともバッファレベルが2分の1に下落したときには、新規レート(NR)に達する。この例では、中間レート決定が行われないので、Buffは線形に下落する。中間決定が行われる場合、Buffの降下は徐々に減速する。
[0121]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プロセスをレート増大に対して素早く反応させる。
[0122]本明細書に記載するように、Cという持続期間にわたるダウンロード速度を計算するために、SMは、RAによって定期的に与えられるダウンロード速度情報を使用する。その目的のために、SMは、RAによって与えられるダウンロード速度情報の履歴を維持し得る。平均がとられる持続期間は、ほとんどのγBバッファ持続時間にあり、このことが、メディアバッファレベルに対して上限があるときに、どれだけの履歴が維持される必要があるかを効果的に制限する。
[0123]選択されたプレイアウトレートがダウンロードレートにほぼ等しい場合、ストリームをダウンロードするのには、そのストリームをプレイアウトするのと同じ時間量だけかかるとすると、Tfast=γT・Bとなるので、バッファリング値Cは、バッファ持続期間程度であることに留意されたい。r時間中のバッファレベルの程度のものを選ぶことは、ダウンロードレート推定値についての平滑化間隔に対する当然の選択である、というのは、それは、ストリーミングクライアントが、失速を避けたい場合にもたなければならない見通し量だからである。
[0124]単純な一実装形態において、平均化ウィンドウ幅は、B、すなわちビデオバッファに含まれるp時間の量に比例する。そのような選択は、失速をうまく防ぐが、欠点がある。すなわち、ダウンロードレートが、選択されたメディアのレートのk倍である場合、毎秒のダウンロードの結果、p時間のうちk秒間分のメディアがダウンロードされ、レート推定を本当にゆっくり適応させることになる。たとえば、k=10であり、10秒間分のバッファがある場合、レートエスティメータは、適応する前にp時間のうち約k・10s=100s分をダウンロードするが、これは非常に長い時間である。このことが、pker方法へのTfastパラメータの導入の理由となる。実際、平滑化に指数加重移動平均が使用される場合、そのようなフィルタは無限インパルス応答を有するので、事態はある程度悪化し得る。この理由により、pkerプロセスは、代わりに有限インパルス応答フィルタを使用する。プレーンな移動平均は機能するが、一実装形態は、また、より精巧な加重移動平均を使用し得る。
[0125]図13は、この最後の点を示す。この図は、単純(固定幅)移動ウィンドウ平均と指数加重移動平均の比較を示す。グラフは、レート変化が見られるときには、固定ウィンドウ移動平均が最初によりゆっくりと新規レートに収束し得るが、1つのウィンドウ持続期間中に収束することを示す。指数加重移動平均は、はじめは急速に動く傾向があるが、後の段階では、ゆっくりと収束するだけである。ウィンドウ化移動平均とは異なり、固定ウィンドウ内では収束しないが、代わりに、レート変化のマグニチュードの対数の時間をかけて収束する。
[0126]γB=1およびγT=0.5なので、pkerプロセスは、様々な保証を与え得る。1つには、ダウンロード速度がどれだけ下落した場合でも、推定値は、バッファがその元の持続期間の半分に縮むのにかかる時間内に新規ダウンロード速度に調整される。もう1つには、ダウンロード速度がどれだけ増大した場合でも、追加のp時間に値する多くとも1つのバッファが、pkerプロセスが新規レートに収束する前にダウンロードされる。直接的な算出は、同様の固定比保証が、0<γBおよび0<γT<1のどの選択にも成り立つことを示す。
[0127]バッファレベル、すなわち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にあるように定義する。
[0128]式1の結果から全体的Tp値を計算するために、DASHクライアントは、MPD(メディアプレゼンテーション記述メタデータ)から決定される、各グループの重みづけ因子、すなわちw’と、リプレゼンテーショングループの数、すなわちGとを考慮し、式2の計算を実施する。バッファレベルBはこれで、B:=Tp−Tと定義される。
[0129]式2は、現在プレイアウトされているフラグメントに属するバッファの部分も取り込む。この定義は、いくつかのフラグメントが一度にダウンロードされる場合にも機能することに留意されたい。
[0130]Tfastを計算するために、一般的ケースにおいて、SMは何らかの履歴を維持する。Trを、RAがメディアをダウンロードする(ダウンロードしようとする)のに費やしたr時間の総量とし、Zを、RAによってダウンロードされたバイトの総量とする。Trの値は、RAによって計算される。SMは、i=1,2,…,Kについて規則的な間隔で(たとえば、100msおきに)サンプリングされたタプル
の履歴、すなわちHを維持し、ここで第Kの観察が最後の観察である。履歴は観察順に記憶されると仮定するので、
ならびに
および
となる。
[0131]ここで、Tfastを計算するために、Bは、上に挙げた方法ですでに計算されていると仮定する。次いで、RAは、たとえばバイナリサーチで履歴をサーチすることによって、式3の不等式が満たされるようにjを決定する。
[0132]すると、
となる。無限履歴をずっと維持する必要はなく、最大バッファ持続期間のγB分を超えて広がるTi値についてだけで十分である。
[0133]図15は、図16の拡大版とともに、pkerプロセスによって使用される値BおよびTfastが、記録された(Tp,Tr)値の履歴からどのように決定され得るかを示す。この図は、r時間およびp時間が等しく高速に進行し(ダウンロード割込みはない)、したがってプレイバック時間(p時間)が、ダウンロード時間(r時間)の45度の傾斜線であるケースを示す。(Tp,Tr)値の履歴はグラフ中にプロットすることができ、プレイバック失速が起こらない場合、厳密にプレイバックタイムラインの上にある曲線が得られる。バッファレベルBはしたがって、プレイアウト時間に対する最後の記録されたTp値の差である。Tfastの値は、現在の(最後の)Tp値を下回るγT・Bのレベルでの、(Tp,Tr)曲線までの水平距離を測定することによって、このグラフ中に見ることができる。
[0134]図11は、図15〜図16と同じ種類のプレゼンテーションを使用して、レートの急上昇に対するpkerプロセスの反応を示す。Tfastは、プレーヤがまだ反応していない急上昇を受信レートが受けたときには、比較的小さい。これは、高受信レートに対する高速反応を示す。平均化ウィンドウは、比較的狭いので、完全にグラフの高レート部分内にあることに留意されたい。したがって、この時点で、pker推定値は、より長いレートにすでに収束している。
[0135]図12はやはり、図15のプレゼンテーションを使用して、レート下落に対する可変ウィンドウサイズWMAフィルタ(たとえば、pker)反応を示す。この場合、Tfastは比較的大きくなるが、バッファがドレインするので、Bは小さくなり、ある程度のドレイン時間の後、平均化ウィンドウを、完全に低レートエリア内に収まらせる。図に示すように、平均化ウィンドウの幅、すなわちBは、BがTfastよりも小さくなるようなものであるが、推定値は依然として、バッファが完全にドレインされる前に、より低い新たなレートに収束する。
[0136]図14は、pkerレート推定プロセスのフローチャートである。
[0137]TfastおよびBの値が計算されると、Cの値が容易に続き、最後のステップは、持続期間Cの過去のウィンドウにわたるレートRを計算するものである。その目的のために、履歴中のZiおよび
値が使用される。
[0138]間隔Cにわたるレートを計算するために、SMまたはRAは、以下のことを行う:(1)
となるような最も大きいjを見つけ、次いで、(2)式4にあるように平均ダウンロードレートを計算する。そのようなjが第1のステップにおいて存在しない場合、SMまたはRAは、j:=0、すなわち、最も古い既知の観察結果を設定する。jの値は、バイナリサーチによって効率的に決定することができる。
[0139]各グループは、そのグループが消費すると予想される総帯域幅の割合に対応する関連付けられた重み、すなわちwを有する。これは、好ましくは非使用可能リプレゼンテーションがフィルタ除去された後の、MPDによって与えられる情報の関数である。本明細書において、グループgの重みwの提案される定義は、w(g):=maxrate(g)+minrate(g)であり、ここで、maxrate()は、グループg中の最大プレイバックレートであり、minrate()は、最小プレイバックレートである。
[0140]重みwから、SMまたはRAは、標準化重みw’を次のように計算することができる。クライアントが、グループ1,…,Gをストリーミングしたいと想定すると、標準化重みは、式5にあるように、すべての重みの合計で除算された重みである。
[0141]標準化は、実際にストリーミングされる重みにわたって行われることを意図している。たとえば、ストリーミング中ではないグループがある場合、そのグループは考慮されるべきでない。
[0142]このpkerプロセスの動作において、いくつかの仮定が行われる。たとえば、個々のリプレゼンテーショングループのバッファレベルは、互いに比較的近く保たれるべきである。pkerプロセスは、そうすることによってより良好に機能する。たとえば、あるグループが、非常に大きいバッファを有し、別のグループは非常に小さいバッファを有し、両方が同様の重みを有すると想定する。そのようなケースでは、小さいバッファにとっては条件が変わったときに失速を避けることが必要なので、レート推定値の迅速な調整を行うことが必要となる。しかし、pkerプロセスは依然として、その推定値を、はるかに大きいバッファ向けに作用しているかのように満足に平滑化する。逆に、より大きいバッファにとっては、測定値は、バッファレベルが許容する、ある程度高い分散を有するので、ナーバスなレート決定となる。
[0143]いくつかのケースでは、バッファレベルが大きく相違するリプレゼンテーショングループを有することは不可避である。この理由により、別の実装形態は、いくつかのバッファが非常に小さいときに、より迅速にレートを調整し、したがってそのようなケースにおいてビットを失速からより良好に保護する、pker方法の変形体を使用することができる。そのような実装形態は、以前と同じようにTfastを計算することができるが、ウィンドウサイズをC=max(STP,min(Tfast,Tp,1−T,Tp,2−T,…,Tp,N−T))に設定する。
[0144]これらのダウンロードレート推定の他の変形体は、各リプレゼンテーショングループについての独立pker推定値を使用して、そのグループについて決定を行うことを含む。
3. フェッチング戦略
[0145]ストリーミングビデオプレーヤは概して、制限付きメディアバッファを有する。したがって、通常動作において、最終的にはバッファ満杯状態に達し得ると予想される。バッファが満杯状態に達すると、ストリーミングモジュールは、バッファのオーバーフィリング(overfilling)を避けるために、メディア入力を抑える(throttle)べきである。これを行うための容易な方法は、バッファが満杯になったときは常に、バッファが次のフラグメントを保持することができるのに十分にドレインされるまで待ち、次いで、フェッチングを再開することである。
[0145]ストリーミングビデオプレーヤは概して、制限付きメディアバッファを有する。したがって、通常動作において、最終的にはバッファ満杯状態に達し得ると予想される。バッファが満杯状態に達すると、ストリーミングモジュールは、バッファのオーバーフィリング(overfilling)を避けるために、メディア入力を抑える(throttle)べきである。これを行うための容易な方法は、バッファが満杯になったときは常に、バッファが次のフラグメントを保持することができるのに十分にドレインされるまで待ち、次いで、フェッチングを再開することである。
[0146]この方法の効果は、各フラグメントが個々にフェッチされ、各フラグメント要求の間に時間ギャップがある、すなわち、次のフラグメントが収まり、要求され得るように、バッファから十分ドレインするのにかかる時間量があることである。
[0147]TCPプロトコルは、そのダウンロードレートを、現在のネットワーク条件に基づいて自動調整する。TCP接続を介してダウンロードが開始されたときには、初期ダウンロードレートは、通常、非常に遅く、より高いダウンロードレートを達成することができるかどうかをTCPプロトコルが調べると増大する。どれだけ高速にTCPがダウンロードレートを増大させるか、およびTCPが概してエンドツーエンドのTCP接続のプロパティにどのように反応するかは、極めて複雑であり、固有のエンドツーエンドのネットワークレイテンシ、TCP配信および確認応答経路に沿ったネットワーク要素のバッファ容量、これらの経路に沿った競合トラフィック、TCPのどのような変形体が使用されるかなどを含む、いくつかの因子に依存する。概して、TCPは、遅いダウンロードレートで始まり、そのダウンロードレートを時間とともに増大させ、したがって、ダウンロード時間全体にわたるTCP接続の平均ダウンロードレートは、ダウンロード時間全体が相当なものであるときの持続可能TCPダウンロードレートに近づくだけである。たとえば、持続可能TCPダウンロードレートが1メガビット/秒であり、TCP接続が、事実上ゼロのダウンロードレートで始まり、時間とともに1秒間にわたって1メガビット/秒まで線形に増大した場合、最初の1秒にわたる平均ダウンロードレートは500キロビット/秒であり、平均ダウンロードレートが持続可能ダウンロードレートの95%を達成するには、10秒間のダウンロードが必要である。この理由により、要求の間の多くのダウンローディングギャップを有するフェッチング戦略は理想的ではなく、ダウンロードギャップは、あるダウンロード要求の完了と、次のダウンロード要求の開始との間の時間期間である。ダウンロード要求の間のギャップがゼロであるときでも、通常、TCPは、前の要求の完了の後、次の要求のためにダウンロードレートを増加させるのにある程度の期間かかるので、理想的ではない。各ギャップの後、持続可能スループットは再び達成されなければならない場合があり、これにより達成される全体的な平均ダウンロードレートが低減される。
[0148]そのような低減されたレートは、より小さいレート推定値をまねき、したがってより小さいメディアレートの選択をまねき得る。その結果、通常、(バイトでのサイズが)より小さいメディアフラグメントがダウンロードされることになり、これによりギャップの相対的な大きさがさらに増大し、より一層小さいプレイバックレートが選択されることになり得る。言い換えると、その効果は自己増幅型である。
[0149]したがって、DASHクライアント実装形態が、この問題の影響を最小限にするプロセスを使用することが有利である。
[0150]ある実装形態は、メディアデータを絶え間なくダウンロードし、次いで、バッファレベルを次のように定期的にドレインすることができる。要求されたがまだプレイアウトされていないp時間の量が、あらかじめ設定された高いウォーターマーク、すなわちMhを超える場合はいつでも、SMは、バッファレベルが低いウォーターマークMlを下回るまで、いかなる要求もそれ以上発行しない。特定の実装形態では、Mh=20秒およびMl=10秒であるが、他の実装形態では、それらの値はより低くてもより高くてもよい。低いウォーターマークを下回った後、通常動作が再開され、SMは、フラグメント決定を再び発し始める。
[0151]別の実装形態は、プレゼンテーション時間ではなくバイトで指定されたウォーターマークを使用して、同様の効果を達成することもできる。
[0152]バッファが定期的にドレインしているという事実は、システムの他の部分によって、有利に利用することができる。たとえば、セクション6.1.2で説明するように、RTTの最新の推定値を取得するのに利用することができる。
[0153]図17は、「ウォーターマーク」フェッチングプロセスの挙動を示す。上のグラフは、ドレイン期間とフェッチング期間の交替パターンが見られるバッファレベルグラフである。ダウンロードレートは、下のグラフに表示されている。各フェッチング期間の最初において、TCPは、持続可能最大速度になるのにある程度の時間をかけるので、(フェッチング期間中の)平均ダウンロードレートは、最大達成可能ダウンロードレートよりも小さい。低いウォーターマークと高いウォーターマークとの間の差が大きいほど、フェッチング期間が長くなり、平均レートが高くなる。
4. レート選択プロセス
[0154]メディアデータを要求し始めるとき、ストリーミングモジュール(SM)は、何らかの方法を使用して、第1のプレイアウトレート選択を行う。SMは、最も低い利用可能レートをとる場合もあり、あるいは、たとえば、ネットワーク条件の履歴を維持し、次いで、この履歴に基づいて、失速なしで持続される可能性が高い、選ぶべきプレイアウトレートの推定値を決定する場合もある。SMが、すでにデータを受信中であり、したがって自由にレート推定値R(たとえば、セクション2にある方法で計算されたレート推定値のうちの1つなど)を有するとき、SMは、そのレートのまま続けるか、それともリプレゼンテーションを変えるかの決定を行う。
[0154]メディアデータを要求し始めるとき、ストリーミングモジュール(SM)は、何らかの方法を使用して、第1のプレイアウトレート選択を行う。SMは、最も低い利用可能レートをとる場合もあり、あるいは、たとえば、ネットワーク条件の履歴を維持し、次いで、この履歴に基づいて、失速なしで持続される可能性が高い、選ぶべきプレイアウトレートの推定値を決定する場合もある。SMが、すでにデータを受信中であり、したがって自由にレート推定値R(たとえば、セクション2にある方法で計算されたレート推定値のうちの1つなど)を有するとき、SMは、そのレートのまま続けるか、それともリプレゼンテーションを変えるかの決定を行う。
[0155]単純なレート決定プロセスについて、ここで説明する。受信機は、推定ダウンロードレートRよりも低いプレイバックレートをもつ最も高い帯域幅リプレゼンテーションを決定し、データをプレイアウトする(プレイバックする)ためのリプレゼンテーションとして選び出す。直接的ではあるが、この手法には、いくつかの問題がある。第1に、その手法は、当然ながら、小さいメディアバッファを増大させないので、ダウンロードレートがほとんど変わらないときでも、失速を受けやすい。第2に、変動する推定値Rは、急速に変化するレート決定をまねき、これは、必要ではない場合があり、視覚的に邪魔になり得る。第3に、少なくともおおよそフラグメントの持続期間、したがって一般的に数秒の、スタートアップ時間につながる。
[0156]DASHクライアントはしたがって、そのレート決定を、ダウンロード推定値Rだけではなく、バッファレベルB(つまり、バッファリングされ、まだプレイアウトされていないp時間の量)、および概して2つの連続する切替え点の間のp時間の持続時間の推定値である変化レートDなどのコンテンツに依存する変数にも基づかせる、レート決定プロセスを実装することができる。
[0157]したがって、一実装形態は、決定レートとして、Rに比例する最も大きいプレイバックレートを選び出せばよく、ここで比例因子はバッファレベルの関数である。
[0158]通常、比例因子λは、バッファレベルの増加関数である。ある実装形態は、λを、たとえば、バッファレベルのアフィン関数にすることができる。
[0159]λがバッファレベルの関数である場合、ある実装形態は、バッファが空または小さいときには小さくなるようにλを選ぶことができる。そのような選択は、小さいバッファを増大させ、ダウンロードレートが正確に予測されないときに失速に対するある程度の安全性も与えるので、有利である。
[0160]より大きいバッファレベルの場合、ある実装形態は、1に近い、1に等しい、または1を超えるλの値を選ぶことができる。こうすることにより、失速する即時の危険性がないときには確実に高プレイアウトレートがダウンロードされるために選ばれることになり、定常状態において高品質メディアがストリーミングされることになる。
[0161]レート決定プロセスは、単なる単純なアフィン関数ではなく、Bの区分的アフィン関数であるλを実装することができる。区分的アフィン関数は、任意の連続関数を、任意の所望の程度の精度まで概算することができ、そうすることにより連続関数が適切な選択となる。代わりに、同じプロパティをもつ、他の任意のパラメータ化可能クラスの関数が選ばれることもできる。
[0162]別の実装形態は、λを、p時間で表されるバッファレベルではなく、バイトで表されるバッファレベルの関数にすることもできる。
[0163]さらに別の実装形態は、λを、バッファレベルBだけではなく、バッファレベルBと切替え機会の頻度の両方の関数にする。そのようにする理由は、レートを変える機会がより少ないプレーヤが、変える機会がより頻繁なものよりも、さらに今後は各決定に関わるからである。したがって、前者のケースでは、各決定は、より大きいタイムスパン、およびより高い危険性への関与である。このことは、バッファレベルBと推定ダウンロードレートRが同じであるとき、失速する危険性を小さく保つために、後者よりも前者のケースではより低いレートを選び出す方がよいであろうということを示唆する。
[0164]レート切替え機会の頻度を考慮に入れるレート選択プロセスのための具体的方法は、次のようになる。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の小さい倍数とすることができる。
[0165]上述した方法など、そのレート決定を単にλ・Rに基づかせるプロセスには、Rの比較的小さい変動でさえも、多くのレート切替えをまねき得るという欠点がある。これは、望ましくない場合がある。十分なバッファがあるときには、Rの小さな変化には直ちに反応せず、それに応じてバッファレベルを変わらせる方がよい場合がある。
[0166]そのような挙動を得るために、プロセスは、両方とも同じ量(たとえば、上で説明したように、B、B/DまたはB/max(100ms,D))の関数である値λおよびμを使用することができ、これらの値は、現在のレートとともに、新規レート決定を選び出すためのものである。これらの関数は、λ・Rが低い許容可能レート選択となり、μ・Rが高い許容可能レート選択となるように選ばれるべきである。プロセスは次いで、それら2つの値を良好なレート決定のためのガイドとして使用するように設計され得る。
[0167]そのような設定において、関数は、概してλ≦μとなるように選ばれるべきである。
[0168]レート決定プロセスは、前の選択がすでにλ・R〜μ・Rの範囲内だった場合、レートを同じに保つことを決定し得る。前の選択がλ・R未満の場合、λ・R以下の、最も大きい利用可能プレイバックレートが選択される。前の選択がμ・Rよりも大きい場合、μ・R以下の、最も大きい利用可能プレイバックレートが選択される。
[0169]ある実装形態は、関数λおよびμがハードコードされることを選ぶことができる。あるいは、状況に応じて、より入念な方法で関数を選択することもできる。具体的には、一実装形態は、クライアントが最大限で行うバッファリングの量に応じて、適切なλおよびμ関数を選択することができる。オンデマンドコンテンツの場合、クライアントは、たくさんのデータ、可能性としては数分間分のメディアデータをプリバッファリングすることを選ぶことができる。低遅延ライブコンテンツの場合、クライアントは、多くとも、おそらく数秒間のみの、エンドツーエンドのレイテンシによって規定されるメディア量をバッファリングしさえすればよい。バッファリングがほとんどないコンテンツの場合、クライアントは、よりコンサバティブ(conservative)な、すなわち、より小さい値を有する、λおよびμ関数を選び出すと決定し得る。
[0170]具体的実装形態は、たとえば、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)が使用される。
[0171]ここで、上記記述にしたがう、レート決定プロセスの詳細な例を挙げる。このために、いくつかの表記法を採り入れる。
[0172] 1)S1,S2,…,SLを、リプレゼンテーショングループの(昇順で与えられる)L個の利用可能リプレゼンテーションのストリームレートとする。
[0173] 2)λ(x)を、負でないスカラーを入力としてとり、負でない実スケーリング係数を戻す区分的一次関数とする。関数λ(x)は、コンパイル時に、または構成ファイルにより設定可能であるべきである。大きいxについて、たとえば、Mlよりも大きいxについて、λ(x)は不変であるべきである。
[0174]ここで、そのような関数がどのように実装され得るかについての一例を挙げる。端点(0,λ0),(x1,λ1),…,(xN,λN)が与えられ、ここでxiは昇順である。λ(x)を評価するために、xi≦xであるような最も大きいiを見つける。次いで、式6を使用して、受信機はこの関数を評価することができる。
[0175]そのようなλ(x)関数についての適切な例は、例示的パラメータN=1、[(0,0.5),(3,1)]によって定義されるもの、つまり、x=0において0.5に等しく、xが3に達するまで線形に増大する関数であり、xが3に達した時点で、関数は1に等しく、その後は1のままである。
[0176] 3)μ(x)を、別のそのような区分的一次関数とする。そのような関数の一例は、x=0において0になり、x=3において1.5に達し、その後は一定のままであるものである。
[0177] 4)Dを、(以前指定された)ある切替え点から次の切替え点までのp時間における持続期間の推定値とする。
[0178] 5)x:=min{(Td−T),Ml}/max{D,1秒)とし、ここでTは現在のプレイバックp時間であり、Tdは、レート決定が行われるp時間であり、Dは、上に挙げた通りであり、Mlはバッファレベル低マーク(セクション3参照)である。
[0179] 6)CURRを、現在選択されているリプレゼンテーション(すなわち、最後のフラグメント要求において使われたもの)とする。UPを、レートが最高でもλ(x)・Rである最も高いビットレートリプレゼンテーションのプレイアウトレートとし、そのようなリプレゼンテーションがない場合、UPは、最も低いビットレートリプレゼンテーションのプレイアウトレートである。DOWNを、最高でもμ(x)・Rのレートの最も高いビットレートリプレゼンテーションのプレイアウトレートとし、そのようなリプレゼンテーションがない場合、DOWNは、最も低いビットレートリプレゼンテーションのプレイアウトレートである。概してλ(x)≦μ(x)なので、概してDOWN≧UPである。
[0180]次いで、レート決定プロセスは、次のフラグメントのレートNEXTを次のように選び出す。(1)UP<CURRの場合、NEXT:=min(DOWN,CURR)であり、(2)それ以外の場合、NEXT:=UPである。
[0181]上のステップ5で単にDではなくmax{D,1秒}を使用する理由は、RTTゆえであり、1の役割は、RTTの上限として作用することである。
[0182]関数λ(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すべてについてバッファ増大が保証されることに留意されたい。
[0183]より簡単なプロセスは、λ(B)・R未満のプレイバックレートをもつ最良リプレゼンテーションとなるように、新規リプレゼンテーションを直接選び出してよい。このリプレゼンテーションは、バッファが空になりそうなときに、バッファは満杯になる傾向にあるというプロパティを依然として有する。ただし、Rは大きく変動し得るので、たくさんのリプレゼンテーション切替えも引き起こす。本明細書において記述する、より洗練されたレート選択プロセスは、切替えを避けようとし、代わりに、より低いプレイバックレートに切り替える前に、バッファをある程度までドレインさせる。これが機能するためには、関数μおよびλは、中間から大までのバッファレベルについて、μがλを超えるように選ばれるべきであり、ここで、選択されたプレイバックレートがCURRであり、測定されたレートがRである場合、式7が満足される限りレート変化は起こらず、レート切替えなしで受信レートをある程度変動させることに留意されたい。
[0184]いくつかのバージョンでは、λおよびμは単に、比B/max{D,1}ではなくバッファレベルBの関数である。後者を導入する動機は、次のようになる。
[0185]αを、選択されたリプレゼンテーションのプレイバックレートと、ダウンロードレートとの比を示すものとする。良好なαを決定することが望まれる。次の切替え点までダウンロードするのに、ほぼα・Dのr時間だけかかる。受信データがバッファに追加されるすぐ前に、バッファは、B−α・Dまでドレインされている。失速を避けるために、その量を正にしたいが、セーフティクッションとして、それは、ダウンロードされると、バッファに追加されるフラグメントのプレイバック持続期間Dに比例するべきであるので、あるβ>0について、少なくともβ・Dであるべきである。要するに、B−αD≧β・Dとしたい。
[0186]αの値を求めると、B/D−β≧αが得られる。これは、リプレゼンテーション選択プロセスが、B/D−βを超えない、プレイバックとダウンロードレートの比を選ぶべきであることを示唆する。関数λ(x)およびμ(x)は、許容可能なそのような比に対する限度であるので、x−βを超えないx=B/Dの関数であるべきである。
[0187]実際には、1つのフラグメントを送信する、RTTの追加コストを考慮に入れるために、B/Dを、B/max{D,1}で置き換える。より一般的には、1は、RTTの近似のある程度の倍数、またはサーバからメディアデータのダウンロードを開始するためのプロセスの反応時間を考慮に入れる他のパラメータで置き換えることができる。
[0188]図18は、プレイバックレートを選択するのに使用され得るλ関数およびμ関数の例を示す。x軸は、Dの単位で表したバッファレベルであり、y軸は、受信比(receive fraction)、すなわち、プレイバックリプレゼンテーションレートを現在の受信またはダウンロードレートで除算したものである。線1802によって図に示すように、受信比が1未満の場合、バッファは増大し、1よりも大きい場合は縮む。3つのエリアが識別される。第1に、プレーヤは、決定点においてλ曲線1804を下回る場合、高いレートに切り替える。λ曲線1804とμ曲線1806との間である場合、選択されたレートのままである。μ曲線1806を上回る場合、低いレートに切り替える。
[0189]図19は、「コンサバティブ(conservative)」設定を使用する、(λ,μ)関数の例示的選択を示す。この設定は、利用可能な帯域幅すべてを使用するわけではないが、引き換えに、非常にまれにしか失速しないという点で「コンサバティブ」である。
[0190]図20は、「中間(moderate)」設定を使用する、(λ,μ)関数の例示的選択を示す。この設定は、コンサバティブ設定よりも多い帯域幅を使用するが、わずかに失速しやすいという点で「中間」である。
[0191]図21は、「アグレッシブ(aggressive)」設定を使用する、(λ,μ)関数の例示的選択を示す。この設定は、利用可能帯域幅をすべて積極的(aggressively)に使おうとするという点で「アグレッシブ」である。この設定は、他の2つの提示した例示的設定よりも頻繁に失速し得る。
[0192]図22は、MLBプロセス、すなわち、米メジャーリーグ(MLB)で働いている何人かの研究者によって提案されたものと同様のプロセスをある程度までエミュレートするためのプロセスを使用する、(λ,μ)関数の例示的選択を示す。(λ,μ)関数は、メディアバッファ充満度に基づいて変わるのではないことに留意されたい。
[0193]図23は、λ設定およびμ設定用の隣り合っている値の例を示す。
[0194]図24は、λ設定およびμ設定用の隣り合っている値の例を示す。
[0195]図36は、レート選択においてλおよびμに使用することができる値のテーブルを備える。
[0196]図25は、レート推定、次いでレートベースのレート選択、次いでバッファ管理ベースのレート選択のためのプロセスを示す。この例示的プロセスにおいて、本明細書において記述する手法のうち1つまたは複数が、レート推定を実施するのに使用される。その推定値に基づいて、新規プレイバックレートが選択され、バッファ管理ルールに基づいて調整されることが可能である。
5. 要求取消し
[0197]いくつかのケースでは、優れたレート選択プロセスでさえも、単独ではビデオプレイバックの失速を防止することができない。たとえば、要求が行われた後であるが完了される前に、ダウンロードレートが急激に下落した場合、選択されたビットレートは大きすぎた可能性があり、遅いダウンロードレートは、プレイバックレートを変えるための次の切替え機会に達する前であってもプレイバック失速につながり得る。
[0197]いくつかのケースでは、優れたレート選択プロセスでさえも、単独ではビデオプレイバックの失速を防止することができない。たとえば、要求が行われた後であるが完了される前に、ダウンロードレートが急激に下落した場合、選択されたビットレートは大きすぎた可能性があり、遅いダウンロードレートは、プレイバックレートを変えるための次の切替え機会に達する前であってもプレイバック失速につながり得る。
[0198]別の例として、たとえば、セルラー接続からWiFi接続への移行により、利用可能帯域幅が劇的に増大するときには、メディアバッファは、比較的低いプレイバックレートメディアで満杯になり得る。この場合、すでにダウンロードされたがまだプレイアウトされていないメディアの大部分を破棄し、破棄されたp時間部分を再度ダウンロードするが、今度はダウンロードするべきより高いプレイバックレートリプレゼンテーションを選ぶことが有利であり得る。したがって、すでにダウンロードされた低プレイバックレートメディアは取り消され、別のリプレゼンテーションからのより高いプレイバックレートのメディアが、プレイアウトされるべき場所にダウンロードされるので、より高品質のユーザエクスペリエンスがもたらされる。
[0199]この理由により、ストリーミングモジュール実装形態は、ダウンロードレートを監視するモジュールを実装することができ、いくつかの状況では以前の決定を取り消し得る。要求が取り消された場合、ストリーミングモジュールは、ダウンロードレートのより新しい、より適切な推定値に基づいて新規要求を発行するべきである。この監視モジュールを、本明細書では要求取消しプロセスと呼ぶ。
[0200]要求取消しプロセスは、様々な理由で要求を取り消すことができる。たとえば、ダウンロードレートが激しく下落し、プレイバックが、データが十分高速に受信されていないことにより、失速する危険があるという理由で、要求を取り消すことができる。取り消す別の理由は、プレイバックのために時間内により高品質のメディアが選択され、取り出され得ると決定された場合である。取り消すさらに別の理由は、受信機が何をしたか、および保留要求の完了の許容に対して取消しが失速期間を短縮するかどうかという推定にかかわらず、失速が起こると受信機が決定した場合である。受信機は次いで、可能性としてはプレイバックされるべきメディアリプレゼンテーションの品質も考慮に入れて、推定されたより短い失速とともに進むアクションを選ぶ。当然ながら、失速があるかどうか、および失速がある場合には失速の持続期間は、推定とは異なり得る。
[0201]実際の取消しは、取消しが決定された後には、要求がその上で発行されたTCP接続をクローズすることによって達成することができる。クローズは、取り消されたフラグメントについてのデータを送り続けないようサーバに伝えるという効果を有し、したがって、クローズされた接続によって使用される帯域幅が、置換えデータをフェッチするために利用可能になる。
[0202]ストリーミングモジュールは次いで、取り消された部分を置き換えるための要求を発行することができる。この目的のために新規TCP接続をオープンすることが必要な場合がある。
[0203]ある実装形態は、置換え要求を選ぶいくつかのオプションを有する。どれが最も適切なオプションであるかは、プレイアウトされているコンテンツのタイプに依存し得る。
[0204]それは、ストリームのシームレスなプレイバックを可能にする置換え要求を選び出そうとする場合がある。一般的ケースでは、このことは、置換え要求が、前のダウンロードされたフラグメントの終了時に、またはその前に、切替え点をもたなければならないことを意味する。
[0205]その場合、プレーヤは、取消しなしでダウンロードを続けるときに失速が予測され、置換えセグメントの取消しおよび選択を用いると失速を回避でき、または少なくとも失速の持続時間を短縮できることが予測される場合、取り消すべきである。プレーヤは次いで、置換え要求についてのそのプロパティをもつ最も高品質のメディア要求を選び出すことができる。
[0206]レート取消しプロセスは、失速を次のように予測することができる。このプロセスは、フラグメント中の未処理バイトの数をダウンロードレートの推定値で除算することによって、発行された要求の推定完了時間を計算することができる。その時間が、円滑なプレイバックのためにフラグメントが必要とされるデッドラインよりも後の場合、失速が予測される。
[0207]切迫した失速が予測される場合、要求取消しプロセスは、レートの切替えが事態を改善する見込みがあるかどうかを決定し、改善が見込まれるときのみ、取り消すという決定が行われる。
[0208]一実装形態は、候補置換えフラグメントのレート推定値およびサイズにのみ基づいて、置換えフラグメントをロードするのにかかる時間を推定することができる。
[0209]別の実装形態は、取消しによる追加オーバーヘッドも考慮に入れることができる。すなわち、既存の要求を取り消し、新規要求を発行するのに必要とされる時間を考慮するために、推定RTTの倍数を加算することができる。取り消された要求からネットワーク上での配信のためにキューイングされているがまだ宛先には届いていないデータは、追加遅延に寄与し得る。クライアントは、この遅延を、TCP受信ウィンドウサイズを推定レートで除算することによって推定することができる。遅延の別の推定値は、推定帯域幅遅延積に基づき得る。クライアントは、2つの推定値のうちの最大値など、2つの推定値を組み合わせることができる。
[0210]要約すれば、クライアントは、置換えフラグメント全体をダウンロードするのに必要とされる時間と、通常はRTTに比例する量と、キューイング遅延の推定値との合計を計算する。失速が予測され、その時間が現在のフラグメントをダウンロードするための推定残り時間よりも小さい場合、取消しが発行される。
[0211]要求取消しプロセスは、また、初期のレート選択が正確でなかったために、第1のフラグメントをダウンロードするのに所望されるよりも長くかかることにプレーヤが気づいたときには、スタートアップ時に取り消すこともできる。
[0212]別のレート取消し実装形態は、また、シームレスなプレイバックを認めず、いくつかのフレームをスキップすることを含意する、置換え要求を選び出すこともできる。これは、エンドツーエンドのレイテンシが小さく保たれることを要求するライブコンテンツを再生するときに必要となり得る。
[0213]フレームスキップを用いて取消しを行う実装形態は、フレームスキップが可能な限り小さくなるような方法で置換えフラグメントを選び出すことができる。
[0214]この実装形態は、置換え要求として、指定された失速持続期間またはスキップフレーム持続期間を超えることなく持続可能にダウンロードすることができる、最も高品質の要求を選ぶことができる。
[0215]すでにダウンロードされたフラグメントについては、異なる種類の取消しが実装され得る。プレーヤは、プレイアウトされる予定のいくらかのメディアをすでにバッファリングしている場合、ネットワークを通じてより高品質のリプレゼンテーションをフェッチし、それをストリーミングすることを決定することができ、以前バッファリングされた、より低品質バージョンは破棄し得る。
[0216]その取消しプロセスは、失速することなくプレイアウトすることができるように時間内により良好な品質のビデオを受信することができると決定した場合、これらの置換え動作を行うことを決定し得る。
[0217]図26は、時間T1における新規フラグメント要求の直後に起こる、ダウンロードレートの強烈な下落を示す。この要求まで、受信レートはORであり、次いで、NRに下落する。バッファレベルは今では下落している。新たに要求されたフラグメントは、約T2=T1+OR/NR*フラグメント持続期間の時間に、完全にダウンロードされる。OR/NRが大きい場合、この値は、時間T1におけるバッファ中のメディアコンテンツのp時間の持続時間よりも大きくなり得、このことは、要求されたフラグメントは、失速なしではプレイバックされないことを意味する。pkerエスティメータは、はるかに速くレートNRに収束しているが、T1よりも前に要求が行われたので、フラグメントのダウンロードは、推定値が新規レートNRに収束する機会がないうちに行われることに留意されたい。失速を避け、訂正された推定値をもつ新規要求を発行するために、要求を取り消し、より適切なビットレートで要求を再発行することが必要である。
[0218]図27は、要求取消しのあるケースを示す。ダウンロードレートの鋭い下落(線2702)の後、バッファはドレインし始め、推定ダウンロードレート(たとえば、pkerプロセス)は、新規ダウンロードレートに収束し始める。どこかの時点で、ストリームマネージャは、失速なしでプレイバックのための時間内にフラグメントが受信されないことに気づく。その点は、図27のプロットにおいて、「取消し点」2704としてマークされている。その時点で、部分的に受信されているフラグメントは、取り消され、バッファから追い出される(したがって、バッファレベルがさらに下落する)。しかしその後、正しいレートをもつフラグメントが要求され得るので、バッファレベルはそれ以上下落しない。実際、自明でない(nontrivial)レート選択プロセスが使用される場合、レベルは再度増大し得る。
[0219]図28は、例示的要求取消しプロセスを示すフローチャートである。
[0220]図29は、要求取消し検出のためのプロセスを示す。
[0221]ここで、上記詳細に基づいて、要求取消し実装形態について説明する。
[0222]このセクションにおいて、Niは、要求されたが、まだ完全には受信されていない、リプレゼンテーショングループi中のフラグメントの数を示す。これらは、Fi,1,…,Fi,Niとして参照される。さらに、Fi,jは、開始p時間の昇順でソートされると仮定し、α(Fi,j)は、要求されたフラグメントFi,jについてすでにダウンロードされたバイトの量を、バイトで表されたフラグメントのサイズで除算したものである。変数Tは、現在のプレイバックp時間を示す。要求取消し検出プロセスは、図29の擬似コードによって示すように進行し得る。
[0223]要求取消し検出プロセスは、実行されると、ニル(nil)を返すことができ、この場合はいかなるアクションもとられることはなく、あるいは、取り消すべきグループ中のフラグメントを識別する。そのようなフラグメントが識別された場合、このことは、このフラグメント、および(p時間順で)その後にくる、同じグループ中のあらゆるものが、取り消され、バッファからフラッシュされるべきであることを意味する。SMは次いで、そのレート決定プロセスを再度呼び出し、セクション用に新規代替要求を発行するべきである。
[0224]このプロセスを説明するために、差し当たり、単一の要求のみが今のところ未処理であると仮定する。その場合、Rを、ダウンロードレートの正確な推定値とし、davailを、問題となっているフラグメントがプレイアウトされることになるまで、依然として受信することができるバイト数とする。量dneedは、そのフラグメント中で依然として欠けているバイト数である。したがって、davail<dneedの場合、プレーヤは、フラグメントFi,jを再生する前に失速すると予測する。このことは、以上のプロセス中の最初の「if」条件について説明している。
[0225]失速が予測される場合であっても、取消しにより失速を避けることになる場合、または少なくともその持続期間を短縮する場合にのみ、取り消すことに意味がある。取消しの後には、新たなフラグメントが選択され、最初からダウンロードされなければならない。ただ1つのリプレゼンテーショングループがあり、レート決定プロセスが正しいレートを選んだ場合、これには持続期間(Fi,j)のほぼλ倍の時間がかかり、ここでλは、現在の適切なラムダ因子である。一方、SMが切り替えないと決定した場合、現在のフラグメントダウンロードの終了には、dneed・R-1の時間がかかる。簡単のために、λ=1と仮定すると、他の因子をもち得る、第2の条件が得られる。
6. 要求アクセラレータ
[0226]ストリーミングメディアクライアント向けの直接的なやり方は、単一HTTP接続を用いてメディアをフェッチすることである。そのようなクライアントは、フラグメント要求を連続して処理することになる。そのような手法には、ビデオストリーミングにおいていくつかの欠点がある。第1に、一般的ネットワーキングソフトウェアはしばしば、長いダウンロードにわたる最大スループットについてのみ合わせられる。これは、大きいファイルを受信するには良いが、安定受信レートなど、他の重要なストリーミング目標とは相反する。第2に、TCPの性質により、リンクの満杯容量は、必ずしもそのようなHTTP接続とともに使用することができるわけではない。チャネルが、ある程度の遅延とパケット損失とを受ける場合、TCPは、達成され得る実際のスループットを制限し、こうすることにより、ストリーミングクライアントが、良好な品質のメディアをストリーミングするのが妨げられる場合がある。
[0226]ストリーミングメディアクライアント向けの直接的なやり方は、単一HTTP接続を用いてメディアをフェッチすることである。そのようなクライアントは、フラグメント要求を連続して処理することになる。そのような手法には、ビデオストリーミングにおいていくつかの欠点がある。第1に、一般的ネットワーキングソフトウェアはしばしば、長いダウンロードにわたる最大スループットについてのみ合わせられる。これは、大きいファイルを受信するには良いが、安定受信レートなど、他の重要なストリーミング目標とは相反する。第2に、TCPの性質により、リンクの満杯容量は、必ずしもそのようなHTTP接続とともに使用することができるわけではない。チャネルが、ある程度の遅延とパケット損失とを受ける場合、TCPは、達成され得る実際のスループットを制限し、こうすることにより、ストリーミングクライアントが、良好な品質のメディアをストリーミングするのが妨げられる場合がある。
[0227]これらの問題を避けるために、本明細書において要求アクセラレータ(RA)と呼ぶ、特殊HTTPクライアントが実装されることができる。要求アクセラレータは、前述した問題を回避または軽減するための特殊プロセスを有する。要求アクセラレータのある実装形態は、いくつかの重要な要素を利用して、その目標を達成することができる。それは、いくつかのTCP接続を使用して、データを受信することができる。それらの接続は、並行してアクティブであることができる。データ要求を、より小さいチャンク要求に分割することができ、それらのチャンク要求は、異なる接続上で個々にダウンロードされ、要求アクセラレータにおいて、1つの大きな部分に再アセンブルされ得る。それは、接続が相互に公平(fair)になるように、TCP接続パラメータ(具体的には、TCP受信ウィンドウサイズなど)を調節し、比較的安定したデータ受信を行うことができる。それは、使用するべきTCP接続の数を、測定されたネットワーク条件および目標プレイバックレートに基づいて動的に調整することができる。
[0228]使用するべきTCP接続の理想的な数は、ネットワーク条件、特に、ラウンドトリップ時間(RTT)およびパケット損失挙動に依存する。RAはしたがって、これらの量を推定するための方法を使用することができる。
[0229]RAは、HTTP要求の発行から、応答が着信し始めるまでかかる時間をサンプリングすることによって、RTTを推定することができる。一実装形態は、一定期間、たとえば最後の数秒間にわたって取得されたすべてのそのようなサンプルの最小値をとることによって得られるRTTの推定値を使用することができる。別の実装形態は、最後のN個の取得サンプルの最小値を使用することができ、ここでNは、推定値としての何らかの整数である。
[0230]TCPプロトコルは、パケット損失を扱い、連続するデータプリフィックスをアプリケーションに届けるので、TCP層より上でのパケット損失の測定値を取得することは、しばしば困難である。したがって、代わりに、パケット損失についての妥当な値をRAプロセスへの入力として固定することが有用なことがある。ある実装形態は、損失を一定であると推定し得る。いかなるパケット損失測定値ももたないので、RAは、損失を1%であると推定する場合もあり、または、RAは、損失を0.1%であると推定する場合もある。推定値は、接続のタイプによって決定されることができ、たとえば、推定値は、WiFi接続については0.1%に設定され、セルラー接続については1%に設定され得る。RTTにおける分散など、他の方法も、RAによってパケット損失を間接的に推論するために使用されることができる。あるいは、ある実装形態は、パケット損失推定値を、それに関する情報についてオペレーティングシステムカーネルを照会することによって取得することができる。
[0231]別の実装形態は、アプリケーション自体における損失を推定することができる。そうするために、その実装形態は、ネットワークソケットからのデータが概して最大セグメントサイズの(MSS)チャンクの形で受信されるが、パケット損失は、はるかに大きいチャンクの受信、すなわち近似的にTCP受信ウィンドウ全体のサイズのバーストを引き起こす、という観察に基づいた以下の手順を使用することができる。Mを、バイトで表されたMSSとすると(良好な推測は、M=1500である)、nバイトが受信された場合、送られるパケットの数は約n/Mである。zを、k・Mバイトを超える読込みを生じたソケット読込みの数とする、ここでkは、ある小さい整数である。kは、アプリケーションの2つのネットワーク読込みの間にk個以上のパケットが到着した見込みがないように、十分に大きいように選ばれると仮定する。ソケット上でコンスタントに待機するアプリケーションについては、k=3がよい。すると、p=z・M/nが、パケット損失確率の推定値である。所望の開始点から、zとnとをカウントすることによって、この手順は、時間の任意の所望の範囲にわたるパケット損失レートを推定することができる。
[0232]RTTの推定値およびパケット損失確率が与えられると、アプリケーションは、必要とされるかなりの数の接続を計算することができる。このプロセスは特に、目標ダウンロードレートがその接続数で達成され得るように十分に大きい、接続の数を選ぶことができる。単一レートの達成可能レートは概して、達成可能スループットに関するTCP式によって制限され、この式によると、おおまかにいえば、単一のTCP接続が、T=MSS/(RTT・√p)の平均ダウンロードレートを達成することができる。したがって、このプロセスは、目標ダウンロードレートをTで除算したものに比例するように、接続の数を選べばよい。
[0233]RAは、使用するべきTCP接続の数に対して、現実的な理由により、下限と上限とを課してもよい。たとえば、RAは、RAがオープンする接続の最大数を8に、および接続の最小数を2に制限してよい。
[0234]帯域幅、損失確率、およびRTTは、変わることがある。要求アクセラレータは、それらの量を監視し、接続の数を動的に変える。
[0235]要求アクセラレータは、HTTP要求を、より小さいサブ要求に分割し、あらゆるサブ要求についての戻されたデータ応答を、元の要求に対応するコヒーレント応答に再アセンブルすることができる。要求をサブ要求に分割するのには、いくつかの利点がある。第1に、利用可能TCP接続を使用するために、それらの接続すべての上で要求を発行できることが必要である。メディアストリーミングプレーヤは、接続すべてを使用するような十分な要求を与えるわけではない場合がある。要求分割は、より多くの数のサブ要求を生じ、サブ要求は様々な接続上で発行され得るので、この問題を緩和する。第2に、要求分割はより短い要求を生じ、そうすることによって時機を逸したデータ配信の危険性が低減され、すなわち、一部のTCP接続が、他の接続よりも時間的に遅い場合、それらの一部の接続は、依然として短い要求とともに使用されることができる。それらは、速い方の接続よりも応答を配信するのが遅いが、要求が小さいので、全体的要求を完了するための追加的な相対遅延は通常、それ程大きくない場合がある。
[0236]概して、より多くの接続が使用されている場合、1つの要求につき、より多くのサブ要求を作成することが好ましい。これを達成するために、要求アクセラレータは、n個の接続があるとき、各要求を、n個のサブ要求に分割することができる。
[0237]別の実装形態は、要求サイズに応じて、1つの要求当たりのサブ要求の数を選び出す。サブ要求サイズが、ダウンロードするのに一定の時間量(たとえば、2秒)かかることが予測されるサイズとなるように選ばれた場合、要求は、より多くの接続がある場合はより多くのサブ要求に分割され、所望の効果を達成する。
[0238]分割ルールは、不必要に小さいサブ要求がないようにすべきである。たとえば、RA実装形態は、その分割プロセスにおいて最小サブ要求サイズを課し、最小値が満たされない場合はより少ないサブ要求に分割することができる。
[0239]マルチプルなTCP接続が使用されるとき、それらの接続は、帯域幅について競合する可能性がある。大きい時間スケールにおいて、各接続は、他の接続と同じ量を受信するが、2〜3秒間など、より小さいスケールでは、一部のTCP接続は、他の接続よりも著しく遅い場合がある。これは、いくつかのサブ要求が、他の要求よりもはるかに長くかかる場合があり、それがプレイバック失速につながり得ることを含意するので、ストリーミングについての問題を起こす。
[0240]これを避けるために、RAは、TCPフロー制御を使用して接続を「制御(tame)」すればよい。こうすることにより、各TCP接続の最大受信ウィンドウを十分に制限することができるので、接続は、その公平なスループット分担を超えて使用することはない。TCP接続を介して飛行中の(送られたが、まだ受信確認されていない)データの量はおおよそ、ダウンロードレートをRTTで除算したものである。したがって、TCP受信ウィンドウが、接続についての目標ダウンロードレートを推定RTTで除算したものにおおまかに、またはそれよりもわずかに大きく設定された場合、ダウンロードレートは、目標ダウンロードレートにおおまかに、またはわずかに大きく制限される。したがって、TCP受信ウィンドウサイズの設定は、調速機(governor)として作用することができ、所与のTCP接続が、他のTCP接続にはるかに低いレートでダウンロードするよう強制したような高いレートでダウンロードすることがないようにする。そのようなメカニズムが整っているので、接続は、おおよそ同じ速度でフェッチする傾向にあり、というのは、遅い接続は、公平な分担まで速度を上げるのに利用可能な帯域幅を有するが、同時に、接続は、少なくとも総目標受信レートであり、またはそれよりもわずかに高い、総ダウンロードレートを達成し得るからである。
[0241]RAは、受信バッファを調整することによって、クライアントにおける受信ウィンドウを調整することができる。RAは、連続する要求の間でこれらの設定を常に再調整する。
[0242]一実装形態は、各接続のTCP受信ウィンドウを、推定RTTと、目標ダウンロードレートを接続の数で除算したものの積よりもわずかに大きく設定し得る。
[0243]目標ダウンロードレートは、たとえば、プレイバックすることを目指すメディアレートから決定され得る。別の実装形態は、現在のプレイバックレートに基づいて(たとえば、現在のダウンロードレートの2倍)目標レートを設定し得る。
6.1 RAの実施形態
[0244]ここで、上述した要素を組み込む要求アクセラレータの実施形態について説明する。
[0244]ここで、上述した要素を組み込む要求アクセラレータの実施形態について説明する。
[0245]図30は、マルチプルなTCP接続を用いてフェッチする挙動のプロットである。図30〜図31は、様々な条件下での挙動を示す。この例において、ウェブサーバへの接続は、毎秒2メガビット(「mbps」)に制限された帯域幅であり、ラウンドトリップ時間は150msであり、0.1%のパケット損失があった。4つの接続アクティブフェッチフラグメントがあった。図30〜図31のプロットは、4つの接続の瞬間レート、ならびに総合レート、ならびにクライアントにおいて取得されたRTT推定値を示す。
[0246]図30において、接続の受信バッファは制限されていない。図31では、受信バッファは帯域幅と遅延との積の約2倍に制限されている。
[0247]図30および図31の例において、両方の方法は、安定して2mbpsの総スループットを達成する。接続が制限された受信ウィンドウを有するケース(図31)では、接続の間の配信は、いっそう一様であり、すなわち、ほとんどの時間、接続はほぼ同じレートで受信する。これは、無制限ウィンドウをもつ接続(図30)にはまったく当てはまらず、この場合、いくつかの接続は、長い時間ストレッチにわたって、他の接続よりも遅い。
[0248]不均一な接続速度は、ストリーミングアプリケーションにとって問題があり、というのは、何らかの緊急データが、(遅い接続上で)非常にゆっくりとしか着信しておらず、帯域幅は、緊急には必要とされないデータをフェッチすることができるより速い接続の方に転用されることを意味し得るからである。
[0249]無制限ウィンドウと制限受信ウィンドウとの間の別の違いは、クライアントが動作するときのRTTである。制限が整っているので、RTTは、低いままであり、伝播遅延に近い。受信ウィンドウ制限がないので、飛行中のデータの量が、基底の伝播遅延に接続の容量を乗じたものを超えると、キューイング遅延は非常に大きくなり、高RTTを引き起こし得る。多くのイベントに対するクライアントの反応時間は概してRTTの倍数であるので、高RTTは、メディアストリーミングクライアントにとって望ましくない。たとえば、新規メディアコンテンツをダウンロードさせるユーザ探究イベント、または要求取消しもしくはリプレゼンテーションの切替えを引き起こすダウンロード速度の低減に対するクライアント反応時間は概して、現在のRTTの何倍にもなり、したがってそのようなイベントに対するクライアントの一般的応答性は、RTTが大きいとき低下する。
[0250]図32は、要求アクセラレータプロセスのフローチャートである。
[0251]図33は、所与のフラグメント要求を生み出すためのいくつかのサブ要求を見つけるためのプロセスを示す。
[0252]図34は、計算されたサイズを有するソース要求の分離区間となるように選ばれた個々の要求を選択するためのプロセスを示す。このプロセスにおいて、サブ要求サイズは意図的にランダム化され、そうすることによって、接続がアイドルである時間は、接続によって変化する。こうすることにより、すべての接続が同時にアイドルになることが避けられ、その結果、より良好なチャネル使用となる。要求サイズも順序付けられ、そうすることによって、より大きい要求がより早く出され、制限されるアイドル時間の差を保つのを助ける。
[0253]図35は、時間オフセットと、時間オフセットによって決定される修復セグメントについてのフラグメント構造との例を示す。
[0254]動作に際して、要求アクセラレータは、HTTP要求(各要求は、URLおよびバイト範囲である)をSCから受信する。
[0255]要求アクセラレータは、HTTPを介して、要求されたバイト範囲をダウンロードし、データが完全に受信されると、SCにデータを返す。RAは、十分に大きいダウンロード速度を達成するが、同時に、各フラグメントがその最終期限時間前に必ず受信されるようにすることを目指す。高ダウンロード速度により、高品質のビデオリプレゼンテーションを選ぶことが可能になるとともに、期限を尊重することによって、プレイバックが失速なしで必ず進むようになる。
[0256]高ダウンロード速度という目標を達成するために、RAは、変化する数のオープンなTCP接続を管理し、これらの接続はすべて、HTTPを介してデータを受信するのに使用される。RAは、何個の接続を使用するべきか、必要な場合はそれらの接続のオープンまたは再オープン、ならびにどのように要求を接続にディスパッチするかの詳細について引き受ける。
[0257]RAは、いくつかのケースでは、ソース要求を、より小さいいわゆるRA要求に分割することを決定し、RA要求は次いで、様々な接続にディスパッチされ、その応答データは、到着すると、RAによってトランスペアレントに再アセンブルされる。たとえば、何らかのファイルの最初の64キロバイトを備えるソース要求について、RAは、2つのRA要求を作成することができ、1つはそのファイルの32キロバイトチャンクについてであり、もう1つは、第2の32キロバイトチャンクについてである。RAは次いで、それらの2つのチャンクを2つの異なる接続上で並列に要求し、2つの32キロバイトチャンクが受信されると、元の要求について、コヒーレントの64キロバイト応答を作成することができる。
[0258]RAは、ソース要求の単なるプレーンな部分的範囲以上のものであるRA要求を発行し得る。たとえば、プレーンなビデオデータに加え、フラグメントのFECデータについての要求を発行することができる。その場合、RAは、FEC情報が受信されると、その情報をトランスペアレントに復号し、最終的な復号フラグメントのみをソースに提示することになる。
[0259]RAは、RA自体を、ネットワーク条件に自動調節する。たとえば、RTTが大きい場合、RAは、要求の間のたくさんのアイドル時間を避けるように、より大きいチャンク要求を発行することを決定し得る。自動調節の別の例は、RAが、その要求の適時性を確実にするように、個々の接続の速度を同様に保とうとすることである。それらのことをできるようにするために、RAは好ましくは、その接続のソケットへの直接アクセスを有する。たとえば、Unix(登録商標)のような環境では、setsockopt()関数を使用してソケットオプションを設定することが可能である。
[0260]RAは、ネットワーク状態を測定および追跡し、これは特に、ダウンロードレートと推定ラウンドトリップ時間(RTT)とを測定することを含む。RAがこの情報を収集する理由は、第1に、接続の自動調節がそれらのアベイラビリティに依存するからであり、第2に、帯域幅情報がSMにパスされる必要があるからであり、SMは、その情報を使用してSMレート推定値を計算する。
[0261]RAがSMに(SCを経由して)フォワードする別の情報ピースは、未処理要求についての進行情報、すなわち、所与の要求のうちどの程度のデータがすでに受信されているかである。SMは、その情報を、SMレート推定値と、要求取消し決定の両方に対して使用する。
[0262]RAは、SMによって、帯域幅推定を行うのに必要とされる情報を追跡する。この情報は、ダウンロードに費やされるr時間の総量、すなわちTr、およびダウンロードされたバイトの総量、すなわちZである。これらの数は両方とも、単調に増加しており、SMによって頻繁にポーリングされる。Trタイマは、少なくとも1つの接続がアクティブである場合にのみ動作している。接続は、HTTP要求を送り出し、または応答データが着信するのを待っている場合、アクティブと見なされる。Zカウンタは、着信バイトをカウントし、すべての接続にわたって集計される。
6.1.1 RAダウンロードレート履歴
[0263]要求アクセラレータは、履歴順に記憶される、(Tr,Z)ペアの増大アレイを保つことによって、レートの何らかの履歴を追跡する。このアレイを、mapTrZと呼ぶ。mapTrZの更新は、頻繁に、少なくとも一定時間間隔で(たとえば、100msおきに)、場合によっては新規データが受信されたときにも、起こる。
[0263]要求アクセラレータは、履歴順に記憶される、(Tr,Z)ペアの増大アレイを保つことによって、レートの何らかの履歴を追跡する。このアレイを、mapTrZと呼ぶ。mapTrZの更新は、頻繁に、少なくとも一定時間間隔で(たとえば、100msおきに)、場合によっては新規データが受信されたときにも、起こる。
[0264]RAは、mapTrZを利用して、ウィンドウ化帯域幅推定値を次のように計算することができる。幅tである、関心のウィンドウを検討し、mapTrZ[last]を、mapTrZ中の最後のエントリとする。次いで、mapTrZ[i].Tr≦mapTrZ[last].Tr−tであるような、最も大きいインデックスiを見つける。iは、バイナリサーチで効率的に見つけられ得ることに留意されたい。レート平均は次いで、式8に示すようになる。
[0265]式8は、後続Trにおける差が、tと比較して小さいと仮定する。このことは、十分頻繁にサンプリングし、小さいウィンドウ幅tを決して選び出さないことによって保証される。
[0266]実際に、任意に増大するアレイは厄介である。過去について考察される最大持続期間は上限を定められ得るので、mapTrZを、代わりに固定サイズのリングバッファとして実装するやり方がある。これは、次のように行われ得る。mapTrZアレイがアップデートされるべきであり、mapTrZアレイが少なくとも2つのペアをすでに含むときは常に、Tr−mapTrZ[last−1].Tr<100msである場合は最後のエントリを置き換え、新規エントリを他のやり方で追加する。
6.1.2 ラウンドトリップ時間(「RTT」)推定値
[0267]RAは、帯域幅推定値を収集する。アプリオリなRTTサンプルを受け取るための簡単なやり方は、HTTP GET要求がアイドル接続上で送出され、応答が着信し始めるときの時間の差を測定することである。
[0267]RAは、帯域幅推定値を収集する。アプリオリなRTTサンプルを受け取るための簡単なやり方は、HTTP GET要求がアイドル接続上で送出され、応答が着信し始めるときの時間の差を測定することである。
[0268]ただし、そのような測定値は、キューイング遅延を実際に含む。すなわち、クライアントが他のオープンなアクティブ接続を有する場合、クライアントにデータを送る最後のホップは、クライアントへのそのリンクが、データを受信することができるレートよりも低いレートを有する場合、いくつかのパケットをバッファリングし得る。その場合、パケットは、本来よりも長い遅延で配信され得る。
[0269]我々のケースでは、クライアント自体の活動によって誘発されるキューイング遅延を無視するRTTを知ることが望ましい。その量の推定値を受け取るために、次のように進める。
[0270]各活動期間中、前述したタイミング方法を用いてRTTサンプルを収集し、各GETの結果、サンプルが得られる。すると、現在の推定値は、すべてのそれらのサンプルのうち最小である。サンプルのリストは、RAが非アクティブになるときには常にフラッシュされる。(クライアントは、たとえば、高ウォーターマークのセクション3を超え、開始されたダウンロードが終了すると、非アクティブになる)。非アクティブ期間中、またはどのRTTサンプルも受信される前のアクティブ期間中、RTT推定値は、最終的な既知の推定値である。
[0271]RTTエスティメータは、象徴的な「どのRTT推定値も既知でない」という値を戻すこともでき、この値は、たとえばクライアントスタートアップ時に使用することができる。
6.1.3 TCP接続の数の調整
[0272]TCPフロー制御の調節により、RAは、様々な接続における帯域幅を、おおよそ同じに保つことができる。いくつかの構成可能な調節定数は、kR(RTT中で測定されたレート測定値ウィンドウであって、奨励値は30)と、kN(比例因子であって、奨励値は8192バイト)と、Nmin(Ntarget下限であって、奨励値は1)と、Nmax(Ntarget上限であって、奨励値は8)とを含み得る。
[0272]TCPフロー制御の調節により、RAは、様々な接続における帯域幅を、おおよそ同じに保つことができる。いくつかの構成可能な調節定数は、kR(RTT中で測定されたレート測定値ウィンドウであって、奨励値は30)と、kN(比例因子であって、奨励値は8192バイト)と、Nmin(Ntarget下限であって、奨励値は1)と、Nmax(Ntarget上限であって、奨励値は8)とを含み得る。
[0273]推定の帯域幅遅延積(BDP:bandwidth-delay-product)は、BDP:=RTT・Rとなるように定義され、ここでRTTは推定RTT(上記のように)であり、ここでRは、最後のkR・RTT時間(ウィンドウ方法で推定される)にわたる平均受信レートである。
[0274]目標接続数は次いで、式9にあるように定義され、ここでkNは構成可能定数である。
[0275]Ntargetの値は、定期的に計算し直される。現在オープンな接続の数がNtarget未満である場合、Ntargetに一致するように、新規接続が直ちにオープンされる。一方、Ntargetが、現在オープンな接続の数未満の場合、いかなる即時アクションもとられない。そうではなく、RA要求が終了されると常に、RAは、オープンである接続の数が多すぎるかどうかをチェックし、多すぎる場合、アイドルになったばかりの接続をクローズする。
6.1.4 接続におけるTCP受信ウィンドウの調整
[0276]RAは、各接続のTCP受信ウィンドウサイズを、
[0276]RAは、各接続のTCP受信ウィンドウサイズを、
に設定する。ここで、cwは、設定可能なハードコードされた定数であり、たとえばcw=3である。RAは、その接続上で次のHTTP要求を発行しようとしているときには常に接続のTCP受信ウィンドウサイズを設定する。
6.1.5 要求分割プロセス
[0277]RAに渡された各ソース要求は、おそらく2つ以上のRA要求に分割され、これらのRA要求は各々、要求された範囲の異なる部分に対応する。所与のソース要求に対応するRA要求がすべて完了されると、受信データは、RAによって完了フラグメントに再アセンブルされ、完了フラグメントは次いで、SCに戻される。
[0277]RAに渡された各ソース要求は、おそらく2つ以上のRA要求に分割され、これらのRA要求は各々、要求された範囲の異なる部分に対応する。所与のソース要求に対応するRA要求がすべて完了されると、受信データは、RAによって完了フラグメントに再アセンブルされ、完了フラグメントは次いで、SCに戻される。
[0278]所与のHTTP要求について、RAは、いくつかの調節可能値に依存するプロセスを使用して、RA要求の数nを決定する。nの値は、Twn(レート推定値ウィンドウ幅であって、奨励値は4s)、Dmin(最小フェッチ持続期間であって、奨励値は2s)、およびcs(RTT中の最小フェッチ持続期間であって、奨励値は6)という調節可能な定数に依存する。
[0279]すると、サブ要求の数nを見つけて、所与のフラグメント要求を行うためのプロセスは、図33の擬似コードに示すようになる。
[0280]個々の要求は次いで、たとえば、計算されたサイズを有する、図34に示すプロセスを使用して、ソース要求の分割間隔となるように選ばれる。
6.1.6 要求ディスパッチプロセス
[0281]要求アクセラレータは、RA要求のセットを維持する。接続が、次の要求を発行する準備ができたときには常に、キューが空いていない場合は要求がRAキューからデキューされ、アイドル接続上で発行される。キューが空の場合、新規フラグメント要求がSCから取得される。その要求は次いで、RA要求に分割され、RAキュー上でキューイングされる。キューイングは好ましくは、サブ要求の数を見つけて所与のフラグメント要求を行うためのプロセスによってスライスが戻される順序で行われる。
[0281]要求アクセラレータは、RA要求のセットを維持する。接続が、次の要求を発行する準備ができたときには常に、キューが空いていない場合は要求がRAキューからデキューされ、アイドル接続上で発行される。キューが空の場合、新規フラグメント要求がSCから取得される。その要求は次いで、RA要求に分割され、RAキュー上でキューイングされる。キューイングは好ましくは、サブ要求の数を見つけて所与のフラグメント要求を行うためのプロセスによってスライスが戻される順序で行われる。
[0282]HTTP接続は、様々な理由で、たとえば、ウェブサーバタイムアウトが起こり、または単一接続上で発行され得る要求の数を超えたことが原因で、シャットダウンを受け得る。RAは、このステータスを適切およびトランスペアレントに扱うべきである。接続がシャットダウンされるときは常に、RAは、接続を自動的にオープンし直す。要求は、クローズされた接続上で要求が進行中の場合、接続からデキューされ、未受信部分についての新規RA要求が、RAキューの前に置かれる。
[0283]この手順により、クローズされた接続は確実に、パフォーマンスに対して最小限の影響しかもたないことになる。
6.1.7 特定の実施形態におけるRAパラメータ選択
[0284]TCP接続は、そのフロー制御によって制限される。すなわち、広告される受信ウィンドウは、どの時点でも受信確認されないことが許容されるデータの量に上限を定める。したがって、Wが、受信ウィンドウのサイズを示し、bdpがその接続の帯域幅遅延積を示す場合、bdp≦W(条件1)を得る。セクション6.1.4の方法は、cw>1であるとすると、この条件(1)が満たされるような受信ウィンドウサイズを選ぶことを記述している。この方法により、個々の接続が、利用可能帯域幅のその公平比率を実質的に超える比率をとる可能性は確実になくなる。レート増大を可能にし、レート下方スパイラルを避けるために、1よりもある程度大きいcw、たとえば、cw=2またはcw=4を選ぶことが好ましい。この値が大きい程、レートはより速くなることができるが、相互に対して接続が公平でなくなる。
[0284]TCP接続は、そのフロー制御によって制限される。すなわち、広告される受信ウィンドウは、どの時点でも受信確認されないことが許容されるデータの量に上限を定める。したがって、Wが、受信ウィンドウのサイズを示し、bdpがその接続の帯域幅遅延積を示す場合、bdp≦W(条件1)を得る。セクション6.1.4の方法は、cw>1であるとすると、この条件(1)が満たされるような受信ウィンドウサイズを選ぶことを記述している。この方法により、個々の接続が、利用可能帯域幅のその公平比率を実質的に超える比率をとる可能性は確実になくなる。レート増大を可能にし、レート下方スパイラルを避けるために、1よりもある程度大きいcw、たとえば、cw=2またはcw=4を選ぶことが好ましい。この値が大きい程、レートはより速くなることができるが、相互に対して接続が公平でなくなる。
[0285]別の制限は、TCP輻輳制御プロセスによって課される。pがパケット損失確率を示し、MがTCP最大セグメントサイズを示す場合、単一接続のレートrは、式10によって示すように制限される。
[0286]ここで、この式を、BDPおよび接続の数Nによって(bdp=r・RTTとBDP=N・bdpとを使用する)書き換えると、式11に示すものを得る。
[0287]この式は、kNが、式11中の不等式が確実に成り立つように、式9中の
未満のビットになるように選ばれるべきであることを示唆する。Mについての典型的な値は1キロバイトであり、p=0.01と設定した場合、
となる。したがって、この例では、式9におけるNを設定するために、セクション6.1.3において提案されたようにkN=8,192バイトと設定することにより、式11の不等式が確実に満足される。受信機は、適切に構成またはプログラムされ得る。
[0288]ここで、所与のソース要求についてのRA要求の数nを計算するための、上のセクション6.1.3のプロセスに移る。アプリオリに、小さいスライスはいくつかの利点を呈するのでスライスを可能な限り小さくしたい。そのような利点として、ある接続が他の接続に比べて遅い場合、そのことが、小さい要求に関する問題を引き起こす可能性は比較的低い、というのは、小さい要求は、遅い接続上であっても迅速に終了するからである。したがって、小さいスライス設定では、遅い接続は本質的に、比較的少ない要求をサービスする結果になる。小さいスライスの別の利点は、RAに、バッファの時間内の比較的短いセクションに対して作用させるので、RAは、最も緊急な作業エリアに対するその作業を強化する傾向があることである。
[0289]ただし、スライスを小さくすることには、代償が伴う。すなわち、第1に、各要求が、アップリンクとダウンリンクの両方においていくらかのオーバーヘッドを招く。第2に、1つの要求を終了した後、接続は、約1RTTだけ、アイドルのままである。したがって、要求分割プロセスは、理想的には、あまりにも多くのアップリンクトラフィックを引き起こすことも、各利用可能リンクの容量を実質的に利用しきれないこともない、可能な限り小さいチャンクを選ぶことを試みるべきである。好ましいプロパティはしたがって、次のようになる。
[0290]1.リアルタイムのDminごとに、1つの接続につき多くとも1つの要求を目指す。こうすることにより、アップリンクトラフィックは、最悪のケースにおけるNtargetに比例する値を限度とする。
[0291]2.cs・RTTおきに、1つの接続につき多くとも1つの要求を目指す。こうすることにより、接続の活動時間が、少なくとも約cs/(cs+1)になるようにされ、すなわち、中間のcsでは1に近づく。
[0292]Dminの良好な選択は、使用ケースに依存する。所望のエンドツーエンドの遅延と同程度(ただしそれ未満)のDminを選び出すことは、一般に、フラグメントの典型的な持続期間である。エンドツーエンドの遅延が大きくなるべき場合、より大きいバッファが使用されることができ、より大きいスライスの悪影響はより小さくなる。一方、短いエンドツーエンドの遅延において、バッファは小さいので、スライスは、失速を引き起こす遅い接続を避けるように小さくあるべきである。そのシナリオにおいて、より高いコストの、より小さい要求は、バッファレベルでの、得られる安定性に値する。
[0293]使用されるパラメータは、MPD(メディアプレゼンテーション記述)中のプロファイルインジケータが、クライアントに対する、ストリーミングされるメディアのプロパティの要約なので、そのインジケータに従って調節され得る。あらゆるメディアセグメントをダウンロードし、それらをエンドユーザに見せるのではなく、クライアントは、MPD内部のプロファイルにある様々な使用ケースに基づいて、セグメントを「スキップする」ことを選ぶことができる。
[0294]csの選択に対する下限は、次のように考えればよい。N個のオープンな接続があり、RAがアクティブである場合、平均で、約N・cs/(cs+1)個のアクティブな接続がある。すべてのN個の接続の受信ウィンドウが、全体として、総計目標レートを持続させるのに十分に大きくなるのを確実にするために、cw・cs/(cs+1)が少なくとも1であることが望ましい。
[0295]この限度はコンサバティブである。アクティブ接続の推定数N・cs/(cs+1)は、ある程度の分散がある可能性が高くても、分散を考慮に入れていない平均にすぎない。実際に、csを、上記限度によって奨励される値の約2〜3倍にすることが有利であり、たとえば、cw=3およびcs=6のとき、cw・cs/(cs+1)は少なくとも2.5である。
6.2. 前方誤り訂正をもつRA
[0296]データがいくつかのTCP接続を介して受信されるとき、これらの接続は、時間的に異なるダウンロードレートを有することがある。フラグメントの要求がいくつかのサブ要求に分割されたとき、フラグメント全体は、最後のサブ要求応答(チャンク)が受信されたときに受信されるだけである。フラグメントが緊急に受信される必要があるとき、サブ要求のうち1つが遅い接続上で扱われる場合があり、フラグメントが素早く受信されるのを妨げるので、これは問題となる場合がある。
[0296]データがいくつかのTCP接続を介して受信されるとき、これらの接続は、時間的に異なるダウンロードレートを有することがある。フラグメントの要求がいくつかのサブ要求に分割されたとき、フラグメント全体は、最後のサブ要求応答(チャンク)が受信されたときに受信されるだけである。フラグメントが緊急に受信される必要があるとき、サブ要求のうち1つが遅い接続上で扱われる場合があり、フラグメントが素早く受信されるのを妨げるので、これは問題となる場合がある。
[0297]コンテンツプロバイダは、ビデオデータに加え、各フラグメントについての追加の前方誤り訂正(「FEC」)修復データを与えることができ、クライアントはこのデータをフェッチして、元のフラグメントを再構築するのを助けることができる。たとえば、クライアントが、4つの接続を有し、4000バイトのサイズのフラグメントを緊急に受信する必要があると仮定する。クライアントの要求アクセラレータは、フラグメントを、各々が1000バイトからなる4つの範囲に分割し、4つの接続の各々において1つの要求を発行することができる。接続1は高速であり、接続4は適度に高速であるが、第2および第3の接続ははるかに遅い場合がある。したがって、総ダウンロードレートが、原則として、フラグメント全体を時間内にダウンロードするのに十分に高い場合であっても、フラグメントは、接続2および3が行き詰っているので、非常に遅れてしか届かない。
[0298]この問題を避けるために、クライアントは、それ自体のサブ要求についてデータフェッチが行われるとすぐに、接続1を使用して、接続2または3と同じデータをフェッチしようとする場合がある。これは役に立ち得るが、RAは、どの接続がより多くの助けを必要とするか、その接続が2それとも3であるか決定を行わなければならない。RAが誤った予測を行った場合、RAは、複製データを不必要にダウンロードしている場合があり、フラグメントは依然として、時間内に届くことができない。
[0299]より優れた要求アクセラレータは、代わりに接続1を使用して、何らかの修復データをフェッチすることができる。修復(FECコード化された)データは、ダウンロードに成功した場合、要求2または3からのデータが欠けているかどうかにかかわらず、欠けているデータを再構築するのに使用することができる。唯一の制約は、受信されるデータの量は、フラグメントを再構築するのに十分なことである。言い換えると、我々の例では、修復バイトの数に、受信されたフラグメントバイトの数を加えると、4000以上になるはずである。
[0300]ある実装形態では、コンテンツプロバイダは、コード化ビデオセグメント用のFEC修復データへのアクセスを与える。プロバイダは、修復データを、元のビデオデータと同様にして、利用可能にすることができる。たとえば、各メディアセグメントファイルについて、修復情報を含む追加FECファイルを与えることができる。コンテンツプロバイダは、メディアプレゼンテーション記述においてFECを使用するための、必要な情報とパラメータとを与えることができる。別の実装形態では、メディアプレゼンテーション記述は、FECについてのいかなる情報も含まないが、クライアントは、セグメントURLからFEC修復URLの名称をどのようにして導出するかについてのルールなど、一般的な協定を使用して、その情報にアクセスすることができる。
[0301]クライアント実装形態は、修復データをいつどのようにして要求するかに関するプロセスを実装することができる。要求される修復データの量は、どれだけ多くのデータが未処理であるかに依存し得る。さらに、どれだけすぐにフラグメントが利用可能になる必要があるかに依存し得る。たとえば、十分すぎる時間が残されている場合、ソースデータすべてを時間内に受信することを望むので、どの修復を要求することも、おそらく余分である。一方、フラグメントが緊急になりつつある場合、クライアントが、そのフラグメントについての十分なデータを時間内に受け取るのに失敗した場合は失速が切迫しているので、たくさんの修復データを要求したいと思うかもしれない。したがって、ある実装形態は、要求される修復データの量をβ(B)Sとなるように設定することができ、ここでSは未処理ソースデータの量であり、β(B)はバッファレベルの減少関数である。
[0302]別の実装形態は、未処理データの量を、未処理の総量ではなく、最も不完全な要求中の未処理データの量に比例させ得る。
6.2.1 修復セグメントジェネレータの実施形態
[0303]DASH規格がどのようにFECを使用するか、特に、FEC用のRaptorQを使用するかに関する、以下の算出はすべて、好ましくは、固定小数点/整数演算を使用して実施される。この算出は、リプレゼンテーションのフラグメント内のソースシンボルの数および位置を算出することを含み、修復セグメント内のフラグメント用の修復シンボルの数および位置を算出することは、固定小数点演算を使用して行われるべきである。というのは、受信FEC修復フラグメントとソースフラグメントの組合せを使用してソースフラグメントを復号するRAプロセスとまったく同じ結果が、ソースセグメントからFEC修復フラグメントを生じる取込み(ingestion)プロセスによって達成される必要があり、したがってこれらの算出はまさに同じ出力結果をもたなければならないからである。固定小数点演算ではなく浮動小数点算出を使用すると、異なるプラットフォーム上の異なる浮動小数点実装形態の異なるコーナーケース挙動により、追跡するのが難しく、両方のエンドポイントがまさに同じ算出結果を生じなければならない規格において許容可能でない、わずかなバグのある挙動が時として生じ得る。
[0303]DASH規格がどのようにFECを使用するか、特に、FEC用のRaptorQを使用するかに関する、以下の算出はすべて、好ましくは、固定小数点/整数演算を使用して実施される。この算出は、リプレゼンテーションのフラグメント内のソースシンボルの数および位置を算出することを含み、修復セグメント内のフラグメント用の修復シンボルの数および位置を算出することは、固定小数点演算を使用して行われるべきである。というのは、受信FEC修復フラグメントとソースフラグメントの組合せを使用してソースフラグメントを復号するRAプロセスとまったく同じ結果が、ソースセグメントからFEC修復フラグメントを生じる取込み(ingestion)プロセスによって達成される必要があり、したがってこれらの算出はまさに同じ出力結果をもたなければならないからである。固定小数点演算ではなく浮動小数点算出を使用すると、異なるプラットフォーム上の異なる浮動小数点実装形態の異なるコーナーケース挙動により、追跡するのが難しく、両方のエンドポイントがまさに同じ算出結果を生じなければならない規格において許容可能でない、わずかなバグのある挙動が時として生じ得る。
[0304]修復セグメント内のフラグメントについての修復シンボルの数と位置とを算出することを伴わない、後で説明する他のすべての算出は、取込みと、正確に同じ結果を算出するためのRAプロセスとの間に依存がないので、所望される場合、(固定小数点でも問題はないが)浮動小数点を用いて行うことができる。
[0305]修復セグメントは、sidxテーブルを含む、すでに処理されたソースセグメントに基づいて、別個のプロセスにおいて生成することができる。ソースセグメント自体に加え、プロセスへの2つの入力は、修復比(repair fragment)RおよびシンボルサイズSである。セグメント内の修復フラグメントの修復シンボルの数および位置の算出に固定小数点演算を使用することを円滑にするために、Rの値は、パーミルで表されることができ、すなわち、R=500は、比が1/2であることを意味する。
[0306]各セグメント内で、ソースセグメントの始めにおいて、時間/バイトオフセットセグメントマップを備えるセグメントインデクシング情報も存在する。時間/バイトオフセットセグメントマップは、時間/バイトオフセットペア(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のフラグメントの最初まで、セグメント中のデータを保護することもでき、使用されない、ゼロをパディングしたデータバイトであってもよい。
[0307]修復比Rは、修復セグメントメタデータとともにMPDに入れてシグナリングされても、他の手段(TBD)によって取得されてもよい。Rについての値の例として、R=500の場合、修復セグメントサイズは、それが生成される元のソースセグメントの対応するサイズの0.5倍として、(非常に厳密に)概算され、ソースセグメント内の、ソースフラグメントに対応する、修復セグメントの修復フラグメントのサイズのサイズも、ソースセグメントのサイズの0.5倍として(非常に粗く)概算される。たとえば、ソースセグメントが1,000キロのデータバイトを含む場合、対応する修復セグメントは、ほぼ500キロバイトの修復データを含む。
[0308]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%を限度とする。
[0309]修復セグメントは、ソースセグメントについて次のように生成することができる。ソースセグメントの各フラグメントは、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)である。
[0310]修復セグメントは、フラグメントについての修復シンボルの連結を備え、修復セグメント内の修復シンボルの順序は、フラグメントが生成される順序であり、フラグメント内で、修復シンボルは、それらの符号化シンボル識別子(「ESI」)の順序である。
[0311]上述したように、フラグメント用の修復シンボルの数を定義することによって、すべての前のフラグメント用の修復シンボルの総数、ならびにしたがって修復フラグメントiのシンボルについてのバイトインデックスおよびバイト範囲は、R、S、B(i−1)およびB(i)にのみ依存し、ソースセグメント内のフラグメントの前または後続構造のいずれにも依存しないことに留意されたい。これは、クライアントに、修復セグメント内の修復ブロックの開始の位置を素早く計算させ、修復ブロックがそこから生成されるソースセグメントの対応するフラグメントの構造についてのローカル情報のみを使用して、その修復ブロック内の修復シンボルの数も素早く計算させるので、有利である。したがって、クライアントは、ソースセグメントの中央からのフラグメントのダウンロードとプレイバックとを始めることを決定した場合、対応する修復セグメント内にあるフラグメントに対応する、対応する修復ブロックを素早く生成し、アクセスすることもできる。
[0312]フラグメント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である。
[0313]本実施形態における修復セグメントについてのURLは、たとえば添字「.repair」をソースセグメントのURLに単に追加することによって、対応するソースセグメントについてのURLから生成することができる。
[0314]修復セグメントは、たとえば、末尾に付加される、対応するソースセグメントの一部でもあり得る。組み合わされたセグメントの構造は、ソースフラグメントおよび修復フラグメントが、組み合わされたセグメント内で連続し、すなわち、組み合わされたセグメントが、第1のソースフラグメント、それに続く第1の修復フラグメント、それに続く第2のソースフラグメント、それに続く第2の修復フラグメントなどを備えるようなものでもあり得る。当業者には認識されるように、上述した方法およびプロセスは、そのような組み合わされたセグメントに適用するために、容易に採用することができる。
6.2.2 修復セグメントを使用する要求アクセラレータの実施形態
[0315]修復セグメントについての修復インデクシング情報および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およびインデクシング情報から暗黙的に導出することができる。
[0315]修復セグメントについての修復インデクシング情報および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およびインデクシング情報から暗黙的に導出することができる。
[0316]一例として、バイトオフセット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つの修復シンボルがある。
[0317]このことは、図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. 例示した実施例
[0318]図25は、レート選択プロセスを示す。λおよびμについての設定が高い程、設定はアグレッシブになる。図23は、パラメータλについての様々な値を示す。図24は、パラメータμについての様々な値を示す。ハイブリッド設定が、2つのメインメカニズムによって、レートゆらぎを削減しようとする。第1のメカニズムは、Bが比較的大きいとき、レートを増大させることにより慎重であることによるものであり、第2のメカニズムは、Bが比較的小さいとき、より懸命に、現在のレートに留まろうとするものである。
[0318]図25は、レート選択プロセスを示す。λおよびμについての設定が高い程、設定はアグレッシブになる。図23は、パラメータλについての様々な値を示す。図24は、パラメータμについての様々な値を示す。ハイブリッド設定が、2つのメインメカニズムによって、レートゆらぎを削減しようとする。第1のメカニズムは、Bが比較的大きいとき、レートを増大させることにより慎重であることによるものであり、第2のメカニズムは、Bが比較的小さいとき、より懸命に、現在のレートに留まろうとするものである。
[0319]pker x.y:C=x*min(y*Tdl,B)についての例示的設定は、8.1、4.2、2.4、4.4または他のx.y値に設定されたx.yであり得る。pkerの実際の平均化ウィンドウは、ダウンロード中断期間のスキップにより、Cよりも長いことに留意されたい。EWMAのスキップはなく、ダウンロード中断期間中のレートは、最後のダウンロード間隔のものと同じであると仮定する。
[0320]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は、いくつかのケースではおおよそ均等である。
[0321]適合型エスティメータは、より長い平均化ウィンドウを有する場合、ライブストリーミング用にほぼ同じ平均レートを維持したまま、レート切替え頻度を削減する。異なる設定が、異なるシナリオについてうまく機能する。アグレッシブ設定は、より安定したシナリオに対してうまく機能し、あまりアグレッシブでない設定は、より変動しやすいシナリオにより適している。帯域幅が、かなりの時間部分(たとえば、20秒間の平均がレートキャップよりも高い時間の%)に対して、特定のマージンだけ、最も高いリプレゼンテーションレートよりも高い場合、よりアグレッシブ設定で進めることが有益である。理想的には、デバイスは、シナリオタイプを検出し、適切な設定を適用することができるべきである。シナリオ検出は、無線技術タイプ、特定の単位時間内のレート変化の回数、移動速度などのような要因に基づき得る。より単純な戦略は、上記観察に基づき、すなわち、「全体的」帯域幅がレートキャップよりも高いとき、よりアグレッシブ設定を使用することができる。
8. レート選択パラメータの設定
[0322]このセクションでは、レート選択パラメータを設定する例が挙げられる。
[0322]このセクションでは、レート選択パラメータを設定する例が挙げられる。
[0323]MLBについて、EFF=1−Rv/Rdlであり、ここでRvは、選択されたリプレゼンテーションの現在のレートであり、Rdlは現在のダウンロードレートである。提案されるルールは、次の通りである。
[0324] EFF<0の場合、おそらく2つ以上のレートだけ下がる
[0325] 0≦EFF<0.1の場合、1レート下がる
[0326] 0.1≦EFF<0.6の場合、現在のレートに留まる
[0327] 0.6≦EFF<0.8の場合、1レート上がる
[0328] 0.8≦EFF≦1の場合、おそらく2つ以上のレートだけ上がる
[0329] アルファ=Rv/Rdlとする。するとこれは、おおよそ次のようになる。
[0330] アルファ≦0.4の場合、少なくとも1つのレートだけ上がる
[0331] 0.4<アルファ≦0.9の場合、同じレートに留まる
[0332] 0.9<アルファの場合、少なくとも1レートだけ下がる
[0333] これを、DASHクライアントレート選択プロセスのコンテキストに当てはめる。
[0324] EFF<0の場合、おそらく2つ以上のレートだけ下がる
[0325] 0≦EFF<0.1の場合、1レート下がる
[0326] 0.1≦EFF<0.6の場合、現在のレートに留まる
[0327] 0.6≦EFF<0.8の場合、1レート上がる
[0328] 0.8≦EFF≦1の場合、おそらく2つ以上のレートだけ上がる
[0329] アルファ=Rv/Rdlとする。するとこれは、おおよそ次のようになる。
[0330] アルファ≦0.4の場合、少なくとも1つのレートだけ上がる
[0331] 0.4<アルファ≦0.9の場合、同じレートに留まる
[0332] 0.9<アルファの場合、少なくとも1レートだけ下がる
[0333] これを、DASHクライアントレート選択プロセスのコンテキストに当てはめる。
[0334]RUPを、UPに対応するリプレゼンテーションのレートとし、RDOWNを、DOWNに対応するリプレゼンテーションのレートとし、上記のように、Rvを、現在選ばれているリプレゼンテーションのレートとする。RUPは、RUP≦ラムダ(t)*Rdlとなるように可能な限り大きくなるように選ばれ、そのRDOWNが、RDOWN≦ミュー(t)*Rdlとなるように可能な限り大きくなるように選ばれる。パラメータt=B/(D+デルタ)であり、ここでBは、メディアバッファにおける現在のプレゼンテーション時間量であり、Dは、現在の決定が行われている時点を超える、次の可能切替え点までの時間に対する限度であり、デルタは、ネットワーク待ち時間とラウンドトリップ時間とを考慮に入れる小さいパラメータであり、たとえば、デルタは、近似として1秒または2秒に設定されてもよく、デルタは、現在のRTTに対する測定された上限に従って設定されてもよい。
[0335]次のレートRNEXTの全体的選択は、次のようになる。
[0336]RUP<Rvの場合、RNEXT=min{Rv,RDOWN}であり、そうでない場合、RNEXT=RUPである。
[0337]上記MLBパラメータは、すべてのtについてラムダ(t)=0.4*Rおよびミュー(t)=0.9と設定することによって概算することができ、ここでRは、次に高いリプレゼンテーションのレートと、現在のリプレゼンテーションのレートのものとの比である。たとえば、現在のレートが500Kbpsであり、次に高いレートが750Kbpsである場合、R=1.5となり、したがってラムダ(t)=0.6となる。これは、MLBプロセスを次のように近似する。
[0338]決定点において、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. レート選択パラメータセット
[0339]以下のテーブルは、いくつかの可能なレート選択パラメータセットを指定する。以下のテーブルに示されていないtの中間値についてのラムダおよびミューの値は、周辺値の間を線形補間することによって算出されるべきである。以下のテーブルに示すものを超えるtの値についてのラムダおよびミューの値は、示されているtの最大値についてのラムダおよびミュー値に設定されるべきである。
[0339]以下のテーブルは、いくつかの可能なレート選択パラメータセットを指定する。以下のテーブルに示されていないtの中間値についてのラムダおよびミューの値は、周辺値の間を線形補間することによって算出されるべきである。以下のテーブルに示すものを超えるtの値についてのラムダおよびミューの値は、示されているtの最大値についてのラムダおよびミュー値に設定されるべきである。
[0340]ミュー(t)≦tおよびラムダ(t)≦tという制約がすべてのtについて満たされる場合、理論的には、プレイバックにおける失速はないが、現実的な点からは、まったく失速しないがはるかに削減されたレートでプレイアウトし続けるよりもむしろ、プレイバックにおいて小さい失速を有することが好ましい場合があり、たとえば、1Mbpsから20Kbpsに急変するのは、その間に1秒間の休止があって1Mbpsから250Kbpsに急変するよりも悪い経験であり得る。ラムダおよびミューの最小値は、図36のテーブルにおいて設定され、ミュー(t)>tおよび/またはラムダ(t)>tの値について、失速が起こる見込みが高いことを注記しておく(ただし、失速は、ラムダ(t)およびミュー(t)の設定によらず、バッファが空であるときは、いずれの場合にも起こり得る)。
[0341]ここまで説明してきたように、クライアントデバイスは、HTTPを介した適合型ビデオストリーミングのためのレート適合プロセスとダウンロードプロセスとを提供することができる。インターネット(および他のネットワーク)を介してビデオをストリーミングするクライアントは、変動帯域幅の問題に直面する。高品質ビデオがストリーミングされる場合、リンクが十分に高速でないときがあり、プレーヤに割り込ませ、再バッファリングさせる。他のケースでは、低品質ビデオは、はるかに少ない帯域幅を使用するが、より劣ったユーザエクスペリエンスとなる。1つの解決策は、ビデオ品質を適応的に調整することであり、すなわち、スループットが高いときは、より良好な品質を選び、自動的に下方切替えすることである。
[0342]ただし、適応ビデオストリーミングは、いくつかの課題を提起する。すなわち、(1)ビデオレート(品質)を選ぶためのプロセスまたはアルゴリズムは、レート下落ならびにレート増大に適応するように、十分に素早く作用するべきである。同時に、早まった、または一貫性のない決定を避け、不必要なレート切替え決定を避けるべきである。クライアントは、高ビデオ品質が達成され得るように、十分に高いレートでデータをフェッチすることを目指すべきである。同時に、ダウンロードプロセスは、データが適時に受信されることを確実にすべきである。各フレームは、プレイアウトされる前に全体が受信されるべきである。これらの目標を、不必要に大きいプレイバックバッファを必要とせずに達成することができるべきである。大きいバッファのいくつかの問題は、ライブイベントの場合、バッファ中のビデオの量が、目標エンドツーエンド遅延によって制限され、これらのケースにおける可能プレイバックバッファを厳しく制限することである。また、大きいバッファへの依存は、バッファが、事前充満される必要があるので、プレイバック開始またはシーク時に望ましくない遅延を引き起こし得る。また、大きいプレイバックバッファは、たくさんのメモリを使い、モバイル電話および他のクライアントデバイスではメモリが乏しい場合がある。
[0343]これらの問題を解決するために、受信レート変化に素早く反応するレート推定のためのプロセス。レート推定は、ビデオをストリーミングする際の使用のために特別に調整された、適応ウィンドウ化平均(adaptive windowed average)であることができる。レートエスティメータは、ウィンドウイング幅(およびしたがって測定値分散)を大きく保ちながら、必要な場合にレートが十分高速に調整することを保証するような形で、ビデオバッファレベルと、ビデオバッファレベルの変化とを考慮に入れる。プロセスによって与えられる保証は、(a)Bが、レート下落が起きたときのバッファ中のビデオデータの量(プレイバック時間の秒数)である場合、エスティメータが、バッファがB/2までドレインするのにかかる時間内にそのレート推定値を調整してしまうこと、および(b)Bが、レート増大が起こっている間のバッファ中のデータの量である場合、レートエスティメータが、原則として多くとも3*Bの時間内に見られ得るように、新規レートに十分に迅速に調整する(スマートなレート変更プロセスを仮定する)ことである。
[0344]レート決定プロセスは、(a)バッファが低レベルにあるときにバッファが満たされ、(b)小さいダウンロードレート推定値が観測される場合であっても、不規則に変化するレートを回避するためにバッファを使用し、(c)安定レートシナリオでは、正しい安定レートを素早く選ぶように、レート決定を行うことができる。(a)正確なレート推定を可能にし、(b)ネットワーク遅延およびパケット損失レートが高い場合であってもリンク容量を達成することが可能であり、(c)ストリームの適時配信を達成する、HTTPのためのマルチメディアダウンロード戦略が使用される。これを達成するために、マルチプルなHTTP接続を使用し、ネットワーク条件に依存して、メディア要求をより小さいチャンク要求に分解し、TCPフロー制御メカニズムを使用して接続を同期させ、データをバースト的に要求することができる。また、接続をビジーに保つために、HTTPパイプライニングプロセスを使用することもできる。
[0345]いくつかの特徴、態様および詳細について、今まで説明してきた。説明したように、様々な実施形態において、方法ステップは、対応するプログラムされた要素、プロセッサに与えられる命令、ハードウェアまたは当業者には明らかであろう他の装置によって実施することができる。同様に、要素は、プロセスまたはプログラム要素によって有効にすることができる。実施形態の要素の構造は、プロセッサによって実行されるが、本明細書では対応する方法ステップとして記述される命令セットを単に備え得る。
[0346]様々な実施形態において、ダウンロードレート加速は、使われても使われなくてもよい。ダウンロードレート加速の例は、TCP接続を介したHTTP要求を使用することによってダウンロードを加速する方法または装置である。TCP接続は、特定のウィンドウサイズを有し、TCP接続の端部にあるノードは、ウィンドウサイズについての設定を変えることができる。1つの新規性は、連続するHTTP要求用にウィンドウサイズを設定することであり、ここでサイズは、目標ダウンロードレートの関数である。したがって、目標ダウンロードレートが変わると、TCPウィンドウサイズが変わり得る。
[0347]一実施形態では、ネットワーク経路によって結合されたソースと受信機との間のネットワーク経路を介したデータダウンロードを制御するための方法および/または装置もしくはコンピュータ可読媒体が使われ、この方法は、ソースと受信機との間の複数のTCP接続の各々について、そのTCP接続用のTCP受信機ウィンドウサイズを決定することであって、ソースと受信機との間のTCP接続が直接接続または間接接続であることができる、決定することと、メディアコンテンツ用の目標ダウンロードレートを決定することであって、目標ダウンロードレートが、少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、決定することと、複数のTCP接続の各TCP接続を使用して、ダウンロードされるべきメディアコンテンツの複数のメディアデータ要素をダウンロードすることとを備え、メディアコンテンツが、複数のHTTP要求への応答の一部分または全部であり、所与のTCP接続用の決定されたTCP受信機ウィンドウサイズは、目標ダウンロードレートに少なくとも部分的に基づいて決定され、決定されたTCP受信機ウィンドウサイズは、少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる。
[0348]現在の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接続に割り当てられ得る。
[0349]制御することはまた、ソースと受信機との間で使用するべきいくつかの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つの値の間で変わる。
[0350]一実施形態では、プレゼンテーションバッファに注目し、バッファがどの程度大きいか/満杯であるか/空であるか、すなわち、バッファのレベルがどこにあるかに基づいて、ダウンロードレートの推定を行うダウンロードレートを推定するための方法および/または装置もしくはコンピュータ可読媒体が使用される。たとえば、有限帯域幅を有するネットワーク経路によってデータソースに結合された受信機においてダウンロードレートを推定することであって、ダウンロードレートが、受信機においてネットワーク経路を介してデータが受信され得るレートであることは、受信機のプレゼンテーションバッファを監視することであって、プレゼンテーションバッファが、少なくともメディアデータが受信される時間と、受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間メディアデータを記憶する、監視することと、ダウンロードレートの推定値がそれに基づくべき非ゼロ推定期間を決定することと、推定期間にわたるバッファレベルのインジケーションを記憶することであって、所与の時間におけるバッファレベルが、プレゼンテーションバッファのうちどの程度が、少なくとも近似的に、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによってその時間に占有されるかに対応する、決定することと、記憶されたインジケーションを、推定ダウンロードレートの測度の一部として使用することとを備え得る。
[0351]プレゼンテーション要素は、ディスプレイとオーディオ出力とを備えることができる。推定期間は、所定の比例因子による、測定されたバッファレベルに比例する持続期間を有し得る。推定期間の持続期間は、測定時間におけるプレゼンテーションバッファ中の未消費のメディアデータのバイト数に比例し、および/またはプレゼンテーションバッファにメディアが追加される追加レートの関数であり、および/またはプレゼンテーションバッファの所定の部分をダウンロードするのに使用される時間に比例するようにとられ得る。所定の持続時間は、プレゼンテーションバッファのコンテンツの所定の比率がダウンロードされた持続時間に対応して得る。推定期間は、プレゼンテーションバッファのコンテンツの所定の比率がダウンロードされた時間、およびメディアデータがプレゼンテーションバッファ中に存在するプレゼンテーション時間のうち、より短い方であることができる。
[0352]一実施形態では、プレイバックレート選択のための方法および/または装置もしくはコンピュータ可読媒体が使用され、プレイバックレートは、メガビット/秒などのメモリ単位/時間で測定される、プレゼンテーションバッファからメディアが消費されるレートである。受信機が、いくつかのメディアについての要求を行うとき、そのメディアのためのプレイバックレートがある。おそらく常にではないがしばしば、より高品質のメディアが、より高いプレイバックレートを有し、したがってトレードオフを提示する。どのプレイバックレートを使用/要求するべきかは、少なくとも時には、どれだけ多くのメディアがプレゼンテーションバッファにあるかに応じて決まる。受信機は、受信機のプレゼンテーション要素を使用してプレイアウトするためのメディアを受信することもでき、ここで、プレイアウトの結果、メディアがプレゼンテーションバッファからあるプレイバックレートで消費されることになり、受信機は、複数のプレイバックレートから選択を行うように構成され、プレゼンテーションバッファを監視することであって、プレゼンテーションバッファは、少なくともメディアデータが受信される時間と受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間メディアデータを記憶する、監視することと、バッファレベルのインジケーションを記憶することであって、バッファレベルは、プレゼンテーションバッファのどの程度が、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによって占有されるかに対応する、記憶することと、推定ダウンロードレートを決定することと、目標プレイバックレートを計算するために、記憶されたインジケーションおよび推定ダウンロードレートを使用することと、目標プレイバックレートに従って複数のプレイバックレートの中から選択をすることとを備える。
[0353]選択されたプレイバックレートは、推定ダウンロードレートの所定の乗数以下であることができ、所定の乗数は、バッファレベルの増加関数である。所定の乗数は、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間のアフィン一次関数であることができ、所定の乗数は、プレゼンテーションバッファのバッファレベルがしきい量未満であるときには、1未満であることができる。所定の乗数は、プレゼンテーションバッファ中のメディアデータのプレゼンテーション持続時間が、あらかじめ設定された最大量のプレゼンテーション時間以上であるときには、1以上であることができる。所定の乗数は、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間の区分的一次関数であることができる。選択されたプレイバックレートは、推定ダウンロードレートの所定の乗数、およびプレゼンテーションバッファ中のメディアデータのバイト数の増加関数の所定の乗数以下であり得る。プレイバックレートは、比例因子にダウンロードレート推定値を乗じたもの以下である複数のプレイバックレートのうち最も大きい利用可能プレイバックレートとなるように選択されればよく、比例因子は、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間を、レート変化に対する反応時間の推定値で除算したものの増加関数である。反応時間は、メディアデータ中の切替え点の間のプレゼンテーション時間に対する上限であり得、および/または反応時間の推定値は、メディアデータ中の切替え点の間のプレゼンテーション時間に関する平均であり得る。反応時間の推定値は、所定の定数に推定ラウンドトリップ時間(「ERTT」)を乗じたもの以上であり得る。
[0354]受信機のプレゼンテーション要素を使用してプレイアウトするためのメディアを受信する受信機であって、プレイアウトの結果、メディアがプレゼンテーションバッファからプレイバックレートで消費され、受信機は、複数のプレイバックレートから選択するように構成され、プレゼンテーションバッファを監視することであって、プレゼンテーションバッファは、少なくともメディアデータが受信される時間と、受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間のメディアデータを記憶する、監視することと、バッファレベルのインジケーションを記憶することであって、バッファレベルが、プレゼンテーションバッファのうちどの程度が、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによって占有されるかに対応する、記憶することと、バッファレベルの許容分散を決定することと、記憶されたバッファレベルインジケーションとバッファレベルの許容分散とを使用して、目標プレイバックレートを計算することと、目標プレイバックレートに従って複数のプレイバックレートの中から選択することと、を行うための方法または装置を備え得る。
[0355]プレイバックレートは、上位比例因子(upper proportional factor)、下位比例因子(lower proportional factor)、ダウンロードレート推定値、現在のプレイバックレート、バッファレベル、およびレート変化に対する反応時間の推定値に基づいて選択することができる。上位比例因子および下位比例因子は両方とも、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間を、レート変化に対する反応時間の推定値で除算したものの増加関数および/または区分的一次関数であることができ、上位比例因子は、下位比例因子よりも大きいものまたは下位比例因子に等しいものである。プレイバックレートは、前のプレイバックレートが、下位比例因子に推定ダウンロードレートを乗じたものと、上位比例因子にダウンロードレート推定値を乗じたものとの間にあるときには、前のプレイバックレートと同じになるように選択されることができる。プレイバックレートは、前のプレイバックレートが、上位比例因子にダウンロードレート推定値を乗じたものを上回るときには、上位比例因子に推定ダウンロードレートを乗じたもの以下の最も大きい利用可能プレイバックレートになるように選択されることができる。プレイバックレートは、前のプレイバックレートが、下位比例因子にダウンロードレート推定値を乗じたものを下回るときには、下位比例因子に推定ダウンロードレートを乗じたもの以下の最も大きい利用可能プレイバックレートになるように選択されることができる。
[0356]一実施形態では、要求を行うためであるが、プロセス要求において取り消すかどうか決定するためでもある方法および/または装置もしくはコンピュータ可読媒体が使用される。受信機は、メディアのセグメント/部分/フラグメントについての要求を行い、要求に対する応答を受信し、応答からのメディアを記憶し、可能性として別の要求を行うとき、要求を取り消し、異なる要求を発行すること好ましいと決定してよい。メディアのプレイバックレートは、最もアグレッシブであるとともに、プレゼンテーションバッファ中のメディアを、消費されるときに使い果たすことなく取得することを期待する最も高いプレイバックレートを選択する受信機によって決定することもできる。ダウンロードレートが予期せぬほど下がった場合、受信機は、その現在の要求を取り消し、より低いプレイバックレートメディアについての新規要求を行うか、それとも現在の要求をプレイアウトさせるか決定する。高プレイバックレート要求を取り消し、より低いプレイバックレート要求で置き換えると、プレゼンテーションバッファのコンテンツがより長く続くことになる場合があるが、要求ミッドストリームを取り消すと、その要求についてのどの部分的に受信されたメディアの損失も引き起こす場合がある。
[0357]そのような一実施形態において、受信機は、受信機のプレゼンテーション要素を使用してプレイアウトするためのメディアを受信し、プレイアウトの結果、メディアは、プレゼンテーションバッファから一定のプレイバックレートで消費され、受信機は、複数のプレイバックレートから選択をするように構成される。要求アクションを決定することは、プレゼンテーションバッファを監視することであって、プレゼンテーションバッファが、少なくともメディアデータが受信される時間と、受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間、メディアデータを記憶する、監視することと、バッファレベルのインジケーションを記憶することであって、バッファレベルが、プレゼンテーションバッファのうちどの程度が、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによって占有されるかに対応する、記憶することと、選択された第1のメディアデータチャンクをダウンロードするために、および発行された要求が未処理のときに、発行された要求の状態を維持することと、ネットワーク条件および発行された要求の状態に基づいて、要求を続けるか、それとも要求を取り消すかを決定することとを備える。
[0358]要求を続けるか、それとも要求を取り消すかを決定することは、第1のメディアデータがプレイアウトされる前に、要求についてのダウンロードを完了するのに十分な時間があるかどうか決定することと、十分な時間がない場合、要求を取り消すこととを備えることができる。要求を続けるか、それとも要求を取り消すかを決定することは、選択された第1のチャンクまたは選択された第2のチャンクのいずれかがプレイアウトされることになる前に、より高レートの第2のチャンクをダウンロードするのに十分な時間があるかどうか決定することと、十分な時間がある場合、要求を取り消し、第2のチャンクについての要求を発行することとをさらに備えることができる。要求を続けるか、それとも要求を取り消すかを決定することは、ダウンロードレートおよびメディア消費レートに基づいて、失速が起こることを検出することと、プレゼンテーション要素が、消費されるメディアによって指示されたレートでメディアデータを消費することができない時間と、プレゼンテーション要素が、消費されるメディアによって指示されたレートでメディアデータの消費を再開することができる時間との間の失速期間を推定することと、継続または取消しが失速期間に対して与える効果を決定することと、要求の取消しが失速期間を短縮することになる場合、要求を取り消すこととをさらに備えることができる。
[0359]他の特徴は、第2のメディアデータチャンクを選択することであって、第2のメディアデータチャンクが、開始プレゼンテーション時間を有し、その開始プレゼンテーション時間が、第1のメディアデータチャンクと同じ開始プレゼンテーション時間である、選択することと、第2のメディアデータチャンクのダウンロードを要求することと、第2のメディアデータチャンクを選択することであって、第2のメディアデータチャンクが、開始プレゼンテーション時間を有し、その開始プレゼンテーション時間が、第1のメディアデータチャンクの開始プレゼンテーション時間よりも後である、選択することと、第2のメディアデータチャンクのダウンロードを要求することとを含んでもよい。第2のメディアデータチャンクは、受信機にとって利用可能な第1のチャンクの開始プレゼンテーション時間のものと比較した、その開始プレゼンテーション時間が、最も低い差となるように、および/またはそのプレイバックが、その開始プレゼンテーション時間と第1のメディアデータチャンクの開始プレゼンテーション時間との間の所定の最大ギャップをもつ最大プレイバックレートとなるように、受信機によって選ぶこともできる。
[0360]いくつかの実施形態は、第1のメディアデータチャンクのうち残っている部分のダウンロードが、プレイバック用の時間内に完了できないかどうか決定することと、第2のメディアデータチャンクのダウンロードが、プレイバック用の時間内に完了され得るかどうか決定することと、要求を続けるか、それとも第1のメディアデータチャンクについての要求を取り消し、代わりに第2のメディアデータチャンクを要求するかの決定を、第1のメディアデータチャンクのうち残っている部分のダウンロードが、プレイバック用の時間内に完了できないかどうか、および第2のメディアデータチャンクのダウンロードが、プレイバック用の時間内に完了され得るかどうかに基づかせることとを含み得る。第2のデータチャンク中のメディアデータのプレイバックレートは、受信機においてサポートされる最も高いプレイバックレートとなるように選ばれることができる。受信機は、すでにプレゼンテーションバッファ中にある少なくともいくらかのメディアデータのプレゼンテーション時間をカバーするメディアデータを要求し、要求されたメディアデータをダウンロードし、要求されたメディアデータをプレイアウトし、すでにプレゼンテーションバッファ中にある対応するメディアデータのうち少なくともいくつかを破棄してもよい。要求されたメディアデータのプレイバックレートは、プレゼンテーションバッファから破棄される対応するメディアデータの最大プレゼンテーション持続時間に対する制約を受ける、最大のプレイバックレートであり得る。要求されるメディアデータは、その開始プレゼンテーション時間が、受信機にとって利用可能な最も早い開始プレゼンテーション時間になるように選ばれ得る。
[0361]いくつかの受信機において、ダウンロードは、バッファレベルに依存し、受信機は、高ウォーターマークおよび低ウォーターマークの概念を使用する。そのような受信機において、メディアデータは、ソースからダウンロードされ、受信機のプレゼンテーションバッファに記憶される。プレゼンテーションバッファの充満レベル(または単に「レベル」)が決定され、ここで充満レベルは、プレゼンテーションバッファのどのような部分が、プレゼンテーション要素によってまだ消費されていないメディアデータを含むかを表す。充満レベルが高充満しきい値(「高ウォーターマーク」)を上回る場合、ダウンロードは停止し、充満レベルが低充満しきい値(「低いウォーターマーク」)を下回る場合、ダウンロードはリスタートする。充満レベルは、プレゼンテーション要素によってメディアデータが消費されると、アップデートされ得る。充満レベルは、メモリ記憶容量の単位および/またはプレゼンテーション時間の単位で測ることができる。ダウンロードは、推定ラウンドトリップ時間(「ERTT」)に基づくことができ、ERTTは、メディアデータダウンロードがリスタートされるとリセットされる。ダウンロードが複数のTCP接続を介して起きた場合、メディアデータダウンロードがリスタートされると、使用されるいくつかのTCP接続はリセットされ得る。高充満しきい値および低充満しきい値は、時間とともに変化しうる。
[0362]本開示を読んだ後には、当業者にはさらなる実施形態が想起され得る。他の実施形態では、上で開示された発明の組合せまたは副次的な組合せが、有利に行われ得る。コンポーネントの例示的な構成は例示を目的に示され、組合せ、追加、再構成などが、本発明の代替的な実施形態において考えられることを理解されたい。したがって、本発明は、例示的な実施形態に関して説明されてきたが、多数の修正が可能であることを当業者は認識するだろう。
[0363]たとえば、本明細書で説明される処理は、ハードウェアコンポーネント、ソフトウェアコンポーネント、および/またはこれらの任意の組合せを使用して実施され得る。したがって、本明細書および図面は、限定的な意味ではなく例示的であると解釈されるべきである。しかしながら、特許請求の範囲において述べられるような本発明のより広い趣旨および範囲から逸脱することなく、様々な修正および変更を行うことができ、本発明は、以下の特許請求の範囲内にあるすべての修正と等価物とを包含することが意図されることは、明らかである。
Claims (32)
- ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御する方法であって、
前記ソースと前記受信機との間の複数のTCP接続の各々について、そのTCP接続用のTCP受信機ウィンドウサイズを決定することであって、前記ソースと前記受信機との間のTCP接続が直接接続または間接接続であることができる、決定することと、
前記複数のTCP接続の各々について、メディアコンテンツ用の目標ダウンロードレートを決定することであって、前記目標ダウンロードレートが、少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、決定することと、
ダウンロードされるべき前記メディアコンテンツの複数のメディアデータ要素をダウンロードするために、前記複数のTCP接続の各TCP接続を使用することであって、前記メディアコンテンツが、複数のHTTP要求への応答の一部分または全部である、使用することとを備え、
所与のTCP接続用の前記決定されたTCP受信機ウィンドウサイズが、そのTCP接続用の前記目標ダウンロードレートに少なくとも部分的に基づいて決定され、前記決定されたTCP受信機ウィンドウサイズが、前記少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、方法。 - 現在のTCP接続用の前記決定されたTCP受信機ウィンドウサイズが、乗数レートで乗算された、前記現在のTCP接続についての現在の推定ラウンドトリップ時間(「ERTT」)の積に少なくとも部分的に基づいて決定され、前記乗数レートが、前記現在のTCP接続用の前記目標ダウンロードレートと、前記目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である、請求項1に記載の方法。
- 前記現在のERTTが、少なくとも部分的に、直前の測定期間にわたる最小の観測されたRTTの測度によって決定される、請求項2に記載の方法。
- 前記直前の測定期間が、10秒またはそれ以下の期間に対応する、請求項3に記載の方法。
- 前記現在のERTTが、少なくとも部分的には、休止期間の終了時の測度によって決定され、前記休止期間が、前記複数のTCP接続を介したアクティブHTTP要求が、所定の継続時間期間だけ存在していなかった期間である、請求項2に記載の方法。
- TCP接続用の前記目標ダウンロードレートが、使用中のすべてのTCP接続にわたる現在の総ダウンロードレートを、使用中のTCP接続の数で除算したものに比例する、請求項1に記載の方法。
- TCP接続用の前記目標ダウンロードレートが、使用中のすべてのTCP接続にわたる現在の総ダウンロードレートを、使用中のTCP接続の数で除算したものの2倍である、請求項1に記載の方法。
- 前記目標ダウンロードレートが、前記メディアコンテンツのプレイバックレートに比例し、前記プレイバックレートが、使用中のすべてのTCP接続に及ぶ総計にわたるレートを、使用中のTCP接続の数で除算したものである、請求項1に記載の方法。
- 各メディアデータ要素が、所定の分散範囲内のサイズを有するいくつかのチャンクに分割され、そのようなチャンクの数が、使用中のTCP接続の数に基づく、請求項1に記載の方法。
- そのようなチャンクの前記数が、現在のTCP接続についての現在の推定ラウンドトリップ時間(「ERTT」)、現在のダウンロードレート、および/または要求されているメディアフラグメントのサイズのうち少なくとも1つにさらに基づく、請求項9に記載の方法。
- 前記所定の分散範囲がゼロであり、したがって各チャンクがフラグメント要求ごとに同じサイズを有し、前記チャンクの数が、使用中のTCP接続の数に所定の因子を乗じたものに等しい、請求項9に記載の方法。
- 各チャンクが、最小バイト数以上のサイズを有する、請求項9に記載の方法。
- 後続メディアデータ要素についての後のHTTP要求が、第1の利用可能TCP接続に割り当てられる、請求項1に記載の方法。
- ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御する方法であって、
メディアコンテンツ用の目標ダウンロードレートを決定することであって、前記目標ダウンロードレートが、少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、決定することと、
前記ネットワーク経路に関する少なくとも1つのネットワーク条件を決定することと、
前記ソースと前記受信機の間で使用するべきTCP接続の数を決定することであって、前記数が1よりも大きく、使用するべきTCP接続の前記数が、少なくとも部分的に、前記決定された少なくとも1つのネットワーク条件に基づいて決定される、決定することと、
ダウンロードされるべき前記メディアコンテンツの複数のメディアデータ要素をダウンロードするために、前記数のTCP接続の各々を使用することであって、前記メディアコンテンツが、複数のHTTP要求への応答の一部分または全部である、使用することとを備える方法。 - 使用中のTCP接続の前記数が、TCP接続についての推定ラウンドトリップ時間(「ERTT」)、前記目標ダウンロードレート、および損失レートの推定値に少なくとも部分的に基づいて決定される、請求項14に記載の方法。
- 前記損失レートが、1%または0.1%であると推定される、請求項15に記載の方法。
- 使用するべきTCP接続の前記数が、両端値を含む2と16との間に制限され、および/または(a)前記目標ダウンロードレート、(b)推定ラウンドトリップ時間(「ERTT」)、および(c)推定損失レートの平方根の積に比例する、請求項14に記載の方法。
- 前記TCP接続の各々について、前記目標ダウンロードレートに少なくとも部分的に基づいて決定される、そのTCP接続用のTCP受信機ウィンドウサイズを決定することであって、前記決定されたTCP受信機ウィンドウサイズが、前記少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、決定することをさらに備える、請求項14に記載の方法。
- ネットワーク経路を介したソースからネットワークを介してデータをダウンロードする受信機であって、
前記ネットワークからデータを受信するための受信機回路と、
プロセスを実行するためのプロセッサと、
データを記憶するためのメモリと、
TCP接続用のTCP受信機ウィンドウサイズを含む、前記ソースと前記受信機との間の複数のTCP接続に関連したデータのためのストレージであって、前記ソースと前記受信機との間のTCP接続が、直接接続または間接接続であることができる、ストレージと、
メディアコンテンツ用の目標ダウンロードレートを決定するための論理であって、前記目標ダウンロードレートが、少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、論理と、
前記メディアコンテンツの複数のメディアデータ要素をダウンロードした結果のためのストレージであって、前記メディアコンテンツが、複数のHTTP要求への応答の一部分または全部であるストレージとを備え、
所与のTCP接続用の前記決定されたTCP受信機ウィンドウサイズが、前記目標ダウンロードレートに少なくとも部分的に基づくサイズであり、決定されたTCP受信機ウィンドウサイズが、前記少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、受信機。 - 現在のTCP接続用の前記決定されたTCP受信機ウィンドウサイズが、乗数レートで乗算された、前記現在のTCP接続についての現在の推定ラウンドトリップ時間(「ERTT」)の積であり、前記乗数レートが、前記現在のTCP接続用の前記目標ダウンロードレートと、前記目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である、請求項19に記載の受信機。
- 前記現在のERTTが、直前の測定期間にわたる最小の観測されたRTTの測度である、請求項20に記載の受信機。
- 前記現在のERTTが、少なくとも部分的には、休止期間に続くダウンロード期間中の測度によって決定され、前記休止期間が、前記TCP接続を介したアクティブHTTP要求が、所定の継続時間期間だけ存在していなかった期間である、請求項20に記載の受信機。
- 前記目標ダウンロードレートが、使用中のすべてのTCP接続にわたる現在の総ダウンロードレートを、使用中のTCP接続の数で除算したものに比例する、請求項19に記載の受信機。
- 各メディアデータ要素が、所定の分散範囲内のサイズを有するいくつかのチャンクに分割され、そのようなチャンクの数が、使用中のTCP接続の数、現在のTCP接続についての現在の推定ラウンドトリップ時間(「ERTT」)、現在のダウンロードレート、および/または要求されるメディアフラグメントのサイズのうち少なくとも1つに基づく、請求項19に記載の受信機。
- ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御するためのプロセッサによって実行するための非一時的コンピュータ可読媒体であって、
前記ソースと前記受信機との間の複数のTCP接続の各々について、そのTCP接続用のTCP受信機ウィンドウサイズを決定するためのプログラムコードであって、前記ソースと前記受信機の間のTCP接続が直接接続または間接接続であることができる、プログラムコードと、
メディアコンテンツ用の目標ダウンロードレートを決定するためのプログラムコードであって、前記目標ダウンロードレートが少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、プログラムコードと、
前記複数のTCP接続の各TCP接続を使用して、ダウンロードされるべき前記メディアコンテンツの複数のメディアデータ要素をダウンロードするためのプログラムコードであって、前記メディアコンテンツが複数のHTTP要求への応答の一部分または全部である、プログラムコードと、
前記目標ダウンロードレートに少なくとも部分的に基づいて、所与のTCP接続用のTCP受信機ウィンドウサイズを決定するためのプログラムコードであって、前記決定されたTCP受信機ウィンドウサイズが前記少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、プログラムコードと、を備える非一時的コンピュータ可読媒体。 - 現在のTCP接続用の前記決定されたTCP受信機ウィンドウサイズが、前記現在のTCP接続についての現在の推定ラウンドトリップ時間(「ERTT」)を乗数レートで乗算した積に少なくとも部分的に基づいて決定され、前記乗数レートは、前記現在のTCP接続用の前記目標ダウンロードレートと、前記目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である、請求項25に記載の非一時的コンピュータ可読媒体。
- 前記現在のERTTが、少なくとも部分的に、直前の測定期間にわたる最小の観測されたRTTの測度によって、または休止期間に続くダウンロード期間中の測度によって決定され、前記休止期間が、前記複数のTCP接続を介したアクティブHTTP要求が、所定の継続時間期間だけ存在していなかった期間である、請求項26に記載の非一時的コンピュータ可読媒体。
- 前記目標ダウンロードレートが、使用中のすべてのTCP接続を介した前記メディアコンテンツのプレイバックレートまたは現在の総ダウンロードレートを、使用中のTCP接続の数で除算したものに比例する、請求項25に記載の非一時的コンピュータ可読媒体。
- ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御するためのプロセッサによって実行するための非一時的コンピュータ可読媒体であって、
メディアコンテンツ用の目標ダウンロードレートを決定するためのプログラムコードであって、前記目標ダウンロードレートが少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、プログラムコードと、
前記ネットワーク経路に関する少なくとも1つのネットワーク条件を決定するためのプログラムコードと、
前記ソースと前記受信機との間で使用するべきTCP接続の数を決定するためのプログラムコードであって、前記数が1よりも大きく、使用するべきTCP接続の前記数が、少なくとも部分的に、前記決定された少なくとも1つのネットワーク条件に基づいて決定される、プログラムコードと、
前記数のTCP接続の各々を使用して、ダウンロードされるべき前記メディアコンテンツの複数のメディアデータ要素をダウンロードするためのプログラムコードであって、前記メディアコンテンツが複数のHTTP要求への応答の一部分または全部である、プログラムコードと、を備える非一時的コンピュータ可読媒体。 - 使用中のTCP接続の前記数が、TCP接続についての推定ラウンドトリップ時間(「ERTT」)、前記目標ダウンロードレート、および損失レートの推定値に少なくとも部分的に基づく、請求項29に記載の非一時的コンピュータ可読媒体。
- 使用するべきTCP接続の前記数が、両端値を含む2と16との間であり、および/または(a)前記目標ダウンロードレート、(b)推定ラウンドトリップ時間(「ERTT」)、および(c)推定損失レートの平方根の積に比例する、請求項29に記載の非一時的コンピュータ可読媒体。
- 前記目標ダウンロードレートに少なくとも部分的に基づいてTCP接続用のTCP受信機ウィンドウサイズを決定するためのプログラムコードをさらに備え、前記TCP受信機ウィンドウサイズが、前記少なくとも2つの連続するHTTP要求についての少なくとも2つの値の間で変わる、請求項29に記載の非一時的コンピュータ可読媒体。
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,796 US20140136653A1 (en) | 2012-02-27 | 2013-01-19 | Dash client and receiver with download rate acceleration |
US13/745,796 | 2013-01-19 | ||
PCT/US2013/027806 WO2013130472A1 (en) | 2012-02-27 | 2013-02-26 | Controlling http streaming between a source and a receiver over multiple tcp connections |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2015515173A true JP2015515173A (ja) | 2015-05-21 |
JP2015515173A5 JP2015515173A5 (ja) | 2016-03-24 |
Family
ID=47891978
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014558947A Withdrawn JP2015515173A (ja) | 2012-02-27 | 2013-02-26 | マルチプルなtcp接続を介したソースと受信機との間のhttpストリーミングの制御 |
Country Status (5)
Country | Link |
---|---|
US (1) | US20140136653A1 (ja) |
EP (1) | EP2820818A1 (ja) |
JP (1) | JP2015515173A (ja) |
CN (1) | CN104205771A (ja) |
WO (1) | WO2013130472A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017225044A (ja) * | 2016-06-16 | 2017-12-21 | Kddi株式会社 | コンテンツ配信システムのクライアント装置、コンテンツの取得方法及びプログラム |
Families Citing this family (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
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 |
JP6180524B2 (ja) | 2012-07-09 | 2017-08-16 | ヴィド スケール インコーポレイテッド | 電力認識型ビデオ復号およびストリーミング |
US9357021B2 (en) | 2013-03-14 | 2016-05-31 | Comcast Cable Communications, Llc | Delivery of content |
US9197572B2 (en) * | 2013-03-15 | 2015-11-24 | The Regents Of The University Of California | Throughput enabled rate adaptation in wireless networks |
GB201310665D0 (en) * | 2013-06-14 | 2013-07-31 | Microsoft Corp | Rate Control |
US9100618B2 (en) | 2013-06-17 | 2015-08-04 | Spotify Ab | System and method for allocating bandwidth between media streams |
US10097604B2 (en) * | 2013-08-01 | 2018-10-09 | Spotify Ab | System and method for selecting a transition point for transitioning between media streams |
US9529888B2 (en) | 2013-09-23 | 2016-12-27 | Spotify Ab | System and method for efficiently providing media and associated metadata |
US20150271226A1 (en) * | 2014-03-18 | 2015-09-24 | Qualcomm Incorporated | Transport accelerator implementing a multiple interface architecture |
IL231685A (en) * | 2014-03-24 | 2015-09-24 | Giraffic Technologies Ltd | A system and method for predicting memory reduction and network design |
US20160212054A1 (en) * | 2015-01-20 | 2016-07-21 | Microsoft Technology Licensing, Llc | Multiple Protocol Media Streaming |
KR102078869B1 (ko) | 2015-03-17 | 2020-02-18 | 삼성전자주식회사 | 데이터 전송률 향상을 위한 다중 연결 제어 방법 및 장치 |
GB2537459B (en) * | 2015-06-03 | 2017-06-21 | Bridgeworks Ltd | Transmitting data |
US20180205802A1 (en) * | 2017-01-13 | 2018-07-19 | Cisco Technology, Inc. | Cache Aware Streaming |
US10084855B2 (en) * | 2017-01-23 | 2018-09-25 | Akamai Technologies, Inc. | Pixel-based load balancing |
US10425456B2 (en) * | 2017-11-29 | 2019-09-24 | Bank Of America Corporation | Request processing system using a splitting engine |
CN111866549B (zh) | 2019-04-29 | 2023-03-24 | 腾讯科技(深圳)有限公司 | 一种视频处理方法及装置、终端、存储介质 |
US11061656B1 (en) * | 2019-05-07 | 2021-07-13 | PODTRAC, Inc. | System and method for providing analysis of download completeness for downloadable media |
CN112040302B (zh) * | 2019-06-03 | 2023-01-03 | 优视科技有限公司 | 视频缓冲方法、装置、电子设备及计算机可读存储介质 |
US11070607B2 (en) * | 2019-07-22 | 2021-07-20 | DAZN Limited | Dynamic behavior modification for content download and playback |
CN111093110B (zh) * | 2019-12-03 | 2021-02-12 | 华为技术有限公司 | 一种http请求传输方法及设备 |
CN111131019B (zh) * | 2019-12-12 | 2021-06-22 | 华为技术有限公司 | 一种多路http通道复用的方法及终端 |
CN112819624B (zh) * | 2021-02-01 | 2024-04-16 | 上交所技术有限责任公司 | 一种适用于证券交易系统的低时延分布式流控方法 |
CN118044208A (zh) * | 2021-09-30 | 2024-05-14 | 杜比实验室特许公司 | 用于多源传递的数据速率和缓冲区估计的方法 |
CN114579152B (zh) * | 2022-05-06 | 2022-07-29 | 中科亿海微电子科技(苏州)有限公司 | 一种fpga下载器及其下载速度调节方法 |
CN115119216B (zh) * | 2022-06-24 | 2024-05-14 | 深圳友讯达科技股份有限公司 | 一种常供电的LoRaWAN网络通信方法及系统 |
Family Cites Families (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7061856B2 (en) * | 2001-02-05 | 2006-06-13 | The Board Of Trustees Of The Leland Stanford Junior University | Data throughput over lossy communication links |
AU2002316128A1 (en) * | 2001-05-18 | 2002-12-03 | 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 |
US7542471B2 (en) * | 2002-10-30 | 2009-06-02 | Citrix Systems, Inc. | Method of determining path maximum transmission unit |
JP4433202B2 (ja) * | 2003-07-11 | 2010-03-17 | 日本電気株式会社 | トランスポート層中継方法及びトランスポート層中継装置並びにプログラム |
US7516238B2 (en) * | 2003-09-30 | 2009-04-07 | Microsoft Corporation | Background transport service |
US7675856B2 (en) * | 2005-03-24 | 2010-03-09 | Microsoft Corporation | Bandwidth estimation in broadband access networks |
US7701853B2 (en) * | 2005-09-30 | 2010-04-20 | Alcatel-Lucent Usa Inc. | Method for policing-based adjustments to transmission window size |
US8150995B2 (en) * | 2005-09-30 | 2012-04-03 | Microsoft Corporation | Receive window auto-tuning |
US7783773B2 (en) * | 2006-07-24 | 2010-08-24 | Microsoft Corporation | Glitch-free media streaming |
US7821937B1 (en) * | 2007-06-29 | 2010-10-26 | Symantec Corporation | Network protocol with damage loss resilient congestion control algorithm |
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 |
EP2398273B1 (en) * | 2010-06-18 | 2018-02-14 | Acer Incorporated | Method of handling buffer status report and communication device thereof |
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 |
US8903952B2 (en) * | 2011-08-16 | 2014-12-02 | Arris Enterprises, Inc. | Video streaming using adaptive TCP window size |
-
2013
- 2013-01-19 US US13/745,796 patent/US20140136653A1/en not_active Abandoned
- 2013-02-26 WO PCT/US2013/027806 patent/WO2013130472A1/en active Application Filing
- 2013-02-26 JP JP2014558947A patent/JP2015515173A/ja not_active Withdrawn
- 2013-02-26 EP EP13710174.7A patent/EP2820818A1/en not_active Withdrawn
- 2013-02-26 CN CN201380016038.1A patent/CN104205771A/zh active Pending
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017225044A (ja) * | 2016-06-16 | 2017-12-21 | Kddi株式会社 | コンテンツ配信システムのクライアント装置、コンテンツの取得方法及びプログラム |
Also Published As
Publication number | Publication date |
---|---|
CN104205771A (zh) | 2014-12-10 |
US20140136653A1 (en) | 2014-05-15 |
WO2013130472A1 (en) | 2013-09-06 |
EP2820818A1 (en) | 2015-01-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP6054427B2 (ja) | プレイバックレート選択を伴う改良されたdashクライアントおよび受信機 | |
JP2015511782A (ja) | ダウンロードレートエスティメータを備えた改良されたdashクライアントおよび受信機 | |
JP2015515173A (ja) | マルチプルなtcp接続を介したソースと受信機との間のhttpストリーミングの制御 | |
JP2015513840A5 (ja) | ||
CA2888218C (en) | Playback stall avoidance in adaptive media streaming | |
US20150271231A1 (en) | Transport accelerator implementing enhanced signaling | |
US20080256272A1 (en) | Packet Scheduling for Data Stream Transmission | |
EP2993911A1 (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 medium | |
EP4005175B1 (en) | Dynamic behavior modification for content download and playback |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20160202 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20160202 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20170127 |
|
A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20170130 |