WO2017007263A1

WO2017007263A1 - Broadcast signal transmitting device, broadcast signal receiving device, broadcast signal transmitting method, and broadcast signal receiving method

Info

Publication number: WO2017007263A1
Application number: PCT/KR2016/007384
Authority: WO
Inventors: 윤준희; 오현묵; 오세진; 이장원; 서종열; 황수진; 김진필
Original assignee: 엘지전자 주식회사
Priority date: 2015-07-08
Filing date: 2016-07-07
Publication date: 2017-01-12

Abstract

The present invention proposes a method for transmitting broadcast signals. The method for transmitting broadcast signals, according to the present invention, proposes a system which can support a next-generation broadcast service in an environment which supports next-generation hybrid broadcast using terrestrial broadcast networks and the Internet. In addition, the present invention proposes an efficient signaling method, which can cover both terrestrial broadcast networks and the Internet, in an environment which supports next-generation hybrid broadcast.

Description

Broadcast signal transmitting apparatus, broadcast signal receiving apparatus, broadcast signal transmitting method, and broadcast signal receiving method

The present invention relates to a broadcast signal transmission apparatus, a broadcast signal reception apparatus, and a broadcast signal transmission and reception method.

As analog broadcast signal transmission is terminated, 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 as well as the video / audio data.

UHD broadcasting aims to provide viewers with improved image quality and immersion through various aspects compared to existing HD broadcasting. As one of the methods for this, UHD extends the range of brightness and color expression expressed in content to the range of perceived brightness and color in the real human visual system, that is, high dynamic range (HDR) and wide color (WCG). gamut) is likely to be introduced. In other words, by providing improved high contrast and color in the content, users who watch UHD content will experience greater immersion and presence. In the present invention, when the content is reproduced on the display, by presenting a method for effectively reproducing the image brightness and color in accordance with the intention of the producer, it is possible to watch the image of the improved image quality.

That is, the digital broadcasting system may provide high definition (HD) images, multichannel audio, and various additional services. However, for digital broadcasting, data transmission efficiency for a large amount of data transmission, robustness of a transmission / reception network, and network flexibility in consideration of a mobile receiving device should be improved.

In accordance with the object of the present invention and as included and outlined herein, the present invention provides a system and an associated signaling scheme that can effectively support next-generation broadcast services in an environment that supports next-generation hybrid broadcasting using terrestrial broadcasting networks and Internet networks. Suggest.

The present invention can provide a method for producing and viewing HDR content that is adaptive to scene characteristics.

The present invention can control copying on a media element basis for HDR content.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are incorporated in and constitute a part of this application for further understanding of the invention, illustrate embodiments of the invention, together with a detailed description that illustrates the principles of the invention.

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

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

3 illustrates a low level signaling (LLS) table and a service list table (SLT) according to an embodiment of the present invention.

4 illustrates a USBD and an S-TSID delivered to ROUTE according to an embodiment of the present invention.

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

6 illustrates a link layer operation according to an embodiment of the present invention.

FIG. 7 illustrates a link mapping table (LMT) according to an embodiment of the present invention. FIG.

8 is a diagram illustrating a hybrid broadcast reception device according to an embodiment of the present invention.

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

FIG. 10 is a diagram illustrating a dynamic adaptive streaming over HTTP (DASH) data model according to an embodiment of the present invention. FIG.

FIG. 11 illustrates a DASH data model in detail according to an embodiment of the present invention. FIG.

12 is a block diagram of a receiver according to an embodiment of the present invention.

FIG. 13 is a diagram illustrating an apparatus for producing and playing a metadata-based HDR broadcast service according to an embodiment of the present invention.

14 illustrates a method of operating a receiver for HDR video according to an embodiment of the present invention.

15 illustrates a post-processing unit according to an embodiment of the present invention.

16 through 19 illustrate syntax of an SEI message and an HDR information descriptor according to an embodiment of the present invention.

20 to 21 illustrate an embodiment of signaling metadata information according to a RAP.

22 illustrates dynamic_range_mapping_info according to an embodiment of the present invention.

23 shows a case of referring to an SEI message defined in HEVC according to an embodiment of the present invention.

24 and 25 illustrate an embodiment of signaling HDR_info descriptor through PMT according to an embodiment of the present invention.

26 and 27 illustrate an embodiment of signaling HDR_info descriptor through EIT according to an embodiment of the present invention.

28 illustrates HDR_info_descriptor () according to another embodiment of the present invention.

29 is a diagram showing the structure of a media file according to an embodiment of the present invention.

30 is a diagram illustrating an HDR configuration box for providing HDR information according to an embodiment of the present invention.

FIG. 31 illustrates a scheme for defining HDR information in a tkhd box according to an embodiment of the present invention.

32 is a diagram illustrating a method of defining HDR information in a vmhd box according to an embodiment of the present invention.

33 is a diagram illustrating a method of defining HDR information in a trex box according to an embodiment of the present invention.

34 is a diagram illustrating a method of defining HDR information in a tfhd box according to an embodiment of the present invention.

35 is a diagram illustrating a method of defining HDR information in a trun box according to an embodiment of the present invention.

FIG. 36 illustrates a scheme for defining HDR information in various flags, sample group entries, or sample entries according to an embodiment of the present invention.

FIG. 37 illustrates a scheme for defining HDR information in a HEVC sample entry, an HEVC configuration box, or an HEVC decoder configuration record according to an embodiment of the present invention. FIG.

38 is a diagram illustrating a method of storing / delivering HDR information by defining an HDR information SEI box according to an embodiment of the present invention.

39 is a diagram illustrating an HDR information box for providing image quality improvement information according to an embodiment of the present invention.

40 is a diagram illustrating an HDR information box for providing image quality improvement information according to an embodiment of the present invention.

FIG. 41 is a diagram illustrating an embodiment related to a specific type of field included in an HDR information box.

42 is a diagram illustrating a method of defining image quality improvement information in a stsd box according to an embodiment of the present invention.

43 is a diagram illustrating a method of defining image quality improvement information in a tkhd box according to an embodiment of the present invention.

44 is a diagram illustrating a method of defining image quality improvement information in a vmhd box according to an embodiment of the present invention.

45 is a diagram illustrating a method of defining image quality improvement information in a trex box according to an embodiment of the present invention.

46 is a diagram illustrating a method of defining image quality improvement information in a tfhd box according to an embodiment of the present invention.

FIG. 47 is a diagram illustrating a method of defining image quality improvement information in a trun box according to an embodiment of the present invention. FIG.

48 is a diagram illustrating a method of defining image quality improvement information in a sample group entry or a sample entry according to an embodiment of the present invention.

FIG. 49 is a diagram illustrating a method of defining picture quality improvement information in an HEVC sample entry, an HEVC configuration box, or an HEVC decoder configuration record according to an embodiment of the present invention.

50 is a diagram illustrating a method of defining image quality improvement information in an sbgp box or an sgpd box according to an embodiment of the present invention.

51 is a diagram illustrating a copy control box for providing copy control information according to an embodiment of the present invention.

52 is a diagram illustrating a method of defining copy control information in a tkhd box according to an embodiment of the present invention.

FIG. 53 illustrates a scheme for defining copy control information in a vmhd box, smhd box, hmhd box, or nmhd box according to an embodiment of the present invention.

54 is a diagram illustrating a method of defining copy control information in a trek box according to an embodiment of the present invention.

55 is a diagram illustrating a method of defining copy control information in a tfhd box according to an embodiment of the present invention.

56 is a diagram illustrating a method of defining copy control information in a trun box according to an embodiment of the present invention.

57 illustrates a method of defining copy control information in a visual sample group entry according to an embodiment of the present invention.

58 is a diagram illustrating a method of defining copy control information in a visual sample entry according to an embodiment of the present invention.

FIG. 59 is a diagram illustrating a method of defining copy control information in a pssh box according to an embodiment of the present invention. FIG.

60 is a diagram illustrating a method of defining copy control information in a tenc box according to an embodiment of the present invention.

FIG. 61 is a diagram illustrating a method of defining copy control information in a senc box according to an embodiment of the present invention. FIG.

62 is a diagram illustrating a method of defining copy control information in CencSampleEncryptionInformationVideoGroupEntry or CencSampleEncryptionInformationGroupEntry according to an embodiment of the present invention.

63 is a view showing a copy control box according to an embodiment of the present invention.

64 is a diagram illustrating a description of an HDR configuration description including image quality improvement information according to an embodiment of the present invention.

65 and 66 illustrate a description of @schemeIdUri and @value of an HDRConfiguration element including picture quality improvement information according to an embodiment of the present invention.

67 is a view showing an embodiment related to a specific type of field included in an HDRConfiguration element.

68 is a diagram illustrating an embodiment of a configuration of a common attribute and an element including picture quality improvement information according to an embodiment of the present invention.

69 is a view showing another embodiment of a configuration of a common attribute and an element including picture quality improvement information according to an embodiment of the present invention.

70 is a view illustrating another embodiment of a configuration of a common attribute and an element including picture quality improvement information according to an embodiment of the present invention.

71 is a view showing another embodiment of a configuration of a common attribute and an element including picture quality improvement information according to an embodiment of the present invention.

72 is a diagram illustrating a configuration of a content component including image quality improvement information according to an embodiment of the present invention.

73 is a diagram illustrating a configuration of a segment base including image quality improvement information according to an embodiment of the present invention.

74 is a flowchart illustrating a method of transmitting a broadcast signal according to an embodiment of the present invention.

75 is a diagram illustrating a configuration of an apparatus for transmitting a broadcast signal according to an embodiment of the present invention.

76 is a flowchart illustrating a method of receiving a broadcast signal according to an embodiment of the present invention.

77 is a diagram showing the configuration of an apparatus for receiving a broadcast signal according to an embodiment of the present invention.

Preferred embodiments of the present invention will be described in detail, examples of which are illustrated in the accompanying drawings. DETAILED DESCRIPTION The following detailed description with reference to the accompanying drawings is intended to explain preferred embodiments of the invention rather than to show only embodiments that may be implemented in accordance with embodiments of the 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 ones widely used in the art, but some terms are arbitrarily selected by the applicant, and their meanings are described in detail in the following description as necessary. Therefore, the present invention should be understood based on the intended meaning of the term and not the simple name or meaning of the term.

The present invention provides an apparatus and method for transmitting and receiving broadcast signals for next generation broadcast services. The next generation broadcast service according to an embodiment of the present invention includes a terrestrial broadcast service, a mobile broadcast service, a UHDTV service, and the like. According to an embodiment of the present invention, a broadcast signal for a next generation broadcast service may be processed through 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) that is optimized to minimize receiver complexity while achieving the performance required for a particular application.

The service may be delivered to the receiver through a plurality of layers. First, the transmitting side can generate service data. The delivery layer on the transmitting side performs processing for transmission to the service data, and the physical layer encodes it as a broadcast signal and transmits it through a broadcasting network or broadband.

The service data may be generated in a format according to ISO BMFF (base media file format). The ISO BMFF media file may be used in broadcast network / broadband delivery, media encapsulation and / or synchronization format. In this case, the service data is all data related to the service, and may include a concept including service components constituting the linear service, signaling information thereof, non real time (NRT) data, and other files.

The delivery layer will be described. The delivery layer may provide a transmission function for service data. The service data may be delivered through a broadcast network and / or broadband.

There may be two methods for broadcast service delivery through a broadcasting network.

The first method may be to process service data into Media Processing Units (MPUs) based on MPEG Media Transport (MMT) and transmit the data using MMM protocol (MMTP). In this case, the service data delivered through the MMTP may include service components for linear service and / or service signaling information thereof.

The second method may be to process service data into DASH segments based on MPEG DASH and transmit it using Real Time Object Delivery over Unidirectional Transport (ROUTE). In this case, the service data delivered through the ROUTE protocol may include service components for the linear service, service signaling information and / or NRT data thereof. That is, non-timed data such as NRT data and files may be delivered through ROUTE.

Data processed according to the MMTP or ROUTE protocol may be processed into IP packets via the UDP / IP layer. In service data transmission through a broadcasting network, a service list table (SLT) may also be transmitted through a broadcasting network through a UDP / IP layer. The SLT may be included in the LLS (Low Level Signaling) table and transmitted. The SLT and the LLS table will be described later.

IP packets may be treated as link layer packets at the link layer. The link layer may encapsulate data of various formats delivered from an upper layer into a link layer packet and then deliver the data to the physical layer. The link layer will be described later.

In hybrid service delivery, at least one or more service elements may be delivered via a broadband path. In the case of hybrid service delivery, the data transmitted through the broadband may include service components in a DASH format, service signaling information and / or NRT data thereof. This data can be processed via HTTP / TCP / IP, passed through the link layer for broadband transmission, and delivered to the physical layer for broadband transmission.

The physical layer may process data received from a delivery layer (upper layer and / or link layer) and transmit the data through a broadcast network or a broadband. Details of the physical layer will be described later.

Describe the service. The service may be a collection of service components that are shown to the user as a whole, the components may be of different media types, the service may be continuous or intermittent, the service may be real time or non-real time, and the real time service may be a sequence of TV programs. It can be configured as.

Services can have many types. Firstly, the service may be a linear audio / video or audio only service that may have app-based enhancements. Secondly, the service may be an app-based service whose reproduction / configuration is controlled by the downloaded application. Third, the service may be an ESG service that provides an electronic service guide (ESG). Fourth, it may be an Emergency Alert (EA) service that provides emergency alert information.

When a linear service without app-based enhancement is delivered through the broadcasting network, the service component may be delivered by (1) one or more ROUTE sessions or (2) one or more MMTP sessions.

When a linear service with app-based enhancement is delivered through a broadcast network, the service component may be delivered by (1) one or more ROUTE sessions and (2) zero or more MMTP sessions. In this case, data used for app-based enhancement may be delivered through a ROUTE session in the form of NRT data or other files. In one embodiment of the invention, linear service components (streaming media components) of one service may not be allowed to be delivered using both protocols simultaneously.

When the app-based service is delivered through the broadcast network, the service component may be delivered by one or more ROUTE sessions. In this case, the service data used for the app-based service may be delivered through a ROUTE session in the form of NRT data or other files.

In addition, some service components or some NRT data, files, etc. of these services may be delivered via broadband (hybrid service delivery).

That is, in one embodiment of the present invention, the linear service components of one service may be delivered through the MMT protocol. In another embodiment of the present invention, the linear service components of one service may be delivered via a ROUTE protocol. In another embodiment of the present invention, the linear service component and NRT data (NRT service component) of one service may be delivered through the ROUTE protocol. In another embodiment of the present invention, linear service components of one service may be delivered through the MMT protocol, and NRT data (NRT service components) may be delivered through the ROUTE protocol. In the above embodiments, some service component or some NRT data of a service may be delivered over broadband. Here, the data related to the app-based service or the app-based enhancement may be transmitted through a broadcast network according to ROUTE or through broadband in the form of NRT data. NRT data may also be referred to as locally cashed data.

Each ROUTE session includes one or more LCT sessions that deliver, in whole or in part, the content components that make up the service. In streaming service delivery, an LCT session may deliver an individual component of a user service, such as an audio, video, or closed caption stream. Streaming media is formatted into a DASH segment.

Each MMTP session includes one or more MMTP packet flows carrying an MMT signaling message or all or some content components. The MMTP packet flow may carry a component formatted with an MMT signaling message or an MPU.

For delivery of NRT user service or system metadata, an LCT session carries a file based content item. These content files may consist of continuous (timed) or discrete (non-timed) media components of an NRT service, or metadata such as service signaling or ESG fragments. Delivery of system metadata, such as service signaling or ESG fragments, can also be accomplished through the signaling message mode of the MMTP.

At the receiver, the tuner can scan frequencies and detect broadcast signals at specific frequencies. The receiver can extract the SLT and send it to the module that processes it. The SLT parser can parse the SLT, obtain data, and store it in the channel map. The receiver may acquire bootstrap information of the SLT and deliver it to the ROUTE or MMT client. This allows the receiver to obtain and store the SLS. USBD or the like can be obtained, which can be parsed by the signaling parser.

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

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

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

The SLS is signaling information describing characteristics of a corresponding service and may include information for acquiring a corresponding service and a service component of the corresponding service, or may include receiver capability information for reproducing the corresponding service significantly. Having separate service signaling for each service allows the receiver to obtain the appropriate SLS for the desired service without having to parse the entire SLS delivered in the broadcast stream.

When the SLS is delivered through the ROUTE protocol, the SLS may be delivered through a dedicated LCT channel of a ROUTE session indicated by the SLT. In some embodiments, this LCT channel may be an LCT channel identified by tsi = 0. In this case, the SLS may include a user service bundle description (USBD / USD), a service-based transport session instance description (S-TSID), and / or a media presentation description (MPD).

Here, USBD to USD is one of the SLS fragments and may serve as a signaling hub for describing 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. The USBD may further include metadata information that enables the receiver to determine the transmission mode (broadcast network / broadband). Details of the USBD / USD will be described later.

The S-TSID is one of the SLS fragments, and may provide overall session description information for a transport session carrying a service component of a corresponding service. The S-TSID may provide transport session description information for the ROUTE session to which the service component of the corresponding service is delivered and / or the LCT channel of the ROUTE sessions. The S-TSID may provide component acquisition information of service components related to one service. The S-TSID may provide a mapping between the DASH Representation of the MPD and the tsi of the corresponding service component. The component acquisition information of the S-TSID may be provided in the form of tsi, an identifier of an associated DASH representation, and may or may not include a PLP ID according to an embodiment. The component acquisition information enables the receiver to collect audio / video components of a service and to buffer, decode, and the like of DASH media segments. The S-TSID may be referenced by the USBD as described above. Details of the S-TSID will be described later.

The MPD is one of the SLS fragments and may provide a description of the DASH media presentation of the service. The MPD may provide a resource identifier for the media segments and may provide contextual information within the media presentation for the identified resources. The MPD may describe the DASH representation (service component) delivered through the broadcast network, and may also describe additional DASH representations delivered through the broadband (hybrid delivery). The MPD may be referenced by the USBD as described above.

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

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

The MP table is a signaling message of the MMT for MPU components and may provide overall session description information for an MMTP session carrying a service component of a corresponding service. The MP table may also contain descriptions for assets delivered via this MMTP session. The MP table is streaming signaling information for MPU components, and may provide a list of assets corresponding to one service and location information (component acquisition information) of these components. Specific contents of the MP table may be in a form defined in MMT or a form in which modifications are made. Here, Asset is a multimedia data entity, which may mean a data entity associated with one unique ID and used to generate one multimedia presentation. Asset may correspond to a service component constituting a service. The MP table may be used to access a streaming service component (MPU) corresponding to a desired service. The MP table may be referenced by the USBD as described above.

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

ROUTE sessions are identified by source IP address, destination IP address, and destination port number. The LCT session is identified by a transport session identifier (TSI) that is unique within the scope of the parent ROUTE session. MMTP sessions are identified by destination IP address and destination port number. The MMTP packet flow is identified by a unique packet_id within the scope of the parent MMTP session.

In case of ROUTE, the S-TSID, the USBD / USD, the MPD, or the LCT session carrying them may be called a service signaling channel. In the case of MMTP, USBD / UD, MMT signaling messages or packet flow carrying them may be called a service signaling channel.

Unlike the illustrated embodiment, one ROUTE or MMTP session may be delivered through a plurality of PLPs. That is, one service may be delivered through one or more PLPs. Unlike shown, components constituting one service may be delivered through different ROUTE sessions. In addition, according to an embodiment, components constituting one service may be delivered through different MMTP sessions. According to an embodiment, components constituting one service may be delivered divided into a ROUTE session and an MMTP session. Although not shown, a component constituting one service may be delivered through a broadband (hybrid delivery).

An 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 a type of the corresponding LLS table, and the provider_id field may identify service providers related to services signaled by the corresponding LLS table. Here, the service provider is a broadcaster using all or part of the broadcast stream, and the provider_id field may identify one of a plurality of broadcasters using the broadcast stream. The LLS_table_version field may provide version information of a corresponding LLS table.

According to the value of the LLS_table_id field, the corresponding LLS table includes the above-described SLT, a rating region table (RRT) including information related to a content advisory rating, a SystemTime information providing information related to system time, and an emergency alert. It may include one of the CAP (Common Alert Protocol) message that provides information related to. According to an embodiment, other information other than these may be included in the LLS table.

One embodiment t3020 of the illustrated SLT may include an @bsid attribute, an @sltCapabilities attribute, a sltInetUrl element, and / or a Service element. Each field may be omitted or may exist in plurality, depending on the value of the illustrated Use column.

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

The service element may be an element including information on services described by the corresponding SLT, and a service element may exist for each service. The Service element contains the @serviceId property, the @sltSvcSeqNum property, the @protected property, the @majorChannelNo property, the @minorChannelNo property, the @serviceCategory property, the @shortServiceName property, the @hidden property, the @broadbandAccessRequired property, the @svcCapabilities property, the BroadcastSvcSignaling element, and / or the svcInetUrl element. It may include.

The @serviceId attribute may be an identifier of a corresponding service, and the @sltSvcSeqNum attribute may indicate a sequence number of SLT information for the corresponding service. The @protected attribute may indicate whether at least one service component necessary for meaningful playback of the corresponding service is protected. The @majorChannelNo and @minorChannelNo attributes may indicate the major channel number and the minor channel number of the corresponding service, respectively.

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

The BroadcastSvcSignaling element may provide information related to broadcast signaling of a corresponding service. This element may provide information such as a location, a protocol, and an address with respect to signaling through a broadcasting network of a corresponding service. Details will be described later.

The svcInetUrl element may provide URL information for accessing signaling information for a corresponding service through broadband. The sltInetUrl element may further include an @urlType attribute, which may indicate the type of data that can be obtained through the URL.

The aforementioned BroadcastSvcSignaling element may include an @slsProtocol attribute, an @slsMajorProtocolVersion attribute, an @slsMinorProtocolVersion attribute, an @slsPlpId attribute, an @slsDestinationIpAddress attribute, an @slsDestinationUdpPort attribute, and / or an @slsSourceIpAddress attribute.

The @slsProtocol attribute can indicate the protocol used to deliver the SLS of the service (ROUTE, MMT, etc.). The @slsMajorProtocolVersion attribute and @slsMinorProtocolVersion attribute may indicate the major version number and the minor version number of the protocol used to deliver the SLS of the corresponding service, respectively.

The @slsPlpId attribute may provide a PLP identifier for identifying a PLP that delivers the SLS of the corresponding service. In some embodiments, this field may be omitted, and the PLP information to which the SLS is delivered may be identified by combining information in the LMT to be described later and bootstrap information of the SLT.

The @slsDestinationIpAddress attribute, @slsDestinationUdpPort attribute, and @slsSourceIpAddress attribute may indicate the destination IP address, the destination UDP port, and the source IP address of the transport packet carrying the SLS of the corresponding service, respectively. They can identify the transport session (ROUTE session or MMTP session) to which the SLS is delivered. These may be included in the bootstrap information.

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

The userServiceDescription element may include an @globalServiceID attribute, an @serviceId attribute, an @serviceStatus attribute, an @fullMPDUri attribute, an @sTSIDUri attribute, a name element, a serviceLanguage element, a capabilityCode element, and / or a deliveryMethod element. Each field may be omitted or may exist in plurality, depending on the value of the illustrated Use column.

The @globalServiceID attribute is a globally unique identifier of the service and can be used to link with 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 service ID information of the SLT. The @serviceStatus attribute may indicate the status of the corresponding service. This field may indicate whether the corresponding service is active or inactive.

The @fullMPDUri attribute can refer to the MPD fragment of the service. As described above, the MPD may provide a reproduction description for a service component delivered through a broadcast network or a broadband. The @sTSIDUri attribute may refer to the S-TSID fragment of the service. The S-TSID may provide parameters related to access to the transport session carrying the service as described above.

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

The capabilityCode element may indicate capability or capability group information of the receiver side necessary for significantly playing a corresponding service. This information may be compatible with the capability information format provided by the service announcement.

The deliveryMethod element may provide delivery related information with respect to contents accessed through a broadcasting network or a broadband of a corresponding service. The deliveryMethod element may include a broadcastAppService element and / or a unicastAppService element. Each of these elements may have a basePattern element as its child element.

The broadcastAppService element may include transmission related information on the DASH presentation delivered through the broadcast network. These DASH representations may include media components across all periods of the service media presentation.

The basePattern element of this element may represent a character pattern used by the receiver to match the segment URL. This can be used by the DASH client to request segments of the representation. Matching may imply that the media segment is delivered over the broadcast network.

The unicastAppService element may include transmission related information on the DASH representation delivered through broadband. These DASH representations may include media components across all periods of the service media presentation.

The basePattern element of this element may represent a character pattern used by the receiver to match the segment URL. This can be used by the DASH client to request segments of the representation. Matching may imply that the media segment is delivered over broadband.

An embodiment t4020 of the illustrated S-TSID may have an S-TSID root element. The S-TSID root element may include an @serviceId attribute and / or an RS element. Each field may be omitted or may exist in plurality, depending on the value of the illustrated Use column.

The @serviceId attribute is an identifier of a corresponding service and may refer to a corresponding service of USBD / USD. The RS element may describe information on ROUTE sessions through which service components of a corresponding service are delivered. Depending on the number of such ROUTE sessions, there may be a plurality of these elements. The RS element may further include an @bsid attribute, an @sIpAddr attribute, an @dIpAddr attribute, an @dport attribute, an @PLPID attribute, and / or an LS element.

The @bsid attribute may be an identifier of a broadcast stream through which service components of a corresponding service are delivered. 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 @bsid attribute of SLT.

The @sIpAddr attribute, the @dIpAddr attribute, and the @dport attribute may indicate a source IP address, a destination IP address, and a destination UDP port of the corresponding ROUTE session, respectively. If these fields are omitted, the default values may be the source IP address, destination IP address, and destination UDP port values of the current, ROUTE session carrying that SLS, that is, carrying that S-TSID. For other ROUTE sessions that carry service components of the service but not the current ROUTE session, these fields may not be omitted.

The @PLPID attribute may indicate PLP ID information of a 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 being delivered. According to an embodiment, this field is omitted, and the PLP ID information of the corresponding ROUTE session may be confirmed by combining information in the LMT to be described later and IP address / UDP port information of the RS element.

The LS element may describe information on LCT channels through which service components of a corresponding service are delivered. Depending on the number of such LCT channels, there may be a plurality of these elements. The LS element may include an @tsi attribute, an @PLPID attribute, an @bw attribute, an @startTime attribute, an @endTime attribute, an SrcFlow element, and / or a RepairFlow element.

The @tsi attribute may represent tsi information of a corresponding LCT channel. Through this, LCT channels through which a service component of a corresponding service is delivered may be identified. The @PLPID attribute may represent PLP ID information of a 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 LCT session, and the @endTime attribute may indicate the end time of the LCT channel.

The SrcFlow element may describe the source flow of ROUTE. The source protocol of ROUTE is used to transmit the delivery object, and can establish at least one source flow in one ROUTE session. These source flows can deliver related objects as an object flow.

The RepairFlow element may describe the repair flow of ROUTE. Delivery objects delivered according to the source protocol may be protected according to Forward Error Correction (FEC). The repair protocol may define a FEC framework that enables such FEC protection.

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

The userServiceDescription element may include an @globalServiceID attribute, an @serviceId attribute, a Name element, a serviceLanguage element, a contentAdvisoryRating element, a Channel element, an mpuComponent element, a routeComponent element, a broadbandComponent element, and / or a ComponentInfo element. Each field may be omitted or may exist in plurality, depending on the value of the illustrated Use column.

The @globalServiceID attribute, the @serviceId attribute, the Name element and / or the serviceLanguage element may be the same as the corresponding fields of the USBD delivered to the above-described ROUTE. The contentAdvisoryRating element may indicate the content advisory rating of the corresponding service. This information may be compatible with the content advisory rating information format provided by the service announcement. The channel element may include information related to the corresponding service. The detail of this element is mentioned later.

The mpuComponent element may provide a description for service components delivered as an MPU of a corresponding service. This element may further include an @mmtPackageId attribute and / or an @nextMmtPackageId attribute. The @mmtPackageId attribute may refer to an MMT package of service components delivered as an MPU of a corresponding service. The @nextMmtPackageId attribute may refer to an MMT package to be used next to the MMT package referenced by the @mmtPackageId attribute in time. The MP table can be referenced through the information of this element.

The routeComponent element may include a description of service components of the corresponding service delivered to ROUTE. Even if the linear service components are delivered in the MMT protocol, the NRT data may be delivered according to the ROUTE protocol as described above. This element may describe information about such NRT data. The detail of this element is mentioned later.

The broadbandComponent element may include a description of service components of the corresponding service delivered over broadband. In hybrid service delivery, some service components or other files of a service may be delivered over broadband. This element may describe information about these data. This element may further include the @fullMPDUri attribute. This attribute may refer to an MPD that describes service components delivered over broadband. In addition to the hybrid service delivery, when the broadcast signal is weakened due to driving in a tunnel or the like, the element may be needed to support handoff between the broadcast network and the broadband band. When the broadcast signal is weakened, while acquiring the service component through broadband, and when the broadcast signal is stronger, the service continuity may be guaranteed by acquiring the service component through the broadcast network.

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

The aforementioned channel element may further include an @serviceGenre attribute, an @serviceIcon attribute, and / or a ServiceDescription element. The @serviceGenre attribute may indicate the genre of the corresponding service, and the @serviceIcon attribute may include URL information of an icon representing the corresponding service. The ServiceDescription element provides a service description of the service, which may further include an @serviceDescrText attribute and / or an @serviceDescrLang attribute. Each of these attributes may indicate the text of the service description and the language used for that text.

The aforementioned routeComponent element may further include an @sTSIDUri attribute, an @sTSIDDestinationIpAddress attribute, an @sTSIDDestinationUdpPort attribute, an @sTSIDSourceIpAddress attribute, an @sTSIDMajorProtocolVersion attribute, and / or an @sTSIDMinorProtocolVersion attribute.

The @sTSIDUri attribute may refer to an S-TSID fragment. This field may be the same as the corresponding field of USBD delivered to ROUTE described above. This S-TSID may provide access related information for service components delivered in ROUTE. This S-TSID may exist for NRT data delivered according to the ROUTE protocol in the situation where linear service components are delivered according to the MMT protocol.

The @sTSIDDestinationIpAddress attribute, the @sTSIDDestinationUdpPort attribute, and the @sTSIDSourceIpAddress attribute may indicate a destination IP address, a destination UDP port, and a source IP address of a transport packet carrying the aforementioned S-TSID, respectively. That is, these fields may identify a transport session (MMTP session or ROUTE session) carrying the aforementioned S-TSID.

The @sTSIDMajorProtocolVersion attribute and the @sTSIDMinorProtocolVersion attribute may indicate a major version number and a minor version number of the transport protocol used to deliver the aforementioned S-TSID.

The above-mentioned ComponentInfo element may further include an @componentType attribute, an @componentRole attribute, an @componentProtectedFlag attribute, an @componentId attribute, and / or an @componentName attribute.

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

The @componentProtectedFlag attribute may indicate whether a corresponding service component is protected, for example, encrypted. The @componentId attribute may represent an identifier of a corresponding service component. The value of this attribute may be a value such as asset_id (asset ID) of the MP table corresponding to this service component. The @componentName attribute may represent the name of the corresponding service component.

The link layer may be a layer between the physical layer and the network layer. The transmitter may transmit data from the network layer to the physical layer, and the receiver may transmit data from the physical layer to the network layer (t6010). The purpose of the link layer may be to compress all input packet types into one format for processing by the physical layer, to ensure flexibility and future scalability for input packet types not yet defined. have. In addition, the link layer may provide an option of compressing unnecessary information in the header of the input packet, so that the input data may be efficiently transmitted. Operations such as overhead reduction and encapsulation of the link layer may be referred to as a link layer protocol, and a packet generated using the corresponding protocol may be referred to as a link layer packet. The link layer may perform functions such as packet encapsulation, overhead reduction, and / or signaling transmission.

As a reference on the transmission side, the link layer ALP may perform an overhead reduction process on input packets and then encapsulate them into link layer packets. In addition, according to an embodiment, the link layer may encapsulate the link layer packet without performing an overhead reduction process. The use of the link layer protocol can greatly reduce the overhead for data transmission on the physical layer, and the link layer protocol according to the present invention can provide IP overhead reduction and / or MPEG-2 TS overhead reduction. have.

In the case where the illustrated IP packet is input as an input packet (t6010), the link layer may sequentially perform IP header compression, adaptation, and / or encapsulation. In some embodiments, some processes may be omitted. First, the RoHC module performs IP packet header compression to reduce unnecessary overhead, and context information may be extracted and transmitted out of band through an adaptation process. The IP header compression and adaptation process may be collectively called IP header compression. Thereafter, IP packets may be encapsulated into link layer packets through an encapsulation process.

In the case where the MPEG 2 TS packet is input as an input packet, the link layer may sequentially perform an overhead reduction and / or encapsulation process for the TS packet. In some embodiments, some processes may be omitted. In overhead reduction, the link layer may provide sync byte removal, null packet deletion and / or common header removal (compression). Sync byte elimination can provide overhead reduction of 1 byte per TS packet. Null packet deletion can be performed in a manner that can be reinserted at the receiving end. In addition, common information between successive headers can be deleted (compressed) in a manner that can be recovered at the receiving side. Some of each overhead reduction process may be omitted. Thereafter, TS packets may be encapsulated into link layer packets through an encapsulation process. The link layer packet structure for encapsulation of TS packets may be different from other types of packets.

First, IP header compression will be described.

The IP packet has a fixed header format, but some information required in a communication environment may be unnecessary in a broadcast environment. The link layer protocol may provide a mechanism to reduce broadcast overhead by compressing the header of the IP packet.

IP header compression may include a header compressor / decompressor and / or adaptation module. The IP header compressor (RoHC compressor) may reduce the size of each IP packet header based on the RoHC scheme. The adaptation module may then extract the context information and generate signaling information from each packet stream. The receiver may parse signaling information related to the packet stream and attach context information to the packet stream. The RoHC decompressor can reconstruct the original IP packet by recovering the packet header. Hereinafter, IP header compression may mean only IP header compression by a header compressor, or may mean a concept in which the IP header compression and the adaptation process by the adaptation module are combined. The same is true for decompressing.

Hereinafter, the adaptation will be described.

In the case of transmissions on the unidirectional link, if the receiver does not have the context information, the decompressor cannot recover the received packet headers until it receives the complete context. This can result in channel change delays and turn-on delays. Therefore, the configuration parameter and context information between the compressor / decompressor can be transmitted out of band through the adaptation function. The adaptation function may generate link layer signaling using context information and / or configuration parameters. The adaptation function may periodically send link layer signaling over each physical frame using previous configuration parameters and / or context information.

The context information is extracted from the compressed IP packets, and various methods may be used according to the adaptation mode.

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

Mode # 2 may be a mode for extracting context information (static chain) by detecting IR packets in the compressed packet stream. After extraction, the IR packet is converted into an IR-DYN packet, and the IR-DYN packet can be transmitted in the same order in the packet stream by replacing the original IR packet.

Mode # 3 t6020 may be a mode for detecting IR and IR-DYN packets and extracting context information from the compressed packet stream. Static chains and dynamic chains can be extracted from IR packets and dynamic chains can be extracted from IR-DYN packets. After extraction, the IR and IR-DYN packets can be converted into regular compressed packets. The switched packets can be sent in the same order within the packet stream, replacing the original IR and IR-DYN packets.

In each mode, the remaining packets after the context information is extracted may be encapsulated and transmitted according to the link layer packet structure for the compressed IP packet. The context information may be transmitted by being encapsulated according to a link layer packet structure for signaling information as link layer signaling.

The extracted context information may be included in the RoHC-U Description Table (RTT) and transmitted separately from the RoHC packet flow. The context information may be transmitted through a specific physical data path along with other signaling information. According to an embodiment, a specific physical data path may mean one of general PLPs, a PLP to which LLS (Low Level Signaling) is delivered, a dedicated PLP, or an L1 signaling path. 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 whenever the context information changes. In some embodiments, the RDT may be transmitted in every physical frame. In order to transmit the RDT in every physical frame, a previous RDT may be re-use.

Prior to acquiring the packet stream, the receiver may first select PLP to acquire signaling information such as SLT, RDT, LMT, and the like. When the signaling information is obtained, the receiver may combine these to obtain a mapping between the service-IP information-context information-PLP. That is, the receiver can know which service is transmitted to which IP streams, which IP streams are delivered to which PLP, and can also obtain corresponding context information of the PLPs. The receiver can select and decode a PLP carrying a particular packet stream. The adaptation module can parse the context information and merge it with the compressed packets. This allows the packet stream to be recovered, which can be delivered to the RoHC decompressor. Decompression can then begin. At this time, the receiver detects the IR packet and starts decompression from the first received IR packet according to the adaptation mode (mode 1), or detects the IR-DYN packet to perform decompression from the first received IR-DYN packet. Can start (mode 2), or start decompression from any normal compressed packet (mode 3).

Hereinafter, packet encapsulation will be described.

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

Segmentation may be utilized in the packet encapsulation process. If the network layer packet is too large to be processed by the physical layer, the network layer packet may be divided into two or more segments. The link layer packet header may include fields for performing division at the transmitting side and recombination at the receiving side. Each segment may be encapsulated into a link layer packet in the same order as the original position.

Concatenation may also be utilized in the packet encapsulation process. If the network layer packet is small enough that the payload of the link layer packet includes several network layer packets, concatenation may be performed. The link layer packet header may include fields for executing concatenation. In the case of concatenation, each input packet may be encapsulated into the payload of the link layer packet 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 may be added depending on the chaining or splitting, and the additional header may include necessary fields according to the situation. In addition, an optional header may be further added to transmit additional information. Each header structure may be predefined. As described above, when the input packet is a TS packet, a link layer header structure different from other packets may be used.

Hereinafter, link layer signaling will be described.

Link layer signaling may operate at a lower level than the IP layer. The receiving side can acquire the link layer signaling faster than the IP level signaling such as LLS, SLT, SLS, and the like. Therefore, link layer signaling may be obtained before session establishment.

Link layer signaling may include internal link layer signaling and external link layer signaling. Internal link layer signaling may be signaling information generated in the link layer. The above-described RDT or LMT to be described later may correspond to this. The external link layer signaling may be signaling information received from an external module, an external protocol, or an upper layer. The link layer may encapsulate link layer signaling into a link layer packet and deliver it. A link layer packet structure (header structure) for link layer signaling may be defined, and link layer signaling information may be encapsulated according to this structure.

The LMT may provide a list of higher layer sessions carried by the PLP. The LMT may also provide additional information for processing link layer packets carrying higher layer sessions. In this case, the higher layer session may be called multicast. Information on which IP streams and which transport sessions are being transmitted through a specific PLP may be obtained through the LMT. Conversely, information on which PLP a specific transport session is delivered to may be obtained.

The LMT may be delivered to any PLP identified as carrying an LLS. Here, the PLP through which the LLS is delivered may 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 LLS is delivered to the corresponding PLP for each PLP. The L1 detail signaling information may correspond to PLS2 data to be described later.

That is, the LMT may be delivered to the same PLP together with the LLS. Each LMT may describe the mapping between PLPs and IP address / port as described above. As mentioned above, the LLS may include an SLT, where these IP addresses / ports described by the LMT are all IP addresses associated with any service described by the SLT forwarded to the same PLP as that LMT. It can be / ports.

According to an embodiment, the PLP identifier information in the above-described SLT, SLS, etc. may be utilized, so that information on which PLP the specific transmission session indicated by the SLT, SLS is transmitted may be confirmed.

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

The LMT according to the illustrated embodiment may include a signaling_type field, a PLP_ID field, a num_session field, and / or information about respective sessions. Although the LMT of the illustrated embodiment describes IP streams transmitted to one PLP for one PLP, a PLP loop may be added to the LMT according to an embodiment, so that information on a plurality of PLPs may be described. In this case, as described above, the LMT may describe PLPs for all IP addresses / ports related to all services described by the SLTs delivered together, in a PLP loop.

The signaling_type field may indicate the type of signaling information carried by the corresponding table. The value of the signaling_type field for the LMT may be set to 0x01. The signaling_type field may be omitted. The PLP_ID field may identify a target PLP to be described. When a PLP loop is used, each PLP_ID field may identify each target PLP. From the PLP_ID field may be included in the PLP loop. The PLP_ID field mentioned below is an identifier for one PLP in a PLP loop, and the fields described below may be fields for the corresponding PLP.

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

The src_IP_add field, dst_IP_add field, src_UDP_port field, and dst_UDP_port field are the source IP address, destination IP address, source UDP port, destination UDP port for the transport session among the upper layer sessions forwarded to the PLP identified by the corresponding PLP_ID field. It can indicate a port.

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

The compressed_flag field may indicate whether header compression has been applied to data of a link layer packet carrying a corresponding transport session. In addition, the existence of the context_id field to be described later may be determined according to the value of this field. When header compression is applied (compressed_flag = 1), an RDT may exist, and the PLP ID field of the RDT may have the same value as the corresponding PLP_ID field associated with this compressed_flag field.

The SID field may indicate a sub stream ID (SID) for link layer packets carrying a corresponding transport session. These link layer packets may include an SID having the same value as this SID field in the optional header. Through this, the receiver can filter the link layer packets by using the information of the LMT and the SID information of the link layer packet header without parsing all the link layer packets.

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

In the above-described embodiments of the signaling information / table of the present invention, each field, element, or attribute may be omitted or replaced by another field, and additional fields, elements, or attributes may be added according to an embodiment. .

In one embodiment of the present invention, service components of one service may be delivered through a plurality of ROUTE sessions. In this case, the SLS may be obtained through the bootstrap information of the SLT. The SLS's USBD allows the S-TSID and MPD to be referenced. The S-TSID may describe transport session description information for other ROUTE sessions to which service components are delivered, as well as a ROUTE session to which an SLS is being delivered. Through this, all service components delivered through a plurality of ROUTE sessions may be collected. This may be similarly applied when service components of a service are delivered through a plurality of MMTP sessions. For reference, one service component may be used simultaneously by a plurality of services.

In another embodiment of the present invention, bootstrapping for ESG services may be performed by a broadcast network or broadband. Through ESG acquisition through broadband, URL information of the SLT may be utilized. ESG information and the like can be requested to this URL.

In another embodiment of the present invention, one service component of one service may be delivered to the broadcasting network and one to the broadband (hybrid). The S-TSID may describe components delivered to a broadcasting network, so that a ROUTE client may acquire desired service components. USBD also has base pattern information, which allows you to describe which segments (which components) are to be routed to which path. Therefore, the receiver can use this to know what segment to request to the broadband server and what segment to find in the broadcast stream.

In another embodiment of the present invention, scalable coding for a service may be performed. The USBD may have all the capability information needed to render the service. For example, when a service is provided in HD or UHD, the capability information of the USBD may have a value of “HD or UHD”. The receiver may know which component should be played in order to render the UHD or HD service using the MPD.

In another embodiment of the present invention, through the TOI field of the LCT packets delivered to the LCT channel carrying SLS, which SLS fragments the corresponding LCT packets carry (USBD, S-TSID, MPD, etc.) Can be identified.

In another embodiment of the present invention, app components to be used for app-based enhancement / app-based service may be delivered through a broadcast network or through broadband as an NRT component. In addition, app signaling for app-based enhancement may be performed by an application signaling table (AST) delivered with SLS. In addition, an event, which is a signaling of an operation to be performed by the app, may be delivered in the form of an event message table (EMT) with SLS, signaled in an MPD, or in-band signaled in a box in a DASH representation. . AST, EMT, etc. may be delivered via broadband. App-based enhancement may be provided using the collected app components and such signaling information.

In another embodiment of the present invention, a CAP message may be included in the aforementioned LLS table for emergency alerting. Rich media content for emergency alerts may also be provided. Rich media may be signaled by the CAP message, and if rich media is present it may be provided as an EAS service signaled by the SLT.

In another embodiment of the present invention, the linear service components may be delivered through a broadcasting network according to the MMT protocol. In this case, NRT data (for example, an app component) for a corresponding service may be delivered through a broadcasting network according to the ROUTE protocol. In addition, data on the service may be delivered through broadband. The receiver can access the MMTP session carrying the SLS using the bootstrap information of the SLT. The USBD of the SLS according to the MMT may refer to the MP table so that the receiver may acquire linear service components formatted with the MPU delivered according to the MMT protocol. In addition, the USBD may further refer to the S-TSID to allow the receiver to obtain NRT data delivered according to the ROUTE protocol. In addition, the USBD may further reference the MPD to provide a playback description for the data delivered over the broadband.

In another embodiment of the present invention, the receiver may transmit location URL information for obtaining a streaming component and / or a file content item (such as a file) to the companion device through a method such as a web socket. An application of a companion device may request the component, data, and the like by requesting the URL through an HTTP GET. In addition, the receiver may transmit information such as system time information and emergency alert information to the companion device.

The hybrid broadcasting system may transmit a broadcast signal by interworking a terrestrial broadcasting network and an internet network. The hybrid broadcast reception device may receive a broadcast signal through a terrestrial broadcast network (broadcast) and an internet network (broadband). The hybrid broadcast receiver 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, 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 modules can do.

The physical layer module (s) may receive and process a broadcast-related signal through a terrestrial broadcast channel, convert it into an appropriate form, and deliver the signal to a physical layer I / F module.

The physical layer I / F module (s) may obtain an IP datagram from information obtained from the physical layer module. In addition, the physical layer I / F module may convert the obtained IP datagram into a specific frame (eg, RS Frame, GSE, etc.).

The service / content acquisition controller may perform a control operation for acquiring service, content, and signaling data related thereto through broadcast and / or broadband channels.

The Internet Access Control Module (s) may control a receiver operation for acquiring a service, content, or the like through a broadband channel.

The signaling decoder may decode signaling information obtained through a broadcast channel.

The service signaling manager may extract, parse, and manage signaling information related to service scan and service / content from an IP datagram.

The service guide manager may extract announcement information from an IP datagram, manage an SG database, and provide a service guide.

The App Signaling Manager may extract, parse and manage signaling information related to application acquisition from an IP datagram.

Alert Signaling Parser can extract, parse and manage signaling information related to alerting from IP datagram.

Targeting Signaling Parser can extract, parse and manage signaling information related to service / content personalization or targeting from IP datagram. In addition, the targeting signal parser may deliver the parsed signaling information to the targeting processor.

The streaming media engine can extract and decode audio / video data for A / V streaming from IP datagrams.

The non-real time file processor can extract, decode and manage file type data such as NRT data and applications from IP datagrams.

The Component Synchronizer can synchronize content and services such as streaming audio / video data and NRT data.

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

The App Processor may process application related information, downloaded application status, and display parameters.

The A / V Processor may perform audio / video rendering related operations based on decoded audio, video data, and application data.

The device manager may perform a connection and data exchange operation with an external device. In addition, the device manager may perform management operations on external devices, such as adding, deleting, and updating external devices that can be interworked.

The data sharing & communication unit 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, or the like.

The redistribution module (s) may obtain relevant information about next-generation broadcast services and contents when the broadcast receiver does not directly receive the terrestrial broadcast signal. In addition, the redistribution module may support the acquisition of broadcast services and content by the next generation broadcast system when the broadcast receiver does not directly receive the terrestrial broadcast signal.

Companion device (s) may be connected to the broadcast receiver of the present invention to share audio, video, or signaling inclusion data. The companion device may refer to an external device connected to the 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.

The present invention proposes a next-generation media service providing method for providing content capable of supporting High Dynamic Range (HDR). In the case where HDR content capable of expressing rich brightness is provided, the present invention proposes metadata and a delivery method thereof. Through this, the content may be adaptively adjusted according to various scene-specific characteristics of the content, and the content may be provided with improved image quality.

In the case of UHD broadcasting or the like, brightness that cannot be expressed by existing contents can be expressed, thereby providing a high level of realism. With the introduction of HDR, the range of expression of the brightness of the content image is increased, and the difference in the scene-specific characteristics of the content may be larger than before. In order to effectively represent scene-specific features of the content on the display, metadata may be defined and these may be passed to the receiver. At the receiver, based on the received metadata, an image of the content may be appropriately provided as intended by the service provider.

The present invention proposes a method of signaling HDR parameters related to video tracks, video samples, etc. of content providing HDR based on a media file such as ISOBMFF. The present invention proposes a method of storing and signaling HDR flags and / or parameters associated with a video track (stream). The present invention proposes a method of storing and signaling HDR flags and / or parameters related to a video sample, a video sample group or a video sample entry. The present invention proposes a method of storing and signaling an SEI NAL unit including HDR related information.

The storage / delivery method of HDR information according to the present invention may be utilized in the generation of content supporting HDR. That is, the method of the present invention may be utilized when generating a media file for content that supports HDR, generating a DASH segment operating on MPEG DASH, or generating an MPU operating on MPEG MMT. The receiver (including a DASH client, an MMT client, etc.) may obtain HDR information (flag, parameter, box, etc.) from a decoder and the like, and effectively provide the corresponding content based on the information.

HDR configuration box or HDR related flag information, which will be described later, may exist simultaneously in multiple boxes in a media file, DASH segment, or MMT MPU. In this case, the HDR information defined in the upper box may be overridden by the HDR information defined in the lower box. For example, when the HDR information is simultaneously included in the tkhd box and the vmhd box, the HDR information of the tkhd box may be overridden by the HDR information of the vmhd box.

The DASH-based adaptive streaming model according to the illustrated embodiment describes the operation between the HTTP server and the 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. Accordingly, the AV content can be provided without interruption.

First, the DASH client can obtain the MPD. MPD may be delivered from a service provider such as an HTTP server. The MPD may be delivered according to the delivery embodiment described above. The DASH client can request the segments from the server using the access information to the segment described in the MPD. In this case, the request may be performed by reflecting the network state.

After acquiring the segment, the DASH client may process it in the media engine and display the segment on the screen. The DASH client may request and acquire a required segment by adaptively reflecting a playing time and / or a network condition (Adaptive Streaming). This allows the content to be played back seamlessly.

Media Presentation Description (MPD) may be represented in XML form as a file containing detailed information for allowing a DASH client to dynamically acquire a segment. This MPD may be the same as the MPD described above according to an embodiment.

The DASH Client Controller may generate a command for requesting the MPD and / or the segment reflecting the network situation. In addition, the controller can control the obtained information to be used in an internal block of the media engine or the like.

The MPD Parser may parse the acquired MPD in real time. This allows the DASH client controller to generate a command to obtain the required segment.

The segment parser may parse the acquired segment in real time. Internal blocks such as the media engine may perform a specific operation according to the information included in the segment.

The HTTP client may request the HTTP server for necessary MPDs and / or segments. The HTTP client may also pass MPD and / or segments obtained from the server to the MPD parser or segment parser.

The media engine may display content on the screen using media data included in the segment. At this time, the information of the MPD may be utilized.

The transmitting apparatus according to an embodiment of the present invention may enable a DASH-based client to provide an HDR service by signaling high dynamic range (HDR) configuration information in MPEG DASH. That is, the transmission device according to an embodiment of the present invention may signal configuration information on the HDR content itself.

According to an embodiment of the present invention, signaling for high dynamic range (HDR) configuration information in MPEG DASH may be applied to a DASH-based system. For example, it can be applied to ATSC 3.0, DVB IPTV, DASG-based streaming system.

The transmitting apparatus according to an embodiment of the present invention may collect HDR-related parameters (EOTF, bit depth, peak luminance, codec information, metadata, etc.) into one set and signal the configured set. In this case, the transmitting apparatus according to an embodiment of the present invention may signal the HDR type in the MPD since the above-described HDR-related parameter set may not be provided in all receivers.

According to the DASH data model according to an embodiment of the present invention, the media presentation may include one or more periods. One period may include one or more adaptation sets. One adaptation set may include one or more representations. One representation may include one or more segment information. One segment information may include an initialization segment and one or more media segments.

Referring to this figure, the period starting from the media time of 100 seconds has http://dash.com as the baseURL, Adaptation Set 1 for the audio component, Adaptation Set 2 for the video component, and / or Adaptation for the caption component. Include Set 3. Here, Adaptation Set 2 includes Representation 1, Representation 2, and the like. Representation 1 represents a video component having specifications such as bandwidth = 850 kbps, width = 1280 and height = 720, and Representation 2 represents a video component having specifications such as bandwidth = 1250 kbps, width = 1280 and height = 720. Representation 1 includes segment information including information on a segment carrying a video component represented by Representation 1. Segment Information includes duration and / or template information of the segment. In this figure, the segment for the video component represented by Representation 1 has a duration of 10 seconds and has a template of ./video-1-$Number$. In this figure, Representation 1 includes Initialization Segment, Media Segment 1 to Media Segment 10. The segment information includes information on a segment for Representation 1. In this figure, the segment information includes template information of the initialization segment (http://dash.com/video-1), presentation start time information of the media segment 1 (start = 100s), and template information (http://dash.com). / video-1-1), presentation start time information for Media Segment 2 (start = 110s) and template information (http://dash.com/video-1-2), presentation start time information for Media segment 10 (start = 190s) and template information (http://dash.com/video-1-10).

The DASH data model according to an embodiment of the present invention may be expressed as a relationship between an MPD element, a Period element, an AdaptationSet element, a Representation element, a SubRepresentation element, a ContentComponent element, and / or a SegmentBase element.

MPD elements include @id, @profile, @type @availabilityStartTime, @minBufferTime @suggestedPresentationDelay, ProgramInformation (0..N), Location (0..N), Period (0..N), and / or Metrics (0 .. N). Here, @profile and / or @minBufferTime may be a mandatory field.

Period elements include @id, @start, @duration, AssetIdentifier (0..1), EventStream (0..N), AdaptationSet (0..N), and / or Subset (0..N).

The AdaptationSet element is @id, @group, @min (max) Bandwidth, @min (max) Width, @min (max) Height

@min (max) FrameRate, Common, Accessibility (0..N), Role (0..N), Rating (0..N), Viewpoint (0..N), ContentComponent (0..N) and / Or Representation (0..N).

Representation elements include @id, @bandwidth, @dependencyId, Common, BaseURL (0..N), SegmentBase (0..1), SegmentList (0..1), SegmentTemplate (0..1), and / or SubRepresentation ( 0..N). Here, @id and / or @bandwidth may be mandatory fields.

SubRepresentation elements include @level, @dependencyLevel, @bandwidth, @contentComponent and / or Common.

ContentComponent elements include @id, @lang, @contentType, @par, Accessibility (0..N), Role (0..N), Rating (0..N), and / or Viewpoint (0..N) do. Here, when @lang, @contentType and / or @par do not exist in AdaptationSet, these fields may or may not be defined in ContentComponent.

The SegmentBase element includes @timescale, @presentationTimeOffset, @timeShiftBufferDepth, @availabilityTimeOffset, Initialization (0..1) and / or RepresentationIndex (0..1).

The DASH data model according to an embodiment of the present invention includes a common attribute and an element.

Commmon attributes and elements include @ mimeType, @ width, @height, @sar, @framerate, @audiosamplingRate, @codec, @startWithSAP, FramePacking (0..N), AudioChannelConfiguration (0..N), ContentProtection (0 .. N), EssentialProperty (0..N), SupplementalProperty (0..N) and / or InbandEventStream (0..N).

The aforementioned common attributes and elements may be included and applied in AdaptationSet, Representation and / or SubRepresentation.

In this figure and the description above, fields with @ in front of field names represent attributes, and fields without @ represent elements. Also, (0..N) after the element name indicates that there are at least 0 and at most N elements. Where N indicates that no limit is set.

According to one embodiment of the invention, the description of the element or attribute in the MPD follows the content defined in the DASH standard.

MPD is a description of a media presentation to provide a streaming service.

Period represents the interval of media presentation. Consecutive sequences of all periods make up a media presentation.

Segment represents a unit of data associated with the URL and byte range described by the MPD.

An Adaptation Set represents a set of interchangeable encoded versions of one or more media content components.

Representation represents an aggregation and encapsulation of one or more media streams in a transport format.

Sub-Representation represents a part of Representation described by MPD.

The receiver according to the illustrated embodiment is a Tuner, Physical Layer Controller, Physical Frame Parser, Link Layer Frame Processor, IP / UDP Datagram Filter, DTV Control Engine, Route Client, Segment Buffer Control, MMT Client, MPU reconstruction, Media Processor, Signaling Parser, DASH Client, ISO BMFF Parser, Media Decoder and / or HTTP Access Client. Each detailed block of the receiver may be a processor that is hardware.

The tuner can receive and process broadcast signals through terrestrial broadcast channels and convert them into appropriate forms (Physical Frame, etc.). The physical layer controller may control operations of a tuner, a physical frame parser, etc. using RF information of a broadcast channel to be received. The physical frame parser may acquire the link layer frame through parsing the received physical frame and processing related thereto.

The link layer frame processor may acquire link layer signaling from a link layer frame, acquire an IP / UDP datagram, and perform related operations. The IP / UDP Datagram Filter may filter a specific IP / UDP datagram from the received IP / UDP datagrams. The DTV Control Engine is in charge of the interface between each component and can control the operation of each component by passing parameters.

The Route Client can generate one or more ISO Base Media File Format (ISOBMFF) objects by processing Real-Time Object Delivery over Unidirectional Transport (ROUTE) packets that support real-time object transport, and collecting and processing multiple packets. Segment Buffer Control can control the buffer related to segment transmission between Route Client and Dash Client.

The MMT Client can process MPEG Media Transport (MPT) transport protocol packets that support real-time object transport and collect and process multiple packets. MPU reconstruction may reconstruct a Media Processing Unit (MPU) from an MMTP packet. The Media Processor can collect and process the reconstructed MPU.

The Signaling Parser may acquire and parse DTV broadcast service related signaling (Link Layer / Service Layer Signaling), and generate and / or manage a channel map based on this. 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 may extract audio / video data and related parameters from an ISO BMFF object. The media decoder may decode and / or present the received audio and video data. The HTTP Access Client can request specific information from an HTTP server and process the response to the request.

The receiver according to the embodiment of the present invention may further include a viewing authority related control unit t8010. The viewing authority related control unit may further include an output interface and / or a CA (Conditional Access) module according to an embodiment.

The CA module may process key information and / or viewing authority information for decoding the scrambled broadcast stream. Here, the scrambled broadcast stream may mean an encrypted broadcast stream. The CA module may process information and deliver key information required for the DASH client, the ISOBMFF Parser, and / or the Media Processor. According to an embodiment, the CA module may process the license, key information, and viewing authority information and transmit the same to another module, or even decrypt the encrypted stream in the CA module itself.

The output interface can control an external interface that can be connected to an external device. The external device may include a companion device and / or a device containing other authentication information.

The HDR video production apparatus may include at least one of the capture / film scanner 101, the post-production block (mastering unit 102), and / or the 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 figure, although the metadata included in the video stream is received, the metadata of the present invention is not only a broadcast signal but also other paths (for example, IP-based broadcasting / communication, wire / wireless communication, wire / wireless interface, and near field communication). Etc.) can also be sent and received.

The capture / film scanner 101 of the HDR video production apparatus may convert a natural scene composed of natural colors into a digital image. For example, the capture / film scanner may be a device for converting an optical image into a digital image such as a video camera, a camera, a scanner, and the like. The capture / film scanner 101 may sense an optical image and output raw HDR (High Dynamic Range) video.

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

Encoder / multiplexer 103 may encode and multiplex at least one or more mastered HDR video and HDR metadata.

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

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

The metadata processor 106 may receive and store the HDR metadata. The metadata processor may check the set number or the version number included in the HDR metadata to check whether there is a change to the stored HDR metadata, and if there is a change, update the existing HDR metadata. The metadata processor may output the HDR metadata to the post processor according to timing information received from the synchronizer.

The post processor 107 may perform post-processing on the HDR video received from the decoder by using the HDR metadata received from the metadata processor. Through this process, HDR video can be converted to improved HDR video with HDR metadata.

The synchronizer 108 may provide timing information to the metadata processor and the post processor so that the metadata is applied at the correct time point for the entire HDR video or each scene, each video clip, or each frame. Here, the meta data may indicate information on the mastering display, or may mean information that is commonly applied in units of channels, programs, or content, or information that is applied to each of a series of scenes, video clips, and frames.

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

In the present invention, the operation of the receiver is mainly described, but the same considerations may be considered when generating a related signal, and may also be applied to a transfer signal and a mastering signal between productions.

When the video stream is received, the receiver may 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 update performer. 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 content.

The partial application information may indicate metadata that can be limitedly applied to a part of content and may mean information applied to each of a continuous scene, a video clip, or a frame. The receiver may process the received common information or partial information by applying the received common information or partial information to the content after determining the performance of the playable content type. A receiver capable of playing back HDR video may convert the content using the received metadata. The receiver may display the converted content as the final image after the processing operation. A detailed receiver operation method 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, referred to as HDR_info ()). The receiver may analyze the metadata obtained from the video stream by passing it to the metadata parser 202 and store the metadata in the memory. Metadata may be divided into common application information (common HDR metadata) and partial application information (scene / frame HDR metadata). In the present invention, by transmitting the range to which the corresponding metadata is applied using the type information (HDR_info_type) to be described later, the metadata is applied according to the mastering display, or the metadata is commonly applied in units of channel, program, and content, or continuous Metadata can be applied to each scene, video clip, and frame.

In addition, the metadata may further include information that can match the corresponding metadata, for example, the metadata and the image frame to which the metadata is applied, in the form of synchronization start information (sync_start) and synchronization period information (sync_duration). It may include.

Depending on the embodiment, the common application information may be a value that may indicate the dynamic range of the content / mastering display / frame, for example maximum minimum brightness or high contrast, a transfer function such as EOTF, content or mastering display. It may include at least one information of the color space, the color temperature of the content or the mastering display, the brightness range conversion function, the color space conversion function and / or viewing environment information.

In this specification, a value that can indicate the dynamic range of the 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 transfer function such as EOTF may be transmitted through a transfer function type (transfer_function_type). The color space of the content or mastering display may be transmitted through the CG information type (color_gamut_type). The color temperature of the content or mastering display may be transmitted through the color temperature information type (color_temperature_type). The brightness range conversion function may be transmitted through the DR mapping information type (dynamic_range_mapping_info_type). The color space conversion function may be transmitted through the CG mapping information type (color_gamut_mapping_info_type). The viewing environment information may be transmitted through the viewing environment information type (viewing_condition_info_type). The syntax of each information and a description of the included field 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 coverage. Partial application information can deliver more specific information in that the application range is limited to a certain portion of the content. For example, the common application information may transmit a brightness range applied to the entire content as a value such as f-stop or high contrast. In contrast, the partial application information may deliver more specific information by transmitting a maximum minimum value for a frame unit. Depending on the type of application information transmitted through this, the information delivery range may be differentially applied to each step. Similarly, in the case of dynamic range mapping, after general content transformation information is transmitted as common application information, a complex transformation function that can make use of characteristics of each scene can be delivered through partial application information.

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

First, a case in which the display included in the receiver is an SDR display or a display having a similar capability will be described. If it is determined that the receiver display cannot fully play the decoded HDR content, the receiver may not play the HDR content or may perform a transformation to play the content. A receiver capable of converting an HDR video into an SDR video may convert and receive the received HDR video into an SDR video. To this end, the HDR metadata may include information on a transform function for converting the HDR video into the SDR video. For example, dynamic_range_mapping_info_type or color_gamut_mapping_info_type may be used as the information on the above-described transform function, and the HDR metadata may additionally signal that the corresponding information is used for converting the HDR video to the SDR video when necessary.

Next, a case in which the display included in the receiver is an HDR display will be described. This is the case when the display of the receiver is determined to be able to fully play the decoded content. In this case, image quality may be improved by using common application information included in HDR metadata, and image quality may be improved by using dynamic range mapping, color gamut mapping, viewing condition mapping, and the like. According to an embodiment, the image quality line for the entire content using the common application information may be omitted when the partial application information may be applied in the third step to be described later. In addition, the image quality improvement for the video using the common application information may be implemented through a separate module or applied in connection with the post processing module described in FIG. 3.

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

In the above description, the scene-by-scene (or clip-by-clip, frame-by-frame) processing is added as an example. In this case, the metadata provided for each scene, clip, or frame is used. Detailed dynamic transformations per scene, video clip or frame of each content allow for the display of even higher quality HDR video. In this case, according to an embodiment of the present invention, the broadcast transmission device may allow the receiver to identify in a supplemental enhancement information (SEI) message that information on a scene, video clip or frame basis is transmitted using HDR_info_type. In addition, the broadcast transmission device may provide information on a time point at which scene or frame information should be applied to the receiver by using a synchronization information type (sync_info_type), synchronization start information (sync_start), and synchronization interval information (sync_duration). . The receiver identifies that scene, video clip, or frame information is transmitted through the HDR video information type (HDR_info_type), and provides timing information on when to apply scene, video clip, or frame information through sync_info_type, sync_start, and sync_duration. Can be obtained. In addition, if necessary, the receiver may convert timing information provided through metadata into information for synchronizing with an image.

In addition, when the broadcast transmission device provides common application information, the broadcast transmission device may inform the receiver of what kind of scene, video clip, or frame unit metadata is provided in the future. The broadcast transmission device may inform the receiver in advance of the information through HDR_video_enhancement_info_present_type. That is, the receiver may prepare the operation of the associated module by obtaining in advance information on whether the partial application information is received from the common application information and the type thereof. According to an embodiment, the broadcast transmission device may indicate the fact that metadata is provided in a frame, video clip, or scene unit using common application information, or may have specific information in frame, video clip, or scene unit. Can be indicated. For example, the broadcast transmission device may indicate that dynamic range mapping or / and color gamut mapping information is provided in units of frames or scenes using common application information.

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

In the present invention, the post processor may include a DR mapping block 301, a CG mapping block 302, and a viewing condition adjustment block 303. The post processing unit may receive the HDR video data and perform image quality improvement using dynamic range mapping, color gamut mapping, viewing condition mapping, and the like. The dynamic range mapping block 301 may perform image quality improvement by applying dynamic range information, transfer function information, and DR mapping information to the input HDR video data. The CG mapping block 302 may apply color gamut information, color temperature information, and CG mapping information to the input HDR video data to perform image quality improvement. The viewing condition adjustment block 303 may apply the viewing environment information to the HDR video data to perform image quality improvement.

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 may be used as the same meaning as 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, information about a mastering display may be displayed or commonly applied in units of channels, programs, and content. In addition, it can be classified into a series of scenes, video clips, and frames, and classified into different methods (e.g., before and after conversion, transmission format, target format after conversion, and static / dynamic metadata). You can also add

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

In addition, the unit to which the information is applied may be classified in the SEI message as well as assigned by different payloadTypes. For example payloadType = 52 (mastering display), payloadType = 53 (channal), payloadType = 54 (program), payloadType = 55 (content), payloadType = 56 (scene), payloadType = 57 (clip), payloadType = 58 ( frame).

The transition flag (transition_flag) information is a signal for ending time of content associated with the currently described SEI message. For example, when the HDR content ends and is converted to the SDR content, the transition_flag is set to 1 for the last frame. In this case, it may be considered as meaning that the transmission of the HDR information descriptor is terminated according to the application field, and the receiver may lead to an operation such as turning off a module related to the HDR information descriptor based on this signal. If the receiver is separated into a STB (settop box) and a display device and connected to a wired / wireless interface (for example, HDMI, DisplayPort, MHL, etc.), it is similar to STB for information such as interruption of HDR related information or termination of HDR content. To the display device. The transition_flag may be informed in the frame in which the HDR information descriptor terminates in the meaning of informing the end time. If it is promised in advance, a method notified by the RAP including the end frame may also be applied.

The set_number information may indicate an identification number unique to the HDR information descriptor. That is, in a situation in which a plurality of HDR information descriptors are transmitted from the broadcast transmission device to the receiver on a time unit or frame basis, the HDR information descriptors may serve to distinguish each HDR information descriptor. If necessary, it may play a role of distinguishing a plurality of descriptors for each channel, program, content, frame, scene, clip, etc. in connection with the above-described HDR_info_type. For example, in case of delivering different DR mapping functions for the purpose of supporting a display having various kinds of luminance, a plurality of descriptors for each channel, program, content, frame, scene, clip, etc. in connection with the above-described HDR_info_type It can play a role of distinguishing.

The version (version_number) information may indicate the version of the HDR information descriptor. In association with at least one of the HDR_info_type and the set_number, this may indicate that there is an information change 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 the metadata processor may be applied to the image as it is. However, when the version_number is changed, the broadcast reception device may update information in the metadata buffer and apply new information to an image.

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

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

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

The number of additional enhancement information (number_of_HDR_video_enhancement_info) information indicates the number of related information for the case where there is an additional SEI message related to the current SEI message. Or it may provide enhanced information. For example, if HDR_info_type = 0011 (content) information is transmitted, information about a mastering display and a scene may be transmitted in association with it, in which case it has a value of 3. In this case, the receiver may use only the information in the content according to the performance when performing image quality processing such as tone mapping and gamut mapping. If it is determined that the user has more detailed information, for example, only information of HDR_info_type = 0100 (scene) may be used, or all the information may be collectively used according to the embodiment.

The additional enhancement 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 the HDR_info_type of FIG. 5. In this case, it is possible to inform whether DR mapping, gamut mapping, and viewing condition related information are transmitted through enh_dynamic_range_mapping_info_ present_flag, enh_color_gamut_mapping_info_present_flag, and enh_viewing_condition_info_present_flag, and prepare the receiver operation for processing information on the information in advance or use the improved information compared to the current information. Can be used to determine whether or not.

An improved DR flag (enh_dynamic_range_mapping_info_present_flag) may indicate that DR mapping information exists for associated metadata information when the value is 1.

The enhanced CG flag (enh_color_gamut_mapping_info_present_flag) may indicate that gamut mapping information exists for associated metadata information when the value is 1.

The enhanced viewing environment flag enh_viewing_condition_info_present_flag may indicate that viewing condition information exists for associated metadata information when the value is 1.

If metadata type is distinguished by payloadType value of SEI message instead of HDR info, in addition to using HDR_info_type and related flags as above, payloadType value of corresponding SEI message may be directly transmitted. That is, for the above example, payloadType = 52 (mastering display) and payloadType = 56 (scene) can be delivered as additional (enhancement) information about payloadType = 53 (content). Alternatively, payloadType may be added to provide information together with HDR_info_type.

The sync information type (sync_info_type) information may indicate a method of representing information for synchronizing with content, scene, clip, or frame to which information in the HDR information descriptor is to be applied. For example, a picture order count (POC) value used in a decoder can be delivered, or a pic_order_count_lsb value can be delivered directly. In the case of storage media, media time information can be used and the cumulative frame number can be determined based on the reference time for the start of video.

The synchronization start (sync_start) information is information related to the start point of synchronization. Rather than sending related information every frame, if the relevant information is delivered in a specific period such as RAP, it is necessary to connect the start and end of the section in which the information is used with the video frame. According to the present invention, an embodiment in which start information of a section or frame to which corresponding information is applied using sync_start information is indicated by information such as time, POC, number of frames, and PTS in association with sync_info_type. The sync_info_type may define the type of synchronization information as time, time difference, start order, picture order count (POC), PTS, and the number of aggregated frames.

For example, consider a case where three metadata are applied to 2 seconds (starting point), 2.5 seconds, and 3.5 seconds within a 2 to 4 second RAP interval for a 50 fps video stream having a RAP interval of 2 seconds.

When Sync_info_type = 0x00, the type of synchronization information is set as time, and the sync_start information of each metadata may be transmitted to 2000, 2500, and 3500. Additionally, sync_duration may be additionally signaled as 500, 1000, or 1000. At this time, there is a case where a time reference is required for time determination, and may be separately signaled, such as defining a time in an adaptation field of a TS header.

When Sync_info_type = 0x01, the type of synchronization information may be set as a time difference. The broadcast transmission device may signal to the receiver that the signal is immediately applied, applied after 0.5 seconds from the RAP, and applied after 1.5 seconds from the RAP by signaling sync_start = 0, 500, and 1000, respectively.

In the case of Sync_info_type = 0x02, the type of synchronization information may be set as a start order, and may indicate the order such as sync_start = 0, 1, and 2. FIG. If the start order is signaled, the receiver may apply synchronization information in order at regular time intervals. The predetermined time interval may be a fixed value or may have a value determined in order. For example, it can be assumed that 0 is applied immediately, 1 is applied to RAP + 0.5 seconds, and 2 is applied to RAP + 1.5 seconds.

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

Even when signaling PTS (presentation time stamp) and frame number, the application time of metadata can be indicated through PTS and frame number information similarly to the above POC example.

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

The number of DR information (number_of_dynamic_range_info) information may indicate the number of dynamic range information expression methods corresponding to a mastering display, channel, program, content, scene, clip, or frame.

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. The method for expressing the dynamic range may be as shown. The dynamic range may be expressed using at least one of maximum brightness, minimum brightness, average brightness, average or median values composed of certain components. In addition, in the case of white, bright parts such as normal white, diffuse white, and specular white can be classified in detail according to their characteristics, and in the case of black, they can be classified according to their characteristics such as normal black, deep black, and pitch dark. Can be.

As shown in the example below, the broadcast transmission device may express information such as specular white and pitch dark through HDR info to subdivide the brightness of the list and the shadow in the content. Such information is used as a criterion for determining the receiver display environment. It can be used or used as information for mapping according to the display environment.

The DR information value (dynamic_range_info_value) information may carry a corresponding value according to dynamic_range_info_type. That is, content, mastering display, and scene DR can be expressed in detail according to dynamic_range_info_type as follows. Alternatively, it can be used to describe the characteristics of the container video format and the actual content separately.

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 the type of transfer function used for the mastering display, channel, program, content, scene, clip, or frame of the HDR video. For example, a predetermined EOTF may be signaled, such as SMPTE ST 2084, ITU BT.1886, BT.2020, and the like. Depending on the type of transfer function, the method may be classified and signaled as a method of representing absolute brightness or representing relative brightness. If necessary, the coefficient of any transfer function may be transferred.

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

The color_temperature_type information may indicate information about a reference white corresponding to a mastering display, channel, program, content, scene, clip, or frame. For example, it may be a standard light source color temperature such as D65 and D50, and if necessary, an arbitrary value representative of the color temperature may be represented, such as an RGB color primary for white (XYZ, RGBW, etc.).

The DR mapping type (dynamic_range_mapping_info_type) information indicates the type of dynamic range mapping information corresponding to the mastering display, channel, program, content, scene, clip, or frame. For example, as shown in the figure, another SEI message may refer to information by referring to a Knee function information SEI message or a Tone mapping information SEI message included in the HEVC. In addition, the content may be described directly in a predetermined HDR information descriptor.

The CG mapping type (color_gamut_mapping_info_type) information indicates the type of color gamut mapping information corresponding to the mastering display, channel, program, content, scene, clip, or frame. For example, as shown in the figure, information defined in the color remapping information SEI message included in the HEVC may be cited. In addition, the content may be described directly in a predetermined HDR information descriptor.

The viewing_condition_info_type information indicates the type of 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 may describe the content directly in a predetermined HDR information descriptor.

When the external SEI message is referred to the above-described dynamic_range_mapping_info_type, color_gamut_mapping_info_type, and viewing_condition_info_type, a method of directly signaling payloadType of the SEI message may be used. For example, when referring to the Knee function information SEI message, a method of notifying in detail through dynamic_range_mapping_info_type = 0 and payloadType = 141 may be used.

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

Metadata transmission according to time is 1) method to send all the information in every frame, 2) method to transmit in the frame of the point of time when metadata is changed in RAP and 3) within period with RAP Method of transmitting metadata applied at once at the time of cycle 4) Various methods can be considered, such as transmitting before RAP related to application time. Moreover, the method of 1) -4) can also be mixed and used.

20 illustrates an embodiment of signaling metadata information according to a RAP. Common application information (common type) applied to the entire video may be transmitted for each RAP. This is the case when HDR_info_type is set to 0000. The common application information is repeated information, but the broadcast transmission device may compensate for information loss due to a transmission error by transmitting common application information for each RAP.

When it is necessary to provide information that is applied differently according to a scene, it can be transmitted by using scene metadata. This is the case when HDR_info_type is set to 0100. In this case, the information corresponding to the RAP time point and the information applied after the scene change in the RAP can be sent together. The information corresponding to the RAP time point and the information applied after the scene change in the RAP may be defined as sets having different roles, and may be distinguished by being given different set_numbers. Also, according to an embodiment, different sets_numbers may be used for the purpose of distinguishing the information applied to the same scene by separately separating and transmitting the information that plays different roles. If the same information is applied over two or more RAPs, the same set_number may be used. However, if there is no detailed information update, the same version_number may be set. In this case, when there is a change in the detailed information, the metadata processor may determine whether the information is changed in which set and update the metadata processor by having a different version_number. When the next RAP arrives, sync_start can be applied to the new RAP because the scene start time is replaced by the new RAP. In this case, if the end point (sync_start + sync_duration) of the sync interval is the same, there is no information change and the same version_number may be applied.

When the application information is transmitted in advance before the RAP related to the metadata application time used in the program arrives, the application time may be informed through relative concepts such as time difference, order, and frame number. In this case, it may be informed that the metadata is to be applied in the future instead of the corresponding RAP by using a method of signaling in a longer interval than the RAP or the pre-promised signaling such as Sync_start = FFFF.

The second HDR_info_type = 0100 for 00: 00: 00: 00 ~ 00: 00: 02: 00 is set to sync_start = 0, sync_duration = 180 and the second in 00: 00: 02: 00 ~ 00: 00: 04: 00 HDR_info_type = 0100 may be set to sync_start = 0 and sync_duration = 60. As the start time is changed from 00: 00: 00: 00 to 00: 00: 02: 00, the duration can be signaled by changing the duration of the same information (set 1, ver 0). Do not perform metadata update.

If there is a change in details about the information that plays the same role as the previous information, the broadcast transmission device may increase version_number while maintaining set_number of common application information. The metadata processor of the receiver may recognize the information change based on the changed version_number and update the existing information with the new information.

If there is a change of information in the metadata in the section 00: 00: 04: 00 ~ 00: 00: 06: 00, information such as a start time may be additionally delivered. When there is a change in information in the metadata, for example, when B information is changed to B 'as illustrated, a new version number may be assigned. In the drawing, the version number for set_number = 2 was 0 in the range 00: 00: 02: 00 ~ 00: 00: 04: 00, but the version number in the range 00: 00: 04: 00 ~ 00: 00: 06: 00. You can see that it increased to 1. Even if the end point changes, it can be informed that the version number should be updated.

21 illustrates a method of signaling metadata information based on a time flow according to another embodiment of the present invention. 21 illustrates a case in which there is a switch between HDR and SDR in signaling metadata information. As shown, in the third RAP, the HDR video stream is converted into an SDR video stream. In this case, the HDR information descriptor is no longer transmitted or received after the third RAP.

When transmission of the HDR information descriptor is stopped, the broadcast transmission device may inform the receiver through the transition_flag. When the DR of the content is switched from HDR to SDR, the delivery of the SEI message that has delivered the video characteristics for the HDR / WCG content is stopped, and no further information may be delivered after the content switching contest. Of course, the use of HDR information descriptors such as mastering display information, color gamut mapping, and viewing conditions may also occur for SDR content. However, in this example, legacy SDR content not using the HDR information descriptor may be considered. In this case, it is important to turn on the transition_flag, that is, to set it to 1, and set transition_flag to on in the frame immediately before the transition occurs and the RAP containing the frame (second RAP in the drawing) as shown in the above example. can do.

22 illustrates dynamic_range_mapping_info according to an embodiment of the present invention. If the above-described dynamic_range_mapping_info_type is set to 0x03, dynamic_range_mapping_info () may be directly defined in the HDR_info descriptor. When HDR_info_type is channel, program, or content as common application information related to mastering display or video, the information described in FIG. 9 may be used throughout the image (channel, program or content), and scene type or frame as partial application information. In the case of type, the above-described information may be used for a corresponding section. The following describes the fields included in dynamic_range_mapping_info ().

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_of_coeff), EOTF coefficient information (transfer_curve_coeff [i ]), Clipping flag information (clipping_flag), linear mapping flag information (linear_mapping_flag), clipping maximum brightness range information (luma_clipping_upper_bound), clipping minimum brightness range information (luma_clipping_lower_bound), maximum brightness information (luminance_upper_bound), minimum brightness information (luminance_lower_bound), Maximum brightness digital value (luma_upper_value), minimum brightness digital value (luma_lower_value), key area transformation curve type information (mid_DR_transformation_curve_type), key area transformation curve detail (mid_DR_transformation_curve ()), key brightness range area ratio information (mid_DR_percentage), upper area Transform curve type information (upper_DR_transformation_curve_t ype), upper region transformation curve details (upper_DR_transformation_curve ()), upper luminance range region ratio information (upper_DR_percentage), lower region transformation curve type information (lower_DR_transformation_curve_type), subregion transformation curve details (lower_DR_transformation_curve ()), and the number of additional regions Information (number_luminance_upper_bound_diff), additional region difference information (luminance_upper_bound_diff [i]), additional region difference digital value (luma_upper_value_diff [i]), change upper region transformation curve type information (upper_DR_transformation_curve_type [i]), and change upper region transformation curve details ( upper_DR_transformation_curve ()), change upper brightness range region ratio information (upper_DR_percentage [i]), and / or change key brightness range region ratio information (mid_DR_percentage [i]).

The maximum reference brightness information (luminance_max) indicates the maximum reference brightness expressed in the UHD broadcast content. That is, the maximum value of the brightness range DR is shown. For example, in the case of a reference monitor, 100 cd / m ^ 2 is set as the maximum reference brightness, and in this case, 1, which is the quotient of the value divided by 100 (decimal) in consideration of a general range, may be transmitted. .

The minimum reference brightness information (luminance_min) indicates the minimum reference brightness expressed in the UHD broadcast content. That is, the minimum value of the brightness range DR is shown. For example, in the case of a reference monitor, 0.05 cd / m ^ 2 is set as the minimum reference brightness. In this case, 5, which is a value obtained by multiplying 100 (decimal number) by the value in consideration of a general range, may be transmitted.

The arbitrary EOTF information (private_EOTF) indicates whether any EOTF function is used. In general, when a widely used EOTF such as ITU-R BT.1886, REC.709, BT.2020, etc. is used, it can be delivered by VUI information. However, when the EOTF, which is not yet defined as a standard, is used, it may be indicated by setting the field value to 1. For example, perceptual quantization can be used as an EOTF, i.

EOTF coefficient number information (number_of_coeff) represents the number of coefficients used for any EOTF.

EOTF coefficient information (transfer_curve_coeff [i]) represents a coefficient used for any EOTF.

The clipping flag information clipping_flag is information indicating whether the clipping option is used and may have a value of 1 when the use of the clipping option is allowed.

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

The clipping maximum brightness range information (luma_clipping_upper_bound) indicates a digital value for the upper threshold in the brightness range DR displayed when the clipping option is used.

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

The maximum brightness information (luminance_upper_bound) represents a maximum value (in units of nit) of the brightness range that must be expressed among the brightness ranges expressed in the UHD broadcast content. The maximum brightness information may be a criterion for determining the display type of the receiving device. In addition, an additional criterion for determining the display type of the receiving device may be signaled.

The minimum brightness information (luminance_lower_bound) indicates a minimum value (in nit) of the brightness range that must be expressed among the brightness ranges expressed in the UHD broadcast content. The minimum brightness information may be a criterion for determining the display type of the receiving device. In addition, an additional criterion for determining the display type of the receiving device may be signaled.

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

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

The core region transformation curve type information (mid_DR_transformation_curve_type) identifies a luminance range transformation curve used in the core luminance range region. The conversion curve can be any one of a linear curve, an exponential curve, an S curve, a logarithmic curve, a combination curve, and a look up table (LUT). One can be used.

The core region transformation curve detail information mid_DR_transformation_curve () indicates additional information according to the transformation curve identified by the core region transformation curve type information mid_DR_transformation_curve_type. For example, slope information may be transmitted when a linear curve is used, and information about the bottom may be transmitted when an exponential curve or a logarithmic curve is used, and an S curve may be used. If (s curve) is used, the coordinates of the inflection point and the information about the base and y-intercept for each section can be transmitted.When the combination curve is used, the x coordinate of each section, each The curve type of the section and information on the graph may be transmitted.

The core brightness range region ratio information mid_DR_percentage represents a ratio of the core brightness range region of the brightness range of the ultra-high definition broadcasting content to the entire brightness range DR of the reception device display.

The upper region transformation curve type information (upper_DR_transformation_curve_type) identifies a brightness range transformation curve used in the upper luminance range region. The conversion curve can be any one of a linear curve, an exponential curve, an S curve, a logarithmic curve, a combination curve, and a look up table (LUT). One can be used.

The upper region transformation curve detailed information (upper_DR_transformation_curve ()) indicates additional information according to the transformation curve identified by the upper region transformation curve type information (upper_DR_transformation_curve_type). For example, slope information may be transmitted when a linear curve is used, and information about the bottom may be transmitted when an exponential curve or a logarithmic curve is used, and an S curve may be used. If (s curve) is used, the coordinates of the inflection point and the information about the base and y-intercept for each section can be transmitted.When the combination curve is used, the x coordinate of each section, each The curve type of the section and information on the graph may be transmitted.

The upper brightness range region ratio information (upper_DR_percentage) indicates a ratio of the upper brightness range region of the brightness range of the UHD broadcast content to the entire brightness range DR of the display of the receiving device.

The lower region transformation curve type information (lower_DR_transformation_curve_type) identifies a brightness range transformation curve used in the lower luminance range region. The conversion curve can be any one of a linear curve, an exponential curve, an S curve, a logarithmic curve, a combination curve, and a look up table (LUT). One can be used.

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

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

The additional area difference information (luminance_upper_bound_diff [i]) represents a difference value for configuring an i + 1th brightness value in ultra high definition broadcast content. If you extend the core brightness range area on a display (case 2) that has a wider brightness range than the existing brightness range but does not accommodate all of the brightness ranges expressed in ultra-high definition broadcast content, the maximum brightness information (luminance_upper_bound) is luminance_upper_bound + luminance_upper_bound_diff [0] +… Can be changed to the value indicated by luminance_upper_bound_diff [i].

The additional region difference digital value luma_upper_value_diff [i] represents a digital value for the i + 1th brightness value in the ultra high definition broadcast content. If you extend the core brightness range area on a display that has a wider brightness range than the existing brightness range but does not accommodate all the brightness ranges represented in ultra-high definition broadcast content (case 2), the maximum brightness digital value (luma_upper_value) is luma_upper_value + luma_upper_value_diff [0 ] +… Can be changed to the value indicated by luma_upper_value_diff [i].

The changed upper region transformation curve type information (upper_DR_transformation_curve_type [i]) may identify the transformation curve used in the changed upper luminance range region when supporting the i + 1 th brightness range. That is, the changed upper region conversion curve type information may identify the conversion curve used in the changed upper brightness range region when the core brightness range region is extended.

The change upper region transformation curve detailed information (upper_DR_transformation_curve ()) indicates additional information according to the transformation curve identified by the change upper region transformation curve type information (upper_DR_transformation_curve_type [i]). That is, when the i + 1th brightness range is supported, the details of the conversion curve used in the changed upper brightness range area are shown.

The changed upper brightness range region ratio information (upper_DR_percentage [i]) indicates the ratio of the changed upper brightness range region to the total brightness range (DR) of the receiving device when the core brightness range region of the UHD broadcast content is changed. .

The changed core brightness range region ratio information mid_DR_percentage [i] indicates a ratio of the changed core brightness range region to the entire brightness range DR of the receiving device display when the core brightness range region of the UHD broadcast content is changed.

23 shows a case of referring to an SEI message defined in HEVC according to an embodiment of the present invention. If the above-described color_gamut_mapping_info_type is set to 0x00, gamut_mapping_info () may refer to the SEI message defined in HEVC without being directly defined in the HDR_info descriptor. Here, the SEI message may follow the color remapping information SEI message syntax defined in HEVC.

When HDR_info_type is common application information related to mastering display or video, information that is referred to throughout the image (channel, program or content) can be used when channel, program or content is used. In case of scene type or frame type as partial application information The referenced information can be applied only to the section.

24 and 25 illustrate an embodiment of signaling HDR_info descriptor through PMT according to an embodiment of the present invention. PMT stands for program mapping table and 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, program info length information, and first descriptor information. , Stream type information, basic PID (elementary PID) information, elementary stream information length (Es_info_length) information, second descriptor information, CRC information, and the like. The first descriptor information may indicate descriptor information included in the first loop following the program info length information, and the second descriptor information may indicate descriptor information included in the second loop following the length of the elementary stream information.

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

UHD_program_info_descriptor may include at least one of descriptor tag (descriptor_tag) information, descriptor length (descriptor_length) information, or service type information (UHD_service_type). The service type information (UHD_service_type) may indicate the type of UHD service. For example, the service type information may indicate a UHD service type designated by a user, such as UHD1 (4K), UHD2 (8K), or classification according to quality. Through this, various UHD services can be provided to the receiver. In the case of the present invention, UHD_service_type = 1100 (UHD1 service with HDR information metadata, 4K example) may indicate that HDR info is provided for different steps or units such as video, scene, clip, or frame.

26 and 27 illustrate an embodiment of signaling HDR_info descriptor through EIT according to an embodiment of the present invention. ATSC and DVB systems may include an EIT as a signaling table, with the syntax contained therein as shown.

The Event Information Table (EIT) of the ATSC and DVB systems according to the embodiment of the present invention is commonly used as a table_id field, section_syntax_indicator field, section_length field, source_id (service_id) field, version_number field, current_next_indicator field, section_number field, last_section_number field, num_events_in_section It may include a (segment_last_section_number) field, an event_id field, a start_time field, a length_in_seconds (duration) field, a descriptors_length field, a descriptor () field, and / or a CRC_32 field.

The table_id field identifies that this table is an Event Information Table (EIT). The section_syntax_indicator field is a 1-bit field set to 1 to indicate the long form of the MPEG-2 private_section table. The section_length field indicates the length of the table section following this field in number of bytes. The source_id field represents a source ID of a virtual channel transmitting an event described in this 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 and indicates whether this table is currently applicable or next applicable. The section_number field represents the number of a section. The last_section_number field identifies the number of the last section. The num_events_in_section field represents the number of events included in the corresponding table section. The event_id field identifies a specific number indicating the event described. The start_time field represents the start time of the event based on GPS second. The value representing the start time of the event in the virtual channel may be greater than the value representing the end time of the event being broadcast. The end time of the event may be defined as the sum of the start time of the event and the value representing the length of the event in time. The length_in_seconds (duration) field represents the duration of an event in seconds. The descriptors_length field represents the total length of an event descriptor (descriptor ()) described later. descriptor () is a descriptor loop located in the table. The descriptor loop may include additional descriptors. Zero or more descriptors may be included in the EIT, and the descriptor may correspond to an event level descriptor describing 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 included in the event level descriptor and transmitted. UHD_program_info_descriptor may be used to distinguish the type of UHD service, and the HDR_info descriptor may determine whether to include HDR image information metadata at an event level, and may be used to determine whether the receiver is acceptable. In the case of cable broadcasting, the same information may be provided to the AEIT instead of the descriptor.

The CRC_32 field includes a CRC value for checking the integrity of data. The CRC value can ensure that zero values are output from the registers in the decoder as defined in Annex A of ISO-13818-1 “MPEG-2 Systems” after the entire EIT section has been processed.

When the UHD_service_type of the UHD_program_info_descriptor signaled through the EIT is set to 1100, the receiver may confirm that information on an appropriate viewing environment is transmitted through metadata. For example, when UHD_service_type is 1100, the receiver may identify that a corresponding service is UHD1 service with HDR information metadata, 4K.

When the UHD_service_type of the UHD_program_info_descriptor signaled through the EIT is set to 0000, the receiver checks the existence of the HDR_info_descriptor () and may know that HDR info is provided for different steps or units such as video, scene or frame. Here, the UHD_service_type may indicate that 0000 is a UHD1 service.

In the above-described case, it is possible to determine whether the content provider can utilize information in units of a mastering display, content, scene, or frame desired by the content provider using HDR_info_descriptor (). By using this, it is possible to determine in advance whether to use content, scene or frame unit metadata with respect to content played back at the current or future time point, and the receiver can prepare a setting for a situation such as a scheduled recording in advance.

28 illustrates HDR_info_descriptor () according to another embodiment of the present invention. There may be a plurality of information about an event. That is, the information applied to the content is not consistently applied, but the information applied over time or by the presence or absence of the inserted content may be converted. Alternatively, one mode may support various modes intended by the producer. In this case, it is necessary to determine whether these modes are acceptable in the display of the receiver, and information on this may be provided through the viewing_condition_metadata by the broadcast transmission device. The syntax in viewing_condition_metadata may follow the definition of the viewing condition descriptor of the SEI message.

The HDR_info_descriptor may include at least one of descriptor tag (descriptor_tag) information, descriptor length (descriptor_length) information, and number of information (number_of_info) information. The HDR_info_descriptor may include a loop and may include as many HDR_info_metadata () as indicated by number_of_info. The syntax of the HDR_info_metadata () may be delivered with a script of the embodiment of the above-described HDR information descriptor configuration or a part thereof.

In order to store and transmit media data such as audio or video, a standardized media file format may be defined. According to an embodiment, the media file of the present invention may have a file format based on ISO BMFF (ISO base media file format).

The media file according to the present invention may include at least one box. The box may be a data block or an object including media data or metadata related to the media data. The boxes may form a hierarchical structure with each other, such that the data may be classified so that the media file may be in a form suitable for storage and / or transmission of a large amount of media data. In addition, the media file may have an easy structure for accessing the media information, such as a user moving to a specific point of the media content.

The media file according to the present invention may include an ftyp box, a moov box and / or an mdat box.

An ftyp box (file type box) can provide file type or compatibility related information for a corresponding media file. The ftyp box may include configuration version information about media data of a corresponding media file. The decoder can identify the media file by referring to the ftyp box.

The moov box (movie box) may be a box including metadata about media data of a corresponding media file. The moov box can act as a container for all metadata. The moov box may be a box of the highest layer among metadata related boxes. According to an embodiment, only one moov box may exist in a media file.

The mdat box (media data box) may be a box containing actual media data of the media file. Media data may include audio samples and / or video samples, where the mdat box may serve as a container for storing these media samples.

According to an embodiment, the above-described moov box may further include a mvhd box, a trak box and / or an mvex box as a lower box.

The mvhd box (movie header box) may include media presentation related information of media data included in the media file. That is, the mvhd box may include information such as media generation time, change time, time specification, duration, etc. of the media presentation.

The trak box (track box) can provide information related to the track of the media data. The trak box may include information such as stream related information, presentation related information, and access related information for an audio track or a video track. There may be a plurality of trak boxes according to the number of tracks.

According to an embodiment, the trak box may further include a tkhd box (track header box) as a lower box. The tkhd box may include information about the track indicated by the trak box. The tkhd box may include information such as a creation time, a change time, and a track identifier of the corresponding track.

The mvex box (movie extend box) may indicate that the media file may have a moof box to be described later. To know all the media samples of a particular track, moof boxes may have to be scanned.

The media file according to the present invention may be divided into a plurality of fragments according to an embodiment (t14010). Through this, the media file may be divided and stored or transmitted. The media data (mdat box) of the media file may be divided into a plurality of fragments, and each fragment may include a mdat box and a moof box. According to an embodiment, information of the ftyp box and / or the moov box may be needed to utilize the fragments.

The moof box (movie fragment box) may provide metadata about media data of the fragment. The moof box may be a box of the highest layer among metadata-related boxes of the fragment.

The mdat box (media data box) may contain the actual media data as described above. This mdat box may include media samples of media data corresponding to each corresponding fragment.

According to an embodiment, the above-described moof box may further include a mfhd box and / or a traf box as a lower box.

The mfhd box (movie fragment header box) may include information related to an association between a plurality of fragmented fragments. The mfhd box may include a sequence number to indicate how many times the media data of the corresponding fragment is divided. In addition, it may be confirmed whether there is no missing data divided using the mfhd box.

The traf box (track fragment box) may include information about a corresponding track fragment. The traf box may provide metadata about the divided track fragments included in the fragment. The traf box may provide metadata so that media samples in the track fragment can be decoded / played back. There may be a plurality of traf boxes according to the number of track fragments.

According to an embodiment, the above-described traf box may further include a tfhd box and / or a trun box as a lower box.

The tfhd box (track fragment header box) may include header information of the corresponding track fragment. The tfhd box may provide information such as a basic sample size, a duration, an offset, an identifier, and the like for media samples of the track fragment indicated by the traf box described above.

The trun box (track fragment run box) may include corresponding track fragment related information. The trun box may include information such as duration, size, and playback time of each media sample.

The aforementioned media file or fragments of the media file may be processed into segments and transmitted. The segment may have an initialization segment and / or a media segment.

The file of the illustrated embodiment t14020 may be a file including information related to initialization of the media decoder except for media data. This file may correspond to the initialization segment described above, for example. The initialization segment may include the ftyp box and / or moov box described above.

The file of the illustrated embodiment t14030 may be a file including the aforementioned fragment. This file may correspond to the media segment described above, for example. The media segment may include the moof box and / or mdat box described above. In addition, the media segment may further include a styp box and / or a sidx box.

The styp box (segment type box) may provide information for identifying the media data of the fragmented fragment. The styp box may play the same role as the above-described ftyp box for the divided fragment. According to an embodiment, the styp box may have the same format as the ftyp box.

The sidx box (segment index box) may provide information indicating an index for the divided fragment. Through this, it is possible to indicate how many fragments are the corresponding fragments.

According to an embodiment (t14040), the ssix box may be further included. The ssix box (sub-segment index box) may provide information indicating an index of the sub-segment when the segment is further divided into sub-segments.

The boxes in the media file may include more extended information based on a box-to-full box form as in the illustrated embodiment t14050. In this embodiment, the size field and the largesize field may indicate the length of the corresponding box in bytes. The version field may indicate the version of the box format. The type field may indicate the type or identifier of the corresponding box. The flags field may indicate a flag related to the box.

In order to provide HDR information related to video tracks or video samples in the media file, an HDR configuration box can be defined. The HDR configuration box can be located in the media file. According to an embodiment, the HDR configuration box may be included in a moov box, a moof box or a third box. The HDR configuration box may be called an hdrc box.

The HDR configuration box may have a hdr_config field. The hdr_config field may include an OETF_type field, max_mastering_display_luminance field, min_mastering_display_luminance field, hdr_type_transition_flag field, hdr_sdr_transition_flag field, sdr_hdr_transition_flag field, sdr_compatibility_flag field, average_frame_luminance_level field and

The OETF_type field may indicate the type of the source OETF (opto-electronic transfer function) of the video data. When the value of this field is 1, 2, or 3, it may correspond to the ITU-R BT.1886, ITU-R BT.709, and ITU-R BT.2020 types, respectively. Other values can be left for future use.

The max_mastering_display_luminance field may indicate a peak luminance value of a mastering display of corresponding video data. This value can be an integer value between 100 and 1000.

The min_mastering_display_luminance field may indicate a minimum luminance value of a mastering display of corresponding video data. This value may be a fractional number value between 0 and 0.1.

The hdr_type_transition_flag field may be a flag indicating whether the HDR information of the corresponding video data is changed to apply another type of HDR information.

The hdr_sdr_transition_flag field may be a flag indicating whether corresponding video data is switched from HDR to SDR.

The sdr_hdr_transition_flag field may be a flag indicating whether corresponding video data is switched from SDR to HDR.

The sdr_compatibility_flag field may be a flag indicating whether corresponding video data is compatible with an SDR decoder or an SDR display.

The average_frame_luminance_level field may indicate an average value of luminance level for one video sample. In addition, this field may indicate a maximum value among average values of luminance levels of each sample belonging to the sample group or the video track (stream).

The max_frame_pixel_luminance field may indicate the maximum value of pixel luminance values for one video sample. In addition, this field may indicate the largest value among pixel luminance maximum values of each sample belonging to the sample group or the video track (stream).

“That video data” that the fields describe is a video track, a video sample group, or respective video samples in a media file. The range described by each field may vary according to the description object. For example, the hdr_type_transition_flag field may indicate whether the corresponding video track is switched from HDR to SDR or may indicate whether one video sample is switched from HDR to SDR.

HDR information may be included in the structure of the above-described media file itself to store / transmit. In this embodiment, HDR information (parameters) may be added to the tkhd box in the above-described moov box. Added HDR information is shaded.

In the illustrated embodiment t16010, the hdr_flag field may be a flag indicating whether HDR video data is included in a corresponding video track described by the tkhd box. When the value of this field is 1, HDR video data may be included in the corresponding video track. When the value of this field is 1, four flag fields to be described later may exist.

Based on the hdr_flag and the flag field value to be described later, it may be determined whether or not the video decoder or the like can process the video data in the corresponding video track. For example, in case of a decoder capable of processing only SDR, it may be understood that corresponding video data cannot be processed when HDR_flag = 1 and SDR_compatibility = 0.

The hdr_type_transition_flag field may be a flag indicating whether HDR information (parameters) related to HDR video data in a corresponding video track have been changed. When the value of this field is 1, the HDR information for the HDR video data in the corresponding video track may be changed to other HDR information.

The hdr_sdr_transition_flag field may be a flag indicating whether video data in a corresponding video track is switched from HDR to SDR. When the value of this field is 1, it may be confirmed that corresponding video data is converted from HDR to SDR.

The sdr_hdr_transition_flag field may be a flag indicating whether video data in a corresponding video track is switched from SDR to HDR. When the value of this field is 1, it may be confirmed that video data is converted from SDR to HDR.

The sdr_compatibility_flag field may be a flag indicating whether video data in a corresponding video track is compatible with a decoder or display that supports SDR. If the value of this field is 1, it may be confirmed that the HDR video data in the corresponding video track is compatible with devices supporting SDR. When the value of this field is 1, decoder / display devices supporting SDR may determine whether to decode / display HDR video data included in a corresponding video track.

According to an embodiment, when the transition related flag is set to 1, the decoder or the like may make the data (SEI, etc.) in the video related thereto before processing video data.

According to an embodiment (t16020), the above-described HDR configuration box may be added to the tkhd box. The hdr_flag field in the present embodiment may be the same as the hdr_flag field in the above-described embodiment t16010. However, in this case, when the value of the hdr_flag field is 1, it may be indicated that the hdr_config box having the HDR configuration box type exists in place of the above four flags in the tkhd box.

Here, the hdr_config box may include HDR information about video data included in a corresponding video track. This box is therefore of the above-mentioned HDR configuration box type, and may include a OETF_type field, max_mastering_display_luminance field, min_mastering_display_luminance field, hdr_type_transition_flag field, hdr_sdr_transition_flag field, sdr_hdr_transition_flag field, sdr_compatibility_flag field, average_frame_luminance_level field and / or max_frame_pixel_luminance field as described above, .

The definition of these fields is as described above, but in this embodiment, since the HDR configuration box is present in the tkhd box, these fields may describe information about the corresponding video track. For example, the OETF_type field may indicate an OETF type for video data in the "corresponding video track". In particular, the hdr_type_transition_flag field, hdr_sdr_transition_flag field, sdr_hdr_transition_flag field, and / or sdr_compatibility_flag field may have the same meaning as the four flag fields in the above-described embodiment (t16010).

According to an embodiment, the average_frame_luminance_level field in this HDR configuration box may indicate a maximum value among average values of luminance levels of each of the video samples in the corresponding video track. Also, the max_frame_pixel_luminance field may indicate the largest value among the maximum values of pixel luminance of each of the video samples in the corresponding video track.

HDR information may be included in the structure of the above-described media file itself to store / transmit. In this embodiment, HDR information (parameters) may be added to the vmhd box in the above-described trak box. Added HDR information is shaded.

Here, the vmhd box (video media header box) is a lower box of the above-described trak box and may provide general presentation related information about the corresponding video track.

In the illustrated embodiment t17010, an hdr_flag field may be included. In addition, the hdr_type_transition_flag field, the hdr_sdr_transition_flag field, the sdr_hdr_transition_flag field, and / or the sdr_compatibility_flag field may be further included according to the value of the hdr_flag field. These fields may play the same role as the fields of the same name in the tkhd box described above.

In addition, in the illustrated embodiment t17020, an hdr_flag field may be included. In addition, the hdr_config box, which is an HDR configuration box, may be further included according to the value of the hdr_flag field. The hdr_flag field and the hdr_config box may play the same role as the field or box of the same name in the above-described tkhd box.

That is, in the illustrated embodiments, the HDR information in the vmhd box may provide HDR information about video data included in the corresponding video track.

According to an embodiment, HDR information may be simultaneously included in the tkhd box and the vmhd box. In this case, embodiments of the HDR information structure included in each box may be combined with each other. When the HDR information is simultaneously included in the tkhd box and the vmhd box, the values of the HDR information defined in the tkhd box may be overridden to the values of the HDR information defined in the vmhd box. That is, when the values of the HDR information defined in both are different, the value in the vmhd box may be used. If the HDR information is not included in the vmhd box, the HDR information in the tkhd box may be used.

HDR information may be included in the structure of the above-described media file itself to store / transmit. In the present embodiment, HDR information (parameters) may be added to the trex box in the aforementioned mvex box. Added HDR information is shaded.

Here, the trex box (track extend box) is a lower box of the above-described mvex box, and may set default values used by each movie fragment. By providing a default value for this box, space and complexity in the traf box can be reduced.

The trex box may include a default_hdr_flag field and / or a default_sample_hdr_flag field. Depending on the value of the default_hdr_flag field, the default_hdr_config box, which is an HDR configuration box, may be further included. In addition, depending on the value of the default_sample_hdr_flag field, the default_sample_hdr_config box, which is an HDR configuration box, may be further included.

The default_hdr_flag field may be a flag indicating whether HDR video data is included in a video track fragment included in the corresponding fragment. When the value of this field is 1, it may be indicated that the fragment includes HDR video data by default. If the value of this field is 1, a default_hdr_config box, which is an HDR configuration box, may be further included.

The default_hdr_config box may include HDR information that can be commonly applied to video samples included in the corresponding video track fragment. This box is the aforementioned HDR configuration box and may include the fields of the aforementioned HDR configuration box.

Other fields except the average_frame_luminance_level field and / or the max_frame_pixel_luminance field among the fields of the box may play the same role as the fields of the same name in the HDR configuration box included in the tkhd box described above. The average_frame_luminance_level field may indicate a maximum value among average values of luminance levels of each video sample belonging to a track fragment in the corresponding fragment. max_frame_pixel_luminance field The maximum_frame_pixel_luminance field may indicate the largest value among the maximum values of pixel luminance of each video sample belonging to the track fragment in the corresponding fragment.

The default_sample_hdr_flag field may be a flag indicating whether HDR video samples are included in a video track fragment included in the corresponding fragment. When the value of this field is 1, it may be indicated that the fragment includes HDR video samples by default. If the value of this field is 1, the default_sample_hdr_config box, which is an HDR configuration box, may be further included.

The default_sample_hdr_config box may include HDR information that can be applied to each of the video samples included in the corresponding video track fragment. This box is the aforementioned HDR configuration box and may include the fields of the aforementioned HDR configuration box.

Other fields except the average_frame_luminance_level field and / or the max_frame_pixel_luminance field among the fields of the box may play the same role as the fields of the same name in the HDR configuration box included in the tkhd box described above. The average_frame_luminance_level field may indicate an average value of luminance levels of each video sample belonging to a track fragment in a corresponding fragment. max_frame_pixel_luminance field This may indicate the maximum value of pixel luminance of each video sample belonging to the track fragment in the corresponding fragment.

HDR information may be included in the structure of the above-described media file itself to store / transmit. In this embodiment, HDR information (parameters) may be added to the tfhd box in the above-described moof box. Added HDR information is shaded.

In the illustrated embodiment t19010, the hdr_flag field may be a flag indicating whether HDR video data is included in a corresponding video track fragment described by the tfhd box. When the value of this field is 1, HDR video data may be included in the corresponding video track fragment.

When the value of the hdr_flag field is 1, the hdr_type_transition_flag field, the hdr_sdr_transition_flag field, the sdr_hdr_transition_flag field, and / or the sdr_compatibility_flag field may be further included. These fields may play the same role as the fields of the same name in the tkhd box described above. In this case, however, these fields may describe the video track fragment, not the entire video track.

That is, the hdr_type_transition_flag field may indicate whether there is a change in the HDR information with respect to media data related to the track fragment in the corresponding track fragment. The hdr_sdr_transition_flag field may represent that the track fragment is switched from HDR to SDR. The sdr_hdr_transition_flag field may represent that the track fragment is switched from SDR to HDR. The sdr_compatibility_flag field may indicate whether the HDR video data of the corresponding track fragment is compatible with the SDR decoder / display.

In the illustrated embodiment t19020, the tfhd box may include the HDR configuration box described above. According to the value of the hdr_flag field, it may be indicated whether the hdr_config box, which is an HDR configuration box, is included. The hdr_config box may provide HDR information that may be commonly applied to video samples of the corresponding track fragment.

Other fields except the average_frame_luminance_level field and / or the max_frame_pixel_luminance field among the fields of the box may play the same role as the fields of the same name in the HDR configuration box included in the tkhd box described above. In this case, however, these fields may describe the video track fragment, not the entire video track.

The average_frame_luminance_level field may indicate a maximum value among average values of luminance levels of each video sample belonging to a track fragment in the corresponding fragment. max_frame_pixel_luminance field The maximum_frame_pixel_luminance field may indicate the largest value among the maximum values of pixel luminance of each video sample belonging to the track fragment in the corresponding fragment.

In the illustrated embodiment t19030, the tfhd box may further include HDR information according to the tf_flags value. tr_flags may indicate flags associated with the box. For example, when tr_flags includes a value of 0x000001, it may be indicated that the base data offset information is included in the tfhd box, and when it includes the value of 0x000002, it may be indicated that the sample description index information is included in the tfhd box.

According to an embodiment, when the tf_flags value includes a value of 0x100000, it may be indicated that a default value of HDR information for video samples included in a track fragment in the corresponding fragment exists. The tf_flags value indicating the presence of the HDR information may have a value other than the 0x100000 value in some embodiments. (0x100000: default-sample-hdr-configuration-present)

If the tf_flags value includes a value of 0x100000, the tfhd box may include a deafult_sample_hdr_config box, which is an HDR configuration box. The deafult_sample_hdr_config box may play the same role as the deafult_sample_hdr_config box in the above-described trex box.

HDR information may be included in the structure of the above-described media file itself to store / transmit. In this embodiment, HDR information (parameters) may be added to the trun box in the traf box described above. Added HDR information is shaded.

In the illustrated embodiment t20010, the trun box may include an hdr_flag field. In addition, the hdr_type_transition_flag field, the hdr_sdr_transition_flag field, the sdr_hdr_transition_flag field, and / or the sdr_compatibility_flag field may be further included according to the value of the hdr_flag field. These fields may signal HDR related matters that may be commonly applied to video samples in the corresponding track fragment. These fields may have the same meaning as the fields of the same name in the tfhd box described above.

In some embodiments, HDR information may be simultaneously included in the tfhd box and the trun box. In this case, embodiments of the HDR information structure included in each box may be combined with each other. When the HDR information is simultaneously included in the tfhd box and the trun box, the values of the HDR information defined in the tfhd box may be overridden to the values of the HDR information defined in the trun box. That is, when the values of the HDR information defined in both are different, the value in the trun box may be used. If the HDR information is not included in the trun box, the HDR information in the tfhd box may be used.

In the illustrated embodiment t20020, the trun box may include an hdr_flag field, and may further include an hdr_config box, which is an HDR configuration box, according to the value of the hdr_flag field. This box may contain HDR information that can be commonly applied to video samples within the track fragment. The fields in this box may have the same meaning as the fields of the same name of the HDR configuration box in the tfhd box described above.

In the illustrated embodiment t20030, the trun box may further include HDR information according to the tf_flags value. tr_flags may indicate flags associated with the box. For example, when tr_flags includes a value of 0x000001, it may be indicated that data offset information is included in a trun box. When tr_flags includes a value of 0x000004, it may be indicated that the first sample flag information is included in a trun box.

According to an embodiment, when the tf_flags value includes a value of 0x002000, it may be indicated whether there is HDR information that can be commonly applied to video samples included in the track fragment in the corresponding fragment. The tf_flags value indicating that the HDR information is present may have a value other than the 0x002000 value in some embodiments. (0x002000: hdr-configuration-present)

When the tf_flags value includes a value of 0x002000, the trun box may include an hdr_config box, which is an HDR configuration box. The hdr_config box may play the same role as the hdr_config box in the above-described tfhd box.

In the illustrated embodiment t20040, the trun box may further include HDR information according to the tf_flags value. According to an embodiment, when the tf_flags value includes a value of 0x001000, it may be indicated whether there is HDR information that can be applied to each of the video samples included in the track fragment in the corresponding fragment. The tf_flags value indicating that the HDR information exists may have a value other than the 0x001000 value according to an embodiment. (0x001000: sample-hdr-configuration-present)

If the tf_flags value includes a value of 0x001000, the trun box may include a sample_hdr_config box, which is an HDR configuration box. The sample_hdr_config box may provide HDR information about the sample.

The meaning of the information in the sample_hdr_config box may be the same as the meaning of the information in the deafult_sample_hdr_config box of the tfhd box described above. That is, the deafult_sample_hdr_config box of the tfhd box may provide default HDR information that may be applied to each sample, and the sample_hdr_config box of the trun box may provide individual HDR information that may be applied to the sample for each sample.

However, the average_frame_luminance_level field and / or max_frame_pixel_luminance field of the sample_hdr_config box may have a different meaning from those of the default_sample_hdr_config box. The average_frame_luminance_level field may indicate an average value of the luminance level of the video sample. max_frame_pixel_luminance field This may represent the maximum value of pixel luminance of a corresponding video sample.

In the illustrated embodiment t21010, default-sample_flags in the trex box, default_sample_flags in the tfhd box, sample_flags in the trun box, and / or HDR related flags shown on the first_sample_flags in the trun box may be added.

First, the hdr_flag field may be included on each flag. The hdr_flag field may be a field indicating whether a corresponding media sample is an HDR video sample. When the value of this field is 1, it may be indicated that the corresponding sample is an HDR video sample. According to an embodiment, existence of flag fields to be described later may be determined by the value of the hdr_flag field.

The sdr_compatibility_flag field, the hdr_type_transition_flag field, and / or the hdr_sdr_transition_flag field have the same meaning as the above-described fields of the same name, but may be different in that they are described for the corresponding media sample (HDR video sample).

That is, the sdr_compatibility_flag field may indicate whether the corresponding HDR video sample is compatible with a decoder / display supporting SDR. The hdr_type_transition_flag field may indicate that HDR information (parameter) for the corresponding HDR video sample and HDR information for the HDR video sample subsequent thereto may be different. If the value of this field is 1, the current sample is the last HDR video sample to which the existing HDR information is applied, and the following samples may indicate that other HDR information may be applied. The hdr_sdr_transition_flag field may be a flag indicating whether the current HDR video sample is the last HDR sample, and the following samples are SDR samples. If the value of this field is 1, this may indicate that the corresponding sample is the last HDR sample, followed by the SDR samples.

In the illustrated embodiment t21020, the HDR information may be included in the visual sampel group entry. If the same HDR related flag can be applied to one or more video samples present in one media file or fragment, HDR flags, such as the illustrated embodiment, may be further included in the visual sample group entry.

The depicted HDR related flags have the same meaning as the flags of the same name described above, but in this case, the corresponding sample group may be described. That is, the hdr_flag field may indicate whether the corresponding sample group is an HDR video sample group. The hdr_type_transition_flag field may indicate whether HDR information (parameter) related to HDR video samples is changed to other HDR information and applied in the corresponding HDR video sample group. The hdr_sdr_transition_flag field may indicate whether to switch from HDR to SDR in the corresponding video sample group. The sdr_hdr_transition_flag field may indicate whether HDR transition is performed in SDR within a corresponding video sample group. The sdr_compatibility_flag field may indicate whether HDR video samples in the corresponding video sample group are compatible with a decoder / display supporting SDR.

In the illustrated embodiment t21030, HDR information may be included in the visual sampel group entry. If the same HDR information (parameter) can be applied to one or more video samples present in one media file or fragment, the hdr_flag field and the HDR configuration box may be further included in the visual sample group entry as shown in the illustrated embodiment. .

Here, the hdr_flag field may have the same meaning as the hdr_flag field in the aforementioned visual sample group entry. The information in the HDR configuration box may have the same meaning as the information in the HDR configuration box described above. In this case, however, each piece of information may be described for the corresponding sample group. That is, the information in the HDR configuration box can provide default HDR information (parameters) that can be commonly applied to HDR video samples of the corresponding sample group. Here, the average_frame_luminance_level field and / or the max_frame_pixel_luminance field may have different meanings. The average_frame_luminance_level field may indicate a maximum value among average values of luminance levels of each video sample belonging to the corresponding sample group. The max_frame_pixel_luminance field may indicate the largest value among the maximum values of pixel luminance of each video sample belonging to the corresponding sample group.

In the illustrated embodiment t21040, the HDR information may be included in the visual sampel entry. As initialization information required to decode respective video samples present in one media file or fragment, HDR flag information related to the sample may be further included in the visual sample entry.

The hdr_flag field may indicate whether the associated video track or sample includes the HDR video sample. The hdr_type_transition_flag field may indicate whether HDR information (parameter) for an associated video track or sample is changed and thus other HDR information is applied. The hdr_sdr_transition_flag field may be a flag indicating whether an associated video track or sample is switched from HDR to SDR. The sdr_hdr_transition_flag field may be a flag indicating whether an associated video track or sample is switched from SDR to HDR. The sdr_compatibility_flag field may be a flag indicating whether an associated video track or sample is compatible with the SDR decoder / display.

In the illustrated embodiment t21050, HDR information may be included in a visual sampel entry. As initialization information required to decode respective video samples present in one media file or fragment, HDR information (parameter) related to the sample may be further included in the visual sample entry.

The hdr_flag field may indicate whether the associated video track or sample includes the HDR video sample. The hdr_config box is an HDR configuration box and may include HDR information (parameters) about an associated video track or sample. Each of the information included in the above-described HDR configuration box may be as described above. In this case, however, each of the pieces of information may describe the associated video track or samples.

In the illustrated embodiment t22010, the HDR information may be included in the HEVC sample entry HEVCSampleEntry. As initialization information required to decode respective HEVC samples present in the media file or fragment, HDR information related to each HEVC sample or the like may be added as shown. The added HDR information may be added in the form of the above-described HDR configuration box according to an embodiment. According to an embodiment, the HDR information may be added in the same manner as AVC sample entry (AVCSampleEntry), AVC2 sample entry (AVC2SampleEntry), SVC sample entry (SVCSampleEntry), MVC sample entry (MVCSampleEntry).

In the illustrated embodiment t22020, the HDR information may be included in the HEVC Configuration Box. As initialization information required to decode respective HEVC samples present in the media file or fragment, HDR information related to each HEVC sample or the like may be added as shown. The added HDR information may be added in the form of the above-described HDR configuration box according to an embodiment. According to an embodiment, the HDR information may be added in the same manner as in the AVC configuration box (AVCConfigurationBox), the SVC configuration box (SVCConfigurationBox), the MVC configuration box (MVCConfigurationBox), and the like.

In the illustrated embodiment t22030, HDR information may be included in an HEVC decoder configuration record (HEVCDecoderConfigurationRecord). As initialization information required to decode respective HEVC samples present in the media file or fragment, HDR information related to each HEVC sample or the like may be added as shown. The added HDR information may be added in the form of the above-described HDR configuration box according to an embodiment. In this case, whether to add the HDR configuration box may be performed by the hdr_flag field. According to an embodiment, the HDR information may be added in the same manner as the AVC decoder configuration record (AVCDecoderConfigurationRecord), the SVC decoder configuration record (SVCDecoderConfigurationRecord), the MVC decoder configuration record (MVCDecoderConfigurationRecord), and the like.

The present invention defines an HDR information SEI box (HDRInformationSEIBox) (t23010). This box contains an SEI NAL unit, which may have an SEI message containing HDR related information. The HDR information SEI box may be called hisb box.

The HDR information SEI box may be included in the visual sample entry, the HEVC configuration box and / or the HEVC sample entry, as shown in the illustrated embodiments (t23020, t23030, t23040). Also, according to an embodiment, it may be included in an AVC sample entry, an MVC sample entry, and an SVC sample entry.

The present invention proposes a method for storing and / or signaling image quality improvement information that is commonly applicable to ISOBMFF or adaptive to various scene characteristics. Here, the image quality improvement information may include HDR information and WCG information. The present invention proposes a method of storing and / or signaling an HDR parameter related to a video track or a video sample of content providing HDR based on a media file such as ISOBMFF. Specifically, the present invention proposes a method for storing and / or signaling HDR parameters and / or WCG parameters associated with video samples. The present invention also proposes a method of storing and / or signaling HDR parameters and / or WCG parameters associated with video sample entries. The present invention can provide an image having an improved image quality by transmitting metadata about elements that can adjust the content in common or adaptively to various scene characteristics.

An HDR information box can be defined to provide picture quality improvement information related to video samples in a media file. The HDR information box may store and signal HDR static metadata and HDR dynamic metadata applicable to video samples included in the ISOBMFF. The HDR information box may include both HDR static metadata and HDR dynamic metadata in the above-described embodiment. The HDR information box may be referred to as an hdri box. The HDR information box can store and / or signal HDR metadata in the video sample.

The HDR information box may optionally include HDR information (or HDR video information) included in the above-described HDR information descriptor and / or HDR information included in the HDR configuration box. That is, the HDR information box may include some or all of the HDR information (or HDR video information) included in the HDR information descriptor and / or some or all of the HDR information included in the HDR configuration box or the like. As described above, the HDR information box may include not only parameters related to HDR but also parameters related to WCG.

The HDR information box may be applied to various positions depending on the object to which the image quality improvement parameter is applied. That is, the HDR information box may be included in the box defined in the existing ISOBMFF or may be included in the newly defined box.

The illustrated embodiment H39010 represents an HDR information box defined as a full box.

The illustrated embodiment H39020 represents an HDR information box that includes image quality enhancement parameters commonly applied to video data. Description of each field included in the illustrated embodiment will be described later.

40 is a diagram illustrating an HDR information box for providing image quality improvement information according to an embodiment of the present invention. FIG. 41 is a diagram illustrating an embodiment related to a specific type of field included in an HDR information box.

The illustrated embodiment H40010 represents an HDR information box including a quality improvement parameter applied to each video sample. The HDR information box can be applied to each video sample, as shown. Although an embodiment in which the HDR information box is applied to each video sample is illustrated in the drawing, the HDR box may be extended to a video clip, a video scene, or the like.

According to an embodiment, the HDR information box includes a sample_count field, an HDR_app_type field, a TF_type field, a CG_type field, a CT_type field, a set_num field, a version_num field, a max_mastering_display_luminance field, a min_mastering_display_luminance field, an average_frame_luminance_level field, a max_frame_pixel_lumin_trans_field field, hdr_flagg_trans_transition , sdr_compatibility_flag field, HDR_app_type_transition_flag field, WCG_info_transition_flag field, number_of_DR_info field, DR_mapping_info_present_flag field, CG_mapping_info_present_flag field, and / or VC_info_present_flag field.

The sample_count field may indicate the number of samples to which the quality improvement parameter to be described later is applied. The value of sample_count may be defined in the sample size box (stsz) of the international standard ISO / IEC 14496-12.

The HDR_app_type field may not only include all of the information indicated by the aforementioned HDR_info_type, but may also extend the aforementioned HDR_info_type. For example, information about a mastering display may be displayed or commonly applied in units of channels, programs, and content. In addition, it can be divided into tracks, continuous scenes, video clips, and frames. In particular, the HDR_app_type field may further include a case in which the target type is a video sample (frame). A specific embodiment H41010 regarding the HDR_app_type field is as shown.

The TF_type field may indicate the same information as the above-described transfer_function_type. That is, the TF_type field may indicate the type of transfer function used for the mastering display, channel, program, content, track, scene, clip, or frame of the HDR video. For example, predetermined EOTFs such as SMPTE ST 2084, ITU BT.1886, BT.2020 can be signaled, and the specific method is divided after signaling like absolute brightness expression, relative brightness expression method, etc. according to the transfer function. You may. If necessary, the coefficient of any transfer function may be transferred.

The CG_type field may indicate the same information as the color_gamut_type described above. That is, the CG_type field may indicate the type of color gamut corresponding to the mastering display, channel, program, content, scene, clip, or frame of the HDR video. For example, a standard color gamut such as BT.709, BT.2020, or DCI-P3 may be represented, or, if necessary, an arbitrary color gamut may be represented through an RGB color primary (XYZ, RGBW, etc.).

The CT_type field may indicate the same information as the color_temperature_type described above. That is, the CT_type field may indicate information about the reference white corresponding to the mastering display, channel, program, content, scene, clip, or frame. For example, it may be a standard light source color temperature such as D65 and D50, and if necessary, an arbitrary value representative of the color temperature may be represented, such as an RGB color primary for white (XYZ, RGBW, etc.).

The set_number field may indicate the same information as the above-described set_number. That is, the set_number field represents an identification number of characteristic values that the current HDR parameters have. For example, it may play a role of distinguishing each sample, clip, scene, etc. in a situation where a plurality of HDR characteristic values are transmitted in units of a sample, a clip, a scene, and the like. According to an embodiment, the set_number field may define a plurality of HDR characteristic values for each of common, frame, scene, etc. in association with the HDR_app_type field. For example, in case of delivering different DR mapping functions for the purpose of supporting a display having various kinds of luminance, it may play a role of distinguishing each other for common, frame, scene, etc. in connection with the above-described HDR_app_type field. have.

The version_number field may indicate the same information as the aforementioned version_number. That is, the version_number field may indicate a version of the HDR information box. The version_number field represents a version of the HDR information box. In connection with the HDR_app_type field and / or the set_number field, it may represent that there is a change among the HDR parameters included in the current HDR information box. For example, if the HDR information box with the same HDR_app_type field and / or set_number field has the same version number, the information in the metadata buffer can be applied to the image as it is.However, if the version_number field is changed, the information in the metadata buffer is updated. New information can be applied to the image.

The max_mastering_display_luminance field may indicate the same information as max_mastering_display_luminance included in the aforementioned HDR configuration box (HDRConfigurationBox). In other words, the max_mastering_display_luminance field may indicate a peak luminance value of the mastering display. This value can be an integer value between 100-10000.

The average_frame_luminance_level field may indicate the same information as average_frame_luminance_level included in the above-described HDR configuration box. That is, the average_frame_luminance_level field may indicate an average value of luminance level for one video sample. In addition, the average_frame_luminance_level field may indicate a maximum value among average values of luminance levels of each sample belonging to the sample group or video track (stream).

The max_frame_pixel_luminance field may indicate the same information as max_frame_pixel_luminance included in the above-described HDR configuration box. That is, max_frame_pixel_luminance may represent the maximum value of pixel luminance values for one video sample. In addition, max_frame_pixel_luminance may represent the largest value among the maximum values of pixel luminance of each sample belonging to the sample group or video track (stream).

The min_mastering_display_luminance field may indicate the same information as min_mastering_display_luminance included in the above-described HDR configuration box. That is, min_mastering_display_luminance may indicate the minimum luminance value of the mastering display. This value may be a fractional number between 0 and 0.1.

The hdr_info_transition_flag field may indicate the same information as hdr_type_transition_flag included in the above-described HDR configuration box. That is, the hdr_info_transition_flag field may be a flag indicating whether another HDR parameter is applied by changing an HDR parameter or the like.

The hdr_sdr_transition_flag field may indicate the same information as hdr_sdr_transition_flag included in the above-described HDR configuration box. That is, the hdr_sdr_transition_flag field may be a flag indicating whether to switch from HDR to SDR.

The sdr_hdr_transition_flag field may indicate the same information as sdr_hdr_transition_flag included in the above-described HDR configuration box. That is, the sdr_hdr_transition_flag field may be a flag indicating whether to switch from SDR to HDR.

The sdr_compatibility_flag field may indicate the same information as sdr_compatibility included in the above-described HDR configuration box. That is, the sdr_compatibility_flag field may be a flag indicating whether the SDR decoder or the SDR display is compatible.

The HDR_app_type_transition_flag field may be a flag indicating that the HDR_app_type has been changed. That is, the HDR_app_type_transition_flag field may indicate that the predetermined HDR_app_type is changed to another HDR_app_type. According to an embodiment, when the HDR_app_type_transition_flag field is 1, it may indicate that the HDR_app_type is changed.

The WCG_info_transition_flag field may be a flag indicating that WCG information has been changed. That is, the WCG_info_transition_flag field may indicate that predetermined WCG information is changed to other WCG information. According to an embodiment, when the WCG_info_transition_flag field is 1, it may indicate that the WCG information is changed.

Meanwhile, when the receiver is divided into an STB and a display device and connected through a wired / wireless interface, information indicating an interruption of SDR, HDR, and / or WCG related information or content termination may also be transmitted to the display device. . The above-described transition_flags may serve to inform the time of transition of the information or HDR application type. Meanwhile, the wired / wireless interface may be HDMI, DisplayPort, MHL, or the like.

The number_of_DR_info field may indicate the same information as the aforementioned number of DR information (number_of_dynamic_range_info). That is, the number_of_DR_info field may indicate the number of dynamic range information expression methods corresponding to a mastering display, channel, program, content, track, scene, clip, or frame.

The DR_info_type field may indicate the same information as the above-described DR information type (dynamic_range_info_type). That is, the DR_info_type field indicates a method of expressing dynamic range information corresponding to a mastering display, channel, program, content, track, scene, clip, or frame. The method for expressing the dynamic range is the same as the illustrated embodiment H41020. The dynamic range may be expressed using at least one of maximum brightness, minimum brightness, average brightness, average or median values composed of certain components. In addition, in the case of white, bright parts such as normal white, diffuse white, and specular white can be classified in detail according to their characteristics, and in the case of black, they can be classified according to their characteristics such as normal black, deep black, and pitch dark. Can be.

As shown in the drawing, the broadcast transmission device may express information such as specular white and pitch dark to subdivide the brightness of the directory and the dark part in the content. Such information may be used as a criterion for determining a receiver display environment or may be used as information for mapping according to the display environment. The DR_info_type field may have a meaning distinguished according to an application range HDR_app_type. For example, if the HDR_app_type is a frame, the average level may mean the brightness average in a single frame, but when the HDR_app_type is content, the average level may mean the maximum, minimum or median of the frame average in the content. have. According to an embodiment, elements for distinguishing the maximum value, the minimum value, or the median value may be further defined.

The DR_info_value field may indicate the same information as the above-described dynamic_range_info_value. That is, a corresponding value may be delivered according to the DR_info_value field. As shown below, each of content, mastering display, and scene DR can be expressed in detail according to the DR_info_value field. According to an embodiment, the DR_info_value field may be used to separately describe the characteristics of the container video format and the actual content.

The DR_mapping_info_present_type field may indicate the same information as the DR flag (dynamic_range_mapping_info_present_flag). That is, the DR_mapping_info_present_type field may represent that dynamic range mapping related information is included in a box. According to an embodiment, when the DR_mapping_info_present_type field is 1, it may represent that dynamic range mapping information is included in a mastering display, channel, program, content, track, scene, clip, or frame. When the DR_mapping_info_present_type field indicates that dynamic range mapping information is included in a box, the box may include a DR_mapping_info_type field.

The DR_mapping_info_type field may indicate the same information as the above-described DR mapping type (dynamic_range_mapping_info_type). That is, the DR_mapping_info_type field represents the type of dynamic range mapping information corresponding to the mastering display, channel, program, content, track, scene, clip, or frame. For example, the DR_mapping_info_type field refers to a Knee function information SEI message or a Tone mapping information SEI message included in HEVC, so that other SEI messages may refer to the information. In addition, the DR_mapping_info_type field may describe the content directly in a predetermined HDR information box. A specific embodiment H41030 regarding the dynamic_range_mapping_info_type field is as shown.

The CG_mapping_info_present_flag field may indicate the same information as the above-described CG flag color_gamut_mapping_info_present_flag. That is, the CG_mapping_info_present_flag field may represent that color gamut mapping related information is included in the box. According to an embodiment, when the CG_mapping_info_present_flag field is 1, it may represent that color gamut mapping related information is included in a mastering display, channel, program, content, track, scene, clip, or frame. When the CG_mapping_info_present_flag field indicates that color gamut mapping related information is included in a box, the box may include a CG_mapping_info_type field.

The CG_mapping_info_type field may indicate the same information as the above-described CG mapping type (color_gamut_mapping_info_type). That is, the CG_mapping_info_type field indicates the type of color gamut mapping information corresponding to the mastering display, channel, program, content, track, scene, clip, or frame. For example, the CG_mapping_info_type field may cite information defined in the color remapping information SEI message included in HEVC. In addition, the CG_mapping_info_type field may describe the content directly in the pre-defined HDR information box. A specific embodiment H41040 regarding the color_gamut_mapping_info_type field is as shown.

The VC_info_present_flag field may indicate the same information as the above-described viewing environment flag (viewing_condition_info_present_flag). That is, the VC_info_present_flag field may represent that the viewing condition related information is included in the box. According to an embodiment, when the VC_info_present_flag field is 1, it may represent that viewing condition related information is included in a mastering display, channel, program, content, track, scene, clip, or frame. When the VC_info_present_flag field indicates that the viewing condition related information is included in the box, the box may include a VC_info_type field.

The VC_info_type field may indicate the same information as the aforementioned viewing environment type (viewing_condition_info_type). That is, the VC_info_type field indicates the type of viewing condition information corresponding to the mastering display, channel, program, content, track, scene, clip, or frame. For example, the VC_info_type field may refer to information defined in viewing_condition defined as a separate SEI message, or may describe the content directly in a predetermined HDR information box.

When referring to the external SEI message for the aforementioned DR_mapping_info_type, CG_mapping_info_type, and VC_info_type, unlike the above, a method of directly signaling the payloadType of the SEI message may be used. For example, when referring to the Knee function information SEI message, a method of more specifically notifying through DR_mapping_info_type = 0 and payloadType = 141 may be used.

The image quality improvement information may be included in the structure of the above-described media file itself to store / transmit. In the present exemplary embodiment, information (parameters) related to image quality improvement may be added to a sample description box (stsd box), which is a lower box of the sample table box in the trak box. Added picture quality improvement information is shaded in the drawing.

In the illustrated embodiment, the hdr_flag field may be a flag indicating whether HDR video data is included in the video sample in the video track described by the stsd box. According to an embodiment, when the value of the hdr_flag field is 1, it may indicate that HDR video data is included in a video sample. In addition, when the value of the hdr_flag field is 1, the HDR information box may be included in the stsd box.

The hdr_info box may represent an instance of the HDR information box. That is, the hdr_info box may include detailed parameters related to image quality improvement for the HDR video data included in the video sample. Each attribute included in the hdr_info box may be the same as that included in the aforementioned HDR information box. That is, the hdr_info field includes the sample_count field, the HDR_app_type field, the TF_type field, the CG_type field, the CT_type field, the set_num field, the version_num field, the max_mastering_display_luminance field, the min_mastering_display_luminance field, the average_frame_luminance_level field, the hd__g_dr_dr_dr_dr_dr_dr_flag_transition_flaition_transition_transition_transition_transition_transition_transition_transition_transition_transition_transition_transition_fla It may include an HDR_app_type_transition_flag field, a WCG_info_transition_flag field, a number_of_DR_info field, a DR_mapping_info_present_flag field, a CG_mapping_info_present_flag field, and / or a VC_info_present_flag field.

The image quality improvement information may be included in the structure of the above-described media file itself to store / transmit. In the present embodiment, image quality improvement information (parameters) may be added to the tkhd box in the above-described moov box. Added picture quality improvement information is shaded in the drawing.

In the illustrated embodiment, the hdr_flag field may be a flag indicating whether HDR video data is included in the video track described by the tkhd box. According to an embodiment, when the value of the hdr_flag field is 1, it may indicate that HDR video data is included in the video track. In addition, when the value of the hdr_flag field is 1, the HDR information box may be included in the tkhd box.

The image quality improvement information may be included in the structure of the above-described media file itself to store / transmit. In the present embodiment, image quality improvement information (parameters) may be added to the aforementioned vmhd box. Added picture quality improvement information is shaded in the drawing.

Here, the vmhd box is a lower box of the above-described trak box and may provide general presentation related information about the corresponding video track.

According to an embodiment, detailed parameters related to image quality improvement may be simultaneously included in the tkhd box and the vmhd box. In this case, embodiments of the HDR information box structure included in each box may be combined with each other. When the tkhd box and the vmhd box include image quality improvement information at the same time, the values of the parameters of the HDR information box defined in the tkhd box may be overridden to the values of the parameters of the HDR information box defined in the vmhd box. That is, when the values of the quality improvement information defined in both are different, the value in the vmhd box may be used. For image quality improvement information not included in the vmhd box, image quality improvement information in the tkhd box may be used.

The image quality improvement information may be included in the structure of the above-described media file itself to store / transmit. In the present embodiment, image quality improvement information (parameters) may be added to the trex box in the aforementioned mvex box. Added picture quality improvement information is shaded in the drawing.

The trex box may include a default_hdr_flag field and / or a default_sample_hdr_flag field. According to the value of the default_hdr_flag field, a default_hdr_info box which is an HDR information box may be further included. In addition, depending on the value of the default_sample_hdr_flag field, a default_sample_hdr_info box which is an HDR information box may be further included.

The default_hdr_flag field may be a flag indicating whether HDR video data is included in a video track fragment included in the corresponding fragment. According to an embodiment, when the value of the default_hdr_flag field is 1, it may represent that the fragment includes HDR video data by default. When the value of the default_hdr_flag field is 1, a default_hdr_info box which is an HDR information box may be further included.

The default_hdr_info box may represent an instance of the HDR information box. That is, the hdr_info box may include detailed parameters related to image quality improvement for the HDR video data included in the video sample. Each attribute included in the hdr_info box may be the same as that included in the aforementioned HDR information box, ie, the hdr_info box may include the fields of the aforementioned HDR information box.

Other fields except the average_frame_luminance_level field and / or max_frame_pixel_luminance field among the fields of the box may play the same role as fields of the same name in the HDR information box included in the tkhd box described above. The average_frame_luminance_level field may indicate a maximum value among average values of luminance levels of each video sample belonging to a track fragment in the corresponding fragment. max_frame_pixel_luminance field The maximum_frame_pixel_luminance field may indicate the largest value among the maximum values of pixel luminance of each video sample belonging to the track fragment in the corresponding fragment.

The default_sample_hdr_flag field may be a flag indicating whether HDR video samples are included in a video track fragment included in the corresponding fragment. According to an embodiment, when the value of the default_sample_hdr_flag field is 1, it may be indicated that HDR video samples are included by default in the corresponding video track fragment. When the value of the default_sample_hdr_flag field is 1, a default_sample_hdr_info box which is an HDR information box may be further included.

The default_sample_hdr_config box may represent an instance of the HDR information box. That is, the default_sample_hdr_config box may include HDR-related detailed parameters that may be applied to each of the video samples included in the corresponding video track fragment. Each attribute included in the default_sample_hdr_config box may be the same as that included in the above-described HDR information box. That is, the default_sample_hdr_config box may include the fields of the aforementioned HDR information box.

Other fields except the average_frame_luminance_level field and / or max_frame_pixel_luminance field among the fields of the box may play the same role as fields of the same name in the HDR information box included in the tkhd box described above. The average_frame_luminance_level field may indicate an average value of luminance levels of each video sample belonging to a track fragment in a corresponding fragment. max_frame_pixel_luminance field This may indicate the maximum value of pixel luminance of each video sample belonging to the track fragment in the corresponding fragment.

The image quality improvement information may be included in the structure of the above-described media file itself to store / transmit. In this embodiment, image quality improvement information (parameters) may be added to the tfhd box in the above-described moof box. Added picture quality improvement information is shaded in the drawing.

In the illustrated embodiment H46010, the hdr_flag field may be a flag indicating whether HDR video data is included in a corresponding video track fragment described by the tfhd box. According to an embodiment, when the value of the hdr_flag field is 1, it may indicate that HDR video data is included in the corresponding video track fragment. When the value of the Hdr_flag field is 1, an hdr_info box which is an HDR information box may be further included.

The hdr_info box may represent an instance of the HDR information box. That is, the hdr_info box may include detailed parameters related to image quality improvement for the HDR video data included in the video sample. Each attribute included in the hdr_info box may be the same as that included in the aforementioned HDR information box.

In the illustrated embodiment H46020, the tfhd box may further include image quality improvement information according to the tr_flags value. When tf_flags includes 0x100000, this may indicate that a default value of the quality improvement parameter associated with the video sample included in the video track fragment exists. In this case, as shown in the illustrated embodiment, a default quality improvement parameter to be applied to the video sample may be stored and signaled. In the present embodiment, tf_flags is specified as 0x100000, but the value of tf_flag may be set to another value according to the embodiment.

In the illustrated embodiment H46030, the default_sample_hdr_info box may represent an instance of the HDR information box. That is, the default_sample_hdr_info box may include default picture quality improvement parameters that can be applied to each of the video samples included in the corresponding video track fragment. Each attribute included in the default_sample_hdr_info box may be the same as that included in the above-described HDR information box. That is, the default_sample_hdr_info box may include the fields of the above-described HDR information box.

Other fields except the average_frame_luminance_level field and / or max_frame_pixel_luminance field among the fields of the box may play the same role as fields of the same name in the HDR information box included in the tkhd box described above. The average_frame_luminance_level field may indicate an average value of luminance levels of each video sample belonging to a track fragment in a corresponding fragment. max_frame_pixel_luminance field This may indicate the maximum value of pixel luminance of each video sample belonging to the track fragment in the corresponding fragment. In this case, however, these fields may describe the video track fragment, not the entire video track.

The image quality improvement information may be included in the structure of the above-described media file itself to store / transmit. In the present embodiment, image quality improvement information (parameters) may be added to the trun box in the traf box described above. Added picture quality improvement information is shaded in the drawing.

In the illustrated embodiment H47010, the hdr_flag field may be a flag indicating whether HDR video data is included in a corresponding video track fragment. According to an embodiment, when the value of the hdr_flag field is 1, it may indicate that HDR video data is included in the corresponding video track fragment. When the value of the Hdr_flag field is 1, an hdr_info box which is an HDR information box may be further included.

The hdr_info box may represent an instance of the HDR information box. That is, the hdr_info box may include detailed parameters related to image quality improvement for the HDR video data included in the video track. Each attribute included in the hdr_info box may be the same as that included in the aforementioned HDR information box.

In some embodiments, the image quality improvement information may be simultaneously included in the tfhd box and the trun box. In this case, embodiments of the image quality improvement information structure included in each box may be combined with each other. When the image quality improvement information is included in the tfhd box and the trun box at the same time, the value of the image quality improvement information defined in the tfhd box may be overridden to the value of the image quality improvement information defined in the trun box. If the image quality improvement information in the trun box is not included, the image quality improvement information in the tfhd box may be used.

In the illustrated embodiment H47020, the trun box may further include image quality improvement information according to the tr_flags value. When tf_flags includes 0x002000, it may indicate whether there is information on an image quality improvement parameter that can be commonly applied to video samples included in the video track fragment. When tf_flags includes 0x001000, the trun box may indicate whether information about a quality improvement parameter applicable to each video sample in the video track fragment exists. In the present embodiment, when tf_flags is 0x002000 and tf_flags is 0x001000, the case where tf_flags is 0x001000 is specified. However, depending on the embodiment, the value of tf_flags may be set to a different value.

In the illustrated embodiment H47030, when the tf_flags value includes a value of 0x002000, the trun box may include an hdr_info box which is an HDR information box. The hdr_info box may include information on an image quality enhancement parameter that can be commonly applied to video samples included in the video track fragment. The attributes of the parameters included in the hdr_info box may have the same meaning as the attributes of the parameters of the above-described HDR information box.

In the illustrated embodiment H47040, when the tf_flags value includes a value of 0x001000, the trun box may include a sample_hdr_info box which is an HDR information box. The sample_hdr_info box may include information on an image quality enhancement parameter corresponding to each video sample in the video track fragment. The attributes of the parameters included in the sample_hdr_info box may have the same meaning as the attributes of the parameters of the above-described HDR information box.

In the illustrated embodiment H48010, the HDR information may be included in the visual sample group entry. The illustrated embodiment may provide a way to enable storing and signaling the same picture quality improvement related parameters in one or more video samples present in one media file or fragment.

The hdr_flags field may be a flag indicating whether the sample group is an HDR video sample group or not. According to an embodiment, when the hdr_flags field is 1, it may indicate that the corresponding sample group is an HDR video sample group. When the value of the hdr_flag field is 1, an hdr_info box which is an HDR information box may be further included.

The hdr_info box may represent an instance of the HDR information box. The hdr_info box may include a default HDR parameter that can be commonly applied to HDR video samples of a sample group. Attributes of each parameter included in the hdr_info box may be the same as those included in the above-described HDR information box.

In the illustrated embodiment H48020, the image quality improvement information may be included in the visual sample entry. The illustrated embodiment may provide a way to be able to store and signal initialization information necessary to decode each video sample present in one media file or fragment. Here, the initialization information required to decode each video sample may mean an image quality improvement parameter associated with each video sample.

The hdr_flags field may indicate whether an associated video track or sample includes an HDR video sample. According to an embodiment, when the value of the hdr_flag field is 1, an hdr_info box which is an HDR information box may be further included.

The hdr_info box may represent an instance of the HDR information box. The hdr_info box may include detailed parameters related to image quality improvement. Attributes of each parameter included in the hdr_info box may be the same as those included in the above-described HDR information box.

In the illustrated embodiment H49010, the quality improvement information may be included in the HEVC sample entry HEVCSampleEntry. The illustrated embodiment may provide a method of storing and signaling initialization information necessary to decode each HEVC samples present in a media file or fragment. Here, the initialization information necessary to decode each HEVC samples may mean an image quality improvement parameter associated with each HEVC sample. As shown in the illustrated embodiment, the quality improvement information may be included in the HEVCSampleEntry in the form of an HDR information box. According to an embodiment, the picture quality improvement information may be included in the same manner as the AVC sample entry, the AVC2 sample entry, the SVC sample entry, the MVC sample entry, and the like.

The hdr_info box may represent an instance of the HDR information box. The hdr_info box may include detailed parameters related to picture quality improvement related to HEVC samples. Attributes of each parameter included in the hdr_info box may be the same as those included in the above-described HDR information box.

In the illustrated embodiment H49020, the quality improvement information may be included in the HEVC configuration box. The illustrated embodiment may provide a method of storing and signaling initialization information necessary to decode each HEVC samples present in a media file or fragment. Here, the initialization information necessary to decode each HEVC samples may mean an HDR parameter associated with each HEVC sample. As shown in the illustrated embodiment, the quality improvement information may be included in the HEVCConfigurationBox in the form of an HDR information box. According to an embodiment, the picture quality improvement information may be included in the same manner as in the AVC configuration box (AVCConfigurationBox), the SVC configuration box (SVCConfigurationBox), the MVC configuration box (MVCConfigurationBox) and the like.

The hdr_info box may represent an instance of the HDR information box. The hdr_info box may include a quality improvement detail parameter related to the HEVC sample and the like. Attributes of each parameter included in the hdr_info box may be the same as those included in the above-described HDR information box.

In the illustrated embodiment H49030, the quality improvement information may be included in the HEVC decoder configuration record HEVCDecoderConfigurationRecord. The illustrated embodiment may provide a method of storing and signaling initialization information necessary to decode each HEVC samples present in a media file or fragment. Here, the initialization information necessary to decode each HEVC samples may mean an image quality improvement parameter associated with each HEVC sample. As shown in the illustrated embodiment, the quality improvement information may be included in the HEVCDecoderConfigurationRecord in the form of an HDR information box. According to an embodiment, the picture quality improvement information may be included in the same manner as the AVC decoder configuration record (AVCDecoderConfigurationRecord), the SVC decoder configuration record (SVCDecoderConfigurationRecord), the MVC decoder configuration record (MVCDecoderConfigurationRecord), and the like.

The hdr_info box may represent an instance of the HDR information box. The hdr_info box may include detailed parameters related to picture quality improvement related to video samples. Attributes of each parameter included in the hdr_info box may be the same as those included in the above-described HDR information box.

According to an embodiment of the present invention, a method of storing and / or signaling an image quality improvement parameter associated with a video scene, sequence, or clip may be provided. According to an embodiment of the present invention, a method for storing and / or signaling HDR parameters and / or WCG parameters associated with a video scene, sequence and / or clip may be provided.

According to an embodiment of the present invention, an sbgp box or an sgpd box may be used together with the HDR information box to provide scene-based HDR / WCG information. Here, the sbgp box and the sgpd box may mean a sample-to-group box and a sample group description box of the international standard ISO / IEC 14496-12, respectively.

In the illustrated embodiment H50010, the sbgp box includes a grouping_type field. The grouping_type field is a parameter representing a grouping type and may have an integer value. When grouping each sample into a scene, sequence, or clip, the grouping_type field may be assigned a predetermined integer value. For example, when scene # 1-100 exists, in order to assign a sample to each scene, the grouping type for each scene may have a value of 1-100. In addition, sample_count and group_description_index values may be determined for each grouping type value.

The illustrated embodiment H50010 has been described based on a scene, but the above description may be equally applied to a sequence or a clip as well as a scene.

In the illustrated embodiment H50020, the sgpd box includes a grouping_type field and a VisualSampleGroupEntry. The grouping_type field is a parameter representing a grouping type and may have an integer value. When grouping each sample into a scene, sequence, or clip, the grouping_type field may be assigned a predetermined integer value. For example, when scene # 1-100 exists, in order to assign a sample to each scene, the grouping type for each scene may have a value of 1-100. In addition, sample_count and group_description_index values may be determined for each grouping type value.

VisualSampleGroupEntry may indicate a visual sample group entry according to the grouping type. VisualSampleGroupEntry may provide HDR information and / or WCG information to a video based on a scene, sequence, or clip according to the parameters of the above-described visual sample group entry.

Meanwhile, when the HDR_app_type field included in the HDR information box described above indicates a scene or a clip, the sbgp box or the sgpd box may be used as well as the HDR information included in the HDR information box. That is, when the HDR_app_type field indicates a scene or a clip, the HDR / WCG information may be applied using the sbgp box or the sgpd box in addition to the HDR information box.

According to an embodiment of the present invention, when generating an ISOBMFF-based file, storing the above parameter for copy control relating to a video track, an audio track, a data track (stream), a video sample, an audio sample, and / or a data sample; In this case, a signalable box can be newly defined.

A copy control box (cpcl box) according to an embodiment of the present invention includes copy_control_flag information, num_copy_control_info information, num_play_control_info information, ep_copy_control_info information, trick_mode_control_flag information, num_output_control_info information, stereo_video_control_flag information, num_scalabilitychannel or audio_control can do.

The copy_control_flag information may indicate whether the video / audio / data (video, audio and / or data) track or sample is copy protected. For example, when the value of the copy_control_flag information is set to 0, it may indicate that copy protection is not applied to the corresponding track or sample, and when it is set to 1, it may indicate that copy protection is applied to the corresponding track or sample. have. As a default, the value of the copy_control_flag information may be set to one.

The num_copy_control_info information is information indicating the number of copies that can be copied to a video / audio / data track or a sample. For example, if the value of num_copy_control_info information is set to 0x00, it may indicate that copying is impossible, and if it is set to 0x01-0xFE, it may indicate the number of times that copying is possible, and if it is set to 0xFF, It may indicate that there is no limit.

The num_play_control_info information may correspond to information specifying the number of times a file can be played back in a device (eg, a broadcast receiver). For example, when the value of the num_play_control_info information is set to 0x00, it may indicate that playback is impossible, and when it is set to 0x01-0xFE, it may directly indicate the number of times that playback is possible, and when it is set to 0xFF, It may indicate no limitation. The num_play_control_info information may have a default value of 0xFF.

The ep_copy_control_info information may indicate an expiration period of recording and / or time-shift for content. When the value of the ep_copy_control_info information is set to 0x0000, it may indicate that there is no expiration period, and when it is set to 0x0001, it may indicate that an expiration period of 60 minutes is applied, and when it is set to 0x0002-0xFFFF, these bits indicate 2 to It may indicate that an expiration period of 65535 hours applies.

The trick_mode_control_flag information may indicate whether a trick mode is possible. For example, when the value of the trick_mode_control_flag information is set to 0, it may indicate that the trick mode control is impossible. When set to 1, it may indicate that the trick mode control is possible.

The num_output_control_info information may indicate designation of the number of output devices capable of simultaneously playing a corresponding file when the value of output_control_flag information (or copy_control_flag information) is 1. For example, when the value of num_output_control_info information is set to 0x00, it may indicate that playback is not possible on the multi-screen, and only the main playback device can play the file, and when set to 0x01, the main playback device In addition, one device may indicate that the content of the file can be played at the same time, and when set to '0x02-0Xff', it indicates that two or more devices other than the main playback device can play the content of the file at the same time. It can represent the number.

Next generation broadcast systems may provide n-screen services. By receiving a service in a broadcast system, it is possible to express the corresponding service on n screens. In this process, however, the service must be copied or retransmitted. In such an environment there is a need to be limited to allowing an unlimited number of screens to copy or retransmit the service. For example, if you have two or more televisions in one household, you can subscribe to a broadcast viewing plan to receive services for only one television, and copy or retransmit those services for the remaining televisions. A situation of watching a service on a device may occur. Since this situation is not desired by the broadcaster, the broadcaster may include the number of devices capable of providing the n-screen service in the broadcast viewing plan. In this case, the broadcast system may signal the number of output devices that a broadcaster allows and simultaneously reproduces using the num_output_control_info information.

The stereo_video_control_flag information may indicate whether copy of stereo video is possible. For example, when the value of the stereo_video_control_flag information is set to 0, it may indicate that stereo video cannot be copied, and that mono video can be copied, and when the value of the stereo_video_control_flag information is set to 1, stereo This may indicate that copying of the video is possible. The default value of the stereo_video_control_flag information may be zero.

The num_scalability_control_info information may indicate the number of scalability that can be copied with respect to media to which scalable coding has been applied. For example, when the value of the num_scalability_control_info information is set to 0x00, it may indicate that copying to media with scalable coding is not possible, and when the value of the num_scalability_control_info information is set to 0x01, one scalability copy is performed. It may indicate that it is possible, and when the value of the num_scalability_control_info information is set to 0x02-0xFF, it may indicate that two or more scalability copies are possible. Here, when the value of the num_scalability_control_info information is 0x01, it may indicate that only the base layer can be copied. When the value of the num_scalability_control_info information is 0x01-0xFF, the base layer and one or more enhancements may be used. It may indicate that copying to an enhancement layer is possible. As a default, a default value of num_scalability_control_info information may be 0x00.

The num_audio_channel_control_info information may indicate the number of channels that can be copied for multichannel audio. For example, when the value of num_audio_channel_control_info information is set to 0x00, it may indicate that copying to multichannel audio is impossible, and when the value of num_audio_channel_control_info information is set to 0x01-0xFF, one or more of multichannel audio may be used. It may indicate that copying for the channel is possible. As a default, a default value of num_audio_channel_control_info information may be 0x00.

In addition to the above-described information, the copy control box may further include the information described above or below in the present invention, and the name of the box and / or each parameter (information) may be changed.

The tkhd box may contain information describing attributes for the track (video / audio / data). The tkhd box may include creation_time information, modification_time information, track_ID information, and / or duration information. The tkhd box can be included in the moov box.

creation_time information is information indicating the time at which the track described by this box was created.

The modification_time information is information indicating the time when the track described by this box was modified.

The track_ID information is information for identifying a specific track in the entire presentation.

The duration information is information representing the duration of the track.

In addition to the above-described information, the tkhd box may include some or all of the information (copy control information) included in the above-described copy control box. That is, the tkhd box may further include copy_control_flag information, num_copy_control_info information, num_play_control_info information, ep_copy_control_info information, trick_mode_control_flag information, num_output_control_info information, stereo_video_control_flag information, num_scalability_control_info information, and / or num_audio_channel. In this case, the copy control information can describe the contents of the copy control for the corresponding track in track units.

The vmhd box, smhd box, hmhd box and / or nmhd box may include some or all of the above-described copy control information (or copy control parameters).

The vmhd box corresponds to a video media header box and may include general presentation information for video media.

The smhd box corresponds to a sound media header box and may include general presentation information for audio media.

The hmhd box corresponds to a hint media header box, and may include general information about a hint track.

The nmhd box corresponds to a null media header box, and may include general information about streams other than video or audio streams.

If the tkhd box, vmhd box, smhd box, hmhd box, and / or nmhd box contain copy control information at the same time, the value of the copy control information defined in the track header box is the vmhd box, smhd box, hmhd box, and / or nmhd box. Can be overridden by the value of the copy control information defined in.

When the copy control information is defined in the vmhd box, the smhd box, the hmhd box, and / or the nmhd box, the copy control may be applied in the unit described by the box.

The trex box can be included in the mvex box (movie extends box).

The trex box may include information for setting default values used by a movie fragment.

trex box track_ID information, default_sample_description_index information, default_sample_duration information, default_sample_size information, default_sample_flags information, default_sample_copy_control_flag information, default_sample_num_copy_control_info information, default_sample_num_play_control_info information, default_sample_ep_copy_control_info information, default_sample_ trick_mode_control_flag information, default_sample_ num_out_control_info information, stereo_video_control_flag information, num_scalability_control_info information and / or comprises a num_audio_channel_control_info information can do.

The track_ID information is information for identifying a track in a movie box.

The default_sample_description_index information, default_sample_duration information, default_sample_size information, and default_sample_flags information each include sample_description_index information indicating the index of the sample entry describing the sample, sample_duration information indicating the duration of the sample, sample_size information indicating the size of the sample, and the flags set for the samples. A default value for sample_flags information indicating a value may be indicated.

default_sample_copy_control_flag information, default_sample_num_copy_control_info information, default_sample_num_play_control_info information, default_sample_ep_copy_control_info information, default_sample_trick_mode_control_flag information, default_sample_num_out_control_info information, stereo_video_control_flag information, num_scalability_control_info information and num_audio_channel_control_info information are each above one copy_control_flag information, num_copy_control_info information, num_play_control_info information, ep_copy_control_info information, trick_mode_control_flag information, num_out_control_info information, stereo_video_control_flag information The basic values of the num_scalability_control_info information and the num_audio_channel_control_info information may be indicated. The default_sample_copy_control_flag information, the default_sample_num_copy_control_info information, the default_sample_num_play_control_info information, the default_sample_ep_copy_control_info information, the default_sample_trick_mode_control_flag information, the default_sample_num_out_control_info information, the stereo_video_control_flag information, the num_scalability control_info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the _info, the __, _, _, _, _ and _

According to another embodiment of the present invention, the default_sample_flags information may include copy_control_flag information, trick_mode_control_flag information, and / or stereo_video_control_flag information. Since the default_sample_flags information may include one or more flags for the samples, it may include copy_control_flag information, trick_mode_control_flag information, and / or stereo_video_control_flag information related to the samples.

The tfhd box can be included in the moof box.

Each movie fragment can add zero or more fragments to each track. A track fragment may contain zero or more consecutive samples. The tfhd box contains information for setting default values and / or information used for these samples.

tfhd box includes track_ID information, copy_control_flag information, num_copy_control_info information, num_play_control_info information, ep_copy_control_info information, trick_mode_control_flag information, num_out_control_info information, stereo_video_control_flag information, num_scalability_control_info information, num_audioset_channel_data_data_data It may include.

The base_data_offset information is information indicating a base offset for calculating an offset of data.

The description of the information contained in the tfhd box with the same name as the above-mentioned information is replaced with the above-mentioned description.

The trun box can be included in the track fragment box in the moof box.

The trun box contains information describing a set of samples for one track.

trun box includes sample_count information, copy_control_flag information, num_copy_control_info information, num_play_control_info information, ep_copy_control_info information, trick_mode_control_flag information, num_out_control_info information, stereo_video_control_flag information, num_scalability_control_info information, num_audiogs sample_fla Sample_composition_time_offset information may be included.

The sample_count information is information indicating the number of samples included in this fragment.

The description of the information contained in the trun box with the same name as the above-mentioned information is replaced with the above-mentioned description.

If all or part of the copy control information is simultaneously included in the tfhd box (Track fragment header box) and the trun box (track run box), the copy control information defined in the tfhd box is overridden by the value defined in the trun box. Can be

When copy control information is defined in a trun box, copy control may be applied in units of sets of samples.

According to another embodiment of the present invention, sample_flags information and / or first_sample_flags information may include copy_control_flag information, trick_mode_control_flag information, and / or stereo_video_control_flag information. Since sample_flags information and / or first_sample_flags information may include one or more flags for samples, it may include copy_control_flag information, trick_mode_control_flag information and / or stereo_video_control_flag information related to the samples.

The visual sample group entry may include copy_control_flag information, num_copy_control_info information, num_play_control_info information, ep_copy_control_info information, trick_mode_control_flag information, num_out_control_info information, stereo_video_control_flag information, num_scalability_control_info information, and / or audio.

In the information included in the visual sample group entry, the description of the information having the same name as the above information is replaced with the above description.

When copy control information is included in a visual sample group entry, the same copy control information may be applied to one or more video samples existing in one file or movie fragment. That is, when defining copy control information in a visual sample group entry, it is not necessary to define or signal a plurality of copy control information for each sample, thereby saving bandwidth for data transmission. It works.

The visual sample entry may include copy_control_flag information, num_copy_control_info information, num_play_control_info information, ep_copy_control_info information, trick_mode_control_flag information, num_out_control_info information, stereo_video_control_flag information, num_scalability_control_info information, and / or num_audio.

Description of information having the same name as the above-mentioned information among the information included in the visual sample entry is replaced with the above description.

When the visual sample entry includes copy control information, the copy control information may be applied to each sample as initialization information necessary to decode each sample existing in one file or movie fragment. have.

In this case, there is an effect that copy control is possible for each sample.

Based on the above-described ISOBMFF, when generating a file for the content that can be controlled for copying, generating a DASH segment that can operate on MPEG DASH, or generating an MPU that can operate on MPEG MMT, the copy control information is included in a corresponding unit. Can be included in The receiver allows the decoder (including the DASH client, and / or MMT client) to effectively perform decoding and / or display of the corresponding content using copy control information.

Some or all of the above-described copy control information may exist simultaneously in several boxes in one ISOBMFF file or DASH segment, MMT MPU. In this case, some or all of the copy control information defined in the upper box may be overridden by values of some or all of the copy control information having the same name defined in the lower box.

The pssh box may include information required by the content protection system to play the content.

The pssh box may include copy_control_flag information, num_copy_control_info information, num_play_control_info information, ep_copy_control_info information, trick_mode_control_flag information, num_out_control_info information, stereo_video_control_flag information, num_scalability_control_info information and / or num_audio_channel.

In a movie box or movie fragment box, if a pssh box can exist and the pssh box contains all or part of the copy control information, the copy control information is common to the video samples included in the track fragment. Can be applied as

The tenc box may be included in the Scheme Information Box.

The tenc box contains information related to encryption common to video samples included in the track fragment.

The tenc box may include default_copy_control_flag information, default_num_copy_control_info information, default_num_play_control_info information, default_ep_copy_control_info information, default_trick_mode_control_flag information, default_num_out_control_info information, stereo_video_control_flag information, num_scalability_control_info information, and / or channel.

When the tenc box includes some or all of the copy control information, the copy control information may be used as a default value for copy control on video samples included in the track fragment.

The senc box may be included in a track fragment box or a track box.

The senc box contains information related to the encryption that is applied to each sample.

The senc box may include copy_control_flag information, num_copy_control_info information, num_play_control_info information, ep_copy_control_info information, trick_mode_control_flag information, num_out_control_info information, stereo_video_control_flag information, num_scalability_control_info information and / or num_audio_channel_control_info.

If the senc box includes some or all of the copy control information, the copy control information may be applied to each of the video samples included in the track fragment. In this case, copy control is possible for each of the video samples.

CencSampleEncryptionInformationVideoGroupEntry may include copy_control_flag information, num_copy_control_info information, num_play_control_info information, ep_copy_control_info information, trick_mode_control_flag information, num_out_control_info information, stereo_video_control_flag information, numnum_scalability_control_info info / channel, and / or audio information.

CencSampleEncryptionInformationGroupEntry may include copy_control_flag information, num_copy_control_info information, num_play_control_info information, ep_copy_control_info information, trick_mode_control_flag information, num_out_control_info information, stereo_video_control_flag information, num_scalability_control_info info and / or channel.

When the handler type of the track is video ('vide'), if you want to apply the same copy control information to one or more video samples present in a file or movie fragment, all or all of the copy control information in CencSampleEncryptionInformationGroupEntry Some may be included.

If the handler's type of track indicates a type other than video, and you want to apply the same copy control information to one or more video samples that exist in a file or movie fragment, all of the copy control information in CencSampleEncryptionInformationGroupEntry or Some may be included.

According to an embodiment of the present invention, a copy control box may be defined to store and signal the parameters included in the above-described copy control box. According to an embodiment of the present invention, instead of defining a separate boxtype, a uuid (Universal Unique IDentifier) box type of ISOBMFF may be used as it is. According to an embodiment of the present invention, a box may be configured by further defining an extended type of 16 bytes. The illustrated syntax uses an extension type called CopyControlInfo, but an extension type other than CopyControlInfo type may be used. According to an embodiment of the present invention, a copy control parameter may be provided while using an existing ISOBMFF box type without defining a separate box type.

The picture quality improvement information according to an embodiment of the present invention may be described by the illustrated HDRConfiguration element.

According to an embodiment of the present invention, the HDR configuration description (HDR configuration information) may be included in the HDRConfiguration element and described by this element.

The HDRConfiguration element according to an embodiment of the present invention includes @schemeIdUri, @value and / or @id. Here, @schemeIdUri may be a mandatory field, and @value and @id may be an optional field. (L10010)

@schemeIdUri represents a URI that identifies the schema. The semantic of this element can be specified in the schema described by this attribute. This attribute can be a URN or a URL. If a URL is used as this attribute, this attribute may contain date information in the form mmyyyy.

@value represents the value for this element. The spatial and semantics for this value may be defined by the schema identified by @schemeIdUri described above.

@id represents an identifier for this element. Elements with the same attribute value may be identical to each other. In other words, if there are elements with the same attribute value, only one of these elements is processed and sufficient, and the other elements do not have to be processed.

HDRConfiguration element according to an embodiment of the present invention may be represented in the form of the bottom (L10020) of this figure.

65 and 66 illustrate a description of @schemeIdUri and @value of an HDRConfiguration element including picture quality improvement information according to an embodiment of the present invention. 67 is a view showing an embodiment related to a specific type of field included in an HDRConfiguration element.

According to an embodiment of the present invention, the @schemeIdUri of the HDRConfiguration element including the HDR configuration description may have urn: mpeg: dash: hdr: 201x.

According to an embodiment of the present invention, the @value of the HDRConfiguration element including the HDR configuration description is HDRAppType, TransferFunctionType, ColorGamutType, ColorTemperatureType, SetNumber, VersionNumber, ContrastRatio, FStop, PeakLuminanceLevel, MinLuminanceLevel, AverageLuminanceLevel, MedianLuminanceLevel, NormalWhiteLevel, DiffWhite NormalBlackLevel, DeepBlackLevel, PitchDarkLevel, HDRSDRTransitionFlag, SDRHDRTransitionFlag, SDRCompatibilityFlag, HDRInfoTransitionFlag, HDRAppTypeTransitionFlag, TransferFunctionTransitionFlag, WCGInfoTransitionFlag, ColorTemperatureTransitionFlag, HDRMappingInfoPresentFlag, HDRMappingFontInfo

The HDRAppType may indicate a range to which information for HDR configuration is applied. For example, the HDRAppType may indicate information on a mastering display, or may apply application information about a channel, a program, and a content unit, and may indicate application information about each of a series of scenes, video clips, and frames. In addition, the HDRAppType may indicate application information according to other criteria. For example, the HDRAppType may indicate application information by distinguishing between before and after conversion, a transmission format, a target target format after conversion, static metadata, and dynamic metadata. The HDRAppType may be expressed like the embodiment H67010 shown in the HDR Application Type and may be extended in the future.

The TransferFunctionType may indicate the type of transfer function used for the mastering display, channel, program, content, track, scene, clip, and / or frame of the HDR video. For example, a predetermined EOTF such as SMPTE ST 2084, ITU BT.1886, BT.2020, etc. may be signaled through TransferFunctionType. In addition, a specific method may be signaled through a TransferFunctionType after dividing an absolute brightness expression method or a relative brightness expression method according to the type of the transfer function. Depending on the embodiment, coefficients of any transfer function may be passed through TransferFunctionType. TransferFunctionType may be expressed as Transfer Functino Type (H67020) shown and may be extended in the future.

The ColorGamutType may indicate a type of color gamut corresponding to a mastering display, channel, program, content, track, scene, clip, and / or frame of the HDR video. For example, ColorGamutType may indicate standard color gamut such as BT.709, BT.2020, and DCI-P3. According to an embodiment, the ColorGamutType may represent any color gamut through RGB color primary, XYZ, or RGBW. The ColorGamutType may be represented as the illustrated Color Gamut type (H67030), and may be extended in the future.

The ColorTemperatureType may indicate information about a reference white corresponding to a mastering display, channel, program, content, track, scene, clip, and / or frame of a color gamut. For example, ColorTemperatureType may be a standard light source color temperature such as D65, D50. According to an embodiment, ColorTemperatureType may represent any value representative of color temperature, such as RGB color primary, XYZ, or RGBW for white.

SetNumber may indicate an identification number of characteristic values currently held by the HDR parameters. For example, SetNumber may play a role of distinguishing each sample, clip, scene, etc. in a situation where a plurality of HDR characteristic values are transmitted in units of a sample, a clip, a scene, and the like. According to an embodiment, SetNumber may be distinguished when defining a plurality of HDR characteristic values for each of common, frame, scene, etc. in association with HDR_info_type. For example, if different DR mapping functions are delivered to support displays with various kinds of luminance, SetNumber can play a role in distinguishing them.

VersionNumber represents the version of the HDR Configuration. VersionNumber may indicate that there is information change among HDR parameters included in the current HDR configuration element in association with HDR_app_type and / or set_number. For example, when the HDR configuration elements having the same HDR_app_type and / or set_number have the same version number, the information in the metadata buffer may be applied to the image as it is. However, when the version_number is changed, the updated new information may be applied to the image after updating using information in the metadata buffer.

ContrastRatio may indicate N at a contrast ratio of N: 1.

FStop can indicate N at 2 ^ N f-stop.

PeakLuminanceLevel may indicate a maximum brightness value.

MinLuminanceLevel may indicate a minimum brightness value.

AverageLuminanceLevel may indicate an average brightness value.

MedianLuminanceLevel may indicate a medium brightness value.

NormalWhiteLevel may indicate a normal white level value.

DiffuseWhiteLevel may indicate a diffuse white level value.

SpecularWhiteLevel may indicate a specular white level value.

NormalBlackLevel may indicate a normal black level value.

DeepBlackLevel may indicate a deep black level value.

PitchDarkLevel may indicate a pitch dark level value.

PeakLuminanceLevel, MinLuminanceLevel, AverageLuminanceLevel, MedianLuminanceLevel, NormalWhiteLevel, DiffuseWhiteLevel, SpecularWhiteLevel, NormalBlackLevel, DeepBlackLevel and / or PitchDarkLevel may have units such as nit or cd / m ² .

The HDRSDRTransitionFlag may be a flag indicating whether to switch from HDR to SDR.

SDRHDRTransitionFlag may be a flag indicating whether to switch from SDR to HDR.

SDRCompatibilityFlag may be a flag indicating compatibility with the SDR decoder / display.

The HDRInfoTransitionFlag may be a flag indicating whether another HDR parameter is applied by changing an HDR parameter or the like.

The HDRAppTypeTransitionFlag may be a flag indicating a case where an HDR applicable type (HDRAppType) is changed and another HDRAppType is applied. According to an embodiment, when the HDRAppTypeTransitionFlag is 1, this may indicate a transition of the HDRAppType.

The TransferFunctionTransitionFlag may be a flag indicating a case where a Transfer Function type is changed and another Transfer Function is applied. According to an embodiment, when TransferFunctionTransitionFlag is 1, this may indicate transition of a transfer function.

The WCGInfoTransitionFlag may be a flag indicating a case in which WCG information is changed to apply other WCG information. According to an embodiment, when the WCGInfoTransitionFlag is 1, this may indicate conversion of WCG information.

The ColorTemperatureTransitionFlag may be a flag indicating a case where color temperature information is changed to apply different color temperature information. According to an embodiment, when ColorTemperatureTransitionFlag is 1, this may indicate conversion of color temperature information.

The HDRMappingInfoPresentFlag may be a flag indicating whether HDR mapping related information is included in the HDR configuration element. According to an embodiment, when the HDRMappingInfoPresentFlag is 1, it may represent that HDR mapping related information is included in the HDR configuration element.

The HDRMappingInfoType may indicate an information type for HDR mapping. For example, HDRMappingInfoType may refer to a Knee function information SEI message or a Tone mapping information SEI message included in HEVC, and may quote information of another SEI message or directly describe content in an HDR configuration element. The HDRMappingInfoType may be expressed as the HDR mapping info type H67040 shown and may be extended in the future.

The WCGMappingInfoPresentFlag may be a flag indicating whether WCG mapping related information is included in the HDR configuration element. According to an embodiment, when the WCGMappingInfoPresentFlag is 1, it may represent that the WCG mapping related information is included in the HDR configuration element.

WCGMappingInfoType may indicate an information type for WCG mapping. For example, WCGMappingInfoType can refer to the information defined in the Color remapping information SEI message included in HEVC, or can describe the content directly in the HDR configuration element. The WCGMappingInfoType may be expressed as the illustrated WCG mapping info type (H67050) and may be extended in the future.

The ViewingConditionInfoPresentFlag may be a flag indicating whether the HDR configuration element includes the Viewing Condition mapping related information. According to an embodiment, when ViewingConditionInfoPresentFlag is 1, it may represent that the Viewing Condition mapping related information is included in the HDR configuration element.

ViewingConditionInfoType may indicate an information type for viewing condition mapping. For example, ViewingConditionInfoType may cite information defined in viewing_condition defined as a separate SEI message, or may directly describe content in an HDR configuration element.

The picture quality improvement information according to an embodiment of the present invention may be described by the common attributes and elements shown.

According to an embodiment of the present invention, the HDR description may be included in common attributes and elements. Common attributes and elements may be applied to an adaptation set, a representation, and / or a sub-representation.

Common attributes and elements according to an embodiment of the present invention are @profile, @HDRFlag, @HDRTypeTransitionFlag, @HDRSDRTransitionFlag, @SDRHDRTransitionFlag, @HDRInfoTransition, @HDRAppTypeTransition, @TransferFunctionTransition, @WCGInfoTransition, @ColorTemperatureTransat or FrameTransaction It may include an HDRConfiguration.

@profile may represent a profile related to a related representation in a list of media presentation profiles. The value of this attribute may be a subset of each value in a higher level hierarchical document (Representatino, Adapatation Set, MPD). This attribute may be optional.

@HDRFlag may be a flag indicating whether a corresponding video media component supports HDR. This attribute may be optional.

@HDRTypeTransitionFlag may indicate the end of the current HDR video media component or may indicate the transition from the current HDR type to another HDR type within the video media component. That is, if the HDR types are different, one or more values of the attributes and / or elements constituting the HDR may be different. For example, HDR type # 1 represents the type of HDR video media component with oeft: 3, max_lum: 100, min_lum: 0.5, max_frame_lum: 0, max_pixel_lum: 0, and HDR type # 2 represents oeft: 1, max_lum: Representing the type of the HDR video media component with 1000, min_lum: 0.05, max_frame_lum: 0, max_pixel_lum: 0, the two HDR video media components have different types. According to one embodiment, this attribute may be present if set to true, not present if set to false, and the default value of this attribute may be false.

@HDRSDRTransitionFlag may indicate the end of the current HDR video media component or may indicate the transition from HDR to SDR within the video media component. According to one embodiment, this attribute may be present if set to true, not present if set to false, and the default value of this attribute may be false.

@SDRHDRTransitionFlag may indicate the end of the current SDR video media component or may indicate the transition from SDR to HDR within the video media component. According to one embodiment, this attribute may be present if set to true, not present if set to false, and the default value of this attribute may be false.

@HDRInfoTransition may represent a transition of current HDR characterisitics within a video media component. According to one embodiment, this attribute may be present if set to true, not present if set to false, and the default value of this attribute may be false.

@HDRAppTypeTransition may indicate a transition of the current HDR applicable type within the video media component. According to one embodiment, this attribute may be present if set to true, not present if set to false, and the default value of this attribute may be false.

@TransferFunctionTransition can represent a transition of the current HDR Transfer Function within the video media component. According to one embodiment, this attribute may be present if set to true, not present if set to false, and the default value of this attribute may be false.

@WCGInfoTransition may indicate the transition of the current WCG type in the video media component. According to one embodiment, this attribute may be present if set to true, not present if set to false, and the default value of this attribute may be false.

@ColorTemperatureTransition can indicate the transition of the current color temperature within the video media component. According to one embodiment, this attribute may be present if set to true, not present if set to false, and the default value of this attribute may be false.

@SDRCompatibility may be a flag indicating whether the video media component is compatible with SDR. This attribute may be optional.

FramePacking may indicate frame-packing arrangement information of a corresponding video media component type. This element may be zero or more.

The HDRConfiguration may represent HDR configuration information of the video media component. This element may be zero or more.

According to another embodiment of the present invention, the HDR description may be included in common attributes and elements. Common attributes and elements may be applied to an adaptation set, a representation, and / or a sub-representation.

The common attributes and elements according to another embodiment of the present invention are @profile, @HDRFlag, @HDRTypeTransitionFlag, @HDRSDRTransitionFlag, @SDRHDRTransitionFlag, @HDRInfoTransition, @HDRAppTypeTransition, @TransferFunctionTransition, @WCGInfoTransition, @ColorTemperatureAppatibility, @ColorTemperatureTransition, It may include TransferFunctionType, @ColorGamutType and / or @ColorTemperatureType.

The description of @profile, @HDRFlag, @HDRTypeTransitionFlag, @HDRSDRTransitionFlag, @SDRHDRTransitionFlag, @HDRInfoTransition, @HDRAppTypeTransition, @TransferFunctionTransition, @WCGInfoTransition, @ColorTemperatureTransition, and @SDRCompatibility have been described above.

@HDRAppType may provide an identifier for the HDR applicable type of the source picture of the video media component. This attribute can be a positive integer expressed in decimal. This attribute may be optional.

@TransferFunctionType may provide an identifier for an opto-electronic transfer function curve of the source picture of the video media component. This attribute can be a positive integer expressed in decimal. This attribute may be optional.

@ColorGamutType may provide an identifier for the WCG of the source picture of the video media component. This attribute can be a positive integer expressed in decimal. This attribute may be optional.

@ColorTemperatureType may provide an identifier for the color temperature of the source picture of the video media component. This attribute can be a positive integer expressed in decimal. This attribute may be optional.

The common attributes and elements according to another embodiment of the present invention are @profile, @SetNumber, @VersionNumber, @ContrastRatio, @Fstop, @PeakLuminanceLevel, @MinLuminanceLevel, @AverageLuminanceLevel, @MedianLuminanceLevel, @NormalWhiteLevel, @DiffuseWhiteLevel, @SpecularWhite It may include @NormalBlackLevel, @DeepBlackLevel and / or @PitchDarkLevel.

@profile may represent a profile related to a related representation in a list of media presentation profiles. The value of this attribute may be a subset of each value in a higher level hierarchical document (Representatino, Adapatation Set, MPD). This attribute may be optional. This is as described above.

@SetNumber may provide an identifier for the HDR parameter of the source picture of the video media component. This attribute can be a positive integer expressed in decimal. This attribute may be optional.

@VersionNumber may provide an identifier for an HDR configuration version of a source picture of a video media component. This attribute can be a positive integer expressed in decimal. This attribute may be optional.

@ContrastRatio can express the contrast ratio. This attribute may be a non-negative fractional value. This attribute may be optional.

@Fstop can represent an F-stop. That is, @Fstop may mean N at 2 ^ N. This attribute can be a positive integer expressed in decimal. This attribute may be optional.

@PeakLuminanceLevel can express peak luminance level. This attribute can be a positive integer expressed in decimal. This attribute may be optional. This attribute can have a value of 100-10000.

@MinLuminanceLevel can express the minimum luminance level. This attribute may be a non-negative fractional value. This attribute may be optional. According to one embodiment, this attribute may have a value of 0-0.1.

@AverageLuminanceLevel can represent an average luminance level. This attribute can be a positive integer or a fraction. This attribute may be optional.

@MedianLuminanceLevel can express the median luminance level. This attribute can be a positive integer or a fraction. This attribute may be optional.

@NormalWhiteLevel may represent a normal white level. This attribute can be a positive integer or a fraction. This attribute may be optional.

@DiffuseWhiteLevel can represent a diffuse white level. This attribute can be a positive integer or a fraction. This attribute may be optional.

@SpecularWhiteLevel can represent a specular white level. This attribute can be a positive integer or a fraction. This attribute may be optional.

@NormalBlackLevel can represent a normal black level. This attribute can be a positive integer or a fraction. This attribute may be optional.

@DeepBlackLevel can express deep black level. This attribute can be a positive integer or a fraction. This attribute may be optional.

@PitchDarkLevel can represent pitch dark level. This attribute can be a positive integer or a fraction. This attribute may be optional.

Common attributes and elements according to another embodiment of the present invention may include @profile, @HDRMappingInfoPresentFlag, @HDRMappingInfoType, @WCGMappingInfoPresentFlag, @WCGMappingInfoType, @ViewingConditionInfoPresentFlag and / or @ViewingConditionInfoType.

@HDRMappingInfoPresentFlag may indicate HDR mapping information in a video media component. According to one embodiment, this attribute may be present if set to true, not present if set to false, and the default value of this attribute may be false.

@HDRMappingInfoType may provide an identifier for HDR mapping information of the source picture of the video media component. This attribute can be a positive integer expressed in decimal. This attribute may be optional.

@WCGMappingInfoPresentFlag may indicate WCG mapping information in the video media component. According to one embodiment, this attribute may be present if set to true, not present if set to false, and the default value of this attribute may be false.

@WCGMappingInfoType may provide an identifier for WCG mapping information of a source picture of a video media component. This attribute can be a positive integer expressed in decimal. This attribute may be optional.

@ViewingConditionInfoPresentFlag may indicate viewing condition information in the video media component. According to one embodiment, this attribute may be present if set to true, not present if set to false, and the default value of this attribute may be false.

@ViewingConditionInfoType may provide an identifier for viewing condition information of the source picture of the video media component. This attribute can be a positive integer expressed in decimal. This attribute may be optional.

The picture quality improvement information according to an embodiment of the present invention may be described by the illustrated content component.

According to an embodiment of the present invention, the HDR configuration may be included in a content component element.

According to an embodiment of the present invention, another content component element includes @id, @HDRFlag, @HDRTypeTransitionFlag, @HDRSDRTransitionFlag, @SDRHDRTransitionFlag, @HDRInfoTransition, @HDRAppTypeTransition, @TransferFunctionTransition, @WCGInfoTransition, @ColorTemperatureTransition, @SDRCompatibility, HDR It may include.

The ContnetComponent element is an element representing a description of one content component.

@id represents the identifier of the media component. This attribute can have a unique value within the corresponding adaptation set.

The description of @HDRFlag, @HDRTypeTransitionFlag, @HDRSDRTransitionFlag, @SDRHDRTransitionFlag, @HDRInfoTransition, @HDRAppTypeTransition, @TransferFunctionTransition, @WCGInfoTransition, @ColorTemperatureTransition, @SDRCompatibility, and HDRConfiguration are as described above.

Accessibility may indicate information about an accessibility scheme.

The image quality improvement information according to an embodiment of the present invention may be described by the illustrated segment base.

According to an embodiment of the present invention, the HDR configuration may be included in the SegmentBase element.

A SegmentBase element according to an embodiment of the present invention describes a SegmentBase element, which describes a type for segment base information indicating a base type for other elements.

SegmentBase element according to an embodiment of the present invention is @timescale, @HDRFlag, @HDRTypeTransitionFlag, @HDRSDRTransitionFlag, @SDRHDRTransitionFlag, @HDRInfoTransition, @HDRAppTypeTransition, @TransferFunctionTransition, @WCGInfoTransition, @ ColorTemperature / Transition, HDR It may include.

@timescale describes the timescale in seconds used to match different real-time duration values in the segment information.

Initialization represents a URL that contains the possible byte range for the initialization segment.

According to an embodiment of the present invention, when the above-described elements and / or attributes are signaled at the parent level and also at the parent level, at this time, the value and the child at the parent level If the value at the level is different, the values of the element and / or attribute signaled at the higher level may be overridden with values signaled at the lower level. For example, when an element and / or an attribute is signaled through the MPD and segmentBase, the values of the element and / or attribute of the MPD corresponding to the parent level are the values of the element and / or attribute of the segmentBase corresponding to the child level. Can be overridden.

According to an aspect of the present invention, a method for delivering picture quality improvement information using a media file format is provided. According to an aspect of the present invention, by defining the quality improvement information on the media itself rather than a separate signaling path, it is possible to improve efficiency in various next generation content systems supporting UHD broadcasting.

According to an aspect of the present invention, the signaling information for the HDR information and the WCG information may not need to be separately configured for the HDR media data or the WCG media data. Since the HDR information and the like can be identified by the media file itself, the receiver can grasp the HDR information and the like and perform an image quality improvement process before decoding the video data.

According to an aspect of the present invention, since the image quality improvement information may be defined in the basic media file itself, it may be compatible with various storage / delivery systems. That is, if the system uses the media file format, the image quality improvement process may be performed without changing or improving the structure of the additional storage / transmission system.

According to an aspect of the present invention, since the image quality improvement information is reflected at the time of generating the media file, the receiver may provide the media data as intended at the time of generating the media data. That is, according to an aspect of the present invention, the image quality improvement information may not be changed by signaling information.

According to another aspect of the present invention, image quality improvement information such as HDR parameters and / or WCG parameters may indicate information on a mastering display, or may be commonly applied in units of channels, programs, and content, and may include tracks, scenes, clips, and frames. It may be applied individually to the (sample) unit. That is, according to another aspect of the present invention, the image quality improvement information may be classified into static metadata and dynamic metadata. Accordingly, according to another aspect of the present invention, commonly applicable information and image quality improvement information adaptive to various scene characteristics may be signaled.

According to another aspect of the present invention, a method of storing and / or signaling copy control information using a media file format is provided. The copy control information may be included in a separately defined box and stored in a media file, or may be included in a predefined box. When the copy control information is included in a separately defined box, scalability is enhanced, and when the copy control information is included in a predefined box, compatibility is enhanced.

The present disclosure discloses a scheme for storing and / or signaling HDR information and / or WCG information. The HDR information and / or WCG information disclosed herein may be included in a media file and transmitted, or may be transmitted through a system level, such as a DASH MPD. That is, in the above-described embodiment, only when each HDR parameter and / or WCG parameter is included or transmitted in the media file (see FIGS. 39 to 63) or transmitted at the system level (see FIGS. 64 to 73) Although described, each parameter may be stored and / or transmitted at the media level, system level or media level and system level.

In addition, in the present specification, the HDR information and / or WCG information is provided in the form of an HDR information descriptor, an HDR configuration descriptor, an HDR information box, an HDR configuration box, and the like. Various parameters included in such descriptors, boxes, and the like may be applied to other descriptors, boxes, and the like within the scope of contradiction.

In this specification, terms such as HDR information and WCG information may be clearly distinguished, or may be used as a concept in which WCG information is included in the HDR information. According to an embodiment, the HDR information may be used as a concept including WCG information as well as HDR information.

The method for transmitting a broadcast signal according to an embodiment of the present invention may include generating a media file including video data and image quality improvement information (S74100), and generating one or more segments including the generated media file ( S74200), generating a broadcast signal including the generated one or more segments (S74300), and transmitting the broadcast signal (S74400).

In the generating of the media file (S74100), a media file including video data and image quality improvement information may be generated. Here, the media file may be an ISOBMFF based media file. Details of such a media file structure have been described above with reference to FIG. 29 and the like. The media file may include video data and picture quality improvement information. The image quality improvement information may mean the above-described HDR information and / or WCG information. The HDR information and / or the WCG information may be image quality improvement information described with reference to FIGS. 39 to 73. The picture quality improvement information may be applied to the video data and used to improve the picture quality of the video data.

According to an embodiment, the generating of the media file (S74100) may be performed by the apparatus for manufacturing the HDR broadcast service of FIG. 13.

In the generating of the segment (S74200), one or more segments including the media file generated in the generating of the media file (S74100) may be generated. In operation S74200, the generated media file may be processed into one or more segments. Here, the segment may be a DASH segment. According to an embodiment, the generating of the media file (S74100) and the generating of the segment (S74200) may be combined into one step. Here, the segment may be divided into an initialization segment including an ftyp box and a moov box, and a media segment including the aforementioned fragment.

The generating of the broadcast signal in operation S74300 may generate a broadcast signal including one or more generated segments.

In operation S74400, the broadcast signal may be transmitted. The broadcast signal may be transmitted through a broadcast network or broadband according to an adaptive streaming scheme. Details of the DASH-based adaptive streaming scheme and the DASH-based data model are described above with reference to FIGS. 9 and 10.

In one embodiment, the image quality improvement information may include at least one first image quality improvement parameter. The first quality improvement parameter may refer to quality improvement information commonly applied to the first video presentation unit constituting video data included in the media file. That is, the first quality improvement parameter may refer to quality improvement information that is commonly applied to a specific video presentation unit. The first quality improvement parameter may be included in the aforementioned HDR information box. For example, the first image quality improvement parameters may be image quality improvement parameters included in the HDR information box of FIG. 39 described above. Here, the video presentation unit may mean a track, scene, clip or frame unit. For example, the first quality improvement parameter may be commonly applied to the video track. As another example, the first quality improvement parameter may be commonly applied to the video scene. As another example, the first quality improvement parameter may be commonly applied to a video clip. As another example, the first quality improvement parameter may be commonly applied to a video frame (sample).

In another embodiment, the image quality improvement information may include at least one second image quality improvement parameter.

The second quality improvement parameter may refer to quality improvement information applied to each of the second video presentation units constituting video data included in the media file. That is, the second quality improvement parameter may refer to quality improvement information applied to various scenes of video data included in the media file, respectively. Here, various scenes of the video data may mean a track, a scene, a clip, or a frame (sample). Therefore, the second quality improvement parameter may be applied for each track, for each scene, for each clip, or for each frame. In other words, the second quality improvement parameter may be applied for each video presentation unit constituting the video data. As described above, the video presentation unit may mean a track, scene, clip, or frame unit. As an example, the second quality improvement parameter may be applied to each of the video tracks. As another example, the second quality improvement parameter may be applied to each of the video scenes. As another example, the second quality improvement parameter may be applied to each of the video clips. As another example, the second quality improvement parameter may be applied to each of the video frames (samples). The second quality improvement parameter may be included in the above-described HDR information box similarly to the first quality improvement parameter. For example, the second quality improvement parameter may be image quality improvement parameters included in the HDR information box of FIG. 40 described above.

The above-described first quality improvement parameter and the second quality improvement parameter may be used together. The first image quality improvement parameter may provide image quality improvement information that is commonly applied, and the second image quality improvement parameter may provide image quality improvement information adaptive to a scene. Also, the first video presentation unit to which the first quality improvement parameter is applied and the second video presentation unit to which the second quality improvement parameter is adaptively applied may be the same. For example, the first quality improvement parameter may be commonly applied to the video sample, and the second quality improvement parameter may be applied to each of the video samples separately.

In yet another embodiment, the video presentation unit may be a video sample. In this case, the second quality improvement parameter may be applied to each of the video samples constituting the video data. At this time, some of the video samples may be grouped into a video scene or a video clip. When grouping, the grouping type may be indicated in a grouping type field included in a sample-to-group box or a sample group description box of the ISO / IEC 14496-12 standard. An embodiment of grouping on a video sample basis is illustrated in FIG. 51 described above.

In yet another embodiment, the media file may include at least one copy control information. Specific examples of the copy control information are described in Figs. 51 to 63 and the corresponding descriptions. The copy control information can include copy control parameters associated with the media elements that make up the video data. Here, the media element may represent an element of video, audio and / or data. Specifically, the media element may be used as a term referring to a data set constituting video, audio and / or data. That is, media elements may represent content, components, segments (subsegments), tracks, samples, adaptation sets, and / or presentations of video, audio, and / or data.

Copy control parameters may provide copy control information associated with such media elements. According to an embodiment, the copy control parameters may provide copy control information related to the above-described video presentation. That is, the copy control parameter may provide copy control information for each track, scene, clip or frame.

Copy control parameters included in the media file may include a copy control flag, copy control count information, stereo video flag, audio channel number information, scalability number information, and the like, and may further include other parameters. Examples of more specific copy control parameters are described in FIGS. 51-63 and the corresponding description.

The media file may be included in a copy control box defined separately or in a predefined box. An example of the predefined box may be a uuid (Universal Unique IDentifier) box defined in ISOBMFF. Embodiments in which a media file is included in a copy control box defined separately are described in the description in FIG. 51 and the corresponding description. Incidentally, the embodiment in which the media file is included in a uuid (Universal Unique IDentifier) box defined in ISOBMFF is described in FIG. 63 and the corresponding description.

75 is a diagram showing the configuration of an apparatus for transmitting a broadcast signal according to an embodiment of the present invention.

An apparatus for transmitting a broadcast signal according to an embodiment of the present invention, the file generator 75100 for generating a media file including video data and image quality improvement information, and generating one or more segments including the generated media file The segment generator 75200 may include a broadcast signal generator 75300 for generating a broadcast signal including the generated one or more segments, and a broadcast signal transmitter 75400 for transmitting the broadcast signal.

The file generator 75100 may generate a media file including video data and image quality improvement information. Here, the media file may be an ISOBMFF based media file. Details of this media file structure are described in FIG. 29 and the corresponding description. The media file may include video data and picture quality improvement information. The image quality improvement information may mean the above-described HDR information and / or WCG information. The HDR information and / or the WCG information may be image quality improvement information described with reference to FIGS. 39 to 73. The picture quality improvement information may be applied to the video data and used to improve the picture quality of the video data.

The segment generator 75200 may generate one or more segments including the media file in which the file generator 75100 is generated. The segment generator 75200 may process the generated media file into one or more segments. Here, the segment may be a DASH segment. Here, the segment may be divided into an initialization segment including an ftyp box and a moov box, and a media segment including the aforementioned fragment.

The broadcast signal generator 75300 may generate a broadcast signal including one or more generated segments.

The broadcast signal transmitter 75400 may transmit the generated broadcast signal. The broadcast signal may be transmitted through a broadcast network or broadband according to an adaptive streaming scheme. Details of the DASH-based adaptive streaming scheme and the DASH-based data model are described above with reference to FIGS. 9 and 10.

In yet another embodiment, the media file may include at least one copy control information. According to another embodiment, the file generator 75100 may generate a media file including one or more copy control information. Specific examples of the copy control information are described in Figs. 51 to 63 and the corresponding descriptions. The copy control information can include copy control parameters associated with the media elements that make up the video data. Here, the media element may represent an element of video, audio and / or data. Specifically, the media element may be used as a term referring to a data set constituting video, audio and / or data. That is, media elements may represent content, components, segments (subsegments), tracks, samples, adaptation sets, and / or presentations of video, audio, and / or data.

The media file may be included in a copy control box defined separately or in a predefined box. An example of the predefined box may be a uuid (Universal Unique IDentifier) box defined in ISOBMFF. Embodiments in which a media file is included in a copy control box defined separately are described in the description in FIG. 51 and the corresponding description. Incidentally, the embodiment in which the media file is included in a uuid (Universal Unique IDentifier) box defined in ISOBMFF is described in FIG. 63 and its description.

According to an embodiment of the present invention, a method for receiving a broadcast signal includes receiving a broadcast signal including one or more segments (S76100), wherein the one or more segments include media data including video data and quality improvement information. Includes,-obtaining a media file including video data and image quality improvement information by processing a segment included in the received broadcast signal (S76200) and presenting the video data using the obtained image quality improvement information (S76300). ) May be included.

Receiving a broadcast signal (S76100), a broadcast signal including one or more segments may be received. Here, the one or more segments may include a media file containing video data and picture quality improvement information. In operation S76100, the broadcast signal may be a broadcast signal generated and transmitted by the method and / or apparatus for transmitting the above-described broadcast signal. According to an embodiment, the step (S76100) of receiving a broadcast signal may be performed by the receiver of FIG. 12. Here, the segment may be a DASH segment. The segment may be divided into an initialization segment including an ftyp box and a moov box, and a media segment including the aforementioned fragment. The broadcast signal may be received through a broadcast network or broadband according to an adaptive streaming scheme. Details of the DASH-based adaptive streaming scheme and the DASH-based data model are described above with reference to FIGS. 9 and 10.

In operation S76200, a media file including video data and image quality improvement information may be obtained by processing a segment included in the broadcast signal received in operation S76100. Here, the media file may be an ISOBMFF based media file. Details of such a media file structure have been described above with reference to FIG. 29 and the like. The media file may include video data and picture quality improvement information. The image quality improvement information may mean the above-described HDR information and / or WCG information. The HDR information and / or the WCG information may be image quality improvement information described with reference to FIGS. 39 to 73. The picture quality improvement information may be applied to the video data and used to improve the picture quality of the video data. According to an embodiment, the obtaining of the media file (S76200) may be performed by the apparatus for playing the broadcast service of FIG. 13 described above.

In the step of presenting the video data (S76300), the video data may be presented using the obtained image quality improvement information. According to an embodiment, the presenting of the video data (S76300) may be performed by the apparatus for reproducing the above-described broadcast service of FIG. 13.

In yet another embodiment, the media file may include at least one copy control information. The receiving side can perform copy control processing on the media file using the copy control information of one director. Specific examples of the copy control information are described in Figs. 51 to 63 and the corresponding descriptions. The copy control information can include copy control parameters associated with the media elements that make up the video data. Here, the media element may represent an element of video, audio and / or data. Specifically, the media element may be used as a term referring to a data set constituting video, audio and / or data. That is, media elements may represent content, components, segments (subsegments), tracks, samples, adaptation sets, and / or presentations of video, audio, and / or data.

An apparatus for receiving a broadcast signal according to an embodiment of the present invention includes a broadcast signal receiver 77100 for receiving a broadcast signal including one or more segments, wherein the one or more segments include video data and image quality improvement information. Including media data, a segment processor 77200 for processing a segment included in the received broadcast signal to obtain a media file including the video data and the image quality improvement information and the video data using the obtained image quality improvement information. It may include a presentation unit (77300) for presenting.

The broadcast signal receiver 77100 may receive a broadcast signal including one or more segments. Here, the one or more segments may include a media file containing video data and picture quality improvement information. The broadcast signal in the broadcast signal receiving unit 77100 may be a broadcast signal generated and transmitted by the method and / or apparatus for transmitting the above-described broadcast signal. According to an embodiment, the broadcast signal receiver 77100 may correspond to some components of the receiver of FIG. 12 described above. Here, the segment may be a DASH segment. The segment may be divided into an initialization segment including an ftyp box and a moov box, and a media segment including the aforementioned fragment. The broadcast signal may be received through a broadcast network or broadband according to an adaptive streaming scheme. Details of the DASH-based adaptive streaming scheme and the DASH-based data model are described above with reference to FIGS. 9 and 10.

The segment processor 77200 may obtain a media file including video data and image quality improvement information by processing a segment included in the broadcast signal received by the broadcast signal receiver 77100. Here, the media file may be an ISOBMFF based media file. Details of such a media file structure have been described above with reference to FIG. 29 and the like. The media file may include video data and picture quality improvement information. The image quality improvement information may mean the above-described HDR information and / or WCG information. The HDR information and / or the WCG information may be image quality improvement information described with reference to FIGS. 39 to 73. The picture quality improvement information may be applied to the video data and used to improve the picture quality of the video data. According to an embodiment, the segment processor 77200 may correspond to some components of the apparatus for playing the broadcast service of FIG. 13 described above.

The presentation unit 77300 may present video data by using the obtained image quality improvement information. According to an embodiment, the presentation unit 77300 may correspond to some components of the apparatus for playing the broadcast service of FIG. 13 described above.

In yet another embodiment, the media file may include at least one copy control information. In another embodiment, the broadcast signal receiving apparatus may further include a copy control unit which controls copying to a media file using copy control information. Specific examples of the copy control information are described in Figs. 51 to 63 and the corresponding descriptions. The copy control information can include copy control parameters associated with the media elements that make up the video data. Here, the media element may represent an element of video, audio and / or data. Specifically, the media element may be used as a term referring to a data set constituting video, audio and / or data. That is, media elements may represent content, components, segments (subsegments), tracks, samples, adaptation sets, and / or presentations of video, audio, and / or data.

The module or unit may be processors that execute successive procedures stored in a memory (or storage unit). Each of the steps described in the above embodiments may be performed by hardware / processors. Each module / block / unit described in the above embodiments can operate as a hardware / processor. In addition, the methods proposed by the present invention can be executed as code. This code can be written to a processor readable storage medium and thus read by a processor provided by an apparatus.

For convenience of description, each drawing is divided and described, but it is also possible to design a new embodiment by merging the embodiments described in each drawing. And, according to the needs of those skilled in the art, it is also within the scope of the present invention to design a computer-readable recording medium on which a program for executing the previously described embodiments is recorded.

Apparatus and method according to the present invention is not limited to the configuration and method of the embodiments described as described above, the above-described embodiments may be selectively all or part of each embodiment so that various modifications can be made It may be configured in combination.

On the other hand, it is possible to implement the method proposed by the present invention as a processor-readable code in a processor-readable recording medium provided in a network device. The processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor. Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet. . The processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.

In addition, although the preferred embodiment of the present invention has been shown and described above, the present invention is not limited to the above-described specific embodiment, the technical field to which the invention belongs without departing from the spirit of the invention claimed in the claims. Of course, various modifications can be made by those skilled in the art, and these modifications should not be individually understood from the technical spirit or the prospect of the present invention.

In addition, in this specification, both the object invention and the method invention are described, and description of both invention can be supplementally applied as needed.

It is understood by those skilled in the art that various changes and modifications can be made in the present invention without departing from the spirit or scope of the invention. Accordingly, 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.

Reference is made herein to both apparatus and method inventions, and the descriptions of both apparatus and method inventions may be complementary to one another.

Various embodiments have been described in the best mode for carrying out 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 changes and modifications can be made in the present invention without departing from the spirit or scope of the invention. Accordingly, 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

Generating a media file including video data and picture quality improvement information;

Creating one or more segments containing the created media file;

Generating a broadcast signal including the generated one or more segments; And

Transmitting the broadcast signal;

Broadcast signal transmission method comprising a.
The image quality improving information of claim 1,

A broadcast signal transmission method comprising high dynamic range (HDR) information or wide color gamut (WCG) information.
The image quality improving information of claim 1,

And at least one first quality improvement parameter commonly applied to a first video presentation unit constituting the video data.
The method of claim 1, wherein the media file,

And an HDR information box including the at least one first quality improvement parameter.
The image quality improving information of claim 1,

At least one second quality enhancement parameter,

The at least one second quality improvement parameter is applied to each of the second video presentation units constituting the video data.
The method of claim 5, wherein the second video presentation unit,

A broadcast signal transmission method, each one of a video track, a video scene, a video clip, and a video sample.
The method of claim 1, wherein the media file,

And an HDR information box configured with the at least one second quality improvement parameter.
The method of claim 6,

The second video presentation unit is a video sample,

The at least one second quality improvement parameter is applied to each of the video samples constituting the video data,

Some of the video samples are grouped into a video scene or video clip, where the grouping type to be grouped is in a grouping type field included in a sample-to-group box or a sample group description box. The broadcast signal transmission method indicated by.
The method of claim 1, wherein the media file,

At least one copy control information,

And the at least one copy control information comprises copy control parameters associated with a video presentation constituting the video data.
The method of claim 9, wherein the copy control information,

A copy control flag indicating whether copy control for the video presentation is applied, a copy control number information indicating a copy number for the video presentation, a stereo video flag indicating whether copying for stereo video is possible, and multiple channels A broadcast signal transmission method comprising audio channel number information indicating the number of channels that can be copied for audio and scalability number information indicating whether copying is possible for media to which scalable coding has been applied.
The method of claim 9, wherein the media file,

And a copy control box including the at least one copy control information.
The method of claim 9,

The at least one copy control information is included in a universal unique identifier (uuid) box predefined in the ISO Base Media File Format (ISOBMFF).
A file generator for generating a media file including video data and quality improvement information;

A segment generator which generates at least one segment including the generated media file;

A broadcast signal generator for generating a broadcast signal including one or more generated segments; And

A broadcast signal transmitter for transmitting the broadcast signal;

Broadcast signal transmission apparatus comprising a.