WO2013139804A1

WO2013139804A1 - Fast channel change algorithm

Info

Publication number: WO2013139804A1
Application number: PCT/EP2013/055721
Authority: WO
Inventors: George MIKELADZE; Davit MISHELASHVILI; Levan NATROSHVILI
Original assignee: Qarva Ltd.
Priority date: 2012-03-20
Filing date: 2013-03-19
Publication date: 2013-09-26
Also published as: GB2500406A; GB201204874D0

Abstract

A method for initiating streaming media delivery over a network from a server to a client, comprising the steps of determination of the technical environment and network connection parameters of the client through the client, a client issuing a command to server to initiate streaming media delivery including a channel ID and stream position, and a server receiving the initiate delivery command and starting burst transmission of media according to channel ID and stream position.

Description

Titel: Fast channel change algorithm

[0001] This present application is directed at a method and a system for streaming media from a media server to client modules according to the preambles of the independent claims.

[0002] Traditional systems for delivering broadcast media to the consumer rely on the use of a physical tuner in a client module, for example in the form of a television set that tunes to and receives the media information. In such a model, a user can quickly change channels, resulting in a real time transition from one program to another, so that the user does not perceive a delay in the presentation of a new program upon tuning to a new program. However, this simple manner of operation does not work for streaming digital media information over a network as is the case for example in IPTV environments. In such environments, the client module, which can be either a set top box or a software module, has to buffer a certain amount of media information before it can begin playing the media information to the consumer. Buffering, however, requires a certain amount of time when the user first connects to a stream of media information. Furthermore, digital media information is commonly expressed as a series of key frames (e.g., I frames) and difference frames (e.g., B and P frames). Accordingly, a client module must wait for a key frame before it can begin presenting the media information to the consumer, resulting in a noticeable lag prior to the presentation of programs as the user switches from one channel to another.

[0003] Over time various methods were developed to reduce the effects of the problem in media streaming environments described above. According to these methods, the server infrastructure delivers an initial burst of media information, which feeds a large quantity of media information to the client module via a communication channel, enabling it to begin presentation of the media information on an expedited basis. After this initial burst, the server infrastructure delivers the media information to the client module at a regular data rate.

[0004] Generally, these methods including the bursts of media information are very demanding as regards required communication channels beyond that required to transmit the media information at its normal steady-state rate. This problem may be addressed by allocating extra bandwidth to implement the methods. However, many environments allocate a limited amount of bandwidth to the communication channels, which posts additional problems, so that the methods mentioned above have the potential of overburdening such a communication channel, particularly when multiple users in a household are consuming media information at the same time.

[0005] Other environments that are rate-limited may allocate a relatively large amount of bandwidth to the channels, thus reducing the potential of over-saturating the available channels.

[0006] A method to make such systems less costly, less error prone, and more efficient was disclosed in US 2009/0077255 Al to Microsoft Corp. which is included herein by reference.

[0007] What is described in this document is a method for delivering resource information to a client module, the method comprising the steps of delivering the resource information, using a first delivery technique, at above-nominal data rate levels during an initial burst period of data transmission to the client module; delivering the resource information at join interval data rate levels during a join interval following the burst period, wherein, following the join interval, the client module switches to a second delivery technique for providing the resource information; and responding to requests from the client module to supply parts of the resource information which the client module potentially missed during the join interval as a result of its receipt of the resource information at the join interval data rate levels.

[0008] The method described in this document has a number of advantages over prior methods. However, time has shown that there still is room for improvement. In particular, in the method as described in US 2009/0077255 Al , it is a server that is driving the process, i.e. the server takes all the decisions regarding parameters like burst length and speed, non-burst length and speed, moment of joining multicast, filling of pre-multicast period by some unicast or not filling, etc. while the client just executes commands given by Server.

