Can you give an example of a player/feature combo where this is the case? For general player features there's not really an excuse for only working in one browser, but features like Casting can be browser dependent because the browser has to expose that functionality. Other interesting prototypes rely on a new API called Web Codecs that isn't fully supported everywhere.
In the core JS of Video.js v10 we're building without the assumption of there even being a browser involved so we can point to future JS-based platforms like React Native.
In the works! You should be able to use the existing <youtube-video-element> [1] with the HTML side of v10 today, but we're working on porting over the other media elements into the new architecture for better React support.
Absolutely! The community has always been the strongest part of the project.
In the new version the core player itself is built as many composable components rather than one monolithic player, so we're going to invite more people to contribute their "plugins" to the core repo as more of those composable components. Versioning plugins and keeping them up to date has always been a challenge, so we're thinking this will help keep the whole ecosystem working well together.
The biggest architectural move at multiple layers of the stack was moving from monolithic controller objects to composable, tree-shakeable components, functions and state slices. Less trade-offs and more taking advantage of modern JS bundlers.
Full rewrite and an intentional architecture to allow for composability and tree shaking, meaning the player bundle only ever includes the features you're using.
Something AI has done for Video.js is allow us to set our sights higher, with the about the same size team. Specifically aiming for idiomatic components and patterns for each popular JS framework (React, Svelte, Vue, React Native), not just web component wrappers (though I still love web components on their own).
I’m not sure which user we’re talking about, but it’s up to the video.js user to decide if and when they use ads. Just like it’s up to YouTube. Video can get expensive, so some video wouldn’t exist without some form of monetization.
Fair point, we could answer that more directly on the site. Besides the comparison were there other things that make it seem oriented to people already familiar with it?
Generally, the video tag is great and has come a very long way from when Video.js was first created. If the way you think about video is basically an image with a play button, then the video tag works well. If at some point you need Video.js, it'll become obvious pretty quick. Notable differences include:
* Consistent, stylable controls across browsers (browsers each change their native controls over time)
* Advanced features like analytics, ABR, ads, DRM, 360 video (not all of those are in the new version yet)
* Configurable features (with browsers UIs you mostly get what you get)
* A common API to many streaming formats (mp4/mp3, HLS, DASH) and services (Youtube, Vimeo, Wistia)
Of course many of those things are doable with the video tag itself, because (aside from the iframe players) video.js uses the video tag under the hood. But to add those features you're going to end up building something like video.js.
All solid feedback, thanks! I'm making sure these get captured as issues. Otherwise we're closely tracking feature parity with Plyr (and other players) and our goal is to have full parity by GA, aiming for the middle of the year.
That's great! It looks like you have a pretty extensive integration with the prior version of Video.js, so migrating will take some work, but I think worth it when you can make the time. That said, for Beta it works with browser-supported formats and HLS, with support for services like Youtube and Vimeo close behind as we migrate what we haver in the Media Chrome ecosystem[1]. So if that's what you need maybe hold your breath for a few weeks.
What are you supporting today that requires Wowza or Red5? The short answer is Video.js is only the front-end so it won't help the server side of live streaming much. I'm of course happy to recommend services that make that part easier though.
This is true, and the whole iOS/iPadOS/tvOS ecosystem supports HLS natively making it much easier to work with on that platform. In addition, Chrome recently added support for HLS[1] (and not DASH), so the native browser support for HLS is getting pretty wide.
HLS also has newer features that address the growing manifest issues you were seeing. [2]
All that said, I think a lot of people would feel more comfortable if the industry's adaptive streaming standard wasn't completely controlled by Apple.
Oh hi Zach! Blast from the past. Hope you’re doing well and thanks for the well wishes. Always enjoyed chatting you and the JW team at FOMS and conferences. The water’s warm back here in video tech if you ever want to jump back in!
OP and Mux co-founder here so have all the context on this. A lot has changed. Mux stepped in to help maintain React Player a few years ago. It wasn't getting frequent updates and Mux has a vested interest in the whole OSS player ecosystem (even if we didn't built it) because Mux Video (hosting) is player agnostic, and we get support requests for all of them. @luwes from Mux did the work to get to the new version, while making it possible to use Media Chrome media elements with React Player and consolidating some development efforts. We're still a tiny player team so that was important.
There are no immediate plans to deprecate React Player and I think it holds a special place in the ecosystem, but there will be overlap with video.js v10 and if there's specific features you care about or feel are missing, or if you think we're doing a bad job, please voice it here.
It was a similar story with Vidstack and Plyr, with Mux first sponsoring the projects. That's how I met Rahim and Sam, and how we got talking about a shared vision for the future of players.
Not a today answer, but this is something I'm excited to build within the new Presets concept of video.js v10, where we can build specific "video interfaces" beyond a standard player using the composable architecture.
I've been building for the web since the 90s and it's always felt a little off how slow the uptake on web components has been. Glenn Maddern's X-GIF talk at JSConf EU '13 opened my mind to expanding the browser beyond its locked-in set of HTML tags. I got super excited and started building with web components v1, but React was so dominant they never really got traction. And to be fair they had real problems too (not easy to create without something like Lit, complex async lifecycles, reactive frameworks really don't like other things having state). Around 2020, after almost a decade building Video.js and being tired of trying to make the player work with every single framework, I started building Media Chrome (https://www.media-chrome.org/) as web components. It's been out almost six years and if you look at the npm stats there's been a real spike in just the last year, even the last few months to over 1M weekly downloads. I don't know what's driving that but it's cool to see.
We're putting out Video.js v10 beta in March, rebuilt from the ground up and merged with Media Chrome. We're being really intentional to build an idiomatic React version in addition to WCs, not just wrapped web components, but I'm interested to see if the web component version is actually the more popular flavor.
https://github.com/videojs/v10/discussions