JP7442302B2 - データ処理装置およびその制御方法、プログラム - Google Patents

Description

本発明は、データ処理装置およびその制御方法、プログラムに関する。

近年、映像データをHTTP（Hypertext Transfer Protocol）でストリーミング配信する技術としてISOで標準化されたMPEG-DASH（Dynamic Adaptive Streaming over Http）が普及している。具体的には、送信装置が、映像データを所定の時間長のセグメントに分割し、セグメントを取得するためのURL（Uniform Resource Locator）をプレイリストと呼ばれるファイルに記述する。受信装置は初めにこのプレイリストを取得して、プレイリストに記述されている情報を用いて所望のセグメントを送信装置に要求して取得する。また、特許文献１では、MPEG-DASHを用いて映像データを取得する構成において、映像データに含まれる画像を時間的かつ空間的に分割して生成される複数のセグメントのうち、所望のセグメントを受信装置が選択して受信する構成が開示されている。

特開２０１６－９９２５号公報

しかしながら、MPEG-DASHでは、符号化データとして動画（映像データ）を配信することしか想定されておらず、静止画を配信することは想定されていない。特許文献１は、１つの動画ファイルを時分割し、且つ、空間的に分割して得られたセグメントを配信するが、１つのファイルに複数の画像を含み得るファイル、例えばHEIFファイルを配信する場合に、個々の画像を配信可能にするものではない。なお、HEIFとは、High Efficiency Image File Formatの略である。また、本明細書において、画像とは動画と静止画を総称する用語である。従って、例えばコンテンツサーバに保持されたHEIFファイルに複数の静止画が格納され、受信装置がそのHEIFファイル中の一部の静止画のみを必要とするような場合でも、受信装置は当該HEIFファイルをまるごとダウンロードしなければならないという課題があった。

本発明の一態様では、１つのファイルに格納された複数の画像から所望の画像を配信可能とする技術が提供される。

本発明の一態様による送信装置は以下の構成を備える。すなわち、
複数のコンテンツを含む所定のフォーマットのファイルを解析して前記複数のコンテンツおよび前記複数のコンテンツの関係を示す関係情報を取得する取得手段と、
前記取得手段により取得された前記複数のコンテンツを格納する格納手段と、
前記格納手段から前記複数のコンテンツを個別に取得するための取得情報と、前記関係情報とを記述したプレイリストを生成する生成手段と、
前記プレイリストを外部装置に送信し、前記外部装置が前記プレイリストに含まれる前記取得情報を用いて要求したコンテンツを前記外部装置に送信する通信手段と、を備える。

本発明によれば、１つのファイルに格納された複数の静止画から所望の静止画を配信可能とする技術が提供される。

実施形態による通信システムの構成を示す図。 実施形態による送信装置の機能構成例を示すブロック図。 実施形態におけるHEIFファイル解析処理の一例を示すフローチャート。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 送信装置において生成されるプレイリストの一例を示す図。 実施形態による受信装置の機能構成例を示すブロック図。 受信装置による受信処理の例を示すフローチャート。 実施形態による送信装置のハードウエア構成例を示すブロック図。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

＜第１実施形態＞
図１に第１実施形態における通信システムの全体構成例を示す。送信装置１００は、所定のフォーマットのファイルを配信するデータ処理装置の一例であり、ネットワーク１５０を介して、受信装置２００と接続される。送信装置１００は、画像データをHTTPプロトコルでストリーミング配信する。送信装置１００は、後述のように、１つのファイルに含まれている複数の画像から所望の画像をストリーミング配信することができる。なお、送信装置１００、受信装置２００はそれぞれ複数存在しても良い。送信装置１００の具体的な例としては、カメラ装置、ビデオカメラ装置、スマートフォン、携帯電話、ＰＣ装置、クラウドサーバ装置などが挙げられる。但し、後述の機能構成を満たすものであれば、送信装置１００はこれらの例に限定されるものではない。受信装置２００は、コンテンツの再生・表示機能、通信機能、及びユーザからの入力を受け付ける機能を備えるデータ処理装置である。受信装置２００の具体例は、スマートフォン、携帯電話、ＰＣ装置、テレビなどが挙げられる。但し、後述の機能を備えるものであれば、受信装置２００はこれらに限定されるものではない。

ネットワーク１５０は、送信装置１００と受信装置２００を通信可能に接続する。ネットワーク１５０の例としては、例えば有線LAN（Local Area Network）や無線LAN（Wireless LAN）が挙げられる。但し、ネットワーク１５０は、これらに限られるものではなく、例えば、インターネットや3G/4G/LTE/5GなどのWAN（Wide Area Network）、アドホックネットワーク、Bluetoothなどでもよい。

次に、第１実施形態における送信装置１００の機能構成について、図２を用いて説明する。図２は、第１実施形態による送信装置１００の機能構成例を示すブロック図である。

ファイル解析部１０１と符号化データ抽出部１０２では、複数のコンテンツを含む所定のフォーマットのファイルを解析して、複数のコンテンツおよびそれら複数のコンテンツの関係を示す関係情報を取得する。本実施形態において、所定のフォーマットのファイルとは、例えばHEIF（High Efficiency Image File Format）ファイルである。また、関係情報とは、静止画とサムネイル画像の関係、派生画像とそれを構成する画像の関係などがあげられる。ファイル解析部１０１はHEIFファイルを取得し、その構造を解析する。符号化データ抽出部１０２は、HEIFファイルの解析結果を基にHEIFファイルに格納されたコンテンツの符号化データを抽出する。セグメント生成部１０３は、符号化データ抽出部１０２が抽出した符号化データを、必要に応じて通信に適した時間長やビットレートに変換し、符号化データを格納したセグメントを生成する。符号化データ変換部１０４は、抽出された符号化データを必要に応じて異なる符号化形式に変換する。尚、セグメント生成部１０３は、符号化データ変換部１０４により生成された符号化データを格納したセグメントを生成する機能も有する。

配信データ格納部１０５は、以上のようにして取得された複数のコンテンツを、外部装置（本実施形態の例では受信装置２００）が個別に取得することができるように格納する。より具体的には、配信データ格納部１０５は、セグメント生成部１０３および符号化データ変換部１０４で生成されたデータを格納する。プレイリスト生成部１０６は、配信データ格納部１０５から複数のコンテンツを個別に取得するための取得情報（本実施形態ではURL（Uniform Resource Locator））と、上述した関係情報とを記述したプレイリストを生成する。より具体的には、プレイリスト生成部１０６は、HEIFファイルの解析結果を基に配信データ格納部１０５に格納されたデータへのアクセスを可能とするURLを記述したプレイリストを生成する。関係情報の詳細については後述する。通信部１０７は外部装置である受信装置２００からの要求に応じて、生成されたプレイリスト、配信データなどを、ネットワーク１５０を介して受信装置２００に送信する。

以上のような各機能部は、一つ又は複数のＣＰＵが一つ又は複数のメモリに格納された所定のプログラムを実行し、制御することにより実現され得る。なお、上記機能部の各々の１部或いはすべてが専用のハードウエアによって実現されてもよい。

ここで、図１９のブロック図を参照して、実施形態による送信装置１００のハードウエア構成について説明する。送信装置１００は、ＣＰＵ１２１、ＲＯＭ１２２、ＲＡＭ１２３、補助記憶装置１２４、表示部１２５、操作部１２６、通信Ｉ／Ｆ１２７、及びバス１２８を有する。

ＣＰＵ１２１は、ＲＯＭ１２２やＲＡＭ１２３に格納されているコンピュータプログラムやデータを用いて送信装置１００の全体を制御することで、図２に示す送信装置１００の各機能を実現する。なお、送信装置１００がＣＰＵ１２１とは異なる１又は複数の専用のハードウエアを有し、ＣＰＵ１２１による処理の少なくとも一部を専用のハードウエアが実行してもよい。専用のハードウエアの例としては、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）、およびＤＳＰ（デジタルシグナルプロセッサ）などがある。ＲＯＭ１２２は、変更を必要としないプログラムなどを格納する。ＲＡＭ１２３は、補助記憶装置１２４から供給されるプログラムやデータ、及び通信Ｉ／Ｆ１２７を介して外部から供給されるデータなどを一時記憶する。補助記憶装置１２４は、例えばハードディスクドライブ等で構成され、画像データや音声データなどの、受信装置２００への送信対象となる種々のデータ（ファイル）を記憶する。

表示部１２５は、例えば液晶ディスプレイやＬＥＤ等で構成され、ユーザが送信装置１００を操作するためのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）などを表示する。操作部１２６は、例えばキーボードやマウス、ジョイスティック、タッチパネル等で構成され、ユーザによる操作を受けて各種の指示をＣＰＵ１２１に入力する。ＣＰＵ１２１は、表示部１２５を制御する表示制御部、及び操作部１２６を制御する操作制御部として動作する。

通信Ｉ／Ｆ１２７は、送信装置１００と外部の装置（例えば受信装置２００）との通信に用いられる。本実施形態では、通信Ｉ／Ｆ１２７はネットワーク１５０と接続するインターフェイスである。送信装置１００がネットワーク１５０と有線で接続される場合には、通信用のケーブルが通信Ｉ／Ｆ１２７に接続される。送信装置１００がネットワーク１５０と無線で接続される場合には、通信Ｉ／Ｆ１２７はアンテナを備える。バス１２８は、送信装置１００の各部をつないで情報を伝達する。

なお、本実施形態では補助記憶装置１２４、表示部１２５、操作部１２６が送信装置１００の内部に存在するものとするが、これらの少なくとも一つが送信装置１００の外部に別の装置として存在していてもよいし、省略されてもよい。

次に、本実施形態における送信装置１００においてHEIFファイルを解析する処理の流れについて図３を用いて説明する。図３は、ファイル解析部１０１によるHEIFファイルの解析処理の一例を示すフローチャートである。

まず、ステップＳ３０１において、ファイル解析部１０１は、配信対象となるHEIFファイルを取得する。次に、ステップＳ３０２において、ファイル解析部１０１は、HEIFファイルのmetaヘッダ内にハンドラタイプpictが存在するかを確認する。pictハンドラが存在しないと判定された場合（ステップＳ３０２でＮＯ）は、ファイル解析部１０１は、これ以上の解析を行わずに本処理を終了する。一方、pictハンドラが存在すると判定された場合（ステップＳ３０２でＹＥＳ）、ステップＳ３０３において、ファイル解析部１０１は、HEIFファイルに格納されているアイテムの数と種類を取得する。尚、HEIFファイルでは、格納されている画像、画像に関連するメタデータなどのコンテンツをアイテムと呼ぶ。

次に、ステップＳ３０４において、ファイル解析部１０１は、アイテム間の参照情報を取得する。例えば、HEIFファイルには、静止画とそのサムネイル画像の関係を示す参照情報が格納されている。また、HEIFファイルは、複数の画像を組み合わせて１つの画像を生成するための画像を格納することができる。複数の画像を組み合わせて生成される１つの画像を派生画像と呼ぶ。HEIFにおいて、派生画像がアイテムとして含まれている場合は、派生画像とその派生画像を構成する複数の画像との関係を示す参照情報がHEIFファイルに格納されている。また、派生画像を生成するためには、複数の画像を配置するための位置の情報が必要となる。そこで、ファイル解析部１０１は、HEIFファイルのアイテムに派生画像が含まれている場合（Ｓ３０５でＹＥＳ）には、ステップＳ３０６において、派生画像を生成する為の座標情報を取得する。なお、HEIFファイルのアイテムに派生画像が含まれていない場合（Ｓ３０５でＮＯ）は、ステップＳ３０６はスキップされる。派生画像の扱いについては、第２実施形態により詳述する。

ステップＳ３０７において、ファイル解析部１０１は、HEIFファイルからアイテムの代替情報を取得する。代替情報が設定されている具体的なケースとしては、例えば派生画像を表示する事が出来ない場合に、代わりに表示する画像を指定するケースがある。代替画像に関しては、第２実施形態でより詳しく述べる。次にステップＳ３０８において、ファイル解析部１０１は、各アイテムに紐づくプロパティを特定する。プロパティの具体例としては、アイテムの符号化情報、矩形サイズ情報などがあげられる。そこで次のステップＳ３０９において、ファイル解析部１０１は、特定したプロパティから符号化情報と画像の矩形サイズ情報を取得する。次に、ステップＳ３１０において、ファイル解析部１０１は、HEIFファイル内におけるアイテムの位置とサイズ情報を取得する。

符号化データ抽出部１０２は、以上のようにしてファイル解析部１０１が取得したアイテムの位置とサイズ情報を基に、HEIFファイルからアイテムを抽出する。符号化データ変換部１０４は、抽出された符号化データを必要に応じて異なる符号化形式に変換する。例えば、符号化データ変換部１０４は、データの変換前の符号化形式がHEVCであった場合に、必要応じてこれをJPEGに変換する。取得情報は、異なる符号化形式に変換したものを取得可能なURLを含み得る。セグメント生成部１０３は、符号化データ抽出部１０２により抽出された符号化データおよび符号化データ変換部１０４により変換された符号化データからセグメントを生成し、配信データ格納部１０５に格納する。プレイリスト生成部１０６は、ファイル解析部１０１が取得した参照情報、符号化情報、画像サイズ情報などを用いて、受信装置２００が配信データ格納部１０５に格納されたセグメントにアクセスするためのプレイリストを生成する。

次に、第１実施形態における送信装置１００において生成されるプレイリストの例について、図４～図９を用いて説明する。図４は、本発明の一実施形態である送信装置において生成するプレイリストの一例であり、複数の画像が格納されたHEIFファイルを配信可能とする記述例である。図４のプレイリストは、取得情報として４つの静止画と４つのサムネイル画像のURLを含み、関係情報として静止画とサムネイル画像の対応を示す情報を含む。

図４に示すプレイリストは、MPEG-DASHにおける配信に用いられるMPD（Media Presentation Description）の一部を示している。図４において、プレイリストは４つの画像と各々の画像のサムネイル画像が取得可能である事を示している。図４では、画像を各々Representationとして記述し、各々のSubRepresentationとしてサムネイル画像を記述している。サムネイル画像に関しては、タイプ属性４０１に示す様に、サムネイル画像である事を示すタイプ"thmb"が記述されている。なお、画像については、タイプ属性として"image"が記述されている。画像とサムネイル画像の関係は、RepresentationとSubRepresentationの関係により表される。

また、図４においてマイムタイプ４０２（mimeType）は、Representation以下の４つの画像およびサムネイル画像のマイムタイプを示している。図４の例では、マイムタイプ４０２は、HEVCで符号化された画像を格納したHEIFファイルである事を示している（image/heic）。つまり、送信装置１００は、配信するHEIFファイルに複数の画像が格納されていた場合、改めて各々の画像を１つだけ格納するHEIFファイルを生成する。このHEIFファイルへの再カプセル化は、セグメント生成部１０３で行われ、生成されたHEIFファイルは配信データ格納部１０５に格納される。

また、図４においてRepresentationの属性としてプライマリ属性４０３～４０６を記述している。プライマリ属性は、複数のアイテム（画像）間の優先度を示す情報であり、関係情報の一例である。HEIFファイルでは、複数の画像が格納されている場合に、優先的に表示や印刷を行うアイテムを指定する事が出来る。図４の例ではプライマリ属性４０３の値を"1"、その他のプライマリ属性４０４、４０５、４０６の値を"0"とする事で、プライマリ属性の値"1"を設定された画像がプライマリ画像である事を示している。

尚、HEIFファイルではプライマリアイテムを示す情報として、アイテムの識別子を１つ指定する為、MPDで表現するには、上記の様にどれか１つのプライマリ属性の値を"1"とすれば実現可能である。なお、"0"か"1"の２レベルではなく、例えば"0"を最高優先度として、"1"、"2"と値が大きくなるに従い優先度を下げる様にすれば、容易に３つ以上のレベルの優先度を表現する事ができる。

次に、プレイリストの他の例について図５を用いて説明する。図４の例では、送信装置１００が、入力されたHEIFファイルに格納されていた複数の画像のそれぞれを、画像を１つだけ格納したHEIFファイルとして再カプセル化するケースを説明した。次に、再カプセル化しないケースについて図５を用いて説明する。再カプセル化しない場合、複数のコンテンツ（本例では、複数の画像）のそれぞれについて、コンテンツを符号化して得られる符号化データと、その符号化データの復号に必要な復号情報とが別々に格納される。これらを取得するための取得情報は、符号化データを配信データ格納部１０５から取得するための情報と、復号情報を配信データ格納部１０５から取得するための情報と、を含む。図５は、第１実施形態の送信装置１００において生成されるプレイリストの一例であり、特に複数の画像が格納されたHEIFファイルを配信可能とするもう１つの記述例である。

図５において、初期化情報５０１はHEVCで符号化された１つ目の画像を復号する為に必要な復号情報の一例であり、画像データ５０２は１つ目の画像のHEVC符号化データを示す。つまり、入力されたHEIFファイルから抽出した初期化情報と符号化情報をカプセル化することなくそのまま取得可能としている。同様に、初期化情報５０３と画像データ５０４は、１つ目の画像のサムネイル画像の初期化情報と符号化情報である。

なお、図５のマイムタイプ５０５は"image/H265"と記述されている。画像のサブタイプとして"H265"はIANA（Internet Assigned Number Authority）で承認されていない。しかし、図５の様に再カプセル化が不要であれば、入力されたHEIFファイルから抽出したデータをそのまま利用する事が出来る為、送信装置１００での処理を簡略化する事ができる。つまり、図５の記述例では、セグメント生成部１０３において、抽出した画像アイテムを改めてHEIFファイルとしてカプセル化しなくても良い。

以上、図４、図５では、サムネイル画像を、画像のRepresentation内におけるSubRepresentationとして記述することで、画像とサムネイル画像の関係を表した。すなわち、RepresentationとSubRepresentationの関係が、画像間の関係情報に相当する例である。次に、サムネイル画像をRepresentationとして記述するケースについて図６を用いて説明する。図６は、第１実施形態の送信装置１００において生成されるプレイリストの一例であり、特に複数の画像が格納されたHEIFファイルを配信可能とするプレイリストの記述例である。

図６において、Representationのタイプ属性６０１はサムネイルである事を示す。Representationの参照識別子６０２に当該サムネイルの基画像のRepresentationの識別子６０３の値である"0"を記述する事で、このサムネイルはRepresentationの識別子が"0"の画像のサムネイルである事を示すことが出来る。すなわち、参照識別子６０２は、画像間の関係を表す関係情報の例である。図６では、同様に４つの画像の各々についてサムネイル画像をRepresentationとして記述している。

また、複数の画像と各々のサムネイル画像の組合せについてのプレイリストの記述例について、図７を用いて説明する。図７は、第１実施形態の送信装置１００において生成されるプレイリストの一例であり、特に複数の画像が格納されたHEIFファイルを配信可能とするプレイリストの記述例である。

図７において、サムネイル画像は、基となる画像とは異なるRepresentationのSubRepresentationとして記述されている。SubRepresentationのタイプ属性７０１（type=thmb）でサムネイル画像である事を示し、参照識別子７０２で基となる画像のRepresentationの識別子７０３の値を記述している。

第１実施形態において、ここまでに説明したMPDの記述例は、何れも複数の画像と各々のサムネイル画像を記述したものであるが、同じ属性値をまとめて記述する事で記述量を削減するケースについて、図８を用いて説明する。プレイリストの記述量の削減は、プレイリストの送受信に要する時間を削減する。図８は、第１実施形態による送信装置１００において生成されるプレイリストの一例であり、特に複数の画像と各々のサムネイル画像が格納されたHEIFファイルを配信可能とする際に、MPDの記述量を削減することができる記述例である。

図８において、同じ属性情報を持つ４つの画像が１つのRepresentationの異なるセグメントとして記述される。同様に、同じ属性情報を持つ４つのサムネイル画像も１つのRepresentationの異なるセグメントとして記述される。サムネイル画像を記述したRepresentationでは、タイプ属性８０１でサムネイル画像である事が示されている。また、サムネイル画像を示す各セグメントの参照識別子８０２により基となる画像の識別子８０３を記述する事で、サムネイル画像と元となる画像を紐付ける事ができる。更に図８の様にプライマリ属性８０４を、画像を表すセグメント毎に記述することで、プライマリアイテムも識別する事ができる。

次に、画像以外のアイテムとして、EXIFなどのメタデータをMPDに記述するケースについて図９を用いて説明する。図９は、第１実施形態による送信装置１００において生成されるプレイリストの一例であり、特にEXIFなどのメタデータをMPDに記述する場合のプレイリストの記述例である。

図９において、MPDに記述するアイテムはXMP（Extensible Metadata Platform）とEXIFであり、マイムタイプ９０１はこれらメタデータのデータ形式がXMLである事を示している。図９の１つ目のRepresentationはタイプ属性９０２でXMPである事を示しており、参照識別子９０３はこのXMPが付随する画像の識別子を記述する。更にもう１つのRepresentationはタイプ属性９０４でEXIFである事を示しているが、図９の例では、EXIFの情報をXML形式に変換したものを取得可能である事を示しており、参照識別子９０５は、このEXIFが付随する画像の識別子を示す。

以上のように、第１実施形態によれば、１つのHEIFファイルに格納された複数の画像から所望の画像を配信可能とすることが可能になる。

＜第２実施形態＞
第１実施形態では、複数の画像が格納されたHEIFファイルを配信可能とするプレイリストについて説明した。第２実施形態では、HEIFの派生画像、代替画像をMPDに記述するケースについて説明する。なお、第２実施形態による通信システムをおよびデータ処理装置としての送信装置１００の構成、動作は第１実施形態（図１、図２、図３）と同様である。第２実施形態では、特に図３のステップＳ３０６で取得される派生画像に関する記述を例示する。

図１０（ａ）は、派生画像の構成例を示す図である。また、図１０（ｂ）は、第２実施形態による送信装置１００において生成されるプレイリストの一例であり、特に複数の画像を組み合わせて１つの画像を生成する派生画像をMPDに記述する記述例である。

図１０（ａ）に示されるように、本実施形態で例示される派生画像は、４つの画像（id=1～id=4の画像）を縦横に２つ並べて生成したグリッド画像である。派生画像と派生画像を構成する４つの画像は図１０（ｂ）のプレイリストにおいてRepresentationとして記述されている。派生画像のRepresentationにおいて、タイプ属性１００１は派生画像を示すタイプである"dimg"が記述される。また、派生画像のRepresentationに含まれているSubRepresentationのタイプ属性１００２に、派生画像の詳細タイプであるグリッド画像を示す"grid"が記述される。さらに、カウント属性１００３に当該グリッド画像を構成する画像の数である"4"が記述される。

更に、SubRepresentation以下のセグメントとして、派生画像（グリッド画像）を構成する４つのセグメント情報１００４が記述される。セグメント情報１００４の各セグメントは、参照識別子として構成画像（＝セグメント）を含むRepresentationの識別子を記述することで、派生画像がどの画像によって構成されるのかを明示する。また、セグメント情報１００４には、各セグメントの配置を示す情報として、セグメントを表示する位置を示す座標情報が記述されている。尚、図１０（ｂ）では座標情報として左上の座標を記述しているが、座標を示す情報はグリッド画像における各画像の表示位置を特定出来れば良いので、右下や中心の座標などでも良い。

ところで、HEIFの派生画像にはグリッド以外にも種類があり、その中でもオーバーレイ画像はグリッド画像と同様の記述方法で表現する事ができる。派生画像としてオーバーレイ画像を生成、表示するには、派生画像を構成する画像の座標情報以外に、それらを重ねるための順番を示すレイヤー情報が必要となる。レイヤー情報は、例えば、セグメント情報１００４に記述された各セグメントの属性情報の１つとして記述され得る。あるいは、セグメント情報１００４に記述されるセグメントの順番がレイヤーの順序を示すものとしても良い。

次に、図１０（ｂ）で説明した派生画像の記述量を削減するプレイリストについて図１１を用いて説明する。図１１は、第２実施形態による送信装置１００において生成されるプレイリストの他の例であり、特に複数の画像を組み合わせて１つの画像を生成する派生画像を配信可能とする際に、MPDの記述量を削減する記述例である。

図１１において、派生画像に関する記述は図１０の例と同様である。すなわち、Representationのタイプ属性（"dimg"）で識別し、SubRepresentationのタイプ属性（"grid"）とカウント属性（"4"）で派生画像の詳細タイプと派生画像を構成するセグメントの数が示される。一方、派生画像を構成する構成画像については、第1実施形態で説明した図８のプレイリストと同様に、同じ属性情報を持つ構成画像を１つのRepresentationにまとめることで記述量を削減している。ところが、構成画像を１つのRepresentationにまとめると、派生画像のセグメント情報が参照するRepresentationの識別子が、構成画像間で同一になってしまう。そこで、本実施形態では、派生画像を構成するセグメントに記述される参照識別子１１０１は、構成画像をまとめたRepresentationの識別子１１０２と構成画像であるセグメントの補助識別子１１０３を組合せて記述する。図１１では、２つの識別子をハイフンでつなげる形式で記述している。

次に、図３のステップＳ３０７で、アイテムの代替情報が取得された場合について説明する。例えば、受信装置２００の能力によっては、プレイリストに記載された派生画像を表示できない場合がある。その様な場合に、派生画像の代わりに表示する画像を記述したプレイリストについて図１２を用いて説明する。図１２は、第２実施形態による送信装置１００において生成されるプレイリストの一例であり、表示する画像に優先度を設定する事で代替画像を示す記述例である。

図１２において、派生画像は４つの構成画像と１つのSEI（Supplemental Enhancement Information：アルファプレーン）から生成される。ここで、派生画像の表示を最優先とするが、受信装置２００が派生画像を表示できない場合には、その派生画像を構成する画像のうちの１つが派生画像に替えて表示される代替画像として用いられる。この場合、派生画像のプライマリ属性を最高優先度とし、代替画像として用いる画像にはその次の優先度を設定する。プライマリ属性の値が"0"を最高優先度とし、数が大きくなる毎に優先度が低くなるものとする。図１２では派生画像のプライマリ属性1201の値を"0"としている。また、次点として１つ目の構成画像のプライマリ属性1202の値を"1"として、更に次点として２つ目の構成画像のプライマリ属性1203の値と３つ目の構成画像のプライマリ属性1204の値を共に"2"としている。プライマリ属性の値が等しい場合は、どちらを選択しても良いものとする。

次に、代替画像を示す方法として、優先度ではなく代替グループを設定するケースについて、図１３を用いて説明する。図１３は、第２実施形態による送信装置１００において生成されるプレイリストの一例であり、画像に代替グループを設定する記述例である。図１３では、HEIFファイルに含まれている複数のコンテンツは、相互に代替する画像のグループを代替グループとして含み、関係情報は、複数の画像のそれぞれがどの代替グループに属するかを表す。

図１３において、画像１～６は代替グループ属性１３０１～１３０６が記述されており、代替グループ属性の値が等しいものが代替可能なグループを表す。図１３では、代替グループ属性１３０１～１３０３の値が"1"、代替グループ属性１３０４～１３０６の値が"2"と記述されている。よって、受信装置２００は、画像１～３の中から１つ、同様に画像４～６の中から１つを選択して使用する事ができる。図１３のプレイリストの例では、サイズの異なる複数の画像を含む２つの代替グループが記述されている。なお、図１３では、サイズが異なる複数の画像が代替グループに属している例を示したがこれに限られるものではない。例えば、異なる符号化方法で符号化された複数の画像が代替グループに属してもよい。このようにすれば、受信装置２００は、自身が対応している符号化データに対応して、柔軟に画像を選択することができる。

次に、受信装置２００において派生画像を表示できない場合を考慮して、生成済みの派生画像を用意するケースについて、図１４を用いて説明する。図１４は、第２実施形態による送信装置１００において生成されるプレイリストの一例であり、予め送信装置１００側で派生画像を生成することで派生画像を取得可能にする記述例である。

図１４のプレイリストにおいて、派生画像１４０１は、図１０における派生画像の記述と同様に４つの構成画像から生成される。派生画像１４０２は、派生画像１４０１を１つの画像としてHEVCで再符号化したものである。また、派生画像１４０３は、派生画像１４０１を１つの画像としてJPEGで再符号化したものである。派生画像１４０２，１４０３は、符号化データ変換部１０４で生成される。また、３つの派生画像は同じ代替グループに設定されている（alt="1"）。派生画像１４０２，１４０３は、派生画像１４０１の代替画像となり得る。従って、４つの構成画像から派生画像を生成する事ができない受信装置２００は、１つの画像として生成済みの派生画像である派生画像１４０２（HEIF）か派生画像１４０３（JPEG）のどちらかを取得して利用することができる。

以上、第２実施形態では、派生画像、代替画像に関する関係情報を例示した。なお、第２実施形態では、複数の静止画を組み合わせて１つの画像を表示する派生画像の記述方法を中心に説明してきたが、本実施形態で説明した方法を用いれば、静止画と動画を組み合わせた派生画像を記述する事も容易になし得る事は言うまでもない。

＜第３実施形態＞
次に、第３実施形態として、スライドショーの様に再生時間に応じて表示する画像を変更させるケースについて説明する。なお、第３実施形態による通信システムをおよび送信装置の構成、処理は第１実施形態（図１、図２、図３）と同様である。

図１５は、第３実施形態である送信装置において生成するプレイリストの一例であり、特に再生時刻の経過と共に取得可能な画像を変更する記述例である。図１５では、１０秒間のピリオド（duration="PTIM10.0S"）が３つ存在し、各々のピリオドで異なる画像が取得可能となっている。したがって、受信装置２００は各々のピリオドにおいて、異なる画像を取得して表示する事ができる。図１５のプレイリストの例では、image1.heic→image2.heic→image3.heicの順に、各画像が１０秒ずつ表示される。

次に、図１５を用いて説明した、再生時間に応じて表示する画像を変更するケースに対応したMPDの記述量を削減する方法について図１６を用いて説明する。図１６は、第３実施形態による送信装置１００において生成されるプレイリストの一例であり、特に再生時刻の経過と共に表示すべき画像を変更する記述例である。

配信可能な画像が複数のピリオドで共通な場合、同じ画像に関する情報（属性情報や取得用URLなど）をピリオド毎に記述するのは冗長である為、図１６では、ピリオド毎に異なる情報をまとめて記述する。図１６において、ピリオド情報１６０１には、ピリオド毎に異なる情報のみを記載するものとし、優先度要素１６０２としてピリオド毎に最優先となるRepresentationの識別子を記述する。尚、優先度要素の記述方法としては、ピリオド情報１６０３に記述されている優先度要素１６０４の様に、ピリオド毎に優先度が高い（或いは低い）順にRepresentationの識別子を記述しても良い。ここで、図１６に示すMPDの例を受信した受信装置２００は、各ピリオドにおいて、表示可能な画像の中で最も優先度が高い画像を表示する事が期待される。

以上のように、第１～第３実施形態によれば、HEIFファイルをMPEG-DASHで配信することが出来るので、例えばHEIFファイルの中から所望の静止画のみを取得したり、所定の時間毎に取得可能な静止画を設定したりすること、などが可能となる。

＜第４実施形態＞
第４実施形態では、第１実施形態～第３実施形態で説明した送信装置１００からプレイリストを受信し、受信したプレイリストを用いて送信装置１００からコンテンツ（画像）を取得する受信装置２００を説明する。

図１７は、受信装置２００のハードウエア構成例を示すブロック図である。受信装置２００において、通信部１７０１は、ネットワーク１５０と接続して送信装置１００との通信を行う。一つ又は複数のメモリ１７０２は、一つ又は複数のＣＰＵ１７０３により実行される各種プログラムを格納する。また、メモリ１７０２は、ＣＰＵ１７０３が各種処理を実行する際の作業メモリを提供する。メモリ１７０２は、ＲＯＭ、ＲＡＭ、ハードディスクなど、またはそれらの組み合わせである。ＣＰＵ１７０３は、メモリ１７０２に格納されたプログラムを実行して、各種の制御を実行する。例えば、ＣＰＵ１７０３は、送信装置１００からプレイリストを受信してメモリ１７０２に保持し、プレイリストを用いて送信装置１００から画像を取得し、ディスプレイ１７０４に画像を表示する。

図１８は、受信装置２００が送信装置１００からコンテンツ（画像）を取得する取得処理を説明するフローチャートである。ステップＳ１８０１において、ＣＰＵ１７０３は、送信装置１００にプレイリストを要求する。ステップＳ１８０２において、ＣＰＵ１７０３は、送信装置１００からプレイリストを受信する。受信したプレイリストは、メモリ１７０２に保持される。

次に、ＣＰＵ１７０３は、ステップＳ１８０３において、プレイリストの格納先が記載されたセグメントのうち、所望のセグメントを選択する。セグメントの選択は、例えば、受信装置２００に対するユーザ操作に基づいてなされてよいし、実行中のアプリケーションからの指示に基づいてなされてもよい。次に、ＣＰＵ１７０３は、ステップＳ１８０４において、ステップＳ１８０３で選択されたセグメントを送信装置１００に対して通信部１７０１を介して要求する。ステップＳ１８０５において、ＣＰＵ１７０３は、通信部１７０１を介して送信装置１００からセグメントのデータ（例えば、静止画、サムネイル画像など）を取得する。なお、ＣＰＵ１７０３は、プレイリスト中のセグメントに記述されたＵＲＬを用いて、送信装置１００からセグメントを取得することができる。ステップＳ１８０６において、ＣＰＵ１７０３は、ステップＳ１８０５で受信したデータを再生する。例えば、ＣＰＵ１７０３は、受信した静止画をディスプレイ１７０４に表示する。

例えば、以下のような処理が実現される。ＣＰＵ１７０３は、図４のプレイリストを受信した場合に、複数のサムネイル画像のセグメントを要求することにより複数のサムネイル画像を送信装置１００から取得してディスプレイ１７０４に表示する。その後、例えばユーザによるサムネイル画像の選択操作に応じて、ＣＰＵ１７０３は選択されたサムネイル画像に対応する静止画のセグメントを送信装置１００に要求し、そのセグメントデータである静止画を取得してディスプレイ１７０４に表示する。

また、ＣＰＵ１７０３は、最高優先度の画像を表示する設定の下で図１０のプレイリスト受信した場合に、最高優先度の画像は派生画像（グリッド画像）である。したがって、ＣＰＵ１７０３は、派生画像の記述に従って、必要な画像のセグメントを要求することにより４枚の画像を受信し、グリッド画像を生成し、ディスプレイ１７０４に表示する。また、第３実施形態の図１５、図１６に示したプレイリストを用いれば、受信装置２００は、HEIFファイルに含まれている複数のファイルを順次に、スライドショーのように表示させることができる。

以上のように、第１実施形態～第３実施形態のプレイリストを受信した受信装置は、複数のアイテムを含むＨＥＩＦファイルの全体を受信することなく、そのＨＥＩＦファイルに含まれている複数のアイテムの中の必要なアイテムを選択的に受信することができる。

＜その他の実施形態＞
以上、実施形態例を詳述したが、本発明は例えば、システム、装置、方法、プログラム若しくは記録媒体（記憶媒体）等としての実施態様をとることが可能である。具体的には、複数の機器（例えば、ホストコンピュータ、インターフェイス機器、撮像装置、ｗｅｂアプリケーション等）から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１００：送信装置、１０１：ファイル解析部、１０２：符号化データ抽出部、１０３：セグメント生成部、１０４：符号化データ変換部、１０５：配信データ格納部、１０６：プレイリスト生成部、１０７：通信部、１５０：ネットワーク、２００：受信装置

Claims (20)

1. 複数のコンテンツを含む所定のフォーマットのファイルを解析して前記複数のコンテンツおよび前記複数のコンテンツの関係を示す関係情報を取得する取得手段と、
   前記取得手段により取得された前記複数のコンテンツを格納する格納手段と、
   前記格納手段から前記複数のコンテンツを個別に取得するための取得情報と、前記関係情報とを記述したプレイリストを生成する生成手段と、
   前記プレイリストを外部装置に送信し、前記外部装置が前記プレイリストに含まれる前記取得情報を用いて要求したコンテンツを前記外部装置に送信する通信手段と、を備えることを特徴とするデータ処理装置。
2. 前記格納手段は、前記複数のコンテンツのそれぞれを、符号化データと前記符号化データの復号に必要な復号情報とを有する１つのファイルとして格納し、
   前記取得情報は、前記格納手段から前記１つのファイルを取得するための情報であることを特徴とする請求項１に記載のデータ処理装置。
3. 前記格納手段は、前記複数のコンテンツのそれぞれについて、コンテンツを符号化して得られる符号化データと前記符号化データの復号に必要な復号情報を別々に格納し、
   前記取得情報は、前記符号化データを取得するための情報を前記格納手段から取得するための情報と、前記復号情報を前記格納手段から取得するための情報と、を含むことを特徴とする請求項１または２に記載のデータ処理装置。
4. 前記複数のコンテンツは、静止画と前記静止画に対応するサムネイル画像とを含み、
   前記関係情報は、前記静止画と前記サムネイル画像の対応を示す情報を含む、ことを特徴とする請求項１乃至３のいずれか１項に記載のデータ処理装置。
5. 前記複数のコンテンツは複数の静止画を含み、
   前記関係情報は、前記複数の静止画の優先度を表す情報を含む、ことを特徴とする請求項１乃至４のいずれか１項に記載のデータ処理装置。
6. 前記複数のコンテンツは、画像と、前記画像に関連するメタデータとを含み、
   前記関係情報は、前記画像と前記メタデータとの対応を示す情報を含む、ことを特徴とする請求項１乃至５のいずれか１項に記載のデータ処理装置。
7. 前記複数のコンテンツは複数の画像を含み、
   前記関係情報は、前記複数の画像から派生する派生画像を表す、ことを特徴とする請求項１乃至６のいずれか１項に記載のデータ処理装置。
8. 前記派生画像は、前記複数の画像を並べて表示するグリッド画像であることを特徴とする請求項７に記載のデータ処理装置。
9. 前記派生画像は、前記複数の画像を重ね合わせて表示するオーバーレイ画像であることを特徴とする請求項７に記載のデータ処理装置。
10. 前記複数のコンテンツは、前記派生画像の生成に用いられる前記複数の画像の少なくとも１つに関連するアルファプレーンを含むことを特徴とする請求項７乃至９のいずれか１項に記載のデータ処理装置。
11. 前記関係情報は、前記派生画像と前記複数の画像について優先度を指定する情報を含むことを特徴とする請求項７乃至１０のいずれか１項に記載のデータ処理装置。
12. 前記派生画像を１つの画像として生成する生成手段をさらに備え、
    前記格納手段は、前記生成手段により生成された画像を前記外部装置から取得できるように格納し、
    前記取得情報は、前記生成手段により生成された画像を取得するための情報を含み、
    前記関係情報は、前記生成手段により生成された画像が前記派生画像の代替画像であることを示すことを特徴とする請求項７乃至１１のいずれか１項に記載のデータ処理装置。
13. 前記複数のコンテンツは複数の画像を含み、
    前記関係情報は、前記複数の画像のそれぞれが属する代替グループを表すことを特徴とする請求項１乃至６のいずれか１項に記載のデータ処理装置。
14. 前記複数のコンテンツは、複数の画像を含み、
    前記関係情報は、前記複数の画像の各々の取得可能な時間を示すことを特徴とする請求項１に記載のデータ処理装置。
15. 前記関係情報は、取得可能な時間のそれぞれにおいて取得可能な複数の画像が存在することと、それぞれの時間における画像の優先度とを示すことを特徴とする請求項１４に記載のデータ処理装置。
16. 前記所定のフォーマットはHEIF（High Efficiency Image File Format）であることを特徴とする請求項１乃至１５のいずれか１項に記載のデータ処理装置。
17. 請求項１乃至１６のいずれか１項に記載されたデータ処理装置の前記通信手段により送信された前記プレイリストを受信する受信手段と、
    前記プレイリストに記述された前記取得情報と前記関係情報とを用いて、必要なコンテンツの送信を前記データ処理装置に要求する要求手段と、
    前記要求手段の要求に応じて前記データ処理装置から送信されるコンテンツを受信し、処理する処理手段と、を備えることを特徴とするデータ処理装置。
18. 複数のコンテンツを含む所定のフォーマットのファイルを解析して前記複数のコンテンツおよび前記複数のコンテンツの関係を示す関係情報を取得する取得工程と、
    前記取得工程により取得された前記複数のコンテンツを格納手段に格納する格納工程と、
    前記格納手段から前記複数のコンテンツを個別に取得するための取得情報と、前記関係情報とを記述したプレイリストを生成する生成工程と、
    前記プレイリストを外部装置に送信し、前記外部装置が前記プレイリストに含まれる前記取得情報を用いて要求したコンテンツを前記外部装置に送信する通信工程と、を備えることを特徴とするデータ処理装置の制御方法。
19. 請求項１８に記載されたデータ処理装置の制御方法の実行により送信された前記プレイリストを受信する受信工程と、
    前記プレイリストに記述された前記取得情報と前記関係情報とを用いて、必要なコンテンツの送信を前記データ処理装置に要求する要求工程と、
    前記要求工程の要求に応じて前記データ処理装置から送信されるコンテンツを受信し、処理する処理工程と、を備えることを特徴とするデータ処理装置の制御方法。
20. コンピュータを、請求項１乃至１７のいずれか１項に記載のデータ処理装置の各手段として機能させるためのプログラム。

Images