特許 6054398 適応ＨＴＴＰストリーミングのための表示の改善された切り替えを提供する切替シグナリング方法

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

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

(11)【特許番号】6054398

(24)【登録日】2016年12月9日

(45)【発行日】2016年12月27日

(54)【発明の名称】適応ＨＴＴＰストリーミングのための表示の改善された切り替えを提供する切替シグナリング方法

(51)【国際特許分類】

   H04N 21/845 20110101AFI20161219BHJP

   G06F 13/00 20060101ALI20161219BHJP

   H04N 21/238 20110101ALI20161219BHJP

【ＦＩ】

   H04N21/845

   G06F13/00 540A

   H04N21/238

【請求項の数】21

【全頁数】117

(21)【出願番号】特願2014-528652(P2014-528652)

(86)(22)【出願日】2012年8月31日

(65)【公表番号】特表2014-529970(P2014-529970A)

(43)【公表日】2014年11月13日

(86)【国際出願番号】US2012053394

(87)【国際公開番号】WO2013033565

(87)【国際公開日】20130307

【審査請求日】2014年4月28日

(31)【優先権主張番号】61/529,656

(32)【優先日】2011年8月31日

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

(31)【優先権主張番号】13/545,697

(32)【優先日】2012年7月10日

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

(73)【特許権者】

【識別番号】595020643

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

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

(74)【代理人】

【識別番号】100108855

【弁理士】

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

(74)【代理人】

【識別番号】100109830

【弁理士】

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

(74)【代理人】

【識別番号】100103034

【弁理士】

【氏名又は名称】野河 信久

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100153051

【弁理士】

【氏名又は名称】河野 直樹

(74)【代理人】

【識別番号】100140176

【弁理士】

【氏名又は名称】砂川 克

(74)【代理人】

【識別番号】100158805

【弁理士】

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

(74)【代理人】

【識別番号】100179062

【弁理士】

【氏名又は名称】井上 正

(74)【代理人】

【識別番号】100124394

【弁理士】

【氏名又は名称】佐藤 立志

(74)【代理人】

【識別番号】100112807

【弁理士】

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

(74)【代理人】

【識別番号】100111073

【弁理士】

【氏名又は名称】堀内 美保子

(72)【発明者】

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

(72)【発明者】

【氏名】ミンダー、ロレンツ・クリストフ

【審査官】 福西 章人

(56)【参考文献】

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

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

【文献】 特表２００９−５２８００２（ＪＰ，Ａ）

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

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

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

Ｈ０４Ｎ ５／３８−５／４６

Ｈ０４Ｎ ７／１０，７／１４−７／１７３，７／２０−７／２２

Ｈ０４Ｎ ２１／００−２１／８５８

Ｇ０６Ｆ １３／００

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

【請求項1】

サーバからクライアントに送信されるメディアストリームにおいて、適応ＨＴＴＰストリーミングのためのリプレゼンテーションを切り替えるためのシグナリングの方法であって、
リプレゼンテーションの１つまたは複数のセグメントのためのセグメントマップを生成することであって、前記セグメントマップは、１つまたは複数の時間的な開始点および前記１つまたは複数の時間的な開始点の各々についてバイトオフセット情報を含み、前記セグメントマップは、１つまたは複数の時間的な終了点および前記１つまたは複数の時間的な終了点の各々についてバイトオフセット情報をさらに含み、ここにおいて時間的な開始点は、１つまたは複数の他のリプレゼンテーションから前記リプレゼンテーションへの切り替えがなされることができ、前記リプレゼンテーションが前記リプレゼンテーションの任意の後続の時間的な終了点まで再生されることができる、前記リプレゼンテーション内の対応するバイトオフセット、および開始フレームを示し、ここにおいて時間的な終了点は、前記リプレゼンテーションからの切り替えが前記１つまたは複数の他のリプレゼンテーションになされることができる、前記リプレゼンテーション内の対応するバイトオフセット、および終了フレームを示し、再生は、前記時間的な終了点以前の前記リプレゼンテーションの任意の開始点で開始することができ、前記時間的な終了点まで再生される、ことと、
前記セグメントマップを前記リプレゼンテーションの前記１つまたは複数のセグメントに関連付けることと、
を備える、方法。

【請求項2】

複数のリプレゼンテーションとしてストリーミングされるコンテンツをフォーマットする方法であって、ここにおいて前記複数のリプレゼンテーションの各々はコンテンツの項目に対する選択肢であり、
前記複数のリプレゼンテーションの第１のリプレゼンテーションを複数のセグメントとして編成することであって、ここにおいてセグメントが、前記リプレゼンテーションの他のセグメントのうちでの時間的な順序を有するリプレゼンテーションコンテンツの一部分に関連するデータを備え、ここにおいてセグメントは、前のセグメントへのアクセス権を有さない受信機によって使用できる、ことと、
前記第１のリプレゼンテーションの１つまたは複数のセグメントのためのセグメントマップを生成することであって、前記セグメントマップは、１つまたは複数の時間的な開始点および前記１つまたは複数の時間的な開始点の各々についてバイトオフセット情報を含み、前記セグメントマップは、１つまたは複数の時間的な終了点および前記１つまたは複数の時間的な終了点の各々についてバイトオフセット情報をさらに含み、ここにおいて時間的な開始点は、１つまたは複数の他のリプレゼンテーションから前記第１のリプレゼンテーションへの切り替えがなされることができ、前記第１のリプレゼンテーションが前記第１のリプレゼンテーションの任意の後続の時間的な終了点まで再生されることができる、前記第１のリプレゼンテーション内の対応するバイトオフセット、および開始フレームを示し、ここにおいて時間的な終了点は、前記第１のリプレゼンテーションからの切り替えが前記１つまたは複数の他のリプレゼンテーションになされることができる、前記第１のリプレゼンテーション内の対応するバイトオフセット、および終了フレームを示し、再生は、前記時間的な終了点以前の前記第１のリプレゼンテーションの任意の開始点で開始することができ、前記時間的な終了点まで再生される、ことと、
前記第１のリプレゼンテーションの前記１つまたは複数の時間的な開始点および前記１つまたは複数の時間的な終了点と、第２のリプレゼンテーションの１つまたは複数の時間的な開始点および１つまたは複数の時間的な終了点を揃えることであって、ここにおいて揃えることが、前記第１のリプレゼンテーション内のセグメントの時間的な開始点の提示時間と前記第２のリプレゼンテーション内のセグメントの時間的な終了点の提示時間との一致をもたらす、ことと、を備える、方法。

【請求項3】

各セグメントに対してファイル名を決定することと、
各セグメントの前記ファイル名を使用する複数のファイルとして各セグメントのコンテンツを格納することとをさらに備える、請求項２に記載の方法。

【請求項4】

コンテンツを消費するクライアントにおいて、コンテンツ要求を決定することであって、ここにおいて前記コンテンツ要求が少なくとも１つのリプレゼンテーションと提示時間範囲とを規定する、ことと、
前記コンテンツ要求に対応する１つまたは複数のセグメントを表す前記複数のファイルのうちの１つまたは複数のファイルの１つまたは複数のＵＲＬのセットを決定することと、
１つまたは複数のＵＲＬの前記セットを使用して前記１つまたは複数のセグメントを要求することと、
前記１つまたは複数のセグメントを受信することと、
前記１つまたは複数のセグメントからのコンテンツを前記クライアントでコンテンツ消費者に提供することとをさらに備える、請求項３に記載の方法。

【請求項5】

ネットワークに接続し、前記ネットワークを通じて要求し、０でない再生時間を有するコンテンツを提示するように構成されたクライアントデバイスを使用してコンテンツを要求する方法であって、
コンテンツ要求を決定することであって、ここにおいて前記コンテンツ要求は少なくとも１つのリプレゼンテーションと提示時間範囲とを規定し、前記提示時間範囲は要求されている前記リプレゼンテーションの少なくとも一部分を定義する、ことと、
格納されたメディアリプレゼンテーションデータセットから、要求フォーマットのテンプレート、セグメント時間長、および可変セグメント範囲を読み取ることであって、前記可変セグメント範囲はセグメントの提示時間範囲の変動を定義し、前記変動は前記メディアリプレゼンテーションデータセットに格納される前記セグメント時間長に関係する、ことと、
前記セグメント時間長の値を前記提示時間範囲の始まりに対応する時間的な開始点と比較して、初期セグメントインデックスを決定することであって、前記時間的な開始点は、１つまたは複数の他のリプレゼンテーションから前記リプレゼンテーションへの切り替えがなされることができ、前記リプレゼンテーションが前記リプレゼンテーションの任意の後続の時間的な終了点まで再生されることができる、前記リプレゼンテーション内の対応するバイトオフセット、および開始フレームを示し、ここにおいて時間的な終了点は、前記リプレゼンテーションからの切り替えが前記１つまたは複数の他のリプレゼンテーションになされることができる、前記リプレゼンテーション内の対応するバイトオフセット、および終了フレームを示し、再生は、前記時間的な終了点以前の前記リプレゼンテーションの任意の開始点で開始することができ、前記時間的な終了点まで再生される、ことと、
前記初期セグメントインデックス、前記可変セグメント範囲、および前記セグメント時間長とを評価して、所望のセグメントインデックスを決定することと、
前記所望のセグメントインデックスおよび前記要求フォーマットのテンプレートに基づいて、前記コンテンツ要求に対応するファイル要求を生成することと、
前記ファイル要求を使用して少なくとも１つのファイルを要求することとを備える、方法。

【請求項6】

前記ファイル要求はＵＲＬであり、少なくとも１つのファイルを要求することが、前記ＵＲＬを使用したＨＴＴＰ要求を使用して実行される、請求項５に記載の方法。

【請求項7】

前記初期セグメントインデックスは前記時間的な開始点を前記セグメント時間長で除算することによって決定され、前記所望のセグメントインデックスは前記除算の余りが前記可変セグメント範囲より小さい場合に前記初期セグメントインデックスとして決定され、前記除算の余りが前記可変セグメント範囲以上である場合に前記初期セグメントインデックスのすぐ前のセグメントインデックスとして決定される、請求項５に記載の方法。

【請求項8】

前記提示時間範囲の終わりに対応する、または前記終わりよりも遅い、時間的な終了点を伴うコンテンツを含むセグメントが受信されるまで、ファイル要求を繰り返すことをさらに備える、請求項５に記載の方法。

【請求項9】

前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長から、前記セグメント時間長に前記変動の時間範囲を足した時間長までの間となるような時間範囲である、請求項５に記載の方法。

【請求項10】

前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長の１．０倍から前記セグメント時間長の１＋Ｐ倍までの間となるような比率Ｐである、請求項５に記載の方法。

【請求項11】

前記セグメント時間長に関係のある前記変動は、前記変動の時間範囲にわたる前記セグメント時間長よりもセグメント提示時間が大きくまたは小さくなり得るような時間範囲である、請求項５に記載の方法。

【請求項12】

前記提示時間範囲の終わりに対応する、または前記終わりよりも遅い、時間的な終了点を伴うコンテンツを含むセグメントが受信されるまで、ファイル要求を繰り返すことをさらに備える、請求項１１に記載の方法。

【請求項13】

セグメントが複数のリプレゼンテーションのうちの１つから要求され、前記複数のリプレゼンテーションの各々がコンテンツの項目に対する選択肢である、請求項５に記載の方法。

【請求項14】

ネットワークを通じてコンテンツを要求し、前記ネットワークを通じて取り出され０でない再生時間を有する前記コンテンツを提示するように構成されたクライアントデバイスであって、
格納された命令を実行することが可能な処理要素と、
データを格納可能なメモリと、
命令を格納可能なメモリと、
前記処理要素に、コンテンツ要求を決定させるためのプログラムコードであって、ここにおいて前記コンテンツ要求は少なくとも１つのリプレゼンテーションと提示時間範囲とを規定し、前記提示時間範囲は要求されている前記提示の少なくとも一部分を定義する、プログラムコードと、
前記処理要素に、格納されたメディアリプレゼンテーションデータセットから、要求フォーマットのテンプレート、セグメント時間長、および可変セグメント範囲を読み取らせるためのプログラムコードであって、ここにおいて前記可変セグメント範囲はセグメントの提示時間範囲の変動を定義し、前記変動は前記メディアリプレゼンテーションデータセットに格納される前記セグメント時間長に関係する、プログラムコードと、
前記処理要素に、前記セグメント時間長の値を前記提示時間範囲の始まりに対応する時間的な開始点と比較して、初期セグメントインデックスを決定させるためのプログラムコードであって、前記時間的な開始点は、１つまたは複数の他のリプレゼンテーションから前記リプレゼンテーションへの切り替えがなされることができ、前記リプレゼンテーションが前記リプレゼンテーションの任意の後続の時間的な終了点まで再生されることができる、前記リプレゼンテーション内の対応するバイトオフセット、および開始フレームを示し、ここにおいて時間的な終了点は、前記リプレゼンテーションからの切り替えが前記１つまたは複数の他のリプレゼンテーションになされることができる、前記リプレゼンテーション内の対応するバイトオフセット、および終了フレームを示し、再生は、前記時間的な終了点以前の前記リプレゼンテーションの任意の開始点で開始することができ、前記時間的な終了点まで再生される、プログラムコードと、
前記処理要素に、前記初期セグメントインデックス、前記可変セグメント範囲、および前記セグメント時間長を評価して、所望のセグメントインデックスを決定させるためのプログラムコードと、
前記処理要素に、前記所望のセグメントインデックスおよび前記要求フォーマットのテンプレートに基づいて、前記コンテンツ要求に対応するファイル要求を生成させるためのプログラムコードと、
前記ネットワークにメッセージを送信し前記ネットワークからメッセージを受信するためのネットワークインターフェースと、
前記処理要素に、前記ファイル要求を使用して少なくとも１つのファイルを要求させるためのプログラムコードとを備える、クライアントデバイス。

【請求項15】

前記ネットワークインターフェースはワイヤレスネットワークインターフェースである、請求項１４に記載のクライアントデバイス。

【請求項16】

前記ネットワークインターフェースは有線ネットワークインターフェースである、請求項１４に記載のクライアントデバイス。

【請求項17】

前記ファイル要求はＵＲＬであり、要求が前記ＵＲＬを使用したＨＴＴＰ要求である、請求項１４に記載のクライアントデバイス。

【請求項18】

前記処理要素に、前記提示時間範囲の終わりに対応する、または前記終わりよりも遅い、時間的な終了点を伴うコンテンツを含むセグメントが受信されるまで、ファイル要求を繰り返させるためのプログラムコードをさらに備える、請求項１４に記載のクライアントデバイス。

【請求項19】

前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長から、前記セグメント時間長に前記変動の時間範囲を足した時間長までの間となるような時間範囲である、請求項１４に記載のクライアントデバイス。

【請求項20】

前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長の１．０倍から前記セグメント時間長の１＋Ｐ倍までの間となるような比率Ｐである、請求項１４に記載のクライアントデバイス。

【請求項21】

前記セグメント時間長に対するものである前記変動は、セグメント提示時間が前記変動の時間範囲にわたる前記セグメント時間長よりも大きくまたは小さくなり得るような時間範囲である、請求項１４に記載のクライアントデバイス。

【発明の詳細な説明】

【関連出願】

【0001】

同時係属特許出願の参照
本出願は、２０１１年８月３１日に出願され、「Ｓｗｉｔｃｈ Ｓｉｇｎａｌｉｎｇ Ｍｅｔｈｏｄｓ Ｐｒｏｖｉｄｉｎｇ Ｉｍｐｒｏｖｅｄ Ｓｗｉｔｃｈｉｎｇ Ｂｅｔｗｅｅｎ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ Ｆｏｒ Ａｄａｐｔｉｖｅ ＨＴＴＰ Ｓｔｒｅａｍｉｎｇ」と題され、その全体が引用によりここにほとんど組み込まれる米国仮特許出願第６１／５２９，６５６号の非仮出願であって、これによる優先権を主張する。

【0002】

本開示は、同一出願人による下記の出願／特許を、本文書にほとんど全て記載されるかのように引用によって本出願に組み込む。

【0003】

２００９年９月２２日に出願され、「Ｅｎｈａｎｃｅｄ Ｂｌｏｃｋ−Ｒｅｑｕｅｓｔ Ｓｔｒｅａｍｉｎｇ Ｓｙｓｔｅｍ」と題された米国特許出願第６１／２４４，７６７号（以後「Ｌｕｂｙ Ａ１」）、
２００９年１１月３日に出願され、「Ｅｎｈａｎｃｅｄ Ｂｌｏｃｋ−Ｒｅｑｕｅｓｔ Ｓｔｒｅａｍｉｎｇ Ｓｙｓｔｅｍ」と題された米国特許出願第６１／２５７，７１９号（以後「Ｌｕｂｙ Ａ２」）、
２００９年１１月４日に出願され、「Ｅｎｈａｎｃｅｄ Ｂｌｏｃｋ−Ｒｅｑｕｅｓｔ Ｓｔｒｅａｍｉｎｇ Ｓｙｓｔｅｍ」と題された米国特許出願第６１／２５８，０８８号（以後「Ｌｕｂｙ Ａ３」）、
２００９年１２月１１日に出願され、「Ｅｎｈａｎｃｅｄ Ｂｌｏｃｋ−Ｒｅｑｕｅｓｔ Ｓｔｒｅａｍｉｎｇ Ｓｙｓｔｅｍ」と題された米国特許出願第６１／２８５，７７９号（以後「Ｌｕｂｙ Ａ４」）、
２０１０年１月２０日に出願され、「Ｅｎｈａｎｃｅｄ Ｂｌｏｃｋ−Ｒｅｑｕｅｓｔ Ｓｔｒｅａｍｉｎｇ Ｓｙｓｔｅｍ」と題された米国特許出願第６１／２９６，７２５号（以後「Ｌｕｂｙ Ａ５」）、
２０１０年９月２１日に出願され、「Ｅｎｈａｎｃｅｄ Ｂｌｏｃｋ−Ｒｅｑｕｅｓｔ Ｓｔｒｅａｍｉｎｇ Ｓｙｓｔｅｍ」と題された米国特許出願第１２／８８７，４７６号（以後「Ｌｕｂｙ Ｂ」）、
２００８年４月１５日に出願され、「Ｄｙｎａｍｉｃ Ｓｔｒｅａｍ Ｉｎｔｅｒｌｅａｖｉｎｇ ａｎｄ Ｓｕｂ−Ｓｔｒｅａｍ Ｂａｓｅｄ Ｄｅｌｉｖｅｒｙ」と題され、Ｌｕｂｙ他を挙げる米国特許出願第１２／１０３，６０５号、および、
２０１０年２月１２日に出願され、「Ｂｌｏｃｋ Ｐａｒｔｉｔｉｏｎｉｎｇ ｆｏｒ ａ Ｄａｔａ Ｓｔｒｅａｍ」と題され、Ｐａｋｚａｄ他を挙げる米国特許出願第１２／７０５，２０２号（以後「Ｐａｋｚａｄ」）。

【技術分野】

【0004】

本発明は、改善されたメディアストリーミングシステムと方法に関し、より詳細には、ストリームされたメディアの提示を最適化し、ストリームされたメディアデータの効率的な同時または適時分配の配信を提供現するためにネットワークおよびバッファ条件に適応するシステムと方法に関する。

【背景技術】

【0005】

高品質のオーディオおよびビデオが、インターネットのようなパケットベースのネットワーク、セルラーおよびワイヤレスネットワーク、電力線ネットワーク、並びに他のタイプのネットワークを通じて配信されることがより一般的になるにつれて、ストリーミングメディア配信がますます重要になり得る。配信されるストリーミングメディアが提示され得る際の品質は、元のコンテンツの解像度（または他の属性）、元のコンテンツの符号化品質、受信デバイスがメディアを復号し提示する能力、受信機で受信された信号の適時性および品質などを含む、いくつかの要因に依存し得る。知覚される良好なストリーミングメディア体験を作り出すには、受信機で受信される信号の転送および適時性が特に重要であり得る。良好な転送は、送信者が送信したものに対して受信機で受信されるストリームの忠実さを提供できる一方で、適時性は、あるコンテンツに対する最初の要求の後で受信機がどれだけ迅速にそのコンテンツの再生（ｐｌａｙ ｏｕｔ）を開始できるかに相当し得る。

【0006】

メディア配信システムは、メディアソース、メディア送付先、並びにソースおよび送付先を分離する（時間および／または空間で）チャネルを有するシステムとして特徴付けられ得る。通常、ソースは、電子的に管理可能な形式のメディアへのアクセス権を有する送信機と、メディア（またはその類似物）の受信を電子的に制御し、メディアをメディア消費者（例えば、受信機、記憶デバイスまたは素子、別のチャネルなどに何らかの方法で結合されたディスプレイデバイスを有するユーザ）に提供する能力を伴った受信機とを含む。

【0007】

「消費」は、何らかの方法で消費されるメディアを提示などのために使用する送付先での処理である。例えば、モバイルビデオプレーヤは、しばしばビデオの再生レートでビデオデータを「消費する」。通常の速さの再生レートを有するビデオのように、メディアがある再生レートを有する場合、「提示時間」が定義され得る。例えば、メディア提示の開始から２：００．００分の通常の中断されない再生の後に視聴者が達するメディアストリームの点は、２：００．００の提示時間（「ＰＴ」）を有すると呼ばれる。

【0008】

多くの変形が可能であるが、一般的な例では、メディア配信システムは電子的な形式のメディアコンテンツに対するアクセス権を有する１つまたは複数のサーバを有し、１つまたは複数のクライアントシステムまたはデバイスはメディアに対する要求をサーバに対して行い、サーバはサーバの一部として送信機を使用してメディアを伝え、受信されたメディアが何らかの方法でクライアントによって消費され得るようにクライアントの受信機に送信する。単純な例では、１つのサーバと１つのクライアントが所与の要求および応答に対してあるが、必ずしもそうではなくてよい。

【0009】

従来、メディア配信システムは、「ダウンロード」モデルまたは「ストリーミング」モデルのいずれかとして特徴付けられ得る。「ダウンロード」モデルは、メディアデータの配信とユーザまたは受信者デバイスに対するメディアの再生との間のタイミング独立性によって特徴付けられ得る。

【0010】

一例として、ダウンロードモデルすなわちダウンロード構成において、メディアプレーヤまたは他のメディア消費者およびメディアに結合された受信機は、メディアがプレーヤ／消費者により必要とされるとき、あるいは使用されようとするときよりも十分前にダウンロードされる。メディアが使用される（消費される）とき、必要とされるほどの量が受信者において既に利用可能となっていることが好ましい。ダウンロードコンテキスト(download context)での配信は、ＨＴＴＰ、ＦＴＰ、または、Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（「ＦＬＵＴＥ」）のようなファイル転送プロトコルを使用して実行されることが多く、配信レートは、ＴＣＰ／ＩＰのような混雑制御プロトコル(congestion control protocol)および／または背後フロー(underlying flow)によって決定され得る。フローまたは混雑制御プロトコルの動作は、ユーザまたは送付先デバイスに対するメディアの再生とは独立であってよく、この再生は、ダウンロードと同時に、または何らかの他の時点で行われ得る。

【0011】

「ストリーミング」モードは、メディアデータの配信のタイミングと、ユーザまたは受信者デバイスに対するメディアの再生のタイミングとの密接な結合(tight coupling)によって特徴付けられ得る。このコンテキスト(context)での配信は、制御のためのリアルタイムストリーミングプロトコル（「ＲＴＳＰ」）およびメディアデータのためのリアルタイム転送プロトコル（「ＲＴＰ」）のような、ストリーミングプロトコルを使用して実行されることが多い。配信レートはストリーミングサーバにより決めることができ、データの再生レートと一致することが多い。

【0012】

「ダウンロード」モデルのいくつかの欠点は、配信と再生とのタイミング独立性により、メディアデータが再生のために必要な時に利用可能でないことが（例えば、利用可能な帯域幅がメディアデータレートに満たないことにより）あり、再生が一時的に停止し（「ストール(stalling)」）、これにより貧しいユーザ体験をもたらすこと、あるいはメディアデータが再生のはるか前にダウンロードされるように要求されることが（例えば、利用可能な帯域幅がメディアデータレートを超えることにより）あり、乏しいかもしれない受信デバイスの記憶リソースを消費し、コンテンツが最終的に再生されなかったり、他の方法で使用されなかったりすると無駄になってしまう、配信のための貴重なネットワークリソースを消費することであり得る。加えて、多くの場合において最も快いユーザ体験は、ユーザが何を見るかを決めてからほぼ直ぐにビデオを見られることであり、これは、ユーザが何を見るか決めてからビデオを注文し、見ることが可能になるまでに数分、数時間、またはことにより数日待たなければならないモデルとは対照的である。

【0013】

「ダウンロード」モデルの利点は、そのようなダウンロードを行うために必要な技術、例えばＨＴＴＰ、が非常に成熟し、広く展開され、広範囲の用途にわたって適用可能なことであり得る。そのようなファイルのダウンロードの高度なスケーラビリティのためのダウンロードサーバおよび解決法（例えば、ＨＴＴＰウェブサーバおよびコンテンツ配信ネットワーク）は容易に利用可能であって、この技術に基づくサービスの展開を簡単かつ低コストにする。

【0014】

「ストリーミング」モデルのいくつかの欠点は、一般に、メディアデータの配信のレートが、サーバからクライアントへの接続で利用可能な帯域幅に適合せず、帯域幅と遅延とを保証する特別なストリーミングサーバまたはより複雑なネットワークアーキテクチャが必要とされることであり得る。利用可能な帯域幅に従って配信データレートの変動をサポートするストリーミングシステムが存在する（例えば、Ａｄｏｂｅ Ｆｌａｓｈ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ）が、これらは一般に、全ての利用可能な帯域幅を利用することについて、ＴＣＰのようなダウンロード転送フロー制御プロトコルほど効率的ではなく、サーバ／クライアントストリーミングセッションをサポートするために特別なサーバ設備を必要とする。

【0015】

最近では、「ストリーミング」モデルと「ダウンロード」モデルの組合せに基づく新たなメディア配信システムが開発され展開されている。そのようなモデルの例は、本明細書では「適応ＨＴＴＰストリーミング」（本明細書では「ＡＨＳ」と呼ばれる）と呼ばれる。通常、同じマルチメディアコンテンツは、例えば、異なる復号およびレンダリング能力を持つクライアントデバイスを考慮して帯域幅適合をさせるために、様々な異なる方法で符号化され得る。例えば、同じマルチメディアコンテンツ（同じ映画など）が、異なるコーデック、異なるフレームレート、異なるビットレート、あるいは異なる解像度に従って符号化されたり、異なるファイルフォーマットを使用してカプセル化されたりなどできる。特性の各ユニークな組合せがマルチメディアコンテンツの「表示(representation)」を構成する。

【0016】

様々な表示(variety of representations)が、類似の復号およびレンダリング要件(similar decoding and rendering requirements)（例えば、類似のコーデック(similar codecs)、関連の解像度(related resolutions)、類似のファイルフォーマット(similar file formats)など）を有し得るが、同一マルチメディアコンテンツの異なる品質の表示を提供する異なるビットレートをもたらし得る。「適応セット」は１グループの表示であって、そのうちの１表示をクライアントが選択し得るものである。表示の所与の期間に対して、ビデオ適応セットおよびオーディオ適応セットのような複数の適応セットが存在できるが、本明細書の例では、単一の適応セットが一般性を損なわずに検討され得る。

【0017】

表示は、例えば各セグメントがマルチメディアコンテンツのためのある期間、例えば１０秒、１秒、３０秒などに対応する複数のセグメントに分割されてよい。クライアントデバイスは現在利用可能な帯域幅の量を求め、次いで、表示のビットレートおよび現在利用可能な帯域幅に基づいて表示のうちの１つからの１つまたは複数の後続セグメントを要求できる。このようにして、帯域幅の量が増えると、クライアントデバイスは、比較的品質の高い表示からの（１つまたは複数の）セグメントを要求できるが、帯域幅の量が減ると、クライアントデバイスはその量の帯域幅が対応できる比較的品質の低い表示からの（１つまたは複数の）セグメントを要求できる。

【0018】

表示の各セグメントはファイルに格納されてよく、ＵＲＬはそのような各ファイルに関連付けられるので、ＵＲＬは、標準的なＨＴＴＰウェブサーバからのセグメントファイルのＨＴＴＰダウンロードを要求するために、ＡＨＳクライアントによって使用され得る。この手法を使用すると、特定の開始点からメディアコンテンツを再生するためのユーザ要求に応答して、ＡＨＳクライアントは、セグメントをダウンロードするためのＨＴＴＰ要求を発し、要求されたセグメントを再生のために受信できる。理想的には、ユーザによって要求された開始点からのメディアコンテンツの再生は、ユーザ要求後すぐにデバイスにおいて開始でき、メディアコンテンツの再生はその後この開始点からリアルタイムで、すなわち、追加のメディアデータが到着するのを待機する間メディア再生が一時的にストールするストール事象を伴わずに継続できる。いくつかのＡＨＳシステムでは、ＨＴＴＰバイト範囲要求もセグメントの部分を要求するために使用され得る。

【0019】

ＡＨＳの１つの利点は、ＡＨＳが、標準的なＨＴＴＰウェブサーバ、すなわち、他のインターネットコンテンツを配信するために使用されるものと同一の設備を使用して展開できることである。ＡＨＳの別の潜在的利点は、複数の異なるタイプのネットワーク上で複数の異なるデバイスにわたって展開されているＡＨＳクライアントが、再生デバイスの特性、ダウンロードに利用可能な帯域幅などのネットワーク条件、および他の要因に応じて再生を要求するためにどの表示が適しているかを動的に決めることが可能なことである。この最後の利点は特にモバイルデバイスについて重要であり、利用可能なネットワーク帯域幅は短い時間軸で大きく変動することがあるので、ストールを回避しつつ同時に所与のネットワーク条件に対して可能な最高品質の再生を提供するために、ＡＨＳクライアントは、１つの表示の複数のセグメントを要求することから、別の表示の複数のセグメントを要求することへと高速に変更する必要があり得る。さらに、他の特性、例えば、バッテリにおける残り電荷の量、または再生のディスプレイサイズなどが、モバイルデバイス上で高速に変更し得る。

【0020】

表示の切り替えに使用されると考えるのに適切であろうフレーム、例えばＩフレーム、は、ＰまたはＢフレームのような他のタイプのフレームほどのビデオ圧縮を提供し得ない。しかしながら、切り替えがあまり頻繁ではない点で、表示の切り替えを試みるクライアントデバイスは、切り替えが可能になるまで長期間待たなくてはならないことがあり、これは、（例えば、最初に表示のための再生の開始が遅延するとか、表示の切り替えの後における再生イベントの再バッファ／詰まりとかにより）ユーザ体験を悪化させ得る。従って、マルチメディアコンテンツの表示の切り替えのために使用され得るフレームをどの程度頻繁に含めるかに関して、戦略的な決定が通常行われる。

【0021】

１つの一般的なＡＨＳ解決法は、「ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ」と題されたＩＥＴＦ草案において説明され、ドメイン「ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ」を有するＵＲＬおよびそこにある「／ｈｔｍｌ／ｄｒａｆｔ−ｐａｎｔｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｍｉｎｇ−０６」という名称のファイルにおいて見出され得る、Ａｐｐｌｅ Ｉｎｃ．により最初に開発されたＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇプロトコル（以後「ＨＬＳ」と呼ばれる）であり、これはＡｐｐｌｅ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（本明細書では「ＡＬＳ」と省略される）とも呼ばれることもある。別の一般的なＡＨＳ解決法は、例えば、ＩＳＯ／ＩＥＣ２３００９−１：２０１２において規定されるような、ＭＰＥＧ ＤＡＳＨ規格（本明細書では「ＭＰＥＧ ＤＡＳＨ」または「ＭＰＥＧ ＤＡＳＨ規格」と省略される)で説明されている。

【0022】

従って、必要とされるのは、表示の切り替えの間にシームレスなユーザビデオ体験を提供し、表示の切り替えの間のネットワークリソースの効率的な使用も可能にする、改善されたシグナリング方法とそのようなシグナリング方法の使用法である。

【発明の概要】

【0023】

本明細書で説明される切替シグナリング方法は、本明細書で説明される適応ＨＴＴＰストリーミングのための表示(representations for adaptive HTTP streaming)の改善された切り替えを提供し、適応ＨＴＴＰストリーミング解決法(adaptive HTTP streaming solutions)に対するユーザ体験(user experience)と帯域幅の効率(bandwidth efficiency)との改善を可能にする。シグナリング方法は、セグメントマップを表示の各セグメントに関連付けることを含み、セグメントマップは、バイトオフセット情報(byte offset information)および場合によって(potentially)このセグメントについての他の情報と共に、関連するセグメント内の時間的な開始点および時間的な終了点(temporal start and temporal exit points)の両方を備える。セグメントマップは、適応ストリーミング解決法の表現のより高速な切り替えを提供すると同時に、切り替えの間にネットワークを通じてより少量のデータをダウンロードし、ビデオプレーヤによってある表示から別の表示に切り替える時のより円滑なビデオ再生(video playout)を可能にするために、クライアントによって有利に使用され得る。

【0024】

これら実施形態は、表示切替情報をシグナリングすること、並びにこのような情報を使用してより良いユーザ視聴体験およびよりネットワーク効率の良い表示の切り替えとを提供することのために使用される方法に対する新たな改善を含む。新たな切替情報の例は、時間的な開始点、時間的な終了点、および関連するセグメントのセグメントマップ内のこれら点に関連するバイトオフセットを含む。開始点は、表示が切り替えられてこの表示の任意の後続終了点までシームレスに再生し続けることのできる時間的な点を示し、開始点に関連付けられるバイトオフセットはセグメント内のバイトの位置を示し、ダウンロードはその開始点から再生させるであろうデータを受信し始めることができる。同様に、終了点は、再生が終了点以前の表示の任意開始点で開始できて終了点までシームレスに再生させることのできる時間的な点を示し、終了点に関連付けられるバイトオフセットはセグメント内のバイトの位置を示し、ダウンロードはその終了点まで再生させるであろうデータを受信することを終えることができる。セグメント自体が暗号化されている場合でも、表示のシームレスな切り替えおよびネットワークリソースの効率的な使用をさせるために、十分な情報がセグメントマップに与えられる。

【0025】

いくつかの実施形態では、異なる表示がセグメント化され、「ＳＡＰ整列(SAP alignment)」が適応セットの異なる表示の間に存在する。異なる表示は複数の表示にまたがって一致する開始時間および終了時間を有し得る。いくつかの実施形態では、異なる表示がセグメント化され、「重複パッチ整列(overlap patch alignment)」が異なる表示の間に存在する。ここにおいて、開始点である提示開始時間および終了点である提示終了時間とが一致する。整列のタイプと、それが一部の、無しの、または全ての表示、もしくはペアまたはグループの表示に対して存在するかどうかとが１つのプロファイルでシグナリングされ得る。

【0026】

これら実施形態は、既存のコンテンツの符号化処理とフォーマット処理とを変更する必要がないように、既存の展開を改善するために使用され得るので、コンテンツを受信し再生する既存のクライアントは影響を受けない。これら実施形態は、符号化されフォーマットされたコンテンツに関連付けられる、セグメントマップのような強化情報へのアクセス権を、生成し与える。これら実施形態はまた、生成された強化情報にアクセスするために拡張クライアントによって、利用されて上で説明された利益を提供できる方法を提供する。

【0027】

以下の発明を実施するための形態は、添付の図面と共に、本発明の本質および利点のより良い理解をもたらすであろう。

【図面の簡単な説明】

【0028】

【図1】提示時間順序(presentation time order)、フレーム依存構造(frame dependency structure)、およびクローズドＧＯＰ構造(closed GOP structure)を有する符号化されたデータビデオストリームのためのファイルフォーマット順序の例を示す図。

【図2】提示時間順序、フレーム依存構造、およびオープンＧＯＰ構造を有する符号化されたデータビデオストリームのためのファイルフォーマット順序の別の例を示す図。

【図3】提示時間順序、フレーム依存構造、および代替的なオープンＧＯＰ構造を有する符号化されたデータビデオストリームのためのファイルフォーマット順序の別の例を示す図。

【図4】提示時間順序、フレーム依存構造、および代替的なＧＯＰ構造を有する符号化されたデータビデオストリームのためのファイルフォーマット順序の別の例を示す図。

【図5】図１に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示す図。

【図6(a)】図２に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示すもので、ファイルフォーマット順序が復号順序である例を示す図。

【図6(b)】図２に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示すもので、ファイルフォーマット順序が提示順序である例を示す図。

【図7】図３に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示す図。

【図8】図４に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示す図。

【図9】図１に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示す図。

【図10(a)】図２に示されるものと同じ構造を有するフレームを備える、表示のための終了点リストを示すもので、ファイルフォーマット順序が復号順序である例を示す図。

【図10(b)】図２に示されるものと同じ構造を有するフレームを備える、表示のための終了点リストを示すもので、ファイルフォーマット順序が提示順序である例を示す図。

【図11】図３に示されるものと同じ構造を有するフレームを備える、表示のための終了点リストを示す図。

【図12】図４に示されるものと同じ構造を有するフレームを備える、表示のための終了点リストを示す図。

【図13】図４に示されるものと同じフレーム依存構造を有するフレームを備えるが、ファイルフォーマット順序が図４に示される復号順序ではなく提示時間順序である、表示のための開始点リストを示す図。

【図14】図４に示されるものと同じフレーム依存構造を有するフレームを備えるが、ファイルフォーマット順序が図４に示される復号順序ではなく提示時間順序である、表示のための終了点リストを示す図。

【図15】Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）システムにおけるセグメントタイムラインファイルのシグナリングの例を示す図。

【図16】時間ベースとインデックスベースの混合されたセグメントＵＲＬテンプレートの生成の例を示す図。

【図17】セグメントＵＲＬ交差規則の構築の例を示す図。

【図18】本発明の実施形態によるブロック要求ストリーミングシステムの要素を示す図。

【図19】コンテンツ取込システムによって処理されるデータを受信するためのブロックサービング設備（「ＢＳＩ」）に結合されるクライアントシステムの要素をより詳しく示す、図１８のブロック要求ストリーミングシステムを示す図。

【図20】取込システムのハードウェア／ソフトウェアの実装形態を示す図。

【図21】クライアントシステムのハードウェア／ソフトウェアの実装形態を示す図。

【図22】図１８に示されるコンテンツ記憶装置に格納され得る、典型的なソースセグメントの詳細を示す図。

【図23(a)】複数のバージョンのメディアストリームにわたる整列された探索点(seek points)を有する可変ブロックサイジングを示す図。

【図23(b)】複数のバージョンのメディアストリームにわたる整列されていない探索点を有する可変ブロックサイジングを示す図。

【図24】図１８に示されるコンテンツ記憶装置の可能な構造を示し、セグメントおよびｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｏｒ（「ＭＰＤ」）ファイル、並びにＭＰＤファイル内のセグメント、タイミングおよび他の構造の内訳を含む図。

【図25】メタデータテーブルを示す図。

【図26】サーバからクライアントへのブロックおよびメタデータテーブルの送信を示す図。

【図27】複数のセグメントわたる連続的なタイミングと非連続的(discontinuous)なタイミングとを示す図。

【0029】

図面において、同様の項目は同様の番号によって参照され、同様のまたは同一の項目の複数のインスタンスを示すために、括弧内でサブインデックスが与えられる。別段示されない限り、最後のサブインデックス（例えば、「Ｎ」または「Ｍ」）は、任意の特定の値に限定されることは意図されず、ある項目のインスタンスの数は、同じ数が例示されサブインデックスが再使用される場合であっても、別の項目のインスタンスの数と異なっていてよい。

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

【0030】

詳細な説明
本明細書で説明されるように、ストリーミングシステムの目標は、メディアを、メディアの格納位置（あるいは、メディアが生成される位置）から、メディアが消費される位置、すなわち、クライアントによってユーザに対して提示されるか、人もしくは電子的な消費者によって他の方法で「使い果たされる」、位置へ移動させることである。理想的には、ストリーミングシステムは、受信端において中断されない再生（またはより一般的には、中断されない「消費」）を実現でき、クライアントは、ユーザが１つまたは複数のストリームを要求した後すぐにストリームまたはストリームの集合体を再生することを開始できる。効率性の理由のために、例えば、サーバとクライアントとの間の帯域幅の利用可能な量の変動によって、クライアントがあるストリームから別のストリームに切り替えるなどして、ストリームがもはや必要ではないことをユーザが示せば、各ストリームが中止されることも望ましい。ビデオのようなメディアコンテンツはシームレスに再生されるべきであるが、このメディアコンテンツを再生するために異なるストリームがクライアントによって選択される場合、限られた帯域幅を新たなストリームによって占有し、古いストリームを停止するのが好ましいことが多い。

【0031】

本明細書で説明される実施形態による方法は、多くの利益を提供する。一部の適用形態は、本明細書で説明される特徴の全てよりも少ない特徴で、適切に満足のいく体験を提供し得るので、実行可能なシステムは本明細書で説明された特徴の全てを含む必要はないことを理解されたい。

【0032】

所々でソフトウェア、命令、ステップ、処理、または手順などに関して説明されるが、説明される発明は、有形媒体に格納されるソフトウェアとして実装されてよく、かつ／または、本明細書で説明されるもの、もしくは他のもののような、メディアの送信と受信と消費とを支援するための適切なハードウェアを有する、コンピューティングデバイス、送信機、受信機などとして実装されてよいことを理解されたい。

【0033】

適応ＨＴＴＰストリーミング
適応ＨＴＴＰストリーミング（「ＡＨＳ」）は、特定タイプのストリーミングである。ＡＨＳでは、ソースが標準的なウェブサーバおよびコンテンツ配信ネットワーク（「ＣＤＮ」）であってよく、標準的なＨＴＴＰを使用してよい。この技法はストリームのセグメント化および複数のストリームの使用に関与し、全てが標準化されたＨＴＴＰ要求のコンテキスト(context)内にあり得る。ビデオのようなメディアは異なるバージョンまたは表示を形成するために複数のビットレートで符号化され得る。「バージョン(version)」および「表示(representation)」という用語は、本文書で同義に使用される。各バージョンすなわち表示は、場合によって各々数秒のオーダーのより小さな断片(pieces)へ分割され、セグメントを形成し得る。各セグメントは次いで、ファイルに関連付けられるＵＲＬを使用して要求される、別個のファイルとしてウェブサーバまたはＣＤＮ上に格納され得る。表示の提示時間の長さは全てのセグメントに対して同一でなくてよい。

【0034】

クライアント側では、次にクライアントによって一緒にシームレスに継がれる個々のセグメントに対し、ＨＴＴＰを使用して、要求が行われ得る。クライアントは、利用可能な帯域幅に基づいて異なるデータレートに切り替えることができる。クライアントはまた、各々が異なるメディアコンポーネント(media components)を提示する複数の表示を要求でき、これら表示においてメディアを一緒にかつ同期して提示できる。切り替えのためのトリガは、例えば、バッファ占有率およびネットワーク測定結果を含み得る。安定状態で動作している時、クライアントは目標のバッファ占有率を維持するようにサーバに対する要求を調整し得る。

【0035】

ＡＨＳの利点は、ビットレートの適応、高速な始動と探索、および最小の不要配信を含み得る。これら利点は、配信を再生の前の短時間のみに制御することと、利用可能な帯域幅を最大限に使用する（可変ビットレートのメディアを通じて）ことと、ストリームのセグメント化およびインテリジェントなクライアント手順を最適化することとに由来する。

【0036】

これらＡＨＳ解決法は多くの良好な特徴を有するが、改善できることがある。例えば、ＨＬＳ解決法は、ある表示への切替点や複数の表示の切替点をシグナリングできる能力から利益を得るはずである。別の例として、ＭＰＥＧ ＤＡＳＨは、より効率的な切り替えおよびネットワークリソースのより効率的な使用をさせるオープンＧＯＰビデオ符号化が利用される場合に、ある表示への切り替えや複数の表示の切り替えのより詳細なシグナリングから利益を得るはずである。別の例として、ストリームへ容易につながったり、ライブストリーミングセッションに再びつながったりすることをＡＨＳクライアントにさせる自動化された方式でセグメントのＵＲＬを生成するための追加の方法が有益であろう。

【0037】

本明細書で説明されるのは、表示の切り替えの間のシームレスなユーザビデオ体験を提供し、表示の切り替えの間のネットワークリソースの効率的な使用も可能にする、改善されたシグナリング方法とそのようなシグナリング方法の使用法である。

【0038】

ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎがＡＨＳクライアントに提供されて、クライアントがストリーミングサービスをユーザに提供するために複数のファイルの集合体（例えば、本明細書で「３ｇｐセグメント」と呼ばれる３ＧＰＰによって規定されるフォーマットにある）を使用できるようにし得る。ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ、並びに場合によってこのｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎの更新は、クライアントが包含メディアを同期方式で提示でき、かつ探索、ビットレートの切り替え、および異なる表示におけるメディアコンポーネント(media components)を一緒に提示することのような高度な機能も提供できるように各々複数のメディアコンポーネントを含む複数のセグメントの構造化された集合体であるメディア提示を記述する。クライアントは、サービスの準備のために異なる方法でｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ情報を使用し得る。具体的には、ＡＨＳクライアントは、データがクライアント能力およびストリーミングサービス内のユーザに対して有用となるように集合体におけるどのセグメントにアクセスできるかをｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎから判定できる。

【0039】

いくつかの実施形態では、ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎは静的であり得るが、セグメントは動的に生成され得る。ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎは、サービスのアクセス時間およびダウンロード時間を最小にできるほどコンパクトであり得る。他の専用サーバ接続、例えば、クライアントとサーバとの間の定期的なまたは頻繁なタイミングの同期が最小になり得る。

【0040】

メディア提示は、異なるタイプのアクセスネットワークへのアクセス権、異なる現在のネットワーク条件、ディスプレイサイズ、アクセスビットレート、およびコーデックのサポートのような、異なる能力を有する端末によるアクセスを許容するように構築され得る。クライアントは次いで、適切な情報を抽出して、ストリーミングサービスをユーザに提供できる。

【0041】

ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎはまた、要件に従って展開の柔軟性と小型化を許容し得る。

【0042】

最も単純な場合には、代替的な各表示が、単一の３ＧＰファイル、すなわち３ＧＰＰ ＴＳ２６．２４４において定義されるものに準拠するファイル、または、ＩＳＯ／ＩＥＣ１４４９６−１２または派生した規格において定義されるようなＩＳＯベースのメディアファイルフォーマット（３ＧＰＰ Ｔｅｃｈｎｉｃａｌ Ｓｐｅｃｉｆｉｃａｔｉｏｎ２６．２４４において説明される３ＧＰファイルフォーマットなど）に準拠する任意の他のファイルに格納され得る。本文書の残りでは、３ＧＰファイルに言及する場合、ＩＳＯ／ＩＥＣ１４４９６−１２および派生した規格が、ＩＳＯ／ＩＥＣ１４４９６−１２または任意の派生した規格において定義されるような、より一般的なＩＳＯベースのメディアファイルフォーマットに対して、全ての説明された機能を割り当てることができることを理解されたい。クライアントは次いで、ファイルの最初の部分を要求して、動画フラグメントの時間およびバイトオフセットと共に、メディアメタデータ（「ｍｏｏｖ」ボックスとも呼ばれるＭｏｖｉｅヘッダボックスに通常格納される）を知ることができる。クライアントは次いで、ＨＴＴＰ ｐａｒｔｉａｌ ｇｅｔ要求を発して、要求に応じて動画フラグメントを取得できる。

【0043】

いくつかの実施形態では、各表示をいくつかのセグメントに分割するのが望ましいことがある。セグメントフォーマットが３ＧＰファイルフォーマットに基づく場合、セグメントは、「時間的分割(time-wise splitting)」と呼ばれる、動画フラグメントの重複しない時間スライスを含む。これらセグメントの各々は複数の動画フラグメントを含んでよく、各々がそれ自体で有効な３ＧＰファイルであり得る。別の実施形態では、表示がメタデータ（通常はＭｏｖｉｅヘッダ「ｍｏｏｖ」ボックス）を含む初期セグメントとメディアセグメントのセットとに分割され、表示の各々は、メディアデータと初期セグメントの連結物とを含み、任意のメディアセグメントは有効な３ＧＰファイルを形成し、さらに、初期セグメントの連結物およびある表示の全てのメディアセグメントは有効な３ＧＰファイルを形成する。全体の提示は、各セグメントを再生し、次いで、各表示の開始時間に従ってファイル内のローカルのタイムスタンプをグローバルな提示時間にマッピングすることによって、形成され得る。

【0044】

この説明全体で、「セグメント(segment)」への言及は、記憶媒体から完全にまたは部分的に構築されもしくは読み取られる、または、例えばＨＴＴＰ要求を含むファイルダウンロードプロトコル要求の結果として他の方法で取得される任意のデータオブジェクトを含むものと理解されるべきであることに留意されたい。例えば、ＨＴＴＰの場合、データオブジェクトは、ディスク上、またはＨＴＴＰサーバに接続されもしくはＨＴＴＰサーバの一部を形成する他の記憶媒体上に存在する実際のファイルに格納されてよく、またはデータオブジェクトは、ＨＴＴＰ要求に応答して実行されるＣＧＩスクリプトや他の動的に実行されるプログラムによって構築されてよい。「ファイル(file)」および「セグメント(segment)」という用語は、別段規定されない限り、本文書では同義に使用される。ＨＴＴＰの場合、セグメントは、ＨＴＴＰ要求応答の本体であると考えられ得る。

【0045】

「提示(presentation)」および「コンテンツ項目(content item)」という用語は、本文書では同義に使用される。多くの例で、提示は、定められた「再生(playout)」時間を有する、オーディオ、ビデオ、または他のメディア提示であるが、他の変形も可能である。

【0046】

「ブロック(block)」および「フラグメント(fragment)」という用語は、別段規定されない限り、本文書では同義に使用され、全般に、インデックスを付されたデータの最小の集合体(aggregation)を指す。利用可能なインデックス付けに基づいて、クライアントは、異なるＨＴＴＰ要求において、フラグメントの異なる部分を要求でき、または、１つのＨＴＴＰ要求において、１つまたは複数の連続するフラグメントまたはフラグメントの部分を要求できる。ＩＳＯベースのメディアファイルフォーマットに基づくセグメントまたは３ＧＰファイルフォーマットに基づくセグメントが使用される場合、フラグメントは通常、動画フラグメントヘッダ（「ｍｏｏｆ」）ボックスとメディアデータ（「ｍｄａｔ」）ボックスの組合せとして定義される動画フラグメントを指す。

【0047】

本明細書では、データを搬送するネットワークは、本明細書の説明を簡単にするためにパケットベースであることが仮定され、本開示を読めば、当業者が明細書で説明される本発明の実施形態を連続的なビットストリームネットワークのような他のタイプの送信ネットワークに適用できることが認識される。

【0048】

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

【0049】

シーケンスにおけるキーフレーム
ビデオコーディングでは、ビデオデータのいくつかのフレーム（「Ｉフレーム」として知られているイントラ予測モード符号化されたフレームなど）がビデオデータの他のフレームを参照することなく独立にコーディングされる。フレーム間の時間的な冗長性を利用するために、他のフレーム（すなわち、ＰおよびＢフレームのようなインター予測モード符号化されたフレーム）は、以前のまたは後続のコーディングされたフレーム（参照フレームと呼ばれる）に対してコーディングされる。ＡＨＳの潜在的な障害の１つは、フレーム（または一般的には、他のデータ）が以前のフレームまたは後続のフレームに対してコーディングされる時にどのようにある表示から別の表示へシームレスに切り替えるかである。潜在的な障害とは、コンテンツの異なる表示が異なる表示において同時に提示されるべきフレームに対する異なるフレーム依存フレーム構造を使用して符号化されるビデオであり得ることである。依存フレーム構造が異なる表示にまたがって同じである場合でも、表示は異なる解像度を使用することがあり、品質が異なるので、ある表示におけるフレームを使用して他の表示のフレームを復号することは、一般に、ビデオのシームレスな再生にはつながらず、すなわち、劣悪なユーザ視聴体験をもたらし得る。従って、ＡＨＳに関する課題は、表示をどのようにシームレスに切り替えるかである。

【0050】

キーフレームは、クライアントデバイスが、表示のより以前のデータにアクセスすることなく表示の復号を開始できるようになる時点の表示のフレームであり、すなわち、キーフレームは、Ｉフレームより後のフレームがＩフレームより前のいずれのフレームにも依存しないような、Ｉフレームである。その上、キーフレームは、表示のための表示アクセス点、すなわち、ビデオのダウンロードおよび再生が開始し得る場所として機能し得る。さらに、そのようなキーフレームは、第１の表示から第２の表示に切り替える時に有用であることがあり、それは、第２の表示におけるキーフレームは、第２の表示における再生の開始点であり得るからである。例えば、クライアントデバイスは、第２の表示におけるキーフレームの時間的な位置により決まる第１の表示におけるデータを取り出し、次いで、第２の表示のキーフレームにおいて開始するデータを取り出すことによって、第１の表示から第２の表示に切り替えることができる。いくつかの限られた場合には、この戦略が表示の切り替えにおいてシームレスなユーザ体験を提供できるが、他の状況(situations)では、この単純な戦略が表示の切り替えにおいてシームレスなユーザ体験を提供することに失敗することがあり、それは、例えば、第２の表示におけるキーフレームよりも時間的に前にある第１の表示におけるフレームが、第２の表示のキーフレームよりも時間的に後にある第１の表示における他のフレームに依存するからである。

【0051】

さらに、デジタル著作権管理（ＤＲＭ）システムおよび／または暗号化の使用により、フレーム依存構造が、表示の切り替えおよびダウンロードの決定を行う受信クライアントの一部において利用可能ではなくなることが多い。

【0052】

データ依存構造
ＭＰＥＧ１、ＭＰＥＧ２、またはＨ．２６４ＡＶＣ符号化ビデオのような、一般のビデオ符号化技術では、単一の表示を有するフレームの提示時間順序は、フレームの復号順序とは異なり得る。提示時間順序は、フレームが他のフレームに対して表示される、連続的な順序である。

【0053】

提示時間順序は、各フレームに関連付けられる提示時間によってより正確に決定され、２つのフレームの提示時間の差は、２つのフレームが表示されるべき時間の差である。本開示では、提示時間はより広く解釈されるべきである。例えば、コンテンツのある点における提示時間は、コンテンツの始まりの意図される再生開始時間である０から、上記の点までの時間として測定されてよく、例えば、上記の点がコンテンツの開始の２０秒後に再生されることが意図される場合、その点に関連付けられる提示時間は２０秒である。あるいは、当業者が認識するように、提示時間は、実時間またはＵＴＣ時間または他の等価な時間尺度に関して測定され得る。

【0054】

復号順序は、フレームが様々なフレーム間の相互依存性を考慮して復号され得るフレームの順序である。各フレームに対して、そのフレームに依存する全てのフレームがそのフレームに対して順序的に後にある場合、フレームの順序は復号順序であると言われる。これは、復号されるべき次のフレームを既に復号されたフレームに基づいて復号させる。ストリーミング配信システムでは、フレームが簡単に復号され得るように順序通りにフレームが到達するのを確実にするために、フレームの送信順序は復号順序であることが普通である。以下の説明では、ファイルフォーマット順序がクライアントに配信されるべき表示のファイルまたはセグメント内のフレームの順序であると定義されるので、複数のファイルまたはファイルの複数の部分がクライアントによって要求される場合、ファイルフォーマット順序は、表示の部分がクライアントに配信される順序であることが多い。ＡＨＳシステムにおいて、表示内におけるフレームの順序、すなわちファイルフォーマット順序は復号順序であることが普通である。

【0055】

図１は、提示時間順序、フレーム依存構造、および符号化されたデータビデオストリームのためのファイルフォーマット順序の例を示す。提示時間順序フレーム番号は、フレームに一意に番号を付けるために使用され、以後「提示時間順序フレーム番号(presentation time order frame number)」は「フレーム番号」と省略される。例えば、提示時間における最初のフレームは、以後フレーム１と呼ばれる。各フレームは、タイプ「Ｉ」（イントラコード (Intra-code)）、「Ｐ」（予測 (Predictive)）または「Ｂ」（双予測(Bi-predictive)）と標識される。図１のフレーム依存構造は、フレーム間の弓状の線によって示される。２つのフレーム間の弓状の点線は、提示時間順序における後のフレームが前のフレームに依存することを示し、２つのフレーム間の弓状の実線は、提示時間順序における前のフレームが後のフレームに依存することを示す。「復号順序(decode order)」は、各フレームが、それに依存するあらゆるフレームより前にあるような順序である。

【0056】

図１に示される例では、フレーム１はＩフレームなので、フレーム１は、フレーム１に対して受信されたデータに基づいて復号可能である。フレーム２は、フレーム２に対して受信されたデータと共に（フレーム２はＢフレームである）フレーム１および５に対して受信されたデータに基づいて、復号可能である。同様に、フレーム３はフレーム１、３、５を使用し、フレーム４はフレーム１、４、５を使用し、フレーム５はフレーム１、５を使用し、フレーム６はフレーム５、６を使用し、フレーム７はフレーム５、７を使用し、フレーム８はフレーム５、８を使用するので、フレーム１〜８は、フレーム１〜８のコンテンツが受信されると復号され得る。しかしながら、フレーム２はフレーム５がないと完全に復号できないので、フレームが「復号順序」で受信される場合、フレーム２は、５個のフレームの受信を待機しなければならないのではなく、わずか３個のフレーム（１，２，５）を受信した後で復号され得る。

【0057】

図１に示される例では、フレームのフォーマット順序は、示される復号順序と同じである。ピクチャのグループ（または「ＧＯＰ」）は、Ｉフレームにおいて開始し、シーケンスにおける次のＩフレームの１つ前のフレームまでの、連続的なフレームのセットとして定義され得る。図１では、フレーム１〜８は１つのＧＯＰを備え、フレーム９〜１６は第２のＧＯＰを備え、フレーム１７は第３のＧＯＰの始まりである。図１に示されるＧＯＰ構造は、ＧＯＰを備えるフレームの各々が他のＧＯＰのフレームに依存しないので、「クローズドＧＯＰ構造(closed-GOP structure)」と呼ばれることがある。

【0058】

図２は、提示時間順序、フレーム依存構造、および符号化されたデータビデオストリームのファイルフォーマット順序の別の例を示し、図１で説明されたものと同じ用語の用例に従う。この場合、提示時間順序において、ＧＯＰの最後のＰフレームと次のＧＯＰのＩフレームとの間のＢフレームは、次のＧＯＰのＩフレームに全て依存し得るので、ＧＯＰを備えるフレームの一部は他のＧＯＰのフレームに依存し得る。図２に示されるＧＯＰ構造は、「オープンＧＯＰ構造(open-GOP structure)」と呼ばれることがある。

【0059】

図３は、提示時間順序、フレーム依存構造、および符号化されたデータビデオストリームのファイルフォーマット順序の別の例を示し、図１で説明されたものと同じ用語の用例に従う。この場合、フレーム間にはより複雑な依存構造があり、すなわち、Ｂフレーム６、７、８はそれぞれ、提示時間順序で次のＧＯＰの始まりにおけるＩフレーム９の後にあるＰフレーム１３に依存する。

【0060】

図４は、提示時間順序、フレーム依存構造、および符号化されたデータビデオストリームのファイルフォーマット順序の別の例を示し、図１で説明されたものと同じ用語の用例に従う。この場合、Ｂフレーム１４、１５、１６はそれぞれ、次のＧＯＰの始まりにおけるＩフレーム１７に依存するが、提示時間順序でそれらの前にあるいずれのフレームにも依存しない。

【0061】

開始点および終了点
一般にストリーミングコンテンツに関して、コンテンツの表示のフレーム依存構造と、メディアコンテンツの表示を切り替えるために使用される方法、特に表示の切り替えができる時点をどのようにシグナリングするかとの間には関係がある。以下で説明されるような、開始点情報および終了点情報と一般に呼ばれる簡潔なフォーマットで生成されクライアントに伝えられ得る。コンテンツの１つの表示しかない場合、すなわち、別の表示への切り替えがサポートされない場合であっても、開始点情報および終了点情報は、他の目的でも、例えば、表示のどの部分を単一の要求でダウンロードすべきかを判定するために、使用され得る。

【0062】

この議論では、フレームの提示時間は、コンテンツの他のフレームの表示開始時間に対する、フレームが表示を開始するようにされている時間であり、すなわち、フレームの提示開始時間であり、各フレームは、提示時間順序において次の連続するフレームのちょうど提示開始時間において表示を終了するようにされており、すなわち、フレームの提示終了時間は、提示時間順序において次のフレームの提示開始時間、または単に提示時間である。

【0063】

以下の開始点および終了点の定義では、バイトオフセットは常に、フレームの始まりに対するバイトオフセットであると仮定され、提示時間は常に、フレームの提示開始時間（前のフレームの提示終了時間に等しい）であると仮定されるが、当業者が認識するようにこれら制約は緩められてよい。例えば、他の代替的な定義および説明では、データストリームにおける任意の点に対するバイトオフセット、例えば、ビデオのフレームを備えるデータの中心に対するバイトオフセットが考えられてよく、任意の有効な提示時間、例えば、フレームの提示開始時間と提示終了時間の中間にある提示時間が考えられてよい。

【0064】

本明細書で使用される場合、開始点は、例えば、「（提示開始時間(entry presentation time)，開始バイトオフセット(entry byte offset)）」またはより簡潔に「（ＰＴ，ＢＯ）」の形式で開始の時間およびバイトオフセットの指示(indication)を使用して表されまたは示され得る。表示の開始点（ＰＴ，ＢＯ）は、表示のダウンロードがバイトオフセットＢＯから開始され終わりに進むように続く場合に、表示におけるコンテンツのビデオフレームが提示時間ＰＴで開始して終わりに至る提示時間順序でシームレスに再生され得る、点である。従って、本明細書での説明では、開始点は２次元の点を規定し、一方の次元はファイルフォーマット順序に対応し、他方の次元は提示時間順序に対応する。本明細書において以下でより詳しく説明されるように、表示のためのそのような点のシグナリングは、表示の開始点として使用されてよく、すなわち、表示のダウンロードと再生をどこで開始するかを判定するために使用されてよい。

【0065】

開始点（ＰＴ，ＢＯ）の定義によって、少なくともＰＴの提示開始時間を有する全てのフレームと、これらフレームが直接的または間接的のいずれかに依存する全てのフレームとが、表示内の少なくともＢＯであるバイトオフセットで開始することに留意されたい。

【0066】

表示内の可能な各バイトオフセットＢＯに対して、（ＰＴ，ＢＯ）が開始点となり、全てのそのような可能な開始点のうちで提示時間ＰＴが最小の提示時間となるようなユニークなＰＴが存在し、関数ＴｅｎｔｒｙＢ（）は、ＴｅｎｔｒｙＢ（ＢＯ）＝ＰＴとなるように定義される。全ての可能なバイトオフセットＢＯに対するそのような開始点のリストは、「バイトオフセット開始点リスト(byte offset entry point list)」と本明細書では呼ばれる。

【0067】

ファイルフォーマットが２つ以上のメディア、例えばオーディオデータおよびビデオデータの組合せ(mixture)を含む場合、開始点は、異なるメディアを考慮しなければならないことがあることに留意されたい。例えば、バイトオフセットＢＯに関連付けられる提示時間ＰＴはＰＴ１とＰＴ２の大きい方として定義されてよく、ＰＴ１は第１のメディアのバイトオフセットＢＯについて達成され得る最小の提示時間であり、ＰＴ２は第２のメディアについて達成され得る最小の提示時間である。同様のコメントが、開始点および終了点に関連して以後説明される、全てのさらなる定義および方法に対して有効である。

【0068】

同様に、可能な各提示時間ＰＴに対して、（ＰＴ，ＢＯ）が開始点となり、バイトオフセットＢＯが全てのそのような開始点のうちで最大のバイトオフセットとなるようなユニークなＢＯが存在し、ＢｅｎｔｒｙＴ（ＰＴ）＝ＢＯと定義する。全ての可能な提示時間(possible presentation times)ＰＴに対するそのような開始点のリストが本明細書で「提示時間開始点リスト(presentation time entry point list)」と呼ばれる。

【0069】

異なるバイトオフセットを有するが同じ提示時間を有するバイトオフセット開始点リスト内に複数の開始点があり、異なる提示時間を有するが同じバイトオフセットを有する提示時間開始点リスト内に複数の開始点があることがあり得る。さらに、バイトオフセット開始点リスト内の開始点（ＰＴ，ＢＯ）が、ＰＴ’＝ＰＴかつＢＯ’＞ＢＯである他の開始点（ＰＴ’，ＢＯ’）がバイトオフセット開始点リスト内にないようなものである場合、開始点（ＰＴ，ＢＯ）は、提示時間開始点リスト内にもあり、ＢＯ’＝ＢＯかつＰＴ’＜ＰＴである他の開始点（ＰＴ’，ＢＯ’）が提示時間開始点リスト内にないという性質を有する。同様に、提示時間開始点リスト内の開始点（ＰＴ，ＢＯ）が、ＢＯ’＝ＢＯかつＰＴ’＜ＰＴである他の開始点（ＰＴ’，ＢＯ’）が提示時間開始点リスト内にないようなものである場合、開始点（ＰＴ，ＢＯ）は、バイトオフセット開始点リスト内にもあり、ＰＴ’＝ＰＴかつＢＯ’＞ＢＯである他の開始点（ＰＴ’，ＢＯ’）がバイトオフセット開始点リスト内にないという性質を有する。

【0070】

バイトオフセット開始点リストと提示時間開始点リストの両方にある開始点を「主開始点(major entry point)」と分類し、これら開始点リストのうちの１つにしかない残りの開始点(entry point)を「副開始点(minor entry points)」と分類する。（ＰＴ，ＢＯ）が主開始点である場合、（ＰＴ，ＢＯ）＝（ＴｅｎｔｒｙＢ（ＢＯ），ＢｅｎｔｒｙＴ（ＰＴ））であることに留意されたい。各副開始点（ＰＴ，ＢＯ）に対して、ＢＯ’＞ＢＯである主開始点（ＰＴ，ＢＯ’）またはＰＴ＞ＰＴ’である主開始点（ＰＴ’，ＢＯ）のいずれかが存在し、前者の場合、同じ提示時間で開始する同じコンテンツの再生が、主開始点を有するより後のバイトオフセットで開始され得るので、主開始点は副開始点より優れており、後者の場合、より多くのコンテンツの再生が主開始点を有する同じバイトオフセットで開始され得るので、主開始点は副開始点より優れている。

【0071】

これら定義は、表示内におけるフレームの順序に関係なく、すなわち、ファイルフォーマット順序が表示内におけるフレームの提示時間順序、復号順序、あるいは何か他の順序かどうかにかかわらず有効であることに留意されたい。

【0072】

同様に、形式「（提示終了時間(exit presentation time)、終了バイトフセット(exit byte offset)）」の終了点(exit point)を定義する、ここで表示の終了点（ＰＴ，ＢＯ）の意味は、表示が始まりからバイトオフセットＢＯまでダウンロードされれば、表示におけるコンテンツのビデオフレームが、始まりから開始して提示時間ＰＴまで表示時間順序でシームレスに再生され得ることである。従って、本明細書での説明では、終了点は２次元の点を規定し、一方の次元はファイルフォーマット順序に対応し、他方の次元は提示時間順序に対応する。本明細書において以下でより詳しく説明するように、表示のためのそのような点のシグナリングは、表示からの終了点として使用されてよく、すなわち、表示のダウンロードと再生をどこで終了するかを判定するために使用されてよい。

【0073】

終了点（ＰＴ，ＢＯ）の定義によって、大きくともＰＴの提示終了時間を有する全てのフレームと、これらフレームが直接的または間接的のいずれかに依存する全てのフレームとは、表示内の大きくともＢＯであるバイトオフセットで終了することに留意されたい。

【0074】

表示内の可能な各バイトオフセットＢＯに対して、（ＰＴ，ＢＯ）が終了点となり、全てのそのような可能な終了点のうちで提示時間ＰＴが最大の提示時間となるようなユニークなＰＴが存在し、ＴｅｘｉｔＢ（ＢＯ）＝ＰＴと定義する。全ての可能なバイトオフセットＢＯに対するそのような終了点のリストを「バイトオフセット終了点リスト(presentation time exit point list)」として定義する。

【0075】

同様に、可能な各提示時間ＰＴに対して、（ＰＴ，ＢＯ）が終了点となり、バイトオフセットＢＯが全てのそのような終了点のうちで最小のバイトオフセットとなるようなユニークなＢＯが存在し、ＢｅｘｉｔＴ（ＰＴ）＝ＢＯと定義する。全ての可能な提示時間ＰＴに対するそのような終了点のリストを「提示時間終了点リスト(presentation time exit point list)」として定義する。

【0076】

異なるバイトオフセットを有するが同じ提示時間を有するバイトオフセット終了点リストに複数の終了点があり、異なる提示時間を有するが同じバイトオフセットを有する提示時間終了点リストに複数の終了点があることがあり得る。さらに、バイトオフセット終了点リスト内の終了点（ＰＴ，ＢＯ）が、ＰＴ’＝ＰＴかつＢＯ’＜ＢＯである他の終了点（ＰＴ’，ＢＯ’）がバイトオフセット終了点リスト内にないようなものである場合、終了点（ＰＴ，ＢＯ）は、提示時間終了点リスト内にもあり、ＢＯ’＝ＢＯかつＰＴ’＞ＰＴである他の終了点（ＰＴ’，ＢＯ’）が提示時間終了点リスト内にないという性質を有する。同様に、提示時間終了点リスト内の終了点（ＰＴ，ＢＯ）が、ＢＯ’＝ＢＯかつＰＴ’＞ＰＴである他の終了点（ＰＴ’，ＢＯ’）が提示時間終了点リスト内にないようなものである場合、終了点（ＰＴ，ＢＯ）は、バイトオフセット終了点リスト内にもあり、ＰＴ’＝ＰＴかつＢＯ’＜ＢＯである他の終了点（ＰＴ’，ＢＯ’）がバイトオフセット終了点リスト内にないという性質を有する。

【0077】

バイトオフセット終了点リストと提示時間終了点リストの両方にある終了点を「主終了点(major exit point)」と分類し、これら終了点リストのうちの１つにしかない残りの終了点を「副終了点(minor exit points)」と分類する。（ＰＴ，ＢＯ）が主終了点である場合、（ＰＴ，ＢＯ）＝（ＴｅｘｉｔＢ（ＢＯ），ＢｅｘｉｔＴ（ＰＴ））であることに留意されたい。各副終了点（ＰＴ，ＢＯ）に対して、ＢＯ’＜ＢＯである主終了点（ＰＴ，ＢＯ’）またはＰＴ＜ＰＴ’である主終了点（ＰＴ’，ＢＯ）のいずれかが存在し、前者の場合、同じ提示時間で終了する同じコンテンツの再生が、主終了点を有するより早いバイトオフセットで終了し得るので、主終了点は副終了点より優れており、後者の場合、より多くのコンテンツの再生が主終了点を有する同じバイトオフセットで終了し得るので、主終了点は副終了点より優れている。

【0078】

これら定義は、表示内におけるフレームの順序とは関係なく、すなわち、ファイルフォーマット順序が表示内におけるフレームの提示時間順序、復号順序、あるいは何か他の順序かどうかにかかわらず有効であることに留意されたい。

【0079】

図５は、図１に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示す。図５に示される第１の表は、フレーム番号に従ってファイルフォーマット順序でリストされたフレームを、各フレームの始まりに対するバイトオフセットと共に示す。図５に示される第２の表は、提示時間開始点リストを示す。図５に示される第３の表は、バイトオフセット開始点リストを示す。図５に示される第４の表は、主開始点のリストである。これら最後の３つの表では、開始提示時間は再生され得る最初のフレームのフレーム番号であり、以後「開始フレーム(entry frame)」と呼ばれる。図５では、主開始点が、（１，０）、（９，２７５３７）、および（１７，５４５２３）である。全ての主開始点に対し、ファイルフォーマット順序で開始フレームの後にある全てのフレームが再生されることになり、これはクローズドＧＯＰ構造の結果であることに留意されたい。フレーム番号を使用して提示時間を示すことは、提示時間を表すための唯一の方法であり、一般に再生されるべきメディアまたはデータをフレームのような別々の時間ステップにおいて表すことのできないフォーマットを含む、他の多くの提示時間フォーマットが存在することに留意されたい。

【0080】

図６、図７、および図８は、図２、図３、および図４にそれぞれ示される構造と同じ構造を有するフレームを備える、表示の開始点リストをそれぞれ示す。図６（ａ）、図６（ｂ）、図７、および図８の各々に示される５つの表は、図５について上で説明されたものと同じフォーマットと意味とを有するが、図６（ａ）はファイルフォーマットの復号順序を使用し、一方図６（ｂ）は提示順序をファイルフォーマット順序として使用する。

【0081】

図６（ａ）では、主開始点が、（１，０）、（９，２２０３３）、および（１７，４１９９３）である。主開始点（９，２２０３３）に対しては、ファイルフォーマット順序で開始フレーム９の後にある全てのフレーム、例えば、フレーム６、７、および８が再生されるとは限らないことに留意されたい。これは、オープンＧＯＰ構造の結果である。

【0082】

図７では、主開始点が、（１，０）、（９，２２０３１）、および（１７，４８３０３）である。主開始点（９，２２０３１）に対しては、ファイルフォーマット順序における最初のダウンロードされるフレームはフレーム９ではなくフレーム１３であるので、ダウンロードされる最初のフレームは、この主開始点に対して再生される最初のフレームではないことに留意されたい。さらに、ファイルフォーマット順序でフレーム１３の後にあるフレーム６、７、および８は、この主開始点からダウンロードされるべきであるが、再生されるべきではない。これは、この代替的なオープンＧＯＰ構造の結果である。

【0083】

図８では、主開始点は、（１，０）、（９，２７５３７）、および（１４，４８３０３）である。主開始点（１４，４８３０３）に対しては、ファイルフォーマット順序における最初のダウンロードされるフレームはフレーム１４ではなくフレーム１７であるので、ダウンロードされる最初のフレームは、この主開始点に対して再生される最初のフレームではないことに留意されたい。これは、この代替的なＧＯＰ構造の結果である。

【0084】

図９、図１０、図１１、および図１２は、図１、図２、図３、および図４にそれぞれ示される構造と同じ構造を有するフレームを備える、表示の終了点リストをそれぞれ示す。図９、図１０（ａ）、図１０（ｂ）、図１１、および図１２の各々に示される５つの表は、図５について上で説明されたものと同様のフォーマットと意味とを有する。違いは、終了点が開始点の代わりに示され、提示終了時間が再生され得る最後のフレームのフレーム番号であることにあり、以後「終了フレーム(exit frame)」と呼ばれる。図１０（ａ）はファイルフォーマットの復号順序を使用し、図１０（ｂ）はファイルフォーマット順序として提示順序を使用する。

【0085】

別の例として、図１３は、図４に示されるものと同じ依存フレーム構造を有するフレームを備えるが、ファイルフォーマット順序が図４に示される復号順序でなく提示時間順序である、表示のための開始点リストを示し、図１４は、対応する終了点リストを示す。

【0086】

表示の各主開始点および主終了点をシグナリングすることが適切である場合があるが、一方で他の場合には、この量のシグナリングは、大量のシグナリングオーバーヘッドを示し得るので、選択された主開始点および主終了点のみがシグナリングされる。他の場合には、副開始点と副終了点の一部をシグナリングすることも適切である。

【0087】

開始点と終了点とを生成するための方法
実装において、開始点生成器と終了点生成器の実装形態は、入力のメディア符号化フォーマットに依存し得る。例えば、入力はＭＰＥＧ２ＴＳフォーマットへとカプセル化されるＭＰＥＧ２符号化コンテンツであってよく、入力はＭＰＥＧ２ＴＳフォーマットへとカプセル化されるＨ．２６４ＡＶＣコンテンツであってよく、または入力はＩＳＯファイルフォーマットへとカプセル化されるＨ．２６４ＡＶＣコンテンツであってよい。他のより詳細な例として、Ｈ．２６４ＡＶＣコンテンツは「クローズドＧＯＰ」を使用して符号化されてよく、または「オープンＧＯＰ」を使用して符号化されてよく、または非常に汎用的なビデオフレーム間の依存構造にせさるように符号化されてよい。他の例として、Ｂフレームが除外されたり、Ｂフレームが許容されたりしてよい。

【0088】

好ましくは、異なる開始点生成器および終了点生成器の実装形態の出力フォーマットは、それぞれ、方法に対する特定のメディア符号化フォーマットの入力とは独立の、同じ開始点フォーマットおよび終了点フォーマットである。これは、元のコンテンツのメディア符号化フォーマットとは独立にセグメントマップを生成するためにセグメントマップ生成器が使用され得るので有利であり、すなわち、同じセグメントマップ生成器は、元のメディア符号化フォーマットがＩＳＯファイルフォーマットで搬送される「オープンＧＯＰ」を伴うＨ．２６４ＡＶＣかどうかにかかわらず、または、メディア符号化フォーマットがＭＰＥＧ ＴＳフォーマットで搬送される「クローズドＧＯＰ」を伴うがＢフレームを伴わないＭＰＥＧ２ＴＳであるかどうかにかかわらず使用され得る。

【0089】

好ましくは、開始点生成器および終了点生成器の出力は開始点と終了点の十分に濃密なセットをそれぞれ含み、セグメントマップ生成器がクライアントによって使用され得るセグメントマップを生成するために選択対象である十分な開始点と終了点とを有し、エンドユーザに素晴らしいストリーミング体験を提供するようにすべきである。これは、開始点生成器および終了点生成器がＡＨＳストリーミング方法の仕様を考慮する必要がなく、代わりにＡＨＳストリーミング論理の仕様がセグメントマップ生成器によって考慮され得るので、好ましい。

【0090】

任意のフレームＦに対して、フレームＦが依存する全てのフレームがファイルフォーマット順序でフレームＦよりも前にある場合、表示内におけるフレームのファイルフォーマット順序が復号順序にあると言われる。

【0091】

以下で説明される開始点および終了点を生成する実施形態および方法では、バイトオフセットは常に、フレームの始まりに対するバイトオフセットであると仮定され、提示時間は常に、フレームの提示開始時間（以前のフレームの提示終了時間に等しい）であると仮定されるが、当業者が認識するようにこれら制約は緩められてよい。

【0092】

ファイルフォーマット順序が復号順序である場合における終了点生成方法の第１の実施形態は次の通りである。ファイルフォーマット順序における各フレームの提示時間と各フレームに対するバイトオフセットとを決定する。各提示時間ＰＴに対して、ＰＴよりも厳密に短い提示時間を有する全てのフレームよりもファイルフォーマット順序で後にある全てのフレームのうちで最小のバイトオフセットを有する、フレームに対するバイトオフセットＢＯを決定する。決定された終了点は（ＰＴ，ＢＯ）である。（ファイルフォーマット順序においてそのようなフレームがない場合、ＢＯは、表示の終わりに対するバイトオフセットである。）ＢＯ＝ＢｅｘｉｔＴ（ＰＴ）であることに留意されたい。この実施形態では、終了点生成方法は、背後にあるフレーム依存構造を分析して、終了点のリストを生成する必要がないことに留意されたい。これは、ファイルフォーマット順序が復号順序であるという特性が、ファイルフォーマット順序およびフレームの提示時間に基づいて終了点を効率的に決定するのに、十分なフレーム依存構造を表すからである。

【0093】

第１の実施形態によって生成されたリスト内の複数の連続する終了点が同じ終了バイトオフセットＢＯを有する場合、提示時間順序における最後の終了点、すなわち、同じ終了バイトオフセットＢＯを有するこれら連続する終了点のうちで最大の提示時間ＰＴを有する終了点が主終了点であり、残りが副終了点である。

【0094】

表示のファイルフォーマット順序が復号順序である場合の、終了点生成方法の第２の実施形態は次の通りである。ファイルフォーマット順序における各フレームの提示時間と各フレームに対するバイトオフセットとを決定する。各バイトオフセットＢＯに対して、BOでまたはその後に開始するファイルフォーマット順序における全てのフレームのうちで最早の提示時間ＰＴを決定する。決定された終了点は（ＰＴ，ＢＯ）である。（１つの追加の終了点（ＰＴ，ＢＯ）が存在し、ＢＯは表示の終わりに対するバイトオフセットであり、ＰＴは表示の提示終了時間である。）ＰＴ＝ＴｅｘｉｔＢ（ＢＯ）であることに留意されたい。この実施形態では、終了点生成方法は、背後にあるフレーム依存構造を分析して、終了点のリストを生成する必要がないことに留意されたい。これは、ファイルフォーマット順序が復号順序であるという特性が、ファイルフォーマット順序およびフレームの提示時間に基づいて終了点を効率的に決定するのに、十分なフレーム依存構造を表すからである。

【0095】

第２の実施形態によって生成されたリスト内の複数の連続する終了点が同じ提示終了時間ＰＴを有する場合、ファイルフォーマット順序における最早の終了点、すなわち、同じ提示終了時間ＰＴを有するこれら連続する終了点のうちで最小のバイトオフセットＢＯを有する終了点が主終了点であり、残りが副終了点である。

【0096】

図５〜図１４は、開始点と終了点とを生成するための例と可能なフォーマットとを示す。ファイルフォーマット順序は、図５〜図１２に示される例に対して示される復号順序であるので、上で説明された終了点生成方法は、図９〜図１２に示される終了点リストを生成するために使用されてよく、第１の実施形態は、これら例の各々において第２の表を生成するために使用されてよく、第２の実施形態は、これら例の各々において第３の表を生成するために使用されてよく、これら例の各々において主終了点の第４の表は、上で説明された２つの実施形態のいずれかを使用して生成され得る。

【0097】

終了点生成器に対する多くの代替形態および拡張がある。例えば、終了点生成方法の第２の実施形態は、ファイルフォーマットが連続的に生成される時のように、すなわち各バイトオフセットＢＯに対して、オンラインの方法で終了点を生成でき、方法は、ファイルフォーマット順序でＢＯよりも前に開始する全てのフレームのうちで欠落フレームの最早の提示時間ＰＴを決定でき、終了点は（ＰＴ，ＢＯ）である。例えば、図１において、バイトオフセットＢＯがフレーム５の始まりに対するものである場合、ファイルフォーマット順序でＢＯよりも前に開始するフレームはフレーム１なので、欠落フレームの最早の提示時間ＰＴはフレーム２の提示時間であり、これは、提示終了時間がフレーム１の提示終了時間であることを意味する。別の例として、図１において、バイトオフセットＢＯがフレーム１３の始まりに対するものである場合、ファイルフォーマット順序でＢＯよりも前に開始するフレームはフレーム１、５、２、３、４、６、７、８および９なので、このリスト内の欠落フレームの最早の提示時間ＰＴはフレーム１０の提示時間であり、これは、提示終了時間がフレーム９の提示終了時間であることを意味する。BOでまたはその後に開始するファイルフォーマットにおけるフレームについての情報は必要とされないことに、留意されたい。当業者が認識するように、ファイルフォーマット順序でＢＯよりも前にある全てのフレームの提示時間からのＰＴの効率的な決定をさせる標準的データ構造と方法とが存在する。

【0098】

図１３および図１４に示される例では、ファイルフォーマット順序は、図４に示される復号順序ではないが、ファイルフォーマット順序は提示時間順序であることに留意されたい。ファイルフォーマット順序が復号順序ではないので、終了点生成方法の第１の実施形態は図１４に示される第２の表を生成せず、同様に、終了点生成方法の第２の実施形態は、図１４に示される第３の表を生成しないことを、立証できる。しかしながら、以下で説明される終了点生成方法の第３の実施形態は、図１４に示される表を生成するために使用され得る。

【0099】

背後にあるファイルフォーマット順序およびフレーム依存構造とは独立に使用され得る終了点生成方法の第３の実施形態は、次のように説明され得る。各バイトオフセットＢＯに対して、大きくともＰＴの提示終了時間を有する全てのフレームが、ファイルフォーマット順序でＢＯよりも前に開始するフレームのみに、直接的または間接的のいずれかに依存するように、最遅の提示時間ＰＴを決定する。次いで、決定された終了点は（ＰＴ，ＢＯ）である。ＰＴ＝ＴｅｘｉｔＢ（ＢＯ）であることに留意されたい。終了点生成方法の第３の実施形態は、ファイルフォーマットが連続的に生成される時のように、すなわち各バイトオフセットＢＯに対して、オンラインの方法で終了点を生成し、ファイルフォーマット順序でＢＯよりも前にあるフレームの提示時間およびフレーム依存構造のみに基づいて、ＢＯに関連付けられる提示終了時間を決定できる。

【0100】

ＢＯに関連付けられる提示終了時間を決定するための１つの処理は、ＢＯよりも前に開始するフレームの第１のリストを決定し、BOでまたはＢＯを過ぎて開始するフレームに直接的または間接的のいずれかに依存する全てのフレームを、フレームの第１のリストから除去することによって、フレームの第１のリストからフレームの第２のリストを決定することであり、ＰＴは、フレームの第２のリストにない全てのフレームのうちで最小のフレーム番号を有するフレームの提示時間である。フレームの第２のリストが次のように決定され得ることに、留意されたい。BOでまたはＢＯを過ぎて開始するフレームに直接依存する全てのフレームを、フレームの第１のリストから選択することによって、フレームの第３のリストを決定する。フレームの第２のリストが次いで、フレームの第１のリスト内のフレームのうちのフレーム依存構造から、かつフレームの第３のリストから決定され得る。

【0101】

当業者が認識するように、上で説明された実施形態に対して可能な多くの代替形態および最適化が存在する。例えば、特定のバイトオフセットＢＯに関連付けられる提示終了時間を決定するための、上で説明された処理は、ＢＯのための情報とリストとを決定するための、ＢＯの前のバイトオフセットからの情報とリストとを保持する全体の処理に統合され得る。別の最適化として、リストフォーマット以外のデータ構造が使用されてよく、リストの一部分のみについての詳細な情報が、明示的に表されてよい。例えば、フレーム依存構造が、ファイルフォーマット順序でそのフレームの後または前にある多くともＤ個のフレームであるフレームに、各フレームが直接的または間接的のいずれかに依存するようなものであることが知られている場合、ＢＯよりも前または後に開始するＤ個のフレームに対する詳細な情報が保持されてよく、フレームについてのあらゆる他の情報が、暗黙的に、または圧縮されたフォーマットで表され得る。

【0102】

開始点発生方法の第１の実施形態は、次の通りである。よくあるように、次のような特性を有する、ＩＤＲフレームと省略されることの多いＩｎｄｅｐｅｎｄｅｎｔ Ｄａｔａ Ｒｅｆｒｅｓｈフレームと以後呼ばれるタイプのフレームがあると、仮定する。フレームＦがいずれの他のフレームにも依存せず、フレームＦの提示時間よりも長い提示時間を有する全てのフレームＦ’、および、そのようなフレームＦ’が依存する全てのフレームが全て、ファイルフォーマット順序でフレームＦの後にある場合、フレームＦはＩＤＲフレームである。

【0103】

開始点生成方法の第１の実施形態は、ＩＤＲフレームを識別でき、そのような各ＩＤＲフレームＦに対して、ファイルフォーマット順序におけるフレームＦに対するバイトオフセットＢＯを決定でき、次いで、開始点を（ＰＴ，ＢＯ）として決定でき、ＰＴはフレームＦの提示時間である。この第１の実施形態では、開始点生成方法は、背後にあるフレーム依存構造を分析して、開始点のリストを生成する必要がないことに留意されたい。これは、ＩＤＲフレームの定義が、開始点を効率的に決定するのに十分なフレーム依存性とファイルフォーマット構造とを表すからである。

【0104】

開始点生成方法の第１の実施形態に対する、多くの代替形態および拡張が存在する。例えば、開始点生成方法の第１の実施形態は、ファイルフォーマットが連続的に生成される時のように、すなわちファイルフォーマット順序におけるフレームＦに対する各バイトオフセットＢＯに対して、オンラインの方法で開始点を生成し、ＦがＩＤＲフレームであるかどうかを判定し、ＩＤＲフレームである場合、フレームＦの提示時間ＰＴを決定し、開始点（ＰＴ，ＢＯ）を決定できる。フレームＦの後にあるファイルフォーマットにおけるフレームについての情報は必要とされないことに、留意されたい。

【0105】

背後にあるファイルフォーマット順序およびフレーム依存構造とは独立に使用され得る終了点開始方法の第２の実施形態は、次のように説明され得る。各バイトオフセットＢＯに対して、少なくともＰＴの提示時間を有する全てのフレームが、ファイルフォーマット順序でBOでまたはＢＯよりも後に開始するフレームのみに、直接的または間接的のいずれかに依存するように、最早の提示時間ＰＴを決定する。次いで、決定された終了点は（ＰＴ，ＢＯ）である。ＰＴ＝ＴｅｎｔｒｙＢ（ＢＯ）であることに留意されたい。

【0106】

図５、図６（ａ）、図７、および図８は、それぞれ図１、図２、図３、および図４に示されるフレーム依存構造に対応する、ファイルフォーマット順序と、対応する生成された開始点リストとの、異なる例を示す。図６（ｂ）および図１３は、ファイルフォーマット順序が提示時間順序である場合の、それぞれ図２および図４に示されるフレーム依存構造に対応する、ファイルフォーマット順序と対応する生成された開始点リストとの別の例を示す。これら開始点の特性の一部は、上で既に説明されている。

【0107】

図５、図６（ａ）、図６（ｂ）、図８、および図１３において、フレーム依存構造およびファイルフォーマット順序は、各々のＩフレームがＩＤＲフレームであり、従って開始点生成方法の第１の実施形態が開始点のリストを生成できるようなものである。第１の実施形態によって生成される開始点リストは、図５、図６（ａ）、および図６（ｂ）に対する主開始点リストの第４の表に対応する。第１の実施形態によって生成される開始点リストは、図８に対する主開始点リストの第４の表とは異なり、具体的には、図８に示される主開始点（１４，４８３０３）は、第１の実施形態が生成するであろう開始点（１７，４８３０３）よりも好ましい。第１の実施形態によって生成される開始点リストは、図１３に対する主開始点リストの第４の表のサブセットであり、具体的には、図１３に示される３個の主開始点（１４，４８３０３）、（１５，５１０３２）および（１６，５４５２３）は、第１の実施形態によっては生成されないであろう。

【0108】

図７では、ラベル９を有するＩフレームはＩＤＲフレームではなく、ラベル１０、１１、および１２を有するフレームはファイルフォーマット順序においてＩフレームの後に続くので、それらのフレームは全て、Ｉフレームに先行するラベル１３を有するフレームに依存することに留意されたい。

【0109】

第２の実施形態によって生成される開始点リストは、図５、図６（ａ）、図６（ｂ）、図７、図８、および図１３に対する主開始点リストの第３の表に対応する。

【0110】

第２の実施形態によって生成されたリスト内の複数の連続する開始点が同じ提示開始時間ＰＴを有する場合、ファイルフォーマット順序における最遅の開始点、すなわち、同じ提示開始時間ＰＴを有するこれら連続する開始点のうちで最大のバイトオフセットＢＯを有する開始点が主開始点であり、残りが副開始点である。図５、図６（ａ）、図６（ｂ）、図７、図８、および図１３における第４の表に示されている主開始点リストは、一般に、第２の実施形態によって生成される開始点リストに基づいて、この主開始点選択処理から生成され得る。

【0111】

フレームが、ファイルフォーマット順序に関してＤ個よりも多くのフレーム分だけ離れているいずれのフレームにも、直接的または間接的のいずれかに依存しないようにフレーム依存構造が限定されるような、いくつかの正の整数値Ｄがあると仮定する。次いで、開始点生成方法の第２の実施形態は、ファイルフォーマットが次のように連続的に生成される時のように、すなわち各バイトオフセットＢＯに対して、オンラインの方法で生成されてよく、ファイルフォーマット順序でＢＯよりも前にあるフレームからＢＯよりも後の多くともＤ個のフレームまでの、提示時間およびフレーム依存構造のみに基づいて、ＢＯに関連付けられる提示開始時間を決定できる。

【0112】

ＢＯに関連付けられる提示開始時間を決定するための１つの処理は、ＢＯよりも前に開始する最大のフレーム番号を有するフレームと共にファイルフォーマット順序においてバイトオフセットBOで開始するＤ個の連続するフレームとを備える、Ｄ＋１個のフレームの第１のリストを決定し、ＢＯよりも前に開始するフレームに直接的または間接的のいずれかに依存するフレームの第１のリスト内のフレームのうちで、フレームの最大のフレーム番号である第１のフレーム番号を決定することであり、ＰＴは、第１のフレーム番号よりも大きなフレーム番号を有するフレームの提示時間である。ファイルフォーマット順序においてフレームの第１のリストよりも先にあるいずれのフレームも、ＢＯよりも前に開始する任意のフレームに、直接的または間接的のいずれかに依存し得ないことを留意されたい。第１のフレーム番号は、次のように決定され得る。ＢＯよりも前に開始するフレームに直接依存する全てのフレームを、フレームの第１のリストから選択することによって、フレームの第２のリストを決定する。第１のフレーム番号が次いで、フレームの第１のリスト内のフレームのうちのフレーム依存構造から、かつフレームの第２のリストから決定され得る。

【0113】

当業者が認識するように、上で説明された実施形態に対して可能な多くの代替形態および最適化が存在する。例えば、特定のバイトオフセットＢＯに関連付けられる提示開始時間を決定するための、上で説明された第２の実施形態は、ＢＯのための情報とリストとを決定するための、ＢＯの前のバイトオフセットからの情報とリストとを保持する全体の処理に統合され得る。別の最適化として、リストフォーマット以外のデータ構造が使用されてよく、リストの一部分のみについての詳細な情報が、明示的に表されてよい。例えば、BOで開始するＤ個の連続するフレームのための詳細な情報が保持されてよく、フレームについての任意の他の情報は、暗黙的に、または圧縮されたフォーマットで表され得る。

【0114】

シームレスな切替方法
１．開始点と終了点とを使用したシームレスな切替方法
表示に関連付けられる開始点と終了点の特性は、次の通りである。開始点と共にリストされた提示開始時間は再生を開始して、表示の終了点と共にリストされた任意の後続の提示終了時間までシームレスに継続できる表示でのデータの提示時間を示し、開始点に関連付けられるバイトオフセットはその提示時間で再生を開始させるであろうデータを受信するダウンロードが開始できるセグメント内のバイト位置を示す。同様に、終了点と共にリストされた提示終了時間は、表示の開始点と共にリストされた任意の以前の提示開始時間で開始したシームレスな再生を終了できる表示でのデータの提示時間を示し、終了点に関連付けられるバイトオフセットはその提示時間で再生を終了させるであろうデータを受信するダウンロードが終了できるセグメント内のバイト位置を示す。

【0115】

第１の表示から第２の表示に切り替えるためのクライアント方法の概要は、次の通りである。クライアントが提示時間Ｔの後の可能な最早の提示時間においてシームレスな切り替えを行うことを望むと決定したと仮定し、ここで例えばＴは、メディアバッファにおいて既に利用可能な第１の表示、または、メディアバッファへダウンロードされるように既に要求されている第１の表示からの最遅の提示時間である。第２の表示に対する利用可能な開始点から、クライアントは、少なくともＴである第２の表示の全ての提示開始時間のうちでＴＳが最早となるように開始点（ＴＳ，ＢＯＳ）を選択できる。第１の表示に対する利用可能な終了点から、クライアントは、少なくともＴＳである第１の表示の全ての提示終了時間のうちでＴＥが最早となるように、終了点（ＴＥ，ＢＯＥ）を選択できる。クライアントは、第１の表示から終了バイトオフセットＢＯＥまでのデータをダウンロードでき、開始バイトオフセットＢＯＳで開始する第２の表示からのデータをダウンロードできる。クライアントは、第１の表示および第２の表示からのダウンロードされたデータをメディアプレーヤに提供し、第１の表示から時刻ＴＥまで（時刻ＴＥを含む）をビデオ復号し、時刻ＴＳで開始しそこから継続する第２の表示をビデオ復号するように、メディアプレーヤに命令できる。ＴＳがＴＥに等しくない場合、すなわちＴＥ＞ＴＳである場合、メディアプレーヤは、第１の表示から何らかの提示時間ＴＵまで、ディスプレイに対してビデオをレンダリングして、次いで、提示時間ＴＵで開始する第２の提示からの表示を継続すると決定でき、ＴＵは、ＴＳからＴＥまでの間にある。いくつかの実施形態では、ＴＵ＝ＴＳであれば好ましく、それは、開始点における第２の表示の再生の新たな開始が可能になるからである。

【0116】

第１の代替的なクライアント切替方法として、クライアントが提示時間Ｔの前の可能な最遅の提示時間においてシームレスな切り替えを行うことを望むと決定したと仮定する。第１の表示に対する利用可能な終了点から、クライアントは、大きくともＴである第１の表示に対する全ての提示終了時間のうちでＴＥが最遅となるように終了点（ＴＥ，ＢＯＥ）を選択できる。第２の表示に対する利用可能な開始点から、クライアントは、大きくともＴＥである第２の表示に対する全ての提示開始時間のうちでＴＳが最遅となるように、開始点（ＴＳ，ＢＯＳ）を選択できる。開始点および終了点が選択されると、第１の代替的なクライアント方法の残りは、上で説明されたようなものであり得る。

【0117】

第２の代替的なクライアント切替方法として、クライアントが提示時間Ｔに可能な限り近い提示時間においてシームレスな切り替えを行うことを望むと決定したと仮定する。第１の表示に対する利用可能な終了点から、クライアントは、少なくともＴである第１の表示に対する全ての提示終了時間のうちでＴＥが最早となるように終了点（ＴＥ，ＢＯＥ）を選択できる。第２の表示に対する利用可能な開始点から、クライアントは、大きくともＴＥである第２の表示に対する全ての提示開始時間のうちでＴＳが最遅となるように開始点（ＴＳ，ＢＯＳ）を選択できる。開始点および終了点が選択されると、第２の代替的なクライアント方法の残りは、上で説明されたようなものであり得る。

【0118】

第３の代替的なクライアント切替方法として、クライアントは、大きくともＴである第２の表示の全ての開始点のうちでＴＳが最遅の提示開始時間となるように、第２の提示に対して利用可能な開始点から開始点（ＴＳ，ＢＯＳ）を選択できる。第１の表示に対する利用可能な終了点から、クライアントは、ＴＳの後である第１の表示の全ての提示終了時間のうちでＴＥが最早となるように、終了点（ＴＥ，ＢＯＥ）を選択できる。

【0119】

第４の代替的なクライアント切替方法として、クライアントが、例えば、第１の表示からダウンロードしたバッファに既にあるメディアに基づいて、第１の表示におけるバイトオフセットＢＯよりも前の可能な最遅の提示時間において、第１の表示から第２の表示へシームレスな切り替えを行うことを望むと決定したと仮定し、ＢＯは、メディアバッファに既にダウンロードされている第１の表示の一部分の終わりのバイトオフセットであってよく、または、メディアバッファへのダウンロードを既に要求されている第１の表示の終わりのバイトオフセットであってよい。第１の表示に対して利用可能な終了点から、クライアントは、大きくともＢＯである第１の表示に対する全ての終了バイトオフセットのうちでＢＯＥが最遅となるように終了点（ＴＥ，ＢＯＥ）を選択できる。第２の表示に対して利用可能な開始点から、クライアントは、大きくともＴＥである第２の表示に対する全ての提示開始時間のうちでＴＳが最遅となるように開始点（ＴＳ，ＢＯＳ）を選択できる。開始点および終了点が選択されると、第４の代替的なクライアント方法の残りは、上で説明されたようなものであり得る。当業者が認識するように、例えば、第４の代替形態のように、第１の表現に対する初期バイトオフセットに基づく切り替えの決定に基づき、第２の代替形態で説明されたように、これに基づいて開始点と終了点とを決定する、上記の組合せである他の代替的なクライアント切替方法がある。

【0120】

第１、第２、および第４の代替的なクライアント切替方法に対して、第１の表示のために選ばれた終了点は、第２の表示のために選ばれた開始点とは独立であることに留意されたい。従って、これら代替形態は、切り替え先として考えられ得る２つ以上の第２の表示の選択肢があり得る場合に、魅力的な方法を提供し、クライアントは、可能性のある第２の表示のいずれを選ぶかを決める前に、第１の表示のダウンロードをどこで完了するかを決めることができる。所与の提示時間ＴまたはバイトオフセットＢＯの前に、第１の表示に対する終了点を選ぶ代替形態は、利用可能な帯域幅が減少したことが原因でクライアントがレートの低い第２の表示に下がる必要がある場合に適用可能であることがあり、この場合、提示時間ＴまたはバイトオフセットＢＯは、最遅の利用可能な提示時間、または第１の表示に対して利用可能なもしくはまもなく利用可能になるバイトオフセットであってよく、利用可能な帯域幅が減少した場合に、よりレートの高い第１の表示から追加のデータをダウンロードする必要がなく、それは、このことが、再生をシームレスに継続することを可能にするのに十分なデータが第２の表示から届く前に、メディアバッファが使い果たされる確率を最小にする傾向があるからである。

【0121】

２．開始点および終了点に基づくダウンロード部分の選択
本開示を読んだ後に当業者が認識するように、クライアントが開始点および終了点情報を利用できる多くの方法がある。例えば、ユーザ体験に関する決定的な要因は、ユーザが、例えば、ウェブページにおけるリンクをクリックすることによって、または、マウスを使用してビデオの再生位置を異なる再生時間へとドラッグすることによって、ビデオの再生を要求した時から、ビデオの再生が開始するまでにかかる時間である。この時間が短いほど、一般にユーザ体験は良好になり、特にユーザが異なるコンテンツを試しに見ている場合、すなわち、あるコンテンツから別のコンテンツへとかなり頻繁に移動している場合、または、特定のコンテンツ内の異なる開始位置を探している場合、特に良好になる。従って、この始動時間を最小にすることは、重要な問題である。

【0122】

開始点情報および終了点情報へのアクセス権を有するクライアントは、再生がコンテンツの単一の表示からのものである場合、すなわち、ある表示から別の表示への切り替えがない場合でも、この情報を使用して、始動時間を最小にできるので、クライアントは必ずしもＡＨＳクライアントではない。例えば、クライアントは、再生を開始すべき第１の開始点と、後続の第１の終了点、第２の終了点、第３の終了点などのリストとを与えられ得る。クライアントは、後続の終了点を使用して、第１の要求においてコンテンツのどの部分を要求するかを決めることができ、この部分は、第１の開始点のバイトオフセットから第１の終了点のバイトオフセットまでであり得る。クライアントは次いで、第１のダウンロード要求が満たされている時、再生が開始した後のストールまたは再バッファを避ける技法を好ましくは使用して、ビデオの再生をいつ開始すべきかについて決めることができる。クライアントはまた、後続の要求の開始バイトオフセットおよび終了バイトオフセットとして、後続の終了点のバイトオフセットを使用して、コンテンツの後続の部分に対するダウンロード要求を発することができるので、好ましくは、これら後続の要求は、ストールまたは再バッファを回避するような方法で発せられる。メディアバッファが満ちると、クライアントは、メディアが満ちていない場合よりもコンテンツの大きな部分にわたるコンテンツの部分に対する要求を発する可能性があり、ここで、より大きいとは、提示時間がより長いこと、バイトがより多いこと、またはこれら両方を意味する。

【0123】

別の代替形態として、ＡＨＳクライアントは、上で説明され次のように拡張される方法を使用できる。コンテンツのただ１つの表示ではなく、複数の表示がある。ＡＨＳクライアントは、第１の表示のコンテンツの再生を開始すべき第１の開始点と、この第１の表示に対する第１の後続の終了点とを取得し、またはそれらを与えられてよく、また、第１の開始点の後にある代替的な表示に対する開始点も与えられてよい。この場合、ＡＨＳクライアントは、前の段落において説明されたクライアント方法と同様に、しかし部分を決定するために代替的な表示における可能な開始点も場合によって使用して、第１の表示のどの部分をダウンロードすべきかを決めることができる。例えば、これは普通であることが多いが、終了点の頻度は開始点の頻度よりも高くてよく、例えば、表示の連続的な開始点の各ペアの間に設けられる、複数の、例えば５個以上の終了点が存在し得る。この場合、ＡＨＳクライアントは、前のように、例えば、第１の表示の開始点から第１の後続の終了点までの、比較的短いダウンロード部分で開始すると決めることができ、メディアバッファは、例えば、ある終了点から、その後の２つ以上の終了点である終了点までの、より大きな部分のダウンロードを開始するために拡大する。しかしながら、ＡＨＳクライアントは、第１の表示のどの部分をダウンロードすべきかについて決定を行う際に、他の代替的な表示に対する開始点を考慮して、例えば、レート切替が必要である場合に、ＡＨＳクライアントが、第１の表示からダウンロードされ場合によって第２の表示に切り替えられる重複するコンテンツの量を最小にするために、第１の表示から適切な部分をダウンロードすることを、確実にできる。例えば、第１の表示から部分をダウンロードする時、ＡＨＳクライアントは、切り替えが選ばれ得る第２の表示の可能な第２の開始点の提示時間にある、またはそれをわずかに過ぎた終了点に関連付けられるバイトオフセットで終了する第１の表示から、現在のダウンロード部分を選ぶことができ、すなわち、現在のダウンロード部分の後に選ばれる次のダウンロード部分は、第２の開始点に関連付けられるバイトオフセットで開始する、第２の表示からのものであり得る。

【0124】

別の代替形態として、Ｌｕｂｙ Ａ５において開示されるように、クライアントは、複数の同時のＨＴＴＰ接続を使用して表示をダウンロードでき、加えてＦＥＣを使用できる。この代替形態では、Ｌｕｂｙ Ａ５において開示されるように、高速な始動時間を確実にしつつ、同時にダウンロード要求の数を最小にするような方法で、複数の接続がコンテンツをダウンロードするようにスケジューリングされることが重要である。従って、最初に始動する時、クライアントは、複数の接続にわたって、第１の開始点から第１の後続の終了点まで、コンテンツの部分のダウンロードを区分でき、例えば、４つの接続のうちの第１の接続は、この部分の最初の１／４のダウンロードを要求でき、第２の接続は、次の１／４のダウンロードを要求できる、などである。このようにして、接続は、再生のために最初に必要とされるコンテンツの部分の断片を全てダウンロードしている。さらに、Ｌｕｂｙ Ａ５において開示されるように、コンテンツに対する追加のＦＥＣデータは、別個のファイルにおいて利用可能にされてよく、このＦＥＣデータに対するダウンロード要求が、再生のために必要であるコンテンツの配信をさらに高速化するために行われ得る。前の代替形態のように、メディアバッファが満ちるに従い、ダウンロード要求部分の断片は大きくなることがあり、ＡＨＳクライアントの場合、第１の表示に対して選ばれたダウンロード部分（複数の接続を通じて要求されるべき複数の断片へと続いて区分される）の開始および終了が、切り替えの行われ得る可能な代替的な表示に対する開始点に基づいて行われ得る。

【0125】

３．切替情報を生成するための処理の概要
セグメントマップは、適応ストリーミング方法の表示のより高速な切り替えを提供すると同時に、切り替えの間にネットワークを通じてより少量のデータをダウンロードし、ビデオプレーヤによってある表示から別の表示に切り替える時のより円滑なビデオ再生を可能にするために、クライアントによって有利に使用され得る。やはり本明細書で説明されるように、セグメントマップは、例えば始動時間の改善と、再バッファ／ストール事象に対する回復力の改善とを可能にすることのような、他の使用法を有する。

【0126】

例として、セグメントマップは、開始点リストと、終了点リストと、任意選択で、表示のセグメントに関連付けられる他のメタデータとを備え得る。開始点リストは、開始点のリストを備え、開始点のリストは、そのような各開始点、提示開始時間、および開始バイトオフセットに関連付けられる。終了点リストは、終了点のリストを備え、終了点のリストは、そのような各終了点、提示終了時間、および終了バイトオフセットに関連付けられる。

【0127】

セグメントマップを生成することは、２つの方法の部分へと機能的に区分され得る。第１の方法の部分に関連付けられるのは、本明細書では開始点生成器および終了点生成器と呼ばれる、２つのタイプの方法であり、開始点生成器および終了点生成器は、特定のフォーマットで符号化されるメディアのファイルまたはストリームを入力として取り込み、そのメディアに対する開始点および終了点の詳細なリストをそれぞれ生成する。本明細書ではセグメントマップ生成器と呼ばれる第２の方法の部分は、セグメントマップを生成するための開始点および終了点の詳細なリストを、入力として取り込む。

【0128】

セグメントマップ生成器の実施形態は、セグメントマップを生成するために、開始点生成器および終了点生成器の出力を使用できる。セグメントマップ生成器は、メディアフォーマットに依存しないものであってよく、セグメントマップにおいて、最適化された開始点および終了点のリストを提供でき、ここで、最適化されているとは、開始点および終了点が小型な方法で選択され表されることを意味するので、セグメントマップは、クライアントが表示を開始し終了するのに良好な場所の豊富なセットを提供する。セグメントマップの生成は、メディアコンテンツの各表示に対して独立に実行されてよく、または協調して実行されてよい。

【0129】

多くの変形が可能である。例えば、特にライブストリーミングコンテンツでは、開始点生成器と終了点生成器とセグメントマップ生成器とを緊密に統合する方法が好ましく、また、オンデマンドストリーミングコンテンツにおいても好ましいことがある。

【0130】

Ｐａｋｚａｄにおいて開示される方法は、ＡＨＳクライアントによって効率的かつ効果的に使用され得る開始点と終了点のセットから、簡潔なセグメントマップを生成するために使用されてよく、すなわち、Ｐａｋｚａｄは、表示のセグメントを好ましいフラグメントへと区分するための方法を含む、セグメントマップ生成器のいくつかの実施形態を開示する。方法を、本明細書で説明される方法および処理によって拡張でき、具体的には、各フラグメントが、それぞれ主開始点における開始または主終了点における終了を可能にするように開始または終了するのであれば、好ましい。

【0131】

例として、図１は、クローズドＧＯＰフレーム依存構造を示し、この場合、第１のフラグメントはフレーム１と、５と、２と、３と、４とを備えてよく、第２のフラグメントはフレーム６と、７と、８とを備えてよく、第３のフラグメントはフレーム９と、１３と、１０と、１１と、１２とを備えてよく、第４のフラグメントはフレーム１４と、１５と、１６とを備えてよい、などである。このフラグメント構造は、全ての主開始点がフラグメントの始まりにあるので、かつ、クライアントが表示を開始しまたは切り替える時に部分的なＧＯＰのダウンロードを可能にし、従って、ＧＯＰ全体がダウンロードされるより前にコンテンツに相当する部分的なＧＯＰの再生を可能にするので、好ましいことがある。ＧＯＰの終わりにある特定の主終了点も好ましく、それは、一般にＢフレームがＩフレームまたはＰフレームよりも小さく、従って、大きなフレームと同じ量の再生時間を可能にする小さなフレームをダウンロードすることが、一般に有利であるからである。ＧＯＰ構造が異なる表示の間で整列される場合、この例では、フラグメント構造が、再生されないフレームのダウンロードを何ら伴わない表示の切り替えを可能にする。

【0132】

別の例として、図２は、オープンＧＯＰフレーム依存構造を示し、この場合、第１のフラグメントはフレーム１を備えてよく、第２のフラグメントはフレーム５と、２と、３と、４とを備えてよく、第３のフラグメントはフレーム９と、６と、７と、８とを備えてよく、第４のフラグメントはフレーム１３と、１０と、１１と、１２とを備えてよく、第５のフラグメントは、フレーム１７と、１４と、１５と、１６とを備えてよい、などである。この場合、第１のフラグメントは、それより後のパターンとは異なるフレームのパターンを伴って形成される。このフラグメント構造は、前の段落の例について説明されたのと同じ利点の多くを有する。ＧＯＰ構造が異なる表示の間で整列される場合、このフラグメント構造が、再生されない４個の重複するフレーム、すなわち、１個のＩフレームおよび３個のＢフレームの最小限のダウンロードを伴う表示の切り替えを可能にする。

【0133】

ＭＰＥＧ ＤＡＳＨシグナリングに基づくマッピングの変化
１．開始点および終了点のＭＰＥＧ ＤＡＳＨ規格シグナリング
ＭＰＥＧ ＤＡＳＨ規格は、以下の表１に示されるような、セグメント内のフラグメントを表すための大まかなセグメントマップ構造を有する。

【表1】

【0134】

上のセグメントマップ構造の解釈は、次の通りである。ＥＳＰＴの値は、セグメント内の最早の提示時間を伴うフレームの提示時間である。

【0135】

Ｔｉｍｅｓｃａｌｅの値は、表示のこのセグメントに対する、時間をティック単位で測定するために使用される１秒当たりのティックの数である。例えば、Ｔｉｍｅｓｃａｌｅ＝３００００である場合、表示のこのセグメントに対して、１秒当たり３００００個のティックがあるので、９００００ティックとして表される時間は、９００００／３００００秒、すなわち３秒という長さを示す。通常、時間の全ての単位、例えば、ＥＳＰＴ、Ｄｅｌｔａ、およびＲＡＰ−ｄｅｌｔａが、セグメント内のティックで表される。フレームの通常の長さは１００１ティックであることがあり、これは、１秒当たり約２９．９７個のフレームがあることを意味する。

【0136】

Ｎの値は、セグメント内のフラグメントの数である。

【0137】

ＳＢ（ｉ）の値は、セグメントのフラグメントｉのバイト単位のサイズである。従って、セグメント内のフラグメントｉの始まりに対するバイトオフセットは、ｉ未満の全てのｊにわたるＳＢ（ｊ）の和である。

【0138】

Ｄｅｌｔａ（ｉ）の値は、フラグメントｉ＋１内の任意のフレームの最早の提示時間と、フラグメントｉ内の任意のフレームの最早の提示時間との差である。従って、フラグメントｉの後の次のフラグメント内のフレームの最早の提示時間は、ＥＳＰＴに、ｊ≦ｉである全てのｊにわたるＤｅｌｔａ（ｊ）の和を足したものである。

【0139】

ＲＡＰ−ｐｒｅｓｅｎｔ−ｆｌａｇ（ｉ）の値は、フラグメントｉ内に表示アクセスポイント（ＲＡＰ）があるかどうかを示す。

【0140】

フラグメントｉ内でシグナリングされるＲＡＰがある場合、ＲＡＰ−ｄｅｌｔａ（ｉ）の値は、フラグメントｉ内のＲＡＰ提示時間と、フラグメントｉ内のフレームの最早の提示時間との差である。従って、フラグメントｉ内にＲＡＰがある場合、フラグメントｉ内のＲＡＰ提示時間は、ＥＳＰＴと、ＲＡＰ−ｄｅｌｔａ（ｉ）と、ｊ＜ｉである全てのｊにわたるＤｅｌｔａ（ｊ）の和とを足したものである。

【0141】

ＭＰＥＧ ＤＡＳＨセグメント構造の背後にある基本的な考えは、ＨＴＴＰ１．１バイト範囲要求を使用してセグメント内のフラグメントをダウンロードでき、フラグメントは通常、ダウンロードのために要求されるエンティティのうちで最小であることである。表示のシームレスな切り替えをサポートするような方法でフラグメント構造を整列することは理にかなっており、特に、フラグメントの境界を開始点および終了点と揃え、セグメント内で開始点と終了点とをシグナリングし、効率的かつシームレスな切り替えをサポートすることは、有益である。

【0142】

ＭＰＥＧ ＤＡＳＨセグメントマップフォーマットは、セグメントの開始点のシグナリングをサポートするために、次のように使用され得る。ＭＰＥＧ ＤＡＳＨ規格は、次のように関連付けられる（本明細書で使用される用語に変換される）、バイトオフセット、すなわちＩＲＡＰと、提示時間、すなわちＴＲＡＰとを備えるものとして、ＲＡＰを定義する。（１）表示のダウンロードがバイトオフセットＩＲＡＰから開始され終わりに進むように続く場合、ＴＲＡＰは、表示におけるコンテンツのビデオフレームが、提示時間ＴＲＡＰで開始する提示順序でシームレスに再生され得るような、最早の提示時間であり、（２）表示のダウンロードがバイトオフセットＩＲＡＰから開始され終わりに進むように続く場合、ＩＲＡＰは、表示におけるコンテンツのビデオフレームが、提示時間ＴＲＡＰで開始する提示順序でシームレスに再生され得るような、最大のバイトオフセットである。

【0143】

従って、ＭＰＥＧ ＤＡＳＨ規格で定義されるＲＡＰは、本開示で定義される主開始点と等価であり、すなわち、（ＴＲＡＰ，ＩＲＡＰ）＝（ＴｅｎｔｒｙＢ（ＩＲＡＰ），ＢｅｎｔｒｙＴ（ＴＲＡＰ））である。そのＲＡＰに対するバイトオフセットがフラグメント内にある場合、フラグメントはＲＡＰを含んでいると言われる。

【0144】

ＭＰＥＧ ＤＡＳＨ規格は、次のようにＲＡＰをシグナリングできる。フラグメントｉが少なくとも１つのＲＡＰを含み、ＢＯを、フラグメントｉが含む全てのＲＡＰのバイトオフセットのうちで最小のＲＡＰのバイトオフセットとし、ＰＴ＝ＴｅｎｔｒｙＢ（Ｏ）を、ＢＯに対応するＲＡＰの提示時間とする。ＲＡＰ−ｐｒｅｓｅｎｔ−ｆｌａｇ（ｉ）の値は、ＲＡＰの存在を示すために設定されてよく、ＲＡＰ−ｄｅｌｔａ（ｉ）の値は、ＰＴから、ＥＳＰＴと、ｊ＜ｉである全てのｊにわたるＤｅｌｔａ（ｊ）の和とを引いたものに設定され得る。ＲＡＰフレームを含まない各フラグメントｉに対して、ＲＡＰ−ｐｒｅｓｅｎｔ−ｆｌａｇ（ｉ）の値は、ＲＡＰがないことを示すために設定され得る。従って、ＭＰＥＧ ＤＡＳＨ規格は、フラグメント内で主開始点をシグナリングすることをサポートする。

【0145】

ＢＯ（ｉ）を、セグメント内でのフラグメントｉの最初のバイトに対するバイトオフセットとする。フラグメントｉがＲＡＰを含む場合、ＴｅｎｔｒｙＢ（ＢＯ（ｉ））は、フラグメントｉ内で最早の提示時間を有するＲＡＰのＲＡＰ提示時間であることに留意されたい。

【0146】

いくつかの場合には、ＭＰＥＧ ＤＡＳＨセグメントマップフォーマットは、セグメントの終了点のシグナリングをサポートするために、次のように使用され得る。全てのフラグメントｉに対して、フラグメントｉ＋１の最初のバイトに対するバイトオフセットＢＯ（ｉ＋１）は、フラグメントｉの終わりで終了することに対応するバイトオフセットである。以下に説明される環境(circumstances)では、フラグメントｉの終わりで終了することに関連付けられる提示終了時間ＴｅｘｉｔＢ（ＢＯ（ｉ＋１））が、ＭＰＥＧ ＤＡＳＨセグメントマップフォーマットに基づいて、次のように正確に決定され得る。ＥＰＴ（ｉ）の値を、ＥＳＰＴに、ｊ≦ｉである全てのｊにわたるＤｅｌｔａ（ｊ）の和を足したものに設定する。前に説明されたように、ＥＰＴ（ｉ）は、フラグメントｉ＋１内の任意のフレームの最早の提示時間である。ＥＰＴ（ｉ）は、次の２つの条件が満たされれば、ＴｅｘｉｔＢ（ＢＯ（ｉ＋１））に等しいことが保証される。

【0147】

２．終了点の正しいシグナリングのための２つの条件
終了点の正しいシグナリングのための２つの条件は、（１）ファイルフォーマット順序が復号順序であることと、（２）フラグメント内の任意のフレームの最早の提示時間の数列が、連続的なフラグメントにわたって厳密に増加していくこと、すなわち、ＥＰＴ（１）＜ＥＰＴ（２）＜ＥＰＴ（３）などとなることである。

【0148】

第１の条件は、必ずではないが、ファイルフォーマットにおいて一般に真であり得る。さらに、ファイルフォーマットが復号順序ではない場合、通常は、上で説明されたシグナリングは、フラグメントの提示終了時間を正確にシグナリングしない。図４に示されるフレーム依存構造に対応するが、ファイルフォーマット順序が復号順序ではなく提示時間順序である、図１４は、第１の条件が真ではない例である。この例では、第１のフラグメントがフレーム１と、２と、３と、４とを含み、第２のフラグメントがフレーム５と、６と、７と、８とを含む場合、ＥＰＴ（１）の値は、フレーム５の提示時間に対するものであり、これは、第１のフラグメントの提示終了時間として使用されると、最初の４個のフレーム１、２、３、および４が第１のフラグメントを受信することで再生され得ることを示す。しかしながら、フレーム１のみが、第１のフラグメントを受信することで再生され得るので、ＥＰＴ（１）の値は、第１のフラグメントに対する提示終了時間を正確にシグナリングしない。

【0149】

第２の条件は真であることが多いが、セグメントのフラグメント構造に依存し、第１の条件が真であっても第２の条件が真ではない例がある。例えば、図９を参照すると、第１のフラグメントが最初の１３２４４バイトを備えフレーム１を搬送し、第２のフラグメントが次の５１５０バイトを備えフレーム５を搬送し、第３のフラグメントが次の３６３７バイトを備えフレーム２、３、４を搬送すると仮定する。この例では、最初の３個のフラグメントに対して上で計算されたような提示終了時間ＥＰＴ（１）、ＥＰＴ（２）、およびＥＰＴ（３）は、それぞれ、フレーム５、２、６の提示時間である。具体的には、第１のフラグメントに関連付けられる提示終了時間ＥＰＴ（１）は、提示時間順序における最初の４個のフレームを示し、すなわち、フレーム１、２、３、および４を、第１のフラグメントをダウンロードすることで再生できることを示すが、これは明らかに当てはまらない。

【0150】

従って、全体的に、ＭＰＥＧ ＤＡＳＨ規格は、フラグメント内の開始点をシグナリングすることをサポートするが、終了点をシグナリングすることのサポートは、それほど一般的ではない。

【0151】

３．第１のセグメントマップ方法：改善された終了点シグナリング
前に述べられたように、終了点がＭＰＥＧ ＤＡＳＨ規格によって常に正しくシグナリングされ得るとは限らない。具体的には、終了点が正しくシグナリングされるために、前に説明された終了点の正しいシグナリングのための２つの条件が、通常は必要とされる。第２の条件を除去できる１つの方法は、終了点のシグナリングの改善のためにＭＰＥＧ ＤＡＳＨを拡張するための、このセクションで説明される方法を使用することである。

【0152】

この手法では、ＥＳＰＴは、表示の残りにある、以前のセグメントよりも後の任意のフレームの最早の提示時間として再定義される。また、Ｄｅｌｔａ（ｉ）の値は、表示の残りにある、フラグメントｉよりも後の任意のフレームの最早の提示時間と、表示の残りにある、フラグメントｉ−１よりも後の任意のフレームの最早の提示時間との間の差として再定義される。

【0153】

そして、ＲＡＰ−ｄｅｌｔａ（ｉ）の値を、フラグメントｉ内のシグナリングされたＲＡＰのＲＡＰ提示時間と、表示の残りにある、フラグメントｉ−１よりも後の任意のフレームの最早の提示時間との間の差として再定義する。

【0154】

第１の条件が満たされる、すなわちファイルフォーマット順序が復号順序である場合、上記のパラメータの再定義によって、これら再定義された値に基づいて計算されたようなＥＰＴ（ｉ）は、第２の条件が満たされない場合でも、フラグメントｉに対する正しい提示終了時間であることが保証される。例として、図９を参照すると、上で説明された例のように、第１のフラグメントが最初の１３２４４バイトを備えフレーム１を搬送し、第２のフラグメントが次の５１５０バイトを備えフレーム５を搬送し、第３のフラグメントが次の３６３７バイトを備えフレーム２、３、および４とを搬送すると仮定する。この例では、ＥＳＰＴの値は前と同じであり、すなわち、フレーム１の提示時間である。しかしながら、最初の３個のフラグメントに関連付けられる上記の再定義に基づいて計算されたような提示終了時間ＥＰＴ（１）、ＥＰＴ（２）、およびＥＰＴ（３）は、それぞれ、フレーム２、２、６の提示時間である。具体的には、第１のフラグメントに関連付けられる提示終了時間ＥＰＴ（１）は、提示時間順序における最初のフレーム、すなわちフレーム１が、第１のフラグメントをダウンロードすることで再生され得ることを示す。さらに、第２のフラグメントに関連付けられる提示終了時間ＥＰＴ（２）は、フレーム１のみが最初の２個のフラグメントをダウンロードすることで再生され得ることを示し、第３のフラグメントに関連付けられる提示終了時間ＥＰＴ（３）は、最初の５個のフレーム１、２、３、４、および５が最初の３個のフラグメントをダウンロードすることで再生され得ることを示す。

【0155】

第２の条件に対応できる別の方法は、フラグメント内の任意のフレームの最早の提示時間の数列が連続的なフラグメントにわたって厳密に増加するような方法で、フラグメント構造が形成される場合である。例えば、各フラグメントが主終了点を含む場合、第２の条件が満たされる。

【0156】

フラグメント構造を決定することが可能である場合、主開始点を含む各フラグメントは、主開始点がフラグメントの始まりの近くにあるようなものであれば好ましい。また、主終了点を含む各フラグメントは、主終了点がフラグメントの終わりの近くにあるようなものであれば好ましい。

【0157】

両方の条件が除去され得る１つの方法は、現在のＭＰＥＧ ＤＡＳＨセグメントマップで搬送されるパラメータの定義を次のように修正することであり、これは、ＭＰＥＧ ＤＡＳＨセグメントマップシグナリングの好ましい方法である。

【0158】

４．第２のセグメントマップ方法：ＭＰＥＧ ＤＡＳＨセグメントマップ方法の修正
ＢＯを、表示のセグメントの始まりに対するバイトオフセットとし、ＢＯ（ｉ）を、フラグメントｉの始まりに対するバイトオフセットとする。

【0159】

ＥＳＰＴの値を、ＴｅｘｉｔＢ（ＢＯ）と再定義する。

【0160】

Ｄｅｌｔａ（ｉ）の値を、ＴｅｘｉｔＢ（ＢＯ（ｉ＋１））−ＴｅｘｉｔＢ（ＢＯ（ｉ））と再定義する。

【0161】

ＲＡＰ−ｄｅｌｔａ（ｉ）の値を、ＴｅｎｔｒｙＢ（ＢＯ（ｉ））−ＴｅｘｉｔＢ（ＢＯ（ｉ））と再定義する。

【0162】

ＭＰＥＧ ＤＡＳＨセグメントマップ方法の第２の修正は、上で説明された終了点の正しいシグナリングのための２つの条件のうちの第１の条件が満たされる場合、上で説明された第１の修正と実質的に等価であることに留意されたい。すなわち、第１の条件が満たされる場合、ＴｅｘｉｔＢ（ＢＯ）は、表示の残りにある以前のセグメントよりも後の任意のフレームの最早の提示時間であり、ＴｅｘｉｔＢ（ＢＯ（ｉ＋１））−ＴｅｘｉｔＢ（ＢＯ（ｉ））は、表示の残りにあるフラグメントｉよりも後の任意のフレームの最早の提示時間と、表示の残りにあるフラグメントｉ−１よりも後の任意のフレームの最早の提示時間との差であり、ＴｅｎｔｒｙＢ（ＢＯ（ｉ））−ＴｅｘｉｔＢ（ＢＯ（ｉ））は、フラグメントｉ内のシグナリングされたＲＡＰのＲＡＰ提示時間と、表示の残りにあるフラグメントｉ−１よりも後の任意のフレームの最早の提示時間との差である。しかしながら、第２の修正は、あらゆる条件と無関係に終了時間を計算するために正確に使用されてよく、ＭＰＥＧ ＤＡＳＨ規格内のＲＡＰの現在の定義と調和するためのさらなる事項である。

【0163】

ＴｅｘｉｔＢ（ＢＯ（ｉ＋１））は少なくともＴｅｘｉｔＢ（ＢＯ（ｉ））であるので、Ｄｅｌｔａ（ｉ）は、各フラグメントｉに対して負ではないことが保証される。さらに、主終了点の提示終了時間の数列は、終了バイトオフセットが増加する順で厳密に増加しているので、Ｄｅｌｔａ（ｉ）は、各フラグメントが少なくとも１つの主終了点を含む場合、各フラグメントｉに対して０より大きいことが保証され、Ｄｅｌｔａ（ｉ）＝０は、フラグメントｉが主終了点を何ら含まないことを示す。さらに、フラグメントｉが少なくとも１つの主終了点を含む場合、ＴｅｘｉｔＢ（ＢＯ（ｉ＋１））は、フラグメントｉ内の最後の主終了点の提示終了時間である。また、ＴｅｎｔｒｙＢ（ＢＯ（ｉ））は少なくともＴｅｘｉｔＢ（ＢＯ（ｉ））なので、ＲＡＰ−ｄｅｌｔａ（ｉ）は０以上であることが保証される。

【0164】

開始点および終了点は、ＡＨＳシステムにおいて表示の切り替えを行う際には等しく重要なので、ＭＰＥＧ ＤＡＳＨ規格をさらに拡張することを考えることができる。

【0165】

ＲＸＰと省略される「表示終了点(representation exit point)」の定義をＭＰＥＧ ＤＡＳＨ規格に導入でき、ＲＡＰが主開始点として定義される方法と同様に、ＲＸＰが主終了点として定義される。

【0166】

新たなパラメータＲＸＰ−ｐｒｅｓｅｎｔ−ｆｌａｇ（ｉ）が、各フラグメントｉに対して導入されてよく、ＲＸＰ−ｐｒｅｓｅｎｔ−ｆｌａｇ（ｉ）の値は、フラグメントｉ内に表示終了点（ＲＸＰ）があるかどうかを示す。ＲＸＰ−ｐｒｅｓｅｎｔ−ｆｌａｇの値は、ＭＰＥＧ ＤＡＳＨセグメントマップにおいて明示的にシグナリングされる必要はないが、代わりに、他のパラメータから次のように計算され得る。ＲＸＰ−ｐｒｅｓｅｎｔ−ｆｌａｇ（ｉ）の値は、Ｄｅｌｔａ（ｉ）＞０である場合、フラグメントｉ内にＲＸＰがあることを示し、Ｄｅｌｔａ（ｉ）＝０である場合、フラグメントｉ内にＲＸＰがないことを示す。

【0167】

フラグメントｉ内にＲＸＰがある場合、フラグメントｉに対するＲＸＰ提示時間は、ＥＳＰＴに、Ｄｅｌｔａ（ｉ）と、ｊ＜ｉである全てのｊにわたるＤｅｌｔａ（ｊ）の和とを足したものである。

【0168】

ＭＰＥＧ ＤＡＳＨ規格におけるように、ＲＡＰ−ｐｒｅｓｅｎｔ−ｆｌａｇ（ｉ）の値は、フラグメントｉ内に表示アクセスポイント（ＲＡＰ）があるかどうかを示す。

【0169】

フラグメントｉ内にＲＡＰがある場合、フラグメントｉに対するＲＡＰ提示時間は、ＥＳＰＴに、ＲＡＰ−ｄｅｌｔａ（ｉ）と、ｊ＜ｉである全てのｊにわたるＤｅｌｔａ（ｊ）の和とを足したものである。

【0170】

バイトオフセットについての情報も含むフラグメント内の複数の主開始点および／または主終了点を示すことを含む、ＭＰＥＧ ＤＡＳＨ規格の他の拡張も可能である。

【0171】

セグメントマップに含まれ得る他の情報は、例えばＡＥＳによって提供されるＣＢＣスタイルのブロック暗号化が使用される場合に復号を助けるために使用され得る情報であり、データの各ブロックは例えば１６バイトであり、ブロックが連鎖的に暗号化され、すなわち、次のブロックを暗号化するために、前のブロックの暗号化されたものはまず、次のブロックとの排他的論理和をとられて新たなブロックを形成し、そして、新たなブロックの暗号化されたものは、次のブロックの暗号化された値となる。従って、前のブロックの暗号化された値は、次のブロックを復号するために必要とされ、すなわち、次のブロックの値は、次のブロックの暗号化されたものを復号し、それと、前のブロックの暗号化された値との排他的論理和をとることによって、形成される。従って、フラグメントの最初の暗号化されたブロックを復号するのに必要な、または、セグメントマップ内のＲＡＰまたはＲＸＰの最初の暗号化されたブロックを復号するのに必要な、以前の暗号化されたブロックに対するバイトオフセットを提供することは、有益である可能性がある。あるいは、セグメントマップ自体において以前の暗号化されたブロックを提供することが、有益である可能性がある。

【0172】

セグメントマップは、関連するセグメントから別個のファイルとして提供されてよく、セグメントマップのＵＲＬは、セグメントファイルのＵＲＬから導出され、例えば、セグメントマップのＵＲＬは、セグメントのＵＲＬの末尾に「．ｓｅｇｍｅｎｔ＿ｍａｐ」が追加されたものである。この変形形態には、セグメントファイルが変更されないので、セグメントマップファイルの存在を認識しないクライアントがその存在の影響を受けないという利点があり、一方セグメントインデックスファイルを認識しそれを利用できるクライアントは、セグメントインデックスファイルをダウンロードし使用して、表示切替の体験を改善できる。

【0173】

別の変形形態として、セグメントマップは、セグメントを拡張するためにセグメントの先頭に追加されてよく、次いでクライアントは、拡張セグメントの短いプレフィックスをダウンロードしてファイルのセグメントマップを取得することによって、セグメントマップをダウンロードできる。この変形形態には、第１の変形形態よりも、管理すべきファイルおよび関連するＵＲＬが少ないという利点があるが、先頭に追加されたセグメントマップを解析または使用するように構成されていない既存のクライアントがある場合には、問題となり得る。別の変形形態として、セグメントマップは、セグメントを拡張するためにセグメントの末尾に追加され得る。他の変形形態として、いくつかのセグメントおよび／または表示のセグメントマップは、１つのファイルに統合され得る。別の変形形態では、１つのセグメントのセグメントマップが、複数のファイルに区分されてよく、これらセグメントマップのＵＲＬは、例えば、テンプレートに基づくＵＲＬの生成を使用して、セグメントのＵＲＬから自動的に導出され得る。この変形形態は、セグメントが多くのフラグメント／ブロックを備える場合、例えば、セグメントが２時間の映画であり、各フラグメントの長さが５００ミリ秒前後である場合には、特に有用であることがある。

【0174】

上記の実施形態の多くの変形形態がある。例えば、フラグメント／ブロック当たり多くとも１つの開始点と終了点とをリストするのではなく、フラグメント当たり複数の開始点および／または終了点がリストされてよい。コンテンツが暗号化される場合、セグメントマップは、後続の部分を復号するための暗号化されたコンテンツのダウンロードをどこで開始するかを示すための、暗号化バイトオフセットを含み得る。例えば、コンテンツがＡＥＳによって提供されるＣＢＣ暗号化を使用して暗号化され、暗号化されたデータの一部分を復号するために、データのストリームにおける暗号化されたデータの以前の部分が必要である場合、セグメントマップは、暗号化されたデータのこれら以前の部分に対するバイトオフセットを提供できる。

【0175】

セグメントマップはまた、ビデオのシームレスな切り替えと再生とを支援するための、クライアントおよび／またはメディアプレーヤに関連する他の情報を含み得る。例えば、表示がオーディオデータを備えるか、またはビデオデータとオーディオデータの組合せを備えるかを示す情報を、セグメントマップに追加することが可能である。また、ＦＥＣ修復セグメントが利用可能かどうかを示すものと、利用可能である場合、ＦＥＣ修復セグメントを使用するためにクライアントによって使用され得るＦＥＣセグメントマップのシグナリングとを追加することが可能である。

【0176】

５．第３のセグメントマップ方法：ＡＬＳストリーミングのためのセグメントマップの生成およびフォーマット
一部のＡＨＳストリーミングシステムでは、セグメントマップを、セグメント自体とは別個のファイルとして生成し提供することが有用である。後方互換性が、一式の論拠を与える。セグメントマップは、何らかの既存のＡＨＳシステム、または今後展開されるＡＨＳシステムに対して、規定も考慮もされていない。後方互換性を保ったまま、セグメントマップによってそのようなシステムを拡張することは、多くの価値をもたらすことができ、すなわち、セグメントマップの利用可能性を利用できる拡張ＡＨＳクライアントに対する、改善された切り替えおよび始動のエンドユーザ体験とネットワーク効率とを提供でき、非拡張ＡＨＳクライアントの性能に対して何ら負の影響を与え得ない。他の論拠は、本開示の他の部分で説明される。このセクションで開示されるセグメントマップは、セグメント自体とは別個のファイルとして説明されるが、これらセグメントマップはまた、セグメントファイルの一部であってよく、例えば、セグメントマップは、セグメントの先頭に追加され、セグメントの末尾に追加され、または、セグメント全体に散りばめられてよい。

【0177】

特定のセグメントについての情報を提供するためのセグメントマップの単純なフォーマットは、セグメントの選択された主開始点および選択された主終了点のリストを含むことであり、選択された主開始点は、セグメント内で開始する、主開始点の全てまたは主開始点の選択されたサブセットであってよく、選択された主終了点についても同様である。従って、セグメントマップにおいて特定のセグメントについての情報を生成し提供するための１つの可能なフォーマットは、次の通りである。

【0178】

ＢＯを、表示のセグメントの始まりに対するバイトオフセットとし、ＡＰＴ（０）＝ＴｅｎｔｒｙＢ（ＢＯ）、ＡＢＯ（０）＝ＢＯ、ＸＰＴ（０）＝ＴｅｘｉｔＢ（ＢＯ）、かつＸＢＯ（０）＝ＢＯとする。ＡＮを、選択された主開始点の数とし、ＸＮを、選択された主終了点の数とする。全てのｉ＝１，…，ＡＮに対して、（ＡＰＴ（ｉ），ＡＢＯ（ｉ））を、バイトオフセットが増加する順序でｉ番目の選択された主開始点とし、同様に、ｉ＝１，…，ＸＮに対して、（ＸＰＴ（ｉ），ＸＢＯ（ｉ））を、バイトオフセットが増加する順序で選択された主終了点の始まりに対するバイトオフセットとする。そして、このセグメントに付随するセグメントマップの部分のフォーマットは、以下の表２に示されるようなデータ構造であり得る。

【表2】

【0179】

表２のセグメントマップ構造の解釈は、次の通りである。Ｔｉｍｅｓｃａｌｅの値は、ＭＰＥＧ ＤＡＳＨ規格について説明された通りである。セグメント内の選択された主開始点ｉのバイトオフセットは、全てのｊ＝０，…，ｉにわたるＡＢＯ（ｊ）の和であり、セグメント内の選択された主終了点ｉのバイトオフセットは、全てのｊ＝０，…，ｉにわたるＸＢＯ（ｊ）の和である。同様に、セグメント内の選択された主開始点ｉの提示時間は、全てのｊ＝０，…，ｉにわたるＡＰＴ（ｊ）の和であり、セグメント内の選択された主終了点ｉの提示時間は、全てのｊ＝０，…，ｉにわたるＸＰＴ（ｊ）の和である。

【0180】

セグメントマップにおいてセグメント内の選択された主開始点と選択された主終了点とを示すための代替的なフォーマットは、次の通りである。

【0181】

６．第４のセグメントマップ方法
Ｌを、組み合わされた、選択された主開始点と選択された主終了点とのリストとし、このとき、点は（バイトオフセット，提示時間）のペアとしてリストされ、点はバイトオフセットが増加する順序でリストされ、このリスト内の開始点および終了点は、それらが同じ（バイトオフセット，提示時間）の値を有する場合、重複していると考えられる。Ｎを、リストＬ内のユニークな点の数とする。全てのｉ＝１，…，Ｎに対して、（ＰＴ（ｉ），ＢＯ（ｉ））を、リストＬ内のｉ番目の点とする。ＢＯを、表示のセグメントの始まりに対するバイトオフセットとし、ＰＴ（０）＝ＴｅｘｉｔＢ（ＢＯ）かつＢＯ（０）＝ＢＯとする。そして、このセグメントに付随するセグメントマップの部分のフォーマットは、表３のリストに示されるようなものであり得る。

【表3】

【0182】

表３のセグメントマップ構造の解釈は、次の通りである。表示タイプは、どのタイプのデータが参照されるセグメントに含まれるかを示し、０は、データがオーディオのみであることを示し、１は、データがビデオのみであることを示し、２は、データがオーディオとビデオの両方の組合せであることを示す。従って、クライアントは、セグメントマップをダウンロードすることで表示タイプを判定できる。Ｔｉｍｅｓｃａｌｅの値は、ＭＰＥＧ ＤＡＳＨ規格について説明された通りである。セグメント内の点ｉのバイトオフセットは、全てのｊ＝０，…，ｉにわたるＢＯ（ｊ）の和であり、セグメント内の点ｉの提示時間は、全てのｊ＝０，…，ｉにわたるＰＴ（ｊ）の和である。一部のファイルフォーマット順序およびフレーム依存構造では、ＰＴ（ｉ）−ＰＴ（ｉ−１）が０よりも小さくなり得ることが可能であり、一方他のファイルフォーマット順序およびフレーム依存構造では、ＰＴ（ｉ）−ＰＴ（ｉ−１）は常に少なくとも０であることに留意されたい。ＲＰ（ｉ）の値は、点ｉが開始点か、終了点か、または開始点と終了点の両方かを示す。

【0183】

上記に対する多くの拡張がある。例えば、セグメントマップは、部分的なセグメントまたは複数のセグメントについての情報を含み得る。セグメントマップは、ＵＲＬと、どのセグメントについての情報をセグメントマップが含むかを示すためのバイト範囲とを含み得る。

【0184】

上で説明された第４のセグメントマップ方法も、ＭＰＥＧ ＤＡＳＨフラグメント構造を決定するために使用され得ることに留意されたい。例えば、各ｉ＝１，…，Ｎに対して、バイトオフセットＢＯ（ｉ−１）で開始しバイトオフセットＢＯ（ｉ）−１で終了するものとして定義されるフラグメントが存在し得る。この場合、各フラグメントの開始および終了は、選択された主開始点、選択された主終了点、または、選択された主開始点と選択された主終了点の両方のいずれかに対応する。

【0185】

ＭＰＥＧ ＤＡＳＨによって使用されるセグメントマップシグナリング方法と協調するために、ファイルフォーマット順序が復号順序である場合、代替的な実施形態が使用され得る。この代替的な実施形態では、各フラグメントが少なくとも１つの主終了点を含むように、すなわち、各ｉ＝１，…，Ｎに対して、ＢＯ（ｉ−１）＜ＢＯ≦ＢＯ（ｉ）である少なくとも１つの主終了点（ＰＴ，ＢＯ）が存在するように、フラグメント構造が形成され、前に説明されたような「ＭＰＥＧ ＤＡＳＨ規格の開始点および終了点のシグナリング」というセグメントマップシグナリング方法が使用され得る。前に説明されたように、この方法のＤｅｌｔａ（ｉ）の値は、フラグメントｉ＋１内の任意のフレームの最早の提示時間と、フラグメントｉ内の任意のフレームの最早の提示時間との差である。従って、フラグメントｉの後の次のフラグメント内のフレームの最早の提示時間は、ＥＳＰＴに、ｊ≦ｉである全てのｊにわたるＤｅｌｔａ（ｊ）の和を足したものである。この場合、「終了点の正しいシグナリングのための２つの条件」は両方とも満たされるので、各フラグメントは終了点を含み、フラグメントｉの後の次のフラグメント内のフレームの最早の提示時間は、フラグメントｉの終わりに関連付けられる提示終了時間である。従って、各フラグメントの終わりは、セグメントマップ内のシグナリング情報に基づいて計算され得る、提示終了時間を有する終了点である。

【0186】

多くの他の拡張および代替形態も可能である。例えば、前に説明されたＭＰＥＧ ＤＡＳＨの代替形態および拡張の全ても、このセクションで説明された実施形態に適用される。例えば、選択された主開始点は、場合によって副開始点を含むように拡張されてよく、選択された主終了点は、場合によって副終了点を含むように拡張されてよい。

【0187】

切替パッチを使用してデータをシグナリングし並べ替えるための方法
いくつかの場合には、より効率的なビデオ符号化を可能にするために、データ依存構造がより複雑であることがあり、ＡＨＳクライアントが、ある表示から出てＳＡＰにおいて第２の表示に参加することは簡単ではないことがある。例えば、前に説明されたように、図１に示されるクローズドＧＯＰ構造はそのような移行を容易にするが、図２に示されるオープンＧＯＰ構造は、そのような移行をより難しくする。開始点および終了点が揃えられた場合の、クローズドＧＯＰ移行とオープンＧＯＰ移行の差の１つの例は、次の通りである。

【0188】

終了点（ＰＴ，ＢＯ）における第１の表示から開始点（ＰＴ’，ＢＯ’）における第２の表示に移行するとき、クローズドＧＯＰでは、提示時間ＰＴとＰＴ’が等しく、これら表示からダウンロードされたコンテンツには重複がなく、２つの表示からのコンテンツは、メディアプレーヤが再生するのに有効なコンテンツを表すように連結でき、シームレスな移行を可能にすることがわかる。クローズドＧＯＰ移行の例として、２つの表示が、図１、図５、および図９に示されるものと同じデータ依存構造とファイルフォーマットとを共有すると仮定する。この場合、図９に示されるように、第１の表示からの移行は、終了点（８，２７５３７)で行われてよく、これは、第１の表示がバイトオフセット２７５３７までダウンロードされ、表示終了時間がフレーム８の再生のすぐ後であることを示す。

【0189】

図５を参照すると、第２の表示への対応する移行は、開始点（９，２７５３７)で行われてよく、これは、第２の表示がバイトオフセット２７５３７においてダウンロードを開始し、表示開始時間がフレーム９の再生と共に開始することを示す。この例では、同じフレームの重複するダウンロードはなく、すなわち、第１の表示からダウンロードされた全てのフレームは、第２の表示からダウンロードされた全てのフレームとは異なる。この例では、第１の表示の終了点のバイトオフセットおよび第２の表示の開始点のバイトオフセットは等しく、それは、これら両方の表示が、同じ表示点および終了点に対してちょうど同じバイトオフセットを有するからであるが、一般的には、移行前後の２つの表示は、異なる品質およびレートで符号化されるので、同じ表示時間に対するバイトオフセットは一般的には等しくない。

【0190】

終了点（ＰＴ，ＢＯ）における第１の表示から開始点（ＰＴ’，ＢＯ’）における第２の表示に移行するとき、オープンＧＯＰでは、提示時間ＰＴとＰＴ’が等しいとは限らず、これら表示からダウンロードされたコンテンツには重複があることがあり、２つの表示からのコンテンツは、メディアプレーヤが再生するのに有効なコンテンツを表すように簡単に連結できない。これら場合には、ＡＨＳクライアントが、メディアプレーヤに対する重複コンテンツをメディアプレーヤに提供する時に、どのコンテンツが重複しているかをメディアプレーヤにシグナリングすることが有用であり、それは、シームレスな方式で重複コンテンツを再生するのに、このことがメディアプレーヤにとって有用であり得るからである。他の場合には、メディアプレーヤは、重複コンテンツがいつメディアプレーヤに提供されるかを理解し、可能な限りシームレスにコンテンツの再生を処理するための、論理と方法とを備える。

【0191】

オープンＧＯＰ移行の例として、２つの表示が、図２、図６（ａ）、および図１０（ａ）に示されるものと同じデータ依存構造とファイルフォーマットとを共有すると仮定する。この場合、図１０（ａ）に示されるように、第１の表示からの移行は、終了点（９，３１０４３)で行われてよく、これは、第１の表示がバイトオフセット３１０４３までダウンロードされること、すなわち、クライアントが示されるファイルフォーマット順序におけるフレーム８まで、フレーム８を含めてダウンロードすることと、提示終了時間がフレーム９の再生のすぐ後であることとを示す。図６（ａ）を参照すると、第２の表示への対応する移行は、開始点（９，２２０３３)で行われてよく、これは、第２の表示がバイトオフセット２２０３３においてダウンロードを開始すること、すなわち、クライアントが示されるファイルフォーマット順序におけるフレーム９でダウンロードを開始することと、提示開始時間がフレーム９の再生と共に開始することとを示す。

【0192】

このオープンＧＯＰの例では、上のクローズドＧＯＰの例とは対照的に、両方の表示が、全体として同じ開始点および終了点に対してちょうど同じバイトオフセットを有していても、両方の表示が、移行の開始点および終了点に対して異なるバイトオフセットを有することに留意されたい。このオープンＧＯＰの例では、この移行においてダウンロードされる重複フレームのセットがあり、すなわち、フレーム９、６、７、および８が、この移行において、各表示に対して１回ずつダウンロードされる。好ましくは、エンドユーザに対する時間的にシームレスな移行の体験を提供するために、フレームのこれらセットのうちの１つのみが、メディアプレーヤによる再生などのためにメディア消費者によって使用される。

【0193】

本明細書では、フレームのこの重複するセットは「重複パッチ(overlap patch)」と呼ばれる。上の例では、各重複パッチは、３１０４３−２２０３３＝９０１０バイトである。いくつかの例では、バイトの数は、ある表示の重複パッチと別の表示の重複パッチとでは異なり得る。しかしながら、この例では、これらは同じである。クライアントは次いで、２×（３１０４３−２２０３３）＝１８０２０バイト、すなわち２つの表示の重複パッチをダウンロードし、これら重複パッチのうちの１つのみを使用して、フレーム６、７、８、および９とを再生する。従って、この例では、９０１０バイトのオーバーヘッドがある。

【0194】

一般に、移行の前後の２つの表示は、通常は異なる品質およびレートで符号化されるので、同じ提示時間に対するバイトオフセットは一般に等しくなく、従って、重複パッチのためにダウンロードされたバイトの総数、すなわち２つの表示の各々における重複パッチのバイトサイズの合計は、必ずしも２倍ではない。重複パッチから再生されるフレームのサイズは、メディアプレーヤが、ある表示から、重複パッチ内のフレームのうちの他の表示へと再生を移行することを、どのように決めるかに依存し得る。

【0195】

オープンＧＯＰデータ依存性と他のより高度なデータ依存構造とを使用する時の、シームレスな移行の効率性と簡易性とを拡張するために、本明細書で説明されるいくつかの方法が使用され得る。第１は、例えばセグメントマップ内で、重複パッチ構造をシグナリングするための方法、すなわち、ある表示から別の表示に切り替えるために使用され得る、または、表示内における開始点でコンテンツの再生を開始するために使用され得る、または、表示の終了点でコンテンツの再生を停止するために使用され得る、可能な重複パッチに対応する開始点と終了点のペアをシグナリングするための方法である。

【0196】

セグメントマップ内で重複パッチをシグナリングするための可能なフォーマットが、様々なフォーマットでクライアントに伝えられ得るデータ構造として、表４に示される。

【表4】

【0197】

クライアントは次いで、セグメントマップからのこのデータ構造を解釈して、重複パッチがどこで発生しているかを判定する。この例示的なデータ構造では、Ｔｉｍｅｓｃａｌｅの値は、ＭＰＥＧ ＤＡＳＨ規格に対して説明された通りであり得る。ＯＰの値は、このセグメントマップにおいてシグナリングされる重複パッチの数である。タイプフィールドは、重複パッチがシグナリングされていることをシグナリングする。ペア（ＡＰＴ（ｉ），ＡＢＯ（ｉ））は、ｉ番目の重複パッチの開始点であり、ペア（ＸＰＴ（ｉ），ＸＢＯ（ｉ））は、ｉ番目の重複パッチの終了点である。

【0198】

上記のシグナリング方法には多数の変形形態が存在する。例えば、重複パッチのシグナリングは、セグメントマップ内で、他のＳＡＰ、開始点、および終了点のシグナリングと共に、シグナリングされ得る。別の例として、シグナリングの厳密な詳細は変化し得る。

【0199】

別の変形形態として、ＯＰの値は一定でありシグナリングされなくてもよい。例えば、セグメントのセグメントマップがセグメントの先頭に追加され、セグメント当たり１つのみの重複パッチがあるということがあってよく、セグメントは、開始点で開始し終了点で終了する。この場合、ＯＰの値は１である。別の変形形態として、重複パッチのシグナリングは、セグメントマップ内の別のフラグによってシグナリングされてよく、フラグが０に設定されている場合、セグメントにおいてシグナリングされる重複パッチはなく、フラグが１に設定されている場合、セグメント内でシグナリングされるちょうど１つの重複パッチがある。

【0200】

既存のＭＰＥＧ ＤＡＳＨプロファイルの一部では、適応セットの異なる表示の間でＳＡＰ整列が存在する。ＭＰＥＧ ＤＡＳＨまたは他のＡＨＳ技法の標準的なプロファイルの変形形態では、適応セットの異なる表示の間での重複パッチの整列の、または一般的には、異なるビットレートおよび品質で同じコンテンツを表すグループの間での重複パッチの整列が、所与のプロファイルに対してシグナリングされるか常に真であるかのいずれかであり得る場合、プロファイルは許容され得る。異なる表示の間での重複パッチの整列とは、かなりの部分または全ての重複パッチに対して、特定の表示が開始点（ＡＰＴ，ＡＢＯ）を有するシグナリングされる重複パッチと対応する終了点（ＸＰＴ，ＸＢＯ）とを有する場合、適応セットまたはグループ内の他の表示も、形式（ＡＰＴ，ＡＢＯ’）の開始点と形式（ＸＰＴ，ＸＢＯ’）の終了点とを有するシグナリングされる重複パッチを有すること、すなわち、開始点である提示開始時間と終了点である提示終了時間とが一致することを意味する。バイトオフセットは一致する必要はなく、一致しないことが多いことに留意されたい。

【0201】

シグナリングされる重複パッチを表示の間で揃えていることは、ＡＨＳクライアントにとって非常に有益であり得る。例えば、これによって、ＡＨＳクライアントは、第１の表示のセグメントマップ情報から、現在の第１の表示から別の第２の表示へ切り替えるための戦略、すなわち、第２の表示のダウンロードを開始する提示開始時間と、第１の表示の提示終了時間とを決定することが可能になる。このことは有益であることがあり、それは、ＡＨＳクライアントが、どの提示時間において切り替えを行うかを決定するために、第２の提示のセグメントマップ情報をダウンロードまたは入手するのを避けることができるからである。別の利点は、ＡＨＳクライアントが、第２の表示から情報をダウンロードする前でも、重複パッチの提示開始時間と提示終了時間とをメディアプレーヤにシグナリングでき、従って、重複コンテンツについてのヒントを前もってメディアプレーヤに提供できることである。

【0202】

実施形態では、メディアコンテンツのソースは、重複パッチと共にセグメント内のデータを配置するように構成されてよく、クライアントは、存在するかどうかにかかわらず、重複パッチの存在を仮定してデータを処理するように構成されてよい。いくつかの実施形態では、そのようなソースは、重複パッチを認識または認知しないクライアントによって使用され得る。

【0203】

同じ適応セットまたはグループにおける表示の間での重複パッチの整列のための１つの可能な方法は、異なる表示の間で整列されたセグメントを有することと、重複パッチであるセグメント、すなわち、重複パッチの開始点のバイトオフセットで開始し、重複パッチの終了点のバイトオフセットで終了するセグメントを表示内に有することであり、すなわち、（ＰＴ，ＢＯ）が重複パッチの開始点であり（ＰＴ’，ＢＯ’）が重複パッチの終了点である場合、セグメントは、表示内におけるバイトオフセットＢＯで開始し、表示内におけるバイトオフセットＢＯ’で終了する。

【0204】

重複パッチと一致するセグメントも、重複パッチを備えるセグメントとしてシグナリングされ得る。この場合、ＡＨＳクライアントが第１の表示から第２の表示への移行を望む場合、ＡＨＳクライアント方法は、例えば開始点（ＡＰＴ，ＡＢＯ）と終了点（ＸＰＴ，ＸＢＯ）とを有する重複パッチであるセグメントを、第１の表示において見出し、ＸＢＯ−ＡＢＯバイトのコンテンツ備えるそのセグメントをダウンロードし、第２の表示における対応する重複パッチであるセグメント、すなわち、開始点（ＡＰＴ，ＡＢＯ’）および終了点（ＸＰＴ，ＸＢＯ’）に対応する第２の表示からのＸＢＯ’−ＡＢＯ’バイトのコンテンツを有する第２の表示におけるセグメントをダウンロードし、提示時間間隔ＡＰＴからＸＰＴのうちで、第１の表示から第２の表示への移行を行うようにメディアプレーヤにシグナリングすることであり得る。

【0205】

別の変形形態は、重複パッチが完全にセグメント内に完全に含まれるように制限し、セグメント内の重複パッチの位置をシグナリングすることである。この変形形態は、例えば、セグメント期間が重複パッチの期間よりも全般にはるかに長い場合、例えば、オンデマンドコンテンツでは、表示当たり１セグメントしか存在し得ない場合、または、ライブコンテンツでは、セグメント期間が数秒であり得る一方で重複パッチ期間が数十ミリ秒または数百ミリ秒であり得る場合に、好ましいことがある。この場合、ＡＨＳクライアントが第１の表示から第２の表示に移行する時、ＡＨＳクライアントは、第１の表示における重複パッチの終わりで終了する第１の表示におけるセグメントをダウンロードし、第２の表示における重複パッチの始まりで開始する第２の表示におけるセグメントをダウンロードでき、これによって、再生されるべきではないこれらセグメントの他の部分のダウンロードを避ける。

【0206】

上で説明されたように、いくつかの冗長なコンテンツおよび／または使用されないコンテンツが、重複パッチに基づいて要求され送信され得る。従って、第１の表示から第２の表示に切り替える時、コンテンツの２つの異なるバージョンが重複パッチにおいてダウンロードされ、また、メディアプレーヤは、重複パッチ内のコンテンツの各部分の２つのバージョンのうちの１つのみを再生するので、冗長なコンテンツがダウンロードされる。従って、重複パッチサイズが最小になるようにデバイスを構成することには、良い理由がある。

【0207】

クライアントが、重複パッチの開始点で開始する表示からのコンテンツを再生し始めている場合、または、重複パッチの終了点で終了する表示からのコンテンツの再生を終了しつつある場合にも、重複パッチサイズが小さいことに利益があり、それは、上記のいずれの場合でも、決して再生されないコンテンツがダウンロードされることがあるからである。

【0208】

例えば、図２と、図６（ａ）と、図１０（ａ）とを再び参照して、示されるファイルフォーマット順序におけるフレーム９と、６と、７と、８とを備える重複パッチを考える。この重複パッチにおいて表示を切り替える時、フレーム９、６、７、および８は２回、すなわち第１の表示に対して１回、第２の表示に対して１回ダウンロードされる。この重複パッチの開始点を使用して再生を開始するとき、すなわち、フレーム９において再生を開始するためにフレーム９の始まりにおいてダウンロードを開始するとき、フレーム６、７、および８は、ダウンロードされないフレーム５にも依存するので、ダウンロードされるが再生できない。

【0209】

重複パッチのサイズと期間とを最小にするために、復号順序とは限らない他のファイルフォーマット順序を考えることが有用である。次の方法を考える。サーバが、復号順序ではなく提示順序としてファイルフォーマット順序を使用して、セグメントを形成する。セグメントに関連付けられるセグメントマップ内のシグナリングは、セグメント内のコンテンツを復号順序へとどのように並べ替えるかをシグナリングできる。ＡＨＳクライアントは、セグメントまたはセグメントの部分をダウンロードし、受信されたコンテンツを復号順序へと並べ替え、コンテンツを復号順序でメディアプレーヤに提供できる。このことは、ＡＨＳクライアントが、コンテンツの部分をメディアプレーヤに提供する前に、コンテンツの部分を場合によって並べ替えることを必要とするが、いくつかの場合には、メディアプレーヤは、コンテンツを復号順序で受信する必要はないことがある。また、ＡＨＳクライアントは、復号順序でコンテンツをメディアプレーヤに提供するために、コンテンツをメディアプレーヤに提供する前にわずかにより多くのコンテンツをバッファリングする必要があり得る。しかしながら、この方法には多くの利点がある。

【0210】

この例では、ファイルフォーマット順序が提示順序であるという指示が、例えばＭＰＤにおいてシグナリングされ得る。ファイルフォーマット順序が提示順序であることをシグナリングされた表示に対して、主開始点および主終了点および復号順序が、シグナリングされた各フレームに対して次のフォーマットを使用してシグナリングされ得る。

【数1】

【0211】

上式において、ＳＢＯはファイルフォーマット順序におけるフレームの開始バイトオフセットであり、キーワード「ｓｔａｒｔ＿ＢＯ」によって開始バイトオフセットであるものとしてシグナリングされる。同様に、ＥＢＯは、フレームの終了バイトオフセットであり、キーワード「ｅｎｄ＿ＢＯ」によってそのようなものとしてシグナリングされる。キーワード「ｄｅｃｏｄｅ＿ＢＯ」によってシグナリングされるＤＢＯは、フレームを復号順序にするためにこのフレームが挿入されるべきである、ファイルフォーマット順序におけるバイトオフセットである。任意選択のキーワード「ｅｎｔｒｙ」は、フレームの始まりが開始点である場合に含まれ、同様に任意選択のキーワード「ｅｘｉｔ」は、フレームの終わりが終了点である場合に含まれる。

【0212】

例として、図２に示されるフレーム依存構造を考えるが、代わりに、ファイルフォーマット順序が復号順序ではなく提示順序であり、すなわち、ファイルフォーマット順序が図６（ｂ）および図１０（ｂ）に示されるようであると仮定する。そして、この例の上で説明されたシグナリングは次のようであり得る。

【数2】

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

セグメントマップによるセグメントの参照の方法
Ｍを、セグメントマップによって参照される（部分的なまたは完全な）セグメントファイルの数とする。ｉ＝１，…，Ｍに対して、ＵＲＬ（ｉ）を、提示時間の順序で並べられた、セグメントマップにおいて参照されるｉ番目のセグメントファイルのＵＲＬとし、ＢＳ（ｉ）およびＢＥ（ｉ）をそれぞれ、バイト範囲の開始バイトオフセットおよび終了バイトオフセットとし、セグメントマップは、このバイト範囲についての情報を、ｉ番目のセグメントファイルに対して含む。そして、これらセグメントを参照するためのセグメントマップフォーマットは、表５のようであってよい。

【表5】

【0243】

上式は、ｉ＝１，…，Ｍに対する、ＵＲＬ（ｉ）を伴うセグメントのバイト範囲ＢＳ（ｉ）からＢＥ（ｉ）の連結物である「仮想セグメント(virtual segment)」を定義する。この「仮想セグメント」についてのセグメントマップ内の点の詳細なリストは、例えば、第４のセグメントマップ方法で説明されたフォーマットであってよく、リストされた点のバイトオフセットは、この仮想セグメントに関して計算される。従って、例えば、セグメントマップ内の２つの連続する点の間の仮想セグメントデータの部分が、部分的に一方のセグメント内にあり、部分的にもう一方のセグメント内にあるということがあり得る。ＢＳ（ｉ）とＢＥ（ｉ）の１つまたは両方が、例えば、値の欠損を示すものとして−１を使用して、ｉの値の全てまたは一部に対する範囲から省略されてよい。例えば、［−１，ＢＥ（ｉ）］は、セグメントの始まりからバイトオフセットＢＥ（ｉ）までの、ＵＲＬ（ｉ）によって参照されるセグメントを示し、［ＢＳ（ｉ），−１］は、バイトオフセットＢＳ（ｉ）からセグメントの終わりまでの、ＵＲＬ（ｉ）によって参照されるセグメントを示し、［−１，−１］は、ＵＲＬ（ｉ）によって参照されるセグメント全体を示す。

【0244】

セグメントマップファイルは、一定のまたは予測可能な提示時間スパンに対して利用可能にされ得る。例えば、０ｍｏｄｕｌｏ１０秒に等しい可能性のある各提示開始時間スパンに対するセグメントマップファイルが存在することを示す、提示時間スパン規則が存在してよく、すなわち、セグメントマップファイルの提示開始時間は、コンテンツの終わりまで（終わりがあれば）、０秒、１０秒、２０秒、３０秒、４０秒、５０秒などであり、各セグメントマップファイルの提示時間スパンの長さは２０秒である。この場合、ｍｏｕｓｅ＿１６５４３として識別され得るコンテンツに対し、ｒｅｐ＿３８９３４として識別され得るそのコンテンツの表示について、セグメントマップのＵＲＬのシーケンスは次の通りであり得る。

【数3】

【0245】

この例では、提示時間スパンに対する規則を仮定すると、セグメントマップファイルのＵＲＬは、コンテンツ識別子ｍｏｕｓｅ＿１６５４３および表示識別子ｒｅｐ＿３８９３４から決定されてよく、ｓｅｇ＿ｍａｐは、ファイルをセグメントマップとして識別する。

【0246】

別の代替形態として、セグメントマップファイルは、２つ以上の表示に対するマッピング情報を含み得る。例えば、セグメントマップファイルは、コンテンツの全ての表示についてのマッピング情報を含み得る。この場合、代替的な可能なセグメントマップのＵＲＬのフォーマットは、「ｃｏｎｔｅｎｔ＿ＩＤ．ＳＰＴ＿Ｘ．Ｄｕｒ＿Ｙ．ｓｅｇ＿ｍａｐ」であり、「ｃｏｎｔｅｎｔ＿ＩＤ」はコンテンツを識別し、「ＳＰＴ＿Ｘ」はスパンの提示開始時間がＸであることを識別し、「Ｄｕｒ＿Ｙ」はスパンの提示終了時間がＸ＋Ｙであることを識別し、「ｓｅｇ＿ｍａｐ」はこれをセグメントマップとして識別する。セグメントマップファイル内に含まれるマッピング情報の実際の提示時間スパンが、規定された提示時間スパンと完全に一致することは必要とされず、例えば、セグメントマップファイル内の各表示のためのマッピング情報が、Ｘ−ｄからＸ＋Ｙ＋ｅまでの提示時間をカバーし、ｄおよびｅが提示時間の小さな正の増分であるということがあり得ることに留意されたい。この場合、セグメントマップファイルは、コンテンツの複数の表示のための、セグメント、セグメントの部分、または複数のセグメントを参照し得る。

【0247】

上記の実施形態では、セグメントマップファイルのＵＲＬは、コンテンツおよび表示のための何らかの基本ＵＲＬから導出されてよく、セグメントマップファイル内のマップ情報は、ある一定の（大まかに一定、丸めは許容される）長さの提示時間、例えば、提示時間の開始の秒数および終了の秒数、または、提示時間の開始の秒数および長さの秒数、または、提示時間の開始の「ティック(ticks)」および長さの「ティック」で表される提示時間スパンをカバーし得る。「ティック」という単位が提示時間を表すために使用されることがあり、「ティック毎秒」が表示に関連する時間の単位である。各表示の「ティック単位」は、セグメントマップファイルに含まれ得る他の情報の例である。例えば、毎秒３００００ティックは、各ティックが１秒の１／３００００の部分であることを示す。上記の各場合において、提示時間スパンは、提示の始まりからの、または何らかの他の一定の基準時間までの、時間の累積的な尺度を使用して示される。

【0248】

セグメントタイムラインファイルを使用する方法
このセクションにおいて説明される方法は、以前の方法に基づくが、ＭＰＥＧ ＤＡＳＨ規格の変更の量がより少ない全体の構造を提供し、好ましい全体的な解決法を提供できる。

【0249】

今後「セグメントタイムライン(segment timeline)」ファイルと呼ばれる、上で説明されたセグメントマップの特徴の一部を有する新たなタイプのファイルが、導入され得る。セグメントタイムラインファイルのＵＲＬは、セグメントマップについて上で説明されたものと同様に、提示時間の長さに基づいてＵＲＬ構築規則を使用して生成されてよく、例えば、可能なフォーマットは、「ｃｏｎｔｅｎｔ＿ＩＤ．ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤ．Ｄｕｒ＿Ｘ．ＥＰＴ＿Ｙ．ｓｅｇｍｅｎｔ＿ｔｉｍｅｌｉｎｅ」であり、「ｃｏｎｔｅｎｔ＿ＩＤ」および「ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤ」はそれぞれコンテンツおよびコンテンツの表示を識別し、「Ｘ」はセグメントタイムラインによってカバーされる提示時間スパンの概略的な長さであり、「Ｙ」は提示時間スパンの概略的な提示終了時間であり、「ｓｅｇｍｅｎｔ＿ｔｉｍｅｌｉｎｅ」はファイルをセグメントタイムラインファイルとして識別する。セグメントタイムラインファイルの存在、およびセグメントタイムラインファイルに対するＵＲＬ構築規則は、ＭＰＤ内でシグナリングされてよく、例えば、構築規則は、１０秒の倍数からコンテンツの長さまでのＹの全ての値に対するファイルが存在し、かつＸ＝３０であることを規定でき、ＸおよびＹの値は単位が秒である。

【0250】

セグメントのＭＰＥＧ ＤＡＳＨフォーマットおよびセグメントのセグメントマップは、ＩＳＯファイルフォーマットにおいてセグメントのために使用されてよく、すなわち、セグメントマップ（Ｓｉｄｘ）は、セグメントの先頭に追加され、そのセグメントで搬送されるデータの提示時間の長さをカバーする。ＭＰＥＧ２ＴＳファイルフォーマットでは、セグメントマップ（Ｓｉｄｘ）は、ＭＰＥＧ ＤＡＳＨ規格において説明されるフォーマットで、セグメントとは別個のファイル内にあり、セグメントＵＲＬから導出されるＵＲＬを伴う、セグメント当たり１つのセグメントマップがある。セグメントのＵＲＬおよびセグメントマップ（これらが異なるファイル内にある場合）は、ＭＰＥＧ ＤＡＳＨ規格における既存のＵＲＬ構築規則を使用してシグナリングされることが推奨され、連続するセグメント（または別個のファイルとして搬送される場合はセグメントマップ）は、順番にインデックスを付されたＵＲＬを有することが推奨され、すなわち、セグメントのＵＲＬは、「ｃｏｎｔｅｎｔ＿ＩＤ．ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤ．Ｉｎｄｅｘ＿Ｘ．ｓｅｇｍｅｎｔ」と同様のパターンに従ってよく、Ｘの値のシーケンスは、例えば０、１、２、３、４などであり、すなわち、提示時間において順次的であるセグメントに対する連続的な整数である。従って、セグメントのＵＲＬは、提示時間内のセグメントのシーケンスを示すが、シーケンスにおける異なるセグメントの長さは表示内において変動してよく、また、異なる長さであってよく、複数の表示の間で変動してよい。従って、セグメントマップのＵＲＬに割り当てられるインデックスは、提示時間スパンの順序に関して順次的であってよく、セグメントマップのＵＲＬに割り当てられるインデックスは、提示時間スパンの長さに依存しない。代替形態として、ＵＲＬは、ＡＬＳシステムのための既存のＡＬＳのようにシグナリングされてよく、対応するセグメントマップのＵＲＬは、セグメントマップが関連するセグメントのＵＲＬから、簡単な規則によって導出されてよく、例えば、セグメントマップのＵＲＬは、「．ｓｅｇ＿ｍａｐ」が末尾に追加された関連するセグメントのＵＲＬであり得る。

【0251】

セグメントタイムラインファイルに関するセグメントのセットは、セグメントタイムラインファイルがカバーする提示スパンと重複する提示時間スパンをカバーする、セグメントのセットであると定義される。例えば、セグメントタイムラインファイルのＵＲＬが、「ｃｏｎｔｅｎｔ＿ＩＤ．ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤ．Ｄｕｒ＿１５．ＥＰＴ＿６０．ｓｅｇｍｅｎｔ＿ｔｉｍｅｌｉｎｅ」である場合、そのＵＲＬは、提示時間４５で開始し提示時間６０で終了する１５秒の提示時間スパンの長さをカバーするので、４５秒から６０秒の期間内に提示開始時間または提示終了時間を有する全てのセグメントは、セグメントタイムラインファイルに関連すると言われる。セグメントタイムラインファイルに関連するセグメントマップの同様の定義を行うことができ、この定義は、提示時間の副範囲およびバイトの副範囲によって定義されるセグメントの部分またはセグメントマップを含むように拡張され得る。

【0252】

セグメントタイムラインファイルは、セグメントタイムラインファイルに関連する、ＵＲＬのリストとセグメントの提示開始時間（別個のファイルとして搬送される場合、セグメントマップも）とを含み得る。あるいは、セグメントタイムラインファイルは、セグメントＵＲＬを構築するもとになり得る情報、例えば、セグメントのインデックスの範囲を含んでよく、例えば、インデックスは、ＭＰＤ内のセグメントに対するＵＲＬセグメント構築規則によって暗黙的に定義されるものに由来する。

【0253】

ＭＰＤはまた、最大セグメント提示時間スパンＴＳｍａｘを規定でき、Ｔｉｍｅｓｃａｌｅも規定でき、Ｔｉｍｅｓｃａｌｅは、セグメントタイムラインのＵＲＬにおいて提示時間を表すために使用され得る。最大セグメント提示時間スパンＴＳｍａｘは、任意のセグメントの提示開始時間と、そのセグメントの前のセグメントの提示開始時間との差が大きくともＴＳｍａｘとなるように、定義され得る。例えば、ＴＳｍａｘ＝２秒である場合、セグメントｉの提示開始時間と、提示時間の順序ですぐ前にあるセグメントｉ−１の提示開始時間との差は、大きくとも２秒である。

【0254】

代替形態として、セグメントタイムラインファイルはまた、セグメントマップ、またはセグメントの提示終了時間、または他の関連情報を含み得る。

【0255】

セグメントタイムラインファイルの指示は、ＡＬＳシステムによっても使用されてよく、ＵＲＬの導出元の提示時間スパンは、例えば一定の長さを有し一定の提示終了時間にあり、例えば、提示終了時間は各々１０秒でありスパンの全てが２０秒の長さを有し、または、提示終了時間および長さは、一定の規則を使用してＡＬＳメタデータによって通知されるセグメントの長さから導出されてよく、例えば、セグメントの通知された長さがＴ秒である場合、セグメントタイムラインファイルは各々Ｔ秒で終了してよく、各々が２×Ｔの長さを有する。

【0256】

セグメントマップファイルとセグメントタイムラインファイルとを使用するためのクライアント方法
セグメントマップファイルの１つの利点は、セグメントマップファイル無しに、クライアントがセグメントのセグメントマップ構造、例えば有効な開始点および終了点を実質的に決定できないことであり、これは、そのような情報がセグメント自体内で直接与えられないからである。そのようなセグメントマップ情報は、場合によってセグメントから導出され得るが、通常は、この情報を導出するためにセグメントがクライアントによってダウンロードされる必要があり、この情報は、メディアデータの構造を決定するためにメディアデータ自体がダウンロードされる必要があるので有効ではないことがあり、セグメントマップ情報を決定する主な目的の１つは、セグメントのどの部分をダウンロードするかを決定することである。さらに、セグメントマップ情報が導出され得る場所のクライアントアーキテクチャは通常、クライアントの表示選択方法の部分とは隔離されており、すなわち、セグメントマップ情報がクライアントによって導出され得る場所は、メディアが再生される場所に近いクライアントのメディア処理部分の奥深くにあり、一方、クライアントのクライアント表示選択部分は、メディアがネットワークを通じてクライアントに入る場所に近く、通常、クライアントのこれら２つの部分の間には良好なインターフェースがない。また、セグメントは暗号化され得るもので、マップ情報が導出され得るよりも前にセグメントが復号される必要があり、これは通常、表示選択論理と対話しないクライアントの隔離された部分にあるので、問題を悪化させる。

【0257】

さらに、セグメントファイルがメディアデータを含む提示時間の長さは正確にシグナリングされないことがあり、例えば、ＡＬＳでは、各セグメントが１０秒の長さとしてシグナリングされる場合、各セグメントは実際には、最も近い秒への丸めが原因で、９．５秒と１０．５秒との間のどこかにあることがある。ＡＬＳ／ＨＬＳ規格では、セグメントの長さのみがシグナリングされるので、累積提示時間はシグナリングされず、クライアントは、最大で１００秒の誤差、すなわち、２００個のセグメントにわたる最大で２００×０．５秒の累積推定誤差を有する、２００番目の連続セグメントに対する、セグメント開始提示時間の推定を行い得る。さらに、コンテンツの符号化およびセグメントファイルへのセグメント化は、各表示に対して異なる長さを有する各ＡＬＳ表示に対して、独立に実行されることがある。異なる表示のセグメントの長さは、ＡＬＳでは異なり得るので、これは、ある表示に長期間とどまった後で、ある表示から別の表示に切り替えようとする時に、特に問題となる。それは、切り替え先の表示において正しい提示時間を伴うセグメントを決定することが難しく、正しいセグメントを決定することは、いくつかの試行的なセグメントをダウンロードすることと、それらの提示時間を決定するためにそれらを詳しく調査する必要性とを伴い得るからである。当業者が認識するように、これら問題は、再生されないデータをダウンロードすること、再生されるべき次のメディアの部分をどのセグメントが含むかを決定するためにセグメントをダウンロードする間にメディアバッファ内の再生可能なメディアが完全になくなることによる、詰まり、再バッファまたはストールのようなユーザ体験の問題を引き起こすこと、および、開始点および終了点についての情報を有さないことにより、ある表示から別の表示へのシームレスな切り替えを提供しないことなどに関する、大きな非効率性をもたらし得る。これら問題および関連する問題の少なくとも一部は、表示の切り替えを試みないクライアントでも起こり得る。

【0258】

上で説明された実施形態では、クライアントは、暗黙的なＵＲＬ構築およびアクセスの規則を使用してセグメントマップにアクセスでき、例えば、クライアントは、コンテンツのために取得されたメタデータから、「ｃｏｎｔｅｎｔ＿ＩＤ」と「ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤ」とを生成し、次いで、セグメントマップに対して可能な提示開始時間の期間は何かということについての提示スパン規則へのアクセス権を有し、例えば、提示スパン規則は、０、１０、２０、３０、４０、…、およびセグメントマップに対して可能な長さの期間、というパターンに従い、例えば、常に２０である。このことから、クライアントは、セグメントマップのＵＲＬを形成してそれを要求でき、これによって、本明細書で開示される切替方法と高速始動方法に関連する方法とを実施する時に、どのセグメントをダウンロードしセグメントのどの部分をダウンロードするかを決定するために使用され得るマッピング情報を取得できる。セグメントマップファイル提示時間スパンが同様である場合、クライアントは、ある時間スパンの長さの間にある表示から別の表示にどのように切り替えるかを決めるために、異なる表示に対するセグメントマップファイルの同じ提示時間スパンを要求できる。しかしながら、セグメントマップファイルの提示時間スパンが異なる表示に対して異なる場合でも、基本的には同じ利点が提供される。あるいは、セグメントマップファイルが２つ以上の表示についての情報を含む場合、クライアントは、同じセグメントマップファイルからの表示の全てに対する、同じ提示時間スパンマッピング情報に関連する情報とにアクセスできる。また、セグメントマップの提示時間スパンは、例えば上の例のように重複していることがあるので、クライアントは境界条件に至らず、例えば、提示時間内の２０秒前後で切り替えが起きるべきであるとクライアントが決定し、セグメントマップファイルの時間スパンが０〜１０秒、その次が１０〜２０秒、その次が２０〜３０秒などである場合、クライアントは、１０〜２０秒にわたるセグメントマップファイルと、さらに、２０〜３０秒にわたるセグメントマップファイルとをダウンロードする必要があり得る。一方、各々１０秒で開始するが各々２０秒にわたるセグメントマップファイルもある場合は、クライアントは、例えば１０〜３０秒にわたるセグメントマップファイルをダウンロードし、２０秒という目標の提示時間の前と後の両方のマッピング情報をファイルが含んでいることを確実にでき、これは、時間スパンが重複しない場合と比べて、時間スパンが重複する場合はこの例では２倍のセグメントマップファイルを有することと引き換えである可能性がある。一般に、マッピング情報はメディアコンテンツデータ自体と比較すると概ね小さいので、提示時間スパンが重複するのが好ましいことが多い。さらに、重複ははるかに小さくてよく、例えば、連続するセグメントマップファイルは、１０秒の間隔で開始する期間をカバーし、各々のスパンは１１秒であり、この場合、連続するセグメントマップの間の重複は１秒である。

【0259】

これら実施形態は、既存のＡＬＳクライアントが負の影響を受けず修正されることなく動作できるように、既存のＡＬＳコンテンツの生成を拡張するために使用され得る。上で説明されたように具現化される追加の処理が、上で説明されたような関連するＵＲＬを伴うセグメントマップファイルを生成し、例えばＨＴＴＰ１．１を使用してＵＲＬに基づいてアクセスするコンテンツ配信ネットワークにおいて、これらセグメントマップファイルを利用可能にするために、ＡＬＳシステムに加えられ得る。本明細書で説明される方法と処理とを伴う拡張クライアントは、表示のセグメントマップファイルのための適切なＵＲＬを形成し、適切なセグメントマップファイルを要求し、これらセグメントマップファイルを使用して始動および切替選択の方法を案内し、より良好なユーザ体験を提供できる。これら拡張クライアント方法は、簡単な方法でマッピング情報を使用でき、例えば、クライアントはそれでも、バイト範囲要求を伴わずにＨＴＴＰに基づいてセグメントファイル全体をダウンロードできるが、切り替えのための適切な開始点と終了点とを伴う切り替えのための正しい提示時間を有する、ダウンロードすべき正しいセグメントを、セグメントマップファイルから正確に決定することが少なくとも可能であり得る。ＨＴＴＰバイト範囲要求がサポートされる場合、より高度なクライアントは、セグメントマップファイルに含まれるマッピング情報をより効率的に使用して、例えば、表示を切り替える時、またはコンテンツ内の規定された提示時間で開始する時に、ＡＬＳセグメントのどの部分をダウンロードするかを厳密に選択することによって、表示の切り替えと高速な始動とを可能にし得る。

【0260】

拡張ＡＨＳクライアントは、そのようなセグメントマップが所与のコンテンツに対して利用可能であるという明示的なシグナリングを何ら伴わずに、セグメントマップファイルをダウンロードするのを試みることができる。セグメントマップが利用可能ではないコンテンツでは、クライアントのダウンロード要求は失敗し、例えば、ＨＴＴＰ応答は、例えば「ＨＴＴＰ ｅｒｒｏｒ ４０４−ｆｉｌｅ ｎｏｔ ｆｏｕｎｄ」を返し、この例では、拡張ＡＨＳクライアントは、セグメントマップがこのコンテンツでは利用可能ではないと推測し、非拡張ＡＬＳクライアントの挙動に戻ることができる。

【0261】

本明細書で説明されるシステムおよび方法の拡張は、セグメントマップが特定の各コンテンツに対して利用可能かどうかを、各コンテンツに対して、例えばＭＰＥＧ ＤＡＳＨ ＭＰＤメタデータファイルにおいて明示的に示すことである。この場合、拡張ＡＨＳクライアントは、これを使用してセグメントマップが利用可能かどうかを判定できるので、例えば、セグメントマップに対するＨＴＴＰ要求をそれが利用可能ではない場合に行い、「ｆｉｌｅ ｎｏｔ ｆｏｕｎｄ」応答を受信するという余分なオーバーヘッドを避けることができる。この場合、拡張ＡＨＳクライアントは、セグメントマップが利用可能ではない場合、非拡張ＡＬＳクライアント方法と論理とを直ちに使用できる。さらに、セグメントマップが利用可能であると示されるが、何らかの理由でセグメントマップの全てが利用可能ではない（例えば、全体のコンテンツ配信ネットワークの一部における何らかの障害により）場合、拡張ＡＨＳクライアント方法は、「ｆｉｌｅ ｎｏｔ ｆｏｕｎｄ」応答が何らかの要求に対して返ってきた場合に何をすべきかを知っているという意味でより堅牢(robust)であり得る。すなわち、一部のセグメントマップが利用可能ではない場合でも、他の表示および期間に対する他のセグメントマップは依然として利用可能であり得ると共に、拡張ＡＨＳクライアントは利用可能であり得るセグメントマップを依然として要求し続け得る。

【0262】

別の可能な拡張は、背後にあるフレーム依存構造およびファイルフォーマット順序、すなわち、良好に選択された開始点における開始セグメントおよび良好に選択された終了点における終了セグメントなどとより良好に揃うように、セグメント構造を生成することである。例えば、セグメントは、ある主開始点から次の連続する主開始点にわたるように構築され得る。セグメントマップファイルはそれでも、セグメントファイルの時間スパンとは独立である、時間スパンの規則的なパターンを有し得る。これによって、ＨＴＴＰ１．１バイト範囲要求の使用の大部分または全てを回避でき、それでも、開始点で開始し終了点で終了する部分における表示からコンテンツをダウンロードできるという利益を受けることができる、セグメントをダウンロードするための拡張ＡＨＳクライアント向けの簡単なアルゴリズムを提供する。ＨＴＴＰバイト範囲要求は広くサポートされないことがあるので、上記のことは有利であり得る。

【0263】

セグメントマップは、他の関連情報も含み得る。例えば、セグメントマップは、特定の表示がオーディオのみか、オーディオとビデオの組合せか、またはビデオのみかを示し得る。別の例として、セグメントマップは、ＦＥＣ修復セグメントのＵＲＬと、ＦＥＣ修復セグメントのセグメントマッピング情報、例えば、Ｌｕｂｙ Ａ４で開示されるフォーマットまたは同様の代替的なフォーマットのセグメントマッピング情報とを含み得る。セグメントファイルに関しては、セグメントマップは、セグメントマップファイル構造とは独立の構造を伴う、複数のまたは部分的なＦＥＣ修復セグメントのためのＵＲＬおよび／または関連するマッピング情報を含んでよく、ＡＨＳクライアントは、セグメントマップのＵＲＬ構造に基づいてこれらセグメントマップにアクセスし、次いで、セグメントマップに含まれる情報を使用してどのＦＥＣ修復セグメントにアクセスすべきかを決定し、ＦＥＣ修復セグメントの構造を決定できる。

【0264】

セグメントタイムラインファイルを使用する上で説明されたシステムに対して、ＡＨＳクライアントは次のように動作し得る。ＭＰＤから、ＡＨＳクライアントは、セグメントタイムラインファイルの提示時間スパンも示す、セグメントタイムラインファイルのＵＲＬのリストを構築できる。ＡＨＳクライアントはまた、ＵＲＬ構築規則から、または、前に説明されたような他の手段のいずれかで、セグメントのＵＲＬのリストを構築できる。ＡＨＳクライアントは、セグメントタイムラインファイルがいつ利用可能かということと、セグメントタイムラインファイルをいつダウンロードすべきかということとを、現在の実時間と、見られているコンテンツの提示タイムラインに対する現在の実時間の関係とに基づいて、決めることができる。セグメントタイムラインファイルから、ＡＨＳクライアントは、関連するセグメントデータとセグメントマッピング情報とを含むどのセグメントとセグメントマップとをダウンロードすべきかを決定できる。セグメントタイムラインファイルにおいてリストされる最後のセグメントに対して、ＡＨＳクライアントは、その最後のセグメントのダウンロードがいつ可能になるかを、セグメントタイムラインファイルにおいてリストされた提示開始時間から、かつ、任意のセグメントの最長の提示時間スパンである値ＴＳｍａｘから、決定できる。従って、コンテンツが利用可能になってから、コンテンツがＡＨＳによりダウンロードされ見られるまでの、全体のエンドツーエンドの遅延は、セグメントタイムラインファイルの追加による影響を受けず、一方、セグメントタイムラインファイルは、ある表示から別の表示に切り替える時、または、コンテンツの最中のある提示時間からコンテンツを開始する時、どのセグメントとセグメントマップとをダウンロードすべきかということについて、ＡＨＳクライアントに価値のあるヒントを与える。従って、ＡＨＳクライアントの性能をよくするために、セグメントタイムラインファイルを提供することには、多くの利点がある。

【0265】

図１５は、ＤＡＳＨシステムにおけるセグメントタイムラインファイルのシグナリングの例を示す。図１５の左側は、コンテンツに対して利用可能にされ得るＭｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ）の何らかの関連のある部分を示し、この例では、ＭＰＤにおいて表される２つの表示がある。第１の表示では、ビデオが約５００Ｋｂｐｓで６４０×４８０の解像度で符号化されることが可能であり、第２の表示では、ビデオが約２５０Ｋｂｐｓで符号化されることが可能であり解像度はやはり６４０×４８０であり、両方の表示が、コンテンツ中の１００秒で開始する期間内で利用可能である。この例におけるコンテンツの全てに対する基本ＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／である。

【0266】

図１５に示されるように、第１の表示に対するセグメントタイムラインファイルの時間軸は、毎秒１ティックであり、これらセグメントタイムラインファイルのＵＲＬテンプレートパターンは、．／ａｈｓ−５−ＤＵＲ４．ＥＰＴ＄２＊Ｔｉｎｄ＄．ｔｉｍｅであり、完全なＵＲＬは、基本ＵＲＬとこのテンプレートにより定義されるＵＲＬ部分との連結物である。ここで、ＤＵＲ４は、セグメントタイムラインによってカバーされる提示時間のスパンが４ティック、すなわちｔｉｍｅｓｃａｌｅ＝１なので等価的に４秒であることを示し、ＥＰＴ＄２＊Ｔｉｎｄ＄は、スパンの提示終了時間が２×Ｔｉｎｄティック、すなわちｔｉｍｅｓｃａｌｅ＝１なので等価的に２×Ｔｉｎｄ秒であることを示し、Ｔｉｎｄはセグメントタイムラインファイルのインデックスを示す。従って、第１のセグメントタイムラインファイル（Ｔｉｎｄ＝１である）の完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−ＤＵＲ４．ＥＰＴ２．ｔｉｍｅであり、第２のセグメントタイムラインファイル（Ｔｉｎｄ＝２である）の完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−ＤＵＲ４．ＥＰＴ４．ｔｉｍｅであり、以下同様である。これは、全てのセグメントタイムラインファイルが４秒のスパンをカバーし、第１のセグメントタイムラインファイルのスパンが提示時間２秒で終了し（従って、スパンの最初の２秒は実際には存在しない）、第２のセグメントタイムラインのスパンが提示時間４秒で終了し、以下同様であることを示す。

【0267】

図１５に示されるように、第１の表示のセグメントファイルの時間軸は、毎秒３００００ティックであり、これらセグメントファイルのＵＲＬテンプレートパターンは、．／ａｈｓ−５−＄Ｓｉｎｄ＄．３ｇｓであり、完全なＵＲＬは、基本ＵＲＬとこのテンプレートにより定義されるＵＲＬ部分との連結物である。ここで、Ｓｉｎｄはセグメントファイルのインデックスを示す。従って、第１のセグメントファイル（Ｓｉｎｄ＝１である）の完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−１．３ｇｓであり、第２のセグメントファイル（Ｓｉｎｄ＝２である）の完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−２．３ｇｓであり、以下同様である。

【0268】

図１５の中央部に示されるセグメントタイムラインファイルは、セグメントタイムラインファイルによってカバーされる提示時間スパン内に提示開始時間を有するセグメントファイルの各々に対するＳｉｎｄを搬送し、そのセグメントファイルで搬送されるメディアの対応するＳＰＴ（提示開始時間）も搬送し、ＳＰＴの単位はセグメント時間軸のティックであり、すなわち毎秒３００００ティックである。例えば、Ｓｉｎｄ＝５かつＳＰＴ＝７９０７９である第５のセグメントについての情報は、第２のセグメントタイムラインファイル（Ｔｉｎｄ＝２）と第３のセグメントタイムラインファイル（Ｔｉｎｄ＝３）の両方で搬送され、それは、７９０７９ティックのＳＰＴが７９０７９／３００００秒に対応し、すなわち約２．６４秒が第２のセグメントタイムラインファイルと第３のセグメントタイムラインファイルの両方のタイムスパン内にあるからである。いくつかの実施形態では、他のデータも、セグメントタイムラインファイル、例えば、セグメントに対するセグメントマップなどで搬送される。

【0269】

図１５の右側に示されるセグメントファイルは、示されるＳＰＴで開始するメディアデータを搬送し、これらセグメントファイルの各々のＵＲＬが示される。セグメントファイルで搬送されるデータの大部分、例えば、メディアデータ自体、および場合によってセグメントに関連するセグメントマップなどは、図１５に示されていない。

【0270】

図１５の左側に示されるＭＰＤはまた、第２の表示に関連付けられる、セグメントタイムラインファイルとセグメントファイル情報とを示す。対応するセグメントタイムラインファイルおよびセグメントファイルは、この第２の表示について、図１５に示されない。図１５に示されるように、第２の表示に対するセグメントタイムラインファイルの時間軸は、毎秒１ティックであり、これらセグメントタイムラインファイルのＵＲＬテンプレートパターンは、．／ａｈｓ−２−ＤＵＲ７．ＥＰＴ＄３＊Ｔｉｎｄ＄．ｔｉｍｅであり、完全なＵＲＬは、基本ＵＲＬとこのテンプレートにより定義されるＵＲＬ部分との連結物である。ここで、ＤＵＲ７は、セグメントタイムラインによってカバーされる提示時間のスパンが７ティック、すなわちｔｉｍｅｓｃａｌｅ＝１なので等価的に７秒であることを示し、ＥＰＴ＄３＊Ｔｉｎｄ＄は、スパンの提示終了時間が３×Ｔｉｎｄティック、すなわちｔｉｍｅｓｃａｌｅ＝１なので等価的に３×Ｔｉｎｄ秒であることを示し、Ｔｉｎｄはセグメントタイムラインファイルのインデックスを示す。従って、第１のセグメントタイムラインファイル（Ｔｉｎｄ＝１である）の完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−２−ＤＵＲ７．ＥＰＴ３．ｔｉｍｅであり、第２のセグメントタイムラインファイル（Ｔｉｎｄ＝２である）の完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−２−ＤＵＲ７．ＥＰＴ６．ｔｉｍｅであり、以下同様である。これは、全てのセグメントタイムラインファイルが７秒のスパンをカバーし、第１のセグメントタイムラインファイルのスパンが提示時間３秒で終了し（従って、スパンの最初の４秒は実際には存在しない）、第２のセグメントタイムラインのスパンが提示時間６秒で終了し、以下同様であることを示す。図１５に示されるように、第２の表示のセグメントタイムラインファイルの時間軸は、毎秒３００００ティックであり、これらセグメントファイルのＵＲＬテンプレートパターンは、．／ａｈｓ−２−＄Ｓｉｎｄ＄．３ｇｓであり、完全なＵＲＬは、基本ＵＲＬとこのテンプレートにより定義されるＵＲＬ部分との連結物である。ここで、Ｓｉｎｄはセグメントファイルのインデックスを示す。従って、第１のセグメントファイル（Ｓｉｎｄ＝１である）の完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−２−１．３ｇｓであり、第２のセグメントファイル（Ｓｉｎｄ＝２である）の完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−２−２．３ｇｓであり、以下同様である。

【0271】

図１５に示される例では、ＡＨＳクライアントは次のように動作し得る。ＡＨＳクライアントは、ＭＰＤのＵＲＬを使用してＭＰＤをダウンロードし、ＭＰＤ内の情報を使用して、上で説明されたようなセグメントタイムラインファイルとセグメントファイル情報とを決定できる。ＡＨＳクライアントが、毎秒３００００ティックのセグメント時間軸において、提示時間約１１００００ティックで第１の表示へ切り替えることを望むと仮定する。１１００００／３００００は約３．６７秒なので、ＡＨＳクライアントは、３．６７秒がセグメントタイムラインによってカバーされる時間スパンの最中のどこかとなるように、セグメントタイムラインのＵＲＬを形成することを選ぶことができ、例えば、６秒のＥＰＴと４秒の時間スパンの長さとを有するＴｉｎｄ＝３であるセグメントタイムラインファイルが良好な選択であることがあり、ＡＨＳクライアントは、ＭＰＤ内の第１の表示に対するセグメントタイムラインＵＲＬテンプレート構築規則を使用して、このセグメントタイムラインファイルのＵＲＬを、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−ＤＵＲ４．ＥＰＴ６．ｔｉｍｅと決定できる。ＡＨＳクライアントは、このＵＲＬを使用して、次のデータ要素を含むこのセグメントタイムラインファイルをダウンロードできる。

【数4】

【0272】

７９０７９＜１１００００＜１２５１２５なので、ＡＨＳクライアントは、ＡＨＳクライアントが第１の表示に切り替えることを望む地点が、Ｓｉｎｄ＝５であるセグメントファイル内にあると判定できる。ＭＰＤ内のセグメントＵＲＬテンプレート構築規則と、セグメントインデックスＳｉｎｄ＝５とに基づいて、ＡＨＳクライアントは、このセグメントのＵＲＬをｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−５．３ｇｓとして形成でき、ＡＨＳクライアントは、このＵＲＬを使用してこのセグメントをダウンロードできる。

【0273】

上記の多数の変形形態が存在する。例えば、ライブストリーミングサービスでは、ＡＨＳクライアントは、現在の提示時間に基づいて、ファイルのダウンロードがいつ利用可能になるかを判定できる。例えば、セグメントタイムラインファイルは、直ちに、または、現在の提示時間がセグメントタイムラインファイルの提示終了時間（ＥＰＴ）に達したすぐ後に、ダウンロードが可能になってよく、ＡＨＳクライアントは、セグメントタイムラインのＵＲＬテンプレート構築規則および現在の提示時間に基づいて、どのセグメントタイムラインファイルのダウンロードが可能かを判定できる。別の例として、セグメントファイルのダウンロードは、直ちに、または現在の提示時間が後続のセグメントファイルのＳＰＴに達してからすぐ後に、可能になってよい。従って、ＡＨＳクライアントは、セグメントタイムラインファイルで搬送されるセグメントインデックスおよびそれらの対応するＳＰＴに基づいて、どのセグメントファイルのダウンロードが可能かを判定できる。例えば、ＡＨＳクライアントがＥＰＴ＝Ｚまでの時間スパンをカバーするセグメントタイムラインファイルをダウンロードしており、セグメントタイムラインファイルが長くともＺである最大提示時間を伴うメディアデータを搬送するＳｉｎｄ＝ｉであるセグメントファイルについての情報を搬送する場合、ＡＨＳクライアントは、Ｓｉｎｄ＝ｉであるセグメントファイルのダウンロードが可能である、またはまもなく可能になると判定できる。別の例として、Ｓｉｎｄ＝ｉかつＳＰＴ＝Ｙであるセグメントファイルがセグメントタイムラインファイルにおいてリストされる最後のセグメントファイルである場合、ＡＨＳクライアントは、利用可能なメディア提示時間が提示時間Ｙ＋ＴＳｍａｘかそれよりも後である時、Ｓｉｎｄ＝ｉであるセグメントファイルのダウンロードが可能であると判定でき、ＴＳｍａｘは、セグメントファイルの時間スパンの上限を上回るものとして定義される。

【0274】

ＡＨＳクライアントは、特定の提示時間Ｔのメディアデータをどのセグメントファイルが含むかを、次のように決定できる。ＡＨＳクライアントは、Ｔを含む提示時間スパンを伴うセグメントタイムラインファイルのＵＲＬ、すなわち、提示時間Ｚ−Ａで開始し提示時間Ｚで終了する（ここでＺ−Ａ≦Ｔ≦Ｚ）長さＡの提示時間スパンを伴うセグメントタイムラインファイルのＵＲＬを決定できる。これは、Ｔの値を使用してＺとＡとを計算する、セグメントタイムラインＵＲＬテンプレート構築規則を使用して行われ得る。いくつかのそのようなセグメントタイムラインファイルが存在することがあり、Ｔが提示時間スパンの中心に最も近いようなセグメントタイムラインファイルが好ましいことがあることに、留意されたい。ＡＨＳクライアントは、構築されたＵＲＬを使用して、セグメントタイムラインファイルをダウンロードできる。次いで、セグメントタイムラインファイルにおける情報に基づいて、ＡＨＳクライアントは、どのセグメントファイルがＴを含むかを次のように決定できる。Ｙ＿１、Ｙ＿２、…、Ｙ＿ｋを、セグメントタイムラインファイルが情報を含むｋ個のセグメントファイルのＳＰＴとし、ｉ＋１、ｉ＋２、・・・、ｉ＋ｋを、これらセグメントファイルのインデックスとし、ｋの値もパラメータとしてセグメントタイムラインマップで搬送されてよく、Ｚ−Ａ≦Ｙ＿１＜Ｙ＿２＜…＜Ｙ＿ｋ≦Ｚである。Ｚ−Ａ≦Ｔ＜Ｙ＿１である場合、インデックスｉを伴うセグメントファイルは提示時間Ｔを含み、２とｋとの間の何らかのｊに対してＹ＿（ｊ−１）≦Ｔ＜Ｙ＿ｊである場合、インデックスｊ−１を伴うセグメントファイルは提示時間Ｔを含み、Ｙ＿ｋ≦Ｔ＜Ｚである場合、インデックスｋを伴うセグメントファイルは提示時間Ｔを含む。

【0275】

時間ベースとインデックスベースの混合されたセグメントＵＲＬテンプレートの生成
セグメントＵＲＬテンプレート構築規則は、時間ベースの要素とインデックスベースの要素の両方を含むように、次のように強化され得る。ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬを、表示の全てのセグメントのセグメントＵＲＬに含まれる時間ベースの情報に対する、１秒当たりのティックの数を表すために使用される時間軸とし、ＴｉｎｄおよびＳｉｎｄを正の整数のインデックスとし、ＴＭを正の整数の定数とする。すると、セグメントＵＲＬテンプレート構築規則は、次の形式となり得る。

【0276】

１．Ｃｏｎｔｅｎｔ＿ＩＤ．Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤ．ＰＴ＄Ｔｉｎｄ＄．ＳＥＧ＄Ｓｉｎｄ＄
ＴＭの値は、ＴＭ／ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬが少なくともＴＳｍａｘとなるように設定されるべきであり、ＴＳｍａｘは、この表示内における任意のセグメントの最大提示時間スパンである。例えば、ＴＳｍａｘ＝２．２秒でありＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝１０である場合、ＴＭ／ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝２２／１０秒≧ＴＳｍａｘなので、ＴＭは２２と等しく設定され得る。このことは、ＴＭ×Ｔｉｎｄが大きくとも表示の総提示時間スパンであるような各正の整数に対して、少なくとも１つのセグメントがＴＭ×（Ｔｉｎｄ−１）とＴＭ×Ｔｉｎｄとの間の提示時間の期間に開始することを保証し、ここで全ての時間が、時間軸ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬに対するものである。

【0277】

各セグメントに対して、そのセグメントのＴｉｎｄおよびＳｉｎｄの値は、上記のセグメントＵＲＬテンプレート構築規則に従って、そのセグメントのＵＲＬを完全に定義する。セグメントのＴｉｎｄおよびＳｉｎｄの値は、次のように決定され得る。セグメントのＴｉｎｄの値は、ＴＭ×（Ｔｉｎｄ−１）≦ＳＰＴ＜ＴＭ×Ｔｉｎｄを満たし、ＳＰＴは、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの時間軸における、セグメントの提示開始時間ＳＰＴである。上で説明されたように、Ｔｉｎｄ×ＴＭが大きくとも表示の総提示時間スパンであるような各正のＴｉｎｄに対して、値Ｔｉｎｄを割り当てられた少なくとも１つのセグメントである。値Ｔｉｎｄを割り当てられたセグメントうち、最早のＳＰＴを伴うセグメントは値Ｓｉｎｄ＝１を割り当てられ、その次に早いＳＰＴを伴うセグメントは値Ｓｉｎｄ＝２を割り当てられ、その次に早いＳＰＴを伴うセグメントは値Ｓｉｎｄ＝３を割り当てられ、ここで、セグメントの数はＴｉｎｄの異なる値に対して変化するので、Ｓｉｎｄの最大の使用される値は、Ｔｉｎｄの異なる値に対して変化し得る。

【0278】

図１６は、ＤＡＳＨシステムにおける、時間ベースとインデックスベースの混合されたセグメントＵＲＬテンプレートの生成の例を示す。図１６の左側は、コンテンツに対して利用可能にされ得るＭｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ）の何らかの関連のある部分を示し、この例では、ＭＰＤにおいて表される２つの表示がある。第１の表示では、ビデオが約５００Ｋｂｐｓで６４０×４８０の解像度で符号化されることが可能であり、第２の表示では、ビデオが約２５０Ｋｂｐｓで符号化されることが可能であり解像度はやはり６４０×４８０であり、両方の表示が、コンテンツ中の１００秒で開始する期間内で利用可能である。この例におけるコンテンツの全てに対する基本ＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／である。

【0279】

図１６に示されるように、第１の表示のセグメントＵＲＬのＴｉｍｅｓｃａｌｅＳｅｇＵＲＬは、毎秒１０ティックであり、ＴＭの値は２２ティックであり、これらセグメントファイルのＵＲＬテンプレートパターンは、．／ａｈｓ−５−＄Ｔｉｎｄ＄．＄Ｓｉｎｄ＄．３ｇｓであり、セグメントの完全なＵＲＬは、基本ＵＲＬとこのテンプレートにより定義されるＵＲＬ部分との連結物である。ＴＭ＝２２かつＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝１０なので、第１の表示の任意セグメントの最大提示時間スパンは、２２／１０＝２．２秒であることに留意されたい。ＴＭ×Ｔｉｎｄは、Ｔｉｎｄの所与の値を伴うセグメントの提示開始時間のスパンが、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの時間軸においてＴＭ×Ｔｉｎｄティックであることを示し、すなわち、第１の表示に対して、Ｔｉｎｄの各値は、セグメント提示開始時間の２．２秒をカバーする。ＴＭ×（Ｔｉｎｄ−１）とＴｉｎｄとの間で最早の提示開始時間を伴うセグメントはＳｉｎｄ＝１を有し、ＴＭ×（Ｔｉｎｄ−１）とＴｉｎｄとの間で２番目に早い提示開始時間を伴うセグメントは、そのようなセグメントがあれば、Ｓｉｎｄ＝２を有し、以下同様である。従って、Ｔｉｎｄ＝１である第１のセグメントファイルの完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−１．１．３ｇｓであり、Ｔｉｎｄ＝１である第２のセグメントファイルの完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−１．２．３ｇｓであり、Ｔｉｎｄ＝２である第１のセグメントファイルは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−２．１．３ｇｓである。

【0280】

図１６に示されるように、第１の表示のＴｉｍｅｓｃａｌｅＳｅｇは、毎秒３００００ティックであり、これは、セグメント内のメディアフレームに対して表される提示時間が、毎秒３００００ティックの単位であることを示す。従って、例えば、セグメント内のフレームの提示時間が１００１０である場合、秒単位での提示時間は１００１０／３００００、すなわち約０．３３秒である。

【0281】

図１６の中心に示される第１の表示のセグメントファイルは、ＴｉｍｅｓｃａｌｅＳｅｇの単位で、セグメントの提示開始時間ＳＰＴを示し、セグメントのＵＲＬも示す。例えば、第５のセグメントはＳＰＴ＝７９０７９を有し、これは、７９０７９／３００００秒、すなわち約２．６３６秒に対応する。このＳＰＴは、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝毎秒１０ティックの単位で２２ティックと４４ティックとの間、すなわち２．２秒と４．４秒との間にあるので、このセグメントではＴｉｎｄ＝２である。さらに、これは、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝毎秒１０ティックの単位で２２ティックと４４ティックとの間にある最早のＳＰＴを伴うセグメントなので、このセグメントではＳｉｎｄ＝１である。従って、セグメント５のセグメントＵＲＬは、図１６に示されるように、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−２．１．３ｇｓである。図１６は、あったとしても、セグメントファイルで搬送されるメディアデータまたはセグメントマップ情報を示さない。

【0282】

図１６に示されるように、第２の表示のセグメントＵＲＬのＴｉｍｅｓｃａｌｅＳｅｇＵＲＬは、毎秒２０ティックであり、ＴＭの値は３０ティックであり、これらセグメントファイルのＵＲＬテンプレートパターンは、．／ａｈｓ−２−＄Ｔｉｎｄ＄．＄Ｓｉｎｄ＄．３ｇｓであり、セグメントの完全なＵＲＬは、基本ＵＲＬとこのテンプレートにより定義されるＵＲＬ部分との連結物である。ＴＭ＝３０かつＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝２０なので、第１の表示の任意セグメントの最大提示時間スパンは、３０／２０＝１．５秒であることに留意されたい。ＴＭ×Ｔｉｎｄは、Ｔｉｎｄの所与の値を伴うセグメントの提示開始時間のスパンが、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの時間軸においてＴＭ×Ｔｉｎｄティックであることを示し、すなわち、第１の表示に対して、Ｔｉｎｄの各値は、セグメント提示開始時間の１．５秒をカバーする。ＴＭ×（Ｔｉｎｄ−１）とＴｉｎｄとの間で最早の提示開始時間を伴うセグメントはＳｉｎｄ＝１を有し、ＴＭ×（Ｔｉｎｄ−１）とＴｉｎｄとの間で２番目に早い提示開始時間を伴うセグメントは、そのようなセグメントがあれば、Ｓｉｎｄ＝２を有し、以下同様である。従って、Ｔｉｎｄ＝１である第１のセグメントファイルの完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−１．１．３ｇｓであり、Ｔｉｎｄ＝１である第２のセグメントファイルの完全なＵＲＬは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−１．２．３ｇｓであり、Ｔｉｎｄ＝２である第１のセグメントファイルは、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−２．１．３ｇｓである。

【0283】

図１６に示されるように、第２の表示のＴｉｍｅｓｃａｌｅＳｅｇは、毎秒３００００ティックであり、これは、セグメント内のメディアフレームに対して表される提示時間が、毎秒３００００ティックの単位であることを示す。従って、例えば、セグメント内のフレームの提示時間が１１０１１である場合、秒単位での提示時間は１１０１１／３００００、すなわち約０．３６７秒である。

【0284】

図１６の右側に示される第２の表示のセグメントファイルは、ＴｉｍｅｓｃａｌｅＳｅｇの単位で、セグメントの提示開始時間ＳＰＴを示し、セグメントのＵＲＬも示す。例えば、第８のセグメントはＳＰＴ＝１７５１７５を有し、これは、１７５１７５／３００００秒、すなわち約５．８４秒に対応する。このＳＰＴは、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝毎秒２０ティックの単位で９０ティックと１２０ティックとの間、すなわち４．５秒と６秒との間にあるので、このセグメントではＴｉｎｄ＝４である。さらに、これは、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝毎秒２０ティックの単位で９０ティックと１２０ティックとの間にある２番目に早いＳＰＴを伴うセグメントなので、このセグメントではＳｉｎｄ＝２である。セグメント８のセグメントＵＲＬは、図１６に示されるように、ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−２−４．２．３ｇｓである。

【0285】

表示のセグメント化を実行するサーバによる、上記のセグメントＵＲＬテンプレート構築規則に従ったセグメントＵＲＬの生成は単純である。セグメントＵＲＬのＴｉｎｄは、セグメントの提示開始時間のみに依存し、ＵＲＬのＳｉｎｄは、同じＴｉｎｄを有する以前に生成されたセグメントの数のみに依存する。従って、セグメントＵＲＬは、そのようなサーバによってリアルタイムに生成されてよく、セグメントで搬送されるメディアが利用可能になる前に、かつ、セグメントで搬送されるメディアの提示時間が利用可能になる前に、利用可能にされてよい。

【0286】

上で説明されたような、時間ベースとインデックスベースの混合されたセグメントＵＲＬテンプレートの生成の利点は、セグメントが可変の提示時間スパンを有し得る一方で、同時に、ＡＨＳクライアントがセグメントＵＲＬを構築でき、正確なセグメント提示時間スパンについての事前の情報を伴うことなく、かつ、セグメントＵＲＬリストまたはＭＰＤに対する複雑な更新を伴うことなく、セグメントをダウンロードできることである。すなわち、ＡＨＳクライアントは、簡単なセグメントＵＲＬテンプレート構築規則を使用して、関心のあるセグメントのＵＲＬを構築できる。可変の提示時間スパンを伴うセグメントの利点は、以前に説明されており、例えば、このことは、セグメントが主開始点で開始することを可能にし、最良の圧縮と再生の品質とを提供する自然な提示時間の境界にビデオ圧縮が主開始点を柔軟に配置することを可能にし、これら境界は、コンテンツ自体内の、シーンの変化または動作のシーケンスによって決定され得る。

【0287】

ＡＨＳクライアントは、時間ベースとインデックスベースの混合されたセグメントＵＲＬテンプレートの生成に基づいて、ライブシステムに対して次のように動作できる。ＡＨＳクライアントは、ＭＰＤのＵＲＬを使用してＭＰＤをダウンロードし、ＭＰＤ内の情報を使用して、上で説明されたようなセグメントＵＲＬテンプレート構築規則とＭＰＤ内の他の情報とを決定できる。例えば、ＡＨＳクライアントは、クライアントが要求し得る可能性のある表示のＴＭおよびＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの値を使用して、任意のこれら関連する表示の任意のセグメントの提示時間スパンの上限ＴＳｍａｘを決定できる。例えば、２つの表示がある図１６では、いずれの表示の選択もクライアントに可能であると仮定すると、クライアントは、２２／１０と３０／２０の大きい方、すなわち、２．２秒と１．５秒の大きい方として、ＴＳｍａｘを計算できる。

【0288】

ＡＨＳクライアントが、何らかの実時間Ｔにおいてライブストリームからの表示の要求と再生とを開始することを決めると仮定し、Ｔは、表示のＴｉｍｅｓｃａｌｅＳｅｇＵＲＬティックの単位で表される。ＡＨＳクライアントが要求し再生することを望む表示のＴおよびＴＭに基づいて、クライアントは、Ｍ＝ｆｌｏｏｒ（Ｔ／ＴＭ）を計算でき、ｆｌｏｏｒは、その変数以下の最大の整数を出力する関数である。クライアントは、Ｔｉｎｄ＝Ｍ−１およびＳｉｎｄ＝１に対応するＵＲＬを伴う、セグメントＩと呼ぶセグメントを要求できる。時間Ｔにおいて、セグメントＩは利用可能であることが保証され、それは、Ｔｉｎｄ＝Ｍ−１である任意のセグメントの提示開始時間がＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの単位で少なくともＴＭティックだけＴよりも前にあり、かつ、セグメントＩの提示時間スパンがＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの単位で長くともＴＭティックであり、セグメントＩの終わりがＴよりも前であり従ってセグメントＩが利用可能であるからである。さらに、Ｔｉｎｄ＝Ｍ−１である少なくとも１つのセグメントがあるので、Ｔｉｎｄ＝Ｍ−１およびＳｉｎｄ＝１であるセグメントＩがある。ＡＨＳクライアントは、現在の実時間ＴとセグメントＩの提示開始時間との差が、例えばＴＳｍａｘの何らかの倍数であれば、例えば、差が少なくともＴＳｍａｘまたは少なくとも２×ＴＳｍａｘであれば、セグメントＩの再生を開始できる。

【0289】

多くの可能性のあるＡＨＳクライアント戦略が可能である。例えば、クライアントは、さらに過去のメディアのダウンロードを開始し、再生のためにメディアのバッファを構築でき、これには、ダウンロード遅延に対する回復力を向上させ、最初のダウンロードレートが最初の再生レートよりも高い場合に始動時間を低減するかもしれない潜在的利益を伴う。

【0290】

上では、かつ以下では、「実時間(real-time)」、「Ｔの値(the value of T)」、および「利用可能である(available)」という用語は一般に、コンテンツが作成された時とコンテンツの再生が可能になった時との間の遅延が可能な限り少ない状態で、クライアントがライブコンテンツの再生を実時間で試みている時の状況(situation)を表すコンテキスト(context)で使用される。上で説明されたように、クライアントは、メディアバッファを構築するために、ライブコンテンツの提示時間においてさらに後にあるコンテンツを再生することを選ぶことができ、オンデマンドコンテンツでは、コンテンツの全てが、始めからクライアントに利用可能であり得るので、これらコンテキスト(context)では、「実時間」は、クライアントが現在ダウンロードを望んでいるメディアの所望の提示時間としてより一般的に見られ、「Ｔの値」は、クライアントが現在ダウンロードを試みているコンテンツの概略的な提示時間であり、クライアントがダウンロードを試みているコンテンツの全てが利用可能である。

【0291】

ＡＨＳクライアントがセグメントＩをダウンロードすると、または、セグメントＩの提示終了時間へのアクセス権を有すると、ＡＨＳクライアントは、次のセグメントＩ＋１の提示開始時間も知る。セグメントＩ＋１の提示開始時間は、セグメントＩ＋１がＴｉｎｄ＝Ｍ−１とＳｉｎｄ＝２とを有するかどうか、すなわち、セグメントＩ＋１の提示開始時間がＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの単位でＴＭ×（Ｍ−１）未満であるかどうかを判定し、または、セグメントＩ＋１がＴｉｎｄ＝ＭとＳｉｎｄ＝１とを有するかどうか、すなわち、セグメントＩ＋１の提示開始時間がＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの単位でＴＭ×（Ｍ−１）以上であるかどうかを判定するために、使用され得る。このように続けて、ＡＨＳクライアントは常に、表示内において現在のセグメントの後のセグメントのＴｉｎｄとＳｉｎｄとを決定でき、従って次のセグメントのＵＲＬを決定できる。

【0292】

何らかの理由で、ＡＨＳクライアントが、Ｔｉｎｄ＝Ｍ−１である、表示の特定のセグメントにアクセスできない場合、または特定のセグメントについての情報にアクセスできない場合、ＡＨＳクライアントは、前の段落で説明された手順を使用して、欠落セグメントの後の後続のセグメントのＵＲＬを決定することが可能ではないことがある。しかしながら、ＡＨＳクライアントは、Ｔｉｎｄ＝ＭかつＳｉｎｄ＝１であるセグメントのＵＲＬを決定でき、それは、各Ｔｉｎｄに対して少なくとも１つのセグメントがあり、Ｔｉｎｄ＝ＭかつＳｉｎｄ＝１であるセグメントが何らかの点で利用可能であるはずであるからである。従って、ＡＨＳクライアントが、例えばサーバまたはネットワーク配信のエラーにより、表示からのあるセグメントを欠いている場合、ＡＨＳクライアントは、次に大きいＴｉｎｄ値を伴う最初のセグメントへとスキップすることがあり、これによって、メディアコンテンツの長くとも２×ＴＭ／ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬのスパンの提示時間の再生を欠くことがある。

【0293】

ＡＨＳクライアントは、次のような戦略を使用して、第１の表示から第２の表示に切り替えることができる。ＴＭおよびＴｉｍｅｓｃａｌｅＳｅｇＵＲＬを、切り替え先の第２の表示に対するものとし、Ｔを、切り替えの決定が行われた実時間をＴｉｍｅｓｃａｌｅＳｅｇＵＲＬのティック単位で表したものとする。ＴがＴＭによって等しく分割可能である次の値に達すると、すなわち、Ｍ＝Ｔ／ＴＭが整数になるとすぐに、ＡＨＳクライアントは、第２の表示からのセグメントＩと呼ぶセグメントに対して、Ｔｉｎｄ＝Ｍ−１およびＳｉｎｄ＝１に対応するＵＲＬを生成し、セグメントＩの提示開始時間において第２の表示に切り替えることができる。一方、ＡＨＳクライアントは、第２の表示のセグメントＩの少なくとも提示開始時間まで再生できるようになるまで、第１の表示からのセグメントのダウンロードを続けて、次いで、第２の表示のセグメントＩの再生に切り替えることができる。この段落で説明された方法を使用して、実時間と再生された提示時間との差が少なくとも２×ＴＳｍａｘである場合、セグメントのダウンロードが要求される時と、セグメントの再生を開始するのに少なくとも十分なセグメントがＡＨＳクライアントに到達した時との間の時間を考慮せずに、第１の表示から第２の表示への切り替えを、詰まりまたは休止を何ら伴わずに実行できる。

【0294】

ＡＨＳクライアント方法の例として、図１６を考える。ＭＰＤから、クライアントは、これら２つの表示に対して、ＴＳｍａｘ＝ｍａｘ｛２２／１０，３０／２０｝＝２．２秒であると決定できる。クライアントが、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝毎秒１０ティックの単位で実時間Ｔ＝５２において、すなわち、実時間５．２秒において、第１の表示に参加することを決めると仮定する。第１のクライアント戦略は、クライアントがＭ＝ｆｌｏｏｒ（Ｔ／ＴＭ）を計算することであり、ここでＴＭ＝２２なのでＭ＝２である。これに基づいて、クライアントは、Ｔｉｎｄ＝Ｍ−１＝１およびＳｉｎｄ＝１に対応するセグメント、すなわちセグメント１のＵＲＬを生成し、次いで、セグメント１を要求しダウンロードできる。セグメント１はこの時点で利用可能であり、それは、セグメント１の提示終了時間は大きくともセグメント２の提示開始時間であり、セグメント２の提示開始時間は１００１０／３００００すなわち約０．３３３秒であるからである。クライアントは、セグメント１の少なくとも一部を受信すると、メディアコンテンツの再生を開始でき、従って、実時間と提示時間との間のラグは、この例では約５．２−０．３３＝４．８７秒であり、一般にこの第１のクライアント戦略を使用すると大きくとも３×ＴＳｍａｘである。

【0295】

第１のクライアント戦略を使用して上の例を続けると、セグメント１についての情報、具体的にはその提示終了時間が利用可能になると、次のセグメントの提示開始時間、すなわち１９０１９／３００００を計算でき、これから、この次のセグメント２のＴｉｎｄ＝１かつＳｉｎｄ＝２を決定でき、そのＵＲＬは、ＵＲＬテンプレート構築規則に従って構築され、セグメント２はそのＵＲＬに基づいて要求され得る。何らかの理由で、Ｔｉｎｄ＝１かつＳｉｎｄ＝２に対応するセグメント２が利用可能ではないと仮定する。次いで、ＡＨＳクライアントは、セグメント３および４のＵＲＬを決定できることもできないこともあるが、ＡＨＳクライアントは、Ｔｉｎｄ＝２かつＳｉｎｄ＝１であるセグメント５のＵＲＬを決定し、表示１のセグメント５と後続のセグメントとを要求し再生できる。この例では、ＡＨＳクライアントは、セグメント１を再生し、セグメント２、３、および４の再生をスキップし、次いで、セグメント５および後続のセグメントの再生へと続くことができるので、全体で（７９０７９−１００１０）／３００００、すなわち約２．３秒のメディアコンテンツの再生をスキップし、これは一般に、この第３のクライアント戦略を使用すると大きくとも２×Ｔｍａｘである。

【0296】

上記のように、クライアントが、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝毎秒１０ティックの単位で実時間Ｔ＝５２において、すなわち、実時間５．２秒において、第１の表示に参加することを決めると仮定する。第２の代替的なクライアント戦略は、クライアントが、実時間がＴＭティックの倍数となるまで、すなわち、実時間Ｔが３×ＴＭ／ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝６．６秒に達するまで待機し、次いで上記のように進んで、Ｍ＝Ｔ／ＴＭ＝３を計算し、次いでＴｉｎｄ＝Ｍ−１＝２かつＳｉｎｄ＝１、すなわちセグメント５に対応するＵＲＬを形成し、次いで７９０７９／３００００すなわち約２．６３６秒の提示開始時間を伴ってセグメント５から要求し再生を開始するというものである。この場合、再生は、クライアントが表示１からの再生を決めた時から、少なくとも６．６−５．２秒＝１．４秒だけ遅れ、すなわち一般には、この第２のクライアント戦略を使用すると最大でＴＳｍａｘ秒遅れるが、実時間と提示開始時間とのラグは、６．６−２．６３６＝３．９６４秒改善され、このラグは一般には、この第２のクライアント戦略を使用すると最大で２×ＴＳｍａｘである。この場合、クライアントは、ラグが２×ＴＳｍａｘと等しくなるように、再生を遅らせると決めることができ、すなわち、提示時間２．６３６秒で開始するコンテンツは、実時間２．６３６＋２×２．２＝７．０３６秒で開始するので、同じ表示のセグメントに対する後続の表示の切り替えまたは要求による、詰まりまたは休止はない。

【0297】

上記の例を続けると、ＡＨＳクライアントは、実時間Ｔ＝１０秒で第１の表示から第２の表示に切り替えると決める。ＴＭ＝３０かつＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝２０が、第２の表示に対して規定されるものとする。ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの単位のＴＭによって等しく分割できる次の値にＴが達するとすぐに、すなわち、Ｍ＝Ｔ×ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ／ＴＭが整数になると、これはＭ＝７ではＴ＝１０．５秒において起きるが、ＡＨＳクライアントは、第２の表示のセグメント１０のＴｉｎｄ＝６かつＳｉｎｄ＝１に対応するＵＲＬを生成してこのセグメントを要求でき、このセグメントの提示開始時間は、２３０２３０／３００００すなわち約７．６７４秒である。再生されているものの実時間と提示時間とのラグが、この例について前の段落で説明されたように４．４秒である場合、このセグメントの再生は、実時間の約１２．０７４３秒で開始する。一方、ＡＨＳクライアントは、第２の表示のセグメント１０の少なくとも提示開始時間まで再生できるようになるまで、第１の表示からのセグメントのダウンロードを続け、次いで、第２の表示のセグメント１０の再生の開始に切り替えることができる。

【0298】

上記の方法の多数の変形形態が存在する。例えば、表示のＴＭおよびＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの値は、ＴＭ／ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬがその表示のセグメントの最大提示時間スパン未満となるようなものであり得る。この代替形態では、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬのティック単位でＴＭ×（Ｍ−１）とＴＭ×Ｍとの間に提示開始時間を有する、表示のセグメントが存在しないような、何らかの正の整数値Ｍがあり得る。そのような場合、クライアントがＴｉｎｄ＝ＭかつＳｉｎｄ＝１に対応するセグメントのＵＲＬを形成する場合、そのＵＲＬに対応する表示のセグメントは存在しないことがある。この場合、クライアントが、ＨＴＴＰを使用して、形成されたＵＲＬに基づいてセグメントを要求すると決める場合、クライアントは、「ＨＴＴＰ ４０４ ｆｉｌｅ ｎｏｔ ｆｏｕｎｄ」エラー応答を受信することがあり、クライアントはこの応答を使用して、形成されたＵＲＬに対応するセグメントがないと解釈できる。

【0299】

変形形態の別の例として、同じＴｉｎｄインデックスを有するセグメントに対して、セグメントのＳｉｎｄインデックスは、セグメントの提示開始時間が大きくなる順序ではなく、セグメントの提示開始時間が小さくなる順序で、増えていってよい。例えば、セグメント１の提示開始時間が１．１秒であり、セグメント２の提示開始時間が１．３秒であり、セグメント３の提示開始時間が２．４秒であり、これら全ての３個のセグメントが同じＴｉｎｄ値を有する場合、セグメント３のＳｉｎｄ値は１であってよく、セグメント２のＳｉｎｄ値は２であってよく、セグメント１のＳｉｎｄ値は３であってよい。

【0300】

変形形態の他の例として、セグメントに関連付けられるＴｉｎｄ値は、提示開始時間ではなくセグメントの提示終了時間に基づいてよく、または、セグメントに関連付けられるＴｉｎｄ値は、セグメントの平均提示時間に基づいてよく、または、セグメントの中心バイト位置にあるフレームの提示時間に基づいてよい。

【0301】

変形形態の別の例として、セグメントＵＲＬテンプレート構築規則は、セグメントマップＵＲＬテンプレート構築規則に、または、セグメントマップとメディアデータの組合せを含むセグメントに適用されるように、修正され得る。

【0302】

時間ベースとインデックスベースの複数ＵＲＬバージョンのセグメントＵＲＬテンプレートの生成
時間ベースの要素とインデックスベースの要素の両方を含むセグメントＵＲＬテンプレート構築規則はさらに、次のように強化され得る。ＵＲＬテンプレート構築規則は、１つのセグメントに対して２つ以上のＵＲＬを規定するために使用されてよく、すなわち、同じセグメントは複数のＵＲＬに対応してよく、複数のＵＲＬのいずれもが、セグメントを識別するために、例えば、セグメントを要求しダウンロードするために使用され得る。

【0303】

前のように、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬを、表示の全てのセグメントのセグメントＵＲＬに含まれる時間ベースの情報に対する、１秒当たりのティックの数を表すために使用される時間軸とし、ＴｉｎｄおよびＳｉｎｄを正の整数のインデックスとし、ＴＭを正の整数の定数とする。すると、セグメントＵＲＬテンプレート構築規則は、次の形式となり得る。

【0304】

１．Ｃｏｎｔｅｎｔ＿ＩＤ．Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤ．＄Ｔｉｎｄ＄．＄Ｓｉｎｄ＄
この代替形態では、場合によって、各セグメントに対して、ＴｉｎｄおよびＳｉｎｄの複数の値が決定されてよく、そのセグメントに対する各（Ｔｉｎｄ，Ｓｉｎｄ）ペアは、そのセグメントのＵＲＬを定義する。セグメントに対応するＵＲＬを構築するための規則は、以後セグメントＵＲＬ交差規則構築と呼ばれ、次の通りである。ＳＰＴおよびＥＰＴを、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬのティック時間軸でのセグメントの提示開始時間および提示終了時間とし、セグメントの提示終了時間は、後続のセグメントの提示開始時間である。そして、次の３つの条件のうちのいずれか１つまたは複数が満たされる場合、セグメントに割り当てられたＴｉｎｄ＝Ｍに対応するＵＲＬがある。

【数5】

【0305】

言い換えると、［ＳＰＴ，ＥＰＴ］によって定義された提示時間スパンが、Ｔｉｎｄ＝Ｍを伴うＵＲＬテンプレート構築規則によって定義される時間スパン［ＴＭ×（Ｍ−１），ＴＭ×Ｍ］との非空の交差部分を有する場合、セグメントに割り当てられたＴｉｎｄ＝Ｍに対応するＵＲＬがある。セグメントは、３つの条件のうちの２つ以上を満たすことがあり、例えば、ＳＰＴ≦ＴＭ×（Ｍ−１）かつＥＰＴ≧ＴＭ×Ｍである場合、条件１と３の両方が満たされることに留意されたい。セグメントに割り当てられた各Ｔｉｎｄ＝Ｍに対して、セグメントに割り当てられたＳｉｎｄ値は、同じＴｉｎｄ＝Ｍを割り当てられている表示内におけるセグメントの順序に従ったものであり得る。従って、ＥＰＴ_i＝ＳＰＴ_i+1となるように、提示開始時間および提示終了時間（ＳＰＴ₁，ＥＰＴ₁）、（ＳＰＴ₂，ＥＰＴ₂）、…、（ＳＰＴ_N，ＥＰＴ_N）に従って並べられたＵＲＬ時間スパン［ＴＭ×（Ｍ−１），ＴＭ×Ｍ］との提示時間の交差を伴うＮ個のセグメント１、２、…、Ｎがある場合、Ｔｉｎｄ＝Ｍに対するこれらＮ個のセグメントのＳｉｎｄ値は、それぞれ、１、２、…、Ｎである。

【0306】

セグメントＵＲＬ交差規則構築を使用すると、セグメントに割り当てられるＵＲＬの数は、セグメントの提示時間スパンが交差する、形式［ＴＭ×（Ｍ−１），ＴＭ×Ｍ］のＵＲＬ時間スパンの数である。この構築は、各々のＭに対して、ＴＭ×Ｍが大きくとも、ティック時間軸ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬでの表示の提示終了時間となるような性質を有し、Ｔｉｎｄ＝Ｍに割り当てられた少なくとも１つのセグメントがあり、従って、Ｔｉｎｄ＝Ｍおよびそのような各Ｍに対するＳｉｎｄ＝１に対応するＵＲＬを伴うセグメントが常にある。

【0307】

セグメントＵＲＬ交差規則構築を使用すると、各セグメントは、少なくとも１つのＵＲＬ時間スパンに割り当てられる。具体的には、ＵＲＬ時間スパン［ＴＭ×（Ｍ−１），ＴＭ×Ｍ］が、セグメントが交差する最初のＵＲＬ時間スパンであり、セグメントが全体でＮ個のＵＲＬ時間スパンと交差する場合、Ｎ個のＵＲＬがセグメントに割り当てられ、第１のＵＲＬは、何らかのＩ≧１に対するＴｉｎｄ＝ＭおよびＳｉｎｄ＝１に対応し、第２から第ＮのＵＲＬは、それぞれ、（Ｔｉｎｄ＝Ｍ＋１，Ｓｉｎｄ＝１）、（Ｔｉｎｄ＝Ｍ＋２，Ｓｉｎｄ＝１）、…、（Ｔｉｎｄ＝Ｍ＋Ｎ−１，Ｓｉｎｄ＝１）に対応する。従って、セグメントに対応するＵＲＬの全てが、Ｍを最小のＴｉｎｄ値としてＵＲＬの（Ｔｉｎｄ＝Ｍ，Ｓｉｎｄ＝Ｉ）の値から、かつ、セグメントに割り当てられるＵＲＬの数Ｎから、決定され得る。

【0308】

図１７は、セグメントＵＲＬ交差規則構築の例を示す。ＵＲＬ時間スパンおよび各ＵＲＬ時間スパンに割り当てられた値Ｔｉｎｄ＝Ｍは、図１７の底部に沿って示され、各ＵＲＬ時間スパンに対して示されるＴｉｎｄ値は、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの時間軸単位でのスパンの終わりの提示時間Ｍ×ＴＭである。セグメントの開始点および終了点は、ＵＲＬ時間スパンのすぐ上に示され、垂直な線はあるセグメントの終わりと次のセグメントの始まりを示し、すなわち、垂直な線は連続するセグメントの間の境界を示す。各セグメントの開始点と終了点の間に、そのセグメントに割り当てられたＵＲＬに対応する（Ｔｉｎｄ，Ｓｉｎｄ）値のセットがリストされている。例えば、値（１，２）、（２，１）、（３，１）が、第２のセグメントに対してリストされており、これは、第２のセグメントに対応するＵＲＬが次の形式であることを示す。

【数6】

【0309】

セグメントＵＲＬ交差規則構築のＡＨＳクライアントによる使用の例として、ＡＨＳクライアントが、何らかの実時間Ｔにおいてライブストリームからの表示の要求と再生とを開始することを決めると仮定し、Ｔは、表示のＴｉｍｅｓｃａｌｅＳｅｇＵＲＬティックの単位で表される。ＴＳｍａｘは、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの時間軸単位でのＴＭの正の整数ＭＭ倍であり、すなわち、ＴＳｍａｘ＝ＴＭ×ＭＭであると仮定する。ＡＨＳクライアントが要求し再生することを望む表示のＴおよびＴＭに基づいて、クライアントは、Ｍ＝ｆｌｏｏｒ（Ｔ／ＴＭ）を計算でき、ｆｌｏｏｒは、その変数以下の最大の整数を出力する関数である。クライアントは、Ｔｉｎｄ＝Ｍ−ＭＭ＋１に対応するＵＲＬ時間スパンの開始側の境界と交差する、Ｔｉｎｄ＝Ｍ−ＭＭ＋１かつＳｉｎｄ＝１に対応するＵＲＬを伴う、セグメントＩと呼ぶセグメントを要求できる。時間Ｔにおいて、セグメントＩは利用可能であることが保証され、それは、Ｔｉｎｄ＝Ｍ−ＭＭ＋１に対応するＵＲＬ時間スパンの境界の始まりがＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの単位で少なくともＴＭ×ＭＭティックだけＴよりも前にあり、かつ、セグメントＩの提示時間スパンがＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの単位で長くともＴＭ×ＭＭティックであり、セグメントＩの終わりがＴよりも前であり、従ってセグメントＩが利用可能であるからである。セグメントＩの提示開始時間は、最大でもＴよりも２×ＴＳｍａｘティック前にあることも、立証できる。ＡＨＳクライアントは、現在の実時間Ｔと、セグメントＩの提示開始時間との差が、例えば少なくとも２×ＴＳｍａｘになると、セグメントＩの再生を開始できる。

【0310】

ＡＨＳクライアントがセグメントＩをダウンロードすると、または、セグメントＩの提示終了時間へのアクセス権を有すると、ＡＨＳクライアントは、セグメントＩのすぐ後の次のセグメントＩ＋１の提示開始時間を決定でき、ＡＨＳクライアントは、セグメントＩ＋１がＴｉｎｄ＝Ｍ−ＭＭ＋１かつＳｉｎｄ＝２を有するかどうか、または、セグメントＩ＋１がＴｉｎｄ＝Ｍ−ＭＭ＋２かつＳｉｎｄ＝１を有するかどうか、すなわち、次のセグメントの提示開始時間がＴｉｍｅｓｃａｌｅＳｅｇＵＲＬの単位でＴＭ×（Ｍ−ＭＭ＋１）未満か、それに等しいか、それより大きいかを判定できる。このように続けて、ＡＨＳクライアントは常に、表示内で現在のセグメントの後のセグメントのＴｉｎｄとＳｉｎｄとを決定でき、従って次のセグメントのＵＲＬを決定できる。

【0311】

何らかの理由で、ＡＨＳクライアントが、Ｔｉｎｄ＝Ｍであるセグメントに対する有効に形成されたＵＲＬ要求に対して「ｎｏｔ ｆｏｕｎｄ」応答を受信し、ここでＵＲＬ要求がセグメントＵＲＬ交差規則構築に基づいて形成されている場合、ＡＨＳクライアントは、その欠落セグメントの後の後続のセグメントのＵＲＬを決定できないことがある。しかしながら、ＡＨＳクライアントは、利用可能なセグメントが見つかるまで、Ｎ＝Ｍ＋１、Ｍ＋２などに対し、Ｔｉｎｄ＝ＮかつＳｉｎｄ＝１に対応するＵＲＬを伴うセグメントに対する要求を発することができる。当然、ＡＨＳクライアントは、例えばセグメントが生成されライブで利用可能にされている場合、対応するセグメントが要求の時点で利用可能となるように、これら要求の時間を決めるべきである。従って、ＡＨＳクライアントが、例えばサーバまたはネットワーク配信のエラーにより、表示からのあるセグメントを欠いている場合、ＡＨＳクライアントは、利用可能な次に大きいＴｉｎｄ＝Ｎの値を伴う最初のセグメントへとスキップでき、これによって、欠落セグメントが原因の、可能な提示時間の再生の欠けの量が、ＴＭ／ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ秒という追加の因子のうちで最小限となる。

【0312】

ＡＨＳクライアントは、次のような戦略を使用して、第１の表示から第２の表示に切り替えることができる。ＴＭおよびＴｉｍｅｓｃａｌｅＳｅｇＵＲＬを、切り替え先となる第２の表示に対するものとし、何らかの正の整数ＭＭに対してＴＳｍａｘ＝ＴＭ×ＭＭとし、Ｔを、切り替えの決定が行われた実時間をＴｉｍｅｓｃａｌｅＳｅｇＵＲＬのティック単位で表したものとする。ＴがＴＭによって等しく分割可能である次の値に達すると、すなわち、Ｍ＝Ｔ／ＴＭが整数になるとすぐに、ＡＨＳクライアントは、第２の表示からのセグメントＩと呼ぶセグメントに対して、Ｔｉｎｄ＝Ｍ−ＭＭ＋１およびＳｉｎｄ＝１に対応するＵＲＬを生成し、セグメントＩの提示開始時間において第２の表示に切り替えることができる。一方、ＡＨＳクライアントは、第２の表示のセグメントＩの少なくとも提示開始時間まで再生できるようになるまで、第１の表示からのセグメントのダウンロードを続けて、次いで、第２の表示のセグメントＩの再生に切り替えることができる。この段落で説明された方法を使用して、実時間と再生された提示時間との差が少なくとも２×ＴＳｍａｘである場合、セグメントのダウンロードが要求される時と、セグメントの再生を開始するのに少なくとも十分なセグメントがＡＨＳクライアントに到達した時との間の時間を考慮せずに、第１の表示から第２の表示への切り替えを、詰まりまたは休止を何ら伴わずに実行できる。

【0313】

例として、セグメントＵＲＬ交差規則構築は、当業者が認識するように、拡張ＡＬＳクライアントに対する多くの利点を伴って、既存のＡＬＳシステムに次のように適用され得る。ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ値は１に設定されてよく、すなわち、常に毎秒１つのティックがある。ＴＭの値は、コンテンツの表示におけるセグメントの通知された長さから決定されてよく、例えば、セグメントの長さがコンテンツの表示に対して１０秒として通知された場合、ＴＭは、コンテンツのその表示に対しては１０に設定され、セグメントの長さがコンテンツの表示に対して６秒として通知された場合、ＴＭは、コンテンツのその表示に対しては６に設定される。セグメントＵＲＬ交差規則構築を組み込む、拡張ＡＬＳクライアントおよび拡張セグメントＵＲＬ生成器は、コンテンツの各表示に対して、同じＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ値とＴＭ値とを使用すべきである。前に説明されたように、拡張セグメントＵＲＬ生成器は、セグメントＵＲＬ交差規則構築を使用して、ＡＬＳコンテンツのセグメントのＵＲＬを生成し関連付けるべきであり、一方拡張ＡＬＳクライアントは、セグメントＵＲＬ交差規則構築を使用して、要求すべきセグメントのＵＲＬを決定すべきである。これら方法が既存のＡＬＳシステムに適用される場合、拡張セグメントＵＲＬ生成器はまた、既存のＡＬＳクライアントが修正されずに動作し続けることができるように、既存のセグメントＵＲＬによりコンテンツのセグメントＵＲＬのリストにおいて生成され明示的に提供されるようなＵＲＬを、追加で生成し関連付けることができる。あるいは、拡張セグメントＵＲＬ生成器は、セグメントＵＲＬ交差規則構築を使用して、ＡＬＳコンテンツのセグメントのＵＲＬを生成し関連付け、現在のＡＬＳセグメントＵＲＬリストフォーマット内のリストにおいて、各セグメントの最初のＵＲＬを追加で提供できるので、既存のＡＬＳクライアントは、これら明示的なセグメントＵＲＬリストを使用して、修正されずに動作できる。

【0314】

セグメントの少なくとも一部に割り当てられた２つ以上のＵＲＬが存在する可能性のある、セグメントＵＲＬテンプレート構築規則の多くの変形形態がある。例えば、セグメントの提示時間が増加する順序で同じＴｉｎｄ値を有するセグメントのＳｉｎｄ値を割り当てるのではなく、Ｓｉｎｄ値は、セグメントの提示時間の減少する順序で割り当てられてよい。

【0315】

セグメントＵＲＬ交差規則構造の変形形態として、規則は、ＥＰＴ_i＝ＳＰＴ_i+1となるように、提示開始時間および提示終了時間（ＳＰＴ₁，ＥＰＴ₁）、（ＳＰＴ₂，ＥＰＴ₂）、…、（ＳＰＴ_N，ＥＰＴ_N）に従って並べられたＵＲＬ時間スパン［ＴＭ×Ｍ，ＴＭ×（Ｍ＋１）］との提示時間の交差を伴うＮ個のセグメント１、２、…、Ｎがある場合、Ｔｉｎｄ＝Ｍに対するこれらＮ個のセグメントのＳｉｎｄ値は、それぞれ、０、１、…、Ｎ−１であるというものであり得る。

【0316】

セグメントＵＲＬ交差規則構築の別の変形形態は、あるセグメントに割り当てられる２つ以上のＵＲＬがある場合、例えばＮ＞１個のＵＲＬがあるセグメントに割り当てられる場合、セグメントの２つ以上のコピーが利用可能にされるというものであり得る。例えば、別個のファイルとして利用可能にされるセグメントのＮ個の別個のコピーが存在することがあり、各コピーは、そのコピーを参照しダウンロードするために使用されるそのコピーに割り当てられたちょうど１つのＵＲＬを有するということを除いて、他の各コピーと同一である。別の例として、セグメントの各コピーは同一ではなくてよく、すなわち、各コピーは、他の各コピーとちょうど同じ時間スパンを有し同じ表示に対するものであり得るが、異なるコピーは、異なる方法で符号化されたビデオであり得る。例えば、表示における切り替え先のセグメントとして使用され得るＳｉｎｄ＝１を有するコピーは、それらがＲＡＰで開始するように符号化されてよく、一方、同じ表示の前のセグメントから継続するように使用されるＳｉｎｄ＞１を有するコピーは、ＲＡＰではなく、代わりに同じ表示の前のセグメントからの参照フレームであるフレームを使用して、より効率的に符号化されてよい。

【0317】

別の変形形態として、２つ以上のＵＲＬ構築規則が同じ表示に対して規定されてよく、例えば、Ｓｉｎｄのインデクシングがセグメント提示時間の増加する順序であるＵＲＬ時間スパンと交差するセグメント時間スパンに基づく規則、Ｓｉｎｄのインデクシングがセグメント提示時間の減少する順序であるＵＲＬ時間スパンと交差するセグメント時間スパンに基づく規則、Ｓｉｎｄのインデクシングがセグメント提示開始時間の増加するまたは減少する順序であるＵＲＬ時間スパンに含まれるセグメント提示開始時間に基づく規則、Ｓｉｎｄのインデクシングがセグメント提示終了時間の増加するまたは減少する順序であるＵＲＬ時間スパンに含まれるセグメント提示終了時間に基づく規則、同じ表示に対して異なる値のＴＭまたはＴｉｍｅｓｃａｌｅＳｅｇＵＲＬを伴う規則、セグメント、セグメントマップ、または、セグメントもしくはセグメントマップの組合せに対する異なる規則であり得る。

【0318】

例えば、一般的なセグメントＵＲＬテンプレート構築規則は、次の形式であってよく、「Ｃｏｎｔｅｎｔ＿ＩＤ」はコンテンツを識別し、「Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＿ＩＤ」は表示を識別し、「Ｔｙｐｅ」は、「ＳＰＴ」、「ＥＰＴ」、または「ＩＮＴ」のいずれかであり、「Ｄｉｒｅｃｔｉｏｎ」は「Ｉ」または「Ｄ」のいずれかである。

【数7】

【0319】

上のデータ構造では、「Ｔｙｐｅ」は規則のタイプを示し、すなわち、タイプが「ＳＰＴ」である場合、規則はセグメント提示開始時間に基づき、タイプが「ＥＰＴ」である場合、規則はセグメント提示終了時間に基づき、タイプが「ＩＮＴ」である場合、規則はセグメント交差に基づく。「Ｄｉｒｅｃｔｉｏｎ」はＳｉｎｄのインデクシングの方向を示し、「Ｄｉｒｅｃｔｉｏｎ」が「Ｉ」である場合、Ｓｉｎｄのインデクシングはセグメント提示時間が増加する順序であり、「Ｄｉｒｅｃｔｉｏｎ」が「Ｄ」である場合、Ｓｉｎｄのインデクシングはセグメント提示時間が減少する順序である。

【0320】

一例として、ＵＲＬテンプレート構築規則

【数8】

【0321】

は、コンテンツおよび表示が「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−５−１．１．３ｇｓ」によって識別される規則を示し、「ＩＮＴ」は、規則が前に定義されたようなセグメント交差規則であることを示し、「Ｉ」は、Ｓｉｎｄのインデクシングがセグメント提示時間に関して増加することを示す。ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝１かつＴＭ＝２０なので、この規則によって定義される各ＵＲＬ時間スパンは、長さが２０秒である。

【0322】

簡単なセグメントＵＲＬテンプレートの生成
セグメントＵＲＬは、テンプレートに従って生成されてよく、この場合、テンプレートおよび／または構築規則は、セグメント要求を行うクライアントに対してコンパクトに搬送される。これらテンプレート／規則は、簡単であってもよく複雑であってもよい。セグメントＵＲＬの生成およびＵＲＬテンプレートの生成のための簡単な処理が、例としてここで説明される。

【0323】

前のセクションで説明された表記を維持し、ＴＭは、ティックの単位で表される提示時間のパラメータであり、ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬは、１秒当たりのティックの数である。ＵＲＬテンプレートの生成のために（および場合によって他の目的のために）、両方がティックの単位で表される提示時間のパラメータである、２つの追加のパラメータＤｅｌｔａＭｉｎｕｓおよびＤｅｌｔａＰｌｕｓがある。従って、ＵＲＬテンプレート構築規則の例は、次のデータ構造を使用し得る。

【数9】

【0324】

上のデータ構造では、Ｓｉｎｄは、クライアントに渡される可能性があり、または他の方法でクライアントによって取得される可能性があり、Ｓｉｎｄは、次のように解釈されるべきであるＵＲＬテンプレート構築規則に対する正の整数の変数である。Ｓｉｎｄ＝ｉであるセグメントに対して、ＵＲＬ ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−８．ｉ．３ｇｐを有するセグメントでは、セグメントの提示開始時間ＳＰＴは、値（ＴＭ×Ｉ−ＤｅｌｔａＭｉｎｕｓ）／ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬによって規定される時間（秒単位の）で開始し、値（ＴＭ×Ｉ＋ＤｅｌｔａＰｌｕｓ）／ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬによって規定される時間（秒単位の）で終了する、提示時間間隔内にある。

【0325】

例えば、上の例でＳｉｎｄ＝１７である場合、ＵＲＬ ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ａｈｓ−８．１７．３ｇｐを有するセグメントの提示開始時間ＳＰＴは、５０×１７−４ティックと５０×１７＋６ティックとの間にあり、または等価的に、提示時間８４．６秒と提示時間８５．６秒との間にある。従って、この例では、セグメントの開始時間は、１秒の提示時間間隔内に入り、一方、平均のセグメントの長さはおよそ、ＴＭ／ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ＝５秒である。所望の提示開始時間から、クライアントは、計算を簡単に実行して、要求すべきセグメントを厳密に導出でき、または、そうではなくても効率的であるように十分近いセグメントを導出できる。

【0326】

常にではないが通常、ＤｅｌｔａＭｉｎｕｓおよびＤｅｌｔａＰｌｕｓはＴＭより小さい。しかしながら、ＴＭよりも大きなＤｅｌｔａＭｉｎｕｓまたはＤｅｌｔａＰｌｕｓを許容することで利益が得られる場合がある。

【0327】

上の方法の１つの利益は、ビデオ符号化処理に柔軟性を与えるということであり、すなわち、セグメントの提示開始時間に柔軟性を与えることは、いくつかの場合には各セグメントの始まりにあるＳＡＰの提示時間に、柔軟性を与える。ＳＡＰは多くの場合ＩＤＲフレームなので、ビデオ符号化処理によって生成されるＩＤＲフレームの提示時間に柔軟性があることで、ビデオ符号化処理は、一定の提示時間間隔において生成されたＩＤＲフレームを伴うビデオ圧縮と比較して、同じストリームレートに対してより良好な圧縮を提供することが可能になる。

【0328】

さらなる利益は、方法が、ＴＭ＋ＤｅｌｔａＭｉｎｕｓ＋ＤｅｌｔａＰｌｕｓ以下であり得るエンドツーエンドのレイテンシと、ＩＤＲフレームの位置についてのビデオ圧縮の柔軟性とのトレードオフに対する制御を提供することである。さらなる利益は、ＡＨＳクライアントが、（ＤｅｌｔａＭｉｎｕｓ＋ＤｅｌｔａＰｌｕｓ）／ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬ秒という設定可能な精度の範囲内で、前のまたは後のセグメントについての情報を参照することなく、大まかな提示時間の推定に基づいて、ＡＨＳクライアントの要求すべきセグメントのＵＲＬを生成することが可能になることである。

【0329】

さらなる利益は、方法が、前のまたは後のセグメントまたはＵＲＬについての情報を参照することなく、セグメントに関連するＵＲＬとをサーバが生成することを可能にすることである。これは特に、冗長サーバによるライブストリーミング解決法をサポートする際に有益であることがある。セグメントとＵＲＬとを生成する第１のサーバがクラッシュし、新たな第２のサーバがオンラインとなり前のファイルサーバを置き換える場合、第２のサーバは、クラッシュした第１のサーバの状態とは無関係に、後続のセグメントとＵＲＬとを生成できる。ビデオコンテンツおよびセグメントおよび第２のサーバにより生成されるＵＲＬの断絶を短くでき、この断絶の長さは、第１のサーバがクラッシュしてから第２のサーバが第１のサーバを置き換えるまでの時間間隔に、（ＤｅｌｔａＭｉｎｕｓ＋ＤｅｌｔａＰｌｕｓ）／ＴｉｍｅｓｃａｌｅＳｅｇＵＲＬに比例する時間間隔を足したものに関連する。

【0330】

上の方法の１つの変形形態では、所定の時間間隔内に入るというセグメントの提示開始時間に対する制約は、セグメントの始まりにあるＳＡＰを伴うセグメントにのみ適用される。上の方法の別の変形形態では、セグメントの提示開始時間に対する制約は、何らかの一定の正の整数ＳＡＰ＿ＦＲＥＱの倍数であるインデックスＳｉｎｄを有するセグメントのみに対して適用され、ＳＡＰ＿ＦＲＥＱの倍数であるインデックスＳｉｎｄを有するセグメントのみが、シグナリングされたＳＡＰ内で開始することを要求される。

【0331】

本開示を読んだ当業者が認識するように、上の方法には多くの他の変形形態が存在する。例として、ＤｅｌｔａＭｉｎｕｓおよびＤｅｌｔａＰｌｕｓの値は、各適合セットに対するＭＰＤにおいてシグナリングされてよく、または、適合セット内の表示ごとにシグナリングされてよく、または、全ての適合セットに対して全体的にシグナリングされてよい。他の例として、ＤｅｌｔａＭｉｎｕｓとＤｅｌｔａＰｌｕｓの値の１つまたは両方は、明示的にシグナリングされなくてよく、例えば事前に定義されたプロファイルに基づいて、所定の値に設定されてよい。例えば、事前に定義されたプロファイルに対して、ＤｅｌｔａＭｉｎｕｓは０と定義されてよく、ＤｅｌｔａＰｌｕｓはＴＭ／２と定義されてよい。別の例として、ＤｅｌｔａＭｉｎｕｓおよびＤｅｌｔａＰｌｕｓは、ＤｅｌｔａＭｉｎｕｓおよびＤｅｌｔａＰｌｕｓの値がＭＰＤにおいて明示的に与えられる場合にのみ覆される、所定のデフォルト値を有し得る。他の例として、単一のシグナリングされるパラメータＤｅｌｔａしかなくてよく、ＤｅｌｔａＭｉｎｕｓおよびＤｅｌｔａＰｌｕｓの値は両方ともＤｅｌｔａに設定され、または、ＤｅｌｔａＭｉｎｕｓは０に設定されＤｅｌｔａＰｌｕｓはＤｅｌｔａに設定される。別の例として、ＤｅｌｔａＭｉｎｕｓおよびＤｅｌｔａＰｌｕｓは、他のパラメータから導出されてよく、例えば、ＤｅｌｔａＭｉｎｕｓおよびＤｅｌｔａＰｌｕｓの代わりにシグナリングされるＦｒａｃＤｅｌｔａＭｉｎｕｓおよびＦｒａｃＤｅｌｔａＰｌｕｓという２つのパラメータがあり、ＤｅｌｔａＭｉｎｕｓはＦｒａｃＤｅｌｔａＭｉｎｕｓ×ＴＭに設定され、ＤｅｌｔａＰｌｕｓはＦｒａｃＤｅｌｔａＰｌｕｓ×ＴＭに設定される。

【0332】

ハードウェアシステムの概要
様々なプラットフォームで動作できる様々な実施形態、特徴、方法などが、上で説明された。このセクションは、上の教示と共に使用され得るいくつかの具体的なハードウェアプラットフォームを詳しく説明する。

【0333】

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

【0334】

コンテンツは、動画、オーディオ、２Ｄ平面ビデオ、３Ｄビデオ、他のタイプのビデオ、画像、時間指定されたテキスト、時間指定されたメタデータなどを備え得る。いくつかのコンテンツは、時間指定された方式で提示または消費されるべきデータ、例えば、再生されている他のメディアと共に補助的な情報を提示するためのデータ（通信局識別、広告、株式市況、Ｆｌａｓｈ（商標）シーケンスなど）を伴い得る。他のメディアを結合し、かつ／または単なるオーディオおよびビデオを越える、他のハイブリッド提示も使用され得る。

【0335】

図１９に示されるように、メディアブロックは、ブロックサービング設備１８０１（１）内に格納されてよく、ブロックサービング設備１８０１（１）は例えば、ＨＴＴＰサーバ、コンテンツ配信ネットワークデバイス、ＨＴＴＰプロキシ、ＦＴＰプロキシまたはサーバ、または何らかの他のメディアサーバもしくはシステムであり得る。ブロックサービング設備１８０１（１）はネットワーク１８２２に接続され、ネットワーク１８２２は例えば、インターネットのようなインターネットプロトコル（「ＩＰ」）ネットワークであり得る。６個の機能コンポーネント、すなわち、上で説明されたメタデータを与えられ、メタデータによって示される複数の利用可能なブロックのうちから要求されるべきブロックまたは部分的なブロックを選択する機能を実行する、ブロック選択器１８２３と、ブロック選択器１８２３から要求命令を受信し、規定されたブロック、ブロックの一部、または複数のブロックに対する要求を、ネットワーク１８２２を通じてブロックサービング設備１８０１（１）に送信し、返答としてブロックを備えるデータを受信する必要のある動作を実行する、ブロック要求器１８２４と、さらに、ブロックバッファ１８２５と、バッファモニタ１８２６と、メディアデコーダ１８２７と、メディア消費を支援する１つまたは複数のメディアトランスデューサ１８２８とを有する、ブロック要求ストリーミングシステムクライアントが示される。

【0336】

ブロック要求器１８２４によって受信されるブロックデータは、メディアデータを格納するブロックバッファ１８２５に、一時的な格納のために渡される。あるいは、受信されたブロックデータは、図１８に示されるように、ブロックバッファ１８２５に直接格納され得る。メディアデコーダ１８２７は、ブロックバッファ１８２５によってメディアデータを与えられ、メディアトランスデューサ１８２８に適切な入力を提供するのに必要な変換をこのデータに対して実行し、メディアトランスデューサ１８２８は、メディアを、ユーザまたは他の消費に対して適した形式にする。メディアトランスデューサの例は、携帯電話、コンピュータシステム、またはテレビジョンにおいて見出されるような視覚ディスプレイデバイスを含み、スピーカまたはヘッドフォンのようなオーディオレンダリングデバイスも含み得る。

【0337】

メディアデコーダの例は、Ｈ．２６４ビデオコーディング規格で表されたフォーマットのデータを、ビデオフレームのアナログまたはデジタルの表現、例えば、各フレームまたはサンプルに対する関連する提示タイムスタンプを伴うＹＵＶフォーマットのピクセルマップへと変換する、関数である。

【0338】

バッファモニタ１８２６は、ブロックバッファ１８２５のコンテンツに関する情報を受信し、この情報および場合によって他の情報に基づいて、ブロック選択器１８２３に対する入力を提供し、ブロック選択器１８２３は、本明細書で説明されるように、要求すべきブロックの選択を決定するために使用される。

【0339】

本明細書で使用される用語法では、各ブロックは、そのブロックに含まれるメディアを受信機が通常の速度で再生するのにかかる時間を表す、「再生時間(playout time)」または「長さ(duration)」を有する。いくつかの場合には、ブロック内のメディアの再生は、前のブロックからのデータを既に受信していることに依存し得る。まれに、ブロック内のメディアの一部の再生は、後続のブロックに依存することがあり、この場合、ブロックの再生時間は、後続のブロックを参照せずにブロック内で再生され得るメディアに関して定義され、後続のブロックの再生時間は、後続のブロックを受信した後にのみ再生できるこのブロック内のメディアの再生時間の分、増加する。後続のブロックに依存するメディアをブロック内に含むことはまれであるので、本開示の残りでは、あるブロック内のメディアは後続のブロックに依存しないと仮定するが、この変形形態は以下で説明される実施形態に容易に追加され得ることを当業者は認識するであろうことに、留意されたい。

【0340】

受信機は、ブロックを異なるレートの再生により消費させ得る、「一時停止(pause)」、「早送り(fast forward)」、「巻き戻し(fast forward)」などのような制御機能を有し得るが、受信機が、シーケンスにおける最後のブロックを除く総再生時間以下の、全体の時間のうちの各々の連続するブロックのシーケンスを取得し復号できれば、受信機は、ストールすることなくメディアをユーザに提示できる。本明細書の説明の一部では、メディアストリームにおける特定の位置は、メディアにおける特定の「時間(time)」と呼ばれ、これは、メディア再生の始まりと、ビデオストリームのその特定の位置に達した時間との間で経過した時間に対応する。メディアストリームにおける時間または位置は、従来からある概念である。例えば、ビデオストリームが毎秒２４フレームを備える場合、最初のフレームはｔ＝０．０秒の位置あるいは時間を有すると言うことができ、２４１番目のフレームは、ｔ＝１０．０秒の位置あるいは時間を有すると言うことができる。当然、フレームに基づくビデオストリームにおいて、位置または時間は連続的である必要はなく、それは、２４１番目のフレームの最初のビットから２４２番目のフレームの最初のビットのすぐ前までのストリームにおけるビットの各々は、全て同じ時間の値を有し得るからである。

【0341】

上記の用語法を採用すると、ブロック要求ストリーミングシステム（ＢＲＳＳ）は、１つまたは複数のコンテンツサーバ（例えば、ＨＴＴＰサーバ、ＦＴＰサーバなど）に対して要求を行う１つまたは複数のクライアントを備える。取込システムは、１つまたは複数の取込プロセッサを備え、取込プロセッサは、コンテンツを受信し（リアルタイムで、または非リアルタイムで）、ＢＲＳＳによる使用のためにコンテンツを処理し、場合によって取込プロセッサによって生成されたメタデータと共に、コンテンツサーバがアクセス可能な記憶装置へとコンテンツを格納する。

【0342】

ＢＲＳＳはまた、コンテンツサーバと協調するコンテンツキャッシュを含み得る。コンテンツサーバおよびコンテンツキャッシュは、ＨＴＴＰ要求の形式で、ファイルまたはセグメントに対する要求を受信する、従来のＨＴＴＰサーバおよびＨＴＴＰキャッシュであってよく、ＨＴＴＰ要求は、ＵＲＬを含み、ＵＲＬによって示されるファイルまたはセグメントの全てよりも少ないファイルまたはセグメントを要求するために、あるバイト範囲も含み得る。クライアントは、ＨＴＴＰサーバの要求を行いそれらの要求に対する応答を処理する、従来のＨＴＴＰクライアントを含んでよく、ＨＴＴＰクライアントは、新規のクライアントシステムによって駆動され、新規のクライアントシステムは、要求を編成し、要求をＨＴＴＰクライアントに渡し、ＨＴＴＰクライアントから応答を得て、クライアントデバイスによる再生のために提示プレーヤに要求を提供するために要求を処理（または格納、変換など）する。通常、クライアントシステムは、どのメディアが必要とされるであろうかを前もって知らず（需要は、ユーザの入力、ユーザの入力の変化などに依存し得るので）、よって、メディアが受信されるとすぐに、またはメディアが受信されてからまもなく、メディアが「消費される」という点で、クライアントシステムは「ストリーミング」システムであると言われる。その結果、応答の遅延および帯域幅の制約は、提示の遅延を引き起こすことがあり、例えば、ユーザが提示を消費している箇所にストリームが追いつくと、提示の停止が発生する。

【0343】

良好な品質であると知覚される提示を提供するために、ＢＲＳＳにおいて、クライアント側で、取り込み側で、またはこれら両方のいずれかで、多数の項目が実装され得る。いくつかの場合には、実装される項目は、ネットワークにおけるクライアントとサーバのインターフェースを考慮して、かつそれを扱うように行われる。いくつかの実施形態では、クライアントシステムと取込システムの両方が拡張を認識し、一方他の実施形態では、一方の側のみが拡張を認識する。そのような場合、一方が拡張を認識しない場合でも、システム全体は拡張による利益を受け、他の場合には、両方が拡張を認識する場合にのみ利益は発生するが、一方が認識しなくても、障害を起こすことなく動作する。

【0344】

図２０に示されるように、取込システムは、様々な実施形態によれば、ハードウェアコンポーネントとソフトウェアコンポーネントの組合せとして実装され得る。取込システムは、本明細書で論じられる方法の任意の１つまたは複数をシステムに実行させるように実行され得る、命令のセットを備え得る。システムは、コンピュータの形式の特定の機械として実現され得る。システムは、サーバコンピュータ、パーソナルコンピュータ（ＰＣ）、または、そのシステムによってとられるべき動作を規定する（順次的なまたは他の方式の）命令のセットを実行することが可能な任意のシステムであってよい。さらに、単一のシステムのみが示されるが、「システム」という用語はまた、命令のセット（または複数のセット）を個々にまたは一緒に実行して、本明細書で論じられる方法の任意の１つまたは複数を実行する、システムの任意の集合体を含むものと解釈されるべきである。

【0345】

取込システムは、取込プロセッサ２００２（例えば、中央処理装置（ＣＰＵ））と、実行の間プログラムコードを格納し得るメモリ２００４と、ディスク記憶装置２００６とを含んでよく、これら全てが、バス２０００を介して互いに通信する。システムはさらに、ビデオディスプレイユニット２００８（例えば、液晶ディスプレイ（ＬＣＤ）または陰極線管（ＣＲＴ））を含み得る。システムはまた、英数字入力デバイス２０１０（例えば、キーボード）と、コンテンツソースを受信しコンテンツ記憶装置を送達するためのネットワークインターフェースデバイス２０１２とを含み得る。

【0346】

ディスク記憶装置ユニット２００６は、本明細書で説明される方法または機能の任意の１つまたは複数を具現化する命令（例えば、ソフトウェア）の１つまたは複数のセットが格納され得る、機械可読媒体を含み得る。命令はまた、システムによる命令の実行の間、完全に、または少なくとも部分的に、メモリ２００４および／または取込プロセッサ２００２内に存在してよく、メモリ２００４および取込プロセッサ２００２も、機械可読媒体を構成する。

【0347】

図２１に示されるように、クライアントシステムは、様々な実施形態によれば、ハードウェアコンポーネントとソフトウェアコンポーネントの組合せとして実装され得る。クライアントシステムは、本明細書で論じられる方法の任意の１つまたは複数をシステムに実行させるように実行され得る、命令のセットを備え得る。システムは、コンピュータの形式の特定の機械として実現され得る。システムは、サーバコンピュータ、パーソナルコンピュータ（ＰＣ）、または、そのシステムによってとられるべき動作を規定する（順次的なまたは他の方式の）命令のセットを実行することが可能な任意のシステムであってよい。さらに、単一のシステムのみが示されるが、「システム」という用語はまた、命令のセット（または複数のセット）を個々にまたは一緒に実行して、本明細書で論じられる方法の任意の１つまたは複数を実行する、システムの任意の集合体を含むものと解釈されるべきである。

【0348】

クライアントシステムは、クライアントプロセッサ２１０２（例えば、中央処理装置（ＣＰＵ））と、実行の間プログラムコードを格納し得るメモリ２１０４と、ディスク記憶装置２１０６とを含んでよく、これら全てが、バス２１００を介して互いに通信する。システムはさらに、ビデオディスプレイユニット２１０８（例えば、液晶ディスプレイ（ＬＣＤ）または陰極線管（ＣＲＴ））を含み得る。システムはまた、英数字入力デバイス２１１０（例えば、キーボード）と、要求を送信し応答を受信するためのネットワークインターフェースデバイス２１１２とを含み得る。

【0349】

ディスク記憶装置ユニット２１０６は、本明細書で説明される方法または機能の任意の１つまたは複数を具現化する命令（例えば、ソフトウェア）の１つまたは複数のセットが格納され得る、機械可読媒体を含み得る。命令はまた、システムによる命令の実行の間、完全に、または少なくとも部分的に、メモリ２１０４および／またはクライアントプロセッサ２１０２内に存在してよく、メモリ２１０４およびクライアントプロセッサ２１０２も、機械可読媒体を構成する。

【0350】

高度な方法の概要
次のセクションでは、改善されたブロック要求ストリーミングシステムのための方法が説明される。これら改善の一部は、適用形態における必要性に応じて、これら改善のうちの他のものと共に、またはそれらを伴わずに使用され得ることを理解されたい。一般的な動作では、受信機は、データの特定のブロックまたはブロックの部分に対する、サーバまたは他の送信機への要求を行う。セグメントとも呼ばれるファイルは、複数のブロックを含んでよく、メディア提示の１つの表示に関連付けられる。

【0351】

好ましくは、再生時間または復号時間から、セグメント内の対応するブロックまたはフラグメントのバイトオフセットへのマッピングを提供する、「セグメントインデクシング(segment indexing)」または「セグメントマップ(segment map)」とも呼ばれるインデックス情報が生成される。このセグメントインデクシングは、セグメント内に、通常はセグメントの始めに含まれることがあり（セグメントマップの少なくとも一部は始めにある）、小さいことが多い。セグメントインデックスはまた、別個のインデックスセグメントまたはファイルにおいて提供されることがある。セグメントインデックスがセグメント内に含まれる場合は特に、受信機は、このセグメントマップの一部または全てを高速にダウンロードし、続いてこれを使用して、時間オフセットと、ファイル内でのその時間オフセットに関連付けられるフラグメントの対応するバイト位置とのマッピングを決定できる。

【0352】

受信機は、バイトオフセットを使用して、関心のある時間オフセットに関連付けられない他のフラグメントに関連付けられるデータの全てをダウンロードする必要なく、特定の時間オフセットに関連付けられるフラグメントからのデータを要求できる。このようにして、セグメントマップまたはセグメントインデクシングは、関心のある現在の時間オフセットに関連するセグメントの部分に直接アクセスするための受信機の能力を大きく向上させることができ、コンテンツザッピング時間が改善することと、ネットワーク条件が変化するに従ってある表示から別の表示へ高速に変更できることと、受信機で再生されないメディアをダウンロードすることでネットワークリソースを無駄にすることが減ることとを含む利益を伴う。

【0353】

ある表示（本明細書では「切り替え前の(switch-from)」表示と呼ばれる）から別の表示（本明細書では「切り替え先の(switch-to)」表示と呼ばれる）への切り替えを考える場合、セグメントインデックスはまた、切り替え先の表示におけるランダムアクセスポイントの開始時間を識別し、切り替え前の表示において要求されることになるデータの量を識別し、切り替え先の表示の再生がランダムアクセスポイントからシームレスに開始できるように切り替え前の表示におけるメディアが提示時間までダウンロードされるという意味で、シームレスな切り替えが可能になることを確実にするために、使用され得る。

【0354】

それらのブロックは、受信機のユーザに対する出力を生成するために要求側の受信機が必要とする、ビデオメディアまたは他のメディアのセグメントを表す。メディアの受信機は、例えば受信機がコンテンツを送信するサーバからコンテンツを受信する場合、クライアントデバイスであってよい。例には、セットトップボックス、コンピュータ、ゲームコンソール、特別に装備されたテレビジョン、ハンドヘルドデバイス、特別に装備された携帯電話、または他のクライアント受信機がある。

【0355】

多くの高度なバッファ管理方法が本明細書で説明される。例えば、バッファ管理方法は、時間内に受信され得る最高のメディア品質のブロックが連続して再生されるように、クライアントが要求することを可能にする。可変ブロックサイズ機構が、圧縮の効率を改善する。要求するデバイスにブロックを送信しつつ要求の頻度を制限するための複数の接続を得る能力が改善された送信性能を提供する。部分的に受信されたブロックのデータが、メディア提示を継続するために使用され得る。接続は、ブロックの特定のセットへの接続を最初から約束する必要なく、複数のブロックに対して再使用され得る。複数のクライアントによる複数の可能性のあるサーバのうちからのサーバの選択の一貫性が改善され、これによって、近くのサーバにおけるコンテンツの重複の頻度が下がり、サーバがファイル全体を含む確率が上がる。クライアントは、メディアブロックを含むファイルのＵＲＬに埋め込まれるメタデータ（利用可能なメディア符号化物など）に基づいて、メディアブロックを要求できる。システムは、今後メディア再生の停止を引き起こすことなくコンテンツの再生が開始できるようになるまでに必要なバッファリング時間を計算し、それを最小化できる。利用可能な帯域幅は、複数のメディアブロックの間で共有されてよく、各ブロックの再生時間が近づくと調整されてよいので、必要であれば、利用可能な帯域幅のうちより大きな割合が、最も近い再生時間を有するブロックに割り当てられ得る。

【0356】

ＨＴＴＰストリーミングは、メタデータを利用し得る。提示レベルメタデータは、例えば、ストリームの長さ、利用可能な符号化（ビットレート、コーデック、空間解像度、フレームレート、言語、メディアタイプ）、各符号化物のためのストリームメタデータに対するポインタ、および、コンテンツ保護（デジタル著作権管理（ＤＲＭ）情報）を含む。ストリームメタデータは、セグメントファイルに対するＵＲＬであり得る。

【0357】

セグメントメタデータは、セグメント内の要求に対するバイト範囲対時間の情報と、ランダムアクセスポイント（ＲＡＰ）または他の探索点の識別情報とを含んでよく、この情報の一部または全てが、セグメントインデクシングまたはセグメントマップの一部であり得る。

【0358】

ストリームは、同じコンテンツの複数の符号化物を備え得る。各符号化物は次いで、セグメントへと分割されてよく、各セグメントは、記憶単位またはファイルに対応する。ＨＴＴＰの場合、セグメントは通常、ＵＲＬによって参照され得るリソースであり、そのようなＵＲＬの要求は、要求応答メッセージのエンティティ本体として、セグメントの返信をもたらす。セグメントは、複数のピクチャのグループ（ＧｏＰ）を備え得る。各ＧｏＰはさらに、複数のフラグメントを備えてよく、セグメントインデクシングは、各フラグメントの時間／バイトオフセット情報を提供し、すなわち、インデクシングの単位はフラグメントである。

【0359】

フラグメントまたはフラグメントの部分は、スループットを向上させるために、並列ＴＣＰ接続を通じて要求され得る。このことは、ボトルネックリンク上の接続を共有する時、または、混雑により接続が失われた時に発生する問題を軽減できるので、全体の配信の速度と信頼性とを高め、コンテンツザッピング時間の速度と信頼性とをかなり高めることができる。帯域幅は、過剰な要求によるレイテンシと引き換えであり得るが、帯域幅窮乏のリスクを高め得る、遠すぎる未来に対する要求の実行を避けるように、留意しなければならない。

【0360】

同じサーバ上でのセグメントに対する複数の要求は、反復的なＴＣＰ始動遅延を避けるために、パイプライン化され得る（現在の要求が完了する前に次の要求を行う）。連続するフラグメントに対する要求は、１つの要求に統合され得る。

【0361】

一部のＣＤＮは、大きなファイルを好み、範囲要求を最初に見た時に、元のサーバからのファイル全体のバックグラウンドフェッチをトリガし得る。しかしながら、大半のＣＤＮは、データが利用可能である場合に、キャッシュからの範囲要求に応対する。従って、クライアント要求の一部分をセグメントファイル全体に対するものとすることが、有利であり得る。これら要求は、必要であれば後で取り消され得る。

【0362】

有効な切替点は、目標のストリームにおける探索点、具体的には例えばＲＡＰであり得る。複数のストリームにわたる一定のＧｏＰ構造またはＲＡＰの整列（メディアの始まりに基づく、またはＧｏＰに基づく）のような、異なる実装形態が可能である。

【0363】

一実施形態では、セグメントおよびＧｏＰは、異なるレートのストリームにわたって揃えられ得る。この実施形態では、ＧｏＰは、可変のサイズであってよく、複数のフラグメントを含んでよいが、フラグメントは、異なるレートのストリームの間で揃えられない。

【0364】

いくつかの実施形態では、ファイル冗長性が、利益を得るために利用され得る。これら実施形態では、データの冗長なバージョンを生成するために、消去コードが各フラグメントに適用される。好ましくは、ソースのフォーマットは、ＦＥＣの使用により変化せず、例えば、元の表示の従属する表示として、ＦＥＣ修復データを含む追加の修復セグメントが、取込システムにおいて追加のステップとして生成され利用可能にされる。そのフラグメントのソースデータのみを使用してフラグメントを再構築することが可能なクライアントは、セグメント内のフラグメントのソースデータのみを、サーバから要求できる。サーバが利用不可能である場合、またはサーバに対する接続が遅い場合、これはソースデータに対する要求の前または後のいずれかで判定され得るが、追加の修復データが、修復セグメントからのフラグメントに対して要求されてよく、これは、フラグメントを復元するのに十分なデータを信頼性をもって送達するための時間を短縮し、場合によってＦＥＣの復号を使用して、受信されたソースと修復データの組合せを使用しフラグメントのソースデータを回復する。さらに、フラグメントが差し迫ると、すなわち、その再生時間が差し迫ると、フラグメントの復元を可能にするための追加の修復データが要求されてよく、これは、リンク上でのそのフラグメントのためのデータの割合を高めるが、帯域幅を空けるためにリンク上の他の接続を切断するよりも効率的である。これはまた、並列接続の使用による窮乏のリスクを軽減し得る。

【0365】

フラグメントフォーマットは、リアルタイム転送制御プロトコルＲＴＣＰを通じて達成されたオーディオ／ビデオの同期を伴う、リアルタイム転送プロトコル（ＲＴＰ）パケットの格納ストリームであり得る。

【0366】

セグメントフォーマットはまた、ＭＰＥＧ−２ＴＳ内部タイミングにより達成されたオーディオ／ビデオの同期を伴う、ＭＰＥＧ−２ＴＳパケットの格納ストリームであり得る。

【0367】

１．ストリーミングをより効率的にするためのシグナリングおよび／またはブロック作成の使用
改善された性能を提供するために、ブロック要求ストリーミングシステムにおいて、多数の特徴が使用されてもされなくてもよい。性能は、ストールすることなく提示を再生し、帯域幅の制約の範囲内でメディアデータを取得し、かつ／または、クライアント、サーバ、および／もしくは取込システムにおける限られたプロセッサリソースの範囲内でそのようにすることの、能力に関連し得る。これら特徴の一部が、ここで説明される。

【0368】

２．セグメント内でのインデクシング
動画フラグメントに対するｐａｒｔｉａｌ ＧＥＴ ｒｅｑｕｅｓｔを編成するために、クライアントは、ファイルまたはセグメント内のフラグメントに含まれる全てのメディアコンポーネントの復号時間または提示時間内の、バイトオフセットおよび開始時間を知らされてよく、また、どのフラグメントがランダムアクセスポイントを開始し含むか（かつ、従ってどのフラグメントが代替的な表示の切替点として使用されるのに適しているか）を知らされてよく、この情報は、セグメントインデクシングまたはセグメントマップと呼ばれることが多い。復号時間または提示時間内の開始時間は、直接表されてよく、または、基準時間に対する差分として表されてよい。

【0369】

この時間およびバイトオフセットのインデクシング情報は、動画フラグメント当たり少なくとも８バイトのデータを必要とし得る。例として、５００ｍｓの動画フラグメントを伴う、単一のファイル内に含まれる２時間の動画では、これは全体で約１１２キロバイトのデータとなる。提示を開始する時にこのデータの全てをダウンロードすることは、大きな追加の始動遅延をもたらし得る。しかしながら、クライアントが、開始を望む提示の時点に関連する時間およびオフセットのデータの小さなかたまりを迅速に発見できるように、時間およびバイトオフセットのデータは、階層的に符号化され得る。この情報はまた、セグメントインデックスの何らかの改良版がメディアデータと交互になるように配置され得るように、セグメント内で分布していてよい。

【0370】

各セグメントに対する完全な時間およびオフセットのデータは、既に非常に小さいことがあるので、表示が時間方向に複数のセグメントへとセグメント化される場合、この階層的なコーディングの使用は必要ではないことがあることに留意されたい。例えば、上の例でセグメントが２時間ではなく１分である場合、時間とバイトオフセットのインデクシング情報は、１キロバイト前後のデータであり、これは通常、単一のＴＣＰ／ＩＰパケット内に収まり得る。

【0371】

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

【0372】

第１に、Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｂｏｘ（「ＭＦＲＡ」）が、この目的で使用され得る。ＭＦＲＡは、動画フラグメントを使用するファイルにおいてランダムアクセスポイントを見つける際に読者を支援し得る、表を提供する。この機能を支援するために、ＭＦＲＡは、ランダムアクセスポイントを含むＭＦＲＡボックスのバイトオフセットを付随して含む。ＭＦＲＡは、ファイルの終わりにおいて、またはその近くに配置され得るが、そうであるとは限らない。Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｏｆｆｓｅｔ Ｂｏｘに対するファイルの終わりからスキャンし、その中のサイズ情報を使用することによって、Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｂｏｘの始まりを見つけることが可能になり得る。しかしながら、ＨＴＴＰストリーミングの終わりにＭＦＲＡを配置すると、通常、所望のデータにアクセスするために、少なくとも１つはファイルの終わりからのＭＦＲＡを要求するための要求、１つはＭＦＲＡを取得するための要求、そして最後の１つはファイルにおける所望のフラグメントを取得するための要求という、少なくとも３〜４個のＨＴＴＰ要求が必要となる。従って、始めに配置することが、ＭＦＲＡを単一の要求で第１のメディアデータと共にダウンロードできるので、望ましいことがある。また、ＨＴＴＰストリーミングに対してＭＦＲＡを使用することは非効率であることがあり、それは、時間およびｍｏｏｆ＿ｏｆｆｓｅｔ以外の「ＭＦＲＡ」内の情報のいずれもが必要とされず、長さの代わりにオフセットを規定することはより多くのビットを必要とし得るからである。

【0373】

第２に、Ｉｔｅｍ Ｌｏｃａｔｉｏｎ Ｂｏｘ（「ＩＬＯＣ」）が使用され得る。「ＩＬＯＣ」は、メタデータリソースを含むファイルと、そのファイル内でのメタデータリソースのオフセットと、メタデータリソースの長さとを特定することによって、このファイルまたは他のファイルにおけるメタデータリソースのディレクトリを与える。例えば、システムは、全ての外部から参照されたメタデータリソースを１つのファイルに統合でき、それに従って、ファイルのオフセットとファイルの参照とを再調整する。しかしながら、「ＩＬＯＣ」は、メタデータの位置を与えることが意図されているので、実際のメタデータと共存するのは難しいことがある。

【0374】

最後は、最も適切である可能性があるが、Ｔｉｍｅ Ｉｎｄｅｘ Ｂｏｘ（「ＴＩＤＸ」）と呼ばれる新たなボックスを規定することであり、ＴＩＤＸは、正確なフラグメントの時間または長さとバイトオフセットとを効率的に与えるための専用のボックスである。これは、次のセクションでより詳しく説明される。同じ機能を有する代替的なボックスは、Ｓｅｇｍｅｎｔ Ｉｎｄｅｘ Ｂｏｘ（「ＳＩＤＸ」）であり得る。本明細書では、別段示されない限り、これら２つは交換可能であってよく、それは、両方のボックスが、正確なフラグメントの時間または長さとバイトオフセットとを効率的に与える能力を提供するからである。ＴＩＤＸとＳＩＤＸとの差が、以下で与えられる。両方のボックスがセグメントインデックスを実装するので、ＴＩＤＸボックスとＳＩＤＸボックスをどのように置き換えるべきかは明らかであろう。

【0375】

４．セグメントインデクシング
セグメントは、識別された開始時間と識別された数のバイトとを有する。複数のフラグメントが単一のセグメントへと連結されてよく、クライアントは、要求されたフラグメントまたはフラグメントのサブセットに対応するセグメント内の特定のバイト範囲を識別する要求を発し得る。例えば、ＨＴＴＰが要求プロトコルとして使用される場合、ＨＴＴＰ Ｒａｎｇｅヘッダがこの目的で使用され得る。この手法は、クライアントが、異なるフラグメントのセグメント内での位置を規定するセグメントの「セグメントインデックス(segment index)」に対するアクセス権を有することを必要とする。この「セグメントインデックス」は、メタデータの一部として与えられ得る。この手法は、全てのブロックが別個のファイル内に保存されている手法と比較して、作成され管理される必要のあるファイルがはるかに少ないという結果をもたらす。非常に多数（例えば、１時間の提示では何千何万にも及び得る）のファイルの作成、転送、および格納の管理は、複雑でエラーを生みやすいことがあるので、ファイルの数を減らすことが利益となる。

【0376】

クライアントが、セグメントのより小さな部分の所望の開始時間のみを知っている場合、クライアントはファイル全体を要求し、ファイル全体を読み取って適切な再生開始位置を決定し得る。帯域幅の使用率を改善するために、セグメントは、メタデータとしてインデックスファイルを含んでよく、インデックスファイルは、個々のブロックのバイト範囲をブロックが対応する時間範囲へとマッピングし、これはセグメントインデクシングまたはセグメントマップと呼ばれる。このメタデータは、ＸＭＬデータとしてフォーマットされてよく、または、例えば３ＧＰＰファイルフォーマットのａｔｏｍ ａｎｄ ｂｏｘ構造に従う、バイナリであってよい。インデクシングは簡単であってよく、各ブロックの時間範囲およびバイト範囲は、ファイルの始まりに対する絶対値であり、または、時間範囲およびバイト範囲は階層的であってよく、この場合、いくつかのブロックが親ブロックへとグループ化され（そして親ブロックは親の親ブロックへとグループ化される、など）、所与のブロックの時間範囲およびバイト範囲は、ブロックの親ブロックの時間範囲および／またはバイト範囲に対して表される。

【0377】

５．例示的なインデクシングマップ構造
一実施形態では、メディアストリームの１つの表示に対する元のソースデータは、本明細書では「メディアセグメント(media segment)」と呼ばれる１つまたは複数のメディアファイルに含まれてよく、各メディアセグメントは、メディアの連続的な時間セグメントを再生するために使用されるメディアデータ、例えば５分のメディア再生のためのメディアデータを含む。

【0378】

図２２は、メディアセグメントの例示的な全体の構造を示す。各セグメント内で、ソースセグメントの始めにおいて、またはソースセグメント全体に広がって、時間／バイトオフセットセグメントマップを備えるインデクシング情報も存在し得る。一実施形態における時間／バイトオフセットセグメントマップは、時間／バイトオフセットのペア（Ｔ（０），Ｂ（０））、（Ｔ（１），Ｂ（１））、…、（Ｔ（ｉ），Ｂ（ｉ））、…、（Ｔ（ｎ），Ｂ（ｎ））というリストであってよく、Ｔ（ｉ−１）は、全てのメディアセグメントのうちでメディアの最初の開始時間に対する、メディアのｉ番目のフラグメントの再生のためのセグメント内の開始時間を表し、Ｔ（ｉ）は、ｉ番目のフラグメントの終了時間（かつ、従って、次のフラグメントの開始時間）を表し、バイトオフセットＢ（ｉ−１）は、ソースセグメントの始まりに対する、メディアのｉ番目のフラグメントが開始するこのソースセグメント内のデータの始まりの対応するバイトインデックスであり、Ｂ（ｉ）は、ｉ番目のフラグメントの対応する終了バイトインデックス（かつ、従って、次のセグメントの最初のバイトのインデックス）である。セグメントが複数のメディアコンポーネントを含む場合、Ｔ（ｉ）およびＢ（ｉ）は、絶対的な方法でセグメント内の各コンポーネントに対して与えられてよく、または、基準メディアコンポーネントとして機能する別のメディアコンポーネントに対して表されてよい。

【0379】

この実施形態では、ソースセグメント内のフラグメントの数はｎであり、ｎはセグメントによって異なり得る。

【0380】

別の実施形態では、各フラグメントのセグメントインデックスにおける時間オフセットは、最初のフラグメントの絶対的な開始時間と、各フラグメントの長さとによって決定され得る。この場合、セグメントインデックスは、最初のフラグメントの開始時間と、セグメントに含まれる全てのセグメントの長さとを記録し得る。セグメントインデックスはまた、フラグメントのサブセットのみを記録してよい。その場合、セグメントインデックスは、それを含むセグメントの終わりで終了するか、次のサブセグメントの始まりで終了するかのいずれかである、１つまたは複数の連続するフラグメントとして定義されるサブセグメントの長さを記録する。

【0381】

各フラグメントに対して、探索点、すなわち、その点より後のメディアがその点よりも前の任意のメディアに依存しない点で、フラグメントが開始するかどうか、または探索点をフラグメントが含むかどうかを示す値も存在し得るので、そのフラグメントから先のメディアは、前のフラグメントとは無関係に再生され得る。一般に、探索点は、再生が全ての以前のメディアとは無関係に開始できる、メディア内の点である。図２２はまた、ソースセグメントのための可能なセグメントインデクシングの簡単な例を示す。その例では、時間オフセットの値はミリ秒の単位であるので、このソースセグメントの第１のフラグメントは、メディアの始まりから２０秒で開始し、第１のフラグメントは４８５ミリ秒の再生時間を有する。第１のフラグメントの始まりのバイトオフセットは０であり、第１のフラグメントの終わり／第２のフラグメントの始まりのバイトオフセットは５０２４５であるので、第１のフラグメントのサイズは５０２４５バイトである。フラグメントまたはサブセグメントがランダムアクセスポイントと共に開始しないが、ランダムアクセスポイントがフラグメントまたはサブセグメントに含まれる場合、開始時間と実際のＲＡＰ時間との間の復号時間または提示時間の差が、与えられ得る。これによって、このメディアセグメントへ切り替える場合に、表示からの切り替えが提示されなければならなくなるまでの時間を、クライアントが正確に知ることができる。

【0382】

簡単な、または階層的なインデクシングに加えて、またはそれらの代わりに、デイジーチェーンインデクシングおよび／またはハイブリッドインデクシングが使用され得る。

【0383】

異なるトラックに対するサンプルの長さは同じではないことがあるので（例えば、ビデオサンプルは３３ｍｓ表示され得るが、一方オーディオサンプルは８０ｍｓ続き得る）、動画フラグメント内の異なるトラックは、厳密には同時に開始および終了しないことがあり、すなわち、オーディオはビデオよりもわずかに前またはわずかに後に開始することがあり、これに対応して、反対のことが先行するフラグメントに成り立つ。曖昧さをなくすために、時間およびバイトオフセットのデータにおいて規定されるタイムスタンプは、特定のトラックに対して規定されてよく、この特定のトラックは、各表示に対して同じトラックであってよい。通常、これはビデオトラックである。これによって、クライアントは、表示を切り替えている時に次のビデオフレームを厳密に識別することが可能になる。

【0384】

提示の間、トラックの時間軸と提示時間との間の厳密な関係を維持して、上記の問題にもかかわらず円滑な再生とオーディオ／ビデオの同期の維持とを確実にするように、注意が払われなければならない。

【0385】

セグメントマップを含むボックスの２つの具体的な例が以下で与えられ、１つはｔｉｍｅ ｉｎｄｅｘ ｂｏｘ（「ＴＩＤＸ」）と呼ばれ、１つは（「ＳＩＤＸ」）と呼ばれる。定義は、ＩＳＯベースのメディアファイルフォーマットによるボックス構造に従う。同様のシンタックスを定義するための、同じ意味と機能とを伴うそのようなボックスの他の設計が、読者に明らかとなるであろう。

【0386】

６．Ｔｉｍｅ Ｉｎｄｅｘ ＢＯＸ
定義
ボックスタイプ：「ｔｉｄｘ」
コンテナ：ファイル
必須性：いいえ
量：０または１のいずれかの数
Ｔｉｍｅ Ｉｎｄｅｘ Ｂｏｘは、ファイルのある領域を提示のある時間間隔に関連付ける、時間とバイトオフセットのインデックスのセットを提供できる。Ｔｉｍｅ Ｉｎｄｅｘ Ｂｏｘは、ｔａｒｇｅｔｔｙｐｅフィールドを含んでよく、これは、参照されるデータのタイプを示す。例えば、ｔａｒｇｅｔｔｙｐｅ「ｍｏｏｆ」を伴うＴｉｍｅ Ｉｎｄｅｘ Ｂｏｘは、時間とバイトオフセットの両方に関してファイルに含まれるメディアフラグメントに対するインデックスを提供する。Ｔｉｍｅ Ｉｎｄｅｘ Ｂｏｘのｔａｒｇｅｔｔｙｐｅを伴うＴｉｍｅ Ｉｎｄｅｘ Ｂｏｘは、階層的な時間インデックスを構築するために使用されてよく、ファイルのユーザがインデックスの必要な部分を高速に見進めることを可能にする。

【0387】

セグメントインデックスは、例えば、次のシンタックスを含み得る。

【数10】

【0388】

意味
ｔａｒｇｅｔｔｙｐｅ：このＴｉｍｅ Ｉｎｄｅｘ Ｂｏｘによって参照されるボックスデータのタイプである。これは、Ｍｏｖｉｅ Ｆｒａｇｍｅｎｔ Ｈｅａｄｅｒ（「ｍｏｏｆ」）またはＴｉｍｅ Ｉｎｄｅｘ Ｂｏｘ（「ｔｉｄｘ」）のいずれかであり得る。

【0389】

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

【0390】

ｎｕｍｂｅｒ＿ｏｆ＿ｅｌｅｍｅｎｔｓ：このＴｉｍｅ Ｉｎｄｅｘ Ｂｏｘによってインデックスを付与される要素の数。

【0391】

ｆｉｒｓｔ＿ｅｌｅｍｅｎｔ＿ｏｆｆｓｅｔ：最初にインデックスを付与された要素の、ファイルの始まりからのバイトオフセット。

【0392】

ｆｉｒｓｔ＿ｅｌｅｍｅｎｔ＿ｔｉｍｅ：ｔｉｍｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋ＿ｉｄによって識別されるトラックのＭｅｄｉａ Ｈｅａｄｅｒボックスにおいて規定される時間軸を使用した、最初にインデックスを付与された要素の開始時間。

【0393】

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

【0394】

ｌｅｎｇｔｈ：インデックスを付与された要素のバイト単位での長さ。

【0395】

ｄｅｌｔａＴ：この要素の開始時間と次の要素の開始時間との間の、ｔｉｍｅ＿ｒｅｆｅｒｅｎｃｅ＿ｔｒａｃｋ＿ｉｄによって識別されたトラックのＭｅｄｉａ Ｈｅａｄｅｒボックスにおいて規定される時間軸による差。

【0396】

７．Ｓｅｇｍｅｎｔ Ｉｎｄｅｘ Ｂｏｘ
Ｓｅｇｍｅｎｔ Ｉｎｄｅｘ Ｂｏｘ（「ｓｉｄｘ」）は、動画フラグメントの小型のインデックスと、セグメント内の他のＳｅｇｍｅｎｔ Ｉｎｄｅｘ Ｂｏｘとを提供する。Ｓｅｇｍｅｎｔ Ｉｎｄｅｘ Ｂｏｘには２つのループ構造がある。第１のループは、サブセグメントの最初のサンプル、すなわち、第２のループによって参照される最初の動画フラグメント内のサンプルを記録する。第２のループは、サブセグメントのインデックスを提供する。「ｓｉｄｘ」ボックスのコンテナは、ファイル、または直接的にセグメントである。シンタックスは次の通りであり得る。

【数11】

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

メディア提示における表示は、グローバルなタイムラインにおいて同期され、通常は選択肢である複数の表示のシームレスな切り替えを確実にし、２つ以上の表示の同期した提示を確実にする。従って、適応ＨＴＴＰストリーミングメディア提示内の表示内に含まれるメディアのサンプルのタイミングは、複数のセグメントにわたる連続的なグローバルなタイムラインに関連し得る。

【0440】

複数のタイプのメディア、例えばオーディオおよびビデオを含む、符号化されたメディアのブロックは、異なるタイプのメディアに対して、異なる提示終了時間を有し得る。ブロック要求ストリーミングシステムでは、そのようなメディアブロックは、各メディアタイプが連続的に再生されるような方法で連続的に再生され得るので、１つのブロックからの１つのタイプのメディアサンプルは、先行するブロックの別のタイプのメディアサンプルよりも前に再生されてよく、これは、本明細書では「連続ブロックスプライシング(continuous block splicing)」と呼ばれる。ある代替形態として、そのようなメディアブロックは、任意のタイプの１つのブロックの最早のサンプルが、任意のタイプの先行するブロックの最遅のサンプルよりも後に再生されるような方法で再生されてよく、これは、本明細書では「非連続ブロックスプライシング(discontinuous block splicing)」と呼ばれる。連続ブロックスプライシングは、両方のブロックが、シーケンスにおいて符号化された、同じコンテンツ項目および同じ表示からのメディアを含む場合、または他の場合に、適切であり得る。通常、１つの表示内で、２つのブロックを接合する場合、連続ブロックスプライシングが適用され得る。これは、既存の符号化を適用でき、ブロック境界においてメディアトラックを揃える必要なくセグメント化を行うことができるので、有利である。

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

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

【0485】

（１）第１に、各セグメントの開始時間を、ＭＰＤにおいて規定されるような正確なタイミングに制約する。しかしそうすると、メディアエンコーダは、ＩＤＲフレームの配置について柔軟性をまったく有することができず、ファイルストリーミングのために特別な符号化を必要とし得る。

【0486】

（２）第２に、各セグメントのＭＰＤに正確な開始時間を追加する。オンデマンドの場合、ＭＰＤの小型性が低下し得る。ライブの場合、これは、ＭＰＤの定期的な更新を必要とすることがあり、スケーラビリティを下げ得る。

【0487】

（３）第３に、表示の告知された開始時間またはＭＰＤにおけるセグメントの告知された開始時間に対する、グローバルな時間または正確な開始時間を、セグメントに追加し、ある意味ではセグメントがこの情報を含む。これは、適応ストリーミングに専用の新たなボックスに追加され得る。このボックスはまた、「ＴＩＤＸ」または「ＳＩＤＸ」ボックスによって提供されるような情報も含み得る。この第３の手法の結果は、セグメントの１つの始まりの近くの特定の位置を探す時に、クライアントが、ＭＰＤに基づいて、要求された探索点を含むセグメントの後続のセグメントを選ぶことができる、というものである。この場合の簡単な応答は、取り出されるセグメントの始まりに（すなわち、探索点の後の次のランダムアクセスポイントに）探索点を進めるように移動することであり得る。通常、ランダムアクセスポイントは、少なくとも数秒ごとに提供されるので（かつ、ランダムアクセスポイントの頻度を低くすることによる符号化の利益はほとんどないことが多いので）、最悪の場合、探索点は規定された箇所よりも数秒後に移動され得る。あるいは、クライアントは、セグメントのためのヘッダ情報を取り出す際に、要求された探索点が実際には前のセグメントにあると判定し、代わりにそのセグメント要求できる。これは、探索動作を実行するのに必要な時間の偶発的な増加をもたらし得る。

【0488】

２．アクセス可能なセグメントのリスト
メディア提示は、元のメディアコンテンツの符号化物の何らかの異なるバージョンを各々提供する、表示のセットを備える。有利なことに、表示自体が、他のパラメータと比較して表示を差別化するパラメータについての情報を含む。表示はまた、明示的にまたは暗黙的に、アクセス可能なセグメントのリストを含む。

【0489】

セグメントは、メタデータを含む時間に無関係のセグメント、および、メディアデータを主に含むメディアセグメントにおいて、差別化され得る。Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ（「ＭＰＤ」）は、有利なことに、暗黙的または明示的のいずれかに、異なる属性を識別しセグメントの各々へ割り当てる。各セグメントへと有利に割り当てられた属性は、セグメントがアクセス可能な期間と、それらを通じてセグメントがアクセス可能であるリソースとプロトコルとを備える。加えて、メディアセグメントは、有利なことに、メディア提示におけるセグメントの開始時間、およびメディア提示におけるセグメントの長さのような属性を、割り当てられる。

【0490】

ＯｎＤｅｍａｎｄＡｖａｉｌａｂｉｌｉｔｙＩｎｔｅｒｖａｌのようなｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎにおける属性によって有利に示されるように、メディア提示が「オンデマンド」のタイプである場合、ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎは通常、セグメント全体を表し、セグメントがいつアクセス可能でセグメントがいつアクセス可能ではないかということの指示も提供する。同じメディア提示の再生を、しかし異なる時間に開始する２つのクライアントが、同じｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ、さらには同じメディアセグメントを使用できるように、セグメントの開始時間は有利なことに、メディア提示の始まりに対して表される。これは有利なことに、セグメントをキャッシュする能力を改善する。

【0491】

属性Ｓｅｒｖｉｃｅのようなｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎにおける属性によって有利に示されるように、メディア提示が「ライブ」のタイプである場合、実時間で１日を超えるメディア提示を備えるセグメントは、一般に、セグメントがＭＰＤにおいて完全に表されていても、生成されず、または少なくともアクセス可能ではない。しかしながら、メディア提示サービスが「ライブ」のタイプであるという指示によって、クライアントは、ＭＰＤに含まれる情報およびＭＰＤのダウンロード時間に基づいて、実時間でクライアント内部時間ＮＯＷに対するタイミング属性と共に、アクセス可能なセグメントのリストを生成できる。実時間ＮＯＷにおけるＭＰＤのインスタンスと共に動作する参照クライアントがリソースにアクセスできるように、サーバがリソースをアクセス可能にするという意味で、サーバは有利に動作する。

【0492】

具体的には、参照クライアントは、ＭＰＤに含まれる情報およびＭＰＤのダウンロード時間に基づいて、実時間でクライアント内部時間ＮＯＷに対するタイミング属性と共に、アクセス可能なセグメントのリストを生成する。時間が進むと、クライアントは、同じＭＰＤを使用して、メディア提示を連続的に再生するために使用され得る新たなアクセス可能なセグメントのリストを作成する。従って、サーバは、これらセグメントが実際にアクセス可能になる前に、ＭＰＤ内でセグメントを告知できる。これは有利であり、それは、ＭＰＤの頻繁な更新とダウンロードとを減らすからである。

【0493】

各々の開始時間がｔＳであるセグメントのリストが、ＦｉｌｅＩｎｆｏＳｔａｔｉｃのような要素における再生リストによって明示的に表され、または、ＦｉｌｅＩｎｆｏＤｙｎａｍｉｃのような要素を使用して暗黙的に表されると仮定する。ＦｉｌｅＩｎｆｏＤｙｎａｍｉｃを使用してセグメントリストを生成するための有利な方法が、以下で説明される。この構築規則に基づいて、クライアントは、インデックスｉを有する各セグメントに対し、本明細書ではＦｉｌｅＵＲＩ（ｒ，Ｉ）と呼ばれる各表示ｒのＵＲＩのリストと、開始時間ｔＳ（ｒ，ｉ）とを入手する。

【0494】

セグメントのアクセス可能な時間枠を作成するために、ＭＰＤにおける情報を使用することは、次の規則を使用して実行され得る。

【0495】

Ｓｅｒｖｉｃｅのような属性によって有利に示されるような、「オンデマンド」のタイプのサービスについて、クライアントにおける現在の実時間ＮＯＷが、ＯｎＤｅｍａｎｄＡｖａｉｌａｂｉｌｉｔｙＩｎｔｅｒｖａｌのようなＭＰＤ要素によって有利に表される利用可能な任意の範囲内にある場合、このオンデマンドの提示の全ての説明されるセグメントはアクセス可能である。クライアントにおける現在の実時間ＮＯＷが利用可能な任意の範囲の外にある場合、このオンデマンドの提示の説明されるセグメントはいずれもアクセス可能ではない。

【0496】

Ｓｅｒｖｉｃｅのような属性によって有利に示されるような、「ライブ」のタイプのサービスについて、開始時間ｔＳ（ｒ，ｉ）は有利なことに、実時間における利用可能な時間を表す。利用可能な開始時間は、イベントのライブサービス時間と、キャプチャ、符号化、および公開のためのサーバにおける何らかの転換時間との組合せとして、導出され得る。例えば、この処理のための時間は、例えば、ＭＰＤにおけるＳａｆｅｔｙＧｕａｒｄＩｎｔｅｒｖａｌＬｉｖｅＳｅｒｖｉｃｅとして規定される、安全ガード間隔ｔＧを例えば使用して、ＭＰＤ内で規定され得る。これは、ＵＴＣ時間と、ＨＴＴＰストリーミングサーバ上でのデータの利用可能性との、最小の差を与える。別の実施形態では、ＭＰＤは、イベントのライブ時間と転換時間との差として転換時間を提供することなく、ＭＰＤにおいてセグメントの利用可能な時間を明示的に規定する。以下の説明では、利用可能な時間として、任意のグローバルな時間が規定されることが仮定される。ライブメディアブロードキャスティングの当業者は、この説明を読んだ後、ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎにおける適切な情報から、この情報を導出できる。

【0497】

クライアントにおける現在の実時間ＮＯＷが、ＬｉｖｅＰｒｅｓｅｎｔａｔｉｏｎＩｎｔｅｒｖａｌのようなＭＰＤ要素によって有利に表されるライブ提示間隔の任意の範囲の外にある場合、このライブ提示の説明されるセグメントはいずれもアクセス可能ではない。クライアントにおける現在の実時間ＮＯＷがライブ提示間隔内にある場合、このライブ提示の説明されるセグメントの少なくともいくつかのセグメントはアクセス可能であり得る。

【0498】

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

【0499】

（クライアントに利用可能な）実時間ＮＯＷ
例えばｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎにおけるＴｉｍｅＳｈｉｆｔＢｕｆｆｅｒＤｅｐｔｈとして規定される、許容される時間シフトバッファ深度ｔＴＳＢ。

【0500】

相対的なイベント時間ｔ₁におけるクライアントは、（ＮＯＷ−ｔＴＳＢ）とＮＯＷとの間隔に、または、長さｄのセグメントの終了時間も含まれるような間隔、すなわち（ＮＯＷ−ｔＴＳＢ−ｄ）とＮＯＷとの間隔に開始時間ｔＳ（ｒ，ｉ）を伴うセグメントのみを、要求することが許可され得る。

【0501】

３．ＭＰＤの更新
いくつかの実施形態では、サーバは、ファイルまたはセグメントロケータとセグメントの開始時間とを、前もって知らない。それは、例えば、サーバの位置か変わるため、または、メディア提示が異なるサーバからのいくつかの告知を含むため、または、メディア提示の長さが未知であるため、または、サーバが以後のセグメントのロケータを不明瞭にするのを望むためである。

【0502】

そのような実施形態では、サーバは、既にアクセス可能な、または、ＭＰＤのこのインスタンスが公開されたすぐ後にアクセス可能になるセグメントのみを、表し得る。さらに、いくつかの実施形態では、ユーザがメディアコンテンツの生成から可能な限り近くで含まれるメディアプログラムを体験するように、クライアントは、有利なことに、ＭＰＤにおいて表されるメディアの近くでメディアを消費する。クライアントがＭＰＤ内で表されたメディアセグメントの終わりに達するとクライアントが予測するとすぐに、クライアントは、有利なことに、ＭＰＤの新たなインスタントを要求して、新たなメディアセグメントを表す新たなＭＰＤをサーバが公開したという予測のもとで、連続的な再生を継続する。サーバは、有利なことに、クライアントが連続的な更新のための手順を利用できるように、ＭＰＤの新たなインスタンスを生成し、ＭＰＤを更新する。サーバは、セグメントの生成および公開と共に、サーバのＭＰＤ更新手順を、共通のクライアントが動作し得るように動作する参照クライアントの手順に適応させることができる。

【0503】

ＭＰＤの新たなインスタンスが事前の短時間しか表さない場合、クライアントは、ＭＰＤの新たなインスタンスを頻繁に要求する必要がある。これは、スケーラビリティの問題と、不必要かつ頻繁な要求による不必要なアップリンクおよびダウンリンクのトラフィックとをもたらし得る。

【0504】

従って、一方では、セグメントを必ずしもまだアクセス可能にすることなくできる限り未来のセグメントを表すことに関係があり、もう一方では、新たなサーバの位置を表し、広告のような新たなコンテンツの挿入を許容し、またはコーデックパラメータの変更を提供するために、ＭＰＤ内で予測されない更新を可能にすることに関係がある。

【0505】

さらに、いくつかの実施形態では、メディアセグメントの長さは短いことがあり、例えば数秒の範囲内であり得る。メディアセグメントの長さは、有利なことに、配信またはキャッシュの特性に最適化され得る適切なセグメントサイズに調整するために、ライブサービスにおけるエンドツーエンドの遅延またはセグメントの格納もしくは配信に関連する他の様相を補償するために、または他の理由で、柔軟である。セグメントがメディア提示の長さと比較して短い場合は特に、大量のメディアセグメントリソースおよび開始時間が、ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎにおいて表される必要がある。その結果、ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎのサイズは大きくなることがあり、これは、ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎのダウンリンク時間に悪影響を与えることがあり、従って、メディア提示の始動遅延に、さらにアクセスリンク上での帯域幅の使用率に影響を与えることがある。従って、再生リストを使用したメディアセグメントのリストの表現を許容するだけではなく、テンプレートまたはＵＲＬ構築規則を使用することによる表現も許容することが有利である。テンプレートおよびＵＲＩ構築規則は、この説明では同義に使用される。

【0506】

加えて、ライブの場合に現在時刻を超えてセグメントロケータを表すために、テンプレートが有利に使用され得る。そのような場合、ロケータ、さらにはセグメントリストが、テンプレートによって表されるので、ＭＰＤの更新自体は不必要である。しかしながら、表示またはセグメントの記述の変更を必要とする、予測されない事象は依然として起こり得る。複数の異なるソースからのコンテンツが一緒に接合される場合、例えば、広告が挿入された場合、適応ＨＴＴＰストリーミングのｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎの変更が必要であり得る。異なるソースからのコンテンツは、様々な方式で異なり得る。別の理由は、ライブ提示の間に、コンテンツファイルに使用されるＵＲＬを変更して、１つのライブの元のサーバから別のサーバへのフェイルオーバーを提供する必要があり得る、ということである。

【0507】

いくつかの実施形態では、ＭＰＤが更新される場合、更新されたＭＰＤが次のような意味で前のＭＰＤに適合するように、ＭＰＤに対する更新が実行されることが有利である。すなわち、参照クライアントと、従って任意の実装されるクライアントは、それがＭＰＤの前のインスタンスから生成していたように、アクセス可能なセグメントの同じように機能するリストを、前のＭＰＤの有効時間までの任意の時間、更新されたＭＰＤから生成する。この要件は、（ａ）クライアントが、更新時間の前の古いＭＰＤと適合するので、古いＭＰＤとの同期を伴わずに、新たなＭＰＤを使用して直ちに開始できることと、（ｂ）更新時間が、ＭＰＤに対する実際の変更が発生する時間と同期する必要がないこととを、保証する。言い換えると、ＭＰＤに対する更新は、前もって告知されてよく、サーバは、ＭＰＤの異なるバージョンを維持する必要なく、新たな情報が利用可能になると、ＭＰＤの古いインスタンスを置き換えることができる。

【0508】

表示のセットまたは全ての表示に対するＭＰＤ更新にわたるメディアのタイミングについて、２つの可能性が存在し得る。（ａ）既存のグローバルなタイムラインがＭＰＤ更新にわたって継続する（本明細書では「連続ＭＰＤ更新」と呼ばれる）か、または（ｂ）現在のタイムラインが終了し、新たなタイムラインが変更の後のセグメントで開始する（本明細書では「非連続ＭＰＤ更新と呼ばれる」）のいずれかである。

【0509】

これら選択肢の違いは、メディアフラグメントのトラック、従ってセグメントのトラックが、一般に、トラック間のサンプル粒度の違いによって同時に開始および終了しないということを考えると、明らかであり得る。通常の提示の間、フラグメントの１つのトラックのサンプルは、前のフラグメントの別のトラックのいくつかのサンプルの前にレンダリングされてよく、すなわち、複数のフラグメントの間にはある種の重複が存在するが、単一のトラック内での重複はないことがある。

【0510】

（ａ）と（ｂ）の違いは、そのような重複がＭＰＤ更新にまたがって可能にされ得るかどうかである。ＭＰＤ更新が、完全に別個のコンテンツの接合によるものである場合、そのような重複は一般に達成することが難しく、それは、前のコンテンツと接合されるために新たなコンテンツが新たな符号化を必要とするからである。従って、いくつかのセグメントのタイムラインを再始動することによってメディア提示を非連続的に更新するための能力を提供し、場合によって更新の後に表示の新たなセットも定義することが、有利である。また、コンテンツが独立に符号化されセグメント化されている場合、コンテンツの前の断片のグローバルなタイムライン内で適合するようにタイムスタンプを調整することも回避される。

【0511】

更新が、表されたメディアセグメントのリストに新たなメディアセグメントを追加するためだけなどの、より小さな理由によるものである場合、または、ＵＲＬの位置が変更された場合、重複および連続的な更新が許容され得る。

【0512】

非連続ＭＰＤ更新の場合、前の表示の最後のセグメントのタイムラインは、セグメントにおける任意のサンプルの最遅の提示終了時間で終了する。次の表示のタイムライン（またはより正確には、新たな期間とも呼ばれる、メディア提示の新たな部分の最初のメディアセグメントの最初の提示時間）は、通常かつ有利には、シームレスかつ連続的な再生が保証されるように、最後の期間の提示の終わりと同じこの瞬間に開始する。

【0513】

２つの場合が、図２７に示されている。

【0514】

ＭＰＤ更新を、セグメントの境界に制約することが、好適であり有利である。変更または更新をセグメントの境界へとそのように制約する論拠は、次の通りである。第１に、通常は動画ヘッダである、各表示のバイナリメタデータに対する変更は、少なくともセグメントの境界で起こり得る。第２に、Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎは、セグメントに対するポインタ（ＵＲＬ）を含み得る。ある意味では、ＭＰＤは、メディア提示に関連付けられる全てのセグメントファイルを一緒にグループ化する、「傘の(umbrella)」データ構造である。この包含関係を維持するために、各セグメントは単一のＭＰＤによって参照されてよく、ＭＰＤが更新される場合、ＭＰＤは有利にはセグメントの境界のみにおいて更新される。

【0515】

セグメントの境界は、一般には揃えられる必要はないが、異なるソースから接合されたコンテンツの場合、また、非連続ＭＰＤ更新の場合には一般に、セグメントの境界を揃えることが理にかなう（具体的には、各表示の最後のセグメントは、同じビデオフレームで終了してよく、そのフレームの提示時間よりも遅い提示開始時間を伴うオーディオサンプルを含まなくてよい）。そして、非連続的な更新は、期間と呼ばれる共通の時間的な瞬間において表示の新たなセットを開始できる。表示のこの新たなセットが有効となる開始時間は、例えば、期間開始時間によって与えられる。各表示の相対的な開始時間は０にリセットされ、期間の開始時間は、グローバルなメディア提示タイムラインにおけるこの新たな期間に表示のセットを配置する。

【0516】

連続ＭＰＤ更新では、セグメントの境界は揃えられる必要はない。各代替的な表示の各セグメントは、単一のＭｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎによって支配され得るので、追加のメディアセグメントが動作しているＭＰＤにおいて表されていないという予測によって一般にトリガされる、Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎの新たなインスタンスに対する更新の要求は、消費されると予測される表示のセットを含む表示の消費されるセットに応じて、異なる時間に起こり得る。

【0517】

より一般的な場合において、ＭＰＤの要素と属性の更新をサポートするために、表示または表示のセットだけではなく、任意の要素が有効時間に関連付けられ得る。よって、ＭＰＤのいくつかの要素が更新される必要がある場合、例えば、表示の数が変更された、またはＵＲＬ構築規則が変更された場合、これら要素は各々、要素の複数のコピーをつながっていない複数の有効時間に提供することによって、規定された時間において個々に更新され得る。

【0518】

有効時間に関連付けられる説明された要素が、メディア提示のグローバルなタイムラインのある期間において有効であるように、有効性は、有利なことに、グローバルなメディア時間に関連付けられる。

【0519】

上で論じられたように、一実施形態では、有効時間は、表示の完全なセットにのみ追加される。次いで、完全な各セットは期間を形成する。次いで、有効時間は期間の開始時間を形成する。言い換えると、有効性要素を使用する特定の場合には、表示の完全なセットは、表示のセットに対するグローバルな有効時間によって示される、ある期間において有効であり得る。表示のセットの有効時間は、期間と呼ばれる。新たな期間の始まりにおいて、前のセットの表示の有効性はなくなり、表示の新たなセットが有効になる。期間の複数の有効時間は、好ましくはつながっていないことに再び留意されたい。

【0520】

上で述べられたように、Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎに対する変更は、セグメントの境界で起こるので、各表示に対して、要素に対する変更は、実際には次のセグメントの境界において起こる。クライアントは次いで、メディアの提示時間内の時間の各瞬間に対するセグメントのリストを含む、有効ＭＰＤを形成し得る。

【0521】

ブロックが、異なる表示からの、または異なるコンテンツからの、例えば、コンテンツのセグメントおよび広告からの、メディアデータを含む場合、または他の場合、非連続ブロックスプライシングが適切であり得る。ブロック要求ストリーミングシステムでは、提示メタデータに対する変更はブロックの境界のみにおいて起こることが、必要とされ得る。これは、ブロック内でのメディアデコーダパラメータを更新することが、それらをブロックの間でのみ更新することよりも複雑であることがあるので、実装上の理由により有利であり得る。この場合、規定された有効間隔の始まりよりも前にない第１のブロックの境界から、規定された有効間隔の終わりよりも前にない第１のブロックの境界まで、要素が有効であると考えられるように、上で説明されたような有効間隔が概略的に解釈され得ることが、有利なことに規定され得る。

【0522】

上述されたブロック要求ストリーミングシステムに対する新規の拡張の例示的な実施形態について、メディア提示への変更と題された後で提示されるセクションにおいて説明する。

【0523】

４．セグメント期間のシグナリング
非連続的な更新は、期間と呼ばれる一連のつながっていない間隔へと、提示を実質的に分割する。各期間は、メディアサンプルタイミングのための固有のタイムラインを有する。期間内における表示のメディアタイミングは、有利なことに、各期間、または期間内の各表示に対する、セグメントの長さの別個の小型のリストを規定することによって指示され得る。

【0524】

ＭＰＤ内の要素に関連付けられる、例えば期間開始時間と呼ばれる属性は、メディア提示時間内のいくつかの要素の有効時間を規定し得る。この属性は、ＭＰＤの任意の要素（有効性を割り当てられ得る属性は要素へと変更され得る）に追加され得る。

【0525】

非連続ＭＰＤ更新では、全ての表示のセグメントは、断絶で終了し得る。これは一般に、断絶の前の最後のセグメントが、前のセグメントとは異なる長さを有することを、少なくとも示唆する。セグメントの長さをシグナリングすることは、全てのセグメントが同じ長さを有することを示すこと、または各セグメントに対して別個の長さを示すことのいずれかを伴い得る。セグメントの長さのリストのための小型の表示を有することが望ましいことがあり、これは、セグメントの長さの多くが同じ長さを有さない場合に効率的である。

【0526】

１つの表示または表示のセットにおける各セグメントの長さは、非連続的な更新の開始、すなわち、ＭＰＤ内で表される最後のメディアセグメントまでの期間の開始からの、単一の間隔に対する全てのセグメントの長さを規定する単一の文字列を伴って有利に実行され得る。一実施形態では、この要素のフォーマットは、セグメントの長さのエントリのリストを含む生成物に準拠するテキスト文字列であり、各エントリは、長さの属性ｄｕｒと属性の任意選択の乗算子ｍｕｌｔとを含み、ｍｕｌｔは、この表示が、第１のエントリの長さ＜ｄｕｒ＞の第１のエントリセグメントの＜ｍｕｌｔ＞個を含み、第２のエントリの長さ＜ｄｕｒ＞の第２のエントリセグメントの＜ｍｕｌｔ＞個を含み、以下同様であることを示す。

【0527】

各長さのエントリは、１つまたは複数のセグメントの長さを規定する。＜ｄｕｒ＞値の後に文字「＊」および数字が続く場合、この数字は、秒単位でこの長さを有する連続的なセグメントの数を規定する。乗算子の記号「＊」がない場合、セグメントの数は１つである。「＊」があり後ろに続く数字がない場合、全ての後続のセグメントは規定された長さを有し、リスト内にはさらなるエントリはなくてよい。例えば、文字列「３０＊」は、全てのセグメントが３０秒の長さを有することを意味する。文字列「３０＊１２ １０．５」は、３０秒の長さの１２個のセグメントと、その後に続く１つの１０．５秒の長さとを示す。

【0528】

セグメントの長さが各代替的な表示に対して別々に規定される場合、各間隔内におけるセグメントの長さの合計は、各表示に対して同じであり得る。ビデオトラックの場合、間隔は、各代替的な表示における同じフレームで終了し得る。

【0529】

当業者は、本開示を読めば、セグメントの長さを小型な方式で表現するための、同様かつ等価な方法を見出し得る。

【0530】

別の実施形態では、セグメントの長さは、単一の長さの属性＜ｄｕｒａｔｉｏｎ＞による最後の１つを除いて、表示における全てのセグメントに対して一定であるとシグナリングされる。非連続的な更新の前の最後のセグメントの長さは、次の非連続的な更新の開始点または新たな期間の始まりが提供される限りより短くてよく、これは、最後のセグメントの長さが次の期間の始まりに達することを示唆する。

【0531】

さらなる実施形態が、本開示を読んだ後に、当業者に想起され得る。他の実施形態では、上で開示された発明の組合せまたは副次的な組合せが、有利に行われ得る。コンポーネントの例示的な構成は例示を目的に示され、組合せ、追加、再構成などが、本発明の代替的な実施形態において考えられることを理解されたい。従って、本発明は、例示的な実施形態に関して説明されてきたが、多数の修正が可能であることを当業者は認識するだろう。

【0532】

例えば、本明細書で説明される処理は、ハードウェアコンポーネント、ソフトウェアコンポーネント、および／またはこれらの任意の組合せを使用して実施され得る。いくつかの場合には、ソフトウェアコンポーネントは、媒体と共に提供される、または媒体と別個のハードウェア上での実行のために、有形な非一時的媒体上で提供され得る。従って、本明細書および図面は、限定的な意味ではなく例示的であると解釈されるべきである。しかしながら、特許請求の範囲において述べられるような本発明のより広い趣旨および範囲から逸脱することなく、様々な修正および変更を行うことができ、本発明は、以下の特許請求の範囲内にある全ての修正と等価物とを包含することが意図されることは、明らかである。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］ サーバからクライアントに送信されるメディアストリームにおいて、適応ＨＴＴＰストリーミングのための表示を切り替えるためのシグナリングの方法であって、
セグメントマップを表示のセグメントに関連付けることと、ここにおいてセグメントマップが、バイトオフセット情報と共に、関連付けられたセグメント内の時間的な開始点と時間的な終了点の両方を備える、
前記関連付けられたセグメントの時間スパンとは独立の予測可能な時間スパンのパターンを伴うセグメントマップを生成することとを備える、方法。
［Ｃ２］ 複数の表示としてストリーミングされるコンテンツをフォーマットする方法であって、ここにおいて前記複数の表示の各々はコンテンツの項目に対する選択肢であり、前記コンテンツは、前記コンテンツが使用される提示内での時間を定義した定義済みの提示時間を有する、
各表示を前記表示の複数のセグメントとして編成することと、ここにおいてセグメントが、前記表示の他のセグメントのうちでの時間的な順序を有する前記コンテンツの一部分に関連するデータを備え、前記セグメントは、前のセグメントへのアクセス権を有さない受信機によって使用できるようなものであり、セグメントの時間的な開始点および時間的な終了点が、前記セグメントのデータを使用して提示可能な前記提示の期間を表す、
前記コンテンツ内の提示時間と表示内のバイトオフセットとをマッピングするバイトオフセット情報と共に、前記コンテンツ内の提示時間に対応する時間的な移行点を備えるセグメントマップを生成することと、
前記時間的な開始点の少なくとも一部と前記時間的な終了点の少なくとも一部を揃えることと、ここにおいて揃えることが、第１の表示内のセグメントの時間的な開始点の提示時間と第２の表示内のセグメントの時間的な終了点の提示時間との一致をもたらし、かつ揃えることが、複数の一致をもたらす、を備える、方法。
［Ｃ３］ 各セグメントに対してファイル名を決定することと、
各セグメントのコンテンツを、各セグメントの前記ファイル名を使用して、複数のファイルとして格納することとをさらに備える、Ｃ２に記載の方法。
［Ｃ４］ コンテンツを消費するクライアントにおいて、コンテンツ要求を決定することと、ここにおいて前記コンテンツ要求が少なくとも１つの表示と提示時間範囲とを規定する、
前記コンテンツ要求に対応する前記セグメントを表す前記複数のファイルのうちのファイルの１つまたは複数のＵＲＬのセットを決定することと、
ＵＲＬの前記セットを使用してセグメントを要求することと、
前記セグメントを受信することと、
前記セグメントからのコンテンツを前記クライアントでコンテンツ消費者に提供することとをさらに備える、Ｃ３に記載の方法。
［Ｃ５］ ネットワークに接続可能で、前記ネットワークを通じて要求可能で、０でない再生時間を有するコンテンツを提示可能なクライアントデバイスを使用してコンテンツを要求する方法であって、
コンテンツ要求を決定することと、ここにおいて前記コンテンツ要求は少なくとも１つの提示と提示時間範囲とを規定し、前記提示時間範囲は要求されている前記提示の一部または全ての一部分を定義する、
格納されたメディア提示データセットから、要求フォーマットのテンプレート、セグメント時間長、および可変セグメント範囲を読み取ることと、前記可変セグメント範囲はセグメントの提示時間範囲の変動を定義し、前記変動は前記メディア提示データセットに格納される前記セグメント時間長に関係する、
セグメント時間長の値を前記提示時間範囲の始まりに対応する時間的な開始点と比較して、初期セグメントインデックスを決定することと、
前記初期セグメントインデックス、前記可変セグメント範囲、前記セグメント時間長、および前記可変セグメント範囲とを評価して、所望のセグメントインデックスを決定することと、
前記所望のセグメントインデックスおよび前記要求フォーマットのテンプレートに基づいて、前記コンテンツ要求に対応するファイル要求を生成することと、
前記ファイル要求を使用して少なくとも１つのファイルを要求することとを備える、方法。
［Ｃ６］ 前記ファイル要求はＵＲＬであり、少なくとも１つのファイルを要求することが、前記ＵＲＬを使用したＨＴＴＰ要求を使用して実行される、Ｃ５に記載の方法。
［Ｃ７］ 前記初期セグメントインデックスは前記時間的な開始点を前記セグメント時間長で除算することによって決定され、前記所望のセグメントインデックスは前記除算の余りが前記可変セグメント範囲より小さい場合に前記初期セグメントインデックスとして決定され、前記除算の余りは前記可変セグメント範囲以上である場合に前記初期セグメントのすぐ前のセグメントインデックスとして決定される、Ｃ５に記載の方法。
［Ｃ８］ 前記提示時間範囲の終わりに対応する、または前記終わりよりも遅い、時間的な終了点を伴うコンテンツを含むセグメントが受信されるまで、ファイル要求を繰り返すことをさらに備える、Ｃ５に記載の方法。
［Ｃ９］ 前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長から、前記セグメント時間長に前記変動の時間範囲を足した時間長までの間となるような前記時間範囲である、Ｃ５に記載の方法。
［Ｃ１０］ 前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長の１．０倍から前記セグメント時間長の１＋Ｐ倍までの間となるような比率Ｐである、Ｃ５に記載の方法。
［Ｃ１１］ 前記セグメント時間長に関係のある前記変動は、前記変動の時間範囲にわたる前記セグメント時間長よりもセグメント提示時間が大きくまたは小さくなり得るような前記時間範囲である、Ｃ５に記載の方法。
［Ｃ１２］ 前記提示時間範囲の終わりに対応する、または前記終わりよりも遅い、時間的な終了点を伴うコンテンツを含むセグメントが受信されるまで、ファイル要求を繰り返すことをさらに備える、Ｃ１１に記載の方法。
［Ｃ１３］ セグメントが複数の表示のうちの１つから要求され、前記複数の表示の各々がコンテンツの項目に対する選択肢である、Ｃ５に記載の方法。
［Ｃ１４］ ネットワークを通じて要求可能で、前記ネットワークを通じて取り出され０でない再生時間を有するコンテンツを提示可能なクライアントデバイスであって、
格納された命令を実行することが可能な処理要素と、
データを格納可能なメモリと、
命令を格納可能なメモリと、
コンテンツ要求を決定するためのプログラムコードと、ここにおいて前記コンテンツ要求は少なくとも１つの提示と提示時間範囲とを規定し、前記提示時間範囲は要求されている前記提示の一部または全ての一部分を定義する、
格納されたメディア提示データセットから、要求フォーマットのテンプレート、セグメント時間長、および可変セグメント範囲を読み取るためのプログラムコードと、ここにおいて前記可変セグメント範囲はセグメントの提示時間範囲の変動を定義し、前記変動は前記メディア提示データセットに格納される前記セグメント時間長に関係する、
セグメント時間長の値を前記提示時間範囲の始まりに対応する時間的な開始点と比較して、初期セグメントインデックスを決定するためのプログラムコードと、
前記初期セグメントインデックス、前記可変セグメント範囲、前記セグメント時間長、および前記可変セグメント範囲を評価して、所望のセグメントインデックスを決定するためのプログラムコードと、
前記所望のセグメントインデックスおよび前記要求フォーマットのテンプレートに基づいて、前記コンテンツ要求に対応するファイル要求を生成するためのプログラムコードと、
前記ネットワークにメッセージを送信し前記ネットワークからメッセージを受信するためのネットワークインターフェースと、
前記ファイル要求を使用して少なくとも１つのファイルを要求するためのプログラムコードとを備える、クライアントデバイス。
［Ｃ１５］ 前記ネットワークインターフェースはワイヤレスネットワークインターフェースである、Ｃ１４に記載のクライアントデバイス。
［Ｃ１６］ 前記ネットワークインターフェースは有線ネットワークインターフェースである、Ｃ１４に記載のクライアントデバイス。
［Ｃ１７］ 前記ファイル要求はＵＲＬであり、要求が前記ＵＲＬを使用したＨＴＴＰ要求である、Ｃ１４に記載のクライアントデバイス。
［Ｃ１８］ 前記提示時間範囲の終わりに対応する、または前記終わりよりも遅い、時間的な終了点を伴うコンテンツを含むセグメントが受信されるまで、ファイル要求を繰り返すためのプログラムコードをさらに備える、Ｃ１４に記載のクライアントデバイス。
［Ｃ１９］ 前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長から、前記セグメント時間長に前記変動の時間範囲を足した時間長までの間となるような、前記時間範囲である、Ｃ１４に記載のクライアントデバイス。
［Ｃ２０］ 前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長の１．０倍から前記セグメント時間長の１＋Ｐ倍までの間となるような比率Ｐである、Ｃ１４に記載のクライアントデバイス。
［Ｃ２１］ 前記セグメント時間長に対するものである前記変動は、セグメント提示時間が前記変動の時間範囲にわたる前記セグメント時間長よりも大きくまたは小さくなり得るような前記時間範囲である、Ｃ１４に記載のクライアントデバイス。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6(a)】

【図6(b)】

【図7】

【図8】

【図9】

【図10(a)】

【図10(b)】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23(a)】

【図23(b)】

【図24】

【図25】

【図26】

【図27】