JP7176588B2 - Receiving device and receiving method - Google Patents

Description

The technology disclosed in this specification relates to a transmission device and a transmission method, and a reception device and a reception method, for transmitting data in a predetermined transport format. The present invention relates to a transmitting device and a transmitting method, a receiving device and a receiving method, which transmit according to the Transport method.

Digital broadcasting can provide various character information such as news and weather forecasts and interactive services called data broadcasting. Data broadcasting applications in operation at the time of filing this application are described in the BML (Broadcast Markup Language) system defined by ARIB (Association of Radio Industries and Broadcast) STD-B24.

Data broadcasting applications can be broadly classified into program-linked data broadcasting applications that are linked to broadcast programs and program-unlinked data broadcasting applications that are not particularly linked to broadcast programs, such as news and weather forecasts. Program-linked data broadcasting applications are basically renewed with the change of broadcast programs. Therefore, there is a demand on the broadcasting station side to forcibly switch to the program-linked data broadcasting application and display it when the broadcast program is switched during execution of the program-unlinked data broadcasting application. In a conventional broadcasting system that performs data carousel transmission of a data broadcasting application in BML (Broadcast Markup Language) format, it is possible to forcibly return to a desired data broadcasting application by signaling a return flag (return_entry_flag) (for example, See U.S. Pat.

Also, as a next-generation digital broadcasting system, an ultra-high-definition TV broadcasting standard based on the MMT (MPEG Media Transport) system standardized as a new media transport system by MPEG is under consideration. In the MMT system, it is easy to combine and use different transmission paths, and it can be used in common for a plurality of transmission paths for broadcasting and communication.

WO2006/075590

An object of the technique disclosed in this specification is to provide an excellent transmission device and transmission method, as well as a reception device and reception method, capable of suitably transmitting control information related to transmission of data broadcasting applications.

The present application was made in consideration of the above problems, and the technology described in claim 1 is
a transmission unit that transmits each component that constitutes a broadcast service as a transmission unit based on a predetermined transport method;
an information transmission unit that transmits control information regarding transmission of the component;
and
wherein the information transmission unit transmits control information regarding pullback of the data broadcasting application transmitted from the transmission unit;
It is a transmitter.

According to the technique recited in claim 2 of the present application, in the transmission apparatus recited in claim 1, the predetermined transport scheme is MMT.

According to the technology described in claim 3 of the present application, the information transmission unit of the transmission device according to claim 1 performs entry in conjunction with a broadcast program composed of video and audio components transmitted from the transmission unit. - It is configured to send control information to direct a pull back to the application.

According to the technology recited in claim 4 of the present application, the information transmission unit of the transmission device according to claim 1 includes, in a first table indicating control information related to transmission of components of an application transmitted by the transmission unit: , a pull-back control descriptor instructing pull-back to the entry application is stored and transmitted in units of components.

According to the technique described in claim 5 of the present application, the information transmission unit of the transmission device described in claim 4 stores the pullback control descriptor indicating the pullback target for each component in the first Configured to send tables.

According to the technique recited in claim 6 of the present application, the information transmission unit of the transmission device recited in claim 1 performs pull-back to the entry application in the second table indicating information on the presentation unit of the data broadcasting application. is configured to store and transmit a pullback control descriptor that instructs in units of presentation.

According to the technique described in claim 7 of the present application, the information transmission unit of the transmission device described in claim 6 stores the pullback control descriptor indicating the pullback target in units of presentation for each data content. It is configured to transmit two tables.

According to the technology recited in claim 8 of the present application, the information transmission unit of the transmission device recited in claim 1 transmits information about data broadcasting applications to entry applications in a third table indicating information about data broadcasting applications for each data content. is configured to store and transmit a pullback control descriptor instructing pullback of the data content unit.

According to the technology recited in claim 9 of the present application, the transmission unit of the transmission device recited in claim 8 groups files constituting a data broadcasting application into transmission units based on the predetermined transport method and transmits the files. and the information transmitting unit is configured to transmit the third table in which the pullback control descriptor indicating the pullback target in units of transmission is stored for each data content.

According to the technique recited in claim 10 of the present application, the information transmission unit of the transmission device recited in claim 1 is configured to send a pull-back instruction for instructing pull-back to the entry application in the fourth table indicating operation control of the application. It is configured to store and transmit a control descriptor for each application.

According to the technique described in claim 11 of the present application, the information transmission unit of the transmission device according to claim 10 stores the pullback control descriptor specifying the application to be activated next for each application. is configured to send a table of

According to the technology recited in claim 12 of the present application, the information transmission unit of the transmission device recited in claim 1 includes a common descriptor applied to all applications in a fourth table indicating application operation control. , a pullback control descriptor that instructs a pullback to the entry application is stored and transmitted.

According to the technique recited in claim 13 of the present application, the information transmission unit of the transmission device recited in claim 12 transmits the pull-back control description indicating identification information of the application to be terminated for pull-back to the entry application. It is configured to transmit the fourth table with children arranged as the common descriptor.

In addition, the technology according to claim 14 of the present application is
a transmission step of transmitting each component constituting a broadcast service in transmission units based on a predetermined transport method;
an information transmission step of transmitting control information regarding transmission of the component;
has
the information transmission step transmits control information relating to pullback of the data broadcasting application transmitted in the transmission step;
transmission method.

In addition, the technology according to claim 14 of the present application is
a receiving unit that receives each component of a broadcast service transmitted in transmission units based on a predetermined transport method;
an information receiving unit that receives control information regarding transmission of the component;
and
the information receiving unit receives control information relating to pullback of the data broadcasting application received by the receiving unit;
It is a receiving device.

In addition, the technology according to claim 16 of the present application is
a receiving step of receiving each component of a broadcast service transmitted in transmission units based on a predetermined transport scheme;
an information receiving step of receiving control information relating to the transmission of said component;
has
In the information receiving step, control information relating to pullback of the data broadcasting application received in the receiving step is received.
reception method.

According to the technology disclosed in this specification, it is possible to provide an excellent transmission device and transmission method, as well as a reception device and reception method, capable of suitably transmitting control information related to transmission of data broadcasting applications.

According to the technology disclosed in this specification, for example, in a broadcasting system that transmits data broadcasting applications based on the MMT method, an excellent transmission device and transmission method that can suitably transmit control information regarding display switching of applications. , as well as a receiving device and a receiving method.

Note that the effects described in this specification are merely examples, and the effects of the present invention are not limited to these. Moreover, the present invention may have additional effects in addition to the effects described above.

Still other objects, features, and advantages of the technology disclosed in this specification will become apparent from more detailed description based on the embodiments described later and the accompanying drawings.

FIG. 1 is a diagram schematically showing a configuration example of a digital broadcasting system 10 to which the technique disclosed in this specification is applied. FIG. 2 shows a protocol stack 200 of a broadcasting system using the MMT scheme. FIG. 3 is a diagram showing a configuration example of the broadcast transmission system 11 that transmits the broadcast signal shown in FIG. FIG. 4 is a diagram showing a configuration example of the receiver 12 that receives the broadcast signal shown in FIG. FIG. 5 is a diagram showing an image of a broadcast signal 500 transmitted from the broadcast transmission system 11 to the broadcast transmission path according to the MMT/TLV system. FIG. 6 is a diagram showing a mechanism for designating each asset of the package from the MP table within the PA message. FIG. 7 is a diagram for explaining a mechanism for acquiring files constituting a data broadcasting application to be MMT-transmitted. FIG. 8 is a diagram showing an operation example of forced withdrawal of an application. FIG. 9 is a diagram showing a syntax example 900 of a data asset management table (DAMT) transmitted in a data transmission message. FIG. 10 is a diagram showing a syntax example 1000 of a descriptor for pullback control to an entry application placed in the data asset management table. FIG. 11 is a diagram showing a syntax example 1100 of a data content management table (DCCT). FIG. 12 is a diagram showing a syntax example 1200 of the data/contents management table used in the third embodiment. FIG. 13 is a diagram showing a syntax example 1300 of a descriptor for return control to an entry application placed in the data content information area of the data content management table. FIG. 14 is a diagram showing a syntax example 2000 of MH AIT (application information table). FIG. 15 is a diagram showing a syntax example 1500 of a descriptor (Forced_Return_descriptor) for controlling return to the entry application placed in the loop of the application information of the MH-AIT. FIG. 16 is a diagram showing a syntax example 1600 of a return control descriptor (Forced_Return_descriptor) placed in the MH-AIT common descriptor. FIG. 17 is a flow chart showing a processing procedure for the receiver to control execution of the data broadcasting application.

Hereinafter, embodiments of the technology disclosed in this specification will be described in detail with reference to the drawings.

FIG. 1 schematically shows a configuration example of a digital broadcasting system 10 to which the technique disclosed in this specification is applied. The illustrated digital broadcasting system 10 comprises a broadcasting transmission system 11 and a receiver 12 .

The broadcast transmission system 11 applies the MMT method to transmission of broadcast signals, and transmits each component constituting a broadcast service as an IP packet. Specifically, the code of the video signal and audio signal of the broadcast program, as well as the content related to the broadcast program (data broadcasting application, etc.) and subtitle signals are placed on the MMTP payload, converted into MMTP packets, and transmitted as IP packets. be done. Also, these IP packets are transmitted in the form of TLV packets on the broadcast transmission line. Here, components related to the main body of broadcast programs such as video, audio, and subtitles are timed media. In addition, content used for data broadcasting (such as data broadcasting applications described in HTML: Hyper Text Transfer Protocol) format is non-timed media.

On the other hand, the receiver 12 receives IP packets sent from the broadcast transmission system 11 through the broadcast transmission path. The receiver 12 then decodes transmission media such as video, audio, and subtitles from the received packets, and presents images and audio. Further, when the receiver 12 acquires each file data for data broadcasting from the received packet, the receiver 12 activates an application engine such as an HTML browser to present data broadcasting linked to the broadcast program.

FIG. 2 shows a protocol stack 200 of a broadcasting system using the MMT scheme.

One broadcast service consists of video 201 , audio 202 , subtitles 203 , application 204 and content download 205 components. Video 201 is coded 211 in HEVC (High Efficiency Video Coding) format, audio 202 is coded 212 in AAC (Advanced Audio Coding) format, and subtitles 203 are next film coded 213 . The application 204 also includes an EPG (Electric Program Guide), which is encoded 214 in HTML5 format.

On the MMT layer 220, these timed and non-timed media encoding components 211-214 are MPU formatted and MMTP packetized onto the MMTP payload. MMT-SI (Signaling Information) 221, which is control information (indicating the structure of a broadcast program, etc.) related to MMT, which is a media transport method, is also put on the MMTP payload and converted into MMTP packets. As the data transmission method 215 of the content download 205, there are four types of transmission method: caption/superimposed text transmission method, application transmission method, event/message transmission method, and general-purpose data transmission method.

In the UDP (User Datagram Protocol)/IP layer 230, MMTP packets are converted into IP packets. An NTP (Network Time Protocol) packet 206 containing current time information for timed media is also IP packetized. Further, these IP packets are converted into TLV packets at the TLV layer 240 and transmitted through the broadcast transmission line 250, which is the lowest physical layer. Also, the TLV-SI 241 related to the TLV multiplexing format for multiplexing IP packets is also TLV packetized and transmitted over the broadcast transmission line 250 . A transmission slot in which TLV packets are multiplexed is specified using TLV stream identification information (TLV_stream_id) from a TMCC (Transmission and Multiplexing Configuration Control) signal 251 on the transmission line.

FIG. 3 shows a configuration example of the broadcast transmission system 11 that transmits the broadcast signal shown in FIG. The broadcast transmission system 11 corresponds to, for example, a key station (program production station) that produces the main body of the broadcast program. The illustrated broadcast transmission system 11 includes a clock unit 301, a signal transmission unit 302, a video encoder 303, an audio encoder 304, a caption encoder 305, a signaling encoder 306, a file encoder 307, an electronic It comprises a data processing system (Electronic Data Processing System: EDPS) 308, a TLV signaling encoder 309, an IP service multiplexer (MUX) 310, a TLV multiplexer (MUX) 311, and a modulation/transmission unit 312. .

The clock unit 301 generates time information synchronized with time information obtained from an NTP server (not shown), and sends IP packets containing this time information to the IP service multiplexer 310 .

The signal transmission unit 302 is, for example, a recording/reproducing device such as a studio of a TV broadcasting station or a VTR. Send data (such as HTML document data) to video encoder 303, audio encoder 304, caption encoder 305, and file encoder 307, respectively.

The EDPS 308 is a scheduler of a TV broadcasting station and a file supply source, and controls data broadcasting applications which are non-timed media, control information indicating the structure of a broadcast program, and control information regarding multiplexing of IP packets, respectively, to a file encoder. 307 , signaling encoder 306 and TLV signaling encoder 309 .

The video encoder 303 HEVC-encodes the video signal sent from the signal sending unit 302 , further packetizes it, and sends IP packets including MMT packets of the video signal to the IP service multiplexer 310 . The audio encoder 304 also AAC-encodes the audio signal sent from the signal sending unit 302 , further packetizes it, and sends IP packets including MMT packets of the audio signal to the IP service multiplexer 310 . Caption encoder 305 also caption-encodes the caption signal sent from signal sending section 302 , further packetizes it, and sends IP packets including caption MMT packets to IP service multiplexer 310 .

The signaling encoder 306 generates a signaling message (MMT-SI) describing control information indicating the structure of the broadcast program based on the information sent from the EDPS 308, and the signaling message is arranged in the payload section. IP packets including MMT packets are sent to IP service multiplexer 310 . In this embodiment, signaling messages are roughly classified into three types: PA (Package Access) messages, M2 section messages, and data transmission messages.

The file encoder 307 encodes the data broadcasting application sent from the signal sending unit 302 or the EDPS 308 into file data in HTML5 format, further packetizes it, and sends IP packets including the MMT packets to the IP service multiplexer 310. send.

The broadcast transmission system 11 is equipped with an IP service multiplexer 310 for each channel (broadcast program) to be transmitted. One channel IP service multiplexer 310 multiplexes IP packets containing video, audio, subtitles, signaling messages (MMT-SI), and data broadcasting applications sent from each encoder 303-307. to generate a TLV packet that constitutes one broadcast service (channel).

Based on the information sent from the EDPS 308, the TLV signaling encoder 309 generates a TLV packet in which control information (TLV-SI) regarding multiplexing of the IP packets is arranged in the payload section.

The TLV multiplexer 311 multiplexes the TLV packets generated by the IP service multiplexers 310-1 to 310-N and the TLV signaling encoder 309 to generate a TLV stream identified by the TLV stream identification information. .

The modulation/transmission unit 312 performs RF modulation processing on the TLV stream generated by the TLV multiplexer 311, and sends it out to the broadcast transmission line.

The operation of the broadcast transmission system 11 shown in FIG. 3 will be described.

The clock unit 301 generates time information synchronized with time information obtained from an NTP server (not shown), and generates IP packets containing this time information.

A video signal sent from the signal sending unit 302 is supplied to the video encoder 303 . The video encoder 303 HEVC-encodes the video signal and further packetizes it to generate IP packets including MMT packets of the HEVC-encoded video signal. This IP packet is sent to IP service multiplexer 310 .

Similar processing is also performed on the audio signal and caption signal sent from the signal sending section 302 . That is, the IP packets containing the MMT packets of the AAC-encoded audio signal generated by the audio encoder 304 are sent to the IP service multiplexer 310, and the MMT packets of the caption-encoded signal generated by the caption encoder 305 are sent to the IP service multiplexer 310. The containing IP packet is sent to IP service multiplexer 310 .

Also, in the signaling encoder 306, a signaling message (MMT-SI) describing control information indicating the structure of the broadcast program is generated based on the information sent from the EDPS 308, and this signaling message is arranged in the payload section. An IP packet is generated containing the MMT packet. This IP packet is sent to IP service multiplexer 310 .

Also, the data broadcast application sent from the signal sending unit 302 or the EDPS 308 is supplied to the file encoder 307 . The file encoder 307 encodes the data broadcasting application into the HTML5 format, packetizes it, and generates IP packets including the MMT packets. This IP packet is sent to IP service multiplexer 310 .

Each IP service multiplexer 310 multiplexes IP packets each containing video, audio, caption, signaling message (MMT-SI), and file data (HTML5 document) sent from each encoder 303-307. are plexed to generate TLV packets that constitute one channel.

Based on the information sent from the EDPS 308, the TLV signaling encoder 309 generates a TLV packet in which the control information (TLV-SI) regarding multiplexing of the IP packets is placed in the payload section.

The TLV multiplexer 311 multiplexes the TLV packets generated by the IP service multiplexers 310-1 to 310-N and the TLV signaling encoder 309 to generate a TLV stream. The modulation/transmission unit 312 performs RF modulation processing on the TLV stream generated by the TLV multiplexer 311, and the RF modulated signal is sent to the broadcast transmission path.

FIG. 4 shows a configuration example of the receiver 12 that receives the broadcast signal shown in FIG. The illustrated receiver 12 includes a tuner/demodulator 401, a demultiplexer (DEMUX) 402, a clock recovery unit 403, a video decoder 404, an audio decoder 405, a caption decoder 406, and a system control unit. 407 , an application control unit 408 , a cache memory 408 , an application engine 409 , an IP interface (I/F) 410 and a synthesizing unit 411 . The illustrated receiver 12 includes, for example, a television receiver or set top box installed in the home, as well as an IPTV or CATV retransmitter.

A tuner/demodulator 401 selects and receives a broadcast signal, performs demodulation processing, and obtains a TLV stream. Demultiplexer 402 performs demultiplexing and depacketization on this TLV stream. In this embodiment, demultiplexer 402 comprises TLV filter 402-1, IP filter 402-2, UDP filter 402-3, MMT filter 402-4, and SI filter 402-5.

The TLV filter 402-1 filters TLV packets broadcasted based on the TLV stream identification information. IP filter 402-2 filters IP packets from TLV packets and also filters IP packets received via IP interface 410 based on IP address. Also, the UDP filter 402-3 filters UDP packets. The MMT filter 402-4 filters the MMTP packets from the IP packets based on the information in the MMTP header (described below) to produce MMTP packets carrying video, audio, subtitle, and application coded components, respectively. A video decoder 404 , an audio decoder 405 , a caption decoder 406 and an application engine 409 . SI filter 402-5 filters signaling information SI and distributes it to system control unit 407 and application control unit 408, respectively. SI filter 402-5 shall include an MMT-SI filter for filtering MMT-SI from the MMT stream and a TLV-SI filter for filtering TLV-SI from the TLV stream.

Based on the current time information contained in the NTP packet filtered by the IP filter 402-2 and the UDP filter 402-3 in the demultiplexer 402, the clock recovery unit 403 generates time information synchronized with this time information. Then, each timed media is decoded and output to the video decoder 404, the audio decoder 405, and the caption decoder 406, respectively.

A video decoder 404 decodes the encoded video signal obtained by the demultiplexer 402 to obtain a baseband video signal. Also, the audio decoder 405 decodes the encoded audio signal obtained by the demultiplexer 402 to obtain a baseband audio signal. Also, the caption decoder 406 decodes the caption coded signal obtained by the demultiplexer 402 to obtain a caption display signal.

Application control section 408 controls data broadcasting application processing based on signaling information received via SI filter 402-5. For example, when the application control unit 407 analyzes the MMT-SI and finds the data broadcasting application set as the default entry, it instructs the application engine 409 to present the data broadcasting.

In the broadcasting system 10 according to this embodiment, it is assumed that the data broadcasting application is transmitted from two systems, ie, the broadcasting signal and the IP network. In the former system, it is received by the tuner/demodulator 401, and in the latter system, it is received by the IP interface 410. In both cases, MMT packets packetized in the demultiplexer 402 are sent to the application engine 409 by the MMT filter 402-4. distributed.

The application engine 409 is, for example, an HTML browser or the like, processes file data (HTML5 document or the like), which is an entity of the data broadcasting application, and generates a data broadcasting display signal. The application engine 409 can also acquire file data necessary for displaying data broadcasting (monomedia used for displaying data broadcasting, linked applications, etc.) from the IP network via the IP interface 410. .

The system control unit 410 controls the operation of each unit of the receiver 12 based on the signaling information received via the SI filter 402-5 and the operation information from the user via the user operation unit (not shown). . Also, the system control unit 410 controls the decoding timings of the decoders 404 to 406 based on the signaling information, and adjusts the presentation timings of video, audio, and subtitles. The synthesizing unit 411 synthesizes the caption display signal and the data broadcasting display signal with the baseband video signal to obtain a video signal for video display. Also, the baseband audio signal obtained by the audio decoder 405 becomes an audio signal for audio output. A main broadcast program consisting of a video signal and an audio signal is output as video and audio from a monitor display (not shown). The data broadcast processed by the data broadcast application engine 409 is also superimposed on the screen of the main part of the broadcast program and displayed on the monitor display.

The IP interface 410 is configured by, for example, a network interface card, connects to an IP network such as the Internet or a home network, and performs transmission/reception processing of IP packets.

Also, in this embodiment, it is assumed that the IP packet filtered based on the IP address by the IP filter 402-2 is transmitted or retransmitted from the IP interface 410 to the IP network. Further, when it is found that the broadcast service can be filtered only by IP address, the specific service can be extracted only by the IP filter 402-2 in the demultiplexer 402 and transferred from the receiver 12 to the outside.

The operation of the receiver 12 shown in FIG. 4 will be described.

A tuner/demodulator 401 receives a broadcast signal, performs demodulation processing, and obtains a TLV stream. In the demultiplexer 402, this TLV stream is subjected to demultiplexing and packetization processing, and NTP time information, video, audio, subtitles, each coded signal of data broadcasting, and signaling information are extracted. and distributed to a video decoder 404, an audio decoder 405, a caption decoder 406, an application engine 409, a system controller 407, and an application controller 408, respectively. Similarly, the IP packets received by the IP interface 410 are also demultiplexed and packetized, and distributed to the respective units.

Also, the NTP packets extracted by the demultiplexer 402 are distributed to the clock recovery unit 403 . Based on the time information carried in the NTP packet, the clock recovery unit 403 generates time information synchronized with this time information. That is, the clock recovery unit 403 generates time information matching the time information generated by the clock unit 301 on the broadcast transmission system 11 side.

The encoded video signal extracted by the demultiplexer 402 is sent to the video decoder 404 and decoded to obtain a baseband video signal. Also, the caption coded signal extracted by the demultiplexer 402 is sent to the caption decoder 406 and decoded to obtain a caption display signal.

Application control section 408 controls the processing of the data broadcasting application based on the signaling information received via SI filter 402-5. An application engine 409 comprising an HTML browser or the like processes the coded signal (HTML5 document) of the data broadcasting application extracted by the demultiplexer 402 according to the instruction from the application control unit 408, and converts it into a data broadcasting display signal. is obtained.

The synthesizing unit 411 synthesizes the caption display signal and the data broadcasting display signal with the baseband video signal to obtain a video signal for screen display. Also, the encoded audio signal extracted by the demultiplexer 402 is sent to the audio decoder 405 and decoded to obtain a baseband audio signal for audio output. The video and audio signals are output from a monitor display (not shown).

In the digital broadcasting system 10 shown in FIG. 1, it is assumed that a broadcasting signal is transmitted from the broadcasting transmission system 11 to the receiver 12 by the MMT method. FIG. 5 shows an image of a broadcast signal 500 transmitted from the broadcast transmission system 11 to the broadcast transmission path according to the MMT system.

Broadcast signals of one service (channel: broadcast program) consist of timed media related to the main part of the broadcast program such as video, audio, subtitles, etc., and non-timed media such as file data used for data broadcasting linked to the broadcast program. Consists of media. The media data obtained by encoding these is converted into MPU format, MMTP packetized, and transmitted in IP packets. Signaling information (MMT-SI) (indicating the structure of broadcast programs, etc.) related to MMT, which is a media transport method, is also transmitted in IP packets. These IP packets are transmitted as a TLV stream in the form of TLV packets on the broadcast transmission line. Signaling information (TLV-SI) related to TLV multiplexing format for multiplexing IP packets is also transmitted in the form of TLV packets.

In the MMT system, it is easy to use timed media data and non-timed media data constituting one channel (broadcast program) by combining different transmission paths. In the example shown in FIG. 5, as a broadcast signal 500, MMT transmission paths 501 to 504 are used for each type of data such as video, audio, subtitles, file data, and signaling information. Each MMT transmission path corresponds to one IP data flow. The IP data flow referred to here means that the values of the five fields of IP header and UDP header source IP address, destination IP address, IP header protocol type, source port number, and destination port number are all the same. is a set of IP packets. In the figure, the illustration of the transmission path for caption data is omitted for the sake of convenience. Also, the TLV-SI stream is omitted in FIG.

The broadcasting system 11 of the MMT method is a method of transmitting IP packets on a broadcasting transmission path, and can be operated such that one IP address is mapped for each broadcasting service (or each broadcasting station). In such a case, the receiver can access each MMT transmission line 501 to 504 of the desired broadcasting service (or desired broadcasting station) by filtering the broadcast signal 500 based on the IP address. . MMTP (MMT protocol) packets transmitted on each of the MMT transmission lines 501 to 504 within the same IP address can be uniquely specified by packet identification information (packet_id: PID). Also, MMTP packets on different IP addresses can be specified by a combination of packet identification information, IP address, and port number.

One channel (broadcast program) can be said to be a "package" composed of a plurality of different types of assets such as video, audio, subtitles, and file data (data broadcasting application). A "package" here is a logical set of media data that is transmitted using an MMT transmission line. Also, as used herein, an "asset" is an entity of data used to compose a multimedia presentation that is associated with a unique asset identification.

Each asset consists of a collection (logical group) of one or more MPUs that share the same asset identification information. The MPU can be said to be a format that is a transmission unit in the MMT system. Each MPU is transmitted on dedicated ES (Elementary Stream), ie, MMT transmission lines 501 to 503 for each asset. That is, the transmission line 501 transmits an MMTP packet of an encoded video signal composed of an MPU logical group of video signals having common asset identification information, and a transmission line 502 transmits an MPU logical group of audio signals having common asset identification information. MMT packets of encoded audio signals are transmitted on transmission path 503, and MMT packets of encoded applications composed of MPU logical groups of data broadcasting applications having common asset identification information are transmitted. Each MPU is identified by asset identification information and an MPU sequence number on the corresponding transmission line. Also, the MMT transmission line that transmits each medium can be identified by asset identification information.

In addition, a single package (broadcast program) may transmit multiple assets of the same type (that is, with different asset identification information). For example, two or more data broadcasting applications are provided for the same broadcast program. For example, a program-linked data broadcasting application that is linked to a broadcast program and a program-unlinked data broadcasting application that is not linked to a broadcast program (for example, weather forecast, news, etc.) usually have separate asset identification information as separate assets. allocated and transmitted on different MMT transmission lines as separate MPU logical groups. FIG. 5 depicts a transmission path 503-1 for a data broadcasting application linked to a broadcast program and a transmission path 503-2 for a data broadcasting application not linked to a broadcast program.

Also, the MMT system can be used in common for a plurality of transmission paths for broadcasting and communications. For example, non-timed media such as data broadcasting applications (HTML5 documents, etc.) are transmitted together with timed media using the broadcast signal transmission path 503 as shown in FIG. It can also be provided via a path (not shown).

In transmission path 504, MMTP packets containing MMT-SI, which is a transmission control signal indicating information related to the configuration of MMT packages and broadcasting services, are repeatedly transmitted by the carousel method. The MMT-SI signaling messages transmitted on transmission path 504 include PA message 510, M2 section message 520, and data transmission message 530. FIG.

For example, the PA message 510 is control information indicating the structure of a broadcast program, and includes an MP (MMT Package) table 511 describing information constituting a package such as a list of assets and their positions.

The PA message 510 is the entry point of the broadcast service, and fixed packet identification information (eg, 0x0000) is assigned to the MMTP packet that transmits the PA message 510 . Therefore, the receiver side can acquire the PA message 510 by designating the fixed packet identification information on the MMT transmission line 504 . Then, referring to the MP table 511 transmitted by the PA message 510, each asset (video, audio, caption, file data (data broadcasting application), etc.) constituting the package (broadcast program) can be specified. .

Also, the M2 section message 520 is a message that transmits the section extension format of MPEG-2 Systems. A signaling table such as MH-AIT (Application Information Table) 521 is stored in the M2 section message 520 . MH-AIT 521 is a table for transmitting dynamic control information related to applications and additional information necessary for execution. application), and location (URL). As an application processing method, AUTOSTART (AS) indicating automatic start of the application, PRESENT (PR) indicating that the application is ready to run, KILL indicating termination of the application, acquisition and retention of the application (pre-cache). PREFETCH shown can be mentioned.

