WO2009109232A1 - Procédé et appareil de distribution de contenu multimédia sur un réseau de communications - Google Patents

Procédé et appareil de distribution de contenu multimédia sur un réseau de communications Download PDF

Info

Publication number
WO2009109232A1
WO2009109232A1 PCT/EP2008/052776 EP2008052776W WO2009109232A1 WO 2009109232 A1 WO2009109232 A1 WO 2009109232A1 EP 2008052776 W EP2008052776 W EP 2008052776W WO 2009109232 A1 WO2009109232 A1 WO 2009109232A1
Authority
WO
WIPO (PCT)
Prior art keywords
fragments
media stream
fragment
missing
node
Prior art date
Application number
PCT/EP2008/052776
Other languages
English (en)
Inventor
Andreas Ljunggren
Robert Skog
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to GB1012831.2A priority Critical patent/GB2470306B/en
Priority to PCT/EP2008/052776 priority patent/WO2009109232A1/fr
Publication of WO2009109232A1 publication Critical patent/WO2009109232A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/478—Supplemental services, e.g. displaying phone caller identification, shopping application
    • H04N21/4788—Supplemental services, e.g. displaying phone caller identification, shopping application communicating with other users, e.g. chatting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/632—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing using a connection between clients on a wide area network, e.g. setting up a peer-to-peer communication via Internet for retrieving video segments from the hard-disk of other client devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/6473—Monitoring network processes errors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64746—Control signals issued by the network directed to the server or the client
    • H04N21/64761—Control signals issued by the network directed to the server or the client directed to the server
    • H04N21/64776—Control signals issued by the network directed to the server or the client directed to the server for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications

Definitions

  • the invention relates to the field of distributing media over a communications network, and in particular to the field of distribution of IPTV using a communications network.
  • IPTV IPTV
  • IPTV is typically broadcast using a broadband access network, in which channels are transmitted over a broadband network from a super head-end down to an end-user's set top box (STB).
  • STB set top box
  • Linear content delivery in which all channels in a subscription are simultaneously delivered to a user's set top box (STB), is not suitable for IPTV, as IPTV has limited bandwidth available over a broadband connection.
  • a typical ADSL broadband connection provides a capacity of between 3 and 8 Mbps, and ADSL2 promises to deliver up to 25 Mbps downstream, whereas VDSL can provide a capacity of greater than 30 Mbps.
  • Standard quality MPEG 2 IPTV content requires 2 Mbps per channel, and HDTV will require around 8-10 Mbps per channel.
  • the MPEG 4 standard will approximately halve the bandwidth required to deliver IPTV content with the same quality. Nevertheless, the available bandwidth is a scarce resource, and IPTV solutions must limit the number of channels that can be delivered simultaneously.
  • FIG. 1 illustrates a known way of distributing media in which an IPTV media stream originates in a service provider network 1 , is passed to a core network 2, is further passed into a metro network 3, and finally is sent via access networks 4 to each home network 5 that contains an STB that wishes to receive the media stream.
  • Networks can quickly become saturated due to heavy traffic loads.
  • content can be multicast to reduce bandwidth demands for broadcast TV distribution.
  • Video on Demand (VoD) services can be handled by VoD cache servers located close to the end-user.
  • such caches require additional investment, and many routers would need to be replaced, as existing routers may not support IPTV multicasts.
  • IPTV media stream can be delivered to a STB from another STB, from a media injector from which the stream originates, or from any other peer in the network.
  • An IPTV media stream is typically compressed in order to save bandwidth.
  • An example of a compressed media format is MPEG.
  • MPEG media streams contain different frames, such as l-frames, P-frames and B-frames.
  • l-frames do not depend on data contained in the preceding or following frames, as they contain a complete picture.
  • P-frames provide more compression than l-frames because they utilize data contained in the previous l-frame or P-frame.
  • B-frame are similar to P-frames, except that B-frames interpolate data contained in the following frame as well as the preceding frame.
  • B-frames usually provide more compression than P-frames.
  • every 15th frame or so is an l-frame.
  • P-frames and B-frames might follow an l-frame as follows: IBBPBBPBBPBB(I). The order and number of frames in the sequence can be varied.
  • the average time for switching between channels therefore depends on the length of time between l-frames.
  • the length of time is around 0.5 seconds.
  • the length of time between l-frames can be several seconds.
  • the media stream includes payload data and metadata.
  • the payload data is the media data itself, and is decoded and shown by the receiver.
  • Payload data typically comprises frames as described above.
  • the metadata includes all other data in the media stream. This may be, for example, data describing the payload data, or information establishing signalling between two peers.
  • the media stream is sent in "fragments". Fragments are discrete portions of the media stream containing both the payload data and the metadata.
  • a buffer containing fragments is illustrated in Figure 3.
  • a fragment may contain both metadata about the media stream, and payload data from the media stream itself.
  • the P2P network interface (in, for example, a STB) requests fragments from other P2P peers.
  • the P2P logic is writing fragment number 21 into the buffer and fragment number 17 is sent to the video decoder.
  • fragments are requested from other peers in the P2P network. However, there are situations when one peer does not have the requested fragment, or simply does not respond to the request. In this case, the requesting peer must find the fragment from another peer. Since the data is distributed over a multi-origin network, it is likely that some fragments will be lost due to network faults, or peers quickly joining and leaving the network, in which case it will not be possible to obtain the missing fragment from anywhere. In the worst case scenario, fragments containing parts of key frames (which can be seen as "key fragments”) may be permanently lost. If this happens, many peers will waste time and effort attempting to find such fragments, with no chance of success.
  • the inventors have realised the problems associated with the prior art and devised an apparatus and method to mitigate the problems described above.
  • a node in the network which may be a media injector, transmits a sequence of media stream fragments and recovery record fragments.
  • the recovery record fragments contain sufficient information to enable missing media stream fragments to be reconstructed from the media stream fragments adjacent to the missing fragments.
  • a node in the network receives a sequence of media stream fragments, together with recovery record fragments.
  • the node determines if any media stream fragments in the sequence are missing and, if so, sends a request to a further node requesting the missing media stream fragments. If the missing media stream fragments cannot be recovered, they are reconstructed from adjacent media stream fragments and the recovery record fragments using a suitable reconstruction method such as, for example, Reed Solomon error correction.
  • the method further comprises storing the media stream fragments and recovery record fragments in a memory. This is in order to preserve the fragments in a buffer for use by a video decoder when the fragment is required. However, if a fragment is not useable or required, then there is no need to store it.
  • each media fragment may include fragment data relating to each media stream fragment.
  • Such fragment data may comprise an indicator of whether that media stream fragment is a key fragment comprising key data relating to the media stream.
  • the reconstruction of missing fragments may be prioritised on the basis of the fragment data. For example, it may be that only missing key fragments are reconstructed, in which case it is likely that the reconstruction will be on the basis of adjacent key fragments together with the recovery records.
  • the fragment data is optionally included in metadata contained within the fragment. This is advantageous because both the fragment and the fragment data can be efficiently sent together.
  • the fragment data is added to each fragment at a media injector.
  • the fragment data is received separately from each fragment. This is advantageous in the case where a node communicates with a further node, and can send the fragment data separately from the fragment itself, without having to rewrite the fragment.
  • Key data optionally comprises complete image data for a single image in the media stream.
  • the key data may comprise an l-frame.
  • key data can be any data that is crucial to the media stream. Further examples of key data are lcecast with ID3 tagging, Ogg- tagging, x.264 B frames, header information, Closed Caption data, and encryption data.
  • media stream fragments are transmitted in Maximum Transmission Unit packets. If this is the case the recovery record fragments may optionally use up space within each Maximum Transmission Unit packet not used by the media stream fragments. Alternatively, the recovery record fragments may utilise a fixed proportion of bandwidth.
  • the node is optionally a Set Top Box.
  • the communications network is a peer to peer communications network, and each node is a peer node.
  • a media injector node for distributing media content in a communications network.
  • the node comprises a receiver for receiving a media stream.
  • the node also includes a processor for partitioning the media stream into a sequence of media stream fragments and generating recovery record fragments, the recovery record fragments providing enough information to enable the reconstruction of a missing media stream fragment from adjacent media stream fragments.
  • a transmitter is provided for sending the media stream fragments and recovery record fragments to at least one node located in the communications network.
  • a node for use in an communications network.
  • a receiver receives a sequence of media stream fragments, and recovery record fragments.
  • a processor determines if any fragments in the sequence are missing.
  • a transmitter transmits a request to a further node for the missing fragments.
  • the processor is also arranged to reconstruct the missing fragments using the recovery record fragments and adjacent media stream fragments.
  • apparatus for use in distributing media over a communications network, the apparatus comprising means for performing the method as described in the first or second aspect of the invention.
  • a program for controlling an apparatus to perform the method as described in the first or second aspect of the invention.
  • a program which, when loaded into an apparatus, causes the apparatus to become an apparatus according to the sixth aspect of the invention.
  • a program according to the sixth or seventh aspects of the invention carried on a carrier medium.
  • the carrier medium is optionally a storage medium.
  • a storage medium containing a program according to any one of the sixth or seventh aspects of the invention.
  • Figure 1 illustrates schematically in a block diagram an architecture for the distribution of IPTV
  • Figure 2 illustrates schematically in a block diagram an architecture for the distribution of IPTV in a peer to peer network
  • Figure 3 illustrates schematically in a block diagram a buffer in a STB containing data fragments
  • Figure 4 illustrates schematically in a block diagram a media injector and two Set Top Boxes
  • Figure 5 illustrates schematically in a block diagram the signalling required to initiate an IPTV broadcast with a first Set Top Box
  • Figure 6 illustrates schematically in a block diagram the signalling required to initiate an IPTV broadcast with a further Set Top Box
  • Figure 7 illustrates schematically in a block diagram keep alive messages sent by a Set Top Box
  • Figure 8 illustrates schematically the insertion of recovery records into the network
  • Figure 9 is a flow diagram illustrating the steps according to an embodiment of the invention.
  • Figure 10 illustrates schematically in a block diagram a media injector according to an embodiment of the invention.
  • Figure 11 illustrates schematically in a block diagram a peer node according to an embodiment of the invention.
  • key data is the l-frames in the MPEG format.
  • key data examples include any of: lcecast with ID3 tagging
  • the IPTV P2P requires a media injector in order to introduce the IPTV media stream into the network, although the media injector is not a true peer in the network in the sense that it sends media data but does not receive media data from the peers.
  • Figure 4 is a schematic representation of a simple IPTV P2P network.
  • the network includes an IPTV server 6 and two STBs STB1 and STB2.
  • Each STB includes a P2P network interface to which is connected a video decoder 9, 1 1.
  • STB2 receives the IPTV media stream from both STB1 and the IPTV Server 6, which injects either streaming content 4 or content from a database 7 using a P2P media injector 8.
  • other network nodes may be peers in the network.
  • FIG. 5 illustrates typical signalling required to initiate an IPTV broadcast with a first STB STB1.
  • the video decoder 9 in STB1 receives an instruction from a user to start channel X. This is relayed to the P2P network interface 2 in STB1 , which sends a request to a STB manager 10 in the IPTV back-end to join channel X.
  • the STB Manager 10 returns a peer list to the P2P function in STB1 , but no IPTV media stream.
  • the peer list includes the P2P media injector 8. Since the media injector can be considered as a peer in the network, it is termed STBO.
  • the P2P function in STB1 then sends a request to join channel X to STBO.
  • STBO receives an IPTV media stream from an IPTV media stream source (for example, from the database 7), and sends a peer list and an IPTV media stream comprising fragments of frames to the P2P network interface of STB1.
  • the P2P network interface of STB1 sends the frames to the video decoder 9 in STB1 , which can then show the IPTV media stream to the user.
  • Figure 6 illustrates typical signalling required to initiate an IPTV broadcast with a further STB STB2. It is assumed that STB1 is already receiving an IPTV media stream from
  • STBO When the user of STB2 wishes to receive channel X, he sends an instruction to logic within STB2, which is relayed to a P2P network interface in STB2.
  • the P2P network interface in STB2 sends a request join channel X to the STB manager 10.
  • STB manager 10 returns a peer list but no payload to STB2.
  • the peer list includes STBO and STB1 , as these are both possible sources for the IPTV media stream.
  • the P2P function in STB2 then sends a request to each of STBO and STB1 to join channel X.
  • STBO and STB1 each send a peer list and IPTV data stream to the P2P network interface in STB2, which passes the frames of the IPTV media stream to the video decoder.
  • IPTV media stream is used herein to refer to any kind of data having real time requirements, and includes Video on Demand, user defined TV content, interactive TV, interactive or co-operative games, or audio media.
  • the media stream is to be delivered to the user such that the user can observe the media content at a constant rate without interruptions or delays.
  • the problem can be solved by dedicating a certain amount of the bandwidth to recovery records.
  • Standard methods of error recovery such as Reed-Solomon error correction (as described, for example, in http://en.wikipedia.org/wiki/Reed- Solomon_error_correction) can then be applied.
  • the additional bandwidth may be a fixed amount, (e.g. 5% of all traffic).
  • each Maximum Transmission Unit (MTU) that is transmitted may be "padded out" with a set of recovery records whether or not it includes a key fragment.
  • MTU Maximum Transmission Unit
  • An MTU is the largest packet that a given layer of communications protocol can pass onwards.
  • a "path MTU” is also defined, as the smallest MTU of any of the IP hops of a "path” between a source and destination. Put another way, the path MTU is the largest packet size that traverses this path without suffering fragmentation.
  • IPTV fragments are transmitted, in some circumstances fragments may be grouped together to form MTU packets, but there may well be some free space in each MTU packet which is not taken up by the fragments themselves. The free space should therefore be filled with recovery records.
  • one MTU in Ethernet is 1500 bytes, but one MPEG-TS block is normally 188 bytes. It is thus possible to fit seven MPEG-TS fragments inside one Ethernet MTU, leaving a 184 byte "slack space" that can be used for recovery records.
  • FIG 8 shows the transmission of nine fragments 41-49 within three MTU packets 31 , 32, 33, each of which includes three fragments.
  • nine fragments 41-49 three are key fragments (fragments F2k, F6k and F7k 42, 46, 47) .
  • Each of the three MTU packets 31 , 32, 33 is also padded with a recovery record (R1 , R2, R3) 51 , 52, 53, each of which spans the key fragments found in fragments 1-9.
  • each of the recovery records R1 , R2, R3 contains information about fragments F2k, F6k and F7k.
  • each recovery record 51 , 52, 53 is half the size of any given key fragment.
  • the recovery records are transmitted into the network by the media injector at the same time as the fragments.
  • fragment F6k 46 will also be lost.
  • fragment F6k can be reconstructed from fragments F2k, F7k and recovery records R1 , R3.
  • the missing key fragment F6k can then be retransmitted utilizing standard P2P methodology, thus minimizing any impact on the network and the end user experience. If fragments are not transmitted in MTU packets, the same principle can still be applied.
  • a media injector inserts recovery record fragments which contain enough information for key fragments to be reconstructed using information from the key fragments either side of them, together with the information in the recovery records.
  • Figure 9 is a flow diagram illustrating the insertion of data into the network by a media injector, and the reconstruction of a key fragment if it goes missing in the network.
  • a video encoder encodes media as frames, which are passed to a media injector.
  • the media injector encodes the frames as data fragments, and sends the data fragments into the P2P network.
  • the media injector also inserts recovery records into the network.
  • a node that wishes to receive the channel from the media stream receives the fragments and, in addition to decoding and showing the media stream to the user, stores the fragments in a buffer.
  • the node determines whether any fragments, which are shortly due to be sent to the video decoder for rendering, are missing.
  • the node sends a request for the missing fragments. S6. If the missing fragments are not received after a predetermined delay period, the receiving node reconstructs the missing fragments using the information contained in adjacent fragments, together with the recovery records.
  • the media injector 23 comprises a media stream source 24, which may come from a Video on Demand server, a real time transmission or any other source.
  • the media injector 23 further comprises a processor 25 for converting media frames into media stream fragments, and generating recovery record fragments in addition to the media stream fragments.
  • the media stream fragments containing key frames are optionally tagged with key frame indicators.
  • the media injector 23 further comprises a transmitter for sending the media stream fragments and recovery record fragments into the P2P network.
  • the STB 13 comprises a receiver
  • the STB 13 further comprises a processor
  • the STB 13 further comprises a transmitter 30 for requesting missing key fragments. If the missing key fragments are still not received, the processor reconstructs them (for example using Reed Solomon error correction) from adjacent key fragments and the recovery record fragments.
  • a media injector provides a media stream to STBs, each STB being a peer in the P2P network.
  • the network may include other peers that are not STBs, for example routers, mobile telephones, web cameras and so on.
  • the STB can request missing frames from a server rather than peers in a network.
  • the invention provides the utilisation of spare bandwidth or a dedicated portion of the bandwidth to introduce redundancy of key fragments, enabling reconstruction of such fragments in the case of permanent failure. Redundancy is added on top of the existing traffic, allowing for recovery of selected portions of the streams. The amount of control traffic to recover any given key fragment will be localized in a network sub graph. This provides stronger resilience towards churn in the P2P network.

Abstract

L'invention porte sur un procédé et un appareil pour recevoir du contenu multimédia dans un réseau de communications. Un nœud dans le réseau reçoit une séquence de fragments provenant d'un flux multimédia. Le nœud reçoit également des données de fragment relatives à chaque fragment, les données de fragment comprenant un élément quelconque parmi un indicateur du fait que le fragment comprend des données clés relatives au flux multimédia et une indication de l'instant auquel un fragment suivant comprenant des données clés apparaît dans la séquence. Si le nœud détermine que d'éventuels fragments dans la séquence sont manquants, il utilise les données de fragment pour hiérarchiser les fragments manquants qui sont requis, et envoie une requête à un nœud supplémentaire demandant le fragment manquant ayant la plus haute priorité.
PCT/EP2008/052776 2008-03-07 2008-03-07 Procédé et appareil de distribution de contenu multimédia sur un réseau de communications WO2009109232A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
GB1012831.2A GB2470306B (en) 2008-03-07 2008-03-07 Method and apparatus for distributing media over a communications network
PCT/EP2008/052776 WO2009109232A1 (fr) 2008-03-07 2008-03-07 Procédé et appareil de distribution de contenu multimédia sur un réseau de communications

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2008/052776 WO2009109232A1 (fr) 2008-03-07 2008-03-07 Procédé et appareil de distribution de contenu multimédia sur un réseau de communications

Publications (1)

Publication Number Publication Date
WO2009109232A1 true WO2009109232A1 (fr) 2009-09-11

Family

ID=39739936

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2008/052776 WO2009109232A1 (fr) 2008-03-07 2008-03-07 Procédé et appareil de distribution de contenu multimédia sur un réseau de communications

Country Status (2)

Country Link
GB (1) GB2470306B (fr)
WO (1) WO2009109232A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013109094A1 (fr) * 2012-01-20 2013-07-25 한국전자통신연구원 Procédé de transmission de données multimédia ayant une unité d'accès divisée en unités de fragments multimédia dans un réseau hétérogène
WO2014058276A1 (fr) * 2012-10-11 2014-04-17 Samsung Electronics Co., Ltd. Appareil et procédé de transmission et de réception de données multimédias dans un réseau hybride
US20210266150A1 (en) * 2020-02-26 2021-08-26 Tzero Ip, Llc Secret splitting and metadata storage

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004044710A2 (fr) * 2002-11-11 2004-05-27 Supracomm, Inc. Videoconference en multidiffusion

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004044710A2 (fr) * 2002-11-11 2004-05-27 Supracomm, Inc. Videoconference en multidiffusion

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
AKAR G B ET AL: "Transport Methods in 3DTV-A Survey", IEEE TRANSACTIONS ON CIRCUITS AND SYSTEMS FOR VIDEO TECHNOLOGY, IEEE SERVICE CENTER, PISCATAWAY, NJ, US, vol. 17, no. 11, 1 November 2007 (2007-11-01), pages 1622 - 1630, XP011195152, ISSN: 1051-8215 *
WU ET AL: "Stochastic analysis of the interplay between object maintenance and churn", COMPUTER COMMUNICATIONS, ELSEVIER SCIENCE PUBLISHERS BV, AMSTERDAM, NL, vol. 31, no. 2, 18 January 2008 (2008-01-18), pages 220 - 239, XP022426917, ISSN: 0140-3664 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013109094A1 (fr) * 2012-01-20 2013-07-25 한국전자통신연구원 Procédé de transmission de données multimédia ayant une unité d'accès divisée en unités de fragments multimédia dans un réseau hétérogène
WO2014058276A1 (fr) * 2012-10-11 2014-04-17 Samsung Electronics Co., Ltd. Appareil et procédé de transmission et de réception de données multimédias dans un réseau hybride
US9888293B2 (en) 2012-10-11 2018-02-06 Samsung Electronics Co., Ltd. Apparatus and method for delivering and receiving multimedia data in hybrid network
US10469915B2 (en) 2012-10-11 2019-11-05 Samsung Electronics Co., Ltd. Apparatus and method for delivering and receiving multimedia data in hybrid network
US10469914B2 (en) 2012-10-11 2019-11-05 Samsung Electronics Co., Ltd. Apparatus and method for delivering and receiving multimedia data in hybrid network
US10477280B2 (en) 2012-10-11 2019-11-12 Samsung Electronics Co., Ltd. Apparatus and method for delivering and receiving multimedia data in hybrid network
US20210266150A1 (en) * 2020-02-26 2021-08-26 Tzero Ip, Llc Secret splitting and metadata storage

Also Published As

Publication number Publication date
GB201012831D0 (en) 2010-09-15
GB2470306B (en) 2013-06-19
GB2470306A (en) 2010-11-17

Similar Documents

Publication Publication Date Title
US10034058B2 (en) Method and apparatus for distributing video
US8776161B2 (en) Systems and methods for video processing in network edge devices
CN101316357B (zh) 一种频道切换的方法和终端
US10771821B2 (en) Overcoming lost IP packets in streaming video in IP networks
US20120140645A1 (en) Method and apparatus for distributing video
JP5791893B2 (ja) 以前の伝送データを用いた、ビデオ・コンテンツ及びサービスのブロードキャストの受信のための方法及びデバイス
US8316108B2 (en) Method and apparatus for obtaining media over a communications network
KR20120010089A (ko) Ｈｔｔｐ 기반의 멀티미디어 스트리밍 서비스의 품질 향상을 위한 방법 및 장치
KR20140002026A (ko) 파일 전달 방법들을 이용한 ｉｐ 브로드캐스트 스트리밍 서비스 배포
US20120042092A1 (en) Method for transmitting an iptv streaming service by p2p transmission, and method for receiving an iptv streaming service by p2p transmission
US20200021867A1 (en) Broadcast signal transmitting and receiving method and device
US11765444B2 (en) Streaming media data including an addressable resource index track
US8316148B2 (en) Method and apparatus for obtaining media over a communications network
KR101438737B1 (ko) 멀티플 캐시 네트워크에서의 적응적 비디오 스트리밍 시스템 및 방법
WO2009103343A1 (fr) Procédé et appareil de distribution de données multimédia sur un réseau de communication
WO2009109232A1 (fr) Procédé et appareil de distribution de contenu multimédia sur un réseau de communications
US8811478B2 (en) Data transmission method and apparatus
JP2008193500A (ja) データ送信装置及びデータ中継装置
Eberhard et al. Nextsharepc: an open-source bittorrent-based p2p client supporting svc
WO2009080113A1 (fr) Procédé et appareil de distribution de contenu multimédia dans un réseau de communications
WO2009080111A1 (fr) Procédé et appareil de distribution de contenu multimédia dans un réseau de communications
WO2009095079A1 (fr) Procédé et appareil de distribution de contenu multimédia par l'intermédiaire d'un réseau de communications
WO2009103346A1 (fr) Procédé et appareil permettant d'obtenir des données multimédia sur un réseau de communication
WO2009080116A1 (fr) Procédé et appareil de distribution de contenu multimédia dans un réseau de communications
WO2009080117A1 (fr) Procédé et appareil de distribution de contenu multimédia dans un réseau de communications

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08717523

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
ENP Entry into the national phase

Ref document number: 1012831

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20080307

WWE Wipo information: entry into national phase

Ref document number: 1012831.2

Country of ref document: GB

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08717523

Country of ref document: EP

Kind code of ref document: A1