JPWO2019138929A1 - 情報処理装置および方法 - Google Patents

情報処理装置および方法 Download PDF

Info

Publication number
JPWO2019138929A1
JPWO2019138929A1 JP2019564651A JP2019564651A JPWO2019138929A1 JP WO2019138929 A1 JPWO2019138929 A1 JP WO2019138929A1 JP 2019564651 A JP2019564651 A JP 2019564651A JP 2019564651 A JP2019564651 A JP 2019564651A JP WO2019138929 A1 JPWO2019138929 A1 JP WO2019138929A1
Authority
JP
Japan
Prior art keywords
picture
information
sub
file
image
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2019564651A
Other languages
English (en)
Other versions
JP7396047B2 (ja
Inventor
遼平 高橋
遼平 高橋
平林　光浩
光浩 平林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Publication of JPWO2019138929A1 publication Critical patent/JPWO2019138929A1/ja
Priority to JP2023194210A priority Critical patent/JP2024003189A/ja
Application granted granted Critical
Publication of JP7396047B2 publication Critical patent/JP7396047B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/172—Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/178—Metadata, e.g. disparity information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/161—Encoding, multiplexing or demultiplexing different image signal components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/194—Transmission of image signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/30—Image reproducers
    • H04N13/356—Image reproducers having separate monoscopic and stereoscopic modes
    • H04N13/359—Switching between monoscopic and stereoscopic modes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/119—Adaptive subdivision aspects, e.g. subdivision of a picture into rectangular or non-rectangular coding blocks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23418—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving operations for analysing video streams, e.g. detecting features or characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234345—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements the reformatting operation being performed only on part of the stream, e.g. a region of the image or a time segment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/84—Generation or processing of descriptive data, e.g. content descriptors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)

Abstract

本開示は、サブピクチャのストリームの選択をより容易に行うことができるようにする情報処理装置および方法に関する。全体ピクチャが複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、そのサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、画像符号化データの配信制御に用いられる制御ファイルを生成する。本開示は、例えば、情報処理装置、画像処理装置、画像符号化装置、ファイル生成装置、ファイル送信装置、配信装置、ファイル受信装置、画像復号装置、または再生装置等に適用することができる。

Description

