WO2016099354A1 - Request scheduling for streamed media - Google Patents

Request scheduling for streamed media Download PDF

Info

Publication number
WO2016099354A1
WO2016099354A1 PCT/SE2014/051530 SE2014051530W WO2016099354A1 WO 2016099354 A1 WO2016099354 A1 WO 2016099354A1 SE 2014051530 W SE2014051530 W SE 2014051530W WO 2016099354 A1 WO2016099354 A1 WO 2016099354A1
Authority
WO
WIPO (PCT)
Prior art keywords
time
media
streaming server
media segment
request
Prior art date
Application number
PCT/SE2014/051530
Other languages
French (fr)
Inventor
Anders E Eriksson
Beatriz Grafulla-Gonzalez
Jacob STRÖM
Richard MITIC
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Priority to PCT/SE2014/051530 priority Critical patent/WO2016099354A1/en
Publication of WO2016099354A1 publication Critical patent/WO2016099354A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2408Monitoring of the upstream path of the transmission network, e.g. client requests
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/242Synchronization processes, e.g. processing of PCR [Program Clock References]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4305Synchronising client clock from received content stream, e.g. locking decoder clock with encoder clock, extraction of the PCR packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643Communication protocols
    • H04N21/64322IP
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6581Reference data, e.g. a movie identifier for ordering a movie or a product identifier in a home shopping application
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Definitions

  • the present embodiments generally relate to streaming of media content, and in particular to scheduling of requests for streamed media content.
  • Adaptive streaming standards or specifications such as Moving Picture Experts Group (MPEG) Dynamic Adaptive Streaming over HyperText Transfer Protocol (HTTP) (DASH) and HTTP Live Streaming (HLS) involve creating media segments that contain different encoded versions of one or several of the media components of a media content.
  • MPEG Moving Picture Experts Group
  • HTTP Dynamic Adaptive Streaming over HyperText Transfer Protocol
  • HLS HTTP Live Streaming
  • an adaptation set may contain video data encoded at different alternative bitrates and optionally an intra (I) frame only bitstream with a low frame rate available during trick-mode play.
  • I intra
  • audio contents such as representing different languages, can be available in different encoded versions, e.g. surround sound and different alternative bitrates.
  • MPEG DASH and HLS provide adaptive streaming solutions over HTTP as compared to traditional streaming that typically use Real-Time Streaming Protocol (RTSP).
  • RTSP-based streaming requires the streaming server to keep track of the state of the user client throughout the streaming session.
  • HTTP is stateless implying that if a user client requests media content, the streaming server responds by sending the requested media content and then the transaction is terminated. Each such HTTP request is thereby handled as a completely stand-alone one-time transaction.
  • MPEG DASH and HLS allow a media stream to be made available as media segments on a HTTP server or Content Delivery Network (CDN), denoted streaming server herein. These media segments are acquired by a user client using an HTTP GET requests.
  • the streaming server publishes the media segments once they become available at the streaming server for requesting user clients.
  • the streaming server When publishing a media stream in MPEG DASH, the streaming server must also publish a Media Presentation Description (MPD) that indicates which media segments are available at which time.
  • MPD Media Presentation Description
  • a disparity between the clocks of the streaming server and the user client can typically result in either early or late requests by the user client. This will in turn cause errors or add delay, respectively.
  • MPEG DASH There is a proposed mechanism in MPEG DASH that allows a user client and streaming server to synchronize to an external clock source [1]. However, synchronizing with an external clock introduces further delay or jitter if either the user client or the streaming server takes a long time to access the external clock source. Furthermore, it is generally not desirable to require a third entity, i.e. external clock source, rather to keep the simple server vs. client architecture.
  • Another proposed mechanism in MPEG DASH is a push-based model where the streaming server directly sends a media segment to a user client as soon as it is available [2].
  • a further proposed mechanism is to have the streaming server accessing an external clock source and then including Coordinated Universal Time (UTC) time with each media segment sent to the user client in order to enable the user client to control its clock drift [3].
  • UTC Coordinated Universal Time
  • An aspect of the embodiments relates to a method for streaming multiple media segments comprising media components of a media content.
  • the method comprises receiving a request for a media segment of the multiple media segments from a user client.
  • the method also comprises determining time information based on a reception time of the request for the media segment at a streaming server and a publication time of the media segment at the streaming server.
  • the method further comprises transmitting, to the user client, the time information and the media segment or a notification that the media segment is not yet published at the streaming server.
  • the streaming server configured to stream multiple media segments comprising media components of a media component.
  • the streaming server is configured to receive a request for a media segment of the multiple media segments from a user client.
  • the streaming server is also configured to determine time information based on a reception time of the request for the media segment at the streaming server and a publication time of the media segment at the streaming server.
  • the streaming server is further configured to transmit, to the user client, the time information and the media segment or a notification that the media segment is not yet published at the streaming server.
  • a further aspect of the embodiments relates to a streaming server configured to stream multiple media segments comprising media components of a media component.
  • the streaming server comprises an input unit for inputting a request for a media segment of the multiple media segments from a user client.
  • the streaming server also comprises an information determining unit for determining time information based on a reception time of the request for the media segment at the streaming server and a publication time of the media segment at the streaming server.
  • the streaming server further comprises an output unit for outputting the time information and the media segment or a notification that the media segment is not yet published at the streaming server for transmission to the user client.
  • Yet another aspect of the embodiments relates to a streaming method comprising transmitting, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the method also comprises receiving the media segment and time information from the streaming server.
  • the method further comprises determining a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
  • a further aspect of the embodiments relates to a streaming method comprising transmitting, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the method also comprises receiving a notification that the media segment is not yet published at the streaming server and time information from the streaming server.
  • the method further comprises determining a time of retransmitting a request for the media segment based on the time information and the media presentation information.
  • Yet another aspect of the embodiments relates to a user client configured to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the user client is also configured to receive the media segment and time information from the streaming server.
  • the user client is further configured to determine a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
  • a further aspect of the embodiments relates to a user client comprising an output unit for outputting request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the user client also comprises an input unit for inputting the media segment and time information from the streaming server.
  • the user client further comprises a time determining unit for determining a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
  • Yet another aspect of the embodiments relates to a user client configured to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the user client is also configured to receive a notification that the media segment is not yet published at the streaming server and time information from the streaming server.
  • the user client is further configured to determine a time of retransmitting a request for the media segment based on the time information and the media presentation information.
  • a further aspect of the embodiments relates to a user client comprising an output unit for outputting a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the user client also comprises an input unit for inputting a notification that the media segment is not yet published at the streaming server and time information from the streaming server.
  • the user client further comprises a time determining unit for determining a time of retransmitting a request for the media segment based on the time information and the media presentation information.
  • An aspect of the embodiments relates to a computer program comprising instructions, which when executed by a processor, cause the processor to receive a request for a media segment of the multiple media segments from a user client.
  • the processor is also caused to determine time information based on a reception time of the request for the media segment at a streaming server and a publication time of the media segment at the streaming server.
  • the processor is further caused to transmit, to the user client, the time information and the media segment or a notification that the media segment is not yet published at the streaming server.
  • Another aspect of the embodiments relates to a computer program comprising instructions, which when executed by a processor, cause the processor to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the processor is also caused to receive the media segment and time information from the streaming server.
  • the processor is further caused to determine a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
  • a further aspect of the embodiments relates to a computer program comprising instructions, which when executed by a processor, cause the processor to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the processor is also caused to receive a notification that the media segment is not yet published at the streaming server and time information from the streaming server.
  • the processor is further caused to determine a time of retransmitting a request for the media segment based on the time information and the media presentation information.
  • a related aspect of the embodiments defines a carrier comprising a computer program as defined above.
  • the carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
  • the embodiments enable efficient scheduling of requests for media segments by user clients even in a situation when there are clock disparities between the user client and the streaming server. Thus, such requests for media segments can be scheduled to reduce the risk of long delays and/or reduce the risk of receiving error notifications indicating that the requested media segment is not yet published at the streaming server.
  • the embodiments achieve the efficient scheduling without the need for an external clock source and synchronization thereto.
  • the embodiments also eliminate any errors that may occur by the transit time of a request made to such an external clock source because all timing calculations can be done using internal clocks.
  • the embodiments can be implemented within current pull-based architecture and are therefore compatible with current transport protocol for adaptive streaming.
  • Fig. 1 is a schematic overview of an example of a media distribution system
  • Fig. 2 is flow chart of a method for streaming according to an embodiment
  • Fig. 3 is a flow chart of an additional, optional step of the method shown in Fig. 2;
  • Fig. 4 is a signal diagram showing signaling performed during a media streaming session according to an embodiment
  • Fig. 5 is a flow chart of an additional, optional step of the method shown in Fig. 2;
  • Fig. 6 is a signal diagram showing signaling performed during a media streaming session according to another embodiment
  • Fig. 7 is a flow chart of additional, optional steps of the method shown in Fig. 2
  • Fig. 8 is a flow chart of additional, optional steps of the method shown in Fig. 2;
  • Fig. 9 is a signal diagram illustrating an embodiment of delaying requests for media segments
  • Fig. 10 is a signal diagram illustrating another embodiment of delaying requests for media segments
  • Fig. 11 is a flow chart of additional, optional steps of the method shown in Fig. 2
  • Fig. 12 is a flow chart illustrating a streaming method according to an embodiment
  • Fig. 13 is a flow chart illustrating a streaming method according to another embodiment
  • Fig. 14 is a flow chart of additional, optional steps of the methods shown in Figs. 12 and 13;
  • Fig. 15 is a schematic block diagram of a streaming server according to an embodiment;
  • Fig. 16 is a schematic block diagram of a streaming server according to another embodiment;
  • Fig. 17 is a schematic block diagram of a streaming server according to a further embodiment;
  • Fig. 18 is a schematic block diagram of a user client according to an embodiment;
  • Fig. 19 is a schematic block diagram of a user client according to another embodiment.
  • Fig. 20 is a schematic block diagram of a user client according to a further embodiment
  • Fig. 21 is a schematic block diagram of a computer program based implementation of embodiments.
  • the present embodiments generally relate to streaming of media content, in particular to scheduling of requests for streamed media content.
  • the present embodiments are particularly suitable for usage in connection with adaptive streaming standards or specifications such as MPEG DASH and HLS.
  • Such streaming standards or specifications use HTTP instead of traditional RTSP-based streaming solutions.
  • Fig. 1 schematically illustrates an overview of an example of a media distribution system 1 that can adopt the present embodiments.
  • Media content for instance live media content
  • the media content is typically processed in a media preparation process at a computer, server or other media processing equipment 3.
  • the media preparation process typically generates media segments comprising media components of the media content, such as MPEG DASH segments, also referred to as MPEG DASH media segments, or HLS segments, also referred to as HLS media segments.
  • such media segments comprise different encoded versions of one or several of the media components of the media content.
  • the media segments are then hosted on one or more media origin servers, HTTP servers or CDNs, denoted streaming servers 10 herein.
  • User clients 20 request media segments from the streaming server 10 via HTTP over a wireless or mobile access network 5, and possibly through one or more HTTP caches or proxies 4.
  • the network 5 may also or alternatively be a wired network 5.
  • the media segments are published at the streaming server 10.
  • Publication of a media segment at the streaming server 10 corresponds to making the media segment available for download by a requesting user client 20.
  • the publication time of a media segment at the streaming server 10 corresponds to the point in time from which the media segment can be requested by a user client 20 from the streaming server 10.
  • the streaming server 10 provides media presentation information to the user client 20, such as in the form of a MPEG DASH Media Presentation Description (MPD).
  • MPD MPEG DASH Media Presentation Description
  • Such media presentation information enables the user client 20 to determine scheduled publication times of the respective media segments at the streaming server 10.
  • the media presentation information thereby enables the user client 20 to schedule its request for media segments at the streaming server 10.
  • clock drift can cause a disparity between the clocks of the streaming server 10 and the user client 20.
  • a disparity may in turn result in either early or late requests by the user client 20.
  • the relevant media segment has not yet been published at the streaming server 10 and is therefore not yet ready for transmission to the requesting user client 20 causing transmission of an error message or notification.
  • delay will be added as the media segment will be available at the user client 20 at a later point in time than its publication time at the streaming server 10.
  • the present embodiments can efficiently handle such a situation by providing time information to the user client 20 that can be used when scheduling requests for media contents even if there are any disparity between the clocks at the streaming server 10 and the user client 20.
  • Fig. 2 is a flow chart of a method for streaming multiple media segments comprising media components of a media content.
  • the method comprises receiving a request for a media segment of the multiple media segments from a user client in step S1.
  • a next step S2 comprises determining time information based on a reception time of the request for the media segment at a streaming server and a publication time of the media segment at the streaming sever.
  • the method also comprises transmitting, to the user client and in step S3, the time information and the media segment or a notification that the media segment is not yet published at the streaming server.
  • the present embodiments thereby return time information to a requesting user client in addition to the requested media segment or a notification that the media segment is not yet published at the streaming server.
  • This time information which is determined based on the reception time of the request at the streaming sever and a publication time of the requested media segment at the streaming server, can then be used by the user client for scheduling requests for subsequent media segments and/or scheduling a re-request for the not yet published media segment. Accordingly, subsequent requests for media segments can be more correctly scheduled even if there is a disparity between clocks. This means that the user client can efficiently time or schedule its requests for media segments to points in time that reduce unnecessary delays or too early requests.
  • the method shown in Fig. 2 is in particular suitable as a method for adaptive streaming of multiple segments comprising different encoded versions of media components of a media content.
  • video data or content may be available as encoded at different alternative bitrates and/or in the form of a bitstream useful for so called trick-mode play.
  • audio data or content may be available in different versions, such as representing different languages, different audio settings, such as stereo vs. surround sound, and/or different alternative bitrates.
  • Fig. 3 is a flow chart illustrating an additional, optional step of the method in Fig. 2. The method starts in step S10, which comprises transmitting, to the user client, media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The method then continues to step S1 in Fig. 2.
  • This media presentation information could be regarded as manifest information allowing the user client to derive scheduled publication times of the media segments at the streaming sever.
  • the media presentation information may, for instance, be in the form of a MPD.
  • MPD generally describes a manifest of the available media content, its various alternatives, their Uniform Resource Locator (URL) and media characteristics, such as video resolution and bit rates.
  • URL Uniform Resource Locator
  • the media presentation information can be transmitted to the user client in step S10 according to various ways.
  • the media presentation information can be delivered using HTTP, email, thumb drive, broadcast, or other transports as non-limiting examples.
  • the user client learns about the program timing, media-content availability, media types, resolutions, minimum and maximum bandwidths, and the existence of various encoded alternatives of media components, accessibility features and required Digital Rights Management (DRM), media- component locations on the network, and other content characteristics.
  • DRM Digital Rights Management
  • the user client can select the appropriate encoded alternative and start streaming the media content by fetching the media segments using HTTP GET requests.
  • the segment availability start time of a media segment can be determined as the sum of the value of MPD@availabilityStartTime, the PeriodStart time of the containing Period as defined in section 5.3.2.1 of document [4], the MPD start time of the media segment and the MPD duration of the media segment. More information of using information contained in the MPD to determine scheduled publication times of media segments can be found in section 5.3.9.5.3 of document [4].
  • the media presentation information transmitted to the user client in step S10 allows the user client to determine scheduled publication times, i.e. points in time at which the media segments of the media content should be available at the streaming server.
  • scheduled publication times i.e. points in time at which the media segments of the media content should be available at the streaming server.
  • a disparity between the clocks at the streaming server and the user client may imply that a scheduled publication time as determined by the user client according to its clock may be different from the actual publication time according to the clock at the streaming server.
  • the user client may transmit its requests for media segments at too early or too late points in time with regard to the actual publication times according to the clock of the streaming server.
  • the time information transmitted to the user client in step S3 of Fig. 2 enables the user client to more correctly schedule its requests for media segments as compared to merely using the media presentation information transmitted to the user client in step S10 of Fig. 3.
  • step S2 of Fig. 2 comprises determining the time information based on a difference between the reception time and an actual publication time of the media segment at the streaming server.
  • Step S3 of Fig. 3 then comprises, in this embodiment, transmitting the time information and the media segment to the user client.
  • the streaming server has already published the media segment when it receives the request for the media segment from the user client.
  • the streaming sever notifies the reception time at which it received the request according to its clock.
  • Fig. 4 is a signal diagram illustrating signaling performed during a media streaming session according to an embodiment.
  • the streaming server publishes a media segment N that is then available for requesting user clients.
  • the user client determines a time of request for media segment N, preferably based on the previously received media description information, such as MPD.
  • the user client transmits the request for media segment N to the streaming server, which receives the request and notifies the reception time according to its clock.
  • the streaming server measures or calculates a time difference between the actual publication time and the reception time of the request.
  • the time information is generated based on this measured or calculated time difference.
  • the requested media segment N and the time information are transmitted to the user client.
  • the user client can then calculate an updated time of request for a next media segment, media segment N+1 , based on the received time information and preferably based on the received time information and the previously received media presentation information.
  • Fig. 4 illustrates how the user client determines an updated time of request for media segment N+1 that in this case precedes an original time of request for media segment N+1. As can further be seen in the figure, this updated time occurs shortly after the publication time of media segment N+1 at the streaming server, whereas the original time occurs at a much later point in time.
  • the user client would merely use the media description information to schedule its requests for media segments then the point in time represented by original time in Fig. 4 would be used to request for media segment N+1. This would cause a significant delay from the actual publication time of media segment N+1 and when the user client transmits its request for media segment N+1.
  • the user client in addition uses the time information received from the streaming server in connection with media segment N then the user client can determine an updated and more appropriate time of request for media segment N+1 that compensates for any disparity between the clock of the user client and the clock of the streaming server.
  • the updated time of request for media segment N+1 could be determined by the user client based on the original time of request for media segment N+1 , which in turn is determined based on the previously received media description information, and the time difference defined by the time information. For instance, the updated time could be determined as to - ti, wherein to represents the original time of request for media segment N+1.
  • the streaming server calculates the time between when the media segment was published, and when it was requested by the user client. This time information is sent to the user client. For example, a user client receives a message indicating that the request was 500 ms late. It could then attempt to request the next media segment anything up to 500 ms earlier that it was previously going to.
  • step S2 of Fig. 2 comprises determining the time information based on a difference between the reception time and a predicted publication time of the media segment at the streaming server.
  • step S3 preferably comprises transmitting the time information and the notification that the media segment is not yet published at the streaming server to the user client.
  • the streaming server has not yet published the media segment when it receives the request for the media segment from the user client.
  • the streaming sever notifies the reception time at which it received the request according to its clock.
  • the streaming server determines the time information based on a difference between this reception time and the predicted publication time according to its clock of the requested media segment.
  • the predicted publication time represents the time at which the streaming server predicts publication of the media segment. This predicted publication time can be determined according to various embodiments. For instance, the streaming server could use the previously transmitted media presentation information in order to determine the predicted publication time.
  • the streaming server would then basically perform a similar calculation of scheduled publication times based on the media presentation information that the user clients does but with one large difference; the calculation is according to the clock of the streaming server and not according to the clock of the user client.
  • the streaming server could determine the predicted publication time based on actual publication times of previous media segments. For instance, a predicted publication time of media segment N+1 could be determined as actual publication time of media segment N plus a delta time. This delta time could then be the time difference between actual publication times of two previous consecutive media segments, such as media segment N and media segment N-1 , or an average time difference between actual publication times of several pairs of previous consecutive media segments.
  • Fig. 5 is a flow chart illustrating an additional, optional step representing the determination of the predicted publication time according to an embodiment.
  • the method continues from step S1 in Fig. 2.
  • a next step S20 comprises determining the predicted publication time based on a scheduled publication time of the media segment defined by media presentation information and respective deviations between scheduled publication times and actual publication times of previous media segments of the multiple media segments.
  • the method then continues to step S2 of Fig. 2.
  • the streaming server uses the scheduled publication time of the media segment as defined by the media presentation information, such as MPD, together with deviation information.
  • This deviation information in turns represents deviations between scheduled publication times, as defined by the media presentation information, and actual publication times of previous media segments.
  • the streaming server could calculate an average deviation for the previous media segments or a weighted average deviation preferably using larger weights for more recent previous media segments as compared to more distant previous media segments.
  • Fig. 6 is a signal diagram illustrating signaling performed during a media streaming session according to an embodiment.
  • the user client determines a time of request for media segment N, preferably based on the previously received media description information, such as MPD.
  • the user client transmits the request for media segment N to the streaming server, which receives the request and notifies the reception time according to its clock.
  • the streaming server has not yet published media segment N.
  • the streaming server therefore determines a predicted publication time of media segment N, such as discussed in the foregoing.
  • the streaming server determines the time information based on a difference between the reception time and the predicted publication time.
  • the time information is transmitted to the user client and also a notification that media segment N is not yet published at the streaming server.
  • the user client uses the time information in order to calculate an updated time of request for media segment N, and optionally also for subsequent media segments represented by media segment N+1.
  • This updated time of request is preferably calculated based on the original time of request for media segment N, as determined based on the media presentation information, and the time information, such as to + ti.
  • the user client transmits a new request for media segment N to the streaming server.
  • the streaming server has published media segment N and thereby transmits the requested media segment N to the user client.
  • the streaming server may optionally also determine time information as disclosed in Fig. 4 and transmit such time information to the user client in addition to media segment N.
  • the time information received together with or in connection with the notification is also, in this embodiment, used to calculate an updated time of request for media segment N+1 based on the original time of request for media segment N+1 , preferably as determined based on the media presentation information, and the time information.
  • the original time of request for media segment N+1 precedes the publication time of media segment N+1
  • the updated time of request for media segment N+1 follows shortly after the publication time of media segment N+1.
  • the user client would merely use the media presentation information in order to schedule its requests for media segments then such media segments would be transmitted too early, i.e. before the publication of the respective media segments at the streaming server.
  • the user client uses the time information of the embodiments it is able to determine more appropriate updated time of requests for the media segments that is adapted to the publication times of the media segments at the streaming server even if there may be any clock disparity between the user client and the streaming server.
  • the streaming server may be able to predict (to within a reasonable accuracy) the publication time at which the requested media segment will be available in the future. This time information can be sent by any method, such within or alongside a "404 - file not found" response. The user client can then reschedule its original request and all subsequent requests to account for the disparity.
  • the operations shown in Fig. 4 are thus performed if the reception time of the request for the media segment is after the publication time of the media segment, whereas the operations shown in Fig. 6 are performed if the reception time of the request for the media segment is prior to the publication time of the media segment.
  • the time information could be generated and transmitted to the user client in response to each request for a media segment.
  • the streaming server transmits the time information with a selected periodicity, such as in response to every m th request for a media segment for some defined value ofm.
  • the streaming server transmits the time information to the user client if the difference between the reception time and the publication time is sufficiently large.
  • Fig. 7. The method continues from step S2 in Fig. 2, which in this embodiment comprises determining a difference between the reception time and the publication time.
  • a next step S30 comprises comparing the difference (diff) with a threshold value (T). If the difference is equal to or larger than the threshold value the method continues to step S3, where the time information and the media segment are transmitted to the user client.
  • step S31 which comprises transmitting the media segment to the user client.
  • the time information is transmitted to the user client only if the difference, i.e. the time information, equals or exceeds the threshold value. If the time information is small enough, implying that the request for the media segment was received shortly after the publication time at the streaming server, then no time information needs to be transmitted to the user client. Hence, only the media segment is transmitted to the user client in step S31.
  • Fig. 8 is a flow chart illustrating additional, optional steps of the method in Fig. 2 according to an embodiment.
  • the method continues from step S1 in Fig. 2.
  • a next step S40 comprises calculating a difference between the reception time and the publication time. The difference is compared with a threshold value in step S41. If the difference is equal to or larger than the threshold value the method continues to step S2 in Fig. 2, which comprises determining the time information based on the difference. However, if the difference is smaller than the threshold value, the method instead continues to step S42.
  • This step S42 comprises determining the time information to represent a zero value.
  • the method then continues to step S3 of Fig. 2.
  • the time information indicates a zero value as long as the difference between the reception time and the publication time is sufficiently small, i.e. as long as the request for the media segment is received within a short period of time from the publication time of the media segment.
  • the streaming server does not necessarily have to tell the truth when it generates the time information. This means that the streaming server could, for instance, set a larger value than the difference between the reception time and the publication time. This may be useful in order to induce a delay at the user client, which would decrease the chance of the user client making a too early request for a media segment that has not yet been published.
  • This approach may also be useful not only when delaying requests from user clients to prevent too early requests but also to achieve temporal load balancing when many user clients are requesting media segments from the streaming server.
  • step S2 of Fig. 2 comprises determining the time information based on the reception time, the publication time and a delta time.
  • Fig. 9 illustrates a signal diagram in which the streaming server is transmitting media segments to five different user clients.
  • the streaming server uses the delta times in order to schedule the requests from the five user clients to evenly spread the requests in order to distribute the workload of the streaming server over time.
  • the streaming server will thereby receive requests at a steady rate instead of all at once close to the publication of the media segment.
  • Fig. 10 illustrates a signal diagram according to another embodiment.
  • the delta times are random values. If the number of connected user clients is large, this will provide statistically even temporal spread with minimal input form the streaming server. The random number each user client uses could remain the same for the duration of the media session, or could change over time. In the latter case, new random values may be generated at each time time information is determined at the streaming server
  • Fig. 11 is a flow chart illustrating additional, optional steps of the method shown in Fig. 2. The method continues from step S1 , which comprises, in this embodiment, receiving multiple respective requests for the media segment from multiple user clients. The method continues to step S50, which comprises determining, for each user client of the multiple user clients, a respective delta time.
  • a delta time determined for a first user client of the multiple user clients is determined in step S50 so that a sum of the delta time and a difference between a reception time of a request for the media segment originating from the first user client and the publication time is different from a sum of a delta time determined in step S50 for a second user client of the multiple user clients and a difference between a reception time of a request for the media segment originating from the second user client and the publication time.
  • the streaming server could distribute the points in time at which the user clients will transmit further requests for media segments.
  • the streaming server thereby determines the respective delta times so that not all user clients will transmit requests for media segments at the same time.
  • the streaming server determines the respective delta times so that no more than one or no more than a maximum defined number of user clients will transmit requests for media segments at the same time.
  • step S51 comprises determining playback information defining a playback time of a media component of the media segment.
  • step S3 in Fig. 2 comprises, in this embodiment, transmitting the time information, the playback information and the media segment to the user client.
  • step S51 comprises determining playback information defining a same playback time of the media component for the first user client and the second user client.
  • first and second user clients will use different points in time when transmitting their respective requests for the media segment as defined by the received time information they will have a same playback time, i.e. synchronized playback, as defined by the playback information.
  • the streaming server preferably determines the playback information so that all user clients or at least a minimum number thereof will have synchronized playback, i.e. use a same playback time of the media component.
  • the time information of the embodiments can be transmitted to the user client in step S3 according to various embodiments.
  • the time information could be included in a HTTP header of a HTTP data packet containing, in addition to the HTTP header, a payload portion preferably comprising the media component or at least a portion thereof.
  • the time information is transmitted in-band together with the requested media segment.
  • out-of-band solutions for transmitting the time information are possible and within the scope of the embodiments.
  • Non-limiting examples of such an out-of-band transmission include using a Web socket, which is a protocol providing full-duplex communications channels over a single Transmission Control Protocol (TCP) connection, and Server-Sent Events (SSE), also referred to as event sources.
  • TCP Transmission Control Protocol
  • SSE Server-Sent Events
  • the present embodiments are in particular suitable for usage in connection with MPEG DASH and HLS and other streaming services over HTTP, preferably adaptive streaming services over HTTP.
  • the multiple media segments are multiple DASH media segments or multiple HLS segments.
  • the method as shown in Fig. 2 then comprises a HTTP-based streaming server receiving, in step S1 , a HTTP GET request for a DASH or HLS media segment from a DASH-compliant or HLS-compliant user client.
  • Step S2 comprises the HTTP-based streaming server determining time information based on a reception time of the HTTP GET request at the HTTP-based streaming server and a publication time of the DASH or HLS media segment at the HTTP-based streaming server.
  • Step S3 preferably comprises the HTTP-based streaming server transmitting, to the DASH-compliant or HLS-compliant user client, the time information and the DASH or HLS media segment or a HTTP 404 Not Found error message.
  • Fig. 12 is a flow chart illustrating a streaming method according to an embodiment.
  • the method comprises transmitting, in step S60 and to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • a next step S61 comprises receiving the media segment and time information from the streaming server.
  • the following step S62 comprises determining a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
  • the streaming method of Fig. 12 thereby corresponds to the actions performed by a user client when requesting a media segment from the streaming server and wherein the request is received at the streaming server following publication of the media segment, i.e. the reception time is subsequent to the publication time.
  • step S62 comprises determining the time of transmitting the request for the subsequent media segment based on the time information and an original time of transmitting the request for the subsequent media segment determined based on the media presentation information.
  • step S62 comprises determining the time of transmitting the request for the subsequent media segment based on a sum of the time information and the original time.
  • Fig. 13 is a flow chart illustrating a streaming method according to another embodiment.
  • the method comprises transmitting, in step S70 and to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • a next step S71 comprises receiving a notification that the media segment is not yet published at the streaming server and time information from the streaming server.
  • the following step S72 comprises determining a time of retransmitting a request for the media segment based on the time information and the media presentation information.
  • the streaming method of Fig. 13 thereby corresponds to the actions performed by a user client when requesting a media segment from the streaming server and wherein the request is received at the streaming server prior to publication of the media segment, i.e. the publication time is subsequent to the reception time.
  • step S72 comprises determining the time of retransmitting the request for the media segment based on the time information and the time of transmitting the request for the media segment determined based on the media presentation information.
  • an updated time of retransmitting the request is thereby determined based on the time information and the original time of transmitting the request.
  • the original time is in turn determined based on the media presentation information. This corresponds to operations performed at the client side in Fig. 6.
  • step S72 comprises determining the time of retransmitting the request for the media segment based on a sum of the time information and the time of transmitting the request.
  • Fig. 14 is a flow chart illustrating additional, optional steps of the methods shown in Fig. 12 and 13.
  • the method starts in step S80, which comprises receiving the media presentation information from the streaming server.
  • step S81 comprises determining the time of transmitting the request for the media segment based on the media presentation information.
  • the method then continues to step S60 in Fig. 12 or step S70 in Fig. 13.
  • the received media presentation information such as in the form of a MPD, is used to determine the time of transmitting the request for the media segment in step S81.
  • the streaming server configured to stream multiple media segments comprising media components of a media content.
  • the streaming server is configured to receive a request for a media segment of the multiple media segments from a user client.
  • the streaming server is also configured to determine time information based on a reception time of the request for the media segment at the streaming server and a publication time of the media segment at the streaming server.
  • the streaming server is further configured to transmit, to the user client, the time information and the media segment or a notification that the media segment is not yet published at the streaming server.
  • the streaming server is configured to transmit, to the user client, media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the streaming server is configured to determine the time information based on a difference between the reception time and an actual publication time of the media segment at the streaming server. In this embodiment, the streaming server is also configured to transmit the time information and the media segment to the user client.
  • the streaming server is configured to determine the time information based on a difference between the reception time and a predicted publication time of the media segment at the streaming server. In this embodiment, the streaming server is also configured to transmit the time information and the notification that the media segment is not yet published at the streaming server to the user client. In an embodiment, the streaming sever is configured to determine the predicted publication time of the media segment based on a scheduled publication time of the media segment defined by media presentation information and respective deviations between scheduled publication times and actual publication times of previous media segments of the multiple media segments. In an embodiment, the streaming server is configured to determine a difference between the reception time and the publication time. The streaming server is also configured to compare the difference with a threshold value.
  • the streaming server is further configured to transmit the time information and the media segment to the user client if the difference is equal to or larger than the threshold value.
  • the streaming server is preferably configured to merely transmit the media segment without any time information if the difference is smaller than the threshold value.
  • the streaming server is configured to determine a difference between the reception time and the publication time.
  • the streaming server is also configured to compare the difference with a threshold value.
  • the streaming server is further configured to determine the time information based on the difference if the difference is equal to or larger than the threshold value.
  • the streaming server is additionally configured to determine the time information to represent a zero value if the difference is smaller than the threshold value.
  • the streaming server is configured to determine the time information based on the reception time, the publication time and a delta time.
  • the streaming server is configured to determine the time information based on a sum of the delta time and a difference between the reception time and the publication time. In an embodiment, the streaming server is configured to receive multiple respective requests for the media segment from multiple user clients. The streaming server is preferably configured to determine, for each user client of the multiple user client, a respective delta time.
  • a delta time determined for a first user client of the multiple user clients is determined so that a sum of the delta time and a difference between a reception time of a request for the media segment originating from the first user client and the publication time is different from a sum of a delta time determined for a second user client of the multiple user clients and a difference between a reception time of a request for the media segment originating from the second user client and the publication time.
  • the streaming server is configured to determine playback information defining a playback time of a media component of the media segment.
  • the streaming serer is also configured to transmit the time information, the playback information and the media segment to the user client.
  • the streaming server is configured to determine playback information defining a same playback time of the media component for the first user client and the second user client.
  • embodiments may be implemented in hardware, or in software for execution by suitable processing circuitry, or a combination thereof.
  • Particular examples include one or more suitably configured digital signal processors and other known electronic circuits, e.g. discrete logic gates interconnected to perform a specialized function, or Application Specific Integrated Circuits (ASICs).
  • digital signal processors and other known electronic circuits, e.g. discrete logic gates interconnected to perform a specialized function, or Application Specific Integrated Circuits (ASICs).
  • ASICs Application Specific Integrated Circuits
  • Fig. 15 illustrates a particular hardware implementation of the streaming server 100.
  • the streaming server 100 comprises a receiver 101 configured to receive the request for the media segment from the user client.
  • the streaming server 100 also comprises an information determining unit 102 configured to determine the time information based on the reception time and the publication time.
  • the streaming server 100 further comprises a transmitter 103 configured to transmit the time information and the media segment or the notification to the user client.
  • the receiver 101 is connected to the information determining unit 102 in order to forward the reception time to the information determining unit 102.
  • the information determining unit 102 is in turn connected to the transmitter 103 for forwarding the time information thereto for transmission to the user client.
  • at least some of the steps, functions, procedures, modules and/or blocks described herein may be implemented in software such as a computer program for execution by suitable processing circuitry such as one or more processors or processing units.
  • processing circuitry includes, but is not limited to, one or more microprocessors, one or more Digital Signal Processors (DSPs), one or more Central Processing Units (CPUs), video acceleration hardware, and/or any suitable programmable logic circuitry such as one or more Field Programmable Gate Arrays (FPGAs), or one or more Programmable Logic Controllers (PLCs).
  • DSPs Digital Signal Processors
  • CPUs Central Processing Units
  • FPGAs Field Programmable Gate Arrays
  • PLCs Programmable Logic Controllers
  • the streaming server 110 comprises a processor 114 and a memory 115 comprising instructions executable by the processor 114.
  • the processor 114 is operative to receive the request for the media segment from a receiver 111.
  • the processor 114 is also operative to determine the time information based on the reception time and the publication time.
  • the processor 114 is further operative to output the time information and the media segment or the notification for transmission by a transmitter 113.
  • the streaming server 110 also comprises, in addition to the processor 114 and the memory 115, the receiver 111 and the transmitter 113 as shown in Fig. 16.
  • the processor 114 is operative, when executing the instructions stored in the memory 115, to perform the above described operations.
  • the processor 114 is thereby interconnected to the memory 115 to enable normal software execution.
  • Fig. 21 is, in an embodiment, a schematic block diagram illustrating an example of a streaming server 300 comprising a processor 310, an associated memory 320 and a communication circuitry 330.
  • a computer program 340 which is loaded into the memory 320 for execution by processing circuitry including one or more processors 310.
  • the processor 310 and memory 320 are interconnected to each other to enable normal software execution.
  • a communication circuitry 330 is also interconnected to the processor 310 and/or the memory 320 to enable input of requests and output of time information and media segments or notifications.
  • the term 'processor' should be interpreted in a general sense as any system or device capable of executing program code or computer program instructions to perform a particular processing, determining or computing task.
  • the processing circuitry including one or more processors is thus configured to perform, when executing the computer program, well-defined processing tasks such as those described herein.
  • the computer program 340 comprises instructions, which when executed by the processor 310, cause the processor 310 to receive a request for a media segment of multiple media segments comprising media components of a media content from a user client.
  • the processor 310 is also caused to determine time information based on a reception time of the request for the media segment at a streaming server 300 and a publication time of the media segment at the streaming server 300.
  • the processor 310 is further caused to transmit, to the user client, the time information and the media segment or a notification that the media segment is not yet published at the streaming server 300.
  • the proposed technology also provides a carrier 350 comprising the computer program 340.
  • the carrier 350 is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium 350.
  • the software or computer program 340 may be realized as a computer program product, which is normally carried or stored on a computer-readable medium 350, preferably nonvolatile computer-readable storage medium 350.
  • the computer-readable medium 350 may include one or more removable or non-removable memory devices including, but not limited to a Read-Only Memory (ROM), a Random Access Memory (RAM), a Compact Disc (CD), a Digital Versatile Disc (DVD), a Blue-ray disc, a Universal Serial Bus (USB) memory, a Hard Disk Drive (HDD) storage device, a flash memory, a magnetic tape, or any other conventional memory device.
  • the computer program 340 may thus be loaded into the operating memory 320 of a computer or equivalent processing device, represented by the streaming server 300 in Fig. 21 , for execution by the processor 310 thereof.
  • a corresponding streaming server may be defined as a group of function modules, where each step performed by the processor corresponds to a function module.
  • the function modules are implemented as a computer program running on the processor.
  • the streaming server may alternatively be defined as a group of function modules, where the function modules are implemented as a computer program running on at least one processor.
  • the computer program residing in memory may thus be organized as appropriate function modules configured to perform, when executed by the processor, at least part of the steps and/or tasks described herein.
  • An example of such function modules is illustrated in Fig. 17 illustrating a schematic block diagram of a streaming server 120 with function modules.
  • the streaming server 120 comprises an input unit 121 for inputting a request for a media segment of multiple media segments comprising media components of a media content received from a user client.
  • the streaming server 120 also comprises an information determining unit 122 for determining time information based on a reception time of the request at the streaming server 120 and a publication time of the media segment at the streaming server 120.
  • the streaming server 120 further comprises an output unit 123 for outputting the time information and the media segment or a notification that the media segment is not yet published at the streaming server 120 for transmission to the user client.
  • the streaming server of the embodiments may be implemented in various ways such as in the form of a HTTP server or a media origin server. Also a distributed implementation is possible in the form multiple, i.e. at least two, HTTP or media origin servers or a CDN.
  • the user client is configured to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the user client is also configured to receive the media segment and time information from the streaming server.
  • the user client is further configured to determine a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
  • the user client is configured to determine the time of transmitting the request for the subsequent media segment based on the time information and an original time of transmitting the request for the subsequent media segment determined based on the media presentation information.
  • the user client is configured to determine the time of transmitting the request for the subsequent media segment based on a sum of the time information and the original time.
  • a further aspect of the embodiments relates to a user client that is configured to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the user client is also configured to receive a notification that the media segment is not yet published at the streaming server and time information from the streaming server.
  • the user client is further configured to determine a time of retransmitting a request for the media segment based on the time information and the media presentation information.
  • the user client is configured to determine the time of retransmitting the request for the media segment based on the time information and the time of transmitting the request for the media segment determined based on the media presentation information. In an embodiment, the user client is configured to determine the time of retransmitting the request for the media segment based on a sum of the time information and the time of transmitting the request for the media segment.
  • the user client is configured to receive the media presentation information from the streaming server.
  • the user client is also configured to determine the time of transmitting the request for the media segment based on the media presentation information.
  • Fig. 18 illustrates a particular hardware implementation of the user client 200.
  • the 10 user client 200 comprises a transmitter 201 configured to transmit the request for the media segment to the streaming server.
  • the user client 200 also comprises a receiver 202 configured to receive the time information and the media segment or the notification from the streaming server.
  • the user client 200 further comprises a time determining unit 203 configured to determine the time of transmitting the request for the subsequent media segment or the time of retransmitting the request for the media 15 segment based on the time information and the media presentation information.
  • At least some of the steps, functions, procedures, modules and/or blocks of the user client may be implemented in software such as a computer program for execution by suitable processing circuitry such as one or more processors or processing units.
  • Fig. 19 is a schematic illustration of an embodiment of the user client 210.
  • the user client 210 comprises a processor 214 and a memory 215 comprising instructions executable by the processor 214.
  • the processor 214 is operative to output the request for the media segment for transmission by a transmitter 213.
  • the processor 214 is also operative to receive the time information and the media 25 segment or the notification from a receiver 211.
  • the processor 214 is further operative to determine the time of transmitting the request for the subsequent media segment or the time of retransmitting the request for the media segment based on the time information and the media presentation information.
  • the user client 210 also comprises, in addition to the processor 214 and the memory 30 215, the receiver 211 and the transmitter 213 as shown in Fig. 19.
  • Fig. 21 is, in an embodiment, a schematic block diagram illustrating an example of a user client 300 comprising a processor 310, an associated memory 320 and a communication circuitry 330.
  • a computer program 340 which is loaded into the memory 320 for execution by processing circuitry including one or more processors 310.
  • the processor 310 and memory 320 are interconnected to each other to enable normal software execution.
  • a communication circuitry 330 is also interconnected to the processor 310 and/or the memory 320 to enable output of requests for media segments and input of time information and media segments and/or notifications.
  • the computer program 340 comprises instructions, which when executed by the processor 310, cause the processor 310 to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the processor 310 is also caused to receive the media segment and the time information from the streaming server.
  • the processor 310 is further caused to determine a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
  • the computer program 340 comprises instructions, which when executed by the processor 310, cause the processor 310 to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the processor 310 is also caused to receive a notification that the media segment is not yet published at the streaming server and time information from the streaming server.
  • the processor 310 is further caused to determine a time of retransmitting a request for the media segment based on the time information and the media presentation information.
  • the proposed technology also provides the previously mentioned a carrier 350 comprising the computer program 340.
  • the computer program residing in memory may be organized as appropriate function modules configured to perform, when executed by the processor, at least part of the steps and/or tasks described herein.
  • An example of such function modules is illustrated in Fig. 20 illustrating a schematic block diagram of a user client 220 with function modules.
  • the user client 220 comprises an output unit 221 for outputting a request for a media segment of multiple media segments comprising media components of a media content for transmission to a streaming server at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the user client 220 also comprises an input unit 222 for inputting the media segment and time information received from the streaming server.
  • the user client 220 further comprises a time determining unit 223 for determining a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
  • the user client 220 of Fig. 20 comprises an output unit 221 for outputting a request for a media segment of multiple media segments comprising media components of a media content for transmission to a streaming server at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
  • the user client 220 also comprises an in input unit 222 for inputting a notification that the media segment is not yet published at the streaming server and time information received from the streaming server.
  • the user client 220 further comprises a time determining unit 223 for determining a time of retransmitting a request for the media segment based on the time information and the media presentation information.
  • the user client is preferably implemented as a DASH-compliant or HLS-compliant user client.
  • the user client may be in the form of or implemented within a mobile device, such as a smart phone, mobile telephone, tablet, laptop; a computer; a set-top box; etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

A streaming method comprises receiving a request for a media segment from a user client (20). Time information is determined based on a reception time of the request at a streaming server (10) and a publication time of the media segment at the streaming server (10). The time information is transmitted to the user client (20) with the media segment or a notification that the media segment is not yet published at the streaming server (10). The user client (20) can schedule request for subsequent media segments or reschedule requests for the media segment based on the time information. The embodiments enable efficient scheduling of requests for media segments even in a situation where there are clock disparities between the user client (20) and the streaming server (10).

Description

REQUEST SCHEDULING FOR STREAMED MEDIA
TECHNICAL FIELD
The present embodiments generally relate to streaming of media content, and in particular to scheduling of requests for streamed media content.
BACKGROUND
Adaptive streaming standards or specifications such as Moving Picture Experts Group (MPEG) Dynamic Adaptive Streaming over HyperText Transfer Protocol (HTTP) (DASH) and HTTP Live Streaming (HLS) involve creating media segments that contain different encoded versions of one or several of the media components of a media content. For instance, an adaptation set may contain video data encoded at different alternative bitrates and optionally an intra (I) frame only bitstream with a low frame rate available during trick-mode play. Correspondingly, one or multiple audio contents, such as representing different languages, can be available in different encoded versions, e.g. surround sound and different alternative bitrates.
MPEG DASH and HLS provide adaptive streaming solutions over HTTP as compared to traditional streaming that typically use Real-Time Streaming Protocol (RTSP). RTSP-based streaming requires the streaming server to keep track of the state of the user client throughout the streaming session. In contrast, HTTP is stateless implying that if a user client requests media content, the streaming server responds by sending the requested media content and then the transaction is terminated. Each such HTTP request is thereby handled as a completely stand-alone one-time transaction.
Thus, MPEG DASH and HLS allow a media stream to be made available as media segments on a HTTP server or Content Delivery Network (CDN), denoted streaming server herein. These media segments are acquired by a user client using an HTTP GET requests. The streaming server publishes the media segments once they become available at the streaming server for requesting user clients. When publishing a media stream in MPEG DASH, the streaming server must also publish a Media Presentation Description (MPD) that indicates which media segments are available at which time.
A disparity between the clocks of the streaming server and the user client can typically result in either early or late requests by the user client. This will in turn cause errors or add delay, respectively. There is a proposed mechanism in MPEG DASH that allows a user client and streaming server to synchronize to an external clock source [1]. However, synchronizing with an external clock introduces further delay or jitter if either the user client or the streaming server takes a long time to access the external clock source. Furthermore, it is generally not desirable to require a third entity, i.e. external clock source, rather to keep the simple server vs. client architecture. Another proposed mechanism in MPEG DASH is a push-based model where the streaming server directly sends a media segment to a user client as soon as it is available [2]. This push-based model would require significant changes in the architectural design of an adaptive streaming service. It is also not compatible with the current transport protocol for adaptive streaming in MPEG DASH, i.e. HTTP 1.1 , which is pull-based. Moreover, push-based adaptive streaming goes against the "client-driven" philosophy within which these streaming systems were designed.
A further proposed mechanism is to have the streaming server accessing an external clock source and then including Coordinated Universal Time (UTC) time with each media segment sent to the user client in order to enable the user client to control its clock drift [3]. This proposal has similar shortcomings as the above described proposal having both the streaming server and the user client accessing the external clock source.
Thus, there is still a need for an efficient scheduling of requests by user clients for media content at a streaming server.
SUMMARY
It is a general objective to provide an efficient streaming of media content.
It is a particular objective to provide an efficient scheduling of requests by user clients for media content at a streaming server.
These and other objectives are met by embodiments as disclosed herein.
An aspect of the embodiments relates to a method for streaming multiple media segments comprising media components of a media content. The method comprises receiving a request for a media segment of the multiple media segments from a user client. The method also comprises determining time information based on a reception time of the request for the media segment at a streaming server and a publication time of the media segment at the streaming server. The method further comprises transmitting, to the user client, the time information and the media segment or a notification that the media segment is not yet published at the streaming server.
Another aspect of the embodiments relates to a streaming server configured to stream multiple media segments comprising media components of a media component. The streaming server is configured to receive a request for a media segment of the multiple media segments from a user client. The streaming server is also configured to determine time information based on a reception time of the request for the media segment at the streaming server and a publication time of the media segment at the streaming server. The streaming server is further configured to transmit, to the user client, the time information and the media segment or a notification that the media segment is not yet published at the streaming server.
A further aspect of the embodiments relates to a streaming server configured to stream multiple media segments comprising media components of a media component. The streaming server comprises an input unit for inputting a request for a media segment of the multiple media segments from a user client. The streaming server also comprises an information determining unit for determining time information based on a reception time of the request for the media segment at the streaming server and a publication time of the media segment at the streaming server. The streaming server further comprises an output unit for outputting the time information and the media segment or a notification that the media segment is not yet published at the streaming server for transmission to the user client.
Yet another aspect of the embodiments relates to a streaming method comprising transmitting, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The method also comprises receiving the media segment and time information from the streaming server. The method further comprises determining a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information. A further aspect of the embodiments relates to a streaming method comprising transmitting, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The method also comprises receiving a notification that the media segment is not yet published at the streaming server and time information from the streaming server. The method further comprises determining a time of retransmitting a request for the media segment based on the time information and the media presentation information. Yet another aspect of the embodiments relates to a user client configured to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The user client is also configured to receive the media segment and time information from the streaming server. The user client is further configured to determine a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
A further aspect of the embodiments relates to a user client comprising an output unit for outputting request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The user client also comprises an input unit for inputting the media segment and time information from the streaming server. The user client further comprises a time determining unit for determining a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
Yet another aspect of the embodiments relates to a user client configured to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The user client is also configured to receive a notification that the media segment is not yet published at the streaming server and time information from the streaming server. The user client is further configured to determine a time of retransmitting a request for the media segment based on the time information and the media presentation information.
A further aspect of the embodiments relates to a user client comprising an output unit for outputting a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The user client also comprises an input unit for inputting a notification that the media segment is not yet published at the streaming server and time information from the streaming server. The user client further comprises a time determining unit for determining a time of retransmitting a request for the media segment based on the time information and the media presentation information.
An aspect of the embodiments relates to a computer program comprising instructions, which when executed by a processor, cause the processor to receive a request for a media segment of the multiple media segments from a user client. The processor is also caused to determine time information based on a reception time of the request for the media segment at a streaming server and a publication time of the media segment at the streaming server. The processor is further caused to transmit, to the user client, the time information and the media segment or a notification that the media segment is not yet published at the streaming server. Another aspect of the embodiments relates to a computer program comprising instructions, which when executed by a processor, cause the processor to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The processor is also caused to receive the media segment and time information from the streaming server. The processor is further caused to determine a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
A further aspect of the embodiments relates to a computer program comprising instructions, which when executed by a processor, cause the processor to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The processor is also caused to receive a notification that the media segment is not yet published at the streaming server and time information from the streaming server. The processor is further caused to determine a time of retransmitting a request for the media segment based on the time information and the media presentation information.
A related aspect of the embodiments defines a carrier comprising a computer program as defined above. The carrier is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
The embodiments enable efficient scheduling of requests for media segments by user clients even in a situation when there are clock disparities between the user client and the streaming server. Thus, such requests for media segments can be scheduled to reduce the risk of long delays and/or reduce the risk of receiving error notifications indicating that the requested media segment is not yet published at the streaming server. The embodiments achieve the efficient scheduling without the need for an external clock source and synchronization thereto. The embodiments also eliminate any errors that may occur by the transit time of a request made to such an external clock source because all timing calculations can be done using internal clocks. The embodiments can be implemented within current pull-based architecture and are therefore compatible with current transport protocol for adaptive streaming.
BRIEF DESCRIPTION OF THE DRAWINGS
The embodiments, together with further objects and advantages thereof, may best be understood by making reference to the following description taken together with the accompanying drawings, in which:
Fig. 1 is a schematic overview of an example of a media distribution system;
Fig. 2 is flow chart of a method for streaming according to an embodiment;
Fig. 3 is a flow chart of an additional, optional step of the method shown in Fig. 2;
Fig. 4 is a signal diagram showing signaling performed during a media streaming session according to an embodiment;
Fig. 5 is a flow chart of an additional, optional step of the method shown in Fig. 2;
Fig. 6 is a signal diagram showing signaling performed during a media streaming session according to another embodiment; Fig. 7 is a flow chart of additional, optional steps of the method shown in Fig. 2; Fig. 8 is a flow chart of additional, optional steps of the method shown in Fig. 2;
Fig. 9 is a signal diagram illustrating an embodiment of delaying requests for media segments; Fig. 10 is a signal diagram illustrating another embodiment of delaying requests for media segments; Fig. 11 is a flow chart of additional, optional steps of the method shown in Fig. 2; Fig. 12 is a flow chart illustrating a streaming method according to an embodiment; Fig. 13 is a flow chart illustrating a streaming method according to another embodiment;
Fig. 14 is a flow chart of additional, optional steps of the methods shown in Figs. 12 and 13; Fig. 15 is a schematic block diagram of a streaming server according to an embodiment; Fig. 16 is a schematic block diagram of a streaming server according to another embodiment; Fig. 17 is a schematic block diagram of a streaming server according to a further embodiment; Fig. 18 is a schematic block diagram of a user client according to an embodiment;
Fig. 19 is a schematic block diagram of a user client according to another embodiment;
Fig. 20 is a schematic block diagram of a user client according to a further embodiment; and Fig. 21 is a schematic block diagram of a computer program based implementation of embodiments.
DETAILED DESCRIPTION
Throughout the drawings, the same reference numbers are used for similar or corresponding elements. The present embodiments generally relate to streaming of media content, in particular to scheduling of requests for streamed media content.
The present embodiments are particularly suitable for usage in connection with adaptive streaming standards or specifications such as MPEG DASH and HLS. Such streaming standards or specifications use HTTP instead of traditional RTSP-based streaming solutions.
Fig. 1 schematically illustrates an overview of an example of a media distribution system 1 that can adopt the present embodiments. Media content, for instance live media content, are recorded or generated at one or more cameras or media engines 2. The media content is typically processed in a media preparation process at a computer, server or other media processing equipment 3. The media preparation process typically generates media segments comprising media components of the media content, such as MPEG DASH segments, also referred to as MPEG DASH media segments, or HLS segments, also referred to as HLS media segments. In a particular embodiment, such media segments comprise different encoded versions of one or several of the media components of the media content.
The media segments are then hosted on one or more media origin servers, HTTP servers or CDNs, denoted streaming servers 10 herein. User clients 20 request media segments from the streaming server 10 via HTTP over a wireless or mobile access network 5, and possibly through one or more HTTP caches or proxies 4. The network 5 may also or alternatively be a wired network 5.
The media segments are published at the streaming server 10. Publication of a media segment at the streaming server 10 corresponds to making the media segment available for download by a requesting user client 20. Thus, the publication time of a media segment at the streaming server 10 corresponds to the point in time from which the media segment can be requested by a user client 20 from the streaming server 10. Generally, the streaming server 10 provides media presentation information to the user client 20, such as in the form of a MPEG DASH Media Presentation Description (MPD). Such media presentation information enables the user client 20 to determine scheduled publication times of the respective media segments at the streaming server 10. The media presentation information thereby enables the user client 20 to schedule its request for media segments at the streaming server 10.
However, clock drift can cause a disparity between the clocks of the streaming server 10 and the user client 20. Such a disparity may in turn result in either early or late requests by the user client 20. In the former case, the relevant media segment has not yet been published at the streaming server 10 and is therefore not yet ready for transmission to the requesting user client 20 causing transmission of an error message or notification. In the latter case, delay will be added as the media segment will be available at the user client 20 at a later point in time than its publication time at the streaming server 10. The present embodiments can efficiently handle such a situation by providing time information to the user client 20 that can be used when scheduling requests for media contents even if there are any disparity between the clocks at the streaming server 10 and the user client 20.
Fig. 2 is a flow chart of a method for streaming multiple media segments comprising media components of a media content. The method comprises receiving a request for a media segment of the multiple media segments from a user client in step S1. A next step S2 comprises determining time information based on a reception time of the request for the media segment at a streaming server and a publication time of the media segment at the streaming sever. The method also comprises transmitting, to the user client and in step S3, the time information and the media segment or a notification that the media segment is not yet published at the streaming server.
The present embodiments thereby return time information to a requesting user client in addition to the requested media segment or a notification that the media segment is not yet published at the streaming server. This time information, which is determined based on the reception time of the request at the streaming sever and a publication time of the requested media segment at the streaming server, can then be used by the user client for scheduling requests for subsequent media segments and/or scheduling a re-request for the not yet published media segment. Accordingly, subsequent requests for media segments can be more correctly scheduled even if there is a disparity between clocks. This means that the user client can efficiently time or schedule its requests for media segments to points in time that reduce unnecessary delays or too early requests.
The method shown in Fig. 2 is in particular suitable as a method for adaptive streaming of multiple segments comprising different encoded versions of media components of a media content. For instance, video data or content may be available as encoded at different alternative bitrates and/or in the form of a bitstream useful for so called trick-mode play. Correspondingly, audio data or content may be available in different versions, such as representing different languages, different audio settings, such as stereo vs. surround sound, and/or different alternative bitrates. Fig. 3 is a flow chart illustrating an additional, optional step of the method in Fig. 2. The method starts in step S10, which comprises transmitting, to the user client, media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The method then continues to step S1 in Fig. 2.
This media presentation information could be regarded as manifest information allowing the user client to derive scheduled publication times of the media segments at the streaming sever. The media presentation information may, for instance, be in the form of a MPD. MPD generally describes a manifest of the available media content, its various alternatives, their Uniform Resource Locator (URL) and media characteristics, such as video resolution and bit rates.
The media presentation information, such as MPD, can be transmitted to the user client in step S10 according to various ways. For instance, the media presentation information can be delivered using HTTP, email, thumb drive, broadcast, or other transports as non-limiting examples. By parsing the MPD, the user client learns about the program timing, media-content availability, media types, resolutions, minimum and maximum bandwidths, and the existence of various encoded alternatives of media components, accessibility features and required Digital Rights Management (DRM), media- component locations on the network, and other content characteristics. Using this information, the user client can select the appropriate encoded alternative and start streaming the media content by fetching the media segments using HTTP GET requests.
For instance, for services with MPD@type- dynamic', the segment availability start time of a media segment can be determined as the sum of the value of MPD@availabilityStartTime, the PeriodStart time of the containing Period as defined in section 5.3.2.1 of document [4], the MPD start time of the media segment and the MPD duration of the media segment. More information of using information contained in the MPD to determine scheduled publication times of media segments can be found in section 5.3.9.5.3 of document [4].
Thus, the media presentation information transmitted to the user client in step S10 allows the user client to determine scheduled publication times, i.e. points in time at which the media segments of the media content should be available at the streaming server. However, due to, for instance, clock drift, a disparity between the clocks at the streaming server and the user client may imply that a scheduled publication time as determined by the user client according to its clock may be different from the actual publication time according to the clock at the streaming server. As a consequence, the user client may transmit its requests for media segments at too early or too late points in time with regard to the actual publication times according to the clock of the streaming server.
According to the embodiments, the time information transmitted to the user client in step S3 of Fig. 2 enables the user client to more correctly schedule its requests for media segments as compared to merely using the media presentation information transmitted to the user client in step S10 of Fig. 3.
In an embodiment, step S2 of Fig. 2 comprises determining the time information based on a difference between the reception time and an actual publication time of the media segment at the streaming server. Step S3 of Fig. 3 then comprises, in this embodiment, transmitting the time information and the media segment to the user client.
Thus, in this embodiment the streaming server has already published the media segment when it receives the request for the media segment from the user client. The streaming sever notifies the reception time at which it received the request according to its clock. The streaming server then determines the time information based on a difference between this reception time and the actual publication time according to its clock of the requested media segment. For instance, the time information could be defined as ti = - , wherein ti represents the time information, represents the reception time and represents the actual publication time.
Fig. 4 is a signal diagram illustrating signaling performed during a media streaming session according to an embodiment. The streaming server publishes a media segment N that is then available for requesting user clients. The user client determines a time of request for media segment N, preferably based on the previously received media description information, such as MPD. The user client transmits the request for media segment N to the streaming server, which receives the request and notifies the reception time according to its clock. The streaming server then measures or calculates a time difference between the actual publication time and the reception time of the request. The time information is generated based on this measured or calculated time difference. The requested media segment N and the time information are transmitted to the user client. The user client can then calculate an updated time of request for a next media segment, media segment N+1 , based on the received time information and preferably based on the received time information and the previously received media presentation information. Fig. 4 illustrates how the user client determines an updated time of request for media segment N+1 that in this case precedes an original time of request for media segment N+1. As can further be seen in the figure, this updated time occurs shortly after the publication time of media segment N+1 at the streaming server, whereas the original time occurs at a much later point in time.
Hence, if the user client would merely use the media description information to schedule its requests for media segments then the point in time represented by original time in Fig. 4 would be used to request for media segment N+1. This would cause a significant delay from the actual publication time of media segment N+1 and when the user client transmits its request for media segment N+1. However, if the user client in addition uses the time information received from the streaming server in connection with media segment N then the user client can determine an updated and more appropriate time of request for media segment N+1 that compensates for any disparity between the clock of the user client and the clock of the streaming server. In a particular embodiment, the updated time of request for media segment N+1 could be determined by the user client based on the original time of request for media segment N+1 , which in turn is determined based on the previously received media description information, and the time difference defined by the time information. For instance, the updated time could be determined as to - ti, wherein to represents the original time of request for media segment N+1.
For instance, when a user client requests a media segment from a streaming server, the streaming server calculates the time between when the media segment was published, and when it was requested by the user client. This time information is sent to the user client. For example, a user client receives a message indicating that the request was 500 ms late. It could then attempt to request the next media segment anything up to 500 ms earlier that it was previously going to.
In an embodiment, step S2 of Fig. 2 comprises determining the time information based on a difference between the reception time and a predicted publication time of the media segment at the streaming server. In this embodiment, step S3 preferably comprises transmitting the time information and the notification that the media segment is not yet published at the streaming server to the user client.
Thus, in this embodiment the streaming server has not yet published the media segment when it receives the request for the media segment from the user client. The streaming sever notifies the reception time at which it received the request according to its clock. The streaming server then determines the time information based on a difference between this reception time and the predicted publication time according to its clock of the requested media segment. For instance, the time information could be defined as ti = - tp, wherein tp represents the predicted publication time. The predicted publication time represents the time at which the streaming server predicts publication of the media segment. This predicted publication time can be determined according to various embodiments. For instance, the streaming server could use the previously transmitted media presentation information in order to determine the predicted publication time. The streaming server would then basically perform a similar calculation of scheduled publication times based on the media presentation information that the user clients does but with one large difference; the calculation is according to the clock of the streaming server and not according to the clock of the user client. Alternatively, or in addition, the streaming server could determine the predicted publication time based on actual publication times of previous media segments. For instance, a predicted publication time of media segment N+1 could be determined as actual publication time of media segment N plus a delta time. This delta time could then be the time difference between actual publication times of two previous consecutive media segments, such as media segment N and media segment N-1 , or an average time difference between actual publication times of several pairs of previous consecutive media segments.
Fig. 5 is a flow chart illustrating an additional, optional step representing the determination of the predicted publication time according to an embodiment. The method continues from step S1 in Fig. 2. A next step S20 comprises determining the predicted publication time based on a scheduled publication time of the media segment defined by media presentation information and respective deviations between scheduled publication times and actual publication times of previous media segments of the multiple media segments. The method then continues to step S2 of Fig. 2.
In this embodiment, the streaming server, thus, uses the scheduled publication time of the media segment as defined by the media presentation information, such as MPD, together with deviation information. This deviation information in turns represents deviations between scheduled publication times, as defined by the media presentation information, and actual publication times of previous media segments. For instance, the streaming server could calculate an average deviation for the previous media segments or a weighted average deviation preferably using larger weights for more recent previous media segments as compared to more distant previous media segments. Fig. 6 is a signal diagram illustrating signaling performed during a media streaming session according to an embodiment. The user client determines a time of request for media segment N, preferably based on the previously received media description information, such as MPD. The user client transmits the request for media segment N to the streaming server, which receives the request and notifies the reception time according to its clock. In this embodiment, the streaming server has not yet published media segment N. The streaming server therefore determines a predicted publication time of media segment N, such as discussed in the foregoing. The streaming server then determines the time information based on a difference between the reception time and the predicted publication time. The time information is transmitted to the user client and also a notification that media segment N is not yet published at the streaming server.
The user client uses the time information in order to calculate an updated time of request for media segment N, and optionally also for subsequent media segments represented by media segment N+1. This updated time of request is preferably calculated based on the original time of request for media segment N, as determined based on the media presentation information, and the time information, such as to + ti.
Once the clock of the user client indicates the update time the user client transmits a new request for media segment N to the streaming server. At this point in time the streaming server has published media segment N and thereby transmits the requested media segment N to the user client. The streaming server may optionally also determine time information as disclosed in Fig. 4 and transmit such time information to the user client in addition to media segment N.
The time information received together with or in connection with the notification is also, in this embodiment, used to calculate an updated time of request for media segment N+1 based on the original time of request for media segment N+1 , preferably as determined based on the media presentation information, and the time information. As is seen in Fig. 6, the original time of request for media segment N+1 precedes the publication time of media segment N+1 , whereas the updated time of request for media segment N+1 follows shortly after the publication time of media segment N+1.
Thus, if the user client would merely use the media presentation information in order to schedule its requests for media segments then such media segments would be transmitted too early, i.e. before the publication of the respective media segments at the streaming server. However, when the user client uses the time information of the embodiments it is able to determine more appropriate updated time of requests for the media segments that is adapted to the publication times of the media segments at the streaming server even if there may be any clock disparity between the user client and the streaming server. Should a user client request a media segment prematurely, the streaming server may be able to predict (to within a reasonable accuracy) the publication time at which the requested media segment will be available in the future. This time information can be sent by any method, such within or alongside a "404 - file not found" response. The user client can then reschedule its original request and all subsequent requests to account for the disparity.
The operations shown in Fig. 4 are thus performed if the reception time of the request for the media segment is after the publication time of the media segment, whereas the operations shown in Fig. 6 are performed if the reception time of the request for the media segment is prior to the publication time of the media segment.
The time information could be generated and transmitted to the user client in response to each request for a media segment. Alternatively, the streaming server transmits the time information with a selected periodicity, such as in response to every mth request for a media segment for some defined value ofm. In another alternative, the streaming server transmits the time information to the user client if the difference between the reception time and the publication time is sufficiently large. Such an alternative is illustrated in Fig. 7. The method continues from step S2 in Fig. 2, which in this embodiment comprises determining a difference between the reception time and the publication time. A next step S30 comprises comparing the difference (diff) with a threshold value (T). If the difference is equal to or larger than the threshold value the method continues to step S3, where the time information and the media segment are transmitted to the user client.
However, if the difference is smaller than the threshold value the method preferably continues to step S31 , which comprises transmitting the media segment to the user client.
Thus, in this embodiment the time information is transmitted to the user client only if the difference, i.e. the time information, equals or exceeds the threshold value. If the time information is small enough, implying that the request for the media segment was received shortly after the publication time at the streaming server, then no time information needs to be transmitted to the user client. Hence, only the media segment is transmitted to the user client in step S31.
Fig. 8 is a flow chart illustrating additional, optional steps of the method in Fig. 2 according to an embodiment. The method continues from step S1 in Fig. 2. A next step S40 comprises calculating a difference between the reception time and the publication time. The difference is compared with a threshold value in step S41. If the difference is equal to or larger than the threshold value the method continues to step S2 in Fig. 2, which comprises determining the time information based on the difference. However, if the difference is smaller than the threshold value, the method instead continues to step S42. This step S42 comprises determining the time information to represent a zero value. The method then continues to step S3 of Fig. 2.
Thus, in this embodiment the time information indicates a zero value as long as the difference between the reception time and the publication time is sufficiently small, i.e. as long as the request for the media segment is received within a short period of time from the publication time of the media segment.
The streaming server does not necessarily have to tell the truth when it generates the time information. This means that the streaming server could, for instance, set a larger value than the difference between the reception time and the publication time. This may be useful in order to induce a delay at the user client, which would decrease the chance of the user client making a too early request for a media segment that has not yet been published.
This approach may also be useful not only when delaying requests from user clients to prevent too early requests but also to achieve temporal load balancing when many user clients are requesting media segments from the streaming server.
Media segments are generally published relatively far apart - typically in the order of seconds. If many user clients are connected to a streaming server and the streaming server uses the previous embodiments to converge the requests at the publication time, its workload will spike very close to when media segments are published while it lays idle otherwise. As previously stated, the streaming server may instruct each user client differently so that they converge at different times, and the load on the streaming server is temporally spread. Hence, in an embodiment step S2 of Fig. 2 comprises determining the time information based on the reception time, the publication time and a delta time. In a particular embodiment, the time information is determined in step S2 based on a sum of the delta time and a difference between the reception time and the publication time, such as ti = to + to - tp, wherein to represents the delta time and tp represents the publication time.
Fig. 9 illustrates a signal diagram in which the streaming server is transmitting media segments to five different user clients. In this embodiment, the streaming server uses the delta times in order to schedule the requests from the five user clients to evenly spread the requests in order to distribute the workload of the streaming server over time. The streaming server will thereby receive requests at a steady rate instead of all at once close to the publication of the media segment.
Fig. 10 illustrates a signal diagram according to another embodiment. In this embodiment, the delta times are random values. If the number of connected user clients is large, this will provide statistically even temporal spread with minimal input form the streaming server. The random number each user client uses could remain the same for the duration of the media session, or could change over time. In the latter case, new random values may be generated at each time time information is determined at the streaming server Fig. 11 is a flow chart illustrating additional, optional steps of the method shown in Fig. 2. The method continues from step S1 , which comprises, in this embodiment, receiving multiple respective requests for the media segment from multiple user clients. The method continues to step S50, which comprises determining, for each user client of the multiple user clients, a respective delta time. A delta time determined for a first user client of the multiple user clients is determined in step S50 so that a sum of the delta time and a difference between a reception time of a request for the media segment originating from the first user client and the publication time is different from a sum of a delta time determined in step S50 for a second user client of the multiple user clients and a difference between a reception time of a request for the media segment originating from the second user client and the publication time. Thus, by either determining delta times for the user clients or randomly generating delta times the streaming server could distribute the points in time at which the user clients will transmit further requests for media segments. In a particular embodiment, the streaming server thereby determines the respective delta times so that not all user clients will transmit requests for media segments at the same time. Preferably, the streaming server determines the respective delta times so that no more than one or no more than a maximum defined number of user clients will transmit requests for media segments at the same time.
In the above described embodiments, the playback or play out of the media component of the media segment will not be synchronized between the user clients. If synchronized playback is desired the streaming server may add extra information relating to playback time to the user clients. Step S51 of Fig. 11 relates to such playback information. Hence, in an embodiment, step S51 comprises determining playback information defining a playback time of a media component of the media segment. The method then continues to step S2 in Fig. 2. Step S3 in Fig. 2 comprises, in this embodiment, transmitting the time information, the playback information and the media segment to the user client.
In a particular embodiment, step S51 comprises determining playback information defining a same playback time of the media component for the first user client and the second user client.
Thus, even if the first and second user clients will use different points in time when transmitting their respective requests for the media segment as defined by the received time information they will have a same playback time, i.e. synchronized playback, as defined by the playback information.
As is schematically illustrated in Figs. 9 and 10, the streaming server preferably determines the playback information so that all user clients or at least a minimum number thereof will have synchronized playback, i.e. use a same playback time of the media component.
The time information of the embodiments can be transmitted to the user client in step S3 according to various embodiments. For instance, the time information could be included in a HTTP header of a HTTP data packet containing, in addition to the HTTP header, a payload portion preferably comprising the media component or at least a portion thereof. In this embodiment, the time information is transmitted in-band together with the requested media segment. Also out-of-band solutions for transmitting the time information are possible and within the scope of the embodiments. Non-limiting examples of such an out-of-band transmission include using a Web socket, which is a protocol providing full-duplex communications channels over a single Transmission Control Protocol (TCP) connection, and Server-Sent Events (SSE), also referred to as event sources.
Other non-limiting examples of transmitting the time information could be using
· HTTP2 HEADERS frames;
• HTTP2 CONTINUATION frames;
• the user client request the time information in a separate request;
• Web Real-Time Communication (WebRTC) data channel; and
• a custom ISO Base Media File Format box in the media file itself.
The above described embodiments of transmitting the time information can also be used when transmitting the optional playback information.
The present embodiments are in particular suitable for usage in connection with MPEG DASH and HLS and other streaming services over HTTP, preferably adaptive streaming services over HTTP.
Hence, in an embodiment, the multiple media segments are multiple DASH media segments or multiple HLS segments. The method as shown in Fig. 2 then comprises a HTTP-based streaming server receiving, in step S1 , a HTTP GET request for a DASH or HLS media segment from a DASH-compliant or HLS-compliant user client. Step S2 comprises the HTTP-based streaming server determining time information based on a reception time of the HTTP GET request at the HTTP-based streaming server and a publication time of the DASH or HLS media segment at the HTTP-based streaming server. Step S3 preferably comprises the HTTP-based streaming server transmitting, to the DASH-compliant or HLS-compliant user client, the time information and the DASH or HLS media segment or a HTTP 404 Not Found error message.
Fig. 12 is a flow chart illustrating a streaming method according to an embodiment. The method comprises transmitting, in step S60 and to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. A next step S61 comprises receiving the media segment and time information from the streaming server. The following step S62 comprises determining a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information. The streaming method of Fig. 12 thereby corresponds to the actions performed by a user client when requesting a media segment from the streaming server and wherein the request is received at the streaming server following publication of the media segment, i.e. the reception time is subsequent to the publication time.
In a particular embodiment, step S62 comprises determining the time of transmitting the request for the subsequent media segment based on the time information and an original time of transmitting the request for the subsequent media segment determined based on the media presentation information.
In this embodiment, an updated time of transmitting the request is thereby determined based on the time information and the original time. The original time is in turn determined based on the media presentation information. This corresponds to operations performed at the client side in Fig. 4. In an embodiment, step S62 comprises determining the time of transmitting the request for the subsequent media segment based on a sum of the time information and the original time.
Fig. 13 is a flow chart illustrating a streaming method according to another embodiment. The method comprises transmitting, in step S70 and to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. A next step S71 comprises receiving a notification that the media segment is not yet published at the streaming server and time information from the streaming server. The following step S72 comprises determining a time of retransmitting a request for the media segment based on the time information and the media presentation information.
The streaming method of Fig. 13 thereby corresponds to the actions performed by a user client when requesting a media segment from the streaming server and wherein the request is received at the streaming server prior to publication of the media segment, i.e. the publication time is subsequent to the reception time.
In a particular embodiment, step S72 comprises determining the time of retransmitting the request for the media segment based on the time information and the time of transmitting the request for the media segment determined based on the media presentation information. In this embodiment, an updated time of retransmitting the request is thereby determined based on the time information and the original time of transmitting the request. The original time is in turn determined based on the media presentation information. This corresponds to operations performed at the client side in Fig. 6.
In an embodiment, step S72 comprises determining the time of retransmitting the request for the media segment based on a sum of the time information and the time of transmitting the request. Fig. 14 is a flow chart illustrating additional, optional steps of the methods shown in Fig. 12 and 13. The method starts in step S80, which comprises receiving the media presentation information from the streaming server. The following step S81 comprises determining the time of transmitting the request for the media segment based on the media presentation information. The method then continues to step S60 in Fig. 12 or step S70 in Fig. 13.
This means that the received media presentation information, such as in the form of a MPD, is used to determine the time of transmitting the request for the media segment in step S81.
Another aspect of the embodiments relates to a streaming server configured to stream multiple media segments comprising media components of a media content. The streaming server is configured to receive a request for a media segment of the multiple media segments from a user client. The streaming server is also configured to determine time information based on a reception time of the request for the media segment at the streaming server and a publication time of the media segment at the streaming server. The streaming server is further configured to transmit, to the user client, the time information and the media segment or a notification that the media segment is not yet published at the streaming server.
In an embodiment, the streaming server is configured to transmit, to the user client, media presentation information defining scheduled publication times of the multiple media segments at the streaming server.
In an embodiment, the streaming server is configured to determine the time information based on a difference between the reception time and an actual publication time of the media segment at the streaming server. In this embodiment, the streaming server is also configured to transmit the time information and the media segment to the user client.
In an embodiment, the streaming server is configured to determine the time information based on a difference between the reception time and a predicted publication time of the media segment at the streaming server. In this embodiment, the streaming server is also configured to transmit the time information and the notification that the media segment is not yet published at the streaming server to the user client. In an embodiment, the streaming sever is configured to determine the predicted publication time of the media segment based on a scheduled publication time of the media segment defined by media presentation information and respective deviations between scheduled publication times and actual publication times of previous media segments of the multiple media segments. In an embodiment, the streaming server is configured to determine a difference between the reception time and the publication time. The streaming server is also configured to compare the difference with a threshold value. The streaming server is further configured to transmit the time information and the media segment to the user client if the difference is equal to or larger than the threshold value. In this embodiment, the streaming server is preferably configured to merely transmit the media segment without any time information if the difference is smaller than the threshold value.
In an embodiment, the streaming server is configured to determine a difference between the reception time and the publication time. The streaming server is also configured to compare the difference with a threshold value. The streaming server is further configured to determine the time information based on the difference if the difference is equal to or larger than the threshold value. The streaming server is additionally configured to determine the time information to represent a zero value if the difference is smaller than the threshold value. In an embodiment, the streaming server is configured to determine the time information based on the reception time, the publication time and a delta time.
In an embodiment, the streaming server is configured to determine the time information based on a sum of the delta time and a difference between the reception time and the publication time. In an embodiment, the streaming server is configured to receive multiple respective requests for the media segment from multiple user clients. The streaming server is preferably configured to determine, for each user client of the multiple user client, a respective delta time. In an embodiment, a delta time determined for a first user client of the multiple user clients is determined so that a sum of the delta time and a difference between a reception time of a request for the media segment originating from the first user client and the publication time is different from a sum of a delta time determined for a second user client of the multiple user clients and a difference between a reception time of a request for the media segment originating from the second user client and the publication time.
In an embodiment, the streaming server is configured to determine playback information defining a playback time of a media component of the media segment. The streaming serer is also configured to transmit the time information, the playback information and the media segment to the user client. In an embodiment, the streaming server is configured to determine playback information defining a same playback time of the media component for the first user client and the second user client.
It will be appreciated that the methods and devices described herein can be combined and re-arranged in a variety of ways.
For example, embodiments may be implemented in hardware, or in software for execution by suitable processing circuitry, or a combination thereof.
The steps, functions, procedures, modules and/or blocks described herein may be implemented in hardware using any conventional technology, such as discrete circuit or integrated circuit technology, including both general-purpose electronic circuitry and application-specific circuitry.
Particular examples include one or more suitably configured digital signal processors and other known electronic circuits, e.g. discrete logic gates interconnected to perform a specialized function, or Application Specific Integrated Circuits (ASICs).
Fig. 15 illustrates a particular hardware implementation of the streaming server 100. In an embodiment, the streaming server 100 comprises a receiver 101 configured to receive the request for the media segment from the user client. The streaming server 100 also comprises an information determining unit 102 configured to determine the time information based on the reception time and the publication time. The streaming server 100 further comprises a transmitter 103 configured to transmit the time information and the media segment or the notification to the user client. In an embodiment, the receiver 101 is connected to the information determining unit 102 in order to forward the reception time to the information determining unit 102. The information determining unit 102 is in turn connected to the transmitter 103 for forwarding the time information thereto for transmission to the user client. Alternatively, at least some of the steps, functions, procedures, modules and/or blocks described herein may be implemented in software such as a computer program for execution by suitable processing circuitry such as one or more processors or processing units.
Examples of processing circuitry includes, but is not limited to, one or more microprocessors, one or more Digital Signal Processors (DSPs), one or more Central Processing Units (CPUs), video acceleration hardware, and/or any suitable programmable logic circuitry such as one or more Field Programmable Gate Arrays (FPGAs), or one or more Programmable Logic Controllers (PLCs).
It should also be understood that it may be possible to re-use the general processing capabilities of any conventional device or unit in which the proposed technology is implemented. It may also be possible to re-use existing software, e.g. by reprogramming of the existing software or by adding new software components.
In a particular example, the streaming server 110, see Fig. 16, comprises a processor 114 and a memory 115 comprising instructions executable by the processor 114. The processor 114 is operative to receive the request for the media segment from a receiver 111. The processor 114 is also operative to determine the time information based on the reception time and the publication time. The processor 114 is further operative to output the time information and the media segment or the notification for transmission by a transmitter 113.
In an embodiment, the streaming server 110 also comprises, in addition to the processor 114 and the memory 115, the receiver 111 and the transmitter 113 as shown in Fig. 16. In a particular embodiment, the processor 114 is operative, when executing the instructions stored in the memory 115, to perform the above described operations. The processor 114 is thereby interconnected to the memory 115 to enable normal software execution. Fig. 21 is, in an embodiment, a schematic block diagram illustrating an example of a streaming server 300 comprising a processor 310, an associated memory 320 and a communication circuitry 330.
In this particular example, at least some of the steps, functions, procedures, modules and/or blocks described herein are implemented in a computer program 340, which is loaded into the memory 320 for execution by processing circuitry including one or more processors 310. The processor 310 and memory 320 are interconnected to each other to enable normal software execution. A communication circuitry 330 is also interconnected to the processor 310 and/or the memory 320 to enable input of requests and output of time information and media segments or notifications. The term 'processor' should be interpreted in a general sense as any system or device capable of executing program code or computer program instructions to perform a particular processing, determining or computing task.
The processing circuitry including one or more processors is thus configured to perform, when executing the computer program, well-defined processing tasks such as those described herein.
The processing circuitry does not have to be dedicated to only execute the above-described steps, functions, procedure and/or blocks, but may also execute other tasks. In an embodiment, the computer program 340 comprises instructions, which when executed by the processor 310, cause the processor 310 to receive a request for a media segment of multiple media segments comprising media components of a media content from a user client. The processor 310 is also caused to determine time information based on a reception time of the request for the media segment at a streaming server 300 and a publication time of the media segment at the streaming server 300. The processor 310 is further caused to transmit, to the user client, the time information and the media segment or a notification that the media segment is not yet published at the streaming server 300. The proposed technology also provides a carrier 350 comprising the computer program 340. The carrier 350 is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium 350.
By way of example, the software or computer program 340 may be realized as a computer program product, which is normally carried or stored on a computer-readable medium 350, preferably nonvolatile computer-readable storage medium 350. The computer-readable medium 350 may include one or more removable or non-removable memory devices including, but not limited to a Read-Only Memory (ROM), a Random Access Memory (RAM), a Compact Disc (CD), a Digital Versatile Disc (DVD), a Blue-ray disc, a Universal Serial Bus (USB) memory, a Hard Disk Drive (HDD) storage device, a flash memory, a magnetic tape, or any other conventional memory device. The computer program 340 may thus be loaded into the operating memory 320 of a computer or equivalent processing device, represented by the streaming server 300 in Fig. 21 , for execution by the processor 310 thereof.
The flow diagram or diagrams presented herein may therefore be regarded as a computer flow diagram or diagrams, when performed by one or more processors. A corresponding streaming server may be defined as a group of function modules, where each step performed by the processor corresponds to a function module. In this case, the function modules are implemented as a computer program running on the processor. Hence, the streaming server may alternatively be defined as a group of function modules, where the function modules are implemented as a computer program running on at least one processor.
The computer program residing in memory may thus be organized as appropriate function modules configured to perform, when executed by the processor, at least part of the steps and/or tasks described herein. An example of such function modules is illustrated in Fig. 17 illustrating a schematic block diagram of a streaming server 120 with function modules. The streaming server 120 comprises an input unit 121 for inputting a request for a media segment of multiple media segments comprising media components of a media content received from a user client. The streaming server 120 also comprises an information determining unit 122 for determining time information based on a reception time of the request at the streaming server 120 and a publication time of the media segment at the streaming server 120. The streaming server 120 further comprises an output unit 123 for outputting the time information and the media segment or a notification that the media segment is not yet published at the streaming server 120 for transmission to the user client. The streaming server of the embodiments may be implemented in various ways such as in the form of a HTTP server or a media origin server. Also a distributed implementation is possible in the form multiple, i.e. at least two, HTTP or media origin servers or a CDN.
Another aspect of the embodiments relates to a user client. The user client is configured to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The user client is also configured to receive the media segment and time information from the streaming server. The user client is further configured to determine a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information. In an embodiment, the user client is configured to determine the time of transmitting the request for the subsequent media segment based on the time information and an original time of transmitting the request for the subsequent media segment determined based on the media presentation information.
In an embodiment, the user client is configured to determine the time of transmitting the request for the subsequent media segment based on a sum of the time information and the original time.
A further aspect of the embodiments relates to a user client that is configured to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The user client is also configured to receive a notification that the media segment is not yet published at the streaming server and time information from the streaming server. The user client is further configured to determine a time of retransmitting a request for the media segment based on the time information and the media presentation information.
In an embodiment, the user client is configured to determine the time of retransmitting the request for the media segment based on the time information and the time of transmitting the request for the media segment determined based on the media presentation information. In an embodiment, the user client is configured to determine the time of retransmitting the request for the media segment based on a sum of the time information and the time of transmitting the request for the media segment.
5 In an embodiment, the user client is configured to receive the media presentation information from the streaming server. The user client is also configured to determine the time of transmitting the request for the media segment based on the media presentation information.
Fig. 18 illustrates a particular hardware implementation of the user client 200. In an embodiment, the 10 user client 200 comprises a transmitter 201 configured to transmit the request for the media segment to the streaming server. The user client 200 also comprises a receiver 202 configured to receive the time information and the media segment or the notification from the streaming server. The user client 200 further comprises a time determining unit 203 configured to determine the time of transmitting the request for the subsequent media segment or the time of retransmitting the request for the media 15 segment based on the time information and the media presentation information.
Alternatively, at least some of the steps, functions, procedures, modules and/or blocks of the user client may be implemented in software such as a computer program for execution by suitable processing circuitry such as one or more processors or processing units.
20
Fig. 19 is a schematic illustration of an embodiment of the user client 210. The user client 210 comprises a processor 214 and a memory 215 comprising instructions executable by the processor 214. The processor 214 is operative to output the request for the media segment for transmission by a transmitter 213. The processor 214 is also operative to receive the time information and the media 25 segment or the notification from a receiver 211. The processor 214 is further operative to determine the time of transmitting the request for the subsequent media segment or the time of retransmitting the request for the media segment based on the time information and the media presentation information.
In an embodiment, the user client 210 also comprises, in addition to the processor 214 and the memory 30 215, the receiver 211 and the transmitter 213 as shown in Fig. 19.
In a particular embodiment, the processor 214 is operative, when executing the instructions stored in the memory 215, to perform the above described operations. The processor 214 is thereby interconnected to the memory 215 to enable normal software execution. Fig. 21 is, in an embodiment, a schematic block diagram illustrating an example of a user client 300 comprising a processor 310, an associated memory 320 and a communication circuitry 330. In this particular example, at least some of the steps, functions, procedures, modules and/or blocks described herein are implemented in a computer program 340, which is loaded into the memory 320 for execution by processing circuitry including one or more processors 310. The processor 310 and memory 320 are interconnected to each other to enable normal software execution. A communication circuitry 330 is also interconnected to the processor 310 and/or the memory 320 to enable output of requests for media segments and input of time information and media segments and/or notifications.
In an embodiment, the computer program 340 comprises instructions, which when executed by the processor 310, cause the processor 310 to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The processor 310 is also caused to receive the media segment and the time information from the streaming server. The processor 310 is further caused to determine a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
In another embodiment, the computer program 340 comprises instructions, which when executed by the processor 310, cause the processor 310 to transmit, to a streaming server, a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The processor 310 is also caused to receive a notification that the media segment is not yet published at the streaming server and time information from the streaming server. The processor 310 is further caused to determine a time of retransmitting a request for the media segment based on the time information and the media presentation information. The proposed technology also provides the previously mentioned a carrier 350 comprising the computer program 340.
The computer program residing in memory may be organized as appropriate function modules configured to perform, when executed by the processor, at least part of the steps and/or tasks described herein. An example of such function modules is illustrated in Fig. 20 illustrating a schematic block diagram of a user client 220 with function modules. The user client 220 comprises an output unit 221 for outputting a request for a media segment of multiple media segments comprising media components of a media content for transmission to a streaming server at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The user client 220 also comprises an input unit 222 for inputting the media segment and time information received from the streaming server. The user client 220 further comprises a time determining unit 223 for determining a time of transmitting a request for a subsequent media segment of the multiple media segments based on the time information and the media presentation information.
In another embodiment, the user client 220 of Fig. 20 comprises an output unit 221 for outputting a request for a media segment of multiple media segments comprising media components of a media content for transmission to a streaming server at a time determined based on media presentation information defining scheduled publication times of the multiple media segments at the streaming server. The user client 220 also comprises an in input unit 222 for inputting a notification that the media segment is not yet published at the streaming server and time information received from the streaming server. The user client 220 further comprises a time determining unit 223 for determining a time of retransmitting a request for the media segment based on the time information and the media presentation information.
The user client is preferably implemented as a DASH-compliant or HLS-compliant user client. The user client may be in the form of or implemented within a mobile device, such as a smart phone, mobile telephone, tablet, laptop; a computer; a set-top box; etc.
The embodiments described above are to be understood as a few illustrative examples of the present invention. It will be understood by those skilled in the art that various modifications, combinations and changes may be made to the embodiments without departing from the scope of the present invention. In particular, different part solutions in the different embodiments can be combined in other configurations, where technically possible. The scope of the present invention is, however, defined by the appended claims.
REFERENCES [1] ISO/IEC 23009-1 , 2014-01-17, Information technology - Dynamic adaptive streaming over HTTP
(DASH) - Part 1 : Media presentation description and segment form / Amendment 1 : High Profile and Availability Time Synchronization, MPEG document W14136
[2] ISO/IEC JTC1/SC29/WG11 MPEG2014/N14619, July 2014, Sapporo, Japan, Descriptions of
Core Experiments on DASH Amendment, Alex Giladi and Thomas Stockhammer
[3] Vetro, The MPEG-DASH Standard for Multimedia Streaming Over the Internet, IEEE MultiMedia,
18(4): 62-67, 2011
[4] ISO/IEC 23009-1 , Second edition, 2014-05-15, Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1 : Media presentation description and segment form

Claims

1. A method for streaming multiple media segments comprising media components of a media content, said method comprising:
receiving (S1) a request for a media segment of said multiple media segments from a user client (20);
determining (S2) time information based on a reception time of said request for said media segment at a streaming server (10) and a publication time of said media segment at said streaming server (10); and
transmitting (S3), to said user client (20), said time information and said media segment or a notification that said media segment is not yet published at said streaming server (10).
2. The method according to claim 1 , further comprising transmitting (S10), to said user client (20), media presentation information defining scheduled publication times of said multiple media segments at said streaming server (10).
3. The method according to claim 1 or 2, wherein
determining (S2) said time information comprises determining (S2) said time information based on a difference between said reception time and an actual publication time of said media segment at said streaming server (10); and
transmitting (S3) said time information comprises transmitting (S3) said time information and said media segment to said user client (20).
4. The method according to claim 1 or 2, wherein
determining (S2) said time information comprises determining (S2) said time information based on a difference between said reception time and a predicted publication time of said media segment at said streaming server (10); and
transmitting (S3) said time information comprises transmitting (S3) said time information and said notification that said media segment is not yet published at said streaming server (10) to said user client (20).
5. The method according to claim 4, further comprising:
determining (S20) said predicted publication time based on a scheduled publication time of said media segment defined by media presentation information and respective deviations between scheduled publication times and actual publication times of previous media segments of said multiple media segments.
6. The method according to any of the claims 1 to 5, wherein receiving (S1) said request comprising receiving (S1) multiple respective requests for said media segment from multiple user clients (20), said method further comprises determining (S50), for each user client (20) of said multiple user clients (20), a respective delta time, wherein a delta time determined for a first user client of said multiple user clients (20) is determined so that a sum of said delta time and a difference between a reception time of a request for said media segment originating from said first user client and said publication time is different from a sum of a delta time determined for a second user client of said multiple user clients (20) and a difference between a reception time of a request for said media segment originating from said second user client and said publication time.
7. The method according to claim 6, further comprising:
determining (S51) playback information defining a same playback time of a media component of said media segment for said first user client and said second user client, wherein transmitting (S3) said time information comprises transmitting said time information, said playback information and said media segment to said first user client and said second user client.
8. A streaming method comprising:
transmitting (S60), to a streaming server (10), a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of said multiple media segments at said streaming server (10);
receiving (S61) said media segment and time information from said streaming sever (10); and determining (S62) a time of transmitting a request for a subsequent media segment of said multiple media segments based on said time information and said media presentation information.
9. The method according to claim 8, wherein determining (S62) said time comprises determining (S62) said time of transmitting said request for said subsequent media segment based on said time information and an original time of transmitting said request for said subsequent media segment determined based on said media presentation information.
10. The method according to claim 9, wherein determining (S62) said time comprises determining (S62) said time of transmitting said request for said subsequent media segment based on a sum of said time information and said original time.
5 11. A streaming method comprising:
transmitting (S70), to a streaming server (10), a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of said multiple media segments at said streaming server (10);
10 receiving (S71) a notification that said media segment is not yet published at said streaming server (10) and time information from said streaming sever (10); and
determining (S72) a time of retransmitting a request for said media segment based on said time information and said media presentation information.
15 12. The method according to claim 11 , wherein determining (S72) said time comprises determining (S72) said time of retransmitting said request for said media segment based on said time information and said time of transmitting said request for said media segment determined based on said media presentation information.
20 13. The method according to claim 12, wherein determining (S72) said time comprises determining (S72) said time of retransmitting said request for said media segment based on a sum of said time information and said time of transmitting said request for said media segment.
14. The method according to any of the claims 8 to 13, further comprising:
25 receiving (S80) said media presentation information from said streaming server (10); and
determining (S81) said time of transmitting said request for said media segment based on said media presentation information.
15. A streaming server (10; 100; 110) configured to stream multiple media segments comprising 30 media components of a media content, wherein
said streaming server (10; 100; 110) is configured to receive a request for a media segment of said multiple media segments from a user client (20); said streaming server (10; 100; 110) is configured to determine time information based on a reception time of said request for said media segment at said streaming server (10; 100; 110) and a publication time of said media segment at said streaming server (10; 100; 110); and
said streaming server (10; 100; 110) is configured to transmit, to said user client (20), said time information and said media segment or a notification that said media segment is not yet published at said streaming server (10; 100; 110).
16. The streaming server according to claim 15, wherein said streaming server (10; 100; 110) is configured to transmit, to said user client (20), media presentation information defining scheduled publication times of said multiple media segments at said streaming server (10; 100; 110).
17. The streaming server according to claim 15 or 16, wherein
said streaming server (10; 100; 110) is configured to determine said time information based on a difference between said reception time and an actual publication time of said media segment at said streaming server (10; 100; 110); and
said streaming server (10; 100; 110) is configured to transmit said time information and said media segment to said user client (20).
18. The streaming server according to claim 15 or 16, wherein
said streaming server (10; 100; 110) is configured to determine said time information based on a difference between said reception time and a predicted publication time of said media segment at said streaming server (10; 100; 110); and
said streaming server (10; 100; 110) is configured to transmit said time information and said notification that said media segment is not yet published at said streaming server (10; 100; 110) to said user client (20).
19. The streaming server according to claim 18, wherein
said streaming server (10; 100; 110) is configured to determine said predicted publication time based on a scheduled publication time of said media segment defined by media presentation information and respective deviations between scheduled publication times and actual publication times of previous media segments of said multiple media segments.
The streaming server according to any of the claims 15 to 19, wherein said streaming server (10; 100; 110) is configured to determine a difference between said reception time and said publication time;
said streaming server (10; 100; 110) is configured to compare said difference with a threshold value; and
said streaming server (10; 100; 110) is configured to transmit said time information and said media segment to said user client (20) if said difference is equal to or larger than said threshold value.
21. The streaming server according to any of the claims 15 to 20, wherein
said streaming server (10; 100; 110) is configured to calculate a difference between said reception time and said publication time;
said streaming server (10; 100; 110) is configured to compare said difference with a threshold value; and
said streaming server (10; 100; 110) is configured to determine said time information based on said difference if said difference is equal to or larger than said threshold value; and
said streaming server (10; 100; 110) is configured to determine said time information to represent a zero value if said difference is smaller than said threshold value.
22. The streaming server according to any of the claims 15 to 21 , wherein said streaming server (10; 100; 110) is configured to determine said time information based on said reception time, said publication time and a delta time.
23. The streaming server according to claim 22, wherein said streaming server (10; 100; 110) is configured to determine said time information based on a sum of said delta time and a difference between said reception time and said publication time.
24. The streaming server according to any of the claims 15 to 23, wherein
said streaming server (10; 100; 110) is configured to receive multiple respective requests for said media segment from multiple user clients (20); and
said streaming server (10; 100; 110) is configured to determine, for each user client (20) of said multiple user clients (20), a respective delta time, wherein a delta time determined for a first user client of said multiple user clients (20) is determined so that a sum of said delta time and a difference between a reception time of a request for said media segment originating from said first user client and said publication time is different from a sum of a delta time determined for a second user client of said multiple user clients (20) and a difference between a reception time of a request for said media segment originating from said second user client and said publication time.
25. The streaming server according to claim 24, wherein
5 said streaming server (10; 100; 110) is configured to determine playback information defining a playback time of a media component of said media segment; and
said streaming server (10; 100; 110) is configured to transmit said time information, said playback information and said media segment to said user client (20).
10 26. The streaming server according to claim 25, wherein
said streaming server (10; 100; 110) is configured to determine playback information defining a same playback time of said media component for said first user client and said second user client.
27. The streaming server according to any of the claims 15 to 26 comprising:
15 a receiver (101) configured to receive said request for said media segment;
an information determining unit (102) configured to determine said time information based on said reception time and said publication time; and
a transmitter (103) configured to transmit said time information and said media segment or said notification to said user client (20).
20
28. The streaming server according to any of the claims 15 to 26 comprising:
a processor (114); and
a memory (115) comprising instructions executable by said processor (114), wherein said processor (114) is operative to receive said request for said media segment from a receiver
25 (111);
said processor (114) is operative to determine said time information based on said reception time and said publication time; and
said processor (114) is operative to output said time information and said media segment or said notification for transmission by a transmitter (113).
30
29. A streaming server (120) configured to stream multiple media segments comprising media components of a media content, said streaming server (120) comprises:
an input unit (121) for inputting a request for a media segment of said multiple media segments received from a user client (20); an information determining unit (122) for determining time information based on a reception time of said request for said media segment at said streaming server (120) and a publication time of said media segment at said streaming server (120); and
an output unit (123) for outputting said time information and said media segment or a notification that said media segment is not yet published at said streaming server (120) for transmission to said user client (20).
30. A user client (20; 200; 210), wherein
said user client (20; 200; 210) is configured to transmit, to a streaming server (10), a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of said multiple media segments at said streaming server (10);
said user client (20; 200; 210) is configured to receive said media segment and time information from said streaming sever (10); and
said user client (20; 200; 210) is configured to determine a time of transmitting a request for a subsequent media segment of said multiple media segments based on said time information and said media presentation information.
31. The user client according to claim 30, wherein said user client (20; 200; 210) is configured to determine said time of transmitting said request for said subsequent media segment based on said time information and an original time of transmitting said request for said subsequent media segment determined based on said media presentation information.
32. The user client according to claim 31 , wherein said user client (20; 200; 210) is configured to determine said time of transmitting said request for said subsequent media segment based on a sum of said time information and said original time.
33. A user client (20; 200; 210), wherein
said user client (20; 200; 210) is configured to transmit, to a streaming server (10), a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of said multiple media segments at said streaming server (10); said user client (20; 200; 210) is configured to receive a notification that said media segment is not yet published at said streaming server (10) and time information from said streaming sever (10); and
said user client (20; 200; 210) is configured to determine a time of retransmitting a request for said media segment based on said time information and said media presentation information.
34. The user client according to claim 33, wherein said user client (20; 200; 210) is configured to determine said time of retransmitting said request for said media segment based on said time information and said time of transmitting said request for said media segment determined based on said media presentation information.
35. The user client according to claim 34, wherein said user client (20; 200; 210) is configured to determine said time of retransmitting said request for said media segment based on a sum of said time information and said time of transmitting said request for said media segment.
36. The user client according to any of the claims 30 to 35, wherein
said user client (20; 200; 210) is configured to receive said media presentation information from said streaming server (10); and
said user client (20; 200; 210) is configured to determine said time of transmitting said request for said media segment based on said media presentation information.
37. The user client according to any of the claims 30 to 36, further comprising:
a transmitter (201) configured to transmit said request for said media segment to said streaming server (10);
a receiver (202) configured to receive said time information and said media segment or said notification from said streaming server (10); and
a time determining unit (203) configured to determine said time of transmitting said request for said subsequent media segment or said time of retransmitting said request for said media segment based on said time information and said media presentation information.
38. The user client according to any of the claims 30 to 36, further comprising:
a processor (214); and
a memory (215) comprising instructions executable by said processor (214), wherein said processor (214) is operative to output said request for said media segment for transmission by a transmitter (213);
said processor (214) is operative to receive said time information and said media segment or said notification from a receiver (211); and
5 said processor (214) is operative to determine said time of transmitting said request for said subsequent media segment or said time of retransmitting said request for said media segment based on said time information and said media presentation information.
39. A user client (220) comprising:
10 an output unit (221) for outputting a request for a media segment of multiple media segments comprising media components of a media content for transmission to a streaming server (10) at a time determined based on media presentation information defining scheduled publication times of said multiple media segments at said streaming server (10);
an input unit (222) for inputting said media segment and time information received from said 15 streaming sever (10); and
a time determining unit (223) for determining a time of transmitting a request for a subsequent media segment of said multiple media segments based on said time information and said media presentation information.
20 40. A user client (220) comprising:
an output unit (221) for outputting a request for a media segment of multiple media segments comprising media components of a media content for transmission to a streaming server (10) at a time determined based on media presentation information defining scheduled publication times of said multiple media segments at said streaming server (10);
25 an input unit (222) for inputting a notification that said media segment is not yet published at said streaming server (10) and time information received from said streaming sever (10); and
a time determining unit (223) for determining a time of retransmitting a request for said media segment based on said time information and said media presentation information.
30 41. A computer program (340) comprising instructions, which when executed by a processor (310), cause said processor (310) to
receive a request for a media segment of multiple media segments comprising media components of a media content from a user client (20); determine time information based on a reception time of said request at a streaming server (300) and a publication time of said media segment at said streaming server (300); and
transmit, to said user client (20), said time information and said media segment or a notification that said media segment is not yet published at said streaming server (300).
42. A computer program (340) comprising instructions, which when executed by a processor (310), cause said processor (310) to
transmit, to a streaming server (10), a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of said multiple media segments at said streaming server (10);
receive said media segment and time information from said streaming sever (10); and determine a time of transmitting a request for a subsequent media segment of said multiple media segments based on said time information and said media presentation information.
43. A computer program (340) comprising instructions, which when executed by a processor (310), cause said processor (310) to
transmit, to a streaming server (10), a request for a media segment of multiple media segments comprising media components of a media content at a time determined based on media presentation information defining scheduled publication times of said multiple media segments at said streaming server (10);
receive a notification that said media segment is not yet published at said streaming server (10) and time information from said streaming sever (10); and
determine a time of retransmitting a request for said media segment based on said time information and said media presentation information.
44. A carrier (350) comprising a computer program (340) according to any of the claims 41 to 43, wherein said carrier (350) is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.
PCT/SE2014/051530 2014-12-18 2014-12-18 Request scheduling for streamed media WO2016099354A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SE2014/051530 WO2016099354A1 (en) 2014-12-18 2014-12-18 Request scheduling for streamed media

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SE2014/051530 WO2016099354A1 (en) 2014-12-18 2014-12-18 Request scheduling for streamed media

Publications (1)

Publication Number Publication Date
WO2016099354A1 true WO2016099354A1 (en) 2016-06-23

Family

ID=52394307

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2014/051530 WO2016099354A1 (en) 2014-12-18 2014-12-18 Request scheduling for streamed media

Country Status (1)

Country Link
WO (1) WO2016099354A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3496414A1 (en) * 2017-12-07 2019-06-12 Canon Kabushiki Kaisha Video image distribution apparatus, control method, and recording medium
CN111526379A (en) * 2019-02-03 2020-08-11 华为技术有限公司 Data transmission method and data transmission device

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2528397A1 (en) * 2010-01-22 2012-11-28 Huawei Technologies Co., Ltd. Method and apparatus for synchronization based on hypertext transfer protocol (http)
US20140189052A1 (en) * 2012-12-28 2014-07-03 Qualcomm Incorporated Device timing adjustments and methods for supporting dash over broadcast
US20140195651A1 (en) * 2013-01-04 2014-07-10 Qualcomm Incorporated Live timing for dynamic adaptive streaming over http (dash)
WO2014108207A1 (en) * 2013-01-11 2014-07-17 Telefonaktiebolaget L M Ericsson (Publ) Technique for operating client and server devices in a broadcast communication network
US20140222962A1 (en) * 2013-02-04 2014-08-07 Qualcomm Incorporated Determining available media data for network streaming

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2528397A1 (en) * 2010-01-22 2012-11-28 Huawei Technologies Co., Ltd. Method and apparatus for synchronization based on hypertext transfer protocol (http)
US20140189052A1 (en) * 2012-12-28 2014-07-03 Qualcomm Incorporated Device timing adjustments and methods for supporting dash over broadcast
US20140195651A1 (en) * 2013-01-04 2014-07-10 Qualcomm Incorporated Live timing for dynamic adaptive streaming over http (dash)
WO2014108207A1 (en) * 2013-01-11 2014-07-17 Telefonaktiebolaget L M Ericsson (Publ) Technique for operating client and server devices in a broadcast communication network
US20140222962A1 (en) * 2013-02-04 2014-08-07 Qualcomm Incorporated Determining available media data for network streaming

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
"IEEE MultiMedia", VETRO, THE MPEG-DASH STANDARD FOR MULTIMEDIA STREAMING OVER THE INTERNET, vol. 18, no. 4, 2011, pages 62 - 67
"Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment form / Amendment 1: High Profile and Availability Time Synchronization, MPEG document W14136", ISO/IEC 23009-1, 17 January 2014 (2014-01-17)
"ISO/IEC 23009-1", 15 May 2014, article "Information technology -- Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment form"
ALEX GILADI; THOMAS STOCKHAMMER: "Sapporo, Japan, Descriptions of Core Experiments on DASH Amendment", ISO/IEC JTC1/SC29/WG11 MPEG2014/N14619, July 2014 (2014-07-01)
IMED BOUAZIZI ET AL: "SAND Parameters for 3GPP", 110. MPEG MEETING; 20-10-2014 - 24-10-2014; STRASBOURG; (MOTION PICTURE EXPERT GROUP OR ISO/IEC JTC1/SC29/WG11),, no. m35384, 24 October 2014 (2014-10-24), XP030063754 *
IRAJ SODAGAR: "The MPEG-DASH Standard for Multimedia Streaming Over the Internet", IEEE MULTIMEDIA, IEEE SERVICE CENTER, NEW YORK, NY, US, vol. 18, no. 4, 1 April 2011 (2011-04-01), pages 62 - 67, XP011378371, ISSN: 1070-986X, DOI: 10.1109/MMUL.2011.71 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3496414A1 (en) * 2017-12-07 2019-06-12 Canon Kabushiki Kaisha Video image distribution apparatus, control method, and recording medium
JP2019103087A (en) * 2017-12-07 2019-06-24 キヤノン株式会社 Video distribution device, control method, and program
US10778740B2 (en) 2017-12-07 2020-09-15 Canon Kabushiki Kaisha Video image distribution apparatus, control method, and recording medium
CN111526379A (en) * 2019-02-03 2020-08-11 华为技术有限公司 Data transmission method and data transmission device
CN111526379B (en) * 2019-02-03 2021-06-29 华为技术有限公司 Data transmission method and data transmission device

Similar Documents

Publication Publication Date Title
JP6783293B2 (en) Synchronizing multiple over-the-top streaming clients
US10880620B2 (en) Playback synchronization across playback devices
US10110657B2 (en) System and method for pushing live media content in an adaptive streaming environment
EP2870776B1 (en) Methods and devices for bandwidth allocation in adaptive bitrate streaming
US11758209B2 (en) Video distribution synchronization
US7979557B2 (en) Fast setup response prediction
JP2014500998A (en) Method and device for media description delivery
EP3391652B1 (en) Controlling retrieval in adaptive streaming
EP2999187A1 (en) Method, computer program product and server for streaming media content from a server to a client
US11503098B2 (en) Embedding MQTT messages in media streams
EP3393129A1 (en) Multimedia content delivery with reduced delay
EP2891323B1 (en) Rendering time control
EP2882191B1 (en) Synchronization of streaming data
WO2012046487A1 (en) Content reproduction device, content delivery system, synchronization method for content reproduction device, control program, and recording medium
WO2016068760A1 (en) Video stream synchronization
CN104396269A (en) Dynamic interstitial transitions
WO2016099354A1 (en) Request scheduling for streamed media
WO2019193991A1 (en) Distribution device, distribution method and program
US20220217192A1 (en) Synchronizing independent media and data streams using media stream synchronization points
EP3107261B1 (en) System, method and devices for low latency transmission
WO2016182481A1 (en) Scheduling in media stream sessions
US20230008021A1 (en) Synchronizing independent media and data streams using media stream synchronization points
WO2018021950A1 (en) Device and method for controlling media streaming from a server to a client

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14828574

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14828574

Country of ref document: EP

Kind code of ref document: A1