CN103269475B - 数据收发设备和数据收发方法 - Google Patents
数据收发设备和数据收发方法 Download PDFInfo
- Publication number
- CN103269475B CN103269475B CN201310052879.XA CN201310052879A CN103269475B CN 103269475 B CN103269475 B CN 103269475B CN 201310052879 A CN201310052879 A CN 201310052879A CN 103269475 B CN103269475 B CN 103269475B
- Authority
- CN
- China
- Prior art keywords
- audio
- data
- stream
- bag
- sound
- 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.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims abstract description 51
- 238000009826 distribution Methods 0.000 claims description 64
- 230000005540 biological transmission Effects 0.000 claims description 62
- 230000005236 sound signal Effects 0.000 claims description 41
- 238000005070 sampling Methods 0.000 description 134
- 230000004048 modification Effects 0.000 description 33
- 238000012986 modification Methods 0.000 description 33
- 230000006870 function Effects 0.000 description 17
- 238000010586 diagram Methods 0.000 description 16
- 238000013507 mapping Methods 0.000 description 10
- 230000008901 benefit Effects 0.000 description 9
- 230000008859 change Effects 0.000 description 8
- 239000011248 coating agent Substances 0.000 description 8
- 238000000576 coating method Methods 0.000 description 8
- 241001269238 Data Species 0.000 description 7
- 238000004737 colorimetric analysis Methods 0.000 description 7
- 239000012530 fluid Substances 0.000 description 7
- 230000003252 repetitive effect Effects 0.000 description 5
- 241000894007 species Species 0.000 description 5
- 239000012634 fragment Substances 0.000 description 4
- 239000003550 marker Substances 0.000 description 4
- 230000008569 process Effects 0.000 description 4
- 230000008929 regeneration Effects 0.000 description 4
- 238000011069 regeneration method Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 3
- 230000011664 signaling Effects 0.000 description 3
- 239000003795 chemical substances by application Substances 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 238000003860 storage Methods 0.000 description 2
- 239000013589 supplement Substances 0.000 description 2
- 230000001052 transient effect Effects 0.000 description 2
- 101100018996 Caenorhabditis elegans lfe-2 gene Proteins 0.000 description 1
- PEDCQBHIVMGVHV-UHFFFAOYSA-N Glycerine Chemical compound OCC(O)CO PEDCQBHIVMGVHV-UHFFFAOYSA-N 0.000 description 1
- 206010047571 Visual impairment Diseases 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000000151 deposition Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000010606 normalization Methods 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000000717 retained effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
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/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/436—Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
- H04N21/4363—Adapting the video or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network
- H04N21/43632—Adapting the video or multiplex stream to a specific local network, e.g. a IEEE 1394 or Bluetooth® network involving a wired protocol, e.g. IEEE 1394
- H04N21/43635—HDMI
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04S—STEREOPHONIC SYSTEMS
- H04S3/00—Systems employing more than two channels, e.g. quadraphonic
-
- 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/439—Processing of audio elementary streams
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G2370/00—Aspects of data communication
- G09G2370/04—Exchange of auxiliary data, i.e. other than image data, between monitor and graphics controller
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G2370/00—Aspects of data communication
- G09G2370/12—Use of DVI or HDMI protocol in interfaces along the display data pipeline
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
- G09G5/003—Details of a display terminal, the details relating to the control arrangement of the display terminal and to the interfaces thereto
- G09G5/006—Details of the interface to the display terminal
Abstract
提供了一种数据收发设备和数据接收方法。根据本发明的多种实施例的数据发送设备,包括:生成与多声道音频数据相关的元数据包的生成单元;将所述生成的元数据包发送到接收设备的发送单元,其中,所述生成的元数据包包括表示所述多声道音频数据的声道分配标准类型信息的音频声道分配标准类型ACAT字段。
Description
技术领域
本发明涉及数据收发设备和方法,更详细地讲,涉及在有线接口环境中,发送多声道音频信号的数据发送设备、数据接收设备、数据收发系统、数据发送方法、数据接收方法。
背景技术
近来,随着多媒体环境的构建,提出了用于多种数据的传输的有线接口环境。例如,HDMI、MHL规定了多种格式的视频数据、音频信号和控制信号的传输规范。尤其,由于多媒体环境的发展,正积极地讨论用于收发高质量的声音的多声道音频信号传输规范。
迄今为止,已提出了从2声道到8声道的关于音频通道的规范。然而,在多媒体环境中,有必要提出具有9声道以上的音频信号的传输规范。这样的多声道音频信号的传输应考虑迄今一直使用的多种格式和设备环境。
发明内容
本发明是根据上述的需要而提出的,本发明的目的在于提供用于传输9声道以上的音频信号的数据发送设备和数据接收设备、数据收发系统、数据发送方法和数据接收方法。
用于实现上述目的的根据本发明一实施例的数据发送设备,包括:生成单元,生成与多声道音频数据相关的元数据包;发送单元,将所述生成的元数据包发送到数据接收设备,其中,所述生成的元数据包包括表示所述多声道音频数据的声道分配标准类型信息的音频声道分配标准类型ACAT字段。
所述声道分配标准类型可以是与10.2声道、22.2声道、30.2声道、30.2声道以上的多声道以及小于10.2声道的多声道中的至少一个相关的声道分配标准类型。
所述生成的元数据包还可包括表示所述多声道音频数据的声道数的声道计数字段,其中,所述声道计数字段可构成为4比特以上。
所述生成的元数据包还可包括表示所述多声道音频数据的声道和扬声器分配信息的3D声道/扬声器分配字段。
所述生成的元数据包还可包括在所述数据接收设备支持多流音频时,表示与所述多声道音频数据对应的流标识信息的字段以及表示流的总数量的字段中的至少一个字段。
所述多声道音频数据可包括9声道以上的音频信号。
用于实现上述目的的根据本发明一实施例的数据接收设备,包括:接收单元,从数据发送设备接收与多声道音频数据相关的元数据包;包解析单元,解析所述接收的元数据包,其中,所述接收的元数据包包括表示所述多声道音频数据的声道分配标准类型信息的音频声道分配标准类型ACAT字段。
所述声道分配标准类型可以是与10.2声道、22.2声道、30.2声道、30.2声道以上的多声道以及小于10.2声道的多声道中的至少一个相关的声道分配标准类型。
所述接收的元数据包还可包括表示所述多声道音频数据的声道数的声道计数字段,其中,所述声道计数字段可构成为4比特以上。
所述接收的元数据包还可包括表示所述多声道音频数据的声道和扬声器分配信息的3D声道/扬声器分配字段。
所述接收的元数据包还可包括在所述数据接收设备支持多流音频时,表示与所述多声道音频数据对应的流标识信息的字段以及表示流的总数量的字段中的至少一个字段。
所述多声道音频数据可包括9声道以上的音频信号。
用于实现上述目的的根据本发明一实施例的数据收发设备,包括:数据发送装置,生成并发送与多声道音频数据相关的元数据包;数据接收装置,接收并解析所述发送的元数据包,其中,所述生成的元数据包包括表示所述多声道音频数据的声道分配标准类型信息的音频声道分配标准类型ACAT字段。
用于实现上述目的的根据本发明一实施例的数据发送方法,包括如下步骤:生成与多声道音频数据相关的元数据包;将所述生成的元数据包发送到数据接收设备,其中,所述生成的元数据包包括表示所述多声道音频数据的声道分配标准类型信息的音频声道分配标准类型ACAT字段。
所述生成的元数据包还可包括表示所述多声道音频数据的声道数的声道计数字段,其中,所述声道计数字段可构成为4比特以上。
所述接收的元数据包还可包括表示所述多声道音频数据的声道和扬声器分配信息的3D声道/扬声器分配字段。
所述接收的元数据包还可包括在所述数据接收设备支持多流音频时,表示与所述多声道音频数据对应的流标识信息的字段以及表示流的总数量的字段中的至少一个字段。
用于实现上述目的的根据本发明一实施例的数据接收方法,包括如下步骤:从数据发送设备接收与多声道音频数据相关的元数据包;解析所述接收的元数据包,其中,所述接收的元数据包包括表示所述多声道音频数据的声道分配标准类型信息的音频声道分配标准类型ACAT字段。
所述生成的元数据包还可包括表示所述多声道音频数据的声道数的声道计数字段,其中,所述声道计数字段可构成为4比特以上。
所述接收的元数据包还可包括表示所述多声道音频数据的声道和扬声器分配信息的3D声道/扬声器分配字段。
根据以上的本发明的多种实施例,本发明可提供这样的规范:可通过生成包括表示所述多声道音频数据的声道分配标准类型信息的音频声道分配标准类型ACAT字段的元数据包并进行发送和接收,由此可传输9声道以上的音频信号。
附图说明
图1是示出3D音频信号的传输时序的图,
图2是示出根据本发明的实施例的数据收发系统的构成的框图,
图3是示出所述数据收发系统的数据发送设备的构成的框图,
图4是示出所述数据收发系统的数据接收设备的构成的框图,
图5是显示根据本发明的实施例的音频采样包的传输流的图,
图6是显示本发明的另一实施例的音频采样包的传输流的图,
图7是示出本发明的传输流格式的图,
图8是显示根据本发明实施例的音频采样包的传输流的图,
图9和图10是显示根据本发明实施例的多流音频采样包的传输流的图,
图11是根据本发明的实施例的多流音频采样包的传输流的图,
图12是示出使用CEC的扬声器位置信息的传输的示图,
图13是示出3D音频采样从BDP被发送到TV的步骤的示图,
图14是示出多流音频从BDP被发送到TV的步骤的示图,
图15是显示用于3D音频的声道的扬声器布置的图,以及,
图16至图17是根据本发明的各种实施例的数据发送方法、数据接收方法的流程图。
具体实施方式
以下,参照附图详细说明本发明的优选实施例。在说明本发明时,当认为针对相关的公知功能或构造的详细说明会不必要地导致本发明的要点不清楚时,省略其详细说明。此外,下述的术语作为考虑在本发明中的功能而定义的术语,可根据用户、操作者或惯例而不同。因此,应基于整个说明书的内容定义所述术语。
多声道音频表示具有两个以上的音频声道的音频信号。以下,多声道音频被区分为2D音频声道和3D音频声道。2D音频声道具有2声道至8声道之间的音频声道,并表示与各个声道对应的扬声器被布置在平面上的音频声道。相反,3D音频声道是具有9声道以上的音频声道,并且与各个声道对应的扬声器被布置在包括平面的3维空间上。
例如,3D音频使用在TTA(10.2ch)、SMPTE2036-2(22.2ch)或IEC62574(30.2ch)中被定义的声道布局。3D音频包含在本发明中定义的下混音音频流。
多流音频是这样的音频信号,即,所述音频信号包括在能够观看两个以上不同的内容的多视图环境中的与各个视图对应的不同的音频信号。针对各个视图的音频信号可以是多声道音频。例如,在支持如同双视图或四视图的游戏的多视图视频的情况下,多流音频(Multi-Stream Audio)可以是与使用3D视频格式传输的视频流相关的音频流的集合。
本说明书基于32声道(或大于32)的3D音频(3D Audio)和针对多视图显示设备的多流音频,说明针对高速有线接口的音频。尤其,下面说明的更改项是为了支持新的音频特征而包含在内的。
然而,由于在与本发明的技术思想等同的范围中本发明可适用于包含HDMI、MHL规范的多种高速有线接口传输规范,因此本发明的权利要求的范围涉及诸如此类的高速有线接口传输规范。
以下,将包含通过数据岛时间段传输的新的高速有线接口包的定义(3D音频采样包、3D单比特音频采样包、音频元数据包、多流音频采样包和多流单比特音频采样包)、用于所述包的封包处理(Packetization process)、用于支持发现根据新特征的能力的E-EDID内的高速有线接口音频数据块的定义等。因为本说明书将HDMI作为示例进行说明,所以说明书中没有重新定义的规格基本遵循HDMI1.4b,不会基于HDMI1.4b进行修改。
在本说明书中,虽然使用重新记载的内容替代与HDMI1.4b相背的内容,但没有与HDMI1.4b相背的内容和记载的内容均成立。另外,本说明书中重新记载的内容还可适用于与其类似的包含MHL的其它高速有线接口环境。
本说明书参考以下内容。
HDMI,HDMI Licensing(HDMI许可),LLC,“High-Definition MultimediaInterface Specification Version1.4b(高清晰度多媒体接口规范版本1.4b)”,2011年10月11日
TTA,TTAK.KO-07.0098,“Audio Signal Formats for Ultra High Definition(UHD)Digital TV(关于超高清(UHD)数字TV的音频信号格式)”,2011年12月21日
SMPTE,SMPTE2036-2:2008,“UHDTV Audio characteristics and audio channelmapping for program production(UHDTV关于程序产品的音频特性和音频声道映射)”,2008
IEC,IEC62574ed1.0,“Audio,video and multimedia systems General channelassignment of multichannel audio(音频、视频和多媒体系统多声道音频的通用声道分配)”,2011年4月7日
MHL,LLC,"Mobile High-definition Link version2.0(移动高清晰地链接版本2.0)",2012年2月
*TTA:Telecommunications Technology Association(电信技术协会)
概要(Overview)
基本音频功能包括采样率为32kHz、44.1kHz或48kHz的IEC60958的L-PCM音频流。基本音频功能可兼容正常的立体声流。可选择地,可假设能够以达到192kHz的采样率发送具有3至32个音频声道的音频的高速有线接口环境。另外,还可发送具有达到49.152Mbps的比特率的IEC61937压缩格式的音频流(例如,环绕声)。在高速有线接口环境中,可发送单比特音频(One Bit Audio)的2至32个音频声道和被称为DST的压缩形式的单比特音频。另外,可发送扬声器能够位于3D空间的任意位置的3D音频流。3D音频流可包含多达32个音频声道,并在数据岛时间段通过连续的包进行发送。此外,在支持多视图视频流的情况下,还可发送多个音频流(例如,针对每个视图具有多个音频的双视图/四视图游戏的情况)。在这种情况下,可支持四个立体声音频流。
数据岛时间段的包定义(Data Island Packet Definition)
在HDMI1.4b规范的5.3.1节包头(Packet Header)中,使用下表替代表5-8。
表1-包类型
*这样的用于信息帧的包布局参考HDMI1.4b规范的8.2节。
如上述表所示,从0x0B到0x0F的字段定义了新的包。0x0B定义3D音频采样包(3DAudio Sample Packet),0x0C定义了3D单比特音频采样包(3D One Bit Audio SamplePacket)。此外,0x0D定义了音频元数据包(Audio Meta Data Packet),0x0E定义了多流音频采样包(Multi-Stream Audio Sample Packet),0x0F定义了多流单比特音频采样包(Multi-Stream One bit Audio Sample Packet)。在本说明书中详细说明重新定义的包。
然而,本说明书同时也对没有如上所述重新定义包的多种方案进行说明。将上述表的包提议命名为第一实施例。可将多种方案命名为诸如第二实施例、第三实施例、…等。将以多种方案和第一实施例之间的差异为重点说明多种方案。
1-1.3D音频采样包(3D Audio Sample Packet)
第一实施例
在第一实施例中,使用重新定义的3D音频采样包发送L-PCM音频格式的3D音频。如上所述,3D音频被定义为在3D空间中扬声器可按照3D音频规格(例如,10.2ch、22.2ch、30.2ch等)分别被布置在给定的位置的音频。
3D音频流包含多达32个音频声道(或多于32个),并且3D音频流在数据岛时间段通过连续的包被发送。各个包包含多达8个音频声道。包头包含用于指示3D音频采样中的包的位置的采样开始(sample_start)和采样存在比特(sample_present bit)。将稍后描述上述内容。下面的表指示3D音频采样包头。
表2-3D音频采样包头
各个字段包含如下信息。
sample_start:[1比特]若采样开始是1,则表示当前包是3D音频采样的第一包。也就是说,sample_start指示3D音频流的开始。宿端(Sink)通过sample_start识别采样的开始部分。
sample_start=1除了可表示当前3D音频采样包是第一包以外,还可表示当前3D音频采样包被完全封包为8个音频声道。然而,如果发送被下混音为小于8声道的3D音频,则可仅对小于8个的音频声道进行封包。sample_start=0表示当前3D音频采样包是3D音频采样的中间或最后一个包,并表示包含8个或小于8个的音频声道。仅存在针对3D音频采样包的五个有效的sample_present bits的设置。
Sample_present.spX:[4字段,均具有1比特]表示子包X是否包含音频采样。一个3D音频采样数据被包含在多于两个的3D音频采样包中,并且每个3D音频采样包含四个子包。因此,每个3D音频采样包头包含与每个子包对应的总共4个sample_present bit。每个sample_present bit指示与其对应的子包是否包含3D音频采样的一部分。
sample_flat.spX:[4字段,均具有1比特]指示子包X是否表示flatline(平线)采样。sample_present.spX仅在被设置时有效。如果在源中没有可使用的有用的音频数据,则4个sample_flat.spX bit被设置。当存在采样率变化或暂时的流中断(interruption)时,出现上述情况。当sample_flat.spX被设置时,虽然子包X仍表示采样期间,但不包含有用的音频数据。sample_flat.spX bit仅在与其对应的sample_present.spXbit被设置时有效。
相邻的3D音频采样包可被用于发送包含L-PCM音频的9至32声道的一个3D音频采样(也就是说,5至16个IEC60958帧。)。
表3表示有效的Sample_Present Bit值。
表3-用于3D音频传输的有效的Sample_Present Bit配置
B.X:[4字段,均具有1比特]如果子包X包含构成IEC60958块的192个帧中的第一帧,则B.X=1。除此之外,B.X=0。
3D音频采样包包括上述表2中示出的音频采样包头和四个子包。3D音频采样包的各个子包包含被定义为IEC60958的3D音频采样数据。
当源需要3D音频流的下混音(down mix)时,被下混音的音频流也可使用3D音频采样包被发送。如果宿端(Sink)不支持3D音频,则源也可能不发送3D音频采样包。将3D音频转换为遗留音频格式(legacy audio format)超出了本说明书的范围。根据声道数,存在很多彼此不同的子包布局。下面的表4至表6示出分别针对12、24和32声道的3D音频包布局的示例。
表4-针对12声道的3D音频采样包布局的示例
表5-针对24声道的3D音频采样包布局的示例
表6-针对32声道(最大)的3D音频采样包布局的示例
图1是示出3D音频信号的传输时序的图。
在图1中,可获知在水平消隐间隔(horizontal Blanking Interval)发送3个8声道2D音频信号采样。在相同的时间段,24声道的3D音频信号的一个采样被发送。
视频依存性(Video Dependency)
表7示出用于CEA-861-F(也可以是D或E)中说明的为了在多种视频格式时序传输3D音频而可以使用的采样率。这里,假设为了内容保护再同步(content protection re-synchronization)需要水平消隐间隔的58TMDS时钟时间段。可通过3D音频采样包支持3D音频传输。
表7示出用于24比特视频格式时序的3D音频的最大采样频率(示意性的)。
表7-用于视频格式时序的3D音频的最大采样频率
第二实施例
不同于第一实施例,还可考虑使用修改的现有的音频采样包格式(audio samplepacket format)的方案。
如同下面的表8,现有的音频采样包的保留区域可被使用为segment_indicator。在本发明的一实施例中,可使用两个比特表示segment_indicator。segment_indicator=00表示开始包,segment_indicator=01表示中间包中的奇数次包,segment_indicator=10表示中间包中的偶数次包,segment_indicator=11表示最后一个数据包。当然这样的示例仅是一个实施例,并且与比特匹配的包可不同。
通过这样的结构能够获知片段的丢失与否。当片段存在丢失时,则存在丢弃整个包含相应的片段的的“第n个采样”的方案或仅丢弃丢失的音频采样包的方案。这里,片段是指代在一个以上的音频采样包被组合时的构成所述组合的单独的音频采样包的术语。
在HDMI1.4b中,布局(layout)表示关于采样以及声道数据的信息。例如,一个音频采样包可包含2声道音频的4个采样或8声道音频的一个采样。本发明通过对此进行扩充,将layout_ext字段添加到现有的保留区域以连同布局表示关于是否提供3D音频的信息。
例如,与现有的相同,layout_ext=0且layout=0,1表示2D音频采样以及声道数,而layout_ext=1且layout=0表示3D音频采样。layout_ext=1且layout=1还可表示多流音频采样。
除针对第二实施例特别地说明字段以外的字段与第一实施例相同。
表8-修改的音频采样包
表8-1segment_indicator字段
表8-2layout和layout_ext之间的关系:参照HDMI1.4b表7-6
图5是示出所述第二实施例的音频采样包的传输流的图。
在图5中,示出在22.2声道的3D音频的情况下,当在水平消隐间隔(horizontalBlanking Interval)发送两个采样包时,每个字段值的设置。第一包的segment_indicator=00并且第二包的segement_indicator=10,最后一个包的segement_indicator=11。由于所述采样包都是3D音频信号,因此layout_ext=1并且layout=0。在10.2声道的3D音频的情况下,所述采样包也具有类似的字段值。
第三实施例
第三实施例也使用了修改的现有的音频采样包格式(audio sample packetformat),但与第二实施例相比,第三实施例显示简略的信息。
如同下面的表9,音频采样包的保留区域可被使用为multichannel_indicator。与第二实施例的segment_indicator不同,multichannel_indicator仅显示关于音频采样包是不是针对3D音频的信息。layout字段所指示的信息根据multichannel_indicator的比特信息而不同。
因此,可使用一个比特表示multichannel_indicator。当multichannel_indicator=0时,layout(布局)字段指示在现有的HDMI1.4b中定义的声道/采样布局。multichannel_indicator=1指示发送8声道以上的多声道音频采样数据的布局。此时,layout字段被使用为指示实施采样的开始。layout=1表示当前音频采样包包含采样的开始部分。layout(start)=0表示当前音频采样包不包含采样的开始部分。当然这样的示例是一实施例,并且与比特匹配的包可不同。除针对第三实施例特别说明的字段以外的其它字段与第一实施例相同。
表9-修改的音频采样包头
表9-1-Multichannel_indicator和布局/开始(Layout/start)
由于这样的结构能够使现有的音频采样包中的保留区域的变化最小化的同时能够仅通过音频采样包掌握关于是否包含3D音频的信息,因此与第二实施例相比,第三实施例具有包结构简单的优点。
图6是示出上述第三实施例的音频采样包的传输流的图。
在图6中,示出在22.2声道的3D音频的情况下,在水平消隐间隔(horizontalBlanking Interval)中发送两个采样包时的各个字段值的设置。第一包的layout=1并且第二包和第三包的layout=0。然而,由于所有的包均是3D音频信号,因此multichannel_indicator=1。10.2声道的3D音频也具有类似的字段值。
第四实施例
第四实施例同样也使用修改的现有的音频采样包格式(audio sample packetformat),但与第二实施例以及第三实施例相比,还提供关于是否提供多流音频的信息。
如同下面的表10,现有的音频采样包的保留区域可被使用为Stream_ID、multiASP_layout。multiASP_layout具有与第三实施例的multichannel_indicator相同的功能。也就是说,multiASP_layout表示是否提供3D音频。另外,layout字段表示的信息根据multiASP_layout的比特信息而不同。
在多流音频被提供的情况下,Stream_ID表示流编号。在本发明的一实施例中,Stream_ID可使用一个比特,如果Stream_ID是0,则表示第一流,如果Stream_ID是1,则表示第二流。它们分别对应于彼此不同的内容的视图。当然这样的示例是一个实施例,并且与比特匹配的包可不同。
如果多流音频的一个视图具有8声道以下的音频信号,则不存在针对一个音频采样包Stream_ID和multiASP_layout同时为1的情况。
表10-修改的音频采样包头
表10-1-Stream__ID的描述
Stream_ID | 描述 |
0 | 第一流 |
1 | 第二流 |
从可通过一个数据采样包一起表示针对多流音频和3D音频两者的信息的角度来讲,这样的结构具有兼容性的优点。另外,在设置Stream_ID字段和流标识符的情况下,由于在发送多个流的情况下,也可识别多个流中的每个,因此可发送超过一个包的大小的多流音频采样数据。针对第四实施例,除特别说明的字段以外的其它字段也与第一实施例相同。
可考虑基于Stream_ID字段值、multiASP_layout字段值以及layout/start字段值的组合的音频数据传输流。multiASP_layout=1表示音频数据传输流是3D音频的传输流,此时layout/start表示包的开始位置信息。Stream_ID=1表示多流,根据layout/start声道和采样的数量被设置。例如,接收到Stream_ID=1的包的宿端识别为多流音频数据被发送的同时将当前接收的包识别为两个多流音频数据中的第二个流的音频数据。
第五实施例
同样,第五实施例也使用修改的现有的音频采样包格式(audio sample packetformat)。
如下面的表11,现有的音频采样包的保留区域可被使用为Supports_Multistream、multiASP_layout。multiASP_layout具有与第四实施例的multiASP_layout相同的功能。也就是说,表示是否提供3D音频。此外,layout字段指示的信息根据multiASP_layout的比特信息而不同。
Supports_Multistream指示关于是否提供多流音频的信息。在本发明的一实施例中,Supports_Multistream可使用一个比特,如果Supports_Multistream是1,则指示提供多流音频。当然这样的示例是一实施例,与比特匹配的包可不同。
根据第五实施例的音频采样包可在一个音频采样包中一同包含最多4个2声道多流音频采样,基于每个视图的音频采样分别与四个子包对应而被发送。
如果多流音频的一个视图具有8声道以下的音频信号,则对于一个音频采样包不存在Supports_Multistream和multiASP_layout同时是1的情况。
表11-修改的音频采样包头
从可通过一个数据采样包一起表示针对多流音频和3D音频两者的信息的角度来讲,这样的结构具有兼容性的优点。此外,还有可在一个音频采样包中记载所有支持的特征的优点。针对第五实施例,除特别说明的字段以外的其它字段也与第一实施例相同。
可考虑基于Supports_Multistream字段值、multiASP_layout字段值以及layout/start字段值的组合的音频数据传输流的特性。Suppports_Multistream=0且multiASP_layout=1表示3D音频的流,此时layout/start指示包的开始位置信息。Supports_Multistream=1指示多流,声道和采样的数量根据layout/start被设置。
第六实施例
第六实施例提供与第四实施例类似的修改音频采样包格式(audio samplepacket format)的方案。
因此,如同下面的表12,现有的音频采样包的保留区域可被使用为Stream_ID、multiASP_layout。Stream_ID、multiASP_layout分别具有与第四实施例的Stream_ID、multiASP_layout相同的功能。另外,layout字段指示的信息根据multiASP_layout的比特信息而变化。
然而,由于使用2比特表示Stream_ID,因此在多流音频被提供的情况下,Stream_ID可表示4个流编号。各个彼此不同的比特组合对应于针对彼此不同的内容的视图。
如果多流音频的一个视图具有8声道以下的音频信号,则对于一个音频采样包不存在Stream_ID为1以上且multiASP_layout是1的情况。
表12-修改的音频采样包头
表12-1Stream_ID的描述
Stream_ID | 描述 |
00 | 第一流 |
01 | 第二流 |
10 | 第三流 |
11 | 第四流 |
从可通过一个数据采样包一起表示针对多流音频和3D音频两者的信息的角度来讲,这样的结构具有兼容性的优点。尤其,与第四实施例相比,可识别更多数量的多流(multi stream)。针对第六实施例,除特别说明的字段以外的其它字段也与第一实施例相同。
表13表示根据Stream_ID字段值、multiASP_字段值以及layout/start字段值的组合的音频数据传输流的特性。multiASP_layout=1表示3D音频的传输流,此时layout/start表示包的开始位置信息。Stream_ID=01~11表示多流,声道和采样的数量根据layout/start被设置。
表13-构想中的应对提议的特征的特性
第七实施例
第七实施例通过使用在第一实施例中重新定义的3D音频采样包发送3D音频采样包和多流音频采样包。
虽然第七实施例与第一实施例类似,但第七实施例还具有指示是否发送多流的ext_layout字段。也就是说,ext_layout=0意味着发送多流音频,ext_layout=1意味着发送3D音频。
由于其它sample_start字段、sample_present.spX字段和smaple_flat.spX字段与前述的第一实施例相同,因此省略重复的说明。表16表示根据第七实施例的音频采样包结构。
表14-扩展的音频采样包
表15表示根据ext_layout字段值的包的主体结构。如表15所示,在多流的情况下,与一个视图对应的音频信号可构成2声道,因此在一个包中可包含针对4个视图的音频信号。与此不同,在3D音频信号的情况下,针对多个声道的音频信号可被表示。虽然在本发明的前述的多种实施例中说明了32声道,但本发明不限于此,本发明可构成32声道以上的音频信号。
表15-EASP封包
另外,在上述方案中,多流音频信号可被包含在垂直同步消隐间隔中与各个视图的视频数据所处的字段对应的字段中而被发送。图7是示出这种情况下的传输流格式的图。在图7中,可包含与各个视图的视频信号的左侧字段对应的音频信号。
1-2.3D单比特音频采样包(3D One Bit Audio Sample Packet)
第一实施例
在第一实施例中,单比特音频格式的3D音频通过使用重新定义的3D单比特音频采样包被发送。如上所述,3D音频被定义为扬声器可位于3D空间中的任何位置的音频。
3D单比特音频流包含32音频通道(或多于32音频通道),在数据岛期间3D单比特音频流通过连续的包被发送。如同表16,包头包含用于在单比特音频采样中指示包的位置的采样开始(sample_start)和采样存在比特(sample_present bit)。
表16-单比特3D采样包头
sample_start:[1比特]当sample_start=1时,当前包是3D单比特音频采样的第一包。由于sample_start与3D音频包的第一实施例中说明的内容相同,因此省略重复的说明。
samples_present.spX:[4字段,均具有1比特]指示子包X是否包含音频采样。3D单比特音频采样包头中可存在四个samples_present比特,并且各个samples_present比特用于各个子包。如果子包包含音频采样,则对应的比特被设置。samples_present.spX仍与前述的相同。
samples_invalid.spX:[4字段,均具有1比特]指示子包X是否指示无效的采样。当sample_invalid=1时,子包X的采样无效。当sample_invalid=0时,子包X的采样有效。该比特仅在samples_present.spX被设置时有效。如果没有源可用的有用的音频数据,则四个samples_invalid.spX比特被设置。当samples_invalid.spX被设置时,虽然子包X仍表示采样期间,但不包含任何有用的数据。
在3D单比特音频中,采样频率信息(sample frequency information)包含于音频信息帧(audio infoframe)中被传送(参照HDMI1.4b规范8.2.2节)。
3D单比特音频采样包包括表16中存在的单比特音频采样包头和四个子包。各个子包可包含用于至多4个音频声道的单比特音频比特。
相邻的3D单比特音频采样包可被用于在3D单比特音频采样的9至32个音频声道之间的发送。由允许的声道分配确定用于3D单比特音频采样包的samples_present比特的有用的组合。不同于3D音频采样包,3D单比特音频采样包不具有B0~B3字段是因为没有遵循IEC60958块格式。
多种替代方案
另外,针对前述的3D音频采样包(3D Audio Sample Packet)的多种实施例,可定义分别与其对应的3D单比特音频采样包。也就是说,除上述的samples_invalid.spX以外,可将3D单比特音频采样包定义为与3D音频采样包相同,在3D音频采样包中可仅排除B0~B3字段。由于除此之外的内容重复,因此省略详细的说明。
1-3.多流音频采样包(Multi Stream Audio Sample Packet)
以下,对重新提议的多流音频采样包结构进行说明。首先说明第一实施例,并且通过着重说明与第一实施例的差异来说明多种方案。
第一实施例
在第一实施例中,L-PCM和IEC61937压缩音频格式的多个音频流使用多流音频采样包被传输。包含在多流音频采样中的每个音频流包含两个音频声道(还可包含多于两个的音频声道)。由包头的stream_present比特确定子包设置。表17示出多流音频采样包的头结构。
表17-多流音频采样包头
stream_present.spX:[4字段,均具有1个比特]指示子包X是否包含流X的音频采样。多流音频采样包头中存在4个stream_present比特,每个stream_present比特用于子包。stream_present比特指示与其对应的子包是否包含音频流。由于stream_present.spX具有与前述的3D音频采样包的sample_present.spX实质相同的功能,因此省略详细的说明。
stream_flat.spX:[4字段,均具有1个比特]指示子包X是否包含流X的flatline采样。stream_flat.spX仅在被设置时有效。也就是说,如果没有源可用的有用的音频数据,则四个stream_flat.spX比特被设置。当存在采样率变化或暂时的流中断时,出现上述情况。当stream_flat.spX被设置时,虽然子包X仍表示采样期间,但不包含有用的音频数据。由于stream_flat.spX也与前述的3D音频采样包的stream_flat.spX实质相同,因此省略详细的说明。
如果子包X包含组成IEC60958块的192个帧中的第一帧,则B.X=1。否则,B.X=0。
多流音频采样包使用所述表17中示出的包头和四个子包。子包均具有相同的结构。
高速有线接口环境在支持多视图音频流的情况下,允许源同时发送4个音频流。(例如,每个视图具有彼此不同的音频的双视图/四视图游戏)。多流音频采样中包含的每个音频流与单个视图相关并包含两个音频声道。各个多流音频采样包的子包可包含被定义为0或1个的IEC60958的IEC60958或IEC61937的块的帧。3个子包布局被定义。下面的表18-20示出针对2、3、4个音频流的多流音频包布局的示例。
表18-针对2个音频流的多流音频采样包布局的示例
表19-针对3个音频流的多流音频采样包布局的示例
表20-针对4个音频流的多流音频采样包布局的示例
图8是示出上述第一实施例的音频采样包的传输流的图。
从图8可获知,在音频采样包是用于双视图(dual-view)双声道音频采样包的情况下,在水平消隐间隔(horizontal Blanking Interval)可发送包含两个采样的一个采样包。在音频采样包是用于四视图(quad-view)的双声道音频采样包的情况下,在水平消隐间隔(horizontal Blanking Interval)发送包含四个采样的一个采样包。在图8中,虽然将最多双声道的多流音频采样传输作为示例进行说明,但以后还可通过一个多流音频采样包发送具有双声道以上的多声道的多流音频采样。总之,虽然在基于各个视图的音频通过对应的子包被发送的方面相同,但可通过多个顺次的多流音频采样包发送一个具有多声道(双声道以上)的多流音频采样包。
多流音频采样包发送四个立体声(stereo)音频采样。各个采样对应于独立的音频流。例如,如果高速有线接口源发送两个彼此不同的音频流,则子包0可用于发送流0的音频采样,子包1可用于发送流1的音频采样。
第二实施例
第二实施例使用修改的现有的音频采样包格式(audio sample packet format),但还提供针对是否提供多流音频的信息。
如同下面的表21,现有的音频采样包的保留区域可被使用为Stream_Identifier。如果多流音频被提供,则Stream_ID表示流编号。在本发明的一实施例中,Stream_ID可使用两个比特,并且00表示第一流,01表示第二流……。各个Stream_ID对应于针对彼此不同的内容的视图。当然这样的示例是一实施例,与比特匹配的包可不同。
在高速有线接口环境中布局表示针对采样和声道数的信息。例如,一个音频采样包可包含双声道音频4个采样或八声道音频1个采样。
表21-修改的音频采样包头
表21-1-Stream_Identifer的描述
这样的结构具有可利用现有的保留区域简单地提供多流的标识的优点。
图9和图10是示出上述第二实施例的多流音频采样包的传输流的图。
从图9中可获知,在多流音频采样包是用于双视图(dual-view)的双声道采样包的情况下,在水平消隐间隔(horizontal Blanking Interval)发送包含针对相同的内容的四个采样数据的一个采样包。也就是说,一个采样包包含针对一个视图的音频信号。在多流音频采样包是用于四视图(quad-view)双声道音频采样包的情况下,在水平消隐间隔(horizontal Blanking Interval)发送针对四个视图的四个个采样包。此外,如同视图2的实施例,针对某一个视图的采样包可被连续发送,或者,也可与其它视图的采样包交替地被发送。在图9中,虽然将双声道音频采样包作为示例进行说明,但双声道以上的多个声道音频采样包的情况也与前述的示例相同。此外,如图9所示,虽然可基于每个视图发送包含一定数量的采样数据,但还可发送彼此不同数量的采样数据。
在图10中示出在多流音频采样包是用于双视图(dual-view)的八声道采样包的情况下,在水平消隐间隔(horizontal Blanking Interval)发送包含表示八声道的采样数据的两个采样包的情况。通过一个采样包完成针对一个视图的采样数据。针对每个视图采样包可被连续发送,或者,也可与其它视图的采样包交替地被发送。在多流音频采样包是用于四视图(quad-view)八声道音频采样包的情况下,虽然都在水平消隐间隔(horizontalBlanking Interval)发送包含针对一个内容的采样数据的一个采样包,但需要针对四个视图分别发送采样包。
如同第二实施例,在Stream_Identifier被使用情况下,如果音频时钟再生包也包含这样的信息,则可更有效率地进行视频和音频的同步。下面的表是示出在第二实施例的情况下的修改的音频时钟再生包的结构的表。
表22-音频时钟再生包头和子包
表22-1音频时钟再生包头
表22-2音频时钟再生子包
N [20比特]音频时钟再生“N”的值
CTS [20比特]周期(cycle)时间戳
表22-3Stream_Identifer的描述
Stream_Identifer | 描述 |
00 | Stream_1 |
01 | Stream_2 |
10 | Stream_3 |
11 | Stream_4 |
如上述表所示,通过在音频时钟再生包的保留区域中包含针对多流的索引的信息,可有效地执行多视图系统的视频和音频的同步。尤其,在不同时显示多视图的系统中,这样的包结构会有用。
第三实施例
由于第三实施例与3D音频采样包的第四实施例类似,因此第三实施例使用修改的音频采样包格式(audio sample packet format),但具备可提供多流标识信息的功能。
如同下面的表23,现有的音频采样格式的保留区域可被使用为Stream_ID、multiASP_layout。关于Stream_ID、multiASP_layout的内容与在3D音频采样包的第四实施例中说明的内容相同。
表23-修改的音频采样包头
表23-1Stream_Identifer的描述
Stream_Identifer | 描述 |
0 | 第一流 |
1 | 第二流 |
从可通过一个数据采样包一起表示针对多流音频和3D音频的信息的角度来讲,这样的结构具有兼容性的优点。根据Stream_ID字段值、multiASP_layout字段值以及layout/start字段值的组合的音频数据传输流的特性与在3D音频采样包的第四实施例中说明的内容相同。
第四实施例
同样,第四实施例也使用修改的现有的音频采样包格式(audio sample packetformat)。第四实施例与3D音频采样包的第五实施例对应。
如同下面的表24,现有的音频采样包的保留区域可被使用为Supports_Multistream、multiASP_layout。Supports_Multistream、multiASP_layout与在3D音频采样包的第五实施例中说明的内容相同。
表24-修改的音频采样包头
从可通过一个数据采样包一起表示针对多流音频和3D音频的信息的角度来讲,这样的结构具有兼容性的优点。此外,还有可在一个音频采样包中记载所有支持的特征的优点。
可考虑根据Supports_Multistream字段值、multiASP_layout字段值以及layout/start字段值的组合的音频数据传输流的特性。针对每个字段值的内容与前述的3D音频采样包的表13相同。
此外,在上述方案中,在垂直同步消隐间隔,多流音频信号可被包含在与每个视图的视频数据所处的字段对应的字段中并被发送。已在前述的图7中说明了上述方案。
第五实施例
第五实施例提供与第三实施例类似的对现有的音频采样包格式(audio samplepacket format)进行修改的方案。
据此,如同下面的表25,现有的音频采样包的保留区域可被使用为Stream_ID、multiASP_layout。Stream_ID、multiASP_layout分别具有与第三实施例的Stream_ID、multiASP_layout相同的功能。
然而,由于使用2比特表示Stream_ID,因此在多流音频被提供的情况下,可指示4个流编号。各个彼此不同的比特组合与针对彼此不同的内容的视图对应。
如果多流音频的一个视图具有八声道以下的音频信号,则不存在针对一个音频采样包Stream_ID为1以上且multiASP_layout为1的情况。
表25-修改的音频采样包头
表25-1Stream_ID的描述
Stream_ID | 描述 |
00 | 第一流 |
01 | 第二流 |
10 | 第三流 |
11 | 第四流 |
从可通过一个数据采样包一起表示针对多流音频和3D音频的信息的角度来讲,这样的结构具有兼容性的优点。尤其,与第三实施例相比,第五实施例可识别更多数量的多流。
表26示出根据Stream_ID字段值、multiASP_layout字段值以及layout/start字段值的组合的音频数据传输流的特性。multiASP_layout=1表示3D音频的传输流,此时layout/start表示包的开始位置信息。Stream_ID=01~11表示多流,并且声道和采样的数量根据layout/start被设置。
表26-构想中的应对提议的特征的特性
第六实施例
第六实施例是将Stream_ID添加到根据第一实施例的音频采样包的方案。Stream_ID与上面描述的内容相同,并且针对其它字段的内容与在第一实施例中说明的内容相同。表27示出根据第六实施例的音频采样包头。然而,虽然在下表中Stream_ID被设置为4比特,但Stream_ID还可被设置为1~3比特或5比特以上。在此,包类型(Packet Type)表示重新定义的包类型。
由于为了识别基于各个流的音频而使用Stream_ID,因此,不同于第一实施例,在一个多流音频采样包中将包含针对一个流的音频采样数据。
表27-扩展音频采样包
第七实施例
第七实施例使用在1.1的第一实施例中重新定义的3D音频采样包示出3D音频采样包和多流音频采样包。
虽然第七实施例类似于第一实施例,但第七实施例还具有指示是否发送多流的ext_layout字段。也就是说,ext_layout=0意味着发送多流音频,ext_layout=1意味着发送3D音频。
由于其它sample_start字段、sample_present.spX字段和sample_flat.spX字段与前述的第一实施例相同,因此省略重复的说明。表28示出根据第七实施例的音频采样包结构。
表28-扩展的音频采样包
表29示出根据ext_layout字段值的包的主体结构。如表29所示,在多流的情况下,与一个视图对应的音频信号可构成2声道,因此在一个包中可包含针对4个视图的音频信号。与此不同,在3D音频信号的情况下,针对多个声道的音频信号可被表示。虽然在本说明书中记载的本发明的多种实施例中说明了32声道,但本发明不限于此,本发明还可应用于32声道以上的音频信号。
表29-EASP封包
表30示出有效的Sample_Present比特值。
表30-用于多音频流传输的有效的Sample_Present比特配置。
图11是示出上述第七实施例的多流音频采样包的传输流。
从图11可获知,在多流音频采样包是用于双视图(dual-view)双声道音频采样包的情况下,在水平消隐间隔(horizontal Blanking Interval)可发送包含针对两个视图的采样的一个采样包。在多流音频采样包是用于四视图(quad-view)的双声道音频采样包的情况下,在水平消隐间隔(horizontal Blanking Interval)发送包含四个采样的一个采样包。也就是说,发送包含针对四个视图的采样的一个采样包。在图11中,虽然将双声道音频采样包作为示例进行说明,但双声道以上的多个声道音频采样包的情况也是一样的。
在上述多种实施例中,在垂直同步消隐间隔,多流音频信号可被包含在与每个视图的视频数据所处的区域对应的区域中并被发送。上述的图7是示出这种情况的传输流格式的图。在图7中,与每个视图的视频信号的左侧区域对应的音频信号可被包含。
1.4多流单比特音频包(Multi-Stream One Bit Audio Packet)
第一实施例
可定义用于多流单比特音频的新的包。所述新的包对应于3D音频采样包。
如果发送多流单比特音频,则各个子包可包含用于0、1、2个(或多于两个)音频通道的单比特音频比特。多流单比特音频采样包包含四个stream_present比特,并分别用于子包。
如果子包包含基于每个单独的流的音频采样,则与其对应的比特被设置。在不存在源可用的有用的音频数据的情况下,四个stream_invalid.spX比特被设置。当stream_invalid.spX被设置时,虽然子包X仍表示采样期间,但不包含任何有用的数据。
表31-多流单比特音频包头
stream_present.spX:[4字段,均具有1个比特]指示子包X是否包含流X的音频采样。由于stream_present.spX具有与前述的3D音频采样包的sample_present.spX实质相同的功能,因此省略详细的说明。
stream_invalid.spX:[4字段,均具有1个比特]指示子包X是否表示流X的无效的采样。在包含在子包X中的采样无效的情况下,Stream_invalid=1。在相反的情况下,Stream_invalid=0。仅在相关的stream_present.spX被设定的情况下,该比特才有效。由于stream_present.spX具有与前述的3D音频采样包的sample_present.spX实质相同的功能,因此省略详细的说明。
参考针对多流单比特音频,将采样频率信息包含在音频信息帧中并发送的特点(参照HDMI1.4b的8.2.2节)。
多流单比特音频采样包使用与表31示出的单比特音频采样子包相同的四个子包。不同于多流音频采样包,单比特多流音频采样包不具有B0~B3字段是因为没有遵循IEC60958块格式。
多种替代方案
此外,可针对前述的多流音频采样包的多种实施例定义分别与其对应的单比特多流音频采样包。也就是说,可将除上述的samlpes_invalid.spX以外的其它字段定义为与多流音频采样包相同,并且在多流音频采样包中可仅排除B0~B3字段。由于除此以外的内容重复,因此省略详细的说明。
2.1.用于3D音频的信息帧(Infoframe for3D Audio)/元数据包
第一实施例
如上所述,在第一实施例中,作为信息帧的替代的与3D音频相关的附加信息可使用重新定义的音频元数据包被发送。当3D音频流被发送时,源针对至少两个视频字段发送一次音频元数据。
音频元数据包含声道数量、音频声道分配标准类型(ACAT:Audio ChannelAllocation Standard Type)和3D音频流的声道/扬声器分配。下面的表指示重新定义的音频元数据包的头。
表32-音频元数据包头
表33-音频元数据包内容
可如下地对上述包的各个字段进行定义。
3D_CC:[5比特]指示被发送的3D音频的声道计数。当音频信息帧中存在音频声道计数(CC0……CC2)与音频元数据包的3D音频声道计数(3D_CC0……3D_CC4)不一致时,忽略音频信息帧的声道计数。表34示出根据3D_CC值的音频声道。
ACAT:[4比特]指示由源提供的音频声道分配标准类型。下面的表35表示ACAT字段的值。在ACAT被设置为0x01(10.2声道)的情况下,表36说明扬声器的位置分配。类似地,表37和表38分别包含用于22.2声道和30.2声道的信息。
3D_CA:[8比特]指示用于3D音频的声道/扬声器分配。在表36-38中示出了详细的内容。对于IEC61937压缩音频流来说,3D_CA字段无效。
表34-3D_CC字段
表35-音频通道分配标准类型字段
表36-针对10.2声道的3D_CA字段(ACAT=0x01)
表37-针对22.2声道的3D_CA字段(ACAT=0x02)
表38-针对30.2声道的3D_CA字段(ACAT=0x03)
主动式(active)3D音频流被发送的情况下,正确的音频元数据包总是在两个视频字段中至少被发送一次。在存在新的3D音频流的开始或可由音频元数据包和音频信息帧表示的3D音频流中包含变化的情况下,被修改的且正确的音频元数据包会不晚于根据第一个受影响的非无声(non-silent)音频采样的一个视频帧被发送。这刚好会在受影响的第一个音频采样被发送以前发生。对于3D单比特音频流来说,音频元数据可在第一个受影响的采样之前被发送。音频元数据包传输可在数据岛期间中的包含水平消隐间隔或垂直消隐间隔的任何时间被发送。如果3D音频被流传输,则宿端忽略包含在音频信息帧中的CC字段和CA字段而参照音频元数据中包含的3D_CC和3D_CA。
然而,在传输前述的音频元数据的情况下,也仍使用现有的音频信息帧(AudioInfo Frame)。也就是说,在重新使用音频元数据以用于针对3D音频的声道分配的情况下,使用音频信息帧以用于针对2D音频的声道分配。
此外,虽然在上述实施例中以10.2声道、22.2声道、30.2声道说明了上述声道分配标准类型(ACAT),但本发明的技术思想还适用于具有数量小于10.2声道、30.2声道以上以及具有10.2声道和30.2声道之间的数量的声道的情况。
此外,虽然上述表中未示出,但在支持多流音频的情况下,元数据包还可包含指示与多声道音频数据对应的流标识信息的字段以及指示整个流数量的字段中的至少一个。
以下,说明根据上述第一实施例的数据收发系统1000。
图2是示出根据本发明的一实施例的数据收发系统1000的构成的框图,图3是示出所述数据收发系统1000的数据发送设备100的构成的框图,图4是示出所述数据收发系统1000的数据接收设备200的构成的框图。
如图2所示,根据本发明的一实施例的数据收发系统1000包含数据发送设备100和数据接收设备200。
如图3所示,根据本发明的一实施例的数据发送设备100包含包生成单元110和发送单元120。
包生成单元110是生成与多声道音频数据有关的元数据包的构成要素。生成的元数据包可包含指示所述多声道音频数据的声道分配标准类型信息的ACAT(Audio ChannelAllocation Standard Type)字段。
传输单元120将所述生成的元数据包发送到数据接收设备。
所述数据发送设备100生成的元数据包与上述第一实施例中说明的元数据包相同。
如图4中所示,根据本发明的一实施例的数据接收设备200包含接收单元210和包解析单元220。
接收单元210从数据发送设备接收与多声道音频数据有关的元数据包。所述接收的元数据包可包含指示所述多声道音频数据的声道分配标准类型的ACAT(Audio ChannelAllocation Standard Type)字段。
包解析单元220对所述接收的元数据包进行解析。
所述数据接收设备200接收的元数据包与上述第一实施例中说明的元数据包相同。
第二实施例
不同于第一实施例,可考虑修改在现有的高速有线接口规范中定义的音频信息帧(Audio Infoframe)的方案。表39表示这种情况下的音频信息帧结构。CC字段指示被发送的音频的声道计数,CA字段表示声道/扬声器分配信息(Channel/Speaker allocation)。
虽然使用3个比特表示现有的CC字段,但第二实施例额外还使用保留区域的2个比特来表示CC字段。也就是说,使用五个比特CC0、CC1、CC2、CC3、CC4来表示声道计数信息。
此外,将声道/扬声器分配信息添加到CEA861-D,表20的保留区域。不同于第一实施例,第二实施例不包含ACAT字段。
表39-修改的音频信息帧
表39-1修改的音频信息帧包头
表39-2音频信息帧包内容
第三实施例
第三实施例对第二实施例进行扩展并修改在现有的高速有线接口规范中定义的音频信息帧(Audio Infoframe)。表40表示这种情况下的音频信息帧结构。如同第二实施例,CC字段指示被发送的音频的声道计数,CA字段表示声道/扬声器分配信息(Channel/Speaker allocation)。
虽然第三实施例基本类似于第二实施例,但第三实施例提供进一步扩展CA字段的方案。将保留区域中的一个比特设置为channel_extension比特,并且当channel_extension=0时,原样使用CEA861-D中定义的CC#和CA#字段。也就是说,支持2D音频模式。相反,当channel_extension=1时,PB2[7:6]被使用为扩展比特(CC4,CC3),PB6的保留区域被使用为CA_ext字段。用于3D音频的扩展比特被使用。
在这种情况下,如同第二实施例,虽然使用3个比特表示CC字段,但第二实施例还使用保留区域的两个比特。也就是说,使用五个比特CC0、CC1、CC2、CC3、CC4来表示声道计数信息。
而且,可通过将PB6字段添加到现有的CA比特(PB4)来使用现有的CA比特。将用于10.2声道以上的音频的声道/扬声器分配信息的定义添加到CEA861-D,Table20(或CEA861-E,Table28)的保留区域。按照各个规范还可单独地定义表。作为结果,由于CA字段被扩展为16比特,因此多声道音频传输变为可能。
然而,不同于上述方法,还可通过替换现有的CA字段而定义8比特大小的字段来使用。例如,可通过使用PB6字段或PB7字段来定义新的CA比特。
表40-修改的音频信息帧2
表40-1音频信息帧包头
表40-2音频信息帧包内容
第四实施例
第四实施例是将第二实施例和第三实施例适当地组合的方案。
在第四实施例中,现有的音频信息帧包含3D_CH_present字段、PB4的CA字段、PB6的3D_CC字段。
3D_CH_present字段执行与第三实施例中的channel_extension相同的功能。也就是说,如果3D_CH_present=0,则原样使用CEA861-D中定义的CC#和CA#字段。也就是说,支持2D音频模式。相反,如果3D_CH_present=1,则将PB6[4:0]使用为CC的扩展比特(CC4,CC3,CC2,CC1,CC0),并如同第二实施例将PB4的保留区域使用为CA字段。用于3D音频的扩展比特被使用。如同第二实施例和第二实施例,ACAT字段没有被定义。其它没有特别说明的内容与前述的第一至第三实施例相同。
表41-修改的音频信息帧3
表41-1音频信息帧包头
表41-2音频信息帧包内容
2.2用于多流音频的信息帧(Infoframe for Multi stream Audio)
在多流音频的情况下,不定义新的元数据包,并使用现有的高速有线接口规范中规定的信息帧。如果多个主动式音频流使用多流音频采样包被发送,则每两个视频字段中至少发送一次正确的音频信息帧。此时,音频信息帧可被用于记录所有主动式音频流的音频特性。
如果可由新的音频流的开始和根据多个新的音频流或音频信息帧表示的音频流中存在任何变化,则修改的正确的音频信息帧可不晚于跟随受影响的第一个非无声(non-silent)音频采样的一个视频字段被发送。这刚好会在受影响的第一个音频采样被发送以前出现。针对单比特音频流,音频信息可在第一个受影响的采样之前被发送。
信息帧的修改
不同于上述实施例,在使用stream_ID的实施例(3D音频采样包的第四、第六实施例、多流音频采样包的第二、第三、第五、第六实施例)的情况下,如同下面的表42,可将stream_ID包含在音频信息帧中。
在表42中,Stream_ID表示当前音频信息帧的流标识,Stream_Count表示被发送的整个音频流的数量。在上述实施例的情况下,不使用流标识符,作为替代而使用通过将采样添加到构成多流音频采样包的主体(body)的四个子包中发送的方式,不修改信息帧。
表42-修改的信息帧
表42-1音频信息帧包头
表42-2音频信息包内容
3.1.用于3D音频的EDID(扩展显示标识数据)
可通过使用如下方法将针对3D音频的音频特性和扬声器分配信息添加到EDID:(1)修改现有的短音频描述符(Short Audio Descriptors)和扬声器分配数据块;(2)在扩展标签代码(Extended Tag Codes)中,在为与音频相关的块保留(Reserved for audio-related blocks)的字段定义为新的数据块;(3)在扩展标签代码中,在HDMI音频数据块的保留区域定义为新的(一个)数据块。
例如,在CEA-861-F(D或E也可)中记录的EDID数据块可被用于一起表示宿端音频特性和扬声器分配支持。宿端音频特性和扬声器分配支持在CEA扩展的数据块收集中所处的一系列短音频描述符(Short Audio Descriptors)中被表示。这样的数据包含由宿端支持的音频编码列表和与所述各种编码分别相关的参数(诸如,支持编码格式的声道数量)。扬声器分配描述符(Speaker Allocation Descriptor)可包含在数据块收集(Data BlockCollection)中,并且支持用于2D音频的多声道(多达8声道)L-PCM或多声道(多达8声道)的单比特音频的宿端需要所述扬声器分配描述符。
第一实施例
然而,在本发明中,如果宿端支持多流音频和/或3D音频传输,则具有扩展标记代码18(Extended Tag Code18)的HDMI音频数据块(High Speed Cable Interface AudioData Block)可被用于表示3D音频特性、3D扬声器分配信息、多流音频特性。
如果宿端支持3D音频传输,则HDMI音频数据块包含具有4字节的一个以上的HDMI3D音频描述符(HDMI_3D_AD)。而且,HDMI音频数据块可包含跟随最后一个HDMI3D音频描述符的一个HDMI3D扬声器分配描述符(HDMI_3D_SAD)。
如果宿端支持多流音频传输但不支持3D音频传输,则HDMI音频数据块可包含3字节的一个以上的CEA短音频描述符(CEA_SAD)。CEA-861-F(D或E也可)中出现CEA短音频描述符。
如果宿端支持多流音频传输和3D音频传输,则HDMI音频数据块包含基于HDMI3D扬声器分配描述符的一个以上的CEA短音频描述符。详细的内容参照表43。
上述HDMI3D音频描述符表示针对在CEA-861-F(D或E也可)中定义的音频编码的支持。高速有线接口设备可支持基于TTA(10.2声道)、SMPTE2036-2(22.2声道)或IEC62574(30.2声道)的3D音频格式。表45至表49记录了详细的内容。这些表根据CEA-861-F(D或E也可)的表24和表26中提供音频格式代码被分类。
如上所述,HDMI3D扬声器分配描述符还可被包含在HDMI音频数据块中,并且支持3D音频的宿端可能需要所述HDMI3D扬声器分配描述符。表50示出了HDMI3D扬声器分配描述符的结构。宿端通过表现出扬声器(即,一对扬声器)来显示音频能力,并设置与其对应的标记。HDMI3D扬声器分配描述符可包含4比特ACAT字段,并且所述4比特ACAT字段表示音频通道分配规范的类型。在表50-52中,记录了详细的内容。CEA短音频描述符(CEA Short AudioDescriptors)还可包含在HDMI音频数据块中,并且支持多流音频传输的宿端会需要所述CEA短音频描述符。这样的描述符记录各个音频流的音频特性。虽然针对各个音频流最大声道计数被限制为双声道,但根据实施例最大声道计数还可大于双声道。
表43-HDMI音频数据块
*随后的数据块有效负荷的长度(字节长度),2+4×X+4+3×Y
**3+4×X+1
对上述表43中示出的HDMI音频书块的各个字段的说明如下:
NUM_HDMI_3D_AD[3比特]:表示HDMI3D音频描述符的数量。
NUM_CEA_SAD[3比特]:表示CEA短音频描述符(CEA Short Audio Descriptors)的数量。
Max_Stream_Count-1[2比特]:表示传输流中的非1的数量。参照表44。
HDMI_3D_AD:HDMI3D音频描述符(HDMI3D音频描述符)
HDMI_3D_SAD:HDMI3D扬声器分配描述符(HDMI3D Speaker AllocationDescriptor)
CEA_SAD:CEA短音频描述符(CEA Short Audio Descriptor)
表44-Max_Stream_Count-1字段
表45-针对音频格式代码=1的HDMI3D音频描述符(LPCM)
表46-针对音频格式代码2至8的HDMI3D音频描述符
表47-针对音频格式代码9至13的HDMI3D音频描述符
表48-针对音频格式代码14的HDMI3D音频描述符(WMA Pro)
表49-针对音频格式代码15的HDMI3D音频描述符(扩展)
表50-针对10.2声道的HDMI3D扬声器分配描述符(TTA标准)
在上述表中有阴影的比特是与10.2声道相关的指定的扬声器。
表51-针对22.2声道的HDMI3D扬声器分配描述符(SMPTE2036-2)
在上述表中有阴影的比特是与22.2声道相关的指定的扬声器。
表52-针对30.2声道的HDMI3D扬声器分配描述符(IEC62574/Ed.1)
在上述表中有阴影的比特是与30.2声道相关的指定的扬声器。
在第一实施例中,虽然使用3字节记录多声道3D音频数据的扬声器分配,但这仅是示例。在30.2声道以上的3D音频数据的情况下,可能需要更多的扬声器分配信息,在这种情况下,3D扬声器分配描述符使用4字节以上的字节来表示扬声器分配。
表53-音频通道分配类型(ACAT)字段
此外,根据制造商可通过将ACAT字段的剩余比特值分配给多种声道类型(例如,Dolby(杜比)、USC或将被标准化的ITU-R的格式等)来所述剩余比特值。
第二实施例
不同于第一实施例,第二实施例修改音频数据块。尤其,CEA短音频描述符的保留区域可被使用为扩展最大声道数据(Max Number of channel)。例如,如下面的表54所示,可利用字节1[7]和字节2[7]进行扩展。通过上述处理,可表示3D音频。CEA短音频描述符可根据音频格式具有不同的字段。
表54-CEA短音频描述符
表54-1针对音频代码=1(LPCM)的CEA短音频描述符
表54-2针对音频代码2至8的CEA短音频描述符
表54-3针对音频代码9至15的CEA短音频描述符
可独立于第二实施例而通过修改扬声器分配数据块来设定ACAT。可通过利用作为扬声器分配数据块有效负荷的保留区域的字节3[7:4]来识别ACAT,并可使用专门的新的表来定义基于各个类型的扬声器分配数据块。ACAT字段的位置还可被定义在字节2[7:3]~字节3[7:0]中的其它位置。
如同下面示出的表55,ACAT=0001可表示TTA标准的10.2声道,ACAT=0010可表示22.2声道。
表55-扬声器分配数据块有效负荷
然而,可根据制造商不同地定义扬声器的分配数据块。在这种情况下,根据制造商,可考虑通过灵活地应用通用的扬声器布置来提高兼容性。在22.2声道的3D音频的情况下,下面的表表示SMPTE2036-2标准。具有阴影的比特对应于多个制造商的通用的扬声器配置。
表56-扬声器分配数据块有效负荷2
然而,在上述的扬声器分配数据块有效负荷的实施例中,可不特别地定义ACAT字段,可在源通过查看扬声器分配数据块有效负荷中设置的比特的位置和种类来直接判断各个类型(例如,10.2声道(TTA)、22.2声道(SMPTE2036-2)、13.1声道(杜比)等)。这是因为可通过音频数据块获知声道的数量。
第三实施例
第三实施例可不在HDMI音频数据块中重新定义,而在EDID的扩展标记代码重新定义“扩展扬声器分配数据块”类型。新的数据块的大小可最多为32字节。在表57中,将4字节的情况作为示例进行说明。当然,ACAT的大小的字段也可根据需要被改变并确定。
通过保留区域(字段3[7:4])识别ACAT,定义根据各个类型的扬声器分配数据块。有效负荷的构成可与前述的实施例相同。当然ACAT字段也可位于前述的保留区域以外的其它字段。
ACAT的剩余字段值可根据制造商被分配给多种声道类型(例如,杜比、USC或将被标准化的ITU-R的格式等)并使用。
表57-修改的扬声器分配数据块
扩展标记代码 | 数据块的类型 |
0 | 视频特性数据块 |
1 | 供应商特定视频数据块 |
2 | 为VESA视频显示装置信息数据块保留 |
3 | 为VESA视频数据块保留 |
4 | 为HDMI视频数据块保留 |
5 | 色度(colorimetry)数据块 |
6…15 | 为与视频相关的块保留 |
16 | CEA混杂(miscellaneous)音频字段 |
17 | 供应商特定音频数据块 |
18 | 为HDMI音频数据块保留 |
19 | 扩展扬声器分配数据块 |
20…31 | 为与音频相关的块保留 |
32…255 | 为一般用途保留 |
表57-1ACAT描述
表57-2扩展扬声器分配数据块净负荷(用于10.2声道)
表57-3扩展扬声器分配数据块净负荷(用于22.2声道)
表57-4扩展扬声器分配数据块净负荷(用于30.2声道)
第四实施例
虽然第四实施例类似于第三实施例,但区别在于在定义基于各个扬声器分配标准类型(例如,10.2声道(TTA)、22.2声道(NHK)、13.1声道(杜比)等)的数据块之后,分别将基于各个类型的数据块添加到扩展标记代码(extended tag code)中。
例如,数据块标记代码19可表示用于TTA10.2声道的扬声器分配数据块,数据块标记代码20可表示用于NHK22.2声道的扬声器分配数据块,数据块标记代码21可表示用于杜比13.1声道的扬声器分配数据块。
表58-修改的扬声器分配数据块
扩展标记代码 | 数据块的类型 |
0 | 视频特性数据块 |
1 | 供应商特定视频数据块 |
2 | 为VESA视频显示装置信息数据块保留 |
3 | 为VESA视频数据块保留 |
4 | 为HDMI视频数据块保留 |
5 | 色度(colorimetry)数据块 |
6…15 | 为与视频相关块保留 |
16 | CEA混杂(miscellaneous)音频字段 |
17 | 供应商特定音频数据块 |
18 | 为HDMI音频数据块保留 |
19 | 用于10.2声道(TTA)的HDMI扬声器分配数据块 |
20 | 用于22.2声道(NHK)的HDMI扬声器分配数据块 |
21 | 用于13.1声道(杜比)的HDMI扬声器分配数据块 |
22…31 | 为与音频相关的块保留 |
32…255 | 为一般用途保留 |
表58-1扬声器分配数据块净负荷(用于多声道)
第五实施例
第五实施例定义扩展音频数据块(Extended Audio Data Block)。扩展音频块对应于扩展标记代码的值。此外,扩展音频数据块包含一个以上的扩展CEA短音频描述符(Extension CEA Short Audio Descriptor)。各个扩展CEA短音频描述符包含关于声道数的信息。此时,虽然各个字段的大小或格式与音频数据块的短音频描述符相同,但各个字段的大小或格式也可被定义为不同于音频数据块的短音频描述符。
表59-扩展音频数据块
扩展标记代码 | 数据块的类型 |
0 | 视频特性数据块 |
1 | 供应商特定视频数据块 |
2 | 为VESA视频显示装置信息数据块保留 |
3 | 为VESA视频数据块保留 |
4 | 为HDMI视频数据块保留 |
5 | 色度(colorimetry)数据块 |
6…15 | 为与视频相关的块保留 |
16 | CEA混杂(miscellaneous)音频字段 |
17 | 供应商特定音频数据块 |
18 | 为HDMI音频数据块保留 |
19 | 扩展音频数据块(包括一个或多个扩展短音频描述符) |
20 | 扩展扬声器分配数据块 |
21 | 多音频流数据块 |
22…31 | 为与音频相关的块保留 |
32…255 | 为一般用途保留 |
表59-1扩展音频数据块
表59-2扩展CEA短音频描述符
如上述表所示,扩展CEA短音频描述符可包含未压缩音频格式代码。未压缩音频格式代码可被定义为如下。
表60-未压缩的音频格式代码
此时,扩展扬声器分配数据块(Extended Speaker Allocation Data Block)可被定义为扩展标记代码的值。如同下表,扩展扬声器分配数据块可包含ACAT字段。保留区域可被使用于扩展。或者,剩余的比特值可根据制造商被分配给多种声道类型(例如,杜比、USC或将被标准化的ITU-R的格式等)并被使用。
表61-扩展扬声器分配数据块
扩展标记代码 | 数据块的类型 |
0 | 视频特性数据块 |
1 | 供应商特定视频数据块 |
2 | 为VESA视频显示装置信息数据块保留 |
3 | 为VESA视频数据块保留 |
4 | 为HDMI视频数据块保留 |
5 | 色度(colorimetry)数据块 |
6…15 | 为与视频相关的块保留 |
16 | CEA混杂(miscellaneous)音频字段 |
17 | 供应商特定音频数据块 |
18 | 为HDMI音频数据块保留 |
19 | 扩展音频数据块(包括一个或多个扩展短音频描述符) |
20 | 扩展扬声器分配数据块 |
21 | 多音频流数据块 |
22…31 | 为与音频相关的块保留 |
32…255 | 为一般用途保留 |
表61-1扩展扬声器分配数据块
表61-2ACAT描述
在此实施例中,扩展扬声器分配数据块的有效负荷如下表所示。阴影区域被使用为各个声道分配类型的扬声器分配。
表62-声道分配兼容性
关于新的扬声器位置的EDID/CEC(EDID/CEC for new Speaker
Position)
在本发明中,可定义用于将新的扬声器位置信息传送给源的扬声器位置数据块(Speaker Position Data Block)。数据块包含与宿端连接的所有扬声器的被布置的坐标值(x,y,z)的布置角度值。源可将这样的信息灵活地应用于下混音或对象音频编码(ObjectAudio Coding)等多种处理中。由于下面的表的扩展标记代码(Extended Tag Code)的值是一实施例,因此扬声器位置数据块可与上面定义的多个数据块一起被定义和使用。
表63-扬声器位置数据块
扩展标记代码 | 数据块的类型 |
0 | 视频特性数据块 |
1 | 供应商特定视频数据块 |
2 | 为VESA视频显示装置信息数据块保留 |
3 | 为VESA视频数据块保留 |
4 | 为HDMI视频数据块保留 |
5 | 色度(colorimetry)数据块 |
6…15 | 为与视频相关的块保留 |
16 | CEA混杂(miscellaneous)音频字段 |
17 | 供应商特定音频数据块 |
18 | 为HDMI音频数据块保留 |
19 | 为与音频相关的块保留 |
20 | 扬声器位置数据块1 |
21 | 扬声器位置数据块2 |
22 | 扬声器位置数据块3 |
23 | 扬声器位置数据块4 |
… | … |
31 | 为与音频相关的块保留 |
32…255 | 为一般用途保留 |
扬声器位置数据块(Speaker Position Data Block)可如同下表被定义。字节[1]~[5]存储针对一个扬声器的位置信息。通过相同的方法,字节[6]~[30]存储扬声器位置信息。字节31、32被定义为保留区域。
当使用示例的方法时,由于一个数据块仅可传达最多6个针对扬声器的位置信息,因此需要数量为(N/6)向上取整的数量的扬声器位置数据块以应对N声道的情况。
表64-扬声器位置数据块
表64-1Speaker_id字段
Speaker_id | 描述 |
00000 | FL |
00001 | FR |
00010~11111 | … |
利用CEC的扬声器位置信息的传输
图12是示出利用CEC的扬声器位置信息的传输的示图。
如图12所示,如果源向宿端请求扬声器位置,则宿端通知针对扬声器位置的信息。
3.1.用于多流音频的EDID(用于3D音频的EDID)
可在扩展标记代码定义用于多流音频的新的数据块(Multi Stream Audio DataBlock)。多流音频数据块包含Max_stream_count-1字段、CEA短音频描述符字段。Max_stream_count-1表示被传输的流的数量。存在一个以上的CEA短音频描述符,并且可根据CEA861-D定义所述CEA短音频描述符。
表65-多流音频数据块
表65-1CEA数据块标记代码
扩展标记代码 | 数据块的类型 |
0 | 视频特性数据块 |
1 | 供应商特定视频数据块 |
2 | 为VESA视频显示装置信息数据块保留 |
3 | 为VESA视频数据块保留 |
4 | 为HDMI视频数据块保留 |
5 | 色度(colorimetry)数据块 |
6…15 | 为与视频相关的块保留 |
16 | CEA混杂(miscellaneous)音频字段 |
17 | 供应商特定音频数据块 |
18 | 为HDMI音频数据块保留 |
19… | 为与音频相关的块保留 |
XX | 多音频流数据块 |
…31 | 为与音频相关的块保留 |
32…255 | 为一般用途保留 |
此外,供应商特定数据块可包括关于是否提供多流视频/音频的指示。上述处理使用multistream_indicator字段。如果宿端支持多流,则multistream_indicator=1。然而,multistream_indicator字段不仅可在HDMIVSDB中被定义,还可在数据块的其它字段中被定义。
表66-供应商特定数据块
如果使用两个以上的比特定义multistream_indicator,则可识别多种多流。
表67-供应商特定数据块
第二实施例
第二实施例通过利用扩展标记代码重新定义了多音频流数块(Multi AudioStream Data Block)。被重新定义的多音频流数据块包含CEA短音频描述符字段、音频流的长度、Max_stream_count字段等。由于针对各个字段的描述与上述其它实施例相同,因此省略重复的说明。
表68-多音频流数据块
扩展标记代码 | 数据块的类型 |
0 | 视频特性数据块 |
1 | 供应商特定视频数据块 |
2 | 为VESA视频显示装置信息数据块保留 |
3 | 为VESA视频数据块保留 |
4 | 为HDMI视频数据块保留 |
5 | 色度(colorimetry)数据块 |
6…15 | 为与视频相关的块保留 |
16 | CEA混杂(miscellaneous)音频字段 |
17 | 供应商特定音频数据块 |
18 | 为HDMI音频数据块保留 |
19 | 扩展音频数据块(包括一个或多个扩展短音频描述符) |
20 | 扩展扬声器分配数据块 |
21 | 多音频流数据块 |
22…31 | 为与音频相关的块保留 |
32…255 | 为一般用途保留 |
表68-1多音频流数据块
第三实施例
此外,类似于第一实施例,可考虑使用HDMI音频数据块的其它方法。
重新定义扩展标记代码。如同第一实施例,可将标记代码18使用于扩展HDMI音频数据块的添加。
下面的表示出扩展HDMI音频数据块(Extended HDMI Audio Data Block)的结构。根据第三实施例的扩展音频数据块包含扩展CEA短音频描述符(ECSAD:Extended CEAShort Audio Descriptor)、扩展扬声器分配描述符(ESAD:Extended Speaker AllocationDescri ptor)和多音频流描述符(MASD:Multiple Audio Stream Descriptor)。
如果宿端装置支持3D音频功能,则扩展CEA短音频描述符包含多达Num_ECSAD字段的值的描述符。如果宿端装置支持3D音频声道功能,当Num_ECSAD字段的值大于0时,扩展扬声器分配描述符包含一个描述符。如果宿端装置支持多流音频功能,多音频流描述符包含多达Num_ECSAD字段的值的描述符。
Max Stream_Count-1字段被定义为宿端装置能够接收的最多流数量减1。由于使用一个音频采样包(Audio Sample Packet)传输多流音频,因此针对各个视图的音频流具有诸如相同的编码类型(coding type)以及采样频率(sampling frequency)等的相同的音频特性。
Num_MASD字段定义扩展CEA短音频描述符的数量。至多可包含7个。Num_MASD字段为0意味着不支持3D音频功能。
Num_ECSAD字段定义该数据块中包含的多流音频描述符的数量。至多可包含4个。Num_ECSAD字段为0意味着不支持多流音频,如果Max Stream_Count-1不为0,则必须定义至少一个MASD。如果ECSAD以使用4字节定义的方法构成,则可至多定义6个。
表69-扩展HDMI音频数据块
X:ECSAD的数量
Y:MASD的数量
表69-1Max Stream Count-1字段
Max Stream Count-1 | 描述 |
00 | 不支持多音频流 |
01 | 两个音频流 |
10 | 三个音频流 |
11 | 四个音频流 |
上述第三实施例可考虑如下的修改的替代方案。
例如,可考虑扩展HDMI音频数据块仅包含ECSAD并使用其它扩展标记代码定义剩余两种ESAD、MASD的方法。
此时,利用其它扩展标记代码定义的两个描述符可被定义为单独的一个数据块或彼此不同的数据块。在上述表中,在PB3被定义的字段中Max Stream_count-1包含在多流音频描述符被定义的数据块中。
不同于上述情况,扩展HDMI音频数据块可包含与3D音频有关的ECSAD和ESAD,并且可使用其它扩展标记代码定义MASD。
参照下面的表,说明ECSAD的结构。
如左下角的表所示,当前该描述符仅可选择LPCM和DSD这两个编码类型。然而,可利用UAFC字段的保留区域额外包含其它未压缩音频格式。
声道的数量被分配有5比特,因此最多可选择32个声道。
表70-扩展CEA短音频描述符
表70-1扩展HDMI音频数据块结构
表70-2未压缩的音频格式代码字段
表70-3扩展CEA短音频描述符
然而,针对上述方法,也可考虑如下的替代方案。
下面的表将描述符的整体大小扩展为4字节。此外,音频格式代码参照了CEA861-E中定义的表。因此,所述音频格式代码均可指示CEA861-E中定义的压缩/未压缩编码类型。
通过增大描述符的大小,数据块内可包含的扩展CEA短音频描述符(ECSAD)的数量被限制为最多6个描述符。然而,前述的实施例中可至多包含4个描述符。
PB3、PB4的语法根据各个音频格式代码类型的变化,以与CEA861-E的表45~49的字节2、3相同的形式被定义。
表71-扩展CEA短音频描述符
表71-1扩展HDMI音频数据块结构
表71-2扩展CEA短音频描述符
在第三实施例中说明ESAD的结构。
ESAD当前可选择最多30.2声道的扬声器分配信息。然而,可利用ACAT区域的保留区域额外包含其它扬声器布置格式(speaker placement format)。
表72-扩展扬声器分配描述符
表72-1扩展HDMI音频块结构
表72-2音频声道分配类型字段
表72-3扩展扬声器分配描述符
下面的表是ESAD。各个表的阴影部分被使用为声道分配类型的扬声器分配。
表73-扩展扬声器分配描述符
以下,说明第三实施例的ESAD的结构。
原样使用CEA861-E中定义的CEA短音频描述符。然而,包含CEA短音频描述符中包含的各个字段的同时,可定义将现有的字段的布置或大小的部分修改/变更的新的格式。仅在传输多流音频时包含该描述符,并且当该描述符被使用时,包含至少一个描述符。
表74-多音频流描述符
表74-1扩展HDMI音频数据块结构
表74-2多音频流描述符
下面的表重新定义了多流音频描述符的结构。在此,使用新的描述符,而不会原样使用CEA短音频描述符。
多流音频的声道数量限制为2个。因此,在描述符中删除不需要的声道计数字段(channel count field),作为替代,将Max Number of Stream-1定义为2比特。此时,扩展HDMI音频数据块(Extended HDMI Audio Data Block PB3)中被定义的Max_Stream_Count-1被定义为各个描述符的Max_Stream_Count-1中的最大值。
各个表表示基于各个音频格式代码的描述符。
表75-多音频流描述符
表75-1用于音频格式代码1(LPCM)的多音频流描述符
表75-2用于音频格式代码2至8的多音频流描述符
表75-3用于音频格式代码9至13的多音频流描述符
表75-4用于音频格式代码14(WMA Pro)的多音频流描述符
表75-5用于音频格式代码15的多音频流描述符(扩展)
4.1用于3D音频和多流音频的应用场景(示例性的(informative))
以下提供用于根据上述第一实施例的3D音频和多流音频的应用场景。这样的示例显示出HDMI2.0源和用于3D音频和多流音频的传输的宿端装置的能力。
用于3D音频的场景
图13是示出3D音频采样如何从BDP被发送到TV的图。这样的示例作如下的假设。
源(例如,BDP)和宿端(例如,TV)均是高速有线接口设备。
源将L-PCM48kHz22.2声道音频流发送到宿端。
宿端可接收L-PCM48kHz22.2声道音频流,并将所述音频流发送到与各个单独的音频流相关的扬声器。被发送的视频格式是1080p/60Hz。
TV包含可通过DDC访问的CEA-861-F(D或E也可)兼容的(compliant)E-EDID数据结构。用于支持3D音频传输的E-EDID连同其它必需的数据块包含HDMI音频数据块。BDP接收HDMI音频数据块并识别在表76中记录的TV的3D音频能力。
表76-用于22.2声道的HDMI音频数据块的示例
字节1、2和3表示HDMI音频数据块的头。N UM_HDMI_3D_AD被设置为1表示支持3D音频传输。因为在次应用场景中BDP不处理多流音频,所以NUM_CEA_SAD和Max_Stream_Count-1被设置为0。
字节4、5、6和7构成用于记录TV的3D音频特性的HDMI3D音频描述符。音频格式代码、最大声道数量-1、采样频率和采样大小被定义。
字节8、9、10、11构成用于记录22.2声道(SMPTE2036-2)的主动式扬声器的HDMI3D扬声器分配描述符。
BDP从TV接收EDID之后,将音频信息帧和音频元数据包发送到TV。在这种情况下,声道计数(Channel Count)和声道/扬声器分配信息使用音频元数据包而不是音频信息帧被发送。
包含在音频元数据包中的3D_CC和3D_CA记录声道计数并分别记录用于22.2声道音频流的声道/扬声器分配信息。表77表示用于22.2声道音频传输的音频信息帧有效负荷的示例。表78示出用于22.2声道音频传输的音频元数据包有效负荷。
表77-用于22.2声道的音频信息帧有效负荷的示例
表78-音频元数据包有效负荷
BDP通过3D音频采样包发送22.2声道音频采样。各个3D音频采样包支持多达8声道,因此为了发送22.2声道音频采样需要3个连续的3D音频采样包。sample_start用于指示第一个3D音频采样包。在此示例中,3个3D音频采样包可如同表79至表81被定义。
表79-用于22.2声道的第一3D音频采样包的示例
表80-用于22.2声道的第二3D音频采样包的示例
表81-用于22.2声道的第三3D音频采样包的示例
4.2用于多流音频的场景示例
图14是示出多流音频如何从BDP被发送到TV的图。做出如下假设。
源(例如,BDP)和宿端(例如,TV)均是高速有线接口设备。
源/宿端进入双视图游戏模式。
源发送针对各个视图的两个音频流。
宿端可将两个音频流发送到两个彼此不同的耳机(headphone)。
被发送的视频格式是例如,HDMI3D1080p/60Hz。
TV包含可通过DDC可访问的CEA-861-F(D或E也可)兼容的(compliant)E-EDID数据结构。为了支持多流音频,E-EDID可连同其它必需的数据块包含HDMI音频数据块。BDP接收HDMI音频数据块并识别在表76中记录的TV的多流音频能力。
表82-用于两个音频流的HDMI音频数据块的示例
字节1、2和3表示HDMI音频数据块的头。NUM_CEA_SAD被设置为2是因为宿端支持用于多流音频的两种音频格式代码。Max_Stream_Count-1被设定为1是因为宿端可处理上述两种独立的音频流。NUM_HDMI_3D_A被设定为0是因为在此场景中BDP不处理3D音频传输。
字节4、5和6构成用于记录音频特性的第一个CEA短音频描述符。在多流音频传输的情况下,最多声道计数被限制为2。因此,Max Number of channels-1为1。
字节7、8和9构成用于记录音频特性的第二个CEA短音频描述符。如上所述,MaxNumber of channels-1为1。BDP从TV接收EDID之后,会将音频信息帧发送到TV。与3D音频传输场景相反,CC和CA用于分别传输声道计数和声道扬声器分配信息(Channel/SpeakerAllocation information)。也就是说,在多流音频传输中音频元数据包不被使用。表83示出用于传输两个音频流的音频信息帧有效负荷的示例。
表83-用于两个音频流的音频信息帧有效负荷的示例
BDP发送包含用于两个独立的音频流的立体声音频采样的多流音频采样包。也就是说,第一个子包包含来自第一个音频流的立体声音频采样,第二个子包包含来自第二个音频流的立体声音频采样。在此示例中,多流音频采样包被定义为如同表84所示。
表84-用于两个音频流的多流音频采样包的示例
3D音频扬声器替代和声道分配(示例性的)
以下,提供用于3D音频传输的扬声器替代和声道分配信息。
图15是示出用于3D音频的声道的扬声器布置的图。
在表85中记载的示例中,在IEC的30.2声道标准类型的情况下,缩写的含义分别如下:FL表示左前侧扬声器;FR表示右前侧扬声器;LFF表示低频音效1(Low Freq uencyEffect1)扬声器;FC表示前面中央(Front Center)扬声器;BL表示左后侧扬声器;BR表示右后侧扬声器;FLW左前侧宽(Front Left Wide)扬声器;FRW表示右前侧宽(F ront RightWide)扬声器;TpFL表示上部左前侧(Top Front Left)扬声器、TpFR表示上部右前侧(TopFront Right)扬声器;BC表示后面中央(Back Center)扬声器;LS表示左侧环绕(LeftSurround)扬声器;RS右侧环绕(Left Surround)扬声器;LFE2表示低频音效2(LowFrequency Effect2)扬声器;FLC表示左前侧中央(Front Left Center)扬声器;FRC表示右前侧中央(Front Left Center)扬声器;TpFC表示上部前面中央(Top Front Center)扬声器;TpC表示上部中央(Top Center)扬声器;SiL表示左侧(Side Lef t)扬声器;SiR表示右侧(Side Right)扬声器;TpBL表示上部后面左侧(Top Back Left)扬声器;TpBR表示上部后面右侧(Top Back Right)扬声器;TpSiL表示上部左侧(Top Side Left)扬声器;TpSiR表示上部右侧(Top Side Right)扬声器;BtFC表示底部前面中央(Bottom Front Center)扬声器;BtFL表示底部前面左侧(Bottom Front Left)扬声器;BtFR表示底部前面右侧(BottomFront Right)扬声器;TpBC表示上部后面中央(Top Back Center)扬声器;TpLS表示上部左侧环绕(Top Left Surround)扬声器;TpRS表示上部右侧环绕(Top Right Surround)扬声器;LSd表示左侧环绕直接(Left Surround Direct)扬声器;RSd表示右侧环绕直接(RightSurround Direct)扬声器。
然而,根据规格的种类,扬声器的名称可不同,例如,对于前面中央扬声器来讲,虽然在IEC规范中标记为FC,但在TTA规范中可标记为C。此外,除如下表所示的名称以外可存在多种扬声器名称。也就是说,下面的表和图15中示出的内容仅是一实施例,扬声器和声道分配可构成为与下面的表和图15中示出的内容不同。
然而,支持多声道的3D音频数据不同于2D数据,基于三维空间的上部、中央部、下部分别具备彼此不同的扬声器的共同的特性。图15描述了这样的扬声器的空间布置的示例。
表85-音频通道描述和缩写比较(CEA/TTA/SMPTE/IEC)
5.数据发送方法、数据接收方法
以下,参照图16至图17说明遵循上述规范的数据发送方法、数据接收方法。
图16至图17是根据本发明的多种实施例的数据发送方法、数据接收方法的流成图。
首先参照图16,根据本发明的多种实施例的数据发送方法包括:生成与多声道音频数据相关的元数据包的步骤(S1610)以及将所述生成的元数据包发送到数据接收设备的步骤(S1620)。此时,所述生成的元数据包包含表示所述多声道音频数据的声道分配标准类型信息的ACAT字段。
由于已在2.1节的第一实施例中针对各个步骤进行了描述,因此省略重复的说明。
参照图17,根据本发明的多种实施例的数据接收方法包括:从数据发送设备接收与多声道音频数据相关的元数据包的步骤(S1710)以及解析所述接收的元数据包的步骤(S1720)。此时,所述接收的元数据包包含表示所述多声道音频数据的声道分配标准类型的ACAT字段。
由于已在2.1节的第一实施例中针对各个步骤进行了描述,因此省略重复的说明。
6.多音频
在高速有线接口环境中,可支持多音频。多音频环境表示针对一个内容支持多个音频的环境。例如,当两名用户使用一个相同的画面游戏时,各个用户需要接收彼此不同的音频。以下,说明如上所述的在支持多音频时的宿端装置和源装置之间的传输包结构。
6.1.音频采样包修改(Audio Sample Packet)方案
第一实施例
如下表所示,可灵活使用多流音频采样包结构。
表86-多流音频采样包
虽然使用多流ASP结构,但在头中重新定义用于通知针对各个视图的多音频的传送的“MS_Layout”字段。定义为使子包的布置结构根据所述MS_Layout字段值变得不同。在传输多音频的结构中,通过信息帧、音频元数据包或重新定义的音频描述包(AudioDescription Packet)传输针对各个音频流的附加信息。剩余字段的定义与现有定义的多流ASP中记录的内容相同。
下表表示MS_Layout值。
表87-MS_Layout
*对于双视图来说,针对左眼(内容1)的音频数据通过子包0、1被传输,针对右眼(内容2)的音频数据通过子包2、3被传输。每个音频数据可通过一个多流ASP最多传输两个采样。
**针对单视图的多音频通过子包0~3被传输。多流ASP可仅传输针对单个视图的音频数据。例如,在3D视频的情况下,仅传输针对左眼的音频信号。针对单个视图,可传输最多4个多音频数据。
***对于双视图多音频来说,针对左眼(内容1)的音频数据可通过子包0、1被传输。子包0、1具有两个彼此不同的音频流。例如,一个流包含韩语音频数据,另一流包含英语音频流。
然而,上述实施例仅是一实施例,可扩展用于表示音频数据的子包的数量。此外,子包的顺序也可构成为不同于上述情形。
第二实施例
第二实施例是与多流ASP不同而如下表所示地定义新的ASP并仅使用为多音频的用途的方案。
表88-多音频音频采样包
第二实施例与多流ASP不同地定义新的包,并且所述新的包被使用于传输针对各个视图的多音频数据。然而,在3D视频格式的情况下,无法使用新的包,仅在单个视频被传输的情况下才可以使用新的数据包。各个子包中的每一个子包可发送一种音频流的采样数据,各个子包中的每一个子包发送彼此不同种类的音频流。在这种情况下,针对单个视频,可同时传输最多四个音频流采样数据。针对各个音频流的附加信息通过信息帧、音频元数据包或(重新定义)的音频描述包被传输。
第三实施例
如下表所示,第三实施例是应用定义音频流标识符字段(Audio streamIdentifier field:AS_ID)的多流ASP结构的方案。
表89-多音频音频采样包
各个ASP仅发送一种音频流采样数据。在双视图的情况下,一个ASP发送针对一个内容(左或右)的音频数据。在四视图的情况下,一个ASP发送与左奇数次视图(内容)、左偶数次视图(内容)、右奇数次视图(内容)或右偶数次视图(内容)中的任意一种视图(内容)相关的音频流。
在针对各个视图传输多音频的情况下,一个ASP发送与左视图(或右视图)相关的一个以上的音频流中的与AS_ID相应的音频流的采样数据。可通过信息帧、音频元数据包或(重新定义的)音频描述包获知表示各个ASP中发送的音频流是哪一视图的哪一种音频流的附加信息。
作为针对此方案的另一种方案,还存在通过将彼此不同的包类型分配给针对多流音频和各个单个视图的多音频ASP来不同地进行定义的方法。此时,虽然两个ASP结构可彼此相同或在部分字段中存在差异,但必需包含“AS_ID”字段。
第四实施例
第四实施例是第三实施例的改进方案,如下表所示,AS_ID使用两个级别区分ID。也就是说,使用AS_Major_ID和AS_Minor_ID来区分AS_ID并进行定义。
表90-多音频音频采样包
AS_Major_ID是识别多流音频的ID,AS_Minor_ID是识别针对各个视图的多音频的ID。AS_Major_ID是更高级别的ID,并且每个AS_Major_ID的各个值都被定义为AS_Minor_ID。
下面的表记录了根据各个ID的各个值的意义。
表91-AS_Major_ID字段和AS_Minor_ID字段
作为针对该方案的替代方案,可能会存在通过将彼此不同的包类型分配给多流音频和针对各个视图的多音频ASP来专门地进行定义的方法。此时,虽然两个ASP结构可彼此相同或在部分字段中存在差异,但必需包含“AS_Major_ID”字段和“AS_Minor_ID”字段。
6.2.信令数据修改方案-1
第一实施例
如下表所示,第一实施例中,在音频元数据包中包含指示是否传输多流音频的字段(MS_Audio_Type)、指示是否传输针对各个视图的多音频数据的字段(Aux_Audio)以及一个以上的音频/视频映射信息(A V Mapping Descriptor)。
表92-音频元数据包头
表93-音频元数据包内容
如已说明的那样,MS_Audio_Type指示是否传输多流音频。字段值如下表所示。
表94-MS_Audio_Type字段
MS_Audio_Type | 描述 |
0 | 0 | 保留 |
0 | 1 | 发送用于双视图的两个音频流 |
1 | 0 | 发送用于三视图的三个音频流 |
1 | 1 | 发送用于四视图的四个音频流 |
也就是说,描述为:当字段值为01时,传输用于双视图的两个音频流,当字段值为10时,传输用于三视图的三个音频流,在四视图情况下,传输四个音频流。
在所述音频元数据包中,Aux_Audio的字段值为1意味着在任何一个视图中传输两个以上的音频流。该字段的值为0意味着所有的视图仅传输一个音频流。
Num_AV_Mapping_Descriptor指示在该字段所属的字节之后将被记录的AV映射描述符的数量。
AV映射描述符包含表示各个音频流包含针对视频的哪个视图的音频数据的信息。依次记录的AV映射描述符依照顺序对应于音频流ID(或子包编号)。也就是说,如果ASP使用音频流ID,则第一个AV映射描述符是针对通过音频流ID值为0的ASP传输的音频流的描述符。通过类似的方法,如果ASP使用以子包为单位识别多流音频的结构,则第一个AV映射描述符是针对通过子包0传输的音频流的信息。AV映射描述符的详细结构如下。
表95-AV映射描述符
PB(X) | 保留(0) | 保留(0) | 保留(0) | 保留(0) | RE | LE | R0 | L0 |
LO被设定为1的音频流表示左视图(双视图的第一内容)或左奇数次(四视图的第一内容)视图的音频数据。
RO被设定为1的音频流表示右视图(双视图的第二内容)或右奇数次视图(四视图的第三内容)的音频数据。
LE被设定为1的音频流表示左偶数次视图(四视图的第二内容)的音频数据。(在双视图的情况下,该字段被设定为0)。
RE被设定为1的音频流表示右偶数次视图(四视图的第四内容)的音频数据。(在双视图的情况下,该字段被设定为0)。
第二实施例
虽然第二实施例类似于第一实施例,但在音频元数据包中定义MS_Audio_Type字段、Aux_Audio字段、Num_AV_Mapping_Descriptor字段以及3D_Audio字段。
表96-音频元数据包头
表97-音频元数据包内容
3D_Audio指示是否将3D音频从源传输到宿端。当3D_Audio字段值被设定为1时,音频元数据包的PB0~PB2被包含。相反,当3D_Audio字段值被设定为0时,省略PB0~PB2。剩余字段的定义与第一实施例相同。
第三实施例
虽然第三实施例与第二实施例类似,但定义音频元数据描述符而不是AV映射描述符,该描述符包含用于针对多流和各个视图的多音频的AV映射信息和音频特性信息(例如,声道计数、采样频率、声道/扬声器分配、级别偏移值(Level Shift Value)、下混音抑制、LFE重放级别信息)。
表98-音频元数据包头
表99-音频元数据包内容
表100-音频元数据描述符
PB(X+0)中定义的各个字段RE、LE、RO、LO以在第二实施例中定义的意义被使用。
PB(X+1)~PB(X+3)中定义的各个字段与CEA-861-F规范的音频信息中定义的字段相同地被使用。
作为第三实施例的替代方案可考虑如下的方法。
-音频元数据包的结构保持为第二实施例的形态。
-在音频信息帧的头或有效负荷字节中的保留区域中添加音频流ID。而且,还使多达音频流的数量的音频信息帧被传输。也就是说,该方法为,在第三实施例的音频元数据描述符PB(X+1)~PB(X+3)中定义的字段是引入了音频信息帧中存在的字段,而替代这些字段,通过在音频信息帧中包含音频流ID,由此发送多个音频信息帧。
第四实施例
第四实施例虽然与第三实施例类似,但第四实施例是通过在音频元数据包的头中包含AS_Major_ID而取代了MS_Audio_Type,是一个音频元数据包仅包含针对一个视图(内容)的信令信息的方案。根据该方案,在传输四视图的情况下,四个音频元数据包应被传输,并且各个包可通过AS_Major_ID被识别。
表101-音频元数据包头
表102-音频元数据包内容
在该方案中,包含在有效负荷中的音频元数据描述符包含与一个视图相关的多音频的特性信息。因此,不同于第三实施例中定义的音频元数据描述符,不需要包含LO字段、RO字段、LE字段、RE字段的第一字节。
此时,依次布置的音频元数据描述符表示按顺序与AS_Minor_ID相应的描述符。也就是说,第一语音元数据描述符表示AS_Minor_ID为0的音频流的描述符。通过相同的方式,第二音频元数据描述符表示AS_Minor_ID为1的音频流的描述符。
如上,与隐含地反映AS_Minor_ID的方案相反,还可考虑明示地在各个音频元数据的描述符的第一字节中包含具有1比特或大于1比特的大小的AS_Minor_ID字段。例如,如果要将音频元数据描述符和包含2比特大小的AS_Minor_ID字段的ASP一起使用,则应给将在音频元数据描述符中定义的AS_Minor_ID分配2比特而进行定义。
第4-1实施例
音频元数据描述符也可以如下表所示地定义。此时,PB(X+0)~PB(X+2)中定义的各个字段被使用为CEA-861-F规范的音频信息帧中定义的字段的意义。
表103-音频元数据描述符
第4-2实施例
如下表所示,也可与第4-1实施例不同地通过包含AS_Minor_ID来定义音频元数据描述符。此时,PB(X+0)~PB(X+2)中定义的各个字段被使用为CEA-861-F规范的音频信息帧中定义的字段的意义。
表104-音频元数据描述符
不需要将单独的字节分配给AS_Minor_ID字段,还具有在方案4-1结构中存在的保留区域中定义的方案。
此外,还存在将AS_Minor_ID字段的大小定义为大于2比特或小于2比特的方案。此时,有必要以与定义AS_Minor_ID字段的其它包(多流音频采样包、音频时钟再生包等)相同的比特大小进行定义。
作为第四实施例的替代方案还有如下的方法。
音频信息帧的头或有效负荷字节中的保留区域中添加AS_Major_ID和AS_Minor_ID。此外,使多达音频流的数量的音频信息帧被传输。该方法为,音频元数据描述符PB(X+1)~PB(X+3)中定义的字段是引入了音频信息帧中存在的字段,而替代这些字段,通过在音频信息帧中包含AS_Major_ID和AS_Minor_ID,由此发送多个音频信息帧。
6.3.信令数据修改方案-2
定义了包含记录各个音频流中包含的数据的特性(例如,语言类型、标题、补充等)的信息的音频描述包。
第一实施例
如下表所示,包含记录各个音频流中包含的音频数据的特性(例如,语言类型、标题、补充等)的信息。
表105-音频描述包头
音频流ID是用于区分各个视图以及基于各个视图被传输的音频流的标示符字段,并且该字段还被定义在多流音频采样包和音频元数据包中。该字段值彼此相同的包在相同的音频流传输中被使用。
由于EXD_Present(扩展描述符存在)没有在Audio_Inform ation_Descriptors_Present中被定义,因此当需要扩展描述符时,该字段值被设定为1。此时,音频描述包有效负荷的第一字节被定义为Extended_Audio_Information_Descriptors_Present字段。
Extended_Audio_Information_Descriptors_Present是根据各个比特的设定确定是否包含特定描述符的字段。包含如下的下级字段。
表106-Audio_Information_Descriptors_Present
MLD、PSD、PD和CAD分别指示是否包含多语言描述符、主要/补充描述符、可听位置描述符和内容咨询描述符(Content Advisory Descriptor)。以下,描述各个描述符的详细结构。被保留的比特是为了指示是否包含以后将添加的描述符而被分配的区间。
表107-MLD(多语言描述符)
可通过ISO639规范中定义的语言代码记录在音频流中使用的语言的种类。然而,并不排除根据其它规范的语言代码。
表108-PSD(主要-补充描述符)
PB(X+0) | PS | PS_Type |
PS字段为1表示主要音频,PS字段为0表示补充音频。
PS_Type字段的值为1表示主要音频的类型,PS_Type字段的值为0表示补充音频的类型。
表109-PS被设置为1时的PS_Type(主要音频)
PS-Type | 描述 |
00x00~0x7E | 保留(将被确定) |
0x7F | 扩展PS_Type字段 |
当PS_Type的字段值为0x00~0x7E时,各个字段值表示主要音频的类型。此外,当PS_Type的字段值为0x7F时,PSD如下所示被扩展为2字节,并且第二字节被使用为Extended_PS_Type field。
表110-PS_Type被设置为0x7F时的PSD(主要-补充描述符)
当需要PS_Type的扩展时,如果PS_Type的值被设定0x7F,则Extended_PS_Type字段被添加。
当PS的字段值被设定为0时,PS_Type用作指示补充音频的类型的字段。表示PS_Type的字段值的内容如下表所示。
表111-PS被设置为0(补充音频)时的P S_Type字段
PS_Type | 描述 |
0x00 | 用于描述性的视频的音频流(针对视觉障碍) |
0x01 | 转移至高频段的音频流(针对听力障碍) |
0x02 | 转移至低频段的音频流(针对听力障碍) |
0x03 | 在高频段放大的音频流(针对听力障碍) |
0x04 | 在低频段放大的音频流(针对听力障碍) |
0x05~0x07E | 保留(将被确定) |
0x07F | 扩展PS_Type字段 |
当PS_Type的值为0x7F时,Extended_PS_Type字段被添加,并且具体的方法与上面的段落中说明的方法相同。
表112-APD(可听位置描述符)
PB(X+0) | Audible_Location | 位置 |
表113-Audible_Location字段
Audible_Location | 描述 |
0x00 | 体育场 |
0x01 | 室内体育场 |
0x02 | 音乐厅 |
0x03~0x0F | 保留(将被确定) |
位置字段是指示被指定为Audible_Location的场所中的音频源的位置的值。
表114-位置字段。
位置 | 描述 |
0x00 | 1(最近) |
0x01 | 2 |
0x02 | 3 |
.. | … |
0x0F | 16(最远) |
此时,可存在很多种表示位置的方法。可使用数字(1、2、3…)表示从视频输出的位置至音频源距离多远的程度。作为另一种方法,通过根据Audible_Location表示位置值(Position value),由此可定义为表示特定位置。例如,当Audible_Location是体育场时,可进行如下定义:位置是0x00表示转播席,位置是0x01表示内野席,0x02表示外野席。
使用表示音频流的收听等级的描述符如下地定义CAD(内容咨询描述符)。
表115-CAD(内容咨询描述符)
PB(X+0) | Rating_type(4比特) | Rating_value(4比特) |
Rating_type是表示基于国家和内容的等级标准类型的字段。Rating_value表示根据Rating_type的标准而定的各个等级的类型。
CAD不仅可被使用为包含针对音频流等级信息的目的,还可被使用为包含针对视频流的等级信息的目的。为了实现上述目的,额外需要修改或新定义传输CAD的包。例如,可存在这样的方法:通过与当前包含CAD的音频描述包独立地重新定义视频描述包来包含具有与CAD相同的信息的描述符。作为另一种方法,还存在通过将音频描述包再定义为AV描述包,来包含针对音频/视频流内容的描述信息的方法。
当重新定义视频描述包时,至少应包含如下的信息。
1)可连接视频描述包和与其相关的视频流(视图)的ID信息。
2)可连接视频描述包和与其相关的音频流的ID信息。该ID可具有与第一实施例中定义的ID相同的值,或着可分配专门的ID值。
3)为了在有效负荷中记录一个以上的多种描述符,包含描述符的数量标记、包含的描述符的类型标记、头或有效负荷的扩展标记。
4)多种描述符可通过定义与视频内容(诸如,各个视频内容的种类、在多视图的情况下的各个视图的位置信息、用于实感媒体的信息)相关的多种信息来包含所述多种信息。
表116-Rating_type字段
表117-Rating_value字段
Rating_type | 0x00 | 0x01 | 0x02 | … |
0x00 | G | TV-Y | EC | … |
0x01 | PG | TY-Y7 | E | … |
0x02 | PG-13 | TV-Y7-FV | T | … |
0x03 | R | TV-G | M | … |
0x04 | NC-17 | TV-PG | AO | … |
.. | … | |||
0x0F |
表示CAD的另一种替代方案如下。
表118-Country_Code,Rating_Type,Rating_Value
PB(X+0) | Country_Code |
PB(X+1) | Rating_Type |
PB(X+2) | Rating_Value |
这是通过单独地分离Country_Code来进行定义的方法。存在通过将1字节或更多的字节分配给Country_Code字段来进行定义的方法。此外,还存在如下表所示地定义该字段的方法或根据ISO3166规范使用3字节表示该字段的方法。
表119-Country_Code字段
Rating-Type | 描述 |
0x00 | ABW(阿鲁巴岛) |
0x01 | AFG(阿富汗) |
… | … |
0xXX | KOR(韩国) |
… | … |
0xYY | USA(美国) |
… | … |
0xFF | ZWE(津巴布韦) |
表120-Rating_Type字段
Rating_type | 描述 |
0x00 | 电影 |
0x01 | TV |
0x02 | 视频游戏 |
… | … |
0xFF | 保留(将被确定) |
表121-Rating_value字段(如果Country_Code被设置为0xYY(美国))
6.4.EDID修改方案
在EDID中,添加指示宿端的是否支持针对单个视图的多音频的标记。所述标记可被包含在HDMI音频数据块、VSIF(LLC或论坛(Forum))等中,或者可被包含在重新定义的数据块中。
6.5.多视图字段定义
在供应商特定信息帧和供应商特定数据块中添加用于记录双视图/三视图/四视图或更多的多视图的支持信息的字段。
第一实施例
第一实施例在供应商特定信息帧的PB5字段添加用于记录双视图/三视图/四视图或更多的多视图的支持信息的3D_MultiView字段。
表122-供应商特定信息帧包内容
3D_MultiView字段指示以3D格式被传输的视频数据是3D模式(HDMI1.4b以前的传输形式)的数据还是多视图(双视图/三视图/四视图)的数据。基于该字段值表示的内容如下表所示。
表123-3D_MultiView字段
此外,还可通过将该字段的大小定义为3比特以上,来将该字段修改为可表示多于四视图的多视图。在这种情况下,上述表也可被扩展。
第二实施例
第二实施例添加用于在供应商特定信息帧的PB7区域记录双视图/三视图/四视图或更多的多视图的支持信息的3D_MultiView字段。
表124-供应商特定信息帧包内容
第二实施例与第一实施例相同地添加3D_MultiView。然而,被添加的位置存在差异。具体地将,在PB7的结构中的比特[5:4]中定义3D_MultiView。
此外,如下表所示,还可在供应商特定数据块中进行定义。
表125-供应商特定数据块
多视图字段表示宿端装置的多视图能力。针对字段值的描述如下表所示。
而且,所述字段的大小可被定义为3比特以上,并可修改为表示四视图以上的多视图。在这种情况下,下面的表应被扩展。
表126-多视图字段
以上,虽然示出和说明了本发明的优选实施例,但本发明不限于上述特定实施例,在不脱离权利要求请求的本发明的要旨的情况下,可由本发明所属的技术领域的具有通常知识的技术人员进行多种改变,并且不可与本发明的技术思想或前景分离地理解这些改变。
Claims (15)
1.一种数据发送设备,包括:
生成单元,生成与多声道音频数据相关的元数据包;
发送单元,将所述生成的元数据包发送到数据接收设备,
其中,所述生成的元数据包包括表示所述多声道音频数据的声道分配标准类型信息的音频声道分配标准类型ACAT字段,
其特征在于,所述声道分配标准类型信息指示10.2声道与30.2声道之间的扬声器位置分配。
2.如权利要求1所述的数据发送设备,其特征在于,所述声道分配标准类型是与10.2声道、22.2声道、30.2声道、30.2声道以上的多声道以及小于10.2声道的多声道中的至少一个相关的声道分配标准类型。
3.如权利要求1所述的数据发送设备,其特征在于,生成的所述元数据包还包括表示所述多声道音频数据的声道数的声道计数字段,其中,所述声道计数字段构成为4比特以上。
4.如权利要求1所述的数据发送设备,其特征在于,生成的所述元数据包还包括表示所述多声道音频数据的声道和扬声器分配信息的3D声道/扬声器分配字段。
5.如权利要求1所述的数据发送设备,其特征在于,生成的所述元数据包还包括在所述数据接收设备支持多流音频时,表示与所述多声道音频数据对应的流标识信息的字段以及表示流的总数量的字段中的至少一个字段。
6.如权利要求1所述的数据发送设备,其特征在于,所述多声道音频数据包括9声道以上的音频信号。
7.一种数据接收设备,包括:
接收单元,从数据发送设备接收与多声道音频数据相关的元数据包;
包解析单元,解析所述接收的元数据包,
其中,所述接收的元数据包包括表示所述多声道音频数据的声道分配标准类型信息的音频声道分配标准类型ACAT字段,
其特征在于,所述声道分配标准类型信息指示10.2声道与30.2声道之间的扬声器位置分配。
8.如权利要求7所述的数据接收设备,其特征在于,所述声道分配标准类型是与10.2声道、22.2声道、30.2声道、30.2声道以上的多声道以及小于10.2声道的多声道中的至少一个相关的声道分配标准类型。
9.如权利要求7所述的数据发送设备,其特征在于,接收的所述元数据包还包括表示所述多声道音频数据的声道数的声道计数字段,其中,所述声道计数字段构成为4比特以上。
10.如权利要求7所述的数据发送设备,其特征在于,接收的所述元数据包还包括表示所述多声道音频数据的声道和扬声器分配信息的3D声道/扬声器分配字段。
11.如权利要求7所述的数据发送设备,其特征在于,接收的所述元数据包还包括在所述数据接收设备支持多流音频时,表示与所述多声道音频数据对应的流标识信息的字段以及表示流的总数量的字段中的至少一个字段。
12.如权利要求7所述的数据发送设备,其特征在于,所述多声道音频数据包括9声道以上的音频信号。
13.一种数据发送方法,包括如下步骤:
生成与多声道音频数据相关的元数据包;
将所述生成的元数据包发送到数据接收设备,
其中,所述生成的元数据包包括表示所述多声道音频数据的声道分配标准类型信息的音频声道分配标准类型ACAT字段,
其特征在于,所述声道分配标准类型信息指示10.2声道与30.2声道之间的扬声器位置分配。
14.如权利要求13所述的数据发送方法,其特征在于,生成的所述元数据包还包括表示所述多声道音频数据的声道数的声道计数字段,其中,所述声道计数字段构成为4比特以上。
15.一种数据接收方法,包括如下步骤:
从数据发送设备接收与多声道音频数据相关的元数据包;
解析所述接收的元数据包,
其中,所述接收的元数据包包括表示所述多声道音频数据的声道分配标准类型信息的音频声道分配标准类型ACAT字段,
其特征在于,所述声道分配标准类型信息指示10.2声道与30.2声道之间的扬声器位置分配。
Applications Claiming Priority (24)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201261599154P | 2012-02-15 | 2012-02-15 | |
US61/599,154 | 2012-02-15 | ||
US201261602978P | 2012-02-24 | 2012-02-24 | |
US201261602975P | 2012-02-24 | 2012-02-24 | |
US61/602,978 | 2012-02-24 | ||
US61/602,975 | 2012-02-24 | ||
US201261604844P | 2012-02-29 | 2012-02-29 | |
US201261604892P | 2012-02-29 | 2012-02-29 | |
US61/604,844 | 2012-02-29 | ||
US61/604,892 | 2012-02-29 | ||
US201261611822P | 2012-03-16 | 2012-03-16 | |
US61/611,822 | 2012-03-16 | ||
US201261613629P | 2012-03-21 | 2012-03-21 | |
US61/613,629 | 2012-03-21 | ||
US201261636901P | 2012-04-23 | 2012-04-23 | |
US201261636879P | 2012-04-23 | 2012-04-23 | |
US61/636,879 | 2012-04-23 | ||
US61/636,901 | 2012-04-23 | ||
US201261641580P | 2012-05-02 | 2012-05-02 | |
US61/641,580 | 2012-05-02 | ||
US201261647628P | 2012-05-16 | 2012-05-16 | |
US61/647,628 | 2012-05-16 | ||
KR1020120157114A KR102011474B1 (ko) | 2012-02-15 | 2012-12-28 | 데이터 전송 장치, 데이터 수신 장치, 데이터 송수신 시스템, 데이터 전송 방법, 데이터 수신 방법 |
KR10-2012-0157114 | 2012-12-28 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103269475A CN103269475A (zh) | 2013-08-28 |
CN103269475B true CN103269475B (zh) | 2017-06-06 |
Family
ID=51660095
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310052879.XA Expired - Fee Related CN103269475B (zh) | 2012-02-15 | 2013-02-18 | 数据收发设备和数据收发方法 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20130222690A1 (zh) |
EP (1) | EP2629540B1 (zh) |
CN (1) | CN103269475B (zh) |
WO (1) | WO2013122388A1 (zh) |
Families Citing this family (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2013122386A1 (en) | 2012-02-15 | 2013-08-22 | Samsung Electronics Co., Ltd. | Data transmitting apparatus, data receiving apparatus, data transreceiving system, data transmitting method, data receiving method and data transreceiving method |
WO2013122385A1 (en) * | 2012-02-15 | 2013-08-22 | Samsung Electronics Co., Ltd. | Data transmitting apparatus, data receiving apparatus, data transreceiving system, data transmitting method, data receiving method and data transreceiving method |
WO2013122387A1 (en) | 2012-02-15 | 2013-08-22 | Samsung Electronics Co., Ltd. | Data transmitting apparatus, data receiving apparatus, data transceiving system, data transmitting method, and data receiving method |
KR101915258B1 (ko) * | 2012-04-13 | 2018-11-05 | 한국전자통신연구원 | 오디오 메타데이터 제공 장치 및 방법, 오디오 데이터 제공 장치 및 방법, 오디오 데이터 재생 장치 및 방법 |
EP2779578B1 (en) * | 2013-03-15 | 2019-11-20 | Samsung Electronics Co., Ltd. | Data Transmitting Apparatus, Data Receiving Apparatus, Data Transceiving System, Method for Transmitting Data, and Method for Receiving Data |
EP2779577B1 (en) | 2013-03-15 | 2019-05-01 | Samsung Electronics Co., Ltd. | Data transmitting apparatus, data receiving apparatus, data transceiving system, method for transmitting data, and method for receiving data |
US10075796B2 (en) * | 2013-10-04 | 2018-09-11 | Sony Corporation | File generation device, file generation method, file reproduction device, and file reproduction method |
US9549015B2 (en) | 2014-04-15 | 2017-01-17 | Lattice Semiconductor Corporation | Communication of multimedia data streams over multiple communication lanes |
RU2701060C2 (ru) * | 2014-09-30 | 2019-09-24 | Сони Корпорейшн | Передающее устройство, способ передачи, приемное устройство и способ приема |
BR112017008015B1 (pt) | 2014-10-31 | 2023-11-14 | Dolby International Ab | Métodos e sistemas de decodificação e codificação de áudio |
DE102016116152A1 (de) * | 2016-04-30 | 2017-11-02 | Krohne Messtechnik Gmbh | Elektrisches Gerät mit einer Funktionseinrichtung |
US10015612B2 (en) | 2016-05-25 | 2018-07-03 | Dolby Laboratories Licensing Corporation | Measurement, verification and correction of time alignment of multiple audio channels and associated metadata |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1462522A (zh) * | 2001-04-27 | 2003-12-17 | 索尼株式会社 | 数据发送/接收设备,数据发送/接收方法和传输系统 |
CN1756086A (zh) * | 2004-07-14 | 2006-04-05 | 三星电子株式会社 | 多通道音频数据编码/解码方法和设备 |
CN1960498A (zh) * | 2006-08-23 | 2007-05-09 | 中兴通讯股份有限公司 | 一种移动多媒体广播系统的多音轨实现方法 |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2004364171A (ja) * | 2003-06-06 | 2004-12-24 | Mitsubishi Electric Corp | マルチチャネルオーディオシステム並びにこれに用いられるヘッドユニット及びスレーブユニット |
JP4082376B2 (ja) * | 2004-04-02 | 2008-04-30 | ソニー株式会社 | 送信装置、送信方法及び送受信システム |
JP2006317575A (ja) * | 2005-05-11 | 2006-11-24 | Matsushita Electric Ind Co Ltd | オーディオ復号装置 |
CN101331771B (zh) * | 2006-05-16 | 2010-07-28 | 索尼株式会社 | 通信系统、发送设备、接收设备和通信方法 |
EP2148326B1 (en) * | 2007-04-17 | 2013-08-14 | Panasonic Corporation | Communication system |
EP2276192A4 (en) * | 2008-04-30 | 2014-03-12 | Korea Electronics Telecomm | METHOD AND APPARATUS FOR TRANSMITTING / RECEIVING MULTICHANNEL AUDIO SIGNALS USING SUPER FRAME |
CN102474642A (zh) * | 2009-07-09 | 2012-05-23 | Lg电子株式会社 | 输出三维内容的显示设备的影像输出方法及采用了该方法的显示设备 |
JP2011124925A (ja) * | 2009-12-14 | 2011-06-23 | Sony Corp | 出力制御装置、出力制御方法、プログラム、及び出力制御システム |
JP5754080B2 (ja) * | 2010-05-21 | 2015-07-22 | ソニー株式会社 | データ送信装置、データ受信装置、データ送信方法およびデータ受信方法 |
-
2013
- 2013-02-13 WO PCT/KR2013/001131 patent/WO2013122388A1/en active Application Filing
- 2013-02-14 EP EP13155194.7A patent/EP2629540B1/en active Active
- 2013-02-15 US US13/768,181 patent/US20130222690A1/en not_active Abandoned
- 2013-02-18 CN CN201310052879.XA patent/CN103269475B/zh not_active Expired - Fee Related
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1462522A (zh) * | 2001-04-27 | 2003-12-17 | 索尼株式会社 | 数据发送/接收设备,数据发送/接收方法和传输系统 |
CN1756086A (zh) * | 2004-07-14 | 2006-04-05 | 三星电子株式会社 | 多通道音频数据编码/解码方法和设备 |
CN1960498A (zh) * | 2006-08-23 | 2007-05-09 | 中兴通讯股份有限公司 | 一种移动多媒体广播系统的多音轨实现方法 |
Non-Patent Citations (1)
Title |
---|
《A DTV Profile for Uncompressed High Speed Digital Interfaces》;CEA;《http://blogimg.chinaunix.net/blog/upfile2/090903185624.pdf》;20080331;第6部分,表格23 * |
Also Published As
Publication number | Publication date |
---|---|
WO2013122388A1 (en) | 2013-08-22 |
EP2629540A2 (en) | 2013-08-21 |
US20130222690A1 (en) | 2013-08-29 |
CN103269475A (zh) | 2013-08-28 |
EP2629540A3 (en) | 2014-05-14 |
EP2629540B1 (en) | 2020-04-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103269475B (zh) | 数据收发设备和数据收发方法 | |
CN103269476B (zh) | 数据收发设备和数据收发系统 | |
US20060009985A1 (en) | Multi-channel audio system | |
CN104053039B (zh) | 数据收发装置、数据收发系统以及数据收发方法 | |
CN104053040B (zh) | 数据收发装置、数据收发系统以及数据收发方法 | |
CN102067490A (zh) | 产生和播放基于对象的音频内容的方法和记录具有用于基于对象的音频服务的文件格式结构的数据的计算机可读记录介质 | |
CN105635798B (zh) | 一种基于异构无线音频的立体声实现方法及系统 | |
EP2629541A2 (en) | Data transmitting apparatus, data receiving apparatus, data transceiving system, data transmitting method, data receiving method and data transceiving method | |
KR102149411B1 (ko) | 오디오 데이터 생성 장치 및 방법, 오디오 데이터 재생 장치 및 방법 | |
CN106341719A (zh) | 同时利用设备多种播放模块的同步音频播放方法及装置 | |
WO2020137767A1 (ja) | 送信装置、送信方法、受信装置および受信方法 | |
CN104221402B (zh) | 数据发送装置、数据接收装置、数据收发系统、数据发送方法、数据接收方法和数据收发方法 | |
JP6514648B2 (ja) | データ送信装置、データ受信装置及びデータ送受信システム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20170606 |