Re: [Hls-interest] LL-HLS survey: require all SERVER-CONTROL tags to match

Both packaging and player developers would benefit from the simplicity of stricter requirements of consistent server-control attributes across renditions.

If an implementer needed to remove server-control for backwards-compatibility with older clients, it would be simple enough for the origin to produce a parallel playlist with server-control consistently disabled across all renditions.

You may also consider a new _HLS_format  query arg which a player could pass to the origin when requesting the master playlist. This argument would allow the player to request characteristics of the subsequent presentations such as

  *   Discreet part versus byte range addressing
  *   Use of server control

These would only be requests. The origin would acknowledge compliance by returning the appropriate SERVER-CONTROL attributes and address syntax in the response. This allows a client to request the formatting and behavior that it wants, versus the implementation today in which the origin is blind to the needs of the client and the formatting decision is made ahead of runtime by a decoupled CMS.

-Will

From: Joey Parrish <joeyparrish=40google.com@dmarc.ietf.org>
Date: Tuesday, July 21, 2020 at 11:06 AM
To: Roger Pantos <rpantos=40apple.com@dmarc.ietf.org>
Cc: "hls-interest@ietf.org" <hls-interest@ietf.org>
Subject: Re: [Hls-interest] LL-HLS survey: require all SERVER-CONTROL tags to match

Hi Roger,

As a client developer, I would tend to prefer stricter requirements that would allow simpler clients.

Beyond the concerns you already mentioned, having per-rendition hold-backs would require our streaming model to change in Shaka Player, and I don't see any obvious benefit.  It's not even clear to me how we would be expected to operate with different hold-backs per rendition.

Would switching streams require us to change the "live edge" presented to the user?  (We consider two live edges: the true live edge of what's available to fetch from the server, and what we /tell/ the user is "live", which is the true live edge minus hold back.)

I don't work on the packaging side, but being strict about these attributes applying to all renditions would also seem to make compatibility with DASH easier to maintain.  For example, to be compatible with DASH, I expect a packager would be unable to use per-rendition hold-backs, even if they were allowed.

So why add the client complexity if multi-format packagers may not be able to use the feature anyway?

Thanks,
Joey

On Tue, Jul 21, 2020 at 10:47 AM Roger Pantos <rpantos=40apple.com@dmarc.ietf.org<mailto:40apple.com@dmarc..ietf.org>> wrote:
We plan to specify whether the attributes of the EXT-X-SERVER-CONTROL tag are allowed to vary between different Renditions. Following the principle that it’s always easier to progressively ease constraints than to impose new ones, our plan right now is be pretty strict up front and say that all attribute value must match across all Renditions.

(For reference, the currently-defined SERVER-CONTROL attributes are: CAN-SKIP-UNTIL; CAN-SKIP-DATERANGES; HOLD-BACK; PART-HOLD-BACK; CAN-BLOCK-RELOAD.)

One reason to require consistency is to avoid situations where a player tunes in to a particular set of Renditions, decides to join in LL mode (or not) and how far back from live, and then switches bitrate or language and encounters a different set of SERVER-CONTROL attributes that would have led it do a different tune-in decision, too late to avoid playback disruption.

Before we go ahead with the rule change I’d like to suss out any problems it would create. Specifically,

1) For packager vendors: would imposing this constraint place any unreasonable burdens on configuration or operation?

2) Conversely, for client implementations: would adopting a looser rule create problems, beyond what I described above?

thanks,

Roger Pantos
Apple Inc.
--
Hls-interest mailing list
Hls-interest@ietf.org<mailto:Hls-interest@ietf.org>
https://www.ietf.org/mailman/listinfo/hls-interest<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_hls-2Dinterest&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=KkevKJerDHRF9WRs8nW8Ew&m=OZRsplMkPccDsrzH4AFvrx6MmXNcMV48FT_LpcyYuCU&s=jmZkF9ELoQiNFW0ax4js-J6il1oiOzJOmegf2a3WUXY&e=>