HK1067267A - Method and system for delivering media selections through a network - Google Patents

Description

Method and system for delivering media selections over a network

Technical Field

The present invention relates to a network multimedia delivery system. And more particularly to a media delivery system for delivering media selections to multiple media clients over a hybrid multipoint/unicast network.

Background

In a true video-on-demand (VOD) system, the user is allowed to watch a video program at any time and perform any VCR-like interactive functions such as fast forward/fast rewind, skip forward/backward, slow and pause. This is easily achieved by providing a dedicated channel for each user. But this method is expensive, inefficient and not scalable. Thus, multicast network delivery is considered as one of the solutions for large-scale VOD systems to reduce cost and improve scalability. A multicast media stream can be shared by a large number of users. Unfortunately, it is difficult to implement interactive functions for multicast media streams. In recent years, it has become a challenging and popular issue to satisfy a user's request without affecting other users in the same multicast group.

Many studies have attempted to solve this problem. One of the studies is to provide limited VCR functionality depending on the buffer size of the set-top box. Interactive functions such as fast forward can only be implemented using frames already stored in the buffer. A large amount of buffer is required for better VCR performance. Moreover, this technique cannot serve certain interactive functions, such as skip forward/skip backward, which involves changing the buffer contents. In another study, it was proposed that user interaction could be handled by creating a unicast media stream. This new stream may be retained until the end of the video. This means that all users can eventually save a single stream instead of sharing the same multicast stream. Thus, scalability is reduced or many interactive request requests may be blocked. These problems limit the usefulness of such systems, particularly in situations where such systems are implemented in cities with millions of users.

It is therefore an object of the present invention to address at least some of the problems associated with the prior art. At a minimum, it is an object of the present invention to provide the public with a useful choice.

Disclosure of Invention

Accordingly, the present invention provides a method for delivering media to a plurality of media clients, said clients having a buffer for caching media in a selected media stream within a streaming interval and processing capabilities for playing media in a multicast media stream over a network, comprising the steps of:

-generating a plurality of multicast media streams, wherein each multicast media stream is repeated within a regular stream interval;

-joining the media client to the selected multicast media stream in response to a selection request from the media client;

-caching the selected multicast media stream in at least one interactive server,

such that interaction requests and/or errors in playing the media within the media client are handled by the interaction server or media server.

Another aspect of the present invention provides a system for delivering media selections to a plurality of media clients, the clients having a buffer for caching media within a selected media stream within a streaming interval and processing capabilities for playing media within a multicast media stream over a network, comprising:

-at least one media server for generating a plurality of multicast media streams, wherein each multicast media stream is repeated at regular stream intervals, joining a media client to a selected multicast media stream in response to a selection request from said media client; and

-at least one interactive server for caching the selected multicast media stream,

such that interaction requests and/or errors in playing media within the media client are handled by the interaction server or the media server.

Drawings

Preferred embodiments of the present invention will now be explained by way of example with reference to the accompanying drawings; wherein:

fig. 1 shows the overall architecture of the media delivery system of the present invention.

Figure 2 shows the scheduling of media streams of a particular preferred embodiment generated by an interactive server.

Fig. 3 shows how the media client merges back to the multicast media stream after the interaction is performed.

Fig. 4 shows a pause operation, while fig. 5 shows a corresponding change in the buffer of the media client during the pause operation.

Fig. 6 shows the change of the buffer of the media client during a slow motion operation.

Fig. 7 shows how to decide the appropriate multicast media stream after a fast forward operation.

Fig. 8 shows the difference between the play points of the fast forward operation and the normal play operation.

Fig. 9 shows the difference between the playback points of the fast-reverse operation and the normal playback operation.

Fig. 10 shows how to decide the appropriate multicast media stream after the forward jump operation.

Detailed Description

The invention will now be described in the following paragraphs by way of example with reference to the accompanying drawings. List 1 is a list of components, which are convenient to refer to the reference numerals.

