WO2020204801A1

WO2020204801A1 - Method and server for controlling a streaming session of a media asset

Info

Publication number: WO2020204801A1
Application number: PCT/SE2020/050346
Authority: WO
Inventors: Göran ALMGREN; Torbjörn EINARSSON; Kalle HENRIKSSON; Olov DANIELSSON
Original assignee: Edgeware Ab
Priority date: 2019-04-05
Filing date: 2020-04-02
Publication date: 2020-10-08
Also published as: SE1950432A1

Abstract

A method and a controlling server for controlling a streaming session of a media asset are provided. The media asset is divided into a plurality of individually addressable media asset segments corresponding to different time intervals and being accessible via one or more content delivery functions. According to the method a manifest file comprising addresses to the 5 media asset segments is sent from a controlling server to a client device. The addresses explicitly or implicitly specify the controlling server as host. A request for a media asset segment is then received from the client device to the controlling server and based on the received request, a media asset segment and a content delivery function is selected in the controlling server. A response comprising a redirection address to the selected media asset segment is sent from the 10 controlling server to the client device. The redirection address includes an indication of the selected content delivery function as host.

Description

METHOD AND SERVER FOR CONTROLLING A STREAMING SESSION OF A MEDIA ASSET

TECHNICAL FIELD

The present disclosure relates to the field of media asset streaming. More particularly the present disclosure relates to a method and controlling server for controlling a streaming session of a media asset.

BACKGROUND

Streaming of a media (e.g. video and associated content) asset over the Internet or other communication network, whether it being a live media stream having content that is not yet completely available, but is updated during the session, or a complete existing media asset being streamed on demand having complete assets which can be fully described with one manifest needs controlling from different aspects.

In certain media streaming applications, the media assets are fragmented into segments corresponding to different portions of the media asset and possibly also corresponding to different versions of the media assets. For example, a media asset relating to video may be fragmented to produce segments corresponding to different time ranges, such as seconds 0-6, 6-12 etc., of the video. The video may further be fragmented in relation to different versions, such as versions having respective quality levels of the video to be streamed. Hence, for each of the time ranges of the video, such as seconds 0-6, 6-12 etc., there may be segments corresponding to a respective quality level. Correspondingly, there may be other types of media such that audio and subtitle segments in one or multiple versions.

A client device wishing to retrieve a media asset, such a as a video, will need to request the segments of the media asset, such as the segments of the video. The client device will then first receive a manifest file after request, e.g. by means of a manifest Uniform Resource Locator (URL). The manifest file comprises identification of the segments, e.g. by means of an URL (absolute or relative) for each segment. The URLs generally indicate a host from which the segments can be retrieved and a location of the corresponding segment on that host. Typically the same host is identified for all segments. Once the manifest file has been provided to the client device, there is no possibility to alter its content without control of the client device, until an updated version of the manifest has been provided. This may happen for live video, but for on-demand video, the manifest is typically fetched once.

One drawback of the use of this type of manifest files is that it provides limited possibilities for adaptation for a specific session where a media asset is requested to a client device. For example, it could be desirable to be able to direct the retrieval of different segments from different hosts depending on varying conditions in the network or other.

According to one prior art method, adaptation in relation to different segments in a single session has been introduced by means of manipulation of manifests such that segment requests are distributed to different content delivery functions as hosts depending on various conditions. Content delivery functions may here be a node in a Content Delivery Network, a proxy or any other source of media segments. In such prior art methods, the URLs in a manifest file provided to a client device are rewritten such that different segments are retrieved from different hosts. One drawback with this prior art method is that the manifest file must consist of a list of segment URLs. For manifest files on another format where individual segment URLs cannot be controlled, such as for manifest files for Dynamic Adaptive Streaming over HTTP (DASH) using SegmentTemplate, this prior art method cannot be applied. Furthermore, changes of URLs during session playback can only be done in cases that manifest files are fetched multiple times, as for live sessions.

In other prior art methods the selection of content delivery function to use as host can be made on the client device side. One drawback with this prior art method is that the adaption can only be made based on information available in the client device, or by providing information to the client in a side channel. Such side-channel information is typically not standardized and therefore requires specific client-server integration in order to be able to steer the choice of adaptation or content delivery function by a media service provider and/or a network service provider.

SUMMARY

