WO2016111563A1 - 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치 - Google Patents
통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치 Download PDFInfo
- Publication number
- WO2016111563A1 WO2016111563A1 PCT/KR2016/000141 KR2016000141W WO2016111563A1 WO 2016111563 A1 WO2016111563 A1 WO 2016111563A1 KR 2016000141 W KR2016000141 W KR 2016000141W WO 2016111563 A1 WO2016111563 A1 WO 2016111563A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- packet
- media
- information
- data
- mpd
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 76
- 238000004891 communication Methods 0.000 title claims abstract description 42
- 230000006854 communication Effects 0.000 title claims abstract description 42
- 239000000872 buffer Substances 0.000 claims description 75
- 230000005540 biological transmission Effects 0.000 claims description 67
- 230000011664 signaling Effects 0.000 claims description 47
- 239000012634 fragment Substances 0.000 claims description 21
- 238000012546 transfer Methods 0.000 claims description 8
- 238000013507 mapping Methods 0.000 claims description 7
- 238000012545 processing Methods 0.000 description 11
- 238000010586 diagram Methods 0.000 description 10
- 230000003139 buffering effect Effects 0.000 description 9
- 238000010295 mobile communication Methods 0.000 description 9
- 230000008569 process Effects 0.000 description 9
- AWSBQWZZLBPUQH-UHFFFAOYSA-N mdat Chemical compound C1=C2CC(N)CCC2=CC2=C1OCO2 AWSBQWZZLBPUQH-UHFFFAOYSA-N 0.000 description 8
- 239000000284 extract Substances 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 238000004458 analytical method Methods 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 5
- 238000012986 modification Methods 0.000 description 4
- 230000004048 modification Effects 0.000 description 4
- 230000008439 repair process Effects 0.000 description 4
- 238000002591 computed tomography Methods 0.000 description 3
- 230000014509 gene expression Effects 0.000 description 3
- 239000012092 media component Substances 0.000 description 3
- 230000003044 adaptive effect Effects 0.000 description 2
- 230000007175 bidirectional communication Effects 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 238000000354 decomposition reaction Methods 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- SUTJFACQYOCLNG-UHFFFAOYSA-N methyl 6-[[2-[9a-[2-[(2-methoxycarbonyl-3,3-dimethyl-7-oxo-4-thia-1-azabicyclo[3.2.0]heptan-6-yl)amino]-2-oxoethyl]-7-oxo-5a,6-dihydrodibenzofuran-3-yl]acetyl]amino]-3,3-dimethyl-7-oxo-4-thia-1-azabicyclo[3.2.0]heptane-2-carboxylate Chemical compound C1=C2OC3CC(=O)C=CC3(CC(=O)NC3C(N4C(C(C)(C)SC43)C(=O)OC)=O)C2=CC=C1CC(=O)NC(C1=O)C2N1C(C(=O)OC)C(C)(C)S2 SUTJFACQYOCLNG-UHFFFAOYSA-N 0.000 description 2
- 229920002776 polycyclohexyl methacrylate Polymers 0.000 description 2
- 230000000750 progressive effect Effects 0.000 description 2
- 230000008929 regeneration Effects 0.000 description 2
- 238000011069 regeneration method Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000002730 additional effect Effects 0.000 description 1
- 238000002583 angiography Methods 0.000 description 1
- 230000000593 degrading effect Effects 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- -1 electricity Substances 0.000 description 1
- 230000010006 flight Effects 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 238000003384 imaging method Methods 0.000 description 1
- 238000007689 inspection Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000002595 magnetic resonance imaging Methods 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000003252 repetitive effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000005070 sampling Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000002604 ultrasonography Methods 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Images
Classifications
-
- 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
-
- 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
- H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0023—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the signalling
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
- H04L47/2433—Allocation of priorities to traffic types
-
- 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/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- 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/75—Media network packet handling
- H04L65/762—Media network packet handling at the source
-
- 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
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
- H04N21/23605—Creation or processing of packetized elementary streams [PES]
-
- 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
- H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
-
- 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/432—Content retrieval operation from a local storage medium, e.g. hard-disk
- H04N21/4325—Content retrieval operation from a local storage medium, e.g. hard-disk by playing back content from the storage medium
-
- 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/4343—Extraction or processing of packetized elementary streams [PES]
-
- 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/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/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
-
- 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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
- H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
- H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
-
- 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/61—Network physical structure; Signal processing
- H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
- H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
-
- 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/633—Control signals issued by server directed to the network components or client
- H04N21/6338—Control signals issued by server directed to the network components or client directed to network
-
- 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/84—Generation or processing of descriptive data, e.g. 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
- H04N21/845—Structuring of content, e.g. decomposing content into time segments
- H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
-
- 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/85—Assembly of content; Generation of multimedia applications
- H04N21/854—Content authoring
- H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]
-
- 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
- H04N21/85—Assembly of content; Generation of multimedia applications
- H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
- H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL
-
- 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/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
Definitions
- the present invention relates to a method and apparatus for transmitting and receiving information and data related to media in a media transmission communication system.
- DMB digital multimedia broadcasting
- DVP-H Digital Multimedia broadcasting
- ATSC-M / H Advanced Television Systems Committee-Mobile / Handheld
- IPTV Internet Protocol TeleVision
- digital broadcasting offers programs that are tens of times clearer than conventional analog broadcasting, with compact disk (CD) quality programs, and offers more channels for home shopping, home banking, and e-mail. It provides high quality broadcasting service by providing new interactive service such as Internet and Internet.
- MMT MPEG Picture Media Transport
- IP Internet Protocol
- a technique for transporting coded media data
- the coded media data includes timed audiovisual media data and non-timed data.
- ISOBMFF International Standardization Organization
- MPU Media Processing Unit
- HTTP hyper text transfer protocol
- the DASH segment can be transmitted using a transport protocol optimized for the transmission of objects (ie files).
- An example of the transport protocol is a real time object delivery over unidirectional transport (ROUTE) protocol, which is a file transport method based on request for comments (RFC) and MMT technology.
- ROUTE can be used to carry files on top of User Datagram Protocol (UDP) and IP layers.
- UDP User Datagram Protocol
- IP layers IP layers.
- the basic transmission unit of ROUTE is a Layered Coding Transport (LCT) packet.
- the header of the LCT packet indicates what part of the object the data included in the payload includes in the form of a byte offset.
- One embodiment of the present invention proposes a method and apparatus for transmitting and receiving information and data related to the importance of media in a communication system.
- One embodiment of the present invention provides a method and apparatus for transmitting and receiving information on a boundary of a data unit interpretable in a communication system.
- An embodiment of the present invention provides a method and apparatus for transmitting information on a buffer required before service reproduction in a communication system through signaling information.
- One embodiment of the present invention provides a method and apparatus for allowing a terminal to seamlessly receive a media service during network switching in a hybrid wireless network.
- a method of transmitting media information in a communication system comprising: generating a packet payload and a packet header related to media data, and transmitting a packet comprising the packet header and the packet payload, wherein the packet header Includes importance-related information indicating a priority type of data included in the packet payload.
- a method of transmitting media information in a communication system comprising: generating a packet payload and a packet header related to media data, and transmitting a packet comprising the packet header and the packet payload, wherein the packet header Includes signaling information indicating mapping between data included in the packet payload and a data unit for decoding.
- a method of transmitting media information in a communication system comprising: generating a packet payload and a packet header related to media data, transmitting a packet comprising the packet header and the packet payload, and decoding information of the packet. And transmitting a packet including a Layered Coding Transport (LCT) Session Instance description (LSID) including the LSID, wherein the LSID includes a transfer rate and a minimum buffer time of the media data. ).
- LCT Layered Coding Transport
- LSID Session Instance description
- a method of receiving media information by a terminal in a communication system comprising: receiving one or more packets including a media presentation description (MPD) and a media stream for a media service from a server, and for generating a new MPD
- MPD media presentation description
- the process of reading from and playing back is included.
- FIG. 1A shows a simplified structure of a media transport system according to an embodiment of the present invention.
- FIG. 1B illustrates a structure of a media file transmitted through a media transport system according to an embodiment of the present invention.
- FIG. 2 illustrates a simplified structure of a media transmission apparatus in a communication system according to an embodiment of the present invention.
- FIG. 3 illustrates a simplified structure of a media receiving apparatus in a communication system according to an embodiment of the present invention.
- FIG. 4 is a block diagram illustrating a structure of a transmitter supporting the transmission of media data according to an embodiment of the present invention.
- FIG. 5 is a block diagram illustrating a structure of a receiver for receiving media data according to an embodiment of the present invention.
- FIG. 6 illustrates a header format of an LCT packet based on a ROUTE protocol applicable to the present invention.
- FIG 7 shows an example of an extended header of an LCT packet header including additional header information.
- FIG 8 illustrates an example of an extended header of an LCT packet header including importance related information according to an embodiment of the present invention.
- FIG. 9 schematically illustrates a procedure of processing an extension header of an LCT packet carrying importance related information in a communication system according to an embodiment of the present invention.
- FIG. 10 is a flowchart illustrating a procedure for transmitting importance-related information through a packet header of an LCT packet according to an embodiment of the present invention.
- FIG. 11 is a flowchart illustrating a procedure of receiving importance related information through a packet header of an LCT packet according to an embodiment of the present invention.
- FIG. 12 illustrates an example of an FDT instance of an LSID carrying importance related information according to an embodiment of the present invention.
- FIG. 13 is a flowchart illustrating a procedure of processing an EFDT instance of an LSID carrying importance related information in a communication system according to an embodiment of the present invention.
- FIG. 14 is a block diagram illustrating a structure of a receiver for receiving media data according to an embodiment of the present invention.
- 15A and 15B are diagrams illustrating examples of an extension header of the LCT packet header.
- 16 illustrates an example of a packet transmission procedure using start and end fields according to an embodiment of the present invention.
- 17 is a flowchart illustrating a procedure for transmitting a packet including signaling information for a data unit according to an embodiment of the present invention.
- FIG. 18 is a flowchart illustrating a procedure of receiving a packet including signaling information of a data unit according to an embodiment of the present invention.
- FIG. 19 illustrates a format of an extended header including information for identifying a data unit for outputting a packet buffer according to an embodiment of the present invention.
- 20 is a diagram illustrating an example of a packet transmission procedure using start and end location fields according to an embodiment of the present invention.
- 21A to 21D illustrate information included in an extension header according to various embodiments of the present invention.
- 22 illustrates a system structure for transmitting and receiving control information according to an embodiment of the present invention.
- 23 shows a system structure for transmitting and receiving control information according to an embodiment of the present invention.
- a “component” may include one or more components.
- first and second may be used to describe various components, but the components are not limited by the terms. The terms are used only for the purpose of distinguishing one component from another.
- first component may be referred to as the second component, and similarly, the second component may also be referred to as the first component.
- an electronic device may include a communication function.
- the electronic device may be a smart phone, a tablet personal computer (PC), a mobile phone, a video phone, an e-book reader, a desktop ( desktop PC, laptop PC, netbook PC, personal digital assistant (PDA), portable multimedia player (PMP), MP3 player (MPEG Audio Layer-) 3 player), mobile medical device, camera, wearable device (e.g., head-mounted device (HMD), electronic clothing, electronic bracelet, electronic necklace, electronic It can be an accessory, an electronic tattoo, or a smart watch.
- PDA personal digital assistant
- PMP portable multimedia player
- MP3 player MPEG Audio Layer- 3 player
- HMD head-mounted device
- electronic clothing electronic bracelet
- electronic necklace electronic It can be an accessory, an electronic tattoo, or a smart watch.
- the electronic device may be a smart home appliance having a communication function.
- the smart home appliance includes a television, a digital video disk (DVD) player, audio, a refrigerator, an air conditioner, a vacuum cleaner, an oven, a microwave oven, a washer, a dryer. and the air cleaner and the set-top box (set-top box) and, TV box (For example, Samsung HomeSync TM, Apple TV TM , or Google TV TM) and game consoles (gaming console), and electronic dictionaries and , A camcorder, an electronic photo frame, and the like.
- DVD digital video disk
- an electronic device may include a medical device (eg, magnetic resonance angiography (MRA) device, magnetic resonance imaging (MRI), and computed tomography) computed tomography (CT) devices, imaging devices or ultrasound devices), navigation devices, global positioning system (GPS) receivers, event data recorders (EDRs), and flights Flight data recorder (FDR), automotive infotainment device, navigational electronic device (e.g. navigational navigation device, gyroscope or compass), avionics device, security device And industrial or consumer robots.
- MRA magnetic resonance angiography
- MRI magnetic resonance imaging
- CT computed tomography
- CT computed tomography
- imaging devices or ultrasound devices navigation devices
- GPS global positioning system
- EDRs event data recorders
- FDR flights Flight data recorder
- automotive infotainment device navigational electronic device (e.g. navigational navigation device, gyroscope or compass), avionics device, security device And industrial or consumer robots.
- an electronic device includes a furniture, a part of a building / structure, an electronic board, an electronic signature receiving device, a projector, and various measurement devices (eg, Water, electricity, gas or electromagnetic wave measuring devices) and the like.
- various measurement devices eg, Water, electricity, gas or electromagnetic wave measuring devices
- the electronic device may be a combination of devices as described above.
- the electronic device according to the preferred embodiments of the present invention is not limited to the device as described above.
- the method and apparatus proposed in various embodiments of the present invention include an Institute of Electrical and Electronics Engineers (IEEE) 802.11ac communication system, an IEEE 802.16 communication system, and digital multimedia broadcasting (DMB). ), Mobile broadcasts such as digital video broadcasting-handheld (DVP-H), and advanced television systems committee-mobile / handheld (ATSC-M / H) services.
- IEEE Institute of Electrical and Electronics Engineers
- DMB digital multimedia broadcasting
- Mobile broadcasts such as digital video broadcasting-handheld (DVP-H), and advanced television systems committee-mobile / handheld (ATSC-M / H) services.
- IPTV Internet protocol television
- MMT mobile machines
- EPS evolved packet systems
- LTE long-term evolution
- LTE-A long-term evolution-advanced
- HSDPA high-speed downlink packet High speed downlink packet access
- HSUPA high speed uplink packet access
- 3rd generation project partnership 2 3GPP2 A high rate packet data (HRPD) mobile communication system, a 3GPP2 wideband code division multiple access (WCDMA) mobile communication system, a 3GPP2 code division multiple access (CDMA) mobile communication system
- HRPD high rate packet data
- WCDMA wideband code division multiple access
- CDMA code division multiple access
- the present invention can be applied to various communication systems such as a mobile Internet protocol (Mobile IP) system and a communication system such as an IEEE mobile communication system.
- FIG. 1A shows a simplified structure of a media transport system according to an embodiment of the present invention.
- a media transport system may include a media transmitter 110 and a media receiver 130.
- the media receiving apparatus 130 may communicate with the media transmitting apparatus 110 based on the Internet 105, and at least part of the communication between the media receiving apparatus 130 and the media transmitting apparatus 110 may be a radio access network node ( 120 may include a wireless section.
- the media transmission apparatus 110 may be a content server on the Internet as an example.
- the media transmission apparatus 110 may be configured as a combination of a content server that provides multimedia contents through the Internet and a server that provides control information related to broadcasting through a broadcast channel.
- the media receiving device 130 may be an electronic device capable of receiving media data and / or providing the user.
- the media transmitting apparatus 110 may retain multimedia contents having various qualities, and provide the client 130 with multimedia contents suitable for the broadcasting environment of the user and the receiving environment of the media receiving apparatus 130.
- the media transmission apparatus 110 may provide a real time streaming service using MPEG-DASH.
- the media transmission apparatus 110 may transmit segments including media presentation description (MPD) in the form of extensible markup language (XML) and multimedia content for transmission in the form of binary format to the client 130 using the ROUTE protocol. have.
- MPD media presentation description
- XML extensible markup language
- the DASH 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 / or time to be transmitted to the media receiving apparatus 130 to support a streaming service.
- the media segment may include information on how to access the media presentation in the segment, such as information in the media stream, at least one access unit, presentation time or index.
- the media segment may be divided into at least one subsegment by segment index.
- the MPD has a hierarchical structure and may include information on structural functions and roles of each layer.
- Multimedia content may include at least one media segment.
- Each media segment may include at least one fragment.
- the fragment may be the above-described subsegment.
- 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 an initial presentation time, data offset, and SAP (Stream Access Points) information of media data existing in the fragment.
- SAP Stream Access Points
- the movie fragment box may include metadata about the media data ('mdat') box.
- the movie fragment box may include information related to the timing, indexing, and decoding of media data samples in the fragment.
- the fragment payload may include a media data (mdat) box.
- the media data (mdat) box may include actual media data for the corresponding media component (video and audio, etc.). Encoded media data is included in chunk units in the media data (mdat) box corresponding to the fragment payload. Samples corresponding to the same track may be included in one chunk.
- the media transmission apparatus 110 may generate at least one transport block by dividing the fragment.
- the media transmission apparatus 110 may include the fragment header and the payload data in different transport blocks to distinguish the fragment header and the payload data. Thereafter, the media transmission apparatus 110 may generate at least one symbol by dividing the at least one transport block.
- the length of all symbols in the object may be the same. Also, in order to equalize the length of all symbols in the object, the last symbol of the transport block may include padding bytes.
- the media transmission apparatus 110 may packetize at least one symbol. For example, the media transmission apparatus 110 may generate at least one LCT packet based on at least one symbol. Then, the media transmitting apparatus 110 may transmit the at least one LCT packet. The at least one LCT packet may be received by the media receiving device 130 via the Internet 105 and / or the radio access network node 120.
- FIG. 1B illustrates a structure of a media file transmitted through a media transport system according to an embodiment of the present invention.
- the media file 102 is divided into one or more DASH segments 104, 106, 108.
- the DASH segments 104, 106, 108 are divided into an Initialization Segment 104 and one or more Media Segments 106, 108.
- the initialization segment 104 is information required for playing the media data included in the media segments 106 and 108 and includes a file type ('ftyp') box and a movie ('moov') box.
- the file type (ftyp) box may include the file type, file version, and compatibility information for the media file 110, and the moov box may include metadata describing the media data. .
- Media segments 106 and 108 include a media data (mdat) box containing actual media data, and one or more whole self-contained movie fragments ('moof') associated with the media data (mdat) box. ) Must include a box.
- the movie fragment box may include metadata for the corresponding media data (mdat) box.
- media segments 106 and 108 may include a segment type ('styp') box.
- FIG. 2 illustrates a simplified structure of a media transmission apparatus in a communication system according to an embodiment of the present invention.
- the media transmission apparatus 200 includes a transmitter 220, a processor 210, and a storage unit 230.
- the processor 210 controls the overall operation of the media transmitting apparatus 200.
- the processor 210 may control the media transmission apparatus 200 to perform an operation according to at least one of the embodiments of the present invention.
- the transmitter 220 transmits various signals, data, information, messages, and the like to the media receiving apparatus under the control of the processor 210.
- the media transmitting apparatus 200 may further include a receiver capable of receiving various signals, data, information, messages, and the like from the media receiving apparatus. .
- the storage unit 230 stores program codes and various data required for the operation of the media transmitting apparatus 200, in particular information, data, parameters, and the like related to the operation according to the embodiments of the present invention.
- the storage unit 230 may store media data, control information, and the like.
- the media transmission apparatus 200 is implemented as separate units such as the transmitter 220, the processor 210, and the storage unit 230, but the media transmission apparatus 200 is a transmitter 220. ), At least two of the processor 210 and the storage unit 230 may be implemented in a combined form.
- FIG. 3 illustrates a simplified structure of a media receiving apparatus in a communication system according to an embodiment of the present invention.
- the media receiving apparatus 300 includes a processor 310, a receiver 320, and a storage unit 330.
- the processor 310 controls the overall operation of the media receiving device 300.
- the processor 310 may control the media receiving apparatus 300 to perform an operation according to at least one of the embodiments of the present invention.
- the receiver 320 receives various signals, data, information, messages, and the like from the media transmission apparatus 200 as an example under the control of the processor 310.
- the media receiving apparatus 300 may further include a transmitter capable of transmitting various signals, data, information, and messages to the media transmitting apparatus. .
- the storage unit 330 stores program codes and various data necessary for the operation of the media receiving apparatus 300, in particular information, data, parameters, and the like related to the operation according to the embodiments of the present invention.
- the storage unit 330 may store media data, control information, and the like received from the media transmitting apparatus 200.
- the media receiving apparatus 300 is implemented as separate units such as the processor 310, the receiver 320, and the storage unit 330, but the media receiving apparatus 300 is the processor 310. ),
- the receiver 320 and the storage unit 330 may be implemented in a combined form.
- FIG. 4 is a block diagram illustrating a structure of a transmitter supporting the transmission of media data according to an embodiment of the present invention.
- the structure of the transmitter 400 shown here may be implemented as at least part of the transmitter 220 and the processor 210 shown in FIG. 2 as an example.
- the receiver 400 includes one or more encoders 410 and 415, a segment generator 420, and a packetizer 430.
- Encoders 410 and 415 encode media data (eg, files) in units of access units (AUs), and segment generator 420 includes media segments that contain encoded media data for one or more access units.
- segment generator 420 includes media segments that contain encoded media data for one or more access units.
- the packetizer 430 generates DASH segments based on a transport protocol optimized for transmission of an object (ie, a file), for example, packets based on a ROUTE protocol (referred to as ROUTE packets or LCT packets). It is sent to the counterpart.
- ROUTE packets or LCT packets ROUTE protocol
- the transmitter 400 may further include a signaling encoder 425.
- the signaling encoder 425 generates control information (or signaling information) required for ROUTE transmission, and the control information may be inserted into the packet header or payload by the packetizer 430.
- FIG. 5 is a block diagram illustrating a structure of a receiver for receiving media data according to an embodiment of the present invention.
- the structure of the receiver 500 shown here may be implemented as at least part of the receiver 320 and the processor 310 shown in FIG. 3 as an example.
- the transmitter 500 may include a de-packetizer 510 and a segment parser 520 and one or more decoder buffers 530 and 535. And further decoders 540 and 545.
- Depacketizer 510 receives packets based on a transport protocol used by a transmitter, e.g., a ROUTE protocol (referred to as ROUTE packets or LCT packets), and decomposes the packets into segments, e.g., DASH segments. Create Although not shown, the DASH segments may be stored in the segment buffer until the segment analyzer 520 is ready.
- the segment analyzer 520 analyzes the DASH segments according to ISOBMFF and outputs media data in units of an access unit. Access units are stored in corresponding decoder buffers 530, 535 until the corresponding decoders 540, 545 are ready. Decoders 540 and 545 decode the access units to output media data.
- the receiver 500 further includes a signaling decoder 525.
- the signaling decoder 525 may decode the control information (or signaling information) provided from the depacketizer 510 and provide necessary information to the segment analyzer 520 and other entities.
- the control information may be obtained from, for example, a packet header of each packet.
- a session that can be established according to the ROUTE protocol may be configured with at least one Layered Coding Transport (LCT) session.
- LCT Layered Coding Transport
- a media component when one media component is delivered through one LCT session, at least one media component may be multiplexed and transmitted through a ROUTE session.
- at least one transport object may be delivered through one LCT session.
- FIG. 6 illustrates a header format of an LCT packet based on a ROUTE protocol applicable to the present invention.
- each field of the LCT packet header 600 represents the following information.
- the LCT packet header 600 includes an LCT version number (V), a congestion control flag (C), a protocol-specific indication (PSI) 601, and a transport session identifier flag (transport session).
- identifier flag S, transport object identifier flag (O), half-word flag (H), reserved (Res) field (603), close session flag: A), close object flag (B), LCT header length (HDR_LEN), codepoint (CP) 605, congestion control information (CCI), transport session identifier field (transport session identifier (TSI)), transport object identifier (TOI), and header extension (header extension) (610).
- the LCT packet may further include a FEC payload ID field and / or a symbol encoding field, and a payload containing media data.
- the LCT version number (V) field indicates a protocol version number. For example, this field indicates the LCT version number.
- the version number field of the LCT packet header 600 should be interpreted as a ROUTE version number field. As an example, the version of ROUTE may be version "1" of the LCT building block. In this case, the version number field is set to '0001b'.
- the Congestion Control Flag (C) field indicates the length of the Congestion Control Information (CCI) field.
- C 0 indicates that the CCI field has a length of 32 bits
- the PSI field 601 may be used as an indicator of a specific purpose in the LCT higher protocol. For example, the PSI field 601 indicates whether the current packet is a source packet or an FEC repair packet. If the ROUTE source protocol carries the source packet, the PSI field 601 will be set to "10b.”
- the transport session identifier flag (S) field indicates the length of the transport session identifier (TSI) field.
- the TSI field has a length of 32 * S + 16 * H.
- the transport object identifier flag (O) field indicates the length of the transport object identifier (TOI) field.
- TOI transport object identifier
- an object may mean one file, and TOI is identification information of each object, and a file having a TOI of 0 is called a file delivery table (FDT).
- FDT file delivery table
- the halfword flag (H) field indicates whether to add a half word (16 bits) to the length of the TSI and TOI fields.
- the closed session flag (A) field indicates that the session has ended or is about to end.
- the closed object flag (B) field indicates that the object being transmitted has terminated or is about to terminate.
- the LCT header length (HDR_LEN) field indicates the total length of the LCT packet header 600 in units of 32 bit words.
- the code point (CP) field indicates the type of payload carried by this packet. Depending on the type of payload, an additional payload header may be added to prefix the payload data.
- the Congestion Control Information (CCI) field is used to transmit congestion control information such as the number of layers, the number of logical channels, the number of sequences, and the like.
- the transport session identifier (TSI) field is a unique identifier of the session.
- TSI uniquely identifies one session among all sessions from a particular sender.
- the TSI field identifies a transport session in ROUTE, and the context of the transport session is provided by an LCT Session Instance description (LSID).
- LCT Session Instance description (LSID).
- the LSID defines each LCT session that constitutes a ROUTE session.
- Each transport session is uniquely identified by the TSI in the LCT packet header 600.
- the transport object identifier (TOI) field is a unique identifier of the object.
- the TOI indicates to which object in the session this packet belongs.
- the mapping of objects to TOI fields is provided by the extended FDT.
- the extended FDT specifies the details of the file delivery data. This is an FDT header extension.
- the extended FDT along with the LCT packet header can be used to generate an FDT equivalency description for the delivery object.
- the extended header field 610 is used for transmitting additional information in the LCT.
- the extension header 610 is not always used or is used to accommodate an optional header field with variable size.
- the FEC payload ID field includes identification information of a transmission block or an encoding symbol.
- the FEC payload ID indicates an identifier when a file to be transmitted is FEC encoded.
- an FEC payload ID may be assigned for the broadcaster or broadcast server to identify when the file is FEC encoded.
- the symbol encoding field may include data of a transmission block or an encoding symbol.
- the packet payload contains bytes generated from the object. If more than one object is sent in the session, the transmission object ID (TOI) in the LCT packet header 600 should be used to identify the object from which the packet payload data was generated.
- TOI transmission object ID
- a communication system supporting a ROUTE scheme transmission of importance information related to play out together with codec (coder / decoder (CODEC)) related information of media included in a payload of an LCT packet Suggest reception.
- codec coder / decoder
- the ROUTE protocol is a file transport method and does not define importance information indicating the importance of the media being transmitted. That is, since the LCT packet does not contain a definition of how important the data contained in the payload is, the receiver handles and / or processes the received LCT packets in the order in which they are received. None else but to do.
- the LCT packet header 600 of FIG. 6 may designate what type of media data included in the payload of the LCT packet has by using a field value of the CP field 601.
- the CP field 601 is related to encoding related information, for example, audio / video related information and clock rate information, rather than the importance of corresponding media data.
- the CP field 601 is 8 bits and used to indicate the type of payload carried by the LCT packet, and an additional payload header may be added before the payload according to the payload type.
- RTP real-time transport protocol
- LCT LCT standard
- Payload type Name MediaType No. of channels Clock rate (Hz) Frame size (ms) Default packet size (ms) 0 PCMU audio One 8000 any 20 One reserved audio One 8000 2 reserved audio One 8000 3 GSM audio One 8000 20 4 G723 audio One 8000 30 30 5 DVI4 audio One 8000 any 20 6 DVI4 audio One 16000 any 20 7 LPC audio One 8000 any 20 8 PCMA audio One 8000 any 20 9 G722 audio One 8000 any 20 10 L16 audio 2 44100 any 20 11 L16 audio One 44100 any 20 12 QCELP audio One 8000 20 13 CN audio One 8000 14 MPA audio 1, 2 90000 8-72 15 G728 audio One 8000 2.5 20 16 DVI4 audio One 11025 any 20 17 DVI4 audio One 22050 any 20 18 G729 audio One 8000 10 20
- PCMU pulse-code modulation ⁇ (mu) -law
- GSM Global System for Mobile communication
- G723, G722, G728, G729 Means a voice codec provided by the International Telecommunication Union Telecommunication standardization sector (ITU-T)
- DVI4 means digital video interaction 4
- LPC means linear predictive coding
- PCMA stands for PCM A-law
- L16 stands for Linear PCM 16-bit audio
- QCELP stands for Qualcomm Code Excited Linear Prediction (CELP)
- CN comfort noise.
- MPA stands for MPEG Audio.
- the clock rate refers to the speed at which the time stamp in the RTP header is increased, which is different from the sampling rate of the codec.
- the CP field 601 in the LCT packet header indicates to the CP field 601 in the LCT packet header the importance of a packet not related to media data in the payload, for example that the packet contains important information such as an MPD or an initialization segment.
- the LCT packet header 600 includes an extension header 610 that can be used by the ROUTE protocol.
- the LCT packet header 600 may be used to provide additional header information, such as presentation time or server wall clock.
- FIG 7 shows an example of an extended header of an LCT packet header including additional header information.
- the extension header 700 may include an extension header type (HET) field 710 and a header extension length (HEL) field 720.
- the HET field 710 indicates the type of the extension header 700 as 8 bits
- the HEL field 720 indicates the length of the entire extension header 700 in multiples of a 32-bit word.
- the extension header 720 may further include a 64-bit network time protocol (NTP) timestamp field 730 indicating a presentation time.
- NTP network time protocol
- the time stamp field 730 is greater than the sender current time (SCT).
- SCT sender current time
- the presentation time indicates a time when an object included in the packet should be presented.
- information related to the importance of data included in the LCT packet payload is added to the LCT packet header in a manner similar to that shown in FIG.
- the importance related information that may be added to the LCT packet header may indicate at least one of the following contents as an example.
- a fragmentation method (eg, a sample unit fragment or a box unit fragment) of the included media segment may be designated. You can also specify which boxes of the ISOBMFF are included.
- FIG 8 illustrates an example of an extended header of an LCT packet header including importance related information according to an embodiment of the present invention.
- the extension header 800 includes a HET field 810, a HEL field 815, a Priority (P) field 820, and a Priority Type (PT) field 825.
- the remaining area of the extended header 800 may include other header information such as the NTP time stamp field 830.
- a header field indicating the importance of payload data of a ROUTE packet will be referred to as an EXT_PRIORITY header.
- P field 820 is used to indicate whether PT field 825 is present.
- the PT field 825 indicates the importance type of the current payload carried by the corresponding LCT packet.
- the importance type of the payload may be indicated as shown in Table 2 below as an example.
- Payload includes media manifest info. (ex.MPD of DASH) 0x1 Payload includes media initialization related info. (ex.Init.Segment of DASH) 0x2 Payload includes media segments fragmented as arbitrarily 0x3 Payload includes media segments fragmented as application-specific (arbitrary basis) 0x4 Payload includes media segments fragmented as application-specific (sample basis) 0x5 Payload includes media segments fragmented as application-specific (a collection of box basis) 0x6 Payload includes media segments including ftyp box 0x7 Payload includes media segments including moov box 0x8 Payload includes media segments including moof box 0x9 Payload includes media segments including mdat box 0xA Payload includes media segments (ex.
- 0xB Payload includes media segments (ex. DASH segment) with non-time constraint.
- 0xC Payload includes signaling message
- 0xD Payload includes RAP (Random Access Point) To 0xF Reserved
- FIG. 9 schematically illustrates a procedure of processing an extension header of an LCT packet carrying importance related information in a communication system according to an embodiment of the present invention.
- LCT packets # 1, 2, 3, and 4 940 are received through the IP layer 950 and the UDP layer 945.
- Each LCT packet 940 includes an extension header in a packet header, and the extension header is information related to importance for payload data in the packet. For example, the P field 820 and the PT field 825 shown in FIG. ) May be included.
- the ROUTE layer 920 receives the received LCT packet without reconstructing and parsing all the objects 925 including the FDT instance 930 and the media objects 935 from the received LCT packet 940. Examining the header 900 of 940 may indicate how important the information contained in the LCT packet 940 is, thus determining the order in which the LCT packets 940 should be prioritized, or the object. Payload data may be passed to a higher layer prior to full reconstruction of 925.
- the ROUTE layer 920 may determine to preferentially process an LCT packet including an MPD or an initialization segment among the LCT packets 940 received and buffered in the packet buffer. Then, payload data of the LCT packet determined to be preferentially processed is output from the ROUTE layer 920 in preference to other LCT packets. As such, important data 905 such as MPD and initialization segment is preferentially output by ROUTE layer 920, and media segments 915 are thereafter output. The segments are subject to segment analysis and decoding by the DASH layer 910.
- FIG. 10 is a flowchart illustrating a procedure for transmitting importance-related information through a packet header of an LCT packet according to an embodiment of the present invention.
- the transmitter receives media content (eg, DASH content) and generates initialization segments and media segments (eg, DASH segments) based on the DASH content in step 1010. .
- the transmitter generates header information related to payload data to be transmitted.
- the header information may include importance-related information that may indicate whether the payload data to be transmitted is an MPD, an initialization segment, or a media segment.
- the importance-related information includes a PT field that may be defined as an example, as shown in Table 2.
- the transmitter In step 1020, the transmitter generates a transport packet (eg, an LCT packet) based on the DASH segments and the header information.
- the LCT packet may include the importance related information in an extension header.
- the LCT packet is transmitted to the receiver using a corresponding transmission protocol, for example, a ROUTE protocol.
- FIG. 11 is a flowchart illustrating a procedure of receiving importance related information through a packet header of an LCT packet according to an embodiment of the present invention.
- the receiver receives transport packets (eg, LCT packets) based on a transport protocol (eg, a ROUTE protocol), and decomposes (ie, depacketizes) the LCT packets in step 1110. )do.
- the receiver analyzes the header information obtained through the decomposition.
- the header information includes importance related information related to payload data carried by the corresponding LCT packet.
- the importance-related information includes a PT field that may be defined as an example, as shown in Table 2.
- step 1120 the receiver preferentially detects payload data of the LCT packet determined to be preferentially processed according to the importance related information, and in step 1125, the receiver carries a segment carried by the payload data based on the detected payload data. Analyze In step 1130, the segment is decoded by the decoder of the receiver.
- the importance related information of the payload data transmitted by the LCT packet may be transmitted through an extended FDT (EFDT) in the LSID.
- EFDT extended FDT
- the FLUTE protocol transmits the information necessary for transmission and the various attributes of the file to be transmitted through the transmission of the FDT instance, and then starts the file transmission.
- the LCT session included in the ROUTE session is described by the LSID.
- the LSID provides a description of all transport sessions transmitted on the ROUTE session.
- the LSID may be transmitted over the same ROUTE session that includes LCT sessions and may also be transmitted over a communication network, broadcast network, the Internet, 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 session in which the value of TSI is '0'.
- the LSID may include signaling information (or control information) for 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 on the LCT 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.
- FIG. 12 illustrates an example of an FDT instance of an LSID carrying importance related information according to an embodiment of the present invention.
- the FDT instance 1200 defines an FDT in a session.
- the FDT instance has an attribute @ObjectType 1210 indicating the importance type of the object to be transferred, along with attributes of the file to be transferred, for example, the attribute @Content_Location identifying the file to be transferred, and the attribute @TOI identifying the object to be transferred. It may include.
- an FDT instance including information about importance may be referred to as an extended FDT (EFDT) instance.
- FIG. 13 is a flowchart illustrating a procedure of processing an EFDT instance of an LSID carrying importance related information in a communication system according to an embodiment of the present invention.
- LCT packets # 1, 2, 3, 4 (1340) are received through the IP layer 1350 and the UDP layer 1345.
- Each LCT packet 1340 includes a packet header and payload data.
- the ROUTE layer 1320 obtains objects 1325 including media objects 1335 from the received LCT packet 940.
- the receiver may acquire the LSID 1330 including the EFDT instance through at least one LCT packet or another path.
- the EFDT instance of LSID 1330 provides importance related information for a particular object identified by TSI and TOI.
- the importance related information may include, as an example, the @ObjectType attribute shown in FIG. 12.
- the ROUTE layer 1320 may determine to preferentially process an object such as an MPD or an initialization segment among the objects 1325. Then, the object determined to be processed preferentially is output from the ROUTE layer 1320 in preference to other objects. This preferentially outputs important data 1305, such as the MPD and initialization segment, by the ROUTE layer 1320, and the media segments 1315 are thereafter output. The segments are subjected to segment analysis and decoding by the DASH layer 1310.
- a media transmission device for example, a ROUTE transmitter downloads DASH content based on ISOBMFF.
- the DASH content may include an MPD, initialization segment, media segments, and the like. Then, the ROUTE transmitter generates objects according to the FLUTE protocol based on the MPD, initialization segment, and media segments.
- a TOI is assigned to the MPD, the initialization segment, and the media segments.
- the created objects are fragmented and attached with header information to be generated into LCT packets for delivery.
- the ROUTE transmitter In order to indicate that important data necessary for the purpose of fast channel switching or the like is included in the LCT packet, the ROUTE transmitter generates an extension header including the importance related information and tags it in the LCT packet.
- the importance related information may be, for example, a P field and a PT field.
- Main points that can be indicated through the PT field are as follows.
- A. Indicates whether the LCT packet includes an MPD, an initialization segment, or a media segment.
- Sample basis Fragmented on a specific sample basis.
- the ROUTE transmitter transmits the LCT packet generated as described above through UDP / IP.
- a media receiving device for example, a ROUTE receiver receives a ROUTE / UDP / IP packet through a ROUTE session, removes a UDP / IP packet header from the received ROUTE / UDP / IP packet, and restores an LCT packet.
- the ROUTE receiver then parses the packet header of the LCT packet and interprets the importance related information in the extension header of the packet header.
- the importance related information may include the P field and the PT field described above.
- the ROUTE receiver then checks whether there is a P field in the extension header. If the value of the P field is set to 1 as a result of the inspection, it is determined that a PT field indicating whether payload data includes important information in the LCT packet is in the extension header and detects the PT field.
- Table 3 below shows an example of descriptions that can be indicated by the PT field.
- the ROUTE receiver may identify which object and what is contained in the LCT packet based on the PT field and the TOI field in the LCT packet.
- a media transmission apparatus supporting ROUTE / DASH transmission may transmit MPD and binary format segments in XML format using the ROUTE protocol.
- the MPD has a hierarchical structure and may include information on structural functions and roles of each layer.
- DASH transmission technology uses the MPD's attributes MPD @ minBufferTime (MBT) and Represntation @ bandwidth (BW) to convey the minimum size of the buffer required by the receiver. More specifically, assuming that media data is delivered to a receiver at a constant bitrate bandwidth (BW) starting from a stream access point (SAP), the decoder may use BW * to ensure that media is played back seamlessly. After buffering the MBT data, that is, the decoding operation should start after the MBT time after receiving the first bit. As described above, the amount of data to be stored in the buffer before starting the decoding operation is called an initial buffering amount.
- the receiver extracts the media data from the received DASH segments and stores it in the decoder buffer in units of an access unit.
- one segment may contain more than a few seconds of media data and the amount may be much larger than the BW * MBT described above. Therefore, although the decoder can start decoding if only buffering the media data of BW * MBT, the decoder cannot start decoding until all ROUTE packets constituting the intact DASH segment are received. This delay is one of the important factors that increases the initial start time and channel switch time of the service.
- the data unit is used to refer to a unit for outputting data in the packet buffer.
- the data unit for the output may mean decodable data alone, that is, a data unit for decoding.
- the transmitter treats one object as one transmission unit irrespective of its contents, divides the object into units suitable for transmission, and transmits the ROUTE packet so that the payload of each ROUTE packet is equal to the data unit of the packet buffer. May not match.
- a small box or an access unit may be transmitted in one ROUTE packet, but when a single box or an access unit is large, transmission of one or more ROUTE packets is required due to constraints of lower layers. Therefore, in order to define the mapping between the data unit of the packet buffer and the ROUTE packet, the transmitter transmits additional signaling information through the packet header.
- the signaling information may indicate at least one of the following information about the packet in which the signaling information is inserted.
- the packet contains one or more intact data units
- the packet contains the last part of the data unit.
- FIG. 14 is a block diagram illustrating a structure of a receiver for receiving media data according to an embodiment of the present invention.
- the receiver 1400 shown here may be implemented as at least part of the receiver 320 and the processor 310 shown in FIG. 3 as an example.
- the transmitter 1400 may include a packet buffer 1405, a depacketizer 1410, a segment analyzer 1420, one or more decoder buffers 1430, 1435, and one or more decoders. (1440, 1445).
- the depacketizer 1410 receives packets (referred to as ROUTE packets or LCT packets) based on a transport protocol used by a transmitter, for example, a ROUTE protocol, from the packet buffer 1405, and decomposes the packets into segments. For example, DASH segments are created. Although not shown, the DASH segments may be stored in the segment buffer until the segment analyzer 1420 is ready.
- the segment analyzer 1420 analyzes the DASH segments according to ISOBMFF and outputs media data in units of an access unit. Access units are stored in corresponding decoder buffers 1430 and 1435 until the corresponding decoders 1440 and 1445 are ready. Decoders 1440 and 1445 decode the access units to output media data.
- ISOBMFF defines the general form of time-based multimedia files such as video and audio.
- a file conforming to ISOBMFF consists of a series of objects called boxes, each of which contains media data or metadata.
- interpretation of metadata must be preceded, and the metadata is processed in a box unit. Therefore, when the input of the segment analyzer 1420 is configured in a box unit or an access unit, the segment analyzer 1420 may output media data to the decoder buffers 1430 and 1435 without additional delay time. To this end, the depacketizer 1410 transmits the data stored in the packet buffer 1405 to the segment analyzer 1420 in a box unit or an access unit unit.
- receiver 1400 further includes a signaling decoder 1425.
- the signaling decoder 1425 may decode control information (or signaling information) provided from the depacketizer 1410 and provide necessary information to the depacketizer 1410 and other entities.
- the control information may be obtained from, for example, a packet header of each packet.
- the format of the LCT packet used as the basic transmission unit in the ROUTE protocol is shown in FIG. 6.
- a PSI field 601, a Res field 603, or an extension header ( 610 may be used.
- 15A and 15B are diagrams illustrating examples of an extension header of the LCT packet header.
- the extension header 1500a may include an extension header type (HET) field 1510, an extension header length (HEL) field 1520, and header extensions content (HEC) 1530. Can be.
- the HET field 1510 indicates the type of the extended header 1500a
- the HEL field 1520 indicates the length of the entire extended header 1500a in multiples of a 32-bit word.
- the extended header 1500b may include an extended header type (HET) field 1540 and an extended header content (HEC) 1545.
- the HET field 1540 indicates the type of extension header 1500b.
- Signaling information for defining a mapping between the data unit of the packet buffer and the packet may be included in the extension header content 1530 or 1545 in the extension header 1500a or 1500b.
- the correlation between the payload of the LCT packet and the data unit may be one of the following.
- the payload of one LCT packet includes one or more intact data units.
- the payload of one LCT packet includes a portion of one data unit.
- LCT packets including one data unit are continuously transmitted.
- the transmitter may include the following two fields in the packet header.
- Start (S) field (1 bits): has a value of 1 when the first byte of the packet payload corresponds to the first byte of the data unit, and has a value of 0 otherwise.
- End (E) field (1 bits): has a value of 1 when the last byte of the packet payload corresponds to the last byte of the data unit, and has a value of 0 otherwise.
- the two fields may be transmitted through the PSI field 601 or the Res field 603 shown in FIG. 6.
- the two fields may be included in the extension headers 1530 and 1545 shown in FIG. 15A or 15B.
- the correlation between the packet payload and the data unit is defined as follows using the two fields.
- the packet payload contains part of one data unit
- the packet payload contains a portion containing the first byte of one data unit
- the packet payload contains a portion containing the last byte of one data unit
- the packet payload contains the whole of one or more data units
- 16 illustrates an example of a packet transmission procedure using start and end fields according to an embodiment of the present invention.
- an object 1600 is composed of a plurality of boxes 1610, 1620, 1630 a / b / c, and the boxes 1610, 1620, 1630 a / b / c are included in a packet buffer of a receiver. Corresponds to the data unit for packet output.
- the set 1610 including OU1, OU2, OU3, and OU4 corresponding to four small boxes is transmitted through one packet 1615.
- OU5 1620 corresponding to one box is transmitted through one packet 1625, and OU6 1630a, 1630b and 1630c corresponding to one box are transmitted through three packets 1635a, 1635b and 1635c. Is sent.
- 17 is a flowchart illustrating a procedure for transmitting a packet including signaling information for a data unit according to an embodiment of the present invention.
- the transmitter receives media content (eg, DASH content) and generates initialization segments and media segments (eg, DASH segments) based on the DASH content in step 1710. .
- the transmitter generates header information related to payload data to be transmitted.
- the header information may include signaling information indicating correlation between payload data included in a packet and a data unit.
- the signaling information includes, for example, an S field and an E field which can be inserted into the PSI field 601 or the Res field 603 of the packet header.
- the transmitter In step 1720, the transmitter generates a transport packet (eg, an LCT packet) based on the DASH segments and the header information.
- the LCT packet may include the signaling information in a packet header.
- the LCT packet is transmitted to the receiver using a corresponding transmission protocol, for example, a ROUTE protocol.
- FIG. 18 is a flowchart illustrating a procedure of receiving a packet including signaling information of a data unit according to an embodiment of the present invention.
- the receiver receives a transport packet (eg, LCT packet) based on a transport protocol (eg, a ROUTE protocol), and decomposes (ie, depacketizes) the LCT packet in step 1810. .
- the receiver analyzes the header information obtained through the decomposition.
- the header information includes signaling information related to correlation of payload data carried by the LCT packet and data unit.
- the signaling information includes, for example, an S field and an E field which can be inserted into the PSI field 601 or the Res field 603 of the packet header.
- step 1820 the receiver determines the processing of the LCT packet based on the signaling information in the packet header.
- a detailed procedure of the receiver will be described with reference to the example of FIG. 16 as follows.
- the receiver receives the first packet 1615 and identifies that the first packet 1615 contains one or more intact data units 1610 based on the S and E fields of the packet header. Accordingly, the receiver directly delivers payload data of the first packet 1615 to the output, that is, the segment analyzer 1420.
- the receiver similarly identifies that the second packet 1625 includes one or more intact data units 1620 based on the S and E fields of the packet header, and The payload data of the second packet 1625 is directly transferred to the segment analyzer 1420.
- the receiver Upon receiving the third packet 1635a, the receiver determines that the payload of the third packet 1635a includes a portion 1630a including the beginning of the data unit based on the S and E fields of the packet header. To identify. In this case, the receiver stores the payload data of the third packet 1635a in the packet buffer 1405 instead of directly delivering the payload data to the segment analyzer 1420.
- the receiver Upon receiving the fourth packet 1635b, the receiver identifies that the payload of the fourth packet 1635b does not include the end of the data unit based on the S and E fields of the packet header.
- the payload data of the first packet 1635b is stored together with the payload of the previous packet 1635a.
- the receiver Upon receiving the fifth packet 1635c, the receiver identifies that the payload of the fifth packet 1635c includes the last portion 1630c of the data unit based on the S and E fields of the packet header,
- the payload data of the third and fourth packets 1635a and 1635c previously stored and the payload data of the fifth packet 1635c are output from the packet buffer 1405 and transmitted to the segment analyzer 1420.
- the operation of the receiver according to the S and E fields indicating the correlation between payload data and the data unit is as follows.
- the receiver may apply some delay before outputting data to the segment analyzer 1420.
- the data unit for packet output is an input unit of the segment analyzer 1420. Since the input unit of the segment analyzer 1420 coincides with the processing unit of the segment analyzer 1420, the segment analyzer 1420 processes the input data without additional delay in step 1825 to transfer the media data to the decoder buffers 1430 and 1435. You can print it out.
- the decoders 1440 and 1445 compare the amount of media data stored in the decoder buffers 1430 and 1435 with an initial buffering requirement received through separate signaling, so that the amount of stored media data is larger than the initial buffering requirement. If it is equal to or greater than one, it starts decoding when it determines that enough media data is buffered.
- the initial buffering requirement may be delivered to the receiver through, for example, the MPD @ minBufferTime (MBT) attribute and the Represntation @ bandwidth (BW) attribute in the MPD.
- the S field may be omitted.
- the transmitter includes the following two fields in the packet header of each LCT packet.
- the two fields may be transmitted through the PSI field 601 or the Res field 603 shown in FIG. 6.
- the two fields may be included in the extension headers 1530 and 1545 shown in FIG. 15A or 15B.
- the receiver When the receiver receives the LCT packet having the E field set to 1, the receiver may output one or more buffered data units.
- the correlation between the packet payload and the data unit is defined as follows using the two fields.
- the packet payload contains part of one data unit
- the packet payload contains a portion containing the first byte of one data unit
- the packet payload contains a portion containing the last byte of one data unit
- the packet payload contains all or part of one or more data units
- the LCT packet may include information indicating a position or boundary of each data unit included in the payload of the packet.
- the information indicating the location may be included in the extension headers 1530 and 1545 of the LCT packet illustrated in FIG. 15A or 15B as an embodiment.
- FIG. 19 illustrates a format of an extended header including information for identifying a data unit for outputting a packet buffer according to an embodiment of the present invention.
- the extension header 1900 includes a HET field 1910, a first start position field 1920, and a last end position field 1930.
- the HET field 1910 has 8 bits and has a value between 128 and 255, and indicates the type of the extension header 1900.
- the first start position field 1920 indicates a position in the object of the start byte of the first data unit among the data units including the start byte in the packet payload.
- the last end position field 1930 indicates a position in the object of the last byte of the last data unit among the data units including the last byte in the packet payload.
- the location fields 1920 and 1930 may be displayed based on the first byte of the packet payload and not the start of the object.
- 20 is a diagram illustrating an example of a packet transmission procedure using start and end location fields according to an embodiment of the present invention.
- the object 2000 includes a plurality of boxes 2010, 2020, 2030, and 2040, and the boxes 2010, 2020, 2030, and 2040 are data for packet output in a packet buffer of a receiver. Corresponds to the unit.
- the size of each OU is as follows. That is, the size of the OU1 (2010) is 600 bytes, the size of the OU2 (2020) is 300 bytes, the size of the OU3 (2030) is 100 bytes, the size of the OU4 (2040) is 100 bytes, the size of the OU5 (2050) The size is 500 bytes.
- the packet payloads of the LCT packets 2015, 2025, 2035, and 2045 are sequentially allocated 400 bytes of data among the objects 2000.
- the receiver receiving the packets 2015, 2025, 2035 and 2045 processes the packets 2015, 2025, 2035 and 2045 according to the values of the S and E fields as follows.
- the first start position and the last end position may be indicated by the first start position field and the last end position field included in the extension header of the current packet, respectively.
- the receiver may apply some amount of delay before outputting data to the segment analyzer.
- the segment analyzer receives data of a data unit corresponding to its processing unit, and thus, the segment analyzer may process the input data without additional delay and output the media data to the decoder buffer.
- the S field in the packet header may be omitted.
- 21A illustrates information included in an extended header when an S field is omitted in a packet header according to an embodiment of the present invention.
- the extended header includes a HET field and a last ending position field 2110.
- the description of the last end position field 2110 is as mentioned above.
- the transmitter may selectively perform media aware packetization and may inform the receiver whether the transmitter performs media aware packetization using a separate signaling field.
- the transmitter does not include the location fields in the extension header when performing media aware packetization, and may include the location fields in the extension header when not performing media aware packetization, and the receiver is located in the extension header. If the fields exist, it may be determined that the transmitter has performed media aware packetization.
- the transmitter may include start (S) and end (E) fields in the extension header instead of the packet header.
- 21B illustrates the format of a fixed length extension header including start and end fields according to an embodiment of the present invention.
- the extended header includes the HET field, the S field 2115, the E field 2120, the first start position field 2125, and the last end position field 2130.
- the description of the fields 2115, 2120, 2125, and 2130 is as described above.
- 21C illustrates the format of a variable length extension header including start and end fields according to an embodiment of the present invention.
- the extended header includes the HET field, the HEL field 2135, the S field 2140, the E field 2145, the first start position field 2150, and the last end position field 2155.
- the description of the fields 2140, 2145, 2150, and 2155 is as described above.
- the S fields 2115 and 2140 and the first starting position fields 2125 and 2150 may be omitted.
- the transmitter may transmit an extension header included in the packet as shown in FIG. 21D only when the packet payload includes the last byte of the data unit.
- the extended header includes a HET field and a last ending position field 2160. Description of the field 2160 is as described above.
- the embodiments of the present invention include information on the boundary of the data unit that the segment analyzer can interpret in the packet header of the LCT packet, so that the receiver inputs a part of the DASH segment to the segment parser. As a result, service initial access time and channel switching time can be reduced.
- the amount of file data that must be stored in the buffer prior to decoding is related to the encoding of media content and the situation of the network.
- FIG. 1B the format of an ISO file used by a transmitter according to the ISOBMFF standard (for example, ISO / IEC 14496-12: 2012 (E)) is shown in FIG. 1B.
- the transmitter may deliver information related to initial buffering by including a pdin box (progressive download information box) in a file as shown in FIG. 1B.
- pdin box progressive download information box
- the pdin box aids in the progressive download of ISO files.
- the box contains combinations of an effective file download bitrate and a proposed initial playback delay. Pdin boxes can be placed as early as possible in the ISO file.
- the rate field means a download rate expressed in bytes / second
- the intial_delay field means the suggested delay to use when playing the file. In other words, if the download continues at the download rate given by the pdin box, all data in the file can be received within use time and playback is not interrupted.
- the pdin box may not be included in the file, and even if it is included, the receiver will not know the values in the pdin box after parsing the file.
- the actual initial delay is increased compared to the initial delay (ID) suggested by the pdin box.
- the initial delay required for stable service reproduction in the receiver is set in consideration of the file transfer rate. For example, if a receiver starts segment analysis after a file is received for one second under the assumption that the transmission rate is maintained at 500 kbytes / sec, media data included in the file may be seamlessly played.
- the initial delay is a value considering the characteristics of the media included in the file and the Internet download environment, and is difficult to apply to the broadcasting environment immediately.
- the receiver starts segment analysis after receiving a file for ID seconds, signaling information is provided for enabling media data to be played back seamlessly.
- the signaling information is delivered through separate signaling.
- the signaling information is transmitted through a source flow element included in the LSID of the ROUTE protocol.
- the signaling information may include attributes @transferRate and @minBufferTime of LSID.
- the attributes included in the source flow element of the LSID are called SourceFlow @ transferRate and SourceFlow @ minBufferTime.
- signaling information and an initialization segment are repeatedly transmitted to shorten the channel switching time. Since the initialization segment is regarded as initial signaling information, it may be transmitted through a separate session from the media segments together with the MPD, or may be transmitted through the same thin line as the media segments.
- SourceFlow @ transferRate and SourceFlow @ minBufferTime are set considering both initialization segment and media segments.
- SourceFlow @ transferRate R.
- R is calculated considering both the size of the initialization segment and the repetitive transmission period. If the receiver starts to analyze and decode the segment after storing R * ID data of the received file, the media data can be played back seamlessly. Where SourceFlow @ minBufferTime is equal to ID.
- the receiver collects (ie buffers) the received packets from the time of receiving the first packet of the initialization segment to the time after the ID and delivers them to the segment analyzer.
- the initialization segment may be received at the receiver before the media segments to be played are received.
- SourceFlow @ transferRate and SourceFlow @ minBufferTime which are attributes included in the LSID of the source flow through which the media segments are transmitted, are set in consideration of both the initialization segment and the media segments.
- SourceFlow @ minBufferTime set by the transmitter is calculated as follows.
- the receiver collects (ie buffers) the received packets for a time from the time of receiving the first packet of the media segments to after (R * ID-IS) / R and delivers them to the segment analyzer.
- the terminal when the terminal connects to a broadband network such as the Internet while receiving a media service through a broadcast network, the terminal is connected when the signal strength is small compared to the signal transmitted through the broadcast network. You will receive media services over the Internet.
- the broadcasting service provider may continue to serve the baseball game through the Internet, and the terminal may play the baseball game. If you want to continue to receive the broadcast service for the need to switch from the broadcast network to the Internet.
- a broadcaster may provide a broadcast service with a small number of connected terminals over the Internet.
- it is effective to service a broadcast service with a large number of terminals connected to the broadcast network.
- the Internet may have a relatively unstable transmission environment compared to the broadcast network, thereby degrading service quality. Accordingly, there is a need for a technique for allowing a terminal to seamlessly receive a media service in a state where network switching between different networks is required in a hybrid wireless network.
- control information is provided to allow a terminal to seamlessly receive a media service in a state in which network switching between different networks is required.
- 22 illustrates a system structure for transmitting and receiving control information according to an embodiment of the present invention.
- the system includes a broadcast content server 2200, a content server 2220 for the Internet, and a broadcast receiving terminal 2230.
- the broadcast receiving terminal 2230 includes a terminal controller 2245, a media player 2250, an MPD analyzer 2240, a buffer 2255, and a received packet analyzer 2235.
- the broadcast receiving terminal 2230 may access the content server 2200 for broadcasting through a broadcast network, and / or may access the content server 2220 for the Internet through a broadband network such as the Internet.
- the broadcast receiving terminal 2230 In order to receive a media service through a broadcast network, the broadcast receiving terminal (hereinafter referred to as a terminal) 2230 needs URL information on a broadcast network (hereinafter referred to as broadcast URL information).
- broadcast URL information When the media service uses transmission based on ROUTE / DASH, the broadcasting URL information may be obtained from an MPD. Accordingly, the terminal 2230 obtains an MPD including broadcast URL information for the media service from the broadcast content server 2200 and receives a media stream 2210 stored at a location indicated by the broadcast URL information.
- the terminal controller 2245 is configured to instruct the broadcast content server 2200 to indicate a location on the Internet for the media service. Request a new MPD that contains URL information. Then, the broadcast content server 2200 transmits the new or updated MPD 2205 including the URL information for the Internet requested by the terminal 2230 to the terminal 2230. The terminal 2230 obtains Internet URL information for the media service from the new / updated MPD 2205, and requests a request for the media service from the Internet content server 2220 based on the URL information for the Internet. 2260, and receives a media stream 2225 for the media service from a content server 2220 for the Internet. Accordingly, the terminal 2230 can seamlessly receive the media service while switching from the broadcast network to the Internet.
- the received packet analyzer 2235 of the terminal 2230 extracts the MPD and the media stream from the packets received from the broadcast content server 2200 or the Internet content server 2220, respectively, and then the MPD analyzer 2240 and the buffer 2255, respectively. To pass).
- the MPD analyzer 2240 extracts information such as URL information, a buffer minimum waiting time, and a buffer access time from the MPD and transmits the extracted information to the terminal controller 2245, and the terminal controller 2245 uses the media based on the received information.
- the regeneration unit 2250 is controlled.
- the media player 2250 reads the media stream stored in the buffer 2255 to play the media based on the buffer minimum wait time or the buffer accessible time.
- the buffer 2255 is based on the buffer minimum wait time or the buffer access time acquired from the MPD of the broadcast network at the time when the terminal 2230 switches from the broadcast network to the Internet. ) Can cause dropping during media playback due to differences in packet transmission rates between broadcast networks and the Internet.
- the terminal 2230 may acquire the relevant information necessary for media playback by receiving a packet including an MPD including an URL for the Internet at the time of switching from the broadcast network to the Internet and analyzing the MPD.
- the MPD contains a lot of information related to media playback, the amount of information transmission increases when the MPD is frequently transmitted.
- embodiments described below provide a technique for supporting seamless service reproduction of a terminal during network switching without significantly increasing the amount of network transmission.
- 23 shows a system structure for transmitting and receiving control information according to an embodiment of the present invention.
- the system includes a broadcast content server 2300, a content server 2320 for the Internet, and a broadcast receiving terminal 2330.
- the broadcast receiving terminal 2330 includes a terminal controller 2345, a media playback unit 2350, an MPD analyzer 2340, a buffer 2355, a received packet analyzer 2335, and an MPD generator 2370.
- the broadcast reception terminal 2330 may access the broadcast content server 2300 through a broadcast network, and / or may access the content server 2320 for the Internet through a broadband network such as the Internet.
- the broadcast receiving terminal 2330 In order to receive a media service through a broadcast network, the broadcast receiving terminal (hereinafter referred to as a terminal) 2330 needs URL information on the broadcast network (hereinafter referred to as broadcast URL information).
- the broadcasting URL information may be obtained from an MPD. Accordingly, the terminal 2330 obtains an MPD including broadcast URL information for the media service from the broadcast content server 2300 and receives a media stream 2310 stored at a location indicated by the broadcast URL information.
- the terminal controller 2345 may instruct the broadcast content server 2300 to indicate a location on the Internet for the media service. Request a new MPD that contains URL information. Then, the broadcast content server 2300 transmits the new or updated MPD 2305 including the URL for the Internet requested by the terminal 2330 to the terminal 2330. The terminal 2330 obtains Internet URL information for the media service from the new / updated MPD 2305, and requests a request for the media service from the Internet content server 2320 based on the URL information for the Internet. 2360, and receives a media stream 2325 for the media service from the content server 2320 for the Internet.
- the received packet analyzer 2335 of the terminal 2330 extracts an MPD and a media stream from at least one packet received from the broadcast content server 2300 or the Internet content server 2320, respectively, and the MPD analyzer 2340. Transfer to buffer 2355.
- the MPD analyzer 2340 extracts information such as URL information, a buffer minimum waiting time, and a buffer access time from the MPD and transmits the extracted information to the terminal controller 2345, and the terminal controller 2345 uses media based on the received information.
- the regeneration unit 2350 is controlled.
- the media player 2350 reads the media stream stored in the buffer 2355 to play the media based on the buffer minimum wait time or the buffer accessible time.
- the terminal controller 2345 may have the data held in the buffer 2355 be less than or equal to the minimum buffer amount based on the received packet amount for seamless media playback. You must keep it from falling.
- the broadcast content server 2300 transmits an MPD template to be used for network switching, so that the MPD generator 2370 of the terminal 2330 may generate its own MPD, and the broadcast content server 2300 may transmit the terminal 2330.
- Packetized information 2380 (hereinafter referred to as MPD generation information) 2380 is transmitted to the terminal 2330 to control the buffer 2355 based on the network state.
- the broadcast content server 2300 generates the MPD generation information based on the network state of the terminal 2330.
- the MPD generation information may have a smaller size than a conventional MPD and may be transmitted more frequently.
- the received packet analyzer 2335 of the terminal 2330 extracts and analyzes a packet including the MPD generation information 2380 transmitted by the broadcast content server 2300, and extracts the MPD generation information 2372 as a result of the analysis. It passes to the MPD generator 2370.
- the MPD generator 2370 generates its own MPD (or virtual MPD) 2374 based on the MPD generation information 2372, and transfers the generated MPD 2374 to the MPD information analyzer 2340.
- the MPD generator 2370 may generate the MPD 2374 by applying the MPD generation information 2372 to a preset MPD template, a previously received MPD template, or a previously received MPD.
- the MPD analyzer 2340 analyzes the MPD 2374 to extract URL information for Internet and information necessary for buffer control and media playback management (for example, a buffer minimum waiting time, a buffer access time, and the like).
- the information is transmitted to the terminal controller 2345.
- the terminal controller 2345 controls the media player 2350 to play the media based on the information reflecting the network state. That is, the media player 2350 reads the media stream stored in the buffer 2355 to play the media based on the buffer minimum wait time or the buffer accessible time provided by the terminal controller 2345.
- the MPD template used to generate its own MPD in the terminal 2330 may be an MPD schema defined in MPEG DASH, and in one embodiment, may be carried through a packet transmitted from the broadcast content server 2300. have.
- the MPD generation information required to control the buffer 2355 based on the network state may include information as shown in Table 4 below.
- Explanation newURL 255 bytes Address information from which media can be obtained maxE2eDelay 32bits Maximum delay time for packet transmission between server and terminal periodStartTime 32bits Start time of MPD @ Period currently being transferred accessTime 32bits Time to access DASH @ Segment (media data) of server minAccessTime 32bits Time to access essential information related to DASH @ Segment of server
- an initial value for time allocation is based on a coordinated universal time (UTC) or a system time clock (STC) of a server.
- UTC coordinated universal time
- STC system time clock
- the broadcast content server 2300 is a terminal 2330.
- the times indicated in Table 4 may be specified as absolute times or relative times.
- the MPD generator 2370 may calculate values to be included in the MPD to generate the MPD based on the MPD generation information as described above.
- MPD @ availabilityStartTime Converts into one of MPD @ availabilityStartTime + maxE2eDelay value or accessTime + minAccessTime or minAccessTime according to the buffer state management of the terminal 2330.
- MPD @ minBufferTime and MPD @ availabilityStartTime mean values that the terminal 2330 has previously received through the MPD and is currently applying.
- the MPD generation information may be transmitted using the following means.
- the broadcast content server 2300 allocates 1 bit of the Res field of the LCT packet header to the “header extension for signaling” field, assigns the bit value of the field to “1”, and generates an “MPD” in the extension header of the LCT packet header. You can add the "Info” field or the "MPD Template” field in the extension header.
- the broadcast content server 2300 may generate and transmit an MMT signaling message including elements including MPD generation information based on the format of the MMT signaling message.
- the elements may be inserted into one packet together with a GFDT descriptor of the MMT.
- the transmission is included in an electronic program guide (EPG) for a broadcast service.
- EPG electronic program guide
- the broadcast content server 2300 may insert and transmit the aforementioned MPD generation information in a specific field of the service guide guide.
- the service guide guide includes information that can be interpreted by the received packet analyzer 2335 and / or the MPD generator 2370, rather than information expressed to the user.
- the broadcast content server 2330 may include MPD generation information in an HTTP response message.
- the MPD template and / or the MPD generation information is provided from the broadcasting content server 2300 . Of course it can receive.
- a computer readable recording medium is any data storage device capable of storing data that can be read by a computer system. Examples of the computer readable recording medium include read only memory (ROM), and random access memory (RAM). And, compact disk-read only memory (CD-ROMs), magnetic tapes, floppy disks, optical data storage devices, and carrier wave carrier waves (such as data transmission over the Internet).
- ROM read only memory
- RAM random access memory
- CD-ROMs compact disk-read only memory
- CD-ROMs compact disk-read only memory
- CD-ROMs compact disk-read only memory
- CD-ROMs compact disk-read only memory
- magnetic tapes magnetic tapes
- floppy disks floppy disks
- optical data storage devices such as data transmission over the Internet
- carrier wave carrier waves such as data transmission over the Internet
- any such software may be, for example, volatile or nonvolatile storage, such as a storage device such as a ROM, whether or not removable or rewritable, or a memory such as, for example, a RAM, a memory chip, a device or an integrated circuit. Or, for example, on a storage medium that is optically or magnetically recordable, such as a compact disk (CD), DVD, magnetic disk or magnetic tape, and which can be read by a machine (eg computer). have.
- volatile or nonvolatile storage such as a storage device such as a ROM, whether or not removable or rewritable, or a memory such as, for example, a RAM, a memory chip, a device or an integrated circuit.
- a storage medium that is optically or magnetically recordable such as a compact disk (CD), DVD, magnetic disk or magnetic tape, and which can be read by a machine (eg computer). have.
- the method according to an embodiment of the present invention may be implemented by a computer or a portable terminal including a control unit and a memory, wherein the memory is suitable for storing a program or programs including instructions for implementing embodiments of the present invention. It will be appreciated that this is an example of a machine-readable storage medium.
- the present invention includes a program comprising code for implementing the apparatus or method described in any claim herein and a storage medium readable by a machine (such as a computer) storing such a program.
- a machine such as a computer
- such a program can be transferred electronically through any medium, such as a communication signal transmitted over a wired or wireless connection, and the invention suitably includes equivalents thereof.
- the apparatus may receive and store the program from a program providing apparatus connected by wire or wirelessly.
- the program providing apparatus includes a memory for storing a program including instructions for causing the program processing apparatus to perform a preset content protection method, information necessary for the content protection method, and wired or wireless communication with the graphic processing apparatus.
- a communication unit for performing and a control unit for automatically transmitting the program or the corresponding program to the request or the graphics processing unit.
Landscapes
- Engineering & Computer Science (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Databases & Information Systems (AREA)
- Computer Security & Cryptography (AREA)
- Library & Information Science (AREA)
- Quality & Reliability (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
Description
Payload type (PT) | Name | MediaType | No. of channels | Clock rate(Hz) | Frame size (ms) | Default packet size (ms) |
0 | PCMU | audio | 1 | 8000 | any | 20 |
1 | reserved | audio | 1 | 8000 | ||
2 | reserved | audio | 1 | 8000 | ||
3 | GSM | audio | 1 | 8000 | 20 | 20 |
4 | G723 | audio | 1 | 8000 | 30 | 30 |
5 | DVI4 | audio | 1 | 8000 | any | 20 |
6 | DVI4 | audio | 1 | 16000 | any | 20 |
7 | LPC | audio | 1 | 8000 | any | 20 |
8 | PCMA | audio | 1 | 8000 | any | 20 |
9 | G722 | audio | 1 | 8000 | any | 20 |
10 | L16 | audio | 2 | 44100 | any | 20 |
11 | L16 | audio | 1 | 44100 | any | 20 |
12 | QCELP | audio | 1 | 8000 | 20 | 20 |
13 | CN | audio | 1 | 8000 | ||
14 | MPA | audio | 1, 2 | 90000 | 8-72 | |
15 | G728 | audio | 1 | 8000 | 2.5 | 20 |
16 | DVI4 | audio | 1 | 11025 | any | 20 |
17 | DVI4 | audio | 1 | 22050 | any | 20 |
18 | G729 | audio | 1 | 8000 | 10 | 20 |
Value | Meaning |
0x0 | Payload includes media manifest info. (ex. MPD of DASH) |
0x1 | Payload includes media initialization related info. (ex. Init. Segment of DASH) |
0x2 | Payload includes media segments fragmented as arbitrarily |
0x3 | Payload includes media segments fragmented as application-specific (arbitrary basis) |
0x4 | Payload includes media segments fragmented as application-specific (sample basis) |
0x5 | Payload includes media segments fragmented as application-specific (a collection of box basis) |
0x6 | Payload includes media segments including ftyp box |
0x7 | Payload includes media segments including moov box |
0x8 | Payload includes media segments including moof box |
0x9 | Payload includes media segments including mdat box |
0xA | Payload includes media segments (ex. DASH segment) with time constraint. |
0xB | Payload includes media segments (ex. DASH segment) with non-time constraint. |
0xC | Payload includes signaling message |
0xD | Payload includes RAP (Random Access Point) |
~ 0xF | Reserved |
OBJECT | TOI | PT | Description |
\TEST.XML | 0 | - | TOI=0은 FDT를 담고 있음을 의미함. (ROUTE 고유의 정의) |
\TEST1.XML | 1 | 0 | PT=0은 MPD를 담고 있음을 의미함. |
\TEST2.XML | 2 | 1 | PT=1은 초기화 세그먼트를 담고 있음을 의미함. 디코더 셋팅이 필요한 경우 수신기는 우선적으로 수신/복원 필요한 오브젝트가 포함된 것으로 판단함. |
\TEST3.XML | 3 | 4 | PT=4은 LCT 패킷에 미디어 데이터가 담겨져 있지만, 특정 박스가 아닌 샘플 단위로 프래그먼트되어 있음을 의미함. |
… | .. | … | … |
필드명 | 크기 | 설명 |
newURL | 255bytes | 미디어를 획득할 수 있는 주소 정보 |
maxE2eDelay | 32bits | 서버와 단말간의 패킷 전송의 최대 지연 시간 |
periodStartTime | 32bits | 현재 전송 중인 MPD@Period의 시작 시간 |
accessTime | 32bits | 서버의 DASH@Segment(미디어 데이터)를 접근할 수 있는 시간 |
minAccessTime | 32bits | 서버의 DASH@Segment에 관련된 필수 정보에 접근할 수 있는 시간 |
Claims (14)
- 통신 시스템에서 미디어 정보를 송신하는 방법에 있어서,미디어 데이터에 관련된 패킷 페이로드와 패킷 헤더를 생성하는 과정과,상기 패킷 헤더와 상기 패킷 페이로드로 구성된 패킷을 송신하는 과정을 포함하며,상기 패킷 헤더는, 상기 패킷 페이로드에 포함된 데이터의 중요도 타입(priority type)을 지시하는 중요도 관련 정보를 포함함을 특징으로 하는 송신 방법.
- 제 1 항에 있어서, 상기 중요도 타입은,상기 패킷 페이로드에 MPD(Media Presentation Description)가 포함됨을 지시하거나,상기 패킷 페이로드에 디코더 초기화를 위한 초기화 세그먼트가 포함됨을 지시하거나,상기 패킷 페이로드에 포함되는 미디어 세그먼트의 프래그먼트 방식을 지시하거나,상기 패킷 페이로드 내 미디어 세그먼트에 포함되는 박스 타입을 지시하거나,상기 패킷 페이로드에 시그널링 메시지가 포함됨을 지시하거나,상기 패킷 페이로드에 RAP(Random Access Point)이 포함됨을 지시하는 것을 특징으로 하는 송신 방법.
- 제 1 항에 있어서, 상기 중요도 관련 정보는,상기 패킷 헤더 내의 확장 헤더 내에 포함되며,중요도 타입 필드가 포함되는지를 지시하는 중요도 필드와, 상기 중요도 타입을 지시하는 상기 중요도 타입 필드로 구성되는 것을 특징으로 하는 송신 방법.
- 통신 시스템에서 미디어 정보를 송신하는 방법에 있어서,미디어 데이터에 관련된 패킷 페이로드와 패킷 헤더를 생성하는 과정과,상기 패킷 헤더와 상기 패킷 페이로드로 구성된 패킷을 송신하는 과정을 포함하며,상기 패킷 헤더는, 상기 패킷 페이로드에 포함된 데이터와 디코딩을 위한 데이터 단위 간의 매핑을 지시하는 시그널링 정보를 포함함을 특징으로 하는 송신 방법.
- 제 4 항에 있어서, 상기 시그널링 정보는,상기 패킷 페이로드가 하나 이상의 온전한 데이터 단위를 포함하고 있는지,상기 패킷 페이로드가 하나의 데이터 단위의 시작 부분을 포함하고 있는지, 혹은상기 패킷 페이로드가 하나의 데이터 단위의 마지막 부분을 포함하고 있는지를 지시하는 것을 특징으로 하는 송신 방법.
- 제 4 항에 있어서, 상기 시그널링 정보는,상기 패킷 페이로드의 첫 번째 바이트가 하나의 데이터 단위의 첫 번째 바이트에 해당하는지를 지시하는 시작(S) 필드와, 상기 패킷 페이로드의 마지막 바이트가 하나의 데이터 단위의 마지막 바이트에 해당하는지를 지시하는 종료(End) 필드 중 적어도 하나를 포함하며,상기 S 및 E 필드는 상기 패킷 헤더 내의 PSI(protocol-specific indication) 필드, 예약된 필드 및 확장 헤더 중 어느 하나에 포함되는 것을 특징으로 하는 송신 방법.
- 제 4 항에 있어서, 상기 시그널링 정보는,상기 패킷 페이로드 내 시작 바이트가 포함된 데이터 단위 중 첫 번째 데이터 단위의 시작 바이트의 오브젝트 내에서의 위치를 나타내는 처음 시작 위치 필드와,상기 패킷 페이로드 내 마지막 바이트가 포함된 데이터 단위 중 마지막 데이터 단위의 마지막 바이트의 오브젝트 내에서의 위치를 나타내는 마지막 종료 위치 필드 중 적어도 하나를 포함하는 것을 특징으로 하는 송신 방법.
- 통신 시스템에서 미디어 정보를 송신하는 방법에 있어서,미디어 데이터에 관련된 패킷 페이로드와 패킷 헤더를 생성하는 과정과,상기 패킷 헤더와 상기 패킷 페이로드로 구성된 패킷을 전송하는 과정과,상기 패킷의 디코딩 정보를 포함하는 LSID(Layered Coding Transport (LCT) Session Instance description)를 포함하는 패킷을 송신하는 과정을 포함하며,상기 LSID는, 상기 미디어 데이터의 전송 레이트(transfer rate)와 버퍼 최소 대기 시간(minim buffer time)을 포함함을 특징으로 하는 송신 방법
- 제 8 항에 있어서, 상기 버퍼 최소 대기 시간은,(R*ID - IS)/R에 의해 계산되며,여기서 R은 상기 전송 레이트이고, ID는 주어진 초기 지연(initial delay)이고, IS는 초기화 세그먼트의 크기임을 특징으로 하는 송신 방법.
- 제 8 항에 있어서, 상기 LSID를 포함하는 패킷은 상기 미디어 데이터를 포함하는 패킷과 동일하거나 다른 세션을 통해 전송되는 것을 특징으로 하는 송신 방법.
- 통신 시스템에서 단말에 의해 미디어 정보를 수신하는 방법에 있어서,서버로부터 미디어 서비스에 대한 MPD(Media Presentation Description) 및 미디어 스트림을 포함하는 하나 혹은 그 이상의 패킷들을 수신하는 과정과,새로운 MPD의 생성을 위한 MPD 템플릿 및 상기 단말의 네트워크 상태에 기반한 MPD 생성 정보를 수신하는 과정과,상기 MPD 템플릿 및 MPD 생성 정보를 기반으로 자체적인 MPD를 생성하는 과정과,상기 자체적인 MPD를 기반으로 상기 미디어 스트림을 버퍼로부터 읽어 내어 재생하는 과정을 포함함을 특징으로 하는 수신 방법.
- 제 11 항에 있어서, 상기 MPD 생성 정보는,상기 미디어 서비스에 관련된 미디어를 획득할 수 있는 위치를 지시하는 URL(uniform resource locator) 정보와, 패킷 전송의 최대 지연 시간과, MPD 전송 주기의 시작 시간과, 미디어 데이터에 접근할 수 있는 시간과, 미디어 데이터에 관련된 필수 정보에 접근할 수 있는 시간과, 버퍼 최소 대기 시간 및 버퍼 접근 가능 시간 중 적어도 하나를 포함하는 것을 특징으로 하는 수신 방법.
- 제 11 항에 있어서, 상기 MPD 생성 정보를 포함하는 패킷은,상기 미디어 스트림을 포함하는 패킷들과 동일하거나 혹은 다른 서버로부터 수신되는 것을 특징으로 하는 수신 방법.
- 제 11 항에 있어서, 상기 MPD 생성 정보를 포함하는 패킷은,상기 단말이 방송 네트워크로부터 인터넷으로 전환하는 시점에서 전송되는 것을 특징으로 하는 수신 방법.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR1020177021957A KR102379530B1 (ko) | 2015-01-07 | 2016-01-07 | 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치 |
CN201680011210.8A CN107251521B (zh) | 2015-01-07 | 2016-01-07 | 用于在通信系统中发送和接收媒体信息的方法 |
US15/542,325 US10645432B2 (en) | 2015-01-07 | 2016-01-07 | Method and apparatus for transmitting and receiving media information in communication system |
Applications Claiming Priority (8)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR10-2015-0002252 | 2015-01-07 | ||
KR20150002252 | 2015-01-07 | ||
KR20150003012 | 2015-01-08 | ||
KR10-2015-0003012 | 2015-01-08 | ||
KR20150003011 | 2015-01-08 | ||
KR10-2015-0002994 | 2015-01-08 | ||
KR20150002994 | 2015-01-08 | ||
KR10-2015-0003011 | 2015-01-08 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2016111563A1 true WO2016111563A1 (ko) | 2016-07-14 |
Family
ID=56356180
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/KR2016/000141 WO2016111563A1 (ko) | 2015-01-07 | 2016-01-07 | 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치 |
Country Status (4)
Country | Link |
---|---|
US (1) | US10645432B2 (ko) |
KR (1) | KR102379530B1 (ko) |
CN (1) | CN107251521B (ko) |
WO (1) | WO2016111563A1 (ko) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2018174367A1 (ko) * | 2017-03-22 | 2018-09-27 | 엘지전자 주식회사 | 방송 신호 송수신 방법 및 장치 |
US11290755B2 (en) | 2017-01-10 | 2022-03-29 | Qualcomm Incorporated | Signaling data for prefetching support for streaming media data |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3090566A4 (en) * | 2014-01-02 | 2018-01-24 | LG Electronics Inc. | Broadcast transmission device and operating method thereof, and broadcast reception device and operating method thereof |
KR102163920B1 (ko) * | 2014-01-03 | 2020-10-12 | 엘지전자 주식회사 | 방송 신호를 송신하는 장치, 방송 신호를 수신하는 장치, 방송 신호를 송신하는 방법 및 방송 신호를 수신하는 방법 |
WO2016133296A1 (ko) * | 2015-02-16 | 2016-08-25 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
US10367874B2 (en) * | 2016-11-04 | 2019-07-30 | Verizon Patent And Licensing Inc. | MPEG-DASH delivery over multicast |
WO2019172726A1 (ko) * | 2018-03-09 | 2019-09-12 | 엘지전자 주식회사 | 신호 송신 장치, 신호 수신 장치, 신호 전송 방법, 및 신호 수신 방법 |
CN108989286B (zh) * | 2018-06-08 | 2020-01-14 | 北京开广信息技术有限公司 | 通用数据流的封装方法、解封装方法及装置 |
CN113206826B (zh) * | 2018-09-28 | 2022-10-04 | 华为技术有限公司 | 传输媒体数据的方法、客户端和服务器 |
US20220150296A1 (en) * | 2019-03-15 | 2022-05-12 | Nokia Technologies Oy | Method and apparatus for grouping entities in media content |
US20240056591A1 (en) * | 2021-04-12 | 2024-02-15 | Lg Electronics Inc. | Method for image coding based on signaling of information related to decoder initialization |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080046575A1 (en) * | 2006-08-21 | 2008-02-21 | Nokia Corporation | Caching directives for a file delivery protocol |
US20100215344A1 (en) * | 1999-09-28 | 2010-08-26 | Sony Corporation | Transport stream processing device, and associated methodology of generating and aligning source data packets in a physical data structure |
JP2011101156A (ja) * | 2009-11-05 | 2011-05-19 | Nippon Hoso Kyokai <Nhk> | 受信装置 |
WO2013107502A1 (en) * | 2012-01-17 | 2013-07-25 | Telefonaktiebolaget L M Ericsson (Publ) | Method for sending respectively receiving a media stream |
US20140059180A1 (en) * | 2012-08-22 | 2014-02-27 | Futurewei Technologies, Inc. | Carriage of ISO-BMFF Event Boxes in an MPEG-2 Transport Stream |
KR20140093763A (ko) * | 2010-07-19 | 2014-07-28 | 엘지전자 주식회사 | 미디어 파일 송수신 방법 및 그를 이용한 송수신 장치 |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102055789B (zh) * | 2009-11-09 | 2013-10-09 | 华为技术有限公司 | 实现基于http的流媒体业务的方法、系统和网络设备 |
KR101739272B1 (ko) * | 2011-01-18 | 2017-05-24 | 삼성전자주식회사 | 멀티미디어 스트리밍 시스템에서 컨텐트의 저장 및 재생을 위한 장치 및 방법 |
WO2013184248A1 (en) * | 2012-04-27 | 2013-12-12 | Huawei Technologies Co., Ltd. | Support for short cryptoperiods in template mode |
US9900166B2 (en) | 2013-04-12 | 2018-02-20 | Qualcomm Incorporated | Methods for delivery of flows of objects over broadcast/multicast enabled networks |
US9385998B2 (en) * | 2013-06-06 | 2016-07-05 | Futurewei Technologies, Inc. | Signaling and carriage of protection and usage information for dynamic adaptive streaming |
JPWO2015068598A1 (ja) * | 2013-11-11 | 2017-03-09 | 日本電気株式会社 | 装置、セッション処理品質安定化システム、優先度処理方法、送信方法、中継方法およびプログラム |
KR101838083B1 (ko) * | 2014-04-18 | 2018-03-13 | 엘지전자 주식회사 | 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법 |
CN105594219B (zh) * | 2014-07-31 | 2019-08-20 | Lg 电子株式会社 | 用于广播信号的发射/接收处理的设备和方法 |
-
2016
- 2016-01-07 KR KR1020177021957A patent/KR102379530B1/ko active IP Right Grant
- 2016-01-07 US US15/542,325 patent/US10645432B2/en not_active Expired - Fee Related
- 2016-01-07 WO PCT/KR2016/000141 patent/WO2016111563A1/ko active Application Filing
- 2016-01-07 CN CN201680011210.8A patent/CN107251521B/zh not_active Expired - Fee Related
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100215344A1 (en) * | 1999-09-28 | 2010-08-26 | Sony Corporation | Transport stream processing device, and associated methodology of generating and aligning source data packets in a physical data structure |
US20080046575A1 (en) * | 2006-08-21 | 2008-02-21 | Nokia Corporation | Caching directives for a file delivery protocol |
JP2011101156A (ja) * | 2009-11-05 | 2011-05-19 | Nippon Hoso Kyokai <Nhk> | 受信装置 |
KR20140093763A (ko) * | 2010-07-19 | 2014-07-28 | 엘지전자 주식회사 | 미디어 파일 송수신 방법 및 그를 이용한 송수신 장치 |
WO2013107502A1 (en) * | 2012-01-17 | 2013-07-25 | Telefonaktiebolaget L M Ericsson (Publ) | Method for sending respectively receiving a media stream |
US20140059180A1 (en) * | 2012-08-22 | 2014-02-27 | Futurewei Technologies, Inc. | Carriage of ISO-BMFF Event Boxes in an MPEG-2 Transport Stream |
Non-Patent Citations (1)
Title |
---|
SAMSUNG TELECOMMUNICATIONS: "Details of the New Transport Protocol", TSG SA4 MBS TELCO, TDOC S4-AHI428, 14 December 2013 (2013-12-14), Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/Ad-hoc_MBS/Docs_AHI> * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11290755B2 (en) | 2017-01-10 | 2022-03-29 | Qualcomm Incorporated | Signaling data for prefetching support for streaming media data |
WO2018174367A1 (ko) * | 2017-03-22 | 2018-09-27 | 엘지전자 주식회사 | 방송 신호 송수신 방법 및 장치 |
Also Published As
Publication number | Publication date |
---|---|
CN107251521A (zh) | 2017-10-13 |
KR102379530B1 (ko) | 2022-03-29 |
US20180278970A1 (en) | 2018-09-27 |
CN107251521B (zh) | 2021-01-12 |
KR20170094461A (ko) | 2017-08-17 |
US10645432B2 (en) | 2020-05-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2016111563A1 (ko) | 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치 | |
WO2014209057A1 (ko) | 지상파 방송망과 인터넷 프로토콜망 연동 기반의 하이브리드 방송 시스템에서 방송 서비스의 송수신 방법 및 장치 | |
WO2010082783A2 (ko) | 비실시간 서비스 처리 방법 및 방송 수신기 | |
WO2013048148A2 (en) | Method and apparatus for transmitting and receiving content | |
WO2015008986A1 (ko) | 하이브리드 방송 시스템의 방송 신호를 송신/수신하는 방법 및 장치 | |
WO2011071290A2 (en) | Streaming method and apparatus operating by inserting other content into main content | |
WO2018052253A1 (ko) | 송신 장치 및 그 송신 방법 | |
WO2016018042A1 (en) | Apparatus and method for transmitting/receiving processes of a broadcast signal | |
WO2012011724A2 (ko) | 미디어 파일 송수신 방법 및 그를 이용한 송수신 장치 | |
WO2011105811A2 (en) | Method and apparatus for transmitting and receiving data | |
WO2015002500A1 (ko) | 실시간 전송 프로토콜 기반의 방송 시스템에서 미디어 방송 신호의 송수신 방법 및 장치 | |
WO2011059291A2 (en) | Method and apparatus for transmitting and receiving data | |
WO2010058958A2 (ko) | 비실시간 서비스 처리 방법 및 방송 수신기 | |
WO2013055191A2 (ko) | 방송 시스템에서의 제어 메시지 구성 장치 및 방법 | |
WO2014171718A1 (ko) | 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법 | |
WO2012033319A2 (ko) | 스트리밍 컨텐츠 제공 장치 및 방법 | |
WO2011074844A2 (en) | Method of processing non-real time service and broadcast receiver | |
WO2009134105A2 (en) | Method of receiving broadcasting signal and apparatus for receiving broadcasting signal | |
EP2868106A1 (en) | A method and an apparatus for processing a broadcast signal including an interactive broadcast service | |
EP2499780A2 (en) | Method and apparatus for providing and receiving data | |
WO2011132883A2 (ko) | 인터넷 기반 컨텐츠 송수신 방법 및 그를 이용한 송수신 장치 | |
WO2015126117A1 (ko) | 방송 신호 송수신 방법 및 장치 | |
WO2011132879A2 (ko) | 인터넷 기반 컨텐츠 송수신 방법 및 그를 이용한 송수신 장치 | |
WO2017209574A1 (ko) | 미디어 콘텐츠 제공 방법 및 장치 | |
WO2011132882A2 (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: 16735184 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 15542325 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 20177021957 Country of ref document: KR Kind code of ref document: A |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 16735184 Country of ref document: EP Kind code of ref document: A1 |