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

[Pieter-Jan Speelmans <[e-mail]>]

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, <[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]> 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
>>
>> #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"
>>                 }
>>             }
>>         }
>>     ]
>> }
>
>
> 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
> 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]> 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 
<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