An object of the present disclosure is to provide a method and a controlling server which seeks to mitigate, alleviate, or eliminate one or more of the above-identified deficiencies in the art and disadvantages singly or in any combination. According to a first aspect, a method for controlling a streaming session of a media asset is provided. The media asset is divided into a plurality of individually addressable media asset segments corresponding to different time intervals and being accessible via one or more content delivery functions. According to the method, a manifest file comprising addresses to the media asset segments is sent from a controlling server to a client device. The addresses explicitly or implicitly specifying the controlling server as host. A request for a media asset segment is then received from the client device to the controlling server and based on the received request, a media asset segment and a content delivery function is selected in the controlling server. A response comprising a redirection address to the selected media asset segment is sent from the controlling server to the client device. The redirection address includes an indication of the selected content delivery function as host.

By the addresses explicitly or implicitly specifying the controlling server as host it is meant that for a manifest including a list of, or a template for generation of, absolute addresses, each address explicitly indicate the controlling server as host, whereas for a manifest including relative addresses it is implicit that the controlling server is host in view of the manifest being received from the controlling server.

By the redirect address including an indication of the content delivery function as host it is meant that the redirect address directs or leads the client device to the content delivery function to retrieve the requested media asset segment.

By providing a method for controlling a streaming session of a media asset according to the described aspect, it is possible to steer the segment requests to different content delivery functions. This is an advantage compared to methods relying on using the manifest to indicated segment-specific hosts, since it can be used for any type of manifest, and not only the ones which are based on using lists of segment addresses. In particular, template-based manifest files can be used where addresses, such as URLs, are functions of media asset segment number or times. Adaptation of which content delivery function to be used as host can then be made for each media asset segment separately since the manifest file will indicate the controlling server as host and the client device will first request a media asset segment from the controlling server which could then redirect the client device to use a selected address with a specific content delivery function as host. By selecting a content delivery function in response to a request for a media asset segment on a per segment basis, and sending a response comprising a redirection address including an indication of the selected content delivery function as host, the selection can be dynamically adapted on a per segment basis and the client device can potentially be directed to a new content delivery function as host for each new media asset segment requested. This is advantageous since it enables redirection of the request to the optimal content delivery function at the time of the request. For example, if a content delivery function has been used as host and there is an indication of congestion or other which indicates that the content delivery function should not be continued to be used as host, a new different content delivery function can be selected at that time to be used as host for retrieval to a client device of a segment being currently requested by the client device. Furthermore, the redirect decision may also be based on reduction of costs for delivery, or based on different characteristic of the content delivery functions. For example small vs large media asset segments can result in selection of servers optimized for different media such as RAM-based or SSD servers to reach higher performance.

An additional advantage is that redirection decisions such as streaming of segments from another content delivery function can be achieved without any interruption even after the manifest has been provided to the client device. Furthermore, and in contrast to prior art, a streaming session can be stopped even after the manifest has been provided to the client device and even if the streaming session is delivered from a content delivery function not owned and/or controlled by the media asset owner or session controller owner.

In embodiments, the addresses may either be relative or specify the controlling server as host explicitly.

In embodiments, the media asset segments corresponding to different time intervals that further correspond to variants, the request for a media asset segment further relates to a requested variant, and selecting a media asset segment and a content delivery function is further based on the requested variant. For example, variants of media asset segments may relate to different quality levels of the media to be streamed, such as different video resolutions. In such embodiments, the selected media asset segment in the redirect response may be different from the media asset segment signalled in the request. When receiving a request for a media asset segment corresponding to a time interval and a variant, a media asset segment corresponding to the same time interval but to a different variant may be selected. For example, a media asset segment corresponding to a variant with a lower quality level can be selected depending on current network conditions and/or priority of the client device requesting the media asset segment. This is advantageous since adaptation on a per segment basis can be made in relation to which media asset segment is delivered to a client device which enables an immediate selection of media segment variant based on requirements, limitations, priorities and/or availability at a client. The selection of media segment variant may also be based on requirements, limitations, priorities and/or availability at a server. The selection of media segment variant may also be based on requirements, limitations, priorities and/or availability of a network.

