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

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

Info

Publication number
JPWO2020116154A1
JPWO2020116154A1 JP2020559890A JP2020559890A JPWO2020116154A1 JP WO2020116154 A1 JPWO2020116154 A1 JP WO2020116154A1 JP 2020559890 A JP2020559890 A JP 2020559890A JP 2020559890 A JP2020559890 A JP 2020559890A JP WO2020116154 A1 JPWO2020116154 A1 JP WO2020116154A1
Authority
JP
Japan
Prior art keywords
node
information
bit rate
mpd
detail
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
JP2020559890A
Other languages
English (en)
Other versions
JP7484723B2 (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
Sony Group Corp
Original Assignee
Sony Corp
Sony Group 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, Sony Group Corp filed Critical Sony Corp
Publication of JPWO2020116154A1 publication Critical patent/JPWO2020116154A1/ja
Application granted granted Critical
Publication of JP7484723B2 publication Critical patent/JP7484723B2/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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
    • G06F3/011—Arrangements for interaction with the human body, e.g. for user immersion in virtual reality
    • G06F3/013—Eye tracking input arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • 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/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/21805—Source of audio or video content, e.g. local disk arrays enabling multiple viewpoints, e.g. using a plurality of cameras
    • 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/23412—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs for generating or manipulating the scene composition of objects, e.g. MPEG-4 objects
    • 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
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • 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/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44012—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving rendering scenes according to scene graphs, e.g. MPEG-4 scene graphs
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4728—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for selecting a Region Of Interest [ROI], e.g. for requesting a higher resolution version of a selected region
    • 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • 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
    • 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
    • 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/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format
    • 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/20—Image signal generators
    • H04N13/275—Image signal generators from 3D object models, e.g. computer-generated stereoscopic image signals
    • H04N13/279—Image signal generators from 3D object models, e.g. computer-generated stereoscopic image signals the virtual viewpoint locations being selected by the viewers or determined by tracking

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Library & Information Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Graphics (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本開示は、コンテンツ再生のロバスト性を向上させることができるようにする情報処理装置および方法に関する。
３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、そのコンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する。例えば、その情報として、コンテンツの再生を制御する制御ファイルのアクセス情報を含むメタデータを生成する。本開示は、例えば、画像処理装置、画像符号化装置、または画像復号装置等に適用することができる。

Description

本開示は、情報処理装置および方法に関し、特に、コンテンツ再生のロバスト性を向上させることができるようにした情報処理装置および方法に関する。
従来、３次元空間（3D空間とも称する）の３次元オブジェクト（3Dオブジェクトとも称する）を表現する３次元コンテンツ（3Dコンテンツとも称する）の配信が提案された。また、この3Dコンテンツとしては、例えば、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能な6DoFコンテンツが提案された。
6DoFコンテンツの配信方法として、例えば、3D空間を複数の3Dオブジェクトで構成し複数のオブジェクトストリームとして伝送する方法が提案された。そして、その際、例えば、Scene Descriptionという記述法を用いることが提案された。このScene Descriptionとして、シーンをシーングラフと呼ばれるツリー階層構造のグラフで表現し、そのシーングラフをバイナリ形式またはテキスト形式で表現する方法（MPEG-4 Scene Description）が提案された（例えば、非特許文献１参照）。
"ISO/IEC 14496-11", Second Edition, 2015-05-29
しかしながら、伝送帯域に関しては、Scene Descriptionは、伝送帯域に応じてアダプティブに配信する機能を有していない。そのため、Scene Descriptionデータおよびメディアデータを伝送するだけの十分な伝送帯域が確保できる場合は再生が可能であるが、伝送帯域が限られてしまうと、クライアントはデータの取得ができず、再生ができないまたは途切れるといったことが起きるおそれがあった。
本開示は、このような状況に鑑みてなされたものであり、コンテンツ再生のロバスト性を向上させることができるようにするものである。
本技術の一側面の情報処理装置は、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する生成部を備える情報処理装置である。
本技術の一側面の情報処理方法は、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する情報処理方法である。
本技術の一側面の情報処理装置および方法においては、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、そのコンテンツの配信の際にビットレートを選択可能にする情報を含むメタデータが生成される。
シーングラフの例について説明する図である。 ノードの例について説明する図である。 ノードのシンタックスの例について説明する図である。 LODノードの例について説明する図である。 シーングラフの例について説明する図である。 配信システムの主な構成例を示すブロック図である。 ファイル生成装置の主な構成例を示すブロック図である。 クライアント装置の主な構成例を示すブロック図である。 ファイル生成処理の流れの例を説明するフローチャートである。 再生処理の流れの例を説明するフローチャートである。 Scene Descriptionの例について説明する図である。 MPDの例について説明する図である。 Scene Descriptionの例について説明する図である。 MPDの例について説明する図である。 BitWrapperノードおよびMovieTextureノードの例について説明する図である。 ファイル生成処理の流れの例を説明するフローチャートである。 再生処理の流れの例を説明するフローチャートである。 Scene Description処理の流れの例を説明するフローチャートである。 レンダリング処理の流れの例を説明するフローチャートである。 Scene Descriptionの例について説明する図である。 MPDの例について説明する図である。 Scene Descriptionの例について説明する図である。 MPDの例について説明する図である。 BitWrapperノードおよびMovieTextureノードの例について説明する図である。 Scene Descriptionの例について説明する図である。 MPDの例について説明する図である。 MPDの例について説明する図である。 BitWrapperノードおよびMovieTextureノードの例について説明する図である。 配信システムの主な構成例を示すブロック図である。 ファイル生成装置の主な構成例を示すブロック図である。 クライアント装置の主な構成例を示すブロック図である。 ファイル生成処理の流れの例を説明するフローチャートである。 再生処理の流れの例を説明するフローチャートである。 ClientSelectionノードの例について説明する図である。 Scene Descriptionの例について説明する図である。 ファイル生成処理の流れの例を説明するフローチャートである。 再生処理の流れの例を説明するフローチャートである。 Scene Description処理の流れの例を説明するフローチャートである。 BitWrapperノードおよびMovieTextureノードの例について説明する図である。 ファイル生成処理の流れの例を説明するフローチャートである。 再生処理の流れの例を説明するフローチャートである。 MPDの例について説明する図である。 MPDの例について説明する図である。 再生処理の流れの例を説明するフローチャートである。 Scene Description処理の流れの例を説明するフローチャートである。 ファイル生成処理の流れの例を説明するフローチャートである。 再生処理の流れの例を説明するフローチャートである。 ClientSelectionノードの例について説明する図である。 BitWrapperノードおよびMovieTextureノードの例について説明する図である。 ファイル生成処理の流れの例を説明するフローチャートである。 再生処理の流れの例を説明するフローチャートである。 MPDの例について説明する図である。 MPDの例について説明する図である。 再生処理の流れの例を説明するフローチャートである。 ファイル生成処理の流れの例を説明するフローチャートである。 再生処理の流れの例を説明するフローチャートである。 ClientSelectionノードの例について説明する図である。 BitWrapperノードおよびMovieTextureノードの例について説明する図である。 Qualityの種類の例について説明する図である。 MPDの例について説明する図である。 ClientSelectionノードの例について説明する図である。 BitWrapperノードおよびMovieTextureノードの例について説明する図である。 MPDの例について説明する図である。 ClientSelectionノードの例について説明する図である。 BitWrapperノードおよびMovieTextureノードの例について説明する図である。 MPDの例について説明する図である。 再生処理の流れの例を説明するフローチャートである。 ビットレート選択処理の流れの例を説明するフローチャートである。 ClientSelectionノードの例について説明する図である。 BitWrapperノードおよびMovieTextureノードの例について説明する図である。 LODノードの例について説明する図である。 ClientSelectionノードの例について説明する図である。 BitWrapperノードおよびMovieTextureノードの例について説明する図である。 LODノードの例について説明する図である。 ClientSelectionノードの例について説明する図である。 MPDの例について説明する図である。 ビットレート選択処理の流れの例を説明するフローチャートである。 ClientSelectionノードの例について説明する図である。 BitWrapperノードおよびMovieTextureノードの例について説明する図である。 Transformノードの例について説明する図である。 ビットレート選択処理の流れの例を説明するフローチャートである。 部分３Dオブジェクトの例を示す図である。 部分３DオブジェクトをシグナルするScene Descriptionの例を示す図である。 部分３DオブジェクトをシグナルするScene Descriptionの例を示す図である。 物体全体をシグナルするScene Descriptionの例を示す図である。 BitwrapperノードとMovieTextureノードの例を示す図である。 物体Ａが４つの部分３Ｄオブジェクトで構成される場合のMPDの例を示す図である。 Periodで物体を構成するAdaptationSetをシグナルするMPDの例を示す図である。 BitwrapperノードとMovieTextureノードの例を示す図である。 BitwrapperノードとMovieTextureノードの例を示す図である。 コンピュータの主な構成例を示すブロック図である。
以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．技術内容・技術用語をサポートする文献等
２．6DoFコンテンツの配信
３．第１の実施の形態（ビットレートアダプテーション）
４．第２の実施の形態（ビットレートを一律に制御するためのシグナリング）
５．第３の実施の形態（取得するビットレートの組み合わせを示すシグナリング）
６．第４の実施の形態（Level of Detailの制御によりビットレートを選択するためのシグナリング）
７．第５の実施の形態（コンテンツオーサ等の意図を示すシグナリング）
８．第６の実施の形態（注目オブジェクトのLevel of Detailを保つための実装法）
９．第７の実施の形態（部分３Ｄオブジェクトで構成される場合のシグナリング）
１０．付記
＜１．技術内容・技術用語をサポートする文献等＞
本技術で開示される範囲は、実施例に記載されている内容だけではなく、出願当時において公知となっている以下の非特許文献に記載されている内容も含まれる。
非特許文献１：（上述）
非特許文献２：R. Mekuria, Student Member IEEE, K. Blom, P. Cesar., Member, IEEE, "Design, Implementation and Evaluation of a Point Cloud Codec for Tele-Immersive Video",tcsvt_paper_submitted_february.pdf
非特許文献３：TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU（International Telecommunication Union）, "Advanced video coding for generic audiovisual services", H.264, 04/2017
非特許文献４：TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU（International Telecommunication Union）, "High efficiency video coding", H.265, 12/2016
非特許文献５：Jianle Chen, Elena Alshina, Gary J. Sullivan, Jens-Rainer, Jill Boyce, "Algorithm Description of Joint Exploration Test Model 4", JVET-G1001_v1, Joint Video Exploration Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11 7th Meeting: Torino, IT, 13-21 July 2017
つまり、上述の非特許文献に記載されている内容もサポート要件を判断する際の根拠となる。例えば、非特許文献４に記載されているQuad-Tree Block Structure、非特許文献５に記載されているQTBT（Quad Tree Plus Binary Tree） Block Structureが実施例において直接的な記載がない場合でも、本技術の開示範囲内であり、請求の範囲のサポート要件を満たすものとする。また、例えば、パース（Parsing）、シンタックス（Syntax）、セマンティクス（Semantics）等の技術用語についても同様に、実施例において直接的な記載がない場合でも、本技術の開示範囲内であり、請求の範囲のサポート要件を満たすものとする。
＜２．6DoFコンテンツの配信＞
＜２−１：コンテンツ＞
現在の映像配信においては、映画などの配信で利用されている２次元映像（2Dコンテンツとも称する）の配信が主流である。さらに、全方位が見まわし可能である360度映像配信も行われている。360度映像は、3DoF（Degree of Freedom）映像や3DoFコンテンツとも称する。2Dコンテンツ、3DoFコンテンツどちらも、基本は２次元にエンコードされた映像が配信され、クライアントで表示される。
また、3DoF+コンテンツと称するコンテンツもある。この3DoF+コンテンツは、3DoFコンテンツのように全方位の見回しが可能であり、さらに、視点位置を少し動かすことが可能であるコンテンツである。視点位置の動かせる範囲は、座っている状態で頭を動かせる程度が想定されている。3DoF+コンテンツは、２次元にエンコードされた映像を１つまたは複数使うことにより、視点位置の移動を実現している。
これに対して、全方位見回し（視線方向を自由に選択）することができ、さらに空間の中を歩いて回れる（視点位置を自由に選択することができる）6DoF映像（6DoFコンテンツとも称する）もある。6DoFコンテンツは、時刻毎に１つもしくは複数の３次元オブジェクト（3Dオブジェクトとも称する）で３次元空間（3D空間とも称する）を表現したものである。つまり、6DoFコンテンツは、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツである。
3Dオブジェクトとは、（１）3D空間内にある１つの物体、（２）（１）の物体の一部、（３）3D空間内の複数の物体の集合のいずれかを示している。3Dオブジェクトのデータとしては、多面体の形状データとして表すことのできるメッシュデータとその面に張り付けるデータであるテクスチャデータで構成する方法や、複数の点の集合で構成するもの（Point Cloud）がある。
6DoFコンテンツを伝送する方法としては、3D空間を１つの3Dオブジェクトで構成し１つのオブジェクトストリームで伝送する方法と、3D空間を複数の3Dオブジェクトで構成し複数のオブジェクトストリームで伝送する方法が考えられる。
3D空間の表現として、6DoFコンテンツを2D DisplayやHMD（Head Mounted Display）で表示する場合、視点位置から離れている物体は、表示が小さくなり、近い場合は表示が大きくなるという6DoFコンテンツの表現特性がある。表示が小さい物体は解像度が低くてもよい。しかしながら、前者のように、広い領域の6DoFコンテンツを１つのオブジェクトストリームで伝送する場合、このような表示特性に関係なく6DoFコンテンツ全体の解像度が均一となってしまう。全体の解像度が均一であるということは、表示画面をレンダリングする場合、適切な解像度である部分もあれば、不必要に高い解像度の部分が存在することになる。不必要に高い解像度の部分は、余分なデコード・レンダリング処理が必要となる。すなわち、不要に負荷が増大するおそれがあった。
後者のように、3D空間を複数の3Dオブジェクトで構成し複数のオブジェクトストリームで伝送する方法では、6DoFコンテンツを複数のオブジェクトストリームで構成し、視点位置からの距離に応じて適切に表示するための情報を示すScene Descriptionという記述法が用いられる。
このScene Descriptionの規格は、複数存在する。基本的には、シーンをシーングラフと称するツリー階層構造のグラフで表現し、そのシーングラフをバイナリ形式またはテキスト形式で表現する。ここで、シーングラフは、視点位置に基づく空間表示制御情報であり、その視点位置における3Dオブジェクトの表示に関する情報を、ノードを構成単位として定義し、複数のノードを階層的に組合せることで構成される。ノードは、3Dオブジェクトの位置情報や大きさ情報のノード、メッシュデータやテクスチャデータへのアクセス情報のノード、視点位置からの距離に応じて適切に表示するための情報などのためのノードがあり、3Dオブジェクト毎にこれらのノードを用いる。
なお、以下においては、6DoFコンテンツは、そのメタデータであるScene Descriptionデータ（Scene Descriptionのストリームデータ）と、複数の3Dオブジェクトのメディアデータ（3Dオブジェクトのメッシュデータとテクスチャデータを合わせて表現したもの）とで構成されるものとする。3DオブジェクトのメディアデータはPoint Cloudといった別の形式も適用可能である。また、Scene Descriptionデータは、MPEG-4 Scene Description（ISO/IEC 14496-11）に準拠するものとする。
MPEG-4 Scene Descriptionデータは、シーングラフをBIFS（BInary Format for Scenes）という形式でバイナリ化してものである。このシーングラフをBIFSへ変換するのは決められたアルゴリズムで可能である。また、ISO base media file formatに格納することで時刻ごとにシーンを規定することができ、動いている物体などの表現が可能である。
6DoFコンテンツを表現した場合、シーングラフは例えば、図１のようになる。図１のシーングラフ１０により表現される6DoFコンテンツには、複数の3Dオブジェクトが含まれている。図１においては、3Dオブジェクト１の構成のみが詳細に示されており（3Dオブジェクト１のTransformノード１２−１の子ノード以下が示されており）、3Dオブジェクト２乃至3Dオブジェクトｎの詳細な構成（3Dオブジェクト２のTransformノード１２−２乃至3DオブジェクトｎのTransformノード１２−ｎの子ノード以下）は、省略されている。
ルートのGroupノード１１は、子ノードとしてTransformノード１２を有する。Transformノード１２には、3Dオブジェクトの位置や大きさ等の情報がまとめられている。つまり、各Transformノード１２により、3D空間内の各3Dオブジェクトの情報がまとめられている。Transformノード１２は、子ノードとしてShapeノード１３を有する。Shapeノード１３には、その3Dオブジェクトの形状に関する情報がまとめられている。Shapeノード１３は、子ノードとして、Appearanceノード１４およびBitwrapperノード１５を有する。Appearanceノード１４には、テクスチャデータの情報がまとめられている。Bitwrapperノード１５には、メッシュデータの情報がまとめられている。Bitwrapperノード１５は、別ファイルになっているメッシュデータへのアクセス情報を有する。Appearanceノード１４は、子ノードとして、MovieTextureノード１６を有する。MovieTextureノード１６は、別ファイルになっているテクスチャデータへのアクセス情報を有する。
図２にこれらの各ノードが有する情報の例を示す。これらのノードには、情報（の種類）毎にフィールド（field）が設定され、各フィールドにそのフィールドに対応する情報が格納される。このノードのシンタックスの例を図３に示す。
Scene Descriptionの機能に、１つの3Dオブジェクトに対して複数のLevel of detailのデータをもち、表示の状態に合わせて切り替えることのできる機能がある。Level of detailとは、例えば、メッシュデータの頂点数およびテクスチャデータの解像度の内、少なくともいずれか一方が異なるデータである。例えば、メッシュデータの頂点数が多い程、または、テクスチャデータが高解像度である程、より高Level of detailである。
この機能は、3D空間の表現として、視点位置から離れている3Dオブジェクトは、2D DisplayやHMDで表示するとき、表示が小さくなり、近い場合は表示が大きくなるという6DoFコンテンツの表現特性を利用している。例えば、視点位置から近い場合は、大きく表示されることから、高Level of detailのデータ（頂点数が多いメッシュデータと、解像度の高いテクスチャデータ）を用いる必要がある。これに対して、視点位置から遠い場合は、小さく表示されることから、低Level of detailのデータ（頂点数が少ないメッシュデータと、解像度の低いテクスチャデータ）を用いれば十分である。
この機能は、Scene DescriptionのLODノードにより実現される。LODノードが有する情報の例を図４に示す。図４に示されるように、LODノード３１には、3DオブジェクトのLevel of detailを切り替えるための情報が含まれており、例えば、「距離を求めるための3Dオブジェクトの中心点」(図４のcenter field)、「視点位置と3Dオブジェクトの距離」(図４のrange field)、および「距離ごとで利用するべき3Dオブジェクトのデータ」(図４のlevel field)が含まれている。
LODノードの機能を用いることにより、視点位置に応じて3Dオブジェクトの適切なLevel of detailを選択することができ、表示品質を適切に保ちつつ、処理量を減らすことが可能になる。以下において、視点位置に応じたアダプテーションとも称する。
例えば、LODノード３１はTransformノード１２とShapeノード１３との間に配置される。LODノード３１の「距離ごとで利用するべき3Dオブジェクトのデータ」（図４のlevel field）は、選択すべきShapeノード１３にアドレスするものとなる。
LODノードを用いたシーングラフ１０の例を図５に示す。図５に示されるように、このシーングラフ１０においては、各Transformノード１２の子ノードとして、LODノード３１が設けられている。LODノード３１は、視点位置と3Dオブジェクトとの距離を用いてLevel of detailを切り替える。LODノード３１には、3Dオブジェクトとの距離を求めるために利用する中心位置の座標が記述され、距離ごとに利用する3Dオブジェクトのデータを示す、子ノードのShapeノード１３を持つ（Shapeノード１３−１乃至Shapeノード１３−３）。それぞれのShapeノード１３では、割り当てられたレベルの異なるメッシュデータとテクスチャデータへのアクセス情報を有するノードの情報が設定される。
これによって、距離が近い場合は、高Level of detailのデータを、中間距離の場合は、中Level of detailのデータを、遠い場合は、低Level of detailのデータを用いることができ、視点に応じて適切なLevel of detailのデータを用いることが可能になる。
ここで、6DoFコンテンツの配信を考える。6DoFコンテンツは、Scene Descriptionデータと、そこから参照されるメディアデータ（メッシュデータとテクスチャデータ）とを、ネットワーク経由で取得することで再生することができる。これに対して、Scene Descriptionを用いた6DoFコンテンツの再生には、以下のような前提がある。
・主に6DoFコンテンツ配信サーバがローカルにあるような、十分な伝送帯域が確保できるネットワーク環境かストレージある。
・クライアントの処理能力が十分にある。つまり、取得した全てのメッシュ・テクスチャのデコードと、表示処理（レンダリング）が決められた時間内にできる。
クライアントの処理量に関しては、視点位置に応じたアダプテーションを用いることで処理量を減らすことをScene Descriptionでは実現している。しかしながら、伝送帯域に関しては、Scene Descriptionは、伝送帯域に応じてアダプティブに配信する機能を有していない。そのため、Scene Descriptionデータおよびメディアデータを伝送するだけの十分な伝送帯域が確保できる場合は再生が可能であるが、伝送帯域が限られてしまうと、クライアントはデータの取得ができず、再生ができなかったり、途切れたりするおそれがあった。
なお、6DoFコンテンツの場合、再生時の品質の低減を抑制するために、3Dオブジェクト間の品質の相関性を維持する必要がある。したがって、仮に2Dコンテンツのようにビットレートアダプティブな配信手法を行うとしても、ビットレートを適応的に操作した場合に視点位置に応じた3Dオブジェクト間の品質の相関性を維持するための手段がなく、クライアントの状況に応じた適切な配信ができないおそれがあった。
＜２−２：コンセプト＞
そこで、Scene Descriptionを拡張し、ビットレートアダプテーションを可能にするシグナリングを行うようにする（第１の実施の形態（実施の形態１とも称する））。このようにすることにより、Scene Descriptionを用いた6DoFコンテンツ配信における伝送帯域制限による再生への影響を抑制し、コンテンツ再生のロバスト性を向上させることができる。
また、全てのメッシュ、テクスチャのビットレートを一律に下げることで品質を維持できることを示すシグナリングを追加するようにしてもよい（第２の実施の形態（実施の形態２とも称する））。このようにすることにより、クライアントがどのビットレートを選択すれば良いかが明らかになり、視点位置に最適な3Dオブジェクト間の相対的な品質を維持することができる。
さらに、各テクスチャやメッシュの、どのビットレートを同時に取得すると品質を維持できるかを示すメタ情報を追加するようにしてもよい（第３の実施の形態（実施の形態３とも称する））。このようにすることにより、ビットレートを一律に下げるビットレートアダプテーションでは3Dオブジェクト間の相対的な品質を維持することが困難な場合であっても、3Dオブジェクト間の相対的な品質を維持することができる。
また、それぞれの3DオブジェクトのLevel of detailを下げることで伝送帯域を削減するためのシグナリングを追加するようにしてもよい（第４の実施の形態（実施の形態４とも称する））。このようにすることにより、例えば、全て最低のビットレートのメッシュやテクスチャを選択しても、その合計ビットレートよりも伝送帯域の方が狭い場合であっても、再生が途切れるのを抑制することができる。
さらに、3Dオブジェクトの重要度情報のシグナリングを追加するようにしてもよい（第５の実施の形態（実施の形態５とも称する））。このようにすることにより、コンテンツオーサ等の意図において重要な3DオブジェクトのLevel of detailを維持することができる。
また、注目している3Dオブジェクトを識別して、その3DオブジェクトのLevel of detailを保つようにしてもよい（第６の実施の形態（実施の形態６とも称する））。このようにすることにより、ユーザの注目している3DオブジェクトのLevel of detailを維持することができる。
以下に、各実施の形態について説明する。なお、以下においては、Scene Descriptionとして、MPEG-4 Scene descriptionを適用して説明する。しかしながら、Scene Descriptionの規格は任意であり、例えば、VRML（Virtual Reality Modeling Language）、Open Scene Graph（http://www.openscenegraph.org/）、Universal Scene Description（https://graphics.pixar.com/usd/docs/index.html）、X3D（ISO/IEC 19775-1）、glTF（https://www.khronos.org/gltf/）等であってもよい。
＜３．第１の実施の形態（実施の形態１）＞
第１の実施の形態においては、各3DオブジェクトのLevel of detail毎にビットレートアダプテーションすることができるようにシグナリングを拡張する。例えば、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、そのコンテンツの配信の際にビットレートを選択可能にする情報を含むメタデータを生成するようにする。例えば、情報処理装置において、３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、そのコンテンツの配信の際にビットレートを選択可能にする情報を含むメタデータを生成する生成部を備えるようにする。
このようにすることにより、Scene Descriptionを用いた6DoFコンテンツ配信における伝送帯域制限による再生への影響を抑制し、コンテンツ再生のロバスト性を向上させることができる。
＜３−１：実施の形態１−１＞
コンテンツの配信の際にビットレートを選択可能にする情報として、そのコンテンツの再生を制御する制御ファイルのアクセス情報を含むメタデータを生成するようにしてもよい。つまり、例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、ビットレートアダプテーション実現するようにしてもよい。現在の2Dコンテンツや3DoFコンテンツにおいては、DASH（Dynamic Adaptive Streaming over HTTP、ISO/IEC 23009-1）を用いて、ビットレートの異なるデータに切り替えることで、伝送帯域が狭くなった際にも途切れることなく再生が可能である仕組みがある。この方法は、DASHのマニフェストファイルであるMPDファイルのAdaptationSetでビットレートの異なるデータをRepresentationでシグナリングしている。
そこで、このようなMPDで実現しているビットレートアダプテーションの仕組みを利用し、Scene Descriptionと組み合わせることで、再生の途切れ等の発生を抑制するようにする。例えば、Scene Descriptionの外部メディアデータのアクセス情報で、MPDファイルのAdaptationSetを参照することができるようにしてもよい（実施の形態１−１−１）。この場合、クライアント装置１０３は、外部メディアデータとして示されたMPDのAdaptationSetの中から、ビットレートを選択する。
Scene DescriptionにおいてLODノードが存在する場合、視点位置に応じて各3Dオブジェクトに対して適切なLevel of detailが決まる。そこで、本実施の形態１−１では、Level of detail毎にビットレートバリエーションを持つことにより、Level of detail毎にビットレートアダプテーションを可能にする。
＜配信システム＞
図６は、本技術を適用したシステムの一態様である配信システムの主な構成の一例を示すブロック図である。図６に示される配信システム１００は、6DoFコンテンツをサーバからクライアントに配信するシステムである。
図６に示されるように、この配信システム１００は、ファイル生成装置（File generation apparatus）１０１、配信サーバ（Web server）１０２、およびクライアント装置（Client apparatus）１０３を有する。配信サーバ１０２とクライアント装置１０３とは、インターネット１１０を介して接続される。なお、図６においては、各装置を１台ずつ示しているが、配信システム１００は、各装置を任意の台数有することができる。つまり、ファイル生成装置１０１、配信サーバ１０２、およびクライアント装置１０３は、それぞれ、複数台であってもよい。
ファイル生成装置１０１は、Scene Descriptionデータ（Scene Description data）１２１、MPDファイル（MPD file）１２２、およびメディアデータ（media data）１２３を生成する（メディアデータ１２３−１、メディアデータ１２３−２、・・・）。ファイル生成装置１０１は、生成したそれらのデータを配信サーバ１０２にアップロードする。
クライアント装置１０３は、Scene Descriptionデータ１２１、MPDファイル１２２、メディアデータ１２３等を配信サーバ１０２に要求し、配信させる。クライアント装置１０３は、配信されたそれらのデータを取得すると、レンダリングを行って表示用の画像を生成し、その画像をモニタ（Display）に表示させる。
＜ファイル生成装置＞
図７は、ファイル生成装置１０１の主な構成例を示すブロック図である。図７に示されるように、ファイル生成装置１０１は、制御部１５１およびファイル生成部１５２を有する。
制御部１５１は、ファイル生成部１５２の制御に関する処理を行う。ファイル生成部１５２は、制御部１５１に制御されて、Scene Descriptionデータ１２１（Scene Descriptionとも称する）、MPDファイル１２２（MPDとも称する）、およびメディアデータ１２３等のデータの生成に関する処理を行う。ファイル生成部１５２は、データ入力部１６１、Scene Description生成部１６２、メディアデータ生成部１６３、MPDファイル生成部１６４、セグメントファイル生成部１６５、記録部１６６、およびアップロード部１６７を有する。
データ入力部１６１は、データの入力を受け付ける。データ入力部１６１は、受け付けたデータを、Scene Description生成部１６２、メディアデータ生成部１６３、およびMPDファイル生成部１６４に供給する。
Scene Description生成部１６２は、Scene Descriptionデータ１２１の生成に関する処理を行う。例えば、Scene Description生成部１６２は、データ入力部１６１から供給されるデータに基づいて、Scene Descriptionデータ１２１を生成し、それをセグメントファイル生成部１６５に供給する。
メディアデータ生成部１６３は、メディアデータ１２３の生成に関する処理を行う。例えば、メディアデータ生成部１６３は、データ入力部１６１から供給されるデータに基づいて、メディアデータ１２３を生成し、それをセグメントファイル生成部１６５に供給する。
MPDファイル生成部１６４は、MPDファイル１２２の生成に関する処理を行う。例えば、MPDファイル生成部１６４は、データ入力部１６１から供給されるデータに基づいて、MPDファイル１２２を生成し、それを記録部１６６に供給する。
セグメントファイル生成部１６５は、セグメントファイルの生成に関する処理を行う。例えば、セグメントファイル生成部１６５は、Scene Description生成部１６２から供給されたScene Descriptionデータ１２１を取得し、そのScene Descriptionデータ１２１をセグメント毎にファイル化し、Scene Descriptionデータ１２１のセグメントファイル（Scene Descriptionセグメントファイルとも称する）を生成する。また、セグメントファイル生成部１６５は、メディアデータ生成部１６３から供給されたメディアデータ１２３を取得し、そのメディアデータ１２３をセグメント毎にファイル化し、メディアデータ１２３のセグメントファイル（メディアデータセグメントファイルとも称する）を生成する。セグメントファイル生成部１６５は、生成したScene Descriptionセグメントファイルやメディアデータセグメントファイルを記録部１６６に供給する。
記録部１６６は、MPDファイル生成部１６４から供給されるMPDファイル１２２、並びに、セグメントファイル生成部１６５から供給されるScene Descriptionセグメントファイルおよびメディアデータセグメントファイルを、自身が有する記録媒体に記録する。また、記録部１６６は、所定のタイミングにおいてまたはユーザ等の要求に基づいて、記録媒体に記録しているそれらのファイルを読み出し、それをアップロード部１６７に供給する。
アップロード部１６７は、記録部１６６からMPDファイル１２２、Scene Descriptionセグメントファイル、およびメディアデータセグメントファイルを取得し、それらを配信サーバ１０２にアップロードする（送信する）。
＜クライアント装置＞
図８は、クライアント装置１０３の主な構成例を示すブロック図である。図８に示されるように、クライアント装置１０３は、制御部１７１および再生処理部１７２を有する。制御部１７１は、再生処理部１７２の制御に関する処理を行う。再生処理部１７２は、制御部１７１に制御されて、6DoFコンテンツの再生に関する処理を行う。再生処理部１７２は、MPDファイル取得部１８１、MPDファイル処理部１８２、Scene Descriptionセグメントファイル取得部１８３、Scene Descriptionセグメントファイル処理部１８４、表示制御部１８５、計測部１８６、メディアデータセグメントファイル選択部１８７、メディアデータセグメントファイル取得部１８８、復号処理部１８９、表示情報生成部１９０、および表示部１９１を有する。
MPDファイル取得部１８１は、MPDファイル１２２の取得に関する処理を行う。例えば、MPDファイル取得部１８１は、配信サーバ１０２にアクセスしてMPDファイル１２２を要求し、取得する。MPDファイル取得部１８１は、取得したMPDファイル１２２をMPDファイル処理部１８２に供給する。
MPDファイル処理部１８２は、MPDファイルに関する処理を行う。例えば、MPDファイル処理部１８２は、MPDファイル取得部１８１から供給されるMPDファイル１２２を取得し、そのMPDファイルをパースし、MPDファイル１２２やそのパース結果をScene Descriptionセグメントファイル取得部１８３に供給する。
Scene Descriptionセグメントファイル取得部１８３は、Scene Descriptionセグメントファイルの取得に関する処理を行う。例えば、Scene Descriptionセグメントファイル取得部１８３は、MPDファイル処理部１８２から供給される情報（MPDファイル１２２やそのパース結果）を取得し、その情報に基づいて配信サーバ１０２にアクセスし、Scene Descriptionセグメントファイルを取得する。Scene Descriptionセグメントファイル取得部１８３は、取得したScene Descriptionセグメントファイルを、Scene Descriptionセグメントファイル処理部１８４に供給する。
Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイルに関する処理を行う。例えば、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイル取得部１８３から供給されるScene Descriptionセグメントファイルを取得する。また、Scene Descriptionセグメントファイル処理部１８４は、表示制御部１８５から視点位置を示す情報を取得する。Scene Descriptionセグメントファイル処理部１８４は、取得したそれらの情報に基づいて、MPDファイルのアクセス先を決定する。Scene Descriptionセグメントファイル処理部１８４は、その決定したアクセス先をメディアデータセグメントファイル選択部１８７に供給する。
表示制御部１８５は、6DoFコンテンツの表示制御に関する処理を行う。例えば、表示制御部１８５は、視点位置を示す情報をScene Descriptionセグメントファイル処理部１８４、メディアデータセグメントファイル選択部１８７、表示情報生成部１９０等に供給する。計測部１８６は、配信サーバ１０２からクライアント装置１０３までの伝送路の伝送帯域を計測し、その計測結果をメディアデータセグメントファイル選択部１８７に供給する。
メディアデータセグメントファイル選択部１８７は、メディアデータセグメントファイルの選択に関する処理を行う。例えば、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２において、表示制御部１８５から供給される視点位置を示す情報や、計測部１８６から供給される伝送帯域を示す情報等に基づいて、再生するメディアデータセグメントファイルを選択する。メディアデータセグメントファイル選択部１８７は、その選択結果を示す情報をメディアデータセグメントファイル取得部１８８に供給する。
メディアデータセグメントファイル取得部１８８は、メディアデータセグメントファイルの取得に関する処理を行う。例えば、メディアデータセグメントファイル取得部１８８は、メディアデータセグメントファイル選択部１８７から供給されるメディアデータセグメントファイルの選択結果を示す情報を取得する。それらの情報に基づいて、メディアデータセグメントファイル取得部１８８は、配信サーバ１０２にアクセスし、メディアデータセグメントファイル選択部１８７により選択されたメディアデータセグメントファイルを要求し、取得する。メディアデータセグメントファイル取得部１８８は、取得したメディアデータセグメントファイルを復号処理部１８９に供給する。
復号処理部１８９は、メディアデータセグメントファイル取得部１８８から供給されるメディアデータセグメントファイルを取得し、復号する。復号処理部１８９は、その復号したメディアデータセグメントファイルを表示情報生成部１９０に供給する。表示情報生成部１９０は、復号処理部１８９から供給されるメディアデータセグメントファイルに基づいてレンダリングを行い、表示用の画像を生成する。表示情報生成部１９０は、生成した表示用の画像を表示部１９１に供給し、表示させる。
＜ファイル生成処理の流れ＞
次に、ファイル生成装置１０１が実行するファイル生成処理の流れの例を、図９のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のMPDファイル生成部１６４は、ステップＳ１０１において、MPDファイル１２２を生成する。
ステップＳ１０２において、Scene Description生成部１６２は、ステップＳ１０１において生成されたMPDファイルへのリンクを含むScene Descriptionデータ１２１を生成する。
ステップＳ１０３において、メディアデータ生成部１６３は、メディアデータ１２３を生成する。
ステップＳ１０４において、セグメントファイル生成部１６５は、ステップＳ１０２において生成されたScene Descriptionデータ１２１を用いて、Scene Descriptionセグメントファイルを生成する。また、セグメントファイル生成部１６５は、ステップＳ１０３において生成されたメディアデータ１２３を用いて、メディアデータセグメントファイルを生成する。
ステップＳ１０５において、記録部１６６は、ステップＳ１０１において生成されたMPDファイル１２２を記録する。また、ステップＳ１０６において、記録部１６６は、ステップＳ１０４において生成されたセグメントファイル（Scene Descriptionセグメントファイルおよびメディアデータセグメントファイル）を記録する。
ステップＳ１０７において、アップロード部１６７は、ステップＳ１０５において記録されたMPDファイル１２２を読み出し、配信サーバ１０２にアップロードする。
ステップＳ１０８において、アップロード部１６７は、ステップＳ１０６において記録されたセグメントファイル（Scene Descriptionセグメントファイルおよびメディアデータセグメントファイル）を読み出し、配信サーバ１０２にアップロードする。
ステップＳ１０８の処理が完了すると、ファイル生成処理が終了する。
＜再生処理の流れ＞
次に、クライアント装置１０３により実行される再生処理の流れの例を、図１０のフローチャートを参照して説明する。再生処理が開始されると、MPDファイル取得部１８１は、ステップＳ１２１において、配信サーバ１０２にアクセスし、MPDファイル１２２を取得する。
ステップＳ１２２において、MPDファイル処理部１８２は、ステップＳ１２１において取得したMPDファイル１２２をパースし、Scene Descriptionデータ１２１を最初に取得することを認識し、そのScene Descriptionデータ１２１のAdaptationSetを参照し、Scene Descriptionデータ１２１のアクセス情報（URL（Uniform Resource Locator））を取得する。
ステップＳ１２３において、Scene Descriptionセグメントファイル取得部１８３は、ステップＳ１２２において取得したURLから、現在時刻に対応するScene Descriptionセグメントファイルを取得する。
ステップＳ１２４において、Scene Descriptionセグメントファイル処理部１８４は、表示制御部１８５から視点位置を示す情報を取得する。
ステップＳ１２５において、Scene Descriptionセグメントファイル処理部１８４は、ステップＳ１２３において取得したScene Descriptionデータ１２１をパースし、ステップＳ１２４において取得した情報により示される視点位置に基づいて、MPDファイル１２２内のアクセス先を決定する。
ステップＳ１２６において、計測部１８６は、配信サーバ１０２とクライアント装置１０３との間の伝送路の伝送帯域を計測する。メディアデータセグメントファイル選択部１８７は、その計測結果（つまり伝送帯域を示す情報）を取得する。
ステップＳ１２７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２において、ステップＳ１２６において取得した伝送帯域を示す情報に基づいて、メディアデータセグメントファイルを選択する。
ステップＳ１２８において、メディアデータセグメントファイル取得部１８８は、配信サーバ１０２にアクセスし、ステップＳ１２７において選択されたメディアデータセグメントファイルを取得する。
ステップＳ１２９において、復号処理部１８９は、ステップＳ１２８において取得したメディアデータセグメントファイルを復号する。そして、表示情報生成部１９０は、復号されたメディアデータセグメントファイルを用いてレンダリングを行い、表示用画像を生成する。
ステップＳ１２９の処理が終了すると再生処理が終了する。このように各処理を行うことにより、クライアント装置１０３は、コンテンツ再生のロバスト性を向上させることができる。
＜３−２：実施の形態１−１−１＞
＜Scene DescriptionとMPDの構成＞
MPDにおいて、Scene DescriptionデータのAdaptationSetと、そこから参照されるメディアデータのビットレートバリエーションのAdaptationSetをシグナリングするようにしてもよい。つまり、例えば、制御ファイルであるMPD（Media Presentation Description）の、３次元オブジェクトのLevel of Detailに対応し、そのLevel of Detailの複数のビットレートバリエーションに関する情報を含むAdaptationSetへのアクセス情報を含むメタデータを生成するようにしてもよい。
図１１は、その場合のScene Descriptionデータ１２１の例を示す。図１２は、その場合のMPDファイル１２２の例を示す。図１１および図１２において、丸囲みの数字は、各図の矢印の対応関係を示す。MPDファイル１２２（図１２）には、Scene Descriptionデータ１２１を示すためのAdaptationSetや、各3DオブジェクトのLevel of detail毎のメッシュデータとテクスチャデータを示すAdaptationSetが記述されている。例えば3DオブジェクトAの高Level of Detail AHのメッシュデータの、ビットレートバリエーションが１つのAdaptationSetに記述されている。
＜MPDのシグナリング拡張＞
図１２に示されるように、本実施の形態のMPDファイル１２２には、Scene Descriptionデータ１２１のAdaptatioSetと各メディアデータ１２３のAdaptatonSetが示される。この構成の場合、クライアント装置１０３は、最初にMPDファイル１２２を取得し、そのMPDファイル１２２を解析する。その際、Scene Descriptionデータ１２１のAdaptationSetを最初に処理する必要がある。しかしながら、既存のシグナリングでは、どのAdapttionSetを最初に処理すべきかがわからない。
そこで、（１）最初に処理すべきAdaptationSetをシグナリングする、（２）最初に処理すべきでないAdaptationSetであることをシグナリングする、（３）（１）と（２）を同時にシグナリングする、の３つの実施方法を示す。
（１）最初に処理すべきAdaptationSetをシグナリングする。
最初に処理すべきAdaptationSetを示すシグナリングのためにSupplementalPropertyを利用する。以下の例のように、schemeIdUriで、InitialSelectionを設定する。value値は設定しない。
例 :< SupplementalProperty schemeIdUri="InitialSelection" />
（２）最初に処理すべきでないAdaptationSetであることをシグナリングする。
最初に処理すべきでない各メディアデータのAdapttionSetは、Scene Descriptionデータ１２１から参照されるデータである。他から参照されるデータであり、最初に処理すべきでないことを示す。例えば、以下の例のように、各メディアデータのAdaptationSetに、EssentialPropertyを設定し、そのEssentialPropertyのschemeIdUriはExternalReferencedDataを示し、value値でどのデータから参照されているかAdaptationSet@idを示す。
例 :< EssentialProperty schemeIdUri=" ExternalReferencedData " value="AdaptationSet@id"/>
EssentialPropertyで指定することにより、既存のクライアントは、このPropertyを知らなければ単体で再生はできない。また、このPropertyがわかるクライアントも、外部から参照されるデータであることがわかるため、単体で再生しなくなる。つまり、過去互換性を持つMPDファイルとなる。
（３）（１）と（２）を同時にシグナリングする。
（１）と（２）を同時にシグナリングすることで実現する。
＜変形例＞
（１）および（２）は、以下の例のように、AdaptationSetのattributeでシグナリングするようにしてもよい。
例 :< AdaptationSet InitialSelection="TRUE" />
例 :< AdaptationSet ExternalReferencedData ="TRUE"/>
また、（２）はAdaptationSetではなく、ExternalReferencedAdaptationSetと名前を変えることで利用のされ方がいままでと違うことを示すようにしてもよい。
さらに、最初に処理すべきAdaptationSetと、処理すべきでないAdaptationSetをPreselectionで同時にシグナリングするようにしてもよい。
Preselectionは、EssentialPropertyもしくはSupplementalProperty でschemeIdURI="urn:mpeg:dash:preselection:2016"とvalue="tag, media component list"をシグナルする。media component listはspace区切りでmedia componentを複数シグナルすることができ、１つ目がmain media componentとなる。main media componentは例えばAdaptationSet@idでシグナルする。Preselectionは1decodeで処理することが前提であるが、ここでは拡張し、同時にレンダリング処理されるものを扱えるものと拡張する。
この場合、main media componentとして、Scene DescriptionのAdaptationSet@idを示し、media component listの２つ目以降にScene Descriptionから参照されるメディアデータAdaptatioSet@idを並べる。つまり、main media componentが最初に処理すべきAdaptationSetであり、２つ目以降は最初に処理すべきでないAdaptationSetとなる。この手法においては、EssentialPropertyでシグナリングする。この手法は、既存のpreselectionのschmeIdUriを使っているが、別のschmeIdUriで実現してもよい。
また、最初に処理すべきAdaptationSetと、処理すべきでないAdaptationSetをRoleでシグナリングするようにしてもよい。例えば、AdaptationSetでRole elementをシグナリングし、Role elementのvalueを設定する。RoleのSchemeIdUriで"urn:mpeg:dash:role:2018"をシグナリングする。最初に処理すべきAdaptationSetは、以下の例のように、value="initial"を指定する。
例：<Role schemeIdUri="urn:mpeg:dash:role:2018" value=" initial"/>
最初に処理すべきでないAdaptationSetは、以下の例のように、value=" ExternalReferencedData"をシグナリングする。
例：<Role schemeIdUri="urn:mpeg:dash:role:2018" value=" ExternalReferencedData"/>
＜Scene Descriptionのシグナリング拡張＞
図１１に示されるように、Scene Description１２１のメッシュ、テクスチャを示すノードであるBitwrapperノード１５、MovieTextureノード１６からMPDファイル１２２のAdaptationSetへアクセスすることができるように拡張する。
Bitwrapperノード１５、MovieTextureノード１６ではURLを用いて外部メディアデータへのアクセス情報をシグナルしている。MPEG-4 Scene Description(ISO/IEC 14496-11)のBitwrapperノード１５およびMovieTextureノード１６の構造例は、図２に示した通りである。外部メディアデータへのアクセスに使われるフィールド（field）はどちらのノードもurl fieldである。本実施の形態では、Bitwrapperノード１５およびMovieTextureノード１６のsyntaxは拡張せず、それぞれのurl fieldの表記方法を拡張する。
本実施の形態では、url fieldで示すURLをMPDファイル１２２へのURLに加えてURLパラメータでAdaptationSet@idをシグナリングし、Level of Detail違いのメディアデータを示す。具体的には、例えばAdaptationSetを表すURLパラメータの変数"AS"を用い、その値でAdaptationSet@idをシグナリングする。例えば、AdaptationSet@id=1のAdaptationSetを示す場合は、以下の例のようにURLパラメータのついたURLをノードのURLに指定する。
URLの例：http://www.6dofserver.com/6dof.mpd?AS=1
既存の手法ではurlでは１つのメディアデータを示すために利用していたが、本手法により、複数のメディアデータの集合を示すことができるようにする。これにより、クライアントは示された複数のメディアデータの集合から、ビットレートを選択することができる。
図１１の例でのScene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLの記述例を図１３に示し、図１２の例のMPDファイル１２２の記述の例を図１４に示す。この場合、MPDファイル１２２のシグナリング拡張は、上述の（２）を用いている。このような記述により、Scene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLから、MPDファイル１２２のAdaptationSetへのリンクを示すことができる。
＜変形例＞
なお、URLパラメータで指定するのではなく、Scene Descriptionデータ１２１のBitwrapperノード１５やMovieTextureノード１６に、AdaptationSet@idを示すfieldを追加する拡張をしてもよい。この場合、url fieldは、MPDファイル１２２へのアクセス情報を記述する。
また、以上においてはBitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。また、url fieldではなく、メディアデータのアクセス情報のリストを示しているurlを示すlistUrl fieldを追加し、MPDファイル１２２のURLを記述するようにしてもよい。この場合、URLパラメータ付きURLを格納してもよいし、図１５に示されるように、MPDファイル１２２へのURLだけを示し、AdaptatonSet@idは別のfieldとしてもよい。
＜ファイル生成処理の流れ＞
次に、この場合のファイル生成処理の流れの例を、図１６のフローチャートを参照して説明する。
ファイル生成処理が開始されると、ファイル生成装置１０１のMPDファイル生成部１６４は、ステップＳ１４１において、Scene DescriptionのAdaptationSetと、ビットバリエーション毎のRepresentationを有するLevel of Detail毎のAdaptationSetとを含むMPDファイル（図１２や図１４の例のようなMPDファイル）を生成する。
ステップＳ１４２において、Scene Description生成部１６２は、Level of Detailのビットバリエーション毎のMPDのAdaptationSetへのリンクを含むScene Descriptionデータ（図１１や図１３の例のようなMPDファイル）を生成する。
ステップＳ１４３乃至ステップＳ１４８の各処理は、ステップＳ１０３乃至ステップＳ１０８（図９）の各処理と同様に実行される。ステップＳ１４８の処理が終了すると、ファイル生成処理が終了する。
以上のようにファイル生成処理を実行することにより、ファイル生成装置１０１は、配信の際の適応的なビットレート制御を可能にする（ビットレートアダプテーションを実現する）ことができる。したがって、ファイル生成装置１０１は、コンテンツ再生のロバスト性を向上させることができる。
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図１７のフローチャートを参照して説明する。再生処理が開始されると、ステップＳ１６１乃至ステップＳ１６４の各処理が、ステップＳ１２１乃至ステップＳ１２４（図１０）の各処理と同様に実行される。
ステップＳ１６５において、Scene Descriptionセグメントファイル処理部１８４は、Scene Description処理を実行し、MPDのアクセス先（AdaptationSet）を決定する。
ステップＳ１６６において、計測部１８６は、配信サーバ１０２とクライアント装置１０３との間の伝送路の伝送帯域を計測する。メディアデータセグメントファイル選択部１８７は、その計測結果（つまり伝送帯域を示す情報）を取得する。
ステップＳ１６７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２の、各3Dオブジェクトの所望のLevel of Detailに対応するAdaptationSetのそれぞれにおいて、Representationを選択する。その際、メディアデータセグメントファイル選択部１８７は、取得する全セグメントファイルのビットレートの合計がステップＳ１６６において取得した伝送帯域より小さくなるように、Representationを選択する。
ステップＳ１６８において、メディアデータセグメントファイル取得部１８８は、配信サーバ１０２にアクセスし、ステップＳ１６７において選択されたRepresentationにより指定されるメディアデータセグメントファイル（全ての3Dオブジェクトのメッシュファイルおよびテクスチャファイル）を取得する。
ステップＳ１６９において、復号処理部１８９は、ステップＳ１６８において取得したメディアデータセグメントファイルを復号する。そして、表示情報生成部１９０は、復号されたメディアデータセグメントファイルを用いてレンダリング処理を行い、表示用画像を生成する。ステップＳ１６９の処理が終了すると、再生処理が終了する。
＜Secene Description処理の流れ＞
次に、図１７のステップＳ１６５において実行されるScene Description処理の流れの例を、図１８のフローチャートを参照して説明する。
Scene Description処理が開始されると、Scene Descriptionセグメントファイル処理部１８４は、ステップＳ１８１において、Scene Descriptionデータ１２１について、RootのGroupノード１１を取得し、全ての子ノード（Transformノード１２）を取得する。
ステップＳ１８２において、Scene Descriptionセグメントファイル処理部１８４は、RootのGroupノード１１について、未処理の子ノード（Transformノード１２）が存在するか否かを判定する。存在すると判定された場合、処理はステップＳ１８３に進む。
ステップＳ１８３において、Scene Descriptionセグメントファイル処理部１８４は、未処理のTransformノード１２を処理対象として選択し、その処理対象のTransformノード１２を処理する。この処理により、レンダリングする位置や大きさが決まる。
ステップＳ１８４において、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionデータ１２１について、Transformノード１２の子ノードのLODノード３１を取得する。
ステップＳ１８５において、Scene Descriptionセグメントファイル処理部１８４は、そのLODノード３１の中心座標パラメータと視点位置の距離を求める。
ステップＳ１８６において、Scene Descriptionセグメントファイル処理部１８４は、そのLODノード３１の距離パラメータと求めた距離とを比較し、処理する子ノードを決定する。
ステップＳ１８７において、Scene Descriptionセグメントファイル処理部１８４は、決定した子ノードを取得して、メッシュファイルおよびテクスチャファイルのアクセス情報（例えばURL）からMPDのAdaptationSetを取得する。
ステップＳ１８７の処理が終了すると、処理はステップＳ１８２に戻り、それ以降の処理が繰り返される。つまり、ステップＳ１８２乃至ステップＳ１８７の各処理が、各Transformノード１２について実行される。
ステップＳ１８２において、未処理のTransformノードが存在しないと判定された場合、処理は、ステップＳ１８８に進む。ステップＳ１８８において、Scene Descriptionセグメントファイル処理部１８４は、利用する全てのAdaptationSetを決定する。ステップＳ１８８の処理が終了すると、Scene Description処理が終了し、処理は図１７に戻る。
＜レンダリング処理の流れ＞
次に、図１７のステップＳ１６９において実行されるレンダリング処理の流れの例を、図１９のフローチャートを参照して説明する。
レンダリング処理が開始されると、表示情報生成部１９０は、ステップＳ２０１において、Scene Descriptionデータ１２１の情報を利用して取得した各3Dオブジェクトのメッシュファイルおよびテクスチャファイルのデータを用いて、シーンを構成する。
ステップＳ２０２において、表示情報生成部１９０は、そのシーンの各3Dオブジェクトを、視点位置、視線方向、および画角に基づいてレンダリングし、表示用画像を生成する。ステップＳ２０２が終了すると、レンダリング処理が終了し、処理は図１７に戻る。
以上のように、各処理を実行することにより、クライアント装置１０３は、配信の際の適応的なビットレート制御を可能にする（ビットレートアダプテーションを実現する）ことができる。したがって、ファイル生成装置１０１は、コンテンツ再生のロバスト性を向上させることができる。
＜３−３：実施の形態１−１−２＞
＜Scene DescriptionとMPDの構成＞
MPDのAdaptationSetの構成は任意であり、実施の形態１−１−１の例に限定されない。例えば、同じ3DオブジェクトのメッシュデータはMPDの１つのAdaptationSetでシグナリングするようにしてもよい。同様に、同じ3DオブジェクトのテクスチャデータはMPDの１つのAdaptationSetでシグナリングするようにしてもよい。つまり、１つの3Dオブジェクトの全てのLevel of Detailのビットレートバリエーションがメッシュとテクスチャそれぞれ１つのAdaptationSetに含まれるようにしてもよい。なお、この場合もMPDシグナリング拡張は、上述の実施の形態１−１−１の場合と同様である。換言するに、制御ファイルであるMPDの、３次元オブジェクトに対応するAdaptationSetの、その３次元オブジェクトのLevel of Detailに対応し、そのLevel of Detailの複数のビットレートバリエーションに関する情報を含むrepresentationへのアクセス情報を含むメタデータを生成するようにしてもよい。
図２０は、この場合のScene Descriptionデータ１２１の例を示す。図２１は、この場合のMPDファイル１２２の例を示す。図２０および図２１において、丸囲みの数字は、各図の矢印の対応関係を示す。
この場合、MPDファイル１２２（図２１）には、Scene Descriptionデータ１２１のAdaptationSet、各3Dオブジェクトのメッシュデータとテクスチャデータ毎のAdaptationSetとが記述されている。例えば、図２０および図２１に示されるように、3DオブジェクトAの高Level of Detail AH、中Level of Detail AM、低Level of Detail ALのメッシュデータのビットレートバリエーションが１つのAdaptationSetに記述される。
＜３−４：実施の形態１−１−２−１＞
以上のようなMPDファイル１２２およびScene Descriptionデータ１２１の構成を、Scene Descriptionデータ１２１を拡張することで実現するようにしてもよい。例えば、所望のMPDのアクセス情報、そのMPD内の所望のAdaptationSetを指定する情報、およびそのAdaptationSet内の所望のRepresentationを指定する情報からなるアクセス情報を含むメタデータを生成するようにしてもよい。
＜Scene Descriptionのシグナリング＞
図２０および図２１を参照して説明した構成において、Scene Descriptionデータ１２１のメッシュを示すノードであるBitwrapperノード１５や、テクスチャを示すノードであるMovieTextureノード１６の、Level of detailに含まれるビットレートバリエーションは、MPDファイル１２２のそれぞれのAdaptationSet内のいくつかのRepresentationになる。
そこで、Scene Descriptionデータ１２１のBitwrapperノード１５やMovieTextureノード１６において、アクセス情報（例えばURL）により、ビットレートバリエーションである、MPDファイル１２２のRepresentationをシグナリングするようにしてもよい。
より具体的には、Representationを表すURLパラメータの変数である"RS"とその値によりRepresentation@idが示されるようにする。Bitwrapperノード１５やMovieTextureノード１６においては、ビットレートバリエーションの数のRepresentation@idを記述することができる。例えば、Representation@id=1、Representation@id=2、Representation@id=3があるLevel of detailに含まれるメッシュのビットレートバリエーションを示す場合は、以下の例のようにURLパラメータのついたURLを、アクセス情報として、Bitwrapperノード１５やMovieTextureノード１６に記述する。
URLの例：http://www.6dofserver.com/6dof.mpd?RS=1&RS=2&RS=3
図２０のScene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLの記述例を図２２に示す。また、図２１のMPDファイル１２２の記述例を、図２３に示す。図２２および図２３において、丸囲みの数字は、各図の矢印の対応関係を示す。
これらの図に示されるように、Scene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６において、変数RSの値として、AHm-n、AHt-m（n, mは、任意の自然数）を記述することにより、そのノードを、MPDファイル１２２の3Dオブジェクトに対応するAdaptationSetの、その値のRepresentationidを有するRepresentationに紐づけることができる。つまり、Scene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLのフィールドにおいて、MPDファイル１２２のビットレートバリエーションの数のRepresentationへのリンクを示すことができる。
＜変形例＞
なお、URLパラメータでAdaptationSetの@idも同時にシグナリングするようにしてもよい。シグナリングの仕方は、実施の形態１−１−１において上述したのと同様である。
また、URLパラメータで指定するのではなく、例えば図２４に示されるように、Scene Descriptionデータ１２１のBitwrapperノード１５やMovieTextureノード１６において、Representation@idを示すフィールド（field）を拡張するようにしてもよい。この場合、url fieldには、MPDファイル１２２へのアクセス情報が記述される。
さらに、AdaptationSet@idを示すfieldを追加する拡張をしてもよい。また、以上においては、Bitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードにおいて、これらと同様にfieldを拡張するようにしてもよい。
また、url fieldではなく、メディアデータのアクセス情報のリストを示しているurlを示すlistUrl fieldを追加し、MPDのURLを記述するようにしてもよい。この場合、URLパラメータ付きURLを格納してもよいし、MPDファイル１２２へのURLだけを示し、Representation@idは別のfieldとするようにしてもよい。
＜３−５：実施の形態１−１−２−２＞
また、MPDファイル１２２も拡張するようにしてもよい。例えば、MPDファイル１２２において、互いに同一のLevel of DetailのRepresentationをグルーピングし、Scene Descriptionデータ１２１のBitwrapperノード１５およびMovieTextureノード１６に記述されるアクセス情報が、そのグループを示すようにしてもよい。つまり、互いに同一のビットレートバリエーションをグループ化する情報を含むMPDを生成するようにしてもよい。このようにすることにより、実施の形態１−１−２−１の場合と比較して、Scene Descriptionデータ１２１に記述されるメディアデータのURLのURLパラメータを、ビットレート数によらず、一定にすることができる。またScene Descriptionデータ１２１を作成した後に、ビットレートバリエーションを増大させる場合に、Scene Descriptionデータ１２１のシグナリングに影響が出ないようにすることができる。
＜MPDのシグナリング＞
MPDファイル１２２のRepresentationをグルーピングし、Scene Descriptionデータ１２１のLevel of detailで利用するビットレートバリエーションがわかるシグナリングをする。
そのために、以下の例のように、Level of detailで利用するビットレートバリエーションは、同じValue値を持つSupplementalPropertyをRepresentationにシグナリングするようにする。
例 :<SupplementalProperty schemeIdUri="RepresentationGroup" value="1"/>
このSupplementalPropertyにおいて、schemeIdUriでRepresentationGroupを示し、value値でグループ番号を示す。同じAdaptationSetに含まれ、同じValue値を持つRepresentaitonが、同一のグループに属していることを示す。
＜変形例＞
なお、上述の例では、RepresentationGroupが何のGroupであるかがわからないので、value値をコンマ区切りにして、"group番号, グループ種類"として、グループの種類も同時にシグナリングするようにしてもよい。以下にその例を示す。この例において、"LOD"は、Level of detailのグループであることを示す。
例 : <SupplementalProperty schemeIdUri="RepresentationGroup" value="1, LOD"/>
＜Scene Descriptionのシグナリング＞
また、Scene Descriptionデータ１２１においては、Bitwrapperノード１５およびMovieTextureノード１６のアクセス情報（URL）により上述のRepresentationのグループを示すようにする。ただし、どのAdaptationSetに含まれるRepresentationのグループかわからないので、AdaptationSetも同時に示すようにする。
MPDファイル１２２のURLパラメータに、AdaptationSetを示すパラメータと、RepresentationGroupを示すパラメータをシグナルする。AdaptationSetを示すパラメータは、実施の形態１−１−１において上述したものと同じである。RepresentationGroupを示すパラメータとしては、変数であるReplesentationGroupを与え、その値には、MPDファイル１２２のRepresentationGroupのvalueをシグナリングするようにする。以下にそのURLの例を示す。
URLの例：http://www.6dofserver.com/6dof.mpd?AS=1&ReplesentationGroup=1
図２０のScene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLの記述例を図２５に示す。また、図２１のMPDファイル１２２の記述例を、図２６に示す。図２５および図２６において、丸囲みの数字は、各図の矢印の対応関係を示す。
このように記述することにより、Scene Descriptionデータ１２１のBitwrapperノード１５とMovieTextureノード１６のURLから、MPDファイル１２２のAdaptationSetおよびその中のLevel of DetailのビットレートバリエーションのRepresentationの集合を示す、RepresentationGroupへのアクセス情報を示すことができる。
＜変形例＞
以上においては、シグナリングを各Representationに行うように説明したが、AdaptationSetにシグナリングしてもよい。その場合、例えば、schmeIdUriでReplesentationGroupを示すようにしてもよい。グルーピング情報は、グループ毎にSupplementalPropertyのエレメント（element）としてRepresentationGroupを新しく追加する。RepresentationGroupは、id（RepresentationGroupのvalueと同じ意味）と、グループに含まれるRepresentationのidのリストから成る。以下にその例を示す。
<SupplementalProperty schemeIdUri=" ReplesentationGroup " >
<RepresentationGroup id=1 member="representaiton@id1 representation@id2..."/>
< RepresentationGroup id=2 member=" epresentaiton@id4 representation@id5..."/>
</SupplementalProperty>
この場合のMPDファイル１２２の記述例を図２７に示す。図２７の例においては、MPDファイル１２２において上述の例のような記述がされ、RepresentationGroup id=1は、高Level of Detailのビットバリエーションのグループに紐づけられている。
なお、Scene Descriptionデータ１２１のurlのURLパラメータで指定するのではなく、例えば、図２８に示されるように、Bitwrapperノード１５やMovieTextureノード１６において、AdaptationSet@idとRepresentationGroupを示すfieldを拡張するようにしてもよい。この場合、url fieldは、MPDファイル１２２へのアクセス情報が記述される。
また、以上においては、Bitwrapperノード１５やMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。さらに、url fieldではなく、メディアデータのアクセス情報のリストを示しているurlを示すlistUrl fieldを追加し、MPDファイル１２２のURLを記述するようにしてもよい。
＜３−６：実施の形態１−１−３＞
＜起点をScene Descriptionにする＞
実施の形態１−１−１および実施の形態１−１−２においては、最初にMPDファイル１２２を取得し、その後Scene Descriptionデータ１２１を取得し、視点に応じた適切な構成を選択し、さらにその後にMPDファイル１２２のAdaptationSetからビットレートを選択するように説明した。すなわち、最初にMPDファイル１２２を取得しているので、処理の起点がMPDファイル１２２になっている。
この処理の起点をScene Descriptionデータ１２１にするようにしてもよい。その場合、それ以降の処理は、実施の形態１−１−１または実施の形態１−１−２において説明したのと同様である。つまり、最初に取得するファイルがScene Descriptionデータ１２１になり、視点に応じた適切な構成を選択した後に、MPDファイル１２２を取得し、指示されているAdaptationSetからビットレートを選択することになる。その場合、例えば、図１４のMPDファイル１２２の、下記の部分（すなわち、Scene Descriptionデータ１２１のAdaptationSet）が不要になる。つまり、メタデータへのアクセス情報を含まないMPDを生成するようにしてもよい。
<AdaptationSet id="0" > // Scene Description
<Representation id="sd" bandwidth="500000"><BaseURL> SD.mp4 </BaseURL></Representation>
</AdaptationSet>
また、各メディアデータのAdaptationSetにシグナリングされる、< EssentialProperty schemeIdUri=" ExternalReferencedData " value="AdaptationSet@id"/>のvalue値のシグナリングが不要になる。
＜３−７：実施の形態１−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
実施の形態１−１においては、Scene Descriptionデータ１２１およびMPDファイル１２２を用いてビットレートアダプテーションを実現する場合について説明したが、Scene Descriptionデータ１２１を拡張することでビットレートアダプテーションを実現するようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。換言するに、メタデータは、コンテンツの、視点位置に基づく空間表示制御情報であり、そのコンテンツの配信の際にビットレートを選択可能にする情報をノードとして有する視点位置に基づく空間表示制御情報を生成するようにしてもよい。
＜Scene Descriptionの拡張＞
既存のScene Descriptionデータ１２１の場合、図５に示されるように、3DオブジェクトのLevel of detail毎にBitwrapperノード１５とMovieTextureノード１６がそれぞれ１つずつシグナルすることができるのみであり、各Level of detailにおいて、複数のBitwrapperノード１５とMovieTextureノード１６をシグナルすることができない。つまり、ビットバリエーションをもつことができない。
そこで、メッシュデータおよびテクスチャデータ毎に複数のビットレートのデータから選択できるようにScene Descriptionデータ１２１を拡張する。
＜配信システム＞
この場合の配信システム１００の構成は、図２９に示されるように、図６の例と同様である。ただし、ファイル生成装置１０１は、Scene Descriptionデータ１２１やメディアデータ１２３を生成するが、MPDファイル１２２は、生成しない。したがって、配信サーバ１０２もMPDファイル１２２をクライアント装置１０３に供給しない。クライアント装置１０３は、配信サーバ１０２よりScene Descriptionデータ１２１を取得し、そのScene Descriptionデータ１２１に基づいて、メディアデータを配信サーバ１０２から取得し、再生する。
＜ファイル生成装置＞
この場合のファイル生成装置１０１の主な構成例を図３０に示す。図３０に示されるように、この場合のファイル生成装置１０１は、図７の場合と同様に、制御部１５１およびファイル生成部１５２を有する。
ただし、ファイル生成部１５２は、データ入力部１６１、Scene Description生成部１６２、メディアデータ生成部１６３、セグメントファイル生成部１６５、記録部１６６、およびアップロード部１６７を有する。つまり、図７の場合と比べて、MPDファイル生成部１６４が省略される。
記録部１６６は、セグメントファイル生成部１６５から供給されるScene Descriptionセグメントファイルおよびメディアデータセグメントファイルを、自身が有する記録媒体に記録する。また、記録部１６６は、所定のタイミングにおいてまたはユーザ等の要求に基づいて、記録媒体に記録しているそれらのセグメントファイルを読み出し、それをアップロード部１６７に供給する。
アップロード部１６７は、記録部１６６からScene Descriptionセグメントファイルおよびメディアデータセグメントファイルを取得し、それらを配信サーバ１０２にアップロードする（送信する）。
＜クライアント装置＞
この場合のクライアント装置１０３の主な構成例を図３１に示す。図３１に示されるように、この場合のクライアント装置１０３は、図８の場合と同様に、制御部１７１および再生処理部１７２を有する。
ただし、再生処理部１７２は、Scene Descriptionセグメントファイル取得部１８３、Scene Descriptionセグメントファイル処理部１８４、表示制御部１８５、計測部１８６、メディアデータセグメントファイル取得部１８８、復号処理部１８９、表示情報生成部１９０、および表示部１９１を有する。つまり、図８の場合と比べて、MPDファイル取得部１８１、MPDファイル処理部１８２、およびメディアデータセグメントファイル選択部１８７が省略される。
Scene Descriptionセグメントファイル取得部１８３は、配信サーバ１０２にアクセスし、6DoFコンテンツおよび視点位置に対応するScene Descriptionセグメントファイルを取得し、それをScene Descriptionセグメントファイル処理部１８４に供給する。つまり、Scene Descriptionセグメントファイル取得部１８３は、MPDファイル１２２無しにScene Descriptionセグメントファイルを取得する。
Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイル、視点位置、伝送帯域等の情報に基づいて、再生するメディアデータセグメントファイルを選択する。Scene Descriptionセグメントファイル処理部１８４は、その決定したメディアデータセグメントファイルのアクセス先をメディアデータセグメントファイル取得部１８８に供給する。
メディアデータセグメントファイル取得部１８８は、配信サーバ１０２にアクセスし、Scene Descriptionセグメントファイル処理部１８４により選択されたメディアデータセグメントファイルを要求して取得し、復号処理部１８９に供給する。
＜ファイル生成処理の流れ＞
次に、この場合のファイル生成処理の流れの例を、図３２のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のScene Description生成部１６２は、ステップＳ２２１において、Level of Detailのビットバリエーション毎のメディアデータへのリンクを含むScene Descriptionを生成する。
ステップＳ２２２乃至ステップＳ２２５の各処理は、ステップＳ１０３、ステップＳ１０４、ステップＳ１０６、およびステップＳ１０８の各処理と同様に実行される。ステップＳ１０８の処理が完了すると、ファイル生成処理が終了する。
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図３３のフローチャートを参照して説明する。再生処理が開始されると、Scene Descriptionセグメントファイル取得部１８３は、ステップＳ２４１において、現在時刻の、Level of Detailのビットバリエーション毎のメディアデータへのリンクを含むScene Descriptionを取得する。
ステップＳ２４２において、Scene Descriptionセグメントファイル処理部１８４は、表示制御部１８５から視点位置を示す情報を取得する。ステップＳ２４３において、Scene Descriptionセグメントファイル処理部１８４は、その情報により示される視点位置に基づいて、Level of Detailを選択する。
ステップＳ２４４において、計測部１８６は、配信サーバ１０２とクライアント装置１０３との間の伝送路の伝送帯域を計測する。Scene Descriptionセグメントファイル処理部１８４は、その計測結果（つまり伝送帯域を示す情報）を取得する。
ステップＳ２４５において、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイルにおいて、ステップＳ２４４において取得した伝送帯域を示す情報に基づいて、ノードを選択する。
ステップＳ２４６において、メディアデータセグメントファイル取得部１８８は、配信サーバ１０２にアクセスし、ステップＳ２４５において選択されたノードのメッシュファイルまたはテクスチャファイルを取得する。
ステップＳ２４７において、復号処理部１８９は、ステップＳ２４６において取得したメディアデータセグメントファイルを復号する。そして、表示情報生成部１９０は、復号されたメディアデータセグメントファイルを用いてレンダリングを行い、表示用画像を生成する。
ステップＳ２４７の処理が終了すると再生処理が終了する。このように各処理を行うことにより、クライアント装置１０３は、コンテンツ再生のロバスト性を向上させることができる。
＜３−８：実施の形態１−２−１＞
＜新しいノードを定義する＞
Scene Descriptionデータ１２１を拡張するにあたって、既存のノードはそのまま利用し、ビットレートアダプテーションのために新しいノードを追加するようにしてもよい。つまり、３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現する専用のノードを含む視点位置に基づく空間表示制御情報を生成するようにしてもよい。
＜Scene Descriptionのシグナリング＞
例えば、複数のノードからクライアントが選択をすることができることを示す、ClientSelectionノードを新たに定義するようにしてもよい。ClientSelectionノードは、複数のノードとそれぞれのノードで示されるデータのビットレートをシグナリングすることができるノードである。そのClientSelectionノードの例を図３４に示す。
図３４に示されるように、ClientSelectionノード３０１は、複数の子ノードを示すSelectionNode fieldと、それぞれの子ノードのビットレートを示すbitrate fieldを有する。つまり、SelectionNode fieldには、子ノードのリストが記述され、bitrate fieldには、各子ノードのビットレートのリストが記述される。両フィールドのリストの順は対応しており、SelectionNode fieldのn番目の子ノードのビットレート情報は、bitrate fieldのn番目のビットレート情報で示される。
このようなClientSelectionノード３０１を利用して複数のビットレートから選択をできるようにしたScene Descriptionデータ１２１のシーングラフの例を図３５に示す。図３５においては、3DオブジェクトAの高Level of Detailに関してのみビットレートバリエーションのグラフのみが示されている。その他のLevel of Detail、3Dオブジェクトも同様のため、省略している。
図３５の3DオブジェクトAの高Level of Detailのメッシュデータでは、Shapeノード１３−１の子ノードをClientSelectionノード３０１−１としている。そのClientSelectionノード３０１−１は、17Mbps、15Mbps、13MbpsのビットレートバリエーションのBitwrapperノード１５（Bitwrapperノード１５−１−１、Bitwrapperノード１５−１−２、Bitwrapperノード１５−１−３）を子ノードとしている。テクスチャデータのビットレートバリエーションは、Appearanceノードの子ノードをClientSelectionノード３０１−２としている。そのClientSelectionノード３０１−２は、17Mbps、15Mbps、13MbpsのビットレートバリエーションのMovieTextureノード１６（MovieTextureノード１６−１−１、MovieTextureノード１６−１−２、MovieTextureノード１６−１−３）を子ノードとしている。
以上のように、ClientSelectionノード３０１を用いることにより、メッシュデータやテクスチャデータの複数のビットレートバリエーションを、その子ノードとして表現することができる。したがって、その各子ノードにより、各ビットレートバリエーションのメディアデータへのアクセス情報を記述することができるので、このようなClientSelectionノード３０１を用いたScene Descriptionデータを用いることにより、配信における適応的なビットレートの制御（配信のビットレートアダプテーション）を実現することができる。つまり、伝送帯域幅が狭くなることによる再生の途切れの発生等を抑制することができ、コンテンツ再生のロバスト性を向上させることができる。
＜ファイル生成処理の流れ＞
次に、この場合のファイル生成処理の流れの例を、図３６のフローチャートを参照して説明する。
ファイル生成処理が開始されると、ファイル生成装置１０１のScene Description生成部１６２は、ステップＳ２６１において、上述のようなClientSelectionノード３０１を含むScene Descriptionデータ１２１を生成する。
ステップＳ２６２乃至ステップＳ２６５の各処理は、ステップＳ２２２乃至ステップＳ２２５の各処理と同様に実行される。ステップＳ２６５の処理が終了すると、ファイル生成処理が終了する。
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図３７のフローチャートを参照して説明する。再生処理が開始されると、Scene Descriptionセグメントファイル取得部１８３は、ステップＳ２８１において、現在時刻の、ClientSelectionノード３０１を含むScene Descriptionデータ１２１を取得する。ステップＳ２８２の処理は、ステップＳ２４２の処理（図３３）と同様に実行される。
ステップＳ２８３において、Scene Descriptionセグメントファイル処理部１８４は、ステップＳ２８２において取得した情報に基づいてScene Description処理を実行し、メッシュデータやテクスチャデータのビットレートバリエーションを決定する。
ステップＳ２８４の処理は、ステップＳ２４４の処理（図３３）と同様に実行される。
ステップＳ２８５において、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイルにおいて、利用するLevel of Detailのメッシュファイルおよびテクスチャファイルのビットレートバリエーション（ClientSelectionノードの子ノード）を選択する。その際、Scene Descriptionセグメントファイル処理部１８４は、取得する全セグメントファイルのビットレートの合計がステップＳ２８４において取得した伝送帯域より小さくなるような子ノードを選択する。
ステップＳ２８６の処理は、ステップＳ２４６の処理（図３３）と同様に実行される。
ステップＳ２８７において、復号処理部１８９は、ステップＳ２８６において取得したメディアデータセグメントファイル（メッシュファイルやテクスチャファイル）を復号する。そして、表示情報生成部１９０は、復号されたメディアデータセグメントファイルを用いてレンダリング処理を行い、表示用画像を生成する。このレンダリング処理は、図１９のフローチャートを参照して説明した場合と同様に実行される。ステップＳ２８７の処理が終了すると、再生処理が終了する。
このように各処理を行うことにより、クライアント装置１０３は、コンテンツ再生のロバスト性を向上させることができる。
＜Secene Description処理の流れ＞
次に、図３７のステップＳ２８３において実行されるScene Description処理の流れの例を、図３８のフローチャートを参照して説明する。
Scene Description処理が開始されると、ステップＳ３０１乃至ステップＳ３０６の各処理が、ステップＳ１８１乃至ステップＳ１８６の各処理と同様に実行される。
ステップＳ３０７において、Scene Descriptionセグメントファイル処理部１８４は、決定した子ノードを取得して、ClientSelectionノード３０１から、メッシュファイルおよびテクスチャファイルのノードのバリエーションをリストする。
ステップＳ３０７の処理が終了すると、処理はステップＳ３０２に戻り、それ以降の処理が繰り返される。つまり、ステップＳ３０２乃至ステップＳ３０７の各処理が、各Transformノード１２について実行される。
ステップＳ３０２において、未処理のTransformノードが存在しないと判定された場合、処理はステップＳ３０８に進む。
ステップＳ３０８において、Scene Descriptionセグメントファイル処理部１８４は、利用する全てのLevel of Detailのメッシュファイルとテクスチャファイルのバリエーションを決定する。ステップＳ３０８の処理が終了すると、Scene Description処理が終了し、処理は図３７に戻る。
以上のように、各処理を実行することにより、クライアント装置１０３は、配信の際の適応的なビットレート制御を可能にする（ビットレートアダプテーションを実現する）ことができる。したがって、ファイル生成装置１０１は、コンテンツ再生のロバスト性を向上させることができる。
＜３−９：実施の形態１−２−２＞
＜既存のノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。例えば、３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現するフィールドが追加されたノードを含む視点位置に基づく空間表示制御情報を生成するようにしてもよい。
＜Scene Descriptionのシグナリング＞
例えば、既存のBitwrapperノード１５およびMovieTextureノード１６で複数のアクセス情報をリストし、それぞれのアクセス情報のビットレートを指定できるように拡張してもよい。その場合のBitwrapperノード１５およびMovieTextureノード１６の例を図３９に示す。この場合、Bitwrapperノード１５は、url fieldをurllist fieldに拡張し、複数のメッシュデータファイルを指定できるようになされている。それぞれのurllistで示されるメッシュデータファイルのビットレートは、bitrate fieldで示されている。urllist fieldのn番目に示されるurlのメッシュデータファイルのビットレートは、bitrate fieldのn番目のビットレート情報で示される。
同様にMovieTextureノード１６は、url fieldをurllist fieldに拡張し、複数のテクスチャデータファイルを指定できるようになされている。それぞれのurllistで示されるテクスチャデータファイルのビットレートがbitrate fieldで示されている。
上述の拡張したノードのシーングラフは図５と同様である。ただし、この場合、Bitwrapperノード１５およびMovieTextureノード１６からビットレートの異なるメディアデータにアクセスすることができる。なお、Bitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
＜４．第２の実施の形態（実施の形態２）＞
＜ビットレートを一律に下げるためのシグナリング＞
さらに、全てのメッシュ、テクスチャのビットレートを一律に下げることで品質を維持できることを示すシグナリングを追加するようにしてもよい。換言するに、全ての３次元オブジェクトのビットレートを一律に制御することで品質の維持が可能であることを示す情報をさらに含むメタデータを生成するようにしてもよい。
帯域幅が十分でない場合、各メッシュとテクスチャのビットレートをより下げたセグメントファイルを取得する必要があるが、この時に、全てのメッシュ、テクスチャのビットレートを一律に下げることで品質を維持できることを示す情報をシグナリングすることにより、再生側（クライアント装置１０３）において、各3Dオブジェクトを、どのようにビットレートを下げるのが適切であるかを容易に把握することができる。したがって、その情報に基づいて、6DoFコンテンツの表示の際に維持すべき視点位置で決めた3Dオブジェクト間の品質の相対性を維持するように、全てのメッシュ、テクスチャのビットレートを一律に下げることができる。したがって、6DoFコンテンツの品質の低減を抑制することができる。
＜メッシュおよびテクスチャのビットレートアダプテーションの構成方法＞
本実施の形態においては、次の２つの条件を満たすようにビットレートアダプテーションを構成するものとする。
（１）各メッシュ、テクスチャのビットレートバリエーションの数は等しい。
（２）ビットレートバリエーション間の品質の違いは、他の3Dオブジェクトと相対的に同じである。
例えば、メッシュの場合は、エンコードパラメータ（量子化ビット数）でビットレートバリエーションを作成する（例えば３つビットレートバリエーションを作成する場合、どのメッシュのビットレートバリエーションも量子化ビット数を10,8,6の３パターンで作成する）ものとする。テクスチャの場合も同様にエンコードパラメータ（量子化パラメータ）でビットレートバリエーションを作成するものとする。
＜４−１：実施の形態２−１＞
＜ビットレート順に相対的な品質が維持されていることを示すシグナリングの追加＞
テクスチャのビットレートを一律に下げることで品質を維持できることを示すシグナリングとして、ビットレート順に相対的な品質が維持されていることを示すシグナリングを追加するようにしてもよい。
＜４ー２：実施の形態２−１−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、ビットレート順に相対的な品質が維持されていることを示すシグナリングを追加するようにしてもよい。
つまり、実施の形態１−１と同様のシステムにおいて、ビットレート順に相対的な品質が維持されていることを示すシグナリングを追加するようにしてもよい。つまり、この場合の配信システム１００の構成は図６の例と同様であり、ファイル生成装置１０１の構成は図７の例と同様であり、クライアント装置１０３の構成は図８の例と同様である。
＜ファイル生成処理の流れ＞
この場合のファイル生成処理の流れの例を、図４０のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のMPDファイル生成部１６４は、ステップＳ３２１において、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を含むMPDファイル１２２を生成する。
ステップＳ３２２乃至ステップＳ３２８の各処理は、ステップＳ１０２乃至ステップＳ１０８の各処理（図９）と同様に実行される。ステップＳ３２８の処理が終了すると、ファイル生成処理が終了する。
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図４１のフローチャートを参照して説明する。再生処理が開始されると、クライアント装置１０３のMPDファイル取得部１８１は、ステップＳ３４１において、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を含むMPDファイル１２２を取得する。
ステップＳ３４２乃至ステップＳ３４６の各処理は、ステップＳ１２２乃至ステップＳ１２６の各処理（図１０）と同様に実行される。
ステップＳ３４７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２において、伝送帯域と、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されることを示す情報とに基づいて、メディアデータセグメントファイルを選択する。
ステップＳ３４８およびステップＳ３４９の各処理は、ステップＳ１２８およびステップＳ１２９の各処理（図１０）と同様に実行される。ステップＳ３４９の処理が終了すると、再生処理が終了する。
以上のように各処理を実行することにより、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報に基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを一律に下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
＜４−３：実施の形態２−１−１−１＞
＜MPDのみ拡張＞
その場合、例えば、MPDファイルの拡張のみにより、ビットレート順に相対的な品質が維持されていることを示すシグナリングを追加するようにしてもよい。
＜MPDのシグナリング＞
例えば、MPDファイル１２２の、全てのメッシュおよび、テクスチャのAdaptationSetにおいて、ビットレート順(Representation@bandwidth順)に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示す品質相関情報を追加するようにしてもよい。
具体的には、Periodに、SupplementalPropertyで、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が変わらないAdaptationSetのidリストをスペース区切りでシグナリングする。以下にその例を示す。
例：<SupplementalProperty schemeIdUri="RelativeQualityIsEnsuredByBitrateOrder"
value="as1@id as2@id ・・・">
このSupplementalPropertyは、複数シグナリングしてもよい。例えば、6DoFコンテンツではなく、Audioにも同様に適用してもよい。
本実施の形態の場合のMPDファイル１２２の例を図４２に示す。この例は、3Dオブジェクトが３つあり、それぞれに高中低の３つのLevel of detailをもつ。さらに、それぞれのメッシュとテクスチャに３つのビットレートバリエーションを持つ。
例えば、図４２で、3DオブジェクトAは高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail（AdaptationSet@id=15と16）が適切なLevel of detailであると選択されている場合、ビットレートの組合せ（Representationの組み合わせ）は以下の３パターンから選択すると相対的な品質を維持した表示が可能となる。
パターン１：
Representation@id=AHm-1、Representation@id=AHt-1、Representation@id=BMm-1、Representation@id=BMt-1、Representation@id=CMm-1、Representation@id=CMt-1
パターン２：
Representation@id=AHm-2、Representation@id=AHt-2、Representation@id=BMm-2、Representation@id=BMt-2、Representation@id=CMm-2、Representation@id=CMt-2
パターン３：
Representation@id=AHm-3、Representation@id=AHt-3、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-3、Representation@id=CMt-3
＜変形例＞
図４２においてはPeriodにシグナリングする例を書いたが、AdaptationSetにシグナリングするようにしてもよい。ただし、その場合、value値は指定せず、このPropertyをもつAdaptationSetがビットレート順に取得すると3Dオブジェクト間の相対的な品質が変わらないAdaptationSetであることを示すようにする。以下に例を示す。また、この場合のMPDファイル１２２の例を図４３に示す。
例：<SupplementalProperty schemeIdUri="RelativeQualityIsEnsuredByBitrateOrder">
また、Videoだけでなく、Audioでも同様に利用する場合も考慮し、Value値としてグループ番号を指定し、同じグループ番号間では一律に下げるようにしてもよい。例えば、以下の例のように、valueの先頭にGroupIdをシグナリングするようにしてもよい。
例：<SupplementalProperty schemeIdUri="RelativeQualityIsEnsuredByBitrateOrder"
value="G
roupId, as1@id as2@id ・・・">
また、以下の例のように、SupplementalPropertyではなく、Periodもしくは、AdaptationSetのAttributeとして、@ RelativeQualityIsEnsuredByBitrateOrderをシグナルし、値としてTrue/Falseもしくはグループ番号をシグナルするようにしてもよい。
例：<Period RelativeQualityIsEnsuredByBitrateOrder="as1@id as2@id ・・・">
例：<ApdationSet RelativeQualityIsEnsuredByBitrateOrder="True">
上述した実施の形態１−１−１、実施の形態１−１−２、実施の形態１−１−３の全てにおいて、本実施の形態において説明した方法を適用することができる。本手法を実施の形態１−１−２に適用する場合、URLパラメータや、MPDのRepresentationGroupで示された中で、ビットレート順で処理するようにすればよい。
＜再生処理の流れ＞
この場合のファイル生成処理は、図４０のフローチャートと同様に実行される。この場合の再生処理の流れの例を、図４４のフローチャートを参照して説明する。再生処理が開始されると、MPDファイル取得部１８１は、ステップＳ３６１において、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を含むMPDファイル１２２を取得する。
ステップＳ３６２乃至ステップＳ３６６の各処理は、ステップＳ１６２乃至ステップＳ１６６の各処理（図１７）と同様に実行される。
ステップＳ３６７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２の、各3Dオブジェクトの所望のLevel of Detailに対応するAdaptationSetのそれぞれにおいて、Representationを選択する。その際、メディアデータセグメントファイル選択部１８７は、ビットレートの順番が同じであるRepresentationを選択し、取得する全セグメントファイルのビットレートの合計がステップＳ３６６において取得した伝送帯域より小さくなるように、Representationを選択する。
ステップＳ３６８およびステップＳ３６９の各処理は、ステップＳ１６８およびステップＳ１６９の各処理（図１７）と同様に実行される。ステップＳ３６９の処理が終了すると、再生処理が終了する。
以上のように各処理を実行することにより、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報に基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを一律に下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
＜４−４：実施の形態２−１−１−２＞
＜Scene Descriptionの拡張＞
実施の形態２−１−１−１において説明した方法のようにMPDファイル１２２ではシグナリングせずに、Scene Descriptionデータ１２１においてシグナリングするようにしてもよい。
＜Scene Descriptionのシグナリング＞
Scene Descriptionデータ１２１のBitwrapperノード１５およびMovieTextureノード１６のurl fieldの記述を拡張するようにしてもよい。例えば、URLにビットレート順に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示すURLパラメータを付加するようにする。より具体的には、例えば、RelativeQualityIsEnsuredByBitrateOrderをURLパラメータの変数とし付加する。このURLパラメータを持つ場合、ビットレート順（Representation@bandwidth順）に取得すると3Dオブジェクト間の相対的な品質が維持できることを示すものとする。以下に例を示す。
URLの例：
http://www.6dofserver.com/6dof.mpd?AS=1&RelativeQualityIsEnsuredByBitrateOrder
この場合のScene Descriptionデータ１２１の例を図４５に示す。図４５に示されるように、Bitwrapperノード１５およびMovieTextureノード１６のurl fieldのURLに、URLパラメータの変数として、RelativeQualityIsEnsuredByBitrateOrderが付加されている。
このようにすることにより、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を、Scene Descriptionデータ１２１においてシグナリングすることができる。したがって、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを一律に下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
以上においては、実施の形態１−１−１に適用する場合について説明したが、本手法は、実施の形態１−１−２や実施の形態１−１−３にも同様に適用することができる。実施の形態１−１−２に適用する場合、URLパラメータや、MPDのRepresentationGroupで示された中で、ビットレート順で処理するようにすればよい。
＜変形例＞
本拡張においても、実施の形態２−１−１の変形例のように、ビットレート順に取得するグルーピングを示すために、URLパラメータの値としてグルーピング番号を示すようにしてもよい。
＜４−５：実施の形態２−１−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、ビットレートを一律に下げるためのシグナリングを追加するようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
つまり、実施の形態１−２と同様のシステムにおいて、ビットレート順に相対的な品質が維持されていることを示すシグナリングを追加するようにしてもよい。つまり、この場合の配信システム１００の構成は図２９の例と同様であり、ファイル生成装置１０１の構成は図３０の例と同様であり、クライアント装置１０３の構成は図３１の例と同様である。
＜ファイル生成処理の流れ＞
この場合のファイル生成処理の流れの例を、図４６のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のScene Description生成部１６２は、ステップＳ３８１において、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を含むScene Descriptionデータ１２１を生成する。
ステップＳ３８２乃至ステップＳ３８５の各処理は、ステップＳ２２２乃至ステップＳ２２５の各処理（図３２）と同様に実行される。ステップＳ３８５の処理が終了すると、ファイル生成処理が終了する。
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図４７のフローチャートを参照して説明する。再生処理が開始されると、クライアント装置１０３のScene Descriptionセグメントファイル取得部１８３は、ステップＳ４０１において、現在時刻の、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報を含むScene Descriptionセグメントファイルを取得する。
ステップＳ４０２乃至ステップＳ４０４の各処理は、ステップＳ２４２乃至ステップＳ２４４の各処理（図３３）と同様に実行される。
ステップＳ４０５において、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイルにおいて、伝送帯域と、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されることを示す情報とに基づいて、ノードを選択する。
ステップＳ４０６およびステップＳ４０７の各処理は、ステップＳ２４６およびステップＳ２４７の各処理（図３３）と同様に実行される。ステップＳ４０７の処理が終了すると、再生処理が終了する。
以上のように各処理を実行することにより、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報に基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを一律に下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
＜４−６：実施の形態２−１−２−１＞
＜新しいノードを定義する＞
Scene Descriptionデータ１２１を拡張するにあたって、既存のノードはそのまま利用し、ビットレートアダプテーションのために新しいノードを追加するようにしてもよい。
＜Scene Descriptionのシグナリング＞
例えば、全てメッシュとテクスチャにおいて、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示す品質相関情報を追加するようにしてもよい。より具体的には、ClientSelectionノード３０１にビットレート順に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示すRelativeQualityIsEnsuredByBitrateOrderFlag fieldを追加するようにしてもよい。そのClientSelectionノードの拡張例を図４８に示す。
このRelativeQualityIsEnsuredByBitrateOrderFlagがTRUEであるメッシュおよびテクスチャは、ビットレートを変更する際に、bitrate fieldで示されているビットレート順に同時に下げることにより、3Dオブジェクト間の相対的な品質を変えずにビットレートを下げることができることを示す。
＜変形例＞
なお、本拡張においても、ビットレート順に取得するグルーピングを示すために、RelativeQualityIsEnsuredByBitrateOrderFlag ではなく、RelativeQualityIsEnsuredByBitrateOrderとし、SFint型でシグナルしグルーピング番号を示すようにしてもよい。
＜４−７：実施の形態２−１−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。
＜Scene Descriptionのシグナリング＞
例えば、実施の形態１−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６に、上述のRelativeQualityIsEnsuredByBitrateOrderFlag fieldを拡張するようにしてもよい。図４９にその場合の、Bitwrapperノード１５およびMovieTextureノード１６の例を示す。
＜変形例＞
本拡張においても、ビットレート順に取得するグルーピングを示すために、RelativeQualityIsEnsuredByBitrateOrderFlag ではなく、RelativeQualityIsEnsuredByBitrateOrderとし、SFint型でシグナルしグルーピング番号を示すようにしてもよい。
また、以上においては、Bitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
＜５．第３の実施の形態（実施の形態３）＞
＜取得するビットレート組合せ示すシグナリング＞
さらに、各テクスチャ、メッシュのバリエーションに対して、どのビットレートのものを同時に取得すれば相対的な品質の関係を維持できるかを示す品質相関情報を追加するようにしてもよい。換言するに、３次元オブジェクトの間の相対的な品質を示す情報をさらに含むメタデータを生成するようにしてもよい。
3Dオブジェクト毎にビットレートバリエーション数やその中の品質の変化は異なることがある。例えば、メッシュデータは、頂点数の多い3Dオブジェクト（例えば人）は複数のビットレートを作成することができるが、頂点数の少ない3Dオブジェクト(例えば箱)はエンコードパラメータを変えてもビットレートは変わらないため、同じ数のビットレートが準備できない。
そのような場合に、第２の実施の形態のように一律にビットレートを下げてしまうと、視点位置で決めた3Dオブジェクト間の相対的な品質の関係が大きく崩れる可能性があった。3Dオブジェクトによってはビットレートバリエーションがなく対応できないこともあり得る。その場合、取得できるビットレートのファイルが存在しないので、コンテンツを再生できなくなることもあり得る。
上述のように、品質相関情報を追加することにより、そのような場合であっても3Dオブジェクト間の相対的な品質の関係を維持するようにビットレートを制御することができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
＜５−１：実施の形態３−１＞
＜品質のランキングを利用して選択することで相対的な品質も維持できることを示すシグナリング＞
3Dオブジェクトの各Level of Detailのメッシュおよびテクスチャそれぞれのビットレートバリエーションに品質のランキングをシグナリングする。さらに、それの値を元に取得することで、相対的な品質が維持できることを示すシグナリグを行うようにしてもよい。例えば、３次元オブジェクトの間の相対的な品質を示す情報として、３次元オブジェクトの各ビットレートバリエーションの品質を順位で示すQualityRankingを含むメタデータを生成するようにしてもよい。この際に、QualityRankingの値で相対的な品質が変わらないようにエンコードする。例えば、実施の形態２のビットレートアダプテーションの構成方法でエンコードし、エンコードパラメータ順にQualityRankingを決め、その後、ビットレートの変化が少ないものを間引くようにしてもよい。
＜５−２：実施の形態３−１−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、QulityRanking（品質相関情報）をシグナリングするようにしてもよい。このQualityRankingは既存のDASH規格（ISO/IEC 23009-1）のRepresentation@QualityRankingを用いる。
つまり、実施の形態１−１と同様のシステムにおいて、QulityRankingをシグナリングするようにしてもよい。つまり、この場合の配信システム１００の構成は図６の例と同様であり、ファイル生成装置１０１の構成は図７の例と同様であり、クライアント装置１０３の構成は図８の例と同様である。
＜ファイル生成処理の流れ＞
この場合のファイル生成処理の流れの例を、図５０のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のMPDファイル生成部１６４は、ステップＳ４２１において、QualityRankingを含むMPDファイル１２２を生成する。
ステップＳ４２２乃至ステップＳ４２８の各処理は、ステップＳ１０２乃至ステップＳ１０８の各処理（図９）と同様に実行される。ステップＳ３２８の処理が終了すると、ファイル生成処理が終了する。
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図５１のフローチャートを参照して説明する。再生処理が開始されると、クライアント装置１０３のMPDファイル取得部１８１は、ステップＳ４４１において、QualityRankingを含むMPDファイル１２２を取得する。
ステップＳ４４２乃至ステップＳ４４６の各処理は、ステップＳ１２２乃至ステップＳ１２６の各処理（図１０）と同様に実行される。
ステップＳ４４７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２において、伝送帯域と、QualityRankingとに基づいて、メディアデータセグメントファイルを選択する。
ステップＳ４４８およびステップＳ４４９の各処理は、ステップＳ１２８およびステップＳ１２９の各処理（図１０）と同様に実行される。ステップＳ３４９の処理が終了すると、再生処理が終了する。
以上のように各処理を実行することにより、QualityRankingに基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
＜５−３：実施の形態３−１−１−１＞
＜MPDのみ拡張＞
その場合、例えば、MPDファイルの拡張のみにより、全てのメッシュおよび、テクスチャのAdaptationSetにおいて、RepresentationでシグナリングされるQualityRanking順（Representation＠QualityRanking）に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示す情報を追加するようにしてもよい。
より具体的には、Periodに、SupplementalPropertyで、QualityRanking順に取得すると3Dオブジェクト間の相対的な品質が変わらないAdaptationSetのidリストをスペース区切りでシグナリングする。以下に例を示す。
例：<SupplementalProperty schemeIdUri="RelativeQualityIsEnsuredByQualityRanking"
value="as1@id as2@id ・・・">
同じQualityRanking値のRepresentationがない場合、近いQualityRanking値のRepresentationを選択するようにしてもよい。このSupplementalPropertyは複数シグナリングされることもできる。例えば、6DoFコンテンツではなく、Audioにも同様に適用する場合である。
この場合のMPDファイル１２２の例を図５２に示す。この例は、3Dオブジェクトが３つあり、それぞれに高中低の３つのLevel of detailをもつ。さらに、それぞれのメッシュとテクスチャのビットレートバリエーションは、異なっている。
図５２において、3DオブジェクトAは高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail（AdaptationSet@id=15と16）が適切なLevel of detailであると選択されている場合、ビットレートの組合せはQualityRankingを参考に次の３パターンから選択すると相対的な品質を維持した表示が可能となる。
パターン１：
Representation@id=AHm-1、Representation@id=AHt-1、Representation@id=BMm-1、Representation@id=BMt-1、Representation@id=CMm-1、Representation@id=CMt-1
パターン２：
Representation@id=AHm-2、Representation@id=AHt-2、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-2
パターン３：
Representation@id=AHm-3、Representation@id=AHt-3、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-3
実施の形態１−１−１、実施の形態１−１−２、実施の形態１−１−３のいずれにおいても本手法の適用が可能である。ただし、実施の形態１−１−２の場合、QualityRankingが1から始まらないRepresentationGroupが選択される場合があるが、クライアントの実装で、QualityRankingの値ではなく、QualityRankingの差を用いることで適用が可能である。
＜変形例＞
以上においてはPeriodにシグナリングする例を書いたが、AdaptationSetにシグナリングしてもよい。ただし、その場合は、value値は指定せず、このPropertyをもつAdaptationSetでQualityRanking順に取得すると3Dオブジェクト間の相対的な品質が変わらないAdaptationSetであることを示す。以下に例を示す。また、この場合のMPDファイル１２２の例を図５３に示す。
例：<SupplementalProperty
schemeIdUri="RelativeQualityIsEnsuredByQualityRanking">
また、Videoだけでなく、Audioでも同様に利用する場合も考慮し、Value値としてグループ番号を指定し、同じグループ番号間では一律に下げるようにしてもよい。例えば、valueの先頭にGroupIdをシグナリングする。以下にその例を示す。
例：<SupplementalProperty schemeIdUri=" RelativeQualityIsEnsuredByQualityRanking"
value="G
roupId, as1@id as2@id ・・・">
＜その他の変形例＞
PeriodのAttributeにRelativeQualityIsEnsuredByQualityRankingを追加してもよい。また、AdaptationSetのAttributeにRelativeQualityIsEnsuredByQualityRankingを追加してもよい。以下にその例を示す。
例：<Period RelativeQualityIsEnsuredByQualitRanking="1 2 3 … 17 18">
例：<AdaptatonSet RelativeQualityIsEnsuredByQualitRanking="TRUE">
＜再生処理の流れ＞
この場合のファイル生成処理は、図５０のフローチャートと同様に実行される。この場合の再生処理の流れの例を、図５４のフローチャートを参照して説明する。再生処理が開始されると、MPDファイル取得部１８１は、ステップＳ４６１において、QualityRankingを含むMPDファイル１２２を取得する。
ステップＳ４６２乃至ステップＳ４６６の各処理は、ステップＳ１６２乃至ステップＳ１６６の各処理（図１７）と同様に実行される。
ステップＳ４６７において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２の、各3Dオブジェクトの所望のLevel of Detailに対応するAdaptationSetのそれぞれにおいて、Representationを選択する。その際、メディアデータセグメントファイル選択部１８７は、SupplementalPropertyで示されるAdaptationSetについては、QualityRankingの値が同じか、近い値のRepresentationを選択し、取得する全セグメントファイルのビットレートの合計が伝送帯域より小さくなる組み合わせを選択する。
ステップＳ４６８およびステップＳ４６９の各処理は、ステップＳ１６８およびステップＳ１６９の各処理（図１７）と同様に実行される。ステップＳ４６９の処理が終了すると、再生処理が終了する。
以上のように各処理を実行することにより、ビットレート順に取得すると3Dオブジェクト間の相対的な品質が維持されていることを示す情報に基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
つまり、クライアント装置１０３は、各3DオブジェクトのメッシュデータおよびテクスチャデータのAdaptationSetから、ビットレートを選択する際に、QualityRankingの値が１である組合せ、次に２である組合せと、順に選択していくことで、ビットレートアダプテーションをしても相対的な品質の変わらないようにデータの選択が可能になる。QualityRankingの値が存在しない場合は近い値のQualityRankingのRepresentationを利用するようにしてもよい。
本実施の形態において、QualityRankingをある一定以上存在していない場合がある。その場合、それ以上Qualityを下げることができないため、最低のQualityになるものを選び続けるしかない。しかしながら、QualityRankingが離れすぎてしまい、相対的な品質が維持できないかもしれない。それを回避するために次のような手法をできるようにしてもよい。
（１）クライアント装置１０３が、他のQualityに合うように表示時のQualityを下げて表示する。たとえば、クライアント装置１０３が、表示時にガウスぼかしフィルタをその3Dオブジェクトの部分にのみに適用してから表示する。
（２）実施の形態１−１−１および実施の形態１−１−２に本技術を適用する場合、クライアント装置１０３が、配信サーバ１０２にQualityRankingの低いビットレートを作成させそれを取得する。
クライアント装置１０３は、配信サーバ１０２にMPDファイル名、ApdaptationSetのid、作成してほしいQualityRankingをリクエストする。配信サーバ１０２は、そのリクエストに応じて指定されたAdaptationSetのメッシュデータもしくはテクスチャデータの指定されたQualityRankingのセグメントファイルを作成する。そして、配信サーバ１０２は、MPDファイル１２２をMPD updateの仕組みを利用してUpdateし、クライアント装置１０３に送信する。クライアント装置１０３は、新しく取得したMPDファイル１２２に基づいて、再度、品質のランキングを利用して取得するファイルを選択する。この場合に、サーバには存在しないが作成可能なQualityRankingのセグメントファイルをあらかじめMPDにシグナリングしておいてもよい。
＜５−４：実施の形態３−１−１−２＞
＜Scene Descriptionの拡張＞
実施の形態３−１−１−１において説明した方法のようにMPDファイル１２２ではシグナリングせずに、Scene Descriptionデータ１２１においてシグナリングするようにしてもよい。
＜Scene Descriptionのシグナリング＞
その場合、実施の形態２−１−１−２の場合と同様に、Scene Descriptionデータ１２１のBitwrapperノード１５およびMovieTextureノード１６のurl fieldの記述を拡張するようにしてもよい。
例えば、以下に示す例のように、Scene Descriptionデータ１２１のメッシュ、テクスチャを示すURLのURLパラメータで、QualityRanking順に取得すると3Dオブジェクト間の相対的な品質が変わらないことを示すようにしてもよい。
URLの例：
http://www.6dofserver.com/6DoF.mpd?
AS=1&RelativeQualityIsEnsuredByByQualityRanking
この場合のScene Descriptionデータ１２１の記述は、図４５の例のRelativeQualityIsEnsuredByBitrateOrderの部分がRelativeQualityIsEnsuredByByQualityRankingに置き換わったものになる。
以上においては、実施の形態１−１−１に適用する場合について説明したが、本手法は、実施の形態１−１−２や実施の形態１−１−３にも同様に適用することができる。また、実施の形態３−１−１−１のQualityRankingの低くなるビットレートバリエーションが存在しない場合の処理を行うことができるようにしてもよい。
＜変形例＞
また実施の形態３−１−１−１の変形例のようにグルーピング情報を追加するようにしてもよい。例えば、URLパラメータのRelativeQualityIsEnsuredByQualityRankingの値に、グルーピング情報を追加するようにしてもよい。以下にその例を示す。
URLの例：
http://www.6dofserver.com/6DoF.mpd?
AS=1&RelativeQualityIsEnsuredByQualityRanking=1
URLパラメータを拡張するのではなく、Bitwrapperノード１５、MovieTextureノード１６に、例えば、以下の例のような、新しいfieldを追加するようにしてもよい。
例：field SFBool RelativeQualityIsEnsuredByQualityRankingFlag
＜５−５：実施の形態３−１−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、品質のランキングを利用して選択することで相対的な品質も維持できることを示すシグナリングを追加するようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。なお、この実施の形態においては、（１）品質のランキングをシグナリングする拡張、（２）QualityRanking順に取得することで相対的な品質が維持できることを示すシグナリングの拡張、の２つの拡張が行われる。
また、実施の形態１−２と同様のシステムにおいて、品質のランキングを利用して選択することで相対的な品質も維持できることを示すシグナリングを追加するようにしてもよい。つまり、この場合の配信システム１００の構成は図２９の例と同様であり、ファイル生成装置１０１の構成は図３０の例と同様であり、クライアント装置１０３の構成は図３１の例と同様である。
＜ファイル生成処理の流れ＞
この場合のファイル生成処理の流れの例を、図５５のフローチャートを参照して説明する。ファイル生成処理が開始されると、ファイル生成装置１０１のScene Description生成部１６２は、ステップＳ４８１において、QualityRankingを含むScene Descriptionデータ１２１を生成する。
ステップＳ４８２乃至ステップＳ４８５の各処理は、ステップＳ２２２乃至ステップＳ２２５の各処理（図３２）と同様に実行される。ステップＳ４８５の処理が終了すると、ファイル生成処理が終了する。
＜再生処理の流れ＞
次に、この場合の再生処理の流れの例を、図５６のフローチャートを参照して説明する。再生処理が開始されると、クライアント装置１０３のScene Descriptionセグメントファイル取得部１８３は、ステップＳ５０１において、現在時刻の、QualityRankingを含むScene Descriptionセグメントファイルを取得する。
ステップＳ５０２乃至ステップＳ５０４の各処理は、ステップＳ２４２乃至ステップＳ２４４の各処理（図３３）と同様に実行される。
ステップＳ５０５において、Scene Descriptionセグメントファイル処理部１８４は、Scene Descriptionセグメントファイルにおいて、伝送帯域と、QualityRankingとに基づいて、ノードを選択する。
ステップＳ５０６およびステップＳ５０７の各処理は、ステップＳ２４６およびステップＳ２４７の各処理（図３３）と同様に実行される。ステップＳ５０７の処理が終了すると、再生処理が終了する。
以上のように各処理を実行することにより、QualityRankingに基づく再生が可能になるので、6DoFコンテンツの品質の低減を抑制するように、各3Dオブジェクトのメッシュ、テクスチャのビットレートを下げることができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
＜５−６：実施の形態３−１−２−１＞
＜新しいノードを定義する＞
Scene Descriptionデータ１２１を拡張するにあたって、既存のノードはそのまま利用し、ビットレートアダプテーションのために新しいノードを追加するようにしてもよい。例えば、実施の形態１−２−１において説明したClientSelectionノード３０１を拡張するようにしてもよい。
そのClientSelectionノード３０１の拡張例を図５７に示す。例えば、ClientSelectionノード３０１において、SelectionNode fieldで示される子ノードの品質のランキングをQualityRanking fieldで記述する。QualityRanking[n]は、SelectionNode[n]の品質のランキングを示す。
また、RelativeQualityIsEnsuredByQualityRankingFlagがTRUEであるメッシュおよびテクスチャは、QualityRanking fieldで示されているQualityRanking値が同じであるメッシュおよびテクスチャを選択することで、3Dオブジェクト間の相対的な品質を維持してビットレートを変更できることを示す。
＜変形例＞
また実施の形態３−１−１−１の変形例のように、グルーピング情報をシグナルできるようにしてもよい。その場合、RelativeQualityIsEnsuredByQualityRankingFlagを以下の例に置き換え、値としてグルーピング情報を持つようにする。
field SFint32 RelativeQualityIsEnsuredByQualityRanking
＜５−７：実施の形態３−１−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。
＜Scene Descriptionのシグナリング＞
例えば、実施の形態１−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６に、上述のQualityRanking fieldおよび、RelativeQualityIsEnsuredByQualityRankingFlag fieldを拡張するようにしてもよい。図５８にその場合の、Bitwrapperノード１５およびMovieTextureノード１６の例を示す。
＜変形例＞
実施の形態３−１−２−１の変形例のように、グルーピング情報を扱えるようにしてもよい。また、以上においては、Bitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
＜５−８：実施の形態３−２＞
＜Qualityそのものをシグナリング＞
全てのビットレートバリエーションのQuality（例えばPSNRなど）をシグナリングする。この場合、クライアント装置１０３は、Qualityの変化が同じ程度になるようなデータを選択する。換言するに、３次元オブジェクトの間の相対的な品質を示す情報として、その３次元オブジェクトの各ビットレートバリエーションの品質を値で示すQuality値を含むメタデータを生成するようにしてもよい。
＜５−９：実施の形態３−２−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、ビットレートバリエーションのQualityをシグナリングするようにしてもよい。
＜MPDのシグナリング＞
例えば、QualityそのものをRepresentationでシグナリングするようにしてもよい。例えば、Representationにおいて、SupplementalPropertyを用いて、Qualityの種類や値をシグナリングするようにしてもよい。以下にその例を示す。
<SupplementalProperty schemeIdUri="QualityValue" value="type,value">
この例において、Qualityの種類はtypeにより、Qualityの値はvalueによりシグナリングされる。Qualityの種類によっては時間毎にQuality値が異なることや、3Dオブジェクトを見る位置や方向などでQuality値が変わる可能性もある。その場合、本手法では特定の時間、視点位置、視線方向を元に計算された代表値のQuality値を利用すればよい。また、typeは図５９の表のように示されればよい。
クライアント装置１０３は、示されているtypeとvalue値を用いて、ビットレートを下げる際に、Qualityの変化が同じ程度になるようなRepresentationを選択することで、相対的な品質を維持したビットレート選択が可能になる。
この場合のMPDファイル１２２の例を図６０に示す。この例は、3Dオブジェクトが３つあり、それぞれに高中低の３つのLevel of detailをもつ。さらに、それぞれのメッシュとテクスチャのビットレートバリエーションは、異なっている。
図６０に示されるMPDファイル１２２において、3DオブジェクトAは高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail（AdaptationSet@id=15と16）が適切なLevel of detailであると選択されている場合を考える。ビットレートの組合せはQualityのValueを参考に最もQualityの良いものからの差が同じもしくは近い値を選択すると、次の３パターンが相対的な品質を維持した表示が可能である組合せになる。
パターン１：
Representation@id=AHm-1、Representation@id=AHt-1、Representation@id=BMm-1、Representation@id=BMt-1、Representation@id=CMm-1、Representation@id=CMt-1
パターン２：
Representation@id=AHm-2、Representation@id=AHt-2、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-2
パターン３：
Representation@id=AHm-3、Representation@id=AHt-3、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-3
本実施の形態の手法は、実施の形態１−１−１、実施の形態１−１−２、実施の形態１−１−３のいずれにも適用することができる。
本実施の形態の手法において、Quality値がある一定以上存在しない場合がある。その場合、それ以上Qualityを下げることができないため、最低のQualityになるものを選び続けるしかない。しかしながら、Qualityの相関関係が崩れてしまう。それを回避するために次のような手法をできるようにしてもよい。
（１）クライアントで他のQualityに合うように表示時のQualityを下げて表示する。例えば、表示時にガウスぼかしフィルタをその3Dオブジェクトの部分にのみに適用してから表示する。
（２）実施の形態１−１−１または実施の形態１−１−２の場合、 クライアント装置１０３は、配信サーバ１０２にQualityの低いビットレートを作成させそれを取得する。クライアント装置１０３は、配信サーバ１０２に、MPDファイル名、ApdaptationSetのid、作成してほしいQualityのtypeとvalueをリクエストする。配信サーバ１０２は、リクエストに応じて指定されたAdaptationSetのメッシュデータもしくはテクスチャデータの指定されたQualityのtypeとvalueになるセグメントファイルを作り、配置する。そして、MPDファイル１２２をMPD updateの仕組みを利用し Updateして、クライアント装置１０３に送信する。クライアント装置１０３は新しく取得したMPDファイルを基に、再度、Qualityを利用して取得するファイルを選択する。この場合に、サーバには存在しないが作成可能なQualityのtypeとvalueのセグメントファイルをあらかじめMPDにシグナリングしておいてもよい。
＜変形例＞
RepresentaitonのAttributeにQualityValueを追加するようにしてもよい。以下にその例を示す。
例：<RepresentationAdaptatonSet QualityValue="1,41">
＜５−１０：実施の形態３−２−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、Qualityそのもののシグナリングを追加するようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
＜５−１１：実施の形態３−２−２−１＞
＜新しいノードを定義する＞
Scene Descriptionデータ１２１を拡張するにあたって、既存のノードはそのまま利用し、ビットレートアダプテーションのために新しいノードを追加するようにしてもよい。
本実施は、実施の形態１−２−１のClientSelectionノード３０１を拡張して実現する。この場合のClientSelectionノード３０１の構成例を図６１に示す。ClientSelectionノード３０１のSelectionNodeで示される子ノードのQualityそのものをQualityValue fieldで示す。QualityValue[n]は、SelectionNode[n]のQualityを示す。さらに、Qualityの種類をQualityType fieldで示す。QualityTypeは全てのQualityValueで共通である。QualityType fieldの値は、図５９の表４０１の値を利用する。
＜５−１２：実施の形態３−２−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。実施の形態３−２−２−１の変形例である。実施の形態１−２−２で拡張したBitwrapperノード１５およびMovieTextureノード１６に、QualityValue fieldおよび、QualityType fieldを拡張して実現する。その場合のBitwrapperノード１５およびMovieTextureノード１６の例を図６２に示す。
なお、以上においては、Bitwrapperノード１５およびMovieTextureノード１６の拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
＜５−１３：実施の形態３−３＞
＜同時に再生するメディアデータの組み合せをシグナリング＞
また、同時に再生するメディアデータの組み合せをシグナリングするようにしてもよい。換言するに、３次元オブジェクトの間の相対的な品質を示す情報として、同時再生可能な３次元オブジェクトの各ビットレートバリエーションを示す情報を含むメタデータを生成するようにしてもよい。
＜５−１４：実施の形態３−３−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、同時に再生するメディアデータの組み合せをシグナリングするようにしてもよい。
＜MPDのシグナリング＞
例えば、相対的な品質が維持できる組合せを示すGrouping情報をシグナリングするようにしてもよい。
クライアント装置１０３は、AdaptationSetからRepresentationを選択する際に、同じGroupを選択して再生する。１つのRepresentationが複数のGroupに所属する場合もある。より具体的には、各Representationに、SupplementalPropertyで、グループ番号を示し、このグループ番号をもとに同じグループ番号を選択すれば3Dオブジェクト間の相対的な品質が変わらないことを示す。value値がグループ番号を示す。スペース区切りで複数のグループを示すことができる。以下に例を示す。
例：<SupplementalProperty schemeIdUri="KeepRelativeQualityConsiderationGroup"
value="1...">
図６３は、その場合のMPDファイル１２２の記述例を示す図である。図６３において、3DオブジェクトAは高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail(AdaptationSet@id=15と16)が適切なLevel of detailであると選択されている場合を考える。ビットレートの組合せはKeepRelativeQualityConsiderationGroupの同じ値のRepresentaitonを選択することで、相対的な品質を維持することができる組合せである。この例では、次の３パターンが相対的な品質を維持した表示が可能である組合せになる。
パターン１：
Representation@id=AHm-1、Representation@id=AHt-1、Representation@id=BMm-1、Representation@id=BMt-1、Representation@id=CMm-1、Representation@id=CMt-1
パターン２：
Representation@id=AHm-2、Representation@id=AHt-2、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-2
パターン３：
Representation@id=AHm-3、Representation@id=AHt-3、Representation@id=BMm-3、Representation@id=BMt-3、Representation@id=CMm-1、Representation@id=CMt-3
本実施の形態において、最大の数値のGroup以上にQualityを下げることができない。その際、さらに低いQualityになるGroupを配信サーバ１０２に作成させ、それを取得できるようにしてもよい。クライアント装置１０３は、配信サーバ１０２に、MPDファイル名と、KeepReativeQualityGroupのさらに低い組合せをリクエストする。配信サーバ１０２はリクエストに応じて、KeepReativeQualityGroupの最大数値のGroupよりも低いQualityになる、つまり、全ての3Dオブジェクトで最も低いQualityのメディアデータを作成し、配置する。配信サーバ１０２は、そのMPDファイル１２２をUpdateして、クライアント装置１０３に送信する。クライアント装置１０３は、新しく取得したMPDファイル１２２を基に、再度、KeepReativeQualityGroupを利用して取得するファイルを選択する。この場合に、サーバには存在しないが作成可能なQualityのgroupのセグメントファイルをあらかじめMPDにシグナリングしておいてもよい。
＜変形例＞
RepresentaitonのAttributeにKeepRelativeQualityGroupを追加するようにしてもよい。以下にその例を示す。
例：<AdaptatonSet KeepRelativeQualityGroup ="1">
また、Videoだけでなく、Audioでも同様に利用する場合も考慮し、Value値としてKeepRelativeQualityGroupをさらにグルーピングするidをシグナリングするようにしてもよい。例えば、valueの先頭にGroupIdをシグナリングするようにしてもよい。以下にその例を示す。
例：<SupplementalProperty schemeIdUri=" KeepRelativeQualityGroup"
value="GroupId, as1@id as2@id ・・・">
＜５−１５：実施の形態３−３−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
実施の形態１−２の、Scene Descriptionのみを拡張した手法において、相対的な品質が維持できる組合せを示すGrouping情報をシグナリングするようにしてもよい。
＜５−１６：実施の形態３−３−２−１＞
＜新しいノードを定義する＞
実施の形態１−２−１のClientSelectionノード３０１を拡張するようにしてもよい。この場合のClientSelectionノード３０１の例を図６４に示す。図６４において、ClientSelectionノード３０１のSelectionNodeで示される子ノードに相対的な品質が維持できる組合せを示すGrouping情報をシグナリングするようにしてもよい。より具体的には、KeepRelativeQualityConsiderationGroupを各SelectionNodeに設定するようにしてもよい。SlectionNode[n]が属するGroup情報は、KeepRelativeQualityConsiderationGroup[n]に示される。Groupは、整数値を文字として示し、複数のgroupに属する場合は、スペース区切りで表記する。
＜変形例＞
また実施の形態３−２−１の変形例のようにKeepRelativeQualityGroupをさらにグルーピングするidをシグナリングするようにしてもよい。その場合、以下の例のようなKeepRelativeQualityGroupId fieldを追加すればよい。
field SFint32 KeepRelativeQualityGroupId
＜５−１７：実施の形態３−３−２−２＞
＜既存のノードを拡張する＞
実施の形態３−３−２−１の変形例である。実施の形態１−２−２で拡張した、Bitwrapperノード１５およびMovieTextureノード１６にKeepRelativeQualityConsiderationGroup fieldを拡張するようにしてもよい。図６５に拡張したBitwrapperノード１５およびMovieTextureノード１６の例を示す。
＜変形例＞
また、実施の形態の３−３−２−１のようにKeepRelativeQualityGroupId fieldを追加するようにしてもよい。また、以上においては、Bitwrapperノード１５およびMovieTextureノード１６の拡張例について説明したが、これに限らず、他のノードで同様のfieldを拡張するようにしてもよい。
＜６：第４の実施の形態（実施の形態４）＞
＜Level of detailを切り替えてビットレート選択をするためのシグナリング＞
さらに、限界までビットレートを落とした後、視点位置に応じて決めた3DオブジェクトのLevel of detailから、１つ若しくは複数、または、全ての3Dオブジェクトに対するLevel of detailを下げて、ビットレートアダプテーションするためのシグナリングを追加するようにしてもよい。
全ての3Dオブジェクトで最低のビットレートのメッシュ、テクスチャを選択しても、その合計ビットレートよりも伝送帯域が狭い場合、再生が途切れてしまう可能性があった。
上述のように、Level of detailを下げてビットレートアダプテーションするためのシグナリングを行うことにより、上述のような場合に、6DoFコンテンツの品質の低減を抑制するように、Level of detailを一律に下げることができるようになる。したがって、コンテンツ再生のロバスト性を向上させることができる。
＜６−１：実施の形態４−１＞
＜Level of detailを一律に下げると相対関係が崩れないことを示すシグナリング＞
Level of detailを切り替えてビットレート選択をするために、Level of detailを一律に下げると相対関係が崩れないことを示すシグナリングするようにしてもよい。換言するに、３次元オブジェクトのLevel of Detailを変更しても、その３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含むメタデータを生成するようにしてもよい。
＜６−２：実施の形態４−１−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、Level of detailを一律に下げると相対関係が崩れないことをシグナリングするようにしてもよい。
＜MPDのシグナリング＞
実施の形態１−１−１を基にした実施の形態においては、Scene Descriptionの3DオブジェクトのLevel of detailごとにMPDのAdaptationSetにアクセスできるようになっている。しかしながら、実施の形態１−１−１を基にした実施の形態のMPDには、それぞれのAdaptationSetがどの3DオブジェクトのLevel of Detailに対応するかは示されていない。Level of Detailを切り替えるために、どの3DオブジェクトのLevel of Detailであるかを、Scene Descriptionから情報を取得するのは２度手間になる（煩雑・冗長な作業が必要になる）。
そこで、まず、MPDで同じ3Dオブジェクトに含まれるLevel of Detailがどれであるかを示すようにする。つまり、同じ3DオブジェクトのメッシュのAdaptationSet（Level of Detail）をグルーピングする。同様に同じ3DオブジェクトのテクスチャのAdaptationSet（Level of Detail）をグルーピングする。さらに、Level of detailを一律に下げる場合において、各オブジェクトの表示の相対関係を極力維持することができることをシグナリングする。
このような手法を実現する具体的なシグナリングは、Periodに、Level of detailを一律に下げる場合に、各オブジェクトの表示の相対関係を極力維持できることを示すSupplementalPropertyをシグナリングし、それが可能であるLevel of Detailのグループをシグナリングする。
SupplementalPropertyを用いて、schemeIdUriで、Level of detailを一律に下げる場合において、各オブジェクトの表示の相対関係を極力維持することができることを示す、" LODRelativeQualityIsEnsuredByLODOrder"をシグナリングする。さらに、SupplementalPropertyのElementにLODGroupを追加する。LODGroupは同じ3Dオブジェクトのメッシュもしくは同じ3DオブジェクトのテクスチャのAdaptationSetのグルーピング情報である。LODGroupのmember attributeでグループに含まれるAdaptationSet@idをシグナリングする。シグナリングされるAdaptationSet@idの順は、高Level of detailから順に並べ、Level of Detailの下げる順を示す。以下に例を示す。
例：
<SupplementalProperty schemeIdUri="LODRelativeQualityIsEnsuredByLODOrder">
<LODGroup member="as@id1 as@id2..."/>
<LODGroup member="as@id4 as@id5..."/>
</SupplementalProperty>
クライアントは、第２の実施の形態や第３の実施の形態の手法でビットレートを下げることが困難になった場合、このSupplementalPropertyを基に１つLevel of detailの低いAdaptationSetの組合せを選択し、再び第２の実施の形態や第３の実施の形態の手法を用いてビットレート選択をする。その際に、低いLevel of Detailが存在しない場合は、最も低いLevel of detailの最低ビットレートのデータを使う。
この場合のMPDファイル１２２の例を図６６に示す。この例では、3Dオブジェクトが３つあり、それぞれに高中低の３つのLevel of detailをもつ。それぞれの3DオブジェクトのLevel of detail違いのメッシュデータのグループおよびテクスチャデータのグループを、SupplementalPropertyで示している。
図６６において、3DオブジェクトAは高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail（AdaptationSet@id=15と16）が適切なLevel of detailであると選択されている。その組合せの中でビットレートを下げても合計ビットレートが伝送帯域より多くなってしまう場合、Level of detailを変更する。この際に、SupplementalPropertyを参考に、全てで１つずつ低いLevel of detailを選択する。すると以下のような組み合わせになる。
AdaptationSet@id=3 （3DオブジェクトA 中Level of detailのメッシュデータ）
AdaptationSet@id=4 （3DオブジェクトA 中Level of detailのテクスチャデータ）
AdaptationSet@id=11 （3DオブジェクトB 低Level of detailのメッシュデータ）
AdaptationSet@id=12 （3DオブジェクトB 低Level of detailのテクスチャデータ）
AdaptationSet@id=17 （3DオブジェクトC 低Level of detailのメッシュデータ）
AdaptationSet@id=18 （3DオブジェクトC 低Level of detailのテクスチャデータ）
本手法は、実施の形態１−１−１にも適用することができる。なお、実施の形態１−１−１−１に本手法を適用する場合、実施の形態１−１−２−２のAdaptationSet内でRepresentationGroupを示すシグナリングを行い、AdaptationSetで、RepresentationGroup（つまりLevel of Detail）を一律に下げると相対関係を極力維持することができるシグナリングをSupplementalPropertyで行うことで実現することができる。
実施の形態１−１−２−２に本手法を適用する場合、AdaptationSetで、RepresentationGroup（つまりLevel of Detail）を一律に下げると相対関係を極力維持することができるシグナリングをSupplementalPropertyで行うことで実現することができる。
＜変形例＞
また、以下のようなシグナリングを行うようにしてもよい。
（１）同じ3Dオブジェクトのメッシュやテクスチャのグループ情報をAdaptationSet@groupで識別し、Level of detailの順をSupplementalPropertyで各AdaptationSetにシグナリングする。もしくはAdaptationSetのAttributeに指定する。
（２）同じ3Dオブジェクトのメッシュやテクスチャのグループ情報をAdaptationSet@groupで識別し、Level of detailの順は、Scene Descriptionから取得する。
（３）AdaptationSetで、１つ高いLevel of detailのAdaptationSetと、１つ低いLevel of detailのAdaptationSetをシグナリングする。その記述例を以下に示す。なお、このシグナリングは、AdaptationSetのAttributeで指定するようにしてもよい。
<SupplementalProperty schemeIdUri="LowLevelAdaptationSet"
value="AdaptationSet@id">
<SupplementalProperty schemeIdUri="HighLevelAdaptationSet"
value="AdaptationSet@id">
（４）上述の（１）乃至（３）において、さらに、Level of Detailを一律に下げると相対的な品質関係が崩れないことをAdaptationSetでシグナリングする。より具体的には、AdapttionSetに、SupplementalPropertyで、Level of detailを一律に下げると相対関係を極力維持することができるAdaptationSetであることをシグナリングする。以下にその例を示す。なお、このシグナリングは、AdaptationSetのAttributeで指定するようにしてもよい。
例：<SupplementalProperty schemeIdUri="LODRelativeQualityIsEnsuredByLODOrder">
本手法は、実施の形態１−１−１に適用することができる。なお、本手法を実施の形態１−１−２−１に適用する場合、実施の形態１−１−２−２のAdaptationSet内でRepresentationGroupを示すシグナリングを行い、AdaptationSetで、RepresentationGroup（つまりLevel of Detail）を一律に下げると相対関係を極力維持することができるシグナリングをSupplementalPropertyで行うことで実現することができる。
また、本手法を実施の形態１−１−２−２に適用する場合、AdaptationSetで、RepresentationGroup（つまりLevel of Detail）を一律に下げると相対関係を極力維持することができるシグナリングをSupplementalPropertyで行うことで実現することができる。
＜再生処理の流れ＞
この場合の再生処理の流れの例を、図６７のフローチャートを参照して説明する。再生処理が開始されると、クライアント装置１０３のMPDファイル取得部１８１は、ステップＳ５２１において、QualityGroup情報を含むMPDファイル１２２を取得する。
ステップＳ５２２乃至ステップＳ５２６の各処理は、ステップＳ１６１乃至ステップＳ１６６の各処理（図１７）と同様に実行される。
ステップＳ５２７において、メディアデータセグメントファイル選択部１８７は、現在のLevel of Detailにおいて、伝送帯域より小さくなるビットレートの組み合わせが選択可能であるか否かを判定する。可能であると判定された場合、処理はステップＳ５２８に進む。
ステップＳ５２８において、メディアデータセグメントファイル選択部１８７は、MPDファイル１２２の、各3Dオブジェクトの所望のLevel of Detailに対応するAdaptationSetのそれぞれにおいて、Representationを選択する。その際、メディアデータセグメントファイル選択部１８７は、取得する全セグメントファイルのビットレートの合計が伝送帯域より小さくなるようにRepresentationを選択する。ステップＳ５２８の処理が終了すると、処理はステップＳ５３０に進む。
また、ステップＳ５２７において、現在のLevel of Detailでは伝送帯域より小さくなるビットレートの組み合わせを得ることは不可能であると判定された場合、処理はステップＳ５２９に進む。
ステップＳ５２９において、メディアデータセグメントファイル選択部１８７は、ビットレート選択処理を行い、Level of Detailを下げて、ビットレートの選択を行う。ステップＳ５２９の処理が終了すると、処理はステップＳ５３０に進む。
ステップＳ５３０およびステップＳ５３１の各処理は、ステップＳ１６８およびステップＳ１６９の各処理（図１７）と同様に実行される。ステップＳ５３１の処理が終了すると、再生処理が終了する。
＜ビットレート選択処理の流れ＞
次に、図６７のステップＳ５２９において実行されるビットレート選択処理の流れの例を、図６８のフローチャートを参照して説明する。
ビットレート選択処理が開始されると、メディアデータセグメントファイル選択部１８７は、ステップＳ５５１において、全てのAdaptationSetが最低のLevel of Detailではないか否かを判定する。最低のLevel of DetailではないAdaptationSet（3Dオブジェクト）が存在する（Level of Detailを下げる余地がある）と判定された場合、処理はステップＳ５５２に進む。
ステップＳ５５２において、メディアデータセグメントファイル選択部１８７は、schemeIdUriが"LODRelativeQualityIsEnsuredByLODOrder"のSupplementalPropertyを基に１つずつLevel of Detailの低いAdaptationSetの組み合わせを選択する。
ステップＳ５５３において、メディアデータセグメントファイル選択部１８７は、現在のLevel of Detailにおいて、伝送帯域より小さくなるビットレートの組み合わせを選択することができるか否かを判定する。現在のLevel of Detailにおいて、伝送帯域より小さくなるビットレートの組み合わせが存在しないと判定された場合、処理をステップＳ５５１に戻し、それ以降の処理を繰り返す。つまり、伝送帯域より小さくなるビットレートの組み合わせが見つかるか、全ての3DオブジェクトのLevel of Detailが最低になるまで、ステップＳ５５１乃至ステップＳ５５３の処理が繰り返される。
そして、ステップＳ５５３において、現在のLevel of Detailにおいて、伝送帯域より小さくなるビットレートの組み合わせが存在すると判定された場合、処理はステップＳ５５４に進む。
ステップＳ５５４において、メディアデータセグメントファイル選択部１８７は、各AdaptationSetから、ビットレートの合計が伝送帯域より小さくなるようにRepresentationを選択する。つまり、ステップＳ５５３において検出された「伝送帯域より小さくなるビットレートの組み合わせ」が選択される。ステップＳ５５４の処理が終了すると、ビットレート選択処理が終了し、処理は図６７に戻る。
また、ステップＳ５５１において、全てのAdaptationSet（3Dオブジェクト）のLevel of Detailが最低であり、これ以上Level of Detailを下げる余地がないと判定された場合、処理はステップＳ５５５に進む。
ステップＳ５５５において、メディアデータセグメントファイル選択部１８７は、選択されているAdaptationSetで最低のビットレートになるようにRepresentationを選択する。ステップＳ５５５の処理が終了すると、ビットレート選択処理が終了し、処理は図６７に戻る。
以上のように各処理を実行することにより、3Dオブジェクト間の相対的な品質を維持するように、Level of Detailを下げて、ビットレートを制御することができる。したがって、コンテンツ再生のロバスト性を向上させることができる。
なお、Level of Detailがある一定以上存在していない場合がある。その場合、それ以上Level of Detailを下げることができないため、最低のLevel of Detailの最低のビットレートを選び続けるしかない。しかしながら、その場合、Level of Detailの相対関係が崩れてしまう。それを回避するために次のような手法をできるようにしてもよい。
（１）クライアントで他のQualityに合うように表示時のQualityを下げて表示する。例えば、表示時にガウスぼかしフィルタをその3Dオブジェクトの部分にのみに適用してから表示する。
（２）実施の形態１−１−１または実施の形態１−１−２の場合、クライアント装置１０３は、配信サーバ１０２にさらに低いLevel of Detailを作成させそれを取得する。クライアント装置１０３は、配信サーバ１０２に対し、MPDファイル名、ApdaptationSetのidをリクエストする。配信サーバ１０２は、そのリクエストに応じて指定されたAdaptationSetよりさらに低いLevel of Detailのメッシュデータもしくはテクスチャデータのビットレートバリエーションを作成し、配置する。そして、そのMPDファイル１２２をMPD updateの仕組みを利用しUpdateして、クライアント装置１０３に送信する。クライアント装置１０３は、新しく取得したMPDファイル１２２を基に、再度、Level of Detailを選択する。この場合に、サーバには存在しないが作成可能なLevel of DetailのセグメントファイルをあらかじめMPDとSecene Descriptionにシグナリングしておいてもよい。
＜６−３：実施の形態４−１−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、Level of detailを一律に下げると相対関係が崩れないことをシグナリングするようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
＜６−４：実施の形態４−１−２−１＞
＜新しいノードを定義する＞
例えば、実施の形態１−２−１のClientSelectionノード３０１を拡張し、そのClientSelectionノード３０１のSelectionNodeで示される子ノードにLevel of detailを一律に下げると相対的な品質が維持できることを示すフラグ情報（Flag）をシグナリングするようにしてもよい。より具体的には、LODRelativeQualityIsEnsuredByLODOrderFlagを追加するようにしてもよい。この場合のClientSelectionノード３０１の例を図６９に示す。
＜６−５：実施の形態４−１−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。実施の形態１−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６に、LODRelativeQualityIsEnsuredByLODOrderFlag fieldを拡張するようにしてもよい。図７０にその拡張したBitwrapperノード１５およびMovieTextureノード１６の例を示す。この場合、Bitwrapperノード１５およびMovieTextureノード１６のそれぞれにおいて、LODRelativeQualityIsEnsuredByLODOrderFlag fieldが拡張されている。
＜変形例＞
なお、本手法はLevel of detailの切り替えに関する情報なので、LODノード３１を拡張するようにしてもよい。図７１にその拡張したLODノード３１の例を示す。この場合、LODノード３１にLODRelativeQualityIsEnsuredByLODOrderFlag fieldが拡張されている。
同様に、その他のノードを拡張するようにしてもよい。この場合、シグナリングするノードが少なくなる利点がある。
＜６−６：実施の形態４−２＞
＜Qualityを基にLevel of detailを変更可能であることを示すシグナリング＞
Level of Detailを変更する際に、示されているQualityを基にLevel of Detailを変更することが可能であることを示すようにしてもよい。換言するに、３次元オブジェクトの間の相対的な品質を示す情報に基づいて３次元オブジェクトのLevel of Detailを変更しても、その３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含むメタデータを生成するようにしてもよい。
＜６−７：実施の形態４−２−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、Qualityを基にLevel of detailを変更可能であることを示すシグナリングを行うようにしてもよい。
＜MPDのシグナリング＞
実施の形態４−１−１の場合と同様に、3DオブジェクトのLevel of detailの異なるメッシュのAdaptationSet、または、同じ3Dオブジェクトのテクスチャをグルーピングし、さらに、Qualityを見てLevel of Detail変更をしてもよいことを示すようにしてもよい。
例えば、SupplementalPropertyを用いて、schemeIdUriで、Level of detailを下げる場合にQualityの値を基準することで、各オブジェクトの表示の相対関係を極力維持することができることを示す、" LODRelativeQualityIsEnsuredByQualityValue"をシグナリングする。さらに、SupplementalPropertyのElementにLODGroupを追加する。LODGroupは同じ3Dオブジェクトのメッシュもしくは同じ3DオブジェクトのテクスチャのAdaptationSetのグルーピング情報である。LODGroup のmember attributeでグループに含まれるAdaptationSet@idをシグナリングする。シグナリングされるAdaptationSet@idの順は、高Level of detailから順に並べ、Level of Detailの下げる順を示す。以下に、その例を示す。なお、Quality値のシグナリングは、実施の形態３−２−１で示す手法を用いる。
例：
<SupplementalProperty schemeIdUri= LODRelativeQualityIsEnsuredByQualityValue">
<LODGroup member="as@id1 as@id2..."/>
<LODGroup member="as@id4 as@id5..."/>
</SupplementalProperty>
クライアント装置１０３は、実施の形態３−２−１のクライアント装置１０３の実装をLevel of Detailを下げる場合にも適応し、相対的な品質を維持した組合せでの取得を可能にする。
実際のシグナリング例は、実施の形態３−２−１の図６０に示されるMPDファイル１２２に対し、図６６に示されるMPDファイル１２２のSupplementalPropertyのschemeIdUriをLODRelativeQualityIsEnsuredByQualityValueに変えたものを追加した形になる。
なお、本手法は、実施の形態１−１−１に適用することができる。また、本手法は、LODGroupのmemberが１つのAdaptatonSet@idになり、その中のRepresentationGroupの順にQualityRankingを示すようにすることにより、実施の形態１−１−２にも適用することができる。
＜変形例＞
以下に、他のシグナリング方法の例を示す。
（１）同じ3Dオブジェクトのメッシュやテクスチャのグループ情報をAdaptationSet@groupで識別し、Level of detailの順をSupplementalPropertyで各AdaptationSetにシグナリングする。AdaptationSetのAttributeにシグナリングしてもよい。
（２）同じ3Dオブジェクトのメッシュやテクスチャのグループ情報をAdaptationSet@groupで識別し、Level of detailの順は、Scene Descriptionから取得する。
（３）AdaptationSetで、１つ高いLevel of detailのAdaptationSetと、１つ低いLevel of detailのAdaptationSetをシグナリングする。以下にその例を示す。なお、AdaptationSetのAttributeにシグナリングするようにしてもよい。
<SupplementalProperty schemeIdUri="LowLevelAdaptationSet"
value="AdaptationSet@id">
<SupplementalProperty schemeIdUri="HighLevelAdaptationSet"
value="AdaptationSet@id">
（４）（１）乃至（３）においてはLevel of Detailを一律に下げると相対関係が崩れないことをAdaptationSetでシグナリングする。より具体的には、AdapttionSetに、SupplementalPropertyで、Quality値を基にLevel of detailを下げてもよいAdaptationSetであることをシグナリングする。このシグナリングの例を以下に示す。なお、AdaptationSetのAttributeにシグナリングするようにしてもよい。
例：
<SupplementalProperty schemeIdUri=" LODRelativeQualityIsEnsuredByQualityValue">
（５）Qualityそのものではなく、QulityRankingを用いてもよい。その場合は、3Dオブジェクトのメッシュもしくはテクスチャ全体でQualityRankingを付ける（Level of detailを超えた（AdaptationSetを超えた）QualityRankingになる）。
なお、Level of Detailがある一定以上存在していない場合がある。その場合、それ以上Level of Detailを下げることができないため、最低のLevel of Detailの最低のビットレートを選び続けるしかない。しかしながら、その場合Level of Detailの相対関係が崩れてしまう。それを回避するために次のような手法を用いることができるようにしてもよい。
（１）クライアント装置１０３で他のQualityに合うように表示時のQualityを下げて表示する。たとえば、表示時にガウスぼかしフィルタをその3Dオブジェクトの部分にのみに適用してから表示する。
（２）実施の形態１−１−１または実施の形態１−１−２の場合、クライアント装置１０３は、配信サーバ１０２にさらに低いLevel of Detailを作成させそれを取得する。クライアント装置１０３は、配信サーバ１０２に対し、MPDファイル名、ApdaptationSetのidをリクエストする。配信サーバ１０２は、そのリクエストに応じて指定されたAdaptationSetよりさらに低いLevel of Detailのメッシュデータまたはテクスチャデータのビットレートバリエーションを作成し、配置する。そして、そのMPDファイル１２２を、MPD updateの仕組みで Updateして、クライアント装置１０３に送信する。クライアント装置１０３は、新しく取得したMPDファイル１２２を基に、再度、Level of Detailを選択する。この場合に、サーバには存在しないが作成可能なLevel of DetailのセグメントファイルをあらかじめMPDとSecene Descriptionにシグナリングしておいてもよい。
＜６−８：実施の形態４−２−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、Qualityを基にLevel of detailを変更可能であることを示すシグナリングを追加するようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
＜６−９：実施の形態４−２−２−１＞
＜新しいノードを定義する＞
例えば、実施の形態３−２−２−１のClientSelectionノード３０１を拡張して、本手法のシグナリングを実現するようにしてもよい。この場合のClientSelectionノード３０１の例を図７２に示す。図７２に示されるように、このClientSelectionノード３０１において、SelectionNodeで示される子ノードがQuality値を基にLevel of detailを選択してもよいことを示すFlagがシグナリングされる。より具体的には、LODRelativeQualityIsEnsuredByQualityValueが追加される。
＜変形例＞
例えば、Qualityそのものではなく、QualityRankingを用いるようにしてもよい。その場合、実施の形態４−２−１において説明したように、3Dオブジェクトのメッシュまたはテクスチャ全体でQualityRankingを付けるようにしてもよい。QualityRankingのシグナリングは、実施の形態３−１−２−１において説明した手法となり、それに、各オブジェクトの表示の相対関係を極力維持することができることを示す、LODRelativeQualityIsEnsuredByQualityRanking fieldを追加すればよい。
＜６−１０：実施の形態４−２−２−２＞
＜既存のノードを拡張する＞
なお、実施の形態３−２−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６に、上述のLODRelativeQualityIsEnsuredByLODOrderFlag fieldを拡張するようにしてもよい。その場合のBitwrapperノード１５およびMovieTextureノード１６の例を図７３に示す。図７３に示されるように、この場合、Bitwrapperノード１５およびMovieTextureノード１６のいずれにも、上述のLODRelativeQualityIsEnsuredByLODOrderFlag fieldが追加されている。
＜変形例＞
なお、Qualityそのものではなく、QualityRankingを用いるようにしてもよい。その場合、実施の形態４−２−１において上述したように、3Dオブジェクトのメッシュまたはテクスチャ全体でQualityRankingを付けるようにする。このQualityRankingのシグナリングは、実施の形態３−１−２−２の場合と同様に行えば良い。それに、LODRelativeQualityIsEnsuredByQualityRanking fieldを追加することにより、本手法を適用することができる。
本手法はLevel of detailの切り替えに関する情報なので、LODノード３１を拡張するようにしてもよい。ただし、Quality値のシグナリングは必要であるため、実施の形態３−２−２−１において拡張したClientSelectionノード３０１または実施の形態３−２−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６のシグナリングは必要である。図７４にそのLODノード３１の拡張例を示す。この場合、シグナリングするノードが少なくなる利点がある。また、他のノードを同様に拡張するようにしてもよい。
＜６−１１：実施の形態４−３＞
＜Level of detailにQualityRankingをシグナリングする＞
Level of detailにもQualityRankingをシグナリングし、クライアント装置１０３は、そのQualityRankingを基にLevel of Detailを切り替えるようにしてもよい。
＜６−１２：実施の形態４−３−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、Level of detailにQualityRankingをシグナリングするようにしてもよい。
＜MPDのシグナリング＞
実施の形態４−１−１の場合と同様に、Periodにシグナリングする。例えば、実施の形態４−１−１に、LODGroupのattributeにQualityRankingを追加する。SupplementalProperty のLODRelativeQualityIsEnsuredByLODQualityRankingを示すことで、Level of detailごとに設定されているQualityRankingの相対関係を崩さないようにLevel of detailを選択することで、品質の相関を維持することができる。以下に例を示す。なお、membaer[n]のQualityRankingは、QualityRanking[n]である。
例：
<SupplementalProperty
schemeIdUri="LODRelativeQualityIsEnsuredByLODQualityRanking">
<LODGroup member="as@id1 as@id2..." QualityRanking="1 2…"/>
<LODGroup member="as@id4 as@id5..." QualityRanking="1 2…"/>
</SupplementalProperty>
本手法は、例えば実施の形態１−１−１に適用することができる。なお、LODGroupのmemberが１つのAdaptatonSet@idになり、その中のRepresentationGroupの順にQualityRankingを示すことで、本手法を実施の形態１−１−２にも適用することができる。
＜変形例＞
なお、シグナリング方法は上述の例に限らない。例えば、以下のようにしてもよい。
（１）同じ3Dオブジェクトのメッシュやテクスチャのグループ情報をAdaptationSet@groupで識別し、Level of detailのQualityRankingをSupplementalPropertyで各AdaptationSetにシグナリングする。AdaptationSetのAttributeでシグナリングしてもよい。
（２）AdaptationSetで、１つ高いLevel of detailのAdaptationSetと、１つ低いLevel of detailのAdaptationSetをシグナリングする。以下にその例を示す。なお、AdaptationSetのAttributeにシグナリングするようにしてもよい。
<SupplementalProperty
schemeIdUri="LowLevelAdaptationSet" value="AdaptationSet@id">
<SupplementalProperty
schemeIdUri="HighLevelAdaptationSet" value="AdaptationSet@id">
（３）（１）および（２）においては、Level of DetailのQualityRankingを基に選択すると相対関係が崩れないことをAdaptationSetでシグナリングする。より具体的には、AdapttionSetに、SupplementalPropertyで、QualityRanking値を元にLevel of detailを下げると品質の相対関係が維持できるAdaptationSetであることを示すシグナリングを行う。以下にその例を示す。なお、AdaptationSetのAttributeでシグナリングするようにしてもよい。
例：
<SupplementalProperty
schemeIdUri=" LODRelativeQualityIsEnsuredByLODQualityRanking">
＜６−１３：実施の形態４−３−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、Level of detailにQualityRankingをシグナリングするようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
＜６−１４：実施の形態４−３−２−１＞
＜新しいノードを定義する＞
Scene Descriptionデータ１２１を拡張するにあたって、既存のノードはそのまま利用し、ビットレートアダプテーションのために新しいノードを追加するようにしてもよい。例えば、実施の形態１−２−１において説明したClientSelectionノード３０１を拡張するようにしてもよい。
そのClientSelectionノード３０１の拡張例を図７５に示す。例えば、ClientSelectionノード３０１において、SelectionNode fieldにLevel of detailを一律に下げると相対的な品質が維持できることを示すFlagをシグナリングする。より具体的には、LODRelativeQualityIsEnsuredByLODQualityRanking fieldを追加し、LODQualityRankingを設定する。
＜６−１５：実施の形態４−３−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。例えば、実施の形態１−２−２のBitwrapperノード１５およびMovieTextureノード１６にLODRelativeQualityIsEnsuredByLODQualityRanking fieldを拡張するようにしてもよい。これは、図７０のBitwrapperノード１５およびMovieTextureノード１６のLODRelativeQualityIsEnsuredByLODOrderFlag fieldを、図７５のClientSelectionノード３０１のLODRelativeQualityIsEnsuredByLODQualityRanking fieldで置き換えたものになる。
＜変形例＞
本手法は、Level of detailの切り替えに関する情報なので、LODノード３１を拡張するようにしてもよい。この場合、シグナリングするノードが少なくなる利点がある。これは、図７１に示されLODノード３１のLODRelativeQualityIsEnsuredByLODOrderFlag fieldを、図７５のLODRelativeQualityIsEnsuredByLODQualityRanking fieldで置き換えたものになる。もちろん、これ以外のノードを拡張するようにしてもよい。
＜７．第５の実施の形態（実施の形態５）＞
＜コンテンツオーサなどの意図を示すシグナリング＞
さらに、コンテンツオーサが意図する3Dオブジェクトの重要度情報をシグナリングするようにしてもよい。なお、例えば、第４の実施の形態のフラグ情報（flag）があってもなくても、この手法を使うか否かはクライアントが選択するようにしてもよい。また、Level of detailのレベルによって重要度の有効・無効を設定することができるようにしてもよい。
例えば、シーン中に、コンテンツオーサなどが意図する重要である3Dオブジェクトと、重要でない3Dオブジェクトとが混在する場合に、その情報には関係なく、Level of detailを下げてしまうと、ユーザがコンテンツオーサなどの意図が反映されたシーンを見ることができない可能性がある。
そこで、コンテンツオーサが意図する3Dオブジェクトの重要度情報をシグナリングすることにより、上述のような場合に、重要な3DオブジェクトのLevel of detailを下げることを抑制することができる。これにより、ユーザは、コンテンツオーサなどの意図が反映されたシーンを見ることができる。
＜７−１：実施の形態５−１＞
＜重要度(数値)のシグナリング＞
例えば、3Dオブジェクトの重要度のシグナリングとして、各3Dオブジェクトがシーン中でどれぐらい重要であるかを数値で示すようにしてもよい。換言するに、３次元オブジェクトの重要度を示す情報をさらに含むメタデータを生成するようにしてもよい。
＜７−２：実施の形態５−１−１＞
＜Scene DescriptionとMPDを用いた構成で実現する＞
例えば、DASHのMPDファイルとScene Descriptionデータを用いた構成により、3Dオブジェクトの重要度のシグナリングを行うようにしてもよい。
＜７−３：実施の形態５−１−１−１＞
＜MPDの拡張＞
各3DオブジェクトのメッシュおよびテクスチャのAdaptationSetに、その3Dオブジェクトの重要度を示す値をシグナリングする。重要度は、例えば値が小さいほど重要であるものとする。もちろん、重要度は、この例に限定されず、例えば、値が大きい程重要であるものとしてもよい。
より具体的には、第４の実施の形態のSupplementalPropertyのLODGroupに、Important3Dobject attributeを追加し、そのvalue値で重要度情報をシグナリングするようにしてもよい。3DオブジェクトのメッシュのLODGroupとテクスチャのLODGroupは値を同じにしなければならない。以下にその例を示す。
<LODGroup member="1 3 5" Important3Dobject="1"/>
この場合のMPDファイル１２２の例を図７６に示す。この場合、3Dオブジェクトが３つあり、それぞれに高中低の３つのLevel of detailをもつ。各AdaptationSetに、重要度情報がImportant3Dobject attributeの値としてシグナリングされている。例えば、3DオブジェクトAは、重要度１、3DオブジェクトBとCは重要度２としている。
この図７６のMPDファイル１２２において、3DオブジェクトAは、高Level of detail（AdaptationSet@id=1と2）、3DオブジェクトBは中Level of detail（AdaptationSet@id=9と10）、3DオブジェクトCは中Level of detail（AdaptationSet@id=15と16）が適切なLevel of detailであると選択されている場合、その組合せの中でビットレートを下げても合計ビットレートが伝送帯域より多くなってしまうときは、Level of detailを変更する。その際、SupplementalPropertyを参考に、Important3Dobjectのvalue値の大きなものをまず、全てで１つずつ低いLevel of detailを選択する。つまり、Valueが２である3DオブジェクトBとCのLevel of detailを１つ下げ、3DオブジェクトBは低Level of detail（AdaptationSet@id=11と12）、3DオブジェクトCは低Level of detail（AdaptationSet@id=17と18）になり、その中からビットレートを選択する。それでも、足りない場合は、valueが1である3Dオブジェクトである3DオブジェクトAのLevel of detailを１つ下げ、中Level of detail（AdaptationSet@id=3と4）を選択し、ビットレートを下げる。
＜変形例＞
この場合、LODGroupに含まれるLevel of Detailが全て同じ重要度となる。Level of Detailによって重要度を変えたい場合（例えば、高Level of detailの場合の重要度は高いが、それ以外の場合の重要度は低くするなど）もある。その場合には、Level of detail毎に値をコンマ区切りで指定すればよい。以下にその例を示す。
<LODGroup member="1 3 5" Important3Dobject="1,2,2"/>
また、一部の3Dオブジェクトのみにシグナリングがあってもよい。その場合、値を設定しない。シグナリングがないものは、重要度が存在しない、つまり、重要度が低いものとして扱えばよい。以下にその例を示す。
<LODGroup member="1 3 5" Important3Dobject="1,,"/>
その他、実施の形態４−１−１のその他のシグナリング例にあるようなAdaptationSet単位でシグナリングする場合は、Important3Dobject もAdaptationSetでシグナリングするようにしてもよい。その場合、SupplementalPropertyでImportant3Dobjectのみをシグナリングするようにしてもよい。
また、重要であるか否かを示すだけでも良い。その際、Level of Detail毎に、重要であるか否かを１か０のフラグ情報（flag）で指定することができるようにしてもよい。
重要度情報は、Level of Detailを切り替える際に利用するだけでなく、Level of detail内のビットレートを選択する際にも利用することができるようにしてもよい。
＜ビットレート選択処理の流れ＞
クライアント装置１０３は、3Dオブジェクトの重要度で、どのLevel of Detailからビットレートを上げるか下げるかを決定する。たとえば、伝送帯域が足りない場合は、重要度の低いものからLevel of Detailを下げていく。クライアント装置１０３は、第４の実施の形態を適用する場合であってもなくても、この値のみからLevel of Detailの切り替えを制御するようにしてもよい。
なお、この場合、再生処理は、図６７のフローチャートを参照して説明した場合と同様に実行される。図７７のフローチャートを参照して、この場合の、ステップＳ５２９において実行されるビットレート選択処理の流れの例を説明する。
ビットレート選択処理が開始されると、メディアデータセグメントファイル選択部１８７は、ステップＳ５７１において、全てのAdaptationSetが最低のLevel of Detailではないか否かを判定する。最低のLevel of DetailではないAdaptationSet（3Dオブジェクト）が存在する（Level of Detailを下げる余地がある）と判定された場合、処理はステップＳ５７２に進む。
ステップＳ５７２において、メディアデータセグメントファイル選択部１８７は、schemeIdUriが"LODRelativeQualityIsEnsuredByLODOrder"のSupplementalPropertyから、Important3Dobjectの最大値を取得し、その最大値を変数ａに設定する。
ステップＳ５７３において、メディアデータセグメントファイル選択部１８７は、その変数ａが０でないか否かを判定する。変数ａが０（a = 0）であると判定された場合、処理は、ステップＳ５７１に戻り、それ以降の処理が繰り返される。
つまり、全てのAdaptationSetが最低のLevel of Detailであると判定されるか、または変数ａが０でないと判定されるまで、ステップＳ５７１乃至ステップＳ５７３の処理が繰り返される。そして、ステップＳ５７３において、変数ａが０でないと判定された場合、処理はステップＳ５７４に進む。
ステップＳ５７４において、メディアデータセグメントファイル選択部１８７は、Improtant3DobjectがaであるLODGroupのAdaptationSetを１つLevel of detailの低いものを選択する。
ステップＳ５７５において、メディアデータセグメントファイル選択部１８７は、Level of Detailを変更したAdaptationSetのみのビットレートを選択し直して、伝送帯域より小さくすることができるか否かを判定する。ビットレートを伝送帯域より小さくすることができないと判定された場合、処理はステップＳ５７６に進む。
ステップＳ５７６において、変数aの値が−1される（１で減算される）。ステップＳ５７６の処理が終了すると、処理はステップＳ５７３に戻り、それ以降の処理が繰り返される。
つまり、変数ａが０であると判定されるか、ビットレートを伝送帯域より小さくすることができると判定されるまで、ステップＳ５７３乃至ステップＳ５７６の処理が繰り返される。そして、ステップＳ５７５において、ビットレートを伝送帯域より小さくすることができると判定された場合、処理はステップＳ５７７に進む。
ステップＳ５７７において、メディアデータセグメントファイル選択部１８７は、伝送帯域より小さくすることができるRepresentationを選択する。ステップＳ５７７の処理が終了すると、ビットレート選択処理が終了し、処理は再生処理に戻る。
また、ステップＳ５７１において、全てのAdaptationSetが最低のLevel of Detailであり、Level of Detailを下げる余地がないと判定された場合、処理はステップＳ５７８に進む。
ステップＳ５７８において、メディアデータセグメントファイル選択部１８７は、選択されているAdaptationSetで最低のビットレートになるように、Representationを選択する。ステップＳ５７８の処理が終了すると、ビットレート選択処理が終了し、処理は再生処理に戻る。
つまり、重要度の低い3DオブジェクトのLevel of detailを１つ下げ、次に重要度の低い3DオブジェクトのLevel of detailを１つ下げる・・・という順に処理を進める。このようにすることにより、コンテンツオーサ等の意図する重要度を反映した再生を行うことができる。
なお、重要度の低い3DオブジェクトのLevel of detailを下げられるところまで下げて、その後に、次に重要度の低い3DオブジェクトのLevel of detailを下げられるところまで下げる・・・という順で処理を進めるようにしてもよい。
＜７−４：実施の形態５−１−２＞
＜Scene Descriptionのみを用いた構成で実現する＞
なお、実施の形態１−２のようにScene Descriptionのみを用いる場合において、コンテンツオーサが意図する3Dオブジェクトの重要度情報をシグナリングするようにしてもよい。つまり、この場合、DASHのMPDファイル１２２は利用しない。
＜７−５：実施の形態５−１−２−１＞
＜新しいノードを定義する＞
例えば、実施の形態１−２−１のClientSelectionノード３０１を拡張し、3Dオブジェクトの重要度情報をシグナリングするようにしてもよい。より具体的には、Important3Dobjectを追加するようにしてもよい。重要度は値が小さいほど重要であるとする。しかしながら、フィールドがない場合の初期値でもある0は重要度が設定されていないものとする。もちろん重要度の表現方法は任意であり、この例に限定されない。
この場合のClientSelectionノード３０１の例を図７８に示す。図７８に示されるように、この場合のClientSelectionノード３０１には、3Dオブジェクトの重要度を設定するImportant3Dobject fieldが追加されている。
＜７−６：実施の形態５−１−２−２＞
＜既存ノードを拡張する＞
上述のように新しいノードを定義する代わりに、既存のノードを拡張するようにしてもよい。実施の形態１−２−２において拡張したBitwrapperノード１５およびMovieTextureノード１６に、Important3Dobject fieldを拡張するようにしてもよい。図７９にその拡張したBitwrapperノード１５およびMovieTextureノード１６の例を示す。この場合、Bitwrapperノード１５およびMovieTextureノード１６のそれぞれにおいて、Important3Dobject fieldが追加されている。
＜変形例＞
なお、3Dオブジェクト毎に重要度が決まる場合にはTransformノード１２を拡張するようにしてもよい。図８０は、その拡張したTransformノード１２の例を示す図である。図８０に示されるように、この場合のTransformノード１２には、Important3Dobject fieldが追加されている。このようにすることにより、シグナリングするノードが少なくなる利点がある。なお、この例では、Transformノード１２を拡張したが、他のノードを新しく規定しても良いし、その他のノード（例えばShapeノード１３等）を拡張するようにしてもよい。
＜８：第６の実施の形態（実施の形態６）＞
＜ユーザの注目している3DオブジェクトのLevel of detailを保つための実装法＞
さらに、ユーザが注目している3Dオブジェクトを識別して、その3DオブジェクトのLevel of detailを保つことができるようにしてもよい。
＜８−１：実施の形態６−１＞
＜クライアント装置１０３の実装例＞
伝送帯域が不足する場合、クライアント装置１０３は、以下のルールを適用し、ビットレートを選択するようにしてもよい。換言するに、注目する３次元オブジェクトの重要度を指定する情報をさらに含むメタデータを生成するようにしてもよい。
（１）ユーザの注目している点を取得する。
（２）その注目している点にある3Dオブジェクトを、Scene Descriptionの位置情報から求める。
（３）注目している3Dオブジェクトを重要度１とする。その他の3Dオブジェクトの重要度は２とする。
（４）そして、第５の実施の形態の場合と同様のアルゴリズムでビットレートを選択する。
＜ビットレート選択処理の流れ＞
この場合、再生処理は、図６７のフローチャートを参照して説明した場合と同様に実行される。図８１のフローチャートを参照して、この場合の、ステップＳ５２９において実行されるビットレート選択処理の流れの例を説明する。
ビットレート選択処理が開始されると、メディアデータセグメントファイル選択部１８７は、ステップＳ５９１において、全てのAdaptationSetが最低のLevel of Detailではないか否かを判定する。最低のLevel of DetailではないAdaptationSet（3Dオブジェクト）が存在する（Level of Detailを下げる余地がある）と判定された場合、処理はステップＳ５９２に進む。
ステップＳ５９２において、メディアデータセグメントファイル選択部１８７は、schemeIdUriが"LODRelativeQualityIsEnsuredByLODOrder"のSupplementalPropertyから、Important3Dobjectの最大値を取得し、その最大値を変数ａに設定する。
ステップＳ５９３において、メディアデータセグメントファイル選択部１８７は、ユーザの位置や視線方向等と、Scene Descriptionデータ１２１に記述されている各3Dオブジェクトの位置情報とから、ユーザが注目している3Dオブジェクトを求める。
ステップＳ５９４において、メディアデータセグメントファイル選択部１８７は、ステップＳ５９３において検出したユーザが注目している3Dオブジェクトの重要度を１とし、それ以外の3Dオブジェクト、すなわち、ユーザが注目していない3Dオブジェクトの重要度を２とする。さらに、変数a = 2とする。
ステップＳ５９５乃至ステップＳ６００の各処理は、ステップＳ５７３乃至ステップＳ５７８の各処理（図７７）と同様に実行される。
ステップＳ５９９またはステップＳ６００の処理が終了すると、ビットレート選択処理が終了し、処理は再生処理に戻る。
このようにビットレート選択処理を行うことにより、ユーザが注目している3Dオブジェクトを識別し、その3DオブジェクトのLevel of detailを下げないようにすることができる。したがって、ユーザの主観的な6DoFコンテンツの品質の低減を抑制することができる。
＜変形例＞
なお、注目している3Dオブジェクトの重要度を１、注目されていないが表示されている3Dオブジェクトの重要度を２、それ以外の重要度を３として、表示されていないものからLevel of detailを下げるようにしてもよい。
また、重要度の割り当てをより細分化して、注目されていないが表示されている3Dオブジェクトを、注目している3Dオブジェクトに近い表示されている3Dオブジェクトと、そうでない3Dオブジェクトとで重要度を変える（それぞれに互いに異なる重要度を割り当てる）ようにしてもよい。
さらに、注目していない3DオブジェクトのLevel of Detailを最低レベルまで下げた後、注目している3DオブジェクトのLevel of Detailを下げるようにしてもよい。
また、Level of detail内のビットレート選択の際にも同様に、注目していない3Dオブジェクトからビットレートを下げるようにしてもよい。
＜９：第７の実施の形態（実施の形態７）＞
＜３D空間内にある１つの物体を複数の部分の３Dオブジェクトで構成する場合のシグナリング＞
第１の実施の形態は、３D空間内に存在する物体ごとに３Dオブジェクトとする場合である。物体が複数の部分の３Dオブジェクトで構成される場合においても、この第１の実施の形態の場合と同様にLevel of detail毎にビットレートアダプテーションすることができるようにしてもよい。
例えば、図８２のように円柱の物体Aを分割し、３DオブジェクトA1、３DオブジェクトA2、３DオブジェクトA3、および３DオブジェクトA4の４つの部分に分けるとする。この場合、それぞれの３Dオブジェクトがメッシュデータとテクスチャデータで構成される。
＜９−１：実施の形態７−１＞
＜Scene Descriptionにおいて部分毎の３Dオブジェクトをシグナルする＞
このような全ての部分毎の３DオブジェクトをScene Descriptionにおいてシグナルする。例えば、実施の形態１において説明した手法において、Scene Descriptionで部分毎の３Dオブジェクトをシグナリングする。このようにすることで、実施の形態１において説明した手法と同じ拡張を用いて実施することができる。
例えば、Scene DescriptionとMPDの構成を用いる実施の形態１−１−１の拡張を適用することができる。図８２に示されるように物体Aを４つの３Ｄオブジェクトにする例について実施の形態１−１−１を適用した場合、Scene Descriptionデータ１２１は、例えば図８３に示されるような構成となる。図８３において、３ＤオブジェクトA2乃至３ＤオブジェクトA4についてLoDノード以下の構成は、３ＤオブジェクトA1の場合と同様であるので、その説明は省略する。
図８３に示されるように、実施の形態１−１−１の拡張を適用することにより、物体Ａの一部分である３ＤオブジェクトA1乃至３ＤオブジェクトA4のそれぞれを、個別の3Dオブジェクトとしてシグナルすることができる。
もちろん、実施の形態１−１−１だけでなく、実施の形態１−１以下にある全ての実施の形態（実施の形態１−１−１、実施の形態１−１−２、実施の形態１−１−２−１、実施の形態１−１−２−２、実施の形態１−１−３）において説明した各手法も、図８２の例のような、分割されている３Ｄオブジェクトに対して、適用することができる。
例えば、Scene Descriptionのみを用いる実施の形態１−２−１の拡張を適用してもよい。図８２に示されるように物体Aを４つの３Ｄオブジェクトにする例について実施の形態１−２−１を適用した場合、Scene Descriptionデータ１２１は、例えば図８４に示されるような構成となる。図８４において、３ＤオブジェクトA2乃至３ＤオブジェクトA4についてLoDノード以下の構成は、３ＤオブジェクトA1の場合と同様であるので、その説明は省略する。また、3DオブジェクトA1の中Level of Detail A1MのShapeノード以下の構成は、3DオブジェクトA1の高Level of Detail A1Hの場合と同様であるので、その説明は省略する。同様に、3DオブジェクトA1の低Level of Detail A1LのShapeノード以下の構成も、3DオブジェクトA1の高Level of Detail A1Hの場合と同様であるので、その説明も省略する。
図８４に示されるように、実施の形態１−２−１の拡張を適用することにより、物体Ａの一部分である３ＤオブジェクトA1乃至３ＤオブジェクトA4のそれぞれを、個別の3Dオブジェクトとしてシグナルすることができる。これにより、３ＤオブジェクトA1乃至３ＤオブジェクトA4のそれぞれに、個別にアクセスすることができる。
もちろん、実施の形態１−２−１だけでなく、実施の形態１−２以下にある全ての実施の形態（実施の形態１−２−１および実施の形態１−２−２）において説明した各手法も、図８２の例のような、分割されている３Ｄオブジェクトに対して、適用することができる。
以上のように実施の形態１を適用する手法は、部分毎の３DオブジェクトをScene Descriptionでシグナルし、個別にアクセス可能にする。ただし、この手法の場合は、元々１つの物体であるかどうかまではわからない。
＜９−２：実施の形態７−２＞
＜Scene Descriptionにおいて、物体全体をシグナルし、その物体が複数の３Dオブジェクトで構成されることをシグナルする＞
そこで、Scene Descriptionにおいて、１つの物体が存在している情報までをシグナルし、さらに、MPDの複数のメッシュデータおよびテクスチャデータへアクセスできるようにシグナルしてもよい。
例えば、図８５に示されるように、Scene Descriptionデータ１２１において物体Ａ全体の情報のみをシグナルする。そして、その物体ＡのBitwrapperノードおよびMovie textureノードのアクセス情報で、DASHのMPDファイル１２２の複数のメッシュデータまたはテクスチャデータをシグナルし、それらを全て利用することができるようにする。
＜９−３：実施の形態７−２−１＞
＜部分ごとの３ＤオブジェクトのLevel of DetailごとにAdaptationSetとする場合＞
図１２および図１３に示される例のように、Level of Detail毎にAdaptationSetとする構成によって、複数の３Ｄオブジェクトで構成される物体を表現するようにしてもよい。この場合、物体が複数の３Ｄオブジェクトで構成されることを示すために、Scene DescriptionのBitwrapperノード１５およびMovieTextureノード１６のアクセス情報から複数のAdaptationSetをシグナルする必要がある。
＜９−４：実施の形態７−２−１−１＞
＜URL queryを拡張し複数のAdaptationSetをシグナルする＞
Scene Descriptionの物体のメッシュデータへのアクセス情報を持つBitwrapperノード、テクスチャデータへのアクセス情報を持つMovieTextureノードから、MPDファイルの複数の部分のメッシュデータまたはテクスチャデータのAdaptationSetへアクセスすることができるように拡張し、それらのAdaptationSetを同時に利用する必要があることを示すようにしてもよい。
Bitwrapperノード、MovieTextureノードではURLを用いて外部メディアデータへのアクセス情報をシグナルしている。MPEG-4 Scene Description(ISO/IEC 14496-11)のBitwrapperノードおよびMovieTextureノードの構造例は、図２に示した通りである。外部メディアデータへのアクセスに使われるフィールド（field）はどちらのノードもurl fieldである。本実施の形態では、BitwrapperノードおよびMovieTextureノードのsyntaxは拡張せず、それぞれのurl fieldの表記方法を拡張する。
本実施の形態では、url fieldで示すURLをMPDファイルへのURLに加えてURLパラメータで複数のAdaptationSet@idをシグナリングし、これらを同時に利用しないといけないことを示す。具体的には、例えばAdaptationSetを表すURLパラメータの変数"requiredASList"を用い、その値で物体を構成する部分3DオブジェクトのテクスチャデータもしくはメッシュデータのAdaptationSet@idをセミコロン切りでシグナリングする。例えば、物体Aが、AdaptationSet@id=1、２、３、４から構成される場合は、以下の例のようにURLパラメータのついたURLをノードのURLに指定する。
URLの例：http://www.6dofserver.com/6dof.mpd?requiredASList=1;2;3;4
＜９−５：実施の形態 ７−２−１−２＞
＜Scene Descriptionのノードを拡張する＞
Scene DescriptionデータのBitwrapperノードやMovieTextureノードに、物体を構成する複数の部分3DオブジェクトのテクスチャデータもしくはメッシュデータのAdaptationSet@idを示すfieldを追加する拡張をしてもよい。この場合、url fieldは、MPDファイルへのアクセス情報を記述する。
例えば、図８６に示されるように、Scene DescriptionデータのBitwrapperノード１５やMovieTextureノード１６に、新しいfieldであるRequiredAdaptationSetIdsを追加し、このfieldで、物体を構成するのに必要なAdaptationSetの@idを文字列の配列として格納する。
また、以上においてはBitwrapperノードおよびMovieTextureノードの拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
＜９−６：実施の形態７−２−１−３＞
＜MPD拡張＋URL queryもしくはノード拡張でシグナルする＞
MPDにおいて１つの物体を構成する部分3DオブジェクトのAdaptationSetを識別できるように識別子をシグナルし、その識別子をScene Descriptionからシグナルするようにしてもよい。
例えば、AdaptationSetにある物体のメッシュデータを示すidをシグナルするようにしてもよい。この場合、テクスチャとメッシュおよびLevel of Detailごとにidを変える。
例えば、AdaptationSetに、SupplementalProperty descriptionをシグナルし、schemeIdUriで"ObjectPartsId"をシグナルする。これにより、3Dオブジェクトの一部であり、同じvalue値のAdaptationSetで1つの物体を示すことを表す。valueには識別するための値を入れる。
例：<SupplementalProperty schemeIdUri="ObjectPartsID" value="1">
さらに、図８７に、物体Ａが４つの部分３Ｄオブジェクトで構成される場合のMPDを示す。この例では、メッシュデータのみを示している。
＜変形例＞
Periodで物体を構成する部分3Dオブジェクトのグループをシグナルしてもよい。例えば、schmeIdUriでObjectPartsGroupを示すようにする。グルーピング情報は、グループ毎にSupplementalPropertyのエレメント（element）としてOPGを新しく追加する。OPGは、id（ObjectPartsIdのvalueと同じ意味）と、グループに含まれるAdaptationSetのidのリストから成る。
その例を図８８に示す。図８８は、物体Ａのメッシュデータが４つのAdaptationSetから構成されており、OPGのmemberで４つのAdaptationSet@idが紐づいている。
＜Scene Descriptionのシグナリング＞
Scene DescriptionのBitwrapperノードやMovieTextureノードのアクセス情報として、MPDのObjectPartsIDの値、もしくは、OPG elementのidの値を示せばよい。
例えば、BitwrapperノードやMovieTextureノードのUrl fieldで、MPDのURLにURL queryで示す。URLパラメータの変数"ObjectPartId"を用い、その値でMPDのObjectPartsIDもしくは、OPG elementのidを示す。図８７や図８８の例の場合、以下の例のようにURLパラメータのついたURLをノードのURLに指定する。
URLの例：http://www.6dofserver.com/6dof.mpd?ObjectPartId=1
別のシグナリングとしては、BitwrapperノードやMovieTextureノードにObjectPartIdを示すfiledを追加する手法である。図８９に示されるように、ObjectPartIdを追加し、その値でMPDのObjectPartsIDまたはOPG elementのidを示す。
また、以上においてはBitwrapperノードおよびMovieTextureノードの拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
＜９−７：実施の形態７−２−２＞
＜部分毎の３ＤオブジェクトのLevel of Detailに関わらず１つのAdaptationSetとする場合＞
図２１、図２２に示されるように、Level of Detailに関わらず１つのAdaptationSetで同じ部分の３Ｄオブジェクトがシグナルされる構成で、物体が複数の3Dオブジェクトで構成されてもよい。
この場合、物体Ａが複数の３Ｄオブジェクトで構成されることを示すために、Scene DescriptionのBitwrapperノード、MovieTextureノードのアクセス情報から複数のAdaptationSetとそのAdaptationSetごとに複数のRepresentationをシグナルする必要がある。
＜９−８：実施の形態７−２−２−１＞
＜URL queryで拡張する＞
SceneDescriptionは物体ごとでシグナルしているため、Scene Descriptionデータのメッシュを示すノードであるBitwrapperノードや、テクスチャを示すノードであるMovieTextureノードから、全ての部分の3DオブジェクトのAdaptationSetと、さらにそれらのAdaptationSetに含まれる、適切なLODのビットレートバリエーションのRepresentationを示す必要がある。
そこで、Scene DescriptionデータのBitwrapperノードやMovieTextureノードのアクセス情報（例えばURL）を拡張する。
より具体的には、AdaptationSetとそこに含まれるRepresentationを表すURLパラメータの変数である"requiredASRSList"とその値により全ての部分3DオブジェクトのAdaptationSet@idとその中で利用するRepresentation@idが示されるようにする。
例えばURLパラメータの変数"requiredASRSList"を用い、その値で物体を構成する部分3Dオブジェクトのテクスチャデータもしくはメッシュデータを示す。値としては、AdaptationSet@idをコロンで区切りそのあとに利用するRepresentation@idをコンマ区切りで示す。さらに複数のAdaptationSetをシグナルするためにセミコロン切りでシグナリングする。例えば、物体Aが、AdaptationSet@id=1、２、３、４から構成され、AdaptationSet@id=1ではRepresentation@id=11,12を利用、AdaptationSet@id=2ではRepresentation@id=21,22を利用、AdaptationSet@id=3ではRepresentation@id=31,32を利用、AdaptationSet@id=4ではRepresentation@id=41,42を利用する場合は、以下の例のようにURLパラメータのついたURLをノードのURLに指定する。
http://www.6dofserver.com/6dof.mpd?requiredASRSList=1:11,12;2:21,22;3:31,32;4:41,42
＜９−９：実施の形態７−２−２−２＞
＜Scene Descriptionのノードを拡張する＞
Scene DescriptionデータのBitwrapperノードやMovieTextureノードに、物体を構成する複数のAdaptationSet@idとビットレートバリエーションのRepresentation@idを示すfieldを追加する拡張をしてもよい。この場合、url fieldは、MPDファイルへのアクセス情報を記述する。
図９０に示されるように、Scene DescriptionデータのBitwrapperノード１５やMovieTextureノード１６に、requiredASRSList fieldを追加する。fieldの値としては、実施の形態７−２−２−１で利用した構造である、AdaptationSet@idをコロンで区切りそのあとに利用するRepresentation@idをコンマ区切りにした文字列を複数格納する。
また、以上においてはBitwrapperノードおよびMovieTextureノードの拡張例を示したが、他のノードで同様のfieldを拡張するようにしてもよい。
＜９−１０：実施の形態７−２−２−３＞
＜MPD拡張＋URL queryもしくはノード拡張でシグナルする＞
実施の形態１−１−２−２のRepresentationGroupを用いて、Scene Descriptionから複数の部分3Dオブジェクトをシグナルできるように拡張してもよい。
また、Scene Descriptionデータにおいては、BitwrapperノードおよびMovieTextureノードのアクセス情報（URL）に実施の形態１−１−２−２のRepresentationのグループを複数示すようにする。
MPDファイルのURLパラメータに、AdaptationSetを示すパラメータと、RepresentationGroupを示すパラメータを複数シグナルする。例えば、URLパラメータをrequiredASRGListとして、値としてAdaptationSet@idとコロンでRepresentationGroupのidを示す。複数部分の3Dオブジェクトを示すために、セミコロンで区切る。以下にそのURLの例を示す。
URLの例：http://www.6dofserver.com/6dof.mpd?requiredASRGList =1:1;2:1;3:1;4:1
変形例として、BitwrapperノードやMovieTextureノードを拡張してもよい。実施の形態７−２−２−２の拡張のように、上記のrequiredASRGListをBitwrapperノードやMovieTextureノードとして追加する。
また、変形例として、実施の形態７−２−１−３のObjectPartIdを、Representationにシグナルしてもよい。この時には、LODごとにidを分ける。このようにすると、実施の形態７−２−１−３と同様のシグナルが可能である。実施の形態７−２−１−３のようにPeriodでシグナルする場合、以下のようなSupplementalPropertyを追加すればよい。OPG elementに新しくOPGmember elementを追加し、それぞれの部分3DオブジェクトのAdaptationSet@idと、ビットレートバリエーションのRepresentation@idをASIdおよびRSIdでシグナルする。
<SupplementalProperty schemeIdUri="ObjectPartsGoup" >
<OPG id="1"> // 物体Aを構成する部分3Dオブジェクトのメッシュのグループ
<OPGmember ASid="1" RSid="11,12">
<OPGmember ASid="2" RSid="21,22">
<OPGmember ASid="3" RSid="31,32">
<OPGmember ASid="4" RSid="41,42">
</OPG>
<OPG id="2"> // 物体Aを構成する部分3Dオブジェクトのテクスチャのグループ
//略
</SupplementalProperty>
＜１０．付記＞
＜まとめ＞
以上のように説明した各実施の形態の手法は、適宜、他の実施の形態の手法と組み合わせて用いたり、選択的に併用したりすることができる。
以上のような本開示を適用することにより、6DoFコンテンツの配信でビットレートアダプテーションができるようになり、伝送帯域が限られる場合に再生が途切れることを抑制することができる。すなわち、コンテンツ再生のロバスト性を向上させることができる。
また、クライアント装置１０３は、3Dオブジェクト間の相対的な品質を維持したビットレート選択が可能になる。
さらに、視点位置で決められた3Dオブジェクトの組合せでの最低ビットレートより、さらに低いビットレートになる組み合わせの選択が可能になり、より狭い伝送帯域でも途切れない再生が可能になる。
また、クライアント装置１０３は、コンテンツオーサなどの意図通りの順に3DオブジェクトのLevel of detailを下げることができ、コンテンツオーサなどの意図が反映されたシーンを表示することができる。
さらに、帯域が変わる時に、オブジェクト毎のビットレートを上げる(下げる)アルゴリズム選択に有用である。
また、クライアントは、ユーザの注目している3DオブジェクトのLevel of detailを極力維持して、全体のビットレートを下げることができる。注目している3DオブジェクトのLevel of detailを保つことができる。
＜コンピュータ＞
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここでコンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等が含まれる。
図９１は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
図９１に示されるコンピュータ９００において、CPU（Central Processing Unit）９０１、ROM（Read Only Memory）９０２、RAM（Random Access Memory）９０３は、バス９０４を介して相互に接続されている。
バス９０４にはまた、入出力インタフェース９１０も接続されている。入出力インタフェース９１０には、入力部９１１、出力部９１２、記憶部９１３、通信部９１４、およびドライブ９１５が接続されている。
入力部９１１は、例えば、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部９１２は、例えば、ディスプレイ、スピーカ、出力端子などよりなる。記憶部９１３は、例えば、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部９１４は、例えば、ネットワークインタフェースよりなる。ドライブ９１５は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア９２１を駆動する。
以上のように構成されるコンピュータでは、CPU９０１が、例えば、記憶部９１３に記憶されているプログラムを、入出力インタフェース９１０およびバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。RAM９０３にはまた、CPU９０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
コンピュータ（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９２１に記録して適用することができる。その場合、プログラムは、リムーバブルメディア９２１をドライブ９１５に装着することにより、入出力インタフェース９１０を介して、記憶部９１３にインストールすることができる。
また、このプログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することもできる。その場合、プログラムは、通信部９１４で受信し、記憶部９１３にインストールすることができる。
その他、このプログラムは、ROM９０２や記憶部９１３に、あらかじめインストールしておくこともできる。
＜本技術の適用対象＞
本技術は、任意の画像符号化・復号方式に適用することができる。つまり、上述した本技術と矛盾しない限り、変換（逆変換）、量子化（逆量子化）、符号化（復号）、予測等、画像符号化・復号に関する各種処理の仕様は任意であり、上述した例に限定されない。また、上述した本技術と矛盾しない限り、これらの処理の内の一部を省略してもよい。
上述した実施の形態に係る画像処理装置、画像符号化装置、および画像復号装置は、例えば、衛星放送、ケーブルＴＶなどの有線放送、インターネット上での配信、およびセルラー通信による端末への配信などにおける送信機や受信機（例えばテレビジョン受像機や携帯電話機）、または、光ディスク、磁気ディスクおよびフラッシュメモリなどの媒体に画像を記録したり、これら記憶媒体から画像を再生したりする装置（例えばハードディスクレコーダやカメラ）などの、様々な電子機器に応用され得る。
また、本技術は、任意の装置またはシステムを構成する装置に搭載するあらゆる構成、例えば、システムLSI（Large Scale Integration）等としてのプロセッサ（例えばビデオプロセッサ）、複数のプロセッサ等を用いるモジュール（例えばビデオモジュール）、複数のモジュール等を用いるユニット（例えばビデオユニット）、ユニットにさらにその他の機能を付加したセット（例えばビデオセット）等（すなわち、装置の一部の構成）として実施することもできる。
さらに、本技術は、複数の装置により構成されるネットワークシステムにも適用することもできる。例えば、コンピュータ、AV（Audio Visual）機器、携帯型情報処理端末、IoT（Internet of Things）デバイス等の任意の端末に対して、画像（動画像）に関するサービスを提供するクラウドサービスに適用することもできる。
なお、本技術を適用したシステム、装置、処理部等は、例えば、交通、医療、防犯、農業、畜産業、鉱業、美容、工場、家電、気象、自然監視等、任意の分野に利用することができる。また、その用途も任意である。
例えば、本技術は、観賞用コンテンツ等の提供の用に供されるシステムやデバイスに適用することができる。また、例えば、本技術は、交通状況の監理や自動運転制御等、交通の用に供されるシステムやデバイスにも適用することができる。さらに、例えば、本技術は、セキュリティの用に供されるシステムやデバイスにも適用することができる。また、例えば、本技術は、機械等の自動制御の用に供されるシステムやデバイスに適用することができる。さらに、例えば、本技術は、農業や畜産業の用に供されるシステムやデバイスにも適用することができる。また、本技術は、例えば火山、森林、海洋等の自然の状態や野生生物等を監視するシステムやデバイスにも適用することができる。さらに、例えば、本技術は、スポーツの用に供されるシステムやデバイスにも適用することができる。
＜その他＞
なお、本明細書において「フラグ」とは、複数の状態を識別するための情報であり、真(1)または偽(0)の２状態を識別する際に用いる情報だけでなく、３以上の状態を識別することが可能な情報も含まれる。したがって、この「フラグ」が取り得る値は、例えば1/0の２値であってもよいし、３値以上であってもよい。すなわち、この「フラグ」を構成するbit数は任意であり、1bitでも複数bitでもよい。また、識別情報（フラグも含む）は、その識別情報をビットストリームに含める形だけでなく、ある基準となる情報に対する識別情報の差分情報をビットストリームに含める形も想定されるため、本明細書においては、「フラグ」や「識別情報」は、その情報だけではなく、基準となる情報に対する差分情報も包含する。
また、符号化データ（ビットストリーム）に関する各種情報（メタデータ等）は、符号化データに関連づけられていれば、どのような形態で伝送または記録されるようにしてもよい。ここで、「関連付ける」という用語は、例えば、一方のデータを処理する際に他方のデータを利用し得る（リンクさせ得る）ようにすることを意味する。つまり、互いに関連付けられたデータは、１つのデータとしてまとめられてもよいし、それぞれ個別のデータとしてもよい。例えば、符号化データ（画像）に関連付けられた情報は、その符号化データ（画像）とは別の伝送路上で伝送されるようにしてもよい。また、例えば、符号化データ（画像）に関連付けられた情報は、その符号化データ（画像）とは別の記録媒体（または同一の記録媒体の別の記録エリア）に記録されるようにしてもよい。なお、この「関連付け」は、データ全体でなく、データの一部であってもよい。例えば、画像とその画像に対応する情報とが、複数フレーム、１フレーム、またはフレーム内の一部分などの任意の単位で互いに関連付けられるようにしてもよい。
なお、本明細書において、「合成する」、「多重化する」、「付加する」、「一体化する」、「含める」、「格納する」、「入れ込む」、「差し込む」、「挿入する」等の用語は、例えば符号化データとメタデータとを１つのデータにまとめるといった、複数の物を１つにまとめることを意味し、上述の「関連付ける」の１つの方法を意味する。
また、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
なお、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、および、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
なお、本技術は以下のような構成も取ることができる。
（１） ３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する生成部
を備える情報処理装置。
（２） 前記生成部は、前記情報として、前記コンテンツの再生を制御する制御ファイルのアクセス情報を含む前記メタデータを生成する
（１）に記載の情報処理装置。
（３） 前記制御ファイルは、MPD（Media Presentation Description）であり、
前記生成部は、前記MPDの、前記３次元オブジェクトのLevel of Detailに対応し、前記Level of Detailの複数のビットレートバリエーションに関する情報を含むAdaptationSetへのアクセス情報を含む前記メタデータを生成する
（２）に記載の情報処理装置。
（４） 前記制御ファイルは、MPD（Media Presentation Description）であり、
前記生成部は、前記MPDの、前記３次元オブジェクトに対応するAdaptationSetの、前記３次元オブジェクトのLevel of Detailに対応し、前記Level of Detailの複数のビットレートバリエーションに関する情報を含むrepresentationへのアクセス情報を含む前記メタデータを生成する
（２）または（３）に記載の情報処理装置。
（５） 前記生成部は、所望の前記MPDのアクセス情報、前記MPD内の所望のAdaptationSetを指定する情報、および前記AdaptationSet内の所望のRepresentationを指定する情報からなる前記アクセス情報を含む前記メタデータを生成する
（４）に記載の情報処理装置。
（６） 前記生成部は、さらに、互いに同一のビットレートバリエーションをグループ化する情報を含む前記MPDを生成する
（４）または（５）に記載の情報処理装置。
（７） 前記生成部は、さらに、前記メタデータへのアクセス情報を含まない前記MPDを生成する
（２）乃至（６）のいずれかに記載の情報処理装置。
（８） 前記メタデータは、前記コンテンツの、視点位置に基づく空間表示制御情報であり、
前記生成部は、前記コンテンツの配信の際にビットレートを選択可能にする情報をノードとして有する前記視点位置に基づく空間表示制御情報を生成する
（１）乃至（７）のいずれかに記載の情報処理装置。
（９） 前記生成部は、前記３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現する専用のノードを含む前記視点位置に基づく空間表示制御情報を生成する
（８）に記載の情報処理装置。
（１０） 前記生成部は、前記３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現するフィールドが追加されたノードを含む前記視点位置に基づく空間表示制御情報を生成する
（８）または（９）に記載の情報処理装置。
（１１） 前記生成部は、全ての３次元オブジェクトのビットレートを一律に制御することで品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
（１）乃至（１０）のいずれかに記載の情報処理装置。
（１２） 前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報をさらに含む前記メタデータを生成する
（１）乃至（１１）のいずれかに記載の情報処理装置。
（１３） 前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、前記３次元オブジェクトの各ビットレートバリエーションの品質を順位で示すQualityRankingを含む前記メタデータを生成する
（１２）に記載の情報処理装置。
（１４） 前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、前記３次元オブジェクトの各ビットレートバリエーションの品質を値で示すQuality値を含む前記メタデータを生成する
（１２）または（１３）に記載の情報処理装置。
（１５） 前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、同時再生可能な前記３次元オブジェクトの各ビットレートバリエーションを示す情報を含む前記メタデータを生成する
（１２）乃至（１４）のいずれかに記載の情報処理装置。
（１６） 前記生成部は、前記３次元オブジェクトのLevel of Detailを変更しても、前記３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
（１）乃至（１５）のいずれかに記載の情報処理装置。
（１７） 前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報に基づいて前記３次元オブジェクトのLevel of Detailを変更しても、前記３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
（１）乃至（１６）のいずれかに記載の情報処理装置。
（１８） 前記生成部は、前記３次元オブジェクトの重要度を示す情報をさらに含む前記メタデータを生成する
（１）乃至（１７）のいずれかに記載の情報処理装置。
（１９） 前記生成部は、注目する３次元オブジェクトの重要度を指定する情報をさらに含む前記メタデータを生成する
（１）乃至（１８）のいずれかに記載の情報処理装置。
（２０） ３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する
情報処理方法。
１００ 配信システム， １０１ ファイル生成装置， １０２ 配信サーバ， １０３ クライアント装置， １５１ 制御部， １５２ ファイル生成部， １６１ データ入力部， １６２ Scene Description生成部， １６３ メディアデータ生成部， １６４ MPDファイル生成部， １６５ セグメントファイル生成部， １６６ 記録部， １６７ アップロード部， １７１ 制御部， １７２ 再生処理部, １８１ MPDファイル取得部， １８２ MPDファイル処理部， １８３ Secene Descriptionセグメントファイル取得部， １８４ Scene Descriptionセグメントファイル処理部， １８５ 表示制御部， １８６ 計測部， １８７ メディアデータセグメントファイル選択部， １８８ メディアデータセグメントファイル取得部， １８９ 復号処理部、 １９０ 表示情報生成部， １９１ 表示部

Claims (20)

  1. ３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する生成部
    を備える情報処理装置。
  2. 前記生成部は、前記情報として、前記コンテンツの再生を制御する制御ファイルのアクセス情報を含む前記メタデータを生成する
    請求項１に記載の情報処理装置。
  3. 前記制御ファイルは、MPD（Media Presentation Description）であり、
    前記生成部は、前記MPDの、前記３次元オブジェクトのLevel of Detailに対応し、前記Level of Detailの複数のビットレートバリエーションに関する情報を含むAdaptationSetへのアクセス情報を含む前記メタデータを生成する
    請求項２に記載の情報処理装置。
  4. 前記制御ファイルは、MPD（Media Presentation Description）であり、
    前記生成部は、前記MPDの、前記３次元オブジェクトに対応するAdaptationSetの、前記３次元オブジェクトのLevel of Detailに対応し、前記Level of Detailの複数のビットレートバリエーションに関する情報を含むrepresentationへのアクセス情報を含む前記メタデータを生成する
    請求項２に記載の情報処理装置。
  5. 前記生成部は、所望の前記MPDのアクセス情報、前記MPD内の所望のAdaptationSetを指定する情報、および前記AdaptationSet内の所望のRepresentationを指定する情報からなる前記アクセス情報を含む前記メタデータを生成する
    請求項４に記載の情報処理装置。
  6. 前記生成部は、さらに、互いに同一のビットレートバリエーションをグループ化する情報を含む前記MPDを生成する
    請求項４に記載の情報処理装置。
  7. 前記生成部は、さらに、前記メタデータへのアクセス情報を含まない前記MPDを生成する
    請求項２に記載の情報処理装置。
  8. 前記メタデータは、前記コンテンツの、視点位置に基づく空間表示制御情報であり、
    前記生成部は、前記コンテンツの配信の際にビットレートを選択可能にする情報をノードとして有する前記視点位置に基づく空間表示制御情報を生成する
    請求項１に記載の情報処理装置。
  9. 前記生成部は、前記３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現する専用のノードを含む前記視点位置に基づく空間表示制御情報を生成する
    請求項８に記載の情報処理装置。
  10. 前記生成部は、前記３次元オブジェクトの複数のビットレートバリエーションを複数の子ノードとして表現するフィールドが追加されたノードを含む前記視点位置に基づく空間表示制御情報を生成する
    請求項８に記載の情報処理装置。
  11. 前記生成部は、全ての３次元オブジェクトのビットレートを一律に制御することで品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
    請求項１に記載の情報処理装置。
  12. 前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報をさらに含む前記メタデータを生成する
    請求項１に記載の情報処理装置。
  13. 前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、前記３次元オブジェクトの各ビットレートバリエーションの品質を順位で示すQualityRankingを含む前記メタデータを生成する
    請求項１２に記載の情報処理装置。
  14. 前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、前記３次元オブジェクトの各ビットレートバリエーションの品質を値で示すQuality値を含む前記メタデータを生成する
    請求項１２に記載の情報処理装置。
  15. 前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報として、同時再生可能な前記３次元オブジェクトの各ビットレートバリエーションを示す情報を含む前記メタデータを生成する
    請求項１２に記載の情報処理装置。
  16. 前記生成部は、前記３次元オブジェクトのLevel of Detailを変更しても、前記３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
    請求項１に記載の情報処理装置。
  17. 前記生成部は、前記３次元オブジェクトの間の相対的な品質を示す情報に基づいて前記３次元オブジェクトのLevel of Detailを変更しても、前記３次元オブジェクト間の相対的な品質の維持が可能であることを示す情報をさらに含む前記メタデータを生成する
    請求項１に記載の情報処理装置。
  18. 前記生成部は、前記３次元オブジェクトの重要度を示す情報をさらに含む前記メタデータを生成する
    請求項１に記載の情報処理装置。
  19. 前記生成部は、注目する３次元オブジェクトの重要度を指定する情報をさらに含む前記メタデータを生成する
    請求項１に記載の情報処理装置。
  20. ３次元空間の３次元オブジェクトを表現し、再生の際に視線方向および視点位置を自由に設定可能なコンテンツのメタデータであって、前記コンテンツの配信の際にビットレートを選択可能にする情報を含む前記メタデータを生成する
    情報処理方法。
JP2020559890A 2018-12-03 2019-11-20 情報処理装置および方法 Active JP7484723B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2018226649 2018-12-03
JP2018226649 2018-12-03
PCT/JP2019/045347 WO2020116154A1 (ja) 2018-12-03 2019-11-20 情報処理装置および方法

Publications (2)

Publication Number Publication Date
JPWO2020116154A1 true JPWO2020116154A1 (ja) 2021-10-14
JP7484723B2 JP7484723B2 (ja) 2024-05-16

Family

ID=70975441

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020559890A Active JP7484723B2 (ja) 2018-12-03 2019-11-20 情報処理装置および方法

Country Status (5)

Country Link
US (1) US20220053224A1 (ja)
EP (2) EP4102852A1 (ja)
JP (1) JP7484723B2 (ja)
CN (1) CN113170235A (ja)
WO (1) WO2020116154A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11800184B2 (en) 2021-01-06 2023-10-24 Tencent America LLC Method and apparatus for media scene description

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113424549B (zh) * 2019-01-24 2024-05-28 交互数字Vc控股公司 用于利用多个细节级别和自由度的自适应空间内容流传输的系统和方法
US20210392386A1 (en) * 2020-06-12 2021-12-16 Tencent America LLC Data model for representation and streaming of heterogeneous immersive media
KR20220012740A (ko) * 2020-07-23 2022-02-04 삼성전자주식회사 통신 시스템에서 컨텐츠의 송수신을 제어하기 위한 방법 및 장치
JPWO2022070903A1 (ja) * 2020-09-29 2022-04-07
US11833423B2 (en) * 2020-09-29 2023-12-05 Activision Publishing, Inc. Methods and systems for generating level of detail visual assets in a video game
US11748955B2 (en) * 2020-10-06 2023-09-05 Nokia Technologies Oy Network-based spatial computing for extended reality (XR) applications
JPWO2022149189A1 (ja) * 2021-01-05 2022-07-14
US20240144602A1 (en) * 2021-04-30 2024-05-02 Nippon Telegraph And Telephone Corporation Distribution control system, distribution control apparatus, distribution control method, and program
US20230115603A1 (en) 2021-10-12 2023-04-13 Square Enix Ltd. Scene entity processing using flattened list of sub-items in computer game
WO2023153473A1 (ja) * 2022-02-10 2023-08-17 日本放送協会 メディア処理装置、送信装置及び受信装置
WO2023153472A1 (ja) * 2022-02-10 2023-08-17 日本放送協会 メディア処理装置、送信装置及び受信装置

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050132385A1 (en) 2003-10-06 2005-06-16 Mikael Bourges-Sevenier System and method for creating and executing rich applications on multimedia terminals
JP4760111B2 (ja) * 2005-04-26 2011-08-31 株式会社セガ 映像オブジェクト表現用データ構造生成プログラム、映像オブジェクト表現用データ構造生成方法、映像ソフト開発装置、映像処理プログラム、映像処理方法、映像処理装置、映像オブジェクト表現用データ構造、および、記録媒体
US11277598B2 (en) * 2009-07-14 2022-03-15 Cable Television Laboratories, Inc. Systems and methods for network-based media processing
EP2621188B1 (en) * 2012-01-25 2016-06-22 Alcatel Lucent VoIP client control via in-band video signalling
GB2524531B (en) * 2014-03-25 2018-02-07 Canon Kk Methods, devices, and computer programs for improving streaming of partitioned timed media data
GB2550589B (en) * 2016-05-23 2019-12-04 Canon Kk Method, device, and computer program for improving streaming of virtual reality media content
KR102506480B1 (ko) * 2016-06-14 2023-03-07 삼성전자주식회사 영상 처리 장치 및 그 영상 처리 방법
KR102545195B1 (ko) * 2016-09-12 2023-06-19 삼성전자주식회사 가상 현실 시스템에서 컨텐트 전송 및 재생 방법 및 장치
US20180176468A1 (en) * 2016-12-19 2018-06-21 Qualcomm Incorporated Preferred rendering of signalled regions-of-interest or viewports in virtual reality video
CN110622483B (zh) * 2017-03-23 2022-10-18 Vid拓展公司 改进用于360度自适应流传输的体验的度量和消息

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11800184B2 (en) 2021-01-06 2023-10-24 Tencent America LLC Method and apparatus for media scene description

Also Published As

Publication number Publication date
EP3893514A1 (en) 2021-10-13
EP3893514A4 (en) 2022-02-23
WO2020116154A1 (ja) 2020-06-11
EP4102852A1 (en) 2022-12-14
CN113170235A (zh) 2021-07-23
JP7484723B2 (ja) 2024-05-16
US20220053224A1 (en) 2022-02-17

Similar Documents

Publication Publication Date Title
JP7484723B2 (ja) 情報処理装置および方法
JP7359153B2 (ja) 画像処理装置および方法
JP7384159B2 (ja) 画像処理装置および方法
WO2019142667A1 (ja) 画像処理装置および方法
CN109804635A (zh) 在定时媒体数据流式传输期间改进渲染显示的方法、设备和计算机程序
US10911809B2 (en) Communication apparatus, communication method, and program
DE112020004716T5 (de) Objektbasierte volumetrische videocodierung
EP3422702B1 (en) File generation device, file generation method, reproduction device, and reproduction method
JP7238948B2 (ja) 情報処理装置および情報処理方法
JP7480773B2 (ja) 情報処理装置、情報処理方法、再生処理装置及び再生処理方法
JP6944131B2 (ja) ファイル生成装置およびファイル生成方法、並びに、再生装置および再生方法
WO2021065277A1 (ja) 情報処理装置、再生処理装置及び情報処理方法
JP7501372B2 (ja) 情報処理装置および情報処理方法
EP3509310B1 (en) Delivery device, delivery method, receiver, receiving method, program, and content delivery system
JP6632550B2 (ja) タイムピリオドにまたがってオブジェクトを識別する方法および対応デバイス
WO2022075342A1 (ja) 情報処理装置および方法
WO2020261689A1 (ja) 情報処理装置、情報処理方法、再生処理装置及び再生処理方法
JP7442302B2 (ja) データ処理装置およびその制御方法、プログラム
JP7229696B2 (ja) 情報処理装置、情報処理方法、及びプログラム
JP2022063882A (ja) 情報処理装置および方法、並びに、再生装置および方法
US20240086451A1 (en) Information processing apparatus, reception apparatus, information processing method, and storage medium
WO2022004377A1 (ja) 情報処理装置および方法
CN106165431A (zh) 接收装置、接收方法、传输装置以及传输方法
JP2023544049A (ja) 双方向プレゼンテーションデータストリーム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220929

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231205

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240130

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: 20240402

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240415

R150 Certificate of patent or registration of utility model

Ref document number: 7484723

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150