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

[Eryk Vershen <[e-mail]>]

> On Feb 18, 2021, at 11:28 AM, Pieter-Jan Speelmans <[e-mail]> wrote:
> 
> 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.

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, <[e-mail] <mailto:[e-mail]>> wrote:
> I see some issues with the approach you suggest.
> 
>> On Feb 17, 2021, at 1:46 PM, Pieter-Jan Speelmans <[e-mail] <mailto:[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), ...
>> 
>> 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.
> 
> 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.
>> 
>> 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
>>         } 
>>     } 
>> }
> 
> 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.
> 
> 
>> 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 <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 <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 <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/>
>> 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=[e-mail] <mailto:[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] <mailto:[e-mail]> if you want it to go directly to us.
>> 
>> 
>> 
>> 
>> regards,
>> 
>> Roger Pantos
>> Apple Inc.-- 
>> Hls-interest mailing list
>> [e-mail] <mailto:[e-mail]>
>> 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
> 
> 
> 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