Also, the data transmission message 530 is a message for transmitting control information regarding the transmission of the data broadcasting application. Each signaling table of a data directory management table 531 , a data asset management table 532 and a data content management table 533 is stored in one data transmission message 530 .

The data directory management table 531 is a table for managing data broadcasting applications in directory units (in other words, data broadcasting application production units). This table describes the directory structure related to the directories included in one package and the subdirectories and files (items) included in the directory, so the file configuration of the application and the configuration for file transmission can be separated. can.

The data asset management table 532 is a table for managing data broadcasting applications on an asset-by-asset basis, and describes the configuration of the MPUs in the asset and version information for each MPU.

The data content management table 533 is a table for managing presentation units (PUs) of data broadcasting applications and file information that constitute each data content. The "data content" referred to here generally corresponds to the entire associated application data of one broadcast program. If the table is presentation unit (PU) information, the configuration information of the data broadcasting application file is described in the data broadcasting presentation unit (PU), and the file data for the data broadcasting application is flexible and effective. It can be used for various cache control.

In the data broadcasting application transmission method by MMT, by utilizing the above-mentioned three types of signaling tables 531 to 533 transmitted by data transmission messages, the transmission data structure for each file and the directory structure in content (data broadcasting application) production. can independently express a data structure in units of use, such as application units and presentation units, for effective use of cache memory in the receiver (for example, Japanese Patent Application No. 2014 -88630).

