VideoJS v10 - Big changes coming; input requested

[heff]

Hello VideoJS community! 👋

I’m here with an update on VideoJS v10, which will be a major revamp of the project. As we plan and build, the steering committee would love to hear any input on how you’d like to see the project improve or just change moving forward.

May 17, 2025 will be 15 years since I pushed the first version to Github, and wow have we achieved a lot:

• Millions of websites over time have used VideoJS (source Builtwith)
• Billions of end-users every month of just the CDN-hosted copy (source Fastly stats)
• 38,700 Github stars
• 928 amazing contributors to VideoJS itself
• And 573 plugins

It’s been the greatest privilege to be associated with this project and community, both of which have grown much bigger than I ever expected.

Fifteen years is a long time in Javascript land. In 2010 jQuery was just becoming the most popular library, ES5 had limited support, and Internet Explorer 8 was the most used browser. I started VideoJS to help bridge from Flash video to HTML5 video. It was actually first a tutorial on my personal blog, explaining how to build video player controls with HTML/CSS/JS, which I then rolled into a library after some people showed interest.

We’ve of course evolved VideoJS over time (remember that Closure Compiler phase?), but the tools web developers use today are much different from when the project was started. React, Typescript, and Tailwind are the most common defaults compared to the semantic HTML/CSS and vanilla JS of 2010. We think that warrants taking a big step back and considering how the project is and is not still serving the needs of modern JS, and making changes in v10 that will help VideoJS live on another 15 years. Some topics already on our minds include:

• First-class support for React and other component frameworks
• First-class TypeScript Experience
• Flexible and easily customizable UI components
• Modern styling and themes
• Bundle size, composability, and SSR
• Considerations for AI driven-development
• Playback engine improvements

Drop a note in the comments if you have thoughts on those or other topics for us to consider. 🙏

Media Chrome, too

With VideoJS I wanted people to customize their players in interesting ways, so myself and other contributors spent a lot of time making the CSS and APIs of VideoJS as accessible as we could within the limits of the platform. While I’m proud of that effort I think it had minimal success, with most VideoJS users opting for the default theme. I assume that’s because not many people had the time or interest to learn VideoJS-specific components.

With that in mind, in 2019 I went on a side quest to build Media Chrome using Web Components. I saw the opportunity to make player components that felt like simple HTML and also could be used across many JS frameworks without framework-specific wrappers. While I’ve been a web component evangelist for many years now and still consider myself one, if you’ve kept up with JS news you know they’re not clearly the silver bullet for cross-framework compatibility that I hoped. While Media Chrome continues to grow in popularity itself, this is a good moment to consider the direction ahead for both projects. I’ve always hoped they’d come together, and that’s the current plan, without specific details yet.

Corporate Shepherding

What makes this a good moment is the recent changes in the VideoJS world. Since 2012, Brightcove has been the Corporate Shepherd of VideoJS after acquiring my previous company, Zencoder. They've provided resources and support that helped the project flourish over the years. With recent organizational shifts, the Technical Steering Committee (TSC) has approved Mux (my current company) stepping in as the new Corporate Shepherd going forward.

I’m of course biased, but this feels like a natural fit as we look toward VideoJS's next chapter. I’ll be happy to spend more of my own time on VideoJS, and so will other player devs on the Mux team. Mux is all about video tech for developers, and we're passionate about supporting open source tools that make video development more accessible. The TSC is excited about this new partnership and the momentum it'll bring as we modernize VideoJS for today's dev landscape.

What’s Next

VideoJS is currently at v8 and we're going to reserve v9 for iterative API-breaking changes while we plan and build v10. Here's the roadmap we’re aiming for:

[UPDATED 2025-11-03]

• October 2025 Tech Preview: Community feedback gathering
• February 2026 Beta: Close to stable. Experimental adoption in real projects.
• Mid 2026 GA: Stable APIs. Feature parity w/ Media Chrome, Vidstack, Plyr
• End 2026 Core feature parity: Video.js core/contrib plugins migrated

This timeline gives us enough runway to reimagine VideoJS for modern development while ensuring we don't rush the process. We want to get this right.

Drop comments in this discussion if you have any feedback on where you'd like to see the project go next. 🙏

Cheers!
-heff

[gradyplayer]

