Gilles Dubuc | 28 Jul 14:58 2014

Fwd: MMV browser blacklist?

We can definitely add older Operas to the blacklist if they are problematic. First we need to investigate if the issue is at the OOJS level, in which case if might be fixable, since OOJS now supports older ES3 browsers thanks to a shim.

Added to the current cycle on Mingle:

---------- Forwarded message ----------
From: Erik Moeller <>
Date: Sun, Jul 27, 2014 at 2:28 AM
Subject: MMV browser blacklist?
To: Gergo Tisza <>, Gilles Dubuc <>, Fabrice Florin <>

It looks like we're only blacklisting old versions of MSIE now? I saw a user report that it completely blocked image views on an older browser and just went into to test with Opera 10 (they didn't specify a browser but Opera and old IE versions are always my first guess). Indeed image clicks just die -- and the error console throws oojs errors. 

Seems to me like we either want to most likely significantly expand that blacklist to cover older, more obscure browsers that otherwise lose complete access to images, no?

Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Multimedia mailing list
Multimedia <at>
Brion Vibber | 26 Jul 22:29 2014

Preliminary iOS media playback in mobile view

Today I took a stab at combining ogv.js JavaScript-based media playback with MobileFrontend by adding a loader shim to TimedMediaHandler on the 'mobile' target (the rest of TimedMediaHandler's desktop support code is not loaded, so the UI is mobile-specific but very bare-bones).

Demo page can now play back audio and video in iOS 7's Safari in mobile mode as well as desktop mode:

The mobile loader code checks for any <audio> or <video> elements and asks them if they canPlayType() on any of their available sources, so it only loads if non-native playback is actually required. (So for instance it disengages on Android Chrome which can play Ogg Vorbis audio and WebM video, or in theory in Safari if you have locally enabled MP4/H.264 files.)

It needs more work to check for browser compatibility, sufficient JavaScript engine speed, etc, but I find it encouraging that it works so far. :)

Some thoughts and questions:

* Currently ogv.js gets loaded if any audio/video elements are present that require it to play, even if they don't get played. I can delay the loading to when 'play' is clicked fairly easily.

* [[Media:]] or other direct file links, often used for pronunciation markers in Wikipedia articles, are not picked up by this system. Need to extend things a bit to detect clicks on such links and display a player instead of just downloading the file. Same problem occurs in Safari and IE on desktop mode.

* Should we show the video in an overlay like the mobile media viewer for images, instead of playing inline? This is a good place to add additional controls to reach file info details, as with images. If so should I try to extend the same overlay code in MF or create a near-lookalike that lives in TMH?

* If so, that should probably be used for *all* mobile browsers, using the native playback when available instead of loading ogv.js...

* Should we have a manual resolution switcher, as on desktop? (Controlling source selection via code could also fix a problem with Android being unable to play Ogg Theora videos, to force it to WebM which does work natively.)

* On iOS, should the source selector offer to launch higher-res and WebM videos in the external VLC app? 360p is about the limit of good performance in ogv.js on current A7-based iOS devices, and slower models max out at 160p if they can even handle that.

-- brion
Multimedia mailing list
Multimedia <at>
Fabrice Florin | 26 Jul 01:18 2014

Multimedia Events at Wikimania 2014


We look forward to meeting many of you at Wikimania this year.

Our multimedia team is hosting a number of events during the hackathon and conference.

We invite you to sign up for the sessions that interest you, on the pages linked below.

We’ll update times and places of hackathon sessions on this overview page:

Hope to see you then,

Fabrice — for the Multimedia Team



Hackathon Sessions:

* Upload Wizard Discussion - Wed. Aug. 6
(time/place TBD - 60 minutes in the afternoon)

* Structured Data Discussion - Thu. Aug. 7
(time/place TBD - 90 minutes in the morning)

* Media Viewer Discussion - Thu. Aug. 7
(time/place TBD - 60 minutes in the afternoon)

Conference Sessions:

* Multimedia Overview - Fri., August 8, 11:30 GMT - Auditorium 2:

* The State (and Fate) of Video in Wikimedia - with Andrew Lih and Fabrice Florin  - Fri. Aug. 8, 12:00 GMT - Auditorium 2:

* Freedom in motion: the state of open video and audio at Wikimedia - with our colleague Brion Vibber  - Fri. Aug. 8, 12:30 GMT - Auditorium 2:

* Multimedia Roundtable - Sun. Aug. 10, 11:30 GMT - Boardroom:

* A Culture of Kindness - with Fabrice Florin - Sunday, August 10, 15:30 GMT, Auditorium 1:
(this last one is not focused on multimedia, but might interest you as well :)


Fabrice Florin
Product Manager, Multimedia
Wikimedia Foundation

Multimedia mailing list
Multimedia <at>
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 -
and Upload Wizard included - is not the right place for Wiki
configuration and when it appears to hurt their feelings when I claim
WMF wikis would be MediaWiki's "primary customer". Come, wake up and
whip your fancy ideology. WMF wikis were used as the base for most
software development in regard to MediaWiki -- and they are used for
alpha-testing. We currently can't neglect that, although, I wouldn't
mind if we try hard to change that.

Why did Commons want to amend the licensing options at all?

Upload Wizard offers an option "free in the U.S. because published
before 1923" -- while a work is free in the U.S., it doesn't necessarily
have to be in "foreign countries", where we usually find a protection
duration of author's live time +70 years. And Wikimedia Commons has
decided to respect the copyright situation of a work in the U.S. and the
country of origin.

-- Rillke
Wikimedia Commons administrator

* Local|Common

Multimedia mailing list
Multimedia <at>
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>
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 =

Multimedia mailing list
Multimedia <at>
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:
* - players don't display (patch)

Ubuntu Trusty video transcoding issues:
* .ogv transcodes broken (upstream; workaround)
* .webm transcodes broken (upstream)

And a Vagrant configuration issue:

-- brion
Multimedia mailing list
Multimedia <at>
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: 

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>
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>
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.



Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
Multimedia mailing list
Multimedia <at>
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:

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>