JP7581550B2 - How we protect your content - Google Patents

Description

The present invention relates to a method for protecting content.

One of the extension functions of digital broadcasting services is data broadcasting, which transmits digital data via broadcast waves and displays various information such as weather forecasts, news, and recommended programs. Many television receivers capable of receiving data broadcasting are already commercially available, and many technologies related to receiving data broadcasting have been published, including Patent Document 1 below.

JP 2001-186486 A

In response to recent changes in the content distribution environment, television receivers are also being asked to expand their functions in various ways. In particular, there are many demands for the distribution of content and linked applications using broadband network environments such as the Internet, as well as for higher resolution and definition video content. However, it is difficult to provide high-added-value television receivers that can meet these demands by simply reusing the data broadcasting reception functions and other features that are equipped in current television receivers, or by simply expanding the functions of said data broadcasting reception functions and other features.

The object of the present invention is to provide a receiving device capable of executing functions with higher added value.

The technology described in the claims is used as a means to solve the above problems.

As an example, a method for protecting content in a receiving device of a transmission system in which a broadcasting station transmits the content of a broadcast program and the receiving device receives the content, the transmission system does not transmit from the broadcasting station to the receiving device any of control information corresponding to the L2-Only flag of DTCP2, control information corresponding to the EI flag of DTCP2, control information corresponding to the HDR flag of DTCP2, and control information corresponding to the SDO flag of DTCP2, and includes a receiving step of receiving the content, a storage step of storing the content received in the receiving step, and an output step of outputting the content stored in the storage step from an IP interface of the receiving device, and in the transmission system: The receiving device is a receiving device that does not acquire any of control information corresponding to an L2-Only flag of DTCP2, control information corresponding to an EI flag of DTCP2, control information corresponding to an HDR flag of DTCP2, and control information corresponding to an SDO flag of DTCP2, and an output state when the content stored in the storing step is output through the IP interface in the output step includes a state in which the content is protected by DTCP2 through the IP interface and output, and a state in which the content is protected by DTCP1 through the IP interface and output, and when the content is received in the receiving step, the content does not satisfy any restriction conditions in the transmission system. In the storage step, when the content stored in the storage step is protected by DTCP2 via the IP interface and outputted with a 1-bit L2-Only flag, an EI flag, an HDR flag, and an SDO flag, each of which is control information of DTCP2, set, there is a state in which the L2-Only flag of DTCP2 is fixed to 0 and outputted, even if the content is transmitted in a state indicating that copying is permitted without conditions and protection by encryption is required, even if the content is transmitted with protection of one-generation copy permitted in the transmission system, or even if the content is transmitted with protection of limited number of copies permitted in the transmission system. The content is output via the interface when the IP address of the receiving device and the IP address of the external device to which the content is output are within the same subnetwork, and when the content received in the receiving step is content that has been transmitted with protection specified for one-generation copying in the transmission system or content that has been transmitted with protection specified for limited number of copies, the content received in the receiving step is made playable only by the receiving device and stored in the storage step, and the broadcast program transmitted by the transmission system and received in the receiving step is one that has been transmitted as one of the broadcast programs in a service in which the start and end of the broadcast program are repeated.

By using the technology of the present invention, it is possible to provide a receiving device that can perform functions with higher added value.

1 is a system configuration diagram showing an example of a broadcast communication system including a broadcast receiving device according to a first embodiment. FIG. 1 is an explanatory diagram of an overview of a coded signal in MMT. FIG. 1 is a configuration diagram of an MPU in MMT. FIG. 1 is a diagram illustrating the structure of an MMTP packet in MMT. A conceptual diagram of a protocol stack of a broadcasting system using MMT. FIG. 2 is a diagram showing a hierarchical structure of control information used in a broadcasting system. This is a list of tables used in the TLV-SI of the broadcasting system. This is a list of descriptors used in the TLV-SI of the broadcasting system. This is a list of messages used in MMT-SI of the broadcasting system. This is a list of tables used in MMT-SI of the broadcasting system. This is a list (part 1) of descriptors used in MMT-SI of the broadcasting system. This is a list (part 2) of descriptors used in MMT-SI of the broadcasting system. FIG. 2 is a diagram showing the relationship between data transmission in a broadcasting system and each table. 1 is a block diagram of a broadcast receiving device according to a first embodiment. 2 is a configuration diagram of a logical plane structure of a presentation function of the broadcast receiving device according to the first embodiment. FIG. 1 is a system configuration diagram of clock synchronization/presentation synchronization of a broadcast receiving device according to a first embodiment. 2 is a software configuration diagram of the broadcast receiving device according to the first embodiment. FIG. FIG. 2 is a block diagram of a broadcasting station server according to the first embodiment. FIG. 2 is a block diagram of a service provider server according to the first embodiment. FIG. 2 is a block diagram of a portable information terminal according to the first embodiment. FIG. 2 is a software configuration diagram of the portable information terminal according to the first embodiment. A diagram showing the data structure of MH-TOT of a broadcasting system. A diagram showing the format of the JST_time parameter of a broadcasting system. 11 is a diagram showing a method of calculating the current date from the MJD of the broadcast receiving device in Example 1. A diagram showing the configuration of the NTP format of a broadcasting system. A diagram showing the data structure of an MPU timestamp descriptor in a broadcasting system. A diagram showing the data structure of time information in the TMCC extension information area of a broadcasting system. 4 is an operational sequence diagram of the broadcast receiving device according to the first embodiment during channel scanning. FIG. A diagram showing the data structure of the TLV-NIT of a broadcasting system. A diagram showing the data structure of a satellite distribution system descriptor of a broadcasting system. A diagram showing the data structure of a service list descriptor for a broadcasting system. A diagram showing the data structure of AMT of a broadcasting system. 4 is a sequence diagram of an operation of the broadcast receiving device according to the first embodiment when selecting a channel. FIG. A diagram showing the data structure of the MPT of the broadcasting system. A diagram showing the data structure of an LCT of a broadcasting system. FIG. 13 shows an example of assignment of layouts to layout numbers based on the LCT. FIG. 13 shows an example of assignment of layouts to layout numbers based on the LCT. FIG. 13 shows an example of assignment of layouts to layout numbers based on the LCT. FIG. 13 shows an example of assignment of layouts to layout numbers based on the LCT. 11A and 11B are diagrams illustrating the operation of exception handling in screen layout control based on an LCT. 11A and 11B are diagrams illustrating the operation of exception handling in screen layout control based on an LCT. A diagram showing the data structure of MH-EIT of a broadcasting system. FIG. 2 is a screen display diagram of an EPG screen of the broadcast receiving device according to the first embodiment. 3 is a screen display diagram of an EPG screen of the broadcast receiving device according to the first embodiment. FIG. 3 is a screen display diagram of an EPG screen of the broadcast receiving device according to the first embodiment. FIG. 4 is a screen display diagram of the broadcast receiving device according to the first embodiment when an emergency alert broadcast is displayed. FIG. FIG. 11 is a block diagram of a broadcast receiving device according to a second embodiment. 11 is a diagram illustrating an inconsistency in the current time display when switching broadcast services. 13A and 13B are diagrams illustrating the operation of current time information reference source selection control according to the second embodiment. FIG. 11 is an operation sequence diagram of a current time information update process according to the second embodiment. FIG. 11 is a screen display diagram of an EPG screen of a broadcast receiving device according to a second embodiment. FIG. 11 is a screen display diagram of an EPG screen of a broadcast receiving device according to a second embodiment. FIG. 11 is a system configuration diagram of a broadcast communication system according to a third embodiment. A diagram showing the data structure of a content information descriptor of a broadcasting system. A diagram explaining the meaning of content types in a content information descriptor of a broadcasting system. A diagram explaining the meaning of source device primary color chromaticity coordinates and source device white chromaticity coordinates in the content information descriptor of a broadcasting system. A diagram explaining the meaning of EOTF identification in a content information descriptor of a broadcasting system. FIG. 11 is a screen display diagram of an EPG screen of a broadcast receiving device according to a third embodiment. FIG. 1 is a diagram illustrating a deviation in color gamut between a source device and a monitor device. 13A and 13B are diagrams illustrating a color gamut conversion process of a broadcast receiving device according to a third embodiment. 13A and 13B are diagrams illustrating a color gamut conversion process of a broadcast receiving device according to a third embodiment. FIG. 11 is a diagram for explaining image quality adjustment items of a broadcast receiving device according to a third embodiment. 13A and 13B are diagrams illustrating a luminance level conversion process of a broadcast receiving device according to a third embodiment. 13A and 13B are diagrams illustrating a luminance level conversion process of a broadcast receiving device according to a third embodiment. FIG. 11 is a system configuration diagram of a broadcast communication system according to a fourth embodiment. FIG. 13 is a block diagram of a broadcast receiving device according to a fourth embodiment. FIG. 11 is a software configuration diagram of a broadcast receiving device according to a fourth embodiment. FIG. 13 is a diagram illustrating an interface configuration between a broadcast receiving device and a monitor device according to a fourth embodiment. 13 is a diagram illustrating mastering information output by a broadcast receiving device according to a fourth embodiment. FIG. FIG. 13 is a system configuration diagram of a broadcast communication system according to a fifth embodiment. FIG. 13 is a diagram illustrating an example of output control information according to a fifth embodiment. FIG. 13 is a diagram illustrating an example of reception control information according to a fifth embodiment. FIG. 13 is a diagram illustrating an example of reception control information according to a fifth embodiment. FIG. 13 is a diagram illustrating an example of reception control information according to a fifth embodiment. FIG. 13 is a diagram illustrating an example of reception control information according to a fifth embodiment. FIG. 13 is a diagram illustrating an example of a process for determining whether to protect the output of content according to the fifth embodiment. FIG. 13 is a diagram illustrating an example of a process for determining whether to protect the output of content according to the fifth embodiment. FIG. 13 is a diagram illustrating an example of a process for determining whether to protect the output of content according to the fifth embodiment.

Hereinafter, examples of embodiments of the present invention will be described with reference to the drawings.
Example 1

[System configuration]
1 is a system configuration diagram showing an example of a broadcast communication system including a broadcast receiving device of this embodiment. The broadcast communication system of this embodiment is composed of a broadcast receiving device 100, an antenna 100a, a broadband network such as the Internet 200, a router device 200r, an access point 200a, a radio tower 300t of a broadcast station, a broadcast satellite (or a communication satellite) 300s, a broadcast station server 300, a service provider server 400, other application servers 500, a mobile telephone communication server 600, a base station 600b of a mobile telephone communication network, and a mobile information terminal 700.

The broadcast receiving device 100 receives broadcast waves transmitted from a radio tower 300t via a broadcast satellite (or communication satellite) 300s and an antenna 100a. Alternatively, the broadcast waves transmitted from the radio tower 300t may be received directly from the antenna 100a without passing through the broadcast satellite (or communication satellite) 300s. The broadcast receiving device 100 can also be connected to the Internet 200 via a router device 200r, and can transmit and receive data by communicating with each server device and other communication devices on the Internet 200.

The router device 200r is connected to the Internet 200 via wired communication, to the broadcast receiving device 100 via wired or wireless communication, and to the mobile information terminal 700 via wireless communication. The wireless communication may use a method such as Wi-Fi (registered trademark). This allows each server device and other communication devices on the Internet 200 to transmit and receive data to and from the broadcast receiving device 100 and the mobile information terminal 700 via the router device 200r. Note that communication between the broadcast receiving device 100 and the mobile information terminal 700 may be performed directly using a method such as BlueTooth (registered trademark) or NFC (Near Field Communication) without going through the router device 200r.

The radio tower 300t is a broadcasting facility of a broadcasting station, and transmits broadcast waves including encoded data and subtitle information of broadcast programs, other applications, general-purpose data, etc. The broadcasting satellite (or communication satellite) 300s is a repeater that receives broadcast waves transmitted from the radio tower 300t of the broadcasting station, performs appropriate frequency conversion, etc., and then retransmits the broadcast waves to the antenna 100a connected to the broadcast receiving device 100. The broadcasting station is also assumed to have a broadcasting station server 300. The broadcasting station server 300 stores broadcast programs (video content, etc.) and metadata such as the program title, program ID, program summary, performer information, broadcast date and time of each broadcast program, and is capable of providing the video content and each metadata to a service provider based on a contract. The video content and each metadata may be provided to the service provider through an API (Application Programming Interface) provided by the broadcasting station server 300.

The service provider server 400 is a server device prepared by a service provider, and is capable of providing various services linked to broadcast programs distributed by a broadcast station. The service provider server 400 also stores, manages, and distributes video content and metadata provided by the broadcast station server 300, as well as various content and applications linked to broadcast programs. It also has a function of searching for and providing a list of available content and applications in response to inquiries from television receivers, etc. The storage, management, and distribution of the content and metadata and the storage, management, and distribution of the applications may be performed by different server devices. The broadcast station and the service provider may be the same or different. A plurality of service provider servers 400 may be prepared for each different service. The functions of the service provider server 400 may also be provided by the broadcast station server 300.

The other application server 500 is a known server device that stores, manages, and distributes other general applications, operating programs, content, data, etc. There may be multiple other application servers 500 on the Internet 200.

The mobile telephone communication server 600 is connected to the Internet 200, and is also connected to the mobile information terminal 700 via the base station 600b. The mobile telephone communication server 600 manages telephone communication (calls) and data transmission and reception via the mobile telephone communication network of the mobile information terminal 700, and enables data transmission and reception by communication between the mobile information terminal 700 and each server device on the Internet 200 and other communication devices. The communication between the base station 600b and the mobile information terminal 700 may be performed by the W-CDMA (Wideband Code Division Multiple Access) (registered trademark) system, the GSM (Global System for Mobile communications) (registered trademark) system, the LTE (Long Term Evolution) system, or other communication systems.

The mobile information terminal 700 has a function of telephone communication (calls) and data transmission and reception via a mobile telephone communication network, and a function of wireless communication by Wi-Fi (registered trademark) or the like. The mobile information terminal 700 can be connected to the Internet 200 via the router device 200r or the access point 200a, or via the base station 600b of the mobile telephone communication network and the mobile telephone communication server 600, and can transmit and receive data by communication with each server device on the Internet 200 and other communication devices. The access point 200a is connected to the Internet 200 by wired communication, and is connected to the mobile information terminal 700 by wireless communication. The wireless communication may be a method such as Wi-Fi (registered trademark). The communication between the mobile information terminal 700 and the broadcast receiving device 100 may be performed via the access point 200a, the Internet 200, and the router device 200r, or via the base station 600b, the mobile telephone communication server 600, the Internet 200, and the router device 200r.

[Overview of the MMT method]
The broadcast receiving device 100 shown in Fig. 1 is a television receiver that is compatible with MMT (MPEG Media Transport) instead of TS (Transport Stream) (hereinafter, referred to as MPEG2-TS) defined in the MPEG (Moving Picture Experts Group)-2 system, which is widely adopted in conventional digital broadcasting systems as a media transport method for transmitting data such as video and audio. The television receiver may be compatible with both MPEG2-TS and MMT.

MPEG2-TS is characterized by multiplexing the video, audio, and other components that make up a program into a single stream along with control signals and a clock. As the clock is also treated as a single stream, it is suitable for transmitting a single piece of content over a single transmission path with guaranteed transmission quality, and has been adopted in many conventional digital broadcasting systems. However, there are limitations to the functionality of MPEG2-TS in dealing with changes in the content distribution environment, such as the recent diversification of content, the diversification of devices that use content, the diversification of transmission paths for distributing content, and the diversification of content storage environments. As a result, MMT is a newly formulated media transport method.

Figure 2A shows an example of an outline of the encoded signal in the MMT of this embodiment. As shown in the figure, the MMT of this embodiment has an MFU (Media Fragment Unit), an MPU (Media Processing Unit), an MMTP (MMT Protocol) payload, and an MMTP packet as elements constituting the encoded signal. The MFU is a format for transmitting video, audio, etc., and may be configured in NAL (Network Abstraction Layer) unit units or access unit units. The MPU may be configured with MPU metadata including information on the configuration of the entire MPU, movie fragment metadata including information on the encoded media data, and sample data which is the encoded media data. It is also assumed that the MFU can be extracted from the sample data. In addition, in the case of media such as video components and audio components, the presentation time and the decoding time may be specified in MPU units or access unit units. Figure 2B shows an example of the configuration of an MPU.

The MMTP packet is composed of a header section and an MMTP payload, and transmits control information of the MFU and MMT. The MMTP payload is equipped with a payload header according to the contents (data units) to be stored in the payload section. FIG. 2C shows an example of an overview of constructing an MFU from a video/audio signal, storing it in the MMTP payload, and constructing an MMTP packet. In addition, in a video signal that is encoded using inter-frame prediction, it is desirable to configure the MPU in GOP (Group Of Pictures) units. In addition, when the size of the MFU to be transmitted is small, one MFU may be stored in one payload section, or multiple MFUs may be stored in one payload section. In addition, when the size of the MFU to be transmitted is large, one MFU may be divided and stored in multiple payload sections. In addition, MMTP packets may be protected using techniques such as AL-FEC (Application Layer Forward Error Correction) and ARQ (Automatic Repeat Request) to recover from packet loss on the transmission path.

In the broadcasting system of this embodiment, MPEG-H HEVC (High Efficiency Video Coding) is used as the video encoding method, and MPEG-4 AAC (Advanced Audio Coding) or MPEG-4 ALS (Audio Lossless Coding) is used as the audio encoding method. The encoded data of the video and audio of the broadcast program encoded by each of the above methods is in the format of MFU or MPU, and is further loaded on the MMTP payload to be packetized as MMTP packets and transmitted in IP (Internet Protocol) packets. In addition, data content related to the broadcast program may also be in the format of MFU or MPU, and further loaded on the MMTP payload to be packetized as MMTP packets and transmitted in IP packets. Four types of data content transmission methods will be available: a subtitle/superimposed text transmission method used for streaming data synchronized with broadcasting; an application transmission method used for data transmission asynchronous with broadcasting; an event message transmission method used for synchronous/asynchronous message notification to applications running on television receivers; and a general-purpose data transmission method for synchronous/asynchronous transmission of other general-purpose data.

For the transmission of MMTP packets, UDP/IP (User Datagram Protocol/Internet Protocol) is used on the broadcast transmission path, and UDP/IP or TCP/IP (Transmission Control Protocol/Internet Protocol) is used on the communication line. In addition, the TLV (Type Length Value) multiplexing method is used on the broadcast transmission path for efficient transmission of IP packets. An example of a protocol stack for the broadcast system of this embodiment is shown in Figure 3. In the figure, (A) is an example of a protocol stack on the broadcast transmission path, and (B) is an example of a protocol stack on the communication line.

In the broadcasting system of this embodiment, a mechanism is provided for transmitting two types of control information: MMT-SI (MMT-Signaling Information) and TLV-SI (TLV-Signaling Information). MMT-SI is control information that indicates the configuration of a broadcast program, etc. It is in the form of an MMT control message, placed on an MMTP payload, packetized as an MMTP packet, and transmitted in an IP packet. TLV-SI is control information related to multiplexing of IP packets, and provides information for channel selection and correspondence information between IP addresses and services.

In addition, in broadcasting systems using MMT, time information is also transmitted to provide absolute time. Note that while MPEG2-TS indicates the display time of components based on a different clock for each TS, MMT indicates the display time of components based on Coordinated Universal Time (UTC). These mechanisms enable terminal devices to synchronize and display components transmitted from different transmission points over different transmission paths. To provide UTC, IP packets in NTP (Network Time Protocol) format are used.

[Control information for broadcasting systems using MMT]
In the broadcasting system supported by the broadcasting receiving device 100 of this embodiment, as described above, TLV-SI related to the TLV multiplexing method for multiplexing IP packets and MMT-SI related to MMT, which is a media transport method, are prepared as control information. TLV-SI provides information for the broadcasting receiving device 100 to demultiplex IP packets multiplexed on a broadcast transmission path. TLV-SI is composed of a "table" and a "descriptor". The "table" is transmitted in a section format, and the "descriptor" is placed in the "table". MMT-SI is transmission control information indicating the configuration of an MMT package and information related to a broadcasting service. MMT-SI is composed of three hierarchical layers: a "message" that stores a "table" or a "descriptor", a "table" that has elements and attributes that indicate specific information, and a "descriptor" that indicates more detailed information. An example of the hierarchical structure of control information used in the broadcasting system of this embodiment is shown in FIG. 4.

<Tables used in TLV-SI>
5A shows a list of "tables" used in the TLV-SI of the broadcasting system supported by the broadcast receiving device 100 of this embodiment. In this embodiment, the following are used as the "tables" of the TLV-SI.

(1) TLV-NIT
A Network Information Table for TLV (TLV-NIT) represents information about the physical configuration of the TLV stream transmitted by the network and the characteristics of the network itself.

(2) AMT
The Address Map Table (AMT) provides a list of multicast groups for the IP packets that constitute each service transmitted in the network.

(3) Tables Set by Service Providers In addition, service providers and the like can prepare tables that they set independently.

<Descriptors used in TLV-SI>
5B shows a list of "descriptors" placed in the TLV-SI of the broadcasting system supported by the broadcast receiving device 100 of this embodiment. In this embodiment, the following "descriptors" are used as the TLV-SI "descriptors".

(1) Service List Descriptor The service list descriptor provides a list of services by service identification and service format type.

(2) Satellite Distribution System Descriptor The satellite distribution system descriptor indicates the physical conditions of the satellite transmission path.

(3) System Management Descriptor The system management descriptor is used to distinguish between broadcast and non-broadcast.

(4) Network Name Descriptor The network name descriptor describes the network name using character codes.

(5) Descriptors Set by Service Providers In addition, service providers etc. may prepare their own unique descriptors.

<Messages used in MMT-SI>
6A shows a list of "messages" used in MMT-SI of the broadcasting system supported by the broadcast receiving device 100 of this embodiment. In this embodiment, the following are used as "messages" of MMT-SI.

(1) PA Message The Package Access (PA) message is used to transmit various tables.

(2) M2 Section Message The M2 Section message is used to transmit the section extension format of the MPEG-2 Systems.

(3) CA Message The CA message is used to transmit a table for identifying the conditional access system.

(4) M2 Short Section Message The M2 short section message is used to transmit the section short format of the MPEG-2 Systems.

(5) Data Transmission Message A data transmission message is a message that stores a table related to data transmission.

(6) Messages Set by Service Providers In addition, service providers and the like can prepare messages that they set independently.

<Tables used in MMT-SI>
6B shows a list of "tables" used in the MMT-SI of the broadcasting system supported by the broadcast receiving device 100 of this embodiment. A table is control information having elements and attributes indicating specific information, and is stored in a message and transmitted in an MMTP packet. Note that the message that stores the table may be determined according to the table. In this embodiment, the following is used as the "table" of MMT-SI.

(1) MPT
The MMT Package Table (MPT) provides information that configures a package, such as a list of assets, the location of the assets on the network, etc. The MPT may be stored in a PA message.

(2) PLT
A package list table (PLT) indicates a list of IP data flows and packet IDs that transmit PA messages of MMT packages provided as broadcast services, and IP data flows that transmit IP services. The PLT may be stored in the PA message.

(3) LCT
A Layout Configuration Table (LCT) is used to associate layout information for presentation with a layout number. The LCT may be stored in the PA message.

(4) ECM
An Entitlement Control Message (ECM) is common information consisting of program information and control information, and delivers key information for descrambling, etc. The ECM may be stored in an M2 section message.

(5) EMM
An Entitlement Management Message (EMM) transmits individual information including contract information for each subscriber, key information for decrypting ECM (common information), etc. The EMM may be stored in an M2 section message.

(6) CAT(MH)
A Conditional Access Table (CAT) (MH) is used to store a descriptor for identifying a conditional access system. The CAT (MH) may be stored in a CA message.

(7) DCM
A Download Control Message (DCM) transmits key-related information including a key for decrypting a transmission line encryption for downloading. The DCM may be stored in an M2 section message.

(8) DMM
A Download Management Message (DMM) transmits key-related information such as a download key for decrypting a DCM. The DMM may be stored in an M2 section message.

(9) MH-EIT
The MH-Event Information Table (MH-EIT) is time-series information regarding events included in each service. The MH-EIT may be stored in the M2 section message.

(10) MH-AIT
The MH-Application Information Table (MH-AIT) stores all information related to applications and their required activation states, etc. The MH-AIT may be stored in the M2 section message.

(11) MH-BIT
The MH-BIT (MH Broadcaster Information Table) is used to present information on broadcasters present on the network. The MH-BIT may be stored in the M2 section message.

(12) MH-SDTT
The MH-Software Download Trigger Table (MH-SDTT) is used for download notification information. The MH-SDTT may be stored in the M2 section message.

(13) MH-SDT
The MH-Service Description Table (MH-SDT) has a sub-table that indicates services included in a specific TLV stream, and information about the channel, such as the name of the channel and the name of the broadcasting company. The MH-SDT may be stored in the M2 section message.

(14) MH-TOT
The MH-Time Offset Table (MH-TOT) carries JST time and date (Modified Julian Date) information. The MH-TOT may be stored in the M2 short section message.

(15) MH-CDT
The MH-Common Data Table (MH-CDT) is used to transmit common data to be stored in a non-volatile memory in a section format for all receivers that receive the data. - The CDT may be stored in the M2 section message.

(16) DDM Table The Data Directory Management Table (DDM table) provides a directory structure of files that configure an application in order to separate the file structure of the application from the structure for file transmission. The DDM table may be stored in a data transmission message.

(17) DAM Table The Data Asset Management Table (DAM table) provides the configuration of MPUs in an asset and version information for each MPU. The DAM table may be stored in a data transmission message.

(18) DCC Table The Data Content Configuration Table (DCC table) provides configuration information of files as data contents to realize flexible and effective cache control. The DCC table may be stored in a data transmission message.

(19) EMT
The Event Message Table (EMT) is used to transmit information about event messages. The EMT may be stored in the M2 section message.

(20) Tables Set by Service Providers In addition, service providers and the like can prepare tables that they set independently.

<Descriptors used in MMT-SI>
6C and 6D show a list of "descriptors" arranged in the MMT-SI of the broadcasting system supported by the broadcast receiving device 100 of this embodiment. The descriptor is control information that provides more detailed information, and is arranged in a table. The table in which the descriptor is arranged may be determined according to the descriptor. In this embodiment, the following are used as "descriptors" of the MMT-SI.

(1) Asset Group Descriptor The asset group descriptor provides the group relationship of assets and the priority within the group. The asset group descriptor may be placed in the MPT.

(2) Event Package Descriptor The event package descriptor provides correspondence between an event representing a program and a package. The event package descriptor may be placed in the MH-EIT transmitted in the M2 section message.

(3) Background Color Specification Descriptor The background color specification descriptor provides the background color of the backmost element in the layout specification. The background color specification descriptor may be placed in the LCT.

(4) MPU Presentation Area Specification Descriptor The MPU presentation area specification descriptor provides a position for presenting the MPU. The MPU presentation area specification descriptor may be placed in the MPT.

(5) MPU timestamp descriptor The MPU timestamp descriptor indicates the presentation time of the first access unit in presentation order in the MPU. The MPU timestamp descriptor may be placed in the MPT.

(6) Dependency Descriptor The dependency descriptor provides the asset ID of the dependent asset. The dependency descriptor may be placed in the MPT.

(7) Access Control Descriptor The access control descriptor provides information for identifying a conditional access method. The access control descriptor may be placed in the MPT or CAT (MH).

(8) Scrambling Scheme Descriptor The scrambling scheme descriptor provides information for identifying the encryption target and the type of encryption algorithm at the time of scrambling. The scrambling scheme descriptor may be placed in the MPT or CAT (MH).

(9) Message Authentication Scheme Descriptor The message authentication scheme descriptor provides information for identifying a message authentication scheme when performing message authentication. The message authentication scheme descriptor may be placed in the MPT or CAT (MH).

(10) Emergency Information Descriptor (MH)
The emergency information descriptor (MH) is used when an emergency alert is broadcast. The emergency information descriptor (MH) may be placed in the MPT.

(11) MH-MPEG-4 Audio Descriptor The MH-MPEG-4 Audio Descriptor is used to describe basic information for specifying the coding parameters of an audio stream of ISO/IEC 14496-3 (MPEG-4 Audio). The MH-MPEG-4 Audio Descriptor may be placed in the MPT.

(12) MH-MPEG-4 Audio Extension Descriptor The MH-MPEG-4 Audio Extension Descriptor is used to describe the profile and level of an MPEG-4 audio stream and the coding method specific settings. The MH-MPEG-4 Audio Extension Descriptor may be placed in the MPT.

(13) MH-HEVC Video Descriptor The MH-HEVC video descriptor is used to describe basic coding parameters of a video stream (HEVC stream) of ITU-T Recommendation H.265|ISO/IEC 23008-2. The MH-HEVC video descriptor may be placed in the MPT.

(14) MH-Link Descriptor The MH-Link Descriptor identifies the service that will be provided if a viewer requests additional information related to a particular listing in the program service information system. The MH-Link Descriptor may be located in the MPT, MH-EIT, MH-SDT, etc.

(15) MH-Event Group Descriptor The MH-Event Group Descriptor is used to indicate that multiple events are grouped when there is a relationship between the events. The MH-Event Group Descriptor may be placed in the MH-EIT.

(16) MH-Service List Descriptor The MH-Service List Descriptor provides a list of services by service identification and service type. The MH-Service List Descriptor may be located in the MH-BIT.

(17) MH-Short Event Descriptor The MH-Short Event Descriptor represents an event name and a short description of the event in text form. The MH-Short Event Descriptor may be placed in the MH-EIT.

(18) MH-Extended Event Descriptor The MH-Extended Event Descriptor is used in addition to the MH-Short Event Descriptor to provide a detailed description of an event. The MH-Extended Event Descriptor may be placed in the MH-EIT.

(19) Video Component Descriptor The video component descriptor indicates parameters and descriptions related to a video component, and is also used to express an elementary stream in a character format. The video component descriptor may be placed in the MPT or MH-EIT.

(20) MH-Stream Identification Descriptor The MH-Stream Identification Descriptor is used to label a component stream of a service and to refer to the description contents indicated by the video component descriptor in the MH-EIT by this label. The MH-Stream Identification Descriptor may be placed in the MPT.

(21) MH-Content Descriptor The MH-Content Descriptor indicates the genre of an event. The MH-Content Descriptor may be placed in the MH-EIT.

(22) MH-Parental Rating Descriptor The MH-Parental Rating Descriptor is used to indicate viewing restrictions based on age and to extend to other restriction conditions. The MH-Parental Rating Descriptor may be placed in the MPT or MH-EIT.

(23) MH-Audio Component Descriptor The MH-Audio Component Descriptor indicates each parameter of an audio elementary stream and is also used to express the elementary stream in a character format. The MH-Audio Component Descriptor may be placed in the MPT or the MH-EIT.

(24) MH-Target Region Descriptor The MH-Target Region Descriptor is used to describe the region targeted by a program or some of the streams that constitute a program. The MH-Target Region Descriptor may be placed in the MPT.

(25) MH-Series Descriptor The MH-Series Descriptor is used to identify a series of programs. The MH-Series Descriptor may be placed in the MH-EIT.

(26) MH-SI Transmission Parameter Descriptor The MH-SI transmission parameter descriptor is used to indicate the transmission parameters of the SI. The MH-SI transmission parameter descriptor may be located in the MH-BIT.

(27) MH-Broadcaster Name Descriptor The MH-Broadcaster Name Descriptor describes the name of a broadcaster. The MH-Broadcaster Name Descriptor may be placed in the MH-BIT.

(28) MH-Service Descriptor The MH-Service Descriptor represents the name of a channel and its operator together with the service type in character codes. The MH-Service Descriptor may be placed in the MH-SDT.

(29) IP Data Flow Descriptor The IP Data Flow Descriptor provides information about the IP data flows that constitute a service. The IP Data Flow Descriptor may be located in the MH-SDT.

(30) MH-CA Invocation Descriptor The MH-CA invocation descriptor describes invocation information for invoking a CAS program on the CAS platform. The MH-CA invocation descriptor may be located in the MPT or CAT (CA).

(31) MH-Type Descriptor The MH-Type descriptor indicates the type of file transmitted in the application transmission method. The MH-Type descriptor may be placed in the DAM table.

(32) MH-Info Descriptor The MH-Info Descriptor describes information about an MPU or an item. The MH-Info Descriptor may be placed in a DAM table.

(33) MH-Expire Descriptor The MH-Expire descriptor describes the expiration date of an item. The MH-Expire descriptor may be placed in the DAM table.

(34) MH-Compression Type Descriptor The MH-Compression Type Descriptor indicates that the item to be transmitted is compressed, and indicates the compression algorithm and the number of bytes of the item before compression. The MH-Compression Type Descriptor may be placed in the DAM table.

(35) MH-Data Coding Scheme Descriptor The MH-Data Coding Scheme Descriptor is used to identify a data coding scheme. The MH-Data Coding Scheme Descriptor may be placed in the MPT.

(36) UTC-NPT Reference Descriptor The UTC-NPT reference descriptor is used to convey the relationship between the NPT (Normal Play Time) and the UTC. The UTC-NPT reference descriptor may be placed in the EMT.

(37) Event Message Descriptor The event message descriptor conveys information about event messages in general. The event message descriptor may be placed in the EMT.

(38) MH-Local Time Offset Descriptor The MH-Local Time Offset Descriptor is used when a certain offset value is to be given between the actual time (e.g., UTC+9 hours) and the display time for the human system during daylight saving time implementation. The MH-Local Time Offset Descriptor may be placed in the MH-TOT.

(39) MH-Component Group Descriptor The MH-Component Group Descriptor defines and identifies a combination of components in an event. The MH-Component Group Descriptor may be placed in the MH-EIT.

(40) MH-Logo Transmission Descriptor The MH-Logo Transmission Descriptor is used to describe a simple logo character string, pointing to a logo in CDT format, etc. The MH-Logo Transmission Descriptor may be placed in the MH-SDT.

(41) MPU Extended Timestamp Descriptor The MPU extended timestamp descriptor provides the decoding time of an access unit in an MPU. The MPU extended timestamp descriptor may be placed in the MPT.

(42) MPU Download Content Descriptor The MPU download content descriptor is used to describe attribute information of content downloaded using the MPU. The MPU download content descriptor may be placed in the MH-SDTT.

(43) MH-Network Download Content Descriptor The MH-Network Download Content Descriptor is used to describe attribute information of content downloaded using a network. The MH-Network Download Content Descriptor may be placed in the MH-SDTT.

(44) MH-Application Descriptor The MH-Application Descriptor describes information about an application. The MH-Application Descriptor may be placed in the MH-AIT.

(45) MH-Transmission Protocol Descriptor The MH-Transmission Protocol Descriptor is used to specify a transmission protocol such as broadcasting or communication, and to indicate location information of an application depending on the transmission protocol. The MH-Transmission Protocol Descriptor may be placed in the MH-AIT.

(46) MH-simple application location descriptor The MH-simple application location descriptor is described to indicate details of where to obtain an application. The MH-simple application location descriptor may be placed in the MH-AIT.

(47) MH-Application Boundary Authority Setting Descriptor The MH-application boundary authority setting descriptor is described to set an application boundary and to set authority of broadcast resource access for each area (URL). The MH-application boundary authority setting descriptor may be placed in the MH-AIT.

(48) MH-Launching Priority Information Descriptor The MH-Launching Priority Information Descriptor is described to specify the startup priority of an application. The MH-Launching Priority Information Descriptor may be placed in the MH-AIT.

(49) MH-cache information descriptor The MH-cache information descriptor is described for use in cache control when the resources constituting an application are cached and held when the application is expected to be reused. The MH-cache information descriptor may be placed in the MH-AIT.

(50) MH-Probabilistic Application Delay Descriptor The MH-Probabilistic Application Delay Descriptor is used to delay the timing of application control by a probabilistically set delay amount, assuming load balancing of server access for application acquisition. The MH-Probabilistic Application Delay Descriptor may be placed in the MH-AIT.

(51) Link Destination PU Descriptor The link destination PU descriptor describes another presentation unit that may transition from the presentation unit (PU). The link destination PU descriptor may be placed in the DCC table.

(52) Lock Cache Designation Descriptor The lock cache designation descriptor describes the designation of a file to be cached and locked in the presentation unit. The lock cache designation descriptor may be arranged in the DCC table.

(53) Unlock Cache Designation Descriptor The unlock cache designation descriptor describes the designation of a file to be unlocked among the files locked in the presentation unit. The unlock cache designation descriptor may be arranged in the DCC table.

(54) Descriptors Set by Service Providers In addition, service providers and the like may prepare their own unique descriptors.

<Relationship between data transmission and each control information in the MMT system>
Here, the relationship between data transmission and representative tables in the broadcasting system supported by the broadcasting receiving device 100 of this embodiment will be described with reference to FIG. 6E.

In the broadcasting system supported by the broadcast receiving device 100 of this embodiment, data can be transmitted via multiple routes, such as a TLV stream via a broadcast transmission path and an IP data flow via a communication line. The TLV stream includes TLV-SI such as TLV-NIT and AMT, and an IP data flow, which is a data flow of IP packets. The IP data flow includes video assets including a series of video MPUs and audio assets including a series of audio MPUs. Similarly, the IP data flow may include subtitle assets including a series of subtitle MPUs, superimposition assets including a series of superimposition MPUs, and data assets including a series of data MPUs. These various assets are associated in units called "packages" by the MPT (MMT package table) stored in and transmitted in a PA message. Specifically, the association is made by recording in the MPT a package ID (corresponding to the "MMT_package_id_byte" parameter shown in FIG. 17, described below) and the asset IDs of each asset included in the package (corresponding to the "asset_id_byte" parameter shown in FIG. 17, described below).

The assets constituting the package can be only assets in the TLV stream, but as shown in Figure 6E, they can also include assets transmitted in the IP data flow of the communication line. This can be achieved by including location information of each asset included in the package (corresponding to "MMT_general_location_info()" shown in Figure 17 described later) in the MPT, allowing the broadcast receiving device 100 of this embodiment to grasp the reference destination of each asset. Specifically, by changing the value of the "MMT_general_location_infolocation_type" parameter placed in the location information,
(1) Data multiplexed in the same IP data flow as MPT (location_type = 0x00)
(2) Data multiplexed in IPv4 data flow (location_type = 0x01)
(3) Data multiplexed in IPv6 data flow (location_type = 0x02)
(4) Data multiplexed in the broadcast MPEG2-TS (location_type = 0x03)
(5) Data multiplexed in the IP data flow in MPEG2-TS format (location_type = 0x04)
(6) Data at the specified URL (location_type = 0x05)
It is possible to configure the broadcast receiving device 100 so that it can refer to various types of data transmitted via various transmission paths such as the above.

Of the above-mentioned references, (1) is, for example, an IP data flow received via a digital broadcast signal received by the tuner/demodulator unit 131 of the broadcast receiving device 100 in FIG. 7A, which will be described later. When the MPT is also transmitted as part of the IP data flow on the communication line side, the reference of (1) may be an IP data flow received via the communication line by the LAN communication unit 121, which will be described later. Also, (2), (3), (5), and (6) are IP data flows received via the communication line by the LAN communication unit 121, which will be described later. Furthermore, (4) above can be used, for example, in the case of a broadcast receiving device having both a receiving function for receiving digital broadcast signals using the MMT system and a receiving function for receiving digital broadcast signals using the MPEG2-TS system, such as the broadcast receiving device 800 of Example 2 shown in FIG. 24 described later, when referring to data multiplexed into the MPEG2-TS received by the receiving function for receiving digital broadcast signals using the MPEG2-TS system based on the MPT location information ("MMT_general_location_info()") included in the digital broadcast signals using the MMT system.

The data constituting a "package" is specified in this manner, but in the broadcasting system to which the broadcast receiving device 100 of this embodiment corresponds, a series of data in units of this "package" is treated as a unit of digital broadcasting "service."

Furthermore, the MPT describes the presentation time information of each MPU specified by the MPT (corresponding to the "mpu_presentation_time" parameter shown in FIG. 13B described below), and using this presentation time information, it becomes possible to present (display, output, etc.) multiple MPUs specified by the MPT in a linked manner based on a clock based on the NTP, which is time information in UTC notation. Presentation control of various data using the clock based on the NTP will be described later.

In the data transmission method of this embodiment shown in FIG. 6E, there is also a concept of an "event". An "event" is a concept that indicates a so-called "program" that is handled by the MH-EIT that is included in the M2 section message and sent. Specifically, in a "package" that is pointed to by an event package descriptor stored in the MH-EIT, a series of data included in a period of time (corresponding to the "start_time" parameter shown in FIG. 21 described later) from the start time stored in the MH-EIT (corresponding to the "start_time" parameter shown in FIG. 21 described later) is the data included in the concept of the "event". The MH-EIT can be used in various processes on an "event" basis in the broadcast receiving device 100 of this embodiment (for example, program guide generation process, control of recording and viewing reservations, copyright management process such as temporary storage, etc.).

[Hardware configuration of broadcast receiving device]
7A is a block diagram showing an example of the internal configuration of the broadcast receiving device 100. The broadcast receiving device 100 is composed of a main control unit 101, a system bus 102, a ROM 103, a RAM 104, a storage (accumulation) unit 110, a LAN communication unit 121, an extension interface unit 124, a digital interface unit 125, a tuner/demodulation unit 131, a separation unit 132, a video decoder 141, a video color gamut conversion unit 142, an audio decoder 143, a text superimposition decoder 144, a subtitle decoder 145, a subtitle synthesis unit 146, a subtitle color gamut conversion unit 147, a data decoder 151, a cache unit 152, an application control unit 153, a browser unit 154, an application color gamut conversion unit 155, a sound source unit 156, a video synthesis unit 161, a monitor unit 162, a video output unit 163, an audio synthesis unit 164, a speaker unit 165, an audio output unit 166, and an operation input unit 170.

The main control unit 101 is a microprocessor unit that controls the entire broadcast receiving device 100 according to a predetermined operating program. The system bus 102 is a data communication path for transmitting and receiving data between the main control unit 101 and each operating block within the broadcast receiving device 100.

ROM (Read Only Memory) 103 is a non-volatile memory that stores basic operation programs such as an operating system and other operation programs, and may be a rewritable ROM such as an EEPROM (Electrically Erasable Programmable ROM) or a flash ROM. Operation setting values required for the operation of the broadcast receiving device 100 may be stored in ROM 103. RAM (Random Access Memory) 104 serves as a work area when the basic operation programs and other operation programs are executed. ROM 103 and RAM 104 may be integrated with the main control unit 101. ROM 103 may not be an independent configuration as shown in FIG. 7A, but may use a portion of the storage area in the storage unit 110.

The storage (accumulation) unit 110 stores the operation program and operation setting values of the broadcast receiving device 100, personal information of the user of the broadcast receiving device 100, etc. It can also store operation programs downloaded via the Internet 200 and various data created by the operation programs. It can also store content such as videos, still images, and audio acquired from broadcast waves or downloaded via the Internet 200. A portion of the storage (accumulation) unit 110 may replace all or part of the functions of the ROM 103. The storage (accumulation) unit 110 must retain the stored information even when power is not being supplied from an external source to the broadcast receiving device 100. Therefore, for example, devices such as non-volatile semiconductor element memories such as flash ROM and SSD (Solid State Drive), and magnetic disk drives such as HDD (Hard Disc Drive) are used.

The operating programs stored in the ROM 103 and the storage unit 110 can be added to, updated, and have their functions expanded by downloading from each server device on the Internet 200.

The LAN (Local Area Network) communication unit 121 is connected to the Internet 200 via the router device 200r, and transmits and receives data to and from each server device and other communication devices on the Internet 200. It also acquires the MMT data string (or a part of it) of a program transmitted via a communication line. The connection to the router device 200r may be a wired connection or a wireless connection such as Wi-Fi (registered trademark). The LAN communication unit 121 includes an encoding circuit, a decoding circuit, and the like. The broadcast receiving device 100 may further include other communication units such as a BlueTooth (registered trademark) communication unit, an NFC communication unit, an infrared communication unit, and the like.

The tuner/demodulator 131 receives broadcast waves transmitted from the radio tower 300t via the antenna 100a, and tunes (selects) the channel of the service desired by the user under the control of the main controller 101. Furthermore, the tuner/demodulator 131 demodulates the received broadcast signal to obtain an MMT data string. Note that while the example shown in FIG. 7A illustrates a configuration with one tuner/demodulator, the broadcast receiving device 100 may be configured to include multiple tuner/demodulators for purposes such as simultaneous display of multiple screens and recording of other programs.

The separation unit 132 is an MMT decoder, and distributes the real-time presentation elements such as a video data string, an audio data string, a text superimposed data string, and a subtitle data string to the video decoder 141, the audio decoder 143, the text superimposed data string, and the subtitle decoder 145, based on the control signal in the input MMT data string. The data input to the separation unit 132 may be an MMT data string transmitted via a broadcast transmission path and demodulated by the tuner/demodulation unit 131, or an MMT data string transmitted via a communication line and received by the LAN communication unit 121. The separation unit 132 also plays back a multimedia application and file-based data that is a component of the application, and temporarily stores the data in the cache unit 152. The separation unit 132 also extracts generic data and outputs it to the data decoder 151 for use in streaming data for a player that presents data other than video, audio, and subtitles, or data for an application. In addition, the separation unit 132 may perform error correction and access restriction control on the input MMT data sequence based on the control of the main control unit 101.

The video decoder 141 decodes the video data string input from the separation unit 132 and outputs video information. The video color gamut conversion unit 142 performs color space conversion processing on the video information decoded by the video decoder 141 as necessary for video synthesis processing in the video synthesis unit 161. The audio decoder 143 decodes the audio data string input from the separation unit 132 and outputs the audio information. In addition, the video decoder 141 and the audio decoder 143 may be input with streaming data in, for example, MPEG-DASH (MPEG-Dynamic Adaptive Streaming over HTTP) format acquired from the Internet 200 via the LAN communication unit 121. In addition, a plurality of video decoders 141, video color gamut conversion units 142, audio decoders 143, etc. may be provided in order to simultaneously decode and process a plurality of types of video data strings and audio data strings.

The character superimposition decoder 144 decodes the character superimposition data string input from the separation unit 132 and outputs character superimposition information. The subtitle decoder 145 decodes the subtitle data string input from the separation unit 132 and outputs subtitle information. The character superimposition information output from the character superimposition decoder 144 and the subtitle information output from the subtitle decoder 145 are subjected to synthesis processing in the subtitle synthesis unit 146, and further, in the subtitle color gamut conversion unit 147, color space conversion processing is performed as necessary for video synthesis processing in the video synthesis unit 161. Note that in this embodiment, among the services centered on text information presented simultaneously with the video of a broadcast program, those related to the content of the video are referred to as subtitles, and the rest are referred to as character superimposition. Furthermore, when there is no distinction between them, they are collectively referred to as subtitles.

The browser unit 154 presents the multimedia application file and its component file data acquired from the server device on the Internet 200 via the cache unit 152 or the LAN communication unit 121 in accordance with the instructions of the application control unit 153, which interprets the control information included in the MMT data string and the control information acquired from the server device on the Internet 200 via the LAN communication unit 121. The multimedia application file may be an HTML (Hyper Text Markup Language) document or a BML (Broadcast Markup Language) document, etc. The application information output from the browser unit 154 is further subjected to color space conversion processing as necessary in the application color gamut conversion unit 155 for video synthesis processing in the video synthesis unit 161. The browser unit 154 also plays application audio information by influencing the sound source unit 156.

The video synthesis unit 161 inputs the video information output from the video color gamut conversion unit 142, the subtitle information output from the subtitle color gamut conversion unit 147, the application information output from the application color gamut conversion unit 155, and the like, and performs processing such as selection and/or superimposition as appropriate. The video synthesis unit 161 is equipped with a video RAM (not shown), and the monitor unit 162 and the like are driven based on the video information input to the video RAM. In addition, the video synthesis unit 161 performs scaling processing and superimposition processing of EPG (Electronic Program Guide) screen information created based on information such as MH-EIT included in MMT-SI, as necessary, based on the control of the main control unit 101. The monitor unit 162 is a display device such as a liquid crystal panel, and provides the video information selected and/or superimposed by the video synthesis unit 161 to the user of the broadcast receiving device 100. The video output unit 163 is a video output interface that outputs the video information that has been selected and/or superimposed by the video synthesis unit 161.

The presentation function of the broadcast receiving device 100 of this embodiment is provided with a logical plane structure in order to display the multimedia service as intended by the provider. FIG. 7B shows an example of the configuration of the logical plane structure provided by the presentation function of the broadcast receiving device 100 of this embodiment. In the logical plane structure, a character superimposition plane for displaying character superimposition is arranged in the foreground, and a subtitle plane for displaying subtitles is arranged in the next layer. A multimedia plane for displaying broadcast video, multimedia applications, or composite video thereof is arranged in the third layer, and a background plane is arranged in the background. The subtitle synthesis unit 146 and the video synthesis unit 161 draw character superimposition information on the character superimposition plane, subtitle information on the subtitle plane, and video information, application information, and the like on the multimedia plane. In addition, a background color is drawn on the background plane based on the LCT, etc. included in the MMT-SI. It is assumed that multiple third-layer multimedia planes can be prepared according to the number of video decoders 141. However, even if there are multiple multimedia planes, application information, etc. output from the application color gamut conversion unit 155 is output only to the foreground multimedia plane.

The voice synthesis unit 164 inputs the voice information output from the voice decoder 143 and the application voice information reproduced by the sound source unit 156, and performs processing such as selection and/or mixing as appropriate. The speaker unit 165 provides the voice information selected and/or mixed by the voice synthesis unit 164 to the user of the broadcast receiving device 100. The voice output unit 166 is an audio output interface that outputs the voice information selected and/or mixed by the voice synthesis unit 164.

The expansion interface unit 124 is a group of interfaces for expanding the functions of the broadcast receiving device 100, and in this embodiment, is composed of an analog video/audio interface, a USB (Universal Serial Bus) interface, a memory interface, etc. The analog video/audio interface inputs analog video/audio signals from external video/audio output devices, outputs analog video/audio signals to external video/audio input devices, etc. The USB interface connects to a PC or the like to send and receive data. A HDD may be connected to record broadcast programs and content. A keyboard or other USB device may also be connected. The memory interface connects to a memory card or other memory medium to send and receive data.

The digital interface unit 125 is an interface that outputs or inputs encoded digital video data and/or digital audio data. The digital interface unit 125 is capable of directly outputting the MMT data string obtained by demodulation in the tuner/demodulator unit 131, the MMT data string obtained via the LAN communication unit 121, or mixed data of the above-mentioned MMT data strings. In addition, the digital interface unit 125 may control the MMT data string input to the separator unit 132. The output of digital content stored in the storage unit 110, or the storage of digital content in the storage unit 110 may be performed via the digital interface unit 125.

The digital interface unit 125 may be a DVI terminal, an HDMI (registered trademark) terminal, a Display Port (registered trademark) terminal, etc., and may output or input data in a format conforming to the DVI specification, the HDMI specification, the Display Port specification, etc. It may output or input data in the form of serial data conforming to the IEEE 1394 specification, etc. It may also be configured as an IP interface that outputs digital interfaces via hardware such as Ethernet (registered trademark) or wireless LAN. In this case, the digital interface unit 125 and the LAN communication unit 121 may share the hardware configuration.

The operation input unit 170 is an instruction input unit that inputs operation instructions to the broadcast receiving device 100, and in this embodiment, is configured with a remote control receiving unit that receives commands transmitted from a remote control (not shown) and an operation key with an array of button switches. Only one of them may be used. The operation input unit 170 may also be replaced by a touch panel placed on top of the monitor unit 162. It may also be replaced by a keyboard or the like connected to the extended interface unit 124. The remote control (not shown) may also be replaced by a mobile information terminal 700 equipped with a remote control command transmission function.

As described above, when the broadcast receiving device 100 is a television receiver or the like, the video output unit 163 and the audio output unit 166 are not essential components of the present invention. In addition, the broadcast receiving device 100 may be a television receiver, an optical disk drive recorder such as a DVD (Digital Versatile Disc) recorder, a magnetic disk drive recorder such as a HDD recorder, a STB (Set Top Box), etc. It may also be a PC (Personal Computer), a tablet terminal, a navigation device, a game console, etc. equipped with a digital broadcast receiving function or a broadcast communication linkage function. When the broadcast receiving device 100 is a DVD recorder, a HDD recorder, a STB, etc., the monitor unit 162 and the speaker unit 165 may not be provided. By connecting an external monitor and external speakers to the video output unit 163 and audio output unit 166 or the digital interface unit 125, it becomes possible to perform operations similar to those of the broadcast receiving device 100 of this embodiment.

[System configuration of clock synchronization/presentation synchronization of broadcast receiving device]
FIG. 7C is an example of a system configuration of clock synchronization/presentation synchronization in a broadcasting system that the broadcast receiving device 100 of this embodiment supports. In the broadcasting system of this embodiment, UTC is transmitted from the broadcast sending system to the receiver (such as the broadcast receiving device 100 of this embodiment) in a 64-bit NTP timestamp format. In the NTP timestamp format, "seconds or more" of UTC are represented by 32 bits, and "less than a second" is represented by 32 bits. However, in reality, it is difficult to reproduce one second with 32-bit accuracy. For this reason, as a system clock for synchronizing a video system or a system clock for operating an NTP format clock, for example, a frequency of "2 to the 24th power" Hz (approximately 16.8 MHz) as shown in the figure may be used. In addition, considering that the system clock in the conventional broadcasting system was 27 MHz and that the hardware configuration of the receiver can be easily constructed, it is desirable to adopt a frequency of a power of 2, such as "2 to the 24th power" to "2 to the 28th power", as the system clock.

When the system clock is set to a power of 2 frequency, such as 2 to the 24th power or 2 to the 28th power, on the broadcast transmission system or receiver side, the lowest 8 to 4 bits in the NTP timestamp format transmitted from the broadcast transmission system to the receiver side, which are not referenced by the PLL (Phase Locked Loop) system for regenerating the system clock or the NTP format clock, may be fixed to 0 or 1. In other words, if the system clock is 2 to the nth power Hz (n=24 in the example of FIG. 7C), the lowest 32-n bits in the NTP timestamp format may be fixed to 0 or 1. Alternatively, the receiver side may process the lowest 32-n bits in the NTP timestamp format to be ignored.

When the broadcast transmission system receives NTP format time information from the outside, it configures a PLL system with a 32+n-bit counter using a 2n-power Hz VCO (Voltage Controlled Oscillator), and realizes a transmission system clock that synchronizes with the time information provided from the outside. It also operates the entire signal processing system in synchronization with the 2n-power Hz system clock. Furthermore, the output of the transmission system clock is periodically transmitted to the receiver side via the broadcast transmission path as NTP long format time information.

On the receiver side, the time information in the NTP long format is received via the broadcast transmission path, and the receiving system clock is regenerated by a PLL system based on a VCO of "2 to the power of n" Hz, just like on the broadcast transmission system side. This makes the receiving system clock a clock synchronized with the broadcast transmission system side. In addition, by operating the signal processing system of the receiver in synchronization with the system clock of "2 to the power of n" Hz, clock synchronization between the broadcast transmission system side and the receiver side is realized, enabling stable signal reproduction. In addition, the decoding time and presentation time for each presentation unit of the video/audio signal are set on the broadcast transmission system side based on the time information in the NTP format. Here, the MPT stored in the PA message transmitted by the broadcast signal stores the MPU timestamp descriptor shown in FIG. 13B described later. The "mpu_sequence_number" parameter in the MPU timestamp descriptor in Figure 13B indicates the sequence number of the MPU describing the timestamp, and the "mpu_presentation_time" parameter indicates the presentation time of the MPU in 64-bit NTP timestamp format. Therefore, the receiver can refer to the MPU timestamp descriptor stored in the MPT and control the presentation (display, output, etc.) timing of each MPU, such as the video signal, audio signal, subtitles, and superimposed text.

When focusing on the control of the decoding timing and presentation timing for each presentation unit of the aforementioned video/audio signals, etc., synchronization of the video/audio signals can be ensured even with a clock of about 2 to the power of 16 Hz (approximately 65.5 KHz), and in this case, it is not necessary to refer to the lower 16 bits of the NTP timestamp format described in the MPU timestamp descriptor, etc. In other words, if a clock of 2 to the power of m Hz generated by dividing the system clock, etc. is used to control the decoding timing and presentation timing, it is not necessary to refer to the lower 32-m bits of the NTP timestamp format described in the MPU timestamp descriptor, etc. Therefore, the lower 32-m bits of the NTP timestamp format described in the MPU timestamp descriptor, etc. may be fixed to 0 or 1.

[Software configuration of broadcast receiving device]
7D is a software configuration diagram of the broadcast receiving device 100 of this embodiment, and shows the software configuration in the ROM 103, the RAM 104, and the storage (accumulation) unit 110. In this embodiment, a basic operation program 1001 and other operation programs are stored in the ROM 103, and a receiving function program 1002 and other operation programs are stored in the storage (accumulation) unit 110. The storage (accumulation) unit 110 is also assumed to include a content storage area 1200 for storing content such as moving images, still images, and audio, an authentication information storage area 1300 for storing authentication information and the like required for accessing an external mobile terminal device or each server device, and various information storage areas for storing various other information.

The basic operation program 1001 stored in ROM 103 is expanded in RAM 104, and the main control unit 101 executes the expanded basic operation program to form a basic operation execution unit 1101. Similarly, the reception function program 1002 stored in the storage unit 110 is expanded in RAM 104, and the main control unit 101 executes the expanded reception function program to form a reception function execution unit 1102. The RAM 104 also has a temporary storage area for temporarily holding data created when each operation program is executed, as necessary.

In the following, for simplicity, the process in which the main control unit 101 controls each operation block by expanding the basic operation program 1001 stored in the ROM 103 into the RAM 104 and executing it will be described as the basic operation execution unit 1101 controlling each operation block. Similar descriptions will be used for the other operation programs.

The receiving function execution unit 1102 controls each operation block of the broadcast receiving device 100 to play components such as video and audio transmitted in the broadcasting system of this embodiment. In particular, the transport processing unit 1102a mainly controls the MMT decoder function of the separation unit 132, and distributes the video data string and audio data string separated from the MMT data string to the corresponding decoding processing units. The AV decoding processing unit 1102b mainly controls the video decoder 141 and audio decoder 143. The application processing unit 1102c mainly controls the cache unit 152, application control unit 153, browser unit 154, and sound source unit 156. The character superimposition processing unit 1102d mainly controls the character superimposition decoder 144. The subtitle processing unit 1102e mainly controls the subtitle decoder 145. The general-purpose data processing unit 1102f mainly controls the data decoder 151. The EPG generation unit 1102g interprets the description contents of the MH-EIT and the like included in the MMT-SI to generate an EPG screen. The presentation processing unit 1102h mainly controls the video color gamut conversion unit 142, the subtitle synthesis unit 146, the subtitle color gamut conversion unit 147, the application color gamut conversion unit 155, the video synthesis unit 161, and the audio synthesis unit 164 based on the logical plane structure.

The operating programs may be stored in the ROM 103 and/or the storage unit 110 beforehand at the time of product shipment. After product shipment, they may be acquired via the LAN communication unit 121 from other application servers 500 on the Internet 200. In addition, the operating programs stored on a memory card, optical disk, etc. may be acquired via the expansion interface unit 124, etc.

[Configuration of broadcast station server]
8 is a block diagram showing an example of the internal configuration of the broadcast station server 300. The broadcast station server 300 is made up of a main control unit 301, a system bus 302, a RAM 304, a storage unit 310, a LAN communication unit 321, and a digital broadcast signal transmission unit 360.

The main control unit 301 is a microprocessor unit that controls the entire broadcast station server 300 in accordance with a predetermined operation program. The system bus 302 is a data communication path for transmitting and receiving data between the main control unit 301 and each operation block within the broadcast station server 300. The RAM 304 serves as a work area when each operation program is executed.

The storage unit 310 stores a basic operation program 3001, a broadcast content management/distribution program 3002, and a broadcast content transmission program 3003, and further includes a broadcast content storage area 3200 and a metadata storage area 3300. The broadcast content storage area 3200 stores program content, etc., of each broadcast program broadcast by a broadcast station. The metadata storage area 3300 stores metadata, such as the program title, program ID, program summary, cast, broadcast date and time, and copy control information related to each program content, of each broadcast program.

The basic operation program 3001, broadcast content management/distribution program 3002, and broadcast content sending program 3003 stored in the storage unit 310 are each expanded in the RAM 304, and the main control unit 301 executes each of the expanded programs to form a basic operation execution unit 3101, a broadcast content management/distribution execution unit 3102, and a broadcast content sending execution unit 3103.

In the following, for ease of explanation, the process in which the main control unit 301 expands the basic operation program 3001 stored in the storage unit 310 into the RAM 304 and executes it to control each operation block will be described as the basic operation execution unit 3101 controlling each operation block. Similar descriptions will be used for the other operation programs.

The broadcast content management/distribution execution unit 3102 manages the program content and metadata of each broadcast program stored in the broadcast content storage area 3200 and the metadata storage area 3300, and controls the provision of the program content and metadata of each broadcast program to the service provider based on a contract. Furthermore, when providing the program content and metadata of each broadcast program to the service provider, the broadcast content management/distribution execution unit 3102 may perform authentication processing of the service provider server 400 based on the contract as necessary.

The broadcast content transmission execution unit 3103 performs time schedule management when transmitting the program content of the broadcast program stored in the broadcast content storage area 3200 and the MMT data sequence including the program title, program ID, and copy control information of the program content of the broadcast program stored in the metadata storage area 3300 from the radio tower 300t via the digital broadcast signal transmission unit 360.

The LAN communication unit 321 is connected to the Internet 200 and communicates with the service provider server 400 on the Internet 200. The LAN communication unit 321 includes an encoding circuit, a decoding circuit, and the like. The digital broadcast signal sending unit 360 modulates an MMT data sequence consisting of video data sequences, audio data sequences, program information data sequences, and the like, of the program contents of each broadcast program stored in the broadcast content storage area 3200, and sends it out as a digital broadcast wave via the radio tower 300t.

[Configuration of service provider server]
9 is a block diagram showing an example of the internal configuration of the service provider server 400. The service provider server 400 is composed of a main control unit 401, a system bus 402, a RAM 404, a storage unit 410, and a LAN communication unit 421.

The main control unit 401 is a microprocessor unit that controls the entire service provider server 400 in accordance with a predetermined operation program. The system bus 402 is a data communication path for transmitting and receiving data between the main control unit 401 and each operation block within the service provider server 400. The RAM 404 serves as a work area when each operation program is executed.

The storage unit 410 stores a basic operation program 4001, a video content management/distribution program 4002, and an application management/distribution program 4004, and further includes a video content storage area 4200, a metadata storage area 4300, an application storage area 4400, and a user information storage area 4500. The video content storage area 4200 stores the program content of the broadcast program provided by the broadcast station server 300 as video content. It also stores the video content and the like produced by the service provider. The metadata storage area 4300 stores each metadata provided by the broadcast station server 300 and metadata related to the video content produced by the service provider. The application storage area 4400 stores various applications and the like for realizing services linked to the broadcast program for distribution in response to requests from each television receiver. The user information storage area 4500 stores information (personal information, authentication information, etc.) related to users who are permitted to access the service provider server 400.

The basic operation program 4001, video content management/distribution program 4002, and application management/distribution program 4004 stored in the storage unit 410 are each expanded in the RAM 404, and the main control unit 401 executes the expanded basic operation program, video content management/distribution program, and application management/distribution program to form a basic operation execution unit 4101, a video content management/distribution execution unit 4102, and an application management/distribution execution unit 4104.

In the following, for ease of explanation, the process in which the main control unit 401 expands the basic operation program 4001 stored in the storage unit 410 into the RAM 404 and executes it to control each operation block will be described as the basic operation execution unit 4101 controlling each operation block. Similar descriptions will be used for the other operation programs.

The video content management/distribution execution unit 4102 acquires program contents and metadata of broadcast programs from the broadcast station server 300, manages the video contents and metadata stored in the video content storage area 4200 and the metadata storage area 4300, and controls the distribution of the video contents and metadata to each television receiver. Furthermore, when distributing the video contents and metadata to each television receiver, the video content management/distribution execution unit 4102 may perform authentication processing of each television receiver as necessary. Furthermore, the application management/distribution execution unit 4104 manages each application stored in the application storage area 4400 and controls the distribution of each application in response to a request from each television receiver. Furthermore, when distributing the application to each television receiver, the application management/distribution execution unit 4104 may perform authentication processing of each television receiver as necessary.

The LAN communication unit 421 is connected to the Internet 200, and communicates with the broadcast station server 300 on the Internet 200 and the broadcast receiving device 100 via the router device 200r. The LAN communication unit 421 is equipped with an encoding circuit, a decoding circuit, etc.

[Hardware configuration of mobile information terminal]
10A is a block diagram showing an example of the internal configuration of a portable information terminal 700. The portable information terminal 700 is composed of a main control unit 701, a system bus 702, a ROM 703, a RAM 704, a storage unit 710, a communication processing unit 720, an expansion interface unit 724, an operation unit 730, an image processing unit 740, an audio processing unit 750, and a sensor unit 760.

The main control unit 701 is a microprocessor unit that controls the entire portable information terminal 700 in accordance with a predetermined operating program. The system bus 702 is a data communication path for transmitting and receiving data between the main control unit 701 and each operating block within the portable information terminal 700.

ROM 703 is a memory in which basic operation programs such as an operating system and other operation programs are stored, and may be a rewritable ROM such as an EEPROM or flash ROM. RAM 704 serves as a work area when the basic operation programs and other operation programs are executed. ROM 703 and RAM 704 may be integrated with main control unit 701. Also, ROM 703 may not be an independent configuration as shown in FIG. 10A, but may use a portion of the memory area in storage unit 710.

The storage unit 710 stores the operation program and operation setting values of the mobile information terminal 700, personal information of the user of the mobile information terminal 700, etc. It can also store operation programs downloaded via the Internet 200 and various data created by the operation programs. It can also store content such as videos, still images, and audio downloaded via the Internet 200. A portion of the storage unit 710 may replace all or part of the functions of the ROM 703. The storage unit 710 must also retain the stored information even when the mobile information terminal 700 is not receiving external power. Therefore, for example, devices such as non-volatile semiconductor element memories such as flash ROM and SSDs, and magnetic disk drives such as HDDs are used.

The operating programs stored in the ROM 703 and the storage unit 710 can be added to, updated, and have their functions expanded by downloading them from each server device on the Internet 200.

The communication processing unit 720 is composed of a LAN communication unit 721, a mobile telephone network communication unit 722, and an NFC communication unit 723. The LAN communication unit 721 is connected to the Internet 200 via the router device 200r and the access point 200a, and transmits and receives data to and from each server device and other communication devices on the Internet 200. The connection to the router device 200r and the access point 200a is assumed to be made via a wireless connection such as Wi-Fi (registered trademark). The mobile telephone network communication unit 722 performs telephone communication (calls) and data transmission and reception through wireless communication with the base station 600b of the mobile telephone communication network. The NFC communication unit 723 performs wireless communication when in close proximity to a corresponding reader/writer. The LAN communication unit 721, the mobile telephone network communication unit 722, and the NFC communication unit 723 are assumed to each include an encoding circuit, a decoding circuit, an antenna, etc. Additionally, the communication processing unit 720 may further include other communication units, such as a BlueTooth (registered trademark) communication unit or an infrared communication unit.

The expansion interface unit 724 is a group of interfaces for expanding the functions of the portable information terminal 700, and in this embodiment, is composed of a video/audio interface, a USB interface, a memory interface, etc. The video/audio interface inputs video signals/audio signals from external video/audio output devices, outputs video signals/audio signals to external video/audio input devices, etc. The USB interface connects to a PC or the like to send and receive data. It may also be used to connect a keyboard or other USB devices. The memory interface connects to a memory card or other memory medium to send and receive data.

The operation unit 730 is an instruction input unit that inputs operation instructions to the mobile information terminal 700, and in this embodiment, is configured with a touch panel 730t arranged on top of the display unit 741 and operation keys 730k with an array of button switches. Only one of them may be used. The mobile information terminal 700 may be operated using a keyboard or the like connected to the extended interface unit 724. The mobile information terminal 700 may be operated using a separate terminal device connected by wired or wireless communication. In other words, the mobile information terminal 700 may be operated from the broadcast receiving device 100. The touch panel function may also be provided in the display unit 741.

The image processing unit 740 is composed of a display unit 741, an image signal processing unit 742, a first image input unit 743, and a second image input unit 744. The display unit 741 is a display device such as a liquid crystal panel, and provides image data processed by the image signal processing unit 742 to the user of the mobile information terminal 700. The image signal processing unit 742 is equipped with a video RAM (not shown), and the display unit 741 is driven based on the image data input to the video RAM. The image signal processing unit 742 also has a function of performing format conversion, superimposition processing of menus and other OSD (On Screen Display) signals, etc. as necessary. The first image input unit 743 and the second image input unit 744 are camera units that input image data of the surroundings or the object by converting the light input from the lens into an electrical signal using electronic devices such as a CCD (Charge Coupled Device) or CMOS (Complementary Metal Oxide Semiconductor) sensor.

The audio processing unit 750 is composed of an audio output unit 751, an audio signal processing unit 752, and an audio input unit 753. The audio output unit 751 is a speaker, and provides the audio signal processed by the audio signal processing unit 752 to the user of the mobile information terminal 700. The audio input unit 753 is a microphone, and converts the user's voice, etc. into audio data and inputs it.

The sensor unit 760 is a group of sensors for detecting the state of the mobile information terminal 700, and in this embodiment, is composed of a GPS receiver unit 761, a gyro sensor 762, a geomagnetic sensor 763, an acceleration sensor 764, an illuminance sensor 765, and a proximity sensor 766. These sensors make it possible to detect the position, inclination, direction, and movement of the mobile information terminal 700, as well as the brightness of the surroundings, the proximity of surrounding objects, and the like. The mobile information terminal 700 may also be equipped with other sensors, such as an air pressure sensor.

The portable information terminal 700 may be a mobile phone, a smartphone, a tablet terminal, or the like. It may also be a PDA (Personal Digital Assistant) or a notebook PC. It may also be a digital still camera, a video camera capable of recording video, a portable game machine, a navigation device, or other portable digital device.

The example configuration of the mobile information terminal 700 shown in FIG. 10A includes many components that are not essential to this embodiment, such as the sensor unit 760, but the effect of this embodiment is not diminished even if these components are not included in the configuration. In addition, components not shown, such as a digital broadcast receiving function and an electronic money payment function, may be added.

[Software configuration of mobile information terminal]
10B is a software configuration diagram of the portable information terminal 700 of this embodiment, and shows the software configuration in the ROM 703, the RAM 704, and the storage unit 710. In this embodiment, a basic operation program 7001 and other operation programs are stored in the ROM 703, and a linkage control program 7002 and other operation programs are stored in the storage unit 710. The storage unit 710 is also assumed to include a content storage area 7200 for storing content such as moving images, still images, and audio, an authentication information storage area 7300 for storing authentication information and the like required for accessing a television receiver or each server device, and various information storage areas for storing various other information.

The basic operation program 7001 stored in the ROM 703 is expanded in the RAM 704, and the main control unit 701 executes the expanded basic operation program to constitute a basic operation execution unit 7101. Similarly, the cooperative control program 7002 stored in the storage unit 710 is expanded in the RAM 704, and the main control unit 701 executes the expanded cooperative control program to constitute a cooperative control execution unit 7102. The RAM 704 also includes a temporary storage area for temporarily storing data created when each operation program is executed, as necessary.

In the following, for simplicity, the process in which the main control unit 701 loads the basic operation program 7001 stored in the ROM 703 into the RAM 704 and executes it to control each operation block will be described as the basic operation execution unit 7101 controlling each operation block. Similar descriptions will be used for the other operation programs.

The linkage control execution unit 7102 manages device authentication and connection, sending and receiving of data, and the like, when the mobile information terminal 700 performs linkage operations with the television receiver. The linkage control execution unit 7102 also has a browser engine function for executing applications that link with the television receiver.

The operating programs may be stored in the ROM 703 and/or the storage unit 710 beforehand at the time of product shipment. After product shipment, they may be acquired from other application servers 500 on the Internet 200 via the LAN communication unit 721 or the mobile telephone network communication unit 722. In addition, the operating programs stored in a memory card, optical disk, etc. may be acquired via the expansion interface unit 724, etc.

[Time management of broadcast receiving device]
The broadcast receiving device of this embodiment has two types of time management functions. The first time management function is a time management function based on NTP, as already explained with reference to Fig. 7C. The second time management function is a time management function based on MH-TOT, in which time is managed based on the time information transmitted by MH-TOT, as explained with reference to Fig. 6B.

An example of the configuration of time information transmitted by NTP is shown in FIG. 13A. An example of the data structure of the MPU timestamp descriptor is shown in FIG. 13B. The "reference_timestamp" parameter and "transmit_timestamp" parameter in the NTP format are 64-bit time data in the NTP long format, and the "mpu_presentation_time" parameter in the MPU timestamp descriptor is also 64-bit time data in the NTP timestamp format. The NTP long format time data and the NTP timestamp format time data are data in which UTC's "seconds or more" are represented by 32 bits and "less than a second" is represented by 32 bits. In other words, NTP format time information can transmit time information down to "less than a second". Furthermore, because the time information in NTP format is expressed in UTC, unlike the clock management used in conventional digital broadcasting, it can be consistent with the NTP contained in the signal received over the communication line path (for example, a communication line that can be received by the LAN communication unit 121 in FIG. 7A) as shown in FIG. 3(B).

In contrast, the information transmitted by MH-TOT is as follows. It is assumed that the broadcast receiving device 100 is capable of acquiring the current date and Japan Standard Time from MH-TOT. An example of the data structure of MH-TOT is shown in FIG. 11A. The broadcast receiving device 100 is capable of acquiring the current date and the current time from the "JST_time" parameter of the MH-TOT. As shown in FIG. 11B, the "JST_time" parameter is assumed to include the lower 16 bits of the coded data of the current date based on the Modified Julian Date (MJD) and 24 bits of information that represents Japan Standard Time (JST) as six 4-bit binary-coded decimal (BCD) numbers. The current date can be calculated by performing a specified calculation on the 16-bit encoded data of the MJD. The six 4-bit binary coded decimal numbers are: two 4-bit binary coded decimal numbers represent the hour in two decimal digits, the next two 4-bit binary coded decimal numbers represent the minutes in two decimal digits, and the last two 4-bit binary coded decimal numbers represent the seconds in two decimal digits.

The difference between time based on NTP and time based on MH-TOT is that NTP, as mentioned above, transmits time information in UTC notation down to the "second," whereas MH-TOT transmits information in JST notation down to the "second."

The broadcast receiving device 100 of this embodiment can achieve more accurate synchronization processing by using a time management function based on NTP, which is time information in UTC notation, to synchronize the decoding and display of the video, audio, subtitles, superimposed text, and other presented data that are the content of the broadcast signal. Furthermore, by referring to information in UTC notation rather than the clock notation of the broadcast station, it is also possible to perform synchronization processing for the decoding and display of the video, audio, subtitles, superimposed text, or other data that are the content of the broadcast signal received by the broadcast signal and the video, audio, subtitles, superimposed text, or other data obtained via the communication line path.

Furthermore, the broadcast receiving device of this embodiment may use the time management function based on "JST_time" including 24-bit information expressed by six 4-bit binary-coded decimal numbers of MH-TOT for the process of presenting the current time to the user or each process that handles the MH-Event Information Table (MH-EIT) described in FIG. 6B. In general, the process of presenting the current time to the user in the broadcast receiving device rarely requires accuracy to the nearest second. Also, each piece of time information described in the MH-Event Information Table (MH-EIT) is stored in two decimal digits each for "hours," "minutes," and "seconds" as 24-bit information expressed by six 4-bit binary-coded decimal numbers, similar to the EIT of conventional digital broadcasts transmitted by the MPEG2-TS method. For this reason, the time management function based on MH-TOT in the broadcast receiving device 100 of this embodiment is easily compatible with the process that uses MH-EIT. Specifically, processes that use MH-EIT include program guide generation (described below), control of recording and viewing reservations, copyright management processes such as temporary storage, etc. Precision to the nearest second is rarely required for any of these processes, and precision to the nearest second is sufficient.

The program guide generation process, the control of recording and viewing reservations, and copyright management processes such as temporary storage are also functions that are installed in receivers of digital broadcasting systems using the conventional MPEG2-TS format. In this embodiment, if the broadcasting system is configured to handle the program guide generation process, the control of recording and viewing reservations, and copyright management processes such as temporary storage using time management processes that are consistent with conventional MPEG2-TS digital broadcasting systems, then when configuring a broadcast receiving device that has both the conventional MPEG2-TS format digital broadcast reception function and the MMT format digital broadcast reception function, it will no longer be necessary to design separate processing algorithms for these processes (program guide generation process, recording and viewing reservation control, copyright management processes such as temporary storage, etc.), which can reduce costs.

In addition, even if a receiver does not have the ability to receive digital broadcasts using the conventional MPEG2-TS format, and only has the ability to receive digital broadcasts using the MMT format, it is possible to develop the receiver at lower cost by using the algorithms of functions that are also installed in receivers for digital broadcast systems using the conventional MPEG2-TS format, without having to create completely new algorithms for processes such as generating program guides, controlling recording and viewing reservations, and copyright management processes such as temporary storage.

Therefore, by configuring the time management function based on the MH-TOT "JST_time" parameter for these processes (such as program guide generation, recording and viewing reservation control, and copyright management processes such as temporary storage), it will be possible to provide MMT digital broadcast receiving devices at a lower cost by improving compatibility with conventional broadcasting systems.

As described above, the broadcast receiving device 100 of this embodiment has a time management function that uses two types of time information with different accuracy. One type of time information is time information written in a format that is consistent with conventional digital broadcasting systems, and the other type of time information is time information with a higher resolution than the first type of time information. By using the latter type of time information for synchronizing each content data of the broadcast signal, more advanced information presentation processing than conventional broadcasting systems is realized, and by using the former type of time information for generating a program guide, controlling recording and viewing reservations, and copyright management processing such as temporary storage, a broadcast receiving device can be provided at a low cost.

Therefore, by providing the two types of time management functions described above, the broadcast receiving device 100 of this embodiment can achieve both more advanced information presentation processing and lower costs.

[First Modification of Time Management]
Next, a first modification of the time management in the broadcasting system of this embodiment will be described below.

In a first variant, in order to improve the accuracy of the management time of the NTP-based time management function already described with reference to FIG. 7C, information regarding an estimated delay time in the transmission of time information from a time management server (not shown) or broadcast station server 300 to the broadcast receiving device 100 may be included in the broadcast signal and transmitted, and the broadcast receiving device 100 may be configured to use the information regarding the estimated delay time to correct the system clock of the NTP-based time management function.

In this case, the information on the expected delay time may be configured to be transmitted not in the TLV multiplexed stream shown in FIG. 3A, but in a TMCC (Transmission and Multiplexing Configuration Control) area outside the TLV multiplexed stream. If the information is transmitted in the TMCC area, the broadcast receiving device 100 can extract the information on the expected delay time without undergoing a separation process (demux process) of the TLV multiplexed stream. In other words, it is possible to obtain information that is less susceptible to the delay caused by the separation process in the broadcast receiving device 100, and therefore it is possible to perform a highly accurate system clock correction process. An example of the data structure of the time information transmitted by the TMCC signal is described with reference to FIG. 13C. The time information may be stored in the TMCC extension information area and transmitted, for example. In the time information in the TMCC extension information area of FIG. 13C, the "delta" parameter represents the expected value of the transmission delay from the time management server that distributes UTC or the server device that creates the TMCC signal to a general broadcast receiving device, using a 32-bit signed fixed point. The upper 16 bits describe the integer part, and the lower 16 bits describe the decimal part. The "transmit_timestamp" parameter is a transmission timestamp, and describes the time when this TMCC signal is sent from the server device in NTP timestamp length format. The upper 32 bits represent the integer part, and the lower 32 bits represent the decimal part.

In the first modified example, the broadcast receiving device 100 of this embodiment can correct the system clock of the NTP-based time management function used for synchronizing each content data of the broadcast signal with higher accuracy by using information about the expected delay time described in the time information stored in the TMCC extended information area and transmitted (for example, the aforementioned "delta" parameter and/or "transmit_timestamp" parameter).

[Second Modification of Time Management]
Next, a second modification of the time management in the broadcasting system of this embodiment will be described below.

As mentioned above, the broadcast receiving device 100 of this embodiment has a time management function that acquires the current date and Japan Standard Time from information transmitted by MH-TOT and manages the time. The current date and Japan Standard Time acquired from information transmitted by MH-TOT can be superimposed on video information, application information, etc. by the video synthesis unit 161 of the broadcast receiving device 100, and output to the monitor unit 162 or video output unit 163 for provision to the user. As mentioned above, MH-TOT has the data structure shown in FIG. 11A, and the broadcast receiving device 100 can acquire the current date and current time from the "JST_time" parameter of the MH-TOT.

However, the aforementioned "JST_time" parameter only uses the lowest 16 bits of the MJD encoded data, so an overflow occurs at "April 22, 2038", and dates after "April 23, 2038" cannot be expressed using the specified calculation alone. Therefore, in the second variant of this embodiment, the calculation method is switched between when the MJD value is equal to or greater than a specified value and when it is less than the specified value, so that dates after "April 23, 2038" can be expressed.

Figure 12 shows an example of a first calculation method used when the MJD value is equal to or greater than a predetermined value, and a second calculation method used when the MJD value is less than the predetermined value. For example, if the predetermined value is "32768 (0x8000)", the first calculation method is used to calculate the current date when the MJD is equal to or greater than "32768", and the second calculation method is used to calculate the current date when the MJD is less than "32768". Note that the case where the MJD is less than "32768" is equivalent to the case where the most significant bit of the 16-bit data of the MJD is "0". This makes it possible for the broadcast receiving device 100 of this embodiment to express dates after "April 23, 2038". However, the predetermined value can be set arbitrarily, and the predetermined value may be set to "16384 (0x4000)" or "49152 (0xC000)", etc. The condition for switching the calculation method may be when the most significant 2 bits of the 16-bit data of the MJD are "00" or when the most significant 2 bits of the 16-bit data of the MJD are not "11." If the above-mentioned means is used with the predetermined value set to "32768," it will not be possible to express dates prior to "September 4, 1948," but this will not be a problem in practical use as a television receiver.

In addition, instead of switching between the first and second calculation methods depending on the comparison result between the MJD and the predetermined value, the first and second calculation methods may be switched depending on a flag that replaces part or all of the "reserved" parameter in the data structure of the MH-TOT shown in FIG. 11A or a newly added flag. For example, when the most significant bit of the 16-bit encoded data of the MJD is "0", the flag may be set to "1" if the MJD indicates "April 23, 2038" or later, and set to "0" if the MJD does not indicate "April 23, 2038" or later. Then, when the flag is "1", the second calculation method shown in FIG. 12 may be used, and when the flag is "0", the first calculation method may be used. Alternatively, a new descriptor having the same meaning as the flag may be prepared and placed in the MH-TOT.

As described above, the broadcasting system of this embodiment transmits absolute time in NTP format, and the broadcasting receiving device 100 of this embodiment has a time management function based on this NTP. Furthermore, the broadcasting receiving device 100 of this embodiment controls the decoding timing and presentation timing for each presentation unit of the video/audio signal by referring to the NTP timestamp etc. described in the MPU timestamp descriptor set on an MPU basis. As described above, the time information in the NTP format has the structure shown in FIG. 13A. Furthermore, the MPU timestamp descriptor has the structure shown in FIG. 13B.

Therefore, in the broadcast receiving device 100 of this embodiment, the "reference_timestamp" parameter, the "transmit_timestamp" parameter, or the "mpu_presentation_time" parameter, etc. may be referenced, and either the first calculation method or the second calculation method may be selected depending on the value of the referenced time data, etc. In other words, for example, if the most significant bit of the 64-bit NTP-length format time data is "0", the second calculation method may be used, and if it is not "0", the first calculation method may be used, etc.

Either way, the broadcast receiving device 100 of this embodiment can express dates after April 23, 2038.

[Broadcast receiving device channel selection process (initial scan)]
The AMT of the broadcasting system of this embodiment provides a list of multicast groups of IP packets so that IP packets transmitted by the TLV multiplexing method can be received without distinction from IP packets transmitted over a communication line as much as possible. Multiple IP multicast groups can be listed for one service identification. Also, an address mask can be used to efficiently describe consecutive IP addresses.

In the broadcast receiving device 100 of this embodiment, when scanning channels for initial settings or when rescanning to change settings, it is possible to store a list of services acquired from the TLV-NIT in non-volatile memory such as the ROM 103 or the storage unit 110, and further, it is possible to store a list of IP multicast groups corresponding to each of the services as IP-related information in the non-volatile memory in association with each of the services. By storing the list of services and the IP-related information in non-volatile memory and making them available for constant reference, it becomes unnecessary to re-acquire the TLV-NIT or AMT when switching channels, etc., and it becomes possible to acquire broadcast content efficiently.

Figure 14 shows an example of an operational sequence during channel scanning (rescanning) in the broadcast receiving device 100 of this embodiment.

When channel scanning begins, the reception function execution unit 1102 sets an initial frequency value to the tuner/demodulator unit 131 and instructs it to tune to that frequency value (S101). If the tuner/demodulator unit 131 successfully locks onto the set frequency value (S102: Yes), the reception function execution unit 1102 then acquires the TLV-NIT from the received signal (S103).

If the TLV-NIT acquired in the process of S103 is valid data (S104: Yes), the reception function execution unit 1102 acquires information such as the TLV stream ID and the original network ID from the acquired TLV-NIT (S105). FIG. 15A shows an example of the data structure of the TLV-NIT. The TLV stream ID information can be acquired from the "tlv_stream_id" parameter, and the original network ID information can be acquired from the "original_network_id" parameter. Furthermore, distribution system information regarding the physical conditions of the broadcast transmission path corresponding to each TLV stream ID/original network ID is acquired from the distribution system descriptor (S106), and a list of service IDs is acquired from the service list descriptor (S107). FIG. 15B shows an example of the data structure of the satellite distribution system descriptor. FIG. 15C shows an example of the data structure of the service list descriptor. If the TLV-NIT has multiple different data such as the TLV stream ID, the original network ID, the distribution system information, and the list of service IDs, the processes of S105 to S107 are repeated. Next, the reception function execution unit 1102 creates a service list based on the data acquired in the processes of S105 to S107, such as the TLV stream ID, the original network ID, the distribution system information, and the list of service IDs, and stores the created service list in the ROM 103 or the storage unit 110 (updates it when rescanning) (S108).

Next, the reception function execution unit 1102 acquires the AMT from the received signal (S109), and further acquires a list of IP multicast groups related to each service ID stored in the service list (S110). FIG. 15D shows an example of the data structure of the AMT. If the AMT has a list of IP multicast groups related to multiple service IDs, the process of S110 is repeated. If there are multiple AMTs that have lists of IP multicast groups related to different service IDs, the processes of S109 to S110 are repeated. Next, the reception function execution unit 1102 associates the list of IP multicast groups acquired in the process of S110 with the service ID as IP-related information and stores it in the ROM 103 or the storage unit 110, etc. (updates it when rescanning) (S111).

Note that if the tuner/demodulator unit 131 does not succeed in locking onto the set frequency value in the process of S102 (S102: No), and if the TLV-NIT acquired in the process of S103 is not valid data (S104: No), the processes of S105 to S111 are not performed.

After completing the process of S111, if the frequency value set in the tuner/demodulator 131 is the final frequency value of the channel scan range (S112: Yes), the reception function execution unit 1102 ends the process. On the other hand, if the frequency value set is not the final frequency value of the channel scan range (S112: No), the frequency value set in the tuner/demodulator 131 is increased (S113) and the processes of S102 to S111 are repeated. Note that if a single TLV-NIT can acquire service IDs for all services that make up the broadcast network, and if an AMT having a list of IP multicast groups related to the service IDs can be acquired, the processes of S112 to S113 are not necessary.

By performing the above-mentioned series of processes, the broadcast receiving device 100 of this embodiment creates/updates a list of services (service list) that make up the broadcast network when scanning channels during initial setup or when rescanning to change settings, and at the same time creates/updates a list of IP multicast groups (IP-related information) corresponding to each of the services, and further stores this information in non-volatile memory such as the ROM 103 or storage unit 110.

The rescan for the setting change may be performed automatically when a change in the information in the table is detected by referring to the "version_number" parameter of the TLV-NIT or AMT. When a change in the "version_number" parameter of either the TLV-NIT or AMT is detected, only the information about the table in which the change in the parameter was detected may be automatically updated. However, when the automatic update described above is performed, it is desirable to notify the user that a rescan has been performed automatically. Also, the user may be notified that a change has been made to the information in the table, and the user may be allowed to select whether or not to perform the rescan.

[Broadcast receiving device tuning process (channel switching)]
FIG. 16 is a diagram showing an example of an operation sequence when selecting a station (switching a channel) in the broadcast receiving device 100 of this embodiment.

When the user operates a remote control (not shown) to instruct channel switching, the reception function execution unit 1102 interprets the command sent from the remote control and specifies the service ID of the desired service (S201). Next, the reception function execution unit 1102 starts acquiring the AMT from the signal received by the tuner/demodulator unit 131. If the AMT is successfully acquired within a predetermined time (S202: Yes), information on a list of IP multicast groups corresponding to the service ID is acquired from the acquired AMT (S204). On the other hand, if the AMT is not successfully acquired within the predetermined time (S202: No), information on a list of IP multicast groups corresponding to the service ID is acquired (S204) by referring to IP-related information stored in the ROM 103 or storage unit 110 (S203). Note that the judgment process of S202 may not be performed and the IP-related information stored in the ROM 103 or storage unit 110 may always be referred to.

Next, the reception function execution unit 1102 starts acquiring the TLV-NIT from the received signal of the tuner/demodulator unit 131. If the TLV-NIT is successfully acquired within a predetermined time (S205: Yes), distribution system information for acquiring the IP data flow corresponding to the service ID is acquired from the acquired TLV-NIT (S207). On the other hand, if the TLV-NIT is not successfully acquired within the predetermined time (S205: No), the distribution system information for acquiring the IP data flow corresponding to the service ID is acquired (S207) by referring to the service list stored in the ROM 103 or the storage unit 110, etc. (S206). Note that the judgment process of S205 may not be performed, and the service list stored in the ROM 103 or the storage unit 110, etc. may always be referred to. After acquiring the distribution system information in the process of S207, the reception function execution unit 1102 then controls the tuner/demodulation unit 131 with the frequency value indicated in the acquired distribution system information, receives the IP data flow corresponding to the service ID (S208), extracts the MMT data string from the received IP data flow, and outputs it to the separation unit 132.

In the separation unit 132, the transport processing unit 1102a acquires an MMTP packet with a packet ID of "0" from the input MMT data sequence (S209), and further acquires the MPT contained in the acquired MMTP packet (S210). Next, the transport processing unit 1102a refers to the "MMT_package_id_byte" parameter of the acquired MPT, and checks whether the lowest 16 bits of the "MMT_package_id_byte" parameter are the same value as the service ID. In the example of the data structure of the MPT shown in FIG. 17, if the lowest 16 bits of the "MMT_package_id_byte" parameter are the same value as the service ID (S211: Yes), it is determined that the MMTP packet whose packet ID is "0" is an MMTP packet that contains data of the program corresponding to the service ID, and the MFU is obtained based on the information contained in the obtained MPT (S216).

On the other hand, if the lowest 16 bits of the "MMT_package_id_byte" parameter are not the same value as the service ID (S211: No), it is determined that the MMTP packet with the packet ID of "0" is not an MMTP packet having data of a program corresponding to the service ID. In this case, the transport processing unit 1102a acquires the PLT again (S212) and confirms the packet ID (assumed to be x) of the MMTP packet transmitting the MPT having the "MMT_package_id_byte" parameter corresponding to the service ID by checking the acquired PLT (S213). Furthermore, the transport processing unit 1102a acquires an MMTP packet with a packet ID of "x" from the input MMT data string (S214) and acquires the MPT included in the acquired MMTP packet (S215). Furthermore, it acquires the MFU based on the information contained in the acquired MPT (S216).

It is also possible to always perform steps S212 to S215 without performing steps S209 to S211. In this case, it is possible to reduce the processing time when data for a program corresponding to the service ID is stored in an MMTP packet with a packet ID other than "0".

When the MFU is acquired in the process of S216, the transport processing unit 1102a extracts the encoded video data, encoded audio data, etc. from the acquired MFU and outputs them to the video decoder 141, the audio decoder 143, etc. Below, video/audio decoding processing based on the control of the AV decoding processing unit 1102b and presentation processing based on the control of the presentation processing unit 1102h are performed, but since each of the above processes is publicly known, detailed explanations will be omitted.

The above series of processes enable the broadcast receiving device 100 of this embodiment to perform channel selection (channel switching) operations. In particular, as described with reference to FIG. 14 and FIG. 16, when scanning channels during initial setup or when rescanning to change settings, a service list and IP-related information are created and stored in a non-volatile memory such as the ROM 103 or the storage unit 110 so that they can be referenced at all times, and when selecting a channel (switching a channel), the service list and IP-related information stored in the non-volatile memory such as the ROM 103 or the storage unit 110 are referenced, thereby improving the efficiency of operations during channel selection (switching a channel). In other words, it is possible to shorten the time from the start of channel selection (switching a channel) to the end of channel selection (switching a channel) compared to the case where AMT or TLV-NIT is reacquired during channel selection (switching a channel).

[Screen layout control of broadcast receiving device]
It is assumed that the broadcast receiving device 100 of this embodiment is capable of controlling the screen layout based on the description of the LCT. An example of the data structure of the LCT is shown in FIG.

In the diagram, the "left_top_pos_x" and "right_down_pos_x" parameters indicate the horizontal position of the top left and bottom right of the region, respectively, as a percentage of the total number of pixels in the horizontal direction, when the left side of the full screen display is "0" and the right side is "100". The "left_top_pos_y" and "right_down_pos_y" parameters indicate the vertical position of the top left and bottom right of the region, respectively, as a percentage of the total number of pixels in the vertical direction, when the top side of the full screen display is "0" and the bottom side is "100". The "layer_order" parameter indicates the relative position of the region in the depth direction.

Examples of layout assignment to layout numbers based on the settings of each of the above parameters are shown in Figures 19A to 19D, along with the setting values of each of the above parameters.

Figure 19A shows the default layout setting of the broadcast receiving device 100 of this embodiment, and is an example in which only one area is set on the entire screen. Figure 19B shows an example in which the entire screen is divided into three areas, each of which is designated as "Area 0", "Area 1", and "Area 2". For example, if the number of pixels on the entire screen is 7680 pixels horizontally and 4320 pixels vertically, "Area 0" is set to the range (0,0)-(6143,3455) since the "left_top_pos_x" parameter is "0", the "left_top_pos_y" parameter is "0", the "right_down_pos_x" parameter is "80", and the "right_down_pos_y" parameter is "80". Similarly, "Area 1" is set to the range (6144,0)-(7679,4319), and "Area 2" is set to the range (0,3456)-(6143,4319).

Figure 19C is an example of setting three regions, similar to Figure 19B, but "region 0" is set in the range of (0,0)-(7679,4319), and "region 1" and "region 2" are placed in front of "region 0" in the same range as above, according to the setting of the "layer_order" parameter. Figure 19D is an example of the case where "region 0" is set in device 0 (default device: in this example, broadcast receiving device 100), and "region 1" is set in device 1 (in this example, mobile information terminal 700).

As mentioned above, in the broadcasting system of this embodiment, by using LCT, it becomes possible to perform screen layout control to display multimedia services on the receiver as intended by the service provider.

When dividing the screen according to the setting values of parameters such as "left_top_pos_x", any fractional part after the decimal point can be rounded up or down. Rounding off (or rounding down to the nearest whole number in binary numbers) is also acceptable. For example, if the number of pixels on the entire screen is 7680 pixels/4320 pixels vertically, and the "left_top_pos_x" parameter of "area 0" is "0", the "left_top_pos_y" parameter is "0", the "right_down_pos_x" parameter is "51", and the "right_down_pos_y" parameter is "51", "area 0" may be set in the range of (0,0)-(3916,2203) by rounding up, or in the range of (0,0)-(3915,2202) by rounding down. Also, taking into account the macroblocks during video compression processing, rounding up/down processing may be performed in 8 pixel units or 16 pixel units. This processing makes it possible to efficiently perform area setting based on the LCT and resolution conversion processing of multimedia content in the area.

[Exception handling of screen layout control in broadcast receiving device]
In the broadcast receiving device 100 of this embodiment, even if the screen layout area control is performed by the above-mentioned LCT, when the user instructs to display an EPG screen, etc., it is possible to perform screen layout control that ignores the contents of the LCT as an exception process. Figure 20A shows an example of the operation of exception process of screen layout control based on the LCT.

When the same screen layout control as in FIG. 19B is performed according to the description in the LCT, and broadcast program video is displayed in "Area 0", and broadcast content such as program linkage data linked to the broadcast program is displayed in "Area 1" and "Area 2", and the user instructs the display of the EPG screen using a remote control (not shown), the broadcast receiving device 100 of this embodiment returns the screen layout setting to the default setting (i.e., a state in which the same screen layout control as in FIG. 19A is being performed) regardless of the contents of the description in the LCT, as shown in FIG. 20A (A), and controls the EPG screen to be displayed on the entire screen. Furthermore, when the user instructs the display of the EPG screen to end, the screen layout control according to the description in the LCT is re-executed.

By performing the above-mentioned control, the EPG screen can be displayed larger and easier to view than when the EPG screen is displayed while maintaining area control of the screen layout as shown in FIG. 20A (B).

The above-mentioned exception processing of the screen layout control is not only applied when the EPG screen is displayed, but may also be applied when a sub-screen or dual-screen display is displayed for various setting screens (the recording setting screen in the illustrated example) of the broadcast receiving device 100, as shown in FIG. 20B.

In the case of the recording setting screen shown in FIG. 1A, the display area of the broadcast content is changed from the entire screen to only the sub-screen portion at the bottom right of the screen. Similarly, in the case of the dual-screen display shown in FIG. 1B, the display area of the broadcast content is changed from the entire screen to only the split screen portion at the left middle section of the screen. In either case, the display area for displaying the broadcast content is narrower than when the entire screen is used, so maintaining the area control of the screen layout within the display area (i.e., dividing the area to display multiple broadcast contents simultaneously) is not desirable from a visual standpoint. Therefore, in the broadcast receiving device 100 of this embodiment, in the above situation, only the broadcast content in "Area 0" is selected and displayed in the display area. Note that it is also possible to select and display the broadcast content in "Area 1" or "Area 2" depending on the immediately preceding area selection situation.

By performing the above-mentioned control, it is possible to improve the ease of viewing the broadcast content compared to when various broadcast contents are displayed while maintaining area control of the screen layout. The same is true when displaying a sub-screen on the recorded program list screen, when displaying Internet content in a browser, etc.

[EPG display on broadcast receiving device]
In the broadcasting system of this embodiment, time-series information on events (so-called programs) included in each service constituting the broadcasting network is transmitted by the MH-EIT. FIG. 21 shows an example of the data structure of the MH-EIT of this embodiment. The MH-EIT is identified into two classes by a table ID (corresponding to the "table_id" parameter in the figure), and is capable of indicating information on the current/next event of the own TLV stream and schedule information of each event of the own TLV stream. The broadcast receiving device 100 of this embodiment is capable of acquiring information such as the start time and broadcast time of each event by identifying the event by a service ID (corresponding to the "service_id" parameter in the figure) with reference to the MH-EIT, etc., and creating an EPG screen, and is capable of superimposing the created EPG on video information, etc. by the video synthesis unit 161 and displaying it on the monitor unit 162.

Figure 22A is a diagram showing an example of an EPG screen in the broadcast receiving device 100 of this embodiment. The EPG screen 162a is in a matrix shape with the vertical axis indicating time and the horizontal axis indicating service ID (channel), and displays detailed information about broadcast programs broadcast on each channel during each time period. In addition, the detailed information 162a1 of each broadcast program is mainly composed of a title area 162a2 and a detailed description area 162a3.

The title area 162a2 displays the program title of the broadcast program and symbols and the like representing the attributes of the broadcast program. The symbols and the like representing the attributes of the broadcast program are, for example, symbols/characters indicating that it is a new program, or symbols/characters indicating that it is a rebroadcast program, etc. Alternatively, it may be a symbolized mark such as "data", which means that it supports data broadcasting by a broadcasting service. It may also be a symbolized mark 162a4 such as "Network", which means that content, applications, etc. related to the broadcast program can be obtained from a network. Furthermore, the symbols and the like representing the attributes of the broadcast program may be replaced by differentiating the background color of the detailed information 162a1 from others, or by surrounding the display area of the detailed information 162a1 with a thick frame.

Even if the control information (messages, tables, descriptors, etc.) in the broadcasting system of this embodiment indicates that content, applications, etc. related to the broadcast program can be obtained from the network, if the LAN cable is not connected to the LAN communication unit 121 of the broadcast receiving device 100, or if access to each server device on the network is not possible, the mark 162a4 symbolizing "Network" etc. may be controlled not to be displayed.

In addition, when the broadcast program is a distributed program distributed via the Internet 200 and cannot be acquired only from the broadcast waves, and further, as described above, when the broadcast receiving device 100 is in a state where it cannot access each server device on the network, the detailed information 162b1 displayed on the EPG screen 162b may be controlled to be grayed out as shown in FIG. 22B. In other words, the detailed information of the distributed program that cannot be viewed is controlled not to be displayed. Alternatively, the graying out process may be substituted by differentiating the background color of the detailed information 162b1 from the others. When the detailed information 162b1 is selected by operating the remote control (not shown), the user may be notified by a pop-up or the like that the broadcast receiving device 100 is in a state where it cannot access each server device on the network, or that the distributed program associated with the detailed information 162b1 cannot be viewed.

Through the above-mentioned controls, the broadcast receiving device 100 is able to provide the user with program information for each broadcast program in a format that feels more natural to the user, depending on the network connection status.

Figure 22C is a diagram showing another example of an EPG screen in the broadcast receiving device 100 of this embodiment. In the figure, "M1 Television", "M2 Broadcast", "M3 Channel", "M4 TV", "Television M5", etc. are the broadcast station names for each channel, and in particular, the "M2 Broadcast" station simultaneously provides broadcast programs distributed by airwaves and distributed programs distributed via the Internet 200 (slot information 162c1 indicated by "Internet Broadcast" in the figure).

As shown in the figure, when there is a channel that only has programs distributed via the Internet 200, the EPG screen 162c in the figure (A) is normally controlled to display information for all channels (including information 162c1). On the other hand, when the broadcast receiving device 100 is in a state where it cannot access each server device on the network, the EPG screen 162d in the figure (B) may be controlled not to display information for the "M2 Broadcast (Internet Broadcast)" channel (information 162c1 in the figure (A)), which only has programs distributed via the Internet 200.

The above-mentioned controls make it possible for users of the broadcast receiving device 100 to avoid having to check information about channels that they cannot watch.

[Emergency warning broadcast display on broadcast receiving device]
The broadcast receiving device 100 of this embodiment is capable of performing receiving processing of an emergency alert broadcast when the emergency alert broadcast start control signal bit of the TMCC signal contained in the transmission data including the TLV stream changes from "0" to "1."

The emergency alert broadcast may be provided as a full-screen application or as text information with superimposed text. When the emergency alert broadcast is provided as text information with superimposed text, it is preferable to display the text information of the superimposed text, regardless of the state of the broadcast receiving device 100 immediately before receiving the emergency alert broadcast. That is, as shown in FIG. 23, when a user is watching a normal broadcast program and an emergency alert broadcast is received while a program screen 162e of the broadcast program is displayed on the monitor unit 162, the text information 162e1 of the emergency alert broadcast is superimposed on the program screen 162e. Similarly, when a user instructs the display of an EPG screen and an emergency alert broadcast is received while an EPG screen 162f is displayed on the monitor unit 162, the text information 162f1 of the emergency alert broadcast is superimposed on the EPG screen 162f.

By the above-mentioned control, in the broadcast receiving device 100 of this embodiment, even if the user selects and displays an EPG screen, various setting screens, a recorded program list screen, an Internet browser, etc., when an emergency alert broadcast is received, it is possible to avoid missing important text information based on the emergency alert broadcast. Note that this control may also be performed on text information of normal text superimpositions that are not based on emergency alert broadcasts.

[Various exception handling]
If the broadcast receiving device 100 of this embodiment cannot obtain data outside the TLV stream in the same package, it may perform exception processing, for example, as described below.

As described in FIG. 6E, in the broadcasting system supported by the broadcast receiving device 100 of this embodiment, the data acquired in the TLV stream and the data acquired via a route other than the TLV stream can be included in the same package based on the location information stored in the MPT (corresponding to "MMT_general_location_info()" in FIG. 17). However, the data transmission route other than the TLV stream indicated by the location information (e.g., IPv4 data flow, IPv6 data flow, broadcast MPEG2-TS, etc.) is a receiving function separate from the receiving function of the TLV/MMT stream. Therefore, even when the broadcast receiving device 100 is operating, there may be a situation in which data cannot be acquired from these transmission routes, such as a situation in which the receiving function of these transmission routes is not operating, a situation in which the receiving function itself is operating but a relay device or the like is not operating, a situation in which these transmission routes are not connected by wire or wirelessly, or a situation in which the broadcast receiving device 100 is installed in an environment in which these transmission routes cannot be connected in the first place.

Under such circumstances, when an event is received in which the location information stored in the MPT indicates that data acquired within the TLV stream and data acquired via a route other than the TLV stream are to be associated so as to be included in the same package, the broadcast receiving device 100 of this embodiment may perform, for example, the following operations.

For example, in the case where the LCT sets multiple regions in the screen as shown in FIG. 19B or FIG. 19C, and the video contained in the TLV stream is displayed in "region 0", and data acquired through a transmission path other than the TLV stream is displayed in "region 1" or "region 2", and data from a transmission path other than the TLV stream to be displayed in "region 1" or "region 2" cannot be acquired, the layout display of the multiple regions specified by the LCT may be prohibited. Specifically, even if the LCT is received, the video of the content received in the TLV stream may be left displayed in "region 0" of the default layout display shown in FIG. 19A, and the layout display of the multiple regions may not be changed to that of FIG. 19B or FIG. 19C. Furthermore, even if an instruction to change the default layout to the layout indicated by the LCT is input to the operation input unit 170 of FIG. 7A in this state, the default layout display shown in FIG. 19A may be left as it is, or the display may be switched to another data broadcasting screen, so that the layout display of the multiple regions may not be changed to that of FIG. 19B or FIG. 19C.

As shown in Fig. 19B and Fig. 19C, when the LCT sets multiple regions within the screen, and the video contained in the TLV stream is displayed in "region 0", and data acquired via a transmission path other than the TLV stream is displayed in "region 1" and "region 2", and data of a transmission path other than the TLV stream to be displayed in "region 1" and "region 2" cannot be acquired, another example of operation when the display frame of the multiple regions shown in Fig. 19B and Fig. 19C indicated by the LCT is displayed once, and a background color or a specified still image is displayed in "region 1" and "region 2". If data of a transmission path other than the TLV stream indicated by the location information of the MPT cannot be acquired even after a specified time has elapsed, the display may be switched back to the default layout display state shown in Fig. 19A. In this case, it is preferable to operate so that the program video contained in the TLV stream continues to be displayed in "region 0" even when the layout of Fig. 19A, Fig. 19B, and Fig. 19C is changed, since the user's program video itself will continue.

In addition, when the video of the content received in the TLV stream is displayed in "Area 0" of the default layout display shown in FIG. 19A due to the inability to obtain data of a transmission path other than the TLV stream to be displayed in "Area 1" or "Area 2", the operation of various communication functions and various reception functions of the broadcast receiving device 100 of this embodiment may start, or the communication environment or communication status of the various communication functions or the reception environment or reception status of the various reception functions may change, resulting in a situation in which data of a transmission path other than the TLV stream to be displayed in "Area 1" or "Area 2" can be obtained. In this case, the broadcast receiving device 100 of this embodiment may immediately switch from the default layout display shown in FIG. 19A to a layout of multiple areas as shown in FIG. 19B or FIG. 19C indicated by the LCT, and may display the video of the content received in the TLV stream in "Area 0", and switch to display data obtained from a transmission path other than the TLV stream in "Area 1" or "Area 2". Alternatively, the layout change may not be performed immediately, but may be performed after an instruction to change from the default layout to the layout indicated by the LCT is input from the operation input unit 170.

[Copyright protection function]
In the digital broadcasting system compatible with the broadcast receiving device 100 of this embodiment, by including copy control information in the MPT and transmitting it, the copy control information may be configured to transmit, for example, "unlimited copying allowed" (which may be divided into two types: "unlimited copying allowed and encryption processing required when storing and outputting" and "unlimited copying allowed and encryption processing not required when storing and outputting"), "one generation only allowed", "predetermined number of times of copying allowed" (for example, so-called "dubbing 10" if nine times of copying and one time of moving allowed), "copy prohibited", etc. of the content referred to by the MPT. In this case, the broadcast receiving device 100 of this embodiment may be configured to control the storage of the content in the storage (storage) unit 110, recording on a removable recording medium, output to an external device, copying to an external device, moving to an external device, etc., according to the copy control information. Note that the target of the storage process may include not only the storage (storage) unit 110 inside the broadcast receiving device 100, but also records that have been subjected to protection processing such as encryption processing so that they can be played back only by the broadcast receiving device 100. Specifically, the targets of the storage process include external recording devices and the like that are in a state where recording and playback can be performed only by the broadcast receiving device 100 .

Specific examples of processing based on the copy control information are described below.

First, when the copy control information included in the MPT indicates "unlimited copying", the broadcast receiving device 100 of this embodiment may store in the storage unit 110, record on a removable recording medium, output to an external device, copy to an external device, and move to an external device without restrictions. However, when "unlimited copying and encryption processing required at the time of storage and output" is separated from "unlimited copying and no encryption processing required at the time of storage and output", in the case of "unlimited copying and encryption processing required at the time of storage and output", storage in the storage unit 110, recording on a removable recording medium, output to an external device, copy to an external device, and move to an external device may be performed an unlimited number of times, but encryption processing must be performed in all cases.

In addition, if the copy control information included in the MPT indicates "copyable for one generation only," the broadcast receiving device 100 of this embodiment allows for encryption and storage in the storage (accumulation) unit 110, but when outputting the stored content to an external device for viewing, it will be encrypted and output together with copy control information indicating "copy prohibited." However, so-called move processing to an external device (processing in which content is copied to an external device and the content in the storage (accumulation) unit 110 of the broadcast receiving device 100 is made unplayable by erasing the content, etc.) is possible.

In addition, if the copy control information included in the MPT indicates that copying is permitted a specified number of times, the broadcast receiving device 100 of this embodiment allows the content to be encrypted and stored in the storage (accumulation) unit 110, but when outputting the stored content to an external device for viewing, it will be encrypted and output together with copy control information indicating "copy prohibited." However, a predetermined number of copies and move processes may be allowed to be made to external devices. In the case of the so-called "dubbing 10" provision, nine copies and one move process may be made to external devices.

In addition, if the copy control information included in the MPT indicates "copy prohibited", the broadcast receiving device 100 of this embodiment prohibits copying to the storage unit 110. However, if the broadcast receiving device 100 is configured to have a "temporary storage" mode that allows storage in the storage unit 110 only for a predetermined period of time or a predetermined period of time specified by control information included in the broadcast signal (for example, by the MH-Expire descriptor shown in FIG. 6D), the content can be temporarily stored in the storage unit 110 even if the copy control information included in the MPT indicates "copy prohibited". When the content for which the copy control information included in the MPT indicates "copy prohibited" is output for viewing on an external device, it is encrypted and output together with the copy control information indicating "copy prohibited".

The output for viewing to the aforementioned external device may be performed via the video output unit 163 and audio output unit 166 in FIG. 7A, or via the digital I/F unit 125 and LAN communication unit 121, etc. The copy or move process to the aforementioned external device may be performed via the digital I/F unit 125 and LAN communication unit 121, etc. in FIG. 7A.

The process described above makes it possible to achieve appropriate content protection according to the copy control information associated with the content.

In addition, copying of content whose copy control information indicates copy restrictions such as "Copyable for one generation only", "Copyable a specified number of times", or "Copying prohibited" to an external device via the LAN communication unit 121 may be permitted only when the IP address of the external device that is the destination of the packet transmitted from the broadcast receiving device 100 is in the same subnetwork as the IP address of the broadcast receiving device 100, and may be prohibited when the IP address of the external device is outside the same subnetwork as the IP address of the broadcast receiving device 100. Content whose copy control information indicates "Copyable without limit and requires encryption processing when stored and output" may also be handled in the same manner.

Similarly, the process of moving content whose copy control information indicates copy restrictions such as "Copyable for one generation only", "Copyable a specified number of times", or "Copyable an unlimited number of times with encryption processing required when storing and outputting" to an external device via the LAN communication unit 121 after it has been stored in the storage unit 110 is only possible if the IP address of the external device that is the destination of the packet sent from the broadcast receiving device 100 is in the same subnetwork as the IP address of the broadcast receiving device 100, and may be prohibited if the IP address of the external device is outside the same subnetwork as the IP address of the broadcast receiving device 100.

In principle, video output and audio output for viewing of the content stored in the storage (accumulation) unit 110 of the broadcast receiving device 100 are possible only when the IP address of the external device that is the destination of the transmission packet from the broadcast receiving device 100 is in the same subnetwork as the IP address of the broadcast receiving device 100, and are prohibited when the IP address of the external device is outside the same subnetwork as the IP address of the broadcast receiving device 100. However, if the external device is connected within the same subnetwork as the IP address of the broadcast receiving device 100 within a specified period of time and has been registered (paired) as a device that can be viewed even outside the same subnetwork as the IP address of the broadcast receiving device 100, it may be configured to enable video output and audio output for viewing of the content stored in the storage (accumulation) unit 110 of the broadcast receiving device 100 to the external device even if the IP address of the external device is outside the same subnetwork as the IP address of the broadcast receiving device 100. In this case, the video output and audio output for viewing are performed by encrypting the content.

According to the process described above, different processes are performed depending on whether the external device is in the same subnetwork as the IP address of the broadcast receiving device 100 or not, thereby achieving both user convenience and content protection.

Next, as explained in FIG. 6E, in the digital broadcasting system supported by the broadcast receiving device 100 of this embodiment, due to the location information in the MPT ('MMT_general_location_info()' in FIG. 17), data acquired via a different route (IPv4, IPv6, MPEG2-TS, URL, etc.) from the data acquired via the TLV stream of the broadcast route may be included in the same package and the same event as the data acquired via the TLV stream. In this case, content protection when copy control information is included in the MPT will be explained.

First, when copy control information is included in the MPT, data included in the same package and the same event in the location information may be controlled according to the copy control information included in the TLV stream, even if the data was obtained via a different route (IPv4, IPv6, MPEG2-TS, URL, etc.) than the data obtained via the TLV stream of the broadcast route. As described above, the copy control state of the content specified by this copy control information can be specified as "unlimited copying" (which may be divided into two types: "unlimited copying and encryption processing required when storing and outputting" and "unlimited copying and no encryption processing required when storing and outputting"), "one generation only copying", "a specified number of copies" (for example, 9 copies + 1 move is the so-called "dubbing 10"), "no copying", etc.

Here, if the data position indicated by the location information includes MPEG2-TS data transmitted in another digital broadcast signal, the MPEG2-TS data is also broadcast in association with copy control information in the other digital broadcast signal. This raises the question of how and according to which information copy control of the MPEG2-TS data should be performed (whether according to the copy control information included in the TLV/MMT stream, or according to the copy control information included in the MPEG2-TS).

In the digital broadcasting system of this embodiment, to solve this problem, the broadcast receiving device 100 can perform one of the following solutions:

<Operation example 1>
In a first operation example, when copy control information is included in the MPT and data included in the same package and the same event in the location information includes MPEG2-TS data transmitted in another digital broadcast signal, the copy control state indicated by the copy control information included in the TLV stream is given priority over the copy control state indicated by the copy control information included in the MPEG2-TS.

For example, if the copy control status indicated by the copy control information included in the TLV stream is "one-generation copy permitted" and the copy control status indicated by the copy control information included in the MPEG2-TS is "a specified number of times copy permitted," then even if the data was acquired via a different route (digital broadcast in MPEG2-TS transmission format) than the data acquired in the TLV stream, copy control may be performed on the data as "one-generation copy permitted" content. For example, if the copy control status indicated by the copy control information included in the TLV stream is "unlimited copying permitted" and the copy control status indicated by the copy control information included in the MPEG2-TS is "specified number of times copy permitted," then copy control may be performed on the data as "unlimited copying permitted" content, even if the data was acquired via a different route (digital broadcast in MPEG2-TS transmission format) than the data acquired in the TLV stream.

In this operation, data acquired via a route other than the TLV stream can also be put into a copy state that is desired to be managed in the broadcast system supported by the broadcast receiving device 100 of this embodiment.

<Operation example 2>
In a second operation example, when copy control information is included in the MPT, and data included in the same package and the same event in the location information includes MPEG2-TS data transmitted in another digital broadcast signal, the copy control state indicated by the copy control information included in the TLV stream is compared with the copy control state indicated by the copy control information included in the MPEG2-TS, and if the copy control state indicated by the copy control information included in the MPEG2-TS is stricter than the copy control state indicated by the copy control information included in the TLV stream, the MPEG2-TS data is excluded from the content to be processed when storing in storage unit 110 or the like, recording on a removable recording medium, or outputting from a digital interface.

In this operation, for data acquired via a route other than the TLV stream, duplication of copy control states on the broadcast receiving device 100 of this embodiment can be eliminated while respecting the original copy control information set in the broadcasting system that transmits the data.

In addition, if the comparison shows that the copy control state indicated by the copy control information contained in the MPEG2-TS is the same as or more lenient than the copy control state indicated by the copy control information contained in the TLV stream, copy control can be performed on the MPEG2-TS data contained in the same package and the same event in the location information as content in the copy control state indicated by the copy control information contained in the TLV stream.

In this operation, for data acquired via a route other than the TLV stream, duplication of copy control states on the broadcast receiving device 100 of this embodiment can be eliminated while respecting the original copy control information set in the broadcasting system that transmits the data.

In the above explanation, the copyright protection function of the broadcast receiving device 100 of this embodiment has been described as being performed based on the copy control information contained in the MPT. However, the table in which the copy control information is placed is not limited to the MPT. In addition to the MPT, the copy control information may be placed and transmitted in the MH-Service Description Table (MH-SDT) or MH-Event Information Table (MH-EIT) described in FIG. 6B, or in other tables, and the broadcast receiving device 100 may perform copyright protection processing according to these.

According to the present embodiment described above, it is possible to provide a broadcast receiver compatible with MMT digital broadcasting.
Example 2

The following describes Example 2 of the present invention. Note that the configuration, processing, effects, etc. of this example are the same as those of Example 1 unless otherwise specified. For this reason, the following mainly describes the differences between this example and Example 1, and explanations of common points are omitted as much as possible to avoid duplication. In addition, the following description will be given assuming that the broadcast receiving device of this example is a television receiver that supports both the MMT and MPEG2-TS media transport methods.

[Hardware configuration of broadcast receiving device]
24 is a block diagram showing an example of the internal configuration of a broadcast receiving device 800. The broadcast receiving device 800 is composed of a main control unit 801, a system bus 802, a ROM 803, a RAM 804, a storage unit 810, a LAN communication unit 821, an expansion interface unit 824, a digital interface unit 825, a first tuner/demodulation unit 831, a second tuner/demodulation unit 832, an MMT decode processing unit 841, an MPEG2-TS decode processing unit 842, a video synthesis unit 861, a monitor unit 862, a video output unit 863, an audio synthesis unit 864, a speaker unit 865, an audio output unit 866, and an operation input unit 870.

The main control unit 801, system bus 802, ROM 803, RAM 804, storage unit 810, expansion interface unit 824, digital interface unit 825, monitor unit 862, video output unit 863, speaker unit 865, audio output unit 866, operation input unit 870, etc. have the same functions as the main control unit 101, system bus 102, ROM 103, RAM 104, storage (accumulation) unit 110, expansion interface unit 124, digital interface unit 125, monitor unit 162, video output unit 163, speaker unit 165, audio output unit 166, operation input unit 170, etc. in the broadcast receiving device 100 of Example 1, and detailed explanations are omitted.

The first tuner/demodulator 831 receives the broadcast waves of a broadcast service that employs MMT as a media transport method via an antenna (not shown), and tunes (selects) the channel of the service desired by the user based on the control of the main control unit 801. Furthermore, the first tuner/demodulator 831 demodulates the received broadcast signal to obtain an MMT data string, and outputs it to the MMT decode processor 841. The second tuner/demodulator 832 receives the broadcast waves of a broadcast service that employs MPEG2-TS as a media transport method via an antenna (not shown), and tunes (selects) the channel of the service desired by the user based on the control of the main control unit 801. Furthermore, the second tuner/demodulator 832 demodulates the received broadcast signal to obtain an MPEG2-TS data string, and outputs it to the MPEG2-TS decode processor 842.

The MMT decode processing unit 841 inputs the MMT data sequence output from the first tuner/demodulation unit 831, and performs separation and decoding of the real-time presentation elements such as the video data sequence, the audio data sequence, the superimposed text data sequence, and the subtitle data sequence based on the control signal included in the MMT data sequence. The MMT decode processing unit 841 has functions equivalent to the separation unit 132, the video decoder 141, the video color gamut conversion unit 142, the audio decoder 143, the superimposed text decoder 144, the subtitle decoder 145, the subtitle synthesis unit 146, the subtitle color gamut conversion unit 147, the data decoder 151, the cache unit 152, the application control unit 153, the browser unit 154, the application color gamut conversion unit 155, the sound source unit 156, and the like in the broadcast receiving device 100 of the first embodiment. The MMT decode processing unit 841 is capable of performing the various processes described in the first embodiment. The details of the various processes are as described in the first embodiment, and therefore will not be described here.

The MPEG2-TS decode processing unit 842 inputs the MPEG2-TS data string output from the second tuner/demodulation unit 832, and performs processes such as separation and decoding of the real-time presentation elements such as the video data string, audio data string, superimposed text data string, and subtitle data string based on the control signal contained in the MPEG2-TS data string. The MPEG2-TS decode processing unit 842 has the same functions as the IRD (Integrated Receiver Decoder) unit of a conventional television receiver that receives broadcast waves from a broadcast service that uses MPEG2-TS as the media transport method, and detailed description will be omitted.

The video synthesis unit 861 inputs the video information, subtitle information, and application information output from the MMT decode processing unit 841 and the video information, subtitle information, and application information output from the MPEG2-TS decode processing unit 842, and performs processing such as selection and/or superimposition as appropriate. The video synthesis unit 861 is equipped with a video RAM (not shown), and the monitor unit 862 and the like are driven based on the video information input to the video RAM. Furthermore, the video synthesis unit 861 performs scaling processing, superimposition processing of EPG screen information, and the like as necessary based on the control of the main control unit 801. The audio synthesis unit 164 inputs the audio information output from the MMT decode processing unit 841 and the audio information output from the MPEG2-TS decode processing unit 842, and performs processing such as selection and/or mixing as appropriate.

The LAN communication unit 821 is connected to the Internet 200 via the router device 200r, and transmits and receives data to and from each server device and other communication devices on the Internet 200. It also acquires the MMT data sequence (or a part of it) and MPEG2-TS data sequence (or a part of it) of a program transmitted via a communication line, and outputs them to the MMT decoding processing unit 841 and the MPEG2-TS decoding processing unit 842 as appropriate.

[Time display on broadcast receiving device]
In the broadcast receiving device 800 of this embodiment, the current date and the current time can be displayed on the EPG screen, various setting screens, etc. The information on the current date and the current time is transmitted by MH-TOT or the like in a broadcast service that adopts MMT as a media transport method, and is transmitted by TOT (Time Offset Table) or the like provided in SI (Service Information) defined in the MPEG-2 system in a broadcast service that adopts MPEG2-TS as a media transport method. The broadcast receiving device 800 can obtain the information on the current date and the current time by referring to the MH-TOT or the TOT.

In addition, generally, when the video synthesis unit 861 mainly selects the video information etc. output from the MMT decode processing unit 841, the information relating to the current date and current time obtained from the MH-TOT is superimposed on the video information etc., and when the video synthesis unit 861 mainly selects the video information etc. output from the MPEG2-TS decode processing unit 842, the information relating to the current date and current time obtained from the TOT is superimposed on the video information etc.

However, because there are differences in encoding/decoding processes and transmission paths between broadcast services that use MMT as the media transport method and broadcast services that use MPEG2-TS as the media transport method, there is a possibility that inconsistencies may occur, particularly in the current time display, when selecting a broadcast service that uses MMT as the media transport method and when selecting a broadcast service that uses MPEG2-TS as the media transport method. For example, as shown in FIG. 25, when the screen display is switched from EPG screen 162g, which displays channel information for a broadcast service that uses MMT as the media transport method, to EPG screen 162h, which displays channel information for a broadcast service that uses MPEG2-TS as the media transport method, the current time display switches from current time display 162g1 to current time display 162h1, which may cause the user to feel a visual discomfort due to the inconsistency.

In the broadcast receiving device 800 of this embodiment, in order to prevent the user from feeling visually uncomfortable, even when the video synthesis unit 861 is primarily selecting video information, etc. output from the MMT decoding processing unit 841, the information relating to the current date and current time obtained from the TOT is controlled to be superimposed on the video information, etc. In other words, the current time information provided by a broadcast service that employs MPEG2-TS as a media transport method is controlled to be superimposed on the content of the broadcast service that employs MMT as a media transport method.

By performing the above control, the broadcast receiving device 800 of this embodiment always displays the current time information obtained by referencing the TOT when displaying the current time. Therefore, even when switching between a broadcast service that uses MMT as the media transport method and a broadcast service that uses MPEG2-TS as the media transport method, it is possible to prevent the user from feeling visual discomfort due to inconsistencies in the display of the current time.

FIG. 26A shows an example of the selection control of the current time information reference source according to the reception status of each broadcast service in the broadcast receiving device 800 of this embodiment. In the broadcast receiving device 800 of this embodiment, when a broadcast service that uses MPEG2-TS as the media transport method is available for reception, the device always refers to the TOT to acquire current time information, and only when a broadcast service that uses MPEG2-TS as the media transport method is unavailable for reception and a broadcast service that uses MMT as the media transport method is available for reception is the device controlled to refer to the MH-TOT to acquire current time information.

In addition, the same effect as described above can be obtained by controlling the content of a broadcast service that uses MMT as the media transport method to be superimposed on the current time information provided by the broadcast service that uses MPEG2-TS as the media transport method, in the opposite manner to the above control.

As described above, in either case of controlling the content of a broadcast service that employs MMT as the media transport method to be superimposed with current time information provided by a broadcast service that employs MPEG2-TS as the media transport method, or controlling the content of a broadcast service that employs MPEG2-TS as the media transport method to be superimposed with current time information provided by a broadcast service that employs MMT as the media transport method, it is possible to correct the current time information by referring to the "delta" parameter of the time information in the TMCC extension information area, as explained in [Time management of the broadcast receiving device] in Example 1.

In addition, in both cases of broadcast services that use MMT as the media transport method and broadcast services that use MPEG2-TS as the media transport method, there is a possibility that the MH-TOT or TOT transmitted by each broadcast service constituting the network may contain errors due to malfunctions in the transmitting system, transmission errors, etc. In the broadcast receiving device 800 of this embodiment, as a countermeasure against the errors in the MH-TOT or TOT, if it is determined that the MH-TOT or TOT acquired from the service being received contains an error, the device has a function to acquire the MH-TOT or TOT from another broadcast service on the same network or from an arbitrary broadcast service on another network and perform a process of updating the time information of the built-in clock by referring to the current time information.

Figure 26B shows an example of the process of updating current time information when a broadcast service that uses MPEG2-TS as the media transport method is being received in the broadcast receiving device 800 of this embodiment. Note that the same process as shown in the figure can be performed even when a broadcast service that uses MMT as the media transport method is being received.

When updating the time information of the built-in clock in the broadcast receiving device 800 of this embodiment, the receiving function execution unit 1102 first acquires the TOT from the MPEG2-TS data string of the currently being received broadcast service (broadcast service that employs MPEG2-TS as the media transport method) (S301), and then acquires the current time information by referring to the acquired TOT (S302). Next, the receiving function execution unit 1102 performs a process of comparing the current time information acquired in the process of S302 with the time information of the built-in clock.

If the result of the comparison process shows that the difference between the current time information acquired in the process of S302 and the time information of the built-in clock is within a predetermined value (for example, within 3 minutes) (S303: Yes), the reception function execution unit 1102 updates the time information of the built-in clock with the current time information acquired in the process of S302 (S306). On the other hand, if the result of the comparison process shows that the difference between the current time information acquired in the process of S302 and the time information of the built-in clock is not within a predetermined value (S303: No), or if the TOT acquired in S301 has a flag indicating that there is an error in the data, the reception function execution unit 1102 acquires a TOT from an MPEG2-TS data sequence of another broadcast service in the same network, or acquires an MH-TOT from an MMT data sequence of an arbitrary broadcast service (a broadcast service that adopts MMT as a media transport method) of another network (S304), and further acquires current time information from the acquired TOT or MH-TOT (S305). The reception function execution unit 1102 can then perform the comparison process of S303 again using the current time information acquired in the process of S305.

By performing the above process, if the broadcast receiving device 800 of this embodiment determines that the MH-TOT or TOT acquired from the service being received contains an error, it is able to acquire the MH-TOT or TOT from another broadcast service on the same network, or from any broadcast service on another network, and refer to the current time information to update the time information of the built-in clock.

Note that if, during initial settings after shipping from the factory, repeating the processes of S304 to S305 fails to obtain current time information whose difference with the time information of the built-in clock falls within a specified range, the time information of the built-in clock can be set again using the current time information obtained in the process of S302. In this way, it is possible to deal with cases where there is an error in the time information of the built-in clock of the broadcast receiving device 800 of this embodiment.

[EPG display on broadcast receiving device]
Event schedule information of a broadcast service that adopts MMT as a media transport method is transmitted by MH-EIT, etc. On the other hand, event schedule information of a broadcast service that adopts MPEG2-TS as a media transport method is transmitted by EIT (Event Information Table) etc. provided in SI defined in the MPEG-2 system. Therefore, generally, when video information etc. provided by a broadcast service that adopts MMT as a media transport method is displayed, event schedule information (MH-EIT) of the broadcast service that adopts MMT can be acquired, and when video information etc. provided by a broadcast service that adopts MPEG2-TS as a media transport method is displayed, event schedule information (EIT) of the broadcast service that adopts MPEG2-TS can be acquired.

However, the broadcast receiving device 800 of this embodiment is capable of acquiring both the MH-EIT and the EIT even when displaying video information provided by a broadcast service that employs MMT as the media transport method, or when displaying video information provided by a broadcast service that employs MPEG2-TS as the media transport method, thereby improving usability for the user.

Figure 27A shows an example of an EPG screen in the broadcast receiving device 800 of this embodiment. In the figure, EPG screen 162i is an EPG screen created based on the MH-EIT of a broadcast service that uses MMT as the media transport method, and "M1 TV", "M2 Broadcast", "M3 Channel", "M4 TV", "TV M5", etc. are the broadcast station names of the broadcast service that uses MMT as the media transport method. Also, EPG screen 162j is an EPG screen created based on the EIT of a broadcast service that uses MPEG2-TS as the media transport method, and "T6 TV", "T7 Broadcast", "T8 Channel", "T9 TV", "TV TA", etc. are the broadcast station names of the broadcast service that uses MPEG2-TS as the media transport method.

For example, when a user is watching a broadcast program provided by a broadcast service that employs MMT as the media transport method and instructs the display of an EPG screen by operating a remote control (not shown), the initial screen of the EPG screen (not shown) is displayed. The initial screen of the EPG screen is an EPG screen created based on the MH-EIT of the broadcast service that employs MMT as the media transport method, and displays detailed information on the broadcast programs of each channel from 17:00 (nearby the current time) on October 7, 2014 (today). Next, if the user wishes to check detailed information on the broadcast programs of each channel from 20:00 on October 9, 2014, and instructs the update of the EPG screen by operating a remote control (not shown), EPG screen 162i is displayed.

Furthermore, if the user wishes to check detailed information on a broadcast program provided by a broadcast service that employs MPEG2-TS as the media transport method and instructs a network switch by operating a remote control (not shown), an EPG screen 162j is displayed. At this time, the broadcast receiving device 800 of this embodiment controls to display detailed information on the broadcast programs of each channel on the same day and in the same time slot (i.e., from 8:00 p.m. on October 9, 2014) as the EPG screen 162i that was displayed immediately before, rather than the initial screen of the EPG screen (i.e., detailed information on the broadcast programs of each channel from 5:00 p.m. on October 7, 2014) created based on the EIT of the broadcast service that employs MPEG2-TS as the media transport method.

The above-mentioned control enables the user to continuously check detailed information about broadcast programs on the same day and at the same time on multiple networks using different media transport methods with simple operations. In other words, the usability of the broadcast receiving device 800 is improved.

Figure 27B is a diagram showing an example of an EPG screen in the broadcast receiving device 800 of this embodiment that is different from the above. EPG screen 162k shows a state in which EPG screen 162i shown in Figure 27A is displayed and then scrolled in the channel direction (horizontal direction) by operating a remote control (not shown). That is, in the example shown in Figure 27B, by scrolling the EPG screen in the channel direction (horizontal direction), channel information created based on the MH-EIT of a broadcast service that employs MMT as the media transport method and channel information created based on the EIT of a broadcast service that employs MPEG2-TS as the media transport method are seamlessly displayed on the same time axis.

Therefore, even if the user desires to check channel information created based on the EIT of a broadcast service that adopts MPEG2-TS as a media transport method while checking channel information created based on the MH-EIT of a broadcast service that adopts MMT as a media transport method, it is possible to eliminate the need to instruct switching of networks by operating a remote control (not shown). Furthermore, the user can simultaneously check detailed information related to broadcast programs on the same day and at the same time on multiple networks that use different media transport methods. In other words, the usability of the broadcast receiving device 800 is improved.
Example 3

The following describes Example 3 of the present invention. Note that the configuration and effects of this example are the same as those of Example 1 unless otherwise specified. For this reason, the following mainly describes the differences between this example and Example 1, and explanations of common points are omitted as much as possible to avoid duplication.

The broadcast receiving device 100 of this embodiment is capable of supporting HDR (High Dynamic Range), a technology that expands the luminance range of colors in video content, and expanding the color gamut. In addition, in MMT, a media transport method supported by the broadcast receiving device 100 of this embodiment, content information related to the HDR and color gamut expansion can be transmitted together with the encoded data of the program content in order to enable the video to be reproduced as intended by the content producer on the monitor device used by the user (such as the broadcast receiving device 100 of this embodiment).

[System configuration]
The system configuration in this embodiment is basically the same as the system configuration shown in Fig. 1. The coded data of the program content included in the broadcast wave sent from the radio tower 300t may be the content data output from the photographing device 390c that is appropriately coded and modulated without being temporarily stored in the broadcasting station server 300, as shown in Fig. 28. Alternatively, the content data output from the photographing device 390c may be stored in the broadcasting station server 300, and the stored content data may be edited in various video/audio ways by the editing device 390e, and further coded and modulated before being sent.

In addition to the coded data and text information of the program content, other applications, general-purpose data, etc., the broadcast waves also include content information descriptors that describe information on the luminance of the program content and the color reproduction performance of the equipment (camera equipment 390c, monitor device of editing equipment 390e, etc.) used in creating/editing the program content, and these are transmitted as control information (content information) related to the program content together with the messages/tables/descriptors of the MMT-SI described above.

[Data structure of content information descriptor]
An example of the data structure of the content information descriptor is shown in Fig. 29A. The content information descriptor may be placed in the MPT or MH-EIT. Each parameter in the data structure of the content information descriptor has the function described below.

・'descriptor_tag'
The descriptor tag is a 16-bit field that has the function of uniquely identifying each descriptor.

"descriptor_length (descriptor length)"
The descriptor length indicates the total number of data bytes of each parameter that follows this field.

・『component_tag』
The component tag is a label for uniquely identifying a component stream and is described in a 16-bit field. The value shall be the same as the component tag described in the MH-stream identification descriptor.

・『content_type』
The content type indicates the type of video content included in the component stream according to FIG. 29B. When this parameter is "0", it indicates that the video content is video edited and processed by the editing device 390e (recorded program, etc.). When this parameter is "1", it indicates that the video content is video edited and processed by the editing device 390e (recorded program, etc.) and that this content is HDR compatible. When this parameter is "2", it indicates that the video content is content data output from the image capture device 390c (live broadcast program, etc.). When this parameter is "3", it indicates that the video content is content data output from the image capture device 390c (live broadcast program, etc.) and that this content is HDR compatible. Furthermore, other classifications may be made using this parameter.

・“source_primaries_rx (source device primary color chromaticity coordinates (Rx))”
“source_primaries_ry (source device primary color chromaticity coordinates (Ry))”
“source_primaries_gx (source device primary color chromaticity coordinates (Gx))”
“source_primaries_gy (source device primary color chromaticity coordinates (Gy))”
“source_primaries_bx (source device primary color chromaticity coordinates (Bx))”
“source_primaries_by (source device primary color chromaticity coordinates (By))”

The source device primary chromaticity coordinates are parameters that indicate information about the color reproduction performance of the source device, and indicate the color gamut that the source device can handle by the coordinate values of each of the primary colors R (red)/G (green)/B (blue) on the CIE chromaticity diagram (CIExy chromaticity diagram). Note that the source device is the monitor device of the editing device 390e when the "content_type" parameter is "0" or "1". In this case, the source device primary chromaticity coordinates indicate the chromaticity coordinate values of the color gamut that can be displayed on the monitor device of the editing device 390e. Also, when the "content_type" parameter is "2" or "3", the source device is the imaging device 390c. In this case, the source device primary chromaticity coordinates indicate the chromaticity coordinate values of the color gamut that can be output by the imaging device 390c.

Each coordinate value on the CIE chromaticity diagram is represented by a value in the range of "0.000" to "1.000", and is described in a 10-bit field in the range of "0000000000b" to "1111101000b". For example, as shown in FIG. 29C, the chromaticity coordinate values of R (red) in the BT.709 standard are "x = 0.640 (1010000000b)" and "y = 0.330 (0101001010b)", and the chromaticity coordinate values of G (green) in the BT.2020 standard are "x = 0.170 (0010101010b)" and "y = 0.797 (1100011101b)".

・"source_white_point_x (source device white chromaticity coordinate (x))"
“source_white_point_y (source device white chromaticity coordinate (y))”
The source device white chromaticity coordinates are parameters indicating information on the color reproduction performance of the source device, and indicate the coordinate values on the CIE chromaticity diagram of the white reference point that the source device can support. The source device is the monitor device of the editing device 390e when the "content_type" parameter is "0" or "1." In this case, the source device white chromaticity coordinates are the white chromaticity coordinates of the monitor device of the editing device 390e. In addition, when the "content_type" parameter is "2" or "3", the source device is the image capture device 390c. In this case, the source device white chromaticity The coordinates indicate the chromaticity coordinate values of the white reference point that can be output by the photographing device 390c.

Each coordinate value on the CIE chromaticity diagram is represented by a value in the range of "0.0000" to "1.0000", and is described in a 14-bit field in the range of "000000000000000b" to "10011100010000b". For example, as shown in Figure 29C, the chromaticity coordinate values of the white reference point in the BT.709 standard and BT.2020 standard are "x = 0.3127 (00110000110111b)" and "y = 0.3290 (00110011011010b)".

・『source_luminance_max (maximum brightness of source device)』
"source_luminance_min (source device minimum luminance)"
The source device maximum luminance and the source device minimum luminance are parameters indicating information on the maximum luminance and the minimum luminance that the source device can handle. When the "content_type" parameter is "0" or "1", the source device is the monitor device of the editing device 390e. In this case, the source device maximum luminance and the source device minimum luminance indicate the maximum and minimum values of luminance that can be displayed on the monitor device of the editing device 390e. When the "content_type" parameter is "2" or "3", the source device is the imaging device 390c. In this case, the source device maximum luminance and the source device minimum luminance indicate the maximum and minimum values of luminance that the imaging device 390c can output.

The source device maximum luminance shall be expressed as a value in the range of "1 (cd/ ^m2 : candela/square meter)" to "65535 (cd/ ^m2 )" and described in a 16-bit field in the range of "0000h" to "FFFFh". The source device minimum luminance shall be expressed as a value in the range of "0.0001 (cd/ ^m2 )" to "6.5535 (cd/ ^m2 )" and described in a 16-bit field in the range of "0000h" to "FFFFh".

・'num_of_scene (number of scenes)'
The number of scenes indicates the number of scenes (which may be called chapters, etc.) that constitute the video content included in the component stream. If the number of scenes is "1", this parameter may be omitted.

・"scene_start_time (scene start time)"
The scene start time is a 40-bit field that indicates the start time of a scene (chapter). The upper 16 bits of this field indicate the lower 16 bits of the Modified Julian Date (MJD), and the lower 24 bits indicate Japan Standard Time ( JST) hours, minutes, and seconds are expressed as a six-digit BCD code. If the number of scenes is "1", this parameter may be omitted.

・『scene_duration』
The scene duration is a 24-bit field that indicates the duration of a scene (chapter). This field indicates the duration in hours, minutes, and seconds using a six-digit BCD code. If the number of scenes is "1", this parameter may be omitted.

・"max_light_level_of_content (maximum content brightness)"
The content maximum luminance is expressed as a 16-bit field that indicates the maximum luminance in each scene (chapter). If the number of scenes is "1", this parameter indicates the maximum luminance throughout the entire content. The content maximum luminance is expressed as a value in the range of "1 (cd/ ^m2 )" to "65535 (cd/ ^m2 )", and is described in the range of "0000h" to "FFFFh" in a 16-bit field.

・"max_frame_ave_light_level (maximum frame average brightness)"
The maximum average frame luminance is expressed as a 16-bit field that indicates the maximum value of the average frame luminance in each scene (chapter). If the number of scenes is "1", this parameter indicates the maximum value of the average frame luminance throughout the entire content. The maximum average frame luminance is expressed as a value in the range of "1 (cd/ ^m2 )" to "65535 (cd/ ^m2 )", and is described in the range of "0000h" to "FFFFh" in a 16-bit field.

・"max_light_level_of_frame (maximum brightness within frame)"
The maximum luminance within a frame is expressed as a 16-bit field that indicates the maximum luminance within each frame. The maximum luminance within a frame is expressed as a value in the range of "1 (cd/ ^m2 )" to "65535 (cd/ ^m2 )" and is described in the range of "0000h" to "FFFFh" in the 16-bit field.

・『frame_average_light_level (average brightness within frame)』
The average brightness within a frame is expressed as the average brightness of each frame in a 16-bit field. The average brightness within a frame is expressed as a value in the range of "1 (cd/ ^m2 )" to "65535 (cd/ ^m2 )" and is described in the range of "0000h" to "FFFFh" in a 16-bit field.

・“EOTF_identification”
The EOTF (Electro-Optical Transfer Function) identification identifies the type of conversion characteristic (transfer characteristic) between an electric signal and an optical signal, such as gamma correction, applied to the video signal of the video content included in the component stream. For example, in the example shown in Fig. 29D, when this parameter is "0", it indicates that the video content has undergone gamma correction suitable for a monitor device with display characteristics conforming to BT.709. When the parameter is "2", it indicates that the video content has undergone 10-bit gamma correction suitable for monitor devices with display characteristics conforming to BT.2020. When the parameter is "3", This indicates that the video content has been subjected to 12-bit gamma correction suitable for monitor devices with display characteristics conforming to BT.2020. Also, when this parameter is "4", the video content is suitable for monitor devices conforming to SMPTE2084. This indicates that gamma correction appropriate to the particular monitor device has been applied. Additionally, other classifications may be made using this parameter. The "EOTF identification" parameter may be capable of identifying the type of colorimetry, etc. Note that the types of conversion characteristics (transfer characteristics) between electrical signals and optical signals shown in FIG. 29D are merely examples, and the types of conversion characteristics (transfer characteristics) between electrical signals and optical signals may be identified by the "EOTF identification" parameter. The video signal may be subjected to other electrical and optical signal conversion characteristic (transfer characteristic) processing, and the characteristic may be identified by the "EOTF identification" parameter.

Here, the broadcast receiving device 100 that has received the video content and the "EOTF identification" parameter refers to the "EOTF identification" parameter associated with the video content, and further refers to the display characteristics of the monitor device that displays the video content, and performs appropriate electrical-optical conversion and other processing based on these, thereby making it possible to display each of the video contents in a state suitable for the monitor device. For example, if the transfer characteristics identified by the "EOTF identification" parameter associated with the video content correspond to the display characteristics of the monitor device that displays the video content, then the electrical-optical conversion identified by the "EOTF identification" parameter can be performed as is in the display processing. Furthermore, if the transfer characteristics identified by the "EOTF identification" parameter associated with the video content do not correspond to the display characteristics of the monitor device that displays the video content, instead of performing the electrical-optical conversion identified by the "EOTF identification" parameter as is, a conversion process is performed to convert the video signal that has been subjected to conversion processing between an electrical signal and an optical signal according to the identification of the "EOTF identification" parameter into a video signal suitable for electrical-optical conversion processing that corresponds to the display characteristics of the monitor device, and then a display process is performed to perform electrical-optical conversion that corresponds to the display characteristics of the monitor device.

The following describes the conversion process for converting the video signal that has been subjected to the above-mentioned electrical/optical conversion process according to the identification of the "EOTF identification" parameter into a video signal suitable for electrical-optical conversion processing corresponding to the display characteristics of the monitor device. Note that, hereinafter, the above-mentioned process is referred to as transfer characteristic conversion processing.

Video content with an "EOTF identification" parameter value of "2," "3," or "4" is HDR video content with a wide range of expressible brightness and color gamut. In contrast, video content with an "EOTF identification" parameter value of "0" is SDR (Standard Dynamic Range) video content with a narrower range of expressible brightness and color gamut than HDR video content.

In addition, a display device with display characteristics conforming to BT.2020 or SMPTE2084 can be called an HDR-compatible display device. In contrast, a display device with display characteristics conforming to BT.709 can be called an SDR-compatible display device. Furthermore, a display device with display characteristics conforming to BT.709 that does not support HDR display characteristics such as BT.2020 or SMPTE2084 may be called an SDR-compatible display device (non-HDR compatible display device) as a subordinate concept of an SDR-compatible display device.

Here, if the transfer characteristic conversion process is not performed when the HDR video content is displayed on an SDR-compatible display device (non-HDR-compatible display device) such as a monitor device with display characteristics conforming to BT.709, the monitor device cannot fully express the wide range of brightness and color gamut of the HDR video content, resulting in a display image that is difficult to see due to brightness collapse and color collapse. That is, in this case, the transfer characteristic conversion process can be performed to convert the wide range of brightness and color gamut of the HDR video content so that it fits within the range of brightness and color gamut that can be expressed by the monitor device. This process may be expressed as a dynamic range reduction conversion of brightness and color gamut reduction conversion. In addition, since this is a process of converting HDR video content with a wide range of brightness and color gamut that can be expressed into SDR video content with a narrow range of brightness and color gamut that can be expressed, it may be expressed as an HDR-SDR conversion process.

On the other hand, video content having a value of "0" in the "EOTF identification" parameter is SDR video content with a narrow range of expressible brightness and color gamut. If the transfer characteristic conversion process is not performed when the SDR video content is displayed on an HDR-compatible display device such as a monitor device with display characteristics conforming to BT. 2020, the wide brightness display performance and color gamut display performance of the monitor device cannot be fully utilized. That is, in this case, in the transfer characteristic conversion process, a conversion process may be performed on the SDR video content so that the wide brightness display performance and color gamut display performance of the monitor device can be fully utilized. This process may be expressed as a brightness dynamic range expansion conversion or a color gamut expansion conversion. In addition, since this is a process of converting SDR video content with a narrow range of expressible brightness and color gamut into HDR video content with a wide range of expressible brightness and color gamut, it may be expressed as an SDR-HDR conversion process. Note that the SDR-HDR conversion process is not necessarily required, and it is not necessary to perform the SDR-HDR conversion process when displaying the SDR video content on an HDR-compatible display device such as a monitor device with display characteristics conforming to BT.2020. In this case, the brightness and color gamut display performance remains within the range of SDR display characteristics, but the displayed image does not have brightness collapse or color collapse, making it difficult to see, and there is no problem.

As an example of processing to be performed when the "EOTF identification" parameter is not associated with the video content received by the broadcast receiving device 100 and cannot be acquired (if it was not originally transmitted), or when the value of the "EOTF identification" parameter associated with the video content received by the broadcast receiving device 100 cannot be acquired and determined due to a transmission error or the like, the following processing may be performed.

As a first processing example, the value of the "EOTF identification" parameter of the received video content may be treated as, for example, "2" or "3". In other words, if the value of the "EOTF identification" parameter cannot be identified, the video content may be treated as HDR video content. In this way, the transfer characteristic conversion process is not performed on an HDR-compatible display device such as a monitor device with display characteristics compliant with BT.2020, but if the actual content is HDR video content, appropriate display is performed, and even if the actual content is SDR video content, the brightness display performance and color gamut display performance remain within the range of SDR display characteristics, but the displayed image is not difficult to see due to brightness crushing or color crushing. In addition, if the monitor device is BT. In the case of an SDR-compatible display device (non-HDR compatible display device) such as a monitor device with display characteristics conforming to G.709, the transfer characteristic conversion process is performed by treating the video content as HDR video content, but if the actual content is HDR video content, the HDR-SDR conversion process is appropriately performed and displayed, and even if the actual content is SDR video content, the brightness display performance and color gamut display performance are further limited than the range of SDR display characteristics, but at least it is possible to avoid a display image that is difficult to see with brightness crushing and color crushing that cannot fully express the brightness range and color gamut of the video content. (If the actual content is HDR video content and SDR-HDR conversion process is performed, or if the actual content is HDR video content and the content is displayed as is without HDR-SDR conversion on an SDR-compatible display device (non-HDR compatible display device), there is a possibility that such a display image that is difficult to see with brightness crushing and color crushing will be displayed, but this situation can be avoided in the first processing example.)

According to the first processing example described above, if the value of the "EOTF identification" parameter cannot be identified, the video content is treated as HDR video content, enabling video display with fewer problems for the user, regardless of whether the monitor device is an HDR-compatible display device or an SDR-compatible display device (HDR non-compatible display device), whether the actual content is HDR video content or SDR video content.

As a second example of processing when the value of the "EOTF identification" parameter cannot be obtained (including cases where it has not been transmitted, there is a transmission error, or the value is invalid), a parameter related to the resolution of the video signal contained in the video component descriptor, etc. may be referenced to determine whether to treat the content as HDR video content or SDR video content.

For example, even if the value of the "EOTF identification" parameter cannot be identified, if the parameter related to the resolution of the video signal indicates that the video content is high-resolution content with a resolution of 3840 x 2160 pixels or 7680 x 4320 pixels, it may be determined that the video content is HDR video content. Specifically, the value of the "EOTF identification" parameter can be interpreted as "2" or "3." High-resolution content of 3840 x 2160 pixels or 7680 x 4320 pixels is expected to be prepared and used as HDR video content in the future, so this type of processing makes it easier to display the content in a probabilistically appropriate manner.

Even if the value of the "EOTF identification" parameter cannot be identified, if the parameter relating to the resolution of the video signal indicates that the resolution of the video content is 1920 x 1080 pixels or less, it may be determined that the video content is SDR video content. Specifically, the value of the "EOTF identification" parameter can be interpreted as "0." Since there is a large amount of existing SDR content with a resolution of 1920 x 1080 pixels or less, this type of processing makes it more likely that the video content will be displayed appropriately in a probabilistic manner.

According to the second processing example described above, when the value of the "EOTF identification" parameter cannot be identified, the parameter related to the resolution is referenced for judgment, making it more likely that an appropriate display will be performed probabilistically.

Next, a process will be described for the case where the value of the "EOTF identification" parameter associated with the video content received by the broadcast receiving device 100 is a value for which no relationship with the display characteristics is provided in the table of FIG. 29D. Here, a value for which no relationship with the display characteristics is provided in the table of FIG. 29D is a case where the value of the "EOTF identification" parameter in the table of FIG. 29D is a value reserved for the future, such as "1" or "5" to "15", or an unexpected value, etc. These values may be expressed as invalid values. In the case of such invalid values (values for which no relationship with the display characteristics is provided), similar effects can be obtained by performing either the first or second processing example described above.

In the configuration diagram of Figure 7A, the various types of image processing according to the "EOTF identification" parameters described above can be performed by the image color gamut conversion unit 142 controlled by the main control unit 101 based on the data separated by the separation unit 132.

When the video content to be displayed switches between HDR video content and SDR video content due to a change in program or channel, ideally the timing at which the decoded video from the video decoder 141 in FIG. 7A switches between HDR video content and SDR video content should coincide with the timing at which the video processing of the video gamut conversion unit 142 switches between processing for HDR video content and processing for SDR video content. However, in reality, it is thought that there will be some degree of timing discrepancy.

In an HDR-compatible display device that performs SDR-HDR conversion processing on SDR video content, if the timing at which the video color gamut conversion unit 142 switches video processing is earlier than the timing at which the decoded video from the video decoder 141 switches when switching from HDR video content to SDR video content, there will be a time when the SDR-HDR conversion processing is performed on the HDR video content, and it is possible that a display image that is difficult to see due to luminance crushing or color crushing will be displayed. Therefore, when switching from HDR video content to SDR video content, the main control unit 101 can control the processing timing of the video decoder 141 and the video color gamut conversion unit 142 so that the timing at which the video color gamut conversion unit 142 switches video processing is later than the timing at which the decoded video from the video decoder 141 switches. Alternatively, the video may be muted (e.g., blacked out) before the switching between the two starts, and the video may be muted (e.g., blacked out) after the switching between the two is complete.

Furthermore, in an HDR-compatible display device that performs SDR-HDR conversion processing on SDR video content, if the timing at which the video processing of the video gamut conversion unit 142 switches is slower than the timing at which the decoded video from the video decoder 141 switches when switching from SDR video content to HDR video content, there will be a time when the SDR-HDR conversion processing is performed on the HDR video content, and it is possible that a display image that is difficult to see due to luminance crushing or color crushing will be displayed. Therefore, when switching from SDR video content to HDR video content, the main control unit 101 can control the processing timing of the video decoder 141 and the video gamut conversion unit 142 so that the timing at which the video processing of the video gamut conversion unit 142 switches is faster than the timing at which the decoded video from the video decoder 141 switches. Alternatively, the video may be muted (e.g., blacked out) before the switching between the two starts, and the video may be muted (e.g., blacked out) after the switching between the two is complete.

In an SDR-compatible display device that performs HDR-SDR conversion processing on HDR video content and displays SDR video content without performing transfer characteristic conversion processing, if the timing at which the video color gamut conversion unit 142 switches video processing is earlier than the timing at which the decoded video from the video decoder 141 switches when switching from HDR video content to SDR video content, there will be a period of time when the HDR video content is displayed on the SDR-compatible display device as is without performing transfer characteristic conversion processing, and there is a possibility that a display image that is difficult to see due to luminance crushing or color crushing will be displayed. Therefore, when switching from HDR video content to SDR video content, the main control unit 101 simply controls the processing timing of the video decoder 141 and the video color gamut conversion unit 142 so that the timing at which the video color gamut conversion unit 142 switches video processing is later than the timing at which the decoded video from the video decoder 141 switches. Alternatively, the video may be muted (e.g., blacked out) before the switching between the two starts, and the video may be muted (e.g., blacked out) after the switching between the two is complete.

In an SDR-compatible display device that performs HDR-SDR conversion processing on HDR video content and displays SDR video content without performing transfer characteristic conversion processing, if the timing at which the video gamut conversion unit 142 switches video processing is slower than the timing at which the decoded video from the video decoder 141 switches when switching from SDR video content to HDR video content, there will be a period of time when the HDR video content is displayed on the SDR-compatible display device as is without performing transfer characteristic conversion processing, and there is a possibility that a display image that is difficult to see due to luminance crushing or color crushing will be displayed. Therefore, when switching from SDR video content to HDR video content, the main control unit 101 simply controls the processing timing of the video decoder 141 and the video gamut conversion unit 142 so that the timing at which the video gamut conversion unit 142 switches video processing is faster than the timing at which the decoded video from the video decoder 141 switches. Alternatively, the video may be muted (e.g., blacked out) before the switching between the two starts, and the video may be muted (e.g., blacked out) after the switching between the two is complete.

As described above, by performing processing related to the timing of switching the decoded image and the timing of switching the transfer characteristic conversion process, it is possible to avoid presenting the user with a display image that is difficult to see due to brightness or color loss.

Instead of or in addition to the above-described identification process and various video processes using the "EOTF_identification" parameter in the content information descriptor, a flag that enables the same identification as the above-described "EOTF_identification" parameter may be inserted into the encoded video stream, and the identification process and various video processes may be performed using the inserted flag. The identification process and various video processes when the "EOTF_identification" flag is used as a flag in the encoded video stream can be performed by referring to the "EOTF_identification" flag inserted in the encoded video stream instead of referring to the "EOTF_identification" parameter in the content information descriptor in the description of the above-described identification process and various video processes when the "EOTF_identification" parameter in the content information descriptor is used, and therefore a detailed description will be omitted.

However, if the "EOTF_identification" flag is inserted into the encoded video stream as a flag in the encoded video stream, for example, on a frame-by-frame or GOP-by-frame basis, it becomes possible to switch between HDR video content and SDR video content and switch between various video processes corresponding to each video content in finer time units than when the "EOTF_identification" parameter in the content information descriptor set on an asset-by-asset or program-by-program basis is used. That is, the video decoder 141 can grasp the switching between HDR video content and SDR video content on a frame-by-frame or GOP-by-frame basis, and further, the downstream video gamut conversion unit 142 can refer to the identification information of the HDR video content and the SDR video content on a frame-by-frame or GOP-by-frame basis, so that the synchronization accuracy of the switching timing of the video process in the video gamut conversion unit 142 is improved compared to when the "EOTF_identification" parameter in the content information descriptor is used.

In addition, when using both the transmission of the "EOTF_identification" flag in the encoded video stream and the transmission of the "EOTF_identification" parameter in the content information descriptor, the identification process using the "EOTF_identification" flag in the encoded video stream is used to switch the video processing of the video gamut conversion unit 142, and the "EOTF_identification" parameter in the content information descriptor is used for display purposes, for example, to inform the user on a program-by-program basis whether the program is an HDR video content program or an SDR video content program when displaying the program information or in a program guide, thereby making it possible to more appropriately use the two types of identification information.

When using both the transmission of the 'EOTF_identification' flag in the encoded video stream and the transmission of the 'EOTF_identification' parameter in the content information descriptor, the following processing can be considered when there is a mismatch between the two pieces of identification information. The first processing example is an example in which the 'EOTF_identification' flag in the encoded video stream is used preferentially. In this case, there is an advantage that the switching between HDR video content and SDR video content as described above can be precisely synchronized with the switching timing of the corresponding video processing. The second processing example is an example in which the 'EOTF_identification' parameter in the content information descriptor is used preferentially. In this case, there is an advantage that the transfer characteristics, etc. can be quickly identified without referring to the encoded video stream.

The content information descriptor may have a data structure different from that shown in FIG. 29A. For example, it may further include a parameter different from each of the parameters, or it may not include all of the parameters. Also, each of the parameters may use a different name. Also, each of the parameters does not necessarily have to be described in one descriptor, and may be described, for example, in two different descriptors. Also, each of the parameters may be described in a descriptor and placed in a table, or may be described directly in the table.

[EPG display on broadcast receiving device]
In the broadcast receiving device 100 of this embodiment, as in embodiment 1, by referring to the MH-EIT, etc. and identifying the service ID, it is possible to obtain information such as the start time and broadcast duration of each event (broadcast program) and create an EPG screen, and the created EPG can be superimposed on video information, etc. by the video synthesis unit 161 and displayed on the monitor unit 162.

Furthermore, in the broadcast receiving device 100 of this embodiment, by referring to the "content_type" parameter of the content information descriptor, if the type of the video content of each broadcast program is "1" or "3", a symbol or the like representing an attribute indicating that the broadcast program is a program compatible with HDR may be displayed as shown in FIG. 30. The symbol or the like representing the attribute may be, for example, a symbol/character indicating that the broadcast program is compatible with HDR, or may be a mark 162a5 that symbolizes "HDR", meaning that the broadcast program is compatible with HDR. The symbol or the like representing the attribute may be displayed in the title area 162a2 of the detailed information 162a1. Alternatively, it may be displayed in a pop-up when the cursor is placed on the detailed information 162a1. It may also be displayed in other ways.

In addition, if the content information descriptor has a separate parameter such as "HDR_flag" that indicates whether the video content of the broadcast program is compatible with HDR, the "HDR_flag" parameter may be referenced to control whether or not to display a symbol or the like that represents an attribute that indicates that the broadcast program is a program that is compatible with HDR. Note that the name of the "HDR_flag" parameter is an example, and a different name may be used.

In addition, when all or any of the parameters such as the "source_luminance_max", "max_light_level_of_content", and "max_light_level_of_frame" of the content information descriptor exceed a predetermined value (e.g., "100 (cd/ ^m2 )"), control may be performed to display a symbol or the like representing an attribute indicating that the broadcast program is an HDR-compatible program.

In addition, even if the type of video content of each broadcast program is "1" or "3" by referring to the "content_type" parameter of the content information descriptor, or even if all or any of the "source_luminance_max" parameter, the "max_light_level_of_content" parameter, the "max_light_level_of_frame" parameter, etc. of the content information descriptor exceed a predetermined value (for example, "100 (cd/ ^m2 )"), if the monitor unit 162 of the broadcast receiving device 100 is not HDR-compatible, control may be performed so as not to display the symbol/letters indicating that the program is HDR-compatible or the mark 162a5 that symbolizes "HDR" meaning that the program is HDR-compatible.

In addition, the broadcast receiving device 100 of this embodiment may refer to the "EOTF_identification" parameter of the content information descriptor, and when the type of gamma correction applied to the video content of each broadcast program is compatible with the display characteristics of the monitor unit 162 of the broadcast receiving device 100, a symbol or the like representing an attribute indicating that the broadcast program is a program that can be displayed with correct luminance expression may be displayed. The symbol or the like representing the attribute may be, for example, a symbol/character indicating that the program is a program that can be displayed with correct luminance expression, or may be a mark 162a6 that symbolizes "True Contrast", which means that the program is a program that can be displayed with correct luminance expression. Note that, as mentioned above, the type of gamma correction applied to the video content of each broadcast program is a type that can be handled by the display characteristics of the monitor unit 162 of the broadcast receiving device 100 when, for example, the "EOTF_identification" parameter for the video content is "0" and the display characteristics of the monitor unit 162 of the broadcast receiving device 100 conform to BT.709.

By displaying symbols or the like representing attributes such as those described above in the detailed information 162a1 of the EPG screen 162a, the user can easily understand whether each broadcast program displayed on the EPG screen 162a is compatible with HDR, whether the program can be displayed with the correct brightness expression, and so on.

[Color gamut conversion process of broadcast receiving device]
In this embodiment, it is assumed that the video content, which is a recorded program, has been subjected to video/audio editing processing by the editing device 390e as shown in FIG. 28. That is, the provider of the video content edits and processes the video content while checking it on the monitor device of the editing device 390e, and therefore, it is highly likely that the video content is displayed appropriately under the color reproduction performance of the monitor device of the editing device 390e. Meanwhile, the monitor unit 162 of the broadcast receiving device 100, which is the monitor device used by the user to watch the video content, also generally has different color reproduction performance depending on the manufacturer and model. In this case, if the color reproduction performance of the monitor device of the editing device 390e is significantly different from the color reproduction performance of the monitor unit 162 of the broadcast receiving device 100, there is a possibility that a problem will occur in which the video content provider's intended image expression cannot be correctly performed when the video content is displayed on the monitor unit 162 of the broadcast receiving device 100.

That is, in the broadcasting system of this embodiment, as described above, a content information descriptor is transmitted as an MMT-SI descriptor. This content information descriptor indicates, as parameters indicating information about the color reproduction performance of the source device, the coordinate values on the CIE chromaticity diagram of each of the R/G/B primary colors and the white reference point of the color gamut that the source device can handle.

In addition, the broadcast receiving device 100 of this embodiment stores, in various information storage areas of the storage unit 110, coordinate values on the CIE chromaticity diagram of each of the R/G/B primary colors and the white reference point of the color gamut that the monitor unit 162 can handle as parameters indicating information regarding the color reproduction performance of the monitor unit 162. In the above situation, if the coordinates of the R/G/B primary colors and the white reference point of the color gamut that the source device can handle, described in the content information descriptor, are R0/G0/B0 and W0, respectively, as shown in FIG. 31A, and the coordinates of the R/G/B primary colors and the white reference point of the color gamut that the monitor unit 162 can handle, stored in the various information storage areas of the storage unit 110, are R1/G1/B1 and W1, respectively, then the part of the area made up of R0/G0/B0, which is the color gamut that the source device can handle, that does not overlap with the area made up of R1/G1/B1, which is the color gamut that the monitor unit 162 can handle, is an area that may not be displayed correctly on the monitor unit 162.

In order to solve the above-mentioned problem, the broadcast receiving device 100 of this embodiment is equipped with a color gamut conversion processing function that converts the video data of the video content into video data suitable for display on the monitor unit 162 when there is a discrepancy between the color gamut that the source device can handle, as described in the content information descriptor, and the color gamut that the monitor unit 162 can handle, as stored in the various information storage areas of the storage unit 110. The color gamut conversion function equipped in the broadcast receiving device 100 is described below.

The color gamut conversion processing function of the broadcast receiving device 100 of this embodiment is a function that converts the color gamut of the video data (equivalent to the area formed by R0/G0/B0, which is the color gamut that the source device can handle, as shown in FIG. 31A) so that it can be compatible with the color gamut based on the color reproduction performance of the monitor unit 162 (the area formed by R1/G1/B1, as shown in FIG. 31A).

The color gamut conversion processing function provided in the broadcast receiving device 100 of this embodiment may convert the color gamut of the video data so that correct color reproduction is possible on the monitor unit 162 by referring to the coordinate values of each of the R/G/B primary colors of the color gamut that the source device can handle, which is described in the content information descriptor, and the coordinate values of each of the R/G/B primary colors of the color gamut that the monitor unit 162 can handle, which are stored in various information storage areas of the storage unit 110.

On the line segment R0/G0 (or its neighboring area), the color gamut conversion process may be performed by referring only to the coordinate values of the R/G primary colors of the color gamut that the source device can handle and the coordinate values of the R/G primary colors of the color gamut that the monitor unit 162 can handle. On the line segment G0/B0 (or its neighboring area), the color gamut conversion process may be performed by referring only to the coordinate values of the G/B primary colors of the color gamut that the source device can handle and the coordinate values of the G/B primary colors of the color gamut that the monitor unit 162 can handle. On the line segment R0/B0 (or its neighboring area), the color gamut conversion process may be performed by referring only to the coordinate values of the R/B primary colors of the color gamut that the source device can handle and the coordinate values of the R/B primary colors of the color gamut that the monitor unit 162 can handle.

Alternatively, as shown in FIG. 31B, the color gamut of the video data may be divided into three regions, and the color gamut conversion process may be different for each divided region. For example, in the region of the color gamut of the video data consisting of R0/G0/W0, the color gamut conversion process is performed by referring to the coordinate values of each R/G primary color and white reference point of the color gamut that the source device can handle and the coordinate values of each R/G primary color and white reference point of the color gamut that the monitor unit 162 can handle. In the region of the color gamut of the video data consisting of G0/B0/W0, the color gamut conversion process is performed by referring to the coordinate values of each G/B primary color and white reference point of the color gamut that the source device can handle and the coordinate values of each G/B primary color and white reference point of the color gamut that the monitor unit 162 can handle. In the area of the color gamut of the video data that is composed of R0/B0/W0, color gamut conversion processing is performed by referencing the coordinate values of each R/B primary color and white reference point of the color gamut that the source device can support and the coordinate values of each R/B primary color and white reference point of the color gamut that the monitor unit 162 can support.

When the color gamut conversion process is different for each divided area, the color gamut conversion process may be performed on the line segment R0/W0 (or its neighboring area) by referring only to the coordinate values of the R primary color and the white reference point of the color gamut that the source device can handle and the coordinate values of the R primary color and the white reference point of the color gamut that the monitor unit 162 can handle. On the line segment G0/W0 (or its neighboring area), the color gamut conversion process may be performed by referring only to the coordinate values of the G primary color and the white reference point of the color gamut that the source device can handle and the coordinate values of the G primary color and the white reference point of the color gamut that the monitor unit 162 can handle. On the line segment B0/W0 (or its neighboring area), the color gamut conversion process may be performed by referring only to the coordinate values of the B primary color and the white reference point of the color gamut that the source device can handle and the coordinate values of the B primary color and the white reference point of the color gamut that the monitor unit 162 can handle.

An example of the color gamut conversion process will be described with reference to FIG. 31C. In the figure, R0, G0, and B0 are the coordinates of the R/G/B primary colors of the color gamut that the source device can handle described in the content information descriptor, and have the coordinate values of (R0x, R0y), (G0x, G0y), and (B0x, B0y), respectively. R1, G1, and B1 are the coordinates of the R/G/B primary colors of the color gamut that the monitor unit 162 can handle stored in the various information storage area of the storage unit 110, and have the coordinate values of (R1x, R1y), (G1x, G1y), and (B1x, B1y), respectively. P0 is a predetermined color gamut data of the video content, and has the coordinate values of (P0x, P0y). In this case, the color gamut data of P0 is converted to color gamut data shown in P1 by the color gamut conversion process. Note that P1 has coordinate values of (P1x, P1y) and is calculated using the formula for the color gamut conversion process, an example of which is shown below.

<Example of calculation formula for color gamut conversion processing>
P1 = αR1 + βG1 + γB1
however,
α={(G0y-B0y)(P0x-B0x)+(B0x-G0x)(P0y-B0y)}/{(G0y-B0y)(R0x-B0x)
+(B0x-G0x)(R0y-B0y)}
β={(B0y-R0y)(P0x-B0x)+(R0x-B0x)(P0y-B0y)}/{(G0y-B0y)(R0x-B0x)
+(B0x-G0x)(R0y-B0y)}
γ=1-α-β

The above formula is an example of a case where the color gamut conversion process of all color gamut data within the color gamut area of the video content is performed by referring to the coordinate values of each of the R/G/B primary colors of the color gamut that the source device can handle, which is described in the content information descriptor, and the coordinate values of each of the R/G/B primary colors of the color gamut that the monitor unit 162 can handle, which are stored in the various information storage area of the storage unit 110. A similar calculation is possible even if the color gamut of the video data is divided into three areas and the color gamut conversion process is different for each divided area. (However, the parameters to be referenced are different.) Also, since the above formula is a well-known formula using a barycentric coordinate system, detailed explanations regarding the derivation of the formula will be omitted. Also, the above formula is merely an example, and the coordinate values of P1 may be calculated using a different formula.

In addition, if all of the color gamut areas of the video content are included within the color gamut area that the monitor device (broadcast receiving device 100, etc.) can handle, the color gamut conversion process does not need to be performed. For example, if the color gamut of the video content is equivalent to the BT.709 color gamut shown in FIG. 29C and the color gamut that the monitor device (broadcast receiving device 100, etc.) can handle is equivalent to the BT.2020 color gamut, all of the BT.709 color gamut areas are included within the BT.2020 color gamut area, so there is no need to perform the color gamut conversion process. That is, the monitor device (broadcast receiving device 100, etc.) is capable of displaying all of the color gamut data of the video content.

As described above, the color gamut conversion processing function of the broadcast receiving device 100 of this embodiment makes it possible to optimally display the video content on the monitor unit 162 of the broadcast receiving device 100 even if the color reproduction performance of the source device and the color reproduction performance of the monitor unit 162 of the broadcast receiving device 100 are different.

[Brightness adjustment process of broadcast receiving device]
The broadcast receiving device 100 of this embodiment is assumed to have image quality adjustment items as shown in Fig. 32. Each of the image quality adjustment items can be adjusted according to the user's preference by a user's operation. Meanwhile, for an item related to brightness adjustment among the image quality adjustment items, automatic brightness adjustment may be possible by referring to the description in the content information descriptor. The automatic brightness adjustment process will be described below.

The broadcast receiving device 100 of this embodiment is capable of (1) performing automatic brightness adjustment by referring to the "source_luminance_max" and "source_luminance_min" parameters of the content information descriptor, (2) performing automatic brightness adjustment by referring to the "max_light_level_of_content" and "source_luminance_min" parameters, and (3) performing automatic adjustment by referring only to the "max_light_level_of_content" parameter.

In this embodiment, the broadcast receiving device 100 stores the maximum and minimum brightness values that can be displayed on the monitor unit 162 in various information storage areas of the storage unit 110 as parameters indicating information related to the brightness display performance of the monitor unit 162.

The automatic brightness adjustment in the method (1) is performed by referring to the "source_luminance_max" and "source_luminance_min" parameters described in the content information descriptor, and the maximum and minimum brightness values that can be displayed on the monitor unit 162 stored in the various information storage areas of the storage unit 110.

That is, as shown in FIG. 33A, the luminance expression range of the video content is converted so that the luminance level indicated by the "source_luminance_max" parameter roughly matches the maximum luminance level that can be displayed on the monitor unit 162, and the luminance level indicated by the "source_luminance_min" parameter roughly matches the minimum luminance level that can be displayed on the monitor unit 162. By converting the luminance expression range, the user can view, on the monitor unit 162 of the broadcast receiving device 100, video content that has been given the same luminance expression as the monitor device of the editing device 390e that the content provider used to edit and process the content.

The automatic brightness adjustment in the method (2) is performed by referring to the "max_light_level_of_content" parameter and the "source_luminance_min" parameter described in the content information descriptor, and the maximum and minimum brightness values that can be displayed on the monitor unit 162 stored in the various information storage areas of the storage unit 110.

That is, as shown in FIG. 33B, a conversion process is performed on the luminance expression range of the video content so that the luminance level indicated by the "max_light_level_of_content" parameter roughly matches the maximum luminance level that can be displayed on the monitor unit 162, and the luminance level indicated by the "source_luminance_min" parameter roughly matches the minimum luminance level that can be displayed on the monitor unit 162. By performing the conversion process on the luminance expression range, the user can watch the video content by fully utilizing the contrast performance of the monitor unit 162 of the broadcast receiving device 100.

If the content information descriptor further includes a parameter indicating the minimum luminance within each scene (chapter) (e.g., "min_light_level_of_content (minimum content luminance)"), the contrast performance of the monitor unit 162 of the broadcast receiving device 100 can be more effectively utilized by referring to the "min_light_level_of_content" parameter instead of the "source_luminance_min" parameter.

In addition, when the "num_of_scene" parameter is not "1", the conversion process of the luminance expression range in the method (2) above may be performed by changing the parameters to be referenced for each scene (chapter). In this case, it is possible to ensure suitable contrast performance in the monitor unit 162 of the broadcast receiving device 100 for each scene (chapter).

The automatic brightness adjustment in the method (3) is performed by referring to the "max_light_level_of_content" parameter described in the content information descriptor and the maximum brightness value that can be displayed on the monitor unit 162 stored in the various information storage area of the storage unit 110. The minimum brightness value side is based on "0 (cd/ ^m2 )". In this case, it is possible to obtain the same effect as the automatic brightness adjustment in the method (2), and further, it is possible to perform conversion processing of the brightness expression range by simple calculation with reference to a small number of parameters.
In addition, the conversion process of the luminance expression range may be performed only when the ``source_luminance_max'' parameter and the ``max_light_level_of_content'' parameter described in the content information descriptor are greater than the maximum luminance value that can be displayed on the monitor unit 162 stored in the various information storage areas of the storage unit 110.

That is, if the "source_luminance_max" parameter or the "max_light_level_of_content" parameter described in the content information descriptor is greater than the maximum luminance value that can be displayed on the monitor unit 162 stored in the various information storage areas of the storage unit 110, there is a possibility that luminance collapse will occur if the received video content is displayed as is on the monitor unit of the broadcast receiving device 100, but in the opposite case, there is no possibility that the luminance collapse will occur.

As described above, the automatic brightness adjustment process of the broadcast receiving device 100 of this embodiment allows the user to watch video content with an appropriate brightness representation on the monitor unit 162 of the broadcast receiving device 100 by referring to the content information descriptor.

According to this embodiment, by referring to content information accompanying the program content contained in the broadcast wave, it is possible to provide a more useful MMT-compatible broadcast receiving device that is capable of the above-mentioned processes corresponding to HDR and an expanded color gamut.
Example 4

The following describes Example 4 of the present invention. Note that the configuration and effects of this example are the same as those of Example 3 unless otherwise specified. For this reason, the following mainly describes the differences between this example and Example 3, and explanations of common points are omitted as much as possible to avoid duplication.

[System configuration]
FIG. 34 is a system configuration diagram showing an example of a broadcast communication system including the broadcast receiving device of this embodiment. The broadcast communication system of this embodiment is composed of a broadcast receiving device 40100, an antenna 40100a, a connection cable 40200, a monitor device 40300, a broadband network such as the Internet 200, a router device 200r, a radio tower 300t of a broadcast station, a broadcast satellite (or a communication satellite) 300s, a broadcast station server 300, a service provider server 400, and other application servers 500. Although not shown, the system may further include an access point 200a, a mobile telephone communication server 600, a base station 600b of a mobile telephone communication network, and a mobile information terminal 700, in the same connection as in the system configuration diagram of the broadcast communication system of the first embodiment (see FIG. 1). In this case, the mobile information terminal 700 may be capable of communicating directly with the broadcast receiving device 40100 without going through the router device 200r or the like.

Also, as shown in FIG. 28, the encoded data of the program content contained in the broadcast waves transmitted from the radio tower 300t may be output from the filming equipment 390c, or may be data that has been subjected to various video/audio editing processes by the editing equipment 390e.

The broadcast receiving device 40100 receives broadcast waves transmitted from the radio tower 300t via the broadcast satellite (or communication satellite) 300s and the antenna 40100a. Alternatively, the broadcast waves transmitted from the radio tower 300t may be received directly from the antenna 40100a without going through the broadcast satellite (or communication satellite) 300s. The broadcast receiving device 40100 can also be connected to the Internet 200 via the router device 200r, and can transmit and receive data by communicating with each server device and other communication devices on the Internet 200.

The connection cable 40200 is a communication cable that connects the broadcast receiving device 40100 and the monitor device 40300, and transmits the encoded video/audio data, etc. output from the broadcast receiving device 40100. The monitor device 40300 is a video display device that provides the user with video information and audio information obtained by performing a predetermined signal processing on the encoded video/audio data, etc. received via the connection cable 40200, via a display device such as an LCD panel and a speaker.

The monitor device 40300 may also be connectable to the Internet 200 via the router device 200r, and may be capable of transmitting and receiving data by communicating with each server device and other communication devices on the Internet 200. The monitor device 40300 may also be capable of receiving broadcast waves sent from a radio tower 300t via an antenna 40300a (not shown).

[Hardware configuration of broadcast receiving device]
35A is a block diagram showing an example of the internal configuration of a broadcast receiving device 40100. The broadcast receiving device 40100 is composed of a main control unit 101, a system bus 102, a ROM 103, a RAM 104, a storage (accumulation) unit 110, a LAN communication unit 121, an extension interface unit 124, a digital interface unit 40125, a tuner/demodulation unit 131, a separation unit 132, a video decoder 141, a video color gamut conversion unit 142, an audio decoder 143, a text superimposition decoder 144, a subtitle decoder 145, a subtitle synthesis unit 146, a subtitle color gamut conversion unit 147, a data decoder 151, a cache unit 152, an application control unit 153, a browser unit 154, an application color gamut conversion unit 155, a sound source unit 156, a video synthesis unit 161, a video output unit 163, an audio synthesis unit 164, an audio output unit 166, an operation input unit 170, and a transcode processing unit 40181.

The broadcast receiving device 40100 of this embodiment is an optical disk drive recorder such as a DVD recorder or a BD recorder, a magnetic disk drive recorder such as an HDD recorder, an STB, etc. That is, compared to the broadcast receiving device 100 of the first embodiment, the monitor unit 162 and the speaker unit 165 may be omitted.

The digital interface unit 40125 is an interface that outputs or inputs encoded digital video data and/or digital audio data. The digital interface unit 40125 is capable of directly outputting the MMT data string obtained by demodulation in the tuner/demodulator unit 131, the MMT data string obtained via the LAN communication unit 121, or mixed data of the above-mentioned MMT data strings. In addition, the digital interface unit 40125 may be controlled so that the MMT data string input from the digital interface unit 40125 is input to the separator unit 132.

The output of digital content stored in the storage unit 110, or the storage of digital content in the storage unit 110, may be performed via the digital interface unit 40125. The digital interface unit 40125 may be a DVI terminal, an HDMI (registered trademark) terminal, a Display Port (registered trademark) terminal, or the like, and may be controlled to output the video data and audio data output from the video synthesis unit 161 and the audio synthesis unit 164 in a format conforming to the DVI specification, the HDMI specification, the Display Port specification, or the like.

The transcode processing unit 40181 is a signal processing unit that performs transcode calculation processing to convert the encoding format, bit rate, media transport method, etc. of each component that constitutes the content. For example, the transcode processing unit 40181 is capable of converting an MMT data string of a broadcast program content including a video component in MPEG-H HEVC format output from the separation unit 132 into an MPEG2-TS data string (or an MPEG2-PS data string) of program content including a video component in MPEG-2 or MPEG-4 AVC (Advanced Video Coding) format.

It is also possible to perform processing that changes only the bit rate without changing the component encoding format or media transport method. The program content that has undergone the transcoding calculation process can be stored in the storage unit 110 as recorded content, or output from the digital interface unit 40125, etc., and supplied to an external monitor device, etc.

[Software configuration of broadcast receiving device]
Fig. 35B is a software configuration diagram of the broadcast receiving device 40100 of this embodiment, and shows the software configuration in the ROM 103, the RAM 104, and the storage (accumulation) unit 110. Compared to the software configuration diagram of the broadcast receiving device 100 of Example 1 (see Fig. 7D), a transcoding processing program 41003 and a recording/playback processing program 41004 are added to the storage (accumulation) unit 110.

The transcoding processing program 41003 and the recording/playback processing program 41004 stored in the storage unit 110 are respectively expanded in the RAM 104, and the main control unit 101 executes the expanded transcoding processing program and the recording/playback processing program to form a transcoding processing execution unit 41103 and a recording/playback processing execution unit 41104. The transcoding processing execution unit 41103 mainly controls the transcoding calculation processing in the transcoding processing unit 40181. The recording/playback processing execution unit 41104 mainly controls the recording processing of broadcast program content to the content storage area 1200 and the playback processing of recorded content from the content storage area 1200.

The receiving function execution unit 1102 deployed in the RAM 104 further includes an output control unit 41102i. The output control unit 41102i of the receiving function execution unit 1102 controls each process related to data output from the video output unit 163, the audio output unit 166, and the digital interface unit 40125.

Note that the software configuration shown in FIG. 35B is merely an example, and this embodiment does not necessarily have to include all of the programs and execution units shown.

[Interface configuration between broadcast receiving device and monitor device]
Fig. 36 is a system configuration diagram showing an example of an interface configuration between the broadcast receiving device 40100 and the monitor device 40300. In this embodiment, a case will be described in which a connection terminal (not shown) of the digital interface unit 40125 on the broadcast receiving device 40100 side and a connection terminal of a digital interface unit (not shown) on the monitor device 40300 side are connected by a connection cable 40200. Note that the monitor device 40300 may have the same configuration as the broadcast receiving device 100 shown in Fig. 7A. In this case, the digital interface unit 125 corresponds to the digital interface unit on the monitor device 40300 side described above, and the connection cable 40200 is connected to the connection terminal.

As shown in FIG. 36, the connection cable 40200 is configured with n pairs of differential transmission lanes CH1 to CHn, a DDC (Display Data Channel) line standardized by the VESA (Video Electronics Standard Association), a HPD (Hot Plug Detect) line, a CEC (Consumer Electronics Control) line, etc. The differential transmission lanes may also be referred to as differential transmission lines.

The n pairs of differential transmission lanes may be one pair of clock lanes and (n-1) pairs of data lanes. For example, n=4 and one pair of clock lanes and three pairs of data lanes may be used, or n=2 and one pair of clock lanes and one pair of data lanes may be used. All of the n pairs of differential transmission lanes may be data lanes that transmit data with a clock superimposed thereon. For example, n=4 and four pairs of data lanes may be used. The clock lanes and data lanes may be referred to as clock lines and data lines, respectively.

Digital video (R/G/B/Vsync/Hsync, Y/Pb(Cb)/Pr(Cr), etc.)/audio signals and other control signals may be output in a predetermined format from the video synthesis unit 161 and audio synthesis unit 164 via the transmission processing unit 40125b of the digital interface unit 40125 on the broadcast receiving device 40100 side. The predetermined format may conform to specifications such as HDMI (registered trademark), and detailed explanations will be omitted. The digital video/audio signals and other control signals are received by the reception processing unit 40325b of the digital interface unit on the monitor device 40300 side, and are appropriately subjected to necessary processing such as image quality adjustment and volume adjustment in the video processing unit and audio processing unit (not shown), and are output from the display unit and speaker of the monitor device 40300.

The connection cable 40200 may further include a power line, a GND line, and a backup line, although these are not shown. The n pairs of differential transmission lanes and communication lines may be shielded by a GND line. All or part of the backup line, DDC line, HPD line, and CEC line may be used as part of a communication line for network communication. For example, the backup line and HPD line may constitute one transmission line and one reception line of the communication line, or one pair of transmission and reception lines. The CEC line, etc. may be omitted. The DDC line may be used as an I2C (I-squared-C) communication line between the main control unit 101 of the broadcast receiving device 40100 and the main control unit (not shown) of the monitor device 40300.

The transmission processing unit 40125b of the digital interface unit 40125 on the broadcast receiving device 40100 side communicates with the reception processing unit 40325b of the digital interface unit on the monitor device 40300 side via the DDC line, and is further capable of reading EDID (Extended Display Identification Data) from the EDID storage unit 40325c. In other words, the broadcast receiving device 40100 can grasp the display performance of the monitor device 40300 by acquiring the EDID.

In this embodiment, the display performance refers to items such as the input resolution and frame rate that the monitor device 40300 can handle, the video standard, whether or not it can display 3D images, and whether or not the monitor device 40300 can process HDR or an expanded color gamut.

In the present embodiment, the following description will be given taking as an example the process of acquiring the EDID as a means for the broadcast receiving device 40100 to ascertain the display performance of the monitor device 40300. However, the acquired information is not limited to EDID. For example, performance identification information that is different from EDID and identifies the display performance and functions of the monitor device 40300 may be acquired. Furthermore, the display performance of the monitor device 40300 may be ascertained by a means other than acquiring the performance identification information.

The transmission control unit 40125a of the digital interface unit 40125 on the broadcast receiving device 40100 side controls the transmission processing unit 40125b, and is capable of detecting, via the HPD line, that the monitor device 40300 has been connected and that the power supply of the monitor device 40300 has been turned on. The transmission control unit 40125a of the digital interface unit 40125 on the broadcast receiving device 40100 side is capable of performing processing such as turning on the power supply of the monitor device 40300 via the CEC line, etc. The reception control unit 40325a of the digital interface unit on the monitor device 40300 side also controls the reception processing unit 40325b.

Note that the configuration of the connection cable 40200, the internal configuration of the digital interface unit 40125 of the broadcast receiving device 40100, and the internal configuration of the digital interface unit of the monitor device 40300 shown in FIG. 36 are merely examples, and different configurations may be used.

[Mastering Information Parameters]
In this embodiment, as in the third embodiment, the content information descriptor shown in FIG. 29A is transmitted as control information related to the program content together with each message/table/descriptor of the MMT-SI described above. On the other hand, the broadcast receiving device 40100 of this embodiment does not include a monitor unit or a speaker that ultimately provides a video signal or an audio signal to the user, but transmits encoded video/audio data, etc. to the monitor device 40300 via the connection cable 40200, and causes the monitor device 40300 to provide a video signal or an audio signal to the user. That is, the color gamut conversion process, brightness adjustment process, etc., as described in the third embodiment are performed on the monitor device 40300 side according to the display performance of the display unit of the monitor device 40300.

In order to enable the above-mentioned processes on the monitor device 40300 side, the broadcast receiving device 40100 of this embodiment has a function of receiving the content information descriptor from the broadcast wave, appropriately selecting each parameter described in the received content information descriptor, and transmitting it to the monitor device 40300 via the connection cable 40200 as mastering information in a predetermined format. Note that, for example, if the connection cable 40200 is an HDMI (registered trademark) cable and the video data, audio data, and other control signals output from the digital interface unit 40125 are in a format that complies with the HDMI (registered trademark) specifications, the mastering information may be output as part of the other control signals.

Figure 37 shows a list of the parameters that the broadcast receiving device 40100 in this embodiment transmits to the monitoring device 40300 as mastering information.

"source_primaries_R[x,y]", "source_primaries_G[x,y]", and "source_primaries_B[x,y]" are parameters indicating information regarding the color reproduction performance of the source device, and indicate the color gamut that the source device can support by the coordinate values of each of the primary colors R (red), G (green), and B (blue) on the CIE chromaticity diagram. The parameters "source_primaries_rx", "source_primaries_ry", "source_primaries_gx", "source_primaries_gy", "source_primaries_bx", and "source_primaries_by" described in the content information descriptor may be selected and output as the "source_primaries_R[x,y]", "source_primaries_G[x,y]", and "source_primaries_B[x,y]" parameters of the mastering information.

"white_point_x, y" is a parameter indicating information regarding the color reproduction performance, etc., of the source device, and indicates the coordinate value on the CIE chromaticity diagram of the white reference point that the source device can support. The "source_white_point_x" and "source_white_point_y" parameters described in the content information descriptor may be selected and output as the "white_point_x, y" parameters of the mastering information.

"max_source_mastering_luminance" is a parameter indicating information regarding the maximum luminance that the source device can handle. It is indicated by a value ranging from "1 (cd/ ^m2 : candela/square meter)" to "65535 (cd/ ^m2 )". The "source_luminance_max" parameter described in the content information descriptor may be selected and output as the "max_source_mastering_luminance" parameter of the mastering information.

"min_source_mastering_luminance" is a parameter indicating information on the minimum luminance that the source device can handle. It is indicated by a value in the range of "0.0001 (cd/ ^m2 )" to "6.5535 (cd/ ^m2 )". The "source_luminance_min" parameter described in the content information descriptor may be selected and output as the "min_source_mastering_luminance" parameter of the mastering information.

"Maximum_Content_Light_Level" is a parameter indicating the maximum brightness in the content. It is indicated by a value in the range of "1 (cd/ ^m2 )" to "65535 (cd/ ^m2 )". The "max_light_level_of_content" parameter described in the content information descriptor may be selected and output as the "Maximum_Content_Light_Level" parameter of the mastering information.

"Maximum_Frame-average_Light_Level" is a parameter indicating the maximum value of the average frame luminance in the content. It is indicated by a value in the range of "1 (cd/ ^m2 )" to "65535 (cd/ ^m2 )". The "max_frame_ave_light_level" parameter described in the content information descriptor may be selected and output as the "Maximum_Frame-average_Light_Level" parameter of the mastering information.

"Light Level Status" is a 2-bit flag signal that indicates the status of the "Maximum_Content_Light_Level" and "Maximum_Frame-average_Light_Level" parameters.

When the value of this flag is "00b", the "Maximum_Content_Light_Level" parameter and the "Maximum_Frame-average_Light_Level" parameter indicate the maximum brightness and maximum frame average brightness throughout the entire content. When the value of this flag is "01b", the "Maximum_Content_Light_Level" parameter and the "Maximum_Frame-average_Light_Level" parameter indicate the maximum brightness and maximum frame average brightness for each scene (chapter).

When the value of this flag is "10b", it indicates that the "Maximum_Content_Light_Level" parameter and the "Maximum_Frame-average_Light_Level" parameter are omitted. Instead of setting the value of this flag to "10b", the values of the "Maximum_Content_Light_Level" parameter and the "Maximum_Frame-average_Light_Level" parameter may be set to "0".

The broadcast receiving device 40100 of this embodiment transmits the above-described parameters as mastering information to the monitor device 40300 via the connection cable 40200, which enables the monitor device 40300 to perform color gamut conversion processing, brightness adjustment processing, and other processing in accordance with the display performance of the display unit of the monitor device 40300 on the encoded video/audio data transmitted from the broadcast receiving device 40100. Note that each parameter of the mastering information described above may further include other parameters different from the parameters shown in FIG. 37, or it is not necessary to include all of the above parameters. Also, each parameter may have a different name.

[Mastering information generation process of broadcast receiving device]
In this embodiment, when the "content_type" parameter of the content information descriptor is "2" or "3", the video content is content data (such as a live broadcast program) output from the image capture device 390c, and the content information descriptor does not have the "max_light_level_of_content" parameter and the "max_frame_ave_light_level" parameter. That is, in a live broadcast program, the maximum values of the maximum brightness and the average brightness throughout the entire content are not determined until the end of the program content.

In this case, the broadcast receiving device 40100 of this embodiment outputs the mastering information with the values of the "Maximum_Content_Light_Level" parameter and the "Maximum_Frame-average_Light_Level" parameter set to "0". Alternatively, the "max_light_level_of_frame" parameter and the "frame_average_light_level" parameter of the content information descriptor may be substituted for the "Maximum_Content_Light_Level" parameter and the "Maximum_Frame-average_Light_Level" parameter.

On the other hand, when the video content is recorded in the content memory area 1200 of the storage unit 110, the "Maximum_Content_Light_Level" parameter and the "Maximum_Frame-average_Light_Level" parameter may be created by the broadcast receiving device 40100. That is, by performing the recording process of the video content, the broadcast receiving device 40100 can scan the video content from the beginning to the end, and therefore can determine the maximum values of the maximum brightness and average brightness throughout the entire content.

In addition, when the video content recorded in the content memory area 1200 of the storage unit 110 by the recording process is output from the digital interface unit 40125 to the monitor device 40300 via the connection cable 40200 by the playback process, the broadcast receiving device 40100 may be controlled to output the maximum values of the maximum luminance and average luminance throughout the entire content, which are created by scanning the video content from the beginning to the end, as the "Maximum_Content_Light_Level" parameter and the "Maximum_Frame-average_Light_Level" parameter. In other words, in the case of video content that has been recorded once, it is possible to output all parameters of the mastering information to the monitor device 40300, regardless of the value of the "content_type" parameter of the content information descriptor.

[Mastering information output control of broadcast receiving device]
Each parameter of the mastering information may be always output to the monitor device 40300 connected via the connection cable 40200. Alternatively, each parameter of the mastering information may be output to the monitor device 40300 via the connection cable 40200 only when the transmission processing unit 40125b of the digital interface unit 40125 on the broadcast receiving device 40100 side refers to the EDID acquired from the EDID storage unit 40325c of the monitor device 40300 and understands that the monitor device 40300 is capable of processing compatible with HDR or an expanded color gamut. Alternatively, each parameter of the mastering information may be output to the monitor device 40300 via the connection cable 40200 only when the content information descriptor indicates that the video content of the broadcast program is a program compatible with HDR.

In addition, the above-mentioned content information descriptor indicates that the video content of the broadcast program is compatible with HDR when the ``content_type'' parameter of the content information descriptor is ``1'' or ``3'', when the ``HDR_flag'' parameter of the content information descriptor indicates that the video content of the broadcast program is HDR-compatible, when all or any of the ``source_luminance_max'' parameter, ``max_light_level_of_content'' parameter, ``max_light_level_of_frame'' parameter, etc. of the content information descriptor exceed a predetermined value (e.g., ``100 (cd/ ^m2 )''), etc.

In addition, the output of each parameter of the mastering information may be controlled according to the interface type of the digital interface unit 40125. For example, if the interface type of the digital interface unit 40125 is an HDMI interface, control is performed so that each parameter of the mastering information is output, and if the interface type is a DVI interface, control is performed so that each parameter of the mastering information is not output, etc.

Alternatively, the output of each parameter of the mastering information may be controlled according to the interface type of the digital interface unit 40125 on the broadcast receiving device 40100 side and the interface type of the digital interface unit on the monitor device 40300 side. For example, when the interface type of the digital interface unit 40125 on the broadcast receiving device 40100 side and the interface type of the digital interface unit on the monitor device 40300 side are both HDMI interfaces, control is performed to output each parameter of the mastering information, and when the interface type of the digital interface unit 40125 on the broadcast receiving device 40100 side is an HDMI interface but the interface type of the digital interface unit on the monitor device 40300 side is not an HDMI interface (for example, when it is a DVI interface or a Display Port interface, i.e., when the connection cable 40200 is an interface conversion cable), control is performed not to output each parameter of the mastering information, etc.

In addition, when the digital interface unit 40125 is composed of a first digital interface terminal and a second digital interface terminal, control may be performed so that the format of the output data differs depending on whether the data is output from the first digital interface terminal or the second digital interface terminal. In this case, each of the digital interface terminals has the configuration shown in FIG. 36 or another configuration.

For example, if the first digital interface terminal is an HDMI interface and the second digital interface is not an HDMI interface, the output data generation process and data output process can be controlled so that when data is output from the first digital interface terminal, output data including a video signal, an audio signal, and the mastering information is generated and the data is output from the first digital interface terminal, and when data is output from the second digital interface terminal, output data including a video signal and an audio signal but not including the mastering information is generated and the data is output from the second digital interface terminal.

As described above, according to the broadcast receiving device 40100 of this embodiment, by transmitting mastering information together with encoded video/audio data to the monitor device 40300, it becomes possible to preferably execute color gamut conversion processing, brightness adjustment processing, etc. on the monitor device 40300 side. In other words, it becomes possible to provide a broadcast receiving device that can execute functions with higher added value.

(Example 5)
The following describes the fifth embodiment of the present invention. The configuration and effects of the fifth embodiment are the same as those of the fourth embodiment unless otherwise specified. Therefore, the following mainly describes the differences between the fifth embodiment and the fourth embodiment, and omits as much as possible the description of the common points to avoid duplication.

[System configuration]
FIG. 38 is a system configuration diagram showing an example of a broadcast communication system including a broadcast receiving device of this embodiment. The broadcast communication system of FIG. 38 has the same configuration as the broadcast communication system of FIG. 34, but the output destination to which the broadcast receiving device 40100 outputs content is the external video processing device 50300 instead of the monitor device 40300. This means that the output destination of the content includes a video playback device such as a recorder in addition to the display device. Furthermore, in the broadcast communication system including the broadcast receiving device of this embodiment, the control information transmitted together with the content received by the broadcast receiving device 40100 via the broadcast station's radio tower 300t, the broadcast satellite (or communication satellite) 300s, and the broadcast station server 300 is called "reception control information". This includes various control information described in the first embodiment and control information additionally described in this embodiment. Furthermore, in the broadcast communication system including the broadcast receiving device of this embodiment, when the broadcast receiving device 40100 outputs content to the external video processing device 50300 via the network via the router device 200r, the control information transmitted together with the content is called "output control information".

The hardware configuration of the broadcast receiving device, the software configuration of the broadcast receiving device, and the interface configuration between the broadcast receiving device and the monitor device are the same as those in Example 4, so a repeated explanation will be omitted.

In FIG. 35A, by configuring the digital interface unit 40125 using the hardware of the LAN communication unit 121, it is possible to output from the digital interface unit 40125 to an output destination on the network. Here, the output from the digital interface unit 40125 is not limited to an MMT data string, but may be an MPEG2-TS data string (or an MPEG2-PS data string) transcoded from the MMT data string by the transcode processing unit 40181. This is an example of configuring it as an "IP interface" as described in the first embodiment.

Here, in the broadcast communication system of FIG. 38, when the broadcast receiving device 40100 outputs content to the external video processing device 50300 via a network via the router device 200r, this means that the broadcast receiving device 40100 outputs content to the external video processing device 50300 via the IP interface.

As described in the third and fourth embodiments of the present invention, the broadcasting and communication system of this embodiment is capable of transmitting high-quality content, such as not only SDR video content with a resolution of 1920 x 1080 pixels or less, but also content with a resolution exceeding 1920 x 1080 pixels and HDR video content. Here, when the receiver re-outputs these high-quality video contents broadcast in the broadcasting and communication system to an external device via an interface, the content protection required is higher than that required for SDR video content with a resolution of 1920 x 1080 pixels or less.

To achieve this, content protection using DTCP2 (described in Reference 1), a more advanced content protection system than DTCP-IP, has been developed as an interface transmission technology.

[Reference 1: Digital Transmission Licensing Administrator DTCP2 Presentation to CPTWG January 27, 2016]

Specifically, DTCP2 has four new flags ("L2-Only" Flag, "EI" Flag, "HDR" Flag, "SDO" Flag) as shown in FIG. 39. For example, the "L2-Only" Flag in FIG. 39 indicates that "either content protection, DTCP-IP (L1 level content protection) or DTCP2 (L2 level content protection), can be applied" when it is "0", and indicates that "a higher level of content protection (e.g., L2 level content protection such as DTCP2) is required" when it is "1". Note that DTCP-IP (L1 level content protection) is referred to as "DTCP1" in the following explanation to distinguish it from "DTCP2". Also, the "EI" Flag indicates that "the content is 'Non-Enhanced Image'" when it is "0", and indicates that "the content is 'Enhanced Image'" when it is "1". Here, "Enhanced Image" refers to content with a pixel count exceeding 1920x1080 or a color space (e.g., HDR such as BT.2020 or SMPTE2084) exceeding an HD-level color space (SDR such as BT.709). "Non-Enhanced Image" refers to content with an image below HD image quality (e.g., an image with a pixel count of 1920x1080 or less and an HD-level color space (SDR such as BT.709)). "HDR" Flag indicates that "0" means "content with image that may be converted from HDR to SDR," and "1" means "content with image that is prohibited from being converted from HDR to SDR." In addition, if the "SDO" Flag is "0", it indicates that "in the case of an 'Enhanced Image', it cannot be re-output unless it is L2 level content protection, but if an 'Enhanced Image' is converted to a 'Non-Enhanced Image', it can be re-output with L1 level content protection", and if it is "1", it indicates that "regardless of whether the content is an 'Enhanced Image' or a 'Non-Enhanced Image', it can be re-output with either L2 level content protection or L1 level content protection".

When the content protection by DTCP2 described above is applied to the IP interface output of this embodiment, the problem is which content should be assigned which flag as the output control information 50200 in FIG. 38. For example, it is possible to prepare flags substantially corresponding to the four flags in FIG. 39 on the reception control information 50100 side in FIG. 38. In this way, it is possible to make the server of the broadcasting station a sink device of DTCP2. However, the above four flags are 1 bit each, and if these flags can be freely set according to the intention of the broadcasting station or the production side, there are 2 to the power of 4, that is, 16 different content protection states, considering all combinations of the four flags, which is very complicated. This is not suitable for "broadcasting" technology, which is received by many viewers at the same time and in which the start and end of a program are repeated in the service selected. The number of viewers targeted by "broadcasting" technology is huge, and the monitors owned by the viewers are also various. For example, if some viewers have monitors that are not HDR compatible, then content protection control using flags would prevent those viewers from viewing the content at all, a situation that "broadcasting" technology would want to avoid as much as possible. Also, in order to popularize receiving devices, the content transmitted by "broadcasting" technology needs to have a simple system of types that are easy for many viewers to understand.

In addition, adding a new flag to the reception control information 50100 would also complicate the equipment on the content production side.

In consideration of the above, in the broadcast communication system of this embodiment, flags that substantially correspond to the above four flags of DTCP2 are not introduced as they are in the reception control information 50100 of FIG. 38. In addition, when the broadcast receiving device 40100 outputs to the IP interface, the DTCP2 flags are used as the output control information 50200 to provide more suitable content protection. Specifically, in the broadcast communication system of this embodiment, as the reception control information 50100, information on the video resolution of the content, control information regarding the digital copying of the content, control information regarding the storage and output of the content, and the EOTF identification information (transmission characteristic identification information) described in the third and fourth embodiments are used, and when the broadcast receiving device 40100 outputs to the IP interface, the broadcast receiving device 40100 determines the output protection of each content, including the addition of the DTCP2 flag, according to this information.

Here, the information on the video resolution of the content used as one piece of reception control information 50100 will be described. Multiple types of information on the video resolution of the content are transmitted in the broadcast communication system of this embodiment. The broadcast receiving device 40100 can determine the video resolution (number of pixels) of the content using any of these multiple types of information. For example, the determination may be made by acquiring coding parameters stored in the coding stream of HEVC, which is the video coding method of the content of the broadcast system of this embodiment. Alternatively, the determination may be made by acquiring coding parameters described in the MH-HEVC video descriptor placed in the MPT. Alternatively, the determination may be made by acquiring video resolution information described in the video component descriptor.

Next, control information related to the digital copy of content and control information related to the storage and output of content used as one piece of reception control information 50100 will be described. Figure 40 shows descriptors related to the control information related to the digital copy of content and the control information related to the storage and output of content transmitted in the broadcast communication system of this embodiment. Here, the content copy control descriptor stores control information related to the digital copy of content or information indicating the maximum transmission rate. Furthermore, the content usage control descriptor stores information describing the control information related to the storage and output of content. The content copy control descriptor and the content usage control descriptor are, for example, placed in the MPT and transmitted.

Figure 41A shows an example of the data structure of the content copy control descriptor in the broadcasting system of this embodiment. The "digital_recording_control_data" parameter in the figure is digital copy control information, and indicates information that controls the copy generation of the content. Also, Figure 41B shows an example of the parameter value of the digital copy control information and its meaning. For example, when the parameter is "00", it indicates "copying possible without restrictions (synonymous with "unlimited copying possible")", when the parameter is "01", it can be defined by the business operator, when the parameter is "10", it indicates "copying possible for only one generation", and when the parameter is "11", it indicates "copying prohibited". Only when the parameter is "00" and indicates "copying possible without restrictions", it can be said that protection by the digital copy control information is not specified. When the parameter is "01", "10", or "11", it can be said that some protection by the digital copy control information is specified.

Figure 42 also shows an example of the data structure of a content usage control descriptor in the broadcasting system of this embodiment. The "copy_restriction_mode" parameter in the figure is the copy restriction mode, and indicates whether or not a limited number of copies are possible (corresponding to "predetermined number of copies allowed" in embodiment 1). The value of the "encryption_mode" parameter of the content usage control descriptor shown in Figure 42 is used to control protection (encryption) when outputting to the IP interface. If the value of the "encryption_mode" parameter is "0", indicating that protection is required (encryption required), encryption processing is performed when the content is output, and if the value is "1", indicating that protection is not required (encryption not required), the content may be output without protection (encryption processing).

The combination of the "digital_recording_control_data" parameter of the content copy control descriptor, the "encryption_mode" parameter of the content usage control descriptor, and the "copy_restriction_mode" parameter of the content usage control descriptor described above is a specific configuration example of the "copy control information" described in Example 1.

The broadcast receiving device 40100 of this embodiment can obtain the "digital_recording_control_data" parameter of the content copy control descriptor and the "copy_restriction_mode" parameter of the content usage control descriptor described above, and use them to determine whether to protect the output of the content output from the IP interface.

Next, the EOTF identification information used as one piece of reception control information 50100 has already been described in detail in Examples 3 and 4, so a repeated description will be omitted. Furthermore, the broadcast receiving device 40100 of this embodiment may determine output protection of content output from the IP interface using not only the EOTF identification information as reception control information 50100, but also the presence or absence or result of resolution conversion processing of the video of the content, or the presence or absence or result of transfer characteristic conversion processing described in Examples 3 and 4, or the presence or absence of content storage processing or the state after storage.

[Processing for determining output protection of content output from IP interface in broadcast receiving device]
43, 44, and 45 show an example of a process for determining output protection of content output from an IP interface in a broadcast receiving device.
First, Figure 43 shows the process of determining whether to protect the output of content when a broadcast receiving device 40100 receives content together with reception control information 50100 and outputs the content via an IP interface without performing resolution conversion processing or transmission characteristic conversion processing on the content image.

In FIG. 43, the main control unit 101 of the broadcast receiving device 40100 of this embodiment determines whether to protect the output of the content when outputting through the IP interface, based on the information contained in the reception control information 50100. Specifically, the main control unit 101 determines whether to protect the output of the content when outputting through the IP interface, based on a combination of the "digital_recording_control_data" parameter of the content copy control descriptor, the "encryption_mode" parameter of the content usage control descriptor, the video resolution of the received content, and the transfer characteristic (EOTF) identification information. Below, examples of determinations for each combination are explained.

[Figure 43 Combination 1]
In the example of combination 1 in Fig. 43, the "digital_recording_control_data" parameter of the content copy control descriptor indicates "copyable without restrictions," and the "encryption_mode" parameter of the content usage control descriptor indicates that the protection state at the time of output from the IP interface is "not protected." In other words, in this case, neither parameter specifies copy restriction or output protection for the content.

In this case, whether the video resolution is content that exceeds 1920 pixels horizontally and 1080 pixels vertically (content that exceeds the relevant number of pixels horizontally or vertically; hereafter referred to as "over 2K content"), content that is 1920 pixels horizontally and 1080 pixels vertically or less (content that is less than the relevant number of pixels horizontally or vertically; hereafter referred to as "2K or less content"), whether the transfer characteristic identification information indicates HDR or SDR, output protection of the content is not required when outputting through the IP interface. Copy control at the time of output is not required (effectively copy free), and encryption at the time of output is also not required, so naturally there is no need to add output control information for DTCP2. However, the content may be output with protection of DTCP1 (the above-mentioned "DTCP-IP") or DTCP2. In that case, the copy control state at the time of output may be set to "Copy Free" and no encryption may be used. Furthermore, when outputting with protection of DTCP2, the output control information may be determined as follows. The "L2-Only" Flag is set to 0. The "EI" Flag is set to 0 for content below 2K with transfer characteristics of SDR, and 1 for other content. The "HDR" Flag is set to 0. The "SDO" Flag is set to 1. In other words, the protection level of the DTCP for the IP interface output can be either L1 or L2, copy control is copy free, transfer characteristic conversion is not prohibited, and the content is output in a state where it can be re-output in either the L1 or L2 protection state regardless of the resolution or transfer characteristic state. This means that the content is output in the lowest protection state of the output control states of the IP interface output in this embodiment.

[Figure 43 Combinations 2 to 5]
In the examples of combinations 2 to 5 in Figure 43, the "digital_recording_control_data" parameter of the content copy control descriptor indicates that "copying is permitted without restrictions," and the "encryption_mode" parameter of the content usage control descriptor indicates that the protection state at the time of output to the IP interface is "protected."

In this case, because the "encryption_mode" parameter of the content usage control descriptor specifies that protection is to be performed when outputting to the IP interface, output protection is performed using either DTCP2 or DTCP1 in any combination. In this case, the copy control state is set to "EPN," which indicates a state in which there is no copy restriction but encryption is required, and encryption protection processing is performed. Here, the level of output protection processing to be performed, DTCP2 or DTCP1, is determined according to the combination of the video resolution of the received content and the transfer characteristic (EOTF) identification information.

For example, in combination 5, the video resolution of the received content is 2K or less, and the transfer characteristic (EOTF) identification information is SDR. Since this is so-called HD quality content, conventional levels of output protection are sufficient, and output protection is performed using DTCP1. In this case, naturally, output control information for DTCP2 is not added.

In addition, combinations 2, 3, and 4 satisfy either the condition that the video resolution of the received content is over 2K content or the transfer characteristic (EOTF) identification information is HDR. In this case, since the content has a picture quality exceeding HD quality, the content is protected using DTCP2, which is a more advanced level of output protection than DTCP1. In this case, the DTCP2 output control information to be added to the output content is determined as follows:

Here, for the "L2-Only" Flag, in any of combinations 2, 3, and 4, the "L2-Only" Flag is set to 0. If the "L2-Only" Flag is set to 1, even if the image quality is reduced to HD quality by pixel count conversion or transfer characteristic conversion processing on the output destination device, re-output is not possible unless L2 level content protection such as DTCP2 is performed. Depending on the device owned by the viewer, viewing may be impossible (for example, if the device owned by the viewer does not support DTCP2), and this situation is not desirable for protecting "broadcast" content that is received simultaneously by many viewers. The above is the reason for setting the "L2-Only" Flag to 0. In any of the determinations of DTCP2 output control information described below in this embodiment, the "L2-Only" Flag is set to 0 as a general rule for the same reason. However, as a variant, if broadcast content or broadcast services are divided into "free broadcasts" and "paid broadcasts" and these can be distinguished in the broadcast receiving device 40100, the "L2-Only" Flag can be set to 0 for "free broadcasts" and 1 for "paid broadcasts." This is because the viewers of "paid broadcasts" are limited, and a particularly high level of protection is required for the content of "paid broadcasts."

In addition, the "EI" Flag is set to 1 in combinations 2, 3, and 4. This is because either the video resolution of the received content is 2K or higher, or the EOTF identification information is HDR.

In addition, for the "HDR" Flag, in combinations 2 and 3, the "HDR" Flag is set to 0. In these combinations, the transfer characteristic (EOTF) identification information is HDR, and if output as is, the transfer characteristic of the content when output to the IP interface is also HDR. If the "HDR" Flag is set to 1 here, the output device will not be able to perform transfer characteristic conversion processing to convert to SDR content. In this case, depending on the device owned by the viewer, viewing may be impossible (for example, if the device owned by the viewer does not support HDR content). This situation is not desirable for protecting "broadcast" content that is received simultaneously by many viewers. The above is the reason for setting the "HDR" Flag to 0. In any of the determinations of output control information for DTCP2 in the following explanations of this embodiment, the "HDR" Flag is set to 0 as a general rule for the same reason. However, as a variant, if broadcast content or broadcast services are divided into "free broadcasts" and "paid broadcasts" and these can be distinguished by the broadcast receiving device 40100, the "HDR" Flag may be set to 0 for "free broadcasts" and 1 for "paid broadcasts." This is because the viewers of "paid broadcasts" are limited, and there are service providers who believe that there is value in watching "paid broadcast" content in high-quality HDR image quality.

As for the "HDR" Flag, in combination 4, the transfer characteristic (EOTF) identification information is SDR, and if output as is, the transfer characteristic of the content when output to the IP interface will also be SDR. Therefore, there is no need to add the "HDR" Flag, which indicates whether or not the transfer characteristic conversion process for HDR content to SDR is possible.

In addition, the "SDO" Flag is set to 0 in all combinations 2, 3, and 4. Since the "encryption_mode" parameter of the content usage control descriptor specifies protection at the time of IP interface output, it is desirable to protect content with a resolution of over 2K or content with HDR transmission characteristics at a high level of protection. On the other hand, in "broadcasting" technology, which assumes simultaneous reception by many viewers, it is desirable to avoid a situation where some viewers using devices that do not support L2 level content protection are unable to view the content at all. Here, if the "SDO" Flag is set to 0, high L2 level content protection is possible for content with a resolution of over 2K or content with HDR transmission characteristics, while when the content is reduced to HD image quality by resolution conversion processing or transmission characteristic conversion processing, content protection at the conventional DTCP-IP level (L1 level) that is supported by many devices is allowed, so it is highly consistent with these two requirements required for protection processing of the output of content received by "broadcasting" technology. The above is the reason for setting the "SDO" Flag to 0. In determining the output control information of any DTCP2 described below in this embodiment, if copy restriction or content output protection is specified by the "digital_recording_control_data" parameter of the content copy control descriptor or the "encryption_mode" parameter of the content usage control descriptor, or if the status of the content storage process indicates copy restriction or content output protection, the "SDO" Flag is set to 0 for the same reason.

[Figure 43 Combinations 6 to 9]
In the examples of combinations 6 to 9 in Fig. 43, the "digital_recording_control_data" parameter of the content copy control descriptor indicates "copying allowed for one generation only". In this case, since it is specified that there is a copy restriction, it is desirable to protect the content even when it is output to the IP interface, regardless of the value of the "encryption_mode" parameter of the content usage control descriptor. Therefore, output protection is performed using either DTCP2 or DTCP1. In this case, the copy control state is set to "Copy One Generation", indicating that copying is allowed for one generation only, and encryption protection processing is performed.

Here, (1) which level of output protection processing to perform, DTCP2 or DTCP1, and (2) the output control information when output protection processing is performed with DTCP2 are determined according to the combination of the video resolution of the received content and the transfer characteristic (EOTF) identification information. However, the method of determining these in combinations 6, 7, 8, and 9 in Figure 43 is the same as combinations 2, 3, 4, and 5 in Figure 43, respectively, so a repeated explanation will be omitted.

[Figure 43 Combinations 10 to 13]
In the examples of combinations 10 to 13 in Fig. 43, the "digital_recording_control_data" parameter of the content copy control descriptor indicates "copy prohibited". In this case, since it is specified that there is a copy restriction, it is desirable to perform content protection even when outputting to the IP interface, regardless of the value of the "encryption_mode" parameter of the content usage control descriptor. Therefore, output protection is performed using either DTCP2 or DTCP1. In this case, the copy control state is set to "Copy Never", which indicates copy prohibition, and encryption protection processing is performed.

Here, (1) which level of output protection processing to perform, DTCP2 or DTCP1, and (2) the output control information when output protection processing is performed with DTCP2 are determined according to a combination of the video resolution of the received content and the transfer characteristic (EOTF) identification information. However, the method of determining these in combinations 10, 11, 12, and 13 in Figure 43 is the same as in combinations 2, 3, 4, and 5 in Figure 43, respectively, so a repeated explanation will be omitted.

[Example of exception handling for the process in Figure 43]
As described above, an example of the process of determining whether or not to protect the output of content when outputting via an IP interface is described with reference to FIG.

However, it may be necessary to handle some exceptions that are not shown in Figure 43, and these are described below.

For example, if the content copy control descriptor itself or the "digital_recording_control_data" parameter of the content copy control descriptor is not transmitted as the reception control information 50100 due to some reason such as a transmission error, the broadcast receiving device 40100 cannot obtain the "digital_recording_control_data" parameter. In such a case, the broadcast receiving device 40100 can perform the decision process of FIG. 43 by regarding the state as being the same as when the "digital_recording_control_data" parameter of the content copy control descriptor indicates "copyable without restrictions." Specifically, one process from combinations 1 to 5 in FIG. 43 is selected while taking into account the other reception control information 50100.

Furthermore, if the content usage control descriptor itself or the "encryption_mode" parameter of the content usage control descriptor is not transmitted as the reception control information 50100 due to some reason such as a transmission error, the broadcast receiving device 40100 cannot obtain the "encryption_mode" parameter. In such a case, the broadcast receiving device 40100 can perform the decision process of FIG. 43 by regarding the state as being the same as when the "encryption_mode" parameter of the content usage control descriptor indicates "no protection." Specifically, one process will be determined from combinations 1 and 6 to 13 in FIG. 43, taking into account the other reception control information 50100.

In addition, if the transfer characteristic (EOTF) identification information is not transmitted as the reception control information 50100 due to some reason such as a transmission error, the broadcast receiving device 40100 cannot acquire the transfer characteristic (EOTF) identification information. In such a case, instead of making a judgment based on the received transfer characteristic (EOTF) identification information, the broadcast receiving device 40100 can make a judgment based on whether the video format when the content is output via IP interface output is HDR or SDR. Specifically, the description in the transfer characteristic (EOTF) identification information column in FIG. 43 can be interpreted as meaning whether the video format when the content is output via IP interface output is HDR or SDR, and the content output protection decision process can be performed when the IP interface output is performed.

[Modification of the process of FIG. 43]
In the example of FIG. 43, when HDR content is protected by DTCP2 and output to the IP interface (combinations 2, 3, 6, 7, 10, and 11), the "HDR" Flag is output as 0. However, in all of these combinations, the "SDO" Flag indicates 0, and it is assumed that content conversion from HDR to SDR is possible. Then, in combinations 2, 3, 6, 7, 10, and 11 of FIG. 43, control may be performed such that the "HDR" Flag is not output as output control information for DTCP2. In this case, in all of the combinations, the "HDR" Flag is not output, and therefore the IP interface output control of the broadcast receiving device 40100 is simplified.

In addition, in the example of FIG. 43, when content is output with DTCP2 protection, the control to output the "L2-Only" Flag as "0" is shown as the DTCP2 output control information. As described above, even if the output destination device is a DTCP2 compatible device, in consideration of the case where the DTCP2 compatible device further outputs to other devices, if the DTCP2 compatible device performs resolution conversion processing and transfer characteristic conversion processing to convert the content to 2K or less content with transfer characteristics of SDR, output with an L1 level content protection method such as DTCP1 is permitted. However, as a modified example of FIG. 43, in combinations (combinations 10, 11, and 12) in which the "digital_recording_control_data" parameter of the content copy control descriptor is "copy prohibited" and the content is output with Copy Never due to DTCP2 protection, the control to output the "L2-Only" Flag as "1" may be replaced with the control. In this example, for content with the "digital_recording_control_data" parameter of the content copy control descriptor set to "Copy Prohibited", the content provider is deemed to have a higher need for content protection, and content protection is strengthened. Specifically, if the "L2-Only" Flag is set to "1" and the content is output from the destination DTCP2-compatible device to another device, even if resolution conversion processing or transfer characteristic conversion processing is performed, the content cannot be output if the destination device does not support an L2 level content protection method such as DTCP2. In other words, the content is always subjected to L2 level content protection after it is output from the IP interface of the broadcast receiving device 40100.

According to the content output protection decision process when performing IP interface output in Figure 43 described above, when content is received together with reception control information 50100 and IP interface output is performed without performing resolution conversion processing or transfer characteristic conversion processing on the content video, it is possible to achieve content output protection that is well-balanced in terms of both output protection for the image quality of the content video and convenience for viewers of broadcast content.

Next, Figure 44 shows the process of determining content output protection when a broadcast receiving device 40100 receives content along with reception control information 50100, performs resolution conversion processing and transmission characteristic conversion processing on the content image, and outputs it through an IP interface.
In the example of Fig. 44, the broadcast receiving device 40100 of this embodiment performs resolution conversion processing and/or transfer characteristic conversion processing on the video of the received content. The resolution conversion processing may be performed by a resolution processing unit provided between the video decoder 141 and the video color gamut conversion unit 142 of the broadcast receiving device 40100 of Fig. 35A. The transfer characteristic conversion processing may be performed by the video color gamut conversion unit 142, as already explained in the third and fourth embodiments.

In the example of FIG. 44, the content image undergoes resolution conversion processing and/or transfer characteristic conversion processing before the IP interface output is performed, so appropriate content output protection cannot be determined based on the information contained in the reception control information 50100 alone.

Therefore, in addition to the information included in the reception control information 50100, the video resolution after resolution conversion processing and/or the transfer characteristics after transfer characteristic conversion processing are also taken into consideration when deciding on content output protection when performing IP interface output. Specifically, an item "Video Resolution at Output" is provided in "Output State" instead of "Video Resolution" in "Reception Control Information" in FIG. 43, and an item "Transfer Characteristics at Output" is provided in "Output State" instead of "Transfer Characteristics Identification Information (ETOF)" in "Reception Control Information". Here, the main control unit 101 of the reception control information 50100 determines the "Video Resolution at Output" in "Output State" and the "Transfer Characteristics at Output" in "Output State" based on the following judgment.

First, if the broadcast receiving device 40100 of this embodiment performs resolution conversion processing on the video of the received content and does not perform transfer characteristic conversion processing, it can determine the resolution of the video after the resolution conversion processing as the "output video resolution" of the "output state", and determine the transfer characteristic indicated in the "transfer characteristic identification information (ETOF)" of the "reception control information" as the "output transfer characteristic" of the "output state".

In addition, when the broadcast receiving device 40100 of this embodiment performs transfer characteristic conversion processing without performing resolution conversion processing on the video of the received content, it can determine the "video resolution" in the "reception control information" as the "output video resolution" in the "output state", and determine the transfer characteristic after the transfer characteristic conversion processing as the "output transfer characteristic" in the "output state".

In addition, when the broadcast receiving device 40100 of this embodiment performs both resolution conversion processing and transfer characteristic conversion processing on the video of the received content, the resolution of the video after the resolution conversion processing can be determined as the "output video resolution" of the "output state", and the transfer characteristic after the transfer characteristic conversion processing can be determined as the "output transfer characteristic" of the "output state".

In the example of Figure 44, the broadcast receiving device 40100 of this embodiment performs a process of determining whether to protect the output of content when performing IP interface output as shown in Figure 44, using the "video resolution at output" of the "output state" and the "transfer characteristics at output" of the "output state" determined by the judgment described above. However, in the already described Figure 43, if the "video resolution" of the "reception control information" is replaced with the "video resolution at output" of the "output state" and the "transfer characteristics identification information (ETOF)" of the "reception control information" is replaced with the "transfer characteristics at output" of the "output state", the control will be the same as the example of Figure 44. Therefore, the IP interface output control in each of the combinations 1 to 13 of the "digital_recording_control_data" parameter of the content copy control descriptor and the "encryption_mode" parameter of the content usage control descriptor in the "reception control information" in Figure 44, and the "video resolution at output" and "transmission characteristics at output" in the "output state" is similar to the IP interface output control in each of the combinations 1 to 13 of the "digital_recording_control_data" parameter of the content copy control descriptor and the "encryption_mode" parameter of the content usage control descriptor in the "reception control information" in Figure 43, and the "video resolution" and "transmission characteristics identification information (ETOF)", so a repeated explanation will be omitted.

[Example of exception handling for the process in Figure 44]
As described above, an example of the process of determining whether or not to protect the output of content when outputting via an IP interface is described with reference to FIG.

However, it may be necessary to handle some exceptions that are not shown in Figure 44, and these are described below.

For example, if the content copy control descriptor itself or the "digital_recording_control_data" parameter of the content copy control descriptor is not transmitted as the reception control information 50100 due to some reason such as a transmission error, the broadcast receiving device 40100 cannot obtain the "digital_recording_control_data" parameter. In such a case, the broadcast receiving device 40100 can perform the decision process of FIG. 44 by regarding the state as being the same as when the "digital_recording_control_data" parameter of the content copy control descriptor indicates "copyable without restrictions." Specifically, one process is selected from combinations 1 to 5 in FIG. 44, taking into consideration the other reception control information 50100 and the conversion process within the receiver.

In addition, if the content usage control descriptor itself or the "encryption_mode" parameter of the content usage control descriptor is not transmitted as the reception control information 50100 due to some reason such as a transmission error, the broadcast receiving device 40100 cannot obtain the "encryption_mode" parameter. In such a case, the broadcast receiving device 40100 can perform the decision process of FIG. 44 by regarding the state as the same as when the "encryption_mode" parameter of the content usage control descriptor indicates "no protection." Specifically, one process is determined from combinations 1 and 6 to 13 in FIG. 44, taking into consideration other reception control information 50100 and conversion processes within the receiver.

In addition, if the transfer characteristic (EOTF) identification information is not transmitted as the reception control information 50100 due to some reason such as a transmission error, the broadcast receiving device 40100 cannot acquire the transfer characteristic (EOTF) identification information. Even in such a case, in the example of FIG. 44, it is sufficient to make a determination based on whether the content after conversion processing in the receiver is HDR or SDR, so there is no need for exceptional processing in this regard.

[Modification of the process in FIG. 44]
In the example of FIG. 44, when HDR content is protected by DTCP2 and output to the IP interface (combinations 2, 3, 6, 7, 10, and 11), the "HDR" Flag is output as 0. However, in all of these combinations, the "SDO" Flag indicates 0, and it is assumed that content conversion from HDR to SDR is possible. Then, in combinations 2, 3, 6, 7, 10, and 11 of FIG. 44, the "HDR" Flag may be controlled not to be output as output control information for DTCP2. In this case, in all of the combinations, the "HDR" Flag is not output, so that the IP interface output control of the broadcast receiving device 40100 is simplified.

In addition, in the example of FIG. 44, when content is output with DTCP2 protection, the control to output the "L2-Only" Flag as "0" is shown as the DTCP2 output control information. As described above, even if the output destination device is a DTCP2 compatible device, in consideration of the case where the DTCP2 compatible device further outputs to other devices, if the DTCP2 compatible device performs resolution conversion processing and transfer characteristic conversion processing to convert the content to 2K or less content with transfer characteristics of SDR, output with an L1 level content protection method such as DTCP1 is permitted. However, as a modified example of FIG. 44, in combinations (combinations 10, 11, and 12) in which the "digital_recording_control_data" parameter of the content copy control descriptor is "copy prohibited" and the content is output with Copy Never with DTCP2 protection, the control to output the "L2-Only" Flag as "1" may be replaced with the control to output the DTCP2 output control information. In this example, for content with the "digital_recording_control_data" parameter of the content copy control descriptor set to "Copy Prohibited", the content provider is deemed to have a higher need for content protection, and content protection is strengthened. Specifically, if the "L2-Only" Flag is set to "1" and the content is output from the destination DTCP2-compatible device to another device, even if resolution conversion processing or transfer characteristic conversion processing is performed, the content cannot be output if the destination device does not support an L2 level content protection method such as DTCP2. In other words, the content is always subjected to L2 level content protection after it is output from the IP interface of the broadcast receiving device 40100.

According to the content output protection decision process when performing IP interface output in Figure 44 described above, when content is received together with reception control information 50100 and resolution conversion processing and/or transfer characteristic conversion processing is performed on the content video before performing IP interface output, it is possible to achieve content output protection that is well-balanced in terms of both output protection for the image quality of the content video and convenience for viewers of broadcast content.

Next, FIG. 45 shows the process of determining whether to protect the output of content when the broadcast receiving device 40100 receives content together with the reception control information 50100, stores the content, and then outputs the content via the IP interface. The outline of the storage process has already been explained in the first embodiment, so a repeat explanation will be omitted.

First, the broadcast receiving device 40100 determines the storage control state of the content to be stored using the "digital_recording_control_data" parameter of the content copy control descriptor, the "encryption_mode" parameter of the content usage control descriptor, and the "copy_restriction_mode" parameter of the content usage control descriptor contained in the reception control information 50100.

Here, if the "digital_recording_control_data" parameter of the content copy control descriptor indicates "copyable without restrictions" and the "encryption_mode" parameter of the content usage control descriptor indicates "not protected" (example of combination 1 in Figure 45), the storage control state is "storage without copy restrictions and no encryption_mode protection" regardless of the value of the "copy_restriction_mode" parameter of the content usage control descriptor.

In addition, if the "digital_recording_control_data" parameter of the content copy control descriptor indicates "copyable without restrictions" and the "encryption_mode" parameter of the content usage control descriptor indicates "protected" (examples of combinations 2 to 5 in Figure 45), the storage control state is "storage without copy restrictions and encryption_mode protection" regardless of the value of the "copy_restriction_mode" parameter of the content usage control descriptor.

In addition, if the "digital_recording_control_data" parameter of the content copy control descriptor indicates "Copying allowed for one generation only" and the "copy_restriction_mode" parameter of the content usage control descriptor indicates "Copying allowed for one generation only" (examples of combinations 6 to 9 in Figure 45), the storage control state is set to "No re-copying" regardless of the value of the "encryption_mode" parameter of the content usage control descriptor.

In addition, if the "digital_recording_control_data" parameter of the content copy control descriptor indicates "one generation only copying allowed" and the "copy_restriction_mode" parameter of the content usage control descriptor indicates that "number-limited copying allowed" is available (examples of combinations 10 to 13 in Figure 45), the storage control state of "number-limited copying allowed" is possible regardless of the value of the "encryption_mode" parameter of the content usage control descriptor.

In addition, when the "digital_recording_control_data" parameter of the content copy control descriptor indicates "copy prohibited" (examples of combinations 14 to 17 in FIG. 45), the state in which content can be stored is limited to the storage control state of "temporary storage", regardless of the values indicated by the "digital_recording_control_data" parameter of the content copy control descriptor and the "copy_restriction_mode" of the content usage control descriptor. The outline of "temporary storage" has already been explained in Example 1, so a repeat explanation will be omitted.

As described above, the broadcast receiving device 40100 determines the storage control state of the content to be stored using the "digital_recording_control_data" parameter of the content copy control descriptor, the "encryption_mode" parameter of the content usage control descriptor, and the "copy_restriction_mode" parameter of the content usage control descriptor contained in the reception control information 50100.

Next, when the broadcast receiving device 40100 outputs the stored content from the IP interface, it makes a decision on output protection of the content output from the IP interface according to the storage control state of the content and the "video resolution at output" and "transfer characteristics at output" when outputting the content. Here, in the example of FIG. 45, a resolution conversion process and/or a transfer characteristic conversion process may be performed on the video of the content before and after the content storage process. This is common to the example of FIG. 44 in that a resolution conversion process and/or a transfer characteristic conversion process may be performed before the broadcast receiving device 40100 receives the content and outputs it from the IP interface. Therefore, the determination of the "video resolution at output" and "transfer characteristics at output" in the broadcast receiving device 40100 can be performed in the same way as in the example of FIG. 44, so a repeated explanation will be omitted.

Next, we will explain how to determine content output protection when performing IP interface output for each combination in Figure 45.

[Figure 45 Combination 1]
In the example of combination 1 shown in Fig. 45, i.e., when content in a storage control state of "storage without copy restrictions and without encryption_mode protection" is output via an IP interface, content output control can be performed in the same manner as in combination 1 in Fig. 44. To avoid repetition, a repeated explanation will be omitted.

[Figure 45 Combinations 2 to 5]
In the case of the examples of combinations 2 to 5 shown in Fig. 45, i.e., when content in a storage control state of "storage without copy restrictions and encryption_mode protection" is output via an IP interface, content output control similar to that of combinations 2 to 5 in Fig. 44 may be performed. To avoid repetition, a repeated explanation will be omitted.

[Figure 45 Combinations 6 to 9]
In the examples of combinations 6 to 9 shown in Fig. 45, i.e., when content in a storage control state of "no more copies" is output to an IP interface, the copy control state at the time of output differs depending on whether the output process is an output for viewing on a destination device or a move of content to the destination device. Specifically, when the IP interface output is an output for viewing, the copy control state is output as "No More Copies" indicating no more copies. When the IP interface output is a move, the copy control state is output as "Move." In each of combinations 6, 7, 8, and 9 shown in Fig. 45, other content protection controls in the IP interface output are the same as those in each of combinations 6, 7, 8, and 9 shown in Fig. 44, and therefore will not be described again.

[Figure 45 Combinations 10 to 13]
The content protection control in each of the examples of combinations 10, 11, 12, and 13 in FIG. 45, that is, when content in a storage control state of "number-limited copying permitted" is output to an IP interface, is almost the same as each of the examples of combinations 6, 7, 8, and 9 in FIG. 45. The differences are as follows. When content in a storage control state of "no re-copying" is output to an IP interface, once a move process is performed, the content must be rendered unplayable in the broadcast receiving device 40100 (note that the content can be output for viewing any number of times until it is rendered unplayable). In contrast, when the storage control state is "number-limited copying permitted", multiple copy processes and one final move process are possible for the output destination device via the IP interface output. For example, nine copy processes are performed, and one final move process is possible. At the final move process, the content must be rendered unplayable in the broadcast receiving device 40100. Here, the broadcast receiving device 40100 treats each of the several copy processes as a single copy process, and the content of each copy process is output with the copy control status set to "Move" in the protection process of the IP interface output.

In other words, the copy process for content in the storage control state "limited number of copies allowed" is performed by virtually setting up a state in which multiple copies of the content are stored in advance in the broadcast receiving device 40100, and moving each of the multiple stored contents via the IP interface output. Here, if multiple copies of the same content were actually stored in advance, the storage state would be inefficient in terms of the capacity of the storage unit. Therefore, in practice, only one copy of the content is stored, and the information on the number of copies stored is stored and managed in the storage unit or memory unit as management information. This is what is meant by "virtually" above.

Other than the points described above, the content protection control when outputting via an IP interface in the examples of combinations 10, 11, 12, and 13 in Figure 45 is the same as the examples of combinations 6, 7, 8, and 9 in Figure 45, so a repeated explanation will be omitted.

[Figure 45 Combinations 14 to 17]
The content protection control in each of the examples of combinations 14, 15, 16, and 17 in Fig. 45, i.e., when content in the storage control state of "temporary storage" is output through an IP interface, is almost the same as each of the examples of combinations 6, 7, 8, and 9 in Fig. 45. The difference is that content in the storage control state of "temporary storage" cannot be moved to another device (moving is not possible). In other respects, the content protection control in the case of output through an IP interface is the same as each of the examples of combinations 6, 7, 8, and 9 in Fig. 45, so a repeated explanation will be omitted.

According to the content output protection decision process when performing IP interface output in Figure 45 described above, when content is received together with reception control information 50100, the content is stored, and then the IP interface output is performed, it is possible to achieve content output protection that is well-balanced in terms of both output protection for the image quality of the content video and convenience for viewers of the broadcast content.

[Example of exception handling for the process in Figure 45]
As described above, an example of the process of determining whether or not to protect the output of content when outputting via an IP interface is described with reference to FIG.

However, it may be necessary to handle some exceptions that are not shown in Figure 45, and these are described below.

For example, if the content copy control descriptor itself or the "digital_recording_control_data" parameter of the content copy control descriptor is not transmitted as the reception control information 50100 due to some reason such as a transmission error, the broadcast receiving device 40100 cannot obtain the "digital_recording_control_data" parameter. In such a case, the broadcast receiving device 40100 can perform the storage control and content output protection decision process of FIG. 45 by regarding the state as the same as when the "digital_recording_control_data" parameter of the content copy control descriptor indicates "copying possible without restrictions." Specifically, one process from combinations 1 to 5 in FIG. 45 is selected while taking into account the other reception control information 50100.

Furthermore, if the content usage control descriptor itself or the "encryption_mode" parameter of the content usage control descriptor is not transmitted as the reception control information 50100 due to some reason such as a transmission error, the broadcast receiving device 40100 cannot obtain the "encryption_mode" parameter. In such a case, the broadcast receiving device 40100 can perform the storage control and content output protection decision process of FIG. 45 by regarding the state as the same as when the "encryption_mode" parameter of the content usage control descriptor indicates "no protection." Specifically, one process will be determined from combinations 1 and 6 to 17 in FIG. 45, taking into account the other reception control information 50100.

In addition, if the transfer characteristic (EOTF) identification information is not transmitted as the reception control information 50100 due to some reason such as a transmission error, the broadcast receiving device 40100 cannot acquire the transfer characteristic (EOTF) identification information. Even in such a case, in the example of FIG. 45, a determination can be made based on whether the content is HDR or SDR at the time of output after storage control, so there is no need for exceptional processing in this regard.

[Modification of the process in FIG. 45]
In the example of FIG. 45, when HDR content is protected by DTCP2 and output to the IP interface (combinations 2, 3, 6, 7, 10, 11, 14, and 15), the "HDR" Flag is output as 0. However, in all of these combinations, the "SDO" Flag indicates 0, and it is assumed that content conversion from HDR to SDR is possible. Then, in combinations 2, 3, 6, 7, 10, 11, 14, and 15 of FIG. 45, the "HDR" Flag may be controlled not to be output as output control information of DTCP2. In this case, in all of the combinations, the "HDR" Flag is not output, so that the IP interface output control of the broadcast receiving device 40100 is simplified.

In the example of FIG. 45, when content is output with DTCP2 protection, the control to output the "L2-Only" Flag as "0" is shown as the DTCP2 output control information. As described above, even if the output destination device is a DTCP2 compatible device, in consideration of the case where the DTCP2 compatible device further outputs to other devices, if the DTCP2 compatible device performs resolution conversion processing and transfer characteristic conversion processing to convert the content to 2K or less content with transfer characteristics of SDR, output with an L1 level content protection method such as DTCP1 is permitted. However, as a modified example of FIG. 45, in combinations (combinations 6, 7, 8, 10, 11, 12, 14, 15, and 16) in which content is output with No More Copies with DTCP2 protection, the control to output the "L2-Only" Flag as "1" may be replaced. In this example, content with No More Copies with DTCP2 protection is considered to be in higher need of content protection from the content provider, and content protection is further strengthened. Specifically, if the "L2-Only" Flag is set to "1" and the content is output from the destination DTCP2-compatible device to another device, even if resolution conversion processing or transfer characteristic conversion processing is performed, the content cannot be output if the destination device does not support an L2 level content protection method such as DTCP2. In other words, the content will always be subject to L2 level content protection after it is output from the IP interface of the broadcast receiving device 40100.

As described above, the broadcast communication system and broadcast receiving device 40100 of this embodiment make it possible to perform well-balanced content output protection control in terms of both output protection for the image quality of the content video and convenience for viewers of the broadcast content, depending on the control information related to the digital copy of the content and the control information related to the storage and output of the content, or the storage state of the content, and the resolution and transmission characteristics of the content video. In other words, the broadcast communication system and broadcast receiving device 40100 of this embodiment makes it possible to perform more suitable content output protection control.

Although examples of the embodiment of the present invention have been described above using Examples 1 to 5, the configurations for realizing the technology of the present invention are not limited to the above examples, and various modifications are possible. For example, it is possible to replace part of the configuration of one example with the configuration of another example, and it is also possible to add the configuration of another example to the configuration of one example. All of these fall within the scope of the present invention. Furthermore, the numerical values and messages that appear in the text and figures are merely examples, and the effect of the present invention will not be impaired even if different ones are used.

The functions of the present invention described above may be realized in part or in whole by hardware, for example by designing them as integrated circuits. They may also be realized by software, with a microprocessor unit or the like interpreting and executing an operating program that realizes each function. Hardware and software may also be used in combination.

The software that controls the broadcast receiving device 100 may be stored in the ROM 103 and/or storage (accumulation) unit 110 of the broadcast receiving device 100 beforehand at the time of product shipment. It may also be acquired via the LAN communication unit 121 from another application server 500 on the Internet 200 after product shipment. In addition, the software stored in a memory card, optical disk, etc. may be acquired via the expansion interface unit 124, etc.

The control and information lines shown in the diagram are those considered necessary for explanation, and do not necessarily represent all control and information lines on the product. In reality, it is safe to assume that almost all components are interconnected.

100, 800, 40100... Broadcast receiving device, 100a, 40100a... Antenna, 101, 801... Main control unit, 102, 802... System bus, 103, 803... ROM, 104, 804... RAM, 110, 810... Storage unit, 121, 821... LAN communication unit, 124, 824... Expansion interface unit, 125, 825, 40125... Digital interface unit, 131, 831 , 832 ... tuner/demodulation unit, 132 ... separation unit, 141 ... video decoder, 142 ... video color gamut conversion unit, 143 ... audio decoder, 144 ... character superimposition decoder, 145 ... subtitle decoder, 146 ... subtitle synthesis unit, 147 ... subtitle color gamut conversion unit, 151 ... data decoder, 152 ... cache unit, 153 ... application control unit, 154 ... browser unit, 155 ... application color gamut conversion unit, 15 6...sound source unit, 161, 861...video synthesis unit, 162, 862...monitor unit, 163, 863...video output unit, 164, 864...audio synthesis unit, 165, 865...speaker unit, 166, 866...audio output unit, 170, 870...operation input unit, 40181...transcode processing unit, 841...MMT decode processing unit, 842...MPEG2-TS decode processing unit, 200...Internet, 200r...routine data device, 200a...access point, 300t...radio tower, 300s...broadcast satellite (or communication satellite), 300...broadcast station server, 390c...filming equipment, 390e...editing equipment, 400...service provider server, 500...other application servers, 600...mobile telephone communication server, 600b...base station, 700...mobile information terminal, 40200...connection cable, 40300...monitor device.

Claims (1)

A method for protecting content in a receiving device of a transmission system in which a broadcasting station transmits a content of a broadcast program and the receiving device receives the content, comprising:
the transmission system does not transmit any of control information corresponding to an L2-Only flag of DTCP2, control information corresponding to an EI flag of DTCP2, control information corresponding to an HDR flag of DTCP2, and control information corresponding to an SDO flag of DTCP2 from a broadcasting station side to a receiving device;
A receiving step of receiving the content;
a storage step of storing the content received in the receiving step;
an output step of outputting the content stored in the storage step from an IP interface of the receiving device;
Equipped with
In the transmission system, the receiving device is a receiving device that does not acquire any of control information corresponding to an L2-Only flag of DTCP2, control information corresponding to an EI flag of DTCP2, control information corresponding to an HDR flag of DTCP2, and control information corresponding to an SDO flag of DTCP2;
The output state of the content stored in the storage step when outputting the content through the IP interface in the output step includes the following:
a state in which the content is protected by DTCP2 via the IP interface and outputted, and a state in which the content is protected by DTCP1 via the IP interface and outputted,
When the content is received in the receiving step, even if the content is transmitted in a state indicating that the content can be copied without restrictions and requires protection by encryption in the transmission system, even if the content is transmitted with protection designated for one-generation copying in the transmission system, or even if the content is transmitted with protection designated for number-limited copying in the transmission system, when the content stored in the storing step is protected by DTCP2 via the IP interface and output with a 1-bit L2-Only flag, EI flag, HDR flag, and SDO flag, each of which is DTCP2 control information, set, there is a state in which the L2-Only flag of DTCP2 is fixed to 0 and output,
In the output step, the content is output via the IP interface when an IP address of the receiving device and an IP address of an external device that is an output destination are in the same subnetwork,
When the content received in the receiving step is a content that has been transmitted in the transmission system with one-generation copy protection or a content that has been transmitted in the transmission system with number-limited copy protection, the content received in the receiving step is made playable only by the receiving device and is stored in the storing step,
The broadcast program transmitted by the transmission system and received in the receiving step is one of the broadcast programs in a service in which the start and end of the broadcast program are repeated.
How we protect your content.

Images