WO2018186550A1 - 방송 신호 송수신 방법 및 장치 - Google Patents

방송 신호 송수신 방법 및 장치 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)
French (fr)
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/ko

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

본 발명은 미디어 데이터를 송수신하는 장치 및 방법에 관한 것이다. 본 발명의 일 실시예에 따른 미디어 데이터 송신 장치는, 미디어 샘플들을 인코딩하고 상기 인코딩된 미디어 샘플들에 대한 샘플 그룹핑 정보를 포함하는 메타데이터를 생성하는 인코더, 및 상기 인코딩된 미디어 샘플들 및 상기 생성된 메타데이터를 전송하는 단계를 포함하고, 상기 샘플 그룹핑 정보는 상기 미디어 샘플들의 디코딩 디펜던시에 기초하여 적어도 하나의 미디어 샘플을 포함하는 샘플 그룹 각각을 나타내는 정보인 것을 특징으로 한다.

Description

방송 신호 송수신 방법 및 장치
본 발명은 방송 신호를 송수신하는 장치 및 방법에 관한 것이다.
디지털 기술 및 통신 기술의 발전으로 방송, 영화뿐만 아니라 인터넷 및 개인 미디어 등의 다양한 영역에서 오디오/비디오 중심의 멀티미디어 컨텐츠 보급 및 수요가 급속도로 확대되고 있다. 또한, 디스플레이 기술의 발전과 더불어 가정에서의 TV 화면이 대형화 됨에 따라 UHD (Ultra High Definition) 방송 서비스에 대한 논의가 증가되고 있는 추세이다.
방송 서비스와 관련하여, 복수의 사용자에게 동일한 컨텐츠를 전송하는 멀티캐스트 (multicast) 전송 방식은 유니캐스트 (unicast)와 브로드캐스트 (broadcast)의 장점을 모두 활용할 수 있으므로 효과적이다. 하지만, 기존의 멀티캐스트 전송 방식은 단일 네트워크 내에서만 가능했으며 이종망 간의 멀티캐스트 서비스가 불가능한 단점이 있었다. 또한 실시간 IP 멀티캐스트 방송환경에서 파일 기반 멀티캐스트 컨텐츠를 전송하는 경우, 수신기의 초기화 및 AV (audio/video) startup 동작에 긴 시간이 소요되는 단점이 있었다.
본 발명의 목적은, 방송 신호를 전송하는 방법 및 장치에 있어서 전송 효율을 높이는 것이다.
본 발명의 다른 목적은, 멀티캐스트 서비스를 방송망에서 제공하기 위한 전송 장치 및 방법을 제공하는 것이다.
본 발명의 다른 목적은, 멀티캐스트 서비스에 대한 수신기에서의 재생을 신속하게 시작하기 위한 장치 및 방법을 제공하는 것이다.
본 발명의 일 실시예에 따른 미디어 데이터 송신 방법은 미디어 샘플들을 인코딩하는 단계, 상기 인코딩된 미디어 샘플들에 대한 샘플 그룹핑 정보를 포함하는 메타데이터를 생성하는 단계, 및 상기 인코딩된 미디어 샘플들 및 상기 생성된 메타데이터를 전송하는 단계를 포함하고, 상기 샘플 그룹핑 정보는 상기 미디어 샘플들의 디코딩 디펜던시에 기초하여 적어도 하나의 미디어 샘플을 포함하는 샘플 그룹 각각을 나타내는 정보인 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 미디어 데이터 송신 방법에서 상기 미디어 샘플 및 상기 메타데이터는 ISOBMFF (ISO base media file format) 파일 형식으로 인코딩될 수 있다.
또한 본 발명의 일 실시예에 따른 미디어 데이터 송신 방법에서 상기 샘플 그룹핑 정보는 상기 ISOBMFF 파일 내의 무비 프래그먼트 박스 (movie Fragment Box, moof) 또는 무비 박스 (Movie box, moov)에 포함될 수 있다.
또한 본 발명의 일 실시예에 따른 미디어 데이터 송신 방법에서 상기 메타데이터를 생성하는 단계는 상기 샘플 그룹마다 무비 프래그먼트 박스 (movie Fragment Box, moof) 생성하는 것을 특징으로 할 수 있다.
본 발명의 일 실시예에 따른 미디어 데이터 송신 장치는 미디어 샘플들을 인코딩하고 상기 인코딩된 미디어 샘플들에 대한 샘플 그룹핑 정보를 포함하는 메타데이터를 생성하는 인코더, 및 상기 인코딩된 미디어 샘플들 및 상기 생성된 메타데이터를 전송하는 송신부를 포함하고, 상기 샘플 그룹핑 정보는 상기 미디어 샘플들의 디코딩 디펜던시에 기초하여 적어도 하나의 미디어 샘플을 포함하는 샘플 그룹 각각을 나타내는 정보인 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 미디어 데이터 송신 장치에서 상기 미디어 샘플 및 상기 메타데이터는 ISOBMFF (ISO base media file format) 파일 형식으로 인코딩될 수 있다.
또한 본 발명의 일 실시예에 따른 미디어 데이터 송신 장치에서 상기 샘플 그룹핑 정보는 상기 ISOBMFF 파일 내의 무비 프래그먼트 박스 (movie Fragment Box, moof) 또는 무비 박스 (Movie box, moov)에 포함될 수 있다.
또한 본 발명의 일 실시예에 따른 미디어 데이터 송신 장치에서 상기 메타데이터를 생성하는 단계는 상기 샘플 그룹마다 무비 프래그먼트 박스 (movie Fragment Box, moof) 생성하는 것을 특징으로 할 수 있다.
본 발명의 일 실시예에 따른 미디어 데이터 수신 방법은 미디어 데이터를 수신하는 단계, 상기 미디어 데이터에 포함된 샘플 그룹핑 정보를 획득하는 단계, 및 상기 샘플 그룹핑 정보를 이용하여 미디어 샘플을 디코딩하는 단계를 포함하고, 상기 샘플 그룹핑 정보는 상기 미디어 샘플들의 디코딩 디펜던시에 기초하여 적어도 하나의 미디어 샘플을 포함하는 샘플 그룹 각각을 나타내는 정보인 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 미디어 데이터 수신 방법에서 상기 미디어 데이터는 ISOBMFF (ISO base media file format) 파일 형식인 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 미디어 데이터 수신 방법에서 상기 샘플 그룹핑 정보는 상기 미디어 데이터 내의 무비 프래그먼트 박스 (movie Fragment Box, moof) 또는 무비 박스 (Movie box, moov)에 포함된 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 미디어 데이터 수신 방법에서 상기 메타데이터는 상기 샘플 그룹마다 생성된 무비 프래그먼트 박스 (movie Fragment Box, moof)를 포함하는 것을 특징으로 할 수 있다.
본 발명의 일 실시예에 따른 미디어 데이터 수신 장치는 미디어 데이터를 수신하는 수신부, 및 상기 미디어 데이터에 포함된 샘플 그룹핑 정보를 획득하고 상기 샘플 그룹핑 정보를 이용하여 미디어 샘플을 디코딩하는 디코더를 포함하고, 상기 샘플 그룹핑 정보는 상기 미디어 샘플들의 디코딩 디펜던시에 기초하여 적어도 하나의 미디어 샘플을 포함하는 샘플 그룹 각각을 나타내는 정보인 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 미디어 데이터 수신 장치에서 상기 미디어 데이터는 ISOBMFF (ISO base media file format) 파일 형식이고, 상기 샘플 그룹핑 정보는 상기 미디어 데이터 내의 무비 프래그먼트 박스 (movie Fragment Box, moof) 또는 무비 박스 (Movie box, moov)에 포함된 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 미디어 데이터 수신 장치에서 상기 메타데이터는 상기 샘플 그룹마다 생성된 무비 프래그먼트 박스 (movie Fragment Box, moof)를 포함하는 것을 특징으로 할 수 있다.
본 발명의 실시예에 따르면, 방송 시스템의 전송 효율을 높일 수 있다.
본 발명의 실시예에 따르면, 이종망 간에 멀티캐스트 서비스를 제공할 수 있다.
본 발명의 실시예에 따르면, 멀티캐스트 서비스에 대한 수신기에서의 재생을 신속하게 시작할 수 있다.
도 1은 본 발명의 일 실시예에 따른 네트워크 구조를 나타낸 도면이다.
도 2는 본 발명의 일 실시예에 따른 컨텐트 네트워크를 나타낸 도면이다.
도 3은 본 발명의 일 실시예에 따른 컨텐트 네트워크가 위성 릴레이 (satellite realy)를 포함하는 경우를 나타낸 도면이다.
도 4는 본 발명의 일 실시예에 따른 컨텐트 네트워크가 컨텐트 딜리버리 네트워크 (CDN)를 포함하는 경우를 나타낸 도면이다.
도 5는 본 발명의 일 실시예에 따른 유선 (wired) 멀티캐스트 네트워크를 나타낸 도면이다.
도 6은 본 발명의 일 실시예에 따른 모바일 멀티캐스트 네트워크를 나타낸 도면이다.
도 7은 본 발명의 일 실시예에 따른 유저 네트워크를 나타낸 도면이다.
도 8은 본 발명의 일 실시예에 따른 ABR 멀티캐스트를 위한 네트워크 구조를 나타낸 도면이다.
도 9는 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다.
도 10은 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다.
도 11은 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다.
도 12는 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다.
도 13은 본 발명의 일 실시예에 따른 IP network를 통해 미디어 데이터를 전송하기 위한 프로토콜을 나타낸 도면이다.
도 14는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다.
도 15는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다.
도 16은 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다.
도 17은 본 발명의 일 실시예에 따른 DASH 전송 방식을 나타낸다.
도 18은 본 발명의 일 실시예에 따른 DASH 세그먼트의 구조를 나타낸 도면이다.
도 19는 본 발명의 일 실시예에 따른 멀티캐스트를 위한 네트워크 구성을 나타낸 도면이다.
도 20은 본 발명의 일 실시예에 따른 DASH 초기화 세그먼트(initialization segment)의 구조를 나타낸다.
도 21은 본 발명의 일 실시예에 따른 DASH 세그먼트를 발생하는 과정을 나타낸 도면이다.
도 22는 본 발명의 일 실시예에 따른 moov 내에서의 디코딩 샘플 그룹핑을 나타낸 도면이다.
도 23은 본 발명의 일 실시예에 따른 샘플 그룹핑 moof를 나타낸 도면이다.
도 24는 본 발명의 일 실시예에 따른 디코더 configuration 레코드(decoder configuration record)의 확장을 나타낸 도면이다.
도 25는 본 발명의 일 실시예에 따른 샘플 그룹핑 방식을 이용한 재생 가능 시점에 대한 비교를 나타낸 도면이다.
도 26은 본 발명의 일 실시예에 따른 샘플 그룹핑 방식을 이용한 재생 가능 시점에 대한 비교를 나타낸 도면이다.
도 27은 본 발명의 일 실시예에 따른 수신기 구조를 나타낸 도면이다.
도 28은 본 발명의 일 실시예에 따른 컨텐트 서버 및 컨텐트 리시버를 나타낸 도면이다.
도 29는 본 발명의 일 실시예에 따른 컨텐트 서버의 동작 방법을 나타낸다.
도 30은 본 발명의 일 실시예에 따른 컨텐트 리시버의 동작 방법을 나타낸다.
도 1은 본 발명의 일 실시예에 따른 네트워크 구조를 나타낸 도면이다. 도 1에 도시된 바와 같이, 어댑티브 미디어 스트리밍 (Adaptive Media Streaming)을 위한 네트워크는 컨텐트 네트워크 (Content Network), 어댑티브 비트 레이트 (Adaptive Bit Rate, ABR) 멀티캐스트 네트워크 (ABR Multicast Network) 및 유저 네트워크 (User Network)를 포함할 수 있다. 이는 인터넷 프로토콜 (Internet Protocol, IP) 기반의 멀티캐스트 네트워크 (Multicast Network)에서, 어댑티브 미디어 스트리밍을 지원하기 위해 사용되는 네트워크들을 기능별로 구분한 것이다. 또한 각각의 네트워크는 어댑티브 미디어 스트리밍 이외의 다른 기능을 지원하기 위한 부가적인 네트워크에 접속할 수 있다. 예를 들면 컨텐트 네트워크와 유저 네트워크는 유니캐스트 서비스를 위한 유니캐스트 네트워크에 각각 접속할 수 있다.
유저 네트워크는 ABR 멀티캐스트 네트워크에게 수신하고자 하는 컨텐트에 대한 요청(request), 보고 (report), 피드백 (feedback)을 전송할 수 있다. ABR 멀티캐스트 네트워크는 유저 네트워크로부터 수신된 정보에 기초하여 컨텐트 네트워크에게 요청(request), 보고 (report), 피드백 (feedback)을 전송할 수 있다. 컨테트 네트워크는 ABR 멀티캐스트 네트워크로부터 수신된 정보에 기초하여, 멀티 캐스 컨텐트 및 시그널링 정보를 ABR 멀티캐스트 네트워크에게 전송할 수 있다. ABR 멀티캐스트 네트워크는 수신된 멀티 캐스 컨텐트 및 시그널링 정보를 유저 네트워크에게 전송하여 멀티캐스트 서비스를 제공할 수 있다.
도 2는 본 발명의 일 실시예에 따른 컨텐트 네트워크를 나타낸 도면이다. 컨텐트 네트워크 (Content Network)는 어댑티브 멀티캐스트 스트리밍 (adaptive multicast streaming)을 위한 컨텐트의 생성, 수집, 패키징 (packaging) 등의 기능을 담당할 수 있으며, 다양한 컨텐트 소스 (contents source)를 포함할 수 있다. 컨텐트 네트워크는 방송 컨텐트를 서비스 하기 위해, 지상파 (terrestrial) 및 케이블 (cable) 방송 등을 서비스 하는 방송국 (broadcaster)의 헤드 엔드 (head-end)를 포함할 수 있다. 방송국 헤드 엔드는 컨텐트 프로덕션에서 생성된 컨텐트를 인코딩하는 인코더, 인코딩된 컨텐트를 변환하는 packager, 컨텐트를 저장하는 컨텐트 서버 중 적어도 하나를 포함할 수 있다.
또한, 컨텐트 네트워크는 지리적으로 멀리 떨어진 지역으로부터 제작된 서비스를 수신하기 위한 위성 수신 네트워크를 더 포함할 수 있다. 또한 미리 저장된 컨텐트를 서비스 하기 위해 컨텐트 서버 (content server)를 포함 할 수 있다. 컨텐트 네트워크는 컨텐트 서버와 함께, 미디어 전송을 서비스하는 컨텐트 딜리버리 네트워크 (Contents Delivery Network, CDN)를 포함할 수 있다. 따라서 컨텐트 네트워크는 컨텐트와 관련된 시그널링 메시지 (signaling message), 컨트롤 메시지 (control message) 등을 생성 및 전송 할 수 있다.
컨텐트, 시그널링 메시지, 컨트롤 메시지 등의 적절한 상호동작을 위해 컨텐트 네트워크에 속하는 여러 노드들 (nodes) 사이에는 별도의 시그널링 메시지 또는 컨트롤 메시지가 교환될 수 있으며, 이러한 메시지들은 다른 외부 네트워크로 전달되지 않을 수 있다. 이렇게 외부 네트워크로 전달되지 않는 시그널링 메시지 또는 컨트롤 메시지는 인터널 네트워크 시그널링 (internal network signaling)이라 명명할 수 있다.
위에서 설명한 바와 같이, 컨텐트 네트워크에는 브로드캐스터 헤드-엔드 (head-end) 를 포함할 수 있다. 브로드캐스터에서 생성된 컨텐트는 인코딩 및 패키징을 거쳐 멀티캐스트 센더 (multicast sender)로 전달되어 멀티캐스팅 되거나, 컨텐트 서버에 저장 되어 필요 시에 멀티캐스트 센더 (multicast sender)로 전달될 수 있다. 아래에서는 컨텐트 네트워크의 브로드캐스터 헤드-엔드에 포함된 각 구성요소에 대해 설명한다.
먼저, 브로드캐스터 헤드-엔드에 포함된 인코더 (Encoder)는 컨텐트에 대한 인코딩을 수행한다. 브로드캐스터 헤드-엔드에 포함된 패키저 (Packager)는 인코딩된 컨텐트 및 데이터를 멀티캐스트 전송에 적합한 포맷으로 변환할 수 있다. 멀티캐스트 전송에 적합한 포맷은 예를 들어, 하나의 컨텐트를 분할하여 생성된 미디어 세그먼트일 수 있다. 또한 패키저는 필요시 수신기 또는 네트워크에 소속된 장치에서 수신할 수 있는 시그널링을 생성할 수 있다. 패키저에서 생성한 미디어 세그먼트는 직접 멀티캐스트 센더로 전달되어 멀티캐스트될 수 있으나, 해당 미디어 세그먼트가 즉시 전달될 필요가 없는 데이터인 경우에는 컨텐트 서버에 저장될 수 있다. 브로드캐스터 헤드-엔드에 포함된 컨텐트 서버 (Content Server)는 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있다. 컨텐트 서버는 또한 써드 파티에서 생성된 컨텐트 (3rd party content)를 저장하고 필요 시 멀티캐스트에 활용할 수 있다. 여기서, 컨텐트 서버에 저장되어 있는 컨텐트의 경우 별도의 인코딩 과정이 필요 없을 수 있다. 따라서 컨텐트 서버는 컨텐트를 인코딩 또는 패키징한 미디어 세그먼트 및 파일을 저장하고, 전송 요청이 있는 경우 전송할 수 있다. 실시예에 따라서는 미디어 데이터에 대한 인코딩 결과가 컨텐트 서버에 저장될 수도 있으며, 전송 네트워크의 형태에 따라 별도의 패키징 과정이 필요할 수 있다. 브로드캐스터 헤드-엔드에 포함된 오퍼레이터 컨트롤러 (Operator Controller)는 컨텐트 프로덕션 (Content production) 및 컨텐트 서버 (content server) 등을 관리하고, 멀티캐스팅과 관련한 일련의 과정을 관리 및 제어할 수 있다. 오퍼레이터 컨트롤러 (Operator Controller)는 컨텐트 네트워크 내의 복수의 디바이스들 및 노드들(nodes)에 대해 컨트롤 및 시그널링 데이터를 수집 하고, 필요한 경우 멀티캐스트 네트워크로 전달할 수 있다. 이를 통해 오퍼레이터 컨트롤러 (Operator Controller)는 멀티캐스트 네트워크가 멀티캐스트와 관련된 시그널링 및 컨트롤을 수행하는 것을 가능하게 할 수 있다. 또한 오퍼레이터 컨트롤러는 디코딩 디바이스나 플레이어(player)로부터 전달되는 유니캐스트 (unicast) 정보를 수신 및 처리하여 멀티캐스트에 이용할 수 있다.
도 3은 본 발명의 일 실시예에 따른 컨텐트 네트워크가 위성 릴레이 (satellite realy)를 포함하는 경우를 나타낸 도면이다. 위성 릴레이 (satellite realy)가 포함된 컨텐트 네트워크는 인코더, 위성 송신기, 위성 수신기, 패키저 (packager), 컨텐트 서버, 오퍼레이터 컨트롤러를 포함할 수 있다. 지상파 및 케이블 방송 등을 서비스 하는 브로드캐스터의 헤드 엔드 (head-end)는, 지리적으로 떨어진 컨텐트 생산자의 서비스를 수신하기 위한 위성 수신 네트워크를 포함 할 수 있다. 위성 송신 측은 다른 브로드캐스터의 헤드엔드 (head-end)가 될 수 있다. 이러한 경우 복수의 브로드캐스터의 헤드엔드들이 연결되어 있는 위성 송수신 네트워크가 컨텐트 네트워크에 포함될 수 있다. 위성 시스템을 통해 수신된 컨텐트는 인코딩 및 패키징을 멀티캐스트 센더 (Multicast sender)로 전달되어 멀티캐스팅 되거나, 컨텐트 서버 (content server)에 저장되어 필요 시 멀티캐스트 센더 (Multicast sender)로 전달될 수 있다. 위성 릴레이 (satellite realy)가 포함된 컨텐트 네트워크의 인코더는 컨텐트에 대한 인코딩을 수행할 수 있다. 여기서, 인코더는 위성으로 방송 데이터를 중계하기 위한 위성 송신 장치에 연결될 수 있다. 위성 릴레이 (satellite realy)가 포함된 컨텐트 네트워크의 위성 릴레이 시스템 (Satellite Relay System)은 지리적으로 멀리 떨어진 장소에 대한 라이브 방송을 위해서 사용될 수 있다. 예를 들어, 해외 스포츠, 콘서트 중계, 뉴스 등이 위성 릴레이 시스템을 통해 실시간 방송될 수 있다. 이를 위해 별도의 위성 송신 관련 프로토콜 및 전송 방식을 이용할 수 있다. 위성 송수신 시스템을 거친 데이터는 패키저로 전달된다. 위성 릴레이 (satellite realy)가 포함된 컨텐트 네트워크의 패키저에 대한 설명은 이전 도면에서 설명한 바와 같다. 위성 릴레이 (satellite realy)가 포함된 컨텐트 네트워크의 Content Server는 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있다. 지리적으로 멀리 떨어진 장소에 대한 라이브 (live) 방송시 패키저를 거친 데이터는 곧바로 멀티캐스트 센더 (multicast sender)로 전송 되지만, 브로드캐스터의 헤드 엔드 (head-end)에서 해당 컨텐트에 대한 추후 활용을 위해 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있다. 이와 관련된 상세한 설명은 이전 도면에서 설명한 바와 같다. 위성 릴레이 (satellite realy)가 포함된 컨텐트 네트워크의 오퍼레이터 컨트롤러에 대한 설명은 이전 도면에서 설명한 바와 같다.
도 4는 본 발명의 일 실시예에 따른 컨텐트 네트워크가 컨텐트 딜리버리 네트워크 (CDN)를 포함하는 경우를 나타낸 도면이다. IP 네트워크를 이용하여 비디오 컨텐트를 서비스하는 오버더톱 (Over the top, OTT)은 컨텐트 네트워크 (Content Network)의 하나의 실시예로써 고려될 수 있다. OTT의 경우 효율적인 네트워크 자원의 활용 등을 위해 CDN이 연결 될 수 있다. 컨텐트 딜리버리 네트워크 (CDN)를 포함하는 컨텐트 네트워크는 인코더, 패키저, 컨텐트 서버, 오퍼레이터 컨트롤러 및 CDN을 포함할 수 있다. OTT의 컨텐트는 인코딩 및 패키징을 거쳐 CDN에 전달될 수 있다. 또한 인코딩 및 패키징이 수행된 컨텐트는 컨텐트 서버에 저장된 후, 컨텐트에 대한 요청에 대응하여 CDN에 전달될 수 있다. CDN에 전달된 컨텐트는 멀티캐스트 센더로 전달될 수 있다. 실시예에 따라서는 OTT의 컨텐트가 CDN을 거치지 않고 직접 멀티캐스트 센더로 전달되어 멀티캐스트될 수도 있다. OTT의 인코더는 컨텐트에 대한 인코딩을 수행할 수 있다. OTT에서 라이브 (live) 서비스를 제공하거나, 컨텐트 서버 (content server)에 저장될 컨텐트를 제작할 수 있다. OTT의 패키저에 대한 설명은 이전 도면에서 설명한 바와 같다. OTT의 컨텐트 서버 (Content server)에는 OTT에서 서비스할 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있다. 컨텐트 서버는 또한 써드 파티에서 생성된 컨텐트 (3rd party content)를 저장하고 필요 시 멀티캐스트에 활용할 수 있다. 여기서, 컨텐트 서버에 저장되어 있는 컨텐트의 경우 별도의 인코딩 과정이 필요 없을 수 있다. 따라서 컨텐트 서버는 컨텐트를 인코딩 또는 패키징한 미디어 세그먼트 및 파일을 저장하고, 전송 요청이 있는 경우 전송할 수 있다. 실시예에 따라서는 미디어 데이터에 대한 인코딩 결과가 컨텐트 서버에 저장될 수도 있으며, 전송 네트워크의 형태에 따라 별도의 패키징 과정이 필요할 수 있다. OTT의 오퍼레이터 컨틀롤러 (Operator Controller)는 멀티캐스트 데이터 및 유니캐스트 데이터와 관련한 일련의 과정을 관리하고 제어할 수 있다. 오퍼레이터 컨트롤러 (Operator Controller)는 컨텐트 네트워크 내의 복수의 디바이스들 및 노드들(nodes)에 대해 컨트롤 및 시그널링 데이터를 수집 하고, 필요한 경우 멀티캐스트 네트워크로 전달할 수 있다. 이를 통해 오퍼레이터 컨트롤러 (Operator Controller)는 멀티캐스트 네트워크가 멀티캐스트와 관련된 시그널링 및 컨트롤을 수행하는 것을 가능하게 할 수 있다. 또한 오퍼레이터 컨트롤러는 디코딩 디바이스나 플레이어(player)로부터 전달되는 유니캐스트 (unicast) 정보를 수신 및 처리하여 멀티캐스트에 이용할 수 있다. OTT와 CDN은 각각 별도의 오퍼레이터 컨트롤러를 포함할 수 있으며, OTT에 포함된 오퍼레이터 컨트롤러와 CDN에 포함된 오퍼레이터 컨트롤러는 상호 커뮤니케이션이 가능하다.
ABR 멀티캐스트 네트워크는 컨텐트 네트워크로부터 전달된 컨텐트를 IP network를 통해 멀티캐스트하는 너트워크이다. 여기서 IP network는 네트워크 제공자에 의해 QoS 등이 관리되며 비인가(Unauthorized) 트래픽이 제한될 수 있는 managed network 와 비인가 트래픽이 제한되지 않는 unmanaged network 중 어느 하나에 해당할 수 있다. 또한 IP network는 멀티캐스트 네트워크 또는 유저 네트워크에 포함된 디바이스들에 의해 유선 또는 무선 등의 접속방식으로 접속될 수 있다. 멀티캐스트를 위한 IP network를 이용하는데 있어서, 컨텐트 네트워크와 접속되어 있는 IP network는 유저 네트워크와 접속하고 있는 IP network와 다를 수 있다. 즉, 컨텐트 네트워크와 유저 네트워크는 각각 별도의 IP network와 접속할 수 있다. 이러한 경우, 별도의 IP network들은 각각의 network를 제공하는 ISP (Internet Service Provider) 간의 접속 규약을 따를 수 있다. 이러한 경우에도, 멀티캐스트 컨텐트에 대해 sender 와 receiver 사이는 transparent 하다. 즉, sender의 출력 데이터 (output data)는 network 상의 여러 ISP network 및 노드(node)를 거치더라도, receiver의 입력 데이터 (input data)와 동일하다.
멀티캐스트 스트림의 송신 및 수신을 위한 멀티캐스트 네트워크는 multicast sender (server), multicast receiver (client), multicast network controller를 포함할 수 있다. 멀티캐스트 네트워크는 멀티캐스트를 위한 네트워크의 sender 및 receiver의 위치 또는 접속 상태에 따라, 복수의 네트워크를 포함할 수 있다. 또한 이에 대해 각 network에 따라 별도의 protocol을 사용할 수도 있다.
도 5는 본 발명의 일 실시예에 따른 유선 (wired) 멀티캐스트 네트워크를 나타낸 도면이다. 멀티캐스트 스트림은 유선 IP network를 통해 전달될 수 있다. Multicast sender와 Multicast receiver 사이에는 ISP (Internet Service Provider)에서 제공하는 network를 이용할 수 있다. 실시예에 따라 멀티캐스트 스트림은 복수의 ISP에서 관리하는 IP network를 통해 전달될 수 있으며, Multicast sender, receiver, controller 와 IP network의 관리 주체가 다를 수 있다. 이 경우 멀티캐스트 스트림의 전송은 각 ISP에 대응하는 접속 protocol을 따를 수 있다.
멀티캐스트 네트워크에 포함된 멀티캐스트 센더 (Multicast sender)는 각 멀티캐스트 리시버 (multicast receiver)에 컨텐트 데이터 (contents data)를 전송할 수 있다. 멀티캐스트 센더 (Multicast sender)는 컨텐트 네트워크 (Content Network)로 부터 패키징된 컨텐트 (packaged content)를 수신하고, 멀티캐스트 프로토콜 (multicast protocol)을 이용하여 복수의 multicast receiver로 전송할 수 있다. 멀티캐스트 네트워크에 포함된 멀티캐스트 리시버 (Multicast receiver)는 멀티캐스트 센더에서 전송한 컨텐트 데이터를 수신하고, 이를 재생할 수 있는 디코딩 디바이스 (decoding device)에 컨텐트 데이터를 전달할 수 있다. 디코딩 디바이스가 컨텐트 데이터를 효율적으로 재생할 수 있도록, 멀티캐스트 리시버는 컨텐트 데이터를 캐쉬(cache)할 수 있다. 실시예에 따라, 멀티캐스트 리시버는 디코딩 디바이스와 동일한 장치 내에서 구성될 수 있다. 또한 실시예에 따라서는, 멀티캐스트 스트림을 유저 네트워크의 게이트웨이 (Gateway)를 통해 수신할 수도 있다. 이러한 실시예에서는 멀티캐스트 리시버가 유저 네트워크의 구성 요소가 될 수 있다.
멀티캐스트 네트워크에 포함된 멀티캐스트 네트워크 컨트롤러 (Multicast network controller)는 멀티캐스트 센더의 컨텐트 전송 및 관련 세션 (session) 정보를 제어할 수 있다. 또한 멀티캐스트 네트워크 컨트롤러는 각각의 멀티캐스트 센더 및 멀티캐스트 리시버에 대한 배치(configuration)을 위한 시그널링 정보를 관리 및 전달할 수 있다. 이러한 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 컨텐트와는 별도의 프로토콜을 이용하여 각각의 멀티캐스트 센더 및 멀티캐스트 리시버와 연결될 수 있다. 또한 실시예에 따라 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 센더에만 연결되고, 멀티캐스트 리시버로 전송되는 시그널링 정보는 멀티캐스트 컨텐트와 동일한 프로토콜을 따를 수 있다.
멀티캐스트 네트워크에 포함된 네트워크 캐쉬 (Network Cache)는 멀티캐스트 센더와 멀티캐스트 리시버 사이에 캐쉬 기능을 하는 노드 또는 장치를 포함할 수 있다. 네트워크 캐쉬는 멀티캐스트 전송시, 효율적인 네트워크 자원의 사용을 위해 적절한 범위의 컨텐트를 저장하고, 멀티캐스트 리시버에 멀티캐스트 스트림을 전달할 수 있다. 실시예에 따라, 네트워크 캐쉬는 멀티캐스트 센더와 캐쉬된 컨텐트에 대한 갱신 절차를 수행할 수 있다.
도 6은 본 발명의 일 실시예에 따른 모바일 멀티캐스트 네트워크를 나타낸 도면이다. 멀티캐스트 스트림은 유선 IP network를 통해 전달될 수 있지만, 모바일 수신기에 대해서는 모바일 억세스 네트워크 (mobile access network)를 통해 전달될 수 있다. IP multicast를 위해 모바일 억세스 네트워크는 IP 전송을 지원하는 네트워크를 이용할 수 있다. 또한 모바일 억세스 네트워크는 복수의 모바일 수신기에 멀티캐스트 스트림을 서비스 하기 멀티캐스트를 지원 할 수 있다.
멀티캐스트 네트워크에 포함된 멀티캐스트 센더 (Multicast sender)는 각 멀티캐스트 리시버 (multicast receiver)에 컨텐트 데이터 (contents data)를 전송할 수 있다. 멀티캐스트 센더 (Multicast sender)는 컨텐트 네트워크 (Content Network)로 부터 패키징된 컨텐트 (packaged content)를 수신하고, 멀티캐스트 프로토콜 (multicast protocol)을 이용하여 복수의 멀티캐스트 리시버로 전송할 수 있다. 멀티캐스트 네트워크에 포함된 멀티캐스트 리시버 (Multicast receiver)는 멀티캐스트 센더에서 전송한 컨텐트 데이터를 수신하고, 이를 재생할 수 있는 디코딩 디바이스 (decoding device)에 컨텐트 데이터를 전달할 수 있다. 모바일 억세스 네트워크에 접속되어 있는 멀티캐스트 리시버는 해당 모바일 억세스 네트워크에 대한 무선 신호를 수신할 수 있다. 실시예에 따라, 모바일 억세스 네트워크에 접속되어 있는 멀티캐스트 리시버는 별도의 무선 접속 규격을 통해 디코딩 디바이스와 연결 될 수 있다. 디코딩 디바이스가 컨텐트 데이터를 효율적으로 재생할 수 있도록, 멀티캐스트 리시버는 컨텐트 데이터를 캐쉬(cache)할 수 있다. 실시예에 따라, 멀티캐스트 리시버는 디코딩 디바이스와 동일한 장치 내에서 구성될 수 있다.
멀티캐스트 네트워크에 포함된 멀티캐스트 네트워크 컨트롤러 (Multicast network controller)는 멀티캐스트 센더의 컨텐트 전송 및 관련 세션 (session) 정보를 제어할 수 있다. 또한 멀티캐스트 네트워크 컨트롤러는 각각의 멀티캐스트 센더 및 멀티캐스트 리시버에 대한 배치(configuration)을 위한 시그널링 정보를 관리 및 전달할 수 있다. 이러한 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 컨텐트와는 별도의 프로토콜을 이용하여 각각의 멀티캐스트 센더 및 멀티캐스트 리시버와 연결될 수 있다. 또한 실시예에 따라 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 센더에만 연결되고, 멀티캐스트 리시버로 전송되는 시그널링 정보는 멀티캐스트 컨텐트와 동일한 프로토콜을 따를 수 있다. 또한, IP 네트워크와 모바일 억세스 네트워크는 각각 멀티캐스트 네트워크 컨트롤러를 포함할 수 있다. 이 경우 멀티캐스트 네트워크 컨트롤러는 해당하는 네트워크에 대한 제어 및 시그널링 정보의 송수신이 가능하다. 각각의 멀티캐스트 네트워크 컨트롤러는 별도의 프로토콜을 이용해 멀티캐스트 네트워크 컨트롤러 간 통신 (communication)을 수행할 수 있다.
멀티캐스트 네트워크에 포함된 네트워크 캐쉬 (Network Cache)는 멀티캐스트 센더와 멀티캐스트 리시버 사이에 캐쉬 기능을 하는 노드 또는 장치를 포함할 수 있다. 네트워크 캐쉬는 멀티캐스트 네트워크를 구성하는 복수의 네트워크 각각에 포함될 수 있으며, 복수의 네트워크 캐쉬가 각 네트워크에 포함될 수도 있다. 또한, 각각의 네트워크의 일부 노드가 캐쉬 역할을 동시에 수행할 수도 있다. 네트워크 캐쉬는 멀티캐스트 전송시, 효율적인 네트워크 자원의 사용을 위해 적절한 범위의 컨텐트를 저장하고, 멀티캐스트 리시버에 멀티캐스트 스트림을 전달할 수 있다. 실시예에 따라, 네트워크 캐쉬는 멀티캐스트 센더와 캐쉬된 컨텐트에 대한 갱신 절차를 수행할 수 있다.
유저 네트워크는 멀티캐스트 네트워크로부터 데이터를 수신하고, 해당 데이터에 포함된 컨텐트를 소비(consume)하는 디바이스로 전달하는 네트워크라 할 수 있다. 유저 네트워크의 구성 및 멀티캐스트를 통한 서비스의 종류에 따라 유저 네트워크는 다양하게 구성될 수 있다. 위에서 설명한 멀티캐스트 리시버는 실시예에 따라 유저 네트워크에 포함될 수 있다. 멀티캐스트 리시버가 유저 네트워크 내에 포함된 경우, 멀티캐스트 리시버는 유저 네트워크에 포함된 게이트웨이 (gateway) 또는 프록시 (proxy) 역할을 하는 장치를 통해 멀티캐스트 컨텐트를 수신 할 수 있다. 이러한 경우, 해당 게이트웨이 또는 프록시는 ABR 멀티캐스트 네트워크의 구성요소로써 간주될 수 있다.
멀티캐스트 리시버는 유저 네트워크 내에서 서버 또는 멀티캐스트 센더의 역할을 수행할 수 있다. 이로 인해, 유저 네트워크에 포함된 디코딩 디바이스는 멀티캐스트 컨텐트를 소비할 수 있으며, 디코딩 디바이스가 멀티캐스트 컨텐트의 직접 수신이 불가한 경우에도 멀티캐스트 스트리밍이 가능하게 할 수 있다.
도 7은 본 발명의 일 실시예에 따른 유저 네트워크를 나타낸 도면이다. 유저 네트워크의 실시예로써 홈 네트워크가 고려될 수 있다. 멀티캐스트로 전송되는 데이터는 멀티캐스트 리시버가 직접 수신 할 수도 있지만, 홈 네트워크에 속해있는 홈 게이트웨이(Home Gateway)가 데이터를 수신하고, 이를 멀티캐스트 리시버에 전달할 수 있다.
홈 게이트웨이는 홈 네트워크에 복수의 디바이스들이 포함되어 있는 경우, ABR 멀티캐스트 네트워크로부터 데이터를 수신 받을 수 있다. 홈 게이트웨이는 외부 네트워크와의 데이터 송수신을 수행할 수 있고, 또한 프록시의 역할을 동시에 수행할 수 있다. 홈 게이트웨이가 프록시의 역할을 하는 경우, 홈 게이트웨이는 멀티캐스트 리시버에게 전달할 데이터를 캐쉬(cache) 할 수 있다.
멀티캐스트 리시버는 앞서 기술한 ABR 멀티캐스트 네트워크에 포함될 수도 있으나, 네트워크의 구성상 홈 네트워크의 내부에 위치할 수 있다. 홈 네트워크의 구성에 따라 멀티캐스트 리시버가 프록시의 역할을 겸할 수 있다. 멀티캐스트 리시버가 멀티캐스트 스트림을 직접 재생(play)할 수 없는 경우, 멀티캐스트 리시버에는 멀티캐스트 스트림을 재생할 수 있는 디코딩 디바이스가 추가적으로 연결될 수 있다. 또한, 멀티캐스트 리시버는 복수의 디코딩 디바이스들과 연결되어 멀티캐스트 스트림을 전송할 수 있다.
디코딩 디바이스(Decoding device)는 멀티캐스트 스트림을 재생하여 사용자에게 제공하는 디바이스로 정의할 수 있다. 복수의 디코딩 디바이스들이 멀티캐스트 리시버에 접속할 수 있으며, 디코딩 디바이스는 유니캐스트 또는 멀티캐스트를 통해 데이터를 송수신 할 수 있다. 디코딩 디바이스는 멀티캐스트 스트림을 수신하는 멀티캐스트 네트워크 외에도 유니캐스트 네트워크에 접속할 수 있다. 디코딩 디바이스는 컨텐트 네트워크 또는 ABR 멀티캐스트 네트워크에 리퀘스트(request) 또는 리포트(report) 등을 전송할 수 있다. 실시예에 따라서는 디코딩 디바이스 외에 디코딩 모듈과 디스플레이 스크린 등이 별도의 장치로써 홈 네트워크에 포함될 수 있다. 또한 디코딩 디바이스는 멀티캐스트 리시버와 함께 단일 장치로써 구성될 수 있다.
도 8은 본 발명의 일 실시예에 따른 ABR 멀티캐스트를 위한 네트워크 구조를 나타낸 도면이다. 도면은 어댑티브 미디어 스트리밍 (Adaptive Media Streaming)을 위한 전체 네트워크 구조 (network architecture)의 예를 나타낸다. 어댑티브 미디어 스트리밍을 위한 네트워크 구조는 컨텐트 네트워크, ABR 멀티캐스트 네트워크, 유저 네트워크를 포함할 수 있다. 각 네트워크에 대한 자세한 설명은 이전 도면들에서 설명한 바와 같다. 본 발명에서 정의 하고 있는 노드 (node) 또는 엔터티 (entity)는 논리적인 구성이 될 수 있으며, 각각의 노드는 별도의 장치로 구성될 수 있으나, 실시예에 따라서 인접 노드와 같은 장치에서 동작할 수 있다. 도시된 바와 같이 복수 개의 network들이 서로 연결될 수 있으며 효율적인 멀티캐스트 스트리밍을 위해 시그널링 및 매니지먼트 정보를 교환할 수 있다.
아래에서는 어댑티브 미디어 스트리밍을 위한 네트워크 인터페이스 및 프로토콜에 대해 설명한다. 프로토콜은 실제 미디어 데이터가 전송되는 미디어 프로토콜과, 미디어 데이터를 전송하기 위해 각각의 노드 또는 엔터티를 제어하거나, 수신기를 포함하는 여러 노드 및 엔터티에 미디어 데이터에 대한 구성 정보를 전송하기 위한 시그널링 프로토콜로 구분할 수 있다. 시그널링 및 컨트롤 정보는 시그널링 프로토콜을 이용하여 전달 되지만, 수신기가 단일 연결에 의해 미디어 컨텐트를 수신하는 경우에는 별도의 시그널링 패스(path)가 구성되지 않을 수 있다. 이러한 경우에는 시그널링 및 컨트롤 정보는 미디어 프로토콜을 통해 전달 될 수 있다.
도 9는 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다. 도시된 바와 같이, 멀티캐스트 리시버가 디코더 (media player)와 동일한 장치 및 모듈로 구성될 수 있다. 컨텐트 네트워크에서 생성되거나 서버에 저장되어 있는 미디어 컨텐트는 사용자의 디코딩 디바이스에 전달될 수 있으며, 복수의 사용자에게 전달하기 위해 멀티캐스트로 전송될 수 있다.
어댑티브 멀티캐스트 스트리밍 (Adaptive multicast streaming) 환경에서, 컨텐트의 생성과 멀티캐스트 송수신 과정은 분리되어 수행될 수 있다. 따라서, 멀티캐스트 전송을 수행하는 노드 (node) 및 엔터티 (entity)에게로 생성된 컨텐트를 전달 하기 위한 프로토콜과, 해당 컨텐트를 어댑티브 스트리밍 형식으로 멀티캐스트 송수신하는 프로토콜이 각각 정의될 수 있다. 도면에서는 노드 (node) 및 엔터티 (entity)가 멀티캐스트 센더로 도시되었다. 또한, 컨텐트 데이터는 복수의 노드 또는 엔터티를 거치게 되며 각각의 노드 및 엔터티 사이에도 적절한 프로토콜이 필요하다. 이때, 노드 또는 엔터티 상의 프로토콜은 데이터를 효율적이면서 실시간으로 다음 노드로 전달하는 프로토콜을 사용할 수 있으며, 이러한 프로토콜을 터널링 (tunneling) 프로토콜이라 명명할 수 있다. 따라서 도시된 바와 같이 서버와 멀티캐스트 센더 사이에 터널링 프로토콜이 정의될 수 있다. 이때, 터널링 프로토콜의 페이로드로써 미디어 컨텐트가 전달 되지만, 터널링 프로토콜은 해당 미디어 컨텐트가 어떠한 형식인지에 관계없이 동작할 수 있다.
멀티캐스트 센더에서는 멀티캐스트 리시버에 어댑티브 스트리밍을 지원 하는 프로토콜이 정의될 수 있고, 해당 어댑티브 스트리밍은 복수의 멀티캐스트 리시버들로 전달되기 위해 IP multicast 방식이 적용될 수 있다. 어댑티브 스트리밍의 프로토콜에 따라, IP multicast 방식은 TCP/IP 와 UDP/IP 의 조합으로 정의될 수 있다.
멀티캐스트 리시버가 디코더 및 플레이어을 수행할 수 있는 경우, 멀티캐스트 리시버는 IP multicast 패킷을 수신하여 어댑티브 스트리밍 데이터를 획득하고 해당 데이터에서 미디어 컨텐트 포맷에 해당하는 데이터를 디코딩 및 재생 (play)할 수 있다.
도 10은 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다. 도시된 바와 같이, 멀티캐스트 리시버가 디코더 (media player)와는 별도의 장치 또는 모듈로 구성될 수 있다. 컨텐트 네트워크에서 생성되거나 서버에 저장되어 있는 미디어 컨텐트는 사용자의 디코딩 디바이스에 전달될 수 있으며, 복수의 사용자에게 전달하기 위해 멀티캐스트로 전송될 수 있다.
어댑티브 멀티캐스트 스트리밍 (Adaptive multicast streaming) 환경에서, 컨텐트의 생성과 멀티캐스트 송수신 과정은 분리되어 수행될 수 있다. 따라서, 멀티캐스트 전송을 수행하는 노드 (node) 및 엔터티 (entity)에게로 생성된 컨텐트를 전달 하기 위한 프로토콜과, 해당 컨텐트를 어댑티브 스트리밍 형식으로 멀티캐스트 송수신하는 프로토콜이 각각 정의될 수 있다. 도면에서는 노드 (node) 및 엔터티 (entity)가 멀티캐스트 센더로 도시되었다. 또한, 컨텐트 데이터는 복수의 노드 또는 엔터티를 거치게 되며 각각의 노드 및 엔터티 사이에도 적절한 프로토콜이 필요하다. 이때, 노드 또는 엔터티 상의 프로토콜은 데이터를 효율적이면서 실시간으로 다음 노드로 전달하는 프로토콜을 사용할 수 있으며, 이러한 프로토콜을 터널링 (tunneling) 프로토콜이라 명명할 수 있다. 따라서 도시된 바와 같이 서버와 멀티캐스트 센더 사이에 터널링 프로토콜이 정의될 수 있다. 이때, 터널링 프로토콜의 페이로드로써 미디어 컨텐트가 전달 되지만, 터널링 프로토콜은 해당 미디어 컨텐트가 어떠한 형식인지에 관계없이 동작할 수 있다.
멀티캐스트 센더에서는 멀티캐스트 리시버에 어댑티브 스트리밍을 지원 하는 프로토콜이 정의될 수 있고, 해당 어댑티브 스트리밍은 복수의 멀티캐스트 리시버들로 전달되기 위해 IP multicast 방식이 적용될 수 있다. 어댑티브 스트리밍의 프로토콜에 따라, IP multicast 방식은 TCP/IP 와 UDP/IP 의 조합으로 정의될 수 있다.
멀티캐스트 리시버와 디코더 (player)가 별도의 장치 또는 module로 구성되어 있는 경우에는, 멀티캐스트 리시버가 IP multicast 패킷을 수신하여 어댑티브 스트리밍 데이터를 획득하고 이를 다시 디코더에게 전달 할 수 있다. 여기서, 멀티캐스트 리시버와 디코더 사이에는 IP unicast 프로토콜이 사용될 수 있다. 멀티캐스트 리시버가 수신한 컨텐트 데이터는 다시 IP unicast를 통해 디코더로 전달 되고, 디코더는 수신된 미디어 컨텐트 포맷에 해당하는 데이터를 디코딩 및 재생(play)할 수 있다.
아래에서는 시그널링 및 컨트롤 메시지를 위한 프로토콜에 대해 설명한다. 시그널링 및 컨트롤 메시지의 전송은 각 노드 및 엔터티가 어댑티브 스트리밍을 수행하는데 있어서, 전송 제어(control), 스케줄링 (scheduling), configuration 정보 등을 제공하기 위해, 미디어 컨텐트 전송과는 구별되는 프로토콜로 정의 될 수 있다. 각각의 노드 및 엔터티가 접속 되어 있는 경우에 따라 별도의 프로토콜로 정의 될 수 있다. 앞서 기술한 네트워크 구조에서 미디어 컨텐트의 전송을 위한 프로토콜에 시그널링 및 컨트롤 메시지가 포함되어 전송될 수 있으나 그러한 시그널링 및 컨트롤 메시지는 미디어 컨텐트 딜리버리를 위한 프로토콜을 따른다.
도 11은 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다. 앞서 기술한 네트워크 구조에서 컨텐트 네트워크에 포함되는 오퍼레이터 컨트롤러(operator controller)와 멀티캐스트 네트워크에 포함되는 네트워크 컨트롤러 (network controller) 사이에 컨트롤 프로토콜이 정의될 수 있다. 또한 오퍼레이터 컨트롤러가 컨트롤 및 매니지먼트 메시지를 생성하기 위해 네트워크 컨트롤러는 컨트롤 메시지에 대한 응답(response) 또는 리포트 (report) 메시지를 오퍼레이터 컨트롤러로 보낼 수 있다. 따라서, 컨트롤 메시지를 보내기 위한 터널링 프로토콜 (tunneling protocol)은 양방향으로 구성 될 수 있다. 단일 오퍼레이터 컨트롤러는 복수의 멀티캐스트 네트워크 컨트롤러들과 컨트롤 메시지를 송수신할 수 있다. 또한 각각의 멀티캐스트 네트워크 컨트롤러는 별도의 운영주체에서 관리 될 수 있다.
네트워크 컨트롤러에서 네트워크의 configuration 관련 정보는 멀티캐스트 센더 (sender) 및 멀티캐스트 리시버로 전달될 수 있다. 네트워크 컨트롤러는 네트워크 자원에 대한 configuration 정보 및 네트워크의 노드 사이의 mapping 정보, routing 정보 등을 전달할 수 있다. 또한 오퍼레이터 컨트롤러로부터 수신된 configuration 정보 등을 멀티캐스트 센더 또는 멀티캐스트 리시버 등으로 전달할 수 있다. 이 과정에서, 멀티캐스트 네트워크 컨트롤러에서 멀티캐스트 센더로 전송되는 프로토콜과 멀티캐스트 리시버로 전송되는 프로토콜은 구별될 수 있다. 도면 상단은 네트워크 컨트롤러에서 멀티캐스트 센더로 전송되는 프로토콜을 나타내며, 도면 하단은 네트워크 컨트롤러에서 멀티캐스트 리시버로 전송되는 프로토콜을 나타낸다.
또한, 하나의 네트워크 컨트롤러에서 복수의 멀티캐스트 센더 및 멀티캐스트 리시버로 configuration 메시지를 전달 하기 위해 IP multicast가 사용될 수 있다. 멀티캐스트 센더 및 멀티캐스트 리시버 등에서 수집되는 접속, 통계 정보 등은 멀티캐스트 네트워크 컨트롤러로 리포트될 수 있다. 이러한 과정은 각각의 멀티캐스트 센더 및 멀티캐스트 리시버가 독립적으로 수행할 수 있기 때문에 unicast 방식의 프로토콜이 이용될 수 있다. 이러한 일련의 컨트롤 정보, configuration 정보 등은 동적으로 업데이트 될 수 있고, 즉시 또는 스케쥴링을 통해 전송될 수 있다.
멀티캐스트 리시버는 수신된 어댑티브 스트리밍 데이터를 다시 디코딩 디바이스에 전송하기 위한 시그널링 프로토콜을 사용할 수 있다. 여기서, 개별 디코딩 디바이스에 별도의 정보를 제공하기 위해 IP unicast 방식의 프로토콜이 정의될 수 있다. 또한 디코딩 디바이스는 IP unicast 방식의 프로토콜을 이용하여 디코딩 디바이스가 요청하는 사항에 대한 시그널링을 멀티캐스트 리시버에게로 전달할 수 있다. 따라서 멀티캐스트 리시버와 디코딩 디바이스 사이에 양방향 프로토콜로써 정의 될 수 있다.
도 12는 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다. 도시된 바와 같이, 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 리시버에 직접 접속되지 않고, 멀티캐스트 센더를 통해 멀티캐스트 리시버에 접속될 수 있다.
네트워크 컨트롤러에서 네트워크의 configuration 관련 정보는 멀티캐스트 센더 (sender) 및 멀티캐스트 리시버로 전달될 수 있다. 네트워크 컨트롤러는 네트워크 자원에 대한 configuration 정보 및 네트워크의 노드 사이의 mapping 정보, routing 정보 등을 전달할 수 있다. 또한 오퍼레이터 컨트롤러로부터 수신된 configuration 정보 등을 멀티캐스트 센더 또는 멀티캐스트 리시버 등으로 전달할 수 있다. 그런데 여기서 멀티캐스트 컨트롤러는 멀티캐스트 센더에만 연결되어 있고, 멀티캐스트 리시버와는 연결되어 있지 않으므로, 멀티캐스트 센더가 네트워크 컨트롤러에서 멀티캐스트 리시버로 전달되는 configuration 메시지를 포워딩(forwarding) 해 줄 수 있다. 멀티캐스트 네트워크 컨트롤러에서 configuration 관련한 프로토콜 또는 message set은 멀티캐스트 센더로 전송되는 프로토콜과 멀티캐스트 리시버로 전송되는 프로토콜이 구별될 수 있다.
또한, 하나의 네트워크 컨트롤러에서 복수의 멀티캐스트 센더 및 멀티캐스트 리시버로 configuration 메시지를 전달 하기 위해 IP multicast가 사용될 수 있다. 멀티캐스트 센더 및 멀티캐스트 리시버 등에서 수집되는 접속, 통계 정보 등은 멀티캐스트 네트워크 컨트롤러로 리포트될 수 있다. 이러한 과정은 각각의 멀티캐스트 센더 및 멀티캐스트 리시버가 독립적으로 수행할 수 있기 때문에 unicast 방식의 프로토콜이 이용될 수 있다. 이러한 일련의 컨트롤 정보, configuration 정보 등은 동적으로 업데이트 될 수 있고, 즉시 또는 스케쥴링을 통해 전송될 수 있다.
멀티캐스트 리시버에서 멀티캐스트 네트워크 컨트롤러로 전송되는 리포트 등의 정보는 멀티캐스트 센더를 통해 멀티캐스트 네트워크 컨트롤러로 전달 될 수 있다. 즉, 멀티캐스트 리시버로부터 멀티캐스트 네트워크 컨트롤러로 전달되는 리포트 메시지 등을 멀티캐스트 센더가 포워딩 해 줄 수 있다. 그 외의 프로토콜의 동작은 앞서 기술한 도면의 설명과 동일하게 적용될 수 있다.
도 13은 본 발명의 일 실시예에 따른 IP network를 통해 미디어 데이터를 전송하기 위한 프로토콜을 나타낸 도면이다. 각 레이어 (layer) 별로 해당하는 프로토콜 및 패킷 포맷 (packet format)이 결정될 수 있다. 각각의 프로토콜은 독립적으로 구성되거나 상호 동작을 위해 특정 프로토콜들이 조합될 수 있다. 인코더에서 수집된 비디오 및 오디오 데이터를 압축하고 적절한 코덱(codec)으로 변환하여 패키저 (packager)로 전달하는 작업은 송신 시스템 내부적인 데이터 처리로써 수행될 수 있다. 비디오 및 오디오의 멀티캐스트를 위해, 효율적인 codec이 사용 될 수 있으며, 비디오 데이터에 대해서는 HEVC(High Efficiency Video Coding), AVC (Advanced Video Coding) 등의 codec이 사용될 수 있고, 오디오 데이터에 대해서는 AAC (Advanced Audio Coding), AC4 (audio compression 4), MPEG-H (Moving Picture Experts Group-H) audio codec등이 이용될 수 있다.
각각의 codec은 전송 또는 저장에 적합한 형태로 패키징 (packaging) 될 수 있다. 이를 위해서 ISOBMFF (ISO base media file format), CMAF (Common Media Application Format), MPEG-2 TS (Transport Stream) 형태의 포맷 등이 사용될 수 있다. Codec으로 인코딩된 컨텐트 데이터가 패키징되는 과정에서, 특정 수신기에서만 해당 contents가 재생될 수 있도록 DRM (Digital Rights Management)이 추가될 수 있고, DRM에 사용되는 인증 key값은 별도의 링크 또는 채널을 통해 전달될 수 있다.
파일 형태로 구성된 미디어 데이터는 전송 방식에 따라 FLUTE (File Delivery over Unidirectional Transport)과 같이 파일을 직접 전송 할 수 있는 프로토콜이 적용될 수 있다. 또한, DASH (Dynamic Adaptive Streaming over HTTP)와 같은 어댑티브 스트리밍을 지원 하는 프로토콜이 이용될 수 있다. FLUTE 또는 DASH의 구성에 따라 하위 레이어의 프로토콜이 적용될 수 있다. 예를 들어 DASH 가 적용되어 있는 경우 하위 레이어 프로토콜로써 HTTP가 적용되거나, DASH 세그먼트를 파일로 간주하고 FLUTE가 하위 레이어 프로토콜로 사용될 수 있다.
IP multicast를 위해 상위 프로토콜의 구성에 따라 TCP/IP (Transmission Control Protocol/Internet Protocol) 또는 UDP/IP (User Datagram Protocol/Internet Protocol)가 사용될 수 있다. 또한, 멀티캐스트 리시버에서 IP multicast 그룹의 가입 등을 관리해 줄 수 있는 IGMP (Internet Group Management Protocol) 등이 병행될 수 있다. 레이어2 및 레이어1 프로토콜은 각각의 전송 링크에 따라 정의될 수 있다. 즉, 네트워크 상에 구성되는 노드 및 엔터티 사이의 링크에 따라 최적화 된 프로토콜이 구성 될 수 있다. 예를 들어 LAN (Local Area Network) 환경에서 레이어2는 Ethernet, 레이어1은 CSMA/CD (Carrier sense multiple access with collision detection) 프로토콜로 정의될 수 있다.
도 14는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다. 미디어 딜리버리 프로토콜은 미디어 컨텐트가 전송되는 경로에 따른 프로토콜의 구체적인 실시 예를 나타낸 것이다. 여기에서, 멀티캐스트 리시버는 디코더 (media player)와 동일한 장치 및 모듈로 구성되어 있는 경우를 나타낸다.
컨텐트를 위해 서버에서 사용되는 프로토콜은 미디어 코덱 (media codec)과 파일 포맷 (file format)이다. 미디어 코덱은 비디오, 오디오 또는 그 외의 인코딩 포맷을 포함할 수 있다. 비디오에 대해서는 HEVC, AVC 등의 코덱을 포함할 수 있고, 오디오에 대해서는 AAC, AC4, MPEG-H audio codec 등의 코덱을 포함할 수 있다. 파일 포맷에 대한 프로토콜은, 코덱 포맷을 파일 형태로 전송 또는 저장하기 위한 포맷으로써 정의될 수 있다. 이를 위해 ISOBMFF, CMAF 등의 파일 포맷이 사용될 수 있고, 기존 방송 네트워크가 연결되는 경우에는 MPEG-2 TS의 포맷을 이용하여 전송될 수 있다. 파일 포맷을 전송의 효율화를 위해 복수개의 포맷이 사용될 수 있다.
서버와 멀티캐스트 센더 사이의 프로토콜은 주로 파일 포맷의 효율적인 전달을 위한 프로토콜을 정의 할 수 있다. 따라서, 서버에서 생성된 컨텐트의 데이터를 터널링 프로토콜 (tunneling protocol)을 이용하여 전달 할 수 있다. 터널링 프로토콜은 주로 RTP 와 같은 실시간 전송 프로토콜을 이용할 수 있고, 그 외 해당 네트워크에서 사용할 수 있는 IP 기반의 다른 터널링 프로토콜을 이용할 수 있다. 이때 기존의 프로토콜을 그대로 이용 하거나, 해당 네트워크에 적합하도록 필드 (field)의 정의를 변경할 수 있다. 멀티캐스트 센더에서는 서버로부터 터널링 프로토콜을 이용하여 전달되는 파일을 수신하기 위해 입력단에 터널링 프로토콜이 정의 될 수 있다. 이때 터널링 프로토콜을 이용하여 전송되는 파일 포맷은 멀티캐스트 센더로부터 멀티캐스트 리시버로 전달해야 하는 데이터이므로, 해당 데이터의 포맷에 무관하게 터널링 프로토콜이 동작할 수 있다.
멀티캐스트 센더와 멀티캐스트 리시버 사이의 프로토콜은 주로 어댑티브 스트리밍(adaptive streaming)을 위한 프로토콜로 정의될 수 있다. 이러한 프로토콜은 DASH 기반의 프로토콜로 구성될 수 있으며, 이를 위해 하위 레이어 프로토콜은 IP multicast를 기반으로 한다. DASH가 동작하기 위해 HTTP 등의 프로토콜이 함께 사용될 수 있으며, DASH 세그먼트가 파일 형태로 이용되는 경우에는 FLUTE 등의 파일 전송 프로토콜이 구성 될 수 있다. 추가로, DASH/HTTP 프로토콜의 효과적인 네트워크 상의 컨넥션 및 멀티캐스트 전송을 위해 TCP/IP가 사용될 수 있다.
멀티캐스트 리시버는 멀티캐스트로 전송된 패킷 스트림 (packet stream)을 수신하기 위해 TCP/IP를 이용할 수 있다. 또한, 멀티캐스트 리시버는 패킷 스트림에 대한 요청 (request), 수신된 데이터에 대한 응답 (response) 등을 위해 HTTP를 사용할 수 있다. 멀티캐스트 센더에서 DASH를 사용하여 어댑티브 스트리밍하는 경우, 멀티캐스트 리시버는 DASH client를 포함할 수 있다. DASH를 이용하여 어댑티브 스트리밍되는 데이터는 서버에서 송신한 파일 포맷으로 구성되어 있다. 따라서, 멀티캐스트 리시버는 해당 파일 포맷을 식별할 수 있는 파일 포맷 관련 프로토콜과, 식별된 미디어 포맷을 디코딩할 수 있는 미디어 코덱을 사용할 수 있다.
도 15는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다. 미디어 딜리버리 프로토콜은 미디어 컨텐트가 전송되는 경로에 따른 프로토콜의 구체적인 실시 예를 나타낸 것이다. 본 실시예는, 멀티캐스트 리시버가 디코더 (media player)와는 별도의 장치 또는 모듈로 구성되어 있는 경우를 나타낸다. 따라서, 멀티캐스트 리시버는 수신된 멀티캐스트 스트림을 디코딩 디바이스 (디코더)에 전송하는 과정이 필요하다.
멀티캐스트 리시버는 멀티캐스트로 전송된 패킷 스트림 (packet stream)을 수신하기 위해 TCP/IP를 이용할 수 있다. 또한, 멀티캐스트 리시버는 패킷 스트림에 대한 요청 (request), 수신된 데이터에 대한 응답 (response) 등을 위해 HTTP를 사용할 수 있다. 멀티캐스트 센더에서 DASH를 사용하여 어댑티브 스트리밍하는 경우, 멀티캐스트 리시버는 DASH client를 포함할 수 있다. DASH를 이용하여 어댑티브 스트리밍되는 데이터에 대해 멀티캐스트 리시버는 프록시(proxy) 역할을 수행할 수 있다. 멀티캐스트 리시버는 데이터를 디코딩 디바이스로 전달할 수 있다. 멀티캐스트 리시버에 접속되어 있는 디코딩 디바이스의 수는 한정될 수 있으므로 해당 연결은 유니캐스트 전송을 기반으로 할 수 있다. 따라서, 멀티캐스트 리시버는 유니캐스트 연결을 위한 HTTP와 TCP/IP protocol를 이용할 수 있다.
디코딩 디바이스는 멀티캐스트 리시버로부터 전송되는 데이터를 수신하기 위해 유니캐스트 프로토콜을 이용할 수 있다. HTTP 유니캐스트를 통해 전달된 데이터는 서버에서 송신한 파일 포맷을 가질 수 있다. 따라서 디코딩 디바이스는 해당 파일 포맷을 식별할 수 있는 파일 포맷 관련 프로토콜과 식별된 미디어 포맷을 디코딩할 수 있는 미디어 코덱을 사용할 수 있다. 그 외의 프로토콜에 대한 동작은 이전 도면에서 기술한 실시 예와 동일 하다.
도 16은 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다. DASH 세그먼트를 전송하는 방식은 QUIC (Quick UDP Internet Connections) 프로토콜을 이용할 수 있다. TCP/IP를 사용한 멀티캐스트 방식은 컨넥션 (connection)을 형성하는데 딜레이(delay)가 발생 될 수 있고, 스트리밍 데이터를 즉시 전송하는데 부적합할 수 있다. QUIC 기반의 프로토콜은 컨넥션 및 플로우 (flow) 제어에 대한 과정을 QUIC에서 담당한다. 또한 QUIC는 HTTP/2를 사용할 수 있으며, 이로 인해 기존의 HTTP에서 발생하는 전송 지연을 개선할 수 있으며, UDP/IP를 이용하여 스트리밍 데이터를 즉시 전송 할 수도 있다. 그 외의 protocol에 대한 동작은 앞서 기술한 실시 예와 동일 하다.
도 17은 본 발명의 일 실시예에 따른 DASH 전송 방식을 나타낸다. DASH 시스템은 HTTP 서버 및 DASH 클라이언트 간의 데이터 송수신으로 구현될 수 있다. 여기서 DASH 클라이언트는 DASH 억세스 엔진(access engine) 및 미디어 엔진 (media engine)을 포함할 수 있다. DASH에서 HTTP 서버는 다양한 품질의 콘텐트를 일정한 시간 단위의 조각(segment)으로 분할하여 서버에 저장할 수 있다. HTTP 서버는 사용자 디바이스인 DASH 클라이언트의 미디어 요청 시에 분할된 데이터 단위를 HTTP 프로토콜을 이용하여 전송할 수 있다. 여기서 유동적인 HTTP 네트워크 상태를 고려하여, 다양한 품질로 HTTP 서버에 저장되어 있는 미디어 콘텐츠를 선택적으로 전송할 수 있다. 이로 인해, 사용자는 끊김 없는 적응적 스트리밍 서비스를 수신할 수 있다. 위에서 설명한 분할된 파일들에 대한 타임라인 (timeline) 순서 및 품질의 순서에 대한 정보를 포함하는 별도의 파일이 MPD (Media Presentation Description)이다. MPD는 DASH 클라이언트에게 HTTP 서버에 저장된 미디어 데이터에 대한 정보를 제공할 수 있다. MPD는 XML문서로써, 분할된 세그먼트에 부여된 각 URL, 시작시간, 컨텐트 종류 등의 속성을 포함할 수 있다. DASH 클라이언트는 미디어 파일의 수신에 선행하여 서버에 MPD 파일을 요청하고, MPD 파일을 수신할 수 있다. MPD 파일이 수신되면, DASH 클라이언트는 MPD에 포함된 미디어 파일에 관한 정보를 이용하여 HTTP 서버에 저장되어 있는 컨텐트에 대한 세그먼트 파일을 요청할 수 있다.
도 18은 본 발명의 일 실시예에 따른 DASH 세그먼트의 구조를 나타낸 도면이다. DASH 세그먼트는 전송할 콘텐츠를 미디어 세그먼트로 분할하여 일정 기간(duration) 동안 재생될 수 있는 전송 오브젝트의 데이터 단위이다. DASH 미디어 세그먼트는 세그먼트 유형(type)을 나타내는 'styp'박스를 포함하고, 세그먼트 인덱스 정보를 포함하는 'sidx'박스를 포함한다. 또한 DASH 미디어 세그먼트는 fragment단위로 잘려진 미디어 스트림을 포함하고 있는 'mdat'박스와 이에 대한 메타데이터를 담고 있는 'moof'박스를 포함할 수 있다. DASH 클라이언트는 서비스를 요청하기 위해 MPD 파일의 전송을 요청하고, 각 segment URL (Uniform Resource Locator)을 통해 미디어 세그먼트를 요청할 수 있다. 미디어 세그먼트를 디코딩하기 위해서, DASH 클라이언트는 초기화 정보를 담고 있는 초기화 세그먼트 (Initialization segment, IS) 파일을 수신하고 파싱하여 디코더 초기화를 수행한 후, 요청한 미디어 세그먼트 파일을 수신하여 미디어 파싱과 디코딩을 수행할 수 있다.
DASH 클라이언트가 수신하는 파일들은 미디어 재생을 위한 구성요소에 따라 구분될 수 있다. DASH 클라이언트는 Manifest 파일인 MPD, 초기화 세그먼트 파일 및 미디어 세그먼트 파일을 수신한 후 미디어를 재생할 수 있다. 따라서 송신단의 미디어 인코더는 전체 재생 블록 (MPD+IS+sidx+moof+mdat) 을 위해 미디어 데이터를 포함하는 mdat을 인코딩하고, 인코딩 정보를 포함한 메타데이터 헤더(styp+sidx+moof)를 생성할 수 있다. 이후 송신단은 디코더 초기화 정보인 IS.mp4 파일을 생성하고, 세그먼트의 URL 정보를 포함하는 MPD에 작성하여 DASH 클라이언트에게로 전송할 수 있다. 수신단의 파싱 오더(parsing order)는 다음과 같다. 수신단은 MPD 파일을 수신하여 파싱하고, 디코더를 초기화하고, 네트워크 상황에 따른 미디어 세그먼트를 요청할 수 있다.
다양한 품질로 저장된 DASH 세그먼트가 라이브(live) 타입의 서비스를 제공하거나, 라이브 방송 콘텐츠를 인코딩하여 데이터를 전송하는 서비스의 경우는 미디어 서비스 프레임워크(framework) 전체의 실시간성(real-time)이 적용되어야 한다. 따라서, seamless한 서비스의 구현을 위해 딜레이 발생을 최소화해야 한다. DASH 프로토콜을 적용한 라이브 방송시 실시간 컨텐트를 인코딩 및 패킷화하는 과정과 실시간 콘텐츠를 파싱하고 디코딩하는 과정에서 딜레이가 발생하는 경우, 서비스 시작 시점의 딜레이가 발생할 수 있다. 다시 말해, 각 미디어 파일을 생성하고 패킷화하여 송신하면, 패킷의 reception time, 파싱(parsing)을 위해서 전체 패킷이 만들어 질 때까지 기다려야 하는 지연시간이 발생할 수 있다. 이로 인해, 클라이언트 측에서는 버퍼링의 시간이 길어진다. 이와 같은 문제점을 해결하기 위해 아래와 같은 방법을 제안한다.
도 19는 본 발명의 일 실시예에 따른 멀티캐스트를 위한 네트워크 구성을 나타낸 도면이다. 전술한 실시예들과 달리 서버로부터 MPD 파일을 수신하지 않고, 멀티캐스트를 구현할 수도 있다. 이를 MPD less 방식이라고 칭할 수 있다. 멀티캐스트 서비스를 위한 DASH live 스트리밍에서, 멀티캐스트 센더인 DASH 서버는 컨텐트를 생성하고 각 세그먼트에 URL을 부여한 후, MPD를 작성 및 전송하고 스트리밍 서비스를 시작할 수 있다. 하지만, 네트워크의 불안정성 및 bit-rate에 대한 보장이 안되는 네트워크 컨디션의 상황으로 인해, 퀄리티 별로 DASH 컨텐트를 생성하고 DASH 서비스를 시작하기까지 딜레이가 발생할 수 있다. 이에 반해, 유저 네트워크 내의 통신망은 bit-rate가 보장되기 때문에 DASH 서비스를 위한 네트워크 컨디션을 지원할 수 있다.
따라서 유저 네트워크 내에 DASH 서버를 위치시키는 방법을 이용할 수 있다. 즉, 유저 네트워크까지는 기존 conventional multicast model을 유지하여, 컨텐트 네트워크에서 패킷들을 생성 후 바로 전송하는 형태를 이용할 수 있다. 유저 네트워크 내의 DASH 서버는 수신된 패킷을 모아서 세그먼트들의 URL을 생성하고, DASH hierarchy에 맞게 MPD를 생성하고 유니캐스트의 형태로 DASH 클라이언트와 스트리밍 서비스를 진행하는 방법을 사용할 수 있다. 다시 말해, 기존 DASH 서버를 유저 네트워크로 옮겨 놓고, DASH 서버가 멀티캐스트 센더로부터 수신되는 세그먼트 파일들을 모아 MPD를 업데이트하면서 서비스를 진행할 수 있다.
예를 들어, 컨텐트 서버는 HD 급의 세그먼트를 우선적으로 생성하여 멀티캐스트 센더를 통해 전송을 시작하고, 유저 네트워크의 DASH 서버는 세그먼트 패킷들 중 우선적으로 생성된 representation의 정보를 포함하는 MPD를 생성한다. 이때 멀티캐스트 네트워크 컨트롤러는 서비스 관점에서 MPD 타임슬롯 (timeslot)의 동기화 및 관리를 통해 컨트롤 패킷들을 전송할 수 있다. DASH 클라이언트인 디코딩 디바이스는 생성된 MPD를 통해 기존 DASH 모델의 따라 유니캐스트 HTTP 스트리밍을 받을 수 있다. 이를 통해 기존 DASH 클라이언트에 대한 변경 없이, 홈 게이트웨이 (Home gateway) 또는 멀티캐스트 리시버 (multicast receiver)만을 변경하여 신속한 서비스를 받을 수 있다.
도 20은 본 발명의 일 실시예에 따른 DASH 초기화 세그먼트(initialization segment)의 구조를 나타낸다. 아래에서는 DASH 세그먼트 파일의 구조 및 헤더 속성에 대해 기술한다. 세그먼트는 MPD에서 미디어 데이터를 표현할 수 있는 데이터 단위을 지칭할 수 있다. 세그먼트는 URL을 통해 지정된 바이트 범위에 대응하여 분할된 미디어 데이터이며, HTTP GET 요청에 의해 서버로부터 전송되는 미디어 파일 포맷이다. 전술한 바와 같이, DASH의 미디어 재생을 위해, DASH 클라이언트는 초기화 세그먼트(initialization segment, IS)를 통해 디코더 초기화를 수행한다. 그 후, DASH 클라이언트는 메타데이터 박스인 무비 프래그먼트 박스 (movie Fragment Box, moof)로부터 분할된 media fragment 내에 포함된 sample에 대한 timed indexing 정보 및 미디어 샘플 정보를 획득할 수 있다. 마지막으로, DASH 클라이언트는 미디어 데이터 박스 (media data box, mdat) 에 있는 미디어 샘플들의 미디어 디코딩을 진행할 수 있다.
도면 상단에 도시된 바와 같이 초기 세그먼트는 무비 박스 (Movie box, moov)를 통해 미디어 샘플의 디코딩 초기화 정보와 샘플 디스크립션 (sample description) 정보 및 샘플의 그룹핑 (grouping) 정보를 제공할 수 있다. moof 박스는 moof 박스가 정의하는 미디어 프래그먼트 (media fragment) 의 범위까지 미디어 샘플의 time indexing 정보 및 그룹핑된 미디어 샘플(grouped media sample)에 대한 디스크립션을 제공 할 수 있다.
미디어 샘플들은 moov 박스에 포함된 Sample to Group Box ('sbgp' box) 내에서 group_type을 이용하여 그룹핑될 수 있다. sbgp 박스는 도면 중단에 도시된 바와 같다. 그룹핑된 엔트리들에 대한 구체적인 디스크립션은 도면 하단에 도시된 샘플 그룹 디스크립션 박스 (sample group description box, sgpd)의 클래스를 통해 제공될 수 있다. 예를 들어 HEVC 의 temporal ID 를 통한 scalability를 준다고 한다면, Tid = 0 에 해당하는 sample 들과 Tid=1에 해당하는 미디어 샘플들을 나누어 그룹핑하고 각각에 대해 샘플 디스크립션(sample description)이 정의될 수 있다.
DASH, HLS (Http Live Streaming) 등 어댑티브 스트리밍은 전송할 컨텐트 파일과 해당 파일의 속성을 담고 있는 메타데이터의 생성까지 완료되어야 스트리밍을 시작할 수 있다. 이전 도면에서 언급한 대로 전송할 미디어 세그먼트 파일이 모두 생성되기 전에, 우선적으로 전송할 수 있는 미디어 세그먼트 파일이 기존 멀티캐스트 모델을 이용하여 전송될 수 있다. 프록시(proxy)에서 파일을 재생시킬 수 있는 ordering이 만들어지면, 우선적으로 전송된 미디어 세그먼트 파일을 재생할 수 있도록 manifest (ex. MPD) 파일이 생성될 수 있다. 즉, 기존 멀티캐스트 모델에 따라, 멀티캐스트 ABR 모델 내 멀티캐스트 리시버 또는 프록시에 멀티캐스트 데이터가 캐싱 (caching) 되거나, 수신 가능한 유니캐스트 (unicast) 패킷들이 캐싱되면, 특정 시점을 기준으로 멀티캐스트 리시버 또는 프록시에서 MPD 를 만들 수 있다. 복수의 품질로 저장된 DASH 세그먼트가 linear 서비스를 제공하는 경우, 복수의 품질에 해당하는 세그먼트들을 IP 네트워크로 순차적으로 전송해야 하고, 이로 인해 서비스 딜레이가 발생할 수 있다. 이를 극복하기 위해, 빠른 데이터 수신과 일부 미디어 세그먼트를 우선적으로 수신하여 신속하게 재생(playback) 할 수 있다. 아래에서는 데이터의 크기 및 재생 가능한 단위로의 수신하는 시간을 고려하여, 패킷 전송의 우선순위를 정의할 수 있다. 이를 통해 우선순위에 따른 패킷 전송으로 인해 재생 가능한 단위의 렌더링(rendering)이 신속해지므로, 시작 delay 가 낮아질 수 있다.
도 21은 본 발명의 일 실시예에 따른 DASH 세그먼트를 발생하는 과정을 나타낸 도면이다. 즉, 전송될 세그먼트는 도시된 gernerating order에 따라 생성될 수 있으며, 전송블록에 따라 전송될 수 있다. 미디어 세그먼트는 도시된 바와 같이 Quality가 높아질수록 세그먼트 길이가 길어지므로, 전체 세그먼트를 생성하고 전송하는데 지연시간(delay)이 발생할 수 있다. 따라서, 상기 세그먼트 중 신속하게 startup 할 수 있는 세그먼트를 별도로 생성하고, 전송할 필요가 있다. 또한 생성된 블록에 따라 만들어진 데이터를 전송 오브젝트에 따라 부분적으로 패킷화하여 전송해야 한다. 이를 위해 상기 패킷에는 전체 sequence가 아닌 RAP가 가능한 I 프레임만을 포함한 object을 전송할 수 있다. 도시된 바와 같이, 생성 순서(generating order)에 따라 1,2,3,4,5,6을 생성한 후, 전송 오브젝트는 I 프레임만을 포함하도록 구성할 수 있다. 이러한 전송 오브젝트가 수신단에서 수신되는 경우, 수신단은 전송오브젝트를 수신하는 즉시 RAP를 통한 디코딩을 수행할 수 있다. 이후 송신단은 연속하여 나머지 media chunk 패킷을 포함하는 오브젝트를 전송하여 수신단의 후속 프레임들에 대한 재생을 가능하게 할 수 있다. 위에서 설명한 I 프레임만을 선택적으로 포함하는 전송 오브젝트를 송신하는 모드를 패스트 스타트업 모드(fast startup mode)라고 하고, 이를 위해 protocol의 확장을 통해 multicast ABR을 구현할 수 있다.
도 22는 본 발명의 일 실시예에 따른 moov 내에서의 디코딩 샘플 그룹핑을 나타낸 도면이다. 송신단에서 전송 패킷 단위로 미디어 데이터를 전송하면, 수신단에서는 수신된 미디어 데이터를 모아서 재생 가능한 오브젝트를 통해 DASH 세그먼트 또는 재생 가능한 파일이 생성되고, 이에 대한 재생을 시작할 수 있다. 이전 도면에서 설명한 바와 같이, 송신단은 미디어 데이터 패킷에, 복수의 프레임들 중 신속하게 재생 가능한 프레임(I 프레임)만을 선택적으로 포함시키고, 이를 우선적으로 먼저 전송하여 수신단의 startup delay 타임을 줄일 수 있다.
ISOBMFF 등의 파일 포맷(file format)의 헤더의 정보에서 sample 들의 디코딩 의존도 (decoding dependency)를 그룹핑하고, 데이터의 수신 시 재생 가능한 프레임의 시퀀스를 정의하면, 파일이 모두 만들어지지 않아도 재생할 수 있는 장점이 있다. 이를 위해 도 20에서 moov 박스 내의 샘플 그룹핑 (sample grouping)을 확장할 수 있다. 수신단은 수신된 순서대로 프레임들을 모으고, 그룹핑 된 프레임들이 모이면 바로 디코딩을 시작할 수 있다. 이를 통해 수신단은 전체 GOP (group of picture) 또는 mdat 이 수신되지 않아도, 디코딩 가능한 단위만 수신되면 디코딩을 바로 시작하여 딜레이를 줄일 수 있다.
도면 상단에 도시된 바와 같이, 첫번째 실시예로써 송신단은 전송될 샘플들 중 독립적으로 디코딩이 가능한 I 프레임 (I0)을 그룹핑하여 전송할 수 있다. 수신단은 segment 의 디코딩 헤더 정보 (IS 및 moof) 와 group entry의 샘플들이 도착하면 즉시 디코딩을 시작할 수 있다. 또한 송신단은 B2, B3, B4 및 단방향 예측을 하는 P1의 프레임까지 그룹핑하여 송신하고, 수신단은 B2, B3, B4, P1이 도착하면 해당 그룹을 디코딩할 수 있다. 도 22에서 샘플들 중 leading picture를 포함하는 I 프레임인 CRA(clean random access) picture (I5)도 샘플 그룹핑을 통해 수신단에서 수신되는 때 바로 디코딩이 가능하도록 할 수 있다. 수신기는 moov에 있는 샘플 그룹핑 정보에 기초하여 B6, B8, I5 프레임이 수신되면 I5, B6, B7, B8 의 프레임까지 즉시 디코딩을 시작할 수 있다. MPEG 비디오 압축 원리를 이용하여, I 프레임과 단방향 예측을 하는 P 프레임까지 비디오 디코딩 버퍼에 존재한다면, P 이전까지의 프레임들은 모두 디코딩이 가능하기 때문에 파일 전체를 모두 수신하지 않고 그룹핑된 entry 만 재생이 미리 가능하다. 파일 전체를 수신하지 않고 entry 를 재생시키기 위한 정보로 아래와 같이 정의하고 자 한다. 아래에서 설명하는 dependency_sample_number 필드는, 파일 전체를 모두 수신하지 않은 상황에서도, 그룹핑된 해당 그룹 entry 만을 미리 재생할 수 있도록, 비디오 디코딩 버퍼에서 홀딩하고 있어야 하는 샘플을 의미한다.
이와 같이 송신단은 moov 박스 내에 포함된 샘플 그룹 디스크립션 박스 (SampleGroupDescriptionBox, sgpd)에 샘플 그룹핑 정보를 포함시켜 전송할 수 있다. 샘플 그룹핑 정보는 sgpd 내의 fssg 박스 내에 포함될 수 있다. fssg 박스에 대한 자세한 설명은 아래에서 하도록 한다.
두번째 실시예로써, 송신단은 moof를 통해 잘려진 movie fragment 의 단위에서 샘플 그룹핑을 수행할 수 있다. 샘플 그룹핑은 디코딩이 가능한 단위로 수행되므로, 모든 데이터가 수신되기 이전이라도 fast startup이 가능하고, 이를 통해 delay를 줄일 수 있다. 송신단은 moof 박스 내에 포함된 sgpd 박스에 샘플 그룹핑 정보를 포함시켜 전송할 수 있다. 샘플 그룹핑 정보는 sgpd 내의 fssg 박스 내에 포함될 수 있다.
fssg 박스의 신택스 구조는 도시된 바와 같다. fssg 박스는 group_entry_number, group_entry_offset, Delivery_event, Dependency_count 및 dependency_sample_number 필드 중 적어도 하나를 포함할 수 있다. group_entry_number 필드는 전체 샘플 시퀀스 내에서 그룹핑 된 샘플들을 순서대로 나열한 디코딩 그룹의 순서를 나타낼 수 있다. Group_entry_offset 필드는 디코딩 순서의 group의 처음 위치에 대한 offset값을 나타낼 수 있다. Delivery_event 필드는 각 그룹이 가진 미디어 이벤트의 속성을 정의할 수 있다. 예를 들어, Delivery_event가 0x0의 값을 가진 경우 default, 0x1의 값을 가진 경우 Normal picture group, 0x2의 값을 가진 경우 IDR (instantaneous decoding refresh) picture를 포함하는 그룹, 0x3의 값을 가진 경우 CRA picture를 포함하는 그룹을 나타낼 수 있다. Dependency_count 필드는 각 그룹 내에 포함된 picture/sample의 개수를 나타낼 수 있다. dependency_sample_number 필드는 해당 그룹 내 디코딩을 위해 비디오 디코딩 버퍼에 홀딩하고 있어야하는 샘플을 의미할 수 있다. 즉, dependency_sample_number 필드는, 파일 전체를 모두 수신하지 않은 상황에서도, 그룹핑된 해당 그룹 entry 만을 미리 재생할 수 있도록 비디오 디코딩 버퍼에서 홀딩하고 있어야 하는 샘플을 의미한다.
도 23은 본 발명의 일 실시예에 따른 샘플 그룹핑 moof를 나타낸 도면이다. 송신단은 미디어 데이터를 전송하기 위해 미디어 데이터에 대한 인코딩 및 file format 생성을 수행한 후 전송을 시작한다. 즉, 도 21에서 설명한 바와 같이, 송신단은 mdat에 해당하는 미디어 데이터를 인코딩하고, 미디어 데이터의 동기화 정보 및 속성정보를 포함하는 파일 포맷 헤더를 만드는 순서로 세그먼트 파일을 생성한다. 이러한 순서로 동작하는 경우, 송신단은 미디어 데이터가 모두 인코딩 된 후에야 파일 포맷 헤더를 생성할 수 있으며, 따라서 미디어 데이터 전체에 대한 인코딩이 완료되어야 전송이 시작되는 문제점이 발생한다. 이로 인해 end to end delay time이 증가할 수 있다. 따라서 미디어 프레임 전송 간격을 줄이는 방법을 이용하면, 수신기에서 미디어 데이터 전체가 수신되기 전이라도, 수신기가 렌더링을 수행할 수 있는 효과가 있다. 아래에서는 이에 대해 설명한다.
도 22에서 설명한 방식은, 수신기가 세그먼트 내의 moov 또는 moof에 포함된 샘플 그룹핑 정보를 이용하여, 수신된 특정 그룹에 해당하는 프레임 디코딩을 시작하는 방식이다. 즉, 이 방식은 송신단에서 전체 미디어 데이터가 생성된 후, 전체 미디어 데이터에 대한 샘플 그룹핑 정보를 생성하고, 이를 통해 수신단의 디코딩 딜레이를 감소시키는 방식이다. 이에 비해, 본 실시예는 송신단에서 하나의 moof 가 커버하는 세그먼트의 미디어 프레임을 모두 인코딩한 후 전송하는 대신, 의미있는(meaningful) 단위로 전송하는 방법이다. moof 는 sample number 시작점, offset, duration을 통해 프레임이 프리젠테이션 될 수 있는 범위를 나타낼 수 있다. 따라서 송신단이 moof가 커버하는 범위를 전술한 샘플 그룹핑 단위로 한정하고, 이에 따라 샘플 그룹핑 단위로 각각 moof 를 만들어서 보내면, 수신단은 빠른 디코딩을 할 수 있다. 즉 도시된 바와 같이, 송신단은 프레임 I0를 그룹핑하여 제1 moof와 함께 전송하고, B2, B3, B3 및 P1을 그룹핑하여 제2 moof와 함께 전송하고, B6, B7, B8 및 I5를 그룹핑하여 제3 moof와 함께 전송할 수 있다. 이와 같이 송신단에서의 전송 단위를 샘플 그룹핑 단위로 정의하고, 샘플 그룹 마다 moof를 생성하여 전송하여, 전체 미디어 데이터에 대한 인코딩으로 인한 딜레이를 감소시킬 수 있다. 즉, 각 moof의 커버리지가 짧아지고, 그룹 내 참조관계를 통해 수신단은 미리 프레임을 디코딩 할 수 있다. 따라서 송신단은 미디어 데이터 파일이 모두 만들어지는데 소요되는 시간을 줄이는 out of order의 방법으로 미디어 데이터를 전송할 수 있다. Moof 내에서 decoding order와 presentation order의 차이를 보상해주는 것은 composition_time_offset 값을 통해서 가능하다. composition_time_offset 은 ISOBMFF trun box 내에서 정의될 수 있다. 도 22 및 도 23의 송신단과 수신단이 동작하는 과정을 타임라인으로 만들면 도면 하단에 도시된 바와 같다. In order 방식은 미디어 데이터를 모두 인코딩 한 후, 미디어 프레임을 동작할 수 있는 moof 만들고, 그 다음 delivery 가 시작된다. Normal play 방식의 경우 수신단은 56번 샘플까지 모두 생성한 후, 재생이 가능하다. 반면, in order sample grouping 방식의 경우 수신단은 decoding dependency에 따른 sample grouping 정보 기반 파일이 모두 도착하기 전이라도 재생이 가능하다. 즉 도시된 바와 같이 즉각적으로 디코딩이 가능한 I frame을 포함하는 그룹이 수신되면 신속하게 startup 이 가능하다. Normal play 방식과 in order sample grouping 방식은 딜리버리 가능 시점은 동일하다.
이에 비해 out order sample grouping 방식의 경우, 딜리버리 시점이 앞당겨질 수 있다. out order sample grouping 방식에서 송신단은 sample grouping 에 따라 프레임이 만들어지면 moof를 생성한 후 바로 전송할 수 있다. 즉, 전체 미디어 데이터가 인코딩되기 전이라도, 첫번째 샘플 그룹 및 첫번째 moof가 생성되면 전송을 시작할 수 있다. 이로 인해, out order sample grouping은 인코딩 딜레이를 줄일 수 있는 효과를 제공한다. 기존 방식이 하나의 파일에 대해 하나의 moof를 생성하는 것에 비해, 본 발명의 일 실시예는 샘플 그룹 별로 복수의 moof를 생성하고 삽입함으로써 전송 시점까지의 인코딩 딜레이를 단축시키는 효과를 제공할 수 있다. 도시된 바와 같이 송신단은 첫번째 샘플 그룹의 프레임이 생성되면, 두번째 샘플 그룹의 프레임을 생성하는 것과 병행하여 첫번째 샘플 그룹의 프레임에 대한 moof를 생성할 수 있다. 또한 이렇게 생성된 moof는 실시예에 따라 도시된 바와 같이 첫번째 샘플 그룹의 프레임이 전송된 이후에 전송되거나, 이전에도 전송될 수 있다.
따라서 delivery 가 빨라지고, 수신단은 in order sample grouping 방식에 비해 프레임을 미리 디코딩할 수 있다. 여기서, AU (access unit)들을 묶는 단위에 대해, 위에서 언급한 decoding dependency 에 따른 moof의 삽입이 가능하다면, 수신단은 latency를 줄이고 빠른 디코딩을 수행할 수 있다. out order sample grouping 의 경우, sample 혹은 비디오를 인코딩 하고 헤더 없이 미리 전송하여 인코딩 딜레이를 줄일 수 있다. 따라서, 위에서 설명한 짧은 주기의 moof 를 sample grouping 주기에 대응하여 생성하고 전송할 수 있다. 이로 인해, 기존 movie fragment 인코딩 시간보다 본 발명의 일 실시예에 따른 movie fragment 인코딩 시간이 줄어들 수 있다. 수신단에서는 샘플 그룹에 속한 비디오 데이터를 수신하고, moof 에 있는 sample grouping 정보를 통해 비디오 데이터를 재생할 수 있다.
도 24는 본 발명의 일 실시예에 따른 디코더 configuration 레코드(decoder configuration record)의 확장을 나타낸 도면이다. 디코더 초기화 정보가 별도의 시그널링 정보를 통해 수신되지 않는 한, initialization segment (IS)는 미디어 서비스를 제공하는 디코더를 초기화 하기 위해 필요하다. 수신단 디코더가 이전 도면에서 설명한 샘플 그룹핑 및 버퍼링을 통한 디코딩 동작을 수행하기 위해서는 샘플 그룹핑 및 버퍼링 모드가 적용되었음을 송신단이 디코더에게 알려주어야 한다. 즉, 디코더에 대해, 버퍼링을 통한 decoding processing이 가능하다는 초기화 정보를 전달해야 하며 이를 위해 IS가 이용될 수 있다. 따라서 IS에 버퍼링 모델에 대한 정보를 추가 하여, 디코더가 low latency를 위한 버퍼링 모델을 수행하도록 디코더를 초기화 할 수 있다. 해당 정보는 14496-15 HEVC file format에서 샘플의 속성에 대한 configuration 정보를 정의하는 HEVC decoder configuration record (D.C.R) 내에 정의될 수 있다. HEVC decoder configuration record는 샘플의 디코더 초기화 정보(HEVC video VPS, SPS, PPS) 내용들을 포함하고, 비디오 크로마, 루마 속성과 HDR을 transfer characteristic 정보를 포함할 수 있다. HEVC decoder configuration record 정보는 도면 상단에 표시된 바와 같이 샘플들의 디스크립션 (description)을 제공하는 샘플 디스크립션 박스 (sample description box, stsd)에 포함된 HEVC Configuration Box (hvcC)의 sample entry 정보에 포함될 수 있다. HEVC decoder configuration record는 media event의 정보를 포함할 수 있다. media event의 정보는 현재 송수신되는 스트림의 속성이 low latency를 위한 버퍼링의 모드임을 나타내는 초기화 정보로서 initialization segment 에 정의될 수 있다. 즉 IS 내의 샘플 디스크립션에 포함된 media event는 수신단 디코더를 초기화함에 있어서, 위에서 설명한 low latency를 위한 버퍼링 모드가 적용된 데이터가 수신됨을 디코더에게 알려줄 수 있다.
도 25는 본 발명의 일 실시예에 따른 샘플 그룹핑 방식을 이용한 재생 가능 시점에 대한 비교를 나타낸 도면이다. 도시된 바와 같이 시뮬레이션 조건은 4k HEVC video, GoP 56 샘플, 2571475 바이트의 mdat, 데이터 레이트 25 Mbps를 기준으로 하였다. 도면 상단의 Normal playing 방식의 경우, 송신단(Encoder & server side)은 56개의 샘플이 모두 완성된 후 moof를 작성하여 전송한다. 수신단 (Receiver side; in order)은 moof를 수신하고 전체 GoP에 해당하는 56개의 샘플을 모두 수신한 후 비로소 미디어 데이터에 대한 재생(playback)을 시작할 수 있다. 이에 소요되는 수신 시간, 즉 재생을 시작할 수 있는 시간은 0.82 sec였다.
도면 하단의 Sample grouping (In order) 방식의 경우, 위와 동일한 조건에서 sample group entry를 8 entries로 설정하였다. 즉, 하나의 샘플 그룹이 8개의 샘플로 구성되며, 샘플 그룹은 위에서 설명한 바와 같이 디코딩 의존도 (decoding dependency)를 이용하여 그룹핑된다. 따라서 하나의 그룹 내에 포함된 8개의 샘플만 모두 수신되면 수신단은 디코딩을 시작할 수 있다. 이를 통해 수신단은 전체 GOP (group of picture) 또는 mdat 이 수신되지 않아도, 디코딩 가능한 단위만 수신되면 디코딩을 바로 시작하여 딜레이를 줄일 수 있다.
Sample grouping (In order) 방식의 송신단(Encoder & server side)은 Normal playing 방식과 마찬가지로 56개의 샘플이 모두 생성된 후 moof를 작성하여 전송한다. Sample grouping 의 효과는 수신단에서 확인할 수 있다. 수신단 (Receiver side; in order)은 moof를 수신하고 첫번째 샘플인 I 프레임을 수신하면 재생을 시작할 수 있다. 또한 첫번째 그룹에 해당하는 첫번째 샘플부터 여덟번째 샘플까지의 샘플들이 모두 수신되면 즉시 디코딩하고 재생할 수 있다. 또한 두번째 그룹에 속하는 아홉번째 샘플부터 열여섯번째 샘플이 모두 수신되면 두번째 샘플 그룹에 대한 재생도 시작할 수 있다. 이로 인해 Sample grouping (In order) 방식을 사용하는 수신단은 0.3sec, 0.38 sec, 0.46 sec, 0.53 sec, 0.61 sec, 0.68 sec, 0.75 sec, 0.82 sec에 각각 재생을 시작할 수 있었다. 따라서 샘플 그룹핑을 통해 수신단은 각 샘플 그룹에 속하는 샘플들의 수신이 완료될 때마다 재생을 시작할 수 있는 효과를 제공하였으며, 이로 인해 latency를 감소시킬 수 있었다.
도 26은 본 발명의 일 실시예에 따른 샘플 그룹핑 방식을 이용한 재생 가능 시점에 대한 비교를 나타낸 도면이다. 본 도면은 sample grouping (out order) 방식, sample grouping (in order) 방식 및 normal playing 방식 간의 재생 시작 가능시간은 비교한 것이다. 도면 상단의 sample grouping (out order) 방식의 송신단은 첫번째 샘플에 대한 인코딩이 완료되면, 두번째 샘플을 인코딩하면서 첫번째 샘플에 대한 moof1을 생성한다. 또한 송신단은 첫번째 샘플 그룹인 두번째 샘플부터 15번째 샘플에 대한 인코딩이 완료되면, 16번째 샘플을 인코딩하면서 두번째 샘플 그룹에 대한 moof2를 생성한다. 이러한 방식으로 송신단은 샘플 그룹별로 moof를 각각 생성할 수 있다. 또한 송신단은 moof1이 생성되면, 전송(delivery)을 시작할 수 있다. 수신단은 첫번째 샘플 및 moof1이 수신되면 디코딩 및 재생을 시작할 수 있다. 첫번째 샘플은 I frame 이므로 수신단 디코더는 IDR (instantaneous decoding refresh) playback을 수행할 수 있다. 또한 첫번째 샘플 그룹에 속하는 샘플들 및 moof2가 수신되면 해당 샘플 그룹에 대한 재생도 시작할 수 있다.
도면 중단의 sample grouping (in order) 방식의 송신단은 모든 샘플들에 대한 인코딩 및 전체 샘플에 대한 moof를 생성하여 전송하므로, 수신단의 첫번째 moof 수신 시점이 out order 방식에 비해 느리다. 수신단은 moof 및 첫번째 샘플을 수신하면 IDR playback을 시작할 수 있다. 이를 상기 out order 방식과 비교하면 0.5 sec의 재생 시작 시간 차이가 발생하였다.
도면 하단의 Normal playing 방식은 moof 및 전체 56개 샘플에 대한 수신이 완료된 후에 IDR playback을 시작할 수 있다. 이를 상기 out order 방식과 비교하면 1 sec의 재생 시작 시간 차이가 발생하였다.
도 27은 본 발명의 일 실시예에 따른 수신기 구조를 나타낸 도면이다. 수신기는 tuner를 이용하여 방송 신호 또는 멀티캐스트 신호를 수신할 수 있다. 수신기는 ADC (Analog Digital converter)를 이용하여 아날로그 신호를 디지털 신호로 변환하고, Demodulator를 이용하여 수신된 신호를 복조(demodulating)할 수 있다. 수신기는 channel sync. & EQ를 이용하여 수신된 신호에 대해 동기화 및 이퀄라이징을 수행하고, 채널 디코더를 이용하여 수신된 신호에 대한 디코딩을 수행할 수 있다. 디코딩된 신호는 L1(layer 1) 시그널링 파서에 의해 파싱되어 수신기는 L1 시그널링 정보를 획득할 수 있다. L1 시그널링 정보는 수신기의 baseband controller에 전달되어 피지컬 레이어 데이터를 획득하는데 사용될 수 있다. 또한 L1 시그널링 정보는 수신기의 시그널링 컨트롤러에 입력될 수 있다. 또한 디코딩된 신호는 링크 레이어 인터페이스에 입력되어 L2 시그널링 파서에 의해 파싱되고, L2 시그널링 정보는 시그널링 컨트롤러에 입력될 수 있다. 시그널링 컨트롤러는 서비스 시그널링 채널 (service signaling channel, ssc) 프로세싱 버퍼 및 파서와 커뮤니케이션 할 수 있으며, 이를 통해 서비스 MAP DB(data base)를 업데이트 할 수 있다. 또한 서비스 가이드 (service guide, SG) 프로세서는 서비스 가이드 DB를 업데이트할 수 있다. 수신기는 시그널링 컨트롤러에 입력된 시그널링 정보에 따라 패킷 헤더를 복원하고 IP 패킷 필터를 이용하여 IP 패킷을 수신할 수 있다. 또한 수신기의 네트워크 스위치는 유무선 통신을 통해 IP 패킷을 수신할 수 있으며, TCP/IP 스택을 통해 이를 수신할 수 있다. 이렇게 수신된 IP 패킷은 common protocol stack을 거쳐 A/V 서비스 컨트롤러에 입력된다. 수신기의 디멀티플렉서는 오디오 데이터와 비디오 데이터를 역다중화할 수 있다. 수신기는 오디오 디코더 및 오디오 렌더러(renderer)를 이용하여 오디오 데이터를 출력하고, 비디오 디코더 및 비디오 렌더러(renderer)를 이용하여 비디오 데이터를 출력할 수 있다.
도 28은 본 발명의 일 실시예에 따른 컨텐트 서버 및 컨텐트 리시버를 나타낸 도면이다. 컨텐트 서버는 인코더(d28010) 및 송신부(d28020)를 포함할 수 있으며, 컨텐트 리시버는 수신부(d28030) 및 디코더(d28040)를 포함할 수 있다. 컨텐트 서버는 인코더(d29010)를 이용하여 컨텐트를 생성할 수 있으며, 이전 도면들에서 설명한 바와 같이 생성된 컨텐트의 샘플들을 디코딩 디펜던시에 기초하여 그룹핑할 수 있다. 또한 컨텐트 서버의 인코더는 그룹핑된 샘플에 대한 그룹핑 정보를 ISOBMFF 파일의 moov 박스 또는 moof 박스에 포함시킬 수 있다. 이와 같이 그룹핑된 샘플들은 샘플 그룹핑 방식 중 in order 또는 out order 방식으로 전송될 수 있다. 또한 전술한 바와 같이, 실시예에 따라 인코더는 샘플 그룹핑 (out order) 방식을 위해 샘플 그룹 별로 moof를 생성할 수 있다. 또한 인코더는 low latency를 지원하는 샘플 그룹핑 및 버퍼링 모드를 지원함을 나타내는 정보를 IS에 포함시켜 전송할 수 있다. 컨텐트 서버는 송신부(d29020)를 이용하여 미디어 샘플 및 메타데이터(moof)를 전송할 수 있다.
컨텐트 리시버는 수신부(d28030)를 이용하여 컨텐트 서버로부터 미디어 데이터를 수신할 수 있다. 컨텐트 리시버의 수신부(d28030)는 미디어 데이터에 포함된 미디어 샘플 및 메타데이터(moof)를 수신할 수 있다. 전술한 바와 같이 미디어 샘플들은 그룹핑되어, 샘플 그룹핑 정보와 함께 수신될 수 있다. 디코더(d28040)는 샘플 그룹핑 방식에 따라 디코딩 및 재생을 시작할 수 있다. 도 26에서 설명한 바와 같이 디코더는 I 프레임으로 구성된 첫번째 샘플 및 moof가 수신되었을 때 재생을 시작할 수 있으며, 그 이후에는 각 샘플 그룹이 수신 완료될 때마다 해당 샘플 그룹에 대한 재생을 시작할 수 있다.
도 29는 본 발명의 일 실시예에 따른 컨텐트 서버의 동작 방법을 나타낸다. 컨텐트 서버는 미디어 샘플을 인코딩할 수 있다(ds29010). 미디어 샘플은 ISOBMFF 파일 형식의 mdat으로 인코딩될 수 있다. 컨텐트 서버는 인코딩된 미디어 샘플에 대한 샘플 그룹핑 정보를 포함하는 메타데이터를 생성할 수 있다. 메타데이터는 ISOBMFF의 moof 박스 또는 moov 박스에 포함되어 전송될 수 있다. 샘플 그룹핑 정보는 인코딩된 미디어 샘플들 간의 디코딩 디펜던시에 기초하여 생성될 수 있다. 또한 컨텐트 서버는 샘플 그룹핑에 의해 생성된 샘플 그룹마다 moof를 생성하여 전송할 수 있다. 이 경우, 컨텐트 서버는 각 샘플 그룹 별로 moof가 생성된 때, 해당 샘플 그룹에 대한 전송을 시작할 수 있다. 또한 컨텐트 서버는 low latency를 지원하는 샘플 그룹핑 및 버퍼링 모드를 지원함을 나타내는 정보를 IS에 포함시켜 전송할 수 있다. 컨텐트 서버는 인코딩된 미디어 샘플 및 메타데이터를 전송할 수 있다 (ds29030).
도 30은 본 발명의 일 실시예에 따른 컨텐트 리시버의 동작 방법을 나타낸다. 컨텐트 리시버는 컨텐트 서버로부터 미디어 데이터를 수신할 수 있다(ds30010). 미디어 데이터는 ISOBMFF 파일 형식일 수 있으며, 메타데이터 및 미디어 샘플을 포함할 수 있다. 메타데이터는 샘플 그룹핑 정보를 포함할 수 있으며, 샘플 그룹핑 정보는 moof 박스 또는 moov 박스에 포함되어 전송될 수 있다. 컨텐트 리시버는 미디어 데이터에 포함된 메타데이터로부터 샘플 그룹핑 정보를 획득할 수 있다(ds30020). 컨텐트 리시버는 샘플 그룹핑 정보에 기초하여 특정 미디어 샘플을 버퍼링할 수 있다. 컨텐트 리시버는 샘플 그룹핑 정보를 이용하여 미디어 샘플들을 디코딩할 수 있다(ds30030). 이를 통해 컨텐트 리시버는 전체 GoP 또는 전체 mdat이 수신되기 전이라도, 샘플 그룹 별로 디코딩을 실시하여 디코딩 latency를 줄일 수 있다.
본 발명의 실시예에 따르면, 기존의 방송 네트워크 (network), 인터넷 (internet), 홈네트워크 (home network) 등에 속해있는 장치들(devices) 사이의 멀티캐스트 (multicast) 전송을 효과적으로 제공할 수 있다.
본 발명의 실시예에 따르면, 기존 unicast 전송을 multicast로 전환하여 network의 부하를 감소시킬 수 있다.
본 발명의 실시예에 따르면, 리니어 (Linear) 서비스 및 실시간 라이브 인코딩 시 네트워크 상황에 따라 발생되는 딜레이 문제를 극복하고, 신속한 컨텐츠의 재생 시작 (AV startup)을 지원할 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 당업자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.
본 발명에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상술한 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 발명의 영상 처리 방법은 네트워크 디바이스에 구비된 프로세서가 읽을 수 있는 기록매체에 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수가 있다.
발명의 실시를 위한 형태는 위의 발명의 실시를 위한 최선의 형태에서 함께 기술되었다.
본원 발명은 방송 및 비디오 신호 처리 분야에서 사용 가능하고 반복 가능성이 있는 산업상 이용가능성이 있다.

