Rainer Rillke | 19 Jul 15:54 2014

Upload Wizard's configuration

"Commons configuration of Upload Wizard does not belong here" was the
premise under which a patch by a Wikimedia Commons contributor has been
recently rejected in the Upload Wizard repository. There was neither an
explanation of where to put the patch instead, nor anything helpful
about how to achieve it. And it turned out that it's non-trivial.
Okay, so I thought I give the contributor a helping hand and propose
alternative patches. While doing so, I discovered that re-configuring
Upload Wizard in *Settings.php is overly difficult when it comes to
licensing options: While it is possible adding licenses (having a
license label and a template grouped by a key) one has to repeat all the
license groups (this is how the previously defined licenses are grouped)
for example for third party licenses for having just one augmentation.
It has been suggested creating an Extension for licensing options; this
would most likely solve the issue with translation of these options but
it won't solve anything regarding grouping of these licenses. This needs
to be fixed in Upload Wizard. So what could we do about it?
Have the entire license grouping configuration
* … in *Settings.php
* … on-wiki in a page in the MediaWiki namespace
* … on-wiki in a page in the Campaign namespace (i.e. having a "default

The 2 latter options would be, from the administrative perspective,
similar to [[MediaWiki:Licenses]], where licenses are listed for

I don't know why Upload Wizard decided to store these options in its own
extension repository directory in the first place. Was it a lack of
consideration or time, laziness or intentionally? All I know is that
certain people never appear to get tired emphasizing that MediaWiki -
(Continue reading)

Fabrice Florin | 18 Jul 19:45 2014

Media Viewer Update: Quick access to enable/disable, opt-in/opt-out metrics

Hi everyone,

We appreciate the ongoing conversations about Media Viewer, and wanted to give you a quick update on this project. 

This week, we’ve been discussing practical ways to address community concerns on the English Wikipedia and Wikimedia Commons RfCs — and improve metrics used to establish the default configuration for this tool.

We would like to propose a new feature which we think can address many of the issues we’ve heard so far: the Viewing Options Panel (1) would let you quickly disable (or enable) Media Viewer. It would prominently display a ‘cog’ icon at the top right corner of the screen, as shown in the feature's mockup (2) and rough prototype (3). 

Clicking on that icon would display a settings panel with two viewing options:
* 'View quickly’ — enable Media Viewer (or keep it enabled)
* 'View all the details’ — disable Media Viewer and show the file page instead

This would make it much easier for users to decide for themselves if they want Media Viewer enabled or not. It would also allow us to collect better user data on whether or not this tool is useful -- which can inform our discussions about default state for different user groups. To that end, we plan to track the number of enable and disable events by user group on the existing Opt-in/Opt-out Dashboard (4) (this dashboard now tracks clicks on the “Disable/Enable’ links at the bottom of Media Viewer, which would be replaced by the Viewing Options Panel).

What do you think of this new feature? Does it seem worth developing at this time? Any suggestions for improvement? 

We would greatly appreciate your feedback about the Viewing Options Panel on this multimedia mailing list, or on the Media Viewer discussion page:

We are also considering a controlled experiment on the English Wikipedia. We invite you to comment on that separate proposal on its research page. (5) 

Thanks again for taking the time to share your thoughts and feedback on Media Viewer. Your comments are really helpful to us, and we look forward to working with you in coming days to improve this tool together. 

To be continued, 

Fabrice and the Multimedia Team

(1) Viewing Options Panel - Proposed Spec:

(2) Viewing Options Panel - Mockup:

(3) Viewing Options Panel - Rough Prototype:

(4) Opt-in/Opt-out Dashboard:

(5) Controlled Experiment Proposal:


Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation


Multimedia mailing list

Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Michael Dale | 14 Jul 21:49 2014

Upgrading TMH to latest upstream mwEmbed Player

Lately there has been some exciting activity on the player / video front; Brion has done a first pass at
integrating ogv.js[1], multimedia team and volunteers have been submitting fixes and enhancements to
the TMH extension[2], including long standing issues such as dynamically loading the lib to reduce page
payload [3].  In this email we outline: why upgrade, how things have diverged, and architecture choices to
be made.  

= Why Sync with Upstream? =

Over the past two years a teams of developers have been hard at work on the kaltura player library. . Some of
the relevant notes: 

	* Modern skin, theming, templatized plugins components with inherited plugin types, clean separation
of JSON config, CSS, html / templates, and Javascirpt plugins.  
	* Native bridge; enables js-buisness & display logic with of native software video playback; i.e would
enable wmf components ( captions and content license ) to be used with native playback  software such as the
oggKit experiments Brion has done [5]
		See Architecture overview [4]
	* Iframe isolation from parent CSS / JS, Robust embed API. Thumbnail embed API for example; captures user
gesture for playing iframe video on mobile-web ( would not require two clicks )
	* Bugs that show up within WMF such as some versions of android forcing content duration to 1 second, were
addressed up-stream long ago.
	* Kaltura invests in testing a truly massive QA matrix of library features across dozens of platforms.
	* Keep up-to-date with new features and industry trends; MPEG-DASH, WebVTT etc.
	* Plugins for everything but "only loading what you need” we leverage the resource loader to load only
whats needed based on json config. 
		If WMF ever need analytics or wanted to run a preroll during fundraising or whatever, would be simple
modification to JSON player config. 

=  Things have diverged =

The original synchronization architecture had both mwEmbed[6] and TMH share identical copies of
"mwEmbed modules”. Within mwEmbed we packaged the mediaWiki resource loader so that it works as a stand
alone library. This is used within the mwEmbed project to this day [7]. Through the course of development
of “v2” dependencies emerged against an additional module ( KalturaSupport ) which hosts the
component definitions.[12] Additional minor enhancements to the resource loader were added to map JSON
player plguin definitions to resource loader module lists, so that iframe build out logic can include all
required resources prior to player invocation. There are likely other hidden dependencies on iframe
based buildout introduced, and the kWidget embed / player API [8] assumes that the player always lives in
an iframe.    

Furthermore within player v2 has more decencies on normalized metadata and source definitions, i.e
plugins templates reference properties like {mediaProxy.entry.description} or
{mediaProxy.entryMeta.customKey} that gets substituted for the respective value. 

= Stuff we need to regardless of Architecture choices  = 

1) Remove MwEmbedSupport extension, since TMH is the only consumer, bootstrap logic should be moved
2) Synchronize shared resources / update libraries as paladox has started doing upstream [9]
3) Upgrade jQuery usage “promises" instead of custom code that pre-dated promises for doing similar
things like triggerQueuedCallback [10]
4) other mediaWiki updates ( JSON language files [11], etc. ) 

