KR20130094163A - Data transmitting apparatus, data receiving apparatus, data transreceiving system, data transmitting method, data receiving method and data transreceiving method - Google Patents

Abstract

PURPOSE: A data transferring equipment for transmitting multi-stream audio signals, a data receiving equipment, a data transceiver system, a data transmitting method, a data receiving method and a data transmitting-receiving method are provided to include audio data respectively corresponding to one of multiple contents in multiple sub-packets to transmit audio signals about multiple contents as a packet. CONSTITUTION: A packet generator (110) produces a packet having multiple sub-packets. A transmit unit (120) transmits the produced packet to a data receiving equipment. The multiple sub-packets respectively include audio data corresponding to any one of multiple contents. The multiple sub-packets have an identification field, in which the multiple sub-packets respectively indicate respective content, and store part of the respective audio data. [Reference numerals] (110) Packet generator; (120) Transmission part

Description

DATA TRANSMITTING APPARATUS, DATA RECEIVING APPARATUS, DATA TRANSRECEIVING SYSTEM, DATA TRANSMITTING METHOD, DATA RECEIVING METHOD AND DATA TRANSRECEIVING METHOD}

The present invention relates to an apparatus for transmitting and receiving data, and more particularly, to a data transmitting apparatus, a data receiving apparatus, a data transmitting and receiving system, a data transmitting method, a data receiving method, and a data transmitting and receiving method for transmitting a multi-channel audio signal in a wired interface environment. It is about.

Recently, as a multimedia environment has been established, a wired interface environment for various data transmission has been proposed. For example, HDMI and MHL define transmission standards for video data, audio signals, and control signals in various formats. In particular, a multi-view environment in which a plurality of contents can be displayed on one screen to allow a plurality of users to view different contents has emerged, and a multi-content (stream) audio signal transmission standard for transmitting and receiving sound for each content is required. It became. Transmission of such a multi-channel audio signal should take into account various formats and device environments used in the related art.

SUMMARY OF THE INVENTION The present invention has been made in accordance with the above-described needs, and an object of the present invention is to provide a data transmission apparatus, a data reception apparatus, a data transmission / reception system, a data transmission method, a data reception method, and data transmission and reception for transmitting a multi-stream (content) audio signal. To provide a method.

Data transmission apparatus according to an embodiment of the present invention for achieving the above object, the packet generating unit for generating a packet including a plurality of sub-packet, and the transmission unit for transmitting the generated packet to the data receiving apparatus Each of the plurality of subpackets includes audio data corresponding to any one of a plurality of contents.

Each of the plurality of subpackets may further include an identification field for indicating which of the plurality of contents.

The generated packet includes a header, wherein the header indicates whether a stream present bit indicating whether the sub packet includes the audio data and whether the audio data included in the sub packet are valid data. It may include at least one of the indicated stream flat bits.

Each of the plurality of subpackets may store a portion of the audio data.

The audio data may include two or more audio signals.

The audio data may follow the IEC 60958 format.

A data receiving apparatus according to an embodiment of the present invention for achieving the above object, includes a receiving unit for receiving a packet including a plurality of sub-packet, and a packet parsing unit for parsing the received packet, Each subpacket of may include audio data corresponding to any one of a plurality of contents.

The header includes a stream present bit indicating whether the sub packet includes the audio data and a stream flat bit indicating whether the audio data included in the sub packet is valid data. It may include at least one of.

Each of the plurality of subpackets may store a portion of the audio data.

The audio data may include two or more audio signals.

The audio data may be in accordance with the IEC 60958 format.

Data transmission and reception system according to an embodiment of the present invention for achieving the above object, a data transmission device for generating and transmitting a packet including a plurality of sub-packet, and the data receiving to receive and parse the transmitted packet And a plurality of sub-packets each including audio data corresponding to any one of a plurality of contents.

A data transmission method according to an embodiment of the present invention for achieving the above object, the packet generation step of generating a packet including a plurality of sub-packet, and the transmission step of transmitting the generated packet to the data receiving device And each of the plurality of subpackets includes audio data corresponding to any one of a plurality of contents.

Each of the plurality of subpackets may further include an identification field for indicating which of the plurality of contents.

The generated packet includes a header, wherein the header is a stream present bit indicating whether the sub packet includes the audio data and whether the audio data included in the sub packet is valid data. It may include at least one of the stream flat bit.

Each of the plurality of subpackets may store a portion of the audio data.

A data receiving method according to an embodiment of the present invention for achieving the above object includes the steps of receiving a packet including a plurality of sub-packet, and a packet parsing step of parsing the received packet, Each of the plurality of subpackets may include audio data corresponding to any one of the plurality of contents.

The header includes a stream present bit indicating whether the sub packet includes the audio data and a sample flat bit indicating whether the audio data included in the sub packet is valid data. It may include at least one of.

Each of the plurality of subpackets may store a portion of the audio data.

The audio data may include two or more audio signals.

According to an aspect of the present invention, there is provided a data transmission / reception method according to an embodiment of the present invention. Transmitting an EDID block including at least one of the second sub-blocks to the second device, the ACAT field indicating channel allocation standard type information of the multi-channel audio data, and a channel count indicating the number of channels Transmitting a metadata packet including at least one of a channel count field and a 3D channel / speaker assignment field indicating channel / speaker assignment information to the first device, and wherein the second device transmits at least one multi-channel Transmitting an audio sample data packet to the first device, wherein the first device transmits the received Parsing at least one multi-channel audio sample data packet and outputting audio, wherein the at least one multi-channel audio sample data packet is composed of a plurality of subpackets and is located or ordered among the plurality of subpackets. It includes an identification field for identifying.

According to another aspect of the present invention, there is provided a data transmission / reception method, comprising: transmitting, by a first device, an EDID block including a sub block representing a multi-stream audio characteristic of multi-channel audio data to a second device; And at least one of a channel count field indicating a channel number of the multi-channel audio data and a channel / speaker allocation field indicating channel / speaker allocation information. Transmitting to the first device; transmitting, by the second device, at least one audio sample data packet to the first device; and parsing the transmitted at least one audio sample data packet. Outputting audio, wherein the at least one audio sample data packet comprises a plurality of audio samples; Consists of sub-packets, the plurality of sub-packets include audio data corresponding to any of a plurality of contents.

According to various embodiments of the present disclosure as described above, the present invention generates a packet including a plurality of subpackets, and each of the plurality of subpackets includes audio data corresponding to any one of the plurality of contents. This provides a standard for transmitting audio signals for a plurality of contents.

1 is a diagram illustrating a transmission timing of a 3D audio signal;
2 is a block diagram showing the configuration of a data transmission and reception system according to an embodiment of the present invention;
3 is a block diagram showing a configuration of a data transmission apparatus of the data transmission / reception system;
4 is a block diagram showing a configuration of a data receiving apparatus of the data transmitting and receiving system;
5 is a view showing a transport stream of an audio sample packet according to an embodiment of the present invention;
6 is a view showing a transport stream of an audio sample packet according to another embodiment of the present invention;
7 illustrates a transport stream format of the present invention;
8 illustrates a transport stream of an audio sample packet according to an embodiment of the present invention;
9 and 10 illustrate a transport stream of a multi-stream audio sample packet according to an embodiment of the present invention;
11 illustrates a transport stream of a multi-stream audio sample packet according to an embodiment of the present invention;
12 is a schematic diagram showing transmission of speaker position information using CEC;
FIG. 13 is a diagram illustrating a step of transmitting 3D audio samples from a BDP to a TV. FIG.
14 is a diagram illustrating a step in which multi-stream audio is transmitted from a BDP to a TV.
15 illustrates a speaker layout for a channel of 3D audio, and
16 to 19 are flowcharts illustrating a data transmission method and a data reception method according to various embodiments of the present disclosure.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, a detailed description of known functions and configurations incorporated herein will be omitted when it may make the subject matter of the present invention rather unclear. The following terms are defined in consideration of the functions of the present invention, and may vary depending on the user, the operator, or the convention. Therefore, the definition should be based on the contents throughout this specification.

Multi-channel audio refers to an audio signal having two or more audio channels. In the following, multi-channel audio is divided into 2D audio channel and 3D audio channel. The 2D audio channel refers to an audio channel having audio channels between 2 and 8 channels, and a speaker corresponding to each channel is disposed on a plane. In contrast, the 3D audio channel has 9 or more audio channels, and the speaker corresponding to each channel is disposed in a three-dimensional space including a plane.

3D audio uses, for example, the channel layout defined in TTA (10.2ch), SMPTE2036-2 (22.2ch) or IEC62574 (30.2ch). 3D audio includes a downmix audio stream as defined herein.

Multi-stream audio is an audio signal comprising distinct audio signals corresponding to each view in a multi-view environment in which two or more distinct content can be viewed. The audio signal for each view may be multi channel audio. Multi-stream audio may be a set of audio streams associated with a video stream transmitted using the 3D video format, for example, when supporting multi-view video such as dual view or quad view games.

This specification is based on 9-channel extended audio for the HDMI 1.4b specification, based on 32-channel (or higher) 3D audio and multi-stream audio for a multi-view display device. . In particular, the changes described below have been included to support the new audio feature.

However, the present invention can be applied to various wired interface transmission standards such as the MHL standard as well as HDMI in a range equivalent to the technical spirit of the present invention, the scope of the present invention extends to such a similar wired interface transmission standard.

Hereinafter, the definition of a new HDMI packet transmitted through a data island period (3D Audio Sample Packet, 3D One Bit Audio Sample Packet, Audio Metadata Packet, Multi-Stream Audio Sample Packet and Multi-Stream One Bit Audio Sample) Packet, packetization process for the packet, definition of an HDMI audio data block in the E-EDID to support capability discovery according to new features, and the like. Specifications not newly defined herein are basically HDMI 1.4b and have not been changed from HDMI 1.4b.

In the present specification, the content disposed with HDMI 1.4b is replaced with the newly described content, but the content not disposed is compatible with the content described with HDMI 1.4b.

The present specification refers to the following.

HDMI, HDMI Licensing, LLC, “High-Definition Multimedia Interface Specification Version 1.4b”, October 11, 2011

