JP5667646B2 - Ｈｔｔｐメディアストリーム配信のための方法および装置 - Google Patents

Description

本発明は、クライアントがＨＴＴＰメディアストリームにアクセスできるようにするための方法と、ＨＴＴＰメディアストリームを取得するための方法と、それぞれの方法を実行するためのサーバおよびクライアントとに関する。

ＨＴＴＰストリーミングとは、例えばサーバもしくは中間ネットワークノードからクライアントへというような、エンティティ間のライブコンテンツまたはオンデマンドコンテンツのファイルベースのストリーミングの方法である。ＨＴＴＰストリーミング対応のクライアントは、コンテンツのアップロードを必要とする場合、まず、特定の必要なコンテンツのストリームまたは記述を集まって作り上げる小さなファイルまたはファイルのセグメントのリストを、サーバまたはいずれかの他のネットワークノードからそれを取り出すことによって取得する。そのようなリストは、典型的には、ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ばれる。本文脈では、ＭＰＤという用語をプレイリストおよびマニフェスト(Manifest)の同意語として用いる。プレイリストは、Ｍ３Ｕ８形式で記述されてもよいし、ＸＭＬ形式で提供されるリストとして記述されてもよい。

個々の時刻点には、複数の小さなファイルまたはファイルのセグメントが存在してもよく、それらのことを本書では以下メディアセグメントと呼び、それらはクライアントによって選ばれてもよい。ＨＴＴＰストリーミングは、テンプレートを利用してもプレイリストを利用してもどちらでもよい。テンプレートを利用するＨＴＴＰストリーミングでは、要求されたＵＲＬは、ＭＰＤの中でテンプレートを用いて記述され、それは例えば以下のようなタイプであってもよい。
www.server.com/streamfile/$Rep$/$Index$/
ここで、＄Ｒｅｐ＄は、要求された表現によって置換され、＄Ｉｎｄｅｘ＄は、連続番号によって置換され、それを用いて、メディアセグメントが要求される時刻が判定される。

プレイリストを利用するＨＴＴＰストリーミングでは、個々のメディアセグメントおよび個々の時刻は、例えば以下のような、それ自身のＵＲＬを有する。
動画時刻０
−＞動画時刻０に関連するＵＲＬ
動画時刻１
−＞動画時刻１に関連するＵＲＬ
動画時刻２
−＞動画時刻２に関連するＵＲＬ

しかし、既知のＭＰＤ構造は非常に精密であり、従って、特に、多様なコンテンツソースからアクセスできるコンテンツ、および／または、時間の経過と共に特性が異なりうるコンテンツの場合に、許容される柔軟性は非常に低い。

本書の目的は、上記の諸問題の少なくとも一部に対処することである。特に、１つの目的は、ＭＰＤの新たな構造と、そのようなＭＰＤを提供するための方法と、ＨＴＴＰメディアストリームのダウンロードがより柔軟なかたちで実行できるようにＭＰＤを取得および処理するための方法とを提供することであり、併せて、メディアストリームのダウンロードを要求するクライアントについての選択肢も提供する。

第１の態様によって、クライアントがＨＴＴＰメディアストリームにアクセスできるようにするために通信ネットワークのサーバによって行われる方法を提供する。方法を適用する場合、ＭＰＤは、メディア再生タイムラインに従って連続的に構成された少なくとも１つの期間要素を備え、また、個々の期間要素は少なくとも１つの表現を備え、かつ、その少なくとも１つの期間要素のうちの少なくとも１つは少なくとも２つの代替表現を備えるように生成され、ここで、個々の表現は少なくとも１つのメディアセグメントＵＲＩを順に並べた(ordered)シーケンスを備え、個々のメディアセグメントＵＲＩは、ＨＴＴＰメディアストリームの少なくとも１つのメディアセグメントを参照する。

次いでＭＰＤが提供され、その結果、クライアントはそれを取得し、ＭＰＤのコンテンツに基づいて、少なくとも１つの期間要素について、表現を選択し、そして、個々の選択された表現について、それぞれの参照されたメディアセグメントを取得することができる。

提案するＭＰＤ構成は、代替メディアセグメントへの参照を、特に、多様なソースから発信されるメディアセグメントへの参照を、単純化する。

生成するステップは、少なくとも１つのメディアセグメントＵＲＩが少なくとも１つの表現として提供され、かつ、テンプレート形式で記述されるように、少なくとも１つのメディアセグメントＵＲＩを順に並べたシーケンスの少なくとも１つを構成するステップを含んでいてもよい。

代わりに、または、テンプレート形式で１つ以上の表現を提供することと組み合わせて、生成するステップは、少なくとも１つの表現が少なくとも２つのメディアセグメントＵＲＩを順に並べたシーケンスとして提供され、かつ、プレイリスト形式で記述されるように、少なくとも１つの表現を構成するステップを含んでいてもよい。

さらに、同じ期間要素に関連する個々の表現は、表現の中で参照されるメディアセグメントを代表する(representative of)設定を有する第１の属性を備えることによって、クライアントがそれぞれの設定に基づいたそれぞれの期間要素の表現を選択することができてもよく、それを第１の表現属性と呼ぶこともある。

また、期間要素は、第２の属性すなわち表現属性を備えていてもよく、ここで第２の表現属性の設定は、それが、それぞれの期間要素に関連するすべてのメディアセグメントについて共通であるように、かつ、それが、この期間要素に関連するすべての表現を代表するように、選択されてもよい。

より階層的な構造が必要な場合、それぞれの第２の表現属性が、それぞれの期間要素のそれぞれの表現の中に提供されることによって、第２の表現属性が表現レベルで記述されてもよいし、それぞれの期間要素の中に提供されることによって、第２の表現属性が期間要素レベルで記述されてもよい。

あるいは、生成ステップの間にＭＰＤの少なくとも１つの期間要素が少なくとも２つの代替期間構成を備えるように階層型構造をさらに発展させてもよく、この場合、個々の期間構成は、少なくとも２つの表現と、１つの第２の表現属性とを備え、かつ、この場合、第２の表現属性の設定は、それがそれぞれの期間構成を表すように、クライアントが１つ以上の前記表現属性に基づいて期間要素の表現を選択することができるかたちで、選択される。

ＭＰＤの中に適用された表現属性は、例えば、コーデック、ビットレート、解像度、あるいは言語を定義し、それによって、サービスプロバイダが、ユーザデバイスの能力、ユーザの選好、または環境条件のいずれかに依存するか、または、それらを組み合わせた１つ以上の選択可能な代替案を提供できてもよい。

また、より柔軟性のあるＭＰＤを提供することに加えて、そのようなＭＰＤは、少なくとも１つの表現をＭＰＤに追加することによって、または少なくとも１つの表現をＭＰＤから除去することによって、またはＭＰＤの少なくとも１つの表現を修正することによって、更新されてもよい。

ＭＰＤの更新がポーリングに基づいているような一実施形態によると、ＭＰＤを取得したクライアントが指標（指示情報）によって決められた間隔でＭＰＤ更新についてポーリングすることができるように、ＭＰＤがポーリングの間隔の指標を備えていてもよく、一方で、別の選択肢によると、更新されたＭＰＤが代わりにクライアントへとプッシュされてもよい。

また、クライアントが最新の利用可能なメディアセグメントを判定できるようにするために、ＭＰＤは、例えばサーバのタイムラインやウォールクロック時間などの基準を使った、ＨＴＴＰトランスポートストリームのメディア再生タイムラインのマッピングの記述を備えていてもよい。

同じ期間要素の異なる表現のメディアセグメントは、それらが期間要素の開始時に時間的に整合されるように構成されることが望ましい。

別の態様によって、通信ネットワークの少なくとも１つのネットワークノードからＨＴＴＰメディアストリームを取得するために通信ネットワークのクライアントによって行われる方法を提供する。この方法によって、クライアントは、メディア再生タイムラインに従って連続的に構成された少なくとも１つの期間要素を含むＭＰＤを、ネットワークノードの１つから取得するのだが、ここで、個々の期間要素は少なくとも１つの表現を含み、かつ、少なくとも１つの期間要素のうちの少なくとも１つは、少なくとも２つの代替表現を含み、個々の表現は少なくとも１つのメディアセグメントＵＲＩの順序正しいシーケンスを備え、ここで、個々のメディアセグメントＵＲＩは、ＨＴＴＰメディアストリームの少なくとも１つのメディアセグメントを参照する。ＭＰＤを所有すると、クライアントは、期間要素の少なくとも１つについての表現を、ＭＰＤのコンテンツに基づいて選択し、個々の選択された表現についての参照されたメディアセグメントを取得することができる。

それぞれの表現は、それぞれの期間要素の１つ以上の表現属性に基づいて選択されてもよく、その場合、個々の表現は、それぞれの表現または期間要素を代表するそれぞれの設定を有する。

環境の変化に基づいて表現の選択を行うことができるようにするため、ＨＴＴＰメディアストリームを前記少なくとも１つのネットワークノードからクライアントへ送信するために利用可能なビットレートが推定されてもよく、そして、クライアントは、少なくとも１つのビットレート依存の表現属性を考慮に入れることによって、少なくとも１つの期間要素の表現をそのような推定に基づいて選択してもよい。

別の態様によって、クライアントがＨＴＴＰメディアストリームにアクセスできるようにすることができるサーバを提供する。サーバは、上述のように構成されたＭＰＤを生成するように構成された生成ユニットと、クライアントがＭＰＤにアクセスできるようにするように構成された提供ユニットとを備えており、それにより、クライアントは、ＭＰＤを取得することができ、少なくとも１つの期間要素についての表現をＭＰＤのコンテンツに基づいて選択し、かつ、個々の選択された表現についてのそれぞれの参照されたメディアセグメントを取得する。

生成ユニットは、テンプレート形式かプレイリスト形式かまたはそれら両方を組み合わせた形式で記述された少なくとも１つの表現をＭＰＤに提供するように構成されてもよい。

加えて、生成ユニットは、個々のメディアセグメントＵＲＩについて、それぞれの参照された１つ以上のメディアセグメントの持続時間の指標をＭＰＤに提供するように構成されてもよい。

また、クライアントが表現属性に基づいて表現を選択することができるように、生成ユニットは、同じ期間要素に関連する個々の表現に表現属性とそれぞれの表現属性設定とを提供するように構成されてもよい。

それぞれの表現属性が期間レベルで提供された場合には、それぞれの期間要素のすべての表現について有効であり、一方で、表現レベルで提供された場合には、それぞれの期間要素のそれぞれの表現についてのみ有効であるようにするため、生成ユニットは、少なくとも２つの異なるカテゴリの表現属性を提供し、かつ、表現属性を階層型に提供するように構成されてもよい。

生成ユニットは、Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎに少なくとも１つの表現を追加することによって、またはそこから少なくとも１つの表現を除去することによって、またはその少なくとも１つの表現を修正することによって、ＭＰＤを更新するように構成されてもよい。

別の態様によって、通信ネットワークのクライアントであって、通信ネットワークの少なくとも１つのネットワークノードからＨＴＴＰメディアストリームを取得することが可能なクライアントを提供する。クライアントは、上記のように構成されたＭＰＤを、前記少なくとも１つのネットワークノードのうちの１つから取得するように構成された要求ユニットと、個別の表現をそれぞれ、ＭＰＤコンテンツ（ＭＰＤの内容）に基づいて、選択するように構成された選択ユニットとを備えている。

選択ユニットは、典型的には、表現の少なくとも１つの表現属性に基づいてそれぞれの表現を選択するように構成される。

また、クライアントは、少なくとも１つのネットワークノードからクライアントへのＨＴＴＰメディアストリームを送信するのに利用可能なビットレートを推定するように構成された推定ユニットを備えていてもよく、それによって、選択ユニットは、少なくとも１つのビットレート依存の表現属性を考慮に入れることによって、少なくとも１つの期間要素の表現をそのような推定に基づいて選択することができるであろう。

本発明の目的、利点、効果ならびに機能は、添付の図面と共に読まれた場合、本発明の例示的実施形態を示す以下の詳細記述から一層容易に理解されるであろう。
ＨＴＴＰメディアストリームの配信に適した通信ネットワークの簡略化した概要図である。 ネットワークノードにおいてＭＰＤを生成して提供するための方法を示すフローチャートである。 図２の生成プロセスを更に詳細に示すもう１つのフローチャートである。 ネットワークノードからＭＰＤを取得するための方法を示すもう１つのフローチャートである。 一実施形態によって構成されたＭＰＤを示す図である。 別の実施形態によって構成されたＭＰＤを示す図である。 更に別の実施形態によって構成されたＭＰＤを示す図である。 第１のＭＰＤを示す図である。 第１のＭＰＤの更新バージョンを示す図である。 一実施形態によってＭＰＤを提供するように構成されたサーバのブロックスキームを示す略図である。 一実施形態によってＭＰＤを取得して処理するように構成されたクライアントのブロックスキームを示す略図である。 別の実施形態によるサーバ構成の略図である。 別の実施形態によるクライアント構成の略図である。

本書は、開示される図面に関して以下で記述する方法および装置の各種の代替的実施形態をカバーするが、特定の記述および図面は、本発明の範囲を開示された特定の形態に限定することは意図されていないことは理解されるべきである。逆に、請求される本発明の範囲は、添付の請求項に表される本発明の精神と範囲とに入る、そのすべての修正形態および代替的構成を含むと考えられるべきである。

本書は、ＨＴＴＰストリーミングに関連する使用に適した、新しい、より柔軟なＭＰＤの構造について述べる。図１は、サーバとクライアントとの間のＭＰＤの配信を含む適応ＨＴＴＰストリーミングを可能にするのに適したシステムアーキテクチャを示す略図である。図１は、２つのクライアント１００ａと１００ｂとを含んでいて、それらをＨＴＴＰストリーミングクライアントと呼ぶこともあるが、その各々は、典型的にはメディアプレゼンテーションと呼ばれる構造化された一組のデータを取得するため、メディアプレゼンテーションとメディアセグメントの形式の関連のメディアプレゼンテーションとを記述する、関連のメタデータをダウンロードすることによって、ユーザに対するそれぞれのストリーミングサービスを開始してもよい。メタデータと関連のメディアプレゼンテーションとをダウンロードすることは、ＨＴＴＰストリーミングサーバと呼ばれることもあるサーバ１０１から直接行われても、あるいは、メディアセグメントとその関連のメタデータのコピーとを保持していることもある、ここではキャッシュ１０２ａおよびキャッシュ１０２ｂによって表される中間ネットワークノードから行われてもよい。記述された実施形態では、個々のキャッシュ１０２ａおよび１０２ｂは、それぞれのＨＴＴＰプロキシ１０３ａおよび１０３ｂにつながれている。

上記のメタデータは、典型的には、ＭＰＤ、マニフェスト、またはリストと呼ばれる。本文脈では、そのようなリストは、一般にプレイリストと呼ばれ、典型的にはＸＭＬ構造の文書として提供されるが、必ずしもそうとは限らない。

以下で、ＨＴＴＰストリーミングに適用可能な、より柔軟なＭＰＤ構成の原理を記述しよう。提案するＭＰＤを適用することによって、特に時間の経過と共に要求されたメディアプレゼンテーションの特性が異なる場合に、クライアントは、単純かつより柔軟なやり方でメディアコンテンツをアップロードすることを要求することができるであろう。詳細には、本書では代替表現と呼ぶ代替選択肢を記述するメタデータをクライアントに対して搬送しうる柔軟なＭＰＤ構成を提案する。代替表現は、テンプレートおよび／またはプレイリストのスタイルの構造として提供されてもよく、そうであれば、元の手法に対する変更の必要性は最小限であろう。

提案する新たなＭＰＤ構造は、連続的なメディアフローがＨＴＴＰキャッシング階層を通して配信されるためのメディアセグメントに再分割される、上記のような適応ＨＴＴＰストリーミングのシナリオには、特に適切である。

ネットワークのサーバ側では、サーバが、メディアソース１０４から提供された連続的なバイトストリームから連続的なセグメントまたはファイルストリームを作成し、メディアソース１０４では、新たなメディアセグメントがサーバ１０１に連続的にアップロードされてもよい。また、柔軟なＭＰＤを要求側クライアントに提供するのに加えて、サーバ１０１は、ＭＰＤを修正するかまたはＭＰＤからＵＲＩを削除するか、あるいは、ＭＰＤにＵＲＩを追加することによって、新たなメディアセグメントのための新たなＵＲＩを使ってＭＰＤを更新してもよい。本発明によると、そのようなＭＰＤ更新手順は、メディアプレゼンテーションのアップロード手順が進行している間に行われることすら、あってよい。

提案するＭＰＤ構造は期間の定義から構成されたものであるが、この場合、メディアプレゼンテーションは１つ以上の期間のシーケンスとして記述され、個々の期間は、１つの期間の記述、あるいはメディアプレイ（再生）時間の時間範囲または間隔で与えられる。ＭＰＤの一部を成すそのような記述は、期間要素と呼ばれることもある。また、ＭＰＤは、表現の定義から構成されたものとして記述されてもよく、この場合、個々の表現は、それが、関連のメディアコンテンツを復号して提示するためのデータおよび／またはメタデータを含む１つ以上のメディアセグメントを順に並べたリストを記述するように提供される。同じ期間要素に関連する異なる表現は、メディアコンテンツの異なる選択肢を表し、この場合、個々の表現は少なくとも１つの表現属性によって区別できる。

連続した期間要素の関連する表現は、共通の設定に設定された特定の表現属性によって識別でき、それらが一緒になって特定のトラックまたはチャネルを形成する。各々が１つ以上の表現属性によって識別することができる２つ以上の代替表現を１つの期間要素に提供することによって、ＭＰＤを取得したクライアントは、個々の期間要素について、１つ以上の表現属性のそれぞれの設定に基づいて、代替表現の１つを選択することができ、それによって、個々の期間要素について、最も適切なメディアセグメントが、それらをそれぞれのソースから取り出すことによって、取得できるであろう。詳細には、クライアントは、１つのチャネルすなわちトラックから他のチャネルすなわちトラックへ切り換えることをいつでも選んでもよく、次いで、例えば環境の変化やユーザ選好のような状況の変化によって、別の代替トラックの方がより好ましくすなわち望ましくなるまで、選択されたトラックに留まってもよい。

