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

David Hassoun <david@realeyes.com> Mon, 01 March 2021 16:50 UTC

Return-Path: <david@realeyes.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 3BFDD3A1F6E for <hls-interest@ietfa.amsl.com>; Mon, 1 Mar 2021 08:50:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=realeyes-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 WhFKrXpwSdJd for <hls-interest@ietfa.amsl.com>; Mon, 1 Mar 2021 08:50:00 -0800 (PST)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 BFEB13A1F6B for <hls-interest@ietf.org>; Mon, 1 Mar 2021 08:49:59 -0800 (PST)
Received: by mail-qk1-x732.google.com with SMTP id q85so17170975qke.8 for <hls-interest@ietf.org>; Mon, 01 Mar 2021 08:49:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realeyes-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cTTs7o82sZ/myTbbdSNEtuclZcGtBludfp3CMTsFcFA=; b=j8YpH6AXW9VWAi2du8XKZf3j/fb6gFPy/XWzM7nRsWi5rEMfOlRqWobdrdKt09fiKj RcxDv2xt9ba57mkSgHBRGBpGVNZL/7RMtfqlKoUgjeRHet8h9tINqeRvu5LtaOsAoXrX 1P3dY3JLCntEEcKSm9KgkeApiyZqXrrMh7DxWvQznE8VFgfRztny92XODK06y/aaT20J i1Zn4+48I7p0ddGASHWyRUO6QfxB4mTj5+g4HbqFscAm8qLjepxm64vi8DgKaCSLxBmn pLOZ+20jE0hN+ywgyDtYdM1UZqRgVKSRau/QJ6z3PCW114cbdhddA8ziSJziIaCN3bB+ cqWQ==
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=cTTs7o82sZ/myTbbdSNEtuclZcGtBludfp3CMTsFcFA=; b=hhKUCN0VyMZKoKB8D4qhnuCgXZiTN+jxNG+GX+WWJXRoxgsV5Dle8HYdPgWQMS/0w/ ok5W9Qlxd8cCcnkOU1NiS81Rr4Mfw3jEOO3Z/BRCKIrnqRfEQOz7vAJmgaaXhNx+DkSm QTNrRbeyXMjsIo1rM5XzB2U49rJscosDxMDrHBsDC/RPZ5vXVC93403ezcb/P30d5g3j dygApBgf1bLcKsOMnTKdN0J6B2UBv5dw8I5AXD2bcwPOjK239hVXovjMHowaI9YR1Y+S GwPUKcX+bQyNbCbK7PZcmAmwii9uGlNJhBEycR2thvh6668g6VrNJ2d5mjYBVR1Pj7nT 5efw==
X-Gm-Message-State: AOAM531krJQlvj2Taz1BcRmAEforGKKGAbdO4KwSqG3FUD/1NB/LyJoT yWOCcMv126drJ+7UEBwiy4CCVwg7TIBstsRHijUU+w==
X-Google-Smtp-Source: ABdhPJzIN3/1ZIIFGWxQB2N2N1PKykbQxBmxELk69V/Q5Pp2+wZ//q7pzNuAFnWTduEdhSoOQoQ1ZH2ORCN5Yb2RfNo=
X-Received: by 2002:a05:620a:13db:: with SMTP id g27mr3457677qkl.367.1614617397703; Mon, 01 Mar 2021 08:49:57 -0800 (PST)
MIME-Version: 1.0
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> <3DA545F7-EC5B-4DFE-B8AC-A753B20DAD46@akamai.com> <CAKwBfzGxgXLry3EhC=0Dv=k=sWfTOnkk_qE0yHsCF6Vio+3fag@mail.gmail.com>
In-Reply-To: <CAKwBfzGxgXLry3EhC=0Dv=k=sWfTOnkk_qE0yHsCF6Vio+3fag@mail.gmail.com>
From: David Hassoun <david@realeyes.com>
Date: Mon, 01 Mar 2021 09:49:45 -0700
Message-ID: <CAAhbKqFMGDktZ8c3rmK=5XVeK3+KJ-cCFng_S1C7k2YYX_qcrg@mail.gmail.com>
To: Daniel Weinberger <daniel.weinberger@bitmovin.com>
Cc: "Law, Will" <wilaw=40akamai.com@dmarc.ietf.org>, http-live-streaming-review <http-live-streaming-review@group.apple.com>, "hls-interest@ietf.org" <hls-interest@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000704ccb05bc7c6834"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hls-interest/jha8rcSAjuACPh3aJ6ns0NunDCg>
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: Mon, 01 Mar 2021 16:50:04 -0000

