WO2014167169A1

WO2014167169A1 - Media-on-demand system

Info

Publication number: WO2014167169A1
Application number: PCT/FI2013/050390
Authority: WO
Inventors: Tommi KETOLA
Original assignee: Teleste Oyj
Priority date: 2013-04-10
Filing date: 2013-04-10
Publication date: 2014-10-16

Abstract

A method comprising: receiving, in a media-on-demand system, an order from a client terminal for a media item; determining at least one multicast in a network segment that said client terminal is receiving, said multicast comprising at least a first stream of said media item; adjusting parameters of streams of said network segment such that a new stream can be included in the network segment; and including a second stream of said media item in the network segment, said second stream comprising at least the part of said media item from the beginning of the media item to the earliest part received from the at least first stream by the client terminal.

Description

MEDIA-ON-DEMAND SYSTEM

Field of the invention

The present invention relates to media-on-demand systems, and more particularly to push VOD technology. Background of the invention

Video on Demand (VOD) or media-on-demand systems allow users to select and watch/listen to video or audio content on demand. In VOD systems, the video or audio content is either streamed through a set- top box (STB), a computer or other device, allowing viewing in real time, or downloaded to a memory of a computer, digital video recorder (DVR) or portable media player, for example, for viewing at any time. The predominant technique currently in use is based on so-called pull- VOD systems, which can be largely classified into open-loop schemes, closed-loop schemes, and prefix-assisted periodic broadcast schemes.

In simple open-loop schemes, based on the orders from customers a server allocates for each video a number of channels, and on each channel, the whole video is broadcast at playback rate of the video. The starting points of the transmission on the different channels are shifted in time to guarantee a start-up delay of no more than the length of the video. In more efficient schemes, each video is divided into many segments. The server transmits each segment periodically and infinitely each at its own rate. While open-loop schemes broadcast the video regardless of the clients request pattern, closed-loop schemes serve the video in response to clients' requests. Conceptually simplest closed loop scheme is based on each client receiving an independent unicast stream as a response to a request from the client. This scheme operates fully on-demand and supports advanced functions like pause and rewind without a need for local storage capacity. The bandwidth consumed by the scheme is directly proportional to number of active clients, and consumes significant amount of bandwidth at peak hours. The main problem with this scheme is that the network must be built to meet the demand of this peak consumption and it may be largely unused during the off- peak times.

To overcome the excessive bandwidth use of the entirely unicast streaming, combinations of open and closed loop schemes can be used. Clients are typically merged in a hierarchical manner. When a new client arrives, the server initiates a unicast stream to that client. At the same time, the client starts listening, from said number of channels, to the target stream closest in time that is still active. When the client receives via unicast all what it missed from the beginning of the target stream, the unicast stream is terminated and the client continues to listens only to the target stream.

In prefix caching assisted periodic broadcast schemes open-loop and closed-loop systems are combined such that the video is divided into two parts, the prefix and the suffix. The prefix is delivered via a closed- loop scheme while the suffix is multicast via an open-loop scheme, thus fostering the delivery of less-popular videos as well. The pull-VOD systems are viable solutions as long as the number of clients and the number of available video titles remains reasonable, whereby individual orders can be delivered with the scarce network resources. However, with the increased popularity of VOD services the number of clients and/or the number of the available video titles easily increases to a level inevitably causing network congestion, resulting in an unacceptably long start-up delay, slow download and/or jerking streaming.

The push-VOD technique has been developed to alleviate the problem caused by the scarce network resources in comparison to the increased number of orders in pull-VOD system, on one hand, and to provide VOD service for a number of broadcast operators having systems that lack the interactivity, on the other hand. A push-VOD system uses the customer's DVR to automatically record a selection of video titles, often transmitted during the off-peak hours. Users can then watch the downloaded programs at times of their choosing. The downloaded content, stored on the DVR hard drive, is eventually deleted to free memory space for new programs. The selection of the video titles to be transmitted may be decided by the operator, or if the system includes a return channel for making orders, the selection of the video titles may be based on the orders.

Push VOD technology brings several advantages to the network operators, since it is particularly cost-effective for broadcasters as they re-use their existing broadcast infrastructure and the content is pushed during the off-peak hours. The operator does not necessarily need to provide any return channel. On the other hand, the clients get better value out of their personal video recorder (PVR) enabled set-top boxes.

However, the Push VOD technology according to prior art has technical shortcomings. If client wishes to watch content other than those automatically recorded on client's PVR, it is not possible immediately or even nearly immediately, but the client must make an order for the desired media item, if possible, and wait for the media item to be delivered and stored during a forthcoming off-peak time.

Summary of the invention

Now there has been invented an improved method and technical equipment implementing the method, by which a more immediate response to a client's order is possible. Various aspects of the invention include a method, a system, an apparatus and a computer program, which are characterized by what is stated in the independent claims. Various embodiments of the invention are disclosed in the dependent claims.

