WO2012169813A2 - Procédé de transmission de service de diffusion audiovisuelle, procédé de réception de service de diffusion audiovisuelle et appareil de réception de service de diffusion audiovisuelle - Google Patents

Procédé de transmission de service de diffusion audiovisuelle, procédé de réception de service de diffusion audiovisuelle et appareil de réception de service de diffusion audiovisuelle Download PDF

Info

Publication number
WO2012169813A2
WO2012169813A2 PCT/KR2012/004513 KR2012004513W WO2012169813A2 WO 2012169813 A2 WO2012169813 A2 WO 2012169813A2 KR 2012004513 W KR2012004513 W KR 2012004513W WO 2012169813 A2 WO2012169813 A2 WO 2012169813A2
Authority
WO
WIPO (PCT)
Prior art keywords
service
information
caption
data
field
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/KR2012/004513
Other languages
English (en)
Korean (ko)
Other versions
WO2012169813A3 (fr
Inventor
서종열
토마스고머
이준휘
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of WO2012169813A2 publication Critical patent/WO2012169813A2/fr
Publication of WO2012169813A3 publication Critical patent/WO2012169813A3/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing of additional data and video streams
    • H04N21/23617—Multiplexing of additional data and video streams by inserting additional data into a data carousel, e.g. inserting software modules into a DVB carousel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H04N21/4349—Demultiplexing of additional data and video streams by extracting from data carousels, e.g. extraction of software modules from a DVB carousel

Definitions

  • the present invention relates to a broadcast service transmission method, a reception method thereof, and a reception device thereof.
  • Digital television is able to provide a variety of services in addition to video, audio, which is a unique feature of television (TV).
  • broadcast information Electronic Program Guide: EPG
  • EPG Electronic Program Guide
  • broadcast services received from two or more channels may be simultaneously provided.
  • the receiving system is equipped with a large-capacity storage device and is connected to the Internet or a data communication channel capable of bidirectional communication, there are many services that can be provided using broadcast signals.
  • services using broadcast signals are diversified as described above, the necessity of providing information on services using broadcast signals in various ways has increased.
  • An object of the present invention is to provide a method for receiving and processing a non-real-time service and a method for transmitting a non-real-time service.
  • the present invention provides a method for providing content downloaded through a non-real-time service and a receiving apparatus thereof.
  • Another object of the present invention is to provide a broadcast service receiving method capable of providing various information about a broadcast service including a real time service and a non real time service without affecting an existing receiver.
  • Broadcast service receiving method comprises the steps of receiving subtitle service signaling information; Recognizing a type of a data stream including caption data based on the caption service signaling information; And extracting the caption data based on the type of the data stream.
  • a broadcast service receiving apparatus includes: a receiver configured to receive subtitle service signaling information and a data stream of a content item; A service manager recognizing a type of the data stream including subtitle data based on the subtitle service signaling information and extracting the subtitle data based on the type of the data stream; And a display unit for outputting the caption data.
  • Broadcast service transmission method comprises the steps of generating the type information of the data stream including the caption data; Transmitting type information of the data stream; And transmitting a data stream including the caption data based on the type of the data stream.
  • broadcast information may be received and provided through a non-real-time service.
  • broadcast information may be provided using a non-real time service without affecting an existing receiver.
  • 1 is a diagram illustrating a concept of providing an RT service and an NRT service.
  • FIG. 2 is a diagram illustrating a structure of an NRT service according to an embodiment of the present invention.
  • FIG. 3 illustrates a protocol stack for an NRT service configured according to an embodiment of the present invention.
  • FIG. 4 illustrates a protocol stack for an NRT service configured according to another embodiment of the present invention.
  • FIG. 5 illustrates a bitstream section of a TVCT table section (VCT) configured according to an embodiment of the present invention.
  • 6 and 7 illustrate examples of defining a value of a service_type field according to an embodiment of the present invention.
  • FIG. 8 illustrates a bitstream syntax of a DST table section (data_service_table_section) for identifying an application of an NRT service and data_service_table_bytes included in the DST section.
  • FIG. 9 is a reception system for receiving and servicing an NRT service using an ATSC A / 90 standard for delivering a data broadcast stream and an ATSC A / 92 standard for transmitting an IP multicast stream in a reception system according to the present invention. It is a figure for demonstrating a method.
  • FIG. 11 illustrates a method of signaling DSM-CC addressable section data using a VCT.
  • FIG. 14 illustrates a bit stream syntax of an NRT_component_descriptor (MH_component_descriptor) configured according to an embodiment of the present invention.
  • FIG. 15 illustrates a bit stream syntax of an NRT component descriptor to which NRT_component_data configured according to an embodiment of the present invention belongs.
  • FIG. 16 illustrates a bitstream syntax of an NRT-IT section for signaling an NRT application configured according to an embodiment of the present invention.
  • NCT section 17 is a diagram illustrating an embodiment of a bit stream syntax structure for an NCT section (NRT_content_table_section) according to the present invention.
  • FIG. 18 illustrates an embodiment of a bit stream syntax structure of an SMT section that provides signaling information about NRT service data.
  • FIG. 19 illustrates a file description table (FDT) schema for mapping a file and content_id according to an embodiment of the present invention
  • FIG. 20 illustrates mapping of a file and content_id according to another embodiment of the present invention. It is shown to explain the FDT schema.
  • FDT file description table
  • FIG. 20 is a diagram for explaining an FDT schema for mapping a file and content_id according to another embodiment of the present invention.
  • 21 is a flowchart illustrating a method of operating a receiver according to an embodiment of the present invention.
  • 22 and 23 illustrate another embodiment of a reception system capable of receiving, storing, and playing back NRT content for an NRT service.
  • 24 is a flowchart illustrating a method of receiving and providing an NRT service by a receiver according to an embodiment of the present invention.
  • 25 is a diagram illustrating syntax of a caption service descriptor according to an embodiment of the present invention.
  • FIG. 26 is a diagram for explaining the meaning of each value of a subtitle type field included in a caption service descriptor when transmitting caption data included in a separate stream instead of a video stream according to another embodiment of the present invention. .
  • FIG. 27 is a diagram for explaining the meaning of each value of a subtitle format field included in a caption service descriptor when transmitting caption data included in a separate stream instead of a video stream according to another embodiment of the present invention. .
  • FIG. 28 is a flowchart illustrating a method of receiving broadcast service according to an embodiment of the present invention, in particular, providing caption data based on caption service information included in an SMT.
  • 29 is a flowchart illustrating a method of receiving a broadcast service according to another embodiment of the present invention, in particular, providing a caption data based on caption service information included in an NRT-IT.
  • FIG. 30 is a view for explaining another embodiment of a receiving system capable of receiving, storing, and playing back NRT content for an NRT service.
  • FIG. 31 is a flowchart schematically illustrating a broadcast service transmission method according to an embodiment of the present invention.
  • 32 is a flowchart schematically illustrating a broadcast service transmission method according to another embodiment of the present invention.
  • FIG. 33 is a block diagram illustrating a network topology according to an embodiment of the present invention.
  • FIG. 34 is a block diagram illustrating a watermark based network topology according to an embodiment of the present invention.
  • 35 is a ladder diagram illustrating a data flow in a watermark based network topology according to an embodiment of the present invention.
  • 36 is a view illustrating a watermark based content recognition timing according to an embodiment of the present invention.
  • FIG. 37 is a block diagram illustrating a fingerprint based network topology according to an embodiment of the present invention.
  • FIG. 38 is a ladder diagram illustrating a data flow in a fingerprint based network topology according to an embodiment of the present invention.
  • 39 is an XML schema diagram of an ACR-Resulttype containing a query result according to an embodiment of the present invention.
  • FIG. 40 is a block diagram illustrating a watermark and fingerprint based network topology according to an embodiment of the present invention.
  • FIG. 41 is a ladder diagram illustrating a data flow in a watermark and fingerprint based network topology according to an embodiment of the present invention.
  • FIG. 42 is a block diagram of a video display device according to another embodiment.
  • RT service used in the present invention means literally a real time service. In other words, it is a time-bound service.
  • non-real time (NRT) service means non-real-time services other than RT services.
  • non-real-time services are services that are not bound by time.
  • the data for the NRT service may be referred to as NRT service data.
  • the broadcast receiver according to the present invention may receive NRT service through a medium such as terrestrial, cable, or the Internet.
  • the NRT service may be stored in the storage medium of the broadcast receiver and then displayed on the display device according to a preset time or a user's request.
  • the NRT service is received in a file form and stored in a storage medium.
  • the storage medium is an internal HDD mounted in the broadcast receiver.
  • the storage medium may be a USB (Universal Serial Bus) memory or an external HDD connected to the outside of the broadcast receiving system.
  • NRT service signaling information In order to receive files constituting the NRT service, store them in a storage medium, and service the user, signaling information is required. In the present invention, this may be referred to as NRT service signaling information or NRT service signaling data.
  • the NRT service according to the present invention may be classified into a fixed NRT service and a mobile NRT service according to a method of obtaining an IP datagram including NRT service signaling data.
  • the fixed NRT service is provided to the fixed broadcast receiver
  • the Mobile NRT service is provided to the mobile broadcast receiver.
  • 1 illustrates a concept of providing an RT service and an NRT service.
  • the broadcasting station transmits the RT service according to the existing scheme, that is, like the current terrestrial broadcasting (or mobile broadcasting).
  • the broadcasting station may transmit the RT service and use the remaining bandwidth in the process or provide the NRT service using the dedicated bandwidth. That is, the RT service and the NRT service are transmitted through the same channel or different channels. Accordingly, NRT service signaling information (or NRT service signaling data) is required for the broadcast receiver to distinguish between RT service and NRT service, to store the divided NRT service, and to provide the NRT service to a user when necessary. NRT service signaling information (or NRT service signaling data) will be described in detail later.
  • a broadcast station may transmit broadcast service data in real time, and may transmit news clips, weather information, advertisements, Push VODs, and the like in non real time.
  • the NRT service may be news clips, weather information, advertisements, push VOD, as well as specific scenes of a live broadcast stream, detailed information of a specific program, and previews.
  • Conventional broadcast receivers can receive and process real-time services, but cannot receive and process non-real-time services. That is, the conventional broadcast receiver (ie, legacy device) is the principle that the operation is not affected by the NRT stream included in the channel for transmitting the real-time service. In other words, the conventional broadcast receiver cannot process the received NRT service because the conventional broadcast receiver is not provided with a means capable of properly processing the NRT service.
  • the broadcast receiver that is, the NRT device
  • the broadcast receiver can receive and properly process the NRT service combined with the RT service, it can provide a variety of functions to the viewer than the conventional broadcast receiver.
  • FIG. 2 is a diagram illustrating a structure of an NRT service according to an embodiment of the present invention.
  • One NRT service according to the present invention includes one or more content items (or content or NRT content) as shown in FIG. 2, and one content item includes one or more files.
  • the file and the object may be used in the same sense.
  • the content item is the smallest unit that can be played independently.
  • the news may be an NRT service, and economic news, political news, and life news may each be content items. This can be called.
  • Each of the economic news, political news, and life news may be composed of one or more files.
  • the NRT service may be transmitted in the form of an MPEG-2 transport stream (TS) packet through the same broadcast channel or dedicated broadcast channel as the RT service.
  • TS transport stream
  • a unique PID may be allocated to the TS packet of the NRT service data and transmitted.
  • IP-based NRT service data is transmitted through MPEG-2 TS packetization.
  • NRT service signaling data necessary for receiving NRT service data is transmitted through an NRT service signaling channel.
  • the NRT service signaling channel is transmitted through a specific IP stream on the IP layer.
  • the specific IP stream may also be transmitted as an MPEG-2 TS packet.
  • the NRT service signaling data transmitted through the NRT service signaling channel includes an NRT service map table (SMT), an NRT service table (NST), an NRT content table (NCT), and an NRT information table (NRT).
  • NRT Information Table, NRT-IT provides access information of at least one NRT service or content item or files constituting an NRT service running in an IP layer.
  • the NRT-IT or NCT provides detailed information of content items or files constituting an NRT service.
  • NRT service signaling data which may include SMT (or NST) and NRT-IT (or NCT), may be included in a PSIP table on MPEG2 TS or through an NRT service signaling channel on an IP layer in a virtual channel. May be sent.
  • a plurality of NRT service data may be provided through one virtual channel.
  • the non-real-time information table NRT-IT includes information describing content that can be downloaded to be stored in the receiving device.
  • the information provided to the NRT-IT includes the title of the content (eg, the name of the program that can be downloaded), the time the content can be downloaded, and the content recommendation, availability of caption services, content identification, and other metadata. Information may be included as follows.
  • the text fragment table is a table for providing detailed description information about the content item or service.
  • the TFT includes a data structure that supports multiple languages, and thus can represent detailed descriptions (each string corresponding to one language) in several different languages.
  • the text fragment table is included in private sections having a table_id value (TBD) and may be distinguished by TFT_id.
  • TFT section is included in IP packets within the service signaling channel, which may be a channel assigned the multicast IP address 224.0.23.60 and port 4937 by the IANA.
  • the receiver may identify whether a corresponding service is an NRT service by referring to a service_category field in an SMT, for example.
  • the receiver may uniquely identify the NRT service through the NRT service identifier information (NRT_service_id) field from the SMT.
  • the NRT service may include a plurality of content items.
  • the receiver may identify each NRT content item through the content_id field in the NCT or NRT-IT.
  • the NRT content item and the NRT service may be connected by matching the NRT_channel_id field of the NCT with the aforementioned NRT_service_id field.
  • the NRT service is transmitted through a FLUTE session, and the receiver may extract FDT information from the FLUTE session.
  • the content_id in the extracted FDT information may be mapped to a content identifier (content_id) of NCT or OMA-BCAST SG to identify and receive NRT service content selected by a user.
  • the receiver identifies each file constituting the NRT content item using the TOI and Content-Location fields specified in the FDT within the FLUTE session, and the respective TOI or Content-
  • the location and content item may map the content_ID field in the FDT to the content identifier (content_id) field of the NCT or the content identifier (content_id) field of the OMA BCAST SG, and identify and receive NRT service content.
  • FIG. 3 illustrates a protocol stack for an NRT service configured according to an embodiment of the present invention.
  • the file-type NRT service is IP packetized in an IP layer and then transmitted in a MPEG-2 TS format through a specific virtual channel.
  • an NRT service signaling channel for transmitting NRT service signaling data for signaling access information of an IP-based NRT service is IP packetized to a specific IP stream in an IP layer and then transmitted in an MPEG-2 TS form. do.
  • the broadcasting station packetizes NRT content items or files according to a file transfer protocol scheme as shown in FIG. 3, and converts the packetized NRT content items or files into ALC or Asynchronous Layered Coding or Layered Coding Transport. Packetize according to the method.
  • the packetized ALC or LCT data is again packetized according to the UDP scheme, and the packetized UDP data is again packetized according to the IP scheme to become IP data.
  • the IP data may include a file description table (FDT) including information on a file delivery over unidirectional transport (FLUTE) session.
  • FDT file description table
  • FLUTE unidirectional transport
  • the packetized IP data may be referred to as an IP datagram.
  • IP datagrams of an NRT service are encapsulated into an addressable section structure and packetized into an MPEG-2 TS format. That is, one addressable section structure has a form in which a section header and a CRC checksum are additionally added to one IP datagram.
  • the form of the addressable section structure may be a structure that conforms to the Digital Storage Media Command and Control (DSM-CC) section format for transmitting private data. Therefore, the addressable section may be referred to as a DSM-CC addressable section.
  • DSM-CC Digital Storage Media Command and Control
  • NRT service signaling data including at least one of SMT (or NST) and NRT-IT (or NCT) necessary to receive NRT content / files may be transmitted through an NRT service signaling channel on an IP layer.
  • NRT service signaling data may be packetized according to the IP scheme for transmission over the NRT service signaling channel on the IP layer.
  • an NRT service signaling channel is encapsulated in an IP datagram having a well-known IP address and multicasted.
  • the NRT service signaling data may be included in PSI (Program Specific Information) or PSIP (Program and System Infromation Protocol) table section data and transmitted.
  • the PSI table may include, for example, a Program Map Table (PMT), a Program Association Table (PAT), and the like
  • the PSIP table may include, for example, a virtual channel table (VCT) and a terrestrial virtual channel table (TVCT).
  • CVCT Cable Virtual Channel Table
  • STT System Time Table
  • RTT Rating Region Table
  • ETT Extended Text Table
  • DCCT Direct Channel Change Table
  • DCCSCT Direct Channel Change Selection Code Table
  • EIT An Event Information Table, and a Master Guide Table (MGT).
  • PSI Program Specific Information
  • PSIP Program and System Information Protocol
  • DSM-CC addressable section data DSM-CC addressable section data
  • OMA BCAST DRM data are divided in units of 184 bytes, and then 4 bits are stored in each of 184 bytes.
  • MPEG-2 TS packet of 188 bytes can be produced.
  • the value allocated to the PID of the MPEG header may be the only value capable of identifying the TS packet for transmitting the NRT service and the NRT service signaling channel.
  • MPEG-2 TS packets may be modulated by a predetermined transmission scheme, for example, an 8-VSB transmission scheme, in a physical layer and transmitted to a receiving system.
  • a predetermined transmission scheme for example, an 8-VSB transmission scheme
  • FIG. 4 illustrates a protocol stack for an NRT service configured according to another embodiment of the present invention.
  • FIG. 4 shows an example of a protocol stack for providing a mobile NRT service.
  • FIG. 4 includes an adaptation layer between an IP layer and a physical layer so that an IP datagram of mobile service data and an IP datagram of signaling information can be transmitted without using the MPEG-2 TS format. .
  • the broadcast station packetizes the NRT content / files according to the file transfer protocol scheme in FIG. 4, and packetizes the NRT content / files according to the Asynchronous Layered Coding / Layered Coding Transport (ALC / LCT) scheme.
  • the packetized ALC / LCT data is again packetized according to the UDP scheme, and the packetized ALC / LCT / UDP data is again packetized according to the IP scheme to form ALC / LCT / UDP / IP data.
  • the packetized ALC / LCT / UDP / IP data is referred to as an IP datagram for convenience of description in the present invention.
  • the OMA BCAST SG information may configure an IP datagram through the same process as the NRT content / file.
  • NRT service signaling information (eg, SMT) required for receiving the NRT content / files is transmitted through a service signaling channel, which is packetized according to a user datagram protocol (UDP) scheme.
  • the packetized UDP data is again packetized according to the IP method to become UDP / IP data.
  • the UDP / IP data is also called an IP datagram for convenience of explanation.
  • the service signaling channel is encapsulated in an IP datagram having a well-known IP desiccation address and a well-known desiccation UDP port number and multicasted.
  • IP datagrams of the NRT service, NRT service signaling channel, and mobile service data are collected to generate an RS frame.
  • the RS frame may also include an IP datagram of OMA BCAST SG.
  • the length of the column (ie, the number of rows) in the RS frame is determined to be 187 bytes, the length of the row (ie, the number of columns) is N bytes, and N is signaling information such as a transmission parameter (or TPC data). It may vary.
  • the RS frame is modulated by a predetermined transmission scheme, for example, a VSB transmission scheme, in a mobile physical layer and transmitted to a receiving system.
  • a predetermined transmission scheme for example, a VSB transmission scheme
  • signaling whether or not to transmit an NRT service is performed through a PSI / PSIP table.
  • a PSI / PSIP table For example, signaling whether or not to transmit an NRT service to a virtual channel table (VCT) or a local virtual channel table (TVCT) is described as an embodiment.
  • VCT virtual channel table
  • TVCT local virtual channel table
  • FIG. 5 illustrates a bitstream section of a TVCT table section (VCT) configured according to an embodiment of the present invention.
  • the TVCT table section has a table form of an MPEG-2 private section.
  • the TVCT table section is not limited thereto.
  • the packet identification (PID) information regarding audio / video is transmitted through TVCT by parsing the VCT and PID of the audio / video, and the packet identification (PID) information regarding audio / video can be known.
  • the TVCT table section can be divided into header, body and trailer, the header part is from the table_id field to the protocol_version field, and the transport_stream_id field is a 16-bit field, which is defined by a PID value of 0 for multiplexing. (MPEG-2 transport stream ID) in a program association table.
  • the num_channels_in_section field is an 8-bit field, and the body part details the number of virtual channels in the VCT section.
  • the trailer part contains a CRC_32 field.
  • the table_id field (8 bits) is set to 0xC8 to identify that the table section is a table section constituting TVCT.
  • a section_syntax_indicator field (1 bit) is set to 1, indicating that the section follows the general section syntax.
  • the private_indicator field (1 bit) is set to 1.
  • a section_length field (12 bits) specifies the number of bytes remaining in this section from immediately after the section_length field to the end of the section.
  • the value of the section_length field may not be greater than 1021.
  • the table_id_extension field (16 bits) is set to 0x000.
  • a version_number field (5 bits) may have a value of 0 and indicates a version number of the VCT.
  • a section_number field (8 bits) indicates the number of the corresponding table section among the TVCT sections. In the first section of TVCT, section_number must be set to 0x00.
  • the last_section_number field (8 bits) means the table section of the last and highest number among the TVCT sections.
  • protocol_version field (8 bits) is an allowable function of this table type that carries structured parameters differently than defined in the current protocol. Currently, only one valid value of protocol_version is zero. A non-protocol_version can be used in future versions of the standard to recognize structurally different tables.
  • a num_channels_in_section field (8 bits) specifies the number of virtual channels of the VCT section. The number is limited by the table section length.
  • a short_name field (16 bits) represents the name of the virtual channel as a code value of 1 to 7 consecutive 16 bit codes.
  • a major_channel_number field (10 bits) represents a major channel number associated with a virtual channel defined in repetition of a "for" loop. Each virtual channel must be associated with a major channel number and a minor channel number. Along with the minor channel number, the major channel number serves as a reference number of the user's virtual channel.
  • a minor_channel_number field (10 bits) represents a minor or sub-channel number in the range of '0' to '999'. Along with major_channel_number, the field is performed with a channel number of two parts in which minor_channel_number represents a second or right part of the number. minor_channel_number should be set to 0 when service_type is analog television. When service_type is ATSC_digital_television or ATSC_audio_only, use a minor number in the range of '1' to '99'. The value of minor_channel_number prevents major_channel_number and minor_channel_number from overlapping in TVCT.
  • a modulation_mode field (8 bits) indicates a modulation mode for a carrier associated with a virtual channel.
  • the carrier_frequnecy field (32 bits) has a recommended value of zero. Use of the field to identify carrier frequencies is allowed but preferably not.
  • a channel_TSID field (16 bits) is an unsigned integer field representing an MPEG-2 transport stream ID associated with a transport stream carrying an MPEG-2 program referred to by a virtual channel in the range of '0x0000' to '0xFFFF'.
  • a program_number field (16 bits) identifies an unsigned integer number associated with a virtual channel defined in MPEG-2 program association table (PAT) and TS program map table (PM PMT). For the virtual channel corresponding to the analog service, program_number is set to '0xFFFF'.
  • ETM_location field (2 bits) describes the presence and location of an extended text message (ETM).
  • Hidden virtual channels are omitted when the user is surfing the channel and appear undefined or when accessing the channel entry directly.
  • Typical applications for hidden channels are test signals and NVOD services.
  • Hidden channels and their events appear in the EPG display according to the state of the hide_guide bit.
  • the hidden_guide field is set to 0 for a hidden channel, the virtual channel and its events may appear in the EPG display. Since the bit is ignored for channels that do not have a hidden bit set, the hidden channels and their events are always included in the EPG display regardless of the state of the hide_guide bit.
  • Typical applications for hidden channels with the hidden_guide bit set set to '1' are test signals and services that are easy to obtain through application level pointers.
  • the service_type field (6 bits) indicates the type of service transmitted on the virtual channel.
  • 6 and 7 illustrate examples of defining a value of a service_type field according to an embodiment of the present invention.
  • the value '0x04' of the service_type shown in FIG. 6 means that the service_type is ATSC_data_only_service and that the NRT service can be transmitted through the virtual channel.
  • the value '0x08' of the service_type shown in FIG. 7 means that the service_type is ATSC_nrt_service and that the virtual channel provides NRT service conforming to the ATSC standard.
  • a source_id field (16 bits) indicates the source of the program associated with the virtual channel.
  • the descriptors_length field represents the total length (in bytes) of descriptors for the following virtual channels.
  • the descriptor () field contains zero or more descriptors.
  • the additional_descriptors_length field represents the total length (in bytes) of the following VCT descriptor list.
  • the trailer part is a 32-bit field that guarantees zero output from the registers of the decoder defined in the MPEG-2 system after processing the entire STT section. Contains a cyclic redundancy check (CRC) value.
  • CRC cyclic redundancy check
  • the broadcast station may transmit NRT service data or NRT service signaling data conforming to the ASTC standard through the DST table section shown in FIG. 8.
  • a table_id field (8 bits) is a field for identifying a type of a corresponding table section. Through this field, it can be seen that a corresponding table section is a table section constituting a DST. For example, if the value of this field has 0XCF, the receiver may identify that the corresponding table section is a table section constituting the DST.
  • a section_syntax_indicator field (1 bit) is an indicator defining a section format of a DST.
  • the section format may be, for example, a short-form syntax (0) of MPEG.
  • the private_indicator field (1 bit) indicates whether the shape of the corresponding section follows the private section type and may be set to '1'.
  • a private_section_length field (12 bits) represents the length of the remaining table section after this field. Also, the value of this field does not exceed '0xFFD'.
  • the table_id_extension field (16 bits) is dependent on the table and may be a logical part of the table_id field providing a range of remaining fields.
  • a version_number field (5 bits) indicates the version number of the DST.
  • a current_next_indicator field (1 bit) indicates whether a transmitted DST table section is currently applicable. If this field value is 0, it means that the table does not exist yet and is valid for the next table.
  • a section_number field (8 bits) indicates a section number in sections in which a corresponding table section composes a DST table.
  • the section_number of the first section of the DST is set to '0x00'.
  • section_number is incremented by one each time the section of the DST is increased.
  • the last_section_number field (8 bits) indicates the last section number constituting the DST table (highest section_number).
  • data_service_table_bytes represents a data block constituting the DST, and a detailed structure thereof will be described later.
  • the CRC_32 field is a 32-bit field. Cyclic redundancy check that guarantees zero output from the registers of the decoder defined in the MPEG-2 system after processing the entire DST section. ) Value.
  • semantics of fields including the data_service_table_bytes structure described above is defined as follows.
  • the sdf_protocol_version field (8 bits) describes the version of the Service Description Framework protocol.
  • the application_count_in_section field (8 bits) describes the number of applications listed in the DST section.
  • the compatibility_descriptor () field indicates that the structure includes a DSM-CC compatibility descriptor.
  • the purpose is to signal the compatibility requirements of the application in the receiving platform to determine its ability to use that data service.
  • An app_id_byte_length field (16 bits) describes the number of bytes used to identify an application.
  • the app_id_description field (16 bits) may describe the format and semantics of the following application identification bytes.
  • the value of the app_id_description field may be defined as shown in Table 1 below.
  • Table 1 Value Application Identifier Format 0x0000 DASE application 0x0001-0x7FFF ATSC reserved 0x8000-0xFFFF User private
  • the app_id_byte field (8 bits) represents a byte of an application identifier.
  • a tap_count field (8 bits) describes the number of Tap () structures used by the corresponding application.
  • the protocol_encapsulation field (8 bits) describes the type of protocol encapsulation used to transmit the specific data element referenced by the Tap () field.
  • the value of the protocol_encapsulation field may be defined and used as shown in Table 2 below.
  • the action_type field (7 bits) may indicate an attribute of data referred to by the Tap () field.
  • a resource_location field (1 bit) describes the location of the association_tag field that matches the association_tag value listed in the next Tap structure. If this field is set to '0', the matching association_tag exists in the PMT of the current MPEG-2 program. Unlike this, if it is set to '1', the matching association_tag exists in the DSM-CC Resource Descriptor in the Network Resources Table of the corresponding data service.
  • the Tap () field may include information for finding a data element of an application step included in a communication channel of a lower layer.
  • the association_tag field in the Tap () field may include correspondence information between data elements of an application step.
  • the value of the association_tag field in one Tap structure corresponds to the value of the association_tag field of one association tag descriptor included in the current PMT.
  • the Tap () field may include a specific structure including fields as shown in Table 3 below.
  • the tap_id field (16 bits) is used by the application to identify data elements.
  • the value of tap_id is ranged by the value of app_id_byte fields related to Tap () in DST.
  • the tap_id value is selected by the data service provider.
  • the tap_id value may be used in an application for handling data elements.
  • the Use field (16 bits) is used to specify the communication channel referenced by the association_tag.
  • the association_tag field (16 bits) uniquely identifies either the DSM-CC resource descriptor listed in the Network Resource Table or the data elementary stream listed in the PMT. The value of this field may match the association_tag value of the association_tag_descriptor in the PMT of the data service.
  • the Selector () field describes the specific data element available in the communication channel or data elementary stream referenced by the association_tag field.
  • the selector structure may indicate the protocol required for that data element.
  • a tap_info_length field (16 bits) may describe the number of bytes of descriptors of a field next to the field.
  • the descriptor () field may include descriptor information according to a corresponding descriptor format.
  • An app_info_length field (8 bits) describes the number of bytes of descriptors following the field.
  • the descriptor () field may include descriptor information according to a corresponding descriptor format.
  • An app_data_length field (16 bits) describes the length in bytes of the app_data_byte fields.
  • app_data_byte (8 bits) represents input parameters related to the application and other private data fields in one byte.
  • a service_info_length field (8 bits) describes the number of byte units of the following descriptors.
  • the descriptor () field may include descriptor information according to a corresponding descriptor format.
  • the service_private_data_length field (16 bits) describes the length in bytes of the private fields.
  • the service_private_data_byte field (8 bits) represents a private field in 1 byte.
  • FIG. 9 is a reception system for receiving and servicing an NRT service using an ATSC A / 90 standard for delivering a data broadcast stream and an ATSC A / 92 standard for transmitting an IP multicast stream in a reception system according to the present invention. The method is explained.
  • information on the streams constituting each virtual channel is signaled to the service location descriptor of the VCT or the ES_loop of the PMT.
  • the service type of the VCT is 0x02 (i.e., digital A / V / Data) or 0x04 (i.e., data only), as in FIG. 7 or 8, or 0x08 (i.e., NRT Only). service
  • an NRT service stream may be transmitted through the virtual channel.
  • 0x95 that is, DST transmission
  • the DST is used to identify an NRT application (ie, an NRT service).
  • the App_id_descrption field of the DST defines the format and interpretation of subsequent application identification bytes.
  • '0x0003' is allocated to the App_id_descrption field to identify an NRT application.
  • the next Application_id_byte value becomes a Service ID value of the NRT application.
  • the service ID for the NRT application may have a URI value uniquely identifying the corresponding service worldwide.
  • the PID of the MPEG-2 TS packet divided from the IP datagram of the NRT service signaling channel is found through the tap information. Then, an IP datagram transmitting an NRT service signaling channel can be obtained from MPEG-2 TS packets having PIDs found through the tap information, and NRT service signaling data can be obtained from the obtained IP datagram. .
  • the IP access information of the NRT service signaling channel well-known IP access information, that is, a well-known IP address and a well-known UDP port number may be used.
  • the receiver accesses the IP multicast address (or address range) to receive an IP stream, that is, an IP packet, and extracts NRT service signaling data from the received IP packet.
  • the receiver may receive NRT service data, that is, NRT content items / files, store them in a storage medium or display them on a display device based on the extracted NRT service signaling data.
  • NRT service data that is, NRT content items / files
  • the NRT service may be signaled by using a new value, for example, 0x96, instead of 0x95 in the Stream Type field value of the DST.
  • a new value for example, 0x96
  • the existing receiver may ignore it and guarantee backward compatibility.
  • the data transmission scheme using DST is a standard for transmitting all types of IP datagrams through a digital broadcast stream, and may be inefficient for NRT service. Accordingly, in FIG. 10 and FIG. 11, as an example, NRT service is performed by signaling a PID of a specific stream including IP address information and section data of an IP datagram for an NRT service through data of a DSM-CC addressable section. A method of receiving is shown.
  • the receiver may obtain information that an NRT service stream may be transmitted through the virtual channel. That is, the receiver may map the PID of the virtual channel and the channel number to obtain information on whether the NRT service exists according to the service_type information.
  • the receiver may receive a DSM-CC addressable section including NRT service data through Elementary_PID.
  • the receiver may acquire the PID of the DSM-CC addressable section through the VCT or the PMT.
  • the receiver may obtain an NRT_IP_address_list_descriptor_A () field including an IP address of an NRT service signaling channel corresponding to a PID obtained from a PMT of a corresponding stream or an IP address of a FLUTE session for transmitting NRT service data.
  • the receiver may receive the DSM-CC addressable section data from the IP multicast stream or the IP subnet based on the IP address obtained from the NRT_IP_address_list_descriptor_A () field.
  • the receiver finds the DSM-CC addressable section in which the PID corresponding to the obtained elementray_PID exists in the received DSM-CC addressable section data, thereby searching for specific NRT service (eg, A, B, or C) data.
  • the corresponding IP datagram may be obtained.
  • FIG. 11 illustrates a method of signaling DSM-CC addressable section data using a VCT.
  • the receiver may obtain information that the NRT service stream can be transmitted when the service type (service_type) specified in the VCT is 0X02, 0X04, or 0X08.
  • the receiver may obtain an elementary_PID having a stream type of 0X0D from the service_location_descriptor () field in order to receive the DSM-CC stream.
  • the receiver may obtain an NRT_IP_address_list_descriptor_B () field including the IP address of the NRT service signaling channel corresponding to the obtained elementray_PID or the IP address of the FLUTE session for transmitting the NRT service data from the VCT.
  • the receiver may receive the DSM-CC addressable section data from the IP multicast stream or the IP subnet based on the IP address obtained from the NRT_IP_address_list_descriptor_B () field.
  • the receiver parses the DSM-CC addressable section in which the PID corresponding to the obtained elementray_PID exists from the received DSM-CC addressable section data, thereby receiving a specific NRT service (eg, A, B, or C) obtain an IP datagram including the data.
  • a specific NRT service eg, A, B, or C
  • 0x08 is allocated to the service_type field value in the VCT to indicate that one or more NRT services are transmitted to the corresponding virtual channel.
  • the PSI / PSIP section handler obtains the VCT and PMT from the broadcast signal received on the selected channel.
  • the PSI / PSIP section handler parses the obtained VCT to check whether there is an NRT service. This can be known by checking the value of the service_type field in the virtual channel loop of the VCT. For example, if the service_type field value is not 0x08, the corresponding virtual channel does not transmit the NRT service. In this case, since the virtual channel transmits an existing service (that is, legacy ATSC service), the receiver performs an appropriate operation according to the information included in the virtual channel.
  • the demultiplexer transmits an NRT service.
  • the service location descriptor in the virtual channel loop of the VCT is parsed to extract the PID of the DST.
  • the DST is received using the extracted PID.
  • the receiver checks whether the corresponding service provided through the channel selected from the received DST is an NRT service.
  • the NRT service can be confirmed from the value of the App_id_descrption field.
  • '0x0003' is allocated to the App_id_descrption field to identify an NRT application (ie, an NRT service).
  • NRT application ie, an NRT service.
  • the next Application_ id_byte value becomes a Service ID value of an NRT application (ie, an NRT service). Therefore, after identifying the NRT application (i.e., NRT service) as described above, the service manager or the PSI / PSIP section handler performs a tap to find the PID of the MPEG-2 TS packet divided from the IP datagram of the NRT service signaling channel. Extract. Then, the stream PID including the association_tag of the extracted Tap is extracted from the PMT.
  • the addressable section handler may receive the MPEG-2 TS packets corresponding to the extracted stream PID to decapsulate, ie, remove the MPEG-2 header, and restore the DSM-CC addressable section.
  • the receiver removes the section header and the CRC checksum from the DSM-CC addressable section to recover an IP datagram transmitting an NRT service signaling channel and obtains NRT service signaling data from the recovered IP datagram.
  • the access information of the IP datagram transmitting the NRT service signaling channel is a well-known destination IP address and a well-known destination UDP port number.
  • the receiver accesses the IP multicast address (or address range) to receive an IP stream, that is, an IP packet, and extracts NRT service signaling data from the received IP packet.
  • the receiver may receive NRT service data, that is, NRT content items / files, store them in a storage medium or display them on a display device based on the extracted NRT service signaling data.
  • NRT service data that is, NRT content items / files
  • the above-described NRT service may be provided through a DCD (Dynamic Content Delivery) service.
  • the DCD service is a service that periodically transmits the content to the receiver or when the user desires, and the content at this time is selected by the server according to the information of the receiver.
  • the DCD service supports a point-to-point method and a broadcast method for communication means for content delivery, and the present invention provides the above-described NRT service for OMA BCAST, which is one of the broadcast methods of the DCD service. In one embodiment, the transmission method is performed.
  • the NRT service data can be transmitted through the OMA BCAST-type DCD service.
  • the receiver may acquire DCD channel information for receiving the NRT service, and receive the NRT service through the corresponding DCD channel based on the DCD channel information.
  • the DCD channel information may be included in the above-described NST and transmitted.
  • the receiver may receive the NST and perform DCD bootstrap to obtain DCD channel information.
  • the above-described NST may include DCD channel metadata that can be received through a DCD administrator channel for signaling DCD channel information. Accordingly, the receiver may acquire information and metadata about a channel capable of receiving the NRT service through the NST.
  • NST includes metadata of a channel capable of receiving an NRT service
  • a service access speed may be increased by receiving channel metadata capable of directly receiving an NRT service in the NST without receiving NRT service signaling data based on the service type of the above-described virtual channel.
  • update signaling for channel changes may be performed in real time in a broadcast environment.
  • the access information included in the OMA BCAST SG can be obtained by referring to the NST.
  • the receiver receives the DCD channel metadata based on the DCD channel information included in the NST, and obtains connection information for receiving the NRT service based on the NRT service signaling data and the DCD channel metadata acquired in the NST. can do.
  • the NST may include a list of NRT services linked to other virtual channels and transmit the same. Therefore, in this case, the list information of the NRT service may be transmitted through a specific NRT service signaling channel through the IP layer rather than the PSI or PSIP layer. Thus, in this case backward compatibility with PSI or PSIP can be preserved.
  • the DCD channel information including the DCD channel metadata may be included in the access information of the SG of the OMA BCAST, and the access information may correspond to the NRT service information included in the NST. More specifically, the receiver may obtain NRT service information included in the NST from an access fragment of the OMA BCAST SG. Accordingly, the receiver may obtain information for receiving the NRT service by receiving the NST corresponding to the obtained NRT service information.
  • the NRT service transmitted through the DCD channel can be classified by separately assigning a service category.
  • the service category of the NRT service transmitted through the DCD channel may be identified as 0X0F.
  • the syntax is written in the form of MPEG-2 private section for the sake of understanding, but the format of the data may be in any form.
  • other methods such as signaling in the form of a Session Description Protocol (SDP) and signaling through a Session Announcement Protocol (SAP) may be used.
  • SDP Session Description Protocol
  • SAP Session Announcement Protocol
  • NST describes service information and IP access information in a virtual channel through which NST is transmitted, and NRT broadcast stream information of a corresponding service using NRT_service_id, which is an identifier of an NRT broadcast stream to which each service belongs. Also provide.
  • the NST according to the present embodiment includes description information of each fixed NRT service in one virtual channel, and other additional information may be included in a descriptor area.
  • a table_id field (8 bits) is a field for identifying the type of a corresponding table section. Through this field, it is understood that the corresponding table section is a table section constituting the NST.
  • a section_syntax_indicator field (1 bit) is an indicator defining a section format of an NST.
  • the section format may be, for example, a short-form syntax (0) of MPEG.
  • the private_indicator field (1 bit) indicates whether or not the type of the section follows the private section type and is set to '1'.
  • a section_length field (12 bits) indicates the length of the remaining table section after this field. Also, the value of this field does not exceed '0xFFD'.
  • the table_id_extension field (16 bits) is dependent on the table and becomes a logical part of the table_id field that provides the range of remaining fields.
  • the table_id_extension field includes an NST_protocol_version field.
  • An NST_protocol_version field (8 bits) indicates a protocol version for indicating the NST to which parameters having a structure different from those defined in the current protocol are transmitted. Currently, this field value is zero. If a field value is later specified as a nonzero value, it is for a table with a different structure.
  • a version_number field (5 bits) represents the version number of the NST.
  • a current_next_indicator field (1 bit) indicates whether a transmitted NST table section is currently applicable. If this field value is 0, it means that the table does not exist yet and is valid for the next table.
  • a section_number field (8 bits) indicates the section number in the sections in which the corresponding table section composes the NST table.
  • section_number of the first section of the NRT Service Table (NST) is set to '0x00'. section_number is incremented by one each time the section of the NRT service table is increased.
  • the last_section_number field (8 bits) indicates the last section number constituting the NST table. (Highest section_number)
  • a carrier_frequency field (32 bits) indicates a transmission frequency corresponding to the channel.
  • a channel_TSID field (16 bits) means a unique channel identifier of a broadcast stream in which a corresponding NST section is transmitted.
  • a program_number field (16 bits) indicates a program number associated with a virtual channel.
  • a source_id field (16 bits) indicates the source of the program associated with the virtual channel.
  • a num_NRT_services field (8 bits) indicates the number of NRT services in the NST section.
  • the NST according to the present embodiment provides information about a plurality of fixed NRT services using a for loop.
  • the same field information may be provided for each fixed NRT service.
  • An NRT_service_status field (2 bits) identifies the status of the mobile service.
  • the MSB indicates whether the corresponding mobile service is active (1) or inactive (0)
  • the LSB indicates whether the corresponding mobile service is hidden (1) or not (0).
  • Hidden services are mainly used for proprietary applications, and ordinary receivers ignore them.
  • the SP_indicator field (1 bit) is a field for indicating a service protection applied to at least one of components required to provide a meaningful presentation of a corresponding mobile service.
  • a CP_indicator field (1 bit) indicates whether content protection of a corresponding NRT service is performed. If the CP_indicator field value is 1, it may mean that content protection is applied to at least one of the components required to provide a meaningful presentation of the corresponding NRT service.
  • NRT_service_id field (16 bits) is an indicator uniquely identifying the corresponding NRT service within the range of the corresponding NRT broadcast.
  • the NRT_service_id does not change throughout the service.
  • NRT_service_id for the service may not be used for other non-real-time services until the appropriate time elapses.
  • a Short_NRT_service_name field (8 * 8 bits) indicates a short name of the NRT service. If there is no short name of the NRT service, the field may be filled with a null value (eg, 0x00).
  • An NRT_service_category field (6 bits) identifies the type of service transmitted in the corresponding NRT service.
  • a num_components field (5 bits) indicates the number of IP stream components included in the NRT service.
  • the IP_version_flag field (1 bit) indicates that the source_IP_address field, the NRT_service_destination_IP_address field, and the component_destination_IP_address field are IPv4 addresses when set to '0', and the source_IP_address field, NRT_service_destination_IP_address field, and component_destination_IP_address field when the value is set to '1'. .
  • a source_IP_address_flag field (1 bit) indicates that when a flag is set, a source IP address value for a corresponding NRT service exists to indicate source specific multicast.
  • the NRT_service_destination_IP_address_flag field (1 bit) indicates that there is an NRT_service_destination_IP_address field for providing a default IP address for components of the corresponding NRT service.
  • a source_IP_address field (128 bits) has a corresponding field when source_IP_address_flag is set to 1, but a corresponding field will not exist when source_IP_address_flag is set to 0. If this field is present, this field will contain the source IP address of all IP datagrams carrying components of the NRT service. The limited use of the 128-bit long address in this field is intended to enable future use of IPv6, although the use of IPv6 is currently undefined. Source_IP_address becomes a source IP address of the same server transmitting all channels of the FLUTE session.
  • the NRT_service_destination_IP_address field (128 bits) has a corresponding source_IP_address field when source_IP_address_flag is set to 1, but a corresponding source_IP_address field will not exist when source_IP_address_flag is set to 0. If the corresponding source_IP_address field does not exist, the component_destination_IP_address field will exist for each component in the num_components loop. The limited use of the 128-bit long address in the corresponding source_IP_address field is intended to enable the use of IPv6 in the future, although the use of IPv6 is not defined at present. NRT_service_destination_IP_Address is signaled if there is a destination IP address of the session level of this FLUTE session.
  • the NST provides information about a plurality of components using a for loop.
  • the essential_component_indicator field (1 bit) indicates that the corresponding component is an essential component for the NRT service when the value of the corresponding field is set to 1. Otherwise, it indicates that the component is an optional component.
  • a port_num_count field (6 bits) indicates the number of UDP ports associated with the corresponding UDP / IP stream component. The value of the destination UDP port numbers is increased by one starting from the component_destination_UDP_port_num field value.
  • a component_destination_IP_address_flag field (1 bit) is a flag indicating that a component_destination_IP_address field exists for a corresponding component when it is set to 1.
  • a component_destination_IP_address field (128 bits) has a corresponding field when component_destination_IP_address_flag is set to 1, but a corresponding field will not exist when component_destination_IP_address_flag is set to 0. If this field is present, this field will contain the source IP address of all IP datagrams carrying components of the NRT service. The limited use of the 128-bit long address in this field is intended to enable future use of IPv6, although the use of IPv6 is currently undefined.
  • a component_destination_UDP_port_num field (16 bits) indicates a destination UDP port number for the corresponding UDP / IP stream component.
  • a num_component_level_descriptors field (4 bits) provides the number of descriptors that provide additional information for the corresponding IP stream component.
  • the component_level_descriptors field identifies one or more descriptors that provide additional information for the corresponding IP stream component.
  • a num_NRT_service_level_descriptors field (4 bits) indicates the number of NRT service level descriptors for a corresponding service.
  • NRT_service_level_descriptor identifies one or more descriptors that provide no additional information for the NRT service.
  • the specific service type for the NRT service may be informed.
  • the specific service type may include, for example, a portal service that provides web content, a push VOD, and an A / V download.
  • a num_virtual_channel_level_descriptors field (4 bits) describes the number of virtual channel level descriptors for the corresponding virtual channel.
  • virtual_channel_level_descriptor () represents a descriptor that provides additional information about the virtual channel described by the corresponding NST.
  • the NRT service is transmitted through FLUTE, and access information on the NST table is connected with FLUTE session information as follows.
  • Source_IP_address is a source IP address of the same server that transmits all channels of the FLUTE session.
  • NRT_service_destination_IP_Address is signaled when there is a destination IP address of the session level of this FLUTE session.
  • the component may be mapped to a channel in the FLUTE session and may signal a separate destination IP address for each channel (different from the IP address signaled in the session unit) through the component_destination_IP_address.
  • the destination port number may be signaled through component_destination_UDP_port_num and the number of destination ports starting from component_destination_UDP_port_num may be additionally specified through port_num_count.
  • a plurality of channels may be configured for one destination IP address.
  • one component may designate a plurality of channels. In general, however, it is desirable to distinguish channels by their destination IP addresses. Here, it can be seen that one channel is mapped to one component.
  • Content items / files for the NRT service are transmitted through FLUTE and signal corresponding FLUTE session information using the access information on the NST table.
  • FIG. 14 illustrates a bit stream syntax of an NRT_component_descriptor (MH_component_descriptor) configured according to an embodiment of the present invention.
  • NRT_component_descriptor () will appear in the component descriptor loop of each component of each NRT service in the NST. And all the parameters in the descriptor correspond to the parameters used for the components of the NRT service.
  • a component_type field (7 bits) identifies an encoding format of a component.
  • the identification value may be one of values assigned for payload_type of the RTP / AVP stream.
  • the identification value may also be a dynamic value in the range of 96 to 127.
  • the values of this field correspond to the values in payload_type in the RTP header of the IP stream transmitting the corresponding components for the components constituting the media transmitted through the RTP.
  • component_type field in the range of 43 to 71 are defined in future versions of the standard.
  • the component_type 38 defined for the FLUTE component may be used by ATSC to further signal the parameters described below for the FLUTE session, and a new NRT value of 43, which is not yet assigned, may be used. Can also be defined and used as component_type for transmission.
  • a num_STKM_streams field (8 bits) identifies the number of STKM streams associated with that component.
  • the STKM_stream_id field (8 bits) identifies the STKM stream with the keys to decrypt the corresponding protected component obtained.
  • the STKM_stream_id field is referred to in the component descriptor for the STKM stream.
  • the NRT_component_data (component_type) field provides at least one of encoding parameters and other parameters necessary for representing the corresponding component.
  • the structure of the NRT_component_data element is determined by the value of the component_type field.
  • the File Delivery Table (FDT) of FLUTE sessions is used to deliver item lists of all content items and provide the size, data type and other information of the items related to obtaining the items.
  • the present invention obtains information for accessing a FLUTE session for transmitting the corresponding content using the NST to receive the selected content from the SG configured using the NRT-IT.
  • the present invention maps the information on the file transmitted through the FLUTE session with the information of the content item of the NRT-IT. In this case, identification of the service including the selected content item is resolved through the NRT_service_id of the NST.
  • the NRT service is transmitted through FLUTE, and access information on the NST table is connected with FLUTE session information as follows.
  • Source_IP_address becomes the source IP address of the same server that transmits all channels of the FLUTE session.
  • NRT_service_destination_IP_Address is signaled when there is a destination IP address of the session level of this FLUTE session.
  • a component may be mapped to a channel in a FLUTE session and may signal a separate destination IP address (different from the IP address signaled on a session basis) through each component_destination_IP_address.
  • the destination port number may be signaled through component_destination_UDP_port_num and the number of destination ports starting from component_destination_UDP_port_num may be additionally specified through port_num_count.
  • a plurality of channels may be configured for one destination IP address.
  • one component may designate a plurality of channels. However, in general, it is recommended to distinguish the channel by the destination IP address. In this case, one channel is mapped to one component.
  • Component_attribute_byte may be used to signal an additional attribute of a component configuring a session. Additional parameters necessary for signaling a FLUTE session may be signaled through this.
  • parameters are required to signal a FLUTE session, and these parameters include mandatory parameters that are absolutely necessary and parameters that are optionally necessary in connection with the FLUTE session.
  • the mandatory parameters include the source IP address, the number of channels in the session, the destination IP address and port number for each channel in the session. for each channel in the session, the Transport Session Identifier (TSI) of the session, and the start time and end time of the session parameters.
  • TTI Transport Session Identifier
  • Optional parameters related to this may include FEC Object Transmission Information, Some information that tells receiver in the firstplace, that the session contains files that are of interest and Bandwidth specification parameters are included.
  • the number of channels of the session may be explicitly provided, or may be obtained by summing the number of streams constituting the session.
  • the start time and end time of the session the source IP address, the destination IP address and port number of each channel in the session through the NST and component_descriptor.
  • the parameters of the address and port number for each channel in the session, the Transport Session Identifier (TSI) of the session, and the number of channels in the session may be signaled.
  • TTI Transport Session Identifier
  • FIG. 15 illustrates a bit stream syntax of an NRT component descriptor to which NRT_component_data configured according to an embodiment of the present invention belongs.
  • One NRT service may be included in multiple FLUTE sessions. Each session may be signaled using one or more NRT component descriptors depending on the IP addresses and ports used for the session.
  • the TSI field (16 bits) indicates the TSI of the FLUTE session.
  • the session_start_time field indicates the time at which the FLUTE session starts. If the value of this field is all 0, the session can be interpreted as already started.
  • the session_end_time field indicates the time when the FLUTE session ends. If the values of all of the fields are 0, the session may be interpreted as continuing indefinitely.
  • a tias_bandwidth_indicator field (1 bit) indicates flags including transport independent application specific (TIAS) bandwidth information. If the TIAS bandwidth field is indicated as present, the corresponding bit must be set to 1, and if the TIAS bandwidth field is indicated as not present, the corresponding bit must be set to 0.
  • TIAS transport independent application specific
  • the as_bandwidth_indicator field (1 bit) is flags including application specific (AS) bandwidth information. If the AS bandwidth field is present, the corresponding bit must be set to 1. To indicate that the AS bandwidth field is not present, the corresponding bit must be set to 0.
  • AS application specific
  • An FEC_OTI_indicator field (1 bit) indicates whether FEC object transmission information (OTI) information is provided.
  • the tias_bandwidth field represents TIAS maximum bandwidth.
  • the as_bandwidth field has a value of AS maximum bandwidth.
  • the FEC_encoding_id field represents an FEC encoding ID used in the corresponding FLUTE session.
  • the FEC_instance_id field represents an FEC instance ID used in a corresponding FLUTE session.
  • This FLUTE component descriptor may be delivered through a Component_level_descriptor loop of NST.
  • TSI, session_start_time, session_end_Time, etc. which are session level parameters, should be signaled only once, so that only one component of the components of multiple channels may transmit the FLUTE component descriptor through the Component_level_descriptor loop.
  • FIG. 16 illustrates a bitstream syntax of an NRT-IT section for signaling an NRT application configured according to an embodiment of the present invention.
  • the information provided by the NRT-IT may include the title of the content (eg the name of the downloadable program), the downloadable time and information such as content advisories, the availability of caption services, content identification and other meta.
  • Contains data One item of content may consist of one or more files. For example, audio / video clips can be played back as JPEG thumbnail images that can be used for screen display.
  • An instance of an NRT-IT may contain data corresponding to a randomly defined period of time or may describe NRT content starting at a specified time and ending in an indefinite future.
  • Each NRT-IT represents a start time and a duration that can be indefinite.
  • Each NRT-IT instance can be divided into up to 256 sections. Each section contains information of multiple content items, but the information of a particular content item cannot be divided and stored in two or more sections.
  • NRT_information_table_section () in availability order.
  • last_section_number is greater than 0 (meaning that the NRT-IT has been sent to multiple sections)
  • all content item descriptions in a particular section other than the first section will be matched with the first availability of the content item description in the next section. Will have the same or higher initial availability.
  • Each NRT-IT identifies an NRT service associated with a particular value of service_id that is valid for a particular virtual channel for that period.
  • the table_id field (8 bits) is set to 0xTBD to identify that the table section is a table section constituting the NRT-IT.
  • a service_id field (16 bits) describes a service_id field associated with an NRT service showing a content item described in the section.
  • the NRT_IT_version_number field (5 bits) is defined as a set in one or more NRT_content_table_section () with common values for the service_id, current_next_indicator, protocol_version, and time_span_start fields. Identifies the version number of the NRT-IT instance. The version number is increased by 1 modulo 32 when the field of the NRT-IT instance changes.
  • protocol_version field (8 bits) is set to zero.
  • the function of protocol_version allows table types with parameters that may be structurally different from those defined in the current protocol in the future. Currently the only valid value for protocol_version is 0. A nonzero value in protocol_version is used in future versions of the standard to recognize structurally different tables.
  • time_span_start field (32 bits) shows the start of the instance period of the NRT-IT expressed as the number of GPS seconds since 00:00:00 UTC, January 6, 1980.
  • the time of day of time_span_start should be in minutes 00 of the hour.
  • the value 0 of time_span_start shows the duration of the NRT-IT instance started from the past.
  • the value of time_span is the same for each section of a multi-sectioned NRT-IT instance.
  • the values of time_span_start and time_span_length are set so as not to overlap with other NRT-IT instances of the IP subnet in a specified period.
  • time_span_length field (11 bits) identifies the number of minutes started at the time recognized in time_span_start covered by the instance of the NRT-IT. Once set, the value of time_span_length is not changed from the value of given time_span_start. If the value of time_span_length is 0, the NRT-IT instance covers all times started at time_span_start in the indefinite future. When the value of time_span_start is 0, time_span_length is meaningless.
  • time_span_start is the same for each section of the multi-sectioned NRT-IT instance.
  • the values of time_span_start and time_span_length are set so as not to overlap with other NRT-IT instances of the IP subnet in a specified period.
  • a num_items_in_section field (8 bits) indicates the number of content items described in the NRT-IT section.
  • a content_linkage field (16 bits) indicates an identification number of content within a range of 0x0001 to 0xFFFF. The value 0x0000 is not used.
  • the content_linkage combines the metadata of the NRT-IT with one or more files of two linkage functions: FLUTE FDT associated with the NRT service and also forms an identifier for Text Guaranteement in Text FragmentTable (TF_id).
  • the value of the content_linkage field corresponds to the value of the FDTCotent-Linkage element or the value of the File-Content-Linkage element in the FLUTE FDT of each file associated with the content item.
  • the priority rule is applied when matching each content_linkage value including the corresponding content linkage element in the FLUTE FDT.
  • the TF_availiable flag is set to '1' if the Text Fragment exists in the Text Frangment Table of the service signaling channel. If a Text Fragment is not included in the service signaling channel for the content item, the value of the TF_availiable field is set to '0'.
  • the low_lantency flag is set to '1', the content is valid in the current digital transmission with a sufficiently low latency that the number of times the user should try when waiting. If set to '0', the retrieval delay is longer and the user interface suggests later viewing to the user.
  • playback_length_in_seconds (20 bits) is an integer representing the playback time of the content in seconds. Content containing text and / or still images is represented by the value '0'. For content including audio or audio / video content, playback_length_in_seconds indicates the playback time of the audio or audio / video content.
  • the content_length_included flag When the content_length_included flag is set to '1', it indicates that the content_length field is present in the repetition of the 'for' loop. If set to '0', it indicates that the content_length field does not exist in the repetition of the 'for' loop.
  • the playback_delay_included flag When the playback_delay_included flag is set to '1', the playback_delay field indicates that it is present in an iteration of a 'for' loop. If set to '0', the playback_delay field indicates that it is not present in the iteration of the 'for' loop.
  • the expiration field indicates that it exists in an iteration of a 'for' loop. If set to '0', the expiration field does not exist in the iteration of the 'for' loop.
  • the duration (12 bit) field indicates the scheduled cycle time of the carousel, in minutes, that includes the referenced content item in the range of 1 to 2880.
  • the receiver uses a duration parameter that determines the amount of time to capture the referenced content.
  • playback_delay (20 bits) is represented by the number of seconds following the receipt of the first byte before playing in the associated content, while buffering the incoming stream. A value of 0 indicates that playback has started immediately. If playback_delay is not set, the receiver retrieves the complete file or the file before playback.
  • the expiration field (32 bits) represents an expiration time expressed as the number of GPS seconds since 00:00:00 UTC, January 6, 1980. After expiration, the content is deleted from memory. If no expiration time is set, the receiver uses its own method of managing memory resources.
  • a content_name_length_ field (8 bits) indicates the length (byte unit) of content_name_text.
  • the content_name_text () field represents a content item title in a format of a multi-string structure.
  • a content_descriptors_length field (12 bits) indicates the total length (in bytes) of the content_descriptor that provides additional information about the content level.
  • the content_descriptor is a descriptor applied to each content item separately.
  • descriptor_length (10 bits) represents the total length of the descriptor (byte unit).
  • the descriptor is a descriptor generally applied to all content items described in the current NRT-IT section.
  • NCT section 17 is a diagram illustrating an embodiment of a bit stream syntax structure for an NCT section (NRT_content_table_section) according to the present invention. A detailed description of each field of the NCT section is as follows.
  • a table_id field (8 bits) is an identifier of a table, and an identifier for identifying an NCT may be set.
  • a section_syntax_indicator field (1 bit) is an indicator that defines the section format of the NCT.
  • the private_indicator field (1 bit) indicates whether the NCT follows the private section.
  • a section_length field (12 bits) indicates a section length of NST.
  • An NRT_channel_id field (16 bits) indicates a value that can uniquely identify an NRT service including content described in the NCT.
  • a version_number field (5 bits) represents the version number of the NCT.
  • a current_next_indicator field (1 bit) indicates whether information included in the corresponding NCT section is currently applicable information or future applicable information.
  • a section_number field (8 bits) indicates a section number of the current NCT section.
  • the last_section_number field (8 bits) indicates the last section number of the NCT.
  • a protocol_version field (8 bits) indicates the protocol version to allow NCT to transfer parameters with different structures than those defined in the current protocol (An 8-bit unsigned integer field whose function is toallow, in the future, this NRT Content Table to carry parameters that may be structured differently than those defined in the current protocol.At present, the value for the protocol_version shall be zero.Non-zero values of protocol_version may be used by a future version of this standard to indicate structurally different tables.)
  • a num_contents_in_section field (8 bits) indicates the number of contents described in this NCT. In this case, the number of contents indicates the number of contents (or files) transmitted through a virtual channel specified by source_id.
  • a 'for' loop (or a content loop) is performed as many as the number of contents corresponding to the num_contents_in_section field value, thereby providing detailed information of the corresponding content for each content.
  • a content_version field indicates a version number for content (or file) having a specific content_id value. That is, suppose that the content_id of the content previously received and stored by the receiver is 0x0010, and the same content, that is, the content having the content_id value of 0x0010 is transmitted. In this case, when the content_version field value is changed, newly announced content is received through the NCT to update or replace previously stored content.
  • the content_version field value means a serial number indicating a version of a release, but may actually directly represent published (released) time. In this case, when the publish time is hard to be expressed as the content_version field, a new field that can express the published (released) time may be used.
  • a content_id field (16 bits) indicates an identifier that can uniquely identify the content (or file).
  • a content_available_start_time field (32 bits) and a content_available_end_time field (32 bits) indicate a start time and an end time of a FLUTE session for transmitting the content.
  • ETM_location field (2 bits) describes the presence and location of an extended text message (ETM).
  • a content_length_in_seconds field (30 bits) indicates the actual playback time of the corresponding content in seconds when the content (or file) is an A / V file.
  • a content_size field (48 bits) indicates the size of the content (or file) in bytes.
  • a content_delivery_bit_rate field (32 bits) indicates a bit rate for transmitting the content (or file) and indicates a target bit rate. That is, it indicates how much bandwidth to allocate when the service provider or broadcasting station transmits the corresponding content. Therefore, when the receiver uses content_size and content_delivery_bit_rate, the minimum time required to receive the corresponding content (or file) can be known. That is, the time taken to receive the content can be estimated and the corresponding information can be provided to the user. The minimum reception time is obtained by calculating (conent_size * 8) / (content_delivery_bit_rate), and the unit is seconds.
  • a content_title_length field (8 bits) indicates the length of content_title_text () in bytes. Using this field, the receiver can know how many bytes of data should be read in order to correctly obtain content_title_text () information.
  • the content_title_text () field indicates a content title in the format of a multiple string structure.
  • the receiver may acquire configuration information of NRT content / file using the NCT and provide a guide for NRT content / file based on the obtained configuration information of NRT content / file.
  • the access information of the FLUTE session for transmitting the content / file selected from the guide may be obtained from the NST, and the selected content may be received using the obtained FLUTE session access information.
  • the present invention may transmit container information, encoding information, and a decoding parameter of a media object, which are essential for the rendering of content / files constituting an NRT service, in the NCT. Therefore, the receiving system extracts container information, encoding information, and decoding parameters of the media object, which are essential for the rendering of the corresponding content, for each content and can be used to render the corresponding content.
  • FIG. 18 illustrates an embodiment of a bit stream syntax structure of an SMT section that provides signaling information about NRT service data.
  • the SMT describes signaling information (or signaling information of NRT service) and IP access information of a mobile service in an ensemble in which the SMT is transmitted.
  • the SMT also provides broadcast stream information of the corresponding service using Transport_Stream_ID, which is an identifier of a broadcast stream to which each service belongs.
  • Transport_Stream_ID is an identifier of a broadcast stream to which each service belongs.
  • the SMT according to an embodiment of the present invention includes description information of each mobile service (or NRT service) in one ensemble, and other additional information may be included in a descriptor area.
  • the SMT section may be transmitted in the form of an IP stream in an RS frame.
  • RS frame decoders of a receiver to be described later decode an input RS frame and output the decoded RS frame to a corresponding RS frame handler.
  • Each RS frame handler divides the input RS frame into row units to form an M / H TP and outputs the M / H TP handler.
  • a table_id field (8 bits) is a field for distinguishing a type of table, and this shows that the table section is a table section in SMT (table_id: An 8-bit unsigned integer number that indicates the type of table section being defined in Service Map Table (SMT).
  • SMT Service Map Table
  • a section_syntax_indicator field (1 bit) is an indicator defining a section format of an SMT.
  • the section format may be, for example, a short-form syntax ('0') of MPEG (section_syntax_indicator: This 1-bit field shall be setto '0' to always indicate that this table is derived from the "short" form of the MPEG-2 privatesection table).
  • the private_indicator field (1 bit) indicates whether the SMT follows the private section (private_indicator: This1-bit field shall be set to '1').
  • section_length A 12-bit field.It specifies the number of remaining bytes this table section immediately following this field.The value in this field shall not exceed 4093 (0xFFD)).
  • a table_id_extension This is a 16-bit field and is table-dependent.It shall be considered to be logically part of the table_id field providing the scope for the remaining fields).
  • the table_id_extension field includes an SMT_protocol_version field.
  • SMT_protocol_version An 8-bit unsigned integer field whose function is to allow, in the the SMT_protocol_version field (8 bits) indicates the protocol version to allow SMT to transmit parameters whose parameters differ from those defined in the current protocol. future, this SMT to carry parameters that may be structured differently than those defined in the current protocol.At present, the value for the SMT_protocol_version shall be zero.Non-zero values of SMT_protocol_version may be used by a future version of this standard to indicate structurally different tables).
  • An ensemble_id field (8 bits) is an ID value associated with a corresponding ensemble, and values of '0x00' to '0x3F' may be allocated. The value of this field is preferably derived from parade_id of TPC data. If the ensemble is transmitted through the primary RS frame, the most significant bit (MSB) is set to '0' and the remaining 7 bits are used as the parade_id value of the parade. Meanwhile, if the ensemble is transmitted through the secondary RS frame, the most significant bit (MSB) is set to '1' and the remaining 7 bits are used as the parade_id value of the parade (ensemble_id: This 8-bit unsigned integer).
  • this field in the range 0x00 to 0x3F shall be the Ensemble ID associated with this Ensemble.
  • the value of this field shall be derived from the parade_id carried from the baseband processor of physical layer subsystem, by using the parade_id of the associated Parade for the least significant 7 bits, and using '0' for the most significant bit when the Ensemble is carried over the Primary RS frame, and using '1' for the most significant bit when the Ensemble is carried over the Secondary RS frame).
  • a version_number field (5 bits) represents a version number of the SMT.
  • the section_number field (8 bits) indicates the number of the current SMT section (section_number: This 8-bit field shall give the section number of this NRT Service Signaling table section.
  • the section_number of the first section in an NRT Service Signaling table shall be 0x00.
  • the section_number shall be incremented by 1 with each additional section in the NRT Service Signaling table).
  • the last_section_number field (8 bits) indicates the last section number constituting the SMT table.
  • last_section_number This 8-bit field shall give the number of the last section (i.e., the section with the highest section_number) of the Service Signaling table of which this section is a part).
  • a num_services field (8 bits) indicates the number of services in the SMT section. (num_services: This 8 bit field specifies the number of services in this SMT section). At least one mobile service may be included and received as an ensemble including the SMT, at least one NRT service may be included and received, or both mobile service and NRT service may be included. If only ensemble NRT services including SMT are transmitted and transmitted, the number of NRT services included in the SMT may be indicated.
  • a 'for' loop (or a service loop) is performed as many as the number of services corresponding to the num_services field value, thereby providing signaling information for a plurality of services. That is, signaling information of the corresponding service is displayed for each service included in the SMT section.
  • the service may be a mobile service or an NRT service.
  • the following field information may be provided for each service.
  • the service_id field (16 bits) indicates a value that uniquely identifies this service (A 16-bit unsigned integer number that shall uniquely identify this service within the scope of this SMT section.).
  • the service_id field value of one service does not change while the service is maintained. To avoid confusion at this point, if a service terminates, the service_id field value of that service may not be used until a certain amount of time has elapsed. , it is recommended that if a service is terminated, then the service_id for the service should not be used for another service until after a suitable interval of time has elapsed).
  • the service_id will identify the NRT service.
  • the Multi_ensemble_service field (2 bits) identifies whether the service is transmitted through one or more ensemble.
  • this field only identifies whether a service is represented as part of a service transmitted over that ensemble. In other words, if the service is an NRT service, the field identifies whether the NRT service is transmitted through one or more ensemble (multi_ensemble_service: A two-bit enumerated field that shall identify whether the Service is carried across more than one Ensemble. , this field shall identify whether or not the Service can be rendered only with the portion of Service carried through this Ensemble).
  • multi_ensemble_service A two-bit enumerated field that shall identify whether the Service is carried across more than one Ensemble. , this field shall identify whether or not the Service can be rendered only with the portion of Service carried through this Ensemble).
  • the service_status field (2 bits) identifies the state of the corresponding service.
  • the MSB indicates whether the service is active ('1') or inactive ('0'), and the LSB indicates whether the service is hidden ('1') or not ('0').
  • the MSB of the service_status field indicates whether the corresponding NRT service is active ('1') or inactive ('0'), and the LSB indicates that the NRT service is hidden ('1'). Indicates whether or not ('0').
  • An SP_indicator field (1 bit) indicates whether a service is service protected. If the SP_indicator field value is 1, service protection is applied to at least one of the components required to provide a meaningful presentation of the service (A 1-bit field that indicates, when set to 1, service protection is applied). to at least one of the components needed to provide a meaningful presentation of this Service).
  • the short_service_name_length field (3 bits) indicates the length of the short service name described in the short_service_name field in bytes.
  • the short_service_name field indicates the short name of the service (short_service_name: The short name of the Service, each character of which shall be encoded per UTF-8 [29] .When there is an odd number of bytes in the short name, the second byte of the last of the byte pair per the pair count indicated by the short_service_name_length field shall contain 0x00). For example, if the service is a mobile service, the short name of the mobile service is displayed, and if the service is an NRT service, the short name of the NRT service is displayed.
  • a service_category field (6 bits) identifies the type category of the corresponding service. If the value of this field is set to a value indicating "informative only", the value of this field is treated as an informative description of the category of the service. And the receiver is required to examine the component_level_descriptors () field of the SMT to identify the actual category of the received service. For services with video and / or audio components they have an NTP time base component.
  • the value of the service_category field has a value of '0x0E', for example, this indicates that the service is an NRT service.
  • signaling information of a service currently described in the SMT section is signaling information of an NRT service.
  • a num_components field (5 bits) indicates the number of IP stream components in the corresponding service (num_components: This 5-bit field specifies the number of IP stream components in this Service).
  • the IP_version_flag field (1 bit) indicates that the source_IP_address field, the service_destination_IP_address field, and the component_destination_IP_address field are IPv6 addresses when set to '1', and that the source_IP_address field, service_destination_IP_address field, and component_destination_IP_address field are IPv4 addresses when set to '0'.
  • IP_version_flag A 1-bit indicator, which when set to '0' shall indicate that source_IP_address, service_destination_IP_address, and component_destination_IP_address fields are IPv4 addresses. The value of '1' for this field is reserved for possible future indication that source_IP_address, service_destination_IP_address, and component_destination_IP_address fields are for IPv6.Use of IPv6 addressing is not currently defined).
  • source_IP_address_flag A 1-bit Boolean flag that shall indicate, when set, that a source IP address value for this Service is present to indicate a source specific multicast.
  • service_destination_IP_address_flag A 1-bit Boolean flag that indicates, when set to '1). ', that a service_destination_IP_address value is present, to serve as the default IP address for the components of this Service).
  • the source_IP_address field (32 or 128 bits) needs to be interpreted when the source_IP_address_flag is set to '1', but does not need to be interpreted when the source_IP_address_flag is not set to '0'.
  • source_IP_address_flag When source_IP_address_flag is set to '1' and the IP_version_flag field is set to '0', this field indicates a 32-bit IPv4 address indicating a source of the corresponding virtual channel. If the IP_version_flag field is set to '1', this field indicates a 32-bit IPv6 address indicating the source of the corresponding virtual channel (source_IP_address: This field shall be present if the source_IP_address_flag is set to '1' and shall not be present if the source_IP_address_flag is set to '0'.If present, this field shall contain the source IP address of all the IP datagrams carrying the components of this Service.The conditional use of the 128 bit-long address version of this field is to facilitate possible use of IPv6 in the future, although use of IPv6 is not currently defined).
  • the Source_IP_address field is a source IP address of the same server transmitting all channels of the FLUTE session.
  • the service_destination_IP_address field (32 or 128 bits) needs to be interpreted when the service_destination_IP_address_flag is set to '1', but does not need to be interpreted when the service_destination_IP_address_flag is set to '0'. If service_destination_IP_address_flag is set to '1' and the IP_version_flag field is set to '0', this field indicates a 32-bit destination IPv4 address for the corresponding virtual channel.
  • service_destination_IP_address_flag is set to '1' and the IP_version_flag field is set to '1', this field indicates a 64-bit destination IPv6 address for the corresponding virtual channel. If the service_destination_IP_address cannot be resolved, the component_destination_IP_address field in the num_components loop must be resolved, and the receiving system must use component_destination_IP_address to access the IP stream component (service_destination_IP_address: This field shall be present if the service_destination_IP set_1_address_flag 'and shall not be present if the service_destination_IP_address_flag is set to' 0'.If this service_destination_IP_address is not present, then the component_destination_IP_address field shall be present for each component in the num_components loop. The conditional use of the 128 bit-long address version of this field is to facilitate possible use of
  • the SMT according to the present embodiment provides information about a plurality of components by using a for loop.
  • a 'for' loop (or a component loop) is performed as many as the number of components corresponding to the num_components field value, thereby providing access information for a plurality of components. That is, it provides connection information of each component included in the service. In this case, the following field information may be provided for each component.
  • one component corresponds to one FLUTE session.
  • the essential_component_indicator field (1 bit), if set to '1', indicates that the corresponding component is an essential component for a mobile service. Otherwise_component_indicator: A one-bit indicator which, when set to '1' shall indicate that this component is an essential component for the service.Otherwise, this field indicates that this component is an optional component).
  • the component_destination_IP_address_flag field (1 bit) is a flag indicating that the component_destination_IP_address field exists for the component if it is set to '1' (component_destination_IP_address_flag: A 1-bit Boolean flag that shall indicate, when set to '1' that the component_destination_IP_address is present for this component).
  • a port_num_count field (6 bits) indicates the number of UDP ports associated with the corresponding UDP / IP stream component.
  • the destination UDP port number is incremented by 1 starting from the value of the destination_UDP_port_num field.
  • the destination UDP port number is incremented by two starting from the value of the destination_UDP_port_num field, because this field shall indicate the number of destination UDP ports associated with this UDP / IP stream component.
  • the values of the destination UDP port numbers shall start from the component_destination_UDP_port_num field and shall be incremented by one, except in the case of RTP streams, when the destination UDP port numbers shall start from the component_estination_UPD_port_num field and shall be incremented by two, to allow for the RTCP streams associated with the RTP streams).
  • a destination_UDP_port_num field (16 bits) indicates a destination UDP port number for the corresponding IP stream component.
  • the value of destination_UDP_port_num is an even number, and the next higher value indicates the destination UDP port number of the associated RTCP stream (component_destination_UDP_port_num: A 16-bit unsigned integer field, that represents the destination UDP port number for this UDP / IP stream component.
  • component_estination_UDP_port_num shall be even, and the next higher value shall represent the destination UDP port number of the associated RTCP stream).
  • component_destination_IP_address field 32 or 128 bits
  • this field indicates a 32-bit destination IPv4 address for the corresponding IP stream component.
  • IP_version_flag field is set to '1'
  • this field indicates a 128-bit destination IPv6 address for the corresponding IP stream component (component_destination_IP_address: This field shall be present if the component_destination_IP_address_flag is set to '1' and shall not be present if the component_destination_IP_address_flag is set to '0'.
  • the destination address of the IP datagrams carrying this component of the M / H Service shall match the address in this field.
  • the destination address of the IP datagrams carrying this component shall match the address in the M / H_service_destination_IP_address field.
  • a num_component_level_descriptors field (4 bits) indicates the number of descriptors that provide additional information of the component level.
  • the component_level_descriptor () is included in the component loop as many as the number corresponding to the num_component_level_descriptors field value, thereby providing additional information about the component.
  • a num_service_level_descriptors field (4 bits) indicates the number of descriptors that provide additional information of the corresponding service level.
  • Service_level_descriptor () is included in the service loop as many as the number corresponding to the num_service_level_descriptors field value to provide additional information about the service. If the service is a mobile service, additional information about the mobile service is provided. If the service is an NRT service, additional information about the NRT service is provided.
  • a num_ensemble_level_descriptors field (4 bits) is the number of descriptors that provide additional information of the ensemble level.
  • Ensemble_level_descriptor () is included in the ensemble loop as many as the number corresponding to the num_ensemble_level_descriptors field value, thereby providing additional information about the ensemble.
  • component_descriptor () may also be provided as component_level_descriptors () in the SMT of FIG. 18.
  • the component_descriptor () is used as one of the component level descriptor component_level_descriptors () of the SMT, and describes additional signaling information of the corresponding component.
  • the signaling information necessary for receiving the corresponding FULTE session in the mobile NRT service may also be provided using the component descriptor of FIG. 14.
  • the component_data (component_type) field provides data for FLUTE file delivery as shown in FIG. Since description of each field of FIG. 14, FIG. 15 was mentioned above, it abbreviate
  • FIG. 19 illustrates an FDT schema for mapping a file and content_id according to an embodiment of the present invention
  • FIG. 20 illustrates an FDT schema for mapping a file and content_id according to another embodiment of the present invention.
  • the FDT instant level entry file designation method is represented.
  • NRT content has multiple files but each file has no representation, making it difficult to find related files of NRT content.
  • FIGS. 19 and 20 illustrate inserting content_id into the FDT in each file.
  • the FDT instance level means a level including a definition part of the common attributes of all files declared in the FDT, and the FDT file level includes definitions of individual attributes in each file. It can be used to mean a level.
  • the receiver identifies whether the service transmitted through the channel is an NRT service based on SMT.
  • the receiver also identifies the content item and file of the corresponding NRT service.
  • the receiver can identify the file and the content item in the NRT service, but the receiver cannot match the file of the content item because there is no information about the file of the content item. Thus, the receiver cannot process the received NRT service.
  • the present invention may provide a method for identifying whether a content item is associated.
  • the method will show what files exist in the content item.
  • the receiver can properly process the received NRT service.
  • the method may designate based on the FDT information in the FLUTE session by transmitting the NRT service. For example, each file that constructs a content item is identified based on the content-location and TOI fields specified in the FLUTE session.
  • the content_id in the FDT is matched with the content identifier (content_id) of the NCT or the content identifier of the content fragment in the OMB BCAST SG.
  • the part indicated by 1 denotes a content identifier at the FDT-Instance level, where the content identifier declared is all files declared in the FDT-Instance. Is given to. Of course, this information may be overridden by assigning a new content identifier at the file level. Alternatively, if a specific file belongs to a content item other than the content item defined at the FDT-Instance level, this may be indicated by giving a file level content_id to be described below. In this embodiment, content_id is expressed using 16 bits.
  • the part marked 2 declares the content_id at the file level. If the file contained in the FDT instance belongs to a different content item, this method is used for each file to identify which content item and all files in the content to which entry. Signal whether it belongs.
  • Number 3 is a method for notifying whether each file is an entry file for each file.
  • the file that corresponds to the root file that must be played first among the files that make up the content item or must be accessed first to access the content item is called an entry file.
  • the entry attribute may be omitted and the default value is false, indicating that the file is not an entry file.
  • "entry” is the head of the file that needs to be processed to execute the file. . For example, "index.html” may be "entry”.
  • the entry file can be set to "true” and other files can be set to "false”. Through the entry file, duplication of transmitting the same file can be effectively controlled. Once the file has downloaded, there is no need to download it to another or separate instance because the entry file points to a file of content for another reference.
  • a particular file signals the entry in a group related to the file level to serve as an entry in a particular group but may fail in other groups.
  • the following two methods can be considered to indicate whether an entry file is provided when a content identifier is assigned at the FDT-instance level.
  • the content identifier overlaps at the FDT-Instance level and the file level. It may have a structure. In other words, one of the file-level and the FDT-instance level may specify the content_id, but when the other content_id is specified together at the file-level and the FDT-instance level, the content_id of the file-level has priority.
  • the FDT-Content-ID-Type is separately defined for the FDT-instance level content identifier and extended to include the content location of the entry file as indicated by 2.
  • the entry level is defined by its content_id. For example, it shows which entry file is in each content_id.
  • the overlapping signaling of content-location may be a disadvantage, but it may be advantageous that the entry file configuration information may be directly obtained for each content item.
  • 21 is a flowchart illustrating a method of operating a receiver according to an embodiment of the present invention.
  • a receiver receives NRT service signaling data through an NRT service signaling channel, displays NRT guide information using the received NRT service signaling data, and displays selected NRT content for the selected NRT content.
  • the NRT service data may be received to provide an NRT service.
  • a channel is selected by the user (S1000). Then, the physical transport channel is tuned according to the selected channel.
  • the VCT and the PMT are obtained from the broadcast signal received through the tuned physical transport channel (S1010).
  • the acquired TVCT (VCT) is parsed to determine whether there is an NRT service (S1020). This can be known by checking the value of the service_type field in the virtual channel loop of the VCT. For example, when the value of the service_type field is 0x08, it may be checked whether there is an NRT service. If it is not 0X08, since the corresponding virtual channel does not transmit the NRT service, an appropriate operation such as providing general A / V service may be performed according to the information included in the virtual channel (S1111).
  • the virtual channel transmits the NRT service, so that it matches with a specific PID (PID_NST) of a stream including a well-known IP address for accessing the NRT service signaling channel.
  • PID_NST a specific PID of a stream including a well-known IP address for accessing the NRT service signaling channel.
  • the receiver receives a transport packet (TP) having a PID value corresponding to the PID value from the obtained PID value PID_NST (S1040).
  • TP transport packet
  • the receiver extracts NRT service signaling data including an NRT service table (NST) from the received TP, or extracts an IP address for accessing the above-described NRT service signaling channel from the received TP, and then forms another form through the IP layer.
  • NST NRT service table
  • the receiver obtains channel information for transmitting NRT service data for each NRT service from the NST (S1060).
  • the receiver obtains an NRT content table (NCT) having a value of an NRT_channel_id field that matches the Channel_id value, which is an identifier of the obtained channel information, from the NRT service signaling data (S1070).
  • NCT NRT content table
  • the receiver obtains content information on NRT content constituting each NRT service from each field of the acquired NCT (S1080).
  • the content information may include at least one of the content_delevery_bit_rate, content_available_start_time, content_available_end_time, and content_title_text () fields according to the above-described embodiment of the NCT.
  • the receiver displays NRT guide information using content information.
  • the user may select NRT content to use or receive from the displayed NRT guide information.
  • the receiver acquires NRT service access information to which the selected NRT content belongs from the NST (S1100).
  • the NRT service access information may include, for example, channel information or IP address information for receiving NRT service data.
  • the receiver may access the channel or server for transmitting the NRT service using the obtained NRT service access information, receive the corresponding NRT content (S1110), and perform an appropriate operation according to the received NRT content.
  • 22 and 23 illustrate another embodiment of a reception system capable of receiving, storing, and playing back NRT content for an NRT service.
  • the receiver of FIG. 23 includes an operation controller 100, a baseband processor 110, a service demultiplexer 120, a stream component handler 130, a media handler 140, a file handler 150, a service manager 160, PVR Manager 170, First Storage 180, SG Handler 190, EPG Manager 191, NRT Service Manager 192, Application Manager 194, Middleware Engine 193, Presentation Manager 195 And a user interface (UI) manager 196.
  • UI user interface
  • the baseband processor 110 may include a tuner 111 and a demodulator 112.
  • the service demultiplexer 120 includes an MPEG-2 TP handler 121, a PSI / PSIP handler 122, an MPEG-2 TP demultiplexer 123, a descrambler 124, and a second storage 125. can do.
  • the stream component handler 130 may include a packetized elementary stream (PES) decoder 131, an elementary stream (ES) decoder 132, a PCR handler 133, an STC handler 134, and a DSM-CC addressable section handler 135. ), An IP datagram handler 136, a descrambler 137, a UDP handler 138, a service signaling section handler 138-1, and a conditional access system (CAS) 139.
  • PES packetized elementary stream
  • Media handler 140 may include an A / V decoder 141.
  • the file handler 150 may include an ALC / LCT stream handler 151, a file reconstruction buffer 152, an XML parser 153, an FDT handler 154, a decompressor 155, and a third storage unit ( 156, and file decoder 157.
  • the tuner 111 tunes a broadcast signal of a desired channel among broadcast signals received through terrestrial waves, for example, by controlling the service manager 160 to generate an intermediate frequency (IF) signal. Down conversion is performed to the demodulator 112.
  • the tuner 111 may receive a real time stream and a non real time stream. In the present invention, the non-real time stream will be referred to as an NRT stream.
  • the demodulator 112 performs automatic gain control, carrier recovery, and timing recovery on the digital IF signal of the passband input from the tuner 111, converts it into a baseband signal, and performs channel equalization. For example, when the broadcast signal is a VSB modulated signal, a VSB demodulation process is performed to perform automatic gain control, carrier recovery, and timing recovery.
  • the demodulated and channel equalized data in the demodulator 112 is output to the MPEG-2 TP handler 121 in the form of an MPEG-2 Transport Stream (TS) packet.
  • TS MPEG-2 Transport Stream
  • the MPEG-2 TP (Transport Stream Packet) handler 121 is composed of an MPEG-2 TP buffer and an MPEG-2 TP parser, and temporarily stores the output of the demodulator 112 and then analyzes a TS header to demodulate the demodulator 112. Is output to the demultiplexer 123 if it is an A / V TS packet for real time or an NRT TS packet, and to the PSI / PSIP handler 122 if it is a TS packet for a PSI / PSIP table.
  • the PSI / PSIP handler 122 includes a PSI / PSIP section buffer and a PSI / PSIP parser, and temporarily stores TS packets output from the MPEG-2 TP handler 121 and then refers to the TS by referring to a table identifier.
  • the table is restored from the PSI / PSIP section data included in the payload of the packet and parsed.
  • whether a table is composed of one section or a plurality of sections can be known through a table_id field, a section_number field, and a last_section_number field in the corresponding section. Collecting sections with the same table identifier completes the corresponding table.
  • the parsed table information is collected by the service manager 160 and stored in the first storage unit 180.
  • Table information such as VCT, PAT, PMT, DST, etc. according to the present invention is stored in the first storage unit 180 through the above process.
  • the service manager 160 stores the table information in the first storage unit 180 in the form of a service map and guide data.
  • the demultiplexer 123 divides the audio TS packet and the video TS packet into the PES decoder 131 if the input TS packet is an A / V TS packet in real time, and outputs the same to the PES decoder 131.
  • the DSM-CC handler 135 the demultiplexer 123 outputs a TS packet including a Program Clock Reference (PCR) to the PCR handler 133 and a CAS packet 139 if a TS packet includes CA (Conditional Access) information.
  • the NRT TS packet is divided into a TS packet including NRT service data and a TS packet including an NRT service signaling channel.
  • the TS packet of the NRT service data is assigned a unique PID to identify the NRT service, and the PID of the TS packet including the NRT service signaling channel is extracted using DST and PMT.
  • the demultiplexer 123 If the payload of the input TS packet is scrambled, the demultiplexer 123 outputs the descrambler 124 to the descrambler 124, and the descrambler 124 outputs information necessary to descramble from the CAS 139.
  • the control word is used to descramble the TS packet.
  • the demultiplexer 123 stores the real time A / V packet input by the request of any one of temporary recording, scheduled recording, and time shift in the second storage unit 125.
  • the second storage unit 125 is a mass storage medium and may be, for example, an HDD. Download (ie, storage) and upload (ie, playback) in the second storage unit 125 are controlled by the PVR manager 170.
  • the demultiplexer 123 divides the audio TS packet and the video TS packet from the A / V TS packet uploaded from the second storage unit 125 and outputs the PTS decoder 131 according to a reproduction request.
  • the demultiplexer 123 is controlled by the service manager 160 and / or the personal Vedeo recorder (PVR) manager 170 for the above-described processing.
  • PVR personal Vedeo recorder
  • the service manager 160 when the service manager 160 indicates that the service_type field value in the VCT indicates that the NRT service is transmitted, the service manager 160 extracts identification information of each NRT service from the NRT service descriptor (NRT_service_descriptor ()) received in the virtual channel loop of the VCT. And the PID of the DST is extracted from the service location descriptor (or the ES loop of the PMT) of the VCT to receive the DST.
  • NRT_service_descriptor NRT_service_descriptor
  • the NRT service is identified from the received DST, and the PID of the MPEG-2 TS packet including the NRT service signaling channel is extracted using the DST and PMT to receive the identified NRT service.
  • the extracted PID is output to the demultiplexer 123.
  • the demultiplexer 123 outputs MPEG-2 TS packets corresponding to the PID output from the service manager 160 to the addressable section handler 135.
  • the PCR is a time reference value used for time synchronization of the audio ES and the video ES in the A / V decoder 141.
  • the PCR handler 133 restores the PCR included in the payload of the input TS packet and outputs the PCR to the STC handler 134.
  • the STC handler 134 restores the STC (System Time Clock), which becomes the reference clock of the system, from the PCR and outputs the STC (System Time Clock) to the A / V decoder 141.
  • the PES decoder 131 includes a PES buffer and a PES handler.
  • the PES decoder 131 temporarily stores the audio TS packet and the video TS packet, and then removes the TS header from each TS packet to restore the audio PES and the video PES.
  • the reconstructed audio PES and video PES are output to the ES decoder 132.
  • the ES decoder 132 includes an ES buffer and an ES handler.
  • the ES decoder 132 removes each PES header from the audio PES and the video PES and restores the pure data to the audio ES and the video ES.
  • the reconstructed audio ES and video ES are output to the A / V decoder 141.
  • the A / V decoder 141 decodes the audio ES and the video ES with respective decoding algorithms, restores them to a state before compression, and outputs the same to the presentation manager 195. At this time, time synchronization is performed when decoding the audio ES and the video ES according to the STC.
  • the audio decoding algorithm may be an AC-3 decoding algorithm, an MPEG 2 audio decoding algorithm, an MPEG 4 audio decoding algorithm, an AAC decoding algorithm, an AAC + decoding algorithm, an HE AAC decoding algorithm, an AAC SBR decoding algorithm, an MPEG surround decoding algorithm, or a BSAC decoding.
  • At least one of the algorithm may be applied, and the video decoding algorithm may apply at least one of an MPEG 2 video decoding algorithm, an MPEG 4 video decoding algorithm, an H.264 decoding algorithm, an SVC decoding algorithm, and a VC-1 decoding algorithm.
  • the CAS 139 includes a CA stream buffer and a CA stream handler.
  • the CAS 139 temporarily stores the TS packet output from the MPEG-2 TP handler 121 or the service protection data restored and output from the UDP datagram handler 138. Thereafter, information (eg, a control word used for scramble) for descrambling is restored from the stored TS packet or service protection data. That is, an EMM (Entitlement Management Message), an ECM (Entitlement Control Message), etc., included in the payload of the TS packet are extracted, and the extracted EMM, ECM, etc. are analyzed to obtain information necessary for descramble.
  • the ECM may include a control word (CW) used for scramble. In this case, the control word may be encrypted with an authentication key.
  • the EMM may include an authentication key and entitlement information of the corresponding data. Information necessary for descrambling obtained by the CAS 139 is output to the descramblers 124 and 137.
  • the DSM-CC section handler 135 is composed of a DSM-CC section buffer and a DSM-CC section parser.
  • the DSM-CC section handler 135 temporarily stores the TS packets output from the demultiplexer 123 and includes the DSM-CC section handler 135 in the payload of the TS packets.
  • the addressable section is restored, the header and CRC checksum of the addressable section are removed, the IP datagram is restored, and then output to the IP datagram handler 136.
  • the IP datagram handler 136 is composed of an IP datagram buffer and an IP datagram parser. After buffering the IP datagram received from the DSM-CC section handler 135, the IP datagram handler 136 extracts a header of the buffered IP datagram. After analyzing and restoring the UDP datagram from the payload of the IP datagram, the data is output to the UDP datagram handler 138.
  • the scrambled UDP datagram is descrambled by the descrambler 137 and then output to the UDP datagram handler 138.
  • the descrambler 137 receives information necessary to descramble (eg, a control word used for scramble) from the CAS 139 to descramble the UDP datagram, and then performs a UDP datagram. Output to handler 138.
  • the UDP datagram handler 138 is composed of a UDP datagram buffer and a UDP datagram parser, and buffers UDP datagrams output from the IP datagram handler 136 or the descrambler 137 and then buffers the UDP.
  • the header of the datagram is extracted and analyzed to restore data included in the payload of the UDP datagram. In this case, if the restored data is service protection data, the data is output to the CAS 139, if the NRT service signaling data is output to the service signaling section handler 138-1, and if the NRT service data is output to the ALC / LCT stream handler 151. .
  • the access information of the IP datagram transmitting the NRT service signaling channel may be a well-known destination IP address and a well-known destination UDP port number.
  • the IP datagram handler 136 and the UDP datagram handler 138 have a well-known destination IP multicast address and a well-known destination UDP port number, and transmit an NRT service signaling channel.
  • a cast stream, that is, NRT service signaling data is extracted and output to the service signaling section handler 138-1.
  • the service signaling section handler 138-1 includes a service signaling section buffer and a service signaling section parser.
  • the service signaling section handler 138-1 restores and parses an NST from the NRT service signaling data and outputs the parsed NST to the service manager 160. Parsing the NST may extract access information of a FLUTE session for transmitting content / files constituting an NRT service and signaling information necessary for rendering the NRT service. For example, information necessary for rendering of content / files of an NRT service transmitted to each FLUTE session may be extracted from the NST.
  • Information necessary for rendering the content / files of the NRT service may be container information, encoding information, or may be a decoding parameter of a media object.
  • the information parsed from the NST is collected by the service manager 160 and stored in the first storage unit 180.
  • the service manager 160 stores the information extracted from the NST in the first storage unit 180 in the form of a service map and guide data.
  • the role of the service manager 160 may be performed by the NRT service manager 192. That is, the information parsed from the NST may be collected by the NRT service manager 192 and stored in the first storage unit 180.
  • the ALC / LCT stream handler 151 is composed of an ALC / LCT stream buffer and an ALC / LCT stream parser. After buffering the data of the ALC / LCT structure output from the UDP datagram handler 138, the ALC / LCT stream handler 151 receives the ALC from the buffered data. Parse the header and header extension of the / LCT session. As a result of analyzing the header and header extension of the ALC / LCT session, if the data transmitted to the ALC / LCT session is an XML structure, the data is output to the XML parser 153, and if the file structure is a file structure, the file reconstruction buffer 152 is output.
  • the data is output to the file decoder 157 or stored in the third storage unit 156.
  • the ALC / LCT stream handler 151 is controlled by the NRT service manager 192 when data transmitted through the ALC / LCT session is data for an NRT service. In this case, if data transmitted to the ALC / LCT session is compressed, the data is decompressed by the decompressor 155 and then output to at least one of the XML parser 153, the file decoder 157, and the third storage unit 156.
  • the XML parser 153 analyzes the XML data transmitted through the ALC / LCT session, outputs the analyzed data to the FDT handler 154 if the analyzed data is data for a file-based service, and if the data is for service guide, the SG handler ( 190)
  • the FDT handler 154 analyzes and processes a file description table of the FLUTE protocol through an ALC / LCT session. If the received file is a file for NRT service, the FDT handler 154 is controlled by the NRT service manager 192.
  • the SG handler 190 collects and analyzes data for a service guide transmitted in an XML structure and outputs the data to the EPG manager 191.
  • the file decoder 157 decodes the file output from the file reconstruction buffer 152 or the file output from the decompressor 155 or the file uploaded from the third storage unit 156 using a predetermined algorithm to decode the middleware engine 193. Output to the A / V decoder 141.
  • the middleware engine 193 analyzes and executes data of a file structure, that is, an application.
  • the application may be output to an output device such as a screen or a speaker through the presentation manager 195.
  • the middleware engine 193 is a JAVA based middleware engine.
  • the EPG manager 191 receives the service guide data from the SG handler 190 according to the user's input, converts the service guide data into the display format, and outputs it to the presentation manager 195.
  • the application manager 194 performs overall management regarding the processing of the application data received in the form of the file or the like.
  • the service manager 160 collects and analyzes PSI / PSIP table data or NRT service signaling data transmitted through an NRT service signaling channel to generate a service map and stores the service map in the first storage unit 125. In addition, the service manager 160 controls access information on the NRT service desired by the user, and controls the tuner 111, the demodulator 112, the IP datagram handler 136, and the like.
  • the operation controller 100 is the service manager 160, the PVR manager 170, the EPG manager 191, the NRT service manager 192, and the application manager 194 according to a user's command input through the UI manager 196. ), At least one of the presentation manager 195 is controlled to perform a function according to the user's command.
  • the NRT service manager 192 performs overall management of the NRT service transmitted in the form of content / file through a FLUTE session on the IP layer.
  • the UI manager 196 transmits a user's input to the operation controller 100 through the UI.
  • the presentation manager 195 may include at least one of audio and video data output from the A / V decoder 141, file data output from the middleware engine 193, and service guide data output from the EPG manager 191. And at least one of the screens.
  • any one of the service signaling section handler 138-1, the service manager 160, and the NRT service manager 192 configures the NRT service from the FLST session loop (or component loop of the NST) of the NST.
  • the FLUTE level access information is obtained from NRT_FLUTE_File_delivery_descriptor () received in the FLUTE session loop of the NST.
  • the FLUTE level access information is obtained from component_descriptor () received in the component loop of the NST.
  • the ALC / LCT stream handler 151 and the file decoder 157 access the FLUTE file delivery session using the obtained FLUTE level access information to collect files belonging to the session. Collecting these files constitutes one NRT service.
  • the NRT service may be stored in the third storage unit 156 or output to the middleware engine 193 or the A / V decoder 141 to be displayed on the display device.
  • the third storage unit 156 is a storage medium for storing a file such as NRT service data.
  • the third storage unit 156 may be shared with the second storage unit 125 or may be used separately.
  • 24 is a flowchart illustrating a method of receiving and providing an NRT service by a receiver according to an embodiment of the present invention.
  • the receiver may acquire NRT service signaling information through an NRT service signaling channel or receive an IP datagram in the case of a mobile NRT service, and obtain an SMT from the NRT service signaling information (S2010).
  • NRT service information may be obtained by parsing NRT_service_info_descriptor in a service level descriptor loop in SMT.
  • the obtained NRT service information may include an application type for each NRT service or requirement information for other NRT services.
  • the receiver outputs an NRT service guide based on the obtained NRT service information (S2030).
  • the NRT service guide may display application and service category information for each service.
  • detailed information may be further displayed based on each field of the NRT service info descriptor.
  • the detailed information may include, for example, capacity information of the corresponding NRT service according to the storage_requirement field or audio or video codec information of the corresponding NRT service according to the audio_codec_type or video_codec_type field.
  • the user may select an NRT service to receive or use based on the information displayed in the service guide.
  • the receiver obtains an identifier (content_id) for a content item constituting the selected NRT service from the NCT.
  • the receiver obtains an NRT_service_id corresponding to the selected NRT service from the SMT, obtains an NCT having an NRT_channel_id value that matches the obtained NRT_service_id value, and uses an NCT identifier (content_id) for a content item configuring a corresponding NRT service through the obtained NCT. ) Can be obtained.
  • the receiver accesses a FLUTE session to receive a file configuring a corresponding content item using the acquired content item identifier (content_id) (S2050). Since each file constituting the content item is matched with the TOI or Content-Location field specified in the FDT in the FLUTE session, the receiver then receives the file of the corresponding content item using the FLUTE session (S2060). For example, the reception of a file may be performed by reading an FDT in a corresponding FLUTE session and receiving a corresponding file or an object when the Content-ID attribute field of the corresponding file matches the acquired content_id.
  • the receiver may obtain a list of files corresponding to the content item by parsing the FDT instances in the corresponding FLUTE session.
  • the receiver acquires entry information including a list of files serving as an entry among the list of files (S2070).
  • the receiver provides the NRT service to the user based on the received content item and a list or entry information of files corresponding to the content item (S2080).
  • the content downloaded through the NRT service can be used at a point in time desired by the user independently of real-time broadcasting.
  • the broadcasting station may transmit the NRT service in advance, store and receive by the receiver, and designate to execute the content item of the corresponding NRT service at a time when a specific real time broadcast is transmitted or displayed on the receiver.
  • the NRT service may include content that can be executed at a specific time after downloading in advance in association with real-time broadcasting.
  • the NRT service may include content for preparing in advance to execute a specific NRT service at a specific time.
  • the NRT service content triggered at a specific time associated with real-time broadcasting such that a specific action is executed for a specific NRT service may be referred to as a triggered declarative object (TDO).
  • TDO triggered declarative object
  • the NRT service application may be classified into a non-real time declarative object (NDO) or a trigger declarative object (TDO) according to whether or not it is executed at a specific time.
  • a broadcast station may transmit trigger information for triggering such a trigger declarative object (TDO).
  • TDO trigger declarative object
  • the trigger information may include information for the receiver to perform a specific action on a specific trigger declarative object at a specific time point.
  • the trigger information may include trigger signaling data (trigger signaling information) for signaling a trigger and trigger data constituting the trigger.
  • trigger signaling data trigger signaling information
  • a data stream for transmitting trigger data may be referred to as a trigger stream.
  • the trigger data may mean the trigger itself.
  • Such a trigger may include at least one of a trigger identifier for identifying a trigger, a TDO identifier for identifying an NRT service for triggering, action information to be performed on the TDO, and a trigger time.
  • the trigger stream may be transmitted using a user data space or a DTV-CC.
  • the trigger stream may have various forms for transmission. As described above, although the trigger stream may be transmitted in various forms, each trigger stream may include a trigger conceptually identical or similar to the trigger proposed in the present invention.
  • the trigger identifier may be an identifier for uniquely identifying the trigger.
  • the broadcaster may transmit one or more triggers to broadcast program information for a predetermined time provided through the EIT.
  • the receiver may perform an action on the trigger target TDO at a specific time for each trigger based on one or more triggers. In this case, the receiver may distinguish each trigger using a trigger identifier.
  • the TDO identifier may be an identifier for identifying NRT service content that is a target of a trigger. Accordingly, the TDO identifier may include at least one of a triggered NRT service identifier (NRT_service_id), content linkage (content_linkage), a URI, or a URL of an NRT content item entry. And a target identifier targer_service_id for identifying a trigger target TDO to be described later.
  • the TDO action information may include information on an action to be performed on the TDO to be triggered.
  • the action information may be at least one of execution, termination, and extension instructions of the target TDO.
  • the action information may include an instruction for generating a specific function or event in the target TDO.
  • the trigger may request the receiver to activate the target TDO.
  • the action information includes an extension command of the target TDO
  • the trigger may indicate to the receiver that the target TDO is to be extended.
  • the action information includes a termination command of the target TDO
  • the trigger may indicate to the receiver that the target TDO should be terminated.
  • the broadcast station may control the TDO operation in the receiver according to the real-time broadcast content through the trigger.
  • the trigger time may mean a time designated for performing (triggering) a designated action on the target TDO.
  • the trigger time may be synchronized with a video stream of a specific virtual channel in order to associate the NRT service with a real time broadcast.
  • the broadcasting station may designate the trigger time with reference to the PCR referenced in the video stream.
  • the receiver may trigger the TDO at a time designated by the broadcasting station by referring to the PCR referenced by the video stream.
  • the broadcast station may signal the trigger by including a trigger identifier in the header of the video stream to transmit the correct trigger time.
  • the trigger time may be designated as UTC time.
  • UTC time has the advantage that you can trigger by referring to absolute time, not relative time.
  • Such trigger time may be an accurate trigger time and may include an approximate start time.
  • the receiver may receive an approximate time and prepare an action for the target TDO in advance before the correct trigger time. For example, the receiver may prepare to execute the TDO in advance and operate the TDO naturally at the trigger time.
  • 25 is a diagram illustrating syntax of a caption service descriptor according to an embodiment of the present invention.
  • caption data includes text data as well as caption data
  • caption data and caption data may be used in the same meaning.
  • the caption service and the subtitle service may also be used in the same sense.
  • the caption service may include a plurality of caption data, and for example, may include a plurality of caption data implemented in different languages.
  • the caption service descriptor includes information about captions such as closed captioning type information and language code information about the caption service and an event.
  • the caption service descriptor may be represented in a descriptor loop of each EIT event having a subtitle.
  • the caption service descriptor is immediately after the ES_info_length field of TS_program_map_section () and may exist in the descriptor loop defining the video stream_type.
  • the caption service descriptor includes a descriptor_tag field, a descriptor_length field, a number_of_services field, and a plurality of caption service descriptions.
  • the descriptor_tag field is an 8-bit field for distinguishing the descriptor as caption_service_descriptor () and may have a value of 0x86.
  • the descriptor_length field is an 8-bit field for indicating the number of bytes following the corresponding field.
  • the number_of_services field indicates the number of a plurality of subtitle service descriptions and is an unsigned 5-bit field of 1 to 16. If the TV subtitle does not exist in the related video service, caption_service_descriptor () does not exist in both the program map table and the event information table.
  • Each 'for' loop defines one subtitle service that exists as a sub-stream within a 9600 bps (bit per second) subtitle stream. Each loop provides the language, attributes, and associated service number (for improved caption) of the substream.
  • Each of the plurality of subtitle service descriptions includes a language field, an easy_reader field, a wide_aspect_ratio field, a cea708_flag field, a timed_text_flag field, a digital_cc field, a line21_field field, a caption_service_number field, a subtitle_type field, a subtitle_format field, and a track_id field.
  • the language field represents a 3-byte language code that defines a language associated with one subtitle service.
  • the easy_reader field indicates that when the Boolean flag is set, the subtitle service contains a beginner's text alignment. When the Boolean flag is cleared, it indicates that the subtitle service is not set up for beginners.
  • the wide_aspect_ratio field may be provided with a subtitle service for a 16: 9 screen when the Boolean flag is set, and a subtitle service for a 4: 3 screen is provided when the Boolean flag is clear, but is optional for a 16: 9 screen. Can be displayed in the center of the screen.
  • a subtitle service for 4: 3 screen may be provided in the wide_aspect_ratio field. If the value of the field is '00', a subtitle service for 4: 3 screen may be provided. If the field is '10', the subtitle service for 16: 9 screen may be provided. If a value of the corresponding field is '11', for example, a subtitle service for a 21: 9 screen having a width form of 16: 9 or more may be provided.
  • the cea708_flag field indicates whether caption data provided in an NRT service or NRT content is provided by a method specified in consumer electronics association (cea) -708. If the value of this field is '1', it indicates that cea-708 subtitle data is included in the video stream and transmitted. In this case, the receiver may process caption data using a caption decoder.
  • the timed_text_flag field indicates whether subtitle data provided from an NRT service or NRT content is provided in the form of a Society of Motion Picture and Television Engineers (SMPTE) Timed Text. If the value of this field is '1', it indicates that the caption data is included and transmitted in a separate timed text stream rather than a video stream. In this case, the receiver should use a decoder separate from the caption decoder to process timed text data.
  • the value of the cea708_flag field and the timed_text_flag field included in one caption_service_descriptor () must be different from each other. For example, the value of the cea708_flag field and the timed_text_flag field included in one caption_service_descriptor () may not be '0' at the same time.
  • the digital_cc field indicates that there is an improved TV subtitle service according to cea-708 when the flag is set. If the flag is clear, it indicates that there is a line-21 subtitle service. For line-21 subtitles, the line21_field field indicates whether the service transmits an even field or an odd field.
  • the line21_field field indicates that when the flag is set, the line-21 subtitle service is associated with field 2 of NTSC type. If the flag is clear, the line-21 subtitle service indicates that it is associated with field 1 of type NTSC.
  • the flag of the line21_field field is defined only when the flag of the digital_cc field indicates that there is an improved TV subtitle service according to cea-708.
  • the caption_service_number field distinguishes a service number of a corresponding caption stream related to languages and attributes defined in the corresponding 'for' loop and is an unsigned 6-bit integer between 0 and 63.
  • the caption_service_number field is defined only when the flag of the digital_cc field indicates that there is an improved TV subtitle service according to cea-708.
  • the subtitle_type field, the subtitle_format field, and the track_id field may be used when the format of the caption data is the SMPTE Timed Text format.
  • the subtitle data may be included as a separate subtitle track of the Common File Format (CFF) container extended based on the ISO MP4 file. While the subtitle data in cea-708 format is included in the video stream, the subtitle data in SMPTE Timed Text format exists as a separate track from the video stream.
  • CFF Common File Format
  • the language field includes a plurality of subtitle_type fields, a plurality of subtitle_format fields, and a plurality of track_id fields.
  • the subtitle data in Korean may be subtitle data representing at least one of a non-disabled person, a hearing impaired person, a visually impaired person, a forced subtitle, a commandant person, and other purposes.
  • the subtitle data in Korean may be, for example, subtitle data in a text form, an image form, or a mixture of text and images.
  • the caption data in one language such as Korean may mean a plurality of caption data having different uses or forms.
  • the subtitle_type field defines the purpose of the subtitle.
  • FIG. 26 is a diagram for explaining the meaning of each value of a subtitle type field included in a caption service descriptor when transmitting caption data included in a separate stream instead of a video stream according to another embodiment of the present invention. .
  • a value of '0x01' of the subtitle_type field means that the subtitle is a non-disabled subtitle, '0x02' means a subtitle for the deaf, and '0x03' means a subtitle for the visually impaired. If the value of the subtitle_type field is '0x04', the subtitle indicates the required subtitle regardless of whether the user has activated the subtitles, and the subtitle track of the correct language should be selected, in which case often a 'forced caption' It is referred to as. If the value of the subtitle_type field is '0x05', it means a subtitle of a commentary or another purpose.
  • the subtitle_format field defines the format of the subtitle.
  • FIG. 27 is a diagram for explaining the meaning of each value of a subtitle format field included in a caption service descriptor when transmitting caption data included in a separate stream instead of a video stream according to another embodiment of the present invention. .
  • a value of '0x01' in the subtitle_format field means that the subtitle is text.
  • a value of '0x02' in the subtitle_format field means that the subtitle is an image.
  • a value of '0x03' in the subtitle_format field indicates that the subtitle is text. Means that it is a mixture of images.
  • the track_id field is an integer that is referred to to uniquely identify the subtitle track in the corresponding content item.
  • the receiver may uniquely identify the subtitle track of the CFF container based on the value of the track_id field. Accordingly, the receiver can select and reproduce captions faster by using the value of the track_id field. If there is no value of the track_id field, since the subtitle track of the CFF container can be uniquely identified based on metadata included in the CFF file, the corresponding sub title track can be selected and played.
  • FIG. 28 is a flowchart illustrating a method of receiving broadcast service according to an embodiment of the present invention, in particular, providing caption data based on caption service information included in an SMT.
  • the receiver obtains an SMT from NRT service signaling information (S101).
  • the receiver extracts a caption service descriptor from the SMT (S103).
  • the receiver may obtain a caption service descriptor by parsing a service level descriptor loop in the SMT.
  • the data stream for transmitting the content item includes a video stream.
  • One video stream may include a plurality of subtitle services.
  • the receiver may output the subtitle service selected by the user to the screen.
  • the caption service selection information provided to the user may be included in the caption service descriptor.
  • the receiver may extract a descriptor identified by caption_service_descriptor () from the SMT using the descriptor_tag field information.
  • the caption service descriptor extracted from the SMT may include signaling information about the currently received NRT service.
  • the receiver sets a type of language according to a user input related to language selection (S105).
  • the receiver may provide a caption setting menu for the user to set the caption language.
  • the user may select, for example, Korean as the caption language in the caption setting menu provided by the receiver.
  • the receiver may set the type of language to Korean based on a user input regarding language selection for the caption language.
  • the receiver extracts language type information of caption data from the caption service descriptor extracted in step S103 (S107).
  • the receiver may extract, for example, language type information of the caption data from the language code defined in the language field of the caption service descriptor.
  • the receiver determines whether the type of language set in step S105 and the language type information extracted in step S107 are the same (S109).
  • the receiver may select only the subtitle service provided in the same kind of language as the language selected by the user by comparing the type of language according to the user input regarding language selection with the type of language based on the subtitle service signaling information obtained from the SMT. For example, if the user selects Korean as the caption language, the receiver may select only the caption service descriptor signaling the caption data provided in Korean from the SMT.
  • the receiver extracts transmission type information of caption data from the caption service descriptor (S111).
  • the receiver may extract transmission type information of caption data, for example, from a cea708_flag field or a timed_text_flag field.
  • the receiver may extract information indicating that the transmission form of caption data is included in the video stream and transmitted.
  • the receiver may extract information indicating that the transmission form of caption data is included in a separate timed text stream rather than a video stream and transmitted.
  • the receiver determines whether the transmission form of caption data is included in the video stream and transmitted (S113). For example, as described above in step S111, if the value of the cea708_flag field of the caption service descriptor is '1', the receiver may determine that a transmission form of caption data is included in the video stream and transmitted. In addition, when the value of the digital_cc field of the caption service descriptor is '1', the receiver may know that there is a caption service according to cea-708.
  • the receiver extracts caption service number information of the caption data from the caption service descriptor selected in step S109 (S115).
  • the receiver may extract, for example, the value of the caption_service_number field from the caption service descriptor.
  • the receiver may extract the value of the caption_service_number field from the caption service descriptor only when there is a caption service according to cea-708 according to the value of the digital_cc field of the caption service descriptor.
  • the receiver receives the corresponding content item based on the extracted caption service number information (S117).
  • the receiver may receive a content item including caption data provided in Korean based on the value of the caption_service_number field. In this case, the receiver may receive a plurality of content items that provide the corresponding subtitle service.
  • the receiver extracts caption data from the video stream based on the caption service number information (S119).
  • a description with reference to FIG. 30 is as follows.
  • FIG. 30 is a view for explaining another embodiment of a receiving system capable of receiving, storing, and playing back NRT content for an NRT service.
  • an A / V decoder of a receiver decodes an audio stream and a video stream, restores it to a state before compression, and outputs the same.
  • Subtitle display setting is set in the corresponding content item.
  • Caption decoder extracts caption data from the video stream.
  • the caption decoder of the receiver may extract caption data from the video stream using the value of the caption_service_number field of the caption service descriptor.
  • the receiver outputs extracted caption data (S121).
  • the A / V decoder of the receiver may output the restored audio data and the restored video data to the presentation control, and the receiver's caption decoder may output the restored caption data to the presentation control.
  • the receiver receives the corresponding content item ( S123).
  • the receiver may receive a content item including caption data provided in Korean based on the value of the caption_service_number field.
  • the receiver may receive a plurality of content items that provide the corresponding subtitle service.
  • the receiver may separately receive subtitle_type field information, subtitle_format field information, and track_id field information included in the caption service descriptor.
  • the receiver extracts caption data transport stream information from the caption service descriptor (S125).
  • the receiver may extract track_id field information from the caption service descriptor. If the track_id field information is not included in the caption service descriptor, the receiver may extract the subtitle track information by extracting metadata information of the caption data included as a separate subtitle track in the CFF container.
  • a description with reference to FIG. 30 is as follows.
  • an A / V decoder of a receiver decodes an audio stream and a video stream, restores it to a state before compression, and outputs the same.
  • Subtitle display setting is set in the corresponding content item.
  • the SMPTE Timed Text decoder extracts caption data from the video stream.
  • the SMPTE Timed Text decoder of the receiver may extract caption data from the Timed Text stream using the value of the track_id field of the caption service descriptor.
  • the receiver may extract subtitle_type field information from the caption service descriptor.
  • the receiver may extract caption data for the same purpose as a user input for caption use selection using the subtitle_type field information. For example, when the receiver receives a user input for selecting subtitles for the hearing impaired, the receiver may extract the subtitle_type field including the notification information for the hearing impaired from the caption service descriptor, and extract the caption data for the hearing impaired from the timed text stream.
  • the receiver may extract subtitle_format field information from the caption service descriptor.
  • the receiver may extract caption data having the same form as a user input regarding a caption data format using the subtitle_format field information. For example, when the receiver receives a user input for selecting a caption in the form of an image, the receiver may extract a subtitle_format field including the image form information from the caption service descriptor and extract caption data in the form of an image from a timed text stream.
  • the receiver extracts caption data from the caption data transport stream using the extracted caption data transport stream information (S127).
  • the receiver may extract corresponding caption data from the plurality of caption data included in the timed text stream using the track_id field information. If the track_id field information is not included in the caption service descriptor, the receiver may extract corresponding caption data from the timed text stream using metadata of the subtitle track.
  • the receiver outputs the extracted caption data (S121). Description of step S121 is as described above.
  • the receiver may output caption data through the display unit.
  • 29 is a flowchart illustrating a method of receiving a broadcast service according to another embodiment of the present invention, in particular, providing a caption data based on caption service information included in an NRT-IT.
  • the receiver obtains an NRT-IT from NRT service signaling information (S151).
  • the receiver extracts a caption service descriptor from the NRT-IT (S153).
  • the receiver may obtain a caption service descriptor by parsing a content level descriptor loop of NRT_IT.
  • the caption service descriptor may include caption service selection information provided to the user.
  • the caption service descriptor extracted from the NRT-IT may include signaling information about an NRT content item to be serviced in the future.
  • the receiver sets a type of language according to a user input related to language selection (S155).
  • the user may select, for example, Korean as the caption language in the caption setting menu provided by the receiver.
  • the receiver may set Korean as a caption language based on user input regarding language selection.
  • step S155 may not necessarily be performed after step S153, and may be performed before or after step S151 or step S153 as long as it can be executed before step S157 is executed. In this manner, step S105 is also sufficient if step S107 can be executed before step S107 is executed.
  • the receiver extracts language type information of caption data from the caption service descriptor (S157). In this step, the description of the step S107 described above may be applied.
  • the receiver determines whether the type of language set in step S155 and the information of the language type extracted in step S153 are the same (S159). In this step, the description of step S109 may be applied.
  • the receiver extracts transmission type information of caption data from the caption service descriptor (S161). In this step, the description of step S111 can be applied.
  • the receiver determines whether the transmission form of the caption data is included in the video stream and is transmitted (S163). When the caption data is included in the video stream and transmitted, the receiver determines the caption service number information of the caption data from the caption service descriptor. To extract (S165). These steps may be applied to the description of steps S113 and S115, respectively.
  • the receiver reserves the recording of the corresponding content item using the caption service number information (S167).
  • the receiver may reserve recording of a content item including caption data provided in Korean, based on the value of the caption_service_number field.
  • the receiver records the corresponding content item according to a predetermined schedule (S169).
  • the receiver may receive the content item reserved in step S167 by recording.
  • the receiver extracts caption data from the video stream using caption service number information for reproduction of the recorded corresponding content item (S171).
  • a description with reference to FIG. 30 is as follows.
  • step S119 when an A / V decoder of a receiver decodes an audio stream and a video stream, restores it to a state before compression, and outputs the same. Subtitle display is set in the corresponding content item. Caption decoder extracts caption data from the video stream. In this step, the description of step S119 may be applied.
  • the receiver outputs extracted caption data (S173).
  • the description of step S121 described above may be applied.
  • the receiver determines whether the transmission form of the caption data is included in the video stream and is transmitted (S163). When the caption data is included in the separate timed text stream and is transmitted instead of the video stream, the receiver determines that the content item has been transmitted. The recording is reserved (S175). Each of these steps may be applied to the description of step S123.
  • the receiver extracts caption data transport stream information from the caption service descriptor (S177).
  • the caption data transport stream information may include track_id field information or metadata information of caption data included in the CFF container.
  • An A / V decoder of a receiver decodes an audio stream and a video stream, restores it to a state before compression, and outputs the same. Subtitle display setting is set in the corresponding content item.
  • the SMPTE Timed Text decoder extracts caption data from the video stream.
  • the SMPTE Timed Text decoder of the receiver may extract caption data from the Timed Text stream using the value of the track_id field of the caption service descriptor or metadata information of the caption data. As a description of this, the description of S125 may be applied.
  • the receiver records the corresponding content item according to a predetermined schedule (S179).
  • the receiver may receive the content item reserved in step S175 by recording the content item.
  • the receiver extracts caption data from the caption data transport stream (S181).
  • the receiver may extract the corresponding caption data from the plurality of caption data included in the timed text stream using the track_id field information or the metadata of the subtitle track.
  • a description of step S127 may be applied.
  • step S173 the receiver outputs the extracted caption data (S173). Description of step S173 has been described above.
  • a broadcast station may transmit caption service signaling information by designating a type of a data stream including caption data.
  • a transmitter for transmitting a broadcast service may include an NRT service transmitter, a multiplexer, a modulator, and the like.
  • the NRT service transmitter includes an NRT service generator and an NRT service. It may include a signaling data generator.
  • a method of transmitting a broadcast service including caption service signaling information by a transmitter will be described with reference to FIGS. 31 and 32.
  • FIG. 31 is a flowchart schematically illustrating a broadcast service transmission method according to an embodiment of the present invention.
  • the transmitter generates language type information of caption data (S401).
  • the transmitter may generate language type information of the caption data by defining a language code of 3 bytes in the language field described above.
  • the transmitter generates data stream type information (S403).
  • the transmitter may generate data stream type information by setting the value of the cea708_flag field described above. For example, the transmitter may set the value of the cea708_flag field to '1' to define that cea-708 subtitle data is included in the video stream and transmitted.
  • the transmitter generates caption stream identification information (S405).
  • the transmitter may generate caption stream identification information by setting a value of the caption_service_number field described above. For example, the transmitter may identify the cea-708 caption data from other caption data by setting a 6-bit number in the caption_service_number field.
  • the transmitter generates a caption service descriptor including language type information, data stream type information, and caption stream identification information (S407).
  • the transmitter may set values in the descriptor_tag field, descriptor_length field, number_of_services field, easy_reader field, wide_aspect_ratio field, digital_cc field, and line21_field field as described above and include them in the caption service descriptor.
  • the transmitter transmits a caption service descriptor to the receiver (S409).
  • the transmitter may transmit the SMT or NRT-IT including the caption service descriptor to the receiver.
  • the transmitter generates caption data according to language type information, data stream type information, and caption stream identification information (S411).
  • the order of step S407 and step S411 may be reversed.
  • the transmitter includes the caption data in the video stream of the corresponding content item and transmits it (S413).
  • 32 is a flowchart schematically illustrating a broadcast service transmission method according to another embodiment of the present invention.
  • the transmitter generates language type information of caption data (S431).
  • the transmitter may generate language type information in the same manner as in step S401 described above.
  • the transmitter generates data stream type information (S433).
  • the transmitter may generate data stream type information by setting a value of the timed_text_flag field described above.
  • the transmitter may define that the caption data is included in the text stream and transmitted by setting the value of the timed_text_flag field to '1'.
  • the transmitter generates caption track identification information (S435).
  • the transmitter may generate caption track identification information by setting a value of the track_id field described above. For example, the transmitter may identify a corresponding subtitle track from another subtitle track by setting a 32-bit number in the track_id field.
  • the transmitter may generate metadata including identification information on the corresponding subtitle track.
  • the transmitter generates a caption service descriptor including language type information, data stream type information, and caption track identification information (S437).
  • the transmitter may set values in the descriptor_tag field, descriptor_length field, number_of_services field, easy_reader field, wide_aspect_ratio field, subtitle_type field, and subtitle_format field described above to include in the caption service descriptor.
  • the transmitter transmits a caption service descriptor to the receiver (S439).
  • the transmitter may transmit the SMT or NRT-IT including the caption service descriptor to the receiver.
  • the transmitter may transmit a CFF file including metadata including identification information of the corresponding subtitle track to the receiver.
  • the transmitter generates caption data according to language type information, data stream type information, and caption stream identification information (S441).
  • the order of step S437 and step S441 may be reversed.
  • the transmitter includes the caption data in the text stream of the corresponding content item and transmits it (S443).
  • Additional services include service information, metadata, additional data, compiled executables, web applications, Hypertext Markup Language (HTML) documents, XML documents, cascading style sheet (CSS) documents, audio files, and video.
  • the file may be an address such as a Uniform Resource Locator (URL).
  • the additional service may be signaling data, interworking information, trigger, SMT, NRT-IT, EIT, VCT, PMT as described above.
  • the additional service may be caption signaling data as described above.
  • broadcasting stations transmit main service audio content, together with enhanced service data that can be used in connection with the main audio and video content or independent of the main audio and video content.
  • video display devices in each home rarely directly receive broadcast signals through airwaves. Rather, the video display device of each home is connected to a broadcast receiving device such as a set-top box, and thus often reproduces uncompressed audio and video content provided by the broadcast receiving device.
  • a broadcast receiving device such as a set-top box
  • the broadcast reception device receives content from a server called a multichannel video programming distributor (MVD).
  • the multi-channel video distributor receives a broadcast signal from a broadcast station, extracts content from the received broadcast signal, converts the content into a signal suitable for transmission, and provides the converted signal to the broadcast receiving device.
  • the broadcasting station since the multi-channel video distributor may exclude extracted additional service data or add another additional service data, the broadcasting station only plays a role of providing audiovisual contents and provides broadcasting service-oriented additional services. Can not.
  • the broadcast receiving apparatus also extracts main audio and video data from the signal received from the multichannel video distributor, and provides only the uncompressed audio and video data to the video display device, only an additional service under the control of the broadcast receiving device is available, and No additional services can be made. This further prevents the broadcaster from providing self-directed supplementary services.
  • an object of the present invention is to provide a video display device and a method of controlling the same, which enable broadcast service-driven supplementary services.
  • FIG. 33 is a block diagram illustrating a network topology according to an embodiment of the present invention.
  • the network topology includes a content providing server 10, a content recognizing service providing server 20, a multi-channel video distribution server 30, and an additional service information providing server ( 40, a plurality of additional service providing servers 50, a set top box 60, a network 70, and a receiver 300.
  • the content providing server 10 may correspond to a broadcasting station and broadcasts a broadcast signal including main audio-visual content.
  • the broadcast signal may further include an additional service.
  • the supplementary service may or may not be related to the main audiovisual content.
  • the content recognizing service providing server 20 provides a content recognizing service that enables the receiver 300 to recognize content based on the main audio and video content.
  • the content recognizing service providing server 20 may or may not modify the main audio and video content.
  • One or more content recognition service providing servers may exist.
  • the content recognizing service providing server 20 may be a watermark server for modifying the main audiovisual content to insert a visible watermark such as a logo into the main audiovisual content.
  • the watermark server may watermark the content provider's logo on the upper left or upper right of each frame of the main audiovisual content.
  • the content recognizing service providing server 20 may be a watermark server for modifying the main AV content and inserting the content information into the main AV content as an invisible watermark.
  • the content recognizing service providing server 20 may be a fingerprint server that extracts and stores feature information from some frames or some audio samples of the main audio and video content. This feature information is also called signature.
  • the multi-channel video distribution server 30 receives and multiplexes a broadcast signal from a plurality of broadcasting stations and provides the multiplexed signal to the set top box 60.
  • the multi-channel video distribution server 30 performs demodulation and channel decoding on the received broadcast signal to extract the main AV content and the additional service, and then performs channel encoding on the extracted main AV content and the extracted additional service. It is possible to generate multiplexed signals for distribution.
  • the multi-channel video distribution server 30 may exclude the extracted additional service or add another additional service, the broadcasting station may not provide a broadcaster-led service.
  • the set top box 60 extracts the main audio and video content by tuning a channel selected by the user, receiving a signal of the tuned channel, and performing demodulation and channel decoding on the received signal.
  • the set top box 60 extracts the extracted main audio and video content from H.264 / MPEG-4 AVC (Moving Picture Experts Group-4 advanced video coding), Dolby AC-3, and MPEG-2 AAC (Moving Picture Experts Group-2 Advanced Audio). Decoding to generate uncompressed main AV content.
  • the set top box 60 provides the generated uncompressed main audio and video content to the receiver 300 through an external input port of the receiver 300.
  • the supplementary service information providing server 40 provides supplementary service information for one or more available supplementary services related to the main AV content in response to a request of the receiver 300.
  • the additional service information providing server 40 and the receiver 300 may communicate with each other via the network 70.
  • the additional service information providing server 40 may provide additional service information for the highest priority additional service among a plurality of available additional services.
  • the supplementary service providing server 50 provides one or more supplementary services that can be used in connection with the main audio and video content in response to a request of the receiver 300.
  • the additional service providing server 50 and the receiver 300 may communicate with each other via the network 70.
  • the network 70 may be an IP-based network or an ATSC Advanced Television Systems Committee-Mobile / Handheld (AT / M) channel.
  • the receiver 300 may be a device having a display unit, such as a television, a laptop, a mobile phone, a smartphone, or the like.
  • the receiver 300 may receive uncompressed main audio and video content from the set-top box 60 through an external input port, and includes encoded main audio and video content from the content providing server 10 or the multichannel video distribution server 30.
  • the broadcast signal may be received through a broadcast network.
  • the receiver 300 may be provided with the content recognition service from the content recognition service providing server 20 through the network 70, and associated with the main audiovisual content from the additional service information providing server 40 through the network 70. Addresses of one or more additional services available may be received, and one or more additional services available in connection with the main audio and video content may be provided from the additional service providing server 50 through the network 70.
  • At least two of the content providing server 10, the content recognizing service providing server 20, the multichannel video distribution server 30, the additional service information providing server 40, and the plurality of additional service providing servers 50 are one server. It may be combined in the form of or may be operated by one operator.
  • FIG. 34 is a block diagram illustrating a watermark based network topology according to an embodiment of the present invention.
  • the network topology according to an embodiment of the present invention further includes a watermark server 21.
  • the watermark server 21 as shown in FIG. 34 applies modification to the main audio and video content to insert content information into the main audio and video content.
  • the multichannel video distribution server 30 receives and distributes a broadcast signal including the modified main AV content.
  • the watermark server may use a digital watermarking technique as described below.
  • Digital watermarks are the process of embedding information in digital signals in a way that is difficult to delete.
  • the digital signal can be audio, photo, or video.
  • the inserted information is also contained in the copy.
  • One digital signal can carry several different watermarks at the same time.
  • the inserted information is discernible to the eye in the picture or video.
  • the inserted information is text or a logo that identifies the owner of the media.
  • a television station adds its logo to the corner of the video being sent, this is an eye identifiable watermark.
  • the duplication apparatus may obtain a watermark from the digital media before duplication of the digital media, and may decide whether to duplicate or not based on the content of the watermark.
  • Another application of watermarking is in tracking the source of digital media. At each point on the distribution path, a watermark is embedded in the digital media. If such digital media is found later, a watermark can be extracted from the digital media and the source of the distribution can be grasped from the content of the watermark.
  • the file format for digital media may include additional information called metadata, which is distinguished from metadata in that digital watermarks are conveyed in the audiovisual signal of digital media itself.
  • Watermarking methods include spread spectrum, quantization, and amplitude modulation.
  • the watermarking method corresponds to spread spectrum.
  • Spread-spectrum watermarks are known to be quite robust, but they do not carry much information because they interfere with the embedded host signal.
  • the watermarking method corresponds to the quantization type. Quantization watermarks are less robust, but can carry quite a bit of information.
  • the watermarking method corresponds to an amplitude modulation.
  • 35 is a ladder diagram illustrating a data flow in a watermark based network topology according to an embodiment of the present invention.
  • the content providing server 10 transmits a broadcast signal including the main audio and video content and the additional service (S101A).
  • the watermark server 21 receives a broadcast signal provided by the content providing server 10 and applies a modification to the main audiovisual content to insert a visible watermark such as a logo into the main audiovisual content, or to the main audiovisual content.
  • the watermark information is inserted as an invisible watermark, and the watermarked main AV content and the supplementary service are provided to the MVPD 30 (S103A).
  • the watermark information inserted through the invisible watermark may include one or more of watermark usage, content information, additional service information, and available additional services.
  • the watermark usage may indicate one of unauthorized copy protection, audience rating research, and additional service acquisition.
  • the content information may include identification information of a content provider that provides main audio and video content, main audio and video content identification information, main audio and video content rating information, time information of a content section used to acquire content information, a name of a channel on which main audio and video content is broadcast, and main One or more of a logo of a channel on which audiovisual content is broadcast, a description of a channel on which main audio and video content is broadcast, a usage information reporting address, a usage information reporting period, and a minimum usage time for obtaining usage information.
  • the time information of the content section used for obtaining the content information may be time information of the content section in which the used watermark is embedded. If the receiver 300 uses the fingerprint for obtaining the content information, the time information of the content section used for obtaining the content information may be time information of the content section from which the feature information is extracted.
  • the time information of the content section used to acquire the content information includes the start time of the content section used to acquire the content information, the duration of the content section used to acquire the content information, and the end time of the content section used to acquire the content information. It may include one or more of.
  • the usage information report address may include at least one of a main AV content viewing information report address and an additional service usage information report address.
  • the usage information reporting period may include one or more of a main audio and video content viewing information reporting period and an additional service usage information reporting period.
  • the minimum usage time for acquiring the usage information may include at least one of a minimum viewing time for acquiring the main AV content viewing information and a minimum usage time for extracting additional service usage information.
  • the receiver 300 Based on the case in which the main audio and video content is watched for a minimum viewing time, the receiver 300 obtains the viewing information of the main audio and video content, and reports the viewing information extracted to the main audio and video content viewing information reporting address in the main audio and video content viewing information reporting period. can do.
  • the receiver 300 may acquire the additional service usage information based on the case where the additional service is used for a minimum usage time and report the usage information extracted to the additional service usage information report address in the supplementary service usage information reporting period.
  • the supplementary service information includes information on whether an supplementary service exists, an supplementary service address providing server address, an acquisition path of each available supplementary service, an address for each available supplementary service, a start time of each available supplementary service, End time of each available supplementary service, lifetime of each available supplementary service, acquisition mode of each available supplementary service, request period for each available supplementary service, of each available supplementary service
  • One or more of priority information, a description of each available additional service, a category of each available additional service, a usage information reporting address, a usage information reporting period, and a minimum usage time for obtaining usage information. have.
  • the acquisition path of the available additional service may represent an IP based network or an ATSC Advanced Television Systems Committee-Mobile / Handheld (AT / M) channel.
  • AT / M ATSC Advanced Television Systems Committee-Mobile / Handheld
  • the additional service information may further include frequency information and channel information.
  • the acquisition mode of each available supplementary service may indicate Push or Pull.
  • the watermark server 21 may insert watermark information as an invisible watermark in the logo of the main audio and video content.
  • the watermark server 21 may insert a barcode at a predetermined position of the logo.
  • the predetermined position of the logo may correspond to the bottom 1 line of the area where the logo is displayed.
  • the receiver 300 may not display the barcode.
  • the watermark server 21 may insert watermark information in the form of metadata of a logo. At this time, the shape of the logo can be maintained.
  • the watermark server 21 may insert N-bit watermark information into each of the logos of the M frames. That is, the watermark server 21 may insert M * N watermark information through M frames.
  • the MVPD 30 receives a broadcast signal including watermarked main AV content and an additional service, generates a multiplexed signal, and provides the multiplexed signal to the set top box 60 (S105A).
  • the multiplexed signal may exclude the received additional service or include a new additional service.
  • the set-top box 60 tunes a channel selected by the user, receives a signal of the tuned channel, demodulates the received broadcast signal, performs channel decoding, and performs audio decoding to uncompress main audio and video content. After generating the, the generated uncompressed main audio and video content is provided to the receiver 300 (S106A).
  • the content providing server 10 also broadcasts a broadcast signal including the main audio and video content through a wireless channel (S107A).
  • the MVPD 30 may transmit a broadcast signal including the main audio and video content to the receiver 300 directly without passing through the set top box 60 (S108A).
  • the receiver 300 may receive uncompressed main audio and video content through the set top box 60. Alternatively, the receiver 300 may receive a broadcast signal through a wireless channel and demodulate and decode the received broadcast signal to obtain main AV content. Alternatively, the receiver 300 may receive a broadcast signal from the MVPD 30, demodulate and decode the received broadcast signal to receive main audio and video content.
  • the receiver 300 extracts watermark information from audio frames of some frames or some sections of the acquired main audio and video content. If the watermark information corresponds to the logo, the receiver 300 checks the watermark server address corresponding to the logo extracted from the correspondence between the plurality of logos and the plurality of watermark server addresses. If the watermark information corresponds to the logo, the receiver 300 cannot identify the main audio and video content using only the logo.
  • the receiver 300 may not identify the main AV content, but the watermark information may include the content provider identification information or the watermark server address.
  • the receiver 300 checks the watermark server address corresponding to the content provider identification information extracted from the correspondence between the plurality of content provider identification information and the plurality of watermark server addresses. Can be.
  • the receiver 300 accesses the watermark server 21 corresponding to the obtained watermark server address and transmits a first query (S109A). .
  • the watermark server 21 provides a first response to the first query in operation S111A.
  • the first response may include one or more of content information, additional service information, and available additional services.
  • the receiver 300 may not obtain the additional service. However, the watermark information and the first response may include the additional service address providing server address. As such, when the receiver 300 does not acquire the additional service address or the additional service through the watermark information and the first response and obtains the additional service address providing server address, the receiver 300 obtains the additional service address providing server.
  • the second service including the content information is transmitted by accessing the additional service information providing server 40 corresponding to the address (S119A).
  • the supplementary service information providing server 40 retrieves one or more available supplementary services related to the content information of the second query. Thereafter, the additional service information providing server 40 provides additional service information for one or more available additional services to the receiver 300 in a second response to the second query in operation S121A.
  • the receiver 300 accesses the one or more available additional service addresses and requests additional services (S123A). Obtain a service (S125A).
  • 36 is a view illustrating a watermark based content recognition timing according to an embodiment of the present invention.
  • the receiver 300 when the set top box 60 is turned on and tunes the channel, and the receiver 300 receives the main audio and video content of the tuned channel from the set top box 60 through the external input port 311.
  • the receiver 300 may detect a content provider identifier (or broadcaster identifier) from the watermark of the main AV content. Thereafter, the receiver 300 may detect content information from the watermark of the main AV content based on the detected content provider identifier.
  • the detectable period of the content provider identifier and the detectable period of the content information may be different.
  • the detectable period of the content provider identifier may be shorter than the detectable period of the content information.
  • the receiver 300 may have an efficient configuration for detecting only necessary information.
  • FIG. 37 is a block diagram illustrating a fingerprint based network topology according to an embodiment of the present invention.
  • the network topology according to an embodiment of the present invention further includes a fingerprint server 22.
  • the fingerprint server 22 as shown in FIG. 37 does not modify the main audio and video content, and extracts and stores feature information from some frames or some audio samples of the main audio and video content. Subsequently, when the fingerprint server 22 receives the feature information from the receiver 300, the fingerprint server 22 provides the identifier and time information of the audiovisual content corresponding to the received feature information.
  • FIG. 38 is a ladder diagram illustrating a data flow in a fingerprint based network topology according to an embodiment of the present invention.
  • the content providing server 10 transmits a broadcast signal including the main audio and video content and the additional service (S201A).
  • the fingerprint server 22 receives a broadcast signal provided by the content providing server 10, extracts a plurality of feature information from a plurality of frame sections or a plurality of audio sections of the main audio and video content, respectively, A database for a plurality of corresponding query results is constructed (S203A).
  • the query result may include one or more of content information, additional service information, and available additional services.
  • the MVPD 30 receives a broadcast signal including main AV content and an additional service, generates a multiplexed signal, and provides the multiplexed signal to the set top box 60 (S205A).
  • the multiplexed signal may exclude the received additional service or include a new additional service.
  • the set-top box 60 tunes a channel selected by the user, receives a signal of the tuned channel, demodulates the received broadcast signal, performs channel decoding, and performs audio decoding to uncompress main audio and video content. After generating the, the generated uncompressed main audio and video content is provided to the receiver 300 (S206A).
  • the content providing server 10 also broadcasts a broadcast signal including the main audio and video content through a wireless channel (S207A).
  • the MVPD 30 may transmit a signal including the main audio and video content to the receiver 300 directly without passing through the set top box 60 (S208A).
  • the receiver 300 may receive uncompressed main audio and video content through the set top box 60. Alternatively, the receiver 300 may receive a broadcast signal through a wireless channel and demodulate and decode the received broadcast signal to obtain main AV content. Alternatively, the receiver 300 may receive a broadcast signal from the MVPD 30, demodulate and decode the received broadcast signal to receive main audio and video content. The receiver 300 extracts feature information from audio samples of some frames or sections of the acquired main audio and video content in operation S213A.
  • the receiver 300 accesses the fingerprint server 22 corresponding to the preset fingerprint server address and transmits a first query including the extracted feature information (S215A).
  • the fingerprint server 22 provides a query result as a first response to the first query in operation S217A. If the first response corresponds to a failure, the receiver 300 may transmit a first query including feature information extracted by accessing the fingerprint server 22 corresponding to another fingerprint server address.
  • the fingerprint server 22 may provide an Extensible Markup Language (XML) document as a query result.
  • XML Extensible Markup Language
  • An example of an XML document containing a query result will be described with reference to FIG. 39 and Table 4.
  • FIG. 39 An example of an XML document containing a query result will be described with reference to FIG. 39 and Table 4.
  • FIG. 39 An example of an XML document containing a query result will be described with reference to FIG. 39 and Table 4.
  • 39 is an XML schema diagram of an ACR-Resulttype containing a query result according to an embodiment of the present invention.
  • an ACR-Resulttype containing a query result has a ResultCode attribute, ContentID, NTPTimestamp, SignalingChannelInformation, and ServiceInformation elements.
  • the ResultCode attribute has a value of 200, this may mean that the query result is successful. If the ResultCode attribute has a value of 404, this may mean that the query result has failed.
  • the SignalingChannelInformation element has a SignalingChannelURL element, and the SignalingChannelURL element has UpdateMode and PollingCycle attributes.
  • the UpdateMode property may have a Pull value or a Push value.
  • the ServiceInformation element has a ServiceName, ServiceLogo, and ServiceDescription element.
  • Table 4 shows the XML Schema of ACR-ResultType containing these query results.
  • an ATSC content identifier as shown in Table 5 below may be used.
  • the ATSC content identifier has a structure consisting of a TSID and a house number.
  • the 16 bit unsigned integer TSID carries a transport stream identifier.
  • the 5-bit unsigned integer end_of_day is set to the hour of the day when broadcast is over and the content_id value can be reused.
  • the 9-bit unsigned integer unique_for is set to the number of days for which the content_id value cannot be reused.
  • content_id represents a content identifier.
  • the receiver 300 decreases unique_for by 1 at a time corresponding to end_of_day every day, and considers content_id to be unique if unique_for is not 0.
  • a Global service identifier for an ATSC-M / H service as described below may be used.
  • the global service identifier has the form
  • ⁇ region> is a two letter international country code as defined by ISO 639-2.
  • ⁇ Xsid> for local service is a decimal number of TSID as defined in ⁇ region>, and ⁇ xsid> for local service (major> 69) is "0".
  • ⁇ serviceid> is defined as ⁇ major> or ⁇ minor>. ⁇ major> represents a major channel number, and ⁇ minor> represents a minor channel number.
  • an ATSC content identifier as described below may be used.
  • the ATSC Content Identifier has the following form:
  • ⁇ region> is a two letter international country code as defined by ISO 639-2.
  • ⁇ Xsid> for local service is a decimal number of TSID as defined in ⁇ region>, which may be followed by ".”
  • ⁇ Xsid> for regional service (major> 69) is ⁇ serviceid>.
  • ⁇ content_id> is the base64 sign of the content_id field defined in Table 5
  • ⁇ unique_for> is the decimal sign of the unique_for field defined in Table 5
  • ⁇ end_of_day> is the decimal sign of the end_of_day field defined in Table 5.
  • FIG. 38 will be described again.
  • the receiver 300 accesses the additional service information providing server 40 corresponding to the obtained additional service address providing server address.
  • the second query including the content information is transmitted.
  • the supplementary service information providing server 40 retrieves one or more available supplementary services related to the content information of the second query. Thereafter, the additional service information providing server 40 provides additional service information for one or more available additional services to the receiver 300 in a second response to the second query in operation S221A.
  • the receiver 300 accesses the one or more available additional service addresses to request additional services (S223A), and obtains additional services. (S225A).
  • the receiver 300 transmits an HTTP request to the supplementary service providing server 50 through SignalingChannelURL and sends an HTTP response including a PSIP binary stream in response to the supplementary service providing server 50.
  • the receiver 300 may transmit the HTTP request according to the polling period specified by the PollingCycle property.
  • the SignalingChannelURL element may have an update time attribute. In this case, the receiver 300 may transmit the HTTP request at the update time specified by the update time attribute.
  • the receiver 300 may asynchronously receive an update from the server by using the XMLHTTPRequest API. After the receiver 300 makes an asynchronous request to the server through the XMLHTTPRequest object, the server provides the signaling information as a response through this channel when there is a change in the signaling information. If there is a limit in the waiting time of the session, a session timeout respond is generated, and the receiver can immediately recognize and re-request it to maintain the signaling channel between the receiver and the server at all times.
  • FIG. 40 is a block diagram illustrating a watermark and fingerprint based network topology according to an embodiment of the present invention.
  • the network topology according to an embodiment of the present invention further includes a watermark server 21 and a fingerprint server 22.
  • the watermark server 21 as shown in FIG. 40 inserts content provider identification information into the main audiovisual content.
  • the watermark server 21 may insert the content provider identification information into the main audio and video content as a watermark that looks like a logo, or insert the content provider identification information into the main audio and video content as an invisible watermark.
  • the fingerprint server 22 does not modify the main audio and video content, and extracts and stores feature information from audio samples of some frames or sections of the main audio and video content. Subsequently, when the fingerprint server 22 receives the feature information from the receiver 300, the fingerprint server 22 provides the identifier and time information of the audiovisual content corresponding to the received feature information.
  • FIG. 41 is a ladder diagram illustrating a data flow in a watermark and fingerprint based network topology according to an embodiment of the present invention.
  • the content providing server 10 transmits a broadcast signal including the main audio and video content and the additional service (S301A).
  • the watermark server 21 receives a broadcast signal provided by the content providing server 10 and applies a modification to the main audiovisual content to insert a visible watermark such as a logo into the main audiovisual content, or to the main audiovisual content.
  • the watermark information is inserted as an invisible watermark, and the watermarked main AV content and the additional service are provided to the MVPD 30 (S303A).
  • the watermark information inserted through the invisible watermark may include one or more of content information, additional service information, and available additional services.
  • the content information and the additional service information are as described above.
  • the MVPD 30 receives a broadcast signal including watermarked main AV content and an additional service, generates a multiplexed signal, and provides the multiplexed signal to the set top box 60 (S305A).
  • the multiplexed signal may exclude the received additional service or include a new additional service.
  • the set-top box 60 tunes a channel selected by the user, receives a signal of the tuned channel, demodulates the received broadcast signal, performs channel decoding, and performs audio decoding to uncompress main audio and video content. After generating the, the generated uncompressed main audio and video content is provided to the receiver 300 (S306A).
  • the content providing server 10 also broadcasts a broadcast signal including the main audio and video content through a wireless channel (S307A).
  • the MVPD 30 may transmit a signal including the main audio and video content to the receiver 300 directly without passing through the set top box 60 (S308A).
  • the receiver 300 may receive uncompressed main audio and video content through the set top box 60. Alternatively, the receiver 300 may receive a broadcast signal through a wireless channel and demodulate and decode the received broadcast signal to obtain main AV content. Alternatively, the receiver 300 may receive a broadcast signal from the MVPD 30, demodulate and decode the received broadcast signal to receive main audio and video content.
  • the receiver 300 extracts watermark information from audio frames of some frames or some sections of the acquired main audio and video content. If the watermark information corresponds to the logo, the receiver 300 checks the watermark server address corresponding to the logo extracted from the correspondence between the plurality of logos and the plurality of watermark server addresses. If the watermark information corresponds to the logo, the receiver 300 cannot identify the main audio and video content using only the logo.
  • the receiver 300 may not identify the main AV content, but the watermark information may include the content provider identification information or the watermark server address.
  • the receiver 300 checks the watermark server address corresponding to the content provider identification information extracted from the correspondence between the plurality of content provider identification information and the plurality of watermark server addresses. Can be.
  • the receiver 300 accesses the watermark server 21 corresponding to the obtained watermark server address and transmits a first query (S309A). .
  • the watermark server 21 provides a first response to the first query in operation S311A.
  • the first response may include one or more of a fingerprint server address, content information, additional service information, and available additional services.
  • the content information and the additional service information are as described above.
  • the receiver 300 extracts feature information from audio samples of some frames or some sections of the main audio and video content (S313A).
  • the receiver 300 accesses the fingerprint server 22 corresponding to the fingerprint server address in the first response and transmits a second query including the extracted feature information (S315A).
  • the fingerprint server 22 provides a query result as a second response to the second query in operation S317A.
  • the receiver 300 accesses the additional service information providing server 40 corresponding to the obtained additional service address providing server address.
  • the third query including the content information is transmitted.
  • the supplementary service information providing server 40 retrieves one or more available supplementary services related to the content information of the third query. Thereafter, the additional service information providing server 40 provides additional service information for one or more available additional services to the receiver 300 in a third response to the third query in operation S321A.
  • the receiver 300 accesses the one or more available additional service addresses and requests additional services (S323A). Acquire an additional service (S325A).
  • FIG. 42 is a block diagram of a video display device according to another embodiment.
  • the receiver 300 includes a broadcast signal receiver 301, a demodulator 310, a channel decoder 305, a demultiplexer 320, and an audiovisual decoder. 309, an external input port 311, a playback control unit 313, a playback device 320, a service manager 350, a data transmission / reception unit 341, and a memory 350.
  • the broadcast signal receiver 301 receives a broadcast signal from the content providing server 10 or the MVPD 30.
  • the demodulator 310 demodulates the received broadcast signal to generate a demodulated signal.
  • the channel decoder 305 performs channel decoding on the demodulated signal to generate channel decoded data.
  • the demultiplexer 320 separates the main AV content and the supplementary service from the channel decoded data.
  • the separated additional service is stored in the additional service storage unit 352.
  • the audiovisual decoder 309 generates and uncompresses the main audiovisual content by AV decoding the separated main audiovisual content.
  • the external input port 311 receives uncompressed main audio and video content from the set top box 60, a digital versatile disk (DVD) player, a Blu-ray disc player, or the like.
  • the external input port 311 may include one or more of a DSUB port, a high definition multimedia interface (HDMI) port, a digital visual interface (DVI) port, a composite port, a component port, and an S-video port. have.
  • HDMI high definition multimedia interface
  • DVI digital visual interface
  • the reproduction control unit 313 reproduces at least one of the uncompressed main audio and video content generated by the audiovisual decoder 309 or the uncompressed main audio and video content received from the external input port 311 on the reproduction device 320 by user selection. do.
  • the playback device 320 includes a display unit 321 and a speaker 323.
  • the display unit 321 includes a liquid crystal display (LCD), a thin film transistor-liquid crystal display (TFT LCD), an organic light-emitting diode (OLED), and a flexible display (flexible). and at least one of a 3D display.
  • the service manager 350 obtains content information of the main audio and video content, and obtains an available additional service based on the obtained content information.
  • the service manager 350 may obtain identification information of the main audio and video content based on some frames or some sections of the audio sample of the uncompressed main audio and video content. contents recognition (ACR).
  • the data transceiver 341 may include an ATSC-M / H (Advanced Television Systems Committee-Mobile / Handheld) channel transceiver 341a and an IP transceiver 341b.
  • ATSC-M / H Advanced Television Systems Committee-Mobile / Handheld
  • the ATSC-M / H channel transceiver 341a communicates with another device or server through an ATSC-M / H channel.
  • the IP transceiver 341b communicates with another device or server through an IP-based network.
  • the memory 350 may include a flash memory type, a hard disk type, a multimedia card micro type, a card type memory (for example, SD or XD memory), RAM (Random Access Memory, RAM), Static Random Access Memory (SRAM), Read-Only Memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Programmable Read-Only Memory (PROM), Magnetic Memory, Magnetic It may include a storage medium of at least one type of disk, optical disk.
  • the receiver 300 may operate in association with a web storage that performs a storage function of the memory 350 on the Internet.
  • the memory 350 includes a content information storage unit 351, an additional service storage unit 352, a logo storage unit 353, a setting information storage unit 354, a bookmark storage unit 355, and a user information storage unit 356.
  • the usage information storage unit 357 may be included.
  • the content information storage unit 351 stores a plurality of content information corresponding to the plurality of feature information.
  • the additional service storage unit 352 may store a plurality of additional services corresponding to the plurality of feature information, or may store a plurality of additional services corresponding to the plurality of content information.
  • the logo storage unit 353 stores a plurality of logos.
  • the logo storage unit may further store a content provider identifier corresponding to the plurality of logos or a watermark server address corresponding to the plurality of logos.
  • the setting information storage unit 354 stores setting information for the ACR.
  • the bookmark storage unit 355 stores the bookmark.
  • the user information storage unit 356 stores user information.
  • the user information may include one or more of one or more account information, region information, family member information, preferred genre information, video display device information, and usage information providing range for one or more services.
  • the one or more account information may include account information for the usage information measuring server and account information of a social network service such as twitter and facebook.
  • Area information may include address information, postal code.
  • Family member information may include the number of family members, the age of each member, the gender of each member, the religion of each member, the occupation of each member, and the like.
  • Preferred genre information may be set to one or more of sports, movies, dramas, education, news, entertainment, and other genres.
  • the video display device information may include information about a type, a manufacturer, a firmware version, a resolution, a model name, an OS, a browser, a storage device, a storage device capacity, and a network speed.
  • the receiver 300 may collect and report the main AV content and the additional service usage information within the set range.
  • the usage information providing range may be set for each virtual channel.
  • the usage information measurement allowable range may be set for the entire physical channel.
  • the usage information storage unit 357 stores main audiovisual content viewing information and additional service usage information collected by the receiver 300.
  • the receiver 300 may analyze the service usage pattern based on the collected main audio and video content viewing information and the collected additional service usage information, and store the analyzed service usage pattern in the usage information storage unit 357.
  • the service manager 350 may obtain content information of the main AV content from the fingerprint server 22 or the content information storage unit 351. If there is no content information corresponding to the extracted feature information in the content information storage unit 351 or there is not enough content information, the service manager 350 may receive additional content information through the data transmission / reception unit 341. In addition, the service manager 350 may continuously update the content information.
  • the service manager 350 may obtain an additional service available from the additional service providing server 50 or the additional service storage 353. If there is no additional service in the additional service storage unit 353 or there is not enough additional service, the service manager 350 may update the additional service through the data transmission / reception unit 341. In addition, the service manager 350 may continuously update the additional service.
  • the service manager 350 may extract a logo from the main audio and video content, and query the logo storage unit 355 to obtain a content provider identifier or watermark server address corresponding to the extracted logo. If there is no logo that matches the extracted logo in the logo storage unit 355 or there is not enough logo, the service manager 350 may receive an additional logo through the data transmission / reception unit 341. In addition, the service manager 350 may continuously update the logo.
  • the service manager 350 may perform various methods to reduce the computational burden in comparing the logo extracted from the main audio and video content with the plurality of logos in the logo storage unit 355.
  • the service manager 350 may perform the comparison based on the color characteristic. That is, the service manager 350 may compare the color characteristics of the extracted logo with the color characteristics of the logo in the logo storage unit 355 to determine whether they match.
  • the service manager 350 may perform the comparison based on the character recognition. That is, the service manager 350 may determine whether there is a match by comparing the characters recognized from the extracted logo with the characters recognized from the logo in the logo storage unit 355.
  • the service manager 350 may perform the comparison based on the shape of the outline of the logo. That is, the service manager 350 may compare the contour shape of the extracted logo with the contour shape of the logo in the logo storage unit 355 and determine whether there is a match.
  • the service manager 350 obtains the content information of the main audio and video content based on some frames of the uncompressed main audio and video content or the audio sample of the section, and obtains the signaling data for the additional service based on the obtained content information.
  • the additional service may be acquired based on this signaling data.
  • the service manager 350 obtains content information of the main audio and video content based on some frames or some sections of the audio sample of the uncompressed main audio and video content, and obtains signaling data for the subtitle service based on the obtained content information. After that, a caption service can be obtained based on this signaling data.
  • the above-described broadcast service transmission method and reception method according to an embodiment of the present invention may be stored in a computer-readable recording medium that is produced as a program to be executed in a computer, and an example of a computer-readable recording medium may be a ROM. , RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, and the like, and also includes a carrier wave (for example, transmitted over the Internet).
  • a computer-readable recording medium may be a ROM. , RAM, CD-ROM, magnetic tape, floppy disk, optical data storage, and the like, and also includes a carrier wave (for example, transmitted over the Internet).
  • the computer readable recording medium can be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. And functional programs, codes and code segments for implementing the method can be easily deduced by programmers in the art to which the present invention belongs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

La présente invention se rapporte à un procédé de transmission d'un service de diffusion audiovisuelle, à un procédé de réception d'un service de diffusion audiovisuelle et à un appareil de réception d'un service de diffusion audiovisuelle. Selon l'un des modes de réalisation de la présente invention, le procédé de réception du service de diffusion audiovisuelle comprend les étapes consistant : à recevoir des données de signalisation de service de sous-titrage ; à reconnaître le type de flux de données contenant des données de sous-titrage sur la base des données de signalisation de service de sous-titrage ; et à extraire les données de sous-titrage sur la base du type de flux de données. Selon le mode de réalisation de la présente invention, les informations relatives à un programme audiovisuel peuvent être reçues et transmises par le biais d'un service non en temps réel.
PCT/KR2012/004513 2011-06-09 2012-06-08 Procédé de transmission de service de diffusion audiovisuelle, procédé de réception de service de diffusion audiovisuelle et appareil de réception de service de diffusion audiovisuelle Ceased WO2012169813A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161494901P 2011-06-09 2011-06-09
US61/494,901 2011-06-09

Publications (2)

Publication Number Publication Date
WO2012169813A2 true WO2012169813A2 (fr) 2012-12-13
WO2012169813A3 WO2012169813A3 (fr) 2013-03-28

Family

ID=47296611

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/004513 Ceased WO2012169813A2 (fr) 2011-06-09 2012-06-08 Procédé de transmission de service de diffusion audiovisuelle, procédé de réception de service de diffusion audiovisuelle et appareil de réception de service de diffusion audiovisuelle

Country Status (1)

Country Link
WO (1) WO2012169813A2 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015126426A1 (fr) * 2014-02-24 2015-08-27 Hewlett-Packard Development Company, L.P. Décodage d'une image principale à l'aide d'une image auxiliaire
WO2015126117A1 (fr) * 2014-02-23 2015-08-27 엘지전자 주식회사 Procédé et appareil d'émission et de réception d'un signal de diffusion
WO2017043836A1 (fr) * 2015-09-09 2017-03-16 엘지전자 주식회사 Dispositif d'émission de signal de radiodiffusion, dispositif de réception de signal de radiodiffusion, procédé d'émission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion
EP3468204A4 (fr) * 2016-05-31 2019-05-08 Sony Corporation Dispositif d'émission, procédé d'émission, dispositif de réception, et procédé de réception
CN113438518A (zh) * 2015-07-06 2021-09-24 Lg电子株式会社 处理广播数据的方法、接收系统和发送系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0621775D0 (en) * 2006-11-01 2006-12-13 Sony Uk Ltd Recording apparatus
KR101520692B1 (ko) * 2007-12-11 2015-05-15 엘지전자 주식회사 디지털 방송 수신기 및 데이터 처리 방법
KR101581359B1 (ko) * 2008-06-09 2015-12-30 엘지전자 주식회사 방송 신호 수신 방법 및 수신 시스템

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015126117A1 (fr) * 2014-02-23 2015-08-27 엘지전자 주식회사 Procédé et appareil d'émission et de réception d'un signal de diffusion
US9860574B2 (en) 2014-02-23 2018-01-02 Lg Electronics Inc. Method and apparatus for transceiving broadcast signal
WO2015126426A1 (fr) * 2014-02-24 2015-08-27 Hewlett-Packard Development Company, L.P. Décodage d'une image principale à l'aide d'une image auxiliaire
US9953199B2 (en) 2014-02-24 2018-04-24 Hewlett-Packard Development Company, L.P. Decoding a main image using an auxiliary image
CN113438518A (zh) * 2015-07-06 2021-09-24 Lg电子株式会社 处理广播数据的方法、接收系统和发送系统
CN113438518B (zh) * 2015-07-06 2023-02-28 Lg电子株式会社 处理广播数据的方法、接收系统和发送系统
WO2017043836A1 (fr) * 2015-09-09 2017-03-16 엘지전자 주식회사 Dispositif d'émission de signal de radiodiffusion, dispositif de réception de signal de radiodiffusion, procédé d'émission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion
EP3349470A4 (fr) * 2015-09-09 2019-01-16 LG Electronics Inc. Dispositif d'émission de signal de radiodiffusion, dispositif de réception de signal de radiodiffusion, procédé d'émission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion
US10237591B2 (en) 2015-09-09 2019-03-19 Lg Electronics Inc. Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
EP3468204A4 (fr) * 2016-05-31 2019-05-08 Sony Corporation Dispositif d'émission, procédé d'émission, dispositif de réception, et procédé de réception

Also Published As

Publication number Publication date
WO2012169813A3 (fr) 2013-03-28

Similar Documents

Publication Publication Date Title
WO2012091322A1 (fr) Procédé de transmission de service audiovisuel, procédé de réception de service audiovisuel et appareil de réception de service audiovisuel
WO2012161535A2 (fr) Procédé permettant de transmettre un service de diffusion, appareil permettant de le recevoir, et procédé permettant de traiter un service supplémentaire en utilisant l'appareil permettant de le recevoir
WO2013022309A1 (fr) Procédé d'émission de service de radiodiffusion, procédé de réception de service de radiodiffusion et appareil pour recevoir un service de radiodiffusion
WO2012091371A1 (fr) Procédés d'émission et de réception de service de diffusion et appareil de réception du service de diffusion
WO2012144867A2 (fr) Procédé de transmission pour service de radiodiffusion, procédé de réception associé, et appareil de réception associé
WO2013058633A1 (fr) Procédé de réception de service de diffusion et appareil de réception de service de diffusion
WO2012169779A2 (fr) Procédé permettant de transmettre et de recevoir un service de radiodiffusion et dispositif récepteur associé
WO2010021526A2 (fr) Procédé de traitement d'informations supplémentaires relatives à un service ou contenu annoncé dans un service en temps non réel et récepteur de diffusion
WO2012091370A1 (fr) Procédé de transmission de service de diffusion, et procédé et appareil pour le recevoir
WO2012173441A2 (fr) Procédé d'émission d'un service de diffusion, procédé de réception d'un service de diffusion et appareil de réception d'un service de diffusion
WO2011049278A1 (fr) Procédé pour traiter des informations de programme de diffusion et récepteur de diffusion
WO2017007224A1 (fr) Dispositif d'émission de signal de radiodiffusion, dispositif de réception de signal de radiodiffusion, procédé d'émission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion
WO2014025207A1 (fr) Procédé et appareil pour traiter un signal de diffusion contenant un service de radiodiffusion interactive
WO2013042902A1 (fr) Procédé de réception de service de diffusion et dispositif de réception correspondant
WO2014035130A1 (fr) Procédé et appareil de traitement de signal de service numérique
WO2014030924A1 (fr) Appareil et procédé de traitement d'un service interactif
WO2009151265A2 (fr) Procédé et système pour recevoir des signaux de radiodiffusion
WO2016171496A1 (fr) Dispositif d'émission de signal de radiodiffusion, dispositif de réception de signal de radiodiffusion, procédé d'émission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion
WO2010068033A2 (fr) Procédé de traitement de service en temps différé et récepteur de diffusion
WO2013119082A1 (fr) Appareil d'affichage d'image et procédé de fonctionnement associé
WO2012099427A2 (fr) Procédé permettant de transmettre un service de diffusion, procédé permettant de recevoir un service de diffusion et appareil permettant de recevoir un service de diffusion
WO2012111979A2 (fr) Procédé d'émission d'un service de radiodiffusion, procédé de réception d'un service de radiodiffusion, et appareil de réception d'un service de radiodiffusion
WO2014042368A1 (fr) Appareil et procédé de traitement d'un service interactif
WO2011122838A2 (fr) Procédé de traitement de service sans contrainte temps réel et récepteur de diffusion
WO2011112053A2 (fr) Système de traitement de service de diffusion non en temps réel et son procédé de traitement

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12796234

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12796234

Country of ref document: EP

Kind code of ref document: A2