Currently ogv.js is delivered to all video.js users. We probably want to load all that emscripten code conditionally however.
The emscripten-compiled code is all in dynamically-loaded modules since some versions back -- the codecs themselves are loaded in background Workers, the demuxer gets loaded into main context on demand. The core ogv.js file includes only the player logic and its direct dependencies (file streaming, audio output, yuv->rgb conversion).
But that's still a fair chunk of code there's no reason to load much of the time, so bonus points if we can load it conditionally as well.
Could do that through the MediaWiki+RL side by pulling up the pre-built videojs-ogvjs plugin (which bundles ogv.js inside via browserify IIRC) only after checking for relevant support, though that probably complicates initializing stuff.
Alternately the videojs-ogvjs plugin could load ogv.js as a static asset dynamically itself, as the current plugin for the mwembed stuff does.
(Double-checked and the videojs-ogvjs plugin is not bundling ogv.js itself, requires it to be preloaded. Misremembered. :D)
It looks like you can initialize a videojs plugin after a videojs instance has loaded, but I don't know if that'll work as expected with a tech plugin like this...
Best option might be something like this:
- make a tmh-videojs-shim RL module, loaded as early as possible, that includes ogv-support.js and a list of enabled transcode derivative types. It'll check for native support (at least one video, and at least one audio format should be supported as 'probably' or 'maybe'!) and for ogv.js infrastructure support.
- Have that module fire off RL for either just videojs, or videojs/ogvjs/videojs-ogvjs as a bundle.
- Once both that load is complete and DOMReady has been reached, fire off instantiation of videojs players on top of the raw native ones.
On a large page, this might even give opportunity to background-load videojs and/or ogvjs while the page is still loading/parsing/rendering. :)