JP6501933B2 - Ｘｍｌドキュメントの生成装置、生成方法、情報処理装置、情報処理方法、及びプログラム - Google Patents

Description

本発明は、メディアデータ、を送信するための方法およびデバイスに関する。

メディア表現は、通常、オーディオ、ビデオまたはテキストのような、複数のメディアコンテンツからなる。これらは、クライアントデバイスにより合わせて再生されるために、サーバからクライアントに送られ得る。これらのメディアコンテンツは、クライアントによりサーバからダウンロードされる。

この文脈では、ＤＡＳＨ（“Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ”）と呼ばれる新規の標準規格が近年現れてきている（“ＩＳＯ／ＩＥＣ ２３００９−１，Ｄｙｎａｍｉｃ ａｄａｐｔｉｖｅ ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ），Ｐａｒｔ１：Ｍｅｄｉａ ｐｒｅｓｅｎｔａｔｉｏｎ ｄｅｓｃｒｉｐｔｉｏｎ ａｎｄ ｓｅｇｍｅｎｔ ｆｏｒｍａｔｓ”を参照）。この標準規格により、メディア表現のコンテンツのコンパクトな記述と、ＨＴＴＰアドレスとの間に関係を作ることが可能である。通常、この関係は、マニフェストファイルまたは記述ファイルと呼ばれるファイルで記述される。ＤＡＳＨの文脈では、このマニフェストファイルは、ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）ファイルとも呼ばれるファイルである。

ＭＰＤファイルがクライアントデバイスに送られたときに、各メディアコンテンツの記述はクライアントにより容易に知られ得る。マニフェストファイルを読み取ることにより、クライアントは、メディア表現で提示されるこの種のメディアコンテンツを認識し、および、関係付けられたメディアコンテンツをダウンロードするためのＨＴＴＰアドレスを認識する。そのため、どのメディアコンテンツを（ＨＴＴＰリクエストを通じて）ダウンロードするか、および、どのメディアコンテンツを再生する（メディアデータセグメントの受信後にデコーディングおよび再生する）かを決定できる。

この関係に加えて、ＤＡＳＨ標準規格は、各メディアコンテンツを小さな期間に分けることを提案する。時間的な分解がＭＰＤファイルに加えられる。したがって、これは、ＨＴＴＰアドレス（またはＵＲＬ）と、小さな期間にわたる各メディアコンテンツのコンパクトな記述との間の関係を記述する。

本発明は、（ＤＡＳＨ ＭＰＤを参照することにより）マニフェストファイル中のビデオ記述に焦点を当てる。以下で説明するように、メディア表現の他のエレメント（例えば、オーディオ、テキスト、．．．）を直接考慮に入れない場合でさえ、これらは、さらにグローバルなメディア記述中に容易に組み込まれ得る。

ビデオの空間解像度はますます重要になってきている。この観点では、４Ｋ２Ｋのビデオが市場に現れ始めている。しかし、モバイルアプリケーションは、このような解像度を高品質で表示できない。

解決策として提案されるのは、ビデオをタイルに分けることである。モバイルアプリケーションのユーザが、ビデオのサブパートを表示する、または、ビデオのサブパートに焦点を当てることを望む場合に、サブパートに対応するタイルのみが送信される。このプロセスにより、ビデオの一部を高品質に保つことが可能になる。

ＤＡＳＨの文脈では、メディア表現を形成するために、既知の標準規格である“ＩＳＯ ＢＭＦＦ”（“Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ”）を使用して、メディアコンテンツをメディアデータセグメント中にカプセル化する。

伝統的に、各トラックは、トラックがビデオのサブパートに対応する場合でさえ、ＤＡＳＨを使用することにより、独立したメディアコンテンツとしてマニフェストで記述される。マニフェストでは、各トラックが同じビデオのサブパートであることをシグナリングできない。当然、現在のＭＰＤの規定では、タイル化されたビデオの記述は可能ではない。実際には、ユーザは、ＭＰＤで記述された各ビデオが、タイル化されたビデオのサブパートであることを知るために、（マニフェストに加えて）第１の初期設定セグメントをダウンロードする必要がある。その後、ユーザは、タイルの位置とビデオコンテンツとの間の関係を導き出すために、各ビデオコンテンツの各第１のメディアデータセグメントの始点を、最低限、ダウンロードする必要がある。この初期設定情報のダウンロードは、遅延ならびに追加のおよび不要なＨＴＴＰリクエストに対して行われる。

ＤＡＳＨの使用と互換性のない別の先行技術において、“Ｉｎ ｐａｃｋｅｔ ｖｉｄｅｏ ２０１０，Ａｎ Ｉｎｔｅｒａｃｔｉｖｅ Ｒｅｇｉｏｎ Ｏｆ Ｉｎｔｅｒｅｓｔ Ｖｉｄｅｏ Ｓｔｒｅａｍｉｎｇ Ｓｙｓｔｅｍ ｆｏｒ Ｏｎｌｉｎｅ Ｌｅｃｔｕｒｅ Ｖｉｅｗｉｎｇ”，Ａ．Ｍａｖｌａｎｋａｒ，Ｐ．Ａｇｒａｗａｌ，Ｄ．Ｐａｎｇ，Ｄ．Ｈａｌａｗａ，Ｎ．Ｃｈｅｕｎｇ，Ｂ．Ｇｉｒｏｄ”という記事が、スケーリング可能なビデオのためにタイルを記述する特有のマニフェスト（“プロプライエタリマニフェスト”）を提案している。特有のマニフェストは、各タイルに対する識別子および１つの位置情報を提供する。ベースレイヤに関係付けられるＵＲＬおよびプロプライエタリマニフェストにより提供されるタイル情報から、特定のタイルにアクセスするためのＨＴＴＰクエリが構築され、このクエリはタイルインデックスに関係付けられる。このタイプのＨＴＴＰクエリは、ＨＴＴＰクエリから、バイト範囲を、および、結果的にそのリクエストを満たすためにクライアントデバイスに送られることになるタイルを読み出すために、サーバ側での処理を要求する。これは、非常に特有のサーバによってのみ行うことができる。

本発明は、先の懸案のうちの１つ以上に対処するために考案された。

ＨＴＴＰを通したメディアストリーミングの一般原則の例についてのブロック図を示す。 特に、フレームがタイルに分割されたときの、本発明の実施形態にしたがった、ＨＴＴＰを通したメディアストリーミングをさらに詳細に説明したフローチャートである。 本発明の実施形態にしたがった、タイルに分割されるフレームと、関心領域とを概略的に表す。 本発明の実施形態にしたがった、タイルに分割される、空間的にスケーリング可能なビデオからのフレームと、関心領域とを概略的に表す。 メディア表現およびマニフェストファイルを生成させる一般原則の例を示すブロック図である。 ＤＡＳＨを使用してストリーミングされるメディア表現のクラシカルな編成を概略的に表す。 サブトラックが含まれない記述ファイル／マニフェストを示す。 本発明にしたがった、最初のビデオをビデオサブトラックに前処理するための実施形態を概略的に記述する。 タイル化されたビデオフレームのスライスおよびスライスセグメントへの分割を概略的に記述する。 本発明にしたがった、ビデオサブトラックをファイルフォーマットにエンコードおよびカプセル化するための実施形態を概略的に記述する。 本発明にしたがった、各ビデオサブトラックの位置を運ぶのに使用できるファイルフォーマットのボックスの実施形態を概略的に記述する。 本発明にしたがった、マニフェスト／記述ファイルのシンタックスを記述する。 本発明にしたがった、マニフェスト／記述ファイルのシンタックスを記述する。 本発明にしたがった、マニフェスト／記述ファイルのシンタックスを記述する。 本発明にしたがった、ビデオサブトラックによるメディア表現のためのマニフェスト／記述ファイルの完全な例を示す。 本発明の１以上の実施形態の実現のためのコンピューティングデバイスの概略的なブロック図である。 本発明にしたがった、ビデオサブトラックによるメディア表現のためのマニフェスト／記述ファイルの別の例を示す。 本発明にしたがった、ビデオサブトラックによるメディア表現のためのマニフェスト／記述ファイルで使用される別のシンタックスを示す。

図１ａは、特にＤＡＳＨのような、ＨＴＴＰを通したメディアストリーミングの一般原則を記述する。ＨＴＴＰを通したメディアストリーミングに関する新規のプロトコルおよび標準規格の大半は、この原則に基づいている。

メディアサーバ１００は、異なるメディア表現（メディアプレゼンテーション）を含む。メディア表現１０１の例を示す。ここで、メディア表現１０１は、オーディオデータおよびビデオデータを含む。ここでは、ビデオは統合されている、つまり、タイルに分割されていないと考える。この例では、オーディオおよびビデオは同じファイルでインターリーブされると考える。このメディア表現が構築される方法を以下の図２に説明する。このメディア表現は、独立していて連続的な小さな時間的なセグメント１０２、１０２ａおよび１０３（例えば、ｍｐ４セグメント）に時間的に分けられ、つまり、メディア表現のインターリーブされたオーディオ／ビデオのデータは３つの連続的な時間的な期間に分けられる。これらの時間的なセグメントに独立してアドレスを割り当て、ダウンロードすることができる。メディアコンテンツのダウンロードアドレスは、ＨＴＴＰアドレスである。（１つのＨＴＴＰアドレスは、オーディオ／ビデオのメディアコンテンツのそれぞれの時間的なセグメントに関係付けられる）。これらは、こうした時間的なセグメントのうちのそれぞれの１つに対して、サーバ１００により設定される。

マニフェストファイル１０４（または記述ファイル（ディスクリプションファイル））は、ＸＭＬ文書である。ＸＭＬ文書は、時間的なメディアセグメントのコンテンツ、例えば、メディアのタイプ（オーディオ、ビデオ、オーディオ−ビデオ、テキスト．．．）、コーディングフォーマット、セグメントの持続時間を記述する。さらに、ＸＭＬ文書は、記述される各メディアコンテンツセグメントにＵＲＬを関係付ける。

マニフェストファイル１０４は、クライアントまたはユーザに関連するクライアントデバイス１１０に送られる。受信したマニフェストファイル１０５を読み取ることにより、クライアントは、異なるメディアコンテンツの時間的なセグメントと、時間的なセグメントを指定するＨＴＴＰアドレスとの関係を知ることができる。さらに、マニフェストファイル１０５は、メディア表現のコンテンツ（この例では、インターリーブされたオーディオ／ビデオ）についての情報を与える。例えば、情報は、解像度および／またはビットレートを含んでもよい。

そのため、クライアントデバイス１１０は、クライアントデバイス１１０が望む時間的なセグメントをダウンロードするためのＨＴＴＰリクエスト１０６を発することができ、これらの時間的なセグメントは受信したマニフェストファイル１０５に記述される。

応答として、サーバ１００は、要求された時間的なセグメントを送る１０７。これらの時間的なセグメントは、クライアントデバイス１１０により表示１０９のためにデコーディングされ得る１０８。

