WO2015167200A1 - 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 - Google Patents
방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 Download PDFInfo
- Publication number
- WO2015167200A1 WO2015167200A1 PCT/KR2015/004217 KR2015004217W WO2015167200A1 WO 2015167200 A1 WO2015167200 A1 WO 2015167200A1 KR 2015004217 W KR2015004217 W KR 2015004217W WO 2015167200 A1 WO2015167200 A1 WO 2015167200A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data
- fragment
- information
- broadcast signal
- packet
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 128
- 230000011664 signaling Effects 0.000 claims abstract description 263
- 230000005540 biological transmission Effects 0.000 claims abstract description 114
- 239000000872 buffer Substances 0.000 claims description 95
- 230000008054 signal transmission Effects 0.000 claims description 89
- 238000013507 mapping Methods 0.000 claims description 81
- 230000036961 partial effect Effects 0.000 claims description 9
- 238000012546 transfer Methods 0.000 claims description 8
- 230000003139 buffering effect Effects 0.000 claims description 6
- 230000000694 effects Effects 0.000 abstract description 8
- 239000012634 fragment Substances 0.000 description 552
- 239000010410 layer Substances 0.000 description 83
- 101000596046 Homo sapiens Plastin-2 Proteins 0.000 description 73
- 102100035182 Plastin-2 Human genes 0.000 description 73
- 238000010586 diagram Methods 0.000 description 70
- 102100037812 Medium-wave-sensitive opsin 1 Human genes 0.000 description 54
- 108091006146 Channels Proteins 0.000 description 49
- 230000008569 process Effects 0.000 description 40
- 238000012545 processing Methods 0.000 description 33
- 230000008439 repair process Effects 0.000 description 28
- 101000596041 Homo sapiens Plastin-1 Proteins 0.000 description 27
- 102100035181 Plastin-1 Human genes 0.000 description 27
- 239000000284 extract Substances 0.000 description 27
- 239000012092 media component Substances 0.000 description 20
- 238000003780 insertion Methods 0.000 description 18
- 230000037431 insertion Effects 0.000 description 18
- 230000006835 compression Effects 0.000 description 17
- 238000007906 compression Methods 0.000 description 17
- AWSBQWZZLBPUQH-UHFFFAOYSA-N mdat Chemical compound C1=C2CC(N)CCC2=CC2=C1OCO2 AWSBQWZZLBPUQH-UHFFFAOYSA-N 0.000 description 17
- 238000006243 chemical reaction Methods 0.000 description 14
- 230000006870 function Effects 0.000 description 14
- 230000006978 adaptation Effects 0.000 description 13
- 230000008859 change Effects 0.000 description 11
- 230000003068 static effect Effects 0.000 description 10
- 238000007726 management method Methods 0.000 description 8
- 239000011159 matrix material Substances 0.000 description 8
- 238000012986 modification Methods 0.000 description 7
- 230000004048 modification Effects 0.000 description 7
- 230000004044 response Effects 0.000 description 7
- 230000001174 ascending effect Effects 0.000 description 6
- 230000007246 mechanism Effects 0.000 description 6
- 230000002829 reductive effect Effects 0.000 description 6
- 230000011218 segmentation Effects 0.000 description 6
- 238000003860 storage Methods 0.000 description 6
- 230000002123 temporal effect Effects 0.000 description 6
- 239000000969 carrier Substances 0.000 description 5
- 238000001514 detection method Methods 0.000 description 5
- 240000002791 Brassica napus Species 0.000 description 4
- 238000013461 design Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000009467 reduction Effects 0.000 description 4
- 238000009877 rendering Methods 0.000 description 4
- 239000012141 concentrate Substances 0.000 description 3
- 238000012937 correction Methods 0.000 description 3
- 238000012217 deletion Methods 0.000 description 3
- 230000037430 deletion Effects 0.000 description 3
- 238000002716 delivery method Methods 0.000 description 3
- 238000005304 joining Methods 0.000 description 3
- 230000033001 locomotion Effects 0.000 description 3
- 238000001824 photoionisation detection Methods 0.000 description 3
- 230000002441 reversible effect Effects 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 150000001875 compounds Chemical class 0.000 description 2
- 238000006731 degradation reaction Methods 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 230000001419 dependent effect Effects 0.000 description 2
- 238000009826 distribution Methods 0.000 description 2
- 235000007682 pyridoxal 5'-phosphate Nutrition 0.000 description 2
- 238000004904 shortening Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000004913 activation Effects 0.000 description 1
- 230000003044 adaptive effect Effects 0.000 description 1
- 230000002730 additional effect Effects 0.000 description 1
- 230000036626 alertness Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 239000000470 constituent Substances 0.000 description 1
- 238000005388 cross polarization Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000013213 extrapolation Methods 0.000 description 1
- 238000001125 extrusion Methods 0.000 description 1
- 238000005562 fading Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 238000001997 free-flow electrophoresis Methods 0.000 description 1
- 239000002346 layers by function Substances 0.000 description 1
- 230000000670 limiting effect Effects 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 230000021715 photosynthesis, light harvesting Effects 0.000 description 1
- 230000010287 polarization Effects 0.000 description 1
- 230000006798 recombination Effects 0.000 description 1
- 238000005215 recombination Methods 0.000 description 1
- 238000011946 reduction process Methods 0.000 description 1
- 239000000344 soap Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
-
- 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/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
- H04N21/4383—Accessing a communication channel
- H04N21/4384—Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
-
- 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/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
-
- 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client
- H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
- H04N21/643—Communication protocols
Definitions
- the present invention relates to a broadcast signal transmission apparatus, a broadcast signal reception apparatus, and a broadcast signal transmission and reception method.
- the digital broadcast signal may include a larger amount of video / audio data than the analog broadcast signal, and may further include various types of additional data as well as the video / audio data.
- the digital broadcasting system may provide high definition (HD) images, multichannel audio, and various additional services.
- HD high definition
- data transmission efficiency for a large amount of data transmission, robustness of a transmission / reception network, and network flexibility in consideration of a mobile receiving device should be improved.
- the apparatus for transmitting broadcast signals is included in at least one content component of a service and recovered individually.
- a delivery object generator for generating at least one delivery object;
- Signaling Encoder for generating signaling information providing for the discovery and acquisition of the service and the at least one content component, wherein the signaling information is a transport session for transmitting the at least one content component of the service and the transport session Includes first information about at least one delivery object transmitted via;
- a transmitter for transmitting the at least one delivery object and the signaling information through a unidirectional channel.
- the delivery object comprises one of a file, a part of the file, a group of the file, a Hyper Text Transfer Protocol (HTTP) Entity, and a group of the HTTP Entity. It can be one.
- HTTP Hyper Text Transfer Protocol
- the signaling information may further include second information including a description of the DASH Media Presentation corresponding to the service.
- the signaling information may further include offset information indicating a position of a first byte of a payload of a transport protocol packet for transmitting the delivery object.
- the signaling information may further include real time information indicating whether the at least one delivery object transmits a streaming service.
- the signaling information may further include mapping information for mapping the transport session to a Transport Session Identifier (TSI) and mapping the delivery object to a Transport Object Identifier (TOI).
- TSI Transport Session Identifier
- TOI Transport Object Identifier
- the signaling information may further include time stamp information indicating time information of the delivery object.
- the present invention proposes a broadcast signal receiving apparatus.
- the apparatus for receiving broadcast signals includes a signaling decoder for extracting signaling information for providing discovery and acquisition of at least one content component of a service, and the signaling information is transmitted for transmitting the at least one content component of the service.
- the delivery object is included in at least one content component of the service and recovered individually;
- a delivery object processor for restoring the at least one delivery object;
- a media decoder for decoding the at least one delivery object.
- the first information includes offset information indicating a position of a first byte of a payload of a transport protocol packet transmitting the delivery object, and real time information indicating whether the at least one delivery object transmits a streaming service.
- At least one of mapping information for mapping the transport session to a Transport Session Identifier (TSI) and mapping the delivery object to a Transport Object Identifier (TOI), and time stamp information indicating time information for the delivery object. can be.
- the signaling information may further include second information including a description of the DASH Media Presentation corresponding to the service.
- said delivery object processor comprises: a transport protocol client for parsing said transport protocol packet to recover at least one delivery object; And a buffer / control unit for buffering the delivery object and delivering the delivery object to the media decoder.
- said delivery object processor comprises: a transport protocol client for parsing said transport protocol packet to recover at least one delivery object; An HTTP Entity generator for generating at least one HTTP Entity based on the delivery object and the signaling information, the HTTP Entity including an HTTP Entity body including an HTTP Entity header and the at least one delivery object; An internal HTTP server configured to store the at least one HTTP entity; And a DASH client requesting the at least one delivery object from the internal HTTP server based on the second information, and delivering the delivery object to the media decoder.
- the HTTP Entity header is a Content-Length field indicating the size of the HTTP Entity body, a Content-Location field including a resource address for the HTTP Entity, within a full HTTP Entity body (full HTTP Entity-payload) It may include at least one of a Content-Range field indicating a location of a partial HTTP Entity-payload, and an Expires field indicating date / time information capable of receiving a valid request.
- the delivery object processor comprises: a packet client for parsing at least one packet transmitting the service to restore the HTTP entity; A transport protocol converter for converting the HTTP entity into at least one transport protocol packet based on second information including a description of the DASH Media Presentation corresponding to the service; A transport protocol client for parsing the transport protocol packet to recover at least one delivery object; And a buffer / control unit for buffering the delivery object and delivering the delivery object to the media decoder.
- the present invention can provide various broadcast services by processing data according to service characteristics to control a quality of service (QoS) for each service or service component.
- QoS quality of service
- the present invention can achieve transmission flexibility by transmitting various broadcast services through the same radio frequency (RF) signal bandwidth.
- RF radio frequency
- the present invention can improve data transmission efficiency and robustness of transmission and reception of broadcast signals using a multiple-input multiple-output (MIMO) system.
- MIMO multiple-input multiple-output
- the present invention it is possible to provide a broadcast signal transmission and reception method and apparatus capable of receiving a digital broadcast signal without errors even when using a mobile reception device or in an indoor environment.
- the broadcast signal transmission apparatus has an effect of reducing a transmission waiting time for transmitting multimedia content.
- the broadcast signal receiving apparatus has an effect of reducing the reproduction waiting time for playing the multimedia content.
- FIG. 1 shows a structure of a broadcast signal transmission apparatus for a next generation broadcast service according to an embodiment of the present invention.
- FIG 2 illustrates an input formatting block according to an embodiment of the present invention.
- FIG 3 illustrates an input formatting block according to another embodiment of the present invention.
- BICM bit interleaved coding & modulation
- FIG. 5 illustrates a BICM block according to another embodiment of the present invention.
- FIG. 6 illustrates a frame building block according to an embodiment of the present invention.
- FIG 7 illustrates an orthogonal frequency division multiplexing (OFDM) generation block according to an embodiment of the present invention.
- OFDM orthogonal frequency division multiplexing
- FIG. 8 illustrates a structure of a broadcast signal receiving apparatus for a next generation broadcast service according to an embodiment of the present invention.
- FIG. 9 shows a frame structure according to an embodiment of the present invention.
- FIG. 10 illustrates a signaling hierarchy structure of a frame according to an embodiment of the present invention.
- FIG 11 illustrates preamble signaling data according to an embodiment of the present invention.
- FIG 13 illustrates PLS2 data according to an embodiment of the present invention.
- FIG 14 illustrates PLS2 data according to another embodiment of the present invention.
- FIG. 15 illustrates a logical structure of a frame according to an embodiment of the present invention.
- PLS 16 illustrates physical layer signaling (PLS) mapping according to an embodiment of the present invention.
- EAC emergency alert channel
- FEC forward error correction
- 21 illustrates the basic operation of a twisted row-column block interleaver according to an embodiment of the present invention.
- FIG. 22 illustrates an operation of a twisted row-column block interleaver according to another embodiment of the present invention.
- FIG. 23 illustrates a diagonal read pattern of a twisted row-column block interleaver according to an embodiment of the present invention.
- FIG. 24 illustrates XFECBLOCKs interleaved from each interleaving array according to an embodiment of the present invention.
- 25 is a diagram illustrating data processing time when the FLUTE protocol is used.
- FIG. 26 illustrates a ROUTE protocol stack according to an embodiment of the present invention.
- FIG. 27 illustrates a data structure of file-based multimedia content according to an embodiment of the present invention.
- FIG. 28 is a diagram illustrating a media segment configuration of MPEG-DASH to which a data structure is applied according to an embodiment of the present invention.
- 29 is a diagram illustrating data processing time using a ROUTE protocol according to an embodiment of the present invention.
- FIG. 30 is a view showing the structure of an LCT packet for transmitting a file according to an embodiment of the present invention.
- FIG. 31 is a view showing the structure of an LCT packet for transmitting a file according to an embodiment of the present invention.
- FIG. 32 is a diagram illustrating real-time broadcast assistance information signaling using an FDT according to an embodiment of the present invention.
- FIG 33 is a diagram illustrating a configuration of a broadcast signal transmission apparatus according to an embodiment of the present invention.
- 34 is a diagram illustrating a configuration of a broadcast signal transmission apparatus according to an embodiment of the present invention.
- 35 is a flowchart illustrating a real-time generation and transmission process of file-based multimedia content according to an embodiment of the present invention.
- 36 is a flowchart illustrating a process of generating a packet using a packetizer in detail by a broadcast signal transmission apparatus according to an embodiment of the present invention.
- FIG. 37 is a flowchart illustrating a real-time generation / transmission process of file-based multimedia content according to an embodiment of the present invention.
- FIG. 38 illustrates a structure of a file-based multimedia content receiver according to an embodiment of the present invention.
- 39 illustrates a structure of a file-based multimedia content receiver according to an embodiment of the present invention.
- FIG. 40 is a diagram illustrating a real-time reception / consumption process of file-based multimedia content according to an embodiment of the present invention.
- 41 is a diagram illustrating a real-time reception / consumption process of file-based multimedia content according to an embodiment of the present invention.
- FIG. 42 is a diagram showing the structure of a packet including object type information according to another embodiment of the present invention.
- 43 is a diagram showing the structure of a packet including object type information according to another embodiment of the present invention.
- 44 is a diagram illustrating a structure of a broadcast signal receiving apparatus using object type information according to another embodiment of the present invention.
- 45 is a diagram illustrating a structure of a broadcast signal receiving apparatus using object type information according to another embodiment of the present invention.
- 46 is a diagram showing the structure of a packet including type information according to another embodiment of the present invention.
- FIG. 48 is a diagram showing the structure of a packet including mapping information according to another embodiment of the present invention.
- 49 is a diagram showing the structure of an LCT packet including grouping information according to another embodiment of the present invention.
- 50 is a diagram illustrating grouping of a session and an object according to another embodiment of the present invention.
- 51 is a diagram illustrating a structure of a broadcast signal transmission apparatus using packet information according to another embodiment of the present invention.
- FIG. 52 is a diagram illustrating a structure of a broadcast signal receiving apparatus using packet information according to another embodiment of the present invention.
- 53 is a diagram illustrating a structure of a broadcast signal receiving apparatus using packet information according to another embodiment of the present invention.
- FIG. 54 is a diagram illustrating a structure of a broadcast signal receiving apparatus using packet information according to another embodiment of the present invention.
- 55 is a diagram illustrating a structure of a broadcast signal receiving apparatus using packet information according to another embodiment of the present invention.
- 56 is a diagram showing the structure of a packet including priority information according to another embodiment of the present invention.
- 57 is a diagram showing the structure of a packet including priority information according to another embodiment of the present invention.
- 58 is a diagram showing the structure of a packet including offset information according to another embodiment of the present invention.
- RAP random access point
- RAP random access point
- 61 is a diagram showing the structure of a packet including real time information according to another embodiment of the present invention.
- FIG. 62 is a diagram showing the structure of a broadcast signal transmission apparatus according to another embodiment of the present invention.
- FIG. 63 is a diagram showing the structure of a broadcast signal receiving apparatus according to another embodiment of the present invention.
- 64 is a diagram showing the structure of a broadcast signal transmission apparatus according to another embodiment of the present invention.
- 65 is a diagram illustrating a structure of a broadcast signal receiving apparatus according to another embodiment of the present invention.
- 66 is a diagram illustrating a structure of a broadcast signal receiving apparatus according to another embodiment of the present invention.
- 67 is a diagram illustrating a structure of a broadcast signal receiving apparatus according to another embodiment of the present invention.
- FIG. 68 is a diagram illustrating a method of configuring an HTTP Entity header according to another embodiment of the present invention.
- 69 is a diagram showing the structure of a broadcast signal receiving apparatus according to another embodiment of the present invention.
- 70 is a view showing a configuration method of an HTTP entity header according to another embodiment of the present invention.
- 71 is a flowchart of a broadcast signal transmission method according to another embodiment of the present invention.
- 72 is a flowchart illustrating a broadcast signal receiving method according to another embodiment of the present invention.
- the present invention provides an apparatus and method for transmitting and receiving broadcast signals for next generation broadcast services.
- the next generation broadcast service includes a terrestrial broadcast service, a mobile broadcast service, a UHDTV service, and the like.
- a broadcast signal for a next generation broadcast service may be processed through a non-multiple input multiple output (MIMO) or MIMO scheme.
- MIMO multiple input multiple output
- the non-MIMO scheme may include a multiple input single output (MISO) scheme, a single input single output (SISO) scheme, and the like.
- the MISO or MIMO scheme uses two antennas, but the present invention can be applied to a system using two or more antennas.
- the present invention can define three physical profiles (base, handheld, advanced) that are optimized to minimize receiver complexity while achieving the performance required for a particular application. have.
- the physical profile is a subset of all the structures that the corresponding receiver must implement.
- the three physical profiles share most of the functional blocks, but differ slightly in certain blocks and / or parameters. Further physical profiles can be defined later.
- a future profile may be multiplexed with a profile present in a single radio frequency (RF) channel through a future extension frame (FEF). Details of each physical profile will be described later.
- RF radio frequency
- FEF future extension frame
- the base profile mainly indicates the main use of a fixed receiving device in connection with a roof-top antenna.
- the base profile can be moved to any place but can also include portable devices that fall into a relatively stationary reception category.
- the use of the base profile can be extended for handheld devices or vehicles with some improved implementation, but such use is not expected in base profile receiver operation.
- the target signal-to-noise ratio range of reception is approximately 10-20 dB, which includes the 15 dB signal-to-noise ratio receiving capability of existing broadcast systems (eg, ATSC A / 53). Receiver complexity and power consumption are not as important as in battery powered handheld devices that will use the handheld profile. Key system parameters for the base profile are listed in Table 1 below.
- the handheld profile is designed for use in battery powered handheld and in-vehicle devices.
- the device may move at pedestrian or vehicle speed.
- the power consumption as well as the receiver complexity is very important for the implementation of devices in the handheld profile.
- the target signal-to-noise ratio range of the handheld profile is approximately 0-10 dB, but can be set to reach below 0 dB if intended for lower indoor reception.
- the advance profile provides higher channel capability in exchange for greater execution complexity.
- the profile requires the use of MIMO transmission and reception, and the UHDTV service is a target use, for which the profile is specifically designed.
- the enhanced capability may also be used to allow for an increase in the number of services at a given bandwidth, for example multiple SDTV or HDTV services.
- the target signal to noise ratio range of the advanced profile is approximately 20 to 30 dB.
- MIMO transmissions initially use existing elliptic polarization transmission equipment and can later be extended to full power cross polarization transmissions. Key system parameters for the advance profile are listed in Table 3 below.
- the base profile may be used as a profile for both terrestrial broadcast service and mobile broadcast service. That is, the base profile can be used to define the concept of a profile that includes a mobile profile. Also, the advanced profile can be divided into an advanced profile for the base profile with MIMO and an advanced profile for the handheld profile with MIMO. The three profiles can be changed according to the designer's intention.
- Auxiliary stream A sequence of cells carrying data of an undefined modulation and coding that can be used as a future extension or as required by a broadcaster or network operator.
- Base data pipe a data pipe that carries service signaling data
- Baseband Frame (or BBFRAME): A set of Kbch bits that form the input for one FEC encoding process (BCH and LDPC encoding).
- Coded block one of an LDPC encoded block of PLS1 data or an LDPC encoded block of PLS2 data
- Data pipe a logical channel in the physical layer that carries service data or related metadata that can carry one or more services or service components
- Data pipe unit A basic unit that can allocate data cells to data pipes in a frame
- Data symbol OFDM symbol in a frame that is not a preamble symbol (frame signaling symbols and frame edge symbols are included in the data symbols)
- DP_ID This 8-bit field uniquely identifies a data pipe within the system identified by SYSTEM_ID.
- Dummy cell A cell that carries a pseudo-random value used to fill the remaining unused capacity for physical layer signaling (PLS) signaling, data pipes, or auxiliary streams.
- PLS physical layer signaling
- FAC Emergency alert channel
- Frame A physical layer time slot starting with a preamble and ending with a frame edge symbol.
- Frame repetition unit A set of frames belonging to the same or different physical profile that contains an FEF that is repeated eight times in a super-frame.
- FEC Fast information channel
- FECBLOCK set of LDPC encoded bits of data pipe data
- FFT size The nominal FFT size used for a particular mode equal to the active symbol period Ts expressed in cycles of the fundamental period T.
- Frame signaling symbol The higher pilot density used at the start of a frame in a particular combination of FFT size, guard interval, and scattered pilot pattern, which carries a portion of the PLS data. Having OFDM symbol
- Frame edge symbol An OFDM symbol with a higher pilot density used at the end of the frame in a particular combination of FFT size, guard interval, and scatter pilot pattern.
- Frame-group set of all frames with the same physical profile type in a superframe
- Future extention frame A physical layer time slot within a super frame that can be used for future expansion, starting with a preamble.
- Futurecast UTB system A proposed physical layer broadcast system whose input is one or more MPEG2-TS or IP (Internet protocol) or generic streams and the output is an RF signal.
- Input stream A stream of data for the coordination of services delivered to the end user by the system.
- Normal data symbols data symbols except frame signaling symbols and frame edge symbols
- PHY profile A subset of all structures that the corresponding receiver must implement
- PLS physical layer signaling data consisting of PLS1 and PLS2
- PLS1 The first set of PLS data carried in a frame signaling symbol (FSS) with fixed size, coding, and modulation that conveys basic information about the system as well as the parameters needed to decode PLS2.
- FSS frame signaling symbol
- PLS2 The second set of PLS data sent to the FSS carrying more detailed PLS data about data pipes and systems.
- PLS2 dynamic data PLS2 data that changes dynamically from frame to frame
- PLS2 static data PLS2 data that is static during the duration of a frame group
- Preamble signaling data signaling data carried by the preamble symbol and used to identify the basic mode of the system
- Preamble symbol a fixed length pilot symbol carrying basic PLS data and positioned at the beginning of a frame
- Preamble symbols are primarily used for fast initial band scans to detect system signals, their timings, frequency offsets, and FFT sizes.
- Superframe set of eight frame repeat units
- Time interleaving block A set of cells in which time interleaving is performed, corresponding to one use of time interleaver memory.
- Time interleaving group A unit in which dynamic capacity allocation is performed for a particular data pipe, consisting of an integer, the number of XFECBLOCKs that change dynamically.
- a time interleaving group can be directly mapped to one frame or mapped to multiple frames.
- the time interleaving group may include one or more time interleaving blocks.
- Type 1 DP A data pipe in a frame where all data pipes are mapped to frames in a time division multiplexing (TDM) manner.
- Type 2 DPs Types of data pipes in a frame where all data pipes are mapped to frames in an FDM fashion.
- XFECBLOCK set of N cells cells carrying all the bits of one LDPC FECBLOCK
- FIG. 1 shows a structure of a broadcast signal transmission apparatus for a next generation broadcast service according to an embodiment of the present invention.
- a broadcast signal transmission apparatus for a next generation broadcast service includes an input format block 1000, a bit interleaved coding & modulation (BICM) block 1010, and a frame building block 1020, orthogonal frequency division multiplexing (OFDM) generation block (OFDM generation block) 1030, and signaling generation block 1040. The operation of each block of the broadcast signal transmission apparatus will be described.
- BICM bit interleaved coding & modulation
- OFDM generation block orthogonal frequency division multiplexing
- signaling generation block 1040 The operation of each block of the broadcast signal transmission apparatus will be described.
- IP streams / packets and MPEG2-TS are the main input formats and other stream types are treated as general streams.
- management information is input to control the scheduling and allocation of the corresponding bandwidth for each input stream.
- One or multiple TS streams, IP streams and / or general stream inputs are allowed at the same time.
- the input format block 1000 can demultiplex each input stream into one or multiple data pipes to which independent coding and modulation is applied.
- the data pipe is the basic unit for controlling robustness, which affects the quality of service (QoS).
- QoS quality of service
- One or multiple services or service components may be delivered by one data pipe. Detailed operations of the input format block 1000 will be described later.
- a data pipe is a logical channel at the physical layer that carries service data or related metadata that can carry one or multiple services or service components.
- the data pipe unit is a basic unit for allocating data cells to data pipes in one frame.
- parity data is added for error correction and the encoded bit stream is mapped to a complex value constellation symbol.
- the symbols are interleaved over the specific interleaving depth used for that data pipe.
- MIMO encoding is performed at BICM block 1010 and additional data paths are added to the output for MIMO transmission. Detailed operations of the BICM block 1010 will be described later.
- the frame building block 1020 may map data cells of an input data pipe to OFDM solid balls within one frame. After mapping, frequency interleaving is used for frequency domain diversity, in particular to prevent frequency selective fading channels. Detailed operations of the frame building block 1020 will be described later.
- the OFDM generation block 1030 can apply existing OFDM modulation having a cyclic prefix as the guard interval.
- a distributed MISO scheme is applied across the transmitter.
- a peak-to-average power ratio (PAPR) scheme is implemented in the time domain.
- PAPR peak-to-average power ratio
- the proposal provides a variety of FFT sizes, guard interval lengths, and sets of corresponding pilot patterns. Detailed operations of the OFDM generation block 1030 will be described later.
- the signaling generation block 1040 may generate physical layer signaling information used for the operation of each functional block.
- the signaling information is also transmitted such that the service of interest is properly recovered at the receiver side. Detailed operations of the signaling generation block 1040 will be described later.
- 2 illustrates an input format block according to an embodiment of the present invention. 2 shows an input format block when the input signal is a single input stream.
- the input format block illustrated in FIG. 2 corresponds to an embodiment of the input format block 1000 described with reference to FIG. 1.
- Input to the physical layer may consist of one or multiple data streams. Each data stream is carried by one data pipe.
- the mode adaptation module slices the input data stream into a data field of a baseband frame (BBF).
- BBF baseband frame
- the system supports three types of input data streams: MPEG2-TS, IP, and GS (generic stream).
- MPEG2-TS features a fixed length (188 bytes) packet where the first byte is a sync byte (0x47).
- An IP stream consists of variable length IP datagram packets signaled in IP packet headers.
- the system supports both IPv4 and IPv6 for IP streams.
- the GS may consist of variable length packets or constant length packets signaled in the encapsulation packet header.
- (a) shows a mode adaptation block 2000 and a stream adaptation (stream adaptation) 2010 for a signal data pipe
- PLS generation block 2020 and PLS scrambler 2030 are shown. The operation of each block will be described.
- the input stream splitter splits the input TS, IP, GS streams into multiple service or service component (audio, video, etc.) streams.
- the mode adaptation module 2010 is composed of a CRC encoder, a baseband (BB) frame slicer, and a BB frame header insertion block.
- the CRC encoder provides three types of CRC encoding, CRC-8, CRC-16, and CRC-32, for error detection at the user packet (UP) level.
- the calculated CRC byte is appended after the UP.
- CRC-8 is used for the TS stream
- CRC-32 is used for the IP stream. If the GS stream does not provide CRC encoding, then the proposed CRC encoding should be applied.
- the BB Frame Slicer maps the input to an internal logical bit format.
- the first receive bit is defined as MSB.
- the BB frame slicer allocates the same number of input bits as the available data field capacity. In order to allocate the same number of input bits as the BBF payload, the UP stream is sliced to fit the data field of the BBF.
- the BB frame header insertion block can insert a 2 bytes fixed length BBF header before the BB frame.
- the BBF header consists of STUFFI (1 bit), SYNCD (13 bit), and RFU (2 bit).
- the BBF may have an extension field (1 or 3 bytes) at the end of the 2-byte BBF header.
- Stream adaptation 2010 consists of a stuffing insertion block and a BB scrambler.
- the stuffing insertion block may insert the stuffing field into the payload of the BB frame. If the input data for the stream adaptation is sufficient to fill the BB frame, STUFFI is set to 0, and the BBF has no stuffing field. Otherwise, STUFFI is set to 1 and the stuffing field is inserted immediately after the BBF header.
- the stuffing field includes a 2-byte stuffing field header and variable sized stuffing data.
- the BB scrambler scrambles the complete BBF for energy dissipation.
- the scrambling sequence is synchronized with the BBF.
- the scrambling sequence is generated by the feedback shift register.
- the PLS generation block 2020 may generate PLS data.
- PLS provides a means by which a receiver can connect to a physical layer data pipe.
- PLS data consists of PLS1 data and PLS2 data.
- PLS1 data is the first set of PLS data delivered to the FSS in frames with fixed size, coding, and modulation that convey basic information about the system as well as the parameters needed to decode the PLS2 data.
- PLS1 data provides basic transmission parameters including the parameters required to enable reception and decoding of PLS2 data.
- the PLS1 data is constant during the duration of the frame group.
- PLS2 data is the second set of PLS data sent to the FSS that carries more detailed PLS data about the data pipes and systems.
- PLS2 contains parameters that provide enough information for the receiver to decode the desired data pipe.
- PLS2 signaling further consists of two types of parameters: PLS2 static data (PLS2-STAT data) and PLS2 dynamic data (PLS2-DYN data).
- PLS2 static data is PLS2 data that is static during the duration of a frame group
- PLS2 dynamic data is PLS2 data that changes dynamically from frame to frame.
- the PLS scrambler 2030 may scramble PLS data generated for energy distribution.
- the aforementioned blocks may be omitted or may be replaced by blocks having similar or identical functions.
- FIG 3 illustrates an input format block according to another embodiment of the present invention.
- the input format block illustrated in FIG. 3 corresponds to an embodiment of the input format block 1000 described with reference to FIG. 1.
- FIG. 3 illustrates a mode adaptation block of an input format block when the input signal corresponds to a multi input stream.
- a mode adaptation block of an input format block for processing multi input streams may independently process multiple input streams.
- a mode adaptation block for processing a multi input stream may be an input stream splitter 3000 or an input stream synchro.
- Each block of the mode adaptation block will be described.
- Operations of the CRC encoder 3050, the BB frame slicer 3060, and the BB header insertion block 3070 correspond to the operations of the CRC encoder, the BB frame slicer, and the BB header insertion block described with reference to FIG. Is omitted.
- the input stream splitter 3000 splits the input TS, IP, and GS streams into a plurality of service or service component (audio, video, etc.) streams.
- the input stream synchronizer 3010 may be called ISSY.
- ISSY can provide suitable means to ensure constant bit rate (CBR) and constant end-to-end transmission delay for any input data format.
- CBR constant bit rate
- ISSY is always used in the case of multiple data pipes carrying TS, and optionally in multiple data pipes carrying GS streams.
- Compensating delay block 3020 may delay the split TS packet stream following the insertion of ISSY information to allow TS packet recombination mechanisms without requiring additional memory at the receiver. have.
- the null packet deletion block 3030 is used only for the TS input stream. Some TS input streams or split TS streams may have a large number of null packets present to accommodate variable bit-rate (VBR) services in the CBR TS stream. In this case, to avoid unnecessary transmission overhead, null packets may be acknowledged and not transmitted. At the receiver, the discarded null packet can be reinserted in the exact place it originally existed with reference to the deleted null-packet (DNP) counter inserted in the transmission, ensuring CBR and time stamp (PCR) updates. There is no need.
- VBR variable bit-rate
- the header compression block 3040 can provide packet header compression to increase transmission efficiency for the TS or IP input stream. Since the receiver may have a priori information for a particular portion of the header, this known information may be deleted at the transmitter.
- the receiver may have a priori information about the sync byte configuration (0x47) and the packet length (188 bytes). If the input TS delivers content with only one PID, that is, one service component (video, audio, etc.) or service subcomponent (SVC base layer, SVC enhancement layer, MVC base view, or MVC dependent view) Only, TS packet header compression may (optionally) be applied to the TS. TS packet header compression is optionally used when the input stream is an IP stream. The block may be omitted or replaced with a block having similar or identical functions.
- FIG. 4 illustrates a BICM block according to an embodiment of the present invention.
- the BICM block illustrated in FIG. 4 corresponds to an embodiment of the BICM block 1010 described with reference to FIG. 1.
- the broadcast signal transmission apparatus for the next generation broadcast service may provide a terrestrial broadcast service, a mobile broadcast service, a UHDTV service, and the like.
- the BICM block according to an embodiment of the present invention can independently process each data pipe by independently applying the SISO, MISO, and MIMO schemes to the data pipes corresponding to the respective data paths.
- the apparatus for transmitting broadcast signals for the next generation broadcast service according to an embodiment of the present invention may adjust QoS for each service or service component transmitted through each data pipe.
- the BICM block shared by the base profile and the handheld profile and the BICM block of the advanced profile may include a plurality of processing blocks for processing each data pipe.
- the processing block 5000 of the BICM block for the base profile and the handheld profile includes a data FEC encoder 5010, a bit interleaver 5020, a constellation mapper 5030, a signal space diversity (SSD) encoding block ( 5040, and a time interleaver 5050.
- a data FEC encoder 5010 a bit interleaver 5020
- a constellation mapper 5030 a signal space diversity (SSD) encoding block ( 5040, and a time interleaver 5050.
- SSD signal space diversity
- the data FEC encoder 5010 performs FEC encoding on the input BBF to generate the FECBLOCK procedure using outer coding (BCH) and inner coding (LDPC).
- Outer coding (BCH) is an optional coding method. The detailed operation of the data FEC encoder 5010 will be described later.
- the bit interleaver 5020 may interleave the output of the data FEC encoder 5010 while providing a structure that can be efficiently realized to achieve optimized performance by a combination of LDPC codes and modulation schemes. The detailed operation of the bit interleaver 5020 will be described later.
- Constellation mapper 5030 can be QPSK, QAM-16, non-uniform QAM (NUQ-64, NUQ-256, NUQ-1024) or non-uniform constellation (NUC-16, NUC-64, NUC-256, NUC-1024)
- NUQ-64, NUQ-256, NUQ-1024 non-uniform QAM
- NUC-16, NUC-64, NUC-256, NUC-1024 A constellation point whose power is normalized by modulating each cell word from the bit interleaver 5020 in the base and handheld profiles or the cell word from the cell word demultiplexer 5010-1 in the advanced profile. e l can be provided.
- the constellation mapping applies only to data pipes. It is observed that NUQ has any shape, while QAM-16 and NUQ have a square shape. If each constellation is rotated by a multiple of 90 degrees, the rotated constellation overlaps exactly with the original. Due to the rotational symmetry characteristic, the real and imaginary components have the same capacity and average power. Both NUQ and N
- the time interleaver 5050 may operate at the data pipe level.
- the parameters of time interleaving can be set differently for each data pipe. The specific operation of the time interleaver 5050 will be described later.
- the processing block 5000-1 of the BICM block for the advanced profile may include a data FEC encoder, a bit interleaver, a constellation mapper, and a time interleaver.
- the processing block 5000-1 is distinguished from the processing block 5000 in that it further includes a cell word demultiplexer 5010-1 and a MIMO encoding block 5020-1.
- operations of the data FEC encoder, the bit interleaver, the constellation mapper, and the time interleaver in the processing block 5000-1 may be performed by the data FEC encoder 5010, the bit interleaver 5020, and the constellation mapper 5030. Since this corresponds to the operation of the time interleaver 5050, the description thereof will be omitted.
- Cell word demultiplexer 5010-1 is used by an advanced profile data pipe to separate a single cell word stream into a dual cell word stream for MIMO processing. A detailed operation of the cell word demultiplexer 5010-1 will be described later.
- the MIMO encoding block 5020-1 may process the output of the cell word demultiplexer 5010-1 using the MIMO encoding scheme.
- MIMO encoding scheme is optimized for broadcast signal transmission. MIMO technology is a promising way to gain capacity, but depends on the channel characteristics. Especially for broadcast, the difference in received signal power between two antennas due to different signal propagation characteristics or the strong LOS component of the channel makes it difficult to obtain capacity gains from MIMO.
- the proposed MIMO encoding scheme overcomes this problem by using phase randomization and rotation based precoding of one of the MIMO output signals.
- MIMO encoding is intended for a 2x2 MIMO system that requires at least two antennas at both the transmitter and the receiver.
- Two MIMO encoding modes are defined in this proposal, full-rate spatial multiplexing (FR-SM) and full-rate full-diversity spatial multiplexing (FRFD-SM).
- FR-SM encoding provides increased capacity with a relatively small complexity increase at the receiver side, while FRFD-SM encoding provides increased capacity and additional diversity gain with a larger complexity increase at the receiver side.
- the proposed MIMO encoding scheme does not limit the antenna polarity arrangement.
- MIMO processing is required for the advanced profile frame, which means that all data pipes in the advanced profile frame are processed by the MIMO encoder. MIMO processing is applied at the data pipe level.
- the pair of constellation mapper outputs, NUQ (e 1, i and e 2, i ), are fed to the input of the MIMO encoder.
- MIMO encoder output pairs g1, i and g2, i are transmitted by the same carrier k and OFDM symbol l of each transmit antenna.
- FIG. 5 illustrates a BICM block according to another embodiment of the present invention.
- the BICM block illustrated in FIG. 5 corresponds to an embodiment of the BICM block 1010 described with reference to FIG. 1.
- the EAC is part of a frame carrying EAS information data
- the FIC is a logical channel in a frame carrying mapping information between a service and a corresponding base data pipe. Detailed description of the EAC and FIC will be described later.
- a BICM block for protecting PLS, EAC, and FIC may include a PLS FEC encoder 6000, a bit interleaver 6010, and a constellation mapper 6020.
- the PLS FEC encoder 6000 may include a scrambler, a BCH encoding / zero insertion block, an LDPC encoding block, and an LDPC parity puncturing block. Each block of the BICM block will be described.
- the PLS FEC encoder 6000 may encode scrambled PLS 1/2 data, EAC and FIC sections.
- the scrambler may scramble PLS1 data and PLS2 data before BCH encoding and shortening and punctured LDPC encoding.
- the BCH encoding / zero insertion block may perform outer encoding on the scrambled PLS 1/2 data using the shortened BCH code for PLS protection, and insert zero bits after BCH encoding. For PLS1 data only, the output bits of zero insertion can be permutated before LDPC encoding.
- the LDPC encoding block may encode the output of the BCH encoding / zero insertion block using the LDPC code.
- C ldpc and parity bits P ldpc are encoded systematically from each zero-inserted PLS information block I ldpc and appended after it.
- LDPC code parameters for PLS1 and PLS2 are shown in Table 4 below.
- the LDPC parity puncturing block may perform puncturing on the PLS1 data and the PLS2 data.
- LDPC parity bits are punctured after LDPC encoding.
- the LDPC parity bits of PLS2 are punctured after LDPC encoding. These punctured bits are not transmitted.
- the bit interleaver 6010 may interleave each shortened and punctured PLS1 data and PLS2 data.
- the constellation mapper 6020 may map bit interleaved PLS1 data and PLS2 data to constellations.
- FIG. 6 illustrates a frame building block according to an embodiment of the present invention.
- the frame building block illustrated in FIG. 7 corresponds to an embodiment of the frame building block 1020 described with reference to FIG. 1.
- the frame building block may include a delay compensation block 7000, a cell mapper 7010, and a frequency interleaver 7020. have. Each block of the frame building block will be described.
- the delay compensation block 7000 adjusts the timing between the data pipes and the corresponding PLS data to ensure co-time between the data pipes and the corresponding PLS data at the transmitter. have.
- PLS data is delayed by the data pipe.
- the delay of the BICM block is mainly due to the time interleaver 5050.
- In-band signaling data may cause information of the next time interleaving group to be delivered one frame ahead of the data pipe to be signaled.
- the delay compensation block delays the in-band signaling data accordingly.
- the cell mapper 7010 may map a PLS, an EAC, an FIC, a data pipe, an auxiliary stream, and a dummy cell to an active carrier of an OFDM symbol in a frame.
- the basic function of the cell mapper 7010 is to activate the data cells generated by time interleaving for each data pipe, PLS cell, and EAC / FIC cell, if any, corresponding to each OFDM symbol in one frame. (active) mapping to an array of OFDM cells.
- Service signaling data (such as program specific information (PSI) / SI) may be collected separately and sent by a data pipe.
- PSI program specific information
- SI program specific information
- the frequency interleaver 7020 may randomly interleave data cells received by the cell mapper 7010 to provide frequency diversity.
- the frequency interleaver 7020 may operate in an OFDM symbol pair consisting of two sequential OFDM symbols using different interleaving seed order to obtain the maximum interleaving gain in a single frame.
- FIG 7 illustrates an OFDM generation block according to an embodiment of the present invention.
- the OFDM generation block illustrated in FIG. 7 corresponds to an embodiment of the OFDM generation block 1030 described with reference to FIG. 1.
- the OFDM generation block modulates the OFDM carrier by inserting a pilot by the cell generated by the frame building block, inserts a pilot, and generates a time domain signal for transmission.
- the block sequentially inserts a guard interval and applies a PAPR reduction process to generate a final RF signal.
- the OFDM generation block includes a pilot and reserved tone insertion block (8000), a 2D-single frequency network (eSFN) encoding block 8010, an inverse fast fourier transform (IFFT).
- Block 8020 PAPR reduction block 8030, guard interval insertion block 8040, preamble insertion block 8050, other system insertion block 8060, and DAC block ( 8070).
- the other system insertion block 8060 may multiplex signals of a plurality of broadcast transmission / reception systems in a time domain so that data of two or more different broadcast transmission / reception systems providing a broadcast service may be simultaneously transmitted in the same RF signal band.
- two or more different broadcast transmission / reception systems refer to a system that provides different broadcast services.
- Different broadcast services may refer to terrestrial broadcast services or mobile broadcast services.
- FIG. 8 illustrates a structure of a broadcast signal receiving apparatus for a next generation broadcast service according to an embodiment of the present invention.
- the broadcast signal receiving apparatus for the next generation broadcast service may correspond to the broadcast signal transmitting apparatus for the next generation broadcast service described with reference to FIG. 1.
- An apparatus for receiving broadcast signals for a next generation broadcast service includes a synchronization & demodulation module 9000, a frame parsing module 9010, a demapping and decoding module a demapping & decoding module 9020, an output processor 9030, and a signaling decoding module 9040. The operation of each module of the broadcast signal receiving apparatus will be described.
- the synchronization and demodulation module 9000 receives an input signal through m reception antennas, performs signal detection and synchronization on a system corresponding to the broadcast signal receiving apparatus, and performs a reverse process of the procedure performed by the broadcast signal transmitting apparatus. Demodulation can be performed.
- the frame parsing module 9010 may parse an input signal frame and extract data in which a service selected by a user is transmitted.
- the frame parsing module 9010 may execute deinterleaving corresponding to the reverse process of interleaving. In this case, positions of signals and data to be extracted are obtained by decoding the data output from the signaling decoding module 9040, so that the scheduling information generated by the broadcast signal transmission apparatus may be restored.
- the demapping and decoding module 9020 may convert the input signal into bit region data and then deinterleave the bit region data as necessary.
- the demapping and decoding module 9020 can perform demapping on the mapping applied for transmission efficiency, and correct an error generated in the transmission channel through decoding. In this case, the demapping and decoding module 9020 can obtain transmission parameters necessary for demapping and decoding by decoding the data output from the signaling decoding module 9040.
- the output processor 9030 may perform a reverse process of various compression / signal processing procedures applied by the broadcast signal transmission apparatus to improve transmission efficiency.
- the output processor 9030 may obtain necessary control information from the data output from the signaling decoding module 9040.
- the output of the output processor 8300 corresponds to a signal input to the broadcast signal transmission apparatus and may be MPEG-TS, IP stream (v4 or v6), and GS.
- the signaling decoding module 9040 may obtain PLS information from the signal demodulated by the synchronization and demodulation module 9000. As described above, the frame parsing module 9010, the demapping and decoding module 9200, and the output processor 9300 may execute the function using data output from the signaling decoding module 9040.
- FIG. 9 shows a frame structure according to an embodiment of the present invention.
- FIG. 9 shows a structural example of a frame time and a frame repetition unit (FRU) in a super frame.
- (a) shows a super frame according to an embodiment of the present invention
- (b) shows a FRU according to an embodiment of the present invention
- (c) shows a frame of various physical profile (PHY profile) in the FRU
- (D) shows the structure of the frame.
- Super frame may consist of eight FRUs.
- the FRU is the basic multiplexing unit for the TDM of the frame and is repeated eight times in the super frame.
- Each frame in the FRU belongs to one of the physical profiles (base, handheld, advanced profile) or FEF.
- the maximum allowable number of frames in a FRU is 4, and a given physical profile may appear any number of times from 0 to 4 times in the FRU (eg, base, base, handheld, advanced).
- the physical profile definition may be extended using the reserved value of PHY_PROFILE in the preamble if necessary.
- the FEF portion is inserted at the end of the FRU if included. If the FEF is included in the FRU, the maximum number of FEFs is 8 in a super frame. It is not recommended that the FEF parts be adjacent to each other.
- One frame is further separated into multiple OFDM symbols and preambles. As shown in (d), the frame includes a preamble, one or more FSS, normal data symbols, and FES.
- the preamble is a special symbol that enables fast Futurecast UTB system signal detection and provides a set of basic transmission parameters for efficient transmission and reception of the signal. Details of the preamble will be described later.
- the main purpose of the FSS is to carry PLS data.
- the FSS For fast synchronization and channel estimation, and hence for fast decoding of PLS data, the FSS has a higher density pilot pattern than normal data symbols.
- the FES has a pilot that is exactly the same as the FSS, which allows frequency only interpolation and temporal interpolation within the FES without extrapolation for symbols immediately preceding the FES.
- FIG. 10 illustrates a signaling hierarchy structure of a frame according to an embodiment of the present invention.
- PLS 10 shows a signaling hierarchy, which is divided into three main parts: preamble signaling data 11000, PLS1 data 11010, and PLS2 data 11020.
- the purpose of the preamble carried by the preamble signal every frame is to indicate the basic transmission parameters and transmission type of the frame.
- PLS1 allows the receiver to access and decode PLS2 data that includes parameters for connecting to the data pipe of interest.
- PLS2 is delivered every frame and divided into two main parts, PLS2-STAT data and PLS2-DYN data. The static and dynamic parts of the PLS2 data are followed by padding if necessary.
- FIG 11 illustrates preamble signaling data according to an embodiment of the present invention.
- the preamble signaling data carries 21 bits of information needed to enable the receiver to access the PLS data and track the data pipes within the frame structure. Details of the preamble signaling data are as follows.
- PHY_PROFILE This 3-bit field indicates the physical profile type of the current frame. The mapping of different physical profile types is given in Table 5 below.
- FFT_SIZE This 2-bit field indicates the FFT size of the current frame in the frame group as described in Table 6 below.
- GI_FRACTION This 3-bit field indicates a guard interval fraction value in the current super frame as described in Table 7 below.
- EAC_FLAG This 1-bit field indicates whether EAC is provided in the current frame. If this field is set to 1, EAS is provided in the current frame. If this field is set to 0, EAS is not delivered in the current frame. This field may be converted to dynamic within a super frame.
- PILOT_MODE This 1-bit field indicates whether the pilot mode is a mobile mode or a fixed mode for the current frame in the current frame group. If this field is set to 0, mobile pilot mode is used. If the field is set to '1', fixed pilot mode is used.
- PAPR_FLAG This 1-bit field indicates whether PAPR reduction is used for the current frame in the current frame group. If this field is set to 1, tone reservation is used for PAPR reduction. If this field is set to 0, no PAPR reduction is used.
- This 3-bit field indicates the physical profile type configuration of the FRU present in the current super frame. In the corresponding field in all preambles in the current super frame, all profile types carried in the current super frame are identified. The 3-bit field is defined differently for each profile as shown in Table 8 below.
- PLS1 data provides basic transmission parameters including the parameters needed to enable the reception and decoding of PLS2. As mentioned above, the PLS1 data does not change during the entire duration of one frame group. A detailed definition of the signaling field of the PLS1 data is as follows.
- PREAMBLE_DATA This 20-bit field is a copy of the preamble signaling data excluding EAC_FLAG.
- NUM_FRAME_FRU This 2-bit field indicates the number of frames per FRU.
- PAYLOAD_TYPE This 3-bit field indicates the format of payload data carried in the frame group. PAYLOAD_TYPE is signaled as shown in Table 9.
- NUM_FSS This 2-bit field indicates the number of FSS in the current frame.
- SYSTEM_VERSION This 8-bit field indicates the version of the signal format being transmitted. SYSTEM_VERSION is separated into two 4-bit fields: major and minor.
- the 4-bit MSB in the SYSTEM_VERSION field indicates major version information. Changes in the major version field indicate incompatible changes. The default value is 0000. For the version described in that standard, the value is set to 0000.
- Minor Version A 4-bit LSB in the SYSTEM_VERSION field indicates minor version information. Changes in the minor version field are compatible.
- CELL_ID This is a 16-bit field that uniquely identifies a geographic cell in an ATSC network. ATSC cell coverage may consist of one or more frequencies depending on the number of frequencies used per Futurecast UTB system. If the value of CELL_ID is unknown or not specified, this field is set to zero.
- NETWORK_ID This is a 16-bit field that uniquely identifies the current ATSC network.
- SYSTEM_ID This 16-bit field uniquely identifies a Futurecast UTB system within an ATSC network.
- Futurecast UTB systems are terrestrial broadcast systems whose input is one or more input streams (TS, IP, GS) and the output is an RF signal.
- the Futurecast UTB system conveys the FEF and one or more physical profiles, if present.
- the same Futurecast UTB system can carry different input streams and use different RFs in different geographic regions, allowing for local service insertion.
- Frame structure and scheduling are controlled in one place and are the same for all transmissions within a Futurecast UTB system.
- One or more Futurecast UTB systems may have the same SYSTEM_ID meaning that they all have the same physical structure and configuration.
- the following loop is composed of FRU_PHY_PROFILE, FRU_FRAME_LENGTH, FRU_GI_FRACTION, and RESERVED indicating the length and FRU configuration of each frame type.
- the loop size is fixed such that four physical profiles (including FFEs) are signaled within the FRU. If NUM_FRAME_FRU is less than 4, the unused fields are filled with zeros.
- FRU_PHY_PROFILE This 3-bit field indicates the physical profile type of the (i + 1) th frame (i is a loop index) of the associated FRU. This field uses the same signaling format as shown in Table 8.
- FRU_FRAME_LENGTH This 2-bit field indicates the length of the (i + 1) th frame of the associated FRU. Using FRU_FRAME_LENGTH with FRU_GI_FRACTION, the exact value of frame duration can be obtained.
- FRU_GI_FRACTION This 3-bit field indicates the guard interval partial value of the (i + 1) th frame of the associated FRU.
- FRU_GI_FRACTION is signaled according to Table 7.
- the following fields provide parameters for decoding PLS2 data.
- PLS2_FEC_TYPE This 2-bit field indicates the FEC type used by the PLS2 protection.
- the FEC type is signaled according to Table 10. Details of the LDPC code will be described later.
- PLS2_MOD This 3-bit field indicates the modulation type used by PLS2.
- the modulation type is signaled according to Table 11.
- PLS2_SIZE_CELL This 15-bit field indicates C total_partial_block which is the size (specified by the number of QAM cells) of all coding blocks for PLS2 carried in the current frame group . This value is constant for the entire duration of the current frame-group.
- PLS2_STAT_SIZE_BIT This 14-bit field indicates the size, in bits, of the PLS2-STAT for the current frame-group. This value is constant for the entire duration of the current frame-group.
- PLS2_DYN_SIZE_BIT This 14-bit field indicates the size, in bits, of the PLS2-DYN for the current frame-group. This value is constant for the entire duration of the current frame-group.
- PLS2_REP_FLAG This 1-bit flag indicates whether the PLS2 repeat mode is used in the current frame group. If the value of this field is set to 1, PLS2 repeat mode is activated. If the value of this field is set to 0, PLS2 repeat mode is deactivated.
- PLS2_REP_SIZE_CELL This 15-bit field indicates C total_partial_block , which is the size (specified by the number of QAM cells) of the partial coding block for PLS2 delivered every frame of the current frame group when PLS2 repetition is used. If iteration is not used, the value of this field is equal to zero. This value is constant for the entire duration of the current frame-group.
- PLS2_NEXT_FEC_TYPE This 2-bit field indicates the FEC type used for PLS2 delivered in every frame of the next frame-group.
- the FEC type is signaled according to Table 10.
- PLS2_NEXT_MOD This 3-bit field indicates the modulation type used for PLS2 delivered in every frame of the next frame-group.
- the modulation type is signaled according to Table 11.
- PLS2_NEXT_REP_FLAG This 1-bit flag indicates whether the PLS2 repeat mode is used in the next frame group. If the value of this field is set to 1, PLS2 repeat mode is activated. If the value of this field is set to 0, PLS2 repeat mode is deactivated.
- PLS2_NEXT_REP_SIZE_CELL This 15-bit field indicates C total_full_block , which is the size (specified in the number of QAM cells) of the entire coding block for PLS2 delivered every frame of the next frame-group when PLS2 repetition is used. If iteration is not used in the next frame-group, the value of this field is equal to zero. This value is constant for the entire duration of the current frame-group.
- PLS2_NEXT_REP_STAT_SIZE_BIT This 14-bit field indicates the size, in bits, of the PLS2-STAT for the next frame-group. The value is constant in the current frame group.
- PLS2_NEXT_REP_DYN_SIZE_BIT This 14-bit field indicates the size of the PLS2-DYN for the next frame-group, in bits. The value is constant in the current frame group.
- PLS2_AP_MODE This 2-bit field indicates whether additional parity is provided for PLS2 in the current frame group. This value is constant for the entire duration of the current frame-group. Table 12 below provides the values for this field. If the value of this field is set to 00, no additional parity is used for PLS2 in the current frame group.
- PLS2_AP_SIZE_CELL This 15-bit field indicates the size (specified by the number of QAM cells) of additional parity bits of PLS2. This value is constant for the entire duration of the current frame-group.
- PLS2_NEXT_AP_MODE This 2-bit field indicates whether additional parity is provided for PLS2 signaling for every frame of the next frame-group. This value is constant for the entire duration of the current frame-group. Table 12 defines the values of this field.
- PLS2_NEXT_AP_SIZE_CELL This 15-bit field indicates the size (specified by the number of QAM cells) of additional parity bits of PLS2 for every frame of the next frame-group. This value is constant for the entire duration of the current frame-group.
- RESERVED This 32-bit field is reserved for future use.
- FIG 13 illustrates PLS2 data according to an embodiment of the present invention.
- PLS2-STAT data of the PLS2 data.
- PLS2-STAT data is the same within a frame group, while PLS2-DYN data provides specific information about the current frame.
- FIC_FLAG This 1-bit field indicates whether the FIC is used in the current frame group. If the value of this field is set to 1, the FIC is provided in the current frame. If the value of this field is set to 0, FIC is not delivered in the current frame. This value is constant for the entire duration of the current frame-group.
- AUX_FLAG This 1-bit field indicates whether the auxiliary stream is used in the current frame group. If the value of this field is set to 1, the auxiliary stream is provided in the current frame. If the value of this field is set to 0, the auxiliary frame is not transmitted in the current frame. This value is constant for the entire duration of the current frame-group.
- NUM_DP This 6-bit field indicates the number of data pipes carried in the current frame. The value of this field is between 1 and 64, and the number of data pipes is NUM_DP + 1.
- DP_ID This 6-bit field uniquely identifies within the physical profile.
- DP_TYPE This 3-bit field indicates the type of data pipe. This is signaled according to Table 13 below.
- DP_GROUP_ID This 8-bit field identifies the data pipe group with which the current data pipe is associated. This can be used to connect to the data pipe of the service component associated with a particular service that the receiver will have the same DP_GROUP_ID.
- BASE_DP_ID This 6-bit field indicates a data pipe that carries service signaling data (such as PSI / SI) used in the management layer.
- the data pipe indicated by BASE_DP_ID may be a normal data pipe for delivering service signaling data together with service data or a dedicated data pipe for delivering only service signaling data.
- DP_FEC_TYPE This 2-bit field indicates the FEC type used by the associated data pipe.
- the FEC type is signaled according to Table 14 below.
- DP_COD This 4-bit field indicates the code rate used by the associated data pipe.
- the code rate is signaled according to Table 15 below.
- DP_MOD This 4-bit field indicates the modulation used by the associated data pipe. Modulation is signaled according to Table 16 below.
- DP_SSD_FLAG This 1-bit field indicates whether the SSD mode is used in the associated data pipe. If the value of this field is set to 1, the SSD is used. If the value of this field is set to 0, the SSD is not used.
- DP_MIMO This 3-bit field indicates what type of MIMO encoding processing is applied to the associated data pipe.
- the type of MIMO encoding process is signaled according to Table 17 below.
- DP_TI_TYPE This 1-bit field indicates the type of time interleaving. A value of 0 indicates that one time interleaving group corresponds to one frame and includes one or more time interleaving blocks. A value of 1 indicates that one time interleaving group is delivered in more than one frame and contains only one time interleaving block.
- DP_TI_LENGTH The use of this 2-bit field (only allowed values are 1, 2, 4, 8) is determined by the value set in the DP_TI_TYPE field as follows.
- N TI the number of time interleaving block per time interleaving group
- This 2-bit field represents the frame interval (I JUMP ) within the frame group for the associated data pipe, and allowed values are 1, 2, 4, 8 (the corresponding 2-bit fields are 00, 01, 10, 11). For data pipes that do not appear in every frame of a frame group, the value of this field is equal to the interval between sequential frames. For example, if a data pipe appears in frames 1, 5, 9, 13, etc., the value of this field is set to 4. For data pipes that appear in every frame, the value of this field is set to 1.
- DP_TI_BYPASS This 1-bit field determines the availability of time interleaver 5050. If time interleaving is not used for the data pipe, this field value is set to 1. On the other hand, if time interleaving is used, the corresponding field value is set to zero.
- DP_FIRST_FRAME_IDX This 5-bit field indicates the index of the first frame of the super frame in which the current data pipe occurs.
- the value of DP_FIRST_FRAME_IDX is between 0 and 31.
- DP_NUM_BLOCK_MAX This 10-bit field indicates the maximum value of DP_NUM_BLOCKS for the data pipe. The value of this field has the same range as DP_NUM_BLOCKS.
- DP_PAYLOAD_TYPE This 2-bit field indicates the type of payload data carried by a given data pipe. DP_PAYLOAD_TYPE is signaled according to Table 19 below.
- DP_INBAND_MODE This 2-bit field indicates whether the current data pipe carries in-band signaling information. In-band signaling type is signaled according to Table 20 below.
- DP_PROTOCOL_TYPE This 2-bit field indicates the protocol type of the payload carried by the given data pipe.
- the protocol type of payload is signaled according to Table 21 below when the input payload type is selected.
- DP_CRC_MODE This 2-bit field indicates whether CRC encoding is used in the input format block. CRC mode is signaled according to Table 22 below.
- DNP_MODE This 2-bit field indicates the null packet deletion mode used by the associated data pipe when DP_PAYLOAD_TYPE is set to TS ('00'). DNP_MODE is signaled according to Table 23 below. If DP_PAYLOAD_TYPE is not TS ('00'), DNP_MODE is set to a value of 00.
- ISSY_MODE This 2-bit field indicates the ISSY mode used by the associated data pipe when DP_PAYLOAD_TYPE is set to TS ('00'). ISSY_MODE is signaled according to Table 24 below. If DP_PAYLOAD_TYPE is not TS ('00'), ISSY_MODE is set to a value of 00.
- HC_MODE_TS This 2-bit field indicates the TS header compression mode used by the associated data pipe when DP_PAYLOAD_TYPE is set to TS ('00'). HC_MODE_TS is signaled according to Table 25 below.
- HC_MODE_IP This 2-bit field indicates the IP header compression mode when DP_PAYLOAD_TYPE is set to IP ('01'). HC_MODE_IP is signaled according to Table 26 below.
- PID This 13-bit field indicates the number of PIDs for TS header compression when DP_PAYLOAD_TYPE is set to TS ('00') and HC_MODE_TS is set to 01 or 10.
- FIC_VERSION This 8-bit field indicates the version number of the FIC.
- FIC_LENGTH_BYTE This 13-bit field indicates the length of the FIC in bytes.
- NUM_AUX This 4-bit field indicates the number of auxiliary streams. Zero indicates that no auxiliary stream is used.
- AUX_CONFIG_RFU This 8-bit field is reserved for future use.
- AUX_STREAM_TYPE This 4 bits is reserved for future use to indicate the type of the current auxiliary stream.
- AUX_PRIVATE_CONFIG This 28-bit field is reserved for future use for signaling the secondary stream.
- FIG 14 illustrates PLS2 data according to another embodiment of the present invention.
- the value of the PLS2-DYN data may change during the duration of one frame group, while the size of the field is constant.
- FRAME_INDEX This 5-bit field indicates the frame index of the current frame within the super frame. The index of the first frame of the super frame is set to zero.
- PLS_CHANGE_COUNTER This 4-bit field indicates the number of super frames before the configuration changes. The next super frame whose configuration changes is indicated by the value signaled in that field. If the value of this field is set to 0000, this means that no scheduled change is expected. For example, a value of 1 indicates that there is a change in the next super frame.
- FIC_CHANGE_COUNTER This 4-bit field indicates the number of super frames before the configuration (i.e., the content of the FIC) changes. The next super frame whose configuration changes is indicated by the value signaled in that field. If the value of this field is set to 0000, this means that no scheduled change is expected. For example, a value of 0001 indicates that there is a change in the next super frame.
- NUM_DP NUM_DP that describes the parameters related to the data pipe carried in the current frame.
- DP_ID This 6-bit field uniquely represents a data pipe within the physical profile.
- DP_START This 15-bit (or 13-bit) field indicates the first starting position of the data pipe using the DPU addressing technique.
- the DP_START field has a length different according to the physical profile and the FFT size as shown in Table 27 below.
- DP_NUM_BLOCK This 10-bit field indicates the number of FEC blocks in the current time interleaving group for the current data pipe.
- the value of DP_NUM_BLOCK is between 0 and 1023.
- the next field indicates the FIC parameter associated with the EAC.
- EAC_FLAG This 1-bit field indicates the presence of an EAC in the current frame. This bit is equal to EAC_FLAG in the preamble.
- EAS_WAKE_UP_VERSION_NUM This 8-bit field indicates the version number of the automatic activation indication.
- EAC_FLAG field If the EAC_FLAG field is equal to 1, the next 12 bits are allocated to the EAC_LENGTH_BYTE field. If the EAC_FLAG field is equal to 0, the next 12 bits are allocated to EAC_COUNTER.
- EAC_LENGTH_BYTE This 12-bit field indicates the length of the EAC in bytes.
- EAC_COUNTER This 12-bit field indicates the number of frames before the frame in which the EAC arrives.
- AUX_PRIVATE_DYN This 48-bit field is reserved for future use for signaling the secondary stream. The meaning of this field depends on the value of AUX_STREAM_TYPE in configurable PLS2-STAT.
- CRC_32 32-bit error detection code that applies to the entire PLS2.
- FIG. 15 illustrates a logical structure of a frame according to an embodiment of the present invention.
- the PLS, EAC, FIC, data pipe, auxiliary stream, and dummy cell are mapped to the active carrier of the OFDM symbol in the frame.
- PLS1 and PLS2 are initially mapped to one or more FSS. Then, if there is an EAC, the EAC cell is mapped to the immediately following PLS field. If there is an FIC next, the FIC cell is mapped.
- the data pipes are mapped after the PLS or, if present, after the EAC or FIC. Type 1 data pipes are mapped first, and type 2 data pipes are mapped next. Details of the type of data pipe will be described later. In some cases, the data pipe may carry some special data or service signaling data for the EAS.
- auxiliary stream or stream if present, is mapped to the data pipe next, followed by a dummy cell in turn. Mapping all together in the order described above, namely PLS, EAC, FIC, data pipe, auxiliary stream, and dummy cell, will correctly fill the cell capacity in the frame.
- FIG 16 illustrates PLS mapping according to an embodiment of the present invention.
- the PLS cell is mapped to an active carrier of the FSS. According to the number of cells occupied by the PLS, one or more symbols are designated as FSS, and the number N FSS of the FSS is signaled by NUM_FSS in PLS1.
- FSS is a special symbol that carries a PLS cell. Since alertness and latency are critical issues in PLS, the FSS has a high pilot density, enabling fast synchronization and interpolation only on frequencies within the FSS.
- the PLS cell is mapped to an active carrier of the FSS from the top down as shown in the example of FIG.
- PLS1 cells are initially mapped in ascending order of cell index from the first cell of the first FSS.
- the PLS2 cell follows immediately after the last cell of PLS1 and the mapping continues downward until the last cell index of the first FSS. If the total number of required PLS cells exceeds the number of active carriers of one FSS, the mapping proceeds to the next FSS and continues in exactly the same way as the first FSS.
- EAC, FIC or both are present in the current frame, EAC and FIC are placed between the PLS and the normal data pipe.
- FIG 17 illustrates EAC mapping according to an embodiment of the present invention.
- the EAC is a dedicated channel for delivering EAS messages and is connected to the data pipes for the EAS. EAS support is provided, but the EAC itself may or may not be present in every frame. If there is an EAC, the EAC is mapped immediately after the PLS2 cell. Except for PLS cells, none of the FIC, data pipes, auxiliary streams or dummy cells are located before the EAC. The mapping procedure of the EAC cell is exactly the same as that of the PLS.
- EAC cells are mapped in ascending order of cell index from the next cell of PLS2 as shown in the example of FIG. Depending on the EAS message size, as shown in FIG. 17, the EAC cell may occupy few symbols.
- the EAC cell follows immediately after the last cell of PLS2 and the mapping continues downward until the last cell index of the last FSS. If the total number of required EAC cells exceeds the number of remaining active carriers of the last FSS, the EAC mapping proceeds to the next symbol and continues in exactly the same way as the FSS. In this case, the next symbol to which the EAC is mapped is a normal data symbol, which has more active carriers than the FSS.
- the FIC is passed next if present. If no FIC is sent (as signaling in the PLS2 field), the data pipe follows immediately after the last cell of the EAC.
- FIC is a dedicated channel that carries cross-layer information to enable fast service acquisition and channel scan.
- the information mainly includes channel binding information between data pipes and services of each broadcaster.
- the receiver can decode the FIC and obtain information such as broadcaster ID, number of services, and BASE_DP_ID.
- BASE_DP_ID For high-speed service acquisition, not only the FIC but also the base data pipe can be decoded using BASE_DP_ID. Except for the content that the base data pipe transmits, the base data pipe is encoded and mapped to the frame in exactly the same way as a normal data pipe. Thus, no further explanation of the base data pipe is needed.
- FIC data is generated and consumed at the management layer. The content of the FIC data is as described in the management layer specification.
- FIC data is optional and the use of FIC is signaled by the FIC_FLAG parameter in the static part of the PLS2. If FIC is used, FIC_FLAG is set to 1 and the signaling field for FIC is defined in the static part of PLS2. Signaled in this field is FIC_VERSION, FIC_LENGTH_BYTE. FIC uses the same modulation, coding, and time interleaving parameters as PLS2. The FIC shares the same signaling parameters as PLS2_MOD and PLS2_FEC. FIC data is mapped after PLS2 if present, or immediately after EAC if EAC is present. None of the normal data pipes, auxiliary streams, or dummy cells are located before the FIC. The method of mapping the FIC cells is exactly the same as the EAC, which in turn is identical to the PLS.
- the FIC cells are mapped in ascending order of cell index from the next cell of PLS2 as shown in the example of (a).
- FIC cells are mapped for several symbols.
- the FIC cell follows immediately after the last cell of PLS2 and the mapping continues downward until the last cell index of the last FSS. If the total number of required FIC cells exceeds the number of remaining active carriers of the last FSS, the mapping of the remaining FIC cells proceeds to the next symbol, which continues in exactly the same way as the FSS. In this case, the next symbol to which the FIC is mapped is a normal data symbol, which has more active carriers than the FSS.
- the EAC is mapped before the FIC and the FIC cells are mapped in ascending order of cell index from the next cell of the EAC as shown in (b).
- one or more data pipes are mapped, followed by auxiliary streams and dummy cells if present.
- FIG 19 shows an FEC structure according to an embodiment of the present invention.
- the data FEC encoder may perform FEC encoding on the input BBF to generate the FECBLOCK procedure using outer coding (BCH) and inner coding (LDPC).
- BCH outer coding
- LDPC inner coding
- the illustrated FEC structure corresponds to FECBLOCK.
- the FECBLOCK and FEC structures have the same value corresponding to the length of the LDPC codeword.
- N ldpc 64800 bits (long FECBLOCK) or 16200 bits (short FECBLOCK).
- Tables 28 and 29 below show the FEC encoding parameters for the long FECBLOCK and the short FECBLOCK, respectively.
- a 12-error correcting BCH code is used for the outer encoding of the BBF.
- the BBF-generated polynomials for short FECBLOCK and long FECBLOCK are obtained by multiplying all polynomials.
- LDPC codes are used to encode the output of the outer BCH encoding.
- ldpc P parity bits
- I ldpc - is systematically encoded from the (BCH encoded BBF), it is attached to the I ldpc.
- the finished B ldpc (FECBLOCK) is expressed by the following equation.
- N ldpc for long FECBLOCK - specific procedures for calculating the K ldpc parity bits is as follows.
- x represents the address of the parity bit accumulator corresponding to the first bit i 0
- Q ldpc is a code rate dependent constant specified in the address of the parity check matrix.
- Equation 6 x represents the address of the parity bit accumulator corresponding to information bit i 360 , that is, the entry of the second row of the parity check matrix.
- the final parity bits are obtained as follows.
- the corresponding LDPC encoding procedure for short FECBLOCK is t LDPC for long FECBLOCK.
- the time interleaver operates at the data pipe level.
- the parameters of time interleaving can be set differently for each data pipe.
- DP_TI_TYPE (allowed values: 0 or 1): Represents the time interleaving mode.
- 0 indicates a mode with multiple time interleaving blocks (one or more time interleaving blocks) per time interleaving group. In this case, one time interleaving group is directly mapped to one frame (without interframe interleaving).
- 1 indicates a mode having only one time interleaving block per time interleaving group. In this case, the time interleaving block is spread over one or more frames (interframe interleaving).
- DP_NUM_BLOCK_MAX (allowed values: 0 to 1023): Represents the maximum number of XFECBLOCKs per time interleaving group.
- DP_FRAME_INTERVAL (allowed values: 1, 2, 4, 8): Represents the number of frames I JUMP between two sequential frames carrying the same data pipe of a given physical profile.
- DP_TI_BYPASS (allowed values: 0 or 1): If time interleaving is not used for the data frame, this parameter is set to one. If time interleaving is used, it is set to zero.
- the parameter DP_NUM_BLOCK from the PLS2-DYN data indicates the number of XFECBLOCKs carried by one time interleaving group of the data group.
- each time interleaving group is a set of integer number of XFECBLOCKs, and will contain a dynamically varying number of XFECBLOCKs.
- N xBLOCK_Group (n) The number of XFECBLOCKs in the time interleaving group at index n is represented by N xBLOCK_Group (n) and signaled as DP_NUM_BLOCK in the PLS2-DYN data.
- N xBLOCK_Group (n) may vary from the minimum value 0 to the maximum value N xBLOCK_Group_MAX (corresponding to DP_NUM_BLOCK_MAX ) having the largest value 1023.
- Each time interleaving group is either mapped directly to one frame or spread over P I frames.
- Each time interleaving group is further divided into one or more (N TI ) time interleaving blocks.
- each time interleaving block corresponds to one use of the time interleaver memory.
- the time interleaving block in the time interleaving group may include some other number of XFECBLOCKs. If the time interleaving group is divided into multiple time interleaving blocks, the time interleaving group is directly mapped to only one frame. As shown in Table 32 below, there are three options for time interleaving (except for the additional option of omitting time interleaving).
- the time interleaver will also act as a buffer for the data pipe data before the frame generation process. This is accomplished with two memory banks for each data pipe.
- the first time interleaving block is written to the first bank.
- the second time interleaving block is written to the second bank while reading from the first bank.
- Time interleaving is a twisted row-column block interleaver.
- the number of columns N c is equal to N xBLOCK_TI (n, s)
- 21 illustrates the basic operation of a twisted row-column block interleaver according to an embodiment of the present invention.
- Fig. 21A shows a write operation in the time interleaver
- Fig. 21B shows a read operation in the time interleaver.
- the first XFECBLOCK is written in the column direction to the first column of the time interleaving memory
- the second XFECBLOCK is written to the next column, followed by this operation.
- the cells are read diagonally.
- Cells are read. Specifically, Assuming that this is a time interleaving memory cell position to be read sequentially, the read operation in this interleaving array is a row index as in the equation below. Column index Related twist parameters Is executed by calculating.
- the cell position to be read is coordinate Calculated by
- FIG. 22 illustrates an operation of a twisted row-column block interleaver according to another embodiment of the present invention.
- FIG. 22 Denotes an interleaving array in the time interleaving memory for each time interleaving group including the virtual XFECBLOCK.
- the interleaving array for twisted row-column block interleaver inserts a virtual XFECBLOCK into the time interleaving memory. It is set to the size of, and the reading process is made as follows.
- the number of time interleaving groups is set to three.
- the maximum number of XFECBLOCKs is signaled in PLS2-STAT data by NxBLOCK_Group_MAX, which Leads to.
- Figure 23 illustrates a diagonal read pattern of a twisted row-column block interleaver according to one embodiment of the present invention.
- an embodiment of the present invention provides a data configuration method for transmitting file-based multimedia content in a real-time broadcasting environment.
- an embodiment of the present invention provides a method for identifying segmentation generation information and consumption information of a file for transmitting file-based multimedia content in a real-time broadcasting environment.
- an embodiment of the present invention provides a method for generating a file division for transmitting file-based multimedia content in a real-time broadcasting environment.
- an embodiment of the present invention provides a file division consumption method for consuming file-based multimedia content in a real-time broadcasting environment.
- 25 is a diagram illustrating data processing time when the FLUTE protocol is used.
- the hybrid broadcast service may transmit A / V content to an existing broadcast network and provide additional data related to A / V content through an internet network.
- a service for transmitting a part of A / V content through an internet network has been provided.
- File-based multimedia content has been widely used in the form of a download method through the existing Internet network because it has excellent scalability and no dependency on a transport protocol.
- a protocol suitable for interworking with a broadcasting network and the Internet network and for transmitting file-based multimedia content of a large file is a FLUTE (File Delivery over Unidirectional Transport protocol).
- FLUTE is an application for unidirectional file transfer based on ALC. It is a protocol that defines information about the file itself or information for transmission. FLUTE transmits a file after transmitting information necessary for transmission and information on various attributes of a file to be transmitted through transmission of a file delivery table (FDT) instance.
- FDT file delivery table
- Asynchronous Layered Coding is a standardized protocol that allows a single sender to provide reliability and congestion control over multiple channels while sending files to multiple receivers.
- ALC is a combination of FEC Building Block for error control, WEBRC Building Block for congestion control, and Layered Coding Transport (LCT) building block for session and channel management. .
- ALC is a content delivery protocol that enables very efficient transmission to a large number of recipients.
- ALC is unidirectional, allows limited transmission as needed, and does not require specific channels and resources for feedback. Since ALC has no feedback, it provides reliable service by applying the FEC code scheme in whole or in part for reliability.
- the object to be delivered is configured by the transport block and the FEC scheme through the FEC encoding according to the FEC scheme to be applied and delivered.
- ALC's session consists of one or more channels, and various receivers select a channel in the session according to network conditions to receive a desired object. Recipients can concentrate on receiving their content and are hardly affected by the status of other recipients or packet loss. Therefore, ALC has high robustness and can provide stable content download using multi-layered transmission.
- LCT provides transport level support for reliable content delivery (eg FLUTE) and stream transport protocols.
- LCT provides information about the content and characteristics of basic information to be delivered to the recipient.
- the LCT may include a Treansport Session Identifier (TSI) field, a Transport Object ID (TOI) field, and a Congestion Control Information (CCI) field.
- TSI Treansport Session Identifier
- TOI Transport Object ID
- CCI Congestion Control Information
- the TSI field contains information identifying an ALC / LCT session. For example, a channel in a session can be identified using the sender IP address and a UDP port.
- the TOI field contains information identifying each file object.
- the CCI field contains information on the use and the Congestion Control Block.
- the LCT may provide additional information and FEC related information through an extension header.
- the object e.g., file, etc.
- the object is packetized according to the FLUTE protocol, which in turn is packetized according to the 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 be ALC / LCT / UDP / IP data.
- File-based multimedia contents can be transmitted not only to the Internet but also to the broadcast network through a content transmission protocol such as LCT.
- the multimedia content composed of at least one object or file may be transmitted and consumed in an object unit or file unit through the LCT. Specifically, it is as follows.
- the multimedia content may include at least one object.
- One object may include at least one fragment (Fragment 1 and Fragment 2).
- the data processing time when the FLUTE protocol is used is shown.
- the bottommost figure shows the encoding start time and the encoding end time for one object in the broadcast signal transmission apparatus
- the middle figure shows the transmission start time for the one object and The transmission end time
- the top picture shows the playback start time and the playback end time for one object in the broadcast signal receiving apparatus.
- the apparatus for transmitting broadcast signals starts the transmission of an object after ending the generation of the object including at least one fragment. Therefore, a transmission waiting time as much as D t1 is generated between a time point at which the broadcast signal transmission apparatus starts to generate an object and a time point at which transmission is started.
- the broadcast signal receiving apparatus starts reproduction of the object after receiving the object including the at least one fragment. Therefore, a reproduction waiting time as much as D r1 occurs between a time point at which the broadcast signal reception apparatus starts to receive an object and a time point at which playback is started.
- the broadcast signal transmitting apparatus transmits data in units of objects, and therefore, the broadcast signal receiving apparatus has a limitation that it can only consume the corresponding object after receiving all the data for one object. . Therefore, transmission of an object using the FLUTE protocol is not suitable for a real time broadcasting environment.
- FIG. 26 illustrates a ROUTE protocol stack according to an embodiment of the present invention.
- the broadcast service of a next generation broadcast system supporting IP-based hybrid broadcasting may include video data, audio data, subtitle data, signaling data, electronic service guide (ESG) data, and / or NRT content data.
- ESG electronic service guide
- Video data, audio data, and caption data may be encapsulated in the form of ISO Base Media File (hereinafter referred to as ISO BMFF).
- ISO BMFF ISO Base Media File
- data encapsulated in the form of ISO BMFF may take the form of MPEG (Moving Picture Expert Group) -DASH (Dynamic Adaptive Streaming over HTTP) segment or MMT (MPEG Media Transport) media processing unit (MPU).
- MPEG Motion Picture Expert Group
- DASH Dynamic Adaptive Streaming over HTTP
- MMT MPEG Media Transport
- the data encapsulated in ISO BMFF format may be transmitted in the broadcast network and the Internet network identically or differently according to the characteristics of each transmission network.
- data encapsulated in the form of signaling data, ESG data, NRT content data, and / or ISO BMFF may be encapsulated into an application layer transport protocol packet supporting real-time object transmission.
- data encapsulated in the form of ISO BMFF may be encapsulated by a Real-Time Object Delivery over Unidirectional Transport (ROUTE) and a transport packet of MMT.
- ROUTE Real-Time Object Delivery over Unidirectional Transport
- ROUTE Real-Time Object Delivery over Unidirectional Transport
- ALC Asynchronous Layered Coding
- LCT Layered Coding Transport
- ROUTE is an enhanced version or functional replacement with additional features for FLUTE.
- ROUTE may carry signaling messages, Electronic Service Guide (ESG) messages, and NRT content.
- ESG Electronic Service Guide
- NRT content
- ROUTE is particularly well suited for transmitting streaming media such as MPEG-DASH Media Segment files.
- FLUTE Compared to FLUTE, ROUTE provides lower end-to-end latency through the delivery chain.
- the ROUTE protocol is a generic transport application that provides for the transport of any kind of object.
- the ROUTE protocol supports rich presentation including scene descriptions, media objects, and DRM related information.
- ROUTE is particularly well suited for the delivery of real-time media content and offers many features.
- ROUTE provides individual delivery and access to different media components (e.g. language tracks, subtitles, alternative video views). And, ROUTE provides support of layered coding by enabling delivery in different transport sessions or in different ROUTE sessions. ROUTE also provides support for flexible FEC protection, including multistage. ROUTE also provides an easy MPEG-DASH combination. The MPEG-DASH combination enables synergy between the broadcast and broadband delivery modes of DASH. ROUTE also provides quick access to the media when joining a ROUTE session and / or a transport session. ROUTE also provides high scalability by focusing on delivery concepts. ROUTE also provides compatibility with existing IETF protocols and with the use of IETF-endorsed extension mechanisms.
- media components e.g. language tracks, subtitles, alternative video views.
- ROUTE provides support of layered coding by enabling delivery in different transport sessions or in different ROUTE sessions.
- ROUTE also provides support for flexible FEC protection, including multistage.
- ROUTE also provides an easy MPEG-DASH combination. The MPEG-DASH combination
- the ROUTE protocol is divided into two main components.
- the first component is a source protocol for the delivery of objects or flows / sets of objects.
- the second component is a repair protocol for flexibly protecting delivery objects or bundles of delivery objects delivered through the source protocol.
- the source protocol is independent of the repair protocol. That is, the source protocol can be used without the ROUTE repair protocol.
- the repair protocol may be used for specific development scenarios, specific geographic areas, or specific service for mobile reception.
- the source protocol may be supported by FLUTE as well as the extensions defined in 3GPP TS 26.346.
- the source protocol may use some theories of FCAST as defined in RFC 6968.
- object metadata and object content may be delivered together as a compound object.
- the ROUTE protocol adds specific optimizations and limitations that enable optimized support for real-time delivery of media data.
- the source ROUTE protocol provides real-time delivery of object-based media data.
- the source ROUTE protocol provides for flexible packetization, which includes enabling media-aware packetization as well as transport aware packetization of delivery objects.
- the source ROUTE protocol is independent of files and / or delivery objects. That is, the delivery object may be part of a file or a group of files.
- Delivery objects are a key component of the ROUTE protocol because the receiver recovers the delivery objects and passes them to the application.
- the delivery object is self-contained for the application and is associated with specific attributes, metadata, and timing directive information related to the application.
- attributes are provided in-band with the objects.
- data is delivered out-of-band in a static or dynamic fashion.
- the delivery object may contain a complete file or part of a file accompanied by a "FDT Instance".
- the delivery object may include an HTTP Entity Header and an HTTP Entity Body.
- the delivery object may include a package of delivery objects.
- the delivery object may be a full file or a byte ranges of a file accompanying the FDT instance.
- the delivery object may be delivered in real time or non-timed delivery. If the delivery object is delivered in real time (If timed), specific real time limits and buffer limits apply, and specific extension headers can be used. Dynamic and static metadata can be used to describe delivery object properties.
- the delivery object may be delivered through specific data structures, such as ISO BMFF structures. In this case, media-aware packetization or general packetization may be applied.
- the delivery format can specify which formats are used to convey information to the application.
- the ROUTE repair protocol is FEC based and may operate as an additional layer between the transport layer (e.g., UDP) and the object delivery layer protocol.
- FEC can reuse the FEC Framework definitions defined in RFC 6363. However, FEC differs in that it protects delivery objects carried in the source protocol.
- Each FEC source block may contain a portion of a delivery object.
- the delivery object may be a single delivery object (similar to FLUTE) or multiple delivery objects. Multiple delivery objects may be created prior to FEC protection.
- ROUTE FEC may be similar in meaning to the FEC scheme defined in RFC 5052.
- the ROUTE FEC may include the contents of RFC 5052.
- the FEC scheme defines the FEC encoding and decoding The FEC scheme is used to identify the packet payload data in the protocol fields and the contents of the FEC scheme. Procedures can be defined.
- All packets in ROUTE are LCT packets defined in RFC 5651.
- Source and repair packets may be distinguished by at least one ROUTE session, a LCT transport session, and / or a PSI bit. Different ROUTE sessions may be sent on different IP / UDP port combinations. Different LCT transport sessions may have different TSI values in the LCT header. If source and repair packets are sent through the same LCT transport session, they can be distinguished by the PSI bits in the LCT. This mode of operation is mostly suitable for FLUTE compatible deployments.
- ROUTE defines a source protocol that includes packet formats, sending behavior, and receiving behavior. And, ROUTE defines a repair protocol. And, ROUTE defines metadata for transport session establishment and metadata for object flow delivery. And, ROUTE can define mappings for ROUTE for rich and high quality linear TV broadcast services and recommendations for MPEG-DASH configuration.
- the scope of the ROUTE protocol is the reliable delivery of delivery objects and associated metadata using LCT packets.
- Objects can be made available to applications through the Delivery Object Cache.
- the implementation of this cache may vary depending on the application.
- the ROUTE protocol concentrates on the format of the LCT packets carrying delivery objects.
- the ROUTE protocol focuses on reliable delivery of delivery objects using a repair protocol based on FEC.
- the ROUTE protocol focuses on the definition and delivery of object metadata that enables the delivery of an object between the delivery object cache and the application along with the delivery objects.
- the ROUTE protocol concentrates on the ROUTE session and the LCT session for establishing the reception of objects and their metadata.
- the ROUTE protocol focuses on normative aspects, formats, and semantics of auxiliary information sent with packets to optimize performance for specific applications. For example, real time delivery may be an example.
- the ROUTE protocol provides recommended mappings of DASH Media Presentation formats specific to ROUTE delivery as well as the appropriate DASH formats used for delivery.
- the key issue is that by using ROUTE, DASH media formats can be used as is.
- This architectural design enables converged unicast / broadcast services.
- a ROUTE session for carrying LCT packets is established.
- These packets may carry source objects or FEC repair data.
- the source protocol may include at least one LCT sessions, and each LCT session may send related objects with metadata.
- Metadata can be delivered statically in the LCT Session Instance Description (LSID) and dynamically delivered as LCT extension headers in compound objects or packet headers in Entity Mode.
- Packets may be sent via ALC using a specific FEC scheme that allows for flexible fragmentation of an object at arbitrary byte boundaries.
- delivery objects may be FEC protected individually or in the form of bundles.
- the bundle-type object is encoded and only repair packets can be delivered. In combination with the source packets, this allows restoration of delivery object bundles.
- At least one repair flow may be generated, and each repair flow may have different characteristics. For example, each repair flow may have different latency requirements, and may have different protection requirements.
- Dynamic MetaData is metadata that dynamically generates descriptions corresponding to FDT on the client.
- the DMD is transmitted through the Entity-header in Entity Mode and may be carried through the LCT header in other modes of delivery.
- the ROUTE protocol can support different protection and delivery schemes for source data. In order to be used efficiently in the backward-compatibility mode, the ROUTE protocol can support all existing uses for NRT delivery.
- the ROUTE session is associated with the IP address / port combination. Typically, by joining a ROUTE session, all packets of the session can be received and the application protocol can apply additional processing.
- Each ROUTE session may include at least one LCT transport session.
- LCT transport sessions may be a subset of a ROUTE session.
- one LCT transport session can typically transmit one media component (e.g. DASH Representation).
- DASH Representation e.g. DASH Representation
- a ROUTE session may be considered as a complex of LCT transport sessions that carry at least one media component that is a component of at least one DASH Media Presentation.
- at least one object associated with each other may be transmitted.
- the objects may be DASH segments related to one representation.
- metadata properties can be passed so that the objects can be used in applications.
- Applications may include, but are not limited to, DASH Media Presentations, HTML-5 Presentations, or other object-consuming applications.
- ROUTE sessions may be bounded or unbounded from the temporal perspective.
- the ROUTE session may include at least one LCT transport session.
- Each transport session is uniquely identified by a unique Transport Session Identifier (TSI) in the LCT header.
- TTI Transport Session Identifier
- the ROUTE Session Description specifies at least one sender IP address, an address and port number for the session, an indication that the session is a ROUTE session, an indication that all packets are LCT packets, and / or to join and consume a session at the IP / UDP level. May contain other necessary information.
- the Session Description may include, but is not limited to, data rates used for the ROUTE session and the duration of the ROUTE session.
- the session description may be in the form of Session Description Protocol (SDP) defined in RFC 4566, or in the form of XML metadata defined in RFC 3023.
- SDP Session Description Protocol
- the session description may be transmitted through a session announcement protocol using a proprietary session control protocol located on a web page with scheduling information.
- the Session Description may be sent in an email or other out-of-band manner.
- Transport sessions are not described in the ROUTE session description, but may be described in the LCT Session Instance Description (LSID).
- Transport sessions ie, LCT transport sessions or LCT sessions
- Source Flows can carry source data.
- Repair Flows can send repair data.
- At least one LCT transport session included in one ROUTE session may be described by an LCT Session Instance description (LSID).
- the LSID may define what is transmitted in each LCT transport session included in the ROUTE session.
- Each transport session can be uniquely identified by a Transport Session Identifier (TSI) in the LCT header.
- TSI Transport Session Identifier
- the LSID may describe at least one transport session transmitted in the ROUTE session.
- the LSID may be delivered through the same ROUTE session including LCT transport sessions and may be delivered through an external means of the ROUTE session.
- the LSID may be delivered through unicast or other ROUTE session.
- Entity Mode can be used. If such objects are not delivered via Entity Mode, the LSID must be recovered before obtaining an extended FDT for the received object.
- LSID's Internet Media Type is application / xml + route + lsid.
- the LSID may refer to at least one other data fragment.
- the LSID element may include a version attribute, a validity attribute, and / or an expiration attribute.
- the LSID element can be properly updated using a version attribute as well as a validity attribute and an expiration attribute. For example, certain transport sessions may end after some time or when a new session is started.
- the version attribute may indicate the version of the LSID element.
- the version can be incremented by one when the descriptor is updated.
- the received LSID element with the highest version number indicates the currently valid version.
- the validity attribute may indicate the date and / or time when the LSID element becomes valid.
- the validity attribute may or may not exist. If the validity attribute does not exist, the receiver may assume that the LSID element version is valid immediately.
- the expiration attribute may indicate the date and / or time when the LSID element expires.
- the expiration attribute may or may not exist. If not present, the receiver may assume that the LSID element is valid at all times or until the receiver receives a new LSID element with an associated expiration value.
- the LSID element may include at least one TransportSession element.
- the TransportSession element may include information on at least one LCT transport session.
- Each TransportSession element may include a tsi attribute, a SourceFlow element, and / or a RepairFlow element.
- the Tsi attribute specifies a transport session identifier. Session identifiers do not have a value of zero.
- the SourceFlow element may include information about the source flow transmitted through the transport session.
- the RepairFlow element may include information about repair flow transmitted through a transport session.
- the data encapsulated into the application layer transport protocol packet can be packetized according to the IP / UDP method.
- Data packetized according to an IP / UDP scheme may be referred to as an IP / UDP datagram.
- the IP / UDP datagram may be transmitted by being carried in a broadcast signal.
- data encapsulated in the form of ISO BMFF can be delivered to the receiver based on a streaming technique.
- the streaming technique may include MPEG-DASH.
- the signaling data may be transmitted in the following manner.
- signaling data may be transmitted through a specific data pipe (hereinafter referred to as DP) of a transport frame (or frame) delivered to a physical layer of a next-generation broadcast transmission system and a broadcast network according to a signaling property.
- DP specific data pipe
- the signaling form may be a form encapsulated into a bit stream or an IP / UDP datagram.
- the signaling data may be returned and delivered as a response to the request of the receiver.
- ESG data and NRT content data may be transmitted in the following manner.
- ESG data and NRT content data may be encapsulated into an application layer transport protocol packet. Then, the data encapsulated in the application layer transport protocol packet may be transmitted as described above.
- the ESG data and the NRT content data may be returned and delivered as a response to the request of the receiver.
- the physical layers (Broadcast PHY and Broadband PHY) of the apparatus for transmitting broadcast signals according to an embodiment of the present invention may have the structure shown in FIG. 1.
- the physical layer of the broadcast signal receiving apparatus may have a structure shown in FIG. 8.
- the signaling data and the IP / UDP datagram may be transmitted through a specific data pipe (hereinafter referred to as DP) of a transport frame (or frame) delivered to the physical layer.
- DP specific data pipe
- the input format block 1000 may receive signaling data and IP / UDP datagrams, and demultiplex each signaling data and IP / UDP datagrams into at least one DP.
- the output processor 9300 may perform an operation opposite to the input format block 1000.
- FIG. 27 illustrates a data structure of file-based multimedia content according to an embodiment of the present invention.
- FIG. 27 illustrates a data structure of file-based multimedia content according to an embodiment of the present invention.
- File-based multimedia content refers to multimedia content consisting of at least one file.
- Multimedia content such as a broadcast program
- the presentation may include at least one object.
- the object may be a file.
- the object may include at least one fragment.
- Fragment according to an embodiment of the present invention refers to a data unit that can be independently decoded and reproduced without dependency on previous data.
- the fragment containing the video data starts with an IDR Picture, and the header data for parsing the media data also has no dependency on the preceding fragment.
- the fragment according to an embodiment of the present invention may be divided and transmitted in units of at least one transport block.
- a transport block according to an embodiment of the present invention means a minimum data unit that can be encoded and transmitted independently without dependency on prior data.
- the transport block may be a meaningful data unit in a GOP unit or chunk unit of a variable size.
- the transport block may include at least one chunk composed of the same media data, such as a GOP of video data. Chunk may refer to a segment of content.
- the transport block may include at least one source block.
- the GOP is a basic unit that performs coding used in video coding, and is a data unit of variable size representing a set of frames including at least one I-frame.
- the GOP since the media data is independently transmitted in a unit of an object internal structure which is a meaningful data unit, the GOP may include an open GOP and a closed GOP.
- a B-frame within one GOP may refer to an I-frame or P-frame of an adjacent GOP.
- Open GOP can significantly increase coding efficiency.
- a B-frame or a P-frame refers only to frames within that GOP, not to frames outside of that GOP.
- the transport block may include at least one data, and each data may have the same or different media type.
- the media type may include an audio type and a video type. That is, the transport block may include at least one data having different media types together as in the case of audio and video.
- the fragment according to an embodiment of the present invention may include a fragment header and a fragment payload.
- the fragment header may include timing information and indexing information for parsing the above-described chunks.
- the fragment header may consist of at least one transport block.
- the fragment header may be included in one transport block.
- at least one chunk data constituting the fragment payload may be included in at least one transport block.
- the fragment header and the fragment payload may be included in at least one transport block, respectively.
- the transport block according to an embodiment of the present invention may be divided into at least one symbol. At least one symbol may be packetized.
- the broadcast signal transmission apparatus according to an embodiment of the present invention may packetize at least one symbol into an LCT packet.
- the broadcast signal transmitting apparatus may transmit packetized data to the broadcast signal receiving apparatus.
- FIG. 28 is a diagram illustrating a media segment configuration of MPEG-DASH to which a data structure is applied according to an embodiment of the present invention.
- FIG. 28 there is shown an embodiment in which a data structure according to an embodiment of the present invention is applied to a media segment of MPEG-DASH.
- the broadcast signal transmission apparatus provides a seamless real-time streaming service by retaining multimedia contents having a plurality of qualities in a server and providing multimedia contents suitable for a user's broadcasting environment and an environment of a broadcast signal receiving apparatus. can do.
- the apparatus for transmitting broadcast signals may provide a real time streaming service using MPEG-DASH.
- the broadcast signal transmitting apparatus is a broadcast signal receiving apparatus using a ROUTE protocol for a media presentation description (MPD) in XML format and a multimedia content for transmission in binary format, and is dynamically changed according to the broadcast environment and the environment of the broadcast signal receiving apparatus. Can be sent.
- MPD media presentation description
- the MPD has a hierarchical structure and may include information on structural functions and roles of each layer.
- the segment may comprise a media segment.
- the media segment refers to a data unit in the form of a media-related object separated by quality and time to be transmitted to a broadcast signal receiving apparatus to support a streaming service.
- the media segment may include information of a media stream, at least one access unit, presentation time, or information on a method of accessing a media presentation in the corresponding segment, such as an index.
- the media segment may be divided into at least one subsegment by a segment index.
- MPEG-DASH content may include at least one media segment.
- the media segment may include at least one fragment.
- the fragment may be the Subsegment described above.
- the fragment may include a fragment header and a fragment payload.
- the fragment header may include a segment index box (sidx) and a movie fragment box (moof).
- the segment index box may provide initial presentation time, data offset, and stream access point (SAP) information of media data existing in the fragment.
- the movie fragment box may include metadata about the media data box mdat.
- the movie fragment box may include timing, indexing, decoding information, and the like, of a media data sample in the fragment.
- the fragment payload may include a media data box (mdat).
- the media data box mdat may include actual media data for the corresponding media component (video and audio, etc.).
- the encoded media data is included in chunks in the media data box (mdat) corresponding to the fragment payload. As described above, samples corresponding to the same track may be included in one chunk.
- the broadcast signal transmission apparatus may generate at least one transport block by dividing the fragment.
- the broadcast signal transmission apparatus may include the fragment header and the payload data in different transport blocks to distinguish the fragment header and the payload data.
- the broadcast signal transmission apparatus may generate a transport block partitioned in chunks in order to divide and transmit data in the fragment payload. That is, the broadcast signal transmission apparatus according to an embodiment of the present invention may generate a transport block so that the boundary of the chunk and the boundary point of the transport block coincide.
- the broadcast signal transmission apparatus may generate at least one symbol by dividing at least one transport block.
- the length of all symbols in an object may be the same.
- the last symbol of the transport block may include padding bytes.
- the broadcast signal transmission apparatus may packetize at least one symbol.
- the broadcast signal transmission apparatus may generate an LCT packet based on at least one symbol.
- the broadcast signal transmission apparatus may transmit the generated LCT packet.
- the apparatus for transmitting broadcast signals generates a fragment header after generating a fragment payload first to generate a fragment.
- the broadcast signal transmission apparatus may generate a transport block corresponding to the media data in the fragment payload.
- at least one transport block corresponding to the media data included in the media data box mdat may be sequentially generated in chunk units. Then, the broadcast signal transmission apparatus may generate a transport block corresponding to the fragment header.
- the broadcast signal transmission apparatus may transmit a transport block generated in order to transmit media content in real time broadcasting according to a generation order.
- the broadcast signal receiving apparatus parses the fragment payload after parsing the fragment header first.
- the broadcast signal transmission apparatus may transmit the parsed data in a parsing order.
- 29 is a diagram illustrating data processing time using a ROUTE protocol according to an embodiment of the present invention.
- the multimedia data may include at least one object.
- Each object may include at least one fragment.
- one object may include two fragments (Fragment1 and Fragment 2).
- the broadcast signal transmission apparatus may split a fragment into at least one transport block.
- the transport block may be a source block, which will be described below with reference to the source block.
- the apparatus for transmitting broadcast signals divides fragment 1 into three source blocks (Source Block 0, Source Block 1, and Source Block 2), and fragments 2 into three source blocks (Source Block 3, Source Block 4, Source Block 5).
- the broadcast signal transmission apparatus may individually transmit each divided source block.
- the broadcast signal transmission apparatus may start transmission of each source block generated immediately after or at the time when each source block is generated.
- the broadcast signal transmission apparatus may transmit source block 0 (S 0 ) after generating source block 0 (S 0 ) for a period of t e0 to t e1 .
- Source block 0 (S 0) transmission start time (t d0) of may be the same as or immediately after the source block 0 (S 0) When completed (t d0) generation of.
- the apparatus for transmitting broadcast signals may generate source blocks 1 (S 1 ) to source blocks 5 (S 5 ) and transmit each of the generated source blocks.
- a transmission wait time of Dt2 may occur between a time point at which one source block starts to be generated and a time point at which transmission starts.
- the transmission wait time D t2 generated in the broadcast signal transmission apparatus according to an embodiment of the present invention is significantly reduced compared to the transmission wait time D t1 generated in the conventional broadcast signal transmission apparatus. Therefore, the broadcast signal transmission apparatus according to an embodiment of the present invention has an effect of reducing the transmission waiting time as compared to the conventional broadcast signal transmission apparatus.
- the broadcast signal receiving apparatus may receive each of the divided source blocks, and generate at least one fragment by combining the received source blocks.
- the apparatus for receiving broadcast signals receives source block 0 (S 0 ), source block 1 (S 1 ), and source block 2 (S 2 ), and combines the three received source blocks to generate fragment 1. can do.
- the apparatus for receiving broadcast signals may receive source block 3 (S 3 ), source block 4 (S 4 ), and source block 5 (S 5 ), and combine fragments to generate fragment 2. have.
- the broadcast signal receiving apparatus may play back each generated fragment individually.
- the broadcast signal receiving apparatus may play back each fragment generated immediately after or when each fragment is generated.
- the broadcast signal receiving apparatus may reproduce each fragment at or after the time when all the source blocks corresponding to each fragment are transmitted.
- the broadcast signal receiving apparatus may generate fragment 1 after receiving source blocks 0 (S 0 ) to source blocks 2 (S 2 ) for t d0 to t d3 hours. Then, the broadcast signal receiving apparatus may play the generated fragment 1.
- the reproduction start time point t p0 of the fragment 1 may be immediately after the generation of the fragment 1 or the same. In addition, the reproduction start time point t p0 of the fragment 1 may be immediately after or the same as the reception completion time point t d3 of the source block 2 (S 2 ).
- the broadcast signal receiving apparatus may generate fragment 2 after receiving source blocks 3 (S 3 ) to 5 (S 5 ) for t d3 to t d6 hours. Can be. Then, the broadcast signal receiving apparatus may play the generated fragment 2.
- the present invention is not limited thereto, and the apparatus for receiving broadcast signals according to an embodiment of the present invention may receive a source block and reproduce the received source block.
- a reproduction waiting time of D r2 may occur between a time point at which one fragment is started and a time point at which playback is started.
- the reproduction waiting time D r2 generated in the broadcast signal receiving apparatus according to an embodiment of the present invention is significantly reduced compared to the reproduction waiting time D r1 generated in the conventional broadcast signal receiving apparatus. Therefore, the broadcast signal receiving apparatus according to an embodiment of the present invention has an effect of reducing the reproduction waiting time as compared to the conventional broadcast signal receiving apparatus.
- the sum of the transmission waiting time and the reproduction waiting time which is the time until one transport block is transmitted from the broadcast signal transmitting apparatus and reproduced by the broadcast signal receiving apparatus, can be significantly reduced. This means that the initial access time for the object is significantly shortened by the broadcast signal receiving apparatus.
- the broadcast signal transmission apparatus may transmit data in units of transport blocks, and the broadcast signal reception apparatus may reproduce the received data in units of transport blocks or fragments.
- the broadcast signal transmission apparatus may transmit data in units of transport blocks, and the broadcast signal reception apparatus may reproduce the received data in units of transport blocks or fragments.
- FIG. 30 is a view showing the structure of an LCT packet for transmitting a file according to an embodiment of the present invention.
- the application layer transport session may consist of a combination of IP address and port number. If the application layer transport session is a ROUTE protocol, the ROUTE session may consist of at least one Layered Coding Transport (LCT) sessions. For example, when delivering one media component through one LCT transport session, at least one media component may be multiplexed and transmitted through one application layer transport session. In addition, at least one transport object may be delivered through one LCT transport session.
- LCT Layered Coding Transport
- each field of the LCT packet indicates the following information.
- LCT packets include LCT version number field (V), Congestion control flag field (C), Reserved field (R), Transport Session Identifier flag field (S), Transport Object Identifier flag field (O), and Half-word flag field (H). ), Sender Current Time present flag field (T), Expected Residual Time present flag field (R), Close Session flag field (A), Close Object flag field (B), LCT header length field (HDR_LEN), Codepoint field (CP ), A Congestion Control Information field (CCI), a Transport Session Identifier field (TSI), a Transport Object Identifier field (TOI), a Header Extensions field, an FEC Payload ID field, and / or an Encoding Symbol (s) field.
- V LCT version number field
- C Congestion control flag field
- R Reserved field
- S Transport Session Identifier flag field
- OF Transport Object Identifier flag field
- H Half-word flag field
- the LCT version number field (V) may indicate a protocol version number.
- the LCT version number field (V) may indicate the LCT version number.
- the LCT version number field (V) of the LCT header may be interpreted as a ROUTE version number field.
- the version of ROUTE implicitly may use version '1' of the LCT building block.
- the version number may be '0001b'.
- the congestion control flag field (C) may indicate the length of the congestion control information field.
- the reserved field R may be a protocol-specific indication field (PSI).
- PSI Protocol-Specific Indication field
- the PSI field may indicate whether the current packet is a soap packet or an FEC repair packet. Since the ROUTE source protocol only transmits source packets, the PSI field may be set to '10b'.
- the Transport Session Identifier flag field (S) may indicate the length of the Transport Session Identifier field.
- the Transport Object Identifier flag field (O) may indicate the length of the Transport Object Identifier field.
- an object may mean one file, and the TOI is identification information of each object, and a file whose TOI is 0 is called an FDT.
- the Half-word flag field (H) indicates whether to add half-word (16 bits) to the length of the TSI and TOI fields.
- the Sender Current Time present flag field may indicate whether a Sender Current Time (SCT) exists.
- the SCT may be included to indicate to the sender how long the session will be processed.
- the Expected Residual Time present flag field may indicate whether an Expected Residual Time (ERT) field exists.
- the ERT may be included to indicate to the sender how long the session / object transmission will last.
- the Close Session flag field (A) indicates that the session has ended or is about to end.
- the Close Object flag field (B) indicates that the object being transmitted has finished or is about to be terminated.
- the LCT header length field (HDR_LEN) may indicate the total length of the LCT header in 32-bit word units.
- the codepoint field may indicate the type of payload carried by the current packet. By type of payload, an additional payload header can be added before the payload data.
- the Congestion Control Information field (CCI) is used to transmit congestion control information such as layer numbers, logical channel numbers, and sequence numbers.
- the CCI field in the LCT header may include necessary Congestion Control Information.
- the Transport Session Identifier field is a unique identifier of the session.
- the TSI may uniquely identify the session among all sessions sent from a particular sender.
- the TSI field may identify a transport session in ROUTE.
- the content of the transport session may be provided by an LST session instance description (LSID).
- LSID LST session instance description
- the LSID may define what is transmitted in each LCT transport session of a ROUTE session. Each transport sessinon can be uniquely identified by the TSI in the LCT header.
- the LSID may be transmitted through the same ROUTE session including LCT transmission sessions, and may also be transmitted through a communication network, a broadcasting network, an internet network, a cable network, and / or a satellite network. The means by which the LSID is transmitted is not limited to this.
- the LSID may be transmitted through a specific LCT transport session in which the value of TSI is '0'.
- the LSID may include signaling information about all transport sessions transmitted through the ROUTE session.
- the LSID may include LSID version information and information about the validity of the LSID.
- the LSID may include transport session information that provides information about the LCT transport session.
- the transport session information includes TSI information identifying a transport session, source flow information transmitted in the corresponding TSI, and information on the source flow in which the source data is transmitted, and a repair flow transmitted in the corresponding TSI and in which repair data is transmitted. It may include repair flow information for providing information on the transport session property information including additional property information on the transport session.
- the TOI can indicate which object in the session is currently related to a packet.
- the TOI field may indicate which object in the current session belongs to the payload of the current packet.
- the mapping of the TOI field to the object may be provided by the Extended FDT.
- Extended FDT can specify the specifics of the file delivery data. This may be an extended FDT instance.
- the extended FDT can be used to generate FDT-equivalent descriptions for the delivery object along with the LCT packet header.
- the Header Extensions field is used as an LCT header extension part for transmitting additional information. Header Extensions in the LCT can be used to accommodate optional header fields that are not always used or have a variable size.
- the EXT_TIME extension can be used to transmit some type of timing information.
- the EXT_TIME extension may include general purpose timing information, Sender Current Time (SCT), Expected Residual Time (ERT), and / or Sender Last Change (SLC) time extensions.
- SCT Sender Current Time
- ERT Expected Residual Time
- SLC Sender Last Change
- the EXT_TIME extension can be used for timing information with narrower applicability.
- the EXT_TIME extension may be defined for single protocol instantiation. In this case, the EXT_TIME extension may be described separately.
- the FEC Payload ID field includes identification information of a transmission block or an encoding symbol.
- the FEC Payload ID indicates an identifier when the file is FEC encoded. For example, when the FLUTE protocol file is FEC encoded, the FEC Payload ID may be allocated by a broadcasting station or a broadcasting server to distinguish it.
- the Encoding Symbol (s) field may include data of a transmission block or an encoding symbol.
- the packet payload may include bytes generated from the object. If more than one object is sent within a session, the Transmission Object ID (TOI) in the LCT header can be used to identify from which object the packet payload data was generated.
- TOI Transmission Object ID
- the LCT packet according to an embodiment of the present invention may include a Real Time Support Extension field (EXT_RTS) which is an extension of the Header Extensions field.
- EXT_RTS may include split generation and consumption information of a file, and may be expressed as fragment information hereinafter.
- the LCT packet according to an embodiment of the present invention includes EXT_RTS as an extension of the Header Extensions field, thereby supporting real-time file transmission and consumption information in a manner compatible with existing LCT.
- the fragment information EXT_RTS may include a header extension type field (HET), a fragment start indicator field (SI), a fragment header flag field (FH), and a fragment header complete indicator field (FC). Can be.
- HET header extension type field
- SI fragment start indicator field
- FH fragment header flag field
- FC fragment header complete indicator field
- the Header Extension Type field indicates the type of the corresponding header extension.
- the HET field may be an integer of 8 bits. Basically, in the LCT, when the HET has a value between 0 and 127, there is a variable length header extension in 32-bit word units and the length is described in the Header Extension Length field (HEL) following the HET. If the HET has a value between 128 and 255, the header extension has a 32-bit fixed length.
- the fragment information EXT_RTS has a fixed length of 32 bits, so that the type of the corresponding header extension can be identified by one unique value among values between 128 and 255.
- the SI field indicates that the corresponding LCT packet includes the start of the fragment.
- the FH field indicates that the LCT packet includes a fragment header part.
- the fragment header has a characteristic that the generation order and the consumption order are different from the fragment payload.
- the broadcast signal receiving apparatus may regenerate fragments by rearranging the transport blocks received in the order of generation based on the FH field in the order of consumption.
- the FC field may indicate that the packet includes the last data of the fragment. For example, if the fragment header is transmitted after the fragment payload is first transmitted, the FC field may indicate that the FC field includes the last data of the fragment header. If the fragment payload is transmitted after the fragment header is transmitted first, the FC field may indicate that the fragment field contains the last data of the fragment payload. In the following description, the fragment payload is first transmitted and then the fragment header is transmitted.
- the broadcast signal reception apparatus When the broadcast signal reception apparatus receives the packet in which the FC field is set to 1, the broadcast signal reception apparatus recognizes that the reception of the fragment header is completed and may restore the fragment by combining the fragment header and the fragment payload.
- the Padding Bytes field indicates the number of padding bytes included in the corresponding LCT packet.
- all LCT packets corresponding to one object must have the same length.
- the last symbol of each transport block may have a different length. Accordingly, the apparatus for transmitting broadcast signals according to an embodiment of the present invention can support real-time file transmission in a manner compatible with existing LCT by using a fixed length packet by filling the remaining portion of the packet with padding bytes.
- the Reserved field may be reserved for future use.
- FIG. 31 is a view showing the structure of an LCT packet for transmitting a file according to an embodiment of the present invention.
- the fragment information EXT_RTS may include a fragment header length field (FHL) instead of the FC field described with reference to FIG. 30.
- FHL fragment header length field
- the FHL field may provide information on whether or not reception of the fragment is completed by indicating the number of symbols constituting the fragment.
- the FHL field may indicate the total number of symbols corresponding to each fragment including both the fragment header and the fragment payload.
- the FHL field may indicate the total number of symbols of the later transmission of the fragment header and the fragment payload.
- the FHL field may indicate the total number of symbols corresponding to the fragment header.
- the FHL field may indicate the length of the fragment header.
- the FHL field may indicate the total number of symbols corresponding to the fragment payload.
- the FHL field may indicate the length of the fragment payload.
- the fragment payload is first transmitted and then the fragment header is transmitted.
- the broadcast signal receiving apparatus may receive an LCT packet including a fragment header corresponding to the number of symbols indicated in the FHL field.
- the broadcast signal reception apparatus may identify that the reception of the fragment header is completed by checking the number of reception of the LCT packet including the fragment header.
- the broadcast signal reception apparatus may identify the completion of the reception of the fragment header by checking the number of transport blocks corresponding to the fragment header.
- FIG. 32 is a diagram illustrating real-time broadcast assistance information signaling using an FDT according to an embodiment of the present invention.
- an embodiment of the present invention provides a method of identifying information about segmentation generation and segmentation consumption of file-based multimedia content in a real-time broadcasting environment.
- Information on the segmentation generation and segmentation consumption of file-based multimedia content may include the above-described data structure and LCT packet information.
- the broadcast signal transmission apparatus may additionally transmit separate signaling information in order to identify split generation information and split consumption information of a file.
- the signaling information may include signaling information using metadata or out-of-band.
- FIG. 32 a method of transmitting signaling information about real time broadcast support information according to an embodiment of the present invention is illustrated.
- the broadcast signal transmission apparatus may transmit signaling information through a file delivery table (FDT) level or a real-time-support attribute of a file level.
- FDT file delivery table
- Real-Time-Support When Real-Time-Support is set to 1, the objects described at the corresponding FDT level or File level have the above-described data structure and packet information, thereby supporting file segmentation generation and consumption in a real-time broadcasting environment. May indicate that there is.
- FIG 33 is a diagram illustrating a configuration of a broadcast signal transmission apparatus according to an embodiment of the present invention.
- a broadcast signal transmission apparatus for transmitting a broadcast signal including multimedia content using a broadcast network may include a signaling encoder C21005, a Transmission Block Generator C21030, and / or a transmitter. (C21050).
- the signaling encoder C21005 may generate signaling information.
- the signaling information is information indicating whether to transmit multimedia content in real time.
- the signaling information may indicate to transmit the multimedia content in real time to at least one of a file level and an FDT level. If the signaling information indicates to transmit the multimedia content at the file level in real time, all data belonging to the file may be transmitted in real time. In addition, if the signaling information indicates to transmit the multimedia content at the FDT level in real time, all files or data belonging to the FDT may be transmitted in real time.
- the Transmission Block Generator C21030 may divide a file included in the multimedia content into at least one transport block that is a data unit that is independently encoded and transmitted.
- the transmitter C21050 may transmit a transport block.
- 34 is a diagram illustrating a configuration of a broadcast signal transmission apparatus according to an embodiment of the present invention.
- a broadcast signal transmission apparatus for transmitting a broadcast signal including multimedia content using a broadcast network may include a signaling encoder (not shown), a media encoder (C21010), and a fragment generator (C21020). ), A transmission block generator C21030, a packetizer C21040, and / or a transmitter C21050.
- the signaling encoder (not shown) may generate signaling information.
- the signaling information is information indicating whether to transmit multimedia content in real time.
- the Media Encoder C21010 may generate media data by encoding multimedia content.
- media data may be represented as data.
- the fragment generator C21020 may generate at least one fragment that is a data unit that is independently decoded and reproduced by dividing each file constituting the multimedia content.
- the fragment generator C21020 may generate a fragment header after generating the fragment payload constituting each fragment.
- the fragment generator C21020 may buffer media data corresponding to the fragment payload. Then, the fragment generator C21020 may generate a chunk corresponding to the fragment payload based on the buffered media data.
- the chunk may be a data unit of variable size composed of the same media data, such as a GOP of video data.
- the Fragment Generator C21020 may complete the generation of the chunk corresponding to the fragment payload after continuing to buffer the media data.
- the fragment generator C21020 may determine whether all data corresponding to the fragment payload are generated as chunks.
- the fragment generator C21020 may generate a fragment header corresponding to the fragment payload.
- the transmission block generator C21030 may generate at least one transport block that is a data unit that is independently encoded and transmitted by dividing the fragment.
- a transport block according to an embodiment of the present invention means a minimum data unit that can be encoded and transmitted independently without dependency on prior data.
- the transport block may include at least one chunk composed of the same media data, such as a GOP of video data.
- the Transmission Block Generator C21030 may first generate a transport block corresponding to the fragment payload, and then generate a transport block corresponding to the fragment header.
- the Transmission Block Generator C21030 may generate a fragment header as one transport block. However, the present invention is not limited thereto, and the transmission block generator C21030 may generate a fragment header as at least one transport block.
- the transmission block generator C21030 when a fragment header is generated after the fragment generator C21020 generates a fragment payload constituting each fragment, the transmission block generator C21030 generates a transport block corresponding to the fragment payload. Thereafter, a transport block corresponding to the fragment header may be generated.
- a transport block corresponding to the fragment header is generated first, and then a transport block corresponding to the fragment payload is generated. It may be.
- the Transmission Block Generator C21030 may generate a transport block corresponding to the fragment payload and a transport block corresponding to the fragment header as separate transport blocks.
- the packetizer C21040 may divide the transport block into at least one symbol having the same size and packetize each of the at least one symbol into at least one packet.
- the present invention is not limited thereto, and the symbol may be generated by another device.
- the length of a symbol according to an embodiment of the present invention may be the same. However, the last symbol of each transport block may be smaller in length than other symbols.
- the packetizer C21040 may packetize at least one symbol into at least one packet.
- the packet may be an LCT packet.
- the packet may include a packet header and a packet payload.
- the packet header may include fragment information having information on split generation and split consumption of the file.
- Split generation of a file means splitting and generating a file constituting a multimedia content into at least one chunk or transport block that can be independently encoded and transmitted.
- Splitting consumption of a file means combining at least one transport block received and restoring at least one fragment that can be independently decoded and reproduced and reproduced in units of fragments.
- splitting consumption of a file may include reproducing on a transport block basis.
- the fragment information may include generation of an SI field indicating that a packet includes data of a fragment, an FH field indicating that a packet includes data of a fragment header, and generation of a transport block corresponding to each fragment. It may include at least one of fragment completion information indicating completion, and a PB field indicating the number of padding bytes included in the packet.
- the fragment information may further include a header extension type field (HET) field indicating the type of header extension of the corresponding packet.
- HAT header extension type field
- the fragment completion information may include one of an FC field indicating that the packet includes the last data of the fragment header and an FHL field indicating the total number of symbols corresponding to the fragment header.
- the fragment information may be generated by the packetizer C21040 or may be generated by a separate device.
- the packetizer C21040 will be described with reference to generating fragment information.
- the packetizer C21040 may identify whether the generated symbol includes the first data of the fragment.
- the packetizer C21040 may identify whether the generated symbol includes the first data of the fragment payload. If the generated symbol includes the first data of the fragment payload, the SI field may be set to '1'. If the generated symbol does not include the first data of the fragment payload, the SI field may be set to '0'.
- the packetizer C21040 may identify whether the generated symbol includes data of the fragment payload or data of the fragment header.
- the FH field may be set to '1'. If the generated symbol does not include data of the fragment payload, the FH field may be set to '0'.
- the packetizer C21040 may identify whether generation of a transport block corresponding to each fragment is completed.
- the fragment completion information indicating that the generation of the transport block corresponding to each fragment has been completed may include an FC field indicating that the packet includes the last data of the fragment header.
- the FC field may be set to '1'. If the generated symbol does not include data of the fragment header or is not the last symbol of the corresponding transport block, the FC field may be set to '0'.
- the packetizer C21040 may identify whether the generated symbol is the last symbol of the corresponding transport block and is a symbol having a length different from other symbols. For example, another symbol may be a symbol having a predetermined length, and a symbol different in length from another symbol may be a symbol having a shorter length than other symbols.
- the packetizer C21040 may insert padding bytes into a packet corresponding to the last symbol of each transport block.
- the packetizer C21040 may calculate the number of packing bytes.
- the PB field may indicate the number of padding bytes.
- the padding byte is a byte added to a symbol whose length is short compared to other symbols so that the length is the same as other symbols.
- the padding byte may be the remainder of the packet except for the symbol.
- the PB field may be set to '0'.
- the packet payload may include at least one symbol.
- a description will be given of the fact that one packet includes one symbol.
- the packet containing the last symbol of each transport block may include at least one padding byte.
- the transmitter C21050 may transmit at least one packet in the order in which the transport blocks are generated.
- the transmitter C21050 may first transmit a transport block corresponding to the fragment payload and then transmit a transport block corresponding to the fragment header.
- the present invention is not limited thereto, and when a fragment header and a fragment payload are already generated for the multimedia content, the transmitter C21050 according to an embodiment of the present invention first transmits a transport block corresponding to the fragment header.
- a transport block corresponding to the fragment payload may be transmitted.
- 35 is a flowchart illustrating a real-time generation and transmission process of file-based multimedia content according to an embodiment of the present invention.
- FIG. 35 a process of transmitting the broadcast signal by the above-described broadcast signal transmitter in FIG. 34 is illustrated.
- the apparatus for transmitting broadcast signals may start encoding multimedia content using the media encoder C21010 (CS11100).
- the apparatus for transmitting broadcast signals may generate media data by encoding multimedia content.
- the broadcast signal transmission apparatus may buffer media data corresponding to the fragment payload (CS11200). Then, the broadcast signal transmission apparatus may generate a chunk corresponding to the fragment payload based on the buffered media data.
- the broadcast signal transmission apparatus may complete the generation of the chunk corresponding to the fragment payload after continuously buffering the media data (CS11300).
- the apparatus for transmitting broadcast signals may generate at least one fragment which is a data unit that is independently decoded and reproduced by dividing each file constituting the multimedia content by using the fragment generator C21020 (CS11400).
- the broadcast signal transmission apparatus may generate a fragment header after generating the fragment payload constituting each fragment.
- the broadcast signal transmission apparatus may determine whether all data corresponding to the fragment payload are generated in the chunk.
- the broadcast signal transmission apparatus may generate a fragment header corresponding to the fragment payload.
- the apparatus for transmitting broadcast signals may generate at least one transport block, which is a data unit that is independently encoded and transmitted by dividing the fragment using a transmission block generator C21030 (CS11500).
- the broadcast signal transmitting apparatus when generating a fragment header after generating a fragment payload constituting each fragment, transmits a transmission corresponding to the fragment header after generating a transport block corresponding to the fragment payload. You can create a block.
- the broadcast signal transmitting apparatus may generate a transport block corresponding to a fragment payload and a transport block corresponding to a fragment header as separate transport blocks.
- the apparatus for transmitting broadcast signals may packetize the at least one symbol into at least one packet by dividing the transport block into at least one symbol having the same size using the packetizer C21040 (CS11600 and CS11700).
- the broadcast signal transmission apparatus may transmit at least one packet in the order in which the transport blocks are generated by using the transmitter C21050.
- 36 is a flowchart illustrating a process of generating a packet using a packetizer in detail by a broadcast signal transmission apparatus according to an embodiment of the present invention.
- the broadcast signal transmission apparatus may identify whether the generated symbol includes the first data of the fragment (CS11710).
- the SI field may be set to '1' (CS11712). If the generated symbol does not include the first data of the fragment payload, the SI field may be set to '0' (CS11714).
- the apparatus for transmitting broadcast signals may identify whether the generated symbol includes data of the fragment payload or data of the fragment header (CS11720).
- the FH field may be set to '1' (CS11722). If the generated symbol does not include data of the fragment payload, the FH field may be set to '0' (CS11724).
- the broadcast signal transmission apparatus may identify whether generation of a transport block corresponding to each fragment has been completed (CS11730).
- the FC field may be set to '1' (CS11732). If the generated symbol does not include data of the fragment header or is not the last symbol of the corresponding transport block, the FC field may be set to '0' (CS11734).
- the apparatus for transmitting broadcast signals may identify whether the generated symbol is the last symbol of the corresponding transport block and is a symbol whose length is different from other symbols (CS11740).
- the broadcast signal transmission apparatus may insert padding bytes into a packet corresponding to the last symbol of each transport block.
- the broadcast signal transmission apparatus may calculate the number of padding bytes (CS11742).
- the PB field may indicate the number of padding bytes.
- the PB field may be set to '0' (CS11744).
- the packet payload may include at least one symbol.
- FIG. 37 is a flowchart illustrating a real-time generation / transmission process of file-based multimedia content according to an embodiment of the present invention.
- FIG. 37 the contents of FIG. 37 and those described in FIGS. 35 and 36 are substantially the same, and thus detailed descriptions thereof will be omitted.
- the broadcast signal transmission apparatus may use the FHL field instead of the FC field.
- the above fragment information may include fragment completion information indicating that generation of a transport block corresponding to each fragment has been completed.
- the fragment completion information may include an FHL field indicating the total number of symbols corresponding to the fragment header.
- the broadcast signal transmission apparatus may calculate the number of symbols corresponding to the transport block including the data of the fragment header and record the number of symbols in the FHL field (CS12724).
- the FHL field is the total number of symbols corresponding to the fragment header part and indicates the length of the fragment header.
- the FHL field may be included in the fragment information instead of the above-described FC field so that the broadcast signal receiving apparatus can identify that the reception of the fragment header is completed.
- the broadcast signal reception apparatus may identify whether the reception of the fragment header is completed by checking the number of transmissions of packets including the number of fragment headers recorded in the FHL field.
- FIG. 38 illustrates a structure of a file-based multimedia content receiver according to an embodiment of the present invention.
- a broadcast signal receiving apparatus for transmitting a broadcast signal including multimedia content using a broadcasting network according to an embodiment of the present invention includes a receiver (not shown), a signaling decoder (C22005), and a transmission block regenerator (C22030). ) And / or Media Decoder C22060.
- the signaling decoder C22005 may decode the signaling information.
- the signaling information is information indicating whether to transmit multimedia content in real time.
- the Transmission Block Regenerator C22030 may combine at least one broadcast signal to restore at least one transport block that is a data unit that is independently encoded and transmitted.
- the media decoder C22060 may decode the transport block.
- 39 illustrates a structure of a file-based multimedia content receiver according to an embodiment of the present invention.
- the apparatus for receiving broadcast signals includes a receiver (not shown), a signaling decoder (not shown), a packet filter (C22010), a packet depacketizer (C22020), and a transmission block regenerator (C22030). , Fragment Regenerator (C22040), Fragment Parser (C22050), Media Decoder (C22060), and / or Media Renderer (C22070).
- the receiver may receive a broadcast signal.
- the broadcast signal may include at least one packet.
- Each packet may include a packet header including fragment information and a packet payload including at least one symbol.
- the signaling decoder C22005 may decode the signaling information.
- the signaling information is information indicating whether to transmit multimedia content in real time.
- the packet filter C22010 identifies the start point of the fragment from at least one packet received at any point, and enables packet processing to start from the start point of the fragment.
- the packet filter C22010 may identify a start point of the fragment based on the SI field of the fragment information included in the packet. If the SI filter indicates that the corresponding packet includes the start of the fragment, the packet filter C22010 may discard the packets before the corresponding packet and deliver the packet to the Packet Depacketizer C22020.
- the packet filter C22010 may discard packets before the packet set to '1' and filter packets after the packet set to '1'.
- the packet depacketizer C22020 may depacketize at least one packet to extract fragment information included in the packet header and at least one symbol included in the packet payload.
- the Transmission Block Regenerator C22030 may combine at least one packet to restore at least one transport block that is a data unit that is independently encoded and transmitted.
- the recovered transport block may include data corresponding to the fragment header, and may include data corresponding to the fragment payload.
- the Fragment Regenerator C22040 may combine the at least one transport block to complete the restoration of the fragment header and the fragment payload, and then combine the fragment header and the fragment payload to restore the fragment, which is a data unit that is independently decoded and reproduced. have.
- the fragment regenerator C22040 may restore the fragment payload and the fragment header by combining the transport blocks based on the fragment information.
- the fragment regenerator C22040 may restore the fragment header after first recovering the fragment payload according to the order of received packets.
- the Fragment Regenerator C22040 may restore the fragment header by combining at least one transport block corresponding to the fragment header.
- the Fragment Regenerator C22040 may restore the fragment payload by combining at least one transport block corresponding to the fragment payload.
- the Fragment Regenerator C22040 may determine that the fragment payload and restore the fragment payload. If the value of the FH field is '1', the Fragment Regenerator C22040 may determine that the fragment header is a fragment header and restore the fragment header.
- the fragment regenerator C22040 may restore the fragment by combining the recovered fragment payload and the fragment header.
- the first method is to use the FC field included in the fragment information.
- the fragment completion information may include an FC field indicating that the packet includes the last data of the fragment header.
- FC field indicates that the packet includes the last data of the fragment header
- the Fragment Regenerator C22040 determines that the reception of the fragment header and the fragment payload constituting each fragment is completed, and the fragment header and the fragment payload are completed. The restoration can be completed.
- the FC field may indicate that the packet includes the last data of the fragment header.
- the Fragment Regenerator C22040 may recognize that the reception of the fragment header is completed, and may terminate the process of restoring the fragment header. Then, the Fragment Regenerator C22040 may restore the fragment by combining the fragment header and the fragment payload.
- the broadcast signal reception apparatus may repeat the process of restoring the transport block.
- the broadcast signal receiving apparatus may repeat the process of restoring the transport block. If the value of the FC field is '1', the fragment regenerator C22040 may restore the fragment by combining the fragment header and the fragment payload.
- the second method may determine whether restoration of the fragment payload and the fragment header constituting each fragment is completed based on the FHL field included in the fragment information.
- Fragment Regenerator C22040 may count the number of packets including data of the fragment header.
- the fragment completion information further includes an FHL field indicating the total number of symbols corresponding to the fragment header, and if the value recorded in the FHL field is equal to the number of packets including the data of the fragment header, the fragment header header Fragment Regenerator (C22040) is used. And restoration of the fragment payload may be completed.
- FHL field indicating the total number of symbols corresponding to the fragment header
- the fragment parser C22050 may parse the restored fragment.
- the fragment fragment (C22050) may parse the fragment payload after parsing the fragment header first.
- the fragment parser C22050 may generate at least one media access unit by parsing the recovered fragment.
- the media access unit may include at least one media data.
- the media access unit may be a unit of media data of a predetermined size.
- Media Decoder C22060 may decode the fragment.
- the media decoder C22060 may generate media data by decoding at least one media access unit.
- the decoded media data can be rendered and presented.
- FIG. 40 is a diagram illustrating a real-time reception / consumption process of file-based multimedia content according to an embodiment of the present invention.
- 39 may be equally applied to a broadcast signal receiving method according to an embodiment of the present invention.
- the multimedia content divided into at least one packet is received.
- Combining the loads may include restoring fragments, which are data units that are independently decoded and reproduced, and / or decoding the fragments.
- the broadcast signal receiving apparatus may receive a broadcast signal using a receiver (not shown) (CS21010).
- the broadcast signal may include at least one packet.
- the broadcast signal reception apparatus may identify a start point of a fragment from at least one packet received at an arbitrary point using the packet filter 22010 (CS21020).
- the apparatus for receiving broadcast signals depacketizes at least one packet by using the packet depacketizer C22020 to extract fragment information included in the packet header and at least one symbol included in the packet payload. Can be extracted (CS21030).
- the broadcast signal receiving apparatus may restore at least one transport block, which is a data unit that is independently encoded and transmitted by combining packets using a Transmission Block Regenerator C22030 (CS21040).
- the recovered transport block may include data corresponding to the fragment header, and may include data corresponding to the fragment payload.
- the apparatus for receiving broadcast signals transmits whether a transport block reconstructed based on fragment information using a fragment regenerator C22040 is a transport block corresponding to a fragment header or a fragment payload. It may be identified whether the block (CS21050).
- the broadcast signal receiving apparatus may restore the fragment payload and the fragment header by combining the restored transport blocks.
- the broadcast signal receiving apparatus may restore the fragment payload by combining at least one transport block corresponding to the fragment payload (CS21060).
- the broadcast signal receiving apparatus may restore the fragment header by combining at least one transport block corresponding to the fragment header (CS21070).
- the broadcast signal receiving apparatus may check whether restoration of the fragment payload and the fragment header constituting each fragment is completed based on the FC field included in the fragment information (CS21080).
- the broadcast signal reception apparatus may repeat the process of restoring the transport block.
- the broadcast signal reception apparatus may determine that reception of each fragment is completed.
- the FC field may indicate that the packet includes the last data of the fragment header.
- the broadcast signal reception apparatus determines that reception of the fragment header and the fragment payload constituting each fragment is completed, and the fragment header and the fragment payload are received. Restoration of the load can be completed.
- the broadcast signal reception apparatus may repeat the process of restoring the transport block.
- the broadcast signal receiving apparatus independently combines the fragment header and the fragment payload after combining the at least one transport block using the fragment regenerator C22040 to complete the restoration of the fragment header and the fragment payload.
- the fragment which is the data unit to be reproduced can be restored (CS21090).
- the broadcast signal receiving apparatus may parse the recovered fragment by using the fragment parser C22050 (CS21090).
- the broadcast signal receiving apparatus may generate at least one media access unit by parsing the recovered fragment.
- the present invention is not limited thereto, and the apparatus for receiving broadcast signals may generate at least one media access unit by parsing the transport block.
- the apparatus for receiving broadcast signals may generate media data by decoding at least one media access unit using a media decoder C22060 (CS21100).
- the broadcast signal receiving apparatus may render and present the decoded media data using the media renderer C22070 (CS21110).
- 41 is a diagram illustrating a real-time reception / consumption process of file-based multimedia content according to an embodiment of the present invention.
- FIG. 41 the contents of FIG. 41 described in FIG. 40 are substantially the same, and thus detailed description thereof will be omitted.
- the broadcast signal receiving apparatus may determine whether reception of the fragment header and the fragment payload constituting each fragment is completed based on the FHL field.
- the broadcast signal receiving apparatus uses a fragment regenerator (C22040) to transmit a transport block reconstructed based on fragment information, whether the transport block corresponds to a fragment header or a transport block corresponding to a fragment payload. Awareness may be identified (CS22050).
- C22040 a fragment regenerator
- Awareness may be identified (CS22050).
- the broadcast signal receiving apparatus may restore the fragment payload and the fragment header, respectively, by combining the restored transport blocks.
- the broadcast signal receiving apparatus may restore the fragment payload by combining at least one transport block (CS22060).
- the Fragment Regenerator C22040 may restore the fragment header by combining at least one transport block (CS22070).
- the broadcast signal receiving apparatus may restore the fragment by combining the recovered fragment payload and the fragment header.
- the broadcast signal reception apparatus may check whether restoration of the fragment payload and the fragment header constituting each fragment is completed based on the FHL field included in the fragment information.
- the broadcast signal receiving apparatus may count the number N of packets constituting each fragment (CS22080). For example, the broadcast signal receiving apparatus may count the number of packets including data of the fragment header.
- One packet may include at least one symbol, which will be described below with reference to one packet including one symbol.
- the FHL field may indicate the number of symbols constituting the fragment. If a packet corresponding to the number of symbols recorded in the FHL field has not been received, the broadcast signal reception apparatus may repeat the process of restoring the transport block. For example, if reception of the fragment payload and the fragment header constituting each fragment is not completed, the broadcast signal receiving apparatus may repeat the process of restoring the transport block.
- the fragment completion information further includes an FHL field indicating the total number of symbols corresponding to the fragment header.
- the broadcast signal reception apparatus may determine that reception of the fragment payload and the fragment header constituting each fragment is completed, and may complete the restoration of the fragment header and the fragment payload. (CS22090).
- the FHL field may indicate the total number of symbols corresponding to each fragment including both the fragment header and the fragment payload. At this time, when a packet corresponding to the number of symbols recorded in the FHL field is received, the broadcast signal reception apparatus may determine that reception of the fragment payload and the fragment header constituting each fragment is completed.
- the FHL field may indicate the total number of symbols of what is later transmitted in the fragment header and the fragment payload.
- the FHL field may indicate the total number of symbols corresponding to the fragment header. At this time, if the number of symbols recorded in the FHL field and the number of packets corresponding to the received fragment header are the same, the broadcast signal reception apparatus may determine that reception of the fragment payload and the fragment header constituting each fragment is completed. have.
- the FHL field may indicate the total number of symbols corresponding to the fragment payload. At this time, if the number of symbols recorded in the FHL field is equal to the number of packets corresponding to the received fragment payload, the broadcast signal reception apparatus determines that reception of the fragment payload and the fragment header constituting each fragment is completed. Can be.
- the broadcast signal receiving apparatus may restore the fragment by combining the fragment header and the fragment payload (CS22100).
- FIG. 42 is a diagram showing the structure of a packet including object type information according to another embodiment of the present invention.
- the packet according to another embodiment of the present invention may be an LCT packet, and the LCT packet may include an LCT version number field (V), a Congestion control flag field (C), a Protocol-Specific Indication field (PSI), and a Transport Session Identifier flag field ( S), Transport Object Identifier flag field (O), Half-word flag field (H), Sender Current Time present flag field (T), Expected Residual Time present flag field (R), Close Session flag field (A), Close Object flag field (B), LCT header length field (HDR_LEN), Codepoint field (CP), Congestion Control Information field (CCI), Transport Session Identifier field (TSI), Transport Object Identifier field (TOI), Header Extensions field, FEC It may include a Payload ID field and / or an Encoding Symbol (s) field.
- V LCT version number field
- C Congestion control flag field
- PSI Protocol-Specific Indication field
- S Transport Session Identifier flag field
- S
- a packet according to another embodiment of the present invention may include packet information including metadata.
- the packet information may include object type information indicating the type of the object currently transmitted by the packet when transmitting the MPEG-DASH content.
- the object type information may indicate the type of the object that the current packet or packets to which the same TOI is being transmitted are transmitted.
- the object type information may identify the object type by utilizing two reserved bits located in the 12th bit from the start point of the LCT packet.
- the object type may include a regular file, an initialization segment, a media segment, and / or a self-initializing segment.
- the object type information For example, if the value of the object type information is "00”, the object type indicates "Regular File”; if the value of the object type information is “01”, the object type indicates “Initialization Segment”, and If the value is "10”, the object type may indicate “Media Segment”, and if the value of the object type information is "11”, the object type may indicate "Self-Initializing Segment".
- the type of the object indicated by each object type information may vary depending on the file content being transmitted, and the scheme defining the value of the object type information may be in the form of separate signaling information as a session or out-of-band currently being transmitted. Can be sent.
- Regular file is a unit of data in the form of an object like a general file constituting multimedia content.
- the initialization segment is a data unit in the form of an object that contains initialization information for accessing the representation.
- the initialization segment may include a file type box (ftyp) and a movie box (moov).
- the file type box (ftyp) may include a file type, file version, and compatibility information.
- the movie box may include metadata describing the media content.
- Media segment refers to a data unit in the form of a media-related object separated by quality and time to be transmitted to a broadcast signal receiving apparatus to support a streaming service.
- the media segment may include a segment type box (styp), a segment index box (sidx), a movie fragment box (moof), and a media data box (mdat).
- the segment type box (styp) may include segment type information.
- the segment index box sidx may provide initial presentation time, data offset, and SAP (Stream Access Points) information of media data existing in the media segment.
- the movie fragment box may include metadata about the media data box mdat.
- the media data box mdat may include actual media data for the corresponding media component (video and audio, etc.).
- Self-Initializing Segment refers to a data unit in the form of an object that includes both information of an Initialization Segment and information of a Media Segment.
- 43 is a diagram showing the structure of a packet including object type information according to another embodiment of the present invention.
- the object type information may identify the type of the object currently transmitted by the packet using the LCT Header Extension.
- the object type information using the LCT header extension may be applied to a packet for a transport protocol such as a realtime protocol (RTP).
- RTP realtime protocol
- the object type information may include a header extension type (HET) field, a type field, and / or a reserved field.
- HET header extension type
- the HET field may be an integer of 8 bits and may indicate the type of a corresponding header extension.
- the HET field may identify the type of the corresponding header extension as one unique value among values between 128 and 255.
- the header extension may have a fixed length of 32 bits.
- the Type field may indicate the type of an object to which the current LCT packet or LCT packets to which the same TOI is transmitted are transmitted.
- the Type field may be expressed as object type information.
- the object type may include a regular file, an initialization segment, a media segment, and a self-initializing segment according to the value of the object type information.
- the object type information For example, if the value of the object type information is "0x00", the object type indicates "Regular File”. If the value of the object type information is "0x01”, the object type indicates “Initialization Segment”, and If the value is "0x10”, the object type may indicate “Media Segment”, and if the value of the object type information is "0x11”, the object type may indicate "Self-Initializing Segment”.
- the Reserved field may be a field reserved for future use.
- 44 is a diagram illustrating a structure of a broadcast signal receiving apparatus using object type information according to another embodiment of the present invention.
- the broadcast signal receiving apparatus may perform different procedures according to the type of the object based on the object type information. That is, when the broadcast signal transmission apparatus specifies and transmits object type information in the LCT packet, the broadcast signal receiving apparatus may identify the received object based on the object type information and perform an appropriate operation according to the type of the object.
- the broadcast signal receiving apparatus may include a signaling decoder C32005, a parser C32050, and / or a decoder C32060.
- the components of the broadcast signal receiving apparatus are not limited thereto and may further include the above-described components.
- Signaling Decoder C32005 may decode signaling information.
- the signaling information is information indicating whether to transmit a broadcast signal including multimedia content in real time using a broadcast network.
- the parser C32050 may generate at least one access unit and initialization information for parsing at least one object and accessing the representation based on the object type information.
- the Parser C32050 may include an Initialization Segment Parser C32051, a Media Segment Parser C32052, and / or a Self-Initializing Segment Parser C32053.
- Initialization Segment Parser (C32051), the Media Segment Parser (C32052), and the Self-Initializing Segment Parser (C32053) will be described in the following drawings.
- Decoder C32060 may initialize the corresponding decoder C32060 based on the initialization information. Also, the decoder C32060 may decode at least one object. In this case, the decoder C32060 may receive information about the object in the form of at least one access unit, and the decoder C32060 may generate media data by decoding the at least one access unit.
- 45 is a diagram illustrating a structure of a broadcast signal receiving apparatus using object type information according to another embodiment of the present invention.
- the broadcast signal receiving apparatus may include a packet filter (C32010), a segment buffer (C32030), a parser (C32050), a decoding buffer (C32059), and / or a decoder (C32060).
- a packet filter C32010
- a segment buffer C32030
- a parser C32050
- a decoding buffer C32059
- / or a decoder C32060
- the packet filter C32010 may identify object type information from at least one received packet and classify the object type information so as to perform a procedure corresponding to each object type based on the object type information.
- the Packet Filter (C32010) delivers data of the LCT packet to the Initialization Segment Parser (C32051) through the Segment Buffer (C32031). If the object type information is "2", the Packet Filter (C32010) transmits the data of the LCT packet to the Media Segment Parser (C32052) through the Segment Buffer (C32032). If the transport object type information is "3”, the Packet Filter (C32010) sends the data of the LCT packet to the Segment Buffer (C32033). ) To the Self-Initializing Segment Parser (C32053).
- the segment buffer C32030 may receive data of the LCT packet from the packet filter and store the data for a predetermined time.
- the segment buffer C32030 may exist as one component or may exist as several segment buffers C32031, C32032, and C32033.
- the parser C32050 may generate at least one access unit and initialization information for parsing at least one object and accessing the representation based on the object type information.
- the Parser C32050 may include an Initialization Segment Parser C32051, a Media Segment Parser C32052, and / or a Self-Initializing Segment Parser C32053.
- the initialization segment parser C32051 parses an initialization segment stored in the segment buffer C32031 and may generate initialization information for accessing the representation.
- the Initialization Segment Parser C32051 may receive an Initialization Segment from the Self-Initializing Segment Parser C32053 and generate initialization information for accessing the Representation.
- the Media Segment Parser (C32052) parses the Media Segment stored in the Segment Buffer (C32032), and provides information on the media stream information, at least one Access Unit, and information on how to access the Media Presentation within the segment, such as Presentation time or Index. Can be generated.
- the Media Segment Parser (C32052) receives the Media Segment from the Self-Initializing Segment Parser (C32053), and accesses the media stream information, at least one Access Unit, and the Media Presentation in the corresponding segment, such as Presentation time or Index. Can generate information about
- the Self-Initializing Segment Parser C32053 may parse the Self-Initializing Segment stored in the Segment Buffer C32033 and generate an Initialization Segment and a Media Segment.
- Decoding Buffer C32059 may receive at least one Access Unit from Parser C32050 or Media Segment Parser C32052 and store it for a predetermined time.
- Decoder C32060 may initialize the corresponding decoder C32060 based on the initialization information. Also, the decoder C32060 may decode at least one object. In this case, the decoder C32060 may receive information about the object in the form of at least one access unit, and the decoder C32060 may generate media data by decoding the at least one access unit.
- the broadcast signal transmission apparatus when transmitting MPEG-DASH content, may transmit object type information indicating the type of the object currently being transmitted in the packet.
- the broadcast signal receiving apparatus may identify the type of the object in the received packet based on the object type information, and may perform a process appropriate for each object.
- 46 is a diagram showing the structure of a packet including type information according to another embodiment of the present invention.
- the apparatus for transmitting broadcast signals independently transmits data in units of an object internal structure, which is a meaningful unit, data may be transmitted in a variable size. Therefore, even when the broadcast signal receiving apparatus receives and identifies the object internal structure even before all of the objects are received, the broadcast signal receiving apparatus can reproduce the data in the object internal structure unit. As a result, multimedia content can be transmitted and reproduced in real time through a broadcasting network.
- type information and boundary information may be used to identify the object internal structure.
- the packet information may include type information using the LCT Header Extension.
- the type information may indicate the type of the internal structure of the object that the current packet is transmitting.
- Type information may be referred to as internal structure type information to distinguish it from object type information.
- the type information may be applied to a packet for a transport protocol such as a real time protocol (RTP).
- RTP real time protocol
- the type information may include a header extension type field (HET), an internal unit type field, and / or a reserved field.
- HET header extension type field
- the HET field is the same as described above, and a detailed description thereof will be omitted.
- the Internal Structure Type field may indicate the type of object internal structure transmitted by the LCT packet.
- the object may correspond to a segment of MPEG-DASH, and an object internal structure corresponds to a subcomponent constituting the object.
- the type of object internal structure may include a fragment, a chunk or a GOP, an access unit, and a NAL unit.
- the type of the object internal structure is not limited thereto and may further include meaningful units.
- Fragment refers to a data unit that can be independently decoded and reproduced without dependency on previous data.
- the fragment may mean a data unit including a pair of movie fragment boxes and a media data container box mdat.
- the fragment may correspond to a subsegment of MPEG-DASH and may correspond to a fragment of MMT.
- the fragment may include at least one chunk or at least one GOP.
- Chunk is a set of contiguous samples having the same media type, and is a data unit of variable size.
- the GOP is a basic unit that performs coding used in video coding, and is a data unit of variable size representing a set of frames including at least one I-frame.
- the GOP may include an open GOP and a closed GOP.
- a B-frame within one GOP may refer to an I-frame or P-frame of an adjacent GOP.
- Open GOP can significantly increase coding efficiency.
- a B-frame or a P-frame refers only to frames within that GOP, not to frames outside of that GOP.
- the access unit refers to a basic data unit of encoded video or audio and may include one image frame or audio frame.
- the NAL unit is a compressed video stream encapsulated including summary information about a compressed slice in consideration of communication with a network device.
- it may be a data unit that packetizes data such as a NAL unit slice, a parameter set, and an SEI in byte units.
- the Reserved field may be a field reserved for future use.
- boundary information for identifying the object internal structure will be described in detail.
- the packet information may include boundary information using the LCT Header Extension.
- the boundary information may indicate the boundary of the object internal structure currently transmitted by the packet.
- the boundary information may be applied to a packet for a transport protocol such as a realtime protocol (RTP).
- RTP realtime protocol
- the boundary information may include a header extension type field (HET), a start flag field (SF), a reserved field, and / or an offset field.
- HET header extension type field
- SF start flag field
- SF reserved field
- / or an offset field may be included in the boundary information.
- the HET field is the same as described above, and a detailed description thereof will be omitted.
- the Start Flag field may indicate that the LCT packet includes the start point of the object internal structure.
- the Reserved field may be a field reserved for future use.
- the offset field may include location information indicating the location of the start point of the object internal structure in the LCT packet.
- the location information may include a byte distance from the start point of the payload of the LCT packet to the start point of the object internal structure.
- the broadcast signal transmission apparatus may transmit data in units of an object internal structure having a variable length without transmitting data in units of objects based on the type information and boundary information.
- the broadcast signal receiving apparatus may receive and reproduce data in units of an object internal structure having a variable length without receiving and playing data in units of objects. Accordingly, the apparatus for receiving broadcast signals can identify the object internal structure based on the type information and the boundary information, and can reproduce the received object internal structure for each object.
- the apparatus for receiving a broadcast signal includes a type of a current object internal structure based on type information included in a packet corresponding to a start and end point of an object internal structure expressed in boundary information, or at least one packet transmitted therebetween. Can be identified.
- the broadcast signal receiving apparatus can quickly identify the object internal structure and reproduce in real time even before all the objects are received.
- FIG. 48 is a diagram showing the structure of a packet including mapping information according to another embodiment of the present invention.
- the object internal structure may be identified using mapping information.
- the packet information may include mapping information by using the LCT Header Extension.
- the mapping information is information for mapping at least one of a session, an object, and an object internal structure currently transmitted by the packet to at least one of a Transport Session Identifier (TSI) and a Transport Object Identifier (TOI).
- TSI Transport Session Identifier
- TOI Transport Object Identifier
- the mapping information may be applied to a packet for a transport protocol such as a realtime protocol (RTP).
- RTP realtime protocol
- the mapping information may include a header extension type field (HET), a header extension length field (HEL), and a uniform resource locator field (URL).
- HET header extension type field
- HEL header extension length field
- URL uniform resource locator field
- the HET field is the same as described above, and a detailed description thereof will be omitted.
- the HEL field indicates the total length of the variable length LCT header extension. Basically, in HCT, when HET has a value between 0 and 127, there is a variable length header extension in 32-bit word units. The HEL field following the HET field uses the entire length of the LCT header extension in 32-bit word units. Indicates.
- the URL field may be of variable length and may include a unique address on the Internet of the session, object, and object internal structure currently being transmitted.
- the URL field may be expressed as mapping information.
- the mapping information may indicate the URL of the signaling information.
- the mapping information may include an identifier assigned in the signaling information as well as a unique address of a session, an object, or an object internal structure.
- the identifier may include a Period ID, an Adaptation Set ID, a representation ID, and a component ID.
- the mapping information may include a segment URL, a representation ID, a component ID, an adaptation set ID, a period ID, and the like.
- the signaling information may further include mapping information for mapping the identifier or URL of the object to TOI or TSI, respectively. That is, the signaling information may further include information indicating whether the TOI and the TSI currently being transmitted are mapped among the identifier or the URL of the object.
- the mapping information may be information for mapping the URL of the identifier or the object and TOI or TSI to one of 1: 1, 1: ⁇ , and ⁇ : 1.
- 49 is a diagram showing the structure of an LCT packet including grouping information according to another embodiment of the present invention.
- the object internal structure may be identified using grouping information.
- the LCT packet according to another embodiment of the present invention may include a Session Group Identifier field (SGI) and a Divided Transport Session Identifier field (DTSI).
- SGI and DTSI are a form of the existing Transport Session Identifier field (TSI).
- the LCT packet according to another embodiment of the present invention may include an Object Group Identifier field (OGI) and a Divided Transport Object Identifier field (DTOI).
- OGI and DTOI are obtained by splitting an existing Transport Object Identifier field (TOI).
- the S field indicates the length of the existing TSI field
- the O field indicates the length of the existing TOI
- the H field indicates whether to add half-word (16 bits) to the length of the existing TSI field and the existing TOI field. Indicate whether or not.
- the sum of the lengths of the SGI field and the DTSI field is the same as the existing TSI field, and may be determined based on the values of the S field and the H field.
- the sum of the lengths of the OGI field and the DTOI field is the same as the existing TOI field, and may be determined based on the values of the O field and the H field.
- the existing TSI and TOI are subdivided into SGI, DTSI, OGI, and DTOI, and the SGI, DTSI, OGI, and DTOI may identify different data units, respectively.
- 50 is a diagram illustrating grouping of a session and an object according to another embodiment of the present invention.
- MPD Media Presentation Description
- MPD Media Presentation Description
- the MPD C40000 may include at least one period.
- the MPD C40000 may include a first period C41000 and a second period C42000.
- Period is an element in which MPEG-DASH content is divided into playback times. Available bitrates, languages, captions, subtitles, and the like do not change within Period.
- Each Period may include start time information and may be arranged in ascending order of start time within the MPD.
- the first period C41000 is an element in a section of 0 to 30 min
- the second period C42000 is an element in a section of 30 to 60 min.
- the period may include at least one AdaptationSet (not shown) as a lower element.
- AdaptationSet is a set of interchangeable encoded versions of at least one media content component.
- AdaptationSet may include at least one representation as a lower element.
- the AdaptationSet may include a first Representation C41100, a second Representation C41200, and a third Representation C41300.
- Representation represents an element of a transportable encoded version of at least one media content component and may include at least one media stream.
- the media content component can include a video component, an audio component, and a caption component.
- Representation may include information about the quality of the media content component. Accordingly, the broadcast signal reception apparatus may change the representation in one AdaptationSet to adapt to the network environment.
- the first Representation C41100 is a video component having a bandwidth of 500 kbit / s
- the second Representation C41200 is a video component having a bandwidth of 250 kbit / s
- a third Representation C41300 may be a video component having a bandwidth of 750 kbit / s.
- Representation may include at least one segment as a lower element.
- the first representation C41100 may include a first segment C41110, a second segment C41120, and a third segment C41130.
- Segment represents the element of the largest data unit that can be retrieved in one HTTP request.
- the URL may be provided to each segment.
- the above-described object is a concept corresponding to a file, an initialization segment, a media segment, or a self-initializing segment, and may correspond to a segment of MPEG-DASH and may correspond to an MPU of an MMT.
- Each segment may include at least one fragment as a lower element.
- the second segment C41120 may include a first fragment C41122, a second fragment C41124, and a third fragment C41126.
- Fragment refers to a data unit that can be independently decoded and reproduced without dependency on previous data.
- the fragment may correspond to a subsegment of MPEG-DASH and a fragment of MMT.
- the fragment may include at least one chunk or at least one GOP.
- the first fragment C41122 may include a fragment header and a fragment payload.
- the fragment header may include a segment index box (sidx) and a movie fragment box (moof).
- the fragment payload may include a media data container box (mdat).
- the media data container box mdat may include first to fifth chunks.
- Chunk is a set of contiguous samples having the same media type, and is a data unit of variable size.
- the TSI identifies a transport session, and each representation may be mapped to each TSI.
- the TOI identifies a transport object within a transport session, and each segment can be mapped to each TOI.
- each GSI, DTSI, GOI, and DTOI may be mapped to a new data unit, respectively. It is not limited to the Example of.
- SGIs identify groups of the same transport session, and each Period can be mapped to each SGI.
- the value of the SGI may be mapped to "1”
- the value of the SGI may be mapped to "2”.
- the value of the SGI is not limited to the above-described embodiment and may have the same value as Period ID, which is a value for identifying Period.
- DTSI identifies a transport session, and each representation can be mapped to each DTSI.
- the value of DTSI is mapped to “1”
- the value of DTSI is mapped to “2”
- the value of DTSI is “3”. Can be mapped to.
- the value of the DTSI is not limited to the above-described embodiment and may have the same value as the Representation ID which is a value for identifying the representation.
- OGI identifies the same group of objects within a transport session, and each segment can be mapped to each OGI.
- the value of OGI is mapped to “1”
- the value of OGI is mapped to “2”
- the value of OGI is “3”. May be mapped to ”.
- the DTOI may identify a delivery object.
- One delivery object may be part of one ISO BMFF file or one ISO BMFF file.
- Part of one ISO BMFF file may include a fragment, a GOP, a chunk, an access unit, and / or a NAL unit.
- the fragment header, and each chunk or each GOP of the fragment payload may be mapped to each DTOI.
- the header of the first fragment C41122 has a value of DTOI mapped to “0”, and the first to fifth chunks in the payload of the first fragment C41122 have a value of “10” to “14” in the DTOI. Can be mapped to.
- the usage can be defined according to the values given.
- the DTOI value may be set to an ascending or descending value according to the arrangement order of the objects.
- the apparatus for receiving broadcast signals may rearrange objects and generate fragments or segments based on the DTOI value.
- the value of a specific DTOI may indicate a fragment header.
- the broadcast signal transmitting apparatus or the broadcast signal receiving apparatus may determine whether transmission of the fragment header is completed based on the value of the corresponding DTOI.
- the group of delivery objects may correspond to a content component such as DASH Representation.
- DTOI may be mapped to Segment and OGI may be mapped to Representation.
- OGI may be mapped one-to-one to a representation ID, content component ID, and the like, and may be used as information for multiplexing / demultiplexing content components transmitted in one session.
- 51 is a diagram illustrating a structure of a broadcast signal transmission apparatus using packet information according to another embodiment of the present invention.
- the broadcast signal transmission apparatus may include a signaling encoder C31005, an internal structure generator C31030, a packet information generator C31035, and / or a transmitter C31050.
- the signaling encoder C31005 may generate signaling information indicating whether to transmit a broadcast signal including multimedia content in real time using a broadcast network.
- the signaling information may indicate transmission of multimedia content in real time at least at one of a file level and an FDT level. If the signaling information indicates to transmit the multimedia content at the file level in real time, all data belonging to the file may be transmitted in real time. In addition, if the signaling information indicates to transmit the multimedia content at the FDT level in real time, all files or data belonging to the FDT may be transmitted in real time.
- the internal structure generator C31030 may generate at least one object internal structure that is a data unit that is independently encoded and decoded.
- the object internal structure is obtained by dividing a file constituting the multimedia content into at least one data unit.
- the packet information generator C31035 may generate packet information including metadata identifying the object internal structure.
- the packet information may include metadata regarding a packet for transmitting multimedia content and may include metadata for identifying an object internal structure.
- the packet information may include boundary information indicating the boundary of the object internal structure and type information indicating the type of the object internal structure.
- the boundary information may include a Start Flag (SF) field indicating whether the packet includes the start point of the object internal structure, and an Offset field indicating the position of the start point of the object internal structure in the packet. .
- SF Start Flag
- the type of the object internal structure is a fragment representing a data unit comprising a pair of movie fragment boxes (moof) and a media data container box (mdat), a chunk representing a set of adjacent samples having the same media type, and at least one I. It may include one of a GOP indicating a set of frames including a frame, an access unit indicating a basic data unit of encoded video or audio, and a NAL unit indicating a data unit packetized in bytes.
- the packet information may include mapping information for mapping at least one of a session, an object, and an object internal structure to at least one of a Transport Session Identifier (TSI) and a Transport Object Identifier (TOI).
- TSI Transport Session Identifier
- TOI Transport Object Identifier
- the packet information may include a transport object transmitted by the packet and grouping information that groups the transport session.
- the grouping information includes a Divided Transport Session Identifier (DTSI) field that identifies a transport session, a Session Group Identifier (SGI) field that identifies a group of the same transport session, a Divided Transport Object Identifier (DTOI) field that identifies a transport object, and the same transport. It may include an Object Group Identifier (OGI) field that identifies a group of objects.
- DTSI Divided Transport Session Identifier
- SGI Session Group Identifier
- DTOI Divided Transport Object Identifier
- the SGI field includes information for identifying a Period element of MPEG-DASH
- the DTSI field includes information for identifying a Representation element of MPEG-DASH
- the OGI field includes information for identifying a Segment element of MPEG-DASH.
- the DTOI field may include information identifying a Chunk element of MPEG-DASH.
- the packet information may identify at least one of a session, an object, and an object internal structure based on the type information, boundary information, mapping information, and grouping information.
- the apparatus for transmitting broadcast signals may further include a packetizer (not shown).
- the packetizer may divide the object internal structure into at least one symbol having the same size and packetize each of the at least one symbol into at least one packet.
- the present invention is not limited thereto, and the symbol may be generated by another device.
- the length of a symbol according to another embodiment of the present invention may be the same.
- the Packetizer may then packetize at least one symbol into at least one packet.
- the packet may be an LCT packet.
- the packet may include a packet header and a packet payload.
- the packet header may include packet information that identifies the object internal structure.
- the transmitter C31050 may transmit a broadcast signal including an object internal structure and packet information.
- FIG. 52 is a diagram illustrating a structure of a broadcast signal receiving apparatus using packet information according to another embodiment of the present invention.
- the broadcast signal receiving apparatus may identify an object internal structure based on packet information and decode the received object internal structure. Therefore, even if the broadcast signal receiving apparatus receives only the object internal structure without receiving all of one object, the broadcast signal receiving apparatus can reproduce the object internal structure.
- the broadcast signal receiving apparatus may include a signaling decoder C32005, an extractor C32050, and / or a decoder C32060.
- the broadcast signal receiving apparatus may further include the above-described component.
- Signaling Decoder C32005 may decode signaling information.
- the signaling information is information indicating whether to transmit a broadcast signal including multimedia content in real time using a broadcast network.
- the extractor C32050 may identify the object internal structure from the broadcast signal and extract the object internal structure.
- the extractor C32050 may extract the object internal structure and deliver it to the decoder C32060 even before all of the objects are received based on the packet information.
- the operation of the extractor C32050 may vary depending on the type of the internal structure of the object.
- the above-described Parser C32050 may perform the same operation as the Extractor C32050, or may represent the Extractor C32050 as a Parser C32050.
- the extractor C32050 may identify the type of the current object internal structure based on the type information and the boundary information. For example, the Extractor C32050 may determine the type of the current object internal structure based on the type information included in the packet corresponding to the start and end points of the object internal structure expressed in the boundary information or at least one packet transmitted therebetween. Can be identified.
- the extractor C32050 may extract at least one of a fragment, a chunk or a GOP, and an access unit, which is an object internal structure stored in the object buffer or the segment buffer. To this end, the extractor C32050 may further include an AU Extractor C32056 for extracting an Access Unit, a Chunk Extractor C32057 for extracting Chunks or GOPs, and a Fragment Extractor C32058 for extracting fragments. Subcomponents of the Extractor C32050 will be described in detail in the following drawings.
- the decoder C32060 may receive the object internal structure and decode the corresponding object internal structure based on the type information. In this case, the decoder C32060 may receive information on the object internal structure in the form of at least one access unit, and generate media data by decoding the at least one access unit.
- 53 is a diagram illustrating a structure of a broadcast signal receiving apparatus using packet information according to another embodiment of the present invention.
- the apparatus for receiving broadcast signals may further include a packet depacketizer C22020, a segment buffer C32030, an AU extractor C32056, a decoding buffer C32059, and / or a decoder C32060.
- the packet depacketizer C22020 may depacketize at least one packet and extract packet information included in a packet header.
- the packet depacketizer C22020 may extract type information and boundary information included in the packet header, and may extract at least one symbol included in the packet payload.
- the at least one symbol may be a symbol constituting an object internal structure or a symbol constituting an object.
- the packet depacketizer C22020 may deliver the extracted at least one object or at least one object internal structure to the decoder C32060.
- the segment buffer C32030 may receive data of the LCT packet from the packet depacketizer C22020 and store the data for a predetermined time.
- the segment buffer C32030 may be expressed as an object buffer C32030.
- the segment buffer C32030 may further include an AU Extractor C32056, a Chunk Extractor (not shown), and / or a Fragment Extractor (not shown).
- the segment buffer C320300 may further include a fragment buffer (not shown) and / or a chunk buffer (not shown).
- the segment buffer C32030 may include an AU extractor C32056.
- the present invention is not limited thereto, and the AU extractor C32056 may exist independently of the segment buffer C32030.
- the AU Extractor C32056 may extract an Access Unit stored in the Segment Buffer C32030 based on the boundary information. For example, one access unit may be from the start point of the access unit indicated by the boundary information to before the start point of the next access unit.
- the AU Extractor C32056 may deliver the extracted Access Unit to the Decoder C32060 via the Decoding Buffer C32059.
- the AU Extractor C32056 extracts the object internal structure as soon as reception of the internal structure of the object is completed based on the type information and boundary information. It can be delivered to the decoder C32060.
- the decoding buffer C32059 may receive data from the segment buffer C32030 and store the data for a predetermined time.
- the access unit may be delivered to the decoder C32060 or another component at the processing time given to the access unit in the decoding buffer C32059.
- timing information on a processing time such as a presentation time stamp (PTS) may be provided to the access unit in the form of an LCT header extension.
- PTS presentation time stamp
- the decoder C32060 may receive the object internal structure and decode the corresponding object internal structure based on the type information. In this case, the decoder C32060 may receive the object internal structure in the form of an access unit as well as the object internal structure.
- the decoder C32060 may decode the corresponding access unit that is the internal structure of the object even before all the objects are received.
- FIG. 54 is a diagram illustrating a structure of a broadcast signal receiving apparatus using packet information according to another embodiment of the present invention.
- the broadcast signal receiving apparatus may further include a packet depacketizer C22020, a segment buffer C32030, a chunk buffer C32035, a decoding buffer C32059, and / or a decoder C32060.
- the packet depacketizer C22020 may deliver the extracted at least one object or at least one object internal structure to the decoder C32060 through the segment buffer C32030.
- the segment buffer C32030 may include a chunk extractor C32057. In addition, the segment buffer C32030 may further include a chunk buffer C32035.
- the chunk extractor C32057 may extract the chunk or GOP stored in the segment buffer C32030 based on the boundary information. For example, one chunk or GOP may be from the start point of the chunk or GOP indicated by the boundary information before the start point of the next chunk or GOP.
- the Chunk Extractor C32057 may exist in the Segment Buffer C32030 or may exist independently.
- the Chunk Buffer C32035 may receive at least one chunk or GOP and store the chunk or GOP for a predetermined time.
- the Chunk Buffer C32035 may exist in the Segment Buffer C32030 or may exist independently.
- Chunk Buffer C32035 may further include an AU Extractor C32056.
- the AU Extractor C32056 may extract at least one Access Unit from a chunk or a GOP stored in the Chunk Buffer C32035. Thereafter, the extracted at least one access unit may be delivered to the decoder C32060 via a decoding buffer C32059.
- the decoder C32060 may decode the corresponding Chunk or GOP that is the internal structure of the object even before all the objects are received.
- 55 is a diagram illustrating a structure of a broadcast signal receiving apparatus using packet information according to another embodiment of the present invention.
- the broadcast signal receiving apparatus includes a packet depacketizer (C22020), a segment buffer (C32030), a fragment buffer (C32036), an audio decoding buffer (C32059-1), a video decoding buffer (C32059-2), an audio decoder (C32060-1), and And / or may further include a video decoder C32060-2.
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
Claims (14)
- 서비스의 적어도 하나의 콘텐트 컴포넌트에 포함되며, 독립적으로 복원되는(recovered individually) 적어도 하나의 딜리버리 오브젝트를 생성하는 딜리버리 오브젝트 제너레이터(Delivery Object Generator);상기 서비스 및 상기 적어도 하나의 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 생성하는 시그널링 인코더(Signaling Encoder),상기 시그널링 정보는 상기 서비스의 상기 적어도 하나의 콘텐트 컴포넌트를 전송하는 전송 세션 및 상기 전송 세션을 통해 전송되는 적어도 하나의 딜리버리 오브젝트에 관한 제1 정보를 포함하고; 및상기 적어도 하나의 딜리버리 오브젝트 및 상기 시그널링 정보를 단방향 채널(unidirectional channel)을 통해서 전송하는 트랜스미터(Transmitter)를포함하는 방송 신호 송신 장치.
- 제 1 항에 있어서,상기 딜리버리 오브젝트는 파일, 상기 파일의 일부(a part of the file), 상기 파일의 그룹(a group of the file), Hyper Text Transfer Protocol(HTTP) Entity, 및 상기 HTTP Entity의 그룹 중에서 하나인 방송 신호 송신 장치.
- 제 1 항에 있어서,상기 시그널링 정보는 상기 서비스에 해당하는 DASH Media Presentation의 디스크립션을 포함하는 제2 정보를 더 포함하는 방송 신호 송신 장치.
- 제 1 항에 있어서,상기 시그널링 정보는 상기 딜리버리 오브젝트를 전송하는 전송 프로토콜 패킷의 페이로드의 첫번째 바이트의 위치를 지시하는 오프셋 정보를 더 포함하는 방송 신호 송신 장치.
- 제 1 항에 있어서,상기 시그널링 정보는 상기 적어도 하나의 딜리버리 오브젝트가 스트리밍 서비스를 전송하는지 여부를 지시하는 실시간 정보를 더 포함하는 방송 신호 송신 장치.
- 제 1 항에 있어서,상기 시그널링 정보는 상기 전송 세션을 Transport Session Identifier(TSI)에 매핑시키고, 상기 딜리버리 오브젝트를 Transport Object Identifier(TOI)에 매핑시키는 매핑 정보를 더 포함하는 방송 신호 송신 장치.
- 제 1 항에 있어서,상기 시그널링 정보는 상기 딜리버리 오브젝트에 대한 시간 정보를 지시하는 타임스탬프 정보를 더 포함하는 방송 신호 송신 장치.
- 서비스의 적어도 하나의 콘텐트 컴포넌트의 발견 및 획득을 제공하는 시그널링 정보를 추출하는 시그널링 디코더(Signaling Decoder),,상기 시그널링 정보는 상기 서비스의 상기 적어도 하나의 콘텐트 컴포넌트를 전송하는 전송 세션 및 상기 전송 세션을 통해 전송되는 적어도 하나의 딜리버리 오브젝트에 관한 제1 정보를 포함하고;상기 딜리버리 오브젝트는 상기 서비스의 적어도 하나의 콘텐트 컴포넌트에 포함되며, 독립적으로 복원되고(recovered individually);상기 적어도 하나의 딜리버리 오브젝트를 복원하는 딜리버리 오브젝트 프로세서(Delivery Object Processor); 및상기 적어도 하나의 딜리버리 오브젝트를 디코딩하는 미디어 디코더(Media Decoder)를포함하는 방송 신호 수신 장치.
- 제 8 항에 있어서,상기 제1 정보는 상기 딜리버리 오브젝트를 전송하는 전송 프로토콜 패킷의 페이로드의 첫번째 바이트의 위치를 지시하는 오프셋 정보, 상기 적어도 하나의 딜리버리 오브젝트가 스트리밍 서비스를 전송하는지 여부를 지시하는 실시간 정보, 상기 전송 세션을 Transport Session Identifier(TSI)에 매핑시키고 상기 딜리버리 오브젝트를 Transport Object Identifier(TOI)에 매핑시키는 매핑 정보, 상기 딜리버리 오브젝트에 대한 시간 정보를 지시하는 타임스탬프 정보 중에서 적어도 하나를 더 포함하는 방송 신호 수신 장치.
- 제 9 항에 있어서,상기 시그널링 정보는 상기 서비스에 해당하는 DASH Media Presentation의 디스크립션을 포함하는 제2 정보를 더 포함하는 방송 신호 수신 장치.
- 제 10 항에 있어서,상기 딜리버리 오브젝트 프로세서는상기 전송 프로토콜 패킷을 파싱하여 적어도 하나의 딜리버리 오브젝트를 복원하는 전송 프로토콜 클라이언트; 및상기 딜리버리 오브젝트를 버퍼링하고, 상기 딜리버리 오브젝트를 상기 미디어 디코더로 전달하는 버퍼/제어부를 더 포함하는 방송 신호 수신 장치.
- 제 10 항에 있어서,상기 딜리버리 오브젝트 프로세서는상기 전송 프로토콜 패킷을 파싱하여 적어도 하나의 딜리버리 오브젝트를 복원하는 전송 프로토콜 클라이언트;상기 딜리버리 오브젝트 및 상기 시그널링 정보를 기초로 적어도 하나의 HTTP Entity를 생성하는 HTTP Entity 제너레이터,상기 HTTP Entity는 HTTP Entity header, 및 상기 적어도 하나의 딜리버리 오브젝트를 포함하는 HTTP Entity body를 포함하고;상기 적어도 하나의 HTTP Entity를 저장하는 인터널 HTTP 서버; 및상기 제2 정보를 기초로 상기 인터널 HTTP 서버에 상기 적어도 하나의 딜리버리 오브젝트를 요청하고, 상기 딜리버리 오브젝트를 상기 미디어 디코더로 전달하는 DASH 클라이언트를 더 포함하는 방송 신호 수신 장치.
- 제 12 항에 있어서상기 HTTP Entity header는 HTTP Entity body의 크기를 지시하는 Content-Length field, 상기 HTTP Entity에 대한 리소스 주소를 포함하는 Content-Location field, 완전한 HTTP Entity body(full HTTP Entity-payload) 내에서 부분 HTTP Entity body(partial HTTP Entity-payload)의 위치를 지시하는 Content-Range field, 유효한 요청을 받을 수 있는 날짜/시간 정보를 지시하는 Expires field 중에서 적어도 하나를 포함하는 방송 신호 수신 장치.
- 제 9 항에 있어서,상기 딜리버리 오브젝트 프로세서는상기 서비스를 전송하는 적어도 하나의 패킷을 파싱하여 HTTP Entity를 복원하는 패킷 클라이언트;상기 서비스에 해당하는 DASH Media Presentation의 디스크립션을 포함하는 제2 정보를 기초로 상기 HTTP Entity를 적어도 하나의 전송 프로토콜 패킷으로 변환하는 전송 프로토콜 컨버터;상기 전송 프로토콜 패킷을 파싱하여 적어도 하나의 딜리버리 오브젝트를 복원하는 전송 프로토콜 클라이언트; 및상기 딜리버리 오브젝트를 버퍼링하고, 상기 딜리버리 오브젝트를 상기 미디어 디코더로 전달하는 버퍼/제어부를 더 포함하는 방송 신호 수신 장치.
Priority Applications (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201580008182.XA CN106134203A (zh) | 2014-04-30 | 2015-04-28 | 广播信号发送装置、广播信号接收装置、广播信号发送方法、和广播信号接收方法 |
KR1020167013134A KR101868628B1 (ko) | 2014-04-30 | 2015-04-28 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
CA2933608A CA2933608C (en) | 2014-04-30 | 2015-04-28 | Broadcast signal transmitting device, broadcast signal receiving device, broadcast signal transmitting method, and broadcast signal receiving method |
EP15785588.3A EP3073744A4 (en) | 2014-04-30 | 2015-04-28 | Broadcast signal transmitting device, broadcast signal receiving device, broadcast signal transmitting method, and broadcast signal receiving method |
US15/038,990 US20170171606A1 (en) | 2014-04-30 | 2015-04-28 | Broadcast signal transmitting device, broadcast signal receiving device, broadcast signal transmitting method, and broadcast signal receiving method |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201461986114P | 2014-04-30 | 2014-04-30 | |
US61/986,114 | 2014-04-30 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2015167200A1 true WO2015167200A1 (ko) | 2015-11-05 |
Family
ID=54358859
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/KR2015/004217 WO2015167200A1 (ko) | 2014-04-30 | 2015-04-28 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
Country Status (6)
Country | Link |
---|---|
US (1) | US20170171606A1 (ko) |
EP (1) | EP3073744A4 (ko) |
KR (1) | KR101868628B1 (ko) |
CN (1) | CN106134203A (ko) |
CA (1) | CA2933608C (ko) |
WO (1) | WO2015167200A1 (ko) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110476403A (zh) * | 2017-09-29 | 2019-11-19 | Lg电子株式会社 | V2x通信设备及由其发送/接收多媒体内容的方法 |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20160004858A (ko) * | 2014-07-04 | 2016-01-13 | 삼성전자주식회사 | 멀티미디어 통신 시스템에서 패킷 송/수신 장치 및 방법 |
CA2998129A1 (en) * | 2015-09-18 | 2017-03-23 | Sony Corporation | Transmission apparatus, reception apparatus, and data processing method |
US10146625B2 (en) * | 2015-10-28 | 2018-12-04 | Dell Products L.P. | Systems and methods for intelligent data manager for offloading of bulk data transfers |
US10367874B2 (en) * | 2016-11-04 | 2019-07-30 | Verizon Patent And Licensing Inc. | MPEG-DASH delivery over multicast |
EP3625945B1 (en) * | 2017-06-09 | 2021-09-15 | Huawei Technologies Co., Ltd. | Transmitter communication device and method for transmitting video data |
CN110121209B (zh) * | 2018-02-05 | 2023-04-07 | 北京佰才邦技术股份有限公司 | 一种导频信息的传输方法、网络设备及终端 |
KR102211539B1 (ko) * | 2018-12-11 | 2021-02-03 | 주식회사 디에스브로드캐스트 | 버퍼모델을 따르는 스트리밍을 위한 부가 정보 생성 방법 및 장치 |
US11582125B2 (en) * | 2019-10-01 | 2023-02-14 | Qualcomm Incorporated | Repair mechanism for adaptive bit rate multicast |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009151267A2 (ko) * | 2008-06-09 | 2009-12-17 | 엘지전자(주) | 서비스 제공 방법 및 방송 수신기 |
KR20110094076A (ko) * | 2008-11-18 | 2011-08-19 | 엘지전자 주식회사 | 방송 신호를 수신하는 방법 |
KR20110123658A (ko) * | 2010-05-07 | 2011-11-15 | 한국전자통신연구원 | 3차원 방송 서비스 송수신 방법 및 시스템 |
WO2012121572A2 (ko) * | 2011-03-10 | 2012-09-13 | 한국전자통신연구원 | 프로그램 연동형 스테레오스코픽 방송 서비스를 제공하기 위한 송신 장치 및 방법, 및 수신 장치 및 방법 |
KR20140016906A (ko) * | 2011-05-24 | 2014-02-10 | 엘지전자 주식회사 | 방송 서비스 전송 방법, 그 수신 장치 및 그 수신 장치의 부가 서비스 처리 방법 |
Family Cites Families (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7305696B2 (en) * | 2000-04-17 | 2007-12-04 | Triveni Digital, Inc. | Three part architecture for digital television data broadcasting |
CA2459381A1 (en) * | 2001-09-06 | 2003-03-20 | Airia Inc. | Method and system for providing an audio/video in-route entertainment system |
US20030097661A1 (en) * | 2001-11-16 | 2003-05-22 | Li Hua Harry | Time-shifted television over IP network system |
US7716662B2 (en) * | 2005-06-22 | 2010-05-11 | Comcast Cable Holdings, Llc | System and method for generating a set top box code download step sequence |
US20070250636A1 (en) * | 2006-04-25 | 2007-10-25 | Sean Stephens | Global interactive packet network broadcast station |
US20080059648A1 (en) * | 2006-09-01 | 2008-03-06 | Freedom Broadcast Network, Llc | Dynamically Configurable Processing System |
US8010990B2 (en) * | 2006-10-26 | 2011-08-30 | Intel Corporation | Acceleration of packet flow classification in a virtualized system |
KR100848273B1 (ko) * | 2007-07-03 | 2008-07-25 | 삼성전자주식회사 | 디지털 방송수신기의 파일 처리 장치 및 방법 |
KR101556129B1 (ko) * | 2007-08-24 | 2015-09-30 | 엘지전자 주식회사 | 디지털 방송 송/수신 시스템 및 데이터 처리 방법 |
US9219951B2 (en) * | 2007-10-12 | 2015-12-22 | Analog Devices, Inc. | Mobile TV system architecture for mobile terminals |
US20090119594A1 (en) * | 2007-10-29 | 2009-05-07 | Nokia Corporation | Fast and editing-friendly sample association method for multimedia file formats |
US20100262711A1 (en) * | 2009-04-09 | 2010-10-14 | Nokia Corporation | Systems, methods, and apparatuses for media file streaming |
US9015564B2 (en) * | 2009-08-19 | 2015-04-21 | Qualcomm Incorporated | Content delivery system with allocation of source data and repair data among HTTP servers |
EP2614653A4 (en) * | 2010-09-10 | 2015-04-15 | Nokia Corp | METHOD AND APPARATUS FOR ADAPTIVE CONTINUOUS DIFFUSION |
CN105120370A (zh) * | 2010-12-03 | 2015-12-02 | Lg电子株式会社 | 3d广播接收器和用于接收3d广播信号的方法 |
WO2012141762A1 (en) * | 2011-02-25 | 2012-10-18 | Telecommunication Systems, Inc. | Mobile internet protocol (ip) location |
US9723362B2 (en) * | 2011-06-07 | 2017-08-01 | Lg Electronics Inc. | Method for transmitting and receiving broadcast service and receiving device thereof |
US9191454B2 (en) * | 2011-06-27 | 2015-11-17 | Microsoft Technology Licensing, Llc | Host enabled management channel |
KR101591238B1 (ko) * | 2011-11-01 | 2016-02-18 | 퀄컴 인코포레이티드 | Http 서버들 사이의 소스 데이터 및 리페어 데이터의 할당에 의한 컨텐츠 전달 시스템 |
JP2015503281A (ja) * | 2011-11-23 | 2015-01-29 | エレクトロニクス アンド テレコミュニケーションズ リサーチ インスチチュートElectronics And Telecommunications Research Institute | スケーラビリティ及びビュー情報を提供するストリーミングサービスのための方法及び装置 |
US20130182643A1 (en) * | 2012-01-16 | 2013-07-18 | Qualcomm Incorporated | Method and system for transitions of broadcast dash service receptions between unicast and broadcast |
US9900166B2 (en) * | 2013-04-12 | 2018-02-20 | Qualcomm Incorporated | Methods for delivery of flows of objects over broadcast/multicast enabled networks |
US9674251B2 (en) * | 2013-06-17 | 2017-06-06 | Qualcomm Incorporated | Mediating content delivery via one or more services |
-
2015
- 2015-04-28 KR KR1020167013134A patent/KR101868628B1/ko active IP Right Grant
- 2015-04-28 CA CA2933608A patent/CA2933608C/en active Active
- 2015-04-28 US US15/038,990 patent/US20170171606A1/en not_active Abandoned
- 2015-04-28 WO PCT/KR2015/004217 patent/WO2015167200A1/ko active Application Filing
- 2015-04-28 EP EP15785588.3A patent/EP3073744A4/en not_active Ceased
- 2015-04-28 CN CN201580008182.XA patent/CN106134203A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009151267A2 (ko) * | 2008-06-09 | 2009-12-17 | 엘지전자(주) | 서비스 제공 방법 및 방송 수신기 |
KR20110094076A (ko) * | 2008-11-18 | 2011-08-19 | 엘지전자 주식회사 | 방송 신호를 수신하는 방법 |
KR20110123658A (ko) * | 2010-05-07 | 2011-11-15 | 한국전자통신연구원 | 3차원 방송 서비스 송수신 방법 및 시스템 |
WO2012121572A2 (ko) * | 2011-03-10 | 2012-09-13 | 한국전자통신연구원 | 프로그램 연동형 스테레오스코픽 방송 서비스를 제공하기 위한 송신 장치 및 방법, 및 수신 장치 및 방법 |
KR20140016906A (ko) * | 2011-05-24 | 2014-02-10 | 엘지전자 주식회사 | 방송 서비스 전송 방법, 그 수신 장치 및 그 수신 장치의 부가 서비스 처리 방법 |
Non-Patent Citations (1)
Title |
---|
See also references of EP3073744A4 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110476403A (zh) * | 2017-09-29 | 2019-11-19 | Lg电子株式会社 | V2x通信设备及由其发送/接收多媒体内容的方法 |
CN110476403B (zh) * | 2017-09-29 | 2023-02-17 | Lg电子株式会社 | V2x通信设备及由其发送/接收多媒体内容的方法 |
Also Published As
Publication number | Publication date |
---|---|
CN106134203A (zh) | 2016-11-16 |
EP3073744A1 (en) | 2016-09-28 |
EP3073744A4 (en) | 2017-04-19 |
KR101868628B1 (ko) | 2018-06-18 |
KR20160078996A (ko) | 2016-07-05 |
US20170171606A1 (en) | 2017-06-15 |
CA2933608C (en) | 2018-09-11 |
CA2933608A1 (en) | 2015-11-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2015160137A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2016105090A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2016105100A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2015167200A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2016080803A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2015102381A1 (en) | Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals | |
WO2016093537A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2015178603A1 (ko) | 방송 전송 장치, 방송 전송 장치의 동작 방법. 방송 수신 장치 및 방송 수신 장치의 동작 방법 | |
WO2015126223A1 (en) | Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals | |
WO2016076623A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2016076654A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2016060422A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2016144072A1 (ko) | 방송 신호 송수신 장치 및 방법 | |
WO2016076569A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2015178690A1 (ko) | 방송 신호 송/수신 처리 방법 및 장치 | |
WO2016140486A1 (ko) | 방송 신호 송수신 장치 및 방법 | |
WO2016028119A1 (ko) | 방송 신호 송신 방법, 방송 신호 송신 장치, 방송 신호 수신 방법 및 방송 신호 수신 장치 | |
WO2016111526A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2015105391A1 (en) | Apparatuses and methods for transmitting or receiving a broadcast content via one or more networks | |
WO2016093576A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2016117939A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2016126116A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2016080721A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2016064151A1 (ko) | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 | |
WO2016144118A1 (ko) | 방송 신호 송수신 장치 및 방법 |
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: 15785588 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 20167013134 Country of ref document: KR Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 15038990 Country of ref document: US |
|
ENP | Entry into the national phase |
Ref document number: 2933608 Country of ref document: CA |
|
REEP | Request for entry into the european phase |
Ref document number: 2015785588 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2015785588 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |