DE112018002893T5 - Method for transmitting and receiving a broadcast signal and an apparatus therefor - Google Patents

Abstract

The present invention relates to an apparatus and a method for transmitting and receiving a media service. A method of receiving a media service may include, in particular, the steps of: receiving and storing media presentation description information, including segment uniform resource location pointer (URL) information for media segments and timing information for presenting the media segments, receiving and storing media segments that have at least one of multicast or unicast, and output a media segment that has been requested to play content among the stored media segments; Receiving a control message comprising at least one of basic URL pattern information for identifying at least one media segment that was broadcast over the multicast and at least one of basic URL pattern information for identifying at least one media segment that was broadcast over the unicast; and updating the segment URL information in the stored media presentation description information based on the basic URL pattern information included in the received control message.

Description

Technical field

The present invention relates to an apparatus and a method for transmitting and receiving broadcast signals.

Related state of the art

With the development of digital technology and communication technology, the distribution and demand for audio / video-oriented multimedia content in various areas such as broadcasting, filming, the Internet and personal media are becoming increasingly important. In addition, since the size of TV screens in the home area is growing due to the development of display technology, broadcast services with ultra high resolution ( UHD ) increasingly a topic of conversation.

With regard to a broadcasting service, a multicast broadcasting scheme for broadcasting the same content to a plurality of users is effective because it can use both the unicast and the broadcasting. However, the conventional multicast broadcast scheme is only available within a single network and cannot support multicast service between heterogeneous networks. In addition, if file-based multicast content is broadcast in a real-time IP multicast broadcast environment, then it is a long time for the audio / video ( AV ) of the recipient.

epiphany

Technical problem

An object of the present invention is to provide a multicast signal transmission method and a corresponding device which are able to improve the transmission efficiency.

Another object of the present invention is to provide a broadcast device and a corresponding method for providing a multicast service over a broadcast network.

Another object of the present invention is to provide an apparatus and method for quickly starting playback in a receiver for a multicast service.

Another object of the present disclosure is to provide an apparatus and method compatible with an Adaptive Bit Rate (ABR) legacy service by defining a delivery method using a base URL without modifying the structure of the old manifest.

Technical solution

According to an embodiment of the present disclosure, a method for receiving a media service includes receiving and storing media presentation description information that segment segment resource location pointers ( URL ) Information for media segments and timing information for the presentation of the media segments include receiving and storing media segments sent via at least one of multicast or unicast, and outputting a media segment requested for content reproduction among the stored media segments, receiving a control message at least one comprises URL basic pattern information for identifying at least one media segment that was sent via the multicast and at least one of URL basic pattern information for identifying at least one media segment that was sent via the unicast and updating the segment URL information in the stored media presentation description information based on the basic URL pattern information included in the received control message.

The control message may further include priority information regarding a representation comprising the at least one media segment that was broadcast over the multicast and priority information regarding a representation comprising the at least one media segment that was broadcast over the unicast.

The control message can still use Internet Protocol ( IP ) Include address information and port information relating to a transport session that the at least one media segment delivers via the multicast.

The control message may further include service identification information.

The control message may further include timing compensation information, and the method may further include setting a segment presentation time by updating timing information in the stored media presentation description information based on the timing compensation information.

According to an embodiment of the present disclosure, a media service device includes a broadcast server configured to provide media presentation description information, segment uniform resource location pointers ( URL ) - Media segment information and timing information for presenting the media segments include sending and sending media segments via at least one of a multicast or unicast, a multicast gateway configured to receive and store the media presentation description information, the media segments to receive and store, and output a media segment requested for content playback among the stored media segments, and a network controller configured to generate a control message that includes at least one of basic URL pattern information for identifying at least one media segment that is about the multicast was sent, and includes at least one of basic URL pattern information for identifying at least one media segment sent over the unicast and for sending the control message. The multicast gateway is configured to receive the control message and update the segment URL information in the stored media presentation description information based on the basic URL pattern information included in the received control message.

The control message may further include timing compensation information, and the multicast gateway may be configured to set a segment presentation time by updating timing information in the stored media presentation description information based on the timing compensation information.

The multicast gateway can be located in at least one of a home gateway or a connected set-top box.

If the multicast gateway operates as a proxy server, the proxy server can operate in an in-gateway transparent proxy mode.

Beneficial effects

According to an embodiment of the present disclosure, the broadcast efficiency of a broadcast system can be increased.

According to an embodiment of the present disclosure, a multicast service can be provided between heterogeneous networks.

According to an embodiment of the present disclosure, playback of a multicast service at a receiver can begin quickly.

According to an exemplary embodiment of the present disclosure, a unicast network and a multicast network can be used simultaneously, since a delivery route is identified in a segment by a base URL. This shortens the time required for switching between supply routes and increases the data bandwidth. In particular, it can be identified whether the uniform resource location pointer ( URL ) of data selected for playback URL a segment for multicast or a URL for the unicast from a specific server.

According to an embodiment of the present disclosure, the beginning and the presentation of a segment can be precisely synchronized with one another by means of compensation timing information in a manifest provided by a multicast server.

list of figures

• 1 eine Darstellung, die eine Netzwerkarchitektur gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 2 eine Darstellung, die ein Inhaltsnetzwerk gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 3 eine Darstellung, die einen Fall zeigt, in dem ein Inhaltsnetzwerk gemäß einem Ausführungsbeispiel der vorliegenden Offenbarung eine Weiterleitung per Satellit umfasst;
• 4 eine Darstellung, die einen Fall zeigt, in dem ein Inhaltsnetzwerk gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ein Inhaltszuliefernetzwerk (CDN) umfasst;
• 5 eine Darstellung, die ein drahtgebundenes Multicast-Netzwerk gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 6 eine Darstellung, die ein mobiles Multicast-Netzwerk gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 7 eine Darstellung, die eine Benutzernetzwerk gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 8 eine Darstellung, die eine Netzwerkarchitektur für einen ABR-Multicast gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 9 eine Darstellung, die ein Protokoll für einen adaptive Multicast-Strom gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 10 eine Darstellung, die ein Protokoll für ein adaptives Multicast-Streaming gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 11 eine Darstellung, die ein Protokoll für Signalisierungs- und Steuernachrichten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 12 eine Darstellung, die ein Protokoll für Signalisierungs- und Steuernachrichten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 13 eine Darstellung, die ein Protokoll zum Senden von Mediendaten über ein IP-Netzwerk gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 14 eine Darstellung, die eine Medienzuliefererprotokoll für ein IP-Multicasting gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 15 eine Darstellung, die ein Medienzuliefererprotokoll für ein IP-Multicasting gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 16 eine Darstellung, die ein Medienzuliefererprotokoll für ein IP-Multicasting gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 17 ein DASH-Sendungsschema gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
• 18 eine Darstellung, die eine Struktur eines DASH-Segments gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 19 eine Darstellung, die eine Struktur eines DASH-Segments, eine Erzeugungsreihenfolge und einer Parsingreihenfolge gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 20 eine Darstellung, die ein Benutzernetzwerk und eine MPD gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 21 eine Darstellung, die Einzelheiten einer MPD gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
• 22 eine MPD für ein schnelles Hochfahren gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
• 23 eine Darstellung, die eine Systemarchitektur für einen ABR-Multicast-Dienst gemäß einem Ausführungsbeispiel der vorliegenden Offenbarung zeigt;
• 24 eine Darstellung, die ein Ausführungsbeispiel zum Definieren einer Basis-URL gemäß einem Multicasting-ABR-Zulieferverfahren gemäß der vorliegenden Offenbarung zeigt;
• 25 eine Darstellung, die Ausführungsbeispiele einer Basis-URL, die in einer MPD umfasst ist, gemäß der vorliegenden Offenbarung zeigt;
• 26 eine Darstellung, die ein Ausführungsbeispiel der Semantik einer Steuernachricht gemäß der vorliegenden Offenbarung zeigt;
• 27 eine Darstellung, die ein weiteres Ausführungsbeispiel der Semantik einer Steuernachricht gemäß der vorliegenden Offenbarung zeigt;
• 28 eine vereinfachte Blockdarstellung, die einen entsprechenden Teil der in 23 gezeigten Systemarchitektur zeigt, wenn ein Multicast-Gateway als ein Proxyserver gemäß der vorliegenden Offenbarung operiert;
• 29 bis 33 Darstellungen, die Ausführungsbeispiele von Betriebsverfahren in Proxymodi gemäß der vorliegenden Offenbarung zeigen;
• 34 eine Darstellung, die eine beispielhafte Semantik eines Segmentzeitstrahlelements, das in einer MPD umfasst ist, gemäß der vorliegenden Offenbarung zeigt;
• 35 eine Darstellung, die beispielhafte Zeitinformationen, die in einer ,sidx‘-Box, die in einem Indexsegment umfasst ist, gemäß der vorliegenden Offenbarung zeigt;
• 36 eine Darstellung, die beispielhafte Zeitinformationselemente, die in einer MPD umfasst sind, gemäß der vorliegenden Offenbarung zeigt;
• 37(a) bis 37(e) Darstellungen, die einen beispielhaften Segmentpräsentationszeitstrahl gemäß der vorliegenden Offenbarung zeigen;
• 38 eine Darstellung, die beispielhafte Verfügbarkeitszeitversatzinformationen, die in einer MPD umfasst sind, gemäß der vorliegenden Offenbarung zeigt;
• 39(a) bis 39(f) Darstellungen, die einen beispielhaften Segmentpräsentationszeitstrahl, der basierend auf Zeitvorgabekompensationsinformationen eingestellt ist, gemäß der vorliegenden Offenbarung zeigen;
• 40 und 41 Darstellungen, die ein weiteres Ausführungsbeispiel der Semantik einer Steuernachricht gemäß der vorliegenden Offenbarung zeigen; und
• 42 eine Blockdarstellung, die einen Empfänger gemäß einem Ausführungsbeispiel der vorliegenden Offenbarung zeigt.

Show it:

• 1 a diagram showing a network architecture according to an embodiment of the present invention;
• 2 a diagram showing a content network according to an embodiment of the present invention;
• 3 a diagram showing a case in which a content network according to an embodiment of the present disclosure includes a satellite relay;
• 4 a diagram showing a case where a content network according to an embodiment of the present invention, a content delivery network ( CDN ) includes;
• 5 an illustration showing a wired multicast network according to an embodiment of the present invention;
• 6 an illustration showing a mobile multicast network according to an embodiment of the present invention;
• 7 a diagram showing a user network according to an embodiment of the present invention;
• 8th an illustration showing a network architecture for an ABR multicast according to an embodiment of the present invention;
• 9 an illustration showing a protocol for an adaptive multicast stream according to an embodiment of the present invention;
• 10 an illustration showing a protocol for adaptive multicast streaming according to an embodiment of the present invention;
• 11 an illustration showing a protocol for signaling and control messages according to an embodiment of the present invention;
• 12 an illustration showing a protocol for signaling and control messages according to an embodiment of the present invention;
• 13 an illustration showing a protocol for sending media data over an IP network according to an embodiment of the present invention;
• 14 an illustration showing a media provider protocol for IP multicasting according to an embodiment of the present invention;
• 15 an illustration showing a media provider protocol for IP multicasting according to an embodiment of the present invention;
• 16 an illustration showing a media provider protocol for IP multicasting according to an embodiment of the present invention;
• 17 a DASH broadcast scheme according to an embodiment of the present invention;
• 18 a diagram showing a structure of a DASH segment according to an embodiment of the present invention;
• 19 a diagram showing a structure of a DASH segment, a generation order and a parsing order according to an embodiment of the present invention;
• 20 a representation that a user network and a MPD according to an embodiment of the present invention;
• 21 an illustration, the details of a MPD according to an embodiment of the present invention;
• 22 a MPD for a rapid start-up according to an embodiment of the present invention;
• 23 a diagram showing a system architecture for an ABR multicast service according to an embodiment of the present disclosure;
• 24 15 is an illustration showing an embodiment for defining a base URL according to a multicasting ABR delivery method according to the present disclosure;
• 25 a representation, the embodiments of a base URL, which in a MPD includes, according to the present disclosure;
• 26 a diagram showing an embodiment of the semantics of a control message according to the present disclosure;
• 27 a diagram showing another embodiment of the semantics of a control message according to the present disclosure;
• 28 a simplified block diagram showing a corresponding part of the in 23 the system architecture shown shows when a multicast gateway operates as a proxy server in accordance with the present disclosure;
• 29 to 33 Representations showing embodiments of operating methods in proxy modes according to the present disclosure;
• 34 a diagram showing exemplary semantics of a segment timeline element included in an MPD according to the present disclosure;
• 35 2 is a diagram showing exemplary time information contained in a sidx box included in an index segment in accordance with the present disclosure;
• 36 2 is a diagram showing exemplary time information elements included in an MPD according to the present disclosure;
• 37 (a) to 37 (e) Illustrations showing an exemplary segment presentation timeline according to the present disclosure;
• 38 2 is a diagram showing exemplary availability time offset information included in an MPD according to the present disclosure;
• 39 (a) to 39 (f) Illustrations showing an exemplary segment presentation timeline set based on timing compensation information, in accordance with the present disclosure;
• 40 and 41 Representations showing another embodiment of the semantics of a control message according to the present disclosure; and
• 42 3 is a block diagram showing a receiver according to an embodiment of the present disclosure.

