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

"Law, Will" <wilaw@akamai.com> Fri, 26 February 2021 23:01 UTC

Return-Path: <wilaw@akamai.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 0FA9C3A131C for <hls-interest@ietfa.amsl.com>; Fri, 26 Feb 2021 15:01:58 -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=[AC_DIV_BONANZA=0.001, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 BAFDTBS6IeDd for <hls-interest@ietfa.amsl.com>; Fri, 26 Feb 2021 15:01:54 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 0E9243A1371 for <hls-interest@ietf.org>; Fri, 26 Feb 2021 15:01:53 -0800 (PST)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 11QN0nqU006865; Fri, 26 Feb 2021 23:01:51 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=IrqbnN1LGg3yIg2z9IvtAOxOojEAldyugz3vHGUmmGw=; b=P+vUHQwLNEpRSmsVN4iVTFqOqhIwVOMHjQipC28jugOpK0/py380ugIk4DDlibZQbFvf 3nifUkGPgkkirzKWV1sb+UfAGe8BRCQK4+0mjjVRUXKs/Rhi2D3tS6o+WD8g+Gy3PBrE forTOPMZNZRpl1pptTVAlTOFenyjRtEG8f2rTpKs3z58N2kS5hwN55uM3V6HBg8kAdok 9JxUkgAFkg+Ga9OJQ5gCSv7iz/wISnlIjaRSibAeEOaRsWnkCOOr234+ytxLLhT6adj9 jhTfN8TKt337et5SeTm+KMHVEjtuCJtRHSUT9ugLjSDnsWT4Y57KhdYx7AMEvLrF2kt1 og==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 36xd07v06x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Feb 2021 23:01:50 +0000
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 11QMn7aF009849; Fri, 26 Feb 2021 18:01:49 -0500
Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 36unvwqhn9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 26 Feb 2021 18:01:49 -0500
Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 26 Feb 2021 18:01:48 -0500
Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1497.010; Fri, 26 Feb 2021 18:01:48 -0500
From: "Law, Will" <wilaw@akamai.com>
To: Roger Pantos <rpantos=40apple.com@dmarc.ietf.org>
CC: http-live-streaming-review <http-live-streaming-review@group.apple.com>, "hls-interest@ietf.org" <hls-interest@ietf.org>
Thread-Topic: [Hls-interest] HLS Content Steering v1.0b1 preliminary specification
Thread-Index: AQHXBW90c5cRckquEEycLopFFPwJ56pdRlCAgAN+YgCACmJ3gP//wmMA
Date: Fri, 26 Feb 2021 23:01:48 +0000
Message-ID: <21D7F297-1B18-4246-B5A5-5DBAB0EBF49D@akamai.com>
References: <1F29DDD8-27B8-45B9-918F-6A45E906F4F4@apple.com> <CAAqSTpn7F3LsQCYf5CYLSfh-e-ig3HjVoYP6exxSqGTodYHqdw@mail.gmail.com> <4F54439A-A5AD-4687-9097-AF07FA1FB19D@apple.com> <C24E53B3-AB50-485F-A0F7-D4512742D2B5@apple.com>
In-Reply-To: <C24E53B3-AB50-485F-A0F7-D4512742D2B5@apple.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.45.21011103
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.27.118.139]
Content-Type: multipart/alternative; boundary="_000_21D7F2971B184246B5A55DBAB0EBF49Dakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-26_12:2021-02-26, 2021-02-26 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 adultscore=0 mlxlogscore=999 mlxscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102260168
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-02-26_12:2021-02-26, 2021-02-26 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 spamscore=0 mlxlogscore=999 impostorscore=0 phishscore=0 lowpriorityscore=0 clxscore=1011 malwarescore=0 bulkscore=0 suspectscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2102260170
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.19) smtp.mailfrom=wilaw@akamai.com smtp.helo=prod-mail-ppoint2
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/Oq0cp19DkBmbwSxcnnpoV8fUSeU>
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: Fri, 26 Feb 2021 23:02:03 -0000

Hi Roger

One comment here around the inconsistency of the ‘prefix’ rules between the two cases. The player is being asked to perform two different operations, with “” being a special flag that differentiates between the two.  I will explain the problem and then propose a solution.

