FLOSS Codecs Emerge Victorious In Wikimedia Vote 235
An anonymous reader writes "Michael Maggs from the Wikimedia Foundation's multimedia team has given a final summary of the discussion and vote about whether to support MP4 video or not. Twice as many people voted against adding MP4 to Wikimedia than voted for full support. Now they can get back to their mission of advocating openness. 'Those opposing MP4 adoption believe that in order for what we create to be truly free, the format that it is in also needs to be free, (else everyone viewing it would need to obtain a patent license in some form to be able to view it). ... From that viewpoint, any software infrastructure in Wikimedia projects must adhere to community norms regarding intellectual property, patent status, licensing or encoding methods. Current community requirements are that free/open standards should be used at all times to encode and store video files on the servers that house our data, so that both our content and software can be redistributed without any restrictions. Proprietary video containers or codecs such as MP4 are not allowed on Wikimedia projects because they are patent-encumbered and their software cannot be re-licensed freely (though MP4 content can be freely re-licensed).'"
Need clarification (Score:2)
Is that true? What does he mean by "re-license" in relation to the content of an MP4? (Or maybe I should ask what he means by "content".)
How does the MP4 codec have anything to do with the license regarding the content of an MP4 file?
Re:Need clarification (Score:5, Informative)
Re: (Score:3, Insightful)
Re: (Score:2)
OK, thanks.
Why does Wikimedia hate batteries? (Score:2, Insightful)
Mobile devices have efficient hardware support for codecs like H.264, and using something else takes a toll on battery life.
Re:Why does Wikimedia hate batteries? (Score:5, Insightful)
Freedom isn't free.
Re:Why does Wikimedia hate batteries? (Score:5, Insightful)
And?
Wikimedia is concerned (IIRC) with building a library of content that freely accessible and sharable in perpetuity, I'd say that mission trumps catering to current-gen device users. How many hours per day did you say you spent watching wikimedia videos on your phone? The device manufacturers are after all free to implement hardware decoders for open codecs as well, and unlike H.264 they don't even need to pay any royalty fees to do so.
The geek has no leverage here, (Score:2)
The device manufacturers are after all free to implement hardware decoders for open codecs as well, and unlike H.264 they don't even need to pay any royalty fees to do so.
The thirty H.264 licensors are for the globally dominant players in digital video and so are paying royalties to themselves. We are talking pennies or fractions of a penny per unit here for a cartel the size of Mitsubishi.
There is an enterprise cap on H.264 royalties.
There are 1,300 H.264 licensees --- each fabulously wealthy in their own right --- and each with a commitment to H.264 that extends far beyond the web.
AVC/H.264 Licensees [mpegla.com]
The numbers game:
Disney's Frozen "Let It Go" Sequence Performed by Id [youtube.com]
Re: (Score:2)
If Android requires it as a supported format you can bet the SOCs will start having support for it. In fact several already do. Then there is the fact that as GPUs become programmable the hardware codec support ends up being a piece of firmware which could be done for another codec by a software programmer with access to the hardware specs.
Re: (Score:2)
The hit isn't a very big one:
"with the hardware offload the battery lasted up to 36% longer"
http://blog.webmproject.org/20... [webmproject.org]
And with each faster processor generation, the difference gets smaller and smaller still.
Re: (Score:2)
36% is a pretty big difference, especially when streaming video by the hour.
Re: (Score:2)
That was the max, not typical/average, and I seriously doubt the average user will notice. Yes, it makes a difference if you're watching movies non-stop while taking a long flight, but people generally don't take just enough battery power along to squeak by, so the difference won't register too much.
Re: (Score:2)
The hit isn't a very big one:
"with the hardware offload the battery lasted up to 36% longer"
http://blog.webmproject.org/20... [webmproject.org]
And with each faster processor generation, the difference gets smaller and smaller still.
Followed the link but couldn't see where it showed actual power consumption of the hardware decoder they used (their own I guess?) but given that an ARM CPU might consume around 500mW [virginia.edu] whereas an H.264 hardware decoder doing HD uses 10mW [imgtec.com], either the screen is using a huge amount of power or their hardware leaves a bit to be desired.
Re: (Score:2)
You have to follow one whole link to find out:
"The logic consumes less than 25 milliwatts of power for 1080p video decoding and less than 5 milliwatts for 480p (TSMC65nm LP)"
That has ALWAYS been the case, and I don't know why you're surprised. Back to the very first laptops, back-light power draw absolutely dominates power consump
Re:Why does Wikimedia hate batteries? (Score:5, Informative)
All major ARM chipset manufacturers have committed to including the VP9 hardware codec. [techcrunch.com] My Nexus 5 already has the VP8. Soon even the $40 tablet will have it. The license is free, the hardware design is free, so there should be no problem including this high-value IP.
These new hardware partners include ARM, Broadcom, Intel, LG, Marvell, MediaTek, Nvidia, Panasonic, Philips, Qualcomm, RealTek, Samsung, Sigma, Sharp, Sony and Toshiba.
Re:Why does Wikimedia hate batteries? (Score:4, Funny)
Re: (Score:2)
The format isn't designed so that it can degrade gracefully, allowing lower-performing decoders to ignore/skip over functionality that they cannot support, resulting in a less detailed output?
Re: (Score:2)
Nope, they just crash, lag, or play it with severe artifacts (the latter happens with some hardware codecs and 10bit files).
Basically no modern video codecs are designed to gracefully degrade given limited decoder features, because they rely on bit-perfect output to be used as a reference for future frames. Any error accumulates in the decoding loop and becomes significant artifacting until the next I frame.
How it happened: very encouraging for anti-swpat (Score:5, Insightful)
There was an initial surge of pro-mpeg votes by people connected to the WikiMedia Foundation and the technical team which would have been implementing it, then there were many days of mostly anti-mpeg voting when normal Wikipedia contributors heard about this idea.
As someone who has been campaigning for many years against software patents, it was very encouraging to see that the general Wikipedia populous (i.e. after the initial pro-mpeg surge from employees and pre-briefed technicians) was two-thirds against the use of patented formats.
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
But it's a bit different if the video was taken on a mobile device. Here, the "editing" part might have been much quicker (just a few clippings with the built-in app), and very few codecs might be available.
So it's not really about decodi
Explanation of lack of video.... (Score:3)
It's not absurd at all if you think about the different workflows that could be used.
The AC's choice of the word "absurd" may be a mild hyperbole (if you pardon the oxymoron), but it certainly fails the Occam's Razor test. Which is more likely: that Wikipedia's editors aren't into videos, or that WP's editors really love video editing but don't understand transcoding?
The best explanation for the lack of video in Wikimedia Commons is that it's heavily tied to Wikipedia, and web video simply isn't compatible with the way Wikipedia works. You can't re-edit videos ad infinitum the way you can e
Re: (Score:2)
That would be a pretty major stretch of the law.
If you record video to a patented codec then your recorder needs a license.
If you transcode video to/from a patented codec then your transcoder needs a license.
If you distribute video encoded in a patented codec then the viewers need a license (and *maybe* you need a distribution license, though I suspect that's getting into a legal grey area)
But just because your video passed through a stage where it was encoded in a patented codec doesn't mean that the paten
Re: (Score:2)
Unless you capitalize it, though I have no idea why playing Populous would be associated with Wikipedia.
Tempest in a tea pot (Score:4, Insightful)
The whole issue is about idealism, not practicality. In practice, MP4s are available on pretty much any device.
Unfortunately, that idealism is shooting wikimedia in the foot, because there are platforms that don't have open source codecs installed by default, leaving the "average" user unable to view the videos.
So in their zeal to pursue "openness", they've closed the doors on the people who matter most: the users.
Re:Tempest in a tea pot (Score:4, Insightful)
That availability comes at a price. It's almost impossible for a truly open piece of hardware to compete so we get locked down hardware in return for using proprietary codecs. You are right, it does come down to ideology and as I often say most people don't really want to be free as long as they can live in a golden cage.
Re: (Score:2)
The whole issue is about idealism, not practicality.
What is practical about freedom?
Re: (Score:2)
The question in my mind is whether their mission is to distribute information or promote ideals. I'm disappointed at the decision.
Re:Tempest in a tea pot (Score:5, Insightful)
Re:Tempest in a tea pot (Score:4, Interesting)
Of course if your outlook is limited to the short term of less than the next 12 months then I guess the decision looks bad, but then you're not thinking about the long game.
Re: (Score:3, Insightful)
What makes you think the terribly performing FLOSS codec of the day will be more likely to be supported in the future than today? You'll probably find the FLOSS codecs are just as poorly supported in the future as they are now.
There are a few exceptions, where the FLOSS codecs are really quite good; Xiph has done some great things with speech codecs, for example. But Theora and VP8 are terrible, and VP9 doesn't even match h.264, let alone h.265...
Re:Tempest in a tea pot (Score:5, Insightful)
I'm not sure which codec you're referring too, so I can't answer you there.
I guess my optimism is based on WebM being an open format, thus allowing anyone to implement it on any future platform. Unlike various proprietary formats, that won't. I mean, does your 'phone support Intel Indeo or RealPlayer G2?
That's really odd, because the benchmarks I've seen show VP8 & h264 to be evenly matched, and no one has produced a finished h.265 or VP9 codec, so I do wonder how you think you've seen those two codecs fairly benchmarked?
Re: (Score:3)
I guess my optimism is based on WebM being an open format, thus allowing anyone to implement it on any future platform. Unlike various proprietary formats, that won't. I mean, does your 'phone support Intel Indeo or RealPlayer G2?
H.264 is also an open format in a sense that Indeo etc never were - it has a public specification, and it has complete open source implementations. The only thing that's not open it are the patents, but "in ten years time" they won't be in force anymore.
Re: (Score:2)
Or you can just grab any of the numerous FOSS implementations of it.
Re: (Score:2)
I'm particularly referring to VP8, which Google likes to claim is equivalent to h.264, but in reality it produces dramatically inferior results. The last benchmarks I had looked at showed VP8 requiring about twice the bitrate to achieve comparable quality, although that was a few years ago, so it's possible that the situation has improved. The only real advantage it had was being royalty-free, but that only came about because Google paid for the patent licenses after getting sued for patent infringement.
As
Re:Tempest in a tea pot (Score:5, Informative)
Re: (Score:2)
There are plenty of opensource h.264 decoders. Your source-related arguments are irrelevant.
Re: (Score:3)
Because you don't have to pay patent royalties to use it.
Re: (Score:2)
Because you don't have to pay patent royalties to use it.
Never paid any patent royalties for h.264.
Re: (Score:2)
If you paid to get something with Microsoft Windows or iOS in it you paid for the patent royalties.
Re: (Score:3)
There are fleetingly few of those... WebM support has gotten pretty pervasive. Chrome & Firefox have had it built-in for quite a while, as does Android, and more. In addition, there are native JAVASCRIPT decoders for Vorbis, Theora, and VP8, which could be used for any platforms that lack support, at merely a performance penalty.
Nobody is getting shot "in the foot" here.
Re: (Score:2)
Native javascript? Now there's an oxymoron.. 'Native' means native machine language. Javascript is interpreted bytecode at best. While writing a video decoder in it might be possible, it'll run terribly on anything but the most powerful desktop cpus, and you can forget about anything over 640x480.
Re: (Score:2)
Be sure to spout-off lots of generalizations and pointless guesses, because that helps a lot...
Let's see... My 6 year old, single-core CPU manages real-time decoding of D1 video. But hey, you said it won't work, so I must have completely imagined it.
Re: (Score:2)
Re: (Score:2)
The whole issue is about idealism, not practicality. In practice, MP4s are available on pretty much any device.
Unfortunately, that idealism is shooting wikimedia in the foot, because there are platforms that don't have open source codecs installed by default, leaving the "average" user unable to view the videos.
So in their zeal to pursue "openness", they've closed the doors on the people who matter most: the users.
When I was first starting to use Linux, I tried many distributions, but settled on Debian and Ubuntu.
When I was setting up my desktop, I found Debian incredibly inconvenient. I wanted Java, and Flash... there were a great many compromises that I wanted to make, and Debian made those compromises a real pain in the ass. Ubuntu was perfect, it let me make all those compromises by simply clicking a button.
But I didn't use it on the server when I was doing development. When I was doing development, I realized
Re: (Score:2)
2001, if I'm not mistaken. And discussions about distros misses the point, which was that idealism protects people without legal teams who want to develop things without fear of being sued later, and that they are a small user base of tremendous significance even if you're not one of them.
Re: (Score:2)
WebM codecs such as VP8 and VP9 are also supported on nearly every device. W3.org, Google and the companies supporting ARM have put their full force behind the VPx codecs, and thus the WebM container format. Every Chrome and Firefox user can view it, and if you have device without browser support, you can download either a third party browser such as Firefox or the wikipedia app for most devices, and that will support it.
Support for WebM codecs is very widespread. As of companies backing VP8 and VP9, th
Re: (Score:2)
there are platforms that don't have open source codecs installed by default, leaving the "average" user unable to view the videos
Google Chrome supports if by default. Which kind of platform are you using anyway?
Re: (Score:2)
They have a much better chance of installing an open codec than someone with a free codec only device has of installing a proprietary codec.
Nobody has had the door closed on them.
so what free codec can/should I use? (Score:2)
My question is unrelated to wikimedia, but this seems like the right place to discuss the alternatives to h264/mp4.
I often have to encode videos to send to a few people. Most are computer-illiterate, and it needs to "just work". So I use H264 in Quicktime .mov, because most users have Macs, and those who have Windows definitely have Quicktime installed. I guess .m4v might also work as a container, except it doesn't have a timecode track.
But for the codec, is there a realistic alternative to H264 today? A fo
Re: (Score:3, Informative)
and those who have Windows definitely have Quicktime installed.
Quicktime on Windows is a steaming turd along with its redheaded stepchild iTunes. I definitely don't have it installed. If you can't be bothered to use a 21st century cross platform container format I'll gladly skip watching your video.
Re: (Score:3)
You are obviously not one of the people who needs to work with these videos, but I'm still interested in learning which "21st century cross platform container format" you would recommend, that anyone and their uncle is able to open (without calling me on the phone first).
I don't like QT much either, but what else can play back ProRes and H264, move frame-by-frame (including backwards), and display timecode and frame numbers?
Re: (Score:3)
Just use MP4. That is the standard container for H264 AVC. If you want something fancy use MKV. MKV support is required in order for a video decoder to have the DivX logo on it so even standalone players usually support it. Quicktime is awful. Not the container format but the player software. Like the other guy said its a steaming pile of crap. Especially on Windows.
Re:so what free codec can/should I use? (Score:4, Informative)
WebM is certainly better than QuickTime's H.264 encoding quality. That's VP8 with Vorbis audio in an MKV container.
Oddly enough, your best bet for playback is to use the <video> tag to embed it in a web page. Both Firefox and Chrome natively support WebM, as of quite a while back. Internet Explorer never will, but their market share is dwindling, and all those users need for playback is to install the codec pack first: https://tools.google.com/dlpag... [google.com]
If you want to keep it on QuickTime, there are QT components to support WebM, though I can't speak to their quality: https://code.google.com/p/webm... [google.com]
Re: (Score:2)
Internet Explorer never will
I wouldn't be so categorical about it. A lot of people said that IE would never support WebGL, either, and yet, here we are [microsoft.com].
Re: (Score:2)
Those figures exaggerate IE numbers by more than 2X, according to practically any other source generating statistics on the topic:
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
Re: (Score:2)
No. Not only NO, but HELL NO!
Real friends don't inflict Quicktime on their friends that use Windows.
Quicktime on Windows is and always has been a putrid, steaming, stinking pile.
I have not had Quicktime on any of my computers since I discovered VLC back in 1998.
Re: (Score:2)
VP8/VP9. Include VLC Portable on your USB stick and you're fine.
And that plays when I drop the stick into my bluray player?
Re: (Score:2)
VP8/VP9. Include VLC Portable on your USB stick and you're fine.
And make the recipient of that stick to execute untrusted software?
This means (Score:2)
They are only accepting Vorbis/FLAC audio, Theora video, in ogg containers? Or is everything good as long as the container isn't proprietary?
Re:This means (Score:5, Informative)
You seem to be a few years behind the times... WebM is perfectly FLOSS, and much improved.
For lossy audio, in addition to Vorbis, there is the much better Opus codec. FLAC is the standard for lossless, as there isn't much room for improvement.
For video, VP8 (and soon, VP9) are vastly superior to Theora.
And WebM uses the MKV container... not the horrific Ogg.
Most web browsers support WebM... Chrome/Chromium and Firefox/IceWeasel have support built-in, though the later is lagging a bit behind on VP9/Opus. And IE users can play WebM videos by just installing the codec pack.
The "Video Without Flash" add-on for Firefox will allow you to watch all videos on the most popular video sites in native/WebM format. Not only does this help those who can't get Flash, but also native WebM playback is vastly less resource intensive and far more responsive.
Re: (Score:2)
Thin. (Score:5, Informative)
For information only, the raw, unadjusted, uncorrected figures were:
Prefer full MP4 support: 145
Prefer partial MP4 support - viewing only: 4
Prefer partial MP4 support - contributions only: 56
Neutral: 7
Prefer no MP4 support: 309
Total 521
Is the function of a resource like the Wikipedia to serve its larger audience or its ideological purists?
If you know anyone who cannot legally play an MP4 video, I would like to meet them. If you can frame an intelligible argument for refusing MP4 video contributions, I would like to hear it.
Re:Thin. (Score:4, Interesting)
"If you know anyone who cannot legally play an MP4 video, I would like to meet them."
How is someone to know if they are or are not legally allowed to play MP4?
Re: (Score:2)
You aren't allowed to. Unless someone paid for the patents. Either the hardware or software manufacturer. Did you pay for your playing device? If you didn't there's a good bet you aren't allowed to. The only exception I know of is Adobe Flash. It includes MPEG-4 decoding support and Adobe payed the license. Or whatever. That's why that cancer that is Adobe Flash doesn't seem to vanish from computers. Ever.
Re: (Score:2)
Wikipedia's main goal is to ensure that its repository of knowledge remains available to all in perpetuity. The best way to ensure this is to house it in free-to-implement technical standards so that the content can be supported by playback vendors, cost-free, as well as ensure that the software needed to access the data is always available..
Re: (Score:2)
I've got a better question for you: why are there still people who are unable to open and play back a WebM video? What's the driver behind not including WebM support in the handful of OSes & devices that have refused so far? It isn't technical. It certainly isn't a cost issue. It surely can't be licensing. So that only leaves, what, ideology?
Are Apple & Microsoft going to continue to make their users lives more dif
Re: (Score:2)
Yes, I could make that kind of statement 20 years from now (and probably 10 as well), because the p[atents will have expired.
Re: (Score:2)
Possibly your video card manufacturer... Try VDPAU.
If not, for Linux on x86 or x64 Adobe probably did, and their Flash plugin will decode H.264 videos.
There's plenty of free decoders (Score:2)
File formats aren't copyrightable, and therefore the "FLOSS" label does not apply. Only specific software is copyrightable, and last I checked, there's a plethora of Free Software encoders and decoders, including ffmpeg, x264, etc.
What the maintainer of the codec wishes to do isn't my problem, and it's not Wikimedia's problem.
Re: (Score:2)
File formats aren't copyrightable, and therefore the "FLOSS" label does not apply.
File formats can be patent-encumbered, and therefore the "FLOSS" label does apply. Most formats of any interest are open (forget the OSI for a moment here) but many fewer are Free.
What is this horses#!+ (Score:5, Insightful)
Re: (Score:3)
Clearly the solution is to provide the content in a couple of formats, enough to serve THE USERS. Unless that is, you don't give a shit about users, in which case I don't see why you need a web presence at all...
Wikipedia is big enough that it can and should value its core principles over the short-term convenience of a subset of its users. From the summary:
"Current community requirements are that free/open standards should be used at all times to encode and store video files on the servers that house our data, so that both our content and software can be redistributed without any restrictions." (bold mine)
Wikipedia is using long-term thinking, and I applaud the decision.
MP4 is not a codec (Score:2)
MP4 is a media file container (technically MPEG-4 Part 14, or ISO/IEC 14496-14).
MPEG-4 Part 10 aka ISO/IEC 14496-10 aka AVC aka ITU-T H.264 is a codec that is often found in MP4 containers (except when it is found in MPEG transport streams, such as in Apple HLS).
There are other video codecs that can be in an MP4 container, such as MPEG-4 Part 2, MPEG-2, or MPEG-1.
By the way, HEVC (aka ISO/IEC 23008-2 MPEG-H Part 2 aka ITU-T H.265) is amazingly efficient and everyone should switch to it immediately :)
The what now? (Score:2)
"Now they can get back to their mission of advocating openness."
That was never the mission. This is what they call "mission creep".
As someone that is responsible for creating more content than most of the "no votes" put together, I shake my head in shame.
Unquestionably the right decision (Score:3)
I am surprised there is so much debate here on this. Apparently I have a different understanding of Wikimedia's core mission than some people. In my understanding, their mission is to provide, without restriction, community curated knowledge, period. It is temporarily unfortunate that some (even a significant quantity of) people may be unable to benefit from supporting media to the core knowledge because the platform they are paying for in turn forces them to pay a license for the proprietary technology to read such material. But in the long run it is absolutely appropriate that no proprietary technology should be required to read a single digital bit of the material that Wikipedia provides. To have allowed h.264 would have subtly subverted the core mission.
Re: (Score:3)
Re:But... (Score:4, Insightful)
Some people have priorities beyond people being able to read their website, too.
I thought a website was a way to communicate with people -- a service provided to them. Turns out I'm wrong. Turns out a website is a way of attempting to browbeat people into using hardware that some shadowy collection of self-appointed watchmen have judged pure enough for their tastes.
Re:But... (Score:4, Insightful)
Turns out a website is a way of attempting to browbeat people into using hardware that some shadowy collection of self-appointed watchmen have judged pure enough for their tastes.
The same could be said of closed source licensors and their behavior towards users who desire some control over their hardware.
Re: (Score:3)
Compromise is not always the correct solution, though it is often depicted as the politically correct one.
While 1995 was a more benign time, today's state sponsored patent and copyright wars, extensions, and lawsuits suggest that the LPF was correct with their uncompromising stance.
Re: (Score:2)
Two things that are being glosses over here:
The first is that PNG is a superior image format to GIF... GIF is a 256-color image format, which made sense in the late 80s when it was created due to VGA being the standard back then.
When PNG came out in 1995, SVGA was the current video standard and GIF was already looking obsolete.
The second thing that needs to be mentioned is that H.264 (which is the real loser in Wikimedia's vote here) is controlled by a consortium and not just a single entity. So unlike Un
Re: (Score:2)
"In performance, perhaps. However, some people have other priorities besides performance." ..yeah like practicality...
can I view the video in my browser?
can I view the video on my phone?
if not, I might just as well torrent it.
Re: (Score:3)
Re: (Score:2)
So now, I get to watch 1/2 of what's available because someone doesn't like my choice of codec. That's true freedom.
That's true whining. Install the proper codec.
Re: (Score:2)
Re: (Score:2)
If you don't like Wikimedia's choices, you are absolutely free start your own Wikimedia. With blackjack. And hookers.
Re: (Score:2)
There is no
Re: (Score:3)
Freedom is letting people use what codecs they want, not forcing them to use a handful of really terrible ones.
Re: (Score:2)
It's the formats that are mandated. The "codec" is not. You can write your own VP8 codec from scratch, using the specs, if you choose. Do that with H.264, though, and you're liable for patent royalties. What's more, the MPEG-LA won't sell an individual a license to begin with, so there's no practical way for you to go legit.
And your terms are mixed-up... everyone does anything they want is cal
Re: (Score:2)
Freedom is letting people use what codecs they want, not forcing them to use a handful of really terrible ones.
Wikimedia are serving up data. Accusing them of forcing people to use terrible codecs is like accusing someone of restricting your right to eat beef because they opened a fish and chip shop.
Re: (Score:2)
No, it'd be like a regular customer of the fish and chip shop complaining that they've decided to stop selling fish and chips.
Re: (Score:2)
Not if the goal is to ensure the content remains protected from patent trolls being used as weapons by those wishing to censor such content.
Re: (Score:2)
Who said their primary mission was advocating openness? I thought their mission was building an online encyclopedia. (Or as the Wikimedia Foundation puts it more generally, "... to bring free educational content to the world.") When did it turn into an ideological crusade?
From the Wikimedia Foundation MIssion Statement:
The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally.
..and from the Wikipedia page:
The Wikimedia Foundation's stated goal is to develop and maintain open content, wiki-based projects and to provide the full contents of those projects to the public free of charge.
...although it doesn't explicitly state that patent-unencumbered formats are necessary for those goals, but it's safe to say that insisting on them is fully compatible with those goals. No more ideological than the rest of their 'crusade', IMO.
It's like you show up to a benefit potluck for your local library, and people start ranting about how the food people brought isn't vegan.
To me, it's more like:you show up to a benefit potluck for your local library, and people start complaining that some people are charging money on the side for (or restricting access to) th
Re: (Score:2)
If true, then it's time to develop a truly open codec, not get further into bed with MPEG by switching to h264.
Re: (Score:2)
That might be technically true... Google owns the patents on VP8. But since they've offered an irrevocable perpetual royalty free license to the entire world, it's unencumbered for all reasonable, practical purposes.
VP3 was open-sourced over a decade ago, and no lawsuits ever came out of that. Are you suggesting On2 only RECENTLY started stealing MPEG patents?
Re: (Score:2)
More sources:
Hardware acceleration only improves battery life "up to 36%". That's pretty insignificant to me.
http://blog.webmproject.org/20... [webmproject.org]
Quality improvements have been going non-stop:
http://blog.webmproject.org/20... [webmproject.org]
http://blog.webmproject.org/20... [webmproject.org]
Re: (Score:2)
Re: (Score:2)
And therefore the BETASUCKS campaign was an abject failure.
Fine.