According to a first aspect, a method according to the invention comprises receiving, in a media-on-demand system, an order from a client terminal for a media item; determining at least one multicast in a network segment that said client terminal is receiving, said multicast comprising at least a first stream of said media item; adjusting parameters of streams of said network segment such that a new stream can be included in the network segment; and including a second stream of said media item in the network segment, said second stream comprising at least the part of said media item from the beginning of the media item to the earliest part received from the at least a first stream by the client terminal.

According to an embodiment, in response to multiple network segments transmitting said media item, the method further comprises selecting the most preferable network segment for transmission of the second stream according to one or more of the following criteria:

- a network segment with most transmissions of said media item,

- a network segment with least transmissions of any media items, - a network segment with least bandwidth used,

- a network segment with most recently started transmission of said media item, or

- any combination of these criteria. According to an embodiment, the method further comprises adjusting bit rates of the existing streams said network segment such that the second stream can be included in the network segment.

According to an embodiment, including the second stream of said media item in the network segment comprises adjusting the bandwidth of the second stream and setting a stop position of the second stream to the end-of-file.

According to an embodiment, the method further comprises communicating the adjusted parameters of the network segment to the client terminal.

According to an embodiment, the method further comprises receiving a synchronisation report from the client terminal, the synchronisation report comprising synchronisation points of each of the streams of the network segment having said media item, the synchronisation points indicating the position of the stream where the client terminal has started to store said media item; and adjusting, on the basis of the synchronisation report, the stop positions of a new and ongoing transmissions of the said media item in the network segment to ensure that the client terminal receives all parts of said media item. According to an embodiment, the method further comprises adjusting, on the basis of information available from the media-on-demand system and known system latencies, the stop positions of the started and ongoing transmissions of the said media item in the network segment to ensure that the client terminal receives the all parts of said media item.

According to an embodiment, in response to the second stream has been transferred until the stop position, releasing the transfer resources of the second stream from the network segment; and adjusting the bandwidths of other streams in the network segment to reflect the reduced number of streams.

According to an embodiment, the method further comprises starting the transfer of the second stream either immediately after the parameters of the network segment have been adjusted or after a predefined delay.

According to an embodiment, the network segment comprises one or more DVB multiplexes arranged in MPEG-2 TS format, the method comprises inserting a private data type of packet as a synchronisation packet between media stream packets at desired segmentation intervals. According to an embodiment, the synchronisation packet comprises information related to the framing, the information including one or more the following:

- next frame number;

- previous frame number;

- total number of the frames;

- checksum of the previous frame.

According to a second aspect, there is provided a media-on-demand system comprising at least an order processor, a stream controller and a media streamer, wherein the order processor is arranged to receive an order from a client terminal for a media item; the stream controller is arranged to determine at least one multicast transmitted by the media streamer in a network segment that said client terminal is receiving, said multicast comprising at least a first stream of said media item; the stream controller is arranged to adjust parameters of streams of said network segment such that a new stream can be included in the network segment; and the stream controller is arranged to control the media streamer to include a second stream of said media item in the network segment, said second stream comprising at least the part of said media item from the beginning of the media item to the earliest part received from the at least a first stream by the client terminal.

According to a third aspect, there is provided an apparatus comprising a first communication interface for communicating with an order processor of a media-on-demand system;

a second communication interface for receiving media streams from the media-on-demand system, the second communication interface being arranged to receive multiple network segments, such as DVB stream segments, simultaneously; and

a memory for storing the media streams as segmented transfers.

According to a fourth aspect, there is provided a computer program product, stored on a computer readable medium and executable in a data processing device, for allocating media streams in a media-on- demand system, the computer program product comprising:

a computer program code section for determining at least one multicast transmitted by a media streamer in a network segment that a client terminal is receiving, said multicast comprising at least a first stream of a media item;

a computer program code section for adjusting parameters of streams of said network segment such that a new stream can be included in the network segment; and

a computer program code section for controlling the media streamer to include a second stream of said media item in the network segment, said second stream comprising at least the part of said media item from the beginning of the media item to the earliest part received from the at least first stream not received by the client terminal. These and other aspects of the invention and the embodiments related thereto will become apparent in view of the detailed disclosure of the embodiments further below.

List of drawings

In the following, various embodiments of the invention will be described in more detail with reference to the appended drawings, in which Fig. 1 shows a media-on-demand system according to an embodiment in a reduced block chart;

Fig. 2 shows a method for ordering media items according to an embodiment in a signalling chart;

Figs. 3a-3d show examples of implementing a multiplex of media streams in media-on-demand services, both according to prior art and according to an embodiment of the invention; Fig. 4 shows a block chart of arranging synchronisation points a multiplex of media streams according to an embodiment of the invention;

Fig. 5 shows an example of functionalities of a stream controller according to an embodiment of the invention; and

Fig. 6 shows a client terminal according to an embodiment in a reduced block chart. Description of embodiments

