信息处理装置和信息处理方法与流程

本公开涉及信息处理装置和信息处理方法，且尤其涉及使得能够容易再现多个种类的音频数据中的预定种类的音频数据的信息处理装置和信息处理方法。

背景技术：

近年来，互联网上的流服务的主流已经超过热门视频(OTT-V)。作为基本技术而日益流行的技术是运动图像专家组-基于HTTP的动态自适应流(MPEG-DASH)(例如，参见非专利文献1)。

在MPEG-DASH中，分配服务器针对一条运动图像内容准备具有不同屏幕尺寸和编码速度的运动图像数据组，且再现终端根据发送路径的状况，要求具有最佳屏幕尺寸和最佳编码速度的运动图像数据组，使得实现自适应流分配。

引用列表

非专利文献

非专利文献1：MPEG-DASH(基于HTTP的动态自适应流)(URL:http://mpeg.chiariglione.org/standards/mpeg-dash/media-presentation-description-and-segment-formats/text-isoiec-23009-12012-dam-1)

技术实现要素：

本发明待解决的问题

然而，还未考虑到多组的音频数据中的预定组的音频数据的容易再现(再生，reproduction)。

鉴于上述问题而作出本公开，且本公开支持多组的音频数据中的所期望组的音频数据的容易再现。

问题的解决方案

本公开的第一方面的信息处理装置为包括文件生成单元的信息处理装置，该文件生成单元生成以下文件，其中多个种类的音频数据针对种类中的每一种或多种而被分割到轨道中并被布置，且布置有与所述多个种类相关的信息。

本公开的第一方面的信息处理方法对应于本公开的第一方面的信息处理装置。

在本公开的第一方面中，生成了一种文件，在该文件中多个种类的音频数据针对所述种类的每一种或多种而被分割到轨道中并被布置，且布置有与多个种类相关的信息。

本公开的第二方面的信息处理装置为包括再现单元的信息处理装置，该再现单元从文件中再现预定轨道的音频数据，在该文件中多个种类的音频数据针对所述种类的每一种或多种而被分割到轨道中并被布置，且与多个种类相关的信息被布置。

本公开的第二方面的信息处理方法对应于本公开的第二方面的信息处理装置。

在本公开的第二方面中，预定轨道的音频数据从文件中再现，在该文件中多个种类的音频数据针对所述种类的每一种或多种而被分割到轨道中并被布置且与多个种类相关的信息被布置。

需注意，可以通过使计算机执行程序来实现第一方面的信息处理装置和第二方面的信息处理装置。

另外，为了实现第一方面和第二方面的信息处理装置，可以通过传输介质传输由计算机执行的程序或可将其记录在记录介质上提供由计算机执行的程序。

本发明的效果

根据本公开的第一方面，可以生成文件。另外，根据本公开的第一方面，可以生成使得可容易再现多个种类的频数据中的预定种类的音频数据的文件。

根据本公开的第二方面，可以再现音频数据。另外，根据本公开的第二方面，可以容易地再现多个种类的音频数据中的预定种类的音频数据。

附图说明

图1为示出MPD文件的结构的示图。

图2为示出“Period(时期)”、“Representation(表示)”和“Segment(片段)”之间的关系的示图。

图3为示出MPD文件的层级结构的示图。

图4为示出MPD文件的结构与时间轴之间的关系的示图。

图5为用于说明MP4的3D音频文件格式的轨道(track)的概要的示图。

图6为示出moov box(moov盒子)的结构的示图。

图7为示出3D音频的层级结构的示图。

图8为用于说明本公开应用于的第一实施例中的信息处理系统的概要的示图。

图9为用于说明本公开应用于的第一实施例中的轨道的第一示例的概要的示图。

图10为示出基本轨道的样本条目的语法的示例的示图。

图11为示出形成switch Group的组的轨道的样本条目的语法的示例的示图。

图12为示出片段结构的第一示例的示图。

图13为示出片段结构的第二示例的示图。

图14为示出level assignment(级别分配)盒子的描述示例的示图。

图15为示出本公开应用于的在第一实施例中的MPD文件的第一描述示例的示图。

图16为示出图8的文件生成设备的配置示例的框图。

图17为流程图，其用于描述图16的文件生成设备的文件生成处理。

图18为框图，其示出利用图8的运动图像再现终端实现的流再现单元的配置示例。

图19为流程图，其用于描述图18的流再现单元的再现处理。

图20为用于描述本公开应用于的第一实施例中的轨道的第二示例的概要的示图。

图21为示出switch Group的组的轨道的示例组条目的语法的示例的示图。

图22为示出各个组的轨道的样本条目(sample entry，样本条目)的语法的示例的示图。

图23为用于说明音频文件的轨道的第三示例的概要的示图。

图24为示出MPD文件的第二描述示例的示图。

图25为示出MPD文件的第二描述示例的另一个示例的示图。

图26为用于描述音频文件的轨道的第四示例的概要的示图。

图27为示出MPD文件的第三描述示例的示图。

图28为用于描述音频文件的轨道的第五示例的概要的示图。

图29为示出其中4cc为“mha3”的样本条目的语法的示例的示图。

图30为示出其中4cc为“mha3”的样本条目的语法的另一个示例的示图。

图31为示出MPD文件的第四描述示例的示图。

图32为用于描述音频文件的轨道的第三示例的另一个示例的概要的示图。

图33为用于描述音频文件的轨道的第四示例的另一个示例的概要的示图。

图34为用于描述音频文件的轨道的第五示例的另一个示例的概要的示图。

图35为用于描述音频文件的轨道的第六示例的概要的示图。

图36为示出图35的基本轨道和组轨道的样本条目的语法的示例的示图。

图37为示出其中4cc为“mha3”的样本条目的语法的又一个示例的示图。

图38为用于说明本公开应用至的第二实施例中的轨道的概要的示图。

图39为描述本公开应用至的第二实施例中的MPD文件的第一描述示例的示图。

图40为用于描述本公开应用至的第三实施例中的信息处理系统的概要的示图。

图41为示出图40的文件生成设备的配置示例的框图。

图42为流程图，其用于描述图41的文件生成设备的文件生成处理。

图43为框图，其示出由图40的运动图像再现终端实现的流再现单元的配置示例。

图44为流程图，其用于描述图43的流再现单元的再现处理的示例。

图45为描述本公开应用至的第二实施例中的MPD文件的第二描述示例的示图。

图46为描述本公开应用至的第二实施例中的MPD文件的第三描述示例的示图。

图47为描述本公开应用至的第二实施例中的MPD文件的第四描述示例的示图。

图48为描述本公开应用至的第二实施例中的MPD文件的第五描述示例的示图。

图49为描述本公开应用至的第二实施例中的MPD文件的第六描述示例的示图。

图50为描述本公开应用至的第二实施例中的MPD文件的第七描述示例的示图。

图51为示出包括多个基本轨道的音频文件的轨道结构的示例的示图。

图52为示出包括多个基本轨道的音频文件的轨道结构的另一个示例的示图。

图53为示出计算机的硬件的配置示例的框图。

具体实施方式

在下文中，将描述本公开的预设和用于实施本公开的实施例(以下称为实施例)。需注意，描述将按以下顺序给出。

0.本公开的预设(图1至图7)

1.第一实施例(图8至图37)

2.第二实施例(图38至图50)

3.基本轨道的其他示例(图51和图52)

4.第三实施例(图53)

<本公开的预设>

(MPD文件的结构的说明)

图1是示出MPEG-DASH的媒体表示描述(MPD)文件的结构的示图。

在MPD文件的分析(解析)中，从在MPD文件的“Period”中包括的“Representation”属性(图1的媒体表示)中选出最佳的一个。

然后，通过参考在所选中的“Representation”的排头的“Initialization Segment(初始化片段)”的统一资源定位符(URL)等来获取并处理文件。接着，通过参考后续的“媒体片段”的URL等来获取和再现文件。

需注意，在图2示出了MPD文件中的“Period”、“Representation”和“片段”之间的关系。也就是说，一条运动图像内容可以通过“Period”以比片段更长的时间单位管理，并且可以在各个“Period”中通过“Segment”以片段为单位来管理。另外，在各个“Period”中，可以通过“Representation”以流的属性为单位来管理运动图像内容。

因此，MPD文件具有在“Period”中和以下的图3所示的层级结构。另外，在图4的示例中示出MPD文件的结构关于时间轴的布置。从图4可以清楚地看出，关于相同片段存在多个“Representation”。通过自适应地选择这些“Representation”中的任一个，可以获取和再现用户的所期望的属性的流。

(3D音频文件格式的概要)

图5为用于说明MP4的3D音频文件格式的轨道的概要的示图。

在MP4文件中，可以针对各轨道来管理运动图像内容的编解码信息和表示在文件中的位置的位置信息。在MP4的3D音频文件格式中，3D音频(Channel audio/Object audio/SAOC Object audio/HOA audio/metadata)的所有音频流(elementary stream(基本流，ES)以样本(帧)为单位被记录为一个轨道。另外，3D音频的编解码信息(Pro file/level/audio configuration)被存储为样本条目。

构成3D音频的Channel audio(声道音频)为以声道为单位的音频数据，而Object audio(对象音频)为以对象为单位的音频数据。需注意，对象为声源，且利用附接到对象的麦克风等来获取以对象为单位的音频数据。对象可为物体(诸如固定式麦克风架)或运动体(诸如人)。

另外，SAOC Object audio(SAOC对象音频)为空间音频对象编码(SAOC)的音频数据，而HOA audio(HOA音频)为高阶环境立体混合声(HOA)的音频数据，而metadata(元数据)为Channel audio、Object audio、SAOC Object audio和HOA audio的元数据。

(moov盒子的结构)

图6为示出MP4文件的moov盒子结构的示图。

如图6所示，在MP4文件中，图像数据和音频数据记录为不同轨道。在图6中，虽然未描述细节，但音频数据的轨道相似于图像数据的轨道。样本条目被包括在moov盒子中的stsd盒子中排列的sample description(样本描述)中。

通过该方式，在MP4文件的广播或本地存储再现中，一般地，服务器侧发送所有3D音频的音频流。然后，客户端侧在解析所有的3D音频的音频流时，仅解码和输出必要的3D音频的音频流。然而，在比特率高或存在对本地存储器的读取速率限制的情况下，期望的是，通过仅获取必要的3D音频的音频流来减少解码处理的负荷。

另外，在符合MPEG-DASH的MP4文件的流再现中，服务器侧准备多个编码速度的音频流。因此，客户端侧通过仅获取必要的3D音频的音频流，可以选择和获取对再现环境具有最佳的编码速度的音频流。

如上所述，在本公开中，通过在音频文件中根据种类将3D音频的音频流分割成轨道并且布置音频流，可以有效地仅获取3D音频的预定种类的音频流。因此，在广播或本地存储器再现中，可以减少解码处理的负荷。另外，在流再现中，可以根据频带再现必要的3D音频的音频流中的具有最高质量的音频流。

(3D音频层级结构的描述)

图7为示出3D音频层级结构的示图。

如图7所示，3D音频的音频数据为在各个音频数据中不同的音频元素(Element)。音频元素的类型包括单声道元素(SCE)和声道对元素(CPE)。一个声道的音频数据的音频元素的类型为SCE，而对应于两个声道的音频数据的音频元素的类型为CPE。

同一音频的种类(Channel/Object/SAOC Object/HOA)的音频元素形成组。因此，组类型(GroupType)的实例包括Channels、Objects、SAOC Objects和HOA。两个以上的组可以根据需要形成switch Group(开关组)或group Preset(组预置)。

switch Group为其中包括的组的音频流被排他地再现的组(排他再现组)。即，如图7所示，在存在用于英语(EN)的Object audio的组和用于法语(FR)的Object audio的组的情况下，应当仅再现这些组中的一个。因此，switch Group由用于英语的Object audio的组(组ID为2)和用于法语的Object audio的组(组ID为3)形成。因此，用于英语的Object audio或者用于法语的Object audio被排他地再现。

同时，group Preset定义由内容创作者意欲的组的组合。

另外，3D音频的元数据为各个元数据中不同的Ext元素(Ext Element)。Ext元素的类型包括Object Metadata(对象元数据)、SAOC 3D Metadata(SAOC 3D元数据)、HOA Metadata(HOA元数据)、DRC Metadata(DRC元数据)、SpatialFrame(空间帧)、SaocFrame(Saoc帧)等。Object Metadata的Ext元素是所有Object audio的元数据，以及SAOC 3D Metadata的Ext元素是所有SAOC audio的元数据。另外，HOAMetadata的Ext元素为所有HOAaudio的元数据，且DRC(动态范围控制)Metadata的Ext元素为所有Object audio、SAOC audio和HOAaudio的元数据。

如上所述，3D音频的音频数据的分割单位包括音频元素、组类型、组、switch Group和group Preset。因此，3D音频中的音频数据的音频流可以按各种类被分割到不同轨道，其中种类是音频元素、组类型、组、switch Group或group Preset。

此外，3D音频中的元数据的分割单位包括Ext元素的类型和对应于元数据的音频元素。因此，3D音频的元数据的音频流可以按各种类被分割到不同轨道，其中种类为Ext元素或对应于元数据的音频元素。

在下面的实施例中，音频数据的音频流以一个或多个组被分割到轨道，并且元数据的音频流按Ext元素的各个类型被分割到轨道。

<第一实施例>

(信息处理系统的概要)

图8为用于描述本公开应用至的第一实施例中的信息处理系统的概要的示图。

图8的信息处理系统140被配置成使得与文件生成设备141连接的网络服务器142与运动图像再现终端144通过互联网13连接。

在信息处理系统140中，网络服务器142通过符合MPEG-DASH的方法将待再现的成组的轨道的音频流分配到运动图像再现终端144。

具体地，文件生成设备141以多种编码速度对运动图像内容的3D音频的音频数据和元数据进行编码以生成音频流。文件生成设备141以各编码速度并且以称为片段的从几秒到十秒的各时间单位对所有音频流制作文件以生成音频文件。此时，文件生成设备141针对各个组和Ext元素的各个类型来分割音频流，并且将音频流在音频文件中排列为不同轨道中的音频流。文件生成设备141将生成的音频文件上传(上载)到网络服务器142。

此外，文件生成设备141生成管理音频文件等的MPD文件(管理文件)。文件生成设备141将MPD文件上传到网络服务器142上。

网络服务器142存储由文件生成设备141上传的各个编码速度和片段的音频文件，以及MPD文件。响应于来自运动图像再现终端144的请求，网络服务器142将存储的音频文件、MPD文件等发送到运动图像再现终端144。

运动图像再现终端144运行流数据的控制软件(以下称为控制软件)161、运动图像再现软件162、用于超文本传输协议(HTTP)访问的客户端软件(以下称为访问软件)163等。

控制软件161是控制从网络服务器142串流传输的数据的软件。具体地，控制软件161使运动图像再现终端144从网络服务器142获取MPD文件。

另外，基于MPD文件，控制软件161命令访问软件163发送由运动图像再现软件162指定的待再现的组的传输请求以及对应于该组的Ext元素的类型的轨道的音频流。

运动图像再现软件162是再现从网络服务器142获取的音频流的软件。具体地说，运动图像再现软件162将待再现的组和对应于该组的Ext元素的类型指定给控制软件161。另外，当从访问软件163接收到接收开始的通知时，运动图像再现软件162解码从运动图像再现终端144接收的音频流。运动图像再现软件162根据需要合成并输出作为解码结果获得的音频数据。

访问软件163是使用HTTP控制通过互联网13在运动图像再现终端144和网络服务器142之间的通信的软件。具体地，访问软件163响应于控制软件161的命令，使运动图像再现终端144发送对包括在音频文件中的待再现的轨道的音频流的传输请求。此外，访问软件163响应于传输请求而使运动图像再现终端144开始接收从网络服务器142发送的音频流，并且向运动图像再现软件162供应接收开始的通知。

需注意，在本说明书中，将仅描述运动图像内容的音频文件。然而，实际上，对应的图像文件与音频文件一起生成和再现。

(音频文件的轨道的第一示例的概要)

图9为用于描述音频文件的轨道的第一示例的概要的示图。

注意需，在图9中，为了便于描述，仅示出3D音频中的音频数据的轨道。这同样适用于图20、图23、图26、图28、图30、图32至图35及图38。

如图9所示，所有3D音频的音频流存储在一个音频文件(3dauio.mp4)中。在音频文件(3dauio.mp4)中，3D音频的各组的音频流分别被分割成不同轨道并被排列。另外，与整个3D音频相关的信息被设置为基本轨道(Base Track)。

Track Reference(轨道参考)布置在各个轨道中的轨道盒子中。Track Reference指示在相应轨道与其他轨道之间的参考关系。具体地，Track Reference指示参考关系中对于轨道唯一的其他轨道的ID(以下称为轨道ID)。

在图9的示例中，基本轨道的轨道ID、组ID为1的ID的组#1中的轨道、组ID为2的组#2中的轨道、组ID为3的组#3中的轨道、组ID为4的组#4中的轨道为1、2、3、4、5。另外，基本轨道的Track Reference为2、3、4和5，而组#1至组#4中的轨道的TrackReference为1，即基本轨道的轨道ID。因此，基本轨道和组#1至组#4中的轨道处于参考关系。即，在组#1至组#4中的轨道的再现时，参考基本轨道。

另外，基本轨道的样本条目的4cc(字符码)是“mha2”，并且在基本轨道的样本条目中，布置有包括3D音频的所有组的配置信息或对于仅解码基本轨道而言是必要的配置信息的mhaC盒子以及包括与3D音频的所有组和switch Group相关的信息的mhas盒子。与组相关的信息由组的ID、表示分类成组的元素的数据的内容的信息等来配置。与switch Group相关的信息由switch Group的ID、形成switch Group的各组的ID等配置。

各个组的轨道的样本条目的4cc是“mhg1”，并且在各个组的轨道的样本条目中，可以布置有包括与该组相关的信息的mhgC盒子。在组形成switch Group的情况下，包括与switch Group相关的信息的mhsC盒子布置在组中的轨道的样本条目中。

在基本轨道的样本中，布置有组中的轨道的样本的参考信息或者用于解码参考信息所必需的配置信息。通过按照参考信息的布置顺序来排列由参考信息所参考的组的样本，可以生成在分割成轨道之前的3D音频的音频流。参考信息由组中轨道的样品的位置和大小、组类型等配置。

(基本轨道的样本条目的语法的示例)。

图10为示出基本轨道的样本条目的语法的示例的示图。

如图10所示，在基本轨道的样本条目中，布置有mhaC盒子(MHAC配置盒子)、mhas盒子(MHA音频场景信息(AudioSceneInfo)盒子)等。在mhaC盒子中，描述了3D音频的所有组的配置信息或对仅解码基本轨道所必需的配置信息。另外，在mhas盒子中，描述了音频场景(AudioScene)信息，该信息包括与3D音频的所有组和switch Group相关的信息。音频场景信息描述图7的层级结构。

(各个组的轨道的样本条目的语法的示例)。

图11为示出各个组的轨道的样本条目的语法的示例的示图。

如图11所示，在各个组的轨道样本条目中，布置有mhaC盒子(MHAConfigration Box)、mhgC盒子(MHAGroupDefinition Box)、mhsC盒子(MHASwitchGropuDefinition Box)等。

在mhaC盒子中，描述对解码相应轨道必需的配置信息。此外，在mhgC盒子中，与相应组相关的音频场景信息被描述为组定义(GroupDefinition)。在mhsC盒子中，在相应组形成switch Group的情况下，在switch Group定义(SwitchGroupDefinition)中描述与switch Group相关的音频场景信息。

(音频文件的片段结构的第一示例)

图12为示出音频文件的片段结构的第一示例的示图。

在图12的片段结构中，由ftyp盒子和moov盒子配置初始片段。在moov盒子，trak盒子布置用于包括在音频文件中的每个轨道。另外，在moov盒子，布置有包括指示各个轨道的轨道ID与媒体片段中的ssix盒子中使用的级别之间对应关系的信息的mvex盒子等。

此外，媒体片段由sidx盒子、ssix盒子和一个或多个子片段配置。在sidx盒子中，布置有指示子片段在音频文件中的位置的位置信息。在ssix盒子中，布置有布置在mdat盒子中的各级别的音频流的位置信息。需注意，级别对应于轨道。此外，第一轨道的位置信息为由第一轨道的moof盒子和音频流构成的数据的位置信息。

子片段设置为各任意时间长度，且子片段设置有一对moof盒子和mdat盒子，其共用于所有轨道。在mdat盒子中，所有轨道的音频流通过任意时间长度统一布置，而在moof盒子中，布置音频流的管理信息。布置在mdat盒子中的轨道的音频流在各轨道中是连续的。

在图12的示例中，轨道ID为1的轨道1是基本轨道，轨道ID为2至N的轨道2至轨道N是组ID为1至N-1的组中的轨道。这同样适用于下述图13。

(音频文件的片段结构的第二示例)

图13为示出音频文件的片段结构的第二示例的示图。

图13的片段结构与图12的片段结构不同之处在于moof盒子和mdat盒子针对每个轨道而设。

即，图13的初始片段相似于图12的初始片段。另外，图13的媒体片段通过sidx盒子、ssix盒子和一个或多个子片段构成，相似于图12的媒体片段。在sidx盒子中，子片段的位置信息被布置，相似于图12的sidx盒子。在ssix盒子中，包括由moof盒子和mdat盒子构成的级别的数据的位置信息。

子片段设置成各任意时间长度，且子片段设置有针对每个轨道的一对moof盒子和mdat盒子。即，在各个轨道的mdat盒子中，轨道的音频流通过任意时间长度统一布置(交错存储)，且在moof盒子中，布置音频流的管理信息。

如图12和图13所示，轨道的音频流通过任意时间长度统一布置。因此，相比于音频流以样本为单元统一布置时，通过HTTP等的音频流获取效率得到改进。

(mvex盒子的描述示例)

图14为示出图12和图13的mvex盒子中布置的级别分配盒子的描述示例的示图。

级别分配盒子是将每个轨道的轨道ID与在ssix盒子中使用的级别相关联的盒子。如图14所示，轨道ID为1的基本轨道与级别0相关联，轨道ID为2的声道音频轨道与级别1相关联。此外，轨道ID为3的HOA音频轨道与级别2相关联，轨道ID为4的对象元数据轨道与级别3相关联。此外，轨道ID为5的对象音频轨道与级别4相关联。

(MPD文件的第一描述示例)

图15为示出MPD文件的第一描述示例的示图。

如图15所示，在MPD文件中，描述了管理3D音频的音频文件(3daudio.mp4)的片段的“Representation”、管理包括在片段中的轨道的“SubRepresentation”等。

“Representation”和“SubRepresentation”包括指示在3D文件格式中的作为整体的相应片段或者轨道的编解码的种类(配置文件或级别)的“codecs”。

“SubRepresentation”包括在级别分配盒子中设定的值的“level”，作为指示相应轨道的级别的值。“SubRepresentation”包括“dependencyLevel”，其为指示与具有参考关系(具有依赖性)的其他轨道(以下称为参考轨道)对应的级别的值。

另外，“SubRepresentation”包括<EssentialProperty schemeIdUri＝“urn:mpeg:DASH:3daudio:2014”value＝“dataType,definition”。

“dataType(数据类型)”是指示在对应轨道的样本条目中描述的音频场景信息的内容(definition(定义))的种类的数字，并且该definition是其内容。例如，在GroupDefinition(组定义)包括在轨道的样本条目中的情况下，1描述为轨道的“数据类型”，并且组定义描述为“definition”。另外，在SwitchGroupDefinition包括在轨道的样本条目中的情况下，2描述为轨道的“数据类型”，并且SwitchGroupDefinition描述为“definition”。即，“dataType”和“definition”为指示SwitchGroupDefinition是否存在于相应轨道的样本条目中的信息。“definition”为二进制数据，且由base64方法编码。

需注意，在图15的示例中，所有组形成switch Group。然而，在存在组不形成switch Group的情况下，<EssentialProperty schemeIdUri＝“urn:mpeg:DASH:3daudio:2014”value＝“2,SwitchGroupDefinition”>不被描述在对应于该组的“SubRepresentation”中。这同样适用于下述的图24、图25、图31、图39、图45、图47、图48和图50。

(文件生成设备的配置示例)

图16为示出图8的文件生成设备141的配置示例的框图。

图16的文件生成设备141由音频编码处理单元171、音频文件生成单元172、MPD生成单元173和服务器上传处理单元174配置。

文件生成设备141的音频编码处理单元171以多种编码速度对运动图像内容的3D音频的音频数据和元数据进行编码以生成音频流。音频编码处理单元171将各个编码速度的音频流提供至音频文件生成单元172。

音频文件生成单元172针对每个组和每个类型的Ext元素将轨道分派至从音频编码处理单元171供应的音频流。音频文件生成单元172生成图12或图13的片段结构的音频文件，其中对于各编码速度和片段，以子片段为单位布置轨道的音频流。音频文件生成单元172将生成的音频文件供应至MPD生成单元173。

MPD生成单元173确定其中从音频文件生成单元172供应的音频文件将被存储的网络服务器142的URL等。然后，MPD生成单元173生成其中音频文件的URL等布置在音频文件的“Representation”的“Segment”中的MPD文件。MPD生成单元173将所生成的MPD文件和音频文件供应至服务器上传处理单元174。

服务器上传处理单元174将从MPD生成单元173供应的音频文件和MPD文件上传到网络服务器142上。

(文件生成设备的处理的描述)

图17为流程图，其用于描述图16的文件生成设备141的文件生成处理。

在图17的步骤S191，音频编码处理单元171以多种编码速度对运动图像内容的3D音频的音频数据和元数据进行编码以生成音频流。音频编码处理单元171将各编码速度的音频流提供至音频文件生成单元172。

在步骤S192，音频文件生成单元172针对各个组和Ext元素的各类型将轨道分派给从音频编码处理单元171供应的音频流。

在步骤S193，音频文件生成单元172生成图12或图13的片段结构的音频文件，其中对于每个编码速度和片段，以子片段为单位布置轨道的音频流。音频文件生成单元172将生成的音频文件供应至MPD生成单元173。

在步骤S194，MPD生成单元173生成包括音频文件的URL等的MPD文件。MPD生成单元173将所生成的MPD文件和音频文件供应至服务器上传处理单元174。

在步骤S195，服务器上传处理单元174将从MPD生成单元173供应的音频文件和MPD文件上传到网络服务器142上。然后，终止处理。

(运动图像再现终端的功能性配置示例)

图18是框图，其示出实现使得图8的运动图像再现终端144运行控制软件161、运动图像再现软件162和访问软件163的流再现单元的配置示例。

图18的流再现单元190由MPD获取单元91、MPD处理单元191、音频文件获取单元192、音频解码处理单元194和音频合成处理单元195配置。

流再现单元190的MPD获取单元91从网络服务器142获取MPD文件，且供应MPD文件至MPD处理单元191。

MPD处理单元191从MPD获取单元91供应的MPD文件中提取在用于音频文件的“Segment”中描述的待再现的片段的音频文件的URL信息，并且将该信息供应至音频文件获取单元192。

音频文件获取单元192请求网络服务器142，并且获取在利用从MPD处理单元191供应的URL识别的音频文件中的待再现的轨道的音频流。音频文件获取单元192将获取的音频流供应至音频解码处理单元194。

音频解码处理单元194解码从音频文件获取单元192供应的音频流。音频解码处理单元194将作为解码结果获得的音频数据供应至音频合成处理单元195。音频合成处理单元195根据需要合成从音频解码处理单元194供应的音频数据，且输出该音频数据。

如上所述，音频文件获取单元192、音频解码处理单元194和音频合成处理单元195用作再现单元，并且从存储在网络服务器142中的音频文件中获取并再现待再现的轨道的音频流。

(运动图像再现终端的处理的描述)

图19为流程图，其用于描述图18的流再现单元190的再现处理。

在图19的步骤S211中，流再现单元190的MPD获取单元91从网络服务器142获取MPD文件，且供应MPD文件至MPD处理单元191。

在步骤S212，MPD处理单元191从MPD获取单元91供应的MPD文件中提取在用于音频文件的“Segment”中描述的待再现的片段的音频文件的URL信息，并且将该信息供应至音频文件获取单元192。

在步骤S213，音频文件获取单元192请求网络服务器142并基于从MPD处理单元191供应的URL来获取由URL识别的音频文件中待再现的轨道的音频流。音频文件获取单元192将获取的音频流供应至音频解码处理单元194。

在步骤S214，音频解码处理单元194解码从音频文件获取单元192供应的音频流。音频解码处理单元194将作为解码结果获得的音频数据供应至音频合成处理单元195。在步骤S215，音频合成处理单元195根据需要合成从音频解码处理单元194供应的音频数据，且输出该音频数据。

(音频文件的轨道的第二示例的概要)

需注意，在以上描述中，GroupDefinition和SwitchGroupDefinition布置在样本条目中。然而，如图20所示，GroupDefinition和SwitchGroupDefinition可以布置在样本组条目中，该样品组条目为轨道中的子样本的各个组的样本条目。

在这种情况下，如图21所示，组(其形成switch Group)的轨道的样本组条目包括GroupDefinition和SwitchGroupDefinition。虽然省略图示，但是组(其不形成switch Group)的轨道的样本组条目仅包括GroupDefinition。

另外，各个组的轨道的样本条目变成在图22所示的一个。即，如图22所示，在每个组的轨道的样本条目中，描述了其中相应轨道的音频流的诸如配置文件的配置信息(MPEGHAudioProfile)、级别(MPEGHAudioProfile)等的MHA组音频配置盒子。

(音频文件的轨道的第三示例的概要)

图23为用于描述音频文件的轨道的第三示例的概要的示图。

图23的音频数据的轨道的配置与图9的配置不同之处在于，3D音频的一个或多个组的音频流包括在基本轨道中，并且对应于分割成不包括与作为整体的3D音频相关的信息的轨道(在下文被称为组轨道)的音频流的组的数量为1或更多。

即，图23的基本轨道的样本条目是4cc为“mha2”的样本条目，其包括在3D音频中的音频数据的音频流被分割成多个轨道并被布置时的基本轨道的语法，相似于图9(图10)。

另外，组轨道的样本条目是4cc为“mhg1”的样本条目，其包括针对在3D音频中的音频数据的音频流分割成多个轨道并被布置时的组轨道的语法，相似于图9(图11)。因此，基本轨道和组轨道用样本条目的4cc来识别，并且可以辨识轨道之间的依赖性。

另外，相似于图9，Track Reference布置在轨道中的每个的轨道盒子中。因此，即使在“mha2”和“mhg1”为4cc的基本轨道的样本条目或者组轨道未知的情况下，在轨道之间的依赖性可以利用轨道参考辨识。

需注意，可以不在组轨道的样本条目中描述mhgC盒子和mhsC盒子。另外，在包括3D音频的所有组的配置信息的mhaC盒子在基本轨道的样本条目中描述的情况下，可以不在组轨道的样本条目中描述mhaC盒子。然而，在基本轨道的样本条目中描述包括可以独立地再现基本轨道的配置信息的mhaC盒子的情况下，在组轨道的样本条目中描述包括可以独立地再现组轨道的配置信息的mhaC盒子。可以根据在样本条目中的配置信息的存在/不存在来辨识是处于前一状态还是处于后一状态。然而，可以通过描述在样本条目中的标志或通过改变样本条目的类型来进行辨识。需注意，虽然省略图示，但是在通过改变样本条目的类型来使得前一状态和后一状态可辨识的情况下，4cc的基本轨道的样本条目在前一状态的情况下是“mha2”状态，在后一状态的情况下为“mha4”。

(MPD文件的第二描述示例)

图24为示图，其示出在音频文件的轨道的配置为图23的配置的情况下MPD文件的描述示例。

图24的MPD文件与图15的MPD文件不同之处在于，描述了基本轨道的“SubRepresentation”。

在基本轨道的“SubRepresentation”中，描述了基本轨道的“编解码器”、“层级”、“依赖性层级”和<EssentialProperty schemeIdUri＝"urn:mpeg:DASH:3daudio:2014"value＝"dataType,definition">，相似于组轨道的“SubRepresentation”。

在图24的示例中，基本轨道的“编解码器”是“mha2.2.1”，并且“层级”是指示基本轨道的层级的值“0”。“依赖性层级”是指示组轨道的层级的值“1”和“2”。另外，“数据类型”是指示作为基本轨道的样本条目的mhas盒子中描述的种类的音频场景信息的数字的“3”，并且“定义”由base64方法编码的音频场景的二元数据。

需注意，参考图25，在基本轨道的“SubRepresentation”中，可以划分和描述音频场景信息。

在图25的示例中，“1”被设定成数字，其指示作为种类的“Atmo”，指示具有组ID“1”的组的内容的“Atmo”，在基础音频的样本条目的mhas盒子中描述的音频场景信息(图7)。

另外，“2”至“7”设定为数字，这些数字分别指示，作为种类，指示具有组ID“2”的组的内容的“对话框EN”，指示具有组ID“3”的组的内容的“对话FR”，指示具有组ID“4”的组的内容的“画外音GE”，指示具有组ID“5”的组的内容的“效果”，指示具有组ID“6”的组的内容的“效果”，和指示具有组ID“7”的组的内容的“效果”。

因此，在图25的基本轨道的“SubRepresentation”中，描述了其中“数据类型”为1，而“定义”为Atmo”的<EssentialProperty schemeIdUri＝“urn:mpeg:DASH:3daudio:2014”value＝“dataType,definition”>。相似地，描述了<“urn:mpeg:DASH:3daudio:2014”value＝“dataType,definition”>，其中“数据类型”为“2”、“3”、“4”、“5”、“6”和“7”，而定义为“对话EN”、“对话FR”、“画外音GE”、“效果”、“效果”和“效果”。在图25的示例中，其中基本轨道的音频场景信息被分割和描述的情况已经被描述。然而，组轨道的组定义和switch Group定义可以相似地分割和描述。

(音频文件的轨道的第四示例的概要)

图26为用于描述音频文件的轨道的第四示例的概要的示图。

图26的轨道数据的轨道的配置与图26的配置不同在于，组轨道的样本条目是具有4cc的“mha2”的样本条目。

在图26的情况下，基本轨道和组轨道的样本条目的4ccs均是“mha2”。因此，不可以识别基本轨道和组轨道且在轨道之间的依赖性不可以利用样本条目4cc进行辨识。因此，利用布置在轨道中的每个的轨道盒子中的轨道参考来识别轨道之间的依赖性。

另外，因为样本条目的4ccs为“mha2”，所以在音频数据的音频流被分割和布置在多个轨道中时可以识别作为3D音频的轨道的相应轨道。

需注意，在基本轨道的样本条目的mhaC盒子中，描述3D音频的所有组的配置信息或者独立地再现基本轨道的配置信息，相似于在图9和图23的情况。另外，在mhas盒子中，描述音频场景信息，该信息包括与所有组和3D音频的switch Group相关的信息。

同时在组轨道的样本条目中，未布置mhas盒子。另外，在包括3D音频的所有组的配置信息的mhaC盒子在基本轨道的样本条目中描述的情况下，mhaC盒子可以不在组轨道的样本条目中描述。然而，在基本轨道的样本条目中描述包括可以独立地再现基本轨道的配置信息的mhaC盒子的情况下，在组轨道的样本条目中描述包括可以独立地再现基本轨道的配置信息的mhaC盒子。可以根据在样本条目中的配置信息的存在/不存在来辨识是处于前一状态还是处于后一状态。然而，可以通过描述在样本条目中的标志或通过改变样本条目的类型来识别前一状态和后一状态。需注意，虽然省略图示，但是在通过改变样本条目的类型来使得前一状态和后一状态可辨识的情况下，基本轨道的样本条目的4cc和组轨道的样本条目的4cc例如在前者的情况下是“mha2”以及在后者情况下为“mha4”。

(MPD文件的第三描述示例)

图27为示图，其示出在音频文件的轨道的配置为图26的配置的情况下MPD文件的描述示例。

图27的MPD文件与图24的MPD文件不同之处在于，组轨道的“SubRepresentation”的编解码器为“mha2.2.1”，且<EssentialProperty schemeIdUri＝“urn:mpeg:DASH:3daudio:2014”value＝“dataType,definition”>未在组轨道的“SubRepresentation”中描述。

需注意，虽然省略图示，但是音频场景信息可以在基本轨道的“SubRepresentation”中分割和描述，相似于图25的情况。

(音频文件的轨道的第五示例的概要)

图28为用于描述音频文件的轨道的第五示例的概要的示图。

图28的音频数据的轨道的配置与图23的配置不同之处在于，基本轨道和组轨道的样本条目为这样的样本条目，其包括适用于3D音频的音频数据的音频流被分割成多个轨道的情况下的组轨道和基本轨道这两者的语法。

在图28的情况下，基本轨道和组轨道的样本条目的4ccs均是“mha3”，其为包括适用于基本轨道和组轨道这两者的语法的样本条目的4cc。

因此，相似于图26的情况，利用布置在轨道中的每个的轨道盒子中的轨道参考来识别轨道之间的依赖性。另外，因为样本条目的4ccs为“mha2”，所以在3D音频的音频数据的音频流被分割和布置在多个轨道中时可以识别作为轨道的相应轨道。

(4cc为“mha3”的样本条目的语法的示例)。

图29为示出4cc为“mha3”的样本条目的语法的示例的示图。

如图29所示，4cc为“mha3”的样本条目的语法为通过合成图10的语法和图11的语法获得的语法。

即，在4cc为“mha3”的样本条目中，布置mhaC盒子(MHA配置盒子)、mhas盒子(MHA音频场景信息盒子)、mhgC盒子(MHA组定义盒子)、mhsC盒子(MHAswitch Group定义盒子)等。

在基本轨道的样本条目的mhaC盒子中，描述了3D音频所有组的配置信息或者可以独立地再现基本轨道的配置信息。另外，在mhas盒子中，描述包括与所有组和3D音频switch Group相关的信息，且未布置mhgC盒子和mhsC盒子。

在包括3D音频的所有组的配置信息的mhaC盒子在基本轨道的样本条目中描述的情况下，mhaC盒子可以不在组轨道的样本条目中描述。然而，在基本轨道的样本条目中描述包括可以独立地再现基本轨道的配置信息的mhaC盒子的情况下，在组轨道的样本条目中描述包括可以独立地再现组轨道的配置信息的mhaC盒子。可以根据在样本条目中的配置信息的存在/不存在来辨识是处于前一状态还是处于后一状态。然而，可以通过描述在样本条目中的标志或通过改变样本条目的类型来辨识前一状态和后一状态。需注意，虽然省略图示，但是在通过改变样本条目的类型来使得前一状态和后一状态可辨识的情况下，基本轨道和组轨道的样本条目的4ccs在前一状态的情况下是“mha3”，在后一状态的情况下为“mha5”。另外，未在组轨道的样本条目中布置mhas盒子。可以或可不布置mhgC盒子和mhsC盒子。

需注意，如在图30中所示，在基本轨道的样本条目中，布置mhas盒子、mhgC盒子和mhsC盒子，描述了其中可以独立仅再现基本轨道的配置信息的mhaC盒子，且布置包括3D音频所有组的配置信息的mhaC盒子。在这种情况下，利用包括在这些mhaC中的标志来识别其中描述3D音频的所有组的配置信息的mhaC盒子和其中描述可以独立地仅再现基本轨道的配置信息的mhaC盒子。另外，在这种情况下，mhaC盒子可以不在组轨道的样本条目中描述。mhaC盒子是否在组轨道的样本条目中描述可以根据在组轨道的样本条目中的mhaC盒子存在与否来辨识。然而，可以通过描述在样本条目中的标志或通过改变样本条目的类型来辨识mhaC盒子是否在组轨道的样本条目中描述。需注意，虽然省略图示，但在通过改变样本条目的类型使得可以辨识mhaC盒子是否在组轨道的样本条目中描述的情况下，基本轨道和组轨道的样本条目的4ccs例如在mhaC盒子在组轨道的样本条目中描述的情况为“mha3”，而在mhaC盒子在组轨道的样本条目中未描述的情况下为“mha5”。需注意，在图30，mhgC盒子和mhsC盒子可以不在组轨道的样本条目中描述。

(MPD文件的第四描述示例)

图31为示图，其示出在音频文件的轨道的配置为图28或30的配置的情况下MPD文件的描述示例。

图31的MPD文件与图24的MPD文件不同之处在于，“Representation”的“编解码器”为“mha3.3.1”，而“SubRepresentation”的“编解码器”为“mha3.2.1”。

需注意，虽然省略图示，但音频场景信息可以在基本轨道的“SubRepresentation”中被分割和描述，相似于图25的情况。

另外，在以上描述中，轨道参考布置在轨道中的每个的轨道盒子中。然而，可以不布置轨道参考。例如，图32至34为示图，它们分别示出其中未在图23、图26和图28的音频文件的轨道的轨道盒子中布置轨道参考的情况。在图32的情况下，未布置轨道参考，但在基本轨道和组轨道的样本条目的4ccs不同，且因此可以辨识在轨道之间的依赖性。在图33和图34的情况下，因为布置mhas盒子，所以可以辨识轨道是否为基本轨道。

音频文件的轨道的配置为图32至34的配置的情况的MPD文件分别与图24、图27和图31的MPD文件相同。需注意，在这种情况下，音频场景信息可以在基本轨道的“SubRepresentation”中被分割和描述，相似于图25的情况。

(音频文件的轨道的第六示例的概要)

图35为用于描述音频文件的轨道的第六示例的概要的示图。

图35的音频数据的轨道的配置与图33的结构不同之处在于，在基本轨道的样本中没有布置组的轨道的样本的参考信息和用于解码参考信息所必需的配置信息，包括0组或更多组音频流，在基本轨道的样本条目中描述组的轨道的样本的参考信息。

更具体地，描述追踪在音频场景信息中描述的组被分割的mhmt盒子以新的方式布置在4cc为“mha2”的样本条目中，其当3D音频的音频数据的音频流被分割成多个轨道时包括用于基本轨道的语法。

(4cc为“mha2”的样本条目的语法的另一个示例)。

图36为示出4cc为“mha2”的图35的基本轨道和组轨道的样本条目的语法的示例的示图。

图36的4ccs为“mha2”的样本条目的配置与图10的配置不同之处在于，布置MHA多轨道描述(MHAMultiTrackDescription)盒子(mhmt盒子)。

在mhmt盒子中，作为参考信息，在组ID(组_ID)和轨道ID(轨道_ID)之间的相应信息被描述。需注意，在mhmt盒子中，可以彼此相关联地描述音频元素和轨道ID。

在参考信息在每个样本中未改变的情况下，通过在样本条目中布置mhmt盒子可以有效地描述参考信息。

需注意，虽然省略图示，但在图9、图20、图23、图26、图28、图30、图32和图34的情况下，mhmt盒子可以相似地布置在后轨道的样本条目中，而非描述组的轨道的样本的参考信息，相似于基本轨道的样本。

在这种情况下，4cc为“mha3”的样本条目的语法变成在图37所示的一个。即，图36的4ccs为“mha3”的样本条目的配置与图29的配置不同之处在于，布置MHA多轨道描述(MHAMultiTrackDescription)盒子(mhmt盒子)。

另外，在图23、图26、图28、图30、图32至图34和图35中，3D音频的一个或多个组的音频流可以不包括在基本轨道中，相似于图9。另外，对应于被分割成组轨道的音频流的组的数量可为1。

另外，在图23、图26、图28、图30、图32至图34和图35中，组定义和switch Group定义可以布置在相同组条目中，相似于图20的情况。

<第二实施例>

(轨道的概要)

图38为用于描述本公开应用至的在第二实施例中的轨道的概要的示图。

如图38所示，第二实施例与第一实施例不同之处在于，轨道记录为不同文件(3da_base.mp4/3da_group1.mp4/3da_group2.mp4/3da_group3.mp4/3da_group 4.mp4)。在这种情况下，通过经HTTP获取期望轨道的文件，可以仅获取期望轨道的数据。因此，可以有效地获取通过HTTP的期望轨道的数据。

(MPD文件的描述示例)

图39为描述本公开应用至的在第二实施例中的MPD文件的描述示例的示图。

如图39所示，在MPD文件中，描述了管理3D音频的音频文件(3da_base.mp4/3da_group1.mp4/3da_group2.mp4/3da_group3.mp4/3da_gro up 4.mp4)的片段的“Representation”等。

“Representation”包括“编解码器”、“id”、“关联Id”和“关联类型”。“id”为包括“id”的“Representation”的ID。“关联Id”是指示相应轨道和另一轨道之间的参考关系的信息，并且是参考轨道的“id”。“关联类型”是指示具有参考轨道的参考关系(依赖性)的含义的代码，并且例如使用与MP4的轨道参考的值相同的值。

另外，组的轨道的“Representation”包括<EssentialProperty schemeIdUri＝“urn:mpeg:DASH:3daudio:2014”value＝“dataType,def inition”>。在图39的示例中，管理音频文件的片段的“Representation”在一个“适配集(AdaptationSet)”下提供。然而，可以为音频文件的每个片段提供“适应集”，并且可以在其下提供管理片段的“Representation”。在这种情况下，在“适应集”中，“关联Id”和指示具有参考轨道的参考关系的含义的<EssentialProperty schemeIdUri＝“urn:mpeg:DASH:3daudioAssociationData:2014”value＝“dataType,id”>可以被描述，相似于“关联类型”。另外，在基本轨道和组轨道的“Representation”中描述的音频场景信息、组定义和switch Group定义可以被分割和描述，相似于图25的情况。另外，在“Representation”中描述和分割的音频场景信息、组定义和switch Group定义可以在“适应集”中描述。

(信息处理系统的概要)

图40为用于描述本公开应用至的在第三实施例中的信息处理系统的概要的示图。

在图40所示的配置的相同配置，与图8的配置用相同参考标记标示。适当地省略重叠的描述。

图40的信息处理系统210被配置成使得连接到文件生成设备211的网络服务器212通过互联网13与运动图像再现终端214连接。

在信息处理系统210中，网络服务器142通过符合MPEG-DASH的方法将待再现的组中的音频文件的音频流分配到运动图像再现终端144。

具体地，文件生成设备211以多种编码速度对运动图像内容的3D音频的音频数据和元数据进行编码以生成音频流。文件生成设备211针对每个组和每个类型的Ext元素分割音频流从而使音频流在不同的轨道中。文件生成设备211针对每个片段和每个轨道以每个编码速度制作音频流的文件以生成音频文件。文件生成设备211将作为结果的音频文件上传到网络服务器212上。另外，文件生成设备211生成MPD文件并将其上传到网络服务器212上。

网络服务器212存储用于每个片段及用于每个轨道的处于每个编码速度的音频文件，以及从文件生成设备211上传的MPD文件。响应于来自运动图像再现终端214的请求，网络服务器212将存储的音频文件、存储的MPD文件等发送到运动图像再现终端214。

运动图像再现终端214执行控制软件221、运动图像再现软件162、访问软件223等。

控制软件221是控制从网络服务器212流出的数据的软件。具体地，控制软件221使运动图像再现终端214从网络服务器212获取MPD文件。

另外，基于MPD文件，控制软件221命令访问软件223传送由运动图像再现软件162指定的待再现的组的发送请求以及对应于该组的Ext元素类型的音频文件的音频流。

访问软件223是通过使用HTTP的互联网13控制运动图像再现终端214和网络服务器212之间的通信的软件。具体地，访问软件223响应于控制软件221的命令，使运动图像再现终端144发送待再现的音频文件的音频流的发送请求。此外，访问软件223响应于发送请求而使运动图像再现终端144开始接收从网络服务器212发送的音频流，并且向运动图像再现软件162供应接收开始的通知。

(文件生成设备的配置示例)

图41为示出图40的文件生成设备211的配置示例的框图。

在图41所示的配置的相同配置，与图16的配置用相同参考标记标示。适当地省略重叠的描述。

图41的文件生成设备211的配置与图16的文件生成设备141不同之处在于，音频文件生成单元241和MPD生成单元242被提供来代替音频文件生成单元172和MPD生成单元173。

具体地，音频文件生成设备211的音频文件生成单元241针对每个组和每个类型的Ext元素将轨道分派至从音频编码处理单元171供应的音频流。音频文件生成单元241生成音频文件，在其中音频流以每个编码速度针对每个片段及针对每个轨道被布置。音频文件生成单元241将生成的音频文件供应至MPD生成单元242。

MPD生成单元242确定其中从音频文件生成单元172供应的音频文件待存储于的网络服务器142的URL等。MPD生成单元242生成其中音频文件的URL等布置在用于音频文件的“Representation”的“片段”中的MPD文件。MPD生成单元173将所生成的MPD文件和生成的音频文件供应至服务器上传处理单元174。

(文件生成设备的处理的描述)

图42为流程图，其用于描述图41的文件生成设备211的文件生成处理。

图42的步骤S301和S302的处理相似于图17的步骤S191和步骤S192的处理，因而省略描述。

在步骤S303，音频文件生成单元241生成音频文件，在其中音频流以每个编码速度针对每个片段及针对每个轨道被布置。音频文件生成单元241将生成的音频文件供应至MPD生成单元242。

步骤S304和S305的处理相似于图17的步骤S194和步骤S195的处理，因而省略描述。

(运动图像再现终端的功能性配置示例)

图43是框图，其示出实现使得图40的运动图像再现终端214执行控制软件221、运动图像再现软件162和访问软件223的流再现单元的配置示例。

在图43所示的配置的相同配置，与图18的配置用相同参考标记标示。适当地省略重叠的描述。

图43的流再现单元260的配置和图18的流再现单元190的配置不同之处在于，提供音频文件获取单元264来取代音频文件获取单元192。

音频文件获取单元264请求网络服务器142以获取基于从MPD处理单元191供应的URL的待再现的轨道的音频文件的URL获取音频文件的音频流。音频文件获取单元264将获取的音频流供应至音频解码处理单元194。

即，音频文件获取单元264、音频解码处理单元194和音频合成处理单元195用作再现单元，并且从存储在网络服务器212中的音频文件获取待再现的轨道的音频文件的音频流，并再现该音频流。

(运动图像再现终端的处理的描述)

图44为流程图，其用于描述图43的流再现单元260的再现处理。

图44的步骤S321和S322的处理相似于图19的步骤S221和步骤S212的处理，因而省略描述。

在步骤S323，基于待再现的轨道的音频文件的URL，音频文件获取单元192请求网络服务器142来获取从MPD处理单元191供应的URL的音频文件的音频流。音频文件获取单元264将获取的音频流供应至音频解码处理单元194。

步骤S324和S325的处理相似于图19的步骤S214和步骤S215的处理，因而省略描述。

需注意，在第二实施例中，相似于第一实施例，可以在样本组条目中布置组定义和switch Group定义。

另外，在第二实施例中，相似于第一实施例，音频数据的轨道的配置还可以为在图23、图26、图28、图30、图32至图34和图35中所示的配置。

图45至图47为示图，它们分别示出第二实施例中的音频数据的轨道的配置为在图23、图26和图28中所示的配置的情况下的MPD。在第二实施例中，在音频数据的轨道的配置为在图32、图33、图34或图35中所示的配置的情况下的MPD文件相同于在图23、图26和图28中所示的配置情况下的MPD。

图45的MPD与图39的MPD不同之处在基本轨道的“编解码器”和“associationId(关联Id)”，以及在于<EssentialProperty schemeIdUri＝“urn:mpeg:DASH:3daudio:2014”value＝“dataType,definition”>包括在基本轨道的“Representation”中。具体地，图45的MPD的基本轨道的“Representation”的“编解码器”为“mha2.2.1”，而“关联Id”为组轨道的“id”的“g1”和“g2”。

另外，图46的MPD与图45的MPD不同之处在于组轨道的“编解码器”，且在于<EssentialProperty schemeIdUri＝“urn:mpeg:DASH:3daudio:2014”value＝“dataType,definition”>不包括在组轨道的“Representation”中。具体地，图46的MPD的组轨道的“编解码器”为“mha2.2.1”。

另外，图47的MPD与图45的MPD不同之处在于基本轨道和组轨道的“编解码器”。具体地，图47的MPD的组轨道的“编解码器”为“mha3.2.1”。

需注意，在图45至图47的MPD中，“适应集(AdaptationSet)”可以针对“Representation”进行分割，如图48至图50所示。

<基本轨道的另一个示例>

在以上描述中，仅提供一个基本轨道。然而，可以提供多个基本轨道。在这种情况下，基本轨道被提供用于例如3D音频的每个视点(细节将在下面给出)，并且在基本轨道中，布置包括视点的3D音频的所有组的配置信息的mhaC盒子。需注意，在基本轨道中，可以布置包括视点的音频场景信息的mhas盒子。

3D音频的视点是可以听到3D音频的位置，诸如与3D音频同时再现的图像的视点或预先设置的预定位置。

如上所述，在针对每个视点分割基本轨道的情况下，可以基于包括在每个视点中的配置信息中的在屏幕上的对象的位置等，从相同3D音频的音频流中再现针对每个视点不同的音频。结果，可以减少3D音频的音频流的数据量。

即，在3D音频的视点是可以与3D音频同时再现的棒球场的图像的多个视点的情况下，将在中心后屏幕中具有视点的图像准备为基本视点的图像的主图像。此外，将具有位于板后面的座位中的视点的图像、一垒内内场看台座位、三垒内场看台座位、左外野看台座位、右外野看台座位等准备作为多图像，其为视点(其为非基本视点)的图像。

在这种情况下，如果准备所有视点的3D音频，则3D音频的数据量变大。因此，通过对基本轨道描述视点中的在屏幕上对象等的位置，可以通过视点共享根据在屏幕上对象的位置而改变的音频流诸如Object audio和SAOCObject audio。结果，可以减少3D音频的音频流的数据量

在3D音频的再现时，例如，使用音频流诸如Object audio和SAOCObject audio，以及对应于主图像视点的基本轨道或者在相同时间利用音频流再现的多个图像，根据视点再现不同音频。

相似地，例如，在3D音频的视点是预先设定的体育场的多个座位的位置的情况下，如果准备所有视点的3D音频，则3D音频的数据量变大。因此，通过对基本轨道描述在屏幕上对象的位置，在视点中，可以通过视点共享音频流诸如Object audio和SAOCObject audio。因此，根据由用户使用座位表、使用一个视点的Object audio和SAOCObject audio选择的座位可以再现不同音频，且可以减少3D音频的音频流的数据量。

在基本轨道被提供用于在图28的轨道结构中的3D音频的每个视点的情况下，轨道结构变为如图51所示的一个。在图51所示的示例中，3D音频的视点的数量为三。另外，在图51所示的示例中，针对3D音频的每个视点生成声道音频，并且其他音频数据由3D音频的视点共享。这同样适用于下述图52的示例。

在这种情况下，三个基本轨道被提供用于3D音频的每个视点，如图3所示。轨道参考布置在基本轨道中的每个的轨道盒子中。另外，每个基本轨道的样本条目的语法与4cc为“mha3”的样本条目的语法相同。4cc是指示基本轨道被提供用于3D音频的每个视点的“mhcf”。

包括每个视点的3D音频的所有组的配置信息的mhaC盒子被布置在每个基本轨道的样本条目中。例如，在视点中，因为每个视点的3D音频的所有组的配置信息是在屏幕上的对象的位置。另外，包括每个视点的音频场景信息的mhas盒子布置在每个基本轨道中。

视点的声道音频的组的音频流布置在基本轨道的样本中。

需注意，在样本单元中，在每个视点中存在描述对象在屏幕上的位置的Object Metadata的情况下，Object Metadata也布置在每个基本轨道的样本中。

即，在对象是移动体(例如，运动员)的情况下，在每个视点中屏幕上的对象的位置随时间改变。因此，该位置描述为样本单元中的Object Metadata。在这种情况下，对于每个视点，在样本单元中的Object Metadata布置在对应于视点的基本轨道的样本中。

图51的组轨道的配置与图28的配置相同，除了未布置声道音频的组的音频流，因而省略描述。

需注意，在图51的轨道结构中，视点的声道音频的组的音频流可以不布置在基本轨道中，并且可以布置在不同的组轨道中。在这种情况下，轨道结构变成在图52中所示的一个。

在图52所示的示例中，对应于轨道ID为“1”的基本轨道的视点的声道音频组的音频流布置在轨道ID为“4”的组轨道中。另外，对应于轨道ID为“2”的基本轨道的视点的声道音频组的音频流布置在轨道ID为“5”的组轨道中。

另外，对应于轨道ID为“3”的基本轨道的视点的声道音频组的音频流布置在轨道ID为“6”的组轨道中。

需注意，在图51和图52的示例中，基本轨道的样本条目的4cc为“mhcf”。然而，4cc可为与图28相同的“mha3”。

另外，虽然省略图示，但是其中基本轨道被提供用于在上述所有轨道结构(除了图28的轨道结构外)中的3D音频的每个视点的情况相似于在图51和52的情况。

<第三实施例>

(本公开应用至的计算机的描述)

网络服务器142(212)的一系列处理可以由硬件执行或者可以由软件执行。在通过软件执行一系列处理的情况下，配置软件的程序安装至计算机。这里，计算机包括结合特殊硬件的计算机和通过安装各种类型的程序可以执行各种功能的通用个人计算机等。

图53是框图，其示出利用程序执行网络服务器142(212)的一系列处理的计算机的硬件的配置示例。

在计算机中，中央处理单元(CPU)601、只读存储器(ROM)602和随机存取存储器(RAM)603通过总线604相互连接。

输入/输出接口605还连接到总线604。输入单元606、输出单元607、存储单元608、通信单元609和驱动器610连接到输入/输出接口605。

输入单元606由键盘、鼠标、麦克风等构成。输出单元607由显示器、扬声器等构成。存储单元608由硬盘、非易失性存储器等构成。通信单元609由网络接口等构成。驱动器610驱动可移动介质611诸如磁盘、光盘或磁光盘或半导体存储器。

在如上所述配置的计算机中，CPU 601通过输入/输出接口605和总线604将存储在存储单元608中的程序加载到RAM 603上，并执行该程序，从而执行一系列处理。

由计算机(CPU 601)执行的程序可以通过例如记录在作为封装介质的可移动介质611中来提供。此外，可以通过有线或无线传输介质诸如局域网、互联网或数字卫星广播来提供程序。

在计算机中，可以通过将可移动介质611附接到驱动器610而经由输入/输出接口605将程序安装到存储单元608。此外，程序可以由通信单元609通过有线或无线传输介质接收，并安装到存储单元608。另外，程序可以预先安装到ROM 602或存储单元608。

需注意，由计算机执行的程序可以是根据本说明书中描述的顺序以时间序列处理的程序，或者可以是在诸如被调用时并行处理的程序或者在必要定时处理的程序。

另外，运动图像再现终端144(214)的硬件配置可以具有与图53的计算机相似的配置。在这种情况下，例如，CPU 601执行控制软件161(221)、运动图像再现软件162和访问软件163(223)。运动图像再现终端144(214)的处理可以由硬件执行。

在本说明书中，系统意指多个配置元件(设备、模块(组件)等)的集合，并且所有配置元件可以或可以不在相同外壳中。因此，容纳在分离的壳体中并经由网络连接的多个装置和在单个壳体中容纳多个模块的单个装置均是系统。

注意，本公开的实施例不限于上述实施例，并且在不脱离本公开的精神和范围的情况下可以进行各种改变。

此外，本公开可以应用于执行广播或本地存储再现而非流再现的信息处理系统。

在MPD的实施例中，通过具有当由模式描述的内容不能被理解时可以忽略的描述符定义的基本属性来描述信息。然而，可以通过具有即使由模式描述的内容不能被理解也可以再现的描述符定义的适当性(SupplementalProperty)来描述信息。该描述方法由创作具有意图的内容的侧来选择。

此外，本公开可以采用如下的配置。

(1)一种信息处理装置，包括:

文件生成单元，其被配置成生成文件，其中多个种类的音频数据按所述种类的每一种或多种被分割到轨道中并被布置，且与所述多个种类相关的信息被布置。

(2)根据(1)所述的信息处理装置，其中

与所述多个种类相关的信息布置在预定轨道的样本条目中。

(3)根据(2)所述的信息处理装置，其中

预定轨道为其中分割和布置所述多个种类的音频数据的轨道中的一个。

(4)根据(1)至(3)中任一项所述的信息处理装置，其中，

对于所述轨道中的每个，与对应于所述轨道的种类相关的信息布置在文件中。

(5)根据(4)所述的信息处理装置，其中，

对于所述轨道中的每个，与排他再现种类相关的信息被布置在所述文件中，排他再现种类由与轨道对应的种类、以及对应于从与轨道对应的种类的音频数据排他地再现的音频数据的种类构成。

(6)根据(5)所述的信息处理装置，其中

与对应于所述轨道的所述种类相关的信息和与排他再现种类相关的信息布置在对应轨道的样本条目中。

(7)根据(5)或(6)所述的信息处理装置，其中

所述文件生成单元生成管理文件，所述管理文件管理包括指示与排他再现种类相关的信息针对所述轨道中的每个存在与否的信息的所述文件。

(8)根据(1)至(7)中任一项所述的信息处理装置，其中

对应于所述多个种类的所述轨道的参考信息布置在所述文件中。

(9)根据(8)所述的信息处理装置，其中

所述参考信息布置在预定轨道的样本中。

(10)根据(9)所述的信息处理装置，其中

所述预定轨道为其中分割和布置所述多个种类的音频数据的轨道中的一个。

(11)根据(1)至(10)中任一项所述的信息处理装置，其中

指示所述轨道之间的参考关系的信息布置在所述文件中。

(12)根据(1)至(11)中任一项所述的信息处理装置，其中

所述文件生成单元生成管理文件，所述管理文件管理包括指示所述轨道之间的参考关系的信息的所述文件。

(13)根据(1)至(12)中任一项所述的信息处理装置，其中

所述文件为一个文件。

(14)根据(1)至(12)中任一项所述的信息处理装置，其中

所述文件为所述轨道中的每个的文件。

(15)一种信息处理方法，包括以下步骤:

通过信息处理装置，生成文件，其中多个种类的音频数据针对所述种类的每一种或多种而被分割到轨道中并被布置，且与所述多个种类相关的信息被布置。

(16)一种信息处理装置，包括:

再现单元，其被配置成从文件中再现预定轨道的音频数据，在所述文件中多个种类的音频数据针对所述种类的每一种或多种而被分割到轨道中并被布置，且与所述多个种类相关的信息被布置。

(17)一种信息处理方法，包括以下步骤:

通过信息处理装置从文件中再现预定轨道的音频数据，在所述文件中多个种类的音频数据针对所述种类的每一种或多种而被分割到轨道中并被布置，且与所述多个种类相关的信息被布置。

参考标记列表

11 文件生成设备

192 音频文件获取单元

194 音频解码处理单元

195 音频合成处理单元

211 文件生成设备

264 音频文件获取单元

权利要求书(按照条约第19条的修改)

1.一种信息处理装置，包括：

文件生成单元，被配置为针对组中的每个组，将轨道分配至包括多个所述组的由一个轨道构成的音频流以生成由多个所述轨道构成的文件，所述组利用组ID来表示并且由一个或多个音频元素配置成。

2.根据权利要求1所述的信息处理装置，其中

所述文件包括表示所述多个组与所述多个轨道之间的对应关系的信息。

3.根据权利要求2所述的信息处理装置，其中

表示所述多个组与所述多个轨道之间的对应关系的信息包括所述多个组的组ID。

4.根据权利要求2所述的信息处理装置，其中

表示所述多个组与所述多个轨道之间的对应关系的信息包括所述多个组的组ID以及与所述多个轨道对应的轨道ID。

5.根据权利要求2所述的信息处理装置，其中

表示所述多个组与所述多个轨道之间的对应关系的信息被包括在基本轨道中。

6.根据权利要求2所述的信息处理装置，其中

所述文件生成单元将表示所述多个组与所述多个轨道之间的对应关系的信息设定为不同于与所述多个组相关的音频场景信息和所述多个组的配置信息的盒子。

7.根据权利要求1所述的信息处理装置，其中

与所述多个组相关的信息被布置在所述文件中的预定轨道的样本条目中。

8.根据权利要求1所述的信息处理装置，其中

对于所述轨道中的每个轨道，与对应于所述轨道的组相关的信息被布置在所述文件中。

9.根据权利要求1所述的信息处理装置，其中

对于所述轨道中的每个轨道，与排他再现组相关的信息被布置在所述文件中，所述排他再现组由与所述轨道对应的组以及对应于从与所述轨道对应的组的音频元素中排他地再现的音频元素的组构成。

10.根据权利要求9所述的信息处理装置，其中

与对应于所述轨道的组相关的信息和与排他再现组相关的信息被布置在对应轨道的样本条目中。

11.根据权利要求9所述的信息处理装置，其中

所述文件生成单元生成管理文件，所述管理文件管理包括表示与排他再现组相关的信息是否针对所述轨道中的每个轨道而存在的信息的所述文件。

12.根据权利要求1所述的信息处理装置，其中

所述多个轨道的参考信息被布置在所述文件中。

13.根据权利要求12所述的信息处理装置，其中

所述参考信息被布置在预定轨道的样本中。

14.根据权利要求1所述的信息处理装置，其中

表示所述轨道之间的参考关系的信息被布置在所述文件中。

15.根据权利要求1所述的信息处理装置，其中

所述文件生成单元生成管理文件，所述管理文件管理包括表示所述轨道之间的参考关系的信息的所述文件。

16.根据权利要求1所述的信息处理装置，其中

所述文件是一个文件。

17.根据权利要求1所述的信息处理装置，其中

所述文件是所述轨道中的每个轨道的文件。

18.一种信息处理方法，包括以下步骤:

针对组中的每个组，将轨道分配至包括多个组的由一个轨道构成的音频流以生成由多个所述轨道构成的文件，所述组利用组ID来表示并且由一个或多个音频元素配置成。

19.一种信息处理装置，包括：

再现单元，被配置成从由多个轨道构成的文件中再现预定轨道，所述文件通过针对组中的每个组将轨道分配至包括多个所述组的由一个轨道构成的音频流而生成，所述组利用组ID来表示并且由一个或多个音频元素配置成。

20.一种信息处理方法，包括以下步骤：

从由多个轨道构成的文件中再现预定轨道，所述文件通过针对组中的每个组将轨道分配至包括多个所述组的由一个轨道构成的音频流而生成，所述组利用组ID来表示并且由一个或多个音频元素配置成。