JP7273766B2 - ビデオストリーミングにおけるシーンセクションと関心領域の処理 - Google Patents

Description

本出願は、シーンのセクションまたは関心領域の特別な処理をサポートするビデオストリーミングの概念に関する。

例えばＤＡＳＨ（ＨＴＴＰによる動的適応型ストリーミング）（ＨＴＴＰ＝ハイパーテキスト転送プロトコル）を使用するビデオストリーミングでは、ビデオストリーミングを特定のシーンセクションに制限し、または特定の関心領域を優先することができると好ましい状況が増えている。例えば、パノラマビュービデオ全体をヘッドマウントディスプレイアプリケーションに送信する必要はない。むしろ、ユーザが見ているセクションに関係するシーンのセクションのみを送信する必要がある。ビデオストリームの一部を除外すると、有効なビデオデータストリームになることはほとんどない。ビデオデータストリームの特定部分の除外が許可される状況は、ほとんどの場合、階層化されたビデオストリームのエンハンスメントレイヤの除外などの特定の状況に限定される。しかし、そのような状況は、シーン部分に関してではなく、ビット深度、空間解像度、時間分解能などの点でビデオデータストリームによって伝達される情報量のスケーラビリティを主に扱う。

その上、ストリーミングターゲット、すなわちクライアントに、特定のビデオのピクチャ内の関心領域に関するヒントを提供して、例えば、ビデオのピクチャの他の部分よりも好まれる関心領域を都合良く予め設定することが好ましいであろう。これまで、このような関心領域のシグナリングを実行する可能性は存在したが、これらの機能は制限されており、サーバとクライアントとの間の通信に負担をかけている。

従って、本発明の目的は、減少されたストリームと元のストリームとの間の適合性を整備する際に、シーンセクション固有の、特定の縮小されたデータストリームのストリーミングを可能にし、かつ、より効率的に関心領域のシグナリングを行う方法を可能にするビデオストリーミングの概念を提供する、ビデオストリーミングの概念を提供することである。

この目的は、独立請求項に記載の主題によって達成される。

本発明者らが見出したことは、セクション固有のビデオデータストリームが、ファイル形式を使用し、セクションを形成するタイルのセットのタイルがその中に符号化されているスライスを、１つ以上のソーストラックのセット内に組み込むことにより、適合性の保存を伴ってシーン全体に関連するビデオデータストリームを削減することにより、導出されてもよく、構成命令を含む１つ以上のギャザリングトラックのセットが、スライスの特定部分の置換を通知し、および／またはスライスの特定部分をコピーすることを指示することによって、セクション固有のビデオデータストリームの合成を指示するために使用されるということである。この手段により、特定のシーンセクションのみに関連するようにビデオデータストリームを縮小することは、しかし、構成命令によって指示されるような合成を行うことによって、適合するセクション固有のビデオデータストリームを取得する機会を受信者、すなわちクライアントに提供することにより実現可能である。

本出願の基礎をなす別の知見は、ビデオストリーミングサーバからクライアントへのビデオストリームによって表されるシーン内の関心領域の位置の指示に関する。大部分のアプリケーションにおいて、プリフェッチングまたは他の優先順位付けの概念を有利に誘導するためには、関心領域の位置が固定されていることは大抵の場合は不十分であることが分かっている。従って、ビデオストリームには、位置が時間的に変化するような形で関心領域の位置を示す情報が付随する。サーバ／クライアントの通信に課せられる制約を低くするために、情報が関心領域のやがて来る位置の変化をスケジュールするような形で、ビデオストリームの５つのフォーマットボックス内で、すなわちビデオストリーム自体の中で、ＳＡＮＤ（サーバおよびネットワークアシストダッシュ）メッセージを介して、および／またはストリーミングセッションの開始時に情報を最初に伝達することを介して情報を伝達してもよい。

上記の概念の組み合わせが実現可能であり、以下の説明および従属請求項の主題でもある。

上で概説した概念の有利な実現形態は、従属請求項の主題である。本出願の好ましい実施形態が、図面を参照して以下に説明される。

サーバと、サーバ１０がアクセス可能なビデオデータストリームと、一実施形態に従ってサーバ１０がクライアントに利用可能にしたストリームとを概略的に示す。 図１のサーバに適合するクライアントを概略的に示し、併せてクライアントが合成する際の基となる、インバウンドストリームおよびセクション固有のビデオデータストリームの概略図、ならびにセクション固有のビデオデータストリームからセクション固有のビデオを再構成する、任意選択的に存在するビデオデコーダ７２の概略図を示す。 一実施形態による、特定のスライスに対する合成のサブプロセスの概略図を示す。 適合性の整備を示すための、図１のサーバがアクセス可能なビデオデータストリームと、図２のクライアントによって合成されたビデオ固有のビデオデータストリームとを処理することができるビデオデコーダの概略図を示す。 構成命令のタイプを示すコンストラクタタグと、それに続くデータフィールド長インジケータＤＦＬと、それに続くデータフィールド長のデータフィールドとからなる構成命令の例を示し、それにより合成されたストリームの中へ、例えば置換を挿入する挿入命令の例を表している。 別のコンストラクタタグを有するコピー命令の例を示し、そのデータフィールドは、データフィールド長インジケータによっても示される長さを有するが、参照トラックへのインデックスＴＲＩと、開始点によってコピーされるべき部分の指示において、命令が参照するサンプルまたはピクチャまたはアクセスユニットのインジケータ、すなわちＳＯと、データオフセットと、長さ、すなわちデータ長とを含む。 図５ｂの命令の代替例を概略的に示す。 第１の実施形態による、構成命令アレイまたはシーケンスの概略図を示す。 コンストラクタアレイの代替例を概略的に示す。 概念化されたビデオデータの概略図であり、図１～図４に関連して概説したストリーミングコンセプトの基礎として有利に機能する。 シーンが４×３タイルに細分化され、クライアントに提供されるセクションが３×２タイルの共通サイズをそれぞれ有する例を概略的に示しており、併せて、各タイルソーストラックおよびギャザリングトラックの、対応する個別レプリゼンテーションへの関連付けを示し、それにより、結局、１２個のタイルレプリゼンテーションと４個のギャザリングレプリゼンテーションになっている。 共通ＵＲＬテンプレートをシグナリングすることによってマニフェストのサイズを縮小するために使用できるマニフェストまたはメディアプレゼンテーション記述ファイルの例を示す。 実施形態による、クライアントによって開始されたそれぞれのセグメントフェッチによって導かれるサーバからクライアントへのセグメントトラフィックを示す概略図であり、別個のレプリゼンテーションが、一方ではソーストラックに、他方ではギャザリングトラックに提供される。 図９と比較した代替例を示す概略図であり、ギャザリングトラック情報がソーストラックのセグメント内で伝達される。 図１０に従ってギャザリングトラックを伝達する実施形態に従って伝達されるギャザリングトラックを示し、結果として生じる冗長性が示されている。 対応するセクションの左上のタイルに関するソーストラックレプリゼンテーションのセグメント内のギャザリングトラックの伝達を示す概略図であり、図６の例を基礎として考えた場合に、結果として生じる冗長性が示されている。 付加的なインデックスフィールドＣＩＤＸを含むように修正された構成命令の例を表す概略図を示し、これにより、示した構成命令を含む対応するギャザリングトラックがパラメータ化可能となり、構成命令のＣＩＤＸがパラメータ化設定として使用されるインデックスに対応すれば、構成命令が単に実行される。 図１３に示すような、インデックス化可能な構成命令を使用するパラメータ化可能なギャザリングトラックの例を概略的に示すが、図１４は、異なるパラメータ化設定における同じパラメータ化可能なギャザリングトラックを示しており、インデックス化可能な構成命令の中で、実際に実行された構成命令を丸で囲んで示している。 時間変化する関心領域の表示を可能にする実施形態による、サーバおよびクライアントを示す概略図を示す。 タイルに細分化されたビデオの概略図を示し、クライアントへのセクション固有のビデオデータストリーム伝送が好ましい例示的な使用例を示す。

図に関して以下で提示した本出願の実施形態の説明は、最初に、適合性の保存においてセクション固有のビデオデータストリームのストリーミングをサポートするビデオストリーミングに関する実施形態に集中する。以下に、ＲＯＩ位置指示に関する実施形態を説明する。アプリケーションでは、両方のタイプの実施形態を一緒に使用して、両方の概念を活用してもよい。

セクション固有のビデオデータストリーミングに関する実施形態の理解を動機付けし容易にするために、ビデオデータストリームによって表されるホストシーンの部分のみをストリーミングしたいという希望に対する出処を示すアプリケーションシナリオの例を説明する。この例は、基礎となるビデオコーデックとしてのＨＥＶＣに関して提供されるが、例がＨＥＶＣに関して提供されるという事実は、本出願およびその後に説明される実施形態がＨＥＶＣに限定されることを示唆すると見なすべきではない。むしろ、任意の他のビデオコーデックを基礎として使用してもよい。

ＨＥＶＣビットストリームは、ピクチャ内予測依存性（エントロピー復号依存性を含む）を断つ「タイル」概念を使用して生成することができる。各タイルは、別々に扱うことができ、例えば１つのプロセッサ／コアで処理することができる。各タイルが異なるスライスの中に含まれる場合、異なるタイル間で共有される情報はなく、オンにすると、再構成されたサンプルのループフィルタリングのみが必要となるであろう。タイルが使用される場合、ビデオ全体は、Ｎ×Ｍタイルの矩形パターンで構成される。特定の使用例では、大きなパノラマから取った小さなウィンドウ（別名ＲｏＩ）の表示のように、タイルのサブセットのみをデコードする必要があるだろう。しかし、最初にＨＥＶＣビットストリームは、ピクチャのタイルが前のピクチャの異なるタイルから推測されないようにインター予測が制約されるように符号化されなければならない。これらの制約が満たされたとしても、ビットストリームの不要な部分が除去される一方で、タイルの選択に対応するビットストリームの部分が連結される場合、結果として得られるビットストリームは、もはや適合するＨＥＶＣビットストリームではない場合がある。

図１６に示す例では、選択されたＲｏＩ（図中の矩形９６０で幅が示される）に対して、９つのタイル（ＨＥＶＣ仕様の観点ではタイルセット）からなるタイルサブセットがどのように抽出されるかが示されている。９つのタイルは、図１６において、ＣＵアドレス１００、１１０、１２０、２００、２１０、２２０、３００、３１０および３２０が示されているタイルである。抽出された部分のＣｕＡｄｄｒが０から始まらず（すなわち、first-_slice_segment_in_pic_flagが１に等しいスライスを含まないことを意味する）、かつ、いくつかのＣｕＡｄｄｒおよび対応するデータが欠落しているので、すなわち１つのタイル行から別のタイル行に移行するときに、ＣＵアドレスはタイル毎に連続していないので、抽出されたＨＥＶＣビットストリームは有効ではない。明らかに、これはどのタイルが選択されるかに依存し、例えば、最も左上のタイルが省略された場合、残りのタイルは適合するＨＥＶＣビットストリームを形成することができない。

ＣＵアドレス空間に関する上記の問題に加えて、抽出されたビットストリーム（すなわち、ＨＥＶＣビットストリーム全体よりも少ない量のタイルを含むＲｏＩ）の特性に適合する、生成される必要がある追加パラメータ（ＰＰＳ、ＳＰＳ、ＶＰＳなど）、またはＳＥＩメッセージがある。

すなわち、図１６に関する上述の説明から、ビデオデータストリームの一部を除去してセクション固有の縮小されたビデオデータストリームを得る場合、適合性の保存は単純な課題ではないことが明らかである。以下に説明される実施形態は、適合性を維持しながらビデオデータストリームのセクション固有部分を伝送することを可能にする。

図１は、本出願の一実施形態によるビデオストリーミングサーバ１０を示し、サーバ１０の動作モードの説明を容易に理解するために、ビデオ１２、ビデオ１２が符号化されて取り込まれサーバ１０が少なくとも部分的にアクセスするビデオデータストリーム１４、ならびにストリーム１６を概略的に示しており、そのストリーミングをサーバ１０がクライアントに提供して、クライアントからセクション固有のビデオデータストリームを、以下により詳細に説明する合成によって取得する。サーバ１０を実装するにはいくつかの可能性があることに留意されたい。例えば、サーバ１０は、電子回路などのハードウェア、フィールドプログラマブルアレイなどのファームウェア、または適切にプログラムされたコンピュータの使用などによるソフトウェアで実装してもよい。

以下でより詳細に説明するように、ビデオストリーミングサーバ１０は、ストリーム１６のストリーミングをクライアントに利用可能にするように構成されている。後者のストリームに基づいて、クライアントは、以下により詳細に概説される方法で、セクション固有のビデオデータストリームを合成することができる。好ましくは、ストリーム１６内のデータ量は、データまたはビデオデータストリーム１４の量と比較して縮小される。原理を理解するために、ビデオデータストリーム１４と、ビデオ１２がビデオデータストリーム１４内に符号化された方法とをまず説明する。サーバ１０は、ストリーム１６を構築するために基礎とする、サーバ１０によって除去されないビデオデータストリーム１４の少なくとも一部に関するビデオデータストリーム１４を利用できる。

図１に示すように、ビデオ１２はピクチャ１８のシーケンスで構成される。図１に示されている、ビデオ１２の内の例示的な３つの連続するピクチャ１８が示されている順序２０は、出力または表示の時間順序に対応し得る。従って、各ピクチャ１８は、シーンの空間サンプリングを表し、すなわち、サンプルのアレイから構成され、それに応じてビデオ１２はシーンの空間時間サンプリングを表す。ピクチャ１８の各々はシーンを完全に示す。「完全に」という用語は、データストリーム１４内に符号化された各ピクチャ１８がシーンを示すということを表し、これに対して、後述するように、ストリーム１６に基づいて合成可能なセクション固有のビデオデータストリームに符号化されたピクチャは、シーンのセクション２２を示すのみである。