A media-on-demand system according to an embodiment is illustrated on a functional level in the block chart of Figure 1. The media-on- demand system is described in the following as capable of delivering media transmissions based on various DVB (Digital Video Broadcast) and MPEG (Motion Picture Experts Group) standards. The various DVB standards comprise different standards, for example, for terrestrial networks (DVB-T), cable networks (DVB-C), satellite networks (DVB-S) and mobile networks (DVB-H; Handheld). The DVB standards define the physical layer and data link layer of the distribution system, whereas the transmissions are organised according to MPEG-2 TS (Transport Stream) standard.

Push VOD systems or push media-on-demand systems are based on the concept of narrowcasting, which refers to delivering media content to a predetermined limited group of audience. Thus, instead of broadcasting the media streams to all receivers in the network, the media streams are multicast, for example, to the receivers in a predetermined narrowcast area in a DVB network. It is, however, noted that the invention is not limited to DVB networks solely, but it can be implemented in any other distribution network capable of implementing the features of the invention. For example, the invention can be implemented in IP (Internet Protocol) networks utilising the IP-specific version of the multicast networking, i.e. IP multicast, for sending IP datagram-based streams to a group of receivers in a single transmission. Thus, the media-on demand system may be implemented as IP television (IPTV) system as well.

The system comprises a client terminal 100, which is used by an end- user (i.e. customer) to browse available media, to order media by communicating with an order processor 102, and to render the ordered media, when received from a network. The client terminal 100 may be, for example, a television set, a set-top box, a mobile phone, a smart phone, an Internet access device (Internet tablet), a personal computer of various size and format, a video decoder or a video player. The client terminal 100 may be connected to the order processor 102 via communication connections such as a fixed connection to the DVB network or to the internet, a wireless connection to the DVB network or the internet, a fixed connection to the mobile network, or a wireless connection to the mobile network. The connections are implemented by means of communication interfaces at the respective ends of the communication connection. The client terminal 100 preferably comprises a local storage for storing media as segmented transfers, preferably faster-than-real-time, and a capability of receiving multiple network segments, such as DVB stream segments simultaneously. The order processor 102 is responsible for validating the orders, and initiating the media transfer via a stream controller 104.

The stream controller 104 is responsible for coordinating the transmission of the ordered media to the client terminal 100 according to the embodiments described below.

A media streamer 106 retrieves the ordered media from a media storage 108 and transmits the media to a network 1 10 according to the commands from the stream controller 104.

In Figure 1 , the order processor 102, the stream controller 104 and the media streamer 106 are shown as different functional units. In practice, the operations of these functional units may be implemented as software components residing on one device or distributed across several devices.

The media storage 108 contains the media, which is available for the client terminal to order and which will be transmitted to the client terminal. It is noted that while Figure 1 depicts the media storage as a single storage unit, in practice the media storage may be implemented as a plurality of media servers connected to the system via various network connections.

The network 1 10 is a data transmission system connecting the media streamer 106 to the client terminals 100. The network 1 10 may contain one or several network segments, which are also capable of multicasting the same data to multiple client terminals. A single client terminal 100 may be connected to one or several network segments. For example, a digital television (DVB) network may be segmented to a plurality of narrowcast areas, which address their unique population of client devices. The narrowcast area has several frequency-multiplexed bit streams, i.e. multiplexes, for transporting the video streams. A multiplex can transmit multiple video streams, and multiple client terminals may be receiving streams from the same multiplex. Thus, a multiplex is may be regarded as a multicast capable network segment. In a traditional media-on-demand system each client terminal will receive their unique stream for rendering, and optionally for storing in a local storage.

The embodiments of an enhanced media-on-demand system will now be further described by referring to the signalling chart of Figure 2. Figure 2 illustrates only one example of messages required to establish the operation of the media-on-demand system, and it is apparent for a skilled person that the same functionalities can be achieved with various alternative configurations of messages and/or message names.

In Figure 2, the end-user may browse the available media items, such as movies, via the user interface of the client terminal 100 and then submit an order (200) for at least one media item to the order processor 102. The order processor validates the order, i.e. checks that the order includes sufficient identification data of the media item, that the ordered media item is available to be transmitted to the client terminal, and that the client is entitled to view the media item. If the order can be successfully validated, the order processor 102 sends a setup_order message (202) to the stream controller 104. The setup_order message (202) comprises the identification data of the media item (e.g. a movie identifier), and sufficient information to select a suitable network segment (e.g. a narrowcast area in digital television network) for transferring the media item to the client terminal. The stream controller 104 has prior knowledge of all available network segments and how clients may be reached via those segments. The stream controller may keep list of all transmissions per a network segment. Upon reception of the setup_order message (202) the stream controller aims to find a suitable network segment for the transmission of the media item (204), i.e. preferably a network segment where the same media item is already being transmitted. If only one network segment is transmitting the same media item is found, said network segment is selected for transmission. If multiple network segments transmit the same media item, algorithm A1 is used to select the most preferable network segment for transmission. The algorithm A1 may be configured to find an optimum network segment according to one or more of the following criteria: a network segment with most transmissions of the same media item,

