Subject: [Hls-interest] Streaming Video Alliance Comments on HLS Content Steering Proposals

From: Jason Thibeault <[email-masked]>
Date: Wed, 7 Apr 2021 23:21:47 -0500

Streaming Video Alliance (SVA) Comments on HLS Steering Proposal

The Streaming Video Alliance is a group of companies spanning the streaming
video value chain. These companies are dedicated to solving the critical
challenges facing online video to improve consumer adoption. Alliance
members have reviewed the HLS Content Steering Proposal 1.1b1 and the
subsequent Redundant Stream Steering Proposal (RSS) and provided comments
on both from the perspectives of our diverse membership (content providers,
CDNs, ISPs, open caching networks, multi-CDN management systems, encoding
systems, advertising insertion systems, video analytics systems, and video
player developers).

---- SEPARATION OF CONCERNS ----
* It is typical in multi-CDN deployments for different entities to provide
distinct parts of the solution. Manifests may be generated and manipulated
by multiple provider’s services, media segments may come from other
provider’s service, and CDN recommendation intelligence may come from yet
another service.

* The HLS Content Steering Proposal blurs the clean delineation of
responsibilities across these services, putting responsibility on the
Steering Service to generate CDN-specific path prefixes (and possibly
tokens).  A cleaner separation of concerns could be achieved by limiting
the steering service’s scope of responsibility strictly to recommending
pathways in a preferred order (as described in the Redundant Stream
Steering Proposal).
CDN-Specific Tokens

* Our most significant concern was initially about the inability to have
CDN-specific suffixes on the steering templates, precluding the real-world
situations where different tokenization schemes are used by different CDNs.

* While the addition of QUERY-PARAMS appears to address this problem when
tokens are expressed as query parameters, it still requires that the
steering server generates CDN tokens (see above: Separation of Concerns)
and it doesn’t address tokens that may be inserted anywhere in the path as
path parameters or segments.

---- IMPACT ON OPEN CACHING REQUEST ROUTING & EXISTING MULTI_CDN SOLUTIONS
----

* Open Caching Request Routing schemes (relying on several IETF’s CDNI
RFCs) can be configured to inspect and rewrite either main or media
manifests to direct traffic to downstream CDNs.

   - The HLS Content Steering Proposal may preclude the rewriting of media
manifest URLs in the main manifest, as the steering server also has
responsibility for generating media manifest URLs.
   - The HLS Content Steering Proposal adds complexity to request routing
based on HTTP redirect, as envisaged in IETF CDNI and SVA. It may, for
example, require steering server requests to be redirected to an open
caching controller for rewriting of URL prefixes.
   - To better support Open Caching redirect routing, the PREFIX attribute
in the steering manifest should be optional. For example, If the current
non-penalized pathway is the first in the list for which there is no PREFIX
attribute, the client would form the URL of variant streams attached to the
corresponding template in the conventional manner  (e.g. using the relative
URI).

* It should be noted that some multi-CDN solutions use DNS on media segment
hostnames to implement mid-stream CDN switching that is transparent to the
player. The HLS Content Steering Proposal’s focus on alternate manifests
will not break these types of solutions, but integration with such
solutions could be challenging.

* Compatibility can be maintained with client-side multi-CDN management
systems if HLS Video players allow client application override of the
steering server pathway recommendation (see Player Behavior section below).

---- SERVER-SIDE AD INSERTIONS ----

* SSAI systems typically generate ad loads at the time of the main manifest
request and persist session identifiers that need to be passed to media
manifests so that identical ad loads can be stitched into each rendition.
The addition of QUERY-PARAMS should be sufficient for allowing session IDs
to be passed on media manifest URLs.

---- PLAYER BEHAVIOR ----

In reviewing the HLS Content Steering Proposal, the SVA suggests the
following additions to the Player Behavior section:

* HLS Video Players should generate events whenever a pathway is selected,
exposing the PATHWAY-ID so that Video QoS systems can log CDN changes.

* HLS Video Players should generate events whenever requests are made to
the steering server, enabling Video QoS systems to log details from the
steering manifest such as TTL and Pathways on successful requests, and
error information on failed requests.

* For compatibility with existing client-side multi-CDN management systems,
HLS Video Players should expose an API that allows access to the existing
Pathway list and to force a pathway change (overriding the server-directed
steering).

--------------------------------------------------------------------

SVA SUPPORT FOR THE HLS REDUNDANT STREAM STEERING PROPOSAL (RSS)

The SVA supports the Redundant Stream Steering Proposal for the following
reasons:

* RSS embraces and extends redundant playlists (the existing HLS approach
for supporting multiple CDNs), and is backward compatible with any player
that supports redundant playlists.

* RSS provides a cleaner separation of concerns and simplifies the
responsibilities of the Steering Service, as it no longer participates in
generation of manifest URLs or tokens.

* RSS simplifies the HLS Stream Steering scheme by eliminating the steering
templates, prefixes, query parameters, and any code complexity associated
with supporting the template substitution.

* RSS avoids the token-generation challenges that have been identified, as
token generation for media manifest URLs remains in the main manifest.

-------------------------------------------------------------------

This document can also be found on the Streaming Video Alliance website at
https://www.streamingvideoalliance.org/document/comments-on-hls-steering-proposal/

----------

Jason Thibeault
Executive Director
Streaming Video Alliance
+1 480-399-2037
https://www.streamingvideoalliance.org
Contributing Editor, Streaming Media Magazine
<https://www.streamingmedia.com/Search/?Query=jason%20thibeault>
https://www.linkedin.com/in/thejasonthibeault

---

From: Roger Pantos <[email-masked]>
Date: Mon, 12 Apr 2021 11:43:37 -0700

> On Apr 7, 2021, at 9:21 PM, Jason Thibeault <[email-masked]> wrote:
> 
> The Streaming Video Alliance is a group of companies spanning the streaming video value chain. These companies are dedicated to solving the critical challenges facing online video to improve consumer adoption. Alliance members have reviewed the HLS Content Steering Proposal 1.1b1 and the subsequent Redundant Stream Steering Proposal (RSS) and provided comments on both from the perspectives of our diverse membership (content providers, CDNs, ISPs, open caching networks, multi-CDN management systems, encoding systems, advertising insertion systems, video analytics systems, and video player developers).

Hello Jason (and everyone else in SVA), glad to have you in the discussion.

You’ve raised some interesting issues. On the one hand, I think that most could be addressed by the current scheme — per-CDN query parameters could be communicated from the master playlist to the steering server via the content-steering URI, new URI replacement rules could be introduced to allow sub-path customization, etc.

On the other hand, there is simplicity to simply tagging redundant variants with a pathway ID that is appealing. The biggest casualty of that approach is the ability to add new pathways during playback.

We’ve got some discussions going on internally. I expect to come back with a more concrete response shortly.

Roger.

