Please give feedback at: https://www.mediawiki.org/wiki/Talk:Code_stewardship_reviews/Feedback_solicitation/TimedMediaHandler
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 long-term.
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
Hard to quantify. Commons has about 800,000 audio files and 110,000 video files. Not sure how much these are used on the projects though.
About 8500 WebM-source video files and 26,500 Ogg Theora-source video files (may be undercounted due to some videos having .ogg extension indistinguishable from audio) are in use in pages on English Wikipedia; have not queried other databases yet.
Audio files are used on hundreds of thousands of pages for pronunciation guides etc, and the MP3 transcoding now done by TMH is required for fast playback on some operating systems.
(Does anyone know how to get overall quantity of views/plays from https://tools.wmflabs.org/mediaviews/ rather than for single files?)
Changes committed in last 1, 3, 6, and 12 months
Mostly dependency updates and i18n last year.
Active work has continued on the replacement frontend in January 2018, to be followed by removal of old frontend (reduction of complexity/deps).
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
4-ish
Number and age of open patches
11, mostly last updated last year. Some are obsolete, some will be recovered.
Number and age of open bugs
See workboard at https://phabricator.wikimedia.org/project/view/299/
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
- a couple self-maintained video.js plugins
- one community-maintained video.js plugin (videojs-source-switcher-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 T100106: Replace Kaltura player with Video.js, which is more modern, maintained, less buggy, closer to HTML5 and browser standards, and will be future-proof to adding MPEG-DASH adaptive streaming if/when we move to it.