特許 6675475 メディア・ストリームに基づくタイルド・ビデオの形成

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

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

(11)【特許番号】6675475

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

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

(54)【発明の名称】メディア・ストリームに基づくタイルド・ビデオの形成

(51)【国際特許分類】

   H04N 21/266 20110101AFI20200323BHJP

   H04N 21/235 20110101ALI20200323BHJP

   H04N 21/462 20110101ALI20200323BHJP

   H04N 21/431 20110101ALI20200323BHJP

   H04N 19/70 20140101ALI20200323BHJP

【ＦＩ】

   H04N21/266

   H04N21/235

   H04N21/462

   H04N21/431

   H04N19/70

【請求項の数】12

【全頁数】96

(21)【出願番号】特願2018-509765(P2018-509765)

(86)(22)【出願日】2016年8月19日

(65)【公表番号】特表2018-530210(P2018-530210A)

(43)【公表日】2018年10月11日

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

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

(87)【国際公開日】20170223

【審査請求日】2018年4月20日

(31)【優先権主張番号】15181677.4

(32)【優先日】2015年8月20日

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

【前置審査】

(73)【特許権者】

【識別番号】512287702

【氏名又は名称】コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100106208

【弁理士】

【氏名又は名称】宮前 徹

(74)【代理人】

【識別番号】100120112

【弁理士】

【氏名又は名称】中西 基晴

(74)【代理人】

【識別番号】100173565

【弁理士】

【氏名又は名称】末松 亮太

(72)【発明者】

【氏名】ヴァン・ブランデンブルク，レイ

(72)【発明者】

【氏名】トーマス，エマニュエル

(72)【発明者】

【氏名】ヴァン・デーフェンテル，マティス・オスカー

【審査官】 冨田 高史

(56)【参考文献】

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

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

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

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

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

Ｈ０４Ｎ １９／００ − １９／９８

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

【請求項1】

複数のタイル・ストリームからデコード・ビデオ・ストリームを形成する方法であって、
−クライアント・コンピュータが、第１組のタイル・ストリーム識別子から、第１タイル位置と関連付けられた少なくとも第１タイル・ストリーム識別子を選択し、第２組のタイル・ストリーム識別子から、第２タイル位置と関連付けられた少なくとも第２タイル・ストリーム識別子を選択するステップであって、前記第１タイル位置が前記第２タイル位置とは異なる、ステップと、
前記第１組のタイル・ストリーム識別子が、第１ビデオ・コンテンツの少なくとも一部のエンコード・メディア・データを含むタイル・ストリームを識別し、前記第２組のタイル・ストリーム識別子が、第２ビデオ・コンテンツの少なくとも一部のエンコード・メディア・データを含むタイル・ストリームを識別し、前記第１および前記第２ビデオ・コンテンツが異なるビデオ・コンテンツであり、１つの組の各タイル・ストリーム識別子が異なるタイル位置と関連付けられ、
タイル・ストリームが、メディア・データと、前記タイル・ストリームのメディア・データをタイルド・ビデオ・フレームにデコードすることをデコーダに指令するように構成されたタイル位置情報とを含み、タイルド・ビデオ・フレームが、前記タイル位置情報によって示されるタイル位置に少なくとも１つのタイルを含み、タイルが前記タイルド・ビデオ・フレームの画像領域におけるビジュアル・コンテンツの小区域を表し、
−前記クライアント・コンピュータが、前記選択した第１タイル・ストリーム識別子に基づいて、１つ以上のネットワーク・ノードに、第１タイル位置と関連付けられた第１タイル・ストリームを前記クライアント・コンピュータに送信することを要求し、更に前記選択した第２タイル・ストリーム識別子に基づいて、第２タイル位置と関連付けられた第２タイル・ストリームを前記クライアント・コンピュータに送信することを要求するステップと、
−前記クライアント・コンピュータが、少なくとも前記第１および第２タイル・ストリームのメディア・データおよびタイル位置情報を、前記デコーダによってデコード可能なビットストリームに組み入れるステップと、
−前記デコーダが、前記ビットストリームをタイルド・ビデオ・フレームにデコードすることによってデコード・ビデオ・ストリームを形成するステップであって、各タイルド・ビデオ・フレームが前記第１タイル位置において、前記第１タイル・ストリームのメディア・データのビジュアル・コンテンツを表す第１タイルと、前記第２タイル位置において、前記第２タイル・ストリームのメディア・データのビジュアル・コンテンツを表す第２タイルとを含む、ステップと、
を含む、方法。

【請求項2】

請求項１記載の方法において、前記第１および第２タイル・ストリームのメディア・データが、タイルド・ビデオ・フレームをサポートするコデックに基づいて独立してエンコードされ、および／または前記タイル位置情報が、更に、前記第１および第２タイルが、タイル格子に基づいて空間的に配列された非重複タイルであることを前記デコーダに知らせる、方法。

【請求項3】

請求項１または２記載の方法であって、更に、複数の組のタイル・ストリーム識別子、または複数の組のタイル・ストリーム識別子を判定するための情報を含む少なくとも１つのマニフェスト・ファイルを供給するステップを含み、各１組のタイル・ストリーム識別子が、異なる所定のビデオ・コンテンツおよび複数のタイル位置と関連付けられる、ステップと、
前記マニフェスト・ファイルに基づいて、前記第１および第２タイル・ストリーム識別子を選択するステップと、
を含む、方法。

【請求項4】

請求項３記載の方法において、前記マニフェスト・ファイルが１つ以上のアダプテーション・セットを含み、アダプテーション・セットが１組のリプリゼンテーションを定め、リプリゼンテーションがタイル・ストリーム識別子を含み、
アダプテーション・セットにおける各タイル・ストリーム識別子が、空間関係記述（ＳＲＤ）記述子と関連付けられ、前記空間関係記述子が、前記タイル・ストリーム識別子と関連付けられたタイル・ストリームのビデオ・フレームのタイルのタイル位置についての情報を前記クライアント・コンピュータに知らせ、または、
アダプテーション・セットにおける全てのタイル・ストリーム識別子が、１つの空間関係記述（ＳＲＤ）記述子と関連付けられ、前記空間関係記述子が、前記アダプテーション・セットにおいて識別されたタイル・ストリームのビデオ・フレームのタイルのタイル・位置について、前記クライアント・コンピュータに知らせる、方法。

【請求項5】

請求項３〜４のいずれか１項記載の方法において、前記第１および第２の判定されたタイル・ストリーム識別子が、それぞれ、第１および第２ユニフォーム・リソース・ロケータ（ＵＲＬ）（の一部）であり、前記第１および第２タイル・ストリームのビデオ・フレームにおけるタイルのタイル位置についての情報が、前記タイル・ストリーム識別子内に埋め込まれる、方法。

【請求項6】

請求項３〜５のいずれか１項記載の方法において、前記マニフェスト・ファイルが、更に、前記タイル・ストリームのビデオ・フレームにおける少なくとも１つのタイルのタイル位置についての情報が埋め込まれたタイル・ストリーム識別子を、前記クライアント・コンピュータが生成することを可能にするタイル・ストリーム識別子テンプレートを含む、方法。

【請求項7】

請求項３〜６のいずれか１項記載の方法において、前記マニフェスト・ファイルが更に、１つ以上のタイル・ストリーム識別子と関連付けられた１つ以上の依存性パラメータを含み、依存性パラメータが、前記依存性パラメータを共通に有し、更に異なるタイル位置を有するタイル・ストリームのメディア・データおよびタイル位置情報が前記ビットストリームに組み入れ可能であることを、前記クライアント・コンピュータに知らせ、前記依存性パラメータが、前記依存性パラメータと関連付けられたタイル・ストリームのメディア・データのデコーディングが、少なくとも１つのベース・ストリームのメタデータに依存することを知らせ、前記ベース・ストリームが、前記マニフェスト・ファイルにおける前記タイル・ストリーム識別子によって定められたタイル・ストリームのメディア・データを、前記デコーダによってデコード可能な前記ビットストリームに組み入れなければならない順序を、前記クライアント・コンピュータに知らせるためにシーケンス情報を含む、方法。

【請求項8】

請求項７記載の方法において、前記１つ以上の依存性パラメータが、１つ以上のリプリゼンテーションを指し示し、前記１つ以上のリプリゼンテーションが１つ以上のリプリゼンテーションＩＤによって識別され、前記１つ以上のリプリゼンテーションが、少なくとも１つのベース・ストリームを定め、または、
前記１つ以上の依存性パラメータが１つ以上のアダプテーション・セットを指し示し、前記１つ以上のアダプテーション・セットが、１つ以上のアダプテーション・セットＩＤによって識別され、前記１つ以上のアダプテーション・セットの少なくとも１つが、前記少なくとも１つのベース・ストリームを定める少なくとも１つのリプリゼンテーションを含む、方法。

【請求項9】

請求項３〜８のいずれか１項記載の方法において、前記マニフェスト・ファイルが、更に、１つ以上の依存性位置パラメータを含み、依存性位置パラメータが、前記マニフェスト・ファイルにおいて少なくとも１つのベース・ストリームが定められる少なくとも１つの位置を、前記クライアント・コンピュータに知らせ、前記マニフェスト・ファイルにおける前記位置が、アダプテーション・セットＩＤによって識別される既定のアダプテーション・セットである、方法。

【請求項10】

請求項３〜９のいずれか１項記載の方法において、前記マニフェスト・ファイルが、更に、１つ以上のリプリゼンテーションまたは１つ以上のアダプテーション・セットと関連付けられた１つ以上のグループ依存性パラメータを含み、グループ依存性パラメータが、前記少なくとも１つのベース・ストリームを定める少なくとも１つのリプリゼンテーションを含むリプリゼンテーションのグループを前記クライアント・コンピュータに知らせる、方法。

【請求項11】

請求項１〜１０のいずれか１項記載の方法において、
前記少なくとも第１および第２タイル・ストリームが、メディア・ストリーミング・プロトコル若しくはメディア・トランスポート・プロトコル、（ＨＴＴＰ）適応ストリーミング・プロトコル、またはＲＴＰプロトコルのような、パケット化メディア・データのためのトランスポート・プロトコルにおけるデータ・コンテナに基づいてフォーマットされ、
前記第１および第２組のタイル・ストリーム識別子によって定められたタイル・ストリームのメディア・データが、メディア・データをタイルド・ビデオ・フレームにエンコードするエンコーダ・モジュールをサポートするコデックに基づいてエンコードされ、並びに／あるいは、
前記第１および第２組のタイル・ストリーム識別子によって定められたタイル・ストリームのメディア・データが、記憶媒体上に（タイル）トラックとして格納され、前記タイル・ストリームの少なくとも一部に関連するメタデータが、前記記憶媒体上に少なくとも１つのベース・トラックとして格納され、前記タイル・トラックおよび少なくとも１つのベース・トラックが、ISO/IEC 14496-12 ISO Base Media File Format (ISOBMFF)またはISO/IEC 14496-15 Carriage of NAL unit structured video in the ISO Base Media File Formatに基づくデータ・コンテナ・フォーマットを有する、方法。

【請求項12】

クライアント・コンピュータであって、
プログラムの少なくとも一部が具体化されたコンピュータ読み取り可能記憶媒体と、
コンピュータ読み取り可能プログラム・コードが具体化されたコンピュータ読み取り可能記憶媒体と、
前記コンピュータ読み取り可能記憶媒体に結合されたプロセッサであって、前記コンピュータ読み取り可能プログラム・コードを実行したことに応答して、実行可能動作を実行するように構成されたプロセッサと、
を含み、前記実行可能動作が、
−第１組のタイル・ストリーム識別子から、第１タイル位置と関連付けられた第１タイル・ストリーム識別子を判定し、第２組のタイル・ストリーム識別子から、第２タイル位置と関連付けられた第２タイル・ストリーム識別子を判定する動作であって、前記第１タイル位置が前記第２タイル位置とは異なる、動作と、
前記第１組のタイル・ストリーム識別子が、第１ビデオ・コンテンツの少なくとも一部のエンコード・メディア・データを含むタイル・ストリームと関連付けられ、前記第２組のタイル・ストリーム識別子が、第２ビデオ・コンテンツの少なくとも一部のエンコード・メディア・データを含むタイル・ストリームと関連付けられ、前記第１および前記第２ビデオ・コンテンツが異なるビデオ・コンテンツであり、１つの組の各タイル・ストリーム識別子が異なるタイル位置と関連付けられ、
タイル・ストリームが、メディア・データと、前記タイル・ストリームのメディア・データをタイルド・ビデオ・フレームにデコードすることをデコーダに指令するように構成されたタイル位置情報とを含み、タイルド・ビデオ・フレームが、前記タイル位置情報によって示されるタイル位置に少なくとも１つのタイルを含み、タイルが前記タイルド・ビデオ・フレームの画像領域におけるビジュアル・コンテンツの小区域を表し、
−前記判定した第１タイル・ストリーム識別子に基づいて、１つ以上のネットワーク・ノードに、第１タイル位置と関連付けられた第１タイル・ストリームを前記クライアント・コンピュータに送信することを要求し、更に前記判定した第２タイル・ストリーム識別子に基づいて、第２タイル位置と関連付けられた第２タイル・ストリームを前記クライアント・コンピュータに送信することを要求する動作と、
−少なくとも前記第１および第２タイル・ストリームのメディア・データおよびタイル位置情報を、前記デコーダによってデコード可能なビットストリームに組み入れる動作であって、前記デコーダが、タイルド・ビデオ・フレームを含むデコード・ビデオ・ストリームを形成ように構成され、前記タイルド・ビデオ・フレームが、前記第１タイル位置において、前記第１タイル・ストリームのメディア・データのビジュアル・コンテンツを表す第１タイルと、前記第２タイル位置において、前記第２タイル・ストリームのメディア・データのビジュアル・コンテンツを表す第２タイルとを含む、動作と、
を含む、クライアント・コンピュータ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、メディア・ストリームに基づくタイルド・ビデオ(tiled video)の形成に関し、特に、タイル・ストリームに基づいてタイルド・ビデオを形成する方法およびシステム、タイルド・ビデオを形成するクライアント・コンピュータ、クライアント・コンピュータがタイルド・ビデオを形成することを可能にするデータ構造、および以上で引用した方法を使用するためのコンピュータ・プログラム製品に関するが、これらに限定されるのではない。

【従来技術】

【0002】

ビデオ・モザイクのようなタイルド・ビデオは、１つ以上のディスプレイ・デバイス上における視覚的に無関係なビデオ・コンテンツまたは関係するビデオ・コンテンツの複数のビデオ・ストリームの複合表示(combined presentation)の一例である。このようなビデオ・モザイクの例には、高速チャネル選択に対して複数のＴＶチャネルを１つのモザイク・ビュー内に含むＴＶチャネル・モザイク、および簡潔な全体像のために複数のセキュリティ・ビデオ・フィードを１つのモザイク内に含むセキュリティ・カメラ・モザイクが含まれる。異なる人々が異なるビデオ・モザイクを必要とするとき、ビデオ・モザイクの個人専用化(personalization)が望まれることが多い。例えば、各ユーザが彼自身が贔屓する１組のＴＶチャネルを有することができる個人専用化ＴＶチャネル・モザイク、電子プログラム・ガイドによって示されるＴＶプログラムに関連するビデオ・モザイクを各ユーザが構成することができる個人専用化インタラクティブ電子プログラム・ガイド（ＥＰＧ）、または各セキュリティ職員が彼自身の１組のセキュリティ・フィードを有することができる個人専用化セキュリティ・カメラ・モザイクがある。ユーザのＴＶチャネルの好みは変化する可能性があるので、またはＴＶチャネルの視聴率が変動するので、ビデオ・モザイクが現在最も視聴されているＴＶチャネルを示す場合や、セキュリティ職員が場所を変えるときに他のセキュリティ・ビデオ・フィードがこのセキュリティ職員にとって関連するようになる可能性がある場合、個人専用化はときの経過に連れて変わる可能性がある。加えてまたは代わりに、ビデオ・モザイクは、インタラクティブである、即ち、ユーザ入力に応答するように構成されるとして差し支えない。例えば、ユーザが特定のタイルをＴＶチャネル・モザイクから選択したとき、ＴＶは特定のチャネルに切り替えることができる。

【0003】

ＷＯ２００８／０８８７７２は、ビデオ・モザイクを生成するための従来のプロセスについて記載する。このプロセスは、異なるビデオを選択し、ビデオ・モザイクを表すビデオ・ストリームをクライアント・デバイスに送信できるように、サーバ・アプリケーションが、選択されたビデオを処理するステップを含む。ビデオ処理は、ビデオをデコードすること、デコードされたドメインにおいて、選択されたビデオのビデオ・フレームを空間的に組み合わせてスティッチする(stitch)こと、およびビデオ・フレームを１つのビデオ・ストリームに再エンコードすることを含むことができる。このプロセスは、デコーディング／エンコーディングおよびキャッシング(caching)に関して大量の依頼(recourses)を必要とする。更に、最初にビデオ・ソースにおいて、２番目にサーバにおいてという二重エンコーディング・プロセスの結果、元のソース・ビデオの品質劣化が生ずる。

【0004】

Sanchez et al,による論文、"Low Complexity cloud-video-mixing using HEVC"（ＨＥＶＣを使用する低複雑度クラウド・ビデオ・ミキシング）、11^th annual IEEE CCNC - Multimedia networking, services and applications 2014, pp. 214-218、は、ビデオ会議および調査の用途のためにビデオ・モザイクを作成するシステムについて記載する。この論文は、規格に準拠したＨＥＶＣビデオ圧縮規格に基づくビデオ・ミキサの解決案について記載する。異なるビデオ・コンテンツに関連する異なるＨＥＶＣビデオ・ストリームを、これらのビデオ・ストリームにおいてＮＡＬユニットに関連するメタデータを書き直すことによって、ネットワークにおいて組み合わせる。このように、サーバは、ビデオ・ストリームのエンコード・ビデオ・コンテンツ(encoded video content)を含む着信ＮＡＬユニットを書き直し、タイルドＨＥＶＣビデオ・ストリームを表すＮＡＬユニットの送信ストリームにこれらを組み合わせる／インターレースする。ここで、各ＨＥＶＣタイルはビデオ・モザイクの画像領域の小区域(subregion)を表す。ビデオ・ミキサの出力は、特殊な制約をエンコーダ・モジュールに課することによって、規格に準拠したＨＥＶＣデコーダ・モジュールによってデコードすることができる。したがって、Sanchezは、デコード・ドメインにおけるデコーディング、スティッチング(stitching)、および再エンコーディングを含むリソース集約的プロセスの必要性を解消するかまたは少なくとも大幅に低減するように、ビデオ・コンテンツをエンコード・ドメインにおいて組み合わせる解決案について記載する。

【0005】

Sanchezによって提案された解決案に伴う問題は、作成されたビデオ・モザイクがサーバ上において専用のプロセスを必要とするので、要求されるサーバ処理容量がユーザの人数と線形で拡縮調整することしかできない、即ち、貧弱な拡縮調整しかできないことである。これは、このようなサービスを大規模に提供するときには、重大なスケーラビリティの問題となる。更に、クライアント−サーバ・シグナリング・プロトコルは、特定のモザイクを求める要求を送り、次いで、この要求に応答して、そのビデオ・モザイクを構成し、ビデオ・モザイクをクライアントに送信するのに時間がかかるので、遅延を招く。加えて、サーバは、このサーバによって配信される全てのストリームにとって１つの障害点、および１つの制御点の双方を形成し、プライバシーおよびセキュリティに関する危険性が生ずる。最後に、Sanchez et al.によって提案されたシステムは、サード・パーティのコンテンツ・プロバイダを許可しない。クライアントに提供される全てのコンテンツは、ビデオを組み合わせる役割を担う中央サーバが把握する必要がある。

【0006】

Sanchezのビデオ・ミキサ機能をクライアント側に移転させることによって、以上で述べた問題を部分的に解決することができる。しかしながら、これは、関連パラメータおよびヘッダを検出するため、そしてＮＡＬユニットのヘッダを書き直すために、クライアントがＨＥＶＣエンコード・ビットストリームを解析しなければならない。このような能力は、民生用の規格に準拠したＨＥＶＣデコーダ・モジュールを超えるデータ記憶容量および処理パワーを必要とする。

【0007】

更に、現行のＨＥＶＣ技術は、異なるタイル位置および異なるコンテンツ・ソースに関連する異なるＨＥＶＣタイル・ストリームを選択するために必要とされる機能を提供しない。例えば、２０１４年３月のＩＳＯ投稿ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ ＭＰＥＧ２０１４では、空間的に関係するＨＥＶＣタイルをどのようにＤＡＳＨクライアント・デバイス（例えば、ＤＡＳＨを使用してストリームを受信するように構成されたクライアント・デバイスまたはコンピュータ）に通知することができるか、そしてこのようなＨＥＶＣタイルを、他の全てのタイルをダウンロードする必要なく、どのようにダウンロードすることができるかについて、複数のシナリオが記載されている。この文書は、１つのビデオ・ソースがＨＥＶＣタイル内にエンコードされ、ＨＥＶＣタイルはサーバ上に格納された１つのファイル（１つのエンコーディング・プロセスによって生成される１つのＩＳＯＢＭＦＦデータ・コンテナ）内にＨＥＶＣタイル・トラックとして格納されるというシナリオを説明する。このデータ・コンテナにおけるＨＥＶＣタイルを記述するマニフェスト・ファイル（ＤＡＳＨではメディア・プレゼンテーション記述またはＭＰＤと呼ばれる）を、格納されているＨＥＶＣタイル・トラックから１つを選択し再生する(playout)するために使用することができる。同様に、ＷＯ２０１４／０５７１３１は、ＭＰＤに基づいて１つのビデオから生じた１組のＨＥＶＣタイル（即ち、１つのビデオ・ソースをエンコードすることによって形成されたＨＥＶＣタイル）から、ＨＥＶＣタイルの部分集合（対象領域）を選択するプロセスについて記載する。

【0008】

MITSUHIRO HIRABAYASHI ET ALの"Considerations on HEVC Tile Tracks in MPD for DASH SRD"（ＤＡＳＨ ＳＲＤに対するＭＰＤにおけるＨＥＶＣタイル・トラックについての考察）、108. MPEG MEETING; 31-03-2014 - 4-4-2014; VALENCIA; MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG1 1 , m33085, 29 March 2014 (2014-03-29)は、ＤＡＳＨ ＳＲＤ上においてＨＥＶＣストリームのＨＥＶＣタイル・トラックをマッピングする方法について記載する。２つの使用事例が記載されている。１つの使用事例では、全てのＨＥＶＣタイル・トラックおよび関連するＨＥＶＣベース・トラック(Base Tracks)が１つのＭＰ４ファイルに含まれると仮定する。この場合、全てのＨＥＶＣタイル・トラックおよびＨＥＶＣベース・トラックをＳＲＤにおける部分表現(subrepresentation)にマッピングすることが提案されている。他の使用事例では、ＨＥＣＶタイル・トラックおよびＨＥＶＣベース・トラックの各々が別個のＭＰ４ファイルに含まれることを仮定する。この場合、全てのＨＥＶＣタイル・トラックＭＰ４ファイルおよびＨＥＶＣベース・トラックＭＰ４ファイルをアダプテーション・セット内のリプリゼンテーションにマッピングすることが提案されている。

【0009】

尚、第２．３章および第２．３．１章によれば、タイル・ビデオを記述する全てのＨＥＶＣタイル・トラックは、同じＨＥＶＣストリームに関係があり、これらは１つのＨＥＶＣエンコーディング・プロセスの結果であることを暗示することは、注記してしかるべきである。更に、これは、全てのこれらのＨＥＶＣタイル・トラックが、ＨＥＶＣエンコーダに入る同じ入力（ビデオ）ストリームに関係することも暗示する。

【0010】

ＧＢ２５１３１３９Ａ（キャノン株式会社［日本］）、２０１４年１０月２２日（２０１４−１０−２２）は、ＤＡＳＨ規格を使用してビデオ・データをストリーミングする方法を開示する。ｎ個の独立したビデオ・サブトラックを作成するために、ビデオの各フレームはｎ個の空間タイルに分割される。ここで、ｎは整数である。この方法は、サーバによって、（ＭＰＤ）メディア・プレゼンテーション記述ファイルをクライアント・デバイスに送信するステップであって、前記記述ファイルがｎ個のビデオ・サブトラックの空間編成に関するデータと、各ビデオ・サブトラックをそれぞれ指定する少なくともｎ個のＵＲＬとを含む、ステップと、クライアント・デバイスまたはクライアント・デバイスのユーザによって選択された１つの対象領域にしたがって、クライアント・デバイスによって１つ以上のＵＲＬを選択するステップと、クライアント・デバイスから、サーバによって、最終的な数のビデオ・サブトラックを要求する１つ以上の要求メッセージを受信するステップであって、各要求メッセージが、クライアント・デバイスによって選択されたＵＲＬの内の１つを含む、ステップと、要求メッセージに応答して、要求されたビデオ・サブトラックに対応するビデオ・データをクライアント・デバイスに、サーバによって送信するステップとを含む。

【0011】

ＷＯ ２０１５／０１１１０９Ａ１（キャノン株式会社［日本］）、キャノン・ヨーロッパ ＬＴＤ（イギリス）、２０１５年１月２９日（２０１５−０１−２９）は、サーバにおいて区分時限メディア・データ(partitioned timed media data)をカプセル化することを開示する。区分時限メディア・データは時限サンプルを含み、各時限サンプルは複数のサブサンプルを含む。時限サンプルの１つの複数のサブサンプルの中から少なくとも１つのサブサンプルを選択した後に、選択したサブサンプルと、他の時限サンプルの各々の１つの対応するサブサンプルとを含む１つの区分トラック(partition track)を、選択したサブサンプル毎に作成する。次に、少なくとも１つの依存性ボックス(dependency box)を作成する。各依存性ボックスは、区分トラックに関係があり、他の作成した区分トラックの１つ以上に対する少なくとも１つの参照(reference)を含む。少なくとも１つの参照は、他の区分トラックの１つ以上に関するデコーディング順序の依存性を表す。区分トラックの各々は、少なくとも１つのメディア・ファイルに独立してカプセル化される。

【発明の概要】

【発明が解決しようとする課題】

【0012】

以上で説明したプロセスおよびＭＰＤは、しかしながら、異なるタイル位置と関連つけけられ、異なるビデオ・ファイル（例えば、異なるエンコーディング・プロセスによって生成された異なるＩＳＯＢＭＦＦデータ・コンテナ）から生じ、ネットワークにおける異なる位置に格納されている場合もある大多数のタイル・トラックに基づいて、クライアント・デバイスが柔軟にそして効率的にビデオ・モザイクを「構成する」(compose)ことを可能にしない。

【0013】

したがって、当技術分野では、異なるタイル位置と関連つけけられ、異なるコンテンツ・ソースから生じたタイル・ストリームに基づいて、ビデオ・モザイクの効率的な選択および構成を可能にする、新たな(improved)方法、デバイス、システム、およびデータ構造が求められている。具体的には、当技術分野では、スケーラブルなトランスポート方式(scalable transport scheme)、例えば、マルチキャストおよび／またはＣＤＮによって大多数のクライアント・デバイスに配信することができるビデオ・モザイクの構成(composition)に対する効率的でスケーラブルな解決を可能にする方法およびシステムが求められている。

【課題を解決するための手段】

【0014】

当業者には認められようが、本発明の態様は、システム、方法、またはコンピュータ・プログラム製品として具体化することができる。したがって、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロコード等を含む）、またはソフトウェアおよびハードウェアの態様を組み合わせた実施形態という形態をなすことができ、これらは全て本明細書では一般に「回路」、「モジュール」、または「システム」と呼ぶこともできる。本開示において説明する機能は、コンピュータのマイクロプロセッサによって実行されるアルゴリズムとして実現することができる。更に、本発明の態様は、コンピュータ読み取り可能プログラム・コードが具体化されている、例えば、格納されている１つ以上のコンピュータ読み取り可能媒体（１つまたは複数）に具体化されたコンピュータ・プログラム製品の形態をなすこともできる。

【0015】

１つ以上のコンピュータ読み取り可能媒体（１つまたは複数）の任意の組み合わせも利用することができる。コンピュータ読み取り可能媒体は、コンピュータ読み取り可能信号媒体またはコンピュータ読み取り可能記憶媒体であってもよい。コンピュータ読み取り可能記憶媒体は、例えば、電子、磁気、光、電磁、赤外線、または半導体システム、装置、あるいはデバイス、更には以上のもののあらゆる適した組み合わせであってもよいが、これらに限定されるのではない。コンピュータ読み取り可能記憶媒体の更に具体的な例（非網羅的な羅列）を挙げるとすれば、以下を含むであろう。１本以上のワイヤを有する電気接続、可搬型コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、消去可能プログラマブル・リード・オンリ・メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、可搬型コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ−ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、あるいは以上のもののあらゆる適した組み合わせ。本文書のコンテキストでは、コンピュータ読み取り可能記憶媒体は、命令実行システム、装置、またはデバイスによる使用のため、またはそれと関連した使用のためのプログラムを収容または格納することができる、任意の有形媒体とすればよい。

【0016】

