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 there.
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…
3) https://gerrit.wikimedia.org/r/#/c/145583/
4) http://knowledge.kaltura.com/kaltura-player-v2-toolkit-theme-skin-guide#Kal…
5) https://brionv.com/log/2014/07/05/ogvkit-native-ogg-vorbistheora-playing-on…
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-ch…
12) https://github.com/kaltura/mwEmbed/tree/master/modules/KalturaSupport/compo…
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.
Cheers,
Bawolff
p.s. For reference, relavent links are
https://bugzilla.wikimedia.org/show_bug.cgi?id=61095
and https://gerrit.wikimedia.org/r/#/c/144349/
https://gerrit.wikimedia.org/r/145612
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.
Thoughts?
--
Mark Holmquist
Software Engineer, Multimedia
Wikimedia Foundation
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
Dear Faidon,
I would like to follow up on our discussions about pre-rendering thumbnails on the back-end, so users can see images faster when they load them in Media Viewer.
How are you coming along with this project? My understanding is that ops procured the hardware needed for that task weeks ago, but needed more time to set up a server-side image pre-rendering service.
We’re still getting a lot of user feedback that images take too long to load, particularly from users with slow connections. We’ve implemented as many solutions as we could find to speed up image load on the front-end, but are now running out of options. So the back-end pre-rendering approach is our only hope for addressing these user concerns at this time.
What do you think is a reasonable ETA for this solution from your perspective? Is there anyone on your team we should be working with to help make this happen? I know you’ve talked to Gilles about this in the past, but wanted to follow up now, since he’s on vacation this week and you will soon become less available. :)
Look forward to working together to add this last missing piece to improve the viewing experience for our users — as well as address performance issues across our sites.
Cheers,
Fabrice
_______________________________
Fabrice Florin
Product Manager
Wikimedia Foundation
http://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)
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_Viewe…
[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
mtraceur(a)member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist
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?
Hi folks,
Brian Wolff (Cc'ed) requested a few days ago for Wikimedia to sign the
Cortado Java applet that we serve as a fallback to play video on
browsers that do not support Ogg video. That's RT #7695.
>From Brian's request: "Java has changed their default security settings
so that unsigned java applets (and even signed applets missing
permissions attribute) generally don't run. In order to make this
fallback work, we should sign the java applet."
A non-EV code-signing certificate costs something between $200-$500 per
year but before we go ahead and consider making this expense, I'd like
to open the discussion about Cortado's future.
I know Brion Vibber (also Cc'ed) has made a significant effort on
implelementing Ogg/Ogv decoding functionality in Javascript and Flash
with an end-goal of replacing Cortado, among others. We also had an
impromptu discussion with Brion and a few others in Zurich
(unfortunately with noone from multimedia, though), during which it was
widely agreed that Java applets provide a very poor user experience in
the modern web landscape.
What's the multimedia team's & community's opinion on that? Do you have
any plans regarding Cortado and/or ogv.js? Do you think we should invest
further into Cortado?
Thanks,
Faidon
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
[1]
https://www.mediawiki.org/wiki/Chemical_Markup_support_for_Wikimedia_Commons
[2] http://mol.wmflabs.org/
Hello analytics,
My last round of reducing our EL consumption was right after the launch of
Media Viewer to all wikis. I see now that the per-schema graphite stats are
back:
http://graphite.wikimedia.org/render/?width=586&height=308&_salt=1404769845…
Is that a reasonable amount of EventLogging usage for MediaViewer? Or
should we do another pass of reducing our usage?