METHOD, COMPUTER PROGRAM PRODUCT AND SERVER FOR STREAMING MEDIA CONTENT FROM A SERVER TO A CLIENT

Abstract

Embodiments of the invention relate to a server for streaming media content to a client and a corresponding method and computer program product. The media content is encoded as at least one stream, wherein the stream is divided into consecutive segments. The server comprises: a receiver configured to receive a request from the client for a manifest file comprising metadata of the at least one stream; and a transmitter configured to, in response to the request for the manifest file: send the requested manifest file to the client; and push a selected segment of the consecutive segments of at the least one stream to the client.

Claims

1. Server for streaming media content to a client, wherein the media content is encoded as at least one stream, the at least one stream being divided into consecutive segments, the server comprising: a receiver configured to receive a request from the client for a manifest file comprising metadata of the at least one stream; and a transmitter configured to, in response to the request for the manifest file: send the requested manifest file to the client; and push a selected segment of the consecutive segments of at the least one stream to the client.

2. Server according to claim 1, wherein the server is configured for adaptive streaming of the media content, wherein the media content is encoded as at least two streams encoded at different bitrates, wherein the manifest file comprises metadata of the at least two streams and wherein the transmitter is configured to push a selected segment of the consecutive segments of a selected one of the at least two streams in response to the request for the manifest file.

3. Server according to claim 2, wherein the server is configured to select as the selected one of the at least two streams the stream having the lowest bitrate.

4. Server according to claim 2, wherein the server is configured to select as the selected one of the at least two streams the stream having a bitrate corresponding to a bitrate previously used by the client.

5. Server according to claim 2, wherein the server is configured to estimate a bitrate based on network parameters and further configured to select as the selected one of the at least two streams the stream having a bitrate corresponding to the estimated bitrate.

6. Server according to claim 1, wherein the server is configured for communicating with the client according to a web protocol supporting server push, wherein preferably the protocol is an HTTP protocol or SPDY protocol, more preferably HTTP 2.0 or later.

7. Server according to claim 1, wherein the transmitter is configured to push the selected segment to the client before sending the requested manifest file to the client.

8. Server according to claim 1, wherein the media content is encoded as at least one video on demand stream, the server being configured to select as the selected segment the first of the consecutive segments of the corresponding stream.

9. Server according to claim 1, wherein the media content is encoded as at least one linear stream, the server being configured to select as the selected segment a segment which precedes the most recent segment of the corresponding stream by a predetermined delay.

10. Server according to claim 9, the server being configured to set the delay according to a delay previously used by the client.

11. Server according to claim 1, wherein the transmitter is configured to push the selected segment to the client in response to the request for the manifest file if: the server is currently streaming different media content to the client than the media content corresponding to the requested manifest file; or the server is currently not streaming media content to the client.

12. Server according to claim 1, wherein the transmitter is further configured push to the client further data in response to the request for the manifest file, such as DRM data.

13. Server according to claim 1, wherein the server is configured to use different stream priorities to control the delivery sequence of pushed data and pulled data.

14. Method for streaming media content from a server to a client, wherein the media content is encoded as at least one stream, the at least one stream being divided into consecutive segments, the method comprising: receiving with the server a request from the client for a manifest file comprising metadata of the at least one stream; sending with the server the requested manifest file to the client in response to the request; and pushing from the server to the client a selected segment of the consecutive segments of the at least one stream in response to the request for the manifest file.

15. A computer program product comprising non-transitory computer-executable instructions configured to, when executed, perform the method of claim 14.

Description

BRIEF DESCRIPTION OF THE FIGURES

[0047] The accompanying drawings are used to illustrate presently preferred non-limiting exemplary embodiments of the present invention. The above and other advantages of the features and objects of the invention will become more apparent and the invention will be better understood from the following detailed description when read in conjunction with the accompanying drawings, in which:

[0048] FIG. 1 schematically shows the communication between a client and a server for starting playout of a stream according to the prior art.

[0049] FIGS. 2A and 2B schematically shows the communication between a client and a server in accordance with an embodiment of the invention, wherein in FIG. 2A the manifest file is sent before a segment is pushed and in FIG. 2B the manifest file is sent after a segment has been pushed.

[0050] FIG. 3 schematically shows an HTTP adaptive streaming client as a browser plugin in accordance with an embodiment of the invention.

[0051] FIG. 4 schematically shows an HTTP adaptive streaming client as a stand-alone application in accordance with an embodiment of the invention.

[0052] FIG. 5 shows a content distribution network delivery appliance in accordance with an embodiment of the invention.

[0053] FIG. 6 shows a flow diagram of a first embodiment of the method according to the invention.

[0054] FIG. 7 shows a flow diagram of a second embodiment of the method of the invention.

[0055] FIG. 8 shows a flow diagram of a third embodiment of the method of the invention.

[0056] FIG. 9 shows a flow diagram of a fourth embodiment of the method of the invention.

DESCRIPTION OF EMBODIMENTS

[0057] A HAS implementation (FIG. 1) comprises a server 2 and a client 4. In a conventional implementation, the client sends a request A “get manifest” to the server. The server responds by returning the manifest B to the client. The client reads the manifest B. The manifest B comprises metadata of the segments of the streams of the media content and may comprise further information, such as DRM data required for playing the media content. In particular, the manifest B comprises an index of the segments of the at least one stream encoding the media content

[0058] In the example shown, the manifest B comprises DRM data. The client requests DRM data by sending “get DRM info” request C to the server 2. The server 2 responds by sending the DRM data D1 to the client 4. It is noted that requesting DRM data and sending DRM data is optional, e.g. the media content may not be protected by DRM.

[0059] Next, the client 4 requests the first segment of the stream by sending a request E “get segment 1” to the server 2.

[0060] Subsequently, the server responds by sending a first segment F1 to the client 4. Therefore, in this conventional implementation, the process of initializing playout takes three Round Trip Times (RTTs) from time t.sub.0 when the client 4 requests the manifest file to time t.sub.1 when the client can start playout of the stream. In particular, when the client 4 is changing channels (zapping) or is otherwise initializing playout of media content, the number of RTTs leads to a noticeable delay.

[0061] In particular, in 2012 the “Conviva viewer experience report” analyzed 22.6 billion video streams in 190 countries and came to the conclusion that 19.5% of the sessions was impacted by slow video startup. The report further points out that when the start time exceeds 2 seconds, the number of people that abandon viewing increases 400% in case of video on demand (VoD) and 140% in case of linear streaming.

[0062] According to an embodiment of the invention, the client 4 sends a request A for a manifest to the server 2 (FIG. 2A). The server 2 responds by sending the manifest B to the client and also pushing the DRM data D2 and pushing the first segment F2. Therefore, only one RTT is required to start the playout of the requested stream. Again, use of DRM data is optional, e.g. the server 2 may push other data instead of DRM data or may push segment F1 only.

[0063] In a preferred embodiment (FIG. 2B), the server pushes the segment F2 in response to the request A of the client before sending the manifest file B to the client. This embodiment has the advantage that pulling of segment F2 by the client is avoided. Pushing DRM data D2 is again optional, and furthermore, the DRM data D2 may alternatively be pushed before the segment F2 is pushed.

[0064] FIG. 3 shows a server 2 and a client 4, wherein the client 4 comprises a browser 6 and a browser plugin 8 for HAS capabilities. The plugin 8 can only request manifests and segments via well-defined software interface towards the browser. In some implementations, no interface may exist for notifying the plugin 8 that an object was pushed by server 2 to the browser 6. The browser 6 will just add the object to the browser cache. When the plugin 8 later request the pushed object, the browser serves the requested object immediately from the local cache.

[0065] The plugin 8 comprises a rate determination algorithm (RDA) component 10 communicating with a client buffer 12. The client buffer is operatively connected to a playout component 14. The browser 6 comprises a browser cache. When initializing the streaming of media content, the client 4 requests a manifest file from server 2 by sending a “get manifest” request A via the RDA component 10 and browser 6 to server 2. Server 2 responds by sending the requested manifest file B to the browser 6 which delivers the manifest file to the RDA component 10. The server 2 also pushes the first segment F2 to the browser cache 16. The pushed segment 18 remains in browser cache such that it can be delivered to the plugin 8 when the RDA component 10 sends a request E to the browser for said first segment. As the pushed segment 18 is already in browser cache 16, the browser can immediately return segment F1 to the RDA component 10. After initialization, further segments are requested by the plugin 8 to the server 2 via a request G and the server responds to the request G by sending the requested segment H. Optionally, the server 2 may push additional data in response to receiving request A, e.g. DRM data.

[0066] In the embodiment shown, the browser 6 implementation does not allow an object to be pushed directly to the plugin 8 from the server 2. However, the invention is not limited to such implementations. The skilled person will appreciate that the limitations of the plug-in interfaces of browsers, such as the NPAPI interface, may not be present in all current and future browsers. For example, browsers may comprise native support for HAS, obviating the need for a HAS plugin 8.

[0067] FIG. 4 shows a server 2 and a client 4 wherein the client comprises a stand-alone application. The client is implemented as an integrated stand-alone application. Therefore, in contrast to the embodiment of FIG. 3, the RDA component 10 can be informed directly when an object is pushed by the server 2. The client 4 requests a manifest with request A, upon which the server 2 returns the manifest B and pushes the first segment F2 to the client. After initialization of the streaming, further segments are communicated by a request G by the client and a response H by the server.