コンピュータ読み取り可能信号媒体は、例えば、ベースバンドにまたは搬送波の一部としてコンピュータ読み取り可能プログラム・コードが内部に具体化された伝搬データ信号を含むことができる。このような伝搬信号は、電磁、光、またはこれらのあらゆる適した組み合わせを含むがこれらに限定されない種々の形態の内任意の形態をなすことができる。コンピュータ読み取り可能信号媒体は、コンピュータ読み取り可能記憶媒体ではなく、命令実行システム、装置、またはデバイスによる使用、またはそれと関連した使用のためにプログラムを伝達、伝搬、または移送することができる任意のコンピュータ読み取り可能媒体とすることができる。

【0017】

コンピュータ読み取り可能媒体上に具体化されたプログラム・コードは、任意の適した媒体を使用して送信することができる。任意の適した媒体には、ワイヤレス、ワイヤライン、光ファイバ、ケーブル、ＲＦ等、または以上のもののあらゆる適した組み合わせを含むが、これらに限定されるのではない。本発明の態様のために動作を実行するコンピュータ・プログラム・コードは、１つ以上のプログラミング言語の任意の組み合わせで書くことができる。プログラミング言語には、Ｊａｖａ（商標）、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のようなオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語のような従来の手続き型プログラミング言語が含まれる。プログラム・コードは、完全にユーザのコンピュータにおいて、部分的にユーザのコンピュータにおいて、単独のソフトウェア・パッケージとして、部分的にユーザのコンピュータにおいてそして部分的にリモート・コンピュータにおいて、あるいは完全にリモート・コンピュータまたはサーバにおいて実行することができる。後者のシナリオでは、リモート・コンピュータをユーザのコンピュータに任意のタイプのネットワークを通じて接続することができる。ネットワークには、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）が含まれ、または接続が外部コンピュータに対して行われてもよい（例えば、インターネット・サービス・プロバイダを使用してインターネットを通じて）。

【0018】

本発明の態様について、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図および／またはブロック図を参照して以下に説明する。尚、フローチャート図および／またはブロック図の各ブロック、そしてフローチャート図および／またはブロック図におけるブロックの組み合わせをコンピュータ・プログラム命令によって実現できることは理解されよう。これらのコンピュータ・プログラム命令は、汎用コンピュータ、特殊目的コンピュータ、または他のプログラマブル・データ処理装置のプロセッサ、具体的には、マイクロプロセッサまたは中央処理ユニット（ＣＰＵ）に供給され、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイスのプロセッサによって命令が実行されて、フローチャートおよび／またはブロック図の１つまたは複数のブロックにおいて指定された機能／アクトを実現する手段を形成する(create)ように、機械を生成することができる。

【0019】

これらのコンピュータ・プログラム命令は、コンピュータ読み取り可能媒体に格納することもでき、コンピュータ読み取り可能媒体に格納された命令が、フローチャートおよび／またはブロック図の１つまたは複数のブロックにおいて指定された機能／アクトを実現する命令を含む製品を生成するように、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイスに特定のやり方で機能するように指令することができる。

【0020】

また、コンピュータ・プログラム命令は、コンピュータ、他のプログラマブル・データ処理装置、または他のデバイス上にロードして、一連の動作ステップをコンピュータ、他のプログラマブル装置、またはデバイス上で実行させ、コンピュータまたは他のプログラマブル装置上で実行する命令が、フローチャートおよび／またはブロック図の１つまたは複数のブロックにおいて指定された機能／アクトを実現するためのプロセスを設けるように、コンピュータ実装プロセスを生成することもできる。

【0021】

図におけるフローチャートおよびブロック図は、本発明の種々の実施形態によるシステム、方法、およびコンピュータ・プログラム製品の可能な実施態様のアーキテクチャ、機能、および動作を例示する。これに関して、フローチャートまたはブロック図における各ブロックは、指定された論理機能（１つまたは複数）を実現するための１つ以上の実行可能命令を含む、モジュール、セグメント、またはコードの一部を表すことができる。また、ある代替実施態様では、ブロック内に記された機能が、図に記された順序以外で行われてもよいことも注記してしかるべきである。例えば、連続して示される２つのブロックが、実際には、実質的に同時に実行されてもよく、またはこれらのブロックが、関与する機能に応じて、逆の順序で実行されてもよいときもある。また、ブロック図および／またはフローチャート図の各ブロック、ならびにブロック図および／またはフローチャート図におけるブロックの組み合わせは、指定された機能またはアクトを実行する特殊目的ハードウェア・ベース・システム、あるいは特殊目的ハードウェアおよびコンピュータ命令の組み合わせによっても実現できることも注記しておく。

【0022】

本発明の目的は、先行技術において知られている欠点の少なくとも１つを低減または解消することである。具体的には、本発明の目的の１つは、タイル・ストリームを生成すること、即ち、ビデオ・フレームにおいて所定の位置にタイルを含む前記ビデオ・フレームにデコーダによってデコードすることができるメディア・データを含むメディア・ストリームを生成することである。異なるタイル・ストリームを選択し、異なる位置におけるタイルと組み合わせることによって、１つ以上のディスプレイ上においてレンダリングすることができるビデオ・モザイクの形成が可能になる。

【0023】

一実施形態では、本発明は、複数のタイル・ストリームからデコード・ビデオ・ストリームを形成する方法に関することができ、この方法は、第１タイル位置と関連付けられた少なくとも第１タイル・ストリーム識別子を選択し、第２タイル位置と関連付けられた少なくとも第２タイル・ストリーム識別子を選択するステップであって、前記第１タイル位置が前記第２タイル位置とは異なる、ステップと、前記選択した第１タイル・ストリーム識別子に基づいて、１つ以上のネットワーク・ノードに、第１タイル位置と関連付けられた第１タイル・ストリームを前記クライアント・コンピュータに送信することを要求し、更に選択した第２タイル・ストリーム識別子に基づいて、第２タイル位置と関連付けられた第２タイル・ストリームを前記クライアント・コンピュータに送信することを要求するステップと、少なくとも前記第１および第２タイル・ストリームのメディア・データおよびタイル位置情報を、前記デコーダによってデコード可能なビットストリームに組み入れ、前記ビットストリームを前記タイルド・ビデオ・フレームにデコードすることによってデコード・ビデオ・ストリームを形成するステップであって、各タイルド・ビデオ・フレームが、前記第１タイル位置において、前記第１タイル・ストリームのメディア・データのビジュアル・コンテンツを表す第１タイルと、前記第２タイル位置において、前記第２タイル・ストリームのメディア・データのビジュアル・コンテンツを表す第２タイルとを含む、ステップとを含むことができる。

【0024】

一実施形態では、第１タイル・ストリーム識別子は、第１組のタイル・ストリーム識別子から選択することができ、第２タイル・ストリーム識別子は、第２組のタイル・ストリーム識別子から選択することができる。

【0025】

一実施形態では、第１組のタイル・ストリーム識別子は、第１ビデオ・コンテンツの少なくとも一部のエンコード・メディア・データを含むタイル・ストリームを識別することができ、第２組のタイル・ストリーム識別子は、第２ビデオ・コンテンツの少なくとも一部のエンコード・メディア・データを含むタイル・ストリームを識別することができる。好ましくは、第１および第２ビデオ・コンテンツは異なるビデオ・コンテンツであり、好ましくは、１組の各タイル・ストリーム識別子は、それぞれ、第１または第２ビデオ・コンテンツの異なるタイル位置と関連付けられる。

【0026】

本発明は、異なるコンテンツ・ソースから生じた(originate)タイル・ストリーム、例えば、異なるエンコーダによって生成された異なるビデオに基づいて、タイルド・ビデオの構成(composition)（例えば、ビデオ・モザイク）の形成およびレンダリングを可能にする。タイル・ストリームとは、メディア・データとタイル位置情報とを含むメディア・ストリームと定義することができ、これによって、前記タイル位置情報が、デコーダにタイル位置を知らせるように構成される(arranged)。このデコーダは、前記タイル・ストリームのメディア・データをタイルド・ビデオ・フレームにデコードするように構成され、タイルド・ビデオ・フレームは、前記タイル位置情報によって示されるように、タイル位置において少なくとも１つのタイルを含み、タイルは、前記タイルド・ビデオ・フレームの画像領域におけるビジュアル・コンテンツの小区域を表す。デコーダは、好ましくは、前記クライアント・コンピュータに通信可能に接続され、このデコーダがこのようなクライアント・コンピュータの一部であるという可能性を含む。

【0027】

タイル・ストリームは、メディア・フォーマットを有することができ、タイル・ストリームと関連つけけられた位置情報が、デコード・メディア・データを含むビデオ・ストリームのタイルド・ビデオ・フレームの画像領域内における特定の位置（タイル位置）においてタイルを含むタイルド・ビデオ・フレームを生成することを、デコーダに指令する。タイル・ストリームは、デコード・メディア・データ（例えば、ビデオ・モザイク）を含むタイルド・ビデオ・フレームのタイル位置毎に、複数のタイル・ストリームからタイル・ストリームを選択することによって、ビデオ・モザイクを構成する(compose)プロセスにおいて特に有利である。タイル・ストリームのビデオ・フレームにおいてタイルを形成するメディア・データは、メディア・デバイス内に実装されたメディア・エンジンによって簡単に処理することができるＮＡＬユニットのような、アドレス可能なデータ構造内に収容することができる。タイルの操作、例えば、異なるタイル・ストリームのタイルをビデオ・モザイクに組み入れることは、タイル・ストリームのメディア・データの簡単な操作、具体的には、タイル・ストリームのＮＡＬユニットの操作によって、先行技術の一部によって必要とされるようにＮＡＬユニットにおいて情報を書き換える必要なく、実現することができる。このように、異なるタイル・ストリームのビデオ・フレームにおけるタイルのメディア・データを容易に操作し、メディア・データを変更することなく、組み合わせることができる。更に、例えば、個人専用化またはカスタム化ビデオ・モザイクの形成において必要となるタイルの操作は、クライアント側で実施することができ、ビデオ・モザイクの処理およびレンダリングは、異なるタイルが異なるビデオ・コンテンツから生じたときであっても、１つのデコーダに基づいて実現することができる。

【0028】

一実施形態では、各タイル・ストリームのメディア・データは、独立してエンコードすることができる（例えば、異なるタイル・ストリームのタイル間で全くコーディング依存性なく）。エンコーディングは、ＨＥＶＣ、ＶＰ９、ＡＶＣ、またはこれらのコデックの内１つから派生したまたはそれに基づくコデックのような、タイルド・ビデオ・フレームをサポートするコデックに基づくことができる。１つ以上のタイルド・メディア・ストリームに基づいて、独立してデコード可能なタイル・ストリームを生成するために、エンコーダは、タイルド・メディア・ストリームの後続ビデオ・フレームにおけるタイルのメディア・データが独立してエンコードされるように構成されなければならない。独立エンコード・タイルは、エンコーダ、好ましくは、ＨＥＶＣエンコーダの相互予測機能(inter-prediction functionality)を無効にすることによって実現することができる。あるいは、独立エンコード・タイルは、相互予測機能を有効にすることによって（例えば、圧縮効率の理由のため）実現することもできるが、その場合、エンコーダは、
−タイル境界を跨ぐループ内フィルタリングを無効にする、
−時間的タイル間依存性がない、
−２つの異なるフレームにおいて２つのタイル間に依存性がない（複数の連続フレームにおいて１つの位置におけるタイルの抽出を可能にするため）、
ように構成され(arrange)なければならない。

【0029】

したがって、この場合、相互予測のための動きベクトルは、メディア・ストリームの複数の連続するビデオ・フレームにわたるタイル境界内に制約される必要がある。

【0030】

一実施形態では、前記位置情報は、更に、前記第１および第２タイルが、タイル格子に基づいて空間的に配列された非重複タイルであることを、前記デコーダに知らせることができる。したがって、タイル位置情報は、ビデオ・ストリームの画像領域内に格子状パターンにしたがってタイルが位置付けられるように構成される(arrange)。このように、タイルの非重複構成(composition)を含むビデオ・フレームは、異なるタイル・ストリームのメディア・データを使用して形成することができる。

【0031】

一実施形態では、この方法は、更に、１組以上のタイル・ストリーム識別子、または１組以上のタイル・ストリーム識別子を判定するための情報、好ましくは、１組以上のＵＲＬを含む少なくとも１つのマニフェスト・ファイルを供給するステップを含むことができる。１組のタイル・ストリーム識別子は、所定のビデオ・コンテンツと関連付けることができ、前記１組のタイル・ストリーム識別子の各タイル・ストリーム識別子は、異なるタイル位置と関連付けることができる。例えば、ビデオＡおよびＢの双方が、１組のタイル・ストリームとして入手可能であってもよく、これらのタイル・ストリームは、異なるコンテンツと関連付けられた１組の異なるタイル・ストリームから特定のタイル位置のためにタイル・ストリームを、クライアント・デバイスが選択できるように、異なるタイル位置に対して入手可能であってもよい。第１および第２タイル・ストリーム識別子は、このようなマニフェスト・ファイルに基づいて選択することができ、このマニフェスト・ファイルを多重選択（ＭＣ：multiple-choice)マニフェスト・ファイルと呼ぶこともできる。ＭＣマニフェスト・ファイルは、タイルド・ビデオ構成(composition)の柔軟で効率的な形成を可能にすることができる。

【0032】

一実施形態では、前記マニフェスト・ファイル、好ましくは、ＭＰＥＧ ＤＡＳＨ系マニフェスト・ファイル（例えば、ＭＰＥＧ ＤＡＳＨ規格に基づくマニフェスト・ファイル）が１つ以上のアダプテーション・セットを含むことができ、アダプテーション・セットは１組のリプリゼンテーションを定め、リプリゼンテーションはタイル・ストリーム識別子を含む。したがって、アダプテーション・セットは、異なるタイル位置と関連つけけられた１組のタイル・ストリームという形態で、ビデオ・コンテンツのリプリゼンテーションを含むことができる。アダプテーション・セットは、好ましくは、ＭＰＥＧ ＤＡＳＨ系アダプテーション・セットである。アダプテーション・セットは、一般に、同じビデオ・コデックにしたがってエンコードされたコンテンツの１つ以上のリプリゼンテーションを含む(contain)ことを特徴とすることができ、これによって、コンテンツの再生を切り替えるためのリプリゼンテーション間の切り替えが可能となり、または特定のアダプテーション・セットでは、複数のリプリゼンテーションのコンテンツの同時再生が可能となる。

【0033】

一実施形態では、アダプテーション・セットにおけるタイル・ストリーム識別子は、空間関係記述（ＳＲＤ）記述子と関連付けることができ、前記空間関係記述子は、前記タイル・ストリーム識別子と関連付けられたタイル・ストリームのビデオ・フレームのタイルのタイル位置についての情報を、前記クライアント・コンピュータに知らせる。

【0034】

一実施形態では、アダプテーション・セットにおける全てのタイル・ストリーム識別子が１つの空間関係記述（ＳＲＤ）記述子と関連付けられ、前記空間関係記述子は、前記アダプテーション・セットにおいて識別されたタイル・ストリームのビデオ・フレームのタイルのタイル位置について、前記クライアント・コンピュータに知らせる。したがって、この実施形態では、クライアントに複数のタイル位置を知らせるためには、１つのＳＲＤ記述子があればよい。
例えば、以下のシンタックスを有するＳＲＤ記述子に基づいて、４つのＳＲＤを記述することができる。

【表1】

ここで、タイル上のｘおよびｙ位置を示すＳＲＤパラメータは、位置のベクトルを表す(represent as)。したがって、この新たなＳＲＤ記述子シンタックスに基づいて、一層緻密なＭＰＤを達成することができる。この実施形態の利点は、マニフェスト・ファイルが大多数のタイル・ストリームのリプリゼンテーションを含む場合に一層明白になる。

【0035】

一実施形態では、前記第１および第２タイル・ストリーム識別子は、それぞれ、第１および第２ユニフォーム・リソース・ロケータ（ＵＲＬ）（の一部）であってもよく、前記第１および第２タイル・ストリームのビデオ・フレームにおけるタイルのタイル位置についての情報は、前記タイル・ストリーム識別子に埋め込まれる。一実施形態では、前記タイル・ストリームのビデオ・フレームにおけるタイルの位置についての情報が埋め込まれたタイル・ストリーム識別子を前記クライアント・コンピュータが生成することを可能にするために、マニフェスト・ファイルにおけるタイル識別子テンプレートを使用することができる。

【0036】

クライアント・デバイスが正しいタイル・ストリームをネットワーク・ノードに要求するために必要とされる正しいタイル・ストリーム識別子、例えば、ＵＲＬ（の一部）をクライアント・デバイスが判定することを可能にするために、１つのアダプテーション・セットにおける複数のＳＲＤ記述子がテンプレート（例えば、ＤＡＳＨ仕様において定められた修正セグメント・テンプレート）を必要とすることがある。このようなセグメント・テンプレートは以下のように表すことができる(look)。
<SegmentTemplatetimescale="90000" initialization
="$object_x$_$object_y$_init.mp4v" media="$object_x$_$object_y$_$Time$.mp4v">

【0037】

このセグメント・テンプレートのベースＵＲＬであるBaseURLならびにobject_xおよびobject_y識別子は、object_xおよびobject_y識別子を、タイル・ストリームの選択されたリプリゼンテーションのＳＲＤ記述子における位置情報と交換することによって、特定のタイル位置と関連付けられたタイル・ストリームのタイル・ストリーム識別子、例えば、ＵＲＬ（の一部）生成するために使用することができる。

【0038】

一実施形態では、この方法は、更に、１つ以上のネットワーク・ノードにベース・ストリームを前記クライアント・コンピュータに送信することを要求するステップを含むことができ、前記ベース・ストリームは、前記タイル・ストリーム識別子によって定められたタイル・ストリームのメディア・データを、前記デコーダによってデコード可能なビットストリームに組み入れなければならない順序に関連するシーケンス情報を含む。

【0039】

一実施形態では、前記方法は、更に、１つ以上のネットワーク・ノードに、前記少なくとも第１および第２タイル・ストリームと関連付けられたベース・ストリームを前記クライアント・コンピュータに送信することを要求するステップであって、前記ベース・ストリームが、前記第１および第２タイル・ストリームのメディア・データを前記ビットストリームに組み入れなければならない順序に関連するシーケンス情報を含む、ステップと、前記第１および第２メディア・データならびに前記第１および第２位置情報を前記ビットストリームに組み入れるために、前記シーケンス情報を使用するステップとを含むことができる。

【0040】

一実施形態では、前記方法は、更に、ビデオ・モザイクを構成する(compose)ためにタイル・ストリームを選択するように構成されたユーザ・インターフェースを設けるステップであって、前記ユーザ・インターフェースが、第１タイル位置と関連付けられた少なくとも第１タイル・ストリームと、第２タイル位置と関連付けられた少なくとも第２タイル・ストリームとを選択するための選択可能項目を含む、ステップと、前記１つ以上の選択可能項目と対話処理することによって、前記第１および第２タイル・ストリームを選択するステップとを含む。したがって、ＭＣマニフェスト・ファイルにおける情報は、グラフィカル・ユーザ・インターフェースを生成しディスプレイ上にレンダリングするために使用することができ、これによって、ビデオ・モザイクのような、タイルド・ビデオ構成(composition)の容易な判定が可能となる。

【0041】

一実施形態では、前記方法は、更に、前記第１タイル・ストリームと関連付けられた第１ＵＲＬの少なくとも一部と、前記第２タイル・ストリームと関連付けられた第２ＵＲＬの少なくとも一部とを含むマニフェスト・ファイルを送信することをネットワーク・ノードに要求するステップと、前記マニフェスト・ファイルを使用して、前記第１および第２タイル・ストリームのメディア・データおよびタイル位置情報を前記クライアント・コンピュータに送信することを１つ以上のネットワーク・ノードに要求するステップとを含むことができる。この実施形態では、タイルド・ビデオ構成(composition)を形成すべき選択されたタイル・ストリームについての情報がネットワークに送られ、応答して、タイルド・ビデオ構成(composition)を定める「個人専用化(personalized)」マニフェスト・ファイルがクライアント・デバイスに送られる。

【0042】

一実施形態では、前記第１組のタイル・ストリーム識別子によって定められたタイル・ストリームのメディア・データを、前記第１ビデオ・コンテンツと関連付けられたメディア・データを含む第１タイル・ストリーム・データ構造内に（タイル）トラックとして格納することができ、前記第２組のタイル・ストリーム識別子によって定められたタイル・ストリームのメディア・データを、前記第２ビデオ・コンテンツと関連付けられたメディア・データを含む第２データ構造内に（タイル）トラックとして格納することができる。

【0043】

一実施形態では、前記第１および／または第２タイル・ストリーム・データ構造は、更に、シーケンス情報を含むベース・トラックを含むことができ、好ましくは、前記シーケンス情報がエキストラクタを含み、各エキストラクタが、前記タイル・ストリーム・データ構造の１つのタイル・トラックの１つにおけるメディア・データを参照する。一実施形態では、前記第１および／または第２データ構造は、例えば、ISO/IEC 14496-12 ISO Base Media File Format (ISOBMFF)またはＡＶＣ用のその変異型、およびHEVC ISO/IEC 14496-15 Carriage of NAL unit structured video in the ISO Base Media File Format に基づくデータ・コンテナ・フォーマットを有するのでもよい。

【0044】

一実施形態では、前記少なくとも第１および第２タイル・ストリームは、メディア・ストリーミング・プロトコルまたはメディア・トランスポート・プロトコル、（ＨＴＴＰ）適応ストリーミング・プロトコル、あるいはＲＴＰプロトコルのようなパケット化メディア・データ用のトランスポート・プロトコルのデータ・コンテナに基づいてフォーマットされる。

【0045】

一実施形態では、前記第１および第２タイル・ストリームの前記メディア・データは、メディア・データをタイルド・ビデオ・フレームにエンコードするためのエンコーダ・モジュールをサポートするコデックに基づいてエンコードされ、好ましくは、前記コデックが、ＨＥＶＣ，ＶＰ９，ＡＶＣあるいはこれらのコデックの１つから派生したコデックまたはそれに基づくコデックの内の１つから選択される。

【0046】

一実施形態では、前記第１および第２タイル・ストリームのメディア・データおよびタイル位置情報は、前記デコーダによって処理することができる、ビットストリーム・レベルで定められたデータ構造に基づいて、好ましくは、Ｈ．２６４／ＡＶＣおよびＨＥＶＣビデオ・コーディング規格のようなコーディング規格によって定められるような、ネットワーク抽象化レイヤ（ＮＡＬ）に基づいて組み立てることができる。

【0047】

一実施形態では、タイル・ストリームのビデオ・フレームにおける１つのタイルと関連付けられたメディア・データは、ビットストリーム・レベルで定められるアドレス可能なデータ構造に収容することができ、好ましくは、前記アドレス可能なデータ構造はＮＡＬユニットである。

【0048】

一実施形態では(one embodiment)、タイルド・ビデオ・フレームにおける１つのタイルと関連付けられたエンコード・メディア・データを、Ｈ．２６４／ＡＶＣおよびＨＥＶＣビデオ・コーディング規格または関連するコーディング規格から分かるような、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットに組み立てることができる。ＨＥＶＣエンコーダの場合、これは、１つのＨＥＶＣタイルが１つのＨＥＶＣを構成する(comprise)ことを要求することによって達成することができる。ＨＥＶＣスライスは、１つの独立したスライス・セグメントに収容される整数個のコーディング・ツリー・ユニットと、ＨＥＶＣ仕様によって定められるのと同じアクセス・ユニット内に次の独立スライス・セグメント（ある場合）に先立つ全ての後続の依存スライス・セグメント（ある場合）とを定める。この要求は、エンコーダ情報において、エンコーダ・モジュールに送ることができる。ビデオ・フレームの１つのタイルのメディア・データがＮＡＬユニットに収容されることを要求することによって、異なるタイル・ストリームのメディア・データの容易な組み合わせが可能になる。

【0049】

一実施形態では、前記マニフェスト・ファイルは、１つ以上のタイル・ストリーム識別子と関連付けられた１つ以上の依存性パラメータを含むことができ、依存性パラメータは、当該依存性パラメータと関連付けられたタイル・ストリームのメディア・データのデコーディングが、少なくとも１つのベース・ストリームのメタデータに依存することを、前記クライアント・コンピュータに知らせる。一実施形態では、ベース・ストリームは、前記マニフェスト・ファイルにおいて前記タイル・ストリーム識別子によって定められたタイル・ストリームのメディア・データを、前記デコーダによってデコード可能なビットストリームに組み入れなければならない順序を、クライアント・コンピュータに知らせるために、シーケンス情報（例えば、エキストラクタ）を含むことができる。一実施形態では、依存性パラメータは、同じ依存性パラメータを共通に有し、更に異なるタイル位置を有することにより、好ましくは少なくとも２つの異なるアダプテーション・セットに属する、タイル・ストリームのメディア・データおよびタイル位置情報が、デコーダによってデコーダ可能な１つのビットストリーム（例えば、デコーダによって使用されるコデックに準拠するビットストリーム）に、ベース・ストリームのメタデータに基づいて組み入れ可能であることを、クライアント・コンピュータに知らせることができ、好ましくは、アダプテーション・セットは、ＭＰＥＧ ＤＡＳＨ規格に基づく。

【0050】

一実施形態では、前記１つ以上の依存性パラメータは、１つ以上のリプリゼンテーションを指し示すことができ、前記１つ以上のリプリゼンテーションは前記少なくとも１つのベース・ストリームを定める。一実施形態では、ベース・ストリームを定めるリプリゼンテーションをリプリゼンテーションＩＤによって識別することができ、１つ以上の依存性パラメータがベース・ストリームのリプリゼンテーションＩＤを指し示すこともできる。

【0051】

一実施形態では、前記１つ以上の依存性パラメータは１つ以上のアダプテーション・セットを指し示すことができ、前記１つ以上のアダプテーション・セットは、前記少なくとも１つのベース・ストリームを定める少なくとも１つのリプリゼンテーションを含む。一実施形態では、ベース・ストリームを定めるリプリゼンテーションを含むアダプテーション・セットをアダプテーション・セットＩＤによって識別することができる。したがって、要求されたリプリゼンテーションが、マニフェストにおいてどこか別の場所（例えば、アダプテーション・セットＩＤによって識別される他のアダプテーション・セット）において定められたベース・トラックにおけるメタデータに依存することをクライアント・デバイスに明示的に知らせるために、baseTrackdependencyld属性を定めることができる。baseTrackdependencyld属性は、マニフェスト・ファイルにおけるリプリゼンテーションの集合体全体における、対応する識別子を有する１つ以上のベース・トラックの検索を誘起することができる。一実施形態では、baseTrackdependencyld属性は、ベース・トラックが、要求されたリプリゼンテーションと同じアダプテーション・セットに位置しない場合、リプリゼンテーションをデコードするためにベース・トラックが必要か否か知らせるために使用することができる。

【0052】

依存性パラメータがリプリゼンテーション・レベルで定められるとき、全てのリプリゼンテーションにわたる検索には、マニフェスト・ファイルにおけるリプリゼンテーション全てのインデックス化が必要となる。特に、マニフェスト・ファイルにおけるリプリゼンテーションの数が相当になり得る、例えば、数百のリプリゼンテーションになり得るメディア・アプリケーションでは、マニフェスト・ファイルにおける全てのリプリゼンテーションにわたる検索は、クライアント・デバイスにとって集中的な処理になるおそれがある。したがて、一実施形態では、クライアント・デバイスがＭＰＤにおいてリプリゼンテーション全体にわたる一層効率的な検索を実行することを可能にする１つ以上のパラメータを、マニフェスト・ファイルに設けることができる。具体的には、一実施形態では、マニフェスト・ファイルは１つ以上の依存性位置パラメータを含むことができ、依存性位置パラメータは、少なくとも１つのベース・ストリームが定められているマニフェスト・ファイルにおける少なくとも１つの位置をクライアント・コンピュータに知らせ、前記ベース・ストリームは、前記マニフェスト・ファイルにおいて定められた１つ以上のタイル・ストリームのメディア・データをデコードするためのメタデータを含む。一実施形態では、前記マニフェスト・ファイルにおける前記ベース・ストリームの位置は、アダプテーション・セットＩＤによって識別される既定のアダプテーション・セットと関連付けられる。

【0053】

したがって、マニフェスト・ファイルにおけるリプリゼンテーション・エレメントは、依存リプリゼンテーションを含む１つ以上の関連リプリゼンテーションを発見することができる少なくとも１つのアダプテーション・セットを指し示す（例えば、AdaptationSet@idに基づいて）dependentRepresentationLocation属性と関連付けることができる。ここで、依存性は、メタデータ依存性および／またはデコーディング依存性に関するとしてもよい。一実施形態では、dependentRepresentationLocationの値は、空白によって分離された１つ以上のAdaptationSet@idとすることができる。

【0054】

本発明の複数の実施形態では、アダプテーション・セットは、１つ以上のリプリゼンテーションを含むことを特徴とし、１つ以上のリプリゼンテーションがＤＡＳＨクライアント・デバイスによって選択されると、コンテンツ・ストリームの継ぎ目ない再生を可能とし、これら１つ以上のリプリゼンテーションが参照することにより、１つよりも多いリプリゼンテーションが存在する場合、継ぎ目ない再生は、同期して再生すること、および／または１つのリプリゼンテーションによって参照されるコンテンツの再生から、同じアダプテーション・セットの他のリプリゼンテーションによって参照されるコンテンツの再生への継ぎ目ない（例えば、中断のない）切り替えを意味する。

【0055】

一実施形態では、前記マニフェスト・ファイルは、更に、１つ以上のリプリゼンテーションまたは１つ以上のアダプテーション・セットと関連付けられた１つ以上のグループ依存性パラメータを含むことができる。グループ依存性パラメータは、前記少なくとも１つのベース・ストリームを定めるリプリゼンテーションを含むリプリゼンテーションのグループを前記クライアント・デバイスに知らせる。したがって、この実施形態では、１つ以上の依存リプリゼンテーションの再生に要求されるリプリゼンテーション（即ち、ストリームを再生するために関連ベース・ストリームにメタデータを要求するタイル・ストリーム・リプリゼンテーション）の一層効率的な検索をクライアント・デバイスが行うことを可能にするために、マニフェスト・ファイルにおいてリプリゼンテーションを集合化するdependencyGroupldパラメータを使用することができる。

【0056】

一実施形態では、リプリゼンテーションのレベルで、dependencyGroupldパラメータを定めることができる（即ち、グループに属するあらゆるリプリゼンテーションにこのパラメータを貼り付ける）。他の実施形態では、アダプテーション・セット・レベルで dependencyGroupldパラメータを定めることもできる。dependencyGroupldパラメータが貼り付けられた１つ以上のアダプテーション・セットにおけるリプリゼンテーションは、ベース・ストリームのようなメタデータ・ストリームを定める１つ以上のリプリゼンテーションを、クライアント・デバイスが捜すことができるリプリゼンテーションのグループを定めることができる。

【0057】

更に他の態様では、本発明はクライアント・コンピュータ、好ましくは、適応ストリーミング・クライアント・コンピュータに関するものもある。このクライアント・コンピュータは、プログラムの少なくとも一部が具体化されたコンピュータ読み取り可能記憶媒体と、コンピュータ読み取り可能プログラム・コードが具体化されたコンピュータ読み取り可能記憶媒体と、コンピュータ読み取り可能記憶媒体に結合されたプロセッサ、好ましくは、マイクロプロセッサとを含む。コンピュータ読み取り可能プログラム・コードを実行したことに応答して、プロセッサは、第１タイル位置と関連付けられた少なくとも第１タイル・ストリーム識別子を選択し、更に第２タイル位置と関連付けられた少なくとも第２タイル・ストリーム識別子を選択する動作であって、前記第１タイル位置が前記第２タイル位置とは異なる、動作と、選択した第１タイル・ストリーム識別子に基づいて、第１タイル位置と関連付けられた第１タイル・ストリームを前記クライアント・コンピュータに送信することを１つ以上のネットワーク・ノードに要求し、更に、選択した第２タイル・ストリーム識別子に基づいて、第２タイル位置と関連付けられた第２タイル・ストリームを前記クライアント・コンピュータに送信することを要求する動作と、少なくとも前記第１および第２タイル・ストリームのメディア・データおよびタイル位置情報を、前記デコーダによってデコード可能なビットストリームに組み入れる動作とを含む実行可能動作を実行するように構成される。前記デコーダは、タイルド・ビデオ・フレームを生成するように構成され、タイルド・ビデオ・フレームは、前記第１タイル位置において前記第１タイル・ストリームのメディア・データのビジュアル・コンテンツを表す第１タイルと、前記第２タイル位置において前記第２タイル・ストリームのメディア・データのビジュアル・コンテンツを表す第２タイルとを含む。

【0058】

一態様では、本発明は、クライアント・コンピュータ、好ましくは、適応ストリーミング・クライアント・コンピュータに関するものもある。このクライアント・コンピュータは、プログラムの少なくとも一部が具体化されたコンピュータ読み取り可能記憶媒体と、コンピュータ読み取り可能プログラム・コードが具体化されたコンピュータ読み取り可能記憶媒体と、コンピュータ読み取り可能記憶媒体に結合されたプロセッサ、好ましくは、マイクロプロセッサとを含む。コンピュータ読み取り可能プログラム・コードを実行したことに応答して、プロセッサは、複数組のストリーム識別子、好ましくは、複数組のＵＲＬを判定するための情報を含むマニフェスト・ファイルを受信する動作であって、各組のタイル・ストリーム識別子が所定のビデオ・コンテンツおよび複数のタイル位置と関連付けられ、タイル・ストリーム識別子が、タイル・位置において少なくとも１つのタイルを含むタイルド・ビデオ・フレームを生成することをデコーダに通知するために、メディア・データおよびタイル位置情報を含むタイル・ストリームを識別し、前記タイルが前記ビデオ・フレームの画像領域におけるビジュアル・コンテンツの小区域を定め、前記マニフェスト・ファイルが、同じ依存性パラメータを共通に有し、更に異なるタイル位置を有するタイル・ストリームのメディア・データおよびタイル位置情報が、ベース・ストリームのメタデータに基づいて、前記デコーダ・モジュールによってデコード可能な１つのビットストリームに組み入れ可能であることを、前記クライアント・コンピュータに知らせるために１つ以上の依存性パラメータを含む、動作と、

【0059】

−前記マニフェスト・ファイルにおける情報を使用して、第１組のタイル・ストリーム識別子から第１タイル位置と関連付けられた第１タイル・ストリーム識別子を判定し、第２組のタイル・ストリーム識別子から第２タイル位置と関連付けられた第２タイル・ストリーム識別子を判定する動作であって、前記第１タイル位置が前記第２タイル位置とは異なり、前記第１組のタイル・ストリーム識別子が、第１ビデオ・コンテンツの少なくとも一部のエンコード・メディア・データを含むタイル・ストリームと関連付けられ、前記第２組のタイル・ストリーム識別子が、第２ビデオ・コンテンツの少なくとも一部のエンコード・メディア・データを含むタイル・ストリームと関連付けられ、好ましくは、第１および第２ビデオ・コンテンツが異なるコンテンツであり、好ましくは、１組の各タイル・ストリーム識別子が、それぞれ第１または第２ビデオ・コンテンツの異なるタイル位置と関連付けられる、動作と、

【0060】

−前記マニフェスト・ファイルにおける情報を使用して、前記第１および第２タイル・ストリームと関連付けられたベース・ストリームを定めるベース・ストリーム識別子を判定する動作と、
−前記第１および第２タイル・ストリーム識別子ならびに前記ベース・ストリーム識別子を使用して、前記第１および第２タイル・ストリームのメディア・データおよびタイル位置情報と、前記ベース・ストリームのメタデータとを、前記クライアント・コンピュータに送信することを、１つ以上のネットワーク・ノードに要求する動作と、
を含む実行可能動作を実行するように構成される。

【0061】

一態様では、本発明は、クライアント・コンピュータ、好ましくは、適応ストリーミング・クライアント・コンピュータに関するものもある。このクライアント・コンピュータは、プログラムの少なくとも一部が具体化されたコンピュータ読み取り可能記憶媒体と、コンピュータ読み取り可能プログラム・コードが具体化されたコンピュータ読み取り可能記憶媒体と、コンピュータ読み取り可能記憶媒体に結合されたプロセッサ、好ましくは、マイクロプロセッサとを含む。コンピュータ読み取り可能プログラム・コードを実行したことに応答して、プロセッサは、

【0062】

−第１組のタイル・ストリーム識別子から、第１タイル位置と関連付けられた第１タイル・ストリーム識別子を判定し、第２組のタイル・ストリーム識別子から、第２タイル位置と関連付けられた第２タイル・ストリーム識別子を判定する動作であって、前記第１タイル位置が前記第２タイル位置とは異なり、前記第１組のタイル・ストリーム識別子が、第１ビデオ・コンテンツの少なくとも一部のエンコード・メディア・データを含むタイル・ストリームと関連付けられ、

【0063】

前記第２組のタイル・ストリーム識別子が、第２ビデオ・コンテンツの少なくとも一部のエンコード・メディア・データを含むタイル・ストリームと関連付けられ、好ましくは、第１および第２ビデオ・コンテンツが異なるコンテンツであり、好ましくは、１組の各タイル・ストリーム識別子が、それぞれ、第１または第２ビデオ・コンテンツの少なくとも一部の異なるタイル位置と関連付けられるが、必ずしもそうではない、動作と、

【0064】

前記クライアント・コンピュータが、好ましくは、デコーダに通信可能に接続可能であり、
前記デコーダが、１つ以上のタイル・ストリームのエンコード・メディア・データを、複数のビデオ・フレームを含むデコード・ビデオ・ストリームにデコードするように構成され、各フレームが１つ以上のタイルを含み、
前記第１および第２組のタイル・ストリーム識別子によって定められた各タイル・ストリームが、少なくとも１つのタイル位置に少なくとも１つのタイルを位置付けることを前記デコーダに指令するように構成されたタイル位置情報と関連付けられ、タイルが、前記デコード・ビデオ・ストリームのビデオ・フレームの画像領域におけるビジュアル・コンテンツの小区域を定め、

【0065】

−第１ＵＲＬまたは前記第１タイル・ストリームと関連付けられた第１ＵＲＬを判定するための情報と、第２ＵＲＬまたは前記第２タイル・ストリームと関連付けられたＵＲＬを判定するための情報と、任意に、第３ＵＲＬまたは前記第１および第２タイル・ストリームのメディア・データを前記デコーダによってデコード可能なビットストリームに組み入れるためのメタデータを含むベース・ストリームと関連付けられたＵＲＬを判定するための情報とを含むマニフェスト・ファイルを送信することを、好ましくはネットワーク・ノードに要求する動作と、

【0066】

−前記マニフェスト・ファイルを使用して、前記第１および第２タイル・ストリームのメディア・データおよびタイル位置情報、ならびに、任意に、前記ベース・ストリームのメタデータを前記クライアント・コンピュータに送信することを、１つ以上のネットワーク・ノードに要求する動作と、
を含む実行可能動作を実行するように構成される。

【0067】

一実施形態では、本発明は、クライアント・コンピュータによる使用のためのデータ構造、好ましくは、マニフェスト・ファイルを格納するための非一時的コンピュータ読み取り可能記憶媒体に関するものもある。前記データ構造は、

【0068】

好ましくは前記クライアント・コンピュータによって、複数組のタイル・ストリーム識別子、好ましくは、複数組のＵＲＬを判定するための情報を含むマニフェスト・ファイルを含む。各組のタイル・ストリーム識別子は、異なる所定のビデオ・コンテンツ、および所定のコンテンツの複数のタイル位置と関連付けられ、タイル・ストリーム識別子は、所定のコンテンツのメディア・データと、タイル位置において少なくとも１つのタイルを含むタイルド・ビデオ・フレームを生成することをデコーダに指令するためのタイル位置情報とを含むタイル・ストリームを識別し、前記タイルが、前記ビデオ・フレームの画像領域におけるビジュアル・コンテンツの小区域を定める。

【0069】

前記マニフェスト・ファイルは、更に、１つ以上のタイル・ストリームと関連付けられた１つ以上の依存性パラメータを含み、前記１つ以上の依存性パラメータは、前記マニフェスト・ファイルにおける少なくとも１つのベース・ストリームを指し示し、前記依存性パラメータは、同じ依存性パラメータを共通に有し、更に異なるタイル位置を有するタイル・ストリームのメディア・データおよびタイル位置情報が、前記少なくとも１つのベース・ストリームのメタデータに基づいて、前記デコーダによってデコード可能な１つのビットストリームに組み入れ可能であることを、前記クライアント・コンピュータに知らせる。言い換えると、デコーダによって使用されるコデックに準拠したビットストリームである。

【0070】

一実施形態では、所定のビデオ・コンテンツと関連付けられた１組のタイル・ストリーム識別子は、１組のリプリゼンテーションを含むアダプテーション・セットとして定めることができ、リプリゼンテーションはタイル・ストリームを定める。

【0071】

一実施形態では、前記マニフェスト・ファイルは、１つ以上のタイル・ストリーム識別子と関連付けられた１つ以上の依存性パラメータを含むことができる。依存性パラメータは、前記依存性パラメータと関連付けられたタイル・ストリームのメディア・データのデコーディングが少なくとも１つのベース・ストリームのメタデータに依存することを、前記クライアント・コンピュータに知らせる。好ましくは、前記ベース・ストリームは、前記マニフェスト・ファイルにおける前記タイル・ストリーム識別子によって定められたタイル・ストリームのメディア・データを、前記デコーダによってデコード可能なビットストリームに組み入れなければならない順序をクライアント・コンピュータに知らせるためのシーケンス情報を含む。言い換えると、デコーダによって使用されるコデックに準拠したビットストリームに組み入れる。

【0072】

一実施形態では、前記１つ以上の依存性パラメータは、好ましくはリプリゼンテーションＩＤによって識別される１つ以上のリプリゼンテーションを指し示すことができる。前記１つ以上のリプリゼンテーションは、前記少なくとも１つのベース・ストリームを定める。または前記１つ以上の依存性パラメータは、好ましくはアダプテーション・セットＩＤによって識別される１つ以上のアダプテーション・セットを指し示す。前記１つ以上のアダプテーション・セットは、前記少なくとも１つのベース・ストリームを定める少なくとも１つのリプリゼンテーションを含む。

【0073】

一実施形態では、前記マニフェスト・ファイルは、更に、１つ以上の依存性位置パラメータを含むことができる。依存性位置パラメータは、前記マニフェスト・ファイルにおいて、少なくとも１つのベース・ストリームが定められた少なくとも１つの位置を前記クライアント・コンピュータに知らせる。前記ベース・ストリームは、前記マニフェスト・ファイルにおいて定められた１つ以上のタイル・ストリームのメディア・データをデコードするためのメタデータを含む。好ましくは、前記マニフェスト・ファイルにおける前記位置は、アダプテーション・セットＩＤによって識別される既定のアダプテーション・セットである。

【0074】

一実施形態では、前記マニフェスト・ファイルは、更に、１つ以上のリプリゼンテーションまたは１つ以上のアダプテーション・セットと関連付けられた１つ以上のグループ依存性パラメータを含むことができる。グループ依存性パラメータは、前記少なくとも１つのベース・ストリームを定めるリプリゼンテーションを含むリプリゼンテーションのグループを、前記クライアント・デバイスに知らせる。

【0075】

本発明の更に他の改良では、マニフェスト・ファイルは、特定のプロパティ、好ましくは提供されるコンテンツのモザイク・プロパティを更に示す１つ以上のパラメータを収容する。本発明の実施形態(embodiments)では、このモザイク・プロパティが定められると、複数のタイル・ビデオ・ストリームが、マニフェスト・ファイルのリプリゼンテーションに基づいて選択され更にこのプロパティを共通に有するとき、デコードされた後に、互いにスティッチされて表示用のビデオ・フレームが作られる。これらのビデオ・フレームの各々は、レンダリングされたときに１つ以上のビジュアル・フレーム間境界がある小区域のモザイクを形作る(constitute)。本発明の好ましい実施形態では、選択されたタイル・ビデオ・ストリームは、１つのビットストリームとしてデコーダ、好ましくは、ＨＥＶＣデコーダに入力される。

【0076】

更に他の実施形態では、マニフェスト・ファイル、好ましくは、ＭＰＥＧ ＤＡＳＨに基づくマニフェスト・タイルは、１つ以上の「spatial_set_id」パラメータと、１つ以上の「spatial set type」パラメータとを含み、少なくとも１つのspatial_set_idパラメータは spatial_set_typeパラメータと関連付けられる。

【0077】

一実施形態では、以上で述べたモザイク・プロパティ・パラメータは、spatial_set_typeパラメータとして含まれる(comprised)。

【0078】

本発明の更に他の実施形態によれば、「spatial_set_type」のセマンティックは、「spatial_set_id」値がマニフェスト・ファイル全体に対して有効であることを表し、異なる「source_id」値を有するＳＲＤ記述子に適用可能である。 これは、異なるビジュアル・コンテンツに対して異なる「source_id」値を有するＳＲＤ記述子を使用する可能性を可能にし、「spatial_set_id」の既知のセマンティックを、その使用が「source_id」のコンテキストの範囲内に制限されることに変更する。この場合、ＳＲＤ記述子を有するリプリゼンテーションは、これらが、「source_id」値に関係なく、同じ「spatial_set_id」を値「mosaic」のそれらの「spatial_set_type」と共有する限り、空間関係を有する。

【0079】

本発明の一実施形態では、モザイク・プロパティ・パラメータ、好ましくは、 spatial_set_typeパラメータは、ＳＲＤ記述子によって定められる利用可能な位置毎に、タイル・ビデオ・ストリームを指し示すリプリゼンテーションを選択することを、ＤＡＳＨクライアント・デバイスに指令する、好ましくは命令するまたは推奨するように構成され、これによって、リプリゼンテーションは、好ましくは、同じ「spatial_set_id」を共有するリプリゼンテーションのグループから選択される。

【0080】

本発明の実施形態では、クライアント・コンピュータ（例えば、ＤＡＳＨクライアント・デバイス）は、本発明の実施形態によるマニフェスト・ファイルを解釈し、マニフェスト・ファイルに収容されているメタデータに基づいて、マニフェスト・ファイルからリプリゼンテーションを選択することによって、タイル・ビデオ・ストリームを引き出すように構成される(arrange)。

【0081】

更に他の実施形態では、デコーダ情報をビデオ・コンテナ内において移送することができる。例えば、エンコーダ情報は、ＩＳＯＢＭＦＦファイル・フォーマット（ＩＳＯ／ＩＥＣ１４４９６−１２）のような、ビデオ・コンテナ内で移送するのでもよい。ＩＳＯＢＭＦＦファイル・フォーマットは、メディア・データおよびそれと関連つけけられたメタデータを格納しこれらにアクセスするための階層構造を形作る(constitute)１組のボックスを指定する。例えば、コンテンツに関係するメタデータのルート・ボックスは「ｍｏｏｖ」ボックスであり、一方メディア・データは「ｍｄａｔ」ボックスに格納される。更に特定すれば、「ｓｔｂｌ」ボックス即ち「サンプル・テーブル・ボックス」は、トラックのメディア・サンプルにインデックスを付けて、追加データを各サンプルと関連付けることを可能にする。ビデオ・トラックの場合、サンプルはビデオ・フレームである。その結果、「タイル・エンコーダ情報」または「ｓｔｅｉ」と呼ばれる新しいボックスをボックス「ｓｔｂｌ」内に追加すると、ビデオ・トラックのフレームと共にエンコーダ情報を格納するために使用することができる。

【0082】

また、本発明は、ソフトウェア・コード部分を含むプログラム製品に関するものもある。このソフトウェア・コード部分は、コンピュータのメモリにおいて実行されると、以上で説明した方法ステップの内任意のものにしたがって、方法ステップを実行するように構成される。

【0083】

更に、添付図面を参照して本発明について更に例示する。添付図面は、本発明による実施形態を模式的に示す。尚、本発明はこれらの具体的な実施形態には全く限定されないことは理解されよう。

【図面の簡単な説明】

【0084】

【図1A】図１Ａは、本発明の実施形態によるビデオ・モザイク・コンポーザを模式的に図示する。

【図1B】図１Ｂは、本発明の実施形態によるビデオ・モザイク・コンポーザを模式的に図示する。

【図1C】図１Ｃは、本発明の実施形態によるビデオ・モザイク・コンポーザを模式的に図示する。

【図2A】図２Ａは、本発明の種々の実施形態によるタイリング・モジュール(tiling module)を模式的に図示する。

【図2B】図２Ｂは、本発明の種々の実施形態によるタイリング・モジュール(tiling module)を模式的に図示する。

【図2C】図２Ｃは、本発明の種々の実施形態によるタイリング・モジュール(tiling module)を模式的に図示する。

【図3】図３は、本発明の他の実施形態によるタイリング・モジュールを図示する。

【図4】図４は、本発明の実施形態による一斉(coordinated)タイリング・モジュールのシステムを図示する。

【図5】図５は、本発明の更に他の実施形態によるタイリング・モジュールの使用を図示する。

【図6】図６は、本発明の実施形態によるタイル・ストリーム・フォーマッタを図示する。

【図7A】図７Ａは、本発明の種々の実施形態にしたがってタイル・ストリームを形成および格納するプロセス、およびメディア・フォーマットを図示する。

【図7B】図７Ｂは、本発明の種々の実施形態にしたがってタイル・ストリームを形成および格納するプロセス、およびメディア・フォーマットを図示する。

【図7C】図７Ｃは、本発明の種々の実施形態にしたがってタイル・ストリームを形成および格納するプロセス、およびメディア・フォーマットを図示する。

【図7D】図７Ｄは、本発明の種々の実施形態にしたがってタイル・ストリームを形成および格納するプロセス、およびメディア・フォーマットを図示する。

【図8】図８は、本発明の他の実施形態によるタイル・ストリーム・フォーマッタを図示する。

【図9】図９は、本発明の実施形態によるＲＴＰタイル・ストリームの形成を図示する。

【図10A】図１０Ａは、本発明の実施形態にしたがって、マニフェスト・ファイルに基づいてビデオ・モザイクをレンダリングするように構成されたメディア・デバイスを図示する。

【図10B】図１０Ｂは、本発明の実施形態にしたがって、マニフェスト・ファイルに基づいてビデオ・モザイクをレンダリングするように構成されたメディア・デバイスを図示する。

【図10C】図１０Ｃは、本発明の実施形態にしたがって、マニフェスト・ファイルに基づいてビデオ・モザイクをレンダリングするように構成されたメディア・デバイスを図示する。

【図11A】図１１Ａは、本発明の他の実施形態にしたがって、マニフェスト・ファイルに基づいてビデオ・モザイクをレンダリングするように構成されたメディア・デバイスを図示する。

【図11B】図１１Ｂは、本発明の他の実施形態にしたがって、マニフェスト・ファイルに基づいてビデオ・モザイクをレンダリングするように構成されたメディア・デバイスを図示する。

【図12A】図１２Ａは、本発明の実施形態によるタイル・ストリームのＨＡＳセグメントの形成を図示する。

【図12B】図１２Ｂは、本発明の実施形態によるタイル・ストリームのＨＡＳセグメントの形成を図示する。

【図13A】図１３Ａは、視覚的に関係するコンテンツのモザイク・ビデオの例を図示する。

【図13B】図１３Ｂは、視覚的に関係するコンテンツのモザイク・ビデオの例を図示する。

【図13C】図１３Ｃは、視覚的に関係するコンテンツのモザイク・ビデオの例を図示する。

【図13D】図１３Ｄは、視覚的に関係するコンテンツのモザイク・ビデオの例を図示する。

【図14】図１４は、本開示において説明するように使用することができる例証的なデータ処理システムを示すブロック図である。

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

【0085】

図１Ａ〜図１Ｃは、本発明の一実施形態によるビデオ・モザイク・コンポーザ・システム(video mosaic composer system)を模式的に図示する。具体的には、図１Ａは、異なる独立したメディア・ストリームを選択し、これらをビデオ・モザイクに組み合わせることを可能にするビデオ・モザイク・コンポーザ・システム１００を図示する。ビデオ・モザイクは、１つのデコーダ・モジュールを含むメディア・デバイスのディスプレイ上においてレンダリングすることができる。以下で更に詳しく説明するが、このビデオ・モザイク・コンポーザは、異なるビデオ・モザイクを効率的で柔軟な方法で形成する（「構成する」(compose)）ことができるように、異なるメディア・ストリームのメディア・データを組み立てる(structure)ために、いわゆるタイルド・ビデオ・ストリーム(tiled video stream)および関連タイル・ストリーム(associated tile stream)を使用することができる。

【0086】

本開示では、「タイルド・メディア・ストリーム」または「タイルド・ストリーム」という用語は、画像領域を表すビデオ・フレームを含むメディア・ストリームを指し、各ビデオ・フレームが１つ以上の小区域を含み、この小区域を「タイル」と呼ぶことができる。タイルド・ビデオ・フレームの各タイルは、そのタイルのタイル位置、およびビジュアル・コンテンツを表すメディア・データに関係付けることができる。更に、ビデオ・フレームにおけるタイルは、タイルに関連するメディア・データがデコーダ・モジュールによって独立してデコード可能であることを特徴とする。この態様については、以下で更に詳しく説明する。

【0087】

更に、本開示において、「タイル・ストリーム」という用語は、タイル・ストリームのメディア・データを、ビデオ・フレーム内の特定のタイル位置における１つのタイルを含むビデオ・フレームにデコードするように、デコーダ・モジュールに命令するためのデコーダ情報を含むメディア・ストリームを指す。タイル位置を知らせるデコーダ情報をタイル位置情報と呼ぶ。

【0088】

以下で更に詳しく説明するが、タイルド・メディア・ストリームのタイルド・ビデオ・フレーム内の特定のタイル位置におけるタイルに関連するメディア・データを選択し、このように収集したメディア・データを、クライアント・デバイスによってアクセスすることができるメディア・フォーマットで格納することによって、タイル・ストリームをタイルド・ストリームに基づいて生成することができる。

【0089】

図１Ｂは、図１Ａのビデオ・モザイク・コンポーザによって使用することができるタイルド・メディア・ストリームおよび関連タイル・ストリームの概念を示す。具体的には、図１Ｂは、複数のタイルド・ビデオ・フレーム１２０_１〜１２０_ｎ、即ち、複数のタイル１２２_１〜１２２_４（この特定例では、４つのタイル）に分割されたビデオ・フレームを示す。タイルド・ビデオ・フレームのタイル１２２_１に関連するメディア・データは、同じビデオ・フレームの他のタイル１２２_２〜１２２_４のメディア・データに対して空間デコーディング依存性を全く有さず、それよりも以前または以後のビデオ・フレームの他のタイル１２２_２〜１２２_４のメディア・データに対して時間デコーディング依存性も全く有さない。

【0090】

このように、後続のタイルド・ビデオ・フレームにおける所定のタイルに関連するメディア・データは、メディア・デバイスにおけるデコーダ・モジュールによって独立してデコードすることができる。言い換えると、クライアント・デバイスは、１つのタイル１２２_１のメディア・データを受信し、他のタイルのメディア・データを必要とせずに、最も早い受信ランダム・アクセス点からメディア・データをビデオ・フレームにデコードし始めることができる。ここで、ランダム・アクセス点は、以前および／または以後のビデオ・フレームに対して時間的デコーディング依存性を全く有さないビデオ・フレーム、例えば、Ｉ−フレームまたはその同等物と関連付けられてもよい。このように、１つの個別のタイルに関連するメディア・データは、１つの独立したタイル・ストリームとしてクライアント・デバイスに送信することができる。１つ以上のタイルド・メディア・ストリームに基づいてどのようにタイル・ストリームを生成することができるか、そしてネットワーク・ノードまたはメディア・デバイスの記憶媒体上にタイル・ストリームをどのように格納することができるかの例については、以下で更に詳しく説明する。

【0091】

エンコード・ビットストリームをクライアント・デバイスに送信するためには、異なるトランスポート・プロトコルを使用してもよい。例えば、一実施形態では、タイル・ストリームをクライアント・デバイスに配信するために、ＨＴＴＰ適応ストリーミング（ＨＡＳ）プロトコルを使用するのでもよい。この場合、タイル・ストリームにおけるビデオ・フレームのシーケンスは、通例２〜１０秒のメディア・データを含む時間セグメント１２４１、１２４２（図１Ｂに図示するように）に時間的に(temporality)分割することができる。このような時間セグメントは、記憶媒体上にメディア・ファイルとして格納することができる。一実施形態では、時間セグメントは、この時間セグメントや他の時間セグメントにおける他のフレーム、例えば、Ｉフレームに時間コーディング依存性を有さないメディア・データから始まることができるので、デコーダはＨＡＳセグメントにおけるメディア・データを直接デコードし始めることができる。

【0092】

したがって、本開示では、「独立してエンコードされた」メディア・データという用語は、ビデオ・フレーム内のタイルに関連するメディア・データと、このタイルの外側にあるメディア・データ（例えば、近隣タイル内にある）との間に空間コーディング依存性がなく、異なるビデオ・フレーム内の異なる位置におけるタイルのメディア・データ間にも時間的コーディング依存性がないことを意味する。独立してエンコードされたメディア・データという用語は、メディア・データが有することができる他の種類の依存性（独立性）からは区別されてしかるべきである。例えば、以下で更に詳しく説明するが、メディア・ストリーム内にあるメディア・データは、このメディア・ストリームをデコードするためにデコーダによって必要とされるメタデータを含む関連メディア・ストリームに依存するのは当然である。

【0093】

本開示において説明するタイルの概念は、異なるビデオ・コデックがサポートすることができる。例えば、高効率ビデオ・コーディング（ＨＥＶＣ）規格は、独立してデコード可能なタイル（ＨＥＶＣタイル）の使用を許容する。ＨＥＶＣタイルは、エンコーダによって作成することができる。エンコーダは、メディア・ストリームの各ビデオ・フレームを、コーディング・ツリー・ブロック（ＣＴＢ）単位で表された既定の幅および高さのタイルを定める、ある数の行および列（「タイルの格子」）に分割する。ＨＥＶＣビットストリームは、ビデオ・フレームをどのようにタイル単位に分割すべきかデコーダに知らせるために、デコーダ情報を含むことができる。デコーダ情報は、異なる方法でのビデオ・フレームのタイル分割についてデコーダに知らせることができる。１つの異なる態様(variant)では、デコーダ情報は、ｎ×ｍタイルの均一格子についての情報を含むのでもよく、フレームの幅およびＣＴＢサイズに基づいて格子におけるタイルのサイズを推論することができる。丸めによる不正確さのために、全てのタイルが正確に同じサイズを有するとは限らないこともある。他の異なる態様では、デコーダ情報は、タイルの幅および高さについて明示的な情報を含むのでもよい（例えば、コーディング・ツリー・ブロック単位で）。このようにすると、ビデオ・フレームを異なるサイズのタイルに分割することができる。最後の行および最後の列のタイルについてのみ、サイズは、残っているＣＴＢの数から導き出されればよい。その後、パケタイザ(packetizer)が生のＨＥＶＣビットストリームを、トランスポート・プロトコルによって使用される、適したメディア・コンテナにパケット化することができる。