Although the media or media selection to be delivered is described below as video, it is understood that other forms of media may be delivered in the present invention instead of video, such as audio or a combination thereof.

1. System architecture

1.2 general description

The overall system architecture of the media delivery system (10) of the present invention is shown in fig. 1. This system comprises four main components:

a) at least one media server. The media server may be a stand-alone server or may be a member of a video server cluster VSC (12) as shown in fig. 1;

b) a plurality of media clients as client workstations CS (14);

c) a network (16) representable as a Multicast Backbone Network (MBN) (20) and a plurality of Local Distribution Networks (LDNs) (22); and

d) at least one interaction server (18) being a distributed interaction server DIS.

Note that the MBN (20) may use any arbitrary topology that supports multicast network communication protocols. The ring architecture shown in fig. 1 is used for simplicity, but should not be construed as requiring such a token ring network for the present invention.

1.2 video Server Cluster VSC (12)

The role of the VSC (12) is to generate multicast media streams for the entire system. Each VSC (12) comprises at least 1 and preferably 5 to 15 media servers. The number of media servers in the cluster can be changed as necessary.

Preferably, each media server stores partial video content in a simple striped format with parity bits for forward error correction, similar to RAID 5. This allows for simple error recovery if the CS (14) misses a video block from the group of parity bits. Likewise, even when some media servers fail, the entire VSC (12) can still be operational, achieving some degree of fault tolerance. Other known banding practices may be employed in the present invention.

The video blocks sent by the VSC (12) are preferably randomly interleaved to minimize the impact of burst block errors and improve system security. Since the blocks are most likely stopped in bursts by interleaving packets sent by the VSC (12), the lost packets are more evenly spread. Thus, a simple parity bit approach can recover most, if not all, of the lost packets.

In addition, block interleaving discourages an eavesdropper from capturing video blocks for viewing. A pseudo-random number sequence may be used to generate the random interleaving: the sequence of generated keys is transmitted to the CS (14) during channel establishment using a public key encryption algorithm. As a result, the CS (14) can record the video sequence from the regenerated pseudo-random number sequence.

To provide interactive functionality to the user, the multicast media stream starts at the VSC (14), for example at regular streaming intervals of every 30 to 60 seconds, to serve multiple media streams to the majority of customers who are not implementing any interactive functionality. A media stream scheduling at 30 second stream intervals is shown in fig. 2.

The flow interval may be selected based on the size and performance of the system (10). However, the flow interval is preferably set to about 30-60 seconds, so that the average start time may be about 15-30 seconds, which is acceptable. Although a large number of multicast media streams are required, it is desirable to do so because it provides a higher quality of service to the user and reduces the buffer requirements of the client for the full interactive functionality. In addition, the more multicast media streams, the number and storage time of unicast media streams required to provide interactivity and integration may be reduced.

1.3 client workstation CS (14)

Each CS (14) has a buffer that can hold media contained within the multicast media stream for a streaming interval of a video block. For a stream interval equal to 30 seconds and MPEG-2 video (2 to 4Mb/s), this amounts to 8-15 MB. Error correction with simple parity bits, such as 1 bit of 10 bits as parity bits, requires a buffer of about 15 × 10/9, i.e. 16.7 MB. Therefore, 32MB of buffer per CS is sufficient.

In addition to storage requirements, each CS (14) must have a network connection so that the media stream can be delivered to the CS (14). This network connection is preferably a broadband network connection which allows 1.5 to 2 times the transmission speed of MPEG-2. Furthermore, each CS (14) must have sufficient processing power to play the media in the multicast media stream. A low-order product equipped with the Pentium 266 and a hardware or software MPEG-2 decoder was found to be satisfactory.

1.4 network (16)

1.4.1 multicast backbone network MBN (20)

There is no specific requirement for the underlying network (16) except that it should be able to supply sufficient bandwidth for delivery of the multicast media stream to the CS (14). In real-life applications, the MBN (20) may be responsible for handling thousands of multicast media streams for distribution to the CS (14) across the LDN (22).