TTA, TTAK.KO-07.0098, “Audio Signal Formats for Ultra High Definition (UHD) Digital TV”, December 21, 2011

SMPTE, SMPTE 2036-2: 2008, “UHDTV Audio characteristics and audio channel mapping for program production”, 2008

IEC, IEC 62574 ed 1.0, “Audio, video and multimedia systems General channel assignment of multichannel audio, April 7, 2011

MHL, LLC, "Mobile High-definition Link version 2.0", February, 2012

TTA: Telecommunications Technology Association

summary( Overview )

The basic audio function consists of L-PCM audio streams of IEC 60958 with sample rates of 32 kHz, 44.1 kHz or 48 kHz. It can accept normal stereo streams. Optionally, HDMI can transmit audio with 3 to 32 audio channels at sample rates up to 192kHz. HDMI can also transmit audio streams in IEC 61937 compressed format with bit rates up to 49.152 Mbps (eg surround sound). HDMI can carry two to 32 audio channels of One Bit Audio and one-bit audio in compressed form called DST. HDMI can also transmit 3D audio streams where speakers can be located anywhere in 3D space. The 3D audio stream includes up to 32 audio channels and is transmitted over consecutive packets in the data island interval. HDMI can also transmit multiple audio streams if it supports multi-view video streaming (e.g., for dual-view / quad-view games with multiple audio per view). In this case, four stereo audio streams may be supported.

Packet definition of data island interval ( Data Island Packet Definition )

In Section 5.3.1 Packet Header of the HDMI 1.4b specification, replace Tables 5-8 with the following table.

Table 1-Packet Types

See Packet 8.2 of the HDMI 1.4b specification for the packet layout for these InfoFrames.

As shown in the table, new packets are defined in the areas 0x0B to 0x0F. 0x0B defines a 3D Audio Sample Packet, and 0x0C defines a 3D One bit Audio Sample Packet. In addition, 0x0D is an audio meta data packet, 0x0E is a multi-stream audio sample packet, and 0x0F is a multi-stream one bit audio sample packet. Packet is defined. In this specification, a newly defined packet will be described in detail.

However, the present specification will also describe various alternatives which do not newly define packets as described above. The packet proposals in the table are named the first embodiment. Various alternatives will be named like the second embodiment, the third embodiment ... Various alternatives are described focusing on the differences from the first embodiment.

1-1. 3D audio sample packet (3D Audio Sample Packet )

First Embodiment

In the first embodiment, 3D audio in the L-PCM audio format is transmitted using a newly defined 3D audio sample packet. As described above, 3D audio is defined as audio in which a speaker may be arranged at a predetermined position according to 3D audio standards (e.g. 10.2ch, 22.2ch, 30.2ch, etc.) in 3D space.

The 3D audio stream contains up to 32 audio channels (or more) and is transmitted over consecutive packets in the data island interval. Each packet includes up to eight audio channels. The packet header includes a sample start (sample_start) and a sample present bit (sample_present bit) to indicate the position of the packet within the 3D audio sample. This will be described later. The table below shows a 3D audio sample packet header.

Table  2-3D Audio Sample Packet Heade r

Each field contains the following information.

sample_start: [1 bit] If the sample start is 1, this indicates that the current packet is the first packet of 3D audio samples. In other words, sample_start indicates the start of the 3D audio stream. Sink identifies the beginning of a sample through sample_start.

sample_start = 1 may indicate that the current 3D audio sample packet is completely packetized into 8 audio channels in addition to being the first packet of the 3D audio sample. However, when transmitting 3D audio downmixed to 8 channels or less, only 8 audio channels or less can be packetized. sample_start = 0 means that the current 3D audio sample packet is the middle or last packet of 3D audio samples and includes 8 or less audio channels. There are only five valid sample_present bits set for the 3D audio sample packet.

sample_present.spX: [4 fields, 1 bit each] indicates whether the sub packet X includes an audio sample. One 3D audio sample data is included in two or more 3D audio sample packets, and each 3D audio sample packet includes four subpackets. Accordingly, each 3D audio sample packet header includes a total of four sample_present bits corresponding to each subpacket. Each sample_present bit indicates whether a corresponding subpacket includes a part of a 3D audio sample.

sample_flat.spX: [4 fields, 1 bit each] indicates whether the subpacket X represents a flatline sample. Valid only when sample_present.spX is set. If no available audio data is available at the source, four sample_flat.spX bits are set. This happens during sample rate changes or temporary stream interruptions. If sample_flat.spX is set, subpacket X still indicates a sample duration but does not contain useful audio data. The sample_flat.spX bit is valid only when the corresponding sample_present.spX bit is set.

Adjacent 3D audio sample packets may be used to transmit one 3D audio sample containing 9 to 32 channels of L-PCM audio. (Ie 5 to 16 IEC 60958 frames).

Table 3 shows valid Sample_Present Bit values.

Table  3 - Valid Sample _ Present Bit Configuration for  3D Audio transmission

B.X: [4 fields, 1 bit each] If subpacket X includes the first frame of the 192 frames constituting the IEC 60958 block, B.X = 1. Otherwise B.X = 0.

The 3D audio sample packet consists of an audio sample packet header shown in Table 2 and four subpackets. Each subpacket of the 3D audio sample packet contains 3D audio sample data defined in IEC 60958.

If the source requires a down mix of the 3D audio stream, the downmixed audio stream can also be sent using the 3D audio sample packet. If the sink does not support 3D audio, the source may not transmit 3D audio sample packets. The conversion of 3D audio to legacy audio format is beyond the scope of this specification. There are a number of different subpacket layouts based on channel numbers. Tables 4 to 6 below show examples of 3D audio packet layouts for 12, 24 and 32 channels, respectively.

Table  4 - Example of  3D Audio Sample Packet Layout for  12 channels

Table  5 - Example of  3D Audio Sample Packet Layout for  24 channels

Table  6 - Example of  3D Audio Sample Packet Layout for  32 channels  ( Max )

1 is a diagram illustrating the transmission timing of a 3D audio signal.

In FIG. 1, it can be seen that three 8-channel 2D audio signal samples are transmitted in a horizontal blanking interval. 24 channels of 3D audio signals are transmitted one sample during the same time.

Video dependency ( Video Dependency )

Table 7 shows the available sample rates for 3D audio transmission at various video format timings as specified in CEA-861-F (also D or E). It is assumed here that 58 TMDS clock periods in the horizontal blank period are necessary for content protection re-synchronization. 3D audio transmission may be supported by 3D audio sample packets.

Table 7 shows the maximum sampling frequency of 3D audio for 24-bit video format timing (informative).

table  7 - maximum sampling frequency of  3D Audio for video format timing

Second Embodiment

Unlike the first embodiment, a method of modifying and using a conventional audio sample packet format may be considered.

As shown in Table 8 below, a reserved area of a conventional audio sample packet may be used as a segment_indicator. In an embodiment of the present invention, segment_indicator may be represented by two bits. If segment_indicator = 00, this may indicate a start packet, odd packets among intermediate packets with segment_indicator = 01, even packets among intermediate packets with segment_indicator = 10, and last packets with segment_indicator = 11. Of course, such an example is one embodiment, and the packets matching the bits may be different.

This structure makes it possible to determine whether a segment is lost. If there is a loss of a segment, there is a way to drop the entire "nth sample" including the segment or discard only the lost Audio Sample Packet. Here, the segment refers to an individual audio sample packet constituting a group when one or more audio sample packets are grouped.

In HDMI 1.4b, layout displays information about the number of samples and channels. For example, one audio sample packet may include four samples of two channel audio or one sample of eight channel audio. The present invention extends this to include a layout_ext field in a reserved area of the related art to display information on whether 3D audio is provided together with the layout.

For example, in the case of layout_ext = 0 & layout = 0, 1, the number of 2D audio samples and channels is shown as in the related art, but in the case of layout_ext = 1 & layout = 0, it is 3D audio samples. When layout_ext = 1 & layout = 1, multi-stream audio samples may be displayed.

Fields other than the fields specifically described with respect to the second embodiment are the same as in the first embodiment.

Table  8 - Modified Audio Sample Packet

FIG. 5 is a diagram illustrating a transport stream of an audio sample packet according to the second embodiment.

In FIG. 5, 22.2 channel 3D audio shows setting of each field value when two sample packets are transmitted in a horizontal blanking interval. Segment_indicator = 00 of the first packet, segment_indicator = 10 of the second packet, and segment_indicator = 11 of the last packet. Since all are 3D audio signals, layout_ext = 1 and layout = 0. 3D audio of 10.2 channels also shows similar field values.

Third Embodiment

The third embodiment also modifies and uses the conventional audio sample packet format, but displays brief information as compared to the second embodiment.

As shown in Table 9 below, a reserved area of a conventional audio sample packet may be used as a multichannel_indicator. Unlike the segment_indicator of the second embodiment, the multichannel_indicator displays only information on whether an audio sample packet is for 3D audio. The information indicated by the layout field varies depending on the bit information of the multichannel_indicator.

Therefore, the multichannel_indicator may be represented by one bit. If multichannel_indicator = 0, the layout field indicates a channel / sample layout defined in the existing HDMI 1.4b. When multichannel_indicator = 1, it indicates a layout that transmits 8-channel or more multi-channel audio sample data. In this case, the layout field is used to indicate the start of the sample. If layout = 1, it means that the current audio sample packet includes the beginning of the sample. If layout (start) = 0, the current audio sample packet does not include the beginning of the sample. Of course, such an example is one embodiment, and the packets matching the bits may be different. Fields other than the fields specifically described with respect to the third embodiment are the same as in the first embodiment.

Table  9 - Modified Audio Sample Packet Header

Such a structure has a simpler packet structure compared to the second embodiment since the information on whether 3D audio is included can be grasped only by the audio sample packet while minimizing the change of the reserved area in the existing audio sample packet.

FIG. 6 is a diagram illustrating a transport stream of an audio sample packet according to the third embodiment.

In FIG. 6, 22.2 channel 3D audio shows setting of each field value when two sample packets are transmitted in a horizontal blanking interval. Layout = 1 of the first packet and layout = 0 of the second and third packets. However, since all packets are 3D audio signals, multichannel_indicator = 1. 3D audio of 10.2 channels also shows similar field values.