[0068] FIG. 5 shows an embodiment of a content distribution network (CDN) delivery appliance 2. The CDN delivery appliance 2 comprises a HTTP server 20 which is in communication with a cache 22. HTTP server 20 is also in communication with a CDN internal communication client (CICC) 24. The CICC 24 communicates with cache 22. The HTTP server 20 is also in communication with a HAS initial push algorithm components (HIPA) which comprises a memory component 28 for storing the client state and/or session state. The CDN delivery appliance further comprises a configuration file 30 which is accessible by the HIPA. The HIPA is further in communication with the cache 22. The client node 4 comprises an HTTP client 32. The HTTP server component 20 takes care of the HTTP communication with the client. The HTTP server 20 receives get requests from the client. The HTTP server 20 performs a check to verify if the requested manifest/segment is already present in the cache 22. If present, it will provide the manifest/segment to the client. If not present, it will inform the CDN internal communication client to fetch the segment/manifest from an upstream CDN node. In case the manifest/segment was not found in cache 22, the CICC fetches the manifest/segment from an upstream CDN node. When the CICC obtains the requested manifest/segment completely or partially, it informs the HTTP server 20. The HTTP server will then take care of the transfer to the client 4 via HTTP client 32.

[0069] Each time when an HTTP request or a response is received by the HTTP server, a functional block called HAS initial push algorithms (HIPA) will be informed. HIPA 26 will disregard all requests/responses that are not HAS related. It will then use one or more algorithms to decide if and what additional manifests/segments must be pushed to the requesting client. It instructs the HTTP server to deliver the additional objects via server push. Finally, the HTTP server will push the initial objects to the client.

[0070] The one or more algorithms for determining the additional data to be pushed may use the configuration file 30 which expresses the relationship between a manifest, related DRM-objects, corresponding initial segment, etc. Furthermore, the one or more algorithms may comprise determining the segment to be pushed, i.e. select the desired bitrate of the first segment. For example, the quality of the stream may be selected as the lowest available quality as described in the requested manifest file. In another example, the quality is selected on the basis of a quality previously used by the client 2. The server 4 may track a client state or a session state, tracking the quality, i.e. bitrate, previously send to individual clients. In another example, the stream quality is selected on the basis of certain network parameters, such as latency and througput.

[0071] A first embodiment of the method of the invention comprises receiving a request for a manifest by a server S102 (FIG. 6). Subsequently, the server returns the requested manifest S104.

[0072] Furthermore, the server pushes the first segment of the stream associated by the manifest file S106. It is noted that the order of steps S104 and S106 may be interchanged.

[0073] In a second embodiment of a method of the invention (FIG. 7), the server receives a request for a manifest 5102 and in response sends the requested manifest S104. In addition to pushing the first segment of the stream corresponding to the requested manifest S106, the server pushes further data related to the stream S108. For example, the further data may comprise DRM data. It is noted that the order of the steps S104, S106, S108 can be in a different order than shown in the figure.

[0074] In a third embodiment of the method of the invention (FIG. 8) the server receives a get request from the client in step S110. In step S112 the server handles the received request. For example, if the request is a request for a manifest file, the server returns the requested manifest file. In step S114 the server determines if the get request is HAS related. If the get request is indeed HAS related, the server determines if a segment must be pushed in step S116. If the server determines that a segment must be pushed in response to the get request, the server pushes the segment in step S118. It is noted that step S112 may alternatively be performed after segment is pushed.

[0075] In a fourth embodiment of the method of the invention (FIG. 9) the server receives a request in step S110. The server verifies if the requested manifest/segment is present in the cache of the server in step S112A if the manifest/segment is present in cache, the server sends the requested manifest/segment in step S112B. Otherwise, the server fetches the manifest/segment from an upstream node in step S112C. Further steps S114/S118 correspond to those in FIG. 8.

[0076] A person skilled in the art would readily recognize that steps of various above-described methods can be performed by programmed computers and/or electronic devices with computation capabilities. Herein, some embodiments are also intended to cover program storage devices, e.g., digital data storage media, which are machine or computer readable and encode machine-executable or computer-executable programs of instructions, wherein said instructions perform some or all of the steps of said above-described methods. The program storage devices may be, e.g., digital memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media. The embodiments are also intended to cover computers and/or electronic devices with computation capabilities (where hard coded or soft coded) programmed to perform said steps of the above-described methods. The functions of the various elements shown in the figures, including any functional blocks may be provided through the use of dedicated hardware as well as hardware capable of executing software in association with appropriate software. Hardware and may include, without limitation, digital signal processor (DSP) hardware, application specific integrated circuit (ASIC), field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), and non volatile storage. Other hardware, conventional and/or custom, may also be included. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic.

[0077] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative circuitry embodying the principles of the invention. Similarly, it will be appreciated that any flow charts, flow diagrams, represent various processes which may be substantially represented in computer readable medium and so executed by a computer or processor, whether or not such computer or processor is explicitly shown.

[0078] Whilst the principles of the invention have been set out above in connection with specific embodiments, it is to be understood that this description is merely made by way of example and not as a limitation of the scope of protection which is determined by the appended claims.