WO2017213371A1 - Broadcast signal reception apparatus and method - Google Patents

Abstract

Disclosed is a broadcast signal reception method. The broadcast signal reception method of the present invention comprises the steps of: parsing a service list table (SLT) included in a broadcast signal, wherein SLT information includes bootstrap information for acquiring service layer signaling (SLS) information; acquiring the SLS information on the basis of the SLT information, wherein the SLS information provides service discovery and description information; and receiving a service component on the basis of the SLT information.

Description

Broadcast signal receiving device and method

The present invention relates to a broadcast signal receiving apparatus and a broadcast signal receiving method, and more particularly, to an apparatus and method for receiving metadata based on information extracted from audio and video.

As analog broadcast signal transmission is terminated, various techniques for transmitting and receiving digital broadcast signals have been developed. The digital broadcast signal may include a larger amount of video / audio data than the analog broadcast signal, and may further include various types of additional data as well as the video / audio data.

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

In order to solve the above technical problem, the present invention proposes a broadcast signal receiving method and a broadcast signal receiving apparatus.

In the broadcast signal reception method according to an embodiment of the present invention, the service list table (SLT) parsing included in the broadcast signal, wherein the SLT information includes bootstrap information for obtaining service layer signaling (SLS) information, Obtaining the SLS information based on the SLT information, wherein the SLS information provides service discovery and description information; And receiving a service component based on the SLS information, the method comprising: receiving uncompressed audio or video; Extracting fingerprint information identifying metadata from the uncompressed audio or video; Transmitting the fingerprint information to a fingerprint server; And receiving URL information and media timing information for receiving metadata corresponding to the fingerprint information from the fingerprint server.

The broadcast signal receiving method according to an embodiment of the present invention further includes transmitting a query to a metadata server based on the URL information and receiving metadata from the metadata server, wherein the metadata is supplemental content. It includes at least one of data or signaling information.

In the broadcast signal receiving method according to an embodiment of the present invention, the reception of the URL information and the media timing information may be received as a response to the request including the fingerprint information.

In the broadcast signal receiving method according to an embodiment of the present invention, the URL information includes at least one of recovery base URL information, dynamic event base URL information, or dynamic event web socket server URL information.

In the broadcast signal reception method according to an embodiment of the present invention, the reception of the URL information and the media timing information is received as a response to the detection of a new recovery file or a new dynamic event.

In the broadcast signal receiving method according to an embodiment of the present invention, the URL information includes at least one of recovery base URL information and dynamic event base URL information.

In the method of receiving a broadcast signal according to an embodiment of the present invention, the SLS and the service component based on the SLS are received based on a Real-Time Object Delivery over Unidirectional Transport (ROUTE) protocol or an MPEG Media Transport (MMT) protocol. .

In order to solve the above technical problem, a broadcast signal receiver according to an embodiment of the present invention, a communication unit for receiving a broadcast signal; A memory for storing data; And a processor controlling the communication unit and the memory, wherein the broadcast receiver parses a service list table (SLT) included in a broadcast signal, obtains SLS information based on the SLT information, and applies the SLS information to the SLS information. Receiving a service component based on the information, wherein the SLT information includes bootstrap information for acquiring the service layer signaling (SLS) information, the SLS information provides service discovery and description information, and the broadcast receiver includes: Receives compressed audio or video, extracts fingerprint information identifying metadata from the uncompressed audio or video, transmits fingerprint information to a fingerprint server, and corresponds to the fingerprint information from the fingerprint server. URL information and media timing information for receiving metadata may be received.

The present invention can provide various broadcast services by processing data according to service characteristics to control a quality of service (QoS) for each service or service component.

The present invention can achieve transmission flexibility by transmitting various broadcast services through the same radio frequency (RF) signal bandwidth.

According to the present invention, it is possible to provide a broadcast signal transmission and reception method and apparatus capable of receiving a digital broadcast signal without errors even when using a mobile reception device or in an indoor environment.

The present invention can effectively support the next generation broadcast service in an environment supporting the next generation hybrid broadcast using the terrestrial broadcast network and the Internet network.

Further effects of the present invention will be described below along with the configuration of the invention.

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

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

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

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

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

6 illustrates a content recovery method according to an embodiment of the present invention.

7 illustrates a content recovery method according to another embodiment of the present invention.

8 illustrates a broadcast signal receiving method according to an embodiment of the present invention.

9 illustrates a broadcast signal receiving method according to an embodiment of the present invention.

