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, and in particular to the field of distribution of IPTV using 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 latest l-frame and all subsequent frames in order to allow the

STB to decode the media stream as quickly as possibly. Unfortunately this is not practical, as the media stream is sent in fragments. 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. In Figure 3 the P2P logic is writing fragment number 21 into the buffer and fragment number 17 is sent to the video decoder.

Other 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. The output to the video decoder is fixed in relative to the start of the IPTV transmission, and the fragments must be sent in sequence. For example, after fragment number 17 has been sent to a video decoder, fragment number 18 must be sent. A problem occurs if fragments are missing from the buffer of a peer, and the peer must decide which fragments must be fetched to minimize any disruption to the end- user caused by missing fragments.

SUMMARY

The inventors have realised the problems associated with the prior art and devised an apparatus and method to mitigate the problems described above. According to a first aspect of the invention, there is provided a method of receiving media content in a communications network. A node in the network receives a sequence of fragments from a media stream. The node also receives fragment data relating to each fragment, the fragment data comprising any of an indicator that the fragment comprises key data relating to the media stream and an indication of when a next fragment comprising key data appears in the sequence. If the node determines that any fragments in the sequence are missing, it uses the fragment data to prioritize which missing fragments are required, and sends a request to a further node requesting the missing fragment having the highest priority.

Optionally, the method further comprises storing the fragments and the fragment data 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 the fragment is not useable or required, then there is no need to store it.

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. Optionally, the fragment data is added to each fragment at a media injector.

As an alternative option, 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. In the optional case where the media stream is an MPEG media stream, the key data may comprise an l-frame. However, 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.

The node is optionally a Set Top Box. In an optional embodiment of the invention, the communications network is a peer to peer communications network, and each node is a peer node.

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 a receiver for receiving a media stream, and a processor for partitioning the media stream into a sequence of fragments. The processor adds to each fragment metadata selected from any of an indicator that the fragment comprises key data relating to the media stream and in indication of when a next fragment comprising key data appears in the sequence. The media injector node further comprises a transmitter for sending the media stream fragments to at least one node located in the communications network.

According to a third aspect of the invention, there is provided a node for use in an communications network. The node comprises a receiver for receiving a sequence of fragments from a media stream, and a further receiver for receiving fragment data relating to each fragment, the fragment data comprising any of an indicator that the fragment comprises key data relating to the media stream and an indication of when a

next fragment comprising key data appears in the sequence. A processor is provided for determining if any fragments in the sequence are missing, and if it is determined that fragments in the sequence are missing, prioritizing the missing fragments on the basis of the fragment data. The node is also provided with a transmitter for transmitting a request to a further node requesting the missing fragment having the highest priority.

The node is optionally a Set Top Box.

As an option, the node further comprises means for analysing the fragments to determine if the fragments contain key data relating to the media stream, and for generating fragment data comprising any of an indicator that the fragment comprises key data relating to the media stream and an indication of when a next fragment comprising key data appears in the sequence. In this case the node further comprises a transmitter for sending the fragment data to a further node. This is advantageous in that the node can determine which fragments contain key data and inform other nodes of this.

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 a seventh 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 I PTV 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 illustrates schematically in a block diagram a memory buffer for a peer in the network;

Figure 10 is a flow diagram illustrating the steps according to an embodiment of the invention;

Figure 11 illustrates schematically in a block diagram a media injector according to an embodiment of the invention; and

Figure 12 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 fragments containing key data. An example of key data is an l-frames 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 key data 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

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. This is illustrated in Figure 4, which 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. 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 7, 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 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.

Referring to Figure 8, when a Media injector 8 construct a fragment to be sent out in the P2P-network 12, each fragment of the data is tagged with an indication 22 if the fragment payload includes key data such as an l-frame. If the fragment does not include key data, then it is tagged with an indication of how many fragments will be sent before the next fragment containing key data is due. In the example of Figure 8, fragment 15 does not include key data, but is tagged with an indicator of "1", because the next fragment (fragment 16) contains key data. Fragment 17 is tagged with an indicator of "2", because the next fragment containing key data will appear in two fragment's time. Fragment 18 is tagged with an indicator of "1", because the next fragment in the sequence contains key data, and fragment 19 contains an indicator indicating that it contains key data.

