JP7789607B2 - Broadcasting system, receiver, receiving method, and program - Google Patents

Description

The present invention relates to a broadcasting system, a receiver, a receiving method, and a program.

In broadcasting, the use of object-based audio signals such as MPEG-H audio is being considered.
Patent Document 1 describes that an audio signal of an audio object (an object-based audio signal) is treated as a priority signal and is played back with priority.

Japanese Patent Application Laid-Open No. 2021-124719

In Patent Document 1, an audio encoding device encodes an object-based audio signal, and an audio decoding device performs decoding processing on the resulting bitstream.
However, some receivers that receive broadcasts do not have the capability to process object-based audio signals, so it is desirable to be able to perform appropriate audio reproduction depending on the capabilities of the receiver.

The present invention has been made in consideration of the above points, and provides a broadcasting system, receiver, receiving method, and program that can perform appropriate audio playback according to the receiver's capabilities.

(1) The present invention has been made to solve the above-mentioned problems. One aspect of the present invention is a broadcasting system that broadcasts data that includes MPEG-H audio as an audio component, the broadcasting system comprising a receiver that includes a separation unit that acquires, at a multiplexing layer, identification information indicating whether MPEG-H audio is present from the airwaves of the broadcast, a control unit that selects an audio component according to the capabilities of the receiver based on the identification information, and a decoding unit that decodes the audio data of the selected audio component.

(2) Another aspect of the present invention is a receiver comprising: a receiving unit that receives a broadcast that includes MPEG-H audio in its audio component; a separating unit that acquires, at a multiplexing layer, identification information indicating whether MPEG-H audio is present from the airwaves of the broadcast; a control unit that selects an audio component according to the capabilities of the receiver based on the identification information; and a decoding unit that decodes the audio data of the selected audio component.

(3) Another aspect of the present invention is a receiving method in a receiver that receives a broadcast that includes MPEG-H audio in its audio component, acquires identification information indicating whether MPEG-H audio is present or not from the broadcast wave at a multiplexing layer, selects an audio component according to the receiver's capabilities based on the identification information, and decodes the audio data of the selected audio component.

(4) Another aspect of the present invention is a program for causing a receiver computer, which includes a receiving unit that receives broadcasts that include MPEG-H audio in the audio component and an acquisition unit that acquires, at a multiplexing layer, identification information indicating whether MPEG-H audio is present from the airwaves of the broadcast, to execute a selection procedure that selects an audio component according to the receiver's capabilities based on the identification information, and decodes the audio data of the selected audio component.

This invention allows for appropriate audio playback depending on the receiver's capabilities.

1 is a diagram illustrating an example of the configuration of a broadcasting system Sys according to an embodiment of the present invention. 1 is a diagram illustrating an example of a broadcasting system according to an embodiment of the present invention. FIG. 10 is a diagram illustrating a comparative example of a broadcasting system according to the present embodiment. FIG. 2 is a diagram illustrating another example of the broadcasting system Sys according to the present embodiment. 1 is an explanatory diagram illustrating an overview of a broadcasting system Sys according to an embodiment of the present invention. FIG. 2 is a diagram illustrating an example of a protocol stack structure according to the present embodiment. FIG. 2 is a diagram showing the data structure of an MPT according to the present embodiment. FIG. 2 is a schematic diagram illustrating a hardware configuration of a receiver according to the present embodiment. FIG. 4 is a diagram illustrating an example of a list of audio modes according to the embodiment. FIG. 2 is a schematic diagram illustrating an example of a flow of signal processing in a receiver according to the present embodiment. FIG. 4 is a diagram showing an example of an audio switching menu according to the embodiment. A schematic diagram showing an example of the structure of an MH-speech component descriptor in this embodiment. FIG. 2 is a schematic diagram illustrating an example of a transmission operation rule according to the present embodiment. FIG. 2 is a schematic diagram illustrating an example of a reception processing standard according to the present embodiment. 10 is a flowchart illustrating a detailed example of switching according to the present embodiment. 10 is a flowchart illustrating another detailed example of switching according to the present embodiment. FIG. 10 is a schematic diagram showing an example of the structure of an MH-MPEG-H audio descriptor according to this modified example. FIG. 10 is a schematic diagram illustrating an example of a transmission operation rule according to the present modification. FIG. 10 is a schematic diagram illustrating an example of a reception processing standard according to the present modification. FIG. 1 is a schematic diagram showing an example of simultaneous audio operation according to the present embodiment. FIG. 10 is a schematic diagram showing another example of simultaneous audio operation according to the present embodiment.

Embodiments of the present invention will be described in detail below with reference to the drawings.

[System configuration]
FIG. 1 is a diagram showing an example of the configuration of a broadcasting system Sys according to an embodiment of the present invention.
The broadcasting system Sys includes a broadcasting device 1 of a broadcasting station (referred to as "broadcasting station 1"), a relay station Sa, a receiver 2, a broadcasting station server 3, and a carrier server 4. The broadcasting is, for example, terrestrial digital broadcasting, but may also be, for example, advanced BS (Broadcasting Satellites) digital broadcasting or advanced wideband CS (Communication Satellites) digital broadcasting. The present invention is not limited to these broadcasting methods, and the broadcasting may also be broadcasting that does not use a relay station Sa. The broadcasting may also be wired broadcasting such as cable television. The relay station Sa is, for example, a digital relay station, but may also be a broadcasting satellite.

In the broadcasting system Sys, a broadcasting station 1 transmits digital broadcast signals, application control information, presentation control information, etc. via broadcast waves. A service provider provides metadata and video content related to programs from a provider server 4.
The application control information notifies receivers compatible with this system of applications linked to programs, and also sends commands and control information for starting and stopping them.
The control information regarding presentation is transmitted as control information regarding whether or not an application can be presented, and whether or not an application and a broadcast program can be superimposed on the same TV screen.
The broadcast station operates a broadcast station server 3 in the broadcast system Sys. The broadcast station server 3 provides metadata such as program titles, program IDs, program summaries, performers, and broadcast dates and times. The information provided by the broadcast station to the service provider is provided via an API (Application Programming Interface) provided in the broadcast station server 3.

The service provider is a party that provides services through the broadcasting system Sys, and produces and distributes content and applications for the services, and operates the broadcasting station server 3 to realize each individual service. Here, the services include broadcasting and communication integration services that integrate broadcasting and communication.
The broadcast station server 3 "manages and distributes applications" by sending them to the receiver 2. As a "server for each service," the broadcast station server 3 provides server functions for realizing individual services (MPEG-H service, VOD program recommendation service, multilingual subtitle service, etc.).

MPEG-H is a set of standards under development by the ISO/IEC Moving Picture Experts Group (MPEG) for digital container standards, video compression standards, audio compression standards, and two conformance testing standards. MPEG-H audio, for example, enables object-based audio. An "object" in object-based audio is each individual sound element that makes up a program, such as music or human voice. With object-based audio, an audio signal is recorded for each sound element, allowing for audio control for each element. Furthermore, when playing back on receiver 2, it is possible to play back a program based on the actual speaker position, using playback position information for the element.

The broadcast station server 3 not only realizes the functional aspects of these services, but also transmits the content that makes up the services (MPEG-H audio data, VOD content, subtitle data, etc.). As a "repository," the broadcast station server 3 registers applications for the broadcast system Sys for distribution, and provides and searches for a list of available applications in response to inquiries from the receiver 2.

The receiver 2 includes a receiver that has the function to realize broadcasting and communication cooperation services in addition to the function to receive existing digital broadcasts. In addition to the broadband network connection function, the receiver 2 has the following functions.
- A function to execute an application in response to an application control signal from broadcasting - A function to provide presentations through collaboration between broadcasting and communication - A terminal collaboration function Here, the terminal includes, for example, a user terminal such as a smartphone, a smart speaker, etc. The terminal collaboration function of the receiver 2 accesses broadcast resources such as program information in response to requests from other terminals, and invokes receiver functions such as playback control.
Another example of the application is a digital mixer for MPEG-H audio. A user (also called a "receiver") can use the digital mixer received from the provider's server 4 to adjust the volume or effects of the audio signals for each sound material, or to adjust the balance between the sound materials. These adjustments can also be made for each speaker.

More specifically, the receiver 2 has the following functions.
The receiver 2 has a "broadcast reception and playback" function that receives broadcast radio waves, selects a specific broadcast service, and synchronously plays back the video, audio, subtitles, and data broadcast that make up the service.
The receiver 2 has a "communication content reception and playback" function that accesses video content stored on a server on the communication network (e.g., the operator server 4), receives it as VOD streaming, and synchronizes and plays back the video, audio, and subtitles that make up the content.
As an "application control" function, receiver 2 has the ability to act on the application engine, mainly regarding managed applications, based on application control information obtained from a server on the communication network or from a broadcast signal, and to control and manage the life cycle and events on an application-by-application basis.
The receiver 2 has an "application engine" function that acquires and executes applications. This function is realized by, for example, an HTML5 browser.
The receiver 2 has a "presentation synchronization control" function that controls the stream presentation synchronization of video, audio, etc. received by broadcasting and video, audio, etc. received by streaming.
The receiver 2 has an "application launcher" function, which is a navigation function that allows the user to select and launch managed applications outside of broadcasting.

FIG. 2 is a diagram showing an example of a broadcasting system Sys according to this embodiment.
The receiver 2 in FIG. 2 is a receiver compatible with MPEG-H audio.

The broadcasting station 1 multiplexes the video signal and the audio signal and transmits the multiplexed signal, using MMT (MPEG Media Transport) and TLV (Type Length Value) as the multiplexing method.
Broadcasting station 1 generates and transmits an audio signal A11 (also referred to as an "advanced audio signal") that includes both MPEG-4 audio (channel-based audio: e.g., audio 12 to audio 14) signals and MPEG-H audio (object-based audio: audio 11) signals.
In this way, the broadcasting station 1 transmits the MPEG-H audio signal and the MPEG-4 audio signal in parallel.

More specifically, the broadcasting station 1 uses MPEG-H audio as an audio component (asset) and generates an advanced audio signal A11 by multiplexing this audio component with each audio component of MPEG-4 audio. This multiplexing is performed after the audio data strings of each audio component are encoded. The broadcasting station 1 transmits a broadcast wave on which this advanced audio signal A11 is multiplexed.
In the asset information table, the broadcasting station 1 uses a descriptor to indicate whether an MPEG-H audio signal (object-based audio: audio 11) is present (see FIG. 12). The descriptor indicating whether an MPEG-H audio signal is present may be a descriptor indicating whether an advanced audio signal A11 is present, or may indicate whether an MPEG-H audio signal is included.
In MMT, components such as video and audio are defined as assets.

An example of MPEG-H audio 11 is a level 3 signal with a maximum of 11.1 channels, dialogue in Japanese or English, and commentary in Japanese. At level 3, the receiver 2 must be capable of simultaneously decoding 16 channels in addition to processing the MPEG-H signal. Another example of MPEG-H audio 11 is a level 4 signal with a maximum of 22.2 channels, dialogue in Japanese or English, and commentary in Japanese. At level 4, the receiver 2 must be capable of simultaneously decoding 28 channels in addition to processing the MPEG-H signal.
In an example of MPEG-4 audio, audio 12 is 7.1ch Japanese, audio 13 is stereo Japanese, and audio 14 is 7.1ch English. Audio 13 is a simulcast (simultaneous broadcast) of audio 12.

The receiver 2 includes a tuner 211, a Demux (demultiplexer) 22, a selector 231, an audio decoder 232, a mixer 233, and a video decoder 241. The detailed configuration of the receiver 2 will be described later.

The tuner 211 receives broadcast waves via an antenna and tunes (selects) to a channel selected by a user operation. The tuned signal is demodulated and input to the Demux 22 as data.
The Demux 22 separates the input data into a video data string, an audio data string, a superimposed text data string, a subtitle data string, etc. The separated audio data string is output to the selector 231. The separated video data string is output to the video decoder 241.

