_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
(HTM) Visit Hacker News on the Web
COMMENT PAGE FOR:
(HTM) Show HN: I took back Video.js after 16 years and we rewrote it to be 88% smaller
derodero24 wrote 6 hours 15 min ago:
The composable/tree-shakeable direction is the right call. I've been on
the consuming end of this â when you only need basic playback,
pulling in 300kb of DRM, analytics, and ABR code is painful.
The loose-coupling architecture is harder to get right though. Did you
consider lazy-loading the heavier subsystems (DRM, ads), or is the
assumption that if you need those you're already bundling anyway?
mc007 wrote 21 hours 38 min ago:
Why does the bundle size matters when playing 3MB+ videos anyway?
Curious how I could integrate one of these players without polluting my
bundle with duplicates :)
jacobgkau wrote 23 hours 10 min ago:
As someone who uses VideoJS on a website with a large video library,
and has generally been dismayed at the state of the plugin ecosystem
every time I consider doing a major version upgrade of VideoJS, this
kind of thing is great to hear.
Heff wrote 21 hours 49 min ago:
Drop a note in the discussions some time. I'd love to hear about what
you're doing and even help migrate when the time is right for you.
(HTM) [1]: https://github.com/videojs/v10/discussions
01jonny01 wrote 23 hours 15 min ago:
It would be good if videoJS had youtube embed api and documentation
like Plyr has
Heff wrote 21 hours 59 min ago:
In the works! You should be able to use the existing [1] with the
HTML side of v10 today, but we're working on porting over the other
media elements into the new architecture for better React support.
[1]
(HTM) [1]: https://www.npmjs.com/package/youtube-video-element
(HTM) [2]: https://github.com/muxinc/media-elements
moi2388 wrote 1 day ago:
Cool. The video tag with ads. Thats what we need /s
dylan604 wrote 1 day ago:
I see you promoting that the looks are consistent across browsers. I've
seen several other video players that are browser dependent because of
particular JS features used. Are future features going to remain
browser agnostic?
Heff wrote 21 hours 51 min ago:
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 without the assumption
of there even being a browser involved so we can point to future
JS-based platforms like React Native.
dylan604 wrote 21 hours 37 min 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.
cpillsbury wrote 19 hours 47 min 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 ( [1] ).
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).
(HTM) [1]: https://github.com/videojs/v10/discussions
dylan604 wrote 19 hours 32 min 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.
cpillsbury wrote 19 hours 24 min 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).
ronak_parmar wrote 1 day ago:
Great Work, Loved the approach.
Heff wrote 1 day ago:
Thank you!
tuukkah wrote 1 day ago:
Has the WebVTT story changed? I once tried to customize the subtitle
rendering but it seemed too difficult.
Daiz wrote 1 day ago:
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.
cpillsbury wrote 1 day ago:
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) -
(HTM) [1]: https://github.com/videojs/v10/blob/main/internal/decision...
tuukkah wrote 1 day ago:
That's great news. Thank you for sharing the resource!
M4v3R wrote 1 day ago:
Sibling comment didn't elaborate, but I think they might be onto
something.
It happened to me personally - LLMs and agentic coding tools enabled me
to pick up old side projects and actually finish them. Some of these
projects were in the drawer for years, and when Sonnet 4 released I
gave them another try and got up to speed really quickly. I suspect
this happened to many developers.
dang wrote 1 day ago:
(We detached this subthread from [1] so it wouldn't go down with that
ship)
(HTM) [1]: https://news.ycombinator.com/item?id=47514723
Heff wrote 1 day ago:
Something AI has done for Video.js is allow us to set our sights
higher, with the about the same size team. Specifically aiming for
idiomatic components and patterns for each popular JS framework
(React, Svelte, Vue, React Native), not just web component wrappers
(though I still love web components on their own).
c16 wrote 1 day ago:
Absolutely the case for me. Small fun projects that would take a few
hours to round off a feature can now be done in an hour. Why wouldn't
i finish it off?
swaminarayan wrote 1 day ago:
What were the biggest architectural changes in the rewrite, and what
tradeoffs did you make compared to the old Video.js design?
Heff wrote 1 day ago:
The biggest architectural move at multiple layers of the stack was
moving from monolithic controller objects to composable,
tree-shakeable components, functions and state slices. Less
trade-offs and more taking advantage of modern JS bundlers.
EdgeNRoots wrote 1 day ago:
88% reduction is wild. Did most of that come from eliminating
dependencies or rewriting core components from scratch?
Heff wrote 1 day ago:
Full rewrite and an intentional architecture to allow for
composability and tree shaking, meaning the player bundle only ever
includes the features you're using.
k4rli wrote 1 day ago:
Opening the article and reading beyond the title would answer that
question.
progx wrote 1 day ago:
Awesome! And thank you all for your projects and your hard work!
I hope the plugin directory get an overhaul too and a prominent place
an the webpage. The plugin ecosystem was for me a huge benefit for
Video.js
Even though some of them are outdated, they were a good source of
inspiration.
Heff wrote 1 day ago:
Absolutely! The community has always been the strongest part of the
project.
In the new version the core player itself is built as many composable
components rather than one monolithic player, so we're going to
invite more people to contribute their "plugins" to the core repo as
more of those composable components. Versioning plugins and keeping
them up to date has always been a challenge, so we're thinking this
will help keep the whole ecosystem working well together.
BatteryMountain wrote 1 day ago:
I'm not familiar with video hosting but have played with html5 video
player but I have this question: on the servers side, do I have to host
a specific endpoint that serves chunks of video? Lets say I take 720p
video @ 800mb and I chunk it into 2mb pieces with ffmpeg. So I have a
folder somewhere (webserver, cdn, blob storage) with the original 4K
video, then generate downscaled versions for 1440p, 1080p, 720p, so I
end up with 4 large files, and then for each of those, I chunk them
into reasonable sizes that aligns with bitrates / key frames. And then
some thumbnail generation. Any advise on what the "best" way would be
to chunk/host video files so that videojs runs the best and smoothest?
I feel that I should build a very lean/fast chunk & thumbnail server,
just one or two endpoints. Or is it best to let the webserver do the
lifting? Or off-the-shelf media servers (like in the self-hosting
community)?
iainmerrick wrote 1 day ago:
It's not quite as simple as that because the chunks should be
self-contained; they need to start with an IDR keyframe, which fully
resets the decoder. That allows the player to seek to the start of
any chunk.
That means when you're encoding the downscaled variants, the encoder
wants to know the size of the file segments so it can insert those
IDR frames. Therefore it's common to do the encoding and segmentation
in a single step (e.g. with ffmpeg's "dash" formatter).
You can have variable-duration or fixed-duration segments. Supposedly
some decoders are happier with fixed-duration segments, but it can be
fiddly to get the ffmpeg settings just right, especially if you want
the audio and video to have exactly the same segment size (here's a
useful little calculator for that: [1] )
For hosting, a typical setup would be to start with a single
high-quality video file, have an encoder/segmenter pipeline that
generates a bunch of video and audio chunks and DASH (.mpd) and/or
HLS (.m3u8) manifests, and put all the chunks and manifests on S3 or
similar. As long as all the internal links are relative they can be
placed anywhere. The video player will start with the top-level
manifest URL and locate everything else it needs from there.
(HTM) [1]: https://anton.lindstrom.io/gop-size-calculator/
panstromek wrote 1 day ago:
If you don't need to switch versions at runtime (ABR), you don't even
need to chunk it manully. Your server has to support range requests
and then the browser does the reasonable thing automatically.
The simplest option is to use some basic object storage service and
it'll usually work well out of the box (I use DO Spaces with built-in
CDN, that's basically it).
pjc50 wrote 1 day ago:
Yes, serving an MP4 file directly into a tag is the simplest
possible thing you can do that works. With one important caveat:
you need to move the "MOOV" metadata to the front of the file.
There are various utilities for doing that.
panstromek wrote 1 day ago:
Yea, passing `-movflags +faststart` to ffmpeg when processing the
file should be enough.
pjc50 wrote 1 day ago:
Just convert it to HLS, which is naturally chunked at 1-2 second
intervals, and serve all the pieces from nginix. No dynamic content
needed. I do this with videojs and it works great. Added bonus of HLS
is that my LG TV supports it natively from tags.
Xenoamorphous wrote 1 day ago:
Maybe look at MPE-DASH?
BatteryMountain wrote 1 day ago:
Just want to say, thanks for the comprehensive blog post and not
treating the reader like children. You did a great job explaining the
differences & changes. I wish more product/project releases were done
this well.
rezmason wrote 1 day ago:
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
(HTM) [1]: https://github.com/morhetz/gruvbox
cyanf wrote 23 hours 49 min ago:
A seldom appreciated benefit of gruvbox: like vim binds, it's
available everywhere.
If it has a theming system, somebody ported gruvbox to it.
hmokiguess wrote 1 day ago:
I have been seeing this theme trending a lot lately, itâs so good
Recently I am using a variation that looks like gruvbox a bit but has
some tweaks to it
(HTM) [1]: https://marketplace.visualstudio.com/items?itemName=hrose.am...
junon wrote 1 day ago:
Gruvbox is oooollld, at least from my recollection. Been around at
least since I started using vim maybe 15 years ago.
yashasolutions wrote 1 day ago:
this the theme I use on my i3 setup - it has some nice vibe from when
terminal would be weirdly orange
deepriverfish wrote 1 day ago:
it's also available in vscode
jxmesth wrote 1 day ago:
Any idea what the website's built with? I really like the design/UI
tbh
genezeta wrote 1 day ago:
As the sibling comment mentions, it's Astro:
(HTM) [1]: https://github.com/videojs/v10/tree/main/site
nihiven wrote 1 day ago:
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.
Cthulhu_ wrote 1 day ago:
The HTML generator meta tag (f11 to open dev tools) says it's
Astro:
(HTM) [1]: https://astro.build/
efilife wrote 1 day ago:
Seeking on the main [1] page doesn't work for me on chromium.
Throws Uncaught (in promise) TypeError: AbortSignal.any is not a
function on
volume-slider-data-attrs.BOpj3NK1.js
(HTM) [1]: https://videojs.org/
rahim_alwer wrote 1 day ago:
Hey there, on the Video.js team. What browser and version did you run
into this on?
efilife wrote 1 day ago:
114, Ungoogled Chromium to be specific. Happy to share more info if
you need it
rahim_alwer wrote 1 day ago:
I have that ticketed up for you [1], and I'll look into it
tomorrow. Thank you!
[1]
(HTM) [1]: https://github.com/videojs/v10/issues/1120
rendaw wrote 1 day ago:
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?
armandososa wrote 16 hours 52 min ago:
> what makes this different from the native html video element?
You don't realize how blessed you are to not know the answer to that
question and to never ever have to say "Screw it, I'll just use
video.js".
pjc50 wrote 1 day ago:
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.)
RobotToaster wrote 1 day ago:
> Most browsers don't support HLS or DASH.
Most can via media source extensions.
pjc50 wrote 1 day ago:
But that's not native. That's how videojs+HLS.js works, it plugs
in the MSE to handle HLS.
rezonant wrote 1 day ago:
Using plain video element plus HLS.js is not complicated or
difficult.
cpillsbury wrote 20 hours 9 min ago:
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.
rezonant wrote 19 hours 15 min ago:
> We definitely aren't trying to convince anyone to use our
free, open source library that doesn't need it.
Could've fooled me...
dbbk wrote 18 hours 51 min ago:
Is there a reason you're being an asshole?
rezonant wrote 14 hours 46 min ago:
Being an asshole? For saying "could have fooled me" to
one of the 6 posts on a brand new account heavily
advertising video.js benefits in response to my post
mentioning that the video element is already both
powerful and easy to use, and that adding HLS.js to add
HLS support to it for browsers that don't support it
natively is dead simple?
I guess your threshold for calling someone an asshole
is a bit low.
I don't have a problem with using video.js for the
reasons the parent poster mentioned, but HTML5 video is
insanely easy to implement, and there's no reason to
take on a dependency like this if you don't need
something beyond what the web platform already gives
you.
Heff wrote 1 day ago:
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.
QuantumGood wrote 1 day ago:
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).
phist_mcgee wrote 20 hours 3 min ago:
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.
ramon156 wrote 10 hours 44 min ago:
Or it prints out the whole Stack, LOC, proj structure, like its
in any way useful to me.
bheadmaster wrote 1 day ago:
> 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.
Heff wrote 1 day ago:
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.
bheadmaster wrote 1 day ago:
The user who uses the software running in his browser.
dylan604 wrote 20 hours 43 min ago:
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.
phantomathkg wrote 1 day ago:
The user can still ad-block.
Or choose to let the ad to run to fund the video producer.
largbae wrote 1 day ago:
Aren't most advertisements served by Linux servers these days?
Free software isn't a monastery, as utopian as that ideal sounds.
dylan604 wrote 20 hours 42 min ago:
the OS of an ad platform is totally not important. I fail to
see how this is relevant at all.
nshelia wrote 1 day ago:
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.
truetraveller wrote 1 day ago:
Okay, what about non-streaming vid? I think the vanilla html5 tag
is solid, correct?
phantomathkg wrote 1 day ago:
If all you want is a fix non-streaming, video, yes. Video tag
just work.
Video.js is catered for those required streaming.
nshelia wrote 1 day ago:
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
bl4kers wrote 1 day ago:
Probably not base case but a quick test to replace my audio player
(currently using Plyr) turned up the following gaps for me, at least
with the out-of-the-box code.
1. No playback rates under 1
2. No volume rocker on mobile
3. Would appreciate having seek buttons on mobile too
4. No (easily apparent) way to add an accent color, stuck with boring
monochrome
5. Docs lacked clear example/demo/playground so I wasn't sure what it
would look like until implemented
Heff wrote 1 day ago:
All solid feedback, thanks! I'm making sure these get captured as
issues. Otherwise we're closely tracking feature parity with Plyr
(and other players) and our goal is to have full parity by GA, aiming
for the middle of the year.
robin_reala wrote 1 day ago:
If weâre doing feedback, then:
- On Mac with Increase Contrast turned on in accessibility settings
the control bar ends up being white-on-light-grey
- When focusing the volume control with a keyboard, you can only
mute or un-mute, not use up or down to adjust the volume. To do
that you have to tab again into the volume slider field
- Donât seem to be able to enter picture-in-picture mode with the
keyboard
- Purely from a first class citizen point of view, itâd be nice
to have all the accessibility options (transcripts, etc) shown in
the homepage demo
Heff wrote 22 hours 3 min ago:
This is great. Keep it coming.
naseemali925 wrote 1 day ago:
This is amazing. We also kind of created a Player context provider and
was using it to maintain/mutate player state globally. If its possible
to also share any examples related to player events and new way to
register plugins in V10, that would also help better understand the
overall picture.
rahim_alwer wrote 1 day ago:
Hey there, I'm on the Video.js team! Sounds like your context
provider approach is already in the right ballpark!
Some background: our store[1] which was inspired by Zustand[2] is
created and passed down via context too. This is the central state
management piece of our library and where we imagine most devs will
build on for extending and customizing to their needs.
Updates are handled via simple store actions like `store.play()`,
`store.setVolume(10)`, etc. Those actions are generally called in
response to DOM events.
On the events side of things, rather than registering event listeners
directly, in v10 you'd subscribe to the store instead. Something like
`store.subscribe(callback)`, or in React you'd use our `usePlayer`[3]
hook. The store is the single source of truth, so rather than
listening to the underlying media element directly, you're observing
state changes.
---
So far with v10 we haven't been thinking about "plugins" in the
traditional sense either. If I had to guess at what it would look
like, it'd be three things:
1. Custom store slices[4] so plugins can extend the store with their
own state and actions
2. A middleware layer that plugs into the store's action pipeline so
a plugin could intercept or react to actions before or after they're
applied, similiar to Zustand middleware, or even in some ways like
Video.js v8 middleware[5]
3. UI components that plugins can ship which use our core primitives
for accessing the store, subscribing to state, etc.
I believe that'd cover the vast majority of what plugins needed in
v8. We haven't nailed down the exact API yet but that's the direction
we're leaning towards. We're still actively working on both the
library and our docs so I don't have somewhere I can link to for
these just yet (sadly)! We're likely targeting sooner, but GA (end of
June) is the deadline.
I should also add... one thing we prototyped early on that may
return: tracking end-to-end requests through the store. A DOM event
triggers a store action like play, which calls `video.play()`, which
then waits for the media event response (play, error, etc.). It
worked really well and lines up nicely with the middleware direction.
[1] [2] [3] [4]: [4] [5]:
(HTM) [1]: https://github.com/videojs/v10/tree/main/packages/store
(HTM) [2]: https://github.com/pmndrs/zustand
(HTM) [3]: https://videojs.org/docs/framework/react/reference/use-playe...
(HTM) [4]: https://zustand.docs.pmnd.rs/learn/guides/slices-pattern#sli...
(HTM) [5]: https://legacy.videojs.org/guides/middleware/
esprehn wrote 1 day ago:
This is very cool, but I'm confused why the React player is smaller
than the HTML player. What's actually in the size comparison there?
rahim_alwer wrote 1 day ago:
Itâs largely because (1) the React runtime is not bundled so itâs
technically not apples to apples, (2) the Web Component includes CSS
as well since weâre using Shadow DOM.
Basically few kB for CSS and few kB for a thin âframeworkâ layer
for managing attr to prop mapping, simple lifecycle, context, and so
on.
gnulinux996 wrote 1 day ago:
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.
cpillsbury wrote 1 day ago:
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: [1] and the CMAF-HAM-inspired
model ( [2] from CML and [3] in our own playback engine library),
just to name a few.
(HTM) [1]: https://cdn.cta.tech/cta/media/media/resources/standards/cta...
(HTM) [2]: https://github.com/streaming-video-technology-alliance/commo...
(HTM) [3]: https://github.com/videojs/v10/blob/main/packages/spf/src/co...
KingMob wrote 1 day ago:
It's still mandatory for all but the newest iOS devices, which don't
support MediaSourceExtensions.
Heff wrote 1 day ago:
This is true, and the whole iOS/iPadOS/tvOS ecosystem supports HLS
natively making it much easier to work with on that platform. In
addition, Chrome recently added support for HLS[1] (and not DASH),
so the native browser support for HLS is getting pretty wide.
HLS also has newer features that address the growing manifest
issues you were seeing. [2] All that said, I think a lot of people
would feel more comfortable if the industry's adaptive streaming
standard wasn't completely controlled by Apple. [1]
(HTM) [1]: https://caniuse.com/http-live-streaming
(HTM) [2]: https://www.mux.com/blog/low-latency-hls-part-2
Retr0id wrote 1 day ago:
How do you actually use HLS in the form of a native browser
feature? Can you just put the m3u8 in the video src?
pjc50 wrote 1 day ago:
Yes, doing that works perfectly. If you use videojs it will
automatically use native support if present.
taosx wrote 1 day ago:
Are there any plans to support other frontend frameworks? If I wanted
to use it today in something like svelte how should I go about it?
rahim_alwer wrote 1 day ago:
We are designing with the goal of supporting more frameworks like
Svelte and Vue specifically, even as far as React Native! We just
donât know when exactly yet but a large part of our approach in v10
is to make sure we can deliver the best possible experience to each
frontend framework. Itâs important for us that the integrations
donât feel like wrappers but truly idiomatic.
In the meantime, weâre hoping our custom elements will act as a
good stopgap. Most frameworks including Svelte support them well, and
weâre pouring love into the APIs so they feel good to use
regardless of which framework.
If youâre interested in peeking under the hood, architecturally
weâre taking a similar approach to TanStack and separating out a
shared core from the beginning, but with one added step of splitting
out the DOM as well to aid in supporting RN one day.
EGreg wrote 1 day ago:
Serious question. We currently have this tool in our framework, that we
use to play videos from youtube, vimeo, and a whole lot of other sites:
[1] We currently already use video.js, and our framework us used all
over the place, so weâd be the perfect use case for you guys.
How would we use video.js 10 instead, and for what? We would like to
load a small video player, for videos, but which ones? Only mp4 files
or can we somehow stream chunks via HTTP without setting up ridiculous
streaming servers like Wowsa or Red5 in 2026?
(HTM) [1]: https://github.com/Qbix/Platform/blob/main/platform/plugins/Q/...
Heff wrote 1 day ago:
That's great! It looks like you have a pretty extensive integration
with the prior version of Video.js, so migrating will take some work,
but I think worth it when you can make the time. That said, for Beta
it works with browser-supported formats and HLS, with support for
services like Youtube and Vimeo close behind as we migrate what we
haver in the Media Chrome ecosystem[1]. So if that's what you need
maybe hold your breath for a few weeks.
What are you supporting today that requires Wowza or Red5? The short
answer is Video.js is only the front-end so it won't help the server
side of live streaming much. I'm of course happy to recommend
services that make that part easier though.
(HTM) [1]: https://github.com/muxinc/media-elements
EGreg wrote 1 day ago:
Thank you for your feedback. Yep I definitely understand that
Video.js is just the front end. I want to avoid using Wowza / Red5
and just want to serve chunks of video files, essentially,
buffering them and pasting them to the "end of the stream" laying
down tracks ahead of the video.js train riding over those tracks.
So I'm just wondering whether we can do streaming that way, and
video.js can "just work" to play the video as we fetch chunks ahead
of it ("buffering" without streaming servers, just basic HTTP range
requests or similar).
colonCapitalDee wrote 1 day ago:
You should check out HLS and DASH. If you're already familiar and
you're not using them because they don't meet your requirements,
then apologies for the foolish recommendation. If not, this could
solve your problem.
Heff wrote 1 day ago:
I second that it sounds like HLS/DASH (Adaptive live streaming
over HTTP) is what you're looking for, instead of RTP/RTMP.
WebRTC being a more open model for real-time streaming, but
nowhere near as easy or scalable HTTP-based streaming today.
However we can all also start getting excited about MoQ [1][2].
[1]
(HTM) [1]: https://moq.dev/
(HTM) [2]: https://www.youtube.com/watch?v=BluV8WBGnHY
nchmy wrote 1 day ago:
I was just lamenting the other day about the size of video.js, which is
used in my legacy web app, and looking for a way to improve that. Very
keen to explore how we could migrate to v10!
Heff wrote 1 day ago:
Drop a note in discussions or issues! Would love to hear what
youâre working with.
(HTM) [1]: https://github.com/videojs/v10/discussions
gorbiesRedScar wrote 1 day ago:
this is lovely work
rahim_alwer wrote 1 day ago:
Thank you!
zacharyozer wrote 1 day ago:
Congrats Steve! I haven't touched video since I was at JW Player a
million years ago, but I always inspired by the simplicity of video.js
(especially the theming).
Hope this new iteration is exceptionally successful.
Heff wrote 1 day ago:
Oh hi Zach! Blast from the past. Hope youâre doing well and thanks
for the well wishes. Always enjoyed chatting you and the JW team at
FOMS and conferences. The waterâs warm back here in video tech if
you ever want to jump back in!
theMMaI wrote 1 day ago:
So fun seeing all these familiar names pop up in a single thread,
haven't been active in video after leaving Kaltura but have fond
memories of FOMS/FOSDEM and meeting all of you!
jjcm wrote 1 day ago:
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.
hrmtst93837 wrote 1 day ago:
Web components sound neat until you try to make styling and SSR
behave across a mess of app setups, and then you're burning time on
shadow DOM quirks, hydration bugs, and framework glue instead of the
player itself. Most users do not care. A plain JS lib with a decent
API is easier to drop into an old stack, easier to debug, and less
likely to turn us into free support for someone's anicent admin
panel.
rahim_alwer wrote 20 hours 20 min ago:
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]:
(HTM) [1]: https://www.mux.com/blog/6-years-building-video-players-9-...
mmcclure wrote 1 day ago:
Ah...you're scratching at some scabs with this totally reasonable
question.
We learned some tough lessons with media-chrome[1] and Mux Player,
where we tried to just write web components. The React side of things
was a bit of a thorn, so we created React shims that provided a more
idiomatic React experience and rendered the web components...which
was mostly fine, but created a new set of issues. The reason we chose
web components was to not have to write framework-specific code, and
then we found ourselves doing both anyway.
With VJS 10 I think we've landed on a pretty reasonable middle
ground. The core library is "headless," and then the rendering layer
sits on top of it. Benefit is true React components and nice web
components.
(HTM) [1]: https://github.com/muxinc/media-chrome
derefr wrote 1 day ago:
Is it not a web component, per se? Per the article, all the React
stuff does seem to bake down to HTML Custom Elements, that get wired
up by some client-side JS registering for them. That client-side JS
is still a "web component", even if it's embedded inside React SPA
code bundle, no?
If you mean "why do I need React / any kind of bundling; why can't I
just include the minified video.js library as a script tag / ES6
module import?" â I'm guessing you can, but nobody should really
want to, since half the point here is that the player JS that
registers to back the custom elements, is now way smaller, because
it's getting tree-shaken down to just the JS required to back the
particular combination of custom elements that you happen to use on
your site. And doing that requires that, at "compile time", the
tree-shaking logic can understand the references from your views into
the components of the player library. That's currently possible when
your view is React components, but not yet possible (AFAIK) when your
view is ordinary HTML containing HTML Custom Elements.
I guess you could say, if you want to think of it this way, that your
buildscript / asset pipeline here ends up acting as a web-component
factory to generate the final custom-tailored web-component for your
website?
pjc50 wrote 1 day ago:
You certainly can just add it to a tag and then not do any of
that.
rcakebread wrote 1 day ago:
I just happened to try v10 yesterday for HLS and it's looking great so
far.
rahim_alwer wrote 1 day ago:
Awesome to hear!
grzes wrote 1 day ago:
can anyone recommend me good, battle-tested "slider" solution for
playing videos as well as displaying images from single gallery?
ideally capable of handling huge galleries (hundreds of items) with
lazy loading
Heff wrote 1 day ago:
Not a today answer, but this is something I'm excited to build within
the new Presets concept of video.js v10, where we can build specific
"video interfaces" beyond a standard player using the composable
architecture.
(HTM) [1]: https://videojs.org/docs/framework/react/concepts/presets
bananadonkey wrote 1 day ago:
I've used [1] in anger and it's great, very extensible too.
(HTM) [1]: https://yet-another-react-lightbox.com/
spankalee wrote 1 day ago:
That only works in React though.
michaelsalim wrote 1 day ago:
Looking great. I'll give it a try later on once things stabilize a bit.
In the meantime, does anyone know what's going on in this space? Seems
to me like a lot is changing over the past year. Eg: react-player new
version, taken over by Mux. And also I did realize Video.js is
sponsored by Mux. And also seemingly different companies working
together.
Heff wrote 1 day ago:
OP and Mux co-founder here so have all the context on this. A lot has
changed. Mux stepped in to help maintain React Player a few years
ago. It wasn't getting frequent updates and Mux has a vested interest
in the whole OSS player ecosystem (even if we didn't built it)
because Mux Video (hosting) is player agnostic, and we get support
requests for all of them. @luwes from Mux did the work to get to the
new version, while making it possible to use Media Chrome media
elements with React Player and consolidating some development
efforts. We're still a tiny player team so that was important.
There are no immediate plans to deprecate React Player and I think it
holds a special place in the ecosystem, but there will be overlap
with video.js v10 and if there's specific features you care about or
feel are missing, or if you think we're doing a bad job, please voice
it here.
It was a similar story with Vidstack and Plyr, with Mux first
sponsoring the projects. That's how I met Rahim and Sam, and how we
got talking about a shared vision for the future of players.
thedanbob wrote 1 day ago:
Very nice! I switched off video.js some time ago because it kept giving
me trouble. Looking forward to trying this new version.
rahim_alwer wrote 1 day ago:
Thank you! Iâm on the Video.js team, and weâd love for you to try
the library out and share your feedback. Weâre especially eager to
hear from developers who used or tried v8 in the past.
Weâre taking a new approach to the library with a lot of new
concepts, so your feedback would help us a ton during Beta as we
figure out whatâs working well and what isnât.
sam_goody wrote 1 day ago:
Very nice. Good Luck!
Did the private equity buy the domain videojs.org (did it take control
of the project and you somehow regained control after selling) or was
this domain (and the project) always under your control?
nakodari wrote 1 day ago:
Absolutely love what you and your friends have built. Great work! Will
give it a spin.
rahim_alwer wrote 1 day ago:
I'm on the Video.js team, just wanted to say thank you! Means a lot
and we'd be eager to hear your experience trying it out. Feel free to
drop a GitHub issue or discussion post if you ever get a chance :)
jen729w wrote 1 day ago:
From me, this is a massive relief after we just deployed a bunch of
videos to Vimeo. The next week they were bought.
I'm a one-man operation. In the order of hundreds of videos served
a week. All I want is control over my own destiny. If this and a
VPS can do that, that'll be amazing. Thank you for doing this.
pjc50 wrote 1 day ago:
You absolutely can do that with videojs, it's very easy.
Might need to consider bandwidth and the usual mitigation against
scrapers if you're serving video unauthenticated.
KingMob wrote 1 day ago:
If you need more than a VPS can provide (like a real CDN), you
can check us out on Swarmify.com. It might be overkill for your
use case, though.
We'll be moving to videojs 10 when it hits GA.
(DIR) <- back to front page