I am not a JS developer, but as an outsider, it seems like a bad plan to re-write with the intention of React or any currently popular JS framework as a "first class" supported entity; a good abstraction layer that could be used to write a high quality interface to any framework seems like a better plan - but that is an uninformed comment from someone that doesn't know anything about the problem space...

[gkatsev]

I agree. I think that piece stems from meeting people where they're at. So, if they use react, they should be able to use video.js without any headaches. This, historically, has been an issue for Video.js.
I think that web components is likely a good direction because they're the new building block for the web. Plus, at this point, all these frameworks should have native support for them. Though, it may still warrant specific wrappers to account for various intricacies.
Additionally, a modular codebase that you can pick and choose what you want to include is helpful here as well.

[heff]

Yeah, I think "first-class" is probably too vague of a term and can be interpreted a number of ways. What I meant is that React has always felt like an afterthought in everything from documentation to architecture, and we don't want that to be the case anymore, not just for React but for many popular UI frameworks. I think more recent player projects have done that better, like Vidstack and Player.style.

[mihar-22]

Hey there, I wanted to chime in here too as I'll be unpacking a lot of this with the team in the coming months! I'm mostly speaking for myself here. I'm the author of an open-source player called Vidstack and I'm also currently on the Mux team. We've briefly started to review existing player architectures under our portfolio (quite a few now) as we plan ahead for v10.

I'll second what heff said in that "first-class" is vague here and it doesn't mean we're planning on centering our player architecture solely around React. I'm personally interested in an agnostic-core that would easily plug into Web Components, React, (your favourite framework). Similar to TanStack and some of the work I did in Vidstack (minus some poor decisions). Basically an architecture we can leverage to ship idiomatic primitives and hooks for any framework, not just React.

In my experience, plus what we've seen in the wild with projects like Media Chrome, while Web Components are great in theory and for certain applications, practically speaking they're not ideal for shipping a great universal developer experience. It can feel like another framework target and limited in design. It's quite an in-depth topic and hard to unpack in a comment but happy to answer specifics as we get further along.

In addition, I wouldn't want us to be locked to any single technology, framework, or environment (e.g., DOM). The web has drastically changed over the last decade. I'd like to keep ourselves flexible to how it might further change in the next decade whilst accounting for the past. I think solid abstractions centered around a well-designed core architecture will get us there. Ultimately, staying true to good software design.

This is a heavy topic and I wouldn't expect most to align with me on it immediately, hoping as I share designs and communicate more with community members that it'll become clearer. I'm not against Web Components at all (love certain parts more than others - looking at Custom Elements), I just think they have narrow applications and can't be used as the big hammer to all nails type thing. We can and should definitely still ship them, and we can even build parts of our library with them where we want strong styling encapsulation and a "drop-in" customizable experience (e.g., themes like player.style).

[cjpillsbury]

Yeah @gradyplayer we've been discussing this a lot. What I think we all agree on over at Mux at least is we should not be building a player that presumes React (which folks have been clarifying here). For folks who just need video on a framework-less, vanilla HTML + JS page, they should be able to do that (and for folks using svelte, or vue, or angularjs, etc. etc. they also should be able to use the player). However, we also want to make sure, at least as much as possible, that folks using an application framework can use the player in a way that feels idiomatic to the framework without having to jump through hoops or learn a bunch of stuff that gets in the way of them using, customizing, etc. the player. To do this to its full extent for all app frameworks is a tall ask, so we're heavily leaning towards prioritizing particular frameworks that are popular, hence React as "first class". This doesn't mean we don't/won't care about other app frameworks, but we've found that our web component solution has worked reasonably well for most of those users/use cases.

[itsjamie]

I'd consider determining browser support early in the rewrite, as it will essentially decide who can use VideoJS for what purpose.

Chrome 38 and Chrome 53 are the two big cut-off versions for a lot of the set-top / smart TV market and feature set. Making heavy use of polyfills kills the performance of the applications, so polyfilling up to the base level of support makes supporting the best video features difficult on the platforms.

I understand that it's a small percentage of users who likely care, but for example: video-dev/hls.js#4939

This made it where hls.js could be running alongside a WebGL rendered application at full framerate, to the rAF loop lagging and killing the overall application UX.

---