Packet identification information of messages and tables transmitted as MMT-SI may be fixed or indirectly specified from other tables. Among them, the PA message is the entry point of the broadcasting service and is assigned fixed packet identification information (eg, 0x0000). The MP table transmitted by the PA message specifies each asset (video, audio, caption, file data (data broadcasting application), etc.) that constitutes the package (broadcast program). Therefore, as shown in FIG. 12, each asset (video, audio, caption, file data (data broadcasting application), etc.) that constitutes a package (broadcast program) can be designated by referring to the MP table.

FIG. 7 illustrates a mechanism for acquiring data broadcast application items multiplexed in the same IP data flow.

A file constituting a data broadcasting application is specified with a path name in an application description such as HTML5. A path name here is written as a combination of a directory node name and a file name. Also, a node tag is defined as a descriptor that integrates directory nodes and files, and is used as information for linking each signaling table.

When a path name is specified from the data broadcasting application, as indicated by reference number 701, the node tag of the file with the specified path name can be obtained from the data directory management table within the data transmission message.

Next, as indicated by reference number 702, the component tag of the asset to which the item having the node tag obtained in the data directory management table is transmitted from the data asset management table in the data transmission message, the download identification Information, MPU sequence number, and item identification information can be obtained.

Further, as indicated by reference number 703, when the location information of the asset having the component tag obtained in the data asset management table is obtained from the MP table, as indicated by reference number 704, the corresponding file is actually Data assets to be transmitted can be identified.