Claims (15)

  1. 미디어 샘플들을 인코딩하는 단계;
    상기 인코딩된 미디어 샘플들에 대한 샘플 그룹핑 정보를 포함하는 메타데이터를 생성하는 단계; 및
    상기 인코딩된 미디어 샘플들 및 상기 생성된 메타데이터를 전송하는 단계를 포함하는 미디어 데이터 송신 방법으로써,
    상기 샘플 그룹핑 정보는 상기 미디어 샘플들의 디코딩 디펜던시에 기초하여 적어도 하나의 미디어 샘플을 포함하는 샘플 그룹 각각을 나타내는 정보인 것을 특징으로 하는 미디어 데이터 송신 방법.
  2. 제 1 항에 있어서,
    상기 미디어 샘플 및 상기 메타데이터는 ISOBMFF (ISO base media file format) 파일 형식으로 인코딩되는 미디어 데이터 송신 방법.
  3. 제 2 항에 있어서,
    상기 샘플 그룹핑 정보는 상기 ISOBMFF 파일 내의 무비 프래그먼트 박스 (movie Fragment Box, moof) 또는 무비 박스 (Movie box, moov)에 포함되는 미디어 데이터 송신 방법.
  4. 제 1 항에 있어서,
    상기 메타데이터를 생성하는 단계는 상기 샘플 그룹마다 무비 프래그먼트 박스 (movie Fragment Box, moof) 생성하는 것을 특징으로 하는 미디어 데이터 송신 방법.
  5. 미디어 샘플들을 인코딩하고 상기 인코딩된 미디어 샘플들에 대한 샘플 그룹핑 정보를 포함하는 메타데이터를 생성하는 인코더; 및
    상기 인코딩된 미디어 샘플들 및 상기 생성된 메타데이터를 전송하는 송신부를 포함하는 미디어 데이터 송신 장치로써,
    상기 샘플 그룹핑 정보는 상기 미디어 샘플들의 디코딩 디펜던시에 기초하여 적어도 하나의 미디어 샘플을 포함하는 샘플 그룹 각각을 나타내는 정보인 것을 특징으로 하는 미디어 데이터 송신 장치.
  6. 제 5 항에 있어서,
    상기 미디어 샘플 및 상기 메타데이터는 ISOBMFF (ISO base media file format) 파일 형식으로 인코딩되는 미디어 데이터 송신 장치.
  7. 제 6 항에 있어서,
    상기 샘플 그룹핑 정보는 상기 ISOBMFF 파일 내의 무비 프래그먼트 박스 (movie Fragment Box, moof) 또는 무비 박스 (Movie box, moov)에 포함되는 미디어 데이터 송신 장치.
  8. 제 5 항에 있어서,
    상기 메타데이터를 생성하는 단계는 상기 샘플 그룹마다 무비 프래그먼트 박스 (movie Fragment Box, moof) 생성하는 것을 특징으로 하는 미디어 데이터 송신 장치.
  9. 미디어 데이터를 수신하는 단계;
    상기 미디어 데이터에 포함된 샘플 그룹핑 정보를 획득하는 단계; 및
    상기 샘플 그룹핑 정보를 이용하여 미디어 샘플을 디코딩하는 단계를 포함하는 미디어 데이터 수신 방법으로써,
    상기 샘플 그룹핑 정보는 상기 미디어 샘플들의 디코딩 디펜던시에 기초하여 적어도 하나의 미디어 샘플을 포함하는 샘플 그룹 각각을 나타내는 정보인 것을 특징으로 하는 미디어 데이터 수신 방법.
  10. 제 10 항에 있어서,
    상기 미디어 데이터는 ISOBMFF (ISO base media file format) 파일 형식인 것을 특징으로 하는 미디어 데이터 수신 방법.
  11. 제 11 항에 있어서,
    상기 샘플 그룹핑 정보는 상기 미디어 데이터 내의 무비 프래그먼트 박스 (movie Fragment Box, moof) 또는 무비 박스 (Movie box, moov)에 포함된 것을 특징으로 하는 미디어 데이터 수신 방법.
  12. 제 10 항에 있어서,
    상기 메타데이터는 상기 샘플 그룹마다 생성된 무비 프래그먼트 박스 (movie Fragment Box, moof)를 포함하는 것을 특징으로 하는 미디어 데이터 수신 방법.
  13. 미디어 데이터를 수신하는 수신부; 및
    상기 미디어 데이터에 포함된 샘플 그룹핑 정보를 획득하고 상기 샘플 그룹핑 정보를 이용하여 미디어 샘플을 디코딩하는 디코더를 포함하는 미디어 데이터 수신 장치로써,
    상기 샘플 그룹핑 정보는 상기 미디어 샘플들의 디코딩 디펜던시에 기초하여 적어도 하나의 미디어 샘플을 포함하는 샘플 그룹 각각을 나타내는 정보인 것을 특징으로 하는 미디어 데이터 수신 장치.
  14. 제 13 항에 있어서,
    상기 미디어 데이터는 ISOBMFF (ISO base media file format) 파일 형식이고, 상기 샘플 그룹핑 정보는 상기 미디어 데이터 내의 무비 프래그먼트 박스 (movie Fragment Box, moof) 또는 무비 박스 (Movie box, moov)에 포함된 것을 특징으로 하는 미디어 데이터 수신 장치.
  15. 제 13 항에 있어서,
    상기 메타데이터는 상기 샘플 그룹마다 생성된 무비 프래그먼트 박스 (movie Fragment Box, moof)를 포함하는 것을 특징으로 하는 미디어 데이터 수신 장치.
