WO2009080113A1

WO2009080113A1 - Method and apparatus for distributing media over a communications network

Info

Publication number: WO2009080113A1
Application number: PCT/EP2007/064446
Authority: WO
Inventors: Andreas Ljunggren; Robert Skog
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2007-12-21
Filing date: 2007-12-21
Publication date: 2009-07-02
Anticipated expiration: 2010-06-21
Also published as: GB2468068B; GB201008838D0; GB2468068A

Abstract

A method and apparatus for distributing media content in a communications network. At a first node in the network, fragments from a media stream are received and stored in a memory. At least one of the fragments comprises a key data indicator indicating that the fragment comprises key data. In the event that the first node receives a request from a second node in the network for the media stream, it sends to the second node the fragment comprising the key data indicator.

Description

Method and Apparatus for Distributing Media over a Communications Network

TECHNICAL FIELD

The invention relates to the field of distributing media over a communications network.

BACKGROUND

TV services broadcast over an IP network are referred to as 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).

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.

Figure 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. In order to mitigate this problem, content can be multicast to reduce bandwidth demands for broadcast TV distribution. Furthermore, Video on Demand (VoD) services can be handled by VoD cache servers located close to the end-user. However, such caches require additional investment, and many routers would need to be replaced, as existing routers may not support IPTV multicasts.

It is known to distribute an IPTV service using a Peer to Peer (P2P) network, as illustrated in Figure 2. Each STB is a peer in the network. An 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. When generating a P-frame, the preceding frame is reconstructed and altered according to incremental extrapolation information. B-frame are similar to P-frames, except that B-frames interpolate data contained in the following frame as well as the preceding frame. As a result, B-frames usually provide more compression than P-frames. Typically, 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.

Since B and P frames depend on adjacent frames it is necessary that when the STB receives a new channel, it receives a full l-frame before the new channel can be shown. The average time for switching between channels therefore depends on the length of time between l-frames. Typically, for MPEG-2 IPTV content, the length of time is around 0.5 seconds. For MPEG-4 part 10 IPTV content, 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. In order to facilitate handling of the media stream, the media stream is sent in "fragments". Fragments are discrete portions of the media stream containing both the payload data and the metadata.

In order to show a channel quickly when a STB connects to a peer, it would be useful if the peer could send the fragments containing key data that is critical for showing the media stream, and related fragments in order to allow the STB to decode the media stream as quickly as possibly. Key data includes not only critical payload such as I- frames, but also metadata such as encryption information. A buffer containing fragments is illustrated in figure 3. A fragment may contain metadata about the media stream, or payload data from the media stream itself. A problem is that it is difficult for a peer to identify which fragments contain key data and which do not. A simple solution to this is for the peer to send all of the information in its buffer. However, the receiving STB may receive many fragments that cannot be used until the next fragment containing key data arrives in the sequence. This leads to delays in the STB showing the media stream, and can be detrimental to the end-user's experience.

SUMMARY

The inventors have realised the problems associated with the prior art and devised an apparatus and method to mitigate the problems and reduce the time it takes for a peer to receive the latest key frame from another peer in the network.

According to a first aspect of the invention, there is provided a method of distributing media content in a communications network. At a first node in the network, fragments from a media stream are received and stored in a memory. At least one of the fragments comprises a key data indicator indicating that the fragment comprises key data. In the event that the first node receives a request from a second node in the network for the media stream, it sends to the second node the fragment comprising the key data indicator. In this way, the second node receives only those fragments necessary to start showing the media stream, and so can show the media stream more quickly than if it received all of the fragments stored in the first node's memory. Furthermore, by only sending the necessary fragments, signalling is reduced.

As an option, the method further comprises sending to the second node fragments related to the fragment comprising the key data indicator. Examples of such fragments include related P- and B-frames in the case that the fragment containing key data contains an l-frame.

Optionally, the communications network is a Peer to Peer communications network and the first and second nodes are peer nodes.

As an option, the method further comprises, prior to receiving fragments at the node, at a media injector adding a key data indicator to each fragment that comprises key data. In this way the media injector controls which fragments are marked as containing key data.

Key data optionally comprises complete image data for a single image in the media stream. The media stream is optionally an MPEG media stream and a key data comprises an l-frame. However, key data need not relate to the payload data. Other examples of key data include data selected from any of lcecast with ID3 tagging, Ogg- tagging, x.264 B frames, header information, Closed Caption data, and Encryption data