図１ｂは、本発明にしたがった、ＨＴＴＰを通した（特にＤＡＳＨでの）メディアストリーミングをさらに正確に示す。ここでは、ストリーミングされたビデオデータは、独立したｎ個のビデオサブトラックを作成するために、ビデオトラックの各フレームがｎ個の空間タイルに分割されるようなビデオトラックを含み、ｎは整数である。

最初に、クライアントデバイスは、サーバから記述ファイル（またはＤＡＳＨでのＭＰＤ）を受信する、ステップ１００８。この記述ファイルは、ｎ個のビデオサブトラックの空間編成についてのデータと、ビデオサブトラックをそれぞれ指定する少なくともｎ個のＵＲＬとを含む。

クライアントは、クライアントが表示させたいと望む関心領域（ＲＯＩ）を選ぶ。例えば、クライアントは、図１ｃに示すように、特定のゾーン上でズームインすることを望む。

図１ｃは、ここでは８個のタイルＴ１、Ｔ２、．．．、Ｔ８に分割されるフレーム１１００を示す。このフレームでは、クライアントは、画像の右下部にある部分１１１０上でズームすることを決定した。図１ｃに示すように、この選ばれた部分１１１０または関心領域は、２つのタイルＴ６およびＴ８に含まれる。

図１ｄは、ベースレイヤ１１２１と、ここでは８個のタイルＴ１、Ｔ２、．．．、Ｔ８に分割される空間エンハンスメントレイヤ１１２２とを持つスケーリング可能なビデオとしてエンコードされるフレーム１１２０を示す。ベースレイヤフレーム１１２１はタイル化されず、そのため、エンハンスメントレイヤ１２２２中の各タイルは、ベースレイヤ全体に依存する。このフレームでは、ユーザが画像１１２２の右下部にある部分１１２３上でズームすることを決めたときに、ユーザは、２つの選択されたタイルだけでなくベースレイヤも必要とする。

図１ｄに示すように、選ばれた部分１１２３または関心領域は、２つのタイルＴ６およびＴ８ならびにベースレイヤ１１２１に含まれる。図１ｄの右部は、タイル化されたベースレイヤ１１３１と、タイルベースである空間依存によるタイル化された空間エンハンスメントレイヤ１１３２としてエンコードされるフレーム１１３０を表す：エンハンスメントレイヤ１１３２における１つのタイルは、ベースレイヤ１１３１の同じポジションにあるタイルにのみ依存する。この構成では、ユーザがＲＯＩ １１３３を選択したときに、ユーザは、２つの選択されたタイル１１３３ならびにベースレイヤ１１３１中の２つの参照タイルＴ０６およびＴ０８を必要とする。

図１ｂでは、図１ｃまたは図１ｄに示すように、クライアントは、スケーラビリティおよびタイル化の観点からビデオ構成に依存して、ＲＯＩを選ぶ、ステップ１０１０。

クライアントにより選ばれたＲＯＩによりカバーされるタイルに対応するＵＲＬ（図１ｃの例ではＴ６およびＴ８のＵＲＬ）は、クライアントデバイスにより選択される、ステップ１０２０。

選択はまた、後にさらに詳細に開発されるいくつかの互換性基準にも基づく。

要求されたメッセージは、クライアントデバイスからサーバに送られる、ステップ１０３０。各リクエストメッセージは、クライアントにより選ばれたＲＯＩによりカバーされる１つのタイルのＵＲＬを含む。以下にさらに詳細に説明するように、タイルに対応するビデオサブトラックは、時間的なセグメント中に編成される。そのため、１つのＵＲＬは、セグメント全体にわたって、タイルに対応するビデオサブトラックを指定する。

リクエストメッセージに応答して、サーバは、ビデオデータ（つまり、以下で説明するようなセグメント）をクライアントデバイスに送る、ステップ１０４０。ビデオサブトラック／タイルが要求された場合に、リクエストメッセージ中のＵＲＬにより指定されたセグメントがクライアントデバイスに送られる。

図２は、メディア表現およびマニフェストファイルの双方の生成のための主なステップを示す。

並行ステップ２００および２０１では、オーディオおよびビデオのデータが取得される。その後、オーディオデータは圧縮される、ステップ２０２。例えば、ＭＰ３標準規格がこのステップに対して使用され得る。並行して、ビデオデータが圧縮される、ステップ２０３。ＭＰＥＧ４、ＡＶＣ、ＨＥＶＣまたはＳＶＣのような、ビデオ圧縮アルゴリズムが使用され得る。いったん、圧縮ステージが行われると、オーディオエレメンタリストリーム２０４およびビデオエレメンタリストリーム２０５が利用可能になる。

エレメンタリストリーム２０４、２０５は、グローバルメディア表現としてカプセル化される、ステップ２０６。

グローバルメディア表現２０７は、カプセル化の結果生じる。例えば、ＩＳＯ ＢＭＦＦ標準規格（または、ＩＳＯ ＢＭＦＦ標準規格のＡＶＣ、ＳＶＣ、ＨＥＶＣ．．．への拡張）は、エンコードされたオーディオおよびビデオのエレメンタリストリームのコンテンツをグローバルメディア表現として記述するために使用され得る。

カプセル化されたメディア表現２０７は、ＸＭＬマニフェストファイル２０９を生成するために使用される、ステップ２０８。

図３は、ＤＡＳＨマニフェストファイルの階層化コンテンツの例を示す。ＤＡＳＨマニフェストファイルの階層化コンテンツは、サーバにおいて利用可能なメディア表現のコンテンツおよびメディアデータとも呼ばれる各メディアコンポーネントとＨＴＴＰアドレスとの間の関係を記述する。

例えば、メディア表現は、Ｐｅｒｉｏｄと呼ばれる粗粒の期間に時間的に分けられてもよい（任意のコンテンツのスプライシング）。

ＭＰＤレベルでの“Ｐｅｒｉｏｄ”は、ある期間の間利用可能な（１つのＰｅｒｉｏｄのみが存在する場合にメディア表現の完全な持続時間となり得る）全メディアコンポーネントを記述する。この期間内、メディアコンテンツコンポーネントは、容易にストリーミング／ランダムアクセス／スイッチングすることを可能にする、先に言及した小さな期間に対応する複数のデータセグメントからなり得る。

ＸＭＬ ＭＰＤは、各期間に関連する全データを含む。この情報を受信することにより、クライアントは、各期間のコンテンツを認識する。例えば、メディア表現３００は、複数のエレメントに分割され、各エレメントはＰｅｒｉｏｄに対応する。例えば、第２のＰｅｒｉｏｄは１００秒および２９４秒に含まれる。

各メディア表現のＰｅｒｉｏｄは、対応する期間の間、利用可能なメディアコンテンツ成分を記述するデータを含む。メディア表現のＰｅｒｉｏｄ３０１のうちの１つを、さらに詳細に示す。

加えて、複数の“ａｄａｐｔａｔｉｏｎ ｓｅｔ（アダプテーションセット：適応セット）”エレメントが組み込まれる：ビデオ記述に対して１つ、オーディオ記述に対して１つ。各適応セットは、所定のトラックに関係付けられる。この例では、第１のグループ適応セットは、ビデオトラックに関係付けられ、第２の適応セットは、考えられる期間に対する前記ビデオトラックに対応するオーディオトラックに関係付けられる。

適応セット構造３０２は、サーバにおいて利用可能なエンコードされたビデオの、可能な異なった表現についての情報を含む。この例では、第１の表現は、５００ｋｂｉｔ／秒のビットレートでエンコードされた６４０ｘ４８０の空間解像度でエンコードされたビデオである。第２の表現は同じビデオであるが、２５０ｋｂｉｔ／秒でエンコードされている。このビデオのそれぞれは、クライアントがビデオに関連するＨＴＴＰアドレスを知っている場合に、ＨＴＴＰリクエストによりダウンロードできる。各表現のコンテンツとＨＴＴＰアドレスとの間の関係付けは、追加の一時サブレイヤを使用することにより行われる。

参照３０３により示すように、ビデオ表現３０２は（この例では１０秒の）時間的なセグメントに分けられる。

第１の表現３０２は、５００ｋｂｉｔｓ／秒の帯域幅、６４０ピクセルの幅および４８０ピクセルの高さを得る。“Ｓｅｇｍｅｎｔ Ｉｎｆｏ”のフィールド３０３により、さらなるパラメータが与えられる。

第２の表現は、２５０ｋｂｉｔｓ／秒の帯域幅、６４０ピクセルの幅および４８０ピクセルの高さを得る。この第２の表現は、例えば、第１の表現と比較して質の低下を表すことがある。クライアントは、ネットワークの利用可能な帯域幅に依存して、これらの表現間でスイッチすることができる。

各時間的なセグメント３０３は、ＨＴＴＰアドレスを通してアクセス可能なサーバにおいて記憶されているコンテンツである。加えて、初期設定セグメント（イニシャリゼーションセグメント）が利用可能である。この初期設定セグメントは、（ビデオがＩＳＯ ＢＭＦＦまたは拡張を使用することによりカプセル化されている場合に、）カプセル化されたビデオのＭＰ４コンテンツを記述するＭＰ４初期設定情報を含む。例えば、この初期設定セグメントは、ビデオに関連するデコーディングアルゴリズムをクライアントがインスタンス化することを助ける。初期設定セグメントのＨＴＴＰアドレスおよびメディアセグメントは、以下でさらに詳細に示すＭＰＤ（または記述）ファイル中に与えられる。

図４は、所定のメディア表現に対する既知のマニフェストファイルの例を与える。このマニフェストは、（ＭＰＤとも呼ばれる）ＤＡＳＨマニフェストである。記載を明確にするために、ＭＰＤの主な特性をここで記述する。

このＭＰＤでは、２つのメディアが記述される。第１のメディアは、英語のオーディオストリームであり、第２のメディアはビデオストリームである。英語のオーディオストリームは、‘ａｄａｐｔａｔｉｏｎ ｓｅｔ’バナーを通して導入される。２つの表現（リプリゼンテーション）は、このオーディオストリームに関連する：
・第１のメディア（“１”に等しいＩＤを持つ）は、６４０００ビット／秒のビットレートを持つＭＰ４カプセル化エレメンタリストリームである。このエレメンタリストリームをハンドルするためのコーデックは、（いったん、ｍｐ４パーサにより解析されると）属性‘ｍｐ４ａ．０ｘ４０’により標準規格で規定される。これは、相対アドレス：７６５７４１２３４８．ｍｐ４においてリクエストによりアクセス可能である。

・第２のメディア（“２”に等しいＩＤを持つ）は、３２０００ビット／秒のビットレートを持つＭＰ４カプセル化エレメンタリストリームである。

ビデオに関連する適応セット（アダプテーションセット）は、６個の表現を含み、それらのＲｅｐｒｅｓｅｎｔａｔｉｏｎ＿ｉｄは、“６”、“７”、“８”、“９”、“Ａ”および“Ｂ”である。これらの表現は、異なる空間解像度（３２０ｘ２４０、６４０ｘ４８０、１２８０ｘ７２０）および異なるビットレート（２５６０００〜２０４８０００ビット／秒）でのビデオを含む。これらの表現のそれぞれについて、異なるＵＲＬが関係付けられる。そのため、クライアントは、例えば、推定帯域幅またはスクリーンの解像度のような、異なる基準にしたがって、同じビデオのこれらの表現の間から選ぶことができる。

ここで、以下の図面は、本発明の実施形態に特に焦点を当てる。

以前に記述したように、マニフェストファイルの適応セットは、（表現バナーを通して）異なる空間解像度および異なるビットレートでエンコードされた同じビデオに関する情報を伝える。

本発明により、表現が、ビデオのサブパートを記述することが可能になる。実際、先行技術で知られているＤＡＳＨ標準規格では、同じビデオのサブパートを記述するための属性は規定されない。言い換えると、ＤＡＳＨ標準規格を使用することにより、ビデオの異なるサブパートに関する絶対的または相対的ローカライゼ―ション情報を直接送ることはできない。

（以下の図面を通した）本実施形態では、この可能性をどのように追加できるかを示す。

図５は、ビデオのタイル化の概念と、この概念がどのようにビデオに適用されるかを記述する。ビデオ５００は、３つのフレームを通してシンボル化される。各フレーム５０１は、Ｔｎと呼ばれる８個の長方形に分割される（ｎは、１〜８の間で可変である）。当然、タイルの数および形は異なるものとすることができる。例えば、ビデオのタイルは異なる次元を有し得る。

しかし、この例では、タイル化は、ビデオフレーム５０１のインデックスが何であれ、同じものとすることができると考える。また、タイルは同じ水平サイズおよび垂直サイズを有すると考える。

このタイル化の結果５０２は、図５の下に与えられる。８個の独立したビデオサブトラックが得られる。これらのビデオサブトラックは、グローバルなビデオ全体の区分である。好ましい実施形態にしたがって、これらのビデオサブトラックは、独立したビデオと考えられ、独立して圧縮される。

本発明は、１つのベースレイヤおよび少なくとも１つのエンハンスメントレイヤを持つスケーリング可能なビデオに容易に適用され得ることが認識される。第１の実施形態では、エンハンスメントレイヤのみがタイルに分割される。結果的に、タイルが要求されるときに、対応するベースレイヤもまたクライアントにより要求され、結果としてベースレイヤはサーバからクライアントに送られる。

別の実施形態では、ベースレイヤおよびエンハンスメントレイヤは双方ともタイルに分割される。この場合、各レイヤ中の対応するタイルのＵＲＬは、サーバに送ることができ、それに応答して、サーバは、クライアントデバイスに、各レイヤ中の対応するタイルを送る。

図５ａは、ＨＥＶＣフォーマットでの特有のタイルおよびスライスの編成を記述する。ＨＥＶＣ標準規格は、ピクチャの、異なる空間サブ分割を規定する：つまり、タイル、スライスおよびスライスセグメントである。これらの異なる区分は、異なる目的のために導入される：つまり、スライスはストリーミングの問題に関連する一方で、タイルおよびスライスセグメントは並行処理を行うことができるように規定される。

タイルは、整数のコーディングツリーユニット（ＣＴＵ）５５３を含むピクチャの長方形領域を規定する。これは当初当業者によりＬＣＵ（最大コーディングユニット）と呼ばれた。図５ａに示されているように、タイル化は、行の境界５５１および列の境界５５２によってのみ規定される。これにより、ポジションおよびサイズの観点から、タイルは、関心領域の記述にふさわしい候補となる。しかし、シンタックスおよびシンタックスのネットワーク抽象化レイヤ（ＮＡＬ）ユニットへのカプセル化の観点からのＨＥＶＣビットストリーム編成は、（アドバンストビデオコーディングにおけるように）むしろ、スライスに基づく。

ＨＥＶＣにおけるスライスは、スライスセグメントの組であり、少なくとも第１のスライスセグメントは独立したスライスセグメントであり、その他は、もしあれば、依存性のスライスセグメントである。スライスセグメントは、整数の連続した（ラスタスキャン順序での）ＣＴＵを含む。スライスセグメントは必ずしも長方形の形を有していない（したがって、ＲＯＩ表現に関してタイルよりも適切でない）。スライスセグメントは、ＨＥＶＣビットストリーム中で２つのパートとしてエンコードされる：すなわち、ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒと、それに続くｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｄａｔａである。

独立したスライスセグメントおよび依存性のスライスセグメントは、これらのヘッダにより異なる：独立したスライスセグメントのヘッダからの情報を再使用するため、依存性のスライスセグメントは、より短いヘッダを有する。独立したスライスセグメントおよび依存性のスライスセグメントの双方とも、ビットストリーム中のエントリポイントのリストを含む：すなわちタイルへのエントリまたはエントロピーデコーディング同期化ポイントへのエントリのいずれかである。エントリポイントは、ＨＥＶＣビットストリーム中のポジションを規定する。エントリポイントは、特定のコードを使用することにより、または、表中で参照されることにより、識別可能である。エントリポイントは、特定のシンタックスエレメントに対応する：例えば、ＮＡＬユニットまたはスライスセグメントの始点。

スライス、スライスセグメントおよびタイルの関係をより良く理解するために、図５ａの５６０および５７０において異なる構成を示す。これらの構成は、第１の構成５５０とは異なる。構成５５０は、１つのタイルが１つのスライス（１つの独立したスライスセグメントのみを含む）を有するケースに対応する。第２の構成５６０では、ピクチャは、太い破線で分離された２つの垂直なタイル５６１、５６２および１つのスライス（５つのスライスセグメントを持つ）に区分される。

図の右部では、ピクチャ５７０は、太い破線により示される２つのタイル５７１、５７２に分けられる。左のタイル５７１は、太い直線により線引きされた２つのスライスを有し（それぞれ２つのスライスセグメントを持ち、１つは依存性のスライスセグメント、１つは独立したスライスセグメント）、右のタイル５７２は、１つのスライス（２つのスライスセグメントを持ち、１つは依存性のスライスセグメント、１つは独立したスライスセグメント）を有する。ＨＥＶＣ標準規格は、以下のように要約され得る、タイルおよびスライスセグメント間の編成規則を規定する（１つまたは双方の条件が満たされなければならない）：
−スライスセグメント中の全ＣＴＵは同じタイルに属する。

−タイル中の全ＣＴＵは同じスライスセグメントに属する。

関心領域のサポートと伝送とを一致させるために、好ましくは、１つのタイルが、１つの独立したセグメントを持つ１つのスライスを含む、図５ａの構成５５０を考える。しかし、カプセル化の解決策は、他の構成５６０または５７０においても機能する。

図５ａに示すように、ピクチャパラメータセット５９０において、タイルはＨＥＶＣビットストリーム中でシグナリングされる。規則的なタイル化が使用される場合に、パラメータである“ｕｎｉｆｏｒｍ＿ｓｐａｃｉｎｇ＿ｆｌａｇ”は、“１”の値を取り、タイルの列５５１および行５５２の数のみが必要とされる。そうでなければ、パラメータは“０”に設定され、各列および線のポジションは、コーディングツリーユニットの数にコーディングされる（典型的には、６４ｘ６４ピクセルのサイズ）。

図６は、カプセル化段階を示す。ストリーミングされる前に、各タイルに対応するデータは、標準規格のフォーマットでカプセル化されるために処理されなければならない。

エンコーディングステップ６０１の入力となるための、８個のタイルに対応するデータが取得される、ステップ６００。各タイルに対応するデータは、独立して圧縮され、エンコードされる、ステップ６０１。任意のビデオ圧縮アルゴリズムを使用できる。例えば、Ｈ２６４、ＨＥＶＣ、ＭＰＥＧ−２を使用できる。いったん、タイルに対応するデータがエンコードされると、ステップ６０１、結果のエレメンタリストリームはファイルフォーマットでカプセル化されなければならない。（標準規格であるＤＡＳＨにおいて提案されている通り）ＩＳＯ ＢＭＦＦ（または、このメディアファイルの拡張）を使用できる。

ビデオの８個のサブパートを含む以下のこれらの８個のビデオトラックは、“ビデオサブトラック”と呼ばれる。８個のビデオサブトラックに対応するデータはエンコードされているため、８個のビデオサブトラックはＩＳＯ ＢＭＦＦファイル中で規定される。８個のビデオサブトラック全体を、同じメディア表現の異なるトラックと見なすことができる。当然、オーディオまたはテキストのトラックのような、追加のトラックを使用できる。しかし、記載を明確にするために、この図では他の種類のメディアの挿入を記述しない。

最初に、カプセル化のプロセス６０２の間に、メディア表現６０２ａが生成される。１つの位置情報が初期設定セグメント６０３において設定される。この初期設定セグメントは、対応するビデオサブトラックに関係付けられた初期設定データを含む。これらのデータの中で、好ましくは各ビデオサブトラックの位置が特定される（次の図でさらに詳細に記述する通り）。

初期設定セグメント６０３に加えて、カプセル化プロセス６０２は、小さな期間に対応する１組のセグメントファイル６０４、６０５（ＭＰＤが生成されるときに、ＵＲＬを通してアクセスできるメディアセグメント）を生成する。この図の例では、２つの小さな期間が規定される。これは、各ビデオサブトラックは時間的に２つの小さな期間に分けられることを意味する。セグメントファイルの組が異なるのは、所定の期間に対する各ビデオサブトラックに起因する。このようなプロセスを使用することにより、クライアントは、任意の提案された期間に対し提案されたビデオサブトラックのうちのいずれかを要求できる。

第１の組のメディアセグメント６０４は、第１の期間に対する異なるトラック（サブトラック）に対応する。第２の組のメディアセグメント６０５は、同じビデオトラックに対する第２のおよびそれに続く期間に関連する。当然、本発明は２つの期間に限定されない。期間の数は限定されない。ボックス６０４および６０５が既存のコンテナではないことを考慮して、これらは点線で表現されていることを銘記されたい。

以下に記述するように、ＵＲＬは、選択されたＲＯＩによりカバーされるタイルをクライアントが要求できるように、各セグメントファイルに関係付けられる。

図３では、２つの時間的な分解を記述したことを銘記されたい：すなわち、
・ブロック３００では、任意のコンテンツのスプライシング、および、
・ブロック３０２／３０３では、小さな期間の生成。

図６では、任意のコンテンツのスプライシングは、１つのグローバルな期間のみを生成させ、各ビデオサブトラックに対応するデータは、２つの小さな期間に対応する２つのメディアセグメントにカプセル化される。

図７は、図６中で参照された初期設定セグメント６０３が、各ビデオサブトラックの位置を伝えるためにどのように構築され得るかを示す。ビデオサブトラックは、ファイルフォーマットのシンタックスでは、ビデオトラックであることを思い出されたい。初期設定セグメントはＩＳＯファイル７００である。

ＩＳＯ ＢＭＦＦ標準規格に規定されるように、このファイルは複数のボックスを含む。記載を明確にするために、既知のボックスは記述されない。この例では８個のビデオサブトラック（８個のビデオトラックを意味する）が規定されるため、カプセル化されたメディア表現の‘ｍｏｏｖ’ボックスは、８個の“ｔｒａｋ”ボックス７０１を含む。

参照番号７０２は、この“ｔｒａｋ”ボックスの例である。これは、第１のビデオサブトラックと関係付けられる。この‘ｔｒａｋ’ボックスはまた複数のボックスを含む。第１のボックス“ｔｋｈｄ”７０３は、ビデオサブトラックの位置を伝えるために使用される。このボックスは複数の属性を含む。本発明で特に使用される属性は行列７０４である。この行列は、ビデオサブトラックの幅および高さと、右のポジションに対応するトラックを表示することを可能にする変形行列とを含む。

図７で与えられるこの行列のパラメータは単に例である。これらのパラメータは、異なるビデオサブトラックの形にしたがって調整されなければならない：この行列は、ビデオサブトラックを同時に表示したものが、図５中で参照される５００最初のビデオのエリアをカバーするように、実現されている。

図８は、記述ファイル（または、ＤＡＳＨ標準規格ではＭＰＤ）を示す。ＤＡＳＨ標準規格では、マニフェストのシンタックス（ＭＰＤシンタックス）は、タイルの概念を考慮することを可能にしない。

図８は、異なるビデオサブトラックの存在および位置についてクライアントに知らせるために、マニフェスト／記述ファイル（ＤＡＳＨ ＭＰＤ）に含まれることがあるエレメントを示す。図８では、ＭＰＤの部分図を与える。

タイルを、ＭＰＤ中のタイル表現に結びつけるために、タイル化されたビデオフレーム８００の例を、ＭＰＤの左部において表す。この例では、タイル化されたビデオフレームは、４つのタイル１：１、１：２、２：１および２：２を含み、これらの幅および高さは、タイル化されたビデオフレーム８００の左側および上側で示される。

部分図８０１は、ビデオサブトラックについての情報を含む適応セットを記述する。記載を明確にするために、この図では、１つのビデオサブトラックに関連するデータのみが表示される。そのため、他のサブトラックは記述されない。しかし、他のサブトラックの記述は類似している（同じシンタックスだが、他のＵＲＬとともに使用される）。

適応セット（“ＡｄａｐｔａｔｉｏｎＳｅｔ”）８０１は、最初のビデオ全体のタイルである１つのビデオサブトラックを記述するために使用される。この適応セットは、１つのビデオサブトラックの１つの表現を含み、この表現は、解像度で規定されるだけでなく、例えばフレームレートまたは帯域幅のような基準により規定される。これらの基準により、クライアントデバイスが、ビデオサブトラックの複数の表現を共に、または、連続的に、選択すること、しないことが可能になる。当然、本実施形態では、第１の解像度の値またはフレームレートを持つビデオサブトラックは、第２の解像度の値またはフレームレートを有する別のサブトラックとともに選択できない。

適応セット８０１では、この適応セットがメディア表現中のビデオサブトラックを表すことをシグナリングするために、（先行技術と比較して）追加のエレメントが提案される。この追加のエレメントは、ビデオサブトラックに対応するタイルの存在および位置の双方をシグナリングする新規のスキーム８０２である。

特に、本発明にしたがって、ＤＡＳＨ標準規格の‘Ｒｏｌｅ’記述子に対する新規のスキームが提案される。“ｓｃｈｅｍｅｌｄＵｒｉ”属性を通して、この“Ｒｏｌｅ”記述子の新規のスキームが規定される。“ｔｉｌｉｎｇ”と呼ばれる新規のタイプは、“ｓｃｈｅｍｅｌｄＵｒｉ”属性を通して規定される。加えて、新規のタイプのｓｃｈｅｍｅｌｄＵｒｉは、追加の属性により完成され、これは、既存のタイルのうちどのタイルを表すかを示すために使用される。

言い換えると、Ｎ個のタイルが利用可能である場合に、Ｒｏｌｅ記述子の“ｓｃｈｅｍｅｌｄＵｒｉ”属性は、例えば、“ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｔｉｌｉｎｇ：２０１３”に等しい（ＤＡＳＨの文脈で一意的な任意の値が提供される）。その後、Ｒｏｌｅ記述子は、１つにまとめられるタイルおよびこれらのタイルのそれぞれの位置を、Ｒｏｌｅ記述子の属性を通じてシグナリングする。ｒｏｌｅ記述子におけるこの新規のスキームの好ましいシンタックスは以下のものである：＜Ｒｏｌｅ ｓｃｈｅｍｅＩｄＵｒｉ＝“ｕｒｎ：ｍｐｅｇ：ＤＡＳＨ：ｔｉｌｉｎｇ：２０１３”Ｉｄ＝‘Ｔ’ ｖａｌｕｅ＝“ｘ：ｙ”／＞。

属性“Ｉｄ”は、可能性あるまたは禁止された関係付けを示す識別子の属性である。

変数‘Ｔ’は、統合され得るタイルの組を識別する。同じ‘Ｉｄ＝Ｔ’の変数は、タイルが、同じ最初のビデオから発行されたことを意味し、同じ解像度を持つことを意味する。結果として、これらは、クライアントにより共にストリーミングされてまとめることができる。変数‘Ｉｄ＝Ｔ’は任意である。デフォルトでは、これが存在しない場合に、全ての規定されたタイルを共に構成できる（これらは、同じ最初のビデオから発行される）。‘Ｔ’は整数である。

属性“ｖａｌｕｅ”により、タイルのポジションを識別することが可能になる。整数である‘ｘ’および‘ｙ’は、左から右、ならびに、上から下への、タイルの組の中の、現在のタイルの水平的および垂直的な位置をシグナリングする。整数である‘ｘ’および‘ｙ’は、あくまで正である。例えば、最初のビデオが、タイルの２つの水平な線に分けられている場合、および、各水平な線がタイルの４つの列に分けられている（８個のタイルが生成される）場合に、ｖａｌｕｅ＝“３：２”は、第３の列および第２の線にタイルがあることを意味する。‘ｘ’および‘ｙ’が“０”に設定されている場合に、スキームに関係付けられているビデオは最初のビデオのタイル化されていないバージョンである、すなわち、フルフレームのビデオであることを意味する。デフォルトでは、タイル化するロールが存在しない場合、ビデオはタイル化されていないビデオである。ＭＰＤ解釈に混乱のリスクがあるときに、これは有用なことがある。

この例では、スキーム８０２の値は、タイル“１：２”に関係付けられたビデオを指定する。

オプションとして、ビデオでないメディアコンポーネントとタイル化されたビデオコンポーネントとのグループ化を明確にする必要があるときに、提案されたスキームは、ビデオではない（が、例えば、オーディオまたはテキスト）メディアコンポーネント（またはメディアデータ）のためにも使用できる。このようなケースでは、Ｉｄ値のみを使用しなければならない。異なるメディアコンポーネントに対する同じＩｄにより、それらの間で関係付けを行うことが可能になる（異なるメディアコンポーネントを同時に再生できる）。

この好ましい実施形態では、“ｖａｌｕｅ”属性は２つの整数値からなる。しかし、他の変数も存在し得る。例えば、値属性のシンタックスは：
・ｖａｌｕｅ＝“ｘ：Ｘ：ｙ：Ｙ”とすることができ、あるいは、コンマで分離でき：ｖａｌｕｅ＝“ｘ：Ｘ，ｙ：Ｙ”、あるいは、例８１２におけるように、水平ポジションと垂直ポジションとの間を何らかのセパレーターまたは記号で分離でき、以下の意味がある：‘ｘ’は、列の組全体の中のタイルの水平位置（タイルのインデックス）をシグナリングし；‘Ｘ’は、列の数をシグナリングし；‘ｙ’は、線の組全体の中のタイルの垂直位置（タイルのインデックス）をシグナリングし；‘Ｙ’は、線の数をシグナリングする。

例えば、図５を参照すると、タイルＴ６のシグナリングは以下のようになるであろう：＜Ｒｏｌｅ ｓｃｈｅｍｅＩｄＵｒｉ＝“ｕｒｎ：ｍｐｅｇ：ＤＡＳＨ：ｔｉｌｉｎｇ：２０１３”Ｉｄ＝‘１’ｖａｌｕｅ＝“２：４：２：２”／＞またはコンマで分離された：ｓｃｈｅｍｅＩｄＵｒｉ＝“ｕｒｎ：ｍｐｅｇ：ＤＡＳＨ：ｔｉｌｉｎｇ：２０１３”Ｉｄ＝‘１’ｖａｌｕｅ＝“２：４，２：２”／＞または水平ポジションと垂直ポジションとの間を何らかのセパレーターまたは記号で分離できる。スキーム８１２の値は、タイル“１：２”に関係付けられたビデオを指定し、タイルが２ｘ２”のグリッドであるという情報を提供する。

ビデオフレーム８００により示される例では、図８ａの下で説明するように、最初のビデオは同じサイズのタイルに分けられる。しかし、これに制限されない。タイルは異なるサイズとすることができる。例えば、タイルは四分木の区分から生成され得る。このようなケースでは、“ｕｒｎ：ｍｐｅｇ：ｄａｓｈ：ｔｉｌｉｎｇ：２０１３”に等しい＠ｓｃｈｅｍｅＩｄＵＲＩのシンタックスは、タイル区分の性質を考慮すべきである。新規のシンタックスは以下のものとすることができる：＜Ｒｏｌｅ ｓｃｈｅｍｅＩｄＵｒｉ＝“ｕｒｎ：ｍｐｅｇ：ＤＡＳＨ：ｔｉｌｉｎｇ：２０１３“Ｉｄ＝‘Ｔ’ｖａｌｕｅ＝“ｃｏｏｒｄｉｎａｔｅｓ”ｃｏｏｒｄｉｎａｔｅ＿ｓｙｓｔｅｍ＝“Ｃ”／＞。

“ｃｏｏｒｄｉｎａｔｅｓ”は、座標系のオプション的な識別子（この例では、‘ｔｈｅ ｖａｌｕｅ “Ｃ”）から識別され得る値（または値の組）であろう。座標系の例は、ピクセルでのタイルの絶対位置、実際にはデフォルトのケースを規定することができる。座標は、タイルの上左隅のピクセルでの位置（ｘ，ｙ）である。“ｃｏｏｒｄｉｎａｔｅ＿ｓｙｓｔｅｍ”属性が指定されないときに、タイル化グリッド中のポジションを示す値中に‘：’という記号が存在しない限り、属性“ｖａｌｕｅ”において与えられる座標をピクセルポジションとして表現すると仮定する。タイルのサイズは、表現の標準規格の属性の幅および高さにより規定される。例えば、図８で参照されるコード部分８２１では、タイルポジションは、シンタックス値＝“ｘ，ｙ”を使用するピクセル座標系を用いてシグナリングされる。参照番号８２２の線では、列＝０、行＝２４０のポジションに上左隅があるタイルを記述する。全コード部分の例８０１、８１１、８２１は、タイル化情報を持つまたは持たないタイルポジションを提供する。タイルサイズは、関係する“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”エレメントから解析スされなければならない。

図８ａは、ＨＥＶＣタイルの特定の文脈では、タイルのポジションおよびサイズの代替的なシグナリングを提供する。この図８ａの右部では、タイル化されたビデオフレームの３つの例８６０、８７０および８７５が提供される。各例は、以下で説明するように特定の構造に対応する。

