URL parameter insertion and addition in adaptive streaming

A method implemented by a client device for media content streaming, the method comprising inserting one or more query parameters in a query string portion of a uniform resource locator (URL), wherein the query string portion follows a path portion of the URL, sending a media request comprising the URL to a streaming server, and receiving one or more segments of a media content from the streaming server in response to the media request.

Not applicable.

REFERENCE TO A MICROFICHE APPENDIX

Not applicable.

BACKGROUND

A media content provider or distributor may deliver media contents to various client devices such as televisions, notebook computers, and mobile handsets. The media content provider may support a plurality of media encoder and/or decoders (codecs), media players, video frame rates, spatial resolutions, bit-rates, video formats, or combinations thereof. A media content may be converted from a source representation to various other representations to suit the different user devices.

A media content may comprise a media presentation description (MPD) and a plurality of segments. The MPD may be an extensible markup language (XML) file describing the media content, such as its various representations, uniform resource locators (URLs), and other characteristics. As one of ordinary skill in the art understands, the media content may be divided into various hierarchies including periods, adaptation sets (AS), representations, and segments.

In adaptive streaming, when a media content is delivered to a client or user device, the user device may select appropriate segments dynamically based on a variety of factors, such as network conditions, device capability, and user choice. Adaptive streaming may include various technologies or standards implemented or being developed, such as Dynamic Adaptive Streaming over Hypertext Transfer Protocol (HTTP) (DASH), HTTP Live Streaming (HLS), or Internet Information Services (IIS) Smooth Streaming. For example, the user device may select a segment with the highest quality (e.g., resolution or bit-rate) possible that can be downloaded in time for playback without causing stalling or rebuffering events in the playback. Thus, the user device may seamlessly adapt its media content playback to changing network conditions.

In adaptive streaming, there may be needs to specify and construct URLs for accessing streaming media segments, in order to provide flexibility and reduce complexity of streaming MPDs, such as the ones used in Moving Picture Expert Group (MPEG) DASH. Some existing solutions, such as URL parameter insertion mechanisms in the URL template specification in the DASH standard, may support parameter specification for URL parameter insertion (or substitution) with simple types. Thus, it is desirable to expand the capability of URL parameter insertion, e.g., to include more types of parameters.

SUMMARY

In one embodiment, the disclosure includes a method implemented by a client device for media content streaming, the method comprising inserting one or more query parameters in a query string portion of a uniform resource locator (URL), wherein the query string portion follows a path portion of the URL, sending a media request comprising the URL to a streaming server, and receiving one or more segments of a media content from the streaming server in response to the media request.

In another embodiment, the disclosure includes an apparatus comprising a receiver configured to receive a media presentation description (MPD) comprising a URL template for a media content, a processor coupled to the receiver and configured to construct a URL based on the URL template, wherein the URL comprises a path portion and a query string portion following the path portion, and wherein the query string portion comprises one or more query parameters, and a transmitter coupled to the processor and configured to transmit a request for the media content to a streaming server, wherein the request comprises the constructed URL.

In yet another embodiment, the disclosure includes a method implemented by a network server for media content streaming, the method comprising receiving a URL from a streaming client, wherein the URL comprises a path and a query string following the path, wherein the query string comprises one or more query parameters, determining one or more segments of a media content to use for the streaming client based on at least one of the received query parameters, and sending the one or more segments to the streaming client.

In yet another embodiment, the disclosure includes an apparatus comprising a receiver configured to receive a URL from a streaming client, wherein the URL comprises a path and a query string following the path, wherein the query string comprises one or more query parameters, a processor coupled to the receiver and configured to determine one or more segments of a media content to use for the streaming client based on at least one of the received query parameters, and a transmitter coupled to the processor and configured to transmit the one or more segments to the streaming client.

DETAILED DESCRIPTION

It may be understood at the outset that, although an illustrative implementation of one or more embodiments are provided below, the disclosed systems and/or methods may be implemented using any number of techniques, whether currently known or in existence. The disclosure may in no way be limited to the illustrative implementations, drawings, and techniques illustrated below, including the exemplary designs and implementations illustrated and described herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.

