Re: [Hls-interest] HLS Content Steering v1.0b1 preliminary specification

Roger Pantos <rpantos@apple.com> Sat, 20 February 2021 03:07 UTC

Return-Path: <rpantos@apple.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 172123A0FC0 for <hls-interest@ietfa.amsl.com>; Fri, 19 Feb 2021 19:07:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.657
X-Spam-Level:
X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.57, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 6VYYw5KGA67v for <hls-interest@ietfa.amsl.com>; Fri, 19 Feb 2021 19:07:20 -0800 (PST)
Received: from nwk-aaemail-lapp02.apple.com (nwk-aaemail-lapp02.apple.com [17.151.62.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854F23A0FBF for <hls-interest@ietf.org>; Fri, 19 Feb 2021 19:07:20 -0800 (PST)
Received: from pps.filterd (nwk-aaemail-lapp02.apple.com [127.0.0.1]) by nwk-aaemail-lapp02.apple.com (8.16.0.43/8.16.0.42) with SMTP id 11K36K1h051611; Fri, 19 Feb 2021 19:07:19 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=mQdw35TdGqt+Ny5YK2ptJHip6HqBqlaKHdf1GZkIELY=; b=uqhW8XKqLK+uiOcwrcDdio037bAWGo+CTjH7aM27uRC2ZdcJBzCqq0clf1xt9u1X41gV NQwwUHcHmz7BBDTmDYY7j7ld0YnVdwhtGLkia/MsK+Mic9YrByhdXjwMAku2F3jqAN7l JGUsRr5PXTPMnIhRo4o+sO930gUKypVLH3E3tt2+uPMu7QspwzBZo9gXwZUpZ3dFrW9i zbahNiF+11kbm30XIk+7EL9LXYcux85EsCPPPgUl2+Lx/k0vxIEmAV3xdyXErIruBfgh EK6/Ap4RDz+c1Vjx13dKJIjT/lQBOSIo0dg3LHG+yAIrWtiD2Wb3LDhymqpwWWwbn8GN RQ==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp02.apple.com with ESMTP id 36pc7msrhu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 19 Feb 2021 19:07:19 -0800
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPS id <0QOT009C84O6QX30@rn-mailsvcp-mta-lapp03.rno.apple.com>; Fri, 19 Feb 2021 19:07:18 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) id <0QOT002004IJ5Q00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Fri, 19 Feb 2021 19:07:18 -0800 (PST)
X-Va-A:
X-Va-T-CD: 363ce4028796a5d0ac470b3a48c24dcf
X-Va-E-CD: 4335616a6ac305163c7e0e056e870746
X-Va-R-CD: 3fe25e5da9104b0db2fa21b8031c261a
X-Va-CD: 0
X-Va-ID: 24dfb1d4-ad03-44d5-8c08-9020b2564a02
X-V-A:
X-V-T-CD: 363ce4028796a5d0ac470b3a48c24dcf
X-V-E-CD: 4335616a6ac305163c7e0e056e870746
X-V-R-CD: 3fe25e5da9104b0db2fa21b8031c261a
X-V-CD: 0
X-V-ID: 2e2ed3bf-efc9-4682-becb-ab099a288156
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-19_08:2021-02-18, 2021-02-19 signatures=0
Received: from smtpclient.apple (unknown [17.149.235.130]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.7.20201203 64bit (built Dec 3 2020)) with ESMTPSA id <0QOT00RD54O56600@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Fri, 19 Feb 2021 19:07:17 -0800 (PST)
From: Roger Pantos <rpantos@apple.com>
Message-id: <4F54439A-A5AD-4687-9097-AF07FA1FB19D@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_F8390666-B3C6-4DA8-BB7A-06A9F51458C0"
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.32\))
Date: Fri, 19 Feb 2021 19:07:16 -0800
In-reply-to: <CAAqSTpn7F3LsQCYf5CYLSfh-e-ig3HjVoYP6exxSqGTodYHqdw@mail.gmail.com>
Cc: hls-interest@ietf.org, http-live-streaming-review <http-live-streaming-review@group.apple.com>
To: Pieter-Jan Speelmans <pieter-jan.speelmans@theoplayer.com>
References: <1F29DDD8-27B8-45B9-918F-6A45E906F4F4@apple.com> <CAAqSTpn7F3LsQCYf5CYLSfh-e-ig3HjVoYP6exxSqGTodYHqdw@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.80.0.2.32)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-19_08:2021-02-18, 2021-02-19 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/hSVK5f_EKwniikMzMjH8PiUCiMw>
Subject: Re: [Hls-interest] HLS Content Steering v1.0b1 preliminary specification
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: Sat, 20 Feb 2021 03:07:23 -0000


