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

Pieter-Jan Speelmans <pieter-jan.speelmans@theoplayer.com> Wed, 22 July 2020 04:37 UTC

Return-Path: <pieter-jan.speelmans@theoplayer.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 EB0C13A0D90 for <hls-interest@ietfa.amsl.com>; Tue, 21 Jul 2020 21:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.788
X-Spam-Level:
X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=theoplayer-com.20150623.gappssmtp.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 Fit-kocgMGfE for <hls-interest@ietfa.amsl.com>; Tue, 21 Jul 2020 21:37:31 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 BF8933A0D8E for <hls-interest@ietf.org>; Tue, 21 Jul 2020 21:37:30 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id v6so1202180iob.4 for <hls-interest@ietf.org>; Tue, 21 Jul 2020 21:37:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=theoplayer-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gbPVZaRPOpY6Mlks4EnWzhiWzQENWUgvDFo83tdTqQU=; b=XvAMrbRvo4skAK5p/bG8U7NzW17MD/UeaYRhe87gVb2eQkOBcJXHcikFUYDCeuSG4W uBHdOeag4BxuzU0dpozNx3Pcs17ao/aTqm51HWcJPxh+O3D4w7fSo6oJimJEz+zzlEZR rQrk3qMeKaUVGG0CfFZaPEOCTK9UTyIoN0Kyv5Ze1e0wLI+v00yK2AzuiHVXYEOk/cYR RodWarZmVQd/CB4rYx1QA4+hdfEAyGnEd9afbkXxhB4TOqXyu8f2M8Zj9maEIz8DfwGq GQzQ7XDB7ir2qe87z4RoLThdYB2TdDghthrfLInYfUrIrapLW078zY53w/KMANIkCxoU imUA==
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=gbPVZaRPOpY6Mlks4EnWzhiWzQENWUgvDFo83tdTqQU=; b=dr1CakL0DWz1CGWaWw50VPb2OiCJzeTqjePZGkbF9/XYgmS510IZiLNXCxL0DKHDZf CVLnrA4kNzbphoREddv0gLLrQVzIyiw6r9emvC5jPnRkhpWgwxVipNaOyPKp77ayPOMT 9zan3SAoutHMQ4+0TpAE9fUgg+4hd4YMICjSj6pPStopzhOv+ZcR4IqRPx599hDbTuOm 9LNDyEAX/MlxpJdlKV+UaZO99VLNtxjYamY3V7BcmZiviJ/IvcA8+4EwHoA57Pi4xJMd /gMRNWLjB6OWp9Xcl0L/eV38CVmbtwVJZQI5FliigQdz3dXGjG0eEYbkFiIaIXt5GN47 R69A==
X-Gm-Message-State: AOAM533mex6KxUGFpJiI+g4lxCmOUqCe9IJtBgY6fOvtC4Eu8enWw7k6 EXGKc22gxjRsY2742zm60OFADw5TqO0OyQOG5CEuHbxBQ/YfqDv9OY8+IELgDVEzy+BRuf+dF9V qUu+g+3SU7xfCagUlyzXEBN0sIuA718LMig==
X-Google-Smtp-Source: ABdhPJxlL9DmMxgHpg2JZ6mEifzxhxdEnoL0Mssoxa4+mGy7KYWtYjuFEBl2xGzbwzKcmUna3RDoQyVUJxXUc+RniGk=
X-Received: by 2002:a6b:d31a:: with SMTP id s26mr31442860iob.48.1595392649662; Tue, 21 Jul 2020 21:37:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAB31503-1E90-4008-BBE5-91B4D25B65E9@apple.com> <CAM1-CVkgUVC8hS5Nc+fRhrfy-c-gDMBog6TtgyWJbyxJ29LV0A@mail.gmail.com> <F28C7DEA-F670-4EA0-93BC-E01281B6F96A@akamai.com>
In-Reply-To: <F28C7DEA-F670-4EA0-93BC-E01281B6F96A@akamai.com>
From: Pieter-Jan Speelmans <pieter-jan.speelmans@theoplayer.com>
Date: Wed, 22 Jul 2020 06:36:53 +0200
Message-ID: <CAAqSTpk14WhtWnK=xOJPOkFOBD-YHk-o7HFWtpkB15C+P-Do5Q@mail.gmail.com>
To: "Law, Will" <wilaw=40akamai.com@dmarc.ietf.org>
Cc: Roger Pantos <rpantos=40apple.com@dmarc.ietf.org>, Joey Parrish <joeyparrish=40google.com@dmarc.ietf.org>, "hls-interest@ietf.org" <hls-interest@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002932dd05ab004cbf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/WQ-DDjl4IBbNAxE2KlnC04bUXuc>
Subject: Re: [Hls-interest] LL-HLS survey: require all SERVER-CONTROL tags to match
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: Wed, 22 Jul 2020 04:37:33 -0000

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=40akamai.com@dmarc.ietf.org>
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=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 <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
> 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
> Hls-interest@ietf.org
> 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