本申请是向中国知识产权局提交的申请日为2016年2月15日的标题为“用于对包括系统数据的音频比特流进行解码的方法和设备”的申请号为201680010203.6的申请的分案申请。
本发明涉及一种用于对包括系统数据的音频比特流进行解码的方法和设备，更具体地讲，涉及一种用于通过使用mpeg-h3d音频流包来发送和恢复系统数据的方法和设备。
背景技术：
根据广播环境的改变，地面广播更可能通过使用机顶盒的重传被提供给用户，而不是通过地面传输被提供给用户。
当地面广播信号通过使用机顶盒等被重传时，高清晰度多媒体接口(hdmi)主要用作机顶盒和电视(tv)之间的接口。然而，由于hdmi并不提供用于发送除了音频数据和视频数据之外的数据(例如，系统数据)的接口，因此系统数据不可经由hdmi被发送给tv。
在这种情况下，为了使用双向广播服务或混合广播服务，用户必须使用从机顶盒发送到广播公司的信道，并且tv不能够独自作为用于双向广播的媒介。
技术实现要素：
技术问题
由于高清晰度多媒体接口(hdmi)不需要针对音频或视频的传输的单独的压缩处理，因此不必须有额外硬件或软件用于恢复，并且数字内容可在不存在任何质量恶化的情况下被发送。然而，如上所述，由于hdmi不提供用于发送除了音频数据和视频数据之外的数据(例如，系统数据)的接口，因此系统数据不可经由hdmi被发送给tv。
提出本发明以解决相关技术的上述问题并且通过使用通过hdmi发送的音频比特流来发送系统数据。
技术方案
根据本发明的一方面，提供一种对音频进行解码的方法，所述方法包括：接收包括音频包的比特流；对接收到的比特流中所包括的音频包进行解码；提取解码的包的类型；从系统元数据对应于提取的解码的包的类型的包获得系统数据；将获得的系统数据发送给系统引擎，其中，系统数据包括以下项中的至少一项：与系统引擎的类型有关的信息以及与系统数据的长度有关的信息。
根据另一实施例，音频比特流经由高清晰度多媒体接口(hdmi)被接收。
根据另一实施例，接收的步骤还包括：确定是否使用获取的系统数据。
根据另一实施例，系统引擎的类型指示以下项中的至少一项：mpeg媒体传输(mmt)以及通过http的动态自适应流传输(dash)。
根据另一实施例，系统数据基于与系统数据有关的位置信息被获得。
根据另一实施例，与系统数据有关的位置信息指示系统数据的位置所在的统一资源定位符(url)。
根据另一实施例，比特流是mpeg-h3d音频流(mhas)。
根据本发明的另一方面，提供了一种音频解码设备，包括：接收器，被配置为接收包括音频包的比特流；解码器，被配置为对接收到的比特流中所包括的音频包进行解码；控制器，被配置为提取解码的包的类型，并且从系统元数据对应于提取的解码的包的类型的包获得系统数据；发送器，被配置为将获得的系统数据发送给系统引擎，其中，系统数据包括以下项中的至少一项：与系统引擎的类型有关的信息以及与系统数据的长度有关的信息。
根据另一实施例，接收器还被配置为经由高清晰度多媒体接口(hdmi)接收音频比特流。
根据另一实施例，控制器确定是否使用获得的系统数据。
根据另一实施例，系统引擎的类型指示以下项中的至少一项：mpeg媒体传输(mmt)以及通过http的动态自适应流传输(dash)。
根据另一实施例，系统数据基于与系统数据有关的位置信息被获得。
根据另一实施例，与系统数据有关的位置信息指示系统数据的位置所在的统一资源定位符(url)。
根据另一实施例，比特流是mpeg-h3d音频流(mhas)。
根据本发明的另一方面，提供另一种方法、另一种系统、一种用于实现所述方法的计算机程序、以及一种记录有计算机程序的非暂时性计算机可读记录介质。
发明的有益效果
根据本发明，内容创建器可通过使用按照mpeg-h标准限定的音频编解码器来进行编码而产生包括系统数据的音频比特流。机顶盒可使用高清晰度多媒体接口(hdmi)将包括系统数据的音频流发送给tv，而不必须改变连接到tv的接口。tv可通过使用按照mpeg-h标准限定的音频编解码器通过对接收到的音频比特流进行解码来获得系统数据。
附图说明
图1是示出地面广播的传输路径的实施例的示图。
图2是示出根据本发明的实施例的地面广播的传输路径的示图。
图3是示出根据本发明的实施例的包括音频解码设备的内容回放设备的详细配置的示图。
图4是根据本发明的实施例的音频解码方法的流程图。
图5是根据本发明的另一实施例的音频解码方法的流程图。
图6是根据本发明的另一实施例的音频解码方法的流程图。
图7是用于描述根据本发明的实施例的用于处理mhas包的净荷的语法的示图。
图8是示出根据本发明的实施例的与mpeg-h3d音频流(mhas)包类型有关的mhaspackettype值的示图。
图9是用于描述根据本发明的实施例的用于处理系统数据包的语法的示图。
图10是用于描述根据本发明的实施例的用于处理系统数据包的语法的示图。
图11是示出根据本发明的另一实施例的用于处理系统数据包的语法的示图。
图12是示出通过使用节目标识符来处理系统数据包的方法的示图。
图13是示出根据本发明的实施例的sysmetapacketconfig的操作的示图。
图14是示出根据本发明的实施例的sysmetapacket的操作的示图。
图15是示出根据本发明的另一实施例的sysmetapacket的操作的示图。
图16是示出根据本发明的实施例的系统级操作的概述的示图。
具体实施方式
最佳实施方式
用于实现目标的本发明的有代表性的技术配置如下。
提供了一种对音频进行解码的方法，所述方法包括：接收由音频包组成的比特流；对接收到的比特流中所包括的音频包进行解码；提取解码的包的类型；从系统元数据对应于提取的解码的包的类型的包获得系统数据；将获得的系统数据发送给系统引擎，其中，系统数据包括以下项中的至少一项：与系统引擎的类型有关的信息和与系统数据的长度有关的信息。
发明的实施方式
以下给出的本发明的详细描述参照了附图，其中，所述附图以示例的方式示出本发明可被实践的特定实施例。这些实施例被足够详细地描述以使本领域普通技术人员能够实践本发明。应该理解，本发明的各种实施例可彼此不同，但是不需要互相排斥。
例如，在不脱离本发明的精神和范围的情况下，在本说明书中描述的特定形状、结构和特征可从一个实施例到另一个实施例被修改和改变。还应该理解，在不脱离本发明的精神和范围的情况下，每个实施例之内的各个组件的位置或布置可被改变。相应地，下面的详细描述将不在限制意义上被采用，并且本发明的范围应该被解释为包括权利要求及其所有等同物的范围。
在附图中的同样的附图标号在数个方面始终表示同样或类似的组件。为了清楚地示出本发明，本发明的说明未涉及的部件被省略，贯穿说明书，同样的部件通过同样的附图标号来表示。
在下文中，将参照附图详细地描述本发明的各种实施例，使得本领域技术人员可容易地实施本发明。然而，本发明可以以许多不同形式来实施，并且不应该被解释为限于在此提出的实施例。
贯穿说明书，将理解，当一部分被称作“连接到”另一部分，所述一部分可被“直接连接到”所述另一部分或者经由另一元件“电连接到”所述另一部分。另外，还将理解，在此使用的术语“包括”和/或“包含”指定陈述的特征或组件的存在，但是不排除一个或更多个其它特征或组件的存在或添加。
在下文中，在此使用的术语的限定如下。
系统数据可以是与用于多媒体传输的传输层有关的信息。
系统数据是与系统引擎(诸如，mpeg媒体传输(mmt)引擎或通过http的动态自适应流传输(dash)引擎)有关的数据。系统数据可遵照多用途互联网邮件扩充(mime)结构并且可指的是dash媒体呈现描述(mpd)或mmt信令消息。
mmt层结构包括：包括封装层、传递层、以及信令层的功能区域。mmt层在传输层上操作。
系统数据可包括与系统数据的位置有关的信息。在这种情况下，系统数据的位置可指示系统数据的位置所在的统一资源定位符(url)。
系统引擎可指示dash引擎或mmt引擎。
系统数据可包括与系统引擎的类型有关的信息。与系统引擎的类型有关的信息是与系统数据对应的参照并且可指示诸如mmt引擎或dash引擎的系统引擎。
mmt是用于mpeg多媒体传输的传输层，并且意图用于作为将在广播和互联网多媒体应用中使用的标准的基于推送的服务。
dash是针对自适应视频流传输的标准，该标准是从mmt分离而出的并且在mmt之前被标准化。为了基于推送的服务，dash限定了多媒体呈现描述格式，其中，多媒体呈现描述格式包括多媒体数据的片段(即，分段文件)的类型以及与其有关的信息。
在下文中，将参照附图详细地描述本发明。
图1是示出地面广播的传输路径的实施例的示图。
内容提供商(节目制作者)100通常可通过两种方式将内容提供给用户。
将内容提供给用户的第一方法是通过由地面广播公司200执行的无线传输来提供内容的方法。地面广播公司200通过地面广播站210的传输塔传输用于地面广播的信号。此时，通过通信塔传输的用于地面广播的信号以无线电波的形式在陆地上传输并且包括音频信号、视频信号、以及系统数据。
内容回放设备600通常是电视机(tv)，内容回放设备600可通过使用户外天线等接收用于地面广播的信号。由于通过内容回放设备接收到的用于地面广播的信号包括音频信号、视频信号和系统数据，因此内容回放设备600可包括用于对音频内容进行解码的音频编解码器610、用于对视频内容进行解码的视频编解码器以及用于处理系统数据的系统引擎630。
超高清晰度(uhd)内容根据作为国际标准的运动图像专家组(mpeg)标准被编码并且被发送，其中，其系统数据满足作为高效视频编码标准的mpeg-h传输层标准。
数据广播可根据是否存在返回信道或返回信号而被划分为单向广播和双向广播。在数据广播的前期，诸如atsc1.0，主要针对单向广播开发技术。然而，近年来，附加数据被添加到现有的广播信号的双向广播被一起提供，使得用户可在观看tv的同时搜索或接收与广播节目有关的信息或其它信息。
在提供单向广播和双向广播两者的混合广播中，tv可用作用于内容和用户之间的交互的媒介，tv被设计为可连接到用于实现混合功能的互联网网络700。
将内容提供给用户的第二方法是由多频道视频节目分发商400等通过有线传输重传地面广播内容的方法。多频道视频节目分发商400是由联邦通信委员会(fcc)规定的传递视频节目服务的服务提供商。根据fcc规范，“诸如但不限于以下项的人：可用于订阅者或顾客购买视频节目的多个频道的有线运营商、多频道多点分发服务、直接广播卫星服务、或者仅电视接收的卫星节目分发器”。
多频道视频节目分发商400包括有线tv、卫星tv、以及iptv，指的是组织实时频道并提供广播频道使用公司(节目提供商)的内容的公司。与多频道视频节目分发商400有关的最近的趋势包括：横向合并的启动、针对内容传输的增长的价格、以及实时过顶(oot)服务的开展。在北美区域，多频道视频广播分发器400被称作在加拿大的广播分发企业。
多频道视频节目分发商400通过重传从地面广播公司200或有线网络300发送的广播内容将广播内容提供给用户。从多频道视频节目分发商400重传的广播内容被专门用于每个多频道视频节目分发商的机顶盒500所接收。
被机顶盒500接收的广播内容可包括以编码的比特流的形式的音频数据、视频数据、以及系统数据。机顶盒500可包括用于对视频数据进行解码的视频编解码器510。机顶盒500可将接收到的音频比特流810或通过对接收到的视频数据进行解码而产生的音频pcm和原始音频数据发送给内容回放设备600。
内容回放设备600可将从机顶盒500发送的解码的视频数据820或音频pcm直接再现。由于内容回放设备600可包括用于对音频内容进行解码的音频编解码器610，因此内容回放设备600可对从机顶盒500发送的音频比特流810进行解码并再现音频内容。
这里，机顶盒500和内容回放设备600之间的接口主要是高清晰度多媒体接口，即hdmi。hdmi是未压缩的数字视频/音频接口标准，并且与使用传统模拟接口相比，hdmi使用户能够享受较高质量的声音或视频。
hdmi是对作为pc和显示设备之间的接口的标准的dvi的修改，针对av电子设备，hdmi是用于在不压缩的情况下传输视频信号和音频信号的数字接口，并且提供在支持hdmi的多媒体源(诸如，机顶盒与dvd播放器，以及包括pc和tv的av装置与监视器)之间的接口。
由于hdmi不包括针对音频或视频的传输的单独的压缩处理，因此针对重构的额外硬件或软件不是必要的。然而，由于hdmi不提供用于发送除了音频数据和视频数据之外的数据(例如，系统数据)的接口，因此系统数据不可经由hdmi被发送给内容回放设备600。
因此，当机顶盒500经由hdmi线缆800被连接到内容回放设备600时，宽带连接所需要的混合广播数据或系统数据不被发送给内容回放设备600。
在这种情况下，为了使用双向广播服务，用户必须使用从机顶盒500发送给多频道视频节目分发商400的返回频道520，并且内容回放设备600不能独自用作用于内容和用户之间的交互的媒介。
图2是示出根据本发明的实施例的地面广播的传输路径的示图。
在图2中示出的实施例涉及一种对由多频道视频节目分发商400通过有线传输提供的地面广播内容进行重传的方法，如图1中所示的实施例中，从多频道视频节目分发商400重传的广播内容被专门用于每个多频道视频节目分发器的机顶盒500接收。
然而，在图1中所示的实施例中，由于系统数据未包括在通过hdmi发送给内容回放设备600的数据中，因此通过机顶盒500接收重传的内容的用户不能够使用双向广播服务。
在图1中所示的实施例中，为了额外地发送系统数据，必须确定哪个传输信道是可用的以及哪个数据将被传输。当音频比特流用作用于发送系统数据的载体时，通过机顶盒500接收重传的内容的用户也可使用双向广播服务。
换句话讲，如图2中示出的实施例中，当系统数据包括在音频数据中并且音频数据被编码时，从多频道音频节目分发器400重传的内容的音频数据包括与系统数据有关的信息。因此，即使当地面广播内容通过机顶盒500被重传时，系统数据也可通过hdmi的音频信道被发送给内容回放设备600。
具体地讲，内容提供商100对广播内容的音频数据进行编码，内容提供商100将系统数据包括在音频数据中并且对音频数据进行编码。地面广播公司200或有线网络300将从内容提供商100接收到的广播内容发送给多频道视频节目分发器400，并且多频道视频节目分发器400将从地面广播公司200或有线网络300接收到的广播内容重传给用户的机顶盒500。
由机顶盒500接收到的广播内容可包括以编码的比特流的形式的音频数据、视频数据和系统数据。在这种情况下，由机顶盒500接收到的系统数据可以是未包括在音频数据中的其它系统数据。
机顶盒500可包括用于对音频数据进行解码的视频编解码器510。机顶盒500将接收到的音频比特流810发送给内容回放设备600，并将通过对接收到的视频数据进行解码而产生的原始视频数据820发送给内容回放设备600。此时，音频比特流可以是包括用于系统信令的系统数据的压缩的mpeg-h音频流。
由于内容回放设备600可包括用于对音频内容进行解码的音频编解码器610，因此内容回放设备600可对从机顶盒500发送的音频比特流810进行解码并再现音频内容。
根据本发明的另一实施例，与另一内容对应的地面广播公司200、有线网络300或多频道视频节目分发商400可对音频数据进行编码，使得系统数据包括在音频比特流中。
通过使用各种传输信道之中的音频传输信道来传送系统数据的优点如下。
音频比特流可以是用于通过hdmi将数据从机顶盒传递到tv(即内容回放设备)的最佳载体。mpeg-h3d音频流(mhas)具有灵活的方案。因此，如图2中所示的实施例中，当音频比特流被用作用于传输系统数据的载体时，可利用mhas。
在这种情况下，系统数据被封装到mhas包中并且变成mpeg-h3d音频数据流的一部分。
mpeg系统标准提供充分限定的功能术语和稳定性。另外，在实际使用中，在多数情况下，期望mpeg系统接收器作为tv。由于mpeg音频已经在tv中实现，因此tv能够处理遵照mpeg标准的音频比特流。换句话讲，当mpeg-h3d音频被用作数据传输器时，可照旧使用mpeg系统的语法。
当mpeg-h3d音频被用作数据传输器时，如图2中所示，使用系统数据的服务场景可通过经由hdmi连接发送作为mhas包的系统数据来实现。
图3是示出根据本发明的实施例的包括音频解码设备的内容回放设备600的详细配置的示图。
如图3中所示，根据本发明的实施例的包括音频解码设备的内容回放设备600包括接收器310、发送器320、解码器330、回放单元340、存储单元360以及控制器350。
接收器310接收从机顶盒发送的内容等。根据实施例，在不存在机顶盒的情况下发送的内容也可被接收，但是其描述将在此省略。
当机顶盒通过hdmi被连接到内容回放设备600时，通过接收器310接收的信号变成解码的原始视频数据和未解码的音频流。由于hdmi不具有针对系统数据的传输的单独信道，因此系统数据可不通过hdmi被独立地接收。然而，根据本发明的实施例，由于系统数据包括在音频比特流中，因此系统数据可通过hdmi被接收。
发送器320将从解码器330发送的恢复的系统数据发送给系统引擎。
解码器330根据接收的内容被编码时使用的编解码器来对接收到的内容进行解码。当内容回放设备600是tv时，解码器330可执行视频解码和音频解码两者。当内容通过连接到机顶盒500的hdmi被接收时，由于接收到的视频已经被解码，因此仅接收到的音频比特流被解码。
根据本发明的实施例，由于音频比特流包括系统数据，因此作为对音频比特流进行解码的结果，恢复的系统数据可与恢复的音频信号一起被获得。编解码器330可将获得的系统数据发送给与系统数据对应的系统引擎。
回放单元340通过显示器、扬声器等对恢复的视频或音频进行回放。
控制器350控制整个内容回放设备600的操作并且控制接收器310、发送器320、解码器330、回放单元340以及存储单元360的操作，使得内容回放设备600再现恢复的内容并且将获得的系统数据发送给系统引擎。
控制器350可基于通过接收器310接收到的音频比特流来确定是否使用音频比特流中所包括的系统数据。当控制器350确定使用系统数据时，解码器330将系统数据发送给发送器320以将提取的系统数据发送给系统引擎。
存储单元360存储内容回放设备600恢复并再现内容所必须的各种类型的信息以及处理系统数据所必须的各种类型的信息。图4是根据本发明的实施例的音频解码方法的流程图。
内容回放设备600通过接收器310接收内容(操作410)。当机顶盒经由hdmi被连接到内容回放设备600时，通过接收器310接收到的信号变成解码的原始视频数据和未解码的音频流。
内容回放设备的解码器330根据用于音频编码的编解码器对接收到的音频比特流进行解码(操作420)。
根据本发明的实施例，由于音频比特流包括系统数据，因此作为对音频比特流解码的结果，恢复的系统数据可与恢复的音频信号一起被获得(操作430)。
解码器330还可将获得的系统数据发送给系统引擎(操作440)。
图5示出根据本发明的另一实施例的音频解码方法的流程图。
音频比特流是用于发送系统数据的良好载体。然而，当系统数据的长度变得极大时，音频比特流的大小也变大，并且因此不可能确保音频数据所必须的充足容量(带宽)。因此，必须限制系统数据的长度以便保证用于音频数据的充足容量。
在这种情况下，系统数据可不被直接包括在音频比特流中。因此，根据本发明的另一实施例，系统数据可被存储在特定位置(服务器)中，并且音频比特流可包括系统数据的位置。这里，系统数据的位置可以是统一资源定位符(url)。
例如，可包括在音频比特流中的系统数据的最大长度被限制为256个字节，并且当系统数据的长度超过最大大小时，指示系统数据的位置的url包括在音频比特流中。
图5中示出的实施例类似于图4中示出的实施例，并且与图4中示出的实施例相比，仅额外地包括用于获得系统数据的位置的操作530。
图6是根据本发明的另一实施例的音频解码方法的流程图。
内容回放设备600通过接收器310接收内容(操作610)。当机顶盒经由hdmi被连接到内容回放设备600时，通过接收器310接收的信号变成解码的原始视频数据和未解码的音频流。
内容回放设备600的解码器330根据用于音频编码的编解码器对接收到的音频比特流进行解码(操作620)。
根据本发明的实施例，由于音频比特流包括系统数据，因此作为对音频比特流进行解码的结果，恢复的系统数据与恢复的音频信号可一起被获得(操作630)。
这里，系统数据可具有根据系统数据将被应用到的系统引擎的结构和语法。这里，必须首先执行用于检查系统引擎的类型的操作640以处理系统数据。系统引擎可指的是由systype表示的通过http的动态自适应流传输(dash)引擎或mpeg媒体传输(mmt)引擎，其中，systype是与系统类型有关的参数。
此时，当系统类型中限定的系统引擎不存在时，确定系统数据将不被使用并且系统数据被忽略。当系统类型中限定的系统引擎存在时，确定系统数据将不被使用，并且系统数据被发送到与系统类型对应的系统引擎(操作650)。
图6中示出的实施例类似于图4中示出的实施例，并且与图4中示出的实施例比较，还包括用于获得系统引擎类型的操作被添加，其中，用于发送系统数据的操作430被修改为用于将系统数据发送给与获得的类型对应的系统引擎的操作650。
在下文中，将参照图7至图16来描述通过使用mpeg-h3d音频的mhas包来发送mpeg系统数据的方法。
参照图7至图15，将描述根据各种实施例的表示系统数据的语法。
当通过使用mpeg-h3d音频的mhas包来发送mpeg系统数据时，每个术语可被限定如下。
系统数据包括指示以下项的信息：(1)哪个内容将被回放，(2)内容在屏幕的哪个部分被恢复，或者(3)内容的回放何时开始。
系统数据是与系统引擎(诸如，mmt或dash)有关的数据，并且可指的是遵照指示系统数据的位置的多用途互联网邮件扩充(mime)结构的dash媒体呈现描述(mpd)或mmt信令消息。
系统包是指包括头部(诸如类型、标签和长度)的完整mhas包，并且系统包可在未被改变的状态下被发送给系统引擎。系统包可包括信息(诸如与系统包是否被扩充有关的信息或者与系统数据的版本有关的信息)。
可选地，从系统包提取的系统数据可被发送给系统引擎。
系统消息是通过mpeg-h3d音频解码器产生并且被发送给音频解码器的外部的系统的消息，并且可指的是节目标识符节目id、系统类型systype、系统数据位置sysdatalocation和升级状态isupdated。稍后将描述每个消息。
系统数据url被称作系统数据的位置所在的url。当系统数据url的metatype是utf-8sys_meta_utf8，(稍后描述的)sysdatalocation指示系统数据的url。当系统数据url的metatype是固定的64位无符号整数高位在先(uimsbf)二进制sys_meta_fixed_64时，sysdatalocation64指示系统数据的url。
系统引擎可指的是由systype指示的通过http的动态自适应流传输(dash)引擎或mpeg媒体传输(mmt)引擎，其中，systype是与系统类型有关的参数。
系统是指作为mpeg-h3d音频被实现的硬件的uhdtv等，并且mpeg-h3d解码器在系统之内被实现。
内容回放设备600可根据在图7至图16中举例说明的至少一个语法的命令和比特的数量从数据流获得并读取针对系统数据的参数。
图7是用于描述根据本发明的实施例的用于处理mhas包的载荷的语法。
mhaspacketpayload7000是用于根据mpeg-h3d音频的mhas包类型来处理载荷的语法。在mhaspacketpayload7000中，组件和解析器可被限定为使用mhaspackettype7010的pactyp_sysmeta7020。如图7中所示，通过修改在mpeg-h编解码器中限定的mhaspacketpayload功能，可实现为使用mhad包来发送mpeg系统数据。
换句话讲，当指示mpeg-h3d音频的mhas包类型的mhas包类型mhaspackettype7010对应于系统元数据pactyp_sysmeta7020时，sysmetapacket7030被调用。
图8是示出根据本发明的实施例的与mhad包类型有关的mhaspackettype值的示图。
当mpeg-h3d音频的mhas包类型mhaspackettype7010是pactyp_filldata时，mhaspackettype的值是0(8010)并且根据mhad包的长度来填充数据。
当mpeg-h3d音频的mhas包类型是pactyp_sysmeta7020时，mhaspackettype7010的值是15(8150)，并且系统元数据通过调用sysmetapacket来获得并且被发送给系统(7030)。
当mhaspackettype7010的值是16或更大时，意指mhas包类型未被限定并且被保留。
图9是用于描述根据本发明的实施例的用于处理系统数据包的语法的示图。
如图9中所示，当mhas包类型对应于pactyp_sysmeta时，通过使用'sysmetapacket'(9000)来配置系统数据。
'sysmetapacket'9000被限定以读取系统数据sysdata9030并且将sysdata9030发送给与systype9010对应的系统，其中，sysdata9030具有对应于datalen9020的字节大小。
systype9010是8位uimsbf并且指示系统数据被用于的mime类型或者系统数据sysdata9030将被发送到的系统引擎的类型。
datalen9020指示系统数据的长度，系统数据的最大长度可被限制为256个字节。由于系统数据的长度被限制，因此当系统数据的长度超过256个字节时，替代系统数据，指示dashmpd或mmt包访问(pa)信令消息的位置的url可包括在音频比特流中并且被发送。
图10是用于描述根据本发明的实施例的用于处理系统数据包的语法的示图。
图10示出systype9010的语法，并且图10的第一列示出systype9010可具有的系统引擎的类型。图10的第二列示出根据系统引擎的类型的systype9010的值，第三列示出与系统引擎的类型对应的mime类型。
当systype9010未被限定时，systype值是0，并且对应的mime类型也未被限定。
当systype9010是mmt时，systype值是1，并且对应的mime类型是应用/mmt信令和可扩展标记语言(xml)。
当systype9010是dash时，systype值是2，并且对应的mime类型是应用/dash信令和可扩展标记语言(xml)。
当systype值时3-255时，类型的限定被保留。具体地讲，当值是3-127时，类型的限定为国际组织标准(iso)而保留，当值是128-255时，类型的限定为用户设置而保留。
与系统引擎的类型对应的systype可遵照mime类型，但是也可不遵照mime类型。在这种情况下，mime类型信息被忽略。
如果systype9010未被限定或保留，则系统数据被抛弃。
图11是示出根据本发明的另一实施例的用于处理系统数据包的语法的示图。
如上所述，由于针对音频比特流的数据容量是有限的，因此当系统数据的容量大时，不可能将整个系统数据包括在音频比特流中。因此，系统数据的最大长度被限制为258个字节。当系统数据的长度超过258个字节时，系统数据的位置可包括在音频比特流而非系统数据中。
'sysmetapacket'1100读取三个字段，包括：systype1110、sysdatalocation1130、以及isdataupdated1140。
systype1110是8位uimsbf，指示系统数据被用于的mime类型和系统数据sysdata1130将被发送到的系统引擎。
datalen1120指示系统数据的长度，系统数据的最大长度可被限制为258个字节。由于系统数据的长度被限制，因此当系统数据的长度超过258个字节时，指示dashmpd或mmtpa信令消息的位置的url可包括在音频比特流而非系统数据中并且被发送。
sysdatalocation1130是8*datalen位的比特串左位在先(bslbf)并且可指示系统数据的位置所在的url。
isdataupdated1140是指示在sysdatalocation1130的系统数据是否已经改变的布尔标记，并且被指定以防止不必要的修补并执行有效的修补。
图12是示出通过使用节目标识符来处理系统数据包的方法的示图。
图12的'sysmetapacketconfig'1200指示根据实施例的用于处理系统数据的语法。当mhas包类型对应于pactyp_sysmeta时，'sysmetapacketconfig'1200可被另外地如图7中所示的那样被限定。
'sysmetapacketconfig'1200读取节目标识符节目id1210以防止系统的错误执行。系统标识符1210是32位uimsbf。
节目标识符1210指示当前节目的唯一标识符或者指示当前节目是否使用系统数据载体。换句话讲，节目标识符1210用于检查读取出的系统数据对于当前正被执行的节目是否有效。
节目标识符programid的初始值被设置为0，并且当节目由于频道改变等而被改变时，节目id被更新。在sysmetapacket被调用之前，programid可首先通过调用sysmetapacketconfig而被检查，从而确定系统数据载体是否被使用以及系统数据对于正被执行的节目是否有效。
例如，当广播频道被改变并且另一节目标识符被读取时，系统删除用于其它节目标识符的所有先前的系统消息。当当前节目未使用系统数据载体时，节目标识符被设置为0(0x0000)，并且系统可删除所有先前的系统消息。
将参照图13至图15更加详细地描述sysmetapacketconfig和sysmetapacket的操作。
图13是示出根据本发明的实施例的sysmetapacketconfig的操作的示图。
当programid从sysmetapacketconfig被读取时，与programid对应的系统消息在programid的字段值被改变时被发送给系统。基于系统消息中的programid，可将用于预设先前的系统数据的事件(诸如，源装置的频道改变)通知给系统。此时，在sysmetapacketconfig中，如图13中所示的那样被定义的系统消息被发送给系统。
图14是示出根据本发明的实施例的sysmetapacket的操作的示图。
当sysmetapacket被执行时，mpeg-h3d音频解码器如图14中所示将mime类型、数据url以及当前节目标识符组合并且产生系统消息msg。
图15示出根据本发明的另一实施例的sysmetapacket的操作的示图。
为了防止不必要的修补，如图15中所示，mpeg-h3d音频解码器可被配置为仅当sysdatalocation被改变时或者当与sysdatalocation对应的链接处的系统数据被改变时将系统消息msg发送给系统，而不改变sysdatalocation。
mpeg-h3d音频解码器产生并发送系统消息，使得系统可修补位于sysdatalocation的系统数据并且将系统数据发送给系统引擎。位于sysdatalocation的系统数据是dashpmd或mmt信令消息并且可遵照mime类型。
在以上描述中，已经描述了用于提供系统修补位于sysdatalocation的系统数据所经由的接口并且将系统数据发送给系统引擎的mpeg-h3d音频解码器的操作。
图16是示出根据本发明的实施例的系统级操作的概述的示图。
为了将mpeg-h3d音频信号用作系统数据载体，mpeg-h3d音频解码器和系统引擎必须彼此交互。必须实现下面的操作，使得系统修补系统数据并将系统数据发送给系统引擎。
(1)当通过sysmetapacket产生的系统消息msg被接收到时，系统基于目标系统引擎是否存在于系统之内以及系统更是否被连接到宽带网络而确定系统消息msg是否可被处理。
(2)当确定系统消息msg可被处理时，在系统消息msg的url字段中限定的系统数据被修补。当url与先前接收到的url相同并且isupdated是0时，系统可不修补系统数据。
(3)修补的系统数据被发送给与mime类型描述对应的系统引擎。
另外，当节目被改变时，事件应该被检测以清除预先加载的系统消息和数据。
(1)当通过sysmetapacketconfig产生的仅具有mprogid字段的系统消息msg从音频解码器被接收到时，系统将该mprogid与预先接收到的mprogid进行比较。当它们彼此不同时，与除了mprogid之外的programid有关的所有操作和缓存被删除并且属于其它节目的所有系统数据被删除。
(2)当mprogid被改变时，系统发送指示以下内容的系统消息：由于节目被改变，因此与先前的节目有关先前加载的系统操作将不被执行。
根据本发明的实施例的包括音频解码设备的内容回放设备可以是tv，根据本发明的另一实施例的系统引擎可以是mmt引擎。
当mhaspackettype是pactyp_sysmeta的mhas包被发送给mpeg-h3d音频解码器时，解码器将解码的pcm数据发送给回放单元(未示出)并将系统包发送给mmt引擎(1')。
当系统数据的容量大并且系统包包括系统数据的位置而非系统数据时，解码器将系统包发送给用于处理系统消息的后台程序(daemon)(1)。后台程序基于系统消息中所包括的位置来修补系统数据(2)，并且将通过修补系统数据而获得的系统数据发送给mmt引擎(3)。
mmt引擎通过使用接收到的系统包或接收到的系统数据来修改mmtpa消息并且解释mmtpa消息。
本发明的以上描述的实施例可被实现为可被各种计算机组件执行的可编程指令并且被存储在非暂时性计算机可读记录介质中。非暂时性计算机可读记录介质可包括程序指令、数据文件、数据结构或程序指令、数据文件、数据结构的组合。存储于非暂时性计算机可读记录介质中的程序指令可为本发明而具体地设计和配置或者对于软件领域的普通技术人员而言可以是公开获知并获得的。非暂时性计算机可读记录介质的示例包括专门被配置为存储并执行程序指令的硬件装置，例如，磁介质(诸如，硬盘、软盘和磁带)、光学记录介质(诸如，cd-rom、dvd等)、磁光介质(诸如，软光盘)、rom、ram、闪存等。程序指令的示例包括由例如编译器制成的机器代码以及可由计算机使用解释器执行的高级语言代码。以上示例性硬件装置可被配置为操作一个或更多个软件模块以便执行示例性实施例中的操作，反之亦可。
虽然已经参照本发明的示例性实施例具体地示出和描述了本发明，但是将理解，本发明不限制公开的实施例，而是相反，本领域技术人员将理解，在不脱离权利要求中公开的本发明的范围和精神的情况下，可做出各种修改、添加和替换。
因此，本发明的精神不应该被解释为限于以上描述的实施例，并且等同于本发明的权利要求或者从本发明的权利要求中的等同地修改的所有范围属于本发明的技术精神。
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
