Le 12/12/12 00:15, Erik Moeller a écrit : 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

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(a)free.fr> wrote:

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:

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(a)gmail.com> wrote: 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, 12 Dec 2012 11:35:40 -0800, David Gerard <dgerard(a)gmail.com> wrote: 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. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]

Le 12/12/12 21:57, David Gerard a écrit : 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–Linux_controversies -- Antoine "hashar" Musso

On Wed, Dec 12, 2012 at 2:50 PM, Rob Lanphier <robla(a)wikimedia.org> wrote: 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 Thu, Dec 13, 2012 at 10:38 AM, Brion Vibber &lt;bvibber(a)wikimedia.org&gt;wrote;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> or mobile < http://en.m.wikipedia.org/wiki/Serge_Haroche> ... 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 12/13/2012 04:56 PM, Brion Vibber 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_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. 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