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

From: Naiwei Zheng <[email-masked]>
Date: Fri, 19 Nov 2021 09:06:09 -0800

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 [email-masked].

Thank you!

Naiwei Zheng
HLS Team, Apple Inc.

---

From: "Law, Will" <[email-masked]>
Date: Fri, 19 Nov 2021 18:33:07 +0000

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=[email-masked]> wrote:

    Hi everyone,

    Thank you!

    Naiwei Zheng
    HLS Team, Apple Inc.

---

From: Naiwei Zheng <[email-masked]>
Date: Fri, 19 Nov 2021 10:43:15 -0800

> On Nov 19, 2021, at 10:33 AM, Law, Will <wilaw=[email-masked]> wrote:
> 
> Hi Naiwei
> 

Yes.

> 2. Params having the same name as an existing param should update the value?

Yes.

> 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 exclu…

At this point we cannot easily expand the valid character set, as doing so would break compatibility with existing clients.

Thanks,

Naiwei Zheng
HLS Team, Apple Inc.

---

From: Roger Pantos <[email-masked]>
Date: Fri, 19 Nov 2021 12:44:07 -0800

Hello Will,

> 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 exclu…

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

Roger.

> -- 
> Hls-interest mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hls-interest

---

From: "Law, Will" <[email-masked]>
Date: Fri, 19 Nov 2021 21:34:07 +0000

@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=[email-masked]> wrote:

    Hello Will,

    > https://urldefense.com/v3/__https://backup.example.com/content/videos/video12/eng.m3u8?tokenA=12345__;!!GjvTz_vk!AnSQiYq4xneY6XEgulqwaRIdBXzXOqy0iPbAONBSEhZGSLABcUX3q9tI_rsg$ 
    > 
    > https://urldefense.com/v3/__https://backup.example.com/content/videos/video12/eng.m3u8?tokenA=6789&tokenB=5555__;!!GjvTz_vk!AnSQiYq4xneY6XEgulqwaRIdBXzXOqy0iPbAONBSEhZGSLABcUX3qznyrFV1$ 
    > 
    > In other words, should 

    Roger.

    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!GjvTz_vk!AnSQiYq4xneY6XEgulqwaRIdBXzXOqy0iPbAONBSEhZGSLABcUX3q9zgI6d3$ 

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

---

From: Roger Pantos <[email-masked]>
Date: Sat, 20 Nov 2021 10:17:41 -0800

Inline:

> On Nov 19, 2021, at 1:34 PM, Law, Will <wilaw=[email-masked]> wrote:
> 

That strikes me as more of a convenience than a compelling design argument, frankly. The set of allowed characters in a URL includes much more than just '/' and ':' and supporting URLs as Pathway IDs would bring up questions about percent-escaping etc. That additional complexity would likely lead to interop issues between servers and clients. My inclination is to keep it simple.

> 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 steer…

That's good to hear!

Roger.