図５ａを参照して説明するように、ＨＥＶＣタイルは、タイルの行および列の境界のポジション（例えば、図５ａに戻ると、参照されるタイル化されたビデオフレーム５５０は、３ｘ３のタイル化構成となる、２つの行５５１と、２つの列５５２の境界を示す）を通して、ビットストリーム中でシグナリングされる。そのため、タイルを記述する“Ｒｏｌｅ”エレメント８６２中に、図８ａ中の例８６１におけるようなタイル化編成を置くことを提案する。この例では、タイル化が規則的であるか否かにかかわらず、最初の値を示すために属性“ｇｒｉｄ”が使用される。これは、ＨＥＶＣ標準規格で規定されるＨＥＶＣビットストリームからのｕｎｉｆｏｒｍ＿ｓｐａｃｅ＿ｆｌａｇをＭＰＤに直接変換する。

タイル化されたビデオフレーム８６０におけるように、タイル化が規則的であるときに、グリッド属性中の他の値は、タイルの列−１の数およびタイルの行−１の数を提供する（ＨＥＶＣビットストリームにおいてエンコードされる通り）。タイル化されたビデオフレーム８６０に対して参照される線８６２におけるように、水平次元でのタイルのこの数は、ＨＥＶＣビットストリームパラメータｎｕｍ＿ｔｉｌｅｓ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１から直接計算され、垂直次元でのタイルの数は、ＨＥＶＣビットストリームパラメータｎｕｍ＿ｔｉｌｅｓ＿ｒｏｗｓ＿ｍｉｎｕｓ１（ＨＥＶＣ標準規格において規定）から直接計算される。この表記により、ＭＰＤ中のＨＥＶＣピクチャパラメータセットの値を直接ＭＰＤに変換することが可能になる（ｎｕｍ＿ｔｉｌｅｓ＿ｃｏｌｕｍｎｓ＿ｍｉｎｕｓ１およびｎｕｍ＿ｔｉｌｅｓ＿ｒｏｗｓ＿ｍｉｎｕｓ１）。グリッド属性に加えて、タイルのサイズおよびポジションを計算できるために、フルフレームビデオのサイズが必要とされる（参照番号線８６２を参照）。

タイル化されたビデオフレーム８７１または８７３において表されるように、タイル化が均一でないケースでは、第１の値が０に等しいグリッド属性は、“Ｒｏｌｅ”エレメントが、ピクセルで与えられる、各列に対するポジションのリストと、行に対するポジションのリストとを導き出すことが可能でなければならない。このようなケースでは、行および列を規定するタイルの境界の数は、“ｇｒｉｄ”属性の後続する値に含まれる。タイル化されたビデオフレーム８７２は、行および列の境界のポジションを示すために、属性に可能性ある名前を提供する（これは、異なる名前とすることができるが、生成および解析の際に本発明に影響を与えない）。行および列の境界のポジションは、フルフレームビデオの幅および高さを持つピクセル中で指定される（線８７２参照）。

（表していない）別の実施形態として、規則的なタイル化に対して、グリッドならびに幅および高さの属性は、例えば、ｇｒｉｄ＝“ｗ，ｈ，Ｗ，Ｈ”のような、１つの単一な属性に簡略化でき、ここで、ｗおよびｈはそれぞれタイルのサイズ（ピクセルでの幅および高さ）を提供し、Ｗ、Ｈはフルフレームビデオのピクセルでのサイズである。例８６１、８６２に適用すると、これはｇｒｉｄ＝“３２０，２４０，６４０，４８０”となる。これは、ＤＡＳＨクライアントに対するシンタックスをより容易に解析することを可能にするという利点を有する（８６２における３つの異なる属性の代わりに４つの値全てを提供する１つの属性）。

タイル化構成のシグナリングに対する別の実施形態は、最高レベルのシグナリングでのタイル化情報を有することである。したがって、１回記述でき、タイルに関係付けられている全“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”フィールドから使用できる。これは、マニフェストの記述コストおよびサイズを減少させ、マニフェストのダウンロード時間を潜在的に減少させて、ストリーミングアプリケーションのスタートアップ遅延を減少させる。

図８ｂでは、コードの部分８８１および８８６は、タイル化構成を記述するためのこのようなエレメントを例として示す。これらのコードの部分８８１および８８６は、図８ｂの右部に概略的に示す２つのタイル化されたビデオフレーム８８０および８８５に関連する。

このタイル化構成から到来する任意のタイル表現は、以前の言及したタイル化“Ｒｏｌｅ”エレメントの“ｉｄ”属性を通じて参照され得る。均一な属性は、タイル化が規則的か否かを示し、ｕｎｉｆｏｒｍ＿ｓｐａｃｉｎｇ＿ｆｌａｇ ＨＥＶＣ ｆｌａｇの直接の変換であることを示す。１に設定されるときに、以下の（列に対する）属性ｃｏｌｓおよびｒｏｗｓは、タイルの列の数−１およびタイルの行の数−１を示す。

参照される例８８０では、１つのみのタイルの行の境界および１つのタイルの列の境界がある。最後の２つの属性は、フルフレームビデオの次元の幅および高さを提供する。タイル化されたビデオフレーム８８５におけるように、タイル化が均一でないときに、“ｔｉｌｉｎｇ”エレメントは、タイルの列および行のピクセルでのポジションを提供する子エレメントを含む（線８８７に示すような、次元毎に１つのエレメント）。タイル化構成が時間とともに変化するケースでは、新しい期間（＜Ｐｅｒｉｏｄ＞）が作成される。この新しい期間は、新しいタイル化構成を含む。

マニフェストが“ｔｉｌｉｎｇ”エレメントを通じて複数のタイル化構成を記述するケースでは、所定のタイルに適用されるタイル化は、タイルを記述する新しい属性をＲｏｌｅに追加することにより、その“ｉｄ”属性を通じて参照できる。例えば：＜Ｒｏｌｅ ｓｃｈｅｍｅＩｄＵｒｉ＝“ｕｒｎ：ｍｐｅｇ：ＤＡＳＨ：ｔｉｌｉｎｇ：２０１３”Ｉｄ＝‘ｔｉｌｉｎｇ＿１’ｖａｌｕｅ＝“０，０”／＞。タイル化構成についてストリーミングクライアントに知らせるための２つの代替実施形態がある。この情報は、例えば、ビデオ中のアドレス割当可能な空間エリアについてユーザに知らせるのに有用である。属性によるアプローチは、各タイルに対する情報を複製する。結果的に、よりコンパクトになるが、同じエレメント中でタイル関連の全情報を保持するのに有益である。これは、コンテンツ配信ネットワーク中の任意の中間ノードによりマニフェストに適用される変化のケースでは、堅牢性をもたらす。

堅牢性のアスペクトおよび“Ｒｏｌｅ”エレメントを通じたタイルの自己記述を考慮すると、ポジション情報に加えてサイズ情報も“ｖａｌｕｅ”属性に置くことも興味深い。この実施形態では、“ｖａｌｕｅ”属性は、以下の順序でｃｏｍａで分離された４つの整数のリストを指定する：上左隅のｘおよびｙのポジションならびにタイルの幅および高さ。例えば：図１２におけるようなｖａｌｕｅ＝“ｘ，ｙ，ｗ，ｈ”を後に記述する。タイルのポジションを表現するのに使用される座標系は、２Ｄ座標系であり、ここで、起点は任意であるが、タイル化の役割に対する同じｉｄを共有する全表現にとって同じとなるであろう。さらに、ｘ軸は、スクリーンの右に向かって方向付けられ、ｙ軸は下に向かって方向付けられるように仮定する。複数のタイルをレンダリングし、それらを空間的に整列させるためにビューアにより幅および高さが使用されてもよい。

別の実施形態は、Ｗ３Ｃ ＭｅｄｉａＦｒａｇｍｅｎｔｓ ＵＲＩ １．０で規定された空間フラグメントに対するシンタックスを使用することにより、タイルのポジションおよびサイズを示すことを提案する。これは、以下のような“ｖａｌｕｅ”属性となる：すなわち、ピクチャ８６０における最初のタイルを記述するためのｖａｌｕｅ＝“＃ｘｙｗｈ＝０，０，３２０，２４０”（図８ａ参照）。これは、メディアフラグメントＵＲＩ仕様もサポートするストリーミングクライアントにとって好適さをもたらす。当然、例えば、メディアフラグメントＵＲＩがビデオをディスプレイにつなげるために使用される場合に、メディアフラグメントＵＲＩを持つクライアントのサポートは、正しい空間フラグメントを持つ“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”と自動的に一致し、適合論理の選択をさらに容易にする。さらに、サーバもメディアフラグメントＵＲＩをサポートするときに、ストリーミングクライアントは、対応するタイルを直接要求するために、メディアフラグメントＵＲＩ仕様により指定されるように、ＭＰＤにおいてＢａｓｅＵＲＬを使用し、値（ｖａｌｕｅ）属性の値をＨＴＴＰレンジヘッダに置くことができる。メディアフラグメントＵＲＩシンタックスを使用する別の利点は、他の何らかのメディアフラグメントＵＲＩクライアントが同じタイルにアクセスできるように、これまで形成されたＵＲＬをクライアントがブックマークし、配信できることである。

各タイルがそれ自体の“ＡｄａｐｔａｔｉｏｎＳｅｔ”で別々に記述されるときに、クライアントが、どのフルフレームビデオの“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”が各タイルに関連するかを特定するのは難しい。タイルを記述する“Ｒｏｌｅ”エレメントにおいて、すなわち、“ｔｉｌｉｎｇＲｏｌｅ”において、空間値＝“０：０”を使用することを先に提案した。しかし、フルフレームビデオは同じ方法で記述できる。タイルの“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”に注釈が付けられる、すなわち、（表されていない）“ｔｉｌｉｎｇ”Ｒｏｌｅを使用する。このようなケースでは、フルフレームビデオの“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”に関係付けられる“ｔｉｌｉｎｇ”Ｒｏｌｅは、このフルフレームビデオのを構成するタイルの“ｔｉｌｉｎｇ”Ｒｏｌｅの“ｉｄ”属性と、その“ｉｄ”属性を同じ値に設定させる。デフォルトでは、任意の値属性なしにタイル化“Ｒｏｌｅ”がビデオの“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”に関係付けられるときに、この“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”はフルフレームビデオとして考えられなければならない。この“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”をさらに明白にするために、値属性を伝えることができる。このようなケースでは、ｘおよびｙフィールドは０をとり、０は、ｗおよびｈがフルフレームビデオの幅および高さの値をとる間の上左隅の値である。“ｔｉｌｉｎｇ”エレメントが宣言されるケースでは、フルフレームビデオの“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”に対するタイル化Ｒｏｌｅは、タイルからフルフレームビデオまでの関連が、ストリーミングするクライアントに明白であるように、当然、その“ｉｄ”を通じてのこのタイル化を参照する。フルフレームビデオのシグナリングに関する先の記述のうちの如何なるのものも、マニフェストを使用するクライアントに対する曖昧さを回避するという利点を有する。しかし、標準規格にできる限り近いままであるために、クラシカルＲｏｌｅエレメントも使用でき、標準規格の“ａｌｔｅｒｎａｔｅ”および“ｍａｉｎ”フィールドは、それぞれ、タイルの“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”を含む適応セットと、フルフレームビデオの“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”を含む適応セットとにそれぞれ割り当てられる。これらの全Ｒｅｐｒｅｓｅｎｔａｔｉｏｎが同じＡｄａｐｔａｔｉｏｎＳｅｔで宣言されるときに、各ＲｅｐｒｅｓｅｎｔａｔｉｏｎのそれぞれのＲｏｌｅを記述するために、Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ毎に１つのＣｏｎｔｅｎｔＣｏｍｐｏｎｅｎｔエレメントを使用できる。

