As some may know, we've restricted videos on Wikimedia sites to the freely-licensed Ogg Theora codec for some years, with some intention to support other non-patent-encumbered formats like WebM.
One of our partners in pushing for free formats was Mozilla; Fire fox's HTML5 video supports only Theora and WebM.
The prime competing format, H.264, has potential patent issues - like other MPEG standards there's a patent pool and certain licensing rules. It's also nearly got an exclusive choke hold on mobile - so much so that Mozilla is considering ways to adopt H.264 support to avoid being left behind:
http://blog.lizardwrangler.com/2012/03/18/video-user-experience-and-our-miss...
Is it time for us to think about H.264 encoding on our own videos?
Right now users of millions of mobile phones and tablets have no access to our audio and video content, and our old desktop fallback of using a Java applet is unavailable.
In theory we can produce a configuration with TimedMediaHandler to produce both H.264 and Theora/WebM transcodes, bringing Commons media to life for mobile users and Apple and Microsoft browser users.
What do we think about this? What are the pros and cons?
-- brion
Please. Although WebM is a promising format, it's not available yet. The Java fallback is a solution even worse than just using Fash, so if we want to get with this century, I believe we have to hold our noses and adopt a modern format.
On Monday, March 19, 2012, Brion Vibber brion@pobox.com wrote:
As some may know, we've restricted videos on Wikimedia sites to the freely-licensed Ogg Theora codec for some years, with some intention to support other non-patent-encumbered formats like WebM.
One of our partners in pushing for free formats was Mozilla; Fire fox's HTML5 video supports only Theora and WebM.
The prime competing format, H.264, has potential patent issues - like
other
MPEG standards there's a patent pool and certain licensing rules. It's
also
nearly got an exclusive choke hold on mobile - so much so that Mozilla is considering ways to adopt H.264 support to avoid being left behind:
http://blog.lizardwrangler.com/2012/03/18/video-user-experience-and-our-miss...
Is it time for us to think about H.264 encoding on our own videos?
Right now users of millions of mobile phones and tablets have no access to our audio and video content, and our old desktop fallback of using a Java applet is unavailable.
In theory we can produce a configuration with TimedMediaHandler to produce both H.264 and Theora/WebM transcodes, bringing Commons media to life for mobile users and Apple and Microsoft browser users.
What do we think about this? What are the pros and cons?
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Not available yet? What century do you come from?
WebM has been supported in Firefox since 4, Chrome since 6, and Opera since 10.6. It's also apparently supported by Opera Mobile since <video> was introduced and the Android browser since Gingerbread.
And where do you get off talking about h264 as modern format from this century. h264's development started in the 20th century, it's been almost 10 years since the format was standardized. If you want to talk about modern and this-century then you should be pointing to WebM which was standardized recently in this century.
I do have one thing to say. I don't think we should drop plans to support WebM. At the very least, if we do decide to add additional support for h264 we should make sure to use <video> tags which include both a WebM and h264 source.
No, it's just none of my programs have an 'export to off' or an 'export to WebM' feature and as much as we might want to, we can't ignore old technology, like IE (even IE7) or Safari (mobile). h264 may not be modern, but it is widely used. I believe we should create a platform that can encode both WebM and H264, with support for native <element>s and Flash.
On Monday, March 19, 2012, Daniel Friesen lists@nadir-seen-fire.com wrote:
Not available yet? What century do you come from?
WebM has been supported in Firefox since 4, Chrome since 6, and Opera
since 10.6.
It's also apparently supported by Opera Mobile since <video> was
introduced and the Android browser since Gingerbread.
And where do you get off talking about h264 as modern format from this
century. h264's development started in the 20th century, it's been almost 10 years since the format was standardized. If you want to talk about modern and this-century then you should be pointing to WebM which was standardized recently in this century.
I do have one thing to say. I don't think we should drop plans to support
WebM. At the very least, if we do decide to add additional support for h264 we should make sure to use <video> tags which include both a WebM and h264 source.
-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On Mon, 19 Mar 2012 20:12:45 -0700, Mono monomium@gmail.com wrote:
Please. Although WebM is a promising format, it's not available yet. The Java fallback is a solution even worse than just using Fash, so if we
want
to get with this century, I believe we have to hold our noses and adopt a modern format.
On Monday, March 19, 2012, Brion Vibber brion@pobox.com wrote:
As some may know, we've restricted videos on Wikimedia sites to the freely-licensed Ogg Theora codec for some years, with some intention to support other non-patent-encumbered formats like WebM.
One of our partners in pushing for free formats was Mozilla; Fire fox's HTML5 video supports only Theora and WebM.
The prime competing format, H.264, has potential patent issues - like
other
MPEG standards there's a patent pool and certain licensing rules. It's
also
nearly got an exclusive choke hold on mobile - so much so that Mozilla
is
considering ways to adopt H.264 support to avoid being left behind:
http://blog.lizardwrangler.com/2012/03/18/video-user-experience-and-our-miss...
Is it time for us to think about H.264 encoding on our own videos?
Right now users of millions of mobile phones and tablets have no access
to
our audio and video content, and our old desktop fallback of using a
Java
applet is unavailable.
In theory we can produce a configuration with TimedMediaHandler to
produce
both H.264 and Theora/WebM transcodes, bringing Commons media to life
for
mobile users and Apple and Microsoft browser users.
What do we think about this? What are the pros and cons?
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 03/19/2012 06:24 PM, Brion Vibber wrote:
In theory we can produce a configuration with TimedMediaHandler to produce both H.264 and Theora/WebM transcodes, bringing Commons media to life for mobile users and Apple and Microsoft browser users.
What do we think about this? What are the pros and cons?
-- brion
The point about mobile is very true and its very very difficult to debase entrenched formats, especially when its tied up in hardware support. And of course the Kaltura HTML5 library used in TMH has a lot of iPad and Android H.264 support code in there for all the commercial usage of the library, so it would not be a technical challenge to support it.
But I think we should get our existing TMH out the door exclusively supporting WebM and Ogg. We and can revisit adding support for other formats after that. High on that list is also mp3 support which would have similar benefits for audio versions of articles and mobile hardware support audio playback.
If people felt it was important, By the end of the year we could have javascript based webm decoders for supporting WebM in IE10 ( in case people never saw this: https://github.com/bemasc/Broadway ) But of course this could be seen as <insert your favourite misguided good efforts analogy here>. i.e maybe efforts are better focused on tools streamlining video contribution process.
Maybe we focus on a way to upload h.264 videos from mobile. Of course doing mobile h.264 uploads correctly would ideally include making source content available, for maximising re-usability of content, without the quality loss in multiple encoding passes, so in effect running up against the very principal that governs the Wikimedia projects to make content a freely reusable resources.
I think Mozilla adding /desktop/ h.264 support may hurt free formats. On desktop they already have strong market share, and right now many companies actually request including WebM in their encoding profiles ( on kaltura ) but that of course would not be true if the Mozilla supports h.264 on desktop, and it would make it harder for google chrome to follow through on their promise to only support WebM ( if they still plan on doing that ).
For mobile it makes sense, Mozilla has no market share there and they have to be attractive to device manufactures create a solid mobile user experience, fit within device battery life expectations etc. And on mobile there is no fall back to flash if the site can't afford to encode all their content into free formats and multiple h.264 profiles. And they can't afford that on a that browser / platform that people have to generality /choose /to install and use.
If they support h.264 on desktop it will be a big set back for free formats, because there won't be any incentive for the vast majority of pragmatic sites to support webm.
--michael
Good morning,
after reading all mails in this thread I'd like to comment on this. I care about this topic as I am leading the WikiTV project we started in Germany (http://meta.wikimedia.org/wiki/WikiTV#WikiTV_.28on_demand.29).
I would appreciate to see WebM out soon, I think that is important. So here I agree with Michael - get the TMH released and then add H.264 support later.
What is unclear to me: Do you mean to store all video data in an intermediate format (be it Ogg or WebM or whatever) and then do a realtime encoding based on the browsers preference and capabilities?
From a usability point of view this would be perfect. I wouldn't be
happy if I needed to upload WikiTV shows in three different formats in the future and I think it would also wasting a lot of disk space. Let alone that these files need a developer to actually get imported into Commons from a FTP server we have to host on our end because we can't upload more than 100 MB, which are 80% of our files.
/Manuel
On Mon, Mar 19, 2012 at 6:24 PM, Brion Vibber brion@pobox.com wrote:
As some may know, we've restricted videos on Wikimedia sites to the freely-licensed Ogg Theora codec for some years, with some intention to support other non-patent-encumbered formats like WebM.
One of our partners in pushing for free formats was Mozilla; Fire fox's HTML5 video supports only Theora and WebM.
The prime competing format, H.264, has potential patent issues - like other MPEG standards there's a patent pool and certain licensing rules. It's also nearly got an exclusive choke hold on mobile - so much so that Mozilla is considering ways to adopt H.264 support to avoid being left behind:
http://blog.lizardwrangler.com/2012/03/18/video-user-experience-and-our-miss...
Is it time for us to think about H.264 encoding on our own videos?
Right now users of millions of mobile phones and tablets have no access to our audio and video content, and our old desktop fallback of using a Java applet is unavailable.
In theory we can produce a configuration with TimedMediaHandler to produce both H.264 and Theora/WebM transcodes, bringing Commons media to life for mobile users and Apple and Microsoft browser users.
What do we think about this? What are the pros and cons?
Would we not need to pay royalties to encode from/to h264? I know streaming h264 is allowed royalty-free, but I thought encoding it was not.
- Ryan
On 20 March 2012 01:24, Brion Vibber brion@pobox.com wrote:
In theory we can produce a configuration with TimedMediaHandler to produce both H.264 and Theora/WebM transcodes, bringing Commons media to life for mobile users and Apple and Microsoft browser users. What do we think about this? What are the pros and cons?
No. Just because Mozilla has decided to do the wrong thing for commercial reasons does not somehow compel us to. It's only pressure from users that will get the companies to use unlocked formats.
- d.
David Gerard wrote:
On 20 March 2012 01:24, Brion Vibber brion@pobox.com wrote:
In theory we can produce a configuration with TimedMediaHandler to produce both H.264 and Theora/WebM transcodes, bringing Commons media to life for mobile users and Apple and Microsoft browser users. What do we think about this? What are the pros and cons?
No. Just because Mozilla has decided to do the wrong thing for commercial reasons does not somehow compel us to. It's only pressure from users that will get the companies to use unlocked formats.
I agree with David here, though I'd encourage all parties to think about the issue broadly and in creative ways.
For example, the Wikimedia Foundation has a substantial amount of capital and could theoretically generate more for a specific purpose like this. Would buying the rights to codecs like these be feasible? What kind of cost are we talking about? Are there other solutions that could be considered that don't compromise Wikimedia's values?
I think we can all agree that Ogg sucks. Are there ways to make it suck less?
MZMcBride
On Wed, Mar 21, 2012 at 2:44 AM, MZMcBride z@mzmcbride.com wrote:
I think we can all agree that Ogg sucks. Are there ways to make it suck less?
We don't. Ogg is a nice container. Ogg Vorbis is an awesome audio codec, way better than MP3, especially better on low bitrates. Ogg Theora sucks, that's true.
—vvv
On 20 March 2012 02:24, Brion Vibber brion@pobox.com wrote: ..
In theory we can produce a configuration with TimedMediaHandler to produce both H.264 and Theora/WebM transcodes, bringing Commons media to life for mobile users and Apple and Microsoft browser users.
What do we think about this? What are the pros and cons?
-- brion
H.264 is a propietery format, and the owners can start asking for a tax to encoders, decoders and users.
Wikipedia would not be the "free encyclopedia" if you start asking people money for watching videos :D
What perhaps can be done, withouth hurting the cause of freedom much, is to have the encoder. So if you uploade a propietery h.264 video, its encoded into a free format. You still helps the H.264 to spread, so is not that cool. If the owners of h.264 start asking money to encoders, you can drop support for the format. Nobody is damaged (people sould change habits of what format video to upload).
The problem can be output. What free format a iPhone support?, if the reply is none, then you have to choise no service at all, or output video in h.264. Not serving people is bad, and serving h.264 is bad because you help h.264 gains more ground, hurting the cause of open formats. Theres no good option. IF you can serve a video that a iPhone can watch, even if using some crappy javascript or java format, you avoid pushing h.264 (so you help the cause of free formats). If this solution is slow, you create a incentive for iPhone to support a open format (what is good again), and everyone can watch all videos (what is good again).
On 20 March 2012 09:59, Tei oscar.vives@gmail.com wrote:
What perhaps can be done, withouth hurting the cause of freedom much, is to have the encoder. So if you uploade a propietery h.264 video, its encoded into a free format. You still helps the H.264 to spread, so is not that cool. If the owners of h.264 start asking money to encoders, you can drop support for the format. Nobody is damaged (people sould change habits of what format video to upload).
We should definitely be able to ingest H.264. (This has been on the wishlist forever and is a much harder problem than it sounds.)
The problem can be output. What free format a iPhone support?, if the reply is none, then you have to choise no service at all, or output video in h.264. Not serving people is bad, and serving h.264 is bad because you help h.264 gains more ground, hurting the cause of open formats. Theres no good option. IF you can serve a video that a iPhone can watch, even if using some crappy javascript or java format, you avoid pushing h.264 (so you help the cause of free formats). If this solution is slow, you create a incentive for iPhone to support a open format (what is good again), and everyone can watch all videos (what is good again).
Android supports Theora. The significant holdout is Apple.
- d.
On 03/20/2012 03:15 AM, David Gerard wrote:
We should definitely be able to ingest H.264. (This has been on the wishlist forever and is a much harder problem than it sounds.)
Once TMH is deployed, practically speaking .. upload to youtube -> import to commons .. will probably be the easiest path for a while. Especially given the tight integration youtube has with every phone, and any capture device with web.
But yes the feature should be developed, and it is more difficult then it sounds when you want to carefully consider things like making the source file available.
--michael
Michael Dale wrote:
On 03/20/2012 03:15 AM, David Gerard wrote:
We should definitely be able to ingest H.264. (This has been on the wishlist forever and is a much harder problem than it sounds.)
Once TMH is deployed, practically speaking .. upload to youtube -> import to commons .. will probably be the easiest path for a while. Especially given the tight integration youtube has with every phone, and any capture device with web.
But yes the feature should be developed, and it is more difficult then it sounds when you want to carefully consider things like making the source file available.
Is there any timeline for a deployment of TimedMediaHandler?
MZMcBride
On Tue, Mar 20, 2012 at 8:59 PM, Tei oscar.vives@gmail.com wrote:
The problem can be output. What free format a iPhone support?
This is a good question. Obviously, in hardware it will support only H.264.
In terms of software decoders there is at least one VP8 decoder that will work on ARM processors, though I have no idea if it has been implemented into any iOS apps yet.
Of course that doesn't help anyone trying to watch video in the browser, but support could be implemented into, eg, the Foundation's official Wikipedia app for iOS (unless there are rules against it? I've heard that Apple requires use of HTTP Live Streaming for in-app videos of a certain length?).
Does anyone know if there are any decoders for VP8 or Theora using OpenCL? It seems hard to find solid information on this subject...
On 20 March 2012 10:42, Stephen Bain stephen.bain@gmail.com wrote:
Of course that doesn't help anyone trying to watch video in the browser, but support could be implemented into, eg, the Foundation's official Wikipedia app for iOS (unless there are rules against it?
If Apple tries to stop Wikipedia using VP8 or Theora codecs, that would be something worth making a small fuss over.
- d.
On Tue, Mar 20, 2012 at 5:24 AM, Brion Vibber brion@pobox.com wrote:
Is it time for us to think about H.264 encoding on our own videos?
Hello, Brion.
I think it is time for Apple to support Wikipedia videos. I suggest that we view the thing from this point of view — Apple do not run a Top-10 site, we do.
I would say that running something on Wikimedia servers which requires us to pay royalties seems incompatible to our mission. As far as I understand, that would be required for video transcoding. Same for MP3. Same was for Flash, which we did not use even though there were numerous cases when it was essential (we still cannot upload >100MB files to Commons because of that).
It's not like it is that bad. OGG/WebM are supported by most major browsers, except IE, Safari and their mobile counterparts. Even for the first two, there are codecs available.
—vvv
On Tue, Mar 20, 2012 at 6:13 AM, Victor Vasiliev vasilvv@gmail.com wrote:
On Tue, Mar 20, 2012 at 5:24 AM, Brion Vibber brion@pobox.com wrote:
Is it time for us to think about H.264 encoding on our own videos?
Hello, Brion.
I think it is time for Apple to support Wikipedia videos. I suggest that we view the thing from this point of view — Apple do not run a Top-10 site, we do.
That would be nice but is completely unrealistic. Apple doesn't support Flash and that's on a lot more sites of the world. They don't bow to pressure from major players who could make them $$$, and they are certainly not going to bow to us. Besides, the lack of wikipedia videos does not appear to be hurting their performance.
Apple has a 30% market share for US smart phones[1] and their global tablet share is 58% [2]
Since such a huge market share basically requires H.264 encoding, I think we should bite the bullet and go for it. If suddenly they start charging, we can drop it immediately.
[1] http://www.engadget.com/2012/03/07/comscore-us-subscriber-count-reaches-100-... [2] http://www.engadget.com/2012/01/26/strategy-analytics-apple-still-owns-table...
On Wed, Mar 21, 2012 at 1:47 AM, Leslie Carr lcarr@wikimedia.org wrote:
Since such a huge market share basically requires H.264 encoding, I think we should bite the bullet and go for it. If suddenly they start charging, we can drop it immediately.
Those accessing Wikimedia in the browser, yes.
It does seem to be possible to support alternative codecs in software within apps. Here is one example:
http://itunes.apple.com/us/app/id406779775
VLC player also used to be available though it was pulled due to a clash between the code's GPL license and the App Store terms of service, it seems:
http://www.macnn.com/articles/11/01/07/move.said.to.be.related.to.licensing....
It would seem possible to bake Theora or WebM support into the iOS app and direct users there if browsing from mobile Safari. Performance would not be so great given it would only be software decoding (this is why I was asking if anyone is aware of OpenCL decoders).
On 20 March 2012 16:26, Stephen Bain stephen.bain@gmail.com wrote: ...
It would seem possible to bake Theora or WebM support into the iOS app and direct users there if browsing from mobile Safari. Performance would not be so great given it would only be software decoding (this is why I was asking if anyone is aware of OpenCL decoders).
This sounds sweet.
Youtube also works somewhat like that: wen you want to see a youtube video link, the youtube app opens. It may make sense for a iOS user to have a wikipedia video opening the wikipedia app. I have heard that the wikipedia app is rather good, too. :DD
On Tue, Mar 20, 2012 at 9:08 AM, Tei oscar.vives@gmail.com wrote:
It would seem possible to bake Theora or WebM support into the iOS app and direct users there if browsing from mobile Safari. Performance would not be so great given it would only be software decoding (this is why I was asking if anyone is aware of OpenCL decoders).
If anyone wants to take this on then do let know. Were about to push a brand new code base for the app so poke us on #wikimedia-mobile for pointers.
--tomasz
On 03/20/2012 02:24 AM, Brion Vibber wrote:
The prime competing format, H.264, has potential patent issues - like other MPEG standards there's a patent pool and certain licensing rules. It's also nearly got an exclusive choke hold on mobile - so much so that Mozilla is considering ways to adopt H.264 support to avoid being left behind:
http://blog.lizardwrangler.com/2012/03/18/video-user-experience-and-our-miss...
Is it time for us to think about H.264 encoding on our own videos?
Right now users of millions of mobile phones and tablets have no access to our audio and video content,
Which are the patents and when do they expire? Which are the platforms that don't support Theora, and what stops them? Maybe we should flood Wikipedia's most visited articles with videos, so millions of users will be made aware that the makers of their equipment (Apple iPad?) should support open formats.
Now, if we were to take this path, how do we flood Wikipedia with videos? Live interviews in all biographies of living people? If this turns out to be completely unrealistic, because we can't produce videos in sufficient quantity, then maybe the time is not yet mature for video in Wikipedia.
I thought it was so 2-3 years ago, but I was wrong. I started this table, http://commons.wikimedia.org/wiki/Category_talk:Videos_by_country and there are now 12 videos in "Videos from Denmark", up from 2 in 2009 and 3 in 2011. But it hasn't exploded into the hundreds or thousands. (If you know of more videos that should be in these categories, please help with categorization!)
I think it would be a great help if I could upload any video format to Wikimedia Commons, and it would be converted to Theora on the server side. Then contributors would only need to be experts on shooting the video, and not on running all the Linux commands to convert between formats.
Hej Lars,
On 03/20/2012 03:03 PM, Lars Aronsson wrote:
Now, if we were to take this path, how do we flood Wikipedia with videos? Live interviews in all biographies of living people? If this turns out to be completely unrealistic, because we can't produce videos in sufficient quantity, then maybe the time is not yet mature for video in Wikipedia.
http://meta.wikimedia.org/wiki/WikiTV http://de.wikipedia.org/wiki/Wikipedia:WikiTV http://commons.wikimedia.org/wiki/Category:WikiTV_%28DE%29 http://wikimania2012.wikimedia.org/wiki/Submissions/WikiTV
;-)
/Manuel
On Tue, 20 Mar 2012 07:03:06 -0700, Lars Aronsson lars@aronsson.se wrote:
On 03/20/2012 02:24 AM, Brion Vibber wrote:
The prime competing format, H.264, has potential patent issues - like other MPEG standards there's a patent pool and certain licensing rules. It's also nearly got an exclusive choke hold on mobile - so much so that Mozilla is considering ways to adopt H.264 support to avoid being left behind:
http://blog.lizardwrangler.com/2012/03/18/video-user-experience-and-our-miss...
Is it time for us to think about H.264 encoding on our own videos?
Right now users of millions of mobile phones and tablets have no access to our audio and video content,
Which are the patents and when do they expire? Which are the platforms that don't support Theora, and what stops them? Maybe we should flood Wikipedia's most visited articles with videos, so millions of users will be made aware that the makers of their equipment (Apple iPad?) should support open formats.
Now, if we were to take this path, how do we flood Wikipedia with videos? Live interviews in all biographies of living people? If this turns out to be completely unrealistic, because we can't produce videos in sufficient quantity, then maybe the time is not yet mature for video in Wikipedia.
Anyone have a good stockpile of old Public Domain movies? I believe there are also at least two freely licensed movies. Everyone is using Blender's CC-BY "Big Buck Bunny" for <video> demos. And I believe there was another film that was openly distributed using .torrents. How about embedding full movies into the articles into the Wikipedia articles about the movies when said movie is a freely licensed modern movie or a Public Domain film?
I thought it was so 2-3 years ago, but I was wrong. I started this table, http://commons.wikimedia.org/wiki/Category_talk:Videos_by_country and there are now 12 videos in "Videos from Denmark", up from 2 in 2009 and 3 in 2011. But it hasn't exploded into the hundreds or thousands. (If you know of more videos that should be in these categories, please help with categorization!)
I think it would be a great help if I could upload any video format to Wikimedia Commons, and it would be converted to Theora on the server side. Then contributors would only need to be experts on shooting the video, and not on running all the Linux commands to convert between formats.
On 20.03.2012 20:29, Daniel Friesen wrote:
On Tue, 20 Mar 2012 07:03:06 -0700, Lars Aronsson lars@aronsson.se wrote:
On 03/20/2012 02:24 AM, Brion Vibber wrote:
The prime competing format, H.264, has potential patent issues - like other MPEG standards there's a patent pool and certain licensing rules. It's also nearly got an exclusive choke hold on mobile - so much so that Mozilla is considering ways to adopt H.264 support to avoid being left behind:
http://blog.lizardwrangler.com/2012/03/18/video-user-experience-and-our-miss...
Is it time for us to think about H.264 encoding on our own videos?
Right now users of millions of mobile phones and tablets have no access to our audio and video content,
Which are the patents and when do they expire? Which are the platforms that don't support Theora, and what stops them? Maybe we should flood Wikipedia's most visited articles with videos, so millions of users will be made aware that the makers of their equipment (Apple iPad?) should support open formats.
Now, if we were to take this path, how do we flood Wikipedia with videos? Live interviews in all biographies of living people? If this turns out to be completely unrealistic, because we can't produce videos in sufficient quantity, then maybe the time is not yet mature for video in Wikipedia.
Anyone have a good stockpile of old Public Domain movies? I believe there are also at least two freely licensed movies. Everyone is using Blender's CC-BY "Big Buck Bunny" for <video> demos. And I believe there was another film that was openly distributed using .torrents. How about embedding full movies into the articles into the Wikipedia articles about the movies when said movie is a freely licensed modern movie or a Public Domain film?
Are these PD? There are quite a lot of them. http://www.archive.org/details/movies Dmitriy
On 20 March 2012 15:03, Lars Aronsson lars@aronsson.se wrote: ..
Now, if we were to take this path, how do we flood Wikipedia with videos? Live interviews in all biographies of living people? If this turns out to be completely unrealistic, because we can't produce videos in sufficient quantity, then maybe the time is not yet mature for video in Wikipedia.
Perhaps if you allow uploading video to articles. All these "Small City Wikipedia Page" will have a short clip of the Main Street made with a movil phone. The 'technical' quality of the video will not very high... until the wiki effect quicks-in, and a new better video replace it. Everybody have a camera in his pocket, in 2012.
On 03/20/2012 05:40 PM, Tei wrote:
Perhaps if you allow uploading video to articles. All these "Small City Wikipedia Page" will have a short clip of the Main Street made with a movil phone. The 'technical' quality of the video will not very high... until the wiki effect quicks-in, and a new better video replace it. Everybody have a camera in his pocket, in 2012.
I love it! Wiki Loves Main Street, the new video competition. There are alread a couple of videos of journeys along streets, perhaps we should gather them under a new category,a subcategory to http://commons.wikimedia.org/wiki/Category:Videos_of_road_traffic
Since a "road movie" is something else, perhaps "street video"? Should we use subtitles to geo tag these videos?
Here are some from Stockholm: http://commons.wikimedia.org/wiki/File:Karlaplan-2011-04-16.ogv http://commons.wikimedia.org/wiki/File:Karlav%C3%A4gen-2011-04-16.ogv http://commons.wikimedia.org/wiki/File:Sibyllegatan-2011-04-16.ogv http://commons.wikimedia.org/wiki/File:Strandv%C3%A4gen-2011-04.ogv
On 20 March 2012 01:24, Brion Vibber brion@pobox.com wrote:
In theory we can produce a configuration with TimedMediaHandler to produce both H.264 and Theora/WebM transcodes, bringing Commons media to life for mobile users and Apple and Microsoft browser users. What do we think about this? What are the pros and cons?
This is too big an issue to resolve only on the tech list - I've forwarded your message to foundation-l as well.
- d.
Thanks for bringing this up, Brion. I've been hoping we could have this conversation for a while now.
Before coming to WMF, I worked for a number of years as a broadcast engineer for a fairly popular video site. So, I've researched this in some depth. Here's a summary.
First, let's talk about the technical difference between the codecs as it pertains to this discussion:
* h.264 is clearly the best from a technical standpoint. The encoder itself has features that aren't present in the others. Also, it's been on the market longer so implementations are more highly optimized. There's specific hardware support in a lot of devices, and GPU-accelerated decode support in a lot of software. h.264 was developed by a number of companies as an "open" standard, but is covered by many patents.
* WebM (aka VP8) is really not bad, but is technically inferior to h.264 Main and High Profiles[1]. It's a modern codec, but being newer doesn't make it better. That said, it's close enough to h.264 that the quality difference isn't worth being concerned about. It was developed in a closed fashion by a single company (ON2), which was then acquired by Google, who open-licensed it.
* Theora is old, and technically inferior. It can encode video of the same quality as h.264 or WebM, but it requires more than twice the bitrate to do it[2]. Client support is poor. Hardware decoders are less important because the lower complexity means it decodes pretty quick.
Now, let's talk about the issues:
Licensing is an issue with h.264. The ways we might be subject to license terms are by serving content, and by distributing an encoder (as part of Mediawiki)[3]. We can escape the second easily by not distributing the actual encoder (libx264). We would probably need to obtain a license for serving video, but MPEG-LA has said that no-cost video distribution will be royalty-free until at least 2015, possibly longer.
Licensing may or may not be an issue with WebM. It's been alleged that WebM infringes some of the h.264 patents. This might be true, or it might be MPEG-LA's butthurt hyperbole. I'm not enough of an expert on codecs or IP to know. Google assures us that everything is fine, but they also have a significant stake in everything being fine. It's impossible to trust any of the companies involved, so I go with Jason from [1] who says it may be an issue. Until this has been litigated, we should keep in mind that things could change for WebM.
Theora is as patent-free as any other technology. It's possible somebody's patents cover it, but if we worry about Theora, we've forsaken the entire idea of patent-freedom. However, the bandwidth cost per video served with Theora is much higher. Let's be clear about that: Theora is currently the only codec that actually costs us more money to use.
Here's what I think we should do:
Let's distribute h.264 for the next three years, alongside WebM and Theora. Use the free formats whenever possible, and switch to h.264 when necessary.
Let's not make the h.264 files readily downloadable. Rather, include a disclaimer explaining that redistribution could subject the user to MPEG-LA's licensing requirements, and wouldn't you prefer this lovely WebM file instead?
This gets us good video distribution now, which helps to fulfill our primary goal: making knowledge available to everyone.
If MPEG-LA decides to start charging for Internet video in 2015, we can turn off h.264 then. People will lose access to video content, but they're people who'd have never had that access before. Also, it makes a statement that people will be a lot more likely to notice.
Doing it this way will give the WebM infrastructure a bit more time to catch up. Hopefully by 2015 it'll be supported broadly enough that the Internet won't be so dependent on h.264.
An argument can be made that our lack of h.264 support will drive WebM adoption, but the mechanism there isn't clear to me. While we're big, we aren't much of a player in the streaming video space right now. It seems like we're facing a classic chicken-and-egg problem: without a broadly supported codec, how do we collect and distribute videos, and without lots of videos, how do we influence the codec market? Note that YouTube is still pushing lots of h.264.
The costs of doing it this way are:
* Additional encoding resources to make the h.264 files. * Additional disk space for storing those files * Reduced bandwidth costs when serving smaller files * ... but increased bandwidth costs since more people will actually watch videos, because they'll work.
As far as a plan goes, I agree with Michael: deploy TMH in the state it's in (WebM and Theora), get the bugs in transcoding and serving video worked out, then add in h.264 when that's done.
References: 1: "The first in-depth technical analysis of VP8" http://x264dev.multimedia.cx/archives/377 2: "Video Encoder Comparison" http://keyj.emphy.de/video-encoder-comparison/ 3: "Summary of AVC license terms" http://www.mpegla.com/main/programs/avc/Documents/AVC_TermsSummary.pdf
-Ian
On Mon, Mar 19, 2012 at 6:24 PM, Brion Vibber brion@pobox.com wrote:
As some may know, we've restricted videos on Wikimedia sites to the freely-licensed Ogg Theora codec for some years, with some intention to support other non-patent-encumbered formats like WebM.
One of our partners in pushing for free formats was Mozilla; Fire fox's HTML5 video supports only Theora and WebM.
The prime competing format, H.264, has potential patent issues - like other MPEG standards there's a patent pool and certain licensing rules. It's also nearly got an exclusive choke hold on mobile - so much so that Mozilla is considering ways to adopt H.264 support to avoid being left behind:
http://blog.lizardwrangler.com/2012/03/18/video-user-experience-and-our-miss...
Is it time for us to think about H.264 encoding on our own videos?
Right now users of millions of mobile phones and tablets have no access to our audio and video content, and our old desktop fallback of using a Java applet is unavailable.
In theory we can produce a configuration with TimedMediaHandler to produce both H.264 and Theora/WebM transcodes, bringing Commons media to life for mobile users and Apple and Microsoft browser users.
What do we think about this? What are the pros and cons?
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 03/20/2012 08:06 PM, Ian Baker wrote:
An argument can be made that our lack of h.264 support will drive WebM adoption, but the mechanism there isn't clear to me. While we're big, we aren't much of a player in the streaming video space right now. It seems like we're facing a classic chicken-and-egg problem: without a broadly supported codec, how do we collect and distribute videos, and without lots of videos, how do we influence the codec market? Note that YouTube is still pushing lots of h.264.
I'm not opposed to trying H.264, but I doubt it will solve our problem, which is that we have too few videos.
The category:Videos from Sweden (an early adopter market) is now at 110 files, which is a ridiculously small number. It has doubled each year (30 in 2010, 52 in 2011), but that growth is too slow to reach any significant numbers in the next 2-3 years. I don't see that lack of H.264 playback is slowing this down, that mechanism isn't clear to me.
I think that converting whatever comes out of my camera into something that Commons will accept is part of the problem. This does not imply that H.264 needs to be stored on Commons, only that whatever is uploaded gets converted by the server rather than by the user before upload.
The biggest obstacle, however, I think is that people aren't used to work creatively with a video camcorder, not the way they work with a still camera, taking events from different angles, in different light, with different aperture or focus. It might be that video requires more specialization, including script-writing and sound editing, and that we should hope for a few specialized, highly productive contributors of video (like that German WikiTV project, or a team driving around capturing streets of every local town), rather than the everybody-can-contribute approach we have taken to still photography and text editing.
I was hoping that we would organize video competitions, but I have held back, because I don't see any crowd with camcorders in their hands. Now, if we get there in 2013 or 2014, and then discontinue H.264 playback in 2015, we could be in for a real backlash.
On 20 March 2012 20:02, Lars Aronsson lars@aronsson.se wrote:
I'm not opposed to trying H.264, but I doubt it will solve our problem, which is that we have too few videos. The category:Videos from Sweden (an early adopter market) is now at 110 files, which is a ridiculously small number. It has doubled each year (30 in 2010, 52 in 2011), but that growth is too slow to reach any significant numbers in the next 2-3 years. I don't see that lack of H.264 playback is slowing this down, that mechanism isn't clear to me. I think that converting whatever comes out of my camera into something that Commons will accept is part of the problem. This does not imply that H.264 needs to be stored on Commons, only that whatever is uploaded gets converted by the server rather than by the user before upload.
Yes. That's the biggest barrier to participation. We need to be able to ingest whatever comes out of people's cameras.
I was hoping that we would organize video competitions, but I have held back, because I don't see any crowd with camcorders in their hands. Now, if we get there in 2013 or 2014, and then discontinue H.264 playback in 2015, we could be in for a real backlash.
This is an excellent argument against making ourselves hostage to the MPEG-LA. Giving people like that any leverage over Wikimedia strikes me as a *spectacularly* awful idea.
(foundation-l added to cc: - changing the encumbered formats policy is not a matter to be quietly decided over on a tech list.)
- d.
On 20 March 2012 19:06, Ian Baker ian@wikimedia.org wrote:
- WebM (aka VP8) is really not bad, but is technically inferior to h.264
Main and High Profiles[1].
This comparison appears specious in the context of this thread, which is the iPhone - the iPhone (which is the context of this thread) doesn't support Main or High, only Baseline.
How does VP8 compare to H.264 Baseline profile?
(Up to 640x480, 'cos the iPhone doesn't go any higher of course. Is the proposal to limit Wikimedia video to 640x480 as well, for the mobile market?)
- d.
On Tue, Mar 20, 2012 at 3:38 PM, David Gerard dgerard@gmail.com wrote:
On 20 March 2012 19:06, Ian Baker ian@wikimedia.org wrote:
- WebM (aka VP8) is really not bad, but is technically inferior to h.264
Main and High Profiles[1].
This comparison appears specious in the context of this thread, which is the iPhone - the iPhone (which is the context of this thread) doesn't support Main or High, only Baseline.
How does VP8 compare to H.264 Baseline profile?
Good point. VP8 is pretty similar to h.264 Baseline. I'd be surprised if even a person with considerable digital video experience would notice the difference.
However, in the context of the iPhone, there's no good way to play VP8. Even if the software problem were solved, the lack of a hardware decoder means it'd completely destroy the battery life.
For our purposes, encoding files with Main or High profiles could be used to drop the bitrate without compromising quality, thereby saving bandwidth. It's not a huge difference, though, and I don't think we'd bother. As I said, VP8 and h.264 are mostly interchangeable from a technical standpoint. I brought it up to debunk the notion that because VP8 is newer, that automatically makes it better.
But... there are other platforms that have a crappy video playback experience with WebM or Theora. I don't think this thread is just about the iPhone, though mobile is certainly the hardest problem to solve here.
We've also been talking about h.264 ingest, which is completely different and arguably more important. There are millions of HD camcorders wandering the world inside people's phones, which are also reasonably capable video editing platforms. We could be taking advantage of that.
-Ian
On 20 March 2012 23:00, Ian Baker ian@wikimedia.org wrote:
We've also been talking about h.264 ingest, which is completely different and arguably more important. There are millions of HD camcorders wandering the world inside people's phones, which are also reasonably capable video editing platforms. We could be taking advantage of that.
That we definitely need. We need to be able to take in anything that comes out of people's cameras.
It's storing and serving it that's going to be problematic. Imagine the deletionfest on Commons ...
- d.
On Tue, Mar 20, 2012 at 4:00 PM, Ian Baker ian@wikimedia.org wrote:
Good point. VP8 is pretty similar to h.264 Baseline. I'd be surprised if even a person with considerable digital video experience would notice the difference.
However, in the context of the iPhone, there's no good way to play VP8. Even if the software problem were solved, the lack of a hardware decoder means it'd completely destroy the battery life.
For our purposes, encoding files with Main or High profiles could be used to drop the bitrate without compromising quality, thereby saving bandwidth. It's not a huge difference, though, and I don't think we'd bother. As I said, VP8 and h.264 are mostly interchangeable from a technical standpoint. I brought it up to debunk the notion that because VP8 is newer, that automatically makes it better.
*nod* for our purposes even Theora is "good enough" to put pretty pictures on the screen; we're not super concerned with the ideal codec, as much as making sure that people can actually get access to the media files we have -- the binary "works" / "doesn't work" is more important.
But... there are other platforms that have a crappy video playback
experience with WebM or Theora. I don't think this thread is just about the iPhone, though mobile is certainly the hardest problem to solve here.
Even my Galaxy Nexus running fancy schmancy Android 4.0 with WebM support isn't a good target for actually playing WebM videos. I did a quick test with 640x360 and 1280x720 versions of a quick throwaway clip:
http://leuksman.com/misc/vid-tests/
The quality of the video files is not likely to be particularly good as I made no attempt to tune them well, just to check what played at all.
The *only* mobile device I tested that played the 720p WebM video was my Galaxy Nexus, but verrrrry slowly and jerkily -- it's clearly not optimized or accelerated very well. The H.264 video at same resolution runs silky smooth. The smaller 640x360 WebM video runs ok, but is of course blurrier being a quarter the pixels. Only Firefox seems to run the Theora files -- the stock Android browser doesn't, nor does Opera Mobile. Nor, oddly, does Firefox run WebM files (though in theory it ought to...?)
Tested with devices handy:
Nexus One (Android 2.3.6; 800x480 screen) * Browser - only h.264 works; can't play 720p * Opera Mobile - only h.264 works; can play 720p * Firefox - only Theora works; kinda slow
Galaxy Tab 10.1 (Android 3.2; 1280x800 screen) * Browser - only h.264 works
Galaxy Nexus (Android 4.0; 1280x720 screen) * Browser - h.264 works; WebM runs but is very slow at 720p; no Theora
Kindle Fire (Android 2.3.4 custom; 1024x600 screen) * Silk Browser - only h.264 works
Blackberry PlayBook (Tablet OS 2.0; 1024x600 screen) * Browser - only h.264 works
iPod Touch (iOS 5.1; 960x640 screen) * Safari - only h.264 works
iPad 3rd-gen (iOS 5.1; 2048x1536 screen) * Safari - only h.264 works
Dell Inspiron Duo tablet (Win8 consumer preview; 1366x768 screen) * IE 10 - only h.264 works
It's looking pretty bleak for anything but h.264 on the mobile front (phones & tablets). :P
We've also been talking about h.264 ingest, which is completely different
and arguably more important. There are millions of HD camcorders wandering the world inside people's phones, which are also reasonably capable video editing platforms. We could be taking advantage of that.
Agreed; accepting incoming video in h.264 will be a must.
-- brion
*nod* for our purposes even Theora is "good enough" to put pretty pictures on the screen; we're not super concerned with the ideal codec, as much as making sure that people can actually get access to the media files we have -- the binary "works" / "doesn't work" is more important.
That's a good point. All things being equal, Theora would be more bandwidth-hungry, but thinking about that now probably counts as premature optimization. :)
Regarding web browsers: our most popular browser, sadly, is IE8. IE9, IE7, and Firefox 3.6 are all still in the top 10 with really significant numbers of pageviews. I think all these browsers will work with Cortado, though, which is one of the TMH player options.
So, on the web we could probably get away with doing free-codec-only playback, at the expense of a lower-quality experience for IE9 and Safari users (which total around 10% of traffic, or about 2 billion pageviews per month).
For mobile, I can't imagine this fixing itself all that quickly. As your tests show, good WebM playback isn't solvable in software on most of the current generation of handsets. People will need to buy new devices to make it really work.
Quick link to the traffic stats: http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm
-Ian
On 21 March 2012 22:04, Ian Baker ian@wikimedia.org wrote:
Regarding web browsers: our most popular browser, sadly, is IE8. IE9, IE7, and Firefox 3.6 are all still in the top 10 with really significant numbers of pageviews. I think all these browsers will work with Cortado, though, which is one of the TMH player options.
Tim says the TMH code isn't up to production use, and TMH has been in the works for months or years - and as I understand it, VP8 uploads were blocked on TMH. Is all this the case?
- d.
On Wed, Mar 21, 2012 at 3:16 PM, David Gerard dgerard@gmail.com wrote:
Tim says the TMH code isn't up to production use, and TMH has been in the works for months or years - and as I understand it, VP8 uploads were blocked on TMH. Is all this the case?
TMH has been reviewed by Ian and NeilK extensively, with lots of changes made by Michael Dale. Review notes and Michael's follow-up here: http://www.mediawiki.org/wiki/TimedMediaHandler/ReviewNotes
Currently being tested, including transcoding support, here: http://commons.wikimedia.beta.wmflabs.org/wiki/File:Electric_sheep.webm (slow as hell right now for some reason)
Another security/architecture review before deployment would be wise, but it's not in the same state it was in a few months ago. And yes, this is a blocker for WebM.
On Wed, Mar 21, 2012 at 3:04 PM, Ian Baker ian@wikimedia.org wrote:
For mobile, I can't imagine this fixing itself all that quickly. As your tests show, good WebM playback isn't solvable in software on most of the current generation of handsets. People will need to buy new devices to make it really work.
Support for encumbered formats is a Board-level policy issue. Parallel distribution in h.264 on mobile would be in contravention of the guidance I got from the Board regarding free file formats the last time I floated parallel distribution in proprietary codecs with them (there's no formal resolution on it, IIRC). It's a highly specialized use case with a unique justification, but we'd have to at least seek the Board's acquiescence if we want to consider it for smartphone video usage.
If someone wants to write up a memo with pros/cons of targeting that smartphone h264 support, that would be helpful in case we want to move this to Board-level reviews.
On 03/21/2012 03:42 PM, Ian Baker wrote:
If someone wants to write up a memo with pros/cons of targeting that smartphone h264 support, that would be helpful in case we want to move this to Board-level reviews.
I'd be into helping out with this. Does anyone want to work on it with me?
I would be happy to help with this as well.
--michael
On Wednesday, March 21, 2012, Ian Baker ian@wikimedia.org wrote:
If someone wants to write up a memo with pros/cons of targeting that smartphone h264 support, that would be helpful in case we want to move this to Board-level reviews.
I'd be into helping out with this. Does anyone want to work on it with
me?
I've started some notes at http://meta.wikimedia.org/wiki/Mobile_video_codec_policy please feel free to edit it viciously!
-- brion
On 3/22/12, Brion Vibber brion@pobox.com wrote:
Even my Galaxy Nexus running fancy schmancy Android 4.0 with WebM support isn't a good target for actually playing WebM videos. I did a quick test with 640x360 and 1280x720 versions of a quick throwaway clip:
...
The *only* mobile device I tested that played the 720p WebM video was my Galaxy Nexus, but verrrrry slowly and jerkily -- it's clearly not optimized or accelerated very well.
Similar story on my Nexus S, also running ICS. The 360p works fine, the 720p is a slideshow.
Though, given the screen is only 800x480, the 720p wouldn't have been terribly useful for me anyway. Which raises the question: do we need to support anything above "good enough" resolution?
Amongst the Android install base [1] 3.3% of devices are tablets, 0.4% are Galaxy Nexi (those at API level 14 - level 15 is the Nexus S and some other ports), and some small fraction of the Gingerbread installs will be handsets such as the Galaxy S II which also has a 720p screen. So the number of devices able to take advantage of higher resolutions is exceedingly small. Of course more handsets with such high resolution are coming to market all the time, but they are also bringing faster CPUs (and GPUs, which can be used for acceleration).
The Android YouTube app (and the widget in the browser if supported) has only just changed to streaming up to 720p for everyone, until this month it would max out at 480p for anything but tablets and devices running ICS. And I think that's more to do with the quality settings Google uses for its 480p transcodes. As I understand it the situation is the same for other video-oriented apps such as Netflix.
Obviously there are a greater number of iOS devices out there with higher resolution, but surely the horsepower is there to GPU accelerate WebM at a reasonable resolution?
Note that though native WebM streaming is only available in ICS, native WebM playback has been included since Gingerbread. That's two-thirds of the install base that can play it out of the box (though not in the browser), up from one third six months ago.
-- [1] http://developer.android.com/resources/dashboard/platform-versions.html
On Tuesday, March 20, 2012, David Gerard dgerard@gmail.com wrote:
On 20 March 2012 19:06, Ian Baker ian@wikimedia.org wrote:
- WebM (aka VP8) is really not bad, but is technically inferior to h.264
Main and High Profiles[1].
This comparison appears specious in the context of this thread, which is the iPhone - the iPhone (which is the context of this thread) doesn't support Main or High, only Baseline.
How does VP8 compare to H.264 Baseline profile?
(Up to 640x480, 'cos the iPhone doesn't go any higher of course. Is the proposal to limit Wikimedia video to 640x480 as well, for the mobile market?)
The iPhone 4s can play 1080p videos according to specs (scaled down to fit 960x640 of course). Several high-end phones now have 720p screens, and are happy to play matching media. Tablets running related operating systems have screen resolutions running from 1024x600 to 2048x1536. Other phones with smaller screens, or on slow networks, might prefer to consume smaller files.
TimedMediaHandler provides us the ability to generate transcodes at several suitable sizes/bit rates. This is par for the course for video upload sites, and simply brings us into line with standard industry practice. We would already, per plan, be producing both smaller SD and larger HD files.
We can also produce Theora, WebM, *and* h.264 versions, or some subset thereof, though additional formats mean more disk space and more transcode time on upload.
But on a lot of devices, h.264 is the only realistic playback option. Java's not available, JavaScript's not fast enough on little ARM CPUs. A dedicated app might work (using more battery due to limited acceleration) but would require additional installation with no benefit to the end-user, who has already paid the patent license for the h.264 decoder in their device as part of its price.
Our commitment to user freedom means we need to use patent-unencumbered formats so *anyone* can use our stuff, including those on free platforms who may not have a licensed h.264 decoder. The idea isn't actually to *limit* our users to only free platforms. I think we do need to consider reach and user experience here.
-- brion
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Brion Vibber wrote:
As some may know, we've restricted videos on Wikimedia sites to the freely-licensed Ogg Theora codec for some years, with some intention to support other non-patent-encumbered formats like WebM.
Any thoughts on http://jplayer.org/?
MZMcBride
On 20/03/12 12:24, Brion Vibber wrote:
Is it time for us to think about H.264 encoding on our own videos?
I'm a pragmatist on these kinds of issues. I support transcoding from free formats to patent-encumbered formats if it means that we can more effectively meet our educational goals. That includes paying license fees, as long as they are affordable.
In theory we can produce a configuration with TimedMediaHandler to produce both H.264 and Theora/WebM transcodes, bringing Commons media to life for mobile users and Apple and Microsoft browser users.
Last time I looked at it, TimedMediaHandler had some code quality issues.
-- Tim Starling
wikitech-l@lists.wikimedia.org