JP2015515173A - マルチプルなｔｃｐ接続を介したソースと受信機との間のｈｔｔｐストリーミングの制御 - Google Patents

マルチプルなｔｃｐ接続を介したソースと受信機との間のｈｔｔｐストリーミングの制御 Download PDF

Info

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
Application number
JP2014558947A
Other languages
English (en)
Other versions
JP2015515173A5 (ja
Inventor
ルビー、マイケル・ジョージ
ミンダー、ロレンツ・クリストフ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2015515173A publication Critical patent/JP2015515173A/ja
Publication of JP2015515173A5 publication Critical patent/JP2015515173A5/ja
Withdrawn legal-status Critical Current

Links

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

クライアントデバイスは、ストリーミングメディアを提示し、ストリームを制御するためのストリームマネージャと、コンテンツについてのネットワーク要求を行うための要求アクセラレータと、ストリームマネージャおよび要求アクセラレータに結合された、どの要求を行うか決定するためのソースコンポーネントと、ネットワーク接続と、メディアプレーヤとを含む。要求アクセラレータは、複数のＴＣＰ接続を使用してダウンロードレートを加速させることができる。目標ダウンロードレートは、ＨＴＴＰ要求の間で変わり得る。所与のＴＣＰ接続用のＴＣＰ受信機ウィンドウサイズは、そのＴＣＰ接続用の目標ダウンロードレートおよび／または現在のＴＣＰ接続用の現在の推定ラウンドトリップ時間を、乗数レートで乗算したものに基づくことができ、乗数レートは、現在のＴＣＰ接続用の目標ダウンロードレートと、目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である。

Description

関連出願の相互参照
[0001]本出願は、参照によってその内容全体がすべての目的のために本明細書に組み込まれている、２０１２年２月２７日に出願された、「Improved DASH Client and Receiver with Rate Adaptation and Downloading for Adaptive Video」と題する米国仮出願第６１／６０３，５６９号の利益を主張する。
[0002]ＤＡＳＨは、「動的適応ストリーミングオーバーＨＴＴＰ（Dynamic Adaptive Streaming over HTTP）」を指す。ＤＡＳＨを使用して、コンテンツプロバイダは、コンテンツを、ＭＰＤファイルなど、関連付けられたメタデータとともに、セグメント、フラグメント、リプレゼンテーション（representations）、アダプテーション（adaptations）などにフォーマットし、それらすべてを、標準ＨＴＴＰサーバまたは特殊化ＨＴＴＰサーバを経由して、利用可能なファイルとして記憶する。ＤＡＳＨクライアントとは、これらのファイルを必要に応じて取得して、ＤＡＳＨクライアントのユーザにプレゼンテーションを提示する受信機である。
[0003]ユーザが通常、ネットワークが制限されている環境において、事前告知がほとんどまたはまったくなしで高品質ストリーミングを望むので、ＤＡＳＨクライアントは、厳しい制約を有する。したがって、改良されたＤＡＳＨクライアントが望まれる。
[0004]クライアントデバイスは、ストリーミングメディアを提示し、ストリームを制御するためのストリームマネージャと、コンテンツについてのネットワーク要求を行うための要求アクセラレータと、どの要求を行うか決定するための、ストリームマネージャおよび要求アクセラレータに結合されたソースコンポーネントと、ネットワーク接続と、メディアプレーヤとを含む。要求アクセラレータは、要求をバッファリングするための要求データバッファと、アクセラレータが応答することができる各要求に完了応答を戻すための論理とを備える。ストリームマネージャ、要求アクセラレータ、およびソースコンポーネントは、プロセッサ命令またはプログラムコードとして実装されることができ、クライアントデバイスは、プログラムメモリと、ワーキングメモリと、プロセッサと、電力源とをさらに備える。クライアントデバイスはまた、ディスプレイとユーザ入力デバイスとを含み得る。クライアントタスクは、効率的にデータをストリーミングするために、ソースコンポーネント、ストリームマネージャ、および要求アクセラレータの間でパースされる。
[0005]様々な態様において、本明細書に記載するように、クライアントは、リプレゼンテーションを維持し、または別のリプレゼンテーションに切り替えるべきときを決定するなどの動作を実施し、どのフラグメントを要求するか決定し、メディアプレーヤが、ほとんどの条件において、失速（stalling）することなくストリームを継続するのに十分なデータを確実に取得できるようにすることができる。
[0006]ソースと受信機との間の複数のＴＣＰ接続を有すること、そして、それら接続の各々について、そのＴＣＰ接続用のＴＣＰ受信機ウィンドウサイズを決定することであって、ソースと受信機との間のＴＣＰ接続が直接接続または間接接続であることができる、決定すること、および複数のＴＣＰ接続の各々について、メディアコンテンツ用の目標ダウンロードレートを決定することであって、目標ダウンロードレートが、少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、決定すること、ダウンロードされるべきメディアコンテンツの複数のメディアデータ要素をダウンロードするために、複数のＴＣＰ接続の各ＴＣＰ接続を使用することであって、メディアコンテンツが、複数のＨＴＴＰ要求への応答の一部分または全部であり、所与のＴＣＰ接続用の決定されたＴＣＰ受信機ウィンドウサイズが、そのＴＣＰ接続用の目標ダウンロードレートに少なくとも部分的に基づいて決定され、決定されたＴＣＰ受信機ウィンドウサイズが、少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、使用することによって、ダウンロードレートが、ソースと受信機との間でネットワーク経路を通じて加速され得る。ダウンロードレート加速のための方法および装置が提供される。
[0007]決定されたＴＣＰ受信機ウィンドウサイズは、乗数レート（multiplier rate）で乗算された、現在のＴＣＰ接続についての現在の推定ラウンドトリップ時間（「ＥＲＴＴ」（estimated round-trip time））に基づいて決定されることができ、乗数レートは、現在のＴＣＰ接続用の目標ダウンロードレート、および目標ダウンロードレートよりも所定の量だけ高いレートによって制限される範囲内である。現在のＥＲＴＴは、履歴により、おそらくはＴＣＰ接続を介したアクティブＨＴＴＰ要求が所定の継続時間期間にわたって存在していなかった休止期間の終了時の測度に基づいて、決定され得る。ＴＣＰ接続についての目標ダウンロードレートは、使用中のすべてのＴＣＰ接続を通じた現在の総ダウンロードレートを、使用中のＴＣＰ接続の数で除算したものに比例するものであることができ、たとえば、ＴＣＰ接続についての目標ダウンロードレートは、使用中のすべてのＴＣＰ接続にわたる現在の総ダウンロードレートを、使用中のＴＣＰ接続の数で除算したものの２倍である。目標ダウンロードレートは、メディアコンテンツのプレイバックレートに比例してよく、プレイバックレートは、使用中のすべてのＴＣＰ接続に及ぶ総計にわたるレートを、使用中のＴＣＰ接続の数で除算したものである。各メディアデータ要素は、所定の分散範囲内のサイズを有するいくつかのチャンクへと分けられてもよく、そのようなチャンクの数は、使用中のＴＣＰ接続の数、現在のＴＣＰ接続についての現在のＥＲＴＴ、現在のダウンロードレート、および／または要求されているメディアフラグメントのサイズに基づく。所定の分散範囲はゼロであり得、および／または各チャンクは、最小バイト数以上のサイズを有し得る。後続メディアデータ要素についての後のＨＴＴＰ要求が、第１の利用可能ＴＣＰ接続に割り当てられることができる。
[0008]いくつかの実施形態では、ソースと受信機との間のネットワーク経路を介したダウンロードは、メディアコンテンツ用の目標ダウンロードレートを決定することと、ネットワーク経路に関するネットワーク条件を決定することと、ネットワーク条件に基づいて、ソースと受信機との間で使用すべきいくつかのＴＣＰ接続を決定することと、複数のＨＴＴＰ要求への応答の一部分または全部として、複数のメディアデータ要素をダウンロードするために、ＴＣＰ接続の各々を使用することとを備える。ＴＣＰ接続の数は、２と１６との間であり、および／または目標ダウンロードレート、ＥＲＴＴ、および推定損失レートの平方根の積に比例し得る。ＴＣＰ受信機ウィンドウサイズは、目標ダウンロードレートに基づいてすることもできる。
[0009]受信機は、ネットワークからデータを受信するための受信機回路と、プロセスを実行するためのプロセッサと、データを記憶するためのメモリと、ＴＣＰ接続についてのＴＣＰ受信機ウィンドウサイズを含む、ソースと受信機との間の複数のＴＣＰ接続に関連したデータ用のストレージであって、ソースと受信機との間のＴＣＰ接続が直接接続または間接接続であることができるストレージと、メディアコンテンツ用の目標ダウンロードレートを決定するための論理（ハードウェア、ソフトウェア、または組合せ）と、メディアコンテンツの複数のメディアデータ要素をダウンロードした結果のためストレージとを含むことができ、メディアコンテンツは、複数のＨＴＴＰ要求への応答の一部分または全部であり、所与のＴＣＰ接続についての決定されたＴＣＰ受信機ウィンドウサイズは、目標ダウンロードレートに少なくとも部分的に基づくサイズであり、決定されたＴＣＰ受信機ウィンドウサイズは、少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる。
[0010]現在のＴＣＰ接続についてのＴＣＰ受信機ウィンドウサイズは、乗数レートで乗算された、現在のＴＣＰ接続についての現在の推定ラウンドトリップ時間（「ＥＲＴＴ」）の積であってもよく、乗数レートは、現在のＴＣＰ接続についての目標ダウンロードレートと、目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である。
[0011]受信機は、マルチプルなＨＴＴＰ接続を使用し、メディア要求をより小さいチャンク要求に分解し、ＴＣＰフロー制御メカニズムを使用して接続を同期させ、データをバースト的に（in bursts）要求することもできる。さらに、受信機は、ＨＴＴＰパイプライン化プロセスを使用して、接続をビジーに保つことができる。
[0012]様々な要素は、ネットワーク経路によって結合されたソースと受信機との間のネットワーク経路を介したデータダウンロードを制御するためのプロセッサによって実行されるコンピュータ可読媒体を使用して実装されることもできる。コンピュータ可読媒体は、非一時的コンピュータ可読媒体でありうる。
[0013]本発明の他の態様が、本記述から明らかになるはずである。
[0014]記録段階と、コンテンツ準備段階と、コンテンツ配信段階とを伴う、メディア記録がどのようにエンドユーザに到達するかを表示する、ＤＡＳＨ展開におけるＤＡＳＨクライアントを含む様々な要素を示す図。 [0015]ストリームマネージャ、要求アクセラレータ、ソースコンポーネント、ネットワーク接続、およびメディアプレーヤを含む様々なコンポーネントを備えたＤＡＳＨクライアントの例示的アーキテクチャを示す図。 [0016]リプレゼンテーション切替えプロセスを示すタイミング図であり、図３Ａは後方参照プロセスについて、図３Ｂは前方参照プロセスについてのタイミング図。 [0017]切替え点がアライメントされている場合のリプレゼンテーション切替えプロセスを示すタイミング図。 [0018]レートエスティメータ、特に、バッファレベルに適合したエスティメータ（ｐｋｅｒタイプのレートエスティメータなど）によって管理される経時レートを示すプロット。 [0019]非適応指数加重移動平均（「ＥＷＭＡ」）フィルタが使用されるときの、ダウンロード時間（ｒ時間）に対するレート増大を示すプロット。 [0020]非適応ＥＷＭＡフィルタが使用されるときの、プレイバック時間（ｐ時間）に対するレート増大を示すプロット。 [0021]可変ウィンドウサイズ加重移動平均（「ＷＭＡ」）フィルタが使用されるときの、ダウンロード時間（ｒ時間）に対するレート増大を示すプロット。 [0022]ｐｋｅｒタイプのプロセスが使用されるときの、プレイバック時間（ｐ時間）に対するレート増大を示すプロット。 [0023]セクション２．１のｐｋｅｒプロセスが使用されるときの、ダウンロード時間に対するレート低下を示すプロット。 [0024]レートの急上昇に対するｐｋｅｒプロセスの挙動を示す図。 [0025]急なレート下落に対するｐｋｅｒプロセスの挙動を示す図。 [0026]単純（固定幅）移動ウィンドウ平均と指数加重移動平均との比較を示す図。 [0027]ｐｋｅｒレート推定プロセスのフローチャート。 [0028]図１６とともに、ｐｋｅｒプロセスによって使用される値ＢおよびＴfastが、記録された（Ｔp，Ｔr）値の履歴からどのように決定され得るかを示す図。 [0029]値を決定する態様を示す図。 [0030]「ウォーターマーク」フェッチングプロセスの挙動を示す図。 [0031]プレイバックレートを選択するのに使用され得るラムダ関数およびミュー関数の例を示す図。 [0032]「コンサバティブ」設定を使用する、（ラムダ，ミュー）関数の例示的選択を示す図。 [0033]「中間」設定を使用する、（ラムダ，ミュー）関数の例示的選択を示す図。 [0034]「アグレッシブ」設定を使用する、（ラムダ，ミュー）関数の例示的選択を示す図。 [0035]ＭＬＢプロセスをある程度までエミュレートするためのプロセスを使用する、（ラムダ，ミュー）関数の例示的選択を示す図。 [0036]ラムダ設定用の隣り合っている値の例を示す図。 [0037]ミュー設定用の隣り合っている値の例を示す図。 [0038]レート推定、次いでレートベースのレート選択、次いでバッファ管理ベースのレート選択のためのプロセスを示す図。 [0039]要求取消しなしでのレート下落を示す図。 [0040]要求取消しのあるレート下落を示す図。 [0041]例示的な要求取消しプロセスを示すフローチャート。 [0042]要求取消し検出のためのプロセスを示す図。 [0043]マルチプルなＴＣＰ接続を用いるが、受信バッファのチューニングは用いないでフェッチする挙動のプロット。 [0044]マルチプルなＴＣＰ接続を用いて、および受信バッファのチューニングを用いてフェッチする他の挙動のプロット。 [0045]例示的な要求アクセラレータプロセスのフローチャート。 [0046]所与のフラグメント要求を生み出すためのいくつかのサブ要求を見つけるためのプロセスを示す図。 [0047]計算されたサイズを有するソース要求の分離区間となるように選ばれた個々の要求を選択するためのプロセスを示す図。 [0048]時間オフセットと、時間オフセットによって決まる修復セグメントについてのフラグメント構造との例を示す図。 [0049]レート選択におけるラムダおよびミューに使用することができる値のテーブル。
詳細な説明
[0050]本明細書で説明されるＤＡＳＨクライアントは、図２に示すように、ストリームマネージャ（ＳＭ）と、要求アクセラレータ（ＲＡ）と、ソースコンポーネント（ＳＣ）と、ネットワーク接続と、メディアプレーヤとを含む。ＤＡＳＨクライアントは、１つまたは複数のメディアデータバッファも含み得る。いくつかの実装形態では、ＲＡ、ＳＣおよびメディアプレーヤはすべて、それら自体のデータバッファ、または１つの大きいデータバッファの論理区画を有し得る。他の実装形態では、おそらくＲＡのみが、要求をバッファリングするためのデータバッファを有し、その結果、ＲＡは、それが応答し得るあらゆる要求に対して完了応答（complete response）を戻すことができるようになり、メディアプレーヤは、ＳＣがセットアップしたデータバッファはどれでも使用する。ＳＭは、決定を行うのに必要とされるメタデータを記憶するための、それ自体の（物理的または論理的）ローカルストレージを有し得る。
[0051]図１は、ＤＡＳＨクライアントをもつＤＡＳＨ展開を示す。
[0052]図２は、様々なコンポーネントをもつＤＡＳＨクライアントの例示的アーキテクチャを示す。ＳＭ、ＲＡ、ＳＣおよびメディアプレーヤは、ハードウェア、ソフトウェアまたは何らかの組合せで実装され得ることを理解されたい。したがって、機能がコンポーネントによるものである場合、機能は、プロセッサ命令、プログラムコードなどとして実装されてよく、この場合、それらの命令を実行するための必要なハードウェア（プログラムメモリ、ＲＯＭ、ＲＡＭ、プロセッサ、電力源、コネクタ、回路板など）が含意される。ネットワーク機能が記述される場合、ネットワーク接続は、存在するものと理解されるべきであり、ワイヤード、光学、ワイヤレスなどであってよく、ユーザインタラクションが含意される場合、ユーザインターフェース能力（ディスプレイ、キーボード、タッチパッド、スピーカ、マイクロフォンなど）も含意される。
[0053]ＤＡＳＨクライアントは、２つのクロック、またはそれらの論理的等価物を維持する。一方のクロックは、クライアント中で稼動するローカルクロックの時間を示すリアルタイムクロック回路またはソフトウェアであり、他方のクロックは、メディアコンテンツの開始に対する、メディアコンテンツのプレゼンテーションの時間を表すプレゼンテーション時間である。本明細書において、リアルタイムクロック時間は「ｒ時間」と呼ばれ、「ｐ時間」は、プレゼンテーション時間を示す記述子である。
[0054]リプレゼンテーションとは、同じコンテンツについての、異なるビットレートまたは他の違いで符号化されたメディアストリームである。したがって、ユーザは通常、１つのリプレゼンテーションを必要とするだけであるが、クライアントは、条件および／または要件が変わると、あるリプレゼンテーションから別のリプレゼンテーションに切り替えうる。たとえば、帯域幅が高い場合、ストリーミングクライアントは、高品質、高ビットレートのリプレゼンテーションを選びうる。帯域幅が低減された場合、クライアントは、より低品質のより低いビットレートリプレゼンテーションに切り替えることによって、これらの条件に適応することができる。
[0055]切替え点（またはランダムアクセスポイント）は、ストリームに先行するデータを知る必要なしに、メディアサンプルの復号がそこから始まり得る、リプレゼンテーション中のサンプルである。特に、ビデオリプレゼンテーションでは、サンプル（フレーム）は概して以前のフレームに依存するので、あらゆるサンプルがランダムアクセスポイントであるわけではない。ストリーミングクライアントは、リプレゼンテーションを切り替えたいときには、無駄な作業を避けるために、必ず切替え点において新たなリプレゼンテーションを復号し始めるべきである。いくつかのケースでは、切替え点は、ストリーミングクライアントに対してセグメントインデックス（ｓｉｄｘ）中でシグナリングされる。
[0056]リプレゼンテーショングループ（単にグループと略記されることがある）とは、切替え可能なリプレゼンテーションのセットである。メディアプレゼンテーションは、１つよりも多くのリプレゼンテーショングループを含み得る。メディアプレゼンテーションは、たとえば、様々なビットレートでのビデオリプレゼンテーションについて１つのリプレゼンテーショングループと、オーディオビットレートについて別のリプレゼンテーショングループとを有し得る。ＤＡＳＨ規格では、リプレゼンテーショングループは、適応セットと呼ばれることもある。
[0057]セグメントとは、複数のリプレゼンテーションのうちの１つのリプレゼンテーションの少なくとも一部分についてのメディアデータを含むファイルである。フラグメントとは、フラグメントの開始ｐ時間からセグメント内のフラグメントのバイト範囲へのマッピングが利用可能である、セグメントの一部である。フラグメントの代わりにサブセグメントという用語が使用されることもあり、これらは等価であると見なされ得る。一部のメディアコンテンツは、フラグメントに分割されず、そのようなケースにおいて、「フラグメント」は、セグメント自体を指す場合がある。
[0058]図３は、２つの可能なリプレゼンテーション切替えプロセスを示すタイミング図である。切替えは、後方参照（backward looking）（図３Ａの第１のプロセス）であることができ、この場合、ｓｗｉｔｃｈ−ｆｒｏｍリプレゼンテーション中ですでに要求されているｐ時間ストレッチを見ることによって、およびこのストレッチの終了に最も近い、ｓｗｉｔｃｈ−ｔｏリプレゼンテーションから、ｐ時間において後退する前の切替え点を選ぶことによって、ｓｗｉｔｃｈ−ｔｏリプレゼンテーションにおける切替え点が見つかる。第２のプロセス（図３Ｂ）は前方参照（forward looking）であり、ｓｗｉｔｃｈ−ｆｒｏｍリプレゼンテーション中の、最後の要求されるｐ時間から始まる、ｓｗｉｔｃｈ−ｔｏリプレゼンテーション中の、ｐ時間において前進する次の切替え点を見つける。
[0059]図４は、切替え点がアライメントされたとき、および切替え点が最後の要求フラグメントの後にすぐに続くときの、切り替えるためのプロセスを示すタイミング図である。この図は、前方参照方法と後方参照方法の両方の挙動を示すが、それは、これらの２つのプロセスが、そのような設定において同一に振る舞うからである。したがって、切替え点がアライメントされるときには、どちらのプロセスも、重複データをダウンロードする必要はない。
[0060]プレゼンテーション時間とは、メディアが、一般には通常速度で、プレイアウトまたはプレイバックすると予想される時間期間である。たとえば、３０分のビデオプレゼンテーションであれば、３０分間再生する。ユーザは、早送りまたは巻き戻しをする場合があるので、実際にかかる時間は変わるが、プレゼンテーションは依然として、３０分のビデオプレゼンテーションであることを理解されたい。プレゼンテーション要素が、プレゼンテーション時間に、ユーザにプレゼンテーションを提示する。プレゼンテーション要素の例としては、視覚ディスプレイおよびオーディオディスプレイ、またはストリームを提示することができるデバイスにパイピングされるビデオ／オーディオストリームがある。「プレイバック」とは、メディアの消費を記述するのに使用される用語である。たとえば、スマートフォンであれば、プレゼンテーションのプレゼンテーション時間（ｐ時間）にわたってプレゼンテーションを表すメディアデータをダウンロードまたは取得し、バッファリングすることができ、メディアプレーヤは、そのメディアを「消費する」と言われ、好ましくは、バッファが少なくともプレゼンテーション時間の終了までは完全には空にならないように消費し、そうすることによってユーザは、受信機がより多くのデータを取得するのを待っている間、プレゼンテーションの失速を受けない。当然ながら、「プレイバック」または「プレイアウト」は、メディアが一度よりも多く再生されることは含意しない。多くの事例において、メディアは一度消費されると、再度使用されることはない。
[0061]プレゼンテーションバッファとは、受信機、メディアプレーヤ内にあるか、または一方もしくは両方にとってアクセス可能なメモリ要素である。説明を簡単にするために、「プレゼンテーションバッファ」、「バッファ」、「メディアバッファ」および「プレイバックバッファ」という用語を互換的に使用するが、これは、ダウンロードされているがまだプレイアウト、すなわち消費されていないデータ、すなわち通常はメディアデータを備える論理バッファであることは理解している。プレゼンテーションバッファを成すデータが、デバイスにおいて、様々なコンポーネントの間で区分される場合があり、すなわち、ダウンロードされたデータのいくつかの部分が、１つのプロセス、たとえば、デバイス内の受信プロセスによって保持され、他の部分は、別のプロセス、たとえば、デバイス内のプレイアウトプロセスにすでに渡されている場合がある。プレゼンテーションバッファを成すデータの少なくとも一部は、異なるプロセスの異なるバッファにわたって少なくとも部分的に複製される場合もあり得る。いくつかのケースでは、ダウンロードされているがまだプレイアウトされていないデータすべてが、依然としてプレゼンテーションバッファ内にあると見なされるわけではなく、たとえば、いくつかのケースでは、メディアコンテンツは、メディアプレーヤにパスされると、もはやプレゼンテーションバッファにあると見なすことはできない。概して、メディアデータが存在する場合、ダウンロードされているがまだプレイアウトされておらず、さらにプレゼンテーションバッファ内にあると見なされないメディアデータの量は、非常に少ない。
[0062]プレゼンテーションバッファは、メディアを受信しプレイバックし、受信メディアデータを、消費されるまで記憶する際の不均一に適応する。メディアデータは、消費された後、構成に応じて、消去されることもでき、または記憶され続けることもできる。いくつかの実装形態では、プレゼンテーションバッファのサイズ（プレゼンテーションバッファに記憶することができるデータバイトの数で測ることができる）は、時間とともに変わり得る。たとえば、プレゼンテーションバッファは、必要に応じて共有メモリから動的に割り振られ得る。
[0063]本明細書において詳細に説明する多くの例では、プレゼンテーションバッファは、サイズによって特徴付けられると仮定され得る。プレゼンテーションバッファに専用の固定メモリサイズのケースでは、そのサイズは、利用可能メモリに記憶することができるバイトの数で測ることができる。プレゼンテーションバッファが動的に割り振られる場合、プレゼンテーションバッファに起因する「サイズ」は、プレゼンテーションバッファに現時点で割り振られているバイトの数、プレゼンテーションバッファに割り振ることができ得るバイトの最大数、または何らかの他の適切な測度に等しいものであり得る。プレゼンテーションバッファサイズは、プレゼンテーションバッファ中の現在利用可能なメディアのプレゼンテーション時間プレイアウト持続期間によって測定されることもある。
[0064]プレゼンテーションバッファは、別の特性、すなわちバッファの「レベル」または「充満レベル」も有する。プレゼンテーションバッファのレベルは、どれだけ多くの未消費メディアデータがプレゼンテーションバッファ中に存在するかを表し、たとえばバイトまたはプレゼンテーション持続時間で測定される。レベルは、メディアデータが受信されると上がり、メディアデータが消費されると下がると予想される。レベルは、論理的なものにすぎない可能性があり、たとえば、プレゼンテーションバッファは、メディアデータで常に満杯（full）であり得るが、メディアの一部、たとえば、すでに消費されたメディアデータは、新規メディアデータが受信されると、上書きのためにマーキングされる。いくつかの受信機は、「空きバッファ」が、未消費のメディアデータがゼロであるコンディションであり、「満杯バッファ」が、プレゼンテーションバッファの１００％が未消費メディアデータで満たされているコンディションであるようにプログラムされ得る。他の受信機は、プレゼンテーションバッファサイズの０％〜１００％よりも小さい範囲にレベルが及ぶように、他の限度を有し得る。未消費メディアデータがバッファに記憶されたときに共有メモリが使われ、プレゼンテーションバッファしか割り振られたことがないケースでは、プレゼンテーションバッファは、定義により、常に満杯になるので、プレゼンテーションバッファのメモリの動的に割り振られたサイズを、レベル比を示すときの水準として使用するのは意味がない場合がある。そうではなく、プレゼンテーションバッファのレベルは、プレゼンテーションバッファ中の未消費メディアデータの量を、プレゼンテーションバッファについての最大許容サイズで除算した比として測ることができる。
１． クライアントコンポーネントの概説
[0065]図１〜図２を再度参照すると、例示的クライアントの様々なコンポーネントが示されている。
[0066]ＳＣは、どのようなリプレゼンテーションが利用可能であるか、およびリプレゼンテーションのフラグメントが何であるかについての情報などのメタデータを追跡する。ＳＣは、ネットワークを介して受信されたメディアデータのバッファリング、およびメディアプレーヤへのハンドオフも担う。ＳＭは、どのようなリプレゼンテーションがどの時点でダウンロードされるべきかを決定すること、およびレート切替え決定を行うことを担う。最終的に、ＲＡは、ＳＣによって与えられる正確なＵＲＬおよびバイト範囲情報を所与として、メディアフラグメントのダウンロードを担当する。
[0067]ＳＭは、レート切替え決定を担うソフトウェアコンポーネントである。ＳＭの目標の１つは、所与の状況向けの最良のコンテンツを選び出すことである。たとえば、たくさんの帯域幅が利用可能である場合、高ダウンロードレートが達成され得るので、ＳＭは、高レートリプレゼンテーションを選び出すべきである。ダウンロードレートが大幅に下落した場合、選ばれた高いリプレゼンテーションはそれ以上持続可能でなくなるので、ＳＭは、条件により適した、より低いリプレゼンテーションレートに切り替えるべきである。ＳＭは、プレイバックバッファを完全にドレインするのを避け（プレイバック失速を引き起こすので）、ただし同時にあまりに急いで、またはあまりに頻繁に切り替えようとはしないように、十分高速にレートを切り替えるべきである。さらに、ネットワークを通じてダウンロードし、失速することなくプレイバックすることができる、最も高品質のコンテンツを要求することを目指すべきである。ＳＭは、意思決定プロセスにおいて、ダウンロード速度以外の要因を考慮に入れるように拡張することができる。可能性としては、リプレゼンテーション決定を行うときには、バッテリ寿命、ディスプレイサイズ、および他の要因などに配慮することができる。そのようなさらなる制約は、フィルタとしてＳＭに追加することができ、本明細書において記述する基本レート決定計算には影響しない。
[0068]典型的な高レベルのクライアント動作について、次に説明する。ユーザが、ライブのスポーツ放送、あらかじめ録画された映画、オーディオストリーム、または、ビデオおよびオーディオ以外のメディアタイプを伴い得る他のオーディオビジュアルもしくは他のコンテンツなど、特定のメディアコンテンツを要求すると想定する。クライアントは、その要求を、おそらくユーザインターフェースまたはコンピュータインターフェースを通して、ＳＭに供給する。ＳＭは、ＳＣに対して要求を行い、どのリプレゼンテーションが利用可能であるか、どのｐ時間帯がどのフラグメントによってカバーされるか、およびリプレゼンテーション中の切替え点がどこにあるかについてのインジケーションを受信する。それに加え、ＳＭは、後で説明するように、自由にできる短期ダウンロードレートについての何らかの情報を有することができ、ＲＡは、このデータをＳＣに報告し、ＳＣは、このデータをＳＭに報告または提供する。
[0069]ＳＭは、その情報を、過去の履歴と一緒に使用して、持続可能レートを推定し、リプレゼンテーション内の適切な切替え点と、その切替え点において始まるそのリプレゼンテーションからダウンロードするべきメディアコンテンツの量とを選ぶ。ダウンロードが進行中であり、メディアコンテンツがプレイバックされるとき、ＳＭは、供給された情報を使用して、レート切替えが順序通りであるかどうかを決定する。レート切替えが順序通りでない場合、ＳＭは、現在のリプレゼンテーションからフラグメントをフェッチし続けるよう、ＳＣに伝える。レート切替えが順序通りである場合、ＳＭは、潜在的切替え点を見て、どのリプレゼンテーションにあるどのフラグメントが、所望の切替えを行うためにフェッチされる必要があるか決定する。ＳＭは次いで、その情報をＳＣに渡す。ＳＣとＳＭとの間のこの交換は、ダウンロードされるべきビデオの次のセクションに対する決定が行われるべきであるときはいつでも、定期的に行われる。良好な決定を行うために、ＳＭはバッファレベルを監視し、いくつかのケースでは、ＳＭは、バッファが十分に満杯であり、いかなるフラグメントも、ある程度の期間ダウンロードされる必要はないと決定し得る。
[0070]ＳＭが、ダウンロードするべきフラグメントを決定すると、ＳＣは、ＲＡに、実際にフラグメントをダウンロードさせ、ダウンロードされたフラグメントをメディアバッファに保たせ、最終的に、メディアデータをプレイアウトする時間になったとき、メディアバッファ中のメディアデータをメディアプレーヤにハンドオーバさせるのを担当する。
[0071]ＳＭはもはや、ＳＣに、ダウンロードするよう伝えたフラグメントに能動的に関与していない。ただし、ＳＭは、所与のフラグメントのダウンロードがすでに始まった後でも、考えを変え、以前発行したフラグメント要求を取り消すことができる。この機能は、ダウンロードレートが劇的に下落し、ダウンロードされているフラグメントが、メディアバッファが完全にドレインされた時間に、利用可能である見込みがなくなったケースにおいて有用である。その条件が起きた場合、ＳＭはその条件を検出し、要求を取り消し、代わりにより適切なレートに切り替える。
[0072]ＳＣは、ＳＭから、フェッチするべきフラグメントハンドルを受信すると、対応するフラグメントのＵＲＬとバイト範囲とを、そのデータ構造中でルックアップし、それを使用して要求を作成し、その要求をＲＡにハンドオーバする。それはまた、ＲＡから応答データを取り出し、受信メディアフラグメントを、再生可能なストリームに変換するのも担う。最終的に、ＳＣは、ＭＰＤから取得したデータ、セグメントインデックス（ｓｉｄｘ）ボックス、またはＡｐｐｌｅのＨＴＴＰライブストリーミング（ＨＬＳ）のケースでは、プレイリストなどのメタデータをパースし、追跡するのを担当する。
[0073]ＲＡは、ＳＣから受信したフラグメントおよびメタデータ要求を引き受け、対応するＨＴＴＰ要求を作成し、それらをネットワーク接続を通じて送出し、対応する応答を取り出し、ＳＣに返すコンポーネントである。ネットワーク接続は、インターネット接続、セルラーベースの接続、ＷｉＦｉ（登録商標）接続またはＨＴＴＰ要求と応答とを扱うことが可能な他のネットワーク接続であることができる。ネットワーク接続は、単一デバイスの内部にあることができ、すなわち、デバイス内にすでにキャッシュされているメディアデータとの内部インターフェースであることができる。また、多くの組合せがあってもよく、すなわち、メディアコンテンツの一部は、ワイヤードインターネット接続から、一部はセルラーベースの接続を介して、一部はＷｉＦｉ接続を介して、一部はローカルキャッシュからダウンロードすることができる。いくつかのケースでは、メディアデータがダウンロードされる接続は混合されてよく、すなわち、いくつかの部分はセルラーを介し、いくつかの部分はＷｉＦｉを介し、いくつかの部分はワイヤードを介するなどである。特定の要求は、いくつかの事例ではＨＴＴＰ以外であってよいが、メディアコンテンツをサービスするサーバがＨＴＴＰサーバである場合はＨＴＴＰが好まれる。
[0074]その最も単純な形において、ＲＡはＨＴＴＰクライアントである。ただし、ＲＡは、一般的なＨＴＴＰクライアントより効率的であることが望ましい場合もある。ＲＡの１つの目標は、十分に高いダウンロード速度を達成することであり、選択されたプレイバックメディアレートよりも大幅に速いダウンロードを目指すべきである。一方、未加工スループットのために適時性を損なわないように、慎重でもあるべきであり、すなわち、間もなくプレイアウトされるフラグメントは、さらに後にくる他のものよりも緊急であり、ＲＡは、それらを時間内に受信しようと試みるべきである。したがって、適時性のためにある程度のスループットを犠牲にすることが必要となり得る。ＲＡは、すべての妥当なネットワーク条件でうまく機能するように設計されるべきである。
[0075]ＲＡの基本設計は、いくつかの接続と、最良の結果を取得するために、できればさらにＦＥＣ（前方誤り訂正）も使用するものである。したがって、ＲＡは通常、２つ以上のオープンなＨＴＴＰ接続を管理する必要がある。ＲＡは、それらの接続に要求をディスパッチする。ＲＡは、いくつかの状況において、要求を、より小さい要求のセットに分割する。対応する応答を受信すると、ＲＡは次いで、データをコヒーレント応答にリアセンブルする。言い換えると、ＲＡは、送出するべきＨＴＴＰ要求の粒度と、どの接続に要求をディスパッチするべきかとを決定し、ソースフラグメントまたは修復セグメントのどの部分を要求するべきか決定する役目を果たす。それらの要求の粒度は、たとえばバッファレベル、要求の緊急度、利用可能な接続の数など、いくつかのことに依存し得る。
[0076]ＲＡによって送出される各要求は、メタデータについての、またはＳＣによってＲＡにパスされたフラグメント要求の一部もしくは全部についてのＨＴＴＰ要求である。ソースメディアデータまたはソースメディアデータから生成された修復データのいずれかについての要求でありうる。ＳＣフラグメント要求から生成されたＲＡ要求への応答は、ほとんどの場合、ＲＡがフラグメント要求中のメディアデータすべてを再構築するのに十分なはずであり、ＲＡは次いで、このデータをＳＣに返す。したがって、ＲＡは、メディアフラグメント要求に関連付けられたＲＡ要求からの応答を、ＳＣに与えられるフラグメント要求への応答に逆アセンブルするのを担う。ＲＡによるアセンブルは、たとえばＦＥＣ修復データについてのいくつかのＲＡ要求がある場合、ＦＥＣ復号を含み得る。
[0077]ＨＴＴＰ要求の管理に加え、ＲＡは、短期の期間にわたる、すなわちある程度のサンプリングレートの時間スライスにわたるダウンロード速度を測定する。例示的サンプリングレートは１００ｍｓであり、すなわち、ＲＡは、１００ｍｓの期間にわたってダウンロード速度を測定する。このデータは、ＳＭによって、ＳＭのダウンロード速度推定値を計算し、最終的にはレート決定を行うのに使用される。他のサンプリングレートも可能である。
[0078]ＲＡは、ＤＡＳＨメディアプレゼンテーション記述（ＭＰＤ）などのメタデータについても、セグメント構造についても知る必要はない。特定の実装形態において、ＲＡは、ＨＴＴＰスタック実装形態のいくつかの同時事例を使用して、いくつかの接続にわたって、いくつかのケースでは同様または異なるサーバへの異なるタイプの接続にもわたって、ＨＴＴＰ検索を実装する。
[0079]ＲＡは、新規要求がいつ受諾され得るかをＳＣに知らせることを担う。ＳＣは、ＳＭに、要求するべき次のフラグメントを決定するよう求め、適切な要求をＲＡに与える。ＲＡは、何らかのステータス情報も与える。ＲＡは、短期ダウンロード速度と、ダウンロードに費やされる総時間とを、ＳＣを経由してＳＭに定期的に与え得る。ＳＭは、また、この情報について、ＳＣを経由して間接的にＲＡをポーリングし得る。それに加え、ＲＡは、各個々の要求がすでに完了された割合についてもＳＭに知らせる。この情報は、ＳＭがそれを取り出すために呼び出すＡＰＩを用いて同様に与えられる。
[0080]ＲＡと、ＳＣと、実際のメディアパイプラインとの間には、非常にタイトなデータフローがあるはずであり、ＲＡまたはＳＣ内にバッファリングされるデータは、（意図的なメディアバッファは別にして）可能な限り少ない。同じことが、様々な形のＨＴＴＰ要求についても成り立ち、ＳＭは、実際の対応するＨＴＴＰ要求がネットワークを介して送出されるときよりも早く、わずかな時間量だけで、要求するべきフラグメントを決定しなければならないはずである。１つの理由は、ＳＭが要求を事前に決定しなければならない程、その情報は正確でも最新でもなくなり、したがって、その決定はより低い品質となる。
[0081]ＳＭは、発行されるべき要求を一度に１つ提出する。ただし、ＳＭは、以前のすべての要求が完了されているわけではない場合にも新規要求を発行することができ、同時要求が許容される。ＳＣは、ＳＭが要求を発行した順序で、要求をＲＡにパスする。ＲＡは次いで、同時処理を引き受け、受信データをＳＣに必ず返す。
[0082]同時要求により、ＲＡは、ＨＴＴＰパイプライン化を実装することが可能になる。実際、複数の接続を利用するＲＡでさえも、この方式に適合する。
１．１． ストリームマネージャ（ＳＭ）
[0083]ＳＭは、ユーザのアクションと、ネットワーク条件と、他の要因との組合せに応じて、フラグメントをいつ要求すべきか、およびどのフラグメントを要求すべきかを決定する。ユーザがコンテンツを見始めると決定すると、ＳＭは、ユーザによって、または提供されるサービスによって指定された、ｐ時間から始まるそのコンテンツについて要求するべき第１のフラグメントを決定するのを担う。たとえば、いくつかのライブストリーミングサービスは、すべてのユーザが、メディアコンテンツの同じｐ時間部分を同じｒ時間に閲覧していることを要求し得るが、他のライブストリーミングおよびオンデマンドサービスは、どのｐ時間をどのｒ時間にプレイバックするかについて、柔軟性をエンドユーザまたはアプリケーションに認め得る。メディアバッファが満杯になると、ＳＭは、さらなるフラグメント要求を与えるのを一時的にサスペンドする。ＳＭは、ネットワーク条件およびたとえばディスプレイのサイズ、残存バッテリ寿命など、他の要因に依存して、ｐ時間中の各時点においてコンテンツをどの品質でプレイバックするべきか決定するのを担う。
[0084]ＳＭが、フラグメント要求を提供するのが適切であると考えるとき、ＳＭは、ＲＡがフラグメント要求を受信および処理する準備ができている場合にしか要求を提供することができない。ＳＣは、ＲＡをポーリングすることによって、準備ができているときを決定し、この情報をＳＭにフォワーディングする。
[0085]ＲＡが次の要求を受信する準備ができているときには、ＳＭは、新規要求が発行されるべきかどうか決定し、要求するべき次のフラグメントを選ぶ。ＳＭは、メディアデータについての要求を、一度に１つのフラグメントだけ行う。ＳＭは、コンテンツの適時およびシームレスなプレイバックを可能にするフラグメントを要求するのを担う。リプレゼンテーション中のプレイバック変更は概して、切替え点においてのみ起こり得、２つの連続する切替え点の間に複数のフラグメントがあってよく、ＳＭはその制約を尊重する。
[0086]概して、ＳＭは、円滑なプレイバックのために時間内に受信されると信じることが妥当なフラグメントを要求することだけを試みる。ただし、ネットワーク条件が、時には非常に急速に劇的に変化しうることを考えると、このことは、すべての状況において保証されるわけではない。したがって、ＳＭは、要求を取り消すことも可能である。ＳＭは、輻輳が検出されるとともに、何のアクションもとられなかった場合に失速する危険性が大きい場合、要求を取り消す。失速とは、何のアクションもとられない場合、たとえば、フラグメント要求が発行された後間もなく、ネットワーク条件の悪化により、急激に、ダウンロードレートが突然下落する場合の可能性である。
[0087]ＳＭは、最も直近の以前選ばれたフラグメントのリプレゼンテーション、すなわちＲと、終了ｐ時間、すなわちＥとを追跡する。ＳＭは通常、Ｅ’＝Ｅという開始ｐ時間を有する次のフラグメントを要求することを選ぶ。いくつかの変形体は、バッファレベルおよび現在のプレイバック時間から決定された開始時間を有し得る。
[0088]ＳＭは、切替え点における潜在的重複が破棄された場合、円滑にプレイバックすることができるストリームを生成することを意図した、一連の要求を生成する。ＳＭが要求を作り出す順序は、ＲＡが要求を（必ずしも発行するわけではないが）優先するべき順序と同じである。この順序は、また、ＲＡがＳＣに受信データを返し、ＳＣがデータをプレイアウトするべきであるのと同じ順序でもある。
[0089]ＳＭが、レートを切り替える必要があると決定した場合、一般的ケースでは、切替えのための２つのプロセスがある。１つのプロセスでは、ＳＭは、Ｅ以下のｐ時間をもつ新規の（「ｓｗｉｔｃｈ−ｔｏ」）リプレゼンテーション中の切替え点（「ランダムアクセスポイント」または「ＲＡＰ」と呼ばれることもある）Ｐを探し、そのような点が識別されると、ＳＭは、新規リプレゼンテーション中のフラグメントを要求し始める。第２のプロセスは、Ｅのものよりも後または等しいｐ時間をもつ切替え点Ｐを探すこと、およびＰを超える終了時間をもつフラグメントが要求されるまで、古い（「ｓｗｉｔｃｈ−ｆｒｏｍ」）リプレゼンテーション中のフラグメントを要求し続けることのうちの１つである。いずれのケースでも、切替えをＳＣにシグナリングすることが有用であり得る。
[0090]これらのプロセスは両方とも、いくらかの重複データがダウンロードされなければならない可能性があるという特性を有することに留意されたい。ｓｗｉｔｃｈ−ｆｒｏｍリプレゼンテーションとｓｗｉｔｃｈ−ｔｏリプレゼンテーションの両方についてデータがダウンロードされる必要があり得る、ｐ時間のストレッチがある。
[0091]これらの切替えプロセスのうちどちらが好ましいかは、状況に依存する。たとえば、ある特定の状況では、プロセスのうち一方についての重複が不当に大きく、他方については極めて短い場合がある。すべてのフラグメントが複数のリプレゼンテーションにわたってアライメントされ、すべてのフラグメントがＲＡＰで始まる単純なケースでは、これらの切替えプロセスは、より簡単な方法に縮小し、この方法において、ＳＭは、ｓｗｉｔｃｈ−ｆｒｏｍリプレゼンテーションではなくｓｗｉｔｃｈ−ｔｏリプレゼンテーションに対して次のフラグメントを要求することによって切り替えるだけである。この場合、どの重複データもダウンロードされる必要はないことにも留意されたい。
１．１．１． ＳＭフラグメント決定プロセス
[0092]このセクションは、どのフラグメントを要求するようＳＣに伝えるべきか決定するためのＳＭフラグメント決定プロセスについて記載する。これらの例では、単一リプレゼンテーショングループが仮定されるが、これらの例は、複数のリプレゼンテーショングループを使用するプロセスに対処するように拡張することができ、たとえば、ビデオリプレゼンテーショングループからビデオリプレゼンテーションを、およびオーディオリプレゼンテーショングループからオーディオリプレゼンテーションを選ぶ。
[0093]ＳＭによって選ばれる次のフラグメントは通常、前のフラグメント要求の終了ｐ時間である開始ｐ時間を有する。以下で、要求するべき次のフラグメントを選ぶための、ＳＭ内に実装することができるある程度の詳細な論理について説明する。
[0094]以下の例では、フラグメントが、ＲＡＰで始まり、リプレゼンテーションの間でアライメントされると仮定する。これが成り立たない場合、この記述の変形形態が可能である。それらの条件が存在する場合、ＳＭのフラグメント決定は、レート決定に縮小し、すなわち、ＳＭは、現在のリプレゼンテーションにとどまるべきか、それとも異なるリプレゼンテーションに切り替えるべきかを決定する。フラグメントが、複数のリプレゼンテーションにわたって必ずしもアライメントされず、ＲＡＰで始まらない、より一般的なケースでは、決定は同様であるが、切替えコストが高くなるので、このことを考慮に入れられる。
[0095]ＳＭリプレゼンテーションプロセスは、２つの論理的に別個のプロセスを備え、第１のプロセスは、ＲＡが与える短期サンプルから概算持続ダウンロードレートを計算するレートエスティメータであり、第２のプロセスは、この推定値を利用して切替え決定を行う決定プロセスである。
２． レート推定プロセス
[0096]適応ビットレートストリーミングクライアントは概して、正しいビットレートメディアを選ぶためのレート決定モジュールによって後で使用されるダウンロードレートエスティメータモジュールを使用する。この手法を用いると、ダウンロードレートが大きいとき、より高品質のメディアがストリーミングされ得る。ダウンロードレートの変化は、リプレゼンテーション切替えをトリガすることができる。レート推定値の品質は、ストリーミングクライアントの品質に対して大きな影響をもつ。
[0097]適応ビデオストリーミングデバイスについての良好なレートエスティメータは、いくつかの特性を有するべきである。第１に、短期ダウンロードレートが大きく変わる場合であっても、分散はほとんどあるべきでない。第２に、基底チャネル（underlying channel）におけるレート変化に素早く適応するべきである。チャネルレートが大幅に下落すると、推定値は、その事実を素早く反映するべきであり、そうすることによってデバイスは、それに従って、失速することなく品質を調整することができる。それに応じて、ビデオ品質の向上が素早く観測されるはずであり、そうすることによってより良好な品質のコンテンツがフェッチされ得る。
[0098]それらの２つの要件を満足するには、トレードオフが求められる場合がある。通常、分散が小さいエスティメータは、大きい反応時間を有し、逆もまた同様である。たとえば、デバイス内で使用することができる単純なエスティメータを検討する。そのエスティメータは、何らかの固定Ｘについて、ダウンロードの最後のＸ秒にわたって移動平均をとる。大きいＸ、たとえば、Ｘ＝３０秒（ｓ）を選び出すと、分散がほとんどない比較的平滑な推定値が得られるが、ダウンロードレート変化に対してゆっくりとしか反応しない。そのようなエスティメータがレート決定に使われた場合、結果として得られるプレーヤは、帯域幅下落に対して頻繁に失速し、またはそうすることが安全に可能であるときにより高いビットレートに適時に切り替えそこねる場合がある。これらの理由により、ある実装形態は、より小さなＸ、たとえばＸ＝３ｓを選び出す場合がある。そのような選択は、はるかに迅速なレート調整をもたらすが、安定性を犠牲にする。レート推定値は大きく変わり、プレーヤはしたがって、ビデオプレイバックレートを非常に頻繁に変化させて、劣悪なユーザエクスペリエンスをまねきうる。
[0099]図５において、凹凸の多い曲線は、たくさんの短期ゆらぎをもつ、未加工ダウンロードレートである。レートエスティメータは、凹凸の多いダウンロードレートの平滑化バージョンである。レートが変化すると、新規持続レートに収束し、レートが変わらない限りは同様のままである。
[0100]所望の特性のうち１つは、バッファレベルがわずかな場合、調整は迅速であり、これがレートの高速適応を引き起こし、その結果、ダウンロードレートが下落中であるときには、調整前にプレゼンテーションバッファが空にならない。一方、メディアバッファ内にたくさんのメディアデータがある場合、レート推定値はより平滑であり、調整はより遅い。メディアバッファ中により多くのメディアデータがあるときには、プレイアウトレートは、ダウンロードレートが下落中であるときには、メディアバッファ中のメディアデータがより少ないときよりも、より長い時間期間、より高いままである傾向にある。
[0101]これ以降で提示するレート推定プロセスは、ｐｋｅｒ、ｐｋｅｒプロセス、またはｐｋｅｒタイプのプロセスと呼ばれ、レート変化に迅速に反応するが、安定してもいるので、低い分散および高い反応性についての要件の両方を満足する。
２．１． ｐｋｅｒプロセス
[0102]このセクションは、本明細書においてｐｋｅｒ、ｐｋｅｒタイプのプロセスまたは単に「ｐｋｅｒプロセス」と呼ばれるレート推定プロセスについて記載する。基本レートエスティメータは、その推定値を、そこからより長い移動平均を計算するためにある方法または別の方法を使用した、短期レート測定値にのみ基づかせる。上述した基本移動ウィンドウ平均（「ＭＷＡ」）は、そのようなプロセスの一例である。
[0103]図６〜図７は、レート選択目的で非適応（固定係数）指数加重平均を使用することの効果を示す。これらのプロットは、簡単のために、新規レート推定値が新規ダウンロード選択を直ちにトリガし（すなわち、フラグメントが比較的小さい）、新規レート選択は単にレート推定であると仮定する。
[0104]図６は、ｒ時間態様を示す。図に示すように、ｘ軸はダウンロード時間（リアルタイム）である。時間Ｔ１において劇的なレート増大が起こるとき、バッファは、非常に速く増大し始め、それは、ビデオデータがプレイアウトされるよりもはるかに速くそのビデオデータがダウンロードされているからである。ＥＷＭＡ推定値は、徐々に真のレートに収束する。
[0105]図７は、同じイベントのｐ時間態様を示す。図において、線７０２は、スクリーンに表示されるビットレートを示す。レートは、図６のｒ時間ピクチャにおけるよりもはるかにゆっくり適応する。ｒ時間と比較した、ｐ時間に対する収束の速度は、はじめはＮＲ／ＯＲの割合で減速される（プレーヤが、その時点で、ダウンロードの１秒当たりに約ＮＲ／ＯＲ秒分のビデオを受信したからである）。したがって、正味の効果は、メディアが、このタイプのレートエスティメータを使用するときには、多大な量のｐ時間についてのダウンロードレートよりもはるかに低いレートでプレイアウトできることである。
[0106]レートが、メディアをストリーミングする目的で推定される場合、エスティメータは、他の関連情報を利用することができる。特に、メディアプレーヤのバッファ、または一般的に、バッファリングされたまたはすでにプレイアウトされた各メディアセグメントをダウンロードするのにどれだけ時間がかかったかについての情報を含む、メディアプレーヤのダウンロード履歴（現在のバッファにあるものよりも過去にさかのぼる）が関心事である。
[0107]ある実装形態は、たとえば、ＭＷＡエスティメータを使用することができるが、メディアバッファに応じたウィンドウサイズを選ぶことができる。
[0108]メディアプレーヤのバッファレベルが高い場合、プレーヤは、ただちに失速する危険状態にはないので、大きいウィンドウを使用して長期推定値をとることができ、結果としてより安定した推定値になる。一方、バッファレベルが低い場合、プレーヤは急速に反応するはずであり、このことは、この場合に、より短い平均化ウィンドウがより良好な選択であることを示唆する。
[0109]したがって、レート推定プロセスの実装形態は、変化するウィンドウ幅を使用することができ、現在のメディアバッファ中のｐ時間の量（つまり、ダウンロードされ、まだプレイアウトされていない現在のｐ時間の量）に比例するｒ時間ウィンドウ幅を使用し得る。
[0110]別の実装形態は、メディアバッファに現在含まれるバイト数に比例するようにウィンドウ幅を選ぶことができる。
[0111]ある実装形態は、単にバッファのレベルではなく、バッファ自体のコンテンツを検査することもできる。たとえば、バッファの大部分が、その同じコンテンツのプレイバック持続期間よりもはるかに短い時間でダウンロードされたと決定した場合、このことは、ダウンロードバッファが急速に増大している最中であり、したがってレートエスティメータは、推定値が調整される必要があると結論づけ得ることを示唆する。
[0112]同様に、レートエスティメータは、バッファレベルの変更レートを追跡し、バッファレベルの高速変化を、レート推定値が急速に調整される必要があるというインジケーションとみなすこともできる。
[0113]図８〜図９は、可変ウィンドウサイズ加重移動平均（「ＷＭＡ」）フィルタが使用されるときの、図６〜図７と同じシナリオにおける挙動を示す。この例では、「ｐｋｅｒ」プロセスは、そのような可変ウィンドウサイズＷＭＡフィルタのように、プログラミングコードとして説明される。ｐｋｅｒプロセスは、プロセッサによって実行されるプログラム命令として実施することができる。
[0114]図８において、線８０２は、基底チャネルが、レートＯＲ（古いレート）からレートＮＲ（新規レート）への急激なレート増大を有する場合のｐｋｅｒレート推定値である。レート選択が新規レートに適応するのにかかるｒ時間の量は、ＯＲ／ＮＲに比例する。増大が大きい程、適応はリアルタイムで速く起こる。図に示すように、時間Ｔ２において、Ｂｕｆｆ＠Ｔ２＝２＊Ｂｕｆｆ＠Ｔ１およびＴfast＝ＯＲ／ＮＲ＊Ｂｕｆｆ＠Ｔ１である。
[0115]図９は、ｐ時間におけるプレイバック挙動を示す。ｐｋｅｒエスティメータは、新規レートに適応するのに約１バッファ持続期間（レート増大が起きたとき、バッファ中にあったｐ時間の量）かかり、すなわち、ｐｋｅｒエスティメータは、メディアバッファが、ｐ時間の持続時間Ｂがメディアバッファに追加された、メディアコンテンツの量を有するときには、新規レートに適応済みであり、ここでＢは、新規レートまでのレート増大時におけるメディアバッファ中のメディアコンテンツのｐ時間の持続時間である。
[0116]上記を行う特定のプロセスについて、ここで説明する。このプロセスは、プレイバックバッファの最後のγT比分（γT-fraction）をダウンロードするのに、どれだけのｒ時間がかかったか決定し、ここでγTは適切に選ばれた定数である。たとえば、これは、現在のプレイバックバッファ全体（γT＝１）をダウンロードするのにかかった完了時間であり得、またはプレイバックバッファの後半分（γT＝０．５）をダウンロードするのにかかった時間であり得る。γT＞１であることもあり得る。Ｔfastを、プレイバックバッファの最後のγT比分をダウンロードするのにかかったｒ時間の量とする。推定ダウンロードレートは、ダウンロード時間の前のＴfast秒にわたるダウンロードレートを推定することによって計算されることができる。γTの他の値も可能であることに留意されたい。本明細書に記載するように、異なる値が、異なる目標に役立ち得る。
[0117]Ｔfast幅のウィンドウにわたるこの種類のウィンドウ化平均は、レート増大を迅速に検出するという、注目すべき特性を有する。実際、Ｔfastを決定するために値γT＜１が使用される場合、エスティメータは、メディアバッファ中のメディアコンテンツのｐ時間の持続時間がＢである特定の瞬間においてどれだけレートが増大する場合でも、レートエスティメータが増大したレートに収束する前にバッファが最大でもＢの有限倍数まで増大するという特性を有する。
[0118]より精巧なレート推定方法は、上で言及した２つの手法を組み合わせることができる。この方法は特に、バッファレベルＢの最小値、および平均化ウィンドウ幅としてのＴfast、すなわち、ダウンロードレートを平均すべきｒ時間の量を使用することができる。より一般的には、ダウンロードレートは、γB・Ｂの最小値およびＴfastの前のｒ時間にわたって平均されることができ、ここでγBは、適切に選ばれた定数である。そのような選択は、失速する危険をもってレートが下落したときに迅速に反応するという特性を有しており、というのは、それらのケースにおいて、Ｂは最小値であり、平均化は、メディアバッファ中のメディアコンテンツのｐ時間の持続時間に比例するｒ時間にわたり、したがって、メディアバッファが半ばまでドレインするときには、レート推定値は新規レートになるからである。たとえば、レート低下時において、メディアバッファ中のメディアコンテンツ持続期間はＢであり、ダウンロードレートが、ダウンロードレート低下前の、選択されたプレゼンテーションのプレイバックレートの比α＜１となるように、ダウンロードレートが低下し、悲観的には、選択されたリプレゼンテーションのプレイバックレートは、レート推定値が新規ダウンロードレートに減少するまで低下しないと想定する。次いで、ダウンロードは、レート低下が起こるときを超えてｘのｒ時間だけ継続するので、バッファレベルは、Ｂ’＝Ｂ−ｘ＋α・ｘ、すなわち、メディアバッファからｘ回のｐ時間ドレインとなり、α・ｘがメディアバッファにダウンロードされる。レート推定値は、ｘ＝Ｂ’であるような時点で、すなわち、ｐ時間におけるメディアバッファレベルが、ダウンロードが新規レートであったｒ時間に等しくなる時点で、新規レートになる。というのは、この時点で、前のｒ時間のダウンロードにわたる推定値が新規レートになるからであり、それは、この時間全体にわたって、ダウンロードが新規レートで行われたからである。式ｘ＝Ｂ’＝Ｂ−ｘ＋α・ｘをｘについて解くと、ｘ＝Ｂ’＝Ｂ／（２−α）となり、すなわち、バッファＢ’が依然として少なくともＢ／２であるとき、レート推定値は新規レートに達する。そうではなく、レートがどこかの時点で大幅に増大する場合、Ｔfastは最小値になり、前のＴfast ｒ時間にわたる平均ダウンロードレートは、前のＢ ｒ時間にわたる平均よりも大幅に高くなる。
[0119]ここで、この構成に基づいて、ｐｋｅｒレート推定プロセスの例について詳細に説明する。このプロセスは、要求アクセラレータ（ＲＡ）などのダウンロードモジュールから取得することができる短期レート測定値と、バッファ情報とを使用して、推定値を計算する。バッファ情報は、短期レート測定値が有用な推定値になるためのウィンドウ幅を決定するのに使用される。
[0120]図１０は、ダウンロードレートが急激に下落するとき、ｐｋｅｒレートエスティメータがどのように発展するかを示す。レートが下落するとすぐに、バッファレベルが下落し始める。レート推定値も、適応し始める。レート推定値は、遅くともバッファレベルが２分の１に下落したときには、新規レート（ＮＲ）に達する。この例では、中間レート決定が行われないので、Ｂｕｆｆは線形に下落する。中間決定が行われる場合、Ｂｕｆｆの降下は徐々に減速する。
[0121]ｐｋｅｒプロセスの設計目標は、十分に大きい平均化ウィンドウを使用して、ノイジーな数をもつのを回避し、反応するのに十分に短い数をもつことである。ｐｋｅｒプロセスは、動的に変化するウィンドウサイズをもつウィンドウ化平均を使用することによって、この目標を達成する。ＲＡは、Ｂ、すなわちプレイバックバッファのレベル（ｐ時間中）と、プロセスパラメータγBおよびγTと、Ｔfast、すなわちバッファの（ｐ時間中）最後のγT比分をダウンロードするのにかかったｒ時間についての保存された値と、Ｒ、すなわちｒ時間中の最後のＣ持続期間のダウンロードにわたる平均ダウンロード速度とを含む、ｐｋｅｒプロセスによって使用するためのいくつかの変数をメモリ中に維持し、ここでＣ＝ｍａｘ（ＳＴＰ，ｍｉｎ（γB・Ｂ，Ｔfast））であり、ＳＴＰは最小許容可能ウィンドウサイズであり、Ｃはサンプル時間期間（たとえば１００ｍｓなど）を超えるはずである。いくつかの実施形態では、γB＝１およびγT＝０．５であるが、他の値も可能であり、結果としては、両方が正でありγT＜１である限り、質的に同様の挙動となる。小さいγBは、ｐｋｅｒプロセスを、レート削減に対して素早く反応させ、小さいγTは、ｐｋｅｒプロセスをレート増大に対して素早く反応させる。
[0122]本明細書に記載するように、Ｃという持続期間にわたるダウンロード速度を計算するために、ＳＭは、ＲＡによって定期的に与えられるダウンロード速度情報を使用する。その目的のために、ＳＭは、ＲＡによって与えられるダウンロード速度情報の履歴を維持し得る。平均がとられる持続期間は、ほとんどのγBバッファ持続時間にあり、このことが、メディアバッファレベルに対して上限があるときに、どれだけの履歴が維持される必要があるかを効果的に制限する。
[0123]選択されたプレイアウトレートがダウンロードレートにほぼ等しい場合、ストリームをダウンロードするのには、そのストリームをプレイアウトするのと同じ時間量だけかかるとすると、Ｔfast＝γT・Ｂとなるので、バッファリング値Ｃは、バッファ持続期間程度であることに留意されたい。ｒ時間中のバッファレベルの程度のものを選ぶことは、ダウンロードレート推定値についての平滑化間隔に対する当然の選択である、というのは、それは、ストリーミングクライアントが、失速を避けたい場合にもたなければならない見通し量だからである。
[0124]単純な一実装形態において、平均化ウィンドウ幅は、Ｂ、すなわちビデオバッファに含まれるｐ時間の量に比例する。そのような選択は、失速をうまく防ぐが、欠点がある。すなわち、ダウンロードレートが、選択されたメディアのレートのｋ倍である場合、毎秒のダウンロードの結果、ｐ時間のうちｋ秒間分のメディアがダウンロードされ、レート推定を本当にゆっくり適応させることになる。たとえば、ｋ＝１０であり、１０秒間分のバッファがある場合、レートエスティメータは、適応する前にｐ時間のうち約ｋ・１０ｓ＝１００ｓ分をダウンロードするが、これは非常に長い時間である。このことが、ｐｋｅｒ方法へのＴfastパラメータの導入の理由となる。実際、平滑化に指数加重移動平均が使用される場合、そのようなフィルタは無限インパルス応答を有するので、事態はある程度悪化し得る。この理由により、ｐｋｅｒプロセスは、代わりに有限インパルス応答フィルタを使用する。プレーンな移動平均は機能するが、一実装形態は、また、より精巧な加重移動平均を使用し得る。
[0125]図１３は、この最後の点を示す。この図は、単純（固定幅）移動ウィンドウ平均と指数加重移動平均の比較を示す。グラフは、レート変化が見られるときには、固定ウィンドウ移動平均が最初によりゆっくりと新規レートに収束し得るが、１つのウィンドウ持続期間中に収束することを示す。指数加重移動平均は、はじめは急速に動く傾向があるが、後の段階では、ゆっくりと収束するだけである。ウィンドウ化移動平均とは異なり、固定ウィンドウ内では収束しないが、代わりに、レート変化のマグニチュードの対数の時間をかけて収束する。
[0126]γB＝１およびγT＝０．５なので、ｐｋｅｒプロセスは、様々な保証を与え得る。１つには、ダウンロード速度がどれだけ下落した場合でも、推定値は、バッファがその元の持続期間の半分に縮むのにかかる時間内に新規ダウンロード速度に調整される。もう１つには、ダウンロード速度がどれだけ増大した場合でも、追加のｐ時間に値する多くとも１つのバッファが、ｐｋｅｒプロセスが新規レートに収束する前にダウンロードされる。直接的な算出は、同様の固定比保証が、０＜γBおよび０＜γT＜１のどの選択にも成り立つことを示す。
[0127]バッファレベル、すなわちＢを計算する１つの手法は、次のようになる。Ｔは、メディアプレーヤの現在のプレイバックｐ時間とし、Ｆi,1，…，Ｆi,nは、開始時間の昇順でソートされたリプレゼンテーショングループｉ中の、ダウンロード済みまたはダウンロード中であって、まだプレイアウトされていないフラグメントとする。依然としてダウンロード中であるグループｉのどのフラグメントもＦi,1，…，Ｆi,nの中にある。α（Ｆi,j）は、すでにダウンロードされたフラグメントＦi,jのバイト数を、バイトでのフラグメントＦi,jのサイズで除算したものなど、ダウンロード済みのフラグメントＦi,jの部分とする。様々なｉおよびｊについてのα（Ｆi,j）の値は、ＲＡによって算出され、ＳＭにパスされ得る。所与のグループｉについて、ダウンロードされたｐ時間の現在の総量を、式１にあるように定義する。
[0128]式１の結果から全体的Ｔp値を計算するために、ＤＡＳＨクライアントは、ＭＰＤ（メディアプレゼンテーション記述メタデータ）から決定される、各グループの重みづけ因子、すなわちｗ’と、リプレゼンテーショングループの数、すなわちＧとを考慮し、式２の計算を実施する。バッファレベルＢはこれで、Ｂ：＝Ｔp−Ｔと定義される。
[0129]式２は、現在プレイアウトされているフラグメントに属するバッファの部分も取り込む。この定義は、いくつかのフラグメントが一度にダウンロードされる場合にも機能することに留意されたい。
[0130]Ｔfastを計算するために、一般的ケースにおいて、ＳＭは何らかの履歴を維持する。Ｔrを、ＲＡがメディアをダウンロードする（ダウンロードしようとする）のに費やしたｒ時間の総量とし、Ｚを、ＲＡによってダウンロードされたバイトの総量とする。Ｔrの値は、ＲＡによって計算される。ＳＭは、ｉ＝１，２，…，Ｋについて規則的な間隔で（たとえば、１００ｍｓおきに）サンプリングされたタプル
の履歴、すなわちＨを維持し、ここで第Ｋの観察が最後の観察である。履歴は観察順に記憶されると仮定するので、
ならびに
および
となる。
[0131]ここで、Ｔfastを計算するために、Ｂは、上に挙げた方法ですでに計算されていると仮定する。次いで、ＲＡは、たとえばバイナリサーチで履歴をサーチすることによって、式３の不等式が満たされるようにｊを決定する。
[0132]すると、
となる。無限履歴をずっと維持する必要はなく、最大バッファ持続期間のγB分を超えて広がるＴi値についてだけで十分である。
[0133]図１５は、図１６の拡大版とともに、ｐｋｅｒプロセスによって使用される値ＢおよびＴfastが、記録された（Ｔp，Ｔr）値の履歴からどのように決定され得るかを示す。この図は、ｒ時間およびｐ時間が等しく高速に進行し（ダウンロード割込みはない）、したがってプレイバック時間（ｐ時間）が、ダウンロード時間（ｒ時間）の４５度の傾斜線であるケースを示す。（Ｔp，Ｔr）値の履歴はグラフ中にプロットすることができ、プレイバック失速が起こらない場合、厳密にプレイバックタイムラインの上にある曲線が得られる。バッファレベルＢはしたがって、プレイアウト時間に対する最後の記録されたＴp値の差である。Ｔfastの値は、現在の（最後の）Ｔp値を下回るγT・Ｂのレベルでの、（Ｔp，Ｔr）曲線までの水平距離を測定することによって、このグラフ中に見ることができる。
[0134]図１１は、図１５〜図１６と同じ種類のプレゼンテーションを使用して、レートの急上昇に対するｐｋｅｒプロセスの反応を示す。Ｔfastは、プレーヤがまだ反応していない急上昇を受信レートが受けたときには、比較的小さい。これは、高受信レートに対する高速反応を示す。平均化ウィンドウは、比較的狭いので、完全にグラフの高レート部分内にあることに留意されたい。したがって、この時点で、ｐｋｅｒ推定値は、より長いレートにすでに収束している。
[0135]図１２はやはり、図１５のプレゼンテーションを使用して、レート下落に対する可変ウィンドウサイズＷＭＡフィルタ（たとえば、ｐｋｅｒ）反応を示す。この場合、Ｔfastは比較的大きくなるが、バッファがドレインするので、Ｂは小さくなり、ある程度のドレイン時間の後、平均化ウィンドウを、完全に低レートエリア内に収まらせる。図に示すように、平均化ウィンドウの幅、すなわちＢは、ＢがＴfastよりも小さくなるようなものであるが、推定値は依然として、バッファが完全にドレインされる前に、より低い新たなレートに収束する。
[0136]図１４は、ｐｋｅｒレート推定プロセスのフローチャートである。
[0137]ＴfastおよびＢの値が計算されると、Ｃの値が容易に続き、最後のステップは、持続期間Ｃの過去のウィンドウにわたるレートＲを計算するものである。その目的のために、履歴中のＺiおよび
値が使用される。
[0138]間隔Ｃにわたるレートを計算するために、ＳＭまたはＲＡは、以下のことを行う：（１）
となるような最も大きいｊを見つけ、次いで、（２）式４にあるように平均ダウンロードレートを計算する。そのようなｊが第１のステップにおいて存在しない場合、ＳＭまたはＲＡは、ｊ：＝０、すなわち、最も古い既知の観察結果を設定する。ｊの値は、バイナリサーチによって効率的に決定することができる。
[0139]各グループは、そのグループが消費すると予想される総帯域幅の割合に対応する関連付けられた重み、すなわちｗを有する。これは、好ましくは非使用可能リプレゼンテーションがフィルタ除去された後の、ＭＰＤによって与えられる情報の関数である。本明細書において、グループｇの重みｗの提案される定義は、ｗ（ｇ）：＝ｍａｘｒａｔｅ（ｇ）＋ｍｉｎｒａｔｅ（ｇ）であり、ここで、ｍａｘｒａｔｅ（）は、グループｇ中の最大プレイバックレートであり、ｍｉｎｒａｔｅ（）は、最小プレイバックレートである。
[0140]重みｗから、ＳＭまたはＲＡは、標準化重みｗ’を次のように計算することができる。クライアントが、グループ１，…，Ｇをストリーミングしたいと想定すると、標準化重みは、式５にあるように、すべての重みの合計で除算された重みである。
[0141]標準化は、実際にストリーミングされる重みにわたって行われることを意図している。たとえば、ストリーミング中ではないグループがある場合、そのグループは考慮されるべきでない。
[0142]このｐｋｅｒプロセスの動作において、いくつかの仮定が行われる。たとえば、個々のリプレゼンテーショングループのバッファレベルは、互いに比較的近く保たれるべきである。ｐｋｅｒプロセスは、そうすることによってより良好に機能する。たとえば、あるグループが、非常に大きいバッファを有し、別のグループは非常に小さいバッファを有し、両方が同様の重みを有すると想定する。そのようなケースでは、小さいバッファにとっては条件が変わったときに失速を避けることが必要なので、レート推定値の迅速な調整を行うことが必要となる。しかし、ｐｋｅｒプロセスは依然として、その推定値を、はるかに大きいバッファ向けに作用しているかのように満足に平滑化する。逆に、より大きいバッファにとっては、測定値は、バッファレベルが許容する、ある程度高い分散を有するので、ナーバスなレート決定となる。
[0143]いくつかのケースでは、バッファレベルが大きく相違するリプレゼンテーショングループを有することは不可避である。この理由により、別の実装形態は、いくつかのバッファが非常に小さいときに、より迅速にレートを調整し、したがってそのようなケースにおいてビットを失速からより良好に保護する、ｐｋｅｒ方法の変形体を使用することができる。そのような実装形態は、以前と同じようにＴfastを計算することができるが、ウィンドウサイズをＣ＝ｍａｘ（ＳＴＰ，ｍｉｎ（Ｔfast，Ｔp,1−Ｔ，Ｔp,2−Ｔ，…，Ｔp,N−Ｔ））に設定する。
[0144]これらのダウンロードレート推定の他の変形体は、各リプレゼンテーショングループについての独立ｐｋｅｒ推定値を使用して、そのグループについて決定を行うことを含む。
３． フェッチング戦略
[0145]ストリーミングビデオプレーヤは概して、制限付きメディアバッファを有する。したがって、通常動作において、最終的にはバッファ満杯状態に達し得ると予想される。バッファが満杯状態に達すると、ストリーミングモジュールは、バッファのオーバーフィリング（overfilling）を避けるために、メディア入力を抑える（throttle）べきである。これを行うための容易な方法は、バッファが満杯になったときは常に、バッファが次のフラグメントを保持することができるのに十分にドレインされるまで待ち、次いで、フェッチングを再開することである。
[0146]この方法の効果は、各フラグメントが個々にフェッチされ、各フラグメント要求の間に時間ギャップがある、すなわち、次のフラグメントが収まり、要求され得るように、バッファから十分ドレインするのにかかる時間量があることである。
[0147]ＴＣＰプロトコルは、そのダウンロードレートを、現在のネットワーク条件に基づいて自動調整する。ＴＣＰ接続を介してダウンロードが開始されたときには、初期ダウンロードレートは、通常、非常に遅く、より高いダウンロードレートを達成することができるかどうかをＴＣＰプロトコルが調べると増大する。どれだけ高速にＴＣＰがダウンロードレートを増大させるか、およびＴＣＰが概してエンドツーエンドのＴＣＰ接続のプロパティにどのように反応するかは、極めて複雑であり、固有のエンドツーエンドのネットワークレイテンシ、ＴＣＰ配信および確認応答経路に沿ったネットワーク要素のバッファ容量、これらの経路に沿った競合トラフィック、ＴＣＰのどのような変形体が使用されるかなどを含む、いくつかの因子に依存する。概して、ＴＣＰは、遅いダウンロードレートで始まり、そのダウンロードレートを時間とともに増大させ、したがって、ダウンロード時間全体にわたるＴＣＰ接続の平均ダウンロードレートは、ダウンロード時間全体が相当なものであるときの持続可能ＴＣＰダウンロードレートに近づくだけである。たとえば、持続可能ＴＣＰダウンロードレートが１メガビット／秒であり、ＴＣＰ接続が、事実上ゼロのダウンロードレートで始まり、時間とともに１秒間にわたって１メガビット／秒まで線形に増大した場合、最初の１秒にわたる平均ダウンロードレートは５００キロビット／秒であり、平均ダウンロードレートが持続可能ダウンロードレートの９５％を達成するには、１０秒間のダウンロードが必要である。この理由により、要求の間の多くのダウンローディングギャップを有するフェッチング戦略は理想的ではなく、ダウンロードギャップは、あるダウンロード要求の完了と、次のダウンロード要求の開始との間の時間期間である。ダウンロード要求の間のギャップがゼロであるときでも、通常、ＴＣＰは、前の要求の完了の後、次の要求のためにダウンロードレートを増加させるのにある程度の期間かかるので、理想的ではない。各ギャップの後、持続可能スループットは再び達成されなければならない場合があり、これにより達成される全体的な平均ダウンロードレートが低減される。
[0148]そのような低減されたレートは、より小さいレート推定値をまねき、したがってより小さいメディアレートの選択をまねき得る。その結果、通常、（バイトでのサイズが）より小さいメディアフラグメントがダウンロードされることになり、これによりギャップの相対的な大きさがさらに増大し、より一層小さいプレイバックレートが選択されることになり得る。言い換えると、その効果は自己増幅型である。
[0149]したがって、ＤＡＳＨクライアント実装形態が、この問題の影響を最小限にするプロセスを使用することが有利である。
[0150]ある実装形態は、メディアデータを絶え間なくダウンロードし、次いで、バッファレベルを次のように定期的にドレインすることができる。要求されたがまだプレイアウトされていないｐ時間の量が、あらかじめ設定された高いウォーターマーク、すなわちＭhを超える場合はいつでも、ＳＭは、バッファレベルが低いウォーターマークＭlを下回るまで、いかなる要求もそれ以上発行しない。特定の実装形態では、Ｍh＝２０秒およびＭl＝１０秒であるが、他の実装形態では、それらの値はより低くてもより高くてもよい。低いウォーターマークを下回った後、通常動作が再開され、ＳＭは、フラグメント決定を再び発し始める。
[0151]別の実装形態は、プレゼンテーション時間ではなくバイトで指定されたウォーターマークを使用して、同様の効果を達成することもできる。
[0152]バッファが定期的にドレインしているという事実は、システムの他の部分によって、有利に利用することができる。たとえば、セクション６．１．２で説明するように、ＲＴＴの最新の推定値を取得するのに利用することができる。
[0153]図１７は、「ウォーターマーク」フェッチングプロセスの挙動を示す。上のグラフは、ドレイン期間とフェッチング期間の交替パターンが見られるバッファレベルグラフである。ダウンロードレートは、下のグラフに表示されている。各フェッチング期間の最初において、ＴＣＰは、持続可能最大速度になるのにある程度の時間をかけるので、（フェッチング期間中の）平均ダウンロードレートは、最大達成可能ダウンロードレートよりも小さい。低いウォーターマークと高いウォーターマークとの間の差が大きいほど、フェッチング期間が長くなり、平均レートが高くなる。
４． レート選択プロセス
[0154]メディアデータを要求し始めるとき、ストリーミングモジュール（ＳＭ）は、何らかの方法を使用して、第１のプレイアウトレート選択を行う。ＳＭは、最も低い利用可能レートをとる場合もあり、あるいは、たとえば、ネットワーク条件の履歴を維持し、次いで、この履歴に基づいて、失速なしで持続される可能性が高い、選ぶべきプレイアウトレートの推定値を決定する場合もある。ＳＭが、すでにデータを受信中であり、したがって自由にレート推定値Ｒ（たとえば、セクション２にある方法で計算されたレート推定値のうちの１つなど）を有するとき、ＳＭは、そのレートのまま続けるか、それともリプレゼンテーションを変えるかの決定を行う。
[0155]単純なレート決定プロセスについて、ここで説明する。受信機は、推定ダウンロードレートＲよりも低いプレイバックレートをもつ最も高い帯域幅リプレゼンテーションを決定し、データをプレイアウトする（プレイバックする）ためのリプレゼンテーションとして選び出す。直接的ではあるが、この手法には、いくつかの問題がある。第１に、その手法は、当然ながら、小さいメディアバッファを増大させないので、ダウンロードレートがほとんど変わらないときでも、失速を受けやすい。第２に、変動する推定値Ｒは、急速に変化するレート決定をまねき、これは、必要ではない場合があり、視覚的に邪魔になり得る。第３に、少なくともおおよそフラグメントの持続期間、したがって一般的に数秒の、スタートアップ時間につながる。
[0156]ＤＡＳＨクライアントはしたがって、そのレート決定を、ダウンロード推定値Ｒだけではなく、バッファレベルＢ（つまり、バッファリングされ、まだプレイアウトされていないｐ時間の量）、および概して２つの連続する切替え点の間のｐ時間の持続時間の推定値である変化レートＤなどのコンテンツに依存する変数にも基づかせる、レート決定プロセスを実装することができる。
[0157]したがって、一実装形態は、決定レートとして、Ｒに比例する最も大きいプレイバックレートを選び出せばよく、ここで比例因子はバッファレベルの関数である。
[0158]通常、比例因子λは、バッファレベルの増加関数である。ある実装形態は、λを、たとえば、バッファレベルのアフィン関数にすることができる。
[0159]λがバッファレベルの関数である場合、ある実装形態は、バッファが空または小さいときには小さくなるようにλを選ぶことができる。そのような選択は、小さいバッファを増大させ、ダウンロードレートが正確に予測されないときに失速に対するある程度の安全性も与えるので、有利である。
[0160]より大きいバッファレベルの場合、ある実装形態は、１に近い、１に等しい、または１を超えるλの値を選ぶことができる。こうすることにより、失速する即時の危険性がないときには確実に高プレイアウトレートがダウンロードされるために選ばれることになり、定常状態において高品質メディアがストリーミングされることになる。
[0161]レート決定プロセスは、単なる単純なアフィン関数ではなく、Ｂの区分的アフィン関数であるλを実装することができる。区分的アフィン関数は、任意の連続関数を、任意の所望の程度の精度まで概算することができ、そうすることにより連続関数が適切な選択となる。代わりに、同じプロパティをもつ、他の任意のパラメータ化可能クラスの関数が選ばれることもできる。
[0162]別の実装形態は、λを、ｐ時間で表されるバッファレベルではなく、バイトで表されるバッファレベルの関数にすることもできる。
[0163]さらに別の実装形態は、λを、バッファレベルＢだけではなく、バッファレベルＢと切替え機会の頻度の両方の関数にする。そのようにする理由は、レートを変える機会がより少ないプレーヤが、変える機会がより頻繁なものよりも、さらに今後は各決定に関わるからである。したがって、前者のケースでは、各決定は、より大きいタイムスパン、およびより高い危険性への関与である。このことは、バッファレベルＢと推定ダウンロードレートＲが同じであるとき、失速する危険性を小さく保つために、後者よりも前者のケースではより低いレートを選び出す方がよいであろうということを示唆する。
[0164]レート切替え機会の頻度を考慮に入れるレート選択プロセスのための具体的方法は、次のようになる。Ｄを、ストリーム中の２つの連続する切替え点の間のｐ時間の典型的な量とする。Ｄの値は、符号化ビデオに依存し、たとえば、２つの連続する切替え点の間のｐ時間中の最大距離、または２つの連続する切替え点の平均距離、または２つの連続する切替え点の９０パーセンタイル距離、またはメディア中の２つの連続する切替え点のｐ時間距離の他の任意の適切な測度となるようにとられ得る。そのようなＤを所与とすると、方法は、Ｂ／Ｄの区分的アフィン関数、またはその変形体、たとえばＢ／ｍａｘ（ｕ，Ｄ）もしくはＢ／（Ｄ＋ｕ）などとなるようにλを選ぶことを含むことができ、ここで値ｕは、要求を発行する際に誘発されるオーバーヘッドを考慮に入れるために追加される。ｕの値は、小さい一定の時間量（たとえば１００ｍｓなど）であることができる。さらなる改良として、ある実装形態は、ｕを、推定ＲＴＴの小さい倍数とすることができる。
[0165]上述した方法など、そのレート決定を単にλ・Ｒに基づかせるプロセスには、Ｒの比較的小さい変動でさえも、多くのレート切替えをまねき得るという欠点がある。これは、望ましくない場合がある。十分なバッファがあるときには、Ｒの小さな変化には直ちに反応せず、それに応じてバッファレベルを変わらせる方がよい場合がある。
[0166]そのような挙動を得るために、プロセスは、両方とも同じ量（たとえば、上で説明したように、Ｂ、Ｂ／ＤまたはＢ／ｍａｘ（１００ｍｓ，Ｄ））の関数である値λおよびμを使用することができ、これらの値は、現在のレートとともに、新規レート決定を選び出すためのものである。これらの関数は、λ・Ｒが低い許容可能レート選択となり、μ・Ｒが高い許容可能レート選択となるように選ばれるべきである。プロセスは次いで、それら２つの値を良好なレート決定のためのガイドとして使用するように設計され得る。
[0167]そのような設定において、関数は、概してλ≦μとなるように選ばれるべきである。
[0168]レート決定プロセスは、前の選択がすでにλ・Ｒ〜μ・Ｒの範囲内だった場合、レートを同じに保つことを決定し得る。前の選択がλ・Ｒ未満の場合、λ・Ｒ以下の、最も大きい利用可能プレイバックレートが選択される。前の選択がμ・Ｒよりも大きい場合、μ・Ｒ以下の、最も大きい利用可能プレイバックレートが選択される。
[0169]ある実装形態は、関数λおよびμがハードコードされることを選ぶことができる。あるいは、状況に応じて、より入念な方法で関数を選択することもできる。具体的には、一実装形態は、クライアントが最大限で行うバッファリングの量に応じて、適切なλおよびμ関数を選択することができる。オンデマンドコンテンツの場合、クライアントは、たくさんのデータ、可能性としては数分間分のメディアデータをプリバッファリングすることを選ぶことができる。低遅延ライブコンテンツの場合、クライアントは、多くとも、おそらく数秒間のみの、エンドツーエンドのレイテンシによって規定されるメディア量をバッファリングしさえすればよい。バッファリングがほとんどないコンテンツの場合、クライアントは、よりコンサバティブ（conservative）な、すなわち、より小さい値を有する、λおよびμ関数を選び出すと決定し得る。
[0170]具体的実装形態は、たとえば、２つの極値関数λ1とλ2との間で関数を線形に補間することができ、ここで選択される補間点は、低バッファウォーターマークＭl（セクション３参照）である。したがって、この実装形態は、２つのハードコードされた関数、すなわちλ1とλ2とを有し、λ1は、あるｍ1未満の、Ｍlの小さい値用に使われ、λ2は、ある値ｍ1、ｍ2についてＭl≧ｍ2であるときに使われ、ここでｍ1＜ｍ2である。ｍ1〜ｍ2の範囲内の値について、関数λ（ｘ）：＝λ1（ｘ）（ｍ2−Ｍl）／（ｍ2−ｍ1）＋λ2（ｘ）（Ｍl−ｍ1）／（ｍ2−ｍ1）が使用される。
[0171]ここで、上記記述にしたがう、レート決定プロセスの詳細な例を挙げる。このために、いくつかの表記法を採り入れる。
[0172] １）Ｓ1，Ｓ2，…，ＳLを、リプレゼンテーショングループの（昇順で与えられる）Ｌ個の利用可能リプレゼンテーションのストリームレートとする。
[0173] ２）λ（ｘ）を、負でないスカラーを入力としてとり、負でない実スケーリング係数を戻す区分的一次関数とする。関数λ（ｘ）は、コンパイル時に、または構成ファイルにより設定可能であるべきである。大きいｘについて、たとえば、Ｍlよりも大きいｘについて、λ（ｘ）は不変であるべきである。
[0174]ここで、そのような関数がどのように実装され得るかについての一例を挙げる。端点（０，λ0），（ｘ1，λ1），…，（ｘN，λN）が与えられ、ここでｘiは昇順である。λ（ｘ）を評価するために、ｘi≦ｘであるような最も大きいｉを見つける。次いで、式６を使用して、受信機はこの関数を評価することができる。
[0175]そのようなλ（ｘ）関数についての適切な例は、例示的パラメータＮ＝１、［（０，０．５），（３，１）］によって定義されるもの、つまり、ｘ＝０において０．５に等しく、ｘが３に達するまで線形に増大する関数であり、ｘが３に達した時点で、関数は１に等しく、その後は１のままである。
[0176] ３）μ（ｘ）を、別のそのような区分的一次関数とする。そのような関数の一例は、ｘ＝０において０になり、ｘ＝３において１．５に達し、その後は一定のままであるものである。
[0177] ４）Ｄを、（以前指定された）ある切替え点から次の切替え点までのｐ時間における持続期間の推定値とする。
[0178] ５）ｘ：＝ｍｉｎ｛（Ｔd−Ｔ），Ｍl｝／ｍａｘ｛Ｄ，１秒）とし、ここでＴは現在のプレイバックｐ時間であり、Ｔdは、レート決定が行われるｐ時間であり、Ｄは、上に挙げた通りであり、Ｍlはバッファレベル低マーク（セクション３参照）である。
[0179] ６）ＣＵＲＲを、現在選択されているリプレゼンテーション（すなわち、最後のフラグメント要求において使われたもの）とする。ＵＰを、レートが最高でもλ（ｘ）・Ｒである最も高いビットレートリプレゼンテーションのプレイアウトレートとし、そのようなリプレゼンテーションがない場合、ＵＰは、最も低いビットレートリプレゼンテーションのプレイアウトレートである。ＤＯＷＮを、最高でもμ（ｘ）・Ｒのレートの最も高いビットレートリプレゼンテーションのプレイアウトレートとし、そのようなリプレゼンテーションがない場合、ＤＯＷＮは、最も低いビットレートリプレゼンテーションのプレイアウトレートである。概してλ（ｘ）≦μ（ｘ）なので、概してＤＯＷＮ≧ＵＰである。
[0180]次いで、レート決定プロセスは、次のフラグメントのレートＮＥＸＴを次のように選び出す。（１）ＵＰ＜ＣＵＲＲの場合、ＮＥＸＴ：＝ｍｉｎ（ＤＯＷＮ，ＣＵＲＲ）であり、（２）それ以外の場合、ＮＥＸＴ：＝ＵＰである。
[0181]上のステップ５で単にＤではなくｍａｘ｛Ｄ，１秒｝を使用する理由は、ＲＴＴゆえであり、１の役割は、ＲＴＴの上限として作用することである。
[0182]関数λ（ｘ）およびμ（ｘ）は、ｘに応じて増加していくことが好ましい。λおよびμ関数は、小さいｘについては＜１であることが好ましく、それにより確実に、選ばれたプレイアウトレートがＲ未満になり、小さいバッファレベルについてバッファ増大が引き起こされる。選択されたプレイバックレートは、最高でもｍａｘ（λ（Ｂ／ｍａｘ｛Ｄ，１｝）、μ（Ｂ／ｍａｘ｛Ｄ，１｝））・Ｒに等しく、λ（Ｂ／ｍａｘ｛Ｄ，１｝）とμ（Ｂ／ｍａｘ｛Ｄ，１｝）の両方が１未満であるバッファレベルＢすべてについてバッファ増大が保証されることに留意されたい。
[0183]より簡単なプロセスは、λ（Ｂ）・Ｒ未満のプレイバックレートをもつ最良リプレゼンテーションとなるように、新規リプレゼンテーションを直接選び出してよい。このリプレゼンテーションは、バッファが空になりそうなときに、バッファは満杯になる傾向にあるというプロパティを依然として有する。ただし、Ｒは大きく変動し得るので、たくさんのリプレゼンテーション切替えも引き起こす。本明細書において記述する、より洗練されたレート選択プロセスは、切替えを避けようとし、代わりに、より低いプレイバックレートに切り替える前に、バッファをある程度までドレインさせる。これが機能するためには、関数μおよびλは、中間から大までのバッファレベルについて、μがλを超えるように選ばれるべきであり、ここで、選択されたプレイバックレートがＣＵＲＲであり、測定されたレートがＲである場合、式７が満足される限りレート変化は起こらず、レート切替えなしで受信レートをある程度変動させることに留意されたい。
[0184]いくつかのバージョンでは、λおよびμは単に、比Ｂ／ｍａｘ｛Ｄ，１｝ではなくバッファレベルＢの関数である。後者を導入する動機は、次のようになる。
[0185]αを、選択されたリプレゼンテーションのプレイバックレートと、ダウンロードレートとの比を示すものとする。良好なαを決定することが望まれる。次の切替え点までダウンロードするのに、ほぼα・Ｄのｒ時間だけかかる。受信データがバッファに追加されるすぐ前に、バッファは、Ｂ−α・Ｄまでドレインされている。失速を避けるために、その量を正にしたいが、セーフティクッションとして、それは、ダウンロードされると、バッファに追加されるフラグメントのプレイバック持続期間Ｄに比例するべきであるので、あるβ＞０について、少なくともβ・Ｄであるべきである。要するに、Ｂ−αＤ≧β・Ｄとしたい。
[0186]αの値を求めると、Ｂ／Ｄ−β≧αが得られる。これは、リプレゼンテーション選択プロセスが、Ｂ／Ｄ−βを超えない、プレイバックとダウンロードレートの比を選ぶべきであることを示唆する。関数λ（ｘ）およびμ（ｘ）は、許容可能なそのような比に対する限度であるので、ｘ−βを超えないｘ＝Ｂ／Ｄの関数であるべきである。
[0187]実際には、１つのフラグメントを送信する、ＲＴＴの追加コストを考慮に入れるために、Ｂ／Ｄを、Ｂ／ｍａｘ｛Ｄ，１｝で置き換える。より一般的には、１は、ＲＴＴの近似のある程度の倍数、またはサーバからメディアデータのダウンロードを開始するためのプロセスの反応時間を考慮に入れる他のパラメータで置き換えることができる。
[0188]図１８は、プレイバックレートを選択するのに使用され得るλ関数およびμ関数の例を示す。ｘ軸は、Ｄの単位で表したバッファレベルであり、ｙ軸は、受信比（receive fraction）、すなわち、プレイバックリプレゼンテーションレートを現在の受信またはダウンロードレートで除算したものである。線１８０２によって図に示すように、受信比が１未満の場合、バッファは増大し、１よりも大きい場合は縮む。３つのエリアが識別される。第１に、プレーヤは、決定点においてλ曲線１８０４を下回る場合、高いレートに切り替える。λ曲線１８０４とμ曲線１８０６との間である場合、選択されたレートのままである。μ曲線１８０６を上回る場合、低いレートに切り替える。
[0189]図１９は、「コンサバティブ（conservative）」設定を使用する、（λ，μ）関数の例示的選択を示す。この設定は、利用可能な帯域幅すべてを使用するわけではないが、引き換えに、非常にまれにしか失速しないという点で「コンサバティブ」である。
[0190]図２０は、「中間（moderate）」設定を使用する、（λ，μ）関数の例示的選択を示す。この設定は、コンサバティブ設定よりも多い帯域幅を使用するが、わずかに失速しやすいという点で「中間」である。
[0191]図２１は、「アグレッシブ（aggressive）」設定を使用する、（λ，μ）関数の例示的選択を示す。この設定は、利用可能帯域幅をすべて積極的（aggressively）に使おうとするという点で「アグレッシブ」である。この設定は、他の２つの提示した例示的設定よりも頻繁に失速し得る。
[0192]図２２は、ＭＬＢプロセス、すなわち、米メジャーリーグ（ＭＬＢ）で働いている何人かの研究者によって提案されたものと同様のプロセスをある程度までエミュレートするためのプロセスを使用する、（λ，μ）関数の例示的選択を示す。（λ，μ）関数は、メディアバッファ充満度に基づいて変わるのではないことに留意されたい。
[0193]図２３は、λ設定およびμ設定用の隣り合っている値の例を示す。
[0194]図２４は、λ設定およびμ設定用の隣り合っている値の例を示す。
[0195]図３６は、レート選択においてλおよびμに使用することができる値のテーブルを備える。
[0196]図２５は、レート推定、次いでレートベースのレート選択、次いでバッファ管理ベースのレート選択のためのプロセスを示す。この例示的プロセスにおいて、本明細書において記述する手法のうち１つまたは複数が、レート推定を実施するのに使用される。その推定値に基づいて、新規プレイバックレートが選択され、バッファ管理ルールに基づいて調整されることが可能である。
５． 要求取消し
[0197]いくつかのケースでは、優れたレート選択プロセスでさえも、単独ではビデオプレイバックの失速を防止することができない。たとえば、要求が行われた後であるが完了される前に、ダウンロードレートが急激に下落した場合、選択されたビットレートは大きすぎた可能性があり、遅いダウンロードレートは、プレイバックレートを変えるための次の切替え機会に達する前であってもプレイバック失速につながり得る。
[0198]別の例として、たとえば、セルラー接続からＷｉＦｉ接続への移行により、利用可能帯域幅が劇的に増大するときには、メディアバッファは、比較的低いプレイバックレートメディアで満杯になり得る。この場合、すでにダウンロードされたがまだプレイアウトされていないメディアの大部分を破棄し、破棄されたｐ時間部分を再度ダウンロードするが、今度はダウンロードするべきより高いプレイバックレートリプレゼンテーションを選ぶことが有利であり得る。したがって、すでにダウンロードされた低プレイバックレートメディアは取り消され、別のリプレゼンテーションからのより高いプレイバックレートのメディアが、プレイアウトされるべき場所にダウンロードされるので、より高品質のユーザエクスペリエンスがもたらされる。
[0199]この理由により、ストリーミングモジュール実装形態は、ダウンロードレートを監視するモジュールを実装することができ、いくつかの状況では以前の決定を取り消し得る。要求が取り消された場合、ストリーミングモジュールは、ダウンロードレートのより新しい、より適切な推定値に基づいて新規要求を発行するべきである。この監視モジュールを、本明細書では要求取消しプロセスと呼ぶ。
[0200]要求取消しプロセスは、様々な理由で要求を取り消すことができる。たとえば、ダウンロードレートが激しく下落し、プレイバックが、データが十分高速に受信されていないことにより、失速する危険があるという理由で、要求を取り消すことができる。取り消す別の理由は、プレイバックのために時間内により高品質のメディアが選択され、取り出され得ると決定された場合である。取り消すさらに別の理由は、受信機が何をしたか、および保留要求の完了の許容に対して取消しが失速期間を短縮するかどうかという推定にかかわらず、失速が起こると受信機が決定した場合である。受信機は次いで、可能性としてはプレイバックされるべきメディアリプレゼンテーションの品質も考慮に入れて、推定されたより短い失速とともに進むアクションを選ぶ。当然ながら、失速があるかどうか、および失速がある場合には失速の持続期間は、推定とは異なり得る。
[0201]実際の取消しは、取消しが決定された後には、要求がその上で発行されたＴＣＰ接続をクローズすることによって達成することができる。クローズは、取り消されたフラグメントについてのデータを送り続けないようサーバに伝えるという効果を有し、したがって、クローズされた接続によって使用される帯域幅が、置換えデータをフェッチするために利用可能になる。
[0202]ストリーミングモジュールは次いで、取り消された部分を置き換えるための要求を発行することができる。この目的のために新規ＴＣＰ接続をオープンすることが必要な場合がある。
[0203]ある実装形態は、置換え要求を選ぶいくつかのオプションを有する。どれが最も適切なオプションであるかは、プレイアウトされているコンテンツのタイプに依存し得る。
[0204]それは、ストリームのシームレスなプレイバックを可能にする置換え要求を選び出そうとする場合がある。一般的ケースでは、このことは、置換え要求が、前のダウンロードされたフラグメントの終了時に、またはその前に、切替え点をもたなければならないことを意味する。
[0205]その場合、プレーヤは、取消しなしでダウンロードを続けるときに失速が予測され、置換えセグメントの取消しおよび選択を用いると失速を回避でき、または少なくとも失速の持続時間を短縮できることが予測される場合、取り消すべきである。プレーヤは次いで、置換え要求についてのそのプロパティをもつ最も高品質のメディア要求を選び出すことができる。
[0206]レート取消しプロセスは、失速を次のように予測することができる。このプロセスは、フラグメント中の未処理バイトの数をダウンロードレートの推定値で除算することによって、発行された要求の推定完了時間を計算することができる。その時間が、円滑なプレイバックのためにフラグメントが必要とされるデッドラインよりも後の場合、失速が予測される。
[0207]切迫した失速が予測される場合、要求取消しプロセスは、レートの切替えが事態を改善する見込みがあるかどうかを決定し、改善が見込まれるときのみ、取り消すという決定が行われる。
[0208]一実装形態は、候補置換えフラグメントのレート推定値およびサイズにのみ基づいて、置換えフラグメントをロードするのにかかる時間を推定することができる。
[0209]別の実装形態は、取消しによる追加オーバーヘッドも考慮に入れることができる。すなわち、既存の要求を取り消し、新規要求を発行するのに必要とされる時間を考慮するために、推定ＲＴＴの倍数を加算することができる。取り消された要求からネットワーク上での配信のためにキューイングされているがまだ宛先には届いていないデータは、追加遅延に寄与し得る。クライアントは、この遅延を、ＴＣＰ受信ウィンドウサイズを推定レートで除算することによって推定することができる。遅延の別の推定値は、推定帯域幅遅延積に基づき得る。クライアントは、２つの推定値のうちの最大値など、２つの推定値を組み合わせることができる。
[0210]要約すれば、クライアントは、置換えフラグメント全体をダウンロードするのに必要とされる時間と、通常はＲＴＴに比例する量と、キューイング遅延の推定値との合計を計算する。失速が予測され、その時間が現在のフラグメントをダウンロードするための推定残り時間よりも小さい場合、取消しが発行される。
[0211]要求取消しプロセスは、また、初期のレート選択が正確でなかったために、第１のフラグメントをダウンロードするのに所望されるよりも長くかかることにプレーヤが気づいたときには、スタートアップ時に取り消すこともできる。
[0212]別のレート取消し実装形態は、また、シームレスなプレイバックを認めず、いくつかのフレームをスキップすることを含意する、置換え要求を選び出すこともできる。これは、エンドツーエンドのレイテンシが小さく保たれることを要求するライブコンテンツを再生するときに必要となり得る。
[0213]フレームスキップを用いて取消しを行う実装形態は、フレームスキップが可能な限り小さくなるような方法で置換えフラグメントを選び出すことができる。
[0214]この実装形態は、置換え要求として、指定された失速持続期間またはスキップフレーム持続期間を超えることなく持続可能にダウンロードすることができる、最も高品質の要求を選ぶことができる。
[0215]すでにダウンロードされたフラグメントについては、異なる種類の取消しが実装され得る。プレーヤは、プレイアウトされる予定のいくらかのメディアをすでにバッファリングしている場合、ネットワークを通じてより高品質のリプレゼンテーションをフェッチし、それをストリーミングすることを決定することができ、以前バッファリングされた、より低品質バージョンは破棄し得る。
[0216]その取消しプロセスは、失速することなくプレイアウトすることができるように時間内により良好な品質のビデオを受信することができると決定した場合、これらの置換え動作を行うことを決定し得る。
[0217]図２６は、時間Ｔ１における新規フラグメント要求の直後に起こる、ダウンロードレートの強烈な下落を示す。この要求まで、受信レートはＯＲであり、次いで、ＮＲに下落する。バッファレベルは今では下落している。新たに要求されたフラグメントは、約Ｔ２＝Ｔ１＋ＯＲ／ＮＲ＊フラグメント持続期間の時間に、完全にダウンロードされる。ＯＲ／ＮＲが大きい場合、この値は、時間Ｔ１におけるバッファ中のメディアコンテンツのｐ時間の持続時間よりも大きくなり得、このことは、要求されたフラグメントは、失速なしではプレイバックされないことを意味する。ｐｋｅｒエスティメータは、はるかに速くレートＮＲに収束しているが、Ｔ１よりも前に要求が行われたので、フラグメントのダウンロードは、推定値が新規レートＮＲに収束する機会がないうちに行われることに留意されたい。失速を避け、訂正された推定値をもつ新規要求を発行するために、要求を取り消し、より適切なビットレートで要求を再発行することが必要である。
[0218]図２７は、要求取消しのあるケースを示す。ダウンロードレートの鋭い下落（線２７０２）の後、バッファはドレインし始め、推定ダウンロードレート（たとえば、ｐｋｅｒプロセス）は、新規ダウンロードレートに収束し始める。どこかの時点で、ストリームマネージャは、失速なしでプレイバックのための時間内にフラグメントが受信されないことに気づく。その点は、図２７のプロットにおいて、「取消し点」２７０４としてマークされている。その時点で、部分的に受信されているフラグメントは、取り消され、バッファから追い出される（したがって、バッファレベルがさらに下落する）。しかしその後、正しいレートをもつフラグメントが要求され得るので、バッファレベルはそれ以上下落しない。実際、自明でない（nontrivial）レート選択プロセスが使用される場合、レベルは再度増大し得る。
[0219]図２８は、例示的要求取消しプロセスを示すフローチャートである。
[0220]図２９は、要求取消し検出のためのプロセスを示す。
[0221]ここで、上記詳細に基づいて、要求取消し実装形態について説明する。
[0222]このセクションにおいて、Ｎiは、要求されたが、まだ完全には受信されていない、リプレゼンテーショングループｉ中のフラグメントの数を示す。これらは、Ｆi,1，…，Ｆi,Niとして参照される。さらに、Ｆi,jは、開始ｐ時間の昇順でソートされると仮定し、α（Ｆi,j）は、要求されたフラグメントＦi,jについてすでにダウンロードされたバイトの量を、バイトで表されたフラグメントのサイズで除算したものである。変数Ｔは、現在のプレイバックｐ時間を示す。要求取消し検出プロセスは、図２９の擬似コードによって示すように進行し得る。
[0223]要求取消し検出プロセスは、実行されると、ニル（nil）を返すことができ、この場合はいかなるアクションもとられることはなく、あるいは、取り消すべきグループ中のフラグメントを識別する。そのようなフラグメントが識別された場合、このことは、このフラグメント、および（ｐ時間順で）その後にくる、同じグループ中のあらゆるものが、取り消され、バッファからフラッシュされるべきであることを意味する。ＳＭは次いで、そのレート決定プロセスを再度呼び出し、セクション用に新規代替要求を発行するべきである。
[0224]このプロセスを説明するために、差し当たり、単一の要求のみが今のところ未処理であると仮定する。その場合、Ｒを、ダウンロードレートの正確な推定値とし、ｄavailを、問題となっているフラグメントがプレイアウトされることになるまで、依然として受信することができるバイト数とする。量ｄneedは、そのフラグメント中で依然として欠けているバイト数である。したがって、ｄavail＜ｄneedの場合、プレーヤは、フラグメントＦi,jを再生する前に失速すると予測する。このことは、以上のプロセス中の最初の「ｉｆ」条件について説明している。
[0225]失速が予測される場合であっても、取消しにより失速を避けることになる場合、または少なくともその持続期間を短縮する場合にのみ、取り消すことに意味がある。取消しの後には、新たなフラグメントが選択され、最初からダウンロードされなければならない。ただ１つのリプレゼンテーショングループがあり、レート決定プロセスが正しいレートを選んだ場合、これには持続期間（Ｆi,j）のほぼλ倍の時間がかかり、ここでλは、現在の適切なラムダ因子である。一方、ＳＭが切り替えないと決定した場合、現在のフラグメントダウンロードの終了には、ｄneed・Ｒ-1の時間がかかる。簡単のために、λ＝１と仮定すると、他の因子をもち得る、第２の条件が得られる。
６． 要求アクセラレータ
[0226]ストリーミングメディアクライアント向けの直接的なやり方は、単一ＨＴＴＰ接続を用いてメディアをフェッチすることである。そのようなクライアントは、フラグメント要求を連続して処理することになる。そのような手法には、ビデオストリーミングにおいていくつかの欠点がある。第１に、一般的ネットワーキングソフトウェアはしばしば、長いダウンロードにわたる最大スループットについてのみ合わせられる。これは、大きいファイルを受信するには良いが、安定受信レートなど、他の重要なストリーミング目標とは相反する。第２に、ＴＣＰの性質により、リンクの満杯容量は、必ずしもそのようなＨＴＴＰ接続とともに使用することができるわけではない。チャネルが、ある程度の遅延とパケット損失とを受ける場合、ＴＣＰは、達成され得る実際のスループットを制限し、こうすることにより、ストリーミングクライアントが、良好な品質のメディアをストリーミングするのが妨げられる場合がある。
[0227]これらの問題を避けるために、本明細書において要求アクセラレータ（ＲＡ）と呼ぶ、特殊ＨＴＴＰクライアントが実装されることができる。要求アクセラレータは、前述した問題を回避または軽減するための特殊プロセスを有する。要求アクセラレータのある実装形態は、いくつかの重要な要素を利用して、その目標を達成することができる。それは、いくつかのＴＣＰ接続を使用して、データを受信することができる。それらの接続は、並行してアクティブであることができる。データ要求を、より小さいチャンク要求に分割することができ、それらのチャンク要求は、異なる接続上で個々にダウンロードされ、要求アクセラレータにおいて、１つの大きな部分に再アセンブルされ得る。それは、接続が相互に公平（fair）になるように、ＴＣＰ接続パラメータ（具体的には、ＴＣＰ受信ウィンドウサイズなど）を調節し、比較的安定したデータ受信を行うことができる。それは、使用するべきＴＣＰ接続の数を、測定されたネットワーク条件および目標プレイバックレートに基づいて動的に調整することができる。
[0228]使用するべきＴＣＰ接続の理想的な数は、ネットワーク条件、特に、ラウンドトリップ時間（ＲＴＴ）およびパケット損失挙動に依存する。ＲＡはしたがって、これらの量を推定するための方法を使用することができる。
[0229]ＲＡは、ＨＴＴＰ要求の発行から、応答が着信し始めるまでかかる時間をサンプリングすることによって、ＲＴＴを推定することができる。一実装形態は、一定期間、たとえば最後の数秒間にわたって取得されたすべてのそのようなサンプルの最小値をとることによって得られるＲＴＴの推定値を使用することができる。別の実装形態は、最後のＮ個の取得サンプルの最小値を使用することができ、ここでＮは、推定値としての何らかの整数である。
[0230]ＴＣＰプロトコルは、パケット損失を扱い、連続するデータプリフィックスをアプリケーションに届けるので、ＴＣＰ層より上でのパケット損失の測定値を取得することは、しばしば困難である。したがって、代わりに、パケット損失についての妥当な値をＲＡプロセスへの入力として固定することが有用なことがある。ある実装形態は、損失を一定であると推定し得る。いかなるパケット損失測定値ももたないので、ＲＡは、損失を１％であると推定する場合もあり、または、ＲＡは、損失を０．１％であると推定する場合もある。推定値は、接続のタイプによって決定されることができ、たとえば、推定値は、ＷｉＦｉ接続については０．１％に設定され、セルラー接続については１％に設定され得る。ＲＴＴにおける分散など、他の方法も、ＲＡによってパケット損失を間接的に推論するために使用されることができる。あるいは、ある実装形態は、パケット損失推定値を、それに関する情報についてオペレーティングシステムカーネルを照会することによって取得することができる。
[0231]別の実装形態は、アプリケーション自体における損失を推定することができる。そうするために、その実装形態は、ネットワークソケットからのデータが概して最大セグメントサイズの（ＭＳＳ）チャンクの形で受信されるが、パケット損失は、はるかに大きいチャンクの受信、すなわち近似的にＴＣＰ受信ウィンドウ全体のサイズのバーストを引き起こす、という観察に基づいた以下の手順を使用することができる。Ｍを、バイトで表されたＭＳＳとすると（良好な推測は、Ｍ＝１５００である）、ｎバイトが受信された場合、送られるパケットの数は約ｎ／Ｍである。ｚを、ｋ・Ｍバイトを超える読込みを生じたソケット読込みの数とする、ここでｋは、ある小さい整数である。ｋは、アプリケーションの２つのネットワーク読込みの間にｋ個以上のパケットが到着した見込みがないように、十分に大きいように選ばれると仮定する。ソケット上でコンスタントに待機するアプリケーションについては、ｋ＝３がよい。すると、ｐ＝ｚ・Ｍ／ｎが、パケット損失確率の推定値である。所望の開始点から、ｚとｎとをカウントすることによって、この手順は、時間の任意の所望の範囲にわたるパケット損失レートを推定することができる。
[0232]ＲＴＴの推定値およびパケット損失確率が与えられると、アプリケーションは、必要とされるかなりの数の接続を計算することができる。このプロセスは特に、目標ダウンロードレートがその接続数で達成され得るように十分に大きい、接続の数を選ぶことができる。単一レートの達成可能レートは概して、達成可能スループットに関するＴＣＰ式によって制限され、この式によると、おおまかにいえば、単一のＴＣＰ接続が、Ｔ＝ＭＳＳ／（ＲＴＴ・√ｐ）の平均ダウンロードレートを達成することができる。したがって、このプロセスは、目標ダウンロードレートをＴで除算したものに比例するように、接続の数を選べばよい。
[0233]ＲＡは、使用するべきＴＣＰ接続の数に対して、現実的な理由により、下限と上限とを課してもよい。たとえば、ＲＡは、ＲＡがオープンする接続の最大数を８に、および接続の最小数を２に制限してよい。
[0234]帯域幅、損失確率、およびＲＴＴは、変わることがある。要求アクセラレータは、それらの量を監視し、接続の数を動的に変える。
[0235]要求アクセラレータは、ＨＴＴＰ要求を、より小さいサブ要求に分割し、あらゆるサブ要求についての戻されたデータ応答を、元の要求に対応するコヒーレント応答に再アセンブルすることができる。要求をサブ要求に分割するのには、いくつかの利点がある。第１に、利用可能ＴＣＰ接続を使用するために、それらの接続すべての上で要求を発行できることが必要である。メディアストリーミングプレーヤは、接続すべてを使用するような十分な要求を与えるわけではない場合がある。要求分割は、より多くの数のサブ要求を生じ、サブ要求は様々な接続上で発行され得るので、この問題を緩和する。第２に、要求分割はより短い要求を生じ、そうすることによって時機を逸したデータ配信の危険性が低減され、すなわち、一部のＴＣＰ接続が、他の接続よりも時間的に遅い場合、それらの一部の接続は、依然として短い要求とともに使用されることができる。それらは、速い方の接続よりも応答を配信するのが遅いが、要求が小さいので、全体的要求を完了するための追加的な相対遅延は通常、それ程大きくない場合がある。
[0236]概して、より多くの接続が使用されている場合、１つの要求につき、より多くのサブ要求を作成することが好ましい。これを達成するために、要求アクセラレータは、ｎ個の接続があるとき、各要求を、ｎ個のサブ要求に分割することができる。
[0237]別の実装形態は、要求サイズに応じて、１つの要求当たりのサブ要求の数を選び出す。サブ要求サイズが、ダウンロードするのに一定の時間量（たとえば、２秒）かかることが予測されるサイズとなるように選ばれた場合、要求は、より多くの接続がある場合はより多くのサブ要求に分割され、所望の効果を達成する。
[0238]分割ルールは、不必要に小さいサブ要求がないようにすべきである。たとえば、ＲＡ実装形態は、その分割プロセスにおいて最小サブ要求サイズを課し、最小値が満たされない場合はより少ないサブ要求に分割することができる。
[0239]マルチプルなＴＣＰ接続が使用されるとき、それらの接続は、帯域幅について競合する可能性がある。大きい時間スケールにおいて、各接続は、他の接続と同じ量を受信するが、２〜３秒間など、より小さいスケールでは、一部のＴＣＰ接続は、他の接続よりも著しく遅い場合がある。これは、いくつかのサブ要求が、他の要求よりもはるかに長くかかる場合があり、それがプレイバック失速につながり得ることを含意するので、ストリーミングについての問題を起こす。
[0240]これを避けるために、ＲＡは、ＴＣＰフロー制御を使用して接続を「制御（tame）」すればよい。こうすることにより、各ＴＣＰ接続の最大受信ウィンドウを十分に制限することができるので、接続は、その公平なスループット分担を超えて使用することはない。ＴＣＰ接続を介して飛行中の（送られたが、まだ受信確認されていない）データの量はおおよそ、ダウンロードレートをＲＴＴで除算したものである。したがって、ＴＣＰ受信ウィンドウが、接続についての目標ダウンロードレートを推定ＲＴＴで除算したものにおおまかに、またはそれよりもわずかに大きく設定された場合、ダウンロードレートは、目標ダウンロードレートにおおまかに、またはわずかに大きく制限される。したがって、ＴＣＰ受信ウィンドウサイズの設定は、調速機（governor）として作用することができ、所与のＴＣＰ接続が、他のＴＣＰ接続にはるかに低いレートでダウンロードするよう強制したような高いレートでダウンロードすることがないようにする。そのようなメカニズムが整っているので、接続は、おおよそ同じ速度でフェッチする傾向にあり、というのは、遅い接続は、公平な分担まで速度を上げるのに利用可能な帯域幅を有するが、同時に、接続は、少なくとも総目標受信レートであり、またはそれよりもわずかに高い、総ダウンロードレートを達成し得るからである。
[0241]ＲＡは、受信バッファを調整することによって、クライアントにおける受信ウィンドウを調整することができる。ＲＡは、連続する要求の間でこれらの設定を常に再調整する。
[0242]一実装形態は、各接続のＴＣＰ受信ウィンドウを、推定ＲＴＴと、目標ダウンロードレートを接続の数で除算したものの積よりもわずかに大きく設定し得る。
[0243]目標ダウンロードレートは、たとえば、プレイバックすることを目指すメディアレートから決定され得る。別の実装形態は、現在のプレイバックレートに基づいて（たとえば、現在のダウンロードレートの２倍）目標レートを設定し得る。
６．１ ＲＡの実施形態
[0244]ここで、上述した要素を組み込む要求アクセラレータの実施形態について説明する。
[0245]図３０は、マルチプルなＴＣＰ接続を用いてフェッチする挙動のプロットである。図３０〜図３１は、様々な条件下での挙動を示す。この例において、ウェブサーバへの接続は、毎秒２メガビット（「ｍｂｐｓ」）に制限された帯域幅であり、ラウンドトリップ時間は１５０ｍｓであり、０．１％のパケット損失があった。４つの接続アクティブフェッチフラグメントがあった。図３０〜図３１のプロットは、４つの接続の瞬間レート、ならびに総合レート、ならびにクライアントにおいて取得されたＲＴＴ推定値を示す。
[0246]図３０において、接続の受信バッファは制限されていない。図３１では、受信バッファは帯域幅と遅延との積の約２倍に制限されている。
[0247]図３０および図３１の例において、両方の方法は、安定して２ｍｂｐｓの総スループットを達成する。接続が制限された受信ウィンドウを有するケース（図３１）では、接続の間の配信は、いっそう一様であり、すなわち、ほとんどの時間、接続はほぼ同じレートで受信する。これは、無制限ウィンドウをもつ接続（図３０）にはまったく当てはまらず、この場合、いくつかの接続は、長い時間ストレッチにわたって、他の接続よりも遅い。
[0248]不均一な接続速度は、ストリーミングアプリケーションにとって問題があり、というのは、何らかの緊急データが、（遅い接続上で）非常にゆっくりとしか着信しておらず、帯域幅は、緊急には必要とされないデータをフェッチすることができるより速い接続の方に転用されることを意味し得るからである。
[0249]無制限ウィンドウと制限受信ウィンドウとの間の別の違いは、クライアントが動作するときのＲＴＴである。制限が整っているので、ＲＴＴは、低いままであり、伝播遅延に近い。受信ウィンドウ制限がないので、飛行中のデータの量が、基底の伝播遅延に接続の容量を乗じたものを超えると、キューイング遅延は非常に大きくなり、高ＲＴＴを引き起こし得る。多くのイベントに対するクライアントの反応時間は概してＲＴＴの倍数であるので、高ＲＴＴは、メディアストリーミングクライアントにとって望ましくない。たとえば、新規メディアコンテンツをダウンロードさせるユーザ探究イベント、または要求取消しもしくはリプレゼンテーションの切替えを引き起こすダウンロード速度の低減に対するクライアント反応時間は概して、現在のＲＴＴの何倍にもなり、したがってそのようなイベントに対するクライアントの一般的応答性は、ＲＴＴが大きいとき低下する。
[0250]図３２は、要求アクセラレータプロセスのフローチャートである。
[0251]図３３は、所与のフラグメント要求を生み出すためのいくつかのサブ要求を見つけるためのプロセスを示す。
[0252]図３４は、計算されたサイズを有するソース要求の分離区間となるように選ばれた個々の要求を選択するためのプロセスを示す。このプロセスにおいて、サブ要求サイズは意図的にランダム化され、そうすることによって、接続がアイドルである時間は、接続によって変化する。こうすることにより、すべての接続が同時にアイドルになることが避けられ、その結果、より良好なチャネル使用となる。要求サイズも順序付けられ、そうすることによって、より大きい要求がより早く出され、制限されるアイドル時間の差を保つのを助ける。
[0253]図３５は、時間オフセットと、時間オフセットによって決定される修復セグメントについてのフラグメント構造との例を示す。
[0254]動作に際して、要求アクセラレータは、ＨＴＴＰ要求（各要求は、ＵＲＬおよびバイト範囲である）をＳＣから受信する。
[0255]要求アクセラレータは、ＨＴＴＰを介して、要求されたバイト範囲をダウンロードし、データが完全に受信されると、ＳＣにデータを返す。ＲＡは、十分に大きいダウンロード速度を達成するが、同時に、各フラグメントがその最終期限時間前に必ず受信されるようにすることを目指す。高ダウンロード速度により、高品質のビデオリプレゼンテーションを選ぶことが可能になるとともに、期限を尊重することによって、プレイバックが失速なしで必ず進むようになる。
[0256]高ダウンロード速度という目標を達成するために、ＲＡは、変化する数のオープンなＴＣＰ接続を管理し、これらの接続はすべて、ＨＴＴＰを介してデータを受信するのに使用される。ＲＡは、何個の接続を使用するべきか、必要な場合はそれらの接続のオープンまたは再オープン、ならびにどのように要求を接続にディスパッチするかの詳細について引き受ける。
[0257]ＲＡは、いくつかのケースでは、ソース要求を、より小さいいわゆるＲＡ要求に分割することを決定し、ＲＡ要求は次いで、様々な接続にディスパッチされ、その応答データは、到着すると、ＲＡによってトランスペアレントに再アセンブルされる。たとえば、何らかのファイルの最初の６４キロバイトを備えるソース要求について、ＲＡは、２つのＲＡ要求を作成することができ、１つはそのファイルの３２キロバイトチャンクについてであり、もう１つは、第２の３２キロバイトチャンクについてである。ＲＡは次いで、それらの２つのチャンクを２つの異なる接続上で並列に要求し、２つの３２キロバイトチャンクが受信されると、元の要求について、コヒーレントの６４キロバイト応答を作成することができる。
[0258]ＲＡは、ソース要求の単なるプレーンな部分的範囲以上のものであるＲＡ要求を発行し得る。たとえば、プレーンなビデオデータに加え、フラグメントのＦＥＣデータについての要求を発行することができる。その場合、ＲＡは、ＦＥＣ情報が受信されると、その情報をトランスペアレントに復号し、最終的な復号フラグメントのみをソースに提示することになる。
[0259]ＲＡは、ＲＡ自体を、ネットワーク条件に自動調節する。たとえば、ＲＴＴが大きい場合、ＲＡは、要求の間のたくさんのアイドル時間を避けるように、より大きいチャンク要求を発行することを決定し得る。自動調節の別の例は、ＲＡが、その要求の適時性を確実にするように、個々の接続の速度を同様に保とうとすることである。それらのことをできるようにするために、ＲＡは好ましくは、その接続のソケットへの直接アクセスを有する。たとえば、Ｕｎｉｘ（登録商標）のような環境では、ｓｅｔｓｏｃｋｏｐｔ（）関数を使用してソケットオプションを設定することが可能である。
[0260]ＲＡは、ネットワーク状態を測定および追跡し、これは特に、ダウンロードレートと推定ラウンドトリップ時間（ＲＴＴ）とを測定することを含む。ＲＡがこの情報を収集する理由は、第１に、接続の自動調節がそれらのアベイラビリティに依存するからであり、第２に、帯域幅情報がＳＭにパスされる必要があるからであり、ＳＭは、その情報を使用してＳＭレート推定値を計算する。
[0261]ＲＡがＳＭに（ＳＣを経由して）フォワードする別の情報ピースは、未処理要求についての進行情報、すなわち、所与の要求のうちどの程度のデータがすでに受信されているかである。ＳＭは、その情報を、ＳＭレート推定値と、要求取消し決定の両方に対して使用する。
[0262]ＲＡは、ＳＭによって、帯域幅推定を行うのに必要とされる情報を追跡する。この情報は、ダウンロードに費やされるｒ時間の総量、すなわちＴr、およびダウンロードされたバイトの総量、すなわちＺである。これらの数は両方とも、単調に増加しており、ＳＭによって頻繁にポーリングされる。Ｔrタイマは、少なくとも１つの接続がアクティブである場合にのみ動作している。接続は、ＨＴＴＰ要求を送り出し、または応答データが着信するのを待っている場合、アクティブと見なされる。Ｚカウンタは、着信バイトをカウントし、すべての接続にわたって集計される。
６．１．１ ＲＡダウンロードレート履歴
[0263]要求アクセラレータは、履歴順に記憶される、（Ｔr，Ｚ）ペアの増大アレイを保つことによって、レートの何らかの履歴を追跡する。このアレイを、ｍａｐＴｒＺと呼ぶ。ｍａｐＴｒＺの更新は、頻繁に、少なくとも一定時間間隔で（たとえば、１００ｍｓおきに）、場合によっては新規データが受信されたときにも、起こる。
[0264]ＲＡは、ｍａｐＴｒＺを利用して、ウィンドウ化帯域幅推定値を次のように計算することができる。幅ｔである、関心のウィンドウを検討し、ｍａｐＴｒＺ［ｌａｓｔ］を、ｍａｐＴｒＺ中の最後のエントリとする。次いで、ｍａｐＴｒＺ［ｉ］．Ｔr≦ｍａｐＴｒＺ［ｌａｓｔ］．Ｔr−ｔであるような、最も大きいインデックスｉを見つける。ｉは、バイナリサーチで効率的に見つけられ得ることに留意されたい。レート平均は次いで、式８に示すようになる。
[0265]式８は、後続Ｔrにおける差が、ｔと比較して小さいと仮定する。このことは、十分頻繁にサンプリングし、小さいウィンドウ幅ｔを決して選び出さないことによって保証される。
[0266]実際に、任意に増大するアレイは厄介である。過去について考察される最大持続期間は上限を定められ得るので、ｍａｐＴｒＺを、代わりに固定サイズのリングバッファとして実装するやり方がある。これは、次のように行われ得る。ｍａｐＴｒＺアレイがアップデートされるべきであり、ｍａｐＴｒＺアレイが少なくとも２つのペアをすでに含むときは常に、Ｔr−ｍａｐＴｒＺ［ｌａｓｔ−１］．Ｔr＜１００ｍｓである場合は最後のエントリを置き換え、新規エントリを他のやり方で追加する。
６．１．２ ラウンドトリップ時間（「ＲＴＴ」）推定値
[0267]ＲＡは、帯域幅推定値を収集する。アプリオリなＲＴＴサンプルを受け取るための簡単なやり方は、ＨＴＴＰ ＧＥＴ要求がアイドル接続上で送出され、応答が着信し始めるときの時間の差を測定することである。
[0268]ただし、そのような測定値は、キューイング遅延を実際に含む。すなわち、クライアントが他のオープンなアクティブ接続を有する場合、クライアントにデータを送る最後のホップは、クライアントへのそのリンクが、データを受信することができるレートよりも低いレートを有する場合、いくつかのパケットをバッファリングし得る。その場合、パケットは、本来よりも長い遅延で配信され得る。
[0269]我々のケースでは、クライアント自体の活動によって誘発されるキューイング遅延を無視するＲＴＴを知ることが望ましい。その量の推定値を受け取るために、次のように進める。
[0270]各活動期間中、前述したタイミング方法を用いてＲＴＴサンプルを収集し、各ＧＥＴの結果、サンプルが得られる。すると、現在の推定値は、すべてのそれらのサンプルのうち最小である。サンプルのリストは、ＲＡが非アクティブになるときには常にフラッシュされる。（クライアントは、たとえば、高ウォーターマークのセクション３を超え、開始されたダウンロードが終了すると、非アクティブになる）。非アクティブ期間中、またはどのＲＴＴサンプルも受信される前のアクティブ期間中、ＲＴＴ推定値は、最終的な既知の推定値である。
[0271]ＲＴＴエスティメータは、象徴的な「どのＲＴＴ推定値も既知でない」という値を戻すこともでき、この値は、たとえばクライアントスタートアップ時に使用することができる。
６．１．３ ＴＣＰ接続の数の調整
[0272]ＴＣＰフロー制御の調節により、ＲＡは、様々な接続における帯域幅を、おおよそ同じに保つことができる。いくつかの構成可能な調節定数は、ｋR（ＲＴＴ中で測定されたレート測定値ウィンドウであって、奨励値は３０）と、ｋN（比例因子であって、奨励値は８１９２バイト）と、Ｎmin（Ｎtarget下限であって、奨励値は１）と、Ｎmax（Ｎtarget上限であって、奨励値は８）とを含み得る。
[0273]推定の帯域幅遅延積（ＢＤＰ：bandwidth-delay-product）は、ＢＤＰ：＝ＲＴＴ・Ｒとなるように定義され、ここでＲＴＴは推定ＲＴＴ（上記のように）であり、ここでＲは、最後のｋR・ＲＴＴ時間（ウィンドウ方法で推定される）にわたる平均受信レートである。
[0274]目標接続数は次いで、式９にあるように定義され、ここでｋNは構成可能定数である。
[0275]Ｎtargetの値は、定期的に計算し直される。現在オープンな接続の数がＮtarget未満である場合、Ｎtargetに一致するように、新規接続が直ちにオープンされる。一方、Ｎtargetが、現在オープンな接続の数未満の場合、いかなる即時アクションもとられない。そうではなく、ＲＡ要求が終了されると常に、ＲＡは、オープンである接続の数が多すぎるかどうかをチェックし、多すぎる場合、アイドルになったばかりの接続をクローズする。
６．１．４ 接続におけるＴＣＰ受信ウィンドウの調整
[0276]ＲＡは、各接続のＴＣＰ受信ウィンドウサイズを、
に設定する。ここで、ｃwは、設定可能なハードコードされた定数であり、たとえばｃw＝３である。ＲＡは、その接続上で次のＨＴＴＰ要求を発行しようとしているときには常に接続のＴＣＰ受信ウィンドウサイズを設定する。
６．１．５ 要求分割プロセス
[0277]ＲＡに渡された各ソース要求は、おそらく２つ以上のＲＡ要求に分割され、これらのＲＡ要求は各々、要求された範囲の異なる部分に対応する。所与のソース要求に対応するＲＡ要求がすべて完了されると、受信データは、ＲＡによって完了フラグメントに再アセンブルされ、完了フラグメントは次いで、ＳＣに戻される。
[0278]所与のＨＴＴＰ要求について、ＲＡは、いくつかの調節可能値に依存するプロセスを使用して、ＲＡ要求の数ｎを決定する。ｎの値は、Ｔwn（レート推定値ウィンドウ幅であって、奨励値は４ｓ）、Ｄmin（最小フェッチ持続期間であって、奨励値は２ｓ）、およびｃs（ＲＴＴ中の最小フェッチ持続期間であって、奨励値は６）という調節可能な定数に依存する。
[0279]すると、サブ要求の数ｎを見つけて、所与のフラグメント要求を行うためのプロセスは、図３３の擬似コードに示すようになる。
[0280]個々の要求は次いで、たとえば、計算されたサイズを有する、図３４に示すプロセスを使用して、ソース要求の分割間隔となるように選ばれる。
６．１．６ 要求ディスパッチプロセス
[0281]要求アクセラレータは、ＲＡ要求のセットを維持する。接続が、次の要求を発行する準備ができたときには常に、キューが空いていない場合は要求がＲＡキューからデキューされ、アイドル接続上で発行される。キューが空の場合、新規フラグメント要求がＳＣから取得される。その要求は次いで、ＲＡ要求に分割され、ＲＡキュー上でキューイングされる。キューイングは好ましくは、サブ要求の数を見つけて所与のフラグメント要求を行うためのプロセスによってスライスが戻される順序で行われる。
[0282]ＨＴＴＰ接続は、様々な理由で、たとえば、ウェブサーバタイムアウトが起こり、または単一接続上で発行され得る要求の数を超えたことが原因で、シャットダウンを受け得る。ＲＡは、このステータスを適切およびトランスペアレントに扱うべきである。接続がシャットダウンされるときは常に、ＲＡは、接続を自動的にオープンし直す。要求は、クローズされた接続上で要求が進行中の場合、接続からデキューされ、未受信部分についての新規ＲＡ要求が、ＲＡキューの前に置かれる。
[0283]この手順により、クローズされた接続は確実に、パフォーマンスに対して最小限の影響しかもたないことになる。
６．１．７ 特定の実施形態におけるＲＡパラメータ選択
[0284]ＴＣＰ接続は、そのフロー制御によって制限される。すなわち、広告される受信ウィンドウは、どの時点でも受信確認されないことが許容されるデータの量に上限を定める。したがって、Ｗが、受信ウィンドウのサイズを示し、ｂｄｐがその接続の帯域幅遅延積を示す場合、ｂｄｐ≦Ｗ（条件１）を得る。セクション６．１．４の方法は、ｃw＞１であるとすると、この条件（１）が満たされるような受信ウィンドウサイズを選ぶことを記述している。この方法により、個々の接続が、利用可能帯域幅のその公平比率を実質的に超える比率をとる可能性は確実になくなる。レート増大を可能にし、レート下方スパイラルを避けるために、１よりもある程度大きいｃw、たとえば、ｃw＝２またはｃw＝４を選ぶことが好ましい。この値が大きい程、レートはより速くなることができるが、相互に対して接続が公平でなくなる。
[0285]別の制限は、ＴＣＰ輻輳制御プロセスによって課される。ｐがパケット損失確率を示し、ＭがＴＣＰ最大セグメントサイズを示す場合、単一接続のレートｒは、式１０によって示すように制限される。
[0286]ここで、この式を、ＢＤＰおよび接続の数Ｎによって（ｂｄｐ＝ｒ・ＲＴＴとＢＤＰ＝Ｎ・ｂｄｐとを使用する）書き換えると、式１１に示すものを得る。
[0287]この式は、ｋNが、式１１中の不等式が確実に成り立つように、式９中の
未満のビットになるように選ばれるべきであることを示唆する。Ｍについての典型的な値は１キロバイトであり、ｐ＝０．０１と設定した場合、
となる。したがって、この例では、式９におけるＮを設定するために、セクション６．１．３において提案されたようにｋN＝８，１９２バイトと設定することにより、式１１の不等式が確実に満足される。受信機は、適切に構成またはプログラムされ得る。
[0288]ここで、所与のソース要求についてのＲＡ要求の数ｎを計算するための、上のセクション６．１．３のプロセスに移る。アプリオリに、小さいスライスはいくつかの利点を呈するのでスライスを可能な限り小さくしたい。そのような利点として、ある接続が他の接続に比べて遅い場合、そのことが、小さい要求に関する問題を引き起こす可能性は比較的低い、というのは、小さい要求は、遅い接続上であっても迅速に終了するからである。したがって、小さいスライス設定では、遅い接続は本質的に、比較的少ない要求をサービスする結果になる。小さいスライスの別の利点は、ＲＡに、バッファの時間内の比較的短いセクションに対して作用させるので、ＲＡは、最も緊急な作業エリアに対するその作業を強化する傾向があることである。
[0289]ただし、スライスを小さくすることには、代償が伴う。すなわち、第１に、各要求が、アップリンクとダウンリンクの両方においていくらかのオーバーヘッドを招く。第２に、１つの要求を終了した後、接続は、約１ＲＴＴだけ、アイドルのままである。したがって、要求分割プロセスは、理想的には、あまりにも多くのアップリンクトラフィックを引き起こすことも、各利用可能リンクの容量を実質的に利用しきれないこともない、可能な限り小さいチャンクを選ぶことを試みるべきである。好ましいプロパティはしたがって、次のようになる。
[0290]１．リアルタイムのＤminごとに、１つの接続につき多くとも１つの要求を目指す。こうすることにより、アップリンクトラフィックは、最悪のケースにおけるＮtargetに比例する値を限度とする。
[0291]２．ｃs・ＲＴＴおきに、１つの接続につき多くとも１つの要求を目指す。こうすることにより、接続の活動時間が、少なくとも約ｃs／（ｃs＋１）になるようにされ、すなわち、中間のｃsでは１に近づく。
[0292]Ｄminの良好な選択は、使用ケースに依存する。所望のエンドツーエンドの遅延と同程度（ただしそれ未満）のＤminを選び出すことは、一般に、フラグメントの典型的な持続期間である。エンドツーエンドの遅延が大きくなるべき場合、より大きいバッファが使用されることができ、より大きいスライスの悪影響はより小さくなる。一方、短いエンドツーエンドの遅延において、バッファは小さいので、スライスは、失速を引き起こす遅い接続を避けるように小さくあるべきである。そのシナリオにおいて、より高いコストの、より小さい要求は、バッファレベルでの、得られる安定性に値する。
[0293]使用されるパラメータは、ＭＰＤ（メディアプレゼンテーション記述）中のプロファイルインジケータが、クライアントに対する、ストリーミングされるメディアのプロパティの要約なので、そのインジケータに従って調節され得る。あらゆるメディアセグメントをダウンロードし、それらをエンドユーザに見せるのではなく、クライアントは、ＭＰＤ内部のプロファイルにある様々な使用ケースに基づいて、セグメントを「スキップする」ことを選ぶことができる。
[0294]ｃsの選択に対する下限は、次のように考えればよい。Ｎ個のオープンな接続があり、ＲＡがアクティブである場合、平均で、約Ｎ・ｃs／（ｃs＋１）個のアクティブな接続がある。すべてのＮ個の接続の受信ウィンドウが、全体として、総計目標レートを持続させるのに十分に大きくなるのを確実にするために、ｃw・ｃs／（ｃs＋１）が少なくとも１であることが望ましい。
[0295]この限度はコンサバティブである。アクティブ接続の推定数Ｎ・ｃs／（ｃs＋１）は、ある程度の分散がある可能性が高くても、分散を考慮に入れていない平均にすぎない。実際に、ｃsを、上記限度によって奨励される値の約２〜３倍にすることが有利であり、たとえば、ｃw＝３およびｃs＝６のとき、ｃw・ｃs／（ｃs＋１）は少なくとも２．５である。
６．２． 前方誤り訂正をもつＲＡ
[0296]データがいくつかのＴＣＰ接続を介して受信されるとき、これらの接続は、時間的に異なるダウンロードレートを有することがある。フラグメントの要求がいくつかのサブ要求に分割されたとき、フラグメント全体は、最後のサブ要求応答（チャンク）が受信されたときに受信されるだけである。フラグメントが緊急に受信される必要があるとき、サブ要求のうち１つが遅い接続上で扱われる場合があり、フラグメントが素早く受信されるのを妨げるので、これは問題となる場合がある。
[0297]コンテンツプロバイダは、ビデオデータに加え、各フラグメントについての追加の前方誤り訂正（「ＦＥＣ」）修復データを与えることができ、クライアントはこのデータをフェッチして、元のフラグメントを再構築するのを助けることができる。たとえば、クライアントが、４つの接続を有し、４０００バイトのサイズのフラグメントを緊急に受信する必要があると仮定する。クライアントの要求アクセラレータは、フラグメントを、各々が１０００バイトからなる４つの範囲に分割し、４つの接続の各々において１つの要求を発行することができる。接続１は高速であり、接続４は適度に高速であるが、第２および第３の接続ははるかに遅い場合がある。したがって、総ダウンロードレートが、原則として、フラグメント全体を時間内にダウンロードするのに十分に高い場合であっても、フラグメントは、接続２および３が行き詰っているので、非常に遅れてしか届かない。
[0298]この問題を避けるために、クライアントは、それ自体のサブ要求についてデータフェッチが行われるとすぐに、接続１を使用して、接続２または３と同じデータをフェッチしようとする場合がある。これは役に立ち得るが、ＲＡは、どの接続がより多くの助けを必要とするか、その接続が２それとも３であるか決定を行わなければならない。ＲＡが誤った予測を行った場合、ＲＡは、複製データを不必要にダウンロードしている場合があり、フラグメントは依然として、時間内に届くことができない。
[0299]より優れた要求アクセラレータは、代わりに接続１を使用して、何らかの修復データをフェッチすることができる。修復（ＦＥＣコード化された）データは、ダウンロードに成功した場合、要求２または３からのデータが欠けているかどうかにかかわらず、欠けているデータを再構築するのに使用することができる。唯一の制約は、受信されるデータの量は、フラグメントを再構築するのに十分なことである。言い換えると、我々の例では、修復バイトの数に、受信されたフラグメントバイトの数を加えると、４０００以上になるはずである。
[0300]ある実装形態では、コンテンツプロバイダは、コード化ビデオセグメント用のＦＥＣ修復データへのアクセスを与える。プロバイダは、修復データを、元のビデオデータと同様にして、利用可能にすることができる。たとえば、各メディアセグメントファイルについて、修復情報を含む追加ＦＥＣファイルを与えることができる。コンテンツプロバイダは、メディアプレゼンテーション記述においてＦＥＣを使用するための、必要な情報とパラメータとを与えることができる。別の実装形態では、メディアプレゼンテーション記述は、ＦＥＣについてのいかなる情報も含まないが、クライアントは、セグメントＵＲＬからＦＥＣ修復ＵＲＬの名称をどのようにして導出するかについてのルールなど、一般的な協定を使用して、その情報にアクセスすることができる。
[0301]クライアント実装形態は、修復データをいつどのようにして要求するかに関するプロセスを実装することができる。要求される修復データの量は、どれだけ多くのデータが未処理であるかに依存し得る。さらに、どれだけすぐにフラグメントが利用可能になる必要があるかに依存し得る。たとえば、十分すぎる時間が残されている場合、ソースデータすべてを時間内に受信することを望むので、どの修復を要求することも、おそらく余分である。一方、フラグメントが緊急になりつつある場合、クライアントが、そのフラグメントについての十分なデータを時間内に受け取るのに失敗した場合は失速が切迫しているので、たくさんの修復データを要求したいと思うかもしれない。したがって、ある実装形態は、要求される修復データの量をβ（Ｂ）Ｓとなるように設定することができ、ここでＳは未処理ソースデータの量であり、β（Ｂ）はバッファレベルの減少関数である。
[0302]別の実装形態は、未処理データの量を、未処理の総量ではなく、最も不完全な要求中の未処理データの量に比例させ得る。
６．２．１ 修復セグメントジェネレータの実施形態
[0303]ＤＡＳＨ規格がどのようにＦＥＣを使用するか、特に、ＦＥＣ用のＲａｐｔｏｒＱを使用するかに関する、以下の算出はすべて、好ましくは、固定小数点／整数演算を使用して実施される。この算出は、リプレゼンテーションのフラグメント内のソースシンボルの数および位置を算出することを含み、修復セグメント内のフラグメント用の修復シンボルの数および位置を算出することは、固定小数点演算を使用して行われるべきである。というのは、受信ＦＥＣ修復フラグメントとソースフラグメントの組合せを使用してソースフラグメントを復号するＲＡプロセスとまったく同じ結果が、ソースセグメントからＦＥＣ修復フラグメントを生じる取込み（ingestion）プロセスによって達成される必要があり、したがってこれらの算出はまさに同じ出力結果をもたなければならないからである。固定小数点演算ではなく浮動小数点算出を使用すると、異なるプラットフォーム上の異なる浮動小数点実装形態の異なるコーナーケース挙動により、追跡するのが難しく、両方のエンドポイントがまさに同じ算出結果を生じなければならない規格において許容可能でない、わずかなバグのある挙動が時として生じ得る。
[0304]修復セグメント内のフラグメントについての修復シンボルの数と位置とを算出することを伴わない、後で説明する他のすべての算出は、取込みと、正確に同じ結果を算出するためのＲＡプロセスとの間に依存がないので、所望される場合、（固定小数点でも問題はないが）浮動小数点を用いて行うことができる。
[0305]修復セグメントは、ｓｉｄｘテーブルを含む、すでに処理されたソースセグメントに基づいて、別個のプロセスにおいて生成することができる。ソースセグメント自体に加え、プロセスへの２つの入力は、修復比（repair fragment）ＲおよびシンボルサイズＳである。セグメント内の修復フラグメントの修復シンボルの数および位置の算出に固定小数点演算を使用することを円滑にするために、Ｒの値は、パーミルで表されることができ、すなわち、Ｒ＝５００は、比が１／２であることを意味する。
[0306]各セグメント内で、ソースセグメントの始めにおいて、時間／バイトオフセットセグメントマップを備えるセグメントインデクシング情報も存在する。時間／バイトオフセットセグメントマップは、時間／バイトオフセットペア（Ｔ（０），Ｂ（０））、（Ｔ（１），Ｂ（１））、．．．、（Ｔ（ｉ），Ｂ（ｉ））、．．．、（Ｔ（ｎ），Ｂ（ｎ））のリストであり、ここでＴ（ｉ−１）は、すべてのメディアセグメントの中のメディアの初期開始時間に対する、メディアの第ｉのフラグメントのプレイバック用のセグメント内の開始時間を表し、Ｔ（ｉ）は、第ｉのフラグメントについての終了時間（およびしたがって、次のフラグメントについての開始時間）を表し、バイトオフセットＢ（ｉ−１）は、メディアの第ｉのフラグメントがソースセグメントの最初のものに相対して始まる、このソースセグメント内のデータの最初のものの対応するバイトインデックスであり、Ｂ（ｉ）は、第ｉのフラグメントまでの、およびそのフラグメントを含むセグメント中の対応するバイト数である（したがって、Ｂ（ｉ）は、フラグメントｉ＋１の第１のバイトのインデックスである）。セグメントが複数のメディア成分を含む場合、Ｔ（ｉ）およびＢ（ｉ）は、絶対的な方法でセグメント中の各成分に対して与えられることができ、または、基準メディア成分をサービスする別のメディア成分に対して表されることができる。いずれの場合にも、Ｂ（０）は、セグメント中の第１のフラグメントの開始バイトインデックスであり、このインデックスは、セグメント中の第１のフラグメントに先行するｓｉｄｘ情報により、ゼロよりも大きいことがある。Ｂ（０）がゼロでない場合、修復セグメントの最初には、ｓｉｄｘに対応するいくつかの修復シンボルがある。実装形態によっては、これらの第１の修復シンボルは、第１のフラグメントの最初まで、セグメント中のデータを保護することもでき、使用されない、ゼロをパディングしたデータバイトであってもよい。
[0307]修復比Ｒは、修復セグメントメタデータとともにＭＰＤに入れてシグナリングされても、他の手段（ＴＢＤ）によって取得されてもよい。Ｒについての値の例として、Ｒ＝５００の場合、修復セグメントサイズは、それが生成される元のソースセグメントの対応するサイズの０．５倍として、（非常に厳密に）概算され、ソースセグメント内の、ソースフラグメントに対応する、修復セグメントの修復フラグメントのサイズのサイズも、ソースセグメントのサイズの０．５倍として（非常に粗く）概算される。たとえば、ソースセグメントが１，０００キロのデータバイトを含む場合、対応する修復セグメントは、ほぼ５００キロバイトの修復データを含む。
[0308]Ｓの値は、修復セグメントメタデータとともにＭＰＤにおいてシグナリングされる、または他の手段によって取得されることができる。たとえば、Ｓ＝６４は、ソースデータおよび修復データが、ＦＥＣ符号化および復号の目的のために、各々が６４バイトのサイズのシンボルを備えることを示す。Ｓの値は、関連付けられたソースセグメントのリプレゼンテーションのストリーミングレートに比例するように選ぶことができる。たとえば、ストリーミングレートが１００Ｋｂｐｓの場合、Ｓ＝１２バイトが適切であり得、ストリーミングレートが１Ｍｂｐｓの場合、Ｓ＝１２０バイトが適切であり得、ストリーミングレートが１０Ｍｂｐｓの場合、Ｓ＝１，２００バイトが適切であり得る。１つの目標は、どの程度の粒度のフラグメントがシンボルに区分されるかと、ストリーミングレートと比較したＦＥＣ復号についての処理要件と、の間の良好なトレードオフを有することであり得る。たとえば、１Ｍｂｐｓのストリーミングレート、および約５００ｍｓのサイズのフラグメントにおいて、各フラグメントは約６４ＫＢのデータであり、Ｓ＝１２０の場合、フラグメントは、ほぼ５００個のソースシンボルからなり、このことは、各シンボルが、ソースブロックを回復するのに必要とされるデータの約０．２％であることを意味し、このことは、シンボル粒度により必要とされる余剰受信が、フラグメントが受信されている最中のＨＴＴＰ接続の数に０．２％を乗じたものを上限とすることを意味する。たとえば、ＨＴＴＰ接続の数が６の場合、シンボル粒度受信オーバーヘッドは、１．２％を限度とする。
[0309]修復セグメントは、ソースセグメントについて次のように生成することができる。ソースセグメントの各フラグメントは、ＦＥＣ符号化目的のためのソースブロックと見なされ、したがって各フラグメントは、修復シンボルがそこから生成されるソースブロックの一連のソースシンボルとして扱われる。第１のｉ個のフラグメント用に生成された修復シンボルの総数は、ＴＮＲＳ（ｉ）＝ｄｉｖｃｅｉｌ（Ｒ＊Ｂ（ｉ），Ｓ＊１０００）として算出され、ここでｄｉｖｃｅｉｌ（Ｉ，Ｊ）は、少なくともＩをＪで除算したものである値、すなわち、ｄｉｖｃｅｉｌ（Ｉ，Ｊ）＝（Ｉ＋Ｊ−１）ｄｉｖ Ｊをもつ、最も小さい整数を出力する関数であり、ここでｄｉｖは、結果が、最も近い整数に切り捨てられる固定小数点除算である。したがって、フラグメントｉについて生成される修復シンボルの数は、ＮＲＳ（ｉ）＝ＴＮＲＳ（ｉ）−ＴＮＲＳ（ｉ−１）である。
[0310]修復セグメントは、フラグメントについての修復シンボルの連結を備え、修復セグメント内の修復シンボルの順序は、フラグメントが生成される順序であり、フラグメント内で、修復シンボルは、それらの符号化シンボル識別子（「ＥＳＩ」）の順序である。
[0311]上述したように、フラグメント用の修復シンボルの数を定義することによって、すべての前のフラグメント用の修復シンボルの総数、ならびにしたがって修復フラグメントｉのシンボルについてのバイトインデックスおよびバイト範囲は、Ｒ、Ｓ、Ｂ（ｉ−１）およびＢ（ｉ）にのみ依存し、ソースセグメント内のフラグメントの前または後続構造のいずれにも依存しないことに留意されたい。これは、クライアントに、修復セグメント内の修復ブロックの開始の位置を素早く計算させ、修復ブロックがそこから生成されるソースセグメントの対応するフラグメントの構造についてのローカル情報のみを使用して、その修復ブロック内の修復シンボルの数も素早く計算させるので、有利である。したがって、クライアントは、ソースセグメントの中央からのフラグメントのダウンロードとプレイバックとを始めることを決定した場合、対応する修復セグメント内にあるフラグメントに対応する、対応する修復ブロックを素早く生成し、アクセスすることもできる。
[0312]フラグメントｉに対応するソースブロック内のソースシンボルの数は、ＮＳＳ（ｉ）＝ｄｉｖｃｅｉｌ（Ｂ（ｉ）−Ｂ（ｉ−１），Ｓ）として算出される。最後のソースシンボルは、Ｂ（ｉ）−Ｂ（ｉ−１）がＳの倍数でない場合、ＦＥＣ符号化および復号の目的のために、ゼロバイトでパッドアウトされ、すなわち、最後のソースシンボルは、ＦＥＣ符号化および復号の目的のためにサイズがＳバイトになるように、ゼロバイトでパッドアウトされるが、これらのゼロパディングバイトは、ソースセグメントの一部として記憶されない。本実施形態では、ソースシンボルについてのＥＳＩは、０，１，．．．，ＮＳＳ（ｉ）−１であり、修復シンボルについてのＥＳＩは、ＮＳＳ（ｉ），…，ＮＳＳ（ｉ）＋ＮＲＳ（ｉ）−１である。
[0313]本実施形態における修復セグメントについてのＵＲＬは、たとえば添字「．ｒｅｐａｉｒ」をソースセグメントのＵＲＬに単に追加することによって、対応するソースセグメントについてのＵＲＬから生成することができる。
[0314]修復セグメントは、たとえば、末尾に付加される、対応するソースセグメントの一部でもあり得る。組み合わされたセグメントの構造は、ソースフラグメントおよび修復フラグメントが、組み合わされたセグメント内で連続し、すなわち、組み合わされたセグメントが、第１のソースフラグメント、それに続く第１の修復フラグメント、それに続く第２のソースフラグメント、それに続く第２の修復フラグメントなどを備えるようなものでもあり得る。当業者には認識されるように、上述した方法およびプロセスは、そのような組み合わされたセグメントに適用するために、容易に採用することができる。
６．２．２ 修復セグメントを使用する要求アクセラレータの実施形態
[0315]修復セグメントについての修復インデクシング情報およびＦＥＣ情報は、対応するソースセグメントについてのインデクシング情報によって、ＲおよびＳの値から暗黙的に定義され、ここでＲは、パーミルを示す０と１０００との間の整数として表され、Ｓは、バイトで表される。時間オフセットおよび修復セグメントを備えるフラグメント構造は、対応するソースセグメントの時間オフセットおよび構造によって決定される。フラグメントｉに対応する修復セグメント中の修復シンボルの冒頭および末尾へのバイトオフセットは、それぞれ、ＲＢ（ｉ−１）＝Ｓ＊ｄｉｖｃｅｉｌ（Ｒ＊Ｂ（ｉ−１），Ｓ＊１０００）およびＲＢ（ｉ）＝Ｓ＊ｄｉｖｃｅｉｌ（Ｒ＊Ｂ（ｉ），Ｓ＊１０００）として算出され得る。フラグメントｉに対応する修復セグメント中のバイト数はすると、ＲＢ（ｉ）−ＲＢ（ｉ−１）であり、したがってフラグメントｉに対応する修復シンボルの数は、ＮＲＳ（ｉ）＝（ＲＢ（ｉ）−ＲＢ（ｉ−１））／Ｓとして算出される。（分子がＳの倍数であることが保証されるので、ここではｄｉｖｃｅｉｌ演算は必要ないが、ｄｉｖｃｅｉｌはここで使用することができ、結果は依然として正しくなることに留意されたい）。フラグメントｉに対応するソースシンボルの数は、ＮＳＳ（ｉ）＝ｄｉｖｃｅｉｌ（Ｂ（ｉ）−Ｂ（ｉ−１），Ｓ）として算出することができ、ここで最後のソースシンボルは、必要な場合、符号化について記述したのと同じく、復号目的のためにゼロでパディングされる。したがって、修復セグメント内の修復ブロックについての修復インデクシング情報、および対応するＦＥＣ情報は、対応するソースセグメントの対応するフラグメントについてのＲ、Ｓおよびインデクシング情報から暗黙的に導出することができる。
[0316]一例として、バイトオフセットＢ（１）＝６，４１０で始まり、バイトオフセットＢ（２）＝６，７７０で終わるフラグメント２を示す、図３５に示す例を検討し、すなわち、フラグメント２はサイズが６，７７０〜６，４１０バイトであり、６，７７０は、フラグメント３の開始バイトインデックスである。この例では、シンボルサイズはＳ＝６４バイトであり、垂直点線は、Ｓの倍数に対応する、ソースセグメント内のバイトオフセットを示す。ソースセグメントサイズの割合としての全体的な修復セグメントサイズは、この例ではＲ＝５００パーミルに設定される（修復は、ソースのほぼ１／２である）。フラグメント２用のソースブロック中のソースシンボルの数は、ＮＳＳ（２）＝ｄｉｖｃｅｉｌ（６，７７０−６，４１０， ６４）＝（６，７７０−６，４１０＋６４−１）ｄｉｖ６４＝６として算出され、これらの６つのソースシンボルは、それぞれＥＳＩ０、．．．、５を有し、ここで第１のソースシンボルは、ソースセグメント内のバイトインデックス６，４１０で始まるフラグメント２の最初の６４バイトであり、第２のソースシンボルは、ソースセグメント内のバイトインデックス６，４７４で始まるフラグメント２の次の６４バイトであり、以下同様である。フラグメント２に対応する修復ブロックの終了バイトオフセットは、ＲＢ（２）＝６４＊ｄｉｖｃｅｉｌ（５００＊６，７７０， ６４＊１，０００）＝６４＊（３，３８５，０００＋６４，０００−１）ｄｉｖ６４，０００＝６４＊５３＝３，３９２として算出され、フラグメント２に対応する修復ブロックの開始バイトオフセットは、ＲＢ（１）＝６４＊ｄｉｖｃｅｉｌ（５００＊６，４１０， ６４＊１，０００）＝６４＊（３，２０５，０００＋６４，０００−１）ｄｉｖ６４，０００＝６４＊５１＝３，２６４として算出され、したがってこの例では、それぞれ、修復セグメント内のバイトオフセット３，２６４で始まり、バイトオフセット３，３９２で終わる、ＥＳＩ６および７をもつフラグメント２に対応する修復ブロック中に２つの修復シンボルがある。
[0317]このことは、図３５に示されている。図３５に示すこの例において、Ｒ＝５００である（修復は、ソースのほぼ１／２である）とともに、フラグメント２に対応する６つのソースシンボルがあるとしても、修復シンボルの数を算出するのにソースシンボルの数を単に使用している場合に期待し得るように、修復シンボルの数は３ではなく、２となるように算定されることに留意されたい。修復シンボルの数を決定するのに、フラグメントのソースシンボルの数を単に使用するのとは反対に、ここで行われるやり方は、対応するソースセグメントの対応するソースブロックに関連付けられたインデックス情報のみから、修復セグメント内の修復ブロックの位置決めを算出することを可能にする。これを、取込みプロセスにおける、およびＲＡプロセス内での無矛盾の算出にするために、修復セグメント内の修復フラグメントについての修復シンボルの数および位置の算出が、固定小数点演算を使用して算出されることが重要である。さらに、ソースブロック中のソースシンボルの数、すなわちＫが増大すると、対応する修復ブロックの修復シンボルの数、すなわちＫＲは、概して、ＫＲは多くともｄｉｖｃｅｉｌ（Ｋ＊Ｒ， １，０００）であり、ＫＲは、少なくともｄｉｖｆｌｏｏｒ（（Ｋ−１）＊Ｒ，１０００）であるので、Ｋ＊Ｒ／１，０００によって厳密に概算され、ここでｄｉｖｆｌｏｏｒ（Ｉ，Ｊ）＝Ｉ ｄｉｖ Ｊである。
７． 例示した実施例
[0318]図２５は、レート選択プロセスを示す。λおよびμについての設定が高い程、設定はアグレッシブになる。図２３は、パラメータλについての様々な値を示す。図２４は、パラメータμについての様々な値を示す。ハイブリッド設定が、２つのメインメカニズムによって、レートゆらぎを削減しようとする。第１のメカニズムは、Ｂが比較的大きいとき、レートを増大させることにより慎重であることによるものであり、第２のメカニズムは、Ｂが比較的小さいとき、より懸命に、現在のレートに留まろうとするものである。
[0319]ｐｋｅｒ ｘ．ｙ：Ｃ＝ｘ＊ｍｉｎ（ｙ＊Ｔｄｌ，Ｂ）についての例示的設定は、８．１、４．２、２．４、４．４または他のｘ．ｙ値に設定されたｘ．ｙであり得る。ｐｋｅｒの実際の平均化ウィンドウは、ダウンロード中断期間のスキップにより、Ｃよりも長いことに留意されたい。ＥＷＭＡのスキップはなく、ダウンロード中断期間中のレートは、最後のダウンロード間隔のものと同じであると仮定する。
[0320]ＭＷＡ（移動ウィンドウ平均）に対して、Ｈ（ｚ）＝（１／Ｄ）＊（（１−ｚ-D）／（１−ｚ-1））であり、ここでＤはウィンドウサイズである。Ｘi＝ｍｉｎ｛Ｒk：ｋ≧ｉ｝であり、ここでＲkは、重みＷkをもつレートのＥＷＭＡであり、Ｗ1＜Ｗ2＜Ｗ3＜…である。ＥＷＭＡについて、Ｈ（ｚ）＝（（１−β）／（１−βｚ-1））であり、ここでβは前の平均の重みである。ＭＷＡおよびＥＷＭＡは、いくつかのケースではおおよそ均等である。
[0321]適合型エスティメータは、より長い平均化ウィンドウを有する場合、ライブストリーミング用にほぼ同じ平均レートを維持したまま、レート切替え頻度を削減する。異なる設定が、異なるシナリオについてうまく機能する。アグレッシブ設定は、より安定したシナリオに対してうまく機能し、あまりアグレッシブでない設定は、より変動しやすいシナリオにより適している。帯域幅が、かなりの時間部分（たとえば、２０秒間の平均がレートキャップよりも高い時間の％）に対して、特定のマージンだけ、最も高いリプレゼンテーションレートよりも高い場合、よりアグレッシブ設定で進めることが有益である。理想的には、デバイスは、シナリオタイプを検出し、適切な設定を適用することができるべきである。シナリオ検出は、無線技術タイプ、特定の単位時間内のレート変化の回数、移動速度などのような要因に基づき得る。より単純な戦略は、上記観察に基づき、すなわち、「全体的」帯域幅がレートキャップよりも高いとき、よりアグレッシブ設定を使用することができる。
８． レート選択パラメータの設定
[0322]このセクションでは、レート選択パラメータを設定する例が挙げられる。
[0323]ＭＬＢについて、ＥＦＦ＝１−Ｒｖ／Ｒｄｌであり、ここでＲｖは、選択されたリプレゼンテーションの現在のレートであり、Ｒｄｌは現在のダウンロードレートである。提案されるルールは、次の通りである。
[0324] ＥＦＦ＜０の場合、おそらく２つ以上のレートだけ下がる
[0325] ０≦ＥＦＦ＜０．１の場合、１レート下がる
[0326] ０．１≦ＥＦＦ＜０．６の場合、現在のレートに留まる
[0327] ０．６≦ＥＦＦ＜０．８の場合、１レート上がる
[0328] ０．８≦ＥＦＦ≦１の場合、おそらく２つ以上のレートだけ上がる
[0329] アルファ＝Ｒｖ／Ｒｄｌとする。するとこれは、おおよそ次のようになる。
[0330] アルファ≦０．４の場合、少なくとも１つのレートだけ上がる
[0331] ０．４＜アルファ≦０．９の場合、同じレートに留まる
[0332] ０．９＜アルファの場合、少なくとも１レートだけ下がる
[0333] これを、ＤＡＳＨクライアントレート選択プロセスのコンテキストに当てはめる。
[0334]ＲＵＰを、ＵＰに対応するリプレゼンテーションのレートとし、ＲＤＯＷＮを、ＤＯＷＮに対応するリプレゼンテーションのレートとし、上記のように、Ｒｖを、現在選ばれているリプレゼンテーションのレートとする。ＲＵＰは、ＲＵＰ≦ラムダ（ｔ）＊Ｒｄｌとなるように可能な限り大きくなるように選ばれ、そのＲＤＯＷＮが、ＲＤＯＷＮ≦ミュー（ｔ）＊Ｒｄｌとなるように可能な限り大きくなるように選ばれる。パラメータｔ＝Ｂ／（Ｄ＋デルタ）であり、ここでＢは、メディアバッファにおける現在のプレゼンテーション時間量であり、Ｄは、現在の決定が行われている時点を超える、次の可能切替え点までの時間に対する限度であり、デルタは、ネットワーク待ち時間とラウンドトリップ時間とを考慮に入れる小さいパラメータであり、たとえば、デルタは、近似として１秒または２秒に設定されてもよく、デルタは、現在のＲＴＴに対する測定された上限に従って設定されてもよい。
[0335]次のレートＲＮＥＸＴの全体的選択は、次のようになる。
[0336]ＲＵＰ＜Ｒｖの場合、ＲＮＥＸＴ＝ｍｉｎ｛Ｒｖ，ＲＤＯＷＮ｝であり、そうでない場合、ＲＮＥＸＴ＝ＲＵＰである。
[0337]上記ＭＬＢパラメータは、すべてのｔについてラムダ（ｔ）＝０．４＊Ｒおよびミュー（ｔ）＝０．９と設定することによって概算することができ、ここでＲは、次に高いリプレゼンテーションのレートと、現在のリプレゼンテーションのレートのものとの比である。たとえば、現在のレートが５００Ｋｂｐｓであり、次に高いレートが７５０Ｋｂｐｓである場合、Ｒ＝１．５となり、したがってラムダ（ｔ）＝０．６となる。これは、ＭＬＢプロセスを次のように近似する。
[0338]決定点において、ＥＦＦ≧０．６、すなわち、アルファ≦０．４の場合、Ｒｖ≦０．４＊Ｒｄｌであり、この場合、（すべてのｔについてラムダ（ｔ）＝０．４＊Ｒであるので）ＲＵＰは少なくともＲｖ＊Ｒとなり、したがってＲＮＥＸＴ＝ＲＵＰとなり、すなわち、レートはレートＲｖ＊Ｒにおいて次に高いリプレゼンテーションまで上がってよく、Ｒｄｌが０．４＊Ｒｖよりもはるかに大きい場合、ＲＵＰは、（リプレゼンテーションレートの粒度に依存して）Ｒｖ＊Ｒよりも大きくなり、ＲＵＰは、ＥＦＦがたとえば０．８よりも大きい場合、Ｒｖ＊Ｒを１レート分超えることになる。ＥＦＦ＜０．１の場合、Ｒｖ＞０．９＊Ｒｄｌであり、この場合、ＲＤＯＷＮは、Ｒｖ未満になり（ＲＤＯＷＮ≦０．９＊Ｒｄｌなので）、レートは下がり、すなわち、ＲＮＥＸＴ＜Ｒｖになる。ＥＦＦが０．１と０．６との間の場合、ＲＵＰ≦Ｒｖ＊ＲおよびＲＤＯＷＮ≧Ｒｖになり、この場合、ＲＮＥＸＴは、Ｒｖと等しくなるように選ばれる。
９． レート選択パラメータセット
[0339]以下のテーブルは、いくつかの可能なレート選択パラメータセットを指定する。以下のテーブルに示されていないｔの中間値についてのラムダおよびミューの値は、周辺値の間を線形補間することによって算出されるべきである。以下のテーブルに示すものを超えるｔの値についてのラムダおよびミューの値は、示されているｔの最大値についてのラムダおよびミュー値に設定されるべきである。
[0340]ミュー（ｔ）≦ｔおよびラムダ（ｔ）≦ｔという制約がすべてのｔについて満たされる場合、理論的には、プレイバックにおける失速はないが、現実的な点からは、まったく失速しないがはるかに削減されたレートでプレイアウトし続けるよりもむしろ、プレイバックにおいて小さい失速を有することが好ましい場合があり、たとえば、１Ｍｂｐｓから２０Ｋｂｐｓに急変するのは、その間に１秒間の休止があって１Ｍｂｐｓから２５０Ｋｂｐｓに急変するよりも悪い経験であり得る。ラムダおよびミューの最小値は、図３６のテーブルにおいて設定され、ミュー（ｔ）＞ｔおよび／またはラムダ（ｔ）＞ｔの値について、失速が起こる見込みが高いことを注記しておく（ただし、失速は、ラムダ（ｔ）およびミュー（ｔ）の設定によらず、バッファが空であるときは、いずれの場合にも起こり得る）。
[0341]ここまで説明してきたように、クライアントデバイスは、ＨＴＴＰを介した適合型ビデオストリーミングのためのレート適合プロセスとダウンロードプロセスとを提供することができる。インターネット（および他のネットワーク）を介してビデオをストリーミングするクライアントは、変動帯域幅の問題に直面する。高品質ビデオがストリーミングされる場合、リンクが十分に高速でないときがあり、プレーヤに割り込ませ、再バッファリングさせる。他のケースでは、低品質ビデオは、はるかに少ない帯域幅を使用するが、より劣ったユーザエクスペリエンスとなる。１つの解決策は、ビデオ品質を適応的に調整することであり、すなわち、スループットが高いときは、より良好な品質を選び、自動的に下方切替えすることである。
[0342]ただし、適応ビデオストリーミングは、いくつかの課題を提起する。すなわち、（１）ビデオレート（品質）を選ぶためのプロセスまたはアルゴリズムは、レート下落ならびにレート増大に適応するように、十分に素早く作用するべきである。同時に、早まった、または一貫性のない決定を避け、不必要なレート切替え決定を避けるべきである。クライアントは、高ビデオ品質が達成され得るように、十分に高いレートでデータをフェッチすることを目指すべきである。同時に、ダウンロードプロセスは、データが適時に受信されることを確実にすべきである。各フレームは、プレイアウトされる前に全体が受信されるべきである。これらの目標を、不必要に大きいプレイバックバッファを必要とせずに達成することができるべきである。大きいバッファのいくつかの問題は、ライブイベントの場合、バッファ中のビデオの量が、目標エンドツーエンド遅延によって制限され、これらのケースにおける可能プレイバックバッファを厳しく制限することである。また、大きいバッファへの依存は、バッファが、事前充満される必要があるので、プレイバック開始またはシーク時に望ましくない遅延を引き起こし得る。また、大きいプレイバックバッファは、たくさんのメモリを使い、モバイル電話および他のクライアントデバイスではメモリが乏しい場合がある。
[0343]これらの問題を解決するために、受信レート変化に素早く反応するレート推定のためのプロセス。レート推定は、ビデオをストリーミングする際の使用のために特別に調整された、適応ウィンドウ化平均（adaptive windowed average）であることができる。レートエスティメータは、ウィンドウイング幅（およびしたがって測定値分散）を大きく保ちながら、必要な場合にレートが十分高速に調整することを保証するような形で、ビデオバッファレベルと、ビデオバッファレベルの変化とを考慮に入れる。プロセスによって与えられる保証は、（ａ）Ｂが、レート下落が起きたときのバッファ中のビデオデータの量（プレイバック時間の秒数）である場合、エスティメータが、バッファがＢ／２までドレインするのにかかる時間内にそのレート推定値を調整してしまうこと、および（ｂ）Ｂが、レート増大が起こっている間のバッファ中のデータの量である場合、レートエスティメータが、原則として多くとも３＊Ｂの時間内に見られ得るように、新規レートに十分に迅速に調整する（スマートなレート変更プロセスを仮定する）ことである。
[0344]レート決定プロセスは、（ａ）バッファが低レベルにあるときにバッファが満たされ、（ｂ）小さいダウンロードレート推定値が観測される場合であっても、不規則に変化するレートを回避するためにバッファを使用し、（ｃ）安定レートシナリオでは、正しい安定レートを素早く選ぶように、レート決定を行うことができる。（ａ）正確なレート推定を可能にし、（ｂ）ネットワーク遅延およびパケット損失レートが高い場合であってもリンク容量を達成することが可能であり、（ｃ）ストリームの適時配信を達成する、ＨＴＴＰのためのマルチメディアダウンロード戦略が使用される。これを達成するために、マルチプルなＨＴＴＰ接続を使用し、ネットワーク条件に依存して、メディア要求をより小さいチャンク要求に分解し、ＴＣＰフロー制御メカニズムを使用して接続を同期させ、データをバースト的に要求することができる。また、接続をビジーに保つために、ＨＴＴＰパイプライニングプロセスを使用することもできる。
[0345]いくつかの特徴、態様および詳細について、今まで説明してきた。説明したように、様々な実施形態において、方法ステップは、対応するプログラムされた要素、プロセッサに与えられる命令、ハードウェアまたは当業者には明らかであろう他の装置によって実施することができる。同様に、要素は、プロセスまたはプログラム要素によって有効にすることができる。実施形態の要素の構造は、プロセッサによって実行されるが、本明細書では対応する方法ステップとして記述される命令セットを単に備え得る。
[0346]様々な実施形態において、ダウンロードレート加速は、使われても使われなくてもよい。ダウンロードレート加速の例は、ＴＣＰ接続を介したＨＴＴＰ要求を使用することによってダウンロードを加速する方法または装置である。ＴＣＰ接続は、特定のウィンドウサイズを有し、ＴＣＰ接続の端部にあるノードは、ウィンドウサイズについての設定を変えることができる。１つの新規性は、連続するＨＴＴＰ要求用にウィンドウサイズを設定することであり、ここでサイズは、目標ダウンロードレートの関数である。したがって、目標ダウンロードレートが変わると、ＴＣＰウィンドウサイズが変わり得る。
[0347]一実施形態では、ネットワーク経路によって結合されたソースと受信機との間のネットワーク経路を介したデータダウンロードを制御するための方法および／または装置もしくはコンピュータ可読媒体が使われ、この方法は、ソースと受信機との間の複数のＴＣＰ接続の各々について、そのＴＣＰ接続用のＴＣＰ受信機ウィンドウサイズを決定することであって、ソースと受信機との間のＴＣＰ接続が直接接続または間接接続であることができる、決定することと、メディアコンテンツ用の目標ダウンロードレートを決定することであって、目標ダウンロードレートが、少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、決定することと、複数のＴＣＰ接続の各ＴＣＰ接続を使用して、ダウンロードされるべきメディアコンテンツの複数のメディアデータ要素をダウンロードすることとを備え、メディアコンテンツが、複数のＨＴＴＰ要求への応答の一部分または全部であり、所与のＴＣＰ接続用の決定されたＴＣＰ受信機ウィンドウサイズは、目標ダウンロードレートに少なくとも部分的に基づいて決定され、決定されたＴＣＰ受信機ウィンドウサイズは、少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる。
[0348]現在のＴＣＰ接続のための決定されたＴＣＰ受信機ウィンドウサイズは、乗数レートで乗算された、現在のＴＣＰ接続についての現在の推定ラウンドトリップ時間（「ＥＲＴＴ」）の積に少なくとも部分的に基づいて決定されることができ、乗数レートは、現在のＴＣＰ接続用の目標ダウンロードレートと、目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である。現在のＥＲＴＴは、たとえば１秒、１０秒、５０秒など、直前の測定期間にわたる最小の観測されたＲＴＴの測度によって決定されることができる。現在のＥＲＴＴは、休止期間の終了における測度によって決定されることができ、休止期間は、ダウンロード期間に続く、ＴＣＰ接続にわたるアクティブＨＴＴＰ要求が所定の継続時間期間だけ存在していない期間である。目標ダウンロードレートは、使用されるすべてのＴＣＰ接続にわたる現在の総ダウンロードレートを、使用されるＴＣＰ接続の数で除算したものに比例し、たとえば現在の総ダウンロードレートの２倍または３倍になり得る。目標ダウンロードレートは、メディアコンテンツのプレイバックレートに比例し得、プレイバックレートは、使用されるすべてのＴＣＰ接続に及ぶ総計にわたるレートを、使用されるＴＣＰ接続の数で除算したものである。各メディアデータ要素は、所定の分散範囲内のサイズを有するいくつかのチャンクに分割され、そのようなチャンクの数は、使用されるＴＣＰ接続の数に基づく。そのようなチャンクの数は、現在のＴＣＰ接続についての現在の推定ラウンドトリップ時間（「ＥＲＴＴ」）、現在のダウンロードレート、および／または要求されるメディアフラグメントのサイズのうち少なくとも１つにさらに基づき得る。所定の分散範囲はゼロであってよく、したがって各チャンクは、フラグメント要求ごとに同じサイズを有し、チャンクの数は、使用されるＴＣＰ接続の数に、所定の因子を乗じたものに等しい。各チャンクは、最小バイト数以上のサイズを有し得る。後続メディアデータ要素についての後のＨＴＴＰ要求が、第１の利用可能ＴＣＰ接続に割り当てられ得る。
[0349]制御することはまた、ソースと受信機との間で使用するべきいくつかのＴＣＰ接続を決定することであって、その数が１よりも大きく、使用するべきＴＣＰ接続の数が、少なくとも部分的に、決定された少なくとも１つのネットワーク条件に基づいて決定される、決定することと、いくつかのＴＣＰ接続の各々を使用して、ダウンロードされるべきメディアコンテンツの複数のメディアデータ要素をダウンロードすることとを含み、メディアコンテンツは、複数のＨＴＴＰ要求への応答の一部分または全部である。使用されるＴＣＰ接続の数は、ＴＣＰ接続についての推定ラウンドトリップ時間（「ＥＲＴＴ」）、目標ダウンロードレート、および損失レートの推定値に基づき得る。損失レートは、１％または０．１％であると推定され得る。使用するべきＴＣＰ接続の数は、両端値を含む２と１６の間であり、および／または（ａ）目標ダウンロードレート、（ｂ）ＥＲＴＴ、および（ｃ）推定損失レートの平方根の積に比例し得る。ＴＣＰ接続の各々について、ＴＣＰ受信機ウィンドウサイズは、そのＴＣＰ接続用に、目標ダウンロードレートに基づいて決定することができ、決定されたＴＣＰ受信機ウィンドウサイズは、少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる。
[0350]一実施形態では、プレゼンテーションバッファに注目し、バッファがどの程度大きいか／満杯であるか／空であるか、すなわち、バッファのレベルがどこにあるかに基づいて、ダウンロードレートの推定を行うダウンロードレートを推定するための方法および／または装置もしくはコンピュータ可読媒体が使用される。たとえば、有限帯域幅を有するネットワーク経路によってデータソースに結合された受信機においてダウンロードレートを推定することであって、ダウンロードレートが、受信機においてネットワーク経路を介してデータが受信され得るレートであることは、受信機のプレゼンテーションバッファを監視することであって、プレゼンテーションバッファが、少なくともメディアデータが受信される時間と、受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間メディアデータを記憶する、監視することと、ダウンロードレートの推定値がそれに基づくべき非ゼロ推定期間を決定することと、推定期間にわたるバッファレベルのインジケーションを記憶することであって、所与の時間におけるバッファレベルが、プレゼンテーションバッファのうちどの程度が、少なくとも近似的に、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによってその時間に占有されるかに対応する、決定することと、記憶されたインジケーションを、推定ダウンロードレートの測度の一部として使用することとを備え得る。
[0351]プレゼンテーション要素は、ディスプレイとオーディオ出力とを備えることができる。推定期間は、所定の比例因子による、測定されたバッファレベルに比例する持続期間を有し得る。推定期間の持続期間は、測定時間におけるプレゼンテーションバッファ中の未消費のメディアデータのバイト数に比例し、および／またはプレゼンテーションバッファにメディアが追加される追加レートの関数であり、および／またはプレゼンテーションバッファの所定の部分をダウンロードするのに使用される時間に比例するようにとられ得る。所定の持続時間は、プレゼンテーションバッファのコンテンツの所定の比率がダウンロードされた持続時間に対応して得る。推定期間は、プレゼンテーションバッファのコンテンツの所定の比率がダウンロードされた時間、およびメディアデータがプレゼンテーションバッファ中に存在するプレゼンテーション時間のうち、より短い方であることができる。
[0352]一実施形態では、プレイバックレート選択のための方法および／または装置もしくはコンピュータ可読媒体が使用され、プレイバックレートは、メガビット／秒などのメモリ単位／時間で測定される、プレゼンテーションバッファからメディアが消費されるレートである。受信機が、いくつかのメディアについての要求を行うとき、そのメディアのためのプレイバックレートがある。おそらく常にではないがしばしば、より高品質のメディアが、より高いプレイバックレートを有し、したがってトレードオフを提示する。どのプレイバックレートを使用／要求するべきかは、少なくとも時には、どれだけ多くのメディアがプレゼンテーションバッファにあるかに応じて決まる。受信機は、受信機のプレゼンテーション要素を使用してプレイアウトするためのメディアを受信することもでき、ここで、プレイアウトの結果、メディアがプレゼンテーションバッファからあるプレイバックレートで消費されることになり、受信機は、複数のプレイバックレートから選択を行うように構成され、プレゼンテーションバッファを監視することであって、プレゼンテーションバッファは、少なくともメディアデータが受信される時間と受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間メディアデータを記憶する、監視することと、バッファレベルのインジケーションを記憶することであって、バッファレベルは、プレゼンテーションバッファのどの程度が、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによって占有されるかに対応する、記憶することと、推定ダウンロードレートを決定することと、目標プレイバックレートを計算するために、記憶されたインジケーションおよび推定ダウンロードレートを使用することと、目標プレイバックレートに従って複数のプレイバックレートの中から選択をすることとを備える。
[0353]選択されたプレイバックレートは、推定ダウンロードレートの所定の乗数以下であることができ、所定の乗数は、バッファレベルの増加関数である。所定の乗数は、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間のアフィン一次関数であることができ、所定の乗数は、プレゼンテーションバッファのバッファレベルがしきい量未満であるときには、１未満であることができる。所定の乗数は、プレゼンテーションバッファ中のメディアデータのプレゼンテーション持続時間が、あらかじめ設定された最大量のプレゼンテーション時間以上であるときには、１以上であることができる。所定の乗数は、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間の区分的一次関数であることができる。選択されたプレイバックレートは、推定ダウンロードレートの所定の乗数、およびプレゼンテーションバッファ中のメディアデータのバイト数の増加関数の所定の乗数以下であり得る。プレイバックレートは、比例因子にダウンロードレート推定値を乗じたもの以下である複数のプレイバックレートのうち最も大きい利用可能プレイバックレートとなるように選択されればよく、比例因子は、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間を、レート変化に対する反応時間の推定値で除算したものの増加関数である。反応時間は、メディアデータ中の切替え点の間のプレゼンテーション時間に対する上限であり得、および／または反応時間の推定値は、メディアデータ中の切替え点の間のプレゼンテーション時間に関する平均であり得る。反応時間の推定値は、所定の定数に推定ラウンドトリップ時間（「ＥＲＴＴ」）を乗じたもの以上であり得る。
[0354]受信機のプレゼンテーション要素を使用してプレイアウトするためのメディアを受信する受信機であって、プレイアウトの結果、メディアがプレゼンテーションバッファからプレイバックレートで消費され、受信機は、複数のプレイバックレートから選択するように構成され、プレゼンテーションバッファを監視することであって、プレゼンテーションバッファは、少なくともメディアデータが受信される時間と、受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間のメディアデータを記憶する、監視することと、バッファレベルのインジケーションを記憶することであって、バッファレベルが、プレゼンテーションバッファのうちどの程度が、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによって占有されるかに対応する、記憶することと、バッファレベルの許容分散を決定することと、記憶されたバッファレベルインジケーションとバッファレベルの許容分散とを使用して、目標プレイバックレートを計算することと、目標プレイバックレートに従って複数のプレイバックレートの中から選択することと、を行うための方法または装置を備え得る。
[0355]プレイバックレートは、上位比例因子（upper proportional factor）、下位比例因子（lower proportional factor）、ダウンロードレート推定値、現在のプレイバックレート、バッファレベル、およびレート変化に対する反応時間の推定値に基づいて選択することができる。上位比例因子および下位比例因子は両方とも、プレゼンテーションバッファ中のメディアデータのプレイバック持続時間を、レート変化に対する反応時間の推定値で除算したものの増加関数および／または区分的一次関数であることができ、上位比例因子は、下位比例因子よりも大きいものまたは下位比例因子に等しいものである。プレイバックレートは、前のプレイバックレートが、下位比例因子に推定ダウンロードレートを乗じたものと、上位比例因子にダウンロードレート推定値を乗じたものとの間にあるときには、前のプレイバックレートと同じになるように選択されることができる。プレイバックレートは、前のプレイバックレートが、上位比例因子にダウンロードレート推定値を乗じたものを上回るときには、上位比例因子に推定ダウンロードレートを乗じたもの以下の最も大きい利用可能プレイバックレートになるように選択されることができる。プレイバックレートは、前のプレイバックレートが、下位比例因子にダウンロードレート推定値を乗じたものを下回るときには、下位比例因子に推定ダウンロードレートを乗じたもの以下の最も大きい利用可能プレイバックレートになるように選択されることができる。
[0356]一実施形態では、要求を行うためであるが、プロセス要求において取り消すかどうか決定するためでもある方法および／または装置もしくはコンピュータ可読媒体が使用される。受信機は、メディアのセグメント／部分／フラグメントについての要求を行い、要求に対する応答を受信し、応答からのメディアを記憶し、可能性として別の要求を行うとき、要求を取り消し、異なる要求を発行すること好ましいと決定してよい。メディアのプレイバックレートは、最もアグレッシブであるとともに、プレゼンテーションバッファ中のメディアを、消費されるときに使い果たすことなく取得することを期待する最も高いプレイバックレートを選択する受信機によって決定することもできる。ダウンロードレートが予期せぬほど下がった場合、受信機は、その現在の要求を取り消し、より低いプレイバックレートメディアについての新規要求を行うか、それとも現在の要求をプレイアウトさせるか決定する。高プレイバックレート要求を取り消し、より低いプレイバックレート要求で置き換えると、プレゼンテーションバッファのコンテンツがより長く続くことになる場合があるが、要求ミッドストリームを取り消すと、その要求についてのどの部分的に受信されたメディアの損失も引き起こす場合がある。
[0357]そのような一実施形態において、受信機は、受信機のプレゼンテーション要素を使用してプレイアウトするためのメディアを受信し、プレイアウトの結果、メディアは、プレゼンテーションバッファから一定のプレイバックレートで消費され、受信機は、複数のプレイバックレートから選択をするように構成される。要求アクションを決定することは、プレゼンテーションバッファを監視することであって、プレゼンテーションバッファが、少なくともメディアデータが受信される時間と、受信機に関連付けられたプレゼンテーション要素によってメディアデータが消費される時間との間、メディアデータを記憶する、監視することと、バッファレベルのインジケーションを記憶することであって、バッファレベルが、プレゼンテーションバッファのうちどの程度が、受信されたがプレゼンテーション要素によってまだ消費されていないメディアデータによって占有されるかに対応する、記憶することと、選択された第１のメディアデータチャンクをダウンロードするために、および発行された要求が未処理のときに、発行された要求の状態を維持することと、ネットワーク条件および発行された要求の状態に基づいて、要求を続けるか、それとも要求を取り消すかを決定することとを備える。
[0358]要求を続けるか、それとも要求を取り消すかを決定することは、第１のメディアデータがプレイアウトされる前に、要求についてのダウンロードを完了するのに十分な時間があるかどうか決定することと、十分な時間がない場合、要求を取り消すこととを備えることができる。要求を続けるか、それとも要求を取り消すかを決定することは、選択された第１のチャンクまたは選択された第２のチャンクのいずれかがプレイアウトされることになる前に、より高レートの第２のチャンクをダウンロードするのに十分な時間があるかどうか決定することと、十分な時間がある場合、要求を取り消し、第２のチャンクについての要求を発行することとをさらに備えることができる。要求を続けるか、それとも要求を取り消すかを決定することは、ダウンロードレートおよびメディア消費レートに基づいて、失速が起こることを検出することと、プレゼンテーション要素が、消費されるメディアによって指示されたレートでメディアデータを消費することができない時間と、プレゼンテーション要素が、消費されるメディアによって指示されたレートでメディアデータの消費を再開することができる時間との間の失速期間を推定することと、継続または取消しが失速期間に対して与える効果を決定することと、要求の取消しが失速期間を短縮することになる場合、要求を取り消すこととをさらに備えることができる。
[0359]他の特徴は、第２のメディアデータチャンクを選択することであって、第２のメディアデータチャンクが、開始プレゼンテーション時間を有し、その開始プレゼンテーション時間が、第１のメディアデータチャンクと同じ開始プレゼンテーション時間である、選択することと、第２のメディアデータチャンクのダウンロードを要求することと、第２のメディアデータチャンクを選択することであって、第２のメディアデータチャンクが、開始プレゼンテーション時間を有し、その開始プレゼンテーション時間が、第１のメディアデータチャンクの開始プレゼンテーション時間よりも後である、選択することと、第２のメディアデータチャンクのダウンロードを要求することとを含んでもよい。第２のメディアデータチャンクは、受信機にとって利用可能な第１のチャンクの開始プレゼンテーション時間のものと比較した、その開始プレゼンテーション時間が、最も低い差となるように、および／またはそのプレイバックが、その開始プレゼンテーション時間と第１のメディアデータチャンクの開始プレゼンテーション時間との間の所定の最大ギャップをもつ最大プレイバックレートとなるように、受信機によって選ぶこともできる。
[0360]いくつかの実施形態は、第１のメディアデータチャンクのうち残っている部分のダウンロードが、プレイバック用の時間内に完了できないかどうか決定することと、第２のメディアデータチャンクのダウンロードが、プレイバック用の時間内に完了され得るかどうか決定することと、要求を続けるか、それとも第１のメディアデータチャンクについての要求を取り消し、代わりに第２のメディアデータチャンクを要求するかの決定を、第１のメディアデータチャンクのうち残っている部分のダウンロードが、プレイバック用の時間内に完了できないかどうか、および第２のメディアデータチャンクのダウンロードが、プレイバック用の時間内に完了され得るかどうかに基づかせることとを含み得る。第２のデータチャンク中のメディアデータのプレイバックレートは、受信機においてサポートされる最も高いプレイバックレートとなるように選ばれることができる。受信機は、すでにプレゼンテーションバッファ中にある少なくともいくらかのメディアデータのプレゼンテーション時間をカバーするメディアデータを要求し、要求されたメディアデータをダウンロードし、要求されたメディアデータをプレイアウトし、すでにプレゼンテーションバッファ中にある対応するメディアデータのうち少なくともいくつかを破棄してもよい。要求されたメディアデータのプレイバックレートは、プレゼンテーションバッファから破棄される対応するメディアデータの最大プレゼンテーション持続時間に対する制約を受ける、最大のプレイバックレートであり得る。要求されるメディアデータは、その開始プレゼンテーション時間が、受信機にとって利用可能な最も早い開始プレゼンテーション時間になるように選ばれ得る。
[0361]いくつかの受信機において、ダウンロードは、バッファレベルに依存し、受信機は、高ウォーターマークおよび低ウォーターマークの概念を使用する。そのような受信機において、メディアデータは、ソースからダウンロードされ、受信機のプレゼンテーションバッファに記憶される。プレゼンテーションバッファの充満レベル（または単に「レベル」）が決定され、ここで充満レベルは、プレゼンテーションバッファのどのような部分が、プレゼンテーション要素によってまだ消費されていないメディアデータを含むかを表す。充満レベルが高充満しきい値（「高ウォーターマーク」）を上回る場合、ダウンロードは停止し、充満レベルが低充満しきい値（「低いウォーターマーク」）を下回る場合、ダウンロードはリスタートする。充満レベルは、プレゼンテーション要素によってメディアデータが消費されると、アップデートされ得る。充満レベルは、メモリ記憶容量の単位および／またはプレゼンテーション時間の単位で測ることができる。ダウンロードは、推定ラウンドトリップ時間（「ＥＲＴＴ」）に基づくことができ、ＥＲＴＴは、メディアデータダウンロードがリスタートされるとリセットされる。ダウンロードが複数のＴＣＰ接続を介して起きた場合、メディアデータダウンロードがリスタートされると、使用されるいくつかのＴＣＰ接続はリセットされ得る。高充満しきい値および低充満しきい値は、時間とともに変化しうる。
[0362]本開示を読んだ後には、当業者にはさらなる実施形態が想起され得る。他の実施形態では、上で開示された発明の組合せまたは副次的な組合せが、有利に行われ得る。コンポーネントの例示的な構成は例示を目的に示され、組合せ、追加、再構成などが、本発明の代替的な実施形態において考えられることを理解されたい。したがって、本発明は、例示的な実施形態に関して説明されてきたが、多数の修正が可能であることを当業者は認識するだろう。
[0363]たとえば、本明細書で説明される処理は、ハードウェアコンポーネント、ソフトウェアコンポーネント、および／またはこれらの任意の組合せを使用して実施され得る。したがって、本明細書および図面は、限定的な意味ではなく例示的であると解釈されるべきである。しかしながら、特許請求の範囲において述べられるような本発明のより広い趣旨および範囲から逸脱することなく、様々な修正および変更を行うことができ、本発明は、以下の特許請求の範囲内にあるすべての修正と等価物とを包含することが意図されることは、明らかである。

Claims (32)

  1. ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御する方法であって、
    前記ソースと前記受信機との間の複数のＴＣＰ接続の各々について、そのＴＣＰ接続用のＴＣＰ受信機ウィンドウサイズを決定することであって、前記ソースと前記受信機との間のＴＣＰ接続が直接接続または間接接続であることができる、決定することと、
    前記複数のＴＣＰ接続の各々について、メディアコンテンツ用の目標ダウンロードレートを決定することであって、前記目標ダウンロードレートが、少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、決定することと、
    ダウンロードされるべき前記メディアコンテンツの複数のメディアデータ要素をダウンロードするために、前記複数のＴＣＰ接続の各ＴＣＰ接続を使用することであって、前記メディアコンテンツが、複数のＨＴＴＰ要求への応答の一部分または全部である、使用することとを備え、
    所与のＴＣＰ接続用の前記決定されたＴＣＰ受信機ウィンドウサイズが、そのＴＣＰ接続用の前記目標ダウンロードレートに少なくとも部分的に基づいて決定され、前記決定されたＴＣＰ受信機ウィンドウサイズが、前記少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、方法。
  2. 現在のＴＣＰ接続用の前記決定されたＴＣＰ受信機ウィンドウサイズが、乗数レートで乗算された、前記現在のＴＣＰ接続についての現在の推定ラウンドトリップ時間（「ＥＲＴＴ」）の積に少なくとも部分的に基づいて決定され、前記乗数レートが、前記現在のＴＣＰ接続用の前記目標ダウンロードレートと、前記目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である、請求項１に記載の方法。
  3. 前記現在のＥＲＴＴが、少なくとも部分的に、直前の測定期間にわたる最小の観測されたＲＴＴの測度によって決定される、請求項２に記載の方法。
  4. 前記直前の測定期間が、１０秒またはそれ以下の期間に対応する、請求項３に記載の方法。
  5. 前記現在のＥＲＴＴが、少なくとも部分的には、休止期間の終了時の測度によって決定され、前記休止期間が、前記複数のＴＣＰ接続を介したアクティブＨＴＴＰ要求が、所定の継続時間期間だけ存在していなかった期間である、請求項２に記載の方法。
  6. ＴＣＰ接続用の前記目標ダウンロードレートが、使用中のすべてのＴＣＰ接続にわたる現在の総ダウンロードレートを、使用中のＴＣＰ接続の数で除算したものに比例する、請求項１に記載の方法。
  7. ＴＣＰ接続用の前記目標ダウンロードレートが、使用中のすべてのＴＣＰ接続にわたる現在の総ダウンロードレートを、使用中のＴＣＰ接続の数で除算したものの２倍である、請求項１に記載の方法。
  8. 前記目標ダウンロードレートが、前記メディアコンテンツのプレイバックレートに比例し、前記プレイバックレートが、使用中のすべてのＴＣＰ接続に及ぶ総計にわたるレートを、使用中のＴＣＰ接続の数で除算したものである、請求項１に記載の方法。
  9. 各メディアデータ要素が、所定の分散範囲内のサイズを有するいくつかのチャンクに分割され、そのようなチャンクの数が、使用中のＴＣＰ接続の数に基づく、請求項１に記載の方法。
  10. そのようなチャンクの前記数が、現在のＴＣＰ接続についての現在の推定ラウンドトリップ時間（「ＥＲＴＴ」）、現在のダウンロードレート、および／または要求されているメディアフラグメントのサイズのうち少なくとも１つにさらに基づく、請求項９に記載の方法。
  11. 前記所定の分散範囲がゼロであり、したがって各チャンクがフラグメント要求ごとに同じサイズを有し、前記チャンクの数が、使用中のＴＣＰ接続の数に所定の因子を乗じたものに等しい、請求項９に記載の方法。
  12. 各チャンクが、最小バイト数以上のサイズを有する、請求項９に記載の方法。
  13. 後続メディアデータ要素についての後のＨＴＴＰ要求が、第１の利用可能ＴＣＰ接続に割り当てられる、請求項１に記載の方法。
  14. ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御する方法であって、
    メディアコンテンツ用の目標ダウンロードレートを決定することであって、前記目標ダウンロードレートが、少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、決定することと、
    前記ネットワーク経路に関する少なくとも１つのネットワーク条件を決定することと、
    前記ソースと前記受信機の間で使用するべきＴＣＰ接続の数を決定することであって、前記数が１よりも大きく、使用するべきＴＣＰ接続の前記数が、少なくとも部分的に、前記決定された少なくとも１つのネットワーク条件に基づいて決定される、決定することと、
    ダウンロードされるべき前記メディアコンテンツの複数のメディアデータ要素をダウンロードするために、前記数のＴＣＰ接続の各々を使用することであって、前記メディアコンテンツが、複数のＨＴＴＰ要求への応答の一部分または全部である、使用することとを備える方法。
  15. 使用中のＴＣＰ接続の前記数が、ＴＣＰ接続についての推定ラウンドトリップ時間（「ＥＲＴＴ」）、前記目標ダウンロードレート、および損失レートの推定値に少なくとも部分的に基づいて決定される、請求項１４に記載の方法。
  16. 前記損失レートが、１％または０．１％であると推定される、請求項１５に記載の方法。
  17. 使用するべきＴＣＰ接続の前記数が、両端値を含む２と１６との間に制限され、および／または（ａ）前記目標ダウンロードレート、（ｂ）推定ラウンドトリップ時間（「ＥＲＴＴ」）、および（ｃ）推定損失レートの平方根の積に比例する、請求項１４に記載の方法。
  18. 前記ＴＣＰ接続の各々について、前記目標ダウンロードレートに少なくとも部分的に基づいて決定される、そのＴＣＰ接続用のＴＣＰ受信機ウィンドウサイズを決定することであって、前記決定されたＴＣＰ受信機ウィンドウサイズが、前記少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、決定することをさらに備える、請求項１４に記載の方法。
  19. ネットワーク経路を介したソースからネットワークを介してデータをダウンロードする受信機であって、
    前記ネットワークからデータを受信するための受信機回路と、
    プロセスを実行するためのプロセッサと、
    データを記憶するためのメモリと、
    ＴＣＰ接続用のＴＣＰ受信機ウィンドウサイズを含む、前記ソースと前記受信機との間の複数のＴＣＰ接続に関連したデータのためのストレージであって、前記ソースと前記受信機との間のＴＣＰ接続が、直接接続または間接接続であることができる、ストレージと、
    メディアコンテンツ用の目標ダウンロードレートを決定するための論理であって、前記目標ダウンロードレートが、少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、論理と、
    前記メディアコンテンツの複数のメディアデータ要素をダウンロードした結果のためのストレージであって、前記メディアコンテンツが、複数のＨＴＴＰ要求への応答の一部分または全部であるストレージとを備え、
    所与のＴＣＰ接続用の前記決定されたＴＣＰ受信機ウィンドウサイズが、前記目標ダウンロードレートに少なくとも部分的に基づくサイズであり、決定されたＴＣＰ受信機ウィンドウサイズが、前記少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、受信機。
  20. 現在のＴＣＰ接続用の前記決定されたＴＣＰ受信機ウィンドウサイズが、乗数レートで乗算された、前記現在のＴＣＰ接続についての現在の推定ラウンドトリップ時間（「ＥＲＴＴ」）の積であり、前記乗数レートが、前記現在のＴＣＰ接続用の前記目標ダウンロードレートと、前記目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である、請求項１９に記載の受信機。
  21. 前記現在のＥＲＴＴが、直前の測定期間にわたる最小の観測されたＲＴＴの測度である、請求項２０に記載の受信機。
  22. 前記現在のＥＲＴＴが、少なくとも部分的には、休止期間に続くダウンロード期間中の測度によって決定され、前記休止期間が、前記ＴＣＰ接続を介したアクティブＨＴＴＰ要求が、所定の継続時間期間だけ存在していなかった期間である、請求項２０に記載の受信機。
  23. 前記目標ダウンロードレートが、使用中のすべてのＴＣＰ接続にわたる現在の総ダウンロードレートを、使用中のＴＣＰ接続の数で除算したものに比例する、請求項１９に記載の受信機。
  24. 各メディアデータ要素が、所定の分散範囲内のサイズを有するいくつかのチャンクに分割され、そのようなチャンクの数が、使用中のＴＣＰ接続の数、現在のＴＣＰ接続についての現在の推定ラウンドトリップ時間（「ＥＲＴＴ」）、現在のダウンロードレート、および／または要求されるメディアフラグメントのサイズのうち少なくとも１つに基づく、請求項１９に記載の受信機。
  25. ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御するためのプロセッサによって実行するための非一時的コンピュータ可読媒体であって、
    前記ソースと前記受信機との間の複数のＴＣＰ接続の各々について、そのＴＣＰ接続用のＴＣＰ受信機ウィンドウサイズを決定するためのプログラムコードであって、前記ソースと前記受信機の間のＴＣＰ接続が直接接続または間接接続であることができる、プログラムコードと、
    メディアコンテンツ用の目標ダウンロードレートを決定するためのプログラムコードであって、前記目標ダウンロードレートが少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、プログラムコードと、
    前記複数のＴＣＰ接続の各ＴＣＰ接続を使用して、ダウンロードされるべき前記メディアコンテンツの複数のメディアデータ要素をダウンロードするためのプログラムコードであって、前記メディアコンテンツが複数のＨＴＴＰ要求への応答の一部分または全部である、プログラムコードと、
    前記目標ダウンロードレートに少なくとも部分的に基づいて、所与のＴＣＰ接続用のＴＣＰ受信機ウィンドウサイズを決定するためのプログラムコードであって、前記決定されたＴＣＰ受信機ウィンドウサイズが前記少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、プログラムコードと、を備える非一時的コンピュータ可読媒体。
  26. 現在のＴＣＰ接続用の前記決定されたＴＣＰ受信機ウィンドウサイズが、前記現在のＴＣＰ接続についての現在の推定ラウンドトリップ時間（「ＥＲＴＴ」）を乗数レートで乗算した積に少なくとも部分的に基づいて決定され、前記乗数レートは、前記現在のＴＣＰ接続用の前記目標ダウンロードレートと、前記目標ダウンロードレートよりも所定の量だけ高いレートとによって制限される範囲内である、請求項２５に記載の非一時的コンピュータ可読媒体。
  27. 前記現在のＥＲＴＴが、少なくとも部分的に、直前の測定期間にわたる最小の観測されたＲＴＴの測度によって、または休止期間に続くダウンロード期間中の測度によって決定され、前記休止期間が、前記複数のＴＣＰ接続を介したアクティブＨＴＴＰ要求が、所定の継続時間期間だけ存在していなかった期間である、請求項２６に記載の非一時的コンピュータ可読媒体。
  28. 前記目標ダウンロードレートが、使用中のすべてのＴＣＰ接続を介した前記メディアコンテンツのプレイバックレートまたは現在の総ダウンロードレートを、使用中のＴＣＰ接続の数で除算したものに比例する、請求項２５に記載の非一時的コンピュータ可読媒体。
  29. ネットワーク経路によって結合されたソースと受信機との間の前記ネットワーク経路を介したデータダウンロードを制御するためのプロセッサによって実行するための非一時的コンピュータ可読媒体であって、
    メディアコンテンツ用の目標ダウンロードレートを決定するためのプログラムコードであって、前記目標ダウンロードレートが少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、プログラムコードと、
    前記ネットワーク経路に関する少なくとも１つのネットワーク条件を決定するためのプログラムコードと、
    前記ソースと前記受信機との間で使用するべきＴＣＰ接続の数を決定するためのプログラムコードであって、前記数が１よりも大きく、使用するべきＴＣＰ接続の前記数が、少なくとも部分的に、前記決定された少なくとも１つのネットワーク条件に基づいて決定される、プログラムコードと、
    前記数のＴＣＰ接続の各々を使用して、ダウンロードされるべき前記メディアコンテンツの複数のメディアデータ要素をダウンロードするためのプログラムコードであって、前記メディアコンテンツが複数のＨＴＴＰ要求への応答の一部分または全部である、プログラムコードと、を備える非一時的コンピュータ可読媒体。
  30. 使用中のＴＣＰ接続の前記数が、ＴＣＰ接続についての推定ラウンドトリップ時間（「ＥＲＴＴ」）、前記目標ダウンロードレート、および損失レートの推定値に少なくとも部分的に基づく、請求項２９に記載の非一時的コンピュータ可読媒体。
  31. 使用するべきＴＣＰ接続の前記数が、両端値を含む２と１６との間であり、および／または（ａ）前記目標ダウンロードレート、（ｂ）推定ラウンドトリップ時間（「ＥＲＴＴ」）、および（ｃ）推定損失レートの平方根の積に比例する、請求項２９に記載の非一時的コンピュータ可読媒体。
  32. 前記目標ダウンロードレートに少なくとも部分的に基づいてＴＣＰ接続用のＴＣＰ受信機ウィンドウサイズを決定するためのプログラムコードをさらに備え、前記ＴＣＰ受信機ウィンドウサイズが、前記少なくとも２つの連続するＨＴＴＰ要求についての少なくとも２つの値の間で変わる、請求項２９に記載の非一時的コンピュータ可読媒体。
JP2014558947A 2012-02-27 2013-02-26 マルチプルなｔｃｐ接続を介したソースと受信機との間のｈｔｔｐストリーミングの制御 Withdrawn JP2015515173A (ja)

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 マルチプルなｔｃｐ接続を介したソースと受信機との間のｈｔｔｐストリーミングの制御

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)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017225044A (ja) * 2016-06-16 2017-12-21 Kddi株式会社 コンテンツ配信システムのクライアント装置、コンテンツの取得方法及びプログラム

Families Citing this family (27)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Cited By (1)

* Cited by examiner, † Cited by third party
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) プレイバックレート選択を伴う改良されたｄａｓｈクライアントおよび受信機
JP2015511782A (ja) ダウンロードレートエスティメータを備えた改良されたｄａｓｈクライアントおよび受信機
JP2015515173A (ja) マルチプルなｔｃｐ接続を介したソースと受信機との間のｈｔｔｐストリーミングの制御
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