Re: [Hls-interest] Streaming Video Alliance Comments on HLS Content Steering Proposals

[Roger Pantos <[e-mail]>]

You’re quite welcome Will. We made a very deliberate decision to take this feature public early so that we would have (some) time to incorporate feedback. It’s encouraging to see so many of you giving it prompt and careful consideration.

Regarding your request for lastSteerTime, I don’t know that we need to formalize that into the spec at this point. A particular steering server could do what you describe itself by maintaining per-client state in RELOAD-URI query parameters. For instance, if the RELOAD-URI carried the preferred pathway ID when the response was formulated, the server could compare that with _HLS_pathway the next time the client checked in to determine if it had switched. The server could also record the last time that either the client reported a switch or the preferred pathway was changed to determine churn rate.


Roger.

> On Apr 15, 2021, at 4:23 PM, Law, Will <wilaw=[e-mail]> wrote:
> 
> Well a big public thank you to Roger and the team at Apple for their open mindedness and willingness to take feedback around this, even to the degree that it represented a large rewrite of the feature. I think you have a genuinely simpler and thus more robust product as a result. We look forward to supporting you in taking it to production. It’s also encouraging for list members who put time & effort in to preparing feedback, to know that it is given due consideration. So thanks all around.
>  
> In speaking with Kirk this afternoon, it would be really useful to have an additional optional reserved parameter of
>  
> _HLS_lastSteerTime=<timestamp>
>  
> in which the player passes to the steering server the last wall-clock time at which it executed a steering action.
>  
> Why would this be useful? Primarily, it allows the decoupling of the check frequency from the steering execution frequency. Delivery problems can happen quickly  - within 30s in some cases. Having a 5 minute check-in interval means that a player can be banging its head against a poorly performing server for many minutes before it moves away. Users have proven inability to absorb such failures for more than 20s or so. We could address this problem by having the player call the steering server every 20s. However we don’t want the QoE churn that might come if the player switches at 20s intervals. It would be nice solution then if the player has the option of checking in frequently but the steering server could then intelligently steer some players who had been stable for a while, immediately, while for others it could wait for some churn-avoiding threshold before steering them. This new timestamp query arg would enable this optimized behavior and it would allow the steering server to remain stateless in its operation. 
>  
> Cheers
> Will
>  
>  
> From: Roger Pantos <rpantos=[e-mail]>
> Date: Thursday, April 15, 2021 at 3:29 PM
> To: "[e-mail]" <[e-mail]>
> Subject: Re: [Hls-interest] Streaming Video Alliance Comments on HLS Content Steering Proposals
>  
> Okay folks, we’ve done a number of audits and we think that simple annotation of redundant streams will work well enough for content steering. I’ve updated the spec to reflect that, and bumped the spec version to 1.2b1. 
>  
> We left an opening in 1.2 that will allow us to introduce new Pathways through the steering manifest if there’s a demand for that in the future.
>  
> As always, thanks to everyone for their thoughtful contributions!