Best mode

1 FIG. 12 is a diagram showing a network architecture according to an embodiment of the present invention. As in 1 an adaptive media streaming network, a content network, an adaptive bit rate ( ABR ) Multicast network and include a user network. This is a functional classification of networks that support adaptive media streaming in an internet protocol ( IP ) -based multicast network can be used. Each network can also connect to an additional network to support functions other than adaptive media streaming. For example, the content network and the user network can each connect to a unicast network for unicast services.

The user network can send a request, a report and a feedback for content to be received to the ABR multicast network. The ABR multicast network can send a request, report, and feedback to the content network based on the information received from the user network. The content network can send multicast content and signaling information to the ABR multicast network based on the information received from the ABR multicast network. The ABR multicast network can send the received multicast content and signaling information to the user network to provide a multicast service.

2 FIG. 12 is an illustration showing a content network according to an embodiment of the present invention. The content network can serve to generate, collect and package content for adaptive multicast streaming, and can include various content sources. The content network can include a head end of a broadcaster that has a terrestrial and a wired Broadcast provides to provide broadcast content. The broadcaster's head end may include at least one of an encoder to encode content produced in content production, a packer to convert the encoded content, or a content server to store the content.

In addition, the content network may further include a satellite reception network to receive generated services from a geographically distant area. The content network may also include a content server to provide pre-stored content. The content network can have a content delivery network ( CDN ) to provide media delivery. Accordingly, the content network can generate and send a signaling message, a control message, and the like related to the content.

A separate signaling message or control message may be exchanged between multiple nodes belonging to the content network for proper interaction between the content, the signaling message, the control message and the like, and these messages may not be delivered to other external networks. The signaling message or the control message that is not sent to the external network can be referred to as an internal network signaling.

As described above, the content network may include a head end of a broadcaster. The content generated by the broadcaster can be encoded and packaged and then fed to a multicast transmitter for multicast or to be stored in the content server and fed to the multicast transmitter if necessary to become. The components included in the head end of the content network broadcaster are described below.

First, an encoder encoded in the head end of the broadcaster encodes the content. A packer included in the head end of the broadcaster can convert the encoded content and data into a format suitable for the multicast broadcast. For example, the format suitable for the multicast broadcast may be a media segment created by dividing a single piece of content. In addition, if required, the packer can generate signaling that can be received by the receiver or a device belonging to the network. The media segment generated by the packer can be fed directly to the multicast transmitter and run through the multicast. However, in the case where the media segment is data that does not have to be delivered immediately, it can be stored in the content server. The content server included in the head end of the broadcaster can store media data and associated signaling. The content server may also store third party content generated by a third party and use it for multicast if necessary. The content stored in the content server may not require a separate encoding process. Accordingly, the content server can store the media segments and the file formed by encoding or packaging the content and can send them when there is a broadcast request. According to one embodiment, a coding result of the media data can be stored in the content server, and a separate packaging process may be required depending on the type of the broadcast network. An operator controller included in the head end of the broadcaster can manage content production, the content server, and the like, and can manage and control a series of operations associated with multicasting. The operator control device can collect control and signaling data for a variety of devices and nodes in the content network, and can send the control and signaling data to the multicast network if necessary. This enables the operator control device to enable the multicast network to carry out signaling and control associated with the multicast. In addition, the operator controller can receive and process unicast information sent from a decoding device or player to use for multicast.

3 FIG. 12 is a diagram showing a case in which a content network according to an embodiment of the present invention includes satellite forwarding. The content network, which is equipped with satellite relaying, may include an encoder, a satellite transmitter, a satellite receiver, a packer, a content server and an operator control device. The head end of a broadcaster that provides terrestrial and wired broadcasting may include a satellite reception network for receiving services from geographically distant content producers. The satellite broadcast side can be the head end of another broadcaster. In this case, a satellite transmission / reception network to which head ends of a plurality of broadcasters are connected may be included in the content network. The content received via the satellite system can be one Encoding and packaging, and can then be fed to the multicast transmitter to go through the multicast or stored in the content server to be fed to the multicast transmitter if necessary. The coder of the content network, in which the transmission via satellite is included, can encode the content. Here, the encoder can be connected to a satellite transmission device for forwarding broadcast data to a satellite. The content network's satellite broadcasting system, which includes satellite broadcasting, can be used to provide a live broadcast for a geographically distant location. For example, overseas sports, concerts, news, and the like can be broadcast in real time through the satellite broadcasting system. A separate satellite broadcasting protocol and broadcasting scheme can be used for this purpose. Data supplied by the satellite transmission / reception system are fed to the packer. The packer of the content network, which includes satellite delivery, is constructed as shown in the previous drawings. The content server of the content network, which includes satellite forwarding, can store media data and associated signaling. When broadcast live to a geographically distant location, the data that went through the packer can be sent directly to the multicast transmitter, but the data and associated signaling in the head end of the broadcaster can be used for later use for the content get saved. A detailed description thereof has been presented with reference to the previous drawings. The description of the operator control device of the content network, which includes satellite relaying, has been presented with reference to the previous drawings.

4 FIG. 12 is a diagram showing a case where a content network according to an embodiment of the present invention has a content delivery network ( CDN ) includes. Over-the-top ( OTT ) to provide video content using the IP network can be considered as an embodiment of the content network. In the case of OTT , can the CDN connected for efficient use of network resources. The the CDN comprehensive content network can include an encoder, packer, content server, operator control device and the like CDN include. The content of the OTT can that CDN can be supplied by coding and packaging. In addition, the encoded and packaged content can be stored in the content server and then the CDN in response to a request for content. The one CDN Content can be fed to the multicast transmitter. According to one embodiment, the content of the OTT the multicast transmitter directly without using the CDN are fed and then the multicast is carried out. The encoder of the OTT can encode the content. The OTT can provide a live service or generate content to be stored in the content server. The packer of the OTT is constructed as described above with reference to the previous drawings. The content server of the OTT can store media data and associated signaling, which can be saved by the OTT are to be provided. The content server can also store generated third party content and use it for multicast if necessary. Here, the content stored in the content server may not require a separate encoding process. Accordingly, the content server can store the media segment and file formed by encoding or packaging the content and send them when there is a send request. According to one embodiment, a coding result of the media data can be stored in the content server, and a separate packaging process may be required depending on the type of the broadcast network. The network controller can collect control and signaling data for a variety of devices and nodes in the content network and send the control and signaling data to the multicast network as needed. This enables the operator control device to enable the multicast network to carry out signaling and control associated with the multicast. In addition, the operator controller can receive and process unicast information sent from a decoder or player to use for multicast. The OTT and the CDN can each comprise a separate operator control device. The operator control device used in the OTT is included, and the operator control device included in the CDN on is included can communicate with each other.

The ABR multicast network is a network that performs a multicast on content that has been delivered from the content network over the IP network. Here, the IP network can either correspond to a managed network in which the QoS is managed by a network provider and unauthorized traffic can be restricted, or an unmanaged network in which unauthorized traffic is not restricted. In addition, the IP network can be connected in a wired or wireless manner by devices included in the multicast network or the user network. When using the IP network for multicast, the IP network connected to the content network can be different from the IP network connected to the user network. That is, the content network and the user network can be connected to separate IP networks. In this case, the separate IP networks can use a connection protocol between Internet service providers ( ISP ) are enough that provide the respective networks. Even in this case, the multicast content between the sender and the receiver is transparent. That is, the output data of the transmitter are the same as the input data of the receiver, even if they pass through several ISP networks and nodes in the network.

The multicast network for sending and receiving multicast streams can comprise a multicast transmitter (server), a multicast receiver (client) and a multicast network control device. The multicast network can include a variety of networks depending on the location or connection status of the sender and receiver of the network for the multicast. A separate protocol can also be used for each network.

5 FIG. 12 is an illustration showing a wired multicast network according to an embodiment of the present invention. Multicast streams can be delivered over a wired IP network. A network provided by an ISP can be used between the multicast transmitter and the multicast receiver. In one embodiment, the multicast stream can be delivered over an IP network managed by a plurality of ISPs, and the management functional units of the multicast transmitter, receiver, controller and IP network can be different from each other. In this case, the transmission of the multicast stream can satisfy a connection protocol that corresponds to each ISP.

The multicast transmitter included in the multicast network can send content data to each multicast receiver. The multicast transmitter can receive packaged content from the content network and send the packaged content to a variety of multicast receivers using the multicast protocol. The multicast receiver included in the multicast network can receive the content data sent from the multicast transmitter and feed the content data to a decoding device capable of reproducing the content data. The multicast receiver can cache the content data to enable the decoding devices to reproduce the content data efficiently. In one embodiment, the multicast receiver can be configured in the same device as the decoding device. In one embodiment, a multicast stream may be received through a gateway of the user network. In this case, the multicast receiver can be a component of the user network.

The multicast network controller included in the multicast network can control the content broadcast of the multicast transmitter and associated session information. In addition, the multicast network controller can manage and send signaling information for the configuration of each of the multicast transmitter and the multicast receiver. The multicast network controller can be connected to each of the multicast transmitter and the multicast receiver using a protocol that is separate from that of the multicast content. According to one embodiment, the multicast network control device can possibly only be connected to the multicast transmitter, and the signaling information sent to the multicast receiver can comply with the same protocol as that of the multicast content.

A network cache included in the multicast network may include a node or device that acts as a cache between the multicast transmitter and the multicast receivers. In a multicast broadcast, the network cache can store an appropriate area of content for efficient use of network resources and deliver a multicast stream to the multicast receiver. According to one embodiment, the network cache can perform an update process for the multicast transmitter and the cached content.

6 FIG. 12 is an illustration showing a mobile multicast network according to an embodiment of the present invention. A multicast stream can be delivered over a wired IP network. For a mobile receiver, however, the multicast stream can be supplied via a mobile access network. For the IP multicast, a network supporting the IP transport can be used as the mobile access network. In addition, the mobile access network can support the multicast in order to supply a multicast stream to a large number of mobile receivers.

The multicast transmitter included in the multicast network can send content data to each multicast receiver. The multicast transmitter can receive packaged content from the content network and send the packaged content to a variety of multicast receivers using a multicast protocol. The multicast receiver included in the multicast network can receive the data sent by the multicast transmitter and supply the content data to a decoding device which is used for Is able to reproduce the content data. The multicast receiver connected to the mobile access network can receive a radio signal for the mobile access network. According to one embodiment, the multicast receiver connected to the mobile access network can be connected to the decoding device according to a separate wireless access protocol. The multicast receiver can cache the content data to enable the decoding device to reproduce the content data efficiently. In one embodiment, the multicast receiver can be configured in the same device as the decoding device.

The multicast network controller included in the multicast network can control the content broadcast of the multicast transmitter and associated session information. In addition, the multicast network controller can manage and send signaling information for the configuration of each of the multicast transmitter and the multicast receiver. The multicast network controller can be connected to each of the multicast transmitter and the multicast receiver using a protocol that is separate from that of the multicast content. In one embodiment, the multicast network controller may only be connected to the multicast transmitter, and the signaling information sent to the multicast receiver may follow the same protocol as that of the multicast content. In addition, the IP network and the mobile access network can each comprise a multicast network control device. In this case, the multicast network control device can send and receive control and signaling information relating to the corresponding network. Each of the multicast network controllers can use a separate protocol to perform communication between the multicast network controllers.

The network cache included in the multicast network may include a node or device that acts as a cache between the multicast transmitter and the multicast receivers. The network cache can be included in any of a variety of networks that make up the multicast network, and a variety of network caches can be included in each network. In addition, some nodes from each network can perform the cache function simultaneously. The network cache can store an appropriate range of content to efficiently use network resources in the multicast broadcast and can deliver a multicast stream to the multicast receivers. According to one embodiment, the network cache can perform an update process for the multicast transmitter and the cached content.

The user network can be referred to as a network to receive data from the multicast network and deliver it to a device to consume the content included in the data. The user network can be implemented in various forms according to the structure of the user network and the type of service provided by the multicasting. According to one embodiment, the multicast receiver described above can be included in the user network. When the multicast receiver is included in the user network, the multicast receiver can receive multicast content through a device that acts as a gateway or proxy that is included in the user network. In this case, the gateway or proxy can be viewed as a component of the ABR multicast network.

The multicast receiver can act as a server or a multicast transmitter in the user network. Accordingly, the decoding device included in the user network can consume the multicast content, and can enable multicast streaming even if the decoding device cannot directly receive the multicast content.

7 FIG. 12 is an illustration showing a user network according to an embodiment of the present invention. A home network can be considered as an embodiment of the user network. The multicast receiver can receive data sent directly by the multicasting, or a home gateway belonging to the home network can receive the data and supply the data to the multicast receiver.

If the home network includes a variety of devices, then the home gateway can receive data from the ABR multicast network. The home gateway can send and receive data to and from an external network while acting as a proxy. In the case where the home gateway acts as a proxy, the home gateway can cache data to be supplied to the multicast receiver.

