Subject: [Hls-interest] HLS Content Steering v1.0b1 preliminary specification

From: Roger Pantos <[email-masked]>
Date: Wed, 17 Feb 2021 12:56:53 -0800

Hello hls-interest,

As discussed on the call today, here is the preliminary specification for the new Content Steering feature. We are converging on the final design for 1.0, so please take a look at it when you can and tell us what you think. 

You can send feedback to this list, or to [email-masked] if you want it to go directly to us.

regards,

Roger Pantos
Apple Inc.

---

From: Pieter-Jan Speelmans <[email-masked]>
Date: Wed, 17 Feb 2021 22:46:09 +0100

Hi all

I am pretty concerned about the backwards compatibility problems when
attempting to use this in combination with older devices. It will force
services to either provide two playlists, one with and one without
EXT-X-DEFINE with client-side detection of the maximum version supported by
the client. While this will not be an issue for up to date Apple devices,
this will definitely be an issue for out of date devices but also most
smart TVs, Chromecasts, Airplay implementations by those other than Apple
(f.e. on LG), ...

One option which could avoid this would be the following approach:
- Leverage the STABLE-VARIANT-ID and STABLE-RENDITION-ID identifiers to
modify an attribute of the Variant or Rendition.
- Allow a Variant or Rendition to be referenced in the Steering Manifest
with an updated value for the relevant attribute.
- Give the EXT-X-CONTENT-STEERING tag a MODIFIES attribute to list the
Variants and Renditions which will be modified and VARIANT-ATTRIBUTES and
RENDITION-ATTRIBUTES attributes to list the attributes which can be
modified rather than the DEFINES attribute.

The language for a Pathway would be defined as:

> {
>     "ID": string, // REQUIRED
>     "VARIANTS": { // REQUIRED
>
        "<STABLE-VARIANT-ID>": { // one for every variant listed to be
> modified

            Key-Value pairs for every attribute which you want to redefine
        }

    },
    "RENDITIONS": { // OPTIONAL

        "<STABLE-RENDITION-ID>": {  // one for every rendition listed as to
> be modified

            Key-Value pairs for every attribute which you want to redefine
        }

    }

}

For example this could make the Master Playlist.

> #EXTM3U
> #EXT-X-VERSION:8
>
>
> #EXT-X-CONTENT-STEERING:MODIFIED="VARIANT-1,VARIANT-2",VARIANT-ATTRIBUTES="URI",SERVER-URI="/steering?video=00001",PATHWAY-ID="My-Great-CDN"

#EXT-X-STREAM-INF:BANDWIDTH=1280000,CODECS="avc1.640028",STABLE-VARIANT-ID="VARIANT-1"
> https://cdn-a.example.com/low/main/audio-video.m3u8
>
> #EXT-X-STREAM-INF:BANDWIDTH=7680000,CODECS="avc1.640028",STABLE-VARIANT-ID="VARIANT-2"
> https://cdn-a.example.com/hi/main/audio-video.m3u8

Which results into a Steering Manifest like the one below.

> {
>     "TTL": 300,
>     "RELOAD-URI": "https://example.com/steering?video=00001&session=123",
>     "PATHWAYS": [
>         {
>             "ID": "My-Great-CDN",
>             "VARIANTS": {
>                 "VARIANT-1": {
>                     "URI": "
> https://cdn-a.example.com/low/main/audio-video.m3u8"
>                 }
>                 "VARIANT-2":{
>                     "URI": "
> https://cdn-a.example.com/hi/main/audio-video.m3u8"
>                 }
>             }
>         },
>         {
>             "ID": "My-Backup-CDN",
>             "VARIANTS": {
>                 "VARIANT-1":{
>                     "URI": "
> https://cdn-b.example.com/low/main/audio-video.m3u8"
>                 }
>                 "VARIANT-2":{
>                     "URI": "
> https://cdn-b.example.com/hi/main/audio-video.m3u8"
>                 }
>             }
>         }
>     ]
> }

Benefits:
- Fully backwards compatible. Older clients will simply ignore the new
EXT-X-CONTENT-STEERING tag, and use the primary source.
- No change needed to the Master Playlist other than the addition of
the #EXT-X-CONTENT-STEERING tag.
- Also compatible with the AUTH-case for EXT-X-DEFINE by allowing the
Variable Substitution on attributes after retrieval from the Steering
Manifest
- As an added bonus, for those who are modifying the master playlist
anyway, the use of STABLE-VARIANT-ID and STABLE-RENDITION-ID allows clients
to identify and identify the Variants and Renditions.

Drawback:
- More closely coupled with HLS, making reuse of the Steering Manifest for
other failover cases less likely.

My personal opinion is that the value of backwards compatibility would
warrant the drawbacks I currently see.

Best regards,
Pieter-Jan

*Pieter-Jan Speelmans*CTO

*THEO Technologies NV*
*w *| www.theoplayer.com
Philipssite 5, Bus 1. 3001 Leuven, Belgium
<https://d2oj23ymxjbl3l.cloudfront.net/>
Leuven (Belgium) - New York (US) - Singapore (SG) - Barcelona (ES)
BTW: BE 0847.829.290, RPR: Leuven

On Wed, Feb 17, 2021 at 9:57 PM Roger Pantos <rpantos=
[email-masked]> wrote:

> Hello hls-interest,
>
> As discussed on the call today, here is the preliminary specification for
> the new Content Steering feature. We are converging on the final design for
> 1.0, so please take a look at it when you can and tell us what you think.
>
> You can send feedback to this list, or to
> [email-masked] if you want it to go directly
> to us.
>
>
>
>
> regards,
>
> Roger Pantos
> Apple Inc.--
> Hls-interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hls-interest
>

-- 
*Legal Notice *
You can find the latest terms and policies of THEO 
Technologies under www.theoplayer.com/terms 
<http://www.theoplayer.com/terms> including our "GENERAL TERMS AND 
CONDITIONS". In the absence of a signed agreement between you and THEO 
Technologies, by replying to this email these terms apply to the relevant 
transaction between us.   
The contents of this email message and any 
attachments are intended solely for the addressee(s) and contain 
CONFIDENTIAL and/or privileged information and are legally protected from 
disclosure. If you are not the intended recipient of this message, please 
immediately alert the sender by reply email and then delete this message 
including any attachments and you are hereby notified that any use, 
dissemination, copying, or storage of this message or its attachments is 
strictly prohibited. 
Full security of emails over the internet cannot be 
ensured. Despite our efforts it is your responsibility to provide for your 
protection.
Global HQ: THEO Technologies NV, Philipssite 5 bus 1, 3001 
Heverlee, Belgium - BE 0847.829.290 - CEO: Steven Tielemans

---

From: Pieter-Jan Speelmans <[email-masked]>
Date: Thu, 18 Feb 2021 20:28:47 +0100

Hi Erik

All valid arguments and great feedback. Thanks for that.

For the modification of other parameters, this is something which can be
disallowed. I don't expect too much of an issue there. If I understand
correctly, attributes such as CODECS could currently also be replaced
through EXT-X-DEFINE.
Similarly the combination of two options to replace variables can be
managed. One could have priority over the other if needed. From a player
perspective, I don't expect any issue grill the player side.

The increased size of the manifest I wouldn't expect too much of an issue
from for practical scenarios if gzip is used.

I did not consider the manifest would need to become a per asset manifest.
That's indeed a big drawback.

For me the biggest concern remains backwards compatibility. For our player,
we can handle it.
Platforms where our customers are forced to use native players, will
restrain adoption significantly.

I hope there are some ideas here which could provide a path towards a
backwards compatibility. There are some other alternatives I can think of,
but all of them have drawbacks I fear.

Best regards,
Pieter-Jan

On Thu, 18 Feb 2021, 20:04 Eryk Vershen, <[email-masked]> wrote:

> I see some issues with the approach you suggest.
>
> On Feb 17, 2021, at 1:46 PM, Pieter-Jan Speelmans <
> [email-masked]> wrote:
>
> Hi all
>
> This suggests being able to modify attributes other than the URI. We
> explicitly disallow that.
> Allowing non-URI attributes to be modified creates the possibility for the
> structure of the master playlist to be changed significantly.
> This creates major problems for the player.
>
>
> This effectively means there are two mechanisms for substituting values:
> the existing variable substitution (EXT-X-DEFINE) and URI substitution via
> steering. Two mechanisms doing similar things is confusing. In addition, we
> would need to work out whether (and how) the two mechanisms could be used
> in the same playlist.
>
>
>         "<STABLE-RENDITION-ID>": {  // one for every rendition listed as
>> to be modified
>
> This is likely to increase the size of the manifests. A playlist can have
> several dozen stable iDs. That makes the notion of using a data URI as
> the SERVER-URI more problematic.
>
>
> With this design, the steering manifest is effectively required to be "per
> asset" rather than shareable across many assets.
>
> Regards,
> -eryk
>
> Eryk Vershen
> Apple Inc.
>
>
> Benefits:
> You can find the latest terms and policies of THEO Technologies under
> www.theoplayer.com/terms including our "GENERAL TERMS AND CONDITIONS". In
> the absence of a signed agreement between you and THEO Technologies, by
> replying to this email these terms apply to the relevant transaction
> between us.
> The contents of this email message and any attachments are intended solely
> for the addressee(s) and contain CONFIDENTIAL and/or privileged information
> and are legally protected from disclosure. If you are not the intended
> recipient of this message, please immediately alert the sender by reply
> email and then delete this message including any attachments and you are
> hereby notified that any use, dissemination, copying, or storage of this
> message or its attachments is strictly prohibited.
> Full security of emails over the internet cannot be ensured. Despite our
> efforts it is your responsibility to provide for your protection.
> Global HQ: THEO Technologies NV, Philipssite 5 bus 1, 3001 Heverlee,
> Belgium - BE 0847.829.290 - CEO: Steven Tielemans
>
>
>

---

From: Eryk Vershen <[email-masked]>
Date: Thu, 18 Feb 2021 11:04:36 -0800

> On Feb 17, 2021, at 1:46 PM, Pieter-Jan Speelmans <[email-masked]> wrote:
> 
> Hi all
> 
> I am pretty concerned about the backwards compatibility problems when attempting to use this in combination with older devices. It will force services to either provide two playlists, one with and one without EXT-X-DEFINE with client-side detection of the maximum version supported by the client. While this will not be an issue for up to date Apple devices, this will definitely be an issue for out of date devices but also most smart TVs, Chromecasts, Airplay implementations by those other than Apple (f.e. on LG), ...
> 
> - Leverage the STABLE-VARIANT-ID and STABLE-RENDITION-ID identifiers to modify an attribute of the Variant or Rendition.

This suggests being able to modify attributes other than the URI. We explicitly disallow that.
Allowing non-URI attributes to be modified creates the possibility for the structure of the master playlist to be changed significantly.
This creates major problems for the player.

> - Allow a Variant or Rendition to be referenced in the Steering Manifest with an updated value for the relevant attribute.

This effectively means there are two mechanisms for substituting values: the existing variable substitution (EXT-X-DEFINE) and URI substitution via steering. Two mechanisms doing similar things is confusing. In addition, we would need to work out whether (and how) the two mechanisms could be used in the same playlist.

> - Give the EXT-X-CONTENT-STEERING tag a MODIFIES attribute to list the Variants and Renditions which will be modified and VARIANT-ATTRIBUTES and RENDITION-ATTRIBUTES attributes to list the attributes which can be modified rather than the DEFINES attribute.
> 
>         "<STABLE-VARIANT-ID>": { // one for every variant listed to be modified
>         "<STABLE-RENDITION-ID>": {  // one for every rendition listed as to be modified

This is likely to increase the size of the manifests. A playlist can have several dozen stable iDs. That makes the notion of using a data URI as the SERVER-URI more problematic.

> https://cdn-a.example.com/low/main/audio-video.m3u8 <https://cdn-a.example.com/low/main/audio-video.m3u8>
> https://cdn-a.example.com/hi/main/audio-video.m3u8 <https://cdn-a.example.com/hi/main/audio-video.m3u8>
> 
>     "RELOAD-URI": "https://example.com/steering?video=00001&session=123 <https://example.com/steering?video=00001&session=123>",
>     "PATHWAYS": [
>         {
>             "ID": "My-Great-CDN",
>             "VARIANTS": {
>                 "VARIANT-1": {
>                     "URI": "https://cdn-a.example.com/low/main/audio-video.m3u8 <https://cdn-a.example.com/low/main/audio-video.m3u8>"
>                 } 
>                 "VARIANT-2":{
>                     "URI": "https://cdn-a.example.com/hi/main/audio-video.m3u8 <https://cdn-a.example.com/hi/main/audio-video.m3u8>"
>                 } 
>             }
>         },
>         {
>             "ID": "My-Backup-CDN",
>             "VARIANTS": {
>                 "VARIANT-1":{
>                     "URI": "https://cdn-b.example.com/low/main/audio-video.m3u8 <https://cdn-b.example.com/low/main/audio-video.m3u8>"
>                 } 
>                 "VARIANT-2":{
>                     "URI": "https://cdn-b.example.com/hi/main/audio-video.m3u8 <https://cdn-b.example.com/hi/main/audio-video.m3u8>"
>                 } 
>             }
>         }
>     ]
> }

With this design, the steering manifest is effectively required to be "per asset" rather than shareable across many assets.

Regards,
-eryk

Eryk Vershen
Apple Inc.

> Benefits:
> - Fully backwards compatible. Older clients will simply ignore the new EXT-X-CONTENT-STEERING tag, and use the primary source.
> - No change needed to the Master Playlist other than the addition of the #EXT-X-CONTENT-STEERING tag.
> - Also compatible with the AUTH-case for EXT-X-DEFINE by allowing the Variable Substitution on attributes after retrieval from the Steering Manifest 
> - As an added bonus, for those who are modifying the master playlist anyway, the use of STABLE-VARIANT-ID and STABLE-RENDITION-ID allows clients to identify and identify the Variants and Renditions.
> 
> Drawback:
> - More closely coupled with HLS, making reuse of the Steering Manifest for other failover cases less likely.
> 
> My personal opinion is that the value of backwards compatibility would warrant the drawbacks I currently see. 
> 
> Best regards,
> Pieter-Jan
> 
> 
> Pieter-Jan Speelmans
> CTO
> 
> THEO Technologies NV
> w | www.theoplayer.com <http://www.theoplayer.com/>
> On Wed, Feb 17, 2021 at 9:57 PM Roger Pantos <rpantos=[email-masked] <mailto:[email-masked]>> wrote:
> Hello hls-interest,
> 
> You can send feedback to this list, or to [email-masked] <mailto:[email-masked]> if you want it to go directly to us.
> 
> 
> 
> 
> regards,
> 
> Roger Pantos
> Apple Inc.-- 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/hls-interest <https://www.ietf.org/mailman/listinfo/hls-interest>
> 
> Legal Notice 
> You can find the latest terms and policies of THEO Technologies under www.theoplayer.com/terms <http://www.theoplayer.com/terms> including our "GENERAL TERMS AND CONDITIONS". In the absence of a signed agreement between you and THEO Technologies, by replying to this email these terms apply to the relevant transaction between us.   
> The contents of this email message and any attachments are intended solely for the addressee(s) and contain CONFIDENTIAL and/or privileged information and are legally protected from disclosure. If you are not the intended recipient of this message, please immediately alert the sender by reply email and then delete this message including any attachments and you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. 
> Full security of emails over the internet cannot be ensured. Despite our efforts it is your responsibility to provide for your protection.
> Global HQ: THEO Technologies NV, Philipssite 5 bus 1, 3001 Heverlee, Belgium - BE 0847.829.290 - CEO: Steven Tielemans

---

From: Eryk Vershen <[email-masked]>
Date: Thu, 18 Feb 2021 11:45:50 -0800

> On Feb 18, 2021, at 11:28 AM, Pieter-Jan Speelmans <[email-masked]> wrote:
> 
> Hi Erik
> 
> For the modification of other parameters, this is something which can be disallowed. I don't expect too much of an issue there. If I understand correctly, attributes such as CODECS could currently also be replaced through EXT-X-DEFINE.

The issue with string substitution in other attributes only applies when the variable comes from the steering manifest.

As a simple example, we could create variables, such that one pathway had English & German subtitles, while another pathway had French & Spanish subtitles.
More elaborate examples can be constructed.

> Similarly the combination of two options to replace variables can be managed. One could have priority over the other if needed. From a player perspective, I don't expect any issue grill the player side.
> 
> The increased size of the manifest I wouldn't expect too much of an issue from for practical scenarios if gzip is used. 
> 
> I did not consider the manifest would need to become a per asset manifest. That's indeed a big drawback.
> 
> For me the biggest concern remains backwards compatibility. For our player, we can handle it. 
> Platforms where our customers are forced to use native players, will restrain adoption significantly.
> 
> I hope there are some ideas here which could provide a path towards a backwards compatibility. There are some other alternatives I can think of, but all of them have drawbacks I fear.
> 
> Best regards,
> Pieter-Jan
> 
> 
> 
> On Thu, 18 Feb 2021, 20:04 Eryk Vershen, <[email-masked] <mailto:[email-masked]>> wrote:
>> On Feb 17, 2021, at 1:46 PM, Pieter-Jan Speelmans <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi all
>>

---

From: Roger Pantos <[email-masked]>
Date: Fri, 19 Feb 2021 19:07:16 -0800

> I am pretty concerned about the backwards compatibility problems when attempting to use this in combination with older devices. It will force services to either provide two playlists, one with and…

Well, we’re still early enough that we could consider changing the format. I’m not particularly moved by the hardship of supporting EXT-X-DEFINE — anybody who is implementing content steering is going to have to do at least that much work in their m3u8 parsing anyway — but I acknowledge that requiring content vendors to provide a different master playlists for old, un-updated clients is a non-trivial burden.

What if we took the following approach instead?

First, add a new STEERING attribute to regular EXT-X-STREAM and MEDIA tags:

#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING=“1”
https://a.example.com/video/mid/index.m3u8 <https://a.example.com/video/mid/index.m3u8>

#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING=“1”
https://a.example.com/video/high/index.m3u8 <https://a.example.com/video/high/index.m3u8>

This links the variants (and renditions) to a steering template definition:

#EXT-X-STEERING-TEMPLATE:ID=“1”,PREFIX="https://a.example.com/video <https://a.example.com/video>”

#EXT-X-CONTENT-STEERING:SERVER-URI="/steering?video=00001",PATHWAY-ID="My-Great-CDN"

The manifest would change a bit:

{
   "VERSION": 0
   "TTL": 300,
   "RELOAD-URI": "https://example.com/steering?video=00001&session=123",
   "PATHWAYS": [
       {
		"ID": "My-Great-CDN",
		"TEMPLATES": {
		   "1" : { 
			“PREFIX”: "https://a.example.com/video" 
		   }
		}
       },
       {
		"ID": "My-Backup-CDN",
		"TEMPLATES": {
		   "1" : { 
			“PREFIX”: "https://b.example.com/backup-video" 
		   }
		}
       }
   ]
}

The client would load and play the master playlist as usual. When it parsed the EXT-X-STREAM-INF and EXT-X-MEDIA tags it would see the STEERING attribute and verify that there is a corresponding EXT-X-STEERING-TEMPLATE and that the PREFIX of the steering template matches the start of the URI (fatal error if either check fails). It would store away the remainder of the URI as the “steerable part.”

When it loaded the manifest it would check that each pathway had an object in its TEMPLATES object for each STEERING-TEMPLATE (matching the key to the ID). (If it did not, steering would be disabled.)

To switch pathways it would concatenate the PREFIX from the TEMPLATES object with the steerable part of each URI. After that, everything would behave the same way.

This approach isn’t as flexible as general variable substitution. But I think that it would still cover the majority of the substitution use cases (and I’d be interested to hear about those that it doesn’t).

Roger.

---

From: Pieter-Jan Speelmans <[email-masked]>
Date: Sat, 20 Feb 2021 10:10:06 +0100

Hi Roger

One downside I see with this approach is the authentication tokens which
would be harder to replace for specific CDNs.
This could be resolved by making the PREFIX attribute a PATTERN containing
a regular expression instead. While very flexible, it would make things
slightly more complicated.
Also, what if CDN1 does not need an authentication token, but CDN2 does. In
that case, you might need to simply append rather than replace the token.
Another case would be if you would use relative paths, it could require a
prepend, and again only for CDN paths other than the current.

I do like the flexibility EXT-X-DEFINE gives. There could be an
intermediate solution where you use the EXT-X-STEERING with a PREPEND,
APPEND and FIND (and REPLACE) where the value could be a parameter as
defined in EXT-X-DEFINE.
In practice, it could look like this:

#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING=“1”
https://a.example.com/video/mid/index.m3u8

#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING=“1”
https://a.example.com/video/high/index.m3u8

#EXT-X-STEERING-TEMPLATE:ID=“1”,FIND="https://a.example.com/video
”,REPLACE="DOMAIN",APPEND="AUTH"

With a steering manifest amongst the lines of
{

  "TTL": 300,
  "RELOAD-URI": "https://example.com/steering?video=00001&session=123",
  "PATHWAYS": [
    {
      "ID": "My-Great-CDN",
      "VALUES": {
        "DOMAIN": "example.com",
        "AUTH": ""
      }
    },
    {
      "ID": "My-Backup-CDN",
      "VALUES": {
        "DOMAIN": "backup.example.com",
        "AUTH": "?auth=456"
      }
    }
  ]
}

It could give a "best of both worlds" where a variable could be filled in
through the original mechanism, but basically filling in a "default" value
for the variables. The case which could still remain tricky is the
authentication tokens, or if you have the authentication token in the URI
path, meaning you need to do 2 replaces (you could allow multiple
templates, but then it becomes hard again as you won't know which takes
precedence).

Best regards,
Pieter-Jan

*THEO Technologies NV*
*w *| www.theoplayer.com

On Sat, Feb 20, 2021 at 4:07 AM Roger Pantos <[email-masked]> wrote:

> Well, we’re still early enough that we could consider changing the format.
> I’m not particularly moved by the hardship of supporting EXT-X-DEFINE —
> anybody who is implementing content steering is going to have to do at
> least that much work in their m3u8 parsing anyway — but I acknowledge that
> requiring content vendors to provide a different master playlists for old,
> un-updated clients is a non-trivial burden.
>
> https://a.example.com/video/mid/index.m3u8
>
> https://a.example.com/video/high/index.m3u8
>
> #EXT-X-STEERING-TEMPLATE:ID=“1”,PREFIX="https://a.example.com/video”
>
>
> The client would load and play the master playlist as usual. When it
> parsed the EXT-X-STREAM-INF and EXT-X-MEDIA tags it would see the STEERING
> attribute and verify that there is a corresponding EXT-X-STEERING-TEMPLATE
> and that the PREFIX of the steering template matches the start of the URI
> (fatal error if either check fails). It would store away the remainder of
> the URI as the “steerable part.”
>
> When it loaded the manifest it would check that each pathway had an object
> in its TEMPLATES object for each STEERING-TEMPLATE (matching the key to the
> ID). (If it did not, steering would be disabled.)
>
> To switch pathways it would concatenate the PREFIX from
> the TEMPLATES object with the steerable part of each URI. After that,
> everything would behave the same way.
>
> This approach isn’t as flexible as general variable substitution. But I
> think that it would still cover the majority of the substitution use cases
> (and I’d be interested to hear about those that it doesn’t).
>
>
> Roger.
>
>

---

From: Roger Pantos <[email-masked]>
Date: Sat, 20 Feb 2021 08:19:35 -0800

I don’t the idea of burdening the client with a lot of complicated regex responsibilities. 

We’ve discussed adding SUFFIX or maybe some kind of query parameter override mechanism to the template. But before moving forward with that I’d want to hear some actual content providers coming forward to say that they’d use it. 

Roger
Sent from my iPhone. 

> On Feb 20, 2021, at 1:10 AM, Pieter-Jan Speelmans <[email-masked]> wrote:
> 
> 
> Hi Roger
> 
> One downside I see with this approach is the authentication tokens which would be harder to replace for specific CDNs.
> This could be resolved by making the PREFIX attribute a PATTERN containing a regular expression instead. While very flexible, it would make things slightly more complicated. 
> Also, what if CDN1 does not need an authentication token, but CDN2 does. In that case, you might need to simply append rather than replace the token.
> Another case would be if you would use relative paths, it could require a prepend, and again only for CDN paths other than the current.
> 
> I do like the flexibility EXT-X-DEFINE gives. There could be an intermediate solution where you use the EXT-X-STEERING with a PREPEND, APPEND and FIND (and REPLACE) where the value could be a parameter as defined in EXT-X-DEFINE.
> #EXT-X-STEERING-TEMPLATE:ID=“1”,FIND="https://a.example.com/video”,REPLACE="DOMAIN",APPEND="AUTH"
> 
> It could give a "best of both worlds" where a variable could be filled in through the original mechanism, but basically filling in a "default" value for the variables. The case which could still remain tricky is the authentication tokens, or if you have the authentication token in the URI path, meaning you need to do 2 replaces (you could allow multiple templates, but then it becomes hard again as you won't know which takes precedence).
> 
> Best regards,
> Pieter-Jan
> 
> 
> 
> Pieter-Jan Speelmans
> CTO
> 
> THEO Technologies NV
> w | www.theoplayer.com
>>> w | www.theoplayer.com
>>>> On Wed, Feb 17, 2021 at 9:57 PM Roger Pantos <rpantos=[email-masked]> wrote:
>>>> Hello hls-interest,
>>>> 
>>> You can find the latest terms and policies of THEO Technologies under www.theoplayer.com/terms including our "GENERAL TERMS AND CONDITIONS". In the absence of a signed agreement between you and THEO Technologies, by replying to this email these terms apply to the relevant transaction between us.   
> You can find the latest terms and policies of THEO Technologies under www.theoplayer.com/terms including our "GENERAL TERMS AND CONDITIONS". In the absence of a signed agreement between you and THEO Technologies, by replying to this email these terms apply to the relevant transaction between us.

---

From: Roger Pantos <[email-masked]>
Date: Fri, 26 Feb 2021 09:42:17 -0800

One objection we’ve heard to the approach below is that it requires the master playlist to be customized on a per-pathway basis. To address that we’re tweaking the proposal slightly: we're making the PATHWAY-ID attribute optional. If it is not present in the master playlist, the client will omit the _HLS_pathway query parameter from the steering manifest request until it obtains its first steering manifest.

(There are other ways for providers to communicate the initial pathway to the steering server. For instance, the SERVER-URI could be relative to the master playlist; each pathway could HTTP-redirect it to the actual steering server along with an origin identifier.)

Here are two examples of the current approach. The first one uses absolute URLs in the master playlist, as you might have with a dynamically-generated master playlist that knows the current pathway when the playlist is produced. The second uses relative URLs, as you might have for a static master playlist that is the same on all pathways.

In both cases the content is available here:

On the first CDN at -

	https://a.example.com/video/my-movie/master.m3u8 <https://a.example.com/video/my-movie/master.m3u8>

and on the second CDN at -

	https://b.example.com/backup-video/my-movie/master.m3u8 <https://b.example.com/backup-video/my-movie/master.m3u8>

-----

Absolute URIs (master playlist URI https://a.example.com/video/my-movie/master.m3u8 <https://a.example.com/video/my-movie/master.m3u8>)

#EXTM3U
#EXT-X-CONTENT-STEERING:SERVER-URI="https://example.com/steering?video=00001 <https://example.com/steering?video=00001&session=123>",PATHWAY-ID="My-Great-CDN"
#EXT-X-STEERING-TEMPLATE:ID="1",PREFIX="https://a.example.com/video <https://a.example.com/video>"
#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING="1"
https://a.example.com/video/my-movie/mid/index.m3u8 <https://a.example.com/video/my-movie/mid/index.m3u8>
#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING="1"
https://a.example.com/video/my-movie/high/index.m3u8 <https://a.example.com/video/my-movie/high/index.m3u8>

The client requests 

	https://example.com/steering?video=00001&_HLS_pathway=“My-Great-CDN <https://a.example.com/steering?video=00001&_HLS_pathway=%E2%80%9CMy-Great-CDN>"

And gets back this steering manifest:

{
  "VERSION": 0,
  "TTL": 300,
  "RELOAD-URI": "https://example.com/steering?video=00001&session=123 <https://example.com/steering?video=00001&session=123>",
  "PATHWAYS": [
    {
      "ID": "My-Great-CDN",
      "TEMPLATES": {
        "1" : {
          "PREFIX": "https://a.example.com/video <https://a.example.com/video>"
        }
      }
    },
    {
      "ID": "My-Backup-CDN",
      "TEMPLATES": {
        "1" : {
          "PREFIX": "https://b.example.com/backup-video <https://b.example.com/backup-video>"
        }
      }
    }
  ]
]

-----

Relative URIs (master playlist URI https://a.example.com/video/my-movie/master.m3u8 <https://a.example.com/video/my-movie/master.m3u8>)

#EXTM3U
#EXT-X-CONTENT-STEERING:SERVER-URI="https://example.com/steering?video=00001 <https://example.com/steering?video=00001&session=123>"
#EXT-X-STEERING-TEMPLATE:ID="1",PREFIX=""
#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING="1"
/mid/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING="1"
/high/index.m3u8

In this case PREFIX=“” indicates that the steerable part is the entire (relative) URI. So after the client receives the steering manifest (same as above), if it has to switch to My-Backup-CDN it will just prepend its PREFIX to the steerable part of each URL to produce:

	https://b.example.com/backup-video <https://b.example.com/backup-video>/mid/index.m3u8

	https://b.example.com/backup-video <https://b.example.com/backup-video>/high/index.m3u8

Unless anybody spots any other major flaws in this approach, we’ll plan to update the preliminary spec and send out another version.

Roger.

> On Feb 19, 2021, at 7:07 PM, Roger Pantos <[email-masked]> wrote:
> 
> 
> 
> 			“PREFIX”: "https://a.example.com/video <https://a.example.com/video>" 
> 		   }
> 		}
>        },
>        {
> 		"ID": "My-Backup-CDN",
> 		"TEMPLATES": {
> 		   "1" : { 
> 			“PREFIX”: "https://b.example.com/backup-video <https://b.example.com/backup-video>" 
> 		   }
> 		}
>        }
>    ]
> }
>