10 illustrates a broadcast signal receiver configuration according to an embodiment of the present invention.

Preferred embodiments of the present invention will be described in detail, examples of which are illustrated in the accompanying drawings. DETAILED DESCRIPTION The following detailed description with reference to the accompanying drawings is intended to explain preferred embodiments of the invention rather than to show only embodiments that may be implemented in accordance with embodiments of the invention. The following detailed description includes details to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these details.

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

The present invention provides an apparatus and method for transmitting and receiving broadcast signals for next generation broadcast services. The next generation broadcast service according to an embodiment of the present invention includes a terrestrial broadcast service, a mobile broadcast service, a UHDTV service, and the like. According to an embodiment of the present invention, a broadcast signal for a next generation broadcast service may be processed through a non-multiple input multiple output (MIMO) or MIMO scheme. The non-MIMO scheme according to an embodiment of the present invention may include a multiple input single output (MISO) scheme, a single input single output (SISO) scheme, and the like. The present invention proposes a physical profile (or system) that is optimized to minimize receiver complexity while achieving the performance required for a particular application.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The LLS_table_id field may identify a type of the corresponding LLS table, and the provider_id field may identify service providers related to services signaled by the corresponding LLS table. Here, the service provider is a broadcaster using all or part of the broadcast stream, and the provider_id field may identify one of a plurality of broadcasters using the broadcast stream. The LLS_table_version field may provide version information of a corresponding LLS table.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The @bsid attribute may be an identifier of a broadcast stream through which service components of a corresponding service are delivered. If this field is omitted, the default broadcast stream may be a broadcast stream that includes a PLP that carries the SLS of the service. The value of this field may be the same value as the @bsid attribute of SLT.

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

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

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

The @tsi attribute may represent tsi information of a corresponding LCT channel. Through this, LCT channels through which a service component of a corresponding service is delivered may be identified. The @PLPID attribute may represent PLP ID information of a corresponding LCT channel. In some embodiments, this field may be omitted. The @bw attribute may indicate the maximum bandwidth of the corresponding LCT channel. The @startTime attribute may indicate the start time of the LCT session, and the @endTime attribute may indicate the end time of the LCT channel.

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

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

5 is a diagram illustrating a USBD delivered to 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 may have a userServiceDescription element. The userServiceDescription element may be an instance of one service.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Hereinafter, a content recovery method of the broadcast receiver will be described.

Signaling information and supplemental content may not be delivered to the broadcast receiver over the air. The broadcast receiver may also receive audio and video from the set-top box via a high-definition multimedia interface (HDMI) cable. The broadcast receiver may receive signaling information or additional content based on additional data included in audio or video. This process may be referred to as content recovery.

Content recovery can be performed by delivering additional data to a broadcast receiver over an HDMI connection. The additional data may be included in the uncompressed audio or video signal. Such additional data may be referred to as content recovery information. The additional data may include means for identifying the content. The additional data may include additional information depending on the capacity of the data delivery method. The broadcast receiver may connect to the remote server via broadband using additional data. The remote server may interpret the additional data and transmit the additional content to the broadcast receiver via broadband. The additional data may include watermark information or fingerprint information.

In this specification, data additionally received by the content recovery method may be referred to as metadata. The metadata may include at least one of supplemental content data or signaling data.

6 illustrates a content recovery method according to an embodiment of the present invention.

6 illustrates a content recovery method of delivering data to a receiver through a watermark extracted from uncompressed audio or video. Watermarks may be inserted and extracted into the media data for content recovery.

As shown in FIG. 6, the broadcast receiver may receive uncompressed audio / video, and the uncompressed audio / video may include a watermark. The broadcast receiver may transmit a query to the metadata server on the basis of the watermark, and receive signaling information or content data in response thereto.

As another content identifier determination method, a fingerprinting method may be used, which will be described in detail below.

7 illustrates a content recovery method according to another embodiment of the present invention.

7 illustrates a content recovery method using a fingerprint (or signature). A fingerprint may be referred to as a signature. The fingerprint information indicates an identifier / information included in the video / audio for content recovery. The fingerprint may identify specific metadata or identify information (URL information or timing information) necessary for obtaining the specific metadata.

In FIG. 7, the broadcast receiver 7010 includes a fingerprint client (FP Client). The broadcast receiver 7010 may receive uncompressed audio / video from equipment such as the set top box 7050. The broadcast receiver 7010 may extract a fingerprint from uncompressed audio / video and transmit the extracted fingerprint to the remote fingerprint server 7020.

As shown in FIG. 7, the broadcasting station 7030 may insert a fingerprint / signature for supplemental data / signaling information into the video / audio. The broadcaster 7030 may extract the fingerprint / signature and transmit the fingerprint / signature to the fingerprint server 7020 together with the corresponding metadata (data / signaling).

The fingerprint server 7020 may check the fingerprint received from the database. When the fingerprint is recognized, the fingerprint server 7020 may transmit URL information and media timing information to the broadcast receiver 7010. The fingerprint server 7020 has fingerprint data received from a plurality of broadcasting stations. The fingerprint server 7020 may receive a fingerprint / signature and metadata corresponding to the fingerprint / signature from the broadcasting station 7030. In an embodiment, the fingerprint server 7020 may store a signature and an address of a server to receive metadata corresponding to the signature. When the fingerprint server 7020 receives the signature, the fingerprint server 7020 may identify matching metadata and transmit at least one of URL information or timing information capable of receiving the metadata.

The broadcast receiver 7010 may receive and provide at least one of supplementary content or signaling information from the metadata server 7040 using the received URL information and timing information.

The broadcast receiver 7010 may synchronize the recovery file, that is, metadata and audio / video, by using the timing information. In one embodiment, the timing information may include an interval code. The interval code may identify an interval of content.

A request / response model and an event-driven model may be used for communication between the fingerprint server and the broadcast receiver.

In the request / response model, the receiver periodically computes the signature of the content and may send a request including the signature to the fingerprint server. The fingerprint server may receive the request from the receiver and send a response. Communication sessions between request and response instances are not kept open. In this model, the fingerprint server may not be able to initiate message transmission to the receiver.

In the event-driven model, the receiver may initiate a persistent connection with the fingerprint server. The receiver may periodically calculate the signatures of the frames and submit the signatures over the connection. In the event-driven model, the receiver may include a submission sequence number in the message in each submission. The fingerprint server does not respond to each submission. The fingerprint server may send a message to the receiver only when a new recovery file or dynamic event is detected. In this model, the fingerprint server can initiate message transmission to the client at any time.

The two models are described in more detail below.

1. Request / Response Model

The fingerprint server responds to each request from the receiver, and the response may include at least one of the following parameter information.

1) Recovery Base URL (URL scheme can be http: or https :)

2) media timing information (e.g., interval code)

3) Dynamic Event Base URL (URL scheme can be http: or https :)

4) Dynamic Event WebSocket Server URL (URL scheme can be http: or https :)

The recovery base URL and interval code can be used by the receiver to request a recovery file from the recovery server. The URL for requesting a recovery file will be described later.

In the request / response model, there are two ways the receiver retrieves the dynamic event. When the dynamic event base URL is received, the receiver may request a dynamic event from the event server. The URL for requesting a dynamic event will be described later. Once the dynamic event websocket server URL is received, the receiver can maintain a persistent connection with the event server based on the websocket protocol.

2. Event-driven model

The fingerprint server using the event-driven model may not respond to each request from the receiver. The receiver can only respond when a new recovery file or dynamic event is detected. The response may include at least one of the following parameter information.

1) Recovery Base URL (URL scheme can be http: or https :)

2) media timing information (e.g., interval code)

3) Dynamic Event Base URL (URL scheme can be http: or https :)

The recovery base URL and interval code can be used by the receiver to request a recovery file from the recovery server. The URL for requesting a recovery file will be described later.

When the dynamic event base URL is received, the receiver may request a dynamic event from the event server. The URL for requesting a dynamic event will be described later.

Recovery file retrieval via broadband

In the case of using the above watermark, as shown in FIG. 6, the broadcast receiver may request and receive recovery data from the metadata server. Hereinafter, a method of receiving such a recovery file will be described.

The broadcast receiver may transmit a recovery data request to the recovery server by transmitting an HTTP GET or HTTP GET request. The recovery data request may be sent from the VP1 payload to the resource specified by the URL constructed. The URL template may be configured as follows.

http [s]: // {hostName} / a336 / rdt / {subdName} / {serverCode}-{intervalCode} .rdt

[string]; The string represents an item in square barckets [], {element}; Elements represent items in curly brackets {}.

The request can use the http prefix if the query employs HTTP, and the https prefix if the query employs HTTPS.

In an embodiment, when the value of the domain_type field of the VP1 payload is '0', the hostName has a value as follows.

a336. {serverCode1}. {serverCode2}. {serverCode3}. {serverCode4} .0.vp1.tv

SubName has the following values,

{serverCode4} {serverCode3} / {serverCode2} / {serverCode1}

The server code may have the following value.

{serverCode4} {serverCode3} {serverCode2} {serverCode1}

As another embodiment, when the value of the domain_type field of the VP1 watermark code is '1', the host name has a value as follows.

a336. {serverCode1}. {serverCode2}. {serverCode3} .1.vp1.tv

SubName has the following values,

{serverCode3} {serverCode2} / {serverCode1}

The server code may have the following value.

{serverCode3} {serverCode2} {serverCode1}

ServerCode1 (serverCode1), ServerCode2 (serverCode2), ServerCode3 (serverCode3), and ServerCode4 (serverCode4) are the minimum of the server_field of the VP1 payload (zero padded from most significant bit to the next byte boundary), respectively. It means the maximum valid byte and can be represented as a two-letter uppercase hexadecimal value (serverCode1, serverCode2, serverCode3, and serverCode4 shall respectively mean the least-to-most significant bytes of the server_field of the VP1 payload (zero-padded at the most-significant bit to the next byte boundary) expressed as two-character uppercase-only hexadecimal values).

The intervalCode is the value of the interval_field of the VP1 payload (zero padded from the most significant bit to the next byte boundary) and can be expressed as an uppercase hexadecimal value. However, it can be 6 characters in the length of the VP1 payload with domain_type = 0 and 8 characters in the length of the VP1 payload with domain_type = 1. (IntervalCode shall be the value of the interval_field of the VP1 payload (zero-padded at the most-significant bit to the next byte boundary) expressed as an uppercase-only hexadecimal value (6 characters in length for VP1 payloads with domain_type = 0 and 8 characters in length for VP1 payloads with domain_type = 1))

DNS resolution of {hostname} of an unspecified IP address (0.0.0.0/32 for IPv4 address or :: / 128 for IPv6 address) may indicate that the recovery protocol is not supported in the code domain. Recovery file requests may not be issued to an unspecified address.

The broadcast receiver may transmit a recovery data request to the recovery server by transmitting an HTTP GET or HTTP GET request. The recovery data request may be sent to the resource specified by the URL constructed from the response of the fingerprint server. The URL template may be configured as follows.

{Recovery Base URL} / {intervalCode} .rdt

The response to the recovery data request may include a recovery file. In addition, the response to the recovery data request may include signaling files. If the signaling files exist, the "valid from", "valid until" and "next URL" attributes associated with each signaling file may be included in the metadata envelope. The Valid From and Valid Until attributes may define the valid interval of the signaling file. The next URL attribute may indicate the URL of the next scheduled version of the signaling file.

Dynamic event retrieval via broadband

Availability of the dynamic event may be indicated by a change in query flag (query_flag) between VP1 payloads in the watermark segment.

The broadcast receiver may transmit a recovery data request to the recovery server by transmitting an HTTP GET or HTTP GET request. The recovery data request may be sent from the VP1 payload to the resource specified by the URL constructed. The recovery data request may be sent to the resource specified by the URL constructed from the VP1 payload having a query flag value different from the preceding payload. The URL template may be configured as follows.

http [s]: // {hostName} / a336 / dyn / {subdName} / {serverCode}-{intervalCode} .dyn

[string]; The string represents an item in square barckets [], {element}; Elements represent items in curly brackets {}. The above description may be applied to a host frame, a sub frame, a server code, and an interval code.

DNS resolution of {hostname} of an unspecified IP address (0.0.0.0/32 for IPv4 address or :: / 128 for IPv6 address) may indicate that the recovery protocol is not supported in the code domain. Recovery file requests may not be issued to an unspecified address.

The broadcast receiver may send a dynamic event request to the event server by issuing an HTTP GET or HTTP GET request. The recovery data request may be sent to the resource specified by the URL constructed from the response of the fingerprint server. The URL template may be configured as follows.

{Dynamic Event Base URL} / {intervalCode} .dyn

The response to the dynamic event request may include a dynamic event. If the event is intended for an application, the event can be delivered to any application in the runtime environment. When an event announces the availability of at least one updated signaling file, the event can be delivered alone or packaged with one or more signaling files for delivery. The attribute of the event may be used to declare an update of the signaling files.

8 illustrates a broadcast signal receiving method according to an embodiment of the present invention.

The broadcast signal receiver may receive a broadcast signal (S8010). The broadcast signal receiver may receive a broadcast signal through a broadcast network or a broadband network.

The broadcast signal receiver may parse service list table (SLT) information included in the broadcast signal (S8020). The SLT information may include bootstrap information necessary to obtain service layer signaling (SLS) information for each service.

The broadcast signal receiver may acquire SLS information based on the SLT information (S8030). SLS information includes service discovery and description information. SLS is signaling information describing characteristics of a corresponding service, and may provide information necessary to acquire a service and a service component, or provide receiver performance information for service reproduction.

The broadcast signal receiver may receive a service component based on the SLS information (S8040). The service component based on the SLS information and the SLS information may be received based on a Real-Time Object Delivery over Unidirectional Transport (ROUTE) protocol or an MPEG Media Transport (MMT) protocol.

The service component may include at least one of video or audio.

SLT parsing, SLS information acquisition, and service / service component reception of the broadcast receiver are described in FIG. 1 to FIG. 5, and the overlapping description will not be described in detail.

9 illustrates a broadcast signal receiving method according to an embodiment of the present invention.

The broadcast signal receiver may receive at least one of uncompressed audio or video (S9010). The broadcast signal receiver may receive uncompressed audio / video from an external device or an internal device. The broadcast signal receiver may receive uncompressed audio / video from a separate set top box. The broadcast signal receiver may receive uncompressed audio / video from a built-in set top box. In addition, the data included in the service component received in FIG. 8 may be processed, and the processed uncompressed audio / video may correspond to the uncompressed audio / video of FIG. 9. That is, the uncompressed audio / video may be included in the received service component or may be received through a separate path. Uncompressed audio / video may represent at least one of audio data / stream or video data / stream.

The broadcast signal receiver may extract fingerprint information from at least one of uncompressed audio or video (S9020). Fingerprint information may be referred to as signature information. The fingerprint information can identify the metadata. That is, the fingerprint server may match or identify specific fingerprint information with specific metadata such as supplementary data or signaling file. The fingerprint information provides the information needed to receive the specific metadata. As an embodiment, the specific metadata may include a signaling file or additional content data.

The broadcast signal receiver may transmit the extracted fingerprint information to the fingerprint server (S9030). The address of the fingerprint server may be preset. In an embodiment, different fingerprint server addresses may be mapped according to the type of fingerprint information. The broadcast signal receiver may transmit fingerprint information to a corresponding fingerprint server based on the extracted type of fingerprint information.

The broadcast signal receiver may receive URL information and media timing information for receiving metadata corresponding to the fingerprint information from the fingerprint server from the fingerprint server (S9040). The URL information may include at least one of recovery base URL information, dynamic event base URL information, and dynamic event web socket server URL information. As described above, when the metadata is received in the request / response model, the URL information may include at least one of recovery base URL information, dynamic event base URL information, or dynamic event web socket server URL information. When the metadata is received in the event-driven model, the URL information may include at least one of the recovery base URL information and the dynamic event base URL information.

In the case of a request / response model, the URL information and media timing information may be received as a response to the request including the fingerprint information. In the event-driven model, the URL information and timing information may be received in response to the detection of a new recovery file or a new dynamic event.

In addition to the method of FIG. 9, the broadcast signal receiver may further include transmitting a metadata query to a metadata server indicated by the URL information received from the fingerprint server and receiving net data from the metadata server. Can be. The metadata may include at least one of supplemental content data or signaling information.

By using the fingerprint information of the present invention, a broadcast station can provide unscheduled content or signaling information. That is, the fingerprint information of the present invention may be used to deliver data not previously known to the broadcast receiver by signaling information such as SLT or SLS. The receiver may receive metadata over the Internet / broadband even if there is a problem in the broadcasting network. Since the fingerprint information has a very small amount of information and the data is received from the metadata server, the present invention can provide supplemental content / signaling information efficiently in a system.

10 illustrates a broadcast signal receiver configuration according to an embodiment of the present invention.

In FIG. 10, the broadcast signal receiver 10000 may include a communication unit 1010, a processor 10020, and a memory 10030.

The communication unit 10010 may be connected to the processor 10020 to transmit / receive a radio signal. The communication unit 10010 may transmit a signal by upconverting data received from the processor 10020 into a transmission / reception band. The communication unit 10010 may down-convert the received data and forward it to the processor 10020. The communication unit 10010 may receive an audio / video signal by wire. The communication unit may comprise at least one of a communication unit for wireless communication or a communication unit for wired communication. The broadcast signal receiver may receive an audio / video signal by using a wired communication unit. The broadcast signal receiver may transmit the fingerprint information or the query and receive the URL information, the timing information or the metadata by using the wireless communication unit.

The processor 10020 may be connected to the communication unit 10010 to implement broadcast signal processing technology according to the ATSC 3.0 system. The processor 10020 may be configured to perform an operation according to various embodiments of the present disclosure according to the drawings and description described above. In addition, a module for implementing the operation of the broadcast signal receiver 10000 according to various embodiments of the present disclosure described above may be stored in the memory 10030 and executed by the processor 10020.

The memory 10030 is connected to the processor 10020 and stores various information for driving the processor 10020. The memory 10030 may be included in the processor 10020 or may be installed outside the processor 10020 and connected to the processor 10020 by a known means. The specific configuration of the broadcast signal receiver 10000 may be implemented so that the above-described matters described in various embodiments of the present invention may be independently applied or two or more embodiments may be simultaneously applied.

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

For convenience of description, the drawings are divided and described, but the embodiments described in each drawing may be merged to implement a new embodiment. Apparatus and method according to the present invention is not limited to the configuration and method of the embodiments described as described above, the above-described embodiments may be selectively all or part of each embodiment so that various modifications can be made It may be configured in combination.

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

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

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

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

The present invention is used in the field of transmitting / receiving a series of broadcast signals.

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

Claims (14)

1. Parsing a service list table (SLT) included in a broadcast signal, wherein the SLT information includes bootstrap information for obtaining service layer signaling (SLS) information;

   Obtaining the SLS information based on the SLT information, wherein the SLS information provides service discovery and description information; And

   A broadcast signal receiving method comprising receiving a service component based on the SLS information,

   Receiving uncompressed audio or video;

   Extracting fingerprint information identifying metadata from the uncompressed audio or video;

   Transmitting the fingerprint information to a fingerprint server; And

   And receiving URL information and media timing information for receiving metadata corresponding to the fingerprint information from the fingerprint server.
2. The method of claim 1,

   Transmitting a query to a metadata server based on the URL information; And

   Receiving metadata from the metadata server, wherein the metadata includes at least one of supplemental content data or signaling information.
3. The method of claim 2,

   The reception of the URL information and the media timing information is received as a response to the request including the fingerprint information.
4. The method of claim 3, wherein

   The URL information includes at least one of recovery base URL information, dynamic event base URL information, or dynamic event web socket server URL information.
5. The method of claim 2,

   The reception of the URL information and the media timing information is received as a response to the detection of a new recovery file or a new dynamic event.
6. The method of claim 5,

   The URL information includes at least one of recovery base URL information and dynamic event base URL information.
7. The method of claim 1,

   And the service component based on the SLS and the SLS is received based on a Real-Time Object Delivery over Unidirectional Transport (ROUTE) protocol or an MPEG Media Transport (MMT) protocol.
8. A communication unit for receiving a broadcast signal;

   A memory for storing data; And

   A broadcast signal receiver comprising a processor for controlling the communication unit and the memory,

   The broadcast receiver parses a service list table (SLT) included in a broadcast signal, obtains SLS information based on the SLT information, receives a service component based on the SLS information, and the SLT information includes the SLS ( Bootstrap information for obtaining service layer signaling) information, wherein the SLS information provides service discovery and description information,

   The broadcast receiver,

   Receive uncompressed audio or video,

   Extract fingerprint information identifying metadata from the uncompressed audio or video,

   Transmit fingerprint information to a fingerprint server, and

   And receiving URL information and media timing information for receiving metadata corresponding to the fingerprint information from the fingerprint server.
9. The method of claim 8,

   The broadcast receiver,

   Send a query to a metadata server based on the URL information, and

   Receiving metadata from the metadata server, wherein the metadata includes at least one of supplemental content data or signaling information.
10. The method of claim 9,

    And the reception of the URL information and the media timing information is received in response to a request including the fingerprint information.
11. The method of claim 10,

    The URL information includes at least one of recovery base URL information, dynamic event base URL information, or dynamic event web socket server URL information.
12. The method of claim 9,

    The reception of the URL information and the media timing information is received as a response to the detection of a new recovery file or a new dynamic event.
13. The method of claim 12,

    The URL information includes at least one of recovery base URL information and dynamic event base URL information.
14. The method of claim 8,

    And the service component based on the SLS and the SLS is received based on a Real-Time Object Delivery over Unidirectional Transport (ROUTE) protocol or an MPEG Media Transport (MMT) protocol.

Images