v10

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

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

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/