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

["Law, Will" <[e-mail]>]

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?



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. 

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.