- a network segment with least transmissions of any media items,

- a network segment with least bandwidth used,

- a network segment with most recently started transmission of the same media item, or

- any combination of these criteria.

The algorithm A1 preferably complies with the maximum bit rate of the network segment and minimum bit rate of individual streams. If no network segment is transmitting the same media item, then algorithm A2 is used to select the preferred network segment. The algorithm A2 may be configured to find an optimum network segment, which may be a network segment with least number of transmissions, or a network segment with least bandwidth used.

If no network segment can be selected, for example, due to network congestion, FAIL status will be returned to the order processor, and no further actions will be taken. Once the stream controller has found a suitable network segment for the transmission of the media item, the stream controller may adjust the parameters of the network segment such that the new stream of the media item can be included to be transmitted in the network segment.

If necessary, the stream controller 104 may adjust bit rates of the existing streams of the selected network segment to make room for the new stream. For this purpose, the stream controller 104 may send a set_bandwidth message (206) to the media streamer 106.

Then the stream controller 104 sets up streaming for the new stream transfer by sending a setup_stream message (208) to the media streamer 106. The bandwidth of the new stream may be adjusted with a set_bandwidth message (210). Furthermore, a stop position of the new stream may be set to the end-of-file, for example using a set_stop_pos message (212). Alternatively, setting the stop position to the new stream may also be a default setting in the media streamer 106.

Adjusting the parameters of the network segment is described above as requiring four separate messages (206 - 212). However, it is possible to indicate the required parameters to the media streamer 106 by using only one (or more) messages having the content of said four messages or a subset thereof combined together.

After having the parameters of the network segment successfully adjusted, the stream controller 104 acknowledges the setup order by sending a setup_order_ack message (214) to the order processor 102, which further communicates the stream parameters in order_ack message (216) to the client terminal 100 to prepare for the playback. Upon receiving the stream parameters, the client terminal may start to listen to the existing streams on the selected network segment to obtain a synchronisation point. After a synchronisation point has been found on a first stream, the client terminal 100 starts to store (218) the media item transmitted on the first stream from the position of the synchronisation point for later playback. The client terminal 100 continues to scan the synchronisation points from all streams of the network segment containing said media item, and preferably stores the media item transmitted on each stream from the position of the found synchronisation point.

According to an embodiment, when all streams have been synchronised, the client terminal 100 may send a sync_report message (220) to the order processor 102, which will be forwarded (222) to the stream controller 104. As a response to receiving the sync_report message, the stream controller adjusts the stop positions of the started and ongoing transmissions of the said media item in the same network segment to ensure that the client terminal, which has made the order, will receive a complete stream from the stream segments. For adjusting the stop positions, the stream controller may use algorithm A3, which adjusts the new stream segment to be started from position 0, and all other stream segment start positions are received from the sync_report message. The stream segments are ordered according to the start positions. The stop positions of all stream segments are set to coincide with the start position of the later transport, and end-of-file for the last stream segment. According to an alternative embodiment, instead of the synchronisation points received from the sync_report message, the stream controller 104 may autonomously select suitable synchronisation points based on information available from the media streamer 106 and known system latencies. Thus, it is not mandatory for the client terminal 100 to send the sync_report message.

Once the client terminal is ready to receive the newly created stream, in addition to receiving the existing streams, it will request the stream from the order processor 102 (stream_request, 224). The order processor 102 sends a start_order message (226) to the stream controller 104, which further instructs the media streamer 106 to start playback with a start_transfer message (228).

Meanwhile, after having received the adjusted parameters for the network segment, the media streamer 106 organises the network segment according to the new parameters, the new stream being included. This may involve requesting (230) the media item from the media storage (108) and downloading (232) the media item from the storage. In a typical case, the media streamer 106 is already streaming the media item in one or more existing streams of the network segment and the media item may be stored e.g. in a local cache of the media streamer. Therefore, requesting and downloading the media item may not be necessary.

In response to receiving the start_transfer message (228) from the stream controller 104, the media streamer 106 starts to transfer the new stream (234) along with the existing streams in the network segment. When the new stream has been transferred until the stop position, the media streamer will release the transfer resources and notify this to the stream controller 104 with a stream_ended message (236).

Upon receiving the stream_ended message, the stream controller will update (238) its list of active transfers by removing the ended transfer, and adjust the bandwidths of all other streams in the same network segment to reflect the reduced number of streams.

It is apparent that various modifications may be made in the above signalling without affecting to the obtained technical effects. Thus, according to an embodiment, the setup_order and start_order messages may be combined into one message such that the transfer of the new stream will start either immediately after the parameters of the network segment have been adjusted or after a predefined delay. According to another embodiment, if multiple setup_stream messages for the same media item for the same network segment are received while the transfer is still ongoing (i.e. no start_order message is received for any of the transfers), the new transfer may be combined such that the parameters of the first ongoing stream will be allocated to the other ongoing streams as well. Moreover, it is possible that the order processor and/or the client terminal may decide to abort the transmission, e.g. due to exceptional circumstances, and an abort_stream message is then transmitted to the media streamer. The stream controller may then release transfers of those stream segments, which are solely allocated to the aborted transmission. The advantages obtained by the embodiments are illustrated in Figures 3a - 3d. Figure 3a shows a traditional approach for implementing a video-on-demand service, wherein a movie (stream 1 ) is transferred to the client terminal at a real-time speed; i.e. the client terminal renders the video data of the stream to be displayed immediately upon reception. In the example of Figure 3a, it is assumed that a multiplex of 25 Mbps is available for stream transfer. Typically, the bandwidth of the multiplex is shared to transfer multiple streams at the same time. For example, the 25 Mbps multiplex in Figure 3a is shared among 10 streams of 2.5 Mbps per stream. In this example, it is further assumed that the transfer of each of the streams 1 - 10 will take 120 minutes at the speed of 2.5 Mbps. However, since each of the streams is transferred at real-time speed, a customer needs to receive the stream from the very beginning for the whole 120 minutes, if he/she wants to watch or store the whole movie.

Another approach known from prior art is to reserve the whole transfer capacity of the multiplex (or a maximum allowed by the performance of the client terminal) for over-speed transfer of one stream at a time. The requirement for this approach is that the client terminals are capable of storing the transfer faster-than real-time. This approach is shown in Figure 3b, where stream 1 is first transferred at the speed of 25 Mbps, completing the transfer in 12 minutes. Herein, the complete stream must be transferred before new one can be started on the same multiplex. Thus, a customer willing to watch or store a movie on stream 10 needs to wait for almost two hours for the transfer. Figure 3c shows an advanced approach for implementing a media-on- demand service, wherein the operator of the media-on-demand service has more flexibility to adjust the stream transfer e.g. according to the popularity of movie orders. Herein, the bandwidth of multiplex can be shared among more than one stream and the number of streams can be increased as long as the bandwidth per stream is at least the realtime bandwidth needed to stream.

In Figure 3c, stream 1 may comprise the most popular movie, for example, and the whole bandwidth of the 25 Mbps multiplex is reserved for it for the first six minutes. For the next 12 minutes (6 - 18 min), the bandwidth of the multiplex is shared among stream 1 and stream 2, thus allowing advancing the start of transferring stream 2. When the transfer of stream 1 has been completed, the whole bandwidth of the multiplex is reserved for stream 2 for the next six minutes (18 - 24 min). However, even though the approach enables to start transferring a plurality of streams earlier and still transfer multiple (e.g. the most popular) streams at the same time, the approach nevertheless requires that a customer needs to receive the stream from the very beginning, if he/she wants to store the whole movie.

Figure 3d shows an example how starting stream segments (movie segments) may be included in multiplexes, which already have streams of the same movie. Herein, it is required that the client terminals have the capability to receive movie data from multiple streams simultaneously, whereby the concurrent stream reception by multiple clients will improve the bandwidth efficiency. Thus, the operator of the media-on-demand service may optimise the transfer of streams in a situation where the transfer of a particular stream has already started and a customer makes an order for said stream.

In the example of Figure 3d, the whole bandwidth of the 25 Mbps multiplex is reserved for stream 1 in the beginning. Almost immediately thereafter, a customer makes an order from his/her client terminal for the reception of the movie already concurrently transferred on stream 1. Using the procedures described in Figure 2, the stream controller concludes that it is required to retransmit the first 10 minutes of the movie, and then the customer may seamlessly join to receiving stream 1. Accordingly, the stream controller adjusts the bandwidth of stream 1 to be 12.5 Mbps for two minutes (1 - 3 min). The remaining 12.5 Mbps of the multiplex is used for transferring the first 10 minutes of the same movie (stream 2) concurrently transferred on stream 1. When stream 2 has been transferred until the stop position, the media streamer releases the transfer resources of stream 2 and the stream controller adjusts the bandwidth of stream 1 back to 25 Mbps. Meanwhile, the client terminal of the customer has caught up the transfer of stream 1 and may then seamlessly join to receiving only stream 1.

As a result, when the client terminals having the capability to receive multiple streams simultaneously are connected to a multicast capable network segment, the stream controller may adjust the multicast to comprise multiple streams or stream segments of the same media item being simultaneously transmitted. This improves the efficiency and throughput of the network. Also the user experience of the customer of the media-on-demand service is enhanced, since ordered media items are can be delivered to the customer significantly faster than previously.

Various transmission methods require segmentation of media streams in a coarser manner than inherently supported by DVB and MPEG standards. An example of such transmission method is HTTP Live Streaming (HLS), developed by Apple Corporation and disclosed in the Internet draft "draft-pantos-http-live-streaming-04", which requires segmentation in the magnitude of seconds. Also the above-described method for shared transmission of media-on-demand content requires segmentation in a coarser manner than supported by DVB and MPEG standards.