ピクチャは、空間的にタイルに細分化される。タイルへのピクチャ１８の細分化は、タイルが行と列に規則的に配置されるようにしてもよい。図１の例では、例えば、ピクチャ１８は、３×３のタイルのアレイに細分化されて示されており、タイルは参照符号２４を使用して全体として示され、１つのピクチャ１８内のタイルをＡからＩを用いてラベリングすることにより、互いに区別している。しかし、ピクチャ当たりのタイルの数は、このタイルの数に限定されない。むしろ、ピクチャ１８は、代わりに、例えばＮ×Ｍ＞２である、Ｎ×Ｍタイルの任意のアレイに分割してもよい。しかし、タイル２４は、矩形以外の形状を有してもよいことに留意されたい。その上、ピクチャ１８の、行および列に配置されたタイル２４のアレイへの細分化もまた、限定的であると見なすべきではない。むしろ、他の種類のタイル分割が使用されてもよい。タイル２４は、ＨＥＶＣのタイルの概念に関するＨＥＶＣ標準で示される「タイル」に限定されるべきではないことにも留意されたい。図１においてここで言及されたタイル２４は、ピクチャ１８が細分化されるサブ領域の任意のサブ領域を示すものとする。図１に示すように、ピクチャのタイル２４への細分化がピクチャ１８間で等しく、それによりピクチャ１８のタイル境界２６を比較したときにタイル間のタイル境界が一致すると好ましい場合がある。

ピクチャ１８がどのようにデータストリーム１４内に符号化されるかについての詳細な方法は多様であるが、符号化は少なくともビデオデータストリーム１４がスライス２６のシーケンスで構成されるように行われなければならない。

スライス２６は、例えば、データストリーム１４を送信してもよいユニットである。スライス２６は、例えば、ユニットを形成してもよく、ユニットにおいてデータストリーム１４が個別にまたは連続したスライスのセットで、それぞれ、ＮＡＬユニットにまたは転送パケットにパケット化されてもよい。以下でより詳細に説明するように、各スライス２６は、スライスヘッダとペイロードセクションとから構成されてもよい。当面は、各スライスがタイル２４を１つだけ内部に符号化して有するように、ピクチャ１８がデータストリーム１４のスライサ２６の中に符号化されれば十分である。図１では、例えば、各タイル２４がちょうど１つのスライス２６内に符号化されていることを示すが、これは一例に過ぎず、図１の実施形態の範囲を限定するものとして扱うべきではない。図１では、スライス２６とタイル２４との間の関連性をそれぞれ示すために、大文字ＡからＩ、およびピクチャ１８からデータストリーム１４に至る破線が使用されている。図１に示すように、データストリーム１４は、特定のピクチャ１８のタイル２４に関連するスライス２６が、それらの間に任意の他のピクチャが符号化されているタイルであるスライス、またはそのタイルを有するスライスが存在しない形で、データストリーム１４内に配置される形で順序付けられたスライス２６を含んでもよい。すなわち、異なるピクチャ１８のタイル２４を伝達するスライス２６はインターリーブされない。しかし、それも単なる例であって、更なる説明を制限するものとして扱うべきではない。完全を期すため、図１はまた、データストリーム１４内にピクチャ１８のいかなる特定のタイル２４にも由来しないスライス２８が存在するであろうことを示している。そのようなスライス２８は、例えば、２つ以上のタイル、ピクチャ１８の全体、またはピクチャ１８のシーケンスにさえ関係する有効性または範囲を有する符号化パラメータを伝達してもよい。以下に提示した説明ではスライス２６に重点を置いているが、スライス２８は、本実施形態の基礎をなす明白な効果を得るために、スライス２６に関して説明したのと類似の方法で処理してもよいことは明らかである。

既に上で示したように、サーバ１０はビデオデータストリーム１４のスライス２６を利用できる。例えば、ビデオデータストリーム１４はそのままデジタル記憶媒体に格納されてもよく、サーバ１０はそこからビデオデータストリーム１４または関連する部分を読み出してストリーム１６を形成する。しかし、以下でより詳細に説明するように、代替的実施形態によれば、サーバ１０は、サーバ１０がストリーム１６を直接読み込んでクライアントにストリーミングすることができる形で概念化された、予め調整されたビデオデータに直接アクセスする。後者の態様は、サーバ１０がクライアントに利用可能にするストリーム１６に関する更なる詳細を記述した後に、より明確になるであろう。

特に、サーバ１０は、シーンのセクション２２に関係するだけの低減された量のデータをクライアントに提供するために、クライアントにストリーム１６を利用可能にする。図１の例では、例えば、セクション２２は、タイルＤ、Ｅ、ＧおよびＨの２×２サブアレイを単に覆っている、またはサブアレイによって形成されているものとして示されている。従って、タイルＡ、Ｂ、Ｃ、ＦおよびＩは、セクション２２に属していない、すなわちセクション２２の外部にあり、それに応じて、セクション２２の外側にあるピクチャ１８の部分をその中で符号化している。それに応じて、サーバ１０は、ストリーム１６がスライス２６の一部またはサブセットのみを組み込んでいるように構成されている。特に、サーバ１０は、ストリーム１６がファイル形式でフォーマットされ、１つ以上のソーストラック３０_ｄ、３０_ｅ、３０_ｇおよび３０_Ｈのセット３０、ならびに１つ以上のギャザリングトラックのセット３２を含むように構成される。セット３０は、セクション２２内のタイルが符号化されるスライス２６、すなわちタイルＤ、Ｅ、ＧおよびＨをその中に組み込んでいる。図１において実施形態が選択され図示されており、セット３０の各ソーストラックがセクション２２内のタイルの内の１つに関連付けられ、関連付けは参照符号３０の下位インデックスの対応する大文字の使用によって示されている。すなわち、この実施形態の場合、各ソーストラックは、関連するタイル２４が符号化されたスライス２６を組み込んでいる。スライス２８などの他のスライスが存在する場合は、それをセット３０に分配するために所定のルールを使用してもよい。これが行われる方法はここでは重要ではない。その上、代替的実施形態によれば、ソーストラックとセクション２２内のタイルとの間の１対１の関連付けは使用されない。むしろ、セット３０内にはただ単に１つのソーストラックが存在してもよい。

図１は、セット３２が１つのギャザリングトラック３２_１を単に備える場合を示す。しかし、後で説明するように、セクション２２に関するギャザリングトラックのセット３２は１を超えてもよい。例えば、セット３２内のギャザリングトラックの数は、セクション２２内のタイル２４の数に等しくてもよい。

１つ以上のギャザリングトラックのセット３２は、セクション固有のビデオデータストリームの前述の合成を示す構成命令を含んでおり、ビデオデータストリームの中にはシーン２２のセクションを単に示すだけのピクチャが符号化されている。構成命令は、一連の矩形３４により図１に示されている。

図１のビデオストリーミングサーバ１０と通信するクライアントの以下の説明から明らかになるように、構成命令３４は、セクション固有のビデオデータストリームの合成を指示または定義しており、例えばクライアントによって実行され、ソーストラックセット３０に組み込まれたスライス２６の特定部分の置換を通知し、ソーストラックセット３０内のスライス２６の特定部分をコピーするように指示する。

図２は、図１のビデオストリーミングサーバ１０に適合するクライアント５０を示しており、クライアントは、構成命令３４によって規定されたように、ビデオストリーミングサーバ１０からストリーム１６を取得し、セクション固有のビデオデータストリームの合成を実行することによって、ビデオストリーミングサーバ１０からビデオ関連セクション２２を取得するように構成されている。クライアント５０の動作モードに関する以降の説明を容易に理解できるように、図２には、クライアント５０がビデオストリーミングサーバ１０から取得するストリーム１６、ならびにクライアント５０が命令３４による指示による合成に従って構築するセクション固有のビデオデータストリーム５２が概略的に示されている。

構成命令３４の例の詳細、およびこれら命令３４のシーケンスがセクション固有のビデオデータストリーム５２の適切な合成を定義し得る方法については、図５ａ～図５ｅに関して後述するが、ここで概略を提示する。図１に関して上述したように、異なるピクチャのスライス２６が互いにインターリーブされないということが、データストリーム適合性の１つの要件であり得る。従って、命令シーケンス３４は、後続のピクチャ１８のタイルに関するスライス２６の合成に後続の命令が信号を送る前に、１つのピクチャに属するタイルの特定部分を適切な順序でデータストリーム５２にコピーする。従って、図２のセクション固有のビデオデータストリーム５２において、ストリーム順で、１つのピクチャに関するスライスが別のピクチャに関するスライスとインターリーブされないように、合成されたスライス５４がデータストリーム５２内に存在することが分かる。スライス５４は、スライス２６の修正したものを表す。セクション２２内の修正スライス５４とタイルとの間の関連が、対応するタイル２４の大文字によって図２に示されている。スライス２６に対するスライス５４のこの種の「変更」を図示するために、スライス２６を図示する図３を参照する。図３では、スライス２６は、シンタックス要素ワイズ符号化セクション５６、およびそれに続く非シンタックス要素ワイズ符号化セクション５８からなるものとして示されている。セクション５６とセクション５８の間の順序は、単に説明の目的のために選択されたものであることを強調すべきである。その上、スライス２６がセクション５６と５８に二分されなくてもよい一方で、セクション５８が欠落さえしてもよいが、セクション５６および／または５８の内の２つ以上を有してもよい。「シンタックス要素ワイズ符号化」という用語は、そのようなセクション５６内において、データストリームのシンタックス要素６０がデータストリーム内に符号化されていて、セクション５６内のデータストリーム内の各ビットに対して、対応するビットが関係するシンタックス要素６０が厳密に１つだけ存在し、その逆も同様であるという事実を意味し得る。換言すれば、対応するセクション５６内に符号化されたシンタックス要素６０のシーケンスは、連続したシンタックス要素６０の間のジャンクションがビットストリームドメイン内で保持され、それにより各シンタックス要素６０が、セクション５６内の１つ以上のビットの対応する連続するランに一意的に関連付けられるように、セクション５６で符号化される。例えば、そのようなセクション５６内では、シンタックス要素６０は圧縮なしで、または可変長コードを使用して符号化されてもよい。これと比較して、「非シンタックス要素ワイズ符号化された」とは、各セクション５８内に符号化されたシンタックス要素のシーケンス間の接合部がビットストリーム領域内で不鮮明になり、そのためセクション５８内のビットはもはや、シンタックス要素の内の１つに厳密に由来しないセクション５８を意味する。例えば、そのようなセクション５８は、例えば、算術的に圧縮された部分であってもよい。

例えば、セクション５６はスライス２６のスライスヘッダであるか、またはそれを含み、一方でセクション５８はスライス２６のペイロードセクションであるか、またはそれを含むことができる。例えば、データストリーム１４を符号化するために使用されるビデオコーデックは、例えば予測コーデックであってもよい。セクション５６の中に符号化されたシンタックス要素６０は、例えば、対応するスライス２６が、対応するデータストリーム１４内に符号化された対応するピクチャの最初のスライスであるかどうかを示すフラグ６０ａ、および／またはスライス２６内に符号化されたピクチャのスライス部分の位置またはスライスアドレスを示すシンタックス要素６０ｂを含んでもよい。シンタックス要素６０は、例えば、スライス２６のスライスヘッダ内に符号化されてもよい。ペイロードセクションおよび／または非シンタックス要素ワイズ符号化セクション５８内に符号化されるシンタックス要素は、コーディングモード、ブロック細分化情報、動きベクトル構成要素などの予測パラメータ、ピクチャ参照インデックス、および／または残余サンプル値および／または予測残余を通知する変換係数レベルなどのシンタックス要素であってもよい。

スライス２６から修正スライス５２を形成する際に、クライアント５０によって実行される合成６２の一部として、ギャザリングトラックセット３２内の命令３４の内の１つ以上は、データストリーム２６から特定部分をコピーしてもよい。そのような命令３４は、図３に斜線で示されている。スライス２６および５２内のコピー部分６６および７０も斜線で示されている。コピーはビットストリームドメインで実行される。すなわち、トランスコーディングは行われない。コピーは、シンタックスレベルではなく圧縮ドメインまたはビットドメインで実行される。コピー命令内に分散化またはインターリーブされることもある、図３に斜線で示した１つ以上の他の命令３４は、スライス２６の非コピー部分の代わりに、修正スライス５２の中に挿入される置換を通知してもよい。スライス２６の非コピー部分は、図３では斜線なしで示され、その置換はスライス５２内で同様に斜線なしで示される。図３に示すように、置換部分または非コピー部分６４はシンタックス要素６０を含んでもよく、これらのシンタックス要素の変更値は、対応する置換命令によって通知され、その一例が、斜線のない矩形３４によって図３で示される。ストリーム１６のスライス２６内のそれぞれの非コピー部分６４の代わりに修正スライス５４内のデータストリーム５２内に挿入される置換の内容は、命令３４のオペレータフィールド内で通知されてもよく、またはギャザリングトラックセット３２内の対応するフィールドを指し示すなどの他の手段によって、置換オペレータ３４によって通知されてもよい。従ってコピー命令３４のシーケンスは結果として修正スライス５４になり、図３の例ではコピー命令３４はコピー部分６６をコピーし、そこで置換命令は置換６８をスライス５４に中に挿入して非コピー部分６４を置換し、コピー命令３４は、スライス２６の更なるコピー部分７０をスライス５４の中にコピーする。このようにして得られた修正スライス５４は、部分６６、６８および７０のシーケンスに関連しており、部分６６、６４および７０のシーケンスに対応する元のスライス２６と比較して修正されている。しかし、図３の例は説明のためにのみ選択されたものであり、例えばスライス２６に対する合成６２内の修正プロセスは置換命令で開始することができることに留意されたい。従って、第１のコピー命令は、例えば、存在しなくてもよい。その上、以下の説明から明らかになるように、他の構成命令のタイプがあってもよく、そのタイプの実行または合成への参加が、例えば命令内に記載された特定のインデックスに依存してもよく、それにより、ある種のパラメータ化設定として機能し得る「選択された」インデックスに対応するフィールド内のインデックスの場合においてのみ、対応する命令が実行される。従って、結果として得られるギャザリングトラックは、インデックスに応じて通知される合成において変化する。その上、図３には具体的には示していないが、合成参照内、すなわちソーストラックのスライス内に、コピーされず置換もされない、すなわち単純に除外／省略される部分があってもよく、６４の不要部分を単純に除外／省略する仕組みがあってもよい。