【0094】

独立デコード可能なタイルをサポートする他のビデオ・コデックには、Ｇｏｏｇｌｅのビデオ・コデックＶＰ９、または、ある程度まで、ＭＰＥＧ−４ Ｐａｒｔ１０ ＡＶＣ／Ｈ．２６４、高度ビデオ・コーディング（ＡＶＣ）規格が含まれる。ＶＰ９では、コーディング依存性は、垂直タイル境界に沿って破壊される。これが意味するのは、同じタイル行内にある２つのタイルを同時にデコードできるということである。同様に、ＡＶＣエンコーディングでは、各フレームを複数の行に分割するためにスライスを使用することができ、メディア・データが独立してデコード可能であるという意味で、これらの行の各々がタイルを定める。したがって、本開示では、「タイル」という用語は、ＨＥＶＣタイルには限定されず、タイルの境界内にあるメディア・データが独立してデコード可能であるビデオ・フレームの画像領域内における任意の形状および／または寸法の小区域を一般に定める。他のビデオ・コデックでは、セグメントまたはスライスというような他の用語が、このように独立してデコード可能な領域に使用されることもある。

【0095】

図１Ａのビデオ・モザイク・コンポーザは、１つ以上のメディア・ソース１０８_１、１０８_２、例えば、１つ以上のカメラ、および／またはサード・パーティのコンテンツ・プロバイダ（図示せず）の１つ以上の（コンテンツ）サーバに接続されたモザイク・タイル・ジェネレータ１０４を含むことができる。カメラによってキャプチャされたメディア・データまたはサーバによって供給されたメディア・データ、例えば、ビデオ・データ、オーディオ・データ、および／またはテキスト・データ（例えば、字幕用）は、データ・コンテナ・フォーマット（例えば、ISO/IEC 14496-12 ISO Base Media File Format (ISOBMFF) またはＡＶＣ用のその変異型、およびHEVC ISO/IEC 14496-15 Carriage of NAL unit structured video in the ISO Base Media File Formatに応じたコンテナ・フォーマットで格納された、適したビデオ／オーディオ・コデックに基づいて、エンコードする（圧縮する）ことができる。このようにエンコードおよびフォーマットされたメディア・データは、１つ以上のネットワーク・ノード、例えば、ルータを介して、ネットワーク１０２内にあるモザイク・タイル・ジェネレータにメディア・ストリーム１１０_１、１１０_２において送信するために、パケット化することができる。

【0096】

モザイク・タイル・ジェネレータは、ビデオ・モザイクを形成するために、１つ以上のタイル・ストリーム１１２_１〜１１２_４、１１３_１〜１１３_４（以後、「モザイク・タイル・ストリーム」と呼ぶこともある）を生成することができる。モザイク・タイル・ストリームは、所定のメディア・フォーマットのデータ・ファイルとして、ネットワーク・ノード１１６の記憶媒体上に格納することができる。これらのモザイク・タイル・ストリームは、１つ以上のメディア・ソースから生じた１つ以上のメディア・ストリーム１１０_１、１１０_２に基づいて形成することができる。１組のモザイク・タイル・ストリームの各モザイク・タイル・ストリームは、所定のタイル位置においてタイルを構成するビデオ・フレームを生成するようにデコーダに命令するためのデコーダ情報を含み、タイルに関連するメディア・データが、元のメディア・ストリームのメディア・データのビジュアル・コピー(visual copy)を表す。

【0097】

例えば、図１Ａに示すように、４つのモザイク・タイル・ストリーム１１２_１〜１１２_４の各々は、これらのモザイク・タイル・ストリームを形成するために使用されたメディア・ストリーム１１０_２のビジュアル・コピーを表すタイルを構成するビデオ・フレームと関連付けられている。４つのモザイク・タイル・ストリーム１１２_１〜１１２_４の各々は、異なるタイル位置にあるタイルと関連付けられている。これらのモザイク・タイル・ストリームの生成中に、タイル・ストリーム・ジェネレータは、タイル・ストリーム間の関係を定めるメタデータを生成することができる。これらのメタデータは、マニフェスト・ファイル１１４_１、１１４_２に格納することができる。マニフェスト・ファイルは、タイル・ストリーム識別子（例えば、ファイル名（の一部））、前記タイル・ストリーム識別子によって識別されたタイル・ストリームを引き出すことができる１つ以上のネットワーク・ノードを突き止めるための位置情報（例えば、ドメイン名（の一部））、およびタイル・ストリーム識別子の各々またはその少なくとも一部に関連するいわゆるタイル位置記述子を含むことができる。したがって、タイル位置記述子は、タイル・ストリーム識別子によって識別されたタイル・ストリームのビデオ・フレームのタイルの空間位置、およびタイルの寸法（サイズ）について知らせ、一方タイル・ストリームのタイル位置情報は、デコーダに、タイル・ストリームのビデオ・フレームにおけるタイルの空間位置および寸法（サイズ）について、クライアント・コンピュータ、例えば、ＤＡＳＨクライアント・コンピュータ／デバイスに知らせる。更に、マニフェスト・ファイルは、タイル・ストリームに含まれるメディア・データについての情報（例えば、品質レベル、圧縮フォーマット等）も含むことができる。

【0098】

マニフェスト・ファイル（ＭＦ）マネージャ１０６は、ネットワーク（例えば、１つ以上のネットワーク・ノード）に格納され、クライアント・デバイスによって要求される可能性があるタイル・ストリームを定める１つ以上のマニフェスト・ファイルを管理する(administer)ように構成することができる。一実施形態では、マニフェスト・ファイル・マネージャは、異なるマニフェスト・ファイル１１４_１、１１４_２の情報を組み合わせて、クライアント・デバイスが所望のビデオ・モザイクを要求するために使用することができる別のマニフェスト・ファイルにするように構成することもできる。

【0099】

例えば、一実施形態では、クライアント・デバイスが所望のビデオ・モザイクについての情報をネットワーク・ノードに送ることができ、応答して、ネットワーク・ノードがマニフェスト・ファイル・マネージャ１０６に、このビデオ・モザイクを形成するタイル・ストリームのタイル・ストリーム識別子を含む別のマニフェスト・ファイル（「カスタム化」マニフェスト・ファイル）を生成するように要求することができる。ＭＦマネージャは、異なるマニフェスト・ファイル（の一部）を組み合わせることによって、または１つのマニフェスト・ファイルから複数の部分を選択することによって、このマニフェスト・ファイルを生成することもでき、各タイル・ストリーム識別子が、ビデオ・モザイクの異なるタイル位置のタイル・ストリームに関係することができる。つまり、カスタム化マニフェスト・ファイルは、「進行中に」生成された特定のマニフェスト・ファイルを定める（要求されたビデオ・モザイクを定める）。このマニフェスト・ファイルをクライアント・デバイスに送ることができ、クライアント・デバイスは、ビデオ・モザイクを形成するタイル・ストリームのメディア・データを要求するために、マニフェスト・ファイルにおけるこの情報を使用する。

【0100】

他の実施形態では、マニフェスト・ファイル・マネージャは、格納されているタイル・ストリームのマニフェスト・ファイルに基づいて、更に別のマニフェスト・ファイルを生成することもでき、この更に別のマニフェスト・ファイルは、同じタイル位置と関連つけけられた複数のタイル・ストリーム識別子を含む。この更に別のマニフェスト・ファイルは、クライアント・デバイスに供給することができ、クライアント・デバイスは、この更に別のマニフェスト・ファイルを使用して、複数のタイル・ストリームから特定のタイル位置における所望のタイル・ストリームを選択することができる。このような更に別のマニフェスト・ファイルを「多重選択」（ＭＣ：multiple choice）マニフェスト・ファイルと呼ぶこともできる。ＭＣマニフェスト・ファイルは、クライアント・デバイスが、ビデオ・モザイクのタイル位置の各々に入手可能な複数のタイル・ストリームに基づいて、ビデオ・モザイクを構成する(compose)ことを可能にする。カスタム化マニフェスト・ファイルおよび多重選択マニフェスト・ファイルについては、以下で更に詳しく説明する。

【0101】

一旦モザイク・タイル・ストリームおよび関連マニフェスト・ファイルが１つ以上のネットワーク・ノード１１６の記憶媒体上に格納されたなら、クライアント・デバイス１１７_１、１１７_２がメディア・データにアクセスすることができる。クライアント・デバイスは、マニフェスト・ファイルまたはその同等物のような、モザイク・タイル・ストリームについての情報に基づいて、タイル・ストリームを要求するように構成することができる。クライアント・デバイスは、要求されたメディア・データを処理してレンダリングするように構成されたメディア・デバイス１１８_１、１１８_２上に実装することができる。このために、メディア・デバイスは、更に、タイル・ストリームのメディア・データを組み合わせてビットストリームにするメディア・エンジン１１９１、１１９２も含むことができる。ビットストリームは、このビットストリームにおける情報をビデオ・モザイク１２０_１、１２０_２のビデオ・フレームにデコードするように構成されたデコーダに入力される。メディア・デバイスは、一般に、コンテンツ処理デバイス、例えば、電子タブレット、スマート・フォン、ノートブック、メディア・プレーヤ、テレビジョン等のような、（移動体）コンテンツ再生デバイスに関係するとして差し支えない。ある実施形態では、メディア・デバイスは、セット・トップ・ボックス、またはコンテンツを処理し、コンテンツ再生デバイスによる今後の消費のために一時的にコンテンツを格納するように構成されたコンテンツ記憶デバイスであってもよい。

【0102】

タイル・ストリームについての情報は、帯域内または帯域外通信チャネルを通じてクライアント・デバイスに提供することができる。一実施形態では、ユーザが選択することができるタイル・ストリームを識別する複数のタイル・ストリーム識別子を含むマニフェスト・ファイルを、クライアント・デバイスに供給することができる。クライアント・デバイスは、このマニフェスト・ファイルを使用して、メディア・デバイスの画面上に（グラフィカル）ユーザ・インターフェース（ＧＵＩ）をレンダリングすることができ、ユーザがビデオ・モザイクを選択（「構成」(compose)）することを可能にする。ここで、ビデオ・モザイクを構成するとは、タイル・ストリームを選択し、ビデオ・モザイクが形成されるようにこれら選択したタイル・ストリームを特定のタイル位置に配置することを含んでもよい。具体的には、メディア・デバイスのユーザが、例えば、タッチ・スクリーンまたはジェスチャ・ベースのユーザ・インターフェースを介してＵＩと対話処理して、タイル・ストリームを選択し、選択したタイル・ストリームの各々にタイル位置を割り当てることができる。ユーザの対話処理は、複数の(a number of)タイル・ストリーム識別子の選択に変換することができる。

【0103】

以下で更に詳しく説明するが、異なるタイル・ストリームのビデオ・フレームを表すビットシーケンスを連結し(concatenate)、タイル位置情報をビットストリームに挿入し、１つのデコーダ・モジュールがそれをデコードできるように、所定のコデック、例えば、ＨＥＶＣコデックに基づいてビットストリームをフォーマットすることによって、ビットストリームを形成することができる。例えば、クライアント・デバイスが、１組の個々のＨＥＶＣタイル・ストリームを要求し、要求したストリームのメディア・データをメディア・エンジンに転送してもよく、メディア・エンジンは、異なるタイル・ストリームのビデオ・フレームを組み合わせて、１つのＨＥＶＣデコーダ・モジュールによってデコードすることができるＨＥＶＣ準拠のビットストリームにすることができる。したがって、ビットストリームをデコードし、クライアント・デバイスが実装されているメディア・デバイスのディスプレイ上にメディア・データをビデオ・モザイクとしてレンダリングすることができる１つのデコーダ・モジュールを使用して、選択したタイル・ストリームを１つのビットストリームに組み合わせて、デコードすることができる。

【0104】

クライアント・デバイスによって選択されたタイル・ストリームは、適した（スケーラブルな）メディア配給技法を使用して、クライアント・デバイスに配信することができる。例えば、一実施形態では、タイル・ストリームのメディア・データをクライアント・デバイスに、適したストリーミング・プロトコル、例えば、ＲＴＰストリーミング・プロトコル、または適応ストリーミング・プロトコル、例えば、ＨＴＴＰ適応ストリーミング（ＨＡＳ）プロトコルを使用して、ブロードキャスト、マルチキャスト（ネットワーク・ベースのマルチキャスト、例えば、イーサネット・マルチキャストおよびＩＰマルチキャスト、ならびにアプリケーション・レベルまたはオーバーレイ・マルチキャスティングの双方を含む）、またはユニキャストすることができる。後者の実施形態では、タイル・ストリームを一時的にＨＡＳセグメントにセグメント化してもよい。メディア・デバイスは、適応ストリーミング・クライアント・デバイスを含むことができ、適応ストリーミング・クライアント・デバイスは、ネットワークにおける１つ以上のネットワーク・ノード、例えば、１つ以上のＨＡＳサーバと通信し、適応ストリーミング・プロトコルに基づいてネットワーク・ノードにタイル・ストリームのセグメントを要求し受信するためのインターフェースを含むことができる。

【0105】

図１Ｃは、モザイク・タイル・ジェネレータを更に詳しく図示する。図１Ｃに示すように、メディア・ソース１０８_２、１０８_３によって生成されたメディア・ストリーム１１０_２、１１０_３を、モザイク・タイル・ジェネレータに送信することができる。モザイク・タイル・ジェネレータは、メディア・ストリームをタイルド・モザイク・ストリームに変換する１つ以上のタイリング・モジュール１２６を含むことができ、タイルド・モザイク・ストリームのビデオ・フレームにおける各タイル（またはタイルの少なくとも一部）のビジュアル・コンテンツは、メディア・ストリームのビデオ・フレームにおけるビジュアル・コンテンツの（倍率調整した）コピーである。つまり、タイルド・モザイク・ストリームは、ビデオ・モザイクを表し、各タイルのコンテンツがメディア・ストリームのビジュアル・コピーを表す。１つ以上のタイル・ストリーム・フォーマッタ１２８は、タイルド・モザイク・ストリームに基づいて、別個のタイル・ストリームおよび関連マニフェスト・ファイル１１４_１、１１４_２を生成するように構成することができ、これらはネットワーク・ノード１１６の記憶媒体上に格納することができる。一実施形態では、タイリング・モジュールをメディア・ソースに実装することもできる。他の実施形態では、ネットワークにおけるネットワーク・ノードにタイリング・モジュールを実装することもできる。タイル・ストリームは、デコーダ・モジュール（本開示において定めるようなタイルの概念をサポートする）に特定のタイル配列（例えば、タイルの寸法、ビデオ・フレームにおけるタイルの位置等）について知らせるためのデコーダ情報と関連付けることができる。

【0106】

図１Ａ〜図１Ｃを参照して説明したビデオ・モザイク・コンポーザ・システムは、コンテンツ配給システムの一部として実装することもできる。例えば、ビデオ・モザイク・コンポーザ・システム（の一部）を、コンテンツ配信ネットワーク（ＣＤＮ）の一部として実装してもよい。更に、図では、クライアント・デバイスが（移動体）メディア・デバイスに実装されているが、クライアント・デバイス（の機能の一部）もネットワークに、具体的には、ネットワークのエッジに実装することもできる。

【0107】

図２Ａ〜図２Ｃは、本発明の種々の実施形態によるタイリング・モジュールを図示する。具体的には、図２Ａは、特定のメディア・フォーマットのメディア・ストリーム２０２を受信するための入力を含むタイリング・モジュール２００を図示する。必要なときに、タイリング・モジュール内のデコーダ・モジュール２０４が、エンコード・メディア・ストリーム(encoded media stream)を、画素ドメインにおける処理を可能にするデコード未圧縮メディア・ストリーム(decoded uncompressed media stream)に変換することができる。例えば、一実施形態では、メディア・ストリームを、生ビデオ・フォーマットを有するメディア・ストリームにデコードすることができる。メディア・ストリームの生メディア・データをモザイク・ビルダ２０６に供給することができる。モザイク・ビルダ２０６は、画素ドメインにおいてモザイク・ストリームを形成するように構成されている。このプロセスの間、デコード・メディア・ストリームのビデオ・フレームを拡縮調整することができ、拡縮調整したフレームのコピーを格子構成（モザイク）に並べることができる。このように配列されたビデオ・フレームの格子を互いにスティッチされて、小区域を含む画像領域を表すビデオ・フレームにすることができ、各小区域が元のメディア・ストリームのビジュアル・コピーを表す。したがって、モザイク・ストリームは、ビデオ・ストリームのＮ×Ｍの視覚的に同一である複製のモザイクを含むことができる。

【0108】

次いで、ビデオ・モザイクを表すビットストリームをエンコーダ・モジュール２０８に転送する。エンコーダ・モジュール２０８は、このビットストリームを、タイルド・ビデオ・フレームを表すエンコード・メディア・データを含むタイルド・モザイク・ストリーム２１０_１にエンコードするように構成され、タイルド・ビデオ・フレームにおける各タイルのメディア・データは独立してエンコードすることができる。例えば、エンコーダ・モジュールは、タイルをサポートするコデックに基づくエンコーダ、例えば、ＨＥＶＣエンコーダ・モジュール、ＶＰ９エンコーダ・モジュール、またはその派生物であってもよい。

【0109】

ここで、モザイク・ストリームのビデオ・フレームにおける小区域の寸法、およびタイルド・モザイク・ストリームのタイルド・ビデオ・フレームにおけるタイルの寸法は、各小区域がタイルと一致するように選択すればよい。モザイク・ビルダは、モザイク・ストリームのビデオ・フレームにおける小区域の数および／または寸法を決定するために、区分情報２１２を使用することができる。

【0110】

モザイク・ストリームは、ストリームが所定の格子サイズを有するモザイク・ストリームを表すこと、およびモザイク・ストリームをタイルド・モザイク・ストリームにエンコードする必要があることを、エンコーダに知らせるためにエンコーダ情報２１４と関連付けることができる。タイル格子はモザイク・ストリームの小区域の格子と一致する。したがって、エンコーダ情報は、エンコーダがモザイク・ストリームのビデオ・フレームにおける小区域の格子と一致するタイルの格子を有するタイルド・ビデオ・フレームを生成する命令を含むことができる。更に、エンコーダ情報は、ビデオ・ストリームにおけるタイルのメディア・データを、アドレス可能なデータ構造（例えば、ＮＡＬユニット）にエンコードするための情報を含むことができ、後続のビデオ・フレームにおけるタイルのメディア・データは、独立してデコードすることができる。

【0111】

モザイク・ストリームのビデオ・フレームにおける小区域の格子サイズについての情報（例えば、区分情報２１２）は、生成したタイルド・ビデオ・フレームに関連するタイル格子の寸法を設定するための格子サイズ情報（例えば、タイルの寸法およびビデオ・フレームにおけるタイルの数）を決定するために使用することができる。

【0112】

１つ以上のタイルド・メディア・ストリームに基づく独立タイル・ストリームの形成、およびタイル・ストリームに基づくクライアント・デバイスによるモザイク・ビデオの形成を可能にするために、タイル・ビデオ・フレームの１つのタイルのメディア・データは、厳格に区切られたアドレス可能なデータ構造内に含まれなければならない。このデータ構造は、エンコーダによって生成することができ、更にデコーダ、および受信メディア・データがデコーダの入力に供給される前にそれを処理するクライアント側の任意の他のモジュールによって個々に処理することができる。

【0113】

例えば、一実施形態(one embodiment)では、タイルド・ビデオ・フレームにおける１つのタイルに関連するエンコード・メディア・データは、H．２６４／ＡＶＣおよびＨＥＶＣビデオ・コーディング規格から知られているようなネットワーク抽象化レイヤ（ＮＡＬ）ユニットに構造化されてもよい。ＨＥＶCエンコーダの場合、これは、１つのＨＥＶＣタイルが１つのＨＥＶＣスライスを構成することを要求することによって行うことができる。ここで、ＨＥＶＣスライスは、１つの独立したスライス・セグメント、および ＨＥＶＣ仕様によって定められる同じアクセス・ユニット内にある次の独立スライス・セグメント（ある場合）に先立つ全ての後続の依存スライス・セグメント（ある場合）に含まれる整数個のコーディング・ツリー・ユニットを定める。この要件は、エンコーダ情報において、エンコーダ・モジュールに送ることができる。

【0114】

エンコーダ・モジュールが、１つのＨＥＶＣスライスを含む１つのＨＥＶＣタイルを生成するように構成される場合、エンコーダ・モジュールは、ネットワーク抽象化レイヤ（ＮＡＬ）のレベルでフォーマットされたエンコード・タイルド・ビデオ・フレームを生成することができる。これは、図２Ｂに模式的に図示されている。この図に示されているように、タイルド・ビデオ・フレーム２１０は、複数のタイル、例えば、図２Ｂの例では９個のタイルを含むことができ、各タイルは、メディア・ストリームのビジュアル・コピー、例えば、同じメディア・ストリームまたは２つ以上の異なるメディア・ストリームを表す。エンコード・タイルド・ビデオ・フレーム２２４は、ＨＥＶＣ規格において定められるメタデータ（例えば、ＶＰＳ、ＰＰＳ、およびＳＰＳ）を含む非ＶＣＬ ＮＡＬユニット２１６を含むことができる。非ＶＣＬ ＮＡＬユニットは、デコーダ・モジュールに、メディア・データの品質レベル、メディア・データをエンコードおよびデコードするために使用されるコデック等について知らせることができる。非ＶＣＬに続いて、ＶＣＬ ＮＡＬユニット２１８〜２２２のシーケンスが位置することができ、各ＮＡＬユニットは、１つのタイルに関連するスライス（例えば、Ｉ−スライス、Ｐ−スライス、またはＢ−スライス）を含む。言い換えると、各ＶＣＬ ＮＡＬユニットは、タイルド・ビデオ・フレームの１つのエンコード・タイルを含むことができる。スライス・セグメントのヘッダは、タイル位置情報、即ち、デコーダ・モジュールにビデオ・フレームにおけるタイルの位置（メディア・フォーマットはスライス当たり１つのタイルに制限されるので、これはスライスと同等である）について知らせるための情報を含むことができる。この情報は、ＨＥＶＣ仕様によって定められるピクチャのコーディング・ツリー・ブロック・ラスタ・スキャンにおける、slice_segment_addressパラメータによって与えることができ、このslice_segment_addressパラメータは、スライス・セグメントにおける最初のコーディング・ツリー・ブロックのアドレスを指定する。slice_segment_addressパラメータは、ビットストリームからの１つのタイルに関連するメディア・データを選択的に選別するために使用することができる。このように、非ＶＣＬ ＮＡＬユニットおよびＶＣＬ ＮＡＬユニットのシーケンスは、エンコード・タイルド・ビデオ・フレーム２２４を形成することができる。

【0115】

１つ以上のタイルド・メディア・ストリームに基づいて、独立してデコード可能なタイル・ストリームを生成するために、タイルド・メディア・ストリームの後続のビデオ・フレームにおけるタイルのメディア・データが独立してエンコードされるように、エンコーダを構成しなければならない。独立してエンコードされたタイルは、エンコーダの相互予測機能(inter-prediction functionality）を無効にすることによって達成してもよい。あるいは、独立してエンコードされたタイルは、相互予測機能を有効にすることによって達成するのでもよい（例えば、圧縮効率の理由のため）。しかしながら、その場合、エンコーダは、
−タイル境界を跨ぐインループ・フィルタリング(in-loop filtering)を無効にする。
−時間的タイル間依存性がない。
−２つの異なるフレームにおける２つのタイル間に依存性がない（複数の連続フレームにおける１つの位置においてタイルの抽出を可能にするため）、
ように構成しなければならない。

【0116】

したがって、その場合、相互予測の動きベクトルを、メディア・ストリームの複数の連続ビデオ・フレームにわたってタイル境界内に制限する必要がある。

【0117】

以下で示すように、ＮＡＬユニットのような、エンコーダ／デコーダ・レベルで個々に処理することができる、厳格に区切られたアドレス可能データ構造に基づく、タイルのメディア・データの操作は、本開示において説明するように、多数の（a number of)タイル・ストリームに基づくビデオ・モザイクの形成には特に有利である。

【0118】

図２Ａを参照して説明したエンコーダ情報は、モザイク・ストリームのビットストリームにおいて、または帯域外通信チャネルにおいて、エンコーダ・モジュールに移送する(transport)ことができる。図２Ｃに示すように、ビットストリームは、フレーム２３０のシーケンス（各々、ｎ個のタイルのモザイクを視覚的に含む）を含むことができ、各フレームは、補足強化情報（ＳＥＩ：supplemental enhancement information）メッセージ２３２、およびビデオ・フレーム２３４を含む。エンコーダ情報は、ＳＥＩメッセージとして、Ｈ．２６４／ＭＰＥＧ−４系コデックを使用してエンコードされるＭＰＥＧストリームのビットストリームに挿入することができる。ＳＥＩメッセージは、補足強化情報（ＳＥＩ）を含むＮＡＬユニットとして定めることができる（ＩＳＯ／ＩＥＣ１４４９６−１０ＡＶＣにおける７．４．１ＮＡＬユニットのセマンティクスを参照のこと）。ＳＥＩメッセージ２３６は、タイプ５メッセージ、即ち、未登録ユーザ・データとして定めることもできる。未登録ユーザ・データと呼ばれるＳＥＩメッセージ・タイプは、任意のデータをビットストリーム内で搬送することを可能にする。ＳＥＩメッセージは、エンコーダ情報を指定するための所定数のパラメータを含むことができ、即ち、エンコーダ２０８が生成する必要があるタイルの配列を含む所定数のパラメータを含むことができる。これらのパラメータは、真のときにタイルの行およびタイルの列の均一間隔を知らせるフラグを含むことができ、行および列の数を導き出すことができる１対の整数がこのフラグに付随する。均一間隔フラグが偽であるとき、２つの整数のベクトルが出されて、これらの整数から、各タイルの幅および高さをそれぞれ導き出すことができる。ＳＥＩメッセージは、デコーディングのプロセスを補助するために、特別な情報を搬送することができる。しかしながら、これらの存在は、準拠するデコーダがこの特別な情報を考慮に入れなくてもよいようにデコード信号を組み立てる(construct)ために、必須ではない。種々のＳＥＩメッセージおよびそれらのセマンティクス（添付Ｄ．２）は、ＩＳＯ／ＩＥＣ１４４９６−１０：２０１２において定められている。ＳＥＩメッセージは、Ｈ．２６５／ＨＥＶＣ系コデックを使用してエンコードされるＭＰＥＧストリームとでも同様に使用することができる。種々のＳＥＩメッセージおよびそれらのセマンティクス（添付Ｄ．３）は、ＩＳＯ／ＩＥＣ２３００８−２：２０１３において定められている。

【0119】

本発明の他の実施形態では、エンコーダ情報をコード化ビットストリーム(coded bitstream)において移送することもできる。フレーム・ヘッダにおけるブール・フラグは、このような情報が存在するか否か示すことができる。フラグがセットされている場合、フラグに続くビットは、エンコーダ情報を表すことができる。

【0120】

更に他の実施形態では、エンコーダ情報をビデオ・コンテナにおいて移送することもできる。例えば、ＩＳＯＢＭＦＦファイル・フォーマット（ＩＳＯ／ＩＥＣ１４４９６−１２）のようなビデオ・コンテナにおいてエンコーダ情報を移送するのでもよい。ＩＳＯＢＭＦＦファイル・フォーマットは、１組のボックスを指定し、メディア・データおよびそれに関連するメタデータを格納するおよびそれにアクセスするための階層構造を形作る(constitute)。例えば、コンテンツに関係するメタデータのルート・ボックスは「ｍｏｏｖ」ボックスであり、一方メディア・データは「ｍｄａｔ」ボックスに格納される。更に特定すれば、「ｓｔｂｌ」ボックス即ち「サンプル・テーブル・ボックス」は、トラックのメディア・サンプルにインデックスを付けて、追加データを各サンプルと関連付けることを可能にする。ビデオ・トラックの場合、サンプルはビデオ・フレームである。その結果、「タイル・エンコーダ情報」または「ｓｔｅｉ」と呼ばれる新しいボックスをボックス「ｓｔｂｌ」内に追加すると、ビデオ・トラックのフレームと共にエンコーダ情報を格納するために使用することができる。

【0121】

一実施形態では、図２Ａのタイリング・モジュールは、スケーリング・モジュール２０５を含んでもよい。スケーリング・モジュール２０５は、メディア・ストリームのビデオ・フレームのコピーを拡縮調整、例えば、拡大または縮小するために使用することができる。ここで、拡縮調整されたビデオ・フレームは、モザイク・ストリームのビデオ・フレームにおける小区域の境界が、タイル・エンコーダ・モジュールによって生成されたタイルド・モザイク・ストリームにおけるタイルド・ビデオ・フレームのタイル格子と一致するように、整数個の小区域をカバーするとよい。モザイク・ビルダは、画素ドメインにおいてエンコード・モザイク・ストリームを構築するために、この拡縮調整されたビデオ・フレームを使用することができ、モザイク２１０２、２１０３（の一部）は図２Ａに示すサイズと異なっていてもよい。このようなモザイク・ストリームは、例えば、個人専用化「ピクチャ・イン・ピクチャ」ビデオ・モザイクを形成するため、または拡大強調(enlarged highlighting)を可能にするために使用することもできる。図２Ａの例では、タイルの数は同じままである。他の実施形態では、ビデオ・フレームが異なる寸法のタイルを含んでもよい。

