JP6633739B2 - Broadcast signal transmitting apparatus, broadcast signal receiving apparatus, broadcast signal transmitting method, and broadcast signal receiving method - Google Patents

Description

  The present invention relates to a broadcast signal transmitting device, a broadcast signal receiving device, and a method for transmitting and receiving a broadcast signal.

  With the end of transmission of analog broadcast signals, various techniques for transmitting and receiving digital broadcast signals have been developed. The digital broadcast signal may include a larger amount of video / audio data than the analog broadcast signal, and may further include various types of additional data in addition to the video / audio data.

  Digital broadcasting systems can provide UHD (Ultra High Definition) images, multi-channel (multi-channel) audio, and various additional services. However, for digital broadcasting, it is necessary to improve data transmission efficiency for a large amount of data transmission, robustness of a transmission / reception network, and network flexibility considering a mobile reception device.

  According to the objects of the present invention, the present invention effectively includes a next generation broadcasting service in an environment supporting a next generation hybrid broadcasting using a terrestrial broadcasting network and the Internet network, as included herein and described generally. A system that can be supported and a related signaling scheme are proposed.

  The present invention can effectively support next-generation broadcasting services in an environment that supports next-generation hybrid broadcasting using a terrestrial broadcasting network and the Internet network.

  The present invention can support a method of providing detailed signaling for service components included in a broadcast service.

  The present invention can support a method for efficiently providing various information such as 3D, caption, WCG, and HDR in a scheme for transmitting a broadcast service.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are included to provide a further understanding of the invention, and are included in and constitute a part of this application, illustrate embodiments of the invention, together with the detailed description, which describes the principles of the invention. .
FIG. 3 is a diagram illustrating a protocol stack according to an embodiment of the present invention. FIG. 4 is a diagram illustrating a service discovery procedure according to an embodiment of the present invention. FIG. 3 is a diagram illustrating an LLS (Low Level Signaling) table and an SLT (Service List Table) according to an embodiment of the present invention. FIG. 4 is a diagram illustrating a USB and an S-TSID transmitted by ROUTE according to an embodiment of the present invention. FIG. 5 is a diagram illustrating a USBD transmitted by an MMT according to an embodiment of the present invention. FIG. 4 is a diagram illustrating a link layer operation according to an embodiment of the present invention. FIG. 3 is a diagram illustrating an LMT (Link Mapping Table) according to an embodiment of the present invention. FIG. 3 is a diagram illustrating a structure of a broadcast signal transmitting apparatus for a next-generation broadcast service according to an embodiment of the present invention. FIG. 4 is a diagram illustrating a writing operation of a time interleaver according to an embodiment of the present invention. FIG. 4 is a block diagram illustrating an interleaving address generator including a main-PRBS generator and a sub-PRBS generator in each FFT mode included in a frequency interleaver according to an embodiment of the present invention. 1 is a diagram illustrating a hybrid broadcast receiving device according to one embodiment of the present invention. FIG. 3 is a diagram illustrating a general operation of a DASH-based adaptive streaming model according to an embodiment of the present invention. FIG. 3 is a diagram showing a block diagram of a receiver according to one embodiment of the present invention. FIG. 1 is a diagram illustrating an apparatus for creating and reproducing an HDR broadcast service of a meta database according to an embodiment of the present invention. FIG. 4 is a diagram illustrating an operation method of a receiver for HDR video according to an embodiment of the present invention. FIG. 4 is a diagram illustrating a post-processing unit according to an embodiment of the present invention. FIG. 5 is a diagram illustrating syntaxes of an SEI message and an HDR information descriptor according to an embodiment of the present invention. FIG. 5 is a diagram illustrating syntax of an SEI message and an HDR information descriptor according to an embodiment of the present invention. FIG. 5 is a diagram illustrating syntax of an SEI message and an HDR information descriptor according to an embodiment of the present invention. FIG. 5 is a diagram illustrating syntax of an SEI message and an HDR information descriptor according to an embodiment of the present invention. FIG. 4 is a diagram illustrating an embodiment of signaling metadata information by RAP. FIG. 4 is a diagram illustrating an embodiment of signaling metadata information by RAP. FIG. 9 is a diagram illustrating dynamic_range_mapping_info according to an embodiment of the present invention. FIG. 8 is a diagram illustrating a case where an SEI message defined in HEVC according to an embodiment of the present invention is referred to. FIG. 4 is a diagram illustrating an example of signaling an HDR_info descriptor via a PMT according to an embodiment of the present invention. FIG. 4 is a diagram illustrating an example of signaling an HDR_info descriptor via a PMT according to an embodiment of the present invention. FIG. 9 is a diagram illustrating an example of signaling an HDR_info descriptor via an EIT according to an embodiment of the present invention. FIG. 9 is a diagram illustrating an example of signaling an HDR_info descriptor via an EIT according to an embodiment of the present invention. FIG. 15 is a diagram illustrating HDR_info_descriptor () according to another embodiment of the present invention. FIG. 2 is a block diagram and a diagram showing an operation method of a receiver according to an embodiment of the present invention. FIG. 4 is a diagram illustrating an HDR information descriptor according to an embodiment of the present invention. FIG. 4 is a diagram illustrating an HDR information descriptor according to an embodiment of the present invention. FIG. 6 is a diagram illustrating a case where a region in a frame is divided by a feature set according to an embodiment of the present invention. FIG. 5 is a diagram illustrating HDR information and information signaling a feature set according to an embodiment of the present invention. FIG. 4 is a diagram illustrating a Spatial boundary field for specifying a spatial area according to an embodiment of the present invention. FIG. 6 is a diagram illustrating a Colorimetry boundary field for specifying a spatial area according to an embodiment of the present invention. FIG. 5 is a diagram illustrating a Luminance boundary field and a Luminance distribution boundary field for specifying a spatial area according to an embodiment of the present invention. FIG. 6 is a diagram illustrating a Color volume boundary field for specifying a spatial area according to an embodiment of the present invention. FIG. 2 is a block diagram illustrating a broadcast transmitter according to one embodiment of the present invention. 1 is a block diagram illustrating a broadcast receiver according to one embodiment of the present invention. FIG. 3 is a diagram illustrating a method of transmitting a broadcast signal including image quality improvement metadata according to an embodiment of the present invention. FIG. 3 is a diagram illustrating a method of receiving a broadcast signal including image quality improvement metadata according to an embodiment of the present invention.

  Preferred embodiments of the present invention will be specifically described, examples of which are shown in the accompanying drawings. The following detailed description with reference to the accompanying drawings does not limit embodiments in which the present invention can be implemented, but rather describes preferred embodiments of the present invention. The following detailed description includes details to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these details.

  Most of the terms used in the present invention are selected from general terms widely used in the art, but some of the terms may be arbitrarily selected by the applicant, and the meanings will be changed when necessary. This will be described in detail in the description. Therefore, the present invention should be understood based on the intended meaning of the term, and not on the simple name or meaning of the term.

  The present invention provides an apparatus and method for transmitting and receiving a broadcast signal for a next-generation broadcast service. Next-generation broadcasting services according to an embodiment of the present invention include terrestrial broadcasting services, mobile broadcasting services, UHDTV services, and the like. According to an embodiment of the present invention, a broadcast signal for a next-generation broadcast service can be processed by a non-Multiple Input Multiple Output (MIMO) or MIMO scheme. The non-MIMO scheme according to an embodiment of the present invention may include a multiple input single output (MISO) scheme, a single input single output (SISO) scheme, and the like. The present invention proposes a physical profile (or system) optimized to achieve the performance required for a particular application and to minimize receiver complexity.

  FIG. 1 is a diagram illustrating a protocol stack according to an embodiment of the present invention.

  The service can be delivered to the receiver via multiple layers. First, the transmitting side can generate service data. The delivery layer on the transmission side performs processing for transmission on the service data, and the physical layer encodes this into a broadcast signal and can transmit it via a broadcast network or broadband.

  Here, the service data can be generated in a format based on ISO BMFF (base media file format). ISO BMFF media files can be used in broadcast network / broadband delivery, media encapsulation and / or synchronization formats. Here, the service data is all data related to the service, and may be a concept including a service component constituting a linear service, signaling information for the service component, NRT (Non Real Time) data, other files, and the like. .

  The delivery layer will be described. The delivery layer can provide a transmission function for service data. The service data can be transmitted via a broadcast network and / or broadband.

  In broadcast service delivery via a broadcast network, there are two methods.

  In the first method, service data can be processed as MPU (Media Processing Units) based on MMT (MPEG Media Transport), and transmitted using MMTP (MMT protocol). In this case, the service data transmitted by the MMTP may include a service component for a linear service and / or service signaling information related thereto.

  According to the second method, service data is processed as a DASH segment based on MPEG DASH, and can be transmitted using a ROUTE (Real time Object delivery over Unidirectional Transport). In this case, the service data transmitted by the ROUTE protocol may include a service component for a linear service, service signaling information related thereto, and / or NRT data. That is, non-timed data such as NRT data and files can be transmitted using ROUTE.

  Data processed by the MMTP or ROUTE protocol can be processed as IP packets via a UDP / IP layer. In transmitting service data via a broadcast network, an SLT (Service List Table) can also be transmitted via a broadcast network via a UDP / IP layer. The SLT can be transmitted by being included in an LLS (Low Level Signaling) table. The SLT and LLS tables will be described later.

  IP packets may be processed as link layer packets at the link layer. The link layer can transmit data of various formats transmitted from the upper layer as a link layer packet, and then transmit the data to the physical layer. The link layer will be described later.

  In a hybrid service delivery, at least one service element can be transmitted through a broadband path. In the case of hybrid service delivery, data transmitted over broadband may include service components in the DASH format, service signaling information related thereto, and / or NRT data. These data may be processed via HTTP / TCP / IP and transmitted to a physical layer for broadband transmission via a link layer for broadband transmission.

  The physical layer processes data transmitted from a delivery layer (an upper layer and / or a link layer) and can transmit the processed data via a broadcast network or broadband. Detailed items regarding the physical layer will be described later.

  The service will be described. A service is a collection of service components that are presented to the user as a whole, components are of different media types, services are continuous or intermittent, and services are real-time or non-real-time. Alternatively, the real-time service may consist of a sequence of TV programs.

  Services can have different types. First, the service may be a linear audio / video service or an audio-only service that may have app-based enhancements. Second, the service may be an application-based service whose playback / configuration is controlled by the downloaded application. Third, the service may be an ESG (Electronic Service Guide) providing ESG (Electronic Service Guide). Fourth, an EA (Emergency Alert) service that provides emergency alert information may be used.

  When delivering a linear service without application-based enhancement over a broadcast network, the service component can be delivered in (1) one or more ROUTE sessions or (2) one or more MMTP sessions.

  When delivering a linear service with application-based enhancements over a broadcast network, the service component may be delivered in (1) one or more ROUTE sessions and (2) zero or more MMTP sessions. In this case, the data used for the application-based enhancement may be transmitted through the ROUTE session in the form of NRT data or other files. In one embodiment of the present invention, it may not be necessary to allow the linear service components (streaming media components) of one service to be transmitted simultaneously by two protocols.

  When delivering app-based services over a broadcast network, service components can be delivered in one or more ROUTE sessions. In this case, service data used for the application-based service can be transmitted through a ROUTE session in the form of NRT data or other files.

  Also, some service components of such services or some NRT data, files, etc. may be transmitted via broadband (hybrid service delivery).

  That is, in one embodiment of the present invention, a linear service component of one service can be transmitted according to the MMT protocol. In another embodiment of the present invention, a linear service component of one service may be transmitted by a ROUTE protocol. In another embodiment of the present invention, the linear service component and the NRT data (NRT service component) of one service may be transmitted by a ROUTE protocol. In another embodiment of the present invention, the linear service component of one service may be transmitted according to the MMT protocol, and the NRT data (NRT service component) may be transmitted according to the ROUTE protocol. In these embodiments, some service components of the service or some NRT data may be communicated over broadband. Here, data related to the application-based service or the application-based enhancement may be transmitted in the form of NRT data via a broadcast network based on ROUTE or via broadband. The NRT data can also be referred to as locally cached data.

  Each ROUTE session includes one or more LCT sessions that fully or partially convey the content components that make up the service. In streaming service delivery, an LCT session can carry individual components of a user service, such as an audio, video, or closed caption stream. Streaming media is formatted as a DASH segment.

  Each MMTP session includes one or more MMTP packet flows that carry MMT signaling messages or all or some content components. An MMTP packet flow may carry a component formatted as an MMT signaling message or MPU.

  For delivery of NRT user services or system metadata, LCT sessions carry file-based content items. These content files can consist of metadata such as continuous (timed) or discrete (non-timed) media components of the NRT service, service signaling, or ESG fragments. Delivery of system metadata such as service signaling or ESG fragments can also be done in the signaling message mode of MMTP.

  In the receiver, the tuner scans the frequency, but can detect the broadcast signal at a specific frequency. The receiver can extract the SLT and send it to its processing module. The SLT parser can parse the SLT, obtain the data and save it in the channel map. The receiver can obtain the SLT bootstrap information and transmit it to the ROUTE or MMT client. This allows the receiver to acquire and store the SLS. A USBD or the like may be obtained, which may be parsed by a signaling parser.

  FIG. 2 is a diagram illustrating a service discovery procedure according to an embodiment of the present invention.

  The broadcast stream transmitted by the physical layer broadcast signal frame can carry LLS (Low Level Signaling). The LLS data can be carried in the payload of an IP packet delivered to a well known IP address / port. This LLS can include an SLT depending on its type. LLS data can be formatted in the form of an LLS table. The first byte of each UDP / IP packet carrying LLS data may be the beginning of an LLS table. Unlike the illustrated embodiment, the IP stream transmitting the LLS data may be transmitted together with other service data via the same PLP.

  The SLT enables a receiver to generate a service list by a fast channel scan and provides access information for locating the SLS. The SLT includes bootstrap information, and the bootstrap information enables the receiver to obtain SLS (Service Layer Signaling) for each service. When the SLS, that is, the service signaling information is transmitted in the ROUTE, the bootstrap information may include a destination IP address and destination port information of the LCT channel carrying the SLS or the ROUTE session including the LCT channel. When the SLS is transmitted in the MMT, the bootstrap information may include destination IP address and destination port information of the MMTP session carrying the SLS.

  In the illustrated embodiment, the SLS of the service # 1 described by the SLT is transmitted via ROUTE, and the SLT includes bootstrap information (sIP1, dIP1, dPort1) for the ROUTE session including the LCT channel through which the SLS is transmitted. be able to. The SLS of the service # 2 described by the SLT is transmitted by the MMT, and the SLT may include bootstrap information (sIP2, dIP2, dPort2) for the MMTP session including the MMTP packet flow in which the SLS is transmitted.

  The SLS is signaling information describing characteristics of the service. The SLS provides information for acquiring the service and service components of the service, and receiver capability information for significantly reproducing the service. Can be included. Having separate service signaling for each service allows the receiver to obtain the appropriate SLS for the desired service without parsing all the SLS conveyed in the broadcast stream.

  When the SLS is transmitted according to the ROUTE protocol, the SLS may be transmitted via a dedicated LCT channel of the ROUTE session indicated by the SLT. Depending on the embodiment, this LCT channel may be an LCT channel identified as tsi = 0. In this case, the SLS can be a USB / USB (User Service Bundle Description / User Service Description), an S-TSID (Service-based Transport Session Session Descriptive Message or Descriptive Message, which can include Service-based Transport Sessions, Sessions, and Descriptive Actions).

  Here, USBD or USD is one of the SLS fragments, and can serve as a signaling hub that describes specific technical information of a service. The USBD may include service identification information, device capability information, and the like. The USBD may include reference information (URI reference) to other SLS fragments (S-TSID, MPD, etc.). That is, USBD / USD can refer to S-TSID and MPD respectively. In addition, the USBD may further include metadata information that enables the receiver to determine a transmission mode (broadcast network / broadband). Specific contents of USBD / USD will be described later.

  The S-TSID is one of the SLS fragments and can provide overall session description information for a transmission session carrying a service component of the service. The S-TSID may provide transmission session description information for a ROUTE session in which a service component of the service is transmitted and / or an LCT channel of the ROUTE session. The S-TSID can provide component acquisition information of a service component related to one service. The S-TSID can provide a mapping between the DASH representation of the MPD and the tsi of the service component. The component acquisition information of the S-TSID may be provided in the form of a tsi, an identifier of the associated DASH representation, and may or may not include a PLP ID depending on the embodiment. Using the component acquisition information, the receiver can collect audio / video components of one service and perform buffering and decoding of DASH media segments. The S-TSID may be referred by the USB as described above. The specific contents of the S-TSID will be described later.

  The MPD is one of the SLS fragments, and can provide a description regarding the DASH media presentation of the service. The MPD may provide a resource identifier for the media segment and provide context information in the media presentation for the identified resource. The MPD can describe DASH representations (service components) transmitted over the broadcast network and can describe additional DASH representations transmitted over broadband (hybrid delivery). The MPD may be referenced by a USBD, as described above.

  When the SLS is transmitted according to the MMT protocol, the SLS may be transmitted in a dedicated MMTP packet flow of the MMTP session indicated by the SLT. According to an embodiment, the packet_id of the MMTP packet carrying the SLS may have a value of 00. In this case, the SLS may include a USB / USD and / or MMT Package (MP) table.

  Here, the USBD is one of the SLS fragments, and can describe specific technical information of the service similarly to that in the ROUTE. The USBD here can also include reference information (URI reference) to other SLS fragments. The MMT USBD can refer to the MP table for MMT signaling. Depending on the embodiment, the USB of the MMT may also include reference information to the S-TSID and / or the MPD. Here, the S-TSID may be for NRT data transmitted by the ROUTE protocol. This is because even when the linear service component is transmitted by the MMT protocol, the NRT data can be transmitted by the ROUTE protocol. MPD may be for service components transmitted over broadband in hybrid service delivery. Specific contents of the USB of the MMT will be described later.

  The MP table is an MMT signaling message for the MPU component, and can provide overall session description information for an MMTP session carrying a service component of the service. In addition, the MP table may include a description for an asset transmitted through the MMTP session. The MP table is streaming signaling information for the MPU component, and can provide a list of assets corresponding to one service and location information (component acquisition information) of these components. The specific contents of the MP table may be in a form defined by the MMT or in a modified form. The asset as referred to herein is a multimedia data entity, and can mean a data entity associated with one unique ID and used to generate one multimedia presentation. An asset may correspond to a service component that constitutes one service. A streaming service component (MPU) corresponding to a desired service can be accessed using the MP table. The MP table may be referenced by the USBD as described above.

  Other MMT signaling messages can also be defined. Such MMT signaling messages can describe additional information related to the MMTP session or service.

  A ROUTE session is identified by a source IP address, a destination IP address, and a destination port number. An LCT session is identified by a unique transport session identifier (TSI) within the parent ROUTE session. An MMTP session is identified by a destination IP address and a destination port number. An MMTP packet flow is identified by a unique packet_id within a parent MMTP session.

  In the case of ROUTE, an S-TSID, USBD / USD, MPD, or an LCT session transmitting these can be called a service signaling channel. In the case of MMTP, USBD / UD, MMT signaling messages, or packet flows carrying these can be referred to as service signaling channels.

  Unlike the illustrated embodiment, one ROUTE or MMTP session may be carried by multiple PLPs. That is, one service may be transmitted via one or more PLPs. Unlike the illustration, the components making up one service may be conveyed in separate ROUTE sessions, depending on the embodiment. Further, according to an embodiment, components constituting one service may be transmitted in a separate MMTP session. According to an embodiment, components constituting one service may be separately transmitted to a ROUTE session and an MMTP session. Although not shown, components constituting one service may be transmitted (hybrid delivery) via broadband.

  FIG. 3 is a diagram illustrating an LLS (Low Level Signaling) table and an SLT (Service List Table) according to an embodiment of the present invention.

  One embodiment (t3010) of the illustrated LLS table may include information according to an LLS_table_id field, a provider_id field, an LLS_table_version field, and / or an LLS_table_id field.

  The LLS_table_id field may identify the type of the LLS table, and the provider_id field may identify a service provider associated with the service signaled by the LLS table. Here, the service provider is a broadcaster that uses all or a part of the broadcast stream, and the provider_id field can identify one of a plurality of broadcasters that use the broadcast stream. The LLS_table_version field can provide version information of the LLS table.

  Depending on the value of the LLS_table_id field, the LLS table includes the above-described SLT, RRT (Rating Region Table) including information related to content advisory rating (System Advisory Rating), SystemTime information that provides information related to system time, and emergency information. It may include one of CAP (Common Alert Protocol) messages providing information related to the alert. Depending on the embodiment, other information may be included in the LLS table.

  One embodiment of the illustrated SLT (t3020) may include a $ bsid attribute, a $ sltCapabilities attribute, a sltInetUrl element and / or a Service element. Each field may be omitted depending on the value of the illustrated Use column, or a plurality of fields may be present.

  The $ bsid attribute may be an identifier of a broadcast stream. The $ sltCapabilities attribute can provide the capability information necessary to decode and significantly play back all services described by the SLT. The sltInetUrl element may provide base URL information used to obtain ESG or service signaling information for the service of the SLT via broadband. The sltInetUrl element may further include a $ urlType attribute, which may indicate a type of data obtained from the URL.

  The Service element is an element including information on a service described by the SLT, and a Service element may exist for each service. Service elements, @ serviceId attribute, @ sltSvcSeqNum attribute, @ protected attribute, @ majorChannelNo attribute, @ minorChannelNo attribute, @ serviceCategory attribute, @ shortServiceName attribute, @ hidden attributes, @ broadbandAccessRequired attribute, @ svcCapabilities attribute, BroadcastSvcSignaling element and / or svcInetUrl Elements can be included.

  The $ serviceId attribute is an identifier of the service, and the $ sltSvcSeqNum attribute can indicate a sequence number of SLT information for the service. The $ protected attribute may indicate whether at least one service component required for significant reproduction of the service is protected. The $ majorChannelNo attribute and $ minorChannelNo attribute can indicate the major channel number and the minor channel number of the service, respectively.

  The $ serviceCategory attribute can indicate a category of the service. The service category includes a linear A / V service, a linear audio service, an application-based service, an ESG service, an EAS service, and the like. The $ shortServiceName attribute can provide the short name of the service. The $ hidden attribute may indicate whether the service is a service for testing or proprietary use. The $ broadbandAccessRequired attribute may indicate whether broadband access is required for significant playback of the service. The $ svcCapabilities attribute can provide capability information necessary for decoding and significant playback of the service.

  The BroadcastSvcSignaling element may provide information related to broadcast signaling of the service. This element can provide information such as a location, a protocol, and an address for signaling via the broadcast network of the service. Details will be described later.

  The svcInetUrl element can provide URL information for accessing signaling information for the service via broadband. The sltInetUrl element may further include a $ urlType attribute, which may indicate a type of data obtained from the URL.

  The BroadcastSvcSignaling element described above includes a \ slsProtocol attribute, a \ slsMajorProtocolVersion attribute, a \ slsMinorProtocolVersion attribute, a \ slsPlpId attribute, a \ ssDlpSurse attribute, a \ ssDestinationRespondA, and a \ ssDestinationIpAddress.

  The $ slsProtocol attribute may indicate a protocol used to transmit the SLS of the service (ROUTE, MMT, etc.). The $ slsMajorProtocolVersion attribute and $ slsMinorProtocolVersion attribute may indicate a major version number and a minor version number of a protocol used for transmitting the SLS of the service, respectively.

  The $ slsPlpId attribute may provide a PLP identifier that identifies a PLP that carries the SLS of the service. Depending on the embodiment, this field may be omitted, and the PLP information to which the SLS is transmitted may be confirmed by combining information in the LMT described later and bootstrap information of the SLT.

  The $ slsDestinationIpAddress attribute, the $ slsDestinationUdPort attribute, and the $ slsSourceIpAddress attribute can indicate a destination IP address, a destination UDP port, and a source IP address of a transmission packet transmitting the SLS of the service, respectively. These can identify the transmission session (ROUTE session or MMTP session) over which the SLS is communicated. These may be included in the bootstrap information.

  FIG. 4 is a diagram illustrating a USB and an S-TSID transmitted by ROUTE according to an embodiment of the present invention.

  One embodiment of the illustrated USBD (t4010) may have a bundleDescription root element. The bundleDescription root element can have a userServiceDescription element. The userServiceDescription element may be an instance for one service.

  The userServiceDescription element includes a $ globalServiceID attribute, a $ serviceId attribute, a $ serviceStatus attribute, a $ fullMPDUri attribute, a $ sSIDUri attribute, a name element, a serviceLanguage element that can be a serviceLanguage element, and a capability / deployment that includes a serviceLanguage element. Each field may be omitted depending on the value of the illustrated Use column, or a plurality of fields may be present.

  The $ globalServiceID attribute is a globally unique identifier of the service, and may be used in linking with the ESG data (Service @ globalServiceID). The $ serviceId attribute is a reference corresponding to the corresponding service entry of the SLT, and may be the same as the service ID information of the SLT. The $ serviceStatus attribute can indicate the status of the service. This field may indicate whether the service is in an active state or an inactive state.

  The $ fullMPDUri attribute can refer to the MPD fragment of the service. As described above, the MPD can provide a playback description for a service component transmitted via a broadcast network or broadband. The ＠sTSIDUri attribute can refer to the S-TSID fragment of the service. The S-TSID may provide parameters related to accessing a transmission session carrying the service, as described above.

  The name element can provide the name of the service. This element may further include a $ lang attribute, but this field may indicate the language of the name provided by the name element. The serviceLanguage element may indicate an available language of the service. That is, this element can list languages in which the service can be provided.

  The capabilityCode element can indicate receiver-side capability or capability group information necessary for significantly reproducing the service. These information may be compatible with a capability information format provided from a service announcement.

  The deliveryMethod element can provide transmission-related information for content accessed via a broadcast network or broadband of the service. The deliveryMethod element may include a broadcastAppService element and / or a unicastAppService element. Each of these elements can have a basePattern element as a sub-element.

  The broadcastAppService element may include transmission-related information for a DASH representation transmitted via a broadcast network. The DASH representation may include media components that span all periods of the service media presentation.

  The basePattern element of this element can indicate the character pattern that the receiver uses to match the segment URL. This can be used by a DASH client to request a segment of the relevant representation. Being matched can imply that the corresponding media segment is transmitted over the broadcast network.

  The unicastAppService element may include transmission-related information for a DASH representation transmitted over broadband. This DASH representation may include media components that span all periods of the corresponding service media presentation.

  The basePattern element of this element can indicate the character pattern that the receiver uses to match the segment URL. This can be used by a DASH client to request a segment of the relevant representation. Being matched can imply that the media segment is transmitted over broadband.

  One embodiment of the S-TSID shown (t4020) may have an S-TSID root element. The S-TSID root element may include a $ serviceId attribute and / or an RS element. Each field may be omitted depending on the value of the illustrated Use column, or a plurality of fields may be present.

  The $ serviceId attribute is an identifier of the service, and can refer to the USBD / USD service. The RS element can describe information on a ROUTE session to which a service component of the service is transmitted. Depending on the number of such ROUTE sessions, there may be a plurality of this element. The RS element may further include a $ bsid attribute, a $ sIpAddr attribute, a $ dIpAddr attribute, a $ port attribute, a $ PLPID attribute, and / or a LS element.

  The $ bsid attribute may be an identifier of a broadcast stream in which a service component of the service is transmitted. If this field is omitted, the default broadcast stream may be a broadcast stream that includes a PLP that carries the SLS of the service. The value of this field may be the same value as the SLT $ bsid attribute.

  The $ sIpAddr attribute, the $ dIpAddr attribute, and the $ dport attribute may indicate the source IP address, destination IP address, and destination UDP port of the corresponding ROUTE session, respectively. If this field is omitted, the default value is the source IP address, destination IP address and destination UDP port of the current ROUTE session carrying the corresponding SLS, ie carrying the corresponding S-TSID. It may be a value. This field may not be omitted for another ROUTE session that is not the current ROUTE session and transmits the service component of the service.

  $ PLPID attribute may indicate PLP ID information of the corresponding ROUTE session. If this field is omitted, the default value may be the PLP ID value of the current PLP to which the corresponding S-TSID is transmitted. In some embodiments, this field may be omitted, and the PLP ID information of the corresponding ROUTE session may be confirmed by combining the information in the LMT described later and the IP address / UDP port information of the RS element.

  The LS element can describe information on an LCT channel to which a service component of the service is transmitted. Depending on the number of such LCT channels, there may be a plurality of this element. The LS element may include a $ tsi attribute, $ PLPID attribute, $ bw attribute, $ startTime attribute, $ endTime attribute, SrcFlow element and / or RepairFlow element.

  The @tsi attribute may indicate tsi information of the corresponding LCT channel. Thereby, the LCT channel to which the service component of the service is transmitted can be identified. The $ PLPID attribute may indicate PLP ID information of the corresponding LCT channel. In some embodiments, this field may be omitted. The ＠bw attribute may indicate the maximum bandwidth of the corresponding LCT channel. The $ startTime attribute may indicate the start time of the corresponding LCT session, and the $ endTime attribute may indicate the end time of the corresponding LCT channel.

  The SrcFlow element can describe the source flow of ROUTE. The ROUTE source protocol is used for transmitting the delivery object, and can establish at least one source flow within one ROUTE session. These source flows can communicate the associated objects as object flows.

  The RepairFlow element can describe a repair flow of ROUTE. The delivery object delivered by the source protocol may be protected by Forward Error Correction (FEC), but the repair protocol may define an FEC framework (framework) that enables such FEC protection.

  FIG. 5 is a diagram illustrating a USBD transmitted by MMT according to an embodiment of the present invention.

  One embodiment of the USBD shown can have a bundleDescription root element. The bundleDescription root element can have a userServiceDescription element. The userServiceDescription element may be an instance for one service.

  The userServiceDescription element can include a $ globalServiceID attribute, a $ serviceId attribute, a Name element, a serviceLanguage element, a contentAdvisoryRating element, a Channel element, an mpuComponent element, and a ComponentComponent element, and a routeComponent element. Each field may be omitted depending on the value of the illustrated Use column, or a plurality of fields may be present.

  The $ globalServiceID attribute, the $ serviceId attribute, the Name element and / or the serviceLanguage element may be the same as the corresponding field of the USBD transmitted in the above-described ROUTE. The contentAdvisoryRating element may indicate a content advisory rating of the service. These pieces of information may be compatible with a content advisory rating information format provided from a service announcement. The Channel element may include information related to the service. The details of this element will be described later.

  The mpuComponent element can provide a description of a service component transmitted as an MPU of the service. This element can further include a $ mmtPackageId attribute and / or a $ nextMmtPackageId attribute. The $ mmtPackageId attribute can refer to the MMT package (Package) of the service component transmitted as the MPU of the service. The $ nextMmtPackageId attribute can refer to the MMT package that is used next to the MMT package that the $ mmtPackageId attribute references in time. The MP table can be referred by using the information of this element.

  The routeComponent element may include a description related to a service component of the service transmitted in the route. Even when the linear service component is transmitted by the MMT protocol, the NRT data may be transmitted by the ROUTE protocol as described above. This element can describe information about such NRT data. The details of this element will be described later.

  The “broadbandComponent” element may include a description related to a service component of the service transmitted over broadband. In hybrid service delivery, some service components or other files of one service may be transmitted via broadband. This element can describe information about such data. This element can further include a $ fullMPDUri attribute. This attribute can refer to the MPD that describes the service components that are transmitted over broadband. In addition to hybrid service delivery, this element may be used to support handoff between a broadcast network and broadband when a broadcast signal becomes weak due to traveling in a tunnel or the like. When the broadcast signal becomes weak, the service component is obtained via the broadband, but when the broadcast signal becomes strong again, the service component is obtained via the broadcast network, and continuity of service can be ensured.

  The ComponentInfo element can include information on a service component of the service. Depending on the number of service components of the service, there may be a plurality of this element. This element can describe information such as the type, role, name, identifier, and presence / absence of protection of each service component. Detailed information of this element will be described later.

  The above-mentioned Channel element may further include a $ serviceGenre attribute, a $ serviceIcon attribute, and / or a ServiceDescription element. The $ serviceGenre attribute indicates the genre of the service, and the $ serviceIcon attribute may include URL information of an icon representing the service. The ServiceDescription element provides a service description of the service, and may further include a $ serviceDescrText attribute and / or a $ serviceDescrLang attribute. Each of these attributes can indicate the text of the service description and the language used for the text.

  The routeComponent element described above may include a $ sSSIDUri attribute, a $ sTSIDDestinationIpAddress attribute, a $ sTSIDDestinationUdPort attribute, a $ sTSIDSourceIpAddress attribute, a $ sTSIDMajorProtocolVersion attribute, and / or a Vsr.

  The ＠sTSIDUri attribute can refer to an S-TSID fragment. This field may be the same as the corresponding field of the USB transmitted by the ROUTE. This S-TSID can provide access-related information for the service component transmitted in ROUTE. This S-TSID may be present for NRT data carried by the ROUTE protocol in situations where the linear service component is carried by the MMT protocol.

  The $ sTSIDDestinationIpAddress attribute, the $ sTSIDDestinationUdPort attribute, and the $ sTSIDSourceIpAddress attribute can indicate the destination IP address, destination UDP port, and source IP address of the transmission packet carrying the S-TSID, respectively. That is, these fields can identify the transmission session (MMTP session or ROUTE session) that carries the S-TSID described above.

  The ＠sTSIDMajorProtocolVersion attribute and the ＴＳsTSIDMinorProtocolVersion attribute may indicate a major version number and a minor version number of a transmission protocol used for transmitting the S-TSID.

  The ComponentInfo element described above may further include a $ componentType attribute, a $ componentRole attribute, a $ componentProtectedFlag attribute, a $ componentId attribute, and / or a $ componentName attribute.

  The $ componentType attribute can indicate the type of the component. For example, this attribute can indicate whether the component is an audio, video, or closed caption component. The $ componentRole attribute can indicate the role of the component. For example, if the component is an audio component, this attribute can indicate whether the component is main audio, music, commentary, or the like. If the corresponding component is a video component, it can indicate whether the component is a primary video. If the component is a closed caption component, it can indicate whether it is a normal caption or an easy reader type.

  The $ componentProtectedFlag attribute can indicate whether the service component is protected, eg, encrypted. The $ componentId attribute can indicate an identifier of the service component. The value of this attribute may be the same value as asset_id (asset ID) of the MP table corresponding to this service component. The $ componentName attribute can indicate the name of the service component.

  FIG. 6 is a diagram illustrating a link layer operation according to an embodiment of the present invention.

  The link layer may be a layer between the physical layer and the network layer. The transmitting side can transmit data from the network layer to the physical layer, and the receiving side can transmit data from the physical layer to the network layer (t6010). The purpose of the link layer is to abstract all input packet types into one format for processing by the physical layer, and to provide flexibility and future scalability for input packet types that have not yet been defined. Can be guaranteed. In addition, the link layer may provide an option to compress unnecessary information in a header of an input packet so that input data is transmitted efficiently. Operations such as link layer overhead reduction and encapsulation are called a link layer protocol, and packets generated by the protocol can be called link layer packets. The link layer may have a function such as packet encapsulation, overhead reduction, and / or signaling transmission (Signaling Transmission).

  On a sender basis, the link layer (ALP) can perform an overhead reduction process on incoming packets and then encapsulate them into link layer packets. In some embodiments, the link layer may encapsulate the link layer packet without performing the overhead reduction process. Through the use of the link layer protocol, the overhead for data transmission on the physical layer can be greatly reduced, and the link layer protocol according to the present invention can provide IP overhead reduction and / or MPEG-2TS overhead reduction. .

  As shown, when an IP packet is input as an input packet (t6010), the link layer may perform an IP header compression, adaptation, and / or encapsulation process in order. In some embodiments, some steps may be omitted. First, the RoHC module compresses an IP packet header to reduce unnecessary overhead, extracts context information through an adaptation process, and transmits the context information out of band. The IP header compression and adaptation process may be collectively referred to as IP header compression. Thereafter, the IP packet can be encapsulated into a link layer packet through an encapsulation process.

  When an MPEG2 TS packet is input as an input packet, the link layer may sequentially perform an overhead reduction and / or an encapsulation process on the TS packet. In some embodiments, some steps may be omitted. In overhead reduction, the link layer may provide for sync byte removal, null packet removal and / or common header removal (compression). The sync byte removal can provide one byte of overhead reduction per TS packet. The null packet may be deleted by a method that can be reinserted on the receiving side. Further, information common between consecutive headers may be deleted (compressed) by a method that can be recovered on the receiving side. Part of each overhead reduction process may be omitted. Thereafter, the TS packet can be encapsulated into a link layer packet through an encapsulation process. The link layer packet structure for the encapsulation of TS packets may be different from other types of packets.

  First, a description will be given of IP Header Compression.

  IP packets have a fixed header format, but some information needed in a communication environment may not be needed in a broadcast environment. Link layer protocols can provide a mechanism to reduce broadcast overhead by compressing the header of IP packets.

  IP header compression can include a header compressor / decompressor and / or adaptation module. The IP header compressor (RoHC compressor) can reduce the size of each IP packet header based on the RoHC scheme. Thereafter, the adaptation module may extract the context information and generate signaling information from each packet stream. The receiver may parse the signaling information associated with the packet stream and attach context information to the packet stream. The RoHC decompressor can recover the packet header and reconstruct the original IP packet. Hereinafter, IP header compression may mean only IP header compression by a header compressor, or may mean a concept combining IP header compression and an adaptation process by an adaptation module. The same applies to decompressing.

  Hereinafter, the adaptation will be described.

  For transmissions on a unidirectional link, if the receiver does not have context information, the decompressor cannot recover the received packet header until it has received the full context. This may cause a channel change delay and a turn-on delay. Therefore, the configuration parameter and the context information between the compressor and the decompressor can be transmitted out of band by using the adaptation function. An adaptation function may generate link layer signaling using context information and / or configuration parameters. The adaptation function may periodically transmit the link layer signaling via each physical frame using the previous configuration parameters and / or context information.

  Context information is extracted from the compressed IP packet, and various methods can be used depending on the adaptation mode.

  Mode # 1 is a mode in which no operation is performed on the compressed packet stream, and can be said to be a mode in which the adaptation module operates as a buffer.

  The mode # 2 may be a mode for detecting an IR packet from a compressed packet stream and extracting context information (static chain). After extraction, the IR packets are converted to IR-DYN packets, and the IR-DYN packets can be transmitted in the same order in the packet stream instead of the original IR packets.

  Mode # 3 (t6020) may be a mode in which IR and IR-DYN packets are detected from the compressed packet stream and context information is extracted. A static chain and a dynamic chain can be extracted from an IR packet, and a dynamic chain can be extracted from an IR-DYN packet. After extraction, the IR and IR-DYN packets can be converted to general compressed packets. The converted packets can be transmitted in the same order in the packet stream instead of the original IR and IR-DYN packets.

  In each mode, the remaining packets after extracting the context information can be transmitted by encapsulation according to the link layer packet structure for the compressed IP packet. The context information is link layer signaling, and can be transmitted by encapsulation according to a link layer packet structure for the signaling information.

  The extracted context information may be included in an RHC (RoHC-U Description Table) and transmitted separately from the RoHC packet flow. The context information can be transmitted on a specific physical data path together with other signaling information. The specific physical data path may refer to one of general PLPs according to the embodiment, a PLP to which LLS (Low Level Signaling) is transmitted, and a designated PLP. Which may mean an L1 signaling path. Here, the RDT may be signaling information including context information (static chain and / or dynamic chain) and / or information related to header compression. According to an embodiment, the RDT may be transmitted each time context information changes. In some embodiments, the RDT may be transmitted in every physical frame. In order to transmit the RDT in each physical frame, the previous RDT may be re-used.

  Before acquiring the packet stream, the receiver can first select the first PLP to acquire signaling information such as SLT, RDT, LMT, and so on. When the receiver obtains the signaling information, the receiver can obtain a mapping between service-IP information-context information-PLP by combining them. That is, the receiver can know what service is transmitted by which IP stream, what PLP is transmitted by what PLP, and the like. Can be obtained. The receiver can select and decode the PLP that carries a particular packet stream. The adaptation module can parse the context information and combine it with the compressed packet. This allows the packet stream to be restored, which can be transmitted to the RoHC decompressor. Thereafter, decompression can begin. At this time, the receiver detects the IR packet according to the adaptation mode and starts decompression from the first received IR packet (mode 1), or detects the IR-DYN packet to start the decompression. Decompression may be started from the received IR-DYN packet (mode 2) or decompression may be started from any general compressed packet (mode 3).

  Hereinafter, the packet encapsulation will be described.

  The link layer protocol can encapsulate all types of input packets, such as IP packets, TS packets, etc. into link layer packets. This allows the physical layer to process only one packet format independently of the network layer protocol type (here, MPEG-2TS packets are considered as a type of network layer packet). Each network layer packet or input packet is transformed into a generic link layer packet payload.

  In the packet encapsulation process, segmentation can be used. If the network layer packet is too large to be processed by the physical layer, the network layer packet can be divided into two or more segments. The link layer packet header may include fields for performing splitting on the transmitting side and performing recombining on the receiving side. Each segment can be encapsulated in the link layer packet in the same order as the original location.

  Concatenation may be used in the packet encapsulation process. Chaining may be performed if the network layer packet is small enough that the payload of the link layer packet includes a plurality of network layer packets. The link layer packet header may include fields for performing chaining. In the case of chaining, each input packet can be encapsulated in the link layer packet payload in the same order as the original input order.

  The link layer packet may include a header and a payload, and the header may include a base header, an additional header, and / or an optional header. The additional header can be further added depending on circumstances such as chaining or splitting, but the additional header can include necessary fields depending on the situation. In addition, an optional header can be further added for transmitting additional information. Each header structure may already be defined. As described above, when the input packet is a TS packet, a different link layer header structure from other packets can be used.

  Hereinafter, link layer signaling will be described.

  Link layer signaling can operate at a lower level than the IP layer. On the receiving side, link layer signaling can be acquired before IP level signaling such as LLS, SLT, and SLS. Therefore, link layer signaling can be obtained before session establishment (establishment).

  The link layer signaling may include internal link layer signaling and external link layer signaling. The internal link layer signaling may mean signaling information generated in a link layer. The above-described RDT or LMT described below corresponds to this. The external link layer signaling may be an external module or an external protocol, or signaling information transmitted from an upper layer. The link layer may transmit the link layer signaling by encapsulating the link layer packet. A link layer packet structure (header structure) for link layer signaling can be defined, and this structure allows for encapsulation of link layer signaling information.

  FIG. 7 is a diagram illustrating an LMT (Link Mapping Table) according to an embodiment of the present invention.

  The LMT may provide a list of higher layer sessions carried on the PLP. Also, the LMT can provide additional information for processing a link layer packet carrying an upper layer session. Here, the upper layer session can also be referred to as multicast. From the LMT, information regarding what IP stream and what transmission session is being transmitted via a specific PLP can be obtained. Conversely, information about which PLP a particular transmission session is conveyed can also be obtained.

  LMT can carry any PLP identified as carrying LLS. Here, the PLP to which the LLS is transmitted can be identified by the LLS flag of the L1 detail signaling information of the physical layer. The LLS flag may be a flag field indicating whether or not the LLS is transmitted to each PLP by the PLP. Here, the L1 detail signaling information may correspond to PLS2 data described later.

  That is, the LMT may be delivered on the same PLP along with the LLS. Each LMT can describe a mapping between a PLP and an IP address / port, as described above. As described above, the LLS may include an SLT, and the IP address / port described by the LMT may be associated with any service described by the SLT carried on the same PLP as the LMT. ) It may be an IP address / port.

  According to the embodiment, it is possible to confirm information on which PLP the specific transmission session indicated by the SLT or SLS is transmitted by using the PLP identifier information in the SLT or SLS described above.

  According to another embodiment, the PLP identifier information in the SLT, the SLS, and the like described above is omitted, and the PLP information for the specific transmission session indicated by the SLT, the SLS can be confirmed by referring to information in the LMT. In this case, the receiver can identify the desired PLP by combining the LMT with other IP level signaling information. Also in this embodiment, the PLP information in the SLT, the SLS, etc. is not omitted and may remain in the SLT, the SLS, etc.

  The LMT according to the embodiment of the figure may include a signaling_type field, a PLP_ID field, a num_session field, and / or information on each session. In the LMT of the embodiment shown in the figure, an IP stream transmitted by the PLP is described for one PLP. However, according to the embodiment, a PLP loop is added to the LMT, and information on a plurality of PLPs is described. May be described. In this case, as described above, the LMT can describe, in the PLP loop, the PLP for every IP address / port associated with any service described by the SLT conveyed therewith.

  The signaling_type field may indicate a type of signaling information transmitted by the table. The value of the signaling_type field for LMT can be set to 0x01. The signaling_type field may be omitted. The PLP_ID field can identify a target PLP to be described. If a PLP loop is used, each PLP_ID field can identify a respective target PLP. The PLP_ID field may be included in the PLP loop. A PLP_ID field described later is an identifier for one PLP in the PLP loop, and a field described below may be a field for the PLP.

  The num_session field may indicate the number of upper layer sessions transmitted by the PLP identified by the PLP_ID field. Depending on the number indicated by the num_session field, information on each session may be included. This information may include a src_IP_add field, dst_IP_add field, src_UDP_port field, dst_UDP_port field, SID_flag field, compressed_flag field, SID field and / or context_id field.

  The src_IP_add field, dst_IP_add field, src_UDP_port field, and dst_UDP_port field are a source IP address, a destination IP address, a source UDP port, and a destination for the transmission session among upper layer sessions transmitted by the PLP identified by the PLP_ID field. The UDP port can be indicated.

  The SID_flag field may indicate whether a link layer packet transmitting the transmission session has an SID field in an optional header. A link layer packet carrying an upper layer session may have an SID field in its optional header, and the value of the SID field may be the same as the SID field in the LMT described below.

  The compressed_flag field may indicate whether header compression has been applied to the data of the link layer packet transmitting the transmission session. Further, the presence or absence of a context_id field described later may be determined based on the value of this field. If header compression is applied (compressed_flag = 1), an RDT may be present, and the PLP ID field of the RDT may have the same value as the PLP_ID field associated with this compressed_flag field.

  The SID field may indicate a SID (substream ID) for a link layer packet transmitting the transmission session. This link layer packet may include an SID having the same value as the actual SID field in the optional header. Accordingly, the receiver does not need to parse the entire link layer packet, and can filter the link layer packet using the LMT information and the SID information of the link layer packet header.

  The context_id field may provide a reference to a CID (context id) in the RDT. The CID information of the RDT may indicate a context ID for the corresponding compressed IP packet stream. The RDT can provide context information for a corresponding compressed IP packet stream. This field may associate the RDT with the LMT.

  In the signaling information / table embodiment of the present invention described above, each field, element, and attribute may be omitted or replaced with another field. Depending on the embodiment, additional fields, elements, and attributes may be added. Is also good.

  In one embodiment of the present invention, a service component of one service can be transmitted through a plurality of ROUTE sessions. In this case, the SLS can be obtained using the bootstrap information of the SLT. S-TSID and MPD can be referred to using the SLS USBD. The S-TSID can describe not only the ROUTE session carrying the SLS, but also the transmission session description information for another ROUTE session carrying the service component. Accordingly, all service components transmitted in a plurality of ROUTE sessions can be collected. Such a matter can be similarly applied to a case where a service component of one service is transmitted through a plurality of MMTP sessions. For reference, one service component may be used simultaneously by multiple services.

  In another embodiment of the present invention, bootstrapping for the ESG service may be performed on a broadcast network or broadband. An ESG can be obtained via broadband, and URL information of the SLT can be used. ESG information or the like can be requested from this URL.

  In another embodiment of the present invention, any one service component of one service can be transmitted over a broadcast network, and any other service component can be transmitted over a broadband (hybrid). The S-TSID describes a component transmitted in a broadcast network so that a ROUTE client can obtain a desired service component. Further, the USBD has base pattern information, and can describe which segment (which component) is transmitted by which path. Thus, the receiver can use this to identify the segment to request from the broadband server and the segment to find from the broadcast stream.

  In another embodiment of the present invention, scalable coding for a service may be performed. The USBD can have all the capability information needed to render the service. For example, when one service is provided in HD or UHD, the capability information of the USB may have an “HD or UHD” value. The receiver knows from the MPD which components must be played in order to render a UHD or HD service.

  According to another embodiment of the present invention, a TOI field of an LCT packet transmitted on an LCT channel transmitting an SLS identifies which SLS fragment (USBD, S-TSID, MPD, etc.) the LCT packet transmits. can do.

  In another embodiment of the present invention, an application component used for application-based enhancement / application-based service may be transmitted as an NRT component over a broadcast network or over a broadband. The application signaling for the application-based enhancement may be performed by an AST (Application Signaling Table) transmitted together with the SLS. In addition, an event, which is signaling for an operation performed by the application, is transmitted in the form of an EMT (Event Message Table) together with the SLS, is signaled in the MPD, or is in-band in the box form in the DASH representation. May be signaled. AST, EMT, etc. may be transmitted via broadband. An application-based enhancement can be provided using the collected application components and such signaling information.

  In another embodiment of the present invention, a CAP message for an emergency alert may be provided in the LS table described above. Rich Media content for emergency alerts can also be provided. The reach media can be signaled by a CAP message, and if reach media is present, it can be provided as an EAS service signaled by the SLT.

  In another embodiment of the present invention, the linear service component can be transmitted via a broadcast network according to the MMT protocol. In this case, NRT data (for example, an application component) for the service can be transmitted over a broadcast network by the ROUTE protocol. In addition, data for the service can be transmitted over broadband. The receiver can access the MMTP session carrying the SLS using the SLT bootstrap information. The MMT SLS USBD refers to the MP table so that the receiver can obtain the MPU formatted linear service component conveyed by the MMT protocol. The USBD may further refer to the S-TSID so that the receiver acquires the NRT data transmitted by the ROUTE protocol. Also, the USBD can further refer to the MPD to provide a playback description for data transmitted over broadband.

  In another embodiment of the present invention, the receiver may communicate to its companion device location URL information from which streaming components and / or file content items (such as files) can be obtained, such as through a web socket. The application of the companion device can request the URL using HTTP GET or the like to acquire the corresponding component, data, and the like. In addition, the receiver can transmit information such as system time information and emergency alert information to the companion device.

  FIG. 8 illustrates a structure of a broadcast signal transmitting apparatus for a next-generation broadcast service according to an embodiment of the present invention.

  An apparatus for transmitting a broadcast signal for a next-generation broadcasting service according to an embodiment of the present invention includes an input format block (Input Format block) 1000, a BICM (bit interleaved coding & modulation) block 1010, a frame building block (Frame building block) 1020, An orthogonal frequency division multiplexing (OFDM) generation block (OFDM generation block) 1030 and a signaling generation block 1040 may be included. The operation of each block of the broadcast signal transmitting device will be described.

  The input data according to one embodiment of the present invention may be an IP stream / packet and an MPEG2-TS as a main input format, and other stream types are treated as general streams.

  The input format block 1000 may demultiplex each input stream into one or multiple data pipes to which independent coding and modulation is applied. A data pipe is a basic unit for robustness control, which affects QoS (Quality of Service). One or many services or service components may be conveyed by one data pipe. A data pipe is a logical channel in a physical layer that carries service data or related metadata that can carry one or multiple services or service components.

  Since the QoS depends on the characteristics of the service provided by the broadcasting signal transmitting apparatus for the next generation broadcasting service according to an embodiment of the present invention, data corresponding to each service must be processed using different methods. Must.

  The BICM block 1010 may include processing blocks applied to a profile (or system) to which MIMO is not applied, and / or processing blocks of a profile (or system) to which MIMO is applied, and processes respective data pipes. A plurality of processing blocks.

  A processing block of a BICM block to which MIMO is not applied may include a data FEC encoder, a bit interleaver, a constellation mapper, a signal space diversity (SSD) encoding block, and a time interleaver. The processing block of the BICM block to which MIMO is applied is distinguished from the processing block of BICM to which MIMO is not applied in that it further includes a cell word demultiplexer and a MIMO encoding block.

  The data FEC encoder performs FEC encoding on the input BBF to generate a FECBLOCK procedure using outer coding (BCH) and inner coding (LDPC). Outer coding (BCH) is a selective coding method. The bit interleaver can interleave the output of the data FEC encoder to achieve optimized performance with a combination of LDPC code and modulation scheme. The constellation mapper maps QPSK, QAM-16, non-uniform QAM (NUQ-64, NUQ-256, NUQ-1024) or non-uniform constellation (NUC-16, NUC-64, NUC-256, NUC-1024). Can be used to modulate a cell word from a bit interleaver or cell word demultiplexer to provide a power normalized constellation point. While NUQ has an arbitrary shape, it is observed that QAM-16 and NUQ have a square shape. Both NUQ and NUC are specially defined for each code rate and are signaled by the PLS2 data parameter DP_MOD. The time interleaver can operate at the data pipe level. The time interleaving parameter may be set differently for each data pipe.

  The time interleaver of the present invention may be located between a BICM chain block and a frame builder. In this case, the time interleaver of the present invention may selectively use a convolution interleaver (Convolution Interleaver, CI) and a block interleaver (Block Interleaver, BI) according to a PLP (Physical Layer Pipe) mode. You may use with. The PLP according to an embodiment of the present invention is a physical path used in the same concept as the above-described DP, and its name can be changed according to a designer's intention. The PLP mode according to an embodiment of the present invention may include a single PLP (single PLP) mode or a multiple PLP (multiple PLP) mode according to the number of PLPs processed by the broadcast signal transmitter or the broadcast signal transmitter. it can. In the present invention, time interleaving that applies different time interleaving methods according to the PLP mode can be referred to as hybrid time interleaving (Hybrid Time Interleaving).

  The hybrid time interleaver may include a block interleaver (BI) and a convolution interleaver (CI). If PLP_NUM = 1, the block interleaver is not applied (block interleaver off (off)) and only the convolution interleaver is applied. If PLP_NUM> 1, both the block interleaver and the convolution interleaver may be applied (block interleaver on). The structure and operation of the convolution interleaver applied when PLP_NUM> 1 may be different from the structure and operation of the convolution interleaver applied when PLP_NUM = 1. The hybrid time deinterleaver can perform an operation corresponding to the inverse operation of the hybrid time interleaver described above.

  Cell word demultiplexers are used to separate a single cell word stream into a dual cell word stream for MIMO processing. The MIMO encoding block can process the output of the cell word demultiplexer using the MIMO encoding scheme. The MIMO encoding scheme of the present invention can be defined as full-rate spatial multiplexing (FR-SM) for providing a capacity increase with a relatively small increase in complexity at the receiver side. MIMO processing is applied at the data pipe level. NUQ (e1, i and e2, i), which is a pair of constellation mapper outputs, is provided as an input of a MIMO encoder, and outputs a MIMO encoder output pair (pair, pair) (g1, i and g2). , I) are transmitted by the same carrier k and OFDM symbol l of each transmit antenna.

  The frame building block 1020 may map data cells of an input data pipe to OFDM symbols in one frame and perform frequency interleaving for frequency domain diversity.

  A frame according to an embodiment of the present invention is separated into a preamble, one or more frame signaling symbols (FSS), and normal data symbols. A preamble is a special symbol that provides a set of basic transmission parameters for efficient transmission and reception of a signal. The preamble may signal basic transmission parameters and transmission type of the frame. In particular, the preamble may indicate whether an emergency alert service (EAS) is provided for the current frame. The main purpose of FSS is to convey PLS data. For fast synchronization and channel estimation, fast decoding of PLS data, FSS has a denser pilot pattern than normal data symbols.

  The frame building block adjusts a timing between the data pipe and the corresponding PLS data, and a delay for ensuring co-time between the data pipe and the corresponding PLS data at the transmitter side. A cell mapper for mapping compensation compensation (delay compensation) blocks, PLS, data pipes, auxiliary streams, dummy cells, and the like to an active carrier of an OFDM symbol in a frame, and a frequency interleaver (frequency) interleaver).

  The frequency interleaver may randomly interleave data cells received from the cell mapper to provide frequency diversity. Also, the frequency interleaver uses two different OFDM symbols using different interleaving seed order to obtain the maximum interleaving gain in a single frame. The OFDM symbol pair (pair, It can operate on data corresponding to (pair) or data corresponding to one OFDM symbol.

  An OFDM generation block 1030 modulates the OFDM carrier with the cells generated by the frame building block, inserts pilots, and generates a time-domain signal for transmission. In addition, the block sequentially inserts a guard interval and applies a PAPR reduction process to generate a final RF signal.

  The signaling generation block 1040 may generate physical layer signaling information used for the operation of each functional block. The signaling information according to an embodiment of the present invention may include PLS data. PLS provides a means by which a receiver can connect to a physical layer data pipe. PLS data is composed of PLS1 data and PLS2 data.

  PLS1 data is the first set of PLS data transmitted in the FSS in a frame having a fixed size, coding, and modulation that conveys basic information about the system as well as the parameters needed to decode the PLS2 data. is there. PLS1 data provides basic transmission parameters, including those required to enable reception and decoding of PLS2 data. PLS2 data conveys more detailed PLS data about data pipes and systems, and is the second set of PLS data transmitted on the FSS. Further, PLS2 signaling is composed of two types of parameters: PLS2 static data (PLS2-STAT data) and PLS2 dynamic data (PLS2-DYN data). PLS2 static data is PLS2 data that is static during the duration of a frame group, and PLS2 dynamic data is dynamic for each frame. PLS2 data that changes in the target.

  PLS2 data may include FIC_FLAG information. The FIC (Fast Information Channel) is a dedicated channel for transmitting cross-layer information that enables fast service acquisition and channel scanning (fast service acquisition and channel scanning). The FIC_FLAG information is a 1-bit field, and indicates whether or not an FIC (fast information channel) is used in the current frame group. When the value of this field is set to 1, FIC is provided in the current frame. If the value of this field is set to 0, FIC will not be transmitted in the current frame. The BICM block 1010 may include a BICM block for protecting PLS data. A BICM block for protection of PLS data may include a PLS FEC encoder, a bit interleaver, and a constellation mapper.

  The PLS FEC encoder externally encodes PLS1 and PLS2 data scrambled using a scrambler for scrambling PLS1 data and PLS2 data and a shortened BCH code for PLS protection, and inserts zero bits after BCH encoding. And an LDPC encoding block for performing encoding using an LDPC code, and an LDPC parity puncturing block. For PLS1 data only, the output bits of the zero insertion can be permutated before LDPC encoding. The bit interleaver interleaves the respective shortened and punctured PLS1 and PLS2 data, and the constellation mapper maps the bit-interleaved PLS1 and PLS2 data to a constellation.

  The apparatus for receiving a broadcast signal for a next-generation broadcast service according to an embodiment of the present invention may perform the reverse process of the apparatus for transmitting a broadcast signal for a next-generation broadcast service described with reference to FIG.

  A broadcast signal receiving apparatus for a next-generation broadcast service according to an embodiment of the present invention includes a synchronization and demodulation module for performing demodulation corresponding to a reverse process of a procedure performed by the broadcast signal transmitting apparatus, and an input signal frame. And a frame parsing module for extracting data for transmitting a service selected by the user, converting an input signal into bit-domain data, de-interleaving the bit-domain data if necessary, and improving transmission efficiency. A demapping and decoding module (demapping) for performing a demapping on a mapping applied for and correcting an error occurring in a transmission channel through decoding. And decoding module), an output processor for performing an inverse process of various compression / signal processing procedures applied by a broadcast signal transmitting apparatus, and PLS information obtained and processed from a signal demodulated by a synchronization and demodulation module. A signaling decoding module may be included. The frame parsing module, the demapping and decoding module, and the output processor can perform their functions using the PLS data output from the signaling decoding module.

  Hereinafter, the time interleaver will be described. The time interleaving group according to an embodiment of the present invention is directly mapped to one frame or spread over PI frames. Also, each time interleaving group is divided into one or more (NTI) time interleaving blocks. Here, each time interleaving block corresponds to one use of a time interleaver memory. The time interleaving blocks in the time interleaving group may include different numbers of XFECBLOCKs. In general, the time interleaver can also function as a buffer for data pipe data before the frame generation process.

  The time interleaver according to one embodiment of the present invention is a twisted row-column block interleaver. The twisted row-column block interleaver according to one embodiment of the present invention writes the first XFECBLOCK in the first column of the time interleaving memory in the column direction, the second XFECBLOCK writes the next column, The remaining XFEBLOCK in the time interleaving block can be written in the same manner. Then, in the interleaving array, the cells can be read diagonally from the first row (starting from the leftmost column to the right along the row) to the last row. In this case, in order to achieve a single memory deinterleaving at the receiver side irrespective of the number of XFECBLOCKs in the time interleaving block, the interleaving array for the twisted row-column block interleaver uses the virtual XFECBLOCK to time. It can be inserted into an interleaving memory. In this case, a virtual XFECBLOCK must be inserted before other XFECBLOCKs to achieve single memory deinterleaving at the receiver side.

  FIG. 9 illustrates a writing operation of a time interleaver according to an embodiment of the present invention.

  The block shown on the left side of the figure shows a TI memory address array, and the block shown on the right side of the figure shows a virtual FEC block for two consecutive TI groups, respectively. Shows a writing operation when two and one are inserted at the forefront of the TI group, respectively.

  The frequency interleaver according to an embodiment of the present invention may include an interleaving address generator for generating an interleaving address to be applied to data corresponding to the symbol pair.

  FIG. 10 is a block diagram of an interleaving address generator including a main PRBS generator and a sub-PRBS generator in each FFT mode included in a frequency interleaver according to an embodiment of the present invention.

  (A) shows a block diagram of the interleaving address generator for the 8K FFT mode, (b) shows a block diagram of the interleaving address generator for the 16K FFT mode, and (c) shows an interleaving address generator for the 32K FFT mode. 3 shows a block diagram of a leaving address generator.

  The interleaving process for an OFDM symbol pair uses one interleaving sequence and is described as follows. First, available data cells (output cells from the cell mapper) interleaved with one OFDM symbol Om, l are Om, l = [xm, l, 0, for l = 0,..., Nsym-1. , Xm, l, p, ..., xm, l, Ndata-1]. At this time, xm, l, and p are the p-th cell of the l-th OFDM symbol in the m-th frame, and Ndata is the number of data cells. Ndata = CFSS for frame signaling symbols, Ndata = Cdata for normal data, and Ndata = CFES for frame edge symbols. Also, the interleaved data cells are defined as Pm, l = [vm, l, 0, ..., vm, l, Ndata-1] for l = 0, ..., Nsym-1.

  For an OFDM symbol pair, the interleaved OFDM symbol pair is vm, l, Hi (p) = xm, l, p, p = 0, ..., Ndata-1 for the first OFDM symbol of each pair. ., Ndata-1 for the second OFDM symbol of each pair, vm, l, p = xm, l, Hi (p), p = 0, ..., Ndata-1. At this time, Hl (p) is an interleaving address generated based on the cyclic shift value (symbol offset) of the PRBS generator and the sub-PRBS generator.

  FIG. 11 is a diagram illustrating a hybrid broadcast receiving apparatus according to one embodiment of the present invention.

  The hybrid broadcast system can transmit a broadcast signal in conjunction with a terrestrial broadcast network and the Internet network. The hybrid broadcast receiving apparatus can receive a broadcast signal via a terrestrial broadcast network (broadcast) and an Internet network (broadband). The hybrid broadcast receiving apparatus includes a physical layer module, a physical layer I / F module, a service / content acquisition controller, an Internet access control module, a signaling decoder, a service signaling manager, a service guide manager, an application signaling manager, an alarm signal manager, and an alarm signal parser. , Targeting signal parser, streaming media engine, non-real-time file processor, component synchronizer, targeting processor, application processor, A / V processor, device manager, data sharing and communication unit, redistribution module, companion device and / or external module. To include It can be.

  A Physical Layer Module (s) receives and processes a broadcast-related signal through a terrestrial broadcast channel, converts the signal into an appropriate form, and transmits the converted signal to a physical layer I / F module. .

  The physical layer I / F module (Physical Layer I / F Module (s)) can acquire an IP datagram from information acquired from the physical layer module. Further, the physical layer I / F module can convert the acquired IP datagram or the like into a specific frame (for example, RS Frame, GSE, or the like).

  The Service / Content Acquisition Controller may perform a control operation for acquiring a service, a content, and signaling data related thereto via a broadcast and / or a broadband channel. it can.

  An Internet Access Control Module (s) can control the operation of a receiver for acquiring services, contents, and the like via a broadband channel.

  A signaling decoder (Signaling Decoder) can decode the signaling information obtained via a broadcast channel or the like.

  A service signaling manager can extract, parse and manage signaling information related to service scanning and services / contents from IP datagrams and the like.

  A service guide manager can extract announcement information from IP datagrams and the like, manage a service guide (SG) database (database), and provide a service guide.

  An application signaling manager can extract, parse, and manage signaling information related to application acquisition from IP datagrams and the like.

  An alert signaling parser can extract, parse, and manage signaling information related to alerting from an IP datagram or the like.

  A targeting signal parser can extract, parse, and manage signaling information related to personalization or targeting of a service / content from an IP datagram or the like. Further, the targeting signal parser may transmit the parsed signaling information to the targeting processor.

  A streaming media engine can extract and decode audio / video data for A / V streaming from an IP datagram or the like.

  2. Description of the Related Art A non-real time file processor may extract, decode, and manage NRT data and data in a file format such as an application from an IP datagram.

  A component synchronizer (Component Synchronizer) can synchronize content and services such as streaming audio / video data and NRT data.

  The targeting processor may process a service / content personalization-related operation based on the targeting signaling data received from the targeting signal parser.

  An application processor (App Processor) can process application related information, downloaded application status, and display parameters.

  An A / V processor may perform an operation related to audio / video rendering based on decoded audio and video data, application data, and the like.

  A device manager can perform connection and data exchange operations with external devices. Also, the device manager can perform management operations on the external device, such as addition / deletion / update of the external device that can be linked.

  The data sharing and communication unit (Data Sharing & Comm.) Can process information related to data transmission and exchange between the hybrid broadcast receiver and an external device. Here, the data that can be transmitted and exchanged may be signaling, A / V data, and the like.

  A redistribution module (s) can acquire information related to next-generation broadcasting services and contents when a broadcast receiver cannot directly receive a terrestrial broadcast signal. In addition, the redistribution module can support a broadcast service and content acquisition by a next-generation broadcast system when a broadcast receiver cannot directly receive a terrestrial broadcast signal.

  A companion device (s) is connected to the broadcast receiver of the present invention and can share data including audio, video, or signaling. A companion device can refer to an external device connected to a broadcast receiver.

  The external module may refer to a module for providing a broadcast service / content, and may be, for example, a next-generation broadcast service / content server. The external module may refer to an external device connected to the broadcast receiver.

  FIG. 12 is a diagram illustrating an overall operation of a DASH-based adaptive streaming model according to an embodiment of the present invention.

  The present invention proposes a next-generation media service providing method for providing contents capable of supporting HDR (High Dynamic Range). When HDR content capable of expressing rich brightness is provided, the present invention proposes related metadata and a transmission method thereof. Accordingly, the content can be adaptively adjusted according to various scene-specific characteristics of the content, and the content can be provided with improved image quality.

  In the case of UHD broadcasting or the like, since the brightness that existing content could not be expressed can be expressed, a high sense of realism can be provided. With the introduction of HDR, the range of expressing the brightness of the content image may be increased, and the difference between the scene-specific characteristics of the content may be larger than before. To effectively show the scene-specific features of the content on the display, metadata can be defined and these can be communicated to the receiver. The receiver can appropriately provide the video of the content according to the service provider's intention based on the transmitted metadata.

  The DASH-based adaptive streaming model according to the illustrated embodiment describes the operation between an HTTP server and a DASH client. Here, DASH (Dynamic Adaptive Streaming over HTTP) is a protocol for supporting HTTP-based adaptive streaming, and can dynamically support streaming according to network conditions. Thus, reproduction of AV content can be provided without interruption.

  First, the DASH client can obtain the MPD. The MPD may be communicated from a service provider, such as an HTTP server. The MPD may be delivered according to the delivery embodiments described above. The DASH client can request the segment from the server using the access information to the segment described in the MPD. Here, this request can be made reflecting the state of the network.

  After acquiring the segment, the DASH client can process the segment with the media engine and display the segment on the screen. The DASH client can request and acquire a necessary segment by reflecting a reproduction time and / or a network condition in real time (Adaptive Streaming). Through this, the content can be reproduced without interruption.

  An MPD (Media Presentation Description) is a file including detailed information for enabling a DASH client to dynamically acquire a segment, and may be expressed in an XML format. This MPD may be the same as the above-described MPD depending on the embodiment.

  The DASH Client Controller can generate a command for requesting an MPD and / or a segment, reflecting the status of the network. Further, the controller can control the acquired information so that it can be used in an internal block such as a media engine.

  The MPD parser can parse the obtained MPD in real time. Through this, the DASH client controller can generate a command that can acquire a required segment.

  The segment parser (Parser) can parse the acquired segment in real time. Depending on the information included in the segment, an internal block such as a media engine can perform a specific operation.

  The HTTP client can request the necessary MPD and / or segment from the HTTP server. In addition, the HTTP client can transmit the MPD and / or the segment obtained from the server to the MPD parser or the segment parser.

  A media engine may display content on a screen using media data included in a segment. At this time, the information of the MPD can be used.

  FIG. 13 is a diagram showing a block diagram of a receiver according to one embodiment of the present invention.

  The receiver according to the illustrated embodiment includes a tuner (Tuner), a physical layer controller (Physical Layer Controller), a physical frame parser (Physical Frame Parser), a link layer frame processor (Link Layer Frame Processor), and IP / UDP data. Filter (IP / UDP Datagram Filter), DTV Control Engine (DTV Control Engine), ROUTE Client (Route Client), Segment Buffer Control (Segment Buffer Control), MMT Client (MMT Client), MPU Reconstruction (MPU Reconstruction) structure, Media Processor, Signaling Parser, DASH Client (DASH Client), ISO BMFF Parser (ISO BMFF Parser), Media Decoder (Media Decoder) and / or HTTP Access Client (HTPent Ace Client) Can be included. Each detail block of the receiver may be a processor which is hardware.

  The tuner can receive and process a broadcast signal via a terrestrial broadcast channel and convert it into a suitable form (such as a Physical Frame). The physical layer controller can control operations of a tuner, a physical frame parser, and the like using RF information of a broadcast channel to be received. The physical frame parser parses the received physical frame and obtains a link layer frame and the like through processing associated therewith.

  The link layer frame processor may obtain link layer signaling or the like from the link layer frame, or may obtain IP / UDP datagrams and perform related operations. The IP / UDP datagram filter may filter a specific IP / UDP datagram from the received IP / UDP datagram. The DTV control engine is responsible for an interface between the components, and can control the operation of each component through transmission of parameters and the like.

  The ROUTE client processes a ROTE (Real-Time Object Delivery over Unidirectional Transport) packet that supports real-time object transmission, collects and processes a large number of packets, and generates one or more ISOBMFF (ISO Base Media File) object. can do. The segment buffer control can control a buffer related to a segment transmission between the ROUTE client and the Dash client.

  The MMT client processes an MMT (MPEG Media Transport) transmission protocol packet that supports real-time object transmission, and can collect and process a large number of packets. The MPU reconstruction can reconstruct an MPU (Media Processing Unit) from an MMTP packet. The media processor can collect and process the reconstructed MPU.

  The signaling parser may obtain and parse DTV broadcast service related signaling (Link Layer / Service Layer Signaling), and generate and / or manage a channel map and the like based on the obtained information. This configuration can handle low level signaling and service level signaling.

  The DASH client can process real-time streaming or adaptive streaming related operations and acquired DASH segments. The ISO BMFF parser can extract audio / video data and related parameters from the ISO BMFF object. The media decoder may decode and / or present the received audio and video data. An HTTP access client can request certain information from an HTTP server and process a response to the request.

  According to the present invention, when HDR (High Dynamic Range) content capable of expressing rich brightness is provided, an element capable of adaptively adjusting the content according to characteristics of various scenes included in the content is received. By transmitting the content to a device, it is possible to provide a method for converting and expressing the content into a video having improved image quality. In UHD broadcasting, by expressing brightness that could not be expressed by existing content, discrimination from existing broadcasting can be provided, and a high sense of realism can be provided. Through the introduction of high dynamic range (HDR), the range of expressing the brightness of an image increases, so that a difference in characteristics between scenes included in content may be greater than before. Accordingly, the broadcast transmitting apparatus may additionally provide information for effectively displaying the characteristics of each scene on a display, and the receiving apparatus may provide a video effect based on the transmitted information, thereby providing a creator. Can express a video in a method suitable for the intended direction.

  UHD broadcasting can provide viewers with improved image quality and immersion compared to existing HD broadcasting through various methods. As one of the methods, UHD broadcasting provides a method of extending the range of the brightness expression and the hue expression represented by the content to the range of the brightness and the hue that can be actually recognized by the human visual system. be able to. That is, HDR (high dynamic range) and WCG (wide color gap) can be applied to UHD content. In other words, by providing enhanced high contrast and color sensation in the content, the user viewing the UHD content will experience a greater immersion and realism. According to the present invention, when a content is reproduced on a display, a method for effectively reproducing the brightness and color of the video according to the intention of the creator or the like is provided, so that the user can view the video with improved image quality. To

  FIG. 14 is a diagram illustrating an apparatus for creating and reproducing an HDR broadcast service of a meta database according to an embodiment of the present invention. The HDR video production device may include at least one of a capture / film scanner 101, a post-production block (mastering unit) 102, and / or an encoder / multiplexer 103. The HDR video playback device may include at least one of a demultiplexer 104, a decoder 105, a metadata processor 106, a post processor 107, a synchronizer 108, and / or a display 109. In the drawings, the metadata included and received in the video stream is shown. However, the metadata of the present invention includes not only a broadcast signal but also other routes (for example, IP-based broadcast / communication, wired / wireless communication, (Wired / wireless interface, short-range wireless communication, etc.).

  The capture / film scanner 101 of the HDR video production device can convert a natural scene composed of natural colors into a digital image. For example, a capture / film scanner may be a device that converts an optical image to a digital image, such as a video camera, camera, scanner, or the like. The capture / film scanner 101 can output an HDR (High Dynamic Range) video by sensing an optical image.

  The post-production block (mastering unit) 102 can receive the raw HDR video and output the mastered HDR video and HDR metadata. The post-production block may receive mastering display information, viewing condition information, color encoding information, color gamut mapping information, and / or DR (dynamic range) information, and perform mastering. Here, the color encoding information includes, for example, EOTF (electro-optical transfer function), BT. 2020 as an example.

  The encoder / multiplexer 103 can encode and multiplex at least one or more mastered HDR videos and HDR metadata.

  The demultiplexer 104 of the HDR video playback device can receive and demultiplex the HDR stream. One HDR stream may include a plurality of contents, and the demultiplexer may output an HDR stream to be decoded to a decoder.

  The decoder 105 can receive the HDR stream and perform decoding. In this process, the decoder can output the decoded HDR video and HDR metadata. The decoded HDR video may be output to a post processor, and the HDR metadata may be output to a metadata processor.

  The metadata processor 106 can receive and store HDR metadata. The metadata processor checks a set number or a version number included in the HDR metadata to determine whether there is a change to the stored HDR metadata, and if there is a change, the existing HDR metadata. Data can be updated. The metadata processor can output HDR metadata to the post-processor according to the timing information received from the synchronizer.

  The post processor 107 can perform post-processing work on the HDR video received from the decoder using the HDR metadata received from the metadata processor. Through this process, the HDR video can be converted into an improved HDR video reflecting the HDR metadata.

  The synchronizer 108 can provide timing information to the metadata processor and post-processor so that the metadata is applied at the exact moment for the entire HDR video or for each scene, each video clip or each frame. . Here, the metadata may indicate information on a mastering display, information commonly applied in units of a channel, a program, a content, or a continuous scene, It may mean information applied to each of a video clip and a frame.

  The HDR display 109 may display and provide the enhanced HDR video to a user.

  FIG. 15 illustrates an operation method of a receiver for HDR video according to an embodiment of the present invention. In the present invention, the operation of the receiver will be mainly described, but the same matter can be considered when generating a related signal, and the present invention is also applied to a transmission signal between productions and a mastering signal. be able to. Also, in the case of information transmission between a source and a sink, matters to be considered in the present invention can be transmitted.

  When the video stream is received, the receiver can separate the HDR metadata from the HDR video signal using the video decoder 201 and store it in a separate metadata processor 202. The metadata processor may include a metadata parser, a metadata buffer, and a metadata updater. The HDR metadata may include common application information (common HDR metadata) and partial application information (scene / frame HDR metadata). The common application information is metadata that can be applied to the entire content, and may mean information that is commonly applied in units of channels, programs, and contents.

  The partial application information may indicate metadata applicable only to a part of the content, and may mean information applied to each of a continuous scene, a video clip, or a frame. After judging the performance for the type of content that can be reproduced, the receiver can apply the received common information or partial information to the content for processing. A receiver that can play HDR video can convert the content using the received metadata. The receiver can display the converted content after the processing operation as a final video. A specific operation method of the receiver is as follows.

  As a first step, the receiver can decode the video stream and obtain HDR metadata. The HDR metadata may mean HDR video information (hereinafter, HDR_info ()). The receiver may transmit metadata obtained from the video stream to a metadata parser 202, analyze the metadata, and store the metadata in a memory. The metadata can be classified into common application information (common HDR metadata) and partial application information (scene / frame HDR metadata). In the present invention, the range to which the metadata is applied is transmitted by using type information (HDR_info_type) to be described later, so that the metadata is applied according to the mastering display, and the metadata is commonly used in units of channels, programs, and contents. You can apply metadata or apply it to each successive scene, video clip, or frame.

  In addition to this, the metadata includes information indicating a section to which the metadata is applied, for example, information capable of matching a video frame to be applied with the synchronization start information (sync_start) and synchronization section information (sync_duration). It can further include in form.

  In some embodiments, the common application information may be a value that can indicate a dynamic range of a content / mastering display / frame, such as a maximum / minimum brightness or a high contrast, a transfer function such as EOTF, or the like. ), The color space of the content or the mastering display, the color temperature of the content or the mastering display, the brightness range conversion function, the color space conversion function, and / or the viewing environment information.

  In this specification, a value indicating a dynamic range of content / mastering display / frame may be transmitted through a DR information type (dynamic_range_info_type) and DR value information (dynamic_range_info_value [i]). In addition, a conversion function such as EOTF may be transmitted through a transfer function type (transfer_function_type). The color space of the content or the mastering display may be transmitted through a CG information type (color_gamut_type). The color temperature of the content or the mastering display may be transmitted through a color temperature information type (color_temperature_type). The brightness range conversion function may be transmitted through a DR mapping information type (dynamic_range_mapping_info_type). The color space conversion function may be transmitted through a CG mapping information type (color_gamut_mapping_info_type). The viewing environment information may be transmitted through a viewing environment information type (viewing_condition_info_type). The syntax of each piece of information and the fields it contains will be described later.

  The partial application information may include the same or similar information as the common application information, and may also include information on the applicable range. Partial application information can convey more specific information in that its application range is limited to certain parts of the content. For example, the common application information can transmit a brightness range applied to the entire content as a value such as f-stop or high contrast. On the other hand, the partial application information can transmit more specific information by transmitting the maximum and minimum values for each frame. Through this, the information transmission range can be differentially applied to each step according to the type of applied information to be transmitted. Similarly, in the case of dynamic range mapping, after transmitting general content conversion information as common application information, it is possible to transmit a complex conversion function that can make use of a feature of each scene through partial application information. .

  As a second step, the receiver can determine whether the display it contains is an HDR display. The receiver can determine whether or not the reproduction environment of the receiver is suitable based on the information on the content acquired using the common information (or the information on the mastering display). For example, the receiver may use the common application information described above, and may consider an SDR display or a display corresponding to the performance between SDR and HDR if the content reproduction environment is not suitable. .

  First, a case where the display included in the receiver is an SDR display or a display having performance equivalent thereto will be described. If it is determined that the display of the receiver cannot completely play the decoded HDR content, the receiver may not play the HDR content or perform a conversion to play the content. A receiver that can convert HDR video to SDR video can convert the received HDR video to SDR video and play it. To that end, the HDR metadata may include information about a conversion function that converts HDR video to SDR video. For example, as the information on the above-described conversion function, dynamic_range_mapping_info_type or color_gamut_mapping_info_type may be used, and HDR metadata may be used for converting HDR video to SDR video if necessary. Additional signaling can be provided.

  Next, a case where the display included in the receiver is an HDR display will be described. This is the case when it is determined that the display of the receiver can completely play the decoded content. In this case, the image quality of the video can be improved using the common application information included in the HDR metadata, and dynamic range mapping, color gamut mapping, and viewing condition mapping. ) Can be used to improve image quality. According to the embodiment, the image quality improvement for the entire content using the common application information may be omitted when the partial application information can be applied in the third step described later. In addition, the image quality improvement operation on the video using the common application information may be implemented through a separate module, or may be applied in cooperation with a post processing module described with reference to FIG.

  As a third step, the receiver can perform an image quality improvement operation for each scene of the HDR video. If it is determined based on the metadata information that the receiver can play HDR content, the receiver can determine whether additional HDR metadata processing is possible.

  FIG. 15 shows an example in which a process for each scene (scene-by-scene) (or a process for each clip (clip-by-clip) or each frame (frame-by-frame)) is additionally performed. In this case, it is possible to display HDR video with improved quality through dynamic conversion in detail for each content scene, video clip or frame using metadata provided in units of scenes, clips, or frames. . In this case, according to an embodiment of the present invention, the broadcast transmitting apparatus may identify, in the SEI (supplemental enhancement information) message, that the receiver is to transmit scene, video clip, or frame unit information using HDR_info_type. You can do so. In addition, the broadcast transmitting apparatus must apply scene or frame unit information to the receiver using the synchronization information type (sync_info_type), synchronization start information (sync_start), and synchronization section information (sync_duration). Information about the time can be provided. The receiver identifies that information of a scene, a video clip, or a frame unit is transmitted through an HDR video information type (HDR_info_type), and transmits the information of a scene, a video clip, or a frame unit through a sync_info_type, a sync_start, and a sync_duration. Timing information about the point of application can be obtained. If necessary, the receiver can also convert timing information provided via the metadata into information for taking a video and a sync.

  In addition, when providing the common application information, the broadcast transmitting apparatus can notify the receiver of what kind of scene, video clip, or metadata in frame units will be provided later. The broadcast transmitting apparatus can notify the receiver of the information in advance through HDR_video_enhancement_info_present_type. That is, the receiver can prepare the operation of the related module by acquiring in advance information on the presence or absence of the partial application information and the type thereof from the common application information. According to an embodiment, the broadcast transmitting apparatus may use the common application information to indicate the fact that metadata is provided in units of frames, video clips, or scenes, or may use a specific application in units of frames, video clips, or scenes. Can indicate what information is available. For example, the broadcast transmitting apparatus may indicate that dynamic range mapping or / and color gamut mapping information is provided in frame units or scene units using the common application information. .

  According to an embodiment, the receiver may apply the common application information and the scene application information to the HDR video in a stepwise manner or may apply the common application information and the scene application information as one operation. In addition, the receiver may apply the common application information and the scene application information to the HDR video for each of the dynamic range mapping and the color gamut mapping, or may apply the common application information and the scene application information by one conversion formula.

  FIG. 16 shows a post-processing unit according to one embodiment of the present invention. In the present invention, the post processor may include a dynamic range mapping (DR) block 301, a color gamut mapping (CG) block 302, and a viewing condition adjustment block 303. The post-processing unit may receive the HDR video data and improve image quality using dynamic range mapping, color gamut mapping, viewing condition mapping, and the like. . The DR mapping block 301 performs image quality improvement by applying dynamic range information, transfer function information, and DR mapping information to the input HDR video data. it can. The CG mapping block 302 performs image quality improvement by applying color gamut information, color temperature information, and CG mapping information to the input HDR video data. Can be. A viewing condition adjustment block 303 can perform image quality improvement work by applying the viewing condition information to the HDR video data. A detailed description of each information will be described later with reference to FIGS.

  17 to 20 show syntax of an SEI message and an HDR information descriptor according to an embodiment of the present invention.

  The SEI message may include an HDR information descriptor, and the HDR information descriptor may include at least one of the following fields. In the present invention, HDR information (HDR information) can be used in the same meaning as HDR video information (HDR video information).

  The HDR information type (HDR_info_type) information may indicate a unit to which information in the HDR information descriptor is applied. For example, the information may indicate information on a mastering display, or may be commonly applied to a unit of a channel, a program, and a content. In addition, it can be classified in a form applied to each of a continuous scene, a video clip, and a frame, and can be divided into other methods (for example, before and after conversion, a transmission format, a target format after conversion, static / dynamic metadata). Etc.) may be added.

  According to the above classification, the type of HDR information (HDR information) defined in the current payloadType can be classified. At this time, as in the embodiment of FIG. 17, only the detailed information corresponding to one HDR_info_type may be described in the payloadType, or two or more pieces of information may all be described. In this case, the syntax can be configured so that the information classified according to each HDR_info_type is continuously located.

  In addition, not only a method of classifying units to which information is applied in the SEI message but also different payloadTypes can be allocated and classified. For example, payloadType = 52 (mastering display), payloadType = 53 (channel), payloadType = 54 (program), payloadType = 55 (content), payloadType = epaypeape, typepeape, typePayType = 56 (scenipetype) ).

  The transition flag (transition_flag) information is a signal indicating the end point of the content related to the currently described SEI message. For example, when the HDR content ends and switches to the SDR content, the transition_flag is set to 1 for the last frame. At this time, it can be considered that transmission of the HDR information descriptor (HDR information descriptor) ends according to the application field, and the receiver turns off the module related to the HDR information descriptor based on the signal. And so on. If the receiver is divided into an STB (set box) and a display device and connected by a wired / wireless interface (for example, HDMI, DisplayPort, MHL, etc.), similarly, the interruption of the HDR related information or the HDR content , Etc., can be transmitted from the STB to the display device. The transition_flag can be notified by a frame in which the HDR information descriptor ends, meaning that the end point is notified. If promised in advance, a method of notifying by the RAP including the end frame may be applied.

  The set (set_number) information may indicate a unique identification number of the HDR information descriptor. That is, in a situation in which a plurality of HDR information descriptors are transmitted from the broadcast transmitting apparatus to the receiver in units of time or frames, each of the HDR information descriptors can play a role in distinguishing each HDR information descriptor. If necessary, a plurality of descriptors for each of a channel (channel), a program (program), a content (content), a frame (frame), a scene (scene), a clip (clip), etc., in cooperation with the above-described HDR_info_type. Can play a role. For example, when different DR mapping functions are transmitted to support displays having various types of luminance, each of channels, programs, contents, frames, scenes, clips, and the like is linked to the above-described HDR_info_type. On the other hand, it can play a role of partitioning a plurality of descriptors.

  The version (version_number) information can indicate a version of the HDR information descriptor. In cooperation with at least one of HDR_info_type and set_number, it can indicate that there is a change in information in the current descriptor. For example, when descriptors having the same HDR_info_type and / or set_number have the same version number, information in a metadata processor can be directly applied to a video. However, when the version_number is changed, the broadcast receiving apparatus can update information in a metadata buffer and apply new information to a video.

  The DR flag (dynamic_range_mapping_info_present_flag) information may indicate that the descriptor includes dynamic range mapping related information.

  The CG flag (color_gamut_mapping_info_present_flag) information can indicate that gamut mapping related information is included in the descriptor.

  The viewing environment flag (viewing_condition_info_present_flag) information can indicate that the viewing environment (viewing condition) related information is included in the descriptor.

  The number of additional improvement information (number_of_HDR_video_enhancement_info) information indicates the number of pieces of related information when there is an additional SEI message related to the current SEI message. Alternatively, improved information can be provided. For example, when HDR_info_type = 0011 (content) information is transmitted, information on a mastering display and a scene may be transmitted in connection therewith. In this case, the information has three values. At this time, when performing image quality processing such as tone mapping and gamut mapping, the receiver can use only information in the content according to the performance. When it is determined that the information has more detailed information, for example, only the information of HDR_info_type = 0100 (scene) can be used, or depending on the embodiment, all the information can be used collectively.

  The additional improvement information type (HDR_video_enhancement_info_present_type) information indicates the type of additional information related to the current SEI message, and may be defined using the same value as HDR_info_type in FIG. At this time, enh_dynamic_range_mapping_info_ present_flag, enh_color_gamut_mapping_info_present_flag, DR mapping (DR mapping) through Enh_viewing_condition_info_present_flag, gamut mapping (gamut mapping), can inform whether the viewing environment (viewing condition) related information is transmitted, the information processing for this To prepare for the operation of the receiver in advance, or to judge whether or not information improved compared to the current information is used.

  If the value of the improved DR flag (enh_dynamic_range_mapping_info_present_flag) is 1, it can indicate that DR mapping information exists for the related metadata information.

  If the value of the improved CG flag (enh_color_gamut_mapping_info_present_flag) is 1, it can indicate that gamut mapping information exists for the related metadata information.

  If the value of the enhanced viewing environment flag (enh_viewing_condition_info_present_flag) is 1, it can indicate that viewing environment information is present for the related metadata information.

  When the metadata type (metadata type) is divided not by the HDR information (HDR info) but by the value of the payloadType of the SEI message, besides the method of using the HDR_info_type and the related flag as described above, The value of the payloadType of the SEI message can be directly transmitted. That is, with respect to the above example, payloadType = 52 (mastering display) and payloadType = 56 (scene) can be transmitted as additional (improved) information for payloadType = 53 (content). Alternatively, information may be provided along with HDR_info_type by adding a payloadType.

  The synchronization information type (sync_info_type) information may indicate a method for expressing information for synchronization with a content, a scene, a clip, or a frame to which information in an HDR information descriptor must be applied. . For example, a POC (Picture order count) value used in the decoder may be transmitted, or a pic_order_count_lsb value may be transmitted directly. In the case of a storage medium, media time information may be used, and may be determined by the number of accumulated frames based on a reference time for a video start.

  The synchronization start (sync_start) information is information related to a synchronization start point. In the case where the information is transmitted in a specific cycle such as RAP instead of transmitting the related information for each frame, it is necessary to connect the start and end of the section where the information is used with the video frame. In the present invention, the embodiment in which the start information of the section or frame to which the information is applied using the sync_start information is shown as information such as time, POC, number of frames, and PTS in cooperation with sync_info_type can be applied. . The sync_info_type can define a type of synchronization information as time, a time difference, a start order, a POC (picture order count), a PTS, and the number of frames added.

  For example, for a 50 fps video stream with a RAP interval of 2 seconds, three metadata are applied for 2 seconds (start time), 2.5 seconds, and 3.5 seconds, respectively, in a 2-4 second RAP interval. The case can be considered.

  When Sync_info_type = 0x00, the type of the synchronization information is set as time, and the sync_start information of each metadata can be transmitted as 2000, 2500, or 3500. Also, the sync_duration may be additionally signaled as 500, 1000, or 1000. At this time, a time reference may be needed to determine the time, and the signaling may be separately performed such as defining the time in an adaptation field of the TS header.

  If Sync_info_type = 0x01, the type of synchronization information may be set as a time difference. The broadcast transmitting apparatus can notify the receiver that it is applied immediately, applied 0.5 seconds after RAP, and applied 1.5 seconds after RAP, by signaling as sync_start = 0, 500, and 1000, respectively. it can.

  When Sync_info_type = 0 × 02, the type of the synchronization information is set as a start order, and the order can be notified as in sync_start = 0, 1, 2. Once the start order is signaled, the receiver can apply the synchronization information according to the order at regular time intervals. The fixed time interval may be a fixed value or may have a value determined according to an order. For example, 0 can be estimated to start immediately, 1 applies to RAP + 0.5 seconds, 2 applies to RAP + 1.5 seconds, and so on.

  If Sync_info_type = 0x03, the type of synchronization information may be set as POC. In this case, the POC value of the video at the time of application of the metadata can be transmitted as 100, 125 and 175, and the duration described later can be transmitted as 25, 50 and 50 according to the POC unit. Can be. Also, a value associated with a POC in a video codec syntax may be directly transmitted.

  Also in the case of signaling a PTS (Presentation time stamp) and the number of frames, it is possible to indicate the application point of the metadata through the information on the PTS and the number of frames, similarly to the case of the POC.

  The synchronization section (sync_duration) information is information relating to a section that continues from the start of synchronization (sync_start). As in the previous example, the synchronization end point can be calculated by sync_start + sync_duration, and if necessary, the synchronization end point information can be directly transmitted together with or instead of the sync_duration. In the case of Live broadcasting, the end time cannot be determined in advance, and thus can be set to a value promised in advance, such as FFFF. If it is possible to determine the application time of the metadata only by the sync_start information, the sync_duration value may not be used. In this case, sync_duration may be used as a flag that provides additional information such as whether or not other metadata is transmitted after the metadata.

  The DR information number (number_of_dynamic_range_info) information is a dynamic range corresponding to a mastering display (mastering display), a channel (channel), a program (program), a content (content), a scene (scene), a clip (clip), or a frame (frame). The number of ways of expressing information can be indicated.

  The DR information type (dynamic_range_info_type) information indicates a method of expressing dynamic range information corresponding to a mastering display, channel, program, content, scene, clip, or frame. A method for expressing the dynamic range may be as shown in the lower part of FIG. The dynamic range may be indicated using at least one of a maximum brightness, a minimum brightness, an average brightness, an average including a constant component, and a median value. Also, in the case of white, a bright portion can be classified in detail according to characteristics, such as normal white, diffuse white, and spectral white. In the case of black, normal black, deep black, and pitch dark As described above, the types can be classified and displayed according to the characteristics.

  As described below, the broadcast transmitting apparatus may provide information such as a spectral white and a pitch dark through HDR information (HDR info), thereby subdividing brightness for bright and dark portions in the content. Such information can be used as a criterion for the display environment of the receiver or can be used as information for mapping according to the display environment.

  As the DR information value (dynamic_range_info_value) information, a corresponding value can be transmitted according to dynamic_range_info_type. That is, the content, the mastering display, and the DR of the scene can be expressed in detail according to the dynamic_range_info_type as described below. Alternatively, it may be used to separately describe a characteristic of a container video format and a characteristic of an actual content.

  Ex) content: peak_luminance_level = 2000 (nit), minimum_luminance_level = 0.1 (nit)

  mastering display: peak_luminance_level = 4000 (nit), minimum_luminance_level = 0.01 (nit)

  scene: white_level_A = 800 (nit), white_level_B = 1500 (nit), black_level_A = 1 (nit), black_level_B = 0.1 (nit)

  The transfer function type (transfer_function_type) information may indicate a type of a transfer function used for a mastering display, a channel, a program, content, a scene, a clip, or a frame of the HDR video. For example, SMPTE ST 2084, ITU BT. 1886, BT. A predetermined EOTF such as 2020 may be signaled. Depending on the type of the conversion function, the method may be divided into an absolute brightness expression method, a relative brightness expression method, and the like, and a specific method may be signaled. If necessary, the coefficients of any transformation function can be transmitted.

  The CG type (color_gamut_type) information may indicate a type of a color gamut corresponding to a mastering display, a channel, a program, content, a scene, a clip, or a frame of the HDR video. For example, BT. 709, BT. A standard color gamut such as 2020, DCI-P3, or an optional color gamut can be indicated through RGB color primary (XYZ, RGBW, etc. is also possible).

  The color temperature type information may indicate information about a reference white corresponding to a mastering display, a channel, a program, content, a scene, a clip, or a frame. For example, a standard light source color temperature such as D65 or D50 may be used. If necessary, an arbitrary value having a representative value for the color temperature such as RGB color primary (XYZ, RGBW, or the like is also possible) for white is shown. You may.

  The DR mapping type (dynamic_range_mapping_info_type) information indicates the type of dynamic range mapping information corresponding to a mastering display, channel, program, content, scene, clip, or frame. For example, as shown in the upper part of FIG. 20, by pointing to Knee function information SEI message or Tone mapping information SEI message included in HEVC, information of another SEI message can be referred to. Also, the content can be described directly in the HDR information descriptor promised in advance.

  The CG mapping type (color_gamut_mapping_info_type) information indicates a type of color gamut mapping information corresponding to a mastering display, channel, program, content, scene, clip, or frame. For example, as shown in the lower part of FIG. 20, information defined in Color remapping information SEI message included in HEVC can be cited. Also, the content can be described directly in the HDR information descriptor promised in advance.

  The viewing environment type (viewing_condition_info_type) information indicates the type of viewing environment (viewing condition) information corresponding to the mastering display, channel, program, content, scene, clip, or frame. For example, the viewing_condition_info_type information may refer to the information defined in the viewing_condition defined as a separate SEI message, or the content may be directly described in a previously promised HDR information descriptor.

  In the case where an external SEI message is referred to the dynamic_range_mapping_info_type, color_gamut_mapping_info_type, and viewing_condition_info_type, the method of using the SEI message is different from the above method. For example, when referring to the Knee function information SEI message, a more specific method may be used through dynamic_range_mapping_info_type = 0 and payloadType = 141.

  FIG. 21 illustrates a method for signaling metadata information based on a time flow according to an embodiment of the present invention.

  The transmission of the metadata according to time is 1) a method of transmitting all the information for each frame, 2) a method of transmitting the metadata in a frame at a section where the metadata is changed and applied in the RAP, 3) a RAP. For example, various methods may be considered, such as a method of transmitting metadata applied within a period with a period at a time at a period time, and a method of transmitting metadata before a RAP associated with an application point. Further, the methods 1) to 4) may be used in combination.

  FIG. 21 shows an embodiment of signaling metadata information by RAP. Common type information applied to the entire video may be transmitted for each RAP. This is the case where HDR_info_type is set to 0000 in FIG. Although the common application information is information that is repeated, the broadcast transmitting apparatus can compensate for information loss due to a transmission error by transmitting the common application information for each RAP.

  If it is necessary to provide information that is applied differently depending on the scene, it can be transmitted using scene metadata. This is the case where HDR_info_type is set to 0100 in FIG. In this case, information corresponding to the RAP time point and information applied after a scene change in the RAP can be transmitted together. The information corresponding to the RAP time point and the information applied after the scene change in the RAP can be defined as sets that play different roles, and can be distinguished by being given different set_numbers. In addition, according to the embodiment, even if information applied to the same scene is different from each other and transmitted separately, different set_numbers can be used to separate the information. If the same information is applied over two or more RAPs, it has the same set_number, and if there is no update of detailed information, the same version_number can be set. Here, when there is a change in the detailed information, the metadata processor has a different version_number so that the metadata processor checks which set has the information change and determines whether or not to update the set. can do. When the next RAP arrives, the sync_start may be applied instead of the new RAP because the scene start time changes to the new RAP. In this case, when the end point (sync_start + sync_duration) of the sync section is the same, it is considered that there is no change in information, and the same version_number can be applied.

  If the application information is transmitted in advance before the RAP associated with the application time of the metadata used in the program arrives, the application time should be notified through a relative concept such as time difference, order, and number of frames. Can be. In this case, it is also possible to notify that the metadata is not the RAP but a metadata to be applied later by using a predetermined signaling such as Sync_start = FFFF or a method of signaling with a longer section length than the RAP. .

  In the section from 00: 00: 00: 00 to 00: 00: 02: 00 in FIG. 21, the second HDR_info_type = 0100 is set to sync_start = 0 and sync_duration = 180, and 00: 00: 02: 00: 00: 00. The second HDR_info_type = 0100 in the section of 00:04:00 may be set to sync_start = 0 and sync_duration = 60. By changing the start time from 00: 00: 00: 00 to 00: 00: 02: 00, it is possible to change the duration and signal the same information (set 1, ver 0). If it is confirmed that the information is the same, the receiver does not perform metadata update.

  If there is a change in the details of the information having the same role as the previous information, the broadcast transmitting apparatus can increase the version_number while maintaining the set_number of the common application information. The metadata processor of the receiver can recognize the change of the information based on the changed version_number, and can update the existing information with new information.

  As shown in FIG. 21, when there is a change in the information in the metadata in the section from 00: 00: 04: 00 to 00: 00: 06: 00, information such as the start time can be additionally transmitted. . When the information in the metadata is changed, for example, as shown, when the B information is changed to B ', a new version number (version number) can be assigned. In the drawing, the version number for set_number = 2 was 0 in the section from 00: 00: 02: 00 to 00: 00: 04: 00, but the section from 00: 00: 04: 00 to 00: 00: 06: 00. Now you can see that the version number has increased to 1. Even when the end point changes, it can be notified through the version number that the update is required.

  FIG. 22 illustrates a method for signaling metadata information based on a time flow according to another embodiment of the present invention. FIG. 22 shows a case where there is a switch between HDR and SDR in signaling metadata information. As shown in the figure, the HDR video stream is switched to the SDR video stream at the third RAP, and in this case, no HDR information descriptor (HDR information descriptor) is transmitted or received after the third RAP.

  When the transmission of the HDR information descriptor is interrupted, the broadcast transmitting apparatus can notify a receiver via a transition_flag. When the DR of the content is switched from HDR to SDR, the transmission of the SEI message that has transmitted the video characteristics for the HDR / WCG content is interrupted, and no more information may be transmitted after the point of switching the content. Of course, the HDR information descriptor such as mastering display information, color gamut mapping, and viewing condition may also be used for the SDR content. , Legacy SDR content that does not use the HDR information descriptor. In this case, the point at which the transition_flag is turned on, that is, the point at which the transition_flag is set to 1, is important, and the RAP including the frame immediately before the point at which the switching occurs and the RAP (the second RAP in the drawing) including the frame as described above. transition_flag can be set to on.

  FIG. 23 is a diagram illustrating dynamic_range_mapping_info according to an embodiment of the present invention. When dynamic_range_mapping_info_type described in the upper part of FIG. 20 is set to 0 × 03, dynamic_range_mapping_info () can be directly defined in HDR_info descriptor. When the HDR_info_type is a channel, a program, or content as common application information related to a mastering display or a video, the information described in FIG. 22 is used for the entire video (channel, program, or content). If the partial application information is a scene type or a frame type, the information described in FIG. 22 can be used for the corresponding section. Hereinafter, the fields included in dynamic_range_mapping_info () will be described.

  The dynamic_range_mapping_info () according to an embodiment of the present invention includes maximum reference brightness information (luminance_max), minimum reference brightness information (luminance_min), arbitrary EOTF information (private_EOTF), EOTF coefficient number information (number_ofETF), and EOTF coefficient number information (number_ofETF). (transfer_curve_coeff [i]), the clipping flag information (clipping_flag), linear mapping flag information (linear_mapping_flag), clipping the maximum brightness range information (luma_clipping_upper_bound), clipping the minimum brightness range information (luma_clipping_lower_bound), the maximum brightness information (l minance_upper_bound), minimum brightness information (luminance_lower_bound), maximum brightness digital value (luma_upper_value), minimum brightness digital value (luma_lower_value_transition_transformation_core_transform_currency_transform_core) , Core brightness range area ratio information (mid_DR_percentage), upper area conversion curve type information (upper_DR_transformation_curve_type), upper area conversion curve detail information (upper_DR_transformation_curve ()), Brightness range area ratio information (upper_DR_percentage), lower-area conversion curve type information (lower_DR_transformation_curve_type), lower-area conversion curve detailed information (lower_DR_transformation_curve_curve_curve ()), additional area number information (number_changer_bubble_update_bubble_muffle_bubble_move_bubble) , Additional region difference digital value (luma_upper_value_diff [i]), changed upper region conversion curve type information (upper_DR_transformation_curve_type [i]), changed upper region conversion curve detailed information (upper_DR_trans) format_curve ()), changed upper brightness range area ratio information (upper_DR_percentage [i]), and / or changed core brightness range area ratio information (mid_DR_percentage [i]).

The maximum reference brightness information (luminance_max) indicates the maximum reference brightness expressed in the ultra-high-definition broadcast content. That is, it indicates the maximum value of the brightness range (DR). For example, in the case of a reference monitor, 100 cd / m ² is set as the maximum reference brightness. In this case, a quotient of a value obtained by dividing the value by 100 (decimal number) in consideration of a general range is used. Can be transmitted.

The minimum reference brightness information (luminance_min) indicates the minimum reference brightness expressed in the ultra-high definition broadcast content. That is, it indicates the minimum value of the brightness range (DR). For example, in the case of a reference monitor, 0.05 cd / m ² is set as the minimum reference brightness. In this case, a value obtained by multiplying the above value by 100 (decimal number) in consideration of a general range is used. 5 can be transmitted.

  The arbitrary EOTF information (private_EOTF) indicates whether or not an arbitrary EOTF function is used. Generally, ITU-R BT. 1886, REC. 709, BT. If a widely used EOTF, such as 2020, is used, it may be conveyed by VUI information. However, if an EOTF that is not yet defined as a standard is used, the field value can be set to 1 to indicate. For example, perceptual quantization may be used as an EOTF that is not defined as a standard, that is, an arbitrary EOTF.

  The EOTF coefficient number information (number_of_coeff) indicates the number of coefficients used for an arbitrary EOTF.

  The EOTF coefficient information (transfer_curve_coeff [i]) indicates a coefficient used for an arbitrary EOTF.

  The clipping flag information (clipping_flag) is information indicating whether or not the clipping option is used, and may have a value of 1 when the use of the clipping option is permitted.

  The linear mapping flag information (linear_mapping_flag) indicates whether or not a linear dynamic range transformation method is used. It has a value of 1 when a linear dynamic range transformation method is used.

  The clipping maximum brightness range information (luma_clipping_upper_bound) indicates a digital value with respect to an upper critical point in a brightness range (DR) displayed when a clipping option is used.

  The clipping minimum brightness range information (luma_clipping_lower_bound) indicates a digital value for a lower critical point in a brightness range (DR) displayed when the clipping option is used.

  The maximum brightness information (luminance_upper_bound) indicates the maximum value (unit of nit) of the brightness range that must be expressed in the brightness range expressed by the ultra-high definition broadcast content. The maximum brightness information can be a reference for determining the type of display of the receiving device. Also, a separate criterion for determining the type of display of the receiving device can be signaled.

  The minimum brightness information (luminance_lower_bound) indicates the minimum value (unit: nit) of the brightness range that must be expressed in the brightness range expressed by the ultra-high definition broadcast content. The minimum brightness information can be a criterion for determining the type of display of the receiving device. Also, a separate criterion for determining the type of display of the receiving device can be signaled.

  The maximum brightness digital value (luma_upper_value) indicates a digital value (digital value) corresponding to the maximum brightness information (luminance_upper_bound).

  The minimum brightness digital value (luma_lower_value) indicates a digital value (digital value) corresponding to the minimum brightness information (luminance_lower_bound).

  The core region conversion curve type information (mid_DR_transformation_curve_type) identifies a brightness range conversion curve used in the core brightness range region. The conversion curve includes a linear curve, an exponential curve, an S curve (s curve), a logarithmic curve, a combination curve, and a LUT (Look Up Table). ) Can be used.

  The core area conversion curve detailed information (mid_DR_transformation_curve ()) indicates additional information based on the conversion curve identified by the core area conversion curve type information (mid_DR_transformation_curve_type). For example, when a linear curve is used, gradient information may be transmitted, and when an exponential curve or a logarithmic curve is used, information about a bottom may be transmitted, and an S curve may be transmitted. When (s curve) is used, the coordinates of the inflection point and information about the base and the y-intercept for each section may be transmitted. When a combination curve is used, each section may be transmitted. , The type of curve in each section, and information on the graph can be transmitted.

  The core brightness range region ratio information (mid_DR_percentage) indicates the ratio of the core brightness range region in the brightness range of the ultra-high-definition broadcast content to the entire brightness range (DR) of the display of the receiving device.

  Upper region conversion curve type information (upper_DR_transformation_curve_type) identifies a brightness range conversion curve used in the upper brightness range region. The conversion curve includes a linear curve, an exponential curve, an S curve (s curve), a logarithmic curve, a combination curve, and a LUT (Look Up Table). ) Can be used.

  The upper region conversion curve detail information (upper_DR_transformation_curve ()) indicates additional information based on the conversion curve identified by the upper region conversion curve type information (upper_DR_transformation_curve_type). For example, when a linear curve is used, gradient information may be transmitted, and when an exponential curve or a logarithmic curve is used, information about the bottom may be transmitted, and the S curve may be transmitted. If (s curve) is used, the coordinates of the inflection point and information about the base and the y-intercept for each section may be transmitted. , The type of curve in each section and information on the graph can be transmitted.

  The upper brightness range region ratio information (upper_DR_percentage) indicates the ratio of the upper brightness range region in the brightness range of the ultra-high-definition broadcast content to the entire brightness range (DR) of the display of the receiving device.

  The lower region conversion curve type information (lower_DR_transformation_curve_type) identifies a brightness range conversion curve used in the lower brightness range region. The conversion curve includes a linear curve, an exponential curve, an S curve (s curve), a logarithmic curve, a combination curve, and a LUT (Look Up Table). ) Can be used.

  The lower region conversion curve detail information (lower_DR_transformation_curve ()) indicates additional information based on the conversion curve identified by the lower region conversion curve type information (lower_DR_transformation_curve_type). For example, when a linear curve is used, gradient information may be transmitted, and when an exponential curve or a logarithmic curve is used, information about the bottom may be transmitted, and the S curve may be transmitted. If (s curve) is used, the coordinates of the inflection point and information about the base and the y-intercept for each section may be transmitted. , The type of curve in each section and information on the graph can be transmitted.

  The additional area number information (number_luminance_upper_bound_diff) indicates the number of variables used to extend the core brightness range area.

  The additional area difference information (luminance_upper_bound_diff [i]) indicates a difference value for forming the (i + 1) th brightness value in the ultra-high-definition broadcast content. When extending the core brightness range area on a display (Case 2) having a brightness range wider than the existing brightness range but not accepting all the brightness ranges expressed in the ultra-high-definition broadcast content, the maximum brightness information (Luminance_upper_bound) can be changed to a value indicated by luminance_upper_bound + luminance_upper_bound_diff [0] + ... + luminance_upper_bound_diff [i].

  The additional area difference digital value (luma_upper_value_diff [i]) indicates a digital value (digital value) for the (i + 1) th brightness value in the ultra-high-definition broadcast content. If the core brightness range is extended on a display (Case 2) that has a brightness range wider than the existing brightness range but cannot accept all the brightness range expressed in the ultra-high-definition broadcast content, the maximum brightness digital The value (luma_upper_value) can be changed to a value indicated by luma_upper_value + luma_upper_value_diff [0] +... + Luma_upper_value_diff [i].

  The changed upper region conversion curve type information (upper_DR_transformation_curve_type [i]) can identify a conversion curve used in the changed upper brightness range region when supporting the (i + 1) th brightness range. That is, when the core brightness range area is extended, the changed upper area conversion curve type information can identify a conversion curve used in the changed upper brightness range area according to the expansion.

  The changed upper region conversion curve detailed information (upper_DR_transformation_curve ()) indicates additional information based on the conversion curve identified by the changed upper region conversion curve type information (upper_DR_transformation_curve_type [i]). That is, in the case of supporting the (i + 1) th brightness range, details of a conversion curve used in the changed upper brightness range area are shown.

  The changed upper brightness range area ratio information (upper_DR_percentage [i]) indicates that when the core brightness range area of the ultra-high-definition broadcast content is changed, the changed upper brightness range area is changed to the entire display of the receiving device. The ratio occupied in the brightness range (DR) is shown.

  The changed core brightness range area ratio information (mid_DR_percentage [i]) indicates that when the core brightness range area of the ultra-high definition broadcast content is changed, the changed core brightness range area is the overall brightness of the display of the receiving device. The ratio occupied in the range (DR) is shown.

  FIG. 24 illustrates a case of referring to an SEI message defined in HEVC according to an embodiment of the present invention. When the color_gamut_mapping_info_type described in the lower part of FIG. 20 is set to 0 × 00, gamut_mapping_info () is not directly defined in the HDR_info descriptor, but can refer to an SEI message defined in HEVC. Here, the SEI message may conform to a color mapping information SEI message syntax defined in HEVC.

  If the HDR_info_type is a channel, a program, or content as common application information related to a mastering display or a video, information referred to throughout the video (channel, program, or content) may be used. If the partial application information is a scene type or a frame type, the information referred to only the corresponding section can be applied.

  FIGS. 25 and 26 show an embodiment of signaling an HDR_info descriptor through a PMT according to an embodiment of the present invention. PMT means a program mapping table, which includes table identifier information, section syntax indicator information, section length information, program number information, version number information, current_next indicator information, section number information, PCR_PID information, It may include program info length information, first descriptor information, stream type information, elementary PID (elementary PID) information, elementary stream information length (Es_info_length) information, second descriptor information, CRC information, and the like. The first descriptor information can indicate the descriptor information included in the first loop following the program info length information, and the second descriptor information can be included in the second loop following the elementary stream information length information. Can be indicated.

  The UHD_program_info_descriptor according to an embodiment of the present invention may be signaled in the first descriptor information included in the PMT, and the HDR_info descriptor may be signaled in the second descriptor information included in the PMT. Can be done.

  The UHD_program_info_descriptor may include at least one of descriptor tag (descriptor_tag) information, descriptor length (descriptor_length) information, and service type information (UHD_service_type), as shown in the upper part of FIG. Here, the service type information (UHD_service_type) can indicate the type of UHD service, as shown in the lower part of FIG. For example, the service type information can indicate the type of UHD service specified by the user, such as UHD1 (4K), UHD2 (8K), or classification based on quality. Through this, various UHD services can be provided to the receiver. In the case of the present invention, HDR information (HDR info) for different stages or units such as video, scene, clip or frame is provided by specifying UHD_service_type = 1100 (UHD1 service with HDR information metadata, 4K example). Can be shown.

  FIGS. 27 and 28 show an embodiment of signaling an HDR_info descriptor via an EIT according to an embodiment of the present invention. The ATSC and DVB systems can include an EIT as a signaling table, and the syntax included therein is as shown in FIGS. 27 and 28.

  An EIT (Event Information Table) of the ATSC and the DVB system according to an embodiment of the present invention is commonly a table_id field, a section_syntax_indicator field, a section_length_service field, a survey_icon_service, a service_id_service, a service_id_service, a service_id_service, a service_id_service, a service_id_service, and a service_id_service. num_events_in_section (segment_last_section_number) field, event_id field, start_time field, length _In_seconds (duration) field, descriptors_length field, descriptor () field, and / or CRC_32 field.

  The table_id field identifies that the table is an EIT (Event Information Table). The section_syntax_indicator field is a one-bit field that is set to 1 to indicate a long form of the MPEG-2 private_section table. The section_length field indicates the length of the table section following this field in bytes. The source_id field indicates a source ID (source id) of a virtual channel that transmits an event described in the section. The version_number field is a 5-bit field indicating the version number of the table. The current_next_indicator field is a 1-bit field that indicates whether this table is currently applicable or next applicable. The section_number field indicates a section number. The last_section_number field identifies the number of the last section. The num_events_in_section field indicates the number of events included in the table section. The event_id field identifies a specific number that indicates the described event. The start_time field indicates the start time of the event with reference to GPS second. The value indicating the start time of the event in the virtual channel may be greater than the value indicating the end time of the event being broadcast. The end time of an event can be defined as the sum of the start time of the event and a value representing the length of the event in time. The length_in_seconds (duration) field indicates the duration of the event in seconds. The descriptors_length field indicates the total length of an event descriptor (descriptor ()) described subsequently. descriptor () is a descriptor loop located in the table. A descriptor loop can include additional descriptors. The EIT may include zero or more descriptors, and the descriptor may correspond to an event level descriptor that describes information applied to each event. According to an embodiment of the present invention, the UHD_program_info_descriptor and the HDR_info descriptor may be transmitted by being included in an event level descriptor. The UHD_program_info_descriptor can be used to distinguish the type of UHD service, and the HDR_info descriptor can check whether or not HDR video information metadata is included at an event level. Can be used to determine if it is acceptable. In the case of cable broadcasting, the same information can be provided to the AEIT instead of the descriptor.

  The CRC_32 field contains a CRC value that can check the integrity of the data. The CRC value can guarantee that after the entire EIT section has been processed, a zero value is output from a register in the decoder defined in Annex A of ISO-13818-1 "MPEG-2 Systems". .

  When UHD_service_type of UHD_program_info_descriptor signaled via the EIT is set to 1100, the receiver can confirm that information on a proper viewing environment is transmitted via metadata. For example, if UHD_service_type is 1100, the receiver can confirm that the service is UHD1 service with HDR information metadata, 4K.

  When UHD_service_type of UHD_program_info_descriptor signaled via the EIT is set to 0000, the receiver checks whether HDR_info_descriptor () is present and outputs HDR information for different stages or units such as video, scene or frame. (HDR info) is provided. Here, if UHD_service_type is 0000, it can be indicated that the service is a UHD1 service.

  In the case described above, it is possible to determine whether or not information on a mastering display, a content, a scene, or a frame unit desired by the content provider can be used on the display of the viewer using HDR_info_descriptor (). Using this, it is possible to determine in advance whether content, scene or frame-based metadata will be used for content that is played back at the current or future point in time, for situations such as scheduled recording. There is an effect that the setting can be prepared in the receiver in advance.

  FIG. 29 illustrates HDR_info_descriptor () according to another embodiment of the present invention. A plurality of pieces of information may exist for one event. That is, the information is not applied consistently to the content, and the information applied depending on time or the presence or absence of the inserted content may be converted. Alternatively, various modes intended by a creator for one content can be supported. At this time, it is necessary to determine whether such a mode is acceptable on the display of the receiver, and information on this may be provided by the broadcast transmitting apparatus via the viewing_condition_metadata. The syntax in the viewing_condition_metadata can conform to the definition of the viewing condition descriptor of the SEI message (viewing condition descriptor).

  The HDR_info_descriptor may include at least one of descriptor tag (descriptor_tag) information, descriptor length (descriptor_length) information, and information number (number_of_info) information, as shown at the top of FIG. The HDR_info_descriptor may include a loop, and may include HDR_info_metadata () as many as the number indicated by the number_of_info. The syntax of the HDR_info_metadata () may be a script of the embodiment of the HDR information descriptor (HDR information descriptor) shown in FIG. 17 or a part thereof.

  FIG. 30 shows a block diagram and an operation method of a receiver according to an embodiment of the present invention. When HDR information is transmitted through the above-described method, a process of analyzing a signal at a receiver and applying the information to an HDR image based on the signal is as follows.

  The receiver according to an embodiment of the present invention can receive a broadcast signal from an RF (radio frequency) channel using a tuner and a demodulator 1601. Although not shown, the broadcast signal can be received not only on the RF channel but also on other routes. For example, the broadcast signal may be received via an IP-based broadcast / communication, wired / wireless communication, wired / wireless interface. Further, the broadcast signal and the metadata described later may be received through different paths. Metadata described later can be transmitted and received not only by a broadcast signal but also by another route (for example, IP-based broadcast / communication, wired / wireless communication, wired / wireless interface, short-range wireless communication, and the like).

  The receiver can decode the received broadcast signal using the channel decoder 1602. Here, the channel decoder can decode using the VSB or QAM method. The decoded broadcast signal can be demultiplexed by the demultiplexer 1603 into broadcast content data and signaling data. Broadcast content data can include HDR video data and can be decoded by video decoder 1605. The signaling data may include information on broadcast content data, and may include a signaling table or signaling information such as PMT, VCT, EIT, and SDT according to an embodiment. The receiver may extract UHD_program_info_descriptor from the signaling information (eg, PMT) using section data processor 1604.

  The receiver uses the UHD_program_info_descriptor to determine whether there are additional services or media that must be additionally received to configure the original UHDTV broadcast. In the embodiment of the present invention, when the receiver receives that UHD_service_type = 1100, it can recognize that there is additional information through the SEI message. Alternatively, after receiving UHD_service_type = 0000 (8K is 0001), the receiver can recognize through EIT that there is video-related additional information through an SEI message.

  Based on the HDR information SEI message or HDR_info_type, the receiver that has confirmed that the additional information exists may determine whether the range to which the additional information is applied is a channel unit, a program unit, a content unit, or a scene. , Clips or frames. Also, in order to synchronize the range in which the additional information is applied in each case, the HDR_info_descriptor () may include information regarding a start time and an end time of the additional information. In one embodiment of the present invention, sync_info_type, sync_start, and sync_duration, which are information for synchronization based on a video frame, are used as examples. HDR_info_descriptor () can include transition_flag information indicating the end point of HDR.

  Also, when HDR_info_type is information applied to the entire content, the signaling information indicates whether additional scene, clip, or frame information is provided via HDR_video_enhancement_info_present_type. can do. Through this, the receiver can know in advance that scene, clip or frame unit information will be provided later, and set in advance the metadata processing for scene, clip or frame unit and the setting for improving the HDR image quality. It can be carried out.

  The receiver can recognize, through dynamic_range_info_type, information about high contrast and information indicating brightness as information capable of expressing a dynamic range through signaling information. For example, dynamic_range_info_type may indicate an aspect ratio and f-stop as high contrast information, or may indicate peak luminance, minimum luminance, and the like as brightness information. The value according to each type can be transmitted to the receiver through dynamic_range_info_value [i]. In particular, according to an embodiment of the present invention, dynamic range information according to characteristics of a content, a mastering display, a frame, and a scene can be indicated, and brightness can be indicated through dynamic_range_info_type. Can be further subdivided and shown. At the same time, the receiver determines the type of the EOTF, the type of the color gamut, and the type of the color temperature used for the color encoding, respectively, through the transfer_function_type, the color_gap_emission_type, and the color_gap_aperture_type through the transfer_function_type_emission_type. I can figure it out.

  The HDR_info_descriptor () can provide a receiver with additional information such as dynamic range mapping, color gamut mapping, and viewing condition information. If additional information can be provided in various ways, an SE or I message is defined in advance in the HEVC through a message that defines a dynamic_range_mapping_info_type, a color_gamut_mapping_info_type, and a viewing_condition_info_type in the HEVC. When the additional information is directly defined in the HDR_info descriptor, the receiver can understand the detailed information through dynamic_range_mapping_info (), color_gamut_mapping_info (), and viewing_condition_info ().

  The signaling information described above can be stored in the metadata processor 1606 of the receiver. The stored signaling information may be updated when the set number or version is changed. The receiver may use the synchronizer 1607 to synchronize the image quality improvement information (signaling information) and the video data such that the image quality improvement information stored in the metadata processor 1606 can be applied to the video data in application units. it can.

  The receiver transmits the dynamic range information of a content, a scene, or a frame to an image quality improving unit such as an HDR algorithm or an existing post-processing module 1608 based on the provided information to improve the image quality. Can be done. Also, the receiver may include a dynamic range mapping, a color gamut mapping, a tone mapping, a detailed mapping related to viewing condition information, and a detailed information related to a viewing condition information. Related modules such as color mapping, color correction, and white balance may be directly connected to improve image quality. If image processing is performed in a linear luminance domain inside the receiver, the EOTF obtained through transfer_function_type may be applied.

  The receiver can display the post-processed HDR video via the display unit 1609 and provide it to the user.

  FIG. 31 shows an HDR information descriptor according to an embodiment of the present invention. In order to more accurately apply the HDR information (information) presented in the present invention, it is necessary to describe an input video format and an output video format in detail. That is, the broadcast signal transmitting apparatus additionally signals information on a video format applied before and after processing the video data, so that the broadcast signal receiving apparatus can perform more accurate color mapping. The illustrated information may be additionally included in the HDR information descriptor along with the information included in the HDR information descriptor described with reference to FIG. The illustrated information can be applied equally to all HDR video processing in the SEI message as in the present embodiment. Also, different HDR video processing, such as color gap mapping and dynamic range mapping, may define different input / output characteristics. .

  The input color space type information (Input_color_space_type) may indicate a standard of color expression among information regarding an image to be subjected to HDR video processing transmitted in the present invention. RGB, YCbCr, xvYCC, XYZ, or the like can be used as a reference for color expression. That is, when the input color space type information is set to 0000, it indicates that the reference of color expression is RGB, and when it is 0001, it is YCbCr, when it is 0010, it is xvYCC, and when it is 0011, it is XYZ. Can be shown. If it is 0100-1111, it may be reserved for future use. Also, the input color space type information may be used together with the color gamut type information. For example, the input color space type information (input_color_space_type) is RGB, and the color gamut type information (color_gamut_type) is BT. If the image has a constant luminance, the image is displayed in BT. 2020 CL-based RGB.

  The input hue accuracy information (Input_color_precision) indicates the accuracy of the color expression, and may be used in conjunction with the input color space type information (Input_color_space_type) if necessary. For example, in the case of RGB, the same color can be expressed with different precisions such as 10 bits / 12 bits / 14 bits. Alternatively, if it is necessary to indicate by a floating point, it can indicate how many digits below the decimal point have precision.

  The output color space type information (Output_color_space_type) is the opposite concept of the input color space type information (Input_color_space_type) and indicates a reference of a final color expression to be targeted after HDR video processing. RGB, YCbCr, xvYCC, XYZ, or the like can be used as a reference for color expression. That is, when the output color space type information is set to 0000, it indicates that the reference of color expression is RGB, and when it is 0001, it is YCbCr, when it is 0010, it is xvYCC, and when it is 0011, it is XYZ. Can be shown. If it is 0100-1111, it may be reserved for future use. The output hue accuracy information (Output_color_precision) indicates the accuracy of the color expression, and may be used in conjunction with the output color space type information (Output_color_space_type) if necessary. The embodiment for the output hue accuracy information can be applied in the same manner as the embodiment for the input hue accuracy information (Input_color_precision). Processing color space type information (processing_color_space_type) indicates a color space (Color space) in which HDR video processing is performed. Generally, a neutral color space such as XYZ can be used, but a specific color space may be designated and used. As the processing color space, XYZ, YCbCr (BT. 2020, non-CL), YCbCr (BT. 2020, CL), CIE L * a * b *, and YUV can be used. That is, when the value of the processing color space type information is set to 0000, it is XYZ, when it is set to 0001, it is YCbCr (BT.2020, non-CL), and when it is set to 0010, it is YCbCr (BT.2020, BT.2020). CL), CIE L * a * b * when set to 0011, and YUV when set to 0100 may be specified as the color space type.

  Processing hue accuracy information (Processing_color_precision) indicates the accuracy of color expression, and may be used in conjunction with processing color space type information (processing_color_space_type) if necessary. This embodiment can be applied in the same way as the embodiment of the input hue accuracy information (Input_color_precision).

  The HDR information descriptor may further include target information. The target information with respect to the dynamic range information indicates information regarding a result that is a target when pursuing improvement in image quality of the frame / scene via the HDR information descriptor. Here, the target may be a video format or a target display.

  The target information can include the following elements. The target dynamic range information type number (Number_of_target_dynamic_range_info_type) information may indicate the number of target dynamic range information types. The target dynamic range information type (target_dynamic_range_info_type) information can define the type of dynamic range information targeted by HDR video processing. On the other hand, the target dynamic range information value (target_dynamic_range_info_value) information can indicate a specific value for the information defined by the target dynamic range information type information. The target conversion function type information (target_transfer_function_type), the target color gamut type information (target_color_gamut_type), and the target color temperature type information (target_color_temperature_type) are the type of the color and the type of the conversion function that target the color, and the type of the color conversion matte with the target. Can be shown. The above information includes the above-mentioned Number_of_dynamic_range_info_type, dynamic_range_info_type, dynamic_range_info_value, transfer_function_emission_type, and transfer_function_type. Here, the previously defined values indicate the dynamic range, the color gamut, and the transfer function of an image to be subjected to HDR video processing, and are applied with specific meaning. it can.

  FIG. 32 shows an HDR information descriptor according to an embodiment of the present invention. The illustrated information may be additionally included in the HDR information descriptor along with the information included in the HDR information descriptor described with reference to FIG. The HDR information descriptor may additionally include HDR program transition flag information, transition set number information, and transition version number information. The HDR transition flag information (HDR_program_transition_flag) indicates a case where there is a major change in the HDR information descriptor. For example, if the flag is 1, it may have the meaning of the end of the current HDR program / content. When the flag is 1, it may mean a change in HDR content, a change in the type of HDR information to be applied, or the like. After the above-mentioned change has occurred, the broadcast transmitting apparatus may notify the HDR information descriptor that there is a major change, a change in the HDR content / program, by setting it to 1 for a certain frame / time. Alternatively, by setting to 1 for a certain frame / time just before the change occurs, there will be a change in the HDR information descriptor after a certain frame / time, that is, a change in the HDR content / program. I can let you know. When this flag is signaled, a condition may be provided to refer to the SEI message in order to apply a main change. If desired, such signaling can be performed at the system or service level as well as at the video level. The transition set number information (transition_set_number) and the transition version number information (transition_version_number) may be transmitted as additional information for notifying the characteristics of the changed HDR content / program. For example, signaling the HDR system to be used in the changed or changed HDR content / program via the transition set number (set_number) information, or linking with the current target when there is information on multiple HDR targets The set number information (set_number) may be signaled. Not only the set number (Set_number) information but also the transition version number (version_number) information can be provided as information on the next HDR content / program. Links to various types of information can be provided as needed. For example, each set number information (set_number) and version number information (version_number) corresponding to a target display (target display) of 1000 nit / 500 nit / 100 nit can be provided.

  The transition flag information (transition_flag) described with reference to FIG. 17 in connection with the HDR transition flag information can be used as follows. The meaning of the transition flag information (Transition_flag) can be extended to indicate that there is a major change in the HDR information descriptor (HDR information descriptor). That is, when the value of the transition flag information (transition_flag) is 1, the SDR is started by giving the meaning that the transmission of the HDR information descriptor (HDR information descriptor) corresponding to the current or the current program ends. In addition to this, it can be used to mean that another HDR program is started or other types of metadata are applied. The specific meaning and method of the signaling may be in accordance with the HDR_program_transition_flag. Here, the transition flag information (transition_flag) may be used alone, or all two signals may be used in conjunction with the HDR transition flag information (HDR_program_transition_flag). For example, the transition flag information (transition_flag) can be signaled at the end of the HDR information descriptor (end of HDR content), and the HDR transition flag information (HDR_program_transition_flag) can be signaled at the start of the next HDR content. .

  The set number information (set_number) described with reference to FIG. 17 in connection with the HDR transition flag information can be used with its meaning extended. The meaning of the set number information (set_number) can be extended to indicate that there is a major change in the HDR information descriptor. That is, a different set number (set_number) can be specified for the HDR information descriptor according to the program / content / channel. In this case, the meaning that the content of the HDR information descriptor has changed is given, and the HDR content ends. , The start of a new HDR content or the like. In addition, the set number information (set_number) may be set to have a fixed value for a specific HDR information descriptor. For example, if different types of parameters can be transmitted according to the HDR system, each HDR system can be classified using set number information (set_number).

  The version number information (version_number) described with reference to FIG. 17 in relation to the HDR transition flag information can be used with its meaning extended. The meaning of the version number information (version_number) can be extended to indicate that there is a major change in the HDR information descriptor. That is, when there is a change in the HDR information descriptor, the broadcast transmitting apparatus assigns a changed version number (version_number), and the broadcast receiving apparatus transmits a new HDR information descriptor from a frame to which the changed HDR information descriptor is applied. Can be set to be referred to as mandatory. In this case, it is used not only when the program / content itself changes within the channel, that is, when the current HDR content is changed to another type of HDR content, as well as the frame / scene unit change within the program. Can be. At this time, the broadcast transmitting apparatus may give a specific version number (version_number) and perform signaling, thereby characteristically notifying a case where a major switch occurs, such as a case where a program / content itself changes.

  FIG. 33 illustrates a case where a region in a frame is divided by a feature set according to an embodiment of the present invention. Here, a frame may mean an entire area range including all pixels in a picture constituting a screen, and may be referred to as a window in some embodiments. The dynamic metadata may be information reflecting characteristics of a frame or a scene (frame / scene) that changes with time. In this regard, different metadata processing may be applied to one frame according to certain characteristics. For example, when both a dark region and a bright region exist in a frame, the effect of the HDR image can be maximized by applying different processing to each region. In this case, the transmitting end can transmit a feature for distinguishing each characteristic, and can transmit different processing methods for each region. The receiving end may perform the area-adaptive processing based on the received characteristic of each area or the processing method. Here, the region may mean a single region defined in a closed curve, or may mean a set of at least one or more regions having the same or similar characteristics. For example, as shown, there may be three regions that make up one frame. The three regions may have different features from each other. Here, there may be an overlapped portion between different regions. In this case, processing can be performed by designating the priority (priority) of each area. The priority order for each area can be specified by the video producer, and the intention of the producer can be reflected. For example, as shown in the figure, a feature set 1 (feature set 1) and a feature set 2 (feature set 2) may overlap. In this case, since the property set 2 having the priority 1 (priority 1) has a higher priority, the property set 2 can be applied to the overlapping area. In addition, when specifying an area, it is possible to specify that the union of each area is the entire frame, so that processing can be performed on all the areas. That is, it is possible to prevent a part that is excluded from the area designation and is not processed from occurring in the entire frame. Of course, it is possible to intentionally not perform processing, but in this case also, it is generally necessary to transmit a signal indicating that processing is not intentionally performed. As described above, a position, a hue characteristic, a brightness characteristic, or the like can be used as a reference for designating or dividing an area. In addition, when tracking a specific object (object) is supported, the object can be designated as an area. In this case, when the object moves in the frame, the designated area can also move.

  FIG. 34 illustrates information for signaling HDR information (HDR information) and a feature set according to an embodiment of the present invention. One frame can be divided into characteristic sets corresponding to a plurality of regions, and different processing can be applied to each of the characteristic sets according to each characteristic. For this purpose, the characteristics of the characteristic set can be specified for each region, and the information to be matched can be arranged according to the characteristics. The drawing shows a case where information is described in parallel in one piece of metadata. That is, the HDR information type (HDR information type), the transition_flag, the set number (set number), the version number (version number), the sync information, and the input / output / processing color space type (input / output / processing section) As described above, dynamic range mapping information excluding information applied to an entire frame, color gamut mapping information, and viewing environment information (viewing information set characteristics). It is intended to convey the process by parallel. Position, color, brightness, histogram, and the like can be considered as a criterion for classifying the characteristic set, and a set can be defined by an intersection of these. When multiple property sets are applied to the same frame, the HDR information may include the following fields.

  The total_number_of_feature_sets_in_a_frame field may indicate the number of feature sets classified in the frame. If the area is not partitioned, the field can be designated as 1.

  The feature_spatial_boundary field can directly specify the position of the region as one of the criteria for specifying the characteristic set. The location of the region can generally be indicated by an x, y index. For example, if the area is a rectangle according to the shape of the area, it can be indicated by the coordinates (x, y) of the start point and the coordinates (x + N, y + M) of the end point. Alternatively, it can be indicated by the start point and the lengths N and M of each side. When the shape of the region is circular, it can be indicated by the center and the diameter of the circle. Having a particular value can also indicate that it is not used. A detailed example of this will be described later with reference to the drawings.

  The feature_colorimetry_boundary field can specify an area having a specific color as one of the criteria for specifying a characteristic set. Generally, RGB colorimetry can be represented by CIE xy coordinates. Alternatively, it may be indicated by the center coordinates and the diameter of a circle (or sphere) in a color space, or an arbitrary range may be specified. Having a particular value can also indicate that it is not used.

  The feature_luminance_boundary field can specify an area having a specific brightness as one of the criteria for specifying a characteristic set. It is also possible to indicate a range of maximum and minimum brightness values or a brightness range that is adjusted (+-) around a specific brightness. Having a particular value can also indicate that it is not used.

  The feature_histogram_boundary field can be used as one of criteria for designating a characteristic set when a region is classified according to characteristics of a histogram. For example, the center brightness (or digital value) information and the boundary information of a portion having the local maximum of the image histogram can be transmitted. At this time, the histogram may transmit a brightness distribution with respect to luminance or information on a specific channel or each of RGB to specify a characteristic. Having a particular value can also indicate that it is not used.

  The feature_priority field may indicate a priority applied when areas specified as a property set overlap. As in the above-described embodiment, different priorities may be applied to all characteristic sets, and a plurality of characteristic sets may have the same priority. When the field is 0, it is possible to specify that a process such as blending is performed on an overlapping area. In addition to the parts described above, a part related to a boundary process between the divided areas may be added.

  In order to perform processing using different metadata according to regions in a frame, features for distinguishing regions in a frame must be transmitted. At this time, as described in the above-described drawings, signaling for different categories such as spatial, colorimetry, luminance, color volume, and histogram can be considered. In addition, one area can be divided as an intersection of at least two or more categories. For example, a rectangular area can be specified in the spatial boundary field, and an area having a specific color can be specified in the colorimetric boundary field in the rectangular area. In other words, regions that simultaneously satisfy the specified regions indicated by the spatial boundary field and the colorimetric boundary field can be made to correspond to a specific characteristic set. One or more signalings for each category can be used, and the following signaling can be considered as a specific example for each category.

  FIG. 35 is a diagram illustrating a Spatial boundary field for designating a spatial area according to an embodiment of the present invention. As a method for specifying a spatial region, signaling for a certain region in a frame can be considered. As a first method, a rectangular area can be designated as a spatial area (d35010). The Spatial boundary field may signal the vertices of the rectangular area, and may signal the upper left and lower right points as shown in the drawing as more efficient signaling. In the drawing, top_left_corner_x_axis and top_left_corner_y_axis indicate the x and y coordinates of the vertex located at the upper left corner of the rectangle. Similarly, bottom_right_corner_x_axis and bottom_right_corner_y_axis indicate the x and y coordinates of the vertex located at the lower right corner of the rectangle. When a region is signaled using the method shown in d35010, a region including the inside of a rectangle determined by two vertices located diagonally can be designated as a spatial region.

  As a second method, when specifying a circular area instead of a rectangle, an area belonging to the inside of the circle can be specified as a spatial area. In this case, the Spatial boundary field may signal information on the center coordinates of the circle (center_of_circle_x_axis, center_of_circle_y_axis) and the radius of the circle (radius_of_circle) (d35020). When a region is signaled using this method, it can be considered to include all pixels belonging to the inside of the circle.

  As a third method, a well-known figure shape such as an ellipse can be considered in addition to the above-described rectangle and circle. When signaling as an arbitrary polygon, as shown in d35030, the number of vertices of the polygon (number_of_points_minus_2) and the position of each vertex (x_axis [i], y_axis [i]) can be signaled. At this time, the number of vertices may be a minimum of three in order to create a polygon. The number_of_points_minus_2 field may signal a number that is two less than the actual number of vertices of the polygon. For example, when the number_of_points_minus_2 field is 2, the rectangular shape described above can be signaled. Thus, when signaled as an arbitrary polygon, it can be considered that the signal points to an area inside the polygon configured by using all the points included in the polygon.

  A fourth method can use a predefined or pre-transmitted area as another signaling method for any polygon. At this time, as shown in d35040, a constant is obtained through information such as the type (mask_type) of the mask (mask), the start or center position of the mask (location_x_axis, location_y_axis), and the size of the mask (ratio: ratio to the reference size). Can be specified. At this time, an area designated or transmitted in advance can be used as the type of the mask. The details of the shape of the area according to the type of the mask may be transmitted in advance through static metadata, or previous frame information may be used. The mask may be directly used as pixel data. You may send it.

  FIG. 36 is a diagram illustrating a Colorimetric boundary field for specifying a spatial area according to an embodiment of the present invention. In order to specify an area corresponding to a feature set, the HDR information may specify a hue range on a chromaticity plane. Generally, a chromaticity plane based on a color space basically used in an image can be used. However, in some cases, a hue range on a specific chromaticity plane intended by the creator can be considered. In order to signal the hue range on a specific chromaticity plane intended by the creator, signaling for the chromaticity plane may be required. In this case, as shown in d36010, a specific color space type (color_space_type) and, if necessary, a conversion equation (coefficient [i]) can be provided. Here, as the color space type, a color space such as YCbCr, Lab, and Yuv can be used as shown in d36020. In addition, the image data may be classified based on criteria such as a luminance expression method (linear, non-linear), a luminance conversion equation (EOTFa, EOTFb), and a center color temperature (D65, D50, etc.). Depending on the embodiment, an arbitrary color space may be used instead of the color space defined in advance. In this case, the color space is defined using a conversion formula from a neutral color space such as XYZ to an arbitrary color space. can do.

  After the color coordinates for specifying the hue range are specified, the hue range can be considered as a set of hues within a certain range in a given color space. In this case, the hue range can be specified by an arbitrary polygon, circle, ellipse, or the like on the color coordinates. In the case of a polygon, as shown in d36030, it is possible to limit the color region inside the specified polygon through the coordinate values (x_axis [i], y_axis [i]) of the vertices based on the number of points (number_of_points_minus_3). it can. The specific area is specified as described in the previous drawing.

  Also, as shown in d36040, a color area can be signaled as a set of colors within a certain radius (radius_of_circle) centered on specific color coordinates (center_of_circle_x_axis, center_of_circle_y_axis).

  Similarly, as shown in d36050, an elliptical shape (coefficient_a, coefficent) with an elliptical shape (coefficient_a, coefficient) around an axis having a constant gradient (angle) centered on a specific color coordinate (center_of_ellipsid_x_axis, center_of_ellipsioid_y_axis). You can also.

  FIG. 37 illustrates a Luminance boundary field and a Luminance distribution boundary field for designating a spatial area according to an embodiment of the present invention. In order to specify an area corresponding to a feature set, the HDR information can specify a range of brightness or a brightness distribution in an image. In the Luminance boundary field, as shown in d37010, an area can be specified as a range of brightness. Under the assumption that the brightness of a pixel exists on a line segment connecting the extremes of black-white, the brightness range can be divided by points on the line segment. At this time, the expression for the brightness may be represented by a digital value (digital_value) indicating a relative distribution of the brightness, or may be represented by an absolute brightness value (luminance_value).

  The Luminance distribution boundary field can specify an area as a brightness distribution, as shown in d37020. As another method of classifying features according to a brightness range, a brightness distribution in an image can be used. At this time, in order to divide the brightness range, a high brightness limit (upper_bound) and a low brightness limit (lower_bound) can be designated based on the brightness (local_maximum) of a point where brightness is mainly distributed. . That is, the upper limit and the lower limit can be signaled based on the reference brightness. Here, each field value may be a digital value (digital_value) or an absolute brightness value (luminance_value) indicating a relative distribution of brightness, and if necessary, use all two as shown in the figure. Is also good. In the present invention, as an example of a brightness distribution, an example in which a range is specified based on a histogram distribution has been described. However, in some embodiments, another type of distribution such as a brightness accumulation distribution may be used. Can be.

  FIG. 38 is a diagram illustrating a Color volume boundary field for specifying a spatial area according to an embodiment of the present invention. A region corresponding to a feature set may be defined in one color space. That is, unlike the above-described embodiment, the color area and the brightness area can be defined in one color space. At this time, if a color space (color space) in which a hue range (color volume) is defined needs to be separately defined, the above-described feature_color_space can be used.

  As a method of defining a hue range (color volume) in a color space, a vertex of a polyhedron can be defined. Here, as shown in d38010, a polyhedron can be defined through the number of vertices (number_of_points) and the coordinates of each vertex (color_volume_x_axis, color_volume_y_axis). That is, the hue included in the polyhedron thus defined in the color space can be designated as a necessary region of the hue range (color volume).

  Next, as another method of specifying a range in a color volume, a method of defining colorimetry according to a brightness level as shown in d38020 can be considered. For example, when a color (hue, saturation) and a brightness (intensity) are separated like an HSI (Hue Saturation Intensity) color space, a hue, a saturation, and a lightness (intensity) are separated. Can correspond to each axis on the xyz coordinate plane. In this case, the brightness level (color_volume_z_axis) is divided into levels corresponding to a predetermined number (number_of_luminance_levels), and the color coordinates (color_volume_x_axis, color_volume_y_axis_) of a polygon according to each brightness level can be defined. That is, colorimetry according to a brightness level may be defined, and a color volume may be defined between each layer through interpolation. In other words, a hue range to be defined in a color space is defined by at least one or more brightness sections defined for at least one or more brightness sections divided in the color space. It can be indicated through the hue range. For example, in a color space, a first hue range is signaled for a first brightness section, and a second hue range is signaled for a second brightness section. Hue range to be displayed. Such signaling for the hue range may be defined for the entire frame, or may be defined for each of a plurality of regions constituting one frame, according to an embodiment. Here, a frame may mean an entire area range including all pixels in a picture constituting a screen, and may be called a window in some embodiments.

  As another example of signaling the color volume according to the brightness level, colorimetry may be signaled in the form of a circle as shown in d38030. In other words, the radius of the color plane expected to include a color similar to the color coordinates (center_of_circle_x_axis, center_of_circle_y_axis) of the center hue with respect to the color plane defined by the divided brightness value (color_volume_z_axis). , And information on the entire color volume can be provided through interpolation between color planes.

  As a method of signaling a boundary for a specific color at a specific brightness within a color volume (color volume), as shown in d38040, target color coordinates (center_of_circle_x_axis, center_of_circle_axis_center, color_center, color_center, object_of_circle_axis, object_center, object_center) Color volume information may be provided using a signaling method for a radius for similar colors (radius_of_circle). In this case, a color volume may be defined as the interior of a sphere having a radius for a similar color centered on the color coordinate.

  In addition to the above-described method, an ellipse in a color plane or a three-dimensional figure based on the ellipse may be considered as a hue range. In general, similar colors / brightness groups will be within a certain range from the center color, and if different weights depending on directionality are required, a shape such as an ellipse or an ellipsoidal solid may be used. Can be used.

  FIG. 39 is a block diagram illustrating a broadcast transmitter according to an embodiment of the present invention. The broadcast transmitter d39010 according to the present invention may include an encoder d39020, a multiplexing unit d39030, and / or a transmitting unit d39040.

  The resolution of the video data input to the broadcast transmitter d39010 may be UHD. Also, the metadata input to the broadcast transmitter d39010 may include image quality improvement metadata for UHD video. The image quality improvement metadata may be transmitted by being included in an SEI message transmitted together with the video data. As described above with reference to FIGS. 17 to 38, the image quality improvement metadata may include an HDR information descriptor (HDR_info_descriptor), which may include information necessary for improving the image quality of UHD video. Information necessary for improving the image quality of UHD video can be applied in units of the entire content (channel, program, content), scene, scene, clip, or frame, and common application information applied to the entire content, and It may also include partial application information applied on a scene, clip, or frame basis. HDR_info_descriptor () can include transition_flag information indicating the end point of HDR.

  Also, the HDR information descriptor may include processing color space type information and processing hue accuracy information for a processing step for improving image quality, as described above. In addition, the HDR information descriptor may further include input color space type information and input hue accuracy information before the processing step, and output color space type information and output hue accuracy information after the processing step. The HDR information descriptor may also include information on a dynamic range, a conversion function type, a color gamut, and a color temperature type targeted by the image quality improvement processing. Also, it may include HDR program transition flag information indicating that a change to HDR content or HDR information is scheduled, and set number information and version number information to be subjected to the transition.

  Also, the HDR information descriptor can divide a plurality of areas included in the frame, and can include feature set information corresponding to each area. For the property set information, different metadata processing can be applied to each area even in the same frame. Each characteristic set may be divided by a region position or by a hue within a certain range in a color space. Further, the characteristic set may be classified according to a brightness range or a brightness distribution. In addition, within a color volume defined by a polyhedron defined in a color space, the color may be classified by at least one of the position, the hue, the brightness range, and the brightness distribution. The HDR information descriptor may include information for distinguishing the above-described property set. Can be included. The detailed description of each piece of information is as described with reference to FIGS.

  Video data input to the broadcast transmitter d39010 may be encoded by the encoder d39020. The transmitting end can use HEVC (High Efficiency Video Coding) as an encoding method for video data. The transmitting end can synchronize the encoded video data with the image quality improvement metadata and multiplex the encoded video data using the multiplexing unit d39030. The image quality improvement metadata may further include synchronization information. The image quality improvement metadata may include synchronization information such as time, time difference, start order, POC, PTS, and the number of accumulated frames according to the synchronization method.

  The transmission unit d39040 can transmit the transport stream output from the multiplexing unit d39030 as a broadcast signal. Here, the transport stream may be channel-coded and modulated before transmission, and then transmitted as a broadcast signal. According to another embodiment of the present invention, the metadata is not only a broadcast signal, but also other routes (eg, IP-based broadcast / communication, wired / wireless communication, wired / wireless interface, short-range wireless communication, etc.). But you can send. Also, the video data may be transmitted through a separate path from the video data.

  FIG. 40 is a block diagram illustrating a broadcast receiver according to an embodiment of the present invention. The broadcast receiver d40010 according to the present invention may include a receiving unit d40020, a demultiplexing unit d40030, and / or a decoder d40040.

  The broadcast signal received by the receiving unit d40020 can be channel-decoded after being demodulated. The channel-decoded broadcast signal may be input to the demultiplexer d40030 and may be demultiplexed into a video stream and image quality improvement metadata. The metadata can be received not only on the broadcast signal but also on other routes (eg, IP-based broadcast / communication, wired / wireless communication, wired / wireless interface, short-range wireless communication, etc.). The output of the demultiplexer can be input to the decoder d40040. The decoder can include a video decoder and a metadata processor. That is, the video stream may be decoded by a video decoder and the image quality improving metadata may be decoded via a metadata processor. The decoded video stream and the image quality improvement metadata can be used by the post-processing unit to improve the image quality of the UHD video, as described with reference to FIG. The receiver can post-process the decoded video data based on the image quality improvement metadata, and can obtain an effect of improving the image quality of the video data for at least one of HDR and WCG. The image quality improvement metadata may include an HDR information descriptor, as described above, and the HDR information descriptor may include, as described above, processing color space type information for a processing step for improving image quality, and processing hue. Accuracy information can be included. In addition, the HDR information descriptor may further include input color space type information and input hue accuracy information before the processing step, and output color space type information and output hue accuracy information after the processing step. The HDR information descriptor may also include information on a dynamic range, a conversion function type, a color gamut, and a color temperature type targeted by the image quality improvement processing. Also, it may include HDR program transition flag information indicating that a change to HDR content or HDR information is scheduled, and set number information and version number information to be subjected to the transition.

  In addition, the HDR information descriptor can divide a plurality of areas included in the frame, and can include feature set information corresponding to each area. For the property set information, different metadata processing can be applied to each area even in the same frame. Each characteristic set may be divided by a region position or by a hue within a certain range in a color space. Further, the characteristic set may be classified according to a brightness range or a brightness distribution. In addition, within a color volume defined by a polyhedron defined in a color space, the color may be classified by at least one of the above-described position, hue, brightness range, and brightness distribution. The HDR information descriptor may include information for distinguishing the above-mentioned property set. For example, at least one of spatial boundary information, colorimetric boundary information, luminance boundary information, luminance distribution boundary information, and color information of the color boundary of the boundary list. Can be included. The detailed description of each piece of information is as described with reference to FIGS.

  FIG. 41 is a diagram illustrating a method of transmitting a broadcast signal including image quality improvement metadata according to an embodiment of the present invention. A method of transmitting a broadcast signal including image quality improvement metadata includes encoding a video stream to generate video data (ds41010), and generating a broadcast signal including the generated video data and image quality improvement metadata (ds41020). ) And transmitting the generated broadcast signal (ds41030).

  Encoding the video stream to generate video data (ds41010) may include receiving a video stream having a UHD resolution and encoding the video stream to generate video data. Here, the video stream may be encoded by HEVC (High Efficiency Video Coding). At the same time, the step of generating video data (ds41010) may generate image quality improvement metadata. As described above, in the step of generating the video data (ds41010), the broadcast transmitting apparatus may transmit the entire content (channel, program, content), scene, scene, clip, or frame of the video data. Applicable image quality improvement metadata can be generated together. The image quality improvement metadata may be data for at least one of HDR and WCG, and may have different amounts of information according to application units. The image quality improvement metadata may be transmitted by being included in the HDR_info_descriptor () described above. HDR_info_descriptor () can include transition_flag information indicating the end point of HDR. Also, the HDR information descriptor may include processing color space type information and processing hue accuracy information for a processing step for improving image quality, as described above. In addition, the HDR information descriptor may further include input color space type information and input hue accuracy information before the processing step, and output color space type information and output hue accuracy information after the processing step. The HDR information descriptor may also include information on a dynamic range, a conversion function type, a color gamut, and a color temperature type targeted by the image quality improvement processing. Also, it may include HDR program transition flag information indicating that a change to HDR content or HDR information is scheduled, and set number information and version number information to be subjected to the transition.

  Also, the HDR information descriptor can divide a plurality of areas included in the frame, and can include feature set information corresponding to each area. For the property set information, different metadata processing can be applied to each area even in the same frame. Each characteristic set may be divided by a region position or by a hue within a certain range in a color space. Further, the characteristic set may be classified according to a brightness range or a brightness distribution. In addition, within a color volume defined by a polyhedron defined in a color space, the color may be classified by at least one of the above-described position, hue, brightness range, and brightness distribution. The HDR information descriptor may include information for distinguishing the above-mentioned property set. For example, at least one of spatial boundary information, colorimetric boundary information, luminance boundary information, luminance distribution boundary information, and color information of the color boundary of the boundary list. Can be included. The detailed description of each piece of information is as described with reference to FIGS.

  Also, the image quality improvement metadata may be defined directly in the signaling information or may be generated in a manner that refers to another message. Such image quality improvement metadata can be reference data for the receiver to improve the image quality of video data according to the application unit. As a result, the receiver can dynamically improve the quality of the video data using the quality improvement metadata received with the video data.

  The step of generating a broadcast signal including the generated video data and the image quality improvement metadata (ds41020) may include building a broadcast signal frame and generating the broadcast signal using a modulation process.

  The step of transmitting the generated broadcast signal (ds41030) may transmit the transport stream as a broadcast signal.

  FIG. 42 is a diagram illustrating a method for receiving a broadcast signal including image quality improvement metadata according to an embodiment of the present invention. A method of receiving a broadcast signal including image quality improvement metadata includes receiving a broadcast signal (ds42010), demultiplexing the received broadcast signal into video data and image quality improvement metadata (ds42020), And decoding and applying the image quality improvement metadata (ds42030).

  In the receiving the broadcast signal (ds42010), the broadcast signal may be received using a receiving unit, and the received broadcast signal may be demodulated and then channel-decoded. The broadcast signal may include a UHD broadcast signal, and may further include image quality improvement metadata for the UHD broadcast content. The detailed description of the image quality improvement metadata is as described with reference to FIGS.

  The step of demultiplexing the received broadcast signal into video data and image quality improving metadata (ds42020) includes demultiplexing the channel-decoded broadcast signal into video data and image quality improving metadata using a demultiplexing unit. can do. The video data may include UHD video data, and the image quality improvement metadata may include HDR or WCG related data applied to UHD video data. The image quality improvement metadata may be included and received in the HDR_info_descriptor () described above. HDR_info_descriptor () can include transition_flag information indicating the end point of HDR. Here, the image quality improvement metadata can be divided into common application information and partial application information according to its application range. The image quality improvement metadata may include at least one of common application information and partial application information. The common application information is information applied to the entire channel, the entire program, or the entire video data forming one content, and the partial application information is partially applied to some scenes, clips, or frames of the video data. May be applicable to the data. The image quality improvement metadata may be directly defined in the signaling information of the broadcast signal, or a method of referring to a predefined message may be used.

  Decoding and applying the video data and the image quality improvement metadata, respectively (ds42030), can decode the video data using a video decoder to obtain the video data. In this step, for the image quality improvement metadata, the image quality improvement metadata can be obtained using a signaling data parser or a metadata decoder. The receiver can improve the quality of the decoded video data based on the quality improvement metadata. The image quality improvement metadata may include HDR or WCG information for video data, and may further include synchronization information indicating a time when each information is applied. The image quality improvement metadata may include an HDR information descriptor as described above, and the HDR information descriptor may include, as described above, processing color space type information and processing hue accuracy information for a processing step for improving image quality. Can be included. In addition, the HDR information descriptor may further include input color space type information and input hue accuracy information before the processing step, and output color space type information and output hue accuracy information after the processing step. The HDR information descriptor may also include information on a dynamic range, a conversion function type, a color gamut, and a color temperature type targeted by the image quality improvement processing. Also, it may include HDR program transition flag information indicating that a change to HDR content or HDR information is scheduled, and set number information and version number information to be subjected to the transition.

  Also, the HDR information descriptor can divide a plurality of areas included in the frame, and can include feature set information corresponding to each area. For the property set information, different metadata processing can be applied to each area even in the same frame. Each characteristic set may be divided by a region position or by a hue within a certain range in a color space. Further, the characteristic set may be classified according to a brightness range or a brightness distribution. In addition, within a color volume defined by a polyhedron defined in a color space, the color may be classified by at least one of the above-described position, hue, brightness range, and brightness distribution. The HDR information descriptor may include information for distinguishing the above-mentioned property set. Can be included. The detailed description of each piece of information is as described with reference to FIGS.

  The image quality improvement metadata can be applied to the video data based on the synchronization information. Through this, the image quality of the video data can be applied to all or sections. The user can receive the improved quality UHD content through the HDR or WCG information additionally applied to the existing UHD content.

  A module or unit may be a processor that performs a series of steps stored in a memory (or storage unit). Each of the steps described in the above embodiments may be performed by a hardware / processor. Each of the modules / blocks / units described in the embodiments described above can operate as hardware / processors. Also, the method presented by the present invention may be implemented as code. This code may be written to a processor-readable storage medium and, therefore, may be read by a processor provided by the apparatus.

  Although the drawings are described separately for convenience of description, the embodiments disclosed in the drawings may be combined to design a new embodiment. The design of a computer-readable recording medium on which a program for executing the above-described embodiments is recorded is also within the scope of the present invention.

  As described above, the apparatus and method according to the present invention are not limited to the configuration and method of the above-described embodiment, and the above-described embodiment may be modified so that various modifications are possible. All or some of the embodiments may be selectively combined and configured.

  On the other hand, the method proposed by the present invention can be embodied as a processor-readable code on a processor-readable recording medium provided in a network device. The processor-readable storage medium includes any type of storage device in which data that can be read by the processor is stored. Examples of recording media readable by the processor include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and in the form of a carrier wave such as a transmission via the Internet. Includes what is embodied. Further, the recording medium readable by the processor may be distributed to computer systems connected via a network, and may store and execute a code readable by the processor in a distributed manner.

  Although the preferred embodiments of the present invention have been shown and described above, the present invention is not limited to the above-described specific embodiments, and departs from the spirit of the present invention as set forth in the appended claims. Of course, various modifications can be made by those having ordinary knowledge in the technical field to which the present invention pertains, and such modifications are individually understood from the technical idea and perspective of the present invention. Must not be done.

  In this specification, both the invention of the product and the invention of the method are described, and the description of both the inventions may be supplementarily applied as necessary.

  It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

  In this specification, both the device invention and the method invention are referred to, and the description of the device invention and the method invention may be applied in a complementary manner to each other.

  Various embodiments have been described in the detailed description of the invention.

  The present invention is used in the field of providing a series of broadcast signals.

  It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention. Thus, it is intended that the present invention cover the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

Claims (6)

A method of transmitting a broadcast signal,
Generating video data;
A step that generates a picture quality improvement metadata,
Transmitting the broadcast signal including the video data and the image quality improvement metadata ,
The image quality improvement metadata is an SEI (supplemental enhancement information) message,
The SEI message includes number information for specifying the number of rectangular areas in the video data frame and coordinate information for specifying the position of each area,
The color mapping information SEI message defined in HEVC is applied to at least one of the rectangular areas,
The method of transmitting a broadcast signal , wherein the color remapping information SEI message provides information on remapping of color samples of the video data . The method of claim 1 , wherein the SEI message further includes brightness range information or brightness distribution information for dividing the rectangular area. The method of claim 1 , wherein the SEI message further includes hue range information for dividing the rectangular area. A method for receiving a broadcast signal,
Receiving the broadcast signal including video data and the image quality improvement metadata,
Demultiplexing the broadcast signal into the video data and the image quality improvement metadata;
Decoding the video data and the image quality improvement metadata, respectively;
Applying the image quality improvement metadata to the video data.
The image quality improvement metadata is an SEI (supplemental enhancement information) message,
The SEI message includes number information for specifying the number of rectangular areas in the video data frame and coordinate information for specifying the position of each area,
The color mapping information SEI message defined in HEVC is applied to at least one of the rectangular areas,
The method for receiving a broadcast signal , wherein the color remapping information SEI message provides information on remapping of color samples of the video data . The method of claim 4 , wherein the SEI message further includes brightness range information or brightness distribution information for dividing the rectangular area. The method of claim 4 , wherein the SEI message further includes hue range information for dividing the rectangular area.