Whilst the tagging may be performed by the Media injector 8, as described above, it is possible for the tagging to be performed at any suitable node in the network. For example, tagging may be performed by a STB in order to indicate to other STBs that it is aware of future fragments containing key data. If the tagging is performed by the Media injector 8, it can be sent directly in the metadata included with the media stream,. If the tagging is performed by a STB, it can be sent in metadata between STBs.

Referring to Figure 9, a buffer in a peer node such as an STB stores the received fragments. Fragment number 15 is sent to the STB's video decoder, to allow the user to view the channel. Fragment numbers 18and 19 are missing from the buffer. A P2P logic function in the STB knows that fragment number 18 does not contain key data, but knows from the indicator "2" in fragment number 17 that fragment number 19 does contain key data. Fragments containing key data such as l-frames are far more important to the overall image quality than fragments that do not contain key data, and so the P2P logic function decides to prioritize a request for fragment number 19 instead of fragment number 18.

The P2P logic in each peer is able to put more effort into obtaining those fragments that improve the experience of the end-user. Other non-key fragments will only give small glitches on the screen, whereas a missing fragment containing, for example, an I- frame, would invalidate subsequent fragments (such as those containing P and B

frames) until the next key data fragment falls in the sequence. As stated above, fragments containing key data need not only contain key payload data such as an I- frame. Key data may also be, for example, encryption data. If a missing fragment contains a rekeying encryption fragment, it would take a long time to recover this missing fragment without using the method of the invention, and so be detrimental to the user's experience.

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

51. The media injector analyses a media stream that it is to send out, and tags any fragments of the media stream that contain key data (e.g. l-frames in the case of an MPEG-2 media stream), and tags non-key data fragments with an indication of when in the sequence of fragments the next fragment containing key data is due;

52. The media injector sends the fragments, including the tagged fragments the P2P network;

53. A node that wishes to receive the channel fo 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. The node determines whether any fragments, which are shortly due to be sent to the video decoder for rendering, are missing;

55. The missing fragments are prioritized on the bases of the tagged information;

56. The node sends a request for the missing fragments, requesting the missing fragments having the highest priority first.

Referring to Figure 1 1 , 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 media injector 23 further comprises a processor 25 for analysing the media stream and tagging fragments containing key frames with key frame indicators. The processor also tags fragments that do not contain key data with an indication of when the next fragment

containing key data will be in the sequence. The media injector 23 further comprises a transmitter for sending the media stream fragments into the P2P network.

Referring to Figure 12, 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 frame indicator. The processor 29 is also used to analyze each fragment for an indication of when the next fragment containing key data will fall in the sequence. The processor 29 is also used to prioritize requests for missing fragments as a result of the indicators contained in the fragments. The STB 13 further comprises 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.

One of the advantages of the invention is that when a peer node sees that some it has some missing fragments that are close to "play out", it will only try to fetch those fragments that contains key data. These fragments will give better picture compared to fragments that do not contain key data, as fragments that do not contain key data can be lost without too much degradation of quality.

The invention can also be used for secondary channels in a "picture in picture" scenario. Where, for example, a secondary channel is being shown overlaid on a primary channel, the peer node can retrieve only those fragments that contain key data for the secondary channel. This will have the effect that the secondary channel is shown in "freeze" frame" mode, appearing to the user effectively as a series of still images. This allows the user to see the secondary channel but does not require the amount of bandwidth that would be required by receiving all of the fragments for both the primary and secondary channels. The key frame indicator and indicator of the next fragment containing key data are used by the peer to request those fragments that it requires.

The above description describes the invention in 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.

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.