Gary Katsevman

Is it something that could be used in conjunction with the existing shaka implementation? Like, if CML is passed to shaka, use CML, otherwise, use the existing implementation? The benefit...

That sounds like a great goal for a major version of shaka regardless of CML usage. Would that mean that CML integration would end up waiting for the major?

Interesting. I wonder if something broke in here? Since, this is specifically one of the use cases tested when the option was added.

Additionally, video.js doesn't specifically handle maintaining a forward buffering itself (like some other players), so, our potential events would mirror the existing events.

Looks like the last relevant change (https://github.com/videojs/video.js/pull/4497) was specifically to skip changing focus for mouse events. Maybe, it should be updated to instead only change focus on keyboard events instead...

Doing a stricter check for keyboard events is _probably_ fine, but we'd need to confirm that it continues to function for Screen Readers. So, potentially, the easiest is to exclude...

yeah, if captions can't work properly without that value, it should probably stop displaying the captions rather than stop playback altogether. Though, it seems like that throw has been around...

I'm not sure if I'll be able to get to it this week. Would a potential fix to make the error not be a critical error? I guess one concern...

A PR would be appreciated, but I'm not sure how easy and maintainable it would be to change since this is all generated from jsdoc.

less CEA and more general/webvtt 🙂 is there a public stream that showcases the issue specifically? If it started with v4.11.x, it might be related to https://github.com/shaka-project/shaka-player/pull/7022?