Re: [Hls-interest] Survey: signaling HLS client capability

[Gaëtan Hervouet <[e-mail]>]

Hi all,

I do agree with Will’s response. Relying on user-agent [1] is indeed
becoming harder and we have to move away from that. Cacheability and
debuggability are of course valid points [2] which is why the query
parameters do seem like a good solution (as long as there is no explosion
of combinations). I do see the problem with having the query parameter sent
on master manifest request impact the content of the variant playlists; it
would break cacheability. However, if that parameter were to be set for all
requests of the playback session (including variants) then the problem goes
away and the response is now deterministic and cacheable. We may also want
to consider an approach where the filters are not "features" but rather an
HLS spec/draft version that the player is compatible with.

We would also be totally fine with Will’s 2nd proposition however the
danger there is that the master playlist might explode in size if it needs
one EXT-X-STREAM-INF url for every combination of features. Sticking to the
client deciding what it can plays though, we could envision following an
LL-HLS approach where the EXT-X-SERVER-CONTROL tag appears in the *master*
manifest:

GET http://content.io./some-coment/master.m3u8

#EXTM3U

#EXT-X-VERSION:10

#EXT-X-SERVER-CONTROL:admode=interstitials

#EXT-X-STREAM-INF:BANDWIDTH=300000

http://content.io./some-content/variant1.m3u8
<http://content.io./some-coment/variant1.m3u8>

#EXT-X-STREAM-INF:BANDWIDTH=1000000

http://content.io./some-content/variant2.m3u8

Then for a device that supports interstitials, it requests the variant with:

GET http://content.io./some-coment/variant1.m3u8?_HLS_admode=interstitials
<http://content.io./some-coment/variant1.m3u8?_HLS_AdMode=interstitials>

Or a device that does not support interstitials:

GET http://content.io./some-coment/variant1.m3u8
<http://content.io./some-coment/variant1.m3u8?_HLS_AdMode=interstitials>

The query parameters would still allow the master and variant requests to
be cached deterministically and the client is the one making the decision
on what it plays while the server just sticks to advertising what it can
offer. Older players will ignore that EXT-X-SERVER-CONTROL tag and the
master playlist can stay relatively small and common to all users.

This example describes interstitials however there could be more
EXT-X-SERVER-CONTROL master attributes for important features, list would
have to be kept to a minimum to avoid an explosion of combination and keep
cache effective.

We think it’s important for that client compatibility feature to be
introduced at the same time as interstitials so that it can be used right
when it’s released instead of waiting years for a big enough number of
clients to support it. Supporting both interstitials and segment stitching
ad mode in one session does not really make sense even if it’s backward
compatible.


Cheers,
Gaetan

On Fri, May 21, 2021 at 5:25 PM Alex Giladi <[e-mail]> wrote:

> Regarding [1] in Will's e-mail, I'm concerned about nuclear
> proliferation of query parameters and special snowflake server-side
> logic.
> While everything is implementable, a deployment with smarter and more
> independent client selecting from a large (and growing) menu of
> options (i.e., [2] scales better
>
> On Fri, May 21, 2021 at 3:07 PM John Luther
> <jluther=[e-mail]> wrote:
> >
> >
> >
> > On Fri, May 21, 2021 at 4:55 PM Ali C. Begen <[e-mail]>
> wrote:
> >>
> >> Not that I don’t agree with what Will said in the rest of his email, I
> would like to express my 100x support for the statement below.
> >
> >
> > +100 from JW Player
> >
> >>
> >>
> >> > On May 21, 2021, at 11:48 PM, Law, Will <wilaw=
> [e-mail]> wrote:
> >> >
> >> > In parallel, I’d also like to see Apple moving the industry in the
> direction of making the players smarter. Player behavior specifications,
> updateable player logic (decoupled from device updates) , player
> conformance tests, and test suites would make for more manageable content &
> feature diversity in the decades ahead.
> >>
> >> --
> >> Hls-interest mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/hls-interest
> >
> > --
> > Hls-interest mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/hls-interest
>
> --
> Hls-interest mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hls-interest
>