図３に関して概説したやり方において、データストリーム５２内のスライス５４は、シンタックス要素６０がセクション２２の周縁部に正しく位置合わせされるように、すなわち、例えばピクチャ１８の左上隅の代わりに、セクション２２の左上隅を参照するように、データストリーム１４および１６内の対応するスライス２６と比較して修正されてもよい。

従って、この動作固有のビデオデータストリーム５２が図２の破線のボックスで示すようなビデオデコーダ７２に供給されると、ビデオデコーダはビデオ７４を出力し、そのピクチャ７６はシーンのセクション２２を単に示し、従ってタイルＤ、Ｅ、ＧおよびＨのみから構成されている。

図１の説明と同様に、クライアント５０は、ハードウェア、ソフトウェアのファームウェアで実施されてもよい。すなわち、クライアント５０は、電子回路、フィールドプログラマブルアレイであってもよく、または適切にプログラムされたプロセッサを備えていてもよく、ビデオデコーダ７２についても同様である。ビデオデコーダ７２に関しては、クライアント５０内に含まれてもよいし、クライアント５０の外部にあってもよいことに留意されたい。

これまで説明したように、合成６２によって、データストリーム１４に対する適合性を保つような形でビデオデータストリーム５２が得られたことが明らかになったはずである。例えば、上述したように、ビデオ適合性は、例えば、対応するビデオデータストリーム内に符号化されたビデオの１つのピクチャに属するデータストリーム内のスライスが、ピクチャのタイル２４を横断する特定のタイル順序に沿って、例えばラスタースキャン順に、例えば行毎に上から下へ順序付けられていることを必要としたであろう。ビデオデータストリーム１４では、例えば、特定のピクチャに属するタイルはＡＢＣの順にＡからＩに横断しており、データストリーム５２では、ビデオ７４の１つのピクチャ２４のタイルに属するスライスが、Ｄ、Ｅ、Ｇ、Ｈの順に並び、続いて次のピクチャのタイルに関するスライスが続くように、修正スライス５４が順序付けられており、以下同様である。各修正スライス５４内では、シンタックス要素６０などのシンタックス要素は、その値に関して修正されていた可能性がある一方で、スライスの他の部分は、いかなる修正もしていないデータストリーム５２内、すなわちコピー部分７０などのコピーされた部分内に採用されていた可能性がある。スライス２８のような他のスライスもデータストリーム５２内で修正してもよい。例えば、スライス２８の修正した例を表すために、スライス７８が図２に例示的に示されている。従って、データストリーム５２内のスライス５４のシーケンスは、ギャザリングトラックのセット３２内の対応する順序の命令３４の実行から生じる。適合性保存は、ビデオデータストリーム１４を復号化してビデオ１２を再構成することができるビデオデコーダが、ビデオデータストリーム５２によって交互に供給される場合を考慮することによって示すことができる。適合性保存によって、ビデオデコーダは、ビデオデータストリーム５２をデコードした結果、ビデオ７４を得る。例えば、図４のビデオデコーダは、図２のビデオデコーダ７２であってもよく、従って図４では同じ参照符号が選択されていることに留意されたい。しかし、代替例によれば、ビデオデコーダ７２は、ビデオデコーダ７２の複雑度のレベルが低減されているため、元のビデオデータストリーム１４を復号することができない場合があることに留意されたい。例えば、ＭＰＥＧ規格の用語を使用すると、ビデオデコーダ７２は、例えば元のビデオデータストリーム１４を復号するには十分ではないが、縮小されたビデオデータストリーム５２を復号するには十分なプロファイル、レベルまたはティアに従うビデオデコーダであってもよい。しかし、データストリーム１４および５２は両方とも、例えばＨＥＶＣなどの１つのビデオコーデックに準拠している。

これまで説明してきた実施形態を実現するための更なる詳細を提供する前に、理解を容易にするためにいくつかの注釈を提示するつもりである。例えば、上記の説明は、ピクチャ１８のこのシーンの１つの特定セクション２２に固有のセクション固有のストリーム１６を、クライアントに提供するサーバ１０の能力に重点を置いたものである。当然ながら、サーバ１０は、図１のタイルＢ、Ｃ、ＥおよびＦを例示的に包含するか、またはそれによって形成される一点鎖線８０によって描かれた、このシーンの他のいくつかのセクションに関して、対応する出力ストリームの形で、ソーストラックの対応するセット３０およびギャザリングトラックのセット３２を提供できてもよい。すなわち、セクション２２とセクション８０の両方は、ピクチャ１８のタイルの対応するｎ×ｍサブアレイからなるシーンの矩形セクションである。ソーストラックのセット３０は、次いでタイルＢ、Ｃ、ＥおよびＦに関するスライスを伝達し、１つ以上のギャザリングトラックのセット、すなわち３２は、縮小されたセクション固有のビデオデータストリームの対応する合成を実行し、その符号化によりシーンセクション２４に対応するピクチャが得られる。「サポートされる」セクションの数は、２よりも大きくてもよい。その上、２２および８０などの部分的なストリーミングがサポートされる、いかなる部分も、隣接するタイルのセットをカバーするように、または隣接するタイルのセットと同等の幅を有するようには制限されない。むしろ、セクションを形成するセットは、不連続なタイルのセットから構成されてもよい。例えば、ピクチャ１８で示されるシーンが３６０°のパノラマビューであったと想定する。この場合、意味のあるセクションは、タイルＣ、Ａ、Ｆ、Ｄを含むセクションのように、シーンの１つのエッジから反対側のエッジまで及ぶセクションによって形成することもできる。しかし、独立して符号化されたタイルの場合は、対応するギャザリングトラックはそれに対応するソーストラックを、適合するセクション固有のビデオデータストリームに合成することができ、結果としてサブセクションＣＦをサブセクションＡＤとつなぎ合わせて表示するセクション固有のピクチャが得られる。ピクチャ７６のセクション内のタイルを、ピクチャ１８内の相対的な位置に対して再配置することさえも用途によっては実現可能であり、有意義であり得る。

その上、上記の説明は、ピクチャがデータストリーム１４および５２内にそれぞれ符号化される方法に関してかなり一般的であった。一例によれば、ピクチャ１８は、タイル２４のタイル境界をまたいだ符号化相互依存性の中断を伴って、ビデオデータストリーム１４のスライス２６内に符号化されている。更に、同じピクチャの空間的に異なる部分をカバーする他の任意のタイル２４からも独立した１つだけのタイル２４を、すなわち対応するタイルを含むピクチャ、または他の任意のピクチャからも空間的に異なる部分をカバーする他の任意のタイルを含むピクチャを、各スライス２４がその中に符号化しているようにさえ、ピクチャ１８はビデオデータストリーム１４のスライス２６内に符号化されてもよい。例えば、特定のピクチャのタイルＥは、同じピクチャ内にあっても、任意の他のピクチャ内にあっても関係なく、タイルＡ、Ｂ、Ｃ、Ｄ、Ｆ、Ｇ、Ｈ、Ｉの任意のタイルへのいかなる符号化相互依存性もなく、対応するスライス２６内に符号化され得る。このような制限により、ビデオ１２に基づいてデータストリーム１４を形成するエンコーダが、動き補償された予測を形成するためにタイルＥ以外のタイルのサンプルを必要とする参照ピクチャの一部を指し示さないように、現在のタイルのタイル境界付近の利用可能な動きベクトルを制限することが要求され得る。しかし、ハイブリッドビデオ符号化コーデックのような予測コーデックを使用する義務はないことに留意されたい。例えば、代替として、ピクチャ１８は、動き補償を伴うまたは伴わないウェーブレット符号化、ロスレス符号化技術等を用いて符号化することができる。その上、ピクチャ１８を符号化する際に利用される空間的相互依存性は、大部分が比較的小さな距離に制限されるので、ピクチャ１８は、タイル境界２５をまたいだ符号化相互依存性を中断することなく、ビデオデータストリーム１４のスライス２６内に符号化することさえできる。縮小されたビデオデータストリーム５２を再構成する際、セクション２２を切り取り、その周辺をビデオ７４のピクチャ７６内にないものとして扱うことにより、対応する情報が損失し再構成歪みが生じるが、ピクチャ７６の周縁部に沿った領域は限定されるので、結果として得られるピクチャ７６の画質はアプリケーションによっては十分であり得る。下記に提示する詳細に関しては、これらの詳細は、ストリーム５２用のファイル形式の例としてＩＳＯベースのメディアファイル形式を特に参照することにも留意されたい。しかし、ストリーム５２は、このファイル形式を使用してフォーマットされることに限定されない。むしろ、任意の他のファイル形式を使用してもよい。図１に示すように、ストリーム１６は、使用されるファイル形式に従って、ストリーム１６によって表されるファイルに含まれるソーストラックのセット３０とギャザリングトラックのセット３２とを定義するファイルヘッダ９０を含んでもよく、併せて、例えば、ギャザリングトラックのセット３２のソーストラックのセット３０からの依存関係などの、トラック３０と３２との間の相互依存性の定義を含んでもよい。その上、ファイル形式に依存して、セット３０および３２内の個々のトラックを指し示すポインタがファイルヘッダ９０に含まれていてもよい。この目的のために、ストリーム１６は、各々がピクチャ７６の１つのピクチャ時刻に対応する、アクセスユニットまたはサンプルに細分化されてもよい。

ＩＳＯベースメディアファイル形式のようなファイル形式を使用して、タイル２４の特定のサブセットの読み取りを可能にするサイド情報をファイル１６内に格納し、任意の規格適合のデコーダ７２によって復号可能な適合（例えばＨＥＶＣ）ビットストリーム５２を生成することが可能である。

このようなデコーダ７２の出力７４は、フルビデオフォーマットの矩形サブセット２２であってもよい。

異なるタイルサブセット２２、８０に対しては、異なるスライスヘッダを有することが必要であることに留意されたい。スライスヘッダが各タイルサブセット２２、８０に対して正しいＣｕＡｄｄｒ６０ｂを有することを確実にするために、データの複数のバージョンを生成することができる。従って、各タイルサブセット２２、８０用に、正しいＮＡＬユニットが正しいＣｕＡｄｄｒ６０ｂと共に格納されているファイル１６内の異なる位置を指し示す、専用ギャザリングトラック３２を生成することが可能である。しかし、これはいくつかのタイルサブセット固有の調整によって全てのビットストリームを複製することにつながり、いくつかの欠点をもたらす。
－ ファイルサイズが増加する（多くの場合、逓倍される）
－ 同時に、異なるタイルサブセットの伝送がトランスポートデータレートを増加させる（多くの場合、逓倍される）
－ 異なるサブセットに対して同じタイルとしてキャッシュすることの有害な影響は、異なるトラックおよびビデオデータに対応し得る。

従って、これまで説明した実施形態は、別の方法を選択した。
１．元のビットストリームのタイル２４のスライス２６は、別々のトラック３０Ａ－Ｉに格納される。各フルピクチャ１８は、ファイル１６内に、例えばヘッダ９０内に格納されたいくつかのメタデータによって与えられる定義済みの順序で、トラック３０Ａ－Ｉ各々の１サンプルを連結したものに対応する。
２．特定のタイルサブセット２２については、追加のトラック３２が生成され、元のビットストリームを形成するトラックセット３０から選択された情報を収集する。
３．複数の「ギャザリング」トラックを生成することができ、一般にはタイルサブセット２２または８０毎に１つのそのようなトラックを生成することができる。
４．「ギャザリング」トラックの各サンプルは、１つ以上のコンストラクタ３４アレイ（図５ｄ参照）からなる。
５．各コンストラクタアレイを解釈から、ＮＡＬユニットまたはスライス５４が得られる。
６．３種類のコンストラクタが使用できる。
－ タイルサブセットに対して具体的に生成されるデータ１００を保持する、イミディエイトデータコンストラクタ（図５ａ参照）。これは、例えば、各スライスの有効なslice_headerをタイルサブセット２２のサンプルに含めるために使用することができる。
－ 各々が別のトラックを指し示し、その参照トラック３０Ｄ～３０Ｈのサンプルから取得される情報を選択する、サンプルコンストラクタ（図５ｂ参照）。これは、有効なslice_headerまたはスライスペイロードのいずれかを指し示すために使用できる（オフセットを使用してペイロードに隣接するslice_headerをスキップする）。コピー部分のオフセット１０２および長さ１０４はオペレータであることもある。
－ 各々が参照トラックのサンプルエントリを指し示し、情報（パラメータセットなど）を選択する、サンプルエントリコンストラクタ（図５ｃ参照）。