[0009] The disadvantage of this approach is that all the actual information regarding the environment of the client, such as connection speed, signal quality, etc. remains unconsidered. If, for example, a Multicast Join command is issued by a client to the network, this command is executed with a very long delay, i.e. more than 10 seconds. In this case, a method as described in US 2009/0077255 Al would have little or no positive effect, as the server delivering the media content cannot know what is happening at the client's side. As a result a user might experience problems while watching or switching to a particular channel, as after the burst was played, the video will stop as Multicast has not actually been joined and the respective media stream has not arrived at the client yet.

[0010] This means that either very strict requirements for network quality would have to be imposed, or a user would have problems watching TV over the network.

[001 1] Furthermore, if some problems occur in some small part of the network regarding Multicast, users would have problems watching TV.

[0012] As a quick solution to this problem, one could substantially increase the burst period to values of one minute or two. This would not help in all cases, however, and, what is even more important, would increase the load on the network just as much, as bursting and unicast in general generate heavy loads on a network.

[0013] Considering all of the above, there is a clear need for a method and/or system that overcomes the disadvantages as described above.

[0014] Accordingly, an approach is proposed in which the client is the driving component and takes all the decisions regarding the time to Join Multicast, Burst, etc., while the Server just executes the commands issued by Client. According to this approach, and as a client knows its own environment such as connection speed and quality, and sees what is happening during the process of changing channels, a respective client may, for example, stay on Unicast forever, if the network experiences problems with Multicast, which leads to a much better user experience, since networks are used based on actual availability and capabilities instead of virtual server demand.

[0015] More specifically what is proposed is a method for initiating streaming media delivery over a network from a server to a client, comprising the steps of determination of the technical environment and network connection parameters of the client through the client, the client then issuing a command to the server to initiate streaming media delivery including a channel ID and stream position, and the server receiving the initiate delivery command and starting burst transmission of media according to channel ID and stream position. According to this method, it is the client that is in the driver's seat and taking all the decisions regarding when to start a stream and how to deliver the stream, taking into account all the environmental parameters of the client, in order to use the available resources to its fullest, but also considering its limitations. [0016] In case that the server and the client are within a TCP network, it is necessary that before the client issues the command to initiate streaming media delivery, the additional steps of the client sending a connect request to the server, and the server accepting the connect request are performed.

[0017] Preferably, there is an additional step of the server terminating the burst transmission after a defined time, and continuing streaming at a nominal bit rate, while circular buffers may be used in the server to store the stream.

[0018] According to another preferred embodiment of the invention, the step of determining the technical environment includes calculating an offset, and a delay before joining multicast based at least upon one of channel bit rate, line bandwidth, and/or buffer size.

[0019] The initial stream that is transmitted from the server to the client preferably is a unicast stream, wherein the client performs the additional step of determining whether a media stream is being received. Upon determination that the client does not receive a unicast stream, the client may issue a multicast join request in order to overcome the lack of unicast media stream.

[0020] On the other hand, if the client does receive a unicast stream, it may wait for the delay to join multicast to end, and, upon reaching the end of the delay, issue a multicast join request to the server just as well, wherein until the first multicast packet arrives, the client receives the unicast stream, and upon arrival of the first multicast packet, stops receipt of the unicast stream.

[0021] To stop the unicast stream, the client may either issue a stop unicast command to the server, or, in the case of a TCP network, simply close the connection to the server.

[0022] Upon accomplishment of unicast to multicast transition, the client may perform another step of determining the existence of lost packets, or holes, in the multicast stream. Additionally, even during receipt of the multicast stream the client may continuously determine the existence of lost packets, or holes, in the multicast stream.

[0023] In both cases and upon determination that lost packets exist, the client can send a request to the server to retransmit any lost packets, in order to fill the holes in the multicast stream.

[0024] Furthermore, if the client upon determines that the multicast stream stops for longer than a predefined time interval, the client may perform the step of sending a request to the server to reinitiate unicast streaming, which in essence will lead to a restart of the entire method as described above.

[0025] Further features and advantages may be taken from the following merely illustrative and in no way limiting description of a preferred embodiment of the invention with reference to the enclosed figures, showing:

[0026] Fig. 1 a flowchart, showing the server side of the method;

[0027] Fig. 2 a flowchart, showing the client side of the method;