DVB transmissions are based on MPEG-2 Transport Stream (MPEG-2 TS), which can multiplex numerous data streams of different types. The MPEG-2 TS standard defines data types e.g. for video, audio, teletext and, in addition, a user defined data type, i.e. private data. MPEG-2 TS is arranged to be transmitted in time-multiplexed fixed sized packets. Now according to an embodiment, if the network segment comprises DVB multiplexes arranged in MPEG-2 TS format, the synchronisation may be achieved by inserting a private data type of packet as a synchronisation packet between media stream packets at desired segmentation intervals.

Thus, the embodiment provides a simple method for providing synchronisation points in DVB media streams, while preserving the compatibility of standard DVB streams. The compatibility ensures that only one stream needs to be stored in the media-on-demand system, and both synchronisation-capable and non-synchronisation-capable terminals can receive the same stream. An example of the embodiment is shown in Figure 4, where, in a multiplex comprising packets of two media streams (M1 , M2), a synchronisation stream S1 synchronising stream M1 is included as private data packets.

The synchronisation packet will carry in minimum information directly related to the framing, which may include one or more the following:

next frame number;

previous frame number;

- total number of the frames;

checksum of the previous frame.

In addition, the synchronisation packet may provide ancillary information related to the service, which is either non-existing or more difficult to decode from the standard MPEG-2 TS, for example:

an identifier of the media item in the stream;

a timestamp.

The synchronisation point may be placed to coincide with other important key points in the stream, for example an intra-coded video frame starting a Group of Pictures (GOP), which will ensure that the next video frame can be completely decoded and displayed.

The stream controller plays a significant role in the above system. The stream controller may be implemented as a separate network element. Alternatively, the stream controller may be a functional unit implemented together with one or more functional units within a common network element. In practice, the operations of the stream controller may be implemented as software components residing on one network element or distributed across several network elements. Consequently, the network elements contain memory, one or more processors, and computer program code residing in the memory for implementing the operations of the stream controller. The purpose of the stream controller is to allocate media streams into network segments (e.g. DVB multiplex) in a way that enables a client terminal to receive multiple transmission of the same media item, when possible. The operations of the stream controller are defined by its response to messages to/from the order processor (Interface A) and the media streamer (Interface B). Some of these messages are shown in Figure 5, and the operation of the stream controller in relation to these messages is described in connection with Figure 2.

A simplified structure of a client terminal device according to an embodiment is illustrated in a block chart of Figure 6. For illustration purposes, an exemplified configuration of a set top box is shown in Figure 6, but it is to be noted that it is merely a representative of various electronic devices with an internal controller used as a content receiving device. As mentioned above, instead of a set-top-box, the client terminal 600 may be, for example, a television set, a mobile phone, a smart phone, an Internet access device (Internet tablet), a personal computer of various size and format, a video decoder or a video player.

The client terminal 600 comprises one or more network interfaces 602 for receiving (RX) media streams from the network and messages from the order processor. The client terminal 600 comprises one or more network interfaces 602 for transmitting (TX) orders and messages to the order processor. The network interfaces 602 may include a fixed connection to the DVB network or to the internet, a wireless connection to the DVB network or the internet, a fixed connection to the mobile network, or a wireless connection to the mobile network. The network interfaces may be in accordance of a WiFi, WiMax, WiMax mobile, wireless, cellular, or other types of communication systems. The network interfaces may use various protocols for communication therethrough including, but not limited to, hypertext transfer protocol (HTTP).

A controller 604 is used to coordinate and control the various functions of the client device. These functions may include at least a tuner 606, a demodulator 608, a decoder 610, one or more memories 612 and a user interface (Ul) 614 management functions. The controller 604 may be a general-purpose processor, such as a microprocessor, that cooperates with control software. The tuner 606 receives the signal or data from an individual media stream. The tuner may receive television programming content, program guide data or other types of data. The demodulator 608 demodulates the signal or data to form a demodulated signal or data. The decoder 610 decodes the demodulated signal to form decoded data or a decoded signal. These functions may be shared among multiple tuners, demodulators and decoders provided within a single client terminal.

The controller 604 is in communication with the memory 612. The memory 612 is illustrated as a single box, but actually there may be a plurality of different types of memory including the hard drive, a flash drive and various other types of memory. The memory 612 may comprise other types of memory or sections of different types of memory. The memory 612 may be non-volatile memory or volatile memory.

The memory 612 may also include a digital video recorder (DVR). The digital video recorder may be a hard drive, flash drive, or other memory device. A record of the content stored in the digital video recorder, i.e. a playlist, may be stored in the DVR or a separate memory.