The present disclosure teaches embodiments to construct a media segment URL by inserting parameters into a query string portion of the URL rather than substituting parameters in the path portion of the URL. URL parameter information may be specified to allow both static and dynamic URL parameter insertion (or substitution). Various types of parameters including parameters from other namespaces, optional and mandatory parameters, and/or query request parameters may be inserted. Processing rules may also be applied to construct URLs based on specified URL parameter information. Inserting parameters into the query string portion may allow a streaming server to manage or control adaptive streaming, e.g., by having the server rather than client determine which representation and/or segments to select for the media content streaming. The server managed adaptive streaming (SMAS) approach may bring about various benefits such as improving consistency of client experiences.

FIG. 1is a schematic diagram of an embodiment of an SMAS system100, which may comprise one or more media streaming servers and streaming clients. As an example,FIG. 1illustrates one streaming server110and one streaming client device130(more servers and clients may be present but are not shown). The streaming client130may obtain (via downloading or streaming) media contents from the streaming server110. A media content may take any viable form such as video, audio, text, or combinations thereof. The media content may contain any applicable type of information, such as movie, music, and/or electronic publication, etc. The streaming system100may implement any suitable content delivery scheme or method, such as a DASH scheme. The streaming client130may be a program or application implemented in an operating system of a user device, or it may be a web client accessed in a web platform.

The streaming server110may be implemented as any suitable type of network server such as an HTTP server, where media contents may be generated or prepared by a streaming media preparation unit. The media preparation unit may be located in the HTTP server or elsewhere (e.g., in a content provider). The streaming server110may be part of a content provider or may be a node in a content distribution network (CDN). The media content may be generated by the content provider and then transmitted to a CDN node. The media content in the streaming server110may comprise an MPD and a plurality of segments. Note that, if desired, the MPD and the segments may be stored in different servers and sent to the streaming client from different servers. For example, an MPD may be sent to the streaming client130from the streaming server110, while corresponding segments may be sent to the streaming client130from a different streaming server (not shown inFIG. 1).

As shown inFIG. 1, the streaming server110comprises an adaptation logic unit (or module)112, a request parser114, a delivery function116, and a media content120. The media content120may comprise one or more periods, and each period may comprise a plurality of available representations. For example, in a first period, a representation122may comprise multiple segments, and another representation124may also comprise multiple segments. A second period may be similar. On the other end of the streaming system100, the streaming client130comprises an access engine132, a monitoring function unit134, and a media engine136.

In operation of the streaming system100, the streaming server110may use the delivery function116to deliver an MPD to the streaming client130(note that the MPD may also be delivered from another server). The MPD can be delivered using HTTP, email, thumb drive, broadcast, or any other transport. By parsing the MPD, the streaming client130may learn information regarding the media content, such as the timing of the program, the availability of media content, the media types, resolutions, minimum and maximum bandwidths, the existence of various encoded alternatives of multimedia components, the accessibility features and the required digital right management (DRM), the location of each media component on the network, and other characteristic of the media content. The MPD may further comprise a URL template, based on which the streaming client130may contrast URLs for obtaining segments.

In order to access the media content120, the streaming client130may send one or more HTTP requests140to the streaming server110for the media content120. Specifically, the HTTP requests140may comprise a URL that contains information provided by the streaming client130(e.g., bandwidth, device capability such as screen size, memory size, etc.). In an embodiment, the URL comprises parameters inserted in a query string portion of the URL (instead of a path portion of the URL). The query string portion may comprise one or more query parameters, and multiple query parameters may be separated by the symbol “&”.

Any type of relevant parameters may be inserted in the query string, such as adaptation parameters which may be required or optional. In the case of an optional parameter, for example, a server may sometimes be unaware of client capabilities. Suppose the streaming client130cannot indicate to the streaming server110the resolution of a video, the streaming client may still indicate to some information of the client device, such as screen size or screen resolution (include as a query parameter). The streaming server110may then use this information to decide a representation or relevant segments for the client130.