クライアントがアクセスできる個々のメディアセグメントは、ＭＰＤの中に含まれるメディアセグメントＵＲＩによって一意に参照され、この場合、個々のメディアセグメントＵＲＩは、テンプレートを通して暗示的に作成されているか、または、例えばプレイリストのような、リストとして明示的に作成されていてもよい。

図２は、ＭＰＤを提供するためのサーバによって実行可能な方法を示すフローチャートの略図である。第１のステップ２００で、上記で論じた原則に従ってテンプレートの手法（アプローチ）、プレイリストの手法またはそれらの組み合わせを適用することによってＭＰＤが生成され、それによって、ＭＰＤの中に記述されることになるメディアプレゼンテーションの個々の期間について必要な選択肢が提供され、そして、その後の第２のステップ２１０で、生成されたＭＰＤがサーバによって提供され、それによって、典型的にはサーバで構成されたかまたは動作可能な形でサーバに接続された記憶手段の中にＭＰＤを記憶することによって、あるいは、ＭＰＤをキャッシュのような中間ノードに送信し、クライアントがＭＰＤをそこから要求してもよいようにすることによって、クライアントがＭＰＤにアクセスできるようになる。後者のステップは、図２に示すように、ＭＰＤを提供するステップと呼ばれてもよい。

サーバを介してメディアコンテンツを配信するコンテンツプロバイダは、特にライブセッションの間に、配信されるメディアコンテンツに関連するＭＰＤが更新可能であることを必要とすることがある。それによって、追加の表現が利用可能になりうるか、または、すでに利用可能な表現が削除または修正されうる。コンテンツプロバイダが、例えばライブセッションの間に、より高品質の表現を提供するか、または、ＭＰＤを介して提示されるメディアストリームの中に広告を挿入する際の柔軟性を高めることを決めることがある。

従って、ステップ２２０で示すように、ステップ２００で第１のＭＰＤを生成した後の任意の時点で、ＭＰＤは、期間要素の追加、削除または修正によって更新されてもよい。ステップ２２０で、いずれかのＭＰＤの更新が必要だと判定された場合、その後のステップ２３０で、更新されたＭＰＤがそれに応じて生成され、そして、更新されたＭＰＤがステップ２１０でサーバによって提供され、それによって、クライアントがそれにアクセスできるようになる。後者の場合、ステップ２１０は、例えば、１つ以上のクライアントに対して更新されたＭＰＤをプッシュすることを含んでもよい。しかし、ＭＰＤの中に記述されたメディアプレイ時間の開始時、またはＭＰＤの終了時の期間に限って、追加、削除、修正が行われてもよい。

次に、図２の生成ステップ２００および２３０について、図３を参照しながら一実施形態によって詳細に記述しよう。第１のステップ３００に示すように、メディアプレゼンテーションの第１の期間要素から始めるが、その後のステップ３１０に示すように、第１の期間要素について第１の表現が提供され、詳細には、第１の表現を記述する命令が提供される。後者のステップは、表現を表す設定を有する表現属性を表現に提供することを含んでおり、すべての必要な表現属性がその表現についてそれに従って設定されるまで繰り返される。また、後者のステップは、関連するメディアセグメントＵＲＩを個々の表現に提供することも含んでいる。ＭＰＤを生成する場合にどの代替表現が、そして任意で、代替期間構成が適用されるのかは、上記に示したように、さまざまな状況に依存する。表現属性は、それが、例えば代替選択肢としての言語、ビットレート、コーデック、解像度、あるいは、クライアントが選択可能であるべきいずれかの他の基準を定義するように設定されてもよい。

次のステップ３２０で、別の表現が関連の期間要素についてＭＰＤの中に提供されることになるかどうか、あるいは、提供された表現は期間要素についての最後の表現だったのかどうかが判定される。前者の場合、ステップ３３０と後続のステップ３１０とに示すように、別の表現を期間要素に対して提供することによってプロセスが続くが、後者の場合には、その後のステップ３４０で、構成中の期間要素が、ステップ３３０および３１０で生成された組に加えて、別の選択可能な選択肢としてＭＰＤの中に提供されることになる別の期間構成を、すなわち、１つ以上の表現の別の組を含むことになるのかどうかが、判定される。別の期間構成が、構成中の期間要素に関連する場合、新たな期間構成がステップ３５０で開始され、関連の表現および表現属性がステップ３３０および３１０で選択され、生成される。

また、ＭＰＤの更新の場合、ステップ３１０は、そのようなＭＰＤ更新に関連する命令を提供することを含んでいてもよい。典型的には、そのような情報は、期間レベルで提供される。加えて、ステップ３１０では、ＭＰＤによって記述されるＨＴＴＰトランスポートストリームのメディアプレイタイムラインのマッピングの記述が、いずれかのサーバタイムラインまたはウォールクロック時間、あるいはいずれかの他の時刻基準と共に、ＭＰＤの中に提供されてもよい。ステップ３１０で表現を提供する場合、それぞれの表現のメディアセグメントは、典型的にはそれらがそれぞれの期間要素の開始時に時間的に整合されるように、提供される。

異なる期間構成の場合、少なくとも１つの表現属性が、２つの期間構成を互いに区別するように設定され、一方で、少なくとも１つの他の表現属性が、期間構成の表現を少なくとも１つの他の表現と区別するように設定される。異なる階層レベルが適用される場合、個々の表現属性が、必要な階層レベルで提供される。

期間要素が準備できると、その後のステップ３６０で、１つ以上の表現が定義されることになる期間要素がまだあるかどうかが判定される。あるという場合には、ステップ３７０で次の期間要素が提供され、次の期間要素のうちのすべての期間要素がＭＰＤに含まれるまで、上述のステップが続けられる。ＭＰＤのすべての期間要素が定義され、それに従って構成された場合、最後のステップ３８０で示すように、生成手順は終了する。

典型的には、それぞれの期間要素のすべての表現に共通するいかなる表現属性も、それぞれステップ３００および３７０でＭＰＤの中に含められる。対応するやり方で、それぞれの期間要素の期間構成に共通するいかなる表現属性も、ステップ３５０でＭＰＤの中に含められる。

ＭＰＤがそれに従って構成され、クライアントがアクセスできるようにされると、これらのクライアントのいずれもＭＰＤにアクセスできるようになり、ＭＰＤのコンテンツ、すなわち、ＭＰＤの中に提供された命令に基づいて、クライアントは、トラックを選択できるようになり、それによって、関連のメディアセグメントを取得することができるであろう。ただし、クライアントの観点からは、ＭＰＤがそれに従って処理されると、ＭＰＤのコンテンツに基づいてメディアセグメントにアクセスするための手順は、複数の既知の先行技術の解決策に従って実行されてもよく、それは本書の範囲外である。

図４は、ＭＰＤの中で提示される代替選択肢として選択可能な必要なメディアプレゼンテーションをメディアコンテンツの形でクライアントが取得できるようにするために、クライアントで実行可能な方法を示す、もう１つのフローチャートである。図４の第１のステップ４００で、要求されたメディアプレゼンテーションに関連するＭＰＤが、例えばサーバまたは中間キャッシュのようなネットワークノードから取得され、その後のステップ４１０で、典型的にはクライアントかまたはクライアントに動作的に接続されたユニットにある従来の記憶手段の中にＭＰＤが記憶される。理解されるべきだが、必要なメディアプレゼンテーションに関連するＭＰＤをどのようにして見つけるかは、当業者には一般に周知であり、従って、本書の範囲外である。

クライアントでは、それぞれの期間要素の中に含まれる期間記述の形で提供されるＭＰＤのコンテンツは、別のステップ４２０で示すように、メディアプレゼンテーションの要求される部分に関連する第１の期間要素から、期間毎に識別できる。オンデマンドのメディアプレゼンテーションをダウンロードする場合、第１の期間要素は、それぞれのＭＰＤの最初の期間要素であろうし、一方で、ライブセッションをダウンロードする場合、第１の期間要素は、ＭＰＤの最初の識別できる期間要素、すなわち、ダウンロードが実行できる最初の期間要素であろう。

その後のステップ４３０では、個々の表現に特有の命令も、すべての表現または期間構成の中に表される表現のグループに関連する命令も含めて、関連の期間要素を表すＭＰＤのコンテンツが、これらの命令に少なくとも部分的に基づいてそれぞれの期間要素について表現が選択されうるように、問い合わせを受ける(interrogated)。異なる表現間の切り替えだけでなくそのような表現の選択も、すでに上述したように、１つ以上の基準に基づいていてもよい。加えて、ＭＰＤは、表現に依存しない追加の命令、例えば、更新されたＭＰＤをどのようにして取得するかに関する命令を含んでいてもよい。