The user interface 614 may include a keyboard, push buttons, a touch screen, a voice activated interface or the like. The user interface 614 may be used to select a channel, select various information, change the volume, change the display appearance, or other functions. The client terminal may further comprise or be in a functional connection with a display 616 for displaying the media content.

The client terminal 600 according to the embodiments comprises a local storage for storing media as segmented transfers and a capability of receiving multiple network segments, such as DVB stream segments simultaneously. A client terminal with the storage capacity being connected to a multicast capable network segment is able to receive and store also other streams of the same media asset, which are simultaneously being transmitted on the same network segment. Thus, the efficiency and consequently the throughput of the network is significantly improved.

For detecting the private data stream for synchronisation purposes, a synchronisation compatible terminal device must be able to maintain the exact position of synchronisation packet with respect to media packets. According to an embodiment, the client terminal is arranged to buffer the media stream and the synchronisation packets within the private data stream such that the position of a synchronisation packet is linked to the corresponding (previous/next) packet in the media stream.

According to a further embodiment, upon detecting the reception of a synchronisation packet in form of a private data packet, the client terminal is arranged to decode the synchronisation packet immediately. The decoding of the synchronisation packet cannot be deferred later, because the synchronisation may change the processing of the next media packet (e.g. store/discard decision). A non-synchronisation-capable client terminal will not detect the private data stream, and therefore it will discard the synchronisation data. Because the media data is in standard MPEG-2 TS format, the terminal is capable of receiving and presenting the media as normally. A skilled man appreciates that any of the embodiments described above may be implemented as a combination with one or more of the other embodiments, unless there is explicitly or implicitly stated that certain embodiments are only alternatives to each other. The various embodiments of the invention can be implemented with the help of computer program code that resides in a memory and causes the relevant apparatuses to carry out the invention. For example, a client terminal device may comprise circuitry and electronics for handling, receiving and transmitting data, computer program code in a memory, and a processor that, when running the computer program code, causes the terminal device to carry out the features of an embodiment. Yet further, a network device may comprise circuitry and electronics for handling, receiving and transmitting data, computer program code in a memory, and a processor that, when running the computer program code, causes the network device to carry out the features of an embodiment. The various devices may be or may comprise encoders, decoders and transcoders, packetizers and depacketizers, and transmitters and receivers.

It is obvious that the present invention is not limited solely to the above- presented embodiments, but it can be modified within the scope of the appended claims.

Claims

Claims:

1. A method comprising:

receiving, in a media-on-demand system, an order from a client terminal for a media item;

determining at least one multicast in a network segment that said client terminal is receiving, said multicast comprising at least a first stream of said media item;

adjusting parameters of streams of said network segment such that a new stream can be included in the network segment; and including a second stream of said media item in the network segment, said second stream comprising at least the part of said media item from the beginning of the media item to the earliest part received from the at least first stream by the client terminal.

2. The method according to claim 1 , wherein, in response to multiple network segments transmitting said media item, the method further comprises

selecting the most preferable network segment for transmission of the second stream according to one or more of the following criteria:

- a network segment with most transmissions of said media item,

- a network segment with least transmissions of any media items,

- a network segment with least bandwidth used,

- any combination of these criteria.

3. The method according to claim 1 or 2, the method further comprising:

adjusting bit rates of the existing streams said network segment such that the second stream can be included in the network segment.

4. The method according to any preceding claim, wherein including the second stream of said media item in the network segment comprises adjusting the bandwidth of the second stream and setting a stop position of the second stream to the end-of-file.

5. The method according to any preceding claim, further comprising

communicating the adjusted parameters of the network segment to the client terminal.

6. The method according to claim 5, further comprising receiving a synchronisation report from the client terminal, the synchronisation report comprising synchronisation points of each of the streams of the network segment having said media item, the synchronisation points indication the position of the stream where the client terminal has started to store said media item; and

adjusting, on the basis of the synchronisation report, the stop positions of the started and ongoing transmissions of the said media item in the network segment to ensure that the client terminal receives the part of said media item.

7. The method according to claim 5, further comprising adjusting, on the basis of information available from the media-on-demand system and known system latencies, the stop positions of the started and ongoing transmissions of the said media item in the network segment to ensure that the client terminal receives the part of said media item.

8. The method according to any of claims 4 - 7, further comprising

in response to the second stream has been transferred until the stop position, releasing the transfer resources of the second stream from the network segment; and

adjusting the bandwidths of other streams in the network segment to reflect the reduced number of streams.

9. The method according to any preceding claim, further comprising

starting the transfer of the second stream either immediately after the parameters of the network segment have been adjusted or after a predefined delay.

10. The method according to any preceding claim, wherein the network segment comprises one or more DVB multiplexes arranged in MPEG-2 TS format, the method comprises

inserting a private data type of packet as a synchronisation packet between media stream packets at desired segmentation intervals.

1 1. The method according to claim 10, wherein the synchronisation packet comprises information related to the framing, the information including one or more the following:

- next frame number;

- previous frame number;

