GB2500406A

GB2500406A - Providing rapid channel changes, with client itself assessing technical environment and network connection parameters

Info

Publication number: GB2500406A
Application number: GB1204874.0A
Authority: GB
Inventors: George Mikeladze; Davit Mishelashvili; Levan Natroshvili
Original assignee: QARVA Ltd
Current assignee: QARVA Ltd
Priority date: 2012-03-20
Filing date: 2012-03-20
Publication date: 2013-09-25
Also published as: WO2013139804A1; GB201204874D0

Abstract

A method for initiating streaming media (AV content) delivery over a network from a server to a client (terminal) comprises the steps of: determination of the technical environment 16 (e.g., calculating an offset, and a delay before joining a multicast based on channel bit rate, line bandwidth and/or buffer size) and network connection parameters of the client through the client (itself); the client issuing 18 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 (high rate) transmission of media according to the channel ID and stream position. The client may also send a connect request to the server. Burst transmission may be terminated after a defined time, with streaming continuing at a nominal bitrate; circular buffers in the server may store the stream. Initially, a unicast stream may be transmitted; if it is determined that the client does not receive the unicast stream, a multicast join request can be issued. Lost packet re-transmission may be initiated. The method is applied to providing fast channel changes (FCC) in networked IPTV environments.

Description

Title: 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 IPTY environments. In such environments, the client Is 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., T 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 Is 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 qualify, etc. remains unconsidered. If, for example, a Multicast Join command is issued by a clicnt to thc network, this command is cxccutcd with a vcry long delay, i.e. more than 10 seconds. In this ease, a method as described inUS 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 cxpcrienee 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 rcspcctivc 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.

[0011] Furthermore, if somc 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, Is however, and, what is even more important, would increase the load on the network just as much, as bursting and unicast in general gcncratc 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 thc 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 cnvironmcnt 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 dcmand.

[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 drivers 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 usc the available resources to its thllest, 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 ofunicast 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 multieast stream stops for longer than a predefincd time interval, the client may perform the step of sending a request to the server to reinitiate unieast 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 eakulations are used: [0030] T -is the current time.

[00311 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 paramctcr that dcscribcs how intcnsivc thc strcam data prcfctch is. This paramctcr 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 bc prcfctchcd due to its unsteady nature. In some examples thcrc 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 makcs 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 savc 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) / ((I + F) x Nominal)) + reserved delay whcrcin thc paramctcr I is cxprcsscd in bytcs 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 morc stable when line bandwidth is unstablc.

[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, ctc.) [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 nctworks using othcr protocols as a connection oricntcd protocol, cstablishing a connection may not be necessary.

[0037] In a second step 4, the server receives a command from client, the command containing information about thc channel ID, and the stream position from where to start burst at T -I. [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 rcccived 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 unieast 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 multieast functionality is down or is experiencing any problems.

[0049] If first multicast packets arrive, the client will stop receiving the unieast 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 multieast stream reception client may ask the sewer to retransmit lost packets (if any).

[0052] According to step 38, if the multieast 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

Claims 1. 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.
2. 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.
3. Method according to claim I 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.
4. Method according to any of the preceding claims, wherein circular buffers are used in the server to store the stream.
5. 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.
6. 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.
7. Method according to any of the preceding claims, wherein the additional step of determining whether a media stream is bcing received by thc client is performed.
8. Method according to claim 7, wherein upon determination that the client does not receive a unicast stream, the client issues a multicast join request.
9. Method according to claim 7, wherein upon determination that the client does rcceive a unicast stream, thc clicnt waits for the delay to join multicast, and, upon reaching the delay, issues a multicast join request to the server.
10. Method according to claim 9, wherein until thc first multicast packct arrives, the client receives the unicast stream.
11. Method according to claim 10, wherein upon arrival of the first multicast packet, is the client stops receipt of the unieast stream.
12. Method according to claim II, wherein the client in stopping receipt of the unicast stream issues a stop unicast command to the server.
13. Method according to claim 11, wherein the client in stopping receipt of the unicast stream closes the connection to the server.
14. Method according to any of claims 11 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.
15. Method according to any of claims 11 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.
17. Method according to claim 14 or 15, wherein the client upon dctcmiination that thc multicast stream stops for longer than a predetined time interval additionally performs the step of sending a request to the server to reinitiate unicast streaming.