After the streaming server110receives the HTTP requests140, the request parser114may parse the HTTP requests140and then forward relevant information to the adaptation logic unit112. The adaptation logic unit112may enable the streaming server to control or manage the media streaming process (for this reason, the streaming system100is referred to as an SMAS). In an embodiment, the adaptation logic unit112uses information contained in the HTTP requests140to make various decisions, e.g., to determine or select which representation and/or which segment(s) to give to the streaming client130. The adaptation logic unit112may use any suitable decision making logic. Compared to client managed adaptive streaming (CMAS), the SMAS system100may be advantageous in the fact that the streaming server110may not need to inform or reveal its file paths to the streaming client130, as decisions are made by the adaptation logic unit112inside the streaming server110. Further, giving control to the streaming server110instead of the streaming client130may improve consistency of user experience when serving the media content120. For example, the streaming server110may offer the same quality of segments to clients with the same bandwidth (if the client had control of streaming, the client supposedly may still request higher quality segments even though its bandwidth is insufficient, e.g., in an attempt to get more bandwidth from a network provider).

After determining which segment(s) to serve the streaming client130, the streaming server110may use the delivery function116to deliver the segments to the streaming client130by sending HTTP responses142. Note that MPD and segments may also be delivered using different delivery functions, and further note that the streaming client130may obtain segments from a plurality of HTTP servers, e.g., to maximize usage of network bandwidth. The access engine132in the streaming client130may render the segments appropriately so as to provide streaming service to the streaming client130. The access engine132may process the media segments and then forward them to the media engine136for playback of the segments. Further, the monitoring function134may monitor conditions of the streaming client130(e.g., bandwidth, authentication code or token, device parameters, etc.) either continuously or intermittently, and provide the conditions to the access engine132. The conditions may be inserted as query parameters of a URL, so that a next HTTP request may reflect the conditions of the streaming client130.

A network connection between the streaming server110and the streaming client130may be of any suitable type. For example, the streaming server110and the streaming client130may be connected via the Internet, a mobile network, or a private network (e.g., company Intranet). Alternatively, the streaming server110and the streaming client130may belong to the same home network and be connected to the same wireless fidelity (WiFi) router.

In an embodiment, third parties in a network may also provide information regarding the streaming client to help improve the streaming process. In providing server management and network assistance to DASH, various types of parameters such as DASH metrics, QoS parameters, and playback environment description parameters may be inserted as query parameters and sent to the streaming server. For example, AMAZON can provide information indicating that a client is a prime member, and a streaming server (e.g., AT&T) may give the client more bandwidth because of the prime membership.

In order to ensure semantic understanding of parameters communicated among various parties including MPD providers, streaming clients (e.g., the client130) and media segment servers (e.g., the server110), such parameters need to be well-defined, e.g., using parameters in the current URL template construction schemes in DASH. Depending on the nature of use of parameters, they may also come from existing standards, such as security assertion markup language (SAML), e.g., for security related tokens, or MPEG-21 digital item adaptation (DIA), e.g., for user environment definitions.

In an embodiment, there are various attributes that a solution from a core experiment (CE) on DASH may have. Firstly, not only parameters of simple types may be supported, but also ones with structures like XML elements. Secondly, the use of parameters may be signaled for either URL insertion or (additional) URL query string. Thirdly, parameters from non-DASH namespaces may be supported. Fourthly, it may be possible to indicate if parameters may be required (by default) or optional to be used. Fifthly, it may be possible to specify the scope of parameters for media segments they apply to at different structural levels within an MPD. This disclosure teaches a way to specify parameters that can be either inserted into parameterized URLs, or passed with URLs as query string parameters, and embodiments in this disclosure may be designed to meet the requirements above.