- total number of the frames;

- checksum of the previous frame.

12. A media-on-demand system comprising at least an order processor, a stream controller and a media streamer, wherein the order processor is arranged to receive an order from a client terminal for a media item;

the stream controller is arranged to determine at least one multicast transmitted by the media streamer in a network segment that said client terminal is receiving, said multicast comprising at least a first stream of said media item;

the stream controller is arranged to adjust parameters of streams of said network segment such that a new stream can be included in the network segment; and

the stream controller is arranged to control the media streamer to include a second stream of said media item in the network segment, said second stream comprising at least the part of said media item from the beginning of the media item to the earliest part received from the at least first stream by the client terminal r.

13. The media-on-demand system according to claim 12, wherein, in response to multiple network segments transmitting said media item, the stream controller is arranged to select the most preferable network segment for transmission of the second stream according to one or more of the following criteria:

- a network segment with most transmissions of said media item,

- a network segment with least transmissions of any media items,

- a network segment with least bandwidth used,

- any combination of these criteria.

14. The media-on-demand system according to claim 12 or 13, wherein the stream controller is arranged to adjust bit rates of the existing streams said network segment such that the second stream can be included in the network segment.

15. The media-on-demand system according to any of claims 12 - 14, wherein the stream controller is arranged to adjust the bandwidth of the second stream and set a stop position of the second stream to the end-of-file.

16. The media-on-demand system according to any preceding claim, wherein the order processor is arranged to communicate the adjusted parameters of the network segment to the client terminal.

17. The media-on-demand system according to claim 16, wherein

the order processor is arranged to receive a synchronisation report from the client terminal, the synchronisation report comprising synchronisation points of each of the streams of the network segment having said media item, the synchronisation points indication the position of the stream where the client terminal has started to store said media item; and

the stream controller is arranged to adjust, on the basis of the synchronisation report, the stop positions of the started and ongoing transmissions of the said media item in the network segment to ensure that the client terminal receives the part of said media item.

18. The media-on-demand system according to claim 16, wherein

the stream controller is arranged to adjust, on the basis of information available from the media-on-demand system and known system latencies, the stop positions of the started and ongoing transmissions of the said media item in the network segment to ensure that the client terminal receives the part of said media item.

19. The media-on-demand system according to any of claims 15 - 18, wherein

the media streamer is arranged to release, in response to the second stream has been transferred until the stop position, the transfer resources of the second stream from the network segment; and

the stream controller is arranged to adjust the bandwidths of other streams in the network segment to reflect the reduced number of streams.

20. The media-on-demand system according to any of claims 12 - 19, wherein

the stream controller is arranged to control the media streamer to start the transfer of the second stream either immediately after the parameters of the network segment have been adjusted or after a predefined delay.

21. The media-on-demand system according to any of claims 12 - 20, wherein the network segment comprises one or more DVB multiplexes arranged in MPEG-2 TS format, the stream controller is arranged to control the media streamer to insert a private data type of packet as a synchronisation packet between media stream packets at desired segmentation intervals.

22. The media-on-demand system according to claim 21 , wherein the synchronisation packet comprises information related to the framing, the information including one or more the following:

- next frame number;

- previous frame number;

- total number of the frames;

- checksum of the previous frame.

23. An apparatus comprising:

a first communication interface for communicating with an order processor of a media-on-demand system;

a memory for storing the media streams as segmented transfers.

24. The apparatus according to claim 23, wherein the apparatus is arranged to send an order for a media item to the order processor.

25. The apparatus according to claim 24, wherein upon receiving stream parameters of a network segment adjusted to the transfer the ordered media item, the apparatus is arranged to

start to listen to on-going streams of the network segment for obtaining a synchronisation point of a first stream; and

store the media item transmitted on the first stream from the position of the synchronisation point for later playback.

26 The apparatus according to claim 23, wherein the apparatus is arranged to

scan synchronisation points from all streams of the network segment containing said media item; and store the media item transmitted on each stream from the position of the found synchronisation point.

27. The apparatus according to claim 25 or 26, wherein upon having synchronised at least one stream containing said media item, the apparatus is arranged to send a synchronisation report to the order processor.

28. The apparatus according to any of claims 23 - 27, wherein the apparatus is arranged to

receive DVB multiplexes arranged in MPEG-2 TS format; and

buffer the media streams and synchronisation packets within a private data stream such that position of a synchronisation packet is linked to a corresponding packet in the media stream.

29. The apparatus according to claim 28, wherein upon detecting the reception of a synchronisation packet in form of a private data packet, the apparatus is arranged to decode the synchronisation packet immediately.

30. A computer program product, stored on a computer readable medium and executable in a data processing device, for allocating media streams in a media-on-demand system, the computer program product comprising:

a computer program code section for controlling the media streamer to include a second stream of said media item in the network segment, said second stream comprising at least the part of said media item from the beginning of the media item to the earliest part received from the at least first stream by the client terminal.