= Architectural options going forward =

We have to decide between some options: 

1) update the modules, ( most similar to existing TMH architecture ) 
	Add kalturaSupport module, support hard coded JSON player config, keep projects in-sync via shared
module copies. 
	Update the player libraries to deal with inline playback ( loses iframe isolation )
	Update embed logic to work against stand alone sources or video tag embed. ( loses some embed api features )
	Add mapping / bootstrap for player metadata and sources.
2) Use an ApiProxy within TimedMediaHander ( use WMF resource loader, but proxies the data services
instead of an alternate embed API, i.e half way between 1 and 3  ) 

3) Completely isolate the player separate server / service that consumes mediaWiki API ( most similar to
how we integrate with other non-kaltura playable entity services ) 
	Would mean player does not consume the same "resource loader" as other extensions
	The player would be a self contained service run on separate servers.  
	Would mean kWidget.embed calls would be used to embed the player. 
	Would be easy to keep in-sync with upstream since we essentially just have to maintain a "JSON xslt”

= links =

1) http://lists.wikimedia.org/pipermail/multimedia/2014-July/000727.html
2) https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/TimedMediaHandler,n,z
3) https://gerrit.wikimedia.org/r/#/c/145583/
4) http://knowledge.kaltura.com/kaltura-player-v2-toolkit-theme-skin-guide#Kaltura%20Player%20v2%20Toolkit%20Architecture%20Diagram
5) https://brionv.com/log/2014/07/05/ogvkit-native-ogg-vorbistheora-playing-on-ios/
7) https://github.com/kaltura/mwEmbed/tree/master/includes/resourceloader
8) http://player.kaltura.com/docs/api
9) https://github.com/kaltura/mwEmbed/pulls/paladox2015
10) https://bugzilla.wikimedia.org/show_bug.cgi?id=65428
11) https://blog.wikimedia.org/2014/04/10/mediawiki-localization-file-format-changed-from-php-to-json/
12) https://github.com/kaltura/mwEmbed/tree/master/modules/KalturaSupport/components
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Brion Vibber | 14 Jul 06:31 2014