This disclosure introduces a new element, which may be denoted as URLParameter, to capture various information related to a streaming client. The element “URLParameter” can be defined in a number of ways in an XML scheme.FIG. 2illustrates an exemplary implementation200of a query parameter as an element “URLParameter”. In the implementation200, the element “URLParameter” comprises multiple attributes including an identification or identifier (id)210, a value220, a namespace230, a query string attribute240, and a usage requirement250. As one of ordinary skill in the art understands, other forms or implementation methods are possible to realize the element “URLParameter” within principles disclosed herein.

The identification210of the parameter may be a required parameter used as a token $id to be replaced when used as part of a parameterized URL, or a “name” (the portion before “=”) when the parameter may be used for a query string. This name may be unique with respect to the namespace230.

The value220may be an optional value to capture any known (static) value of the parameter. It may be the actual value to replace the token $id when used as part of a parameterized URL, or a “value” (the portion after “=”) when used for a query string. If this information is missing, it means that this parameter value is dynamic and may need to be gathered and provided by a streaming client when constructing the URL. Note the actual value of this piece information needs to be encoded in a way that can be used as part of a URL or a URL with query strings.

The query string attribute240may be optional and may indicate if the purpose of this parameter is for insertion or for (additional) query string. When omitted, the default can be set for insertion.

The usage requirement250may be an optional attribute denoted as “required” that indicates whether this parameter is required (i.e., mandatory) or optional. A parameter for insertion should be required, whereas a parameter for query string that may be optional may not have to be added into the URL. This provides flexibility to accommodate clients who may not be able to provide any value for this parameter or servers who may be able to process URLs without this parameter. When omitted, the default may be that the parameter is required.

In the implementation200, the semantics of attributes @id, @value, and @namespace may be straightforward for one of ordinary skill in the art to understand. The attribute @queryString takes a Boolean value, with “false” to indicate the parameter is for URL insertion and “true” for being an additional URL query string. When omitted, the default value of @queryString may be “false”, indicating that the parameter is for URL insertion. The attribute @required also takes a Boolean value, with “false” to indicate the parameter is optional and “true” to indicate the parameter is required.

The element “URLParameter” may be placed optionally on one or more levels including the MPD, period, adaptation set, and representation levels. The element “URLParameter” may be applied to all media segments within its scope. If desired, the element “URLParameter” may be designed to apply to some (but not all) of the media segments within its scope.

In use, a streaming client (e.g., client130) may implement a processing rule for each “URLParameter”. In an embodiment, for each media segment URL or URL template in its scope, the client may first check “required” to see if this parameter is required or optional, and decide if it will process if it is optional. Secondly, if the client decides to process the parameter, the client may gather a parameter value from “value”, according to the namespace provided by “namespace”. This value may already be given by the “value” itself or through some out-of-band mechanism, depending on the parameter semantics from the namespace. Thirdly, the client may check the “queryString” of the parameter, to decide if the parameter is for insertion or query string when placed into the URL or URL template. Fourthly, if the purpose is for URL insertion, the client may find a substitution in the URL matching “id”, and replace the right $id token with the parameter value. Fifthly, if the purpose is for URL query string, the client may construct a string “id” “=” “value”, and place (e.g., append) as a query string into the URL.

Below are some exemplary embodiments to illustrate parameter specification taught herein and its potential use in some use cases.FIG. 3illustrates an exemplary URL template300, which may comprise various parameters including a representation number (RepNumber)310, a segment number (SegNumber)320, and a bandwidth of a streaming client (AvailableBandwidth)330. Using the URL template300, the streaming client may construct a URL and then send the URL to a streaming server for requesting segments of a media content.

Suppose the values of the parameters are: RepNumber=1, SegNumber=2, and AvailableBandwidth=80000. In an embodiment, the streaming client may use the URL template300to construct the following URL:
http://cdn1.example.com/video/1_2.mp4v?bw=80000 (1)

