Since the switch from OggHandler to TimedMediaHandler we are one step closer to supporting video on mobile browsers.
In fact, there's one it works in now -- Firefox for Android!
We've been able to close out this Firefox evangelism bug about our broken mobile video: https://bugzilla.mozilla.org/show_bug.cgi?id=728486
However, every other mobile browser I've tested doesn't support Ogg Theora or WebM formats. Mobile Safari, Chrome, the old stock Android browser, Opera Mobile, and the IE 10 engine in our Windows 8 tablet app will show the thumbnail, but won't play the video because they need MP4/H.264.
Looking at the bug for adding transcoding... https://bugzilla.wikimedia.org/show_bug.cgi?id=39869 https://gerrit.wikimedia.org/r/#/c/25473/ ...it looks like we may have support ready to go but disabled by default, so not yet in use.
Just thought I'd check in on what it'll take to get it going. No immediate rush, but.... I'd really love to have videos working on smartphones and tablets, and not everybody runs Firefox. :)
-- brion
On Tue, Dec 11, 2012 at 3:02 PM, Brion Vibber bvibber@wikimedia.org wrote:
Just thought I'd check in on what it'll take to get it going. No immediate rush, but.... I'd really love to have videos working on smartphones and tablets, and not everybody runs Firefox. :)
As a recap, this is about expanding video support to include h.264, which is patent-encumbered (licensing fees are charged for some uses of the format). Cf. https://meta.wikimedia.org/wiki/Mobile_video_codec_policy
Since there are multiple potential paths for changing the policy (keeping things ideologically pure, allowing conversion on ingestion, allowing h.264 but only for mobile, allowing h.264 for all devices, etc.), and since these issues are pretty contentious, it seems like a good candidate for an RFC which'll help determine if there's an obvious consensus path forward.
Any takers for advancing the community conversation?
Erik
On 11 December 2012 23:15, Erik Moeller erik@wikimedia.org wrote:
Since there are multiple potential paths for changing the policy (keeping things ideologically pure, allowing conversion on ingestion, allowing h.264 but only for mobile, allowing h.264 for all devices, etc.), and since these issues are pretty contentious, it seems like a good candidate for an RFC which'll help determine if there's an obvious consensus path forward. Any takers for advancing the community conversation?
It's definitely in the class of things that would require strong community buy-in, yes.
- d.
Le 12/12/12 00:15, Erik Moeller a écrit :
Since there are multiple potential paths for changing the policy (keeping things ideologically pure, allowing conversion on ingestion, allowing h.264 but only for mobile, allowing h.264 for all devices, etc.), and since these issues are pretty contentious, it seems like a good candidate for an RFC which'll help determine if there's an obvious consensus path forward.
Could we host h.264 videos and related transcoders in a country that does not recognize software patents?
Hints: - I am not a lawyer - WMF has server in Netherlands, EU.
On Wed, Dec 12, 2012 at 3:44 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 12/12/12 00:15, Erik Moeller a écrit :
Since there are multiple potential paths for changing the policy (keeping things ideologically pure, allowing conversion on ingestion, allowing h.264 but only for mobile, allowing h.264 for all devices, etc.), and since these issues are pretty contentious, it seems like a good candidate for an RFC which'll help determine if there's an obvious consensus path forward.
Could we host h.264 videos and related transcoders in a country that does not recognize software patents?
Fact for consideration: Currently our infrastructure is not set up/able to host originals in the Netherlands. And our storage infrastructure takes more than just one server ;)
Hints:
- I am not a lawyer
- WMF has server in Netherlands, EU.
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
FirefoxOS/Boot2Gecko phones presumably also support Ogg Theora and WebM formats, but they're not really a market share yet and may never be in the developed world.
Without trying to downplay the importance of ideological purity, keep in mind that Mozilla, who have largely the same ideology on the matter have conceded defeat on the practical side of it after investing significant effort.
Eg http://appleinsider. com/articles/12/03/14/mozilla_considers_h264_video_support_after_googles_vp8_fails_to_gain_traction
With Google unwilling to commit the battle was winnable.
There is not an ideologically pure answer that is compatible with the goal of taking video content and disseminating it effectively and globally. The conversation needs to be framed as what shade of grey is an acceptable compromise.
Luke Welling
On Wed, Dec 12, 2012 at 6:44 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 12/12/12 00:15, Erik Moeller a écrit :
Since there are multiple potential paths for changing the policy (keeping things ideologically pure, allowing conversion on ingestion, allowing h.264 but only for mobile, allowing h.264 for all devices, etc.), and since these issues are pretty contentious, it seems like a good candidate for an RFC which'll help determine if there's an obvious consensus path forward.
Could we host h.264 videos and related transcoders in a country that does not recognize software patents?
Hints:
- I am not a lawyer
- WMF has server in Netherlands, EU.
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 12 December 2012 17:26, Luke Welling lwelling@wikimedia.org wrote:
Without trying to downplay the importance of ideological purity, keep in mind that Mozilla, who have largely the same ideology on the matter have conceded defeat on the practical side of it after investing significant effort.
That's because their interest is in sheer marketshare. "Mozilla went proprietary for bad reasons, therefore we should too" does not strike me as a convincing argument.
We had this exact conversation before.
- d.
As Brion points out, we get much better coverage. I enabled h.264 locally and ran though a set of Android , iOS and desktop browsers I had available at the time: http://www.mediawiki.org/wiki/Extension:TimedMediaHandler/Platform_testing
Pro h.264: * No one is proposing turning "off" webm, an ideological commitment to support free access with free platforms in royalty free formats, does not necessarily require you exclude derivation to proprietary formats. * We already are not "ideologically pure" ** We submit to the apple store terms of service, we build outputs with non-freedom iOS tool chain etc. ** We write custom code / work arounds to support proprietary non web-standard browsers. * There is little to no chance of Apple adding "googles" codec support to their platform. * We could ingest h.264 making letting the commons store source material in its originally source captured format. This is important for years down the road we have the highest quality possible. * Chicken and egg, for companies like apple to care about wikimedia webm only support, wikimedia would need lots of video, as long as we don't support h.264 our platform discourages wide use video on articles.
Pro Webm: * Royalty free purity in /most/ of what wikimedia distributes. * We could in theory add software playback of webm to our iOS and android app. * Reduced storage costs ( marginal, vs public good of access ) * Reduced licence costs for an h.264 encoder on our two transcoding boxes ( very marginal ) * Risk that mpeg-la adds distribution costs for free online distribution in the future. Low risk, and we could always "turn it off"
--michael
On 12/12/2012 11:26 AM, Luke Welling wrote:
FirefoxOS/Boot2Gecko phones presumably also support Ogg Theora and WebM formats, but they're not really a market share yet and may never be in the developed world.
Without trying to downplay the importance of ideological purity, keep in mind that Mozilla, who have largely the same ideology on the matter have conceded defeat on the practical side of it after investing significant effort.
Eg http://appleinsider. com/articles/12/03/14/mozilla_considers_h264_video_support_after_googles_vp8_fails_to_gain_traction
With Google unwilling to commit the battle was winnable.
There is not an ideologically pure answer that is compatible with the goal of taking video content and disseminating it effectively and globally. The conversation needs to be framed as what shade of grey is an acceptable compromise.
Luke Welling
On Wed, Dec 12, 2012 at 6:44 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 12/12/12 00:15, Erik Moeller a écrit :
Since there are multiple potential paths for changing the policy (keeping things ideologically pure, allowing conversion on ingestion, allowing h.264 but only for mobile, allowing h.264 for all devices, etc.), and since these issues are pretty contentious, it seems like a good candidate for an RFC which'll help determine if there's an obvious consensus path forward.
Could we host h.264 videos and related transcoders in a country that does not recognize software patents?
Hints:
- I am not a lawyer
- WMF has server in Netherlands, EU.
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Original thread from March starts here: http://comments.gmane.org/gmane.science.linguistics.wikipedia.technical/5968...
As I noted back then, this is a drastic policy change that needs a lot wider discussion, including on the wikis, than just wikitech-l.
On 12 December 2012 18:38, Michael Dale mdale@wikimedia.org wrote:
- No one is proposing turning "off" webm, an ideological commitment to
support free access with free platforms in royalty free formats, does not necessarily require you exclude derivation to proprietary formats.
This proposal is not about anything other than enhancing the shiny for owners of iOS devlces. While the devices are indisputable really lovely to use, this particular (shrinking) userbase does not constitute a group in any way lacking in access to anything we do, on any other device they own (and they do own other devices).
The only reason you can't view anything other than H.264 on iOS devices is because Apple want to promote a given severely proprietary format on their locked-down devices. This is not a reason for Wikimedia to break principle.
Mozilla is not an argument. Mozilla doing the wrong thing for directly commercial reasons is not any sort of argument for us to. It's only pressure from users that will get the companies to use unlocked formats.
- We could ingest h.264 making letting the commons store source material in
its originally source captured format. This is important for years down the road we have the highest quality possible.
Ingestion is an *entirely* separate issue, as I pointed out last time around - it is erroneous to conflate it with output. (We should be ingesting absolutely anything we can.)
- Chicken and egg, for companies like apple to care about wikimedia webm
only support, wikimedia would need lots of video, as long as we don't support h.264 our platform discourages wide use video on articles.
This claim makes no sense unless you are conflating ingestion and output. We need more video on Wikimedia from every source we can (including, per that other thread, the cheap Android mobile phones of people in Africa), but that has *nothing* to do with whether we output H.264 for the benefit of those who have chosen to use locked-down iOS devices.
- d.
Thanks for the link. I'll try and stay out of it until I've had time to read the old thread, but I think this is an unfair characterization:
On Wed, Dec 12, 2012 at 2:35 PM, David Gerard dgerard@gmail.com wrote:
This proposal is not about anything other than enhancing the shiny for owners of iOS devlces.
It's about providing knowledge to the rapidly growing userbase of mobile device owners who fall outside the tiny segment that is Android users who have deliberately chosen to replace the stock Android browser with Firefox.
Luke Welling
On Wed, Dec 12, 2012 at 11:35 AM, David Gerard dgerard@gmail.com wrote:
Original thread from March starts here: http://comments.gmane.org/gmane.science.linguistics.wikipedia.technical/5968...
As I noted back then, this is a drastic policy change that needs a lot wider discussion, including on the wikis, than just wikitech-l.
Hi folks,
The WMF Legal team is evaluating the license now to inform this decision. I don't have an ETA for this since they're a little shortstaffed right now and we're heading into the holidays.
Rob
On Wed, 12 Dec 2012 11:35:40 -0800, David Gerard dgerard@gmail.com wrote:
On 12 December 2012 18:38, Michael Dale mdale@wikimedia.org wrote:
- No one is proposing turning "off" webm, an ideological commitment to
support free access with free platforms in royalty free formats, does not necessarily require you exclude derivation to proprietary formats.
This proposal is not about anything other than enhancing the shiny for owners of iOS devlces. While the devices are indisputable really lovely to use, this particular (shrinking) userbase does not constitute a group in any way lacking in access to anything we do, on any other device they own (and they do own other devices).
The only reason you can't view anything other than H.264 on iOS devices is because Apple want to promote a given severely proprietary format on their locked-down devices. This is not a reason for Wikimedia to break principle.
Mozilla is not an argument. Mozilla doing the wrong thing for directly commercial reasons is not any sort of argument for us to. It's only pressure from users that will get the companies to use unlocked formats.
- d.
Sorry, but this isn't just about iOS and wanting to lock into proprietary video formats.
Hardware decoders for WebM are still rare. I hate H.264, but right now H.264 is the one format with hardware decoders in practically every device.
And that's pretty important. Mobile devices are low power. Without native hardware decoding video playback is taxing on the CPU and has bad performance. And more importantly, it becomes a significant drain on the device's battery life. An utter sin for anyone targeting mobile.
On 12 December 2012 11:44, Antoine Musso hashar+wmf@free.fr wrote:
Could we host h.264 videos and related transcoders in a country that does not recognize software patents? Hints:
- I am not a lawyer
- WMF has server in Netherlands, EU.
If anyone owning a chunk of H.264 had a problem with Wikimedia doing things with H.264 in the US, it could only be bad for them. I would suggest this aspect isn't really a problem.
- d.
Le 12/12/12 21:57, David Gerard a écrit :
On 12 December 2012 11:44, Antoine Musso hashar+wmf@free.fr wrote:
Could we host h.264 videos and related transcoders in a country that does not recognize software patents? Hints:
- I am not a lawyer
- WMF has server in Netherlands, EU.
If anyone owning a chunk of H.264 had a problem with Wikimedia doing things with H.264 in the US, it could only be bad for them. I would suggest this aspect isn't really a problem.
Morally I must agree. Legally I emit a huge doubt on this assumption.
We had the SCO - Linux affair [1] a few years ago where some "unknown" company started sueing anyone using Unix based on copyright infringement. It only takes one company and a bunch of lawyers to start being sued.
[1] http://en.wikipedia.org/wiki/SCO%E2%80%93Linux_controversies
On 14 December 2012 10:26, Antoine Musso hashar+wmf@free.fr wrote:
Le 12/12/12 21:57, David Gerard a écrit :
If anyone owning a chunk of H.264 had a problem with Wikimedia doing things with H.264 in the US, it could only be bad for them. I would suggest this aspect isn't really a problem.
Morally I must agree. Legally I emit a huge doubt on this assumption. We had the SCO - Linux affair [1] a few years ago where some "unknown" company started sueing anyone using Unix based on copyright infringement. It only takes one company and a bunch of lawyers to start being sued. [1] http://en.wikipedia.org/wiki/SCO%E2%80%93Linux_controversies
I was thinking legally too, but yeah, danger of patent trolls on serving - I was thinking only of the big guys. Definitely one for WMF legal.
Ingestion should be feasible outside the US, though, if accepting encumbered formats (e.g. anything a mobile phone records) is deemed a legal hazard.
- d.
On 12/11/2012 03:02 PM, Brion Vibber wrote:
However, every other mobile browser I've tested doesn't support Ogg Theora or WebM formats. Mobile Safari, Chrome, the old stock Android browser, Opera Mobile, and the IE 10 engine in our Windows 8 tablet app will show the thumbnail, but won't play the video because they need MP4/H.264.
Did you test WebM in Android Browser 2.3+ or Chrome for Android 18+ (I think this is latest).
http://caniuse.com/webm says those support WebM, but I have not verified.
Matt Flaschen
On Wed, Dec 12, 2012 at 1:04 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 12/11/2012 03:02 PM, Brion Vibber wrote:
However, every other mobile browser I've tested doesn't support Ogg Theora or WebM formats. Mobile Safari, Chrome, the old stock Android browser, Opera Mobile, and the IE 10 engine in our Windows 8 tablet app will show the thumbnail, but won't play the video because they need MP4/H.264.
Did you test WebM in Android Browser 2.3+ or Chrome for Android 18+ (I think this is latest).
http://caniuse.com/webm says those support WebM, but I have not verified.
I was able to play the WebM file of the locomotive on the front page of https://commons.wikimedia.org just now on my Nexus 7 using Chrome, so at least on very new stock Android devices, all is well. My much older Galaxy S didn't fare so well, though, so I would be willing to believe that Android devices with proper WebM support are still relatively rare. That said, the replacement rate for this hardware is frequent enough that it won't be long before my Nexus 7 is "much older".
Rob
On Wed, Dec 12, 2012 at 2:50 PM, Rob Lanphier robla@wikimedia.org wrote:
On Wed, Dec 12, 2012 at 1:04 PM, Matthew Flaschen mflaschen@wikimedia.org wrote:
Did you test WebM in Android Browser 2.3+ or Chrome for Android 18+ (I think this is latest).
http://caniuse.com/webm says those support WebM, but I have not
verified.
I was able to play the WebM file of the locomotive on the front page of https://commons.wikimedia.org just now on my Nexus 7 using Chrome, so at least on very new stock Android devices, all is well. My much older Galaxy S didn't fare so well, though, so I would be willing to believe that Android devices with proper WebM support are still relatively rare. That said, the replacement rate for this hardware is frequent enough that it won't be long before my Nexus 7 is "much older".
Aha, that's good news! I'll run more thorough tests... Android 2.3 is still a majority so depending on whether this is really a 2.3 thing or a 4.0 thing we may or may not have enough coverage for Android.
I'm not sure that hardware decoding is available for WebM on many (any?) devices, so performance seems to vary even on software that understand it; Firefox on my Galaxy Nexus runs the WebM video on http://en.m.wikipedia.org/wiki/Red_Panda very nicely but our Firefox OS test device with a much slower CPU is too choppy to watch.
Another possibility is that we could invest time in making a standalone WebM player application for iOS, Windows 8/RT, etc that we can easily direct people to install without administrative privileges. It wouldn't have hardware acceleration and it would be a poorer user experience to pop out of the browser or Wikipedia app, but it would be possible.
It's much, MUCH easier for us to flip the H.264 switch... there are ideological reasons we might not want to, but we're going to have to put the effort into making those player apps if we want all our data accessible to everyone.
-- brion
On 12/13/2012 12:38 PM, Brion Vibber wrote:
It's much, MUCH easier for us to flip the H.264 switch... there are ideological reasons we might not want to, but we're going to have to put the effort into making those player apps if we want all our data accessible to everyone.
+1 its non trivial amount of effort to integrated native players across at least 3 major platforms, ( iOS, Android, Win8 ), And as pointed out in the thread, low power android / firefox OS devices include h.264 hardware decoders but will fail for medium resolution webm.
I think Wikimedia mobile product needs to come up with some recommendations for the Board / community to evaluate. There are trade offs in effort and resource allocation.
Is integrating software video decoders with native apps the best use of resources? or are there other higher priority efforts? Or more realistically, the ideological hard line, means kicking the proverbial video on Wikipedia bucket further down stream, which is also a trade off of sorts.
--michael
On Thu, Dec 13, 2012 at 10:38 AM, Brion Vibber bvibber@wikimedia.orgwrote:
On Wed, Dec 12, 2012 at 2:50 PM, Rob Lanphier robla@wikimedia.org wrote:
I was able to play the WebM file of the locomotive on the front page of https://commons.wikimedia.org just now on my Nexus 7 using Chrome, so at least on very new stock Android devices, all is well. My much older Galaxy S didn't fare so well, though, so I would be willing to believe that Android devices with proper WebM support are still relatively rare. That said, the replacement rate for this hardware is frequent enough that it won't be long before my Nexus 7 is "much older".
I can play the current media on the front page of Commons in Chrome on my Nexus 7, but it won't play in position on either desktop < http://en.wikipedia.org/wiki/Serge_Haroche%3E or mobile < http://en.m.wikipedia.org/wiki/Serge_Haroche%3E ...
Sigh. :)
Still some work to be done on compatibility...
I also notice that the <source> elements in the <video> seem to start with the original, and aren't labeled with types or codecs. This means that without the extra Kaltura player JS -- for instance as we see it on the mobile site right now -- the browser may not be able to determine which file is playable or best-playable.
This may be contributing to the rrreeeeaaalllyyy slow performance I see on our FirefoxOS test device -- which understands Ogg Theora and WebM but has no hardware acceleration for them, and a relatively slow processor. If it's pulling a 1920x1080 original to play on a 320x480 screen, it's going to be slower than it needs to be.
-- brion
On Thu, Dec 13, 2012 at 2:56 PM, Brion Vibber bvibber@wikimedia.org wrote:
I can play the current media on the front page of Commons in Chrome on my Nexus 7, but it won't play in position on either desktop < http://en.wikipedia.org/wiki/Serge_Haroche%3E or mobile < http://en.m.wikipedia.org/wiki/Serge_Haroche%3E ...
On more careful testing, the *desktop* web site shows the video on the Nexus 7 (and 10) while the *mobile* site shows only a black rectangle when trying to play.
I also notice that the <source> elements in the <video> seem to start with
the original, and aren't labeled with types or codecs. This means that without the extra Kaltura player JS -- for instance as we see it on the mobile site right now -- the browser may not be able to determine which file is playable or best-playable.
It looks like Chrome on Android 4+ (and MAYBE 2.3 but I can't verify it yet) plays WebM but not Ogg Theora. So on the desktop site, the JS finds the WebM sources and they play. On the mobile site (with no video JS available) the first source which is the Ogg Theora original gets selected by default and doesn't play.
Adding 'type' attributes listing the file type and codecs used should allow Chrome to see the WebM versions and play them by itself, and get us working on newer Android devices in Chrome/Browser as well as Firefox...
Filed as: https://bugzilla.wikimedia.org/show_bug.cgi?id=43101
Alternately or in addition, we could pull in some of the JS for the mobile site too, but we'll have to evaluate stuff.
Whee!
-- brion
On 12/13/2012 04:56 PM, Brion Vibber wrote:
On Thu, Dec 13, 2012 at 10:38 AM, Brion Vibber bvibber@wikimedia.orgwrote:
On Wed, Dec 12, 2012 at 2:50 PM, Rob Lanphier robla@wikimedia.org wrote:
I was able to play the WebM file of the locomotive on the front page of https://commons.wikimedia.org just now on my Nexus 7 using Chrome, so at least on very new stock Android devices, all is well. My much older Galaxy S didn't fare so well, though, so I would be willing to believe that Android devices with proper WebM support are still relatively rare. That said, the replacement rate for this hardware is frequent enough that it won't be long before my Nexus 7 is "much older".
I can play the current media on the front page of Commons in Chrome on my Nexus 7, but it won't play in position on either desktop < http://en.wikipedia.org/wiki/Serge_Haroche%3E or mobile < http://en.m.wikipedia.org/wiki/Serge_Haroche%3E ...
Sigh. :)
I think this relates to the page not being purged after the transcodes are updated. If you purge the page, will probably give the nexus a more playable flavour. http://en.wikipedia.org/wiki/Serge_Haroche should work on your nexus now ;)
TMH should add page purge to the job queue, but not sure why that page had not been purged yet.
Still some work to be done on compatibility...
I also notice that the <source> elements in the <video> seem to start with the original, and aren't labeled with types or codecs. This means that without the extra Kaltura player JS -- for instance as we see it on the mobile site right now -- the browser may not be able to determine which file is playable or best-playable.
For correctness we should include "type". But I don't know if that will help, the situation you describe. https://gerrit.wikimedia.org/r/#/c/38665/
But certainly will help in the other ways you outline in the bug 43101
AFAIK there are no standard source tag attributes to represent device specific playback targets ( other than type ), so we set a few in data-* tags and read them within the kaltura html5 lib to do flavour selection.
We of course use the Kaltura HTML5 lib on lots of mobile devices, so if you want to explore usage in the mobile app happy to support. For example including the payload into the application itself ( so its not a page view time )
peace, --michael
On Thu, Dec 13, 2012 at 4:38 PM, Michael Dale mdale@wikimedia.org wrote:
I think this relates to the page not being purged after the transcodes are updated. If you purge the page, will probably give the nexus a more playable flavour. http://en.wikipedia.org/wiki/**Serge_Harochehttp://en.wikipedia.org/wiki/Serge_Harocheshould work on your nexus now ;)
TMH should add page purge to the job queue, but not sure why that page had not been purged yet.
Aha! That could explain it yes.
I also notice that the <source> elements in the <video> seem to start with
the original, and aren't labeled with types or codecs. This means that without the extra Kaltura player JS -- for instance as we see it on the mobile site right now -- the browser may not be able to determine which file is playable or best-playable.
For correctness we should include "type". But I don't know if that will help, the situation you describe. https://gerrit.wikimedia.org/**r/#/c/38665/https://gerrit.wikimedia.org/r/#/c/38665/
But certainly will help in the other ways you outline in the bug 43101
Awesome, thanks! I'll test it out and make sure it does what I expect... currently cloning MediaWiki again in my Linux VM so I can use libav on it without having to compile it under OSX ("all the fun of old proprietary Unix under the hood!"), so will probably test it a bit later. :)
AFAIK there are no standard source tag attributes to represent device specific playback targets ( other than type ), so we set a few in data-* tags and read them within the kaltura html5 lib to do flavour selection.
We of course use the Kaltura HTML5 lib on lots of mobile devices, so if you want to explore usage in the mobile app happy to support. For example including the payload into the application itself ( so its not a page view time )
I'll explore that as well. Spiffy!
-- brion
wikitech-l@lists.wikimedia.org