[0028] Fig. 3 a diagram to visualize the amount of data transmitted according to the invention.

[0029] According to Fig. 3 and for the sake of this description of a preferred embodiment of the invention, the following parameter calculations are used:

[0030] T - is the current time.

[0031] I - is the interval (offset) from where to start receiving the media stream. This interval is calculated by the client, and depends upon on number of technical environment parameters of the client, such as but limited to line bandwidth, channel bit rate, buffer size, etc.. There may be many variations of calculating the I parameter. One basic formula, in which I is measured using bytes, is the following:

I = minimal amount + total buffer size * fetch multiplier + reserved amount wherein minimal_amount is a minimal required amount to be prefetched, total buffer size is the sum of sizes of all buffers involved in the receive/recovery/play system, that may cause a delay before the media stream reaches video/audio decoder module of the client, and fetch multiplier is a parameter that describes how intensive the stream data prefetch is. This parameter may depend on many factors, in example it may differ for CBR (constant bit-rate) and VBR (variable bit rate) streams, because VBR streams may require more data to be prefetched due to its unsteady nature. In some examples there may be found an optimal fetch_multiplier of about 1.3-1.5 for CBR streams, and 1.8-2.0 for VBR streams. But this may be different for other examples.

[0032] Furthermore, reserved_amount is an additional parameter that makes systems more stable, as there may be instability of line bandwidth, or other factors that may cause temporary problems. Essentially, reserved_amount is a certain amount of prefetched additional data to save buffers from running empty if something goes wrong at a later point in time.

[0033] OptimalTransitionTime - is the delay before joining multicast, calculated by the client, depending upon channel bitrate, line bandwidth, buffer size, or other parameters. There may be many variations of calculating the OptimalTransitionTime parameter, but for the sake of this description may be calculated as:

OptimalTransitionTime = ((I x 8) / ((1 + E) x Nominal)) + reserved_delay wherein the parameter I is expressed in bytes in this formula and OptimalTransitionTime in seconds, wherein (1 + E) x Nominal is equal to line bandwidth in bits per second, and reserved_delay is the additional delay in seconds that makes the system more stable when line bandwidth is unstable. [0034] I and (T - I) position parameters in the actual implementation may be measured by time units (seconds, milliseconds, etc.), or by information unit (bits, bytes, etc.)

[0035] Referring now to Fig. 1 the method as seen from the server side is described, wherein both the server and the client are located within a network in which a connection oriented protocol such as TCP is used.

[0036] In a first step 2, the server accepts the connection from client. In other networks using other protocols as a connection oriented protocol, establishing a connection may not be necessary.

[0037] In a second step 4, the server receives a command from client, the command containing information about the channel ID, and the stream position from where to start burst at T - 1.

[0038] In the following step 6, the server starts streaming the burst at (1 + E) x Nominal, whereas in the following step 8, after the burst is over, the server continues streaming at a nominal bitrate, i.e. in live mode. This transition is performed without interruption, over the same unicast channel, wherein the server may use circular buffers to store the channel stream. Furthermore, the transition from burst mode to live mode is done in a natural way without any additional enforcement. [0039] If and when at step 10 the server receives from the client the command to stop streaming or when the client closes the connection (if any), the server stops transmitting the stream and closes the connection channel (if any) from his side as well at step 12.

[0040] Otherwise the server will continue streaming in "live mode" at a nominal bitrate forever, or it may stop transmitting the stream after some predefined time interval has passed, or a traffic limit was reached.

[0041] Turning now to Fig. 2, a preferred embodiment of the method is described from the client side.

[0042] At step 14, the client establishes a connection to the server (again in case that a connection oriented protocol like TCP is used, otherwise the step of establishing connection may not be necessary).

[0043] In the following step 16, the client calculates the offset I according to the instructions above, as well as the OptimalTransitionTime, i.e. the delay before joining multicast.

[0044] In the following step 18, the client sends a command to the server that contains information about the channel ID and the stream position from where to start burst at time T - I.

[0045] The client starts receiving a unicast stream, and optionally fills buffers, starts playing, etc., in step 20.

[0046] In step 22 the client determines, whether there is any problem in establishing connection to the server, whether the server is unable to execute the command received from the client according to step 18, or whether the client does not receive the unicast stream for any reason. If there is a problem of this kind, the client proceeds to the next step 22, according to which it will try to use multicast functionality without the initial unicast burst by immediately going to step 26 and issuing a join multicast request. If no problems can be detected by the client, the method proceeds to step 24, with the client waiting for the OptimalTransitionTime, while still receiving a unicast stream and playing.

[0047] If the OptimalTransitionTime is over, the method proceeds to step 26, with the client issuing a multicast join request, while the client still receives a unicast stream and plays to the user according to step 28.

[0048] According to step 30, the client determines, whether any multicast packets start arriving. If no multicast packets arrive, the client will still continue receiving a unicast stream and playing, which may happen when the network multicast functionality is down or is experiencing any problems.

[0049] If first multicast packets arrive, the client will stop receiving the unicast stream according to step 32 either by issuing an appropriate command to the server, or by simply closing the connection (if any).

[0050] According to step 34, the client receives a multicast stream and plays the media to the user.

[0051] In another step 36 the client checks if there were any "holes", i.e. lost packets in the stream when accomplishing unicast to multicast transition. If this is the case, the client will ask the server to retransmit any lost packets to fill the "holes". During the multicast stream reception client may ask the server to retransmit lost packets (if any).

[0052] According to step 38, if the multicast stream stops for longer than some predefined time interval, the client may decide to switch to the unicast stream. To do so the method returns to the step 1.

Claims

Method for initiating streaming media delivery over a network from a server to a client, comprising the steps of:

Determination of the technical environment and network connection parameters of the client through the client,

Client issuing a command to server to initiate streaming media delivery including a channel ID and stream position,

Server receiving the initiate delivery command and starting burst transmission of media according to channel ID and stream position.

Method according to claim 1, wherein, before the client issues the command to initiate streaming media delivery, the additional steps of the client sending a connect request to the server, and the server accepting the connect request are performed.

Method according to claim 1 or 2, comprising the additional step of the server terminating the burst transmission after a defined time, and continuing streaming at a nominal bit rate.

Method according to any of the preceding claims, wherein circular buffers are used in the server to store the stream.

Method according to any of the preceding claims, wherein the step of determining the technical environment includes calculating an offset, and a delay before joining multicast based at least upon one of channel bit rate, line bandwidth, and/or buffer size.

Method according to any of the preceding claims, wherein the initial stream that is transmitted from the server to the client is a unicast stream. Method according to any of the preceding claims, wherein the additional step of determining whether a media stream is being received by the client is performed.

Method according to claim 7, wherein upon determination that the client does not receive a unicast stream, the client issues a multicast join request.

Method according to claim 7, wherein upon determination that the client does receive a unicast stream, the client waits for the delay to join multicast, and, upon reaching the delay, issues a multicast join request to the server.

Method according to claim 9, wherein until the first multicast packet arrives, the client receives the unicast stream.

Method according to claim 10, wherein upon arrival of the first multicast packet, the client stops receipt of the unicast stream.

Method according to claim 11 , wherein the client in stopping receipt of the unicast tream issues a stop unicast command to the server.

Method according to claim 11 , wherein the client in stopping receipt of the unicast stream closes the connection to the server.

Method according to any of claims 1 1 to 13, wherein the client, upon accomplishment of unicast to multicast transition, performs the step of determining the existence of lost packets in the multicast stream.

Method according to any of claims 1 1 to 13, wherein during receipt of the multicast stream the client continuously determines the existence of lost packets in the multicast stream.

16. Method according to claim 14 or 15, wherein the client upon determination that lost packets exist, sends a request to the server to retransmit any lost packets. -l i- iy. Method according to claim 14 or 15, wherein the client upon determination that the multicast stream stops for longer than a predefined time interval additionally performs the step of sending a request to the server to reinitiate unicast streaming.