PCT/KR2017/013110 2017-04-05 2017-11-17 방송 신호 송수신 방법 및 장치 WO2018186550A1 (ko)

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 (ko) 2018-10-11

Family

ID=63712169

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/013110 WO2018186550A1 (ko) 2017-04-05 2017-11-17 방송 신호 송수신 방법 및 장치

Country Status (1)

Country Link
WO (1) WO2018186550A1 (ko)

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 (ko) 방송 신호 송수신 방법 및 장치
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 (ko) Mmt 패킷 포맷 확장을 통한 하이브리드 전송 방법
WO2012128563A2 (ko) 이종망 기반 연동형 방송콘텐츠 송수신 장치 및 방법
WO2013077698A1 (ko) Mmt 미디어와 dash 미디어와의 연동 방법
WO2013077697A1 (ko) Ｍｍｔ 패키지화 컨텐츠의하이브리드 전송 방법 및 컨텐츠 수신 방법
US20110219414A1 (en) Method, apparatus, and system for switching channels
WO2012099423A2 (ko) 방송 시스템에서의 제어 메시지 구성 장치 및 방법
WO2013162312A1 (ko) 멀티미디어 전송 시스템을 위한 데이터 송수신 방법 및 장치
WO2012060581A2 (ko) 미디어 콘텐트 송수신 방법 및 그를 이용한 송수신 장치
WO2013141666A1 (ko) Ｍｍｔ 패키지화된 ｓｖｃ 비디오 콘텐츠의 하이브리드 전송 방법 및 수신 방법
KR20140002026A (ko) 파일 전달 방법들을 이용한 ｉｐ 브로드캐스트 스트리밍 서비스 배포
WO2016129981A1 (ko) 미디어 데이터를 송수신하는 방법 및 장치
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 (en) Hybrid delivery mechanism in a multimedia transmission system
US20110088069A1 (en) Network device, information processing apparatus, stream switching method, information processing method, program, and content distribution system
KR100948686B1 (ko) 채널 전환시 지연을 줄이기 위한 ｉｐｔｖ 방송 시스템,가속 채널 스트림의 생성 및 재생방법
WO2013187667A1 (ko) 멀티미디어 서비스를 위한 비트 에러율을 이용한 레이트 어댑테이션 방법 및 그 장치
WO2018186550A1 (ko) 방송 신호 송수신 방법 및 장치
WO2018164355A1 (ko) 멀티캐스트 신호 송수신 방법 및 장치
WO2016043432A1 (ko) 멀티미디어의 전송 또는 수신 방법 및 그 장치
WO2014010830A1 (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: 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