Essentially, is VideoJS going to target evergreen desktop / mobile users only?

[heff]

I'd love as much guidance as people can give on the specific cutoffs (like @itsjamie has started). I think @littlespex was recommending an even higher Chrome version when we were talking about this IRL yesterday.

Related question, are all new devices shipping today actually supporting the evergreen-ness of the browser they include, or in 10 years are we going to be complaining about Chrome 137 on old devices?

[gkatsev]

Just double checked, the pts/dts changeover was chrome 69 https://developer.chrome.com/blog/media-updates-in-chrome-69/#pts

But yes, TVs tend to not get updated at all. Supposedly, LG's TVs, at least the oled C and G series are supposed to be getting software updated for 3 years, which may include chromium version bumps. But personally, I'm never plugging a personal smart tv into the internet ever again...

So, yes, I expect us to be complaining about older chromium builds in 5 years time, haha. Though, hopefully, the new devices now can be supported by the newer project via transpilation/polyfills.

[cjpillsbury]

"all new devices" is gonna be a tall order, but the heavy hitters like Samsung and LG have gotten better about API compliance, firmware updates, and even aggressive nudges for said updates (even if not always motivated by the things we may want/care about). That said, unless things change, there will likely be a non-trivial number of folks who defer/delay any firmware/software updates until forced (partly understandable, because often enough these updates have negative general performance impacts on older devices). Add to that expectations from businesses, contractual obligations between device manufacturers and streaming providers, and customer expectations/awareness when they say "Top Streaming Service is garbage on (old and unupdated) Major TV Brand!" Sooo... TL;DR - It will plausibly be better but unlikely to ever be a "non-issue", at least in the foreseeable future.

[littlespex]

Chrome 70 has changeType which makes juggling source buffers a little easier.

[itsjamie]

@heff here's a quick set of reference resources

LG Web Engine Support Matrix: https://webostv.developer.lge.com/develop/specifications/web-api-and-web-engine

• covers a few of the Smart TV brands, as they're based on webOS.

Samsung Web Engine Support Matrix: https://developer.samsung.com/smarttv/develop/specifications/web-engine-specifications.html

Set-top Boxes:

• https://wpewebkit.org/
  • gstreamer-backed MSE implementation (often) in a WebKit environment, mainly standards compliant now, a lot of devices will be firmware locked like @gkatsev mentioned, but if you can support a 2018 WPE build you'll hit the majority of the market at this point (imo).
  • metrological partners
• Android Based Set Tops (FireTV etc)
  • generally, you can avoid these, they'll use Exoplayer/Media3 likely.

Another aspect that's interesting at least if you were looking at a device testing farm ala Bitmovin, but 4K TVs in the older model years have stronger chipsets, so getting the FHD (720p, 1080p) TV will get you a much more representative case for that model year.

[damanV5]

Can we add missing DASH features https://github.com/videojs/http-streaming/blob/main/docs/supported-features.md ?

[cjpillsbury]

Great callout. Playback Engines like dash.js and hls.js have done a(n understandably) much better job at keeping up with newer spec features. Figuring out an architecture that makes these updates easier and isolatable, and ideally shareable across multiple OSS projects would be ideal imo. The Common Media Library initiative/project (cc @littlespex) and similar approaches are definitely on our minds/radar for trying to make these things better and more maintainable across the community as a whole, but also for the future of things like VJS.

[englishm]

MoQ

I'd love to see, if not immediate MoQ support, at least some consideration given to having a path for adding MoQ support in the future as that ecosystem begins maturing. There are a lot of unknowns still at the "streaming format" layer, and we'll likely want to support multiple packaging formats, but thinking through the types of affordances developers may want could help us co-evolve implementations. Both moq-js and/or moq-encoder-player could be part of how this comes together.

[heff]

👍 Makes sense, and I thought the work done at Qualabs Summer Camp on this front was super cool.

How should we be thinking about this in the player architecture specifically? From the little I know I assume we'll need a dedicated "engine" for it, at the same level of HLS.js. Should we be thinking about swappable networking components or anything else?

[cjpillsbury]

hah I was thinking of you + MoQ @englishm. It's at least on my mind, but would love to do some mind melding here. @heff's thoughts/comment ☝️ are roughly mine as well in the broad strokes.

[littlespex]

I think having first class support for swappable playback engines would go a long way to help address many of the issues being discussed.

[englishm]

I assume we'll need a dedicated "engine" for it, at the same level of HLS.js

Yep, exactly! I'm hoping that moq-js, moq-encoder-player or similar can become something like HLS.js for MoQ. Technically it would be for one (or more) MoQ "streaming format" like "WARP" since the MoQT layer offers a lot of options for how media is packaged and mapped to MoQ Objects, Groups, and SubGroups.

Should we be thinking about swappable networking components or anything else?

It's at least on my mind, but would love to do some mind melding here.

In my mind, the most fruitful brainstorming would likely be around the new affordances MoQ can offer—features like configurable latency targets and prioritization, or even publishing MoQT tracks from the player to some upstream aggregation point for CMCD-like player metrics/logging or even qlog logs for low level diagnostics.

I think could be useful to map out just how developers might want to configure a player to take advantage of these capabilities and then feed that vision back into the specifications now that everything is starting to become more concrete. I think approaching this from the perspective of player UX could especially benefit WARP as it may have subtle implications for what's put in the catalog and how that information is used by players/subscribers.

Secondly, it'd be good to know what type of interface an HLS.js analog for MoQ would ideally provide, taking into account the ways in which it might be different to accommodate exposing these additional capabilities.

[littlespex]

Having first class support for swappable playback engines could go a long way to help address many of the issues being discussed. Media Chrome's custom media elements and Vidstack's media providers are good examples of this. I know VideoJS has the concept of "techs", but I'm only familiar with them at a high level. Would they be a good candidate for this, or would we need something new?

[gkatsev]

yeah, video.js techs are probably the first instance of this on the web :)
I hope we can maintain it is some form in the new version of Video.js

[cjpillsbury]

Given the folks involved (myself included), having a playback engine abstraction is highly likely for any "final form" of VJS 10+. The "tech" architecture may be a bit too presumptuous in some of its moving pieces/"connective tissue" to the rest of VJS, but the core principle of abstraction is at the very least in the right ballpark.

[tsi]

One issue that keeps coming back when dealing with video-players is the bundle size and download time.
There's only this much we can do to reduce the actual size of the full-featured player, but what we can do is introduce some sort of lazy-loading via dynamic imports, tree-shaking for ESM etc.
For example - if we could load the ABR engine lazily, and only for sources that require it, we could save a lot of bytes.

[m-yakymenko]

I am developing a player for advanced work with subtitles using this library. I chose it because of the audio track support, because I use it with .mkv files. Sometimes it is very difficult to add a new control, for example, I needed to add another select for the 2nd subtitle track. I understand that this is not rocket science, and it is not that difficult, but if I were asked to recommend a player and the user did not need audio tracks, I would recommend anything that has React supports.
I do not find the current documentation sufficient for comfortable development. This is a very important point, since the complexity of the work could be significantly reduced if more usage examples were added. Using frameworks will make development more declarative and reduce the learning curve. Because at this stage I think that it will be easier for a team of excellent JS developers to write wrappers than for any other developer to repeat the same patterns one after another, with rather vague documentation.
So from the main points I would highlight:

1. TypeScript!!
2. Documentation
3. React

[Murmur]

VideoJS+HLS+multiprogram-multiAudioLang.ts
Playback configuration of Program(channel), PID, Lang of the audio track be chosen from the mpts transport stream.

Broadcast streams may contain a channel with 2..N audio tracks (finnish, swedish, visuallyimpaired speech audio tracks). Let player choose a given audio track by PID or Language+Type(normal, visuallyImpaired).

Most flexible implementation would be callbackFuction_selectAudioTracks(tracks[]) { return tracks[$mychoice] } callback to an app.

See hardcoded proof-of-concept(mux.js) modification but this level of track selection would be good to have in VideoJS playback level.

Click to see code