Fourth Embodiment

The fourth embodiment likewise modifies and uses the conventional audio sample packet format, but provides more information on whether to provide multi-stream audio than the second embodiment and the second embodiment.

As shown in Table 10 below, the reserved area of the conventional audio sample packet may be used as the Stream_ID and the multiASP_layout. multiASP_layout has the same function as multichannel_indicator of the third embodiment. That is, it indicates whether 3D audio is provided. The information indicated by the layout field varies according to the bit information of multiASP_layout.

Stream_ID represents a stream number when multi-stream audio is provided. In an embodiment of the present invention, one bit may be used as the Stream_ID, and in case of 0, the first stream and the second stream are represented. Each corresponds to a view of different content. Of course, such an example is one embodiment, and the packets matching the bits may be different.

If one view of multi-stream audio has an audio signal of 8 channels or less, there will be no case that Stream_ID and multiASP_layout are simultaneously 1 for one audio sample packet.

Table  10 - Modified Audio Sample Packet Header

This structure has the advantage of compatibility in that it is possible to display information about both multi-stream audio and 3D audio through one data sample packet. In addition, when the Stream_ID field and the stream identifier are provided, even when a plurality of streams are transmitted, respective identification can be performed, and thus multi-stream audio sample data exceeding the size of one packet can be transmitted. Also in the fourth embodiment, fields other than those specifically described are the same as in the first embodiment.

An audio data transport stream based on a combination of a Stream_ID field, a multiASP_layout field, and a layout / start field value may be considered. When multiASP_layout = 1, a transport stream of 3D audio is represented, and layout / start indicates start position information of a packet. If Stream_ID = 1, the multistream is displayed, and the number of channels and samples is set according to layout / start. For example, when receiving a packet having Stream_ID = 1, Sink recognizes that Multi-Stream audio data is being transmitted and simultaneously recognizes the currently received packet as audio data of a second stream of two multi-stream audio data.

Fifth Embodiment

Similarly, the fifth embodiment modifies and uses the conventional audio sample packet format.

As shown in Table 11 below, the reserved area of the conventional audio sample packet may be used as Supports_Multistream and multiASP_layout. multiASP_layout has the same function as multiASP_layout of the fourth embodiment. That is, it indicates whether 3D audio is provided. The information indicated by the layout field varies according to the bit information of multiASP_layout.

Supports_Multistream represents information on whether multi-stream audio is provided. In an embodiment of the present invention, Supports_Multistream may use one bit, and if it is 1, it indicates that multi-stream audio is provided. Of course, such an example is one embodiment, and the packets matching the bits may be different.

The audio sample packet according to the fifth embodiment may include up to four two-channel multi-stream audio samples together in one audio sample packet, and audio samples for each view may be transmitted corresponding to four subpackets, respectively. Can be.

If one view of multi-stream audio has an audio signal of 8 channels or less, Supports_Multistream and multiASP_layout will not be 1 simultaneously for one audio sample packet.

Table  11 - Modified Audio Sample Packet Header

This structure has the advantage of compatibility in that it is possible to display information about both multi-stream audio and 3D audio through one data sample packet. In addition, there is an advantage in that all supported features can be described in one audio sample packet. Also in the fifth embodiment, the fields other than those specifically described are the same as in the first embodiment.

The characteristics of the audio data transport stream according to the combination of the Supports_Multistream field, the multiASP_layout field, and the layout / start field value may be considered. If Supports_Multistream = 0 and multiASP_layout = 1, the transport stream of 3D audio is represented. In this case, layout / start indicates packet start position information. If Supports_Multistream = 1, the multistream is displayed, and the number of channels and samples is set according to layout / start.

Sixth embodiment

The sixth embodiment provides a method of modifying a conventional audio sample packet format similar to the fourth embodiment.

Therefore, the reserved area of the conventional audio sample packet can be used as the Stream_ID and the multiASP_layout as shown in Table 12 below. Stream_ID and multiASP_layout each have the same function as Stream_ID and multiASP_layout in the fourth embodiment. The information indicated by the layout field varies according to the bit information of multiASP_layout.

However, since Stream_ID is represented by 2 bits, four stream numbers may be indicated when multi-stream audio is provided. Each different bit combination corresponds to a view of different content.

If one view of the multi-stream audio has an audio signal of 8 channels or less, there will be no case where the Stream_ID is 1 or more and the multiASP_layout is 1 for one audio sample packet.

table  12 - Modified Audio Sample Packet Header

This structure has the advantage of compatibility in that it is possible to display information about both multi-stream audio and 3D audio through one data sample packet. In particular, a larger number of multi-streams can be identified compared to the fourth embodiment. Also in the sixth embodiment, fields other than those specifically described are the same as in the first embodiment.

Table 13 shows characteristics of an audio data transport stream according to a combination of a Stream_ID field, a multiASP_layout field, and a layout / start field value. When multiASP_layout = 1, a transport stream of 3D audio is represented, and layout / start indicates start position information of a packet. If Stream_ID = 01 to 11, a multi-stream is displayed, and the number of channels and samples is set according to layout / start.

table  13 - Capability to deal with proposed features in idea

Seventh embodiment

The seventh embodiment transmits a 3D audio sample packet and a multi-stream audio sample packet by using the 3D audio sample packet newly defined in the first embodiment.

The seventh embodiment is similar to the first embodiment, but further includes an ext_layout field indicating whether to transmit multi-streams. That is, if ext_layout = 0, this means transmitting multi-stream audio, and ext_layout = 1 means transmitting 3D audio.

Since the other sample_start field, sample_present.spX field, and sample_flat.spX field are the same as in the above-described first embodiment, redundant description is omitted. Table 16 shows an audio sample packet structure according to the seventh embodiment.

Table  14- Extended Audio Sample Packet

Table 15 shows the body structure of the packet according to the ext_layout field value. As illustrated, in the case of a multi-stream, an audio signal corresponding to one view may be configured as two channels, and thus, one packet may include audio signals for four views. Alternatively, in the case of a 3D audio signal, audio signals for a plurality of channels may be displayed. Although 32 channels have been described in the above-described various embodiments of the present invention, the present invention is not limited thereto, and an audio signal of 32 channels or more may be configured .

table  15 - EASP packetization

Meanwhile, in the above-described alternatives, the multi-stream audio signal may be included in the region corresponding to the region where the image data of each view is located and transmitted in the vertical synchronization blanking period. 7 is a diagram showing a transport stream format in this case. In FIG. 7, an audio signal corresponding to a left region of an image signal of each view may be included.

1-2. 3D one bit audio sample packet (3D One Bit Audio Sample Packet )

First Embodiment

In the first embodiment, 3D audio in a one bit audio format is transmitted using a newly defined 3D one bit audio sample packet. As described above, 3D audio is defined as audio in which a speaker can be located anywhere in 3D space.

The 3D one bit audio stream contains 32 audio channels (or more channels) and is transmitted in consecutive packets over the data island interval. The packet header includes a sample start (sample_start) and a sample present bit (sample_present bit) to indicate the position of the packet within the one bit audio sample as shown in Table 16.

Table  16-One bit 3D Sample Packet Header

sample_start: [1 bit] If sample_start = 1, the current packet is the first packet of 3D one bit audio samples. Since sample_start is the same as the content described in the first embodiment of the 3D audio packet, duplicate description is omitted.

samples_present.spX: [4 fields, 1 bit each] Indicates whether the subpacket X includes audio samples. There may be four samples_present bits in the 3D one bit audio sample packet header, each for each subpacket. If the subpacket contains an audio sample, the corresponding bit is set. samples_present.spX is also as described above.

samples_invalid.spX: [4 fields, 1 bit each] Indicates whether subpacket X represents an invalid sample. If Samples_invalid = 1, the samples in subpacket X are invalid. If 0, it is valid. This bit is valid only when samples_present.spX is set. If no useful audio data is available at the source, four samples_invalid.spX bits are set. If samples_invalid.spX is set, subpacket X continues to indicate the sample duration but does not contain any useful data.

In 3D one bit audio, sample frequency information is included in an audio info frame and transmitted (see HDMI 1.4b section 8.2.2).

The 3D one bit audio sample packet consists of the one bit audio sample packet header shown in Table 16 and four subpackets. Each subpacket may include one bit audio bits for up to four audio channels.

Adjacent 3D one bit audio sample packets may be used to be transmitted between 9 and 32 audio channels of 3D one bit audio samples. The useful combination of samples_present bits for a 3D one bit audio sample packet is determined by the allowed channel assignment. The reason why the 3D one bit audio sample packet does not have a B0 to B3 field unlike the 3D audio sample packet is that it does not follow the IEC 60958 block format.

Hereinafter, the data transmission / reception system 1000 according to the first embodiment described above will be described.

2 is a block diagram showing the configuration of a data transmission and reception system 1000 according to an embodiment of the present invention, Figure 3 is a block diagram showing the configuration of a data transmission apparatus 100 of the data transmission and reception system 1000. 4 is a block diagram illustrating a configuration of a data receiving apparatus 200 of the data transmitting and receiving system 1000.

As illustrated in FIG. 2, the data transmission / reception system 1000 according to an exemplary embodiment includes a data transmission device 100 and a data reception device 200.

As illustrated in FIG. 3, the data transmission apparatus 100 according to an embodiment of the present invention includes a packet generator 110 and a transmitter 120.

The packet generator 110 generates a packet including a plurality of subpackets. In other words, as described above, a multi-stream audio packet including a plurality of subpackets is generated. In this case, each of the plurality of subpackets may include audio data corresponding to any one of a plurality of contents.

The transmitter 120 transmits the generated packet to a data receiving apparatus.

At this time, each of the plurality of sub-packets may further include an identification field for indicating which of the plurality of contents.

As shown in FIG. 4, the data receiving apparatus 200 according to an exemplary embodiment includes a receiver 210 and a packet parser 220.

The receiver 210 receives a packet including a plurality of subpackets.

The packet parser 220 parses the received plurality of packets. Each of the plurality of subpackets includes audio data corresponding to any one of a plurality of contents.

Various alternatives

