SE1950432A1 - Method and server for controlling a streaming session of a media asset - Google Patents

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 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 controlling server to the client device. The redirection address includes an indication of the selected content delivery function as host.

Description

1l\/IETHOD AND SERVER FOR CONTROLLING A STREAl\/IING SESSION OF A MEDIA ASSET TECHNICAL FIELD The present disclosure relates to the field of media asset streaming. More particularly thepresent disclosure relates to a method and controlling serverforcontrolling a streaming session of a media asset.

BACKGROUND Streaming of a media (e.g. video and associated content) asset over the Internet or othercommunication network, whether it being a live media stream having content that is not yetcompletely available, but is updated during the session, or a complete existing media assetbeing streamed on demand having complete assets which can be fully described with one manifest needs controlling from different aspects. ln certain media streaming applications, the media assets are fragmented into segmentscorresponding to different portions of the media asset and possibly also corresponding todifferent versions of the media assets. For example, a media asset relating to video may befragmented 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 ofthe time ranges of the video, such as seconds 0-6, 6-12 etc., there may be segmentscorresponding 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 thesegments of the media asset, such as the segments of the video. The client device will then firstreceive 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 thesegments can be retrieved and a location of the corresponding segment on that host. Typicallythe 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 2an updated version ofthe 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 foradaptation for a specific session where a media asset is requested to a client device. Forexample, 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 singlesession has been introduced by means of manipulation of manifests such that segment requestsare 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 anyother source of media segments. ln such prior art methods, the URLs in a manifest file providedto 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 ofsegment URLs. For manifest files on another format where individual segment URLs cannot becontrolled, such as for manifest files for Dynamic Adaptive Streaming over HTTP (DASH) usingSegmentTemplate, this prior art method cannot be applied. Furthermore, changes of URLsduring session playback can only be done in cases that manifest files are fetched multiple times, as for live sessions. ln other prior art methods the selection of content delivery function to use as host can be madeon the client device side. One drawback with this prior art method is that the adaption can onlybe made based on information available in the client device, or by providing information to theclient in a side channel. Such side-channel information is typically not standardized andtherefore requires specific client-server integration in order to be able to steer the choice ofadaptation 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 seeksto mitigate, alleviate, or eliminate one or more of the above-identified deficiencies in the art and disadvantages singly or in any combination. 3According to a first aspect, a method for contro||ing a streaming session of a media asset isprovided. The media asset is divided into a plurality of individually addressable media assetsegments corresponding to different time intervals and being accessible via one or morecontent delivery functions. According to the method, a manifest file comprising addresses tothe media asset segments is sent from a contro||ing server to a client device. The addressesexplicitly or implicitly specifying the contro||ing server as host. A request for a media assetsegment is then received from the client device to the contro||ing server and based on thereceived request, a media asset segment and a content delivery function is selected in thecontro||ing server. A response comprising a redirection address to the selected media assetsegment is sent from the contro||ing 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 contro||ing server as host it is meant thatfor a manifest including a list of, or a template for generation of, absolute addresses, eachaddress explicitly indicate the contro||ing server as host, whereas for a manifest includingrelative addresses it is implicit that the contro||ing server is host in view of the manifest being received from the contro||ing server.

By the redirect address including an indication of the content delivery function as host it ismeant 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 contro||ing a streaming session of a media asset according to thedescribed aspect, it is possible to steer the segment requests to different content deliveryfunctions. This is an advantage compared to methods relying on using the manifest to indicatedsegment-specific hosts, since it can be used for any type of manifest, and not only the oneswhich are based on using lists of segment addresses. ln particular, template-based manifestfiles can be used where addresses, such as URLs, are functions of media asset segment numberor times. Adaptation of which content delivery function to be used as host can then be madefor each media asset segment separately since the manifest file will indicate the contro||ingserver as host and the client device will first request a media asset segment from the contro||ingserver 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 ona per segment basis, and sending a response comprising a redirection address including anindication of the selected content delivery function as host, the selection can be dynamicallyadapted on a per segment basis and the client device can potentially be directed to a newcontent delivery function as host for each new media asset segment requested. This isadvantageous since it enables redirection of the request to the optimal content deliveryfunction at the time of the request. For example, if a content delivery function has been usedas host and there is an indication of congestion or other which indicates that the contentdelivery function should not be continued to be used as host, a new different content deliveryfunction can be selected at that time to be used as host for retrieval to a client device of asegment being currently requested by the client device. Furthermore, the redirect decision mayalso be based on reduction of costs for delivery, or based on different characteristic of thecontent delivery functions. For example small vs large media asset segments can result inselection of servers optimized for different media such as RAI\/I-based or SSD servers to reach higher performance.