注記：ファイル形式標準で既に指定されている構造とは対照的に、ここで説明する方法では、サンプルの任意の部分を連結し、それらをサンプルで与えられた任意のデータと連結して出力サンプルを形成することができる。先に指定された構造は、別のトラックのデータを参照することができるが、設計された目的に固有のヘッダデータを生成する。例えばＲＴＰヒントサンプルは、ＲＴＰパケットのみを生成できるが、他のトラックからデータを収集し任意のデータを含むことができ、またはエクストラクタＮＡＬユニットは、１つ以上のＮＡＬユニットを生成することができるだけであるが、他のトラックから収集されたデータブロック長を示すことによって短縮することができる。
・ 新しいシンタックス要素のサポートが必要であることを示す新しいブランドを指定してもよい。
・ ギャザリングトラックのサンプルが、新しいサンプルを無視するレガシーリーダ５０による解析を可能にする互換シンタックス（図５ｅ参照）を使用する場合、そのような「ギャザリング」トラックのサンプルエントリに既存のコードポイントを使用することができる。

Ｎ×Ｍ個のタイル２４、Ｃに切断されたピクチャ１８の全ての可能な矩形（連続した）タイルサブセット２２（８０）の数が式１を用いて計算される。Ｎ≦８、Ｍ≦８のときの、Ｃの得られた値を表１に示す。

特定サイズｎ×ｍの可能な矩形タイルサブセット２２の数は、式２（上述のようにピクチャサイズＮ×Ｍ）を使用して計算される。Ｎ×Ｍのピクチャからの３×２のタイルサブセットに対して得られる値Ｃ_３，２が、３≦Ｎ≦８かつ２≦Ｍ≦８の場合について表２に示される。

式２： Ｃ_ｎ，ｍ＝（Ｎ－ｎ＋１）＊（Ｍ－ｍ＋１）

図２～図５に関して提示した上述の説明は、可能な構成命令に関する詳細な例を明らかにしただけでなく、セクション２２は、第１に、幅がｎ×ｍタイルのアレイではなく単に１つのタイルであってもよく、第２に、サーバ１０およびクライアント５０は、上で概説したように動作してもよいが、いくつかのセクションの内の１つを選択する可能性に関しては、その数は１（２２）または２（２２／８０）に限定されない、という可能性をも明らかにした。サーバ１０が取得を可能にする、セクション固有のビデオデータストリームのセクションのサイズ、およびこれらセクションの位置に依存して、タイル境界２５の全てではない部分が、サーバ１０によってサポートされる任意のセクションの周縁部を形成する場合もある。これはその結果、本出願の一実施形態によれば、ピクチャ１８が、サーバ１０によってサポートされる任意のセクションの周縁部の同一位置にあるタイル境界２５をまたいでのみ符号化相互依存性の中断を有して、ビデオデータストリーム１４のスライス２６内に符号化されてもよいことを意味する。例えば、セクション２２および８０のみをサポートする場合は、セクション２２および８０の周縁部、すなわちタイル対ＡＤ、ＢＥ、ＥＦ、ＨＩ、ＡＢ、ＤＥ、ＥＨ、およびＦＩの間のタイル境界２５のみと同一位置にあるタイル境界２５のみが、符号化相互依存性を中断することによって、ピクチャ１８のスライス２６内への符号化によって考慮され得る。しかし、より高い密度のセクションの場合、例えば、一実施形態によれば、全てのタイル境界２５が符号化相互依存性の中断を引き起こす。これに関連して、同じピクチャのタイル間の符号化相互依存性の中断に関してなされたのと同じ記述が、以前のピクチャへの依存関係が制限されるという、前述の可能性にも適用され得る。すなわち動き予測は、任意のセクション周縁部をまたぐ時間上の参照ピクチャの部分に対する依存関係が存在しないような形に制限される。

以下の実施形態は、セクション２２に関するストリーム１６などの、特定のセクションに関する特定のストリームを、サーバ１０がどのように利用可能にするかに関する可能な詳細を提供する。以降の詳細を容易に理解できるように、図６を参照すると、ビデオ１２および対応するソーストラック３０_Ａ～３０_Ｉが再び示される。ここで、図１の例は、各ソーストラックが、１つのピクチャに関する限り、対応するピクチャのタイルのちょうど１つに属するスライスと、他のピクチャ内の同一位置のタイルのスライスとを組み込んでいることに応じて選択されている。従って、ソーストラック３０_Ａは、ピクチャ１８のタイルＡに関する全てのスライス２６を組み込んでいる。同様に、ソーストラック３０_Ｂは、全てのピクチャ１８のタイルＢに関する全てのスライス２６を伝達し、以下同様である。各ソーストラック３０_Ａ～３０_Ｉにおいて、１つの時刻またはピクチャ１８に属するスライス２６は、後でクライアントにストリームされるファイル形式ストリームにおいて１つの「サンプル」を形成する。サンプル（ピクチャ）のシーケンス、すなわちピクチャの特定のシーケンス１２０に関するスライスの連続するランは、対応するＵＲＬを介してクライアントによって個別に取得可能なセグメント１２２を形成する。図６において、例えば、ピクチャ１８のシーケンス１２０のタイルＡをその中に符号化したスライス２６のシーケンスがセグメント１２２を形成し、次いでピクチャ１８の連続するシーケンス１２４のタイルＡをその中に符号化したスライス２６が続き、ソーストラック３０_Ａの後続セグメント１２６を形成し、以下同様である。同様に、他のソーストラック３０_Ｂ～３０_Ｉも時間的にサンプル（ピクチャ）１２０および１２４、ならびにセグメント１２２および１２６に細分化される。

次に説明する実施形態では、各セクションのギャザリングトラックのセット３２が類似の方法で利用可能になっている。図６では、例えば、サーバが、シーンの４つの異なるセクション２２_１～２２_４、すなわち、それらの間でセクションの位置が異なるだけの各々が２×２の幅のセクションの取得を利用可能にすることが示されている。これらのセクション２２_１～２２_４の各々について、１つのギャザリングトラック３２_１～３２_４がサーバで利用可能になっている。また、各ギャザリングトラック３２_１～３２_４は、時間的にもサンプルとセグメントの中に構成されている。各サンプル１２８について、ギャザリングトラック３２_１などのギャザリングトラックは、構成命令３４を含み、その逐次実行の結果、対応するセクション２２_１のみを示す縮小されたセクション固有のビデオデータストリームの、対応するアクセスユニットの合成をもたらす。すなわち、セクション２２_１を示すピクチャを再構成する、対応するスライスの合成をもたらす。合成のために、ギャザリングトラック３２_１は単にソーストラック３０_Ａ、３０_Ｂ、３０_Ｄおよび３０_Ｅを必要とする。類似の方法で、ギャザリングトラック３２_２～３２_４は、対応するセクション２２_２～２２_４に対する各サンプル／ピクチャ１２８用の構成命令３４を含む。ソーストラック３０_Ａ～３０_Ｉと同様に、ギャザリングトラック３２_１～３２_４はクライアントによってセグメント１２２および１２６の単位で個別に取得可能であり、セグメントの各々は対応するギャザリングトラック３２_１～３２_４のサンプル１２８の対応するシーケンスを伝達する。従って、図６の例では、クライアントは、セクション２２_１に関するセクション固有のビデオデータストリームを得るために、参照されたソーストラック３０_Ａ、３０_Ｂ、３０_Ｄおよび３０_Ｅと共にギャザリングトラック３２_１を取得する必要がある。

従って、図６の実施形態によれば、クライアント１０は、ソーストラック３０_Ａ～３０_Ｉおよびギャザリングトラック３２_１～３２_４の各々を別個のレプリゼンテーションとして扱い、例えば、クライアント５２からサーバ１０への対応する要求の時点で、サーバ１０上の利用可能なメディアデータを記述するファイルであるメディアプレゼンテーション記述のようなマニフェストの中で、状況をクライアントに通知する。しかし、これは、サーバ１０によってクライアント５０に提供されるメディアプレゼンテーション記述がかなりの量の情報を含む必要があることを意味する。例えば、各レプリゼンテーションに対して、すなわち３０_Ａ～３０_Ｉおよび３２_１～３２_４（全部合わせて１３のレプリゼンテーション）の各々に対して、メディアプレゼンテーション記述は、ベースＵＲＬまたはＵＲＬベースの指示と、ピクチャサイズの指示、すなわちソーストラック３０_Ａ～３０_Ｉの場合はタイルサイズの指示、ギャザリングトラック３２_１～３２_４の場合はセクションサイズの指示と、対応するレプリゼンテーションのセグメントのＵＲＬをベースＵＲＬと比較してまたは組み合わせて決定するための計算規則を定義するセグメントまたはＵＲＬテンプレート、および／または対応するレプリゼンテーションが従属するレプリゼンテーションの指示、例えばレプリゼンテーション３２_１が依存する参照レプリゼンテーションとしてのレプリゼンテーション３０_Ａ、３０_Ｂ、３０_Ｄおよび３０_Ｅの指示と、を含み得る。これは相当量のデータである。

これは、図７に関して示されており、４×３タイル分割と、サイズ３×２の対応する４つのセクションの例示的場合を示す。なお、以降の説明では、セクション２２_１～２２_４を関心領域ＲｏＩと呼ぶこともある。更に、ギャザリングトラックに関するレプリゼンテーションはギャザリングレプリゼンテーションと呼ばれ、ソーストラックに対応するレプリゼンテーションはタイルレプリゼンテーションと呼ばれる。

可能な組み合わせの数は、可能な提供されたＲｏＩ次元の低減された数を選択することによって、例えば２×２、３×２または３×３タイルＲｏＩのみに制限することによって低減することができるが、メディアプレゼンテーション記述（ＭＰＤ）内のＤＡＳＨ内に記述された追加トラックまたはレプリゼンテーションの数は依然として非常に多くであろう。図７は、３×２ＲｏＩが提供される４×３タイルパノラマビデオの場合に、説明されたソリューションがどのようになるかを概念的に示す。

ギャザリングレプリゼンテーションの各々は＠ｄｅｐｅｎｄｅｎｃｙＩｄを使用して、元のレプリゼンテーションであるＴｉｌｅ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ Ｒｅｐ．Ｔｉｌｅ１～Ｒｅｐ．Ｔｉｌｅ１２の内のどのレプリゼンテーションに依存しているかを示す。

次に説明する実施形態は、セグメントテンプレートコンセプトをレプリゼンテーションのセット、すなわちギャザリングトラックに関するレプリゼンテーションのセットに向けて拡張することによって、ギャザリングトラックに関して多くの冗長な情報を運ぶメディアプレゼンテーション記述が非常に大きいという問題を克服しようとするものである。メディアプレゼンテーション記述が、各ギャザリングレプリゼンテーションを別々に記述する代わりに、次の実施形態によるメディアプレゼンテーション記述は、セクションの空間位置に依存するギャザリングレプリゼンテーションのセグメントのＵＲＬを決定するための計算規則を定義するＵＲＬテンプレートを有する、メディアプレゼンテーション記述またはマニフェストを提供する。計算規則は、計算されたＵＲＬが全てのギャザリングトラック３２_１～３２_４のセグメント間で相互に異なるようなものである。この概念は、セクション２２_１～２２_４のサイズが同じであって、それにより、マニフェストまたはメディアプレゼンテーション記述が、全てのギャザリングレプリゼンテーション（セクション２２_１～２２_４）に共通した１つで、ギャザリングレプリゼンテーションの特徴を記述できる場合に使用することができる。例えば、メディアプレゼンテーション記述またはマニフェストは、全てのギャザリングレプリゼンテーションに対して１回だけ、ピクチャサイズ、コーディングプロファイルおよび／またはベースＵＲＬを示すことができる。ＵＲＬまたはセグメントテンプレートはまた、ギャザリングレプリゼンテーションのためにマニフェストまたはメディアプレゼンテーション記述内で１回だけ通知される。現在取得されているギャザリングレプリゼンテーションの対応するソーストラックのセットは、取得されたギャザリングレプリゼンテーション自体が属する対応するセクションがカバーするタイルの知識に基づいて、クライアントによって決定され得る。

換言すれば、後者の実施形態は、ＵＲＬのセグメントテンプレートを使用してギャザリングレプリゼンテーションを取得することを可能にする。それはテンプレートを使用したGatheringRepresentationのコンセプトで構成される。上記の図７に示す全てのギャザリングレプリゼンテーションは、ピクチャ次元、ピクチャアスペクト比、プロファイル、レベルなどの同一の特徴を有するべきであるが、他のレプリゼンテーションへの依存性および高解像度ビデオにおける右上の位置が異なるため、テンプレートに基づくＵＲＬによる単一のレプリゼンテーションを提供することができ、高解像度ビデオの右上の位置に基づいて、所望のギャザリングレプリゼンテーションに属する各セグメントの特定のＵＲＬを導出することができる。

シグナリングの観点からのインスタンス化は、ギャザリングレプリゼンテーションのためのＵＲＬテンプレートの例を示す図８のようになる。

