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.
There have been other video players that attempt to be more "professional" adding things like audio meters and other tools. These are using parts of JS that is not available anywhere except in Chrome. After digging in, there's a lot of audio related things that Chrome is trying to do that FF/Safari are not. We have mp4 files with multiple audio streams that Chrome exposes ability to select from while FF/Safari do not. Creating waveforms on the fly from a video source also becomes problematic.
We've also had issues getting frame accuracy when navigating the video stream. There's some sort of "security" that randomizes/rounds the returned value of currentTime that I cannot wrap my head around as how that is security related. Lots of effort spent on getting stock HTML5 video element to be frame accurate.
Core contributor here! FYI these kinds of cases are definitely on my mind. One of the nice things about our overarching architecture is we (or someone else, even you!) can add/extend for these kinds in a way that doesn't deeply "bake them in" to core use cases but still makes it completely possible to add. From "soup to nuts" (to extend my food metaphors), we've built VJS in a "highly composable" manner, which means we can, say, add state features, add UI for those state features, extend media renderers to expose those features to the state (if/when needed), etc. etc. If you want to start a discussion picking a concrete Chrome-only API, I'd encourage it (https://github.com/videojs/v10/discussions).
I don't know if/when we'll prioritize these things as part of the "core library", given our higher priorities of "feature parity" and core functionality, but we're already well situated for these kinds of cases (I'm sure we'll encounter and need to figure out some wrinkles along the way, but I'm confident these will generally be tractable).
> If you want to start a discussion picking a concrete Chrome-only API, I'd encourage it
Sorry, but I don't want to do anything Chrome-only at all. You must have misunderstood my point, as I want cross browser performance. Limiting functionality to one browser is not the point. The main question was if there were things on the road map that were going to be added that would limit use on all browsers. I don't want anything I'm involved with to lock a user into one browser over another. This is no longer 1999 best viewed in Netscape at 800x600 type of nonsense. Otherwise, I have to keep extending on my own. At that point, there's not point in me looking for a 3rd party solve.
Oh I definitely misunderstood! VJS is designed to have a "why not both?" approach for all of these things. Though, to your point, we will never build a core player or set of core functionalities that are not intended to work with all "standard" modern browsers. There are a few maybe obvious asterisks there (e.g. AirPlay for Safari, Chromecast for Chrome, etc.), but that's our general approach. That said, we don't want to preclude folks from being able to take advantage of fancy, browser-specific features if they so choose (and we may have "official" support for some of these).
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.
It will be interesting to see how you handle acces to youtube player settings and cc. This is where other player wrappers fall down.
Plyr did a good job of removing the branding via some clever css, but its annoying you cannot access settings and cc. One idea for a cc button is to always have cc on and then toggle the height styling to show/hide it
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).
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.
Part of what makes AI useful to me is getting though the layers of "what the hell is this, exactly" that slow you down when you jump more than one level beyond your domain knowledge. I think every knowledge container (document, website, what have you) should have a "what the hell is this" link /rich tooltip /accordion section /whatever by default.
Of course, AI explanations often also fail at this unless you give them "ELI5" or other relevant prompting (I'm looking at you Perplexity).
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.
In this case, you're talking about the browser user, and not the dev user of video.js, but I feel like you know this and are just trying to rail against ads in a manner that's just not relevant.
If someone providing video content wants to run ads as part of making the video available to you, that's up to them. It's also up to you if you want to attempt to view the video without those ads or skip watching altogether. But to the dev of video.js, you're personal choices of consuming AVOD content are irrelevant.
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.
- On Mac with Increase Contrast turned on in accessibility settings the control bar ends up being white-on-light-grey
- When focusing the volume control with a keyboard, you can only mute or un-mute, not use up or down to adjust the volume. To do that you have to tab again into the volume slider field
- Don’t seem to be able to enter picture-in-picture mode with the keyboard
- Purely from a first class citizen point of view, it’d be nice to have all the accessibility options (transcripts, etc) shown in the homepage demo
https://github.com/videojs/v10/discussions
reply