---

From: "Law, Will" <[email-masked]>
Date: Fri, 26 Feb 2021 23:01:48 +0000

Hi Roger

One comment here around the inconsistency of the ‘prefix’ rules between the two cases. The player is being asked to perform two different operations, with “” being a special flag that differentiates between the two.  I will explain the problem and then propose a solution.

The current master playlist #EXT-X-STEERING-TEMPLATE attribute is called “prefix”, which implies something inserted ahead of something else. However if we evaluate the first case with an absolute URL

#EXTM3U
#EXT-X-CONTENT-STEERING:SERVER-URI="https://example.com/steering?video=00001<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>",PATHWAY-ID="My-Great-CDN"
#EXT-X-STEERING-TEMPLATE:ID="1",PREFIX="https://a.example.com/video<https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>"
#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING="1"
https://a.example.com/video/my-movie/mid/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/mid/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44hforWWE$>
#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING="1"
https://a.example.com/video/my-movie/high/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/high/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mfpy4iP$>

      "ID": "My-Backup-CDN",
      "TEMPLATES": {
        "1" : {
          "PREFIX": "https://b.example.com/backup-video<https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>"

If the player wishes to implement the switch to my My-Backup-CDN , it must actually match & replace (not prefix) the original URL, in order to convert

https://a.example.com/video/my-movie/mid/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/mid/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44hforWWE$>

in to

https://b.example.com/backup-video/my-movie/mid/index.m3u8

A prefix operation would give https://b.example.com/backup-videohttps://a.example.com/video/my-movie/mid/index.m3u8  which is clearly invalid.

However in the second relative mode, illustrated by

#EXTM3U
#EXT-X-CONTENT-STEERING:SERVER-URI="https://example.com/steering?video=00001<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>"
#EXT-X-STEERING-TEMPLATE:ID="1",PREFIX=""
#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING="1"
/mid/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING="1"
/high/index.m3u8
This prefix operation is exactly what is required to convert

/mid/index.m3u8

in to

https://b.example.com/backup-video/my-movie/mid/index.m3u8

So we have an inconsistency in the algorithm that sits behind the use of “prefix” . This is never a good idea for players, which should rather perform the same operation consistently every time.

Proposal

  1.  Rename the master playlist #EXT-X-STEERING-TEMPLATE identifier PREFIX to be MATCH. This closer reflects its true functionality.
  2.  Implement this single algorithm in the player across all use cases:
     *   To create the NEW URL from the OLD URL given a master playlist MATCH value and a steering manifest  PREFIX value

  1.  Assign NEW to be the value of PREFETCH
  2.  Assign TEMP to be OLD URL
  3.  Delete from TEMP any part that matches MATCH. This operation is consistent even if MATCH is empty string.
  4.  Append TEMP to NEW to create the final URL.

Cheers
Will

From: Roger Pantos <rpantos=[email-masked]>
Date: Friday, February 26, 2021 at 9:42 AM
To: "[email-masked]" <[email-masked]>
Cc: http-live-streaming-review <[email-masked]>
Subject: Re: [Hls-interest] HLS Content Steering v1.0b1 preliminary specification

On the first CDN at -

https://a.example.com/video/my-movie/master.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qV1Gx_j$>

https://b.example.com/backup-video/my-movie/master.m3u8<https://urldefense.com/v3/__https:/b.example.com/backup-video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44llkyj51$>

-----

Absolute URIs (master playlist URI https://a.example.com/video/my-movie/master.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qV1Gx_j$>)

#EXTM3U
#EXT-X-CONTENT-STEERING:SERVER-URI="https://example.com/steering?video=00001<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>",PATHWAY-ID="My-Great-CDN"
#EXT-X-STEERING-TEMPLATE:ID="1",PREFIX="https://a.example.com/video<https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>"
#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING="1"
https://a.example.com/video/my-movie/mid/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/mid/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44hforWWE$>
#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING="1"
https://a.example.com/video/my-movie/high/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/high/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mfpy4iP$>

The client requests

https://example.com/steering?video=00001&_HLS_pathway=“My-Great-CDN<https://urldefense.com/v3/__https:/a.example.com/steering?video=00001&_HLS_pathway=**BMy-Great-CDN__;4oCc!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44h1w5BH2$>"

{
  "VERSION": 0,
  "TTL": 300,
  "RELOAD-URI": "https://example.com/steering?video=00001&session=123<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>",
  "PATHWAYS": [
    {
      "ID": "My-Great-CDN",
      "TEMPLATES": {
        "1" : {
          "PREFIX": "https://a.example.com/video<https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>"
        }
      }
    },
    {
      "ID": "My-Backup-CDN",
      "TEMPLATES": {
        "1" : {
          "PREFIX": "https://b.example.com/backup-video<https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>"
        }
      }
    }
  ]
]

-----

Relative URIs (master playlist URI https://a.example.com/video/my-movie/master.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qV1Gx_j$>)

#EXTM3U
#EXT-X-CONTENT-STEERING:SERVER-URI="https://example.com/steering?video=00001<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>"
#EXT-X-STEERING-TEMPLATE:ID="1",PREFIX=""
#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING="1"
/mid/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING="1"
/high/index.m3u8

https://b.example.com/backup-video<https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>/mid/index.m3u8

https://b.example.com/backup-video<https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>/high/index.m3u8

Roger.

On Feb 19, 2021, at 7:07 PM, Roger Pantos <[email-masked]<mailto:[email-masked]>> wrote:

On Feb 17, 2021, at 1:46 PM, Pieter-Jan Speelmans <[email-masked]<mailto:[email-masked]>> wrote:

Hi all

#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING=“1”
https://a.example.com/video/mid/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/mid/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44myYNLnQ$>

#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING=“1”
https://a.example.com/video/high/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/high/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44j6ekA61$>

#EXT-X-STEERING-TEMPLATE:ID=“1”,PREFIX="https://a.example.com/video<https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>”

The manifest would change a bit:
{
   "VERSION": 0
   "TTL": 300,
   "RELOAD-URI": "https://example.com/steering?video=00001&session=123<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>",
   "PATHWAYS": [
       {
"ID": "My-Great-CDN",
"TEMPLATES": {
  "1" : {
“PREFIX”: "https://a.example.com/video<https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>"
  }
}
       },
       {
"ID": "My-Backup-CDN",
"TEMPLATES": {
  "1" : {
“PREFIX”: "https://b.example.com/backup-video<https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>"
  }
}
       }
   ]
}

Roger.

Best regards,
Pieter-Jan

Pieter-Jan Speelmans
CTO

THEO Technologies NV
w | www.theoplayer.com<https://urldefense.com/v3/__http:/www.theoplayer.com/__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44kRAt7LO$>
Philipssite 5, Bus 1. 3001 Leuven, Belgium
[Image removed by sender.]<https://urldefense.com/v3/__https:/d2oj23ymxjbl3l.cloudfront.net/__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44uAXLPbU$>
Leuven (Belgium) - New York (US) - Singapore (SG) - Barcelona (ES)
BTW: BE 0847.829.290, RPR: Leuven

On Wed, Feb 17, 2021 at 9:57 PM Roger Pantos <rpantos=[email-masked]<mailto:[email-masked]>> wrote:
Hello hls-interest,

You can send feedback to this list, or to [email-masked]<mailto:[email-masked]> if you want it to go directly to us.

regards,

Roger Pantos
Apple Inc.--
Hls-interest mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/hls-interest<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/hls-interest__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44nsxABxl$>

Legal Notice
You can find the latest terms and policies of THEO Technologies under www.theoplayer.com/terms<https://urldefense.com/v3/__http:/www.theoplayer.com/terms__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44hw7Mpir$> including our "GENERAL TERMS AND CONDITIONS". In the absence of a signed agreement between you and THEO Technologies, by replying to this email these terms apply to the relevant transaction between us.
The contents of this email message and any attachments are intended solely for the addressee(s) and contain CONFIDENTIAL and/or privileged information and are legally protected from disclosure. If you are not the intended recipient of this message, please immediately alert the sender by reply email and then delete this message including any attachments and you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited.
Full security of emails over the internet cannot be ensured. Despite our efforts it is your responsibility to provide for your protection.
Global HQ: THEO Technologies NV, Philipssite 5 bus 1, 3001 Heverlee, Belgium - BE 0847.829.290 - CEO: Steven Tielemans

---

From: "Law, Will" <[email-masked]>
Date: Fri, 26 Feb 2021 23:38:56 +0000

Another question on this new proposal: can the spec clarify whether the client is required to request the steering manifest and resolve the pathways before it loads any media playlists? Given the playlist below

#EXTM3U

a client could start by immediately loading https://a.example.com/video/my-movie/mid/index.m3u8, and then resolving the steering manifest in the background after it had built up a few seconds of playback buffer. Players would be tempted to do this as it would provide a lower VST (by one RTT and whatever processing time there is on the steering server). This would be a bad outcome for two reasons a) For QoE as there could potentially be two cold hits against CDNs in the first 10s of playback   - one for the default and the second as the new pathway kicks in and b) if you are trying to move away from an underperforming default pathway your startup sequence would continue to be pinned against it.

The current version of the steering draft is ambiguous. It says “When the player needs to poll for Pathway updates,", but does not dictate when this should happen with respect to conventional start-up.

Suggestion is that if the player understands steering, it MUST resolve the steering manifest prior to loading any media playlist.

-Will

On the first CDN at -

-----

#EXTM3U

The client requests

{
  "VERSION": 0,
  "TTL": 300,

-----

#EXTM3U

Roger.

Hi all

Roger.

Best regards,
Pieter-Jan

Pieter-Jan Speelmans
CTO

THEO Technologies NV

regards,

Roger Pantos
Apple Inc.--

Legal Notice

---

From: Daniel Weinberger <[email-masked]>
Date: Sun, 28 Feb 2021 14:58:39 +0100

Hi Will,

I want to add some thoughts on your last part that a player should be
required to resolve the steering manifest before loading any media playlist.

I'm also in favor of clarifying the expected client behavior, but in this
case there is one negative side effect of your suggestion: It delays the
startup time of a video.
The steering manifest is referenced in the master playlist and if the
player is required to resolve it before the first media playlist is loaded,
this is one additional blocking step in between. I'm sure all player
vendors work hard to minimize startup time and adding additional blocking
requests here is not desired.
It can be argued that this is just a small text file and won't take long to
download even with bad network throughput, but there are also environments
where this is considerable: environments with higher latency.

Regards,
Daniel
_____________________________

 <http://www.bitmovin.com/>

*Daniel Weinberger*
Principal Solutions Architect

On Sat, Feb 27, 2021 at 12:39 AM Law, Will <wilaw=
[email-masked]> wrote:

> Another question on this new proposal: can the spec clarify whether the
> client is required to request the steering manifest and resolve the
> pathways *before* it loads any media playlists? Given the playlist below
>
>
>
> #EXTM3U
>
> #EXT-X-CONTENT-STEERING:SERVER-URI="
> https://example.com/steering?video=00001
> <https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>
> ",PATHWAY-ID="My-Great-CDN"
>
> #EXT-X-STEERING-TEMPLATE:ID="1",PREFIX="https://a.example.com/video
> <https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>
> "
>
> https://a.example.com/video/my-movie/mid/index.m3u8
> <https://urldefense.com/v3/__https:/a.example.com/video/my-movie/mid/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44hforWWE$>
>
> https://a.example.com/video/my-movie/high/index.m3u8
> <https://urldefense.com/v3/__https:/a.example.com/video/my-movie/high/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mfpy4iP$>
>
>
>
> a client could start by immediately loading
> https://a.example.com/video/my-movie/mid/index.m3u8, and then resolving
> the steering manifest in the background after it had built up a few seconds
> of playback buffer. Players would be tempted to do this as it would provide
> a lower VST (by one RTT and whatever processing time there is on the
> steering server). This would be a bad outcome for two reasons a) For QoE as
> there could potentially be two cold hits against CDNs in the first 10s of
> playback   - one for the default and the second as the new pathway kicks in
> and b) if you are trying to move away from an underperforming default
> pathway your startup sequence would continue to be pinned against it.
>
>
>
> The current version of the steering draft is ambiguous. It says “When the
> player needs to poll for Pathway updates,", but does not dictate when this
> should happen with respect to conventional start-up.
>
>
>
> Suggestion is that if the player understands steering, it MUST resolve the
> steering manifest prior to loading any media playlist.
>
>
>
> -Will
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *Roger Pantos <rpantos=[email-masked]>
> *Date: *Friday, February 26, 2021 at 9:42 AM
> *To: *"[email-masked]" <[email-masked]>
> *Cc: *http-live-streaming-review <
> [email-masked]>
> *Subject: *Re: [Hls-interest] HLS Content Steering v1.0b1 preliminary
> specification
>
>
>
> One objection we’ve heard to the approach below is that it requires the
> master playlist to be customized on a per-pathway basis. To address that
> we’re tweaking the proposal slightly: we're making the PATHWAY-ID attribute
> optional. If it is not present in the master playlist, the client will omit
> the _HLS_pathway query parameter from the steering manifest request until
> it obtains its first steering manifest.
>
>
>
> (There are other ways for providers to communicate the initial pathway to
> the steering server. For instance, the SERVER-URI could be relative to the
> master playlist; each pathway could HTTP-redirect it to the actual steering
> server along with an origin identifier.)
>
>
>
> Here are two examples of the current approach. The first one uses absolute
> URLs in the master playlist, as you might have with a dynamically-generated
> master playlist that knows the current pathway when the playlist is
> produced. The second uses relative URLs, as you might have for a static
> master playlist that is the same on all pathways.
>
>
>
> https://a.example.com/video/my-movie/master.m3u8
> <https://urldefense.com/v3/__https:/a.example.com/video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qV1Gx_j$>
>
>
>
> https://b.example.com/backup-video/my-movie/master.m3u8
> <https://urldefense.com/v3/__https:/b.example.com/backup-video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44llkyj51$>
>
>
>
> -----
>
>
>
> Absolute URIs (master playlist URI
> https://a.example.com/video/my-movie/master.m3u8
> <https://urldefense.com/v3/__https:/a.example.com/video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qV1Gx_j$>
> )
>
>
>
> #EXTM3U
>
> #EXT-X-CONTENT-STEERING:SERVER-URI="
> https://example.com/steering?video=00001
> <https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>
> ",PATHWAY-ID="My-Great-CDN"
>
> #EXT-X-STEERING-TEMPLATE:ID="1",PREFIX="https://a.example.com/video
> <https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>
> "
>
> https://a.example.com/video/my-movie/mid/index.m3u8
> <https://urldefense.com/v3/__https:/a.example.com/video/my-movie/mid/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44hforWWE$>
>
> https://a.example.com/video/my-movie/high/index.m3u8
> <https://urldefense.com/v3/__https:/a.example.com/video/my-movie/high/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mfpy4iP$>
>
>
>
> The client requests
>
>
>
> https://example.com/steering?video=00001&_HLS_pathway=“My-Great-CDN
> <https://urldefense.com/v3/__https:/a.example.com/steering?video=00001&_HLS_pathway=**BMy-Great-CDN__;4oCc!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44h1w5BH2$>
> "
>
>
>
>   "RELOAD-URI": "https://example.com/steering?video=00001&session=123
> <https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>
> ",
>
>   "PATHWAYS": [
>
>     {
>
>       "ID": "My-Great-CDN",
>
>       "TEMPLATES": {
>
>         "1" : {
>
>           "PREFIX": "https://a.example.com/video
> <https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>
> "
>
>         }
>
>       }
>
>     },
>
>     {
>
>       "ID": "My-Backup-CDN",
>
>       "TEMPLATES": {
>
>         "1" : {
>
>           "PREFIX": "https://b.example.com/backup-video
> <https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>
> "
>
>         }
>
>       }
>
>     }
>
>   ]
>
> ]
>
>
>
>
>
> -----
>
>
>
> Relative URIs (master playlist URI
> https://a.example.com/video/my-movie/master.m3u8
> <https://urldefense.com/v3/__https:/a.example.com/video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qV1Gx_j$>
> )
>
>
>
> #EXTM3U
>
> #EXT-X-CONTENT-STEERING:SERVER-URI="
> https://example.com/steering?video=00001
> <https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>
> "
>
> In this case PREFIX=“” indicates that the steerable part is the entire
> (relative) URI. So after the client receives the steering manifest (same as
> above), if it has to switch to My-Backup-CDN it will just prepend its
> PREFIX to the steerable part of each URL to produce:
>
>
>
> https://b.example.com/backup-video
> <https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>
> /mid/index.m3u8
>
>
>
> https://b.example.com/backup-video
> <https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>
> /high/index.m3u8
>
>
>
> Unless anybody spots any other major flaws in this approach, we’ll plan to
> update the preliminary spec and send out another version.
>
>
>
>
>
> Roger.
>
>
>
> <https://urldefense.com/v3/__https:/a.example.com/video/mid/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44myYNLnQ$>
>
> <https://urldefense.com/v3/__https:/a.example.com/video/high/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44j6ekA61$>
>
> #EXT-X-STEERING-TEMPLATE:ID=“1”,PREFIX="https://a.example.com/video
> <https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>
> ”
>
>
>    "RELOAD-URI": "https://example.com/steering?video=00001&session=123
> <https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>
> ",
>
>    "PATHWAYS": [
>
>        {
>
> "ID": "My-Great-CDN",
>
> "TEMPLATES": {
>
>   "1" : {
>
> “PREFIX”: "https://a.example.com/video
> <https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>
> "
>
>   }
>
> }
>
>        },
>
>        {
>
> "ID": "My-Backup-CDN",
>
> "TEMPLATES": {
>
>   "1" : {
>
> “PREFIX”: "https://b.example.com/backup-video
> <https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>
> "
>
>   }
>
> }
>
>        }
>
>    ]
>
> }
>
>
>
> *Pieter-Jan Speelmans *CTO
>
> *THEO Technologies NV*
> *w *| www.theoplayer.com
> <https://urldefense.com/v3/__http:/www.theoplayer.com/__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44kRAt7LO$>
> <https://urldefense.com/v3/__https:/d2oj23ymxjbl3l.cloudfront.net/__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44uAXLPbU$>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/hls-interest__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44nsxABxl$>
>
>
>
> *Legal Notice *
>
> www.theoplayer.com/terms
> <https://urldefense.com/v3/__http:/www.theoplayer.com/terms__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44hw7Mpir$>
> including our "GENERAL TERMS AND CONDITIONS". In the absence of a signed
> agreement between you and THEO Technologies, by replying to this email
> these terms apply to the relevant transaction between us.
>