Meanwhile, 3D one bit audio sample packets corresponding to various embodiments of the above-described 3D audio sample packet may be defined. That is, in addition to the above-described samlpes_invalid.spX, it may be defined in the same manner as the 3D audio sample packet, and only the B0 to B3 fields may be excluded from the 3D audio sample packet. Since other contents are duplicated, detailed description is omitted.

1-3. Multi Stream  Audio sample packet ( Multi Stream Audio Sample Packet )

Hereinafter, a newly proposed multi-stream audio sample packet structure will be described. First, the first embodiment will be described, and various countermeasures will be described based on differences from the first embodiment.

First Embodiment

In a first embodiment, a plurality of audio streams of the L-PCM and the IEC 61937 compressed audio format are transmitted using a multi-stream audio sample packet. Each audio stream included in the multi-stream audio sample includes two audio channels (or may include more). The sub packet setting is determined by the stream_present bit of the packet header. Table 17 shows the header structure of a multi-stream audio sample packet.

Table  17 Multi - Stream Audio Sample Packet Header

stream_present.spX: [4 fields, 1 bit each] Indicates that the sub packet X includes audio samples of the stream X. There are four stream_present bits in the multi-stream audio sample packet header, each for a sub packet. The stream_present bit indicates whether a corresponding subpacket includes an audio stream. Since stream_present.spX functions substantially the same as sample_present.spX of the above-described 3D audio sample packet, detailed description of the overlapping range is omitted.

stream_flat.spX: [4 fields, 1 bit each] Indicates whether subpacket X represents a flatline sample of stream X. Valid only when stream_present.spX is set. In other words, if no audio data is available at the source, four stream_flat.spX bits are set. This happens while the sample rate is changing or there is a temporary stream interruption. If stream_flat.spX is set, subpacket X continues to indicate a sample duration but does not contain useful audio data. Since stream_flat.spX is also substantially the same as sample_flat.spX of the above-described 3D audio sample packet, detailed description of the overlapping range will be omitted.

If the subpacket X includes the first frame of the 192 frames constituting the IEC 60958 block, B.X = 1. Otherwise B.X = 0.

The multi-stream audio sample packet uses the packet header and four subpackets shown in Table 17 above. Subpackets all have the same structure

HDMI supports multi-view video streaming, allowing the source to transmit four audio streams simultaneously. (E.g. dual view / quad view games with different audio per view). Each audio stream included in the multi-stream audio sample is associated with one single view and includes two audio channels. The subpacket of each multi-stream audio sample packet may comprise a frame of a block of IEC 60958 or IEC 61937 defined by zero or one IEC 60958. Three subpacket layouts are defined. Tables 18 to 20 below show examples of multi-stream audio packet layouts for two, three, and four audio streams.

Table  18 Example of Multi - Stream Audio Sample Packet Layout for  2 audio streams

Table  19 Example of Multi - Stream Audio Sample Packet Layout for  3 audio streams

Table  20 Example of Multi - Stream Audio Sample Packet Layout for  4 audio streams

8 is a diagram illustrating a transport stream of an audio sample packet according to the first embodiment described above.

In FIG. 8, it can be seen that a two-channel audio sample packet for dual-view may include two samples in one sample packet in a horizontal blanking interval. In the case of a quad-view two channel audio sample packet, four samples are included in one sample packet in a horizontal blanking interval. Although multi-channel audio sample transmission of up to two channels has been described as an example, multi-stream audio samples having multiple channels of two or more channels may be transmitted through one multi-stream audio sample packet. In short, each view-specific audio is identical in that it is transmitted through a corresponding subpacket, but may transmit multi-stream audio sample data having one channel (more than two channels) over one or more sequential multi-stream audio sample packets. .

The multi-stream audio sample packet carries four stereo audio samples. Each sample corresponds to an independent audio stream. For example, if an HDMI source transmits two distinct audio streams, subpacket 0 may be used to transmit audio samples of stream 0 and subpacket 1 may be used to transmit audio samples of stream 1. .

Second Embodiment

The second embodiment modifies and uses the conventional audio sample packet format, and further provides information on whether to provide multi-stream audio.

As shown in Table 21 below, the reserved area of the conventional audio sample packet may be used as the Stream_Identifier. Stream_ID represents a stream number when multi-stream audio is provided. In one embodiment of the present invention, two bits may be used as the Stream_ID, and in case of 00, the first stream is displayed, and in case of 01, the second stream is indicated. Each corresponds to a view of different content. Of course, such an example is one embodiment, and the packets matching the bits may be different.

In HDMI 1.4b, layout displays information about the number of samples and channels. For example, one audio sample packet may include four samples of two channel audio or one sample of eight channel audio.

table  21- Modified Audio Sample Packet Header

This structure has an advantage of providing a multi-stream ID simply by using an existing reserved area.

9 and 10 are diagrams illustrating a transport stream of a multi-stream audio sample packet according to the second embodiment.

In FIG. 9, it can be seen that a two-channel audio sample packet for dual-view can be transmitted by including four sample data for the same content in one sample packet in a horizontal blanking interval. . In other words, one sample packet includes an audio signal for one view. In the case of a two-channel audio sample packet for quad view, four sample packets for four views are transmitted in a horizontal blanking interval. In addition, as in the embodiment of view 2, sample packets for one view may be transmitted continuously or alternately with other views. In the drawing, the two-channel audio sample packet has been described as an example, but the same will be the case with a plurality of channel audio sample packets having two or more channels. In addition, although the number of sample data may be uniformly included for each view and transmitted as shown, it may be possible to transmit different numbers of sample data.

FIG. 10 illustrates a case in which an 8-channel audio sample packet for dual-view includes sample data indicating 8 channels in two sample packets in a horizontal blanking interval. Transmission of sample data for one view is completed through one sample packet. Sample packets for each view may be sent sequentially or alternately with sample packets for other views. In the case of 8-channel audio sample packet for quad-view, it is identical to transmit sample data of one content in one sample packet in a horizontal blanking interval, but for four views Each sample packet must be sent.

When the Stream_Identifier is used as in the second embodiment, when such information is also included in the audio clock reproduction packet, video and audio synchronization can be more efficiently performed. The table below shows the structure of the modified audio clock reproduction packet in the second embodiment.

table  22 - Audio Clock Regeneration Packet Header and Subpacket

As shown in the above table, the video and audio synchronization of the multi-view system can be efficiently performed by including information on the index of the multi-stream in the reserved area of the audio clock play packet. In particular, such a packet structure would be useful for systems where multiple views are not displayed simultaneously.

Third Embodiment

The third embodiment is similar to the fourth embodiment of the 3D audio sample packet, and has a function of modifying and using a conventional audio sample packet format and providing multi-stream identification information.

As shown in Table 23 below, the reserved area of the conventional audio sample packet may be used as the Stream_ID and the multiASP_layout. Stream_ID and multiASP_layout are the same as described in the fourth embodiment of the 3D audio sample packet.

table  23 - Modified Audio Sample Packet Header

This structure has the advantage of compatibility in that it is possible to display information about both multi-stream audio and 3D audio through one data sample packet.

The characteristics of the audio data transport stream based on the combination of the Stream_ID field, the multiASP_layout field, and the layout / start field value are the same as described in the fourth embodiment of the 3D audio sample packet.

Fourth Embodiment

Similarly, the fourth embodiment modifies and uses the conventional audio sample packet format. The fourth embodiment corresponds to the fifth embodiment of the 3D audio sample packet.

As shown in Table 24 below, a reserved area of a conventional audio sample packet may be used as Supports_Multistream and multiASP_layout. Supports_Multistream and multiASP_layout are the same as described in the fifth embodiment of the 3D audio sample packet.

table  24 - Modified Audio Sample Packet Header

This structure has the advantage of compatibility in that it is possible to display information about both multi-stream audio and 3D audio through one data sample packet. In addition, there is an advantage in that all supported features can be described in one audio sample packet.

The characteristics of the audio data transport stream according to the combination of the Supports_Multistream field, the multiASP_layout field, and the layout / start field value may be considered. The content of each field value is the same as Table 13 of the above-mentioned 3D audio sample packet.

Meanwhile, in the above-described alternative, the multi-stream audio signal may be included in the region corresponding to the region where the image data of each view is located and transmitted in the vertical sync blanking period. This has been described with reference to FIG. 7.

Fifth Embodiment

The fifth embodiment provides a method of modifying a conventional audio sample packet format similar to the third embodiment.

Therefore, as shown in Table 25 below, the reserved area of the conventional audio sample packet may be used as the Stream_ID and the multiASP_layout. Stream_ID and multiASP_layout each have the same function as Stream_ID and multiASP_layout in the third embodiment.

However, since Stream_ID is represented by 2 bits, four stream numbers may be indicated when multi-stream audio is provided. Each different bit combination corresponds to a view of different content.

If one view of the multi-stream audio has an audio signal of 8 channels or less, there will be no case where the Stream_ID is 1 or more and the multiASP_layout is 1 for one audio sample packet.

table  25 - Modified Audio Sample Packet Header

This structure has the advantage of compatibility in that it is possible to display information about both multi-stream audio and 3D audio through one data sample packet. In particular, a greater number of multi-streams can be identified compared to the third embodiment.

Table 26 shows characteristics of an audio data transport stream according to a combination of a Stream_ID field, a multiASP_layout field, and a layout / start field value. When multiASP_layout = 1, a transport stream of 3D audio is represented, and layout / start indicates start position information of a packet. If Stream_ID = 01 to 11, a multi-stream is displayed, and the number of channels and samples is set according to layout / start.

table  26 - Capability to deal with proposed features in idea

Sixth embodiment

The sixth embodiment is a method of adding Stream_ID to an audio sample packet according to the first embodiment. Stream_ID is as described above and other fields are the same as described in the first embodiment. Table 27 shows an audio sample packet header according to the sixth embodiment. However, in the following table, Stream_ID is set to 4 bits but may be set to 1 to 3 bits or 5 bits or more. Here, the packet type means a newly defined packet time.

Since the stream ID is used to identify the audio for each stream, unlike the first embodiment, one multi-stream audio sample packet includes audio sample data for one stream.

table  27 - Extension audio Sample Packet

Seventh embodiment

The seventh embodiment represents a 3D audio sample packet and a multi-stream audio sample packet using the 3D audio sample packet newly defined in the first embodiment of 1.1.

