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

[Phil Cluff <[e-mail]>]

I'm in agreement here both from a client and server perspective that this
should be strict, having some media playlists enable LL features but not
others just feels like an edge case for clients that is hard to support and
provides an inconsistent experience across quality levels, which I don't
like.

Thanks.

On Wed, Jul 22, 2020 at 5:35 PM Roger Pantos <rpantos=
[e-mail]> wrote:

> Our thinking at the moment is to specify the consistency requirement on an
> attribute-by-attribute basis, rather than a blanket rule that all
> SERVER-CONTROL tags must match. Right now we plan to put a “must match”
> requirement on every currently defined attribute, so it comes down to the
> same thing but it leaves us some more room for future expansion.
>
>
> Roger Pantos
> Apple Inc.
>
> On Jul 21, 2020, at 9:36 PM, Pieter-Jan Speelmans <
> [e-mail]> wrote:
>
> I do agree that strict is often best. Assumptions in most cases lead to
> issues down the road anyway.
>
> The attributes for which I see most value to allow a difference would be
> CAN-BLOCK-RELOAD. As already mentioned by Joey the hold back attributes
> would incur a lot of questions. For the other attributes, I can see a use
> for backup servers, for example falling back to a version hosted on a
> different CDN which doesn't support blocking reload. From a player
> perspective I don't see too big of a challenge to support this. Skip tags
> can be supported quite easily as well for our architecture.
>
> While it would be preferred for all attributes to be identical across
> renditions, I can see scenario's where this would not be feasible to
> achieve, especially on the blocking reload.
>
> 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) - San Francisco (US) - Singapore (SG) -
> Barcelona (ES)
> BTW: BE 0847.829.290, RPR: Leuven
>
>
> On Tue, Jul 21, 2020 at 8:26 PM Law, Will <wilaw=
> [e-mail]> wrote:
>
>> 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=[e-mail]>
>> *Date: *Tuesday, July 21, 2020 at 11:06 AM
>> *To: *Roger Pantos <rpantos=[e-mail]>
>> *Cc: *"[e-mail]" <[e-mail]>
>> *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=
>> [e-mail] <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
>> [e-mail]
>> 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=>
>>
>> --
>> 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
> --
> 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
>


-- 
Phil Cluff | Streaming Architect | [phone] | [e-mail]