特許 6685989 シグナリング又はブロック生成を用いた拡張ブロック−要求ストリーミングシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6685989

(24)【登録日】2020年4月3日

(45)【発行日】2020年4月22日

(54)【発明の名称】シグナリング又はブロック生成を用いた拡張ブロック−要求ストリーミングシステム

(51)【国際特許分類】

   H04N 21/438 20110101AFI20200413BHJP

   G06F 13/00 20060101ALN20200413BHJP

【ＦＩ】

   H04N21/438

   !G06F13/00 520B

   !G06F13/00 540A

【請求項の数】2

【外国語出願】

【全頁数】102

(21)【出願番号】特願2017-228919(P2017-228919)

(22)【出願日】2017年11月29日

(62)【分割の表示】特願2016-68491(P2016-68491)の分割

【原出願日】2010年9月22日

(65)【公開番号】特開2018-88679(P2018-88679A)

(43)【公開日】2018年6月7日

【審査請求日】2017年12月27日

【審判番号】不服2019-8444(P2019-8444/J1)

【審判請求日】2019年6月25日

(31)【優先権主張番号】61/244,767

(32)【優先日】2009年9月22日

(33)【優先権主張国】US

(31)【優先権主張番号】61/257,719

(32)【優先日】2009年11月3日

(33)【優先権主張国】US

(31)【優先権主張番号】61/258,088

(32)【優先日】2009年11月4日

(33)【優先権主張国】US

(31)【優先権主張番号】61/285,779

(32)【優先日】2009年12月11日

(33)【優先権主張国】US

(31)【優先権主張番号】61/296,725

(32)【優先日】2010年1月20日

(33)【優先権主張国】US

(31)【優先権主張番号】61/372,399

(32)【優先日】2010年8月10日

(33)【優先権主張国】US

(31)【優先権主張番号】12/887,476

(32)【優先日】2010年9月21日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】595020643

【氏名又は名称】クゥアルコム・インコーポレイテッド

【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100109830

【弁理士】

【氏名又は名称】福原 淑弘

(74)【代理人】

【識別番号】100158805

【弁理士】

【氏名又は名称】井関 守三

(74)【代理人】

【識別番号】100112807

【弁理士】

【氏名又は名称】岡田 貴志

(72)【発明者】

【氏名】マイケル・ジー．・ルビー

(72)【発明者】

【氏名】マーク・ワトソン

(72)【発明者】

【氏名】ロレンツォ・ビシサノ

(72)【発明者】

【氏名】パヤム・パクザド

(72)【発明者】

【氏名】ビン・ワン

(72)【発明者】

【氏名】イン・チェン

(72)【発明者】

【氏名】トーマス・ストックハマー

【合議体】

【審判長】 千葉 輝久

【審判官】 間宮 嘉誉

【審判官】 小池 正彦

(56)【参考文献】

【文献】 特開２００６−１７４４１９（ＪＰ，Ａ）

【文献】 特表２００６−５２７４４２（ＪＰ，Ａ）

【文献】 米国特許第６７６３３９２（ＵＳ，Ｂ１）

【文献】 特開２００８−１４８１３７（ＪＰ，Ａ）

【文献】 国際公開第２００９／０１７２２９（ＷＯ，Ａ１）

【文献】 “ＩＴＵ−Ｔホワイトブック”，“オーディオビジュアル／マルチメディア関連（Ｈシリーズ）勧告書”，財団法人新日本ＩＴＵ協会，１９９５年２月１８日，ｐｐ．３９３−４１６，５３１−５３５

【文献】 西村敏，“知っておきたいキーワード ＭＰＥＧ−ＤＡＳＨ”，映像情報メディア学会誌，一般社団法人映像情報メディア学会，２０１７年，Ｖｏｌ．７１，Ｎｏ．１，ｐｐ．７８−８１

(58)【調査した分野】（Int.Cl.，ＤＢ名）

H04N 7/10

H04N 7/14- 7/173

H04N 7/20- 7/56

H04N 21/00-21/858

G06F 13/00

(57)【特許請求の範囲】

【請求項1】

クライアントデバイスがメディア取り込みシステムからメディアデータを受信する通信システムにおいて、
前記メディア取り込みシステムにおいて、メディアプレゼンテーション記述（ＭＰＤ）に記述された立ち上がり遅延を前記クライアントデバイスに提供することを備え、前記立ち上がり遅延は、前記クライアントデバイスが前記メディア取り込みシステムから前記メディアデータを受信するのを最初に開始したときと前記クライアントデバイスが中断なしに前記メディアデータの消費を開始することができるときとの間の遅延であり、前記立ち上がり遅延は、前記メディア取り込みシステムと前記クライアントデバイスとの間で利用可能な送信帯域幅の関数であり、
ここにおいて、前記立ち上がり遅延は、最小の立ち上がり遅延であり、前記最小の立ち上がり遅延は、前記送信帯域幅に基づいて決定される、方法。

【請求項2】

クライアントデバイスがメディア取り込みシステムからメディアデータを受信する通信システムにおいて、
前記クライアントデバイスにおいて、前記メディア取り込みシステムから、メディアプレゼンテーション記述（ＭＰＤ）に記述された立ち上がり遅延を受信することであって、前記立ち上がり遅延は、前記メディア取り込みシステムと前記クライアントデバイスとの間で利用可能な送信帯域幅の関数であり、ここにおいて、前記立ち上がり遅延は、最小の立ち上がり遅延であり、前記最小の立ち上がり遅延は、前記送信帯域幅に基づいて決定され、
前記メディア取り込みシステムからメディアデータを受信することと、
前記最小の立ち上がり遅延だけ前記メディアデータの消費の開始を遅延させることと、
を備える、方法。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、各々がＭｉｃｈａｅｌ Ｇ．Ｌｕｂｙ（マイケルＧ．ラビー）、等の名前を挙げ、各々が“Enhanced Block-Request Streaming System”（拡張ブロック−要求ストリーミングシステム）という題名を有する次の仮出願の利益を主張する非仮特許出願である。

【0002】

米国仮特許出願第６１／２４４，７６７号（出願日：２００９年９月２２日）、
米国仮特許出願第６１／２５７，７１９号（出願日：２００９年１１月３日）、
米国仮特許出願第６１／２５８，０８８号（出願日：２００９年１１月４日）、
米国仮特許出願第６１／２８５，７７９号（出願日：２００９年１２月１１日）、及び 米国仮特許出願第６１／２９６，７２５号（出願日：２０１０年１月２０日）。

【0003】

本出願は、Ｙｉｎｇ Ｃｈｅｎ（イン・チェン）、等の名前を挙げ、“HTTP Streaming Extensions”（ＨＴＴＰストリーミング拡張）という題名を有する米国仮特許出願第６１／３７２，３９９号（出願日：２０１０年８月１０日）の以下の利益も主張する。

【0004】

上記において引用される各仮出願は、全目的のために引用によってここによって組み入れられている。本開示は、あたかも本文書において完全に説明されているものとして、全目的のために、次の共通して譲渡されている出願／特許も引用によって組み入れる。

【0005】

Ｌｕｂｙ（ラビー）（以下“Ｌｕｂｙ Ｉ”）に対する米国特許第６，３０７，４８７号；
Ｓｈｏｋｒｏｌｌａｈｉ，ｅｔ ａｌ．（ショクロラヒ、等）（以下“Ｓｈｏｋｒｏｌｌａｈｉ Ｉ”）に対する米国特許第７，０６８，７２９号；
Ｌｕｂｙ、等（以下“Ｌｕｂｙ ＩＩ”）の名前を挙げ、“Forward Error-Correcting (FEC) Coding and Streaming”（前方誤り訂正（ＦＥＣ）コーディング及びストリーミング）という題名を有する米国特許出願第１１／４２３，３９１号（出願日：２００６年6月９日）；
Ｌｕｂｙ、等（以下“Ｌｕｂｙ ＩＩＩ”）の名前を挙げ、“Dynamic Stream Interleaving and Sub-Stream Based Delivery”（動的ストリームインターリービング及びサブストリームに基づく配信）という題名を有する米国特許出願第１２／１０３，６０５号（出願日：２００８年４月１５日）；
Ｐａｋｚａｄ， ｅｔ ａｌ．（パクザド、等）（以下“Ｐａｋｚａｄ”）の名前を挙げ、“Block Partitioning for a Data Stream”（データストリームのためのブロックパーティショニング）という題名を有する米国特許出願第１２／７０５，２０２号（出願日：２０１０年２月１２日）；及び
Ｌｕｂｙ，ｅｔ ａｌ．（以下“Ｌｕｂｙ ＩＶ”）の名前を挙げ、“Methods and Apparatus Employing FEC Codes with Permanent Inactivation of Symbols for Encoding and Decoding Processes”（符号化及び復号プロセスのためのシンボルの永久的非アクティブ化を伴うＦＥＣコードを採用する方法及び装置）という題名を有する米国特許出願第１２／８５９，１６１号（出願日：２０１０年８月１８日）。

【0006】

本発明は、改良されたメディアストリーミングシステム及び方法に関するものである。本発明は、より具体的には、ストリーミングされたメディアのプレゼンテーション（ｐｒｅｓｅｎｔａｔｉｏｎ）を最適化するためにネットワーク及びバッファ状態に適応するシステム及び方法に関するものであり、ストリーミングされたメディアデータの効率的で同時並行した、又はタイムリーに配分された配信を可能にする。

【背景技術】

【0007】

ストリーミングメディア配信は、高品質の音声及び映像がパケットに基づくネットワーク、例えばインターネット、セルラー及び無線ネットワーク、電力線ネットワーク、及びその他のタイプのネットワーク、を通じて配信されることがより一般的になるのに従ってますます重要になるであろう。配信されたストリーミングメディアを提示することができる品質は、原コンテンツの解像度（又はその他の属性）、原コンテンツの符号化品質、受信デバイスがメディアを復号及び提示する能力、受信機において受信された信号のタイムリー性と品質、等を含む幾つかの要因に依存することができる。実感された良好なストリーミングメディア経験を創出するためには、受信機において受信された信号の転送及びタイムリー性が特に重要であろう。良好な転送は、送信者が送信するものに関する受信機において受信されたストリームの忠実性を提供することができ、他方、タイムリー性は、受信機がそのコンテンツの最初の要求後いかに素早くそのコンテンツをプレイアウト（ｐｌａｙｏｕｔ）するのを開始することができるかを表すことができる。

【0008】

メディア配信システムは、メディアソース、メディアの行先、及びソースと行先を分離するチャネル（時間及び／又は空間）を有するシステムであると特徴付けることができる。典型的には、ソースは、電子的に管理可能な形式のメディアへのアクセスを有する送信機と、メディア（又はそれの近似）の受信を電子的に制御し及びメディア消費者（例えば、受信機、記憶装置又は要素、他のチャネル）に何らかの形で結合された表示デバイスを有するユーザ）にそれを提供する能力を有する受信機と、を含む。

【0009】

多くの変形が可能である一方で、一共通例においては、メディア配信システムは、電子形式のメディアコンテンツへのアクセスを有する１つ以上のサーバを有し、１つ以上のクライアントシステム又はデバイスがサーバに対してメディアの要求を行い、サーバは、サーバとの一部としての送信機を用いてメディアを伝送し、受信されたメディアが何らかの形でクライアントによって消費できるようにクライアントにおける受信機に送信する。単純な例では、所定の要求及び応答に関して１つのサーバ及び１つのクライアントが存在するが、そうである必要はない。

【0010】

伝統的に、メディア配信システムは、“ダウンロード”モデル又は“ストリーミング”モデルのいずれかとして特徴付けることができる。“ダウンロード”モデルは、メディアデータの配信とユーザ又は受信デバイスへのメディアのプレイアウトとの間でのタイミング上の独立性によって特徴付けることができる。

【0011】

一例として、メディアは、それが必要とされるか又は用いられるときよりも十分事前にダウンロードされ、それが用いられるときには、必要なだけの量が受信者において既に入手可能である。ダウンロードの文脈での配信は、ファイル転送プロトコル、例えばＨＴＴＰ、ＦＴＰ又は単方向転送でのファイル配信（ＦＬＵＴＥ）、等を用いてしばしば行われ、配信レートは、基本になるフロー及び／又は混雑制御プロトコル、例えばＴＣＰ／ＩＰ、によって決定することができる。フロー又は混雑制御プロトコルの動作は、ユーザ又は行先デバイスへのメディアのプレイアウトから独立することができ、それは、ダウンロードと同時並行して又は何らかのその他の時点に生じることができる。

【0012】

“ストリーミング”モードは、メディアデータの配信のタイミングとユーザ又は受信者デバイスへのメディアのプレイアウトとの間での強固な結合として特徴付けることができる。この文脈における配信は、ストリーミングプロトコル、例えば制御のためのリアルタイムストリーミングプロトコル（ＲＴＳＰ）及びメディアデータのためのリアルタイム転送プロトコル（ＲＴＰ）、等を用いてしばしば行われる。配信速度は、ストリーミングサーバによって決定することができ、データのプレイアウトレートとしばしば合致される。

【0013】

“ダウンロード”モデルの幾つかの欠点は、配信及びプレイアウトのタイミング上の独立性に起因して、（例えば、利用可能な帯域幅がメディアデータレートよりも小さいことに起因して）メディアデータがプレイアウトのために必要なときに入手できず、プレイアウトを一時的に停止させ（“停止”）、その結果不良なユーザ経験になるか、又は、（例えば、利用可能な帯域幅がメディアデータレートよりも大きいことに起因して）メディアデータをプレイアウトよりもはるかに事前にダウンロードすることが要求され、不足している可能性がある受信デバイスにおける格納リソースを消費し、貴重な格納リソースが配信のために消費され、コンテンツが最終的にプレイアウトされないか又はその他の形で使用されない場合は浪費されるおそれがあることである。

【0014】

“ダウンロード”モデルの一利点は、該ダウンロードを行うために必要な技術、例えばＨＴＴＰ、が非常に成熟しており、幅広く配備され、広範囲な用途にわたって利用可能であることであろう。ダウンロードサーバ及び該ファイルダウンロードの大規模なスケーラビリティのための解決方法（例えば、ＨＴＴＰウェブサーバ及びコンテンツデリバリネットワーク）は簡単に利用可能であり、この技術に基づくサービスの展開を単純かつ低コストにしている。

【0015】

“ストリーミング”モデルの幾つかの欠点は、概して、サーバからクライアントへのコネクションにおいてメディアデータの配信レートが利用可能な帯域幅に合わせて好適化されないこと及び帯域幅及び遅延に関する保証を提供する専用のストリーミングサーバ又はより複雑なネットワークアーキテクチャが要求されることであろう。利用可能な帯域幅による配信データレートの変動をサポートするストリーミングシステム（例えば、Ａｄｏｂｅ Ｆｌａｓｈ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ（Ａｄｏｂｅフラッシュ適応型ストリーミング））が存在するが、これらは、概して、すべての利用可能な帯域幅を利用時にはＴＣＰ等のダウンロード転送フロー制御プロトコルほど効率的でない。

【0016】

最近は、“ストリーミング”モデル及び“ダウンロード”モデルの組み合わせに基づく新しいメディア配信システムが開発及び配備されている。該モデルの一例は、ここにおいては“ブロック−要求ストリーミング”モデルと呼ばれ、メディアクライアントは、ダウンロードプロトコル、例えばＨＴＴＰ、を用いてサービングインフラストラクチャにメディアデータのブロックを要求する。該システムにおける１つの懸念は、ストリームのプレイアウトを開始する能力、例えば、パソコンを用いて受信された音声及び映像ストリームを復号及びレンダリングすること、及びコンピュータ画面上に映像を表示して組み込み式スピーカを通じて音声を再生すること、であることができ、又は、他の例として、セットトップボックスを用いて受信された音声及び映像ストリームを復号及びレンダリングすること及びテレビ表示装置上で映像を表示し及びステレオシステムを通じて音声を再生すること、であろう。

【0017】

その他の懸念、例えばソースストリーミングレートと速度を合わせることができる速さでソースブロックを復号し、復号レーテンシーを最小にし及び利用可能なＣＰＵリソースの使用を低減させることが可能であること、が課題である。他の懸念は、システムのコンポーネントが受信機に配信されたストリームの品質に対して悪影響を及ぼさずに使用不能になることを可能にするロバストで（ｒｏｂｕｓｔ）でスケーラブルなストリーミング配信解決方法を提供することである。プレゼンテーションに関する急速に変化する情報が配信されるのに応じて、それに基づいてその他の問題が発生することがある。従って、改良されたプロセス及び装置を有することが望ましい。

【発明の概要】

【0018】

ブロック−要求ストリーミングシステムは、該システムのユーザ経験及び帯域幅効率の向上を提供し、従来のファイルサーバ（ＨＴＴＰ、ＦＴＰ、等）によって対処される形式のデータを生成する取り込みシステム（ｉｎｇｅｓｔｉｏｎ ｓｙｓｔｅｍ）を典型的に使用し、取り込みシステムは、コンテンツを取り込み、キャッシュを含むことができ又は含まなくてもよいファイルサーバによって対処されるファイル又はデータ要素としてそれを準備する。クライアントデバイスは、取り込みプロセスを利用するために好適化することができ、取り込みプロセスから独立したより良いプレゼンテーションのために役立つ改良を含む。

【0019】

これらの実施形態は、時間に基づくインデキシングの提供を含むブロック要求のシーケンス、タイミング及び構築を決定するためにブロック−要求ストリーミングクライアントにおいて及びブロック要求取り込みシステムにおいて用いられる方法に対する新規の改良を含む。幾つかの実装においては、可変ブロックサイズ設定と最適なブロックパーティショニングとを含むブロック及びファイルの構築のための方法に対する新規の改良が提供される。幾つかの実施形態においては、複数のプレゼンテーションバージョンにわたるランダムアクセスポイントの配置を含むランダムアクセスポイント配置方法に対する新規の改良が提供される。幾つかの実施形態においては、メタデータ内でのシグナリングを含むプレゼンテーションデータを動的に更新する方法に対する新規の改良が提供される。幾つかの実施形態においては、ライブのコンテンツを効率的に提示するための及び時間シフトのための方法に対する新規の改良が提供される。

【0020】

以下の詳細な発明を実施するための形態は、添付図とともに、本発明の性質及び利点のより良い理解を提供するであろう。

【図面の簡単な説明】

【0021】

【図1】本発明の実施形態によるブロック−要求ストリーミングシステムの要素を描いた図である。

【図2】図１のブロック−要求ストリーミングシステムを例示した図であり、コンテンツ取り込みシステムによって処理されるデータを受信するためにブロックサービングインフラストラクチャに結合されるクライアントシステムの要素内のより詳細な細部を示す。

【図3】取り込みシステムのハードウェア／ソフトウェア実装を例示した図である。

【図4】クライアントシステムのハードウェア／ソフトウェア実装を例示した図である。

【図5】図１に示されるコンテンツストアの可能な構造を例示した図であり、セグメント及びメディアプレゼンテーション記述子（“ＭＰＤ”）ファイルと、ＭＰＤファイル内のセグメント、タイミング、及びその他の構造の細部と、を含む。

【図6】図１及び５において例示されたコンテンツストアに格納することが可能な典型的なソースセグメントの詳細を例示した図である。

【図7(a)】ファイル内の単純な及び階層的インデキシングを例示した図である。

【図7(b)】ファイル内の単純な及び階層的インデキシングを例示した図である。

【図8(a)】メディアストリームの複数のバージョンにわたる整合されたシークポイントを有する可変ブロックサイズ設定を例示した図である。

【図8(b)】メディアストリームの複数のバージョンにわたる整合されないシークポイントを有する可変ブロックサイズ設定を例示した図である。

【図9(a)】メタデータテーブルを例示した図である。

【図9(b)】サーバからクライアントへのブロック及びメタデータテーブルの送信を例示した図である。

【図10】ＲＡＰ境界から独立しているブロックを例示した図である。

【図11】セグメント間での連続的及び非連続的タイミングを例示した図である。

【図12】スケーラブルブロックの一態様を示した図である。

【図13】経時でのブロック−要求ストリーミングシステム内での幾つかの変数の展開の図形表示を描いた図である。

【図14】経時でのブロック−要求ストリーミングシステム内での幾つかの変数の展開の他の図形表示を描いた図である。

【図15】スレショルド値の関数としての状態のセル格子を描いた図である。

【図16】１つの要求ごとに単一のブロック及び複数のブロックを要求することができる受信機において実行することができるプロセスのフローチャートである。

【図17】柔軟なパイプラインプロセスのフローチャートである。

【図18】候補の要求の組、それらの優先度、及びそれらを一定の時間に出すことができるコネクションの例を示した図である。

【図19】１つの時間から他までに展開している、候補の要求の組、それらの優先度、及びそれらを出すことができるコネクションの例を示した図である。

【図20】ファイル識別子に基づく一貫したキャッシングサーバプロキシ選択のフローチャートである。

【図21】適切な式言語のための構文定義を例示した図である。

【図22】適切なハッシュ関数の例を示した図である。

【図23】ファイル識別子構築規則の例を示した図である。

【図24】ＴＣＰコネクションの帯域幅変動を例示した図である。

【図25】ソース及び修復データに関する複数のＨＴＴＰ要求を例示した図である。

【図26】ＦＥＣを有する及び有さないチャネルザッピング時間例を示した図である。

【図27】図１に示される取り込みシステムの一部として、ソースセグメント及び制御パラメータから修復セグメントを生成する修復セグメント生成器の詳細を例示した図である。

【図28】ソースブロックと修復ブロックとの間の関係を例示した図である。

【図29】クライアントでの異なる時間におけるライブサービスのための手順を例示した図である。

【0022】

図においては、同様の品目は同様の数字を用いて参照され、及び、同様の又は同一の品目の複数のインスタンスを示すためにサブインデックスが括弧内に提供される。別の指示がない限り、最後のサブインデックス（例えば、“Ｎ”又は“Ｍ”）は、いずれかの特定の値に限定することは意図されず、及び、１つの品目のインスタンス数は、同じ数字が示され及びサブインデックスが再使用されるときでも他の品目のインスタンス数と異なることができる。

【発明を実施するための形態】

【0023】

ここにおいて説明されるように、ストリーミングシステムの１つの最終目標は、メディアをそれの格納場所（又はそれが生成されている場所）からそれが消費される、すなわち、ユーザに提示されるか又は人間の又は電子上の消費者によって“使い果たされる”、場所に移動させることである。理想的には、ストリーミングシステムは、受信端において中断されない再生（より一般的には、中断されない“消費”）を提供することができ及びユーザがストリーム又はストリーム（複数）を要求後まもなくストリーム又はストリームの集合の再生を開始することができる。効率上の理由で、例えば、ユーザが１つのストリームから他のストリームに切り換え中であるか又はそれがストリーム、例えば、“字幕”ストリーム、の提示に従うときに、ストリームをもはや必要としないことをユーザが示した時点で各ストリームが停止されることも望ましい。メディアコンポーネント、例えば映像、が引き続き提示されるが、このメディアコンポーネントを提示するために異なるストリームが選択される場合は、新しいストリームによって限られた帯域幅を占有して旧ストリームは停止させることがしばしば好ましい。

【0024】

ここにおいて説明される実施形態によるブロック−要求ストリーミングシステムは、多くの利益を提供する。幾つかの用途は、ここにおいて説明されるすべての特徴よりも少ない特徴で適切に満足させる経験を提供することができるため、存続可能なシステムは、ここにおいて説明されるすべての特徴を含む必要がないことが理解されるべきである。

【0025】

ＨＴＴＰストリーミング
ＨＴＴＰストリーミングは、特定のタイプのストリーミングである。ＨＴＴＰストリーミングを用いる場合は、ソースは、標準のウェブサーバ及びコンテンツデリバリネットワーク（ＣＤＮ）であることができ及び標準のＨＴＴＰを用いることができる。この技法は、ストリームのセグメンテーションと複数のストリームの使用とを含むことができ、それらはすべて標準化されたＨＴＴＰ要求のコンテキスト内である。メディア、例えば映像、は、異なるバージョン、又は表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）を形成するために複数のビットレートで符号化することができる。用語“バージョン”及び“表現”は、本文書においては同義で用いられる。各バージョン又は表現は、セグメントを形成するためにより小さい部分、おそらく各々が数秒のオーダー、に細分することができる。これで、各セグメントは、別々のファイルとしてウェブサーバ又はＣＤＮに格納することができる。

【0026】

クライアント側では、クライアントによって継ぎ目なしでまとめてスプライシング（ｓｐｌｉｃｅ）された個々のセグメントに関してＨＴＴＰを用いて要求を行うことができる。クライアントは、利用可能な帯域幅に基づいて異なるデータレートに切り換わることができる。クライアントは、各々が異なるメディアコンポーネントを提示する複数の表現を要求することもでき、及び、これらの表現においてまとめて及び同期的にメディアを提示することができる。切り換えためのトリガは、例えば、バッファ占有率とネットワーク測定値とを含むことができる。定常状態で動作時には、クライアントは、目標のバッファ占有率を維持するためにサーバへの要求を整調することができる。

【0027】

ＨＴＴＰストリーミングの利点は、ビットレートの好適化と、高速の立ち上がり及びシーク（ｓｅｅｋ）と、最小の不要な配信とを含むことができる。これらの利点は、配信がプレイアウトのほんの短時間だけ前であるように制御すること、（可変のビットレートメディアを通じて）利用可能な帯域幅を最大限に利用すること、及びストリームセグメンテーション及びインテリジェントクライアント手順を最適化することから得られる。

【0028】

クライアントがユーザにストリーミングサービスを提供するために（例えば、ここでは３ｇｐセグメントと呼ばれる、３ＧＰＰ（登録商標）によって指定された形式の）ファイルの集合を用いることができるようにメディアプレゼンテーション記述をＨＴＴＰストリーミングクライアントに提供することができる。メディアプレゼンテーション記述、そしておそらくこのメディアプレゼンテーション記述の更新は、クライアントが含まれているメディアを同期化された形で提示することができ及び拡張された特徴、例えば、シーク、ビットレート切り換え及び異なる表現でのメディアコンポーネントの共同提示、を提供することができるように、各々がメディアコンポーネントを含むセグメントの構造化された集合であるメディアプレゼンテーションを記述する。クライアントは、サービスのプロビジョニング（ｐｒｏｖｉｓｉｏｎｉｎｇ）のために異なる方法でメディアプレゼンテーション記述情報を用いることができる。特に、メディアプレゼンテーション記述から、ＨＴＴＰストリーミングクライアントは、ストリーミングサービス内においてクライアントの能力及びユーザにとってデータが有用であるようにするために集合内のいずれのセグメントにアクセス可能であるかを決定することができる。

【0029】

幾つかの実装においては、メディアプレゼンテーション記述は、静的であることができるが、セグメントは、動的に生成することが可能である。メディアプレゼンテーション記述は、サービスのためのアクセス及びダウンロード時間を最短にするために可能な限りコンパクトであることができる。その他の専用サーバの接続性、例えば、クライアントとサーバとの間での定期的な又は頻繁なタイミング同期化、を最小にすることができる。

【0030】

メディアプレゼンテーションは、異なる能力、例えば、異なるアクセスネットワークタイプへのアクセス、異なる現在のネットワーク状態、ディプレイのサイズ、アクセスビットレベル及びコーデックサポート、を有する端末によるアクセスを可能にするように構築することができる。これで、クライアントは、ユーザに対してストリーミングサービスを提供するための該当する情報を抽出することができる。

【0031】

メディアプレゼンテーション記述は、要求事項による配備上の柔軟性及びコンパクトさを可能にすることもできる。

【0032】

最も単純な事例においては、各代替表現を、単一の３ＧＰファイル、すなわち、３ＧＰＰ ＴＳ２６．２４４における定義に準拠したファイル、又は、ＩＳＯ／ＩＥＣ １４４９６−１２又は派生仕様において定義されるＩＳＯベースメディアファル形式（例えば、３ＧＰＰ技術仕様２６．２４４において説明される３ＧＰファイル形式）に準拠するあらゆるその他のファイル、に格納することができる。本文書の残りの部分において、３ＧＰファイルに言及するときには、ＩＳＯ／ＩＥＣ １４４９６−１２及び派生仕様は、ＩＳＯ／ＩＥＣ １４４９６−１２又はいずれかの派生仕様において定義されるより一般的なＩＳＯベースメディアファイル形式にすべての説明される特徴をマッピング可能であることが理解されるべきである。これで、クライアントは、（“ｍｏｏｖ”ボックスとも呼ばれるムービーヘッダボックス内に典型的に格納される）メディアメタデータをムービーフラグメント時間及びバイトオフセットとともに知るためにファイルの最初の部分を要求することができる。これで、クライアントは、要求に応じてムービーフラグメントを入手するためのＨＴＴＰ部分的入手要求を出すことができる。

【0033】

幾つかの実装においては、各表現を幾つかのセグメントに分割するのが望ましいことがあり、ここで、セグメントは。セグメント形式が３ＧＰファイル形式に基づく場合は、セグメントは、“時間別分割”と呼ばれるムービーフラグメントの重なり合わないタイムスライスを含む。これらのセグメントの各々は、複数のムービーフラグメントを含むことができ、及び、各々は、それ自体が有効な３ＧＰファイルであることができる。他の実施形態においては、表現は、メタデータ（典型的にはムービーヘッダ“ｍｏｏｖ”ボックス）を含む最初のセグメント及び各々がメディアデータを含むメディアセグメントの組に分割され、最初のセグメントといずれかのメディアセグメントの連結は、有効な３ＧＰファイルを形成し、１つの表現の最初のセグメントと全メディアセグメントの連結は、有効な３ＧＰファイルを形成する。プレゼンテーション全体は、各セグメントを順々にプレイアウトし、各表現の開始時間によりグローバルな提示時間にファイル内のローカルタイムスタンプをマッピングすることによって形成することができる。

【0034】

この説明全体を通じて、“セグメント”への言及は、完全に又は部分的に構築された又は記憶媒体から読み出された又は例えばＨＴＴＰ要求を含むファイルダウンロードプロトコル要求の結果として入手されたいずれかのデータオブジェクトを含むことが理解されるべきである。例えば、ＨＴＴＰの場合は、データオブジェクトは、ＨＴＴＰサーバに接続された又はＨＴＴＰサーバの一部を成すディスク又はその他の記憶媒体上に常駐する実際のファイルに格納することができ、又は、データオブジェクトは、ＨＴＴＰ要求に応答して実行されるＣＧＩスクリプト又はその他の動的に実行されるプログラムによって構築することができる。用語“ファイル”及び“セグメント”は、別の明記がない限りこの文書においては同義で用いられる。ＨＴＴＰの場合は、セグメントは、ＨＴＴＰ要求応答の本体全体であるとみなすことができる。

【0035】

用語“プレゼンテーション”及び“コンテンツ項目”は、この文書では同義で用いられる。多くの例において、プレゼンテーションは、定義された“プレイアウト”時間を有する音声、映像又はその他のメディアプレゼンテーションであるが、その他の変形も可能である。

【0036】

用語“ブロック”及び“フラグメント”は、別の明記がない限りこの文書では同義で用いられ、インデキシングされたデータの最小の集合体を概して意味する。利用可能なインデキシングに基づき、クライアントは、異なるＨＴＴＰ要求においてフラグメントの異なる部分を要求することができ、又は、１つのＨＴＴＰ要求において１つ以上の連続するフラグメント又はフラグメントの一部分を要求することができる。ＩＳＯベースメディアファイル形式に基づくセグメント又は３ＧＰファイル形式に基づくセグメントが用いられる場合は、フラグメントは、典型的には、ムービーフラグメントヘッダ（‘ｍｏｏｆ’）ボックス及びメディアデータ（‘ｍｄａｔ’）ボックスの組み合わせであると定義されるムービーフラグメントを意味する。

【0037】

ここでは、データを搬送するネットワークは、ここにおける説明を簡略化するためにパケットに基づくことが仮定されており、当業者は、この開示を読んだ後は、ここにおいて説明される本発明の実施形態をその他のタイプの送信ネットワーク、例えば、連続的ビットストリームネットワーク、に対して適用可能であると認識されている。

【0038】

ここでは、ＦＥＣコードは、ここにおける説明を簡略化するために、長い可変のデータ配信時間に対する保護を提供すると仮定されており、当業者は、この開示を読んだ後は、本発明の実施形態をその他のタイプのデータ送信上の課題、例えば、データのビットフリップ破損（ｂｉｔ−ｆｌｉｐ ｃｏｒｒｕｐｔｉｏｎ）、に対して適用可能であると認識されている。例えば、ＦＥＣがない場合は、要求されたフラグメントの最後の部分がフラグメントの前の部分よりもはるかに遅く到着するか又は到着時間において高い偏差を有する場合は、コンテンツザッピング時間は大きくかつ可変である可能性があり、他方、ＦＥＣ及び並行要求を用いる場合は、フラグメントを復元することができる前にフラグメントのための要求されたデータの大部分のみが到着する必要があり、それにより、コンテンツザッピング時間を短縮し及びコンテンツザッピング時間の可変性を低下させる。この説明では、符号化されるデータ（すなわち、ソースデータ）は（単一ビットまでの）あらゆる長さであることができる等しい長さの“シンボル”に分割されていると仮定することができるが、シンボルは、データの異なる部分に関して異なる長さであることが可能であり、例えば、データの異なるブロックに関して異なるシンボルサイズを用いることができる。

【0039】

この説明では、ここにおける説明を簡略化するために、ＦＥＣは一度に１つのデータ“ブロック”又は“フラグメント”に適用される、すわなわち、“ブロック”は、ＦＥＣの符号化及び復号目的のための“ソースブロック”であると仮定されている。クライアントデバイスは、セグメントのソースブロック構造を決定するのに役立てるためにここにおいて説明されるセグメントインデキシングを用いることができる。当業者は、本発明の実施形態をその他のタイプのソースブロック構造に適用することができ、例えば、ソースブロックは、フラグメントの一部分であること、又は１つ以上のフラグメント又は複数のフラグメントの複数部分を包含することができる。

【0040】

ブロック−要求ストリーミングとともに用いることが考慮されているＦＥＣコードは、典型的には体系的ＦＥＣコードであり、すなわち、ソースブロックのソースシンボルは、ソースブロックの符号化の一部として含めることができ、従って、ソースシンボルが送信される。当業者が認識することになるように、ここにおいて説明される実施形態は、体系的でないＦＥＣコードに対しても同様に適用される。体系的ＦＥＣ符号器は、ソースシンボルのソースブロックから、幾つかの数の修復シンボルを生成し、ソースシンボル及び修復シンボルの少なくとも一部の組み合わせは、ソースブロックを表現するチャネルを通じて送信される符号化されたシンボルである。幾つかのＦＥＣコードは、必要なだけの数の修復シンボル、例えば、“情報付加コード”（ａｄｄｉｔｉｖｅ ｃｏｄｅ）又は“ファウンテンコード”（ｆｏｕｎｔａｉｎ ｃｏｄｅ）、を効率的に生成するのに役立つことができ、これらのコードの例は、“連鎖反応コード”（ｃｈａｉｎ ｒｅａｃｔｉｏｎｃｏｄｅ）と“多段連鎖反応コード”とを含む。その他のＦＥＣコード、例えばＲｅｅｄ−Ｓｏｌｏｍｏｎコード、は、実際上は、各ソースブロックに関して制限された数の修復シンボルしか生成することができない。

【0041】

これらの例の多くでは、クライアントはメディアサーバ又は複数のメディアサーバに結合され、クライアントは、そのメディアサーバ又は複数のメディアサーバにチャネル又は複数のチャネルを通じてストリーミングメディアを要求すると仮定されている。しかしながら、より多くの関係する手はずも可能である。

【0042】

利益例
ブロック−要求ストリーミングでは、メディアクライアントは、これらのブロック要求のタイミング及びユーザへのメディアプレイアウトのタイミングの結合を維持する。このモデルは、データ配信からのメディアプレイアウトの通常の切り離しに起因する欠点の一部を回避しつつ上述される“ダウンロード”モデルの利点を保持することができる。ブロック−要求ストリーミングモデルは、最大の利用可能な帯域幅がメディアデータのために確実に用いられるようにするために、転送プロトコル、例えばＴＣＰ、において利用可能なレート及び混雑制御メカニズムを利用する。さらに、ブロックへのメディアプレゼンテーションの分割は、符号化されたメディアデータの各ブロックを複数の利用可能な符号化の組から選択することを可能にする。

【0043】

この選択は、利用可能な帯域幅が経時で変化中であるときでさえも、メディアデータレートを利用可能な帯域幅にマッチングさせること、メディア解像度又は復号の複雑さをクライアントの能力又は構成にマッチングさせること、又はユーザの選好、例えば言語、にマッチングさせること、を含むあらゆる数の基準に基づくことができる。選択は、補助コンポーネント、例えばアクセス性に関するコンポーネント、クローズドキャプショニング、字幕、手話映像、等のダウンロード及びプレゼンテーションを含むこともできる。ブロック−要求ストリーミングモデルを用いる既存のシステムの例は、Ｍｏｖｅ Ｎｅｔｗｏｒｋｓ（登録商標）と、Ｍｉｃｒｏｓｏｆｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇと、Ａｐｐｌｅ ｉＰｈｏｎｅ（登録商標）Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌと、を含む。

【0044】

共通して、メディアデータの各ブロックは、個々のファイルとしてサーバ上に格納することができ、プロトコル、例えばＨＴＴＰ、は、ファイルを１つのユニットとして要求するために、サーバで実行されるＨＴＴＰサーバソフトウェアと連携して用いられる。典型的には、クライアントは、本文書では“表現”と典型的に呼ばれるメディアプレゼンテーション、例えば利用可能な符号化の特徴（例えば、要求される帯域幅、解像度、符号化パラメータ、メディアタイプ、言語）、及び、それらの符号化がブロックに分割されている方法を記述するメタデータファイルが提供され、それらは、例えば、拡張マークアップ言語（ＸＭＬ）形式又はプレイリストテキスト形式又はバイナリ形式であることができる。例えば、メタデータは、各ブロックに関するＵｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ（ＵＲＬ）を含むことができる。ＵＲＬ自体は、ドキュメント化されたリソース（ｄｏｃｕｍｅｎｔｅｄ ｒｅｓｏｕｒｃｅ）にアクセスするために用いられるプロトコルがＨＴＴＰであることを示すためにストリング“ｈｔｔｐ：／／”が先頭に添付される等の方式を提供することができる。他の例は、使用されるべきプロトコルがＦＴＰであることを示す“ｆｔｐ：／／”である。

【0045】

その他のシステムでは、例えば、メディアブロックは、要求されるメディアプレゼンテーション部分を示すクライアントからの要求に時間的に間に合う形で応答してサーバによって“オンザフライで”構築することができる。例えば、方式“ｈｔｔｐ：／／”を有するＨＴＴＰの場合は、このＵＲＬの要求の実行は、要求応答の本体全体において何らかの特定のデータを含むこの要求応答を提供する。この要求応答の生成方法に関するネットワーク内での実装は、該要求に対処するサーバの実装に依存して大きく異なることができる。

【0046】

典型的には、各ブロックは、独立して復号可能であることができる。例えば、映像メディアの場合は、各ブロックは、“シークポイント”から始まることができる。幾つかのコーディング方式では、シークポイントは、“ランダムアクセスポイント”又は“ＲＡＰ”と呼ばれるが、すべてのＲＡＰをシークポイントとして指定できるわけではない。同様に、その他のコーディング方式では、シークポイントは、Ｈ．２６４映像符号化の場合は、 “独立データリフレッシュ”フレーム、又は“ＩＤＲ”から開始するが、すべてのＩＤＲをシークポイントとして指定できるわけではない。シークポイントは、映像（又はその他の）メディアにおいて、復号器が以前のフレーム又はデータ又はサンプルに関するデータを要求することなしに復号を開始することができる位置であり、例えば、復号対象フレーム又はサンプルが、独立方式ではなく、例えば現フレームと前フレームとの間の差分として符号化された場合である。

【0047】

該システムにおける１つの懸念は、ストリームをプレイアウトするのを開始する能力、例えば、パソコンを用いて受信された音声ストリーム及び映像ストリームを復号及びレンダリングすること及びコンピュータ画面上に映像を表示して組み込まれたスピーカを通じて音声を再生すること、又は他の例として、セットトップボックスを用いて受信された音声ストリーム及び映像ストリームを復号及びレンダリングすること及びテレビ受像器に映像を表示してステレオシステムを通じて音声を再生すること、であろう。１つの主な懸念は、ユーザがストリームとして配信された新しいコンテンツを視聴することを決定してその決定を表す行動をとる、例えば、ユーザがブラウザの窓内のリンク又はリモコン装置の再生ボタンをクリックしたときと、コンテンツがユーザの画面上に表示されるのが開始するとき、以後“コンテンツザッピング時間”と呼ばれる、との間の遅延を最小にすることであろう。これらの懸念の各々は、ここにおいて説明される拡張されたシステムの要素によって対処することができる。

【0048】

コンテンツザッピングの一例は、ユーザが第１のストリームを介して配信された第１のコンテンツを視聴していて、そのユーザが第２のストリームを介して配信された第２のコンテンツを視聴することを決定し、第２のコンテンツを視聴することを開始するための行動を始めるときである。第２のストリームは、第１のストリームと同じ又は異なるサーバの組から送信することができる。コンテンツザッピングの他の例は、ユーザがウェブサイトを訪問中であり、ブラウザの窓内のリンクをクリックすることによって第１のストリームを介して配信された第１のコンテンツを視聴することを開始するのを決定したときである。同様に、ユーザは、先頭からではなくストリーム内のいずかれの時点からコンテンツを再生することを開始するのを決定することがある。ユーザは、時間位置までシークすることをそれらのクライアントデバイスに指示し、及び、ユーザは、選択された時間が瞬時にレンダリングされることを期待することができる。コンテンツザッピング時間を最小にすることは、ユーザが広範な入手可能なコンテンツを検索及びサンプリング時に高質の高速コンテンツサーフィン経験を可能にするために映像視聴にとって重要である。

【0049】

最近では、送信中のストリーミングメディアの保護のために前方誤り訂正（ＦＥＣ）コードを用いることを考慮するのが共通の慣行になってきている。インターネット及び無線ネットワーク、例えば３ＧＰＰ、３ＧＰＰ２及びＤＶＢ等の団体によって標準化されたそれら、を例として含むパケットネットワークを通じて送信されたときには、ソースストリームは、生成されるか又は入手可能になったときにパケット内に入れられ、従って、それらのパケットは、ソース又はコンテンツストリームが生成されるか又は受信機が利用可能になった順にそれを搬送するために用いることができる。

【0050】

これらの種類のシナリオへのＦＥＣコードの典型的な適用においては、符号器は、修復パケットの生成の際にＦＥＣコードを用いることができ、それらは、ソースストリームを含む原ソースパケットに加えて送信される。修復パケットは、ソースパケットの消失が生じたときに、失われたソースパケットに含まれていたデータを復元するために受信された修復パケットを用いることができるという特性を有する。修復パケットは、完全に失われた消失ソースパケットの内容を復元するために用いることができるが、完全に受信された修復パケットさらには部分的に受信された修復パケットのいずれであるかにかかわらず、部分的なパケット消失から復元するために用いることもできる。このように、完全に又は部分的に失われたソースパケットを復元するために完全に又は部分的に受信された修復パケットを用いることができる。

【0051】

さらにその他の例では、送信されたデータに関してその他のタイプの破損が発生する可能性があり、例えば、ビットの値がフリップ（反転ｆｌｉｐ）されることがあり、従って、該破損を訂正してソースパケットの可能な限り正確な復元を提供するために修復パケットを用いることができる。その他の例では、ソースストリームは、必ずしも個別のパケットで送信されず、その代わりに、例えば連続的なビットストリームとして送信することができる。

【0052】

ソースストリームの保護を提供するために用いることができる数多くのＦＥＣコード例が存在する。Ｒｅｅｄ−Ｓｏｌｏｍｏｎ（リード−ソロモン）コードは、通信システムにおける誤り及び消失訂正のためのよく知られたコードである。例えばパケットデータネットワークを通じての消失訂正に関しては、Ｒｅｅｄ−Ｓｏｌｏｍｏｎコードのよく知られた効率的な実装は、L. Rizzo、“Effective Erasure Codes for Reliable Computer Communication Protocols”（信頼できるコンピュータ通信プロトコルのための有効な消失コード）Computer Communication Review 27(2):24-36(April 1997)（以後“Ｒｉｚｚｏ”）及びBloemer, et al.,“An XOR-Based Erasure-Resilient Coding Scheme”（ＸＯＲに基づく消失弾性コーディング方式）、Technical Report TR-95-48、International Computer Science Institute, Berkeley, California(1995)（以後“ＸＯＲ−Ｒｅｅｄ−Ｓｏｌｏｍｏｎ）”又はその他の場所において説明されるＣａｕｃｈｙ（コーシー）又はＶａｎｄｅｒｍｏｎｄｅ（ファンデルモンド）行列を用いる。

【0053】

ＦＥＣコードのその他の例は、ＬＤＰＣコードと、連鎖反応コード、例えばＬｕｂｙ Ｉにおいて説明されるそれらと、多段連鎖反応コード、例えばＳｈｏｋｒｏｌｌａｈｉ Ｉにおけるそれらと、を含む。

【0054】

Ｒｅｅｄ−Ｓｏｌｏｍｏｎコードの変形のためのＦＥＣ復号化プロセスの例がＲｉｚｚｏ及びＸＯＲ−Ｒｅｅｄ−Ｓｏｌｏｍｏｎにおいて説明される。それらの例では、復号は、十分なソース及び修復データパケットが受信された後に適用することができる。復号プロセスは、計算集約的になることがあり、利用可能なＣＰＵリソースに依存して、これは、ブロック内のメディアが及ぶ時間の長さと比較して、完了するのに相当の時間を要することがある。受信機は、メディアストリームの受信開始とメディアのプレイアウトとの間で要求される遅延を計算するときに復号のために要するこの時間の長さを考慮に入れることができる。復号に起因するこの遅延は、ユーザによる特定のメディアストリーム要求と再生開始との間の遅延としてユーザによって実感される。従って、この遅延を最小にすることが望ましい。

【0055】

多くの用途においては、パケットは、ＦＥＣプロセスが適用されるシンボルにさらに細分することができる。パケットは、１つ以上のシンボルを含むことができ（又は１つよりも少ないシンボルを含むことができるが、通常は、シンボルは、パケットのグループ間での誤り状態が高い相関関係を有することが知られていない限りパケットのグループ間で分割されない）。シンボルは、あらゆるサイズを有することができるが、しばしば、シンボルのサイズは、最大でもパケットのサイズと等しい。ソースシンボルは、送信されるデータを符号化するシンボルである。修復シンボルは、ソースシンボルに加えての、直接的に又は間接的にソースシンボルから生成されたシンボルである（すなわち、送信されるデータは、全ソースシンボルを利用可能であり及び修復シンボルをまったく利用可能でない場合に完全に復元可能である。

【0056】

幾つかのＦＥＣコードは、符号化動作がブロック内に存在するシンボルに依存し、そのブロック内に存在しないシンボルから独立していることができるという点でブロックに基づくことができる。ブロックに基づく符号化を用いることで、ＦＥＣ符号器は、ブロック内のソースシンボルからそのブロックのための修復シンボルを生成し、その後に次のブロックに進むことができ、符号化対象となっている現在のブロックのためのソースシンボル以外のそれらを参照する必要がない。送信の際には、ソースシンボルを備えるソースブロックは、（幾つかのソースシンボル、幾つかの修復シンボル、又は両方であることができる）符号化されたシンボルを備える符号化されたブロックによって表すことができる。修復シンボルが存在することで、すべての符号化されたブロックにおいてすべてのソースシンボルが要求されるわけではない。

【0057】

幾つかのＦＥＣコード、特にＲｅｅｄ−Ｓｏｌｏｍｏｎコード、に関しては、符号化及び復号時間は、１つのソースブロック当たりの符号化されたシンボルの数が増加するのに従って増大して非現実的になることがある。従って、実際上は、特にＲｅｅｄ−Ｓｏｌｏｍｏｎ符号化又は復号プロセスがカスタムハードウェアによって行われる典型的な事例においては、１つのソースブロックごとに生成することができる符号化されたシンボルの総数に関して現実的な上限がしばしば存在し（幾つかの用途に関しては２５５がほぼ現実的な限度である）、例えば、パケット消失に対してストリームを保護するためにＤＶＢ−Ｈ規格の一部として含められているＲｅｅｄ−Ｓｏｌｏｍｏｎコードを用いるＭＰＥ−ＦＥＣプロセスは、１つのソースブロック当たり２５５のＲｅｅｄ−Ｓｏｌｏｍｏｎ総符号化シンボルに制限されている携帯電話内の専用ハードウェア内に実装される。シンボルは別々のパケットペイロード内に入れることがしばしば要求されるため、これは、符号化対象となるソースブロックの最大長に対して現実的な上限を設ける。例えば、パケットペイロードが１０２４バイト以下に制限されており及び各パケットが１つの符号化されたシンボルを搬送する場合は、符号化されたソースブロックは、最大で２５５キロバイトであることができ、これは、当然のことであるが、ソースブロック自体のサイズの上限でもある。

【0058】

その他の懸念、例えばソースストリーミングレートと歩調を合わせることができる速度でソースブロックを復号可能である、ＦＥＣ復号によって導入される復号レーテンシーを最小にすることが可能である、ＦＥＣ復号中のいずれの時点においても受信デバイスの利用可能なＣＰＵの小さい一部分のみを使用可能である、は、ここにおいて説明される要素によって対処される。

【0059】

システムのコンポーネントが受信機に配信されるストリームの品質に悪影響を及ぼさずに不具合になることを可能にするロバストでスケーラブルなストリーミング配信解決方法を提供する必要性。

【0060】

ブロック要求ストリーミングシステムは、プレゼンテーションの構造又はメタデータの変更、例えば、利用可能なメディア符号化の数の変更又はメディア符号化のパラメータ、例えばビットレート、解像度、アスペクト比、音声又は映像コーデック又はコーデックパラメータの変更又はコンテンツファイルと関連付けられたその他のメタデータ、例えばＵＲＬ、の変更、をサポートする必要がある。該変更は、より大きいプレゼンテーションのアドバタイジングセグメント又は異なるセグメント、等の異なるソースからのコンテンツの一括編集、ＵＲＬ又は例えば構成変更、装置の故障又は装置の故障からの回復又はその他の理由に起因するサービングインフラストラクチャの変更結果として必要になるＵＲＬ又はその他のパラメータの修正、を含む幾つかの理由で要求されることがある。

【0061】

連続的に更新されたプレイリストファイルによってプレゼンテーションを制御することができる方法が存在する。このファイルは、連続的に更新されるため、上述される変更の少なくとも一部は、これらの更新内で行うことができる。従来の方法の欠点は、クライアントデバイスがプレイリストファイルを連続的に検索し、“ポーリング”とも呼ばれる、サービングインフラストラクチャに対して負荷をかけること、及び、このファイルは、更新間隔よりも長くキャッシングすることできず、サービングインフラストラクチャにとっての仕事をはるかに困難にすることである。これは、ここにおける要素によって対処されており、このため、上述される種類の更新は、メタデータファイルに関するクライアントによる継続的なポーリングの必要性なしに提供される。

【0062】

特にライブサービスにおける他の問題は、典型的には放送配信からの既知の問題であり、ユーザが番組に加わった時間よりも前に放送されているコンテンツをユーザが視聴することができないことである。典型的には、ローカルでの個人的な録画は不必要なローカルストレージを消費するか又はクライアントが番組に同調されなかったか又はコンテンツ保護規則によって禁止されているため可能でない。ネットワークの録画及び時間シフト視聴が好ましいが、サーバへのユーザの個々のコネクション及びライブサービス以外の別個の配信プロトコル及びインフラストラクチャを要求し、その結果、重複するインフラストラクチャ及び有意なサーバコストが生じる。これも、ここにおいて説明される要素によって対処される。

【0063】

システム概要
本発明の一実施形態が図１を参照して説明され、それは、本発明を具現化したブロック−要求ストリーミングシステムの簡略化された図を示す。

【0064】

図１において、ブロック−ストリーミングシステム１００が例示され、ブロックサービングインフラストラクチャ（“ＢＳＩ”）１０１を備え、それは、コンテンツ１０２を取り込み、そのコンテンツを準備し、及び、取り込みシステム１０３及びＨＴＴＰストリーミングサーバ１０４の両方がアクセス可能なコンテンツストア１１０内にそれを格納することによってＨＰＰＴストリーミングサーバ１０４によるサービスのためにそれをパッケージングするための取り込みシステム１０３を備える。示されるように、システム１００は、ＨＴＴＰキャッシュ１０６も含むことができる。動作上は、クライアント１０８、例えばＨＴＴＰストリーミングクライアント、は、ＨＴＴＰストリーミングサーバ１０４に要求１１２を送信し、ＨＴＴＰストリーミングサーバ１０４又はＨＴＴＰキャッシュ１０６から応答１１４を受信する。各場合において、図１に示される要素は、少なくとも部分的には、プロセッサ又はその他の電子機器において実行されるプログラムコードを備えるソフトウェア内に実装することができる。

【0065】

コンテンツは、ムービー、音声、２Ｄ平面映像、３Ｄ映像、その他の種類の映像、画像、時間が定められたテキスト、時間が定められたメタデータ、等を備えることができる。あるコンテンツは、時間が定められた方式で提示又は消費される予定のデータ、例えば補助情報（例えば、放送局識別、広告、株価、Ｆｌａｓｈ（登録商標）シーケンス、等）をプレイアウト対象となるその他のメディアとともに提示するためのデータ、を含むことができる。その他のメディアを組み合わせるか及び／又は単なる音声と映像を上回るその他のハイブリッドプレゼンテーションも使用可能である。

【0066】

図２に例示されるように、メディアブロックは、ブロックサービングインフラストラクチャ１０１（１）内に格納することができ、それは、例えば、ＨＴＴＰサーバ、コンテンツデリバリネットワークデバイス、ＨＴＴＰプロキシ、ＦＴＰプロキシ又はサーバ、又は何らかのその他のメディアサーバ又はシステムであることができる。ブロックサービングインフラストラクチャ１０１（１）は、ネットワーク１２２に接続され、それは、例えば、インターネット等のインターネットプロトコル（“ＩＰ”）ネットワークであることができる。上述されるメタデータを備え、メタデータによって示される複数の利用可能なブロックの中から要求されるブロック又は部分的ブロックを選択する機能を果たす６つの機能上のコンポーネント、すなわちブロック選択器１２３、ブロック選択器１２３から要求命令を受信し、ネットワーク１２２を通じてブロックサービングインフラストラクチャ１０１（１）に指定されたブロック、1つのブロックの一部分、又は複数のブロックの要求を送信するために及び見返りにブロックを備えるデータを受信するために必要な動作を行うブロック要求器１２４、ブロックバッファ１２５、バッファモニタ１２６、メディア復号器１２７及びメディア消費を容易にする１つ以上のメディア変換器１２８、を有するブロック−要求ストリーミングシステムクライアントが示される。

【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】

一実施形態においては、セグメント及びＧｏＰは、異なるレートのストリームにわたって整合させることができる。この実施形態においては、ＧｏＰは、可変サイズであることができ及び複数のセグメントを含むことができるが、フラグメントは、異なるレートのストリーム間で整合されない。

【0098】

幾つかの実施形態においては、ファイル冗長性を有利に用いることができる。これらの実施形態においては、データの冗長なバージョンを生成するために消失コードが各セグメントに適用される。好ましくは、ソースのフォーマット化はＦＥＣの使用法に起因して変更されず、例えば、原表現の従属した表現として、ＦＥＣ修復データを含む追加の修復セグメントが生成され、取り込みシステム内での追加ステップとして利用可能にされる。クライアントは、フラグメントのためのソースデータのみを用いてそのフラグメントを再構築することができ、サーバに対してセグメント内のフラグメントのためのソースデータのみを要求するだけでよい。サーバが利用不能であるか又はサーバへのコネクションが遅い場合は、それは、ソースデータ要求前又は後に決定することができ、修復セグメントからのフラグメントのために追加の修復データを要求することができ、それは、おそらくフラグメントのソースデータを復元するために受信されたソースデータと修復データの組み合わせを用いるためのＦＥＣ符号化を用いることで、フラグメントを復元するための十分なデータを信頼できる形で配信するための時間を短縮する。さらに、フラグメントが緊急になった、すなわち、それのプレイアウト時間が迫っている、場合にフラグメントの復元を可能にするために追加の修復データを要求することができ、それは、リンク上でのそのフラグメントに関するデータの割合を増大させるが、帯域幅を解放するためにリンク上のその他のコネクションを閉じるよりも効率的である。これは、並行なコネクションの使用による枯渇リスクを軽減することもできる。

【0099】

フラグメント形式は、リアルタイム転送制御プロトコルＲＴＣＰを通じて音声／映像同期化が達成されるリアルタイム転送プロトコル（ＲＰＴ）パケットの格納されたストリームであることができる。

【0100】

セグメント形式は、音声／映像同期化によって達成されたＭＰＥＧ−２ ＴＳ内部タイミングを有するＭＰＥＧ−２ ＴＳパケットの格納されたストリームであることもできる。

【0101】

ストリーミングをより効率的にするためのシグナリングの使用及び／又はブロック生成 ブロック−要求ストリーミングシステムでは、向上された性能を提供するために、幾つかの特徴を用いることができ又は用いることができない。性能は、停止なしでプレゼンテーションをプレイアウトする能力、帯域幅に関する制約内でのメディアデータの入手、及び／又はクライアント、サーバ及び／又は取り込みシステムにおいて限られたプロセッサリソースの範囲内でそうすることに関連することができる。今度はこれらの特徴の一部が説明される。

【0102】

セグメント内でのインデキシング
ムービーフラグメントに関する部分的ＧＥＴ要求を編成するために、復号の際のバイトオフセット及び開始時間又はファイル又はセグメント内のフラグメントに含まれる全メディアコンポーネントの提示時間及びいずれのフラグメントが開始するか又はいずれのフラグメントがランダムアクセスポイントを含むか（そのため代替表現間の切り換えポイントとして用いるのに適するか）をクライアントに連絡することができ、この情報は、セグメントインデキシング又はセグメントマップとしばしば呼ばれる。復号の際の開始時間又は提示時間は、直接表すことができ又は基準時間に対するデルタとして表すことができる。

【0103】

この時間及びバイトオフセットインデキシング情報は、１つのムービーフラグメント当たり少なくとも８バイトのデータを要求することができる。一例として、単一のファイルに含まれていて５００ｍｓのムービーフラグメントを有する２時間の映画に関しては、これは、合計で約１１２キロバイトのデータになる。提示を開始するときにこのデータをすべてダウンロードすることは、その結果として、有意な追加の立ち上がり遅延が生じることがある。しかしながら、時間及びバイトオフセットデータは、階層的に符号化することができ、このため、クライアントは、それが開始することを希望するプレゼンテーション内のポイントに該当する少量の時間及びオフセットデータを素早く見つけ出すことができる。情報は、セグメントインデックスの何らかの改良をメディアデータとインターリービングされた形で配置できるようにセグメント内に分散させることもできる。

【0104】

表現が時間の点で複数のセグメントにセグメント化されている場合は、各セグメントのための完全な時間及びオフセットデータは既にかなり少量であることがあるため、この階層的符号化の使用は必要ないことがあることに注目すること。例えば、上例においてセグメントが２時間ではなく１分である場合は、時間−バイトオフセットインデキシング情報は、約１キロバイトのデータであり、それは、典型的には、単一のＴＣＰ／ＩＰパケット内に納まることができる。

【0105】

フラグメント時間及びバイトオフセットデータを３ＧＰＰファイルに追加するために異なる選択肢が可能である。

【0106】

第１に、ムービーフラグメントランダムアクセスボックス（Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｂｏｘ）（“ＭＦＲＡ”）をこの目的のために用いることができる。ＭＦＲＡは、テーブルを提供し、それは、読者がムービーフラグメントを用いてファイル内のランダムアクセスポイントを見つけるのを援助することができる。この機能を支援するために、ＭＦＲＡは、ランダムアクセスポイントを含むＭＦＲＡボックスのバイトオフセットを付随的に含む。ＭＦＲＡは、ファイルの最後に又は最後の近くに配置することができるが、これは必ずしも該当しない。ムービーフラグメントランダムアクセスオフセットボックスを見つけるためにファイルの最後から走査し及びその中のサイズ情報を用いることによって、ムービーフラグメントランダムアクセスオフセットボックスの始めを探し出すことができる。しかしながら、ＨＴＴＰストリーミングのためにＭＦＲＡを最後に置くことは、希望されるデータにアクセスするために典型的には少なくとも３乃至４回のＨＴＴＰ要求、すなわち、ファイルの最後からＭＦＲＡを要求するための少なくとも１回、ＭＦＲＡを入手するための１回及び最後にファイル内の希望されるフラグメントを入手するための１回、を要求する。従って、始めに置くことは、単一の要求においてｍｆｒａを第１のメディアデータとともにダウンロードすることができるため望ましいであろう。同じく、時間及びｍｏｏｆ＿ｏｆｆｓｅｔ以外は“ＭＦＲＡ”内のいずれの情報も不要であるためＨＴＴＰストリーミングのためにＭＦＲＡを用いることは非効率的であることがあり、及び、長さの代わりにオフセットを指定することは、より多くのビットを要求することがある。

【0107】

第２に、項目場所特定ボックス（Ｉｔｅｍ Ｌｏｃａｔｉｏｎ Ｂｏｘ）（“ＩＬＯＣ”）を用いることができる。“ＩＬＯＣ”は、この又はその他のファイル内のメタデータリソースを含有するファイルの場所を特定することによるそれらのメタデータリソース、そのファイル内でのそれらのオフセット、及びそれらの長さのディレクトリを提供する。例えば、システムは、すべての外部で参照されたメタデータリソースを１つのファイル内に統合し、ファイルオフセット及びファイル参照を適宜再調整することができる。しかしながら、“ＩＬＯＣ”は、メタデータの所在場所を与えることが意図されており、このため、これがリアルなメタデータと共存するのは難しいことがある。

【0108】

最後に、そしておそらく最も適切なことは、正確なフラグメント時間又は継続時間及びバイトオフセットを効率的な方法で提供することを専用とする時間インデックスボックス（Ｔｉｍｅ Ｉｎｄｅｘ Ｂｏｘ）（“ＴＩＤＸ”）と呼ばれる新しいボックスの指定である。これは、次節においてさらに詳細に説明される。同じ機能を有する代替ボックスは、セグメントインデックスボックス（“ＳＩＤＸ”）であろう。ここにおいて、別記されない限り、両方のボックスは正確なフラグメント時間又は継続時間及びバイトオフセットを効率的な方法で提供する能力を提供するため、これらの２つは互換可能である。ＴＩＤＸとＳＩＤＸとの間の相違点が以下において提供される。ＴＩＤＸボックス及びＳＩＤＸボックスの両方がセグメントインデックスを実装するため、両方のボックスの互換方法は明確なはずである。

【0109】

セグメントインデキシング
セグメントは、特定された開始時間及び特定されたバイト数を有する。複数のフラグメントを連結して単一のセグメントにすることができ、クライアントは、要求されたフラグメント又はフラグメントの部分組に対応するセグメント内の特定のバイト範囲を特定する要求を出すことができる。例えば、ＨＴＴＰが要求プロトコルとして用いられるときには、ＨＴＴＰ範囲ヘッダをこの目的のために用いることができる。この手法は、クライアントが異なるフラグメントのセグメント内での位置を指定するセグメントの“セグメントインデックス”へのアクセスを有することを要求する。この“セグメントインデックス”は、メタデータの一部として提供することができる。この手法は、すべてのブロックが別々のファイル内において維持される手法と比較してはるかに少ない数のファイルを生成及び管理する必要があるという結果を有する。（例えば、１時間のプレゼンテーションの場合は何千にも及ぶ可能性がある）非常に大量のファイルの生成、転送及び格納の管理は複雑でかつ誤りを犯しやすい可能性があり、このため、ファイル数の減少は１つの利点を表す。

【0110】

クライアントがセグメントのより小さい部分の希望される開始時間しか知らない場合は、それは、該当するプレイアウト開始場所を決定するためにファイル全体を要求してファイル全体を読み通すことができる。帯域幅の使用を改良するために、セグメントは、インデックスファイルをメタデータとして含むことができ、インデックスファイルは、ブロックが対応する時間範囲と個々のブロックのバイト範囲をマッピングし、セグメントインデキシング又はセグメントマップと呼ばれる。このメタデータは、ＸＭＬデータとしてフォーマット化することができ、又は、それらは、バイナリであることができ、例えば３ＧＰＰファイル形式のアトム（ａｔｏｍ）及びボックス構造に従う。インデキシングは単純であることができ、各ブロックの時間及びバイト範囲は、ファイルの始めに関して絶対的であり、又は、それらは階層的であることができ、幾つかのブロックは、親ブロックに（及び祖父ブロック、等に）グループ分けすることができ、所定のブロックのための時間及びバイト範囲は、そのブロックの親ブロックの時間及び／又はバイト範囲に関して表される。

【0111】

インデキシングマップ構造例
一実施形態においては、メディアストリームの１つの表現のための原ソースデータは、 “メディアセグメント”とここで呼ばれる１つ以上のメディアファイルに入れることができ、各メディアセグメントは、メディアの連続的時間セグメント、例えば、メディア再生の５分間、を再生するために用いられるメディアデータを含む。

【0112】

図６は、メディアセグメントの全体的構造例を示す。各セグメント内において、始めに又はソースセグメント全体に分散して、時間／バイトオフセットセグメントマップを備えるインデキシング情報が存在することもできる。一実施形態における時間／バイト−オフセットセグメントマップは、時間／バイト−オフセット対（Ｔ（０）、Ｂ（０））、（Ｔ（１）、Ｂ（１））、．．．、（Ｔ（ｉ）、Ｂ（ｉ）、．．．、（Ｔ（ｎ）、Ｂ（ｎ））のリストであることができ、Ｔ（ｉ−１）は、全メディアセグメントにおけるメディアの最初の開始時間に対するメディアのｉ番目のフラグメントの再生のためのセグメント内の開始時間を表し、Ｔ（ｉ）は、ｉ番目のフラグメントにとっての終了時間（従って、次のフラグメントにとっての開始時間）を表し、バイト−オフセットＢ（ｉ−１）は、このソースセグメント内でのデータの始めの対応するバイトインデックスであり、ここで、メディアのｉ番目のフラグメントは、ソースセグメントの始めに関して開始し、Ｂ（ｉ）は、ｉ番目のフラグメントの対応する最後のバイトインデックス（従って、次のフラグメントの最初のバイトのインデックス）である。セグメントが複数のメディアコンポーネントを含む場合は、Ｔ（ｉ）及びＢ（ｉ）は、絶対的な形でセグメント内の各コンポーネントのために提供することができ又はそれらは基準メディアコンポーネントに対処する他のメディアコンポーネントに関して表すことができる。

【0113】

この実施形態においては、ソースセグメント内のフラグメントの数はｎであり、ここでは、ｎは、セグメントごとに変化することができる。

【0114】

他の実施形態においては、各フラグメントのためのセグメントインデックス内での時間オフセットは、第１のフラグメントの絶対的開始時間及び各フラグメントの継続時間を用いて決定することができる。この事例においては、セグメントインデックスは、第１のフラグメントの開始時間及びセグメントに含まれる全フラグメントの継続時間をドキュメント化することができる。セグメントインデックスは、同じくフラグメントの部分組のみをドキュメント化することもできる。その事例において、セグメントインデックスは、含有しているセグメントの最後において又は次のサブセグメントの最初において、１つ以上の連続するフラグメントであると定義されるサブセグメントの継続時間をドキュメント化する。

【0115】

各フラグメントに関して、そのフラグメントが、シークポイント、すなわち、あるポイントよりも後のいずれのメディアもそのポイントよりも前のいずれのメディアにも依存しておらず、従って、そのフラグメントから前方のメディアは以前のフラグメントから独立してプレイアウトすることができるそのポイント、において開始するか又はそのポイントを含むかどうかを示す値も存在することができる。シークポイントは、概して、プレイアウトがすべての前のメディアから独立して開始することができるメディア内のポイントである。図６は、ソースセグメントのための可能なセグメントインデキシングの単純な例も示す。その例において、時間オフセット値は、単位がミリ秒であり、従って、このソースセグメントの第１のフラグメントは、メディアの始めから２０秒後に開始し、第１のフラグメントは、４８５ミリ秒のプレイアウト時間を有する。第１のフラグメントの始めバイトオフセットは０であり、第１のフラグメントの終わり／第２のフラグメントの始めのバイトオフセットは、５０，２４５であり、従って、第１のフラグメントのサイズは５０，２４５バイトである。フラグメント又はサブセグメントがランダムアクセスポイントから開始せず、ランダムアクセスポイントがフラグメント又はサブセグメント内に含まれている場合は、開始時間と実際のＲＡＰ時間との間の復号時間又は提示時間差を与えることができる。これは、このメディアセグメントに切り換わる場合に、クライアントが表現からの切り換えを提示することが必要になるまでの時間を正確に知ることができることを可能にする。

【0116】

単純な又は階層的なインデキシングに加えて又は単純な又は階層的なインデキシングの代わりに、デイジーチェーン式（ｄａｉｓｙ−ｃｈａｉｎｅｄ）インデキシング及び／又はハイブリッドインデキシングを用いることが可能である。

【0117】

異なるトラックに関するサンプル継続時間は同じでないことができる（例えば、映像サンプルは３３ｍｓ間表示することができ、音声サンプルは８０ｍｓ続くことができる）ため、ムービーフラグメント内の異なるトラックはまったく同時に開始しないこと及び終了しないことができ、すなわち、音声は、補償するために、映像よりもわずかに前に又はわずかに後に開始することができ、先行フラグメントに関しては逆も真である。曖昧さを回避するために、時間及びバイトオフセットデータ内で指定されているタイムスタンプは、特定のトラックに関して指定することができ、これは、各表現に関して同じトラックであることができる。通常は、これは、映像トラックである。これは、クライアントが表現を切り換え中に次の映像フレームを正確に識別することを可能にする。

【0118】

上記の課題にもかかわらずスムーズなプレイアウト及び音声／映像の同期化の維持を確保するために、提示中にトラックタイムスケールと提示時間との間の厳格な関係を維持するように注意することができる。

【0119】

図７は、幾つかの例、例えば単純なインデックス７００及び階層的インデックス７０２を例示する。

【0120】

セグメントマップを含むボックスの２つの具体例が以下に提供され、１つは時間インデックスボックス（‘ＴＩＤＸ’）と呼ばれ、１つは（‘ＳＩＤＸ’）と呼ばれる。定義は、ＩＳＯベースメディアファイル形式によるボックス構造に準じる。同様の構文を定義し及び同じ意味論と機能を有する該ボックスに関するその他の設計が読者にとって明確であるはずである。

【0121】

時間インデックスボックス定義ボックスタイプ： ‘ｔｉｄｘ’コンテナ： ファイル強制： なし数量： あらゆる数のゼロ又は１
時間インデックスボックスは、ファイルの一定の領域をプレゼンテーションの一定の時間間隔と関連付ける時間及びバイトオフセットインデックスの組を提供することができる。時間インデックスボックスは、参照されたデータのタイプを示すターゲットタイプ（ｔａｒｇｅｔｔｙｐｅ）フィールドを含むことができる。例えば、ターゲットタイプ“ｍｏｏｆ”を有する時間インデックスボックスは、時間及びバイトオフセットの両方に関してファイルに含まれているメディアフラグメントを示すインデックスを提供する。時間インデックスボックスのターゲットタイプを有する時間インデックスボックスは、階層的時間インデックスを構築するために用いることができ、ファイルのユーザがインデックスの要求される部分に素早くナビゲートするのを可能にする。

【0122】

セグメントインデックスは、次の構文を例えば含むことができる。

【0123】

aligned(8) class TimeIndexBoxextends FullBox(‘frai’) {unsigned int(32)targettype;
unsigned int(32) time_reference_track_ID; unsigned int(32) number_of_elements; unsigned int(64) first_element_offset; unsigned int(64) first_element_time; for(i=1; i<=number_of_elements; i++){bit(1) random_access_flag; unsigned int(31) length; unsigned int(32) deltaT; }}意味論
ｔａｒｇｅｔｔｙｐｅ：この時間インデックスボックスによって参照されるボックスデータのタイプである。これは、ムービーフラグメントヘッダ（“ｍｏｏｆ”）又は時間インデックスボックス（“ｔｉｄｘ”）のいずれかであることができる。

【0124】

ｔｉｍｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋ＿ｉｄ：このインデックス内の時間オフセットが指定されるトラックを示す。

【0125】

ｎｕｍｂｅｒ＿ｏｆ＿ｅｌｅｍｅｎｔｓ：この時間インデックスボックスによってインデキシングされた要素の数。

【0126】

ｆｉｒｓｔ＿ｅｌｅｍｅｎｔ＿ｏｆｆｓｅｔ：第１のインデキシングされた要素のファイルの始めからのバイトオフセット。

【0127】

ｆｉｒｓｔ＿ｅｌｅｍｅｎｔ＿ｔｉｍｅ：第１のインデキシングされた要素の開始時間で、ｔｉｍｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋ＿ｉｄによって識別されたトラックのメディアヘッダボックス内で指定されたタイムスケールを用いる。

【0128】

ｒａｎｄｏｍ＿ａｃｃｅｓｓ＿ｆｌａｇ：要素の開始時間がランダムアクセスポイントである場合は１。そうでない場合はゼロ。

【0129】

ｌｅｎｇｔｈ：インデキシングされた要素の長さで、単位はバイト。

【0130】

ｄｅｌｔａＴ：この要素の開始時間と次の要素の開始時間との間のｔｉｍｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋ＿ｉｄによって識別されたトラックのメディアヘッダボックス内で指定されたタイムスケールに関する差分。

【0131】

セグメントインデックスボックス
セグメントインデックスボックス（‘ｓｉｄｘ’）は、セグメント内のムービーフラグメント及びその他のセグメントインデックスボックスのコンパクトなインデックスを提供する。セグメントインデックスボックス内には２つのループ構造が存在する。第１のループは、サブセグメントの第１のサンプル、すなわち、第２のループによって参照される第１のムービーフラグメント内のサンプル、をドキュメント化する。第２のループは、サブセグメントのインデックスを提供する。‘ｓｉｄｘ’ボックスのためのコンテナは、ファイル又は直接セグメントである。

【0132】

構文aligned(8) class SegmentIndexBox extends FullBox(‘sidx’,version,0){
unsigned int(32) reference_track_ID;
unsigned int(16) track_count;
unsigned int(16) reference_count;
for (i=1; i<=track_count; i++)
{
unsigned int(32) track_ID;
if (version==0)
{
unsigned int(32) decoding_time;
} else
{
}unsigned int(64) decoding_time; }}for(i=1; i<=reference_count; i++){
bit(1) reference_type;
unsigned int(31) reference_offset;
unsigned int(32) subsegment_duration;
bit(1) contains_RAP
unsigned int(31) RAP_delta_time;
}}意味論
ｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋ＿ＩＤは、基準トラックに関するｔｒａｃｋ＿ＩＤを提供する。

【0133】

ｔｒａｃｋ＿ｃｏｕｎｔ：後続するループ内のインデキシングされたトラックの数（１以上）
ｒｅｆｅｒｅｎｃｅ＿ｃｏｕｎｔ：第２のループによってインデキシングされた要素の数（１以上）
ｔｒａｃｋ＿ＩＤ：トラックフラグメントがこのインデックスによって識別された第１のムービーフラグメントに含められているトラックのＩＤ。このループ内の正確に１つのｔｒａｃｋ＿ＩＤがｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋ＿ＩＤに等しい
ｄｅｃｏｄｉｎｇ＿ｔｉｍｅ：第２のループ内の第１の項目によって参照されるムービーフラグメント内のｔｒａｃｋ＿ＩＤによって識別されたトラック内の第１のサンプルに関する復号時間であり、（トラックのメディアヘッダボックスのタイムスケールフィールド内でドキュメント化された）トラックのタイムスケールで表される。

【0134】

ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅ：０に設定されたときは、ムービーフラグメント（‘ｍｏｏｆ’）ボックスを参照することを示し、１に設定されたときは、セグメントインデックス（‘ｓｉｄｘ’）ボックスを参照することを示す。

【0135】

ｒｅｆｅｒｅｎｃｅ＿ｏｆｆｓｅｔ：含有するセグメントインデックスボックスに後続する第１のバイトから参照されたボックスの第１のバイトまでの単位がバイトの距離
ｓｕｂｓｅｇｍｅｎｔ＿ｄｕｒａｔｉｏｎ：セグメントインデックスボックスを参照するときには、このフィールドは、そのボックスの第２のループ内のｓｕｂｓｅｇｍｅｎｔ＿ｄｕｒａｔｉｏｎフィールドの合計を有し、ムービーフラグメントを参照するときには、このフィールドは、示されたムービーフラグメント及びループ内の次のエントリによってドキュメント化された第１のムービーフラグメント、又はサブセグメントの最後のうちのいずれか早い方までの後続するムービーフラグメント内において、基準トラック内のサンプルのサンプル継続時間の合計を有する。継続時間は、（トラックのメディアヘッダボックスのタイムスケールフィールド内でドキュメント化された）トラックのタイムスケールで表される。

【0136】

ｃｏｎｔａｉｎｓ＿ＲＡＰ：ムービーフラグメントが参照されるときには、このビットは、ｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋ＿ＩＤに等しいｔａｃｋ＿ＩＤを有するトラックのためのそのムービーフラグメント内のトラックフラグメントが少なくとも１つのランダムアクセスポイントを含む場合は１であり、そうでない場合はこのビットは０に設定される。セグメントインデックスが参照されるときには、このビットは、そのセグメントインデックス内の参照のうちのいずれかが１に設定されたこのビットを有する場合のみに１に設定され、そうでない場合は０に設定される。

【0137】

ＲＡＰ＿ｄｅｌｔａ＿ｔｉｍｅ：ｃｏｎｔａｉｎｓ＿ＲＡＰが１である場合は、ランダムアクセスポイント（ＲＡＰ）の提示（コンポジションｃｏｍｐｏｓｉｔｉｏｎ）時間を提供し、ｃｏｎｔａｉｎｓ＿ＲＡＰが０である場合は、値０で予約される。時間は、ｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋ＿ＩＤに等しいｔａｃｋ＿ＩＤを有するトラック内において、このエントリによってドキュメント化されたサブセグメントの第１のサンプルの復号時間とランダムアクセスポイントの提示（コンポジション）時間との間の差分として表される。

【0138】

ＴＩＤＸとＳＩＤＸとの間の相違点
ＳＩＤＸ及びＳＩＤＸは、インデキシングに関しては同じ機能を提供する。ＳＩＤＸの第１のループは、第１のムービーフラグメントのためのグローバルタイミングをさらに提供するが、グローバルタイミングは、ムービーフラグメント自体内に含めることもでき、参照トラックに関して絶対的又は相対的である。

【0139】

ＳＩＤＸの第２のループは、ＴＩＤＸの機能を実装する。具体的には、ＳＩＤＸは、ｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅによって参照された各インデックスのための参照のためのターゲットの混合を有することを可能にし、他方、ＴＩＤＸは、ＴＩＤＸのみ又はＭＯＯＦのみのいずれかを参照するだけである。ＴＩＤＸ内のｎｕｍｂｅｒ＿ｏｆ＿ｅｌｅｍｅｎｔｓは、ＳＩＤＸ内のｒｅｆｅｒｅｎｃｅ＿ｃｏｕｎｔに対応し、ＴＩＤＸ内のｔｉｍｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋ＿ｉｄは、ＳＩＤＸ内のｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋ＿ＩＤに対応し、ＴＩＤＸ内のｔｆｉｒｓｔ＿ｅｌｅｍｅｎｔ＿ｏｆｆｓｅｔは、第２のループの第１のエントリ内のｒｅｆｅｒｅｎｃｅ＿ｏｆｆｓｅｔに対応し、ＴＩＤＸ内のｆｉｒｓｔ＿ｅｌｅｍｅｎｔ＿ｔｉｍｅは、第１のループ内のｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋのｄｅｃｏｄｉｎｇ＿ｔｉｍｅに対応し、ＴＩＤＸ内のｒａｎｄｏｍ＿ａｃｃｅｓｓ＿ｆｌａｇは、ＳＩＤＸ内のｃｏｎｔａｉｎｓ＿ＲＡＰに対応し、ＳＩＤＸ内ではＲＡＰは必ずしもフラグメントの始めに配置する必要がないという追加の自由を有し、従ってＲＡＰ＿ｄｅｌｔａ＿ｔｉｍｅを要求し、ＴＩＤＸ内の長さは、ＳＩＤＸ内のｒｅｆｅｒｅｎｃｅ＿ｏｆｆｓｅｔに対応し、最後に、ＴＩＤＸ内のｄｅｌｔａＴは、ＳＩＤＸ内のｓｕｂｓｅｇｍｅｎｔ＿ｄｕｒａｔｉｏｎに対応する。従って、２つのボックスの機能は同等である。

【0140】

可変ブロックサイズ設定及びサブＧｏＰブロック
映像メディアに関しては、要求のための映像符号化構造とブロック構造との間の関係が重要であることができる。例えば、各ブロックがシートポイント、例えば、ランダムアクセスポイント（“ＲＡＰ”）、から開始し、各ブロックが映像時間の等しい期間を表す場合は、映像メディアでの少なくとも幾つかのシークポイントの配置は固定されており、シークポイントは、映像符号化内において一定の間隔で生じる。映像符号化の当業者によってよく知られるように、シークポイントが映像フレーム間の関係によって配置されている場合、特に、以前のフレームとの共通点をほとんど有さないフレームにおいてそれらが配置される場合は、圧縮効率を向上させることができる。このように、ブロックは等しい時間量を表すというこの要求は、映像符号化に対して制約を課し、このため、圧縮が最適でないことがある。

【0141】

固定された位置のシークポイントを要求するのではなく、映像プレゼンテーション内のシークポイントの位置を映像符号化システムによって選択可能であるようにするのが望ましい。映像符号化システムがシークポイントを選択するのを可能にすることは、その結果、向上された映像圧縮が得られ、このため、所定の利用可能な帯域幅を用いてより高い品質の映像メディアを提供することができ、その結果、向上されたユーザ経験が得られる。現在のブロック−要求ストリーミングシステムは、全ブロックが同じ継続時間（映像時間）であること、及び、各ブロックがシークポイントから開始しなければならないことを要求することができ、これは、既存のシステムの欠点である。

【0142】

上記よりも有利な点を提供する新規のブロック−要求ストリーミングシステムが今度は説明される。一実施形態においては、映像コンポーネントの第１のバージョンの映像符号化プロセスは、圧縮効率を最適化するためにシークポイントの配置を選択するように構成することができるが、シークポイント間の継続時間に関する最大値が存在することが要求される。この後者の要求事項は、符号化プロセスによるシークポイントの選択を確実に制約し、従って、圧縮効率を低下させる。しかしながら、圧縮効率の低下は、シークポイント間の継続時間の最大値が小さすぎない（例えば、約１秒よりも大きい）ことを条件として、シークポイントに関して一定の固定された位置が要求される場合に被るそれと比較して小さい。さらに、シークポイント間の継続時間の最大値が数秒である場合は、完全に自由なシークポイントの配置と比較した圧縮効率の低下は概して非常に小さい。

【0143】

この実施形態を含む多くの実施形態において、幾つかのＲＡＰはシークポイントでないことができ、例えば、ＲＡＰが周囲のシークポイントに時間的に近すぎることに起因して、又は、ＲＡＰに先行又は後続するシークポイントとＲＡＰとの間のメディアデータ量が小さすぎることに起因して、シークポイントとして選択されない２つの連続するシークポイント間のＲＡＰであるフレームが存在することができる。

【0144】

メディアプレゼンテーションのすべてのその他のバージョン内におけるシークポイントの位置は、第１の（例えば、最高のメディアデータレートの）バージョンと同じであるように制約することができる。これは、符号器によるシークポイントの自由な選択を可能にすることと比較してこれらのその他のバージョンに関する圧縮効率を確実に低下させる。

【0145】

シークポイント使用は、フレームが独立して復号可能であることを典型的要求し、その結果、そのフレームに関して低い圧縮効率が概して生じる。独立して復号可能であることが要求されないフレームは、その他のフレーム内のデータを参照して符号化することができ、それは、符号化対象となるフレームと基準フレームとの間の共通性の量に依存する量だけそのフレームに関する圧縮効率を概して向上させる。シークポイント配置の効率的な選択は、以前のフレームと低い共通性を有するフレームをシークポイントフレームとして優先的に選択し、それによって、独立して復号可能である形でフレームを符号化することによって被る圧縮効率上の不利益を最小にする。

【0146】

しかしながら、原コンテンツは同じであるため、フレームと潜在的基準フレームとの間の共通性のレベルは、コンテンツの異なる表現にわたって高い相関関係を有する。その結果、その他の変形におけるシークポイントが第１の変形におけるシークポイントと同じ位置であるように制約することは、圧縮効率の大きな違いを生じさせない。

【0147】

シークポイント構造は、好ましくは、ブロック構造を決定するために用いられる。好ましくは、各シークポイントは、ブロックの始めを決定し、２つの連続するシークポイント間のデータを包含する１つ以上のブロックが存在することができる。シークポイント間の継続時間は、優れた圧縮を有する符号化を目的として固定されないため、すべてのブロックが同じプレイアウト継続時間を有することを要求されるわけではない。幾つかの実装においては、ブロックは、コンテンツのバージョン間で整合され、すなわち、コンテンツの１つのバージョンにおいて特定のグループのフレームにまたがるブロックが存在する場合は、コンテンツの他のバージョンにおいて同じグループのフレームにまたがるブロックが存在する。コンテンツの所定のバージョンのためのブロックは、重なり合わず、コンテンツのすべてのフレームが各バージョンの正確に１つのバージョン内に含められる。

【0148】

シークポイント間での可変の継続時間、従って、可変の継続時間ＧｏＰ、の効率的な使用を可能にする特徴は、セグメント内に含めること又は他の手段によってクライアントに提供することができるセグメントインデキシング又はセグメントマップである、すなわち、これは、提供することができるこの表現内のこのセグメントと関連付けられたメタデータであり、プレゼンテーションの各ブロックの開始時間と継続時間とを備える。クライアントは、セグメント内に存在する特定のポイントにおいてプレゼンテーションが開始するようにユーザが要求しているときにプレゼンテーションを開始すべきブロックを決定するときにこのセグメントインデキシングデータを用いることができる。該メタデータが提供されない場合は、プレゼンテーションは、コンテンツの始めのみにおいて、又は、（例えば、要求される開始ポイント（時間）を平均のブロック継続時間で割って開始ブロックのインデックスを与えることによって開始ブロックを選択することによって）希望されるポイントに近いランダムな又は近似のポイントにおいて、開始することができる。

【0149】

一実施形態においては、各ブロックは、別個のファイルとして提供することができる。他の実施形態においては、複数の連続するブロックを単一のファイルに統合してセグメントを形成することができる。この第２の実施形態においては、各バージョンのためのメタデータは、各ブロックの開始時間及び継続時間とブロックが開始するファイル内のバイトオフセットとを備えて提供される。このメタデータは、最初のプロトコル要求に応答して提供することができ、すなわち、セグメント又はファイルから別個に入手可能であり、又は、例えば、ファイルの始めにおいて、ブロック自体と同じファイル又はセグメント内に含めることができる。当業者にとって明確であるように、このメタデータは、メタデータをクライアントに転送するために要求されるネットワークリソースを低減させるために、圧縮された形式で、例えば、ｇｚｉｐ又はデルタ符号化又はバイナリ形式で符号化することができる。

【0150】

図６は、ブロックが可変サイズであり、及びブロックの範囲が部分的ＧｏＰ、すなわち、１つのＲＡＰと次のＲＡＰとの間のメディアデータの部分的量、であるセグメントインデキシングの例を示す。この例においては、シークポイントは、ＲＡＰインジケータによって示され、１のＲＡＰインジケータ値は、ブロックがＲＡＰ、又はシークポイントから開始するか又はＲＡＰ、又はシークポイントを含むことを示し、０のＲＡＰインジケータは、ブロックがＲＡＰもシークポイントを含まないことを示す。この例では、最初の３つのブロック、すなわち、バイト０乃至１５７，０３３、は、第１のＧｏＰを備え、それは、１．６２３秒の提示継続時間を有し、提示時間は、コンテンツ内に２０秒入った時点から２１．６２３秒までである。この例では、３つの最初のブロックの第１のものは、０．４８５秒の提示時間を備え、セグメントにおけるメディアデータの最初の５０，２４５バイトを備える。この例では、ブロック４、５、及び６は、第２のＧｏＰを備え、ブロック７及び８は、第３のＧｏＰを備え、ブロック９、１０及び１１は、第４のＧｏＰを備える。シークポイントとして指定されず、従ってセグメントマップ内でＲＡＰとしてシグナリングされないその他のＲＡＰがメディアデータ内に存在可能であることに注目すること。

【0151】

図６を再度参照し、クライアント又は受信機がコンテンツにアクセスすることを希望してメディアプレゼンテーション内への約２２秒の時間オフセットにおいて開始する場合は、クライアントは、該当するメディアデータがこのセグメント内に存在することを最初に決定するために、その他の情報、例えばのちにより詳細に説明されるＭＰＤ、を最初に用いることができる。クライアントは、例えばＨＴＴＰバイト範囲要求を用いて、この事例ではわずか数バイトであるセグメントインデキシングを入手するためにセグメントの最初の部分をダウンロードすることができる。セグメントインデキシングを用いることによって、クライアントは、それがダウンロードすべき第１のブロックは、多くて２２秒であり及びＲＡＰ、すなわちシークポイント、から開始する時間オフセットを有する第１のブロックであることを決定することができる。この例では、ブロック５は２２秒よりも小さい時間オフセットを有する、すなわち、それの時間オフセットは２１．９６５秒であるが、セグメントインデキシングは、ブロック５がＲＡＰから開始しないことを示し、従ってその代わりに、セグメントインデキシングに基づき、クライアントは、ブロック４の開始時間が多くて２２秒の時点であり、すなわち、それの時間オフセットが２１．６２３秒であり、それはＲＡＰから開始するため、それをダウンロードすることを選択する。このように、セグメントインデキシングに基づき、クライアントは、バイトオフセット１５７，０３４において開始するＨＴＴＰ範囲要求を行う。

【0152】

セグメントインデキシングが利用可能でない場合は、クライアントは、このデータをダウンロードする前にすべての以前の１５７，０３４バイトのデータをダウンロードしなければならないことがあり、はるかに長い立ち上がり時間、又はチャネルザッピング時間、につながり、及び有用でないデータの無駄なダウンロードにつながる。代替として、セグメントインデキシングが利用可能でない場合は、クライアントは、セグメント内において希望されるデータが開始する場所を概算することができるが、その概算は不良であることがあり、それは、適切な時間を見逃すことがあり、戻ることを要求して立ち上がり遅延を再度増大させる。

【0153】

概して、各ブロックは、以前のブロックとともにメディアプレイヤーによってプレイアウトできるメディアデータの部分を包含する。従って、ブロッキング構造及びクライアントへのセグメントインデキシングブロッキング構造のシグナリングは、セグメント内に含まれるか又はその他の手段を通じてクライアントに提供されるかにかかわらず、クライアントがネットワークの変動及び混乱に直面した状態で高速チャネルザッピング、及び継ぎ目のないプレイアウトを提供する能力を有意に向上させることができる。セグメントインデキシングによって可能にされた、可変の継続時間のブロック、及びＧｏＰの一部のみを包含するブロックのサポートは、ストリーミング経験を有意に向上させることができる。例えば、図６及びクライアントがプレゼンテーションの約２２秒の時点でプレイアウトを開始することを希望する上述の例を再度参照し、クライアントは、１つ以上の要求を通じて、ブロック４内のデータを要求し、次にこれが再生開始のために入手可能になり次第メディアプレイヤー内にそれを供給することができる。従って、この例では、プレイアウトは、４２，０１１バイトのブロック４がクライアントにおいて受信され次第プレイアウトが開始し、それによって高速チャネルザッピング時間を可能にする。その代わりにクライアントが、プレイアウトが開始する前にＧｏＰ全体を要求する必要がある場合は、これは１４４，２１１バイトのデータであるため、チャネルザッピング時間はそれよりも長くなる。

【0154】

その他の実施形態においては、ＲＡＰ又はシークポイントは、ブロックの中央で生じることもでき、そのＲＡＰ又はシークポイントがブロック又はフラグメント内のどの場所に存在するかを示すデータがセグメントインデキシング内に存在することができる。その他の実施形態においては、時間オフセットは、ブロック内の第１のフレームの提示時間の代わりに、ブロック内の第１のフレームの復号時間であることができる。

【0155】

図８（ａ）及び（ｂ）は、複数のバージョン又は表現にわたる整合されたシークポイント構造を可変ブロックサイズ設定する例を示し、図８（ａ）は、メディアストリームの複数のバージョンにわたる整合されたシークポイントを有する可変ブロックサイズ設定を例示し、図８（ｂ）は、メディアストリームの複数のバージョンにわたる整合されないシークポイントを有する可変ブロックサイズ設定を例示する。

【0156】

時間は、最上部に示され、単位は秒であり、２つの表現のための２つのセグメントのブロック及びシークポイントがこのタイムラインに関するそれらのタイミングに関して左から右に示され、従って、示される各ブロックの長さは、それのプレイアウト時間に比例し、ブロック内のバイト数に比例しない。この例では、２つの表現の両方のセグメントのためのセグメントインデキシングは、シークポイントに関して同じ時間オフセット、ただしシークポイント間において潜在的に異なる数のブロック又はフラグメント、及び、各ブロック内のメディアデータの異なる量に起因するブロックに対する異なるバイトオフセット、を有することになる。この例では、クライアントが約２３秒の提示時間において表現１から表現２に切り換わることを希望する場合は、クライアントは、表現１のためのセグメント内のブロック１．２まで要求し、ブロック２．２から表現２のためのセグメントを要求するのを開始することができ、従って、切り換えは、表現1内のシークポイント１．２と一致するプレゼンテーションにおいて生じ、それは、表現２内のシークポイント２と同じ時点である。

【0157】

上記から明確であるはずであるように、説明されるブロック−要求ストリーミングシステムは、コンテンツ内の特定の位置にシークポイントを配置するように映像符号化を制約せず、これは、既存のシステムの問題のうちの１つを軽減する。

【0158】

上述される実施形態においては、それは、同じコンテンツプレゼンテーションの様々な表現のためのシークポイントが整合されるように構成される。しかしながら、多くの事例において、この整合要求を緩和することが好ましい。例えば、シークポイントが整合された表現を生成する能力を有さない表現を生成するために符号化ツールが用いられていることが時々ある。他の例として、コンテンツプレゼンテーションは、異なる表現間でのシークポイント整合なしに、独立して異なる表現に符号化することができる。他の例として、表現は、それがより低いレートを有し及びそれが切り換える必要がより一般的であるか又はそれは早送り又は巻き戻し又は高速シーク等のトリックモード（ｔｒｉｃｋ ｍｏｄｅ）をサポートするためのシークポイントを含むためより多くのシークポイントを含むことができる。このように、ブロック−要求ストリーミングシステムがコンテンツプレゼンテーションのための様々な表現にわたる整合されないシークポイントに効率的に及び継ぎ目なく対処することを可能にする方法を提供することが望ましい。

【0159】

この実施形態においては、複数の表現にわたるシークポイントの位置は整合しないことができる。ブロックは、新しいブロックが各シークポイントにおいて開始するように構築され、従って、プレゼンテーションの異なるバージョンのブロック間で整合性が存在しないことができる。異なる表現間での該整合されないシークポイント構造の例が図８（ｂ）に示される。時間は、最上部に示され、単位は秒であり、２つの表現のための２つのセグメントのブロック及びシークポイントがこのタイムラインに対するそれらのタイミングに関して左から右に示され、従って、示される各ブロックの長さは、それのプレイアウト時間に比例し、ブロック内のバイト数に比例しない。この例では、２つの表現の両方のセグメントのためのセグメントインデキシングは、シークポイントに関して潜在的に異なる時間オフセット、及びシークポイント間において同じく潜在的に異なる数のブロック又はフラグメント、及び、各ブロック内のメディアデータの異なる量に起因するブロックに対する異なるバイトオフセットを有することになる。この例では、クライアントが約２５秒の提示時間において表現１から表現２に切り換わることを希望する場合は、クライアントは、表現１のためのセグメント内でブロック１．３まで要求し、ブロック２．３から表現２のためのセグメントを要求するのを開始することができ、従って、切り換えは、表現２内のシークポイント２．３と一致するプレゼンテーションにおいて生じ、それは、表現１内のブロック１．３のプレイアウトの中央に存在し、従って、ブロック１．２のためのメディアの一部はプレイアウトされない（ただし、プレイアウトされないブロック１．３のフレームのためのメディアデータは、プレイアウトされるブロック１．３のその他のフレームを復号するために受信機バッファ内にローディングしなければならないことがある）。

【0160】

この実施形態においては、ブロック選択器１２３の動作は、前に選択されたバージョンと異なる表現からブロックを選択する必要があるごとに、最初のフレームが最後の選択されたブロックの最後のフレームに後続するフレームよりも後でない最後のブロックが選択されるように変更することができる。

【0161】

この最後に説明された実施形態は、第１のバージョン以外のバージョン内でのシークポイントの位置を制約する要求を排除し、それによってこれらのバージョンのための圧縮効率を向上させることができ、その結果、所定の利用可能な帯域幅に関してより高い品質のプレゼンテーションが得られ、これは、ユーザ経験を向上させる。１つのさらなる考慮事項は、コンテンツの複数の符号化（バージョン）にわたるシークポイント整合機能を実行する映像符号化ツールは幅広く利用できないことがあることであり、従って、この最後の説明された実施形態の利点は、現在利用可能な映像符号化ツールを使用できることである。他の利点は、コンテンツの異なるバージョンの符号化を、それらの異なるバージョンのための符号化プロセス間での調整の必要なしに並行して進行できることである。他の利点は、符号化ツールに特定のシークポイント位置のリストを提供する必要性なしに、コンテンツの追加のバージョンをのちの時点で符号化してプレゼンテーションに加えることができることである。

【0162】

概して、ピクチャがピクチャグループ（ＧｏＰ）として符号化される場合は、シーケンス内の第１のピクチャがシークポイントであることができるが、それは常にそうである必要はない。

【0163】

最適なブロック分割
ブロック−要求ストリーミングシステムにおける１つの懸念される課題は、符号化されたメディア、例えば映像メディア、の構造とブロック要求のために用いられるブロック構造との間での相互の影響である。映像符号化の当業者によって知られることになるように、各映像フレームの符号化された表現のために要求されるビット数は、フレームごとに時々実質的に変動することばしばしばある。その結果、受信されたデータの量とそのデータによって符号化されたメディアの継続時間との間の関係は直線的でないことがある。さらに、メディアデータをブロック−要求ストリーミングシステム内のブロックに分割することは、さらなる次元の複雑さを加える。特に、幾つかのシステムにおいては、ブロックのメディアデータは、ブロック全体が受信されてしまうまでプレイアウトすることができず、例えば、ブロック内でのメディアデータの配置及び消去コードの使用のブロック内でのメディアサンプル間の依存性の結果としてこの特性が生じることがある。ブロックサイズとブロック継続時間との間でのこれらの複雑な相互の影響及びプレイアウトを開始する前にブロック全体を受信することが必要になる可能性があることの結果として、クライアントシステムはプレイアウトが開始する前にメディアデータがバッファリングされる控えめな手法を採用するのが通例である。該バッファリングは、その結果として、長いチャネルザッピング時間そしてそれによる不良なユーザ経験が生じる。

【0164】

Ｐａｋｚａｄは、データストリームの基本構造に基づいてデータストリームを隣接するブロックに分割する方法を決定するための新しい効率的な方法である“ブロック分割法”について説明し、及び、ストリーミングシステムの関係におけるこれらの方法の幾つかの利点についてさらに説明している。Ｐａｋｚａｄのブロック分割法をブロック−要求ストリーミングシステムに適用する本発明のさらなる実施形態が今度は説明される。この方法は、提示されるメディアデータをおおよその提示時間順に手配することを備えることができ、このため、メディアデータのいずれかの所定の要素（例えば、映像フレーム又は音声サンプル）のプレイアウト時間は、隣接するメディアデータ要素のそれと提供されたスレショルドよりも小さい値だけ異なる。そのようにして順序が設定されたメディアデータは、Ｐａｋｚａｄの用語におけるデータストリームであるとみなすことができ、このデータストリームに適用されたＰａｋｚａｄの方法のうちのいずれも、データストリームとのブロック境界を識別する。あらゆる対の隣接するブロック境界の間のデータは、この開示の用語における“ブロック”であるとみなされ、ブロック−要求ストリーミングシステム内のメディアデータのプレゼンテーションを提供するために適用される。この開示を読んだ時点で当業者にとって明確になるように、ブロック−要求ストリーミングシステムに関してＰａｋｚａｄにおいて開示される方法の幾つかの利点を実現可能である。

【0165】

Ｐａｋｚａｄにおいて説明されるように、部分的ＧｏＰ又は２つ以上のＧｏＰの一部分を包含するブロックを含むセグメントのブロック構造の決定は、クライアントが高速チャネルザッピング時間を可能にする能力に対して影響を与える可能性がある。Ｐａｋｚａｄにおいては、ある１つのターゲット立ち上がり時間を考慮した場合、クライアントがいずれかのシークポイントで表現をダウンロードすることを開始し及びターゲットの立ち上がり時間が経過後にプレイアウトを開始した場合は、各時点においてクライアントがダウンロードしたデータの量が少なくともターゲットのダウンロードレート×ダウンロード開始からの経過時間の間継ぎ目なしで継続するように保証するブロック構造及びターゲットのダウンロードレートを提供する方法が提供された。これは、最も早期の時点で表現をプレイアウトすることをいつ開始すべきか決定するための手段をクライアントに提供し、ダウンロードが上述される条件を満たす限りクライアントが表現をプレイアウトするのを継続することを可能にするため、クライアントがターゲットの開始時間及びターゲットのダウンロードレートへのアクセスを有することが有利である。このように、のちに説明される方法は、それを上述される目的のために使用できるように、ターゲットの立ち上がり時間とターゲットのダウンロードレートをメディアプレゼンテーション記述内に含めるための手段を提供する。

【0166】

メディアプレゼンテーションデータモデル
図５は、図１に示されるコンテンツストアの可能な構造を例示し、セグメント及びメディアプレゼンテーション記述（“ＭＰＤ”）ファイルと、ＭＰＤファイル内のセグメント、タイミング、及びその他の構造の細分と、を含む。今度はＭＰＤ構造又はファイルの可能な実装の詳細が説明される。多くの例において、ＭＰＤはファイルとして説明されるが、非ファイル構造も同様に使用可能である。

【0167】

そこで例示されるように、コンテンツストア１１０は、複数のソースセグメント５１０、ＭＰＤ５００及び修復セグメント５１２を保有する。ＭＰＤは、期間レコード５０１を備えることができ、それは、セグメント情報５０３、例えば初期化セグメント５０４及びメディアセグメント５０５の参照、を含む表現レコード５０２を備えることができる。

【0168】

図９（ａ）は、メタデータテーブル例９００を示し、図９（ｂ）は、ＨＴＴＰストリーミングクライアント９０２がＨＴＴＰストリーミングサーバ９０６へのコネクションを通じてメタデータテーブル９００及びメディアブロック９０４をどのようにして入手するかの例を示す。

【0169】

ここにおいて説明される方法では、クライアントが入手可能なメディアプレゼンテーションの表現に関する情報を備える“メディアプレゼンテーション記述”が提供される。表現は、クライアントが異なる代替の中から１つを選択するという意味で代替であることができ、又は、それらは、クライアントが表現のうちの幾つかを、おそらく同じく代替の組から各々を、選択し及びそれらをまとめて提示するという意味で補完的であることができる。表現は、有利なことにグループに割り当てることができ、クライアントは、１つのグループ内の表現に関して、それらが各々互いに代替であるようにプログラミング又は構成され、他方、異なるグループからの表現では、２つ以上の表現がまとめて提示される。換言すると、グループ内に２つ以上の表現が存在する場合は、クライアントは、プレゼンテーションを形成するために、そのグループから１つの表現を選択し、次のグループから１つの表現を選択し、以下同様であることができる。

【0170】

表現を記述する情報は、有利なことに、表現を復号するために要求されるコーデックのプロフィールとレベルとを含む適用されたメディアコーデックの詳細と、映像フレームレートと、映像解像度と、データレートと、を含むことができる。メディアプレゼンテーション記述を受信するクライアントは、表現が復号又は提示のために適するかどうかを事前に決定するためにこの情報を用いることができる。これは、１つの利点を表し、その理由は、区別する情報が表現のバイナリデータ内にしか含まれていない場合は、それの適切性に関する情報を発見するために全表現からのバイナリデータを要求すること及び該当情報を構文解析及び抽出することが必要になるためである。これらの複数の要求及びデータの構文解析付属（ａｎｎｅｘ）の抽出はある程度の時間が要求され、その結果、長い立ち上がり時間、従って、不良なユーザ経験になる。

【0171】

さらに、メディアプレゼンテーション記述は、時刻に基づいてクライアントの要求を制限する情報を備えることができる。例えば、ライブのサービスに関しては、クライアントは、“現在の放送時間”に近いプレゼンテーション部分を要求することに制限することができる。これは、ライブ放送に関しては、現在の放送時間よりも前に提供されたスレショルドよりも多く放送されたコンテンツに関してサービングインフラストラクチャからデータを消去することが望ましいことがあるため１つの利点である。これは、サービングインフラストラクチャ内の格納リソースの再使用にとって望ましいであろう。これは、提供されるサービスのタイプに依存して同じく望ましいであろう。例えば、幾つかの事例では、プレゼンテーションは、受信するクライアントデバイスの一定の加入モデルに起因してライブのみで入手可能にすることができ、他方、その他のメディアプレゼンテーションは、ライブ及びオンデマンドで入手可能にすることができ、その他のプレゼンテーションは、第１のクラスのクライアントデバイスに対してはライブのみで、第２のクラスのクライアントデバイスに対してはオンデマンドのみで、及び、第３のクラスのクライアントデバイスに対してはライブ又はオンデマンドの組み合わせで入手可能にすることができる。メディアプレゼンテーションデータモデル（下記）において記述される方法は、サービングインフラストラクチャにおいて入手可能でないことがあるデータに関して、要求を行うこと及びユーザへの提供を調整することを回避できるように該方針をクライアントに連絡することを可能にする。代替として、例えば、クライアントは、このデータが入手可能でないことの通知をユーザに提示することができる。

【0172】

本発明のさらなる実施形態においては、メディアセグメントは、ＩＳＯ／ＩＥＣ １４４９６−１２又は派生仕様において説明されるＩＳＯベースメディアファイル形式（例えば、３ＧＰＰ技術仕様２６．２４４において説明される３ＧＰファイル形式）に準拠することができる。３ＧＰＰファイル形式の使用法に関する節（上記）は、ブロック−要求ストリーミングシステム内でのこのファイル形式のデータ構造の効率的な使用を可能にするＩＳＯベースメディアファイル形式の新規な拡張を説明する。この参考文献において説明されるように、情報は、ファイル内で提供することができ、ファイル内でのメディアプレゼンテーションの時間セグメントとバイト範囲と間での高速かつ効率的なマッピングを可能にする。メディアデータ自体は、ＩＳＯ／ＩＥＣ１４４９６−１２において定義されるムービーフラグメント構築により構造化することができる。時間及びバイトオフセットを提供するこの情報は、階層的に又は単一の情報ブロックとして構造化することができる。この情報は、ファイルの始めにおいて提供することができる。３ＧＰＰファイル形式の使用法に関する節において説明される効率的な符号化を用いたこの情報の提供は、その結果として、ブロック要求ストリーミングシステムによって用いられるファイルダウンロードプロトコルがＨＴＴＰである事例では、クライアントが例えばＨＴＴＰ部分的ＧＥＴ要求を用いて素早くこの情報を取り出すことができ、その結果、短い立ち上がり時間、シーク又はストリーム切り換え時間、そして従って、向上されたユーザ経験が得られる。

【0173】

メディアプレゼンテーション内の表現は、典型的には代替である複数の表現にわたる継ぎ目のない切り換えを確実にするために、及び、２つ以上の表現の同期的な提示を確実にするためにグローバルなタイムラインで同期化される。従って、適応型ＨＴＴＰストリーミングメディアプレゼンテーション内の表現内の含まれているメディアのサンプルタイミングは、複数のセグメントにわたる連続的なグローバルなタイムラインに関連することができる。

【0174】

複数のタイプのメディア、例えば音声及び映像、を含む符号化されたメディアのブロックは、異なるタイプのメディアに関して異なる提示終了時間を有することができる。ブロック要求ストリーミングシステムでは、該メディアブロックは、各メディアタイプが連続的に再生され従って１つのブロックからの１つのタイプのメディアサンプルが先行ブロックの他のタイプのメディアサンプルよりも前にプレイアウトできるような形で連続的に再生することができ、それは、ここでは“連続的ブロックスライシング” （ｃｏｎｔｉｎｕｏｕｓ ｂｌｃｏｋ ｓｐｌｉｃｉｎｇ）と呼ばれる。代替として、該メディアブロックは、１つのブロックのあらゆるタイプの最も早いサンプルが先行ブロックのあらゆるタイプの最後のサンプルの後に再生されるような形でプレイアウトすることができ、ここでは“不連続的ブロックスプライシング”（ｄｉｓｃｏｎｔｉｎｕｏｕｓ ｂｌｃｏｋ ｓｐｌｉｃｉｎｇ）と呼ばれる。連続的ブロックスプライシングは、両方のブロックが同じコンテンツ項目及び同じ表現からのメディアを含むときに適切であることができる。典型的には、１つの表現内では、２つのブロックをスプライシングするときに連続的ブロックスプライシングを適用することができる。これは、既存の符号化を適用することができ及びブロック境界でメディアトラックを整合させる必要なしにセグメンテーションを行うことができるため有利である。これは、図１０において例示され、ここで、映像ストリーム１０００は、ブロック１２０２とその他のブロックとを備え、ＲＡＰ、例えばＲＡＰ１２０４、を有する。

【0175】

メディアプレゼンテーション記述
メディアプレゼンテーションは、ＨＴＴＰストリーミングサーバ上の構造化されたファイルの集合体であるとみることができる。ＨＴＴＰストリーミングクライアントは、ストリーミングサービスをユーザに提示する上で十分な情報をダウンロードすることができる。代替表現は、３ＧＰＰファイル形式に準拠するか又は少なくとも３ＧＰファイルから又は３ＧＰファイルに簡単に変換することができる適切に定義されたデータ構造の組に準拠する１つ以上の３ＧＰファイル又は３ＧＰファイルの一部から成ることができる。

【0176】

メディアプレゼンテーションは、メディアプレゼンテーション記述によって記述することができる。メディアプレゼンテーション記述（ＭＰＤ）は、該当する時間にデータにアクセスするための及びストリーミングサービスをユーザに提供するための該当するファイル要求、例えばＨＴＴＰ ＧＥＴ要求、を構築するために用いることができるメタデータを含むことができる。メディアプレゼンテーション記述は、ＨＴＴＰストリーミングクライアントが該当する３ＧＰＰファイル及び複数のファイルを選択する上での十分な情報を提供することができる。アクセス可能であることがクライアントにシグナリングされるユニットは、セグメントと呼ばれる。

【0177】

とりわり、メディアプレゼンテーション記述は、以下のような要素及び属性を含むことができる。

【0178】

ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ（メディアプレゼンテーション記述）要素
エンドユーザにストリーミングサービスを提供するためにＨＴＴＰストリーミングクライアントによって用いられるメタデータをカプセル化する要素。ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎ要素は、次の属性及び要素のうちの１つ以上を含むことができる。

【0179】

Ｖｅｒｓｉｏｎ（バージョン）：拡張性を保証するためのプロトコルに関するバージョン番号。

【0180】

ＰｒｅｓｅｎｔａｔｉｏｎＩｄｅｎｔｉｆｉｅｒ（プレゼンテーション識別子）：プレゼンテーションをその他のプレゼンテーションと一意で識別することができる情報。プライベートフィールド又は名前を含むこともできる。

【0181】

ＵｐｄａｔｅＦｒｅｑｕｅｎｃｙ（更新頻度）：メディアプレゼンテーション記述の更新頻度、すなわち、クライアントが実際のメディアプレゼンテーション記述を再ローディングすることができる頻度。存在しない場合は、メディアプレゼンテーションは静的であることができる。メディアプレゼンテーションを更新することは、メディアプレゼンテーションをキャッシングできないことを意味する。

【0182】

ＭｅｄｉａＰｒｅｓｅｎｔａｔｉｏｎＤｅｓｃｒｉｐｔｉｏｎＵＲＬ（メディアプレゼンテーション記述ＵＲＬ）：メディアプレゼンテーション記述に日付を付けるためのＵＲＩ。

【0183】

Ｓｔｒｅａｍ（ストリーム）：ストリーム又はメディアプレゼンテーションのタイプ、すなわち、映像、音声、又はテキスト、を記述する。映像ストリームタイプは、音声を含むことができ及びテキストを含むことができる。

【0184】

Ｓｅｒｖｉｃｅ（サービス）：追加の属性を有するサービスタイプを記述する。サービスタイプは、ライブ又はオンデマンドであることができる。これは、ある現在の時間を越えるシーク及びアクセスは許可されないことをクライアントに知らせるために用いることができる。

【0185】

ＭａｘｉｍｕｍＣｌｉｅｎｔＰｒｅＢｕｆｆｅｒＴｉｍｅ（最大クライアントプリバッファ時間）：クライアントがメディアストリームをプリバッファリングすることができる最大時間量。このタイミングは、クライアントがこの最大プリバッファ時間を越えてダウンロードすることが制限されている場合にストリーミングとプログレッシブダウンロードを区別することができる。プリバッファリングに関する制限を適用することができないことを示す値は存在することができない。

【0186】

ＳａｆｅｔｙＧｕａｒｄＩｎｔｅｒｖａｌＬｉｖｅＳｅｒｖｉｃｅ（安全性ガード間隔ライブサービス）：サーバにおけるライブサービスの最大ターンアラウンド時間に関する情報。現時点で既にアクセス可能な情報の指示をクライアントに提供する。この情報は、クライアント及びサーバがＵＴＣ時間で動作することが予想されており、厳密な時間同期化が提供されない場合に必要になることがある。

【0187】

ＴｉｍｅＳｈｉｆｔＢｕｆｆｅｒＤｅｐｔｈ（時間シフトバッファ深さ）：クライアントが現在の時間に関してライブサービスにおいてどの程度戻ることができるかに関する情報。この深さの延長によって、サービスプロビジョニング（ｐｒｏｖｉｓｉｏｎｉｎｇ）の特定の変更なしに時間シフト視聴サービス及び追いつきサービスを可能にすることができる。

【0188】

ＬｏｃａｌＣａｃｈｉｎｇＰｅｒｍｉｔｔｅｄ（ローカルキャッシング許可）：このフラグは、ＨＴＴＰクライアントが、ダウンロードされたデータが再生された後にローカルでそれをキャッシングできることを示す。

【0189】

ＬｉｖｅＰｒｅｓｅｎｔａｔｉｏｎＩｎｔｅｒｖａｌ（ライブプレゼンテーション間隔）：ＳｔａｒｔＴｉｍｅ（開始時間）及びＥｎｄＴｉｍｅ（終了時間）を指定することによってプレゼンテーションを入手可能である時間間隔を含む。ＳｔａｒｉＴｉｍｅは、サービスの開始時間を示し、ＥｎｄＴｉｍｅは、サービスの終了時間を示す。ＥｎｄＴｉｍｅが指定されない場合は、現在の時間では終了時間は不明であり、ＵｐｄａｔｅＦｒｅｑｕｅｎｃｙは、クライアントがサービスの実際の終了時間前に終了時間へのアクセスを得ることを保証することができる。

【0190】

ＯｎＤｅｍａｎｄＡｖａｉｌａｂｉｌｉｔｙＩｎｔｅｒｖａｌ（オンデマンド入手可能性間隔）：提示間隔は、ネットワーク上でのサービスの入手可能性を示す。複数の提示間隔を提供することができる。ＨＴＴＰクライアントは、指定された時間窓外のサービスにアクセスすることができない。ＯｎＤｅｍａｎｄ Ｉｎｔｅｒｖａｌのプロビジョニングによって、追加の時間シフト視聴を指定することができる。この属性は、ライブサービスに関しても存在することができる。それがライブサービスに関して存在する場合は、サーバは、クライアントがすべての提供された入手可能性間隔中にＯｎＤｅｍａｎｄ Ｓｅｒｖｉｃｅとしてサービスにアクセスできることを保証することができる。従って、ＬｉｖｅＰｒｅｓｅｎｔａｔｉｏｎＩｎｔｅｒｖａｌは、ＯｎＤｅｍａｎｄＡｖａｉｌａｂｉｌｉｔｙＩｎｔｅｒｖａｌと重複することができない。

【0191】

ＭＰＤＦｉｌｅＩｎｆｏＤｙｎａｍｉｃ（ＭＰＤファイル情報ダイナミック）：メディアプレゼンテーション内のファイルのデフォルト時の動的な構築を記述する。さらなる詳細が以下に提供される。ＭＰＤレベルに関するデフォルト時指定は、幾つかの又はすべての代替表現に関して同じ規則が用いられる場合に不要な反復を避けることができる。

【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】

この手法では、各ファイルは、グローバル提示時間の点でのセグメントの正確な開始時間に関する情報を含むことができる。これをシグナリングするための３つの可能な方法は以下を含む。

【0219】

（１）第１に、各セグメントの開始時間をＭＰＤにおいて指定される正確なタイミングに制限する。しかしながら、メディア符号器は、ＩＤＲフレームの配置に関して柔軟性を有さないことがあり、ファイルストリーミングのための特別な符号化を要求することがある。

【0220】