【0122】

したがって、図２Ａ〜図２Ｃを参照して説明したタイリング・モジュールは、タイルをサポートするエンコーダ、例えば、タイルド・モザイク・ストリーム、即ち、ＨＥＶＣ準拠ビットストリームを生成するように構成された（標準的な）ＨＥＶＣエンコーダを使用する、メディア・ストリームに基づくタイルド・モザイク・ストリームの形成を可能にし、ビデオ・フレームにおけるタイルのメディア・データはＶＣＬ ＮＡＬユニットとして組み立てられ(structured)、タイルド・ビデオ・フレームを形成するメディア・データは、非ＶＣＬ ＮＡＬユニットおよびそれに続くＶＣＬ ＮＡＬユニットのシーケンスとして組み立てられる。タイルド・モザイク・ストリームのタイルド・ビデオ・フレームは、タイルを含み、ビデオ・フレームにおけるタイルのメディア・データは、同じビデオ・フレームにおける他のタイルのメディア・データに関して、独立してデコード可能である。ビデオ・フレームにおける所与のタイルのメディア・データは、その所与のタイルの同じ位置における他のビデオ・フレームにおけるタイルのメディア・データに関して、独立してデコード可能でなくてもよい。つまり、これらのタイルの各々のメディア・データは、異なるビデオ・フレームにおいて同じ所定の位置にあるときには恐らく独立ではない(dependent)が、独立モザイク・タイル・ストリームを形成するために使用することができる。これらの実施形態は、ＮＡＬユニットに関連するメタデータ、即ち、非ＶＣＬ ＮＡＬユニットのコンテンツおよびＶＣＬ ＮＡＬユニットのヘッダを書き直す必要なくＮＡＬユニットのレベルで処理することができるタイルド・メディア・ストリームを生成するように構成されたエンコーダの利点を活用する。

【0123】

図３は、本発明の他の実施形態によるタイリング・モジュールを図示する。この特定の実施形態では、ＮＡＬ解析モジュール３０４は、エンコードされた着信メディア・ストリーム（メディア・ストリーム）のＮＡＬユニットをソートして、２つのカテゴリ、即ち、ＶＣＬ ＮＡＬユニットおよび非ＶＣＬ ＮＡＬユニットに分けるように構成することができる。ＶＣＬ ＮＡＬユニットは、ＮＡＬ複製モジュール３０６によって複製することができる。コピーの数は、特定の格子レイアウトのモザイクを形成するために必要とされるＮＡＬユニットの量と等しくすればよい。

【0124】

ＶＣＬ ＮＡＬユニットのヘッダは、ＮＡＬ書き換えモジュール３１０〜３１４によって、Sanchez et al.において記載されたようなプロセスを使用して、書き換えることができる。このプロセスは、発信する(outcoming)ＮＡＬユニットが同じビットストリームであるが、ピクチャの異なる領域に対応する異なるタイルに属するような方法で、着信する(incoming)ＮＡＬユニットのスライス・セグメント・ヘッダを書き換える動作を含むことができる。例えば、フレームにおける最初のＶＣＬ ＮＡＬユニットは、ＮＡＬユニットが、特定のビデオ・フレームに関連するビットストリームにおいて最初のＮＡＬユニットであることを印するためにフラグ（first_slice_segment_in_pic_flag）を含むことができる。また、非ＶＣＬ ＮＡＬユニットも、Sanchez et al.において記載されたようなプロセスに続いて、ＮＡＬ書き換えモジュール３０８によって書き換えることができる。即ち、ビデオの新たな特性に適合するために、ビデオ・パラメータ集合（ＶＰＳ）を書き換える。書き換え段階の後、ＮＡＬユニットは、ＮＡＬリコンバイナ・モジュール(recombiner module)３１６によって、タイルド・モザイク・ストリーム３１８を表すビットストリームに再度組み入れられる。したがって、この実施形態では、タイリング・モジュールは、タイルド・モザイク・ストリーム、即ち、タイルド・ビデオ・フレームを含むメディア・ストリームの形成を可能にし、タイルド・ビデオ・フレームにおける各タイルは、特定のメディア・ストリームのビデオ・フレームのビジュアル・コピーを表す。これは、タイルド・モザイク・ストリームの生成を高速化することを可能にする。タイルは一回エンコードされ、次いで、ｎ回タイルを複製する代わりに、ｎ回複製され、次いでエンコーディングをｎ回実行する。本実施形態は、サーバにおける完全なデコーディングまたは再エンコーディングが必要でないという利点が得られる。

【0125】

図４は、本発明の実施形態による一斉タイリング・モジュール(coordinated tiling modules)のシステムを図示する。具体的には、図４は、複数のタイリング・モジュール４０６_１、４０６_２に基づいて複数のメディア・ストリーム（よくあること）を複数のタイルド・モザイク・ストリームに変換するときに必要とされる調整について記載する。この場合、メディア・ソース４０２_１、４０２_２、例えば、カメラまたはコンテンツ・サーバは、これらのフレーム・レートが同期することを確保するために、時間同期することが必要となる。このタイプの同期は、ジェネレータ・ロッキング、即ち、ジェン・ロッキング(gen-locking)としても知られている。複数のカメラからのメディア・ストリームの収集(ingest)が複数の収集ノードにわたって分散されるとき（例えば、メディア・ストリームがＣＤＮ内部で処理される場合）、収集された各ストリームの中にタイムスタンプを挿入することによって、更に同期させることもできる。タイムスタンプ挿入の分散(distributed timestamping)は、収集ノードのクロックを時間同期プロトコル４１０と同期させることによって行うことができる。このプロトコルは、ＰＴＰ（高精度時刻プロトコル）または企業固有の時間同期プロトコルのような、標準的なプロトコルであればよい。メディア・ソースが互いにジェン・ロックされ、同じ基準クロックを使用してストリームにタイムスタンプが挿入された場合、全てのメディア・ストリーム４０４_１、４０４_２、および関連するタイルド・モザイク・ストリーム４０８_１、４０８_２は互いに同期される。

【0126】

カメラのジェン・ロックが可能でない場合、様々な代替解決案が利用可能である。一実施形態では、各タイリング・モジュールの入力がジェン・ロックされるように、タイリング・モジュール４０６_１、４０６_２の入力にトランスコーダを配置することができる。トランスコーダは、例えば、付随的に(incidentally)フレームを欠落させるまたは複製フレームを挿入することによって、あるいはフレーム間の内挿補間によって、フレーム・レートを小さな端数だけ変更するように構成することができる。このように、タイリング・モジュールは、それらのトランスコーダをジェン・ロックすることによって、互いにジェン・ロックすることができる。このようなトランスコーダは、タイリング・モジュールの入力の代わりに、出力に配置することもできる。あるいは、タイリング・モジュールがジェン・ロックすることができるエンコーダ・モジュールを有する場合、異なるタイリング・モジュールのエンコーダ・モジュールを互いにジェン・ロックするのでもよい。

【0127】

加えて、一斉タイリング・モジュール４０６_１、４０６_２には、同一の構成パラメータ４１２、例えば、タイルの数、フレーム構造、およびフレーム・レートを設定する(configure)必要がある。その結果、異なるタイリング・モジュールの出力において得られる非ＶＣＬ ＮＡＬユニットは同一になるはずである。タイリング・モジュールの構成設定(configuration)は、手作業の構成設定によって１回実行するか、または構成管理解決案(configuration-management solution)によって調整してもよい。

【0128】

図５は、本発明の更に他の実施形態によるタイリング・モジュールの使用を図示する。この特定的な場合では、少なくとも２つ（即ち、複数）のメディア・ソース５０２_１、５０２_２が、フレームがタイリング・モジュール５０６に供給されるときに、そのフレーム・レートが同期していることを確保するために、これらを時間同期させることができる。タイリング・モジュールは、第１および第２メディア・ストリームを受信し、複数のメディア・ストリームに基づいて、タイルド・モザイク・ストリーム５０８_１、５０８_２を形成することができる。図５のタイルド・モザイク・ストリームの例によって示されるように、タイルド・モザイク・ストリームのタイルド・ビデオ・フレームのタイルはいずれも、それぞれ、第１または第２メディア・ストリームのビデオ・フレームのビジュアル・コピーである。したがって、本実施形態では、タイルド・ビデオ・フレームのタイルは、タイリング・モジュールに入力されるメディア・ストリームのビジュアル・コピーを構成する(comprise)。

【0129】

図６は、本発明の一実施形態によるタイル・ストリーム・フォーマッタを図示する。図６に示すように、タイル・ストリーム・フォーマッタは、１つ以上のフィルタ・モジュール６０４_１、６０４_２を含むことができ、フィルタ・モジュールは、タイルド・モザイク・ストリーム６０２_１、６０２_２を受信および解析し、タイルド・モザイク・ストリームから、タイルド・ビデオ・フレームにおける特定のタイルに関連するメディア・データ６０６_１、６０６_２を抽出するように構成されている。これらの分割メディア・データをセグメント化モジュール(segmenter module)６０８_１、６０８_２に転送することができ、セグメント化モジュール(segmenter module)６０８_１、６０８_２は、所定のメディア・フォーマットに基づいてメディア・データを組み立てる(structure)ことができる。図６に示すように、タイルド・モザイク・ストリームに基づいて１組のモザイク・タイル・ストリーム（この例では４つのタイル・ストリーム）を生成することができ、１つのタイルド・モザイク・タイル・ストリームは、メディア・データと、デコーダ・モジュールについてのデコーダ情報とを含み、デコーダ情報は、ビデオ・フレームにおけるタイルの位置、およびタイルの寸法（サイズ）を判定することができるタイル位置情報を含むことができる。タイル・ストリームがＮＡＬユニットに基づいてフォーマットされる場合、デコーダ情報は、非ＶＣＬ ＮＡＬユニットおよびＶＣＬ ＮＡＬユニット（のヘッダ）に格納することができる。

【0130】

図６の実施形態では、メディア・データをクライアント・デバイスに送信するために、ＨＴＴＰ適応ストリーミング・プロトコルを使用することもできる。使用することができるＨＴＴＰ適応ストリーミング・プロトコルの例には、Ａｐｐｌｅ ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ、Ｍｉｃｒｏｓｏｆｔ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ、Ａｄｏｂｅ ＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ、３ＧＰＰ−ＤＡＳＨ、ＨＴＴＰ累進ダウンロードおよび動的適応ストリーミング(Progressive Download and Dynamic Adaptive Streaming over HTTP)、ならびにＨＴＴＰ ＭＰＥＧ動的適応ストリーミング(MPEG Dynamic Adaptive Streaming over HTTP)［ＭＰＥＧ ＤＡＳＨ ＩＳＯ／ＩＥＣ２３００９］が含まれる。これらのストリーミング・プロトコルは、ビデオおよび／またはオーディオ・データのような（通常）時間的にセグメント化されるメディア・データをＨＴＴＰを介して転送するように構成される。このように時間的にセグメント化されるメディア・データを、通常チャンクと呼ぶ。チャンクをフラグメント（もっと大きなファイルの一部として格納される）、またはセグメント（別個のファイルとして格納される）と呼ぶこともある。チャンクは、任意の再生期間を有することができる。しかしながら、通例、期間は１秒および１０秒の間である。ＨＡＳクライアント・デバイスは、ネットワーク、例えば、コンテンツ配信ネットワーク（ＣＤＮ）にＨＡＳセグメントを順次要求することによってビデオ・タイトルをレンダリングし、ビデオ・タイトルの継ぎ目ないレンダリングが確保されるように、要求および受信したチャンクを処理することができる。

【0131】

したがって、セグメント化モジュールは、タイルド・モザイク・ストリームのタイルド・ビデオ・フレームにおける１つのタイルに関連するメディア・データをＨＡＳセグメント６１０_１、６１０_２に組み立てることができる。ＨＡＳセグメントは、所定のメディア・フォーマットに基づいて、ネットワーク・ノード６１２、例えば、サーバの記憶媒体上に格納することができる。セグメント化モジュールによるＨＡＳセグメントの形成および格納の間、１つ以上のマニフェスト・フィアル（ＭＦ）６１６_１、６１６_２をマニフェスト・ファイル・ジェネレータ６２０によって生成することができる。タイル・ストリーム毎に、マニフェスト・ファイルは、セグメント識別子、例えば、１つ以上のＵＲＬまたはその一部のリストを含むことができる。このように、マニフェスト・ファイルは、ビデオ・モザイクを構成する(compose)ために使用することができる１組のタイル・ストリームについての情報を収容することができる。タイル・セグメント毎に、または少なくともその一部について、マニフェスト・ファイルはタイル位置記述子を含むことができる。一実施形態では、ＭＰＥＧ−ＤＡＳＨ準拠のマニフェスト・ファイルの場合、メディア・プレゼンテーション記述（ＭＰＤ）、即ち、タイル位置記述子は、ＤＡＳＨ仕様において定められるような空間関係記述（ＳＲＤ）記述子のシンタックスを有する。このようなＳＲＤ−ＭＰＤの例について、以下で更に詳しく説明する。クライアント・デバイスは、マニフェスト・ファイルを使用して、ビデオ・モザイクを構成する(compose)ためにクライアント・デバイスに入手可能な１組のモザイク・タイル・ストリームから１つ以上のモザイク・タイル・ストリーム（およびそれらの関連ＨＡＳセグメント）を選択することができる。例えば、一実施形態では、ユーザがＧＵＩと対話処理して、個人専用化ビデオ・モザイクを構成することもできる。

【0132】

図６に示すように、モザイク・タイル・ストリームは、記憶媒体上に特定のメディア・フォーマットに基づいて格納することができる。例えば、一実施形態では、１組のモザイク・タイル・ストリーム６１４_１、６１４_２を、記憶媒体上にメディア・データ・ファイルとして格納することができる。各タイル・ストリームは、データ構造のトラックとして格納することができ、タイル・ストリーム識別子に基づいて、クライアント・デバイスによってトラックに独立してアクセスすることができる。データ構造内に格納されているモザイク・タイル・ストリーム間の（空間）関係についての情報は、データ構造のメタデータ部に格納することができる。加えて、この情報は、クライアント・デバイスによって使用することができるマニフェスト・ファイル６１６_１、６１６_２にも格納することができる。他の実施形態では、クライアント・デバイスが関連マニフェスト・ファイル６１６_３に基づいてモザイク・タイル・ストリームの所望の選択を要求することができるように、異なる複数組のモザイク・タイル・ストリーム（各組のタイル・ストリームは、１つ以上のメディア・ストリームに基づいて形成することができる）を、メディア・フォーマット６１４_３に基づいて格納することができる。

【0133】

更に、マニフェスト・ファイルは、ＨＡＳセグメントをクライアント・デバイスに送信するように構成されたネットワーク・エレメント、例えば、メディア・サーバまたはネットワーク・キャッシュの位置を判定するために、位置情報（通常、ＵＲＬの一部、例えば、ドメイン名）も含むことができる。セグメント（の一部）は、これらの位置の１つへの経路内に位置するネットワークに存在する（透過性(transparent)）キャッシュから、またはネットワークにおいて要求ルーティング機能によって示される場所から引き出すことができる。

【0134】

マニフェスト・ファイル生成モジュール６１６は、マニフェスト・ファイル６１８を記憶媒体、例えば、マニフェスト・ファイル・サーバまたはその他のネットワーク・エレメント上に格納することができる。あるいは、マニフェスト・ファイルをＨＡＳストリームと一緒に記憶媒体上に格納することもできる。前述のように、複数のタイルド・モザイク・ストリーム（これは典型的な場合である）を処理する必要がある場合、セグメント化プロセスの追加の調整が必要となる場合がある。セグメント化モジュールは、同じコンフィギュレーション設定値を使用して並行して動作することができ、マニフェスト・ファイル・ジェネレータは、異なるセグメント化モジュールからのセグメントを参照するマニフェスト・ファイルを正しい方法で生成する必要がある。図６に図示するようなシステムにおける異なるモジュール間のプロセスの調整は、メディア構成プロセッサ(media composition processor)６２２によって制御することができる。

【0135】

図７Ａ〜図７Ｄは、本発明の種々の実施形態にしたがって、タイル・ストリームを形成するプロセス、およびモザイク・タイル・ストリームを格納するためのメディア・フォーマットを図示する。図７Ａは、タイルド・モザイク・ストリームに基づいてタイル・ストリームを形成するプロセスを図示する。第１ステップにおいて、ＮＡＬユニット７０２_１、７０４_１、７０６_１をタイルド・モザイク・ストリームから抽出し（選別し）、個々のＮＡＬユニット（例えば、デコーダ・モジュールによってそのコンフィギュレーションを設定するために使用されるデコーダ情報を含む非ＶＣＬ ＮＡＬユニット７０２２（ＶＰＳ、ＰＰＳ、ＳＰＳ）、および各々タイル・ストリームのビデオ・フレームを表すメディア・データを含むＶＣＬ ＮＡＬユニット７０４_２、７０６_２）に分離することができる。ＶＣＬ ＮＡＬユニットにおけるスライス・セグメントのヘッダは、ビデオ・フレームにおけるタイル（スライス）の位置を定めるタイル位置情報（または、１つのスライスが１つのタイルを収容するので、スライス位置情報）を含むことができる。

【0136】

このようにして選択されたＮＡＬユニットまたはＮＡＬユニットの集合体は、ＨＴＴＰ適応ストリーミング（ＨＡＳ）プロトコルによって定められるようなセグメントにフォーマットすることができる。例えば、図７Ａに示すように、第１ＨＡＳセグメント７０２_３は非ＶＣＬ ＮＡＬユニットを含むのでもよく、第２ＨＡＳセグメント７０２_３は第１位置と関連つけけられたタイルＴ１のＶＣＬ ＮＡＬユニットを含むのでもよく、第３ＨＡＳセグメント７０２_３は第２タイル位置と関連つけけられたタイルＴ２のＶＣＬ ＮＡＬユニットを含むのでもよい。所定のタイル位置において１つの特定のタイルに関連するＮＡＬユニットを選別(filtering)し、これらのＮＡＬユニットを１つ以上のＨＡＳセグメントにセグメント化することによって、ＨＡＳフォーマットされたタイル・ストリームを、所定のタイル位置のタイルと関連付けて形成することができる。一般に、ＨＡＳセグメントは、適したメディア・コンテナ、例えば、ＭＰＥＧ２ ＴＳ、ＩＳＯ ＢＭＦＦ、またはＷｅｂＭに基づいてフォーマット化し、ＨＴＴＰ応答メッセージのペイロードとしてクライアント・デバイスに送ることができる。メディア・コンテナは、ペイロードを再現するために必要とされる全ての情報を含むことができる。一実施形態では、ＨＡＳセグメントのペイロードは、１つのＮＡＬユニットまたは複数のＮＡＬユニットでもよい。あるいは、ＨＴＴＰ応答メッセージは、メディア・コンテナは全くなく、１つ以上のＮＡＬユニットを含むのでもよい。

【0137】

したがって、非ＶＣＬ−ＮＡＬ（非ＶＣＬ ＮＡＬであるビデオ・パラメータ集合ＶＰＳ）およびＶＣＬ−ＮＡＬヘッダ（スライス・セグメント・ヘッダ）を書き換える必要があるという意味で、エンコード・ストリームを妨害するSanchez et al.に記載されている解決案とは対照的に、図７Ａに図示する解決案はＮＡＬユニットのコンテンツを変化させずに残す。

【0138】

図７Ｂは、本発明の一実施形態にしたがって１組のモザイク・タイル・ストリームを格納するためのメディア・フォーマット（データ構造）を図示する。具体的には、図７Ｂは、複数、この場合４つの、タイル７１４_１〜７１４_４を含むビデオ／フレームを含むタイルド・ビデオ・モザイク・メディア・ストリームに基づいて生成することができるモザイク・タイル・ストリームを格納するためのＨＥＶＣメディア・フォーマットを図示する。個々のタイルに関連するメディア・データは、図７Ａを参照して説明したプロセスにしたがって、選別およびセグメント化することができる。その後、タイル・ストリームのセグメントは、個々のタイル・ストリームのメディア・データへのアクセスを可能にするデータ構造に格納することができる。一実施形態では、このメディア・フォーマットは、ＩＳＯ／ＩＥＣ１４４９６−１５またはその同等物において定められているＨＥＶＣファイル・フォーマット７１０としてもよい。図７Ｂに図示するメディア・フォーマットは、メディア・デバイスにおけるクライアント・デバイスがタイル・ストリームの部分集合のみ、例えば、複数のタイル・ストリームの内１つのタイル・ストリームの送信を要求することができるように、タイル・ストリームのメディア・データを１組の「トラック」として格納するために使用することができる。このメディア・フォーマットは、クライアント・デバイスが、ビデオ・モザイクの全てのタイル・ストリームを要求する必要なく、タイル・ストリームに個々に、例えば、そのストリーム識別子（例えば、ファイル名等）に基づいてアクセスすることを可能にする。タイル・ストリーム識別子は、マニフェスト・ファイルを使用して、クライアント・デバイスに供給することができる。図７Ｂに示すように、メディア・フォーマットは１つ以上のタイル・トラック７１８_１〜７１８_４を含むことができ、各タイル・トラックは、タイル・ストリームのメディア・データ７２０_１〜７２０_４、例えば、ＶＣＬおよび非ＶＣＬ ＮＡＬユニットのためのコンテナとして役割を果たす。

【0139】

一実施形態では、トラックは、更に、タイル位置情報７１６_１〜７１６_４も含むことができる。トラックのタイル位置情報は、対応するファイル・フォーマットのタイル関係ボックスに格納することができる。デコーダ・モジュールは、モザイクのレイアウトを初期化するために、タイル位置情報を使用することができる。一実施形態では、トラックにおけるタイル位置情報は、基準空間、通例では、ビデオの輝度成分の画素座標によって定められる空間においてタイルを視覚的に位置付けることをデコーダ・モジュールが行えるようにするために、原点およびサイズ情報を含むとよく、この空間における位置は、画像全体に関連する座標系によって決定することができる。デコーディング・プロセスの間、デコーダ・モジュールは、好ましくは、ビットストリームをデコードするために、エンコード・ビットストリームからのタイル情報を使用する。

【0140】

一実施形態では、トラックは、更に、トラック・インデックス７２２_１〜７２２_４も含むことができる。トラック・インデックスは、特定のトラックに関連するメディア・データを識別するために使用することができるトラック識別番号を示す(provide)。

【0141】

図７Ｂに図示するメディア・フォーマットは、更に、いわゆるベース・トラック７１６も含むことができる。ベース・トラックは、メディア・デバイスにおけるメディア・エンジンが、特定のタイル・ストリームを要求したときにクライアント・デバイスが受信したＶＣＬ ＮＡＬユニットのシーケンス（順序）を判定することを可能にするシーケンス情報を含むことができる。具体的には、ベース・トラックはエキストラクタ(extractor)７２０_１〜７２０_４を含むことができ、エキストラクタは、１つ以上の対応するタイル・トラックにおけるメディア・データ、例えば、ＮＡＬユニットへのポインタを含む。

【0142】

エキストラクタは、ＩＳＯ／ＩＥＣ１４４９６−１５〜１５：２０１４において定められるようなエキストラクタでもよい。このようなエキストラクタには、メディア・エンジンが、エキストラクタ、トラック、およびトラックにおけるメディア・データ間の関係を判定することを可能にする１つ以上のエキストラクタ・パラメータと関連付けることができる。ＩＳＯ／ＩＥＣ１４４９６−１５：２０１４では、track_ref_index、sample_offset、data_offset、およびdata_lenghtパラメータを参照する。track_ref_indexパラメータは、メディア・データを抽出する必要があるトラックを発見するためにトラック参照として使用することができる。sample_offsetパラメータは、情報のソースとして使用することができるトラックにおけるメディア・データの相対インデックスを示す(provide)ことができる。data_offsetパラメータは、基準メディア・データ内においてコピーする最初のバイトのオフセットを示す（抽出がそのサンプルにおけるデータの最初のバイトから始まる場合、オフセットは０の値を取る。オフセットは、ＮＡＬユニット長フィールドの開始を知らせる）。data_lengthパラメータは、コピーするバイト数を示す（このフィールドが０の値を取る場合、１つの参照されたＮＡＬユニット全体をコピーする（即ち、コピーする長さは、データ・オフセットによって参照される長さフィールドから取り込まれる））。

【0143】

ベース・トラックにおけるエキストラクタは、メディア・エンジンによって解析され、ＮＡＬユニット、具体的には、参照するタイル・トラックのＶＣＬ ＮＡＬユニットにおけるメディア・データ（オーディオ、ビデオ、および／またはテキスト・データ）を含むＮＡＬユニットを識別するために使用することができる。したがって、エキストラクタのシーケンスは、メディア・デバイスにおけるメディア・エンジンが、ＮＡＬユニットを識別し、エキストラクタのシーケンスによって定められるようにＮＡＬユニットを順番に並べること、そしてデコーダ・モジュールの入力に供給される準拠ビットストリーム(compliant bitstream)を生成することを可能にする。

【0144】

ビデオ・モザイクは、１つ以上のタイル・トラック（特定のタイル位置と関連つけけられたタイル・ストリームを表す）、およびマニフェスト・ファイルにおいて識別されるベース・トラックからメディア・データを要求し、シーケンス情報、具体的には、エキストラクタに基づいてタイル・ストリームのＮＡＬユニットを順番に並べることによって、デコーダ・モジュールに合ったビットストリームを形成するために、形成することができる。デコーダに合ったビットストリームとは、そのデコーダによってデコード可能な（デコードすることができる）ビットストリームを意味する。言い換えると、デコーダによって使用されるコデックに準拠したビットストリームである。ビデオ・モザイクのタイルド・ビデオ・フレームにおける全てのタイル位置が必ずしもビジュアル・コンテンツを含む訳ではない。特定のビデオ・モザイクがタイルド・ビデオ・フレームにおける特定のタイル位置でビジュアル・コンテンツを必要としない場合、メディア・エンジンは、そのタイル位置に対応するエキストラクタを単純に無視すればよい。

【0145】

例えば、図７Ｂの例では、クライアント・デバイスがビデオ・モザイクを形成するためにタイル・ストリームＡおよびＢを選択したとき、ベース・ストリームおよびタイル・ストリーム１および２を要求することができる。メディア・エンジンは、デコーダ・モジュールに合ったビットストリームを形成するために、ベース・ストリームにおいて、タイル・トラック１およびタイル・トラック２のメディア・データを参照するエキストラクタを使用することができる。デコーダに合ったビットストリームとは、そのデコーダによってデコード可能な（デコードすることができる）ビットストリームを意味する。言い換えると、デコーダによって使用されるコデック（例えば、ＨＥＶＣ）に準拠したビットストリームである。タイル・ストリームＣおよびＤのメディア・データがないことは、デコーダ・モジュールによって「欠落データ」として解釈されればよい。トラック（各トラックは１つのタイル・ストリームのメディア・データを含む）におけるメディア・データは独立してデコード可能であるので、１つ以上のトラックからのメディア・データがなくても、デコーダ・モジュールが引き出すことができるトラックのメディア・データをデコードするのを妨げることにはならない。

【0146】

図７Ｃは、本発明の一実施形態によるマニフェスト・ファイルの例を模式的に図示する。具体的には、図７Ｃは、複数のタイル・ストリーム（この例では、４つのＨＥＶＣタイル・ストリーム）を定める複数のアダプテーション・セット７４０_２〜７４０_５エレメントを定めるＭＰＤを図示する。ここでは、アダプテーション・セットは、特定のメディア・コンテンツ、例えば、ビデオＡ、Ｂ、Ｃ、またはＤと関連つけけることができる。更に、各アダプテーション・セットは、１つ以上のリプリゼンテーション(Representation)、即ち、アダプテーション・セットにリンクされるメディア・コンテンツの１つ以上のコーディングおよび／または品質の変異(variant)も含むことができる。したがって、アダプテーション・セットにおけるリプリゼンテーションは、タイル・ストリーム識別子、例えば、ＵＲＬの一部に基づいてタイル・ストリームを定めることができ、ネットワーク・ノードにタイル・ストリームのセグメントを要求するために、クライアント・デバイスによって使用することができる。図７Ｃの例では、アダプテーション・セットの各々が、１つのリプリゼンテーションを含む（タイル・ストリームが以下のビデオ・モザイクを形成することができるように、特定のタイル位置と関連つけけられた１つのタイル・ストリームを表す）。

【表2】

【0147】

タイル・ストリームは、図７Ｂを参照して説明したような、ＨＥＶCメディア・フォーマットを使用して、ネットワーク・ノード上に格納することができる。

【0148】

ＭＰＤにおけるタイル位置記述子は、１つ以上の空間関係記述（ＳＲＤ）記述子７４２_１〜７４２_５として、フォーマットすることができる。ＳＲＤ記述子は、マニフェスト・ファイルにおいて定められた異なるビデオ・エレメント間に特定の空間関係が存在することをクライアント・デバイスに知らせるために、EssentialPropertyエレメント（記述子を処理するときクライアント・デバイスによって理解されることが必要な情報）、または SupplementalPropertyエレメント（記述子を処理するときこれを知らないクライアント・デバイスによって破棄されてもよい情報）として使用することができる。一実施形態では、schemeldUri “urn:mpeg:dash:srd:2014”を含む空間関係記述子を、タイル位置記述子をフォーマットするためのデータ構造として使用することができる。