// parsePmt language priorities
      var langsAudio  = [ "fin", "swe", "eng" ]; // priority of normal_audio(hardcoded for now)
      var langsAudioNo= [ "nld" ];               // low-priority. nld=dutch "robot"	   
      var fn_parsePmtSortByLang = function(obj1, obj2) {
        var idx1 = langsAudio.indexOf(obj1.lang);
        var idx2 = langsAudio.indexOf(obj2.lang);
        if(idx1>=0 && idx2>=0) return idx1-idx2;
        else if(idx1>=0)       return -1; // use obj1
        else if(idx2>=0)       return 2;  // use obj2
        // unknown langs: do a lowpriority sorting
        idx1 = langsAudioNo.indexOf(obj1.lang);
        idx2 = langsAudioNo.indexOf(obj2.lang);
        if(idx1==idx2 || (idx1<0 && idx2<0)) return 0;
        return idx1>=0 ? 2 : -1;
      };

      /**
       * Parse out the relevant fields of a Program Map Table (PMT).
       * @param payload {Uint8Array} the PMT-specific portion of an MP2T
       * packet. The first byte in this array should be the table_id
       * field.
       * @param pmt {object} the object that should be decorated with
       * fields parsed from the PMT.
       */	   
      parsePmt = function (payload, pmt) {
        var sectionLength, tableEnd, programInfoLength, offset; // PMTs can be sent ahead of the time when they should actually
        // take effect. We don't believe this should ever be the case
        // for HLS but we'll ignore "forward" PMT declarations if we see
        // them. Future PMT declarations have the current_next_indicator
        // set to zero.

        if (!(payload[5] & 0x01)) {
          return;
        }

        var tracksAudio = [] // array of {lang,type,pid} tracks
		
		// overwrite any existing program map table
        self.programMapTable = {
          video: null,
          audio: null,
          'timed-metadata': {}
        }; // the mapping table ends at the end of the current section

        sectionLength = (payload[1] & 0x0f) << 8 | payload[2];
        tableEnd = 3 + sectionLength - 4;
		
		// to determine where the table is, we have to figure out how
        // long the program info descriptors are
        programInfoLength = (payload[10] & 0x0f) << 8 | payload[11];
		
		// advance the offset to the first entry in the mapping table
        offset = 12 + programInfoLength;
        while (offset < tableEnd) {
          // 27=VIDEO_h264, 15=AUDIO_adtsaac, 6=SUBTITLE_dvb
          var streamType = payload[offset];
          var pid = (payload[offset + 1] & 0x1F) << 8 | payload[offset + 2];
		  
		  // only map a single elementary_pid for audio and video stream types
          // TODO: should this be done for metadata too? for now maintain behavior of
          //       multiple metadata streams
		  
          // parse audio components, later sort tracks and select 1st type=normal track
          var infoLen = ((payload[offset + 3] & 0x0F) << 8 | payload[offset + 4]);
          var descLang="";
          var descType=0xFF; //0x00=normal_audio, 0x03=visual_impaired_audio
          if(payload[offset+5]==0x0A || payload[offset+5]==0x59) { // 0x0A=langDesc, 0x59=subDesc
            var descLen = payload[offset+6];
            if(descLen>=4) {
              descLang= String.fromCharCode(payload[offset+7])
                + String.fromCharCode(payload[offset+8])
                + String.fromCharCode(payload[offset+9]);
              descType=payload[offset+10]
            }
          }
          //console.log(`type=${streamType}, pid=${pid}` +"(0x"+bin.toHexString(pid)+"), infoLen="+infoLen
          //   + ", lang="+descLang + ", type="+ descType);		  

          if (streamType === StreamTypes$2.H264_STREAM_TYPE && self.programMapTable.video === null) {
            self.programMapTable.video = pid;
          } else if (streamType === StreamTypes$2.ADTS_STREAM_TYPE && self.programMapTable.audio === null) {
            tracksAudio.push( { "lang": descLang, "type": descType, "pid": pid } ); //self.programMapTable.audio = pid;
          } else if (streamType === StreamTypes$2.METADATA_STREAM_TYPE) {
            // map pid to stream type for metadata streams
            self.programMapTable['timed-metadata'][pid] = streamType;
          }
		  
		  // move to the next table entry
          // skip past the elementary stream descriptors, if present
          offset += ((payload[offset + 3] & 0x0F) << 8 | payload[offset + 4]) + 5;
        }

		//self.trigger("log",{ // not working, how to use videojs logger?
		//  level  : "debug", // warn,error,debug
		//  message: "AudioTracks len="+tracksAudio.length
		//});
		
        if(tracksAudio.length>0) {
          //console.log("AudioTracks(before sort)", tracksAudio);
          tracksAudio.sort(fn_parsePmtSortByLang);			
          var useAudio=null, firstAudio=null;
          for(var idxL=0; idxL<langsAudio.length && useAudio==null; idxL++) {
            for(var idx=0; idx<tracksAudio.length && useAudio==null; idx++) {
              var track = tracksAudio[idx];
              if(firstAudio==null && track.type==0x00) firstAudio=track; // any first normal_audio
              if(track.lang == langsAudio[idxL] && track.type==0x00) useAudio = track; // preferred normal_audio
            }
          }		  
          if(useAudio==null) useAudio = firstAudio!=null ? firstAudio : tracksAudio[0]; // failsafe to any audio
          //console.log("AudioTracks(after sort)", tracksAudio);
          //console.log("useAudio", useAudio);
          self.programMapTable.audio = useAudio.pid;
        }		

        // record the map on the packet as well
        pmt.programMapTable = self.programMapTable;
      };

