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

61–70 of 170 posts

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

#64

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.

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]: https://github.com/videojs/v10/tree/main/packages/store

[2]: https://github.com/pmndrs/zustand

[3]: https://videojs.org/docs/framework/react/reference/use-playe...

[4]: https://zustand.docs.pmnd.rs/learn/guides/slices-pattern#sli...

[5]: https://legacy.videojs.org/guides/middleware/

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

#65
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)?

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

#67

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…

[dead]

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

#70

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

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