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/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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia