Content Steering

[technogeek00]

Use Case Description

Content may be made equally available across multiple delivery networks that players can use interchangeably. These paths need to be signaled to players with potential priority ordering.

Working Notes

• Potential mechanisms are DASH Multiple Base Urls and HLS Content Steering

Open Questions

• Is there a priority signaling mechanism in DASH?
• Alternatively is there a more aligned secondary document reference mechanism for DASH?

[technogeek00]

Discussion Notes:

• DASH Multiple Base URLs is not a great equivalency since its combining responsibilities of manifest and steering, where the HLS solution is explicitly separating the concerns
• Desire to approach with alternative solution for DASH, table below filled on this assumption

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

[technogeek00]

Assigning to @wilaw for proposal on using HLS content steering response in DASH

[technogeek00]

@wilaw proposal captured: Dash-Industry-Forum/DASH-IF-IOP#406

[technogeek00]

2022/03/22 Working Notes

HLS Notes

• Originating source of the format, now formally in RFC-8216bis as Section 7
• #EXT-X-CONTENT-STEERING tag within the multivariant playlist defines the SERVER-URI to the steering manifest and default PATHWAY-ID
• All possible pathways are required to exist as optional fallback pathways in the original multivariant.
  • Pathway identifiers are signaled via the PATHWAY-ID attribute on the EXT-X-STREAM-INF tag
  • Note that PATHWAY-ID is not present on EXT-X-MEDIA tags as they will have to explicitly duplicated for the duplicated optional pathway definitions. Note this may be a non-obvious implication to developers, you cannot just blindly duplicate media-group references, you must explicitly duplicate the full media groups with the appropriate uri references updated
• The steering manifest is a JSON object that describes:
  • a VERSION, clients must refuse versions they do not understand
  • a TTL describing the lifespan of the supplied steering manifest
  • a RELOAD-URI describing an optional alternate uri to load the next steering manifest update from
  • an array of PATHWAY-PRIORITY descriptions, which describe the preference order for Pathway Ids present in the multi-variant
• Implementations are discouraged from having the multivariant and initial content steering manifest differ as clients are expected to immediately abandon the active pathway if there is a different priority in the list
• Calls to the steering server define query semantics with attributes the client must compute and include on the request:
  • _HLS_pathway the PATHWAY-ID the client is actively playing from
  • _HLS_throughput the client measured throughput to the active pathway if known

DASH Notes

• The HLS proposal has been mapped to the DASH proposal and is under discussion in the DASH-IF: Content steering mechanism for DASH compatible with HLS RSS Dash-Industry-Forum/DASH-IF-IOP#406
• Latest proposal creates a new node ContentSteering with:
  • defaultServiceLocation equivalent to the default PATHWAY-ID semantics
  • queryBeforeStart as a boolean defining if the player should respect manifest ordering or is required to get an update before playback
  • the value of the node represents the SERVER-URI
• The DASH BaseURL@serviceLocation attribute is reused as the PATHWAY-ID holder
• The Steering manifest payload is equivalent to the HLS payload
  • The defined steering behavior duplicates the query parameter usage to allow for consistent server implementation
• On-going discussions around different implications this inclusion has to other DASH mechanics as well as IP concerns.

Open Questions

• Do we proceed with interoperability definitions now or hold until DASH proposal is finalized and accepted?
  • Additional potential is that we include all the information we has as informational and switch to normative after finalization.

[technogeek00]

Waiting for DASH-IF progress on Multi-CDN proposal

[technogeek00]

DASH-IF signaling proposal published: Content Steering for DASH

[technogeek00]

As part of implementation for this within the third edition of the DASH-HLS interop specification I'm bringing back a summary of differences and dispositions that were aligned in the group meetings for tracking here. Note that the latest DASH steering spec is available: https://www.etsi.org/deliver/etsi_ts/103900_103999/103998/01.01.01_60/ts_103998v010101p.pdf As the dispositions here capture the original deltas they may no longer be defined as such in the spec causing a disposition of no interop needed.

Functionality	HLS Specification	Original DASH Specification	Interop Capture
Server Query Requirements	After start	After Start, Optional Force before start with ContentSteering@queryBeforeStart	Note that there is no translation capability for before start to HLS
Local Server Proxying	Not Supported	ContentSterring@proxyServer	Remove from DASH version, no longer interop point
Feature Effect Radius	All variants / renditions pointed at by multivariant	All Periods with at least one BaseURL where the @serviceLocation matches location in steering manifest	DASH spec covers fallback logic for mismatches, but highlight in note that DASH can semantically apply to media differently than HLS and this aspect cannot be translated
Unrecognized Key Handling	Not Specified	Client should ignore	Reinforce unknown as ignore
Unrecognized Version Handling	Client should refuse	Client should refuse after consuming TTL and RELOAD-URI	DASH now aligned to always refuse unknown version
HTTP 410 Response	Never request again, may use existing known responses	Not Specified	DASH now matches HLS behavior, no interop point
HTTP 429 Response	Respect Retry-After if present	Not specified	DASH now matches HLS behavior, no interop point
Reload TTL Signal	TTL key (required)	TTL key (optional)	Both now are required, no interop point
Default TTL	300 seconds (only in case of no previous response)	300 seconds	Both now aligned with 300 when no previous response, no interop point
Location Priorities	PATHWAY-PRIORITY key (required, array)	SERVICE-LOCATION-PRIORITY key (optional, array, default false)	DASH aligned to HLS, but highlight client ability to choose
Location Cloning	PATHWAY-CLONES key (optional, array)	Not Supported	DASH added support for cloning to match HLS
General Behavior	Switch to highest location in list that has not been penalized by client	Switch to highest location in list and within active playout area that has not been penalized by client	Specs are aligned, no interop point
Location removed	Switch to next available location if one exists	Switch to next available location if one exists, otherwise fail playback	Interop to highlight behavior difference
Location penalty duration	client determined time	time equal to last steering manifest ttl	Specs now aligned, no interop needed

[technogeek00]

Renamed to align with industry terminology and spec term alignment