[danrossi]

I have had a look at the latest v10 changes. I build custom features for videojs and other players. This is the required current functions that need to be ported over if possible. Im trying to figure it out right now to port plugin features to it.

• javascript json based config setup no markup or react. json configs is how I generate players in my static site so add stuff to it and a basic player template. It's still the easiest way to configure players and most other players do this. I see a way to import a player for a typescript / es6 setup with a features config but for react only ?
• plugin system to override the player features and functions.
• dynamically add control buttons and ui components like the current component system.
  override the player ui component buttons with custom features if needed. Like I can do with the current component system. So the markup style is not good.
• middleware source resolver. I have a plugin that chooses a different source for safari. And another one that does a redirect resolve for load balancing.
• a tech system I use for chromecast playback and shaka player source handler for offline playback so not using hls.js. I have a youtube and vimeo feature that uses the tech system also.
• localization of button tooltips. markup won't provide that. The example markup is english tooltips with no localization ?

There might be others I can't think of right now. plugin system integration would be the first I guess.

Ive built a custom nextjs component for videojs which handles unloading correctly and manage property updates that reconfigures the player, loads custom plugins. I cant see how this is possible with the new system. its typescript markup no seperate react components. Are those react components able to be extended or changed to customise the UI and reskin ? It would have to eventually be ported over but I just built it for someone last year they wont want to change it anytime soon.

[danrossi]

Is there an actual group to provide input because I'm being ignored on discord.

I see you use a markup for HLS to include it in the player. But what about resolving that source ie native HLS for safari or IOS and Dash for others or one HLS for Chrome/Chromecast and another HLS for Safari/Airplay (Chromecast bugs out with sideloaded VTT HLS) , and what about multi format playlists. Its limited to one format and one source. My live offline plugin uses the sources json config with multiple sources, and does round robin source selection fallbacks. Which I use the middleware feature for when recovering from a failure etc

It seems json configuration is scrapped requiring to configure as html attributes instead. That makes it harder for dynamically creating the players like the current player. My static site configures the different players with json. putting dynamic configs in the templating as html makes it even harder. There is no way to add custom configs to the internal hlsjs.

From what I see :there is no auto loading plugin system and has to be setup and inserted as a custom element even if its not a visual plugin and hopefully have full access and control of the player and patch player methods to override things. The docs only show TS and React setup no Es6 setup. Other than the nextjs project I've done customisations for I dont touch TS because it bundles very bloaty with babel just raw es6 bundles for others to include.

The button components all the aria labels are english with no localization system like the current player. So needs a localization system. I've yet to test but it may be possible to extend each button element and re-register the custom element to override the button elements. Like you can do with each component in videojs 8. I have to override some components in some customisations I've done to modify the icons and how the menu functions.

[mihar-22]

@danrossi please read your own text. No one can help if you're asking (saying?) 1000 things and there's not really a clear question in there. Looking for help or providing a lot of feedback under the announcement a year ago isn't ideal either. We're still in very early Beta and the team is working through a lot of features and bugs at the same time.

My recommendation is come to the Discord channel again, and ask or propose one clear thing at a time. I don't know what to make of what you're saying. We'd love to help, but it just needs to be clear.

If you're just providing feedback, then we appreciate it and are taking it all onboard. We just can't immediately react to it or build it.