Hacker News new | ask | show | jobs
by dylan604 85 days ago
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.
1 comments
cpillsbury 85 days ago
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).

link
dylan604 85 days ago
> 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.

link
cpillsbury 85 days ago
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).
link