WO2009095080A1

WO2009095080A1 - Method and apparatus for obtaining media over a communications network

Info

Publication number: WO2009095080A1
Application number: PCT/EP2008/051186
Authority: WO
Inventors: Andreas Ljunggren; Robert Skog
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2008-01-31
Filing date: 2008-01-31
Publication date: 2009-08-06
Anticipated expiration: 2010-07-31
Also published as: GB201011137D0; GB2469235B; GB2469235A

Abstract

A node and a method for use in an IPTV communications network. The node comprises a prediction logic function for determining when the node must receive data fragments relating to a plurality of IPTV channels, and a transmitter for, as a result of the determination, requesting from at least one remote node fragments for the plurality of IPTV channels such that the fragments will, when rendered, provide at least one of the IPTV channels at a reduced quality. A receiver is provided for receiving the requested fragments, along with a memory for storing the received fragments. By requesting fragments for a channel that, when rendered, provide the channel at a reduced quality, bandwidth requirements are reduced.

Description

Method and Apparatus for Obtaining Media over a Communications Network

TECHNICAL FIELD

The invention relates to the field of obtaining media over a communications network, and in particular to obtaining IPTV media data.

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 beneficial if the peer sends the latest l-frame (or other format of complete image frame) and all related 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.

In some circumstances, a user will switch between channels (referred to as "zapping") frequently. In this case, the user joins and leaves P2P networks for specific channels often. When a user leaves a channel the buffer in their STB will no longer build up fragments for that channel, and if a user returns to that channel it will take a significant amount of time to render the media for that channel, as the user's STB will have to build up buffer data once more for the channel.

This problem becomes particularly acute when a user switching between channels that each require a large amount of information to be obtained by the STB before it can be rendered by the STB's media renderer. An example of such a channel is a High Definition (HD) channel.

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 node for use in an IPTV communications network. The node comprises a prediction logic function for determining when the node must receive data fragments relating to a plurality of IPTV channels, and a transmitter for, as a result of the determination, requesting from at least one remote node fragments for the plurality of IPTV channels such that the fragments will, when rendered, provide at least one of the IPTV channels at a reduced quality. A receiver is provided for receiving the requested fragments, along with a memory for storing the received fragments. By requesting fragments for a channel that, when rendered, provide the channel at a reduced quality, bandwidth requirements are reduced. The node is optionally selected from one of a Set Top Box and a proxy node arranged to act on behalf of a Set Top Box. The node is optionally arranged to be used in a Peer to Peer IPTV communications network, in which case it is provided with P2P functionality. However, the node could also be arranged to be used in a client/srver network.

Optionally, the requested fragments are only fragments containing key frame data for at least one of the plurality of IPTV channels. In this way the amount of information received for the channel is greatly reduced, along with the picture quality.

Alternatively, the requested fragments are for a lower resolution broadcast of the same media as at least one of the plurality of IPTV channels. An example of this is where the IPTV channel is a High Definition IPTV channel, and the lower resolution broadcast is a Standard Definition IPTV channel.

The prediction logic function is optionally arranged to determine that the node must receive data fragments relating to a plurality of IPTV channels when a user is switching between channels.

Optionally, the prediction logic function is arranged to instruct the transmitter to stop requesting fragments for the plurality of IPTV channels after it is determined that the user has not switched between IPTV channels for a predetermined amount of time, and only to request fragments for the IPTV channel that the user is currently viewing. This is useful where reduced quality fragments are obtained because a user is "zapping" between channels. Once it is determined that the user is no longer zapping between channels, the node can revert to provide the normal quality channel.

As an option, the prediction logic function is arranged to determine that the node must receive data fragments relating to a plurality of IPTV channels when a user requests a Picture in Picture view showing a plurality of channels on a display device.

According to a second aspect of the invention, there is provided a method of receiving a plurality of IPTV channels at a node in a communications network. The method comprises determining when the node must receive a plurality of IPTV channels, requesting from at least one remote node fragments for the plurality of IPTV channels such that the fragments will, when rendered, provide at least one of the IPTV channels at a reduced quality, receiving the requested fragments and storing the received fragments in a buffer. By requesting fragments for a channel that, when rendered, provide the channel at a reduced quality, bandwidth requirements are reduced.