The multicast receiver may be included in the ABR multicast network described above, or may be within the home network due to the structure of the network. According to the structure of the home network, the multicast receiver can act as a proxy. In the event that the multicast receiver cannot play the multicast stream directly, a decoding device capable of playing the multimedia stream may additionally be connected to the multicast receiver. In addition, the multicast receiver can transmit the multicast stream in conjunction with a variety of decoding devices.

The decoding device can be defined as a device for playing a multicast stream and providing the multicast stream to a user. A variety of decoding devices can be connected to the multicast receiver. The decoding devices can send and receive data in the manner of a unicast or a multicast. The decoding device can connect to a unicast network as well as the multicast network to receive a multicast stream. The decoding devices may send a request, report, or the like to the content network or the ABR multicast network. In some embodiments, in addition to the decoding devices, a decoding module and a display screen in the home network may be included as separate devices. The decoding device can also be configured together with the multicast receiver as a single device.

8th FIG. 12 is a diagram showing a network architecture for an ABR multicast according to an embodiment of the present invention. The figure shows an example of an overall network architecture for adaptive media streaming. The network architecture for adaptive media streaming can include a content network, an ABR multicast network and a user network. Details of each of these networks are the same as described above with reference to the previous drawings. The node or functional unit defined in the present invention may be a logical one. In one embodiment, each node can be constructed as a separate device, or can operate together with an adjacent node in the same device. As shown in the figure, a variety of devices can be interconnected and exchange signaling and management information for efficient multicast streaming.

Network interfaces and protocols for adaptive media streaming are described below. The protocols can be classified into a media protocol through which the media data is actually sent and a signaling protocol to control each node or functional unit to send the media data or to send configuration information regarding the media data to various nodes and functional units including a receiver. Signaling and control information can be sent through the signaling protocol. However, in a case where the receiver receives the media content through a single connection, a separate signaling path may not be configured. In this case, the signaling and control information can be supplied through the media protocol.

9 FIG. 12 is an illustration showing a protocol for adaptive multicast streaming according to an embodiment of the present invention. As shown in the figure, a multicast receiver can include the same devices and modules as a decoder. Media content created in the content network or stored in a server can be supplied to a user's decoding device. The media content can be multicasted to be delivered to a variety of users.

In the adaptive multicast streaming environment, the creation and multicast transmission / reception of the content can be carried out separately. Therefore, a protocol for delivering created content to a node and a functional unit configured to perform the multicast transmission and a protocol for transmitting and receiving the content in the adaptive streaming format can be defined in the manner of the multicast become. In the figure, the node and the functional unit are shown as multicast transmitters. Content data passes through a variety of nodes or functional units, and an appropriate protocol is required between the nodes or functional units. In this case, for a protocol on a node or a functional unit, a protocol for efficiently feeding data to the next node in real time can be used. This protocol can be referred to as a tunneling protocol. Accordingly, as shown in the figure, a tunneling protocol can be defined between the server and a multicast transmitter. In this case, the media content is delivered as a payload of the tunneling protocol, but it should be noted that the tunneling protocol can operate regardless of the format of the media content.

A protocol to support adaptive streaming for multicast receivers can be defined in the multicast transmitter, and the IP multicast scheme can be used to deliver adaptive streaming to a variety of multicast receivers. Depending on the protocol of adaptive streaming, the IP multicast scheme can be used as a combination of TCP / IP and UDP / IP To be defined.

If the multicast receiver can act as a decoder and player, then the multicast receiver can acquire adaptive streaming data by receiving an IP multicast packet, decode data according to the media content format from the data and play the encoded data.

10 FIG. 12 is an illustration showing a protocol for adaptive multicast streaming according to an embodiment of the present invention. As shown in the figure, a multicast receiver can be constructed as a device or module separately from the decoder (media player). The media content created in the content network or stored in a server can be supplied to a user's decoding device. The media content can be multicasted to be delivered to a variety of users.

In the adaptive multicast streaming environment, the creation and multicast transmission / reception of content can be carried out separately. Therefore, a protocol for delivering created content to a node and a functional unit that is configured to perform a multicast transmission and a protocol for sending and receiving the content in the adaptive streaming format can be defined in the manner of the multicast become. In the figure, the node and the functional unit are shown as multicast transmitters. Content data passes through a variety of nodes or functional units, and an appropriate protocol is required between the nodes or functional units. In this case, for a protocol on a node or a functional unit, a protocol for efficiently feeding data to the next node in real time can be used. This protocol can be referred to as a tunneling protocol. Accordingly, as shown in the figure, a tunneling protocol can be defined between the server and a multicast transmitter. In this case, the media content is delivered as a payload of the tunneling protocol, but it should be noted that the tunneling protocol can operate regardless of the format of the media content.

A protocol to support adaptive streaming for multicast receivers can be defined in the multicast transmitter, and the IP multicast scheme can be used to deliver adaptive streaming to a variety of multicast receivers. Depending on the protocol of adaptive streaming, the IP multicast scheme can be defined as a combination of TCP / IP and UDP / IP.

If the multicast receiver and decoder (player) are constructed as separate devices or modules, then the multicast receiver can acquire adaptive streaming data by receiving an IP multicast packet and delivering them to the decoder. Here, an IP unicast protocol can be used between the multicast receiver and the decoder. The content data received by the multicast receiver can be supplied to the decoder through the IP unicast protocol, and the decoder can decode and play the data according to the received media content format.

A protocol for signaling and control messages will be described below. The broadcast of signaling and control messages may be defined by a protocol that is distinguishable from the media content broadcast protocol to provide broadcast control, planning, configuration information, and the like when each node and functional unit performs adaptive streaming. Depending on a case in which each node and each functional unit is connected, the protocol can be defined as a separate protocol. In the network architecture described above, a signaling and control message may be included and sent in the media content broadcast protocol. However, such a signaling and control message is sufficient for a protocol for the media content feed.

11 FIG. 12 is an illustration showing a protocol for signaling and control messages according to an embodiment of the present invention. In the network architecture described above, a control protocol can be defined between an operator control device included in the content network and a network control device included in the multicast network. The network controller may send a response or message message for a control message to the operator controller to cause the operator controller to generate control and management messages. The tunneling protocol for sending a control message can thus be set up bidirectionally his. A single operator controller can send and receive control messages to and from a variety of multicast network controllers. In addition, each of the multicast network controllers can be managed by a separate management functional unit.

The network control device can supply configuration-related information relating to the network to the multicast transmitter and the multicast receiver. The network controller may provide configuration information related to network resources, information related to mapping between the nodes of the network, routing information, and the like. It can also supply configuration information received from the operator control device to the multicast transmitter or the multicast receiver. In this process, the protocol for transmission from the multicast network control device to the multicast transmitter can be distinguished from the protocol for transmission to the multicast receiver. The upper part of the figure shows the protocol for transmission from the network control device to the multicast transmitter, and the lower part of the figure shows the protocol for transmission from the network control device to the multicast receiver.

In addition, an IP multicast can be used to route a configuration message from a single network controller to a plurality of multicast transmitters and multicast receivers. Connection information, statistical information and the like collected by the multicast transmitters and the multicast receivers can be reported to the multicast network controller. Since this process can be carried out independently of each of the multicast transmitters and multicast receivers, a unicast protocol can be used. This set of control information, configuration information, and the like can be updated dynamically and sent immediately or by scheduling.

The multicast receiver can use a signaling protocol to send the received adaptive streaming data to a decoding device. An IP unicast protocol can be defined to provide separate information to individual decoding devices. In addition, the decoding device can send a signaling of a request from the decoding device to the multicast receiver using the IP unicast protocol. Thus, the protocol can be defined as a bidirectional protocol between the multicast receiver and the decoding devices.

12 FIG. 12 is an illustration showing a protocol for signaling and control messages according to an embodiment of the present invention. As shown in the figure, the multicast network controller can be connected to the multicast receiver via a multicast transmitter instead of a direct connection to the multicast receiver.

The network control device can supply configuration-related information relating to the network to the multicast transmitter and the multicast receiver. The network controller may provide configuration information related to network resources, information related to mapping between the nodes of the network, routing information, and the like. It can also supply configuration information received from the operator control device to the multicast transmitter or the multicast receiver. However, since the multicast control device is only connected to the multicast transmitter and not to the multicast receiver, the multicast transmitter can forward the configuration message supplied by the network control device to the multicast receiver. For a protocol or set of messages related to the configuration in the multicast network controller, the protocol for sending to the multicast transmitter may be distinguishable from the protocol for sending to the multicast receiver.

In addition, the IP multicast can be used to send a configuration message from a single network control device to a multitude of multicast transmitters and multicast receivers. Connection information, statistical information and the like collected by the multicast transmitter and the multicast receiver can be reported to the multicast network controller. Since this process can be carried out independently by each of the multicast transmitters and multicast receivers, a unicast protocol can be used. This set of control information, configuration information, and the like can be updated dynamically and sent immediately or by scheduling.

Information such as a report to be sent from the multicast receiver to the multicast network controller can be supplied to the multicast network controller via the multicast transmitter. That is, the multicast transmitter can forward a report message or the like to be supplied from the multicast receiver to the multicast network controller. Operations of the other protocols may be the same as those in the drawings described above.

13 FIG. 12 is an illustration showing a protocol for sending media data over an IP network according to an embodiment of the present invention. A protocol and a packet format can be determined according to each layer. Each protocol can be set up independently, or specific protocols can be combined for mutual cooperation. The operation of the encoder to compress and convert the collected video and audio data into a suitable codec and the feeding of a packer can be carried out as an internal data processing system of a broadcasting system. An efficient codec can be used for multicasting the video and audio data. A codec, like high-efficiency video coding ( HEVC ) or advanced video coding ( AVC ) can be used for the video data and it can be an audio codec, such as advanced audio coding ( AAC ), audio compression 4 ( AC4 ) or moving picture expert group-H (MPEG-H), for which audio data is used.

Each codec can be packaged in a form that is suitable for shipment or storage. For this purpose, a format can be used, such as an ISO basic media file format ( ISOBMFF ), a common media application format ( CMAF ) or an MPEG-2 TS (Transport stream). In the process of packaging content data encoded with a codec, digital rights management ( DRM ) can be added to only allow a specific recipient to play the content, and can be used in the DRM Authentication key value used are sent on a separate connection or a separate channel.

For the media data configured in a file format, a protocol that can send files directly, such as file feed via unidirectional transport ( FLUTE ), can be used according to a shipment schedule. A protocol that supports adaptive streaming, such as dynamic adaptive streaming via, can also be used HTTP ( DASH ). A lower layer protocol can be configured according to FLUTE or DASH be used. For example, if DASH is used, HTTP or may be used as a lower layer protocol FLUTE can be used as a lower layer protocol with a DASH segment considered as a file.

For the IP multicast, the shipment control protocol / Internet protocol ( TCP / IP ) or user datagram protocol / internet protocol ( UDP / IP ) are used according to the structure of the higher layer protocol. The internet group management protocol ( IGMP ) that can manage participation of an IP multicast group and the like can also be used in the multicast receiver. The layer 2 protocol and the layer 1 protocol can be defined according to their transport connections. Ie, optimized protocols can be configured according to connections between the nodes and functional units that are configured on a network. For example, in a local area network environment ( LAN ) can use ethernet as a protocol for the layer 2 , and can be multi-access and collision detection ( CSMA / CD ) as a protocol for the layer 1 To be defined.

14 FIG. 12 is an illustration showing a media delivery protocol for IP multicasting according to an embodiment of the present invention. The media delivery protocol is a specific embodiment of a protocol according to a way through which media content is sent. In the case shown, the multicast receiver is constructed with the same device under the same module as the decoder (media player).

Protocols that are applied to the content server are a media codec and a file format. The media codec can include a video codec, an audio codec, or other encoding formats. The video codec can include a codec, such as HEVC or AVC , and the audio codec may include a codec such as AAC . AC4 and MPEG H , The protocol for the file formats can be defined as a format for sending or storing a codec format in the form of a file. File formats such as. Can be used for this purpose ISOBMFF and CMAF , and it can be the format of MPEG-2 TS be used when the existing broadcast network is connected. A variety of file formats can be used in light of the broadcast efficiency.

For a protocol between the server and the multicast transmitter, mainly a protocol for an efficient feeding of file formats can be defined. Therefore, data of the content created in the server can be supplied using a tunneling protocol. As the tunneling protocol, mainly a real-time broadcast protocol like that RTP , and other IP-based tunneling protocols available on the appropriate network can also be used. In this case, an existing protocol can be used or the definition of a field can be changed to be suitable for the network. In the multicast transmitter a tunneling protocol may be defined at the input terminal to receive a file transmitted from the server using the tunneling protocol. In this case, since the format for the file sent using the tunneling protocol is data to be supplied from the multicast transmitter to the multicast receiver, the tunneling protocol can operate regardless of the format of the data.

