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

From: Roger Pantos <[email-masked]>
Date: Tue, 21 Jul 2020 10:47:34 -0700

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.

---

From: Joey Parrish <[email-masked]>
Date: Tue, 21 Jul 2020 11:06:01 -0700

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=
[email-masked]> 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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hls-interest
>

---

From: "Law, Will" <[email-masked]>
Date: Tue, 21 Jul 2020 18:26:21 +0000

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=[email-masked]>
Date: Tuesday, July 21, 2020 at 11:06 AM
To: Roger Pantos <rpantos=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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=[email-masked]<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.

thanks,

Roger Pantos
Apple Inc.
--
Hls-interest mailing list
[email-masked]<mailto:[email-masked]>
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=>

---

From: Pieter-Jan Speelmans <[email-masked]>
Date: Wed, 22 Jul 2020 06:36:53 +0200

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=[email-masked]>
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=[email-masked]>
> *Date: *Tuesday, July 21, 2020 at 11:06 AM
> *To: *Roger Pantos <rpantos=[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [Hls-interest] LL-HLS survey: require all SERVER-CONTROL
> tags to match
>
>
>
> Hi Roger,
>
>
>
> 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.
>
>
>
> [email-masked] <40apple.com@dmarc..ietf.org>> wrote:
>
> <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=>
>
> --

-- 
*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

---

From: Roger Pantos <[email-masked]>
Date: Wed, 22 Jul 2020 09:35:23 -0700

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 <[email-masked]> 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 <http://www.theoplayer.com/>
> Leuven (Belgium) - New York (US) - San Francisco (US) - Singapore (SG) - Barcelona (ES)
> On Tue, Jul 21, 2020 at 8:26 PM Law, Will <wilaw=[email-masked] <mailto:[email-masked]>> wrote:
> Discreet part versus byte range addressing
> Use of server control
>  
> 
> From: Joey Parrish <joeyparrish=[email-masked] <mailto:[email-masked]>>
> To: Roger Pantos <rpantos=[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Tue, Jul 21, 2020 at 10:47 AM Roger Pantos <rpantos=[email-masked] <mailto:40apple.com@dmarc..ietf.org>> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> 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=>-- 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/hls-interest <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 <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
> --

---

From: Phil Cluff <[email-masked]>
Date: Thu, 23 Jul 2020 11:16:34 +0100

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=
[email-masked]> 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 <
> [email-masked]> wrote:
>
> On Tue, Jul 21, 2020 at 8:26 PM Law, Will <wilaw=
> [email-masked]> wrote:
>
>> 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
> 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
> --

-- 
Phil Cluff | Streaming Architect | +44 7983 406 937 | [email-masked]