無線リソースを浪費しないようにするため、クライアントは、それぞれの期間から１つの表現だけを取り出すべきであり、また、例えばビットレートのような符号化の選択は、期間要素毎に、例えば環境条件の変化に基づいて比較的頻繁に切り換えられてもよいが、その他の選択、例えば、所定の言語によって表される音声トラックは、リンクのビットレートの推定に基づいて、あるいは、いずれかの他の品質に基づく推定に基づいてダウンロードが変更されるべきではない。なぜなら、言語の変更は、異なるメディアビットレートで符号化された異なる言語間で切り換えが繰り返されることに起因して、非常に低い品質の体験をもたらしうるからである。

典型的には、能力に依存する表現属性に適用可能なクライアントの動作、例えば異なるディスプレイの解像度も同様に記述されてもよく、従って、クライアントに配信されるメディアコンテンツは、例えばＱＶＧＡおよびＶＧＡのような、異なる解像度で利用可能であってもよい。典型的には、クライアントは、取得されたメディアコンテンツがレンダリングされる前に、最良の適切な解像度を端末の選好および／またはユーザの選好に基づいて選択し、全部がダウンロードされる間、選択された解像度を維持する。あるいは、クライアントは、例えば、接続性が悪すぎるという理由で、ダウンロードする間に解像度を変更する選択肢を有する。例えば、選択された音声トラックが、プレイ時間のすべての期間中に利用できるのではない場合、クライアントは、代わりに、例えば、デフォルト言語または１番目に利用可能な言語を選択するように構成されてもよい。

また、表現および／または期間構成の選択は、測定値または推定値、例えば利用可能なビットレートの推定値に基づいてもよく、それは典型的にはクライアントによって連続して行われる。ビットレートの推定を行う場合、典型的には、異なる品質の表現が、そのような推定値に基づいて選択されてもよい。

表現が選択されると、ステップ４４０に示すように、関連のメディアセグメントをそのソースから、ＭＤＰのそれぞれの命令に従って取り出すことができる。次のステップ４５０で、必要なメディアプレゼンテーションを取得するために何らかの別の期間要素が関連するかどうかが判定され、もしそうなら、次の期間要素の表現が検討されてステップ４３０で選択され、その後、プロセスは、選択された表現に関連するメディアセグメントをステップ４４０に従って取得することによって続けられる。

また、特定の期間要素について２つ以上の期間構成が定義された場合、そのような代替期間構成の表現が、ステップ４３０で検討され、その結果、それぞれの期間要素の期間構成のうちの１つから１つの表現が選択される。ダウンロードに関係する期間要素がこれ以上存在しない場合、すなわち、クライアントに必要なメディアプレゼンテーションの全部がダウンロードされた場合、ステップ４７０に示すように、記述するプロセスは完了する。

次に、上記で提案したＭＰＤ構造すなわち構成の基本原理の一部を、以下で図５を参照しながら記述しよう。図５に示すように、ＭＰＤを通して記述される単一のメディアプレイのタイムライン５００が１つ以上のプレイ時間の期間に再分割され、それにより、プレイタイムライン５００は、ＭＰＤによって記述される個々の期間または期間要素のタイムラインの連結によって定義される。ＭＰＤは、本書では２つの期間要素５０１および５０２として示す、１つ以上の期間要素のシーケンスを含んでおり、この場合、個々の期間要素は、本書では記述されたメディアプレゼンテーションすなわちメディアストリームのメディアコンテンツの表現または表現要素と呼ぶ、同じメディアコンテンツの代替記述を１つ以上含んでいる。あるいは、ＭＰＤは、メディア構成要素毎に１つのメディアタイムラインを含んでいてもよく、それにより、例えば音声と動画のような、同期ポイントを持つ別個のタイムラインが適用されてもよい。

図５では、第１の期間要素５０１は、３つの異なる表現５０３ａ、５０３ｂ、５０３ｃを含んでおり、それらは、本書ではビットレート属性によって、すなわち、それぞれ１００ｋｂｐｓのビットレートを表す低品質（ＬＱ）属性と、２００ｋｂｐｓを表す中位品質（ＭＱ）属性と、４００ｋｂｐｓを表す高品質（ＨＱ）属性とで表す異なる表現属性を表し、かつ、それら異なる表現属性によって区別できるが、一方で第２の期間要素５０２は、１５０ｋｂｐｓのＬＱ選択肢と５００ｋｂｐｓのＨＱ選択肢とを提供する２つの代替的表現５０４ａ、５０４ｂだけを含んでいる。同じ期間について記述された複数の表現のメディアセグメントは、典型的には、期間要素の開始時に時間的に整合されている。図５のＭＰＤは、それゆえ、それぞれの表現または表現要素の中にすべての命令が構成されるように、すなわち、表現のコンテンツを考慮することによって、その表現について有効なすべての命令をクライアントが利用できるように構成されている。

期間要素の個々の表現は、１つ以上の表現属性を除いて同じコンテンツを記述し、ここでは、選択可能な選択肢がクライアントに提供されることになる場合、１つ以上のこれらの特性は表現毎に異なりうる。

一般に、同じコンテンツが、異なる表現を使って利用可能であったり、１つ以上の表現属性を介して識別可能であったりしてもよく、それらの各々が、クライアントについての代替選択肢を定義してもよい。代わりに、それぞれの期間要素についてのそれぞれの表現属性という点ではクライアントについての選択肢がまったく利用できない場合、この属性に、期間要素のすべての表現と同じ設定を与えることができる。図５に示すように、本書ではそれぞれＨ．２６４＠Ｂａｓｅｌｉｎｅ Ｐｒｏｆｉｌｅ Ｌｅｖｅｌ １．３およびＡＡＣ ａｕｄｉｏに設定されたそれぞれの表現属性によって定義された動画および音声特性が、２つの図示する期間要素のすべての表現について有効な共通の表現属性として定義されており、すなわち、これらの特性は、クライアントが選択できないものであるが、図５に示すすべての期間について、または少なくとも２つの期間について、クライアントによって適用されると想定されている。

異なるメディア品質を表す表現が、典型的には一部の環境の態様、例えば利用可能なビットレートに基づいて選択可能でありうる一方で、異なる言語を有する表現は、代わりに、通常は、例えば要求されたコンテンツを特定の好適言語によって取得するという選好のように、ユーザの選好に基づいて選択可能であるか、あるいは、例えば要求されたコンテンツが英語版に限って入手可能であるというように、コンテンツの提供の仕方に基づいて選択可能であるかのいずれかである。それゆえ、後者の場合、言語は、クライアントによって認識されうる起こりうる環境の変化に関係なく、典型的にはその後の期間についても選択されて維持される。同じことは、典型的にはユーザ装置のディスプレイのタイプに依存し、かつ、典型的にはメディアプレゼンテーションのアップロードの間に変化することのない、異なる解像度について定義された表現についても言える。

別の実施形態によると、ＭＰＤは、すべての表現に共通する表現属性がＭＰＤの高位階層レベル、期間要素レベル、または期間レベルに置かれることを可能にする階層型記述構造として生成または構成することができるが、一方で、期間要素の代替表現間で異なる、すなわち、それぞれの表現に限って有効であることになる表現属性は、本書では表現レベルと呼ばれる、ＭＰＤの低位階層レベルで提供される。また、以下でさらに記述するように、別のレベル、例えば中間的な期間構成レベルが、そのような階層構造に適用されてもよい。

図６は、そのような代替的階層構成の構造を示す図であり、ここで、ビットレート以外の図５のＭＰＤの中に記述されたすべての動画および音声関連の表現属性が、個々の期間６０１、６０２のそれぞれについての期間レベルで共通して定義されている。図２の実施形態と同様に、本書では期間６０１について３つの表現６０３ａ、６０３ｂ、６０３ｃと、期間６０２について２つの表現６０４ａ、６０４ｂとによって表されている個々の表現要素が、ビットレートに依存する代替表現として与えられており、それらは、例えば、期間６０１の表現についてそれぞれＬＱ、ＭＱ、ＨＱに、そして、期間６０２の表現についてそれぞれＬＱ、ＭＱに設定された、それらのビットレート属性によって識別されてもよく、すなわち、ビットレート属性は表現レベルで定義される。

あるいは、ＭＰＤの１つ以上の期間要素について、２つ以上の属性がクライアントによって選択できるようにされてもよい。図７は、別の実施形態による、そのような代替的な階層的ＭＰＤ構造を記述する図であり、ここで、第１および第２の期間７０１、７０２は、図６のそれぞれの第１および第２の期間に対応する。しかし、第３の期間７０３では、期間要素は、以下それらを代替期間構成と呼ぶ、２つの異なるグループの表現７０４ａ、７０４ｂを含んでおり、それらは、表現レベルより上だが期間レベルより下の、別の階層レベルを形成している。代替期間構成を導入することによって、選択可能な表現が異なるグループへと構成されてもよく、それによって、クライアントは、それぞれの表現を２つ以上の選択基準に基づいて容易に選択できるようになる。

本例示的期間構成では、７０４ａは、共通言語属性（Ｌａｎｇ）が英語（ｅｎ）に設定された、言語に基づく表現グループを含み、一方で、代替期間構成７０４ｂについては、対応する表現グループは、共通言語属性（Ｌａｎｇ）がフランス語（Ｆｒ）に設定されている。第１の期間構成７０４ａは、２つの異なるビットレートＬＱおよびＨＱをそれぞれ記述する２つの代替的表現７０５ａ、７０５ｂを含んでおり、一方で、第２の期間構成７０４ｂは、３つの異なるビットレートＬＱ、ＭＱ、ＨＱを記述する３つの代替的表現７０６ａ、７０６ｂ、７０６ｃを含んでいる。それによって、好適言語、すなわち、期間構成７０４ａ、７０４ｂの１つを選択したクライアントは、選択された期間構成から好適品質も選択し、従って、これらの利用可能な選択肢のうちのどちらが選択されるかによって、異なるメディアセグメントも取り出すであろう。図示するように、それぞれの期間構成についての残りの所与の表現属性は、期間レベルで与えられており、それゆえ、すべての３つの期間のメディアセグメントに共通の、選択不可能な選択肢である。

それぞれの表現のメディアセグメントのそれぞれのシーケンスを参照するＵＲＩのシーケンスをＭＰＤの中に記述するやり方は、さまざまである。上記の実施形態については、それぞれのメディアセグメントは、テンプレートの手法を適用することによって記述されてもよいし、あるいは、メディアセグメントが、リスト、典型的にはプレイリストによって、明示的に記述されてもよい。あるいは、両方の手法の組み合わせが適用されてもよい。

テンプレートの手法が適用される場合、それぞれのメディアセグメントは、基準トラックのセグメント毎に、すなわち、特定の表現属性によって表される表現毎に、同じメディア存続時間を含むべきであり、それによって、クライアントは、コンテンツの通常のメディアプレイ時間を導出できるようになる。従って、例えばメディア表現のそれぞれの期間の開始および存続時間のような情報を特定する有効な指標の範囲が、個々のテンプレートについて定義される。

テンプレートとして記述されるメディアセグメントＵＲＩのシーケンスは、ここでは１つのＵＲＬによって記述されるが、例えば以下のように定義されてもよい。

ここで、＄ＳｅｇｍｅｎｔＮｕｍｂｅｒ＄と識別された指標は、それぞれのセグメントの番号を識別するためにＭＰＤの中で用いられる。上記のテンプレートは、２００ｋｂｐｓに設定された帯域幅固有の表現属性を含んでいる。加えて、ここでは、記述されたメディアセグメントシーケンスの有効な指標の範囲は、ここではセグメント番号１１に設定された「ＳｅｇｍｅｎｔＮｕｍｂｅｒＳｔａｒｔ」によるそれぞれの表現の開始と、ここでは１０秒のセグメント存続時間に設定された「ＳｅｇｍｅｎｔＤｕｒａｔｉｏｎ」による存続時間とを通じて記述され、すなわち、引用された要求ＵＲＬから取得されうる個々のセグメントは、１０秒の長さの存続時間を有する。

代わりに、メディアセグメントを参照するＵＲＩのシーケンスを記述するのにプレイリストの手法が用いられる場合、個々の参照されるメディアセグメントは、異なる存続時間のメディアデータを含んでいてもよい。プレイリストとして記述される１つの表現に関連するメディアセグメントＵＲＩのシーケンスの一例を以下に示す。

本書では「ｓｅｇｍｅｎｔ ｄｕｒ」と示す、メディアセグメントのメディア存続時間を定義する指標が、個々のメディアセグメントについて与えられ、それによって、クライアントが、受信されたセグメントから通常のプレイタイムラインを計算できることが好ましい。与えられたプレイリストの例に示すように、正確な存続時間は秒単位で記述される。

標準的テンプレートをベースにし、すなわち、プレイリストを用いず、２つの代替表現を持つ１つの期間を記述する、階層的に構成されたＭＰＤのもう１つの例を以下に示す。

明らかに、上記のテンプレートは、同じ長さの単一の期間を有する、２４０秒の長さのセッションを記述している。表現レベルで提示される共通言語として英語（ｅｎ）を有する２つの異なる表現が含まれているが、ここでは、これらの表現は２つの表現の中の異なる帯域幅属性によって区別できる。与えられた期間については、いずれの表現にも共通する一部の表現属性、例えば、１．０に設定されたｘｍｌバージョンと、ＵＴＦ−８に設定された符号化とが、期間レベルでＭＰＤに挿入される。

プレイリストスタイルのＭＰＤは、上記のテンプレートをベースにしたものと同様の構造を有しているが、プレイリストスタイルのＭＰＤは複数の期間要素を含んでいるという違いがある。テンプレートをまったく用いず、３つの期間を含んでいる、そのようなプレイリストスタイルのＭＰＤの一例を以下に挙げる。

上記のＭＰＤは、個々の期間について好適な帯域幅の選択を可能にする帯域幅属性を有する表現を備えているが、プレイリストの最初に示されるその他の表現属性は、すべての期間および表現について共通である。個々の期間について、クライアントは、記述されたＵＲＬを用いて単一の要求を行い、個々の期間を順次プレイアウトする。

下記のもう１つの実施形態によると、ＭＰＤは、代わりに、プレイリストとテンプレートとの組み合わせとして構成されてもよい。そのような構成によって、複数のソースからダウンロード可能なコンテンツの受信が可能になる。与えられた例では、プレイリストが、「期間開始」０、１１０、１２０をそれぞれ有する３つのテンプレート表現を連結する。そのようなＭＰＤは、例えば、真ん中に広告を挟んで２つに分割されたＴＶ番組を記述するのに適していることがある。クライアントが、上記の例と同様に第１および第３の期間について要求を行ってもよく、ここで、適切な表現が選ばれてもよく、一方で、第２の期間では、利用可能な表現は１つだけであり、クライアントはその表現にアクセスするため、別のサーバに要求を行うことができるであろう。

上記で分かるように、チャネルすなわちトラックの間には多くの相互関係、すなわち、異なる代替表現の間の選択および切り換えの仕方の選択肢があってもよい。例えば、１つを除くすべてのチャネルが英語で提供されてもよいし、あるいは、異なる表現を記述するＵＲＬでさえ、まさに最後の文字に至るまで共通であってもよい。

一実施形態によると、例えば言語属性のような表現属性が、階層構造のすべてのレベルで適用されることにより、言語が、上書きされない限り、該当するサブツリー全体について定義されてもよい。

別の手法は、本書ではＲｅｑｕｅｓｔＵＲＬＥｘｔｅｎｔｉｏｎ要素と呼ぶ拡張要素が表現レベルで定義されることを可能にすることであり、一方で、ｒｅｑｕｅｓｔＵＲＬは、期間要素レベルで例えば以下のように記述されてもよい。

RequestURL=http://www.example.com/content/example.3gp

ここで、期間要素レベルのこのＵＲＬは、表現レベルでは、例えば以下のように拡張される。

RequestURLExtension="R2/$SegmentNumber$

上記の例では、クライアントが要求を行うために、クライアントは、“RequestURL=http://www.example.com/content/example.3gp”と“R2/$SegmentNumber$”とを連結することによって、コンテンツのＲｅｑｕｅｓｔＵＲＬを、それぞれの表現を選択するために以下のように生成する。

http://www.example.com/content/example.3gp R2/$SegmentNumber$

以下に、階層的に記述された表現属性の別の例を示すが、ここでは、動画コンテンツのサイズおよび言語属性が期間レベルで第１および第２の期間の中に示されており、それゆえ、これらの選択肢はいずれも、これらの期間のすべての表現について有効である。

第３の期間では、代わりに、動画コンテンツのサイズおよび帯域幅属性が、高位の期間レベルで示されており、それゆえ、これらの表現属性は、これらの期間のすべての表現について有効であり、一方で、言語は、第３の期間の個々の表現について異なっており、表現レベルの言語属性として示す。

表現属性も階層的に記述されている別の実施形態によると、期間要素は、それについてのメディアセグメントＵＲＩが記述されるメディアプレイ開始時刻を含めて、存続時間を記述する。表現要素は、単一のストリーム特性について、例えば、２００ｋｂｐｓストリームについてのメディアセグメントの第１のトラックと４００ｋｂｐｓのストリームについてのメディアセグメントの第２のトラックとについて、すべてのＵＲＩをカプセル化する。

以下に示すＭＰＤでは、第１の期間はテンプレートに基づく構成を用いて記述され、第２の期間はプレイリスト構成を用いて記述される。すでに上述したように、プレイリスト構成によって記述されたメディアセグメントについてのコンテンツの存続時間は、異なる表現については、異なっている。

第１の期間の間、メディアセグメントは、２００ｋｂｐｓの品質レベルについての１０秒間のメディアデータと、４００ｋｂｐｓの品質レベルについての５秒間のメディアデータとを含んでいる。しかし、個々のメディアセグメントは、まさに、まったく同じメディア存続時間を含んでいる。

第２の期間の間、メディアセグメントの存続時間は変化する。帯域幅属性が２００ｋｂｐｓに設定されているＬＱ表現については、メディアセグメントは平均して２０秒間のメディアデータを含んでおり、一方でＨＱバージョンのメディアセグメント、すなわち、帯域幅属性が４００ｋｂｐｓに設定されているセグメントについては、メディアセグメントは平均して１０秒間しか含んでいない。

