I agree. I think that piece stems from meeting people where they're at. So, if they use react, they should be able to use video.js without any headaches. This, historically, has been an issue for Video.js.
I think that web components is likely a good direction because they're the new building block for the web. Plus, at this point, all these frameworks should have native support for them. Though, it may still warrant specific wrappers to account for various intricacies.
Additionally, a modular codebase that you can pick and choose what you want to include is helpful here as well.

Yeah, I think "first-class" is probably too vague of a term and can be interpreted a number of ways. What I meant is that React has always felt like an afterthought in everything from documentation to architecture, and we don't want that to be the case anymore, not just for React but for many popular UI frameworks. I think more recent player projects have done that better, like Vidstack and Player.style.

Hey there, I wanted to chime in here too as I'll be unpacking a lot of this with the team in the coming months! I'm mostly speaking for myself here. I'm the author of an open-source player called Vidstack and I'm also currently on the Mux team. We've briefly started to review existing player architectures under our portfolio (quite a few now) as we plan ahead for v10.

I'll second what heff said in that "first-class" is vague here and it doesn't mean we're planning on centering our player architecture solely around React. I'm personally interested in an agnostic-core that would easily plug into Web Components, React, (your favourite framework). Similar to TanStack and some of the work I did in Vidstack (minus some poor decisions). Basically an architecture we can leverage to ship idiomatic primitives and hooks for any framework, not just React.

In my experience, plus what we've seen in the wild with projects like Media Chrome, while Web Components are great in theory and for certain applications, practically speaking they're not ideal for shipping a great universal developer experience. It can feel like another framework target and limited in design. It's quite an in-depth topic and hard to unpack in a comment but happy to answer specifics as we get further along.

In addition, I wouldn't want us to be locked to any single technology, framework, or environment (e.g., DOM). The web has drastically changed over the last decade. I'd like to keep ourselves flexible to how it might further change in the next decade whilst accounting for the past. I think solid abstractions centered around a well-designed core architecture will get us there. Ultimately, staying true to good software design.

This is a heavy topic and I wouldn't expect most to align with me on it immediately, hoping as I share designs and communicate more with community members that it'll become clearer. I'm not against Web Components at all (love certain parts more than others - looking at Custom Elements), I just think they have narrow applications and can't be used as the big hammer to all nails type thing. We can and should definitely still ship them, and we can even build parts of our library with them where we want strong styling encapsulation and a "drop-in" customizable experience (e.g., themes like player.style).

Yeah @gradyplayer we've been discussing this a lot. What I think we all agree on over at Mux at least is we should not be building a player that presumes React (which folks have been clarifying here). For folks who just need video on a framework-less, vanilla HTML + JS page, they should be able to do that (and for folks using svelte, or vue, or angularjs, etc. etc. they also should be able to use the player). However, we also want to make sure, at least as much as possible, that folks using an application framework can use the player in a way that feels idiomatic to the framework without having to jump through hoops or learn a bunch of stuff that gets in the way of them using, customizing, etc. the player. To do this to its full extent for all app frameworks is a tall ask, so we're heavily leaning towards prioritizing particular frameworks that are popular, hence React as "first class". This doesn't mean we don't/won't care about other app frameworks, but we've found that our web component solution has worked reasonably well for most of those users/use cases.

I'd love as much guidance as people can give on the specific cutoffs (like @itsjamie has started). I think @littlespex was recommending an even higher Chrome version when we were talking about this IRL yesterday.

Related question, are all new devices shipping today actually supporting the evergreen-ness of the browser they include, or in 10 years are we going to be complaining about Chrome 137 on old devices?

Just double checked, the pts/dts changeover was chrome 69 https://developer.chrome.com/blog/media-updates-in-chrome-69/#pts

But yes, TVs tend to not get updated at all. Supposedly, LG's TVs, at least the oled C and G series are supposed to be getting software updated for 3 years, which may include chromium version bumps. But personally, I'm never plugging a personal smart tv into the internet ever again...

So, yes, I expect us to be complaining about older chromium builds in 5 years time, haha. Though, hopefully, the new devices now can be supported by the newer project via transpilation/polyfills.

