WO2018186550A1 - Procédé et dispositif pour transmettre et recevoir un signal de diffusion - Google Patents

Procédé et dispositif pour transmettre et recevoir un signal de diffusion Download PDF

Info

Publication number
WO2018186550A1
WO2018186550A1 PCT/KR2017/013110 KR2017013110W WO2018186550A1 WO 2018186550 A1 WO2018186550 A1 WO 2018186550A1 KR 2017013110 W KR2017013110 W KR 2017013110W WO 2018186550 A1 WO2018186550 A1 WO 2018186550A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
media
network
sample
content
Prior art date
Application number
PCT/KR2017/013110
Other languages
English (en)
Korean (ko)
Inventor
박종환
권우석
윤준희
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Publication of WO2018186550A1 publication Critical patent/WO2018186550A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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
    • 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/4402—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 reformatting operations of video signals for household redistribution, storage or real-time display

Definitions

  • the present invention relates to an apparatus and method for transmitting and receiving broadcast signals.
  • a multicast transmission scheme for transmitting the same content to a plurality of users is effective because it can take advantage of both the unicast (broadcast) and broadcast (broadcast).
  • the conventional multicast transmission method was possible only within a single network, and multicast service between heterogeneous networks was impossible.
  • AV audio / video
  • An object of the present invention is to improve transmission efficiency in a method and apparatus for transmitting a broadcast signal.
  • Another object of the present invention is to provide a transmission apparatus and method for providing a multicast service in a broadcasting network.
  • a media data transmission method comprises the steps of: encoding media samples, generating metadata including sample grouping information for the encoded media samples, and the encoded media samples and the And transmitting the generated metadata, wherein the sample grouping information is information indicating each sample group including at least one media sample based on the decoding dependency of the media samples.
  • the media sample and the metadata may be encoded in an ISO base media file format (ISOBMFF) file format.
  • ISO base media file format ISO base media file format
  • the sample grouping information may be included in a movie fragment box (moof) or a movie box (Movie box, moov) in the ISOBMFF file.
  • the generating of the metadata may include generating a movie fragment box (moof) for each sample group.
  • An apparatus for transmitting media data includes an encoder for encoding media samples and generating metadata including sample grouping information for the encoded media samples, and the encoded media samples and the generated media. And a transmitter configured to transmit metadata, wherein the sample grouping information is information indicating each sample group including at least one media sample based on the decoding dependency of the media samples.
  • the media sample and the metadata may be encoded in an ISO base media file format (ISOBMFF) file format.
  • ISO base media file format ISO base media file format
  • the sample grouping information may be included in a movie fragment box (moof) or a movie box (Movie box, moov) in the ISOBMFF file.
  • the generating of the metadata by the media data transmission apparatus may be characterized by generating a movie fragment box (moof) for each sample group.
  • a method of receiving media data includes receiving media data, acquiring sample grouping information included in the media data, and decoding a media sample using the sample grouping information.
  • the sample grouping information may be information indicating each sample group including at least one media sample based on the decoding dependency of the media samples.
  • the media data may be characterized as having an ISO base media file format (ISOBMFF) file format.
  • ISOOBMFF ISO base media file format
  • the sample grouping information may be included in a movie fragment box (moof) or a movie box (Movie box, moov) in the media data. have.
  • the metadata may include a movie fragment box (moof) generated for each sample group.
  • An apparatus for receiving media data includes a receiver for receiving media data, and a decoder for acquiring sample grouping information included in the media data and decoding the media sample using the sample grouping information.
  • the sample grouping information may be information indicating each sample group including at least one media sample based on the decoding dependency of the media samples.
  • the media data is in an ISO base media file format (ISOBMFF) file format
  • the sample grouping information is a movie fragment box (moof) or It may be characterized by being included in a movie box (Movie box, moov).
  • the metadata may include a movie fragment box (moof) generated for each sample group.
  • playback at the receiver for the multicast service can be started quickly.
  • FIG. 1 is a diagram illustrating a network structure according to an embodiment of the present invention.
  • FIG. 2 illustrates a content network according to an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating a case where a content network according to an embodiment of the present invention includes satellite realy.
  • FIG. 4 is a diagram illustrating a case in which a content network includes a content delivery network (CDN) according to an embodiment of the present invention.
  • CDN content delivery network
  • FIG. 5 illustrates a wired multicast network according to an embodiment of the present invention.
  • FIG. 6 illustrates a mobile multicast network according to an embodiment of the present invention.
  • FIG. 7 illustrates a user network according to an embodiment of the present invention.
  • FIG. 8 is a diagram illustrating a network structure for ABR multicast according to an embodiment of the present invention.
  • FIG. 9 is a diagram illustrating a protocol for adaptive multicast streaming according to an embodiment of the present invention.
  • FIG. 10 illustrates a protocol for adaptive multicast streaming according to an embodiment of the present invention.
  • FIG. 11 illustrates a protocol for signaling and control messages according to an embodiment of the present invention.
  • FIG. 12 illustrates a protocol for signaling and control messages according to an embodiment of the present invention.
  • FIG. 13 illustrates a protocol for transmitting media data through an IP network according to an embodiment of the present invention.
  • FIG. 14 illustrates a media delivery protocol for IP multicasting according to an embodiment of the present invention.
  • FIG. 15 illustrates a media delivery protocol for IP multicasting according to an embodiment of the present invention.
  • FIG. 16 illustrates a media delivery protocol for IP multicasting according to an embodiment of the present invention.
  • FIG. 17 shows a DASH transmission scheme according to an embodiment of the present invention.
  • FIG. 18 illustrates a structure of a DASH segment according to an embodiment of the present invention.
  • FIG. 19 is a diagram illustrating a network configuration for multicast according to an embodiment of the present invention.
  • FIG. 20 illustrates a structure of a DASH initialization segment according to an embodiment of the present invention.
  • FIG. 21 illustrates a process of generating a DASH segment according to an embodiment of the present invention.
  • 22 is a diagram illustrating decoding sample grouping in moov according to an embodiment of the present invention.
  • FIG. 23 illustrates a sample grouping moof according to an embodiment of the present invention.
  • 24 is a diagram illustrating extension of a decoder configuration record according to an embodiment of the present invention.
  • 25 is a diagram illustrating a comparison of a playable time point using a sample grouping method according to an embodiment of the present invention.
  • FIG. 26 illustrates a comparison of a playable time point using a sample grouping method according to an embodiment of the present invention.
  • FIG. 27 illustrates a receiver structure according to an embodiment of the present invention.
  • FIG. 28 illustrates a content server and a content receiver according to an embodiment of the present invention.
  • 29 illustrates a method of operating a content server according to an embodiment of the present invention.
  • FIG. 30 illustrates a method of operating a content receiver according to an embodiment of the present invention.
  • a network for adaptive media streaming includes a content network, an adaptive bit rate (ABR) multicast network, and a user network (User).
  • ABR adaptive bit rate
  • User User
  • Network This is a functional classification of the networks used to support adaptive media streaming in a multicast network based on the Internet Protocol (IP).
  • IP Internet Protocol
  • Each network can also connect to additional networks to support other functions than adaptive media streaming.
  • the content network and the user network may each connect to a unicast network for unicast services.
  • the user network may send a request, report, and feedback for content to be received to the ABR multicast network.
  • the ABR multicast network may send a request, report, and feedback to the content network based on the information received from the user network.
  • the content network may transmit the multicast content and signaling information to the ABR multicast network based on the information received from the ABR multicast network.
  • the ABR multicast network may transmit the received multicast content and signaling information to the user network to provide a multicast service.
  • the content network may be responsible for generating, collecting, and packaging content for adaptive multicast streaming, and may include various content sources.
  • the content network may include a head-end of a broadcaster that serves terrestrial and cable broadcasting to serve broadcast content.
  • the broadcaster head end may include at least one of an encoder for encoding the content generated in the content production, a packager for converting the encoded content, and a content server for storing the content.
  • the content network may further include a satellite receiving network for receiving services produced from geographically remote regions. It may also include a content server to service pre-stored content.
  • the content network may include, together with a content server, a Content Delivery Network (CDN) that serves media delivery. Accordingly, the content network may generate and transmit a signaling message, a control message, and the like related to the content.
  • CDN Content Delivery Network
  • Separate signaling messages or control messages may be exchanged between nodes belonging to the content network for proper interworking of content, signaling messages, control messages, etc., and these messages may not be forwarded to other external networks. have.
  • the signaling message or control message not transmitted to the external network may be referred to as internal network signaling.
  • the content network may include a broadcaster head-end.
  • Content generated by the broadcaster may be delivered to a multicast sender through encoding and packaging, and may be multicasted, or may be stored in a content server and delivered to a multicast sender when necessary.
  • the following describes each component included in the broadcaster head-end of the content network.
  • an encoder included in the broadcaster head-end performs encoding on content.
  • a packager included in the broadcaster head-end may convert encoded content and data into a format suitable for multicast transmission.
  • a format suitable for multicast transmission may be, for example, a media segment created by dividing one content.
  • the packager may generate signaling that can be received by a receiver or a device belonging to a network if necessary.
  • the media segment generated by the packager may be directly transmitted to the multicast sender and multicasted, but may be stored in the content server when the media segment does not need to be delivered immediately.
  • the content server included in the broadcaster head-end may store media data and related signaling.
  • the content server can also store 3rd party content generated by third parties and use it for multicast if necessary.
  • the content stored in the content server may not need a separate encoding process.
  • the content server may store the media segment and the file encoding or packaging the content, and transmit the content segment upon request.
  • the encoding result of the media data may be stored in the content server, and a separate packaging process may be required according to the type of the transmission network.
  • the operator controller included in the broadcaster head-end manages content production and content server, and manages and controls a series of processes related to multicasting.
  • the operator controller collects control and signaling data for a plurality of devices and nodes in the content network and, if necessary, transmits the control and signaling data to the multicast network. This allows the operator controller to enable the multicast network to perform signaling and control related to the multicast.
  • the operator controller can receive and process unicast information transmitted from a decoding device or a player and use it for multicast.
  • the content network including satellite relay may include an encoder, a satellite transmitter, a satellite receiver, a packager, a content server, and an operator controller.
  • the head-end of a broadcaster serving terrestrial and cable broadcasting may include a satellite receiving network for receiving services of geographically separated content producers.
  • the satellite transmitting side may be the head-end of another broadcaster.
  • a satellite transmission / reception network to which headends of a plurality of broadcasters are connected may be included in the content network.
  • the content received through the satellite system may be multicasted by encoding and packaging to a multicast sender, or may be stored in a content server and transmitted to a multicast sender when necessary.
  • An encoder of a content network including satellite relay may perform encoding on content.
  • the encoder may be connected to a satellite transmission device for relaying broadcast data to a satellite.
  • Satellite relay systems of content networks with satellite realy can be used for live broadcasts to geographically remote locations. For example, overseas sports, concert relaying, news, and the like may be broadcast in real time through the satellite relay system. For this purpose, a separate satellite transmission related protocol and transmission scheme may be used. Data passed through the satellite transmission and reception system is delivered to the packager.
  • a content server of a content network including satellite relay may store media data and related signaling.
  • the data passed through the packager is sent directly to the multicast sender, but the media can be used for later use of the content at the broadcaster's head-end.
  • Data and signaling related thereto may be stored.
  • the description of the operator controller of the content network including satellite realy is as described in the previous drawings.
  • a content network including a content delivery network (CDN)
  • CDN can be connected for efficient use of network resources.
  • a content network including a content delivery network (CDN)
  • CDN may include an encoder, a packager, a content server, an operator controller, and a CDN.
  • the content of the OTT can be delivered to the CDN through encoding and packaging.
  • the encoded and packaged content may be stored in the content server and then delivered to the CDN in response to the request for the content.
  • Content delivered to the CDN may be delivered to the multicast sender.
  • the content of the OTT may be delivered to the multicast sender directly without going through the CDN and multicasted.
  • the encoder of the OTT may perform encoding on the content.
  • a live service may be provided or content to be stored in a content server may be produced. Description of the packager of the OTT is as described in the previous figure.
  • the OTT content server may store media data to be serviced by the OTT and signaling related thereto.
  • the content server can also store 3rd party content generated by third parties and use it for multicast if necessary. In this case, the content stored in the content server may not need a separate encoding process. Accordingly, the content server may store the media segment and the file encoding or packaging the content, and transmit the content segment upon request.
  • the encoding result of the media data may be stored in the content server, and a separate packaging process may be required according to the type of the transmission network.
  • OTT's Operator Controller can manage and control a series of processes involving multicast data and unicast data.
  • the operator controller collects control and signaling data for a plurality of devices and nodes in the content network and, if necessary, transmits the control and signaling data to the multicast network. This allows the operator controller to enable the multicast network to perform signaling and control related to the multicast.
  • the operator controller can receive and process unicast information transmitted from a decoding device or a player and use it for multicast.
  • the OTT and CDN may each include a separate operator controller, and the operator controller included in the OTT and the operator controller included in the CDN may communicate with each other.
  • An ABR multicast network is a network that multicasts content delivered from a content network over an IP network.
  • the IP network may correspond to either a managed network where QoS is managed by a network provider and unlicensed traffic is restricted, or an unmanaged network where unauthorized traffic is not restricted.
  • the IP network may be connected in a wired or wireless manner by devices included in a multicast network or a user network.
  • an IP network connected to a content network may be different from an IP network connected to a user network. That is, the content network and the user network may be connected to separate IP networks.
  • separate IP networks may follow a connection protocol between an ISP (Internet Service Provider) providing each network.
  • ISP Internet Service Provider
  • the sender and receiver are transparent for multicast content. That is, the output data of the sender is the same as the input data of the receiver, even though it passes through several ISP networks and nodes on the network.
  • the multicast network for transmitting and receiving the multicast stream may include a multicast sender (server), a multicast receiver (client), and a multicast network controller.
  • the multicast network may include a plurality of networks, depending on the location or connection status of the sender and receiver of the network for multicast. In addition, a separate protocol may be used for each network.
  • Multicast streams can be delivered over a wired IP network.
  • a network provided by an ISP Internet Service Provider
  • ISP Internet Service Provider
  • the multicast stream may be delivered through an IP network managed by a plurality of ISPs, and management entities of the multicast sender, receiver, controller and IP network may be different.
  • the transmission of the multicast stream may follow an access protocol corresponding to each ISP.
  • the multicast sender included in the multicast network may transmit content data to each multicast receiver.
  • the multicast sender may receive packaged content from a content network and transmit the packaged content to a plurality of multicast receivers using a multicast protocol.
  • the multicast receiver included in the multicast network may receive content data transmitted from the multicast sender and deliver the content data to a decoding device capable of playing the content data.
  • the multicast receiver can cache the content data so that the decoding device can play the content data efficiently.
  • the multicast receiver may be configured in the same apparatus as the decoding device.
  • the multicast stream may be received through a gateway of the user network. In such an embodiment, the multicast receiver may be a component of the user network.
  • the multicast network controller included in the multicast network may control content transmission and related session information of the multicast sender.
  • the multicast network controller may manage and transmit signaling information for configuration of each multicast sender and multicast receiver.
  • Such a multicast network controller may be connected to each multicast sender and multicast receiver using a protocol separate from the multicast content.
  • the multicast network controller may be connected only to the multicast sender, and signaling information transmitted to the multicast receiver may follow the same protocol as the multicast content.
  • the network cache included in the multicast network may include a node or a device that caches between the multicast sender and the multicast receiver.
  • the network cache may store a suitable range of content for efficient use of network resources, and deliver a multicast stream to the multicast receiver.
  • the network cache may perform an update procedure for the multicast sender and the cached content.
  • the multicast stream may be delivered over a wired IP network, but for a mobile receiver it may be delivered over a mobile access network.
  • mobile access networks can use networks that support IP transport.
  • the mobile access network may support multicast to serve a multicast stream to a plurality of mobile receivers.
  • the multicast sender included in the multicast network may transmit content data to each multicast receiver.
  • the multicast sender may receive packaged content from a content network and transmit the packaged content to a plurality of multicast receivers using a multicast protocol.
  • the multicast receiver included in the multicast network may receive content data transmitted from the multicast sender and deliver the content data to a decoding device capable of playing the content data.
  • the multicast receiver connected to the mobile access network may receive a radio signal for the mobile access network.
  • the multicast receiver connected to the mobile access network may be connected to the decoding device through a separate wireless access standard.
  • the multicast receiver can cache the content data so that the decoding device can play the content data efficiently.
  • the multicast receiver may be configured in the same apparatus as the decoding device.
  • the multicast network controller included in the multicast network may control content transmission and related session information of the multicast sender.
  • the multicast network controller may manage and transmit signaling information for configuration of each multicast sender and multicast receiver.
  • Such a multicast network controller may be connected to each multicast sender and multicast receiver using a protocol separate from the multicast content.
  • the multicast network controller may be connected only to the multicast sender, and signaling information transmitted to the multicast receiver may follow the same protocol as the multicast content.
  • the IP network and the mobile access network may each include a multicast network controller. In this case, the multicast network controller can transmit and receive control and signaling information about a corresponding network.
  • Each multicast network controller can perform communication between multicast network controllers using a separate protocol.
  • the network cache included in the multicast network may include a node or a device that caches between the multicast sender and the multicast receiver.
  • the network cache may be included in each of a plurality of networks constituting the multicast network, and a plurality of network caches may be included in each network.
  • some nodes of each network may simultaneously perform a cache role.
  • the network cache may store a suitable range of content for efficient use of network resources, and deliver a multicast stream to the multicast receiver.
  • the network cache may perform an update procedure for the multicast sender and the cached content.
  • the user network may be referred to as a network that receives data from a multicast network and delivers the content included in the data to a device that consumes the content.
  • the user network may be variously configured according to the configuration of the user network and the type of service through multicast.
  • the multicast receiver described above may be included in a user network according to an embodiment. When the multicast receiver is included in the user network, the multicast receiver may receive the multicast content through a device serving as a gateway or proxy included in the user network. In this case, the gateway or proxy may be considered as a component of the ABR multicast network.
  • the multicast receiver may serve as a server or a multicast sender in the user network.
  • the decoding device included in the user network can consume multicast content, and can enable multicast streaming even when the decoding device cannot directly receive the multicast content.
  • FIG. 7 illustrates a user network according to an embodiment of the present invention.
  • a home network may be considered.
  • the multicast receiver may directly receive the data transmitted by the multicast, but the home gateway belonging to the home network may receive the data and transmit the data to the multicast receiver.
  • the home gateway may receive data from the ABR multicast network when the home network includes a plurality of devices.
  • the home gateway can perform data transmission and reception with an external network and can also simultaneously act as a proxy. If the home gateway acts as a proxy, the home gateway can cache data for delivery to the multicast receiver.
  • the multicast receiver may be included in the ABR multicast network described above, but may be located inside the home network due to the configuration of the network. Depending on the configuration of the home network, the multicast receiver can act as a proxy. If the multicast receiver cannot directly play the multicast stream, a decoding device capable of playing the multicast stream may be additionally connected to the multicast receiver. In addition, the multicast receiver may be connected with a plurality of decoding devices to transmit a multicast stream.
  • a decoding device may be defined as a device that plays back and provides a multicast stream to a user.
  • a plurality of decoding devices can connect to the multicast receiver, and the decoding device can transmit and receive data via unicast or multicast.
  • the decoding device may connect to a unicast network in addition to the multicast network that receives the multicast stream.
  • the decoding device may send a request or report or the like to the content network or the ABR multicast network.
  • the decoding module and the display screen may be included in the home network as a separate device in addition to the decoding device.
  • the decoding device can also be configured as a single apparatus with a multicast receiver.
  • the network structure for adaptive media streaming may include a content network, an ABR multicast network, and a user network. Detailed description of each network is as described in the previous drawings.
  • the node or entity defined in the present invention may have a logical configuration, and each node may be configured as a separate device, but may operate in a device such as an adjacent node according to an embodiment. have. As shown, a plurality of networks may be connected to each other and exchange signaling and management information for efficient multicast streaming.
  • the protocol can be classified into a media protocol through which actual media data is transmitted, and a signaling protocol for controlling configuration of each node or entity for transmitting media data, or for transmitting configuration information about media data to various nodes and entities including a receiver.
  • a media protocol through which actual media data is transmitted
  • a signaling protocol for controlling configuration of each node or entity for transmitting media data, or for transmitting configuration information about media data to various nodes and entities including a receiver.
  • Signaling and control information is transmitted using a signaling protocol, but when a receiver receives media content through a single connection, a separate signaling path may not be configured. In this case, signaling and control information can be delivered through the media protocol.
  • a multicast receiver may be comprised of the same devices and modules as a decoder.
  • Media content created in the content network or stored in a server may be delivered to a user's decoding device and may be transmitted in multicast for delivery to a plurality of users.
  • a protocol for delivering content generated to a node and an entity performing multicast transmission and a protocol for multicasting and transmitting the content in the adaptive streaming format may be defined.
  • nodes and entities are shown as multicast senders.
  • content data passes through a plurality of nodes or entities, and an appropriate protocol is required between each node and entity.
  • a protocol on a node or an entity may use a protocol for delivering data to the next node efficiently and in real time, and such a protocol may be referred to as a tunneling protocol.
  • a tunneling protocol may be defined between the server and the multicast sender. At this time, the media content is delivered as a payload of the tunneling protocol, but the tunneling protocol may operate regardless of the format of the media content.
  • a protocol supporting adaptive streaming may be defined for a multicast receiver, and the IP multicast scheme may be applied to the adaptive streaming to be delivered to a plurality of multicast receivers.
  • IP multicast can be defined as a combination of TCP / IP and UDP / IP.
  • the multicast receiver may receive an IP multicast packet to obtain adaptive streaming data, and decode and play data corresponding to a media content format from the data.
  • the multicast receiver may be configured as a device or module separate from the decoder.
  • Media content created in the content network or stored in a server may be delivered to a user's decoding device and may be transmitted in multicast for delivery to a plurality of users.
  • a protocol for delivering content generated to a node and an entity performing multicast transmission and a protocol for multicasting and transmitting the content in the adaptive streaming format may be defined.
  • nodes and entities are shown as multicast senders.
  • content data passes through a plurality of nodes or entities, and an appropriate protocol is required between each node and entity.
  • a protocol on a node or an entity may use a protocol for delivering data to the next node efficiently and in real time, and such a protocol may be referred to as a tunneling protocol.
  • a tunneling protocol may be defined between the server and the multicast sender. At this time, the media content is delivered as a payload of the tunneling protocol, but the tunneling protocol may operate regardless of the format of the media content.
  • a protocol supporting adaptive streaming may be defined for a multicast receiver, and the IP multicast scheme may be applied to the adaptive streaming to be delivered to a plurality of multicast receivers.
  • IP multicast can be defined as a combination of TCP / IP and UDP / IP.
  • the multicast receiver may receive IP multicast packets to obtain adaptive streaming data and deliver them back to the decoder.
  • IP unicast protocol may be used between the multicast receiver and the decoder.
  • the content data received by the multicast receiver is delivered to the decoder again through IP unicast, and the decoder can decode and play data corresponding to the received media content format.
  • Transmission of signaling and control messages may be defined as a protocol distinct from media content transmission in order to provide transmission control, scheduling, configuration information, etc. in each node and entity performing adaptive streaming. have. Depending on the case where each node and entity is connected, it can be defined as a separate protocol.
  • signaling and control messages may be included and transmitted in a protocol for transmitting media content, but such signaling and control messages follow a protocol for media content delivery.
  • a control protocol may be defined between an operator controller included in a content network and a network controller included in a multicast network.
  • the network controller can also send a response or report message to the operator controller in order for the operator controller to generate control and management messages.
  • the tunneling protocol tunneling protocol
  • the tunneling protocol for sending a control message can be configured in both directions.
  • a single operator controller can send and receive control messages with multiple multicast network controllers.
  • each multicast network controller can be managed by a separate operator.
  • the configuration related information of the network may be transmitted to the multicast sender and the multicast receiver.
  • the network controller may transmit configuration information about network resources, mapping information between nodes of the network, routing information, and the like.
  • the configuration information received from the operator controller may be transmitted to the multicast sender or the multicast receiver.
  • the protocol transmitted from the multicast network controller to the multicast sender and the protocol transmitted to the multicast receiver may be distinguished. The upper part of the figure shows the protocol transmitted from the network controller to the multicast sender, and the lower part of the figure shows the protocol transmitted from the network controller to the multicast receiver.
  • IP multicast may be used to deliver configuration messages from a single network controller to a plurality of multicast senders and multicast receivers. Connections, statistical information, etc. collected by the multicast sender and the multicast receiver may be reported to the multicast network controller. Since this process can be performed independently by each multicast sender and multicast receiver, a unicast protocol can be used. This set of control information, configuration information, etc. can be dynamically updated and transmitted immediately or through scheduling.
  • the multicast receiver may use a signaling protocol for sending the received adaptive streaming data back to the decoding device.
  • an IP unicast protocol may be defined to provide separate information to individual decoding devices.
  • the decoding device may transmit signaling of the request of the decoding device to the multicast receiver using an IP unicast protocol. Therefore, it can be defined as a bidirectional protocol between the multicast receiver and the decoding device.
  • the multicast network controller may be connected to the multicast receiver via a multicast sender rather than directly to the multicast receiver.
  • the configuration related information of the network may be transmitted to the multicast sender and the multicast receiver.
  • the network controller may transmit configuration information about network resources, mapping information between nodes of the network, routing information, and the like.
  • the configuration information received from the operator controller may be transmitted to the multicast sender or the multicast receiver.
  • the multicast sender can forward the configuration message transmitted from the network controller to the multicast receiver.
  • a protocol or message set related to configuration may be distinguished from a protocol transmitted to a multicast sender and a protocol transmitted to a multicast receiver.
  • IP multicast may be used to deliver configuration messages from a single network controller to a plurality of multicast senders and multicast receivers. Connections, statistical information, etc. collected by the multicast sender and the multicast receiver may be reported to the multicast network controller. Since this process can be performed independently by each multicast sender and multicast receiver, a unicast protocol can be used. This set of control information, configuration information, etc. can be dynamically updated and transmitted immediately or through scheduling.
  • Information such as reports sent from the multicast receiver to the multicast network controller can be delivered to the multicast network controller through the multicast sender. That is, the multicast sender may forward a report message or the like transmitted from the multicast receiver to the multicast network controller.
  • the operation of other protocols may be applied in the same manner as the description of the above-described drawings.
  • a protocol and a packet format corresponding to each layer may be determined. Each protocol may be configured independently or specific protocols may be combined for interoperability.
  • the operation of compressing the video and audio data collected by the encoder, converting it into an appropriate codec, and delivering it to a packager may be performed as data processing inside the transmission system.
  • efficient codec can be used, codec such as HEVC (High Efficiency Video Coding), AVC (Advanced Video Coding) can be used for video data, and AAC (Advanced) for audio data. Audio Coding), AC4 (audio compression 4), Moving Picture Experts Group-H (MPEG-H) audio codec and the like can be used.
  • Each codec can be packaged in a form suitable for transmission or storage.
  • ISO base media file format ISOBMFF
  • CMAF Common Media Application Format
  • MPEG-2 TS Transport Stream
  • DRM Digital Rights Management
  • DRM Digital Rights Management
  • Media data configured in the form of a file may be applied with a protocol that can directly transfer a file such as FLUTE (File Delivery over Unidirectional Transport) according to a transmission method.
  • a protocol supporting adaptive streaming such as DASH (Dynamic Adaptive Streaming over HTTP) may be used.
  • the lower layer protocol may be applied according to the configuration of FLUTE or DASH. For example, if DASH is applied, HTTP may be applied as a lower layer protocol, or a DASH segment may be regarded as a file and FLUTE may be used as a lower layer protocol.
  • Transmission Control Protocol / Internet Protocol (TCP / IP) or User Datagram Protocol / Internet Protocol (UDP / IP) may be used depending on the configuration of the upper protocol.
  • IGMP Internet Group Management Protocol
  • Layer 2 and Layer 1 protocols may be defined for each transport link. That is, an optimized protocol may be configured according to a link between nodes and entities configured on a network. For example, in a LAN (Local Area Network) environment, Layer 2 may be defined as Ethernet, and Layer 1 may be defined as CSMA / CD (Carrier sense multiple access with collision detection) protocol.
  • the media delivery protocol illustrates a specific embodiment of the protocol according to a path through which media content is transmitted.
  • the multicast receiver is composed of the same devices and modules as the decoder (media player).
  • the protocols used on the server for content are the media codec and file format.
  • the media codec may include video, audio or other encoding formats.
  • the video may include a codec such as HEVC and AVC
  • the audio may include a codec such as AAC, AC4, and MPEG-H audio codec.
  • the protocol for the file format may be defined as a format for transmitting or storing the codec format in the form of a file.
  • file formats such as ISOBMFF and CMAF may be used, and may be transmitted using the format of MPEG-2 TS when the existing broadcast network is connected.
  • a plurality of formats may be used for streamlining the file format.
  • the protocol between the server and the multicast sender can mainly define a protocol for efficient delivery of file formats. Therefore, the data of the content generated in the server can be delivered using a tunneling protocol.
  • the tunneling protocol may mainly use a real-time transmission protocol such as RTP, and other IP-based tunneling protocols that may be used in the corresponding network. At this time, the existing protocol may be used as it is or the definition of the field may be changed to suit the network.
  • a tunneling protocol may be defined at an input terminal to receive a file transferred from the server using the tunneling protocol. In this case, since the file format transmitted using the tunneling protocol is data to be transmitted from the multicast sender to the multicast receiver, the tunneling protocol may operate regardless of the format of the corresponding data.
  • the protocol between the multicast sender and the multicast receiver can be defined primarily as a protocol for adaptive streaming. These protocols can be composed of DASH-based protocols.
  • the lower layer protocol is based on IP multicast.
  • a protocol such as HTTP may be used together for DASH to operate, and when a DASH segment is used as a file, a file transfer protocol such as FLUTE may be configured.
  • TCP / IP can be used for the connection and multicast transmissions on an effective network of the DASH / HTTP protocol.
  • Multicast receivers can use TCP / IP to receive packet streams sent in multicast.
  • the multicast receiver may use HTTP for a request for a packet stream, a response for received data, and the like.
  • the multicast receiver may include a DASH client. Data streamed adaptively using DASH consists of a file format sent by the server. Accordingly, the multicast receiver may use a file format related protocol capable of identifying the corresponding file format and a media codec capable of decoding the identified media format.
  • the media delivery protocol illustrates a specific embodiment of the protocol according to a path through which media content is transmitted.
  • This embodiment shows a case in which the multicast receiver is composed of a device or module separate from the decoder (media player). Therefore, the multicast receiver needs to transmit the received multicast stream to the decoding device (decoder).
  • Multicast receivers can use TCP / IP to receive packet streams sent in multicast.
  • the multicast receiver may use HTTP for a request for a packet stream, a response for received data, and the like.
  • the multicast receiver may include a DASH client.
  • the multicast receiver may act as a proxy for data adaptively streamed using DASH.
  • the multicast receiver can deliver data to the decoding device. Since the number of decoding devices connected to the multicast receiver can be limited, the connection can be based on unicast transmissions. Thus, multicast receivers can use the HTTP and TCP / IP protocols for unicast connections.
  • the decoding device may use a unicast protocol to receive data sent from the multicast receiver.
  • Data delivered via HTTP unicast may have a file format sent by the server.
  • the decoding device may use a file format related protocol capable of identifying the corresponding file format and a media codec capable of decoding the identified media format. Operation for other protocols is the same as the embodiment described in the previous drawings.
  • the method of transmitting the DASH segment may use the Quick UDP Internet Connections (QUIC) protocol.
  • QUIC Quick UDP Internet Connections
  • Multicast schemes using TCP / IP may incur delays in establishing connections and may not be suitable for immediate delivery of streaming data.
  • the QUIC-based protocol takes care of the connection and flow control at QUIC.
  • QUIC can use HTTP / 2, which can improve the transmission delay incurred by the existing HTTP, and can also immediately transmit streaming data using UDP / IP. Operation for other protocols is the same as the above-described embodiment.
  • the DASH system may be implemented by transmitting and receiving data between the HTTP server and the DASH client.
  • the DASH client may include a DASH access engine and a media engine.
  • an HTTP server can divide content of varying quality into segments on a regular basis and store them on the server.
  • the HTTP server may transmit the divided data unit by using the HTTP protocol when a media request of the DASH client which is a user device is performed.
  • it is possible to selectively transmit the media content stored in the HTTP server in various qualities. This allows the user to receive a seamless adaptive streaming service.
  • a separate file including information on a timeline order and a quality order of the divided files described above is a media presentation description (MPD).
  • the MPD may provide the DASH client with information about the media data stored on the HTTP server.
  • the MPD is an XML document and may include attributes such as URL, start time, content type, and the like assigned to the divided segment.
  • the DASH client may request the MPD file from the server prior to receiving the media file and receive the MPD file. When the MPD file is received, the DASH client may request a segment file for the content stored in the HTTP server by using the information about the media file included in the MPD.
  • the DASH segment is a data unit of a transport object that can be reproduced for a predetermined period by dividing the content to be transmitted into media segments.
  • the DASH media segment includes a 'styp' box indicating a segment type and a 'sidx' box containing segment index information.
  • the DASH media segment may include a 'mdat' box containing a media stream cut in fragment units and a 'moof' box containing metadata thereof.
  • the DASH client may request the transmission of the MPD file to request a service, and may request a media segment through each segment Uniform Resource Locator (URL).
  • the DASH client receives and parses an initialization segment (IS) file containing the initialization information, performs decoder initialization, and then receives the requested media segment file to perform media parsing and decoding. Can be.
  • IS initialization segment
  • Files received by the DASH client may be classified according to components for media playback.
  • the DASH client can play the media after receiving the manifest file, the MPD, the initialization segment file, and the media segment file. Therefore, the transmitting media encoder can encode mdat including media data for the entire play block (MPD + IS + sidx + moof + mdat) and generate a metadata header (styp + sidx + moof) containing the encoding information. have. Thereafter, the transmitting end may generate an IS.mp4 file, which is decoder initialization information, write the MPD including the URL information of the segment and transmit the same to the DASH client.
  • the parsing order of the receiving end is as follows. The receiving end may receive and parse the MPD file, initialize the decoder, and request a media segment according to network conditions.
  • FIG. 19 is a diagram illustrating a network configuration for multicast according to an embodiment of the present invention.
  • the multicast may be implemented without receiving the MPD file from the server. This may be referred to as MPD less method.
  • a multicast sender the DASH server
  • a delay may occur between generating DASH content for each quality and starting the DASH service.
  • a communication network in a user network is guaranteed bit-rate, it can support network conditions for a DASH service.
  • a method of locating the DASH server in the user network can be used. That is, up to the user network, the conventional multicast model may be maintained, and a form of transmitting packets immediately after generating the content network may be used.
  • the DASH server in the user network may collect the received packets to generate URLs of the segments, generate an MPD according to the DASH hierarchy, and perform a streaming service with the DASH client in the form of unicast.
  • the existing DASH server may be moved to the user network, and the DASH server may collect segment files received from the multicast sender and update the MPD to perform the service.
  • the content server preferentially creates HD class segments and starts transmission through the multicast sender, and the DASH server of the user network generates an MPD including information of the preferentially generated representation of the segment packets.
  • the multicast network controller may transmit control packets through synchronization and management of MPD timeslots from a service perspective.
  • the decoding device which is a DASH client, can receive unicast HTTP streaming according to the existing DASH model through the generated MPD. This enables fast service by changing only the home gateway or multicast receiver without changing the existing DASH client.
  • a segment may refer to a data unit capable of representing media data in an MPD.
  • a segment is media data divided corresponding to a byte range designated through a URL, and is a media file format transmitted from a server by an HTTP GET request.
  • the DASH client performs decoder initialization via an initialization segment (IS). Thereafter, the DASH client may obtain timed indexing information and media sample information about a sample included in a media fragment divided from a movie fragment box (moof) which is a metadata box. Finally, the DASH client may proceed with media decoding of the media samples in the media data box (mdat).
  • the initial segment may provide decoding initialization information, sample description information, and grouping information of the sample through a movie box (moov).
  • the moof box may provide a description of time indexing information of a media sample and a grouped media sample up to a range of media fragments defined by the moof box.
  • Media samples may be grouped using group_type in a Sample to Group Box ('sbgp' box) included in a moov box.
  • the sbgp box is as shown in the Figure break.
  • Adaptive streaming such as DASH and Http Live Streaming (HLS)
  • HLS Http Live Streaming
  • a media segment file that can be transmitted first may be transmitted using an existing multicast model.
  • a manifest (ex. MPD) file can be created to play the media segment file that was sent first. That is, according to the existing multicast model, when the multicast data is cached to the multicast receiver or proxy in the multicast ABR model or the unicast packets that can be received are cached, the multicast receiver is based on a specific point in time. Alternatively, you can create an MPD in the proxy.
  • a DASH segment stored in a plurality of qualities provides a linear service
  • segments corresponding to the plurality of qualities must be sequentially transmitted to the IP network, which may cause a service delay.
  • fast data reception and some media segments may be preferentially received for quick playback.
  • priority of packet transmission may be defined in consideration of the size of data and the reception time in a reproducible unit. This speeds up the rendering of the playable unit due to the packet transmission according to the priority, thereby lowering the start delay.
  • the segment to be transmitted may be generated according to the inspectionrating order shown and may be transmitted according to the transport block. Since the media segment has a longer segment length as Quality increases, a delay may occur in generating and transmitting an entire segment. Therefore, it is necessary to separately create and transmit a segment that can be quickly started among the segments.
  • data created according to the generated block must be partially packetized according to the transport object and transmitted. To this end, the packet may transmit an object including only I frames capable of RAP, not the entire sequence. As shown, after generating 1,2,3,4,5,6 according to the generating order, the transport object may be configured to include only I frames.
  • the receiving end may perform decoding through the RAP immediately after receiving the transmitting object. Thereafter, the transmitting end may continuously transmit an object including the remaining media chunk packets to enable playback of subsequent frames of the receiving end.
  • the mode of transmitting a transport object selectively including only the I frame described above is called a fast startup mode, and for this purpose, a multicast ABR may be implemented by extending the protocol.
  • the transmitting end transmits the media data in units of transport packets
  • the receiving end may collect the received media data and generate a DASH segment or playable file through the playable object, and may start playback thereof.
  • the transmitting end may selectively include only a frame (I frame) that can be quickly reproduced among a plurality of frames in the media data packet, and transmit the first priority to reduce the startup delay time of the receiving end.
  • sample grouping in the moov box may be extended.
  • the receiving end collects the frames in the order in which they are received, and may start decoding as soon as the grouped frames are collected. Accordingly, even if the entire GOP (group of picture) or mdat is not received, the receiver can start decoding immediately to reduce delay by receiving only a decodable unit.
  • the transmitting end may transmit a group of independently decodable I frames I0 among samples to be transmitted.
  • the receiving end can start decoding immediately when the decoding header information (IS and moof) of the segment and the samples of the group entry arrive.
  • the transmitting end can group and transmit the frames of B2, B3, B4 and P1 for unidirectional prediction, and the receiving end can decode the group when B2, B3, B4, and P1 arrive.
  • CRA clean random access
  • the receiver may immediately start decoding up to the frames of I5, B6, B7, and B8 when frames B6, B8, and I5 are received based on the sample grouping information in moov.
  • frames up to P can be decoded so that only grouped entries can be played without receiving the entire file. It is possible in advance.
  • the following is information to play an entry without receiving the whole file.
  • the dependency_sample_number field described below refers to a sample that must be held in the video decoding buffer so that only the grouped group entries can be reproduced in advance even when all the files are not received.
  • the transmitting end may include the sample grouping information in the sample group description box (sgpd) included in the moov box and transmit the sample grouping information.
  • Sample grouping information may be included in an fssg box in sgpd. A detailed description of the fssg box is provided below.
  • the transmitting end may perform sample grouping in the unit of the movie fragment cut through the moof. Since sample grouping is performed in a decodable unit, fast startup is possible even before all data is received, thereby reducing delay.
  • the transmitter may transmit the sample grouping information in the sgpd box included in the moof box. Sample grouping information may be included in an fssg box in sgpd.
  • the syntax structure of the fssg box is as shown.
  • the fssg box may include at least one of the group_entry_number, group_entry_offset, Delivery_event, Dependency_count, and dependency_sample_number fields.
  • the group_entry_number field may indicate the order of a decoding group in which the grouped samples are ordered in the entire sample sequence.
  • the Group_entry_offset field may represent an offset value for the first position of the group in decoding order.
  • the Delivery_event field may define an attribute of a media event that each group has.
  • Delivery_event has a value of 0x0, it is default; if it has a value of 0x1, it is a normal picture group; if it has a value of 0x2, it is a group containing an instantaneous decoding refresh (IDR) picture; if it has a value of 0x3, it is a CRA picture It may represent a group including.
  • the Dependency_count field may indicate the number of picture / samples included in each group.
  • the dependency_sample_number field may mean a sample that must be held in the video decoding buffer for decoding in the corresponding group. That is, the dependency_sample_number field means a sample that must be held in the video decoding buffer so that only the grouped group entries can be reproduced in advance even when all the files are not received.
  • the transmitting end performs the encoding and file format generation of the media data and then starts the transmission. That is, as described with reference to FIG. 21, the transmitting end generates segment files in the order of encoding the media data corresponding to mdat and creating a file format header including synchronization information and attribute information of the media data.
  • the transmitting end may generate the file format header only after all of the media data has been encoded. Therefore, a problem arises in that the transmission does not start until the encoding of the entire media data is completed. This may increase the end to end delay time. Therefore, when the method of reducing the media frame transmission interval is used, the receiver can perform rendering even before the entire media data is received at the receiver. This is described below.
  • the method described with reference to FIG. 22 is a method in which a receiver starts decoding a frame corresponding to a received specific group by using sample grouping information included in moov or moof in a segment. That is, after the entire media data is generated at the transmitter, this method generates sample grouping information for the entire media data, thereby reducing the decoding delay of the receiver.
  • the transmitter instead of encoding and transmitting all media frames of a segment covered by one moof, the transmitter transmits the data in a meaningful unit.
  • moof may indicate a range in which a frame can be presented through a sample number starting point, an offset, and a duration.
  • the receiver can perform fast decoding. That is, as shown, the transmitting end grouping the frame I0 to transmit with the first moof, grouping B2, B3, B3 and P1 with the second moof, grouping B6, B7, B8 and I5 to the first Can be sent with 3 moof.
  • the transmission unit at the transmitting end may be defined as a sample grouping unit, and a moof may be generated and transmitted for each sample group, thereby reducing delay due to encoding of the entire media data.
  • composition_time_offset may be defined in the ISOBMFF trun box. If the process of the transmitter and the receiver of Figs. 22 and 23 make a timeline as shown in the lower part of the figure. The in order method encodes all the media data, creates a moof to operate the media frame, and then delivery begins.
  • the receiver In the case of the normal play method, the receiver generates all the samples up to 56 and then plays them.
  • the receiving end can play even before all of the sample grouping information-based files according to the decoding dependency arrive. In other words, as shown in the drawing, a group including an I frame that can be decoded immediately can be started quickly. Normal play and in order sample grouping methods can be delivered at the same time.
  • the delivery time may be advanced.
  • the transmitting end may transmit the generated moof immediately. That is, even before the entire media data is encoded, transmission can be started when the first sample group and the first moof are generated. Because of this, out order sample grouping provides the effect of reducing the encoding delay.
  • an embodiment of the present invention may provide an effect of shortening an encoding delay up to a transmission point by generating and inserting a plurality of moofs for each sample group. .
  • the transmitting end may generate a moof for the frame of the first sample group in parallel with generating the frame of the second sample group.
  • the generated moof may be transmitted after the frame of the first sample group is transmitted as shown in the embodiment, or may be transmitted before.
  • the receiving end can decode the frame in advance as compared to the in order sample grouping method.
  • the receiving end may reduce latency and perform fast decoding.
  • encoding delay can be reduced by encoding sample or video and transmitting it in advance without header. Accordingly, the above described short period moof may be generated and transmitted corresponding to the sample grouping period.
  • the movie fragment encoding time according to the embodiment of the present invention may be shorter than the existing movie fragment encoding time.
  • the receiver may receive video data belonging to the sample group and play the video data through the sample grouping information in the moof.
  • FIG. 24 is a diagram illustrating extension of a decoder configuration record according to an embodiment of the present invention.
  • an initialization segment IS
  • the transmitting end should inform the decoder that the sample grouping and buffering mode has been applied. That is, to the decoder, the initialization information that decoding processing through buffering is possible must be delivered, and the IS can be used for this. Therefore, by adding information about the buffering model to the IS, the decoder can be initialized to perform the buffering model for low latency.
  • This information may be defined in an HEVC decoder configuration record (D.C.R) that defines configuration information about a property of a sample in the 14496-15 HEVC file format.
  • the HEVC decoder configuration record may include decoder initialization information (HEVC video VPS, SPS, PPS) contents of a sample, and may include video chroma, luma property, and HDR transfer characteristic information.
  • the HEVC decoder configuration record information may be included in sample entry information of an HEVC Configuration Box (hvcC) included in a sample description box (stsd) that provides a description of samples, as shown at the top of the figure.
  • the HEVC decoder configuration record may include information of a media event.
  • the information of the media event may be defined in the initialization segment as initialization information indicating that a property of a currently transmitted stream is a buffering mode for low latency. That is, the media event included in the sample description in the IS may inform the decoder that the data to which the buffering mode for low latency described above is received in initializing the receiver decoder.
  • FIG. 25 is a diagram illustrating a comparison of a playable time point using a sample grouping method according to an embodiment of the present invention.
  • the simulation conditions were based on 4k HEVC video, 56 GoP 56 samples, mdat of 2571475 bytes, and a data rate of 25 Mbps.
  • the sender Encoder & server side
  • the receiver side in order
  • the reception time required for this, that is, the time at which playback could start was 0.82 sec.
  • the sample group entry is set to 8 entries under the same conditions. That is, one sample group is composed of eight samples, and the sample groups are grouped using the decoding dependency as described above. Therefore, if only eight samples included in one group are received, the receiver can start decoding. Accordingly, even if the entire GOP (group of picture) or mdat is not received, the receiver can start decoding immediately to reduce delay by receiving only a decodable unit.
  • the sender (Encoder & server side) of the sample grouping (In order) method creates and transmits a moof after all 56 samples are generated.
  • the effect of sample grouping can be confirmed at the receiving end.
  • the receiver side receives the moof and can start playback upon receiving the first sample, the I frame.
  • all samples from the first to eighth samples corresponding to the first group are received, they can be immediately decoded and played.
  • playback of the second sample group can also be started.
  • the receiver using the sample grouping (In order) method could start playback at 0.3 sec, 0.38 sec, 0.46 sec, 0.53 sec, 0.61 sec, 0.68 sec, 0.75 sec, and 0.82 sec, respectively. Therefore, through the sample grouping, the receiver provided the effect of starting playback whenever the reception of the samples belonging to each sample group was completed, thereby reducing latency.
  • FIG. 26 illustrates a comparison of a playable time point using a sample grouping method according to an embodiment of the present invention.
  • FIG. In this figure, the playback start time between the sample grouping (out order) method, the sample grouping (in order) method, and the normal playing method is compared.
  • the transmitter of the sample grouping (out order) method completes encoding of the first sample, it generates moof1 for the first sample while encoding the second sample.
  • the transmitting end encodes the sixteenth sample and generates moof2 for the second sample group. In this way, the transmitter can generate moofs for each sample group.
  • the transmitting end may start delivery when moof1 is generated.
  • the receiving end can start decoding and playing when the first sample and moof1 are received. Since the first sample is an I frame, the receiver decoder may perform instantaneous decoding refresh (IDR) playback. Also, when the samples belonging to the first sample group and moof2 are received, playback of the corresponding sample group can also be started.
  • IDR instantaneous decoding refresh
  • the sender of the sample grouping (in order) method of drawing interruption Since the sender of the sample grouping (in order) method of drawing interruption generates and transmits the encoding for all samples and the moof for all samples, the first moof reception time of the receiver is slower than the out order method.
  • the receiving end can start IDR playback upon receiving the moof and the first sample. Compared with the out order method, a playback start time difference of 0.5 sec occurred.
  • the Normal playing scheme at the bottom of the figure can start IDR playback after the reception of the moof and the entire 56 samples is complete. Comparing this with the out order method, a reproduction start time difference of 1 sec occurred.
  • the receiver may receive a broadcast signal or a multicast signal using a tuner.
  • the receiver may convert an analog signal into a digital signal using an analog digital converter (ADC) and demodulate the received signal using a demodulator.
  • Receiver is channel sync.
  • the & EQ may be used to perform synchronization and equalization on the received signal, and the channel decoder may be used to decode the received signal.
  • the decoded signal is parsed by a layer 1 signaling parser so that the receiver can obtain L1 signaling information.
  • the L1 signaling information may be delivered to the baseband controller of the receiver and used to acquire physical layer data. In addition, the L1 signaling information may be input to the signaling controller of the receiver.
  • the decoded signal may be input to the link layer interface and parsed by the L2 signaling parser, and the L2 signaling information may be input to the signaling controller.
  • the signaling controller may communicate with a service signaling channel (ssc) processing buffer and a parser, thereby updating a service MAP DB.
  • the service guide (SG) processor may update the service guide DB.
  • the receiver may restore the packet header according to the signaling information input to the signaling controller and receive the IP packet using the IP packet filter.
  • the network switch of the receiver may receive an IP packet through wired or wireless communication, and may receive it through a TCP / IP stack. The received IP packet is input to the A / V service controller via the common protocol stack.
  • the demultiplexer of the receiver can demultiplex audio and video data.
  • the receiver may output audio data using an audio decoder and an audio renderer, and output video data using a video decoder and a video renderer.
  • the content server may include an encoder d28010 and a transmitter d28020, and the content receiver may include a receiver d28030 and a decoder d28040.
  • the content server may generate content using the encoder d29010 and may group the samples of the generated content based on the decoding dependency as described in the previous drawings.
  • the encoder of the content server may include grouping information about the grouped samples in the moov box or the moof box of the ISOBMFF file. The samples grouped in this way may be transmitted in an in order or out order method of the sample grouping method.
  • the encoder may generate a moof for each sample group for a sample out order method.
  • the encoder can transmit information including the information indicating that it supports the sample grouping and buffering mode supporting low latency.
  • the content server may transmit the media sample and the metadata using the transmitter d29020.
  • the content receiver may receive the media data from the content server using the receiver d28030.
  • the receiver d28030 of the content receiver may receive media samples and metadata included in the media data.
  • media samples may be grouped and received with sample grouping information.
  • the decoder d28040 may start decoding and playing according to a sample grouping method. As described with reference to FIG. 26, the decoder may start playback when the first sample and the moof of the I frame are received, and thereafter, playback may be started for the corresponding sample group whenever each sample group is received.
  • the content server may encode the media sample (ds29010).
  • Media samples can be encoded in mdat in the ISOBMFF file format.
  • the content server may generate metadata that includes sample grouping information for the encoded media sample.
  • the metadata may be transmitted in a moof box or a moov box of ISOBMFF.
  • Sample grouping information may be generated based on decoding dependencies between encoded media samples.
  • the content server may generate and transmit a moof for each sample group generated by the sample grouping. In this case, when the moof is generated for each sample group, the content server may start transmission for the sample group.
  • the content server may transmit information indicating to the IS that it supports sample grouping and buffering mode supporting low latency.
  • the content server may transmit encoded media samples and metadata (ds29030).
  • the content receiver may receive media data from the content server (ds30010).
  • the media data may be in ISOBMFF file format and may include metadata and media samples.
  • the metadata may include sample grouping information, and the sample grouping information may be transmitted in a moof box or a moov box.
  • the content receiver may obtain sample grouping information from metadata included in the media data (ds30020).
  • the content receiver may buffer a particular media sample based on the sample grouping information.
  • the content receiver may decode media samples using the sample grouping information (ds30030). Through this, the content receiver can reduce decoding latency by decoding each sample group even before the entire GoP or the entire mdat is received.
  • the load on the network can be reduced by switching the existing unicast transmission to multicast.
  • Apparatus and method according to the present invention is not limited to the configuration and method of the embodiments described as described above, the above-described embodiments may be selectively all or part of each embodiment so that various modifications can be made It may be configured in combination.
  • the image processing method of the present invention can be implemented as a processor-readable code on a processor-readable recording medium provided in the network device.
  • the processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor. Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet. .
  • the processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.
  • the present invention has industrial applicability that is usable and repeatable in the field of broadcast and video signal processing.