Then, within the specified data asset, the file corresponding to the carousel is repeated by the download identification information obtained from the data asset management table and the download identification information described in the header area of the MMTP packet that transmits the item. A unit of transmission can be uniquely identified. As indicated by reference number 705, among the repeatedly transmitted items, the item having the MPU sequence number and item identification information obtained from the data asset management table can be designated as the desired file. It is assumed that the node tag is unique within a data transmission message, the MPU sequence number is unique within an asset (IP data flow), and the item identification information is unique within a service provider.

Data broadcasting applications can be broadly classified into program-linked data broadcasting applications that are linked to broadcast programs and program-unlinked data broadcasting applications that are not particularly linked to broadcast programs, such as news and weather forecasts. There is a demand on the broadcasting station side to forcibly switch the display to the program-linked data broadcasting application in conjunction with the broadcast program. "In conjunction with the broadcast program" means when the broadcast program is switched, or when the corner within the broadcast program is switched. Even if the non-program-linked data broadcasting application is being executed at such timing, it is terminated and forced to the program-linked data broadcasting application designated as the entry in the broadcast program (or corner within the program). There is a demand for broadcasting stations to pull back.

FIG. 8 schematically shows a case where forced return to the program-linked data broadcasting application specified in the entry is performed.

In FIG. 8, an MMT broadcasting transmission line is assumed, and a video asset 801, an audio asset 802, and data broadcasting application assets 803 and 804 are transmitted through dedicated MMT transmission lines. However, reference number 803 is the asset of the program-linked data broadcasting application, and reference number 804 is the asset of the non-program-linked data broadcasting application.

In addition to the MMT transmission of assets, an event information table (EIT), an application information table (AIT), and data directory management are shown by reference numbers 811 to 816 as control information (MMT-SI) related to MMT. Various signaling tables such as table (DDMT), data asset management table (DAMT), data content management table (DCCT), event message table (EMT) are transmitted. Of these, the event information table 811 describes the program name, broadcast date and time, program content, etc., and is updated when the program is changed or terminated. The application information table also indicates the processing method of each application, and describes, for example, applications to be automatically started (AS) and applications in the executable state (PR). Executable applications are all program-linked and non-program-linked applications transmitted within assets 803 and 804 . Also, the application to be automatically started corresponds to the broadcast-linked data broadcasting application that becomes an entry in the broadcast program (or a corner within the program). Event message table 816 also carries information about event messages.

The horizontal direction in FIG. 8 corresponds to the time axis. At time t1, broadcast program P1 starts airing, at time t2, the corner within the broadcast program P1 changes, and at time t3, broadcast program P1 ends. Assume that the next broadcast program P2 starts.

In the asset 803, the application to be transmitted is changed in conjunction with the switching of the program and the switching of the program segment. Specifically, the program-linked applications app1 and app2 are transmitted during the period from time t1 to t2, and the program-linked applications app6 and app7 are transmitted during the period from time t2 to t3. After time t3, the transmission of the program-linked application is stopped. On the other hand, in the asset 804, the non-program-linked applications app3 and app4 continue to be transmitted without interlocking with the switching of programs or the switching of program corners.

In the period from time t1 to t2, the application information table 811 indicates app1 as an application (AS) to be automatically started, and is transmitted as an executable application (PR) in the assets 803 and 804 within the same period. all other applications app2, app3, app4. In addition, during the period from time t2 to t3, app6 is indicated to the application (AS) to be automatically started, and all other applications transmitted within the same period by the assets 803 and 804 as ready-to-run applications (PR). , the applications app7, app3, and app4 are shown. After time t3, the program non-interlocking application app3 is indicated as an application (AS) to be automatically activated, and the application app4 is indicated as an executable application (PR).

At the bottom of FIG. 8, the reference relationship of the applications and the transition of the display of the applications in each period are shown. During the period from time t1 to t2, app1 is designated as an entry application, and app1 refers to program-linked application app2 and program-unlinked application app3. Furthermore, app3 refers to application app4, which is also program-unlinked. In the period from time t2 to t3, app6 is designated as an entry application, and app1 refers to program-linked application app7 and program-unlinked application app3. Furthermore, app3 refers to application app4, which is program-unlinked, as before time t2.

The entry application app1 is automatically activated in conjunction with the start of the broadcast program P1 on air at time t1. After that, it is assumed that the display of the data broadcasting is changed to the program-unlinked application app3 according to the user's remote control operation or the like. Then, at time t2, the entry application switches to app6 in conjunction with the change of the corner in the broadcast program P1. In such a case, the broadcasting station that broadcasts the broadcast program P1 is requested to forcibly terminate the program-unlinked application app3 and return to the display of the program-linked application app6 as an entry.

In the conventional BML-format data broadcasting application transmission method, it is possible to forcibly return to a desired data broadcasting application by signaling a return flag (return_entry_flag).

In contrast, this specification describes several embodiments in which a signaling message regarding data transmission instructs forced switching of data broadcasting applications in a broadcasting system that employs the MMT method.

In the first embodiment, by arranging a descriptor for return control to the entry application in the data asset management table (see FIG. 5) transmitted in the data transmission message, Implement forced retraction.

FIG. 9 shows a syntax example 900 of a data asset management table (DAMT) transmitted in a data transmission message. The data asset management table is a table for managing data broadcasting applications in units of assets, and describes the configuration of MPUs in assets and version information for each MPU.

table_id (table identification) is an 8-bit fixed value indicating a data asset management table in various signaling information. version_ (version) is an 8-bit integer parameter indicating the version of this data asset management table. For example, if even some of the parameters that make up the data asset management table are updated, the version is incremented by +1. length is a 16-bit long parameter that indicates the size in bytes of this data asset management table, counted immediately after this field.

number_of_data_components is an 8-bit parameter that indicates the number of data components included in the package (ie, the number of datacast application assets). For example, it is assumed that two types of data components, a program-linked data broadcasting application and a program-unlinked data broadcasting application, are transmitted in one package (broadcast program). A loop of the following data components (that is, assets) is arranged for the number of number_of_data_components, and information for each data component is stored. In each data component loop (or asset loop), attribute information of the data component and MPU information included in the data component are written.

Attribute information of the data component includes transaction_id (transaction identification information), component_tag, and download_id (download identification information). transaction_id is an identifier with a version function of the data component. component_tag is a label for identifying the stream of the data component. Let the component_tag be the same value as the component_tag in the MH stream identifier descriptor placed as the asset descriptor in the MP table. download_id serves as a label to uniquely identify data content. MMTP packets that transmit applications (non-timed media) are written with download identification information in extension headers as needed.

num_of_mpus indicates the number of MPUs included in the data component. Attribute information of each MPU is stored in a loop of MPUs arranged for the number of num_of_mpus. MPU_sequence_number is the MPU sequence number assigned to the MPU. num_of_items indicates the number of items (file data) contained in the MPU. Information of each item is stored in the loop of the items arranged by the number of num_of_items.

Item attribute information and item-related information are stored in the loop of one item. Item_id, node_tag, item_size, item_version, and item_checksum are stored as item attribute information. item_id is a 32-bit value that uniquely identifies an item on the MMT transmission path. node_tag is a 16-bit value that identifies the item as the node tag corresponding to the item. By using a 16-bit node_tag instead of a 32-bit item_id as signaling information, the bit size required to identify an item on a data transmission message can be reduced. item_size represents the size of the item in bytes. item_version indicates the version of the item, and version is incremented by +1 each time the content of the item is updated. item_checksum indicates the checksum of the item. It should be noted that setting the checksum for all files is considered to be a large amount of information, so a 1-bit check_sum_flag is set, and only when 1 is assigned to it, a 32-bit item_check_sum appears. . checksum_flag is a flag indicating whether or not checksum is described. When this flag is 1, item_checksum is described. item_info_length indicates the byte length of the subsequent item information area, and item information is written in units of bytes (item_info_byte) in a series of areas consisting of loops for this number of bytes.