An optional way to receive fragments that, when rendered, provide at least one of the IPTV channels at a reduced quality, is to only request fragments containing key frame data.

Optionally, the method comprises determining that the node must receive data fragments relating to a plurality of IPTV channels as a result of a user switching between channels. In this case, the method optionally further comprises determining that the user has not switched between IPTV channels for a predetermined amount of time and, as a result of the determination, stopping requesting fragments for the plurality of IPTV channels and only requesting fragments for the IPTV channel that the user is currently viewing.

The method optionally comprises determining that the node must receive data fragments relating to a plurality of IPTV channels when a user requests a Picture in Picture view showing a plurality of channels on a display device.

According to a third aspect of the invention, there is provided apparatus for use in receiving media over a communications network, the apparatus comprising means for performing the method described above in the second aspect of the invention.

According to a fourth aspect of the invention, there is provided a program for controlling an apparatus to perform the method described above in the second aspect of the invention.

According to a fifth aspect of the invention, there is provided a program which, when loaded into an apparatus, causes the apparatus to become an apparatus as described above in the third aspect of the invention.

According to a sixth aspect of the invention, there is provided a program described above in either of the fourth or fifth 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 as described above in either of the fourth or fifth 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 the contents of a buffer where a user is viewing a single channel;

Figure 9 illustrates schematically the contents of a buffer where a user is switching between channels according to an embodiment of the invention;

Figure 10 illustrates schematically in a block diagram a Set Top Box according to an embodiment of the invention; and Figure 10 is a flow diagram illustrating the steps 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 I D3 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 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 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.

Figure 8 illustrates schematically a buffer in a STB. The buffer contains fragments that contain frame data. In the example of Figure 8, all of the fragments contain frame data relating to Channel X, because that is the channel that the user is currently viewing.

Turning now to Figure 9, if the user begins to switch between Channels Y and Z, the STB if arranged to obtain fragments for both Channels Y and Z such that Channels Y and Z can be viewed at a reduced quality (and therefore take up less buffer space). At a given moment, the user may be viewing Channel Y, but the STB predicts (as discussed below) that the user may wish to switch to Channel Z soon. The STB therefore stores fragments for both Channel Y and Channel Z in its buffer. Note that that buffer size is not increased, and so it is possible that fewer fragments would be stored for each of Channels Y and Z than were previously stored for Channel X. Where Channels Y and Z are High Definition (HD) channels, or any other type of channel that requires a large amount of information, this becomes problematic because the buffer may not be able to store a sufficient number of fragments to provide the user with a rendered image when the user switches channels. This may be because the buffer does not have sufficient space to store fragments containing the most recent key frame.

Furthermore, if the two channels that the user is switching between are both HD quality, then the time to render a channel to which the user switches is increased compared to a Standard Definition (SD) channel. This is because each HD channel requires a lot more information to be sent using the same bandwidth and latency constraints.

In order to address this problem, the STB obtains fragments for each channel that provide the user with sufficient information to see the content of the channel but at a reduced quality. When the STB determines that the user has settled on a channel to watch, it can stop pre-fetching fragments for channels that are not being watched and only obtain fragments for the channel that is being watched, and so the user can watch the channel at the full quality.

One way to obtain fragments that will allow the user to watch a reduced quality image is to only obtain fragments containing key frame data. Another alternative is for a media provider to provide the same channel in both HD and SD format. When the user switches to a HD channel, frames can be obtained from the SD channel until the STB determines that the user has finished switching between channels (for example, if a predetermined amount of time has lapsed). Once the STB has determined that the user has finished switching between channels, then it can revert to obtaining frames from the HD channel to provide the user with HD quality media. In this case, the STB must have some way of knowing the identity of an SD channel that is providing the same media or broadcast as an HD channel. The mechanism of providing this information may be any suitable mechanism, for example by including related channels in metadata relating to the broadcast.

One use of the invention is to allow a user to zap between channels and pre-fetch fragments relating to channel that a user is not currently viewing, but may, according to some prediction logic, switch to soon. In this way, when the user switches to a channel for which fragments have been pre-fetched and stored in the buffer, the STB will be able to start rendering that channel immediately. Another use of the invention is to allow a user to watch a picture-in-picture display. For example, the user may be watching Channel Y but wants to know what is on Channel Z. Channel Z can be displayed in a corner of the user's display equipment at a lower quality.