According to a second aspect of the invention, there is provided a media injector node for distributing media content in a communications network. The media injector node comprises means for receiving a media stream. A processor is provided for partitioning the media stream into fragments and adding a key data indicator to each fragment of the media stream that comprises key data. A transmitter is also provided for sending the media stream fragments to at least one node disposed in the communications network.

The media stream is optionally selected from one of a real time transmission and a server comprising a database of media.

According to a third aspect of the invention, there is provided a node for use in a communications network. The node comprises a receiver for receiving fragments from a media stream, at least one of the fragments comprising a key data indicator indicating that the fragment comprises key data. The node further comprises a storage device for storing the media fragments, and means for receiving a request for the media stream from a second node in the network. A transmitter is provided for sending to the second node the fragment comprising the key data indicator. In this way, only fragments necessary to the second node are sent. The node is optionally a Set Top Box.

According to a fourth aspect of the invention, there is provided apparatus for use in distributing media over a communications network, the apparatus comprising means for performing the method as described in the first aspect of the invention. According to a fifth aspect of the invention, there is provided a program for controlling an apparatus to perform the method as described in the first aspect of the invention.

According to a sixth aspect of the invention, there is provided a program which, when loaded into an apparatus, causes the apparatus to become an apparatus according to the fifth aspect of the invention.

According to a seventh aspect of the invention, there is provided 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.

According to an eighth aspect of the invention, there is provided a storage medium containing a program according to any one of the fifth or sixth aspects of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

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 in a block diagram a media injector and a P2P network according to an embodiment of the invention;

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; and

Figure 11 illustrates schematically in a block diagram a peer node according to an embodiment of the invention

DETAILED DESCRIPTION

The following description sets forth specific details, such as particular embodiments, procedures, techniques, etc. for purposes of explanation and not limitation. In some instances, detailed descriptions of well known methods, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Moreover, individual blocks are shown in some of the drawings. It will be appreciated that the functions of those blocks may be implemented using individual hardware circuits, using software programs and data, in conjunction with a suitably programmed digital microprocessor or general purpose computer, using application specific integrated circuitry, and/or using one or more digital signal processors.

Throughout this specification, reference is made to key frames. An example of a key frame is an l-frame in the MPEG format. However, it will be appreciated by persons of skill in the art that the invention applies to any key data for the media stream. Examples of data that may be stored in a key frame include any of:

• lcecast with ID3 tagging • Ogg-tagging

• MPEG l-frames

• Possible B frames in x.264

• Making sure that the header survives in MJPEG

• Header of RTP (if RTP runs on top of P2P) • Closed Caption subtitles

• Encryption information 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. This is illustrated in Figure 4, which is a schematic representation of a simple IPTV P2P network 1. The network 1 includes an IPTV server 6 and two STBs STB1 and STB2. Each STB includes a P2P network interface 2, 3 to which is connected a video decoder 9, 1 1. In this example, STB1 receives the IPTV media stream from both STB2 and the IPTV Server 6, which injects either streaming content 4 or content from a database 7 using a P2P media injector 8. Note that other network nodes (in addition to STBs) may be peers in the network.

Figure 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, she 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. The 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. It is advantageous for all peers in the P2P network to send each other "keep alive" messages, as illustrated in Figure 6, to ensure that each STB is included in the list of peers and can both send and receive IPTV media streams.

Note that the term "IPTV media stream" is used herein to refer to any kind of media 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. There is some latency in the P2P network, caused by buffers in each STB and the time it takes to establish communication between peers. The term "media stream" need not necessarily refer to the media data injected into the network by a media injector, but can also be used to refer to media data received from other peers in a P2P network.

Referring to Figure 8, when a media injector 8 injects a media stream into a P2P IPTV network 12 for viewing by P2P clients 13 such as STBs, the media injector 8 constructs fragments to be sent out in the P2P-network 12. The fragments 14 are illustrated schematically. It can be seen that fragment 19 includes key data, and so an indicator 22 is used to tag frame 19 to indicate that this fragment contains key data.

When a STB in a P2P IPTV network has frames relating to channel X stored in its buffer, and another peer in the network requests frames for channel X, the STB sends the fragments in its buffer that are tagged with a key data indicator to the requesting peer, along with other related fragments such as, in the case of an MPEG media stream, an l-frame and related P- and B-frames. This allows the requesting peer to start showing the channel to the user as soon as possible. The request from the other peer may specify that only certain fragments containing data of a certain type, for example, fragments containing l-frames, are returned.