An additional advantage is that redirection decisions such as streaming of segments fromanother content delivery function can be achieved without any interruption even after themanifest has been provided to the client device. Furthermore, and in contrast to prior art, astreaming session can be stopped even after the manifest has been provided to the client deviceand 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. ln embodiments, the addresses may either be relative or specify the controlling server as host explicitly. ln embodiments, the media asset segments corresponding to different time intervals thatfurther correspond to variants, the request for a media asset segment further relates to arequested variant, and selecting a media asset segment and a content delivery function isfurther based on the requested variant. For example, variants of media asset segments may relate to different quality levels ofthe media to be strea med, such as different video resolutions. 5ln such embodiments, the selected media asset segment in the redirect response may bedifferent from the media asset segment signalled in the request. When receiving a request fora media asset segment corresponding to a time interval and a variant, a media asset segmentcorresponding 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 selecteddepending on current network conditions and/or priority of the client device requesting themedia asset segment. This is advantageous since adaptation on a per segment basis can bemade in relation to which media asset segment is delivered to a client device which enables animmediate selection of media segment variant based on requirements, limitations, prioritiesand/or availability at a client. The selection of media segment variant may also be based onrequirements, limitations, priorities and/or availability at a server. The selection of mediasegment variant may also be based on requirements, limitations, priorities and/or availability of a network. ln further embodiments, selecting a media asset segment and a content delivery function isfurther based on a request time pattern of previously and currently requested media assetsegments from the client device and/or from other client devices. This enables adaptation inrelation to conclusions drawn from the request time pattern, i.e. the timing of requests over aselected period of time. For example, from a request time pattern for a client device it may beconcluded that the client device is experiencing lack of bandwidth or other network limitationto receive media asset segments at a sufficient rate for playback of the media. The lack ofbandwidth can be local or more widespread. Adaptation can be made to cope for such lack ofbandwidth, e.g. by provision of a version with lower bitrate if such are provided, or attemptingto change content delivery function used as host, i.e. from which a next media asset segmentshould be requested. Similarly, from a request time pattern for other client devices it may beconcluded that there is a more general network congestion such that there is not sufficientamount of ba ndwidth for the client device to receive media asset segments at sufficient rate foruninterrupted playback of the media. From the request time pattern from other clients, it maybe possible to determine if the lack of bandwidth is local or more widespread. Adaptation canthen be made to cope for such lack of bandwidth, e.g. by provision of a version with lowerbitrate 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 6segment and content delivery function can be based on either the request time pattern ofpreviously 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. ln embodiments, selecting a media asset segment and a content delivery function is furtherbased on requested media asset segments from the client device and/or from other clientdevices. This enables adaptation in relation to conclusions from which media asset segmentsare requested, e.g. over a selected period of time. For example, from a requested version of amedia asset segment from a client device it may be concluded that a certain bandwidth and/orreliability will be required to receive the media asset segment, and generally also followingmedia asset segments, at a sufficient rate for playback of the media. Adaptation can be madeto provide for such required bandwidth and/or reliability, e.g. by provision of a version withlower bitrate if such are provided, or changing content delivery function used as host, i.e. fromwhich a next media asset segment should be requested. Similarly, from a requested version ofa media asset segment from other client devices it may be concluded that there is a morewidespread 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. byprovision of a version with lower bitrate if such are provided, or changing content deliveryfunction used as host, i.e. from which a next media asset segment should be requested. Theadaptation can be further based on a priority of the client device, such that a client device withhigh priority will receive a requested variant of higher quality level before a client device withlower priority. Furthermore, for a client device with high priority, a content delivery functionmay be selected which can provide for such required bandwidth and/or reliability, whereas thismay not be the case for a client device with lower priority. Selecting a media asset segment andcontent 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. ln embodiments, a content delivery function is selected which has diagnostic capability of anetwork between itself or another content delivery function and the client device. This enablesdiagnostics of the network between itself, or another content delivery function, and the clientdevice 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. 7ln embodiments, the controlling server receives a request for a further media asset segmentfrom the client device. The controlling server then selects, based on the received request for afurther media asset segment, a further media asset segment for sending from the controllingserver. The controlling server then sends the selected further media asset segment to the clientdevice. ln such embodiments, the controlling server sends the selected further media assetsegment itself rather than first selecting a content delivery function and sending a response tocomprising 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 functionas host. This enables the controlling server to also function as a content delivery function forfurther adaptability of the delivery of media asset segments, and more precisely monitor the transmission process of the media segment. ln further embodiments, the addresses in the manifest file and the redirection addresses areUniform Resource Locators (URLs), URLs and associated byte ranges, or templates that can beused to generate URLs. ln such embodiments, Hypertext Transfer Protocol (HTTP) is typicallyused 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. ln embodiments, a streaming format for the manifest and media asset segments is one of HTTPLive Streaming (HLS), Dynamic Adaptive Streaming over HTTP (DASH), and I\/|icrosoft SmoothStreaming. ln embodiments, the media asset is a live or on-demand adaptive media asset. ln the live case,the available segments may change over time and either requires updated manifests, or amethod to calculate when segments are available. Two methods which don't require manifestupdates are availability time calculations based on DASH manifest attributes and boxes insideI\/|icrosoft SmoothStreaming's (MSS) live segments that carry information about succeedingsegments. The redirect method of controlling the segment requests still work. ln the on-demandcase, 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 8processing circuitry, whereby the controlling server is operative to perform the method of the first aspect. lt is to be noted that the controlling server need not be implemented as a separate physicalentity. lt 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. ln embodiments ofthe second aspect the memory may contain further instructions executableby 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. ln embodiments of the third aspect the computer program may comprise one or more furtherinstructions 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 acomputer program comprising instructions which, when executed by processing circuitry, cause the processing circuitry to perform the method ofthe first aspect. ln embodiments of the fourth aspect the computer program may comprise one or more furtherinstructions 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 exampleembodiments, as illustrated in the accompanying drawings in which like reference charactersrefer 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. 9Figure 3 is a signalling diagram illustrating an exchange of signals in relation to an embodiment ofa 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 theaccompanying drawings. The method and controlling server disclosed herein can, however, berealized 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 disclosureonly, 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 forcontrolling 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 desktopor laptop computer, tablet, mobile phone, smart TV etc. with media player software. The clientdevice is connected to a network 120, which may for example be the Internet, through anysuitable connection means, such as for example one or a plurality of different types of wiredlinks 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 formof a video, from a media service provider entity 130. A controlling server 140 is then used tocontrol retrieval ofthe media asset from one or more of a set of content delivery functions 150,152, 154. lt 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 ofthem 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 serviceprovider 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 ofthe video, such as a number of seconds of the video. The video segments may typically come in multiple variantscorresponding to different qualities or viewing angles. The other media of a session, such asaudio and subtitles, are typically fetched as separate media segments, but can be multiplexedwith the video. The media asset segments are typically not delivered to the clients from themedia service provider entity 130 directly, but from content delivery functions 150, 152, 154which 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 allsegments associated with the media asset. Such an index is generally called a manifest file ormanifest, but may sometimes also referred to as a playlist. The manifest contains informationabout the media asset segments and a name and location for every media asset segment. Oncethe 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 sessionof a media asset, wherein the media asset is divided into a plurality of individually addressablemedia asset segments corresponding to different time intervals and being accessible via one ormore content delivery functions. ln a general embodiment, a manifest is sent 230 from acontrolling server to a client device. The manifest file comprises addresses to the media assetsegments, where the addresses include an indication of the controlling server as host. Thatindication may be that all addresses are relative URLs with respect to the address of themanifest. A request from the client device for a media asset segment is received 240 in thecontrolling server. Based on the received request, a media asset segment and a content deliveryfunction is selected 245 in the controlling server. A response comprising a redirection addressto the selected media asset segment is sent 250 from the controlling server to the client device.The redirection address includes an indication ofthe 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. ln further embodiments of a method for controlling a streaming session of a media assetillustrated 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 11the media assets. For example, a media asset relating to video may be fragmented to producesegments 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, varyingtime ranges etc. Furthermore, the video may further be fragmented in relation to differentversions having respective quality levels of the video to be streamed, using different audiovariants and/or subtitles etc. Hence, for each of the time ranges of the video, such as seconds0-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 sentfrom a client device/client to a controlling server/controller. For a case where HTTP is used, the request is sent as ”GET httpsz//ctrLcom/asset m/manifestmpd”. This step may be preceded by steps where the client requests the media asset from a separate server and is then redirectedto the controller for requesting the media asset from the controller. In the controller, a uniquesession identifier sid_779 is generated 210 for the media session requested and a contextcomprised of information associated with that session ID sid_779. The context holdsinformation 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 thecontroller to the client. For a case where HTTP is used, the session identifier is sent via”302 REDIRECT: Location httpsz//ctrkcom/sid 7?9/asset mfnïanifestaflfapd”. However, any method may be used that makes the client to include the session identifier sid_779 in anysubsequent 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 httpsz//ctrkcorn/sid ïïë/asset m/rraariifesxirnpd” . The controller then looks up the session context created in 210 and validates 225 the session. For example, the controller maycheck if the session identifier sid_779 is valid for ID of the client/user and the ID of the mediaasset. The controller then sends 230 a manifest to the client. For the case using HTTP themanifest is sent using (”200 OK with the asset_m/manifest.mpd file returned as body of themessage"). 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, 12or indirectly from the manifest address, the controller is identified as host for all media assetsegments addresses with names partl, part2, part3 etc. The names may be specific for thesession or they may be the same for all sessions. For a case using HTTP, the segments areidentified by means of an URL (absolute or relative) for each segment. The controller may beexplicitly included as the host part of the all segment request URLs from which the client triesto retrieve each media asset segment. For relative URLs, this includes the step of using the partof 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 session_id. For a case where HTTP is used, the request is sent as ””GET httpsz/fctrLcosn/sid 779/asset m/videol/part1.cmf\/". The controller then receives 240 the request and selects 245 a media source cdf_a from where this media asset segment will beserved, i.e. which content delivery function from which this media asset segment will berequested and served. As the selection is made on a per segment basis, different contentdelivery functions can be selected for different media asset segments to control the session. lfthe name part1 is unique for the session, it has to be to be translated in the controller to a namein the redirect response that is known to the chosen content delivery function. The controllersends 250 a redirect address to the client indicating the media source cdf_a and the media assetFor a case where HTTP is used segment part1 or a translation thereof if required. ”302 REDIRECT Location: httpsz//cdf acorra/sid 779/asset m/video1/part1,c:nfv" is used. The client then sends 255 a request for partx to media_source_n. For a case where HTTP is used ”GET httpsz//cdf acom/sid 779/asset m/videoíipartícmfv” is used to request the media asset segment. The client then receives 260 the media asset segment part1 from the media source cdf_a. lf the received part1 is not the last media asset segment of the media asset, the methodcontinues back to 235 where the client sends a request for a next media asset segment part2 tothe 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 13controller ends the session by blocking requests as described further below. For live assets, theprocess 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 serveras indicated in the manifest, the client's progress/behaviour can be tracked by these requests.lf a session controller desires to stop the session before the last media asset segment isdownloaded, 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 mediaasset segments and then identifying the content delivery function using redirect, so that thecontroller can intercept any segment request. lt would not have been possible in prior artsolutions where a manifest is provided indicating one or more content delivery functions fromwhich media asset segments should be requested. ln such prior art solutions, trackingprogress/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 contentdelivery function addresses among these URLs. This means that all types of HTTP streamingmanifests including template-based ones are supported, and not just list-based manifest as forprior art solutions. ln particular, this applies to the most common MPEG DASH mode which usesSegmentTemplate where individual segment URLs cannot be expressed. A further commonHTTP streaming system is I\/|icrosoft SmoothStreaming which also uses a manifest with templates.

I\/|edia 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 contentdelivery 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. Theseestimates 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. 14Furthermore, since all media asset segments are first requested from the controller, as thecontroller is either explicitly specified as host in the manifest file or implicitly specified as hostfrom the fact that the manifest was retrieved from the controller, the controller can registerwhether or not a specific media asset segment has been requested. This can for example beused to check if one or more media asset segments relating to advertisements or otheradditional content has been requested. lf the one or more media asset segments have not beenrequested, requests for other media asset segments can be denied by a negative response. Thisis advantageous for example to prevent local blocking of media asset segments relating toadvertisements 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 filewhich is known only to the controller will have an advantage that it will be difficult for a clientdevice to identify media asset segments which are part of advertisements or other additionalmedia assets and block them from being rendered. The unique name of the media assetsegment 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 includethe session_id, it is possible to change to a different content delivery function in the middle ofany session for both live and video on demand (VoD) services depending on any session-specificdata. That this can be done dynamically is not only advantageous for the live case but also inthe 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 withindividual 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 deliveryfunction on a per segment basis based on performance, price and many other factors. lt canalso 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 controllerenabling more control to a media service provider and enabling less complex clients, as well asavoiding 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 stepswhich are illustrated in boxes with a dashed border. The steps which are comprised in boxeswith 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 whichmay be comprised in, or a part of, or are further operations which may be taken in addition tothe operations ofthe border example embodiments. The steps do not all need to be performed in order and not all of the operations need to be performed. lt 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 ofa method described in relation to figure 2. Reference numerals referring to the steps illustratedin the flow chart of figure 2 are include in figure 3 and identify the signalling performed in thecorresponding steps. Reference signs on the arrows indicate signalling and reference signs inrelation 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 (”GETlittpsJ/ctrLcom/asset m/manifestmpd” 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. ln 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 16 (”GETlfttpsz//erttrg/.cornlasset m/'rraanifest.rnpd" in case of HTTP). The session identifier sid_779 is in this implementation generated in the entry server instead of in the controller andthe entry server sends a redirect address that includes the session identifier to the client tofrom the controller retrieve the manifest (302 REDIRECT: Location httpsJ/ctrlcom/sid Zfïšš/asset mimanifestmpd” 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 httpsz//ctrlcom/sid Ti9fasset m/fnariifestmpd” in case of HTTP). The controller then validates 225 the session, e.g. by means of a unique token that may include thesession identifier sid_779. The controller then sends 230 a manifest to the client indicatingmedia asset segments partl, part2, part3 etc (”200 OK with the asset_m/manifest.mpd filereturned as body of the message” in case of HTTP). The manifest may either include absoluteaddresses which explicitly specify the controller as host or it may include relative addresseswhich implicitly specify the controller by host in view of the fact that the manifest was retrievedfrom the controller. The client sends 235 a request for a media asset segment partl to thecontroller session identifier indicating the sid_779 (”GET littpsz//ctrLcorn/sid ïfïfä/asset ni/všdeol/partLcmfv” in case of HTTP). The controller then receives 240 the request and selects 245 a media source from where the media assetsegment will be served. ln this case the media source cdf_a is selected. The controller sends 250a redirect address to the client indicating the media source cdf_a and partl(”302 REDIRECT Location: httbsg/icdf acom/sid Yifiš/asset m/videol/partlcmfv” in case of HTTP).

The client then sends 255 a request for partl to the media source cdf_a (”GET httpsz/'lcdf acorn/sid ïïšàlasset m/všdeo1/bart1.crïtfv" in case of HTTP). The client then receives 260 partl from the media source cdf_a (”200 OK with media segment partl as body” in case of HTTP). lf the received partl is not the last segment of the media asset, the method continues to 235where the client sends a request for a next media asset segment part2 to the controllersession identifier indicating the sid_779 (”GET httpsz//ctrlcom/'sid YYFB/asset m/viaåeoii/parflcmfv” in case of HTTP). The controller then receives 240 the request and may select 245 a different media source cdf_b from wherethis media asset segment will be served. The controller sends 250 a redirect address to the client indicating the media source cdf_b and part2 17(302 REDIRECT Location: httpsJ/ctåf bcont/sšd 779/'asset rra/videoí/partlcrrafv” in case of HTTP). The client then sends 255 a request for part2 to the media source cdf_b (GET httpsz//cdf imorn/sid ï/“Yà/asset m/videol/partlcmfxfl' 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 mayincorporate at least some ofthe example embodiments discussed above. As shown in Figure 4,the controlling server 400 may comprise processing circuitry 410. The processing circuitry 410may 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) orany other form of circuitry. lt 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 thatmay be in communication with the processing circuitry 410. The memory 420 may beconfigured 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. ln an embodiment of the control unit illustrated in Figure 4 the memory 420 containsinstructions 430 executable by the processing circuitry 410, whereby the embodiment of thecontrolling server 400 is operative to perform embodiments of the method illustrated in Figure 2 and described hereinabove. lt is to be noted that the controlling server 400 need not be implemented as a separate physicalentity. lt 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. 18Embodiments may be implemented in a computer program product 420 having stored thereona computer program comprising instructions 430 which, when executed by processing circuitry410, 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. lt is understood thatseveral entities in the drawings, e.g., blocks of the block diagrams, and also combinations ofentities in the drawings, can be implemented by computer program instructions, whichinstructions can be stored in a computer-readable memory, and also loaded onto a computeror other programmable data processing apparatus. Such computer program instructions can beprovided to a processor of a general purpose computer, a special purpose computer and/orother programmable data processing apparatus to produce a machine, such that theinstructions, which execute via the processor ofthe computer and/or other programmable dataprocessing apparatus, create means for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks. ln the drawings and specification, there have been disclosed exemplary aspects of thedisclosure. However, many variations and modifications can be made to these aspects withoutsubstantially departing from the principles of the present disclosure. Thus, the disclosureshould be regarded as illustrative rather than restrictive, and not as being limited to theparticular 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. lt should be noted that the word ”comprising” does not necessarily exclude the presence ofother elements or steps than those listed and the words ”a” or ”an” preceding an element donot exclude the presence of a plurality of such elements. lt should further be noted that anyreference signs do not limit the scope of the claims, that the example embodiments may beimplemented at least in part by means of both hardware and software, and that several H ll ”means , units” or ”devices” may be represented by the same item of hardware. ln 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 19not for purposes of limitation, the scope of the embodiments being defined by the following claims.

Claims (14)

CLAll\/IS

1. A method for controlling a streaming session of a media asset, wherein the media assetis divided into a plurality of individually addressable media asset segments corresponding todifferent time intervals and being accessible via one or more content delivery functions, themethod comprising: sending, from a controlling server to a client device, a manifest file comprising addressesto the media asset segments, the addresses explicitly or implicitly specifying the controllingserver as host; receiving, from the client device to the controlling server, a request for a media assetsegment; selecting, in the controlling server, based on the received request, a media assetsegment and a content delivery function; sending, from the controlling server to the client device, a response comprising aredirection address to the selected media asset segment, the redirection address including an indication ofthe selected content delivery function as host.

2. The method according to claim 1, wherein selecting a media asset segment and acontent 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 assetsegment 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 isselected which has diagnostic capability ofa 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 21selecting, in the controlling server, based on the received request for a further mediaasset 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 manifestfile 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 usedfor 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 themanifest 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 segmentscorresponding to different time intervals further correspond to variants, the request for a mediaasset segment further relates to a requested va riant, 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 memorycontaining instructions executable by said processing circuitry, whereby said controlling server is operative to perform the method of any one of claim 1-11.

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

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