Heff

Drop a note in the discussions some time. I'd love to hear about what you're doing and even help migrate when the time is right for you.

https://github.com/videojs/v10/discussions

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.

[1] https://www.npmjs.com/package/youtube-video-element

[2] https://github.com/muxinc/media-elements

This is great. Keep it coming.

Thank you!

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.

I second that it sounds like HLS/DASH (Adaptive live streaming over HTTP) is what you're looking for, instead of RTP/RTMP.

WebRTC being a more open model for real-time streaming, but nowhere near as easy or scalable HTTP-based streaming today.

However we can all also start getting excited about MoQ [1][2].

[1] https://moq.dev/

[2] https://www.youtube.com/watch?v=BluV8WBGnHY

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.

[1] https://github.com/muxinc/media-elements

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.

[1] https://caniuse.com/http-live-streaming

[2] https://www.mux.com/blog/low-latency-hls-part-2

Drop a note in discussions or issues! Would love to hear what you’re working with.

https://github.com/videojs/v10/discussions

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.

https://videojs.org/docs/framework/react/concepts/presets

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.

Video.js creator here, and I agree with this ^. Frame accurate seeking isn't something the native video element does.

Check out the Omakase player: https://player.byomakase.org/

Had to be said :)

Oh boy, I could write a book in response to this...

a section on their site explaining how they are able to undercut everyone in the business and still keep going

This is great feedback that I'm putting on our todo list. We should absolutely have this.

We'll never put pricing out there that we can't handle with our economics, or at least have a clear path to supporting. All of our volume pricing is available publicly, so you should never be bait-and-switched if you're understanding concepts like credits. This is in contrast to some of our competitors that regularly surprise users with new pricing when they hit scale. I hate that so much.

Under the hood we use just-in-time encoding and other advanced optimizations that do give us an edge. Not to mention economies of scale. Writeup to come.

But a challenge comes in customer perception. Some of our customers understand encoding and it's cost, plus the benefits it brings like adaptive streaming and handling user-generated uploads. Many devs are new to video and expect it to cost the same as uploading an MP4 to S3. Some point to our competitors with no encoding costs, and some even point to Youtube as a reason why it should be cheaper. In the past Mux has been labeled as "the expensive option" because we charged for encoding, so we've been working on new pricing shape (some launched already, some to come) that allows you to come in at levels using less encoding that we can support economically, then elect higher levels of encoding costs/values when you understand if they're worth it to you.

We also think video should be more places than it is today, but video is inherently expensive in comparison to many other costs related to building an app, so we see it as our job to keep pushing costs down and shaping pricing so video is accessible to more use cases.

Thank you! Winamp is getting a lot of love (and controversy) right now so it felt worth calling out. But it's not my favorite of the themes in practice. I think that's Sutro, which kind of surprised us by how nice it turned out.

Fully flexible color choice is a foot gun. I've definitely made some very ugly themes with that too. The goal is to have very many themes here, including user-submitted ones, so it might be hard to create something that can warn about issues across all of them. But seeing as we have pretty clear foreground and background color settings with primary/secondary I bet we could make something helpful.

Anything frame-accurate or smooth scrubbing has always been a challenge with he abstraction level of the video element. I don't have an exact answer from you, but you might look around the web codecs space, where more performant examples are being built at a lower level. https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...

That's a really nice implementation. I feel like it should be easy for that to support videos too, if desired. I assume it's just using a media element under the hood.

Thank you! If you still experience friction when trying to build your own theme, then our job isn't done. So let us know!

Good feedback, thanks! There's a related issue in the media chrome repo here: https://github.com/muxinc/media-chrome/issues/957

The situation is a little complex with "hot keys" for controlling the video in general (after clicking on the video), accessibility controls for each component, and then general accessibility expectations for the whole page. For example, should we capture the up and down arrows to always control volume when the player is in focus, or should we not do that because people expect that for scrolling the page.

All that said, we definitely have some iteration ahead of us on this front so thanks again for the input.

Reelplayer! The first web video player that I (and many others) ever used.