The current master playlist #EXT-X-STEERING-TEMPLATE attribute is called “prefix”, which implies something inserted ahead of something else. However if we evaluate the first case with an absolute URL

#EXTM3U
#EXT-X-CONTENT-STEERING:SERVER-URI="https://example.com/steering?video=00001<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>",PATHWAY-ID="My-Great-CDN"
#EXT-X-STEERING-TEMPLATE:ID="1",PREFIX="https://a.example.com/video<https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>"
#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING="1"
https://a.example.com/video/my-movie/mid/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/mid/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44hforWWE$>
#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING="1"
https://a.example.com/video/my-movie/high/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/high/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mfpy4iP$>

      "ID": "My-Backup-CDN",
      "TEMPLATES": {
        "1" : {
          "PREFIX": "https://b.example.com/backup-video<https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>"


If the player wishes to implement the switch to my My-Backup-CDN , it must actually match & replace (not prefix) the original URL, in order to convert

https://a.example.com/video/my-movie/mid/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/mid/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44hforWWE$>

in to

https://b.example.com/backup-video/my-movie/mid/index.m3u8

A prefix operation would give https://b.example.com/backup-videohttps://a.example.com/video/my-movie/mid/index.m3u8  which is clearly invalid.

However in the second relative mode, illustrated by

#EXTM3U
#EXT-X-CONTENT-STEERING:SERVER-URI="https://example.com/steering?video=00001<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>"
#EXT-X-STEERING-TEMPLATE:ID="1",PREFIX=""
#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING="1"
/mid/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING="1"
/high/index.m3u8
This prefix operation is exactly what is required to convert

/mid/index.m3u8

in to

https://b.example.com/backup-video/my-movie/mid/index.m3u8

So we have an inconsistency in the algorithm that sits behind the use of “prefix” . This is never a good idea for players, which should rather perform the same operation consistently every time.

Proposal


  1.  Rename the master playlist #EXT-X-STEERING-TEMPLATE identifier PREFIX to be MATCH. This closer reflects its true functionality.
  2.  Implement this single algorithm in the player across all use cases:
     *   To create the NEW URL from the OLD URL given a master playlist MATCH value and a steering manifest  PREFIX value

  1.  Assign NEW to be the value of PREFETCH
  2.  Assign TEMP to be OLD URL
  3.  Delete from TEMP any part that matches MATCH. This operation is consistent even if MATCH is empty string.
  4.  Append TEMP to NEW to create the final URL.



Cheers
Will










From: Roger Pantos <rpantos=40apple.com@dmarc.ietf.org>
Date: Friday, February 26, 2021 at 9:42 AM
To: "hls-interest@ietf.org" <hls-interest@ietf.org>
Cc: http-live-streaming-review <http-live-streaming-review@group.apple.com>
Subject: Re: [Hls-interest] HLS Content Steering v1.0b1 preliminary specification

One objection we’ve heard to the approach below is that it requires the master playlist to be customized on a per-pathway basis. To address that we’re tweaking the proposal slightly: we're making the PATHWAY-ID attribute optional. If it is not present in the master playlist, the client will omit the _HLS_pathway query parameter from the steering manifest request until it obtains its first steering manifest.

(There are other ways for providers to communicate the initial pathway to the steering server. For instance, the SERVER-URI could be relative to the master playlist; each pathway could HTTP-redirect it to the actual steering server along with an origin identifier.)

Here are two examples of the current approach. The first one uses absolute URLs in the master playlist, as you might have with a dynamically-generated master playlist that knows the current pathway when the playlist is produced. The second uses relative URLs, as you might have for a static master playlist that is the same on all pathways.

In both cases the content is available here:

On the first CDN at -

https://a.example.com/video/my-movie/master.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qV1Gx_j$>

and on the second CDN at -

https://b.example.com/backup-video/my-movie/master.m3u8<https://urldefense.com/v3/__https:/b.example.com/backup-video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44llkyj51$>

-----

Absolute URIs (master playlist URI https://a.example.com/video/my-movie/master.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qV1Gx_j$>)

#EXTM3U
#EXT-X-CONTENT-STEERING:SERVER-URI="https://example.com/steering?video=00001<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>",PATHWAY-ID="My-Great-CDN"
#EXT-X-STEERING-TEMPLATE:ID="1",PREFIX="https://a.example.com/video<https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>"
#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING="1"
https://a.example.com/video/my-movie/mid/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/mid/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44hforWWE$>
#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING="1"
https://a.example.com/video/my-movie/high/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/high/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mfpy4iP$>

The client requests

https://example.com/steering?video=00001&_HLS_pathway=“My-Great-CDN<https://urldefense.com/v3/__https:/a.example.com/steering?video=00001&_HLS_pathway=**BMy-Great-CDN__;4oCc!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44h1w5BH2$>"

And gets back this steering manifest:

{
  "VERSION": 0,
  "TTL": 300,
  "RELOAD-URI": "https://example.com/steering?video=00001&session=123<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>",
  "PATHWAYS": [
    {
      "ID": "My-Great-CDN",
      "TEMPLATES": {
        "1" : {
          "PREFIX": "https://a.example.com/video<https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>"
        }
      }
    },
    {
      "ID": "My-Backup-CDN",
      "TEMPLATES": {
        "1" : {
          "PREFIX": "https://b.example.com/backup-video<https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>"
        }
      }
    }
  ]
]


-----

Relative URIs (master playlist URI https://a.example.com/video/my-movie/master.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/my-movie/master.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qV1Gx_j$>)

#EXTM3U
#EXT-X-CONTENT-STEERING:SERVER-URI="https://example.com/steering?video=00001<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>"
#EXT-X-STEERING-TEMPLATE:ID="1",PREFIX=""
#EXT-X-STREAM-INF:BANDWIDTH=200000,STEERING="1"
/mid/index.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING="1"
/high/index.m3u8

In this case PREFIX=“” indicates that the steerable part is the entire (relative) URI. So after the client receives the steering manifest (same as above), if it has to switch to My-Backup-CDN it will just prepend its PREFIX to the steerable part of each URL to produce:

https://b.example.com/backup-video<https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>/mid/index.m3u8

https://b.example.com/backup-video<https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>/high/index.m3u8

Unless anybody spots any other major flaws in this approach, we’ll plan to update the preliminary spec and send out another version.


Roger.


On Feb 19, 2021, at 7:07 PM, Roger Pantos <rpantos@apple.com<mailto:rpantos@apple.com>> wrote:




On Feb 17, 2021, at 1:46 PM, Pieter-Jan Speelmans <pieter-jan.speelmans@theoplayer.com<mailto: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://urldefense.com/v3/__https:/a.example.com/video/mid/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44myYNLnQ$>

#EXT-X-STREAM-INF:BANDWIDTH=400000,STEERING=“1”
https://a.example.com/video/high/index.m3u8<https://urldefense.com/v3/__https:/a.example.com/video/high/index.m3u8__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44j6ekA61$>

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

#EXT-X-STEERING-TEMPLATE:ID=“1”,PREFIX="https://a.example.com/video<https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>”

#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<https://urldefense.com/v3/__https:/example.com/steering?video=00001&session=123__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44qtYzaA4$>",
   "PATHWAYS": [
       {
"ID": "My-Great-CDN",
"TEMPLATES": {
  "1" : {
“PREFIX”: "https://a.example.com/video<https://urldefense.com/v3/__https:/a.example.com/video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44mqwdeF4$>"
  }
}
       },
       {
"ID": "My-Backup-CDN",
"TEMPLATES": {
  "1" : {
“PREFIX”: "https://b.example.com/backup-video<https://urldefense.com/v3/__https:/b.example.com/backup-video__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44gKCaDMb$>"
  }
}
       }
   ]
}

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<https://urldefense.com/v3/__http:/www.theoplayer.com/__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44kRAt7LO$>
Philipssite 5, Bus 1. 3001 Leuven, Belgium
[Image removed by sender.]<https://urldefense.com/v3/__https:/d2oj23ymxjbl3l.cloudfront.net/__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44uAXLPbU$>
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://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/hls-interest__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44nsxABxl$>

Legal Notice
You can find the latest terms and policies of THEO Technologies under www.theoplayer.com/terms<https://urldefense.com/v3/__http:/www.theoplayer.com/terms__;!!GjvTz_vk!E3AorzSNM8BjAiM9Qaz2_XmVx2NyOl_J1ZzrkyQCOBZuw0Khr__44hw7Mpir$> 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