The seventh embodiment is similar to the first embodiment, but further includes an ext_layout field indicating whether to transmit multi-streams. That is, if ext_layout = 0, this means transmitting multi-stream audio, and ext_layout = 1 means transmitting 3D audio.

Since the other sample_start field, sample_present.spX field, and sample_flat.spX field are the same as in the above-described first embodiment, redundant description is omitted. Table 28 shows an audio sample packet structure according to the seventh embodiment.

table  28 - Extended Audio Sample Packet

Table 29 shows the packet body structure according to the ext_layout field value. As illustrated, in the case of a multi-stream, an audio signal corresponding to one view may be configured as two channels, and thus, one packet may include audio signals for four views. Alternatively, in the case of a 3D audio signal, audio signals for a plurality of channels may be displayed. Although various embodiments of the present invention describe 3D audio for up to 32 channels in the present disclosure, the present invention is not limited thereto and may be applicable to audio signals of 32 channels or more.

table  29- EASP packetization

Table 30 shows valid Sample_Present Bit values.

Table  30- Valid Sample _ Present Bit Configuration for Multiple Audio  Stream transmission

FIG. 11 is a diagram illustrating a transport stream of a multi-stream audio sample packet according to the seventh embodiment.

In FIG. 11, it can be seen that a two-channel audio sample packet for dual-view can be transmitted by including samples for two views in one sample packet in a horizontal blanking interval. In the case of a quad-view two channel audio sample packet, four samples are included in one sample packet in a horizontal blanking interval. That is, one sample packet includes four samples for transmission. In the drawing, the two-channel audio sample packet has been described as an example, but the same will be the case with a plurality of channel audio sample packets having two or more channels.

In the above-described various embodiments, the multi-stream audio signal may be included in the region corresponding to the region where the image data of each view is located and transmitted in the vertical sync blanking period. 7 described above shows a transport stream format in this case. In FIG. 7, an audio signal corresponding to a left region of an image signal of each view may be included.

1.4 multi Stream  One-bit audio packet ( Multi - Stream One Bit Audio Packet )

First Embodiment

New packets can be defined for multi-stream one-bit audio. This corresponds to a 3D audio sample packet.

When transmitting multi-stream one-bit audio, each subpacket may include one-bit audio bits for zero, one, two (or more) audio channels. The multi-stream one-bit audio sample contains four stream_present bits, each for a subpacket.

If the subpacket contains audio samples of each individual stream, the corresponding bit is set. Four stream_invalid.spX bits are set if no audio data is available from the source. If stream_invalid.spX is set, subpacket X continues to indicate a sample period, but does not contain any useful data.

table  31 - Multi - Stream One Bit Audio Packet Header

stream_present.spX: [4 fields, 1 bit each] Indicates whether the subpacket X includes audio samples of the stream X. Since stream_present.spX functions substantially the same as sample_present.spX of the above-described 3D audio sample packet, detailed description of the overlapping range is omitted.

stream_invalid.spX: [4 fields, 1 bit each] Indicates whether subpacket X represents an invalid sample of stream X. If the samples included in the sub packet X are invalid, Stream_invalid = 1. In the opposite case, Stream_invalid = 0. The bit is valid only if the associated stream_present.spX is set. Since stream_present.spX functions substantially the same as sample_present.spX of the above-described 3D audio sample packet, detailed description of the overlapping range is omitted.

Note that for multi-stream one-bit audio, sample frequency information is included in the audio info frame and transmitted (see section 8.2.2 of HDMI 1.4b).

The multi-stream one-bit audio sample packet uses four subpackets identical to the one-bit audio sample subpacket shown in Table 31. The reason why one-bit multi-stream audio sample packets do not have B0 to B3 fields differently from multi-stream audio sample packets is that they do not follow the IEC 60958 block format.

Various alternatives

Meanwhile, the one-bit multi-stream audio sample packet corresponding to the various embodiments of the above-described multi-stream audio sample packet may be defined. That is, in addition to the above-described samlpes_invalid.spX, it can be defined in the same manner as the multi-stream audio sample packet, and only B0 to B3 fields can be excluded from the multi-stream audio sample packet. Since other contents are duplicated, detailed description is omitted.

2.1. For 3D audio Info  frame( Infoframe for  3D Audio ) Of Meta  Data packet

First Embodiment

In the first embodiment, as described above, additional information related to 3D audio may be transmitted using a newly defined audio metadata packet instead of the info frame. The source always transmits audio metadata once for at least two video fields, when the 3D audio stream is transmitted.

 The audio metadata includes the number of channels, an audio channel allocation standard type (ACAT), and channel / speaker allocation of the 3D audio stream. The table below shows headers of newly defined audio metadata packets.

Table  32 - Audio Metadata Packet Header

Table  33- Audio Metadata Packet contents

Each field of the packet is defined as follows.

3D_CC: [5 bits] Indicates a channel count of 3D audio transmitted. If the audio channel count (CC0 ... CC2) in the audio info frame does not match the 3D audio channel count (3D_CC0 ... 3D_CC4) of the audio metadata packet, the channel count of the audio info frame is ignored. Table 34 shows audio channels according to 3D_CC values.

ACAT: [4 bits] Indicates the type of audio channel assignment standard provided by the source. Table 35 below shows the values of the ACAT field. Table 36 describes the assignment of speaker positions when ACAT is set to 0x01 (10.2 channels). Similarly, Tables 37 and 38 contain information for 22.2 and 30.2 channels, respectively.

3D_CA: [8bits] Indicates channel / speaker assignment for 3D audio. Details are shown in Table 36 to Table 38. The 3D_CA field is not valid for IEC 61937 compressed audio streams.

Table  34 3D_ CC field

Table  35 - Audio Channel Allocation Standard Type field

Table  36-3D_ CA field for  10.2 channels  ( ACAT  = 0x01)

Table  37-3D_ CA field for  22.2 channels  ( ACAT  = 0x02)

Table  38-3D_ CA field for  30.2 channels  ( ACAT  = 0x03)

Whenever an active 3D audio stream is transmitted, the correct audio metadata packet can be transmitted at least once in two video fields. If there is a start of a new 3D audio stream or there is a change included in the 3D audio stream that can be represented by the audio metadata packet and the audio info frame, the corrected and correct audio metadata packet is first affected by non-disruptive non -silent) can be sent no later than one video frame following audio samples. This may occur just before the first affected audio sample is transmitted. For 3D one bit audio streams, audio metadata may be sent before the first affected sample. The audio metadata packet transmission may be transmitted at any time including a horizontal blank section or a vertical blank section within the data island section. When 3D audio is streamed, the sink ignores the CC and CA fields included in the audio info frame and instead references the 3D_CC and 3D_CA included in the audio metadata.

However, even when transmitting the above-described audio metadata, the existing audio info frame is still used. That is, even when audio metadata is newly used for channel allocation for 3D audio, an audio info frame is used for channel allocation for 2D audio.

In addition, in the above-described embodiment, the channel allocation standard type (ACAT) has been described as 10.2 channels, 22.2 channels, and 30.2 channels, but the technical idea of the present invention is less than 10.2 channels, 30.2 channels or more, or the number between 10.2 and 30.2 channels. The same may be applied to a channel having.

Second Embodiment

Unlike the first exemplary embodiment, a method of modifying an audio info frame defined in the conventional HDMI 1.4b may be considered. Table 39 shows the audio info frame structure in this case. The CC field indicates a channel count of the transmitted audio, and the CA field indicates channel / speaker allocation information.

Although the conventional CC field is represented by three bits, the second embodiment further uses two bits of the reserved area. That is, channel count information is displayed using five bits of CC0, CC1, CC2, CC3, and CC4.

Meanwhile, Channel / Speaker allocation information is added to the reserved areas of CEA861-D and Table 20. Unlike the first embodiment, the second embodiment does not include an ACAT field.

table  39 - Modified Audio Infoframe

Third Embodiment

The third embodiment also extends the second embodiment to modify an audio infoframe defined in the conventional HDMI 1.4b. Table 40 shows the audio info frame structure in this case. As in the second embodiment, the CC field indicates a channel count of the transmitted audio, and the CA field indicates channel / speaker allocation information.

The third embodiment is basically similar to the second embodiment, but provides a method of further extending the CA field. If one bit of the reserved area is set to channel_extension bit and channel_extension = 0, the CC # and CA # fields defined in CEA861-D are used as they are. That is, it supports 2D audio mode. On the other hand, if channel_extension = 1, PB2 [7: 6] is used as the extension bits CC4 and CC3 of the CC, and the reserved area of the PB6 is used as the CA_ext field. Extension bits for 3D audio are used.

In this case, although the conventional CC field is represented by three bits as in the second embodiment, the second embodiment further uses two bits of the reserved area. That is, channel count information is displayed using five bits of CC0, CC1, CC2, CC3, and CC4.

In addition, the PB6 field may be added to the existing CA bits (PB4). Add definition of Channel / Speaker allocation information for audio over 10.2ch to reserved area of CEA861-D, Table 20 (or CEA861-E, Table28). A separate table can be defined for each specification. As a result, the CA field is extended to 16 bits, enabling multichannel audio transmission.

However, unlike the above, a new 8-bit field may be defined and used instead of the existing CA field. For example, a new CA bit can be defined using the PB6 field or the PB7 field .

table  40 - Modified Audio Infoframe  2

Fourth Embodiment

The fourth embodiment is a combination of the second embodiment and the third embodiment as appropriate. In the fourth embodiment, a conventional audio info frame includes a 3D_CH_present field, a CA field of PB4, and a 3D_CC field of PB6.

The 3D_CH_present field performs the same function as the channel_extension in the third embodiment. That is, if 3D_CH_present = 0, the CC # and CA # fields defined in CEA861-D are used as they are. That is, it supports 2D audio mode. On the other hand, if 3D_CH_present = 1, PB6 [4: 0] is used as the extension bits CC4, CC3, CC2, CC1, and CC0 of the CC, and the reserved area of the PB4 is used as the CA field as in the second embodiment. Extension bits for 3D audio are used. As in the second and third embodiments, the ACAT field is not defined. Other details not specifically described are the same as those of the first to third embodiments.

table  41- Modified Audio Infoframe  3

