Patent Application
20130185759
The invention relates to a method for providing video chunks to a client entity using a request-response protocol, each video chunk being available at a server entity as a plurality of encoded video chunks encoded according to respective quality levels said method including the steps of:
For efficient delivery of video files over the Internet, real-time protocols such as RTP (Real-time Transport Protocol) and UDP (User Diagram Protocol) have been developed. Due to the availability Content Delivery Networks (CDNs) with HTTP caching nodes for popular web pages, the familiarity of webpage developers with HTTP technology, and the more easy firewall traversal of HTTP/TCP since firewalls are configured to pass websites that are accessed through the web browser, there is a tendency to use non real-time protocols such as HTTP/TCP increasingly for delivery of video files over the Internet. There exist different categories of solutions for delivering video files over the Internet via non real-time protocols such as HTTP/TCP. One of them is adaptive streaming. HTTP adaptive streaming (HAS), known for instance from the “HTTP-Based Adapting Streaming” part of the “IIS Smooth Streaming Technical Overview” by Alex Zambelli (Microsoft Silverlight).
HAS relies on the availability at a server or at an intermediate or caching element of video files in different qualities and segmented time slots, also called chunks, of for instance 2 seconds duration.
Time segments of different qualities can be combined when viewing the video. HTTP adaptive streaming enables the client entity to view the video in the highest quality estimated possible, and to request lower quality segments when the available bandwidth in the network is insufficient, or at start-up of a new video in order to enable quick start through downloading initial segments of lower quality. Typically, the client entity shall try to keep its buffer filled to a certain level, e.g. 20 to 30 seconds playback time. When the buffer depletes, the client starts requesting lower quality segments of the video file in order to fill up the buffer more quickly and avoid freezing of the video.
Since the choice of the quality level influences the required bandwidth to download the corresponding encoded chunks, sudden fluctuations in the available network bandwidth are challenging for the selection of the chunk quality. In case a number of subsequent chunks can be downloaded at a high speed, it can be decided to go to a higher video quality level and as long as chunks can be transferred quickly, it will be decided to further increase the quality level for the viewer. If the bandwidth suddenly drops, the high-quality chunk that is at that moment downloaded must be finished completely at the lower bandwidth. This has a severe impact on the filling level of the buffer at the client entity that stores the chunks before displaying them to a client's user. This can even lead to complete buffer starvation, resulting in a video freeze for the viewer.
Bandwidth fluctuations can have several causes such as:
At any time, a balance has to be found when selecting a quality level. If the selection is adapted too quickly, this will result in a lot of unnecessary quality variations which can be disturbing for the viewer. If the decision taking is not reactive enough, this will result in a more constant display quality at the risk of invoking a buffer under-run.
Because it is not possible on the client side to make solid predictions in case of strong bandwidth fluctuations, the achieved quality is sub-optimal. On top, there is a risk for buffer starvation.
It is an object of the invention to overcome the above shortcomings of the known method.
In this way, instead of following a pure ‘trial and error/recovery’ style of prediction of the optimal quality level, the additional information received from the server entity enables the client (within some margin of accuracy) to ‘calculate’ the highest quality level that can be achieved without causing a buffer under-run.
An additional feature of an embodiment of the method according to the invention is that said server entity sends said additional information upon request from said client entity. In this way the client entity determines the timing and frequency of the quality selection.
Another additional feature of an embodiment of the method according to the invention is that said additional information is sent together with said information on said quality levels. In this way the above additional feature is realized whilst in the same time limiting the number of transfers of information.
Still another additional feature of an embodiment of the method according to the invention is that said server entity sends said additional information whenever a predetermined relevant change in said transfer time occurs. In this way, in a system where the additional information is provided upon request from the client entity, this client entity will be made aware of relevant changes in the transfer time occuring between two information requests.
Another additional feature of an embodiment of the method according to the invention is that communication between said server entity and said client entity is performed via an intermediate network element and that said method includes the additional step of said intermediate network element updating said additional information to take into account local information available at said intermediate network element such as, but not limited to possibly cached chunks or transfer time needed to transfer video chunks from said intermediate network element to said client entity or profile information of said client entity or any combination thereof.
Intermediate network elements could influence the transfer time of the chunks. F.i. caches could reduce that estimated transfer time. Also, the bandwidth available to or needed by a client can be dependent on the client's profile f.i. on its subscription agreement or on its viewing behavior respectively. This additional feature makes it possible to inform the client entity thereof.
The invention also relates to a server entity, to a client entity and to an intermediate network entity realizing the method according to the invention.
Embodiments of a server entity, of a client entity and of an intermediate network element realizing the present invention are hereafter described, by way of example only, and with reference to the accompanying FIGURE that represents a network where a server entity S communicates with a client entity C via the Web either directly or via an intermediate network element IN. S also communicates with a Network management module NM.
For the sake of clarity the web connections between S, NM, IN and C are represented by single lines.
S contains a server storage entity SSTE, a server receiving entity SRE, a server sending entity SSE, a server processing entity SPE and a server manager SM.
S uses the Hypertext Transfer Protocol (HTTP) to provide video streams to C either directly or via IN that acts as a caching entity. The video source is cut in chunks of typically 2 to 4 seconds long that are encoded using the desired delivery code format. How this is done is not described in detail as it is not the subject of this invention. The coding can be done by S or by an external encoder. The chunks are stored in S by SSTE and are delivered by means of adaptive streaming. To this end the chunks are encoded using different bit rates corresponding to different quality levels.
IN contains a receiving part INRE, a processing part INPE, a sending part INSE and a storage part INSE. It functions as caching element for video chunks to be sent to C to reduce the transmission time of these chunks and to reduce the load on the network.
C contains a receiving part CRE, a sending part CSE and a processing part CPE.
In order to have video chunks sent to it, C, or more specifically CSE in C, in a first instance sends a request to S to get information on the available quality levels this is a so called manifest request. In the shown embodiment this request is sent directly to S, but this can equally well be done via IN.
S receives this request via SRE and transmits it to SPE. SPE is adapted to retrieve the information on the available quality levels from S STE. SM Is adapted to obtain from a network manager module NM via the network, bandwidth related information on parameters that can influence the time needed to transfer video chunks to C, such as network load and bandwidth reserved for C. This information is forwarded to SPE that is adapted to evaluate this transfer time based on the bandwidth related information, on the size of the available chunks and on local information such as the load of the server. For the calculation following formula is used in the considered implementation, but other formulas can be used as well:
(t=BW/s+RTT+Ts)
with t=estimated transfer time, BW=bandwidth available from server to client, s=size of the segment, RTT=round trip time (client-server-client), Ts=processing time needed by the server to handle the request. Information on t is then, together with the information on the available quality levels, sent to SSE in the form of a so called manifest message, for transmission to C. This transmission is done via IN. IN receives the message in INRE that transmits it to INPE where the information on the evaluated transfer time in the manifest message is possibly adapted based on what chunks are cached by IN, on the quality levels available in IN and on how this availability near to C can influence the transfer time. In the considered embodiment IN modifies the time to
tu=BWI/s+RTTI+TsI
if the chunk is available in the cache,
with tu=updated estimated transfer time, BWI=bandwidth available from IN to client, s=size of the segment, RTTI=round trip time (client-IN-client), TsI=processing time needed by the IN to handle the request. Again in alternative embodiments other formulas could be used as well. The updated manifest message is then forwarded to INSE for transmission to C.
It has to be noted that in the considered embodiment IN is a caching unit. In an alternative embodiment IN can however also be an access node such as a DSLAM node. In this case the evaluated download time is adapted in function of the type of access link (ADSL, VDSL, fiber . . . ).
C receives the manifest message via CSE that passes it on to CPE. CPE uses the estimated download times and the locally available information on the size of its local buffers (not shown in the FIGURE) that are used to buffer the chunks before displaying them to a user (also not shown) to calculate the highest quality level that can be achieved for the transfer without causing a buffer over/under-run. Information on this calculated quality level is inserted in a chunk request message that is forwarded to CRE for transfer to S via IN, in order to obtain video chunks with the requested quality level. This request is then handled either by IN if the requested chunks are cached or is forwarded to S by IN if they are not available at IN and the requested chunks are sent to C.
C periodically sends out such manifest requests in order to become aware of changes in the evaluated transfer time due to changes in the network or in S, such as fluctuations of the network load, changes in the caching conditions, changes in the load of S.
In addition, SPE in S periodically checks via SM if there are no sudden changes in the network conditions that could have a relevant impact on the evaluated transfer time. If they occur the evaluated transfer time is recalculated and a new manifest message is sent to C. In alternative embodiments this checking is done by SM, or triggers are received from the network whenever changes in the network conditions occur.
How the video chunks are encoded and decoded and how they are streamed to the user is not described herein since this is not the subject of the invention.
Also, the implementation of the functional blocks in S, IN and C is not described in details as this implementation should be quite straightforward for a person skilled in the art based on the above functional descriptions.
In addition it should be noted that the described functions may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared. Other hardware, conventional and/or custom, may also be included.
The above description and drawing merely illustrate the principles of the invention. It will thus be appreciated that, based on this description, those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within its spirit and scope. Furthermore, the examples recited herein are principally intended expressly to be only for pedagogical purposes to aid the reader in understanding the principles of the invention and the concepts contributed by the inventor(s) to furthering the art, and are to be construed as being without limitation to such specifically recited example and conditions and all statements herein reciting principles, aspects, and embodiments of the invention, as well as specific example thereof, are intended to encompass equivalents thereof.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10305816.0 | Jul 2010 | EP | regional |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/EP11/62765 | 7/25/2011 | WO | 00 | 4/3/2013 |