> * It is typical in multi-CDN deployments for different entities to provide distinct parts of the solution. Manifests may be generated and manipulated by multiple provider’s services, media segments may come from other provider’s service, and CDN recommendation intelligence may come from yet another service.
> 
> * The HLS Content Steering Proposal blurs the clean delineation of responsibilities across these services, putting responsibility on the Steering Service to generate CDN-specific path prefixes (and possibly tokens).  A cleaner separation of concerns could be achieved by limiting the steering service’s scope of responsibility strictly to recommending pathways in a preferred order (as described in the Redundant Stream Steering Proposal).
> CDN-Specific Tokens
> 
> * Our most significant concern was initially about the inability to have CDN-specific suffixes on the steering templates, precluding the real-world situations where different tokenization schemes are used by different CDNs.
> 
> * While the addition of QUERY-PARAMS appears to address this problem when tokens are expressed as query parameters, it still requires that the steering server generates CDN tokens (see above: Separation of Concerns) and it doesn’t address tokens that may be inserted anywhere in the path as path parameters or segments.
> 
> ---- IMPACT ON OPEN CACHING REQUEST ROUTING & EXISTING MULTI_CDN SOLUTIONS ----
> 
> * Open Caching Request Routing schemes (relying on several IETF’s CDNI RFCs) can be configured to inspect and rewrite either main or media manifests to direct traffic to downstream CDNs.
> 
>    - The HLS Content Steering Proposal may preclude the rewriting of media manifest URLs in the main manifest, as the steering server also has responsibility for generating media manifest URLs.
>    - The HLS Content Steering Proposal adds complexity to request routing based on HTTP redirect, as envisaged in IETF CDNI and SVA. It may, for example, require steering server requests to be redirected to an open caching controller for rewriting of URL prefixes.
>    - To better support Open Caching redirect routing, the PREFIX attribute in the steering manifest should be optional. For example, If the current non-penalized pathway is the first in the list for which there is no PREFIX attribute, the client would form the URL of variant streams attached to the corresponding template in the conventional manner  (e.g. using the relative URI).
> 
> * It should be noted that some multi-CDN solutions use DNS on media segment hostnames to implement mid-stream CDN switching that is transparent to the player. The HLS Content Steering Proposal’s focus on alternate manifests will not break these types of solutions, but integration with such solutions could be challenging.
> 
> * Compatibility can be maintained with client-side multi-CDN management systems if HLS Video players allow client application override of the steering server pathway recommendation (see Player Behavior section below).
>  
> * SSAI systems typically generate ad loads at the time of the main manifest request and persist session identifiers that need to be passed to media manifests so that identical ad loads can be stitched into each rendition. The addition of QUERY-PARAMS should be sufficient for allowing session IDs to be passed on media manifest URLs.
> 
> In reviewing the HLS Content Steering Proposal, the SVA suggests the following additions to the Player Behavior section:
> 
> * HLS Video Players should generate events whenever a pathway is selected, exposing the PATHWAY-ID so that Video QoS systems can log CDN changes.
> 
> * HLS Video Players should generate events whenever requests are made to the steering server, enabling Video QoS systems to log details from the steering manifest such as TTL and Pathways on successful requests, and error information on failed requests.
> 
> * For compatibility with existing client-side multi-CDN management systems, HLS Video Players should expose an API that allows access to the existing Pathway list and to force a pathway change (overriding the server-directed steering).
> 
> The SVA supports the Redundant Stream Steering Proposal for the following reasons:
> 
> * RSS embraces and extends redundant playlists (the existing HLS approach for supporting multiple CDNs), and is backward compatible with any player that supports redundant playlists.
> 
> * RSS provides a cleaner separation of concerns and simplifies the responsibilities of the Steering Service, as it no longer participates in generation of manifest URLs or tokens.
>  
> * RSS simplifies the HLS Stream Steering scheme by eliminating the steering templates, prefixes, query parameters, and any code complexity associated with supporting the template substitution.
> 
> * RSS avoids the token-generation challenges that have been identified, as token generation for media manifest URLs remains in the main manifest.
> 
> This document can also be found on the Streaming Video Alliance website at https://www.streamingvideoalliance.org/document/comments-on-hls-steering-proposal/ <https://www.streamingvideoalliance.org/document/comments-on-hls-steering-proposal/>
> 
> ----------
> 
> Jason Thibeault
> Executive Director
> Streaming Video Alliance
> +1 480-399-2037
> https://www.streamingvideoalliance.org <https://www.streamingvideoalliance.org/>
> Contributing Editor, Streaming Media Magazine <https://www.streamingmedia.com/Search/?Query=jason%20thibeault>
> https://www.linkedin.com/in/thejasonthibeault <https://www.linkedin.com/in/thejasonthibeault>-- 
> Hls-interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hls-interest

---

From: "Law, Will" <[email-masked]>
Date: Mon, 12 Apr 2021 20:44:32 +0000

Hi Roger

Re “. The biggest casualty of that approach is the ability to add new pathways during playback.”

Content distributors cannot add new CDNs on a whim. At a minimum there are contracts to be signed, keys and signing-secrets to be shared and QA tests to be performed. This implies that the universe of possible CDNs is known before an event and before the main playlist is generated. What is a practical requirement however is that a distributor may not want to use all their available CDNs all the time and may want the flexibility to change the mixture and prioritization midway through an event. This I believe can be accommodated with RSS.

Imagine a distributor has 4 pathways they can use, A,B, C and D. D is very expensive and they prefer not to use them at all, unless they absolutely have to when the other 3 pathways are all failing to perform. The main playlist could be generated with the redundant variants (A ..D) listed in order. The steering manifest would only return A,B,C at the start of the event. There would be no traffic on D since that pathway is not advertised by the steering server. If at some midpoint due to performance or economic reasons they wished to shift all the traffic to D, they could so by instructing the steering response to now only return an option for D. All steering-aware clients would shift to D. This is the same effect as adding a new pathway, the only nuance being that the pathway had to be described in the main playlist even if it is never used.

