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.
Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller
111–120 of 170 posts
Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller
#112Earlier 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
Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller
#113In 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
Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller
#114Earlier 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.
Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller
#115[flagged]
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
#116I 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.
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
#117Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller
#118Earlier 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.
Re: Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller
#119I'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.)