記載されたシグナリングにより、ＵＲＬを構築し、ＲｏＩの位置に基づいて必要なタイルを導出することが可能になる。より具体的には、このギャザリングトラックテンプレートに基づく解決策を使用するために、異なる要素および属性がＭＰＤに追加される。最初に、タイルレプリゼンテーションを異なるＡｄａｐｔａｔｉｏｎＳｅｔに分割してもよく、既存のＳｐａｔｉａｌ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｄｅｓｃｒｉｐｔｏｒ（ＳＲＤ）を使用してもよい。次に、GatheringRepresentationが埋め込まれている場合、更なるAdaptationSetを提供してもよい。GatheringRepresenationsがAdaptationSet内に含まれている場合、他のレプリゼンテーション（「通常のレプリゼンテーション」）は同時に提供され得ない。GatheringRepresentationsの存在を、@GatheringRepresentationsPresentと呼ばれる新しい属性によって（または代替として、この特別なレプリゼンテーションの存在を示すことを可能にするＵＲＮ（ｕｎｉｆｒｏｍ ｒｅｓｏｕｒｃｅ ｎａｍｅ）を追加することによって、記述子、例えばEssentialProperty記述子を使用することにより）、指示してもよい。GatheringRepresentationsと一緒に使用するためにダウンロードできるタイルレプリゼンテーションを含むAdaptationSetは、帰属する@BaseAdaptationSetIdsによって示される。GatheringRepresentations、ならびに通常のレプリゼンテーションで使用されるRepresenationBaseType内の既存の@width属性と@height属性を使用して、指定されたGatheringRepresentationを使用するのに必要なタイルレプリゼンテーションの数を導出することができる。加えて、属性@sameQualityRankingを使用して、異なる性質を有する異なるタイルのレプリゼンテーションをGatheringRepresentationsと一緒に使用すべきでないことを示すことができる。テンプレートＵＲＬは、GatheringRepresentationsのセグメントのＵＲＬを導出するために使用されるので、そのようなＵＲＬテンプレート内に配置できるパラメータを導出するための仕組みが必要である。ＤＡＳＨでは、４つの識別子がテンプレートＵＲＬの置換に使用される。

$Number$と$Time$は、レプリゼンテーション内の所与のセグメントを識別し、そのＵＲＬを生成するために使用される。$RepresentationID$と$Bandwidth$は、レプリゼンテーションを識別するために使用され得る。１つ目は一意の識別子に対応し、２つ目は２つ以上のレプリゼンテーションの間で共有することができる。従って、実際のタイルを含む通常のレプリゼンテーションに基づいて、GatheringRepresentationの$RepresentationID$を導出するルールが必要である。これは、SegmentTemplate要素がGatheringRepresentationと一緒に使用される場合、この識別子を含まなければならないこと、および$RepresentationID$を生成するメカニズムを提供する新しいコンストラクタ（または既存のコンストラクタの拡張子、例えばEssentialProperty記述子）を追加する必要があることを意味する。これは、上記のＸＭＬ構文に、要素idDerivationMechanismによって追加される。１つの例は、例えば、@schemeIdURIが「urn:mpeg:dash:GatheringRepresentationIDderivation:2015」width@valueが１に等しい、に等しい場合であり、タイルレプリゼンテーションの@id属性が連結されて、対応するGatheringRepresentationの$RepresentationID$を生成することを意味する。

記載された方法は、テンプレートベースのレプリゼンテーションを使用することによってＭＰＤのサイズを縮小するのに役立つであろう。しかし、このようなアプローチでは、依然としてクライアント側からギャザリングレプリゼンテーションセグメントに対して追加のＨＴＴＰ ＧＥＴを発行する必要があり、サーバ側から提供される必要がある小さなファイルの数が非常に大きくなることにつながり、サーバおよびキャッシュにとって不利であることが知られている。しかし、毎回、ギャザリングレプリゼンテーションのみがダウンロードされるため、同じ解像度の全てのギャザリングレプリゼンテーションが同じトラックを持つことができ、それにより「ｍｏｏｖ」ボックスを小さく抑えることができるので、「ｍｏｏｖ」ボックス内のトラック数を小さく抑えることになる。

トラック依存関係は「ｍｏｏｖ」ボックス内に、より明示的には「ｔｒａｋ」ボックス内に記述されるため、ｍｏｏｖボックスは全ての依存関係のスーパーセットを含んでいなければならず、そのとき、@dependencyIdは正しいものをＭＰＥＧ－ＤＡＳＨに渡す。これは、「ｔｒｅｆ」ボックス内で通知される全ての従属トラックが毎回は存在しないことにつながり、このことは、複数のコンストラクタが異なるトラックを参照する、明示的な再構成を用いてのみＡＵ再構成が可能であり、（所望のＲｏＩに属する）異なるトラックから異なるコンストラクタを収集する、暗黙の再構成は可能ではないことを意味する。この事実は、複数のギャザリングトラック間のある種の「重複した」シグナリングから、一部のオーバーヘッドにつながるであろう。

図９は、サーバ側でセグメントを収集するための多数の小さなファイルが存在することを示している。

従って、上記の説明は、ソーストラックとギャザリングトラックを別個のレプリゼンテーション、すなわちタイルレプリゼンテーションおよびギャザリングレプリゼンテーションとして別々に扱うことを可能にするために、メディアプレゼンテーション記述１４０（図８）のサイズをどのように縮小するかの可能性を提供したが、図９は、レプリゼンテーションのセグメントに対応する各時間間隔において、クライアント５０がサーバ１０から取得するセグメントの数がかなり多いことを明らかにした。図９は、斜線を使用してギャザリングレプリゼンテーションのセグメントを示すことによって、一方ではタイルレプリゼンテーションの任意のセグメントを、他方ではギャザリングレプリゼンテーションのセグメントを区別している。図９に示すように、クライアント５０は、現在ダウンロードされているギャザリングレプリゼンテーションの各セグメント１４２に対してＮ個のタイルセグメント１４４を取得する必要がある。ここで、Ｎは、現在ダウンロードされているギャザリングレプリゼンテーションが関連するセクションが空間的にカバーするタイルの数である。例えば、図６の例では、現在ダウンロードされているビデオセクション２２_１～２２_４のために、クライアント５０によって４つのセグメントが取得されなければならない。しかし、各セグメント取得は、対応する要求がクライアント５０からサーバ１０に送信されることを必要とするので、これらセグメントがタイルセグメント１４４に比べてかなり小さいという事実を考慮するときには特に、ギャザリングセグメント１５２を追加で送信することを避けることが好ましい。

サーバおよびＣＤＮに有害な多数の小さなファイルの問題を回避するために、別の実施形態は、以下に示すように、各レプリゼンテーションに、従って（サブ）セグメントに２つのトラックを有することで構成される。最初のものは、他のタイルとは独立して再生されたときに、各タイル（または、同じトラックに複数がカプセル化されている場合はタイルグループ）のサンプルをリカバリーする方法のみを記述する典型的なビデオトラックに対応する。図１０を参照して、状況を図９と比較されたい。

ギャザリングトラックにはいくつかのオプションがある。

最初のものは、上述の技術を使用することからなり、これは、所望のＲｏＩの左上タイルの追加トラック（ギャザリングトラック）が必要なトラック依存性のみを示し、明白なＡＵ再構成が以前に定義されたコンストラクタの命令に従うことにより実行され得ることを意味する。ユーザは、どれが左上タイル（図の例では、最初はtrackN+1、それ以降はtrackM）であるかに応じて、１つまたは別のギャザリングトラックを再生し得る。ダウンロードされたギャザリングトラックを参照し、サンプル毎に単一のスライスを仮定したとき、存在するコンストラクタが図１１に示される。

再び図６を参照して状況を説明するために、図１２を参照するが、そこでは図６の例に関連して、セクション２２_１に関心があるときに、クライアント５０が時刻／ピクチャ／サンプルに関して取得する４つのセグメントを示しているが、ここではギャザリングトラックのために余分なレプリゼンテーションを費やさないという概念を使用している。むしろ、ギャザリングトラック３２_１～３２_４は、ソーストラック自体のセグメント内に「隠されている」または「含まれる」。図１２は、クライアント５０によって、ある時刻にソーストラック３０_Ａ、３０_Ｂ、３０_Ｄおよび３０_Ｅの各々から１つずつ取り出された４つのセグメントを示す。上述のように、ギャザリングトラック３２_１～３２_４は、それぞれのギャザリングトラックに対応するセクションの左上のタイルを形成するタイルに対応するソーストラックのセグメント内に含まれている。例えば、ギャザリングトラック３２_１はソーストラック３０_Ａのセグメント内で伝達され、ギャザリングトラック３２_２はソーストラック３０_Ｂのセグメント内で伝達され、ギャザリングトラック３２_３はソーストラック３０_Ｄのセグメント内で伝達され、ギャザリングトラック３２_４はソーストラック３０_Ｅのセグメント内で伝達される。図１２は、クライアント５０が、ギャザリングトラック３２_１が依存しているソーストラックを取得するために、取得するソーストラック３０_Ａ、３０_Ｂ、３０_Ｄおよび３０_Ｅの内の１つのサンプルを示し、ギャザリングトラック３２_１はソーストラック３０_Ａに含まれる。ギャザリングトラック３２_１のサンプル１２８の構成操作３４のシーケンスは、タイルＡ、Ｂ、ＤおよびＥに関して合成を順次実行する。従って、構成操作のシーケンスは、４つの部分１５０_１～１５０_４に細分化される。同様に、ギャザリングトラック３２_２～３２_４の対応する構成命令は、他のソーストラック３０_Ｂ、３０_Ｄおよび３０_Ｅ内に含まれている。クライアントは後者を必要としないが、他のセクション２２_２～２２_４のいずれかに関心を持つクライアントのために含まれている。図１２から分かるように、構成命令の部分の中で、ギャザリングトラック３２_１～３２_４の各々の中にはタイルＥに関連する１つの部分がある。しかし、これらの部分は大変類似しており同一であり、例えば、波括弧１５２を用いて示される下位部分に関して同一である。部分１５２がカバーしていないタイルＥに関する部分の残部は、例えば、参照符号６０ａおよび６０ｂを使用して図３に関して上述した第１のスライスおよびスライスアドレス指示に関連してもよい。冗長性を除去するために、引き続き説明する概念を使用してもよい。しかし、これを説明する前に、ソーストラック３０_Ａ、すなわち対応するセクション２２_１の左上のタイルに関するソーストラックのみの中のギャザリングトラック３２_１の伝達が、例えば部分１５１～１５４が、対応するセクション２２_１によってカバーされるタイル上に分配されるように、変更されてもよいことに留意されたい。その場合、例えば、ギャザリングトラック３２_１は、ソーストラック３０_Ａ、３０_Ｂ、３０_Ｄおよび３０_Ｅに分配される。

図１１および図１２に関して既に説明したように、多くの冗長な情報が存在する。加えて、異なる量のタイルをグループ化するＲｏＩの可能な解像度が複数ある場合、可能性のある解像度毎に１つずつ、より多くのギャザリングトラックが必要になり、そこでは図にマークしたデータがあらゆる場所で冗長であり得る。

更なる実施形態は、前述の冗長情報に関する問題を扱う。その目的のために、暗黙の再構成が考慮され、そこでは各ギャザリングトラックが、コンストラクタインデックスが存在するコンストラクタのアレイで構成される。ビデオ内の対応するトラックの位置に応じて（または「ｔｒｅｆ」依存関係の順序に従って）インデックスが決定され（ｉ）、ＣＩＤＸ＝ｉのコンストラクタのみが実行される。従って、ＮＡＬＵペイロードサイズなどの共通の情報を共有し、いくつかの異なるヘッダの可能性のみを通知することができ、オーバーヘッドの一部が節約される。図１３には、前述のイミディエイトコンストラクタに対するそのようなコンストラクタの構造が示されている（他のエクストラクタも類似の方法で拡張することができる）。

図１４に、この技術を使用するときのサンプル用のコンストラクタを示す。

従って、図１４で分かるように、より少ない冗長データが必要となる。

すなわち、図１２に関して上述した冗長性を避けることの後者の可能性は、以下のように実現される。すなわち、左上の（または他の）タイルに関するソーストラックの中に完全にあるギャザリングトラック３２_１などのギャザリングトラックを、対応するセクション２２_１内で伝達するのではなく、パラメータ化可能なギャザリングトラックが各ソーストラック３０_Ａ～３０_Ｉ内で伝達される。「パラメータ化」の数は、対応するソーストラックが関係するタイルと重なり合うセクションの数に相当する。例えば、ソーストラック３０_Ｅは、各セクション２２_１～２２_４のメンバであるタイルＥに関係する。従って、ソーストラック３０_Ｅ内で伝達されるパラメータ化可能なギャザリングトラックギャザリングトラックは、利用可能な４つのパラメータ化を有し得る。タイルＢ、Ｆ、ＤおよびＨのソーストラック内で伝達されるパラメータ化可能なギャザリングトラックに対しては単に２つのパラメータ化が存在しさえすればよく、タイルＡ、Ｃ、ＧおよびＩのソーストラックにはパラメータ化が存在する必要がないか、または１つだけ存在しさえすればよい。「パラメータ化」は、対応するパラメータ化可能なギャザリングトラックを、実際のギャザリングトラック３２_１～３２_４の対応する部分に変える。例えば、ソーストラック３０_Ｅ内で伝達されるパラメータ化可能なギャザリングトラックは、最初の値を用いてパラメータ化された場合、部分１５０_４になる。従って、クライアント５０は、シーンのセクション２２_１をダウンロードするためにソーストラック３０_Ａ、３０_Ｂ、３０_Ｄおよび３０_Ｅを取得し、各ピクチャまたはサンプルに対して、連続して、ソーストラック３０_Ａ内で伝達された（パラメータ化されたまたはパラメータ化されていない）ギャザリングトラックと、ソーストラック３０_Ｂおよび３０_Ｄに対応してパラメータ化されたギャザリングトラックと、ソーストラック３０_Ｅの適切にパラメータ化されたギャザリングトラックとを実行し、続くピクチャまたはサンプルについても以下同様である。別のパラメータ化を使用して、ソーストラック３０_Ｅの同じパラメータ化可能なギャザリングトラックが、パラメータ化されていない任意のギャザリングトラック３２_２～３２_４に対して、部分１５２を形成することができる。図１３および１４に関して示すように、「インデックス化可能構成命令」を使用して、パラメータ化可能なギャザリングトラックの非同一部分または適合可能部分を形成することができる。適用されたインデックスに応じて、適用されたインデックスに対応するインデックスフィールドを有する、インデックス化可能な命令だけが合成に関与する。しかし、例えばシーンが３６０°のパノラマビューの場合には有意義なので、サポートされたセクションのセットは、図１２に示すものに対して拡大して、あるシーンのエッジから別のシーンのエッジに及ぶものも含むことができることを、繰り返しておく。対応するギャザリングトラックを有する追加セクションは、例えば、タイルセット｛Ｃ、Ａ、Ｄ、Ｆ｝および｛Ｄ、Ｆ、Ｇ、Ｉ｝をカバーするセクションであり得る。この場合、全てのタイルＡ～Ｉのソーストラックのセグメントは、パラメータ化可能なギャザリングトラックを取り込むであろうし、パラメータ設定の数は、トラック３０_{Ｄ，Ｅ，Ｆ}のセグメントに対しては３つ、トラック３０_{Ａ，Ｂ，Ｃ，Ｇ，Ｈ，Ｉ}に対しては２つである。