ＭＰＤは、必要に応じていつでも更新されてよい。図８ａおよび８ｂは、略図であるが、ここで図８ａは、それぞれの表現を持つ２つの期間要素８０１、８０２を含む古いＭＰＤの図であり、図８ｂは、メディアプレイタイムラインの終点に追加された第３の期間の中に３つの代替表現を含む追加の期間要素８０３を備えた、更新されたＭＰＤの図である。更新の間、最新の期間記述は、メディアＵＲＩの有効範囲を記述するように修正されなければならない。また、テンプレート構成も、新たな表現の追加に起因して変更されてもよい。図８ａおよび図８ｂに示すように、期間８０１および８０２の命令は、古いＭＰＤにおいても更新されたＭＰＤにおいても同一である。

ＭＰＤの更新がまったく適用されない場合であっても、ライブ事例についてのサポートは可能でありうる。明確な終点を有するものであればいかなるライブ送信であっても、少なくとも大まかな精度でクライアントがサーバと時間的に同期していれば、関連のＭＰＤを通して記述することができる。そのような状況でＭＰＤは、それぞれのメディアプレイタイムラインとサーバの時刻またはウォールクロック時間、例えばＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｅｒｉｏｄ）とのマッピングを記述するように構成されてもよい。

例えば、ＭＰＤが、メディアプレイ時間は１６０５ｈ ＣＥＴに始まると定義してもよい。クライアントが一定の精度で時間的に同期された場合、クライアントは、最新の利用可能なメディアセグメントかまたはクライアントで現在構成中のメディアセグメントを判定することができるであろう。

タイムシフトは、ライブ事例に依存するであろう。「最新の利用可能なメディアセグメント」の十分に正確な理解を端末が有する場合、タイムシフトバッファは、「通常のメディアプレイ時間」または「セグメントの番号」において記述されてもよい。他の方法、例えばウォールクロック時間を通してタイムシフトバッファを記述することも可能である。

次に、サーバから利用可能になるようにされうるＭＰＤ更新の場合について、クライアントがＭＰＤ更新に気付くことを可能にする２つの異なる手法を以下に記述しよう。

第１の実施形態によって、クライアントが、サーバから、またはキャッシュあるいはいずれかの他の中間ネットワークノードから、新たなＭＰＤ更新についての頻繁なポーリングを行うように構成される。ポーリングの間隔は、典型的にはＭＰＤの記述の中に与えられるが、代替案として、事前設定されてもよい。ＭＰＤファイルは、典型的にはメディアセグメントより非常に小さく、従って、ＨＴＴＰキャッシュにとって、メディアセグメントを処理するよりはるかに容易である。また、従来のキャッシング階層は、典型的には、徐々に増加する多数の小さな文書を、それゆえ、更新されたＭＰＤを、処理するよう、最適化されている。

別の実施形態によると、クライアントは、代わりに、プッシュ通知手法を適用するように構成され、この場合、クライアントは、サーバによって、典型的には関連のメディアセグメントと一緒にインチャネルで送信される通知を受信することによって、ＭＰＤ更新について通知される。新たなＭＰＤは、関連のメディアセグメントと一緒に、サーバによってマルチパートＭＩＭＥコンテナの中で提供されてもよい。中間的なキャッシュが、いずれかの他のタイプのファイルが処理されるのと同様に、そのようなマルチパートＭＩＭＥコンテナを処理してもよい。クライアントがタイムシフトモードにある場合、クライアントは、典型的には、いずれかの探索動作を開始する前にＭＰＤ更新についてポーリングするように構成されるであろう。

次に、上記のいずれかの実施形態による構造を有するＭＰＤを提供するように構成されたサーバについて、図９の簡略化したブロックスキームを参照しながら記述しよう。サーバ９００は、プレイタイムラインの個々の期間について、関連の表現と、任意で、代替の期間構成とを、第１の通信ユニット９２０を介していずれかのタイプの従来のメディアソース（図示しない）からサーバ９００に入力データとして提供されたそれぞれのメディア表現について、生成するように構成された生成ユニット９１０を備えており、それにより、それぞれの表現に関連する選択可能な表現属性が、クライアントに選択可能な選択肢として入手可能になる。

また、生成ユニット９１０は、典型的には、必要な場合にはいつでも上記の手順に従ってＭＰＤを更新するように構成される。本書ではサーバ９００の提供ユニット９３０と呼ばれるもう１つのユニットが、要求側クライアントがＭＰＤにアクセスできるようになるようにＭＰＤを提供するように構成される。従って、一実施形態によると、提供ユニット９３０は、ＭＰＤをいずれかのタイプの記憶手段の中に記憶するように構成され、それにより、サーバ９００にアクセスするクライアントが、本書では第２の通信ユニット９４０によって表す通信ユニットを介して記憶手段にＭＰＤを要求し、取得してもよい。本書では、そのような記憶機能性は、いずれかのタイプの従来の記憶機能性に基づきうる記憶ユニット９５０によって提供される。あるいは、提供ユニット９３０は、中間的なネットワークノード、例えばキャッシュに対して、第２の通信ユニット９４０を介してＭＰＤを送信するように構成され、それによって、クライアントが、必要なときにはいつでも中間ノードからＭＰＤを取得できるようになされてもよい。

また、上記のように、サーバ９００は、サーバ９００によって以前に生成されてサーバ９００に記憶されたＭＰＤを更新するように構成されてもよい。また、そのような更新の選択肢が適用されることになる場合、生成ユニット９１０は、適切な機能性を備えるであろうが、それによって、ＭＰＤの既存の期間要素に対する１つ以上の表現の追加と、新たな期間要素の追加と、期間要素から１つ以上の表現を削除することと、および／または、１つ以上の表現を修正することとがそれに従って可能になりうる。ＭＰＤを修正するための命令は、本書ではＵＩ９６０によって表す、いずれかのタイプのユーザインタフェース（ＵＩ）を介して生成ユニット９１０に提供されてもよい。ＭＰＤによって記述されるメディアプレイ時間は、「未来」に限定されない。コンテンツプロバイダは、既存の期間要素または新たな期間要素の１つ以上の新たな表現を追加しようと思う場合、サーバ９００を、新たな期間記述がメディアプレイタイムラインの最後に追加され、いずれの以前の期間要素も変更されないままであるように制御してもよい。

次に、対応するかたちで、例えば移動電話、セットトップボックス、ラップトップまたはＰＣのような、メディア表現をレンダリングでき、かつ、ＭＰＤおよび関連するメディアセグメントをネットワークノードから、例えばサーバまたはキャッシュから要求できる、いずれかのタイプのユーザデバイスの中に実装されるのに適したクライアントを、図１０の簡略化したブロックスキームを参照しながら以下により詳細に記述しよう。

クライアント１０００は、典型的にはユーザインタフェース（ＵＩ）を介して入力されたコマンドに基づいて、通信ユニット１０２０を介してＭＰＤおよび関連するメディアセグメントをネットワークノードに要求して取得するように構成された要求ユニット１０１０を備えており、ユーザインタフェース（ＵＩ）は、本書ではＵＩ１０３０によって表されるが、いずれのタイプの従来のＵＩであってもよい。また、クライアント１０００が、見込まれる選択肢として上述したように、更新されたＭＰＤについてポーリングするように構成されている場合、要求ユニット１０１０は、そのようなポーリングを、典型的にはＭＰＤから以前に取得されたポーリング間隔に従って、実行するように構成されてもよい。ポーリングメカニズム自体は当業者には周知であり、それゆえ、本書の範囲外である。

また、クライアント１０００は記憶ユニット１０４０も備えていて、これは、いずれかのタイプの利用可能な記憶技術に基づいて構成され、かつ、要求ユニット１０１０に接続されていてもよく、それにより、通信ユニット１０２０を介して要求ユニット１０１０によって受信された後、ＭＰＤが記憶され、それゆえ、メディアプレゼンテーションの目的でクライアント１０００がアクセスできるようになされている。また、クライアント１０００は、それぞれの期間要素に適用されうるような１つ以上の選択基準に従って表現および／または期間構成を選択するように構成された選択ユニット１０５０を備えている。選択ユニット１０５０は、例えば、ユーザによって選択された好適言語のような選択肢を、ＵＩ１０３０を介して受信してもよく、次いで、その入力が、関連の期間構成またはそれぞれの期間要素についての表現を選択するために選択ユニット１０５０によって用いられる。

エンドユーザに最良の品質の体験を提供するために、クライアント１０００は、利用可能なリンクのビットレートによる表現間で、またはいずれかの他の品質に関連する推定値によって表現を切り換えることによって、メディア表現のメディア品質を適応的に調整するように構成されてもよい。また、そのような選択肢を提供するために、クライアント１０００は、適切なパラメータを典型的には連続的に推定し、かつ、その推定値に基づいて最適で実装特有の表現を選択するように構成されたユニットを備えていてもよい。本書では、そのような機能性は、推定ユニット１０６０によって提供される。推定ユニット１０６０は、典型的には、推定されたビットレートが、事前設定されたマージンを持つ現在選択されている表現によって表されるビットレートを上回るもしくは下回る場合に、或る代替表現から別の表現へと切り換えるように構成されてもよい。

