Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

videojs.org

Post reply on HN
Print view View original

151–160 of 170 posts

Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

#151

Post by dylan604 »

bheadmaster wrote: post #121
Heff wrote: post #118

Earlier quoted context omitted.

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.

The user who uses the software running in his browser.

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.

Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

#152

Post by dylan604 »

largbae wrote: post #114
bheadmaster wrote: post #109

Earlier quoted context omitted.

> Advanced features like [...] ads I understand the use-case for this, but I find it working against the spirit of free software, which is bringing control back to the user.

Aren't most advertisements served by Linux servers these days? Free software isn't a monastery, as utopian as that ideal sounds.

the OS of an ad platform is totally not important. I fail to see how this is relevant at all.

Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

#154

Post by rahim_alwer »

hrmtst93837 wrote: post #85
jjcm wrote: post #17

Out of curiousity, why not distribute this as a webcomponent? It's a perfect use case for it - a semantic object that has built in controls / chrome.

[flagged]

This is such an elegant summary of why WCs are painful. I wish I had summarized it so well. I'm on the Video.js team and I wrote about my journey on this front as well [1].

[1]: https://www.mux.com/blog/6-years-building-video-players-9-bi...

Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

#155

Post by cpillsbury »

rezonant wrote: post #136
pjc50 wrote: post #103

Earlier quoted context omitted.

But that's not native. That's how videojs+HLS.js works, it plugs in the MSE to handle HLS.

Using plain video element plus HLS.js is not complicated or difficult.

Hey, core contributor here! If a plain video element plus hls.js is all you need to accomplish your goals, we wouldn't ever try to convince you otherwise. In fact, our "HlsVideo" media renderer is backed by hls.js, and Rob Walch has done Herculean feats maintaining and updating that playback engine. If, however, you don't simply want what's provided from the built in , or don't want to worry about all of the hairy edge cases or minutia of feature-rich UIs, VJS can help. If you want it to be dirt simple to switch between, say, a simple MP4, MPEG-DASH, or HLS, Video.js's architecture makes that simple. If you want to customize UIs from the ground up but not have to think about/worry about the state modeling of relevant media UI state, you can grab all and only the bits of VJS you want. Also, while still in its early stages, if you don't need the "swiss army knife" of features (and, sadly, code footprint) that is built into hls.js, you can use our "SimpleHlsVideo" media renderer.

We definitely aren't trying to convince anyone to use our free, open source library that doesn't need it. But we do think there are lots of value adds for lots of folks under lots of circumstances that we can and will help, including as simple as not needing to reinvent the wheel a bunch of times.

Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

#156

Post by phist_mcgee »

QuantumGood wrote: post #139
Heff wrote: post #56

Earlier quoted context omitted.

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 b…

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 the…

I love a github repo's readme.md that only uses jargon and contains no intro paragraph on what the thing is or how it is to be used.

Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

#157

Post by cpillsbury »

dylan604 wrote: post #150
Heff wrote: post #147

Earlier quoted context omitted.

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 w…

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…

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).

Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

#158

Post by dylan604 »

cpillsbury wrote: post #157
dylan604 wrote: post #150

Earlier quoted context omitted.

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…

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…

> 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.

Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

#159

Post by cpillsbury »

dylan604 wrote: post #158
cpillsbury wrote: post #157

Earlier quoted context omitted.

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…

> 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 any…

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).

Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller

#160

Post by rezonant »

cpillsbury wrote: post #155
rezonant wrote: post #136

Earlier quoted context omitted.

Using plain video element plus HLS.js is not complicated or difficult.

Hey, core contributor here! If a plain video element plus hls.js is all you need to accomplish your goals, we wouldn't ever try to convince you otherwise. In fact, our "HlsVideo" media renderer is backed by hls.js, and Rob Walch has done Herculean feats maintaining and updating that playback engine. If, however, you don't simply want what's provided from the built in , or don't want to worry about all of the hairy ed…

> We definitely aren't trying to convince anyone to use our free, open source library that doesn't need it.

Could've fooled me...

Post reply on HN