選択されたＲｏＩに対応するアクセスユニット（ＡＵ）を再構成するために、２つ以上のセグメントのこれらギャザリングトラックのいくつかを使用する必要があることは明らかである。そのような場合、追従すべきギャザリングトラック間の依存関係を知ることが重要である。１つのオプションは、他のギャザリングトラックの依存関係を無視して、左上位置のタイルの「ｔｒｅｆ」依存関係に追従することである。

加えて、２つ以上のＲｏＩ次元（１ピクチャあたりＮ×Ｍタイル、Ｎは水平タイル数、Ｍは垂直タイル数）が許容される場合、この手法を使用しないとトラック数は非常に急速に増加する。この結果、ダウンロードされる必要のある「ｍｏｏｖ」ボックスが多数となり、またはダウンロードされている、全てのトラックが定義された「ｍｏｏｖ」ボックスが非常に大きくなる。レプリゼンテーション毎に複数のトラックを用いた暗示的再構成により（キャッシュやＣＤＮのパフォーマンスに有害な）非常に小さなセグメントをダウンロードする必要を除外できるが、ギャザリングトラックに対して別個のレプリゼンテーションが提供される、上で説明した最初のアプローチと比較して、大きな「ｍｏｏｖ」ボックスまたは多数の「ｍｏｏｖ」ボックスをダウンロードすることが必要となる。

暗黙のＡＵ再構成では、上述の技術を拡張して、追加ＣＩＤＸを追加することによって、同じトラックを異なるＲｏＩ次元に使用することができる。コンストラクタの使用法は、上で説明したものと同じであり、所与のインデックスを持つものだけが実行される。

しかし、このような場合、異なる依存関係を記述することは不可能なので、「ｔｒｅｆ」ボックスを使用して依存関係を導出することはできない。同様に、プロファイル、レベルなどを記述するサンプルエントリは、同じトラックが異なる最終ＲｏＩ解像度に使用され得るため、現在使用されているようには使用できない。

「ｔｒｅｆ」は、各ギャザリングトラックによって使用されて、どのタイルトラックに適用するかを示す。所与のＲＯＩを抽出するために、新しいボックスを追加して、複数のギャザリングトラックを関連付ける機能を果たし得る。このトラックは中心的でなければならず、例えば、「ｍｏｏｖ」ボックスにおけるある種の代替グループ化によって、可能な全てのＲＯＩを記述しなければならない。所与の次元のＲＯＩを再生するには複数の代替例があるが、この代替案の各々はパノラマビデオの所与の位置に対応する。

現在の実施形態は、可能な動作点を記述し、ＡＵ再構成のために同時に使用する必要のある異なるトラックを関連付けることを可能にする、代替サンプルグループの定義を含み、かつ、正しいＮＡＬＵを得るためにコンストラクタアレイで使用する必要があるＣＩＤＸを含む。

そのとき、代替サンプルグループは、プロファイル、レベルを記述することができる。すなわち、それらはサンプルエントリと同じ情報を含まなければならない。

実施形態２では、ギャザリングトラックは、別個のレプリゼンテーションとして提供されると想定している。ギャザリングトラックに非外部レプリゼンテーションが使用される場合（すなわち、それらがタイル自体と同じセグメントに含まれる場合）、異なるタイルを一緒に復号化できることをＭＰＤ内に通知する必要がある。これは、要素を追加するか、または既存のサブセット要素を変更することによって実行できる。ギャザリングトラックを用いて利用可能なＲＯＩの寸法、ならびに集合的にダウンロードされたデータのｍｉｍｅ Ｔｙｐｅは、そのような要素に含まれることになる。

従って、クライアントへの適応型ストリーミングを介したソーストラックおよびギャザリングトラックに関する直近の説明を簡単に要約すると、次のことが明らかになったはずである。ソーストラックおよびギャザリングトラックは、別個のセグメント内で、すなわち、各々が別個のＵＲＬに関連した別個のレプリゼンテーションのセグメント内で伝達されてもよく、従ってソーストラックレプリゼンテーションとギャザリングトラックレプリゼンテーションとは区別することができる。結果として得られる縮小されたセクション固有のビデオデータストリーム５２の特定セグメントに対して、クライアント５０は従って、所望のセクション内のタイルを伝達するソーストラックの各々の対応するセグメントと、所望のセクションに関連するギャザリングトラックの対応するセグメントとをフェッチしなければならない。メディアプレゼンテーション記述またはマニフェストは、これらのギャザリングレプリゼンテーションの、ピクチャサイズ、セグメントテンプレートなどの特徴を別個に記述しながら、ギャザリングレプリゼンテーションのための、相互に異なるＵＲＬベースの明示的なシグナリングを含んでいてもよい。マニフェストファイルサイズを縮小するために、全てのギャザリングレプリゼンテーションに共通に、マニフェスト内にＵＲＬテンプレートを提示してもよい。計算規則は、セクションの空間位置に応じて、ギャザリングトラックのセグメントのＵＲＬの計算法を定義する。セクションは、このマニフェスト縮小コンセプトに従って同じサイズでありシーン位置においてのみ互いに異なる。それに応じて、マニフェストは、ギャザリングレプリゼンテーションの残りのレプリゼンテーション特徴の多くまたは全てを、ピクチャサイズなどのこれらギャザリングレプリゼンテーションに関しては、共通して記述することができる。他の実施形態では、ソーストラックのセグメントのみが相互に異なるＵＲＬに関連付けられ、従って対応するソーストラックレプリゼンテーションのセグメントを形成する。この実施形態によれば、クライアントは、所望のシーンセクション内でスライスを伝達するそれらのソーストラックレプリゼンテーションのセグメントを、特定の所望のセクションに対してフェッチし、これらのセグメントは、所望のセクションに関連するギャザリングトラックを同時に伝達するかまたは含み、ギャザリングトラックは構成命令を含み、フェッチされたセグメント内で伝達されたスライスからセクション固有のビデオデータストリームを合成する。特定の所望のセクション用のギャザリングトラックは、所望のセクション内のタイルに関連するソーストラックの内の所定の１つのセグメント内にのみ伝達されてもよく、このセグメントは、所望のセクション内の所定のタイル位置内のタイル、例えば所望のセクションの左上のタイルに関するスライスを伝達するセグメントなどである。別の実施形態では、各ソーストラックレプリゼンテーションは、そのセグメント内に、ソーストラック固有のパラメータ化可能なギャザリングトラックを含む。ここで、依然として、クライアントは、セクション内のタイルの間で定義されたタイル順で、パラメータ化されたギャザリングトラックに基づいて、セグメント内で伝達されるパラメータ化可能なギャザリングトラックを適切にパラメータ化し、セクション固有のビデオデータストリーム合成を実行することで、所望のセクション内にあるタイルのスライスに関するソーストラックに属するそれらセグメントをフェッチするだけであり、パラメータ化されたギャザリングトラックのサンプル、すなわち所定のピクチャに関する部分は、パラメータ化されたギャザリングトラックの、その時点でタイル順に実行されている後続のサンプルと共に、タイル順で実行される。パラメータ化は、別のインデックスを含むパラメータ化可能なギャザリングトラック内の構成命令がスキップされるように、所定のインデックスを選択することによって実行されてもよい。しかし、上述したように、ソーストラックのセグメント内にギャザリングトラックを詰め込む場合であっても、クライアントには、ギャザリングトラックを別個のレプリゼンテーションとして処理する場合にＭＰＤ内で伝達されるような、ギャザリングトラックに関する情報に類似した情報が組み込まれていてもよい。例えば、マニフェストまたはＭＰＤに対し、いわば対応するギャザリングトラックの存在を示すことによって、複数のタイル、すなわち特定のセクションを一緒に再生できることの保証を付与されてもよく、この情報は、対応するギャザリングトラックを使用して合成によって得られた、セクション固有のビデオデータストリームを復号するのに必要な、プロファイル、レベル、およびティアなどの、セクションに関連する情報を付加的に含んでいてもよい。この意味で、マニフェストは、どのタイルセットを一緒に再生できるかに関する制限をも示しており、すなわち許可されるセクションと許可されないセクションの内の１つを形成する。

上記の概念および実施形態は、ＩＳＯベースのメディアファイル形式をそれに応じて拡張するために、以下のように具体的に実施することができる。ここでは、任意選択的に、独立して復号化可能なＨＥＶＣタイルは、タイルトラックと呼ばれる異なるトラックで伝達される場合がある。タイルトラックは、タイルが属する関連するＨＥＶＣレイヤのＮＡＬユニットを伝達するＨＥＶＣトラックへの「ｔｂａｓ」参照があるビデオトラックである。このようなタイルトラック内のサンプル、またはサンプル記述ボックスはいずれも、ＶＰＳ、ＳＰＳまたはＰＰＳ ＮＡＬユニットを含まない。むしろ、これらのＮＡＬユニットは、対応するタイルトラックの「ｔｂａｓ」トラック参照によって識別されるように、関連するレイヤを含むトラックのサンプル内またはサンプル記述ボックス内に存在する。「ｔｂａｓ」トラック参照によって示されるように、タイルトラックおよび関連レイヤを含むトラックは両方とも、以下で定義されるように、エクストラクタを使用して所望のビットストリームがどのように解釈されるかを指示してもよい。タイルトラック内のサンプルは、１つ以上のタイルの完全なスライスのセットである。ビデオ全体を含むタイルトラックまたはトラックの使用とは関係なく、これらは、上で例を説明したエクストラクタを使用することによって、必要に応じて断片が抽出される参照またはソーストラックとして機能することができ、更なる例をここで説明する。特に、ＩＳＯベースのメディアファイル形式のＨＥＶＣおよびＬ－ＨＥＶＣトラック用のエクストラクタは、参照によってＮＡＬユニットデータを抽出するトラック、すなわちギャザリングトラックのコンパクトな形成を可能にする。エクストラクタは、１つ以上のコンストラクタを含んでもよい。
ａ）サンプルコンストラクタは、参照によって、別のトラックのサンプルからＮＡＬユニットデータを抽出する。
ｂ）サンプル記述コンストラクタは、参照によって、サンプル記述からＮＡＬユニットデータを抽出する。
ｃ）インラインコンストラクタは、ＮＡＬユニットデータを含む。
従って、そのようなエクストラクタは図５ｅまたは図５ｄのように構成してもよく、そこではアレイ長の指示をオフにすることができる。サンプルコンストラクタおよびサンプル記述コンストラクタは、図５ａ～５ｃのように具体化されてもよい。

アグリゲータはエクストラクタを含んでもよく、または参照してもよい。エクストラクタはアグリゲータを参照してもよい。エクストラクタが、エクストラクタを必要とするファイルリーダによって処理されると、含まれているコンストラクタを出現順序で解決するときに生じるバイトによって、エクストラクタは論理的に置き換えられる。アグリゲータ以外は、サンプルコンストラクタによって参照されるバイトはエクストラクタを含んではならない。エクストラクタは別のエクストラクタを直接的または間接的に参照してはならない。当然ながら、エクストラクタによって参照されるデータはそうであってはいけないが、エクストラクタによって参照されるトラック、すなわちソーストラックはエクストラクタを含んでいてもよい。

エクストラクタは、現在のトラックから、またはエクストラクタが「ｓｃａｌ」タイプのトラック参照によって常駐するトラックにリンクされた別のトラックから、データを抽出するための、１つ以上のコンストラクタを含むことができる。解決されたエクストラクタのバイト数は、次の内の１つになる。
ａ）ＮＡＬユニット全体。アグリゲータが参照されると、含まれたバイトおよび参照されたバイトの両方がコピーされる。
ｂ）２つ以上のＮＡＬユニット全体。

どちらの場合も、解決されたエクストラクタのバイトは有効な長さフィールドおよびＮＡＬユニットヘッダで始まる。

サンプルコンストラクタのバイトは、指定された「ｓｃａｌ」トラック参照によって参照されるトラック内の単一の識別されたサンプルからのみコピーされる。このアラインメントはデコード時間に基づいて行われる。すなわち、サンプル化時間テーブルのみを使用し、その後のサンプル数のカウントされたオフセットによって行われる。エクストラクタはメディアレベルの概念であり、従っていかなる編集リストも考慮される前にデスティネーショントラックに適用される。当然ながら、２つのトラック内の編集リストは同一となるように選択することができる。

エクストラクタの構文例を以下に示す。
class aligned(8) Extractor () {
NALUnitHeader();
do {
unsigned int(8) constructor_type;
if( constructor_type == 0 )
SampleConstructor();
else if( constructor_type == 1 )
SampleDescriptionConstructor();
else if( constructor_type == 2 )
InlineConstructor();
} while( !EndOfNALUnit() )
}