Preferably, the MBN (20) is connected to the LDN (22) via a high-speed router. Each router must be capable of performing the desired multicast network routing protocols, such as PIM, MOSPF, DVMRP, etc. Ideally, the MBN (20) must be fault tolerant and rerouted to an alternate path when needed. Current proposals for IP over DWDM networks may be used as they appear to provide this desirable feature. Generally, the higher the bandwidth of the backbone network, the more media streams it can provide to the user.

1.4.2 local distribution network LDN (22)

The LDN (22) carries multicast media streams to each CS (14) and prunes the streams therein whenever they are not needed. A simple tree network may be sufficient for this purpose.

1.5 distributed interactive server DIS (18)

The DIS (18) is primarily responsible for error recovery by caching the multicast media stream and for generating unicast content in response to interactive requests from the CS (14). While these functions may be provided by the VSC (12), they are preferably implemented by the DIS (18) to reduce the load on the overall server and network.

Since each multicast media stream provided by the VSC is viewable by a virtually unlimited number of users, whereas unicast media streams for interactive functions are not, a distributed approach is chosen that makes the system more scalable.

One of the DIS (18) functions is to handle errors while playing media in the CS (14), including transmitting any video blocks that the CS (14) has not received. When the CS (14) fails to reconstruct the lost video block, it sends a request to the DIS for the lost video block.

Packet delay may be minimized as DIS (18) is distributed closer to CS (14), and this improves response time and retransmission success rate of the interworking function. The multicast media stream provides most of the traffic flow. It is found in related studies that less than 2% of users perform interactive functions at the same time. Therefore, DIS (18) of lower-order products is sufficient for the media delivery system (10).

2. Service provision

The architecture of the media delivery system (10) may provide three different classes of service a, B, and C unified within a single framework.

The class a service is similar to the current cable TV service. The user can watch any broadcast channel in a non-interactive manner. To support tier a services, the media delivery system (10) must be able to support hundreds of non-interactive multicast network channels. This is provided by standard IP multicast network channels over a broadband infrastructure (and in many other architectures as well). The key issue to be solved is the handling of erroneous retransmissions. In this context, class a services are provided by a VSC (12) using multicast network IP flows and are distributed to a CS (14) via a network (16). Error recovery and retransmission may be handled by DIS (18) at each LDN to improve error retransmission.

The goal of class B services is to support a limited number of media (e.g., hundreds of hours of MPEG-2 programming) in a fully interactive manner with high user scalability. This is provided by the hybrid multicast network-unicast media streaming technique of the present invention, which may require a moderate amount of system resources to support a large number of users. This service is particularly desirable in cities where millions of users may view certain media (such as movies, sports, or music concerts) with little or no restriction. In the media delivery system (10) of the present invention, hundreds of hours of video content (MPEG-2) can be supported efficiently at the cost of current interactive multicast network distribution.

The level B service is the most complex and will be explained in the following paragraphs.

The goal of class C services is to provide unlimited content to a fixed number of users. This service concept is similar to many existing services that assign a unique unicast media stream to each viewer. Unfortunately, this service is not scalable, since its cost per user of service provision is fixed and also quite high in terms of the current state of the art. However, when this service is bundled with the previous two DINA services, only a small percentage of viewers may request the service, and thus the overall system cost may be significantly reduced.

The class C service is handled in the following manner. When a CS (14) requests class C service, a dedicated interactive request is made by the CS (14) for dedicated media. The local DIS (18) is first checked for the presence of a copy of the private media stored in the local cache of the DIS (18). If so, the local DIS (18) will service the request directly by initiating a unicast media stream. If not, the user administrator will initiate a request to the VSC (12). The VSC (12) will distribute its content to the CS (14) requesting the service via a unicast media stream, either directly by the VSC (12) or indirectly to the DIS (18). Interactivity is handled by either the VSC (12) or the DIS (18). The caching is implemented on the local DIS (18) with the goal of reducing the number of requests to VSCs and the required backbone bandwidth depending on usage statistics of the medium.