> On Feb 17, 2021, at 1:46 PM, Pieter-Jan Speelmans <pieter-jan.speelmans@theoplayer.com> wrote:
> 
> Hi all
> 
> I am pretty concerned about the backwards compatibility problems when attempting to use this in combination with older devices. It will force services to either provide two playlists, one with and one without EXT-X-DEFINE with client-side detection of the maximum version supported by the client. While this will not be an issue for up to date Apple devices, this will definitely be an issue for out of date devices but also most smart TVs, Chromecasts, Airplay implementations by those other than Apple (f.e. on LG), ...

Well, we’re still early enough that we could consider changing the format. I’m not particularly moved by the hardship of supporting EXT-X-DEFINE — anybody who is implementing content steering is going to have to do at least that much work in their m3u8 parsing anyway — but I acknowledge that requiring content vendors to provide a different master playlists for old, un-updated clients is a non-trivial burden.

What if we took the following approach instead?

First, add a new STEERING attribute to regular EXT-X-STREAM and MEDIA tags:

#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING=“1”
https://a.example.com/video/mid/index.m3u8 <https://a.example.com/video/mid/index.m3u8>

#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING=“1”
https://a.example.com/video/high/index.m3u8 <https://a.example.com/video/high/index.m3u8>

This links the variants (and renditions) to a steering template definition:

#EXT-X-STEERING-TEMPLATE:ID=“1”,PREFIX="https://a.example.com/video <https://a.example.com/video>”

#EXT-X-CONTENT-STEERING:SERVER-URI="/steering?video=00001",PATHWAY-ID="My-Great-CDN"

The manifest would change a bit:

{
   "VERSION": 0
   "TTL": 300,
   "RELOAD-URI": "https://example.com/steering?video=00001&session=123",
   "PATHWAYS": [
       {
		"ID": "My-Great-CDN",
		"TEMPLATES": {
		   "1" : { 
			“PREFIX”: "https://a.example.com/video" 
		   }
		}
       },
       {
		"ID": "My-Backup-CDN",
		"TEMPLATES": {
		   "1" : { 
			“PREFIX”: "https://b.example.com/backup-video" 
		   }
		}
       }
   ]
}

The client would load and play the master playlist as usual. When it parsed the EXT-X-STREAM-INF and EXT-X-MEDIA tags it would see the STEERING attribute and verify that there is a corresponding EXT-X-STEERING-TEMPLATE and that the PREFIX of the steering template matches the start of the URI (fatal error if either check fails). It would store away the remainder of the URI as the “steerable part.”

When it loaded the manifest it would check that each pathway had an object in its TEMPLATES object for each STEERING-TEMPLATE (matching the key to the ID). (If it did not, steering would be disabled.)

To switch pathways it would concatenate the PREFIX from the TEMPLATES object with the steerable part of each URI. After that, everything would behave the same way.

This approach isn’t as flexible as general variable substitution. But I think that it would still cover the majority of the substitution use cases (and I’d be interested to hear about those that it doesn’t).


Roger.

> 
> My personal opinion is that the value of backwards compatibility would warrant the drawbacks I currently see. 
> 
> Best regards,
> Pieter-Jan
> 
> 
> Pieter-Jan Speelmans
> CTO
> 
> THEO Technologies NV
> w | www.theoplayer.com <http://www.theoplayer.com/>
> Philipssite 5, Bus 1. 3001 Leuven, Belgium
>  <https://d2oj23ymxjbl3l.cloudfront.net/>
> Leuven (Belgium) - New York (US) - Singapore (SG) - Barcelona (ES)
> BTW: BE 0847.829.290, RPR: Leuven
> 
> 
> On Wed, Feb 17, 2021 at 9:57 PM Roger Pantos <rpantos=40apple.com@dmarc.ietf.org <mailto:40apple.com@dmarc.ietf.org>> wrote:
> Hello hls-interest,
> 
> As discussed on the call today, here is the preliminary specification for the new Content Steering feature. We are converging on the final design for 1.0, so please take a look at it when you can and tell us what you think. 
> 
> You can send feedback to this list, or to http-live-streaming-review@group.apple.com <mailto:http-live-streaming-review@group.apple.com> if you want it to go directly to us.
> 
> 
> 
> 
> regards,
> 
> 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://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