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

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

@Roger re "Can you illustrate the use case for URLs as Pathway-IDs?"

Yes - I was looking at steering from the point of view of a distributor who needs to steer both HLS and DASH content, and wondering if the same steering response could be used to steer both formats. Since DASH has the concept of BaseURLs (functionally equivalent to multi-source HLS variants), it turns out  that as long as we add the steering server URL to the manifest and add some sort of pathway-ID to each BaseURL, then it is relatively trivial to also steer a DASH player with no changes to the steering server output. This idea is captured at https://github.com/Dash-Industry-Forum/DASH-IF-IOP/issues/406. While discussing this it was raised that instead of adding a new attribute to the baseURL, we could simply use the baseURL itself as the identifier. Hence my question to Naiwei as to whether the current restrictions on characters could be relaxed.

If the answer is no, and no-one else raises use-cases that requires URLs inside pathway-IDs, then I think it's fine and can rescind the request __  We have another workaround (discussed this morning actually) on the DASH side which is to override the existing serviceLocation attribute of BaseURL as use that as a pathway-ID. I think that will work.

I am reasonably confident that the currently defined steering server response will be able to be used interoperably across formats, and that is a good prospect for anyone currently building a steering service. 

Cheers
Will

 

On 11/19/21, 12:44 PM, "Roger Pantos" <rpantos=[e-mail]> wrote:

    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://urldefense.com/v3/__https://backup.example.com/content/videos/video12/eng.m3u8?tokenA=12345__;!!GjvTz_vk!AnSQiYq4xneY6XEgulqwaRIdBXzXOqy0iPbAONBSEhZGSLABcUX3q9tI_rsg$ 
    > 
    > 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://urldefense.com/v3/__https://backup.example.com/content/videos/video12/eng.m3u8?tokenA=6789&tokenB=5555__;!!GjvTz_vk!AnSQiYq4xneY6XEgulqwaRIdBXzXOqy0iPbAONBSEhZGSLABcUX3qznyrFV1$ 
    > 
    > 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!GjvTz_vk!AnSQiYq4xneY6XEgulqwaRIdBXzXOqy0iPbAONBSEhZGSLABcUX3q9zgI6d3$ 

    -- 
    Hls-interest mailing list
    [e-mail]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!GjvTz_vk!AnSQiYq4xneY6XEgulqwaRIdBXzXOqy0iPbAONBSEhZGSLABcUX3q9zgI6d3$