The above behavior assumes steering-aware clients. Legacy clients (steering un-aware) would see the redundant offerings and would select the first available. By listing D last, the distributor would ensure that legacy traffic only reached D if A,B,C had all failed and that is probably the desirable outcome under those conditions.

Cheers
Will

From: Roger Pantos <rpantos=[email-masked]>
Date: Monday, April 12, 2021 at 11:43 AM
To: Jason Thibeault <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Hls-interest] Streaming Video Alliance Comments on HLS Content Steering Proposals

On Apr 7, 2021, at 9:21 PM, Jason Thibeault <[email-masked]<mailto:[email-masked]>> wrote:

Roger.

---- PLAYER BEHAVIOR ----

This document can also be found on the Streaming Video Alliance website at https://www.streamingvideoalliance.org/document/comments-on-hls-steering-proposal/<https://urldefense.com/v3/__https:/www.streamingvideoalliance.org/document/comments-on-hls-steering-proposal/__;!!GjvTz_vk!D0iuZIYq23Zuq29cTqeTLY6eqQT8Q_pCUYP95dpjE5yM-Yrnz7k0O7G1uoMU$>

----------
[Image removed by sender.]
Jason Thibeault
Executive Director
Streaming Video Alliance
+1 480-399-2037
https://www.streamingvideoalliance.org<https://urldefense.com/v3/__https:/www.streamingvideoalliance.org/__;!!GjvTz_vk!D0iuZIYq23Zuq29cTqeTLY6eqQT8Q_pCUYP95dpjE5yM-Yrnz7k0OzRDKJof$>
Contributing Editor, Streaming Media Magazine<https://urldefense.com/v3/__https:/www.streamingmedia.com/Search/?Query=jason*20thibeault__;JQ!!GjvTz_vk!D0iuZIYq23Zuq29cTqeTLY6eqQT8Q_pCUYP95dpjE5yM-Yrnz7k0O_5YJ5dh$>
https://www.linkedin.com/in/thejasonthibeault<https://urldefense.com/v3/__https:/www.linkedin.com/in/thejasonthibeault__;!!GjvTz_vk!D0iuZIYq23Zuq29cTqeTLY6eqQT8Q_pCUYP95dpjE5yM-Yrnz7k0OwW_9oGD$>
--
Hls-interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/hls-interest

---

From: Roger Pantos <[email-masked]>
Date: Thu, 15 Apr 2021 15:28:13 -0700

Okay folks, we’ve done a number of audits and we think that simple annotation of redundant streams will work well enough for content steering. I’ve updated the spec to reflect that, and bumped the spec version to 1.2b1. 

We left an opening in 1.2 that will allow us to introduce new Pathways through the steering manifest if there’s a demand for that in the future.

As always, thanks to everyone for their thoughtful contributions!

Roger.

> On Apr 12, 2021, at 1:44 PM, Law, Will <wilaw=[email-masked]> wrote:
> 
> Hi Roger
>  
>> On Apr 7, 2021, at 9:21 PM, Jason Thibeault <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> This document can also be found on the Streaming Video Alliance website at https://www.streamingvideoalliance.org/document/comments-on-hls-steering-proposal/ <https://urldefense.com/v3/__https:/www.streamingvideoalliance.org/document/comments-on-hls-steering-proposal/__;!!GjvTz_vk!D0iuZIYq23Zuq29cTqeTLY6eqQT8Q_pCUYP95dpjE5yM-Yrnz7k0O7G1uoMU$>
>>  
>> ---------- 
>> 
>> Jason Thibeault
>> Executive Director
>> Streaming Video Alliance
>> +1 480-399-2037
>> https://www.streamingvideoalliance.org <https://urldefense.com/v3/__https:/www.streamingvideoalliance.org/__;!!GjvTz_vk!D0iuZIYq23Zuq29cTqeTLY6eqQT8Q_pCUYP95dpjE5yM-Yrnz7k0OzRDKJof$>
>> Contributing Editor, Streaming Media Magazine <https://urldefense.com/v3/__https:/www.streamingmedia.com/Search/?Query=jason*20thibeault__;JQ!!GjvTz_vk!D0iuZIYq23Zuq29cTqeTLY6eqQT8Q_pCUYP95dpjE5yM-Yrnz7k0O_5YJ5dh$>
>> https://www.linkedin.com/in/thejasonthibeault <https://urldefense.com/v3/__https:/www.linkedin.com/in/thejasonthibeault__;!!GjvTz_vk!D0iuZIYq23Zuq29cTqeTLY6eqQT8Q_pCUYP95dpjE5yM-Yrnz7k0OwW_9oGD$>
>> -- 
>> [email-masked] <mailto:[email-masked]>