FIG. 4illustrates an exemplary URL template400, which is similar to the URL template300in various aspects. In the interest of conciseness, further descriptions will focus on aspects that are different or yet to be described (same applies to other templates). The URL template400comprises various parameters including a representation number (RepNumber), a segment number (SegNumber), and a bandwidth of a streaming client (AvailableBandwidth). Unlike the URL template300, the URL template400further comprises a parameter410with a static value. The static value may be defined by a streaming server and provided to the client. As an example, the parameter410is denoted as “shorthand” and has a static value of “thisIsAReallyLongPath”.

Suppose the values of the parameters are: RepNumber=1, SegNumber=2, and AvailableBandwidth=80000. In an embodiment, using the URL template400, the streaming client may construct the following URL (2):
http://cdn1.example.com/video/1_2_thisIsAReallyLongPath.mp4v?bw=80000 (2)

Suppose the values of the parameters are still: RepNumber=1, SegNumber=2, and AvailableBandwidth=80000. In an embodiment, using the URL template500, the streaming client may construct the following URL (3):
http://cdn1.example.com/video/1_2.mp4v?AvailableBandwidth=80000 (3)

In URL (3), the bandwidth parameter (bw=80000) may be determined by the streaming client (e.g., using the monitoring function134), and then inserted as a query parameter in the query string portion of the URL.

For the purpose of illustration, user environment description (UED) parameters defined by MPEG-21 DIA may be used an example.FIG. 6Aillustrates an exemplary “AvailableBandwidth” element600in the DIA namespace denoted as “urn:mpeg:mpeg21:2003:01-DIA-NS”.FIG. 6Billustrates an exemplary URL template610that comprises a namespace parameter612with value “urn:mpeg:mpeg21:2003:01-DIA-NS”.

Suppose the values of the parameters are: RepNumber=1, SegNumber=2, and AvailableBandwidth=<AvailableBandwidth maximum=“256000” average=“80000”/>. In an embodiment, using the URL template610, the streaming client may construct the following URL:

In URL (4), the bandwidth parameter is a range instead of a fixed value. Further, special characters in the bandwidth parameter are encoded and then inserted as a query parameter in the query string portion of the URL.

In an embodiment for DASH, substitution parameters listed in Table 1 may be made available to a DASH client at URL construction stage.

TABLE 1$<Identifier>$Substitution parameterFormat$$Is an escape sequence, i.e. “$$” is replacednot applicablewith a single “$”.$RepresentationID$This identifier is substituted with the valueThe format tag shall not beof the attribute Representation@id of thepresent.containing Representation.$Number$This identifier is substituted with the numberThe format tag may beof the corresponding Segment.present.If no format tag is present,a default format tag withwidth = 1 shall be used.$Bandwidth$This identifier is substituted with the valueThe format tag may beof Representation@bandwidth attributepresent.value.If no format tag is present,a default format tag withwidth = 1 shall be used.$Time$This identifier is substituted with the valueThe format tag may beof the SegmentTimeline@t attribute for thepresent.Segment being accessed. Either $Number$If no format tag is present,or $Time$ may be used but not both at thea default format tag withsame time.width = 1 shall be used.$querypart$This identifier is substituted with the queryThe format tag shall not bepart of the computed query stringpresent.(UrlQueryString).$fragmentpart$This identifier is substituted with theThe format tag shall not befragment part of the computed query stringpresent.(UrlQueryString).$query:param$This identifier is substituted with the valueThe format tag shall not beof the param parameter if this parameter ispresent.present in the query part of the computedquery string (UrlQueryString).$fragment:param$This identifier is substituted with the valueThe format tag shall not beof the param parameter if this parameter ispresent.present in the fragment part of the computedquery string (UrlQueryString).

One of ordinary skill in the art will understand the meaning of substitution parameters in Table 1. In particular, the last four substitution parameters listed in Table 1 may be new parameters introduced herein.

In an embodiment for DASH, a URL query string element (UrlQueryString) may be set up as the following Table 2.

One of ordinary skill in the art will understand the meaning of elements or attributes in Table 2. In an embodiment, the UrlQueryString element may appear at most once at the levels of period, adapatation set and presentation.

The UrlQueryString in Table 2 describes how to build a URL query string, which can come from various places including an MPD URL when the @useMPDUrlQuery is set, the @QueryString attribute when present, the @OptionalQueryString attribute when present, or the @xlink resolution when present.

The URL query string may be constructed by concatenating query strings, if present and available (especially for @OptionalQueryString), resulting from @useMPDUrlQuery, @mpdQueryString, @OptionalQueryString and @xlink:href.

When two or more occurrences of UrlQueryString exist within an MPD, the final URL query string used at the inner-most representation level may be a concatenation of the corresponding URL query strings of the occurrences in their orders of appearance in the MPD hierarchy.

Note that “basic” parameter signaling may be used (@queryString=“a=X&b=Y”), as well as uniform resource name (URN)-dependent signaling (@queryString=“a=$urn:XYZ&b=$urn:ABC”). In the latter case, the client may be aware of the provided urns, and have to compute appropriate values for them. Suggested use cases for such parameter include a global positioning system (GPS) location, or measured bandwidth, where the client needs to provide feedback through URL parameters. The “$” sign is added before the URN scheme to notify that a computation is awaited.

Various potential use cases exist in an adaptive streaming system (e.g., the system100), and embodiments disclosed herein may apply to any of the potential use cases. This disclosure describes a number of exemplary use cases, but it should be understood that these examples are non-limiting.

FIG. 7illustrates an exemplary MPD700, which may be used for personalization of media segment URLs based on a MPD URL. With the current DASH specification, personalizing media segments URLs per client may require personalizing MPDs, which mean creation of a specific MPD per client. This use case inFIG. 7discloses personalization of media segment URLs based on the MPD URL, so that a single MPD is sufficient. One intent is to allow transmission of a token from the MPD URL to media segments URLs.

It is assumed that the MPD700is available at URL http://a.com/x.mpd?token=abcdeXYZ. The processing of UrlQueryString leads to a query string, “token=abcdeXYZ”. Then the first media segment URL of the video representation with bandwidth=250 is http://a.com/250000/Seg1.mp4v?token=abcdeXYZ.

During the course of a media content, there may be dynamic events that may be unexpected (e.g., extra time-outs during a basketball game). During these events, advertisement (ad) or other information may be inserted to the media content.FIG. 8illustrates an exemplary MPD800, which may be used for ad insertion and/or live resolution of parameters. In this use case, query parameters may be used to trigger ad insertion. The ad may not be known at the time the MPD is generated. It is thus proposed to allow just-in-time resolution of some parameters. The streaming server may update an original MPD during streaming of the media content to the streaming client, and send the updated MPD to the streaming client. The updated MPD reflects dynamic events that are unexpected at a time of generating the original MPD.

Thus, responses to segment requests sent by the streaming server may include just-in-time MPD updates. This mechanism may sometimes be better than in-band event carriage and scheduled periodic updates. The xlink may be resolved on request, and the resulting query string is “xlinkparam=somevalue”. Then the first media segment URL of the video representation with bandwidth 250 kbps is “http://a.com/250000/Seg1.mp4v?xlinkparam=somevalue”.

Another potential use case is to enable client feedback through parameters. Query parameters may be a way for the DASH client to provide feedback to the server, such as measured bandwidth, GPS location, etc.FIG. 9Aillustrates an exemplary MPD900for enabling client feedback through parameters −1, andFIG. 9Billustrates an exemplary MPD950for enabling client feedback through parameters −2.

The use cases inFIGS. 9A and 9Bassume that “urn:prmDef-1” refers to an exemplary parameter description970shown inFIG. 9C, which is encoded by a Web Application Description Language (WADL). Further, the use case inFIG. 9Aassumes that the MPD900is available at URL “http://a.com/x.mpd?pd=$urn:prmDef-1”.

In the MPD900, the processing of UrlQueryString leads to a query string, “pd=$urn:prmDef-1”. The client may be able to understand the “urn:prmDef-1” scheme and insert the appropriate values (GPS location in this case) in the media segment URL, which would look like http://a.com/250000/Seg1.mp4v?location=areaA.

