This is mostly just a placeholder for now. Will fill out more later. Feel free to add more info.
**A succinct problem statement to give context for why the review was initiated.**
Most of our audio and video handling is done by the TimedMediaHandler extension, which was developed largely by a single developer (Michael Dale) back in 2011–2012. TimedMediaHandler is starting to show its age and feels rather clunky compared to what most people expect from audio and video players these days. If Wikipedia's multimedia support is going to be taken seriously, we need to invest more resources in maintaining and improving this extension.
**Current developers/maintainers:**
In theory, it is maintained by the Multimedia team. In reality, it's mostly maintained by Brion Vibber, with occasional help from other devs and volunteers, none of which are on the Multimedia team. It's basically orphaned, but not completely neglected. (Brion is doing another push on it in 2018 to remove some of the old issues, but a wider maintainer base would be very welcome.)
**Number, severity, and age of known and confirmed security issues:**
One open security bug from Aug 2017 (normal severity). 3 closed security bugs.
**Was it a cause of production outages or incidents? List them.**
None known, but see monitoring alerts below.
**Does it have sufficient hardware resources for now and the near future (to take into account expected usage growth)?**
Additional video scaler boxes, and perhaps additional swift storage space, may be required in future if we get lots of large video contributions from users. Adding video scalers is relatively easy, but should be planned at some point. Capacity planning for swift storage should consider potential future growth.
**Is it a frequent cause of monitoring alerts that need action, and are they addressed timely and appropriately?**
There have been a few issues in the last year with the transcode queue getting clogged up during batch uploads and batch-reencodes done by community members, which affects other users' ability to use recently uploaded files. Since these run on dedicated job queue runners (video scalers) it doesn't affect other parts of the production system much, but is a concern.
Because they didn't break other stuff, they didn't get as much attention as they might have.
**When it was first deployed to Wikimedia production**
2012
**Usage statistics based on audience(s) served**
**Changes committed in last 1, 3, 6, and 12 months**
**Reliance on outdated platforms (e.g. operating systems)**
Server-side components run on current operating systems (eg Debian stretch). Unmaintained ffmpeg2theora dependency has been removed.
**Number of developers who committed code in the last 1, 3, 6, and 12 months**
**Number and age of open patches**
**Number and age of open bugs**
**Number of known dependencies?**
* MwEmbedPlayer ext -> current player frontend; will be removed once video.js frontend is deployed
* video.js (npm) new player frontend; currently in progress of upgrade from v5 to v6
* ogv.js (npm) used as fallback WebM player on Safari, IE, Edge
* getid3 (composer) used for metadata extraction
* ffmpeg (debian) used for transcoding to playback formats
**Is there a replacement/alternative for the feature? Is there a plan for a replacement?**
No, but some old components of TMH are being replaced:
The Kaltura player frontend in MwEmbedPlayer + TimedMediaHandler is being replaced with a VideoJS-based frontend which is more modern, maintained, less buggy, and will be future-proof to adding MPEG-DASH adaptive streaming if/when we move to it.