本開示は、情報処理装置および方法に関し、特に、サブピクチャのストリームの選択をより容易に行うことができるようにした情報処理装置および方法に関する。
従来、HTTP（Hypertext Transfer Protocol）プロトコルによるアダプティブなコンテンツ配信技術の標準化規格として、MPEG-DASH（Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP）がある（例えば、非特許文献１、非特許文献２参照）。
また、このMPEG-DASHのファイルフォーマットとして、動画圧縮の国際標準技術「MPEG-4（Moving Picture Experts Group - 4）」のファイルコンテナ仕様であるISOBMFF（International Organization for Standardization Base Media File Format）がある（例えば、非特許文献３参照）。
ところで、所謂全天球映像のような、水平方向の周囲360度および垂直方向の周囲180度の画像を立体構造に投影した画像である立体構造画像を、平面画像にマッピングした全天球画像（投影平面画像とも称する）の配信にMPEG-DASHを利用することが考えられている。例えば、立体構造画像を単数の平面にマッピングし、その立体構造画像が平面にマッピングされた投影平面画像として配信することにより、MPEG-DASHを適用することができる。その際、１つの全天球映像の投影平面画像（全体ピクチャとも称する）を複数のサブピクチャ（sub-picture）に分割し、複数のトラック（track）に格納することも提案されている。なお、sub-pictureの表示領域を識別する場合には、まずsub-picture分割情報をもとにsub-pictureから全体ピクチャを構築したのちに、region-wise packing情報をもとにregion-wise packingされた全体ピクチャを配置しなおす処理が必要である（例えば、非特許文献４参照）。
"Information technology . Dynamic adaptive streaming over HTTP (DASH) . Part 1: Media presentation description and segment formats", ISO/IEC23009-1, 2014/05 "Information technology . Dynamic adaptive streaming over HTTP (DASH) . Part 1: Media presentation description and segment formats AMENDMENT2: Spatial relationship description, generalized URL parameters and other extensions", ISO/IEC 23009-1:2014/Amd 2:2015, 2015/07 "Information technology - Coding of audio-visual objects - Part 12: ISO base media file format", ISO/IEC 14496-12, 2005-10-01 Ye-Kui Wang, Youngkwon Lim,"MPEG#120 OMAF meeting agenda and minutes", ISO/IEC JTC1/SC29/WG11 MPEG2017/M41823, October 2017, Macau, China
しかしながら、現在提案されている方法では、sub-picture化がなされた場合、ピクチャ領域毎にサイズ・位置を変更した配置情報（分割前の全体ピクチャのregion-wise packing情報）は、Sub Picture Composition Boxの下のRegion Wise Packing Boxにシグナルされる。その為、sub-picture trackを選択・再生する場合、sub-picture trackのprojected picture上の表示領域を識別するために、Sub Picture Composition Boxをパースし、region-wise packing情報とsub-picture分割情報とを識別する必要があり、sub-picture trackではないtrackを選択・再生する場合に比べて、その処理の負荷が増大するおそれがあった。
本開示は、このような状況に鑑みてなされたものであり、サブピクチャのストリームの選択をより容易に行うことができるようにするものである。
本技術の一側面の情報処理装置は、全体ピクチャが複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成するファイル生成部を備える情報処理装置である。
本技術の一側面の情報処理方法は、全体ピクチャが複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成する情報処理方法である。
本技術の他の側面の情報処理装置は、全体ピクチャが複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得するファイル取得部と、前記ファイル取得部により取得された前記制御ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部とを備える情報処理装置である。
本技術の他の側面の情報処理方法は、全体ピクチャが複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得し、取得された前記制御ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う情報処理方法である。
本技術の一側面の情報処理装置および方法においては、全体ピクチャが複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、そのサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、画像符号化データの配信制御に用いられる制御ファイルが生成される。
本技術の他の側面の情報処理装置および方法においては、全体ピクチャが複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、そのサブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、画像符号化データの配信制御に用いられる制御ファイルが取得され、その取得された制御ファイルに含まれるその領域に関する情報に基づいて、画像符号化データのストリームの選択が行われる。
本開示によれば、情報を処理することができる。特に、サブピクチャのストリームの選択をより容易に行うことができる。
ISOBMFFのsub-picture trackのBox階層構造の例を示す図である。 ISOBMFFのsub-picture trackでないtrackのBox階層構造の例を示す図である。 Sub Picture Composition Boxのシンタックスの例を示す図である。 Sub Picture Region Boxのシンタックスの例を示す図である。 Sub Picture Region Box内で定義されるフィールドのセマンティクスの例を示す図である。 Region Wise Packing Boxのシンタックスの例を示す図である。 Region Wise Packing Structのシンタックスの例を示す図である。 Region Wise Packing Struct内で定義されるフィールドのセマンティクスの例を示す図である。 RectRegionPackingのシンタックスの例を示す図である。 RectRegionPacking内で定義されるフィールドのセマンティクスの例を示す図である。 ファイル生成装置の主な構成例を示すブロック図である。 クライアント装置の主な構成例を示すブロック図である。 表示領域情報の例を示す図である。 アップロード処理の流れの例を説明するフローチャートである。 コンテンツ再生処理の流れの例を説明するフローチャートである。 2D Coverage Information Boxのシンタックスの例を示す図である。 2D Coverage Information Box内で定義されるフィールドのセマンティクスの例を示す図である。 表示領域情報の例を示す図である。 不連続な領域を含むsub-pictureの例を示す図である。 2D Coverage Information Boxのシンタックスの例を示す図である。 この場合に追加されるフィールドのセマンティクスの例を示す図である。 Region Wise Packing Structのシンタックスの例を示す図である。 この場合に追加されるフィールドのセマンティクスの例を示す図である。 RectProjectedRegionのシンタックスの例を示す図である。 RectProjectedRegion内で定義されるフィールドのセマンティクスの例を示す図である。 Region Wise Packing Structのシンタックスの例を示す図である。 RectRegionPackingのシンタックスの例を示す図である。 Coverage Information Boxのシンタックスの例を示す図である。 Coverage Information Box内で定義されるフィールドのセマンティクスの例を示す図である。 Spherical offset projection SEI messageのシンタックスの例を示す図である。 Spherical offset projection SEI message内で定義されるフィールドのセマンティクスの例を示す図である。 2D Coverage Information Sample Entryのシンタックスの例を示す図である。 2D Coverage Information Sampleのシンタックスの例を示す図である。 Sample Table Boxの例を示す図である。 2D Coverage Information Sample Group Entryのシンタックスの例を示す図である。 アップロード処理の流れの例を説明するフローチャートである。 コンテンツ再生処理の流れの例を説明するフローチャートである。 2D coverage information descriptorの属性値の例を示す図である。 2D coverage information descriptorの属性値の例を示す図である。 データタイプの例を示す図である。 Region Wise Packing descriptorの属性値の例を示す図である。 Region Wise Packing descriptorの属性値の例を示す図である。 Content coverage descriptorの属性値の例を示す図である。 Content coverage descriptorの属性値の例を示す図４３に続く図である。 データタイプの例を示す図である。 データタイプの例を示す、図４５に続く図である。 データタイプの例を示す、図４６に続く図である。 sub-picture化の例を示す図である。 sub-picture化の例を示す図である。 sub-picture化の例を示す図である。 アップロード処理の流れの例を説明するフローチャートである。 コンテンツ再生処理の流れの例を説明するフローチャートである。 Original Stereo Video Boxのシンタックスの例を示す図である。 Original Stereo Video Box内で定義されるフィールドのセマンティクスの例を示す図である。 表示サイズのシグナルの例を示す図である。 Pixel Aspect Ratio Boxのシンタックスの例を示す図である。 Pixel Aspect Ratio Box内で定義されるフィールドのセマンティクスの例を示す図である。 表示時のピクセル縦横比のシグナルの例を示す図である。 Original Scheme Information Boxのシンタックスの例を示す図である。 2D Coverage Information Boxのシンタックスの例を示す図である。 2D Coverage Information Box内で定義されるフィールドのセマンティクスの例を示す図である。 stereo_presentation_suitableのシグナルの例を示す図である。 Track Stereo Video Boxのシンタックスの例を示す図である。 2D Coverage Information Boxのシンタックスの例を示す図である。 2D Coverage Information Box内で定義されるフィールドのセマンティクスの例を示す図である。 view_idcのシグナルの例を示す図である。 アップロード処理の流れの例を説明するフローチャートである。 コンテンツ再生処理の流れの例を説明するフローチャートである。 2D coverage information descriptorの属性値の例を示す図である。 2D coverage information descriptorの属性値の例を示す、図６９に続く図である。 データタイプの例を示す図である。 コンピュータの主な構成例を示すブロック図である。 Sub Picture Composition Boxのシンタクスの例を示す図である。 Supplemental Propertyのシンタクスの例を示す図である。
以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．sub-pictureに関する情報のシグナル
２．第１の実施の形態（sub-pictureの表示領域のシグナル、ISOBMFFの拡張）
３．第２の実施の形態（sub-pictureの表示領域のシグナル、MPDの拡張）
４．第３の実施の形態（全体ピクチャのステレオ情報のシグナル、ISOBMFFの拡張）
５．第４の実施の形態（全体ピクチャのステレオ情報のシグナル、MPDの拡張）
６．付記
＜１．sub-pictureに関する情報のシグナル＞
＜技術内容・技術用語をサポートする文献等＞
本技術で開示される範囲は、実施の形態に記載されている内容だけではなく、出願当時において公知となっている以下の非特許文献に記載されている内容も含まれる。
非特許文献１：（上述）
非特許文献２：（上述）
非特許文献３：（上述）
非特許文献４：（上述）
つまり、上述の非特許文献に記載されている内容もサポート要件を判断する際の根拠となる。例えば、パース（Parsing）、シンタックス（Syntax）、セマンティクス（Semantics）等の技術用語についても同様に、実施の形態において直接的な記載がない場合でも、本技術の開示範囲内であり、請求の範囲のサポート要件を満たすものとする。
＜MPEG-DASH＞
従来、例えば非特許文献１や非特許文献２に記載のように、HTTP（Hypertext Transfer Protocol）プロトコルによるアダプティブなコンテンツ配信技術の標準化規格として、MPEG-DASH（Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP）がある。
このMPEG-DASHにより、例えば、ウェブサイトからインターネットのウェブページをダウンロードする場合と同様の通信プロトコルであるHTTPを用いて、ネットワーク帯域の変動に応じた最適なビットレートでのビデオ再生を実現することができる。
この標準規格により、動画配信サービスのためのインフラや動画再生クライアント向けの技術開発をより容易にすることができる。特に、配信サービスを手掛ける事業者にとっては、動画配信サービスと動画再生クライアントとの間の互換性が向上する他、既存のコンテンツ資産を活用しやすい利点があり、市場の成長を促進する効果が期待される。
MPEG-DASHは、主に、２つの技術企画で構成されている。動画や音声ファイルを管理するメタデータを記述したMPD（Media Presentation Description）と称するマニュフェストファイル仕様を定めた規格と、実際に動画コンテンツを伝達するためのセグメントフォーマット(segment format)と称するファイルフォーマットの運用規格である。
このファイルフォーマットとして、例えば非特許文献３に記載のように、動画圧縮の国際標準技術「MPEG-4（Moving Picture Experts Group - 4）」のファイルコンテナ仕様であるISOBMFF（International Organization for Standardization Base Media File Format）がある。ISOBMFFには、MPEG-DASHの要件を満たすための機能拡張がISO/IEC（International Organization for Standardization / International Electrotechnical Commission） 14496-12の拡張仕様として加えられた。
＜MPEG-DASHを用いた全天球映像の配信＞
ところで、所謂全天球映像のように、水平方向の周囲360度および垂直方向の周囲180度の画像を立体構造に投影した立体構造画像を、平面画像にマッピングした投影平面画像がある。例えば、視点から見た周辺の画像（全天球映像）をその視点を中心とする立体構造にレンダリングして立体構造画像とすることにより、視点の周辺の画像をより自然に表現したり、その立体構造画像から所望の視線方向の画像を容易に生成したりすることができる。
近年、この投影平面画像（全天球映像等）の配信にMPEG-DASHを利用することが考えられている。例えば非特許文献４に記載のように、立体構造画像を単数の平面にマッピングし、その立体構造画像が平面にマッピングされた投影平面画像として配信することにより、MPEG-DASHを適用することができる。
立体構造に投影し、平面へマッピングする方法（プロジェクションフォーマット（projection format）とも称する）として、例えば、ERP（Equirectangular projection（正距円筒））やCMP（Cubemap projection（キューブマップ））等がある。例えば、ERPの場合、水平方向の周囲360度および垂直方向の周囲180度の画像が球状の立体構造に投影された立体構造画像が、単数の平面に、球状の立体構造の緯度方向と経度方向とが直交するようにマッピングされる。また、例えばCMPの場合、水平方向の周囲360度および垂直方向の周囲180度の画像が立方体の各面に投影された立体構造画像の各面が展開され、単数の平面に所定の順に並べるようにマッピングされる。
このように全天球映像が投影・マッピングされた投影平面画像をプロジェクテドピクチャ（projected picture）とも称する。つまり、projected pictureとは、projection format毎に決まる、全天球映像を表現する２次元画像（２次元picture）のことである。
非特許文献４に記載のMPEG-I Part2 Omnidirectional Media Format（ISO/IEC 23090-2）FDIS（Final Draft International Standards）（以下、OMAFとも称する）では、１つの全天球映像の投影平面画像（全体ピクチャとも称する）を複数のサブピクチャ（sub-picture）に分割し、複数のトラック（track）に格納する技術の議論がなされている。
例えば、特定の視野領域ごとに、視野に対応するサブピクチャトラック（sub-picture track）を構成し、クライアントは自身の視野領域に応じてそのsub-picture trackを選択・再生する、といったユースケースがある。
＜ISOBMFFファイルのBox階層構造＞
図１のBox階層構造１１は、全天球映像をsub-picture track化する場合のISOBMFFファイルのBox階層構造の例を示す。
Box階層構造１１に示されるように、この場合、Track Group Boxの下に全体ピクチャについての情報が格納される。例えば、Sub Picture Composition Box（spco）には、ピクチャがsub-picture化されているか等の、sub-picture trackのgroupingに使用される情報が格納される。また、その下には、Sub Picture Region Box（sprg）、Region Wise Packing Box（rwpk）、Stereo Video Box（stvi）等のBoxが形成される。
Sub Picture Region Boxには、sub-pictureの分割の仕方等を示すsub-picture分割情報が格納される。また、Region Wise Packing Boxには、分割前の全体ピクチャのregion-wise packing情報が格納される。また、Stereo Video Boxには、全体ピクチャのステレオ表示（立体視表示）に関する情報（ステレオ情報）が格納される。ステレオ情報とは、例えばサイドバイサイド（side by side）やトップアンドボトム（top & bottom）等、立体視表示用画像の種類などを示す情報である。
また、Media Box（mdia）の下のMedia Information Box（minf）の下のSample Table Box（stbl）の下のSample Description Box（stsd）の下のRestricted Sample Entry（resv）（Sample Entryの一種）の下のRestricted Scheme Information Box（rinf）の下のScheme Information Box（schi）の下には、Projected Omnidirectional Video Box（povd）、StereoVideoBox（stvi）等のBoxが形成される。
Projected Omnidirectional Video Boxには、全天球映像に関連するメタデータが格納される。StereoVideoBoxには、そのBoxが対応するsub-pictureについてのステレオ情報が格納される。
図２のBox階層構造１２は、全天球映像をsub-picture track化しない場合のISOBMFFファイルのBox階層構造の例を示す。
Box階層構造１２に示されるように、この場合、Track Group Boxは形成されず、Region Wise Packing Boxは、Projected Omnidirectional Video Boxの下に形成される。
つまり、sub-picture化がなされた場合、ピクチャ領域ごとにサイズ・位置を変更した配置情報を示すRegion Wise Packing Boxは、Sub Picture Composition Boxのみにシグナルされ、分割前の全体ピクチャのregion-wise packing情報を有する。これに対して、sub-picture化がなされていない場合、Region Wise Packing Boxは、Projected Omnidirectional Video Boxにシグナルされ、trackに格納されたピクチャのregion-wise packing情報を有する。以下において、Sub Picture Composition Boxを有するtrackをsub-picture trackと称する。
＜sub-picture trackの選択＞
その為、トラック（track）がsub-picture trackであるか、sub-picture化がなされていない通常のtrackであるかによって、クライアントがそのtrackの画像の、投影平面画像（projected picture）上における表示領域を識別するための処理が異なる。例えば、sub-picture trackを選択・再生する場合、sub-picture trackのprojected picture上の表示領域を識別するために、Sub Picture Composition Boxをパースし、region-wise packing情報とsub-picture分割情報とを識別する必要がある。これに対して、sub-picture trackではないtrackを選択・再生する場合、この処理は不要である。
図３のシンタックス２１は、Sub Picture Composition Boxのシンタックスの例を示す。シンタックス２１に示されるように、このSub Picture Composition Boxにおいて、Sub Picture Region BoxとRegion Wise Packing Boxとがセットされる。
図４のシンタックス２２は、Sub Picture Region Boxのシンタックスの例を示す。シンタックス２２に示されるように、このSub Picture Region Boxにおいて、track_x、track_y、track_width、track_height、composition_width、composition_height等のフィールドが定義される。
図５のセマンティクス２３は、Sub Picture Region Box内で定義されるフィールドのセマンティクスの例を示す。セマンティクス２３に示されるように、track_xは、trackに格納されるsub-pictureの、全体ピクチャ上での水平方向位置を示す。track_yは、trackに格納されるsub-pictureの、全体ピクチャ上での垂直方向位置を示す。track_widthは、trackに格納されるsub-pictureの幅を示す。track_heightは、trackに格納されるsub-pictureの高さを示す。composition_widthは、全体ピクチャの幅を示す。composition_heightは、全体ピクチャの高さを示す。
図６のシンタックス２４は、Region Wise Packing Boxのシンタックスの例を示す。シンタックス２４に示されるように、このRegion Wise Packing Boxにおいて、Region Wise Packing Structがセットされる。
図７のシンタックス２５は、Region Wise Packing Structのシンタックスの例を示す。シンタックス２５に示されるように、このRegion Wise Packing Structにおいて、constituent_picture_matching_flag、num_regions、proj_picture_width、proj_picture_height、packed_picture_width、packed_picture_height、guard_band_flag[i]、packing_type[i]、GuardBand(i)等のフィールドがセットされる。
図８のセマンティクス２６は、Region Wise Packing Struct内で定義されるフィールドのセマンティクスの例を示す。セマンティクス２６に示されるように、constituent_picture_matching_flagは、ピクチャがステレオの場合、左目用ビュー（Left view）および右目用ビュー（Right view）に対して同じregion-wise packingが適用されるか否かを示すフラグ情報である。例えば、このフィールドの値が０の場合、モノ（単視点ビュー）であるか、または、Left viewおよびRight viewに互いに異なるpackingが適用されることを示す。また、このフィールドの値が１の場合、Left viewおよびRight viewに対して同じpackingが適用されることを示す。
また、num_regionsは、packed regionの数を示す。proj_picture_widthは、projected pictureの幅を示す。proj_picture_heightは、projected pictureの高さを示す。packed_picture_widthは、packed picture（region-wise packingされたpicture）の幅を示す。packed_picture_heightは、packed pictureの高さを示す。
また、guard_band_flag[i]は、ガードバンドが存在するか否かを示すフラグ情報である。例えば、このフィールドの値が０の場合、packed regionにガードバンドが存在しないことを示し、このフィールドの値が１の場合、packed regionにガードバンドが存在することを示す。packing_type[i]は、packed regionの形状を示す。例えばこのフィールドの値が０の場合、packed regionが矩形であることを示す。GuardBand(i)は、領域周囲のガードバンド情報である。
また、シンタックス２５に示されるように、Region Wise Packing Structにおいては、さらに、RectRegionPackingがセットされる。図９のシンタックス２７は、このRectRegionPackingのシンタックスの例を示す。シンタックス２７に示されるように、このRectRegionPackingにおいて、proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]、proj_reg_left[i]、transform_type[i]、packed_reg_width[i]、packed_reg_height[i]、packed_reg_top[i]、packed_reg_left[i]等のフィールドがセットされる。
図１０のセマンティクス２８は、RectRegionPacking内で定義されるフィールドのセマンティクスの例を示す。セマンティクス２８に示されるように、proj_reg_width[i]は、region-wise packing適用元のprojected regionの幅を示す。proj_reg_height[i]は、region-wise packing適用元のprojected regionの高さを示す。proj_reg_top[i]は、region-wise packing適用元のprojected regionの垂直方向位置を示す。proj_reg_left[i]は、region-wise packing適用元のprojected regionの水平方向位置を示す。transform_type[i]は、packed regionの回転やミラーリングを示す。packed_reg_width[i]は、region-wise packingで再配置されたpacked regionの幅を示す。packed_reg_height[i]は、region-wise packingで再配置されたpacked regionの高さを示す。packed_reg_top[i]は、region-wise packingで再配置されたpacked regionの垂直方向位置を示す。packed_reg_left[i]は、region-wise packingで再配置されたpacked regionの水平方向位置を示す。
つまり、例えばクライアントがユーザの視野に応じてsub-picture trackを選択するような場合、これらの情報をパースする必要があり、sub-picture trackではないtrackを選択・再生する場合に比べて、その処理の負荷が増大するおそれがあった。
＜ステレオ情報の識別＞
また、ステレオ全天球映像の全体ピクチャをsub-picture化した場合、全体ピクチャのステレオ情報（全体ピクチャがどのような種類の立体視表示用画像であるか等）を示すStereo Video Boxは、Sub Picture Composition Boxにシグナルされ、sub-pictureのステレオ情報（sub-pictureがどのような種類の立体視表示用画像であるか等）を示すStereo Video Boxは、trackのSample EntryのScheme Information Box下にシグナルされる。これに対して、sub-picture化がなされていない場合、Stereo Video Boxは、Scheme Information Box下のみにシグナルされ、trackに格納されたピクチャのステレオ情報を有する。
その為、trackがsub-picture trackか、sub-picture化がなされていない通常のtrackかによって、クライアントがそのtrackのステレオ情報を識別するための処理が異なる。例えば、全体ピクチャがステレオ画像（立体視用画像）である場合、分割されたsub-picture trackは、L viewおよびR viewを含むが、フレームパッキングアレンジメントがtop & bottomでもside by sideでもない場合がある。
したがって、このようなsub-pictureがステレオで表示可能か否かを識別する場合、Sub Picture Composition Boxをパースし、region-wise packing情報とsub-picture分割情報、およびステレオ情報を識別する処理が必要となる。これに対して、sub-picture trackではないtrackを選択・再生する場合、この処理は不要である。
つまり、例えばクライアントが自身のステレオ表示能力に応じてsub-picture trackを選択する場合、sub-picture trackではないtrackを選択・再生する場合に比べて、その処理の負荷が増大するおそれがあった。
以上においては、ISOBMFFファイルにおけるsub-picture trackの選択について説明したが、MPDファイルでは、sub-pictureは、アダプテーションセット（Adaptation Set）として管理される。このMPDファイルにおけるsub-pictureを参照するAdaptation Setの選択についても同様の理由により、処理の負荷が増大するおそれがあった。つまり、ISOBMFFファイルの場合またはMPDファイルの場合に関わらず、ストリームの選択の負荷が増大するおそれがあった。
＜sub-pictureの表示領域のシグナル＞
そこで、全体ピクチャをサブピクチャ（sub-picture）化する場合、そのsub-pictureの表示領域に関する情報をシグナルする（コンテンツの再生側に提供する）ようにする。表示領域とは、全体ピクチャにおける領域のことを示す。すなわち、sub-pictureの表示領域に関する情報とは、そのsub-pictureに対応するピクチャ全体における領域に関する情報、つまり、sub-pictureが全体ピクチャのどの部分の画像であるかを示す情報である。この情報により、例えば、sub-pictureに対応する領域の位置、大きさ、形状等が示される。領域の表現方法は任意であり、例えば、領域の範囲が座標等により示されるようにしてもよい。
このようにすることにより、コンテンツを再生するクライアントは、この情報に基づいて、sub-pictureが全天球映像において何処に表示されるかを把握することができる。
その際、このsub-pictureの表示領域に関する情報を、sub-picture毎の情報としてシグナルするようにする。このようにすることにより、クライアントは、容易にこの情報を得ることができる。したがって、クライアントは、所望のサブピクチャのストリームを容易に選択することができる。例えば、ユーザの視野に応じてストリームを選択する場合に、クライアントは、その視野の方向や範囲に対応する適切なストリームを容易に選択することができる。
＜sub-picture化される全体ピクチャのステレオ情報のシグナル＞
また、sub-picture化されるピクチャ全体のステレオ表示に関する情報であるステレオ情報をシグナルするようにする。このようにすることにより、コンテンツを再生するクライアントは、この情報に基づいて全体ピクチャがステレオ画像（立体視用画像）であるか否かや、ステレオ画像である場合はその種類（タイプ）等を容易に把握することができる。これにより、クライアントは、sub-pictureに含まれる画像がどのような画像であるか（例えばどのようなタイプのステレオ画像（またはモノ画像（単視点画像））のどの部分に対応するのか等）を容易に把握することができる。
したがって、クライアントは、所望のストリームを容易に選択することができる。例えば自身の能力（capability）に応じてストリームを選択する場合に、クライアントは、その自身の能力（capability）に応じた適切なストリームを容易に選択することができる。
＜ファイル生成装置＞
次に、sub-pictureに関するシグナルを行う装置の構成について説明する。図１１は、本技術を適用した情報処理装置の一態様であるファイル生成装置の構成の一例を示すブロック図である。図１１に示されるファイル生成装置１００は、ISOBMFFファイル（セグメントファイル）やMPDファイルを生成する装置である。例えば、ファイル生成装置１００は、非特許文献１乃至非特許文献４に記載されている技術を実装し、MPEG-DASHに準拠した方法で、ストリームを含むISOBMFFファイルや、ストリームの配信制御に用いられる制御ファイルであるMPDファイルを生成し、それらのファイルを、ネットワークを介して、それらのファイルを配信するサーバにアップロード（送信）する。
なお、図１１においては、処理部やデータの流れ等の主なものを示しており、図１１に示されるものが全てとは限らない。つまり、ファイル生成装置１００において、図１１においてブロックとして示されていない処理部が存在したり、図１１において矢印等として示されていない処理やデータの流れが存在したりしてもよい。
図１１に示されるようにファイル生成装置１００は、制御部１０１、メモリ１０２、およびファイル生成部１０３を有する。
制御部１０１は、ファイル生成装置１００全体の動作を制御する。例えば制御部１０１は、ファイル生成部１０３を制御して、ISOBMFFファイルやMPDファイルを生成させたり、生成されたISOBMFFファイルやMPDファイルをアップロードさせたりする。制御部１０１は、このような制御に関する処理を、メモリ１０２を利用して行う。例えば、制御部１０１は、所望のプログラム等をメモリ１０２にロードして実行することにより、上述のような制御に関する処理を行う。
ファイル生成部１０３は、制御部１０１の制御に従って、ISOBMFFファイルやMPDファイルの生成やアップロード（送信）に関する処理を行う。図１１に示されるように、ファイル生成部１０３は、データ入力部１１１、データ符号化・生成部１１２、MPDファイル生成部１１３、記録部１１４、およびアップロード部１１５を有する。
データ入力部１１１は、データ入力の受け付けに関する処理を行う。例えば、データ入力部１１１は、テクスチャやメッシュの生成に必要な画像等のデータや、MPDファイルの生成に必要なメタデータ等の入力を受け付ける。また、データ入力部１１１は、受け付けたデータを、データ符号化・生成部１１２やMPDファイル生成部１１３に供給する。
データ符号化・生成部１１２は、データの符号化やファイルの生成に関する処理を行う。例えば、データ符号化・生成部１１２は、データ入力部１１１から供給された画像等のデータに基づいて、テクスチャやメッシュ等のストリームを生成する。また、データ符号化・生成部１１２は、生成したストリームを格納するISOBMFFファイルを生成する。また、データ符号化・生成部１１２は、生成したISOBMFFファイルを記録部１１４に供給する。
図１１に示されるように、データ符号化・生成部１１２は、前処理部１２１、エンコード部１２２、およびセグメントファイル生成部１２３を有する。
前処理部１２１は、符号化前の画像等のデータに対する処理を行う。例えば、前処理部１２１は、データ入力部１１１から供給された画像等のデータに基づいて、テクスチャやメッシュのストリームを生成する。また、例えば、前処理部１２１は、その生成したストリームをエンコード部１２２に供給する。
エンコード部１２２は、ストリームの符号化に関する処理を行う。例えば、エンコード部１２２は、前処理部１２１から供給されたストリームを符号化する。また、例えば、エンコード部１２２は、その符号化により得られた符号化データを、セグメントファイル生成部１２３に供給する。
セグメントファイル生成部１２３は、セグメントファイルの生成に関する処理を行う。例えば、セグメントファイル生成部１２３は、データ入力部１１１から供給されたメタデータ等に基づいて、エンコード部１２２から供給された符号化データをセグメント単位でファイル化する（セグメントファイルを生成する）。また、例えば、セグメントファイル生成部１２３は、セグメントファイルの生成に関する処理として、以上のように生成したISOBMFFファイルを記録部１１４に供給する。例えば、セグメントファイル生成部１２３は、セグメントファイルとしてISOBMFFファイルを生成し、生成したISOBMFFファイルを記録部１１４に供給する。
MPDファイル生成部１１３は、MPDファイルの生成に関する処理を行う。例えば、MPDファイル生成部１１３は、データ入力部１１１から供給されたメタデータ等に基づいて、MPDファイルを生成する。また、例えば、MPDファイル生成部１１３は、生成したMPDファイルを記録部１１４に供給する。なお、MPDファイル生成部１１３は、MPDファイルの生成に必要なメタデータ等をセグメントファイル生成部１２３から取得するようにしてもよい。
記録部１１４は、例えば、ハードディスクや半導体メモリ等の任意の記録媒体を有し、データの記録等に関する処理を行う。例えば、記録部１１４は、MPDファイル生成部１１３から供給されたMPDファイルを記録する。また、例えば、記録部１１４は、セグメントファイル生成部１２３から供給されたセグメントファイル（例えばISOBMFFファイル）を記録する。
アップロード部１１５は、ファイルのアップロード（送信）に関する処理を行う。例えば、アップロード部１１５は、記録部１１４に記録されているMPDファイルを読み出す。また、例えば、アップロード部１１５は、読み出したMPDファイルを、ネットワーク等を介して、MPDファイルをクライアント等に配信するサーバ（図示せず）にアップロード（送信）する。
また、例えば、アップロード部１１５は、記録部１１４に記録されているセグメントファイル（例えばISOBMFFファイル）を読み出す。また、例えば、アップロード部１１５は、読み出したそれらのセグメントファイルを、ネットワーク等を介して、セグメントファイルをクライアント等に配信するサーバ（図示せず）にアップロード（送信）する。
つまり、アップロード部１１５は、MPDファイルやセグメントファイル（例えばISOBMFFファイル）をサーバに送信する通信部として機能する。なお、アップロード部１１５によるMPDファイルの送信先とセグメントファイル（例えばISOBMFFファイル）の送信先は、互いに同一であってもよいし、互いに異なっていてもよい。また、ここでは、ファイル生成装置１００が、MPDファイルやセグメントファイル（例えばISOBMFFファイル）を、それらのファイルをクライアントに配信するサーバにアップロードする装置として機能する例について説明するが、ファイル生成装置１００がそのサーバとして機能するようにしてもよい。その場合、ファイル生成装置１００のアップロード部１１５が、ネットワークを介してMPDファイルやセグメントファイル（例えばISOBMFFファイル）をクライアントに配信するようにすればよい。
＜クライアント装置＞
図１２は、本技術を適用した情報処理装置の一態様であるクライアント装置の構成の一例を示すブロック図である。図１２に示されるクライアント装置２００は、MPDファイルやセグメントファイル（例えばISOBMFFファイル）を取得し、それらのファイルに基づいて、コンテンツを再生する装置である。例えば、クライアント装置２００は、非特許文献１乃至非特許文献４に記載されている技術を実装し、MPEG-DASHに準拠した方法でセグメントファイルをサーバ（または上述のファイル生成装置１００）より取得し、そのセグメントファイルに含まれるストリーム（コンテンツ）を再生する。その際、クライアント装置２００は、MPDファイルをサーバ（または上述のファイル生成装置１００）より取得し、そのMPDファイルを利用して所望のセグメントファイルを選択し、サーバより取得するようにしてもよい。
なお、図１２においては、処理部やデータの流れ等の主なものを示しており、図１２に示されるものが全てとは限らない。つまり、クライアント装置２００において、図１２においてブロックとして示されていない処理部が存在したり、図１２において矢印等として示されていない処理やデータの流れが存在したりしてもよい。
図１２に示されるようにクライアント装置２００は、制御部２０１、メモリ２０２、および再生処理部２０３を有する。
制御部２０１は、クライアント装置２００全体の動作を制御する。例えば制御部２０１は、再生処理部２０３を制御して、サーバからMPDファイルやセグメントファイル（例えばISOBMFFファイル）を取得させたり、セグメントファイルに含まれるストリーム（コンテンツ）を再生させたりする。制御部２０１は、このような制御に関する処理を、メモリ２０２を利用して行う。例えば、制御部２０１は、所望のプログラム等をメモリ２０２にロードして実行することにより、上述のような制御に関する処理を行う。
再生処理部２０３は、制御部２０１の制御に従って、セグメントファイルに含まれるストリーム（コンテンツ）の再生に関する処理を行う。図１２に示されるように、再生処理部２０３は、計測部２１１、MPDファイル取得部２１２、MPDファイル処理部２１３、セグメントファイル取得部２１４、表示制御部２１５、データ解析・復号部２１６、および表示部２１７を有する。
計測部２１１は、計測に関する処理を行う。例えば、計測部２１１は、クライアント装置２００とサーバとの間のネットワークの伝送帯域を計測する。また、例えば、計測部２１１は、その計測結果をMPDファイル処理部２１３に供給する。
MPDファイル取得部２１２は、MPDファイルの取得に関する処理を行う。例えば、MPDファイル取得部２１２は、所望のコンテンツ（再生するコンテンツ）に対応するMPDファイルを、ネットワークを介してサーバから取得する。また、例えば、MPDファイル取得部２１２は、取得したMPDファイルをMPDファイル処理部２１３に供給する。
MPDファイル処理部２１３は、MPDファイルに基づく処理を行う。例えば、MPDファイル処理部２１３は、MPDファイル取得部２１２から供給されたMPDファイルに基づいて、取得するストリームを選択する。また、例えば、MPDファイル処理部２１３は、その選択結果をセグメントファイル取得部２１４に供給する。なお、取得するストリームの選択にあたっては、計測部２１１から供給された計測結果や、表示制御部２１５から供給されたユーザの視点位置や視線方向に関する情報も適宜利用される。
セグメントファイル取得部２１４は、セグメントファイル（例えばISOBMFFファイル）の取得に関する処理を行う。例えば、セグメントファイル取得部２１４は、所望のコンテンツの再生に必要なストリームが格納されたセグメントファイルを、ネットワークを介してサーバから取得する。また、例えば、セグメントファイル取得部２１４は、取得したセグメントファイルをデータ解析・復号部２１６に供給する。
なお、セグメントファイル取得部２１４がセグメントファイル（例えばISOBMFFファイル）を取得するサーバは、MPDファイル取得部２１２がMPDファイルを取得するサーバと同一であってもよいし、異なっていてもよい。また、セグメントファイル取得部２１４が、MPDファイル処理部２１３から供給されるストリームの選択結果に基づいて、セグメントファイルを取得するようにしてもよい。つまり、セグメントファイル取得部２１４が、MPDファイル等に基づいて選択されたストリームが格納されたセグメントファイルをサーバから取得するようにしてもよい。
表示制御部２１５は、コンテンツの再生（表示）の制御に関する処理を行う。例えば、表示制御部２１５は、コンテンツを視聴するユーザの視点位置や視線方向の検出結果を取得する。また、例えば、表示制御部２１５は、その取得した検出結果（ユーザの視点位置や視線方向に関する情報）をMPDファイル処理部２１３やデータ解析・復号部２１６に供給する。
データ解析・復号部２１６は、データの解析や復号等に関する処理を行う。例えば、データ解析・復号部２１６は、セグメントファイル取得部２１４から供給されたISOBMFFファイルを処理し、コンテンツの表示用画像を生成する。また、データ解析・復号部２１６は、その表示用画像のデータを表示部２１７に供給する。
図１２に示されるように、データ解析・復号部２１６は、セグメントファイル処理部２２１、デコード部２２２、および表示情報生成部２２３を有する。
セグメントファイル処理部２２１は、セグメントファイル（例えばISOBMFFファイル）に対する処理を行う。例えば、セグメントファイル処理部２２１は、セグメントファイル取得部２１４から供給されたISOBMFFファイルから所望のストリームの符号化データを抽出する。また、例えば、セグメントファイル処理部２２１は、抽出した符号化データをデコード部２２２に供給する。
なお、セグメントファイル処理部２２１が、表示制御部２１５から供給されたユーザの視点位置や視線方向に関する情報や計測部２１１において計測された伝送帯域等に基づいて、ストリームを選択し、そのストリームの符号化データをセグメントファイルから抽出するようにしてもよい。
デコード部２２２は、復号に関する処理を行う。例えば、デコード部２２２は、セグメントファイル処理部２２１から供給された符号化データを復号する。また、例えば、デコード部２２２は、その復号により得られたストリームを表示情報生成部２２３に供給する。
表示情報生成部２２３は、表示用画像のデータの生成に関する処理を行う。例えば、表示情報生成部２２３は、表示制御部２１５から供給されたユーザの視点位置や視線方向に関する情報と、デコード部２２２から供給されたストリームとに基づいて、ユーザの視点位置や視線方向に応じた表示用画像のデータを生成する。また、例えば、表示情報生成部２２３は、生成された表示用画像のデータを、表示部２１７に供給する。
表示部２１７は、例えば液晶表示パネル等を用いたディスプレイやプロジェクタ等の任意の表示デバイスを有し、その表示デバイスを用いた画像表示に関する処理を行う。例えば、表示部２１７は、表示情報生成部２２３から供給されたデータに基づいて、画像表示等のコンテンツ再生を行う。
＜２．第１の実施の形態＞
＜ISOBMFFによるsub-pictureの表示領域情報のシグナル＞
上述したsub-pictureの表示領域に関する情報のシグナルを、セグメントファイルであるISOBMFFファイルにおいて行うようにしてもよい。
つまり、格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、そのサブピクチャが符号化された画像符号化データを含むファイルを生成するようにしてもよい。
例えば、情報処理装置であるファイル生成装置１００において、セグメントファイル生成部１２３が、格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、そのサブピクチャが符号化された画像符号化データを含むファイルを生成するファイル生成部として機能するようにしてもよい。つまり情報処理装置（例えばファイル生成装置１００）が、ファイル生成部（例えばセグメントファイル生成部１２３）を備えるようにしてもよい。
このようにすることにより、上述したように、クライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
なお、ISOBMFFファイルにおいては、ストリームはトラック（track）として管理される。つまり、ISOBMFFファイルを用いる場合、trackを選択することにより、ストリームの選択が行われる。
また、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。全天球映像は、視点を中心とする全方位の画像（つまり、視点から見た周辺の画像）である。この全天球映像は、立体構造にレンダリングして水平方向の周囲360度および垂直方向の周囲180度の画像とすることができる。上述のように、立体構造画像を単数の平面にマッピングして投影平面画像とすることにより、MPEG-DASHを適用したストリーム配信制御が可能になる。つまり、ファイル生成装置１００が、このような投影平面画像の全部、または一部を全体ピクチャとし、それをsub-picture化する場合において、上述のように本技術を適用することができる。なお、投影平面画像の一部を全体ピクチャとした場合においても、sub-pictureの投影平面画像全部における表示領域に関する情報がシグナルされる。
例えば、図１３に示されるように、水平方向の周囲360度および垂直方向の周囲180度の画像がCubemap projectionにより立体構造（立方体）に投影されて立体構造画像３０１が生成される。また、その立体構造画像３０１が所定の方法で単数の平面にマッピングされ、投影平面画像（projected picture）３０２が生成される。ファイル生成装置１００は、このような投影平面画像３０２をsub-picture化して、sub-pictures（sub-picture３０３乃至sub-picture３０８）を生成し、それぞれを互いに異なるtrackに格納するISOBMFFファイルを生成する。
その際、ファイル生成装置１００は、矢印３１１に示されるように、どのsub-pictureが、全体ピクチャ（投影平面画像３０２）のどの部分に対応するかを示す情報（表示領域情報）をISOBMFFファイルにおいてシグナルする。
このようにすることにより、全天球映像を配信する場合においても、上述したようにクライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
なお、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてISOBMFFファイルに含まれるようにしてもよい。このようにすることにより、クライアントは、sub-picture trackの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
＜アップロード処理の流れ＞
その場合の図１１のファイル生成装置１００により実行されるアップロード処理の流れの例を、図１４のフローチャートを参照して説明する。
アップロード処理が開始されると、ファイル生成装置１００のデータ入力部１１１は、ステップＳ１０１において、画像とメタデータを取得する。
ステップＳ１０２において、セグメントファイル生成部１２３は、sub-picture毎の情報として、projected pictureにおける表示領域情報を含むISOBMFFファイルを生成する。
ステップＳ１０３において、記録部１１４は、ステップＳ１０２の処理により生成されたISOBMFFファイルを記録する。
ステップＳ１０４において、アップロード部１１５は、ステップＳ１０３において記録されたISOBMFFファイルを記録部１１４より読み出し、それをサーバにアップロードする。
ステップＳ１０４の処理が終了すると、アップロード処理が終了する。
以上のようにアップロード処理を行うことにより、ファイル生成装置１００は、sub-picture毎の情報として、projected pictureにおける表示領域情報を含むISOBMFFファイルを生成することができる。
したがって、クライアントは、その情報に基づいて、ユーザの視野等に応じた適切なストリームをより容易に選択し、再生することができる。
＜ISOBMFFにシグナルされたsub-pictureの表示領域情報の利用＞
また、ISOBMFFファイルにシグナルされたsub-pictureの表示領域に関する情報を利用してストリームの選択や再生を行うようにしてもよい。
つまり、格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、そのサブピクチャが符号化された画像符号化データを含むファイルを取得し、その取得されたファイルに含まれるその領域に関する情報に基づいて、画像符号化データのストリームの選択を行うようにしてもよい。
例えば、情報処理装置であるクライアント装置２００において、セグメントファイル取得部２１４が、格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、そのサブピクチャが符号化された画像符号化データを含むファイルを取得するファイル取得部として機能し、データ解析・復号部２１６が、そのファイル取得部により取得されたファイルに含まれるその領域に関する情報に基づいて、画像符号化データのストリームの選択を行う画像処理部として機能するようにしてもよい。つまり、情報処理装置（例えばクライアント装置２００）が、ファイル取得部（例えばセグメントファイル取得部２１４）と、画像処理部（例えばデータ解析・復号部２１６）とを備えるようにしてもよい。
このようにすることにより、クライアント装置２００は、ストリームの選択をより容易に行うことができる。
なお、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、クライアント装置２００が、投影平面画像の全部、または一部を全体ピクチャとしてそれをsub-picture化したストリームを取得し、再生する場合においても、上述のように本技術を適用することができる。
また、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてISOBMFFファイルに含まれるようにしてもよい。このようにすることにより、クライアント装置２００は、sub-picture trackの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
＜コンテンツ再生処理の流れ＞
その場合のクライアント装置２００により実行されるコンテンツ再生処理の流れの例を、図１５のフローチャートを参照して説明する。
コンテンツ再生処理が開始されると、クライアント装置２００のセグメントファイル取得部２１４は、ステップＳ１２１において、sub-picture毎の情報としてprojected pictureにおける表示領域情報を含むISOBMFFファイルを取得する。
ステップＳ１２２において、表示制御部２１５は、ユーザの視点位置（および視線方向）の計測結果を取得する。
ステップＳ１２３において、計測部２１１は、サーバとクライアント装置２００との間のネットワークの伝送帯域幅を計測する。
ステップＳ１２４において、セグメントファイル処理部２２１は、クライアント装置２００のユーザの視野に相当する（対応する）sub-picture trackを、そのsub-pictureのprojected pictureにおける表示領域情報を基に選択する。
ステップＳ１２５において、セグメントファイル処理部２２１は、ステップＳ１２４において選択されたtrackのストリームの符号化データを、ステップＳ１２１において取得されたISOBMFFファイルから抽出する。
ステップＳ１２６において、デコード部２２２は、ステップＳ１２５において抽出されたストリームの符号化データを復号する。
ステップＳ１２７において、表示情報生成部２２３は、ステップＳ１２６において復号されて得られたストリーム（コンテンツ）を再生する。より具体的には、表示情報生成部２２３は、そのストリームから表示用画像のデータを生成し、それを表示部２１７に供給し、表示させる。
ステップＳ１２７の処理が終了すると、コンテンツ再生処理が終了する。
以上のようにコンテンツ再生処理を行うことにより、クライアント装置２００は、ISOBMFFファイルに含まれるsub-pictureの表示領域に関する情報を利用して、より容易にストリームを選択することができる。例えば、クライアント装置２００は、その情報に基づいて、ユーザの視野に応じた適切なストリームを容易に選択することができる。
＜2D Coverage Information Boxによる定義＞
上述のように、ファイル生成装置１００のセグメントファイル生成部１２３は、OMAFのISOBMFFファイルにおいて、sub-pictureがprojected pictureにおいてどの部分の表示に相当するかを示すsub-pictureの表示領域情報を新規定義し、trackにシグナルする。つまり、セグメントファイル生成部１２３は、sub-pictureの表示領域情報をサブピクチャ毎の情報として定義する。
例えば、セグメントファイル生成部１２３は、そのsub-pictureの表示領域情報として2D Coverage Information Boxを定義し、Region Wise Packing Boxと異なるBoxとしてシグナルする。例えば、セグメントファイル生成部１２３は、その2D Coverage Information Boxを、Scheme Information Boxに定義する。例えば、セグメントファイル生成部１２３が、その2D Coverage Information Boxを、Scheme Information Boxの下のProjected Omnidirectional Video Boxに定義するようにしてもよい。また、セグメントファイル生成部１２３が、その2D Coverage Information Boxを、その他のBoxに定義するようにしてもよい。
つまり、sub-pictureの表示領域情報（トラックに格納されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、Region Wise Packing Boxとは異なる、ISOBMFFファイルのScheme Information Box、または、そのScheme Information Boxの下階層のBoxに格納されるようにしてもよい。
このようにすることにより、クライアント装置２００は、Sub Picture Composition Boxをパースせずに、容易にsub-picture trackを選択し、再生することができる。
なお、この2D Coverage Information Box は、trackに格納されるピクチャ（picture）がsub-pictureでない場合や、Region Wise Packing Boxが存在しない場合（ピクチャがRegion Wise Packingされない場合）にも、表示領域情報のシグナルに使用可能である。
図１６のシンタックス３３１は、この2D Coverage Information Boxのシンタックスの例を示す。シンタックス３３１に示されるように、2D Coverage Information Boxにおいては、proj_picture_width、proj_picture_height、proj_reg_width、proj_reg_height、proj_reg_top、proj_reg_left等のフィールドがセットされる。
図１７のセマンティクス３３２は、この2D Coverage Information Boxにおいて定義されるフィールドのセマンティクスの例を示す。セマンティクス３３２に示されるように、proj_picture_widthは、projected pictureの幅を示す。proj_picture_heightは、projected pictureの高さを示す。proj_reg_widthは、trackのpictureが対応する、projected picture上における領域の幅を示す。proj_reg_heightは、trackのpictureが対応する、projected picture上における領域の高さを示す。proj_reg_topは、trackのpictureが対応する、projected picture上における領域の垂直方向座標を示す。proj_reg_leftは、trackのpictureが対応する、projected picture上における領域水平方向座標を示す。
つまり、図１８に示されるような各種情報が、2D Coverage Information Boxにおいて定義される。
なお、これらの各フィールドは、実際のピクセル数で示されるようにしてもよいし、proj_reg_width、proj_reg_height、proj_reg_top、およびproj_reg_leftが、proj_picture_widthおよびproj_picture_heightに対する相対値で示されるようにしてもよい。実際のピクセル数で示される場合、クライアントのディスプレイの解像度に応じてtrackを選択する場合に有用である。
クライアント装置２００は、このような構成のsub-picture trackの2D Coverage Information Boxを参照することで、Sub Picture Composition Boxをパースすることなくsub-picture trackの表示領域を容易に識別することができる。それによって、クライアント装置２００は、例えば、ユーザの視野に応じたsub-picture trackの選択をより容易に行うことができる。なお、sub-picture trackでないtrackについても、クライアント装置２００は、同様の処理により選択することができる。
また、図３のシンタックス２１に示すSub Picture Composition Boxにおいて、図７３のシンタックス１００１に示すようにidentical_to_proj_pic_flagフィールドを追加で定義し、全体ピクチャがprojected pictureに同一か否かを示し、全体ピクチャがprojected pictureに同一である場合において、図４のシンタックス２２に示すSub Picture Region Boxがsub-picture trackの表示領域情報を示す、としてもよい。identical_to_proj_pic_flagフィールドの値は、例えば０が全体ピクチャがprojected pictureと異なることを示し、１が全体ピクチャがprojected pictureと同一であることを示す。
このとき、identical_to_proj_pic_flagフィールドが1の場合において全体ピクチャはregion-wise packing処理がなされておらず、図５のセマンティクス２３に示すSub Picture Region Boxのtrack_x、track_y、track_width、track_height、composition_width、composition_heightフィールドのセマンティクスは、それぞれ図１７のセマンティクス３３２に示される2D Coverage Information Boxのproj_reg_left、proj_reg_top、proj_reg_width、proj_reg_height、proj_picture_width、proj_picture_heightフィールドのセマンティクスと同一となる。
なお、identical_to_proj_pic_flagフィールドはSub Picture Region Boxに追加で定義されてもよいし、その他のBoxで定義してもよい。また、特定のBoxの有無で、全体ピクチャがprojected pictureに同一か否かを示してもよい。
また、Sub Picture Composition Boxや、FullBoxを拡張したその他のBoxが共通に持つ２４bitのflagsの１bitを利用し、全体ピクチャがprojected pictureに同一か否かを示してもよい。
＜sub-pictureに不連続となる領域が含まれる場合＞
なお、図１６のシンタックス３３１では、図１９のようにsub-pictureがprojected picture上で不連続となる領域を含む場合には対応することができない。図１９の例の場合、projected picture３５１がsub-picture化されて、sub-picture３５２乃至sub-picture３５５が形成される。この場合、sub-picture３５２には、立体構造画像におけるLeft面およびRight面が含まれている（Left面およびRight面が隣接している）。このLeft面およびRight面は、projected picture３５１において不連続である。また、sub-picture３５３には、立体構造画像におけるTop面およびBottom面が含まれている（Top面およびBottom面が隣接している）。このTop面およびBottom面は、projected picture３５１において不連続である。
図１６のシンタックス３３１では、projected pictureの１つのまとまった領域しか指定することができないので、このような不連続な複数の領域を指定することができない。
そこで、2D Coverage Information Boxにおいて、複数の領域を指定することができるようにし、projected pictureにおける不連続な複数の領域を指定することができるようにしてもよい。
図２０のシンタックス３７１は、この場合の2D Coverage Information Boxのシンタックスの例を示す。シンタックス３７１に示されるように、この場合、num_regionsフィールドが、定義されるフィールドに追加される。図２１のセマンティクス３７２は、この場合の2D Coverage Information Boxにおいて追加されるフィールドのセマンティクスの例を示す。セマンティクス３７２に示されるように、num_regionsは、そのsub-pictureに含まれるprojected picture上の領域数を示す。
つまり、この場合、2D Coverage Information Boxにおいて、num_regionsフィールドを用いて、projected pictureの領域毎に（互いに独立して）、図１７に示される各フィールドを定義するようにしている。したがって、projected pictureの複数の領域を指定することができる。これにより、projected pictureの不連続な表示領域のシグナルが可能となる。
なお、2D Coverage Information BoxがSub Picture Composition Boxにシグナルされた場合、全体ピクチャ（projected picture）における表示領域をシグナルするようにしてもよい。
また、2D Coverage Information BoxがtrackのProjected Omnidirectional Video Boxに存在しなければ、そのtrackが360°全天球の映像を格納していることを示すものとしてもよい。同様に、2D Coverage Information BoxがSub Picture Composition Boxに存在しなければ、sub-picture trackが構成する全体ピクチャは360°全天球の映像であることを示すものとしてもよい。
＜Region Wise Packing Boxの拡張＞
OMAFで規定されているRegion Wise Packing Box内のRegion Wise Packing Structを拡張し、trackのsub-pictureが、projected pictureのどの部分の表示領域に相当するかをシグナルするようにしてもよい。Region Wise Packing Boxのシグナル場所は、sub-picture trackのSample EntryのProjected Omnidirectional Video Box下である。なお、このRegion Wise Packing Boxが、その他の場所にシグナルされるようにしてもよい。
例えば、新たにsub-pictureの表示領域情報をシグナルすることを示すフラグと、sub-pictureの表示領域情報をシグナルするRect Projected Region構造を定義し、Region Wise Packing Structでシグナルする。なお、このRegion Wise Packing Structは、trackに格納されるpictureがsub-pictureでない場合にも、この表示領域情報のシグナルに使用可能である。
図２２のシンタックス３７３は、その場合のRegion Wise Packing Structのシンタックスの例を示す。シンタックス３７３に示されるように、この場合、2D_coverage_flagフィールドが、Region Wise Packing Structにおいて定義されるフィールドに追加される。図２３のセマンティクス３７４は、この場合のRegion Wise Packing Structにおいて追加的に定義されるフィールドのセマンティクスの例を示す。セマンティクス３７４に示されるように、2D_coverage_flagは、projected picture上での表示領域のみをシグナルするか否かを示すフラグ情報である。例えば、このフィールドの値が０の場合、region-wise packing情報をシグナルすることを示す。また、このフィールドの値が１の場合、projected picture上での表示領域をシグナルすることを示す。
なお、この場合のRegion Wise Packing Structにおいては、さらに、RectProjetedRegionが定義される。図２４のシンタックス３７５は、そのRectProjetedRegionのシンタックスの例を示す。シンタックス３７５に示されるように、このRectProjetedRegionにおいては、proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]、proj_reg_left[i]等のフィールドが定義される。
図２５のセマンティクス３７６は、このRectProjetedRegionにおいて定義されるフィールドのセマンティクスの例を示す。セマンティクス３７６に示されるように、proj_reg_widthは、trackのpictureが対応する、projected picture上における領域の幅を示す。proj_reg_heightは、trackのpictureが対応する、projected picture上における領域の高さを示す。proj_reg_topは、trackのpictureが対応する、projected picture上における領域の垂直方向座標を示す。proj_reg_leftは、trackのpictureが対応する、projected picture上における領域水平方向座標を示す。
なお、上記各フィールドは、実際のピクセル数で示されるようにしてもよいし、proj_reg_width, proj_reg_height, proj_reg_topおよびproj_reg_leftがRegion Wise Packing Structでシグナルされるproj_picture_widthおよびproj_picture_heightに対する相対値で示されるようにしてもよい。
また、Rect Wise Packing Structを拡張し、2D_coverage_flag==1のときにprojected pictureにおける表示領域情報のみをシグナルするようにしてもよい。
図２６のシンタックス３７７は、その場合のRect Wise Packing Structのシンタックスの例を示す。図２７のシンタックス３７８は、この場合のRect Wise Packing StructにおいてセットされるRectRegionPackingのシンタックスの例を示す図である。
＜Coverage Information Boxの拡張＞
OMAFで定義されたtrackの球面上における表示領域を示すCoverage Information Boxを拡張し、新たに定義する2D Content Coverage Structによりprojected picture上における表示領域をシグナル可能にするようにしてもよい。
つまり、sub-pictureの表示領域情報（トラックに格納されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、ISOBMFFファイルの、トラックの球面上における表示領域を示すCoverage Information Boxに格納されるようにしてもよい。
図２８のシンタックス３７９は、拡張したCoverage Information Boxのシンタックスの例を示す。シンタックス３７９に示されるように、この場合のCoverage Information Boxにおいて、2D_coverage_flag、ContentCoverageStruct()、2DContentCoverageStruct()が定義される。
図２９のセマンティクス３８０は、これらのフィールドのセマンティクスの例を示す。セマンティクス３８０に示されるように、2D_coverage_flagは、表示領域情報のタイプをシグナルするフラグ情報である。この値が０の場合、球面上表示領域情報をシグナルすることを示し、この値が１の場合、projected picture上での表示領域をシグナルすることを示す。ContentCoverageStruct()は、trackの球面上表示領域をシグナルする。2DContentCoverageStruct()は、trackのprojected picture上での表示領域をシグナルする。2D Content Coverage Struct内のフィールドは、図２０の場合の2D Coverage Information Boxと同様である。
なお、Content Coverage Structを拡張し、球面上表示領域の他に、projected picture上での表示領域をシグナルするようにしてもよい。
＜sub-pictureの分割方法が動的に変化する場合のシグナリング＞
以上においては、sub-pictureの分割方法がストリーム中で動的に変化しない場合のシグナリングについて説明した。これに対して、分割方法が動的に変化する場合、projected pictureにおけるsub-pictureの表示領域情報がストリーム中で動的に変化する。その場合、上述の例では対応することができない。
そこで、sub-pictureの動的に変化する表示領域情報をシグナルするための追加シグナリング例を以下に説明する。なお、シグナルされる情報は、上述の2D Coverage Information Boxでシグナルされる情報（例えば、図１６等）と同一である。
＜Supplemental Enhancement Information (SEI) message＞
HEVC、AVCにおいて、2D Coverage Information SEI messageを新規定義し、その中において、ストリーム中で動的に変化するsub-pictureの表示領域情報をアクセスユニット単位でシグナルするようにしてもよい。
つまり、sub-pictureの表示領域情報（トラックに格納されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、ISOBMFFファイルのSupplemental Enhancement information messageに格納されるようにしてもよい。
図３０のシンタックス３８１は、その場合の2D Coverage Information SEI messageのシンタックスの例を示す。シンタックス３８１に示されるように、2D Coverage Information SEI messageにおいては、2D_coverage_information_cancel_flag、2D_coverage_information_persistence_flag、2D_coverage_information reserved_zero_6bits、proj_picture_width、proj_picture_height、num_regions、proj_reg_width[i]、proj_reg_height[i]、proj_reg_top[i]、proj_reg_left[i]等がセットされる。
図３１のセマンティクス３８２は、その2D Coverage Information SEI messageにおいて定義されるフィールドのセマンティクスの例を示す。セマンティクス３８２に示されるように、2D_coverage_information_cancel_flagは、2D_coverage_informationのキャンセルに関するフラグ情報である。この値が１の場合、出力順で先行するSEIの持続的適用がキャンセルされる。また、この値が０の場合、2D coverage情報がシグナルされる。
2D_coverage_information_persitence_flagは、SEIの適用範囲に関するフラグ情報である。この値が０の場合、SEIが含まれるピクチャのみに、SEIの情報が適用される。また、この値が１の場合、SEIの適用は、新たなcoded video sequenceが開始されるか、ストリームの末尾に到達するかまで持続する。
2D_coverage_information_reserved_zero_6bitsは、0で埋められる。proj_picture_widthは、projected pictureの幅を示す。proj_picture_heightは、projected pictureの高さを示す。num_regionsは、projected picture上の領域数を示す。proj_reg_widthは、ストリームが対応する、projected picture上における領域の幅を示す。proj_reg_heightは、ストリームが対応する、projected picture上における領域の高さを示す。proj_reg_topは、ストリームが対応する、projected picture上における領域の垂直方向座標を示す。proj_reg_leftは、ストリームが対応する、projected picture上における領域水平方向座標を示す。
なお、上記各フィールドは、実際のピクセル数で示されるようにしてもよいし、proj_reg_width, proj_reg_height, proj_reg_topおよびproj_reg_leftがproj_picture_widthおよびproj_picture_heightに対する相対値で示されるようにしてもよい。
＜Timed metadata＞
また、時系列で変化するメタデータを格納するストリームであるtimed metadataの仕組みを利用し、2D Coverage Information timed metadataを新規定義し、その中において、参照するストリーム内で動的に変化するsub-pictureの表示領域情報をシグナルするようにしてもよい。2D Coverage Information timed metadataが紐づくtrackに対するtrack reference typeとしては、例えば'2dco'を用いる。
つまり、sub-pictureの表示領域情報（トラックに格納されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、ISOBMFFファイルのtimed metadataに格納されるようにしてもよい。
timed metadataを使用することで、クライアントはsub-pictureストリームをデコードせずとも、動的に変わる表示領域を事前に識別し、どのストリームを選択するかの基準とすることができる。
図３２のシンタックス３８３は、2D Coverage Information Sample Entryのシンタックスの例を示す。図３３のシンタックス３８４は、2D Coverage Information Sampleのシンタックスの例を示す。
2D Coverage Information Sample Entryには、一般的にストリーム中で不変となるproj_picture_width, proj_picture_heightがシグナルされる。なお、これらがストリーム中で変化する場合には、2DCoverageInformationSample内においてシグナルされるようにしてもよい。
なお、2D Coverage Information Sample Entryおよび2D Coverage Information Sample内の各フィールド（field）のセマンティクスは、図１７および図２１と同様である。
＜Sample Group＞
ISOBMFFで定義される、sample単位でメタ情報を紐づける仕組みであるSample Groupというツールを使用して、ストリーム内で動的に変化するsub-pictureの表示領域情報を、sample単位でシグナルするようにしてもよい。
メタ情報が記述されるSample Groupは、図３４に示されるように、サンプルテーブルボックス（Sample Table Box）のサンプルグループディスクリプションボックス（Sample Group Description Box）にグループエントリ（Group Entry）としてシグナルされ、サンプルトゥグループボックス（Sample To Group Box）を介して、sampleと紐づけられる。
図３４に示されるように、Sample To Group Boxのグルーピングタイプ（grouping_type）は、紐づけられるSample Group Description Boxのgrouping_typeを示す。１エントリ（1 entry）につき、サンプルカウント（sample_count）とグループディスクリプションインデックス（group_description_index）がシグナルされ、そのgroup_description_indexは、紐づくグループエントリ（Group Entry）のインデックス（index）を示し、sample_countはそのGroup Entryに属するサンプル（sample）の数を示す。
例えば、新たに2D Coverage Information Sample Group Entryを定義し、ストリーム内で動的に変化するsub-pictureの表示領域情報を、その中に格納するようにしてもよい。
つまり、sub-pictureの表示領域情報（トラックに格納されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、ISOBMFFファイルのSample Group Entryに格納されるようにしてもよい。
図３５のシンタックス３９１は、その2D Coverage Information Sample Group Entryのシンタックスの例を示す。このSample Group Entryは、上述したように、Sample Group Description Boxにシグナルされ、Sample To Group Boxによって、sampleとSample Group Entryが紐づけられる。grouping_typeは'2cgp'となる。
なお、この2D Coverage Information Sample Group Entry内の各フィールドのセマンティクスは、図１６および図２１と同様である。
なお、上述した３つの例（Supplemental Enhancement Information (SEI) message、Timed metadata、Sample Group）は、trackに格納されるpictureがsub-pictureでない場合においても、動的に変化する表示領域情報のシグナルに使用することができる。
また、以上のようにsub-pictureのprojected picture上における表示領域が動的に変化する場合、Projected Omnidirectional Video Boxにシグナルされる2D Coverage Information Boxの情報は、ストリームの表示領域の初期値とすることができる。
また、ストリーム中でsub-pictureのprojected pictureにおける表示領域が動的に変化することを示すフラグを2D Coverage Information Box、またはその他のBox内でシグナルするようにしてもよい。この情報により、クライアントは、容易に、動的に表示領域が変化するストリームであることを識別することができる。
＜３．第２の実施の形態＞
＜MPDファイルによるsub-pictureの表示領域に関する情報のシグナル＞
上述したsub-pictureの表示領域に関する情報のシグナルを、MPDファイルにおいて行うようにしてもよい。つまり、クライアントが、sub-pictureを参照するAdaptation Setを例えばユーザの視野に応じて選択・再生することを可能にするために、MPDファイルにおいて、sub-pictureのprojected picture上における表示領域情報を新規定義し、Adaptation Setにシグナルするようにしてもよい。
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、そのサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、画像符号化データの配信制御に用いられる制御ファイルを生成するようにしてもよい。
例えば、情報処理装置であるファイル生成装置１００において、MPDファイル生成部１１３が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、そのサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、画像符号化データの配信制御に用いられる制御ファイルを生成するファイル生成部として機能するようにしてもよい。つまり情報処理装置（例えばファイル生成装置１００）が、ファイル生成部（例えばMPDファイル生成部１１３）を備えるようにしてもよい。
このようにすることにより、上述したように、クライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
なお、MPDファイルにおいては、ストリーム毎のメタデータはアダプテーションセット（Adaptation Set）やリプレゼンテーション（Representation）として管理される。つまり、MPDファイルを用いる場合、アダプテーションセット（Adaptation Set）やリプレゼンテーション（Representation）を選択することにより、ストリームの選択が行われる。
また、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、ファイル生成装置１００が、このような投影平面画像の全部、または一部を全体ピクチャとし、それをsub-picture化する場合において、上述のように本技術を適用することができる。
このようにすることにより、全天球映像を配信する場合においても、上述したようにクライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
なお、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてMPDファイルに含まれるようにしてもよい。このようにすることにより、クライアントは、Adaptation Setが参照するsub-pictureの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
＜アップロード処理の流れ＞
その場合の図１１のファイル生成装置１００により実行されるアップロード処理の流れの例を、図３６のフローチャートを参照して説明する。
アップロード処理が開始されると、ファイル生成装置１００のデータ入力部１１１は、ステップＳ２０１において、画像とメタデータを取得する。
ステップＳ２０２において、セグメントファイル生成部１２３は、その画像のセグメントファイルを生成する。
ステップＳ２０３において、MPDファイル生成部１１３は、sub-picture毎の情報として、projected pictureにおける表示領域情報を含むMPDファイルを生成する。
ステップＳ２０４において、記録部１１４は、ステップＳ２０２の処理により生成されたセグメントファイルを記録する。また、記録部１１４は、ステップＳ２０３の処理により生成されたMPDファイルを記録する。
ステップＳ２０５において、アップロード部１１５は、ステップＳ２０４において記録されたセグメントファイルを記録部１１４より読み出し、それをサーバにアップロードする。また、アップロード部１１５は、ステップＳ２０４において記録されたMPDファイルを記録部１１４より読み出し、それをサーバにアップロードする。
ステップＳ２０４の処理が終了すると、アップロード処理が終了する。
以上のようにアップロード処理を行うことにより、ファイル生成装置１００は、sub-picture毎の情報として、projected pictureにおける表示領域情報を含むMPDファイルを生成することができる。
したがって、クライアントは、その表示領域情報に基づいて、例えばユーザの視野に応じた適切なストリームをより容易に選択し、再生することができる。
＜MPDファイルにシグナルされたsub-pictureの表示領域に関する情報の利用＞
また、MPDファイルにシグナルされたsub-pictureの表示領域に関する情報を利用してストリームの選択を行うようにしてもよい。
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、そのサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、画像符号化データの配信制御に用いられる制御ファイルを取得し、その取得された制御ファイルに含まれるその領域に関する情報に基づいて、画像符号化データのストリームの選択を行うようにしてもよい。
例えば、情報処理装置であるクライアント装置２００において、MPDファイル取得部２１２が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、そのサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、画像符号化データの配信制御に用いられる制御ファイルを取得するファイル取得部として機能し、MPDファイル処理部２１３が、そのファイル取得部により取得された制御ファイルに含まれるその領域に関する情報に基づいて、画像符号化データのストリームの選択を行う画像処理部として機能するようにしてもよい。つまり、情報処理装置（例えばクライアント装置２００）が、ファイル取得部（例えばMPDファイル取得部２１２）と、画像処理部（例えばMPDファイル処理部２１３）とを備えるようにしてもよい。
このようにすることにより、クライアント装置２００は、ストリームの選択をより容易に行うことができる。
なお、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、クライアント装置２００が、投影平面画像の全部、または一部を全体ピクチャとしてそれをsub-picture化したストリームを取得し、再生する場合においても、上述のように本技術を適用することができる。
また、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてMPDファイルに含まれるようにしてもよい。このようにすることにより、クライアント装置２００は、Adaptation Setが参照するsub-pictureの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
＜コンテンツ再生処理の流れ＞
その場合のクライアント装置２００により実行されるコンテンツ再生処理の流れの例を、図３７のフローチャートを参照して説明する。
コンテンツ再生処理が開始されると、クライアント装置２００のMPDファイル取得部２１２は、ステップＳ２２１において、sub-picture毎の情報としてprojected pictureにおける表示領域情報を含むMPDファイルを取得する。
ステップＳ２２２において、表示制御部２１５は、ユーザの視点位置（および視線方向）の計測結果を取得する。
ステップＳ２２３において、計測部２１１は、サーバとクライアント装置２００との間のネットワークの伝送帯域幅を計測する。
ステップＳ２２４において、MPDファイル処理部２１３は、クライアント装置２００のユーザの視野に相当する（対応する）sub-pictureを参照するAdaptation Setを、そのsub-pictureのprojected pictureにおける表示領域情報を基に選択する。
ステップＳ２２５において、MPDファイル処理部２１３は、ステップＳ２２４において選択されたAdaptation Setの中から、ユーザの視点位置および視線方向やクライアントとサーバとの間のネットワークの伝送帯域幅等に応じたリプレゼンテーション（Representation）を選択する。
ステップＳ２２６において、セグメントファイル取得部２１４は、ステップＳ２２５において選択されたリプレゼンテーション（Representation）に対応するセグメントファイルを取得する。
ステップＳ２２７において、セグメントファイル処理部２２１は、ステップＳ２２６において取得されたセグメントファイルから符号化データを抽出する。
ステップＳ２２８において、デコード部２２２は、ステップＳ２２７において抽出されたストリームの符号化データを復号する。
ステップＳ２２９において、表示情報生成部２２３は、ステップＳ２２８において復号されて得られたストリーム（コンテンツ）を再生する。より具体的には、表示情報生成部２２３は、そのストリームから表示用画像のデータを生成し、それを表示部２１７に供給し、表示させる。
ステップＳ２２９の処理が終了すると、コンテンツ再生処理が終了する。
以上のようにコンテンツ再生処理を行うことにより、クライアント装置２００は、MPDファイルに含まれるsub-pictureの表示領域に関する情報を利用して、より容易にストリームを選択することができる。例えば、クライアント装置２００は、その情報に基づいて、ユーザの視野に応じた適切なストリームを容易に選択することができる。
＜2D Coverage Information descriptorによる定義＞
上述のように、ファイル生成装置１００のMPDファイル生成部１１３は、OMAFのMPDファイルにおいて、Adaptation setが参照するsub-pictureがprojected pictureにおいてどの部分の表示に相当するかを示すsub-pictureの表示領域情報を新規定義し、シグナルする。つまり、MPDファイル生成部１１３は、sub-pictureの表示領域情報をサブピクチャ毎の情報として定義する。
例えば、MPDファイル生成部１１３は、そのsub-pictureの表示領域情報として2D Coverage Information descriptorを定義し、Region wise packing descriptorと異なるdescriptorとしてシグナルする。例えば、MPDファイル生成部１１３は、@schemeIdUri="urn:mpeg:mpegI:omaf:2017:2dco"のSupplemental Propertyを2D coverage information descriptorとして定義する。なお、MPDファイル生成部１１３が、同じschemeIdUriのEssential Propertyを用いて2D coverage information descriptorを定義するようにしてもよい。
つまり、サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、sub-pictureの表示領域情報（アダプテーションセットにより参照されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、MPDファイルのSupplemental PropertyまたはEssential Propertyに定義されるようにしてもよい。
なお、EssentialPropertyのschemeIdUriに対応していないDASHクライアントは、このPropertyの書かれているAdaptation Set（Representation等でもよい）は無視しなければならない。また、SupplementalPropertyのschemeIdUriに対応していないDASHクライアントは、このProperty値を無視して、AdaptationSet（Representation等でもよい）を利用してもよい。
なお、この2D Coverage Information descriptorは、Adaptation Set以外に、MPDやRepresentationに存在するようにしてもよい。また、この2D Coverage Information descriptorは、Adaptation Setが参照するpictureがsub-pictureでなくても、または、region-wise packing処理がなされていなくても、適用可能である。
図３８の属性値４１１は、この2D coverage information descriptorの属性値の例を示す。属性値４１１に示されるように、omaf:@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。omaf:@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。omaf:@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。omaf:@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。omaf:@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。omaf:@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標を示す。
上記各属性値は、実際のピクセル数で示されるようにしてもよいし、omaf:@proj_reg_width, omaf:@proj_reg_height, omaf:@proj_reg_topおよびomaf:@proj_reg_leftがomaf:@proj_picture_widthおよびomaf:@proj_picture_heightに対する相対値で示されるようにしてもよい。
また、全体ピクチャがprojected pictureに同一であることを示す情報を、MPDファイルのSupplemental PropertyまたはEssential Propertyに定義されるようにしてもよい。例えば、MPDファイル生成部１１３は、図７４に示す@schemeIdUri="urn:mpeg:mpegI:omaf:2017:prid"のSupplemental PropertyをProjected picture identical descriptorとして定義する。例えばこのdescriptorがAdaptationSetに存在する場合、AdaptationSetが参照するsub-pictureから構成される全体ピクチャはregion-wise packing処理がなされておらず、projected pictureと同一であることを示す。
このとき、Projected picture identical descriptorが存在するAdaptationSetが参照するsub-pictureの表示領域を、例えば、全体ピクチャを２以上の領域に分割して独立して符号化したときの各領域の表示領域を示すMPEG-DASH SRD（Spatial Relationship Description）で示してもよい。図示はしないが、SRDでは、図４のシンタックス２２に示すSub Picture Region Boxと同様に、sub-pictureの分割の仕方等を示すsub-picture分割情報が示される。
このとき、Projected picture identical descriptorが存在するAdaptationSetにおいて、図示はしないが、SRDの属性値であるobject_x、object_y、object_width、object_height、total_width、total_heightのセマンティクスは、それぞれ図３８の属性値４４１に示される2D coverage information descriptorの属性値であるomaf:@proj_reg_left、omaf:@proj_reg_top、omaf:@proj_reg_width、omaf:@proj_reg_height、omaf:@proj_picture_width、omaf:@proj_picture_heightのセマンティクスと同一となる。
なお、このProjected picture identical descriptorは、Adaptation Set以外に、MPDやRepresentationに存在するようにしてもよいし、全体ピクチャがprojected pictureに同一であることを示す情報をその他のdescriptor、要素、属性によって定義されるようにしてもよい。
＜sub-pictureに不連続となる領域が含まれる場合＞
なお、上記の例では、sub-pictureがprojected picture上で不連続となる領域を含む場合の表示領域情報をシグナルできない。そこで、2D Coverage Information descriptorが、sub-pictureがprojected picture上で不連続となる領域を含む場合にも対応することができるようにしてもよい。
図３９の属性値４１２は、その場合の2D Coverage Information descriptorの属性値の例を示す。属性値４１２に示されるように、twoDCoverageは、データタイプがomaf:twoDCoverageTypeのコンテナ要素である。twoDCoverage@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。twoDCoverage@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。
twoDCoverage.twoDCoverageInfoは、データタイプが、omaf:twoDCoverageInfoTypeであり、projected picture上における領域情報を示す要素を示す。この属性値は、複数シグナルすることができる。twoDCoverage.twoDCoverageInfo@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。twoDCoverage.twoDCoverageInfo@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。
twoDCoverage.twoDCoverageInfo@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。twoDCoverage.twoDCoverageInfo@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標を示す。
図４０のデータタイプ４１３は、この2D Coverage Information descriptorのデータタイプの定義の例を示す。
以上のように、projected picture上の複数領域をシグナル可能にすることで、projected picture上で不連続な表示領域のシグナルが可能となる。
＜Region-wise packing descriptorの拡張＞
OMAFで定義されているRegion-wise packing descriptorを拡張し、Adaptation Setが参照するsub-pictureの、projected picture上における表示領域情報をシグナルするようにしてもよい。
図４１の属性値４１４は、図３８の属性値４１１のシグナルをもとに拡張したRegion-wise packing descriptorの属性値の例を示す。データタイプは、図４０と同様である。
属性値４１４に示されるように、omaf: @packing_typeは、データタイプがomaf:OptionallistofUnsignedByteであり、region-wise packingのパッキングタイプを示す。この属性値が０の場合、矩形領域のパッキングであることを示す。
omaf:@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。omaf:@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。omaf:@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。omaf:@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。
omaf:@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。omaf:@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標である。
上記各属性値は、実際のピクセル数で示されるようにしてもよいし、omaf:@proj_reg_width, omaf:@proj_reg_height, omaf:@proj_reg_topおよびomaf:@proj_reg_leftがomaf:@proj_picture_widthおよびomaf:@proj_picture_heightに対する相対値で示されるようにしてもよい。
図４２の属性値４１５は、図３９の属性値４１２のシグナルをもとに拡張したRegion-wise packing descriptorの属性値、すなわち、不連続な領域を含む場合に対応したRegion-wise packing descriptorの属性値の例を示す。データタイプは、図４０と同様である。
属性値４１５に示されるように、omaf: @packing_typeは、データタイプがomaf:OptionallistofUnsignedByteであり、region-wise packingのパッキングタイプを示す。この属性値が０の場合、矩形領域のパッキングであることを示す。
twoDCoverageは、データタイプがomaf:twoDCoverageTypeであるコンテナ要素である。twoDCoverage@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。twoDCoverage@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。twoDCoverage.twoDCoverageInfoは、データタイプがomaf:twoDCoverageInfoTypeであり、projected picture上における領域情報を示す要素を示す。この属性値は、複数シグナルすることができる。
twoDCoverage.twoDCoverageInfo@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。twoDCoverage.twoDCoverageInfo@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。
twoDCoverage.twoDCoverageInfo@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。twoDCoverage.twoDCoverageInfo@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標を示す。
＜Content coverage descriptorの拡張＞
また、OMAFで定義された、Adaptation Setの球面上における表示領域を示すContent coverage descriptorを拡張し、projected picture上における表示領域をシグナル可能にするようにしてもよい。
つまり、サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、sub-pictureの表示領域情報（アダプテーションセットに参照されるサブピクチャに対応するピクチャ全体における領域に関する情報）は、MPDファイルの、Adaptation Setの球面上における表示領域を示すCoverage Information descriptorにおいて定義されるようにしてもよい。
図４３の属性値４１６および図４４の属性値４１７は、拡張したContent coverage descriptorの属性値の例を示す。Content coverage descriptorを拡張する場合、上述したISOBMFFファイルにおいてContent coverage Boxを拡張する場合と同様に、2D_coverage_flag属性によって、球面上領域をシグナルするか、projected picture上における表示領域をシグナルするかの切り替えを行う。
属性値４１６に示されるように、ccは、データタイプがomaf:CCTypeであるコンテナ要素である。cc@2D_coverage_flagは、データタイプがxs:booleanであり、表示領域が球面上で定義されるか、projected picture上で定義されるか、を示すフラグ情報である。この属性値が０の場合、球面上で定義されることを示し、この値が１の場合、projected picture上で定義されることを示す。
cc.sphericalCoverageは、データタイプがomaf:sphericalCoverageTypeである、球面上表示領域情報のコンテナ要素である。この要素は、cc@2D_coverage_flag=0のときのみ存在する。cc.sphericalCoverage @shape_typeは、データタイプがxs:unsignedByteであり、球面上領域の形状を示す。この属性値が０の場合、4 great circlesで囲まれる領域であることを示す。また、この属性値が１の場合、２つのazimuth circleと２つのelevation angleで囲まれる領域であることを示す。
cc.sphericalCoverage @view_idc_presence_flagは、データタイプがxs:booleanであり、view_idc属性が存在するか否かを示すフラグ情報である。この属性値が０の場合、view_idc属性が存在しないことを示し、この属性値が１の場合、view_idc属性が存在することを示す。
cc.sphericalCoverage @default_view_idcは、データタイプがomaf:ViewTypeであり、領域全てに共通なviewを示す。例えば、この属性値が０の場合、sub-pictureに含まれるすべての領域のビュータイプ（view_idc）がモノビュー（mono view）であることを示す。また、この属性値が１の場合、sub-pictureに含まれるすべての領域のビュータイプ（view_idc）がレフトビュー（left view）であることを示す。また、この属性値が２の場合、sub-pictureに含まれるすべての領域のビュータイプ（view_idc）がライトビュー（right view）であることを示す。また、この属性値が３の場合、sub-pictureに含まれるすべての領域のビュータイプ（view_idc）がステレオビュー（stereo view）であることを示す。この属性値は、cc@view_idc_presence_flag=0のとき、必ず存在する。また、cc@view_idc_presence_flag=1のとき、この属性は存在してはいけない。
cc.sphericalCoverage.coverageInfoは、データタイプがomaf:coverageInfoTypeであり、球面上領域情報を示す要素である。この要素は、複数シグナルすることができる。
cc.sphericalCoverage.coverageInfo@view_idcは、データタイプがomaf:ViewTypeであり、領域毎のviewを示す。例えば、この属性値が０の場合、その属性値が対応する領域のビュータイプ（view_idc）がモノビュー（mono view）であることを示す。また、この属性値が１の場合、その属性値が対応する領域のビュータイプ（view_idc）がレフトビュー（left view）であることを示す。また、この属性値が２の場合、その属性値が対応する領域のビュータイプ（view_idc）がライトビュー（right view）であることを示す。また、この属性値が３の場合、その属性値が対応する領域のビュータイプ（view_idc）がステレオビュー（stereo view）であることを示す。この属性値は、cc@view_idc_presence_flag=0のとき、存在してはいけない。また、cc@view_idc_presence_flag=1のとき、この属性は必ず存在する。
cc.sphericalCoverage.coverageInfo@center_azimuthは、データタイプがomaf:Range1であり、球面上表示領域中心の方位角を示す。cc.sphericalCoverage.coverageInfo@center_elevationは、データタイプがomaf:Range2であり、球面上表示領域中心の仰角を示す。cc.sphericalCoverage.coverageInfo@center_tiltは、データタイプがomaf:Range1であり、球面上表示領域中心のチルト角を示す。cc.sphericalCoverage.coverageInfo@azimuth_rangeは、データタイプがomaf:HRangeであり、球面上表示領域の方位角レンジを示す。cc.sphericalCoverage.coverageInfo@elevation_rangeは、データタイプがomaf:VRangeであり、球面上表示領域の仰角レンジを示す。
cc.twoDCoverageは、データタイプがomaf:twoDCoverageTypeであるprojected picture上における表示領域情報のコンテナ要素である。cc@2D_coverage_flag=1のときのみ存在する。
cc.twoDCoverage@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。cc.twoDCoverage@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。cc.twoDCoverage.twoDCoverageInfoは、データタイプがomaf:twoDCoverageInfoTypeであり、projected picture上における領域情報を示す要素である。この要素は、複数シグナルすることができる。
cc.twoDCoverage.twoDCoverageInfo@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。cc.twoDCoverage.twoDCoverageInfo@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。
cc.twoDCoverage.twoDCoverageInfo@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。cc.twoDCoverage.twoDCoverageInfo@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標を示す。
図４５のデータタイプ４１８、図４６のデータタイプ４１９、および図４７のデータタイプ４２０は、この拡張したContent coverage descriptorのデータタイプの定義の例を示す。
＜sub-pictureの分割方法が動的に変化する場合のシグナリング＞
なお、ストリーム中でprojected pictureにおける表示領域が動的に変化する場合、上述のシグナリングに加え、2D coverage information descriptor, region-wise packing descriptorおよびContent coverage descriptorに追加でフラグをシグナルし、projected pictureにおける表示領域が動的に変化するストリームであることを示すようにしてもよい。
＜４．第３の実施の形態＞
＜ステレオ情報のシグナル＞
＜１．sub-pictureに関する情報のシグナル＞の＜ステレオ情報の識別＞において上述したように、ステレオ全天球映像の全体ピクチャをsub-picture化した場合、全体ピクチャのステレオ情報はSub Picture Composition Box下にシグナルされるStereo Video Boxでシグナルされ、sub-pictureのステレオ情報はSample EntryのScheme Information Box下のStereo Video Boxでシグナルされる。
全体ピクチャがステレオ画像である場合、生成可能なsub-pictureのバリエーションとして例えば以下の３パターンがある。
図４８は、sub-picture化の第１のパターンの様子の例を示す図である。この場合、projected picture（全体ピクチャ）４３１がsub-picture化されて、sub-picture４３２乃至sub-picture４３７が生成される。projected picture４３１は、サイドバイサイド（side by side）のステレオ画像により構成される。sub-picture４３２乃至sub-picture４３７は、それぞれ、projected picture４３１上で同一の表示領域となるLeft viewとRight viewを含み、top & bottomやside by sideといったStereo Video Boxでシグナル可能なフレームパッキングアレンジメントとなっている。
図４９は、sub-picture化の第２のパターンの様子の例を示す図である。この場合、projected picture（全体ピクチャ）４４１がsub-picture化されて、sub-picture４４２乃至sub-picture４４６が生成される。projected picture４４１は、サイドバイサイド（side by side）のステレオ画像により構成される。sub-picture４４２乃至sub-picture４４６は、それぞれ、Left viewおよびRight viewを含むが、各viewのprojected picture４４１上の表示領域が一致せず、top & bottomやside by sideといったStereo Video Boxでシグナル可能なフレームパッキングアレンジメントとならない。
図５０は、sub-picture化の第３のパターンの様子の例を示す図である。この場合、projected picture（全体ピクチャ）４５１がsub-picture化されて、sub-picture４５２およびsub-picture４５３が生成される。projected picture４５１は、サイドバイサイド（side by side）のステレオ画像により構成される。sub-picture４５２は、Left viewのみを含むモノピクチャとなっている。sub-picture４５３は、Right viewのみを含むモノピクチャとなっている。
第１のパタンーンの場合、sub-picture trackのSample Entry/rinf/schiにStereo Video Boxがシグナルされ、適切なフレームパッキングアレンジメント情報がシグナルされる。例えば図４８の場合、side by sideとなる。なお、sub-pictureのフレームパッキングアレンジメント情報ではなく、全体ピクチャのフレームパッキングアレンジメント情報がシグナルされてもよい。
第２のパターンの場合、Sample Entry/rinf/schiにはStereo Video Boxがシグナルされない。したがって、クライアントは、sub-pictureがモノピクチャなのか、Left viewおよびRight viewを含んでいるがtop & bottomやside by sideといったフレームパッキングアレンジメントが適用されていないのかを識別することができないおそれがあった。
第３のパターンの場合、Sample Entry/rinf/schiにはStereo Video Boxがシグナルされない。したがって、クライアントは、分割前の全体ピクチャがモノピクチャであるのかステレオ画像であるのかを識別することができないおそれがあった。レンダリング時のアップスケール（upscale）が必要であるか否かは、分割前の全体ピクチャがモノピクチャであるのかステレオ画像であるのかによって異なるため、その識別ができないと、クライアントが適切にレンダリングすることができないおそれがあった。
例えば、図５０のように、全体ピクチャがside by sideのステレオ画像であり、そのうちのLeft viewのみを持つsub-pictureについては、レンダリングの際、水平方向に２倍のupscaleが必要である。これに対して、全体ピクチャがモノピクチャである場合、この処理は不要である。
＜ISOBMFFによるsub-picture化される全体ピクチャのステレオ情報のシグナル＞
そこで、sub-picture化されるピクチャ全体のステレオ表示に関する情報であるステレオ情報を、セグメントファイルであるISOBMFFファイルにおいて行うようにしてもよい。
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、そのピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを生成するようにしてもよい。
例えば、情報処理装置であるファイル生成装置１００において、セグメントファイル生成部１２３が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、そのピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを生成するファイル生成部として機能するようにしてもよい。つまり情報処理装置（例えばファイル生成装置１００）が、ファイル生成部（例えばセグメントファイル生成部１２３）を備えるようにしてもよい。
このようにすることにより、上述したように、クライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
また、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、ファイル生成装置１００が、投影平面画像の全部、または一部を全体ピクチャとし、それをsub-picture化する場合において、上述のように本技術を適用することができる。
このようにすることにより、全天球映像を配信する場合においても、上述したようにクライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
なお、この全体ピクチャのステレオ情報は、サブピクチャ（sub-picture）毎の情報としてISOBMFFファイルに含まれるようにしてもよい。このようにすることにより、クライアントは、sub-picture trackの情報を参照するだけで、その全体ピクチャのステレオ情報（例えば、全体ピクチャステレオ画像であるか否かや、どのようなタイプのステレオ画像であるか等）を容易に把握することができる。
＜アップロード処理の流れ＞
その場合の図１１のファイル生成装置１００により実行されるアップロード処理の流れの例を、図５１のフローチャートを参照して説明する。
アップロード処理が開始されると、ファイル生成装置１００のデータ入力部１１１は、ステップＳ３０１において、画像とメタデータを取得する。
ステップＳ３０２において、セグメントファイル生成部１２３は、sub-picture毎の情報として、全体ピクチャ（projected picture）のステレオ情報を含むISOBMFFファイルを生成する。
ステップＳ３０３において、記録部１１４は、ステップＳ３０２の処理により生成されたISOBMFFファイルを記録する。
ステップＳ３０４において、アップロード部１１５は、ステップＳ３０３において記録されたISOBMFFファイルを記録部１１４より読み出し、それをサーバにアップロードする。
ステップＳ３０４の処理が終了すると、アップロード処理が終了する。
以上のようにアップロード処理を行うことにより、ファイル生成装置１００は、sub-picture毎の情報として、projected pictureのステレオ情報を含むISOBMFFファイルを生成することができる。
したがって、クライアントは、その情報に基づいて、自身の能力（capability）等に応じた適切なストリームをより容易に選択し、再生することができる。
＜ISOBMFFにシグナルされたsub-picture化される全体ピクチャのステレオ情報の利用＞
また、ISOBMFFファイルにシグナルされた、sub-picture化される全体ピクチャのステレオ情報を利用してストリームの選択や再生を行うようにしてもよい。
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、そのピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを取得し、その取得されたファイルに含まれるステレオ情報に基づいて、画像符号化データのストリームの選択を行うようにしてもよい。
例えば、情報処理装置であるクライアント装置２００において、セグメントファイル取得部２１４が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、そのピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを取得するファイル取得部と、として機能し、データ解析・復号部２１６が、そのファイル取得部により取得されたファイルに含まれるステレオ情報に基づいて、画像符号化データのストリームの選択を行う画像処理部として機能するようにしてもよい。つまり、情報処理装置（例えばクライアント装置２００）が、ファイル取得部（例えばセグメントファイル取得部２１４）と、画像処理部（例えばデータ解析・復号部２１６）とを備えるようにしてもよい。
このようにすることにより、クライアント装置２００は、ストリームの選択をより容易に行うことができる。
なお、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、クライアント装置２００が、投影平面画像の全部、または一部を全体ピクチャとしてそれをsub-picture化したストリームを取得し、再生する場合においても、上述のように本技術を適用することができる。
また、この全体ピクチャのステレオ情報は、サブピクチャ（sub-picture）毎の情報としてISOBMFFファイルに含まれるようにしてもよい。このようにすることにより、クライアント装置２００は、sub-picture trackの情報を参照するだけで、その全体ピクチャのステレオ情報（例えば、全体ピクチャステレオ画像であるか否かや、どのようなタイプのステレオ画像であるか等）を容易に把握することができる。
＜コンテンツ再生処理の流れ＞
その場合のクライアント装置２００により実行されるコンテンツ再生処理の流れの例を、図５２のフローチャートを参照して説明する。
コンテンツ再生処理が開始されると、クライアント装置２００のセグメントファイル取得部２１４は、ステップＳ３２１において、sub-picture毎の情報として全体ピクチャ（projected picture）のステレオ情報を含むISOBMFFファイルを取得する。
ステップＳ３２２において、表示制御部２１５は、ユーザの視点位置（および視線方向）の計測結果を取得する。
ステップＳ３２３において、計測部２１１は、サーバとクライアント装置２００との間のネットワークの伝送帯域幅を計測する。
ステップＳ３２４において、セグメントファイル処理部２２１は、クライアント装置２００がステレオ再生を行うか否か（またはステレオ再生を行う機能（capability）を有するか否か）を判定する。ステレオ再生を行う（またはステレオ再生の機能を有する）と判定された場合、処理はステップＳ３２５に進む。
ステップＳ３２５において、セグメントファイル処理部２２１は、ステレオ表示可能なsub-picture trackを選択候補とする。その際、セグメントファイル処理部２２１は、ステップＳ３２１において取得されたISOBMFFファイルに含まれる全体ピクチャのステレオ情報を参照することにより、第２のパターンのフレームパッキングアレンジメントが適用されていないステレオ表示可能なsub-picture track（例えば、図４９のsub-picture４４５やsub-picture４４６）も選択候補に含めることができる。ステップＳ３２５の処理が終了すると、処理はステップＳ３２７に進む。
また、ステップＳ３２４において、クライアント装置２００がステレオ再生を行わない（またはステレオ再生の機能を有していない）と判定された場合、処理はステップＳ３２６に進む。
ステップＳ３２６において、セグメントファイル処理部２２１は、ステップＳ３２１において取得されたISOBMFFファイルに含まれる全体ピクチャのステレオ情報等に基づいて、モノピクチャのsub-picture trackを選択候補とする。その際、セグメントファイル処理部２２１は、ステップＳ３２１において取得されたISOBMFFファイルに含まれる全体ピクチャのステレオ情報を参照することにより、第３のパターンのsub-picture track（例えば、図５０のsub-picture４５２やsub-picture４５３）について、レンダリングの際に水平方向に２倍のアップスケール（upscale）が必要であることを把握することができる。ステップＳ３２６の処理が終了すると、処理はステップＳ３２７に進む。
ステップＳ３２７において、セグメントファイル処理部２２１は、ステップＳ３２５またはステップＳ３２６において設定した候補の中から、クライアント装置２００のユーザの視野に応じたsub-picture trackを選択する。
ステップＳ３２８において、セグメントファイル処理部２２１は、ステップＳ３２７において選択されたsub-picture trackのストリームの符号化データを、ステップＳ３２１において取得されたISOBMFFファイルから抽出する。
ステップＳ３２９において、デコード部２２２は、ステップＳ３２８において抽出されたストリームの符号化データを復号する。
ステップＳ３３０において、表示情報生成部２２３は、ステップＳ３２９において復号されて得られたストリーム（コンテンツ）を再生する。より具体的には、表示情報生成部２２３は、そのストリームから表示用画像のデータを生成し、それを表示部２１７に供給し、表示させる。
ステップＳ３３０の処理が終了すると、コンテンツ再生処理が終了する。
以上のようにコンテンツ再生処理を行うことにより、クライアント装置２００は、ISOBMFFファイルに含まれるsub-picture化される全体ピクチャのステレオ情報を利用して、より容易にストリームを選択することができる。例えば、クライアント装置２００は、その情報に基づいて、自身の能力（capability）等に応じた適切なストリームをより容易に選択し、再生することができる。
＜全体ピクチャのステレオ情報をSample Entryにシグナル＞
例えば、分割前の全体ピクチャがステレオ画像である場合、ファイル生成装置１００のセグメントファイル生成部１２３が、sub-picture trackのSample Entryにおいて、全体ピクチャのステレオ情報をシグナルするようにしてもよい。
例えば、ISOBMFFファイルの、そのSample Entryの下のScheme Information Box、または、そのScheme Information Boxの下階層のBoxに、全体ピクチャのステレオ情報が格納されるようにしてもよい。
＜Original Stereo Video Box＞
例えば、分割前の全体ピクチャのステレオ情報をシグナルするために、ファイル生成装置１００のセグメントファイル生成部１２３が、Original Stereo Video Boxを新規定義し、sub-picture trackのSample EntryのScheme Information Box（schi）の下に、そのBoxをシグナルするようにしてもよい。つまり、このOriginal Stereo Video Boxに、分割前の全体ピクチャのステレオ情報が格納されるようにしてもよい。
なお、このOriginal Stereo Video Boxの場所は任意であり、上述のScheme Information Boxに限定されない。また、Original Stereo Video Boxでシグナルされる情報は、Stereo Video Boxと同様である。
図５３のシンタックス４６１は、このOriginal Stereo Video Boxのシンタックスの例を示す。シンタックス４６１に示されるように、Original Stereo Video Boxにおいては、single_view_allowed、stereo_scheme、length、stereo_indication_type等のフィールドが定義される。
図５４のセマンティクス４６２は、このOriginal Stereo Video Boxにおいて定義されるフィールドのセマンティクスの例を示す。セマンティクス４６２に示されるように、single_view_allowedは、許容されるビューの種類を示す情報である。例えばこのフィールドの値が０の場合、コンテンツはステレオスコピック対応のディスプレイでのみ表示されることを意図していることを示す。また、このフィールドの値が１の場合、コンテンツはモノスコピックディスプレイでright viewの表示が許されていることを示す。また、このフィールドの値が２の場合、コンテンツはモノスコピックディスプレイでleft viewの表示が許されていることを示す。
stereo_schemeは、フレームパッキング方法に関する情報である。例えば、このフィールドの値が１の場合、フレームパッキング方法は、ISO/IEC 14496-10のFrame packing arrangement SEIに従うことを示す。また、このフィールドの値が２の場合、フレームパッキング方法は、ISO/IEC 13818-2のAnnex.Lに従うことを示す。また、このフィールドの値が３の場合、フレームパッキング方法は、ISO/IEC 23000-11のframe/sevice compatible および2D/3D Mixed seviceに従うことを示す。
lengthは、stereo_indication_typeのバイト長を示す。また、stereo_indication_typeは、stereo_shcemeに従った、フレームパッキング方法を示す。
クライアント装置２００のセグメントファイル処理部２２１は、Original Stereo Video Boxおよび2D Coverage Information Boxを参照することで、全体ピクチャのステレオ情報を取得することができる。そして、セグメントファイル処理部２２１は、この情報に基づいて、sub-picture trackのSample EntryにStereo Video Boxがシグナルされていない場合、sub-pictureがモノなのか、Left viewおよびRight viewを含むものの、Stereo Video Boxでシグナルされるフレームパッキングアレンジメントが適用されていないのか、をSub Picture Composition Boxをパースせずに、容易に識別することができる。つまり、sub-picture trackでないtrackの場合と同様、Sample Entryに格納された情報のみからステレオ情報の識別が可能となる。
つまりクライアント装置２００は、Sub Picture Composition Boxをパースせず、sub-picture track単独の選択・再生することができる。
＜表示サイズのシグナル＞
さらに、ステレオである全体ピクチャを分割して生成したモノsub-picture（モノピクチャであるsub-picture）を格納するsub-picture trackのTrack Headerのwidthおよびheightに、全体ピクチャのフレームパッキングアレンジメントをもとにupscaleした表示サイズをシグナルするようにしてもよい。
つまり、ISOBMFFファイルに、sub-pictureの表示サイズに関する情報が含まれるようにしてもよい。
その様子の例を図５５に示す。図５５に示されるように、ステレオ画像の全体ピクチャから生成されたsub-picture４７１およびsub-picture４７２は、各領域の画像が水平方向にダウンスケールされている。したがって、表示時（レンダリング）の際には、水平方向にupscaleする必要がある。そこで、この表示時の画像４７３の表示サイズをTrack Headerのwidthおよびheightとしてシグナルするようにする。これにより、クライアント装置２００が、モノsub-pictureを適切にレンダリングすることができる。
なお、このTrack Headerのwidthおよびheightにおけるシグナリングの代わりに、ISOBMFFで定義される、表示時のピクセル縦横比情報をシグナルするPixel Aspect Ratio Box（pasp）をVisual Sample Entryにシグナルするようにしてもよい。この場合も、上述のTrack Headerのwidthおよびheightにおいてシグナルする場合と同等の効果を得ることができる。
図５６のシンタックス４８１は、Pixel Aspect Ratio Boxのシンタックスの例を示す。シンタックス４８１に示されるように、Pixel Aspect Ratio Boxにおいては、例えば、hSpacing、vSpacing等のフィールドが定義される。
図５７のセマンティクス４８２は、このPixel Aspect Ratio Boxにおいて定義されるフィールドのセマンティクスの例を示す。セマンティクス４８２に示されるように、hSpacingおよびvSpacingは、相対的なピクセル高さ、幅を示す情報である。レンダリングの際には、この情報に基づいて、ピクセル幅がvSpace/hSpace倍されて表示される。
その様子の例を図５８に示す。図５８に示されるsub-picture４９１およびsub-picture４９２は、ステレオ画像の全体ピクチャから生成されたsub-pictureであり、各領域の画像が水平方向にダウンスケールされている。そこで、hSpace=1、vSpase=2をシグナルすることにより、クライアント装置２００は、例えば、sub-picture４９１を表示（レンダリング）する際に、これらの情報に基づいて、ピクセル幅を２倍にしてレンダリングして、画像４９３のように、適切なアスペクト比で画像を表示させることができる。つまり、クライアント装置２００が、モノsub-picture（モノ画像からなるsub-picture）を適切にレンダリングすることができる。
＜Original Scheme Information Box＞
また、sub-picture trackのSample EntryのRestricted Scheme Information Box（rinf）下に、Original Scheme Information Boxを新規定義し、そのBox内に分割前の全体ピクチャのステレオ情報をシグナルするようにしてもよい。なお、Original Scheme Information Boxを定義する場所は、任意であり、上述のrinfに限定されない。
図５９のシンタックス５０１は、その場合のOriginal Scheme Information Boxのシンタックスの例を示す。シンタックス５０１に示されるように、Original Scheme Information Boxにおいては、例えば、scheme_specific_dataが定義される。
このscheme_specific_dataには、sub-pictureに分割される前の全体ピクチャについての情報がシグナルされる。例えば、全体ピクチャがステレオであった場合には、全体ピクチャのステレオ情報を持つStereo Video Boxがシグナルされるようにしてもよい。このようにすることにより、クライアント装置２００は、Sub Picture Composition Boxをパースせず、sub-picture track単独の選択・再生することができる。
なお、このscheme_specific_dataには、Stereo Video Boxに限らず、全体ピクチャに関するポストプロセッシング情報がシグナルされるようにしてもよい（例えば、Region Wise Packing Boxなど）。
＜sub-picture track選択を容易にする追加情報＞
さらに、2D Coverage Information Boxを拡張し、track選択を容易にするステレオ関連情報をシグナルするようにしてもよい。
例えば、2D Coverage Information Boxにstereo_presentation_suitable_flagを追加し、sub-picture trackがステレオ表示可能か否かをシグナルするようにしてもよい。この情報を参照することで、クライアント装置２００は、第３の実施の形態において上述した全体ピクチャのステレオ情報と、第１の実施の形態において定義した2D Coverage Information Boxでシグナルされるprojected picture上における領域情報に基づいてステレオ表示が可能であるか否かを識別する処理を行わずとも、ステレオ表示が可能であるか否かを識別することができる。
つまり、ISOBMFFファイルが、サブピクチャ毎のステレオ表示に関する情報であるサブステレオ情報をさらに含むようにしてもよい。
図６０のシンタックス５０２は、この場合の2D Coverage Information Boxの例を示す。シンタックス５０２に示されるように、この場合、さらにstereo_presentation_suitableが定義される（定義されるフィールドにstereo_presentation_suitableが追加される）。
図６１のセマンティクス５０３は、この追加されるフィールドのセマンティクスの例を示す。セマンティクス５０３に示されるように、stereo_presentation_suitableは、trackのピクチャのステレオ表示に関する情報である。このフィールドの値が０の場合、trackのピクチャがモノであるか、または、L view、R viewを含むがステレオ表示不可能であることを示す。このフィールドの値が１の場合、trackのピクチャは、一部領域のステレオ表示が可能であることを示す。このフィールドの値が２の場合、trackのピクチャは全ての領域がステレオ表示可能であることを示す。
図６２は、stereo_presentation_suitableのシグナル例を示す図である。例えば、図６２の上側に示されるように、side by sideのステレオ画像である全体ピクチャ（projected picture）５１１を、sub-picture化して生成された、sub-picture５１２乃至sub-picture５１７は、L viewとR viewを含み、ステレオ表示可能である。したがって、これらのsub-pictureには、stereo_presentation_suitable=2がセットされる。
これに対して、図６２の下側に示されるように、side by sideのステレオ画像である全体ピクチャ（projected picture）５２１を、sub-picture化して生成された、sub-picture５２２乃至sub-picture５２６は、L viewとR viewを含む。ただし、sub-picture５２２乃至sub-picture５２４は、ステレオ表示することができない。したがって、これらのsub-pictureには、stereo_presentation_suitable=0がセットされる。
また、sub-picture５２５およびsub-picture５２６は、一部の領域をステレオ表示することができる。したがって、これらのsub-pictureには、stereo_presentation_suitable=1がセットされる。
なお、ステレオ表示可能か否かの情報を、個別のBox（その情報を格納する為の専用のBox）、例えばTrack Stereo Video Boxを新規定義して、sub-picture trackのschi下にシグナルするようにしてもよい。
図６３のシンタックス５３１は、その場合のTrack Stereo Video Boxのシンタックスの例を示す。
また、sub-picture trackのSample EntryのProjected Omnidirectional Video Box下でシグナルされるRegion Wise Packing Box、または、第１の実施の形態において上述したRectProjected Region構造を拡張し、stereo_presentation_suitable_flagをシグナルするようにしてもよい。また、その他のBoxにstereo_presentation_suitable_flagをシグナルするようにしてもよい。
さらに、ステレオ表示が不可能である場合においては、Track Header Boxのtrack_not_intended_for_presentation_aloneフラグを用い、sub-picture単独再生が望ましくないことをシグナルするようにしてもよい。
なお、上述の各種情報は、trackに格納されるpictureがsub-pictureでない場合においても適用可能である。
＜view情報のシグナル＞
また、2D Coverage Information Boxを拡張し、sub-pictureのprojected picture上における表示領域に対し、view情報を追加でシグナルするようにしてもよい。この情報を参照することで、クライアント装置２００は、第３の実施の形態において上述した全体ピクチャのステレオ情報と、第３の実施の形態において定義した2D Coverage Information Boxでシグナルされるprojected picture上における領域情報から各領域のview情報を識別する処理を行わずとも、sub-pictureがモノ画像であるか、L viewおよびR viewを含むのかを容易に識別することができる。
つまり、ISOBMFFファイルが、サブピクチャのビュータイプを示すビュー情報をさらに含むようにしてもよい。
図６４のシンタックス５３２は、この場合の2D Coverage Information Boxのシンタックスの例を示す図である。シンタックス５３２に示されるように、この場合、2D Coverage Information Boxにおいて、view_idc_presence_flag、default_view_idc、view_idc等のフィールドが追加的に定義される。
図６５のセマンティクス５３３は、この2D Coverage Information Boxにおいて追加的に定義されるフィールドのセマンティクスの例を示す。セマンティクス５３３に示されるように、view_idc_presense_flagは、各領域に個別のview_idcが存在するか否かを示す。例えば、このフィールドの値が０の場合、各領域に個別のview_idcが存在しないことを示す。また、このフィールドの値が１の場合、各領域に個別のview_idcが存在することを示す。
つまり、ISOBMFFファイルが、ビュー情報が領域毎に存在するかを示す情報をさらに含むようにしてもよい。
default_view_idcは、領域全てに共通なviewを示す。例えば、このフィールドの値が０の場合、このsub-picture内の全ての領域がmono viewであることを示す。また、このフィールドの値が１の場合、このsub-picture内の全ての領域がleft viewであることを示す。また、このフィールドの値が２の場合、このsub-picture内の全ての領域がright viewであることを示す。また、このフィールドの値が３の場合、このsub-picture内の全ての領域がstereo viewであることを示す。
view_idcは、領域毎のviewを示す。例えば、このフィールドの値が０の場合、その領域がmono viewであることを示す。また、このフィールドの値が１の場合、その領域がleft viewであることを示す。また、このフィールドの値が２の場合、その領域がright viewであることを示す。また、このフィールドの値が３の場合、その領域がstereo viewであることを示す。また、このフィールドが存在しない場合、default_view_idcが各領域のviewを示すことを示す。
つまり、ビュー情報は、サブピクチャに含まれる領域毎の情報であってもよい。
図６６は、このview_idcをシグナルする様子の例を示す図である。図６６に示されるように、side by sideの全体ピクチャ５４１を、sub-picture５４２およびsub-picture５４３のようにsub-picture化する場合、これらのsub-pictureには、それぞれ、view_idc=3がセットされる。
これに対して、全体ピクチャ５４１を、sub-picture５４４およびsub-picture５４５のようにsub-picture化する場合、sub-picture５４４に対しては、view_idc=1がセットされ、sub-picture５４５に対しては、view_idc=2がセットされる。
なお、trackに格納されるpictureがsub-pictureでない場合においても、これらの追加情報を適用することができる。
同様に、Region Wise Packing Box、および第１の実施の形態において定義したRect Projected Region構造を拡張し、view情報をシグナルするようにしてもよい。
＜５．第４の実施の形態＞
＜MPDファイルによるsub-picture化される全体ピクチャのステレオ情報のシグナル＞
上述したsub-picture化される全体ピクチャのステレオ情報のシグナルを、MPDファイルにおいて行うようにしてもよい。つまり、クライアントが、sub-pictureを参照するAdaptation Setを例えばクライアントの能力（capability）に応じて選択・再生することを可能にするために、MPDファイルにおいて、sub-picture化される全体ピクチャのステレオ情報を新規定義し、Adaptation Setにシグナルするようにしてもよい。
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、そのアダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、画像符号化データの配信制御に用いられる制御ファイルを生成するようにしてもよい。
例えば、情報処理装置であるファイル生成装置１００において、MPDファイル生成部１１３が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、そのアダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、画像符号化データの配信制御に用いられる制御ファイルを生成するファイル生成部として機能するようにしてもよい。つまり情報処理装置（例えばファイル生成装置１００）が、ファイル生成部（例えばMPDファイル生成部１１３）を備えるようにしてもよい。
このようにすることにより、上述したように、クライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
また、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、ファイル生成装置１００が、このような投影平面画像の全部、または一部を全体ピクチャとし、それをsub-picture化する場合において、上述のように本技術を適用することができる。
このようにすることにより、全天球映像を配信する場合においても、上述したようにクライアントは、この情報に基づいてストリームの選択をより容易に行うことができる。
なお、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてMPDファイルに含まれるようにしてもよい。このようにすることにより、クライアントは、Adaptation Setが参照するsub-pictureの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
＜アップロード処理の流れ＞
その場合の図１１のファイル生成装置１００により実行されるアップロード処理の流れの例を、図６７のフローチャートを参照して説明する。
アップロード処理が開始されると、ファイル生成装置１００のデータ入力部１１１は、ステップＳ４０１において、画像とメタデータを取得する。
ステップＳ４０２において、セグメントファイル生成部１２３は、その画像のセグメントファイルを生成する。
ステップＳ４０３において、MPDファイル生成部１１３は、sub-picture毎の情報として、全体ピクチャ（projected picture）のステレオ情報を含むMPDファイルを生成する。
ステップＳ４０４において、記録部１１４は、ステップＳ４０２の処理により生成されたセグメントファイルを記録する。また、記録部１１４は、ステップＳ４０３の処理により生成されたMPDファイルを記録する。
ステップＳ４０５において、アップロード部１１５は、ステップＳ４０４において記録されたセグメントファイルを記録部１１４より読み出し、それをサーバにアップロードする。また、アップロード部１１５は、ステップＳ４０４において記録されたMPDファイルを記録部１１４より読み出し、それをサーバにアップロードする。
ステップＳ４０４の処理が終了すると、アップロード処理が終了する。
以上のようにアップロード処理を行うことにより、ファイル生成装置１００は、sub-picture毎の情報として、全体ピクチャのステレオ情報を含むMPDファイルを生成することができる。
したがって、クライアントは、その表示領域情報に基づいて、例えばクライアント装置２００の機能（capability）に応じた適切なストリームをより容易に選択し、再生することができる。
＜MPDファイルにシグナルされたsub-picture化される全体ピクチャのステレオ情報の利用＞
また、MPDファイルにシグナルされた、sub-picture化される全体ピクチャのステレオ情報を利用してストリームの選択を行うようにしてもよい。
つまり、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、そのアダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、画像符号化データの配信制御に用いられる制御ファイルを取得し、その取得された制御ファイルに含まれるステレオ情報に基づいて、画像符号化データのストリームの選択を行うようにしてもよい。
例えば、情報処理装置であるクライアント装置２００において、MPDファイル取得部２１２が、ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、そのアダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、画像符号化データの配信制御に用いられる制御ファイルを取得するファイル取得部として機能し、MPDファイル処理部２１３が、その取得された制御ファイルに含まれるステレオ情報に基づいて、画像符号化データのストリームの選択を行う画像処理部として機能するようにしてもよい。つまり、情報処理装置（例えばクライアント装置２００）が、ファイル取得部（例えばMPDファイル取得部２１２）と、画像処理部（例えばMPDファイル処理部２１３）とを備えるようにしてもよい。
このようにすることにより、クライアント装置２００は、ストリームの選択をより容易に行うことができる。
なお、上述のピクチャ（全体ピクチャ）は、全天球映像（水平方向の周囲360度および垂直方向の周囲180度の画像を投影・マッピングした投影平面画像）の全部、または一部であるようにしてもよい。つまり、クライアント装置２００が、投影平面画像の全部、または一部を全体ピクチャとしてそれをsub-picture化したストリームを取得し、再生する場合においても、上述のように本技術を適用することができる。
また、この領域に関する情報（表示領域情報）は、サブピクチャ（sub-picture）毎の情報としてMPDファイルに含まれるようにしてもよい。このようにすることにより、クライアント装置２００は、Adaptation Setが参照するsub-pictureの情報を参照するだけで、そのsub-pictureが全体ピクチャのどの部分に対応するかを容易に把握することができる。
＜コンテンツ再生処理の流れ＞
その場合のクライアント装置２００により実行されるコンテンツ再生処理の流れの例を、図６８のフローチャートを参照して説明する。
コンテンツ再生処理が開始されると、クライアント装置２００のMPDファイル取得部２１２は、ステップＳ４２１において、sub-picture毎の情報として全体ピクチャ（projected picture）のステレオ情報を含むMPDファイルを取得する。
ステップＳ４２２において、表示制御部２１５は、ユーザの視点位置（および視線方向）の計測結果を取得する。
ステップＳ４２３において、計測部２１１は、サーバとクライアント装置２００との間のネットワークの伝送帯域幅を計測する。
ステップＳ４２４において、MPDファイル処理部２１３は、クライアント装置２００がステレオ再生を行うか否か（またはステレオ再生を行う機能（capability）を有するか否か）を判定する。ステレオ再生を行う（またはステレオ再生の機能を有する）と判定された場合、処理はステップＳ４２５に進む。
ステップＳ４２５において、MPDファイル処理部２１３は、ステレオ表示可能なsub-pictureを参照するAdaptation Setを選択候補とする。その際、MPDファイル処理部２１３は、ステップＳ４２１において取得されたMPDファイルに含まれる全体ピクチャのステレオ情報を参照することにより、第２のパターンのフレームパッキングアレンジメントが適用されていないステレオ表示可能なsub-picture（例えば、図４９のsub-picture４４５やsub-picture４４６）を参照するAdaptation Setも選択候補に含めることができる。ステップＳ４２５の処理が終了すると、処理はステップＳ４２７に進む。
また、ステップＳ４２４において、クライアント装置２００がステレオ再生を行わない（またはステレオ再生の機能を有していない）と判定された場合、処理はステップＳ４２６に進む。
ステップＳ４２６において、MPDファイル処理部２１３は、ステップＳ４２１において取得されたMPDファイルに含まれる全体ピクチャのステレオ情報等に基づいて、モノピクチャのsub-pictureを参照するAdaptation Setを選択候補とする。その際、MPDファイル処理部２１３は、ステップＳ４２１において取得されたMPDファイルに含まれる全体ピクチャのステレオ情報を参照することにより、第３のパターンのsub-picture（例えば、図５０のsub-picture４５２やsub-picture４５３）について、レンダリングの際に水平方向に２倍のアップスケール（upscale）が必要であることを把握することができる。ステップＳ４２６の処理が終了すると、処理はステップＳ４２７に進む。
ステップＳ４２７において、MPDファイル処理部２１３は、ステップＳ４２５またはステップＳ４２６において設定した候補の中から、クライアント装置２００のユーザの視野に相当する（対応する）sub-pictureを参照するAdaptation Setを選択する。
ステップＳ４２８において、MPDファイル処理部２１３は、ステップＳ４２４において選択されたAdaptation Setの中から、ユーザの視点位置および視線方向やクライアントとサーバとの間のネットワークの伝送帯域幅等に応じたリプレゼンテーション（Representation）を選択する。
ステップＳ４２９において、セグメントファイル取得部２１４は、ステップＳ４２８において選択されたリプレゼンテーション（Representation）に対応するセグメントファイルを取得する。
ステップＳ４３０において、セグメントファイル処理部２２１は、ステップＳ４２９において取得されたセグメントファイルから符号化データを抽出する。
ステップＳ４３１において、デコード部２２２は、ステップＳ４３０において抽出されたストリームの符号化データを復号する。
ステップＳ４３２において、表示情報生成部２２３は、ステップＳ４３１において復号されて得られたストリーム（コンテンツ）を再生する。より具体的には、表示情報生成部２２３は、そのストリームから表示用画像のデータを生成し、それを表示部２１７に供給し、表示させる。
ステップＳ４３２の処理が終了すると、コンテンツ再生処理が終了する。
以上のようにコンテンツ再生処理を行うことにより、クライアント装置２００は、MPDファイルに含まれるsub-pictureの表示領域に関する情報を利用して、より容易にストリームを選択することができる。例えば、クライアント装置２００は、その情報に基づいて、自身の能力（capability）等に応じた適切なストリームをより容易に選択し、再生することができる。
＜MPDファイルにおけるステレオ情報のシグナル詳細＞
例えば、2D coverage information descriptorを拡張し、第３の実施の形態において説明した場合と同様に、stereo_presentation_suitableフィールド、およびview情報をシグナルするようにしてもよい。
つまり、MPDファイルは、サブピクチャのビュータイプを示すビュー情報をさらに含むようにしてもよい。
また、そのビュー情報は、サブピクチャに含まれる領域毎の情報であるようにしてもよい。
さらに、MPDファイルは、そのビュー情報が領域毎に存在するかを示す情報をさらに含むようにしてもよい。
図６９の属性値５５１および図７０の属性値５５２は、拡張した2D coverage information descriptorの属性値の例を示す。属性値５５１および属性値５５２に示されるように、twoDCoverageは、データタイプがomaf:twoDCoverageTypeであるコンテナ要素である。twoDCoverage@stereo_presentation_suitableは、データタイプがomaf:StereoPresentationTypeであり、Adaptation Setがステレオ表示可能かどうか示す。例えば、この属性値が０の場合、Adaptation Setが参照するピクチャがモノであるか、または、ステレオ表示不可能であることを示す。また、この属性値が１の場合、Adaptation Setが参照するピクチャは、一部の領域のステレオ表示が可能であることを示す。また、この属性値が２の場合、Adaptation Setが参照するピクチャは、全ての領域のステレオ表示が可能であることを示す。
twoDCoverage@view_idc_presence_flagは、データタイプがxs:booleanであり、各領域に個別のview_idcが存在するか否かを示す。例えばこの属性値が０の場合、各領域に個別のview_idcが存在しないことを示す。また、この属性値が１の場合、各領域に個別のview_idcが存在することを示す。twoDCoverage@default_view_idcは、データタイプがomaf:ViewTypeであり、領域全てに共通なviewを示す。例えば、この属性値が０の場合、mono viewであることを示し、この属性値が１の場合、left viewであることを示し、この属性値が２の場合、right viewであることを示し、この属性値が３の場合、stereo viewであることを示す。なお、twoDCoverage@view_idc_presence_flag=0のとき、この属性は必ず存在する。また、twoDCoverage@view_idc_presence_flag=1のとき、この属性は存在してはいけない。
twoDCoverage@proj_picture_widthは、データタイプがxs:unsignedIntであり、projected pictureの幅を示す。twoDCoverage@proj_picture_heightは、データタイプがxs:unsignedIntであり、projected pictureの高さを示す。twoDCoverage.twoDCoverageInfoは、データタイプがomaf:twoDCoverageInfoTypeであり、projected picture上における領域情報を示す要素である。この要素は、複数シグナルすることができる。
twoDCoverage.twoDCoverageInfo@view_idcは、データタイプがomaf:ViewTypeであり、領域ごとのviewを示す。例えば、この属性値が０の場合、mono viewであることを示し、この属性値が１の場合、left viewであることを示し、この属性値が２の場合、right viewであることを示し、この属性値が３の場合、stereo viewであることを示す。なお、twoDCoverage@view_idc_presence_flag=0のとき、この属性は存在してはいけない。また、twoDCoverage@view_idc_presence_flag=1のとき、この属性は必ず存在する。
twoDCoverage.twoDCoverageInfo@proj_reg_widthは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の幅を示す。twoDCoverage.twoDCcoverageInfo@proj_reg_heightは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の高さを示す。
twoDCoverage.twoDCoverageInfo@proj_reg_topは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域の垂直方向座標を示す。twoDCoverage.twoDCoverageInfo@proj_reg_leftは、データタイプがxs:unsignedIntであり、Adaptation Setが参照するpictureが対応する、projected picture上における領域水平方向座標を示す。
図７１のデータタイプ５５３は、この場合のデータタイプの定義の例を示す。
なお、第２の実施の形態において説明した、拡張したRegion-wise packing descriptorおよびContent coverage descriptorをさらに拡張し、stereo_presentation_suitableおよびview情報をシグナルするようにしてもよい。また、その他のdescriptorを用いてこれらの情報をシグナルするようにしてもよい。
＜６．付記＞
＜コンピュータ＞
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここでコンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等が含まれる。
図７２は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
図７２に示されるコンピュータ９００において、CPU（Central Processing Unit）９０１、ROM（Read Only Memory）９０２、RAM（Random Access Memory）９０３は、バス９０４を介して相互に接続されている。
バス９０４にはまた、入出力インタフェース９１０も接続されている。入出力インタフェース９１０には、入力部９１１、出力部９１２、記憶部９１３、通信部９１４、およびドライブ９１５が接続されている。
入力部９１１は、例えば、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部９１２は、例えば、ディスプレイ、スピーカ、出力端子などよりなる。記憶部９１３は、例えば、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部９１４は、例えば、ネットワークインタフェースよりなる。ドライブ９１５は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア９２１を駆動する。
以上のように構成されるコンピュータでは、CPU９０１が、例えば、記憶部９１３に記憶されているプログラムを、入出力インタフェース９１０およびバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。RAM９０３にはまた、CPU９０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
コンピュータ（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９２１に記録して適用することができる。その場合、プログラムは、リムーバブルメディア９２１をドライブ９１５に装着することにより、入出力インタフェース９１０を介して、記憶部９１３にインストールすることができる。
また、このプログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することもできる。その場合、プログラムは、通信部９１４で受信し、記憶部９１３にインストールすることができる。
その他、このプログラムは、ROM９０２や記憶部９１３に、あらかじめインストールしておくこともできる。
＜本技術の適用対象＞
以上においては、ISOBMFFファイルまたはMPDファイルに本技術を適用する場合について説明したが、本技術は、これらの例に限らず、立体構造画像を単数の平面にマッピングした投影平面画像のストリームを配信する、任意の規格のファイルに対して適用することができる。つまり、上述した本技術と矛盾しない限り、配信制御、ファイル形式、符号化・復号方式等の各種処理の仕様は任意である。また、本技術と矛盾しない限り、上述した一部の処理や仕様を省略してもよい。
また、以上においては、本技術の適用例としてファイル生成装置１００やクライアント装置２００について説明したが、本技術は、任意の構成に適用することができる。
例えば、本技術は、衛星放送、ケーブルＴＶなどの有線放送、インターネット上での配信、およびセルラー通信による端末への配信などにおける送信機や受信機（例えばテレビジョン受像機や携帯電話機）、または、光ディスク、磁気ディスクおよびフラッシュメモリなどの媒体に画像を記録したり、これら記憶媒体から画像を再生したりする装置（例えばハードディスクレコーダやカメラ）などの、様々な電子機器に適用され得る。
また、例えば、本技術は、システムLSI（Large Scale Integration）等としてのプロセッサ（例えばビデオプロセッサ）、複数のプロセッサ等を用いるモジュール（例えばビデオモジュール）、複数のモジュール等を用いるユニット（例えばビデオユニット）、または、ユニットにさらにその他の機能を付加したセット（例えばビデオセット）等、装置の一部の構成として実施することもできる。
また、例えば、本技術は、複数の装置により構成されるネットワークシステムにも適用することもできる。例えば、本技術を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングとして実施するようにしてもよい。例えば、コンピュータ、AV（Audio Visual）機器、携帯型情報処理端末、IoT（Internet of Things）デバイス等の任意の端末に対して、画像（動画像）に関するサービスを提供するクラウドサービスにおいて本技術を実施するようにしてもよい。
なお、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、および、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
＜本技術を適用可能な分野・用途＞
本技術を適用したシステム、装置、処理部等は、例えば、交通、医療、防犯、農業、畜産業、鉱業、美容、工場、家電、気象、自然監視等、任意の分野に利用することができる。また、その用途も任意である。
例えば、本技術は、観賞用コンテンツ等の提供の用に供されるシステムやデバイスに適用することができる。また、例えば、本技術は、交通状況の監理や自動運転制御等、交通の用に供されるシステムやデバイスにも適用することができる。さらに、例えば、本技術は、セキュリティの用に供されるシステムやデバイスにも適用することができる。また、例えば、本技術は、機械等の自動制御の用に供されるシステムやデバイスに適用することができる。さらに、例えば、本技術は、農業や畜産業の用に供されるシステムやデバイスにも適用することができる。また、本技術は、例えば火山、森林、海洋等の自然の状態や野生生物等を監視するシステムやデバイスにも適用することができる。さらに、例えば、本技術は、スポーツの用に供されるシステムやデバイスにも適用することができる。
＜その他＞
なお、本明細書において「フラグ」とは、複数の状態を識別するための情報であり、真(1)または偽(0)の２状態を識別する際に用いる情報だけでなく、３以上の状態を識別することが可能な情報も含まれる。したがって、この「フラグ」が取り得る値は、例えば1/0の２値であってもよいし、３値以上であってもよい。すなわち、この「フラグ」を構成するbit数は任意であり、1bitでも複数bitでもよい。また、識別情報（フラグも含む）は、その識別情報をビットストリームに含める形だけでなく、ある基準となる情報に対する識別情報の差分情報をビットストリームに含める形も想定されるため、本明細書においては、「フラグ」や「識別情報」は、その情報だけではなく、基準となる情報に対する差分情報も包含する。
また、符号化データ（ビットストリーム）に関する各種情報（メタデータ等）は、符号化データに関連づけられていれば、どのような形態で伝送または記録されるようにしてもよい。ここで、「関連付ける」という用語は、例えば、一方のデータを処理する際に他方のデータを利用し得る（リンクさせ得る）ようにすることを意味する。つまり、互いに関連付けられたデータは、１つのデータとしてまとめられてもよいし、それぞれ個別のデータとしてもよい。例えば、符号化データ（画像）に関連付けられた情報は、その符号化データ（画像）とは別の伝送路上で伝送されるようにしてもよい。また、例えば、符号化データ（画像）に関連付けられた情報は、その符号化データ（画像）とは別の記録媒体（または同一の記録媒体の別の記録エリア）に記録されるようにしてもよい。なお、この「関連付け」は、データ全体でなく、データの一部であってもよい。例えば、画像とその画像に対応する情報とが、複数フレーム、１フレーム、またはフレーム内の一部分などの任意の単位で互いに関連付けられるようにしてもよい。
なお、本明細書において、「合成する」、「多重化する」、「付加する」、「一体化する」、「含める」、「格納する」、「入れ込む」、「差し込む」、「挿入する」等の用語は、例えば符号化データとメタデータとを１つのデータにまとめるといった、複数の物を１つにまとめることを意味し、上述の「関連付ける」の１つの方法を意味する。
また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
また、例えば、上述したプログラムは、任意の装置において実行されるようにしてもよい。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
また、例えば、１つのフローチャートの各ステップを、１つの装置が実行するようにしてもよいし、複数の装置が分担して実行するようにしてもよい。さらに、１つのステップに複数の処理が含まれる場合、その複数の処理を、１つの装置が実行するようにしてもよいし、複数の装置が分担して実行するようにしてもよい。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
また、例えば、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
また、例えば、本技術に関する複数の技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
なお、本技術は以下のような構成も取ることができる。
（１） 格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを生成するファイル生成部
を備える情報処理装置。
（２） 前記ピクチャは、全天球映像である
（１）に記載の情報処理装置。
（３） 前記領域に関する情報は、前記サブピクチャ毎の情報として前記ファイルに含まれる
（１）または（２）に記載の情報処理装置。
（４） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記ピクチャ領域ごとの配置情報は、Region Wise Packing Boxにシグナルされる情報であり、
前記領域に関する情報は、Region Wise Packing Boxとは異なる、前記ISOBMFFファイルのScheme Information Box、または、前記Scheme Information Boxの下階層のBoxに格納される
（３）に記載の情報処理装置。
（５） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、トラックの球面上における表示領域を示すCoverage Information Boxに格納される
（３）に記載の情報処理装置。
（６） 前記領域に関する情報は、ストリーム中で動的に変化する
（１）乃至（５）のいずれかに記載の情報処理装置。
（７） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、Supplemental Enhancement information messageに格納される
（６）に記載の情報処理装置。
（８） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、timed metadataに格納される
（６）に記載の情報処理装置。
（９） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、Sample Group Entryに格納される
（６）に記載の情報処理装置。
（１０） 格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを生成する
情報処理方法。
（１１） 格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを取得するファイル取得部と、
前記ファイル取得部により取得された前記ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部と
を備える情報処理装置。
（１２） 前記ピクチャは、全天球映像である
（１１）に記載の情報処理装置。
（１３） 前記領域に関する情報は、前記サブピクチャ毎の情報として前記ファイルに含まれる
（１１）または（１２）に記載の情報処理装置。
（１４） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、前記ISOBMFFファイルのScheme Information Box、または、前記Scheme Information Boxの下階層のBoxに格納される
（１３）に記載の情報処理装置。
（１５） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、トラックの球面上における表示領域を示すCoverage Information Boxに格納される
（１３）に記載の情報処理装置。
（１６） 前記領域に関する情報は、ストリーム中で動的に変化する
（１１）乃至（１５）のいずれかに記載の情報処理装置。
（１７） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、Supplemental Enhancement information messageに格納される
（１６）に記載の情報処理装置。
（１８） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、timed metadataに格納される
（１６）に記載の情報処理装置。
（１９） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記領域に関する情報は、Sample Group Entryに格納される
（１６）に記載の情報処理装置。
（２０） 格納されるサブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含み、さらに、前記サブピクチャが符号化された画像符号化データを含むファイルを取得し、
取得された前記ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う
情報処理方法。
（２１） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、前記ピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを生成するファイル生成部
を備える情報処理装置。
（２２） 前記ピクチャは、全天球映像である
（２１）に記載の情報処理装置。
（２３） 前記ステレオ情報は、前記サブピクチャ毎の情報として前記ファイルに含まれる
（２１）または（２２）に記載の情報処理装置。
（２４） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記ステレオ情報は、前記ISOBMFFファイルのScheme Information Box、または、前記Scheme Information Boxの下階層のBoxに格納される
（２３）に記載の情報処理装置。
（２５） 前記ファイルは、前記サブピクチャの表示サイズに関する情報をさらに含む
（２１）乃至（２４）のいずれかに記載の情報処理装置。
（２６） 前記ファイルは、前記サブピクチャ毎のステレオ表示に関する情報であるサブステレオ情報をさらに含む
（２１）乃至（２５）のいずれかに記載の情報処理装置。
（２７） 前記ファイルは、前記サブピクチャのビュータイプを示すビュー情報をさらに含む
（２１）乃至（２６）のいずれかに記載の情報処理装置。
（２８） 前記ビュー情報は、前記サブピクチャに含まれる領域毎の情報である
（２７）に記載の情報処理装置。
（２９） 前記ファイルは、前記ビュー情報が前記領域毎に存在するかを示す情報をさらに含む
（２８）に記載の情報処理装置。
（３０） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、前記ピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを生成する
情報処理方法。
（３１） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、前記ピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを取得するファイル取得部と、
前記ファイル取得部により取得された前記ファイルに含まれる前記ステレオ情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部と
を備える情報処理装置。
（３２） 前記ピクチャは、全天球映像である
（３１）に記載の情報処理装置。
（３３） 前記ステレオ情報は、前記サブピクチャ毎の情報として前記ファイルに含まれる
（３１）または（３２）に記載の情報処理装置。
（３４） 前記ファイルは、ISOBMFF（International Organization for Standardization Base Media File Format）ファイルであり、
前記ステレオ情報は、前記ISOBMFFファイルのScheme Information Box、または、前記Scheme Information Boxの下階層のBoxに格納される
（３３）に記載の情報処理装置。
（３５） 前記ファイルは、前記サブピクチャの表示サイズに関する情報をさらに含む
（３１）乃至（３４）のいずれかに記載の情報処理装置。
（３６） 前記ファイルは、前記サブピクチャ毎のステレオ表示に関する情報であるサブステレオ情報をさらに含む
（３１）乃至（３５）のいずれかに記載の情報処理装置。
（３７） 前記ファイルは、前記サブピクチャのビュータイプを示すビュー情報をさらに含む
（３１）乃至（３６）のいずれかに記載の情報処理装置。
（３８） 前記ビュー情報は、前記サブピクチャに含まれる領域毎の情報である
（３７）に記載の情報処理装置。
（３９） 前記ファイルは、前記ビュー情報が前記領域毎に存在するかを示す情報をさらに含む
（３８）に記載の情報処理装置。
（４０） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像データを互いにトラックに格納し、前記ピクチャ全体のステレオ表示に関する情報であるステレオ情報を含むファイルを取得し、
取得された前記ファイルに含まれる前記ステレオ情報に基づいて、前記画像符号化データのストリームの選択を行う
情報処理方法。
（４１） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成するファイル生成部
を備える情報処理装置。
（４２） 前記ピクチャは、全天球映像である
（４１）に記載の情報処理装置。
（４３） 前記領域に関する情報は、前記サブピクチャ毎の情報として前記制御ファイルに含まれる
（４１）または（４２）に記載の情報処理装置。
（４４） 前記制御ファイルは、MPD（Media Presentation Description）ファイルであり、
前記サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、
前記ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、
前記領域に関する情報は、前記MPDファイルのSupplemental PropertyまたはEssential Propertyに定義される
（４３）に記載の情報処理装置。
（４５） 前記制御ファイルは、MPD（Media Presentation Description）ファイルであり、
前記サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、
前記ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、
前記領域に関する情報は、前記MPDファイルのContent coverage descriptorに定義される
（４３）に記載の情報処理装置。
（４６） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成する
情報処理方法。
（５１） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得するファイル取得部と、
前記ファイル取得部により取得された前記制御ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部と
を備える情報処理装置。
（５２） 前記ピクチャは、全天球映像である
（５１）に記載の情報処理装置。
（５３） 前記領域に関する情報は、前記サブピクチャ毎の情報として前記制御ファイルに含まれる
（５１）または（５２）に記載の情報処理装置。
（５４） 前記制御ファイルは、MPD（Media Presentation Description）ファイルであり、
前記サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、
前記ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、
前記領域に関する情報は、前記MPDファイルのSupplemental PropertyまたはEssential Propertyに定義される
（５３）に記載の情報処理装置。
（５５） 前記制御ファイルは、MPD（Media Presentation Description）ファイルであり、
前記サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、
前記ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、
前記領域に関する情報は、前記MPDファイルのContent coverage descriptorに定義される
（５３）に記載の情報処理装置。
（５６） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応するピクチャ全体における領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得し、
取得された前記制御ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う
情報処理方法。
（６１） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、前記アダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成するファイル生成部
を備える情報処理装置。
（６２） 前記ピクチャは、全天球映像である
（６１）に記載の情報処理装置。
（６３） 前記制御ファイルは、前記サブピクチャのビュータイプを示すビュー情報をさらに含む
（６１）または（６２）に記載の情報処理装置。
（６４） 前記ビュー情報は、前記サブピクチャに含まれる領域毎の情報である
（６３）に記載の情報処理装置。
（６５） 前記制御ファイルは、前記ビュー情報が前記領域毎に存在するかを示す情報をさらに含む
（６３）または（６４）に記載の情報処理装置。
（６６） 前記制御ファイルは、アダプテーションセットがステレオ表示可能かどうか示す情報をさらに含む
（６３）乃至（６５）のいずれかに記載の情報処理装置。
（６７） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、前記アダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成する
情報処理方法。
（７１） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、前記アダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得するファイル取得部と、
前記ファイル取得部により取得された前記制御ファイルに含まれる前記ステレオ情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部と
を備える情報処理装置。
（７２） 前記ピクチャは、全天球映像である
（７１）に記載の情報処理装置。
（７３） 前記制御ファイルは、前記サブピクチャのビュータイプを示すビュー情報をさらに含む
（７１）または（７２）に記載の情報処理装置。
（７４） 前記ビュー情報は、前記サブピクチャに含まれる領域毎の情報である
（７３）に記載の情報処理装置。
（７５） 前記制御ファイルは、前記ビュー情報が前記領域毎に存在するかを示す情報をさらに含む
（７３）または（７４）に記載の情報処理装置。
（７６） 前記制御ファイルは、アダプテーションセットがステレオ表示可能かどうか示す情報をさらに含む
（７３）乃至（７５）のいずれかに記載の情報処理装置。
（７７） ピクチャ全体が複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データをアダプテーションセット毎に管理し、前記アダプテーションセットのステレオ表示に関する情報であるステレオ情報を含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得し、
取得された前記制御ファイルに含まれる前記ステレオ情報に基づいて、前記画像符号化データのストリームの選択を行う
情報処理方法。
１００ ファイル生成装置， １０１ 制御部， １０２ メモリ， １０３ ファイル生成部， １１１ データ入力部， １１２ データ符号化・生成部， １１３ MPDファイル生成部， １１４ 記録部， １１５ アップロード部， １２１ 前処理部， １２２ エンコード部， １２３ セグメントファイル生成部， ２００ クライアント装置， ２０１ 制御部， ２０２ メモリ， ２０３ 再生処理部， ２１１ 計測部， ２１２ MPDファイル取得部， ２１３ MPDファイル処理部， ２１４ セグメントファイル取得部， ２１５ 表示制御部， ２１６ データ解析・復号部， ２１７ 表示部， ２２１ セグメントファイル処理部， ２２２ デコード部， ２２３ 表示情報生成部， ９００ コンピュータ

Claims (20)

  1. 全体ピクチャが複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成するファイル生成部
    を備える情報処理装置。
  2. 前記全体ピクチャは、全天球映像である
    請求項１に記載の情報処理装置。
  3. 前記領域に関する情報は、前記サブピクチャ毎の情報として前記制御ファイルに含まれる
    請求項１に記載の情報処理装置。
  4. 前記制御ファイルは、MPD（Media Presentation Description）ファイルであり、
    前記サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、
    前記ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、
    前記領域に関する情報は、前記MPDファイルのSupplemental PropertyまたはEssential Propertyに定義される
    請求項３に記載の情報処理装置。
  5. 前記制御ファイルは、アダプテーションセットのステレオ表示に関する情報であるステレオ情報をさらに含む
    請求項１に記載の情報処理装置。
  6. 前記全体ピクチャは、全天球映像である
    請求項５に記載の情報処理装置。
  7. 前記制御ファイルは、前記サブピクチャのビュータイプを示すビュー情報をさらに含む
    請求項１に記載の情報処理装置。
  8. 前記ビュー情報は、前記サブピクチャに含まれる領域毎の情報である
    請求項７に記載の情報処理装置。
  9. 前記制御ファイルは、前記ビュー情報が前記領域毎に存在するかを示す情報をさらに含む
    請求項８に記載の情報処理装置。
  10. 前記制御ファイルは、アダプテーションセットがステレオ表示可能かどうか示す情報をさらに含む
    請求項７のいずれかに記載の情報処理装置。
  11. 全体ピクチャが複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを生成する
    情報処理方法。
  12. 全体ピクチャが複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得するファイル取得部と、
    前記ファイル取得部により取得された前記制御ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う画像処理部と
    を備える情報処理装置。
  13. 前記全体ピクチャは、全天球映像である
    請求項１２に記載の情報処理装置。
  14. 前記領域に関する情報は、前記サブピクチャ毎の情報として前記制御ファイルに含まれる
    請求項１２に記載の情報処理装置。
  15. 前記制御ファイルは、MPD（Media Presentation Description）ファイルであり、
    前記サブピクチャ毎の画像符号化データは、アダプテーションセット毎に管理され、
    前記ピクチャ領域毎の配置情報は、Region-wise packing descripitorに格納され、
    前記領域に関する情報は、前記MPDファイルのSupplemental PropertyまたはEssential Propertyに定義される
    請求項１４に記載の情報処理装置。
  16. 前記制御ファイルは、アダプテーションセットのステレオ表示に関する情報であるステレオ情報をさらに含む
    請求項１２に記載の情報処理装置。
  17. 前記全体ピクチャは、全天球映像である
    請求項１６に記載の情報処理装置。
  18. 前記制御ファイルは、前記サブピクチャのビュータイプを示すビュー情報をさらに含む
    請求項１２に記載の情報処理装置。
  19. 前記制御ファイルは、アダプテーションセットがステレオ表示可能かどうか示す情報をさらに含む
    請求項１８のいずれかに記載の情報処理装置。
  20. 全体ピクチャが複数のサブピクチャに分割されて符号化されたサブピクチャ毎の画像符号化データを管理し、前記サブピクチャに対応する全体ピクチャにおける領域に関する情報を、ピクチャ領域毎の配置情報とは異なる情報として含む、前記画像符号化データの配信制御に用いられる制御ファイルを取得し、
    取得された前記制御ファイルに含まれる前記領域に関する情報に基づいて、前記画像符号化データのストリームの選択を行う
    情報処理方法。