3. Interactive function

The interactive functions of the CS (14), including fast forward, fast reverse, forward skip and backward skip may be performed with dedicated unicast media streams from the DIS. Such interactive functions are provided within the class B service.

Generally, when the CS (14) requests an interworking function, the CS (14) first leaves the multicast group to which it currently belongs, and then requests a unicast media stream to handle the interworking function. When the CS (14) completes the interactive function, it first uses the unicast media stream for normal play, but uses a higher pump rate, e.g., 1.5-2X. As a result, the CS (14) buffer will be filled continuously and will fill up after one or two slots. At this point the CS (14) will close the unicast stream to rejoin an appropriate multicast network. Although the unicast stream can be kept open, it will increase the network load.

In order to provide a limited amount of media to an unlimited number of users in a fully interactive manner, a batch concept is employed in the present invention so that the users can simultaneously share the same video stream while the interactive functionality is still implemented. This may allow a multicast network to serve many users and reduce servers and networks.

There are three types of flows defined for class B services: 1) m (i) streams-which represent normally played multicast media streams initiated at the beginning of the ith streaming interval; 2) i-stream-which represents an interactive unicast media stream opened for any user requested interactive function; 3) j-stream, which represents an integrated unicast media stream used by a user to integrate back into m (i) stream.

When a user engages in an interactive function, a new unicast network may be provided to the user depending on what the initiated interactive request is. A unicast network is said to be split from the original multicast network. This splitting operation is straightforward when a new unicast network is provided to handle the requested interaction.

On the other hand, the merge operation is more complex and extremely important as it allows users on a unicast network to merge back into the m (I) stream and release the I stream after the interworking function is performed. A significant improvement in VOD interaction features can be achieved by incorporating operations to reduce the number of unicast media streams. Which in turn allows the same number of streams to serve more user interaction requests, so that better quality of service and scalability can be achieved.

The architecture of the media delivery system (10) can ensure that all clients can be merged back into the m (i) stream as long as the following requirements are met: 1) CS (14) is sufficient to hold all frames for an interval of one stream (e.g. 30-60 seconds), and 2) J streams can be transmitted at a higher speed than m (i) streams and thus can fill the necessary buffers before merging.

For example, considering a 30 second MPEG-2(4.7Mbps) video, the required buffer is 18MB (30 x 4.7/8). As soon as the user has completed all interactive functions and returns to normal play, the J-stream is started immediately. The J-stream then transmits the frames at a faster speed f. Since the incoming data rate is faster than the consumption rate r, the buffer will fill up. f can be chosen to be different values depending on the network architecture. Networks with larger bandwidths may support larger f, meaning that clients may merge back into the m (i) stream in a shorter time.

Suppose that the buffer is being filled at a rate of (f-r) Mbps. In the worst case, the time required to fill the buffer is:

for example, if f is 1.5 × 4.7Mbps, T is_Fill60 seconds.

Once the buffer is full, the user must be able to merge back into the m (i) stream, which is shown in fig. 3. Assume that after some interactive action and J-streaming, the buffer has been filled at 280 seconds of arbitrary marking relative to the CS (14). The current playing point of the stream is at 90 seconds, so the CS (14) buffer stores frames of the stream from 90 seconds to 120 seconds. The CS (14) then leaves the J-flow because no more data can be stored, thus freeing the J-flow to serve other users.

Since the stream interval between m (i) streams is the same size as the CS buffer, m (i) streams with the current playout time within the CS buffer time stamp can always be found. Since the CS must continue to play more than the already buffered frames, it can merge back into the appropriate m (k) stream. In doing so, it may start receiving frames at 120 seconds of the m (k) stream (i.e., 290 seconds relative to the time stamp of the CS). At this point, when a frame of 90 seconds to 100 seconds has been played, 10 seconds of buffer space in the CS may be released. Thus, this user is successfully merged back into the shared m (k) stream.

