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

[Roger Pantos <[e-mail]>]

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 <[e-mail]> 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.
> 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
> 
> 
> 
> Pieter-Jan Speelmans
> CTO
> 
> THEO Technologies NV
> w | www.theoplayer.com
> Philipssite 5, Bus 1. 3001 Leuven, Belgium
> 
> Leuven (Belgium) - New York (US) - Singapore (SG) - Barcelona (ES)
> BTW: BE 0847.829.290, RPR: Leuven
> 
> 
>> On Sat, Feb 20, 2021 at 4:07 AM Roger Pantos <[e-mail]> wrote:
>> 
>> 
>>> On Feb 17, 2021, at 1:46 PM, Pieter-Jan Speelmans <[e-mail]> 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), ...
>> 
>> 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
>> 
>> #EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING=“1”
>> 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”
>> 
>> #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.
>> 
>>> 
>>> 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
>>> 
>>> 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=[e-mail]> 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 [e-mail] if you want it to go directly to us.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> regards,
>>>> 
>>>> Roger Pantos
>>>> Apple Inc.-- 
>>>> Hls-interest mailing list
>>>> [e-mail]
>>>> 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 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
>> 
> 
> Legal Notice 
> 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