---

From: "Law, Will" <[email-masked]>
Date: Thu, 15 Apr 2021 23:23:10 +0000

Well a big public thank you to Roger and the team at Apple for their open mindedness and willingness to take feedback around this, even to the degree that it represented a large rewrite of the feature. I think you have a genuinely simpler and thus more robust product as a result. We look forward to supporting you in taking it to production. It’s also encouraging for list members who put time & effort in to preparing feedback, to know that it is given due consideration. So thanks all around.

In speaking with Kirk this afternoon, it would be really useful to have an additional optional reserved parameter of

_HLS_lastSteerTime=<timestamp>

in which the player passes to the steering server the last wall-clock time at which it executed a steering action.

Why would this be useful? Primarily, it allows the decoupling of the check frequency from the steering execution frequency. Delivery problems can happen quickly  - within 30s in some cases. Having a 5 minute check-in interval means that a player can be banging its head against a poorly performing server for many minutes before it moves away. Users have proven inability to absorb such failures for more than 20s or so. We could address this problem by having the player call the steering server every 20s. However we don’t want the QoE churn that might come if the player switches at 20s intervals. It would be nice solution then if the player has the option of checking in frequently but the steering server could then intelligently steer some players who had been stable for a while, immediately, while for others it could wait for some churn-avoiding threshold before steering them. This new timestamp query arg would enable this optimized behavior and it would allow the steering server to remain stateless in its operation.

Cheers
Will

From: Roger Pantos <rpantos=[email-masked]>
Date: Thursday, April 15, 2021 at 3:29 PM
To: "[email-masked]" <[email-masked]>
Subject: Re: [Hls-interest] Streaming Video Alliance Comments on HLS Content Steering Proposals

---

From: Phil Cluff <[email-masked]>
Date: Fri, 16 Apr 2021 10:14:57 +0100

Thanks Roger and the Apple team for looking at this approach, it's really
appreciated! I also really appreciate that this finally formalises the
expected player behaviour for redundant streams.

I think there is something missing though, specifically, in the current
implementation I don't think it works for un-muxed audio and video, and
text tracks, since PATHWAY-ID can only be defined on #EXT-X-STREAM-INF,
#EXT-X-I-FRAME-STREAM-INF.

I think we also need to be able to define PATHWAY-ID on #EXT-X-MEDIA so
that we do things like this for redundant alternate audio or text tracks:

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-0",NAME="en
(Main)",DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en",URI="
https://primary-cdn.com/audio-0.m3u8",PATHWAY-ID="1"
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-0",NAME="en
(Main)",DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en",URI="
https://backup-cdn.com/audio-0.m3u8",PATHWAY-ID="2"

And the same for text tracks:

#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs-1",CHARACTERISTICS="public.accessibility.transcribes-spoken-dialog",NAME="English",AUTOSELECT=YES,DEFAULT=YES,FORCED=NO,LANGUAGE="en",URI="
https://primary-cdn.com/subs-1.m3u8",PATHWAY-ID="1"
#EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs-1",CHARACTERISTICS="public.accessibility.transcribes-spoken-dialog",NAME="English",AUTOSELECT=YES,DEFAULT=YES,FORCED=NO,LANGUAGE="en",URI="
https://backup-cdn.com/subs-1.m3u8",PATHWAY-ID="2"

I think this might require some minor changes under 4.3.4.1.1. Rendition
Groups in the HLS spec to clarify that entries in a group are not
duplicates when their PATHWAY-ID does not match.

Let me know if I've missed something as always!

Thanks again!

On Fri, Apr 16, 2021 at 12:23 AM Law, Will <wilaw=
[email-masked]> wrote:

> Well a big public thank you to Roger and the team at Apple for their open
> mindedness and willingness to take feedback around this, even to the degree
> that it represented a large rewrite of the feature. I think you have a
> genuinely simpler and thus more robust product as a result. We look forward
> to supporting you in taking it to production. It’s also encouraging for
> list members who put time & effort in to preparing feedback, to know that
> it is given due consideration. So thanks all around.
>
>
>
> In speaking with Kirk this afternoon, it would be really useful to have an
> additional optional reserved parameter of
>
>
>
> Why would this be useful? Primarily, it allows the decoupling of the check
> frequency from the steering execution frequency. Delivery problems can
> happen quickly  - within 30s in some cases. Having a 5 minute check-in
> interval means that a player can be banging its head against a poorly
> performing server for many minutes before it moves away. Users have proven
> inability to absorb such failures for more than 20s or so. We could address
> this problem by having the player call the steering server every 20s.
> However we don’t want the QoE churn that might come if the player switches
> at 20s intervals. It would be nice solution then if the player has the
> option of checking in frequently but the steering server could then
> intelligently steer some players who had been stable for a while,
> immediately, while for others it could wait for some churn-avoiding
> threshold before steering them. This new timestamp query arg would enable
> this optimized behavior and it would allow the steering server to remain
> stateless in its operation.
>
>
>
> Cheers
>
> Will
>
>
>
>
>
> *From: *Roger Pantos <rpantos=[email-masked]>
> *Date: *Thursday, April 15, 2021 at 3:29 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Hls-interest] Streaming Video Alliance Comments on HLS
> Content Steering Proposals
>
>
>
> Okay folks, we’ve done a number of audits and we think that simple
> annotation of redundant streams will work well enough for content steering.
> I’ve updated the spec to reflect that, and bumped the spec version to
> 1.2b1.
>
>
>
> We left an opening in 1.2 that will allow us to introduce new Pathways
> through the steering manifest if there’s a demand for that in the future.
>
>
>

-- 
Phil Cluff | Product Lead | +44 7983 406 937 | [email-masked]

---

From: Roger Pantos <[email-masked]>
Date: Fri, 16 Apr 2021 09:09:15 -0700

You’re quite welcome Will. We made a very deliberate decision to take this feature public early so that we would have (some) time to incorporate feedback. It’s encouraging to see so many of you giving it prompt and careful consideration.

Regarding your request for lastSteerTime, I don’t know that we need to formalize that into the spec at this point. A particular steering server could do what you describe itself by maintaining per-client state in RELOAD-URI query parameters. For instance, if the RELOAD-URI carried the preferred pathway ID when the response was formulated, the server could compare that with _HLS_pathway the next time the client checked in to determine if it had switched. The server could also record the last time that either the client reported a switch or the preferred pathway was changed to determine churn rate.

Roger.

> On Apr 15, 2021, at 4:23 PM, Law, Will <wilaw=[email-masked]> wrote:
>

---

From: Roger Pantos <[email-masked]>
Date: Fri, 16 Apr 2021 09:22:50 -0700

Hello Phil. Audio and text tracks can be steered to particular pathways the same way they are today: by defining per-pathway Rendition Groups and making sure each Variant Stream on a particular pathway specifies the Rendition Group for that pathway:

#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-0-A",NAME="en (Main)",DEFAULT=YES,LANGUAGE="en",URI="audio-0.m3u8 <https://primary-cdn.com/audio-0.m3u8>"
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-0-B",NAME="en (Main)",DEFAULT=YES,LANGUAGE="en",URI="https:// <https://backup-cdn.com/audio-0.m3u8>backup.example.com/content/videos/video12/audio-0.m3u8"

#EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="avc1.640028”,AUDIO="audio-0-A”,PATHWAY-ID="CDN-A"
low/audio-video.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="avc1.640028",AUDIO="audio-0-B",PATHWAY-ID="CDN-B"
https://backup.example.com/content/videos/video12/low/audio-video.m3u8

I’d be willing to add some advice along those lines to the spec, perhaps as a SHOULD. But at the moment I’m not inclined to require it, in order to give content providers maximum flexibility.

Roger.