2.2 multi Stream  For audio Info  frame( Infoframe for Multi stream Audio )

In the case of multi-stream audio, new metadata packets are not defined and the info frame defined in the existing HDMI 1.4b is used. When a plurality of active audio streams are transmitted using a multi-stream audio sample packet, an accurate audio info frame may be transmitted at least once per two video fields. The audio info frame can then be used to describe the audio characteristics of all active audio streams.

If there is a change in the beginning of a new audio stream and any changes contained in the audio stream that may be represented by multiple new audio streams or audio info frames, the correct correct audio info frame is the first non-silent affected. It may be sent no later than one video field following the audio sample. This may occur just before the first affected audio sample is transmitted. For one bit audio streams an audio info frame may be sent before the first affected sample.

Info  Modify frame

In the case of using the stream_ID unlike the above embodiment (fourth and sixth embodiments of the 3D audio sample packet and the second, third, fifth and sixth embodiments of the multi-stream audio sample packet), the audio information is shown in Table 42 below. You can include stream_ID in the frame.

In Table 42, Stream_ID represents the stream ID of the current audio info frame, and Stream_Count represents the total number of audio streams transmitted. In the above embodiment, the information frame is not modified by transmitting a sample in four subpackets constituting the body of the multi-stream audio sample packet instead of using the stream identifier.

Table  42 - Modified Info Frame

3.1. EDID for 3D audio ( EDID for  3D Audio )

For information on audio characteristics and speaker assignments for 3D audio, refer to 1) modifying existing shortened audio descriptor and speaker assignment data blocks, or 2) defining new data blocks in the Reserved for audio-related blocks area in Extended Tag Codes. Extended Tag Codes can be included in the EDID by defining a new data block in the Reserved for HDMI Audio Data Block area.

For example, the EDID data block described in CEA-861-F (also D or E) may be used to indicate both sync audio characteristics and speaker assignment support. Sync audio characteristics and speaker assignment support are represented in a series of Short Audio Descriptors located in the CEA Extension's data block collection. This data includes parameters associated with each of those encodings, such as a list of audio encodings supported by the sink and the number of channels that support that format. Speaker Allocation Descriptors can be included in the Data Block Collection and support multi-channel (up to 8 channels) L-PCM or multi-channel (up to 8 channels) one-bit audio for 2D audio. Required for sink.

First Embodiment

However, in the present invention, when the sink supports multi-stream audio and / or 3D audio transmission, an HDMI Audio Data Block having an Extended Tag Code 18 is used to display 3D audio characteristics, 3D speakers. It can be used to indicate allocation information, multi-stream audio characteristics.

If the sink supports 3D audio transmission, the HDMI audio data block includes one or more HDMI 3D audio descriptors (HDMI_3D_AD) with 4 bytes. In addition, the HDMI audio data block may include one HDMI 3D speaker allocation descriptor (HDMI_3D_SAD) following the last HDMI 3D audio descriptor.

If the sink supports multi-stream audio transmission but not 3D audio transmission, the HDMI audio data block may include one or more CEA shortened audio descriptors (CEA_SAD) along 3 bytes. CEA short audio descriptors appear on the CEA-861-F (also D or E).

If the sink supports multi-stream audio transmission and 3D audio transmission, the HDMI audio data block includes one or more CEA short audio descriptors that conform to the HDMI 3D speaker allocation descriptor. See Table 43 for details.

The HDMI 3D audio descriptor described above represents support for audio encoding as defined in CEA-861-F (also D or E). HDMI devices may support 3D audio formats that conform to TTA (10.2ch), SMPTE2036-2 (22.2ch) or IEC62574 (30.2ch). The details are described in Table 45 through Table 49. These tables are classified according to the audio format codes given in Tables 24 and 26 of CEA-861-F (also D or E).

As described above, the HDMI 3D speaker allocation descriptor may be included in the HDMI audio data block and may be required for a sink supporting 3D audio. The structure of the HDMI 3D speaker allocation descriptor is shown in Table 50. A sink indicates audio capability by indicating a speaker, a pair of speakers, and sets a corresponding flag. The HDMI 3D Speaker Assignment Descriptor may include a 4-bit ACAT field, which indicates the type of audio channel assignment specification. Details are described in Tables 50 to 52. CEA Short Audio Descriptors may also be included in the HDMI audio data block and may be required for sinks that support multi-stream audio transmission. These descriptors describe the audio characteristics of each audio stream. The maximum channel count is limited to two channels for each audio stream, but may be more than that depending on the embodiment.

table  43 - HDMI Audio Data Block

* The length of following data block payload (in bytes), 2+ 4 * X + 4 + 3 * Y

** 3 + 4 * X + 1

Each field of the HDMI audio data block shown in Table 43 will be described below.

NUM_HDMI_3D_AD [3 bits]: Indicates the number of HDMI 3D audio descriptors.

NUM_CEA_SAD [3 bits]: Indicates the number of CEA Short Audio Descriptors.

Max_Stream_Count-1 [2 bits]: Indicates the number obtained by subtracting 1 from the transmitted stream. See Table 44

HDMI_3D_AD: HDMI 3D Audio Descriptor

HDMI_3D_SAD: HDMI 3D Speaker Allocation Descriptor

CEA_SAD CEA: CEA Short Audio Descriptor

Table  44 Max _ Stream _ Count -One field

Table  45 HDMI  3D Audio Descriptor for Audio Format Code  = 1 ( LPCM )

Table  46 HDMI  3D Audio Descriptor for Audio Format Codes  2 to  8

Table  47 HDMI  3D Audio Descriptor for Audio Format Codes  9 to  13

Table  48 HDMI  3D Audio Descriptor for Audio Format Code  14 ( WMA Pro )

Table  49 HDMI  3D Audio Descriptor for Audio Format Code  15 ( extension )

Table  50 HDMI  3D Speaker Allocation Descriptor for  10.2 channels  ( TTA Standard )

The shaded bits in the table above are the designated speakers associated with the 10.2 channels.

Table  51 HDMI  3D Speaker Allocation Descriptor for  22.2 channels  ( SMPTE2036 -2)

The shaded bits in the table above are the designated speakers associated with the 22.2 channels.

Table  52 HDMI  3D Speaker Allocation Descriptor for  30.2 channels  ( IEC62574 Of Ed .One)

The shaded bits in the table above are the designated speakers associated with the 30.2 channels.

Although speaker allocation of multi-channel 3D audio data is described in three bytes in the first embodiment, this is only an example. For 3D audio data of more than 30.2 channels, more speaker allocation information may be required. In this case, the 3D Speaker Allocation Descriptor may indicate speaker allocation using 4 bytes or more.

Table  53 Audio Channel Allocation Type  ( ACAT ) field

On the other hand, the remaining bit value of the ACAT field may be assigned to various channel types (eg Dolby, USC or the format of ITU-R to be standardized in the future) according to the manufacturer.

Second Embodiment

Unlike the first embodiment, the second embodiment modifies an audio data block. In particular, the reserved area of the CEA Short Audio Descriptor may be used to extend and display the maximum number of channels. For example, it can be extended using Byte1 [7] and Byte2 [7] as shown in Table 54 below. This allows 3D audio to be represented. The CEA Short Audio Descriptor may have different field areas depending on the audio format.

Table  54 - CEA Short Audio Descriptor

Independently of the second embodiment, an ACAT (Audio Channel Allocation Standard Type) may be set by modifying a speaker allocation data block. ACAT can be identified using Byte3 [7: 4], a reserved area of the Speaker Allocation Data Block payload, and the speaker allocation data block for each type can be defined as a separate new table. The position of the ACAT field may be defined at another position within the range of Byte2 [7: 3] to Byte3 [7: 0].

As shown in Table 55, ACAT = 0001 may represent 10.2 channels of the TTA standard, and ACAT = 0010 may represent 22.2 channels.

Table  55- Speaker Allocation Data Block Payload

However, according to the manufacturer, the allocation data block of the speaker may be defined differently. In this case, the manufacturer may think of ways to increase compatibility by using a common speaker layout. The table below shows the SMPTE2036-2 standard for 22.2 channels of 3D audio. Shaded bits correspond to common speaker layouts from different manufacturers.

Table  56 - Speaker Allocation Data Block Payload  2

However, in the above-described embodiment of the Speaker Allocation Data Block Payload, the ACAT field is not defined separately, and the type of each type (eg 10.2ch (TTA), 22.2ch (SMPTE2036-2), 13.1ch (Dolby), etc.) is classified as Source. In the speaker allocation data block payload, it is possible to directly determine the location and type of the bit set in the payload. This is because the number of channels can be known through the modified audio data block.

Third Embodiment

In the third embodiment, the “Extended Speaker Allocation Data Block” type is newly defined in the Extended Tag Code of the EDID without newly defining the HDMI audio data block. The new data block may be up to 32 bytes in size. In Table 57, the case of 4 bytes is taken as an example. The size of the ACAT can also be changed by changing as necessary.

ACAT is identified using the reserved area (Byte3 [7: 4]), and Speaker Allocation Data Block for each type is defined. The configuration of the payload may be the same as in the above-described embodiment. Of course, the ACAT field may be located in an area other than the reserved area described above.

The remaining bit values of the ACAT field may be allocated and used for various channel types (e.g. Dolby, USC, or the format of ITU-R to be standardized in the future) according to the manufacturer.

Table  57 - Modified Speaker Allocation Data Block

Fourth Embodiment

The fourth embodiment is similar to the third embodiment, but after defining data blocks for Speaker Allocation Standard Types (eg 10.2ch (TTA), 22.2ch (NHK), 13.1ch (Dolby), etc.) The difference is that they are added to each extended tag code.

For example, data block tag code 19 represents a speaker allocation data block for a TTA 10.2 channel, data block tag code 20 represents a speaker allocation data block for an NHK 22.2 channel, and data block tag code 21 is for a Dolby 13.1 channel. It may represent a speaker allocation data block.

Table  58 - Modified Speaker Allocation Data Block

Fifth Embodiment

The fifth embodiment defines an extended audio data block. The extended audio block corresponds to the value of the extended tag code. And, the extended audio data block includes one or more Extension CEA Short Audio Descriptors. Each extended CEA short audio descriptor contains information about the number of channels. In this case, the size or format of each field may be the same as the short audio descriptor of the audio data block, but may be defined differently.