上記の構文例の意味に関しては、同じものが次のようになる。
NALUnitHeader()は、ＩＳＯ／ＩＥＣ ２３００８－２ ＮＡＬ ｕｎｉｔｓの最初の２バイトを示すことができる。nal_unit_typeは、ＩＳＯ／ＩＥＣ ２３００８－２ ｖｉｄｅｏでは４９に設定される。forbidden_zero_bitは、ＩＳＯ／ＩＥＣ ２３００８－２で指定されているように設定することができる。他のフィールドは、nuh_layer_idおよびnuh_temporal_id_plus1に関する場合があり、後で指定するように設定され得る。constructor_typeは、後続のコンストラクタを指定する。SampleConstructor、SampleDescriptionConstructor、およびInlineConstructorは、それぞれ０、１、２に等しいconstructor_typeに対応する。constructor_typeの他の値は、他のコンストラクタのために予約されていることもあるが、そうでないこともある。EndOfNALUnit()は、このエクストラクタでデータが更に続くときに０（偽）を返す関数である。それ以外の場合は１（真）を返す。

サンプルコンストラクタの構文については、次の例を参照されたい。
class aligned(8) SampleConstructor () {
unsigned int(8) track_ref_index;
signed int(8) sample_offset;
unsigned int((lengthSizeMinusOne+1)*8)
data_offset;
unsigned int((lengthSizeMinusOne+1)*8)
data_length;
}

上記のサンプルコンストラクタ構文の意味は次のようになる。
track_ref_index：図５ｂおよび図５ｃのＴＲＩのような参照トラックを指す。
sample_offset：参照トラック、すなわち所望のピクチャＩＤに対応する参照トラックの一部の先頭で「サンプル」をインデックス化する。すなわち、sample_offsetは図５ｂのＳＯに対応し、
data_offset：コピーされる参照サンプル内の最初のバイトのオフセット。そのサンプル内のデータの最初のバイトで抽出が開始された場合、オフセットの値は０をとる。すなわち、data_offsetは、図５ｂおよび５ｃのデータオフセットに対応し、
data_length：コピーされるバイト数。このフィールドが値０をとる場合、data_offsetはＮＡＬ単位長フィールドの先頭を参照し、単一の参照ＮＡＬユニット全体がコピーされる（すなわち、コピーされる長さはdata_offsetによって参照される長さフィールドから取得され、アグリゲータの場合はadditional_bytesフィールドによって補完される）。例えば、図５ｂおよび５ｃに提示されたデータ長を比較する。

２つのトラックが異なるlengthSizeMinusOne値を使用する場合、抽出されたデータはデスティネーショントラックの長さフィールドのサイズに適応するために再フォーマットする必要があることに留意されたい。

サンプル記述コンストラクタの構文については、次の例を参照されたい。
class aligned(8) SampleDescriptionConstructor () {
unsigned int(8) length;
unsigned int(8) track_ref_index;
int(8) sample_description_index;
fieldSize = (length - 2) / 2;
unsigned int(fieldSize) data_offset;
unsigned int(fieldSize) data_length;
}

上記のサンプル記述コンストラクタ構文の意味は次のようになる。
length：このフィールドに続くSampleDescriptionConstructorに属するバイト数。長さの値は、偶数で、４以上、１０以下でなければならない。それは図５ｂおよび図５ｃのフィールドＤＦＬに対応する。
track_ref_indexは、「ｔｒｅｆ」ボックス内に列挙された「ｓｃａｌ」タイプのトラック参照のインデックスを識別する。値０は、このコンストラクタが見つかった現在のトラックを示す。値１は最初のトラック参照を示す。track_ref_indexの値は、トラック参照の数を超えてはならない。それは図５ｂおよび図５ｃのフィールドＴＲＩに対応する。
sample_description_indexは、「ｓｔｓｄ」ボックスに列挙されたサンプル記述のインデックスを識別する。sample_description_indexの値は、ゼロであってはならなく、サンプルエントリの数を超えてもならない。それは図５ｃのフィールドＳＯに対応する。
data_offsetは、サンプル記述からコピーされるブロックの最初のデータバイトのアドレス指定に使用される符号なしのオフセットである。値０は、参照されるサンプル記述の最初のバイトでコピーが開始されることを意味する。それは図５ｂおよび図５ｃのフィールド、Ｄａｔａ Ｏｆｆｘｅｔに対応する。
data_lengthは、参照トラックのサンプル記述からコピーされるデータブロック長を指定する。０という値は、参照されるサンプル記述からバイトがコピーされないことを意味する。data_lengthは、参照されるサンプル記述のサイズを超えてはならない。それは図５ｂおよび５ｃのフィールドデータ長に対応する。

インラインコンストラクタ構文については、次の例を参照されたい。
class aligned(8) InlineConstructor () {
unsigned int(8) length;
unsigned int(8) inline_data[length];
}

上記のインラインコンストラクタのコンストラクタ構文の意味は次のようになる。
length：このフィールドに続くInlineConstructorに属するバイト数。長さの値は０よりも大きくなければならない。０に等しい長さの値は予約されている。それは図５ａのフィールドＤＦＬに対応する。
inline_data：インラインコンストラクタを解決するときに返されるデータバイト。それは図５ａに提示されたフィールドであるＤａｔａ Ｆｉｌｅｄに対応する。

アグリゲータとエクストラクタは両方とも、ＩＳＯ／ＩＥＣ ２３００８－２に指定されているようにＮＡＬユニットヘッダを使用してもよい。エクストラクタによって抽出された、またはアグリゲータによってアグリゲートされたＮＡＬユニットは全て、アグリゲータまたはエクストラクタのコンテンツを再帰的に検査することによって参照されるまたは含まれるＮＡＬユニットである。フィールドnuh_layer_idおよびnuh_temporal_id_plus1は、以下のように設定してもよい。nuh_layer_idは、アグリゲートされた、または抽出された全てのＮＡＬユニット内のフィールドの最低値に設定してもよい。nuh_temporal_id_plus1は、アグリゲートされた、または抽出された全てのＮＡＬユニット内のフィールドの最低値に設定してもよい。

すなわち、シーンの空間的に可変なセクションをクライアントにストリーミングするために、上記のいずれかのやり方でビデオデータを概念化することができる。ビデオデータは、ファイル形式でフォーマットされ、１つ以上のソーストラックを含み、各ソーストラックは、ビデオの、シーン全体をキャプチャしたピクチャが、その中で空間的に細分化されているタイルの内の対応する１つに関連付けられており、ソーストラックは、各スライスが１つだけのタイルを符号化するように、ビデオのピクチャがその中で符号化されている、ビデオデータストリームのスライスを、ソーストラック内で分配しており、かつビデオデータは１つ以上のギャザリングトラックのセットを含み、そのギャザリングトラックの各々は、タイルの対応するサブセットによって形成されたセクションの複数の位置の内の対応する１つに関連付けられ、かつ対応する位置におけるシーンのセクションを示すピクチャがその中で符号化されている、セクション位置固有のビデオデータストリームの合成を示す構成命令を含む。構成命令は、図５ａ～図５ｃ、もしくは図５ａ～図５ｅ、または直前に提示した例の中から選択してもよい。

以下の実施形態は、ＲｏＩプリフェッチのためのヒントをクライアントに提供するための概念に関する。

現在、高解像度および広角のビデオが益々普及している。それらは１８０°～３６０°のパノラマや球面ビデオを含む。これらのビデオのサイズが大きくなるにつれて、ビデオ全体を高解像度で送信することは実用的ではなくなる。異なるストリーミング方法では、例えば、ビデオを複数のタイルに分割し、ユーザの関心領域（ＲｏＩ）をカバーするもののみを送信することを探索している。他の方法は、品質、解像度などの変化する特性で符号化されるビデオの領域を送信し、ユーザに送信されるビデオビットレートを最適化することを伴ってもよい。

上記のようなこれらアプローチのいずれかにおいて、その発想は、ビデオ送信の最適化はユーザの好みに基づいて行われ、ユーザに示されるビデオの一部は高品質でダウンロードされ、一方でユーザ対話によってユーザに示され得る他の（ＲｏＩとは考えられていない）一部は、プリフェッチとして同じまたは別の品質でダウンロードすることができるということである。

ＤＡＳＨ規格は、空間的関係記述子を使用することによって、ビデオのそれら提供された部分の空間的関係のシグナリングを可能にする。この記述子は、提供されるコンテンツの関係を、それらがカバーするビデオの空間領域の観点で、ユーザが理解することを可能にするが、ＲｏＩシグナリングに関してギャップが存在する。ユーザは、例えばビデオ内の時空間的な活動に関する詳細な情報を有していない。［１］のようないくつかの作品は、ビデオのＲｏＩの時空間的な特性を知ることが、より効率的な送信方式につながり得ることを示しており、ほとんどのユーザにとって関心のある主要な活動をカバーする、ビデオの重要な空間領域を、ＲｏＩ特性を考慮しない送信方式と比べて、より高い品質でダウンロードすることができる。

更に、実用上の配慮として、そのようなサービスにおけるストリーミングセッションの開始を分析することができる。実際のメディアデータのダウンロードに関する決定を下す前に、クライアントがＲｏＩ特性を知ることが不可欠である。従って、ＶＯＤセッションの開始またはライブチューンインでは、ＲｏＩは最適な品質で要求され、実際にユーザに表示されている。

Ｒｏｌｅ－Ｍａｉｎシグナリングを使用するＭＰＤベースのソリューションには、ＭＰＤサイズが不釣り合いに増加するという欠点があり、ライブストリーミングサービスでは効率的に使用できない。なぜなら、これは、必要以上に頻繁なＭＰＤのプリング、またはクライアントでＭＰＤの更新をトリガする新しいＭＰＤを要求する必要があるという一種の指示に起因する追加の遅延、のいずれかを必要とするからである。

本明細書で以下に説明する実施形態は、１つ以上のＲｏＩの位置およびその移動をシグナリングするために使用する仕組み、すなわちレプリゼンテーションまたはタイルへの時間の経過に対するマッピングを提案する。
－ 「ｅｍｓｇ」ファイル形式ボックスを使用した帯域内ソリューション：ＶｏＤに適している。このボックスを伝達する各セグメントは、次のセグメントにおけるＲｏＩの空間位置を指示し、それにより、クライアントは、例えばその対応するレプリゼンテーションのプリフェッチのために利用可能な帯域幅のより多くを使用することによって、このボックスを適切に使用することができる。ヒントをプリフェッチするには適しているが、ＲＯＩを開始するには適していない。
－ ＳＡＮＤメッセージを使用した帯域外ソリューション：ライブサービスに適している。そのような環境では、「ｅｍｓｇ」ボックスを追加できるためには、処理されるべき次のセグメントを待つ必要があるので、コンテンツ生成部が遅延を増加させるので、「ｅｍｓｇ」は最良の解決策ではないかもしれない。加えて、この情報は、ＶｏＤコンテキストにおける再生開始（またはシーキング）に使用することができる。ヒントをプリフェッチしＲＯＩを開始するのに適している。
－ 更なるオプションは、位置（ｘ、ｙ）および次元（幅、高さ）を宣言することによって１つ以上のＲｏＩが記述される異なる時間間隔を記述する、ファイルの先頭のボックスである。

「ｅｍｓｇ」を使用する概念は次のようになる。

ＤＡＳＨイベントメッセージボックスは、ＭＰＥＧ ＤＡＳＨで次のように定義されている。
aligned(8) class DASHEventMessageBox extends FullBox(‘emsg’, version = 0, flags = 0){
string scheme_id_uri;
string value;
unsigned int(32) timescale;
unsigned int(32) presentation_time_delta;
unsigned int(32) event_duration;
unsigned int(32) id;
unsigned int(8) message_data[];
}
}

次に、提案されたＲｏＩシグナリングは、メインのＲｏＩ座標を通知するscheme_id_uriを追加する。ＲｏＩ特性を識別するために、URN「urn:mpeg:dash:RoIchangeEvent:2016」を定義することができる。代替として、既存のスキーム「urn:mpeg:dash:event:2012」を拡張し、新しい値を追加することもできる。

このスキーマを使用するイベントの場合、`emsg`. message_data[]’フィールドには、以下に定義するDASHRoIchangeEvent構造が含まれる。
aligned(8) struct DASHRoIchangeEvent
{
if ( `emsg`.value == 1 ) //single RoI
{
unsigned int(32) source_id; // Refers to the source_id in MPD in Sect. H.2
unsigned int(32) x; // horizontal position of RoI
unsigned int(32) y; // vertical position of RoI
unsigned int(32) width; // width position of RoI
unsigned int(32) height; // height position of RoI
}
if ( `emsg`.value == 2 ) //multiple RoIs
{
unsigned int(32) source_id; // Refers to the source_id in MPD in Sect. H.2
unsigned int(8) num_RoIs; // Number of RoIs present
for (i=0;i<numRoIs;i++){
unsigned int(32) x_i; // horizontal position of RoI
unsigned int(32) y_i; // vertical position of RoI
unsigned int(32) width_i; // width position of RoI
unsigned int(32) height_i; // height position of RoI
}
}
}

この情報は、ダウンロードされる次のセグメントに関連する。代替として、emsg.valuesを更に追加することにより、２つ以上のセグメントのＲｏＩを示す別のバージョンを開発することができる。

ＳＡＮＤを使用する概念は次のようになる。

所定の時間にＲｏＩを指示する、新たなＰａｒａｍｅｔｅｒｓ Ｅｎｈａｎｃｉｎｇ Ｒｅｃｅｐｔｉｏｎ（ＰＥＲ、すなわち、ＤＡＳＨ Ａｗａｒｅ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔ（ＤＡＮＥ）からＤＡＳＨクライアントへ送信されるメッセージ）が定義される。このメッセージは、先に「ｅｍｓｇ」の場合に定義されたメッセージに類似している。