これは、図１１でさらに詳細に記述する。この例は、９６０ｘ５４０の４つの空間タイル（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ １１０１，１１０２，１１０３，１１０４）からなるＨＤビデオ（１１０６におけるＲｅｐｒｅｓｅｎｔａｔｉｏｎ‘Ｒ０’）を記述する。各タイルはそれ自体の“ＡｄａｐｔａｔｉｏｎＳｅｔ”および関係する“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”とともに“ｔｉｌｉｎｇ”Ｒｏｌｅを有する。“ＴＳ１”により特定される、関係付けられ得る４つのタイルの１つの組のみがある。

２つのサブセット１１０５は、第１のサブセットからのフルフレームビデオと第２のサブセットからの任意のタイルまたはタイルの構成との間の選択を示すように規定される。所定のタイルに対して複数の“Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ”スキームが利用可能であるときに、例えば、帯域幅の観点から、ＤＡＳＨにより提供されるダイナミックスイッチングメカニズムは壊れないことが図１１の例から容易に推定され得る。

図９は、本発明で規定される新規のスキームの使用を示す完全な例である。この例は、ＤＡＳＨ標準規格（ＭＰＤ）を参照としてとる。この図では、メディア表現（ビデオおよびオーディオメディア）を記述する。２つのサブセットが記述される：
・第１のサブセットは、Ｉｄ：‘０’、‘１’、‘２’および‘３’を持つ適応セットを含み、
・第２のサブセットは、適応セットタグＩｄ：‘４’、‘５’および‘６’を含む。

先に言及したように、サブセットの使用により、いくつかの適応セットを共にストリーミングできないことが指定できるようになる。第２のサブセットの適応セットは、第１のサブセットの適応セットともにストリーミングできない。第１のサブセットでは、オーディオおよびビデオ表現（新規のスキームを持つおよび持たない）が利用可能である。このような表現は、スキーム‘ｔｉｌｉｎｇ’がサポートされていない場合でさえ、メディアデータをストリーミングする可能性をクライアントに与える（スキームを持たないＭＰＤシンタックスが常に理解される）。

第１のサブセットでは、第１のビデオ表現を含む適応セットが、線９００を使用することにより記述される：
・＜Ｒｏｌｅ ｓｃｈｅｍｅＩｄＵｒｉ＝“ｕｒｎ：ｍｐｅｇ：ＤＡＳＨ：ｔｉｌｉｎｇ：２０１３”Ｉｄ＝“１”ｖａｌｕｅ＝“０：０”／＞。

この線は、この適応セットに関係付けられた表現がビデオのタイル化されていないバージョン（ｖａｌｕｅ＝“０：０”）であることを示す。

本発明で提案されるスキームを持つ線は、オーディオメディア９１０を含む適応セットに関係付けられる：
・＜Ｒｏｌｅ ｓｃｈｅｍｅＩｄＵｒｉ＝“ｕｒｎ：ｍｐｅｇ：ＤＡＳＨ：ｔｉｌｉｎｇ：２０１３”Ｉｄ＝“１”／＞。

この線は、この適応セット中に含まれるオーディオメディアがビデオのタイル化されていないバージョンに関連することを示す。オプション的なフィールド‘ｖａｌｕｅ＝“０：０”’’も追加できるが、この例では無用である。

第２のサブセット（Ｉｄ＝“４”、“５”および“６”を持つ適応セット）では、新規スキームを通して２つのビデオサブトラックが記述される。第１のタイルに関連する表現エレメントは、‘４’に等しい‘Ｉｄ’を持つ適応セットに含まれる。第１のビデオサブトラックを指定する線９２０は以下の通りである：
・＜Ｒｏｌｅ ｓｃｈｅｍｅＩｄＵｒｉ＝“ｕｒｎ：ｍｐｅｇ：ＤＡＳＨ：ｔｉｌｉｎｇ：２０１３”Ｉｄ＝“１”ｖａｌｕｅ＝“１：１”／＞。

第２のビデオサブトラックを指定する線９３０は以下の通りである：
・＜Ｒｏｌｅ ｓｃｈｅｍｅＩｄＵｒｉ＝“ｕｒｎ：ｍｐｅｇ：ＤＡＳＨ：ｔｉｌｉｎｇ：２０１３”Ｉｄ＝“１”ｖａｌｕｅ＝“１：２”／＞。

この線は、適応セットに含まれる表現が、タイルの第２の線の第１のタイルに関連するＵＲＬを含むことを指定する。

本発明で提案されるスキームを持つ線９４０は、オーディオメディアを含む（第２のサブセットの）適応セットに関係付けられる：
・＜Ｒｏｌｅ ｓｃｈｅｍｅＩｄＵｒｉ＝“ｕｒｎ：ｍｐｅｇ：ＤＡＳＨ：ｔｉｌｉｎｇ：２０１３”Ｉｄ＝“１”／＞。

この線は、この適応セット中に含まれるオーディオメディアがビデオサブトラックのタイル化されたバージョンのうちの１つに関連することを示す。

図１０は、本発明の１以上の実施形態の実現のためのコンピューティングデバイス１０００の概略的なブロック図である。コンピューティングデバイス１０００は、マイクロコンピュータ、ワークステーションまたは軽量ポータブルデバイスのような、デバイスであってもよい。コンピューティングデバイス１０００は、以下に接続された通信バスを備える：
−マイクロプロセッサのような、中央処理ユニット１００１は、ＣＰＵと示す；
−マニフェストを読み取るおよび書き出すための、ならびに／または、ビデオをエンコーディングするための、ならびに／または、所定のファイルフォーマット下でデータを読み取るもしくは生成させるための方法を実現するのに必要な、記録変数およびパラメータに適合したレジスタ並びに、本発明の実施形態の方法の実行可能なコードを記憶するためのランダムアクセスメモリ１００２は、ＲＡＭと示す。そのメモリ容量は例えば拡張ポートに接続されたオプション的なＲＡＭにより拡張され得る；
−本発明の実施形態を実現するためのコンピュータプログラムを記憶するためのリードオンリーメモリ１００３は、ＲＯＭと示す；
−ネットワークインターフェース１００４は、処理されることになるデジタルデータを送信または受信する通信ネットワークに通常接続される。ネットワークインターフェース１００４は、信号ネットワークインターフェースとすることができ、または、１組の異なるネットワークインターフェースからなることができる（例えば、ワイヤードおよびワイヤレスインターフェース、あるいは、異なる種類のワイヤードまたはワイヤレスインターフェース）。データは、送信のためにネットワークインターフェースに書き出されるか、または、ＣＰＵ１００１中で動作するソフトウェアアプリケーションの制御下で受信するためにネットワークインターフェースから読み取られる；
−ユーザから入力を受信し、または、ユーザに情報を表示するためのユーザインターフェース１００５；
−ハードディスク１００６は、ＨＤと示す；
−ビデオソースまたはディスプレイのような、外部デバイスからデータを受信し、外部デバイスにデータを送るためのＩ／Ｏモジュール１００７。

実行可能なコードは、リードオンリーメモリ１００３、ハードディスク１００６、または、例えばディスクのようなリムーバブルデジタル媒体のいずれかに記憶されてもよい。バリアントにしたがって、プログラムの実行可能なコードを、実行される前に、ハードディスク１００６のような、通信デバイス１０００の記憶手段のうちの１つに記憶するために、通信ネットワークにより、ネットワークインターフェース１００４を通じて受信できる。

中央処理ユニット１００１は、本発明の実施形態にしたがったプログラムのソフトウェアコードの命令またはその一部を実行するよう制御、および指示するように適合され、この命令は先述の記憶手段のうちの１つに記憶される。電源をオンにした後、ＣＰＵ１００１は、例えば、ソフトウェアアプリケーションに関する、メインＲＡＭメモリ１００２からの命令がプログラムＲＯＭ１００３またはハードディスク（ＨＤ）１００６からロードされた後に、これらの命令を実行できる。このようなソフトウェアアプリケーションは、ＣＰＵ１００１により実行されるときに、以前の図で示したフローチャートのステップを実行させる。

本実施形態では、本発明を実現するためにソフトウェアを使用する当該装置はプログラム可能な装置である。しかし、代わりに、本発明はハードウェアで（例えば、特定用途向け集積回路またはＡＳＩＣの形態で）実現されてもよい。

本発明は、特定の実施形態を参照して上述のように記述されているが、本発明は特定の実施形態に限定されず、本発明の範囲内にある技術の当業者にとってその修正は明らかであろう。

例えば、本発明は、例えば、特定の関心領域にズームするために、ＴＶに対するリモートコントローラーとしてふるまうカメラ、スマートフォンまたはタブレットなどに組み込んで良い。。これは、特定の関心エリアを選択することによりＴＶプログラムブラウジングを個人的に体験するために同じデバイスからも使用できる。ユーザによるこれらのデバイスおよび方法の別の使用は、ユーザの好ましいビデオのいくつかの選択されたサブパートを他の接続されたデバイスと共有することである。これは、監視カメラが本発明にしたがってデータを提供する方法を支援する場合に、監視下に置かれている建物の特定のエリアで起こったことをモニタリングするためにも、スマートフォンまたはタブレットでも使用できる。

多くのさらなる修正およびバリエーションは、先述の例示的な実施形態を参照したときに技術に熟知した当業者に示唆されるであろう。先述の例示的な実施形態は、単に例であり、本発明の範囲を限定するように意図されておらず、範囲は、添付の特許請求の範囲によってのみ決定される。特に、異なる実施形態による異なる特徴は適宜置き換えて良い。
上述の実施形態は、以下のように表現することも可能である。

本発明の第１の態様にしたがって、所定のビデオに対応するデータをストリーミングするための方法が提案され、独立したｎ個のビデオのサブトラックを作るために、ビデオの各フレームはｎ個の空間タイルに分割され、ｎは整数である。

方法は、
・サーバによりクライアントデバイスに記述ファイルを送信することと、
・クライアントデバイスにより、クライアントデバイスまたはクライアントデバイスのユーザにより選ばれた１つの関心領域にしたがって、１以上のＵＲＬを選択することと、
・サーバにより、クライアントデバイスから、結果の数のビデオサブトラックを要求するための１以上のリクエストメッセージを受信することと、
・リクエストメッセージに応答して、サーバによりクライアントデバイスに、要求されたビデオサブトラックに対応するビデオデータを送信することとを含み、記述ファイルは、ｎ個のビデオサブトラックの空間編成と、各ビデオサブトラックをそれぞれ指定する少なくともｎ個のＵＲＬとについてのデータを含み、各リクエストメッセージは、クライアントデバイスにより選択されるＵＲＬのうちの１つを含む。

