Externalized Personalization Parameters

[technogeek00]

Use Case Description

Content providers desire for players to make personalized / individualized requests while providing cacheable manifest responses.

Working Notes

• The main goal is for the primary content MPD and M3U8 objects to be shared across consumers
• HLS the mechanism is EXT-X-DEFINE with the QUERYPARAM / IMPORT parameters
• DASH the mechanism is ExtUrlQueryInfo from the Annex I definition
• HLS is more literal on inclusion with the M3U8 explicitly placing templated variables while DASH is more systematic with rules defining inclusion on requests

Open Questions

• Specification provided mechanisms provide path for aligning on query parameters, is this enough or are headers required?

[technogeek00]

Overall questionaire score: 8

Question	Answer
Does the feature relate to an industry streaming use-case?	Yes, Stream Personalization / Tokenization
- What is the commonality of this case?	Very Common
- Is this an established or emerging practice?	Emerging
Does this feature have related mechanisms in both DASH and HLS?	Yes
- What is the maturity of support in both specifications?	HLS - Mature , DASH - Mature
- What is the maturity of implementation support for both specifications?	HLS - Immature, DASH - Immature
- Are there known interoperability issues between specs?	Yes, HLS only provides query arg alignment
- Has anyone implemented this interoperably?	Yes
- Are there features missing in a specification with open proposals for it?	No
Has the industry defined defacto mechanisms not present in both DASH and/or HLS?	No
- Why was functionality defined outside of the main specifications?	N/A
- Has the functionality been standardized elsewhere (DASH-IF, CTA, SVA)?	N/A
- Is the functionality proprietary or openly developed?	N/A
- Could the functionality be incorporated into specifications with evangelism?	N/A

[technogeek00]

Research Note Summary 2024/08/14

This comment summarizes information for this work prior to formal specification drafting

HLS

• Enabled by the Variable Substitution functionality within the Playlist
  • This functionality is limited to URI lines, quoted-string AttributeValues and hexadecimal-sequence AttributeValues
  • Variable reference looks like {$VARNAME} where VARNAME follows the semantics outlined by EXT-X-DEFINE
  • Variables must be declared prior to use when scanning top to bottom of the M3U8 document
• Variable values are defined by EXT-X-DEFINE lines (HLS spec 4.4.2.3), attributes:

Attribute	Required	Description
NAME	No	The name of the variable being defined by the tag.
VALUE	When NAME exists	The explicit value to set the variable to.
IMPORT	No	The name of the variable definition in the parent Multivariant to import. Not allowed in multivariants, variable name is inherited to this variant.
QUERYPARAM	No	The name of the query parameter the variable value is sourced from. Variable name is equal to query parameter name.

• Other significant notes
  • Variable names are case sensitive
  • EXT-X-DEFINE are not implicitly carried across reloads, aka always put it in
  • When pulling from query parameters, the query parameters should be pulled from the redirected URI in the case of a 30x
  • Repeated query parameters can use any of the sourced parameters
  • Query Parameter support was added in a later version, requires EXT-X-VERSION of 11

DASH

• Enabled by the Annex I Flexible Insertion of URL Parameters
  • This annex introduces multiple elements up:URLQueryInfo and up:ExtUrlQueryInfo, and up:ExtHttpHeaderInfo
  • Both Ext* types were introduced in later versions and succeed the base up:URLQueryInfo functionality
  • Generally support is targeted around up:ExtUrlQueryInfo only
  • Operates on a class of requests rather than on specific string variable replacements
• Details on up:ExtUrlQueryInfo in I.3
  • Must be specified within an EssentialProperty or SupplementalProperty Descriptor with URN urn:mpeg:dash:urlparam:2016
  • Is itself xlinkable but that xlink will execute without replacement
  • Attributes:

Attribute	Required / Default	Description
@queryTemplate	No	Defines a query template containing one or more template identifiers
@useMPDUrlQuery	No, default false	Whether or not the query string of the MPD URL should be used for query reference. When ture and @queryString are present, they are concatenated together
@queryString	No	A base query string to use for query reference
@includeInRequests	No, default segment	The requests to include parameters on. White space separated list of potential values: segment, xlink, mpd, callback, chaining, fallback
@headerParamSource	No, default segment	HTTP responses where header templates should source values from. White space separated list of potential values: segment, xlink, mpd, callback
@sameOriginOnly	No, default false	Restricts parameters to only the origins they were received from.

• Template Identifiers

Identifier	Meaning
$$	Escape sequence for utilizing the value $ in a query template
$querypart$	Identifier replaced by the full query part of the initialQueryString, cannot be used with other identifiers
$query:<param>$	Identifier replaced by the value of the <param> parameter in the initialQueryString. Empty string if that parameter does not exist.
$header:<header-name>$	Identifier replaced by the latest received value of the <header-name> HTTP header in the indicated @headerParamSources

• General operation method
  • An initialQueryString is derived based on element parameter values
  • A finalQueryString is computed based on the @queryTemplate and initialQueryString
  • The computed finalQueryString is attached to identified requests as they are made
• Other significant notes
  • The up:ExtUrlQueryInfo elements may exist at multiple hierarchies in the DASH manifest and in this case they are a concatenation of the computed finalQueryString at each level of the hierarchy declared
  • Repeated query parameters in the initialQueryString utilize the last declared value
  • Query strings are explicitly computed at request execution time meaning values from reloads or other requests can cause further changes

Open Questions

• DASH is silent on the utilization of the URI resulting from the 30x, can this be clarified?
• HLS utilizing any value and DASH utilizing last value in the case of duplicate parameters is in conflict. Can we normalize HLS to last? Or do we restrict to non-repetition?
• With HLS substitution evaluated on each variant reload and DASH query computation on each request execution, is there effective parity in variable freshness?