> On Apr 16, 2021, at 2:14 AM, Phil Cluff <[email-masked]> wrote:
> 
> Thanks Roger and the Apple team for looking at this approach, it's really appreciated! I also really appreciate that this finally formalises the expected player behaviour for redundant streams.
> 
> I think there is something missing though, specifically, in the current implementation I don't think it works for un-muxed audio and video, and text tracks, since PATHWAY-ID can only be defined on #EXT-X-STREAM-INF, #EXT-X-I-FRAME-STREAM-INF.
> 
> I think we also need to be able to define PATHWAY-ID on #EXT-X-MEDIA so that we do things like this for redundant alternate audio or text tracks:
> 
> #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-0",NAME="en (Main)",DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en",URI="https://primary-cdn.com/audio-0.m3u8 <https://primary-cdn.com/audio-0.m3u8>",PATHWAY-ID="1"
> #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-0",NAME="en (Main)",DEFAULT=YES,AUTOSELECT=YES,LANGUAGE="en",URI="https://backup-cdn.com/audio-0.m3u8 <https://backup-cdn.com/audio-0.m3u8>",PATHWAY-ID="2"
> 
> #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs-1",CHARACTERISTICS="public.accessibility.transcribes-spoken-dialog",NAME="English",AUTOSELECT=YES,DEFAULT=YES,FORCED=NO,LANGUAGE="en",URI="https://primary-cdn.com/subs-1.m3u8 <https://primary-cdn.com/subs-1.m3u8>",PATHWAY-ID="1"
> #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP-ID="subs-1",CHARACTERISTICS="public.accessibility.transcribes-spoken-dialog",NAME="English",AUTOSELECT=YES,DEFAULT=YES,FORCED=NO,LANGUAGE="en",URI="https://backup-cdn.com/subs-1.m3u8 <https://backup-cdn.com/subs-1.m3u8>",PATHWAY-ID="2"
> 
> I think this might require some minor changes under 4.3.4.1.1. Rendition Groups in the HLS spec to clarify that entries in a group are not duplicates when their PATHWAY-ID does not match. 
> 
> On Fri, Apr 16, 2021 at 12:23 AM Law, Will <wilaw=[email-masked] <mailto:[email-masked]>> wrote:
> From: Roger Pantos <rpantos=[email-masked] <mailto:[email-masked]>>
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> https://www.ietf.org/mailman/listinfo/hls-interest <https://www.ietf.org/mailman/listinfo/hls-interest>
> 
> 
> -- 
> Phil Cluff | Product Lead | +44 7983 406 937 | [email-masked] <mailto:[email-masked]>

---

From: Phil Cluff <[email-masked]>
Date: Fri, 16 Apr 2021 18:30:15 +0100

Thanks Roger, that makes complete sense.

I think this is fine as a SHOULD for sure. I think it'd be good to have
this advice / example in the spec, as redundant streams in general have (in
my opinion) always been a little unloved from that perspective.

Thanks again!

On Fri, Apr 16, 2021 at 5:22 PM Roger Pantos <[email-masked]> wrote:

> Hello Phil. Audio and text tracks can be steered to particular pathways
> the same way they are today: by defining per-pathway Rendition Groups and
> making sure each Variant Stream on a particular pathway specifies the
> Rendition Group for that pathway:
>
> #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-0-A",NAME="en
> (Main)",DEFAULT=YES,LANGUAGE="en",URI="audio-0.m3u8
> <https://primary-cdn.com/audio-0.m3u8>"
> #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="audio-0-B",NAME="en
> (Main)",DEFAULT=YES,LANGUAGE="en",URI="https://
> <https://backup-cdn.com/audio-0.m3u8>
> backup.example.com/content/videos/video12/audio-0.m3u8"
>
>
> I’d be willing to add some advice along those lines to the spec, perhaps
> as a SHOULD. But at the moment I’m not inclined to require it, in order to
> give content providers maximum flexibility.
>
>
> Roger.
>
>> In speaking with Kirk this afternoon, it would be really useful to have
>> an additional optional reserved parameter of
>>
>>
>>
>> in which the player passes to the steering server the last wall-clock
>> time at which it executed a steering action.
>>
>>
>>
>> Why would this be useful? Primarily, it allows the decoupling of the
>> check frequency from the steering execution frequency. Delivery problems
>> can happen quickly  - within 30s in some cases. Having a 5 minute check-in