Landscapes

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

Abstract

La présente invention concerne un procédé et un dispositif pour transmettre et recevoir des données multimédia. Le dispositif pour transmettre des données multimédia, selon un mode de réalisation, comprend un encodeur pour encoder des échantillons multimédia et générer des métadonnées qui comprennent des informations de regroupement d'échantillons sur les échantillons multimédia encodés, et une étape de transmission des échantillons multimédia encodés et des métadonnées générées, les informations de regroupement d'échantillons indiquant, sur la base de la dépendance de décodage des échantillons multimédia, chaque groupe d'échantillons qui comprend au moins un échantillon multimédia.
PCT/KR2017/013110 2017-04-05 2017-11-17 Procédé et dispositif pour transmettre et recevoir un signal de diffusion WO2018186550A1 (fr)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US201762481706P 2017-04-05 2017-04-05
US62/481,706 2017-04-05
US201762482204P 2017-04-06 2017-04-06
US62/482,204 2017-04-06
US201762484902P 2017-04-13 2017-04-13
US62/484,902 2017-04-13
US201762492164P 2017-04-29 2017-04-29
US62/492,164 2017-04-29

Publications (1)

Publication Number Publication Date
WO2018186550A1 true WO2018186550A1 (fr) 2018-10-11

Family

ID=63712169

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/013110 WO2018186550A1 (fr) 2017-04-05 2017-11-17 Procédé et dispositif pour transmettre et recevoir un signal de diffusion