In further embodiments, selecting a media asset segment and a content delivery function is further based on a request time pattern of previously and currently requested media asset segments from the client device and/or from other client devices. This enables adaptation in relation to conclusions drawn from the request time pattern, i.e. the timing of requests over a selected period of time. For example, from a request time pattern for a client device it may be concluded that the client device is experiencing lack of bandwidth or other network limitation to receive media asset segments at a sufficient rate for playback of the media. The lack of bandwidth can be local or more widespread. Adaptation can be made to cope for such lack of bandwidth, e.g. by provision of a version with lower bitrate if such are provided, or attempting to change content delivery function used as host, i.e. from which a next media asset segment should be requested. Similarly, from a request time pattern for other client devices it may be concluded that there is a more general network congestion such that there is not sufficient amount of bandwidth for the client device to receive media asset segments at sufficient rate for uninterrupted playback of the media. From the request time pattern from other clients, it may be possible to determine if the lack of bandwidth is local or more widespread. Adaptation can then be made to cope for such lack of bandwidth, e.g. by provision of a version with lower bitrate if such are provided, or attempting to change content delivery function used as host, i.e. from which the requested media asset segment should be delivered. Selecting a media asset segment and content delivery function can be based on either the request time pattern of previously requested media asset segments from the client device or the request time pattern of previously requested media asset segments from other client devices, or on both.

In embodiments, selecting a media asset segment and a content delivery function is further based on requested media asset segments from the client device and/or from other client devices. This enables adaptation in relation to conclusions from which media asset segments are requested, e.g. over a selected period of time. For example, from a requested version of a media asset segment from a client device it may be concluded that a certain bandwidth and/or reliability will be required to receive the media asset segment, and generally also following media asset segments, at a sufficient rate for playback of the media. Adaptation can be made to provide for such required bandwidth and/or reliability, e.g. by provision of a version with lower bitrate if such are provided, or changing content delivery function used as host, i.e. from which a next media asset segment should be requested. Similarly, from a requested version of a media asset segment from other client devices it may be concluded that there is a more widespread required bandwidth and/or reliability to receive the media asset segment. Adaptation can be made to provide for such required bandwidth and/or reliability, e.g. by provision of a version with lower bitrate if such are provided, or changing content delivery function used as host, i.e. from which a next media asset segment should be requested. The adaptation can be further based on a priority of the client device, such that a client device with high priority will receive a requested variant of higher quality level before a client device with lower priority. Furthermore, for a client device with high priority, a content delivery function may be selected which can provide for such required bandwidth and/or reliability, whereas this may not be the case for a client device with lower priority. Selecting a media asset segment and content delivery function can be based on either the requested media asset segments from the client device or the requested media asset segments from other client devices, or on both.

In embodiments, a content delivery function is selected which has diagnostic capability of a network between itself or another content delivery function and the client device. This enables diagnostics of the network between itself, or another content delivery function, and the client device and further adaptive use of such diagnostics since selection of a content delivery function with such diagnostics can be made adaptively for each requested media asset segment. In embodiments, the controlling server receives a request for a further media asset segment from the client device. The controlling server then selects, based on the received request for a further media asset segment, a further media asset segment for sending from the controlling server. The controlling server then sends the selected further media asset segment to the client device. In such embodiments, the controlling server sends the selected further media asset segment itself rather than first selecting a content delivery function and sending a response to comprising a redirection address to the selected media asset segment to the client device, where the redirection address includes an indication of the selected content delivery function as host. This enables the controlling server to also function as a content delivery function for further adaptability of the delivery of media asset segments, and more precisely monitor the transmission process of the media segment.

In further embodiments, the addresses in the manifest file and the redirection addresses are Uniform Resource Locators (URLs), URLs and associated byte ranges, or templates that can be used to generate URLs. In such embodiments, Hypertext Transfer Protocol (HTTP) is typically used for the request for a media asset segment and HTTP redirect response is used for the response comprising a redirection address to the selected media asset segment.

In embodiments, a streaming format for the manifest and media asset segments is one of HTTP Live Streaming (HLS), Dynamic Adaptive Streaming over HTTP (DASH), and Microsoft Smoothstreaming. In embodiments, the media asset is a live or on-demand adaptive media asset. In the live case, the available segments may change over time and either requires updated manifests, or a method to calculate when segments are available. Two methods which don't require manifest updates are availability time calculations based on DASH manifest attributes and boxes inside Microsoft SmoothStreaming's (MSS) live segments that carry information about succeeding segments. The redirect method of controlling the segment requests still work. In the on-demand case, all the segments are available and are listed in a static manifest or inside a box in a media file on the server. Such boxes are "sidx" for MPEG DASH and "mfra" for MSS.

According to a second aspect, a controlling server is provided. The controlling server comprises processing circuitry and a memory. The memory contains instructions executable by the processing circuitry, whereby the controlling server is operative to perform the method of the first aspect.

It is to be noted that the controlling server need not be implemented as a separate physical entity. It may also be implemented as a virtual entity in a separate or same physical entity as other entities, e.g. in a cloud server or other network entity.

In embodiments of the second aspect the memory may contain further instructions executable by the processing circuitry, whereby the controlling server is operative to perform methods of any of the embodiments of the method of the first aspect.

According to a third aspect, a computer program is provided, comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method of the first aspect.

In embodiments of the third aspect the computer program may comprise one or more further instructions which when executed by the processing circuitry, cause the processing circuitry to perform methods of any of the embodiments of the method of the first aspect.

According to a fourth aspect, a computer program product is provided having stored thereon a computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method of the first aspect.

In embodiments of the fourth aspect the computer program may comprise one or more further instructions which when executed by the processing circuitry, cause the processing circuitry to perform methods of any of the embodiments of the method of the first aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing will be apparent from the following more particular description of the example embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the example embodiments.

Figure 1 is a block diagram illustrating a network in which an embodiment is implemented.

Figure 2 is a flowchart illustrating embodiments of a method. Figure 3 is a signalling diagram illustrating an exchange of signals in relation to an embodiment of a method.

Figure 4 is a block diagram illustrating an embodiment of a controlling server.

DETAILED DESCRIPTION

Aspects of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. The method and controlling server disclosed herein can, however, be realized in many different forms and should not be construed as being limited to the aspects set forth herein. Like numbers in the drawings refer to like elements throughout.

The terminology used herein is for the purpose of describing particular aspects of the disclosure only, and is not intended to limit the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

Figure 1 is a block diagram illustrating a network 100 in which embodiments of a method for controlling streaming of a media asset may be implemented. A user having a client device 110, which can be any type of device including a suitable media player software, such as a desktop or laptop computer, tablet, mobile phone, smart TV etc. with media player software. The client device is connected to a network 120, which may for example be the Internet, through any suitable connection means, such as for example one or a plurality of different types of wired links or wireless links, such as for example xDSL, cellular access, TCP/IP, WiFi, Bluetooth, WLL, optical fibre or a combination thereof. The user wants to stream a media asset, e.g. in the form of a video, from a media service provider entity 130. A controlling server 140 is then used to control retrieval of the media asset from one or more of a set of content delivery functions 150, 152, 154. It is to be noted that the media service provider entity 130, the controlling server 140, and the content delivery functions 150, 152, 153 need not be separate physical entities. Each of them may be implemented in a separate physical entity or may be implemented as a virtual entity in a separate or same physical entity, e.g. in a cloud server or other network entity.

Typically, a media asset to be provided by a media service provider from a media service provider entity 130, is divided into media asset segments. For example, a video may be divided into a number of segments each corresponding to a time interval of the video, such as a number of seconds of the video. The video segments may typically come in multiple variants corresponding to different qualities or viewing angles. The other media of a session, such as audio and subtitles, are typically fetched as separate media segments, but can be multiplexed with the video. The media asset segments are typically not delivered to the clients from the media service provider entity 130 directly, but from content delivery functions 150, 152, 154 which may be owned by the media service provider or a third party providing storing and streaming capability to the media service provider.

When the client requests a media asset, the client device will typically receive an index of all segments associated with the media asset. Such an index is generally called a manifest file or manifest, but may sometimes also referred to as a playlist. The manifest contains information about the media asset segments and a name and location for every media asset segment. Once the manifest has been received, the client device can start requesting the media asset segments from the location indicated in the manifest.

Figure 2 is a flowchart illustrating embodiments of a method for controlling a streaming session of a media asset, wherein the media asset is divided into a plurality of individually addressable media asset segments corresponding to different time intervals and being accessible via one or more content delivery functions. In a general embodiment, a manifest is sent 230 from a controlling server to a client device. The manifest file comprises addresses to the media asset segments, where the addresses include an indication of the controlling server as host. That indication may be that all addresses are relative URLs with respect to the address of the manifest. A request from the client device for a media asset segment is received 240 in the controlling server. Based on the received request, a media asset segment and a content delivery function is selected 245 in the controlling server. A response comprising a redirection address to the selected media asset segment is sent 250 from the controlling server to the client device. The redirection address includes an indication of the selected content delivery function as host, that typically may be in the form of an absolute URL. For HTTP, this would be a 3XX response with a Location header with an absolute segment URL.

In further embodiments of a method for controlling a streaming session of a media asset illustrated in the figure 2, the media asset is fragmented into segments corresponding to different portions of the media asset and possibly also corresponding to different versions of the media assets. For example, a media asset relating to video may be fragmented to produce segments corresponding to different time ranges, such as seconds 0-6, 6-12 etc., of the video. Other divisions of the media asset are possible, such as longer or shorter time ranges, varying time ranges etc. Furthermore, the video may further be fragmented in relation to different versions having respective quality levels of the video to be streamed, using different audio variants and/or subtitles etc. Hence, for each of the time ranges of the video, such as seconds 0-6, 6-12 etc., there may be segments corresponding to a respective quality level and in relation to different audio variants and/or subtitles etc.

A request is sent 205 to start a media session for a media asset asset_m. The request is sent from a client device/client to a controlling server/controller. For a case where HTTP is used, the request is sent as "GET https://ctri.com/3sset m/manifest.mpd". This step may be preceded by steps where the client requests the media asset from a separate server and is then redirected to the controller for requesting the media asset from the controller. In the controller, a unique session identifier sid_779 is generated 210 for the media session requested and a context comprised of information associated with that session ID sid_779. The context holds information about the media session such as ID of the client/user, ID of the media asset, requested media segments etc. The session identifier sid_779 is then sent 215 from the controller to the client. For a case where HTTP is used, the session identifier is sent via "302 REDIRECT: Location https://ctri.com/sid 779/asset m/manifest.mpd". However, any method may be used that makes the client to include the session identifier sid_779 in any subsequent calls to the controller relating to this media session, e.g. the session identifier may be included in a HTTP cookie.

The client then sends 220 a request for the media asset asset_m together with the session identifier sid_779. For a case where HTTP is used, the request is sent as "GET https://ctrl.com/sid 779/asset m/manifest.mpd" . The controller then looks up the session context created in 210 and validates 225 the session. For example, the controller may check if the session identifier sid_779 is valid for ID of the client/user and the ID of the media asset. The controller then sends 230 a manifest to the client. For the case using HTTP the manifest is sent using ("200 OK with the asset_m/manifest.mpd file returned as body of the message"). The manifest file is typically a text file and comprises identification of the media asset segments together with other data such as timing, bitrate, and language. In the manifest, or indirectly from the manifest address, the controller is identified as host for all media asset segments addresses with names parti, part2, part3 etc. The names may be specific for the session or they may be the same for all sessions. For a case using HTTP, the segments are identified by means of an URL (absolute or relative) for each segment. The controller may be explicitly included as the host part of the all segment request URLs from which the client tries to retrieve each media asset segment. For relative URLs, this includes the step of using the part of the URL of the manifest request as the base path, i.e. the controller is implicitly specified as host.

Alternatively, the controller may send a redirect so that the manifest will be requested from elsewhere.

The client sends 235 a request for a media asset segment partx to the controller indicating the sessionjd. For a case where HTTP is used, the request is sent as ""GET https://ctrl.com/sid 779/asset m/videol/partl.cmfv". The controller then receives 240 the request and selects 245 a media source cdf_a from where this media asset segment will be served, i.e. which content delivery function from which this media asset segment will be requested and served. As the selection is made on a per segment basis, different content delivery functions can be selected for different media asset segments to control the session. If the name parti is unique for the session, it has to be to be translated in the controller to a name in the redirect response that is known to the chosen content delivery function. The controller sends 250 a redirect address to the client indicating the media source cdf_a and the media asset segment parti or a translation thereof if required. For a case where HTTP is used "302 REDIRECT Location: httpsi//cdf a.com/sid 779/asset m/videol/partl.cmfv" is used. The client then sends 255 a request for partx to media_source_n. For a case where HTTP is used "GET https://cdf a.com/sid 779/asset m/videol/partl.cmfv" is used to request the media asset segment. The client then receives 260 the media asset segment parti from the media source cdf_a.

If the received parti is not the last media asset segment of the media asset, the method continues back to 235 where the client sends a request for a next media asset segment part2 to the controller indicating the session identifier sid_779. The method then continues until either the last media asset segment has been requested, the client has dropped the session, or the controller ends the session by blocking requests as described further below. For live assets, the process may involve an intermediate step of requesting an updated version of manifest from the controller to get an updated list of available segments.

Since all requests for media asset segments from the client are first sent to the controlling server as indicated in the manifest, the client's progress/behaviour can be tracked by these requests. If a session controller desires to stop the session before the last media asset segment is downloaded, it is possible by returning negative responses, e.g. such as HTTP 404 Not Found, to these requests. This is made possible by the use of first requesting the controller for all media asset segments and then identifying the content delivery function using redirect, so that the controller can intercept any segment request. It would not have been possible in prior art solutions where a manifest is provided indicating one or more content delivery functions from which media asset segments should be requested. In such prior art solutions, tracking progress/behaviour and stopping a session would require control of the content delivery functions and/or the client. When HTTP is used, all media URLs address the session controller and there is no content delivery function addresses among these URLs. This means that all types of HTTP streaming manifests including template-based ones are supported, and not just list-based manifest as for prior art solutions. In particular, this applies to the most common MPEG DASH mode which uses SegmentTemplate where individual segment URLs cannot be expressed. A further common HTTP streaming system is Microsoft Smoothstreaming which also uses a manifest with templates.

Media sessions can be monitored in detail in relation to for example selected media types (quality, language etc), segment request rate, and bytes requested from different content delivery functions. No specific functional requirements on the client device/client or content delivery function.

Monitoring the parameters can be used to estimate for example client Quality of Experience, client viewing patterns (pause, skip, zap, etc), and load on content delivery function. These estimates can then be used to automatically e.g. move or stop a media streaming session, or any immediate or later action that the media service provider wants. Furthermore, since all media asset segments are first requested from the controller, as the controller is either explicitly specified as host in the manifest file or implicitly specified as host from the fact that the manifest was retrieved from the controller, the controller can register whether or not a specific media asset segment has been requested. This can for example be used to check if one or more media asset segments relating to advertisements or other additional content has been requested. If the one or more media asset segments have not been requested, requests for other media asset segments can be denied by a negative response. This is advantageous for example to prevent local blocking of media asset segments relating to advertisements or other additional content in a client device for a user with a subscription which requires streaming of advertisements or other additional media assets.

Furthermore, using unique names for the media asset segments indicated in the manifest file which is known only to the controller will have an advantage that it will be difficult for a client device to identify media asset segments which are part of advertisements or other additional media assets and block them from being rendered. The unique name of the media asset segment known only to the controller will be translated back to a non-session-unique name when sending a redirect to the media asset segment after a first request from the client.

Furthermore, since the controlling server may require that all requests from the clients include the sessionjd, it is possible to change to a different content delivery function in the middle of any session for both live and video on demand (VoD) services depending on any session-specific data. That this can be done dynamically is not only advantageous for the live case but also in the VoD case compared to manifest-based segment routing according to prior art where the segment URLs must be determined at the generation time of the manifest.

Furthermore, prior art solutions using rewrite of manifests at manifest generation time with individual URLs for each segment are only possible for list-based manifests like HLS and DASH with SegmentList.

Hence, according to the embodiments, the controlling server can choose content delivery function on a per segment basis based on performance, price and many other factors. It can also redirect to a lower bitrate than requested or stop a session by refusing to deliver a requested segment. The segment requests, together with the data in the manifest, also provide information about the currently used bandwidth, language and other special variant information that allows for detailed monitoring.

This enables moving of decisions that in prior art have been done in the client to the controller enabling more control to a media service provider and enabling less complex clients, as well as avoiding or decreasing the need to develop proprietary integration with the client in order to achieve session control and monitoring.

Even if reference has been to HTTP, any protocol that enables a controlling server to redirect the client to another source could also be used.

Figure 2 comprises some steps which are illustrated in boxes with a solid border and some steps which are illustrated in boxes with a dashed border. The steps which are comprised in boxes with a solid border are operations which are comprised in the broadest example embodiment. The steps which are comprised in boxes with a dashed border are example embodiments which may be comprised in, or a part of, or are further operations which may be taken in addition to the operations of the border example embodiments. The steps do not all need to be performed in order and not all of the operations need to be performed.

It should be appreciated that the example operations of Figure 2 may be performed simultaneously for any number of users and client devices in the network.

Figure 3 is a signalling diagram illustrating an exchange of signals in relation to embodiments of a method described in relation to figure 2. Reference numerals referring to the steps illustrated in the flow chart of figure 2 are include in figure 3 and identify the signalling performed in the corresponding steps. Reference signs on the arrows indicate signalling and reference signs in relation to the vertical line under the indication "Controller" indicates steps performed in the controller. Arrows with dashed lines indicate redirect.

First a request is sent 205 to start a media session for a media asset asset_m ("GET https://ctrl.com/asset m/manifest.mpd" in case of HTTP). A unique session identifier sid_779 is generated 210 in the controller. The session identifier sid_779 is then sent 215 from the controller to the client.

In some implementations, the step 205 will be preceded by a request to start the media session for the media asset asset_m to an entry server ("GET https://entrv.com/asset m/manifest.mpd" in case of HTTP). The session identifier sid_779 is in this implementation generated in the entry server instead of in the controller and the entry server sends a redirect address that includes the session identifier to the client to retrieve the manifest from the controller

(302 REDIRECT: Location https://ctrl.CQ m/sid 779/asset m/manifest.mpd" in case of HTTP).

The client then sends 220 a request for the media asset asset_m together with the session identifier sid_779 ("GET https://ctrl.com/sid 779/asset m/manifest.mpd" in case of HTTP). The controller then validates 225 the session, e.g. by means of a unique token that may include the session identifier sid_779. The controller then sends 230 a manifest to the client indicating media asset segments parti, part2, part3 etc ("200 OK with the asset_m/manifest.mpd file returned as body of the message" in case of HTTP). The manifest may either include absolute addresses which explicitly specify the controller as host or it may include relative addresses which implicitly specify the controller by host in view of the fact that the manifest was retrieved from the controller. The client sends 235 a request for a media asset segment parti to the controller indicating the session identifier sid_779

("GET https://ctrl.com/sid 779/asset m/videol/partl.cmfv" in case of HTTP). The controller then receives 240 the request and selects 245 a media source from where the media asset segment will be served. In this case the media source cdf_a is selected. The controller sends 250 a redirect address to the client indicating the media source cdf_a and parti ("302 REDIRECT Location: https://cdf a. com/sid 779/asset m/videol/partl.cmfv" in case of HTTP). The client then sends 255 a request for parti to the media source cdf_a ("GET https://cdf a.com/sid 779/asset m/videol/partl.cmfv" in case of HTTP). The client then receives 260 parti from the media source cdf_a ("200 OK with media segment parti as body" in case of HTTP).

If the received parti is not the last segment of the media asset, the method continues to 235 where the client sends a request for a next media asset segment part2 to the controller indicating the session identifier sid_779

("GET https://ctrl.com/sid 779/asset /videol/part2.cmfv" in case of HTTP). The controller then receives 240 the request and may select 245 a different media source cdf_b from where this media asset segment will be served. The controller sends 250 a redirect address to the client indicating the media source cdf_b and part2 (302 REDIRECT Location: https://cdf b.com/sid 779/asset m/videol/part2.cmfv" in case of HTTP). The client then sends 255 a request for part2 to the media source cdf_b (GET https://cdf b.com/sid 779/asset m/videol/part2.cmfy" in case of HTTP). The client then receives 260 part2 from the media source cdf_b ("200 OK with media segment part2 as body" in case of HTTP).

Figure 4 is a block diagram illustrating embodiments of a controlling server 400 which may incorporate at least some of the example embodiments discussed above. As shown in Figure 4, the controlling server 400 may comprise processing circuitry 410. The processing circuitry 410 may be any suitable type of computation unit, e.g. a microprocessor, digital signal processor (DSP), field programmable gate array (FPGA), or application specific integrated circuit (ASIC) or any other form of circuitry. It should be appreciated that the processing circuitry need not be provided as a single unit but may be provided as any number of units or circuitry.

The controlling server 400 may further comprise at least one memory unit or circuitry 420 that may be in communication with the processing circuitry 410. The memory 420 may be configured to store executable program instructions 430. The memory 420 may be any suitable type of computer readable memory and may be of volatile and/or non-volatile type.

Figure 4 is a block diagram illustrating embodiments of a controlling server 400 for configuration in a network. The network may for example be a network as illustrated in Figure 1.

In an embodiment of the control unit illustrated in Figure 4 the memory 420 contains instructions 430 executable by the processing circuitry 410, whereby the embodiment of the controlling server 400 is operative to perform embodiments of the method illustrated in Figure 2 and described hereinabove.

It is to be noted that the controlling server 400 need not be implemented as a separate physical entity. It may also be implemented as a virtual entity in a separate or same physical entity as other entities, e.g. in a cloud server or other network entity.

Embodiments may be implemented in a computer program, comprising instructions 430 which, when executed by processing circuitry 410, cause the processing circuitry 410 to perform embodiments of the method of the disclosure. Embodiments may be implemented in a computer program product 420 having stored thereon a computer program comprising instructions 430 which, when executed by processing circuitry 410, cause the processing circuitry 410 to perform embodiments of the method of the disclosure. Aspects of the disclosure are described with reference to the drawings. It is understood that several entities in the drawings, e.g., blocks of the block diagrams, and also combinations of entities in the drawings, can be implemented by computer program instructions, which instructions can be stored in a computer-readable memory, and also loaded onto a computer or other programmable data processing apparatus. Such computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer and/or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer and/or other programmable data processing apparatus, create means for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks. In the drawings and specification, there have been disclosed exemplary aspects of the disclosure. However, many variations and modifications can be made to these aspects without substantially departing from the principles of the present disclosure. Thus, the disclosure should be regarded as illustrative rather than restrictive, and not as being limited to the particular aspects discussed above. Accordingly, although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation.

It should be noted that the word "comprising" does not necessarily exclude the presence of other elements or steps than those listed and the words "a" or "an" preceding an element do not exclude the presence of a plurality of such elements. It should further be noted that any reference signs do not limit the scope of the claims, that the example embodiments may be implemented at least in part by means of both hardware and software, and that several "means", "units" or "devices" may be represented by the same item of hardware.

In the drawings and specification, there have been disclosed exemplary embodiments. However, many variations and modifications can be made to these embodiments. Accordingly, although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the embodiments being defined by the following claims.

Claims

1. A method for controlling a streaming session of a media asset, wherein the media asset is divided into a plurality of individually addressable media asset segments corresponding to different time intervals and being accessible via one or more content delivery functions, the method comprising:

sending, from a controlling server to a client device, a manifest file comprising addresses to the media asset segments, the addresses explicitly or implicitly specifying the controlling server as host;

receiving, from the client device to the controlling server, a request for a media asset segment;

selecting, in the controlling server, based on the received request, a media asset segment and a content delivery function;

sending, from the controlling server to the client device, a response comprising a redirection address to the selected media asset segment, the redirection address including an indication of the selected content delivery function as host.

2. The method according to claim 1, wherein selecting a media asset segment and a content delivery function is further based on a request time pattern of previously requested media asset segments from the client device and/or from other client devices.

3. The method according to any one of claims 1 and 2, wherein selecting a media asset segment and a content delivery function is further based on requested media asset segments from the client device and/or from other client devices.

4. The method according to any one of claims 1-3, wherein a content delivery function is selected which has diagnostic capability of a network between a content delivery server and the client device.

5. The method according to any one of claims 1-4, further comprising:

receiving, from the client device to the controlling server, a request for a further media asset segment; and selecting, in the controlling server, based on the received request for a further media asset segment, a further media asset segment for sending from the controlling server;

sending, from the controlling serverto the client device, the selected further media asset segment.

6. The method according to any one of claims 1-5, wherein the addresses in the manifest file and the redirection addresses are Uniform Resource Locators (URLs), URLs and associated byte ranges, or templates that can be used to generate URLs.

7. The method according to claim 6, wherein Hypertext Transfer Protocol (HTTP) is used for the request for a media asset segment and HTTP redirect response is used for the response comprising a redirection address to the selected media asset segment.

8. The method according to any one of claims 1-7, wherein a streaming format for the manifest and media asset segments is one of HTTP Live Streaming (HLS), Dynamic Adaptive Streaming over HTTP (DASH), and Microsoft Smoothstreaming.

9. The method according to any one of claims 1-8, wherein the media asset segments corresponding to different time intervals further correspond to variants, the request for a media asset segment further relates to a requested variant, and selecting a media asset segment and a content delivery function is further based on the requested variant.

10. The method according to claim 9, wherein the selected media asset segment in the response is different from the media asset segment in the request.

11. The method according to any one of claims 1-10, wherein the media asset is a live or on- demand adaptive media asset.

12. A controlling server comprising processing circuitry and a memory, said memory containing instructions executable by said processing circuitry, whereby said controlling server is operative to perform the method of any one of claim 1-11.

13. A computer program, comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method according to any one of claims 1-11.

14. A computer program product having stored thereon a computer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method according to any one of claims 1-11.