Page MenuHomePhabricator

TimedMediaHandler: code stewardship review
Closed, ResolvedPublic

Description

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.

Event Timeline

kaldari created this task.Jan 23 2018, 1:36 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 23 2018, 1:36 AM
kaldari updated the task description. (Show Details)
kaldari updated the task description. (Show Details)

TMH has a new video player called Videojs which replaces the kaultra player.

brion added a comment.Jan 23 2018, 6:18 AM

Note I'm increasing my current work on TMH this quarter, to include:

  • finishing the replacement of the old Kaltura player frontend with a modern, maintained VideoJS-based frontend
    • following the above, the removal of the MwEmbedPlayer side-extension and its confusing setup, and all the related bits
    • ^ this alone will greatly simplify the code base
  • further improvements to the admin interface (Special:TimedMediaHandler) and the job queue infrastructure
  • cleanup of the configuration and extension setup (finish migration to extension.json)

I would really like either for Multimedia team to own it some day, or for their to be a dedicated A/V team, but for now I guess it's me. ;)

brion updated the task description. (Show Details)Jan 23 2018, 6:34 AM
brion updated the task description. (Show Details)Jan 23 2018, 6:48 AM
kaldari updated the task description. (Show Details)Jan 23 2018, 8:49 AM
kaldari updated the task description. (Show Details)Jan 23 2018, 8:54 AM
kaldari updated the task description. (Show Details)
greg triaged this task as Normal priority.Jan 23 2018, 5:23 PM
greg moved this task from Backlog to In Review on the Code-Stewardship-Reviews board.
TheDJ added a subscriber: TheDJ.Jan 23 2018, 11:38 PM
TheDJ updated the task description. (Show Details)Jan 23 2018, 11:43 PM
kaldari updated the task description. (Show Details)Jan 24 2018, 12:41 AM
brion updated the task description. (Show Details)Jan 24 2018, 9:49 PM
Restricted Application added a subscriber: MusikAnimal. · View Herald TranscriptJan 24 2018, 9:49 PM
brion updated the task description. (Show Details)Jan 24 2018, 10:07 PM

(Does anyone know how to get overall quantity of views/plays from https://tools.wmflabs.org/mediaviews/ rather than for single files?)

Do you mean for all playable media on Commons? That tool currently only allows support for up to 10 files, but I plan to add category support soon. Beyond that, I can look into adding mass querying of playcounts like we do for Massviews (except for pageviews), but if you want all playable media, across the board, it may be better to do some one-off analysis, unless we start regularly precomputing this data and serving it from an API. @Harej probably knows more.

Do you mean for all playable media on Commons? That tool currently only allows support for up to 10 files, but I plan to add category support soon. Beyond that, I can look into adding mass querying of playcounts like we do for Massviews (except for pageviews), but if you want all playable media, across the board, it may be better to do some one-off analysis, unless we start regularly precomputing this data and serving it from an API. @Harej probably knows more.

A one-off query would be awesome for now, but long-term it'd be great to have an overall "quantity of files played" and "total bandwidth used for media playback" available in the grafana graphs, to watch for spikes and just to have an overview for planning. I'll file a separate task for the kinds of data I'd want in that.

brion updated the task description. (Show Details)Jan 24 2018, 10:55 PM
brion updated the task description. (Show Details)Jan 24 2018, 11:03 PM
Jrbranaa added subscribers: adam, Jrbranaa.EditedApr 6 2018, 6:54 PM

FY18/19 Code Steward to be @brion . Adam working to address resourcing gaps. FY19/20 plans may change once Multimedia's grant obligations are complete.

Jrbranaa closed this task as Resolved.Apr 6 2018, 7:11 PM
Jrbranaa claimed this task.
Jrbranaa reassigned this task from Jrbranaa to dr0ptp4kt.