In more detail, and referring to Figure 10, a STB 12 is provided with prediction logic function 13 to predict user behaviour and act upon the results of the predictions. For example, if a user changes from Channel Z to Channel Y and back again to Channel Z, it may be likely that the user will return once more to Channel Y.

The STB 12 therefore uses the prediction logic function 13 to predict which channel the user will switch to next after a given amount of time, and will fetch fragments containing key frame data for the predicted channel (or channels), and for the channel currently being viewed, for a certain amount of time. The prediction logic function 13 may predict that if a user stays with a certain channel for a predetermined amount of time, the user is unlikely to switch to another channel at any time soon, and will therefore stop obtaining key frame fragments for channels that the user is not currently viewing.

The STB 12 is provided with a transmitter 14 for requesting fragments containing key frame data from other peers in the network (or from another node in a client/server network) and a receiver 15 for receiving the requested fragments. The STB 12 also has a buffer (or memory) 16 for storing the received fragments. When a user wishes to view a particular channel, fragments from the buffer are passed to a media renderer 14

(otherwise known as a video decoder) for rendering the media on the user's display device.

The STB 12 is therefore keeping selected channels that are not currently being viewed active for a certain time. If the user subsequently switches to one of the active channels, the buffer will already contain fragments for that channel and the STB 12 can immediately start rendering the media. This greatly reduces the amount of time that a user has to wait before seeing the media when switching between channels. The STB 12 selects channels to keep active either by employing prediction algorithms that predict the user's channel switching behaviour or simply by obtaining a list of channels from a user's "favourites" list.

The prediction logic function 13 ensures that the fragments obtained during zapping between channels will relate to frames of a reduced quality (e.g. only fragments containing key frame data), allowing more media data to be stored in the buffer compared to the amount of data that can be stored for a single channel viewed at full quality.

The STB 12 re-arranges the buffer memory 16 to ensure that fragments relating to more than one channel at a time can be stored. It will be appreciated that for a given memory size, the more channels for which a STB 12 obtains fragments, the fewer fragments will be stored for each channel in the buffer memory 16. This places a limit on the amount of time that a channel can be viewed for before the STB 12 must start to fetch fragments for that channel to enable a viewer to watch it. However, if a user quickly switches between channels then this will not be a problem, as the buffer may not run out of fragments for the user to view before the viewer switches to another channel. When the prediction logic function 13 determines that the end-user has settled for one channel and has stopped zapping between channels, then that channel will be "upgraded" to the quality expected by the user (for example, normal definition to HD), by obtaining all of the fragments for that channel rather than just the fragments containing key frame data. Frames for the other active channel (s) that are no longer being viewed by the user are no longer obtained. The prediction logic 13 may determine that the user has settled for one channel based on previous user behaviour, or on the user not switching channels for a predetermined length of time.

Note that in the above example, the user is described as switching between two channels, but it will be appreciated that the user may be switching between more channels.

Referring now to Figure 1 1 , a flow diagram is shown illustrating the basic steps of an embodiment of the invention. The following numbering refers to the numbering in the flow diagram:

S1. The prediction logic function in the STB determines that the STB requires more than one channel. As discussed above, this may be because the user has started zapping between channels and it is desirable to render the channels more quickly, or because the user requires a Picture in Picture (PiP) image to be rendered. If the user is zapping between channels, then the prediction logic must select which channels are required.

S2. The STB requests fragments for the selected channels. In the case where the user is zapping between channels, the STB may request fragments such that all of the requested channels will be displayed at a reduced quality. In the case where the user requires PiP, the STB may only request reduced quality fragments for the channel that is to be rendered "in the picture"

53. The STB receives fragments for the requested channels and stores them in the buffer.

54. Fragments for the channel that the user is viewing are passed to a media renderer for the user to view at a reduced quality. If the user switches channel to a channel for which fragments are already stored in the buffer, these can be passed to the media renderer with very little delay. If the user is using PiP then the fragments for both the "main" channel and the PiP channel are passed to the media renderer.