"all new devices" is gonna be a tall order, but the heavy hitters like Samsung and LG have gotten better about API compliance, firmware updates, and even aggressive nudges for said updates (even if not always motivated by the things we may want/care about). That said, unless things change, there will likely be a non-trivial number of folks who defer/delay any firmware/software updates until forced (partly understandable, because often enough these updates have negative general performance impacts on older devices). Add to that expectations from businesses, contractual obligations between device manufacturers and streaming providers, and customer expectations/awareness when they say "Top Streaming Service is garbage on (old and unupdated) Major TV Brand!" Sooo... TL;DR - It will plausibly be better but unlikely to ever be a "non-issue", at least in the foreseeable future.

Chrome 70 has changeType which makes juggling source buffers a little easier.

@heff here's a quick set of reference resources

LG Web Engine Support Matrix: https://webostv.developer.lge.com/develop/specifications/web-api-and-web-engine

• covers a few of the Smart TV brands, as they're based on webOS.

Samsung Web Engine Support Matrix: https://developer.samsung.com/smarttv/develop/specifications/web-engine-specifications.html

Set-top Boxes:

• https://wpewebkit.org/
  • gstreamer-backed MSE implementation (often) in a WebKit environment, mainly standards compliant now, a lot of devices will be firmware locked like @gkatsev mentioned, but if you can support a 2018 WPE build you'll hit the majority of the market at this point (imo).
  • metrological partners
• Android Based Set Tops (FireTV etc)
  • generally, you can avoid these, they'll use Exoplayer/Media3 likely.

Another aspect that's interesting at least if you were looking at a device testing farm ala Bitmovin, but 4K TVs in the older model years have stronger chipsets, so getting the FHD (720p, 1080p) TV will get you a much more representative case for that model year.

Great callout. Playback Engines like dash.js and hls.js have done a(n understandably) much better job at keeping up with newer spec features. Figuring out an architecture that makes these updates easier and isolatable, and ideally shareable across multiple OSS projects would be ideal imo. The Common Media Library initiative/project (cc @littlespex) and similar approaches are definitely on our minds/radar for trying to make these things better and more maintainable across the community as a whole, but also for the future of things like VJS.

👍 Makes sense, and I thought the work done at Qualabs Summer Camp on this front was super cool.

How should we be thinking about this in the player architecture specifically? From the little I know I assume we'll need a dedicated "engine" for it, at the same level of HLS.js. Should we be thinking about swappable networking components or anything else?

hah I was thinking of you + MoQ @englishm. It's at least on my mind, but would love to do some mind melding here. @heff's thoughts/comment ☝️ are roughly mine as well in the broad strokes.

I think having first class support for swappable playback engines would go a long way to help address many of the issues being discussed.

I assume we'll need a dedicated "engine" for it, at the same level of HLS.js

Yep, exactly! I'm hoping that moq-js, moq-encoder-player or similar can become something like HLS.js for MoQ. Technically it would be for one (or more) MoQ "streaming format" like "WARP" since the MoQT layer offers a lot of options for how media is packaged and mapped to MoQ Objects, Groups, and SubGroups.

Should we be thinking about swappable networking components or anything else?

It's at least on my mind, but would love to do some mind melding here.

In my mind, the most fruitful brainstorming would likely be around the new affordances MoQ can offer—features like configurable latency targets and prioritization, or even publishing MoQT tracks from the player to some upstream aggregation point for CMCD-like player metrics/logging or even qlog logs for low level diagnostics.

I think could be useful to map out just how developers might want to configure a player to take advantage of these capabilities and then feed that vision back into the specifications now that everything is starting to become more concrete. I think approaching this from the perspective of player UX could especially benefit WARP as it may have subtle implications for what's put in the catalog and how that information is used by players/subscribers.

Secondly, it'd be good to know what type of interface an HLS.js analog for MoQ would ideally provide, taking into account the ways in which it might be different to accommodate exposing these additional capabilities.

yeah, video.js techs are probably the first instance of this on the web :)
I hope we can maintain it is some form in the new version of Video.js

Given the folks involved (myself included), having a playback engine abstraction is highly likely for any "final form" of VJS 10+. The "tech" architecture may be a bit too presumptuous in some of its moving pieces/"connective tissue" to the rest of VJS, but the core principle of abstraction is at the very least in the right ballpark.