A protocol for adaptive streaming can mainly be defined as the protocol between the multicast transmitter and the multicast receiver. This protocol can include a DASH-based protocol. For this purpose, the lower layer protocol is based on the IP multicast. For DASH to operate, a protocol such as HTTP , can be used together with the DASH. In the case where a DASH segment in the form of a file is used, a file transfer protocol such as FLUTE , can be configured. It can also TCP / IP for an effective connection and multicast transmission from DASH / HTTP be used on the network.

The multicast receiver can TCP / IP use to receive a packet stream that was sent as a multicast. The multicast receiver can also HTTP use for a request for a packet stream, a response to the received data, and the like. If the multicast transmitter DASH used for adaptive streaming, the multicast receiver can include a DASH client. Data that is adaptively separated using DASH is configured in a file format that is sent from the server. Accordingly, the multicast receiver can use a file format-related protocol that is able to identify the file format and a media codec that is able to decode the identified media format.

15 FIG. 12 is an illustration showing a media delivery protocol for IP multicasting according to an embodiment of the present invention. The media delivery protocol is a specific embodiment of a protocol according to a way through which media content is sent. This embodiment represents a case in which the multicast receiver is configured as a device or module separate from the decoder (media player). Therefore, the multicast receiver needs an operation to send a received multicast stream to the decoding device (the decoder).

The multicast receiver can TCP / IP use to receive a packet stream that was sent as a multicast. The multicast receiver can also HTTP use for a request for a packet stream, a response to the received data, and the like. If the multicast transmitter DASH used for adaptive streaming, then the multicast receiver can comprise a DASH client. The multicast receiver can act as a proxy for data that has been adaptively streamed using DASH. The multicast receiver can supply the data to the decoding device. Since the number of decoding devices connected to the multicast receiver can be limited, the corresponding connection can be based on a unicast broadcast. Accordingly, the multicast receiver HTTP under TCP / IP as protocols for the unicast connection.

The decoding device can use a unicast protocol to receive data sent by the multicast receiver. Data supplied by the HTTP unicast can have a file format sent by the server. Accordingly, the decoding device can use a file format related protocol capable of identifying the file format and a media codec capable of decoding the identified media format. Operations of the other protocols may be the same as those in the embodiment described with reference to the previous drawings.

16 FIG. 12 is an illustration showing a media delivery protocol for IP multicasting according to an embodiment of the present invention. The protocol for fast UDP Internet connections (QUIC) can be used to send the DASH segment. The multicast scheme using TCP / IP may cause delays in setting up connections and may not be suitable for sending streaming data immediately. It is in the QUIC-based protocol QUIC responsible for a process of connection and flow control. It can also QUIC HTTP / 2 use, which eliminates the problem of transmission delay that the existing protocol HTTP entails, is solved. In addition, streaming data can be used directly using UDP / IP be sent. Operations of the other protocols are the same as those in the embodiment described above.

17 13 shows a DASH broadcast scheme according to an embodiment of the present invention. The DASH system can be implemented by sending and receiving data between the HTTP server and the DASH client. The DASH client can include a DASH access engine and a media engine. In DASH, the HTTP server can divide content of different qualities into segments in a certain time unit and store the divided content in the server. The HTTP server can send the divided data unit upon request for media from the DASH client, which is a user device, using the HTTP protocol. In view of the flexible HTTP network status, media contents of various qualities that are stored on the HTTP server can be sent optionally. This can allow the user to receive a seamless adaptive streaming service. A separate file that includes information regarding a timeline order and a quality order of the divided files described above is a media presentation description ( MPD ). The MPD can provide the DASH client with information regarding the media data stored on the HTTP server. The MPD is an XML document and can include attributes such as the URL, start time, content type and the like assigned to each segmented segment. The DASH client can request and receive an MPD file from the server before receiving the media file. Upon receipt of the MPD file, the DASH client can request a segment file of the content stored on the HTTP server using the information regarding the media file contained in the MPD is included.

18 FIG. 12 is a diagram showing a structure of a DASH segment according to an embodiment of the present invention. The DASH segment is a data unit of a transfer object that can be reproduced for a predetermined duration by dividing the content to be sent into media segments. The DASH media segment includes a 'styp' box indicating the segment type and a 'sidx' box containing segment index information. In addition, the DASH media segment can include an, mdat box, which comprises a media stream truncated in fragment units, and an, moof box, which includes metadata in this regard. The DASH client can request a broadcast of an MPD file, which is a manifest file, to request a service, and can request a media segment through each uniform resource location pointer ( URL ) Requests. The DASH client can pars an initialization segment ( ISS) -Receive file that includes initialization information, perform decoder initialization, and then receive the requested media segment file and perform media parsing and decoding to decode the media segment.

Files received by the DASH client can be classified according to components for media playback. The DASH client can view the media after receiving the MPD which is a manifest file, play the initialization segment file and the media segment file. Therefore, the media encoder of the sending terminal can encode the mdat including media data for the entire playback block (MPD + IDS + sidx + moof + mdat) and generate a metadata header (styp + sidx + moof) including the encoding information. Thereafter, the sending terminal can generate an IS.mp4 file that represents decoder initialization information that MPD including the URL information related to the segment and sending it to the DASH client. The parsing order of the receiving terminal is as follows. The receiving terminal can receive and parse the MPD file, initialize the decoding and request a media segment according to network conditions.

In the case where the DASH segments stored in various qualities provide a live type service or a data broadcasting service by encoding live broadcast content, the real time operation of the entire media service framework is applied. Therefore, the delay should be minimized to realize a seamless service. If a delay occurs in the encoding and packaging of real-time content and the real-time content is parsed and decoded during a live broadcast using the DASH protocol, a delay may occur at the start of the service. In other words, if each media file is created, packaged, and sent, there may be a delay time that corresponds to a packet reception time and the time it takes for the entire packet to be generated for parsing the packet. As a result, the buffer time on the client side becomes longer. To solve this problem, the following procedure is proposed.

19 14 is a diagram showing a structure of a DASH segment, a generation order, and a parsing order according to an embodiment of the present invention. The MPD , the IS . sidx . moof and I-frames described in the previous drawings can be configured as a single assembly block and sent in advance in order to reduce a transmission / reception delay of media data and to allow the receiving terminal to play media quickly. This block can be referred to as a fast boot build block. Under Using the broadcast MPD, the DASH client can perform playback by MPD broadcast and the segment request according to the conventional model in the manner of a unicast. While the DASH framework is operating, the DASH client can perform a quick boot using the I-frame that is included in and with the single build block MPD is received. In other words, the server of the sending terminal can optionally send the I-frame instead of sending the entire mdat frame that is covered by the moof header, thereby reducing the reception delay. In addition, the DASH client can provide fast audio and video ( AV ) -Power up by starting playback from the I-frame that is a random access point ( RAP ) is. In addition, in the case of the live broadcast, instead of generating all segments of the overall qualities, the sending terminal server can selectively generate a representation / segment that enables a quick start-up, considering the network situation or according to the consideration of the network operator, and one Generate and send a light MPD enabled for this. The DASH client can be easy MPD received and configure the fast boot build block to start playing quickly. Thereafter, the DASH client can receive a segment of a different quality through the proxy to perform a bit stream switching according to the qualities of the segments. In summary, the sending terminal server can only carry out a transmission considering segments for a fast start-up, and can provide segment information for the fast start-up in the MPD to minimize the delay in playing media data.

20 shows an illustration showing a user network and a MPD according to an embodiment of the present invention. As shown in the upper part of the figure, if the client requests the DASH content stored in the proxy to receive the service, then the existing one MPD no content indicating a fast boot segment mode (quick mode) described in the previous figure. Therefore, if the client accesses the component, then signaling is required which indicates a segment for fast access, ie a fast start-up segment. The lower part of the figure shows the hierarchical structure of the MPD , The MPD is configured in a hierarchical structure that includes elements and attributes. Each layer describes elements and attributes that include information related to media content, structural functions, and roles. The description of the video and audio component levels begins with an adjustment set that includes one or more display entries. The representation includes information regarding URL paths of the segments, and the client can perform a bit stream switching between the representations according to network conditions.

21 shows a representation, the details of a MPD according to an embodiment of the present invention. The representation described above in the MPD can include a descriptor that can specify a common attribute. The representation may include a common attribute descriptor, as shown in the upper part of the figure. The common attributes can include an auxiliary property descriptor that can be used to define an element that is necessary for the framework of the corresponding representation. Elements of such a type of descriptor can define an attribute indicating which operation should be performed by the schemeIdUri attribute as shown in the middle of the figure and can define a specific code point for a specific operation by value attributes. The fast start-up information described above can be found in the MPD can be defined using an extension of a new auxiliary property descriptor, thereby signaling a display that is capable of a quick start-up under the display entries. That is, as shown in the lower part of the figure, the schemeIdUri attribute can be defined as a fast boot, and the existing segment mode and the fast boot mode can be defined for the value attributes. The fast mode can signal to the DASH client that a fast start-up is possible using the fast start-up building block described in the previous figure.

22 shows one MPD for fast start-up according to an embodiment of the present invention. As shown in the figure, the MPD can be expressed in XML, and can define the schemeIdUri attribute of the auxiliary property element as a quick boot and set the value attribute to quick mode for a display that supports a quick boot. This enables the MPD to signal to the DASH client that the display supports the rapid startup described above.

23 14 is a diagram showing a system architecture for an ABR multicast service according to an embodiment of the present disclosure.

In 23 the system architecture can be a recording unit 1010 for reporting content providers, a content provider controller 1020 , a content preparation unit 1030 , a content hosting unit 1040 , a multicast server 1050 , a staging unit 1060 , a multicast gateway 1070 and a content player 1080 include. The system architecture can also be a service discovery unit 1091 , a license management unit 1093 for digital rights management ( DRM ) and a unicast repair unit 1095 include.

The content preparation unit 1030 can be a content coding unit 1031 , a content encryption unit 1033 and a content packaging unit 1035 include. The multicast server 1050 can be a content exploitation unit 1051 and a multicast transmission unit 1053 include. The staging unit 1060 can be a service registration unit 1061 and a network controller 1063 include. The multicast gateway 1070 can be a service reporting unit 1071 , a service management unit 1072 , a multicast receiving unit 1073 , a store of value 1074 and a unicast repair client 1075 include. The content rendering device 1080 can a display measure reporting unit 1081 , a content unpacking unit 1083 , a content decoding unit 1085 and a content decryption unit 1087 include.

The following reference points, which in 23 are primarily used to send content.

L is a unicast HTTP interaction interface between the multicast gateway 1070 and the content player 1080 , This interface L includes fetching all specified types of content. If the multicast gateway 1070 and the content player 1080 are arranged together in a single end device, such as in a set-top box ( STB ), then the interface L can be used as a logical application programming interface ( API ) will be realized.

B is a bootstrap unicast HTTP (S) interaction interface between the content hosting device 1040 and the content player 1080 , This interface B is used to fetch manifestos and fetch content in an unregulated case.

A is an HTTP (S) acquisition interface for content that is not provided through an M interface. This is for the multicast gateway 1070 used to deliver content directly from the content hosting unit 1040 to fetch over the unicast if an interface U unable to perform content repair.

M is an interface for the multicast server 1050 is used to multicast IP content to the multicast gateway 1080 to send. The interface M can also be used for the multicast server 1050 used to multicast IP content to the unicast repair unit 1095 to send.

U is a unicast interaction interface between the unicast repair unit 1095 and the unicast repair client 1075 of the multicast gateway 1070 ,

U ' is a unicast interaction interface between the unicast repair unit 1095 and the multicast server 1050 ,

Pin is a content publication for the content hosting unit 1040 through the content packaging unit 1035 the content preparation unit 1030 , This can be implemented as a push interface or the content can be pulled as needed.

O _in is a utilization of content between the content hosting unit 1040 and the multicast server 1050 is sent and received. This is typically implemented as a pull interface.

P _in ' is a utilization of content from the multicast server 1050 through the content packaging unit 1035 the content preparation unit 1030 provided. This is typically implemented as a push interface.

• C_MS: Steuerschnittstelle für die Konfiguration des Multicast-Servers 1050.
• C_MR: Steuerschnittstelle für die Konfiguration des Multicast-Gateway 1070.
• C_CP: Steuerschnittstelle für die Konfiguration der Bereitstellungseinheit 1060.
• R_S: Dienstmeldung durch die Dienstmeldeeinheit 1071 zu der Dienstmeldeaufnahmeeinheit 1061.
• R_CP: Dienstmeldung durch die Dienstmeldeaufnahmeeinheit 1061 an die Aufnahmeeinheit 1010 zur Meldung von Inhaltsbereitstellermaßen.
• R_PM: Melden von Abspielmaßen durch die Inhaltswiedergabeeinheit 1080 an die Aufnahmeeinheit 1010 zum Melden von Inhaltsbereitstellermaßen.

The following reference points, which are in 23 are used for control signaling and operational reporting.

• C _MS : Control interface for the configuration of the multicast server 1050 ,
• C _MR : Control interface for the configuration of the multicast gateway 1070 ,
• C _CP : Control interface for the configuration of the delivery unit 1060 ,
• R _S : Service report by the service reporting unit 1071 to the service entry unit 1061 ,
• R _CP : service report by the service registration unit 1061 to the acquisition unit 1010 to report content delivery.
• R _PM : reporting of playback dimensions by the content playback unit 1080 to the acquisition unit 1010 to report content.