In the MPD950, the processing of UrlQueryString leads to a query string, “a=$urn:SomeStandardizedBandwidthMeasurement”. The client may be aware of the signalized scheme and may provide the measured bandwidth value accordingly, which leads to http://a.com/Seg1.mp4v?bandwidth=500000.

Another similar use case is illustrated by an MPD970as shown inFIG. 9D. In the MPD970, the processing of UrlQueryString elements at three levels leads to a query string “a=XYZ&b=EFG&c=RST”. Then, a first media segment URL of the video representation with bandwidth 250 kbps is http://a.com/250000/Seg1.mp4v?parameter1=EFG&parameter2=XYZ.

It should be understood that there may exist many other potential use cases, in which embodiments disclosed herein may apply. For example, an authentication code (or security token) may be requested by a streaming server in a URL template. Based on the URL template, the streaming client may need to access the authentication code and verify its own identity with the streaming server before it is allowed to obtain any segment. The authentication code may be generated by the streaming client, the streaming server, or a third party server, and may be stored in any suitable form. The authentication code may be sent to the server as a query parameter inserted in the query string. The code or token passing from the client to the server may enable better session management.

In another exemplary use case, the streaming server may force the play-out of a particular content such as an ad for a certain period of time. In this case, the streaming client may supply a play-out evidence for the server or for a network to verify before fulfilling subsequent segment requests. The evidence may be generated by the streaming client and may be stored in any suitable form. The forced play-out mechanism may sometimes be better than pure CMAS, e.g., when the client is not trustworthy. For example, if client had control of streaming, the client may just request the next period when it detects a segment is an ad period. Using parameter insertion mechanisms disclosed herein, the server may ask for evidence from the client that the ad period has been played out. The evidence is given as a query parameter. The server holds the main content until it receives the evidence.

In another exemplary use case, the streaming server may fulfill spatial adaptation within a full-field view. When streaming a high resolution video, the client can zoom in a certain area/angle (e.g., to focus on a particular player or the basket in a basketball game). In this case, a region of interest (ROI) and/or a viewing angle may be provided by the client as query parameters. Accordingly, the streaming server may provide one or more segments that portrait a video signal specified by at least one of the ROI and the viewing angle. Such capability may enrich user experience.

FIG. 10is a flowchart of an embodiment of a method1000, which may be implemented by a client device (e.g., the streaming client130). The method1000starts from step1010, where the client device may obtain an MPD for a media content. The MPD may comprise a URL template for construction of URLs. In step1020, the client device may insert one or more query parameters in a query string portion of a URL, wherein the query string portion follows a path portion of the URL. In an embodiment, the one or more parameters are inserted in the query string portion of the URL based on the URL template. The one or more query parameters may be any type of relevant parameters such as a client authentication code, an authorization token (such as those from OAuth (Open Standard for Authorization), SAML (OASIS Security Assertion Markup Language SAML), and GAA (3GPP Generic Authentication Architecture)), evidence showing that the client device has finished playing a length of a forced play-out content, a ROI, client power consumption, or a viewing angle, or a URL to acquire, obtain or retrieve one or more of these parameters, or combinations thereof.

In step1030, the client device may send a media request comprising the URL to a streaming server (e.g., the streaming server110). In step1040, the client device may receive one or more segments of the media content from the streaming server in response to the media request. Specifically, the segments may be determined by the streaming server in response to the media request and based at least in part on the query parameters.

It should be understood that the method1000serves as an exemplary embodiment, thus alternatives may be used to modify the method1000and additional steps may be incorporated as necessary. For example, the client device may monitor network conditions and/or device operation conditions during playback of the media content, and one of the network conditions may be a bandwidth available to the client device during the playback of the media content. Further, the bandwidth may be specified as one of the query parameters inserted in step1020.

