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

Daniel Weinberger <daniel.weinberger@bitmovin.com> Tue, 25 May 2021 23:33 UTC

Return-Path: <daniel.weinberger@bitmovin.com>
X-Original-To: hls-interest@ietfa.amsl.com
Delivered-To: hls-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E1F3A1326 for <hls-interest@ietfa.amsl.com>; Tue, 25 May 2021 16:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bitmovin.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUK6NsW5RVaQ for <hls-interest@ietfa.amsl.com>; Tue, 25 May 2021 16:33:24 -0700 (PDT)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CAC3A1318 for <hls-interest@ietf.org>; Tue, 25 May 2021 16:33:24 -0700 (PDT)
Received: by mail-qv1-xf35.google.com with SMTP id c13so15802156qvx.5 for <hls-interest@ietf.org>; Tue, 25 May 2021 16:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bitmovin.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2iFM3yq1bwugJrL1f7AXV3eKN9zc4wRcO54jabBIlBQ=; b=r5PpjbEpgJ5pHS+LErFpzLWupuXnT24oLD6Ls6LH5jafJUQr1yVYOq9xOJCuu2CNsk ZWAEFqGEnlKS2uBJ5GdY4qHt6FhlHx9lrzTZ3jcc5Hp5Gib6elF3mNgEzQgDrxnuya/U G5F2iQDp7gtjmsvP82nLR0Qls9xN9ltcVHCgJ/WCulPSVFbpYq9juUOLOOoll3UH1YPK mn+Nrby4SMooGliCGwB+qGOxxHAiW/akWwFe7ZL4CQHEgRIls2sLPmUPx62TFJtA5zar ZpVjcDizwhBLzxYtTrYUwMSGV+VvWO9bPncoqreyEWlnPzWMavqPiBwrniPet9Uv6OHZ rJqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2iFM3yq1bwugJrL1f7AXV3eKN9zc4wRcO54jabBIlBQ=; b=WwSZrMG3JcLury6wLvl+tw57Q8Z4a9RCehCFgPynx69yrJz2DLvdtCzroyppwjiBQq ijyUNh0es6tAeepP1ZsQRMw7l3+eFoqSVxrXLxgeBkU0AVhZE/Gbobn/oX3X3FcrgsBU kt4IhZ9yMbpDmC4kcK3gkIpbAwsbZuR1OPiYHUCsh29lpZSSG5nNYbFXz/ij6hr0YYXv 5SBLIY71c8oXsuM0SEZhVEfAseqShpNaFg/BDjdNhn8IFwMgBSa3ex1YFQf3cMEoGheR 0wuWYy5UWM8mwlFBvW7lJSrJwdNO9C1G33WFR4P74b7ha3Wz9v1hRdxibWRxcvNF4GGN u2gQ==
X-Gm-Message-State: AOAM533PyZJu6AYdJ362JYpA/5HS0ZDh/xN+obwz8RPAN8A48RBBKm9A L2xPhMbXkjjkBAJc2ZhhWGi83zZTQphqLpNNT9tF
X-Google-Smtp-Source: ABdhPJzzYAZfdZ0YiwetaByEh76iO94g3lFsAGlhnZ8OlhJl8W/RBG1UQ/t9+qaYTy/pvPpB0kjAEHFikHIt4NSMbO4=
X-Received: by 2002:a05:6214:c6c:: with SMTP id t12mr38939023qvj.34.1621985601868; Tue, 25 May 2021 16:33:21 -0700 (PDT)
MIME-Version: 1.0
References: <8FE883FB-29BD-402B-BB50-E199036281EE@apple.com> <F6795C0F-A95E-42A1-85AA-23C01C5213DA@akamai.com> <369959B7-EACA-4127-834A-8300BA57D660@networked.media> <CAANhuA_UHZ4eXP14XO2U7=9MduFCRzBMfGas7FS4f0NpCEmL7g@mail.gmail.com> <CAF-MBS+tbGYg+SzjHGBU453ML_3H=Fi+s-w7cvYxSXL65pdSFg@mail.gmail.com> <CAEyqsc1QCftKsZz_ScvrHSQXFLYCxSK=q8M9G7s4ASNa6t-Dgw@mail.gmail.com>
In-Reply-To: <CAEyqsc1QCftKsZz_ScvrHSQXFLYCxSK=q8M9G7s4ASNa6t-Dgw@mail.gmail.com>
From: Daniel Weinberger <daniel.weinberger@bitmovin.com>
Date: Wed, 26 May 2021 01:33:05 +0200
Message-ID: <CAKwBfzEh7Wj+k2LBjqsym18UUwUcEQtGOu1AnMcXe=3Z0omjfA@mail.gmail.com>
To: Gaëtan Hervouet <gaetanhervouet=40google.com@dmarc.ietf.org>
Cc: Alex Giladi <alex.giladi@gmail.com>, John Luther <jluther=40jwplayer.com@dmarc.ietf.org>, "Ali C. Begen" <ali.begen@networked.media>, "Law, Will" <wilaw=40akamai.com@dmarc.ietf.org>, Roger Pantos <rpantos=40apple.com@dmarc.ietf.org>, "hls-interest@ietf.org" <hls-interest@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a16e9a05c32ff3d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/3LojkB5755-gVCQdZlfFjcujtx4>
Subject: Re: [Hls-interest] Survey: signaling HLS client capability
X-BeenThere: hls-interest@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussions about HTTP Live Streaming \(HLS\)." <hls-interest.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hls-interest>, <mailto:hls-interest-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hls-interest/>
List-Post: <mailto:hls-interest@ietf.org>
List-Help: <mailto:hls-interest-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hls-interest>, <mailto:hls-interest-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2021 23:33:30 -0000

