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

Abstract

The present invention proposes a method for transmitting a broadcast signal. The method of transmitting a broadcast signal according to the present invention proposes a system capable of supporting next-generation broadcasting services in an environment that supports next-generation hybrid broadcasting using a terrestrial broadcasting network and an Internet network. We also propose an efficient signaling scheme that can be used in both terrestrial broadcast networks and Internet networks in environments that support next-generation hybrid broadcasting. [Selection] Figure 33

Description

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

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

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

  In accordance with the purpose of the present invention, as included and generally described herein, the present invention effectively enables next-generation broadcasting services in an environment that supports next-generation hybrid broadcasting using a terrestrial broadcasting network and the Internet network. A system that can be supported and a related signaling scheme are proposed.

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

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

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

The accompanying drawings, which are included to provide a further understanding of the invention and are included in and constitute a part of this application, illustrate embodiments of the invention, together with a detailed description that illustrates the principles of the invention. .
It is a figure which shows the protocol stack based on one Example of this invention. It is a figure which shows the service discovery procedure which concerns on one Example of this invention. It is a figure which shows the LLS (Low Level Signaling) table and SLT (Service List Table) which concern on one Example of this invention. It is a figure which shows USBD and S-TSID transmitted by ROUTE according to an embodiment of the present invention. FIG. 3 is a diagram illustrating USBD transmitted by MMT according to an embodiment of the present invention. It is a figure which shows the link layer (Link Layer) operation | movement which concerns on one Example of this invention. It is a figure which shows LMT (Link Mapping Table) which concerns on one Example of this invention. It is a figure which shows the structure of the broadcast signal transmitter with respect to the next-generation broadcast service which concerns on one Example of this invention. FIG. 6 is a diagram illustrating a writing operation of a time interleaver according to an embodiment of the present invention. FIG. 4 is a block diagram of an interleaving address generator including a main-PRBS generator and a sub-PRBS generator according to each FFT mode included in a frequency interleaver according to an embodiment of the present invention. It is a figure which shows the hybrid broadcast receiver which concerns on one Example of this invention. FIG. 3 is a diagram illustrating a general operation of a DASH-based adaptive streaming model according to an embodiment of the present invention. It is a figure which shows the block diagram of the receiver which concerns on one Example of this invention. It is a figure which shows the structure of the media file which concerns on one Example of this invention. FIG. 5 is a diagram illustrating a bootstrapping process through an SLT according to an embodiment of the present invention. FIG. 6 is a diagram illustrating a flow of MMT protocol-based signaling according to an embodiment of the present invention. It is a figure which shows the capability descriptor based on one Example of this invention. It is a figure which shows the capability code which concerns on one Example of this invention. It is a figure which shows a part of USBD which concerns on the other Example of this invention. It is a figure which shows a part of MP table which concerns on one Example of this invention. It is a figure which shows the asset group descriptor which concerns on one Example of this invention. It is a figure which shows the accessibility (accessibility) information which concerns on one Example of this invention. It is a figure which shows the ComponentInfo element in USBD based on one Example of this invention. It is a figure which shows the component attribute (Component Property) information which concerns on one Example of this invention. It is a figure which shows the component attribute (Component Property) information which concerns on one Example of this invention. It is a figure which shows utilization of the component attribute (Component Property) information which concerns on one Example of this invention. It is a figure which shows HEVC video component description information based on one Example of this invention. It is a figure which shows HEVC timing & HRD information which concerns on one Example of this invention. FIG. 6 is a diagram illustrating caption information according to an embodiment of the present invention. It is a figure which shows the HDR information which concerns on one Example of this invention. It is a figure which shows the WCG information which concerns on one Example of this invention. FIG. 6 is a diagram illustrating HFR information / Pull Down information according to an embodiment of the present invention. FIG. 5 is a diagram illustrating signaling information related to 3D service and multi-view service according to an embodiment of the present invention. It is a figure which shows operation | movement of the media engine of the receiver based on HDR information processing capability based on one Example of this invention. It is a figure which shows operation | movement of the media engine of the receiver based on the WCG information processing capability based on one Example of this invention. It is a figure which shows operation | movement of the media engine of the receiver based on the HFR information processing capability based on one Example of this invention. It is a figure which shows operation | movement of the media engine of the receiver based on the pull-down recovery information processing capability based on one Example of this invention. FIG. 6 is a diagram illustrating metadata for supporting a 3D service according to an embodiment of the present invention. FIG. 5 is a diagram illustrating metadata for a bar according to an embodiment of the present invention. It is a figure which shows the metadata regarding the original source format which concerns on one Example of this invention. FIG. 5 is a diagram illustrating a method for generating a letterbox using bar data according to an embodiment of the present invention. FIG. 10 is a diagram illustrating a method of generating a letterbox using bar data according to another embodiment of the present invention. FIG. 5 is a diagram illustrating a method for generating a pillar box using bar data according to an embodiment of the present invention. FIG. 6 is a diagram illustrating a method for generating a pillar box using bar data according to another embodiment of the present invention. FIG. 5 is a diagram illustrating a method for transmitting a broadcast signal according to an embodiment of the present invention. 1 is a diagram illustrating an apparatus for transmitting a broadcast signal according to an embodiment of the present invention.

  Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. The following detailed description with reference to the accompanying drawings is intended to illustrate the preferred embodiments of the present invention, rather than to limit the possible embodiments of the present invention. The following detailed description includes details to provide a thorough understanding of the present invention. However, it will be apparent to those 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 common ones widely used in the field, but some of the terms may be arbitrarily selected by the applicant, and the meaning is as follows. This will be described in detail. Thus, 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 broadcasting service according to an embodiment of the present invention includes a terrestrial broadcasting service, a mobile broadcasting service, a UHDTV service, and the like. According to an embodiment, the present invention can process a broadcast signal for a next-generation broadcast service using a non-MIMO (non-Multiple Input Multiple Output) or a MIMO scheme. The non-MIMO scheme according to an embodiment of the present invention may include a MISO (Multiple Input Single Output) scheme, a SISO (Single Input Single Output) scheme, and the like. The present invention proposes a physical profile (or system) that is optimized to achieve the performance required for a particular application and to minimize the complexity of the receiver.

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

  The service can be transmitted to the receiver through a plurality of layers. First, service data can be generated on the transmission side. The delivery layer on the transmission side performs processing for transmission on the service data, and the physical layer can encode it into a broadcast signal and transmit it via a broadcast network or broadband.

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

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

  There are two methods for service delivery via a broadcast network.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Each MMTP session includes one or more MMTP packet flows that carry MMT signaling messages or all or some content components. The MMTP packet flow can carry components formatted as MMT signaling messages or MPUs.

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

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

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

  A broadcast stream transmitted by a broadcast signal frame of a physical layer can carry LLS (Low Level Signaling). LLS data can be carried in the payload of an IP packet that is conveyed to a well-known IP address / port. This LLS can include an SLT depending on its type. The LLS data can 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 for transmitting LLS data may be transmitted along with other service data via the same PLP.

  The SLT enables the receiver to generate a service list by high-speed channel scanning and provides access information for locating the SLS. The SLT includes bootstrap information, which allows the receiver to obtain a Service Layer Signaling (SLS) for each service. If the SLS, ie, service signaling information is conveyed in the ROUTE, the bootstrap information may include the destination IP address and destination port information of the LCT channel carrying the SLS or the ROUTE session that includes the LCT channel. When the SLS is transmitted in the MMT, the bootstrap information may include the destination IP address and destination port information of the MMTP session that carries the SLS.

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

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

  When SLS is communicated via the ROUTE protocol, the SLS can be communicated via the dedicated LCT channel of the ROUTE session indicated by the SLT. Depending on the embodiment, this LCT channel may be an LCT channel identified as tsi = 0. In this case, the SLS can include USBD / USD (User Service Bundle Description / User Service Description), S-TSID (Service-based Transport Session Indication / Migration PestM).

  Here, USBD or USD is one of the SLS fragments, and can serve as a signaling hub that describes specific technical information of a service. The USBD can include service identification information, device capability information, and the like. The USBD can 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). Specific contents of USBD / USD will be described later.

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

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

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

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

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

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

  A ROUTE session is identified by a source IP address, a destination IP address, and a destination port number. An LCT session is identified by a unique TSI (Transport Session Identifier) within the scope of the parent ROUTE session. The MMTP session is identified by the destination IP address and the destination port number. An MMTP packet flow is identified by a unique packet_id within the parent MMTP session.

  In the case of ROUTE, S-TSID, USBD / USD, MPD, or an LCT session that carries these can be called a service signaling channel. In the case of MMTP, a USBD / UD, MMT signaling message, or a packet flow that carries them can be called a service signaling channel.

  Unlike the illustrated embodiment, one ROUTE or MMTP session may be transmitted by a plurality of PLPs. That is, one service may be transmitted via one or more PLPs. Unlike the illustration, according to the embodiment, components constituting one service may be conveyed in a separate ROUTE session. Also, according to the embodiment, components constituting one service may be transmitted in a separate MMTP session. According to the embodiment, components constituting one service may be transmitted separately in a ROUTE session and an MMTP session. Although not shown, components constituting one service may be transmitted (hybrid delivery) via broadband.

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

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

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

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

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

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

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

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

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

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

  The svcInetUrl element can provide URL information for accessing signaling information for the service via broadband. The sltIntUrl element can further include an @urlType attribute, which can indicate the type of data obtained from the URL.

  The above-mentioned BroadcastSvcSignaling element includes @slsProtocol attribute, @slsMajorProtocolVersion attribute, @slsMinorProtocolVersion attribute, @slsPlpId attribute, @slsDestinationIpAddress attribute, @slsAddress attribute, and

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

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

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

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

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

  The userServiceDescription element includes an @globalServiceID attribute, an @serviceId attribute, an @serviceStatus attribute, an @fullMPDUri attribute, an @sTSIDURI attribute, a name element, a serviceLanguage element, and a capability element. Each field may be omitted depending on the value of the shown Use column, and a plurality of fields may exist.

  The @globalServiceID attribute is a globally unique identifier of the service, and may be used upon linking 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 the service ID information of the SLT. The @serviceStatus attribute can indicate the status of the service. This field can indicate whether the service is in an active state or an inactive state.

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

  The name element can provide the name of the service. This element can further include an @lang attribute, but this field can indicate the language of the name provided by the name element. The serviceLanguage element can indicate an available language of the service. That is, this element can enumerate languages that can provide the service.

  The capabilityCode element can indicate the capability or capability group information on the receiver side that is necessary for significantly reproducing the service. These pieces of information may be compatible with a capability information format provided by a service announcement.

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

  The broadcastAppService element can include transmission related information for the DASH representation transmitted over the broadcast network. This DASH representation can include media components that span all the periods of the service media presentation.

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

  The unicastAppService element can contain transmission related information for DASH representations transmitted over broadband. This DASH representation may include media components that span all periods of the service media presentation of interest.

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

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

  The @serviceId attribute is an identifier of the service, and can refer to the USBD / USD service. The RS element can describe information about a ROUTE session to which a service component of the service is transmitted. There may be a plurality of such elements depending on the number of such ROUTE sessions. 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 to which a service component of the service is transmitted. If this field is omitted, the default broadcast stream may be a broadcast stream including 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, @dIpAddr attribute, and @dport attribute may indicate the source IP address, destination IP address, and destination UDP port of the corresponding ROUTE session, respectively. If this field is omitted, the default value carries the corresponding SLS, i.e., the current IP address, destination IP address and destination UDP port of the current ROUTE session carrying the relevant S-TSID. It may be a value. This field may not be omitted for other ROUTE sessions that carry the service component of the service that is not currently a ROUTE session.

  The @PLPID attribute can indicate PLP ID information of the corresponding ROUTE session. When this field is omitted, the default value may be the PLP ID value of the current PLP to which the corresponding S-TSID is transmitted. Depending on the embodiment, this field may be omitted, and the PLP ID information of the corresponding ROUTE session may be confirmed by combining the information in the LMT described later and the IP address / UDP port information of the RS element.

  The LS element can describe information on the LCT channel on which the service component of the service is transmitted. There may be a plurality of such elements depending on the number of such LCT channels. 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 can indicate tsi information of the corresponding LCT channel. As a result, the LCT channel to which the service component of the service is transmitted can be identified. The @PLPID attribute can indicate PLP ID information of the corresponding LCT channel. Depending on the embodiment, this field may be omitted. The @bw attribute may indicate the maximum bandwidth of the corresponding LCT channel. The @startTime attribute can indicate the start time of the corresponding LCT session, and the @endTime attribute can indicate the end time of the corresponding LCT channel.

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

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

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

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

  The userServiceDescription element includes an @globalServiceID attribute, an @serviceId attribute, a Name element, a serviceLanguage element, a contentAdvisoryRating element, a Channel element, a mumpcomponent element, a component element, a component element, a component element, a component element, Each field may be omitted depending on the value of the shown Use column, and a plurality of fields may exist.

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

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

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

  The broadcastComponent element can contain a description for the service component of the service that is transmitted in broadband. In hybrid service delivery, some service components or other files of a service may be communicated via broadband. This element can describe information about such data. This element can further include an @fullMPDUri attribute. This attribute can refer to an MPD that describes a service component delivered over broadband. In addition to hybrid service delivery, this element may be used to support a handoff between the broadcast network and the broadband when the broadcast signal becomes weak due to traveling in a tunnel or the like. When the broadcast signal becomes weak, the service component is acquired via broadband. However, when the broadcast signal becomes strong again, the service component can be acquired via the broadcast network to ensure continuity of service.

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

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

  The routeComponent element described above may include an @sTSIDUri attribute, an @sTSIDDestinationIpAddress attribute, an @sTSIDDestinationUppPort attribute, an @sTSIDSourceIpAddress attribute, an @sTSIDMajorProtocolVersion attribute, and / or an @sID attribute.

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

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

  The @sTSIDMajorProtocolVersion attribute and the @sTSIDMinorProtocolVersion attribute can indicate a major version number and a minor version number of a transmission protocol used to convey the above-described S-TSID.

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

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

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

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

  The link layer may be a layer between the physical layer and the network layer. On the transmitting side, data can be transmitted from the network layer to the physical layer, and on the receiving side, data can be transmitted from the physical layer to the network layer (t6010). The purpose of the link layer is to abstract all input packet types into one format for processing by the physical layer, and flexibility and future expandability for undefined input packet types. It is possible to ensure that. In addition, the link layer can efficiently transmit input data by providing an option to compress unnecessary information in the header of the input packet. Operations such as link layer overhead reduction and encapsulation are called link layer protocols, and packets generated by the protocols can be called link layer packets. The link layer may have functions such as packet encapsulation, overhead reduction, and / or signaling transmission (Signaling Transmission).

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

  When an IP packet is input as an input packet (t6010), the link layer can perform IP header compression, adaptation, and / or encapsulation processes in order. Depending on the embodiment, some processes may be omitted. First, IP packet header compression is performed by the RoHC module to reduce unnecessary overhead, and context information can be extracted through an adaptation process and transmitted out of band. The IP header compression and adaptation process can be collectively referred to as IP header compression. Thereafter, the IP packet can be encapsulated into a link layer packet through an encapsulation process.

  When an MPEG2 TS packet is input as an input packet, the link layer can sequentially perform overhead reduction and / or encapsulation processes on the TS packet. Depending on the embodiment, some processes may be omitted. In overhead reduction, the link layer may provide sync byte removal, null packet removal and / or common header removal (compression). Sync byte removal can provide 1 byte overhead reduction per TS packet. The null packet may be deleted by a re-insertable method on the receiving side. Further, common information between consecutive headers may be deleted (compressed) by a method that can be restored on the receiving side. A part of each overhead reduction process may be omitted. Thereafter, the TS packet can be encapsulated into a link layer packet through an encapsulation process. The link layer packet structure for encapsulation of TS packets may be different from other types of packets.

  First, IP header compression is described.

  An IP packet has a fixed header format, but some information necessary in a communication environment may not be necessary in a broadcast environment. The link layer protocol can 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 an adaptation module. An IP header compressor (RoHC compressor) can reduce the size of each IP packet header based on the RoHC scheme. The adaptation module can then extract context information and generate signaling information from each packet stream. The receiver can parse the signaling information related to the corresponding packet stream and attach the context information to the packet stream. The RoHC decompressor can recover the packet header and reconstruct the original IP packet. Hereinafter, the IP header compression may mean only the IP header compression by the header compressor, or may mean a concept that combines the IP header compression and the adaptation process by the adaptation module. The same applies to decompressing.

  Hereinafter, adaptation will be described.

  In transmission over a unidirectional link, if the receiver does not have context information, the decompressor cannot recover the received packet header until it receives the complete context. This can lead to channel change delay and turn-on delay. Therefore, using the adaptation function, configuration parameters and context information between the compressor / decompressor can be transmitted out of band. An adaptation function may generate link layer signaling using context information and / or configuration parameters. The adaptation function may transmit link layer signaling periodically through each physical frame using previous configuration parameters and / or context information.

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

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

  Mode # 2 may be a mode in which IR packets are detected in the compressed packet stream to extract context information (static chain). After extraction, the IR packet is converted to an IR-DYN packet, and the IR-DYN packet can be transmitted in the same order in the packet stream in place of the original IR packet.

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

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

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

  The receiver can first obtain signaling information such as SLT, RDT, LMT by selecting the first PLP before obtaining the packet stream. When this signaling information is acquired, the receiver can combine these to acquire a mapping between service-IP information-context information-PLP. That is, the receiver can know what service is transmitted in which IP stream, what IP stream is transmitted in which PLP, and the context information of the PLP. Can be obtained. The receiver can select and decode the PLP that carries a particular packet stream. The adaptation module can parse the context information and combine it with the compressed packet. As a result, the packet stream can be recovered and transmitted to the RoHC decompressor. After that, decompression can begin. At this time, the receiver detects the IR packet in accordance with the adaptation mode, starts the decompression from the first received IR packet (mode 1), detects the IR-DYN packet, Decompression may be started from the received IR-DYN packet (mode 2), or decompression may be started from any general compressed packet (mode 3).

  Hereinafter, packet encapsulation will be described.

  The link layer protocol can encapsulate all types of input packets such as IP packets and TS packets into link layer packets. Thus, the physical layer only needs to process one packet format independently of the network layer protocol type (in this case, an MPEG-2 TS packet is considered as a kind of network layer packet). Each network layer packet or input packet is transformed into a generic link layer packet payload.

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

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

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

  Hereinafter, link layer signaling will be described.

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

  Link layer signaling can include internal link layer signaling and external link layer signaling. Internal link layer signaling may refer to signaling information generated at the link layer. The RDT mentioned above or the LMT described later corresponds to this. The external link layer signaling may be signaling information transmitted from an external module, an external protocol, or an upper layer. The link layer may encapsulate and transmit link layer signaling into link layer packets. A link layer packet structure (header structure) for link layer signaling can be defined, and the link layer signaling information can be encapsulated by this structure.

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

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

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

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

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

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

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

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

  The num_session field can indicate the number of upper layer sessions transmitted by the PLP identified by the PLP_ID field. Information regarding each session may be included depending on the number indicated by the num_session field. This information may include a 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 a source IP address, a destination IP address, a source UDP port, and a destination for the transmission session among upper layer sessions transmitted by the PLP identified by the PLP_ID field. A UDP port can be indicated.

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

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

  The SID field can indicate an SID (sub stream ID) for a link layer packet carrying the transmission session. This link layer packet may include an SID having the same value as the present SID field in its optional header. Through this, the receiver does not need to parse all the link layer packets, and can filter the link layer packets using the LMT information and the SID information of the link layer packet header.

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

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

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

  In other embodiments of the present invention, bootstrapping for ESG services may be performed over a broadcast network or broadband. ESG can be acquired via broadband and URL information of SLT can be used. ESG information or the like can be requested from this URL.

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

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

  In another embodiment of the present invention, the SLS fragment transmitted by the LCT packet (USBD, S-TSID, MPD, etc.) is identified from the TOI field of the LCT packet transmitted through the LCT channel carrying the SLS. can do.

  In another embodiment of the present invention, an application component used for an application-based enhancement / application-based service may be transmitted as an NRT component in a broadcast network or in broadband. Further, application signaling for application-based enhancement may be performed by an AST (Application Signaling Table) transmitted together with SLS. In addition, events that are signaling for operations performed by the application are transmitted together with SLS in the form of an EMT (Event Message Table), signaled in the MPD, or in-band in the form of a box in the DASH representation. It may be signaled. AST, EMT, etc. may be transmitted via broadband. Application-based enhancements and the like can be provided using the collected application components and such signaling information.

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

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

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

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

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

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

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

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

  The BICM block 1010 may include a processing block applied to a profile (or system) to which MIMO is not applied and / or a processing block of a profile (or system) to which MIMO is applied to process each data pipe. A plurality of processing blocks can be included.

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

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

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

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

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

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

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

  The frame building block adjusts the timing between the data pipe and the corresponding PLS data so as to ensure the co-time between the data pipe and the corresponding PLS data on the transmitter side. A cell mapper for mapping the compensation (delay compensation) block, PLS, data pipe, auxiliary stream, dummy cell, etc. to the active carrier of the OFDM symbol in the frame, and a frequency interleaver (frequency) interleaver).

  The frequency interleaver can provide frequency diversity by randomly interleaving data cells received from the cell mapper. In addition, the frequency interleaver uses an OFDM symbol pair (pair, pair, which is composed of two sequential OFDM symbols using different interleaving seed orders in order to obtain the maximum interleaving gain in a single frame. Can operate on data corresponding to a pair) or data corresponding to one OFDM symbol.

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

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

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

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

  The PLS FEC encoder externally encodes the scrambled PLS1 and 2 data using a scrambler for scrambling PLS1 data and PLS2 data, and a shortened BCH code for PLS protection, and inserts zero bits after BCH encoding. A BCH encoding / zero insertion block, an LDPC encoding block for encoding using an LDPC code, and an LDPC parity puncturing block. For PLS1 data only, zero insertion output bits can be permuted prior to LDPC encoding. The bit interleaver can interleave the respective shortened and punctured PLS1 data and PLS2 data, and the constellation mapper can map the bit interleaved PLS1 data and PLS2 data to the constellation.

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

  A broadcast signal receiving apparatus for a next generation broadcasting service according to an embodiment of the present invention includes a synchronization and demodulation module that performs demodulation corresponding to the reverse process of a procedure performed by a broadcast signal transmitting apparatus, and an input signal frame. A frame parsing module that extracts data transmitted by the service selected by the user, converts the input signal into bit area data, and then deinterleaves the bit area data as necessary to improve transmission efficiency. A demapping and decoding module that performs demapping on the mapping applied for the transmission and corrects errors generated in the transmission channel through decoding. & Decoding module), obtaining and processing PLS information from signals demodulated by the synchronization and demodulation module, and an output processor that performs the reverse process of various compression / signal processing procedures applied by the broadcast signal transmitting apparatus A signaling decoding module may be included. The frame parsing module, the demapping and decoding module, and the output processor can perform their functions using the PLS data output from the signaling decoding module.

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

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

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

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

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

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

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

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

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

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

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

  The physical layer module (s) can receive and process broadcast-related signals via a terrestrial broadcast channel, convert the signals into an appropriate form, and transmit them to the physical layer I / F module. .

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

  A service / content acquisition controller may perform a control operation for acquiring a service, content, and related signaling data through a broadcast and / or a broadband channel. it can.

  An Internet Access Control Module (s) can control the operation of a receiver for obtaining services, content, etc. via a broadband channel.

  A signaling decoder can decode the signaling information acquired through a broadcast channel or the like.

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

  A service guide manager (Service Guide Manager) can extract announcement information from an IP datagram or the like, manage an SG (Service Guide) database (database), and provide a service guide.

  An application signaling manager (App Signaling Manager) can extract, parse and manage signaling information related to application acquisition from an IP datagram.

  An alert signal parser can extract, parse and manage signaling information related to alerts from IP datagrams and the like.

  A Targeting Signal Parser can extract, parse and manage signaling information related to service / content personalization or targeting from IP datagrams and the like. The targeting signal parser can also transmit the parsed signaling information to the targeting processor.

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

  A non-real time file processor can extract, decode, and manage data in the form of files such as NRT data and applications from IP datagrams.

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

  A targeting processor may process service / content personalization related operations based on the targeting signaling data received from the targeting signal parser.

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

  An A / V processor can perform audio / video rendering-related operations based on decoded audio and video data, application data, and the like.

  A device manager can connect to external devices and exchange data. In addition, the device manager can perform management operations on external devices such as adding / deleting / updating external devices that can be linked.

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

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

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

  An external module (External Module (Management)) may refer to a module for providing a broadcast service / content, and may be a next-generation broadcast service / content server, for example. An external module can refer to an external device connected to a broadcast receiver.

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

  The present invention proposes a next-generation media service provision method that provides content capable of supporting HDR (High Dynamic Range). In the case where HDR content capable of expressing rich brightness is provided, the present invention proposes related metadata and a transmission method thereof. Through this, it is possible to adaptively adjust the content according to the various scene characteristics of the content, and to provide the content with improved image quality.

  In the case of UHD broadcasting or the like, brightness that cannot be expressed by existing content can be expressed, so that a high level of realism can be provided. With the introduction of HDR, the expression range of the brightness of the content video is increased, and the difference in the characteristics of the content according to the scene can be larger than before. In order to effectively show the scene-specific features of the content on the display, metadata can be defined and communicated to the receiver. Based on the transmitted metadata, the receiver can appropriately provide the content video according to the intention of the service provider.

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

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

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

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

  A DASH client controller can generate commands that request MPDs and / or segments, reflecting network conditions. The controller can also control the acquired information so that it can be used by an internal block such as a media engine.

  The MPD parser (Parser) can parse the acquired MPD in real time. Through this, the DASH client controller can generate a command that can acquire a necessary segment.

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

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

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

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

  The receiver according to the illustrated embodiment includes a tuner, a physical layer controller, a physical frame parser, a link layer frame processor, and IP / UDP data. Filter (IP / UDP Datagram Filter), DTV Control Engine (DTV Control Engine), ROUTE Client (Route Client), Segment Buffer Control (Segment Buffer Control), MMT Client (MMT Client), MPU Reconstruction (MPU Reco) instruction), media processor (Media Processor), signaling parser (Signaling Parser), DASH client (DASH Client), ISO BMFF parser (ISO BMFF Parser), media decoder (Media Decoder) and / or HTTP access client (HTTP Ccc) Can be included. Each detail block of the receiver may be a hardware processor.

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

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

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

  The MMT client processes MMT (MPEG Media Transport) transmission protocol packets supporting real-time object transmission, and can collect and process a large number of packets. The MPU reconstruction can reconstruct an MPU (Media Processing Unit) from the 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 or the like based on the acquired and parsed signaling parser. This configuration can handle low level signaling and service level signaling.

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

  FIG. 14 is a diagram illustrating the structure of a media file according to an embodiment of the present invention.

  A stylized media file format may be defined for storing and transmitting media data such as audio or video. Depending on the 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. Here, the box may be a data block or an object including media data or metadata related to the media data. The boxes can be hierarchically structured with respect to each other so that the data is classified and the media file has a form suitable for storing and / or transmitting large-capacity media data. In addition, the media file may have an easy structure in accessing the media information, such as the 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.

  The ftyp box (file type box) can provide file type or compatibility related information for the media file. The ftyp box can include configuration version information for the media data of the media file. The decoder can classify the media file with reference to the ftyp box.

  The moov box (movie box) may be a box including metadata for the media data of the media file. The moov box can act as a container for all metadata. The moov box may be a top layer box among the metadata related boxes. Depending on the embodiment, there may be only one moov box in a media file.

  The mdat box (media data box) may be a box for storing actual media data of the media file. The media data can include audio samples and / or video samples, and the mdat box can act as a container for placing such media samples.

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

  The mvhd box (movie header box) can include media presentation related information of media data included in the media file. That is, the mvhd box can include information such as media generation time, change time, time standard, and duration 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 depending on the number of tracks.

  The trak box may further include a tkhd box (track header box) as a lower box according to an embodiment. The tkhd box can include information regarding the track indicated by the trak box. The tkhd box can include information such as the generation time, change time, and track identifier of the track.

  The mvex box (movie extend box) can indicate that a moof box described later can exist in the media file. In order to know all the media samples of a particular track, the moof box must 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 can be divided and stored or transmitted. The media data (mdat box) of the media file is divided into a plurality of fragments, and each fragment may include a moof box and a divided mdat box. Depending on the embodiment, information of the ftyp box and / or the moov box may be required to take advantage of the fragment.

  The moof box (movie fragment box) can provide metadata for the media data of the fragment. The moof box may be a top layer box among the metadata related boxes of the fragment.

  The mdat box (media data box) can include actual media data as described above. The mdat box can include media samples of media data corresponding to each of the fragments.

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

  The mfhd box (movie fragment header box) may include information related to the association between a plurality of divided fragments. The mfhd box can indicate the number of data obtained by dividing the media data of the relevant fragment by including a sequence number (sequence number). In addition, it is possible to check whether there is any missing data among the divided data using the mfhd box.

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

  Depending on the 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) can include header information of the track fragment. The tfhd box can provide information such as a basic sample size, a period, an offset, and an identifier for the media sample of the track fragment indicated by the traf box.

  The trun box (track fragment run box) can include information related to the track fragment. The trun box may contain information such as the duration, size, playback time, etc. for each media sample.

  The aforementioned media file or media file fragment can be processed and transmitted as a segment. The segment can be 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, etc., except for media data. This file may correspond to, for example, the initialization segment described above. The initialization segment can include the ftyp box and / or the moov box described above.

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

  The type box (segment type box) can provide information for identifying media data of divided fragments. The styp box can play the same role as the above-described ftyp box for the divided fragments. Depending on the embodiment, the styp box may have the same format as the ftyp box.

  The sidx box (segment index box) can provide information indicating an index for the divided fragment. Through this, it is possible to indicate the number of the fragment that has been divided.

  Depending on the embodiment (t14040), a ssix box may further be included, the ssix box (sub-segment index box) providing information indicating an index of the sub-segment when the segment is further divided into sub-segments. Can do.

  The box in the media file may include further expanded information based on a form of a box or a full box (FullBox) like the illustrated embodiment (t14050). In this embodiment, the size field and the largeize field can indicate the length of the box in bytes. The version field can indicate the format version of the box. The type field can indicate the type or identifier of the box. The flags field can indicate a flag related to the box.

  FIG. 15 is a diagram illustrating a bootstrapping process through an SLT according to an embodiment of the present invention.

  As described above, SLS bootstrapping may be performed via SLT bootstrap information. As described above, the SLT may be transmitted after being processed by IP / UDP, or may be transmitted without being processed by IP / UDP according to an embodiment. Generally, LLS (Low Level Signaling) such as SLT can be transmitted by the most robust method in the transmission.

  When the SLS is transmitted by the ROUTE protocol, the receiver can approach the SLS via the SLT bootstrap information. The service component of the service can be acquired using the information of the ROUTE SLS. Here, the SLS and service components may be transmitted by ROUTE, UDP, and IP protocols.

  If the SLS is transmitted according to the MMT protocol, the receiver can access the SLS via the bootstrap information of the SLT. The service component of the service can be acquired using the MMTP SLS information. The MMTP SLS may include USBD and / or MMTP messages. As described above, the USBD can refer to the MMTP message, and the MPT message in the MMTP message can provide information for obtaining the streaming component conveyed by the MMT protocol. The MMT USBD can further reference the S-TSID for acquiring the NRT component of the service transmitted by the ROUTE protocol. In addition to the MPT message described above, other MMTP messages for providing other information may be defined. Here, the SLS and streaming components may be conveyed by MMT, UDP, and IP protocols. Here, the NRT component may be transmitted by ROUTE, UDP, and IP protocols. The detailed bootstrapping process is as described above.

  FIG. 16 is a diagram illustrating an MMT protocol-based signaling flow according to an embodiment of the present invention.

  First, the process of acquiring the SLT and using this to acquire the SLS may be the same. For MMT-based signaling, the SLS can include USBD and / or MMTP messages. Information about the MMT package (Package) related to the service can be acquired from the USBD. By using this, an MPT (MP Table) message can be acquired from a service signaling channel or the like. The service component of the service can be acquired via the MPT message. In the illustrated embodiment, information about assets for the base layer of scalable coding content (Asset) and / or assets for the enhancement layer can be obtained. In addition, a route (such as a transmission session) in which each asset can be acquired can be acquired. Here, the asset may correspond to a service component of the service. The MPU can be acquired via the path, and can be decoded and reproduced. The detailed bootstrapping process is as described above.

  Depending on the embodiment, MMTP messages other than MPT messages may be defined. Additional information about the service can be transmitted via these messages. For example, scalable coding related information, 3D related information, HDR related information, color gamut related information, additional information for service components, and the like may be transmitted via these messages. Depending on the embodiment, MPD for service components communicated via broadband, or table for application signaling, event information may also be communicated via this message.

  FIG. 17 is a diagram illustrating a capability descriptor according to an embodiment of the present invention.

  The present invention proposes a method of signaling capability information of a service component included in a broadcast service or service. Signaling may be performed for capabilities or capability groups for services / service components, and capability information may be signaled depending on the target device.

  The aforementioned SLT may include capability information. It may be capability information for the entire service described by the SLT, or may be capability information of a service level for each service described by the SLT. The above-mentioned @sltCapabilities attribute or @svcCapabilities attribute may correspond here. If the SLT has a binary format, capability information may be included in the SLT as an SLT level descriptor or an SLS level descriptor.

  The capability descriptor shown in the figure represents the above-described capability information in the form of a descriptor. However, according to the embodiment, the capability information may be expressed in other formats such as XML. Also, depending on the embodiment, information such as information in the illustrated capability descriptor may be included in the above-described SLT @sltCapabilities attribute or @svcCapabilities attribute. In this case, the descriptor tag, descriptor length information, and the like may be omitted. Below, this capability information is demonstrated on the basis of a descriptor.

  The capability descriptor of the illustrated embodiment may include a descriptor_tag field, a descriptor_length field, and / or a num_capability_codes field. The descriptor_tag field and the descriptor_length field can respectively provide information for identifying that the descriptor is a capability descriptor, and length information of the descriptor.

  The num_capability_codes field can indicate the number of capability information included in the descriptor. Depending on the embodiment, this field may indicate the number of capability codes included in the descriptor. Depending on the value of the num_capability_codes field, a detail field for each capability information may be further included. The detail field may include an essential_indicator field, a capability_category field, and / or a capability_code field. Depending on the embodiment, the essential_indicator field may be omitted.

  The essential_indicator field may indicate whether a subsequent capability code is a capability that must be supported when playing the service or service component. If the value of this field is 1, it can be known that the following capabilities must be supported when playing the service or service component.

  The capability_category field can indicate a category of capability information that follows. Depending on the embodiment, this field may indicate a target to which subsequent capability information is applied. The capability category information may be for classifying capability categories. Depending on the embodiment, the capability category information may be for grouping capabilities that can be equally applied to the service or service component. Through this, capabilities that are applied to the components in the service in the same manner or capability information that is applied to each component can be signaled.

  For example, when the value of this field is 0x02, the capability may be a capability related to the video component. That is, it can be known that the following capability code is a capability code for the video-related capability. For example, a capability code associated with a video codec, resolution, video provision method, transmission protocol, FEC algorithm, target device, etc. may follow.

  When the value of this field is 0x03, the capability may be a capability related to the audio component. That is, it can be known that the following capability code is a capability code for the audio-related capability. For example, capability codes associated with audio codecs, audio channels, transmission protocols, FEC algorithms, target devices, etc. may follow.

  When the value of this field is 0x04, the capability may be a capability related to a closed caption. For example, the capability code associated with the type of closed caption, transmission protocol, FEC algorithm, target device, etc. may follow.

  When the value of this field is 0x05, the capability may be a capability related to the application. For example, the capability code associated with the type of application, transmission protocol, FEC algorithm, target device, etc. may be followed.

  When the value of this field is 0x06 to 0x08, the capability may be a capability related to a transmission protocol, an FEC algorithm, and a target device, respectively. That is, it is not a capability associated with video / audio / closed caption / application. In this case, the transmission protocol, FEC algorithm and items for the target device indicated by the following capability code can be applied to all components (video / audio / closed caption / application) in the service.

  The capability_code field can indicate a capability code indicating capability information for the service or service component. Here, the capability code may be a code value designated for each capability. This will be described later.

  For example, if a broadcast service provides UVC video based on HEVC, 7.1 channel audio based on MPEG-H, and closed caption based on SMPTE timed text (Timed Text), the descriptor May have a capability code indicating this. In this case, num_capability_code may have a value of 0x05. The five capability_codes can have values of 0x13 (HEVC), 0x22 (ultra high definition video), 0x40 (MPEG-H audio), 0x52 (7.1 channel) and / or 0x60 (SMPTE timed text), respectively. . Here, the essential_indicator field may be omitted.

  FIG. 18 is a diagram illustrating a capability code according to an embodiment of the present invention.

  As described above, the capability code may be a code indicating the capability for the service or service component. The illustrated capability code may be a value that can be used in the capability_code field described above. Each classification (video, audio, etc.) of the illustrated capability codes may be a value that can be used in the capability_category field described above.

  Depending on the embodiment, the digits at the front of the illustrated capability code (eg, 0x01, 0x02, 0x03 ...) may be used to identify a capability category. In this case, the remaining digits of the capability code can be used to identify the capability within the category. The capability code according to an exemplary embodiment of the present invention may include a capability code for a high quality video enhancement type (High Quality Video Enhancement Type). For example, when the capability code is 0xA0, HDR (high dynamic range), when it is 0xA1, when it is WCG (wide color gamut), and when it is 0xA2, it can indicate HFR (high frame rate).

  FIG. 19 is a diagram showing a part of a USBD according to another embodiment of the present invention.

  The present invention proposes a method of signaling capability information of a service component included in a broadcast service or service. The present invention also proposes a scheme for signaling video / audio / closed caption information for a service / service component. The present invention also proposes a scheme for signaling HEVC video related information for a service / service component. The present invention also proposes a scheme for signaling information on SMPTE-TT or CEA-809 based closed captions for services / service components. The present invention also provides 3D for services / service components, scalable content, component groups, real-time or non-real-time content, accessibility, view configuration for display area, and target A method for signaling information about the screen is proposed. The present invention also provides a method for signaling HDR (High Dynamic Range), WCG (Wide Color Gamut), HFR (High Frame Rate), and Pull Down Recovery Configuration (Pull Down Recovery Configuration) information for a service / service component. To do. The present invention also proposes a scheme for signaling 3D audio, AC-4, and MPEG-H related information for services / service components. In addition, the present invention proposes a scheme for signaling PIP (Picture in Picture) related information in relation to a service / service component. In this connection, PIP SRD (Spatial Relationship Description) related information, display priority information, SRD signaling information between different content sources, signaling information for the display area of each view, and each view Signaling information regarding the role of (view) may be signaled.

  The information described above may be transmitted by being included in SLT or other service signaling information according to an embodiment. Depending on the embodiment, the information may be transmitted by being included in USBD by ROUTE or MMT. Also, depending on the embodiment, this information may be defined as one of the ROUTE SLS and may be transmitted along with other SLS, and may be defined as one of the MMTP SLS and be included in one of the MMTP messages described above. It may be included and communicated. Depending on the embodiment, these pieces of information may be included and transmitted in the MPD. In this case, the information may be included and transmitted in the above-described essential property (EssentialProperty) and / or supplemental property (SupplementalProperty). Depending on the embodiment, the information may be included in the MPT message described above in the MMTP message, or may be included in one of the separately defined MMTP messages. Depending on the embodiment, these pieces of information may be defined and transmitted in various descriptors in XML or binary form, or may be included in signaling information formed by elements, such as ROUTE, MMT, 3GPP, etc. . This information will be described later in detail.

  The ROUTE or MMT USBD described above may include a ComponentInfo element, depending on the embodiment. The ComponentInfo element is as described above. Depending on the embodiment, the ComponentInfo element may be extended to further include the illustrated fields.

  In the illustrated example, the ComponentInfo elements are @componentGroupId, @essentialIndicator, @dependentComponentID, @protocolTypeType, @rt, @ targetDevice @ componentCode, @componentProh, It may further include Targeting, Component Description and / or ComponentProperty. Depending on the embodiment, only a portion of this added field may be added to the ComponentInfo element.

  @ComponentGroupId may be an identifier of a component group. Here, a component group can be a collection of components. Components included in a component group may be components that show the same scene or are combined to generate a presentation. For example, service components including music, dialogs, and sound effects used to provide completed audio can be grouped into a component group. In addition, service components including a left video and a right video of 3D video can be grouped into one component group.

  @EssentialIndicator can indicate whether the component is an essential component in the service. When the value of this field is 1, the component may be an essential component in the service. @DependentComponentID can indicate an identifier for a dependent component. For example, in the enhanced video component, this field can indicate the identifier of the base video component.

  @ProtocolType may indicate a transmission protocol that conveys the component. For example, a ROUTE or MMT protocol can be indicated. @Rt can indicate whether the component is a real-time component.

  @TargetDevice can indicate the target device targeted by the component. For example, if the value of this field is 0, 1, 2, 3, it may indicate that the component is a component for the primary device, companion device, primary & companion device, and primary screen inset, respectively. it can.

  @ComponentCodec can provide codec information for the component. @ComponentProfile can indicate the profile of the component. @ComponentLang can indicate the language used in the component. This field can be used especially in audio and closed caption components. @Width can indicate the horizontal width of the video media presentation transmitted by the video component. @Height can indicate the vertical height of the video media presentation conveyed by the video component.

  Accessibility can provide accessibility related information for the component. Capability can provide capability-related information for the component. Rating can provide rating related information for the component. Targeting can provide information related to targeting or personalization of the component. ComponentDescription can provide component description information for the component. This information may include codec dependent encoding parameters. ComponentProperty can provide component attributes for processing the component.

  In addition, the above-mentioned @componentType field in the ComponentInfo element can indicate the type of the component. When the component has a value of 0, 1, 2, or 3, the component is an audio, video, caption, or application component, respectively. You can show that there is.

  Also, the @componentRole field can indicate the role of the component. This role can be indicated according to the indicated component type. In the case of an audio component, if this field has a value of 1, 2, 3, 4, 5, 6, 7, the audio component is Can play the role of complete main, music, effects, dialog, commentary, visually implied, hearing impaired, voice over, and subset it can. Here, visual / hearing impair may mean that the audio component is an audio component for a visually impaired person. Voice over may mean that the audio component serves to desk video components.

  In the case of a video component, depending on the value of this field, the video component may include primary video, alternative camera view, sign language, 3D left video, 3D right video, 3D video depth information, video including caption, etc. Can show that In the case of a caption component, depending on the value of this field, it may mean that the caption component plays a role of main, alternative, supplement, normal, easy reader, and the like.

  Depending on the embodiment, the rest of the ROUTE or MMT USBD described above can also be modified. Such changes may be combined with each other depending on the number of cases. Depending on the embodiment, the USBD may further include @providerid, @serviceCategory, @spIndicator, @serviceStatus, @shortServiceName, and / or capabilityCode.

  @Providerid can identify the service provider of the service. @ServiceCategory can indicate the category of the service. @SpIndicator may be the same as the above-mentioned @protected attribute. @ServiceStatus may be the same as the @servicestatus attribute described above. @ShortServiceName can indicate the short name of the service. The capabilityCode may indicate a capability or capability group that is required for the receiver to provide a meaningful media presentation of the service.

  Depending on the embodiment, the USBD may further include @majorChannelNo, @minorChannelNo, and / or @serviceLange in the above-described Channel element.

  @MajorChannelNo, @minorChannelNo can indicate the major / minor channel number of the service. @ServiceLange can indicate the primary language of the service.

  Depending on the embodiment, the USBD may further include a dashComponent element instead of the above-described routeComponent and broadcastComponent. The dashComponent element can include an @fullMPDUri, @sTSIDUri, and / or deliveryMethod element.

  @FullMPDUri can provide reference information to the MPD for service components delivered over a broadcast network or broadband. @STSIDUri can provide transmission session related information for the service component of the service. The deliveryMethod can provide transmission related information of the service component of the service. As described above, elements for each of the components transmitted via the broadcast network / broadband and / or basePattern information for the elements may be further included.

  FIG. 20 is a diagram showing a part of an MP table according to an embodiment of the present invention.

  The MPT message described above can carry the MP table. As described above, information such as proximity (proximity), 3D, and caption may be transmitted via the MMTP message. As illustrated, it may be transmitted as part of the MPT message, or may be transmitted as MMT signaling via a separately defined MMTP message. These information and transmission modes will be described later in detail.

  Such information may be conveyed in the form of a descriptor in an MPT message or other MMTP message, and according to an embodiment, this descriptor may correspond to an asset descriptor. The descriptor may be transmitted by being included in DVB SI service signaling such as SDT or EIT, or may be transmitted together.

  According to an embodiment, information on a service component (corresponding to an asset) on the MMT may be signaled as illustrated. A field to be described later may be further added to the MMTP message.

  The service_type field can indicate the type of the service. That is, it may mean a final service that can be provided in combination with at least one asset included in the MP table. For example, the field may indicate a stereoscopic 3D service, a multi-view service, a panorama service, or the like.

  The asset_role_flag field can indicate whether role information for the service component (asset) is included. The asset_target_flag field can indicate whether target screen information for the service component is included. The asset_group_flag field can indicate whether the service component belongs to a specific component group. When included in a specific component group, the value of this field may be 1. The rt_flag field may indicate whether the service component is transmitted in real time or non-real time. When the value of this field is 1, the service component may be transmitted in real time.

  The asset_role field can indicate the role of the service component. For example, when the value of this field is 0, 1, 2, 3, 4, 5, 6, or 7, the service component includes primary video, alternative camera view, other alternative video components, sign language, and follow subject video. (Follow subject video) 3D left image, 3D right image, 3D depth information, and the like can be shown.

  The asset_target field can indicate a target device targeted by the service component. It may be the same as the definition of @targetDevice described above. The asset_group_id field can provide an identifier of a component group that includes the service component. The component group is as described above.

  FIG. 21 is a diagram illustrating an asset group descriptor according to an embodiment of the present invention.

  The asset group descriptor can be described for a component group (asset group) when the service is transmitted via the MMT protocol. This descriptor may be transmitted via the same path as described above.

  The asset group descriptor may include an asset_group_id field that identifies the component group, a num_of_accessibility field that indicates the number of components (assets) included in the component group, and / or an asset_id () field that identifies each component.

  FIG. 22 is a diagram illustrating accessibility information according to an embodiment of the present invention.

  The proximity information may include information related to the proximity of the service or service component. The accessibility information may have one form of the descriptors according to the above-described embodiments, or may have an element form.

  In the illustrated embodiment (t25010), the accessibility information can be defined in the form of a descriptor. @SchemeIdUri may be a URI for identifying that the descriptor has an accessibility scheme related to the accessibility information. In this case, @schemIdId can have a value of urn: atsc3.0: accessibility: 201x. @Value can have a value whose meaning is defined according to the accessibility scheme. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (t25020) can indicate each parameter of @value described above. Visually implied may indicate whether the service component is a service component that targets a visually impaired or a viewer with low vision. “Healing impaired” may indicate whether the service component is a service component that targets a hearing impaired or a weakly hearing audience. Enhanced-audio-integrity may indicate whether the audio service component is an enhanced audio service component in terms of intelligibility. 3D supported may indicate whether the service component is a service component that supports 3D functions. Depending on the embodiment, it may be indicated whether the service component is a service component included in the 3D service. Normal can indicate whether the service component is a service component for a general audience (mainly for closed caption components). Easy reader can indicate whether the service component is a service component in the form of an easy reader (mainly for closed caption components). Easy reader may mean a closed caption in a form that is easy to read.

  Depending on the embodiment, the accessibility information may be defined in the form of an accessibility element having each parameter of @value described above as a subfield.

  In the illustrated embodiment (t25030), the accessibility information can be defined in the form of a descriptor. As described above, this descriptor may be transmitted by being included in the MMT signaling information. This descriptor may be transmitted by being included in the above-described MPT message or other MMTP message. This descriptor may be one type of asset descriptor.

  The num_of_accessibility field may indicate the number of subsequent accessibility codes (accessibility_code). The accessibility_code field may indicate proximity (proximity) related information. The accessibility related information may be expressed by an accessibility code. For example, if the accessibility code has the values 0x00, 0x01, 0x02, this can have the meaning of visual impair, hearing impair, 3D support, etc., respectively. The accessibility information is as described above. Values between 0x03 and 0xFF can be left for future use.

  FIG. 23 is a diagram illustrating a ComponentInfo element in USBD according to an embodiment of the present invention.

  In the illustrated embodiment (t26010), signaling is performed for each component of the 3D video. The first component is a video component (0x02, Video) indicating that it plays the role of 3D left video (@ componentRole = 3D video left view), and may have a component ID of 0x01. The second component is also a video component (0x02, Video), indicating that it plays the role of 3D right video (@ componentRole = 3D video right view), and can have a component ID of 0x02.

  The two service components are service components that form one 3D video and are related to each other, and thus can be grouped into the same component group. This component group can have an identifier of 0x01, the contents of which are each componentInfo. Can be signaled at the element. When the second component has a dependency on the first component, the @dependentComponentID of the second component has a value of 0x01, thereby indicating the component ID of the first component.

  In the illustrated example (t26020), follow-subject metadata on other components for a particular video component may be signaled. The first component is a video component and can signal that it plays the role of primary video. The second component may be a component that serves as follow subject metadata for the first component. This role can be signaled, and @dependentComponentID can indicate the component ID of the first component. In addition, as the related components, the first / second component may be included in the same component group (0x01).

  In the illustrated embodiment (t26030), one base video component and two enhanced video components are signaled. If one enhanced video has a dependency on the base video and the other enhanced video has a dependency on the first enhanced video, this relationship is signaled using the @dependentComponentID field as shown. Can be done. Also, where each video component can constitute the same scene, it can be included in the same component group.

  In the illustrated example (t26040), the role as a 3D component and the role in scalable coding for the two service components are signaled. These components can be included in the same component group where they can constitute the same scene.

  The first service component (ID = 0x01) is a base video component and can simultaneously serve as a right image of the 3D service. Two ComponentInfo elements can be described for the first service component. Each element can have the same service component ID (ID = 0x01).

  The second service component (ID = 0x02) is an enhanced video component and can serve as a left image of the 3D service. Similarly, two ComponentInfo elements can describe the second service component. These elements can have the same service component ID (ID = 0x02). Also, the second service component can have a dependency on the first component. @DependentComponentID can indicate the ID of the first service component.

  FIG. 24 is a diagram illustrating component attribute information according to an embodiment of the present invention.

  The component attribute information can include information related to the attribute of the service or service component. The component attribute information may have one form of the descriptors according to the above-described embodiments, or may have an element form.

  Component attribute information may also be referred to as view configuration information, depending on the embodiment. Depending on the embodiment, component attribute information may refer to view configuration information for a video component. Here, the component is a video component and may be part of a multiview. If the video component is part of a video array, the @role attribute of the view configuration information can indicate that the component is the <x, y> th video component of the <n, m> array.

  In the illustrated embodiment (t27010), component attribute information can be defined in the form of a descriptor. @SchemeIdUri may be a URI for identifying that the descriptor has a component attribute scheme related to the component attribute information. In this case, @schemIdId can have a value of urn: atsc3.0: view-conf: 201x. @Value can have a value whose meaning is defined according to the component attribute scheme. These values can be called parameters and can be distinguished by ',' respectively. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (t27020) can indicate each parameter of @value described above. View_x and / or View_y may indicate the video origin of the video component with reference to the upper left corner (left-top) of the screen. Each field can indicate the x and y coordinates of the origin of the video. View_width and / or View_height may indicate the width (width) and / or height (height) of the video of the video component. View_total_width and / or View_total_height may indicate the width and / or height of the entire area in which the video array is displayed with reference to the upper left corner (left-top) of the screen. View_display_priority can indicate the priority of the video of the video component. The priority order may be a priority order when the video is displayed. In the case where the images overlap, the higher the priority, the more images can be displayed before the other images. That is, it is possible to cover only the overlapping portions with other images. The smaller the value of this field, the higher the priority order. If the value is 0, it can be displayed on the screen the most forward. Source_id may be an identifier for the source of the video component. When a multi-view (video array) displayed at the same time is divided into a plurality of video components and transmitted, the source ID of each video component may be the same.

  Depending on the embodiment, the component attribute information may be defined in the form of a component attribute element having each parameter of @value described above as a subfield.

  In the illustrated embodiment (t27030), component attribute information can be defined in the form of a descriptor. As described above, this descriptor may be transmitted by being included in the MMT signaling information. This descriptor may be transmitted by being included in the above-described MPT message or other MMTP message. This descriptor may be one type of asset descriptor.

  view_x, view_y, view_width, view_height, total_width, total_height, source_id, and / or view_priority may be the same as described above. total_width, total_height, and view_priority may be the same as view_total_width, view_total_height, and view_display_priority, respectively.

  The source_id_flag can indicate whether or not the source_id exists. The view_total_info_flag field may indicate whether information regarding an area where a multi-view to be displayed at the same time is displayed is included. Depending on this field, total_width, total_height may exist. The view_priority_flag field can indicate whether or not priority information of the video of the video component is included. Depending on this field, view_priority may exist.

  FIG. 25 is a diagram illustrating component attribute information according to an embodiment of the present invention.

  The component attribute information can include information related to the attribute of the service or service component. The component attribute information may have one form of the descriptors according to the above-described embodiments, or may have an element form.

  Component attribute information may also be referred to as view position configuration information, depending on the embodiment. Depending on the embodiment, component attribute information may refer to view position configuration information for a video component. Here, the component is a video component and may be part of a stereoscopic 3D service.

  In the illustrated embodiment (d25010), component attribute information can be defined in the form of a descriptor. @SchemeIdUri may be a URI for identifying that the descriptor has a component attribute scheme related to the component attribute information. In this case, @schemIdUri can have a value of urn: atsc3.0: view-position-conf: 201x. @Value can have a value whose meaning is defined according to the component attribute scheme. These values can be called parameters and can be distinguished by ',' respectively. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (d25020) can indicate each parameter of @value described above. The right_view_flag field may indicate whether the video component is a right view or a left view. It has a value of 0 if the video component is the left viewpoint, and a value of 1 if it is the right viewpoint. When the left / right video components constituting the stereoscopic 3D service are transmitted separately, the view position configuration information for each video component is transmitted. May be signaled as d25040 using the component property element. Since each left / right viewpoint video component (left / right video component) constitutes one scene, it can have the same component group ID (componentGroupId) value.

  The component attribute information may be referred to as view position configuration information according to an embodiment. Depending on the embodiment, component attribute information may refer to view position configuration information for a video component. Here, the component is a video component and may be part of a multi-view service.

  In the illustrated embodiment (d25010), component attribute information can be defined in the form of a descriptor. @SchemeIdUri may be a URI for identifying that the descriptor has a component attribute scheme related to the component attribute information. In this case, @schemIdUri can have a value of urn: atsc3.0: view-position2-conf: 201x. @Value can have a value whose meaning is defined according to the component attribute scheme. These values can be called parameters and can be distinguished by ',' respectively. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (d25030) can indicate each parameter of @value described above. The viewpoint position information (view_position field) may mean view position information of the video component in the multi-view service. The viewpoint position information (view_position field) may be set to 0 for the first viewpoint located on the leftmost side of the multiview. In addition, the viewpoint position information may be set to a value that increases by 1 each time the first viewpoint moves to the next viewpoint from the left side to the right side. Here, the multiview may be a 3D multiview or a multiview for panorama. Here, in the case of 3D multi-view, the above-described view position information may include the meaning of the left viewpoint or the right viewpoint for each viewpoint. That is, from the view position information represented by numbers, the viewpoint (view) included in the component is the left viewpoint (left view) for providing the 3D service, or the right viewpoint (right view). Can be confirmed. When the video components corresponding to the respective viewpoints constituting the multi-view service are transmitted separately, the view position configuration (view position2 configuration) information for each video component is the component attribute information (component property). element) and can be signaled as d25040. Video components constituting one scene in the multi-view can have the same component group ID (componentGroupId) value. In addition, video components constituting other scenes may have different component group ID (componentGroupID) values.

  FIG. 26 is a diagram illustrating utilization of component property information according to an embodiment of the present invention.

  In the illustrated embodiment (t28010), one screen can be transmitted in two video components. In this case, the view configuration information for each video component may be signaled using the componentProperty element as described above. Since these constitute one scene, they can have the same componentGroupId value. The componentProperty element of the ComponentInfo element for each component can have the above-described view configuration information.

  Both have scheme IDs of urn: atsc3.0: view-conf: 201x, and @value is “1920, 0, 1920, 2160, 3840, 2160”, “0, 0, 1920, 2160, 3840, respectively”. 2160 ". The parameter of @value can have a meaning according to the definition of the parameter described above in order.

  In the illustrated example (t28020), a video component including a separate sign language can be transmitted along with a video component that provides one main video. In this case, the sign language video component can provide information on where the sign language image is displayed in the area where the main video is displayed. This information can be signaled in the form of the view configuration information described above.

  Similarly, in the case of PIP (Picture in Picture), view configuration information can be provided in the same manner as in the case of sign language. Here, in the case of a sign language video or a PIP video, since it must be displayed before the main video, it can have a higher priority than the main video. This component may be included in the same component group, and the sign language component or the PIP component may indicate that the @targetDevice attribute is “primary screen inset”.

  The view configuration information of the sign language component or PIP component has a scheme ID of urn: atsc3.0: view-conf: 201x, and @value has “1200, 50, 1024, 768, 3840, 2160, 0”. be able to. The parameter of @value can have a meaning according to the definition of the parameter described above in order.

  The capability information described above may also be signaled. The capability information may have one form of the descriptors according to the above-described embodiments, or may have an element form. Capability information may also define a capability scheme ID according to which capability value may be defined. Moreover, you may define in the form of the capability element which has each parameter of @value as a subfield. The capability information is defined in the form of a descriptor, and may be transmitted by being included in the MMT signaling information. This descriptor may be transmitted by being included in the above-described MPT message or other MMTP message. This descriptor may be one type of asset descriptor. The detailed fields, parameters, and structure of the capability information have already been described above.

  FIG. 27 is a diagram illustrating HEVC video component description information according to an embodiment of the present invention.

  The HEVC video component description information may include information related to the HEVC video of the service or service component. The HEVC video component description information can also be referred to as HEVC video information. The HEVC video information may include component-related encoding parameters, parameters for rendering the component, or the like. The HEVC video information may have one of the descriptors according to the above-described embodiments, or may have an element.

  In the illustrated embodiment (t29010), HEVC video information can be defined in the form of a descriptor. @SchemeIdUri may be a URI for identifying that the descriptor has a HEVC video scheme associated with HEVC video information. In this case, @schemIdId can have a value of urn: atsc3.0: hevc: 201x. @Value can have a value whose meaning is defined according to the HEVC video information scheme. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (t29020) can indicate each parameter of @value described above.

  The profile_space may be the same as the value of general_profile_space included in the SPS of the bitstream for the HEVC video stream. In the case of the HEVC temporal video subset or the HEVC temporal video sub-bitstream, it may be the same as the value of the sub_layer_profile_space included in the SPS of the bitstream.

  The tier_flag may be the same as the value of the general_tier_flag included in the SPS of the bitstream for the HEVC video stream. In the case of HEVC temporal video subset or HEVC temporal video sub-bitstream, it may be the same as the value of sub_layer_tier_flag included in the SPS of the bitstream.

  The profile_idc may be the same as the value of general_profile_idc included in the SPS of the bitstream for the HEVC video stream. In the case of HEVC temporal video subset or HEVC temporal video sub-bitstream, it may be the same as the value of sub_layer_profile_idc included in the SPS of the bitstream.

  The profile_compatibility_indication may be the same as the value of general_profile_compatibility_flag [i] included in the SPS of the bitstream for the HEVC video stream. In the case of HEVC temporal video subset or HEVC temporal video sub-bitstream, it may be the same as the value of sub_layer_profile_compatibility_flag [i] included in the SPS of the bitstream.

  progressive_source_flag may be the same as the value of general_progressive_source_flag included in the SPS of the bitstream for the HEVC video stream. In the case of HEVC temporal video subset or HEVC temporal video sub-bitstream, it may be the same as the value of sub_layer_progressive_source_flag included in the SPS of the bitstream.

  The interlaced_source_flag may be the same as the value of general_interlaced_source_flag included in the SPS of the bitstream for the HEVC video stream. In the case of HEVC temporal video subset or HEVC temporal video sub-bitstream, it may be the same as the value of sub_layer_interlaced_source_flag included in the SPS of the bitstream.

  The non_packed_constraint_flag may be the same as the value of general_non_packed_constraint_flag included in the SPS of the bitstream for the HEVC video stream. In the case of HEVC temporal video subset or HEVC temporal video sub-bitstream, it may be the same as the value of sub_layer_non_packed_constraint_flag included in the SPS of the bitstream.

  For the HEVC video stream, frame_only_constraint_flag may be the same as the value of general_frame_only_constraint_flag included in the SPS of the bitstream. In the case of HEVC temporal video subset or HEVC temporal video sub-bitstream, it may be the same as the value of sub_layer_frame_only_constraint_flag included in the SPS of the bitstream.

  reserved_zero_44 bits may be the same as the value of general_reserved_zero_44 bits included in the SPS of the bitstream for the HEVC video stream. In the case of HEVC temporal video subset or HEVC temporal video sub-bitstream, it may be the same as the value of sub_layer_reserved_zero_44 bits included in the SPS of the bitstream.

  level_idc may be the same as the value of general_level_idc included in the SPS of the bitstream for the HEVC video stream. In the case of HEVC temporal video subset or HEVC temporal video sub-bitstream, it may be the same as the value of sub_layer_level_idc included in the SPS of the bitstream.

  HEVC_still_present_flag may indicate whether the HEVC video stream or HEVC high temporal sub-layer representation can include HEVC still pictures.

  HEVC_24hr_picture_present_flag indicates whether the HEVC video stream or HEVC high temporal sub-layer representation can include HEVC24 hour pictures (24-hours).

  temporal_id_min and / or temporal_id_max may indicate the smallest temporalId value and / or the largest temporalId value of HEVC AUs included in the HEVC video stream.

  According to an embodiment, HEVC video information may be defined in the form of HEVC video information element having each parameter of @value described above as a subfield.

  In the illustrated embodiment (t29030), HEVC video information can be defined in the form of a descriptor. As described above, this descriptor may be transmitted by being included in the MMT signaling information. This descriptor may be transmitted by being included in the above-described MPT message or other MMTP message. This descriptor may be one type of asset descriptor. When the MMT asset is a HEVC video stream component, the value corresponding to the HEVC video stream can be assigned to the asset type of the MP table.

  profile_space, tier_flag, profile_idc, profile_compatibility_indication, progressive_source_flag, interlaced_source_flag, non_packed_constraint_flag, frame_only_constraint_flag, reserved_zero_44bits, level_idc, HEVC_still_present_flag, HEVC_24hr_picture_present_flag, may temporal_id_min and / or temporal_id_max is included in the descriptor, the meaning is as described above.

  FIG. 28 is a diagram illustrating HEVC timing & HRD information according to an embodiment of the present invention.

  The HEVC timing & HRD information may include timing information or an HRD description related to the HEVC video stream component. The HEVC timing & HRD information may have one of the descriptors according to the above-described embodiments, or may have an element. This may be indicated by the componentProperty element described above.

  In the illustrated embodiment, HEVC timing & HRD information can be defined in the form of a descriptor. @SchemeIdUri may be a URI for identifying that the descriptor has a scheme related to HEVC timing & HRD information. In this case, @schemaIdUri can have a value of urn: atsc3.0: hevc-timing: 201x. @Value can have a value whose meaning is defined according to the scheme. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (t30010) can indicate each parameter of @value described above. The hrd_management_valid_flag may indicate whether a buffering period SEI (Picture Period SEI) message and a picture timing SEI (Picture Timing SEI) message are present in the HEVC video stream or HEVC high temporal sub-layer representation. picture_and_timing_info_present_flag can indicate whether the descriptor includes 90 kHz_flag for accurate mapping with the 90 kHz system clock and its associated parameters. The 90 kHz_flag may indicate whether the time base frequency of the HEVC video stream is 90 kHz. N and / or K may provide N, K parameter values related to the time scale. In the HEVC video stream or HEVC high temporal sub-layer representation, the HEVC time base frequency may be defined by the vui_time_scale element of the VUI parameter. The relationship between HEVC time_scale and STC can be defined by N and K parameter values, and can be expressed as HEVC time_scale = (N x system_clock_frequency) / K. If 90 kHz_flag is 1, N may have a value of 1 and K may have a value of 300. If 90 kHz_flag is 0, N, K values may be provided by the N, K fields. The num_units_in_tick can be coded in the same manner as the vui_num_units_in_tick field of the VUI parameter, and the value of this field is applied to the entire HEVC video stream or HEVC high-temporal sub-layer representation related to the HEVC timing & HRD description information. it can.

  According to an embodiment, HEVC timing & HRD information may be defined in the form of HEVC timing & HRD information element having each parameter of @value described above as a subfield.

  In the illustrated embodiment (t30020), HEVC timing & HRD information can be defined in the form of a descriptor. As described above, this descriptor may be transmitted by being included in the MMT signaling information. This descriptor may be transmitted by being included in the above-described MPT message or other MMTP message. This descriptor may be one type of asset descriptor.

  hr_management_valid_flag, picture_and_timing_info_present_flag, 90 kHz_flag, N, K and / or num_units_in_tick may be included in the descriptor, and the meaning thereof is as described above.

  FIG. 29 is a diagram illustrating caption information according to an embodiment of the present invention.

  If the service component is a closed caption stream component, the caption information can include caption description information related to the service component. The caption information may have one form of the descriptors according to the above-described embodiments, or may have an element form. This may be indicated by the componentProperty element described above.

  In the illustrated embodiment, caption information can be defined in the form of a descriptor. @SchemeIdUri may be a URI for identifying that the descriptor has a caption scheme associated with the caption information. In this case, @schemIdId can have a value of urn: atsc3.0: caption: 201x. @Value can have a value whose meaning is defined according to the caption scheme. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (t31010) can indicate each parameter of @value described above. The caption_codec can indicate the encoding type of the caption component. Depending on the embodiment, “CEA-608”, “CEA-708”, “SMPTE-TT”, etc. may be indicated. The lang can include language information of the caption component. The caption_service_number may include the service number of the caption when the caption component type is CEA-708. easy_reader_flag can indicate whether or not the caption component is an easy reader type. The aspect_ratio may indicate a display aspect ratio of the caption component. Depending on the embodiment, “4: 3” or “16: 9” may be indicated. 3D supported may indicate whether the caption component supports 3D.

  Depending on the embodiment, the caption information may be defined in the form of a caption element having each parameter of @value described above as a subfield.

  In the illustrated embodiment (t31020), caption information can be defined in the form of a descriptor. As described above, this descriptor may be transmitted by being included in the MMT signaling information. This descriptor may be transmitted by being included in the above-described MPT message or other MMTP message. When the MMT asset is a closed caption component, the value corresponding to the closed caption stream can be assigned to the asset type of the MP table. According to the embodiment, the asset type of the MP table may include a descriptor illustrated as an asset descriptor while indicating a value corresponding to the HEVC video stream. In this case, it may be indicated that closed caption data is included in the HEVC video bitstream. This descriptor may be one type of asset descriptor.

  Caption_lang, caption_codec, easy_reader, wide_aspect_ratio, 3d_supported, and / or caption_service_number may be included in the descriptor, and the meaning thereof is as described above. The caption_lang, easy_reader, and wide_aspect_ratio may be the same as the above-mentioned lang, easy_reader_flag, and aspect_ratio, respectively. In the case of the caption_codec, if the values are 0x01, 0x02, 0x03, 0x04, 0x05, respectively, “CEA-608”, “CEA-708”, “SMPTE timed text”, “EBU-TT-D”, “CFF”, respectively. It can be shown that the encoding type “TT” was used. The url_flag, URL_length, and URL_text fields may be the same as those in the caption information described above.

  For example, when the closed caption component includes English subtitles based on SMPTE-TT, the descriptor has a scheme ID of “urn: atsc3.0: caption: 201x”, and @value is “SMPTE-TT, ENG”, respectively. , False, 4: 3, false ”. The parameter of @value can have a meaning according to the definition of the parameter described above in order.

  Further, when closed caption data is included in the bit stream of the HEVC video stream component based on CEA-708, the closed caption related information can be signaled together with the above-described HEVC video data related information by the above-described method. .

  FIG. 30 is a diagram illustrating HDR information according to an embodiment of the present invention.

  The HDR information may include HDR parameter information related to the service component if the service component is a video component. The HDR information may have one form of the descriptors according to the above-described embodiments, or may have an element form. This may be indicated by the above-described componentProperty element or ComponentDescription element.

  In the illustrated embodiment, HDR information can be defined in the form of descriptors. @SchemeIdUri may be a URI for identifying that the descriptor has an HDR scheme related to the HDR information. In this case, @schemIdId can have a value of urn: atsc3.0: hdr: 201x. @Value can have a value whose meaning is defined according to the HDR scheme. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (t32010) can indicate each parameter of @value described above. The OETF_type can indicate the type of the source OETF (opt-electronic transfer function) of the video data. When the value of this field is 1, 2, or 3, ITU-R BT. 1886, ITU-R BT. 709, ITU-R BT. It may correspond to the 2020 type. Other values can be left for future use.

  max_mastering_display_luminance may indicate a peak luminance value of a mastering display of the video data. This value may be an integer value between 100 and 1000. The min_mastering_display_luminance may indicate a minimum luminance value of the mastering display of the video data. This value may be a fractional value between 0 and 0.1.

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

  The hdr_type_transition_flag may be a flag indicating whether HDR information for the video data is changed and another type of HDR information is applied. For example, HDR parameters that were oeft: 3, max_lum: 100, min_lum: 0.5, max_frame_lum: 0, max_pixel_lum: 0 are oft: 1, max_lum: 1000, min_lum: 0.05, max_frame_lum: 0, max_pixel_lum: If changed to 0, etc., this field can have a true value. The hdr_sdr_transition_flag may be a flag indicating whether or not the video data is switched from HDR to SDR. The sdr_hdr_transition_flag may be a flag indicating whether or not the video data is switched from SDR to HDR. The sdr_compatibility_flag may be a flag indicating whether or not the video data is compatible with an SDR decoder or an SDR display.

  Depending on the embodiment, the HDR information may be defined in the form of an HDR element having each parameter of @value described above as a subfield.

  In the illustrated embodiment (t32020), the HDR information can be defined in the form of a descriptor. As described above, this descriptor may be transmitted by being included in the MMT signaling information. This descriptor may be transmitted by being included in the above-described MPT message or other MMTP message. This descriptor may be one type of asset descriptor. The descriptor may be transmitted by being included in DVB SI service signaling such as SDT or EIT, or may be transmitted together.

  OETF_type, max_mastering_display_luminance, min_mastering_display_luminance, average_frame_luminance_level, max_frame_pixel_luminance, hdr_type_transition_flag, hdr_sdr_transition_flag, may sdr_hdr_transition_flag and / or sdr_compatibility_flag is included in the descriptor, the meaning is the same as described above.

  Depending on the embodiment, one or more of the HDRTypeTransitionFlag, the HDRSDRTTransitionFlag, and the SDRHDRTransitionFlag may not be true at the same time. For example, when the value of HDRSDRTTransitionFlag is true, the values of HDRTypeTransitionFlag and SDRHDRTransitionFlag can be false.

  FIG. 31 is a diagram illustrating WCG information according to an embodiment of the present invention.

  If the service component is a video component, the WCG information may include WCG information related to the service component. The WCG information may have one form of the descriptors according to the above-described embodiments, or may have an element form. This may be indicated by the above-described componentProperty element or ComponentDescription element.

  WCG information can also be referred to as color gamut information. The color gamut information can take two forms, one being a container color gamut and the other being a content color gamut. The container color gamut may include color gamut related information used in the process of mapping the encoding, decoding step and / or decoded pixel value. The content color gamut may include information regarding the color gamut of the original source. That is, the content color gamut can indicate an effective color space volume applied to actual content.

  In the illustrated embodiment (t33010), the content WCG information can be defined in the form of a descriptor. @SchemeIdUri may be a URI for identifying that the descriptor has a content WCG scheme related to the content WCG information. In this case, @schemIdId can have a value of urn: atsc3.0: wcg: content: 201x. @Value can have a value whose meaning is defined according to the content WCG scheme. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (t33010) can indicate each parameter of @value described above.

  The contentColorGamutType can indicate the type of color gamut for the video data. That is, this field can indicate chromaticity coordinates of the source primaries. This value may be the same as the color primary value of VUI (video usability information). If the value of the VUI parameter does not exist, the color primary value of the VUI is not specified (unspecified), and the following eight parameters can have values.

  The contentColorPrimaryRx and the contentColorPrimaryRy can respectively indicate an x coordinate value and ay coordinate value for the R color of the video source. This may be in the form of a fractional number between 0 and 1. The contentColorPrimaryGx and the contentColorPrimaryGy can respectively indicate an x coordinate value and ay coordinate value for the G color of the video source. This may be in the form of a fractional number between 0 and 1. contentColorPrimaryBx and contentColorPrimaryBy can indicate an x-coordinate value and a y-coordinate value for the B color of the video source, respectively. This may be in the form of a fractional number between 0 and 1. The contentWhitePx and the contentWhitePy can respectively indicate an x coordinate value and a y coordinate value with respect to a white point (White point) of the video source. This may be in the form of a fractional number between 0 and 1.

  The content WCG Transition may be a flag indicating whether or not the content color gamut of the video data is switched from WCG (Wide Color Gamut) to SCG (Standard Color Gamut). An embodiment may indicate that the end of video data supporting WCG is included in the video component. The contentSCGCompatibility may be a flag indicating whether or not the content color gamut of the WCG video is compatible with an SCG-based decoder and display.

  In the illustrated embodiment (t33020), the container WCG information can be defined in the form of a descriptor. @SchemeIdUri may be a URI for identifying that the descriptor has a container WCG scheme related to the container WCG information. In this case, @schemIdId can have a value of urn: atsc3.0: wcg: container: 201x. @Value can have a value whose meaning is defined according to the container WCG scheme. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (t33020) can indicate each parameter of @value described above. This parameter may be the same as the parameter for the content color gamut described above. However, this parameter can be described for the container color gamut. For example, containerColorGamutType can indicate the container color gamut type of the video. That is, it is possible to indicate chromaticity coordinates for color primaries that are used during encoding or that can be used during decoding.

  containerColorPrimaryRx, containerColorPrimaryRy, containerColorPrimaryGx, containerColorPrimaryGy, containerColorPrimaryBx, containerColorPrimaryBy, containerWhitePx, containerWhitePy is, RGB color and the white point x of the respective encoding / decoding is used when coding / usable color primary (color primaries), to exhibit y-coordinate it can. That is, the coordinates of the color gamut of the container can be shown.

  The container WCG Transition may be a flag indicating whether or not the container color gamut of the video data is switched from WCG to SCG. An embodiment may indicate that the video component includes an end of video data that supports the WCG of the container. The containerSCGCompatibility may be a flag indicating whether the container color gamut of the WCG video is compatible with an SCG-based decoder and display.

  Depending on the embodiment, the content / container WCG information may be defined in the form of a content / container WCG element having each parameter of @value described above as a subfield.

  In the illustrated embodiment (t33030), content / container WCG information can be defined in the form of a descriptor. As described above, this descriptor may be transmitted by being included in the MMT signaling information. This descriptor may be transmitted by being included in the above-described MPT message or other MMTP message. If the MMT asset is a video stream component that includes content that supports WCG, a descriptor illustrated as an asset descriptor may be included. The descriptor may be transmitted by being included in DVB SI service signaling such as SDT or EIT, or may be transmitted together.

  This descriptor (t33030) can also include both content WCG information and container WCG information.

  The color_gamut_type may be the same as the containerColorGamutType described above. The color_space_transition_flag is a flag indicating whether or not the chromaticity coordinates for the color primaries used during encoding / decoding for the video samples of the video component are changed to other chromaticity coordinates. It may be. The wcg_scg_transition_flag may be a flag indicating whether or not the container color gamut of the video sample of the video component is switched from WCG to SCG. For example, BT. 2020 to BT. Reference numeral 709 denotes whether or not the container color gamut changes. The scg_wcg_transition_flag may be a flag indicating whether or not the container color gamut of the video sample of the video component is switched from SCG to WCG. The scg_compatibility_flag may be a flag indicating whether the container color gamut of the video sample of the video component is compatible with the SCG-based decoder and display. That is, when an existing SCG decoder or display is used, it is possible to confirm whether or not the WCG video can be output without quality problems without additional mapping information or upgrade. . Since this is information about the container color gamut, this field indicates that the SCG-based decoder / display is BT. Whether the video data can be decoded without knowing the color gamut such as 2020 can be shown. The color_primary_flag may be a flag indicating whether or not there is detailed information regarding chromaticity coordinates of color primaries that can be used when encoding / decoding the video sample of the video component. Depending on the value of the color_primary_flag, the color_primaryRx field, the color_primaryRy field, the color_primaryGx field, the color_primaryGy field, the color_primary field, the color_primWritable field, and the color_primWritable field. This field can indicate the color primaries RGB color and white point x and y coordinates used / available for encoding / decoding, respectively.

  The content_wcg_flag can indicate to the video component whether or not detailed information regarding the content color gamut is included in the descriptor. The content_color_gamut_type can indicate the content color gamut type of the video stream. That is, this field can indicate a chromaticity coordinate with respect to the original source primaries of the video data. The content_color_space_transition_flag may be a flag indicating whether or not these chromaticity coordinates are changed to other chromaticity coordinates with respect to the original source primaries of the video data of the video component. The content_wcg_scg_transition_flag may be a flag indicating whether or not the content color gamut of the video data of the video component is switched from WCG to SCG. The content_scg_wcg_transition_flag field may be a flag indicating whether or not the content color gamut of the video data of the video component is switched from SCG to WCG. The content_scg_compatibility_flag field may be a flag indicating whether the content color gamut of the video data of the video component is compatible with the SCG-based decoder and display. That is, when the value of this field is 1, it can be shown that the effective color expression range of the video data is compatible with SCG, and that separate mapping or the like is unnecessary. The content_color_primary_flag field may be a flag indicating whether or not there is detailed information related to chromaticity coordination of the original source primary of the video data of the video component. Depending on the value of content_color_primary_flag field Content_color_primaryRx field, Content_color_primaryRy field, Content_color_primaryGx field, Content_color_primaryGy field, Content_color_primaryBx field, Content_color_primaryBy field can include content_color_whitePx field and / or content_color_whitePy field. This field can indicate the RGB color of the original source primaries and the x and y coordinates of the white point, respectively.

  Depending on the embodiment, the color_gamut_type and / or content_color_gamut_type described above may have the following meanings.

  0: reserved / 1: Rec. ITU-R BT. 709-5, Rec. ITU-R BT. 1361 conventional color gamut system and extended color gamut system, IEC 61966-2-1 (sRGB or s Yc), IEC 61966-2-4, Society of Motion 17 for future use / 4: Rec. ITU-R BT. 470-6 System M (historical), United States National Television System Committee 1953 Recommendation for transmission standards for colour television, United States Federal Communications Commission Title 47 Code of Federal Regulations (2003) 73.682 (a) / 5: Rec. ITU-R BT. 470-6 System B, G (historical), Rec. ITU-R BT. 601-6 625, Rec. ITU-R BT. 1358 625, Rec. ITU-R BT. 1700 625 PAL and 625 SECAM / 6: Rec. ITU-R BT. 601-6 525, Rec. ITU-R BT. 1358 525, Rec. ITU-R BT. 1700 NTSC, Society of Motion Picture and Television Engineers 170M (2004) / 7: Society of Motion Picture and Television Engineers il il. ITU-R BT. 2020 / 10-255: Reserved for future use

  FIG. 32 is a diagram illustrating HFR information / Pull Down information according to an embodiment of the present invention.

  The HFR information may include HFR information associated with the video service component if the video service component supports HFR. The HFR information may have one form of the descriptors according to the above-described embodiments, or may have an element form. This may be indicated by the above-described componentProperty element or ComponentDescription element. As described above, the HFR information may be included in the MPD.

  In the illustrated embodiment (t34010), the HFR information can be defined in the form of a descriptor. @SchemeIdUri may be a URI for identifying that the descriptor has an HFR scheme related to the HFR information. In this case, @schemIdId can have a value of urn: atsc3.0: hfr: 201x. @Value can have a value whose meaning is defined according to the HFR scheme. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (t34010) can indicate each parameter of @value described above. SFRCompatibility can indicate whether the video component is compatible with an SFR (Standard Frame Rate) or a legacy frame rate. SFR_HFR_Transition may indicate whether the video component includes a transition from a general frame rate (SFR or legacy frame rate) to HFR. HFR_SFR_Transition may indicate whether the video component includes a transition from HFR to a general frame rate (SFR or legacy frame rate).

  The pull-down information may include pull-down recovery configuration (Pull Down Recovery Configuration) information for the service component. The pull-down information may have one form of the descriptors according to the above-described embodiments, or may have an element form. This may be indicated by the above-described componentProperty element or ComponentDescription element.

  The pull-down recovery configuration will be described. For example, if the original source is in film mode (eg, 24p), this can be changed to another frame rate for encoding (eg, 60i). In this case, dirty frames may occur. The dirty frame can be generated by the following method.

  All original film frames can be considered to consist of two fields. One may be for odd lines of the image and the other may be for even lines of the image. Thus, there can be 8 fields for every 4 film frames. Here, the four film frames can be referred to as A, B, C, and D, respectively. The 8 fields can be stretched to 10 fields. This may be done by repeating two fields (top, bottom).

  An A frame may be crossed over three fields (At, Ab, Ab), a B frame may be spanned over two fields (Bt, Bb), and a C frame may be spanned over three fields. (Ct, Ct, Cb), the D frame may span two fields (Dt, Db). These may be represented as At-Ab-Ab-Bt-Bb-Ct-Ct-Cb-Dt-Db, 3-2-3-2 pull-down, or simply 3-2 pull-down. Here, At may mean the top field of the A frame, and Bb may mean the bottom field of the B frame.

  In the case of “At-Ab-Ab-Bt-Bb-Ct-Ct-Cb-Dt-Db”, the Ab-Bt frame and the Bb-Ct frame can be called dirty frames. However, the receiver can know the original frame rate via a pull-down recovery configuration. The receiver can recover the original frame rate stream from the encoded / transmitted frame rate stream. Here, the recovery may be a process of removing the dirty frame.

  Pull-down may be a term used in connection with a post-production process for film or video transmission, such as in film making / TV production. The film frame rate may be switched to the broadcast frame rate by a broadcaster. However, the system level frame rate related information can include only broadcast frame rate information. Therefore, in order to recover the original frame rate, the system level signaling must be able to signal information related to the original frame rate. For example, original frame rate (eg, 24p) information and / or pull down type information (eg, 3: 2 pull down) may be included in the signaling information. Also, the video level information of the pulled-down video can request recovery to the original video.

  In the illustrated embodiment (t34020), the pull-down information can be defined in the form of a descriptor. @SchemeIdUri may be a URI for identifying that the descriptor has a pull-down scheme associated with the pull-down information. In this case, @schemeIdUri may have a value of urn: atsc3.0: pulldown: 201x. @Value can have a value whose meaning is defined according to the pull-down scheme. This value will be described later. @Id can indicate the identifier of the descriptor. If they have the same identifier, they can contain the same scheme ID, value, and parameters.

  The illustrated example (t34020) can indicate each parameter of @value described above. PullDownType can indicate the type of pull-down applied to the encoded video stream. It can be expressed as a decimal integer instead of a negative number. This field is 0-reserved, 1-2: 2 pull-down, 2-2: 3 pull down, 3-3: 2 pull-down, 4-4: 4 pull-down, 5 according to the value. -5: 5 pull-down, 6-6: 4 pull-down,...

  PullDownTransition can indicate whether the video component includes a transition from the pulled down data to the original frame rate. Depending on the embodiment, this field may indicate whether the end of the pulled down data is included in the video component.

  OriginalFrameRate can indicate the original frame rate (captured frame rate) of the video data. This field can be expressed as a decimal integer instead of a negative number. This information may be provided to recover from the encoding frame rate to the original frame rate. Depending on the value of this field, 0-reserved, 1-120, 2-120 / 1.001, 3-100, 4-60, 5-60 / 1.001, 6-50, 7-30, Original frame rates such as 8-30 / 1.001, 9-25, 10-24, 11-24 / 1.001, 12-14-reserved can be indicated.

  OriginalScanType can indicate the scanning type of the original video corresponding to the video. This field can be expressed as a decimal integer instead of a negative number. This field can indicate a type such as 0-reserved, 1-interlaced, 2-progressive, 3-unspecified depending on the value.

  Depending on the embodiment, the pull-down information may be defined in the form of a pull-down element having each parameter of @value described above as a subfield.

  In the illustrated embodiment (t34030), the HFR information & pull-down information can be defined in the form of a descriptor. As described above, this descriptor may be transmitted by being included in the MMT signaling information. This descriptor may be transmitted by being included in the above-described MPT message or other MMTP message. If the MMT asset is a video stream component that includes content that supports HFR, a descriptor illustrated as an asset descriptor may be included. The descriptor may be transmitted by being included in DVB SI service signaling such as SDT or EIT, or may be transmitted together.

  This descriptor (t34030) can also include both HFR information and pull-down information. sfr_compatibility_flag, sfr_hfr_transition_flag, hfr_sfr_transition_flag, pull_down_type, pull_down_transition_flag, original_framerate and / or original_scan_type, respectively, SFRCompatibility described above, SFR_HFR_Transition, HFR_SFR_Transition, PullDownType, PullDownTransition, OriginalFrameRate, may be the same as OriginalScanType. The original_frameate_flag can indicate whether or not the original_frameate field exists in the descriptor. The original_scene_type_flag can indicate whether or not the original_scene_type field exists in the descriptor.

  FIG. 33 shows 3D service and multiview service related signaling information according to an embodiment of the present invention. If the MMT asset is a video stream component for a stereoscopic 3D service, a view position descriptor (view_position_descriptor) d33010 can be included as an asset_descriptor in the MP_table. The view position descriptor (view_position_descriptor) can include stereoscopic 3D parameter information and the like. This may be included in other signaling tables of MMT or DVB SI (SDT or EIT). The view position descriptor can include at least one of the following fields: The descriptor_tag field may be an identifier for the view position descriptor (view_position_descriptor). The descriptor_length field can indicate the length of the view position descriptor (view_position_descriptor). The right_view_flag field can indicate whether the component of the video stream is a right view component. When the value of the field is 0, it indicates that the component of the video stream (video stream) is a left view component, and when the value of the field is 1, the right view (right view). It can indicate that it is a component.

  If the MMT asset is a video stream component for a multi-view service, a view position descriptor (view_position2_descriptor) d33020 can be included as an asset_descriptor in the MP_table. The view position descriptor (view_position2_descriptor) may include multiview parameter information and the like. The view position descriptor (view_position2_descriptor) also includes dependency information between components. This may be included in other signaling tables of MMT or DVB SI (SDT or EIT). The view position descriptor (view_position2_descriptor) may include at least one of the following fields. The descriptor_tag field may be an identifier for the view position descriptor (view_position2_descriptor). The descriptor_length field can indicate the length of the view position descriptor (view_position2_descriptor). The num_of_views field may mean the total number of views (views) included in the view position descriptor (view_position2_descriptor). That is, the total number of viewpoints provided in the multi-view service can be indicated. The view_position field may mean view position information of the video component in the case of multi-view. Here, the viewpoint position information may be set to 0 for the first viewpoint located on the leftmost side of the multiview. In addition, the viewpoint position information may be set to a value that increases by 1 each time the first viewpoint moves to the next viewpoint from the left side to the right side. (The view position means the order for the left-most view being equal to 0 and the value of the order increasing by 1 for next view from left to right.) Here, the multiview is a 3D multiview. ) Or panorama (multiview). Here, in the case of 3D multi-view, the above-described view position information may include the meaning of the left viewpoint or the right viewpoint for each viewpoint. That is, from the view position information represented by numbers, the viewpoint (view) included in the component is the left viewpoint (left view) for providing the 3D service, or the right viewpoint (right view). ).

  FIG. 34 is a diagram illustrating the operation of the media engine of the receiver based on the HDR information processing capability according to an embodiment of the present invention.

  A receiver parser (ISOBMFF parser) can parse ISOBMFF-based media files, DASH segments and / or MMT MPUs, and the like. Depending on the result of parsing, video samples can be transmitted to the video decoder, and HDR information (metadata) can be transmitted to the metadata parser.

  The video decoder can decode the video samples to obtain HDR video data. If there is HDR information acquired in this process, it can be transmitted to the metadata parser. When signaling messages such as DASH / MMT are received, the signaling processor can extract the HDR metadata from them and communicate it to the metadata parser. The metadata parser can parse the received HDR metadata. Using the metadata acquired here, control information necessary for the video decoder can be transmitted to the video decoder. The metadata parser can also serve as a buffer or metadata update. The update may be performed using set_number, version_number, or the like.

  The number of cases depends on whether the receiver is capable of HDR display. If display of HDR video is not possible, the HDR video data may be transferred to the SDR display block via HDR-SDR conversion. The SDR display block is a hardware block that can receive and play back the converted SDR video. At this time, information transmitted from the metadata parser may be used for the conversion.

  If the receiver is capable of HDR display, quality enhancement can be performed on the HDR video. At this time, it is possible to perform quality enhancement using common HDR information (Dynamic range, transfer function, color gauge, color temperature, DR / CG mapping, viewing condition, etc.) transmitted from the metadata parser.

  The number of cases depends on whether the receiver can process scene / frame-specific metadata. If the scene / frame metadata cannot be processed, the HDR display block of the receiver can play back the received HDR video data.

  If scene / frame metadata can be processed, scene-by-scene HDR video quality enhancement may be performed. At this time, quality enhancement can be performed by using scene / frame HDR metadata (White levels, Black levels, frame-by-frame, DR / CG mapping, etc.) transmitted from the metadata parser. In this case, the HDR display block of the receiver can play the enhanced HDR video data. The HDR display block may be a hardware block.

  The timing converter can transmit time-related information to a metadata parser, a synchronizer, and the like. The synchronizer can provide information necessary for the scene-specific HDR video quality enhancement operation using information such as sync_start and sync_duration.

  FIG. 35 is a diagram illustrating the operation of the media engine of the receiver based on the WCG information processing capability according to an embodiment of the present invention.

  A receiver parser (ISOBMFF parser) can parse ISOBMFF-based media files, DASH segments and / or MMT MPUs, and the like. Depending on the result of parsing, WCG video samples can be transmitted to the video decoder, and color gamut information (metadata) can be transmitted to the metadata parser.

  The video decoder can decode the video samples to obtain WCG video data. If there is color gamut related information acquired in this process, it can be transmitted to the metadata parser. When signaling messages such as DASH / MMT are received, the signaling processor can extract the color gamut metadata from them and communicate it to the metadata parser. The metadata parser can parse the received color gamut metadata. The container / content color gamut information acquired here can be used in the process of the receiver. The metadata parser can also serve as a buffer or metadata update. The update may be performed using set_number, version_number, or the like.

  The number of cases is divided depending on whether or not content color gamut information is included in the received data. If the content color gamut information is not included, the receiver can determine whether the display color gamut is greater than or the same as the container color gamut. If the display color gamut is larger or the same as the container color gamut, the receiver can provide a full WCG display. If the display color gamut is smaller than the container color gamut, the receiver can perform gamut mapping from the container color gamut to the display color gamut. The receiver can then provide an SCG display or a partial WCG display. In this process, common container color gamut related information transmitted from the metadata parser can be used.

  Conversely, if content color gamut information is included in the received data, the receiver can determine whether the display color gamut is greater than or the same as the content color gamut. If the display color gamut is greater than or the same as the content color gamut, the receiver can provide a full WCG display. If the display color gamut is smaller than the content color gamut, the receiver can perform gamut mapping from the content color gamut to the display color gamut. The receiver can then provide an SCG display or a partial WCG display. In this process, common content color gamut related information transmitted from the metadata parser can be used.

  FIG. 36 is a diagram illustrating the operation of the media engine of the receiver based on the HFR information processing capability according to an embodiment of the present invention.

  A receiver parser (ISOBMFF parser) can parse ISOBMFF-based media files, DASH segments and / or MMT MPUs, and the like. Depending on the result of parsing, HFR video data may be obtained.

  When DASH MPD or MMT based signaling messages are received, the signaling processor can extract HFR metadata from them and communicate to the metadata parser. The metadata parser can parse the received HFR metadata. The HFR information acquired here can be used in the process of the receiver. The metadata parser can also serve as a buffer or metadata update. The update may be performed using set_number, version_number, or the like.

  If HFR decoding / display can be performed on the HFR video data, the HFR video data can be communicated to the video decoder. The HFR video decoder can decode the video samples. At this time, if the HFR metadata is acquired, it can be transmitted to the metadata parser. The HFR video decoder transmits the decoded data to the HFR display, which can display it.

  When HFR decoding / display cannot be performed, compatibility with SFR can be confirmed. When SFRCompatibility has a value of 1, it is compatible and frame rate conversion can be performed. The converted data can be transmitted to an SFR or a legacy video decoder. In this process, HFR metadata can be received from the metadata parser and used. If HFR metadata is acquired during the video decoding process, it can be transmitted to the metadata parser. The video decoder can communicate this to the legacy display. This video data may be video data converted to the original frame rate. Legacy displays can display this.

  FIG. 37 is a diagram illustrating the operation of the media engine of the receiver based on the pull-down recovery information processing capability according to an embodiment of the present invention.

  A receiver parser (ISOBMFF parser) can parse ISOBMFF-based media files, DASH segments and / or MMT MPUs, and the like. Depending on the result of parsing, the video samples can be transmitted to the video decoder for decoding.

  When DASH MPD or MMT based signaling messages are received, the signaling processor can extract pull-down recovery related metadata from them and communicate it to the metadata parser. The metadata parser can parse the received pull-down recovery related metadata. The pull-down recovery related information acquired here can be used in the process of the receiver. The metadata parser can also serve as a buffer or metadata update. The update may be performed using set_number, version_number, or the like.

  The receiver can check the PullDownFlag to see if the decoded video is a pulled down video. If the receiver is a pulled down video, the receiver can recover the original FR stream using information such as the pulled down type. In this process, pull-down recovery related information of the metadata parser can be used. This is not the case if the video is not pulled down. The recovered source FR video or decoded video data can be transmitted to the display for display.

  FIG. 38 shows metadata for supporting a 3D service according to an embodiment of the present invention. According to one embodiment of the present invention, the video data may include a SEI message that includes metadata for supporting a 3D service. In the present invention, the compression format for the reference view video and the additional view video constituting the content supporting the 3D service may be HD or UHD. In connection with the screen ratio, the reference view video and the additional view video may have the same aspect ratio with respect to the active area. If the screen ratio of the left image and the right image constituting the 3D service is not exactly the same, the smaller input image is letterboxed or pillar boxed. obtain. Here, letterboxed may mean adjusting the screen ratio by positioning black bars or the like above and below the target image. Also, the pillar box may mean adjusting the screen ratio by positioning black bars or the like on the left and right of the target image. Such an operation can be performed before compression, and the two views can have the same screen ratio in the active area. In addition, the presence of embedded bars in the above-described image may be indicated by an active format descriptor (AFD). In addition, the presence of bars may be selectively indicated by bar data information (Bar Data information). In relation to the frame rate, the frame rate of the additional view video may be a value obtained by dividing the frame rate of the reference view video by an integer of 1 or more.

  The example (d38010) shown in the upper part of the figure can indicate a multiview view position SEI message. The SEI message may be transmitted together with the video data. The SEI message can indicate a left view and a right view of a stereoscopic video carried by SHVC (Scalable HEVC, Scalable High-efficiency Video Coding).

  A multiview view position SEI message may be identified by payload type information having a value of 180. As shown, the multiview view position SEI message may include a num_views_minus1 field and a view_position [i] information. The num_views_minus1 field can indicate the number of views included in the multi-view service. According to an embodiment, the num_views_minus1 field may indicate a number that is 1 less than the number of views included in the multi-view service. The multiview view position SEI message may include view_position [i] information for each view. For a fixed & mobile hybrid 3D service, the view_position [i] information in the SEI message can indicate the order of views having the same dependency ID (DependencyId) as i. Such a view may be one of the views that follow a left-to-right order for the display. Here, the view order may mean a value in which the leftmost view is 0, and then increases by 1 as the view is moved one by one to the right. For example, when the base layer video is a right view and the enhancement layer video is a left view, view_position [0] may be 1 and view_position [1] may be 0. That is, since the enhancement layer video having dependency ID 1 is the left viewpoint, the view position information of the enhancement layer video can be set to zero. Also, since the base layer video having dependency ID 0 is the right viewpoint, the view position information of the base layer video can be set to 1.

  The example (d38020) shown in the lower part of the figure may indicate a multiview scene position SEI message. The SEI message may be transmitted together with the video data. The SEI message may include min_disparity information and / or max_disparity_range information. A multiview scene position SEI message may be identified by payload type information. A multiview scene position SEI message may be used to process the decoded views prior to rendering the image on a 3D display. The minimum binocular disparity may indicate a three-dimensional position (location) of an object (front-most object) positioned in the forefront in the video. In order to render a receiver-generated graphic such as OSD (on-screen display) ahead of the decoded views, the minimum binocular disparity is:

  It can be included in a multiview scene position SEI message. That is, the receiver uses the minimum binocular disparity information included in the multiview scene position SEI message among the SEI messages in the video data, and the position where the video data is displayed. The graphic information generated by the receiver can be displayed ahead of the display. In the embodiment described above, each SEI message may further include a dependency ID.

  FIG. 39 may show metadata related to a bar according to an embodiment of the present invention. Information on the bar may be transmitted as an SEI message in the video data. Information on the bar may be transmitted as a separate table or descriptor included in DVB SI service signaling such as SDT or EIT, or may be transmitted together. The information about the bar may include at least one of the following information. The top_bar_flag field may indicate whether or not a bar exists above the displayed screen. The bottom_bar_flag field can indicate whether a bar exists below the displayed screen. The left_bar_flag field can indicate whether a bar exists on the left side of the screen to be displayed. The right_bar_flag field can indicate whether a bar exists on the right side of the displayed screen. When the top_bar_flag field is set to 1, that is, when a bar exists on the upper side of the screen, the marker_bits field and the line_number_end_of_top_bar field may be included in the metadata regarding the bar. The line_number_end_of_top_bar field may define the last line number of the top bar. That is, the upper bar may have a size from the upper end of the screen to a line defined by the line_number_end_of_top_bar field. If the bottom_bar_flag field is set to 1, that is, if there is a bar at the bottom of the screen, the marker_bits field and the line_number_start_of_bottom_bar field may be included in the metadata regarding the bar. The line_number_start_of_bottom_bar field may define the starting line number (line number) of the bottom bar. That is, the lower bar may have a size from a line defined by the line_number_start_of_bottom_bar field to the lower end of the screen. If the left_bar_flag field is set to 1, that is, if a bar exists on the left side of the screen, the marker_bits field and the pixel_number_end_of_left_bar field may be included in the metadata regarding the bar. The pixel_number_end_of_left_bar field may define the last pixel number of the left bar. That is, the left bar can have a size from the left edge of the screen to the pixel defined by the pixel_number_end_of_left_bar field. When the right_bar_flag field is set to 1, that is, when a bar exists on the right side of the screen, the marker_numbers field and the pixel_number_start_of_right_bar field may be included in the metadata regarding the bar. The pixel_number_start_of_right_bar field may define the starting pixel number of the right bar. That is, the right bar can have a size from the pixel defined by the pixel_number_start_of_right_bar field to the right edge of the screen. In addition, additional_bar_data may be further included. Using the above-described fields, the information regarding the bar can describe the size of the bar displayed on the screen. That is, the size of the letterbox bar can be indicated by the line_number_end_of_top_bar field and the line_number_start_of_bottom_bar field, as described above. In addition, the size of the pillar box bar can be indicated by the pixel_number_end_of_left_bar field and the pixel_number_start_of_right_bar field, as described above. However, such a field is created based on an original source format. That is, since the line and pixel values are based on the format at the time of production of the video content, the meanings of the values may differ depending on the reception status. That is, the video format transmitted at the transmission end or the video format encoded at the transmission end may be different from the original source format. An example of this is when the video content is resized for transmission. In such a case, the interpretation of the information about the bar at the receiving end can be ambiguous. This is because the information about the bar is a value based on the original source format, while the content has a changed format.

  FIG. 40 may show metadata regarding an original source format according to an embodiment of the present invention. Information regarding the original source format may be transmitted as an SEI message in the video data. Information on the original source format may be transmitted as a separate table or descriptor included in DVB SI service signaling such as SDT or EIT, or may be transmitted together. The information regarding the original source format can include at least one of the following information. The identity_format_flag field may indicate whether the compression format and the production format are the same. It may be signaled as 1 when the compression format and the production format are the same, and as 0 when they are different. Here, the production format may mean an original source format. The org_spatial_resolution field can signal the actual spatial resolution captured at the production end. For example, the resolution by each field value is as follows. 0x0: unspecified; 0x1: 3840x2160; 0x2: 2160x1440; 0x3: 1920x1080; 0x4: 1280x720; 0x5: 960x540; 0x6: 640x360; 0x7: customized.

  The org_frame_rate field may be used to signal an actual frame rate captured at the production end. For example, the frame rate by each field value is as follows. 0x0: reserved; 0x1 = 23.976 Hz, 0x2 = 24 Hz, 0x3 = 29.97 Hz, 0x4 = 30 Hz, 0x5 = 59.94 Hz, 0x6 = 60 Hz, 0x7 = 25 Hz, 0x08 = 50 Hz, 0x09 = 100 Hz, 0x0A = 120 / 1.001 Hz, 0x0B = 120 Hz.

  The scanning_format field can signal whether the scanning format is interlaced or progressive. For example, the scanning format for each field value is as follows. 00: unspecified, 01: progressive, 10: interlaced, 11: reserved.

  The org_horizontal_size_div_8 field and the org_vertical_size_div_8 field may not have a pre-defined format in a pre-defined format in the actual spatial resolution captured at the production end. That is, it does not signal a preset value, but indicates the value of the horizontal and vertical resolution of the actual production format. The actual horizontal and vertical resolution may be a value obtained by multiplying each field value by 8. As described above, the information on the original source format can be used as information that can reflect the original intent of the original author.

  FIG. 41 illustrates a method for generating a letterbox using bar data according to an embodiment of the present invention. In the first case, the emission format sent out by the broadcasting system is the same as the production format. For example, the emission format, ie the resolution of the encoded video, may be 3840 * 2160. Also, the production format, that is, the resolution of the original source video may be 3840 * 2160. In this case, the dental_format_flag field included in the information on the original source format described above may be set to 1. Further, in the bar information (bar_data) d41010, the top_bar_flag field and the bottom_bar_flag field are set to 1 to indicate that a letter box using the upper bar (top bar) and the lower bar (bottom bar) is generated. Can do. In the bar information (bar_data) d41010, the line_number_end_of_top_bar field may have an A value, and the line_number_start_of_bottom_bar field may have a B value. In this case, as shown at d41020, the upper bar may have a vertical size of A + 1. Here, the horizontal size of the upper bar may be the same as the horizontal size of the production format. Also, the lower bar can have a vertical size of V-B. Here, V can indicate the vertical size of the production format. That is, since the production format is 3840 * 2160, V can have a value of 2160 and the lower bar can have a vertical size of 2160-B. Here, the horizontal size of the lower bar may be the same as the horizontal size of the emission format or the production format. Thus, when the production format and the emission format are the same, the broadcast receiving apparatus can generate the letter box by calculating the size of the letter box by directly applying the information included in the bar_data to the emission format. An area excluding the letterbox generated on the display of the broadcast receiving apparatus may be an active image area.

  FIG. 42 illustrates a method for generating a letterbox using bar data according to another embodiment of the present invention. This figure can explain the case where the emission format transmitted by the broadcasting system is different from the production format. The second case is a case where the emission format sent out by the broadcasting system is smaller than the production format (d42010). For example, the emission format, ie the resolution of the encoded video, may be 1920 * 1080. Also, the production format, that is, the resolution of the original source video may be 3840 * 2160, which is larger than this. In this case, the identity_format_flag field included in the information on the original source format described above may be set to 0. In the information about the bar, the top_bar_flag field and the bottom_bar_flag field may be set to 1 to indicate that a letterbox using the upper bar and the bottom bar is generated. In the information about the bar, the line_number_end_of_top_bar field may have an A value, and the line_number_start_of_bottom_bar field may have a B value. In this case, as shown at d42010, the upper bar may have a vertical size of (A + 1) / R. Here, R is the ratio between the emission format and the production format. In an embodiment, the value of R may be 2 because the production format (3840 * 2160) has twice the size of the emission format (1920 * 1080). Depending on the embodiment, R may mean a value obtained by dividing V, which is the vertical size of the production format, by the vertical size of the emission format. In this case, the value of R is 2. Here, the horizontal size of the upper bar may be the same as the horizontal size of the emission format. Also, the lower bar can have a vertical size of (V−B) / R. Here, V can indicate the vertical size of the production format. That is, since the production format is 3840 * 2160, V can have a value of 2160 and the lower bar can have a vertical size of (2160-B) / 2. Here, the horizontal size of the lower bar may be the same as the horizontal size of the emission format. As described above, when the production format is larger than the emission format, the broadcast receiving apparatus applies the information included in the bar_data to the production format, and scales it according to the ratio between the production format and the emission format, and the size of the bar. Can be determined and a bar can be generated. That is, the broadcast receiving apparatus can check the size of the bar in the emission format using the information about the original source format received together with the information about the bar, and generate the letter box through scaling. An area excluding the letterbox generated on the display of the broadcast receiving apparatus may be an active image area.

  As a third case, the emission format transmitted by the broadcasting system is larger than the production format (d42020). For example, the emission format, ie the resolution of the encoded video, may be 1920 * 1080. Also, the production format, that is, the resolution of the original source video, may be smaller than this, 1280 * 720. In this case, the identity_format_flag field included in the information on the original source format described above may be set to 0. In the information about the bar, the top_bar_flag field and the bottom_bar_flag field may be set to 1 to indicate that a letterbox using the upper bar and the bottom bar is generated. In the information about the bar, the line_number_end_of_top_bar field may have an A value, and the line_number_start_of_bottom_bar field may have a B value. In this case, as shown at d42020, the upper bar may have a vertical size of (A + 1) * F. Here, F is the ratio between the emission format and the production format. In an embodiment, the emission format (1920 * 1080) has a size 1.5 times that of the production format (1280 * 720), so the value of F may be 1.5. Depending on the embodiment, F may mean a value obtained by dividing the vertical size of the emission format by V, which is the vertical size of the production format. In this case, the value of F is 1.5. Here, the horizontal size of the upper bar may be the same as the horizontal size of the emission format. Also, the lower bar can have a vertical size of (V−B) * F. Here, V can indicate the vertical size of the production format. That is, since the production format is 1280 * 720, V can have a value of 720 and the lower bar can have a vertical size of (720-B) * 1.5. Here, the horizontal size of the lower bar may be the same as the horizontal size of the emission format. As described above, when the production format is smaller than the emission format, the broadcast receiving apparatus applies the information included in the bar_data to the production format, and scales it according to the ratio between the production format and the emission format, thereby obtaining the bar size. Can be determined and a bar can be generated. That is, the broadcast receiving apparatus can check the size of the bar in the emission format using the information about the original source format received together with the information about the bar, and generate the letter box through scaling. An area excluding the letterbox generated on the display of the broadcast receiving apparatus may be an active image area.

  FIG. 43 illustrates a method for generating a pillar box using bar data according to an embodiment of the present invention. In the first case, the emission format sent out by the broadcasting system is the same as the production format. For example, the emission format, ie the resolution of the encoded video, may be 3840 * 2160. Also, the production format, that is, the resolution of the original source video may be 3840 * 2160. In this case, the dental_format_flag field included in the information on the original source format described above may be set to 1. Also, in the bar information (bar_data) d43010, the left_bar_flag field and the right_bar_flag field are set to 1, indicating that a pillar box using the left bar and the right bar is generated. it can. In the bar information (bar_data) d43010, the pixel_number_end_of_left_bar field may have a C value, and the pixel_number_start_of_right_bar field may have a D value. In this case, the left bar can have a horizontal size of C + 1, as shown at d43020. Here, the vertical size of the left bar may be the same as the vertical size of the production format. Also, the right bar can have a horizontal size of HD. Here, H can indicate the horizontal size of the production format. That is, since the production format is 3840 * 2160, H can have a value of 2160 and the right bar can have a horizontal size of 2160-D. Here, the vertical size of the right bar may be the same as the vertical size of the emission format or the production format. As described above, when the production format and the emission format are the same, the broadcast receiving apparatus can generate the pillar box by calculating the size of the pillar box by directly applying the information included in bar_data to the emission format. An area excluding the pillar box generated on the display of the broadcast receiving apparatus may be an active image area.

  FIG. 44 illustrates a method for generating a pillar box using bar data according to another embodiment of the present invention. This figure can explain the case where the emission format transmitted by the broadcasting system is different from the production format. The second case is a case where the emission format sent out by the broadcasting system is smaller than the production format (d44010). For example, the emission format, ie the resolution of the encoded video, may be 1920 * 1080. Also, the production format, that is, the resolution of the original source video may be 3840 * 2160, which is larger than this. In this case, the identity_format_flag field included in the information on the original source format described above may be set to 0. Also, in the bar information (bar_data) d43010, the left_bar_flag field and the right_bar_flag field are set to 1, indicating that a pillar box using the left bar and the right bar is generated. it can. In the bar information (bar_data) d43010, the pixel_number_end_of_left_bar field may have a C value, and the pixel_number_start_of_right_bar field may have a D value. In this case, as shown at d44010, the left bar can have a horizontal size of (C + 1) / R. Here, R is the ratio between the emission format and the production format. In an embodiment, the value of R may be 2 because the production format (3840 * 2160) has twice the size of the emission format (1920 * 1080). Depending on the embodiment, R may mean a value obtained by dividing H, which is the horizontal size of the production format, by the horizontal size of the emission format. In this case, the value of R is 2. Here, the vertical size of the left bar may be the same as the vertical size of the emission format. Also, the right bar can have a horizontal size of (HD) / R. Here, H can indicate the horizontal size of the production format. That is, since the production format is 3840 * 2160, H can have a value of 3840 and the right bar can have a horizontal size of (3840-D) / 2. Here, the vertical size of the right bar may be the same as the vertical size of the emission format. As described above, when the production format is larger than the emission format, the broadcast receiving apparatus applies the information included in the bar_data to the production format, and scales it according to the ratio between the production format and the emission format, and the size of the bar. Can be determined and a bar can be generated. That is, the broadcast receiving apparatus can check the size of the bar in the emission format by using the information about the original source format received together with the information about the bar, and generate a pillar box through scaling. An area excluding the pillar box generated on the display of the broadcast receiving apparatus may be an active image area.

  As a third case, the emission format transmitted by the broadcasting system is larger than the production format (d44020). For example, the emission format, ie the resolution of the encoded video, may be 1920 * 1080. Also, the production format, that is, the resolution of the original source video, may be smaller than this, 1280 * 720. In this case, the identity_format_flag field included in the information on the original source format described above may be set to 0. In the information about the bar, the left_bar_flag field and the right_bar_flag field may be set to 1 to indicate that a pillar box using the left bar and the right bar is generated. In the information about the bar, the pixel_number_end_of_left_bar field may have a C value, and the pixel_number_start_of_right_bar field may have a D value. In this case, the left bar can have a horizontal size of (C + 1) * F, as shown at d44020. Here, F is the ratio between the emission format and the production format. In an embodiment, the emission format (1920 * 1080) has a size 1.5 times that of the production format (1280 * 720), so the value of F may be 1.5. Depending on the embodiment, F may mean a value obtained by dividing the vertical size of the emission format by the vertical size of the production format. In this case, the value of F is 1.5. Here, the vertical size of the left bar may be the same as the vertical size of the emission format. Also, the right bar can have a horizontal size of (HD) * F. Here, H can indicate the horizontal size of the production format. That is, because the production format is 1280 * 720, H can have a value of 1280, and the right bar can have a horizontal size of (1280-D) * 1.5. Here, the vertical size of the right bar may be the same as the vertical size of the emission format. As described above, when the production format is smaller than the emission format, the broadcast receiving apparatus applies the information included in the bar_data to the production format, and scales it according to the ratio between the production format and the emission format, thereby obtaining the bar size. Can be determined and a bar can be generated. That is, the broadcast receiving apparatus can check the size of the bar in the emission format by using the information about the original source format received together with the information about the bar, and generate a pillar box through scaling. An area excluding the pillar box generated on the display of the broadcast receiving apparatus may be an active image area.

  FIG. 45 is a diagram illustrating a method for transmitting a broadcast signal according to an embodiment of the present invention.

  A method for transmitting a broadcast signal according to an embodiment of the present invention includes a service data and service signaling information generation step (ds45010), a service list table generation step (ds45020), and an IP (Internet Protocol) packet processing. Step (ds45030) and / or generating a broadcast signal and transmitting it via a broadcast network (ds45040) may be included.

  First, the service data generation unit (d46010) on the transmission side can generate service data for broadcast service and / or service signaling information for signaling the broadcast service. Here, the service data may be a concept that summarizes media data, NRT data, streaming data, and the like included in the broadcast service. The service data can include service components of the service. Here, the service signaling information may correspond to the SLS described above. The service data generation unit is a block that generates data related to an actual service in order to provide a service on the service provider side, and may be a hardware element.

  The lower-level signaling generation unit (d46020) on the transmission side can generate a service list table. The service list table may correspond to the SLT described above. As described above, the service list table may include bootstrap information that identifies a transmission session in which service signaling information is transmitted. Here, the bootstrap information is as described above. The transmission session may be an MMTP session and / or a ROUTE session, depending on the embodiment. The lower level signaling generation unit is a block that supervises generation of LLS (Low Level Signaling) such as SLT, and may be a hardware element.

  The transmission layer processing unit (d46030) on the transmission side can process the generated service component, service signaling information and / or service list table as an IP packet. Prior to this, the data can be processed by UDP. The transmission layer processing unit is a block in charge of processing higher layer data for transmission, and may be a hardware element.

  The physical layer processing unit (d46040) on the transmission side can process the generated IP packet to generate a broadcast signal, and transmit the broadcast signal via the broadcast network. In this process, other operations are first performed on the link layer described above, and higher layer data (such as IP packets) can be encapsulated in link layer packets. Thereafter, the link layer packet may be processed as a broadcast signal through a process such as encoding / interleaving according to an operation defined in the physical layer. The generated broadcast signal may be transmitted via a broadcast network or the like. Depending on the embodiment, the data described above may be transmitted by broadband. The physical layer processing unit is a block responsible for the link layer and / or the physical layer described above, and may be a hardware element.

  In the method for transmitting a broadcast signal according to another embodiment of the present invention, the service signaling information may include USBD. As described above, USBD can operate as a signaling hub that describes technical information related to broadcast services. The USBD may further include service type information. Here, the service type information may mean a type of a final service provided by combining components described in USBD. The service type information may be stereoscopic 3D (Stereoscopic 3D), multi-view (Multiview), or the like.

  In the method of transmitting a broadcast signal according to still another embodiment of the present invention, the service list table or the USBD may further include capability information. This may mean various capability information included in the above-described SLT or USBD. The capability information can describe at least one or more capabilities required to significantly present the broadcast service. Here, capability information may be described using a predefined capability code. Depending on the embodiment, the capability information may be described by a capability category code indicating a category of the capability. Depending on the embodiment, the capability information may be described by combining a capability category code and a capability code that specifically indicates what capability information is meant in the category. The capability information is as described above.

  In the method for transmitting a broadcast signal according to another embodiment of the present invention, when the service signaling information of the broadcast service is conveyed by the MMT protocol, the service signaling information further includes a signaling message including caption information for the broadcast service. be able to. As described above, when SLS is transmitted according to MMTP, signaling information may be transmitted via an MMTP message. Depending on the embodiment, various information (multiview, caption, 3D, WCG, HDR, etc.) may be conveyed in the MPT message or other newly defined MMTP messages. Depending on the embodiment, a single MMTP message may include a plurality of pieces of information at the same time. Also, the MPT message or other newly defined MMTP message may further include service type information. Here, the service type information may mean a type of a final service provided by combining an asset described by an MPT message or another newly defined MMTP message. The service type information may be stereoscopic 3D (Stereoscopic 3D), multi-view (Multiview), or the like.

  The caption information includes language information indicating the caption language of the broadcasting service, role information indicating the role of the caption, aspect ratio information indicating the aspect ratio of the caption, and the caption is an easy reader caption. Easy reader information indicating whether or not, and / or 3D support information indicating whether or not the caption supports 3D (3-Dimensional). The caption information is as described above. As described above, the multi-view information may be included in the MPD.

  In the method for transmitting a broadcast signal according to still another embodiment of the present invention, the signaling message may further include 3D related information for a service component of a broadcast service. Here, the signaling message may mean one of MMTP messages. The 3D related information may include minimum parallax information between the video of the service component and an adjacent video of the video, and / or maximum parallax information between the video and the adjacent video. . The 3D information is as described above. According to an embodiment, the 3D related information may further include view position information indicating an order of the video (view) of the service component. Depending on the embodiment, the view position information may be conveyed via other MMTP messages or MPDs.

  The view position information transmitted via the MPD may include right view information for each component in association with the 3D service. This can indicate whether the component is a right view or a left view. Further, the view position information transmitted via the MPD may include the view position information of each component in association with the multi-view service. Here, the multi-view service may mean 3D multi-view or panoramic multi-view. In the case of 3D multi-view, the view position information can indicate the left viewpoint or the right viewpoint.

  If the MMT asset is a video stream component for a stereoscopic 3D service, a view position descriptor can be included as asset_descriptor in the MP table. The view position information communicated through the view position descriptor may include right view information for each component in association with the 3D service. This can indicate whether the component is a right view or a left view. Further, the view position information transmitted via the MPD may include the view position information of each component in association with the multi-view service. Here, the multi-view service may mean 3D multi-view or panoramic multi-view. In the case of 3D multi-view, the view position information can indicate the left viewpoint or the right viewpoint.

  In a method for transmitting a broadcast signal according to still another embodiment of the present invention, the USBD may include component information related to a service component of a broadcast service. The component information is as described above. The component information may include component type information indicating the type of the service component and / or component role information indicating the role of the service component according to the type of the service component. Each piece of information may correspond to the above-mentioned @componentType attribute and / or @componentRole attribute. The component role information can indicate whether the audio or video component of the broadcast service is a service component for a hearing or visually impaired person. In other words, this information can indicate whether or not the component is a component for sharing implied / visually implied.

  In a method for transmitting a broadcast signal according to still another embodiment of the present invention, when service signaling information of a broadcast service is transmitted using a ROUTE protocol, the USBD may further include information referring to the MPD. As described above, the MPD may include a resource identifier and / or resource context information for service data of a broadcast service. As described above, this MPD may include various previously described information for components. Depending on the embodiment, the MPD may further include caption information and / or 3D related information for the broadcast service.

  A method for receiving a broadcast signal according to an embodiment of the present invention will be described. This method is not shown.

  In the method of receiving a broadcast signal according to an embodiment of the present invention, a receiving-side physical layer processing unit processes a broadcast signal and obtains an IP packet therefrom, a lower level signaling processing unit obtains an SLT, and Obtaining bootstrap information; identifying a transmission session transmitting SLS using the bootstrap information; obtaining a SLS by approaching the transmission session; obtaining a service component of a broadcast service using the SLS And / or providing a broadcast service using the service component from which the display unit is acquired. Depending on the embodiment, information such as the above-described caption, 3D, HDR, WCG, and multi-view may be acquired from SLT and / or SLS information. Depending on which MMTP or ROUTE protocol is used, this information can be obtained from the SLS MPD or the SLS MMTP message. The physical layer processing unit, the lower level signaling processing unit, and / or the display unit on the receiving side may be hardware elements.

  The method for receiving a broadcast signal according to the embodiment of the present invention can correspond to the above-described method for transmitting a broadcast signal according to the embodiment of the present invention. A method for receiving a broadcast signal is a hardware module corresponding to a module (for example, a service data generation unit, a transmission layer processing unit, a lower level signaling generation unit, a physical layer processing unit, etc.) used in a method for transmitting a broadcast signal. Can be done by. A method for receiving a broadcast signal may have an embodiment corresponding to the embodiment of the method for transmitting a broadcast signal described above.

  The above-described steps may be omitted depending on the embodiment, and may be replaced by other steps that perform similar / identical operations.

  FIG. 46 is a diagram illustrating 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 may include the above-described service data generation unit, transmission layer processing unit, lower level signaling generation unit, and / or physical layer processing unit. Each block and module is as described above.

  An apparatus for transmitting a broadcast signal and an internal module / block thereof according to an embodiment of the present invention may implement the above-described method for transmitting a broadcast signal of the present invention.

  An apparatus for receiving a broadcast signal according to an embodiment of the present invention will be described. This device is not shown.

  An apparatus for receiving a broadcast signal according to an embodiment of the present invention may include the above-described physical layer processing unit, lower level signaling processing unit, and / or display unit. Each block and module is as described above.

  An apparatus for receiving a broadcast signal and an internal module / block thereof according to an embodiment of the present invention may implement the above-described method for receiving a broadcast signal of the present invention.

  The above-described internal blocks / modules of the device may be a processor that executes a continuous process stored in a memory, or may be a hardware element located inside / outside of the device according to an embodiment. .

  The above-described modules may be omitted depending on the embodiment, and may be replaced by other modules performing similar / same operations.

  The module or unit may be a processor that executes a continuous process stored in a memory (or storage unit). Each step described in the above embodiments may be performed by a hardware / processor. Each module / block / unit described in the above-described embodiments can operate as hardware / processor. Also, the method presented by the present invention may be executed as code. This code may be written on a processor readable storage medium and thus read by a processor provided by the apparatus.

  For convenience of explanation, the drawings have been described separately. However, the embodiments disclosed in the drawings may be combined to be designed to embody a new embodiment. It is also within the scope of the present invention to design a computer-readable recording medium in which a program for executing the embodiment described above is recorded according to the needs of a normal engineer.

  As described above, the apparatus and method according to the present invention are not limited to the configurations and methods of the described embodiments, and each of the above-described embodiments can be modified in various ways. All or part of the embodiments may be selectively combined.

  On the other hand, the method proposed by the present invention can be embodied as a processor-readable code on a processor-readable recording medium provided in a network device. The recording medium readable by the processor includes any kind of recording device in which data readable by the processor is stored. Examples of recording media that can be read by the processor include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc., and in the form of carrier waves such as transmission over the Internet. Including those embodied. The recording medium readable by the processor may be distributed to computer systems connected to a network, and the code readable by the processor may be stored and executed in a distributed manner.

  Although the preferred embodiments of the present invention have been illustrated and described above, the present invention is not limited to the specific embodiments described above, and does not depart from the spirit of the present invention claimed in the scope of claims. It should be understood that various modifications can be made by those having ordinary knowledge in the technical field to which the invention pertains, and such modifications can be individually understood from the technical idea and perspective of the present invention. must not.

  In the specification, both the invention of the product and the invention of the method are explained, and the explanations of both inventions may be supplementarily applied as necessary.

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

In this specification, both the device invention and the method invention are referred to, and the description of the device invention and the method invention can be applied to complement each other.
〔Example〕

  Various embodiments have been described in the best mode for carrying out the invention.

  The present invention is used in a series of broadcast signal providing fields.

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

Claims (14)

Generating service data of broadcast service and service signaling information for signaling the broadcast service, wherein the service data includes a service component included in the broadcast service;
Generating a service list table, the service list table including bootstrap information identifying a transmission session in which the service signaling information is transmitted; and
Processing the service component, the service signaling information and the service list table as IP (Internet Protocol) packets;
Processing the IP packet to generate a broadcast signal, and transmitting the broadcast signal via a broadcast network. The service signaling information includes USBD (User Service Bundle Description),
The broadcast signal transmission method according to claim 1, wherein the USBD operates as a signaling hub that describes technical information related to the broadcast service. The USBD further includes service type information,
The broadcast signal transmission method according to claim 2, wherein the service type information indicates a type of the service when a service is provided by combining a plurality of service components. When the service signaling information of the broadcast service is transmitted by an MMT (MPEG Media Transport) protocol,
The service signaling information further includes information on a view position (view position),
The broadcast signal transmission method according to claim 2, wherein the information on the view position includes right viewpoint information indicating whether a service component for the 3D service is a right view. When the service signaling information of the broadcast service is transmitted by an MMT (MPEG Media Transport) protocol,
The service signaling information further includes information on a view position (view position),
The broadcast signal transmission according to claim 2, wherein the information on the view position includes viewpoint number information with respect to a total number of viewpoints included in a service component for a multi-view service, and viewpoint position information indicating a position of each viewpoint. Method.   The broadcast signal transmission method according to claim 1, wherein the service data includes information related to an original source video as a supplemental enhancement information (SEI) message.   The broadcast signal transmission method according to claim 6, wherein the information related to the original source video includes resolution information and frame rate information of a production format. A service data generation unit for generating service data of a broadcast service and service signaling information for signaling the broadcast service, wherein the service data includes a service component included in the broadcast service;
A low level signaling generating unit for generating a service list table, wherein the service list table includes bootstrap information for identifying a transmission session to which the service signaling information is transmitted. When,
A transmission layer processing unit that processes the service component, the service signaling information, and the service list table as an IP (Internet Protocol) packet;
A broadcast signal transmitting apparatus comprising: a physical layer processing unit that processes the IP packet to generate a broadcast signal and transmits the broadcast signal via a broadcast network. The service signaling information includes USBD (User Service Bundle Description),
The broadcast signal transmitting apparatus according to claim 8, wherein the USBD operates as a signaling hub that describes technical information related to the broadcast service. The USBD further includes service type information,
The broadcast signal transmitting apparatus according to claim 9, wherein the service type information indicates a type of the service when a service is provided by combining a plurality of service components. When the service signaling information of the broadcast service is transmitted by an MMT (MPEG Media Transport) protocol,
The service signaling information further includes information on a view position (view position),
The broadcast signal transmitting apparatus according to claim 9, wherein the information on the view position includes right viewpoint information indicating whether a service component for a 3D service is a right view. When the service signaling information of the broadcast service is transmitted by an MMT (MPEG Media Transport) protocol,
The service signaling information further includes information on a view position (view position),
The broadcast signal transmission according to claim 9, wherein the information on the view position includes viewpoint number information with respect to a total number of viewpoints included in a service component for multi-view service, and viewpoint position information indicating a position of each viewpoint. apparatus.   The broadcast signal transmitting apparatus according to claim 8, wherein the service data includes information related to an original source video as a SEI (supplemental enhancement information) message.   The broadcast signal transmitting apparatus according to claim 13, wherein the information related to the original source video includes resolution information and frame rate information of a production format.