FIG. 11is a flowchart of an embodiment of a method1100, which may be implemented by a network server (e.g., the streaming server110) acting as a server for media content streaming. The method1100starts in step1110, where the network server may generate an MPD for a media content, wherein the MPD comprises a URL template that specifies one or more query parameters to be included in the query string portion of the URL. In step1120, the network server may send the MPD to a streaming client coupled to the network server via a network connection.

In step1130, the network server may receive a URL from the streaming client, wherein the URL comprises a path and a query string following the path, wherein the query string comprises one or more query parameters. In step1140, the network server may determine one or more segments of a media content to use for the streaming client based on at least one of the received query parameters. In step1150, the network server may send the one or more segments to the streaming client.

It should be understood that the method1100serves as an exemplary embodiment, thus it may be modified as necessary. For example, as the MPD and corresponding segments may be generated and/or stored by different network servers, some steps such as steps1110and1120may be skipped whenever appropriate.

FIG. 12is a schematic diagram of an embodiment of a computer system or network device1200. The network device1200may be implemented as any suitable device, such as a network server, a streaming server (e.g., the streaming server110), or a client device (e.g., the streaming client device130) disclosed herein. The network device1200may be capable of receiving, processing, and transmitting messages such as media requests and segments to and from a network. The network device1200may comprise one or more ingress ports1210coupled to a receiver1212(Rx), which may be configured for receiving MPD and/or segments from other network components. The network device1200may further comprise one or more egress ports1230coupled to a transmitter (Tx)1232, which may be configured for transmitting MPD and/or segments to other network components. The network device1200may further comprise a logic unit or processor1220coupled to the receiver1212and configured to process the segments or otherwise determine to which network components to send the segments.

The processor1220may be implemented using hardware or a combination of hardware and software. The processor1220may be implemented as one or more central processor unit (CPU) chips, cores (e.g., a multi-core processor), field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), and/or digital signal processors (DSPs). The processor1220may be configured to implement any of the functional modules or units described herein, such as the adaptation logic unit112, the request parser114, the delivery function116, the access engine132, the media engine136, the monitoring function134, a media player1221, or any other functional component known by one of ordinary skill in the art, or any combinations thereof. The media player1221may be an application running on the processor1220and configured to play decoded media segments.

The network device1200may further comprise at least one memory1222. The memory1222may be configured to store an MPD1223and segments1224. The MPD1223and the segments1224may be stored or packed in various forms as described above. For example, the MPD1223may be any of the MPDs700,800,900,950, and970. As shown inFIG. 12the segments1224and the MPD file1223are stored as separate files, but they may also be stored in a single file.

In practice, there may be bidirectional traffic processed by the network device1200, thus some ports may both receive and transmit packets (e.g., segments). In this sense, the ingress ports1210and egress ports1230may be co-located or may be considered different functionalities of the same ports that are coupled to transceivers (Rx/Tx). One of more of the processor1220, the memory1222, the receiver1212, and the transmitter1232may also be configured to at least partially implement or support any of the methods and implementations described above, such as the implementation200, the method1000, and the method1100.

It is understood that, by programming and/or loading executable instructions onto the network device1200, at least one of the processor1220and the memory1222can be changed. As a result, the network device1200may be transformed in part into a particular machine or apparatus (e.g. a network router having the functionality taught by the present disclosure). The executable instructions may be stored on the memory1222and loaded into the processor1220for execution.

Any processing of the present disclosure may be implemented by causing a processor (e.g., a general purpose multi-core processor) to execute a computer program. In this case, a computer program product can be provided to a computer or a network device using any type of non-transitory computer readable media. The computer program product may be stored in a non-transitory computer readable medium in the computer or the network device. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), compact disc read only memory (CD-ROM), compact disc recordable (CD-R), compact disc rewritable (CD-R/W), digital versatile disc (DVD), Blu-ray (registered trademark) disc (BD), and semiconductor memories (such as mask ROM, programmable ROM (PROM), erasable PROM), flash ROM, and random access memory (RAM)). The computer program product may also be provided to a computer or a network device using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g. electric wires, and optical fibers) or a wireless communication line.