【0149】

タイル位置記述子は、ＳＲＤ記述子における数値パラメータに基づいて定めることができる。ＳＲＤ記述子は、互いに空間関係を有するビデオ・エレメントをリンクするSource_idパラメータを含むパラメータのシーケンスを構成する(comprise)ことができる。例えば、図７Ｃにおいて、各ＳＲＤ記述子におけるSource_idは、「１」の値に設定され、これらのアダプテーション・セットが、所定の空間関係を有する１組のタイル・ストリームを形成することを示す。Source_idパラメータの後ろには、タイル位置パラメータｘ，ｙ，ｗ，ｈが続くことができ、これらの位置パラメータは、ビデオ・フレームの画像領域におけるビデオ・エレメント（タイル）の位置を定めることができる。これらの座標から、タイルの寸法（サイズ）も判定することができる。ここで、座標値ｘ，ｙは、ビデオ・フレームの画像領域における小区域（タイル）の原点を定めることができ、寸法値ｗおよびｈは、このタイルの幅および高さを定めることができる。タイル位置パラメータは、所与の任意の単位、例えば、画素単位で表すことができる。クライアント・デバイスは、ＭＰＤにおいて定められたタイル・ストリームに基づいて、ユーザがビデオ・モザイクを構成する(compose)ことを可能にするＧＵＩを生成するために、ＭＰＤにおける情報、具体的には、ＳＲＤ記述子における情報を使用することができる。

【0150】

第１アダプテーション・セット７４０１のＳＲＤ記述子７４２１におけるタイル位置パラメータｘ，y，ｗ，ｈ，Ｗ，Ｈは、０に設定されることにより、このアダプテーション・セットはビジュアル・コンテンツを定めないが、他のアダプテーション・セット７４０_２〜７４０_５に定められているトラックにおけるメディア・データを参照するエキストラクタのシーケンスを含むベース・トラックを定めることを、クライアント・デバイスに知らせる（図７Ｂを参照して説明したのと同様の方法で）。

【0151】

タイル・ストリームのデコーディングには、デコーダがタイル・ストリームのビジュアル・サンプルをデコードするために必要とするメタデータが要求されることがある。このようなメタデータは、タイル格子（タイルの数および／またはタイルの寸法）、ビデオ分解能（または更に一般的に、全ての非ＶＣＬ ＮＡＬユニット、即ち、ＰＰＳ、ＳＰＳ、およびＶＰＳ）、デコーダ準拠ビットストリームを形成するためにＶＣＬ ＮＡＬユニットを連結しなければならない順序（例えば、本開示の他のところで説明したようなエキストラクタ等を使用する）に関する情報を含むとよい。メタデータがタイル・ストリーム自体の中にない場合（例えば、イニシャライゼーション・セグメント(Initialization Segment)を媒介とする）、タイル・ストリームは、そのメタデータを含むベース・ストリームに依存する場合がある。タイル・ストリームのベース・ストリームに対する依存性は、依存性パラメータによってＤＡＳＨクライアントに知らせることができる。この特定的な依存性パラメータを、本願全体を通じて、メタデータ依存性パラメータとも呼ぶ。メタデータ依存性パラメータ（ＭＰＥＧ ＤＡＳＨ規格では、この理由のために使用することができるパラメータは、dependencyIdパラメータと呼ばれることもある）は、ベース・ストリームを１つ以上のタイル・ストリームにリンクすることができる。

【0152】

アダプテーション・セット７４０_２〜７４０_５において定められるリプリゼンテーションは、リプリゼンテーション（タイル・ストリーム）をデコードするために必要とされるメタデータを含むいわゆるベース・トラック７４６_１を定めるアダプテーション・セット７４０_１におけるリプリゼンテーションid="mosaic-base"を逆に参照する dependencyldパラメータ７４４_２〜７４４_５（dependencyld="mosaic-base"）を含む。ＭＰＥＧ ＤＡＳＨ仕様におけるdependencyIdの使用事例の１つは、アダプテーション・セット内におけるリプリゼンテーションのコーディング依存性をクライアント・デバイスに知らせるために使用された。例えば、レイヤ間依存性があるスケーラブル・ビデオ・コーディング(Scalable Video Coding)が一例であった。

【0153】

しかしながら、図７Ｃの実施形態では、dependencyId属性またはパラメータの使用は、マニフェスト・ファイルにおけるリプリゼンテーション（即ち、マニフェスト・ファイルにおける異なるアダプテーション・セット）が依存リプリゼンテーション、即ち、これらのリプリゼンテーションをデコードおよび再生するためにメタデータを含む関連ベース・ストリームを必要とするリプレゼンテーションであることをクライアント・デバイスに知らせるために使用される。

【0154】

つまり、図７Ｃの例におけるdependencyId属性がクライアント・デバイスに知らせることができるのは、記憶媒体上に１つ以上のベース・トラックとして格納されるかもしれず、１つ以上のベース・ストリームとしてクライアント・デバイスに送信されるかもしれないメタデータに、複数のアダプテーション・セット（各々特定のコンテンツと関連する）における複数のリプリゼンテーションが依存する可能性があるということである。これら異なるアダプテーション・セットにおける依存リプリゼンテーションのメディア・データが、同じベース・トラックに依存することもある。したがって、依存リプリゼンテーションが要求されたとき、クライアントにマニフェスト・ファイルにおいて対応するＩＤを有するベース・トラックを検索するように促してもよい。

【0155】

更に、dependencyId属性は、その場合に同じdependencyId属性を有する複数の異なるタイル・ストリームが要求されたとき、これらのタイル・ストリームに関連するメディア・データをバッファし、デコーダ準拠ビットストリームに処理し、１つのデコーダ・モジュール（１つのデコーダ・インスタンス）によって、再生のためにタイルド・ビデオ・フレームのシーケンスにデコードしなければならないことを、クライアント・デバイスに知らせることもできる。

【0156】

タイル・ストリームのメディア・データ、および関連ベース・ストリームのメタデータ（例えば、ベース・ストリームを定めるアダプテーション・セットを指し示すdependencyId属性を有するタイル・ストリーム）を受信したとき、メディア・エンジンはベース・トラックにおけるエキストラクタを解析することができる。各エキストラクタをＶＣＬ ＮＡＬユニットにリンクすることができるので、エキストラクタのシーケンスは、要求されたタイル・ストリーム（トラック７４６_２〜７４６_４において定められる）のＶＣＬ ＮＡＬユニットを識別し、これらを順番にならべ、順番にならべたＮＡＬユニットのペイロードを、デコーダ・モジュールがビットストリームを１つ以上のディスプレイ・デバイス上でビデオ・モザイクとしてレンダリングすることができるタイルド・ビデオ・フレームにデコードするために必要なメタデータ、例えば、タイル位置情報を含むビットストリーム（例えば、ＨＥＶＣ準拠ビットストリーム）に連結するために使用することができる。

【0157】

このように、dependencyID属性は、リプリゼンテーション・レベルでベース・ストリームをタイル・ストリームとリンクする。したがって、ＭＰＤでは、メタデータを含むベース・ストリームは、リプリゼンテーションｉｄと関連つけけられたリプリゼンテーションを含むアダプテーション・セットとして記述することができ、メディア・データを含むタイル・ストリームは、アダプテーション・セットとして記述することができ、異なるアダプテーション・セットが異なるコンテンツ・ソース（異なるエンコーディング・プロセス）から生ずることもある。各アダプテーション・セットは、少なくとも１つのリプリゼンテーションと、ベース・ストリームのリプリゼンテーションｉｄを参照する関連dependencyId属性とを含むことができる。

【0158】

タイルド・メディア・ストリームのコンテキスト内では、他のタイプのデコーディング依存性（独立性）もあり得る。例えば、２つの異なるフレームにわたるタイル境界を跨ぐメディア・データのデコーディング依存性がある。この場合、１つのタイルのメディア・データをデコードするには、他の位置にある他のタイルのメディア・データ（例えば、近隣タイルにおけるメディア・データ）が必要となる場合がある。しかしながら、本開示では、特に明記しない限り、タイルド・メディア・ストリームおよび関連タイル・ストリームは独立してエンコードされる。これが意味するのは、ビデオ・フレームにおけるタイルのメディア・データは、デコーダによって、他のタイル位置にあるタイルのメディア・データを必要とせずに、デコードできるということである。

【0159】

以上で説明したような方法でdependencyId属性の機能を使用する代わりに、要求されたリプリゼンテーションが、マニフェストにおける他の場所（例えば、他のアダプテーション・セット）において定められたベース・トラックにおけるメタデータに依存することをクライアント・デバイスに明示的に知らせるために、新たなbaseTrackdependencyld属性を定めることができる。baseTrackdependencyld属性は、マニフェスト・ファイルにおけるリプリゼンテーションの集合体全域にわたって対応する識別子を有する１つ以上のベース・トラックを検索するように促す。一実施形態では、baseTrackdependencyld属性は、リプリゼンテーションをデコードするためにベース・トラックが必要か否か知らせるためにあり、ベース・トラックは、要求されたリプリゼンテーションと同じアダプテーション・セットには位置しない。

【0160】

以上で説明したＭＰＤにおけるＳＲＤ情報は、コンテンツ・オーサー(content author)に、異なるタイル・ストリーム間において特定の空間関係を記述する能力を提供することができる。ＳＲＤ情報は、クライアント・デバイスがタイル・ストリームの所望の空間構成(spatial composition)を選択するのを補助することができる。しかしながら、ＳＲＤ情報解析をサポートするクライアント・デバイスは、コンテンツ・オーサーがメディア・コンテンツを記述するように、レンダリングされるビューを構成する(compose)ことに拘束されない。図７ＣのＭＰＤは、クライアント・デバイスによって要求される特定のモザイク構成を含むことができる。このプロセスについては以下で更に詳しく説明する。例えば、ＭＰＤは、図７Ｂを参照して説明したようなビデオ・モザイクを定めることができる。その場合、図７ＣのＭＰＤは４つのアダプテーション・セットを含み、各々が（オーディオ）ビジュアル・コンテンツを表すタイル・ストリームおよび特定のタイル位置を参照する。

【0161】

クライアント・デバイスがタイル・ストリームを異なるメディア・ソースから一層柔軟に選択することを可能にするために、メディア構成プロセッサ６２２は、異なるメディア・ソースから生じたモザイク・タイル・ストリーム（異なるエンコーダから生じた）を組み合わせ、これらを所定のデータ構造（メディア・フォーマット）で格納することができる。例えば、一実施形態では、第１組のタイル・トラックと第１ベース・トラック（および関連するマニフェスト・ファイル６１６_１）とを含む第１データ構造６１４_１（の一部）と、第２組のタイル・トラックと第２ベース・トラック（およびマニフェスト・ファイル６１６_２に関連する）とを含む第２データ構造６１４_２（の一部）とを組み合わせ（各々、図７Ｂに図示したものと同様のメディア・フォーマットを有する）、図６に図示したような１つのデータ構造６１４_３（および関連マニフェスト・ファイル６１６_３）にすることができる。このようなデータ構造は、図７Ｄに模式的に図示するメディア・フォーマットを有することができる。

【0162】

一実施形態では、図６のタイル・ストリーム・フォーマッタ６００のメディア構成プロセッサ６２２は、異なるビデオ・モザイクのタイル・ストリームを組み合わせて新たなデータ構造７３０にすることができる。例えば、タイル・ストリーム・フォーマッタは、第１ＨＥＶＣメディア・フォーマットから生じた１組のタイル・ストリーム７３２_１〜７３２_４と、第２ＨＥＶＣメディア・フォーマット生じた１組のタイル・ストリーム７３４_１〜７３４_４とを含むデータ構造を生成することができる。各組は、ベース・トラック７３１_１、７３１_２と関連付けることができる。

【0163】

既に以上で説明したように、エキストラクタが属するタイル・トラックは、それが参照する特定のトラックを識別するエキストラクタ・パラメータに基づいて判定することができる。具体的には、track_ref_indexパラメータまたはその同等物は、タイル・トラックの、特定のＭＡＬユニットにおける、トラックおよび関連メディア・データを発見するためのトラック参照として使用することができる。例えば、図７Ｂを参照して説明したトラック・パラメータに基づいて、図７Ｂに図示した４つのタイル・トラックを参照するエキストラクタのエキストラクタ・パラメータは、ＥＸ１＝（１，０，０，０）、ＥＸＴ２＝（２，０，０，０）、ＥＸＴ３＝（３，０，０，０）、およびＥＸＴ４（４，０，０，０）というようにすればよい。ここで、値１〜４は、track_ref_indexパラメータによって定められるＨＥＶＣタイル・トラックのインデックスである。更に、最も単純な場合では、タイルを抽出するときにサンプル・オフセットがなく、データ・オフセットがなく、エキストラクタは、メディア・エンジンにＮＡＬユニット全体をコピーするように命令する。

【0164】

図８は、本発明の他の実施形態によるタイル・ストリーム・フォーマッタを図示する。具体的には、図８は、図２〜図５を参照して説明したように、少なくとも１つのタイルド・モザイク・ストリームに基づいてＲＴＰモザイク・タイル・ストリームを生成するためのタイル・ストリーム・フォーマッタを図示する。このストリーム・フォーマッタは、１つ以上のフィルタ・モジュール８０４_１、８０４_２を含むことができ、フィルタ・モジュールは、タイルド・モザイク・ストリーム８０２_１、８０２_２を受信し、タイルド・モザイク・ストリームのタイルド・ビデオ・フレームにおける特定のタイルに関連するメディア・データ８０６_１、８０６_２を選別するように構成することができる。これらのメディア・データをＲＴＰストリーマ８０８_１、８０８_２に転送することができ、ＲＴＰストリーマは、所定のメディア・フォーマットに基づいてメディア・データを組み立てることができる。図８の実施形態では、選別されたメディア・データは、ＲＴＰストリーム・モジュール８０８_１、８０８_２によってＲＴＰタイル・ストリーム８１０_１、８１０_２にフォーマットすることができる。ＲＴＰストリーム８２０_１、８２０_２は、記憶媒体８１２、例えば、クライアント・デバイスのグループにＲＴＰストリームをマルチキャストするように構成されたマルチキャスト・ルータによってキャッシュすることができる。

【0165】

マニフェスト・ファイル・ジェネレータ８１６は、ＲＴＰタイル・ストリームを識別するためのタイル・ストリーム識別子を含む１つ以上のマニフェスト・ファイル８２２_１、８２２_２を生成することができる。一実施形態では、タイル・ストリーム識別子は、ＲＴＳＰ ＵＲＬ（例えば、rtsp://example.com/mosaic-videoA1.mp4/）であってもよい。クライアント・デバイスは、ＲＴＳＰクライアントを含み、ＲＴＳＰ ＵＲＬを使用してＲＴＳＰ ＳＥＴＵＰメッセージを送出することによって、ユニキャストＲＴＰストリームを初期化することができる。あるいは、タイル・ストリーム識別子は、タイル・ストリームがマルチキャストされるＩＰマルチキャスト・アドレスでもよい。クライアント・デバイスは、ＩＰマルチキャストに加入し、ＩＧＭＰまたはＭＬＰプロトコルを使用することによってマルチキャストＲＴＰストリームを受信することができる。マニフェスト・ファイルは、更に、タイル・ストリームについてのメタデータ、例えば、タイル位置記述子、タイル・サイズ情報、メディア・データの品質レベル等を含むことができる。

【0166】

加えて、マニフェスト・ファイルは、メディア・エンジンが、デコーダ・モジュールの入力に供給されるビットストリームを形成するために、選択したＲＴＰタイル・ストリームからＮＡＬユニットのシーケンスを判定することを可能にするために、シーケンス情報を含むことができる。あるいは、シーケンス情報は、メディア・エンジンによって判定されてもよい。例えば、ＨＥＶＣ仕様は、準拠ＨＥＶＣビットストリームにおけるタイルド・ビデオ・フレームのＨＥＶＣタイルをラスタ・スキャン順に並べることを命令する。言い換えると、１つのタイルド・ビデオ・フレームに関連するＨＥＶＣタイルは、左上のタイルから始まり右下のタイルへ、１行ずつ、左から右の順で、ビットストリームに順番に並べられる。メディア・エンジンは、タイルド・ビデオ・フレームを形成するためにこの情報を使用することができる。

【0167】

異なる中間ビデオ・ストリームからの対応するフレームが正しく平行ＲＴＰタイル・ストリームにカプセル化するように、図８のシステムにおけるＲＴＰストリーマ・モジュールが適正に同期して動作することを確保するためには、これらＲＴＰストリーマ・モジュールの間において調整が必要になることもある。調整は、既知のタイムスタンプ技法を使用して、対応するフレームに同じＲＴＰタイムスタンプを供給することによって行うことができる。異なるメディア・ストリームからのＲＴＰタイムスタンプは、異なるレートで前進し(advance)、通常独立したランダム・オフセットを有することができる。したがって、ＲＴＰタイムスタンプは１つのストリームのタイミングを再現するのに十分であろうが、異なるメディア・ストリームからのＲＴＰタイムスタンプの直接比較は、同期のためには有効ではない。代わりに、ＲＴＰタイムスタンプに対応するデータがサンプリングされたときを表す基準クロック（壁時計）からのタイムサンプルとＲＴＰタイムスタンプとを対にすることによって、ストリーム毎に、ＲＴＰタイムスタンプをサンプリング・インスタンスに関係付けることができる。基準クロックは、同期されなければならない全てのストリームで共有することができる。他の実施形態では、クライアント・デバイスが、ＲＴＰタイムスタンプと、ＲＴＰタイムスタンプと異なるＲＴＰタイル・ストリームとの間の関係とを追跡することを可能にする１つ以上のマニフェスト・ファイルを生成することもできる。図８のシステムにおける異なるモジュール間の調整は、メディア構成プロセッサ８２２によって制御することができる。

【0168】

図９は、本発明の一実施形態によるＲＴＰタイル・ストリームの形成を図示する。図９に示すように、タイルド・ビデオ・ストリームのＮＡＬユニット９０２_１、９０４_１、９０６_１を選別し、別個のＮＡＬユニットに分離する。即ち、デコーダ・モジュールによってそのコンフィギュレーションを設定するために使用されるメタデータを含む非ＶＣＬ ＮＡＬユニット９０２_２（ＶＰＳ，ＰＰＳ，ＳＰＳ）と、ＶＣＬ−ＮＡＬユニット９０４_２、９０６_２とに分離する。ここで、各ＶＣＬ ＮＡＬユニットは１つのタイルを搬送し、各ＶＣＬ−ＮＡＬユニットにおけるスライスのヘッダは、スライス位置情報、即ち、フレームにおけるスライスの位置に関する情報を含む。フレームにおけるスライスの位置は、スライス毎に１つのタイルの場合、タイルの位置と一致する。

【0169】

その後、ＶＣＬ ＮＡＬユニットをＲＴＰストリーマ・モジュールに供給することができる。ＲＴＰストリーマ・モジュールは、各々１つのタイルのメディア・データを含むＮＡＬユニットを、ＲＴＰタイル・ストリーム９１０、９１２のＲＴＰパケットにパケット化するように構成されている。例えば、図９に示すように、第１タイルＴ１に関連するＶＣＬ ＮＡＬユニットは第１ＲＴＰストリーム９１０において多重化され、第２タイルＴ２に関連するＶＣＬ ＮＡＬユニットは第２ＲＴＰストリーム９１２において多重化される。同様に、非ＶＣＬ−ＮＡＬユニットは、非ＶＣＬ−ＮＡＬユニットをそのペイロードとして有するＲＴＰパケットを含む１つ以上のＲＴＰストリーム９０８に多重化される。このように、ＲＴＰタイル・ストリームを形成することができ、各ＲＴＰタイル・ストリームは特定のタイル位置と関連付けられる。例えば、ＲＴＰタイル・ストリーム９１０は、第１タイル位置にあるタイルＴ１に関連するメディア・データを含むことができ、ＲＴＰタイル・ストリーム９１２は、第２タイル位置にあるタイルＴ２に関連するメディア・データを含むことができる。

【0170】

ＲＴＰパケットのヘッダは、単調にそして線形に時間的に増加する時間を表すＲＴＰタイムスタンプを含むことができるので、これを同期の目的に使用することができる。ＲＴＰパケットのヘッダは、更に、パケットの逸失を検出するために使用することができるシーケンス番号も含むことができる。

【0171】

図１０Ａ〜図１０Ｃは、本発明の一実施形態にしたがって、マニフェスト・フィアルに基づいてビデオ・モザイクをレンダリングするように構成されたメディア・デバイスを図示する。具体的には、図１０Ａはメディア・デバイス１０００を図示する。メディア・デバイス１０００は、ＨＡＳセグメント化タイル・ストリームを要求および受信するＨＡＳクライアント・デバイス１００２、および異なるタイル・ストリームのＮＡＬユニットを１つのビットストリームに組み合わせるＮＡＬコンバイナ１０１８と、ビットストリームをタイルド・ビデオ・フレームにデコードするデコーダ１０２２とを含むメディア・エンジン１００３を含む。メディア・エンジンは、メディア・デバイスに関連するディスプレイ１００４上でビデオをレンダリングするために、ビデオ・フレームをビデオ・バッファ（図示せず）に送ることができる。

【0172】

ユーザ・ナビゲーション・プロセッサ１０１７は、ＨＡＳセグメント１０１０_１〜１０１０_３としてネットワーク・ノード１０１１の記憶媒体上に格納することができる複数のモザイク・タイル・ストリームから１つ以上のモザイク・タイル・ストリームを選択するために、ユーザがグラフィカル・ユーザ・インターフェース（ＧＵＩ）と対話処理することを可能にすることができる。タイル・ストリームは、独立してアクセス可能なタイル・トラックとして格納することができる。メタデータを含むベース・トラックは、タイル・トラックとして格納されているメディア・データに基づいて、メディア・エンジンがデコーダに合わせてビットストリームを組み立てることを可能にする（図７〜図７Ｃを参照して詳しく説明した通り）。以下で更に詳しく説明するが、クライアント・デバイスは、ベース・トラックのメタデータ、および選択したモザイク・タイル・ストリームのメディア・データを要求および受信（バッファ）するように構成することができる。メディア・データおよびメタデータは、メディア・エンジンによって、選択したモザイク・タイル・ストリームのメディア・データ、具体的には、タイル・ストリームのＮＡＬユニットを、ベース・トラックにおける情報に基づいて組み合わせて、デコーダ・モジュール１０２２への入力のためのビットストリームにするために使用される。

【0173】

クライアント・デバイスのマニフェスト・ファイル・リトリーバ(retriever)１０１４は、所望のビデオ・モザイクのタイル・ストリームを引き出すためにクライアントによって使用することができる少なくとも１つのマニフェスト・ファイルをクライアント・デバイスに供給するように構成されたネットワーク・ノードに要求を送るために、例えば、ＧＵＩと対話処理するユーザによって、動作可能にする(activate)ことができる。あるいは、他の実施形態では、マニフェスト・ファイルを別の通信チャネル（図示せず）を介してクライアント・デバイスに送る（プッシュする）こともできる。例えば、一実施形態では、クライアント・デバイスとネットワーク・ノードとの間に（双方向）Ｗｅｂｓｏｃｋｅｔ通信チャネルを形成するのでもよく、マニフェスト・ファイルをクライアント・デバイスに送信するために使用することができる。

【0174】

マニフェスト・ファイル（ＭＦ）マネージャ１００６は、マニフェスト・ファイルのクライアント・デバイスへの配給を制御することができる。ネットワーク・ノード１０１１の記憶媒体上に格納されているタイル・ストリームのマニフェスト・ファイル１０１２_１〜１０１２_４を管理するように構成されたマニフェスト・ファイル（ＭＦ）マネージャが、マニフェスト・ファイルのクライアント・デバイスへの配給を制御することもできる。マニフェスト・ファイル・マネージャは、ネットワーク・ノード１０１１上または別個のマニフェスト・ファイル・サーバ上で実行するネットワーク・アプリケーションとして実装することもできる。

【0175】

一実施形態では、マニフェスト・ファイル・マネージャは、所望のビデオ・モザイクを形成するために必要とされるストリームを要求するためにクライアント・デバイスが必要とする情報を含む専用マニフェスト・ファイル（「カスタム化」マニフェスト・ファイル）を、クライアント・デバイスのために（動作中に）生成するように構成することもできる。一実施形態では、マニフェスト・ファイルがＳＲＤ収容ＭＰＤの形態を有することもできる。

【0176】

マニフェスト・ファイル・マネージャは、このような専用マニフェスト・ファイルを、クライアント・デバイスの要求における情報に基づいて生成することができる。クライアント・デバイスからビデオ・モザイクを求める要求を受けたとき、マニフェスト・ファイル・マネージャはこの要求を解析し、この要求における情報に基づいて、要求されたビデオ・モザイクの構成(composition)を判定し、マニフェスト・ファイル１０１２_１〜１０１２_３に基づいて、マニフェスト・ファイル・マネージャによって管理される専用マニフェスト・ファイルを生成し、応答メッセージにおいてこの専用マニフェスト・ファイルをクライアント・デバイスに返送することができる。このような専用マニフェスト・ファイル、具体的には、専用ＳＲＤ型ＭＰＤの例について、図７Ｃを参照して詳しく説明する。

【0177】

一実施形態では、クライアント・デバイスが、要求されたビデオ構成を、マニフェスト・ファイル・マネージャへのｈｔｔｐ ＧＥＴ要求におけるＵＲＬとしてエンコードすることができる。この要求ビデオ構成情報は、ＵＲＬのクエリ・ストリング引数によって、またはＨＴＴＰ ＧＥＴ要求に挿入される特定のＨＴＴＰヘッダにおいて送信することができる。他の実施形態では、クライアントが、要求されたビデオ構成を、マニフェスト・ファイル・マネージャへのＨＴＴＰ ＰＯＳＴ要求におけるパラメータとしてエンコードすることもできる。

【0178】

ＨＴＴＰ ＰＯＳＴ応答において、マニフェスト・ファイル・マネージャはＵＲＬを供給することができ、クライアント・デバイスは、このＵＲＬを使用して、恐らくはＨＴＴＰリディレクション・メカニズムを使用して、要求されたビデオ構成を含むマニフェスト・ファイルを引き出すことができる。あるいは、マニフェスト・ファイルは、ＰＯＳＴ要求の応答本体において供給することもできる。この要求に応答して、マニフェスト・ファイル・リトリーバは、要求されたマニフェスト・ファイルを受信し、これによって、ユーザおよび／または（ソフトウェア）アプリケーションによって選択されたモザイク・タイル・ストリームを引き出すことができることをクライアント・デバイスに知らせることができる。

【0179】

一旦マニフェスト・ファイルを受信したなら、ＭＦリトリーバは、ベース・トラックのメディア・データと選択されたモザイク・タイル・ストリームとを含むＨＡＳセグメントをネットワーク・ノードに要求するために、クライアント・デバイスのセグメント・リトリーバ１０１６を動作可能にすることができる。このプロセスにおいて、セグメント・リトリーバは、マニフェスト・ファイルを解析し、セグメント要求、例えば、ＨＴＴＰ ＧＥＴ要求を生成してネットワーク・ノードに送り、応答メッセージ、例えば、ＨＴＴＰ ＯＫ応答メッセージにおいて、要求したセグメントをネットワーク・ノードから受信するために、セグメント識別子および位置情報、例えば、ネットワーク・ノードのＵＲＬ（の一部）を使用することができる。このように、要求されたタイル・ストリームに関連する複数の連続ＨＡＳセグメントをクライアント・デバイスに送信することができる。引き出されたセグメントは、一時的にバッファ１０２０に格納することができ、メディア・エンジンのＮＡＬコンバイナ・モジュール１０１８は、ベース・トラックにおける情報、具体的には、ベース・トラックにおけるエキストラクタに基づいてタイル・ストリームのＮＡＬユニットを選択し、ＮＡＬユニットを、デコーダ・モジュール１０２２によってデコードすることができる順列ビットストリーム(ordered bitstream)に連結することによって、セグメントにおけるＮＡＬユニットをＨＥＶＣ準拠ビットストリームに組み入れることができる。

【0180】

図１０Ｂは、図１０Ａに示したようなメディア・デバイスによって実行することができるプロセスを模式的に図示する。クライアント・デバイスは、ビデオ・モザイク１０２６（の一部）をメディア・デバイスのディスプレイ上でレンダリングするためにＨＡＳクライアント・デバイスおよびメディア・エンジンによって使用することができる、１つ以上のタイル・ストリーム、具体的には、１つ以上のタイル・ストリームのＨＡＳセグメントを選択するために、マニフェスト・ファイル、例えば、多重選択マニフェスト・ファイル(multiple choice manifest file)を使用することができる。図１０Ｂに示すように、マニフェスト・ファイル（例えば、図７Ｃを参照して説明したようなマニフェスト・ファイル）に基づいて、クライアント・デバイスは、ネットワーク・ノード上でＨＡＳセグメント１０２０、１０２２_１〜１０２２_４、１０２４_１〜１０２４_４として格納されている１つ以上のタイル・ストリームを選択することができる。選択されたＨＡＳセグメントは、１つ以上の非ＶＣＬユニット１０２０を含むＨＡＳセグメントと、１つ以上のＶＣＬ ＮＡＬユニットを含むＨＡＳセグメント（例えば、図１０Ｂでは、ＶＣＬ ＮＡＬユニットは、選択されたタイルＴａ１ １０２２_１、Ｔｂ２ １０２４_２、およびＴａ４ １０２２_４と関連付けられている）とを含むことができる。

