Currently ogv.js is delivered to all video.js users. We probably want to load all that emscripten code conditionally however.
|mediawiki/extensions/TimedMediaHandler : master||Made the dependency on videojs-ogvjs conditional|
|Open||None||T49145 Formally deprecate jQuery UI after we've stopped using jQuery UI in extensions and core (replacing it with OOUI).|
|Open||None||T100270 Replace use of jQuery UI and MW UI with OOUI across all Wikimedia-deployed extensions and core|
|Open||None||T89496 Replace TimedMediaHandler's use of deprecated jQuery UI with OOUI|
|Open||None||T158181 Aim for workflow equivalence for MediaWiki on desktop and mobile web|
|Open||brion||T62565 TMH totally broken on mobile|
|Resolved||TheDJ||T93544 Consider alternatives for EmbedPlayer|
|Open||None||T96504 Video subtitles delay|
|Open||None||T121099 Playing a video on iOS when using desktop site does not allow pausing the video or see the control bar|
|Open||None||T217085 Enable TimedMediaHandler video player in articles on mobile (instead of hyperlink to unplayable video)|
|Open||None||T203413 a small audio ogg file does not get played in full|
|Open||brion||T100106 Replace Kaltura player with Video.js|
|Resolved||TheDJ||T133228 Make video.js's loading of ogv.js conditional|
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. :)