Country Status (1)

Country Link
WO (1) WO2018186550A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040088541A (ko) * 2002-02-25 2004-10-16 소니 일렉트로닉스 인코포레이티드 Ｍｐ4에서 ａｖｃ를 지원하기 위한 방법 및 장치
KR20080006609A (ko) * 2005-04-13 2008-01-16 노키아 코포레이션 스케일링가능성 정보의 코딩, 저장, 및 시그널링
KR20120083744A (ko) * 2011-01-18 2012-07-26 삼성전자주식회사 멀티미디어 스트리밍 시스템에서 컨텐트의 저장 및 재생을 위한 장치 및 방법
KR20160034952A (ko) * 2013-07-23 2016-03-30 캐논 가부시끼가이샤 코딩 종속성들에 대한 일반 시그널링을 이용하여 분할된 시간 설정형 미디어 데이터를 캡슐화하는 방법, 디바이스 및 컴퓨터 프로그램
US20160198207A1 (en) * 2013-07-22 2016-07-07 Sony Corporation Information processing apparatus and method

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040088541A (ko) * 2002-02-25 2004-10-16 소니 일렉트로닉스 인코포레이티드 Ｍｐ4에서 ａｖｃ를 지원하기 위한 방법 및 장치
KR20080006609A (ko) * 2005-04-13 2008-01-16 노키아 코포레이션 스케일링가능성 정보의 코딩, 저장, 및 시그널링
KR20120083744A (ko) * 2011-01-18 2012-07-26 삼성전자주식회사 멀티미디어 스트리밍 시스템에서 컨텐트의 저장 및 재생을 위한 장치 및 방법
US20160198207A1 (en) * 2013-07-22 2016-07-07 Sony Corporation Information processing apparatus and method
KR20160034952A (ko) * 2013-07-23 2016-03-30 캐논 가부시끼가이샤 코딩 종속성들에 대한 일반 시그널링을 이용하여 분할된 시간 설정형 미디어 데이터를 캡슐화하는 방법, 디바이스 및 컴퓨터 프로그램