【0181】

図７Ｂを参照して説明したメディア・フォーマットに基づいて、異なるタイル・ストリームに関連するＨＡＳセグメントを格納することができる。このメディア・フォーマットに基づいて、ＩＳＯ／ＩＥＣ１４４９６−１２またはＩＳＯ／ＩＥＣ１４４９６−１５規格のような、メディア・フォーマットにしたがって、個々にアドレス可能なトラックを含むタイル・ストリームを格納することができる。異なるタイル・トラックに格納されているメディア・データ、即ち、ＶＣＬ ＮＡＬユニット間の関係は、ベース・トラックにおける情報によって示される(provide)。したがって、タイル・ストリームの選択の後、クライアント・デバイスは、ベース・トラックと、選択したタイルに関連するタイル・トラックとを要求することができる。一旦クライアント・デバイスが選択したタイルのＨＡＳセグメントを受信し始めたなら、ベース・トラックにおける情報、具体的には、ベース・トラックにおけるエキストラクタを使用して、ＶＣＬ ＮＡＬユニットを、タイルド・ビデオ・フレーム１０２８を定めるＮＡＬデータ構造１０２６に組み入れ、連結することができる。このように、エンコード・タイルド・ビデオ・フレームを含む準拠ビットストリームをデコーダ・モジュールに供給することができる。

【0182】

カスタム化マニフェスト・ファイルの代わりに、多重選択マニフェスト・ファイルに基づいてビデオ・モザイクを引き出すこともできる。このプロセスの例を図１０Ｃに図示する。具体的には、この図は、多重選択マニフェスト・ファイルを使用して、２つ以上の異なるデータ構造に基づいたビデオ・モザイクの形成を図示する。この実施形態では、少なくとも第１ビデオＡのタイル・ストリームおよび第２ビデオＢのタイル・ストリームを、それぞれ、第１および第２データ構造１０３０_１、１０３０_２として格納することができる。各データ構造は、複数のタイル・トラック１０３４_１、１０３４_２〜１０４２_１、１０４２_２を含むことができ、各トラックは、特定のタイル位置と関連付けられた特定のタイル・ストリームのメディア・データを含むことができる。更に、各データ構造は、シーケンス情報、即ち、異なるタイル・ストリームのＮＡＬユニットをどのようにデコーダ準拠ビットストリームに組み入れることができるか、メディア・エンジンに知らせるための情報を含む、ベース・トラック１０３２_１、１０３２_２も含むことができる。好ましくは、第１および第２データ構造は、図７Ｂを参照して説明したものと同様のＨＥＶＣメディア・フォーマットを有する。その場合、図７Ｃを参照して説明したようなＭＰＤを使用して、特定のトラックに格納されているメディア・データをどのようにして引き出すか、クライアントに知らせることができる。

【0183】

各タイル・トラックはトラック・インデックスを含むことができ、ベース・トラック(basis track)におけるエキストラクタは、トラック・インデックスによって識別される特定のトラックを識別するためにトラック参照を含む。例えば、先に図７Ｂを参照して説明したトラック・パラメータに基づいて、第１タイル・トラック（インデックス値「１」と関連付けられた）を参照する第１エキストラクタのエキストラクタ・パラメータをＥＸ１＝（１，０，０，０）として定めることができ、第２タイル・トラック（インデックス値「２」と関連付けられた）を参照する第２エキストラクタをＥＸＴ２＝（２，０，０，０）として定めることができ、第３タイル・トラック（インデックス値「３」と関連付けられた）を参照する第３エキストラクタをＥＸＴ３＝（３．０，０．０）として定めることができ、第４タイル・トラック（インデックス値「４」と関連付けられた）を参照する第４エキストラクタをＥＸＴ４＝（４．０，０，０）として定めることができる。ここで、値１〜４は、タイル・トラックのインデックスである（track_ref_indexパラメータによって定められる）。更に、この特定的な実施形態では、タイルを抽出するときにサンプル・オフセットがなく、データ・オフセットがなく、エキストラクタはクライアント・デバイスにＮＡＬユニット全体をコピーするように命令すると仮定する。

【0184】

各ＨＥＶＣファイルは、同じタイル・インデックシング方式、例えば、１からｎまでのトラック・インデックス値を使用し、各トラック・インデックスは、特定のタイル位置にあるタイル・ストリームのメディア・データを含むタイル・トラックを参照する。タイル・トラックの順序１からｎは、タイルがタイルド・ビデオ・フレームに並べられる順序（例えば、ラスタ・スキャン順）を定めることができる。言い換えると、例えば、図７Ｂに示すような２×２モザイクの場合、全ての左上タイルは、インデックスが１のトラックに格納され、全ての右上タイルは、インデックスが２のトラックに格納され、全ての左下タイルは、インデックスが３のトラックに格納され、全ての右下タイルは、インデックスが４のトラックに格納されなければならない。したがって、例えば、図４を参照して説明したように、タイリング・モジュールの共通コンフィギュレーションを使用してタイル・ストリームを生成し、ＨＥＶＣメディア・フォーマットのような共通メディア・フォーマットに基づいて格納するとき、第１および第２データ構造のベース・トラックは同一であり、ビデオＡのトラックおよび／またはビデオＢのトラックをアドレスするために使用することができる。これらの条件は、例えば、同一の設定値を有するエンコーダ／タイル・ストリーム・フォーマッタに基づいてデータ構造を生成することによって、満たすことができる。

【0185】

その場合、クライアント・デバイスは、第１および第２データ構造のフォーマットを変えることなく、即ち、メディア・データを物理的に記憶媒体上に格納する方法を変更することなく、タイル・トラックの組み合わせを第１データ構造および第２データ構造から引き出すことができる。クライアント・デバイスは、図１０Ｃに模式的に図示するように、多重選択マニフェスト・ファイル１０４２（ＭＣ−ＭＦ）に基づいて、異なるデータ構造から生じたタイル・トラックの組み合わせを選択することができる。このようなマニフェスト・ファイルは、１つのタイル位置に対して複数のタイル・ストリームを定めることを特徴とする。これは、マニフェスト・ファイルが、実際には、１つのタイル位置に対してユーザが異なるタイル・ストリームを選択することを可能にする多重選択マニフェスト・ファイルであることを、クライアント・デバイスにトリガすることができる。あるいは、マニフェスト・ファイルが、ビデオ・モザイクを構成する(compose)ために使用することができる多重選択マニフェスト・ファイルであることをクライアント・デバイスに知らせるために、多重選択マニフェスト・ファイルが識別子またはフラグを有することもできる。クライアント・デバイスがマニフェスト・ファイルを多重選択マニフェスト・ファイルとして識別した場合、メディア・デバイスにおいて、所望のビデオ・モザイクを構成する(compose)ことができるように、異なるタイル位置に対してユーザがタイル・ストリーム識別子（タイル・ストリームを表す）を選択することを可能にするＧＵＩアプリケーションを起動する(trigger)ことができる。続いて、クライアント・デバイスのセグメント・リトリーバ１０１６は、選択されたタイル・ストリーム識別子を使用して、セグメント要求、例えば、ＨＴＴＰ要求をネットワーク・ノードに送ることができる。

【0186】

図１０Ｃの例に示すように、マニフェスト・ファイル１０４２は、少なくとも１つのベース・ファイル識別子１０４４、例えば、ビデオＡのベース・ファイル・モザイク−ベース．ｍｐ４(base file mosaic-base. mp4 of video A)、ビデオＡ１０４６のタイル・ストリーム識別子、およびビデオＢ１０４８のタイル・ストリーム識別子を含むことができる。各タイル・ストリーム識別子は、タイル位置と関連付けられる。この例では、タイル位置１、２、３、および４は、それぞれ、左上、右上、左下、および右下のタイル位置を参照することができる。したがって、図７Ｂに図示した専用マニフェスト・ファイル構造（カスタム化マニフェスト・ファイル）が、特定のビデオ・モザイクを求めるクライアント・デバイスの要求に応答して生成されるのとは対照的に、多重選択マニフェスト・ファイル１０４２は、クライアント・デバイスが、複数のタイル・ストリームから異なるタイル位置におけるタイル・ストリームを選択することを可能にする。複数のタイル・ストリームを異なるビジュアル・コンテンツと関連付けることもできる。

【0187】

したがって、特定のビデオ・モザイクを定める専用（カスタム化）マニフェスト・ファイルとは対照的に、多重選択マニフェスト・ファイル１０４２は、１つのタイル位置に対して異なるタイル・ストリーム識別子（異なるタイル・ストリームと関連付けられた）を定める。多重選択マニフェスト・ファイルにおけるタイル・ストリームは、必ずしもタイル・ストリームを構成する(comprise)１つのデータ構造にリンクされるとは限らない。逆に、多重選択マニフェスト・ファイルが、異なるタイル・ストリームを構成する(comprise)異なるデータ構造を指し示すこともでき、クライアント・デバイスはこれらを使用してビデオ・モザイクを構成する(compose)ことができる。

【0188】

多重選択マニフェスト・ファイル１０４２は、異なるマニフェスト・ファイル１０１０_１、１０１０_２に基づいて、マニフェスト・ファイル・マネージャによって、例えば、第１データ構造（ビデオＡのメディア・データによってタイル・トラックを構成する(comprise)）のマニフェスト・ファイル（の一部）と、第２データ構造（ビデオＢのメディア・データによってタイル・トラックを構成する(comprise)）のマニフェスト・ファイルとを組み合わせることによって、生成することができる。タイル・ストリームに基づいてクライアント・デバイスがビデオ・モザイクを構成する(compose)ことを可能にする多重選択マニフェスト・ファイルの異なる有利な実施形態について、以下で更に詳しく説明する。

【0189】

マニフェスト・ファイル１０４２に基づいて、クライアント・デバイスはビデオＡおよびＢのタイルの特定の組み合わせ１０５０を選択することができ、クライアント・デバイスは、１つの特定のタイル位置に対して１つの特定のタイル・ストリームの選択しか許可しない。この組み合わせは、第１データ構造（ビデオＡ）のタイル・トラック２および３、１０３６_１、１０３８_１、ならびに第２データ構造（ビデオＢ）のタイル・トラック１および４ １０３４_２、１０４０_２に関連するタイル・ストリームを選択することによって実現することができる。

【0190】

尚、図１０Ａ〜図１０Ｃにおける異なる機能エレメントは、本発明から逸脱することなく、異なる方法で実装できることを具申する。例えば、一実施形態では、ネットワーク・エレメントの代わりに、ＭＦマネージャ１００６をメディア・デバイスにおける機能エレメントとして、例えば、ＨＡＳクライアント１００２の一部等として実装してもよい。その場合、ＭＦリトリーバは、ビデオ・モザイクの形成において使用することができるタイル・ストリームを定める複数の(a number of)異なるマニフェスト・ファイルを引き出すことができ、これらのマニフェスト・ファイルに基づいて、ＭＦマネージャは、クライアント・デバイスが所望のビデオ・モザイクを形成するためにタイル・ストリームを要求することを可能にする、更に他のマニフェスト・ファイル、例えば、カスタム化マニフェスト・ファイルまたは多重選択マニフェスト・ファイルを形成することができる。

【0191】

図１１Ａおよび図１１Ｂは、本発明の他の実施形態にしたがって、マニフェスト・ファイルに基づいてビデオ・モザイクをレンダリングするように構成されたメディア・デバイスを図示する。具体的には、図１１Ａはメディア・デバイス１１００を図示する。メディア・デバイス１１００は、ＲＴＰタイル・ストリームを要求し、要求したタイル・ストリームのメディア・データを受信する（バッファする）ＲＴＳＰ／ＲＴＰクライアント・デバイス１１０２を含む。ＮＡＬコンバイナ１１１８およびデコーダ１１２２を含むメディア・エンジン１１０３は、ＲＴＳＴ／ＲＴＰクライアントにバッファされているメディア・データをそこから受信することができる。ＮＡＬコンバイナは、ビットストリームをタイルド・ビデオ・フレームにデコードするデコーダに合わせて、異なるＲＴＰタイル・ストリームのＮＡＬユニットをビットストリームに組み入れることができる。「デコーダに合わせたビットストリーム」とは、そのデコーダによってデコード可能な（デコードすることができる）ビットストリームを意味する。言い換えると、デコーダによって使用されるコデックに準拠したビットストリームである。メディア・エンジンは、メディア・デバイスに関連するディスプレイ１１０４上にビデオをレンダリングするために、ビデオ・フレームをビデオ・バッファ（図示せず）に送ることができる。

【0192】

クライアント・デバイスのマニフェスト・ファイル・リトリーバ１１１４は、例えば、ＧＵＩと対話処理するユーザによって、マニフェスト・ファイル１１１２_１〜１１１２_３をネットワーク・ノード１１１１に要求するために起動することができる。あるいは、他の実施形態では、別の通信チャネル（図示せず）を介してマニフェスト・ファイルをクライアント・デバイスに送る（プッシュする）こともできる。例えば、一実施形態では、クライアント・デバイスとネットワーク・ノードとの間にＷｅｂｓｏｃｋｅｔ通信チャネルを確立することもできる。マニフェスト・ファイルは、専用ビデオ・モザイクを定めるカスタム化マニフェスト・ファイル、またはクライアント・デバイスがビデオ・モザイクを「構成する」(compose)ことができる複数の異なるビデオ・モザイクを定める多重選択マニフェスト・ファイルでもよい。マニフェスト・ファイル・マネージャ１１０６は、選択されたタイル・ストリーム１１１０_１、１１１０_２に関連するマニフェスト・ファイル１１１２_１、１１２１_２に基づいて、このようなマニフェスト・ファイル（例えば、多重選択マニフェスト・ファイル１１１２_３）を生成するように構成することができる（図１０Ａ〜図１０Ｃを参照して説明したのと同様に）。

【0193】

ユーザ・ナビゲーション・プロセッサ１１１７は、所望のビデオ・モザイクの一部であるタイル・ストリームの選択を補助することができる。具体的には、ユーザ・ナビゲーション・プロセッサは、ネットワーク・ノード上に格納またはキャッシュされている複数のＲＴＰタイル・ストリームから１つ以上のタイル・ストリームを選択するために、ユーザがグラフィカル・ユーザ・インターフェースと対話処理することを可能にするのでもよい。

【0194】

ＲＴＰタイル・ストリームは、多重選択マニフェスト・ファイルに基づいて選択することができる。その場合、クライアント・デバイスは、メディア・デバイスのディスプレイ上にＧＵＩを生成するために、マニフェスト・ファイルにおけるタイル位置記述子を使用することができ、ＧＵＩは、ユーザが１つ以上のタイル・ストリームを選択するためにクライアント・デバイスと対話処理することを可能にする。一旦ユーザが複数の(a number of)タイル・ストリームを選択したなら、ユーザ・ナビゲーション・プロセッサは、ＲＴＰストリーム・リトリーバ１１６（例えば、ユニキャストＲＴＰストリームを引き出すためにはＲＴＳＰクライアント、あるいはＲＴＰストリームを搬送するＩＰマルチキャスト（１つまたは複数）に加入する(join)ためにはＩＧＭＰまたはＭＬＰクライアント）に、選択されたＲＴＰタイル・ストリームをネットワーク・ノードに要求するように促すことができる。このプロセスの間、ＲＴＰストリーム・リトリーバは、ストリーム要求、例えば、ＲＴＳＰ ＳＥＴＵＰメッセージまたはＩＧＭＰ加入メッセージを送って、要求されたストリームをネットワーク・ノードから受信するために、マニフェスト・ファイルにおけるタイル・ストリーム識別子、および位置情報、例えば、ＲＴＳＰ ＵＲＬまたはＩＰマルチキャスト・アドレスを使用することができる。このように、要求されたタイル・ストリームに関連する複数のＲＴＰストリームをクライアント・デバイスに送信することができる。受信した異なるＲＴＰストリームのメディア・データは、一時的にバッファ１１２０に格納することができる。各タイル・ストリームのメディア・データ、ＲＴＰパケットは、ＲＴＰタイムスタンプに基づいて、正しい再生順序に並べることができ、ＮＡＬコンバイナ・モジュール１１１８は、異なるＲＴＰストリームのＮＡＬユニットを、デコーダ・モジュール１１２２に合わせたデコーダ・コデック準拠ビットストリームに組み入れるように構成することができる。「デコーダに合わせたビットストリーム」とは、そのデコーダによってデコード可能な（デコードすることができる）ビットストリームを意味する。言い換えると、デコーダによって使用されるコデックに準拠したビットストリームである。

【0195】

図１１Ｂは、図１１Ａに示すようなメディア・デバイスによって実行されるプロセスを模式的に図示する。クライアント・デバイスは、１つ以上のタイル・ストリームを選択するために、マニフェスト・ファイルを使用することができる。クライアント・デバイスは、ＲＴＰパケットのＲＴＰタイムスタンプを使用して、時間的に異なるＲＴＰペイロードを関係付け、同じフレームに属するＮＡＬユニットを順番に並べてビットストリームにすることができる。

【0196】

図１１Ｂは、５つのＲＴＰストリーム、即ち、非ＶＣＬ ＮＡＬユニットを含む１つのＲＴＰストリーム１１２２および異なるタイル位置と関連つけけられた４つのＲＴＰタイル・ストリーム１１２４〜１１３０を含む例を図示する。クライアント・デバイスは、３つのＲＴＰストリーム、例えば、非ＶＣＬ ＮＡＬユニット１１３２を含むＲＴＰストリーム、第１タイル位置と関連つけけられた第１タイルのメディア・データを含むＶＣＬ ＮＡＬユニットを含む第１ＲＴＰタイル・ストリーム１１３４、および第２タイル位置と関連つけけられた第２タイルのメディア・データを含むＶＣＬ ＮＡＬユニットを含む第２ＲＴＰタイル・ストリーム１３１６を選択することができる。

【0197】

ＲＴＰヘッダにおける情報およびメタデータ、例えば、マニフェスト・ファイルにおける情報を使用して、１つ以上のビデオ・フレーム（の一部）のＮＡＬデータ構造１１３８が形成されるように、異なるＮＡＬユニット、即ち、ＲＴＰパケットのペイロードを、正しい時間順に組み合わせる、即ち、連結することができる。ＮＡＬデータ構造１１３８は、１つ以上の非ＶＣＬ ＮＡＬユニットと、１つ以上のＶＣＬ ＮＡＬユニットとを含み、各ＶＣＬ ＮＡＬユニットは特定のタイル位置にあるタイルと関連付けられる。デコーダ・モジュールへの入力のためのビットストリームは、このプロセスを連続ＲＴＰパケットのために繰り返すことによって形成することができる。デコーダ・モジュールは、図１０Ａおよび図１０Ｂを参照して説明したのと同様に、ビットストリームをデコードすることができる。

【0198】

したがって、以上の図１０および図１１から、マニフェスト・ファイルに基づいて異なるタイル位置と関連付けられた異なるタイル・ストリームを選択し、選択したタイル・ストリームのメディア・データを受信し、受信したタイル・ストリームのメディア・データを順番に並べて、タイルを処理することができるデコーダ・モジュールによってデコードすることができるビットストリームにすることによって、モザイク・ビデオを構成する(compose)ことができるということになる。通例、このようなデコーダ・モジュールは、デコーダ・モジュールがビデオ・フレームにおけるタイルの位置を判定することを可能にするために、デコーダ・モジュール・コンフィギュレーション情報、具体的には、タイル位置情報を受信するように構成される。一実施形態では、デコーダ情報の少なくとも一部を、非ＶＣＬ ＮＡＬユニットにおける情報および／またはＶＣＬ ＮＡＬユニットのヘッダにおける情報に基づいて、デコーダ・モジュールに提供することができる。

【0199】

図１２Ａおよび図１２Ｂは、本発明の他の実施形態によるタイル・ストリームのＨＡＳセグメントの形成を図示する。具体的には、図１２Ａおよび図１２Ｂは、複数のＮＡＬユニットを含むＨＡＳセグメントを形成するプロセスを図示する。図７Ｂにおいて説明したように、タイル・ストリームは、メディア・コンテナの異なるトラックに格納することができる。次いで、各トラックを数秒の時間セグメント、つまり、複数のＮＡＬユニットを含む時間セグメントにセグメント化することができる。この複数のＮＡＬユニットの格納およびインデックス化は、クライアント・デバイスがＨＡＳセグメントのペイロードを解析して複数のＮＡＬユニットを求めることができるように、ＩＳＯ／ＩＥＣ１４４９６−１２またはＩＳＯ／ＩＥＣ１４４９６−１５のような所与のファイル・フォーマットにしたがって実行することができる。

【0200】

１つのＮＡＬユニット（ビデオ・フレームにおける１つのタイルを構成する(comprise)）は、４０ミリ秒の典型的な長さを有する（毎秒２５フレームのフレーム・レートに対して）。したがって、１つのＮＡＬユニットだけを含むＨＡＳセグメントは、非常に短いＨＡＳセグメントになり、高いオーバーヘッド・コストが伴う。ＲＴＰヘッダはバイナリで非常に小さいが、ＨＡＳヘッダは大きい。これは、ＨＡＳセグメントが大きなＡＳＣＩＩ−エンコードＨＴＴＰヘッダと共にＨＴＴＰ応答にカプセル化された完全なファイルであるからである。したがって、図１２Ａの実施形態では、１つのタイルに関連する複数のＮＡＬユニット（通例、ビデオの１〜１０秒と同等のものに対応する）を含むＨＡＳセグメントが形成される。タイルド・モザイク・ストリームのＮＡＬユニット１２０２_１、１２０４_１、１２０６_１は、別個のＮＡＬユニット、即ち、デコーダ・モジュールによってそのコンフィギュレーションを設定するために使用されるメタデータを含む非ＶＣＬ ＮＡＬユニット１２０２_２（ＶＰＳ，ＰＰＳ，ＳＰＳ）、および各々タイル・ストリームのフレームを含むＶＣＬ ＮＡＬユニット１２０４_２、１２０６_２に分割することができる。ＶＣＬ−ＮＡＬユニットにおけるスライスのヘッダ情報は、ビデオ・フレームのスライスの位置に関連するスライス位置情報も含むことができ、これは、エンコーディングの間にスライス毎に１つのタイルという制約が適用される場合、ビデオ・フレームにおけるタイルの位置でもある。

【0201】

このようにして形成されたＮＡＬユニットは、ＨＡＳプロトコルによって定められるようなＨＡＳセグメントにフォーマット化することができる。例えば、図１２Ａに示すように、非ＶＣＬ ＮＡＬユニットは第１ＨＡＳセグメント１２０８として格納することができ、非ＶＣＬ ＮＡＬユニットは、異なる原子コンテナ(atomic container)、例えば、ＩＳＯ／ＩＥＣ１４４９６−１２およびＩＳＯ／ＩＥＣ１４４９６−１５においてボックスと呼ばれるものに格納される。同様に、異なる原子コンテナに格納されたタイルＴ１の連結ＶＣＬ ＮＡＬユニットは、第２ＨＡＳセグメント１２１０として格納することができ、異なる原子コンテナに格納されたタイルＴ２の連結ＶＣＬ ＮＡＬユニットは、第３ＨＡＳセグメント１２１２として格納することができる。

【0202】

したがって、複数のＮＡＬユニットは、連結されて、１つのＨＡＳセグメントにペイロードとして挿入される。このように、第１および第２タイル・ストリームのＨＡＳセグメントを形成することができ、ＨＡＳセグメントは複数の連結ＶＣＬ−ＮＡＬユニットを含む。同様に、複数の連結非ＶＣＬ ＨＡＳユニットを含むＨＡＳセグメントも形成することができる。

【0203】

図１２Ｂは、本発明の一実施形態によるビデオ・モザイクを表すビットストリームの形成を図示する。ここでは、タイル・ストリームは、図１２Ａを参照して説明したような、複数のＮＡＬユニットを含むＨＡＳセグメントを含むことができる。具体的には、図１２Ｂは複数の（この場合、４つの）ＨＡＳセグメント１２１８_１〜１２１８_４を図示し、各々、特定のタイル位置に特定のタイルを含むビデオ・フレームの複数のＶＣＬ ＮＡＬユニット１２２０_１〜１２２０_３を含む。ＨＡＳセグメント毎に、クライアント・デバイスは、ＮＡＬユニットの境界を示す所与のファイル・フォーマット・シンタックスに基づいて、連結されたＮＡＬユニットを分離することができる。次いで、ビデオ・フレーム１２２２_１〜１２２２_３毎に、メディア・エンジンはＶＣＬ−ＮＡＬユニットを収集し、モザイク・ビデオを表すビットストリーム１２２_４をデコーダ・モジュールに供給できるように、所定のシーケンスでＮＡＬユニットを配列し、デコーダ・モジュールは、ビットストリームをビデオ・モザイク１２２６を表すビデオ・フレームにデコードすることができる。

【0204】

尚、本開示において説明したタイルド・ビデオの構成(composition)またはビデオ・モザイクの概念は、それが（視覚的に）無関係なコンテンツのタイル・ストリームを組み合わせること、および／または（視覚的に）関係あるコンテンツのタイル・ストリームを組み合わせることにも関係することもあるという意味で、広く解釈されて当然であることを具申する。例えば、図１３Ａ〜図１３Ｄは、後者の状況の例を図示し、本開示において説明した方法およびシステムは、広視野ビデオの中心部分に関連する第１組のタイル・ストリーム（図１３Ｂ）（本質的に、中または狭視野画像）、および広視野ビデオの周辺部分に関連する第２組のタイル・ストリーム（図１３Ｃ）において、広視野ビデオ（図１３Ａ）を変換するために使用することができる。本開示において説明したようなＭＰＤを使用すると、クライアント・デバイスが、狭視野画像をレンダリングするための第１組のタイル・ストリーム、または広視野画像をレンダリングするための第１および第２組のタイル・ストリームの組み合わせのいずれかを、レンダリングされる画像の分解能を悪化させることなく、選択することを可能にすることができる。第１および第２組のタイル・ストリームを組み合わせる結果、視覚的に関係があるコンテンツのタイルのモザイクが得られる。

【0205】

以下では、多重選択マニフェスト・ファイルの種々の実施形態について更に詳しく説明する。第１実施形態では、多重選択マニフェスト・ファイルは、特定の提案ビデオ・モザイク・コンフィギュレーションを含むことができる。この目的のために、複数のタイル・ストリームを複数のタイル位置と関連つけけることができる。このようなマニフェスト・ファイルは、クライアント・デバイスが、新たなマニフェスト・ファイルを要求することなく、１つのモザイクから他のモザイクに切り替えるのを可能にすることができる。このように、クライアント・デバイスは第１ビデオ・モザイク（タイル・ストリームの第１構成(composition)）から第２ビデオ・モザイク（タイル・ストリームの第２構成(composition)）に変更するために新たなマニフェスト・ファイルを要求する必要がないので、ＤＡＳＨセッションの不連続がない。

【0206】

多重選択マニフェスト・ファイルの第１実施形態は、２つ以上の所定のビデオ・モザイクを定めることができる。例えば、多重選択ＭＰＤは２つのビデオ・モザイクを定めることができ、クライアントはこれらから選択することができる。各ビデオ・モザイクは、ベース・トラックと、図７Ｂを参照して説明したモザイクと同様である、この例では２×２タイル配列を定める複数のタイル・トラックとを含むことができる。各トラックは、ＳＲＤ記述子を含むアダプテーション・セットとして定められ、１つのビデオ・モザイクに属するトラックは、これらのトラックに格納されているタイル・ストリームが互いに空間関係を有することをクライアント・デバイスに知らせるために、同じsource_idパラメータ値を有する。このように、以下のＭＣ−ＭＰＤは次の２つのビデオ・モザイクを定める。

【0207】

【表3】

【0208】

【表4】

【0209】

【表5-1】

【0210】

【表5-2】

【0211】

【表5-3】

【0212】

所定のビデオ・モザイクを含む以上の多重選択マニフェスト・ファイルは、ＤＡＳＨに準拠し、クライアント・デバイスはＭＰＤを使用して、同じＭＰＥＧ−ＤＡＳＨセッション内において１つのモザイクから他のモザイクに切り替えることができる。しかしながら、マニフェスト・ファイルは、所定のビデオ・モザイクの選択しか許可しない。これは、クライアント・デバイスが、タイル位置毎に、複数の異なるタイル・ストリームからタイル・ストリームを選択することによって（例えば、図１０Ｃを参照して説明したように）、任意にビデオ・モザイクを構成する(compose)ことを許さない。

【0213】

クライアント・デバイスに更に高い柔軟性を提供するために、クライアントにかかるデコーディングの負担を最小に抑えつつ、クライアント・デバイスがビデオ・モザイクを構成する(compose)こと、即ち、１つのデコーダがビデオ・モザイク全体をデコードすることを可能にするように、マニフェスト・ファイルをオーサリングする(author)ことができる。例えば、タイル位置毎にビデオＡ、Ｂ、Ｃ、またはＤのタイル・ストリームに基づいて、以下のビデオ・モザイクを構成する(compose)ことができる。

