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

111–120 of 170 posts

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

#111
post #108

Has the WebVTT story changed? I once tried to customize the subtitle rendering but it seemed too difficult.

I would also be interested in this. Subtitle presentation is something where browsers are still generally very bad at out of the box, so having good subtitle rendering support built directly into the library would make a lot of sense to me. As someone with a lot of knowledge on this subject, I would be very much willing to help at least draft design documents for something like this, if not more.

Hey there, core contributor here! This came up during our beta effort. We very likely will be having an opt-in, non-native subtitles rendering implementation. I know at least a few team members that really want it, which adds to the likelihood that we'll add it eventually. The short version of why we started with native subtitles - bundle size and legal compliance, with a dash of prioritization and a sprinkle of hope that some looming laws will motivate browser owners to prioritize improvements. If you want to see our design decision artifact on the topic, we try to make a lot of them public (also to help the robots these days) - https://github.com/videojs/v10/blob/main/internal/decisions/...

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

#112
post #70

Earlier quoted context omitted.

Any idea what the website's built with? I really like the design/UI tbh

As the sibling comment mentions, it's Astro: https://github.com/videojs/v10/tree/main/site

Looks cool, reminds of a VHS box. Also nails the look of 70s decor that was everywhere when I was growing up in the 80s/90s.

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

#113

In case anyone's wondering, this website's syntax highlighting color scheme is called "gruvbox", which I quite like but took an embarrassingly long time to track down https://github.com/morhetz/gruvbox

this the theme I use on my i3 setup - it has some nice vibe from when terminal would be weirdly orange

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

#114
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…

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

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

#115

[flagged]

Hey there, core contributor here! Starting with the last one first, since that's the easiest - VJSv10 is basically a completely new player, so no backwards compatibility planned (think Mac For the primary question - this is a tough one, specifically because v10 is a completely new, ground up architecture. Part of this will be feature parity - v8 does many things/handles many cases that v10 doesn't do yet. That may seem like that is an unfair comparison, and, in some sense, that's true. However, this is in fact part of the ethos of our new architecture: by building a highly composable, loosely coupled player framework with well defined architectural "seams"/contracts, you can more easily pull in "all and only what you need for your use case" (a phrase I've been bandying about). While v8 allows for some of this, it's still much harder and you still end up pulling in stuff you probably don't need for a lot of use cases.

Another one is the UI layer - v8 ended up building an entire component implementation. At the time of building, it kind of had to. v10, on the other hand, can "stand on the shoulders of giants", building on top of e.g. custom elements, or React, or any future frameworks we decide to target (and our architecture makes that comparatively easy as well).

I do suspect that once we hit true feature parity, the numbers will be much closer for "the kitchen sink." The thing is, few people (if any) need the kitchen sink.

Thanks for the tough question!

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

#116

I am curious, why would anyone pick HLS over Dash in these days? Granted, my knowledge on the matter is rather limited, but I had some long running streams (weeks) and with HLS the playlist became quite large while with dash, the mpd was as small as it gets.

Core VJS contributor here and builder of players and playback engines for too long (aka before HLS and MPEG-DASH were a thing). As others mentioned, the support matrix for HLS is very typically the proximate, pragmatic reason why folks will reach for HLS over DASH in a "pick one" situation. You're right that HLS is particularly bad for 24/7, long lived DVR/"EVENT" (to use HLS jargon) streams (fine for live, and there are some "cheats" you can do for EVENT to help there) compared to MPEG-DASH's -based "dynamic" MPEG usage.

Outside of that, though, the standards themselves have different pain points and tradeoffs. Some things are "cleaner"/"less presumptuous" in DASH, but DASH also has a lot of design details that were both "design by committee" (aka different competing interests resulting in a spec that has arguably too many ways to do the same thing) and overrepresented by server-side folks (so many playback complexities/concerns/considerations weren't thought through). It is also sometimes not constrained enough, at least by default (things like not guaranteeing time alignment across media representations). For what it's worth, I think there are lots of pain points from the HLS design decisions as well, but focusing on DASH here just given the framing of your question.

On the flip side, if you stay within certain bounds, the difference between HLS and DASH simply become text files: one XML manifest (MPD) for DASH and a few playlists (M3U8s) for HLS. There's a lot of effort being made to this end, including: https://cdn.cta.tech/cta/media/media/resources/standards/cta... and the CMAF-HAM-inspired model (https://github.com/streaming-video-technology-alliance/commo... from CML and https://github.com/videojs/v10/blob/main/packages/spf/src/co... in our own playback engine library), just to name a few.

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

#118
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…

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

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.

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

#119
post #81
post #46

I've never used video.js, and the site/advertising seems to be fairly oriented towards people who have used it or are familiar with it. I had one question I couldn't answer reading the site: what makes this different from the native html video element? AFAICT just the transport controls?

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

[dead]
Post reply on HN