I agree with most of what Will said. However, from the client perspective I
want to comment on this part specifically:

One problem with approach [1] is that you would want to use it when the
> client requests the main playlist, however it doesn’t know if the origin
> supports such filtering. It could therefore request AVC as the only codec,
> but receive a static playlist back from an origin that did not support
> filtering. There could be a playlist attribute added to indicate that the
> origin acknowledges the requests and has implemented the filters. If the
> client does not see such an acknowledgement echoed back, then it would know
> that it can’t trust the origin and would have to implement some decisions
> of its own. One could then argue that if it can make those decisions on its
> own, then why entertain the complexity of the filters? If a client is
> modern enough to add these filters to its requests, then couldn’t it simply
> apply them itself?


It's certainly a challenge to handle the case where the server/CDN doesn't
understand the filtering, but
a) it would lead to simply what we have today - a static playlist
b) one could argue that the application should in many use cases know
whether the backend can handle it or not.

I can't agree with the last sentence though. In fact, approach [1] provides
more power to the application that is using the player as it can simply
pass a playlist URL to the player with the correct parameters included.
This makes it completely transparent for the HLS client and any HLS client
can benefit from this new feature, it doesn't need to know about it at all
- as long as the application does.
This can be very powerful when thinking of (also legacy) devices and
platforms with a built-in HLS client, which often don't get updated by a
vendor at all or sporadically.


I agree with the concerns around approach [2] and in my view approach [1]
has fewer down-sides than [2], at least from a client perspective.

Regards,
Daniel
________
Bitmovin

On Tue, May 25, 2021 at 9:30 PM Gaëtan Hervouet <gaetanhervouet=
40google.com@dmarc.ietf.org> wrote:

> 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 <alex.giladi@gmail.com> 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=40jwplayer.com@dmarc.ietf.org> wrote:
>> >
>> >
>> >
>> > On Fri, May 21, 2021 at 4:55 PM Ali C. Begen <ali.begen@networked.media>
>> 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=
>> 40akamai.com@dmarc.ietf.org> 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
>> >> Hls-interest@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/hls-interest
>> >
>> > --
>> > Hls-interest mailing list
>> > Hls-interest@ietf.org
>> > https://www.ietf.org/mailman/listinfo/hls-interest
>>
>> --
>> Hls-interest mailing list
>> Hls-interest@ietf.org
>> https://www.ietf.org/mailman/listinfo/hls-interest
>>
> --
> Hls-interest mailing list
> Hls-interest@ietf.org
> https://www.ietf.org/mailman/listinfo/hls-interest
>