【0214】

【表6】

【0215】

本発明の第２実施形態による多重選択マニフェスト・ファイルでは、クライアント・デバイスが、タイル位置毎にまたはタイル位置の少なくとも一部に対してタイル・ストリームを選択することによって、ビデオ・モザイクを構成する(compose)することができる。

【0216】

【表7-1】

【0217】

【表7-2】

【0218】

【表7-3】

【0219】

以上で説明したマニフェスト・ファイルはＤＡＳＨに準拠する。タイル位置毎に、マニフェスト・ファイルはＳＲＤ記述子に関連するアダプテーション・セットを定め、アダプテーション・セットは、ＳＲＤ記述子によって記述されるタイル位置に入手可能なタイル・ストリームを表すリプリゼンテーションを定める。「拡張」dependencyId（図７Ｃを参照して説明したような）は、このリプリゼンテーションがベース・トラックにおけるメタデータに依存することを、クライアント・デバイスに知らせる。

【0220】

このマニフェスト・ファイルは、クライアント・デバイスが複数のタイル・ストリーム（ビデオＡ、Ｂ、Ｃ、またはＤに基づいて形成される）から選択することを可能にする。各ビデオのタイル・ストリームは、図７Ｂを参照して説明したようなＨＥＶＣメディア・フォーマットに基づいて格納することができる。図１０Ｃを参照して説明したように、同様の設定値または実質的に同一の設定値を有する１つ以上のエンコーダに基づいてタイル・ストリームが生成される限り、ビデオの内１つのベース・トラックが１つだけ必要になる。タイル・ストリームは、クライアント・デバイスによって多重選択マニフェスト・ファイルに基づいて、個々に選択しアクセスすることができる。最大の柔軟性をクライアント・デバイスに提供するために、可能な全ての組み合わせをＭＰＤに記述しなければならない。

【0221】

タイル・ストリームのビジュアル・コンテンツは、関係があっても、無関係でもよい。したがって、このマニフェスト・ファイルのオーサリングは、アダプテーション・セット・エレメントのセマンティックを引き延ばす(stretch)。これは、通常では、ＤＡＳＨ規格は、アダプテーション・セットは視覚的に同等のコンテンツしか含むことができないということを指定するからである（リプリゼンテーションはコデック、分解能等に関して、このコンテンツの変形(variations)を提案する。）。

【0222】

以上の方式をビデオ・フレームにおける大多数のタイル位置およびタイル位置の各々において選択することができる大多数のタイル・ストリームと共に使用すると、マニフェスト・ファイルは非常に長くなる可能性がある。何故なら、タイル位置における各組のタイル・ストリームは、ＳＲＤ記述子と１つ以上のタイル・ストリーム識別子とを含むアダプテーション・セットを必要とするからである。

【0223】

【表8】

【0224】

以下では、本発明の第３実施形態として、アダプテーション・セットのセマンティックに即して、マニフェスト・ファイルが過度に長くなることなく、大多数のタイル・ストリームを定めることを可能とすることができる多重選択マニフェスト・ファイルを供給するという先に特定した問題を扱う、多重選択マニフェスト・ファイルについて説明する。一実施形態では、以下の方法で１つのアダプテーション・セットに複数のＳＲＤ記述子を含ませることによって、これらの問題を解決することができる。

【0225】

【表9】

【0226】

１つのアダプテーション・セットにおいて複数のＳＲＤ記述子の使用が許されるのは、１つのアダプテーション・セットにおける複数のＳＲＤ記述子の使用を除外する適合規則がＤＡＳＨ仕様にはないからである。アダプテーション・セットにおける複数のＳＲＤ記述子の存在によって、クライアント・デバイス、特にＤＡＳＨクライアント・デバイスに、異なるタイル位置と関連つけけられた異なるタイル・ストリームとして、特定のビデオ・コンテンツを引き出せることを知らせることができる。

【0227】

１つのアダプテーション・セットに複数のＳＲＤ記述子を入れるには、クライアント・デバイスが正しいタイル・ストリーム識別子、例えば、ＵＲＬ（の一部）を判定することを可能とする修正セグメント・テンプレートを必要とする場合がある。これは、正しいタイル・ストリームをネットワーク・ノードに要求するためにクライアント・デバイスによって必要とされる。一実施形態では、テンプレート方式は以下の識別子を含むことができる。

【0228】

【表10】

【0229】

セグメント・テンプレートのベースＵＲＬ、BaseURL、ならびにobject_xおよびobject_y識別子は、特定のタイル位置と関連付けられたタイル・ストリームのタイル・ストリーム識別子、例えばＵＲＬ（の一部）を生成するために使用することができる。このテンプレート方式に基づいて、以下の多重選択マニフェスト・ファイルをオーサリングすることができる。

【0230】

【表11-1】

【0231】

【表11-2】

【0232】

【表11-3】

【0233】

したがって、この実施形態では、各アダプテーション・セットは、特定のコンテンツ、例えば、video1、video2等と関連つけけられた複数のタイル位置を定めるために複数のＳＲＤ記述子を含む。マニフェスト・ファイルにおける情報に基づいて、クライアント・デバイスは、このようにして、特定のタイル位置（特定のＳＲＤ記述子によって識別される）において特定のコンテンツ（ベースＵＲＬによって識別される特定のビデオ）を選択し、選択したタイル・ストリームのタイル・ストリーム識別子を組み立てる(construct)ことができる。
具体的には、マニフェスト・ファイルにおける情報は、タイル位置毎に選択可能なコンテンツについてクライアント・デバイスに知らせる。この情報は、メディア・デバイスのディスプレイ上にグラフィカル・ユーザ・インターフェースをレンダリングするために使用することができ、ユーザがビデオ・モザイクを形成するために特定の構成(composition)のビデオを選択することを可能にする。例えば、マニフェスト・ファイルは、ユーザが、ビデオ・モザイクのビデオ・フレームの右上角と一致するタイル位置と関連つけけられた複数のビデオから、第１ビデオを選択することを可能にするとしてもよい。この選択は、以下のＳＲＤ記述子と関連付けることができる。
<EssentialPropertyid="1" schemeldUri="urn:mpeg:dash:srd:2014" value="1, 0, 0, 960, 540, 1920 ,1080, 1"/>

【0234】

このタイル位置が選択された場合、クライアント・デバイスはBaseURLおよびセグメント・テンプレートを使用して、選択されたタイル・ストリームに関連するＵＲＬを生成することができる。この場合、クライアント・デバイスは、セグメント・テンプレートの識別子object_xおよびobject_yを、選択されたタイル・ストリームのＳＲＤ記述子と対応する値（即ち、０）と交換することができる。このように、イニシャライゼーション・セグメントのＵＲＬ、/video1/0_0_init.mp4v、および第１セグメント、/videol/ 0_0_.1234655.mp4vを形成することができる。

【0235】

マニフェスト・ファイルにおいて定められる各リプリゼンテーションには、dependencyIdを関連付けることができ、このリプリゼンテーションが、リプリゼンテーション「モザイク・ベース」によって定められるメタデータに依存することを、クライアント・デバイスに知らせる。

【0236】

ＤＡＳＨ仕様によれば、２つの記述子が同じｉｄ属性を有するとき、クライアント・デバイスはこれらを処理する必要がない。したがって、異なるｉｄ値がＳＲＤ記述子に与えられるのは、クライアントがそれらの全てを処理しなければならないことを、クライアントに知らせるためである。したがって、この実施形態では、タイル位置ｘ，ｙはセグメントのファイル名の一部となる。これによって、クライアントは、所望のタイル・ストリーム（例えば、所定のＨＥＶＣタイル・トラック）をネットワーク・ノードに要求することが可能になる。以前の実施形態のマニフェスト・ファイルでは、このような対策は不要である。何故なら、これらの実施形態では、各位置（各ＳＲＤ記述子）が、異なる名称のセグメントを含む特定のアダプテーション・セットにリンクされるからである。

【0237】

したがって、この実施形態は、緻密なマニフェスト・ファイルに記述されている複数のタイル・ストリームから異なるビデオ・モザイクを構成する(compose)柔軟性を提供し、構成された(composed)ビデオ・モザイクを、１つのデコーダ・デバイスによってデコードすることができるビットストリームに変換することができる。このＭＰＤ方式のオーサリングは、しかしながら、アダプテーション・セット・エレメントのセマンティクスを尊重しない。

【0238】

１つのアダプテーション・セットにおいて複数のＳＲＤ記述子を使用するとき、更に一層緻密なマニフェスト・ファイルを可能にするために、ＳＲＤ記述子のセマンティクスを変更することができる。例えば、以下のマニフェスト・ファイル部分では、４つのＳＲＤ記述子を使用することができる。

【0239】

【表12】

【0240】

これら４つのＳＲＤ記述子は、変更シンタックスを有するＳＲＤ記述子に基づいて記述することができる。

【0241】

【表13-1】

【0242】

【表13-2】

【0243】

このＳＲＤ記述子のシンタックスに基づけば、第２および第３ＳＲＤパラメータ（即ち、タイルのｘおよびｙ位置を示す）は、位置のベクトルとして理解されるはずである。４つの値を一度に、各々を他の３つと組み合わせると、４つの元のＳＲＤ記述子に情報が記述されることになる。したがって、この新たなＳＲＤ記述子シンタックスに基づいて、一層緻密なＭＰＤを達成することができる。明らかに、この実施形態の利点は、ビデオ・モザイクのために選択することができるビデオ・ストリームの数が大きくなる程明らかになる。

【0244】

【表14-1】

【0245】

【表14-2】

【0246】

第４実施形態によるマニフェスト・ファイルは、アダプテーション・セットのセマンティックに即して、マニフェスト・ファイルが過度に長くなることなく、大多数のタイル・ストリームを定めることを可能にできる多重選択マニフェスト・ファイルを、代わりの方法で提供するという問題に取り組む。この実施形態では、この問題は、同じアダプテーション・セットの異なるリプリゼンテーションにおける異なるＳＲＤ記述子を以下のように関連付けることによって解決することができる。

【0247】

【表15-1】

【0248】

【表15-2】

【0249】

したがって、この実施形態では、アダプテーション・セットは複数の（依存）リプリゼンテーションを含むことができ、各リプリゼンテーションはＳＲＤ記述子と関連付けられる。このようにして、同じビデオ・コンテンツ（アダプテーション・セットにおいて定められる）を複数のタイル位置（複数のＳＲＤ記述子によって定められる）と関連付けることができる。各リプリゼンテーションは、タイル・ストリーム識別子（例えば、ＵＲＬ（の一部））を含むことができる。このような多重選択マニフェスト・ファイルの例は、以下のようになってもよい。

【0250】

【表16-1】

【0251】

【表16-2】

【0252】

【表16-3】

【0253】

この実施形態では、オーサリングがアダプテーション・セットのシンタックスに則するという利点、およびリプリゼンテーション・エレメントによってタイル位置が選択されるという利点が得られる。通常では、リプリゼンテーション・エレメントはアダプテーション・セットのメディア・コンテンツの異なるコーディングおよび／または品質の変異(variant)を定める。したがって、この実施形態では、リプリゼンテーションは、アダプテーション・セットに関連するビデオ・コンテンツのタイル位置の変異を定め、したがってリプリゼンテーション・エレメントのシンタックスの比較的小さな拡張を表す。

【0254】

本発明の第３実施形態による多重選択マニフェスト・ファイルを参照して先に説明したような、object_xおよびobject_y識別子を含むセグメント・テンプレート構造(feature)は、ＭＰＤのサイズを更に縮小するために使用することができる。

【0255】

【表17-1】

【0256】

【表17-2】

【0257】

【表17-3】

【0258】

【表17-4】

【0259】

以上で説明した多重選択マニフェスト・ファイルは、適正なデコーディングおよびレンダリングのためにメタデータに依存するリプリゼンテーション（タイル・ストリーム）を定め、図７Ｃを参照して説明したように、リプリゼンテーション・エレメントにおける「拡張」dependencyId属性に基づいて、依存性がクライアント・デバイスに知らされる。

【0260】

dependencyId属性はリプリゼンテーション・レベルで定められるので、全てのリプリゼンテーションにわたる検索には、ＭＰＤにおける全てのリプリゼンテーションのインデックス化が必要となる。特に、ＭＰＤにおけるリプリゼンテーションの数が相当になる、例えば、数百のリプリゼンテーションになる可能性があるメディア・アプリケーションでは、マニフェスト・ファイルにおける全てのリプリゼンテーションにわたる検索は、クライアント・デバイスにとって集中的な処理になるおそれがある。したがって、一実施形態では、クライアント・デバイスがＭＰＤにおけるリプリゼンテーションにわたって一層効率的な検索を実行することを可能にする１つ以上のパラメータをマニフェスト・ファイルに設けることができる。

【0261】

一実施形態では、リプリゼンテーション・エレメントが、依存リプリゼンテーションを含む１つ以上の関連リプリゼンテーションを発見することができる少なくとも１つのアダプテーション・セットを指し示す（例えば、adaptationSet@idに基づいて）dependentRepresentationLocation属性を含むことができる。ここで、依存性は、メタデータ依存性またはデコーディング依存性であってもよい。一実施形態では、dependentRepresentationLocationの値は、空白によって分離された１つ以上のadaptationSet@idとすることができる。

【0262】

dependentRepresentationLocation属性の使用を例示するマニフェスト・ファイルの例を以下に示す。

【0263】

【表18-1】

【0264】

【表18-2】

【0265】

【表18-3】

【0266】

この例に示すように、dependentRepresentationLocation属性は、dependencyld属性またはbaseTrackdependencyld属性と組み合わせて使用することができ（例えば、図７Ｃを参照して論じたように）、dependencyldまたはbaseTrackdependencyld属性は、リプリゼンテーションが他のリプリゼンテーションに依存することをクライアント・デバイスに知らせ、dependentRepresentationLocation属性は、依存リプリゼンテーションに関連するメディア・データを再生するために必要とされるリプリゼンテーショが、dependentRepresentationLocationが指し示すアダプテーション・セットにおいて発見できることを、クライアント・デバイスに知らせる。

【0267】

例えば、この例では、ベース・ストリームのリプリゼンテーション「モザイク・ベース」を含むアダプテーション・セットは、アダプテーション・セット識別子「ｍａｉｎ−ａｄ」によって識別され、「モザイク・ベース」リプリゼンテーションに依存するあらゆるリプリゼンテーション（dependencyIdによって知らされる）は、dependentRepresentation-Locationを使用して、「ｍａｉｎ−ａｄ」を指し示す。このように、クライアント・デバイス（例えば、ＤＡＳＨクライアント・デバイス）は、大多数のリプリゼンテーションを含むマニフェスト・ファイルにおいて、ベース・ストリームのアダプテーション・セットを効率的に突き止めることができる。

【0268】

一実施形態では、クライアント・デバイスがdependentRepresentationLocation属性の存在を確認した場合、dependencyld属性が存在する、要求されたリプリゼンテーションのアダプテーション・セットを超えて１つ以上の更に別のアダプテーション・セットに対する依存リプリゼンテーションの検索を誘起することができる。アダプテーション・セット内における依存リプリゼンテーションの検索は、好ましくは、dependencyld属性によって誘起されるとよい。

【0269】

一実施形態では、dependentRepresentationLocation属性が１つよりも多いアダプテーション・セット識別子を指し示すこともできる。他の実施形態では、１つよりも多いdependentRepresentationLocation属性をマニフェスト・ファイルにおいて使用することもでき、各パラメータが１つ以上のアダプテーション・セットを指し示す。

【0270】

代替実施形態では、１つ以上の依存リプリゼンテーションに関連する１つ以上のリプリゼンテーションを検索するための更に他の方式を起動するために、dependentRepresentationLocation属性を使用することができる。この実施形態では、dependentRepresentationLocation属性は、同じパラメータを有するマニフェスト・ファイル（または１つ以上の異なるマニフェスト・ファイル）における他のアダプテーション・セットを突き止めるために使用することができる。その場合、dependentRepresentationLocation属性は、アダプテーション・セット識別子の値を有さない。代わりに、これは、このリプリゼンテーションのグループを一意に識別する他の値を有する。したがって、アダプテーション・セットにおいて調べるべき値は、アダプテーション・セットｉｄ自体ではなく、一意のdependentRepresentationLocationパラメータの値である。このように、dependentRepresentationLocationパラメータは、マニフェスト・ファイルにおいて１組のリプリゼンテーションを集合化するためのパラメータ（「ラベル」）として使用され、クライアント・デバイスが、要求された依存リプリゼンテーションに関連するdependentRepresentationLocationを確認したとき、dependentRepresentationLocationパラメータによって識別されるリプリゼンテーションのグループにおいて１つ以上のリプリゼンテーションを求めて、マニフェスト・ファイルを調べる。dependentRepresentationLocation属性がアダプテーション・セット・エレメントの中に存在するとき、同じ値のdependentRepresentationLocation属性が各リプリゼンテーション・エレメントにおいて繰り返される場合と同じ意味を有する。

【0271】

このクライアント挙動を、他の実施形態において説明したクライアント挙動（例えば、dependentRepresentationLocationパラメータが、アダプテーション・セット識別子によって識別される特定のアダプテーション・セットを指し示す実施形態）から区別するために、dependentRepresentationLocationパラメータをdependencyGroupldパラメータと呼ぶこともできる。このパラメータは、１つ以上の依存リプリゼンテーションの再生に必要とされるリプリゼンテーションの一層効率的な検索を可能にするマニフェスト・ファイル内におけるリプリゼンテーションの集合化を可能にする。この実施形態では、リプリゼンテーションのレベルでdependentRepresentationLocationパラメータ（またはdependencyGroupldパラメータ）を定めることができる（すなわち、グループに属するあらゆるリプリゼンテーションにこのパラメータを貼り付ける(label)）。他の実施形態では、アダプテーション・セット・レベルでパラメータを定めることもできる。 dependentRepresentationLocationパラメータ（またはdependencyGroupldパラメータ）が貼り付けられた１つ以上のアダプテーション・セットにおけるリプリゼンテーションは、クライアント・デバイスが、ベース・ストリームを定めるリプリゼンテーションを探すことができるリプリゼンテーションのグループを定める。

【0272】

本発明の更に他の改良では、マニフェスト・ファイルは１つ以上のパラメータを収容し(contain)、これらのパラメータは、更に、提供されるコンテンツの特定のプロパティ、好ましくは、モザイク・プロパティを示す。本発明の実施形態(embodiments)では、このモザイク・プロパティが定められると、複数のタイル・ビデオ・ストリームがマニフェスト・ファイルのリプリゼンテーションに基づいて選択され更にこのプロパティを共通して有するとき、デコードされた後に、互いにスティッチされて表示用のビデオ・フレームが作られる。これらのビデオ・フレームの各々は、レンダリングされたときに１つ以上のビジュアル・フレーム間境界がある小区域のモザイクを形作る(constitute)。本発明の好ましい実施形態では、選択されたタイル・ビデオ・ストリームは、１つのビットストリームとしてデコーダ、好ましくは、ＨＥＶＣデコーダに入力される。

【0273】

マニフェスト・ファイルは、好ましくは、ＭＰＥＧ ＤＡＳＨ規格に基づくメディア・プレゼンテーション記述（ＭＰＤ）であり、以上で説明した１つ以上のプロパティ・パラメータで強化されている(enriched)。

【0274】

マニフェスト・ファイルにおいて参照されるタイル・ビデオ・ストリームによって共有される特定のプロパティを知らせる１つの使用事例では、クライアント・デバイスが、現行のプログラムの縮小バージョン(miniature version)を表示するチャネルのモザイクを柔軟に構成する(compose)ことを可能にする（この現行のプログラム、例えば、チャネルは、マニフェスト・ファイルによって知らせることができる）。これは、タイル・ビデオが一緒にスティッチされたときに連続ビュー、例えば、タイルド・パノラマ・ビューを提供する他のタイプのタイルド・コンテンツとは一線を画す。加えて、モザイク・コンテンツは、クライアント・アプリケーションがタイル・ビデオの部分集合のみを提示することもあるパノラマ・ビデオの使用事例とは対照的に、コンテンツ・プロバイダが、ユーザ対話処理によってパンニングおよびズーミング機能を可能にすることによって、アプリケーションがタイル・ビデオの特定の配列の完全なモザイクを表示することを予測するという意味で異なる。その結果、クライアントが適したコンテンツ選択を行うために、すなわち、モザイクにおけるスロットと同じ量のタイル・ビデオを選択するために、モザイク・コンテンツの特性をクライアント・アプリケーションに伝える必要がある。このために、以下に定めるように、パラメータ「spatial_set_type」をＳＲＤ記述子内に追加することができる。

【0275】

【表19】

注：あるいは、「spatial_set_type」が、数値の代わりに、直接「連続」または「モザイク」のストリング値を保持することもできる。

【0276】

以下のＭＰＤの例は、以上で説明した「spatial_set_type」の用法を例示する。

【表20-1】

【0277】

【表20-2】

【0278】

この例は、全てのＳＲＤ記述子に対して同じ「source_id」を定める。これが意味するのは、全てのリプリゼンテーションが互いに空間関係を有するということである。

【0279】

ＳＲＤ記述子の@value属性に含まれる、コンマ分割リスト(comma-separated list)における２番目から最後のパラメータ、すなわち、「spatial_set_id」は、アダプテーション・セットの各々におけるリプリゼンテーションが同じ空間集合に属することを示す。加えて、この同じコンマ分割リストにおける最後のＳＲＤパラメータ、即ち、「spatial_set_type」は、この空間集合がタイル・ビデオのモザイク配列を形作る(constitute)ことを示す。このように、ＭＰＤオーサーは、このモザイク・コンテンツの特有の性質を表現することができる。これは、好ましくは１つのビットストリームとしてデコーダ、好ましくは、ＨＥＶＣデコーダに入力された後に、モザイク・コンテンツの複数の選択されたタイル・ビデオ・ストリームが同期してレンダリングされるとき、１つ以上のタイル・ビデオ・ストリーム間の視覚的境界が、レンダリングされたフレームに現れるということである。何故なら、本発明によれば、少なくとも２つの異なるコンテンツのタイル・ビデオ・ストリームが選択されるからである。その結果、クライアント・アプリケーションは、完全なモザイク集合を構築するという推奨、即ち、マニフェスト・ファイルにおいて示される位置（本例では４箇所）の各々（本例では、４つの異なるＳＲＤ記述子によって示される）に対してタイル・ビデオ・ストリームを選択するという推奨に従うことになる。

【0280】

加えて、本発明の一実施形態によれば、「spatial_set_type」のセマンティックは、「spatial_set_id」値がマニフェスト・ファイル全体に対して有効であり、同じ「source_id」値を有する他のＳＲＤ記述子だけに縛られるのではないことを表すことができる。これは、異なるビジュアル・コンテンツに対して異なる「source_id」値を有するＳＲＤ記述子を使用する可能性を可能にするが、現行の「source_id」のセマンティックに取って代わる。この場合、ＳＲＤ記述子を有するリプリゼンテーションは、これらが、「source_id」値に関係なく、同じ「spatial_set_id」を値「mosaic」のそれらの「spatial_set_type」と共有する限り、空間関係を有する。

【0281】

図１４は、本開示において説明したように使用することができる例証的なデータ処理システムを示すブロック図である。このようなデータ処理システムは、本開示において説明したデータ処理エンティティを含み、サーバ、クライアント・コンピュータ、エンコーダおよびデコーダ等を含む。 データ処理システム１４００は、システム・バス１４０６を通じてメモリ・エレメント１４０４に結合された少なくとも１つのプロセッサ１４０２を含むことができる。したがって、データ処理システムはメモリ・エレメント１４０４内にプログラム・コードを格納することができる。更に、プロセッサ１４０２は、システム・バス１４０６を通じてメモリ・エレメント１４０４からアクセスされたプログラム・コードを実行することができる。一態様では、データ処理システムは、プログラム・コードを格納および／または実行するのに適したコンピュータとして実現することができる。しかしながら、データ処理システム１４００は、プロセッサおよびメモリを含み、本明細書内において説明した機能を実行することができる任意のシステムの形態で実装すればよいことは認められてしかるべきである。

【0282】

メモリ・エレメント１４０４は、例えば、ローカル・メモリ１４０８のような１つ以上の物理メモリ・デバイスと、１つ以上の大容量記憶デバイス１４１０とを含むことができる。ローカル・メモリとは、プログラム・コードの実際の実行中に通常使用されるランダム・アクセス・メモリまたは他の非永続的メモリ・デバイス（１つまたは複数）を指すことができる。大容量記憶デバイスは、ハード・ドライブまたは他の永続的データ記憶デバイスとして実装されればよい。また、処理システム１４００は１つ以上のキャッシュ・メモリ（図示せず）も含むことができる。キャッシュ・メモリは、実行中にプログラム・コードを大容量記憶デバイス１４１０から引き出さなければならない回数を減らすために、少なくとも一部のプログラム・コードの一時的格納に備える。

【0283】

入力デバイス１４１２および出力デバイス１４１４として図示されている入力／出力（Ｉ／Ｏ）デバイスを、任意に、データ処理システムに結合することができる。入力デバイスの例には、例えば、キーボード、マウスのようなポインティング・デバイス等を含むことができるが、これらに限定されるのではない。出力デバイスの例には、例えば、モニタまたはディスプレイ、スピーカ等を含むことができるが、これらに限定されるのではない。入力デバイスおよび／または出力デバイスは、直接または仲介するＩ／Ｏコントローラを介してデータ処理システムに結合することができる。また、ネットワーク・アダプタ１４１６をデータ処理システムに結合してもよく、他のシステム、コンピュータ・システム、リモート・ネットワーク・デバイス、および／またはリモート記憶デバイスに、仲介するプライベートまたはパブリック・ネットワークを通じてデータ処理システムを結合することが可能になる。ネットワーク・アダプタは、前記システム、デバイス、および／またはネットワークによって送信されるデータを受信するデータ受信機、およびデータを前記システム、デバイス、および／またはネットワークに送信するデータ送信機を含むことができる。モデム、ケーブル・モデム、およびイーサネット・カードは、データ処理システム１４５０と共に使用することができる異なるタイプのネットワーク・アダプタの例である。

【0284】

図１４に図示するように、メモリ・エレメント１４０４はアプリケーション１４１８を格納することができる。尚、データ処理システム１４００は、更に、アプリケーションの実行を容易にすることができるオペレーティング・システム（図示せず）を実行することもできることは認められてしかるべきである。実行可能プログラム・コードの形態で実現されるアプリケーションは、データ処理システム１４００によって、例えば、プロセッサ１４０２によって実行することができる。アプリケーションを実行したことに応答して、データ処理システムは、本明細書において更に詳しく説明する１つ以上の動作を実行するように構成することができる。

【0285】

一態様では、例えば、データ処理システム１４００がクライアント・データ処理システムを表すこともできる。その場合、アプリケーション１４１８はクライアント・アプリケーションを表すことができ、クライアント・アプリケーションは、実行されると、「クライアント」を参照して本明細書において説明した種々の機能を実行するように、データ処理システム１４００を構成する。クライアントの例には、パーソナル・コンピュータ、携帯用コンピュータ、移動体電話機等を含むことができるが、これらに限定されるのではない。「クライアント」という用語を引用して本明細書において説明した種々の機能を実行するように構成されたデータ処理システム１４００は、本願に限って言えば、クライアント・コンピュータまたはクライアント・デバイスと呼んでもよい。

【0286】

他の態様では、データ処理システムがサーバを表すこともできる。例えば、データ処理システムが（ＨＴＴＰ）サーバを表すのでもよく、その場合、アプリケーション１４１８は、実行されると、（ＨＴＴＰ）サーバ動作を実行するように、データ処理システムを構成することができる。他の態様では、データ処理システムが本明細書において言及したような、モジュール、ユニット、または機能を表すこともできる。

【0287】

本明細書において使用した用語は、特定の実施形態を説明するために限られており、本発明の限定であることを意図するのではない。本明細書において使用する場合、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈が明らかにそうでないことを示すのでなければ、複数形も含むことを意図している。更に、「含む」(comprises)および／または「含んでいる」(comprising)という用語は、本明細書において使用する場合、述べられる特徴、整数、ステップ、動作、エレメント、および／またはコンポーネントの存在を指定するが、１つ以上の他の特徴、整数、ステップ、動作、エレメント、コンポーネント、および／またはそのグループの存在や追加を除外するのではないことも理解されよう。

【0288】

以下の特許請求の範囲における全ての手段またはステップ＋機能エレメントの対応する構造、材料、アクト、および均等物は、特定的に特許請求される他の特許請求対象エレメントと組み合わせて当該機能を実行する任意の構造、材料、またはアクトを含むことを意図している。本発明の説明は、例示および説明の目的に限って提示されたのであって、網羅的であること、または開示した形態に本発明を限定することを意図するのではない。本発明の範囲および主旨から逸脱することなく、当業者には多くの変更および変種が明白であろう。以上の実施形態が選択され説明されたのは、本発明の原理および実用的用途を最良に説明するためであり、更に他の当業者が、本発明を理解して、想定される特定の使用に適する種々の変更を行って種々の実施形態を得ることを可能にするためである。

【図1A】

【図1B】

【図1C】

【図2A】

【図2B】

【図2C】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図7C】

【図7D】

【図8】

【図9】

【図10A】

【図10B】

【図10C】

【図11A】

【図11B】

【図12A】

【図12B】

【図13A】

【図13B】

【図13C】

【図13D】

【図14】