中央ボックスを、例えば、ＲｏＩの時間的変化を記述する「ｍｏｏｖ」内で使用する概念は以下のように説明することができる。

RoIdescriptionbox ‘roid’
aligned(8) class SegmentIndexBox extends FullBox(‘sidx’, version, 0) {
unsigned int(32) source_ID;
unsigned int(32) timescale;
if (version==0) {
unsigned int(32) earliest_presentation_time; // earliest presentation time for which the box
describes the RoIs
}
else {
unsigned int(64) earliest_presentation_time;
}
unsigned int(16) reserved = 0;
unsigned int(16) RoIs_count;
for(i=1; i <= RoIs_count; i++) //number of RoIs described in time
{
unsigned int(32) RoI_duration;
unsigned int(32) x;
unsigned int(32) y;
unsigned int(32) width;
unsigned int(32) height;
}
}

同様に、メッセージを変更して、以下に示すようにパラメータを追加することにより複数のＲｏＩを組み込むことができる。
…
for(i=1; i <= RoIs_count; i++) //number of RoIs intervals described
{
unsigned int(8) RoI_count_per_interval
for(i=j; j <= RoIs_count; j++) //number of RoIs described for each of intervals in time
{
unsigned int(32) RoI_duration;
unsigned int(32) x;
unsigned int(32) y;
unsigned int(32) width;
unsigned int(32) height;
}
}

上で概説した概念に従って実施形態を説明するために、以下の図を参照する。図１５は、ビデオストリーミングサーバ２００およびクライアント２５０を示す。単に代替として、サーバ２００およびクライアント２５０は、図１～図１５の任意の上記の実施形態に準拠するように実現されてもよい。いずれにしても、ビデオストリーミングサーバ２００は、シーンを表し、かつ、関心領域２７０の位置を指示する情報２６０を、その位置が時間的に変化する形で伴って、サーバ２００からクライアント２５０にストリーミングされる、ビデオストリーム２１６を伴うように構成されている。すなわち、ビデオストリーミングサーバ２００は、特定のシーンを表すビデオデータを利用可能である。ビデオデータは、例えばその中に符号化されたビデオ２８０を有し、そのピクチャ２９０の各々がシーンを示してもよい。ビデオ２８０に関するビデオデータは、図１～図１５に関して上で概説したやり方で概念化してもよい。すなわち、サーバ２００は、取得されたビデオストリーム２１６が、図１～図１５の用語を使うと、セクションを表す、関心領域２７０にのみ関係するように、クライアント２５０がサーバ２００からビデオストリーム２１６を取得することができるように構成されてもよい。代替として、サーバ２００は、ビデオデータストリーム２１６がシーンに関する情報を完全に伝達するように、ビデオデータストリーム２１６の取得を利用可能にするだけである。しかし、後者の場合、クライアント２５０は、例えば、ビデオストリーム２１６のセグメントを異なる順序で取得またはフェッチすることが許容される。例えば、クライアント２５０は、ビデオ２８０の特定の時間的部分に関連しかつシーンの特定の空間領域に関連するセグメントを最初に、同じ時間的部分であるが別の空間的領域のセグメントを取得する前に、フェッチする機会を提供することができる。サーバ２００およびクライアント２５０が、図１および図２のサーバ１０およびクライアント５０に準拠したやり方で具体化され得る可能性を述べることによって明らかになったように、図１５のビデオストリーム２６０は、図１のストリーム１６に対応するストリームであり得る。

図１５は、情報２６０が関心領域２７０の位置を時間と共に変化させることを示す。このような情報２６０がなければ、クライアント２５０は、現在時間のセグメント内のこのシーンの最も興味深い部分を含む可能性が最も高い、このシーンの特定の現在時間のセグメントをフェッチすることができない。しかし、プリフェッチの目的のために、ビデオストリーム２１６の取得を適切に開始する目的のために、ビデオ２８０の空間的に異なる領域に関してクライアントのユーザによって引き起こされるフェッチ要求を叶えるために、クライアント２５０は、できる限り早期に情報２６０を手元に有し、しかし既にフェッチされたビデオ２８０の時間セグメントを参照する可能性はできる限り低いようにすることが好ましい。

一実施形態によれば、ビデオストリーミングサーバ１０は、ビデオストリームのファイル形式ボックス内で情報２６０を伝達するように構成されている。すなわち、ビデオストリーム２１６は、ファイル形式に従ってサーバ２００からクライアント２５０に伝達され、情報２６０はこのようにフォーマットされたビデオストリーム２１６内に埋め込まれる。当然ながら、クライアント２５０は、ビデオストリーム２１６の取得を「盲目的に」、すなわち関心領域２７０の位置に関するいかなる情報２６０もなく開始しなければならない。代替として、関心領域２７０に関する別の情報、すなわち、ビデオの取得を開始した時点の関心領域の位置に関する情報は、サーバ２００によって、クライアント２５０からサーバ２００への適切な要求に応じて、サーバ２００から送信されるメディアプレゼンテーション記述内に、またはビデオストリーム２１６の最初のセグメント内に含めることができる。このようにして、クライアント２５０は、そのときに使用していた情報２６０を用いて、メディアプレゼンテーション記述の適切な情報から、関心領域２７０の位置に関する第１のヒントを取得する機会を得て、それによりビデオ２８０の将来の時間セグメントをプリフェッチすることをスケジュールする。

更に既に上述した代替例によれば、ビデオストリーミングサーバ２００はＤＡＳＨサーバであってもよく、ビデオストリーム２１６のファイル形式ボックス内の代わりに、ＳＡＮＤメッセージによって帯域外に情報２６０を伝達するように構成されていてもよい。両方の概念を使用して、ビデオストリーミングサーバ２００は、関心領域２７０の位置を更新するように、情報２６０を断続的に更新することができる。特に、ビデオストリーミングサーバは、クライアント要求から独立した時間インスタンスで、情報２７０の断続的な更新をスケジュールすることができる。すなわち、クライアント２５０は、情報２６０の更新要求をサーバ２００に送信する必要はない。むしろ、サーバ２００は、それ自体で情報２６０の更新または再送信を開始する。

加えてまたは代替として、サーバ２００は、情報２６０もまた、関心領域２７０の位置のやがて来る変化をスケジュールするように、ストリーミングの開始時に情報２６０を伝達するように構成することさえできる。例えば、ビデオ２８０のビデオコンテンツは、サーバ側で知ることができ、従って、サーバ２００は、例えば、マニフェストまたはメディアプレゼンテーション記述に情報２６０を提供し、それにより情報２６０が、時間的に変化する形で関心領域２７０の位置を指示する、すなわち、ビデオ２８０の時間長さの間に、スケジュールされた時間インスタンスで位置が変化するような形で関心領域２７０の位置を指示する。 代替として、サーバ２００は例えば、関心領域２７０の位置が時間的に変化する形で情報２６０が指示する形で、典型的には、要求しＭＰＤを検査した後にクライアントがフェッチした初期セグメントに、情報２６０を提供する。後者の場合、上述の中央ボックスまたはRoIdescriptionBoxを使用してもよい。

情報２６０の存在または可用性の指示は、ＭＰＤにおいてクライアントに指示され得る。情報２６０の存在またはビデオストリーム２１６が情報２６０を伴うという事実は、クライアントによる対応する要求に依存するようにすることができる。従って、クライアントによって要求されていなければ、サーバ２００は付随物をスキップすることができる。情報２６０が、ＭＰＤ（「ｅｍｓｇ」）または初期セグメント（「ｒｏｉｄ」変形）に含まれる情報などの帯域内情報である場合、手順は、例えば、クライアントが利用可能性の対応する指示を含むＭＰＤを要求することで始まり、続いて、クライアントが情報２６０の要求と共にＭＰＤを新たに要求するか、またはクライアントが情報２６０の存在を要求すると共にサーバから初期セグメントを要求する。類似の方法で、帯域外の情報２６０の存在は、クライアントからの対応する要求に依存させることができる。クライアントの希望に応じて、サーバはＳＡＮＤメッセージを介してＲｏＩ情報２６０をクライアントに送信するか、または送信しない。

サーバ１０およびクライアント５０がハードウェア、ファームウェアまたはソフトウェアで具体化できることに言及した上述の説明と同様に、サーバ２００およびクライアント２５０は、同様に、すなわちハードウェア、ファームウェアまたはソフトウェアの形態で実現されてもよい。

いくつかの態様は装置との関連において記載されているが、これらの態様はまた、ブロックまたはデバイスが、方法ステップまたは方法ステップの特徴に対応するような、対応する方法の記載を表していることは明白である。同様に、方法ステップとの関連において記載される態様もまた、対応するブロックまたは項目、もしくは対応する装置の特徴に関する記載を表す。いくつかのまたは全ての方法ステップは、例えばマイクロプロセッサ、プログラム可能なコンピュータ、または電子回路のようなハードウェア装置によって（またはこれを使用して）実行されてもよい。いくつかの実施形態において、最も重要な方法ステップの１つ以上がこのような装置によって実行されてもよい。

本発明の符号化されたデータストリームまたは信号は、デジタル記憶媒体に格納することができ、もしくはインターネットのような無線伝送媒体または有線伝送媒体などの伝送媒体を通じて伝送することができる。これまで、データストリームへのいくつかの情報の挿入または符号化が説明されてきたが、この説明は、結果としてのデータストリームが対応する情報、フラグのシンタックス要素などを含むという開示と並行して理解すべきである。

特定の実装要件に応じて、本発明の実施形態は、ハードウェアまたはソフトウェアに実装することができる。実装は、電子的に読み取り可能な制御信号が格納されたデジタル記憶媒体、例えばフロッピーディスク、ＤＶＤ、Ｂｌｕ－Ｒａｙ、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭまたはＦＬＡＳＨメモリを使用して実行することができ、これらは、対応する方法が実行されるようにプログラム可能なコンピュータシステムと協働する（または協働することができる）。従って、デジタル記憶媒体はコンピュータ読み取り可能であってもよい。

本発明によるいくつかの実施形態は、本明細書に記載された方法の内の１つが実行されるように、プログラム可能なコンピュータシステムと協働することができる、電子的に読み取り可能な制御信号を有するデータ担体を含む。

一般に、本発明の実施形態は、プログラムコードを有するコンピュータプログラム製品として実現することができ、プログラムコードは、コンピュータプログラム製品がコンピュータ上で動くときに、方法の内の１つを実行するように動作可能である。プログラムコードは、例えば、機械読み取り可能な担体に格納することができる。

他の実施形態は、機械読み取り可能な担体に格納され、本明細書に記載された方法の内の１つを実行するためのコンピュータプログラムを含む。

換言すれば、本発明の方法の実施形態は、コンピュータプログラムがコンピュータ上で動くときに、本明細書に記載された方法の内の１つを実行するためのプログラムコードを有するコンピュータプログラムである。

従って、本発明の方法の更なる実施形態は、本明細書に記載された方法の内の１つを実行するためのコンピュータプログラムが記録されて含まれているデータ担体（またはデジタル記憶媒体またはコンピュータ読み取り可能媒体）である。そのデータ担体、デジタル記憶媒体、または記録された媒体は、典型的には有形および／または非一時的である。

従って、本発明の方法の更なる実施形態は、本明細書に記載された方法の内の１つを実行するためのコンピュータプログラムを表すデータストリームまたは信号シーケンスである。データストリームまたは信号シーケンスは、例えばインターネットを介して、例えばデータ通信接続を介して転送されるように構成されていてもよい。

更なる実施形態は、本明細書に記載された方法の内の１つを実行するように構成または適合された処理手段、例えばコンピュータまたはプログラム可能論理デバイスを含む。

更なる実施形態は、本明細書に記載された方法の１つを実行するためのコンピュータプログラムがインストールされたコンピュータを含む。

本発明による更なる実施形態は、本明細書で説明される方法の１つを実行するためのコンピュータプログラムを受信機に伝送するように構成されている装置またはシステムを含む（例えば、電子的にまたは光学的に）。受信機は、例えば、コンピュータ、モバイル機器、メモリデバイス等であってもよい。この装置またはシステムは、例えば、コンピュータプログラムを受信機に転送するためのファイルサーバを備えてもよい。

いくつかの実施形態では、プログラム可能論理装置（例えばフィールド・プログラマブル・ゲートアレイ）を使用して、本明細書に記載された方法の機能の一部または全てを実行することができる。いくつかの実施形態では、フィールドプログラマブルゲートアレイは、本明細書に記載された方法の内の１つを実行するためにマイクロプロセッサと協働することができる。一般に、これらの方法は、好ましくは、任意のハードウェア装置によって実行される。

本明細書に記載の装置は、ハードウェア装置を使用して、またはコンピュータを使用して、またはハードウェア装置とコンピュータの組み合わせを使用して実装されてもよい。

本明細書に記載された装置、または本明細書に記載された装置の任意の構成要素は、少なくとも部分的にハードウェアおよび／またはソフトウェアで実現されてもよい。

本明細書に記載の方法は、ハードウェア装置を使用して、またはコンピュータを使用して、またはハードウェア装置とコンピュータの組み合わせを使用して実行されてもよい。

本明細書に記載された装置、または本明細書に記載された装置の任意の構成要素は、少なくとも部分的にハードウェアおよび／またはソフトウェアによって実行されてもよい。

上述の実施形態は、本発明の原理の単なる例示である。本明細書に記載された構成および詳細の変更形態および変形形態は、当業者には明らかとなることが理解される。従って、ここに記載された特許請求の範囲によってのみ限定され、本明細書の実施形態の記載および説明によって示される特定の詳細によっては限定されないことが意図される。

Claims (25)

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. 請求項２４に記載の方法を、コンピュータ上で動いているときに実行するためのプログラムコードを有するコンピュータプログラム。

Images