The invention provides prediction logic in a STB for use in an IPTV P2P network that is activated if a user begins to switch channels. The prediction logic re-arranges the buffer in the STB so that fragments for more than one channel can be handled, and each channel stored in the buffer is of a reduced quality (and hence requires less bandwidth and memory) whilst the user is switching between the channels. Even if fragments for a channel are not sent to the STB media renderer for rendering, the STB will still fetch fragments belonging to that channel as long as it is likely that the user will switch to that channel, or the user is viewing that channel as a "picture-in-picture".

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. For example, the above description refers to pre-fetching fragments for channels that are not currently being viewed by the user when it is expected that a user might switch to that channel, and for PiP applications. However, other applications may also take advantage of the invention. For example, reduced quality channels could be rendered in dynamic menus, for example in showing a viewer a selection of channels on a screen at the same time, and allowing the viewer to choose a channel from the selection.

Claims

CLAIMS:

1. A node for use in an IPTV communications network, the node comprising: a prediction logic function for determining when the node must receive data fragments relating to a plurality of IPTV channels; a transmitter for, as a result of the determination, requesting from at least one remote node fragments for the plurality of IPTV channels such that the fragments will, when rendered, provide at least one of the IPTV channels at a reduced quality; a receiver for receiving the requested fragments; and a memory for storing the received fragments.

2. The node according to claim 1 , wherein the node is selected from one of a Set Top Box and a proxy node arranged to act on behalf of a Set Top Box.

3. The node according to claim 1 or 2, wherein the node is arranged to be used in a Peer to Peer IPTV communications network.

4. The node according to claim 1 , 2 or 3, wherein the requested fragments are only fragments containing key frame data for at least one of the plurality of IPTV channels.

5. The node according to claim 1 , 2 or 3, wherein the requested fragments are for a lower resolution broadcast of the same media as at least one of the plurality of IPTV channels.

6. The node according to claim 5, wherein the IPTV channel is a High Definition IPTV channel, and the lower resolution broadcast is a Standard Definition IPTV channel.

7. The node according to any one of claims 1 to 6, wherein the prediction logic function is arranged to determine that the node must receive data fragments relating to a plurality of IPTV channels when a user is switching between channels.

8. The node according to any one of claims 1 to 7, wherein the prediction logic function is arranged to instruct the transmitter to stop requesting fragments for the plurality of IPTV channels after it is determined that the user has not switched between IPTV channels for a predetermined amount of time, and only to request fragments for the IPTV channel that the user is currently viewing.

9. The node according to claim 1 , 2 or 3, wherein the prediction logic function is arranged to determine that the node must receive data fragments relating to a plurality of IPTV channels when a user requests a Picture in Picture view showing a plurality of channels on a display device.

10. A method of receiving a plurality of IPTV channels at a node in a communications network, the method comprising: determining when the node must receive a plurality of IPTV channels; requesting from at least one remote node fragments for the plurality of IPTV channels such that the fragments will, when rendered, provide at least one of the IPTV channels at a reduced quality; receiving the requested fragments; and storing the received fragments in a buffer.

1 1. The method according to claim 10, comprising requesting only fragments containing key frame data for at least one of the plurality of IPTV channels to be rendered at a reduced quality.

12. The method according to claim 10 or 1 1 , comprising determining that the node must receive data fragments relating to a plurality of IPTV channels as a result of a user switching between channels.

13. The method according to claim 12, further comprising: determining that the user has not switched between IPTV channels for a predetermined amount of time; and as a result of the determination, stopping requesting fragments for the plurality of IPTV channels and only requesting fragments for the IPTV channel that the user is currently viewing.

14. The method according to claim 10 or 11 , comprising determining that the node must receive data fragments relating to a plurality of IPTV channels when a user requests a Picture in Picture view showing a plurality of channels on a display device.

15. An apparatus for use in receiving media over a communications network, the apparatus comprising means for performing the method as claimed in any one of claims 10 to 14.

16. A program for controlling an apparatus to perform a method as claimed in any one of claims 10 to 14.

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

18. A program as claimed in claim 16 or 17, carried on a carrier medium.

19. A program as claimed in claim 18, wherein the carrier medium is a storage medium.

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