（２）第２に、各セグメントのためのＭＰＤに正確な開始時間を追加する。オンデマンドの場合は、ＭＰＤのコンパクト性を低減させることがある。ライブの場合は、これは、ＭＰＤの定期的な更新を要求することがあり、それはスケーラビリティを低下させることがある。

【0221】

（３）第３に、セグメントが情報を含むという意味で、ＭＰＤ内における表現の発表された開始時間又はセグメントの発表された開始時間に関するグローバル時間又は正確な開始時間をセグメントに追加する。これは、適応型ストリーミング専用の新しいボックスに追加することができる。このボックスは、“ＴＩＤＸ”又は“ＳＩＤＸ”ボックスによって提供された情報を含むこともできる。この第３の手法の１つの結果は、セグメントのうちの１つの始め付近の特定の位置までシークするときに、クライアントは、ＭＰＤに基づき、要求されるシークポイントを含むセグメントまで後続するそれを選択することができることである。この事例における単純な応答は、取り出されたセグメントの始めまで（すなわち、シークポイント後の次のランダムアクセスポイントまで）シークポイントを前方に移動させることであることができる。通常は、ランダムアクセスポイントは、少なくとも数秒ごとに提供され（及びそれらの頻度を低くすることによる符号化上の利得はほとんど存在しないことがしばしばであり）、このため、最悪の場合は、シークポイントは、指定されるよりも数秒後に移動されることがある。代替として、クライアントは、セグメントに関するヘッダ情報を取り出す際に、要求されるシークポイントが実際には前セグメント内に存在することを決定して代わりにそのセグメントを要求することができる。この結果、シーク動作を実行するのに要する時間が時折増大することがある。

【0222】

アクセス可能なセグメントリスト
メディアプレゼンテーションは、一組の表現を備え、各々は、原メディアコンテンツに関する符号化の何らかの異なるバージョンを提供する。表現自体は、その他のパラメータと比較して表現の区別パラメータに関する情報を有利に含む。それらは、明示で又は暗黙に、アクセス可能なセグメントのリストも含む。

【0223】

セグメントは、メタデータのみを含むタイムレスセグメント（ｔｉｍｅｌｅｓｓ ｓｅｇｍｅｎｔ）及びメディアデータを主に含むメディアセグメントとして区別することができる。メディアプレゼンテーション記述（“ＭＰＤ”）は、暗黙に又は明示で、セグメントの各々を有利に識別して異なる属性を割り当てる。各セグメントに有利に割り当てられた属性は、セグメントがアクセス可能である期間と、リソースと、セグメントがアクセス可能であるプロトコルと、を備える。さらに、メディアセグメントは、属性、例えばメディアプレゼンテーションにおけるセグメントの開始時間、及びメディアプレゼンテーションにおけるセグメントの継続時間、が有利に割り当てられる。

【0224】

メディアプレゼンテーションが、メディアプレゼンテーション記述内の属性、例えばＯｎＤｅｍａｎｄＡｖａｉｌａｂｉｌｉｔｙＩｎｔｅｒｖａｌ（オンデマンド利用可能性間隔）、によって有利に示されるように、“オンデマンド”タイプである場合は、メディアプレゼンテーション記述は、典型的には、全セグメントを記述し、及び、セグメントがいつアクセス可能であるか及びセグメントがいつアクセス可能でないかの指示も提供する。セグメントの開始時間は、メディアプレゼンテーションの始めに関して有利に表され、このため、同じメディアプレゼンテーションの再生を、ただし異なる時間に、開始する２つのクライアントが同じメディアプレゼンテーション記述及び同じメディアセグメントを用いることができる。これは、セグメントをキャッシングする能力を有利に向上させる。

【0225】

メディアプレゼンテーションが、メディアプレゼンテーション記述内の属性、例えば属性Ｓｅｒｖｉｃｅ（サービス）、によって有利に示されるように、“ライブ”タイプである場合は、実際の時刻以降のメディアプレゼンテーションを備えるセグメントは、セグメントがＭＰＤ内において完全に記述されるにもかかわらず概して生成されないか又は少なくともアクセス可能でない。しかしながら、メディアプレゼンテーションサービスが“ライブ”タイプであることの指示を用いることで、クライアントは、ＭＰＤに含まれる情報及びＭＰＤのダウンロード時間に基づいて実際の経過時間（ｗａｌｌ−ｃｌｏｃｋ ｔｉｍｅ）におけるクライアント内部時間ＮＯＷのためのタイミング属性とともにアクセス可能なセグメントのリストを生成することができる。サーバは、実際の経過時間ＮＯＷにおいてＭＰＤのインスタンスを用いて動作する基準クライアントがリソースにアクセスできるようにリソースをアクセス可能にするという意味で有利に動作する。

【0226】

具体的には、基準クライアントは、ＭＰＤに含まれる情報及びＭＰＤのダウンロード時間に基づいて実際の経過時間におけるクライアント内部時間ＮＯＷのためのタイミング属性とともにアクセス可能なセグメントのリストを生成する。時間の進行とともに、クライアントは、同じＭＰＤを使用し、及び、メディアプレゼンテーションを連続的にプレイアウトするために用いることができる新しいアクセス可能なセグメントリストを生成する。従って、サーバは、ＭＰＤ内のセグメントが実際にアクセス可能である前にこれらのセグメントを発表することができる。これは、ＭＰＤの頻繁な更新及びダウンロードを低減させるため有利である。

【0227】

各々が開始時間ｔＳを有するセグメントのリストが、ＦｉｌｅＩｎｆｏＳｔａｔｉｃ、等の要素内のプレイリストによって明示で又はＦｉｌｅＩｎｆｏＤｙｎａｍｉｃ、等の要素を用いて暗黙に、記述されると仮定する。ＦｉｌｅＩｎｆｏＤｙｎａｍｉｃを用いてセグメントリストを生成するための有利な方法が以下において説明される。この構築規則に基づき、クライアントは、ここではＦｉｌｅＵＲＩ（ｒ，ｉ）と呼ばれる各表現ｒのためのＵＲＩのリスト及びインデックスｉを有する各セグメントのための開始時間ｔＳ（ｒ，ｉ）へのアクセスを有する。

【0228】

セグメントのアクセス可能な時間窓を生成するためのＭＰＤ内の情報の使用は、次の規則を用いて行うことができる。

【0229】

Ｓｅｒｖｉｃｅ、等の属性によって有利に示されるように、“オンデマンド”タイプのサービスに関しては、クライアントＮＯＷにおける現在の実際の経過時間がＯｎＤｅｍａｎｄＡｖａｉｌａｂｉｌｉｔｙＩｎｔｅｒｖａｌ等のＭＰＤ要素によって有利に表されるいずれかの入手可能性範囲内に存在する場合は、このオンデマンドプレゼンテーションのすべての記述されるセグメントがアクセス可能である。クライアントＮＯＷにおける現在の実際の経過時間が入手可能性範囲外にある場合は、このオンデマンドプレゼンテーションの記述されるセグメントのうちのいずれもアクセス不能である。

【0230】

Ｓｅｒｖｉｃｅ、等の属性によって有利に示されるように、“ライブ”タイプのサービスに関して、開始時間ｔＳ（ｒ，ｉ）は、実際の経過時間における入手可能性時間を有利に表す。入手可能性開始時間は、イベントのライブサービス時間及びキャプチャリング、符号化、及び発行のためのサーバにおけるあるターンアラウンド時間の組み合わせとして導き出すことができる。このプロセスのための時間は、例えば、例えばＭＰＤ内でＳａｆｅｔｙＧｕａｒｄＩｎｔｅｒｖａｌＬｉｖｅＳｅｒｖｉｃｅとして指定された安全性ガード間隔ｔＧを用いてＭＰＤ内において例えば指定することができる。これは、ＨＴＴＰストリーミングサーバでのＵＴＣ時間とデータの入手可能性との間の最低の差を提供する。他の実施形態においては、ＭＰＤは、イベントライブ時間とターンアラウンド時間との間の差としてターンアラウンド時間を提供することなしにＭＰＤ内のセグメントの入手可能性時間を明示で指定する。後続する説明では、あらゆるグローバル時間が利用可能性時間として指定されると仮定される。ライブのメディア放送の当業者は、この説明を読んだ後にメディアプレゼンテーション記述内の適切な情報からこの情報を導き出すことができる。

【0231】

クライアントＮＯＷにおける現在の実際の経過時間がＬｉｖｅＰｒｅｓｅｎｔａｔｉｏｎＩｎｔｅｒｖａｌ等のＭＰＤ要素によって有利に表されるライブプレゼンテーション間隔のいずれかの範囲の外に存在する場合は、このライブプレゼンテーションの記述されるセグメントのうちのいずれもアクセス不能である。クライアントＮＯＷにおける現在の実際の経過時間がライブプレゼンテーション間隔内に存在する場合は、このライブプレゼンテーションの記述されるセグメントのうちの少なくとも一定のセグメントはアクセス可能であることができる。

【0232】

アクセス可能なセグメントの制限は、次の値によって制御される。

【0233】

（クライアントによって入手可能な）実際の経過時間ＮＯＷ。

【0234】

メディアプレゼンテーション記述において例えばＴｉｍｅＳｈｉｆｔＢｕｆｆｅｒＤｅｐｔｈとして指定された許可された時間シフトバッファ深さｔＴＳＢ。

【0235】

相対的イベント時間ｔ_１におけるクライアントは、（ＮＯＷ−ｔＴＳＢ）及びＮＯＷの間隔において又は継続時間ｄを有するセグメントの終了時間も含まれその結果（ＮＯＷ−ｔＴＳＢ−ｄ）及びＮＯＷの間隔が得られるような間隔において開始時間ｔＳ（ｒ，ｉ）を有するセグメントを要求することのみが許可される。

【0236】

ＭＰＤの更新
幾つかの実施形態においては、例えばサーバの所在場所は変化するため、サーバは、ファイル又はセグメントロケータ及びセグメントの開始時間は事前には知らず、又は、メディアプレゼンテーションは、異なるサーバからの何らかのアドバタイズメント（ａｄｖｅｒｔｉｓｅｍｅｎｔ）を含み、又は、メディアプレゼンテーションの継続時間は不明であり、又は、サーバは後続するセグメントに関するロケータを不明瞭にすることを希望する。

【0237】

該実施形態においては、サーバは、既にアクセス可能であるか又はＭＰＤのこのインスタンスが発行されてからまもなくアクセス可能になるセグメントしか記述することができない。さらに、幾つかの実施形態においては、クライアントは、ユーザがメディアコンテンツの生成に可能な限り近い時点で含められているメディア番組を経験するようにＭＰＤにおいて記述されるメディアに近いメディアを有利に消費する。クライアントがＭＰＤ内の記述されたメディアセグメントの最後に到達することをそれが予想次第、それは、サーバが新しいメディアセグメントを記述する新しいＭＰＤを発行していることを予想して連続的なプレイアウトを継続するためにＭＰＤの新しいインスタンスを有利に要求する。サーバは、ＭＰＤの新しいインスタンスを有利に生成し、クライアントが連続的更新手順に依存することができるようにＭＰＤを更新する。サーバは、それのＭＰＤ更新手順を、セグメントの生成及び発行とともに、共通のクライアントが行動するのと同じように行動する基準クライアントの手順に合わせて好適化することができる。

【0238】

ＭＰＤの新しいインスタンスが短時間の前方（ｓｈｏｒｔ ｔｉｍｅ ａｄｖａｎｃｅ）のみを記述する場合は、クライアントは、ＭＰＤの新しいインスタンスを頻繁に要求する必要がある。この結果、不必要な頻繁な要求に起因するスケーラビリティ問題及び不必要なアップリンク及びダウンリンクトラフィックが生じることがある。

【0239】

従って、セグメントをまだ必ずしもアクセス可能にすることなしに可能な限り遠い将来までそれらを記述するのが一方では適切であり、ＭＰＤ内の予測されない更新が新しいサーバ所在場所を表すのを可能にすること、アドバタイズメント、等の新しいコンテンツの挿入を可能にすること、又はコーデックパラメータの変更を提供することが他方では適切である。

【0240】

さらに、幾つかの実施形態においては、メディアセグメントの継続時間は小さく、例えば数秒の範囲内に、することができる。メディアセグメントの継続時間は、配信又はキャッシング特性に合わせて最適化することができる適切なセグメントサイズに合わせて調整するために、ライブサービスにおける又はセグメントの格納又は配信を取り扱うその他の態様における最後と最後との間の遅延を補償するために、又はその他の理由のために有利に柔軟である。特にセグメントがメディアプレゼンテーション継続時間と比較して小さい事例においては、有意な量のメディアセグメントリソース及び開始時間をメディアプレゼンテーション記述において記述する必要がある。その結果、メディアプレゼンテーション記述のサイズが大きくなることがあり、それは、メディアプレゼンテーション記述のダウンロード時間に対して悪影響を及ぼし、従ってメディアプレゼンテーションの立ち上がり遅延及びアクセスリンク上での帯域幅使用法に対して影響を及ぼすことがある。従って、プレイリストを用いたメディアセグメントのリストの記述を可能にするだけでなく、テンプレート又はＵＲＬ構築規則を用いることによる記述も可能にすることが有利である。テンプレート及びＵＲＬ構築規則は、この説明では同義で用いられる。

【0241】

さらに、テンプレートは、現在の時間を越えるライブ事例においてセグメントロケータを記述するために有利に用いることができる。該事例においては、ロケータ及びセグメントリストはテンプレートによって記述されるためＭＰＤの更新はそれ自体が不要である。しかしながら、表現又はセグメントの記述の変更を要求する予測されないイベントが依然として発生することがある。複数の異なるソースからのコンテンツがひとつにスプライシング（接合）されるとき、例えば、アドバタイズメントが挿入されているとき、に適応型ＨＴＴＰストリーミングメディアプレゼンテーション記述の変更が必要になることがある。異なるソースからのコンテンツは、様々な形で異なることがある。他の理由は、ライブのプレゼンテーション中においては、１つのライブのオリジンサーバから他へのフェールオーバーのために提供するコンテンツファイルに関して用いられるＵＲＬを変更する必要があるためである。

【0242】

幾つかの実施形態においては、ＭＰＤが更新される場合は、基準クライアントそして従ってあらゆる実装されたクライアントは、ＭＰＤの前インスタンスから行っていたであろうと同じように前ＭＰＤの有効時間までのあらゆる時間の間に更新されたＭＰＤからアクセス可能なセグメントの同一の機能のリストを生成するという意味で更新されたＭＰＤが前ＭＰＤと互換可能であるようにＭＰＤの更新が行われることが有利である。この要求事項は、（ａ）新しいＭＰＤは更新時間前に旧ＭＰＤと互換可能であるため、クライアントが旧ＭＰＤとの同期化なしにそれを用いることを直ちに始めることができること、及び（ｂ）更新時間をＭＰＤの実際の変更が行われる時間と同期化させる必要がないことを保証する。換言すると、ＭＰＤの更新は事前にアドバタイズすることができ、サーバは、ＭＰＤの異なるバージョンを維持する必要なしに新情報が入手可能になった時点でＭＰＤの旧インスタンスを交換することができる。

【0243】

一組の表現又は全表現のためのＭＰＤ更新におけるメディアタイミングに関して２つの可能性が存在することができる。（ａ）既存のグローバルタイムラインがＭＰＤ更新を越えて継続する（ここでは“連続的ＭＰＤ更新”と呼ばれる）、又は（ｂ）現在のタイムラインが終了し、新しいタイムラインが変更に引き続いてセグメントから開始する（ここでは“不連続的ＭＰＤ更新”と呼ばれる）。

【0244】

これらの選択肢間の相違点は、メディアフラグメント、そして従ってセグメント、のトラックは、概して、トラック間での異なるサンプル粒度（ｇｒａｎｕｌａｒｉｔｙ）に起因して同時に開始して終了することはないことを考慮したときに明白であろう。通常のプレゼンテーション中には、フラグメントの１つのトラックのサンプルは、前フラグメントの他のトラックの幾つかのサンプルの前にレンダリングすることができる。すなわち、単一のトラック内では重なり合いは存在することができないが、フラグメント間にはある種の重なり合いが存在する。

【0245】

（ａ）と（ｂ）の間の相違点は、該重なり合いをＭＰＤ更新に対してまで可能にすることができるかどうかである。ＭＰＤ更新が完全に別個のコンテンツのスプライシングに起因するときには、新コンテンツは前コンテンツとスプライシングされるための新しい符号化が必要であるため該重なり合いは達成させるのが概して困難である。従って、一定のセグメントに関するタイムラインを再開させることによってメディアプレゼンテーションを不連続的に更新するための能力を提供すること及びおそらく更新後に新しい組の表現を定義することも有利である。さらに、コンテンツが独立して符号化及びセグメンテ−ションされている場合は、前コンテンツのグローバルタイムライン内に適合するようにタイムスタンプを調整することも回避される。

【0246】

更新がそれよりも重要でない理由による、例えば、記述されたメディアセグメントのリストに新しいメディアセグメントを追加するだけである、とき、又は、ＵＲＬの所在場所が変更される場合は、重なり合い及び連続的更新を許容することができる。

【0247】

不連続的ＭＰＤ更新の場合は、前表現の最後のセグメントのタイムラインは、セグメント内のサンプルの最後のプレゼンテーションの終了時間に終了する。次の表現のタイムライン（より正確には、メディアプレゼンテーションの新しい部分の最初のメディアセグメントの最初の提示時間であり、新しい期間とも呼ばれる）は、継ぎ目なしの連続プレイアウトが保証されるようにするために最後の期間のプレゼンテーションの最後とまさに同じ瞬間に典型的に及び有利に開始する。

【0248】

２つの事例が図１１において例示される。

【0249】

ＭＰＤ更新をセグメント境界に制限するのが好ましく及び有利である。該変更又は更新をセグメント境界に制限することの論理的根拠は次の通りである。第１に、各表現、典型的にはムービーヘッダ、のためのバイナリメタデータの変更は、少なくともセグメント境界において生じることができる。第２に、メディアプレゼンテーション記述は、セグメントを示すポインタ（ＵＲＬ）を含むことができる。ある意味では、ＭＰＤは、メディアプレゼンテーションと関連付けられた全セグメントファイルを１つにまとめてグループ分けする“傘”データ構造である。この含有関係を維持するために、各セグメントは、単一のＭＰＤによって参照することができ、ＭＰＤが更新されるときには、それは、セグメント境界のみで有利に更新される。

【0250】

セグメント境界は、整合させることは概して要求されないが、異なるソースからスプライシングされたコンテンツの事例に関しては、及び概して不連続的ＭＰＤ更新に関しては、セグメント境界を整合させるのが合理的である（具体的には、各表現の最後のセグメントは同じ映像フレームで終了することができ及びそのフレームの提示時間よりも遅い提示開始時間を有する音声サンプルを含むことはできない）。これで、不連続的更新は、期間と呼ばれる共通の瞬間に新しい組の表現を開始させることができる。この新しい組の表現の有効性の開始時間は、例えば、期間開始時間によって提供される。各表現の相対的開始時間は、ゼロにリセットされ、期間の開始時間は、グローバルメディアプレゼンテーションタイムライン内のこの新しい期間内に表現の組を入れる。

【0251】

連続的ＭＰＤ更新に関しては、セグメント境界は整合させる必要がない。各代替表現の各セグメントは、単一のメディアプレゼンテーション記述によって制御することができ、従って、メディアプレゼンテーション記述の新しいインスタンスに関する更新要求は、動作中のＭＰＤでは追加のメディアセグメントは記述されないという予想によって概してトリガされ、消費されることが予想される表現の組を含む消費された表現の組に依存して異なる時間に生じることができる。

【0252】

より一般的な事例におけるＭＰＤ要素及び属性の更新をサポートするために、表現又は表現の組だけでないあらゆる要素を有効時間と関連付けることができる。このため、ＭＰＤの一定の要素を更新する必要がある場合、例えば、表現の数が変更されるか又はＵＲＬ構築規則が変更される場合は、これらの要素は、各々が、要素の複数のコピーに切り離された有効時間を提供することによって、指定された時間に個々に更新することができる。

【0253】

有効性は、グローバルメディア時間と有利に関連付けられ、このため、有効時間と関連付けられた記述された要素は、メディアプレゼンテーションのグローバルタイムラインの期間において有効である。

【0254】

上述されるように、一実施形態においては、有効時間は、完全な表現の組にしか追加されない。各々の完全な組は、期間を形成する。有効時間は、その期間の開始時間を形成する。換言すると、有効性要素を用いる特定の事例においては、完全な表現の組は、表現の組のためにグローバル有効時間によって示された期間の間有効であることができる。表現の組の有効時間は、期間と呼ばれる。新期間の開始時に、前の組の表現の有効性が失効し、新しい表現の組が有効である。期間の有効時間は好ましくは切り離されていることに再度注目すること。

【0255】

上記のように、メディアプレゼンテーション記述の変更は、セグメント境界で行われ、このため、各表現に関して、要素の変更は実際には次のセグメント境界で行われる。クライアントは、メディアの提示時間内の各瞬間に関するセグメントのリストを含む有効なＭＰＤを形成することができる。

【0256】

不連続的ブロックスプライシングは、ブロックが異なる表現からの、又は異なるコンテンツからの、例えばコンテンツのセグメント又はアドバタイズメントからのメディアデータを含む場合に、又はその他の場合に適切であることができる。ブロック要求ストリーミングシステムでは、プレゼンテーションメタデータの変更はブロック境界のみで行われることを要求することができる。これは、ブロック内でメディア復号器パラメータを更新することはブロック間のみでそれらを更新することよりも複雑になることがあるため、実装上の理由で有利であることができる。この場合は、要素が指定された有効間隔の始めよりも早くない第１のブロック境界から指定された有効間隔の終わりよりも早くない第１のブロック境界まで有効であるとみなされるように、上述される有効間隔は近似値として解釈できることを有利に規定することができる。

【0257】

ブロック−要求ストリーミングシステムの上述される新規の拡張の実施形態例が、メディアプレゼンテーションの変更という表題ののちに提示された節において説明される。

【0258】

セグメント継続時間シグナリング
不連続的更新は、プレゼンテーションを期間と呼ばれる一連の切り離された間隔に有効に分割する。各期間は、メディアサンプリングタイミングのためのそれ自体のタイムラインを有する。期間内における表現のメディアタイミングは、各期間に関する又は期間内の各表現に関するセグメント継続時間の別個のコンパクトなリストを指定することによって有利に示すことができる。

【0259】

ＭＰＤ内の要素と関連付けられた、例えば期間開始時間と呼ばれる属性は、メディア提示時間内の一定の要素の有効時間を指定することができる。この属性は、ＭＰＤのいずれかの要素に加えることができる（有効性を割り当てることができる属性は、要素に変更することができる）。

【0260】

不連続的ＭＰＤ更新に関しては、全表現のセグメントが不連続部において終了することができる。これは、少なくとも、不連続部の前の最後のセグメントが前のそれらと異なる継続時間を有することを概して暗に示す。セグメント継続時間をシグナリングすることは、全セグメントが同じ継続時間を有することを示すこと又はすべてのセグメントに関する別個の継続時間を示すことを含むことができる。それらの多くが同じ継続時間を有する場合に効率的であるセグメント継続時間のリストのためにコンパクトな表現を有することが望ましいであろう。

【0261】

１つの表現又は表現の組内の各セグメントの継続時間は、不連続的更新の始め、すなわち、期間の始め、からＭＰＤにおいて記述される最後のメディアセグメントまでの単一の間隔の間の全セグメント継続時間を指定する単一のストリングを用いて有利に成し遂げることができる。一実施形態においては、この要素の形式は、この表現が第１のエントリの継続時間＜ｄｕｒ＞の第１のエントリセグメントの＜ｍｕｌｔ＞、次に、第２のエントリの継続時間＜ｄｕｒ＞の第２のエントリセグメントの＜ｍｕｌｔ＞、以下同様を含むことを示す属性の継続時間属性ｄｕｒ及び属性の任意選択の乗数ｍｕｌｔを各エントリが含むセグメント継続時間エントリリストを含むプロダクション（ｐｒｏｄｕｃｔｉｏｎ）に準拠したテキストストリングである。

【0262】

各継続時間エントリは、１つ以上のセグメントの継続時間を指定する。＜ｄｕｒ＞値が “^＊”文字及び数字によって後続される場合は、この数字は、単位が秒であるこの継続時間を有する連続するセグメントの数を指定する。乗数符号“^＊”が存在しない場合は、セグメント数は１である。“^＊”が後続数字なしで存在する場合は、すべての後続するセグメントが指定された継続時間を有し、リスト内にはさらなるエントリは存在できない。例えば、ストリング“３０^＊”は、全セグメントが３０秒の継続時間を有することを意味する。ストリング“３０^＊１２ １０．５”は、継続時間３０秒の１２のセグメントであり、１０．５秒の継続時間の１つが後続することを示す。

【0263】

セグメント継続時間が各々の代替表現に関して別々に指定される場合は、各間隔内のセグメント継続時間の合計は各表現に関して同じであることができる。映像トラックの場合は、間隔は、各々の代替表現において同じフレームで終了することができる。

【0264】

当業者は、この開示を読んだ時点で、コンパクトな方法でセグメント継続時間を表すための同様の及び同等の方法を見つけるであろう。

【0265】

他の実施形態においては、セグメントの継続時間は、信号継続時間属性＜ｄｕｒａｔｉｏｎ＞によって最後の１つを除く表現内の全セグメントに関して一定であることがシグナリングされる。不連続的更新前の最後のセグメントの継続時間は、次の不連続的更新の開始ポイント又は新しい期間の始めが提供される限りはより短くすることができ、それは、次の期間の始めに至るまでの最後のセグメントの継続時間を意味する。

【0266】

表現メタデータの変更及び更新
ムービーヘッダ“ｍｏｏｖ”の変更、等のバイナリ符号化表現メタデータの変更を示すことは、異なる方法で完遂させることができる。すなわち、（ａ）ＭＰＤ内で参照される別個のファイル内の全表現のための１つのｍｏｏｖボックスが存在することができる、（ｂ）各代替表現内で参照される別個のファイル内の各々の代替表現のための１つのｍｏｏｖボックスが存在することができる、（ｃ）各セグメントは、ｍｏｏｖボックスを含むことができ、従って、自己内蔵型であることができる、（ｄ）ＭＰＤとともに１つの３ＧＰファイル内の全表現のためのｍｏｏｖボックスが存在することができる。

【0267】

（ａ）及び（ｂ）の場合は、 ‘ｍｏｏｖ’ボックスの有効性が切り離されている限りＭＰＤ内ではより多くの‘ｍｏｏｖ’ボックスを参照できるという意味で単一の‘ｍｏｏｖ’を上記の有効性概念と有利に結合させることができる。例えば、期間境界の定義に従い、旧期間内の‘ｍｏｏｖ’の有効性は、新期間の開始とともに失効することができる。

【0268】

選択肢（ａ）の場合は、単一のｍｏｏｖボックスの参照に有効性要素を割り当てることができる。複数のプレゼンテーションヘッダを許容することができるが、一度に１つのみが有効であることができる。他の実施形態においては、上記において定義される期間又は期間全体における表現の組全体の有効時間を、典型的にはｍｏｏｖヘッダとして提供されるこの表現メタデータのための有効時間として用いることができる。

【0269】

選択肢（ｂ）の場合は、各表現のｍｏｏｖボックスの参照に有効性要素を割り当てることができる。複数の表現ヘッダを許容することができるが、一度に１つだけが有効であることができる。他の実施形態においては、上記において定義される表現全体又は期間全体の有効時間を、典型的にはｍｏｏｖヘッダして提供されるこの表現メタデータのための有効時間として用いることができる。

【0270】

選択肢（ｃ）の場合は、ＭＰＤ内のシグナリングは追加することができないが、ｍｏｏｖボックスがいずれかの到来するセグメントに関して変化するかどうかを示すためにメディアストリーム内の追加のシグナリングを追加することができる。これは、“セグメントメタデータ内での更新のシグナリング”の文脈で以下においてさらに説明される。

【0271】

セグメントメタデータ内での更新のシグナリング
潜在的更新に関する知識を得るためのメディアプレゼンテーション記述の頻繁な更新を回避するために、該更新をメディアセグメントとともにシグナリングするのが有利である。更新されたメタデータ、例えばメディアプレゼンテーション記述を入手可能であり、アクセス可能なセグメントリストの生成を成功裏に続けるためには一定の量の時間内にアクセスしなければならないことを示すことができる追加の要素又は要素（複数）をメディアセグメント自体内において提供することができる。さらに、該要素は、更新されたメタデータファイルに関するファイル識別子、例えばＵＲＬ、又はファイル識別子を構築するために用いることができる情報を提供することができる。更新されたメタデータファイルは、有効間隔も付随する追加のメタデータとともに有効間隔を示すために変更されたプレゼンテーションのために原メタデータファイルにおいて提供されるメタデータと等しいそれを含むことができる。該指示は、メディアプレゼンテーションのためのすべての入手可能な表現のメディアセグメント内おいて提供することができる。ブロック要求記述ストリーミングシステムにアクセスするクライアントは、メディアブロック内で該指示を検出した時点で、更新されたメタデータファイルを取り出すためにファイルダウンロードプロトコル又はその他の手段を用いることができる。クライアントは、それにより、メディアプレゼンテーション記述の変更及びそれらが生じるか又は生じた時間に関する情報が提供される。有利なことに、各クライアントは、可能性のある更新又は変更のために何回もファイルを“ポーリング”及び受信するのではなく該変更が生じるときに１回だけ更新されたメディアプレゼンテーション記述を要求する。

【0272】

変更例は、表現の追加又は削除、１つ以上の表現の変更、例えば、ビットレート、解像度、アスペクト比、含められているトラック又はコーデックパラメータの変更、及びＵＲＬ構築規則の変更、例えばアドバタイズメントのための異なるオリジンサーバ、を含む。幾つかの変更は、初期化セグメント、例えば、表現と関連付けられたムービーヘッダ（“ｍｏｏｖ”）アトム、のみに影響を及ぼすことがあり、他方、その他の変更は、メディアプレゼンテーション記述（ＭＰＤ）に対して影響を及ぼすことがある。

【0273】

オンデマンドコンテンツの場合は、これらの変更及びそれらのタイミングは事前に知ることができ及びメディアプレゼンテーション記述においてシグナリングすることができる。

【0274】

ライブコンテンツに関しては、変更は、それらが生じるポイントまで知ることができない。１つの解決方法は、特定のＵＲＬにおいて入手可能なメディアプレゼンテーション記述を動的に更新すること及び変更を検出するためにこのＭＰＤを定期的に要求するようにクライアントに要求することを可能にすることである。この解決方法は、スケーラビリティ（オリジンサーバ負荷及びキャッシュ効率）の点での欠点を有する。非常に多くの視聴者を有するシナリオでは、キャッシュは、キャッシュから前バージョンが無効になった後で及び新バージョンが受信される前に数多くのＭＰＤ要求を受信することができ、これらのすべてをオリジンサーバに転送することができる。オリジンサーバは、ＭＰＤの各々の更新されたバージョンに関するキャッシュからの要求を常に処理する必要がある。さらに、更新は、メディアプレゼンテーションの変更と時間的に整合させることは簡単にはできない。

【0275】

ＨＴＴＰストリーミングの利点のうちの１つは、スケーラビリティのために標準的なウェブインフラストラクチャ及びサービスを利用する能力であるため、好ましい解決方法は、“静的な”（すなわち、キャッシング可能な）ファイルのみを含むこと及びそれらが変化しているかどうかを確認するためにクライアント“ポーリング”ファイルに依存しないことであることができる。

【0276】

適応型ＨＴＴＰストリーミングメディアプレゼンテーションにおいてメディアプレゼンテーション記述を含むメタデータ及びバイナリ表現メタデータ、例えば“ｍｏｏｖ”アトム、の更新を解決するために解決方法が説明及び提案される。

【0277】

ライブコンテンツに関して、ＭＰＤが構築されるときにＭＰＤ又は“ｍｏｏｖ”が変化することがあるポイントを知ることができない。帯域幅及びスケーラビリティ上の理由で、更新の有無を検査するためのＭＰＤの頻繁な“ポーリング”は概して回避すべきであるため、ＭＰＤの更新は、セグメントファイル自体内で“インバンド”（ｉｎ ｂａｎｄ）で示すことができる。すなわち、各メディアセグメントは、更新を示す選択肢を有することができる。上記のセグメント形式（ａ）乃至（ｃ）に依存して、異なる更新をシグナリングすることができる。

【0278】

概して、次の指示をセグメント内の信号において有利に提供することができる。すなわち、この表現内の次のセグメント又は現在のセグメントの開始時間よりも大きい開始時間を有する次のセグメントを要求する前にＭＰＤを更新することができることを示すインジケータ。更新は、事前に発表し、更新は次のセグメントよりも後のいずれかのそれのみにおいて生じる必要があることを示すことができる。このＭＰＤ更新は、メディアセグメントのロケータが変更された場合にバイナリ表現メタデータ、例えばムービーヘッダ、を更新するために用いることもできる。他の信号は、このセグメントの完了に伴って時間的に先行するそれ以上のセグメントは要求すべきでないことを示すことができる。

【0279】

セグメントがセグメント形式（ｃ）によりフォーマット化される、すなわち、各メディアセグメントが自己初期化メタデータ、例えばムービーヘッダ、を含む場合は、後続するセグメントが更新されたムービーヘッダ（ｍｏｏｖ）を含むことを示す他の信号を追加することができる。これは、ムービーヘッダをセグメント内に含めることを有利に可能にするが、ムービーヘッダは、前セグメントがムービーヘッダ更新を示す場合に又は表現を切り換えるときのシーク又はランダムアクセスの場合にクライアントによって要求する必要があるだけである。その他の場合は、クライアントは、ダウンロードからムービーヘッダを除外し、従って帯域幅を有利に節約するバイト範囲要求をセグメントに出すことができる。

【0280】

さらに他の実施形態においては、ＭＰＤ更新指示がシグナリングされる場合は、信号は、ロケータ、例えば更新されたメディアプレゼンテーション記述のためのＵＲＬ、を含むこともできる。更新されたＭＰＤは、有効性属性、例えば不連続的更新の場合は新しい及び古い期間、を用いて、更新前及び後の両方におけるプレゼンテーションを記述することができる。これは、以下においてさらに詳細に説明されるように時間シフト視聴を可能にするために有利に用いることができるが、ＭＰＤ更新をそれが含む変更が有効になる前のあらゆる時点でシグナリングするのを同じく有利に可能にする。クライアントは、新しいＭＰＤを直ちにダウンロードして進行中のプレゼンテーションにそれを適用することができる。

【0281】

具体的な実現においては、メディアプレゼンテーション記述の変更のシグナリング、ｍｏｏｖヘッダ又はプレゼンテーションの終わりを、ＩＳＯベースメディアファイル形式のボックス構造を用いてセグメント形式の規則に従ってフォーマット化されるストリーミング情報ボックス内に含めることができる。このボックスは、異なる更新のうちのいずれかのための特定の信号を提供することができる。

【0282】

ストリーミング情報ボックス定義ボックスタイプ：‘ｓｉｎｆ’コンテナ：なし強制：なし数量：ゼロ又は１
ストリーミング情報ボックスは、ファイルが一部となっているストリームプレゼンテーションに関する情報を含む。

【0283】

構文
aligned(8) class StreamingInformationBox
extends FullBox(‘sinf’) {unsigned int(32) streaming_information_flags; ///以下は任意選択フィールドである。 string mpd_location} 意味論 ｓｔｒｅａｍｉｎｇ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｌａｇｓは、次のうちのゼロ以上の論理ＯＲを含む。

【0284】

０ｘ０００００００１ ムービーヘッダ更新が後続する
０ｘ０００００００２ プレゼンテーション記述更新
０ｘ０００００００４ プレゼンテーション終わり
ｍｐｄ＿ｌｏｃａｔｉｏｎは、プレゼンテーション記述更新フラグが設定されている場合のみに存在し、新しいメディアプレゼンテーション記述のためのユニフォームリソースロケータ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を提供する。 ライブサービスのためのＭＰＤ更新に関する使用事例
サービスプロバイダがここにおいて説明される拡張されたブロック−要求ストリーミングを用いてライブのサッカーイベントを提供することを希望すると仮定する。おそらく何百万人ものユーザがそのイベントのプレゼンテーションにアクセスすることを希望するであろう。このライブイベントは、時間切れがコールされたときの中断、又はアクションのその他の小康状態によって散発的に遮断され、その間にアドバタイズメントを加えることが可能である。典型的には、それらの中断の正確なタイミングに関する事前の通知はまったく又はほとんど行われない。

【0285】

サービスプロバイダは、ライブイベント中にコンポーネントのうちのいずれかが故障した場合に継ぎ目なしの切り換えを可能にするための冗長なインフラストラクチャ（例えば、符号器又はサーバ）を提供することが必要な場合がある。

【0286】

アンというユーザが彼女の携帯デバイスを用いてバス内でサービスにアクセスし、サービスを直ちに入手可能であると仮定する。彼女の隣には他のユーザであるポールが座って彼のラップトップでイベントを視聴している。ゴールが決められて両者が同時にこのイベントを祝する。ポールは、ゲーム内での最初のゴールがさらにエキサイティングであったとアンに言い、アンは、３０分前のイベントを視聴できるようにするためのサービスを使用する。彼女は、そのゴールを見た後にライブのイベントに戻る。
その使用事例に対処するために、サービスプロバイダは、ＭＰＤを更新し、更新されたＭＰＤを入手可能であることをクライアントにシグナリングし、及びクライアントがほぼリアルタイムでデータを提示できるようにそれがストリーミングサービスにアクセスするのを可能にすることができるべきである。

【0287】

ＭＰＤの更新は、ここにおいて別の場所で説明されるように、セグメントの配信と非同期的に実行可能である。サーバは、ある時間の間ＭＰＤが更新されないことの保証を受信機に提供することができる。サーバは、現在のＭＰＤに依存することができる。しかしながら、ある最小の更新期間前にＭＰＤが更新されるときには明示のシグナリングは必要ない。

【0288】

クライアントは異なるＭＰＤ更新インスタンスに対して動作することがあり、従って、クライアントはドリフト（ｄｒｉｆｔ）を有することがあるため、完全に同期的なプレイアウトはほとんど達成されない。ＭＰＤ更新を用いることで、サーバは、提示中であっても、変更を伝達することができ、クライアントに対して変更への注意を促すことができる。ＭＰＤの更新を示すためにセグメントごとのインバンドシグナリングを用いることができ、このため、更新をセグメント境界に制限することができるが、それは、ほとんどの用途において許容可能であるべきである。

【0289】

ＭＰＤの実際の経過時間における発行時間及びＭＰＤが要求されることをシグナリングするためにセグメントの始めに加えられる任意選択のＭＰＤ更新ボックスを提供するＭＰＤ要素を追加することができる。更新は、ＭＰＤと同様に、階層的に行うことができる。

【0290】

ＭＰＤ“発行時間”は、ＭＰＤのために及びＭＰＤが発行されたときに一意の識別子を提供する。それは、更新手順に関するアンカー（ａｎｃｈｏｒ）も提供する。 ＭＰＤ更新ボックスは、ＭＰＤ内において“ｓｔｙｐ”ボックスの後で見つけ、Ｂｏｘ Ｔｙｐｅ＝“ｍｕｐｅ”によって定義することができ、コンテナは不要であり、強制的でなく及びゼロ又は１の数量を有する。ＭＰＤ更新ボックスは、セグメントが一部となっているメディアプレゼンテーションに関する情報を含む。

【0291】

構文例は次の通りである。

【0292】

aligned(8) class MPDUpdateBox
extends FullBox(‘mupe’) {unsigned int(3) mpd information flags; unsigned int(1) new-location flag; unsigned int(28) latest_mpd_update time;
///以下は任意選択フィールドである。
string mpd_location} クラスＭＰＤＵｐｄａｔｅＢｏｘの様々なオブジェクトの意味論は次の通りであることができる。

【0293】

ｍｐｄ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｌａｇｓ：次のうちのゼロ以上の論理ＯＲを含む。

【0294】

０ｘ００ 現在のメディアプレゼンテーション記述更新
０ｘ０１ 将来のメディアプレゼンテーション記述更新
０ｘ０２ プレゼンテーション終わり
０ｘ０３−０ｘ０７ 予約
ｎｅｗ＿ｌｏｃａｔｉｏｎ ｆｌａｇ：１に設定される場合は、新しいメディアプレゼンテーション記述は、ｍｐｄ＿ｌｏｃａｔｉｏｎにおいて指定された新しい場所で入手可能である。

【0295】

ｌａｔｅｓｔ＿ｍｐｄ＿ｕｐｄａｔｅ ｔｉｍｅ：最新のＭＰＤのＭＰＤ発行時間に関してＭＰＤ更新がいつまでに必要であるかの時間（単位ｍｓ）を指定する。クライアントは、現在との間のあらゆる時間にＭＰＤを更新することを選択することができる。

【0296】

ｍｐｄ＿ｌｏｃａｔｉｏｎ：ｎｅｗ＿ｌｏｃａｔｉｏｎ＿ｆｌａｇが設定されている場合のみに存在し、そうである場合は、ｍｐｄ＿ｌｏｃａｔｉｏｎは、新しいメディアプレゼンテーション記述のためのユニフォームリソースロケータを提供する。

【0297】

更新によって用いられる帯域幅が課題である場合は、サーバは、一定のデバイス能力のみが更新されるようにこれらの部分のためのＭＰＤを提供することができる。

【0298】

時間シフト視聴及びネットワークＰＶＲ
時間シフト視聴がサポートされるときには、セッションの寿命中に２つ以上のＭＰＤ又はムービーヘッダが有効であるということが生じることがある。この場合は、必要なときにＭＰＤを更新し、ただし有効性メカニズム又は期間概念を加えることによって、時間窓全体にわたって有効なＭＰＤが存在することができる。これは、時間シフト視聴のための有効な時間窓内にあるいずれかの期間の間ＭＰＤ及びムービーヘッダが発表されるのをサーバが保証できることを意味する。クライアントの入手可能なＭＰＤ及びそれの現在の提示時間のためのメタデータが有効であることを保証するのはクライアントの義務である。小規模なＭＰＤ更新のみを用いたネットワークＰＶＲセッションへのライブセッションの移行もサポート可能である。

【0299】

特別なメディアセグメント
ブロック要求ストリーミングシステム内でＩＳＯ／ＩＥＣ １４４９６−１２のファイル形式が用いられるときの一課題は、上述されるように、プレゼンテーションの単一のバージョンのためのメディアデータを複数のファイルに格納して、連続する時間セグメントで配置するのが有利であることである。さらに、各ファイルがランダムアクセスポイントから開始するように配置することが有利であることができる。さらに、映像符号化プロセス中にシークポイントの位置を選択すること及び符号化プロセス中に行われたシークポイントの選択に基づいて各々がシークポイントから開始する複数のファイルにプレゼンテーションをセグメンテーションすることが有利であることができ、各ランダムアクセスポイントは、ファイルの先頭に配置すること又は配置しないことができるが、各ファイルは、ランダムアクセスポイントから開始する。上述される特性を有する一実施形態においては、プレゼンテーションメタデータ、又はメディアプレゼンテーション記述、は、各ファイルの正確な継続時間を含むことができ、継続時間は、例えばファイルの映像メディアの開始時間と次のファイルの映像メディアの開始時間との間の差分を意味するために用いられる。プレゼンテーションメタデータ内のこの情報に基づき、クライアントは、メディアプレゼンテーションのためのグローバルタイムラインと各ファイル内のメディアのためのローカルタイムラインとの間でのマッピングを構築することができる。

【0300】

他の実施形態においては、すべてのファイル又はセグメントが同じ継続時間を有することを代わりに指定することによってプレゼンテーションメタデータのサイズを有利に縮小することができる。しかしながら、この場合及びメディアファイルが上記の方法によって構築される場合は、ファイルの始めからの正確な指定された継続時間であるポイントにランダムアクセスポイントが存在しないことがあるため、各ファイルの継続時間は、メディアプレゼンテーション記述において指定された継続時間とまったく同じでないことがある。

【0301】

上記の食い違いにかかわらずブロック−要求ストリーミングシステムの正確な動作を提供するための本発明のさらなる実施形態が今度は説明される。この方法では、各ファイル内のメディアのローカルタイムライン（それは、ファイル内のメディアサンプルの復号及び構成タイムスタンプがＩＳＯ／ＩＥＣ １４４９６−１２により指定されるときの基準であるタイムスタンプゼロから開始するタイムラインを意味する）のグローバル提示タイムラインへのマッピングを指定する要素をそのファイル内において提供することができる。このマッピング情報は、ローカルファイルタイムライン内のゼロのタイプスタンプに対応するグローバル提示時間における単一のタイムスタンプを備えることができる。マッピング情報は、ローカルファイルタイムライン内のゼロのタイムスタンプに対応するグローバル提示時間とプレゼンテーションメタデータにおいて提供された情報によるファイルの始めに対応するグローバル提示時間との間の差分を指定するオフセット値を代替で備えることができる。

【0302】

該ボックスに関する例は、例えば、トラックフラグメント復号時間（‘ｔｆｄｔ’）ボックス又はトラックフラグメントメディア調整（‘ｔｆｍａ’）ボックスを伴うトラックフラグメント調整ボックス(‘ｔｆａｄ’)ボックスであることができる。

【0303】

セグメントリスト生成を含むクライアント例
今度はクライアント例が説明される。それは、サーバがＭＰＤの適切な生成及び更新を保証するための基準クライアントとして用いることができる。

【0304】

ＨＴＴＰストリーミングクライアントは、ＭＰＤ内で提供される情報によって誘導される。クライアントは、それが時間Ｔ、すなわち、それがＭＰＤを成功裏に受信することができた時間、に受信したＭＰＤへのアクセスを有することが仮定される。成功裏の受信であることを決定することは、クライアントが更新されたＭＰＤを入手すること又はＭＰＤが前回の成功裏の受信以来更新されていないことをクライアントが検証することを含むことができる。

【0305】

クライアントの動作例が紹介される。連続的なストリーミングサービスをユーザに提供するために、クライアントは、おそらくプレイリストを用いるか又はＵＲＬ構築規則を用いて以下において詳述されるセグメントリスト生成手順を考慮し、現在のシステム時間においてＭＰＤを最初に構文解析し、クライアントローカル時間のための各表現のためのアクセス可能セグメントのリストを生成する。次に、クライアントは、表現属性内の情報及びその他の情報、例えば利用可能な帯域幅及びクライアントの能力、に基づいて１つの又は複数の表現を選択する。グループ分類に依存して、表現は、単独で又はその他の表現とともに提示することができる。

【0306】

各表現に関して、クライアントは、存在する場合は、その表現のためのバイナリメタデータ、例えば“ｍｏｏｖ”ヘッダ、及び選択された表現のメディアセグメントを取得する。クライアントは、おそらくセグメントリストを用いて、セグメント又はセグメントのバイト範囲を要求することによってメディアコンテンツにアクセスする。クライアントは、提示を開始する前にメディアを最初にバッファリングし、プレゼンテーションがいったん開始した時点で、クライアントは、ＭＰＤ更新手順を考慮に入れてセグメント又はセグメントの一部を連続的に要求することによってメディアコンテンツを消費し続ける。

【0307】

クライアントは、それの環境からの更新されたＭＰＤ情報及び／又は更新された情報、例えば利用可能な帯域幅の変更、を考慮に入れて表現を切り換えることができる。ランダムアクセスポイントを含むメディアセグメント要求を用いることで、クライアントは、異なる表現に切り換わることができる。前方に移動するとき、すなわち、現在のシステム時間（提示に関する時間を表現するために“ＮＯＷ時間”と呼ばれる）が進行するときには、クライアントは、アクセス可能なセグメントを消費する。ＮＯＷ時間が進むごとに、クライアントは、ここにおいて指定される手順により各表現のためのアクセス可能なセグメントのリストをおそらく拡張する。

【0308】

メディアプレゼンテーションの最後にまだ到達していない場合で、現在の再生時間が、クライアントが何らかの消費中の又は消費される表現に関してＭＰＤにおいて記述されるメディアのメディア切れになると予想する限度であるスレショルド内に入る場合は、クライアントは、新しいフェッチ時間受信時間Ｔを有するＭＰＤの更新を要求することができる。受信された時点で、クライアントは、アクセス可能なセグメントリストの生成の際におそらく更新されたＭＰＤ及び新しい時間Ｔを考慮に入れる。図２９は、クライアントにおける異なる時間でのライブサービスのための手順を例示する。

【0309】

アクセス可能セグメントリスト生成
ＨＴＴＰストリーミングクライアントがＭＰＤへのアクセスを有し、実際の経過時間ＮＯＷのためのアクセス可能セグメントリストを生成することを希望すると仮定する。クライアントは、一定の精度でグローバル時間基準に合わせて同期化されるが、有利なことにＨＴＴＰストリーミングサーバとの直接的な同期化は要求されない。

【0310】

各表現のためのアクセス可能セグメントリストは、好ましくは、セグメント開始時間及びセグメントロケータのリスト対であると定義され、セグメント開始時間は、一般性を失うことなしに、表現の開始に関するものであると定義することができる。表現の始めは、期間の始めと又はこの概念が適用される場合に整合させることができる。そうでない場合は、表現開始は、メディアプレゼンテーションの始めであることができる。

【0311】

クライアントは、例えばここにおいてさらに定義されるようにＵＲＬ構築規則及びタイミングを使用する。記述されるセグメントのリストが入手された時点で、このリストは、アクセス可能なそれらにさらに制限され、それは、完全なメディアプレゼンテーションのセグメントの部分組であることができる。構築は、クライアントＮＯＷ時間におけるクロックの現在値によって制御される。概して、セグメントは、利用可能性時間の組内のいずれかの時間ＮＯＷの間のみに入手可能である。この窓の外側の時間ＮＯＷに関しては、いずれのセグメントも入手可能でない。さらに、ライブサービスに関して、何らかの時間チェックタイムが、どの程度の将来までメディアが記述されるかに関する情報を提供する。チェックタイムは、ＭＰＤ−ドキュメント化されたメディア時間軸上で定義され、クライアントの再生時間がチェックタイムに達したときに、それは、新しいＭＰＤを有利に要求する。

【0312】

；クライアントの再生時間がチェックタイムに達したときに、それは、新しいＭＰＤを有利に要求する。

【0313】

次に、セグメントリストは、ＭＰＤ属性ＴｉｍｅＳｈｉｆｔＢｕｆｆｅｒＤｅｐｔｈとともにチェックタイムによってさらに制限され、このため、唯一の入手可能なメディアセグメントは、メディアセグメントの開始時間と表現開始時間の合計が最後の記述されたセグメントのＮＯＷマイナスｔｉｍｅＳｈｉｆｔＢｕｆｆｅｒＤｅｐｔｈマイナス継続時間とチェックタイム又はＮＯＷのうちのいずれか小さい方の値との間の間隔内にあるそれらである。

【0314】

スケーラブルブロック
利用可能な帯域幅が時々非常に低くなり、受信機において現在受信中のブロック又はブロック（複数）が、提示を休止させずにプレイアウトする上で時間的に間に合うように完全に受信される可能性がなくなる。受信機は、該状況を事前に検出することができる。例えば、受信機は、それが６単位の時間ごとに５単位のメディアを符号化するブロックを受信中であり及び４単位のメディアのバッファを有することを決定することができ、このため、受信機は、約２４単位の時間後に提示を停止、又は休止させなければならないことを予想することができる。十分な通知を行うことで、受信機は、例えば、現在のブロックのストリームを廃棄することによって該状況に反応し、コンテンツの異なる表現からのブロック又はブロック（複数）、例えば、１単位のプレイアウト時間当たりより少ない帯域幅を使用するそれ、を要求することを開始することができる。例えば、受信機が、同じサイズのブロックに関して少なくとも２０％多い映像時間の間ブロックが符号化された表現に切り換わる場合は、受信機は、帯域幅状況が改善するまで停止する必要性をなくすことができる。

【0315】

しかしながら、廃棄された表現から既に受信されているデータを完全に捨てることを受信機に行わせることは浪費であろう。ここにおいて説明されるブロック−ストリーミングシステムの一実施形態においては、各ブロック内のデータは、受信されていない状態でブロックの残りの部分が提示を続けるためにブロック内のデータの一定の接頭辞を用いることができるような形で符号化及び手配することができる。例えば、スケーラブル映像符号化のよく知られた技法を用いることができる。該映像符号化法の例は、Ｈ．２６４スケーラブルビデオコーディング（ＳＶＣ）又はＨ．２６４アドバンストビデオコーディング（ＡＶＣ）の時間的スケーラビリティを含む。有利なことに、この方法は、例えば利用可能な帯域幅の変更に起因して、ブロック又はブロック（複数）の受信が廃棄されるときでも既に受信されているブロック部分に基づいて提示が継続することを可能にする。他の利点は、単一のデータファイルをコンテンツの複数の異なる表現のためのソースとして使用可能であることである。これは、例えば、要求される表現に対応するブロックの部分組を選択するＨＴＴＰ部分的ＧＥＴ要求を利用することによって可能である。

【0316】

ここにおいて詳述される一改良は、拡張されたセグメントであるスケーラブルセグメントマップである。スケーラブルセグメントマップは、セグメント内の異なる層の所在場所を含み、このため、クライアントは、適宜セグメントの諸部分にアクセスしてそれらの層を抽出することができる。他の実施形態においては、セグメント内のメディアデータは、セグメントの始めから徐々にデータをダウンロードしている間にセグメントの品質が上昇していくような順序が設定される。他の実施形態においては、品質の漸進的な上昇は、セグメントに含まれている各ブロック又はフラグメントに関して適用され、このため、スケーラブルな手法に対処するためにフラグメント要求を行うことができる。

【0317】

図１２は、スケーラブルブロックの態様を示した図である。その図では、送信機１２００は、メタデータ１２０２、スケーラブル層１（１２０４）、スケーラブル層２（１２０６）、及びスケーラブル層３（１２０８）を出力し、後者が遅延される。受信機１２１０は、メディアプレゼンテーション１２１２を提示するためにメタデータ１２０２、スケーラブル層１（１２０４）、及びスケーラブル層２（１２０６）を用いることができる。

【0318】

独立したスケーラビリティ層
上において説明されるように、受信機がメディデータアの特定の表現の要求されたブロックをそれのプレイアウトのために間に合う形で受信することができないときにブロック−要求ストリーミングシステムが停止しなければならないのは、不良なユーザ経験をしばしば生み出すため望ましくない。停止は、選択された表現のデータレートを利用可能な帯域幅よりも大幅に小さくなるように制限することによって回避、低減又は軽減することができ、このため、プレゼンテーションの所定の部分が時間内に受信されないことはほとんど起こりえないことになるが、この戦略は、メディア品質が利用可能な帯域幅によって原則的にサポート可能であるよりも必ず大幅に低下するという欠点を有する。可能なよりも低い品質のプレゼンテーションは、不良なユーザ経験であると解釈することができる。従って、ブロック−要求ストリーミングシステムの設計者は、利用可能な帯域幅よりも大幅に低いデータレートを有するコンテンツバージョンを要求するために、この場合はユーザは不良なメディア品質を被ることがあり、又は、利用可能な帯域幅に近いデータレートを有するコンテンツバージョンを要求するために、この場合はユーザは、利用可能な帯域幅が変化するのに応じた提示中に高い確率の休止を被ることがあり、クライアント手順の設計、クライアントのプログラミング又はハードウェアの構成における選択に直面する。

【0319】

該状況に対処するために、ここにおいて説明されるブロック−ストリーミングシステムは、受信機が層化された要求を行うことができ及び送信機が層化された要求に応答することができるように、複数のスケーラビリティ層を独立して処理するように構成することができる。

【0320】

該実施形態においては、各ブロックのための符号化されたメディアデータは、ここでは “層”と呼ばれる複数の切り離された部分に分割することができ、このため、層の組み合わせは、ブロックのためのメディアデータの全体を備え、及び、層の一定の部分組を受信しているクライアントは、コンテンツの表現の復号及び提示を行うことができる。この手法では、ストリーム内におけるデータの順序設定は、連続する範囲の品質が漸進的に向上する順序であり、メタデータがこれを反映する。

【0321】

上記の特性を有する層を生成するために用いることができる技法の一例は、例えばＩＴＵ−Ｔ規格Ｈ．２６４／ＳＶＣにおいて説明されるスケーラブルビデオコーディングの技法である。上記の特性を有する層を生成するために用いることができる技法の他の例は、ＩＴＵ−Ｔ規格Ｈ．２６４／ＡＶＣにおいて提供される時間的スケーラビリティ層の技法である。
これらの実施形態においては、メタデータは、所定のブロックの個々の層及び／又は複数のブロックの１つの所定の層及び／又は複数のブロックの層の組み合わせの要求の構築を可能にするＭＰＤ内又はセグメント自体内で提供することができる。例えば、ブロックを備える層は、単一のファイル内に格納することができ、及び、個々の層に対応するファイル内のバイト範囲を指定するメタデータを提供することができる。
個々の層又は複数の層を要求するためにバイト範囲を指定することが可能なファイルダウンロードプロトコル、例えばＨＴＴＰ１．１、を用いることができる。さらに、この開示を検討次第当業者にとって明確になるように、可変サイズのブロック又はブロックの可変の組み合わせの構築、要求及びダウンロードに関して上述される技法は、この状況においても同様に適用することができる。

【0322】

組み合わせ
上述されるような層に分割されたメディアデータの使用による既存の技法と比較した場合のユーザ経験の向上及び／又はサービングインフラストラクチャの能力に関する要求の軽減を達成させるためにブロック−要求ストリーミングクライアントによって有利に採用することができる幾つかの実施形態が今度は説明される。

【0323】

第１の実施形態においては、ブロック要求ストリーミングシステムの既知の技法を、コンテンツの異なるバージョンが幾つかの場合には層の異なる組み合わせに代えられる変更を行うことで適用することができる。すなわち、既存のシステムがコンテンツの２つの別個の表現を提供することができる場合は、ここにおいて説明される拡張されたシステムは２つの層を提供することができ、既存のシステムにおけるコンテンツの１つの表現は、拡張されたシステムにおける第１の層とビットレート、品質及びおそらくその他のメトリックの点で類似しており、既存のシステムにおけるコンテンツの第２の表現は、拡張されたシステムにおける２つの層の組み合わせとビットレート、品質及びおそらくその他のメトリックの点で類似する。その結果、拡張されたシステム内で要求される格納容量は、既存のシステムにおいて要求されるそれと比較して低減される。さらに、既存のシステムのクライアントは一方の表現又は他方の表現のブロックの要求を出すことができる一方で、拡張されたシステムのクライアントは、ブロックの第１の層又は両層のいずれかの要求を出すことができる。その結果、２つのシステムでのユーザ経験は類似する。さらに、異なる品質に関してもより高い尤度でキャッシングされる共通のセグメントが用いられるため向上されたキャッシングが提供される。

【0324】

第２の実施形態においては、今説明される層という方法を採用する拡張されたブロック−要求ストリーミングシステムにおけるクライアントは、メディア符号化の幾つかの層の各々のために別々のデータバッファを維持することができる。クライアントデバイス内でのデータ管理の当業者にとって明確になるように、これらの“別々の”バッファは、別々のバッファのための物理的に又は論理的に別々のメモリ領域の割り当てによって又はバッファリングされたデータが単一又は複数のメモリ領域に格納され及び異なる層からのデータの分離は別々の層からのデータの格納場所への参照を含むデータ構造の使用を通じて論理的に達成されるその他の技法によって実装することができ、このため、以降は、用語“別々のバッファ”は、別個の層のデータを別々に識別することができるあらゆる方法を含むことが理解されるべきである。クライアントは、各バッファの占有率に基づいて各ブロックの個々の層の要求を出し、例えば、層は、優先順においてより低い層のためのバッファの占有率がそのより低い層に関するスレショルドを下回る場合は１つの層からのデータの要求を出すことができないような形で優先順序を設定することができる。この方法では、優先順序がより低い層からのデータを受信することが優先され、このため、利用可能な帯域幅が優先順序のより高い層も受信するために要求されるそれを下回る場合は、より低い層のみが要求される。さらに、異なる層と関連付けられたスレショルドは異なることができ、従って、例えばより低い層がより高いスレショルドを有する。より高い層のためのデータをブロックのプレイアウト時間前に受信できないような形で利用可能な帯域幅が変化する事例においては、より低い層のためのデータが必ず既に受信されていることになり、このため、より低い層のみで提示が続くことができる。バッファ占有率に関するスレショルドは、データのバイト、バッファに含まれるデータのプレイアウト継続時間、ブロック数又はあらゆるその他の適切な尺度に関して定義することができる。

【0325】

第３の実施形態においては、第１及び第２の実施形態の方法を組み合わせることができ、このため、各々が（第１の実施形態と同じように）層の部分組を備える複数のメディア表現が提供され及び第２の実施形態が表現内の層の部分組に適用される。

【0326】

第４の実施形態においては、第１、第２及び／又は第３の実施形態の方法を、コンテンツの複数の独立した表現が提供される実施形態と組み合わせることができ、このため、例えば、独立した表現のうちの少なくとも１つは、第１、第２及び／又は第３の実施形態の技法が適用される複数の層を備える。

【0327】

拡張バッファマネージャ
バッファモニタ１２６（図２参照）との組み合わせにおいて、クライアント側バッファを最適化するために拡張されたバッファマネージャを用いることができる。ブロック−要求ストリームシステムは、ユーザ又は行先デバイスに最高のメディア品質を同時に提供しながらメディアのプレイアウトが素早く開始してスムーズに続くことを希望する。これは、クライアントが最高のメディア品質を有するが素早く開始させることもでき及びその後に提示の休止を強制することなしにプレイアウトされるのに間に合って受信することができるブロックを要求するように要求することができる。

【0328】

拡張されたバッファマネージャを用いる実施形態においては、マネージャは、いずれのメディアデータのブロックを要求すべきか及びそれらの要求をいつ行うべきかを決定する。拡張されたバッファマネージャは、例えば、提示されるコンテンツのためのメタデータの組を提供することができ、このメタデータは、コンテンツのために入手可能な表現及び各表現のためのメタデータのリストを含む。表現のためのメタデータは、表現のデータレート及びその他のパラメータ、例えば映像、音声又はその他のコーデック及びコーデックパラメータ、映像解像度、復号の複雑さ、音声言語及びクライアントにおける表現の選択に影響を及ぼすことがあるその他のパラメータに関する情報を備えることができる。

【0329】

表現のためのメタデータは、その表現がセグメンテーションされているブロックに関する識別子を備えることもでき、これらの識別子は、クライアントがブロックを要求するために必要な情報を提供する。例えば、要求プロトコルがＨＴＴＰである場合は、識別子は、おそらくＨＴＴＰ ＵＲＬによって識別されたファイル内でのバイト範囲又は時間スパンを識別する追加情報を伴うＨＴＴＰ ＵＲＬであることができ、このバイト範囲又は時間スパンは、ＵＲＬによって識別されたファイル内の特定のブロックを識別する。

【0330】

具体的な実装において、拡張されたバッファマネージャは、受信機が新しいブロックの要求をいつ行うかを決定し、それ自体で要求の送信を取り扱うことができる。新規の態様においては、拡張されたバッファマネージャは、ストリーミングプレイアウト中に過度に多くの帯域幅を使用することとメタデータがなくなることとの間でバランスをとるバランス比の値により新しいブロックの要求を行う。

【0331】

ブロックバッファ１２５からバッファモニタ１２６によって受信された情報は、メディアデータが受信されたときの各イベント、どれだけの量が受信されているか、メディアデータのプレイアウトがいつ開始及び停止しているか、及びメディアプレイアウトの速度の指示を含むことができる。この情報に基づき、バッファモニタ１２６は、現在のバッファサイズＢ_{ｃｕｒｒｅｎｔ}を表す変数を計算することができる。これらの例では、Ｂ_{ｃｕｒｒｅｎｔ}は、クライアント又はその他のデバイスバッファ又はバッファ（複数）に含められているメディアの量を表し、時間の単位で測定することができ、このため、Ｂ_{ｃｕｒｒｅｎｔ}は、追加のブロック又は部分的ブロックが受信されない場合にバッファ又はバッファ（複数）に格納されているブロック又は部分的ブロックによって表現される全メディアをプレイアウトするのにかかる時間量を表す。従って、Ｂ_{ｃｕｒｒｅｎｔ}は、クライアントにおいて入手可能であるがまだ再生されていないメディアデータの、通常のプレイアウト速度での“プレイアウト継続時間”を表す。

【0332】

時間が経過するのに従い、メディアがプレイアウトされるのに応じてＢ_{ｃｕｒｒｅｎｔ}の値が減少し、ブロックのための新しいデータが受信されるごとに増加することができる。この説明の目的上、ブロックは、そのブロックのデータ全体がブロック要求器１２４において入手可能であるときに受信されたと仮定されるが、例えば部分的ブロックの受信を考慮に入れるためにその他の尺度を代わりに用いることができることに注目すること。実際上は、ブロックの受信は、１つの期間にわたって行うことができる。

【0333】

図１３は、メディアがプレイアウトされてブロックが受信されるのに応じた経時でのＢ_{ｃｕｒｒｅｎｔ}の値の変動を例示する。図１３に示されるように、Ｂ_{ｃｕｒｒｅｎｔ}の値は、ｔ_０よりも小さい時間に関してはゼロであり、データが受信されていないことを示す。ｔ_０では、第１のブロックが受信され、Ｂ_{ｃｕｒｒｅｎｔ}の値は、受信されたブロックのプレイアウト継続時間に等しくなるまで増加する。この時点で、プレイアウトはまだ開始しておらず、このため、Ｂ_{ｃｕｒｒｅｎｔ}の値は、時間ｔ_１まで引き続き一定であり、その時点で、第２のブロックが到着し、Ｂ_{ｃｕｒｒｅｎｔ}は、この第２のブロックのサイズ分だけ増加する。この時点で、プレイアウトが開始し、Ｂ_{ｃｕｒｒｅｎｔ}の値が時間ｔ_２まで直線的に減少し始め、その時点で第３のブロックが到着する。

【0334】

Ｂ_{ｃｕｒｒｅｎｔ}の展開はこの“鋸歯”方式で継続し、（時間ｔ_２、ｔ_３、ｔ_４、ｔ_５及びｔ_６において）ブロックが受信されるごとに段階的に増加し、その間にデータがプレイアウトされるのに応じてスムーズに減少する。この例では、プレイアウトはコンテンツのための通常のプレイアウト速度で進行し、このため、ブロック受信間の曲線の傾きは正確に−１であり、経過した実時間の各１秒に関して１秒のメディアデータが再生されることを意味する。フレームに基づくメディアが１秒当たりの所定のフレーム数、例えば、１秒当たり２４フレーム、においてプレイアウトされた状態では、−１の傾きは、各々の個々のデータフレームのプレイアウトを示す小さいステップ関数、例えば、各フレームがプレイアウトされるときに１秒の−１／２４のステップ、によって概算される。
図１４は、経時でのＢｃｕｒｒｅｎｔの展開の他の例を示す。その例では、第１のブロックはｔ_０において到着し、プレイアウトが直ちに開始する。ブロックの到着及び再生は、ｔ_３まで続き、その時点で、Ｂ_{ｃｕｒｒｅｎｔ}の値がゼロに達する。それが起きたときには、プレイアウトのためのさらなるメディアデータは存在せず、メディア提示の休止を強制する。時間ｔ_４において、第４のブロックが受信されてプレイアウトが再開することができる。従って、この例は、第４のブロックの受信が希望されるよりも遅く、その結果プレイアウトが休止され従って不良なユーザ経験が生じる事例を示す。このように、拡張されたバッファマネージャ及びその他の特徴の最終目標は、高いメディア品質を同時に維持しながらこのイベントの確率を低下させることである。

【0335】

バッファモニタ１２６は、所定の期間に受信されたメディアとその期間の長さの比である他のメトリック、Ｂ_{ｒａｔｉｏ}（ｔ）を計算することもできる。より具体的には、Ｂ_{ｒａｔｉｏ}（ｔ）は、Ｔ_{ｒｅｃｅｉｖｅｄ}／（Ｔ_ｎｏｗ−ｔ）と等しく、Ｔ_{ｒｅｃｅｉｖｅｄ}は、現在の時間よりも早いある時間であるｔから現在の時間Ｔ_ｎｏｗまでの期間において受信された（それのプレイアウト時間によって測定された）メディアの量である。

【0336】

Ｂ_{ｒａｔｉｏ}（ｔ）は、Ｂ_{ｃｕｒｒｅｎｔ}の変化率を測定するために用いることができる。Ｂ_{ｒａｔｉｏ}（ｔ）＝０は、時間ｔ以降にデータが受信されていない事例であり、メディアをプレイアウト中であると仮定した場合、Ｂ_{ｃｕｒｒｅｎｔ}は、その時間以降に（Ｔ_ｎｏｗ−ｔ）だけ減少されていることになる。Ｂ_{ｒａｔｉｏ}（ｔ）＝１は、時間（Ｔ_ｎｏｗ−ｔ）に関してメディアがプレイアウト中であるのと同じ量だけ受信される事例であり、Ｂ_{ｃｕｒｒｅｎｔ}は、時間ｔと同じ値を時間Ｔ_ｎｏｗにおいて有することになる。Ｂ_{ｒａｔｉｏ}（ｔ）＞１は、時間（Ｔ_ｎｏｗ−ｔ）に関してプレイアウトするために必要であるよりも多いデータが受信されている事例であり、Ｂ_{ｃｕｒｒｅｎｔ}は、時間ｔから時間Ｔ_ｎｏｗに増加していることになる。

【0337】

バッファモニタ１２６は、値Ｓｔａｔｅ（状態）をさらに計算し、それは、別個の値数をとることができる。バッファモニタ１２６は、関数ＮｅｗＳｔａｔｅ（Ｂ_{ｃｕｒｒｅｎｔ}， Ｂ_ｒａｉｏ）をさらに装備し、それは、ｔ＜Ｔ_ｎｏｗに関してＢ_{ｃｕｒｒｅｎｔ}の現在値及びＢ_{ｒａｔｉｏ}の値が与えられた場合、新しいＳｔａｔｅ値を出力として提供する。Ｂ_{ｃｕｒｒｅｎｔ}及びＢ_{ｒａｔｉｏ}がＳｔａｔｅの現在値と異なる値を戻すことをこの関数に行わせるごとに、新しい値がＳｔａｔｅに割り当てられ、この新しいＳｔａｔｅ値がブロック選択器１２３に示される。

【0338】

関数ＮｅｗＳｔａｔｅは、対（Ｂ_{ｃｕｒｒｅｎｔ}，Ｂ_{ｒａｔｉｏ}（Ｔ_ｎｏｗ−Ｔ_ｘ）のすべての可能な値のスペースを参照して評価することができ、ここで、Ｔ_ｘは、固定された（設定された）値であることができ、又は、例えばＢ_{ｃｕｒｒｅｎｔ}の値からＴ_ｘの値にマッピングする設定テーブルによってＢ_{ｃｕｒｒｅｎｔ}から導き出すことができ又はＳｔａｔｅの前値に依存することができる。バッファモニタ１２６は、このスペースの１つ以上のパーティショニングが供給され、各パーティショニングは、切り離された領域の組を備え、各領域は、Ｓｔａｔｅ値を用いて注釈される。これで、関数ＮｅｗＳｔａｔｅの評価は、パーティショニングを識別し及び対（Ｂ_{ｃｕｒｒｅｎｔ}，Ｂ_ｒａｉｏ（Ｔ_ｎｏｗ−Ｔ_ｘ）が入る領域を決定する動作を備える。これで、戻り値は、その領域と関連付けられた注釈である。単純な事例では、１つのパーティショニングのみが提供される。それよりも複雑な事例では、パーティショニングは、ＮｅｗＳｔａｔｅ関数の前評価時間における対(Ｂ_{ｃｕｒｒｅｎｔ}，Ｂ_{ｒａｔｉｏ}（Ｔ_ｎｏｗ−Ｔ_ｘ）)に又はその他の要因に依存することができる。

【0339】

１つの具体的に実施形態において、上述されるパーティショニングは、Ｂ_{ｃｕｒｒｅｎｔ}のための幾つかのスレショルド値とＢ_{ｒａｔｉｏ}のための幾つかのスレショルド値とを含む設定テーブルに基づくことができる。具体的には、Ｂ_{ｃｕｒｒｅｎｔ}のためのスレショルド値をＢ_{ｔｈｒｅｓｈ}（０）＝０、Ｂ_{ｔｈｒｅｓｈ}（１）、．．．、Ｂ_{ｔｈｒｅｓｈ}（ｎ_１）、Ｂ_{ｔｈｒｅｓｈ}（ｎ_１＋１）＝∞とし、ここで、ｎ_１は、Ｂ_{ｃｕｒｒｅｎｔ}のためのゼロ以外のスレショルド値の数である。Ｂ_{ｒａｔｉｏ}のためのスレショルド値をＢ_{ｒ−ｔｈｒｅｓｈ}（０）＝０、Ｂ_{ｒ−ｔｈｒｅｓｈ}（１）、．．．、Ｂ_{ｒ−ｔｈｒｅｓｈ}（ｎ_２）、Ｂ_{ｒ−ｔｈｒｅｓｈ}（ｎ_２＋１）＝∞とし、ここで、ｎ_２は、Ｂ_{ｒａｔｉｏ}のためのスレショルド値の数である。これらのスレショルド値は、（ｎ_１＋１）×（ｎ_２＋１）の格子のセルを備えるパーティショニングを定義し、ここで、ｊ番目の行のｉ番目のセルは、Ｂ_{ｔｈｒｅｓｈ}（ｉ−１）≦Ｂ_{ｃｕｒｒｅｎｔ}＜Ｂ_{ｔｈｒｅｓｈ}（ｉ）及びＢ_{ｒ−ｔｈｒｅｓｈ}（ｊ−１）≦Ｂ_{ｒａｔｉｏ}＜Ｂ_{ｒ−ｔｈｒｅｓｈ}（ｊ）である領域に対応する。上述される格子の各セルは、例えばメモリに格納された特定の値と関連付けることによって、状態値を用いて注釈され、関数ＮｅｗＳｔａｔｅは、値Ｂ_{ｃｕｒｒｅｎｔ}及びＢ_{ｒａｔｉｏ}（Ｔ_ｎｏｗ−Ｔ_ｘ）によって示されるセルと関連付けられた状態値を戻す。

【0340】

さらなる実施形態においては、ヒステリシス値を各スレショルド値に関連付けることができる。この拡張された方法では、関数ＮｅｗＳｔａｔｅの評価は、次のように、一時的に変更されたスレショルド値の組を用いて構築された一時的パーティショニングに基づくことができる。ＮｅｗＳｔａｔｅの最後の評価時に選択されたセルに対応するＢ_{ｃｕｒｒｅｎｔ}範囲よりも小さい各Ｂ_{ｃｕｒｒｅｎｔ}スレショルド値に関しては、スレショルド値は、そのスレショルドと関連付けられたヒステリシス値を減じることによって減少される。ＮｅｗＳｔａｔｅの最後の評価時に選択されたセルに対応するＢ_{ｃｕｒｒｅｎｔ}範囲よりも大きい各Ｂ_{ｃｕｒｒｅｎｔ}スレショルド値に関しては、スレショルド値は、そのスレショルドと関連付けられたヒステリシス値を加えることによって増加される。ＮｅｗＳｔａｔｅの最後の評価時に選択されたセルに対応するＢ_{ｒａｔｉｏ}範囲よりも小さい各Ｂ_{ｒａｔｉｏ}スレショルド値に関しては、スレショルド値は、そのスレショルドと関連付けられたヒステリシス値を減じることによって減少される。ＮｅｗＳｔａｔｅの最後の評価時に選択されたセルに対応するＢ_{ｒａｔｉｏ}範囲よりも大きい各Ｂ_{ｒａｔｉｏ}スレショルド値に関しては、スレショルド値は、そのスレショルドと関連付けられたヒステリシス値を加えることによって増加される。変更されたスレショルド値は、ＮｅｗＳｔａｔｅの値を評価するために用いられ、次に、スレショルド値はそれらの原値に戻される。

【0341】

この開示を読み次第スペースのパーティショニングを定義するその他の方法が当業者にとって明白になるであろう。例えば、パーティショニングは、Ｂ_{ｒａｔｉｏ}及びＢ_{ｃｕｒｒｅｎｔ}の線形の組み合わせに基づく不等式、例えば、全体的スペース内でハーフスペースを定義するための実値が与えられたα０、α１、及びα２の場合の形態α１・Ｂ_{ｒａｔｉｏ}＋α２・Ｂ_{ｃｕｒｒｅｎｔ}≦α０の線形不等式スレショルドを使用し、各々の互いに素の集合を幾つかの該ハーフスペースの交点として定義することによって定義することができる。

【0342】

上記の説明は、基本的なプロセスの例示である。この開示を読み次第リアルタイムプログラミングの当業者にとって明確になるように、効率的な実装が可能である。例えば、バッファモニタ１２６に新情報が提供されるごとに、例えばブロックのためのさらなるデータが受信されない場合にＮｅｗＳｔａｔｅが新値に移行する将来の時間を計算することが可能である。この時間に関してタイマが設定され、さらなる入力が存在しない場合は、このタイマの時間切れは、新しいＳｔａｔｅ値をブロック選択１２３に送信させる。その結果、計算は、連続的ではなく、バッファモニタ１２６に新情報が提供されたとき又はタイマが時間切れになったときのみに行う必要がある。

【0343】

Ｓｔａｔｅの適切な値は、“低”（Ｌｏｗ）、“安定”（Ｓｔａｂｌｅ）及び“フル”（Ｆｕｌｌ）であることができる。スレショルド値の適切な組の例及びその結果得られるセル格子が図１５に示される。

【0344】

図１５において、Ｂ_{ｃｕｒｒｅｎｔ}スレショルドは単位がミリ秒の横軸上に示され、ヒステリシス値は、“＋／−値”として下方に示される。Ｂ_{ｒａｔｉｏ}スレショルドは、単位がパーミル（すなわち、１０００によって乗じられる）の縦軸上に示され、ヒステリシス値は、“＋／−値”として下方に示される。状態値は、“低”、“安定”及び“フル”を表すそれぞれの“Ｌ”、“Ｓ”及び“Ｆ”として格子セル内で注釈される。

【0345】

ブロック選択器１２３は、新しいブロックを要求する機会が存在するごとにブロック要求器１２４から通知を受信する。上述されるように、ブロック選択器１２３は、複数の入手可能なブロック及びそれらのブロックのためのメタデータに関する情報が提供され、例えば各ブロックのメディアデータレートに関する情報を含む。

【0346】

ブロックのメディアデータレートに関する情報は、特定のブロックの実際のメディアデータレート（すなわち、単位がバイトのブロックサイズを単位が秒のプレイアウト時間で割った値）、ブロックが属する表現の平均メディアデータレート又はブロックが属する表現を休止なしでプレイアウトするために持続的に要求される利用可能な帯域幅の尺度、又は上記の組み合わせを備えることができる。

【0347】

ブロック選択器１２３は、バッファモニタ１２６によって最後に示されたＳｔａｔｅ値に基づいてブロックを選択する。このＳｔａｔｅ値が“安定”であるときには、ブロック選択器１２３は、前の選択されたブロックと同じ表現からブロックを選択する。選択されたブロックは、メディアデータが以前に要求されていない提示における期間に関するメディアデータを含む第１のブロック（プレイアウト順）である。

【0348】

Ｓｔａｔｅ値が“低”であるときには、ブロック選択器１２３は、前に選択されたブロックのメディアデータレートよりも低いそれを有する表現からブロックを選択する。この事例における表現の正確な選択に対しては幾つかの要因が影響を及ぼす可能性がある。例えば、ブロック選択器１２３は、着信したデータの総合レートの指示を提供することができ及びその値よりも小さいメディアデータレートを有する表現を選択することができる。

【0349】

Ｓｔａｔｅ値が“フル”であるときには、ブロック選択器１２３は、前に選択されたブロックのメディアデータレートよりも高いそれを有する表現からブロックを選択する。この事例における表現の正確な選択に対しては幾つかの要因が影響を及ぼす可能性がある。例えば、ブロック選択器１２３には、着信したデータの総合レートの指示を提供することができ及びその値よりも大きくないメディアデータレートを有する表現を選択することができる。

【0350】

幾つかの追加の要因がブロック選択器１２３の動作に対してさらに影響を及ぼすことがある。特に、バッファモニタ１２６が“フル”状態を引き続き示す場合でさえも、選択されたブロックのメディアデータレートが増加される頻度を制限することができる。さらに、ブロック選択器１２３は、“フル”状態の指示を受信するが、（例えば、最後に選択されたブロックが最高の利用可能なメディアデータレートのために既に存在していたため）より高い利用可能なメディアデータレートのブロックが存在しない可能性がある。この事例では、ブロック選択器１２３は、ブロックバッファ１２５においてバッファリングされたメディアデータの全体量が上記のように制限されるように選択された時間だけ次のブロックの選択を遅延させることができる。

【0351】

追加の要因が、選択プロセス中に考慮されるブロックの組に対して影響を及ぼすことがある。例えば、利用可能なブロックは、符号化解像度がブロック選択器１２３に提供された特定の範囲内に入る表現からのそれらに制限することができる。

【0352】

ブロック選択器１２３は、システムのその他の態様、例えば、メディア復号のための計算リソースの入手可能性、をモニタリングするその他のコンポーネントから入力を受信することもできる。該リソースが欠乏した場合は、ブロック選択器１２３は、メタデータ内において復号の計算の複雑さがより低いことが示されているブロックを選択することができる（例えば、より低い解像度又はフレームレートを有する表現は、概して復号の複雑さがより低い）。

【0353】

上述される実施形態は、バッファモニタ１２６内でのＮｅｗＳｔａｔｅ関数の評価における値Ｂ_{ｒａｔｉｏ}の使用がＢ_{ｃｕｒｒｅｎｔ}のみを考慮する方法と比較して提示の開始時におけるより高速での品質上昇を可能にするという点で実質的な利点をもたらす。Ｂ_{ｒａｔｉｏ}を考慮しない場合は、システムがより高いメディアデータレート、そしてそれによるより高い品質を有するブロックを選択することができる前に大量のバッファリングされたデータが蓄積することがある。しかしながら、Ｂ_{ｒａｔｉｏ}値が高いときには、これは、利用可能な帯域幅が以前に受信されたブロックのメディアデータレートよりもはるかに高いこと及び相対的に小さいバッファリングされたデータ（すなわち、Ｂ_{ｃｕｒｒｅｎｔ}のための低値）の場合でも引き続きより高いメディアデータレート、そしてそれによるより高い品質を有するブロックを要求しても安全であることを示す。同様に、Ｂ_{ｒａｔｉｏ}値が低い（例えば、＜１）である場合は、これは、利用可能な帯域幅が以前に要求されたブロックのメディアデータレートよりも落ちていることを示し、従って、Ｂ_{ｃｕｒｒｅｎｔ}が高い場合でも、システムは、例えばＢ_{ｃｕｒｒｅｎｔ}＝０でメディアのプレイアウトが停止するポイントに達するのを回避するために、より低いメディアデータレート、従ってより低い品質に切り換わる。この向上された動作は、ネットワーク状態そして従って配信速度が急速かつ動的に変化することがある、例えばユーザがモバイルデバイスにストリーミングする、環境において特に重要であることができる。

【0354】

他の利点は、(Ｂ_{ｃｕｒｒｅｎｔ}，Ｂ_{ｒａｔｉｏ})の値のスペースのパーティショニングを指定する設定データの使用によって与えられる。該設定データは、プレゼンテーションメタデータの一部として又はその他の動的な手段によってバッファモニタ１２６に提供することができる。実際の配備では、ユーザネットワークコネクションの挙動はユーザ間で及び単一のユーザに関しては経時で大きく変化しやすいため、全ユーザにとって適切に機能するパーティショニングを予測するのは困難であろう。該設定情報を動的にユーザに提供することが可能であることは、良好な設定値を蓄積された経験により経時で策定するのを可能にする。

【0355】

可変要求サイズ設定
各要求が単一のブロックに関するものである場合及び各ブロックが短いメディアセグメントに関して符号化する場合は、高い頻度の要求が要求されることがある。メディアブロックが短い場合は、映像プレイアウトは、ブロックからブロックへ急速に移動しており、それは、受信機が表現を変更することによってそれの選択されたデータレートを調整又は変更するためのより頻繁な機会を提供し、プレイアウトが停止せずに続くことができる確率を向上させる。しかしながら、高い頻度の要求の欠点は、無線ＷＡＮネットワーク、例えば３Ｇ及び４Ｇ無線ＷＡＮにおいて、利用可能な帯域幅がクライアントにおいてサーバネットワークに制約される一定のネットワークでは持続可能でないことがあり、例えば、クライアントからネットワークへのデータリンクの容量が無線状態の変化に起因して短期間又は長期間制限されるか又は制限される可能性があることである。

【0356】

高い頻度の要求は、サービングインフラストラクチャに対する高い負荷も暗に意味し、それは、容量要求の点での関連コストを発生させる。従って、すべての欠点なしに高い頻度の要求の利益の一部を有するのが望ましいであろう。

【0357】

ブロックストリーミングシステムの幾つかの実施形態においては、高い要求頻度の柔軟性がより低い頻度の要求と結合される。この実施形態においては、ブロックは、上述されるように構築し、同じく上述されるように、まとめて複数のブロックを含むセグメントにすることができる。提示開始時において、提示開始時の高速のチャネルザッピング時間そして従って良好なユーザ経験を保証するためにブロックの一部が適用されるように要求するために各要求が単一のブロック又は複数の同時並行した要求を参照する上述のプロセスが行われる。引き続き、以下において説明される一定の条件が満たされるときに、クライアントは、単一の要求において複数のブロックを包含する要求を出すことができる。これは、ブロックがより大きいファイル又はセグメントにまとめられておりバイト又は時間範囲を用いて要求できることを理由として可能である。連続するバイト又は時間範囲を単一のより大きいバイト又は時間範囲にまとめることができ、その結果、複数のブロックに関して単一の要求を行うことができ、不連続ブロックでさえも１回の要求で要求することができる。

【0358】

単一のブロック（又は部分的ブロック）を要求すべきか又は複数の連続するブロックを要求すべきかを決定することによって推進することができる１つの基本構成は、要求されたブロックがプレイアウトされる見込みであるかどうかの決定をその構成の基礎にすることである。例えば、まもなく他の表現に変わることが必要になる見込みである場合は、クライアントは単一のブロック、すなわち、少量のメディアデータ、の要求を行うのがより良い。これの１つの理由は、他の表現への切り換えが差し迫っているときに複数のブロックの要求が行われた場合は、その切り換えは要求の最後の数ブロックがプレイアウトされる前に行われることがあるためである。このように、これらの最後の数ブロックのダウンロードは、切り換えが行われる先である表現のメディアデータの配信を遅延させることがあり、それは、メディアのプレイアウトの停止を引き起こす可能性がある。

【0359】

しかしながら、単一のブロックの要求は、その結果確実により高い頻度の要求になる。他方、まもなく他の表現に変更することが必要になる見込みがない場合は、複数のすべてのブロックがプレイアウトされる見込みであるため、これらのブロックの要求を行うのが好ましいことになり、この結果より低い頻度の要求になり、それは、特に表現の差し迫った変更が存在しないのが典型的である場合に、要求オーバーヘッドを実質的に低減させることができる。

【0360】

従来のブロック集合システムでは、各要求において要求される量は動的に調整されず、すなわち、典型的には、各要求は、ファイル全体が対象であり、又は、各要求は、表現のファイルのほぼ同じ量が対象である（時折時間の単位で、時折バイトの単位で測定される）。従って、全要求がそれよりも小さい場合は、要求オーバーヘッドが高く、他方、全要求がそれよりも大きい場合は、これは、メディア停止イベントの機会を増大させ、及び／又はネットワーク状態が変化するのに応じて表現を素早く変更しなければならないことを回避するためにより低品質の表現が選択される場合はより低い品質のメディアプレイアウトを提供する。

【0361】

満たされたときに後続する要求に複数のブロックを参照させることができる条件の例は、バッファサイズＢ_{ｃｕｒｒｅｎｔ}に関するスレショルドである。Ｂ_{ｃｕｒｒｅｎｔ}がスレショルドを下回る場合は、出された各要求は、単一のブロックを参照する。Ｂ_{ｃｕｒｒｅｎｔ}がスレショルドよりも大きいか又は等しい場合は、出された各要求は、複数のブロックを参照する。複数のブロックを参照する要求が出された場合は、各々の単一の要求において要求されるブロック数は、幾つかの可能な方法のうちの１つで決定することができる。例えば、その数は一定、例えば２、であることができる。代替として、単一の要求において要求されるブロックの数は、バッファ状態そしてとくにＢ_{ｃｕｒｒｅｎｔ}に依存することができる。例えば、幾つかのスレショルドを設定することができ、単一の要求において要求されるブロックの数は、Ｂ_{ｃｕｒｒｅｎｔ}未満である複数のスレショルドのうち最高のものから導き出される。

【0362】

満たされたときに要求に複数のブロックを参照させることができる条件の他の例は、上述される可変値Ｓａｔｅ（状態）である。例えば、Ｓｔａｔｅが“安定”又は“フル”であるときには、要求は、複数のブロックを対象にして出すことができるが、Ｓｔａｔｅが “低”であるときには、全要求が１つのブロックを対象にすることができる。

【0363】

他の実施形態が図１６に示される。この実施形態においては、次の要求が出されるときに（ステップ１３００において決定）、次の要求のサイズを決定するために現在のＳａｔｅ値及びＢｃｕｒｒｅｎｔが用いられる。現在のＳａｔｅ値が“低”であるか又は現在のＳｔａｔｅ値が“フル”であり、現在の表現が入手可能な最高のものでない（ステップ１３１０で決定され、答えが“はい”である）場合は、次の要求は、例えばまさに次のブロックのために短くなるように選択される（ステップ１３２０において決定されたブロック及び行われた要求）。これの論理的根拠は、これらが、きわめてまもなく表現の変更が存在することになる見込みである状態であることである。現在のＳｔａｔｅ値が“安定”であるか又は現在のＳｔａｔｅ値が“フル”であり、現在の表現が入手可能な最高のものである（ステップ１１３０において決定され、答えが“いいえ”）場合は、次の要求において要求される連続するブロックの継続時間は、何らかの固定されたα＜１に関するＢ_{ｃｕｒｒｅｎｔ}のα部分に比例するように選択され（ステップ１３３０で決定されたブロック、ステップ１３４０で行われた要求）、例えば、α＝０．４に関して、Ｂ_{ｃｕｒｒｅｎｔ}＝５秒の場合は、次の要求は約２秒のブロックを対象にすることができ、Ｂ_{ｃｕｒｒｅｎｔ}＝１０秒の場合は、次の要求は、約４秒のブロックを対象にすることができる。これの１つの論理的根拠は、これらの状態においては、Ｂ_{ｃｕｒｒｅｎｔ}に比例する時間量の間に新しい表現への切り換えが行われる見込みはないことである。

【0364】

柔軟なパイプライン化
ブロック−ストリーミングシステムは、特定の基礎になる転送プロトコル、例えばＴＣＰ／ＩＰ、を有するファイル要求プロトコルを用いることができる。ＴＣＰ／ＩＰ又はその他の転送プロトコル接続の開始時には、完全な利用可能な帯域幅の利用を達成させるために相当の時間がかかることがある。この結果、新しい接続が開始されるごとに“コネクション立ち上がり上の不利益”を被ることがある。例えば、ＴＣＰ／ＩＰの場合は、コネクション立ち上がり上の不利益は、コネクションを確立するための最初のＴＣＰハンドシェークのためにかかる時間及び利用可能な帯域幅の完全な利用を達成させるための混雑制御プロトコルのためにかかる時間の両方に起因して発生する。

【0365】

この事例においては、コネクション立ち上がり上の不利益を被る頻度を低下させるために、単一のコネクションを用いて複数の要求を出すことが望ましいであろう。しかしながら、幾つかのファイル転送プロトコル、例えばＨＴＴＰ、は、転送層のコネクションを完全に閉じる以外は要求を取り消すメカニズムを提供せず、それにより、旧コネクションの代わりに新しいそれが確立されるときにコネクション立ち上がり上の不利益が発生する。出された要求は、利用可能な帯域幅が変化しており及び異なるメディアデータレートが代わりに要求されることが決定された、すなわち、異なる表現への切り換え決定が存在する、場合に取り消す必要があることがある。出された要求を取り消す他の理由は、メディアプレゼンテーションを終了させて（おそらくプレゼンテーションにおける異なるポイントにおける同じコンテンツ項目又はおそらく新しいコンテンツ項目の）新しいプレゼンテーションを開始させることをユーザが要求している場合であることができる。

【0366】

知られるように、コネクション立ち上がり上の不利益は、コネクションを開いた状態にし、後続する要求のために同じコネクションを再使用することによって回避することができ、同じく知られるように、複数の要求が同じコネクション上で同時に出される場合にコネクションを完全に利用される状態に維持することができる（ＨＴＴＰの文脈において“パイプライン化”と呼ばれる技法）。しかしながら、同時に、又はより概して、以前の要求がコネクションを通じて完了する前に複数の要求が出されるような形で複数の要求を出すことの欠点は、コネクションがそれらの要求への応答を搬送することに投入されることであり、このため、出されるべきである要求の変更が望ましくなった場合は、既に出されているもはや希望されない要求を取り消すことが必要になった場合にコネクションを閉じることができる。

【0367】

出された要求を取り消す必要がある確率は、要求を出すことと要求されたブロックのプレイアウト時間との間の時間間隔が大きいときには（利用可能な帯域幅がその間隔中に変化する可能性があることに起因して）出された要求を取り消す必要がある確率も高いという意味でこの時間間隔の継続時間に部分的に依存することがある。

【0368】

知られるように、幾つかのファイルダウンロードプロトコルは、単一の基礎になるトランスポート層コネクションを複数のダウンロード要求のために有利に用いることができるという特性を有する。例えば、ＨＴＴＰは、複数の要求のための単一のコネクションの再使用が、最初以外の要求に関する上述される“コネクション立ち上がり上の不利益”を回避するためこの特性を有する。しかしながら、この手法の１つの欠点は、各々の出された要求内の要求されたデータを転送することにコネクションが投入され、従って、要求又は要求（複数）を取り消す必要がある場合にコネクションが閉じられることがあり、代用コネクションが確立されるときにコネクション立ち上がり上の不利益を被るか、又は、クライアントがもはや必要ないデータを受信するのを待ち、後続するデータの受信遅延を引き起こすことがあることである。

【0369】

今度は、この欠点を被らずにコネクションを再使用する利点を保持し及びコネクションを再使用できる頻度をさらに向上させる実施形態を説明する。

【0370】

ここにおいて説明されるブロック−ストリーミングシステムの実施形態は、開始時にコネクションを特定の要求の組に投入する必要なしに複数の要求のためにコネクションを再使用するように構成される。基本的には、既存のコネクションにおいて既に出されている要求がまだ完了してないが完了間近であるときにはそのコネクション上で新しい要求が出される。既存の要求が完了するまで待たない１つの理由は、以前の要求が完了した場合は、コネクション速度が劣化する可能性がある、すなわち、基礎になるＴＣＰセッションが休止状態になる可能性があるか又はＴＣＰｃｗｎｄ変数が実質的に減らされ、それによってそのコネクション上で出された新しい要求の最初のダウンロード速度を実質的に低下させる可能性があるためである。追加の要求を出す前に完了間近まで待つ１つの理由は、以前の要求が完了するはるか前に新しい要求が出された場合は、その新しい要求はある程度の実質的な期間の間は開始することさえできず、新しい出された要求が開始する前のこの期間中に、例えば表現切り換え決定に起因して、新しい要求を行う決定がもはや有効でないことになる可能性があるためである。このように、この技法を実装するクライアントの実施形態は、コネクションのダウンロード能力を低減させずに可能な限り遅くコネクション上で新しい要求を出す。

【0371】

該方法は、コネクション上で出された最後の要求に応答してこのコネクション上で受信されたバイト数をモニタリングすることと、この数に対して試験を行うことと、を備える。これは、受信機（又は、該当する場合は送信機）がモニタリング及び試験を行うように構成することによって実施することができる。

【0372】

試験に合格した場合は、コネクション上でさらなる要求を出すことができる。適切な試験の一例は、受信されたバイトの数が要求されたデータのサイズの固定された部分よりも大きいかどうかである。例えば、この部分は８０％であることができる。適切な試験の他の例は、図１７において例示されるように、次の計算に基づく。計算においては、コネクションのデータレートの推定値をＲとし、ラウンドトリップ時間（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）（“ＲＴＴ”）の推定値をＴとし、例えば、０．５乃至２の間の値に設定された定数であることができる数値係数をＸとし、ここで、Ｒ及びＴの推定値は、定期的に更新される（ステップ１４１０において更新される）。最後の要求で要求されるデータのサイズをＳとし、受信された要求されたデータのバイト数（ステップ１４２０において計算）をＢとする。

【0373】

１つの適切な試験は、不等式（Ｓ−Ｂ）＜Ｘ・Ｒ・Ｔを評価するためのルーチンを受信機（又は、該当する場合は送信機）に実行させ（ステップ１４３０において試験）、“はい”である場合は、行動を起こさせることである。例えば、コネクション上において出される準備が整っている他の要求が存在するかどうかを確認するために試験を行うことができ（ステップ１４４０）、“はい”である場合は、コネクションにその要求を出し（ステップ１４５０）、“いいえ”である場合は、プロセスは、ステップ１４１０に戻って更新及び試験を継続する。ステップ１４３０における試験の結果が“いいえ”である場合は、プロセスは、ステップ１４１０に戻って更新及び試験を継続する。

【0374】

（例えば、適宜プログラミングされた要素によって実施された）ステップ１４３０での不等式試験は、受信されるべき残りのデータの量が１つのＲＴＴ内の現在の推定された受信レートで受信することができるデータの量のＸ倍に等しいときに各々の後続する要求を出させる。ステップ１４１０においてデータレートＲを推定するための幾つかの方法が当業において知られている。例えば、データレートは、Ｄｔ／ｔとして推定することができ、ここで、Ｄｔは、先行するｔ秒において受信されたビットの数であり、ここで、ｔは、例えば、１秒又は０．５秒又は何らかのその他の間隔であることができる。他の方法は、着信したデータレートの指数加重平均、又は一次有限インパルス応答（ＩＩＲ）フィルタである。ステップ１４１０においてＲＴＴ、Ｔを推定するための幾つかの方法が当業において知られている。

【0375】

ステップ１４３０における試験は、以下においてさらに詳細に説明されるように、インタフェース上のすべてのアクティブなコネクションの集合に対して適用することができる。

【0376】

その方法は、要求を行うことができる先である適切なサーバの組と各々の候補要求を関連付ける候補要求リストを構築することと、候補要求リストの順序を優先度順に設定することと、をさらに備える。候補要求リスト上の幾つかのエントリは、同じ優先度を有することができる。各々の候補要求と関連付けられた適切なサーバのリスト上のサーバは、ホスト名によって識別される。各ホスト名は、よく知られるようにドメイン名システムから入手することができるインターネットプロトコルアドレスの組に対応する。従って、候補要求リスト上の各々の可能な要求は、インターネットプロトコルアドレスの組、具体的には、候補要求と関連付けられたサーバと関連付けられたホスト名と関連付けられたインターネットプロトコルアドレスの組の和集合と関連付けられる。ステップ１４３０において説明される試験がコネクションに関して合格であり、そのコネクション上で新しい要求がまだ出されていないときは必ず、コネクションの行先のインターネットプロトコルアドレスが関連付けられている候補要求のリスト上の最高の優先度の要求が選択され、この要求がコネクション上で出される。要求は、候補要求リストから削除もされる。

【0377】

候補要求は、候補要求リストから削除する（取り消す）ことができ、新しい要求は、候補リスト上の既存の要求よりも高い優先度を持って候補リストに追加することができ、候補リスト上の既存の要求は、それらの優先度を変更することができる。要求が候補要求リスト上にあることの動的性質、及び、候補リスト上でのそれらの優先度の動的性質は、ステップ１４３０において説明されるタイプの試験に合格したときに依存していずれの要求を次に出すことができるかを変更することができる。

【0378】

例えば、ステップ１４３０において説明される試験に対する答えがある時間ｔにおいて “はい”である場合は、出される次の要求は、要求Ａになり、他方、ステップ１４３０において説明される試験に対する答えがある時間ｔ’＞ｔまで“はい”でない場合は、要求Ａが時間ｔとｔ’の間に候補要求リストから削除されることに起因して、又は、要求Ｂが時間ｔとｔ’の間に要求Ａよりも高い優先度を持って候補要求リストに追加されることに起因して、又は、要求Ｂが時間ｔにおいて候補リスト上に存在しているが要求Ａよりも低い優先度を有し、時間ｔと時間ｔ’の間に要求Ｂの優先度が要求Ａのそれよりも高くされたことに起因して出される次の要求が代わりに要求Ｂになる。

【0379】

図１８は、候補要求リスト上の要求のリストの例を示す。この例では、３つのコネクションが存在し、候補リスト上にはＡ、Ｂ、Ｃ、Ｄ、Ｅ及びＦのラベルが付された６つの要求が存在する。候補リスト上の要求の各々は、指示に従ってコネクションの部分組において出すことができ、例えば、要求Ａはコネクション１において出すことができ、他方、要求Ｆはコネクション２又はコネクション３において出すことができる。各要求の優先度は、図１８においてもラベルが付され、より低い優先度値は、要求がより高い優先度であることを示す。このように、優先度０を有する要求Ａ及びＢは、最高の優先度の要求であり、他方、３の優先度値を有する要求Ｆは、候補リスト上の要求の中で最低の優先度である。

【0380】

この時点ｔにおいて、コネクション１がステップ１４３０において説明される試験に合格した場合は、要求Ａ又は要求Ｂのいずれかがコネクション1において出される。代わりにコネクション３がこの時間ｔにおいてステップ１４３０で説明される試験に合格した場合は、要求Ｄはコネクション３において出すことができる最高の優先度を有する要求であるため、要求Ｄがコネクション３において出される。

【0381】

すべてのコネクションに関して、時間ｔからあるその後の時間ｔ’までのステップ１４３０において説明される試験の答えが“いいえ”であり、時間ｔとｔ’との間に要求Ａがそれの優先度を０から５に変更し、要求Ｂが候補リストから削除され、優先度０を有する新要求Ｇが候補リストに追加されると仮定する。これで、時間ｔ’においては、新候補リストは図１９に示されるようになる。

【0382】

時間ｔ’において、コネクション１がステップ１４３０において説明される試験に合格した場合は、優先度４を有する要求Ｃがこの時点でコネクション１において出すことができる候補リスト上の最高の優先度の要求であるため、それがコネクション１において出される。

【0383】

この同じ状況において、代わりに要求Ａが時間ｔにおいてコネクション１で出されていることになる（図１８に示されるように時間ｔにおけるコネクション１のための２つの最高優先度の選択肢のうちの１つであった）と仮定する。時間ｔからあるその後の時間ｔ’までのステップ１４３０において説明される試験の答えはすべてのコネクションに関して “いいえ”であるため、コネクション１は、時間ｔよりも前に出された要求のために依然として少なくとも時間ｔ’までデータを配信中であり、従って、要求Ａは少なくとも時間ｔ’までは開始していなかったことになる。要求Ｃは、ｔ’後の要求Ａが開始していたことになるのと同じ時間に開始するため、及び、その時間までに要求Ｃは要求Ａよりも高い優先度であるため、時間ｔ’において要求Ｃを出すことは、時間ｔにおいて要求Ａを出していた場合よりも優れた決定である。

【0384】

他の代替として、ステップ１４３０において説明されるタイプの試験がアクティブなコネクションの集合に対して適用された場合は、インターネットプロトコルアドレスが候補要求リスト上の最初の要求又は該第１の要求と同じ優先度を有する他の要求と関連付けられている行先を有するコネクションを選択することができる。

【0385】

候補要求リストの構築のために幾つかの方法が可能である。例えば、候補リストは、時系列順にプレゼンテーションの現在の表現のデータの次のｎの部分の要求を表すｎの要求を含むことができ、最も早期の部分のデータの要求が最高の優先度を有し、最後の部分のデータの要求が最低の優先度を有する。幾つかの場合は、ｎは１であることができる。ｎの値は、バッファサイズＢ_{ｃｕｒｒｅｎｔ}、又はＳｔａｔｅ変数又はクライアントバッファ占有状態という他の尺度に依存することができる。例えば、幾つかのスレショルド値をＢ_{ｃｕｒｒｅｎｔ}に関して設定することができ、及び、各スレショルドと関連付けられた値、従ってｎの値、がＢ_{ｃｕｒｒｅｎｔ}よりも小さい最高のスレショルドと関連付けられた値として採用される。

【0386】

上述される実施形態は、コネクションへの柔軟な要求の割り当てを保証し、（そのコネクションの行先ＩＰアドレスは要求と関連付けられたホスト名のうちのいずれかに割り当てられるそれでないことに起因して）最高の優先度の要求が既存のコネクションにとって適切でない場合でもそのコネクションを再使用することに優先権が与えられることを保証する。Ｂ_{ｃｕｒｒｅｎｔ}又はＳｔａｔｅ又はクライアントバッファ占有というその他の尺度への依存は、クライアントが時系列においてプレイアウトされるべき次の部分のデータと関連付けられた要求の発行及び完了を緊急に必要としているときに該“優先順位外”の要求が出されないように保証する。

【0387】

これらの方法は、協力的ＨＴＴＰ及びＦＥＣと有利に組み合わせることができる。

【0388】

一貫したサーバ選択
よく知られるように、ファイルダウンロードプロトコルを用いてダウンロードされるファイルは、ホスト名とファイル名とを備える識別子によって共通して識別される。例えば、これは、ＨＴＴＰプロトコルに関する事例であり、その事例では、識別子は、ユニフォームリソース識別子（ＵＲＩ）である。ホスト名は、インターネットプロトコルアドレスによって識別された、複数のホストに対応することができる。例えば、これは、複数のクライアントからの要求の負荷を複数の物理的機械にわたって分散させる共通の方法である。特に、この手法は、コンテンツデリバリネットワーク（Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）（ＣＤＮ）によって共通して採用される。この場合は、物理的ホストのうちのいずれかへのコネクションにおいて出された要求は、成功することが予想される。クライアントがホスト名と関連付けられたインターネットプロトコルアドレスの中から選択することができるようにする幾つかの方法が知られている。例えば、これらのアドレスは、ドメイン名システムを介してクライアントに典型的に提供され及び優先順位に従って提供される。クライアントは、最高の優先度の（第１の）インターネットプロトコルアドレスを選択することができる。しかしながら、概して、この選択が行われる方法に関してはクライアント間での調整は行われず、その結果、異なるクライアントが異なるサーバに同じファイルを要求することができる。この結果、同じファイルが付近の複数のサーバのキャッシュに格納されることがあり、それは、キャッシュインフラストラクチャの効率を低下させる。

【0389】

これは、同じブロックを要求する２つのクライアントが同じサーバにこのブロックを要求する確率を有利に上昇させるシステムによって処理することができる。ここにおいて説明される新規の方法は、要求されるべきファイルの識別子によって決定された方法で及びインターネットプロトコルアドレス及びファイル識別子の同じ又は類似の選択が提示された異なるクライアントが同じ選択を行うような形で入手可能なインターネットプロトコルアドレスの中から選択することを備える。

【0390】

その方法の第１の実施形態が図２０を参照して説明される。クライアントは、ステップ１７１０において示されるように、インターネットプロトコルアドレスＩＰ_１、ＩＰ_２、．．．、ＩＰ_ｎの組を最初に入手する。ステップ１７２０における決定により、要求が出される対象となるファイルが存在する場合は、クライアントは、ステップ１７３０乃至１７７０における決定により、そのファイルの要求を出すためのインターネットプロトコルアドレスを決定する。インターネットプロトコルアドレスの組及び要求されるファイルに関する識別子を考慮し、方法は、ファイル識別子によって決定された方法でインターネットプロトコルアドレスの順序を設定することを備える。例えば、ステップ１７３０において示されるように、各インターネットプロトコルアドレスに関して、インターネットプロトコルアドレス及びファイル識別子の連結を備えるバイトストリングが構築される。ステップ１７４０において示されるように、ハッシュ関数がこのバイトストリングに適用され、その結果得られたハッシュ値が、ステップ１７５０において示されるように、インターネットプロトコルアドレスの順序設定を含む固定された順序設定により、例えば数字の昇順で、配置される。同じハッシュ関数を全クライアントによって用いることができ、それにより全クライアントによって所定の入力に関してハッシュ関数によって同じ結果が生成されることを保証する。ハッシュ関数は、クライアントの組内の全クライアント内に静的に設定することができ、又は、クライアントの組内の全クライアントは、それらのクライアントがインターネットプロトコルアドレスのリストを入手するときにハッシュ関数の部分的な又は完全な記述を入手することができ、又は、クライアントの組内の全クライアントは、それらのクライアントがファイル識別子を入手するときにハッシュ関数の部分的な又は完全な記述を入手することができ、又は、ハッシュ関数はその他の手段によって決定することができる。ステップ１７６０及び１７７０において示されるように、この順序設定において最初であるインターネットプロトコルアドレスが選択され、このアドレスは、コネクションを確立するため及びファイルの全部又は一部の要求を出すために用いられる。

【0391】

上記の方法は、ファイルを要求するために新しいコネクションが確立されるときに適用することができる。それは、幾つかの確立されたコネクションが利用可能であり及びそれらのうちの１つが新しい要求を出すために選択することができるときに適用することもできる。

【0392】

さらに、確立されたコネクションが利用可能であり及び等しい優先度を有する候補要求の組の中から要求を選択することができるときに、例えば、上述される同じハッシュ値法によって候補要求に関する順序設定が導き出され、この順序設定において最初に現れる候補要求が選択される。それらの方法は、再度コネクションと要求の各々の組み合わせに関するハッシュを計算し、固定された順序設定によりこれらのハッシュ値の順序を設定し及び要求とコネクションの組み合わせの組に関して誘導された順序設定において最初に生じる組み合わせを選択することによって、コネクション及び等しい優先度の要求の組の中からコネクション及び候補要求の両方を選択するために結合することができる。

【0393】

この方法は、次の理由で利点を有する。すなわち、ブロックサービングインフラストラクチャによって採用される典型的な手法、例えば図１（ＢＳ１０１）又は図２（ＢＳ１ｓ１０１）において示されるそれ、そして特に、ＣＤＮによって共通して採用される手法は、クライアント要求を受信する複数のキャッシングプロキシサーバを提供することである。キャッシングプロキシサーバは、所定の要求において要求されるファイルを提供することができず、この場合は、該サーバは、典型的に他のサーバに要求を転送し、典型的には要求されたファイルを含む応答をそのサーバから受信し、クライアントに応答を転送する。キャッシングプロキシサーバは、それが要求されたファイルに対する後続する要求に即座に応答できるようにそのファイルを格納（キャッシング）することもできる。上述される共通の手法は、所定のキャッシングプロキシサーバに格納されたファイルの組はキャッシングプロキシサーバが受信している要求の組によって大部分が決定されるという特性を有する。

【0394】

上述される方法は、次の利点を有する。クライアントの組内の全クライアントにインターネットプロトコルアドレスの同じリストが提供される場合は、これらのクライアントは、同じファイルを対象にして出された全要求に関して同じインターネットプロトコルアドレスを使用する。インターネットプロトコルアドレスの２つの異なるリストが存在し、各クライアントにこれらの２つのリストのうちの１つが提供される場合は、クライアントは、同じファイルを対象にして出された全要求に関して多くとも２つの異なるインターネットプロトコルアドレスを用いる。概して、クライアントに提供されるインターネットプロトコルアドレスのリストが類似する場合は、クライアントは、同じファイルを対象にして出された全要求に関して提供されたインターネットプロトコルアドレスの小さい組を用いる。近接するクライアントはインターネットプロトコルアドレスの類似のリストが提供される傾向があるため、近接するクライアントはそれらのクライアントが利用可能なキャッシングプロキシサーバのほんの小さい部分にファイル要求を出す可能性がある。従って、ファイルをキャッシングするキャッシングプロキシサーバのほんの小さい部分のみが存在することになり、それは、ファイルをキャッシングするために用いられるキャッシングリソースの量を有利に最少にする。

【0395】

好ましくは、インターネットプロトコルアドレスの所定の組に関して、インターネットプロトコルアドレスのうちの所定の１つがステップ１７５０によって生成されたソーティングされたリスト内の最初であるファイルの比率がリスト内の全インターネットプロトコルアドレスに関してほぼ同じであるようにするために、ハッシュ関数は、異なる入力の非常に小さい部分が同じ出力にマッピングされ、及び、異なる入力は基本的にランダムな出力にマッピングされるという特性を有する。他方、所定の入力に関しては、ハッシュ関数の出力は全クライアントに関して同じであるという意味で、ハッシュ関数は決定方式であることが重要である。

【0396】

上述される方法の他の利点は次の通りである。クライアントの組内の全クライアントにインターネットプロトコルアドレスの同じリストが提供されると仮定する。説明されたばかりのハッシュ関数の特性に起因して、これらのクライアントからの異なるファイルの要求は、インターネットプロトコルアドレスの組にわたって均等に分散され、それは、それらの要求がキャッシングプロキシサーバ全体にわたって均等に分散されることを意味する。従って、これらのファイルを格納するために用いられるキャッシングリソースは、キャッシングプロキシサーバ全体にわたって均等に分散され、ファイル要求は、キャッシングプロキシサーバ全体にわたって均等に分散される。従って、方法は、キャッシングインフラストラクチャ全体にわたって格納の均衡化及び負荷の均衡化の両方を提供する。

【0397】

上述される手法の幾つかの変形が当業者に知られており、多くの場合においては、これらの変形は、所定のプロキシに格納されたファイルの組はキャッシングプロキシサーバが受信している要求の組によって少なくとも部分的に決定されるという特性を保持する。所定のホスト名が複数の物理的キャッシングプロキシサーバに対して解決する（ｒｅｓｏｌｖｅ）共通の事例においては、すべてのこれらのサーバが頻繁に要求される所定のファイルのコピーを最終的に格納することが共通となる。キャッシングプロキシサーバ上の格納リソースは限られており、そしてその結果、ファイルはキャッシュから時折削除される（パージされる）ことがあるため、該複製は望ましくないことがある。ここで説明される新規の方法は、この複製が低減される形で所定のファイルの要求がキャッシングプロキシサーバに向けられ、それによってキャッシュからファイルを削除する必要性が低減され及びそれによって所定のファイルがプロキシキャッシュ内に存在する（すなわち、プロキシキャッシュからパージされていない）尤度を上昇させることを保証する。
プロキシキャッシュ内にファイルが存在するときには、クライアントに送信される応答はより高速であり、それは、要求されたファイルが遅れて到着してその結果メディアのプレイアウトの休止、従って不良なユーザ経験、を生じさせる確率を低下させる利点を有する。さらに、プロキシキャッシュ内にファイルが存在しないときは、要求は他のサーバに送信され、サービングインフラストラクチャ及びサーバ間でのネットワークコネクションの両方に対して追加の負荷をかけることがある。多くの場合においては、要求が送信される先であるサーバは遠い場所に所在することがあり、このサーバからキャッシングプロキシサーバへのファイルの返信は、送信コストを生じさせることがある。従って、ここで説明される新規の方法は、結果的にこれらの送信コストを低減させる。

【0398】

確率的ファイル全体の要求
ＨＴＴＰプロトコルが範囲要求とともに用いられる事例における１つの特定の懸念は、サービングインフラストラクチャにおいてスケーラビリティを提供するために共通して用いられるキャッシュサーバの動作である。ＨＴＴＰキャッシュサーバがＨＴＴＰ範囲ヘッダをサポートするのが共通である一方で、異なるＨＴＴＰキャッシュサーバの正確な動作は実装によって変動する。ほとんどのキャッシュサーバ実装は、ファイルがキャッシュ内で入手可能である場合にキャッシュからの範囲要求に対処する。ＨＴＴＰキャッシュサーバの共通の実装は、キャッシュサーバがファイルのコピーを有さない限り範囲ヘッダを含む下流のＨＴＴＰ要求を上流ノードに常に転送する（キャッシュサーバ又はオリジンサーバ）。幾つかの実装においては、範囲要求に対する上流の応答はファイル全体であり、このファイル全体がキャッシングされ、下流の範囲要求に対する応答がこのファイルから抽出されて送信される。しかしながら、少なくとも１つの実装においては、範囲要求に対する上流の応答は、まさに範囲要求自体内のデータバイトであり、これらのデータバイトはキャッシングされず、その代わりに、下流の範囲要求に対する応答として送信されるだけである。その結果、クライアントによる範囲ヘッダの使用は、ファイル自体は絶対にキャッシュ内に持ち込まれずネットワークの望ましいスケーラビリティの特性が失われるという結果を有することがある。

【0399】

上記においては、キャッシングプロキシサーバの動作が説明され、及び、複数のブロックの集合であるファイルからのブロックを要求する方法も説明された。例えば、これは、ＨＴＴＰ範囲要求ヘッダの使用によって達成させることができる。該要求は、以下では“部分的要求”と呼ばれる。ブロックサービングインフラストラクチャ１０１がＨＴＴＰ範囲ヘッダのための完全なサポートを提供しない事例において利点を有するさらなる実施形態が今度は説明される。共通して、ブロックサービングインフラストラクチャ、例えばコンテンツデリバリネットワーク、内のサーバは、部分的要求をサポートするが、部分的要求に対する応答をローカルストレージ（キャッシュ）に格納することができない。該サーバは、ファイル全体がローカルストレージ内に格納されない限り、他のサーバに要求を転送することによって部分的要求を履行することができ、その場合は、応答は、他のサーバに要求を転送することなしに送信することができる。

【0400】

部分的要求である全要求が他のサーバに転送され、いずれの要求もキャッシングプロキシサーバによって対処されず、そもそもキャッシングプロキシサーバを提供するという目的を挫折させることになるため、上述されるブロック集合体の新規の拡張を利用するブロック−要求ストリーミングシステムは、ブロックサービングインフラストラクチャがこの動作を呈する場合は不良になることがある。上述されるようにブロック−要求ストリーミングプロセス中には、クライアントは、ファイルの始めに存在するブロックをある時点で要求することができる。

【0401】

ここで説明される新規の方法により、一定の条件が満たされるごとに、該要求は、ファイル内の第１のブロックの要求からファイル全体の要求に変換することができる。ファイル全体の要求がキャッシングプロキシサーバによって受信されたときに、プロキシサーバは典型的には応答を格納する。従って、これらの要求の使用は、後続する要求が、全ファイルであるか部分的要求であるかにかかわらず、キャッシングプロキシサーバによって直接対処することができるようにローカルキャッシングプロキシサーバのキャッシュ内にファイルを入れさせる。条件は、所定のファイルと関連付けられた要求の組、例えば、対象となるコンテンツ項目を視聴中のクライアントの組によって生成された要求の組、の中で、これらの要求の少なくとも提供された一部分に関して条件が満たされることであることができる。

【0402】

適切な条件の一例は、ランダムに選択された数字が提供されたスレショルドを上回ることである。このスレショルドは、単一のブロック要求のファイル全体の要求への変換がそれらの要求の提供された一部分に関して平均して生じるように設定することができ、例えば、１０回に１回である（その場合は、乱数は間隔［０，１］から選択することができ、スレショルドは０．９であることができる）。適切な条件の他の例は、ブロックと関連付けられた何らかの情報およびクライアントと関連付けられた何らかの情報に関して計算されたハッシュ関数が提供された値の組の中の１つをとることである。この方法は、頻繁に要求されるファイルに関して、ファイルはローカルプロキシサーバのキャッシュ内に入れられるがブロック−要求ストリーミングシステムの動作は各要求が単一のブロックを対象とする標準動作から有意には変更されないという利点を有する。単一のブロックの要求からファイル全体の要求への要求の変換が生じる多くの事例においては、クライアント手順が進行してファイル内のその他のブロックを要求する。これが当てはまる場合は、ファイル全体の要求の結果いずれの場合も対象となるブロックが受信されるため、該要求は抑制することができる。

【0403】

ＵＲＬ構築及びセグメントリストの生成及びシーク
セグメントリスト生成は、オンデマンド事例のためのメディアプレゼンテーションの開始に関するか又は実際の経過時間で表される何らかの開始時間ｓｔａｒｔｔｉｍｅにおいて開始する特定の表現のために特定のクライアントのローカル時間ＮＯＷにおいてＭＰＤからセグメントリストをクライアントがどのように生成することができるかという課題を取り扱う。セグメントリストは、ロケ−タ、例えば任意選択の最初の表現メタデータのＵＲＬ、及びメディアセグメントのリストを備えることができる。各メディアセグメントには、開始時間、継続時間及びロケータを割り当てておくことができる。開始時間は、典型的には、セグメント内の含まれているメディアのメディア時間の概算値を表し、しかしながら、サンプルの正確な時間は必ずしも表さない。開始時間は、該当する時間にダウンロード要求を出すためにＨＴＴＰストリーミングクライアントによって用いられる。各々の開始時間を含むセグメントリストの生成は、異なる方法で行うことができる。ＵＲＬは、プレイリストとして提供することができ又はセグメントリストのコンパクトな表現のためにＵＲＬ構築規則を有利に用いることができる。

【0404】

ＵＲＬ構築に基づくセグメントリストは、例えば、ＭＰＤが特定の属性又は要素、例えばＦｉｌｅＤｙｎａｍｉｃＩｎｆｏ又は同等の信号によってそれをシグナリングする場合に実行することができる。ＵＲＬ構築からセグメントリストを生成する一般的方法は、以下の“ＵＲＬ構築概要”の節において提供される。プレイリストに基づく構築は、例えば、異なる信号によってシグナリングすることができる。セグメントリスト内でシークして正確なメディア時間に到達することもこの関係において有利に実装される。

【0405】

ＵＲＬ構築器概要
前述されるように、本発明の一実施形態においては、クライアントデバイスがプレゼンテーションのブロックに関するファイル識別子を構築することを可能にするＵＲＬ構築規則を含むメタデータファイルを提供することができる。今度は、ＵＲＬ構築規則の変更と、利用可能な符号化の数の変更と、利用可能な符号化と関連付けられたメタデータ、例えばビットレート、アスペクト比、解像度、音声又は映像コーデック又はコーデックパラメータ又はその他のパラメータの変更と、を含むメタデータファイル内の変更を提供するブロック要求ストリーミングシステムのさらなる新規の拡張について説明する。

【0406】

この新規の拡張においては、全体的プレゼンテーション内の時間間隔を示すメタデータファイルの各要素と関連付けられた追加データを提供することができる。この時間間隔内では、要素は有効であるとみなすことができ、時間間隔外では要素は無視することができる。さらに、メタデータの構文は、１回だけ又は多くとも１回現れることが以前に許容された要素が複数回現れることができるように拡張することができる。この場合は、該要素に関しては指定された時間間隔は互いに離れていなければならないことを規定する追加の制約を適用することができる。いずれの所定の瞬間においても、時間間隔が所定の瞬間を含む要素のみを考慮することは、その結果として、原メタデータ構文と一致するメタデータファイルが得られる。該時間間隔は、有効間隔と呼ぶ。従って、この方法は、上述される種類の変更を単一のメタデータファイル内でシグナリングすることを提供する。有利なことに、該方法は、メディアプレゼンテーション内の指定されたポイントでの説明される種類の変更をサポートするメディアプレゼンテーションを提供するために用いることができる。

【0407】

ＵＲＬ構築器
ここにおいて説明されるように、ブロック−要求ストリーミングシステムの１つの共通の特徴は、利用可能なメディア符号化を識別し及びそれらの符号化からブロックを要求するためにクライアントによって必要とされる情報を提供する“メタデータ”をクライアントに提供する必要性である。例えば、ＨＴＴＰの場合は、この情報は、メディアブロックを含むファイルに関するＵＲＬを備えることができる。所定の符号化のためのブロックに関するＵＲＬを記載するプレイリストファイルを提供することができる。複数のプレイリストファイルが、各符号化のために１つずつ、異なる符号化に対応するプレイリストを記載するプレイリストのマスタープレイリストとともに提供される。このシステムの１つの欠点は、メタデータがきわめて大きくなる可能性があり、従ってクライアントがストリームを開始したときに要求するのにある程度の時間がかかることである。このシステムのさらなる欠点は、メディアデータブロックに対応するファイルがリアルタイム（ライブ）でキャプチャされているメディアストリーム、例えば、ライブのスポーツイベント又はニュース番組、から“オンザフライ（ｏｎ−ｔｈｅ−ｆｌｙ）で”生成されるライブのコンテンツの事例において顕著である。この事例においては、プレイリストファイルは、新しいブロックが（例えば、数秒ごとに）入手可能になるのに応じて更新することができる。クライアントデバイスは、新しいブロックを入手可能であるかどうかを決定してそれらのＵＲＬを入手するためにプレイリストファイルを繰り返しフェッチすることができる。これは、サービングインフラストラクチャに対して有意な負荷を課すことがあり、特に、数秒のオーダーが一般的であるブロックサイズに等しい更新間隔よりも長い時間メタデータファイルをキャッシングできないことを意味する。

【0408】

ブロック−要求ストリーミングシステムの１つの重要な態様は、ブロックを要求するために、ファイルダウンロードプロトコルとともに用いるべきファイル識別子、例えばＵＲＬ、をクライアントに知らせるために用いられる方法である。例えば、プレゼンテーションの各表現に関してメディアデータのブロックを含むファイルのＵＲＬを記載するプレイリストが提供される方法。この方法の１つの欠点は、プレイアウトが開始することができる前にプレイリストファイル自体の少なくとも一部をダウンロードする必要があり、チャネルザッピング時間を増大させ従って不良なユーザ経験を生じさせることである。幾つかの又は数多くの表現を有する長いメディアプレゼンテーションに関しては、ファイルＵＲＬのリストは大きくなることがあり、従ってプレイリストファイルが大きくなってチャネルザッピング時間をさらに増大させることがある。

【0409】

この方法の他の欠点は、ライブコンテンツの事例において生じる。この事例では、ＵＲＬの完全なリストを事前に入手可能にすることができず、更新されたバージョンを受信するために、プレイリストファイルは、新しいブロックが入手可能になりクライアントがプレイリストファイルを定期的に要求するのに応じて定期的に更新される。このファイルは頻繁に更新されることに起因して、それは、キャッシングプロキシサーバ内に長期間格納することができない。これは、このファイルの要求のうちの非常に多くがその他のサーバにそして最終的にはそのファイルを生成するサーバに転送されることを意味する。人気のあるメディアプレゼンテーションの場合は、この結果、このサーバ及びネットワークに対して高い負荷をかけることになり、それは、遅い応答時間そして従って長いチャネルザッピング時間及び不良なユーザ経験が結果的に生じることがある。最悪の場合は、サーバが過負荷状態になり、この結果、幾つかのユーザがプレゼンテーションを視聴できないことになる。

【0410】

ブロック−要求ストリーミングシステムの設計では、使用することができるファイル識別子の形式に対して制約を課すことを回避するのが望ましい。この理由は、幾つかの考慮事項が特定の形式の識別子の使用を動機付けるためである。例えば、ブロックサービングインフラストラクチャがコンテンツデリバリネットワークである場合は、格納又はサービス提供負荷をネットワーク全体に分散させることを希望することに関連するファイル命名又は格納上の規約又はシステム設計時に予測することができないファイル識別子の特定の形式に至るその他の要求事項が存在することがある。

【0411】

該当するファイル識別規約を選択する柔軟性を維持しながら上記の欠点を軽減するさらなる実施形態が今度は説明される。この方法では、ファイル識別子構築規則を備えるメディアプレゼンテーションの各表現のためにメタデータを提供することができる。ファイル識別子構築規則は、例えば、テキストストリングを備えることができる。プレゼンテーションの所定のブロックに関するファイル識別子を決定するために、ファイル識別子構築規則の解釈方法を提供することができ、この方法は、入力パラメータの決定と、ファイル識別構築規則を入力パラメータとともに評価することとを備える。入力パラメータは、例えば、識別すべきファイルのインデックスを含むことができ、ここで、第１のファイルはインデックス０を有し、第２はインデックス１を有し、第３はインデックス２を有し、以下同様である。例えば、すべてのファイルが同じ継続時間（又はほぼ同じ継続時間）にまたがる場合は、プレゼンテーション内のいずれかの所定の時間と関連付けられたファイルのインデックスは、簡単に決定することができる。代替として、各ファイルがまたがるプレゼンテーション内の時間は、プレゼンテーション又はバージョンメタデータ内で提供することができる。

【0412】

一実施形態においては、ファイル識別子構築規則は、入力パラメータに対応する一定の特別の識別子を含むことができるテキストストリングを備えることができる。ファイル識別子構築規則の評価方法は、テキストストリング内での特別な識別子の位置を決定することと、各々の該特別な識別子を対応する入力パラメータの値のストリング表現と取り替えることと、を備える。

【0413】

他の実施形態においては、ファイル識別子構築規則は、式言語に準拠したテキストストリングを備えることができる。式言語は、言語内の式が準拠することができる構文の定義と、その構文に準拠してストリングを評価するための規則の組と、を備える。

【0414】

今度は、図２１を参照して１つの具体例が説明され、以下を参照すること。拡張バッカス・ナウア記法（Ａｕｇｍｅｎｔｅｄ Ｂａｃｋｕｓ−Ｎａｕｒ Ｆｏｒｍ）において定義された、適切な式言語に関する構文定義の一例は、図２１に示されるとおりである。図２１の＜ｅｘｐｒｅｓｓｉｏｎ＞（＜式＞）プロダクション（ｐｒｏｄｕｃｔｉｏｎ）に準拠したストリングを評価するための規則の一例は、次のように＜ｅｘｐｒｅｓｓｉｏｎ＞プロダクション（＜ｅｘｐｒｅｓｓｉｏｎ＞）に準拠したストリングを，＜ｌｉｔｅｒａｌ＞（＜リテラル＞）プロダクションに準拠したストリングに反復的に変換することを備える。

【0415】

＜ｌｉｔｅｒａｌ＞プロダクションに準拠した＜ｅｘｐｒｅｓｓｉｏｎ＞は、不変である。

【0416】

＜ｖａｒｉａｂｌｅ＞（＜変数＞）プロダクションに準拠した＜ｅｘｐｒｅｓｓｉｏｎ＞は、＜ｖａｒｉａｂｌｅ＞生成の＜ｔｏｋｅｎ＞（＜トークン＞）ストリングによって識別される変数の値と取り替えられる。
＜ｆｕｎｃｔｉｏｎ＞（＜関数＞）プロダクションに準拠した＜ｅｘｐｒｅｓｓｉｏｎ＞は、以下において説明されるように、これらの規則によりそれの引数の各々を評価し及び＜ｆｕｎｃｔｉｏｎ＞プロダクションの＜ｔｏｋｅｎ＞要素に依存してこれらの引数に変換を適用することによって評価される。

【0417】

＜ｅｘｐｒｅｓｓｉｏｎ＞プロダクションの最後の代替に準拠した＜ｅｘｐｒｅｓｓｉｏｎ＞は、以下において説明されるように、２つの＜ｅｘｐｒｅｓｓｉｏｎ＞要素を評価し及び＜ｅｘｐｒｅｓｓｉｏｎ＞プロダクションの最後の代替の＜ｏｐｅｒａｔｏｒ＞（＜演算子＞）要素に依存してこれらの引数に演算を適用することによって評価される。
上述される方法では、評価は、複数の変数を定義することができる関係において行われると仮定される。変数は、（名前、値）の対であり、ここで、“名前”は、＜ｔｏｋｅｎ＞プロダクションに準拠したストリングであり、“値”は、＜ｌｉｔｅｒａｌ＞プロダクションに準拠したストリングである。幾つかの変数は、評価が開始する前に評価プロセス外で定義することができる。その他の変数は、評価プロセス自体内で定義することができる。１つの変数のみが各々の可能な“名前”を持って存在するという意味で全変数が“グローバル”である。

【0418】

関数の一例は、“ｐｒｉｎｔｆ”関数である。この関数は、１つ以上の引数を受け入れる。第１の引数は、＜ｓｔｒｉｎｇ＞（＜ストリング＞）プロダクション（以後“ストリング”）に準拠することができる。ｐｒｉｎｔｆ関数は、それの第１の引数の変換されたバージョンまで評価する。適用される変換は、Ｃの標準ライブラリの“ｐｒｉｎｔｆ”関数と同じであり、Ｃの標準ライブラリｐｒｉｎｔｆ関数によって予想される追加の引数を供給する追加の引数が＜ｆｕｎｃｔｉｏｎ＞プロダクションに含まれる。

【0419】

関数の他の例は、“ハッシュ”関数である。この関数は、２つの引数を受け入れ、そのうちの第１はストリングであることができ、そのうちの第２は＜ｎｕｍｂｅｒ）プロダクション（以後“数”）に準拠することができる。“ハッシュ”関数は、第１の引数にハッシュアルゴリズムを適用し、第２の引数よりも小さい負でない整数である結果を戻す。適切なハッシュ関数の一例が図２２に示されるＣ関数で与えられ、それらの引数は、入力ストリング（囲んでいる引用符を除く）及び数字の入力値である。ハッシュ関数のその他の例は、当業者によく知られている。

【0420】

関数の他の例は、１つ、２つ又は３つのストリング引数をとる“Ｓｕｂｓｔ”関数である。１つの引数が供給される場合は、“Ｓｕｂｓｔ”関数の結果は第１の引数である。２つの引数が供給される場合は、“Ｓｕｂｓｔ”関数の結果は、第１の引数内での第２の引数の存在（囲んでいる引用符を除く）を削除し、そのようにして変更された第１の引数を戻すことによって計算される。３つの引数が供給される場合は、“Ｓｕｂｓｔ”関数の結果は、第１の引数内での第２の引数の存在（囲んでいる引用符を除く）を第３の引数（囲んでいる引用符を除く）に置き換え、そのようにして変更された第１の引数を戻すことによって計算される。

【0421】

演算子の幾つかの例は、加算、減算、除算、乗算及び剰余の各演算子であり、＜ｏｐｅｒａｔｏｒ＞（＜演算子＞）プロダクション、‘＋’、‘−’、‘／’、‘^＊’、‘％’によってそれぞれ識別される。これらの演算子は、＜演算子＞プロダクションのいずれかの側の＜式＞プロダクションを数字まで評価することを要求する。演算子の評価は、該当する算術演算（それぞれ加算、減算、除算、乗算及び剰余）を通常の方法でこれらの２つの数字に適用することと、＜ｎｕｍｂｅｒ）（＜数＞）プロダクションに準拠した形式でその結果を戻すことと、を備える。

【0422】

演算子の他の例は、＜演算子＞プロダクション‘＝’によって識別される割り当て演算子である。この演算子は、左の引数が＜トークン＞プロダクションに準拠する内容を有するストリングまで評価することを要求する。ストリングの内容は、囲む引用符内の文字ストリングであると定義される。等式演算子は、その名前が左の引数の内容に等しい＜ｔｏｋｅｎ＞である変数に右の引数の評価結果に等しい値が割り当てられるようにする。この値も、演算子式の評価結果である。

【0423】

演算子の他の例は、＜ｏｐｅｒａｔｏｒ＞プロダクション‘；’によって識別されるシーケンス演算子である。この演算子の評価結果は、右の引数である。全演算子と同様に、両方の引数が評価され、左の引数が最初に評価されることに注目すること。

【0424】

この発明の一実施形態においては、ファイルの識別子は、要求されるファイルを識別する入力変数の特定の組を用いて上記の規則によりファイル識別子構築規則を評価することによって入手することができる。入力変数の一例は、名前“ｉｎｄｅｘ”及びプレゼンテーション内のファイルの数値インデックスに等しい値を有する変数である。入力変数の他の例は、名前“ｂｉｔｒａｔｅ”及びプレゼンテーションの要求されるバージョンの平均ビットレートに等しい値を有する変数である。

【0425】

図２３は、ファイル識別子構築規則の数例を示し、入力変数は、希望されるプレゼンテーションの表現に関する識別子を与える“ｉｄ”及びファイルに関するシーケンス番号を与える“ｓｅｑ”である。

【0426】

この開示を読み次第当業者にとって明確になるように、上記の方法の数多くの変形が可能である。例えば、上述されるすべての関数及び演算子が提供される必要があるわけではなく及び追加の関数又は演算子を提供することができる。

【0427】

ＵＲＬ構築規則及びタイミング
この節は、ファイル又はセグメントＵＲＩを割り当てるための基本的なＵＲＬ構築規則及び表現及びメディアプレゼンテーション内の各セグメントに関する開始時間を提供する。

【0428】

この項に関しては、クライアントにおけるメディアプレゼンテーション記述の入手可能性が仮定される。

【0429】

ＨＴＴＰストリーミングクライアントがメディアプレゼンテーション内でダウンロードされるメディアをプレイアウト中であると仮定する。ＨＴＴＰクライアントの実際の提示時間は、提示時間がプレゼンテーションの始めに関してどの時点であるかについて定義することができる。初期化時には、提示時間ｔ＝０を仮定することができる。

【0430】

いずれの時点ｔにおいても、ＨＴＴＰクライアントは、実際の提示時間ｔよりも多くともＭａｘｉｍｕｍＣｌｉｅｎｔＰｒｅＢｕｆｆｅｒＴｉｍｅだけ前の（及びプレゼンテーションの始めに関する）再生時間ｔＰを有するあらゆるデータ及びユーザとの対話、例えばシーク、早送り、等に起因して要求されるあらゆるデータをダウンロードすることができる。幾つかの実施形態においては、ＭａｘｉｍｕｍＣｌｉｅｎｔＰｒｅＢｕｆｆｅｒＴｉｍｅは、クライアントが制約なしに現在の再生時間ｔＰよりも前にデータをダウンロードすることができるという意味で指定しないことさえもできる。

【0431】

ＨＴＴＰクライアントは、不必要なデータをダウンロードするのを回避することができ、例えば、プレイアウトされることが予想されない表現からのいずれのセグメントも典型的にはダウンロードしないことができる。

【0432】

ストリーミングサービスを提供する際の基本プロセスは、例えばＨＴＴＰ ＧＥＴ要求又はＨＴＴＰ部分的ＧＥＴ要求を使用して、ファイル全体／セグメント又はファイル／セグメントの部分組をダウンロードするための該当する要求の生成によるデータのダウンロードであることができる。この説明は、特定の再生時間ｔＰに関するデータにアクセスする方法に対処するが、概して、クライアントは、非効率的な要求を回避するためにそれよりも大きい時間範囲の再生時間に関するデータをダウンロードすることができる。ＨＴＴＰクライアントは、ストリーミングサービスを提供する際のＨＴＴＰ要求の数／頻度を最少にすることができる。

【0433】

特定の表現において再生時間ｔＰにおいて又は少なくとも再生時間ｔＰ近くにおいてメディアデータにアクセスするために、クライアントは、この再生時間を含むファイルのＵＲＬを決定し、この再生時間にアクセスするためのファイル内のバイト範囲をさらに決定する。

【0434】

メディアプレゼンテーション記述は、例えばＲｅｐｅｒｓｅｎｔａｔｉｏｎＩＤ属性の使用によって、各表現に表現ｉｄ、ｒ、を割り当てることができる。換言すると、ＭＰＤの内容は、取り込みシステムによって書かれたとき又はクライアントによって読まれたときには、割り当てが存在するように解釈される。ｉｄ、ｒを有する特定の表現のための特定の再生時間ｉＰに関するデータをダウンロードするために、クライアントは、ファイルに関する該当するＵＲＬを構築することができる。

【0435】

メディアプレゼンテーション記述は、各表現ｒの各ファイル又はセグメントに次の属性を割り当てることができる。

【0436】

（ａ）表現ｒ内のファイルのシーケンス番号ｉ、ｉ＝１、２、．．．、Ｎｒ、（ｂ）表現ｉｄｒを有するファイルの相対的開始時間及び提示時間に関するファイルインデックスｉ、ｔｓ（ｒ，ｉ）として定義される、（ｃ）表現ｉｄｒ及びファイルインデックスｉを有するファイル／セグメントに関するファイルＵＲＬ、ＦｉｌｅＵＲＬ（ｒ，ｉ）として表される。

【0437】

一実施形態においては、ファイルの開始時間及びファイルＵＲＬは、表現のために明示で提供することができる。他の実施形態においては、ファイルＵＲＬのリストを明示で提供することができ、各ファイルＵＲＬは、リスト内の位置によりインデックスｉが固有に割り当てられ、セグメントの開始時間は、１乃至ｉ−１のセグメントに関する全セグメント継続時間の和として導き出される。各セグメントの継続時間は、上述される規則のうちのいずれかにより提供することができる。例えば、基礎数学の当業者は、単一の要素又は属性及び表現内のファイルＵＲＬの位置／インデックスから開始時間を容易に導き出すための方法を導き出すためにその他の方法を用いることができる。

【0438】

動的ＵＲＬ構築規則がＭＰＤで提供される場合は、各ファイルの開始時間及び各ファイルＵＲＩは、構築規則、要求されるファイルのインデックス及びメディアプレゼンテーション記述において提供される潜在的に幾つかの追加のパラメータを用いることによって動的に構築することができる。情報は、例えばＭＰＤ属性及び要素、例えばＦｉｌｅＵＲＩＰａｔｔｅｒｎ及びＦｉｌｅＩｎｆｏＤｙｎａｍｉｃにおいて提供することができる。ＦｉｌｅＵＲＬＰａｔｔｅｒｎは、ファイルインデックスシーケンス番号ｉ及び表現ＩＤｒに基づいてＵＲＩを構築する方法に関する情報を提供する。ＦｉｌｅＵＲＩＦｏｒｍａｔは、次のように構築される。

【0439】

FileURIFormat=sprintf(“%s%s%s%s%s.%s”, BaseURL, BaseFileName,
RepresentationIDFormat, SeparatorFormat, FileSequenceIDFormat, FileExtension);
及びFileURL(r,i)は次のように構築される。

【0440】

FileURL(r,i)=sprintf(FileURIFormat, r, i);
各ファイル／セグメントに関する相対的開始時間ｔｓ（ｒ，ｉ）は、この表現内のセグメントの継続時間を記述するＭＰＤに含まれた何らかの属性、例えばＦｉｌｅＩｎｆｏＤｙｎａｍｉｃ属性、によって導き出すことができる。ＭＰＤは、上記されるのと同じようにメディアプレゼンテーション内の全表現に関して又は少なくともある期間内の全表現に関してグローバルであるＦｉｌｅＩｎｆｏＤｙｎａｍｉｃ属性のシーケンスを含むこともできる。表現ｒ内の特定の再生時間ｔＰに関するメディアデータが要求される場合は、対応するインデックスｉ（ｒ，ｔＰ）はｉ（ｒ，ｔ_ｐ）として導き出され、このため、このインデックスの再生時間はｔｓ（ｒ，ｉ（ｒ，ｔＰ））の開始時間及びｔｓ（ｒ，ｉ（ｒ，ｔＰ）＋１）の間隔内に存在する。セグメントアクセスは、上記の事例によってさらに制約されることがあり、例えば、セグメントにアクセスできない。

【0441】

対応するセグメントのインデックス及びＵＲＬが取得された時点で正確な再生時間ｔＰにアクセスすることは、実際のセグメント形式に依存する。この例では、メディアセグメントは一般性を失うことなしに０において開始するローカルタイムラインを有すると仮定する。再生時間ｉＰにおいてデータにアクセスして提示するために、クライアントは、ｉ＝ｉ（ｒ，ｔ_ｐ）であるＵＲＬＦｉｌｅＵＲＩ（ｒ，ｉ）を通じてアクセスすることができるファイル／セグメントからローカル時間に対応するデータをダウンロードすることができる。

【0442】

概して、クライアントは、ファイル全体をダウンロードすることができ及び再生時間ｔＰにアクセスすることができる。しかしながら、３ＧＰファイルはバイト範囲にローカルタイミングをマッピングするための構造を提供するため、３ＧＰファイルの必ずしもすべての情報をダウンロードする必要はない。従って、十分なランダムアクセス情報を入手可能である限りはメディアを再生するためには再生時間ｔＰにアクセスするための特定のバイト範囲のみで十分であることができる。さらに、例えばセグメントインデックスを用いて、セグメントの最初の部分においてバイト範囲の構造及びマッピング及びメディアセグメントのローカルタイミングに関する十分な情報を提供することができる。セグメントの最初の例えば１２００バイトへのアクセスを有することで、クライアントは、再生時間ｔＰにとって必要なバイト範囲に直接アクセスするための十分な情報を有することができる。

【0443】

さらなる例では、要求されるフラグメント又はフラグメント（複数）のバイトオフセットを識別するためにおそらく以下の“ｔｉｄｘ” ボックスとして指定された、セグメントインデックスを用いることができると仮定する。要求されたフラグメント又はフラグメント（複数）のために部分的ＧＥＴ要求を形成することができる。その他の代替策が存在することができ、例えば、クライアントは、ファイルに関して標準的な要求を出すこと及び第１の“ｔｉｄｘ”ボックスが受信されているときにこれを取り消すことができる。

【0444】

シーク
クライアントは、表現内の特定の提示時間ｔｐまでシークするのを試みることができる。ＭＰＤに基づき、クライアントは、表現内の各セグメントのメディアセグメント開始時間及びメディアセグメントＵＲＬへのアクセスを有する。クライアントは、最大セグメントインデックスｉとして提示時間ｔｐのためのメディアサンプルを含む可能性が最も高いセグメントのセグメントインデックスｓｅｇｍｅｎｔ＿ｉｎｄｅｘを入手することができ、開始時間ｔＳ（ｒ，ｉ）は、提示時間ｔｐ以下であり、すなわち、ｓｅｇｍｅｎｔ＿ｉｎｄｅｘ＝ｍａｘ｛ｉ｜ｔＳ（ｒ，ｉ）≦ｔｐ｝である。セグメントＵＲＬは、ＦｉｌｅＵＲＬ（ｒ，ｉ）として入手される。

【0445】

ＭＰＤ内のタイミング情報は、ランダムアクセスポイントの配置、メディアトラックの整合及びメディアタイミングドリフトに関連する課題に起因して概算であることに注目すること。その結果、上記の手順によって識別されるセグメントは、ｔｐのわずかに後の時間に開始することができ、及び、提示時間ｔｐのためのメディアデータは、前のメディアセグメント内に存在することができる。シークの場合は、シーク時間は、取り出されたファイルの第１のサンプル時間に等しくなるように更新することができ、又は、先行するファイルを代わりに取り出すことができる。しかしながら、代替表現／バージョン間での切り換えが存在する事例を含む連続的なプレイアウト中に、時間ｔｐと取り出されたセグメントの始めとの間の時間のためのメディアデータを入手可能であることに注目すること。

【0446】

提示時間ｔｐまでの正確なシークのために、ＨＴＴＰストリーミングクライアントは、ランダムアクセスポイント（ＲＡＰ）にアクセスする必要がある。３ＧＰＰ適応型ＨＴＴＰストリーミングの場合のメディアセグメント内のランダムアクセスポイントを決定するために、クライアントは、例えば、ランダムアクセスポイントの位置を特定するための‘ｔｉｄｘ’又は‘ｓｉｄｘ’ボックス内の情報、存在する場合、及びメディアプレゼンテーション内の対応する提示時間を用いることができる。セグメントが３ＧＰＰムービーセグメントである事例では、クライアントが、例えばＲＡＰの位置を特定し及びムービーフラグメント内の情報からの必要な提示時間及びＭＰＤから導き出されたセグメント開始時間を入手するために、‘ｍｏｏｆ’及び‘ｍｄａｔ’ボックス内の情報を使用することも可能である。要求された提示時間ｔｐよりも前の提示時間を有するＲＡＰが入手可能でない場合は、クライアントは、前セグメントにアクセスすることができ又は第１のランダムアクセスポイントをシーク結果として使用することができる。メディアセグメントがＲＡＰから開始するときにはこれらの手順は単純である。

【0447】

提示時間ｔｐにアクセスするためにメディアセグメントの必ずしもすべての情報をダウンロードする必要はないことにも注目すること。クライアントは、例えば、バイト範囲要求を用いてメディアセグメントの始めから‘ｔｉｄｘ’又は‘ｓｉｄｘ’ボックスを最初に要求することができる。‘ｔｉｄｘ’又は‘ｓｉｄｘ’ボックスの使用により、セグメントのバイト範囲にセグメントタイミングをマッピングすることができる。部分的ＨＴＴＰ要求を連続的に用いることによって、向上されたユーザ経験及び低い立ち上がり遅延のために、メディアセグメントの該当部分のみにアクセスするだけでよい。

【0448】

セグメントリスト生成
ここにおいて説明されるように、ｄｕｒのシグナリングされた概算のセグメント継続時間を有する表現のためのセグメントのリストを生成するためにＭＰＤによって提供された情報を用いる直接的なＨＴＴＰストリーミングクライアントを実装する方法が明確なはずである。幾つかの実施形態においては、クライアントは、表現内のメディアセグメントに連続的なインデックスｉ＝１、２、３、．．．、を割り当てることができ、すなわち、第１のメディアセグメントにはインデックスｉ＝１が割り当てられ、第２のメディアセグメントにはインデックスｉ＝２が割り当てられ、以下同様である。次に、セグメントインデックスｉを有するメディアセグメントのリストにｓｔａｒｔＴｉｍｅ［ｉ］が割り当てられてＵＲＬ［ｉ］が例えば次のように生成される。最初に、インデックスｉが１に設定される。第１のメディアセグメントの開始時間は、０、ｓｔａｒｔＴｉｍｅ［１］＝０として入手される。メディアセグメントｉのＵＲＬ、ＵＲＬ［ｉ］は、ＦｉｌｅＵＲＬ（ｒ，ｉ）として入手される。プロセスは、インデックスｉを有するすべての記述されたメディアセグメントに関して継続され、メディアセグメントｉのｓｔａｒｔＴｉｍｅ［ｉ］が（ｉ−１）^＊ｄｕｒとして入手され、ＵＲＬ［ｉ］がＦｉｌｅＵＲＩ（ｒ，ｉ）として入手される。

【0449】

同時並行ＨＴＴＰ／ＴＣＰ要求
ブロック−要求ストリーミングシステムにおける１つの懸念は、プレイアウトに間に合う形で完全に受信することができる最高の品質のブロックを常に要求することの希望である。しかしながら、データ到着レートは事前に知ることができず、このため、要求されたブロックがプレイアウトに間に合う形で到着しないことがある。この結果、メディアのプレイアウトを休止させる必要性が生じ、その結果として不良なユーザ経験になる。この問題は、データ到着レートがブロックの受信中に低下した場合でさえも、時間に間に合う形で受信される可能性がより高いより低品質の（そしてこのためより小さいサイズの）ブロックを要求することによって要求すべきブロックを選択する控えめな手法をとるクライアントアルゴリズムによって軽減することができる。しかしながら、この控えめな手法は、おそらくユーザ又は行先デバイスに対してより低い品質のプレイアウトを配信するという欠点を有しており、それも不良なユーザ経験である。その問題は、利用可能なネットワークリソースはコネクション間で共有され、従って異なるプレイアウト時間を有するブロックのために同時使用中であるため、以下において説明されるように、複数のＨＴＴＰコネクションが同時に用いられるときに増幅されることがある。

【0450】

クライアントが同時並行して複数のブロックの要求を出すのが有利であろう。この文脈では、“同時並行して”は、要求に対する応答が重なり合った時間間隔で発生していることを意味し、それは、要求がまったく又はほぼ同時に行われることは必ずしも当てはまらない。ＨＴＴＰプロトコルの場合は、この手法は、（知られるように）ＴＣＰプロトコルの動作に起因して利用可能な帯域幅の利用を向上させることができる。この点については、新しいコンテンツが最初に要求されるときには、ブロックのためのデータが要求される対応するＨＴＴＰ／ＴＣＰコネクションは始動するのが遅くなることがあり、従って、この時点で幾つかのＨＴＴＰ／ＴＣＰコネクションを用いることは第１のブロックのデータ配信時間の速度を劇的に上昇させることができるため、コンテンツザッピング時間を改善するために特に重要である。しかしながら、最初にプレイアウトされるべきブロックの要求は、後続するブロックの要求と競合しており、競合しているＨＴＴＰ／ＴＣＰダウンロードはそれらの配信時間が大幅に変動し従って要求の完了時間が大幅に可変であり、いずれのＨＴＴＰ／ＴＣＰダウンロードが素早く完了し及びいずれがより遅くなるかを制御するのは概して可能ではなく、従って、少なくとも一部の時間においては最初の数ブロックのＨＴＴＰ／ＴＣＰダウンロードが最後に完了する可能性があり、大きい及び可変のチャネルザッピング時間が生じることになるため、異なるＨＴＴＰ／ＴＣＰコネクションを通じて異なるブロック又はフラグメントを要求することは低下した性能が生じる可能性もある。

【0451】

セグメントの各ブロック又はフラグメントが別個のＨＴＴＰ／ＴＣＰコネクションを通じてダウンロードされ、及び、並行なコネクションの数がｎで、各ブロックのプレイアウト継続時間がｔ秒であり、セグメントと関連付けられたコンテンツのストリーミングレートがＳであると仮定する。クライアントがコンテンツをストリーミングするのを最初に開始するときには、ｎ^＊ｔ秒のメディアデータを表す最初のｎのブロックに関する要求を出すことができる。

【0452】

当業者に知られるように、ＴＣＰコネクションのデータレートの大きな変動が存在する。しかしながら、この説明を簡略化するために、全コネクションが並行して進行中でありこのため第１のブロックは要求されたその他のｎ−１のブロックとほぼ同時に完全に受信されると理想的に仮定する。説明をさらに簡略化するために、ｎのダウンロードコネクションによって利用される総帯域幅はダウンロードの継続時間全体の間値Ｂに固定され、及び、ストリーミングレートＳは表現全体にわたって一定であると仮定する。ブロックのプレイアウトはブロック全体がクライアントにおいて入手可能であるときに行うことができるような構造である、すなわち、ブロックのプレイアウトは、例えば、基礎になる映像符号化の構造を理由に、又は各フラグメント又はブロックを別々に暗号化するために暗号化が採用されており、従って、フラグメント又はブロック全体を復号できる前にそれを受信する必要があることを理由に、ブロックの再生はブロック全体が受信された後にしか開始できないとさらに仮定する。従って、以下において説明を簡略化するため、ブロックのうちのいずれかをプレイアウトすることができる前にブロック全体を受信する必要があると仮定する。これで、第１のブロックが到着してプレイアウトすることができる前に要求される時間は、約ｎ^＊ｔ^＊Ｓ／Ｂである。

【0453】

コンテンツザッピング時間を最小にすることが望ましいため、ｎ^＊ｔ^＊Ｓ／Ｂを最小にすることが望ましい。ｔの値は、要因、例えば基礎になる映像符号化構造及び取り込み方法がどのように利用されるか、等によって決定することができ、従ってｔは合理的に小さくすることができるが、ｔの非常に小さい値は、過度に複雑なセグメントマップになり、使用される場合は、おそらく効率的な映像符号化及び復号と適合できないことがある。ｎの値は、Ｂの値に影響を及ぼすこともあり、すなわち、Ｂは、より大きい数ｎのコネクションに関してより大きくなることがあり、従って、コネクションの数ｎを減少させることは、利用される利用可能な帯域幅の量を潜在的に低減させる悪い副作用を有し、このため、コンテンツザッピング時間を短縮させるという最終目標を達成する上で有効でないことがある。Ｓの値は、ダウンロードしてプレイアウトするためにいずれの表現が選択されるかに依存し、理想的には、Ｓは、所定のネットワーク状態のためにメディアのプレイアウト品質を最大にするためにＢに可能限り近くすべきである。従って、この説明を簡略化するために、Ｓは、Ｂとほぼ等しいと仮定する。従って、チャネルザッピング時間は、ｎ^＊ｔに比例する。従って、異なるフラグメントをダウンロードするためにより多くのコネクションを利用することは、典型的に当てはまることであるが、それらのコネクションによって利用される総帯域幅がコネクション数に非直線的に比例する場合はチャネルザッピング時間を劣化させる可能性がある。

【0454】

一例として、ｔ＝１秒と仮定すると、ｎ＝１の場合はＢの値＝５００Ｋｂｐｓ、ｎ＝２の場合はＢの値＝７００Ｋｂｐｓ、ｎ＝３の場合はＢの値＝８００Ｋｂｐｓである。Ｓ＝７００Ｋｂｐｓを有する表現が選択されたと仮定すると、ｎ＝１の場合は、第１のブロックに関するダウンロード時間は、１^＊７００／５００＝１．４秒、ｎ＝２の場合は、第１のブロックに関するダウンロード時間は、２^＊７００／７００＝２秒、ｎ＝３の場合は、第１のブロックに関するダウンロード時間は、３^＊７００／８００＝２．６２５秒である。さらに、コネクション数が増加するのに応じて、（１つのコネクションだけでもある程度の有意な可変性が存在する可能性があるにもかかわらず）それらのコネクションの個々のダウンロード速度の可変性が上昇する可能性がある。従って、この例では、コネクション数が増加するのに応じてチャネルザッピング時間及びチャネルザッピング時間の可変性が上昇する。直感的に、配信中のブロックは異なる優先度を有しており、すなわち、第１のブロックは最も早い配信期限を有し、第２のブロックは２番目に早い期限を有し、等であり、他方、ブロックが配信中であるダウンロードコネクションは、配信中にネットワークリソースに関して競合中であり、従って、最も早い期限を有するブロックは、より多くの競合するブロックが要求されるのに応じてより長く遅延する。他方、この場合でも、究極的に２つ以上のダウンロードコネクションを用いることは、持続可能な形でより高いストリーミングレートをサポートするのを可能にし、例えば、３つのコネクションの場合は、この例では最大８００Ｋｂｐｓのストリーミングレートをサポートすることができ、他方、１つのコネクションでは５００Ｋｂｐｓのストリームのみをサポートすることができる。

【0455】

実際上は、上記のように、コネクションのデータレートは、経時で同じコネクション内及びコネクション間の両方において可変性が高くなる可能性があり、その結果、ｎの要求されたブロックは、概して同時には完了せず、実際には、１つのブロックは他のブロックの時間の１／２で完了するのが共通して当てはまることができる。この結果、幾つかの場合は第１のブロックはその他のブロックよりもはるかに早く完了することがあり、その他の場合は、第１のブロックはその他のブロックよりもはるかに遅く完了することがあるため予測できない挙動が生じ、その結果、プレイアウトの始めは、幾つかの場合は相対的に速く生じ、その他の場合は生じるのが遅いことがある。この予測不能な挙動は、ユーザにとっていらいらするものであることがあり、従って不良なユーザ経験であるとみなすことができる。

【0456】

従って、必要なことは、可能な良質のストリーミングレートを同時にサポートしながらチャネルザッピング時間及びチャネルザッピング時間の可変性を向上させるために複数のＴＣＰコネクションを利用することができる方法である。同じく必要なことは、必要な場合は利用可能な帯域幅のより大きい割合を最も近いプレイアウト時間を有するブロックに向けて割り当てることができるように、ブロックのプレイアウト時間が近づくのに応じて各ブロックに割り当てられた利用可能な帯域幅の割合を調整可能にする方法である。

【0457】

協力的ＨＴＴＰ／ＴＣＰ要求
今度は、同時並行するＨＴＴＰ／ＴＣＰ要求を協力的に用いるための方法を説明する。受信機は、例えば複数のＨＴＴＰバイト範囲要求を用いて複数の同時並行する協力的ＨＴＴＰ／ＴＣＰ要求を採用することができ、他方、各々の該要求は、ソースセグメント内のフラグメントの一部分、又はソースセグメントのフラグメントの全体、又は、修復セグメントの一部分又は修復フラグメント、又は修復セグメントの修復フラグメントの全体が対象となる。

【0458】

ＦＥＣ修復データの使用を伴う協力的ＨＴＴＰ／ＴＣＰ要求の利点は、一貫して素早いチャネルザッピング時間を提供するために特に重要であろう。例えば、チャネルザッピング時間では、ＴＣＰコネクションはまさに開始されたばかりであるか又はある期間の間休止状態である可能性があり、その場合は、混雑窓ｃｗｎｄは、コネクションに関して最小値であり、従って、これらのＴＣＰコネクションの配信速度は、上昇（ｒａｍｐ ｕｐ）するために幾つかの往復時間（ＲＴＴ）を要することになり、この上昇時間中に異なるＴＣＰコネクションにわたって配信速度の高い可変性が存在することになる。

【0459】

今度は、協力的ＨＴＴＰ／ＴＣＰ要求法である非ＦＥＣ法の概要が説明され、複数の同時並行するＨＴＴＰ／ＴＣＰコネクションを用いてソースブロックのメディアデータのみが要求され、すなわち、ＦＥＣ修復データは要求されない。非ＦＥＣ方法を用いた場合は、例えば、フラグメントの一部分に関してＨＴＴＰバイト範囲要求を用いて異なるコネクションを通じて同じフラグメントの一部分が要求され、従って、例えば、各々のＨＴＴＰバイト範囲要求は、フラグメントのためのセグメントマップ内で示されるバイト範囲の一部分が対象となる。個々のＨＴＴＰ／ＴＣＰ要求は、幾つかのＲＴＴ（往復時間）にわたって利用可能な帯域幅を完全に利用するためにそれの配信速度を上昇させ、従って、配信速度が利用可能な帯域幅よりも小さい相対的に長い期間が存在し、例えば、プレイアウトされるコンテンツの第１のフラグメントをダウンロードするために単一のＨＴＴＰ／ＴＣＰコネクションが用いられる場合はチャネルザッピング時間が大きくなる可能性があることが当てはまるであろう。非ＦＥＣ法を用いることで、異なるＨＴＴＰ／ＴＣＰコネクションを通じて同じフラグメントの異なる一部分をダウンロードすることは、チャネルザッピング時間を有意に短縮することができる。

【0460】

今度は、協力的ＨＴＴＰ／ＴＣＰ要求法であるＦＥＣ法の概要が説明され、複数の同時並行なＨＴＴＰ／ＴＣＰコネクションを用いてソースセグメントのメディアデータ及びメディアデータから生成されたＦＥＣ修復データが要求される。ＦＥＣ法を用いた場合は、フラグメントの一部分に関してＨＴＴＰバイト範囲要求を用いて、同じフラグメントの一部分及びそのフラグメントから生成されたＦＥＣ修復データが異なるコネクションを通じて要求され、従って、例えば各々のＨＴＴＰバイト範囲要求は、フラグメントのためのセグメントマップ内で示されるバイト範囲の一部分が対象となる。個々のＨＴＴＰ／ＴＣＰ要求は、幾つかのＲＴＴ（往復時間）にわたって利用可能な帯域幅を完全に利用するためにそれの配信速度を上昇させ、従って、配信時間が利用可能な帯域幅よりも小さい相対的に長い期間が存在し、このため、例えばプレイアウトされるコンテンツの第１のフラグメントをダウンロードするために単一のＨＴＴＰ／ＴＣＰコネクションが用いられる場合はチャネルザッピング時間が大きくなる可能性があることが当てはまるであろう。ＦＥＣ法を用いることは、非ＦＥＣ法と同じ利点を有し、及び、フラグメントを復元できる前に要求されたデータ全体が到着する必要はなく、従って、チャネルザッピング時間をさらに短縮し及びチャネルザッピング時間の可変性をさらに向上させるという追加の利点を有する。異なるＴＣＰコネクションを通じて要求を行い、及びコネクションのうちの少なくとも１つにおいてＦＥＣ修復データも要求することで過度の要求をすることによって、メディア再生を開始するのを可能にする第１の要求されたフラグメントを例えば復元するための十分なデータ量を配信するのに要する時間を大幅に短縮することができ及び協力的ＴＣＰコネクション及びＦＥＣ修復データが用いられない場合よりもはるかに一貫するようにすることができる。

【0461】

図２４（ａ）乃至（ｅ）は、ｅｍｕｌａｔｅｄ ｅｖｏｌｕｔｉｏｎ ｄａｔａ ｏｐｔｉｍｉｚｅｄ（ＥＶＤＯ）（エミュレーションされたエボリューションデータオプティマイズド）ネットワークの同じＨＴＴＰウェブサーバからの同じクライアントへの同じリンクを通じて走っている５つのＴＣＰコネクションの配信レート変動の例を示す。図２４（ａ）乃至（ｅ）において、ｘ軸は、単位が秒の時間を示し、Ｙ軸は、各コネクションに関して、１秒の間隔で測定された５つのＴＣＰコネクションの各々を通じてクライアントにおいてビットが受信されるレートを示す。この特定のエミュレーションでは、このリンクを通じて合計１２のＴＣＰコネクションが走っており、示された時間中におけるネットワークに対する負荷は相対的に高く、それは、２つ以上のクライアントがモバイルネットワークの同じセル内でストリーミングしているときに典型的であろう。配信レートは経時で多少の相関関係を有するが、多くの時点において５つのコネクションの配信レートには大幅な違いが存在することに注目すること。

【0462】

図２５は、サイズが２５０，０００ビット（約３１．２５キロバイト）であるフラグメントのための可能な要求構造を示し、フラグメントの異なる部分のために並行して行われる４つのＨＴＴＰバイト範囲要求が存在する。すなわち、第１のＨＴＴＰコネクションは、第１の５０，０００ビットを要求し、第２のＨＴＴＰコネクションは、次の５０，０００ビットを要求し、第３のＨＴＴＰコネクションは、次の５０，０００ビットを要求し、第４のＨＴＴＰコネクションは、次の５０，０００ビットを要求する。ＦＥＣが用いられない、すなわち非ＦＥＣ法である場合は、これらは、この例ではフラグメントに関する４つのみの要求である。ＦＥＣが用いられる、すなわち、ＦＥＣ法である場合は、この例では、フラグメントから生成された修復セグメントの追加の５０，０００ビットのＦＥＣ修復データを要求する１つの追加のＨＴＴＰコネクションが存在する。

【0463】

図２６は、図２４（ａ）乃至（ｅ）に示される５つのＴＣＰコネクションの最初の数秒の拡大であり、図２６において、Ｘ軸は、１００ミリ秒の間隔の時間を示し、Ｙ軸は、１００ミリ秒の間隔で測定された５つのＴＣＰコネクションの各々を通じてクライアントにおいてビットが受信されるレートを示す。１本の線は、第１の４つのＨＴＴＰコネクション（ＦＥＣデータが要求されるＨＴＴＰコネクションを除く）からフラグメントに関してクライアントにおいて受信されているビットの総量、すなわち、非ＦＥＣ法を用いて到着するもの、を示す。他の線は、５つのすべてのＨＴＴＰコネクション（ＦＥＣデータが要求されるＨＴＴＰコネクションを含む）からフラグメントに関してクライアントにおいて受信されているビットの総量、すなわち、ＦＥＣ法を用いて到着するもの、を示す。ＦＥＣ方法に関しては、フラグメントは２５０，０００の要求されるビットのうちのいずれかの２００，０００ビットの受信からＦＥＣ復号することができると仮定され、それは、例えばＲｅｅｄ−ＳｏｌｏｍｏｎＦＥＣコードが用いられる場合に実現することができ、及び、例えばＬｕｂｙＩＶにおいて説明されるＲａｐｔｏｒＱコードが用いられる場合に基本的に実現することができる。この例のＦＥＣ法に関しては、１秒後にＦＥＣ復号を用いてフラグメントを復元するために十分なデータが受信され、（第１のフラグメントが完全にプレイアウトされる前に後続するフラグメントに関するデータを要求及び受信することができると仮定した場合に）１秒のチャネルザッピング時間を可能にする。この例での非ＦＥＣ法に関しては、フラグメントを復元することができる前に４つの要求に関する全データが受信されなければならず、それは、１．７秒後に発生し、１．７秒のチャネルザッピング時間になる。このように、図２６に示される例では、非ＦＥＣ法は、ＦＥＣ法よりもチャネルサンプリング時間の点で７０％劣る。この例においてＦＥＣ法によって示される利点の理由の１つは、ＦＥＣ法に関しては、要求されたデータのうちの８０％の受信がフラグメントの復元を可能にし、他方、非ＦＥＣ法に関しては、要求されたデータの１００％の受信が要求される。このように、非ＦＥＣ法は、最も遅いＴＣＰコネクションが配信を終了させるのを待たなければならず、及び、ＴＣＰ配信レートの固有の変動に起因して、平均的なＴＣＰコネクションと比較して最も遅いＴＣＰコネクションの配信速度に大幅な偏差が存在する傾向がある。この例のＦＥＣ法を用いた場合は、１つの遅いＴＣＰコネクションは、フラグメントがいつ復元可能であるかを決定しない。代わりに、ＦＥＣ法の場合は、十分なデータの配信は、より悪い場合のＴＣＰ配信レートよりも平均のＴＣＰ配信レートの関数であることが非常に多い。

【0464】

上述される非ＦＥＣ法及びＦＥＣ法の数多くの変形が存在する。例えば、協力的ＨＴＴＰ／ＴＣＰ要求は、チャネルザッピングが発生した後の最初の数フラグメントのみに関して用いることができ、その後は、さらなるフラグメント、複数のフラグメント、又はセグメント全体をダウンロードするために単一のＨＴＴＰ／ＴＣＰ要求のみが用いられる。他の例として、用いられる協力的ＨＴＴＰ／ＴＣＰコネクションの数は、要求されているフラグメントの切迫性、すなわち、これらのフラグメントのプレイアウト時間がどの程度差し迫っているか、及び現在のネットワーク状態の両方の関数であることができる。

【0465】

幾つかの変形では、修復セグメントからの修復データを要求するために複数のＨＴＴＰコネクションを用いることができる。その他の変形では、例えばメディアバッファの現在のサイズ及びクライアントにおけるデータ受信レートに依存して異なるＨＴＴＰコネクションにおいて異なる量のデータを要求することができる。他の変形では、ソース表現は互いに独立しておらず、その代わりに、層化されたメディアコーディングを表現し、例えば拡張されたソース表現は、ベースソース表現に依存することができる。この場合は、ベースソース表現に対応する修復表現、及び、ベース及び拡張ソース表現の組み合わせに対応する他の修復表現が存在することができる。

【0466】

追加の全体的な要素が、上記において開示される方法によって実現することができる利点を増強する。例えば、用いられるＨＴＴＰコネクションの数は、メディアバッファ内の現在のメディア量、及び／又はメディアバッファ内への受信レートに依存して変動することができる。ＦＥＣ、すなわち、上述されるＦＥＣ法及びその方法の変形、を用いる協力的ＨＴＴＰ要求は、メディアバッファが相対的に空であり、メディアバッファが増大するのに応じて、例えば、第１のフラグメントの異なる部分に関して並行してより多くの協力的ＨＴＴＰ要求が行われ、ソースフラグメント全体及び対応する修復フラグメントからの修復データの相対的に大きい部分を要求し、次に、減少された数の同時並行のＨＴＴＰ要求に移行し、１つの要求当たりメディアデータのより大きい部分を要求し、及び、修復データのより小さい部分を要求し、例えば、１つ、２つ又は３つの同時並行のＨＴＴＰ要求に移行し、１つの要求当たり全フラグメント又は複数の連続するフラグメントの要求を行うことに移行し、及び修復データを要求しないことに移行するときに、積極的に用いることができる。

【0467】

他の例として、ＦＥＣ修復データの量は、メディアバッファサイズの関数として変動することができ、すなわち、メディアバッファが小さいときにはより多くのＦＥＣ修復データを要求することができ、メディアバッファが増大するのに応じて、要求されるＦＥＣ修復データの量が低減することができ、メディアバッファが十分に大きいいずれかの時点においてはＦＥＣ修復データは要求することができず、ソース表現のソースセグメントからのデータのみである。該拡張技法の利益は、それらが、要求メッセージトラフィック及びＦＥＣ修復データの両方を低減させることによってソースセグメント内のメディアを配信することによって消費されることになる量を超えて用いられる追加の帯域幅の量を同時に最小にしながら、及び、所定のネットワーク状態に関して可能な最高のメディアレートのサポートを同時に可能にしながら、より高速の及びより一貫したチャネルザッピング時間、及び潜在的なメディアのスタッタ−（ｓｔｕｔｔｅｒ）又は停止に対するより高い弾力性を可能にすることができることである。

【0468】

同時並行ＨＴＴＰコネクションを使用時の追加の拡張
適切な条件が満たされる場合はＨＴＴＰ／ＴＣＰ要求を廃棄することができ、及び、廃棄された要求において要求されたデータに取って代わることができるデータをダウンロードするために他のＨＴＴＰ／ＴＣＰ要求を行うことができ、第２のＨＴＴＰ／ＴＣＰ要求は、原要求内とまったく同じデータ、例えば、ソースデータ、又は重複データ、例えば、第１の要求で要求されていなかった同じソースデータ及び修復データの一部、又は完全に切り離されたデータ、例えば、第１の要求で要求されていなかった修復データ、を要求することができる。適切な条件の一例は、要求が、提供された時間内でのブロックサーバインフラストラクチャ（ＢＳＩ）からの応答なし又はＢＳＩへの転送コネクションの確立の失敗又はサーバからの明示の失敗メッセージの受信又は他の失敗条件に起因して要求が失敗したことである。

【0469】

適切な条件の他の例は、接続速度（対象となる要求に応答したデータ到着速度）の尺度と予想される接続速度との比較又はそこに含まれるメディアデータのプレイアウト時間又はその時間に依存する他の時間の前に応答を受信することが要求される接続速度の推定値の比較により、データの受信が通常よりも遅く進行していることである。

【0470】

この手法は、ＢＳＩが失敗又は不良な性能を時折呈する場合に利点を有する。この場合は、上記の手法は、クライアントがＢＳＩ内での失敗又は不良な性能にかかわらずメディアデータの信頼できるプレイアウトを継続することができる確率を上昇させる。幾つかの場合には、該失敗又は不良な性能を時折呈するようにＢＳＩを設計することに利点が存在することがあり、例えば、該設計は、該失敗又は不良な性能を呈さない又はこれらをより低い頻度で呈する代替設計よりも低いコストを有することができる。この場合は、ここにおいて説明される方法は、それがユーザ経験の結果的な劣化なしでＢＳＩのための該より低いコストの設計の利用を可能にするという点でさらなる利点を有する。

【0471】

他の実施形態においては、所定のブロックに対応するデータに関して出される要求の数は、そのブロックに関する適切な条件が満たされるかどうかに依存することができる。条件が満たされない場合は、クライアントは、ブロックに関するすべての現在未完了のデータ要求の成功裏の完了が高い確率でのブロックの復元を可能にする場合にブロックに関するさらなる要求を行うことを制約することができる。条件が満たされる場合は、ブロックに関するより多い数の要求を出すことができる、すなわち、上記の制約は適用されない。適切な条件の一例は、ブロックのスケジューリングされたプレイアウト時間又はその時間に依存する他の時間までの時間が提供されたスレショルドよりも低くなることである。この方法は、ブロックを備えるメディアデータのプレイアウト時間が近いためブロックの受信がより迫っているときにブロックに関する追加のデータ要求が出されるため利点を有する。共通の転送プロトコル、例えばＨＴＴＰ／ＴＣＰ、の場合は、これらの追加要求は、対象となるブロックの受信に貢献するデータ専用の利用可能な帯域幅の割合を増大させるという効果を有する。これは、完了するためにブロックを復元させるための十分なデータの受信に要する時間を短縮し、従って、ブロックを備えるメディアデータのスケジューリングされたプレイアウト時間の前にブロックを復元することができない確率を引き下げる。上述されるように、ブロックを備えるメディアデータのスケジューリングされたプレイアウト時間の前にブロックを復元することができない場合は、プレイアウトが休止し、その結果不良なユーザ経験になるおそれがあり、従って、ここにおいて説明される方法は、この不良なユーザ経験の確率を有利に引き下げる。

【0472】

この明細書を通じて、ブロックのスケジューリングされたプレイアウト時間への言及は、ブロックを備える符号化されたメディアデータが休止なしでプレゼンテーションのプレイアウトを達成するためにクライアントにおいて最初に入手可能であることができる時間を意味することが理解されるべきである。メディアプレゼンテーションシステムの当業者にとって明確になるように、この時間はブロックの実際のプレイアウトを有効にするためにそのブロックを備えるメディアデータに幾つかの変換関数を適用する必要があり及びこれらの関数は一定の量の完了時間を要求することがあるため、実際上は、プレイアウトのために用いられる物理的変換器（画面、スピーカ、等）におけるブロックを備えるメディアの出現の実際の時間よりもわずかに前である。例えば、メディアデータは、概して圧縮形式で転送され、伸張変換を適用することができる。

【0473】

協力的ＨＴＴＰ／ＦＥＣ法をサポートするファイル構造を生成するための方法
協力的ＨＴＴＰ／ＦＥＣ法を採用するクライアントによって有利に用いることができるファイル構造を生成するための実施形態が今度は説明される。この実施形態においては、各ソースセグメントに関して、次のように生成された対応する修復セグメントが存在する。パラメータＲは、ソースセグメント内のソースデータのために平均してどれだけのＦＥＣ修復データが生成されるかを示す。例えば、Ｒ＝０．３３は、ソースセグメントが１，０００キロバイトのデータを含む場合は、対応する修復セグメントは約３３０キロバイトの修復データを含むことを示す。パラメータＳは、ＦＥＣの符号化及び復号のために用いられる単位がバイトのシンボルサイズを示す。例えば、Ｓ＝６４は、ソースデータ及び修復データがＦＥＣ符号化及び復号を目的としてサイズが６４バイトのシンボルをそれぞれ備えることを示す。

【0474】

修復セグメントは、次のようにソースセグメントに関して生成することができる。ソースセグメントの各フラグメントは、ＦＥＣ符号化目的上のソースブロックであるとみなされ、従って、各フラグメントは、修復シンボルが生成されるソースブロックのソースシンボルのシーケンスとして処理される。第１のｉのフラグメントのために生成された合計の修復シンボル数は、ＴＮＲＳ（ｉ）＝ｃｅｉｌｉｎｇＲ^＊Ｂ（ｉ）／Ｓ）として計算され、ｃｅｉｌｉｎｇ（ｘ）は、少なくともｘである値を有する最小整数を出力する関数である。このため、フラグメントｉのために生成される修復シンボル数は、ＮＲＳ（ｉ）＝ＴＮＲＳ（ｉ）−ＴＮＲＳ（ｉ−１）である。

【0475】

修復セグメントは、フラグメントのための修復シンボルの連結を備え、修復セグメント内での修復シンボルの順序は、それらが生成されるフラグメントの順序であり、フラグメント内では、修復シンボルは、それらの符号化シンボル識別子（ＥＳＩ）の順序である。ソースセグメント構造に対応する修復セグメント構造が図２７に示され、修復セグメント生成器２７００を含む。

【0476】

上述されるようにフラグメントのための修復シンボル数を定義することによって、すべての以前のフラグメントのための修復シンボルの総数、そして従って修復セグメント内へのバイトインデックス、は、Ｒ、Ｓ、Ｂ（ｉ−１）及びＢ（ｉ）に依存するにすぎず、ソースセグメント内のフラグメントの前の又は後続する構造のいずれにも依存しない。これは、クライアントが、修復ブロックが生成されるソースセグメントの対応するフラグメントの構造に関するローカル情報のみを用いて、修復セグメント内の修復ブロックの始めの位置を素早く計算すること、及びその修復ブロック内の修復シンボル数を同じく素早く計算することを可能にするため有利である。このように、クライアントがソースセグメントの中央からフラグメントのダウンロード及びプレイアウトを開始するのを決定した場合は、それは、対応する修復セグメント内から対応する修復ブロックを同じく素早く生成し及びアクセスすることができる。

【0477】

フラグメントｉに対応するソースブロック内のソースシンボル数は、ＮＳＳ（ｉ）＝ｃｅｉｌｉｎｇ（（Ｂ（ｉ）−Ｂ（ｉ−１））／Ｓ）として計算される。最後のソースシンボルは、Ｂ（ｉ）−Ｂ（ｉ−１）がＳの倍数でない場合はＦＥＣ符号化及び復号の目的のためにゼロバイトでパディング（ｐａｄｄｉｎｇ）される、すなわち、最後のソースシンボルがゼロバイトでパディングされ、このため、それは、ＦＥＣ符号化及び復号の目的上はサイズがＳバイトであるが、これらのゼロのパディングバイトは、ソースセグメントの一部として格納されない。この実施形態においては、ソースシンボルのためのＥＳＩは、０、１、．．．、ＮＳＳ（ｉ）−１であり、修復シンボルのためのＥＳＩは、ＮＳＳ（ｉ）、．．．、ＮＳＳ（ｉ）＋ＮＲＳ（ｉ）−１である。

【0478】

この実施形態における修復セグメントに関するＵＲＬは、例えば接頭辞“．ｒｅｐａｉｒ”（修復）をソースセグメントのＵＲＬに単に添付することによって対応するソースセグメントに関するＵＲＬから生成することができる。

【0479】

ここにおいて説明されるように、修復セグメントのための修復インデキシング情報およびＦＥＣ情報は、対応するソースセグメントのためのインデキシング情報によって及びＲ及びＳの値から暗黙に定義される。時間オフセット及び修復セグメントを備えるフラグメント構造は、対応するソースセグメントの時間オフセット及び構造によって決定される。フラグメントｉに対応する修復セグメント内の修復シンボルの終わりに対するバイトオフセットは、ＲＢ（ｉ）＝Ｓ^＊ｃｅｉｌｉｎｇ（Ｒ^＊Ｂ（ｉ）／Ｓ）として計算することができる。このため、フラグメントｉに対応する修復セグメント内のバイト数は、ＲＢ（ｉ）−ＲＢ（ｉ−１）であり、従って、フラグメントｉに対応する修復シンボル数は、ＮＲＳ（ｉ）＝（ＲＢ（ｉ）−ＲＢ（ｉ−１））／Ｓとして計算される。フラグメントｉに対応するソースシンボル数は、ＮＳＳ（ｉ）＝ｃｅｉｌｉｎｇ（（Ｂ（ｉ）−Ｂ（ｉ−１））／Ｓ）として計算することができる。従って、この実施形態においては、修復セグメント内の修復ブロックのための修復インデキシング情報および対応するＦＥＣ情報は、対応するソースセグメントの対応するフラグメントのためのＲ、Ｓ及びインデキシング情報から暗黙に導き出すことができる。

【0480】

一例として、バイトオフセットＢ（１）＝６，４１０において開始し、バイトオフセットＢ（２）＝６，７７０において終了するフラグメント２を示した図２８の例を検討する。この例では、シンボルサイズはＳ＝６４バイトであり、点から成る垂直線は、Ｓの倍数に対応するソースセグメント内のバイトオフセットを示す。ソースセグメントサイズの一部分としての全体的修復セグメントサイズは、この例ではＲ＝０．５に設定される。フラグメント２のためのソースブロック内のソースシンボル数は、ＮＳＳ（２）＝ｃｅｉｌｉｎｇ（（６，７７０−６４１０）／６４）＝ｃｅｉｌ（５．６２５）＝６として計算され、これらの６つのソースシンボルは、ＥＳＩ０，．．．、５をそれぞれ有し、第１のソースシンボルは、ソースセグメント内でバイトインデックス６，４１０において開始するフラグメント２の最初の６４バイトであり、第２のソースシンボルは、ソースセグメント内でバイトインデックス６，４７４において開始するフラグメント２の次の６４バイトであり、以下同様である。フラグメント２に対応する修復ブロックの最後のバイトオフセットは、ＲＢ（２）＝６４^＊ｃｅｉｌｉｎｇ（０．５^＊６，７７０／６４）＝６４^＊ｃｅｉｌｉｎｇ（５２．８９．．．）＝６４^＊５３＝３，３９２として計算され、フラグメント２に対応する修復ブロックの開始バイトオフセットは、ＲＢ（１）＝６４^＊ｃｅｉｌｉｎｇ（０．５^＊６，４１０／６４）＝６４^＊ｃｅｉｌｉｎｇ（５０．０７．．．）＝６４^＊５１＝３，２６４として計算され、従って、この例では、ＥＳＩ６及び７をそれぞれ有するフラグメント２に対応する修復ブロック内には２つの修復シンボルが存在し、修復セグメント内のバイトオフセット３，２６４において開始し、バイトオフセット３，３９２において終了する。

【0481】

図２８に示される例では、Ｒ＝０．５であり及びフラグメント２に対応する６つのソースシンボルが存在するにもかかわらず、修復シンボル数を計算するためにソースシンボル数を単に用いた場合に予想できるように、修復シンボル数は３でなく、ここにおいて説明される方法により２になることに注目すること。修復シンボル数を決定するためにフラグメントのソースシンボル数を単に用いるのとは反対に、上述される実施形態は、対応するソースセグメントの対応するソースブロックと関連付けられたインデックス情報のみから修復セグメント内の修復ブロックの配置を計算するのを可能にする。さらに、ソースブロック内のソースシンボルの数Ｋ．が増加するのに応じて、概して、ＫＲは多くともｃｅｉｌ（Ｋ^＊Ｒ）であり及びＫＲは少なくともｆｌｏｏｒ（（Ｋ−１）^＊Ｒ）であるため、対応する修復ブロックの修復シンボルの数ＫＲは、Ｋ^＊Ｒによってほぼ近似の値が求められ、ここで、ｆｌｏｏｒ（ｘ）は、多くともｘである最大の整数である。

【0482】

当業者が認識することになるように、協力的ＨＴＴＰ／ＦＥＣ法を採用するクライアントによって有利に用いることができるファイル構造を生成するための上記の実施形態の数多くの変形が存在する。代替実施形態の一例として、表現のための原セグメントは、Ｎ＞１の並行セグメントに分割することができ、ｉ＝１，．．．、Ｎの場合は、原セグメントの指定された部分Ｆ_ｉはｉ番目の並行セグメント内に含められ、ここで、Ｆ_ｉのｉ＝１，．．．、Ｎに関する和は、１に等しい。この実施形態においては、上述される実施形態において修復セグメントマップがソースセグメントマップから導き出される方法と同様に、すべての並行セグメントのためのセグメントマップを導き出すために用いられる１つのマスタセグメントマップが存在することができる。例えば、マスタセグメントマップは、全ソースメディアデータが並行セグメントに分割されず、その代わりに１つの原セグメント内に含められている場合はフラグメント構造を示すことができ、原セグメントのフラグメントの最初の接頭辞内のメディアデータの量がＬバイトである場合は、最初のｉの並行セグメント間でのこの接頭辞のバイトの総数は、ｃｅｉｌ（Ｌ^＊Ｇ_ｉ）であり、ここで、Ｇ_ｉは、Ｆ_ｊのｊ＝１、．．．、ｉにおける和であるとして計算することによってマスタセグメントマップからｉ番目の並行セグメントのためのセグメントマップを導き出すことができる。代替実施形態の他の例として、セグメントは、各フラグメントのための原ソースメディアデータ及びその直後に後続するそのフラグメントのための修復データの組み合わせから成ることができ、その結果、ソースメディアデータ及びそのソースメディアデータからＦＥＣコードを用いて生成された修復データの組み合わせを含むセグメントが得られる。代替実施形態の他の例として、ソースメディアデータ及び修復データの組み合わせを含むセグメントは、ソースメディアデータ及び修復データの組み合わせを含む複数の並行セグメントに分割することができる。

【0483】

この開示を読んだ後に当業者にとってのさらなる実施形態を構想することができる。その他の実施形態においては、上記の開示された発明の組み合わせ又は副組み合わせを有利に作ることができる。例示を目的としてコンポーネントの配置例が示され、本発明の代替実施形態では組み合わせ、追加、再編成、等が企図されることが理解されるべきである。従って、本発明は、典型的な実施形態に関して説明されている一方で、当業者は、数多くの修正が可能であることを認識するであろう。

【0484】

以下に、本願の出願当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
要求に応じてクライアントデバイスに電子的に送信されるメディアデータのブロックを生成する方法であって、
プレゼンテーションのメディアを表現するデータを入手することであって、前記プレゼンテーションは、経時のプレゼンテーションであり、定義されたプレイアウトレートを有し、前記プレゼンテーションの一部分は、時間範囲によって定義することができることと、
前記プレゼンテーションのメディアを表現する前記データを複数のブロックとして格納することと、
送信前に、前記ブロック内における複数の時間範囲と複数の位置との間の対応性を特定することと、
前記ブロックの送信前に、前記対応性の少なくとも一部を表現する格納された対応性データを生成し、クライアントデバイスが、前記複数のブロックのいずれの部分組を要求すべきかを、プレイアウトされる前記プレゼンテーションの前記格納された対応性データ及び希望される時間範囲から決定することができるようにすることと、を備える、方法。
［Ｃ２］
前記格納された対応性データは、前記対応するメディアデータを同じく含むファイルの一部として格納されるＣ１に記載の方法。
［Ｃ３］
前記格納された対応性データは、ＸＭＬメタデータとしてフォーマット化されたマップであり、前記時間範囲は、前記プレゼンテーションの始めに関するものであるか又はメディアブロックの始めに関するものであるＣ１に記載の方法。
［Ｃ４］
メディアデータのブロック及び前記格納された対応性データを前記生成することは、メディア取り込みシステムによって行われ、少なくともファイル要求に応答する汎用サーバ上に格納されるＣ１に記載の方法。
［Ｃ５］
前記ファイル要求は、ＨＴＴＰ要求であるＣ４に記載の方法。
［Ｃ６］
前記メディアブロックは、可変の継続時間を有し、前記格納された対応性データは、クライアントデバイスが、メディアブロックの前記可変の継続時間に依存して変動する可能性がある時間範囲及びデータ位置の対応性を決定するのを可能にするＣ１に記載の方法。
［Ｃ７］
ピクチャグループ（ＧｏＰ）が２つ以上のメディアブロックに分割されるＣ１に記載の方法。
［Ｃ８］
提示期間にわたってメディアプレゼンテーションを提示することが可能であるクライアントデバイスにおいて、メディアサーバに対して行う要求を決定する方法であって、
前記クライアントデバイスにおいて、前記メディアプレゼンテーションの希望される期間を決定することであって、前記希望される期間は、前記提示期間の全体よりも小さいことと、
前記クライアントデバイスにおいて、前記メディアを表現するブロック内のデータ範囲に前記メディアプレゼンテーションの時間範囲をマッピングする格納された対応性データを入手することと、
前記クライアントデバイスにおいて、及び前記格納された対応性データから、いずれのデータ範囲を前記メディアサーバに要求すべきかを決定することと、
前記決定された要求を行うことと、
前記クライアントデバイスを用いて前記プレゼンテーションを提示することと、を備える、方法。
［Ｃ９］
クライアントデバイスがメディア取り込みシステムにメディアデータを要求する通信システムにおいて、
前記メディア取り込みシステムにおいて、メディアプレゼンテーションの第１のバージョンを符号化することであって、前記第１のバージョンは、入手可能にされるデータレートバージョンであることと、
ランダムアクセスポイント間の最低の時間的スペースに準じることを条件として、前記符号化の圧縮効率を最適化するために前記第１のバージョン内で前記ランダムアクセスポイントを選択することと、
前記メディアプレゼンテーションの第２のバージョンを符号化することであって、前記第２のバージョンは、入手可能にされる異なるデータレートバージョンであることと、
前記第１のバージョン内の前記ランダムアクセスポイントに時間的に一致するように前記第２のバージョン内のランダムアクセスポイントを選択することと、を備える方法。
［Ｃ１０］
クライアントデバイスがメディア取り込みシステムにメディアデータを要求する通信システムにおいて、
前記メディア取り込みシステムにおいて、メディアプレゼンテーションの第１のバージョンを符号化することであって、前記第１のバージョンは、入手可能にされるデータレートバージョンであることと、
前記第１のバージョン内のランダムアクセスポイントを選択することと、
前記メディアプレゼンテーションの第２のバージョンを符号化することであって、前記第２のバージョンは、入手可能にされる異なるデータレートのバージョンであることと、
前記第１のバージョン内の前記ランダムアクセスポイントから時間的に独立している前記第２のバージョン内の前記ランダムアクセスポイントを選択することと、を備える方法。
［Ｃ１１］
前記メディアプレゼンテーションの前記第１のバージョンの前記符号化は、前記メディアプレゼンテーションの前記第２のバージョンの前記符号化から独立して行われるＣ１０に記載の方法。
［Ｃ１２］
クライアントデバイスがメディア取り込みシステムにメディアデータを要求する通信システムにおいて、
前記クライアント側において、メディアプレゼンテーションの第１のバージョンを受信することであって、前記第１のバージョンは、入手可能にされるデータレートバージョンであり、前記第１のバージョンは、ランダムアクセスポイントの第１の組を有することと、
前記クライアント側において、メディアプレゼンテーションの第２のバージョンを受信することであって、前記第２のバージョンは、入手可能にされるデータレートバージョンであり、前記第２のバージョンは、ランダムアクセスポイントの前記第１の組から時間的に独立しているランダムアクセスポイントの第２の組を有することと、を備える方法。
［Ｃ１３］
前記メディアプレゼンテーションの前記第１のバージョンを消費することによって前記メディアを提示することと、
前記提示することを中断することなしに前記メディアプレゼンテーションの前記第２のバージョンを消費することに切り換わることであって、前記切り換わることは、ランダムアクセスポイントの前記第１の組からの第１のランダムアクセスポイントとランダムアクセスポイントの前記第２の組からの第２のランダムアクセスポイントとの間で発生することと、をさらに備えるＣ１２に記載の方法。
［Ｃ１４］
クライアントデバイスがメディア取り込みシステムからメディアデータを受信する通信システムにおいて、
前記メディア取り込みシステムにおいて、前記クライアントに最小の立ち上がり遅延値を提供することを備え、前記立ち上がり遅延は、前記クライアントデバイスが前記メディア取り込みシステムから前記メディアデータを受信するのを最初に開始したときと前記クライアントデバイスが中断なしに前記メディアデータの消費を開始することができるときとの間の前記遅延であり、前記立ち上がり遅延は、前記メディア取り込みシステムと前記クライアントとの間で利用可能な送信帯域幅の関数である、方法。
［Ｃ１５］
クライアントデバイスがメディア取り込みシステムからメディアデータを受信する通信システムにおいて、
前記クライアントデバイスにおいて、前記メディア取り込みシステムから最小の立ち上がり遅延値を受信することであって、前記立ち上がり遅延は、前記メディア取り込みシステムと前記クライアントとの間で利用可能な送信帯域幅の関数であることと、
前記メディア取り込みシステムからメディアデータを受信することと、
前記立ち上がり遅延だけ前記メディアデータの消費の開始を遅延させることと、を備える方法。
［Ｃ１６］
クライアントデバイスがメディア取り込みシステムからメディアデータストリームを受信する通信システムにおいて、
前記メディア取り込みシステムにおいて、前記メディアデータストリームと関連付けられたメディアプレゼンテーション記述（ＭＰＤ）ファイルを提供することと、
前記メディアデータストリームが前記クライアントに送信されている間に前記ＭＰＤを動的に更新することと、
前記ＭＰＤが更新されていることを示すために前記メディアデータストリーム内に信号を挿入することと、を備える方法。
［Ｃ１７］
クライアントデバイスがメディア取り込みシステムからメディアデータストリームを受信する通信システムにおいて、
前記クライアント側において、前記メディアデータストリームと関連付けられたＭＰＤが更新されていることを示す信号を前記メディアデータストリーム内で検出することと、
前記メディア取り込みシステムに前記更新されたＭＰＤの要求を送信することと、を備える方法。
［Ｃ１８］
クライアントデバイスがメディア取り込みシステムからメディアデータストリームを受信する通信システムにおいて、
前記メディア取り込みシステムにおいて、前記メディアデータストリームと関連付けられたメディアプレゼンテーション記述（ＭＰＤ）ファイルを提供することと、
有効性インジケータ及び時間間隔を前記ＭＰＤ内で提供することであって、前記インジケータは、前記ＭＰＤが前記時間間隔にわたって有効であることをシグナリングすることと、を備える方法。
［Ｃ１９］
クライアントデバイスがメディア取り込みシステムからメディアデータストリームを受信する通信システムにおいて、
前記クライアントデバイスにおいて、前記メディアデータストリームと関連付けられたメディアプレゼンテーション記述（ＭＰＤ）ファイルを受信することと、
有効性インジケータ及び時間間隔を前記ＭＰＤから抽出することであって、前記インジケータは、前記ＭＰＤが前記時間間隔にわたって有効であることをシグナリングすることと、
前記時間間隔と現在の提示時間の比較に基づいて前記ＭＰＤが有効であることを確認することと、を備える方法。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7(a)】

【図7(b)】

【図8(a)】

【図8(b)】

【図9(a)】

【図9(b)】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26】

【図27】

【図28】

【図29】