Here, Demux 22 separates the audio data stream into audio data streams for each audio component: MPEG-H audio 11 and MPEG-4 audio 12, 13, and 14. More specifically, Demux 22 determines whether an MPEG-H audio signal is present using a descriptor in a table describing asset information. If Demux 22 determines that an MPEG-H audio signal is present, and if receiver 2 has MPEG-H audio decoding capabilities, it separates audio 11, audio 12, audio 13, and audio 14 from the advanced audio signal data. If Demux 22 determines that an MPEG-H audio signal is not present, it separates only audio 12, audio 13, and audio 14.

The audio data strings of each audio component output from the Demux 22 are input to the selector 231. The selector 231 selects the audio data strings of the audio components in accordance with user operations or the capabilities of the receiver 2. The capabilities of the receiver 2 include, for example, the number of channels that can be decoded simultaneously, or the type and capabilities of speakers that can be played back. The selector 231 outputs the selected audio data string to the audio decoder 232.
The audio decoder 232 decodes the audio data string of the audio component input from the selector 231 .
If the audio data sequence decoded by the audio decoder 232 is an MPEG-H audio data sequence, the mixer 233 synthesizes the audio for each sound material and performs downmixing. The downmixed audio data sequence is converted into audio and output from a speaker. If the audio data sequence decoded by the audio decoder 232 is an MPEG-4 audio data sequence, the audio data sequence is converted into audio and output from a speaker. In other words, audio synthesis for each sound material and downmixing are not performed on MPEG-4 audio data sequences.

The video data stream output from the Demux 22 is input to the video decoder 241 .
The video decoder 241 decodes the input video data string. The decoded video data string undergoes color space conversion processing as necessary and is used to display the video on a display. The superimposed text data string and subtitle data string separated by the Demux 22 are decoded by a superimposed text decoder and subtitle decoder (not shown), respectively, and the decoded character strings are superimposed on the video.

As described above, the receiver 2 according to this embodiment obtains information indicating the presence of an MPEG-H audio signal at the multiplex layer in a broadcast that includes MPEG-H audio (sound) in the audio component. The receiver 2 selects an audio component according to its own capabilities, allowing appropriate audio playback according to the receiver 2's capabilities.

FIG. 3 is a diagram showing a comparative example of the broadcasting system Sys according to the present embodiment.
This diagram shows an example in which broadcasting station C1 transmits only MPEG-H audio, which is not multiplexed with MPEG-4 audio.
In this example, MPEG-H audio is used as the only audio component. Therefore, the table describing asset information does not include a descriptor indicating whether an MPEG-H audio signal is present. In this case, Demux C22 can acquire MPEG-H audio as an audio component (audio configuration), but cannot determine whether it can be processed (level, etc.). The audio data string output from Demux C22 is decoded by audio decoder C232 and output to mixer C233.

In contrast to the comparative example in Figure 3, the broadcasting station 1 in this embodiment transmits MPEG-H audio signals and MPEG-4 audio signals in parallel. The receiver 2 first determines whether an MPEG-H audio signal is present by checking the descriptor, and then selects either MPEG-H or MPEG-4 audio depending on its audio decoding capabilities.
This allows the receiver 2 to play back audio in the appropriate format, either MPEG-H or MPEG-4, depending on the capabilities of the receiver 2 itself.

4 is a diagram showing another example of the broadcasting system Sys according to this embodiment, in which the receiver 2 is not compatible with MPEG-H.
The receiver 2 in this figure includes a tuner 211, a Demux 22a, a selector 231a, an audio decoder 232a, and an audio decoder 241. In this figure, the same functional units as those in the receiver 2 in Figure 3 are denoted by the same reference numerals, and their description will be omitted.

The Demux 22a separates the input data into a video data string, an audio data string, a superimposed text data string, a subtitle data string, etc. The separated audio data string is output to the selector 231a. The separated video data string is output to the video decoder 241.
Here, the Demux 22a separates the audio data stream into MPEG-4 audio 12, 13, and 14, and audio data streams for each audio component. More specifically, the Demux 22a determines whether an MPEG-H audio signal 11 exists based on a descriptor in a table describing asset information. The Demux 22a determines that the MPEG-H audio signal 11 cannot be played.
The Demux 22 separates the audio 12 , audio 13 , and audio 14 from the data of the audio signal A11.
Note that such signal selection (selection of an MPEG-4 audio signal or selection of a simulcast of only an MPEG-4 audio signal) may be performed by the selector 231 .

FIG. 5 is an explanatory diagram illustrating an outline of the broadcasting system Sys according to this embodiment.
In the broadcasting system Sys, the broadcasting station 1 is configured to include an MPEG-H encoder 11, MPEG-4 encoders 111 to 113, and a Mux (multiplexer) 12. The broadcasting station 1 also has other functional units necessary for broadcasting. Although this diagram shows an example of three MPEG-4 encoders, the broadcasting station 1 may be equipped with two or fewer MPEG-4 encoders, or may be equipped with four or more MPEG-4 encoders.

Receiver 2 is composed of Demux 22, selector 231, MPEG-H audio core decoder 232-1, MPEG-4 decoder 232-2, MPEG-H audio renderer 233-1, and mixer 233-2. In this figure, functional units that are the same as those in receiver 2 in Figure 2 are assigned the same reference numerals. Note that MPEG-H audio core decoder 232-1 and MPEG-4 decoder 232-2 correspond to audio decoder 232 in Figure 2. MPEG-H audio renderer 233-1 and mixer 233-2 correspond to mixer 233 in Figure 2.

At broadcast station 1, background sound (22.2ch/11.1ch), dialogue (Japanese), dialogue (English), and commentary audio (Japanese) data are input to MPEG-H encoder 11 as MPEG-H audio material. Furthermore, 7.1ch audio including Japanese dialogue, stereo audio including Japanese dialogue, and stereo data including English dialogue are input to MPEG-4 encoders 111, 112, and 113, respectively, as MPEG-4 audio material.

The MPEG-H encoder 11 encodes the input audio and outputs an MPEG-H audio stream St1. This stream is also called an MPEG-H 3D audio stream.
The MPEG-4 encoders 111, 112, and 113 encode the input audio and output MPEG-4 audio streams St2, St3, and St4, respectively.

Mux 12 receives the video stream, SI (Signaling Information), MPEG-H audio stream St1, and MPEG-4 audio streams St2, St3, and St4. Mux 12 multiplexes this data. The multiplexed data is modulated, and the modulated signal is broadcast as a broadcast wave.

The broadcast waves received by receiver 2 are demodulated, and the demodulated data is input to Demux 22. Demux 22 separates the input data into a video stream, SI, MPEG-H audio stream St1, and MPEG-4 audio streams St2, St3, and St4. MPEG-H audio stream St1 and MPEG-4 audio streams St2, St3, and St4 are input to selector 231. A descriptor indicating whether an MPEG-H audio signal is present is extracted from the MMT Package Table (MPT) of SI.

The selector 231 determines whether an MPEG-H audio signal is present based on the extracted descriptor, and if an MPEG-H audio signal is present, the selector 231 outputs the MPEG-H audio stream St1 to the MPEG-H audio core decoder 232-1.
The selector 231 outputs the MPEG-4 audio stream St2, St3 or St4 to the MPEG-4 decoder 232-2 based on the MPT.

The MPEG-H audio core decoder 232-1 extracts data of background sounds (22.2ch/11.1ch), dialogue (Japanese), dialogue (English), and commentary audio (Japanese) by decoding the MPEG-H audio core decoder 232-1.
The MPEG-H audio renderer 233 - 1 is an audio renderer for MPEG-H audio, and renders (including down-converting or up-converting) the audio data extracted by the MPEG-H audio core decoder 232 - 1 and outputs it to the mixer 233 .
The MPEG-4 decoder 232-2 decodes the MPEG-4 audio stream St2, St3, or St4 to extract 7.1ch audio including Japanese dialogue, stereo audio including Japanese dialogue, and stereo data including English dialogue, and outputs this to the mixer 233.
The mixer 233-2 synthesizes the audio of the input data, and the synthesized audio is output from each speaker or headphone.

[Regarding broadcast wave control information]
The broadcast wave according to this embodiment will be described.
In broadcast waves, control information is superimposed on the TLV stream, which is the broadcast signal, by each broadcaster and transmitted. The control information includes TLV-SI (TLV-Signaling Information) related to the TLV multiplexing method and MMT-SI (MMT-Signaling Information) related to MMT, a media transport method.
In the following, a (video or audio) "component" is also referred to as an "asset."

<Protocol stack structure of a system using MMT>
An example of the structure of a protocol stack in which control information is arranged in a system using MMT will be described.
FIG. 6 is a diagram showing an example of the structure of a protocol stack according to this embodiment.
As shown in this diagram, the protocol stack used in the broadcasting system includes TMCC (Transmission and Multiplexing Configuration Control), time information, encoded video data, encoded audio data, encoded subtitle data, MMT-SI, an application (also simply referred to as an app) written in HTML5 standard, EPG (Electronic Program Guide), content download data, etc. The codes for the video and audio signals of the broadcast program are MFU (Media Fragment Unit)/MPU. The MFU/MPU is then placed on an MMTP payload and packetized by broadcast station 1 into MMTP packets, which are then transmitted by broadcast station 1 in IP packets. For transmission of data content, the data is packetized by broadcast station 1 into MMTP packets, which are then transmitted by broadcast station 1 in IP packets. When the IP packets configured in this way are broadcast using a broadcast transmission path, they are transmitted by broadcast station 1 in the form of TLV packets. One IP packet or one header-compressed IP packet is transmitted by the broadcasting station 1 in one TLV packet.

Furthermore, the protocol stack used in the broadcasting system provides two types of control information: MMT-SI and TLV-SI. MMT-SI is control information that indicates the structure of a broadcast program, etc. MMT-SI is formatted as an MMT control message, placed in an MMTP payload by broadcast station 1, and converted into MMTP packets, which are then transmitted by broadcast station 1 in IP packets. TLV-SI is control information related to multiplexing IP packets, and provides information for channel selection and information on the correspondence between IP addresses and services.

TMCC is control information inserted into a transmission frame for transmission in a hierarchical modulation method that specifies a modulation method and an error correction method for each unit (slot) of a signal on a transmission path. HEVC (High Efficiency Video Coding) is a method for encoding video signals. AAC (Advanced Audio Coding) and ALS (Audio Lossless Coding) are methods for encoding audio signals. UDP/IP (User Datagram Protocol/Internet Protocol) is one of the protocols used in communication. TLV (TYPE LENGTH VALUE) is one of the data multiplexing methods.
TLV is composed of three parts for encoding data: data type (Type), length (Length), and value (Value).

<Message types and identification>
MMT-SI includes messages, tables, and descriptors.
The messages include a Package Access (PA) message, an M2 section message, a CA message, an M2 short section message, a data transmission message, and a message set by the operator.
The MMT-SI messages used in broadcasting are as follows:

The "PA message" carries the PLT and MPT to indicate the entry point of the service.
The "M2 Section Message" transmits the section extension format of the MPEG-2 Systems.
The "CA message" transmits information about the conditional access method.
The "M2 Short Section Message" transmits the section short format of the MPEG-2 Systems.
The "data transmission message" transmits a table relating to data transmission.

<Table types and identification>
The TLV-SI table used in broadcasting is as follows:

"TLV-NIT (Network Information Table for TLV)" transmits information that associates transmission path information, such as modulation frequency, with broadcast programs in transmission by TLV packets.
The "AMT (Address Map Table)" transmits information that associates a service identifier that identifies a broadcast program number with an IP packet.
"MPT (MMT Package Table)" provides information that configures a package, such as a list of assets and their locations.
"PLT (Package List Table)" indicates a list of packet IDs that transmit PA messages including MPTs of services provided as broadcast services.
An "ECM (Entitled Control Message)" transmits common information consisting of program information (information about the program and a key for descrambling, etc.) and control information (a forced on/off command for the decoder's scrambling function).

"EMM (Entity Management Message) transmits individual information including contract information for each subscriber and a work key for decrypting common information.
"CAT (MH) (Conditional Access Table)" specifies the packet identifier of an MMTP packet that transmits individual information among the related information that constitutes the conditional access broadcast.
The "MH-EIT (MH-Event Information Table)" transmits information about the program, such as the program name, broadcast date and time, and a description of the content.
The "MH-AIT (MH-AppLication Information Table)" transmits dynamic control information related to an application and additional information required for execution.
"MH-BIT (MH-Broadcaster Information Table)" is used to present information about broadcasters present on the network.

"MH-SDTT (MH-Software Download Trigger Table)" transmits notification information such as the download service ID, schedule information, and the type of receiver to be updated.
The "MH-SDT (MH-Service Description Table)" transmits information about the organized channels, such as the names of the organized channels and the names of the broadcasting companies.
The "MH-TOT (MH-Time Offset Table)" transmits the current date and time, and the difference between the actual time and the time displayed to the human system.
The "MH-CDT (MH-Common Data Table)" transmits data that is commonly required by receivers, such as company logos, and is intended to be stored in non-volatile memory.
The "DDMT (Data Directory Management Table)" provides a directory structure of the files that make up an application.

"DAMT (Data Asset Management Table)" provides the configuration of MPUs in an asset and version information for each MPU.
The "DCCT (Data Content Configuration Table)" provides configuration information of a file as data content.
The "EMT (Event Message Table)" is used to transmit information about event messages.

<MMT Package Table>
The MPT (MMT Package Table) provides information that constitutes a package, such as a list of assets and their locations on the network.
FIG. 7 is a diagram showing the data structure of the MPT according to this embodiment.
"tabLe_ID" (table identifier) is an 8-bit field that identifies each table.
"Version" is an area where the version number of the table is written.
"Length" (table length) is an area in which the number of data bytes following this field is written.

"MMT_package_ID_Length" indicates the length of the package ID byte in bytes.
"MMT_package_ID_byte" indicates a package ID, which is the same value as the service ID for identifying the service.
"MPT_descriptors_Length" indicates the length of the MPT descriptor area in bytes.
"MPT_descriptors_byte" (MPT descriptor area) is an area that stores the MPT descriptors.
If the program is a multi-view program, the descriptor area of the MPT includes an MH-component group descriptor (MH-Component_Group_Descriptor()). On the other hand, if the program is not a multi-view program, the descriptor area of the MPT does not include an MH-component group descriptor.
"Number of assets" indicates the number of assets for which this table provides information.
"IDentifier_type" (identifier type) indicates the ID system of the MMTP packet flow. If it is an ID system indicating an asset ID, a specific value (0x00) is set.

The MPT has an area that describes each of one or more assets. This area stores the following fields for each asset:
"Asset_ID_scheme" (asset ID format) indicates the format of the asset ID. For "asset_ID", the receiver 2 uses the component_tag value in the receiving operation. The receiver 2 uses the component_tag value to identify the asset.
"Asset_ID_length" indicates the length of the asset ID bytes in bytes.
"Asset_ID_byte" (asset ID byte) indicates the asset ID.

"Asset_type" indicates the type of asset.
The asset type may be, for example, hcv1, which indicates video data encoded using HEVC, mp4a, which indicates audio data encoded using MPEG-4 audio, or mha1, mha2, mhm1, or mhm2, which indicates audio data encoded using MPEG-H audio.

"Asset_clock_relation_flag" (clock information flag) indicates whether or not the asset has a clock information field.
"Location_count" indicates the number of location information items for an asset.
"MMT_general_location_info" (location information) indicates the location information of the asset.
"Asset_descriptors_length" indicates the total byte length of the subsequent descriptors.
"Asset_descriptors_byte" (asset descriptor area) is an area for storing asset descriptors.

<Descriptor types and identification>
The TLV-SI descriptors used in broadcasting are as follows:
The "Service List Descriptor" is a description of a list of programming channels and their types.
"Satellite Delivery System Descriptor" is a description of the physical conditions of a satellite transmission path.
The "System Management Descriptor" is an identification such as broadcast/non-broadcast.
"Network Name Descriptor" is a description of the network name.

The MMT-SI descriptors used in broadcasting are as follows:
The "remote control key descriptor" uniquely provides a service for assigning to one-touch keys on the receiver's remote control (remote controller).
The "asset group descriptor" provides the group relationship of assets and their priority within the group.
The "MPU timestamp descriptor" provides the presentation time of the MPU.
The "access control descriptor" identifies the conditional access method.
The "Scrambling Scheme Descriptor" identifies the scrambling subsystem.
The "Emergency Information Descriptor (MH)" provides a description of the necessary information and functions as an emergency alert signal.
The "MH-Event Group Descriptor" describes grouping information for multiple events.
The "MH-service list descriptor" describes a list of organized channels and their types.
The "MH-short event descriptor" describes the program name and a brief description of the program.
The "MH-extended event descriptor" describes detailed information about a program.

The "video component descriptor" describes parameters, explanations, etc. relating to the video signal among the program element signals.
The "MH-Stream Identification Descriptor" is used to identify individual program element signals.
The "MH-Content Descriptor" describes the program genre.
The "MH-Parental Rate Descriptor" describes the age limit for viewing.
The "MH-audio component descriptor" describes parameters relating to audio signals among program elements.
The "MH-target area descriptor" describes the target area.
The "MH-series descriptor" describes series information spanning multiple events.
The "MH-SI transmission parameter descriptor" describes the parameters of SI transmission (such as periodicity group and retransmission period).
The "MH-broadcaster name descriptor" describes the broadcaster name.
The "MH-service descriptor" describes the name of the channel and the name of its operator.

The "MH-Data Encoding Descriptor" is used to identify the data encoding method.
The "UTC-NPT reference descriptor" conveys the relationship between the NPT and the UTC.
The "Event Message Descriptor" conveys information about the event message in general.
The "MH-local time offset descriptor" describes the difference in time between the actual time and the time displayed to the human system when daylight saving time is in effect.
The "MH-logo transmission descriptor" describes a simple logo character string, pointing to a CDT format logo, and the like.
The "MPU extended timestamp descriptor" provides the decoding time of the access unit within the MPU, etc.
The "MPU download content descriptor" describes attribute information of content downloaded using the MPU.
The "MH-Application Descriptor" describes information about an application.
The "MH-transmission protocol descriptor" specifies the transmission protocol and describes the location information of the application depending on the transmission protocol.
The "MH-Simple Application Location Descriptor" describes in detail where the application is obtained.

The "MH-application boundary authority setting descriptor" describes the application boundary setting and the broadcast resource access authority setting for each area (URL).
The "link destination PU descriptor" describes information about the link destination presentation unit.
The "application service descriptor" describes entry information of the application related to the service.
The "MPU node descriptor" indicates that the MPU corresponds to a directory node defined in the data directory management table.
The "PU configuration descriptor" indicates a list of MPUs that make up a presentation unit.
The "MH-Hierarchical Coding Descriptor" describes information for identifying a hierarchically coded video stream component.

The "content copy control descriptor" is placed when indicating control information related to digital copying for the entire service or when describing the maximum transmission rate.
The "content usage control descriptor" is used to describe control information related to storage and output for the program. It is also used to specify whether or not "number-limited copying" is to be applied to the program or asset.
The "associated broadcaster descriptor" indicates the identification value of the broadcaster of the BS/broadband CS digital broadcasting and the affiliate of the terrestrial digital broadcasting required for accessing the NVRAM.
The "multimedia service information descriptor" describes detailed information about each content of a multimedia service, such as whether or not there is data content or subtitles.
The "emergency news descriptor" indicates that an emergency news flash (emergency earthquake alert, special news, super flash news) related to safety and security is currently being broadcast.
The "MH-CA contract information descriptor" describes information that confirms that a service or event can be reserved.
The "MH-CA service descriptor" indicates the organization channel of the business entity that operates the automatic display message, and describes the display control information of the message.

<MH-Speech Component Descriptor Location>
The "MH-Speech Component Descriptor" is arranged in the following table.
MPT (Asset Descriptor Area)
・MH-EIT[p/f actual] (MH-EIT[p/f])
・MH-EIT[schedule actual basic] (MH-EIT[schedule basic])

The "MPT" is stored in the "PA message."
"MH-EIT[p/f]" is time-series information about the current and next events, the former being called "present" and the latter being called "following."
"MH-EIT[p/f actual]" and "MH-EIT[schedule actual basic]" are tables that describe events included in the service operated by the own TLV stream, and are stored in the "M2 section message."

The "MH-AIT" is also a table that indicates control information that indicates the application lifecycle, constraints, etc. "MMT" is a multiplexing method that enables integrated transmission over multiple transmission paths. "MP4 AAC " is an audio encoding method defined by ISO/IEC 14496-3. "MP4 ALS" (ALS: Audio Lossless Coding) is an audio lossless encoding method defined by ISO/IEC 14496-3. "MPT" is an abbreviation for MMT Package Table. "MPT" is a table that provides information that constitutes a service (package), such as a list of assets and their locations. It has elements and attributes that indicate specific information. "Tables" are stored in messages and transmitted in MMTP packets. The messages that store "tables" are determined according to the table. "Package" refers to a unit of content in the MMT standard. "Messages" store tables and descriptors. The message is stored in an MMTP payload and transmitted using an MMTP packet.

"SI information" is also information that describes the contents of the multiplexed information, identification information, etc. Receiver 2 is, for example, a "terrestrial digital broadcasting receiver" that has the functions of selecting and demodulating a receiving channel from the IF signal, selecting and decoding a desired program, and outputting a baseband signal. However, receiver 2 may also be an "advanced BS digital broadcasting receiver," in which case, in addition to having these functions, it is a device that can receive advanced BS digital broadcasting in the frequency band of 11.7 GHz to 12.75 GHz. Receiver 2 is also called an STB or IRD.
An "item" is the smallest unit of transmission that constitutes an MPU in application data transmission based on the MMT transmission method. An "item" corresponds to a file. An "MPU" is a transmission unit that is comprised of a collection of items contained within one component. It is expected that an "MPU" will be operated in correspondence with a presentation unit (PU), an update unit, or an accumulation control unit.

A "component" (asset) is a unit that has the same packet ID in one IP data flow. In MPT, it is referred to as an asset. A "component" is identified by a component_tag, which will be described later.
The application set to be transmitted is switched depending on the data event. An "asset" is a transmission unit for video, audio, etc. multiplexed using the MMT method. An "asset type" indicates the type of content being transmitted in each asset. "Simultaneous audio" is the simultaneous transmission of multiple different audio modes within the same event. An "event" is a collection of streams with fixed start and end times within the same service (programming channel), such as news or drama.

[Hardware configuration of receiver 2]
FIG. 8 is a schematic diagram showing the hardware configuration of the receiver 2 according to this embodiment.
The receiver 2 is configured to include a tuner 211, a demodulator 212, a separator 22, a selector 231, an audio decoder 232, a speaker 234, a video decoder 241, a presentation processor 242, a display 243, an input/output device 251, an auxiliary storage device 252, a ROM (Read Only Memory) 253, a RAM (Random Access Memory) 254, a CPU (Central Processing Unit) 255, and a communication chip 256.
The demodulator 212, the separator 22, the selector 231, the audio decoder 232, and the speaker 234 are also referred to as an audio processing unit M. Note that the configuration for processing data (for example, the separator 22, the selector 231, the audio decoder 232, the video decoder 241, and the presentation processor 242) may be realized by software (arithmetic processing by the CPU 255).
8, the hardware components corresponding to the components of the receiver 2 in FIG. 2, FIG. 4, or FIG. 5 are assigned the same numbers as those assigned to the components in FIG. 2, FIG. 4, or FIG.

A digital broadcast signal received by an antenna is input to the receiver 2 via an input terminal, converted into a TLV stream by a tuner 211 and a demodulator 212, and separated into video, audio, other assets, and various MMT message tables through a TLV/MMT separation process by a separator 22. The scrambled assets are decoded by a descrambler using the key obtained by processing the EMM/ECM extracted by the TLV/MMT separation process in a CAS module (not shown). The video assets are decoded by a video decoder 241 and output after processing to present text and graphics images. The audio assets are decoded by an audio decoder 232 and then output. Regarding video and audio output, the receiver itself may be equipped with video and audio output means (display 243 and speaker 234), or may be equipped with a digital video and audio output that outputs decoded video and audio signals to an external device, or a digital audio output that outputs only audio to an external device. A high-speed digital interface may also be provided.
The receiver 2 may also be provided with a storage means such as an auxiliary storage device 252 (HDD, etc.) inside it, providing a broadcast storage function. The receiver 2 has the following memories: RAM 254 used by receiver applications such as EPG and multimedia services, auxiliary storage device 252 (non-volatile memory: NVRAM, etc.) for storing service logo data and EPG data, and ROM 253 (NVRAM can be used as a substitute) for storing fonts, etc.

The separator 22 determines whether an MPEG-H audio signal is present based on a descriptor in a table describing asset information. The MPEG-H audio signal includes an MPEG-H audio asset (also referred to as an "MPEG-H audio asset").
If the separator 22 determines that an MPEG-H audio signal is present, and if the receiver 2 has MPEG-H audio decoding capability, it separates each of the MPEG-H audio assets and one or more MPEG-4 audio assets (MPEG-4 assets) from the data of the MPEG-H audio signal. If the separator 22 determines that an MPEG-H audio signal is not present, it separates each of the one or more MPEG-4 audio assets from the data of the MPEG-4 audio signal.

<Input terminal, tuner, demodulator>
The receiver 2 has two types of terminals for inputting digital broadcast signals: an IF input and an optical input. However, the receiver does not necessarily have to have the IF input but not the optical input.
The tuner 211 corresponds to a right-hand circular band IF frequency, a left-hand circular band IF frequency, or both.
Demodulator 212 performs front-end signal processing.

<Separator/Video Decoder>
The TLV/MMT separation process by the separator 22 consists of two processes: TLV separation and MMT separation. In broadcast transmission, the receiver 2 has the ability to simultaneously process at least 12 assets per service. The receiver 2 may handle up to 22 assets per service. Video assets may be split-screen encoded. Furthermore, the receiver 2 may not have a built-in video decoding process, but may instead be equipped with a function for streaming via a high-speed digital interface. The receiver 2 may output HDR (High Dynamic Range) video to an SDR (Standard Dynamic Range) compatible display. The video switching receiver 2 based on video transfer characteristics monitors the vIDEo_transfer_characteristics value of the video component descriptor and identifies the transfer characteristics of the received video signal.

<Audio decoder>
In a receiver 2 that has downmix processing for an external pseudo surround processor and downmix processing for stereo sound field expansion added as options, the presentation processing unit 242 displays the downmix setting status on the display 243. This allows the receiver to understand the setting status.
If the receiver 2 is equipped with a digital audio output for an MPEG-4 AAC (Advanced Audio Coding) audio stream, it outputs the audio in a format multiplexed in accordance with the AAC extension and the LATM/LOAS (Low-overhead MPEG-4 Audio Transport Multiplex/Low Overhead Audio Stream) broadcast format.If the receiver 2 is equipped with a digital audio output for an MPEG-4 ALS audio stream, it outputs the audio in accordance with the ALS extension and the LATM/LOAS (Low Overhead Audio Stream) broadcast format.

<Output terminal>
The following describes a digital video and audio output terminal and a digital audio output terminal as output terminals provided on the receiver 2. However, the receiver 2 may be equipped with a high-speed digital interface instead of these output terminals.
Note that the receiver 2 having a built-in display device does not need to be equipped with a digital video and audio output terminal. In the case of a receiver 2 that does not have a display device (display 243) such as an STB, the receiver 2 is equipped with an HDMI (registered trademark, the same applies hereinafter) terminal, a terminal for MHL/super MHL output, or a terminal for wireless digital video and audio output function as the digital video and audio output terminal.

The receiver may be equipped with an optical digital audio output terminal or a coaxial digital audio output terminal as a digital audio output terminal. It may also be equipped with an HDMI terminal and have a digital audio output function using the HDMI Audio Return Channel (HDMI-ARC) defined in HDMI 1.4.
When an MPEG-4 AAC audio stream is output to the digital audio output terminal, it must conform to the AAC extension, but the output of 22.2ch multi-channel audio may be TBD. When an MPEG-4 ALS audio stream is output to the digital audio output terminal, it must conform to the ALS extension, but the output of the MPEG-4 ALS stream may be TBD.

NVRAM is used as memory for downloading receiver software and data common to all receivers, as well as downloading data transmitted using the MH-CDT system, such as logo data. NVRAM stores data types, data common to all receivers (genre code table, program characteristic code table, reserved word table), logo data, multimedia services, received emails, and, for example, MPEG-H audio digital mixers.

[Audio asset selection and switching process]
FIG. 9 is a diagram showing an example of a list of audio modes according to this embodiment.
In broadcasting, the audio modes shown in Figure 9 are used. Of these, the three that need to be decoded by the receiver 2 alone are MPEG-4 AAC1ch (only used in advanced wideband CS digital broadcasting), AAC2ch, and AAC5.1ch (2ch downmix processing possible). Audio assets of other modes may not be decoded within the receiver 2 but may be output in stream format to an external amplifier and decoded by the external amplifier. On the other hand, assuming a case where a program using an audio mode other than AAC1ch, AAC2ch, or AAC5.1ch as the main audio is received by a receiver 2 that is not connected to an external amplifier, when audio other than these three modes is broadcast, simulcast audio that can be decoded by all receivers 2 is broadcast simultaneously using different audio assets.

For example, if the audio codec is "MPEG-H," any of MPEG-4 AAC 1ch, 2ch, and 5.1ch will be broadcast simultaneously using different audio assets as a simulcast audio combination. An audio mode may include multiple MPEG-H audio assets, and in this case, different audio assets may include MPEG-H audio assets of different levels. For example, when an audio mode with a high level (Level 3) is broadcast, simulcast audio of an audio mode with a lower specific level (e.g., Levels 1 and 2: levels with fewer channels) may be broadcast simultaneously using different audio assets.
This means that when MPEG-H of a particular level (e.g., level 3) is broadcast, even a receiver 2 that only supports a lower level (e.g., level 2) can play MPEG-H audio by selecting the audio asset of that lower level.

A receiver 2 that is not connected to an external amplifier selects one asset to output sound from among these multiple audio assets and outputs it to an audio output (such as a speaker 234). The asset to be output can be selected arbitrarily by the receiver, or the receiver 2 automatically selects an asset of a compatible audio mode. In the case of automatic selection, priority is basically given to an asset with a smaller component tag value among assets of a compatible audio mode, but the decision may be changed depending on the selection status of language or audio type (such as commentary audio).
The receiver 2 may automatically select an MPEG-H asset by minimizing the component tag value of the MPEG-H asset. Conversely, the receiver 2 may automatically select an MPEG-4 asset by minimizing the component tag value of the MPEG-4 asset. If an MPEG-H asset is present and an MPEG-4 asset is selected, the receiver 2 may display a message indicating that an MPEG-H asset is present.

<Signal processing flow in the audio processing unit M>
FIG. 10 is a schematic diagram showing an example of the flow of signal processing in the receiver according to this embodiment.
This diagram shows an example of the audio processing unit M. The audio processing unit M includes a demodulation unit 212, a TLV/MMT separation unit 22, an audio asset selection unit 231, a decoder unit 232, a mixer unit 2331, a downmixer (DMIX) unit 2332, a switch (SW) unit 2333, a DAC (Digital-Analog Converter) unit 2334, and an external output I/F (interface) unit 251.
10, the components corresponding to the components of the receiver 2 in Fig. 2, 4, or 5 are denoted by the same numbers as those used for the components in Fig. 2, 4, or 5. The mixer unit 2331, downmixer unit 2332, switch unit 2333, and DAC unit 2334 correspond to the mixer 233 in Fig. 2.

This diagram shows the flow of audio signal processing within the receiver 2. The receiver 2 extracts multiple audio assets via the TLV/MMT separation processing unit 22. The audio asset selection unit 231 selects the audio asset to be output from these, and the decoder unit 232 decodes and outputs the audio. Here, the audio asset selected by the audio asset selection unit 231 is input to the decoder unit 232, which decodes it according to its audio mode (audio codec).

The switch unit 2333 selects an asset suitable for an external AV amplifier from among a plurality of audio assets, and outputs the asset to the decoder unit 232 and the external output I/F unit 251 .
The decoder unit 232 decodes the audio asset according to the input audio asset. If the decoded data sequence is an MPEG-H data sequence, that is, if the audio asset is an MPEG-H audio asset, the decoder unit 232 outputs the data sequence to the mixer unit 2331. If the decoded data sequence is a 5.1ch PCM data sequence, the decoder unit 232 outputs the data sequence to the downmixer unit 2331. If the decoded data sequence is a 2ch PCM data sequence, the decoder unit 232 outputs the data sequence to the switch unit 2333.
The mixer unit 2331 performs downmixing processing on the input data stream by synthesizing the audio for each sound material in the MPEG-H audio asset. The downmixer unit 2331 performs downmixing processing to convert the input data stream into 2-channel PCM data. The downmixed data stream is output to the switch unit 2333.
The switch unit 2333 outputs a data string to the DAC unit 2334 or the external output I/F (interface) unit 251 in accordance with an instruction based on the control information from the audio asset selection unit 231. The DAC unit 2334 converts the input data string into an analog audio signal and outputs it to the speaker 234.

<Audio switching menu>
FIG. 11 is a diagram showing an example of the audio switching menu according to the present embodiment.
The audio switching menu F81 is an example of an audio switching menu displayed on a receiver 2 that supports MPEG-H. The audio switching menu F82 is an example of an audio switching menu displayed on a receiver 2a that does not support MPEG-H. The audio switching menu F81 is also an example of an audio switching menu that is displayed on a receiver 2a that supports MPEG-H when MPEG-H audio assets are present (when MPEG-H audio assets and MPEG-4 audio assets are present). The audio switching menu is a menu for selecting one of the audio types of simulcast audio. When an MPEG-H audio asset is selected, the receiver 2 may separate audio types in different languages from a single asset and display them again in the audio switching menu.

The audio type F811 is an audio type for selecting MPEG-H audio. The two audio types F812 are audio types for selecting Japanese as the language and MPEG-4, 5.1ch, or 2ch audio. The audio type F813 is an audio type for selecting English as the language and MPEG-4, 5.1ch, or 2ch audio.
Note that a receiver 2 that supports 5.1ch may or may not display the audio type for selecting 2ch. Furthermore, the audio type uses the audio notation described in the text_char field of the MH-audio component descriptor. If multiple languages exist in an MPEG-H audio asset, multiple audio types (audio notation) may be described in the text_char field. If the audio is MPEG-H, the language may not be selected on the menu screen. In this case, for example, audio type F811 is the audio type for selecting MPEG-H audio.

MH-Speech Component Descriptor
FIG. 12 is a schematic diagram showing an example of the structure of the MH-speech component descriptor according to this embodiment.
The MH-Audio Component Descriptor describes each parameter of an audio elementary stream in an asset and is also used to express the elementary stream in text format. MPEG-4 audio is multiplexed as an audio elementary stream for each audio configuration (e.g., language, number of channels). MPEG-H audio includes various audio configurations in one audio elementary stream.

In the MH-Speech Component Descriptor, the meaning of each field is as follows:
"Descriptor_tag" describes a fixed value indicating that it is an MH-audio component descriptor.
"descriptor_length" describes the descriptor length of the MH-audio component descriptor.

"nga_profile_level" (field F91) indicates whether or not an MPEG-H audio asset exists (whether or not MPEG-H audio exists). If MPEG-H exists, it indicates its profile and level.
A profile represents a set of functions defined for a specific purpose. There are two types of profiles: "Basic Profile" and "Low Complexity Profile" (LC). LC is a standard profile. A "Baseline Profile" is an LC with specific functions omitted. There may be three or more types of profiles. A level represents processing capability and is information corresponding to the processing capability. The level may correspond to, for example, the processing load or the amount of memory used, but may also correspond to the number of channels. A pair of profile and level may specify, for example, the performance of a device or the performance required to decode a bitstream.

"stream_content" is set to a specific value (0x03) for MPEG-4 AAC audio streams, and a different value (0x04) for MPEG-4 ALS audio streams. Note that an even different value (e.g., 0x05) may be set for MPEG-H audio streams.

"component_type" specifies the type of audio component, with 8 bits (b7-b0) defined as b7: dialogue control, b6-b5: audio for disabled people, and b4-b0: audio mode. Note that "component_type" may have an increased number of bits, and a value (e.g., b8) may be added, and the added value may be defined as MPEG-H.
"component_tag" is a label for identifying a component stream, and has the same value as the component tag in the MH-stream identification descriptor.
"Stream_type" describes a fixed value indicating the LATM/LOAS stream format.

The "simulcast_group_tag" is assigned the same number to components that are performing simulcast (transmitting the same content using different encoding methods or audio modes). For components that are not performing simulcast, a specific value (0xFF) is set.
"main_component_flag" has a specific value when the audio component is the main audio.
"quality_indicator" indicates the sound quality mode.
"sampling_rate" indicates the sampling frequency.
"ISO_639_language_code" indicates the language of the audio component. In ES multilingual mode, it indicates the language of the first audio component. The language code is expressed as a three-letter alphabet code. Each character is written in 8 bits and inserted in that order into the 24-bit field.
"text_char" describes the name of the audio type. If this description is a default character string, this field may be omitted.

The simulcast_group_tag (simulcast group identification) is used to distinguish between stereo audio transmitted simultaneously with MPEG-H, 22.2ch surround, or 5.1ch surround, and MPEG-4 AAC stereo audio transmitted simultaneously with the ALS encoding method, on the receiver side. The same simulcast_group_tag value is transmitted for audio transmitted simultaneously.

<Transmission Operation Rules and Reception Processing Standards>
FIG. 13 is a schematic diagram showing an example of the transmission operation rule according to this embodiment.
FIG. 14 is a schematic diagram showing an example of a receiving processing standard according to this embodiment.
FIG. 13 shows an example of sending operation rules for the MH-voice component descriptor, and FIG. 14 shows an example of receiving processing standards for the MH-voice component descriptor.

In these examples, "nga_profile_level" is a label for identifying the presence or absence of MPEG-H, the profile, and the level. Of the four bits of "nga_profile_level," the profile is set in the first bit, and the presence or absence and level of MPEG-H are set in the remaining three bits. The field representing the profile is "nga_profile," which is bslbf (bit string, left bit first). When "nga_profile" has a value of "1," it indicates that the profile is "Basic Profile," and when it has a value of "0," it indicates that the profile is "Low Complexity Profile."
The field indicating the presence or absence and level of MPEG-H is "nga_level", which is uimsbf (unsigned integer most significant bit first: most significant bit first). When "nga_level" has a value of "0", it indicates that an MPEG-H audio signal is not present (not MPEG-H audio), and when it has any other value, it indicates that an MPEG-H audio signal is present (MPEG-H audio). Furthermore, when "nga_level" has a value of "1", it indicates that the level is "Level 1", when it has a value of "2", when it has a value of "Level 2", when it has a value of "3", and when it has a value of "4", it indicates that the level is "Level 4". The "nga_level" values "5" to "7" are unused and may be assigned in the future.

"stream_content" is set to 0x03 for MPEG-4 AAC audio streams, 0x04 for MPEG-4 ALS audio streams, and 0x05 for MPEG-H audio streams. If the value of "stream_content" is anything other than these values, the receiver 2 invalidates the descriptor.

Regarding "simulcast_group_tag," when transmitting/receiving MPEG-H audio, the same value of "simulcast_group_tag" is set for the MPEG-H audio asset and one or more MPEG-4 audio assets. In this case, a value of "simulcast_group_tag" different from this value is set for one or more MPEG-4 audio assets. The latter "simulcast_group_tag" is not set for the MPEG-H audio asset. In other words, the latter simulcast audio includes only MPEG-4 audio assets and does not include MPEG-H audio assets.
"ISO_639_language_code2" may indicate one or more language names of an MPEG-H audio asset. Specifically, a first language (e.g., Japanese) may be described in "ISO_639_language_code" and a second language (e.g., English) may be described in "ISO_639_language_code2." Furthermore, for an MPEG-H audio asset, multiple languages (e.g., Japanese and English) may be described in "ISO_639_language_code2."

In the transmission operation of the MH-audio component descriptor, when updating the parameters of the audio stream within the same event, the broadcasting station 1 generally changes the contents of the MH-audio component descriptor in the MPT and updates the MPT version. However, as an exception, there are cases where transmission operation is performed without updating this descriptor. In this case, the contents of the audio stream and the MH-audio component descriptor temporarily become inconsistent. For example, this may occur when transitioning from the main program to a commercial or during flexible programming. In this case, the broadcasting station 1 does not update the MPT version, so the receiver continues to play the audio stream with the same component tag value.
Such an operation in which this descriptor is not updated when updating the parameters of the audio stream is permitted only when the audio encoding method is AAC and the audio mode is switched between audio modes of 5.1ch or less.

If the MPT version is updated during the MH-Audio Component Descriptor reception process, and the number of audio streams or the contents of this descriptor are updated, the receiver 2 will play audio appropriately in accordance with the contents of this descriptor. As long as the MPT version has not been updated, the receiver 2 will, in principle, continue to play audio streams with the same component tag value. When switching between audio modes of 5.1ch or lower, the contents of the audio stream and this descriptor may differ. In such cases, the receiver 2 will prioritize decoding the contents of the audio stream.

Select an audio asset
The broadcast operates in multiple audio modes (MPEG-H, MPEG-4 AAC 2ch, AAC 5.1ch, AAC 7.1ch, AAC 22.2ch, ALS 2ch, ALS 5.1ch). Monaural and dual mono are not operated.

The receiver 2 has the following audio decoding functions:
・MPEG-4 AAC 2ch playback ・Downmix playback function from MPEG-4 AAC 5.1ch to 2ch To meet these requirements, AAC 2ch is used in simulcast mode in MPEG-H, MPEG-4 AAC 7.1ch, or AAC 22.2ch audio modes (AAC 5.1ch may also be used in simulcast mode). Also, AAC 2ch or AAC 5.1ch is used in simulcast mode in MPEG-H audio mode or ALS audio mode.

The receiver 2 has the function to switch and select as follows when multiple audio assets are in operation.
When playing back on the receiver 2 itself, the receiver 2 determines the audio mode that can be played back on the receiver 2 itself, and switches and plays back the asset with priority given to the asset with the smallest component tag value. When selecting a channel, the asset with the smallest component tag value that can be played back is played back as the default audio.
In a playback environment of up to 2ch, if AAC 2ch audio is simultaneously operated in accordance with MPEG-H or AAC 5.1ch, the receiver 2 will prioritize playback of AAC 2ch audio. In a playback environment of up to a specific level, if MPEG-H is operated, the receiver 2 will prioritize playback of the maximum or minimum level of the levels below the specific level.
However, if the audio mode is switched without updating the MPT version, the asset that is currently being played will continue to be played.

The receiver 2 determines whether multiple languages are used by referring to the simulcast group identification and plays the asset (language) with the smallest component tag value as the default language. For MPEG-H, the receiver 2 may play audio in a predetermined default language. Even if the language is switched, the receiver 2 returns to the default language when the channel is reselected. For MPEG-H, the receiver 2 may have a language fixed mode.
In the receiver 2, the selection of a valid audio asset is cyclically switched by using an audio button on a remote control, etc. For example, in the receiver 2, the selection of an MPEG-H audio asset and one or more MPEG-4 audio assets is cyclically switched.
In the user interface where the receiver selects audio from a menu, audio information is displayed according to the information in the MH-Audio Component Descriptor. Note that the phonetic notation described in the text_char field in the MH-Audio Component Descriptor takes priority when describing the audio type. However, for MPEG-H, the receiver 2 may also take priority over a predetermined phonetic notation.

When the audio mode is switched within the same audio asset, or when the receiver automatically switches to audio from a different asset, the receiver 2 switches in a way that does not sound unnatural to the receiver. The switching operation of the receiver 2 is as follows.
(1) The receiver 2, which has learned of the audio mode or asset switch due to the MPT update approximately 0.5 seconds ago, mutes the output of the preceding audio after fading it.
(2) After the receiver 2 has performed the necessary processing for switching, it cancels the mute and resumes outputting the subsequent audio. The time required for the switching process varies depending on whether the audio asset has been switched and the type of audio mode being updated. Generally, the time required for switching the encoding method is the longest. During the switching process, a silent interval is provided on the sending side.
(3) When the receiver 2 switches from an MPEG-4 audio asset to an MPEG-H audio asset, it displays the MPEG-H audio digital mixer.

[Audio switching operation]
FIG. 15 is a flowchart showing a detailed example of switching according to this embodiment.
This diagram shows the audio switching operation of the receiver 2. The processes of the following steps S101 to S104, S11, S112, and S121, and the control of steps S122 and S123 are performed by the computer of the receiver 2 (CPU 255: control unit).

(Step S101) The receiver selects a channel using a remote control or the like, or the receiver 2 automatically selects a channel. Then, the process of step S102 is performed.
(Step S102) The receiver 2 updates the MPT, and then the process of step S103 is performed.
(Step S103) The receiver 2 checks the default asset. Specifically, the default asset is an asset whose "component_tag" has a specific value. Default assets are predetermined for each asset type. If the asset type is "broadcast transmission audio," a specific value "0x0010" is assigned to the default asset. This specific value is set as the initial value of the variable i (i = 0x0010). Then, the processing of step S104 is performed.

(Step S104) The receiver 2 determines whether or not "component_tag" is an asset of broadcast transmission audio. Assets whose asset type is "broadcast transmission audio" are assigned values from "0x0010" to "0x002F." The receiver 2 determines whether or not the asset is an asset of broadcast transmission audio by determining whether or not the value of the variable i is equal to or less than "0x002F."
Note that MPEG-H audio assets are assigned a smaller value in "component_tag" than MPEG-4 audio assets. In this case, the playability of the MPEG-H audio assets is determined first. However, MPEG-H audio assets may be assigned a larger value in "component_tag" than MPEG-4 audio assets.
If it is determined that the asset is a broadcast transmission audio (Yes), the process of step S111 is performed. On the other hand, if it is determined that the asset is not a broadcast transmission audio asset (No), the process of step S121 is performed.

(Step S111 ) The receiver 2 determines whether the stream can be played back by the receiver 2 itself. Specifically, the receiver 2 determines whether the stream can be played back by the receiver 2 itself, using "stream_content,""component_type,""stream_type," and "nga_profile_level."

To determine whether MPEG-H audio can be played, receiver 2 performs the following determination:

Receiver 2 separates "nga_profile" and "nga_level" from "nga_profile_level". Receiver 2 determines whether an MPEG-H audio signal is not present (not MPEG-H audio) by determining whether "nga_level" is "0". In other words, receiver 2 determines whether an MPEG-H audio signal is present (is MPEG-H audio) by determining whether "nga_level" is not "0".

If "nga_level" is "0", the MPEG-4 audio stream does not contain any MPEG-H audio assets, so the receiver 2 determines whether its own device can play this MPEG-4 audio stream (MPEG-4 audio). If the receiver 2 cannot play this MPEG-4 audio stream (No), it proceeds to step S104. On the other hand, if it can be played (Yes), it proceeds to step S112.

If "nga_level" is not "0" (is between "1" and "4", or is "1" or greater), the MPEG-H audio stream contains an MPEG-H audio asset, so the receiver 2 determines whether its own device can play this MPEG-H audio stream (MPEG-H audio). If the receiver 2 cannot play this MPEG-H audio stream (No), it proceeds to step S104.

On the other hand, if playback is possible, the receiver 2 determines whether the level indicated by "nga_level" is at a level at which playback is possible for the receiver 2 itself (or whether it is at or below the level at which playback is possible). If the receiver 2 determines that the level is not at a level at which playback is possible (No), the process proceeds to step S104.
If the level is playable, the receiver 2 determines whether the profile indicated by "nga_profile" is a profile playable by the receiver 2 itself. If it is not a playable profile (No), the process proceeds to step S104. On the other hand, if it is a playable profile (Yes), the process proceeds to step S112.
If it is determined in at least one of the determinations in step S111 that the asset is not reproducible (No), the variable i is incremented by 1, and the process in step S104 is performed on the asset with the next "component_tag" value.

(Step S112) The receiver 2 checks whether simulcast is available and the language, etc. Specifically, the receiver 2 performs this process using "simulcast_group_tag,""ES_multi_lingual_flag,""main_component_flag,""ISO_639_language_code,""ISO_639_language_code2," and "text_char."
The receiver 2 may use either or a combination of "ISO_639_language_code" or "ISO_639_language_code2" for the language of MPEG-H audio.

(Step S113) The receiver 2 adds the asset information acquired in the processing of S112 to a list in memory (RAM 254 or auxiliary storage device 252). This creates a list of playable streams. Then, the processing of step S104 is performed. Here, the receiver 2 increments the variable i by 1, and performs the processing of step S104 for the asset with the next "component_tag" value.

(Step S121) The receiver 2 selects a stream from the list of playable streams (the list created in the process of S113). The selection may be automatic by the receiver 2 or manual by the recipient. Then, the process of step S122 is performed.
(Step S122) The receiver 2 displays the selected language, etc. The selection may be automatic by the receiver 2 or manual by the recipient. Then, the process proceeds to step S123.
In MPEG-H audio, audio data streams in multiple languages may be stored in one asset. In this case, if an MPEG-H audio stream is selected in step S121, the receiver 2 can select a language without changing (selecting) the asset.
(Step S123) The receiver 2 plays back the audio stream selected in steps S121 and S122. After that, the receiver 2 repeats the operation of this flowchart by performing the process of step S102.

If no particular selection is made, the receiver 2 will select the stream with the smallest component_tag value (for example, the processing of step S121). Furthermore, the receiver 2 allows the recipient to select any desired selection from a list (see Figure 11). If a desired selection is made, the receiver 2 will continue to retain that value (play the stream). However, if the component_tag value (the stream being played) is lost, or if conditions such as the presence or absence of simulcast or language change, the receiver 2 will immediately select and play the stream with the smallest component_tag value that can be played after appropriate switching processing.

FIG. 16 is a flowchart showing another detailed example of switching according to this embodiment.
In this figure, the same processes as those in FIG. 15 are denoted by the same reference numerals, and the description thereof will be omitted.

(Step S1111) The receiver 2 determines whether or not an MPEG-H audio signal is present by determining whether "nga_level" is "0." If "nga_level" is "0" (Yes), the receiver 2 performs the process of step S1114. On the other hand, if "nga_level" is not "0" (No), the receiver 2 performs the process of step S1112.
(Step S1112) The receiver 2 determines whether the profile indicated by "nga_profile" is a profile that the receiver 2 can play (support). If the receiver 2 determines that the profile is not a playable profile (No), the receiver 2 performs the process of step S104. On the other hand, if the profile is a playable profile (Yes), the receiver 2 performs the process of step S1113.

(Step S1113) The receiver 2 determines whether the level indicated by "nga_level" is a level that the receiver itself can play (support) (whether it is below the playable level). If it is not a playable level (No), the process proceeds to step S104. If it is a playable level (Yes), the process proceeds to step S113.
(Step S1114) The receiver 2 determines whether or not the stream is playable by the receiver 2 itself. Specifically, the receiver 2 determines whether or not the stream is playable by the receiver 2 itself, using "stream_content", "component_type", and "stream_type". If the stream is not playable (No), the process of step S104 is performed. If the stream is playable (Yes), the process of step S112 is performed.
If the level is such that playback is possible (Yes) in the process of step S113, the process of step S1114 or S112 may be performed.

[Use Case]
Below, an example of a use case will be shown regarding a broadcast (asset) pattern, a receiver, and audio selection in the receiver in this embodiment.
Broadcast pattern 1 (for example, program A) is a pattern in which the following audio (asset) 11 to 14 are broadcast.
Broadcast pattern 1:
(1A) Audio 11: MPEG-H Level 4 (22.2ch (9/10/3), dialogue Japanese/English, commentary Japanese)
(1B) Audio 12: MPEG-4 (7.1ch, Japanese)
(1C) Audio 13: MPEG-4 (stereo Japanese)
(1D) Audio 14: MPEG-4 (stereo English)
The audio 11 is MPEG-H audio, level 4, 22.2ch audio (BGM), and includes dialogue in Japanese and English, and commentary in Japanese. The audio 13 is audio transmitted simultaneously with the audio 12.

Broadcast pattern 2 (for example, program B other than program A) is a pattern in which the following sounds 11 to 14 are broadcast.
Broadcast pattern 2:
(2A) Audio 11: MPEG-H Level 3 (11.1ch (4/7/0), dialogue Japanese/English, commentary Japanese)
(2B) Audio 12: MPEG-4 (7.1ch, Japanese)
(2C) Audio 13: MPEG-4 (stereo Japanese)
(2D) Audio 14: MPEG-4 (stereo English)
Comparing broadcast pattern 1 and broadcast pattern 2, the differences are that the MPEG-H (audio 11) levels are "Level 4" and "Level 3," and the number of channel audio is "22.2ch" and "11.1ch." Audio 13 is audio that is transmitted simultaneously with audio 12.

Receiver 2 includes receivers with the following capabilities:
Receiver A is a receiver that can support (play back) level 4 of MPEG-H audio.
Receiver B is a receiver that can support (play back) level 3 of MPEG-H audio.
Receiver C is a receiver that does not support (cannot play) MPEG-H audio.

The audio selection for each of the receivers A to C is as follows.
Receiver A is compatible with MPEG-H level 4 and below, as well as MPEG-4. Therefore, receiver A selects MPEG-H audio 11 for both broadcast patterns 1 and 2.
Receiver B is compatible with MPEG-H level 3 and below and MPEG-4, but not with MPEG-H level 4. Therefore, receiver B selects either MPEG-4 audio 12, 13, or 14 in broadcast pattern 1, but selects MPEG-H audio 11 in broadcast pattern 2.
Receiver C selects one of MPEG-4 audio 12, 13, and 14 for both broadcast patterns 1 and 2.
Even if the receiver 2 can select MPEG-H audio, it may select MPEG-4 audio through user operation or settings.

More specifically, it is as follows.
<Receiver B: MPEG-H Level 3 compatible>
In the case of broadcast pattern 1, receiver B can select any one of MPEG-4 audio 12, 13, or 14. Here, receiver B selects audio from the set of audio 12 and audio 14 or the set of audio 13 and audio 14 to prevent overlapping of selections from simulcast audio (audio 12 and audio 13).
In the case of broadcast pattern 2, receiver B can select MPEG-H audio 11.

In the case of broadcast pattern 2, if receiver B is equipped with, for example, 7.1 speakers, it selects audio 11 and generates 7.1ch audio by rendering (down-converting) the selected audio 11. In this case, receiver B can play the following audio (B11) to (B13).
(B11) 7.1ch dialogue Japanese (B12) 7.1ch dialogue English (B13) 7.1ch dialogue Japanese + commentary audio Japanese

In the case of broadcasting pattern 2, when using stereo headphones, for example, receiver B selects audio 11 and generates stereo audio by rendering (down-converting) the selected audio 11. In this case, receiver B can play the following audio (B21) to (B23).
(B21) Stereo dialogue Japanese (B22) Stereo dialogue English (B23) Stereo dialogue Japanese + commentary audio Japanese

<Receiver A: MPEG-H Level 4 compatible>
A case where the receiver A is equipped with a 22.2ch speaker will be described.
In the case of broadcast pattern 1, receiver A selects audio 11, and by performing a rendering process on the selected audio 11, can reproduce the following audio (A11) to (B13).
(A11) 22.2ch dialogue Japanese (A12) 22.2ch dialogue English (A13) 22.2ch dialogue Japanese + commentary audio Japanese

In the case of broadcast pattern 2, receiver A selects audio 11, and by rendering (upconverting) the selected audio 11, can reproduce the following audio (A21) to (B23).
(A21) 22.2ch dialogue Japanese (A22) 22.2ch dialogue English (A23) 22.2ch dialogue Japanese + commentary audio Japanese

As described above, in this embodiment, the broadcasting system Sys broadcasts audio including MPEG-H audio as an audio asset (an example of a component). The separator 22 of the receiver 2 acquires nga_profile_level (an example of identification information indicating whether MPEG-H audio is present) from the broadcast airwaves at the multiplexing layer. The CPU 255 (an example of a control unit) selects an audio asset according to the capabilities of the receiver 2 based on the nga_profile_level. The audio decoder 232 decodes the audio data of the selected audio asset.
This allows the receiver 2 in the broadcasting system Sys to perform appropriate audio reproduction according to its own capabilities.

In addition, in this embodiment, nga_profile_level is placed in the MH-audio component descriptor, which is an MMT (MPEG Media Transport) descriptor that describes parameters related to audio signals among program elements. The separator 22 acquires the MH-audio component descriptor. The CPU 255 selects an audio component according to the capabilities of the receiver 2 based on the nga_profile_level placed in the MH-audio component descriptor.

By reading the nga_profile_level from the MH-audio component descriptor, the receiver 2 can perform appropriate audio playback according to its own device's capabilities. Furthermore, the receiver 2 can determine whether MPEG-H audio is present before inputting the audio data to the audio decoder 232 (before decoding). This allows the receiver 2 to avoid decoding MPEG-H audio data when it cannot decode MPEG-H audio or when decoding is not necessary (for example, when the receiver has selected MPEG-4 audio).

In this embodiment, the broadcast includes MPEG-H audio assets and MPEG-4 audio assets. The audio decoder 232 includes a mixer unit 2331 (an example of a first decoding unit) that decodes audio data from the MPEG-H audio assets, and a downmixer unit 2332 (an example of a second decoding unit) that decodes audio data from the MPEG-4 audio assets. The separator 22 separates the MPEG-H audio from the MPEG-4 audio.
If the CPU 255 determines that MPEG-H audio can be played back based on the nga_profile_level placed in the MH-audio component descriptor, it selects either the MPEG-H audio or MPEG-4 audio audio asset. The audio decoder 232 decodes the audio data of the selected audio asset, either the MPEG-H audio or the MPEG-4 audio.

This allows the receiver 2 to select either MPEG-H audio or MPEG-4 audio, and the receiver 2 can play either MPEG-H audio or MPEG-4 audio depending on its own device's capabilities. On a receiver 2 that can play MPEG-H audio, the recipient can select either MPEG-H audio or MPEG-4 audio.

In this embodiment, the broadcast also includes MPEG-H audio assets and MPEG-4 audio assets. The audio decoder 232 decodes the audio data of the MPEG-4 audio assets. The separator 22 separates the MPEG-H audio from the MPEG-4 audio. The CPU 255 selects the MPEG-4 audio asset when it determines that the MPEG-H audio cannot be played based on the nga_profile_level placed in the MH-audio component descriptor. The audio decoder 232 decodes the audio data of the selected MPEG-4 audio asset.
This allows the receiver 2 to select MPEG-4 audio if its own device (including external amplifiers and external speakers) does not support MPEG-H audio, and the receiver 2 can play MPEG-H audio or MPEG-4 audio depending on the capabilities of its own device.

In this embodiment, each audio asset is identified by a component_tag. MPEG-4 audio is composed of one or more audio assets (they are multiplexed and sent). The separator 22 reads the MH-audio component descriptors (an example of configuration information) of the MPEG-H audio asset and the MPEG-4 audio asset in the order of the component_tag, and obtains the nga_profile_level from the MH-audio component descriptor.
This allows the receiver 2 to determine for each audio asset whether it is MPEG-H audio along with the audio asset information.

In this embodiment, the MH-audio component descriptor contains nga_profile_level (whether nga_level is 0 or not), and nga_level (an example of a level indicating the processing capability of MPEG-H audio) or nga_profile (an example of a profile indicating a set of functions). The CPU 255 selects an audio component according to the capabilities of the receiver 2 based on nga_level or nga_profile.
This allows the receiver 2 to determine whether MPEG-H audio is present and to obtain the level or profile of the MPEG-H audio, allowing the receiver 2 to perform appropriate audio playback according to the level, profile, and the capabilities of its own device.

[Modification: MPEG-H Playability Determination]
The receiver 2 may determine whether or not MPEG-H can be played back as follows.
<Case 1>
The receiver 2 may determine whether an asset is MPEG-H audio using "component_tag." In this case, specific values are assigned to MPEG-H audio assets in "component_tag." For example, MPEG-4 audio assets in Japanese are assigned to 0x0010 to 0x001F, and MPEG-4 audio assets in English are assigned to 0x0020 to 0x0025. MPEG-H audio assets are assigned to 0x0026 to 0x002F. The receiver 2 determines that an asset is an MPEG-H audio asset if "component_tag" is any of 0x0026 to 0x002F. If "component_tag" is not any of 0x0026 to 0x002F, the receiver 2 determines that the asset is not an MPEG-H audio asset. In this case, the receiver 2 may assign the "component_tag" so that the MPEG-H profile and level can also be identified. The receiver 2 may assign the MPEG-H profile and level to the "nga_profile_level".

In Case 1 of this modified example, the receiver 2 can determine whether or not an asset is an MPEG-H audio asset in the process of step S104 (without performing the process of step S111). Furthermore, the receiver 2 can determine whether or not an asset is an MPEG-H audio asset without providing a new field.
Comparing the above embodiment with this variant 1, in the above embodiment, "nga_profile_level" stores whether it is MPEG-H audio, and the MPEG-H profile and level, so it is possible to operate the contents, restrictions (number, number of bytes, etc.) or rules of the values of other fields (component_tag in this variant) while maintaining the existing operation.

<Case 2>
The receiver 2 may determine whether the asset is MPEG-H audio using "component_type." For example, the "component_type" value may be defined as b8:MPEG-H. If "component_type" is b8, the receiver 2 determines that the asset is an MPEG-H audio asset. If "component_type" is not b8, the receiver 2 determines that the asset is not an MPEG-H audio asset. In this case, the receiver 2 may assign "component_type" so that the MPEG-H profile and level can also be identified. The receiver 2 may assign the MPEG-H profile and level to "nga_profile_level."
In case 2 of this modified example, the receiver 2 can determine whether or not an asset is an MPEG-H audio asset without providing a new field.
Comparing the above embodiment with this variant 2, in the above embodiment, "nga_profile_level" stores whether it is MPEG-H audio, and the MPEG-H profile and level, so it is possible to operate the contents, restrictions (number, number of bytes, etc.) or rules of the values of other fields (component_type in this variant) while maintaining the existing operation.

<Case 3>
The receiver 2 may use "stream_content" to determine whether the audio is MPEG-H audio. As described above, the "stream_content" value is set to a specific value (0x03) for an MPEG-4 AAC audio stream, and to another value (0x04) for an MPEG-4 ALS audio stream. Furthermore, a further value (e.g., 0x05) is set for an MPEG-H audio stream.
If "stream_content" is 0x05, the receiver 2 determines that the asset is an MPEG-H audio asset. If "stream_content" is not 0x05, the receiver 2 determines that the asset is not an MPEG-H audio asset. In this case, the receiver 2 may assign "stream_content" so that the MPEG-H profile and level can also be identified. The receiver 2 may assign the MPEG-H profile and level to "nga_profile_level."
In case 3 of this modified example, the receiver 2 can also determine whether an asset is an MPEG-H audio asset without providing a new field.
Comparing the above embodiment with this variant 3, in the above embodiment, "nga_profile_level" stores whether it is MPEG-H audio or not, and the MPEG-H profile and level, so it is possible to operate the contents, restrictions (number, number of bytes, etc.) or rules of the values of other fields (in this variant, stream_content) while maintaining the existing operation.

Similarly, other fields referenced in steps S111 and S112, such as "stream_type" or "asset_type," may be set with information indicating whether the data is MPEG-H audio, or information that identifies the profile and level.

<Case 4>
In this modification, a new descriptor, "MH-MPEG-H audio descriptor," is introduced. The receiver 2 uses the "MH-MPEG-H audio descriptor" to determine whether the audio is MPEG-H audio and to identify the profile and level.

Figure 17 is a schematic diagram showing an example of the structure of an MH-MPEG-H audio descriptor related to this variant. Note that the "MH-MPEG-H audio descriptor" (MH-MPEG-H Audio Descriptor()) is one of the descriptors in MMT-SI, and is described in MMT-SI in addition to the above-mentioned descriptors such as the "MH-audio component descriptor."

In the "MH-MPEG-H Audio Descriptor", the meaning of each field is as follows:
"Descriptor_tag" describes a fixed value indicating that it is an MH-MPEG-H audio descriptor.
"descriptor_length" describes the descriptor length of the MH-MPEG-H audio descriptor.

"nga_type" indicates the type of next-generation audio. For example, '1' is set for MPEG-H audio. Note that for audio other than MPEG-H audio (MPEG-4), '0' may be set, or another next-generation audio type may be set.
"profile_level" indicates a profile and a level. Of the three bits in "profile_level," the first bit indicates a profile, and the remaining two bits indicate a level. For example, if the first bit has a value of "1," it indicates that the profile is a "Basic Profile," and if the value is "0," it indicates that the profile is a "Low Complexity Profile." For the remaining two bits, if the value is "00," the level is "Level 1," if the value is "01," the level is "Level 2," if the value is "10," the level is "Level 3," and if the value is "11," the level is "Level 4."
The profile and the level may be separate fields.

The "component_tag" has the same value as the component_tag in the "MH-Audio Component Descriptor." Note that the "component_tag" in the "MH-MPEG-H Audio Descriptor" also has the same value as the component_tag in the MH-Stream Identification Descriptor.

"preset()" indicates whether or not there are presets and the number of presets. A preset is, for example, a preset in which audio values (values for adjusting the audio) are set in advance for each of multiple sound materials. Different preset values result in different audio balances between sound materials. Presets include, for example, presets that correspond to the audio playback environment (speaker type and placement), presets for improving accessibility, and presets that suit the viewer's preferences. Presets for include presets that increase (or decrease) the volume of only the dialogue, insert audio commentary, or play on a second device (for example, a speaker at hand).
By selecting a preset, the receiver can select and enjoy the audio he or she likes (sound balance, etc.) without having to make detailed settings for all the audio materials.

"Interactive( )" indicates whether or not there is an interactive function and the operation content.
The interactive status indicates whether the receiver can adjust each sound material. The operation details indicate the operation details for adjusting each sound material. The operation details include, for example, information about the material (object to be adjusted for sound), the adjustment details (type of strength or effect, type of user interface, conditions such as upper and lower limits), and the adjustment tool (tool name, provider, download destination, etc.). The receiver can adjust the MPEG-H audio according to the broadcast program.

<Transmission Operation Rules and Reception Processing Standards>
FIG. 18 is a schematic diagram showing an example of the transmission operation rules according to this modification.
FIG. 19 is a schematic diagram showing an example of a reception processing standard according to this modification.
FIG. 18 shows an example of the transmission operation rules for the MH-MPEG-H audio descriptor, and FIG. 19 shows an example of the reception processing standards for the MH-MPEG-H audio descriptor.

The "descriptor_tag" is set to the fixed value "0x8040". This value is greater than the fixed value "0x8014" of the "descriptor_tag" in the "MH-audio component descriptor". In this case, the receiver 2 treats the "MH-audio component descriptor" as having a higher priority than the "MH-MPEG-H audio descriptor" and reads it first. In other words, the "MH-MPEG-H audio descriptor" is treated as auxiliary data for the "MH-audio component descriptor". Note that the value of "descriptor_tag" may be a value smaller than "0x8014".

If the receiver 2 determines that an "MH-MPEG-H audio descriptor" exists in the MPT (see Figure 7) (a descriptor with a descriptor_tag value of "0x8040"), it determines that an MPEG-H audio asset exists.
In this case, the receiver 2 identifies the audio asset of the "component_tag" described in the "MH-MPEG-H audio descriptor" as the MPEG-H audio asset.
In addition, if the "MH-MPEG-H Audio Descriptor" also describes audio assets other than MPEG-H audio assets, the receiver 2 may identify an asset with a "component_tag" corresponding to the "nga_type" value (e.g., a value of "0": MPEG-H) as an MPEG-H audio asset.

15, if the variable i matches the "component_tag" value of the audio asset identified as an MPEG-H audio asset, the receiver 2 determines that an MPEG-H audio signal is present. On the other hand, if they do not match, the receiver 2 determines that an MPEG-H audio signal is not present.
When the receiver 2 determines that an MPEG-H audio signal is present, it determines whether its own device can play back this MPEG-H audio stream. If the receiver 2 cannot play back this MPEG-H audio stream (No), it performs the process of step S104. On the other hand, if it can play back, it determines whether the level indicated by "profile_level" is a level at which its own device can play back. If the receiver 2 does not determine this level at which it can play back (No), it performs the process of step S104. If the level at which it can play back is a level at which it can play back, it performs the process of step S104. If the profile indicated by "profile_level" is a profile at which it can play back, it performs the process of step S112. If the profile indicated by "profile_level" is not a profile at which it can play back, it performs the process of step S112.

15, the receiver 2 adds the asset information acquired in S112 to a list in memory. Here, for MPEG-H audio assets, the receiver 2 also stores the "preset()" and "interactive()" information in the list in memory.
In the process of step S122 or S123, the receiver 2 may automatically select a preset based on the information in "preset()," or may display the contents of the preset and allow the receiver to select a preset. In the process of step S122 or S123, the receiver 2 may display the MPEG-H audio digital mixer based on the information in "interactive()." In these cases, the receiver 2 plays back the audio stream based on the selected preset or the adjustment results by the digital mixer in step S123.

As described above, in this modification, the broadcast includes an MH-audio component descriptor, which is an MMT (MPEG Media Transport) descriptor that describes parameters related to audio signals among program elements, and an MPEG-H audio descriptor that describes parameters related to MPEG-H audio. The nga_type is placed in the MPEG-H audio descriptor. The separator 22 acquires the MH-audio component descriptor and the MPEG-H audio descriptor. The CPU 255 selects an audio component according to the capabilities of the receiver 2, based on the nga_type placed in the MPEG-H audio descriptor.
This allows the receiver 2 to read out nga_type from the MPEG-H audio descriptor and perform appropriate audio playback according to the capabilities of its own device.

In this modification, preset() and interactive() are placed in the MPEG-H audio descriptor. The separator 22 acquires the MH-audio component descriptor and the MPEG-H audio descriptor. The CPU 255 plays back audio based on preset() or interactive() placed in the MPEG-H audio descriptor.
This allows the receiver 2 to play back audio based on preset(). The receiver can select and enjoy the audio of their choice (sound balance, etc.) without having to make detailed settings for all audio materials. The receiver 2 can adjust the audio and play back the audio based on interactive(). The receiver can adjust the MPEG-H-based audio according to the broadcast program.

In the above embodiment (including variations), asset priority may be as follows: For video and audio assets, if multiple assets of the same asset_type are defined in one MPT, and if multiple component descriptors (MH-audio component descriptors) are placed in the MH-EIT, the receiver 2 prioritizes the assets in ascending order of component_tag value. In other words, the receiver 2 determines that the default asset has the highest priority, with higher values indicating lower priorities. This priority can be used, for example, when displaying a list of streams on an EPG or in the display order when a stream switch button is pressed. However, for audio simultaneously transmitted using assets with the same simulcast_group_tag value, in a playback environment of up to 2ch, if AAC 2ch audio is simultaneously operated in accordance with AAC 5.1ch, the receiver 2 will prioritize playback of AAC 2ch audio.

20 is a schematic diagram showing an example of the operation of simulcast_group_tag values in simulcast audio according to this embodiment (including modifications).
In this diagram, an asset with an audio mode of "MPEG-H" is an MPEG-H audio asset, and is available in multiple languages (Japanese and English). This audio asset is assigned a component_tag value of "0x0026." This value is higher than the other audio assets (MPEG-4 audio assets: 0x0010-0x0013, 0x0020-0x0023). In other words, in this example, the priority of MPEG-H audio assets is set lower than that of MPEG-4 audio assets.

This diagram shows an example of operating two simulcast audios. The first simulcast audio has a simulcast_group_tag value of "0x00", and the second simulcast audio has a simulcast_group_tag value of "0x01".
The first simul audio is made up of four MPEG-4 audio assets (0x0010, 0x0011, 0x0020, 0x0021) and one MPEG-H audio asset (0x0026). In other words, it is simul audio that includes an MPEG-4 audio asset and an MPEG-H audio asset.
The second simul audio is made up of four MPEG-4 audio assets (0x0012, 0x0013, 0x0022, 0x0023). In other words, it is a simul audio made up of only MPEG-4 audio assets.
This diagram shows that the audio is made up of a first simul audio and a second simul audio.

21 is a schematic diagram showing another example of the operation of simulcast_group_tag values in simulcast audio according to this embodiment (including modifications).
In this diagram, an asset with an audio mode of "MPEG-H" is an MPEG-H audio asset, and is available in multiple languages (Japanese and English). This audio asset is assigned a component_tag value of "0x0010." This value is assigned a smaller value than other audio assets (MPEG-4 audio assets: 0x0010, 0x0012, 0x0020, 0x0021). In other words, in this example, the priority of MPEG-H audio assets is set higher than that of MPEG-4 audio assets.
The simulcast_group_tag value in this diagram is "0x00", and is made up of four MPEG-4 audio assets (0x0010, 0x0011, 0x0020, 0x0021) and one MPEG-H audio asset (0x0026). This diagram shows an example of operation with one simulcast audio.

Note that multiple simulcast audio may exist in Fig. 21, as in Fig. 20. For example, the four MPEG-4 audio assets in Fig. 20 (0x0012, 0x0013, 0x0022, 0x0023, simulcast_group_tag value "0x01") may be added to the audio assets in Fig. 21.
Also, in Figure 20, as shown in Figure 21, there may be one simulcast audio (MPEG-H audio assets have a lower priority), and the four audio assets with a simulcast_group_tag value of "0x01" may be excluded.

In the above embodiment (including the modified example), the "MH-audio component descriptor" may include preset() or interactive().
In the above embodiment, "voice" may be replaced with "audio.""Asset" may be replaced with "component," and "component" may be replaced with "asset."

In addition, in the above-described embodiment, at least some of the broadcast station 1 (broadcast device 1), receiver 2, broadcast station server 3, and provider server 4, for example, the receiver 2's separator (Demux, TLV/MMT separator) 22, 22a, selector (audio asset selector) 231, audio decoder (decoder) 232, mixer 2331, downmixer 2332, switch 2333, DAC 2334, mixer 233, video decoder 241, presentation processor 242, input/output device 251, CPU 255, and communication chip 256, may be implemented by a computer. In this case, a program for implementing this control function may be recorded on a computer-readable recording medium, and the program recorded on the recording medium may be read into and executed by a computer system. Note that the "computer system" referred to here refers to a computer system built into the broadcast station 1, receiver 2, broadcast station server 3, or provider server 4, and includes hardware such as an OS and peripheral devices. Furthermore, "computer-readable recording media" refers to portable media such as flexible disks, optical magnetic disks, ROMs, and CD-ROMs, as well as storage devices such as hard disks built into computer systems. Furthermore, "computer-readable recording media" may also include devices that dynamically store programs for a short period of time, such as communication lines used when transmitting programs via networks such as the Internet or communication lines such as telephone lines, or devices that store programs for a fixed period of time, such as volatile memory within computer systems that serve as servers or clients in such cases. Furthermore, the above-mentioned programs may be programs that realize some of the aforementioned functions, or may be programs that can realize the aforementioned functions in combination with programs already stored in the computer system.
Furthermore, some or all of the broadcast station 1, receiver 2, broadcast station server 3, and provider server 4 in the above-described embodiment may be realized as an integrated circuit such as an LSI (Large Scale Integration). Each functional block of the broadcast station 1, receiver 2, broadcast station server 3, and provider server 4 may be individually implemented as a processor, or some or all of them may be integrated into a processor. Furthermore, the integrated circuit implementation method is not limited to LSI, and may be implemented using a dedicated circuit or a general-purpose processor. Furthermore, if an integrated circuit implementation technology that can replace LSI emerges due to advances in semiconductor technology, an integrated circuit based on that technology may be used.

One embodiment of the present invention has been described in detail above with reference to the drawings, but the specific configuration is not limited to that described above, and various design modifications can be made without departing from the spirit of the present invention.

Broadcasting System Sys
Relay Station Sa
Broadcasting station, broadcasting equipment 1
MPEG-H Encoder 11
MPEG-4 Encoder 111, 112, 113
Mux (multiplexer) 12
Receiver 2
Broadcasting station server 3
Business server 4
Tuner 211
Demodulator 212
Separator (Demux, TLV/MMT separation section) 22, 22a
Selector (audio asset selection unit) 231
Audio decoder (decoder section) 232
MPEG-H Audio Core Decoder 232-1
MPEG-4 Decoder 232-2
Mixer section 2331
Downmixer section 2332
MPEG-H Audio Renderer 233-1
Mixer 233-2
Switch section 2333
DAC section 2334
Mixer 233
Speaker 234
Video decoder 241
Presentation Processor 242
Display 243
Input/output device (external output I/F) 251
Auxiliary storage device 252
ROM 253
RAM 254
CPU 255
Communication chip 256

Claims (10)

a receiving unit for receiving a broadcast including MPEG-H audio in the audio component;
an acquisition unit that acquires, from the broadcast wave of the broadcast, identification information indicating whether or not MPEG-H audio is present at a multiplexing layer;
a selection unit that selects an audio component according to the capabilities of the receiver based on the identification information;
a decoding unit that decodes the audio data of the selected audio component;
the identification information is included in an audio component descriptor;
the acquisition unit acquires the audio component descriptor,
the selection unit selects an audio component according to a receiver's capability based on the identification information included in the audio component descriptor;
the broadcast wave includes a descriptor that describes information related to object-based audio;
The acquisition unit acquires a descriptor that describes information about the object-based audio.
Receiver . The descriptor describing information related to the object-based audio includes a profile indicating a level or a set of functions indicating processing capabilities of MPEG-H audio;
The receiver according to claim 1 , wherein the selection unit selects an audio component according to a capability of the receiver based on the level or the profile. a receiving unit for receiving a broadcast including MPEG-H audio in the audio component;
an acquisition unit that acquires, from the broadcast wave of the broadcast, identification information indicating whether or not MPEG-H audio is present at a multiplexing layer;
a selection unit that selects an audio component according to the capabilities of the receiver based on the identification information;
a decoding unit that decodes the audio data of the selected audio component;
the identification information is included in an audio component descriptor;
the acquisition unit acquires the audio component descriptor,
the selection unit selects an audio component according to a receiver's capability based on the identification information included in the audio component descriptor;
the broadcast wave includes an audio component of MPEG-H audio and an audio component of MPEG-4 audio;
the selection unit selects an audio component of either MPEG-H audio or MPEG-4 audio when determining that MPEG-H audio can be played back based on the identification information included in the audio component descriptor;
The decoding unit decodes the audio data of the selected audio component, either MPEG-H audio or MPEG-4 audio.
Receiver . a receiving unit for receiving a broadcast including MPEG-H audio in the audio component;
an acquisition unit that acquires, from the broadcast wave of the broadcast, identification information indicating whether or not MPEG-H audio is present at a multiplexing layer;
a selection unit that selects an audio component according to the capabilities of the receiver based on the identification information;
a decoding unit that decodes the audio data of the selected audio component;
the identification information is included in an audio component descriptor;
the acquisition unit acquires the audio component descriptor,
the selection unit selects an audio component according to a receiver's capability based on the identification information included in the audio component descriptor;
the broadcast wave includes an audio component of MPEG-H audio and an audio component of MPEG-4 audio;
the selection unit selects an audio component of MPEG-4 audio when determining that MPEG-H audio cannot be played back based on the identification information included in the audio component descriptor;
The decoding unit decodes the audio data of the selected audio component of the MPEG-4 audio.
Receiver . each of the audio components is identified by a component identifier;
the MPEG-4 audio is composed of one or more audio components;
The receiver according to claim 3 or claim 4, wherein the acquisition unit reads configuration information of the audio components of MPEG-H audio and the audio components of MPEG-4 audio in accordance with the order of the component identifiers, and acquires the identification information from the configuration information. a receiving unit for receiving a broadcast including MPEG-H audio in the audio component;
an acquisition unit that acquires, from the broadcast wave of the broadcast, identification information indicating whether or not MPEG-H audio is present at a multiplexing layer;
a selection unit that selects an audio component according to the capabilities of the receiver based on the identification information;
a decoding unit that decodes the audio data of the selected audio component;
the identification information is included in an audio component descriptor;
the acquisition unit acquires the audio component descriptor,
the selection unit selects an audio component according to a receiver's capability based on the identification information included in the audio component descriptor;
The audio component descriptor includes a profile that indicates a level or set of functions that indicate processing capabilities of MPEG-H audio;
The selection unit selects an audio component according to the capabilities of a receiver based on the level or the profile.
Receiver. a receiving unit for receiving a broadcast including MPEG-H audio in the audio component;
an acquisition unit that acquires, from the broadcast wave of the broadcast, identification information indicating whether or not MPEG-H audio is present at a multiplexing layer;
a selection unit that selects an audio component according to the capabilities of the receiver based on the identification information;
a decoding unit that decodes the audio data of the selected audio component;
The broadcast wave includes an audio component descriptor and a descriptor that describes information related to object-based audio,
the identification information is included in a descriptor that describes information about the object-based audio;
the acquisition unit acquires the audio component descriptor and a descriptor describing information related to the object-based audio;
The selection unit selects an audio component according to the capabilities of a receiver based on the identification information included in a descriptor that describes information related to the object-based audio.
Receiver . A receiving method in a receiver, comprising:
a receiving step of receiving a broadcast including MPEG-H audio in the audio component;
an acquisition step of acquiring, from the airwaves of the broadcast, identification information indicating whether or not MPEG-H audio is present at a multiplexing layer;
a selection step of selecting an audio component according to the receiver's capabilities based on said identification information;
a decoding step of decoding audio data of the selected audio component;
the identification information is included in an audio component descriptor;
The obtaining step obtains the audio component descriptor,
the selecting step selects an audio component according to the capability of a receiver based on the identification information included in the audio component descriptor;
the broadcast wave includes a descriptor that describes information related to object-based audio;
The obtaining step obtains a descriptor that describes information about the object-based audio.
Receiving method. a receiving unit for receiving a broadcast including MPEG-H audio in the audio component;
an acquisition unit that acquires, from the broadcast wave of the broadcast, identification information indicating whether or not MPEG-H audio is present at a multiplex layer;
the broadcast wave includes a descriptor that describes information related to object-based audio;
The acquisition unit acquires an audio component descriptor and a descriptor describing information about the object-based audio, and the computer of the receiver acquires the descriptor ,
selecting an audio component according to the receiver's capabilities based on the identification information;
Decoding the audio data of the selected audio component;
the identification information is included in the audio component descriptor;
and selecting an audio component according to the capabilities of a receiver based on the identification information included in the audio component descriptor.
program. A broadcasting system that broadcasts audio including MPEG-H audio,
The receiver,
a receiving unit for receiving a broadcast including MPEG-H audio in the audio component;
an acquisition unit that acquires, from the broadcast wave of the broadcast, identification information indicating whether or not MPEG-H audio is present at a multiplexing layer;
a selection unit that selects an audio component according to the capabilities of the receiver based on the identification information;
a decoding unit that decodes the audio data of the selected audio component;
the identification information is included in an audio component descriptor;
the acquisition unit acquires the audio component descriptor,
the selection unit selects an audio component according to a receiver's capability based on the identification information included in the audio component descriptor;
the broadcast wave includes a descriptor that describes information related to object-based audio;
The acquisition unit acquires a descriptor that describes information about the object-based audio.
Broadcasting system.