Referring to Figure 9, there is shown a flow diagram illustrating the basic steps of the invention. The following numbering refers to the numbering in Figure 9:

S1. The media injector tags analyses a media stream that it is to send out, and tags any fragments of the media stream that contain key data (for example, l-frames in the case of an MPEG-2 media stream); S2. The media injector sends the fragments, including the tagged fragments, into the P2P network;

S3. A peer node that wishes to receive 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;

54. When a second peer node requests the channel from the peer node, it sends a request to the peer node for the channel;

55. The peer node sends to the second peer node the earliest fragment containing a key data indicator and all related fragments, allowing the second peer node to decode and show the channel to the user of the second peer node.

Referring to Figure 10, there is illustrated schematically a media injector. 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 source may be via a receiver or may be co-located with the media injector. The media injector 23 further comprises a processor 25 for analysing the media stream and tagging fragments containing key data with key data indicators. The media injector 23 further comprises a transmitter for sending the media stream fragments into the P2P network.

Referring to Figure 11 , there is illustrated a STB 13. The STB 13 comprises a receiver 27 for receiving a media stream and a memory 28 for storing the media stream in a buffer. The STB 13 further comprises a processor 29 for determining which fragments of the media stream stored in the memory 28 comprise a key data indicator, and a transmitter 30

The above description describes a scenario in which a media injector provides a media stream to STBs, each STB being a peer in the P2P network. It will be appreciated that the network may include other peers that are not STBs, for example routers, mobile telephones, web cameras and so on.

Furthermore, the above description describes the invention in the context of a P2P network, although it will be appreciated by those of skill in the art that it may equally apply to a client-server based network as illustrated in Figure 1. In this instance, the STB can request missing frames from a server rather than peers in a network. Similarly, the invention could be applied in a Store and Forward communications network.

Although various embodiments have been shown and described in detail, the claims are not limited to any particular embodiment or example. None of the above description should be read as implying that any particular element, step, or function is essential such that it must be included in the claims' scope. The scope of protection is defined by the claims.

Claims

CLAIMS:

1. A method of distributing media content in a communications network, the method comprising: at a first node in the network, receiving fragments from a media stream, at least one of the fragments comprising a key data indicator indicating that the fragment comprises key data; storing the media fragments in a memory; receiving a request from a second node in the network for the media stream; sending to the second node the fragment comprising the key data indicator.

2. The method according to claim 1 , further comprising sending to the second node fragments related to the fragment comprising the key data indicator.

3. The method according to claim 1 or 2, wherein the communications network is a Peer to Peer communications network and the first and second nodes are peer nodes.

4. The method according to claim 1 , 2 or 3, further comprising, prior to receiving fragments at the node, at a media injector adding a key data indicator to each fragment that comprises key data.

5. The method according to any one of claims 1 to 4, wherein key data comprises complete image data for a single image in the media stream.

6. The method according to any one of claims 1 to 5, wherein the media stream is an MPEG media stream and a key data comprises an l-frame.

7. The method according to any one of claims 1 to 6, wherein key data comprises data selected from any of: lcecast with ID3 tagging;

Ogg-tagging; x.264 B frames; header information; Closed Caption data; and Encryption data.

8. A media injector node for distributing media content in a communications network, the node comprising: means for receiving a media stream; a processor for partitioning the media stream into fragments and adding a key data indicator to each fragment of the media stream that comprises key data; and a transmitter for sending the media stream fragments to at least one node disposed in the communications network.

9. The media injector node according to claim 8, wherein the media stream is selected from one of a real time transmission and a server comprising a database of media.

10. A node for use in a communications network, the node comprising: a receiver for receiving fragments from a media stream, at least one of the fragments comprising a key data indicator indicating that the fragment comprises key data; a storage device for storing the media fragments; means for receiving a request for the media stream from a second node in the network; a transmitter for sending to the second node the fragment comprising the key data indicator.

1 1. The node according to claim 10, wherein the node is a Set Top Box.

12. An apparatus for use in distributing media over a communications network, the apparatus comprising means for performing the method as claimed in any one of claims 1 to 7.

13. A program for controlling an apparatus to perform a method as claimed in any one of claims 1 to 7.

14. A program which, when loaded into an apparatus, causes the apparatus to become an apparatus as claimed in claim 12.

15. A program as claimed in claim 13 or 14, carried on a carrier medium.

16. A program as claimed in claim 14, wherein the carrier medium is a storage medium.

17. A storage medium containing a program as claimed in any one of claims 13 to 16.