The operation of each interactive function that may preferably be implemented in the media delivery system (10) of the present invention will now be described in the following paragraphs.

Play/stop

For normal play, the CS (14) first sends a play request to the VSC (14), then joins the multicast media stream, and finally waits for VSC video data. Whereas in terms of stopping, the CS simply tells the VSC and leaves the selected multicast media stream. During the play-out time, the CS buffer is continuously filled with the media of the selected multicast media stream.

To improve the benefits of multicast network delivery, the VSC (12) preferably waits some time to fill the buffer of the CS (14) before starting the newly selected multicast media stream when the user makes a selection request.

Pausing

The pause maintains the playpoint at its current location. During the pause, the CS buffer continues to receive data from the m (i) stream, at which time no data is consumed. And thus data is accumulated in the buffer. If normal play is resumed before the CS buffer is full, the CS (14) can continue to receive data from the same M (i) stream. Only the location of the playing point within the buffer is changed. If the pause is until the buffer is full, the CS (14) does nothing after the buffer is full. Which holds the frames in a buffer for incorporation. Once the merge operation is initiated, it will look for the appropriate m (i) stream merge. This incorporation operation is the same as that already described in paragraph C. Assume that the original stream is M (k) and the pause time is T_PauseThe algorithm is as follows:

if m x the stream interval T_Pause

(m + 1). times.flow interval,

then merge into M (k + M) stream

Where m must generally be positive since the CS (14) rejoins a later multicast media stream so that it maintains the same position within the video. When the playpoint pauses near the end of the stream and its pause time is long, it may have a wrap around the stream and m may take a negative value.

Slow motion

Slow motion plays the stream at a slower speed, e.g., 0.5X. During slow motion, the data consumption rate is smaller than the arrival rate. And thus data will accumulate in the buffer. Similar to the pause, if playback is resumed before the CS buffer is full, the CS (14) continues to receive data from the M (i) stream. If slow motion continues until the buffer is full, the CS (14) must leave the current M (i) stream. The CS (14) will continue playing slow motion to the end of the buffer. The CS (14) then needs to join the next stream to get the needed frames in order to continue slow motion. It is also necessary that the CS (14) join the next stream so that it can resume normal play at any time.

The CS (14) buffer status shown in fig. 6 helps explain how slow motion works, which refers to a specific example of slow motion operation. Its time stamp is relative to the CS (14). In fig. 4, 0.5X slow motion starts at CS 30 seconds. Thereafter, 5 second frames are played every 10 second CS time. However, the incoming frame rate is not changed. Thus 5 second frames are accumulated every 10 seconds CS time. The buffer will fill up in 80 seconds and the CS (14) must leave the current m (k) stream. The CS (14) then adds the next M (k +1) stream to get the lost frame after 80 seconds. Since each stream is separated by the same stream interval of 30 seconds, 80 seconds of frames from the M (k +1) stream will be available at CS110 seconds. Frames received 110 seconds ago are repeated with those in the buffer and will be discarded. At CS 120 seconds, CS (14) resumes normal play. Since the old frame has been played out and CS (14) resumes normal play with frames from the new M (k +1) stream, the play point position will change to the new M (k +1) stream.

Fast forward/fast reverse (FF/REW) for various speeds

Fast forward FF or fast rewind REW is to play frames faster than normal speed. In operation, CS (14) first attempts to serve FF by skipping certain frames using frames in its own buffer. If FF action exceeds the frame range in the buffer, video provided by the pre-recorded I-stream is used with different speeds for forward and reverse directions FF/REW. This not only uses bandwidth more efficiently, but also provides various speeds of FF/REW actions (e.g., 1X fast rewind, 2X, 4X, etc.) in advanced VCRs.

