Re: [Hls-interest] HLS Content Steering v1.3b1 spec update

[Roger Pantos <[e-mail]>]

Hello Will,

> On Nov 19, 2021, at 10:33 AM, Law, Will <wilaw=[e-mail]> wrote:
> 
> Hi Naiwei
> 
> Thanks for updating us on this new cloning proposal. Two questions for you:
> 
> 1. Can you clarify the desired behavior
> 
> If the multivariant playlist contains a pathway entry for CDN-A with the following value: 
> 
> https://backup.example.com/content/videos/video12/eng.m3u8?tokenA=12345
> 
> and then the player receives a steering response which includes a clone instruction for CDN-A with 
> 
> "PARAMS":
> {
> "tokenA": "6789",
> "tokenB": "55555"
> }
> 
> Does it construct the following variant URI for the clone of CDN-A as
> 
> https://backup.example.com/content/videos/video12/eng.m3u8?tokenA=6789&tokenB=5555
> 
> In other words, should 
> 1. New params should be added to the URI, preserving  the existing params?
> 2. Params having the same name as an existing param should update the value?

As Naiwei indicated the answer is "yes." We can add some clarifying language to the spec ("Pathway Cloning"): ".., replacing any existing name/value pair with the same name."

> 
> 2. The current spec limits the pathway-ID string to allow only characters from the set [a..z], [A..Z], [0..9], '.', '-', and '_'. This prohibits the use of URLs as pathway-IDs, since "://" is excluded. Since you are revising the steering spec, is there any chance the character restrictions could be expanded to include "://"? The use case is interoperability of the steering server response to steer non-HLS traffic. 

Can you illustrate the use case for URLs as Pathway-IDs?


Roger.

> 
> Cheers
> 
> Will
> 
> 
> On 11/19/21, 9:25 AM, "Naiwei Zheng" <naiwei=[e-mail]> wrote:
> 
>    Hi everyone,
> 
>    We really appreciate the kind and thoughtful feedback we received from the community since we announced the Content Steering feature.
> 
>    As you may recall, we scaled back our original design for Content Steering based on your feedback. Since then, we've heard from three very large content partners that they do in fact require the ability to introduce new content Pathways during playback, ones that were not part of the original Multivariant Playlist, in order to take advantage of Content Steering.
> 
>    To address that requirement, we are updating the Content Steering spec. Version 1.3 (draft) adds a provision for producing new pathways by "cloning" existing ones. This support is explicitly optional, for both the server and the client.
> 
>    The 1.3 spec also specifies that stable IDs must be present to enable Content Steering for downloadable content. This is because stable IDs are essential for coordinating bit-identical variants and renditions across different Pathways, so that downloader can continue fetching from a bit-identical stream after switching Pathways.
> 
>    For more info, review the attached spec document, and as always, your comments are welcomed, either to his-interest or directly to us at [e-mail].
> 
>    Thank you!
> 
>    Naiwei Zheng
>    HLS Team, Apple Inc.
> 
> 
> -- 
> Hls-interest mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hls-interest