In 23 can simplify the description of the multicast server 1050 can also be referred to as a multicast transmitter, and the multicast gateway 1070 can also be referred to as a multicast proxy. The content rendering device 1080 can also be referred to as a client or the DASH client. An embodiment of the present disclosure will be described below in connection with a manifest that includes a MPD is.

The content encoding unit 1031 the content preparation unit 1030 receives content from the content provider controller 1020 and encodes the received content. That is, the content coding unit 1031 converts source media streams to encoded media to reduce bit rate. A single stream of source media can be converted to many other encoded representations. The content encryption unit 1033 encrypts the through the content encoder 1031 encoded content under the control of the DRM license management unit 1093 , The encryption of the content encryption unit 1033 is optional. If the content encryption unit 1033 performs encryption, then the content decryption unit performs 1087 the content player 1080 also decryption of the encrypted content under the control of the DRM license management unit 1093 by. In one embodiment, the DRM license management unit 1093 Encryption key for the content encryption unit 1033 and the content decryption unit 1087 ready. Content, which is the content encryption unit 1033 bypasses, or encrypted content that comes from the content encryption unit 1033 is packaged in a format suitable for the multicast broadcast and to the multicast server 1050 and / or the content hosting unit 1040 through the content packaging unit 1035 Posted. The format suitable for the multicast broadcast can be, for example, media segments that were created by dividing one of the contents. Furthermore, the content packaging unit 1035 generate a manifest and the generated manifest to the multicast server 1050 send. The manifest can be generated and the multicast server 1050 through the content hosting unit 1040 to be provided.

In another example, the manifest and the content preparation unit can be generated 1030 by the content provider controller 1020 to be provided. In another example, the multicast server 1050 generate the manifesto.

The content that is in the content preparation unit 1030 being prepared, the content hosting unit 1040 made available for unicast delivery. The content hosting unit 1040 can be implemented as a simple web server, as part of a source cluster, or can operate as a distributed content delivery network (CNS) system. As such, load balancing and request distribution techniques (such as DNS competition and HTTP-302 redirection) can be used to redirect clients to the most appropriate content server.

The multicast server 1050 encapsulates the media content (for example, media segments) from the content preparation unit 1030 is output in a packet format suitable for the multicast broadcast, and then sends this encapsulated media content to the multicast gateway 1070 using a specific transport protocol stack. One from real-time object delivery via unidirectional transport ( ROUTE ) HTTP QUIC . FLUTE and NACK-oriented, reliable multicast ( STANDARD ) a cable IPTV can be used as the specific transport protocol stack. Ie, in the multicast server 1050 , the payloads of the used media stream are encapsulated in supplier units of the multicast transport protocol and through the network to participating clients of the multicast gateway 1070 sent using the IP multicast over the interface M , Procedures for utilizing both push and pull content are for the multicast server 1050 possible.

The unicast repair unit 1095 listens to a multicast content broadcast via reference point M and caches a copy of a packet stream locally that it uses to fulfill a repair request made by the unicast repair client 1075 Will be received.

The multicast gateway 1070 provides packaged content segments for the content player 1080 ready.

The multicast gateway 1070 can multicast media segments from the multicast server 1050 receive. Furthermore, the multicast gateway 1070 Media segments via unicast by at least one of the content hosting unit 1040 , the multicast server 1050 or the unicast repair unit 1095 receive. If in particular the unicast repair unit 1095 is unable to repair the content, the multicast gateway can 1070 the content directly from the content hosting unit 1040 received via the unicast via interface A.

In one embodiment of the present disclosure, the multicast gateway 1070 the content player 1080 closest created, and stores and distributes media segments (i.e., content segments) that are in a specific transport protocol stack from the multicast server 1050 were received. That is, the multicast gateway 1070 which is the content playback unit 1080 closest is stores the media segments that are packaged according to a broadcast format and in the specific protocol stack by the multicast server 1050 were provided, and then places a corresponding media segment among the stored media segments of the content playback unit 1080 according to a request (for example, to execute a specific application or switch channels) from the content player 1080 ready. That through the content playback unit 1080 In other words, the requested media segment is sent directly to the content reproduction unit 1080 through the multicast gateway 1070 provided, not by the multicast server 1050 ,

In one embodiment, the multicast gateway is located 1070 with the function described above in a customer-based facility such as a home gateway or an IP-connected STB , The multicast gateway 1070 can operate as a proxy server.

When content requests from the content player 1080 over the interface L can then be received either directly from content stored in the store 1073 is cached, or indirectly from fetched content via the interface A to be served. The fetched content can be stored in the store 1073 be cached.

The service management unit 1072 of the multicast gateway 1070 collates service configuration information relating to multicast content streams that are available via the interface M and the location of the service registration unit 1061 , The information can be obtained directly from the network controller 1063 via the reference point CRM or indirectly from the multicast receiving unit 1073 of the multicast gateway 1070 be received.

The multicast receiving unit 1073 exploits content streams via the interface M. The received content can also be stored in the value memory 1074 cached for later use.

The unicast repair client 1075 recovers a lost multicast packet.

The store of value 1074 provides for temporary storage of values by the interface L to be provided.

The service reporting unit 1071 reports service-related measures (for example a telemetry and analysis data) to the service registration unit 1061 over the interface R _S ,

Network controller 1063 controls, configures and provides network resources. These network resources include resources for multicast broadcast and resources for unicast broadcast. The network control device 1063 distributes configuration information regarding a set of available multicast streams to the network resources, and can additionally transmit this configuration information to the multicast server 1050 over the reference point C _MS and / or via the multicast gateway 1070 Distribute via the reference point CRM. The configuration information regarding the set of available multicast streams can be made according to the content provider controller 1020 and / or the number of client requests are updated.

The content rendering device 1080 is a functional unit that manages the request, reception, decryption and presentation of the content.

The content rendering device 1080 can be separate from the multicast gateway 1070 be on an end device, such as a smartphone. The content rendering device 1080 can alternatively with the multicast gateway 1070 can be combined in an STB or a connected TV set.

The content unpacking unit 1083 takes elementary stream data from a fetched transport object and presents the elementary stream data to the content decoding unit 1085 or the content decryption unit 1087 , For ISO basic media file format segments, media data box (s) are / are extracted, while for MPEG-2 transport streams the payloads of newly merged PES packages are / are extracted.

The content decoding unit 1085 parses and interprets the contents of the elementary media streams, which enables the contents to be rendered for playback on a screen or a loudspeaker.

The content decoding unit 1085 can in particular comprise a multiplicity of decoding devices which simultaneously access the multicast gateway 1070 can access. Each decoding device can transfer data to and from the multicast gateway 1070 Send and receive via a unicast or multicast. That is, the decoding devices can access a unicast network that receives unicast streams as well as a multicast network that receives multicast streams. An application 1097 controls the content player 1080 , The application can be an embedded control application on a built-in TV or one STB (for example, an EPG application) or a third party application provided by a content provider.

The application 1097 interacts with the service management unit 1072 of the multicast gateway 1070 to find the presence or absence of linear services and their reception by the multicast gateway 1070 to control.

An embodiment of an ABR service reception process will be described below. First, the content player receives 1080 a manifesto about a bootstrap that is interface B. The content rendering device 1080 then sends the URL a specific media segment to the multicast gateway 1070 based on information in the manifest that provides information (e.g., an IP address and a host name) regarding the multicast gateway 1070 includes what the media segment corresponds to the URL requests. The multicast gateway 1070 searches for that through the content player 1080 requested media segment among media segments by the multicast server 1050 received and stored, and represents the captured media segment of the content player 1080 ready.

As such, the content playback unit selects upon receipt of a manifest 1080 a representation of a suitable quality according to a DASH model, sends the URL of a corresponding media segment to the multicast gateway 1070 and receives the media segment according to the URL from the multicast gateway 1070 ,

That is, the content rendering unit 1080 receives the representation including the media segment from the multicast gateway 1070 according to a segment template in the manifest. However, if a specific service (e.g., a linear service) is broadcast over the multicast, a corresponding representation may not be easily received because the multicast is a one-to-many broadcast of the service. In this case, a different representation must be selected.

For this purpose, a service is sent simultaneously on different service paths, ie via a unicast and a multicast in one embodiment of the present disclosure. For example, if the representation broadcast over the multicast is not easily received, then the content player can 1080 select a representation that is sent via the unicast and operate the representation. To simplify the description, the multicast is referred to as a first delivery route (or a first delivery process) and the unicast is referred to as a second delivery route (or a second delivery process or vice versa) in the present disclosure. In addition, the broadcast is referred to as a third delivery route (or a third delivery process).

However, there is only one in the current manifesto URL defined to access a media segment. Therefore, the content reproduction unit 1080 may not identify whether the URL one Media segment that is included in the selected representation, the URL a segment in the multicast gateway 1070 is encapsulated in a protocol that supports ABR or is an HTTP URL for unicast from a specific server.

For example, if a path to a segment URL of a multicast service expires or is unavailable, then the content player needs 1080 a process of requesting a new media segment URL of a unicast service in a detour manner and receives the media segment URL. This process can cause a service outage problem in the live service and increase latency. Furthermore, since a multicast protocol and a unicast protocol are different in the live service, different pasing processes and different capacity-based buffer management are carried out. It is therefore important to differentiate between the supply routes. In order to enable media segment repair when a media segment loss occurs within a tunnel or due to a traffic problem, data can be multicast over the interface M ' can be sent and the unicast repair unit 1095 receive the data and then the lost media segment through a unicast request in the multicast gateway 1070 receive. Since the media segment is to be received in a unicast path and processed in the process, the multicast gateway 1070 distinguish the segment information from existing multicast segment information.

To overcome this problem, the present disclosure proposes a method for discriminatingly identifying the URL of a multicast segment and the URL of a unicast segment.

Ie, every representation in the MPD , the 20 includes a base URL for each segment, defining a string based on which the segment was obtained.

In the present disclosure, a base URL is manipulated in accordance with a delivery method, so that a delivery route can be determined in which a corresponding representation is to be requested.

24 FIG. 12 shows an embodiment for defining a base URL based on a multicast ABR delivery method according to the present disclosure. In one embodiment, a base URL for each delivery method, as in 24 is defined in a control message by the network controller 1063 the staging unit 1060 is provided and to the service management unit 1072 of the multicast gateway 1070 was sent. The service management unit 1072 of the multicast gateway 1070 updates the base URLs in a pre-stored MPD with base URLs in the control message issued by the network controller 1063 was received.

An IP-based media service can be provided via one of multicast and unicast or both of multicast and unicast at the same time. If the media service is provided via one of multicast and unicast, then only the base URL of the corresponding delivery method is provided by the network control device 1063 provided. If the media service is provided by multicast and unicast simultaneously, then the base URL for the multicast and the base URL for the unicast can be combined by the network controller 1063 to be provided.

If the base URLs of a multicast media segment and a unicast media segment simultaneously by the network controller 1063 can be provided MPD a representation containing the base URL of the multicast media segment and a representation including the base URL of the unicast media segment.

The multicast gateway 1070 generates basic string patterns based on the configuration 24 and creates addresses where media segments are accessible through base URLs and segment templates.

25 shows an embodiment of base URLs in a MPD according to the present disclosure. If the base URL of a media segment that is included in a representation by the content rendering unit 1080 is selected, for example, is a base URL, denoted by reference character a in 25 is specified, then the content reproduction unit determines 1080 the representation as a multicast representation and thus requests a multicast media segment. In another example, if the content player 1080 of the media segment included in the illustration by the content player 1080 is selected, for example the content player 1080 which is denoted by reference symbol b in 25 is specified, then the content reproduction unit determines 1080 the representation as a unicast representation and requests a unicast media segment.

As such, a manifest is manipulated based on basic patterns and a media segment is requested based on a basic string that is distinguishable by a delivery path.

As described above, if an IP-based media service is provided, then a unicast-based service and a multicast-based service capable of distributing packet traffic can be provided simultaneously in the present disclosure. Therefore, a wider data bandwidth can be used.

The process of distinguishing delivery processes from each other in a manifest file (ie, an MPD file) for providing an ABR streaming service has been described. That is, the present disclosure provides a method that is compatible with an legacy ABR service, in which a delivery method by the content rendering unit 1080 , which determines the representation as without modification of an old manifest structure.

26 shows an embodiment of the semantics of a control message (or a multicast network control message) that the network control device 1063 the multicast gateway 1070 over the interface C _RM provides. The control message can be in an eXtensible Markup Language (XML) format and / or an HTTP-based API message format. In one embodiment of the present disclosure, the control message for providing the ABR multicast service is an HTTP dormant API message. The control message can be sent through an interface capable of sending a control message like that C _MS and the C _RM , The control message can generate manifest information (for example an MPD) for service initialization taking into account the mutual cooperation of a service provider / an Internet service provider and a linear network environment.

With reference to 26 can include the delivery control as its sub-elements @sIPaddr, @dIPaddr, @dport, @serviceId and deliverymethod.

The @ sIPaddr element specifies a source IP address for a multicast session (for example a ROUTE session) that delivers a media service.

The @ dIPaddr element specifies a destination IP address for the multicast session that delivers the media service.

The @ dport element specifies a destination port number for the multicast service that supplies the media service.

The @ serviceId element identifies the media service. This can be one of a service entry, an adaptation-set @ id and an MPD @ id.

The deliverymethod element can be a container of transport-related information belonging to the content of the media service in a multicast or unicast mode of access. The deliverymethod element can include multicast_service and / or unicast_service. Each of these elements can have a basepattern element and a priority element as its sub-elements.

The multicast_service element can be a DASH representation that was delivered via the multicast, including the corresponding media component (s) of a multicast service. In other words, each field can mean a DASH representation that is supplied via the multicast.

As a sub-element of the multicast_service element, basepattern can specify a character string for use by a multicast ABR receiver to match against a segment URL used by a DASH client. This can be used for the DASH client to request DASH media segments of a parent DASH representation. A comparison can implicitly mean that the DASH media segment is delivered via the multicast.

As a further sub-element of the multicast_service element, priority specifies the priority of DASH presentation delivery considering a network and a capacity to provide the multicast service.

The unicast_service element can be a DASH representation that was delivered via the unicast and contains corresponding media component (s) that belong or belong to the unicast service. This means that each field can refer to a DASH representation that was supplied via the unicast.

As a sub-element of the unicast_service element, basepattern can specify a character string for use by a multicast ABR receiver to match against a segment URL used by a DASH client. This can be used for a DASH client to request DASH media segments of a parent DASH representation. A comparison can implicitly mean that the DASH media segment is supplied via the unicast.

As a further sub-element of the unicast_service element, priority specifies the priority of the DASH presentation delivery considering a network and a capacity to provide the unicast service.

27 is with 26 identical except that the deliverymethod element includes a broadcast_service element as its sub-element, and the broadcast_service element includes a basepattern element and a priority element as its sub-elements. That is why 26 referenced for the description of each element.

The tax message in 26 or 27 is shown, the multicast gateway 1070 be provided periodically or each time data is updated in the semantics of the control message. As an alternative, the control message can be sent to the multicast gateway in advance 1070 be provided to operate the multicast gateway 1070 manage adaptively. That is, since a string of a multicast route and a string of a unicast route included in the control message are sent to the multicast gateway in advance 1070 be sent when a MPD is provided at the beginning of the service, then the operation of the multicast gateway 1070 are managed adaptively through the paths of the strings.

In order to distinguish the delivery methods from one another by strings, ie to identify the strings defined in a manifest file, the network control device sends 1063 a control message as in 26 or 27 is shown to the multicast gateway 1070 before a media segment to the multicast gateway 1070 is sent in one embodiment of the present disclosure. The multicast segment becomes the multicast gateway 1070 through the multicast server 1050 Posted.

In another embodiment, the strings that are in 26 or 27 are shown in the SDP using the 3gpp , the SDP from DVB-IPTV SDP or periodic configuration information from a third party, and can be to the multicast gateway 1070 be sent.

In one embodiment of the present disclosure, the network controller includes 1063 the strings in the control message and can go to the multicast gateway 1070 send.

The network control device 1063 can operate the multicast gateway 1070 control by a service request or a control message for obtaining, initializing, etc. a service by the multicast gateway 1070 was sent.

That is, the network control device 1063 can send a control message that controls a media service sent from the multicast server through the CRM interface. Access information as in 26 or 27 are required to control a multicast flow in an external ISP management network or a multicast service controller designated by a network operator without the control message in a specific multicast session of the interface M to include through which multicast media is sent. Access is possible through the IP and the port of the corresponding multicast session, and the string of a segment URL, which is defined in a media representation, is accessible by at least one of component / adaptation identification information, MPD identification information or service entry identification information in a sent manifest. After access, a way in which the media segment can be operated can be determined by comparing a basic pattern that identifies a multicast / unicast service against a basic URL in the manifest file. In other words, it can be identified whether the URL the URL a segment in the multicast gateway 1070 is where a ABR supporting protocol is encapsulated, or is an HTTP URL for unicast from a specific server.

Furthermore, a suitable recipient operation can be realized by defining delivery methods, and a service can be conveyed directly and not in the manner of a detour. Furthermore, a seamless service can be done by defining the priorities of the multicast and unicast routes based on priority information considering the media segment capacities of the current interface M and the multicast gateway 1070 can be achieved. If a lost packet is also to be received via the unicast, then the lost packet is lined up on a multicast media segment in such a way that the lost packet can be requested in accordance with a current play time. The network control device 1063 In other words, sends both multicast route information and unicast route information in the control message to the multicast gateway 1070 to multicast service information and unicast service information in the MPD to update periodically. Thus, a time required for switching between the multicast service and the unicast service can be reduced. Furthermore, if the multicast service and the unicast service are present at the same time, their priorities can be set by a priority element.

If the multicast gateway 1070 operates as a proxy server, then different operating modes can be configured for the proxy server.

In the present disclosure, the multicast gateway 1070 operate in one from an in-gateway transparent proxy mode, an in-gateway forward proxy mode, an in-gateway DNS redirection with reverse proxy mode, an adhesive HTTP redirection plus reverse proxy mode and a manipulation of URLs in a manifest plus reverse proxy mode. The multicast gateway 1070 can be used as a home gateway or a IP-STB configured according to a proxy mode. The multicast gateway 1070 can be in a network gateway and with the location of the content player 1080 (that is, a client).

28 shows a simplified block diagram showing a corresponding part of the in 23 System architecture shown shows when the multicast gateway 1070 operates as a proxy server in accordance with the present disclosure.

In 28 a user network can use the multicast gateway 1070 and the content player 1080 (ie, a client). If the multicast gateway 1070 operates as a proxy server and the proxy mode is the in-gateway transparent proxy mode or the in-gateway forward proxy mode, then the multicast gateway 1070 can be configured with a home gateway and a multicast receiver. If the proxy mode is in-gateway DNS redirection with reverse proxy mode, then the multicast gateway can 1070 include a multicast receiver that sends data directly to the multicast server 1050 exchanges, and the multicast receiver can be a local DNS and a media cache unit. That is, when the multicast receiver is included in the user network, the multicast receiver can receive the multicast content through a device that acts as a gateway or a proxy that is included in the user network. In this case, the gateway or proxy can be viewed as a component of the ABR multicast network. The multicast receiver can act as a server or a multicast transmitter in the user network. Therefore, a decoding device included in the user network can consume the multicast content. Even if the decoding device is not capable of receiving the multicast content directly, multicast streaming can be enabled.

The in-gateway transparent proxy mode of the present disclosure is a mode in which the client 1080 based on IP information related to a target server (ie, the multicast server 1050 ) or the content hosting unit 1040 accesses as in 29 is shown. In this mode the client points 1080 Prior knowledge of access information regarding the multicast server 1050 on. That is, based on access based on the IP information regarding the multicast server 1050 or the content hosting unit 1040 , a DNS configuration and a host name are not required. In one embodiment, the network controller sends 1063 the server IP information in advance to the multicast gateway 1070 over the interface C _RM , Furthermore, the multicast availability is indicated by a unicast response. In the in-gateway transparent proxy mode is an end-to-end device with the content hosting unit 1040 or the multicast server 1050 connected by an HTTP kernel. Generally, the device is in the form of an STB or server transparent mode within a television. That is, a terminal and the content hosting unit 1040 (ie, the origin server) operate as a bypass without identifying the presence of caching in between.

1. 1. Der transparente HTTP-Proxy ist (wahrscheinlich) am selben Ort mit dem Multicast-Gateway 1070 in dem Heimat-Gateway oder der Verkehrslenkungsvorrichtung lokalisiert.
2. 2. Der Client 1080 tätigt einige GET-Anfrage für ein Manifest oder für Medien.
3. 3. Eine Anfrage wird durch das Multicast-Gateway 1070 abgefangen und mit einer Liste von URLs verglichen, von denen bekannt ist, dass sie alternativ über den Multicast verfügbar sind.
4. 4. Das Multicast-Gateway 1070 initiiert in bewusst langsamer Weise eine Multicast-Sitzung, um das Speichern eines lokalen Cache zu beginnen.
5. 5. In der Zwischenzeit werden jedwede Cache-Ausfälle durch das Multicast-Gateway 1070 in der Weise eines Proxy zu dem stromaufwärts gelegenen Unicast-Ursprung über die Schnittstelle U geleitet.
6. 6. Dies funktioniert nicht richtig, wenn das HTTPS ins Spiel kommt, da die Unicast-TLS-Sitzung den transparenten Proxy umgeht, da sie eine Ende-zu-Ende-Sitzung ist.

Exemplary operation in the in-gateway transparent proxy mode according to the present disclosure is given below.

1. 1. The transparent HTTP proxy is (probably) in the same place with the multicast gateway 1070 located in the home gateway or traffic routing device.
2. 2. The client 1080 makes some GET requests for a manifest or for media.
3. 3. A request is made through the multicast gateway 1070 intercepted and compared to a list of URLs known to be alternatively available via multicast.
4. 4. The multicast gateway 1070 initiates a multicast session in a deliberately slow manner to begin storing a local cache.
5. 5. In the meantime, any cache failures are caused by the multicast gateway 1070 in the manner of a proxy to the upstream unicast origin via the interface U directed.
6. 6. This does not work properly when HTTPS comes into play because the unicast TLS session bypasses the transparent proxy because it is an end-to-end session.

The multicast gateway performs in the in-gateway forward proxy mode according to the present disclosure 1070 according to 23 forward operation. Likewise, the in-gateway forward proxy mode does not require DNS configuration because access is based on prior knowledge of all access IP information regarding the multicast server 1050 or the content hosting unit 1040 is done, which is a final target server. As in the in-gateway transparent proxy mode, when data is requested, the identity of a server to be accessed is known. However, the request is forwarded to a corresponding server, ie the multicast gateway 1070 in the in-gateway forward proxy mode as in 30 is shown. For example, although a client setting is proxy.com, Ziel.com is in an address window. This means that all inquiries become the final destination via a proxy, ie the multicast gateway 1070 , forwarded. Accordingly, in the in-gateway forward proxy mode, since a private tunnel originating from a private tunnel CONNECT is established in advance, the client 1080 and the multicast gateway 1070 no HTTP communication through. The multicast availability is delivered in a unicast response as in the in-gateway transparent proxy mode.

1. 1. Der Client 1080 wird explizit konfiguriert, um das Multicast-Gateway 1070 als einen Proxy für alle (oder einige) seiner HTTP(S)-Interaktionen zu verwenden.
2. 2. Der Client 1080 fragt das Manifest über das Multicast-Gateway 1070 an.
3. 3. Der Client 1080 fragt Medien über das Multicast-Gateway 1070 an.
4. 4. Anfrage wird durch das Multicast-Gateway 1070 abgefangen und mit einer Liste von URLs verglichen, von denen bekannt ist, dass sie alternativ über den Multicast verfügbar sind.
5. 5. Das Multicast-Gateway 1070 initiiert in bewusst langsamer Weise eine Multicast-Sitzung, um das Speichern eines lokalen Cache zu beginnen.
6. 6. In der Zwischenzeit werden jedwede Cache-Ausfälle durch das Multicast-Gateway 1070 in der Art eines Proxy zu dem stromaufwärts gelegenen Unicast-Ursprung durch die Schnittstelle U geleitet.
7. 7. In dem HTTPS-Fall würde der Client 1080 VERBINDEN verwenden, um einen sicheren Tunnel mit der Unicast-Quelle zu erstellen, und wäre das Multicast-Gateway 1070 nicht in der Lage, diese Anfragen/Antworten zu sehen und abzufangen.
8. 8. Dies funktioniert nicht, da der vorwärts Proxy durch die Verwendung von VERBINDEN zum Einrichten eines privaten Tunnels zu dem Ursprung umgangen wird.

Exemplary operation in the in-gateway forward proxy mode according to the present disclosure is provided below.

1. 1. The client 1080 is explicitly configured to the multicast gateway 1070 to use as a proxy for all (or some) of its HTTP (S) interactions.
2. 2. The client 1080 asks the manifest via the multicast gateway 1070 on.
3. 3. The client 1080 asks media via the multicast gateway 1070 on.
4. 4. Request is through the multicast gateway 1070 intercepted and compared to a list of URLs known to be alternatively available via multicast.
5. 5. The multicast gateway 1070 initiates a multicast session in a deliberately slow manner to begin storing a local cache.
6. 6. In the meantime, any cache failures are caused by the multicast gateway 1070 in the manner of a proxy to the upstream unicast origin through the interface U directed.
7. 7. In the HTTPS case, the client would 1080 Use CONNECT to create a secure tunnel with the unicast source, and would be the multicast gateway 1070 unable to see and intercept these requests / answers.
8. 8. This does not work because the forward proxy is bypassed by using CONNECT to establish a private tunnel to the origin.

In the reverse proxy mode in-gateway DNS redirection according to the present disclosure, a reverse proxy forwards requests to physically / logically separate servers for the purpose of load balancing or a service. If access is from outside, then it only has the reverse proxy information. Ie, as in 31 is shown, the client recognizes 1080 the proxy as a general server. Because that's why the client 1080 based on a proxy IP, the client must 1080 through the proxy 1070 get and put a DNS through the proxy IP. For example, when a request for a target server is made, all accesses to the target server at the target server are at one address requested, which is mapped to the reverse proxy, and data is received accordingly. If a specific location is accessed with YouTube, filtering can be carried out to prevent forwarding by the proxy.

In-gateway DNS redirection with reverse proxy mode is a reverse proxy that sends a request to the client's original target server 1080 assigns, that is, the content hosting unit 1040 by an IP / host name by DNS redirection / interception of the multicast gateway 1070 for access. On the content hosting unit side 1040 (ie the origin), this is used to send a request and a data response through the host name of the reverse proxy. Therefore, no DNS is required in the in-gateway forward mode, whereas a DNS server in the in-gateway DNS redirection with proxy mode is required.

1. 1. Ein lokaler DNS-Dienst wird mit dem Multicast-Gateway 1070 in einer Heimat-Gateway-Verkehrslenkungsvorrichtung gemeinsam lokalisiert.
2. 2. Eine DHCP-geleaste Leitung wird der Client-Vorrichtung durch die Heimat-Gateway-Vorrichtung erteilt und spezifiziert, dass alle Clients den lokalen DNS-Dienst verwenden sollen, um Host-Namen aufzulösen.
3. 3. Der Client 1080 fragte ein Manifest an, und dieses wird unmodifiziert zurückgegeben.
4. 4. Der Client 1080 sieht in das Manifest hinein und versucht, den Unicast-Hostnamen aufzulösen.
5. 5. Das lokale DNS löst den Unicast-Hostnamen zu der IP-Adresse des Multicast-Gateway 1070 auf.
6. 6. Der Client 1080 tätigt eine Anfrage für Medien an die IP-Adresse des Multicast-Gateway 1070, von dem er annimmt, dass dieses die Unicast-Quelle ist.
7. 7. Das Multicast-Gateway 1070 kann dann mit Medienantworten, die über den Multicast empfangen wurden.
8. 8. HTTP funktioniert gut, da sich der Client 1080 mit dem umgekehrten Proxy in der (ungerechtfertigten) Annahme verbindet, dass dieser der wahre Ursprung ist.

Exemplary operation in proxy mode in-gateway DNS redirection according to the present disclosure will be provided below.

1. 1. A local DNS service is using the multicast gateway 1070 localized together in a home gateway traffic routing device.
2. 2. A DHCP leased line is given to the client device by the home gateway device and specifies that all clients should use the local DNS service to resolve host names.
3. 3. The client 1080 asked for a manifesto and it will be returned unmodified.
4. 4. The client 1080 looks into the manifest and tries to resolve the unicast hostname.
5. 5. The local DNS resolves the unicast host name to the IP address of the multicast gateway 1070 on.
6. 6. The client 1080 makes a request for media to the IP address of the multicast gateway 1070 which he assumes is the unicast source.
7. 7. The multicast gateway 1070 can then use media responses received via the multicast.
8. 8. HTTP works well because of the client 1080 connects to the reverse proxy on the (unjustified) assumption that it is the true origin.

The sticky HTTP redirection plus reverse proxy mode according to the present disclosure is intended to add the HTTP-302 redirection mode. In other words, HTTP responds to the web server with an HTTP response status code. A 302 code under the HTTP response status codes is used to move a user to a new one URL , A 302 redirection means that a requested resource is temporarily transferred to a new one URL was moved. In this way, the new URL is made accessible while an existing URL is maintained.

Accordingly, the client receives 1080 a MPD in a bootstrapping process by the content hosting unit 1040 (ie, the origin server) and interface B, as in 32 is shown. The content hosting unit 1040 can redirect to the IP or hostname of the multicast gateway 1070 through the HTTP 302 perform so that the multicast gateway 1070 Download data like the origin.

1. 1. Der Client 1080 fragt ein Manifest von dem Unicast-Ursprung über die Unicast-Bootstrapping-Schnittstelle B an.
2. 2. Die Inhalts-Hostingeinheit 1040 erteilt eine HTTP-302-Umleitung, die den Client 1080 auf den Hostnamen oder die IP-Adresse des Multicast-Gateway 1070 verweist.
3. 3. Der Client 1080 fragt Medien von dem Multicast-Gateway 1070 unter der Annahme an, dass dieses der Ursprung ist.
4. 4. Das HTTP es funktioniert gut, da sich der Client 1080 mit dem umgekehrten Proxy in der (ungerechtfertigten) Annahme verbindet, dass dieser der wahre Ursprung ist.

Exemplary operation in sticky HTTP redirection plus reverse proxy mode according to the present disclosure is provided below.

1. 1. The client 1080 asks for a manifest from the unicast origin via the unicast bootstrapping interface B on.
2. 2. The content hosting unit 1040 issues an HTTP 302 redirect that the client 1080 the host name or the IP address of the multicast gateway 1070 points.
3. 3. The client 1080 asks media from the multicast gateway 1070 assuming that this is the origin.
4. 4. The HTTP it works fine as the client 1080 connects to the reverse proxy on the (unjustified) assumption that it is the true origin.

In the "manipulation of URLs in the manifest plus reverse proxy" mode according to the present disclosure, the host name / that IP of the multicast gateway 1070 sent such that the multicast gateway 1070 serves as a server as the origin, as is the case in the above reverse proxy (cf. 33 ). However, the URLs in the manifest under the bootstrapping information passed through the interface B a host name was selected, which can select a server according to the multicast situation. In this case, this is a proxy mode in which the content hosting unit 1040 (that is, the origin server) recognizes the multicast and controls the hostname in the manifest, and does not delete the content URLs included in the manifest or reduce components.

1. 1. Der Client 1080 fragt ein Manifest von dem Unicast-Ursprung über die Unicast-Bootstrapping-Schnittstelle B an.
2. 2. Die Inhalts-Hostingeinheit 1040 gibt eine personalisiertes Manifest, das den aufzulösen Hostnamen enthält, zu dem Multicast-Gateway 1070 oder die IP-Adresse des Multicast-Gateway 1070 zurück.
3. 3. Der Client 1080 fragt Medien von dem Multicast-Gateway 1070 unter der Annahme an, dass dieses der Ursprung ist.

Below is an example operation in the "Manipulation of URLs in Manifest + Reverse Proxy" mode according to the present disclosure.

1. 1. The client 1080 requests a manifest from the unicast origin via the unicast bootstrapping interface B.
2. 2. The content hosting unit 1040 issues a personalized manifest to the multicast gateway, including the hostname to be resolved 1070 or the IP address of the multicast gateway 1070 back.
3. 3. The client 1080 asks media from the multicast gateway 1070 assuming that this is the origin.

In the meantime, MPD-DASH defines a timeline by a segment start time and a segment duration by a piece of data / file delivery in a segment mode. The element that defines the segment timeline in the MPD can also be used to calculate the broadcast and receive synchronization information of a segment availability timing and a segment presentation timing based on a time scale provided during encoding.

34 shows an example of the semantics of a segment timeline element for creating a segment timeline of the segment availability timeline and the segment presentation timeline in the MPD-DASH. that is, 34 shows the MPD-DASH-MPD semantics of the segment timeline element.

An @ t element and an @ d element, which are sub-elements of the segment timeline element 34 are the earliest presentation time of a segment or a segment duration.

In 34 information can be defined according to the @ t element and the @ d element itself within the segment. According to an embodiment, as in 35 as shown, the information can be defined in a sidx box that includes segment index information in an index segment. In this case, the first offset information and the earliest presentation time of a media sample of the segment can be defined by 32 bits or 64 bits.

If there is no coding of the index segment, the value of baseMedia-DecodeTime in 'tfdt' of a moof box can replace the earliest presentation time. The segment timeline created in this way can define the segment presentation time by taking into account the entire MPD properties and applying the following equation 1. $$\text{Segment presentation time}=\text{MPD}@\text{availability start time}+\text{period}@\text{begin}+\text{earliest presentation time of the kth segment}+\text{MPD}@\text{suggestedPresentationDelay}$$

In Equation 1 above, the MPD @ availabilityStartTime element, the Period @ start element, and the MPD @ suggestedPresentationDelay element are included in the MPD as in 36 is shown. The MPD @ availabilityStartTime element indicates a point in time at which a DASH client accesses a DASH server to ensure the MPD and the period @ start element indicates a point in time at which a period of time is divided into one or more Time slots from a service perspective within the MPD starts. The SegmentBase @ presentationTimeOffset element and timescale indicate a calculated relative time between the start time of the period and the timeline of the actual media audio / video (A / V). The MPD @ SuggestedPresenationDelay element specifies a value determined by DASH clients considering device-to-device synchronization, jitter, and a transmission delay (or xmit delay).

37 FIG. 12 is a diagram showing an embodiment of an MPD-DASH synchronization timeline.

37 (a) shows an encoder timeline for encoding a media segment, and 37 (b) shows an availability timeline representing a segment duration (ie, a timeline in a state where a Segment is prepared in a DASH server). 37 (c) shows a timeline of broadcast frames sent from the DASH server. 37 (d) indicates a timeline of frames received by the DASH client and 37 (e) specifies a segment presentation timeline that was calculated taking into account all delay factors. that is, 37 (e) FIG. 14 shows an example of the segment presentation timeline calculated by applying Equation 1 described above.

In the MPD-DASH, a timeline is configured with a point in time at which a segment is available in a DASH server, from the point of view that if data is accumulated during the segment duration and thus a complete file is formed, the data can be sent as determined by the availability timeline 37 (b) is shown. However, there may be disadvantages to the latency in which pieces of file are available and sent.

To solve this problem, the present disclosure proposes an embodiment in which, although a segment is not fully available at the time of the linear service broadcast, the segment can be sent in advance.

That is, if the segment availability start time by the value of the Segment-Base @ availabilityTimeOffset element in the MPD is reduced, the segment can be requested in advance, even if the segment is not fully available. In one embodiment, this value is obtained by subtracting an availabilityTimeOffset value from the segment availability start time, and the segment can be requested for this value earlier. In one embodiment, the definitions are defined in the SegmentBase @ availabilityTimeOffset element or the BaseURL @ availabiltyTimeOffset element, as described in 38 is shown. For details of the availabilityTimeOffset information, reference is made to the description of 38 taken.

The foregoing description is expressed in Equation 2 as follows. $$\begin{array}{l}\text{Segment availability start time}=\text{Start: MPD}@\text{availability start time}+\text{period}@\text{begin}+\text{MST}\left(\text{k}\right)-\left(\text{segment Base}@\text{availability timeoffset}\right)+\text{MD}\left(\text{k}\right)\\ \text{MST}\left(\text{k}\right)=\text{MPD}-\text{Start time of the kth segment in the time span MD}\left(\text{k}\right)=\text{MPD duration of the kth segment in the time period}\end{array}$$

The segment base @ availabilityTimeOffset value is subtracted or added from or at the segment availability start time, in particular for the rapid start-up for fast media playback. Thus, the media reproduction can be performed quickly and a supplier route switching time can be shortened compared to the conventional technology.

If the multicast ABR system architecture as in 23 shown, then a delay occurs while the media content is being generated by the content encoding unit 1031 is encoded, the content hosting unit 1040 and / or the multicast server 1050 passes. If the multicast gateway 1070 Operating as a proxy server, then a delay (ie, latency) may occur from the connection in creating a data flow depending on the proxy mode.

Therefore, the present disclosure proposes an embodiment to compensate for such a delay in MPD DASH technology.

That is, the output of the content coding unit 1031 is in a delivery format by the multicast server 1050 encapsulated, and then sent in a specific protocol stack (for example, a ROUTE protocol). Here, a segment presentation time is defined by reflecting a shipment delay using an MPD @ suggestedPresentationDelay element. However, if the data is output from the content coding unit 1031 in the delivery format in the multicast server 1050 be encapsulated, pushed through the interface M and in the multicast gateway 1070 accumulated is the initially defined value for the MPD @ suggestedPresentationDelay element meaningless or difficult to use in practice. In addition, the segment availability start time can be different since a segment mode is different for each channel. In other words, the encoded manifest timing information and timing information at which the data is obtained through a broadcast interface called multicast ABR.

According to an embodiment of the present disclosure, the network control device can 1063 Generate timing compensation information based on which DASH- Timing information can be reconfigured, the timing compensation information included in a control message, and the control message to the multicast gateway 1070 and / or the multicast server 1050 can be sent. In one embodiment, the network controller creates 1063 the timing compensation information based on timing information provided by the content provider controller 1020 to be provided. In the present disclosure, the timing compensation information is also referred to as timing update information or synchronization information for the sake of simplifying the description.

That is, since the timing information provided by the content provider controller 1020 are provided directly to the network control device 1063 without passing through other blocks, there is no delay. However, if the timing information provided by the content provider controller 1020 are provided, the content preparation unit 1030 and the multicast server 1050 then a delay occurs, resulting in a difference between the 2 timing information.