An I-stream containing pre-recorded media is generated by the DIS (18) and provided to the CS (14). For example, when a user requests 4X FF, DIS sends a pre-recorded 4X forward I stream containing the start at the desired time to CS (14). The CS (14) can then play these frames without wasting any bandwidth. When the CS ends the interactive function and resumes normal play, all CS buffers are cleared because they are no longer valid. A J-stream is then sent to the DIS (18) to transfer data to the CS (14) at a faster rate to fill up the buffer for merge operations as described in the preceding paragraph.

To know which packet the J-stream should carry to fit the playout time, the required packet sequence number P must be set equal to (playout time x m (i) transmission rate of the stream)/x, where x is the packet size expressed in bits.

FIG. 7 shows how to determine the appropriate M (i) stream after FF. It can be understood that the actual playing time of 4X FF of 20 seconds is 80 seconds. T is_FFTime of FF action, and T_FillAs previously defined. The play time has elapsed (P)_MC-P_FF) In which P is_FFIs to start the playing time of FF, and P_MCTo restore the normal multicast network m (i) the play time of the stream. (T)_FF+T_Fill) Is the total time of the split and merge operations. Thus, the stream has been played (T)_FF+T_Fill) Time of (d). In FIG. 8, the difference between the playback points of the FF operation and the normal playback operation is shown, which shows [ (P)_MC-P_FF)-(T_FF+T_Fill)]For playing back original multicast media streamThe play time of the new multicast media stream before the break. Assuming that CS is initially within the M (k) stream, the algorithm for FF operation is as follows:

if m x stream interval (P)_MC-P_FF)-(T_FF+T_Fill)

Interval of < (m +1) × stream

Then merge into M (k-M) stream

Where m must be positive as it must advance to the previous stream to reach the rear part of the view.

In terms of REW, it operates like FF. It drives the play time backwards. DIS will send a pre-recorded 1X/2X/4X backward I stream to CS, and J stream is also used to fill the buffer for incorporation. However, referring to FIG. 9, now [ T ]_FF+T_Fill+(P_REW-P_MC)]]Is the playing time after the current position. P_REWThe time to start the REW. The algorithm for the REW operation is as follows:

if mx stream interval is less than or equal to T_FF+T_Fill+(P_REW-P_MC)

Interval of < (m +1) × stream

Then merge into M (k + M) stream

Where m must be positive to enter a later stream to an earlier part of the view.

Jump forward/jump backward (JF/JB)

The forward jump is to proceed immediately to a specific playing time. This is an advanced feature of VCD and DVD players that allows the user to go directly to the playing time to search for frames.

When a user makes a JF request at the media delivery system (10) of the present invention, it first determines whether the target time frame is in the CS buffer. If so, the user may be served by moving only the playpoint location within the buffer to the desired frame. If not, the J-stream starting at the desired time will be sent out immediately by the DIS. CS Clears (CS) its own buffer and plays the frames from the J stream. It accepts J streams until the buffer is full, then leaves J streams and merges back into an m (i) stream.

Fig. 10 shows a specific example where a user jumps forward from a 70 second timestamp to a 130 second timestamp. P_JFIs the time at which JF begins. Just like other inter-functions, the CS needs to find a suitable m (i) stream to incorporate back. The algorithm is similar to FF:

if the mx flow interval is less than or equal to (P)_MC-P_JF)-T_Fill

Interval of < (m +1) × stream

Then merge into M (k-M) stream

Where m must be positive as it requests to view the later part by jumping back to the previous stream.

JB operates similar to JF except that JB will jump to the play time of the earlier part of the view.

If mx stream interval is less than or equal to T_Fill+(P_JB-P_MC)

Interval of < (m +1) × stream

Then merge into M (k + M) stream

Where m must be positive because it requests the earlier part by jumping to the later stream.

It has long been a difficult problem to provide full interactive functionality in a multicast network VOD system. The media delivery system (10) of the present invention may allow a user to implement full interactive functionality including pause, slow motion, fast forward/rewind, skip forward and skip backward, which requires relatively low system resources to function. This may be achieved by limiting the number of unicast media streams during inter-function operation. Accordingly, the overall cost of ownership of such a VOD system providing interactive functions can be reduced.