This is in part why I'm still in favor of an optional client API that can
apply the data done from the steering service. It wont affect VST if this
client already has the data up front to adjust the initial steering and
avoids another API request.

I do think it is very important to have the option to provide up front
steering control outside of the initial playlist control as
realistically many solutions wont have dynamic server generated playlists
(at least for some time).  I know there is pushback to have client API when
everything is being primed to be done from the steering manifest - aka
server side. Though I still find it totally reasonable to have the server
be default with the option to override in client. There was discussion
about a client API to at minimum force a steering load and then with the
local proxy we could do it all client side - or at least partial client
with logic to determine when to override or not. However that still does
not address a clean up front steering control. I suppose we could have an
API/Boolean-Property to determine if a steering manifest is required up
front before playback. If so it will attempt the request and the client can
proxy/intercept to set data immediately or let the http call go through.
It's fairly complex but would potentially achieve the benefit and control
needed?

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Feb 28, 2021 at 6:59 AM Daniel Weinberger <
daniel.weinberger@bitmovin.com> wrote:

> Hi Will,
>
> I want to add some thoughts on your last part that a player should be
> required to resolve the steering manifest before loading any media playlist.
>
> I'm also in favor of clarifying the expected client behavior, but in this
> case there is one negative side effect of your suggestion: It delays the
> startup time of a video.
> The steering manifest is referenced in the master playlist and if the
> player is required to resolve it before the first media playlist is loaded,
> this is one additional blocking step in between. I'm sure all player
> vendors work hard to minimize startup time and adding additional blocking
> requests here is not desired.
> It can be argued that this is just a small text file and won't take long
> to download even with bad network throughput, but there are also
> environments where this is considerable: environments with higher latency.
>
> Regards,
> Daniel
> _____________________________
>
> [image: Bitmovin] <http://www.bitmovin.com/>
>
> *Daniel Weinberger*
> Principal Solutions Architect
>
>
> On Sat, Feb 27, 2021 at 12:39 AM Law, Will <wilaw=
> 40akamai.com@dmarc.ietf.org> wrote:
>
>> Another question on this new proposal: can the spec clarify whether the
>> client is required to request the steering manifest and resolve the
>> pathways *before* it loads any media playlists? Given the playlist below
>>
>>
>>
>> #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$>
>>
>>
>>
>> a client could start by immediately loading
>> https://a.example.com/video/my-movie/mid/index.m3u8, and then resolving
>> the steering manifest in the background after it had built up a few seconds
>> of playback buffer. Players would be tempted to do this as it would provide
>> a lower VST (by one RTT and whatever processing time there is on the
>> steering server). This would be a bad outcome for two reasons a) For QoE as
>> there could potentially be two cold hits against CDNs in the first 10s of
>> playback   - one for the default and the second as the new pathway kicks in
>> and b) if you are trying to move away from an underperforming default
>> pathway your startup sequence would continue to be pinned against it.
>>
>>
>>
>> The current version of the steering draft is ambiguous. It says “When the
>> player needs to poll for Pathway updates,", but does not dictate when this
>> should happen with respect to conventional start-up.
>>
>>
>>
>> Suggestion is that if the player understands steering, it MUST resolve
>> the steering manifest prior to loading any media playlist.
>>
>>
>>
>> -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> wrote:
>>
>>
>>
>>
>>
>>
>>
>> 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://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: 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> 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 if you want it to go directly
>> to us.
>>
>>
>>
>>
>> regards,
>>
>> Roger Pantos
>> Apple Inc.--
>> Hls-interest mailing list
>> 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
>>
>>
>>
>>
>> --
>> Hls-interest mailing list
>> Hls-interest@ietf.org
>> https://www.ietf.org/mailman/listinfo/hls-interest
>>
> --
> Hls-interest mailing list
> Hls-interest@ietf.org
> https://www.ietf.org/mailman/listinfo/hls-interest
>


-- 


*[ David Hassoun | CEO ] *[ p. 303.872.0442 | c. 303.359.7466 ]
[ RealEyes | www.realeyes.com ]
[ 940 Logan | Denver CO, 80203 ]

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>