Preliminary ogv.js integration for Ogg playback in Safari, IE

I spent the weekend hacking at integration of my ogv.js JavaScript Ogg media player into TimedMediaHandler's embedded player widget. Patch set in progress:

It's pretty much working in Safari 7 and IE 10/11, but needs various tweaks and fixes still. Some older browser versions should be supportable using a Flash cross-compile, but I haven't got that running in the embedding yet.

Here's a wiki running the patch with some sample files:

In the process I've noticed several issues with TimedMediaHandler and its dependencies when running on cutting-edge infrastructure; various bugs filed:

HHVM issues:
* https://bugzilla.wikimedia.org/show_bug.cgi?id=67937 - players don't display (patch)

Ubuntu Trusty video transcoding issues:
* https://bugzilla.wikimedia.org/show_bug.cgi?id=67953 .ogv transcodes broken (upstream; workaround)
* https://bugzilla.wikimedia.org/show_bug.cgi?id=67951 .webm transcodes broken (upstream)

And a Vagrant configuration issue:

-- brion
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Federico Leva (Nemo | 11 Jul 23:24 2014

Re: Pre-rendering thumbnails on the back-end

Gergo Tisza, 09/07/2014 00:55:
> There is now: https://bugzilla.wikimedia.org/show_bug.cgi?id=67698 

Thank you! Following up on the "Swift capacity" thread, a doubt
developed in the last few days in my brain:

Gergo Tisza, 06/07/2014 23:08:
>         Media Viewer could benefit greatly from this performance-wise.
>         As seen on this graph, the launch to all wikis affected the
>         average considerably, since users started hitting a lot of
>         images that didn't have Media Viewer-sized thumbnails yet:
>     This looks pretty bad. Thanks for calling it out.
> I don't think it's especially bad; there is a spike after the rollout
> (it can be seen more clearly if you scroll down to the imagemiss stats)
> which lasts about five says, other than that it's just probably the
> effect of rolling out to new userbases which have on average much worse
> network conditions then the Europe/USA based ones.
> If you look at wikis to which we have rolled out earlier, e.g.
> there is no change at all.
> Which is not to say the lack of pregenerated thumbnails is not a serious
> problem (I just don't think it got any worse recently). Comparing the
> global imagehit and imagemiss stats, the lack of pregeneration affects
> about 20% of the requests, and costs about 730ms (an extra 85% loading
> time) for the median user.

This does make me wonder, what do those graphs *actually* measure? Are
they really measuring a comparable/representative set of image requests
from which we can infer that one or the other method is intrinsically
faster than the other, or are they measuring different things e.g. for
some selection bias?


Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Mark Holmquist | 11 Jul 21:06 2014

MMV disablement on private wikis


This seemed like a reasonable (and fast) enough request for me, so I made
a patch. Does anyone have any good reason that the feature which, frankly,
is broken on private sites, should be enabled there?

IIRC Chrome users cannot use the feature at all, Firefox users are hit
or miss.

Plus, most of those private wikis aren't *viewed* by anyone, they're just
communities of editors who discuss issues in private.



Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Mark Holmquist | 10 Jul 23:36 2014

Multimedia team update, a bit tardy

Happy Thursday to y'all! Let's do the run-down.

== Media Viewer ==

This project is winding to a merciful close - we're seeing the final few
patches going out this week and next, and we're switching our work focus
to UploadWizard and other smaller projects.

There is an RFC [0] on English Wikipedia to remove the viewer by default,
which has been closed. The WMF has decided not to disable the viewer by
default, but refer to the talk page [1] for the latest.

There are also RFCs on Commons [2] and dewiki [3].

== UploadWizard ==

We're starting work on planning and metrics for this part of our upload
pipeline. We've started tracking our work on refactoring the software in
Phabricator [4][5], and we have a bigger patch out [6] that's looking to
make the codebase a little more in line with more modern code conventions
in various extensions.

We also have some work underway to replace outdated one-use libraries
with more modern, widely re-usable software.

== Core work ==

We have a few changes open to make thumbnailing a little faster and also
easier to handle. The platform team is reviewing those changes and we
should push them out in the next few weeks.

== Other ==

If I've missed something you have questions on, feel free to bother the
list! Have a nice week, all.

[0] https://en.wikipedia.org/wiki/Wikipedia:Media_Viewer/June_2014_RfC
[1] https://en.wikipedia.org/wiki/Wikipedia_talk:Media_Viewer/June_2014_RfC
[2] https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/Media_Viewer_software_feature
[3] https://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Medienbetrachter
[4] http://fab.wmflabs.org/T433
[5] http://fab.wmflabs.org/T438


Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Gilles Dubuc | 10 Jul 17:26 2014

UploadWizard and GPLv3 libraries

Hi Luis,

We are currently studying open-source libraries to be used in a refactor of UploadWizard, and FineUploaded is currently being considered: http://fineuploader.com/

That library is licensed under GPLv3, while UploadWizard is GPLv2. UploadWizard doesn't specify "2 or later".

Is that a problem? Does that mean we need to work on a license change for UploadWizard? If so, what would be the process?
Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Rainer Rillke | 8 Jul 14:18 2014

Support for Chemical table files [Cross-posted to Commons-l]

As of now, images of structural formulas have to be created using third
party software and converting the output to SVG or PNG. With
MolHandler[1] we aim for a solution capable accepting and rendering
chemical markup files and providing a web-interface for easily creating,
modifying and re-mixing formula files. This does not only make re-using
existing structures easier and simplifies creation of structures,
moreover it allows Wikis to adopt a unified style for rendering these
structures, makes structures searchable (sub-structure search) allows
pulling, pushing and verifying data from big databases like ChemSpider
and PubChem. In the future we plan to enable support for spectra and
more sophisticated file formats to have at least some minimum support
for chemistry-related Wiki-works.

I am currently looking for features you would find helpful and therefore
created a test wiki[2] at which you can create user accounts.
A non-exhaustive list of features is available for raking by drag&drop.
Or just write here what you at least want, what you would like to see
soon and what is less important to you.

-- Rillke

[2] http://mol.wmflabs.org/

Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Brian Wolff | 8 Jul 08:27 2014

Changes to how videos play on iPhones/iPads

Hi all,

With a lot of help from Brion (thanks :), I've now changed the way
that videos are handled on Commons on iOS devices (when browsing from
the desktop site). The change will go live on July 15th.

Previously, you clicked play, not much happened. There was a small
easily ignored pop-up linking you to a help page, and a play button
which in theory linked to the src video file (but in practice was
possibly unclickable due to having too low a z-index).

Now, you are directed to install the vlc-for-iOS app. If you have the
app already installed, the video will automatically open in the app
upon pressing play.

This change will only affect the desktop site, as TimedMediaHandler is
totally not loaded at all on the mobile site (However, if you have the
vlc app installed, you can download the video from the mobile site,
and it should play).

For reference, iOS users represent roughly 11% of our user base. Its
unclear how many of those browse the desktop site vs mobile site,
although I imagine most use mobile and are not affected by this change
:( . Nonetheless, every bit helps.


p.s. For reference, relavent links are
and https://gerrit.wikimedia.org/r/#/c/144349/

Multimedia mailing list
Multimedia <at> lists.wikimedia.org
Erik Moeller | 8 Jul 01:27 2014

OgvKit (iOS)

Really exciting new work by Brion to make free/libre video formats playable on, erm, not-so-free devices:


Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Multimedia mailing list
Multimedia <at> lists.wikimedia.org