Although preferred embodiments of the present invention have been described in detail by way of example, modifications and improvements of the present invention will be apparent to those of ordinary skill in the art. It is to be understood that such modifications and improvements fall within the scope of the appended claims. Furthermore, the embodiments of the invention should not be construed as limited to only examples or figures.

List 1

Reference numerals	Description of the invention
		10	Media delivery system
12	Video server cluster
		14	Media client
16	Network
		18	Distributed interaction server
20	Backbone network for multicast networks
		22	Local distribution network

Claims (18)

1. A method for delivering media to a plurality of media clients, said clients having a buffer for caching media of a selected media stream within a streaming interval and processing capabilities for playing the media within a multicast media stream over a network, comprising the steps of:

-generating a plurality of multicast media streams, wherein each multicast media stream is repeated within a regular stream interval;

-joining the media client to the selected multicast media stream in response to a selection request from the media client;

-continuously caching the buffer of the media client with the non-played media of the selected multicast media stream; and

-caching the selected multicast media stream in at least one interactive server,

such that interaction requests and/or errors in playing the media within the media client are handled by the interaction server or the media server.

2. The method of claim 1, wherein the interaction request and the error while playing the media in the media client are processed by the interaction server.

3. The method of claim 1, wherein the media in each multicast media stream is sent in data packets, and the packets are randomly interleaved.

4. The method of claim 1, wherein the flow interval is 30 to 60 seconds.

5. The method of claim 1, further comprising the step of generating a dedicated unicast media stream by the media server or the interaction server and delivering it to the media client in response to a dedicated interaction request from the media client requesting a dedicated media.

6. The method of claim 5, wherein the dedicated unicast media stream is generated by an interaction server if the interaction server contains the dedicated media.

7. The method of claim 5, wherein the dedicated unicast media stream is generated by a media server if the interactive server does not contain the dedicated media.

8. The method of claim 5, wherein if the interaction server does not contain the dedicated media, the dedicated unicast media stream is generated by the interaction server after the dedicated media is delivered to the interaction server by the media server.

9. The method of claim 1, wherein the interactive request comprises one or more of: pause, slow motion, fast forward, fast reverse, skip forward and skip backward.

10. A system for delivering media selections to a plurality of media clients, the clients having a buffer for caching media in a selected media stream during a streaming interval and processing capabilities for playing media in a multicast media stream over a network, comprising the steps of:

-at least one media server for generating a plurality of multicast media streams, wherein each multicast media stream is repeated at regular stream intervals, joining a media client to a selected multicast media stream in response to a selection request from said media client; and

-at least one interactive server for caching the selected multicast media stream,

such that interaction requests and/or errors in playing media within the media client are handled by the interaction server or the media server.

11. The system of claim 10, wherein interaction requests and errors in playing media in the media client are handled by the interaction server.

12. The system of claim 10, wherein the media in each multicast media stream is sent in data packets, and the packets are randomly interleaved.

13. The system of claim 10, wherein the flow interval is 30 to 60 seconds.

14. The system of claim 10, wherein a dedicated unicast media stream is generated by the media server or the interactive server and delivered to the media client in response to a dedicated interactive request from the media client requesting a dedicated media.

15. The system of claim 14, wherein the dedicated unicast media stream is generated by an interactive server if the interactive server contains the dedicated media.

16. The system of claim 14, wherein the dedicated unicast media stream is generated by a media server if the interactive server does not contain the dedicated media.

17. The system of claim 14, wherein if the interaction server does not contain the dedicated media, the dedicated unicast media stream is generated by the interaction server after the dedicated media is delivered to the interaction server by the media server.

18. The system of claim 10, wherein the interactive request comprises one or more of: pause, slow motion, fast forward, fast reverse, skip forward and skip backward.