Ie in the in 23 System architecture shown, provides the content provider controller 1020 the network control device 1063 Information and timing information related to a current segment being played based on a representative reference play time of a linear service currently being provided in an RF or a reference timeline based on a network state. The network control device 1063 generates the timing compensation information based on the information and the timing information related to the segment by the content provider controller 1020 considering the network status and the proxy server mode in which the multicast gateway was received 1070 operates as a proxy server. In one embodiment, the timing compensation information includes an @ availabilityStartTime element, an @ suggestedPresentationDelay element, and an @ availabilityTimeOffset element. For details of the items is on 40 and 41 Referred. The timing compensation information becomes the multicast server 1050 over the interface C _MS or to the multicast gateway 1070 sent via the CRM interface.

That is, the multicast server 1050 may reconfigure the synchronization information based on the timing compensation information when the delivery reformatting switches from the backward compatibility perspective or when a timing change occurs that causes a new encoding.

If there is a need to meet the request time of a data packet due to the difference in latency between a broadcast linear service and an MABR service over IP, then a current wall clock reference segment must be synchronized. If k of a requested segment, segment (k), and a new time model are created, then a segment availability start time and a segment presentation time are to be reconfigured.

In this case, the network controller 1063 Generate timing compensation information based on the timing information provided by the content provider controller 1020 received, the timing compensation information may include in a control message, and may then send the control message to the multicast server 1050 and / or the multicast gateway 1070 over the interface C _MS and / or send CMR.

In this case, a suggestedPresentationDelay value is determined considering all of a segment duration, a jitter, a transmission delay (or an xmit delay) and a physical stack delay, as in 39 is shown. The multicast gateway 1070 or the client 1080 sets the segment presentation time using the SuggestedPresentationDelay value. If the control message further comprising the timing compensation information from the network controller 1063 is sent, the multicast gateway updates 1070 or the client 1080 corresponding element values in one MPD by the multicast server 1050 received with corresponding item values included in the control message and sets the segment availability start time and the segment presentation time using the updated item values.

The multicast server is also used 1050 the timing compensation information included in the control message through the interface C _MS and or CRM was sent to a corresponding value in the MPD set by the content preparation unit 1030 and / or the content hosting unit 1040 was provided, which enables a new coding.

In one embodiment, information related to a kth segment can be provided by a control interface SP-MC-X (or the client) by monitoring the current segment being played ( K ) are provided in the linear service, and the greatest possible synchronization between the devices can be achieved by applying a kth earliest presentation time.

As described above, a timeline can be obtained by adding or subtracting the availabilityTimeOffset value to or from the segment availability start time. If the delivery format of the multicast server 1050 is re-encoded to reduce a film fragment size and thus narrow a moof interval in the segment, then the segment availability start time should be reconfigured by the availabilityTimeOffset value. Therefore, if there is a change in the delivery format through a request from the content provider (or service provider), or to reduce latency from or linear service, the segment availability start time can be reconfigured using the timing compensation information provided by the network controller 1063 were provided.

The 39 (a) to 39 (f) FIG. 14 shows diagrams showing timelines according to an embodiment of the present disclosure. 39 (a) shows an encoder timeline for encoding a media segment, and 39 (b) shows a receive timeline that reflects a segment duration. 39 (c) shows a receive timeline that reflects both a segment duration and an availability time offset. Ie, in the reception time ( ACO ) according to 39 (c) A segment can be requested by reducing a segment availability start time by a SegmentBase @ presentationTimeOffset value that reflects a segmented data piece mode of the segment or the network status of the MABR. 39 (d) shows a segment presentation timeline defined using information in an MPD by the multicast server 1050 is provided, and 39 (e) FIG. 14 shows a segment presentation timeline defined based on timing compensation information provided by the network controller 1063 are provided. That is, according to the presentation timeline-1 39 (e) FIG. 4 is a segment presentation timeline that was redefined using an MPD @ suggestedPresentationDelay value that was updated based on timing compensation information provided by the network controller 1063 were provided. In the presentation timeline 2 according to 39 (f) , an attempt is made to buffer segment (k) without buffering the playback of a current segment, where segment 1 is based on a linear service AV startup that serves as a current reference. Information to be applied at this time is information corresponding to the segment (k) and the new MPD @ availabilityStartTime, Period @ starttime, MPD @ suggestedPresentationDelay and SegmentBase @ presentationTimeOffset, which is provided by the network control device 1063 received and is the presentation timeline 2 a new segment presentation timeline that was set based on this information.

40 and 41 show a further embodiment of a control message by the network control device 1063 in accordance with the present disclosure in which the semantics of the control message are obtained by providing the timing compensation information described above according to the control message 26 have been added. Like the tax message according to 26 , the control message according to 40 and 41 are in an XML format or an HTTP dormant API message format.

In one embodiment, the timing compensation information includes an @ id element, an @ availabilityStartTime element, an @ suggestedPresentationDelay element, and an @ availabilityTimeOffset element.

The @ id element specifies an identifier for a media presentation.

The @availabilityStartTime element provides an anchor for calculating the earliest availability time (in the UTC ) of any segment included in the media presentation if the @ type field is 'dynamic'. If the @ type field is 'statte', then there is a segment availability start time for all segments that are in the MPD were referenced.

The @ suggestedPresentationDelay element gives a fixed delay offset from the presentation time of each access unit which is to be used for the presentation of each access unit if the @ type field is dynamic. If the @ type field is static, the value of this attribute is ignored.

The @availabilityTimeOffset element specifies an offset for defining a set segment availability time.

For the description of each element that was not described here, reference is made to 40 and 41 taken.

The control message may further include a segment template element that provides segment template information, and may include an @media element and an @skip_number element as its sub-elements.

The @media element specifies a template for generating a media segment list.

The @skip_number element specifies the number of media elements to be skipped for synchronization.

42 FIG. 12 is a block diagram showing a receiver according to an embodiment of the present disclosure. The recipient can use the content player 1080 or part of the content display unit 1080 his.

The in 42 The receiver shown can comprise a signal which comprises a multicast service and / or a unicast service by a tuner. Alternatively, the receiver may receive the signal comprising the multicast service and / or the unicast service from the multicast gateway 1070 receive. In one embodiment, the multicast service and / or the unicast service is a broadcast service. Furthermore, the receiver can receive an MPD from the tuner and / or the multicast gateway in advance 1070 receive. In one embodiment, the MPD updated based on information included in a control message as in 41 and 42 is shown by the network controller 1063 issued and sent to the recipient.

The receiver can convert an analog signal into a digital signal using an analog-to-digital converter ( ADC ) convert and demodulate the received signal using a demodulator. With the received signal, the receiver can use channel sync & EQ perform synchronization and equalization and decode the received signal using a channel decoder. The decoded signal is represented by a layer 1- ( L1 ) Signaling parser parsed, and thus the receiver L1 - Obtain signaling information. The L1 Signaling information can be supplied to a baseband control device of the receiver and can be used to obtain physical layer data. In addition, the L1 signaling information can be input into the signaling control device of the receiver. In addition, the L1 signaling parser can obtain L2 signaling information from the decoded signal. The L2 Signaling information may include service layer signaling information for service acquisition. The service layer signaling information may include user service bundle description ( USBD ) Information, service-based transport session instance description (S-TSID) information, associated process description ( APD ) Information, DASH media presentation description ( MPD ) Information, HTML entry site location description ( HERO ) - Information and distribution window description- ( DWD ) Information.

The L2 signaling information obtained can be input into the signaling control device. The signaling controller can communicate with a service layer signaling channel (or a service signaling channel (ssc)) processing buffer and a parser to create a service MAP database ( DB ) to update. In addition, a service ( SG ) Processor update the service DB. The receiver can restore a packet header according to the signaling information input to the signaling controller and receive an IP packet using an IP packet filter. In addition, the recipient's network switch can receive the IP packet through wired or wireless communication using a TCP / IP stack. The received IP packet is entered into the A / V service controller through the common protocol stack. The demultiplexer of the receiver can demultiplex audio and video data. The receiver can output audio data using an audio decoder and an audio renderer, and output video data using a video decoder and a video renderer.

According to an embodiment of the present invention, multicast transmissions can be effectively provided between devices belonging to a conventional broadcast network, the Internet, a home network, and the like.

According to one embodiment of the present invention, the load on the network can be reduced by switching the conventional unicast broadcast to a multicast broadcast.

According to an embodiment of the present invention, the problem of delay caused by network conditions during linear service and real-time live encoding can be overcome and fast AV startup can be supported.

Although the description of the present invention has been described with reference to each of the accompanying drawings for the sake of clarity, it is possible to design new embodiments by merging the embodiments shown in the accompanying drawings. If a recording medium that is readable by a computer in which programs for executing the embodiments mentioned in the above description are recorded is designed by a person skilled in the art, this may fall within the scope of the appended claims and their equivalents.

The devices and methods according to the present invention may not be limited by the structures and methods of the embodiments mentioned in the above description. The embodiments mentioned in the above description can be configured in the manner of a selective combination with one another in whole or in part in order to enable various modifications.

In addition, the image processing method according to the present invention can be implemented with processor readable code in a processor readable recording medium provided in a network device. The processor readable medium can include any type of recording device capable of storing data readable by a processor. The processor readable medium can be one from one ROME , one R.A.M. , a CD-ROM, magnetic tapes, floppy disks, optical data storage devices, and the like, and may also include a carrier wave type implementation such as broadcast over the Internet. Furthermore, since the processor readable recording medium is distributed on a computer system that is connected via a network, processor readable code can be stored and executed in a distributed manner.

Although the invention has been described above with reference to the exemplary embodiments, it will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the invention described in the appended claims. Such modifications are not to be considered as separate from the technical idea or the point of view of the present invention.

Both device and method inventions are described in this specification, and descriptions of both the device and method inventions are complementary applicable if necessary.

Mode for carrying out the invention

Various embodiments have been described in the best mode for carrying out the invention.

Industrial applicability

The present invention is useful and reproducible in the field of broadcasting and video signal processing.

Claims (14)

A method of receiving a media service, the method comprising: receiving and storing media presentation description information, the segment uniform resource location pointer (URL) information for media segments, and timing information for presentation the media segments include, receiving and storing media segments sent over at least one of multicast or unicast, and outputting a media segment that has been requested for content reproduction among the stored media segments; Receiving a control message comprising at least one of basic URL pattern information for identifying at least one media segment that was broadcast over the multicast and at least one of basic URL pattern information for identifying at least one media segment that was broadcast over the unicast; and updating the segment URL information in the stored media presentation description information based on the basic URL pattern information included in the received control message. Procedure according to Claim 1 wherein the control message further includes priority information regarding a representation that includes the at least one media segment that was broadcast over the multicast and priority information regarding a representation that includes the at least one media segment that was broadcast over the unicast. Procedure according to Claim 1 wherein the control message further includes Internet Protocol (IP) address information and port information related to a transport session that the at least one media segment delivers over the multicast. Procedure according to Claim 1 wherein the control message further includes service identification information, and wherein the service identification information is one of a service entry, an adaptation set identifier at a component level, and a media presentation description identifier at a service level. Procedure according to Claim 1 , wherein the control message is received in the form of an HTTP dormant API message. Procedure according to Claim 1 wherein the control message further includes timing compensation information, further comprising setting a segment presentation time by updating timing information in the stored media presentation description information based on the timing compensation information. A media service device comprising: a broadcast server configured to send media presentation description information including segment uniform resource location pointer (URL) information for media segments and timing information for presenting the media segments, and broadcast media segments via at least one of a multicast or a unicast; a multicast gateway configured to receive and store the media presentation description information, receive and store the media segments, and output a media segment that has been requested for content reproduction among the stored media segments; and a network controller configured to generate a control message comprising at least one of basic URL pattern information for identifying at least one media segment that was broadcast over the multicast and at least one of basic URL pattern information for identifying at least one media segment that over the unicast was sent, and to send the control message, wherein the multicast gateway is configured to receive the control message and update the segment URL information in the stored media presentation description information based on the basic URL pattern information included in the received control message. Media service device according to Claim 7 wherein the control message further includes priority information regarding a representation comprising the at least one media segment that was broadcast over the multicast and priority information regarding a representation comprising the at least one media segment that was broadcast over the unicast. Media service device according to Claim 7 wherein the control message further includes Internet Protocol (IP) address information and port information related to a transport session that the at least one media segment delivers over the multicast. Media service device according to Claim 7 wherein the control message further includes service identification information, and wherein the service identification information is one of a service entry, an adaptation set identifier at a component level, and a media presentation description identifier at a service level. Media service device according to Claim 7 , wherein the control message is sent in the form of an HTTP dormant API message. Media service device according to Claim 7 wherein the control message further includes timing compensation information, and wherein the multicast gateway is configured to set a segment presentation time by updating timing information in the stored media presentation description information based on the timing compensation information. Media service device according to Claim 7 , wherein the multicast gateway is located in at least one of a home gateway or a connected set-top box. Media service device according to Claim 7 when the multicast gateway operates as a proxy server, the proxy server operates in an in-gateway transparent proxy mode.

Images