JP2019564651A 2018-01-12 2018-12-28 情報処理装置および方法 Active JP7396047B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023194210A JP2024003189A (ja) 2018-01-12 2023-11-15 情報処理装置および方法

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2018003796 2018-01-12
JP2018003796 2018-01-12
JP2018127665 2018-07-04
JP2018127665 2018-07-04
PCT/JP2018/048424 WO2019138929A1 (ja) 2018-01-12 2018-12-28 情報処理装置および方法

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2023194210A Division JP2024003189A (ja) 2018-01-12 2023-11-15 情報処理装置および方法

Publications (2)

Publication Number Publication Date
JPWO2019138929A1 true JPWO2019138929A1 (ja) 2021-01-21
JP7396047B2 JP7396047B2 (ja) 2023-12-12

Family

ID=67218624

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2019564651A Active JP7396047B2 (ja) 2018-01-12 2018-12-28 情報処理装置および方法
JP2023194210A Pending JP2024003189A (ja) 2018-01-12 2023-11-15 情報処理装置および方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
JP2023194210A Pending JP2024003189A (ja) 2018-01-12 2023-11-15 情報処理装置および方法

Country Status (11)

Country Link
US (2) US20210084282A1 (ja)
EP (1) EP3734982A4 (ja)
JP (2) JP7396047B2 (ja)
KR (1) KR20200107945A (ja)
CN (1) CN111567057B (ja)
BR (1) BR112020013705A2 (ja)
MX (1) MX2020007074A (ja)
RU (1) RU2020122086A (ja)
SG (1) SG11202005090TA (ja)
TW (1) TW201937937A (ja)
WO (1) WO2019138929A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20220114088A (ko) * 2019-12-31 2022-08-17 노키아 테크놀로지스 오와이 비디오 인코딩 및 비디오 디코딩을 위한 방법, 장치 및 컴퓨터 프로그램 제품
JPWO2022210661A1 (ja) * 2021-03-30 2022-10-06

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015008775A1 (ja) * 2013-07-19 2015-01-22 ソニー株式会社 情報処理装置および方法
WO2017202699A1 (en) * 2016-05-23 2017-11-30 Canon Kabushiki Kaisha Method, device, and computer program for adaptive streaming of virtual reality media content
JP2019024197A (ja) * 2017-07-07 2019-02-14 ノキア テクノロジーズ オーユー ビデオの符号化・復号の方法、装置、およびコンピュータプログラムプロダクト
JP2019062390A (ja) * 2017-09-26 2019-04-18 キヤノン株式会社 情報処理装置、情報提供装置、制御方法、及びプログラム
JP2020521348A (ja) * 2017-10-24 2020-07-16 エルジー エレクトロニクス インコーポレイティド 魚眼ビデオ情報を含む３６０度ビデオを送受信する方法及びその装置
JP2020537367A (ja) * 2017-10-12 2020-12-17 キヤノン株式会社 メディアコンテンツを生成および処理するための方法、装置、およびコンピュータプログラム

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4266737B2 (ja) * 2003-07-31 2009-05-20 キヤノン株式会社 画像処理方法および装置
JP2006107163A (ja) * 2004-10-06 2006-04-20 Konica Minolta Photo Imaging Inc 受付端末及びファイル編集プログラム並びに注文処理方法
JP4993578B2 (ja) * 2007-01-15 2012-08-08 オリンパスイメージング株式会社 画像ファイル再生装置，画像ファイル加工編集装置
KR100962696B1 (ko) * 2007-06-07 2010-06-11 주식회사 이시티 부호화된 스테레오스코픽 영상 데이터 파일의 구성방법
EP2395772A3 (en) * 2008-09-30 2013-09-18 Panasonic Corporation Glasses and display device
JP5089658B2 (ja) * 2009-07-16 2012-12-05 株式会社Ｇｎｚｏ 送信装置及び送信方法
JP5144789B2 (ja) * 2011-06-24 2013-02-13 楽天株式会社 画像提供装置、画像処理方法、画像処理プログラム及び記録媒体
CN104113632B (zh) * 2013-04-22 2016-12-28 联想(北京)有限公司 一种信息处理方法及电子设备
EP3148200B1 (en) * 2014-06-30 2020-06-17 Sony Corporation Information processing device and method selecting content files based on encoding parallelism type
EP3451675A4 (en) * 2016-04-26 2019-12-04 LG Electronics Inc. -1- METHOD FOR TRANSFERRING 360 DEGREE VIDEOS, METHOD FOR RECEIVING 360 DEGREE VIDEOS, DEVICE FOR TRANSMITTING 360 DEGREE VIDEOS AND DEVICE FOR RECEIVING 360 DEGREE VIDEOS
US10554981B2 (en) * 2016-05-10 2020-02-04 Qualcomm Incorporated Methods and systems for generating regional nesting messages for video pictures
US10547879B2 (en) 2016-07-14 2020-01-28 Mediatek Inc. Method and apparatus for streaming video content
WO2018043905A1 (ko) * 2016-08-29 2018-03-08 엘지전자 주식회사 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
KR102305633B1 (ko) 2017-03-17 2021-09-28 엘지전자 주식회사 퀄리티 기반 360도 비디오를 송수신하는 방법 및 그 장치
US10523913B2 (en) * 2017-06-30 2019-12-31 Apple Inc. Packed image format for multi-directional video
US10587883B2 (en) * 2017-07-14 2020-03-10 Qualcomm Incorporated Region-wise packing, content coverage, and signaling frame packing for media content
KR102188270B1 (ko) * 2018-07-06 2020-12-09 엘지전자 주식회사 360 비디오 데이터의 서브픽처 기반 처리 방법 및 그 장치
WO2020050577A1 (ko) * 2018-09-07 2020-03-12 엘지전자 주식회사 비디오 송신 방법, 비디오 송신 장치, 비디오 수신 방법 및 비디오 수신 장치

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015008775A1 (ja) * 2013-07-19 2015-01-22 ソニー株式会社 情報処理装置および方法
WO2017202699A1 (en) * 2016-05-23 2017-11-30 Canon Kabushiki Kaisha Method, device, and computer program for adaptive streaming of virtual reality media content
JP2019024197A (ja) * 2017-07-07 2019-02-14 ノキア テクノロジーズ オーユー ビデオの符号化・復号の方法、装置、およびコンピュータプログラムプロダクト
JP2019062390A (ja) * 2017-09-26 2019-04-18 キヤノン株式会社 情報処理装置、情報提供装置、制御方法、及びプログラム
JP2020537367A (ja) * 2017-10-12 2020-12-17 キヤノン株式会社 メディアコンテンツを生成および処理するための方法、装置、およびコンピュータプログラム
JP2020521348A (ja) * 2017-10-24 2020-07-16 エルジー エレクトロニクス インコーポレイティド 魚眼ビデオ情報を含む３６０度ビデオを送受信する方法及びその装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"DRAFT GUIDELINES", vol. Version 0.0 draft 010, JPN6019003919, 8 October 2017 (2017-10-08), pages 1 - 68, ISSN: 0004953527 *
R. SKUPIN, ET AL.: ""Standardization Status of 360 degree Video Coding and Delivery"", PROCEEDINGS OF 2017 IEEE VISUAL COMMUNICATIONS AND IMAGE PROCESSING (VCIP), JPN6019003911, 13 December 2017 (2017-12-13), pages 1 - 4, XP033325761, ISSN: 0004953528, DOI: 10.1109/VCIP.2017.8305083 *