Table  59 - Extended Audio Data Block

As shown in the table above, the extended CEA shortened audio descriptor may include an uncompressed audio format code. The uncompressed audio format code can be defined as follows.

Table  60- Uncompressed Audio Format Code

In this case, the extended speaker allocation data block may be defined as a value of an extended tag code. The extended speaker assignment data block may include an ACAT field as shown in the table below. The reserved area may be used for extension. Alternatively, the remaining bit values may be assigned to various channel types (e.g. Dolby, USC or ITU-R format to be standardized) according to the manufacturer.

Table  61 - Extended Speaker Allocation Data Block

In this embodiment, the payload of the extended speaker assignment data block is shown in the table below. The shade area is used for speaker allocation of each channel allocation type.

Table  62 - Channel Allocation Compatibility

For new speaker locations EDID / CEC ( EDID Of CEC for new Speaker Position )

In the present invention, a speaker position data block for delivering position information of a new speaker to a source may be defined. The data block includes the coordinates (x, y, z) and the angle of placement of all speakers connected to the sink. This information can be used by the source for a variety of processes, such as down mixing and object audio coding. Since the value of the extended tag code in the table below is an embodiment, the speaker position data block may be defined and used together with the various data blocks defined above.

Table  63 - Speaker Position Data Block

The speaker position data block may be defined as shown in the following table. Byte [1] ~ [5] stores the location information of one speaker. By the same method, Byte [6] ~ [30] stores speaker position information. Byte 31, 32 is defined as reserved area.

When using the example method, since one data block can transmit only position information of up to six speakers, round up (N / 6) speaker position data blocks will be required to correspond to N channels.

Table  64 - Speaker Position Data Block

CEC Speaker location information transmission

12 is a schematic diagram showing transmission of speaker position information using CEC.

As shown in FIG. 12, when the source requests the speaker position from the sink, the sink informs the speaker position information.

3.1. Multi Stream  EDID for audio ( EDID for  3D Audio )

A new multi-stream audio data block for multi-stream audio can be defined in the extension tag code. The multi-stream audio data block includes a Max_stream_count-1 field and a CEA Short Audio Descriptor region. Max_stream_count-1 represents the number of streams to be transmitted. One or more CEA Short Audio Descriptors may be present and may be defined in accordance with CEA861-D.

Table  65 - Multi Stream Audio Data Block

On the other hand, it is possible to indicate whether to provide multi-stream video / audio to the vendor-specific data block. This uses the multistream_indicator field. If the sink supports multiple streams, multistream_indicator = 1. However, the multistream_indicator field may be defined in other areas of the data block as well as the HDMI VSDB.

Table  66- Vendor - specific Data Block

By defining a multistream_indicator using two or more bits, you can identify the various multistreams.

Table  67- Vendor - specific Data Block

Second Embodiment

The second embodiment newly defines a multi audio stream data block using an extension tag code. The newly defined multi-audio stream data block includes a CEA Short Audio Descriptor region, an audio stream length, a Max_stream_count field, and the like. Each field is the same as the above-described other embodiment, and thus redundant description is omitted.

Table  68 - Multi Audio Stream Data Block

Third Embodiment

Meanwhile, similarly to the first embodiment, another method using the HDMI Audio Data Block may be considered.

Redefine the extension tag code. As in the first embodiment, tag code 18 may be used for addition of an extended HDMI audio data block.

The table below shows the structure of the Extended HDMI Audio Data Block. The extended HDMI audio data block according to the third embodiment includes an Extended CEA Short Audio Descriptor (ECSAD), an Extended Speaker Allocation Descriptor (ESAD), and a Multiple Audio Stream Descriptor (MASD). Stream Descriptor).

The extended CEA short audio descriptor (ECSAD) includes descriptors equal to the value of the Num_ECSAD field when the sink device supports the 3D audio function. The extended speaker allocation descriptor (ESAD) includes one descriptor when the value of the Num_ECSAD field is greater than 0 when the sink device supports the 3D-audio-cahnnel function. The multi audio stream descriptor (MASD) includes descriptors corresponding to the value of the Num_MASD field when the sink device supports the multi stream audio function.

The Max Stream_Count -1 field is defined as the maximum number of streams the sink device can receive. Since the multi-stream audio is transmitted in one audio sample packet, the audio stream for each view has the same audio characteristics, such as having the same coding type and sampling frequency.

The Num_MASD field defines the number of extended CEA short audio descriptors. Up to seven can be included. If this field is 0, it means that 3D audio function is not supported.

The Num_ECSAD field defines the number of multi-stream audio descriptors included in this data block. Up to four can be included. If this field is 0, it means that multi-stream audio is not supported. If Max Stream_Count-1 is non-zero, at least one MASD must be defined. If the ECSAD is composed of 4 bytes, up to 6 can be defined.

Table  69 - Extended HDMI Audio Data Block

The third embodiment may consider the following modified alternatives.

For example, an extended HDMI audio data block may include only ECSAD, and the remaining two types of ESAD and MASD may be defined using different extension tag codes.

In this case, two descriptors defined by different extension tag codes may be defined as one separate data block or may be defined as different data blocks. In the above-described table, Max Stream_count -1 in the field defined in PB3 is included in the data block in which the multi-stream audio descriptor is defined.

Unlike the above, the extended HDMI audio data block includes ECSAD and ESAD related to 3D audio, and MASD may be defined using another extended tag code.

The structure of ECSAD is described with reference to the table below. Corresponds to the shaded part of the table.

This descriptor currently only accepts two coding types, LPCM and DSD, as shown in the lower left table. However, another uncompressed audio format may be additionally included using the reserved area of the UAFC field.

The number of channels is 5 bits, so up to 32 channels can be selected.

Table  70 - Extended CEA Short Audio Descriptor

However, the following alternatives can also be considered for the method.

The table below expands the total size of the descriptor to 4 bytes. In addition, audio format codes refer to tables defined in CEA861-E. Therefore, all compression / uncompression coding types defined in CEA861-E can be specified.

As the size of the descriptors increases, the number of extended CEA shortened audio descriptors (ECSADs) that can be included in a data block is limited to a maximum of six descriptors. On the other hand, up to four may be included in the above-described embodiment.

The syntax of PB3 and PB4 is defined in the same form as Byte 2, 3 of Table 45 ~ 49 of CEA861-E according to the change of each audio format code type.

Table  71- Extended CEA Short Audio Descriptor

In the third embodiment, the structure of the ESAD will be described.

This is the shaded area in the table below.

ESAD currently selects speaker allocation information up to max 30.2 channels. However, another speaker placement format may be additionally included using the reserved area of the ACAT field.

Table  72- Extended Speaker Allocation Descriptor

The following table shows the ESAD. The shaded portion of each table is used for speaker assignment of the channel assignment type.

Table  73- Extended Speaker Allocation Descriptors

Hereinafter, the structure of the ESAD of the third embodiment will be described. Corresponds to the shaded area of the table.

Use the CEA Short Audio Descriptor as defined in CEA861-E. However, it is possible to define a new format that includes some fields included in the CEA short audio descriptor while partially modifying / changing the arrangement or size of the existing fields. This descriptor is included only when transmitting multi-stream audio and, if used, at least one.

Table  74 - Multiple Audio Stream Descriptor

The table below redefines the structure of a multi-stream audio descriptor. Instead of using the CEA Short Audio Descriptor, we use a new descriptor.

The number of channels of multi-stream audio is limited to two. Therefore, the unnecessary channel count field is removed from the descriptor and instead, Max Number of Stream -1 is defined as 2-bit. At this time, Max_Stream_Count-1 defined in the Extended HDMI Audio Data Block PB3 is defined as the maximum value of Max_Stream_Count-1 of each descriptor.

Each table represents a descriptor for each audio format code.

Table  75 - Multiple Audio Stream Descriptor

4.1. 3D audio and multi Stream  For audio application  scenario ( informative )

The following provides application scenarios for 3D audio and multi-stream audio according to the first embodiment described above. These examples illustrate the ability of a sink device to transmit HDMI 2.0 sources and 3D audio and multi-stream audio.

Scenario for 3D Audio

FIG. 13 shows how 3D audio samples can be transmitted from a BDP to a TV. This example assumes the following.

The source (eg BDP) and sink (eg TV) are both HDMI 2.0 compliant devices.

The source sends an L-PCM 48kHz 22.2 channel audio stream to the sink.

The sink can receive L-PCM 48kHz 22.2 channel audio samples and send each individual audio stream to the associated speaker. The video format transmitted is 1080p / 60Hz.

The TV includes a CEA-861-F (also D or E) compliant E-EDID data structure accessible through the DDC. To support 3D audio transmission, the E-EDID includes HDMI audio data blocks in addition to other necessary data blocks. The BDP receives HDMI audio data blocks and recognizes the 3D audio capabilities of the TVs described in Table 76.

Table  76- Example of the HDMI Audio Data Block for  22.2 channels

Byte 1, 2, 3 represent the header of the HDMI audio data block. NUM_HDMI_3D_AD is set to 1 to indicate that 3D audio transmission is supported. NUM_CEA_SAD and Max_Stream_Count-1 are set to 0 because the BDP does not handle multi-stream audio in the scenario.

Bytes 4, 5, 6, and 7 constitute an HDMI 3D audio descriptor that describes the 3D audio characteristics of the TV. The audio format code, maximum number of channels-1, sampling frequency, and sample size are defined.

Bytes 8, 9, 10, and 11 constitute an HDMI 3D speaker allocation descriptor that describes active speakers for 22.2 channels (SMPTE 2036-2).

After receiving the EDID from the TV, the BDP transmits an audio info frame and an audio metadata packet to the TV. In this case, the channel metadata and the channel / speaker allocation information are transmitted using the audio metadata packet instead of the audio info frame.

3D_CC and 3D_CA included in the audio metadata packet describe channel counts, and describe channel / speaker allocation information for 22.2 channel audio streams, respectively. Table 77 shows an example of an audio info frame payload for 22.2 channel audio transmission. Table 78 shows the audio metadata packet payload for 22.2 channel audio transmission.

Table  77 - Example of the Audio InfoFrame payload for  22.2 channels

Table  78- Audio Metadata Packet payload

The BDP transmits 22.2 channel audio samples through a 3D audio sample packet. Each 3D audio sample packet supports up to 8 audio channels, so three consecutive 3D audio sample packets are required to transmit 22.2 channel audio samples. sample_start is used to specify the first 3D audio sample packet. In this example, three 3D audio sample packets can be defined as shown in Table 79 through Table 81.

Table  79 - Example of the first  3D Audio Sample Packet for  22.2 channels

Table  80 - Example of the second  3D Audio Sample Packet for  22.2 channels

Table  81 - Example of the third  3D Audio Sample Packet for  22.2 channels

4.2. Multi Stream  Example scenario for audio

14 shows how multi-stream audio can be transmitted from the BDP to the TV. Assume the following example.

The source (eg BDP) and sink (eg TV) are both HDMI 2.0 compliant devices.

The source / sink enters the dual-view game mode.

The source sends two audio streams for each view.

The sink can send two audio streams to two different headphones.

The transmitted video format is HDMI 3D 1080p / 60Hz.

The TV includes a CEA-861-F (also D or E) compliant E-EDID data structure accessible through the DDC. To support multi-stream audio, the E-EDID may include HDMI audio data blocks in addition to other required data blocks. The BDP receives the HDMI audio data block and recognizes the TV's multi-stream audio capabilities as described in Table 76.

Table  82- Example of the HDMI Audio Data Block for two audio streams

Byte 1, 2, 3 represent the header of the HDMI audio data block. NUM_CEA_SAD is set to 2 because the sink supports two kinds of audio format codes for multi-stream audio. Max_Stream_Count-1 is set to 1 because the sink can handle the two independent audio streams described above. NUM_HDMI_3D_AD is set to 0 because the BDP does not handle 3D audio transmissions in the scenario.

Bytes 4, 5, and 6 constitute the first CEA short audio descriptor describing the audio characteristics. For multi-stream audio transmission, the maximum channel count is limited to two. For this reason, Max Number of channels-1 will be 1.

Bytes 7, 8 and 9 constitute a second CEA Short Audio Descriptor describing the audio characteristics. As mentioned above, the Max Number of channels-1 will be one. The BDP will send an audio info frame to the TV after receiving the EDID from the TV. In contrast to the 3D audio transmission scenario, CC and CA are used to transmit Channel Count and Channel Speaker Allocation information, respectively. In other words, the audio metadata packet will not be used for multi-stream audio transmission. Table 83 shows an example of an audio info frame payload for transmitting two audio streams.

Table  83 - Example of the Audio InfoFrame payload for two audio streams

The BDP sends a multi-stream audio sample packet containing stereo audio samples for two independent audio streams. That is, the first subpacket contains stereo audio samples from the first audio stream and the second subpacket contains stereo audio samples from the second audio stream. In this example, the multi-stream audio sample packet can be defined as shown in Table 84.

Table  84- Example of the Multi - Stream Audio Sample Packet for two  audio streams

3D audio speaker replacement & channel assignment ( informative )

Hereinafter, speaker replacement and channel assignment information for 3D audio transmission are provided.

15 is a diagram illustrating a speaker arrangement for a channel of 3D audio. However, the following table and the contents shown in FIG. 15 are merely exemplary, and speaker and channel allocation may be configured differently.

15 is a diagram illustrating a speaker arrangement for a channel of 3D audio.

In the example shown in Table 85, for the IEC 30.2 channel standard type, FL is the front left speaker, FR is the front right speaker, LFF is the low frequency effect 1 speaker, and FC is the front Front center speaker, BL for back left speaker, BR for back right speaker, FLW for front left wide speaker, FRW for front right wide speaker , TpFL is Top Front Left speaker, TpFR is Top Front Right speaker, BC is Back Center speaker, LS is Left Surround speaker, RS is Right Surround ( Right Surround speaker, LFE2 is the Low Frequency Effect 2 speaker, FLC is the Front Left Center speaker, FRC is the Front Right Center speaker, and TpFC is the Top Front Center speaker, TpC Top Center speaker, SiL is Side Left speaker, SiR is Side Right speaker, TpBL is Top Back Left speaker, TpBR is Top Back Right speaker, TpSiL Is Top Side Left speaker, TpSiR is Top Side Right speaker, BtFC is Bottom Front Center speaker, BtFL is Bottom Front Left speaker, BtFR is bottom Bottom Front Right speaker, TpBC for Top Back Center speaker, TpLS for Top Left Surround speaker, TpRS for Top Right Surround speaker, LSd for left surround direct (Left Surround Direct) speaker, RSd stands for Right Surround Direct speaker, respectively.

However, the names of the speakers may be different according to the type of standard. For example, the front center speaker is referred to as FC in the aforementioned IEC standard, but the TTA standard is referred to as C. Other Various speaker names may exist in addition to those shown in the table below. That is, the following table and the contents shown in FIG. 15 are merely exemplary, and speaker and channel allocation may be configured differently.

However, unlike 2D audio data, 3D audio data having multi-channel support has a common feature in that different speakers are provided for upper, middle, and lower regions of a 3D space. An example of such a spatial arrangement of speakers is depicted in FIG. 15.

Table  85 - Audio Channel Description  & Abbreviation  Comparison ( CEA Of TTA Of SMPTE Of IEC )

5. Data transmission method, data reception method

Hereinafter, a data transmission method and a data reception method complying with the above-described standard will be described with reference to FIGS. 16 to 19.

16 to 19 are flowcharts illustrating a data transmission method and a data reception method according to various embodiments of the present disclosure.

First, referring to FIG. 16, in the data transmission method according to various embodiments of the present disclosure, a packet generation step (S1610) of generating a plurality of packets relating to one multi-channel audio sample data may include generating the plurality of packets. A transmission step (S1620) for transmitting to the receiving device. Each of the generated plurality of packets may include an identification field for identifying a position or order from each other. Since each step has been described above, duplicate descriptions are omitted.

Referring to FIG. 17, in the data receiving method according to various embodiments of the present disclosure, a receiving step (S1710) of receiving a plurality of packets relating to one multi-channel audio sample data transmitted from a data transmitting apparatus and the received A packet parsing step (S1720) for parsing a plurality of packets. Each of the received plurality of packets may include an identification field for identifying a position or order from each other. Since each step has been described above, duplicate descriptions are omitted.

In this case, the identification field may include a predetermined bit indicating whether a packet including the identification field is a start packet of the one multi-channel audio sample data.

Referring to FIG. 18, a data transmission method according to various embodiments of the present disclosure may include receiving a packet including a plurality of subpackets (S1810) and parsing the received packet (S1820). Include. Since each step has been described above, duplicate descriptions are omitted.

Referring to FIG. 19, the data receiving method according to various embodiments of the present disclosure may include receiving a packet including a plurality of subpackets (S1910) and parsing the received packet (S1920). Include. Since each step has been described above, duplicate descriptions are omitted.

In this case, each of the plurality of subpackets may include audio data corresponding to any one of a plurality of contents.

While the present invention has been particularly shown and described with reference to exemplary embodiments thereof, it is clearly understood that the same is by way of illustration and example only and is not to be construed as limiting the scope of the invention as defined by the appended claims. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention.

1000: data transmission and reception system
100: data transmission device
200: data receiving device

Claims (20)

A packet generation unit generating a packet including a plurality of subpackets; And
And a transmitting unit for transmitting the generated packet to a data receiving apparatus,
Each of the plurality of subpackets includes audio data corresponding to any one of a plurality of contents. The method according to claim 1,
And a identification field for indicating which of the plurality of contents each of the plurality of subpackets represents. The method according to claim 1,
The generated packet includes a header,
The header may include a stream present bit indicating whether the subpacket includes the audio data and a stream flat bit indicating whether the audio data included in the subpacket is valid data. And at least one data transmission device. The method according to claim 1,
Each of the plurality of subpackets stores a portion of the audio data. The method according to claim 1,
Wherein the audio data includes:
A data transmission device comprising at least two audio signals. The method according to claim 1,
Wherein the audio data includes:
Data transmission device according to IEC 60958 format. A receiving unit for receiving a packet including a plurality of subpackets; And
And a packet parser configured to parse the received packet.
Each of the plurality of subpackets includes audio data corresponding to any one of a plurality of contents. The method of claim 7, wherein
The header includes a stream present bit indicating whether the sub packet includes the audio data and a stream flat bit indicating whether the audio data included in the sub packet is valid data. Data receiving apparatus comprising at least one of. The method of claim 7, wherein
Each of the plurality of subpackets stores a part of the audio data. The method of claim 7, wherein
Wherein the audio data includes:
A data receiving device comprising at least two audio signals. The method of claim 7, wherein
Wherein the audio data includes:
Data receiving device according to IEC 60958 format. A data transmission device for generating and transmitting a packet including a plurality of subpackets; And
And a data receiving device for receiving and parsing the transmitted packet.
And each of the plurality of subpackets includes audio data corresponding to any one of a plurality of contents. A packet generation step of generating a packet including a plurality of subpackets; And
A transmission step of transmitting the generated packet to a data receiving device;
Each of the plurality of subpackets includes audio data corresponding to any one of a plurality of contents. The method of claim 13,
And a identification field for indicating which of the plurality of contents each of the plurality of subpackets represents. The method of claim 13,
The generated packet includes a header,
The header includes a stream present bit indicating whether the sub packet includes the audio data and a stream flat bit indicating whether the audio data included in the sub packet is valid data. And at least one of the data transmission method. The method of claim 13,
Each of the plurality of subpackets stores a part of the audio data. Receiving a packet including a plurality of subpackets; And
A packet parsing step of parsing the received packet;
Each of the plurality of subpackets includes audio data corresponding to any one of a plurality of contents. The method of claim 17,
The header includes a stream present bit indicating whether the sub packet includes the audio data and a sample flat bit indicating whether the audio data included in the sub packet is valid data. Data receiving method comprising at least one of. The method of claim 17,
Each of the plurality of subpackets stores a part of the audio data. The method of claim 17,
Wherein the audio data includes:
A data receiving method comprising at least two audio signals.

Images