Abstract:
Media streaming is more efficient in terms of transmission bitrate consumption, transmission latency and/or fair trade of transmission capacity among several by pushing media content rather than the client pulling media content from the server. Pushing media content to the client at a varying bitrate enables to shift, at least partially, the control over the streaming from the client towards the server. The server may continue to push segments of the media content to the client even without receiving explicit queries or directives for these segments thereby reducing upstream bandwidth consumption. As far as the bitrate adaption is concerned, the server may act as a slave remotely controlled by the client in that media content is pushed at a bitrate depending on the client&#39;s most recently sent information such as reception situation information explicitly indicating the bitrate to be used.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of copending International Application No. PCT/EP2015/055290, filed Mar. 13, 2015, which is incorporated herein by reference in its entirety, and additionally claims priority from U.S. Application No. 61/954,063, filed Mar. 17, 2014, which is incorporated herein by reference in its entirety. 
     
    
       [0002]    The present application is concerned with streaming of media data such as video and/or audio signals. 
       BACKGROUND OF THE INVENTION 
       [0003]    Media streaming technology allows people to watch video or hear an audio signal via a client operating on a person&#39;s desktop, mobile phone, computer or the like. During streaming, only a small portion of the media data is sent to the client device at a time. These portions may be called temporal segments or chunks. In case of bitrate adaptive streaming, the bitrate at which the media data is transmitted to the client&#39;s device is varied in order to account for the varying transmission and reception conditions including, for instance, the available transmission bandwidth, the buffer fullness at the client and so forth. 
         [0004]    Dynamic adaptive streaming over HTTP (DASH) is a popular adaptive bitrate streaming technique for high quality streaming of multimedia content over the internet. DASH streaming typically partitions media content into a sequence of small temporal segments with each such temporal segment containing a portion of the media content in a short interval of playback time. Typically, the content is made available with a media presentation description (MPD) file or manifest which describes information concerning the temporal segments such as timing, URL, media characteristics such as video resolution and bitrates and so forth. One or more versions/representations of the temporal segments of the media content are typically available, the versions differing in bitrate, resolution or other factors, and a selection can be made, typically automatically, based on network conditions, device capabilities and user preference, thereby enabling adaptive streaming. For example, generally when content is played by a DASH client, the client automatically selects from the available segments the next segment to download with the highest bitrate possible that can be downloaded in time for playback without causing pauses or rebuffering events in the playback. 
         [0005]    However, media streaming techniques such as DASH do not address all needs imposed by current network environments. As the bitrate adaptivity is driven by the clients, the communication overhead between server and client puts strain on the transmission network in terms of uplink transmission bandwidth consumption to the server and aspects such as fair assignment of available downlink transmission bandwidth capacity to several clients is difficult to realize. Accordingly, it is an object of the present invention to provide a concept for media streaming which is more efficient in terms of, for example, transmission bandwidth consumption, latency issues and/or fair trade of bandwidth capacities among several clients. 
       SUMMARY 
       [0006]    According to an embodiment, a server for streaming media content may have a reception interface configured to receive a query from a client, the query concerning the media content; a sending interface configured to push the media content to the client using a server-push technology of a network protocol at varying bitrate in units of temporal segments of the media content, wherein the sending interface is configured to push the temporal segments at varying bitrate to the client, wherein the reception interface is configured to intermittently receive reception situation updates from the client, the reception situation updates updating a description of a reception situation of the client, wherein the server has access to the media content in units of temporal segments and to each temporal segment at different bitrates belonging to different versions of the media content, wherein the server has access to a manifest describing versions at which media content is accessible for the server and a bitrate of the versions, and wherein the server is configured to derive from the manifest a bitrate adaptation to be applied by the server so as to adapt the bitrate at which the media content is to be pushed to the reception situation updates from the client. 
         [0007]    According to another embodiment, a client for receiving a media content streamed by a server may have a sending interface configured to send a query concerning the media content to a server and to send reception situation updates to the server; a receiving interface configured to receive the media content pushed from the server using a server-push technology of a network protocol in units of temporal segments of the media content at varying bitrate. 
         [0008]    According to another embodiment, a method for streaming media content may have a reception interface configured to receive a query from a client, the query concerning the media content; a sending interface comprised by a server configured to push the media content to the client using a server-push technology of a network protocol at varying bitrate in units of temporal segments of the media content, wherein the bitrate at which the media content is to be pushed is adapted to reception situation updates received from the client, the reception situation updates updating a description of a reception situation of the client. 
         [0009]    According to another embodiment, a method for receiving a media content streamed by a server may have a sending interface configured to send a query concerning the media content to a server and to send reception situation updates to the server; 
         [0010]    a receiving interface configured to receive the media content pushed from the server using a server-push technology of a network protocol in units of temporal segments of the media content at varying bitrate. 
         [0011]    Another embodiment may have a non-transitory digital storage medium having a computer program stored thereon to perform the method for streaming media content, the method comprising a reception interface configured to receive a query from a client, the query concerning the media content; a sending interface comprised by a server configured to push the media content to the client using a server-push technology of a network protocol at varying bitrate in units of temporal segments of the media content, wherein the bitrate at which the media content is to be pushed is adapted to reception situation updates received from the client, the reception situation updates updating a description of a reception situation of the client, when said computer program is run by a computer. 
         [0012]    Another embodiment may have a non-transitory digital storage medium having a computer program stored thereon to perform the method for receiving a media content streamed by a server, the method comprising a sending interface configured to send a query concerning the media content to a server and to send reception situation updates to the server; a receiving interface configured to receive the media content pushed from the server using a server-push technology of a network protocol in units of temporal segments of the media content at varying bitrate, when said computer program is run by a computer. 
         [0013]    The present application describes a media streaming concept inspired by the idea that media streaming may be made more efficient in terms of, for example, transmission bitrate consumption, transmission latency and/or fair trade of transmission capacity among several clients by sending the media content to the client by pushing the media content rather than the client pulling the media content from the server. Pushing the media content to the client using a server-push technology of a network protocol at a varying bitrate enables to shift, at least partially, the control over the streaming from the client towards the sending device such as the server or proxy, namely in that, for example, the server may continue to push segments of the media content to the client even without receiving explicit queries or directives for these segments from the client thereby reducing upstream bandwidth consumption. As far as the bitrate adaption is concerned, the server may act as a slave remotely controlled by the client in that the media content is pushed at a bitrate depending on the client&#39;s most recently sent information such as reception situation information explicitly indicating the bitrate to be used. Favorably, pushing the media content may be commenced without having yet received any reception situation information from the client, namely with the server or proxy assuming that doing so preliminarily will not be harmfull, i.e. will not lead to, for example, buffer overflow at the client, and assuming that a first reception situation information will arrive from the client soon, thereby reducing the latency of the streaming. Updates concerning the reception situation information may be sent from client to server upon changing transmission bandwidth or client&#39;s buffer fullness conditions or the like only, thereby keeping bandwidth consumption low. Alternatively, bitrate adaptation control may at least partially shifted from client to server, too. For example, the bitrate adaptation control may be rendered at the server remotely influenced by the client, but this remote influence may be performed at a temporal resolution, or at occasions occurring at a mean repetition rate, which is reduced compared to a rate at which the streaming bitrate is adapted in case of a client-driven client-pull technique. Accordingly, transmission bandwidth consumption may be saved since it is possible to influence the bitrate adaptation by the client using lower bandwidth. Moreover, due to shifting the bitrate adaptation control from client towards server, the pushing of the media content may be performed at a lower latency, such as, for example, even without any output buffering. Further, shifting the bitrate adaptation control away from the client towards servers/proxies allows for a more fair distribution of available transmission bandwidth among several clients. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0014]    Embodiments of the present invention will be detailed subsequently referring to the appended drawings, in which: 
           [0015]      FIG. 1  shows a schematic block diagram of a device for streaming media content in accordance with embodiments; 
           [0016]      FIG. 2  shows a schematic diagram illustrating a media content and its segmentation into temporal segments which, in turn, are accessible for the device of  FIG. 1  in different versions of different bitrates; 
           [0017]      FIGS. 3 to 5  show a schematic diagram illustrating a sequence of steps performed at server and client at the beginning of a media content streaming in accordance with various specific embodiments; and 
           [0018]      FIG. 6  shows a block diagram of a client in accordance with an embodiment of the present application. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0019]      FIG. 1  shows a device  10  for streaming a media content  12  to a client, which is not shown in  FIG. 1 . Device  10  comprises a reception interface  14  and a sending interface  16 . The reception interface  14  is configured to receive one or more queries  18  from the client, with the same concerning the media content  12 . Queries  18  of different types may exist and the meaning thereof is discussed further below. 
         [0020]    The sending interface  16  is configured to push the media content  12  to the client using a server-push technology of a network protocol at varying bitrate. Later on, it is described that this network protocol may be HTTP/2.0, although other network protocols having a server-push capability may be used as well. 
         [0021]      FIG. 1  illustrates that the media content  12  may, for instance, be a temporal sampling of an audio and/or video scene such as an audio signal  20  composed of a sequence of audio samples, or a video  22  composed of a sequence of images with  FIG. 1  illustrating the temporal axis with “t”. The media content  12  is, in particular, accessible for device  10  and sending interface  16 , respectively, in units of temporal segments  24  or, alternatively speaking, sending interface  16  is able to vary the bitrate at which the media content  12  is pushed to the client in units of such temporal segments  24 . This means, in turn, that the device  10  has access to the temporal segments  24  at different bitrates. For example, sending interface  16  may have the possibility to retrieve or order the temporal segments  24  at a predetermined bitrate from, for example, a media encoder not shown in  FIG. 1 , or sending interface  16  receives each temporal segment of the media content  12  in different versions, each being associated with a different bitrate. For example, a media encoder such as a video and/or audio encoder, provides the sending interface  16  with encoded versions of the temporal segments  24 , each encoded version being associated with a different bitrate, for example. 
         [0022]      FIG. 2  illustrates the latter alternative in more detail.  FIG. 2  shows the temporal sequential order of the temporal segments  24  of the media content which temporally immediately abut each other without temporal overlap. For example, the temporal length of the temporal segments  24  may be between 1 and 20 seconds, for instance. In order to distinguish between the temporal segments, an index i with in  FIG. 2  exemplarily 0&lt;i&lt;4 is used. The index i monotonically increases, for example, with time t. Each temporal segment  24   i  is accessible for sending interface  16  in one of different versions j with three different versions being exemplarily depicted in  FIG. 2 , i.e. 0&lt;j&lt;J+1, with here exemplarily J=3. In accordance with version j, the sequence of temporal segments  24   i  of the media content is encoded into encoded representations  26   ij  of the temporal segments  24   i  so that version j represents the media content at a bitrate R j . That is, the bit length b ij  of the encoded representations  26   ij  for the temporal segments  24   i  divided by the temporal length t i  of the respective temporal segment  24   i  results, at least on average, for each version j into bitrate R j , i.e. running-mean i (b ij /t i )=const.=R j  or even b ij /t i =R j  for all i. The encoded representations  26   ij  of a certain version j may or may not vary around the mean bitrate R j  in a running average sense for the consecutive temporal segments  24   j . In line with the difference in bitrate of the versions, the versions j represent the respective temporal segments  24   i , i.e. the media content, at different quality and/or information content. For example, versions of higher bitrate may represent the media content at higher quality, using a higher number of audio channels, using a higher number of views, by adding depth information, using a higher temporal resolution, using a higher spatial resolution, using a better SNR quality, using a further color component or the like. The versions j at which the media content  12  may be accessible for device  10  may be coded in a self-contained manner each, i.e. independent from any of the other versions and without exploiting any inter-version prediction so as to avoid inter-version redundancies.  FIG. 2 , however, illustrates using dashed lines that the encoded representations  26   ij  may have alternatively been obtained using layered coding with each version, for example, corresponding to a layer of this layered coding. One of the versions, for example, such as version  1  in  FIG. 2 , may form a base layer of this layered coding, and other versions may represent an enhancement layer of this layered coding and may be composed of the encoded representations of the base layer and optionally any intermediate layer plus enhancement data specific for the respective enhancement layer. This is illustrated in  FIG. 2  using dashed lines. 
         [0023]    Thus, referring back to  FIG. 1 , the sending interface  16  is able to push the media content  12  to the client in units of the just mentioned temporal segments  24  while varying the bitrate at which the temporal segments  24  are pushed to the client. For illustration purposes, for example,  FIG. 1  illustrates that the sending interface  16  pushes temporal segments  24   1  to the client at a bitrate R 2  corresponding to version  2 , temporal segment  24   2  at bitrate R 3  corresponding to version  3  and temporal segment  24   3  at bitrate R 2  corresponding to version  2 . Naturally, this is merely an example and the number of versions J for the temporal segments  24   i  could be other than  3 , such as  2 ,  4  or any other number. Advantageously, owing to the server-push technology, sending interface  16  is able to push the media content to the client, i.e. send-out the temporal segments  24   i  in the form of their encoded representations  26   ij , on its own behalf, i.e. without being pulled to do so by way of respective requests from the client, as would be case when using network protocols not supporting server-push technology such as normal HTTP protocols. 
         [0024]    Any query  18  from the client received at the reception interface  14  may trigger the sending interface&#39;s pushing of the media content to the client, one temporal segment after the other. After triggering the media content pushing, there is no need for any further queries or requests to be received at device  10  from the client. Rather, from that triggering event onwards, the device  10  and sending interface  16 , respectively, sequentially pushes the temporal segments  24  to the client. For instance, later on embodiments will be shown according to which the sending interface  16  is configured to commence pushing the media content responsive to a manifest request  28  from the client, the manifest request  28  requesting a manifest describing versions at which the media content is accessible for device  10  and the bitrates of the versions, respectively. This manifest may, for instance, be an XML file. That is, in accordance with this alternative, device  10  commences pushing the media content responsive to the manifest request  28  inevitably without awaiting, i.e. prior to, receiving any other query  18  from the client, such as a reception situation description  30  a possible content of which is discussed hereinafter. In accordance with an alternative embodiment also described hereinafter, the pushing of the media content by the sending interface  16  is triggered as soon as the reception interface  14  has received a manifest request  28  and a reception situation description  30  from the client. An extra query especially dedicated for triggering the streaming push, could also be provided. 
         [0025]    As described above, the sending interface  16  pushes the media content  12  to the client at varying bitrate. To this end, the sending interface  16  may comprise a bitrate adaptation control  32  configured to vary the bitrate so as to, for example, balance varying transmission bandwidth conditions and/or varying buffer fullness states at the client. The bitrate control  32  may act as a slave remotely controlled by the client via reception situation updates  30  or may evaluate the reception situation updates  30  sent from the client so as to assess an optimum bitrate for the pushing. in the latter case, bitrate adaptation control  32  evaluates, for example, a description of a reception situation of the client continuously updated, for example, by reception situation updates  30  intermittently received at the reception interface  14  from the client. The reception situation of the client described by the reception situation updates  30  describes, for example, the reception situation of the client in terms of the available downlink bandwidth available at the client, in terms of a reception delay at which downloads reach the client, in terms of network information concerning the networks via which the client is communicatively connected to outside, such as mobile 3G, mobile 4G, DSL fixed 4 Mbps, etc., in terms of a device information concerning the client or concerning the device on which the client is running, such as a mobile phone, a computer or the like, in terms of a hardware information concerning the client&#39;s hardware, such as concerning the client&#39;s CPU, memory, etc. and/or in terms of a software information concerning the client and indicating, for example, the operating system on which the client is running, such as android, windows or the like. The bitrate adaptation control  32  may take the description of the reception situation of the client into account in varying the bitrate, i.e. in selecting the bitrate at which the sequence of temporal segments of the media content are pushed to the client. That is, the bitrate adaptation control  32  varies the bitrate of the media content pushing dependent on the reception situation at the client. Additionally or alternatively, bitrate adaptation control  32  may vary the bitrate in dependence on external information. Such external information could, for instance, inform the bitrate adaptation control  32  on a strain put onto the network connecting the client with the server due to other clients and other data transfers running over this network. Such external information may or may not be related to the client. For example, the external information may be an information concerning the client&#39;s rights or priority or budget or the like. Accordingly, clients having higher priority, right or budget may be served at a higher bitrate than compared to clients having lower priority. By way of the continuous update of the reception situation at the client, however, by way of updates  30 , bitrate adaptation control  32  is able to avoid, for instance, buffer overflow and/or buffer underflow situations at the client. In case of the adaptation control  32  acting as a client&#39;s slave, the updates  30  directly provide or indicate, for example, the bitrate at which the pushing of the media content&#39;s segment is to be performed till the reception of the next update  30 . 
         [0026]    Between the reception of two reception situation updates  30 , the bitrate adaptation control  32  uses, as a basis for the bitrate adaptation, the reception situation as described in the earlier one of the two updates  30 . That is, bitrate adaptation control  32  may use the most recently received reception situation update  30  as a description of the client reception situation and may continue, up to the reception of the next update  30 , this reception situation description as a basis for selecting the bitrate at which the temporal segments are pushed to client up to the reception of the next update  30 . 
         [0027]    The bitrate adaptation control  32  may perform the bitrate adaptation according to certain rules. These rules thus define the bitrate adaptation and describe, for example, how to vary the bitrate depending on the reception situation as described and continuously updated by the reception situation updates  30  sent from the client. These rules may be defined in the aforementioned manifest file accessible for the sending interface  16  along with the media content  12 . For example, manifest and media content may be stored on a storage. Alternatively, the manifest may be stored on a storage and the media content  12  or its encoded representation is output by an encoder to device  10  and sending interface  16 , directly, i.e. without any buffering. Buffering of the media content  12  is not necessary due to the sending interface  16  pushing the media content to the client on its own behalf without having to await respective requests for the temporal segments from the client. 
         [0028]    Additionally or alternatively, the aforementioned manifest may define the condition upon which the pushing of the media content is to be commenced. As denoted above, the condition may be fulfilled upon receiving a manifest request  28  only or, alternatively, upon receiving both manifest request  28  and a reception situation description  30 . 
         [0029]    Additionally or alternatively, the aforementioned manifest may define the bitrate at which the pushing is to be performed between the time instant of starting the pushing of the media conent to the client and the time instant of receiving the first reception situation description  30 , if any such time discrepancy exists. 
         [0030]    In addition to the manifest request  28  and the reception situation update  30 , the queries  18  received at the reception interface  14  from the client may also comprise a stop signalization and/or a seeking signalization  34  and  36 , respectively. For example, the device  10  and sending interface  16 , respectively, may be responsive to a reception of the stop signalization from the client so as to stop pushing the media content to the client, and/or could be responsive to the reception of the seek signalization  36  from the client so as to resume pushing the media content  12  from a temporal position indicated within the seek signalization  36  onwards. That is, by way of seek signalization, the client would be enabled to influence the device&#39;s  10  media streaming in such a manner that, for example, the sending interface  16  pushes a temporal segment k after temporal segment j with k≠j+1. Temporal segment  24   k  would be a temporal segment at the temporal position indicated within the seeking signalization  36  and from that temporal segment  24   k  onwards, the media stream  12  would be pushed in units of the temporal segments, namely by resuming the media streaming with the temporal segments  24   k+1 ,  24   k+2 , . . . . 
         [0031]      FIG. 3  illustrates an exchange of data between client and server in the exemplary case of triggering the media content push by way of a reception of a manifest request only. The server is constructed as shown in  FIG. 1  and a temporal axis runs in  FIG. 3  from top to bottom with data leading from client to server being illustrated by an arrow running from left to right and data sent from the server to client being illustrated by arrows leading from right to left. As shown, the media download is initiated by the client by establishing a connection between client and server. In particular, the client starts with sending  40  a stream identifier to the server, the stream identifier or stream ID logically indicating the connection between clients and server and enabling discriminating between packets sent between client and server to one another on the one hand and packets sent via a network connecting client and server between other network entities on the other hand. Thereupon, using the same stream ID, the client sends  42  a manifest request to the server, which is received at the server&#39;s reception interface. Responsive thereto, the server immediately starts/commences pushing the media content to the client. In particular, in step  44 , the server starts with sending a status frame to the client, using the correct stream ID, and then sends  46  the manifest to the client. The server immediately further pushes  48  the first temporal segment of the media content to the client, followed by sending  50  the second temporal segment and sending  52  the third temporal segment.  FIG. 3  illustratively shows the server pushes the first three segments at a version having bitrate 100 kbps.  FIG. 3  illustrates that before sending the fourth temporal segment, the server receives from the client at  54  a reception situation description  30 , here illustratively indicating that the client has a reception bandwidth available of 500 kbps. Accordingly, the server may raise the bitrate at which the media stream may be pushed to the client and accordingly, pushes  56  the fourth temporal segment to the client at a higher bitrate, here exemplary exactly 500 kbps. 
         [0032]    Thus,  FIG. 3  illustrates that the server pushes temporal segments to the client according to information that the client sends to the server through reception situation updates, called “settings frames” in  FIG. 3 . The client can communicate its download bandwidth, roundtrip time, TCP window, etc. with the settings frames. Such settings frames may, for instance, be formed in compliance with the DASH standard, for example, but may also be formed differently or may be extended, as DASH settings frames are extendable. The client could be allowed to select specific representations/versions by way of the settings frames. In that case, the servers bitrate adaptation control  32  would act as a kind of “slave” (blindly) obeying the client&#39;s commands or bitrate wishes sent via the settings frames. 
         [0033]    While  FIG. 3  depicts that the server commences pushing temporal segments to the client without having information from the settings frames,  FIG. 4  depicts a variant of  FIG. 3  according to which the server defers pushing the first temporal segment in step  48  until the reception  58  of the first setting frame from the client as an answer to the manifest provided by the server to the client in step  46 . That is, while the server starts pushing the media content to the client using, for example, the version of the media content associated with a minimum bitrate at which the media content is available without having any information on the reception situation of the client in the case of  FIG. 3 , in the case of the example of  FIG. 4 , the server awaits a first description on the client&#39;s reception situation first before starting pushing the media content to the client. 
         [0034]    It should be noted that in accordance with the description brought forward above, the information for the representation selection, i.e. the reception situation update  30  (settings frames) as well as any of the other queries  18  from the client, could alternatively be signaled out of band, i.e. using another channel on another network protocol as used for the pushing of the media content from device  10  to the client, e.g. a separate HTTP connection or an alternative protocol, e.g. FTP, RTSP, etc. 
         [0035]    For the sake of completeness,  FIG. 5  illustrates that the server may defer any data transmission towards the client until the reception  58  of the first settings frame from the client. In this regard,  FIG. 5  also illustrates the possibility that, in order to compensate for the further detail, for example, this server performs the pushing  48  of the first temporal segment of the audio content prior to the sending-out  44  of the status information and the sending out of the manifest  46 . 
         [0036]    It has already been mentioned above that it would be possible that a server construed as depicted in  FIG. 1  could perform a low latency dynamic adaptive live streaming or a device according to  FIG. 1  could form an outbound module for a realtime communication. As mentioned above, HTTP/2.0 could be used as a basis. In particular, in that case device  10 , enabled by the usage of the server push technology, would immediately push the media data to the client (or the other party in the case of the realtime communication). There would be no need to wait until a temporal segment is fully encoded. Rather, encoded frames could be pushed to the client as soon as the encoder outputs them. As the connection is persistent between client and server as established, for example, in step  40 , an immediate push of a next temporal segment after a segment has been finished is possible and removes the RTT (Round Trip Time) between individual segment requests. Optionally, some frames in the encoded representations, such as I frames, could be prioritized through HTTP/2.0 stream priority. There would be no head of line blocking, e.g., a potentially blocking B frame, for example. 
         [0037]    As far as the HTTP/2.0 server push based streaming is concerned, caching is a further aspect with respect to which the above outlined concept allows for advantages: Proxies, for example, may be used to multiplex multiple downstream HTTP/2.0 sessions to various clients in the case of live streaming, for example. These proxies could be construed as shown in  FIG. 1 . For m:n realtime communication, a proxy could apply multiplex downstream HTTP/2.0 sessions to various clients. 
         [0038]    The device of  FIG. 1  could also be used in the framework of a content delivery network: for example, the manifest, such as the MPD, could be deployed with additional object relation models on the server, i.e. with the aforementioned rules describing the way of performing the bitrate adaptation, for example. In other words, the object relation model could be implemented as a file which could be based on XML without being limited to that, with this file describing, for example, the push behavior. For example, if a client requests segment  1 , the push strategy for this segment involves the server to send segment  2  immediately to the same client. 
         [0039]    It has also already been mentioned above that the media streaming content described above may be used along with scalable video coding, i.e. the media content  12  pushed to the client may have been coded using scalable video coding with the various versions of different bitrate at which the media content is pushed to the client corresponding to the layers of this layered coding. Thus, scalable video coding (layered coding) can be used along with, for example, HTTP/2.0 server push strategy, and then the server could send additional enhancement layers to the client if bandwidth is available. 
         [0040]    For the sake of completeness,  FIG. 6  shows a client in accordance with an embodiment of the present application. The client is generally indicated using reference sign  80  and comprises a sending interface  82  configured to send a query  18  concerning the media content streamed by a server to the server, and a receiving interface  84  configured to receive the media content pushed from the server using the server-push technology of the network protocol. That is, the sending interface  82  sends-out the aforementioned queries  18  and the receiving interface  84  receives the media content pushed from the server as described above. 
         [0041]    Although some aspects have been described in the context of an apparatus, it is clear that these aspects also represent a description of the corresponding method, where a block or device corresponds to a method step or a feature of a method step. Analogously, aspects described in the context of a method step also represent a description of a corresponding block or item or feature of a corresponding apparatus. Some or all of the method steps may be executed by (or using) a hardware apparatus, like for example, a microprocessor, a programmable computer or an electronic circuit. In some embodiments, some one or more of the most important method steps may be executed by such an apparatus. 
         [0042]    The inventive spliced or splicable audio data streams can be stored on a digital storage medium or can be transmitted on a transmission medium such as a wireless transmission medium or a wired transmission medium such as the Internet. 
         [0043]    Depending on certain implementation requirements, embodiments of the invention can be implemented in hardware or in software. The implementation can be performed using a digital storage medium, for example a floppy disk, a DVD, a Blu-Ray, a CD, a ROM, a PROM, an EPROM, an EEPROM or a FLASH memory, having electronically readable control signals stored thereon, which cooperate (or are capable of cooperating) with a programmable computer system such that the respective method is performed. Therefore, the digital storage medium may be computer readable. 
         [0044]    Some embodiments according to the invention comprise a data carrier having electronically readable control signals, which are capable of cooperating with a programmable computer system, such that one of the methods described herein is performed. 
         [0045]    Generally, embodiments of the present invention can be implemented as a computer program product with a program code, the program code being operative for performing one of the methods when the computer program product runs on a computer. The program code may for example be stored on a machine readable carrier. 
         [0046]    Other embodiments comprise the computer program for performing one of the methods described herein, stored on a machine readable carrier. 
         [0047]    In other words, an embodiment of the inventive method is, therefore, a computer program having a program code for performing one of the methods described herein, when the computer program runs on a computer. 
         [0048]    A further embodiment of the inventive methods is, therefore, a data carrier (or a digital storage medium, or a computer-readable medium) comprising, recorded thereon, the computer program for performing one of the methods described herein. The data carrier, the digital storage medium or the recorded medium are typically tangible and/or non-transitionary. 
         [0049]    A further embodiment of the inventive method is, therefore, a data stream or a sequence of signals representing the computer program for performing one of the methods described herein. The data stream or the sequence of signals may for example be configured to be transferred via a data communication connection, for example via the Internet. 
         [0050]    A further embodiment comprises a processing means, for example a computer, or a programmable logic device, configured to or adapted to perform one of the methods described herein. 
         [0051]    A further embodiment comprises a computer having installed thereon the computer program for performing one of the methods described herein. 
         [0052]    A further embodiment according to the invention comprises an apparatus or a system configured to transfer (for example, electronically or optically) a computer program for performing one of the methods described herein to a receiver. The receiver may, for example, be a computer, a mobile device, a memory device or the like. The apparatus or system may, for example, comprise a file server for transferring the computer program to the receiver. 
         [0053]    In some embodiments, a programmable logic device (for example a field programmable gate array) may be used to perform some or all of the functionalities of the methods described herein. In some embodiments, a field programmable gate array may cooperate with a microprocessor in order to perform one of the methods described herein. Generally, the methods are performed by any hardware apparatus. 
         [0054]    The apparatus described herein may be implemented using a hardware apparatus, or using a computer, or using a combination of a hardware apparatus and a computer. 
         [0055]    The methods described herein may be performed using a hardware apparatus, or using a computer, or using a combination of a hardware apparatus and a computer. 
         [0056]    While this invention has been described in terms of several embodiments, there are alterations, permutations, and equivalents which fall within the scope of this invention. It should also be noted that there are many alternative ways of implementing the methods and compositions of the present invention. It is therefore intended that the following appended claims be interpreted as including all such alterations, permutations and equivalents as fall within the true spirit and scope of the present invention. 
       REFERENCES 
       [0057]    [1] Christopher Mueller, Stefan Lederer, Christian Timmerer and Hermann Hellwagner, “Dynamic Adaptive Streaming over HTTP/2.0”, IEEE International Conference on Multimedia and Expo (ICME), 2013. 
         [0058]    [2] Christopher Mueller, Daniele Renzi, Stefan Lederer, Stefano Battista and Christian Timmerer, “Using Scalable Video Coding for Dynamic Adaptive Streaming over HTTP in Mobile Environments”, IEEE 20th European Signal Processing Conference, 2012. 
         [0059]    [3] IETF Working Group on HTTP/2.0, https://datatracker.ietf.org/wg/httpbis/charter/.