あるいは、またはＵＩ１０３０から提供される入力に加えて、選択ユニット１０５０は、それゆえ、推定ユニット１０６０から提供された入力データだけ、もしくは、ＵＩ１０３０からの入力との組み合わせに基づいて決定を行うように構成されてもよい。さらに、選択ユニット１０５０は、事前設定され記憶された設定もしくは選好を、上記の見込まれる入力データと組み合わせて、あるいは優先設定として考慮するように構成されてもよい。一例として、クライアントが常駐しているユーザデバイスのディスプレイは事前設定され、かつ、他の選択肢より優先されてもよい。

また、図１０の選択ユニット１０５０は、選択された表現のＵＲＩを順に並べたそれぞれのリストに従って、選択されたメディアセグメントを１つ以上のそれぞれのネットワークノードから要求するように要求ユニット１０１０に命令することができるように、動作的に要求ユニット１０１０に接続されている。

また、典型的には、通信ユニット１０２０は、典型的にはＭＰＤから取得された同期情報に基づいて、サーバとの同期を可能にするための機能性を備えている。

選択ユニット１０５０によって表現の選択が実行され、対応するメディアセグメントが要求ユニット１０１０によって要求されると、関連のメディアセグメントが典型的にはクライアントの通信手段によって、または、クライアント１０００が常駐するデバイスによって受信され、ここでメディアセグメントは、それらが従来のやり方でレンダリングされうるようにバッファリングされる。また、メディアセグメントを取得して処理するプロセスは、当業者には周知であり、それゆえ、本書ではこれ以上詳しくは論じない。

理解されるべきだが、図９のサーバも図１０のクライアントもいずれも、簡略化した構成を表しており、ここでは、典型的には通常のサーバもしくはクライアントの中にそれぞれ含まれるけれども本書で提案するＭＰＤの取扱の理解には必須ではないエンティティは、分かりやすくするため省略されている。加えて、理解されるべきだが、これらの図の中に示すユニットは、１つのありうる構成として考えられるだけであって、他の機能性ユニットならびに他の組み合わせの機能性ユニットも、記述された機能性が上記の一般原則に従って実行可能である限り、適用可能でありうる。

サーバならびに上記のクライアントは、それぞれのハードウェアに基づく解決策として、ソフトウェアに基づく解決策として、あるいはそれらの組み合わせとして、実装されてもよい。前者の場合、それぞれ図９および図１０で記述されたそれぞれのユニットは、それぞれのＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）構成の形で実現されてもよい。

次に、ソフトウェアに基づく解決策として構成されたサーバ１１００について、図１１を参照しながら記述するが、ここではプロセッサ１１１０が、記憶ユニット８３０と、第１の通信ユニット８２０と、第２の通信ユニット８４０とに接続されていて、記憶ユニット８３０の中に維持された命令に基づいてサーバ機能性を制御するように構成されている。詳細には、プロセッサ１１１０は、図８の生成ユニット８１０の機能性に対応する機能性を実現することによってＭＰＤを生成するように構成された生成機能１１２０と、図８の提供ユニット９３０の機能性に対応する機能性を実現することによって生成されたＭＰＤを提供するように構成された提供機能１１３０とを制御するように構成されている。

次に、対応するかたちで、ソフトウェアに基づくクライアント１２００について、図１２を参照しながら以下に記述するが、ここでは、通信ユニット９２０と記憶ユニット９４０とに接続されたプロセッサ１２１０が、記憶ユニット９４０の中に含まれる命令に基づいて、図９の対応する要求ユニット９１０および選択ユニット９５０によってそれぞれ行われることに対応する機能性を実行するために、要求機能１２２０と選択機能１２３０とを制御するように構成されている。

加えて、プロセッサ１２１０は、図９の推定ユニット９６０の機能性に対応するかたちで推定機能性を実行するように構成された推定機能１２４０を制御するように構成されてもよい。

Claims (37)

1. 通信ネットワークのサーバによって実行される、ＨＴＴＰメディアストリームにクライアントがアクセスできるようにする方法であって、
   ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）を生成するステップであって、メディア再生タイムラインに従って連続的に配列される少なくとも２つの期間要素を前記ＭＰＤに与えるようにし、各期間要素が少なくとも１つの表現を含むと共に前記期間要素のうちの少なくとも１つが少なくとも２つの表現を含むように少なくとも１つの表現を各期間要素に与えるようにし、各表現には少なくとも１つのメディアセグメントＵＲＩを順に並べたシーケンスが与えられ、各メディアセグメントＵＲＩは前記ＨＴＴＰメディアストリームの少なくとも１つのメディアセグメントを参照する、ステップと、
   前記ＭＰＤを提供するステップであって、これにより、前記クライアントが、前記ＭＰＤを取得し、前記ＭＰＤの内容に基づいて少なくとも１つの期間要素についての表現を選択し、選択した各表現について参照される各々のメディアセグメントを取得することができるようにする、ステップと、
   を備えることを特徴とする方法。
2. 前記生成するステップは、
   少なくとも１つのメディアセグメントＵＲＩを順に並べたシーケンスを少なくとも１つ用意するステップであって、当該シーケンスは少なくとも１つの表現として提供されると共にテンプレート形式で記述される、ステップ
   を備えることを特徴とする請求項１に記載の方法。
3. 前記生成するステップは、
   少なくとも１つの前記表現を用意するステップであって、当該表現は少なくとも２つのメディアセグメントＵＲＩを順に並べたシーケンスとして提供されると共にプレイリスト形式で記述される、ステップ
   を備えることを特徴とする請求項１又は２に記載の方法。
4. 前記生成するステップは、
   同一の期間要素に関連する各表現に対して第１の表現属性を提供するステップであって、当該第１の表現属性は前記表現において参照されるメディアセグメントを代表する設定を有し、これにより、前記クライアントが前記設定の各々に基づいて各期間要素の表現を選択することができるようにする、ステップ
   を備えることを特徴とする請求項１乃至３のいずれか１項に記載の方法。
5. 前記生成するステップは、
   各期間要素に対して第２の表現属性を与えるステップと、
   前記期間要素に関連する全てのメディアセグメントに共通する前記第２の表現属性の設定を選択するステップであって、当該設定が前記期間要素に関連する全ての表現を代表するようにする、ステップと、
   を備えることを特徴とする請求項４に記載の方法。
6. 前記生成するステップは、
   各期間要素の各表現において各第２の表現属性を提供するステップであって、前記第２の表現属性が表現レベルで記述されるようにする、ステップ、又は、
   各期間要素において各第２の表現属性を提供するステップであって、前記第２の表現属性が期間要素レベルで記述されるようにする、ステップ
   を備えることを特徴とする請求項５に記載の方法。
7. 前記生成するステップは、
   前記ＭＰＤの少なくとも１つの期間要素に対して少なくとも２つの代替期間構成と第２の表現属性とを与えるステップであって、各期間構成には少なくとも２つの表現が与えられる、ステップと、
   前記第２の表現属性の設定を選択するステップであって、当該設定が各期間構成を代表するようにし、これにより、前記クライアントが前記第１及び第２の表現属性の一方又は両方に基づいて前記期間要素の表現を選択できるようにする、ステップと、
   を備えることを特徴とする請求項４に記載の方法。
8. 前記第１及び第２の表現属性の各々は、コーデック、ビットレート、解像度、及び言語のうちの任意のものを規定する
   ことを特徴とする請求項５、６、又は７に記載の方法。
9. 前記ＭＰＤに対して少なくとも１つの表現を追加すること、前記ＭＰＤから少なくとも１つの表現を削除すること、又は、前記ＭＰＤの少なくとも１つの表現を変更することにより、前記ＭＰＤを更新するステップ
   を更に備えることを特徴とする請求項１乃至８のいずれか１項に記載の方法。
10. 前記生成するステップは、
    前記ＭＰＤに対してポーリング間隔の指示情報を与えるステップであって、これにより、前記クライアントが前記指示情報により決定される間隔でＭＰＤの更新をポーリングすることができるようにする、ステップ
    を備えることを特徴とする請求項９に記載の方法。
11. 前記更新されたＭＰＤを前記クライアントへプッシュするステップ
    を更に備えることを特徴とする請求項９に記載の方法。
12. 前記生成するステップは、
    前記ＭＰＤに対してサーバのタイムライン又はウォールクロック時間のうちの任意のものに対する前記ＨＴＴＰメディアストリームの前記メディア再生タイムラインのマッピングに関する記述を与えるステップ
    を備えることを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
13. 前記生成するステップは、
    同一の期間要素に関する異なる表現のメディアセグメントを用意するステップであって、当該異なる表現のメディアセグメント同士が前記期間要素の開始の時点で時間的に揃っているようにする、ステップ
    を備えることを特徴とする請求項１乃至１２のいずれか１項に記載の方法。
14. 通信ネットワークのクライアントによって実行される、前記通信ネットワークの少なくとも１つのネットワークノードからＨＴＴＰメディアストリームを取得する方法であって、
    メディア再生タイムラインに従って連続的に配列される少なくとも２つの期間要素を含むＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）を前記少なくとも１つのネットワークノードから取得するステップであって、各期間要素は少なくとも１つの表現を含むと共に前記期間要素のうちの少なくとも１つは少なくとも２つの表現を含み、各表現は少なくとも１つのメディアセグメントＵＲＩを順に並べたシーケンスを含み、各メディアセグメントＵＲＩは前記ＨＴＴＰメディアストリームの少なくとも１つのメディアセグメントを参照する、ステップと、
    前記ＭＰＤの内容に基づいて前記期間要素の少なくとも１つについての表現を選択するステップと、
    選択した各表現について、各表現に関連する参照されるメディアセグメントを取得するステップと、
    を備えることを特徴とする方法。
15. 前記選択するステップは、
    各期間要素の１以上の表現属性に基づいて各表現を選択するステップであって、各表現属性は各表現又は期間要素を代表する設定を有する、ステップ
    を備えることを特徴とする請求項１４に記載の方法。
16. 前記少なくとも１つのネットワークノードから前記クライアントへ前記ＨＴＴＰメディアストリームを送信するのに利用可能なビットレートを推定するステップと、
    前記１以上の表現属性のうちの少なくとも１つを考慮することにより前記推定に基づいて少なくとも１つの期間要素の表現を選択するステップであって、ビットレートは表現属性に依存する、ステップと、
    を更に備えることを特徴とする請求項１５に記載の方法。
17. 前記選択するステップは、
    少なくとも１つのクライアント能力を更に考慮することにより各表現を選択するステップ
    を備えることを特徴とする請求項１５又は１６に記載の方法。
18. ＭＰＤの更新がないか前記ネットワークノードをポーリングするステップと、
    前記ＭＰＤが更新されたと判定された場合に、当該更新されたＭＰＤを取得して記憶するステップと、
    を更に備えることを特徴とする請求項１４乃至１７のいずれか１項に記載の方法。
19. 前記ポーリングするステップは、以前に取得したＭＰＤから取得されるポーリング間隔に従って実行される
    ことを特徴とする請求項１８に記載の方法。
20. 前記少なくとも１つのネットワークノードから提供されるプッシュ通知の中で更新されたＭＰＤを受信するステップと、
    前記更新されたＭＰＤを記憶するステップと、
    を更に備えることを特徴とする請求項１４乃至１７のいずれか１項に記載の方法。
21. ＨＴＴＰメディアストリームにクライアントがアクセスできるようにすることができる、通信ネットワークのサーバであって、
    ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）を生成するように構成された生成ユニットであって、メディア再生タイムラインに従って連続的に配列される少なくとも２つの期間要素を前記ＭＰＤに与えるようにし、各期間要素が少なくとも１つの表現を含むと共に前記期間要素のうちの少なくとも１つが少なくとも２つの表現を含むように少なくとも１つの表現を各期間要素に与えるようにし、各表現には少なくとも１つのメディアセグメントＵＲＩを順に並べたシーケンスが与えられ、各メディアセグメントＵＲＩは前記ＨＴＴＰメディアストリームの少なくとも１つのメディアセグメントを参照する、生成ユニットと、
    前記ＭＰＤにクライアントがアクセスできるようにするように構成された提供ユニットであって、これにより、前記クライアントが、前記ＭＰＤを取得し、前記ＭＰＤの内容に基づいて少なくとも１つの期間要素についての表現を選択し、選択した各表現について参照される各々のメディアセグメントを取得することができるようにする、提供ユニットと、
    を備えることを特徴とするサーバ。
22. 前記生成ユニットは、テンプレート形式、プレイリスト形式、又はその組み合わせで記述される少なくとも１つの表現を前記ＭＰＤに与えるように構成される
    ことを特徴とする請求項２１に記載のサーバ。
23. 前記生成ユニットは、各メディアセグメントＵＲＩについて、参照される１以上のメディアセグメントの各々の持続時間の指示情報を前記ＭＰＤに与えるように構成される
    ことを特徴とする請求項２１又は２２に記載のサーバ。
24. 前記生成ユニットは、同一の期間要素に関連する各表現に対して表現属性及び各表現属性の設定を与え、前記クライアントが前記表現属性に基づいて前記表現を選択できるようにするように構成される
    ことを特徴とする請求項２１、２２、又は２３に記載のサーバ。
25. 前記生成ユニットは、少なくとも２つの異なるカテゴリの表現属性を提供し、前記表現属性を階層的な態様で提供し、各表現属性が期間レベルで提供された場合には、当該表現属性は各期間要素の全ての表現に対して有効となるようにし、各表現属性が表現レベルで提供された場合には、当該表現属性は各期間要素の各表現に対して有効となるようにする、ように構成される
    ことを特徴とする請求項２４に記載のサーバ。
26. 前記生成ユニットは、前記ＭＰＤに対して少なくとも１つの表現を追加すること、前記ＭＰＤから少なくとも１つの表現を削除すること、又は、前記ＭＰＤの少なくとも１つの表現を変更することにより、前記ＭＰＤを更新するように構成される
    ことを特徴とする請求項２１乃至２５のいずれか１項に記載のサーバ。
27. 前記生成ユニットは、前記ＭＰＤに対してポーリング間隔の指示情報を与え、これにより、前記ＭＰＤを取得したクライアントが前記ポーリング間隔の指示情報により決定される間隔でＭＰＤの更新をポーリングすることができるようにするように構成される
    ことを特徴とする請求項２６に記載のサーバ。
28. ＭＰＤの更新が実行された際に認識して当該更新されたＭＰＤを前記クライアントへプッシュするように構成された通信ユニットを更に備える
    ことを特徴とする請求項２６に記載のサーバ。
29. 前記生成ユニットは、前記ＭＰＤに対してサーバのタイムライン又はウォールクロック時間のうちの任意のものに対する前記ＨＴＴＰメディアストリームの前記メディア再生タイムラインのマッピングに関する記述を与えるように構成される
    ことを特徴とする請求項２１乃至２８のいずれか１項に記載のサーバ。
30. 前記生成ユニットは、同一の期間要素に関する異なる表現のメディアセグメントを用意し、当該異なる表現のメディアセグメント同士が前記期間要素の開始の時点で時間的に揃っているようにするように構成される
    ことを特徴とする請求項２９に記載のサーバ。
31. 通信ネットワークの少なくとも１つのネットワークノードからＨＴＴＰメディアストリームを取得可能な、前記通信ネットワークのクライアントであって、
    メディア再生タイムラインに従って連続的に配列される少なくとも２つの期間要素を含むＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）を前記少なくとも１つのネットワークノードから取得するように構成された要求ユニットであって、各期間要素は少なくとも１つの表現を含むと共に前記期間要素のうちの少なくとも１つは少なくとも２つの表現を含み、各表現は少なくとも１つのメディアセグメントＵＲＩを順に並べたシーケンスを含み、各メディアセグメントＵＲＩは前記ＨＴＴＰメディアストリームの少なくとも１つのメディアセグメントを参照し、各表現に関連する参照されるメディアセグメントを取得するように構成された、要求ユニットと、
    前記ＭＰＤの内容に基づいて各表現を選択するように構成された選択ユニットと、
    を備えることを特徴とするクライアント。
32. 前記選択ユニットは、前記表現の少なくとも１つの表現属性に基づいて各表現を選択し、これにより、前記要求ユニットが前記選択された表現によって参照される１以上のメディアセグメントを取得できるようにするように構成される
    ことを特徴とする請求項３１に記載のクライアント。
33. 前記少なくとも１つのネットワークノードから前記クライアントへ前記ＨＴＴＰメディアストリームを送信するのに利用可能なビットレートを推定し、これにより、前記選択ユニットが、前記少なくとも１つの表現属性のうちの少なくとも１つを考慮することにより前記推定に基づいて少なくとも１つの期間要素の表現を選択できるようにするように構成された推定ユニットを更に備え、
    ビットレートは表現属性に依存する
    ことを特徴とする請求項３２に記載のクライアント。
34. 前記選択ユニットは、少なくとも１つのクライアント能力を更に考慮することにより各表現を選択するように更に構成される
    ことを特徴とする請求項３２又は３３に記載のクライアント。
35. 前記要求ユニットは、ＭＰＤの更新がないか前記ネットワークノードをポーリングし、前記ＭＰＤが更新されたと判定された場合に、当該更新されたＭＰＤを前記ネットワークノードから取得するように更に構成される
    ことを特徴とする請求項３１乃至３４のいずれか１項に記載のクライアント。
36. 前記要求ユニットは、以前に取得したＭＰＤから取得されるポーリング間隔を適用することにより、ＭＰＤの更新がないか前記ネットワークノードをポーリングするように構成される
    ことを特徴とする請求項３５に記載のクライアント。
37. 前記要求ユニットは、更新されたＭＰＤを含むプッシュ通知を前記少なくとも１つのネットワークノードから受信するように構成される
    ことを特徴とする請求項３１乃至３４のいずれか１項に記載のクライアント。

Images