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
[email protected]
https://lists.wikimedia.org/mailman/listinfo/multimedia