Similar Documents

Publication Publication Date Title
WO2018174367A1 (fr) Procédé et dispositif de transmission et de réception de signal de diffusion
US8495688B2 (en) System and method for fast start-up of live multicast streams transmitted over a packet network
Schierl et al. System layer integration of high efficiency video coding
WO2013169084A1 (fr) Procédé de transmission hybride par extension de format de paquets mmt
WO2012128563A2 (fr) Dispositif et procédé d'émission/réception de contenu radiodiffusé lié grâce à un réseau hétérogène
WO2013077698A1 (fr) Procédé de liaison de média mmt et de média dash
WO2013077697A1 (fr) Procédé de fourniture hybride d'ensemble mmt et de contenu et procédé de réception de contenu
US20110219414A1 (en) Method, apparatus, and system for switching channels
WO2012099423A2 (fr) Appareil et procédé permettant de configurer un message de commande dans un système de diffusion
WO2013162312A1 (fr) Procédé et appareil permettant l'émission-réception de données destinées à un système de transmission multimédia
WO2012060581A2 (fr) Procédé d'émission/réception de contenu multimédia et dispositif d'émission/réception l'utilisant
WO2013141666A1 (fr) Procédé de transmission et procédé de réception hybrides pour un contenu vidéo svc empaqueté dans un mmt
KR20140002026A (ko) 파일 전달 방법들을 이용한 ｉｐ 브로드캐스트 스트리밍 서비스 배포
WO2016129981A1 (fr) Procédé et dispositif de transmission/réception de données multimédias
JP2006166418A (ja) 連続的なビデオディスプレイのためのビデオデータの送信方法及び受信方法
WO2009039741A1 (fr) Procédé et dispositif permettant la commutation de chaînes iptv
US20070297448A1 (en) Method and apparatus for instant channel change
WO2011159093A2 (fr) Mécanisme de fourniture hybride dans un système de transmission multimédia
US20110088069A1 (en) Network device, information processing apparatus, stream switching method, information processing method, program, and content distribution system
KR100948686B1 (ko) 채널 전환시 지연을 줄이기 위한 ｉｐｔｖ 방송 시스템,가속 채널 스트림의 생성 및 재생방법
WO2013187667A1 (fr) Procédé d'adaptation de débit utilisant un taux d'erreur sur les bits pour un service multimédia et appareil associé
WO2018186550A1 (fr) Procédé et dispositif pour transmettre et recevoir un signal de diffusion
WO2018164355A1 (fr) Procédé et dispositif de transmission/réception de signal en multidiffusion
WO2016043432A1 (fr) Procédé et appareil permettant de transmettre ou de recevoir un contenu multimédia
WO2014010830A1 (fr) Procédé et appareil de transmission et de réception de paquets dans un service de transmission hybride de mmt

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: 17904747

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17904747

Country of ref document: EP

Kind code of ref document: A1