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

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

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

reply
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.
reply
The user who uses the software running in his browser.
reply
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.

reply
The user can still ad-block. Or choose to let the ad to run to fund the video producer.
reply
Aren't most advertisements served by Linux servers these days? Free software isn't a monastery, as utopian as that ideal sounds.
reply
the OS of an ad platform is totally not important. I fail to see how this is relevant at all.
reply
it just doesn’t work in every environment. every browser version has it’s own issues and edge cases. If you need stable video player or want streaming features you should use it.

P.S i built movie streaming and tv broadcasting player for country of Georgia and supported environments from 2009 LG Smart TVs to modern browsers.

reply
Okay, what about non-streaming vid? I think the vanilla html5 <video> tag is solid, correct?
reply
you think it’s solid until you want customization and old browser support. it should work fine if you just want to autoplay a small size mp4 file on mute
reply
If all you want is a fix non-streaming, video, yes. Video tag just work. Video.js is catered for those required streaming.
reply
Most browsers don't support HLS or DASH.

(And why does that matter? Dynamic bitrate adjustment. The chunks are slightly easier to cache as well.)

reply
> Most browsers don't support HLS or DASH.

Most can via media source extensions.

reply
But that's not native. That's how videojs+HLS.js works, it plugs in the MSE to handle HLS.
reply
Using plain video element plus HLS.js is not complicated or difficult.
reply
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 <video controls>, 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.

reply