空間タイルはピクセルの行および列からなることが指定される。

言い換えると、本発明の第１の態様は、クライアントがフレームのタイルへの分割を認識し、サーバに直接ＵＲＬリクエストメッセージを送れるように、記述ファイル（ＤＡＳＨではＭＰＤを意味する）にビデオサブトラックのＵＲＬを直接含めることを提案する。

本発明の第１の態様により、サーバとクライアントデバイスとの間のデータのストリーミングに対するリクエストの数を制限することが可能になる。さらに、これが記述ファイルを受信したときに、クライアントは既にタイルの存在および空間編成を認識しており、結果的に、対応するビデオサブトラックを表示する方法が分かる。

実施形態において、記述ファイルは、フルの所定のビデオに対応するトラックを指定するＵＲＬをさらに含み、クライアントデバイスが１つの関心領域にしたがって任意のＵＲＬを選択しない場合に、サーバはクライアントデバイスからフルビデオトラックのＵＲＬを含むリクエストメッセージを受信し、リクエストメッセージに応答して、クライアントデバイスに、フルビデオトラックに対応するビデオデータを送信する。

実施形態において、所定のビデオは、ベースレイヤおよび少なくとも１つのエンハンスメントレイヤを含むスケーリング可能なビデオであり、前記ｎ個のビデオサブトラックはエンハンスメントレイヤに対応し、前記ビデオはベースレイヤビデオトラックをさらに含み、前記記述ファイルはベースレイヤトラックのＵＲＬをさらに含み、クライアントデバイスが１つの関心領域にしたがって少なくとも１つのＵＲＬを選択した場合に、クライアントデバイスは、ベースレイヤのＵＲＬを選択し、サーバはベースレイヤトラックを要求するための１つのリクエストメッセージをクライアントデバイスからさらに受信し、前記リクエストメッセージは、ベースレイヤトラックのＵＲＬを含み、サーバはリクエストメッセージに応答して、要求されたベースレイヤトラックに対応するビデオデータをクライアントデバイスにさらに送信する。

バリアントにしたがって、所定のビデオは、ベースレイヤおよび少なくとも１つのエンハンスメントレイヤを含むスケーリング可能なビデオであり、前記ｎ個のビデオサブトラックはエンハンスメントレイヤに対応し、独立したｎ個のベースレイヤサブトラックを作るために、ベースレイヤの各フレームもｎ個の空間タイルに分割され、ベースレイヤの各タイルはエンハンスメントレイヤ中のタイルに対応し、クライアントデバイスが１つの関心領域にしたがって少なくとも１つのＵＲＬを選択した場合に、クライアントデバイスは、対応するベースレイヤサブトラックのＵＲＬを選択し、サーバはベースレイヤサブトラックを要求するための１つのリクエストメッセージをクライアントデバイスからさらに受信し、前記リクエストメッセージは、ベースレイヤサブトラックのＵＲＬを含み、サーバはリクエストメッセージに応答して、要求されたベースレイヤサブトラックに対応するビデオデータをクライアントデバイスにさらに送信する。

実施形態において、ｎ個の空間タイルの構成は、所定の数の行および列にサブ分割されるグリッドにより記述ファイルにおいて規定され、各構成は予め定められた高さおよび幅を有する。

実施形態において、ｎ個の空間タイルの構成は均一または不均一なエリアを有する空間タイルを規定する。

実施形態において、各空間タイルは長方形の領域である。

実施形態において、空間タイルが均一なエリアを有する場合に、グリッドは水平および垂直双方の次元においてその境界の数により指定される。

実施形態において、空間タイルが不均一なエリアを有する場合に、グリッドはグリッドの行および列の数と、行および列の境界のポジションとにより指定される。

実施形態において、データはＤＡＳＨ標準規格にしたがってストリーミングされ、前記記述ファイルはメディア表現記述ファイルである。

実施形態において、各ＵＲＬは予め規定された期間に対するトラックのセグメントまたはビデオサブトラックを指定する。

実施形態において、ｎ個の空間タイルの構成は、期間全体に対するシンタックスエレメントを使用することにより、各期間に対して規定される。

実施形態において、記述ファイルは、毎期間に対する各ビデオサブトラックに対して規定された１組のパラメータを含み、１組のパラメータは：
ａ．トラックのタイプ：ビデオトラックもしくはビデオサブトラック、ならびに／または
ｂ．トラックがビデオサブトラックの場合に、空間タイルのポジションおよびｎ個の空間タイルの構成
についてのデータを組み込む記述子を含む。

実施形態において、記述ファイルは、毎期間に対して、各タイルに対して規定された１組のパラメータを含み、１組のパラメータは：
トラックのタイプ：ビデオトラックもしくはビデオサブトラック、および／または、
ｂ．トラックがビデオサブトラックの場合に、ｎ個の空間タイルの構成に対する参照についてのデータを組み込むＲｏｌｅエレメントと呼ばれる記述子を含む。

実施形態において、トラックがビデオサブトラックの場合に、記述子はｎ個の空間タイルの構成に対して考えられるタイルのポジションを指定するためのスキームをさらに含む。

実施形態において、空間タイルのポジションは、グリッドの行および列のインデックスを参照することにより示される。

実施形態において、空間タイルのポジションは、タイルの上左隅のピクセルにおけるポジションとタイルの幅および高さとを参照することにより示される。

実施形態において、空間タイルのポジションは、指定された座標系におけるポジションにより示される。

実施形態において、空間タイルのポジションは空間メディアフラグメントとして表現される。

実施形態において、ビデオデータは同じコンテンツを表すｍ個のビデオに対応し、ｍは整数であり、ｍ個のビデオのそれぞれは異なる解像度を有し、ｍ＊ｎ個の独立したビデオサブトラックを作るために、各ビデオの各フレームはｎ個の空間タイルに分割される。

実施形態において、記述ファイルはビデオサブトラックに対するパラメータを含み、パラメータは異なるビデオサブトラックの可能性あるまたは禁止された関係付けについてのデータを含み、前記可能性あるまたは禁止された関係付けは、ＤＡＳＨ標準規格にしたがってデータがストリーミングされる場合に識別子属性により示される。

これにより、サブトラックの任意のサブセットのクライアント側での選択が可能になり、タイルの特定のケースでは、受信したデータをアップサンプリングまたはダウンサンプリングする必要なく、正しい表示が保証される。

実施形態において、方法は、
−所定のビデオに対応するデータを取得することと、
−取得されたデータを圧縮することと、
−圧縮されたデータをカプセル化することと、
−カプセル化されたデータから記述ファイルを生成することとをさらに含み、
前記カプセル化することは、
・所定の数のビデオセグメントファイルを生成させることと、
・メディアファイルセグメントに関係付けられる初期設定セグメントを生成させることとを含み、
各ビデオセグメントファイルは、所定の期間に対するビデオおよびｎ個のビデオサブトラックに関係付けられるデータを含み、
初期設定セグメントは、ビデオトラックおよびビデオサブトラックについての初期設定データを含む。

実施形態において、記述ファイルは、初期設定セグメントに関係付けられたＵＲＬをさらに含む。

実施形態において、初期設定データは各ビデオサブトラックの幅および高さを示す値を含む。

実施形態において、初期設定データは、正しいポジションにおける各ビデオサブトラックの表示を可能にする変換行列をさらに含む。

本発明の別の態様にしたがって、サーバデバイスによりクライアントデバイスに所定のビデオに対応するデータを提供するための方法が提案され、独立したｎ個のビデオのサブトラックを作るために、ビデオの各フレームはｎ個の空間タイルに分割され、ｎは整数である。

方法は、
・記述ファイルを生成させることと、
・前記記述ファイルをクライアントデバイスに送信することと、
・１以上のクライアントデバイスまたはクライアントデバイスのユーザのリクエストに基づいて、所定の数のビデオサブトラックに対応するビデオデータを送信することとを含み、
前記記述ファイルは、ｎ個のビデオサブトラックの空間編成と、各ビデオサブトラックをそれぞれ指定する少なくともｎ個のＵＲＬとについてのデータを含み、
各リクエストは、ＵＲＬのうちの１つを含む。

実施形態において、記述ファイルは、フルの所定のビデオに対応するトラックを指定するＵＲＬをさらに含み、サーバは、フルビデオトラックのＵＲＬを含むクライアントデバイスリクエストに基づいて、クライアントデバイスに、フルビデオトラックに対応するビデオデータを送信する。

実施形態において、所定のビデオは、ベースレイヤおよび少なくとも１つのエンハンスメントレイヤを含むスケーリング可能なビデオであり、前記ｎ個のビデオサブトラックはエンハンスメントレイヤに対応し、前記ビデオはベースレイヤトラックをさらに含み、前記記述ファイルはベースレイヤトラックのＵＲＬをさらに含み、サーバは、ベースレイヤトラックのＵＲＬを含むクライアントデバイスリクエストに基づいて、クライアントデバイスに、ベースレイヤトラックに対応するビデオデータをさらに送信する。

バリアントにしたがって、所定のビデオは、ベースレイヤおよび少なくとも１つのエンハンスメントレイヤを含むスケーリング可能なビデオであり、前記ｎ個のビデオサブトラックはエンハンスメントレイヤに対応し、独立したｎ個のベースレイヤサブトラックを作るために、ベースレイヤの各フレームもｎ個の空間タイルに分割され、ベースレイヤの各タイルはエンハンスメントレイヤ中のタイルに対応し、前記記述ファイルはベースレイヤサブトラックのＵＲＬをさらに含み、サーバは、ベースレイヤサブトラックのＵＲＬを含むクライアントデバイスリクエストに基づいて、クライアントデバイスに、ベースレイヤサブトラックに対応するビデオデータをさらに送信する。

実施形態において、ｎ個の空間タイルの構成は、所定の数の行および列にサブ分割されるグリッドにより記述ファイルにおいて規定され、各構成は予め定められた高さおよび幅を有する。

実施形態において、ｎ個の空間タイルの構成は均一または不均一なエリアを有する空間タイルを規定する。

実施形態において、各空間タイルは長方形の領域である。

実施形態において、空間タイルが均一なエリアを有する場合に、グリッドは水平および垂直双方の次元においてその境界の数により指定される。

実施形態において、空間タイルが不均一なエリアを有する場合に、グリッドはグリッドの行および列の数と、行および列の境界のポジションとにより指定される。

実施形態において、データはＤＡＳＨ標準規格にしたがって送信され、前記記述ファイルはメディア表現記述ファイルである。

実施形態において、各ＵＲＬは予め規定された期間に対するトラックのセグメントまたはサブトラックを指定する。

実施形態において、ｎ個の空間タイルの構成は、期間全体に対するシンタックスエレメントを使用することにより、各期間に対して規定される。