Also Published As

Publication number Publication date
CN111567057A (zh) 2020-08-21
EP3734982A4 (en) 2020-11-25
JP7396047B2 (ja) 2023-12-12
WO2019138929A1 (ja) 2019-07-18
BR112020013705A2 (pt) 2020-12-01
US11729366B2 (en) 2023-08-15
KR20200107945A (ko) 2020-09-16
EP3734982A1 (en) 2020-11-04
SG11202005090TA (en) 2020-06-29
MX2020007074A (es) 2020-09-09
JP2024003189A (ja) 2024-01-11
RU2020122086A (ru) 2022-01-04
CN111567057B (zh) 2022-11-04
US20220224874A1 (en) 2022-07-14
TW201937937A (zh) 2019-09-16
US20210084282A1 (en) 2021-03-18

Similar Documents

Publication Publication Date Title
JP6960528B2 (ja) メディアコンテンツを生成および処理するための方法、装置、およびコンピュータプログラム
KR102559862B1 (ko) 미디어 콘텐츠 전송을 위한 방법, 디바이스, 및 컴퓨터 프로그램
US20240040170A1 (en) Method, device, and computer program for transmitting media content
US11582496B2 (en) Method, device, and computer program for transmitting media content
JP7487742B2 (ja) 画像処理装置および方法
JP2020529149A (ja) イメージ処理方法、端末およびサーバ
JP2024003189A (ja) 情報処理装置および方法
WO2021251173A1 (ja) 情報処理装置および方法
WO2019138928A1 (ja) 情報処理装置および方法
JP2019125865A (ja) 情報処理装置および方法
WO2019138927A1 (ja) 情報処理装置および方法
WO2023169003A1 (zh) 点云媒体的解码方法、点云媒体的编码方法及装置

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20211115

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20221227

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230220

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230613

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230804

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20231031

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231113

R151 Written notification of patent or utility model registration

Ref document number: 7396047

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151