Information of each MPU is stored in the MPU loop. Specifically, MPU_info_length indicates the byte length of the succeeding MPU information area, and information about the MPU is written in units of bytes (item_info_byte) in a series of areas consisting of loops for this number of bytes.

At the end of the asset loop, a descriptor describing information for each asset is placed. Specifically, descriptor_loop_length indicates the total byte length of descriptor. The descriptor stores descriptors describing information in units of assets in a series of areas consisting of loops for the number of descriptor_loop_length. Descriptors to be stored are defined separately.

In the first embodiment, a descriptor (returnToEntry_descriptor) for controlling return to the entry application is arranged as a descriptor that describes information in units of assets.

FIG. 10 shows a syntax example 1000 of a descriptor (returnToEntry_descriptor) for return control to an entry application placed in the data asset management table.

descriptor_tag is an 8-bit integer value that identifies the descriptor 1000 in question. descriptor_length is an area in which the byte length of the data of the descriptor 1000 following this field is written. Return_to_entry_flag indicates whether or not to perform forced return.

Also in the first embodiment, there are two methods of applying the descriptor of the pullback control to the entry application. The first method is to place the pullback control descriptor shown in FIG. does not place a pullback control descriptor. As a result, if the receiver is executing an application other than the application transmitted by the data asset including the auto-start application, the receiver terminates the application and starts the entry application. Consider the receiver operation in this case. For example, when the time t2 arrives and the data asset management table is updated, the receiver checks its contents. The receiver has switched to the execution of app3, which is a non-program-linked application, during the period from time t1 to t2. is immediately terminated, and app6, which is an entry application, is started.

The second method places a pullback control descriptor in the loop of the data asset to be pulled back in the data asset management table. As a result, if the receiver is running an application included in the data asset in which the descriptor is placed, the receiver terminates the application and starts the entry application. Consider the receiver operation in this case. For example, when the time t2 arrives and the data asset management table is updated, the receiver checks its contents. The receiver has switched to the execution of app3, which is a program-unlinked application, during the period from time t1 to t2. Since the child is located, immediately exit app3 and launch the entry application app6.

In this way, by using the data asset management table, it is possible to control the forced pullback of the application on an asset-by-asset basis.

In the second embodiment, by arranging a descriptor for return control to the entry application in the data content management table (see FIG. 5) transmitted by the data transmission message, Implement forced retraction.

FIG. 11 shows a syntax example 1100 of a data content control table (DCCT) transmitted in a data transmission message. The data content management table is a table for managing data broadcasting applications for each presentation unit (PU). This table describes the configuration information of the file of the data broadcasting application in units of presentation (PU) of the data broadcasting.

In table_id (table identifier), an 8-bit fixed value indicating a data content management table is written in various signaling information. version_ (version) is an 8-bit integer parameter indicating the version of the data/contents management table. For example, if even some of the parameters that make up the table are updated, the version is incremented by +1. length is a 16-bit length parameter that indicates the size of the data content management table in bytes, counted immediately after this field.

number_of_contents is an 8-bit parameter indicating the number of data contents transmitted in a package (broadcast program). The following data content loops are arranged for the number of number_of_contents, and information for each data content is stored. Data content generally corresponds to the entire cooperating application data of one broadcast program.

In the loop of one data content, as attribute information of the data content, content_id, content_version, content_size, and PU_info_flag are described, and the presentation unit (PU) of the data broadcasting application constituting the data content is described. Or information about the file is written. content_id (content identification information) is a label that uniquely identifies the data content. content_version is an area in which the version number of the data content is written. content_size is an area to write the size of the data content. Further, PU_info_flag is a flag indicating whether or not the loop of the data content indicates presentation unit (PU) information.

PU_info_flag=1 indicates that the data content loop is presentation unit (PU) information. Information of the presentation unit (PU) of the data broadcasting application constituting the data content is stored in the subsequent area in this case. The number of PUs included in the data content is written in number_of_PUs, followed by a loop of PUs for the number of number_of_PUs.

In the loop of one PU, PU_tag, which is identification information of the PU, PU_size, which is an area for writing the size of the PU, and number_of_member_nodes, which indicates the number of node designations of files or directories that constitute the PU, are written. Then, in a loop of nodes arranged for the number of number_of_member_nodes, a node tag that identifies a file or directory that constitutes the PU is written.

Further, PU information is written in the loop of one PU. Specifically, the byte length of the PU information is indicated in PU_info_length, and the PU information is written in units of bytes (PU_info_byte) in a series of areas consisting of loops corresponding to this number of bytes.

On the other hand, PU_info_flag=0 indicates that the loop of the data content is file information. In this case, the subsequent area is written with the information of the files or directories that make up the data content. Specifically, number_of_nodes is written to indicate the number of node designations of files or directories that constitute the data content. Then, in a loop of nodes arranged by number_of_nodes, a node tag identifying a file or directory constituting the data content is written.

As shown in FIG. 11, in the loop of PUs in the data/contents management table, information on PUs can be stored for each presentation unit PU that constitutes data/contents (provided that PU_info_flag=1). . In the second embodiment, this information area is used to arrange a descriptor (returnToEntry_descriptor) for control of return to the entry application to control forced return of the application for each presentation of the application.

The syntax of the pullback control descriptor placed in the information area for each PU may be the same as in FIG. The return_to_entry_flag of the return control descriptor indicates whether or not to perform forced return.

Also in the second embodiment, there are two methods of applying the pullback control descriptor to the entry application. In the first method, the pullback control descriptor is placed in the PU information area of the loop of the PU including the auto-start application in the data content management table, but the pullback control descriptor is placed in the loop of other PUs. do not do. Since a PU including an auto-start application can be identified by PU_tag=0, the pullback control descriptor is placed only in the loop of the PU with PU_tag=0, and the pullback control descriptor is placed in the loop of the PU whose PU_tag is not 0. Do not place Indicates that applications included in PUs that do not have a pullback control descriptor placed should be terminated when forced pullback to an auto-launch application. The second method is, conversely, in a loop of PUs that do not include auto-start applications, placing a pullback control descriptor in the PU information area of the PU to be pulled back. It indicates that the application included in the PU in which the pullback control descriptor is placed should be terminated at the time of forced pullback to the auto-start application.

Consider the behavior on the receiver side when placing pullback control descriptors only in loops for PUs with PU_tag=0. For example, when the time t2 arrives and the data content management table is updated, the receiver checks the content. The receiver has switched to the execution of app3, which is a program-unlinked application, during the period from time t1 to t2, but in the updated data/contents management table, the pullback control descriptor is PU_tag=0 PU loop immediately terminates app3. As a result, the receiver can automatically activate app6, which is designated as the entry application after time t2, as requested by the broadcasting station.

In this way, by arranging a descriptor (returnToEntry_descriptor) for controlling return to the entry application in the loop of the PU of the data content management table, it is possible to control forced return of the application in units of presentation (PU). .

In the third embodiment, as in the second embodiment, a forced return to the entry application is realized by arranging a return control descriptor to the entry application in the data content management table. However, in the third embodiment, the pull-back control descriptor is arranged in the loop of the upper data content, not the loop of the PU, and the forced pull-back to the entry application is performed in units of the data content higher than the PU. Control.

In the third embodiment, a data content information area for arranging a pullback control descriptor is newly defined in the data content loop of the data content management table. FIG. 12 shows a syntax example 1200 of the data/contents management table used in the third embodiment. The parts that are different from the example syntax 1100 of FIG. 11 are enclosed by dotted lines. This syntax example 1200 will be described below, but the parameters that overlap with those in FIG. 11 will be described.

As indicated by reference number 1201, content_info_flag is defined after PU_info_flag as attribute information of the data content in the data content loop. content_info_flag is a flag indicating whether or not the data content loop includes data content information.

content_info_flag=1 indicates that the data content loop includes data content information. In this case, an area for storing data content information is defined at the end of the data content loop. Specifically, as indicated by reference number 1202, content_info_length indicates the byte length of the data content information, and the data content information is stored in byte units (content_info_byte) in a series of areas consisting of loops for this number of bytes. written.

In the third embodiment, the information area of this data content is used to place a descriptor (returnToEntry_descriptor) for controlling return to entry application, and to control forced return of the application in units of presentation of the application.

FIG. 13 shows a syntax example 1300 of a descriptor (returnToEntry_descriptor) for controlling return to the entry application, which is placed in the data content information area of the data content management table.

descriptor_tag is an 8-bit integer value that identifies the descriptor 1300 in question. descriptor_length is an area in which the byte length of the data of the descriptor 1300 following this field is written. In PU_number_of_target_to_return, the number of PUs included in the data content and specified to end when the application is forced to return is written. Then, in the loop arranged by the number of PU_number_of_target_to_return, a PU tag is written that identifies each PU that should be terminated when the application is forced to return.

Consider the operation on the receiver side in this case. For example, when the time t2 arrives and the data content management table is updated, the receiver checks the content. The receiver switches to the execution of the program-unlinked application app3 during the period from time t1 to t2. Since the tag of the presentation unit (PU) containing app3 is specified in the pullback control descriptor placed in the loop, app3 is terminated immediately. As a result, the receiver can automatically activate app6, which is designated as the entry application after time t2, as requested by the broadcasting station.

In this way, by arranging a descriptor (returnToEntry_descriptor) for control of returning to the entry application in the data content newly defined in the data content loop of the data content management table, presentation is made for each data content. It is possible to control forced pullback of applications in units (PU).

In a fourth embodiment, the entry application is executed by placing the descriptor of the pull-back control to the entry application in the MH-AIT (application information table) (see FIG. 5) transmitted in the M2 section message. • Implement a forced pullback to the application.

FIG. 14 shows a syntax example 1400 of MH-AIT transmitted in the M2 section message. MH-AIT is a table for transmitting dynamic control information related to applications and additional information necessary for execution. application), and location (URL).

table_id (table identification) is an 8-bit fixed value that identifies an application information (AI) table in various signaling information, and is 0x89 in this embodiment. The section_syntax_indicator (section syntax indicator) is a 1-bit field and is always "1". sectoin_length (section length) is a 12-bit field that defines the byte length of the section from the section length field to the end of the section including CRC32. This value shall not exceed 4093 (0xEFD in hexadecimal). application_type (application format) is a 16-bit field and indicates the value of the application transmitted by AIT. In DVB, 0x0001 is assigned to DVB-J applications. It is also set to 0x0001 in the ARIB-J application. The version_number (version number) is a 5-bit field and is the version number of the sub-table. version_number is the version number of the MH AI table, and is incremented by +1 when information in the sub-table changes. Also, when the value of the version number becomes "31", it returns to "0". The current_next_indicator (current/next indicator) is always “1”. section_number (section number) is an 8-bit field and represents the number of the section. The section number of the first section in the sub-table is 0x00. The section number is incremented by +1 each time a section with the same table identification and application type is added. last_section_number (last section number) is an 8-bit field and defines the last section number in the sub-table to which the section belongs.

common_descriptor_length (common descriptor loop length) is an 8-bit field that indicates the byte length of the subsequent descriptor (descriptor in the description area). children) are written. The descriptors in this common descriptor area apply to all applications in the AIT subtable.

application_loop_length is an area to write the number of application information included in this MH AI table. Then, loops of application information are arranged for the number indicated by application_loop_length. And, at the end of the table, ITU-T Recommendation H.264. A cyclic redundancy code CRC32 (CRC) according to H.222.0 is added.

Application_identifier (application identifier), application_control_code (application control code), and application information are arranged in one application information loop.

application_identifier (application identifier) is a parameter that identifies an application. Also, application_control_code (application control code) is an 8-bit field that defines a control code for controlling the state of the application. The semantics of application control codes depend on the application type value. Table 1 shows the semantics of the application control code when it is independent of the application format. Also, application_descriptor_loop_length (application information descriptor loop length) indicates the byte length of the application information descriptor, and the descriptor (application information descriptor) is written in a series of areas consisting of loops for this number of bytes. The application information descriptor in this descriptor area is different from the common descriptor and applies only to the application specified by application_identifier in this loop.

As shown in FIG. 14, an application information descriptor (descriptor) that stores information of the corresponding application is arranged in the loop of the application information of the MH-AIT. In the fourth embodiment, a descriptor for control of pullback to the entry application is placed in this descriptor area to control forced pullback of the application on an application basis. In the fourth embodiment, two pullback control descriptor syntaxes are possible. The first method is to apply the return control descriptor (returnToEntry descriptor) shown in FIG. As a result, the execution of the application specified by the descriptor is terminated and the entry application specified for autostart is started. Consider the operation on the receiver side in this case. For example, when time t2 arrives and MH-AIT is updated, the receiver checks its contents. The receiver switches to the execution of the program-unlinked application app3 during the period from time t1 to t2. Terminate app3 immediately since the child has been placed. As a result, the receiver can automatically activate app6, which is designated as the entry application after time t2, as requested by the broadcasting station. As a modification of this embodiment, one bit of reserved_for_future present in the MH-AIT application information loop or application control descriptor may be used as returnToEntry.

The second method is a method of applying the descriptor (Forced_Return_descriptor) of the return control shown in FIG.

descriptor_tag is an 8-bit integer value that identifies the descriptor 1500 in question. descriptor_length is an area in which the byte length of the data of the descriptor 1500 following this field is written. Also, application_identifier indicates application identification information for identifying the application to be executed next when the application is forcibly pulled back.

In the application information loop of the MH-AIT, a withdrawal control descriptor (Forced_Return_descriptor) is placed for the application to be terminated when the application is forced to return, and the corresponding application is individually instructed to terminate. To explain by applying the operation example shown in FIG. 8, a return control descriptor (Forced_Return_descriptor) is arranged for the program-unlinked applications app3 and app4.

Consider the operation on the receiver side in this case. For example, when time t2 arrives and MH-AIT is updated, the receiver checks its content. The receiver switches to the execution of the program-unlinked application app3 during the period from time t1 to t2. , the forced return control descriptor (Forced_Return_descriptor) is placed in, so app3 is terminated immediately. Then, after time t2, the receiver can automatically activate application app6 whose application identification information is indicated by the withdrawal control descriptor (Forced_Return_descriptor) as requested by the broadcasting station.

In this way, by using MH-AIT, it is possible to control forced return of applications on an application-by-application basis.

In the fifth embodiment, similarly to the fourth embodiment, a forced return to the entry application is realized by placing a return control descriptor (Forced_Return_descriptor) in the MH-AIT. However, in the fifth embodiment, the return control descriptor (Forced_Return_descriptor) is not an application information descriptor that is applied only to a specific application, but a common descriptor (common_descriptor) that is applied to all applications in the AIT subtable. to place.

FIG. 16 shows a syntax example 1600 of a return control descriptor (Forced_Return_descriptor) placed in the MH-AIT common descriptor.

descriptor_tag is an 8-bit integer value that identifies the descriptor 1600 in question. descriptor_length is an area in which the byte length of the data of the descriptor 1600 following this field is written. In number_of_target_to_return is written the number of applications specified to be terminated when the application is forced to return. Then, in the loop arranged by the number of number_of_target_to_return, application identifier (application_identifier) is written to identify each application specified to end when the application is forced to return.

If a return control descriptor (Forced_Return_descriptor) is arranged as a common descriptor of MH-AIT and applied to the operation example shown in FIG. To explain by applying the operation example shown in FIG. 8, the return control descriptor (Forced_Return_descriptor) indicates the application identification information of the program-unlinked applications app3 and app4.

Consider the operation on the receiver side in this case. For example, when time t2 arrives and MH-AIT is updated, the receiver checks its content. The receiver switches to the execution of app3, which is a program-unlinked application, during the period from time t1 to t2, but the return control descriptor (Forced_Return_descriptor) arranged as a common descriptor in the updated MH-AIT. Now, since the application identification information of the program-unlinked application app3 is shown, the application app3 is terminated immediately. As a result, the receiver can automatically activate app6, which is designated as the entry application after time t2, as requested by the broadcasting station.

In this way, by using MH-AIT, it is possible to control forced return of applications on an application-by-application basis.

FIG. 17 shows, in the form of a flowchart, the processing procedure for the receiver to control the execution of the data broadcasting application in each of the first to fifth embodiments described above.

While the broadcast program is on air, each signaling message including the M2 section message and the data transmission message is basically carousel-transmitted, and the receiver acquires the latest signaling table from the signaling message (step S1701). . The signaling table acquired by the receiver shall include the MH-AIT, data asset management table, and data content management table.

The receiver then activates the data broadcasting application (step S1702). The receiver, for example, automatically starts an application specified for automatic start (autostart) by MH-AIT. In addition, the receiver executes an application designated by a user's (viewer of the broadcast program) remote control operation or the like. In the following description, it is assumed that the user does not give an instruction to end the running application for the sake of simplicity.

Unless the signaling table is updated (No in step S1703), the receiver continues the operation of the application.

Here, when the MH-AIT, the data asset management table, the data content management table, and other signaling tables are updated (Yes in step S1703), "kill (End)" is checked (step S1704).

Also, if there is no description such as "kill" for the application in operation in the updated signaling table (No in step S1704), the application in operation is forcibly pulled back to the entry application. It is checked whether termination is indicated based on the control descriptor (step S1705).

Then, if "kill (end)" is specified in the MH-AIT for the application in operation (Yes in step S1704), the termination of the application in operation is instructed based on the pullback control descriptor. If so (Yes in step S1705), the running application is terminated (step S1706).

If an application (entry application) to be automatically started after the running application is terminated is specified (Yes in step S1707), the receiver executes that application.

The technology disclosed herein has been described in detail above with reference to specific embodiments. However, it is obvious that those skilled in the art can modify or substitute the embodiments without departing from the gist of the technology disclosed in this specification.

The technology disclosed in this specification can be applied to various broadcasting systems that employ MMT as a transport method. In addition, the technology disclosed in this specification can be applied to various broadcasting systems that transmit control information regarding transmission of data broadcasting applications.

In short, the technology disclosed in this specification has been described in the form of an example, and the contents of this specification should not be construed in a limited manner. In order to determine the gist of the technology disclosed in this specification, the scope of claims should be considered.

It should be noted that the technology disclosed in this specification can also be configured as follows.
(1) a transmission unit that transmits each component that constitutes a broadcast service as a transmission unit based on a predetermined transport method;
an information transmission unit that transmits control information regarding transmission of the component;
and
wherein the information transmission unit transmits control information regarding pullback of the data broadcasting application transmitted from the transmission unit;
transmitter.
(2) the predetermined transport method is MMT;
The transmission device according to (1) above.
(3) The information transmission unit transmits control information instructing to return to the entry application in conjunction with a broadcast program composed of video and audio components transmitted from the transmission unit.
The transmission device according to (1) above.
(4) The information transmission unit stores, in units of components, pullback control descriptors for instructing pullback to the entry application in a first table indicating control information relating to transmission of components of the application transmitted by the transmission unit. and send,
The transmission device according to (1) above.
(5) The information transmission unit transmits the first table storing the pullback control descriptor indicating the pullback target for each component for each component.
The transmission device according to (4) above.
(6) The information transmission unit stores and transmits, in units of presentation, pullback control descriptors for instructing pullback to the entry application in a second table indicating information on presentation units of data broadcasting applications.
The transmission device according to (1) above.
(7) The information transmitting unit transmits the second table in which the pullback control descriptor indicating the pullback target in units of presentation is stored for each data content.
The transmission device according to (6) above.
(8) The information transmitting unit stores and transmits, in units of data content, a pull-back control descriptor that instructs a pull-back to the entry application in a third table indicating information about the data broadcasting application for each data content. do,
The transmission device according to (1) above.
(9) the transmitting unit groups and transmits files constituting a data broadcasting application into transmission units based on the predetermined transport method;
The information transmitting unit transmits the third table in which the pullback control descriptor indicating the pullback target in transmission units is stored for each data content.
The transmission device according to (8) above.
(10) The information transmitting unit stores and transmits, for each application, a pullback control descriptor that instructs a pullback to the entry application in a fourth table indicating operation control of the application.
The transmission device according to (1) above.
(11) The information transmission unit transmits the fourth table storing, for each application, the pullback control descriptor specifying the application to be activated next.
The transmission device according to (10) above.
(12) The information transmitting unit stores and transmits a pullback control descriptor instructing a pullback to the entry application as a common descriptor applied to all applications in a fourth table indicating application operation control. do,
The transmission device according to (1) above.
(13) The information transmission unit transmits the fourth table in which the pullback control descriptor indicating identification information of the application to be terminated for the pullback to the entry application is arranged as the common descriptor.
The transmission device according to (12) above.
(14) a transmission step of transmitting each component constituting the broadcast service as a transmission unit based on a predetermined transport method;
an information transmission step of transmitting control information regarding transmission of the component;
has
the information transmission step transmits control information relating to pullback of the data broadcasting application transmitted in the transmission step;
Send method.
(15) a receiving unit that receives each component of a broadcast service transmitted in transmission units based on a predetermined transport method;
an information receiving unit that receives control information regarding transmission of the component;
and
the information receiving unit receives control information relating to pullback of the data broadcasting application received by the receiving unit;
receiving device.
(16) a receiving step of receiving each component of a broadcast service transmitted in transmission units based on a predetermined transport method;
an information receiving step of receiving control information relating to the transmission of said component;
has
In the information receiving step, control information relating to pullback of the data broadcasting application received in the receiving step is received.
receiving method.

DESCRIPTION OF SYMBOLS 10... Digital broadcasting system 11... Broadcast transmission system 12... Receiver 301... Clock part 302... Signal transmission part 303... Video encoder 304... Audio encoder 305... Caption encoder 306... Signaling encoder 307... File/ Encoder, 308...EDPS
309 TLV signaling encoder 310 IP service multiplexer 311 TLV multiplexer 312 modulation/transmission unit 401 tuner/demodulation unit 402 demultiplexer 402-1 TLV filter 402-2 IP filter 402-3: UDP filter 402-4: MMT filter 402-5: SI filter 403: clock recovery unit 404: video decoder 405: audio decoder 406: caption decoder 407: system control unit 408: application Control Unit 409 Data Broadcasting Application Engine 410 IP Interface 411 Synthesizing Unit

Claims (3)

a receiving unit that receives an application and an application information table that are transmitted in transmission units based on a predetermined transport method;
a control unit that controls the state of the application based on the control code included in the application information table;
and
A descriptor for an application placed in an application information loop in the application information table includes control information for switching from an application in a ready state to an auto-start application;
The control unit executes the application specified based on the remote control operation, and automatically starts the application specified based on the remote control operation based on the control information when the application information table is updated. control switching to the application,
receiving device. When the application information table is updated , the control unit controls switching from the application specified based on the remote control operation to the auto-start application based on the control information and the control code.
The receiving device according to claim 1. a receiving step of receiving an application and an application information table transmitted in transmission units based on a predetermined transport method;
a control step of controlling the state of the application based on the control code included in the application information table;
has
A descriptor for an application placed in an application information loop in the application information table includes control information for switching from an application in a ready state to an auto-start application;
In the control step, the application specified based on the remote control operation is executed, and when the application information table is updated, the application specified based on the remote control operation is selected based on the control information and the automatic start application. to control switching to
receiving method.

Images