実施形態において、記述ファイルは、毎期間に対する各ビデオサブトラックに対して規定された１組のパラメータを含み、１組のパラメータは：
ａ．トラックのタイプ：ビデオトラックもしくはビデオサブトラック、ならびに／または
ｂ．トラックがビデオサブトラックの場合に、空間タイルのポジションおよびｎ個の空間タイルの構成
についてのデータを組み込む記述子を含む。

実施形態において、記述ファイルは、毎期間に対して、各タイルに対して規定された１組のパラメータを含み、１組のパラメータは：
トラックのタイプ：ビデオトラックもしくはビデオサブトラック、および／または、
ｂ．トラックがビデオサブトラックの場合に、ｎ個の空間タイルの構成に対する参照についてのデータを組み込むＲｏｌｅエレメントと呼ばれる記述子を含む。

実施形態において、トラックがビデオサブトラックの場合に、記述子はｎ個のタイルの構成に対して考えられるタイルのポジションを指定するためのスキームをさらに含む。

実施形態において、空間タイルのポジションは、グリッドの行および列のインデックスを参照することにより示される。

実施形態において、空間タイルのポジションは、タイルの上左隅のピクセルにおけるポジションとタイルの幅および高さとを参照することにより示される。

実施形態において、空間タイルのポジションは、指定された座標系におけるポジションにより示される。

実施形態において、空間タイルのポジションは空間メディアフラグメントとして表現される。

実施形態において、方法は、記述ファイルを生成させるステップに対する準備として：
−所定のビデオに対応するデータを取得することと、
−取得されたデータを圧縮することと、
−圧縮されたデータをカプセル化することとをさらに含み、
前記カプセル化することは、
・所定の数のメディアセグメントファイルを生成させることと、
・メディアファイルセグメントに関係付けられる初期設定セグメントを生成させることとを含み、
各メディアセグメントファイルは、所定の期間に対するビデオおよびｎ個のビデオサブトラックに関係付けられるデータを含み、
初期設定セグメントは、ビデオトラックおよびビデオサブトラックについての初期設定データを含む。

実施形態において、ビデオデータは同じコンテンツを表すｍ個のビデオトラックを含み、ｍは整数であり、ｍ個のビデオトラックのそれぞれは所定の解像度を有し、ｍ＊ｎ個の独立したビデオサブトラックを作るために、各ビデオトラックの各フレームはｎ個の空間タイルに分割される。

実施形態において、記述ファイルはビデオサブトラックに対するパラメータを含み、パラメータは異なるビデオサブトラックの可能性あるまたは禁止された関係付けについてのデータを含み、前記可能性あるまたは禁止された関係付けは、ＤＡＳＨ標準規格にしたがってデータがストリーミングされる場合に識別子属性により示される。

本発明の別の態様にしたがって、クライアントデバイスにより所定のビデオに対応するデータを取得するための方法が提案され、独立したｎ個のビデオのサブトラックを作るために、ビデオの各フレームはｎ個の空間タイルに分割され、ｎは整数である。方法は：
−ｎ個のビデオサブトラックの空間編成と、各ビデオサブトラックをそれぞれ指定する少なくともｎ個のＵＲＬとについてのデータを含む記述ファイルを受信することと、
−クライアントデバイスまたはクライアントデバイスのユーザにより、ビデオ中の少なくとも１つの関心領域を選択することと、
−記述ファイルに基づき、選ばれた関心領域にしたがって１以上のＵＲＬを取得することと、
−ビデオサブトラックを要求するための１以上のリクエストメッセージを送ることと、
−リクエストメッセージに応答して、要求されたビデオサブトラックに対応するビデオデータを受信することとを含み、
各リクエストメッセージは、クライアントデバイスにより選択されたＵＲＬのうちの１つを含む。

実施形態において、記述ファイルは、フルの所定のビデオに対応するトラックを指定するＵＲＬをさらに含み、クライアントデバイスがいずれの関心領域も選択しない場合に、方法は、フルビデオトラックを要求するためのリクエストメッセージを送ることと、リクエストメッセージに応答して、要求されたフルビデオトラックに対応するビデオデータを受信することとをさらに含む。

実施形態において、所定のビデオは、ベースレイヤおよび少なくとも１つのエンハンスメントレイヤを含むスケーリング可能なビデオであり、前記ｎ個のビデオサブトラックはエンハンスメントレイヤに対応し、前記ビデオはベースレイヤビデオサブトラックをさらに含み、前記記述ファイルはベースレイヤトラックのＵＲＬをさらに含み、
クライアントデバイスが１つの関心領域を選んだ場合に、方法は、
−クライアントデバイスによりベースレイヤのＵＲＬを取得することと、
−ベースレイヤトラックのＵＲＬを含むリクエストメッセージを送ることと、
−リクエストメッセージに応答して、要求されたベースレイヤトラックに対応するビデオデータを受信することとをさらに含む。

バリアントにしたがって、所定のビデオは、ベースレイヤおよび少なくとも１つのエンハンスメントレイヤを含むスケーリング可能なビデオであり、前記ｎ個のビデオサブトラックはエンハンスメントレイヤに対応し、独立したｎ個のベースレイヤサブトラックを作るために、ベースレイヤの各フレームもｎ個の空間タイルに分割され、ベースレイヤの各タイルはエンハンスメントレイヤ中のタイルに対応し、前記記述ファイルはベースレイヤサブトラックのＵＲＬをさらに含み、クライアントデバイスが１つの関心領域を選んだ場合に、方法は、
−クライアントデバイスによりベースレイヤサブトラックのＵＲＬを取得することと、
−ベースレイヤサブトラックのＵＲＬを含むリクエストメッセージを送ることと、
−リクエストメッセージに応答して、要求されたベースレイヤサブトラックに対応するビデオデータを受信することとをさらに含む。

実施形態において、ｎ個の空間タイルの構成は、所定の数の行および列にサブ分割されるグリッドにより記述ファイルにおいて規定され、各構成は予め定められた高さおよび幅を有する。

実施形態において、ｎ個の空間タイルの構成は均一または不均一なエリアを有する空間タイルを規定する。

実施形態において、各空間タイルは長方形の領域である。

実施形態において、空間タイルが均一なエリアを有する場合に、グリッドは水平および垂直双方の次元においてその境界の数により指定される。

実施形態において、空間タイルが不均一なエリアを有する場合に、グリッドはグリッドの行および列の数と、行および列の境界のポジションとにより指定される。

実施形態において、データはＤＡＳＨ標準規格にしたがって規定され、前記記述ファイルはメディア表現記述ファイルである。

実施形態において、各ＵＲＬは予め規定された期間に対するトラックのセグメントまたはサブトラックを指定する。

実施形態において、ｎ個の空間タイルの構成は、期間全体に対するシンタックスエレメントを使用することにより、各期間に対して規定される。

実施形態において、記述ファイルは、毎期間に対する各ビデオサブトラックに対して規定された１組のパラメータを含み、１組のパラメータは：
ａ．トラックのタイプ：ビデオトラックもしくはビデオサブトラック、ならびに／または
ｂ．トラックがビデオサブトラックの場合に、空間タイルのポジションおよびｎ個の空間タイルの構成
についてのデータを組み込む記述子を含む。

実施形態において、記述ファイルは、毎期間に対して、各タイルに対して規定された１組のパラメータを含み、１組のパラメータは：
トラックのタイプ：ビデオトラックもしくはビデオサブトラック、および／または、
ｂ．トラックがビデオサブトラックの場合に、ｎ個の空間タイルの構成に対する参照についてのデータを組み込むＲｏｌｅエレメントと呼ばれる記述子を含む。

実施形態において、トラックがビデオサブトラックの場合に、記述子はｎ個のタイルの構成に対して考えられるタイルのポジションを指定するためのスキームをさらに含む。

実施形態において、空間タイルのポジションは、グリッドの行および列のインデックスを参照することにより示される。

実施形態において、空間タイルのポジションは、タイルの上左隅のピクセルにおけるポジションとタイルの幅および高さとを参照することにより示される。

実施形態において、空間タイルのポジションは、指定された座標系におけるポジションにより示される。

実施形態において、空間タイルのポジションは空間メディアフラグメントとして表現される。

実施形態において、ビデオデータは同じコンテンツを表すｍ個のビデオに対応し、ｍは整数であり、ｍ個のビデオのそれぞれは異なる解像度を有し、ｍ＊ｎ個の独立したビデオサブトラックを作るために、各ビデオの各フレームはｎ個の空間タイルに分割される。

実施形態において、記述ファイルはビデオサブトラックに対するパラメータを含み、パラメータは異なるビデオサブトラックの可能性あるまたは禁止された関係付けについてのデータを含み、前記可能性あるまたは禁止された関係付けは、ＤＡＳＨ標準規格にしたがってデータがストリーミングされる場合に識別子属性により示される。

６９．受信したビデオデータは：
−所定の数のビデオセグメントファイルと
−メディアファイルセグメントに関係付けられる初期設定セグメントとを含み、
各ビデオセグメントファイルは、所定の期間に対するビデオおよびｎ個のビデオサブトラックに関係付けられるデータを含み、
初期設定セグメントは、ビデオトラックおよびビデオサブトラックについての初期設定データを含む請求項４８〜６８のいずれか一項に記載の方法。

実施形態において、記述ファイルは、初期設定セグメントに関係付けられたＵＲＬをさらに含む。

実施形態において、初期設定データは各ビデオサブトラックの幅および高さを示す値を含む。

実施形態において、初期設定データは、正しいポジションにおける各ビデオサブトラックの表示を可能にする変換行列をさらに含む。

本発明の別の態様にしたがって、プログラム可能な装置のためのコンピュータプログラム製品が提案され、コンピュータプログラム製品は、プログラム可能な装置にロードされ、実行されるときに、先に詳細を述べた方法を実現するための一連の命令を含む。

本発明の別の態様にしたがって、先に詳細を述べた方法を実現するためのコンピュータプログラムの命令を記憶するコンピュータ読取可能記憶媒体が提案される。

本発明の別の態様にしたがって、所定のビデオに対応するデータをストリーミングするためのデバイスが提案され、独立したｎ個のビデオのサブトラックを作るために、ビデオの各フレームはｎ個の空間タイルに分割され、ｎは整数であり、前記デバイスは、先に詳細を述べたようなデータをストリーミングするための方法を実現するための手段を有する。

本発明の別の態様にしたがって、所定のビデオに対応するデータをクライアントデバイスに提供するためのサーバデバイスが提案され、独立したｎ個のビデオのサブトラックを作るために、ビデオの各フレームはｎ個の空間タイルに分割され、ｎは整数であり、前記サーバは、先に詳細を述べたようなデータを提供するための方法を実現するための手段を有する。

本発明の別の態様にしたがって、所定のビデオに対応するデータを取得するためのクライアントデバイスが提案され、独立したｎ個のビデオのサブトラックを作るために、ビデオの各フレームはｎ個の空間タイルに分割され、ｎは整数であり、前記クライアントデバイスは、先に詳細を述べたようなデータを取得するための方法を実現するための手段を有する。

Claims (27)

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. コンピュータを請求項１７乃至２０のうち、何れか１項に記載の情報処理装置の各手段として動作させるためのプログラム。

Images