Re: [Hls-interest] FYI: Fall 2023 hls-interest meeting

Hi,

Agreed, such a roundtable would be great.

I also support Will's points, especially (1) around CMCD.

Another good topic would be to discuss if it makes sense to bring more
requirements from
https://developer.apple.com/documentation/http-live-streaming/hls-authoring-specification-for-apple-devices
into the HLS specification. For example, many of the Media Playlist
Requirements sound like they should be part of the HLS specification.

Regards,
Daniel Weinberger
Bitmovin Inc.

On Wed, Jul 19, 2023 at 12:47 AM Law, Will <wilaw=
40akamai.com@dmarc.ietf.org> wrote:

> Hi Roger
>
> An hls-interest meeting,  similar to the 2019 roundtable,  would be great.
> Thanks for organizing.
>
> For the agenda, I'd like to request three topics:
>
> 1. Adding CMCD (Common Media Client Data) support to the AVPlayer
> ecosystem. CMCD is now supported by the majority of players, including
> Exoplayer, Roku, hls.js, Theoplayer, Bitmovin, shaka, dash.js, video.js and
> others. I can provide data on the usage, the use-cases and the benefits of
> CMCD support as well as endorsements from the major streaming services who
> use it in production.
> 2. Consider the creation of a separate specification for Content Steering
> Services. Content distributors today want to steer populations of players
> across both HLS and DASH. The HLS IETF draft section 7 defines a mixture of
> server response and client behavior. There is a mirror specification in the
> DASH world. Someone building a steering service must reverse engineer the
> necessary behavior and properties of the service itself. Several
> ambiguities remain unanswered - are additional params allowed?, behavior
> with redirects?, how to report multiple pathways and throughputs since the
> last request?  For interoperability and robustness, it might be useful to
> normatively define the JSON response and behavior of a steering service
> (HLS sections 7.1 ... 7.3) in a separate specification. The HLS spec would
> then reference this spec and define the HLS cloning rules and client
> responsibilities and the DASH spec would do something similar.
> 3. Optimizing the request rate in LL-HLS  byte addressed playback by
> having the player optionally make one request per segment(after starting)
> instead of one request per part. Origin would still block on part
> boundaries and content would still be delivered at line speed.
>
> Cheers
> Will
>
>
>
>
> On 7/17/23, 5:34 PM, "Roger Pantos" <rpantos=40apple.com@dmarc.ietf.org
> <mailto:40apple.com@dmarc.ietf.org>> wrote:
>
>
>
>
> Hi everyone. We are thinking about holding another hls-interest meeting
> this fall. We're tentatively planning a hybrid in-person / remote event
> here in Cupertino. We’re trying to see if we can organize something the
> same week as FOMS and Demuxed (Oct. 23-27) when a lot of folks will be in
> town.
>
>
> If any of you have topics you’d like to discuss during the meeting, please
> send them our way so that we can put together some kind of agenda.
>
>
>
>
> thanks,
>
>
> Roger Pantos
> Apple Inc.
> --
> Hls-interest mailing list
> Hls-interest@ietf.org <mailto:Hls-interest@ietf.org>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!GjvTz_vk!VsfpaJ9j2qGu_r_3i63eu9E0t9DTfmeSgHtkoUi5sCH_8oZ1OFuR_cfAQPZ-hwGf5kd6cDzPK6oQNSdcr6GkYUpiG18w$
> <
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/hls-interest__;!!GjvTz_vk!VsfpaJ9j2qGu_r_3i63eu9E0t9DTfmeSgHtkoUi5sCH_8oZ1OFuR_cfAQPZ-hwGf5kd6cDzPK6oQNSdcr6GkYUpiG18w$>
>
>
>
>
> --
> Hls-interest mailing list
> Hls-interest@ietf.org
> https://www.ietf.org/mailman/listinfo/hls-interest
>