Mozilla Considers H264 After WebM Fails To Gain Traction
HerculesMO writes with word that "Looks as though Mozilla is considering using H264, one step closer to unification of a single protocol for video encoding. It's a big deal for HTML5 traction, but it still leaves Google holding onto WebM." The article, though a bit harsh on Ogg Theora, offers an interesting look at the way standards are chosen (and adopted by the browser makers).
Word has it that you can't run Flash on the iPhone, either.
Obliteracy: Words with explosions
I remember seeing lots of little Real-encoded videos on websites back in the day... whatever happened to them?
Yes, you already posted the story about this in March. Which is the same month when the linked article is from. Good to see timithy is still at the top of his game!
Dupe:
http://news.slashdot.org/story/12/03/13/2027215/mozilla-debates-supporting-h264-in-firefox-via-system-codecs
http://yro.slashdot.org/story/12/03/20/1742209/mozilla-to-support-h264
Old news:
March 13th, 2012 -> This particular blog's story is March 16th, 2012 -> Today is April 26th, 2012
Vanity link:
It's a link to AppleInsider--why on earth would AppleInsider be a novel or interesting source about internal Mozilla strategy?
Dear editors: wake the hell up.
Mozilla wouldn't even have to taint itself by supporting it. Just hook the video tag to the media framework in the host OS - Quicktime, DirectShow, gstreamer etc. and invoke the default h264 codec if its present and suitable or point the user at a way to obtain it if it isn't. They could still ship Theora with the browser if they wanted.
The fact that one company owns the license to this technology and makes no guarantees to _not_ increase licensing costs means that once h.264 support is the be-all end-all solution to web video, this one company has a monopoly on the sole video technology that drives the web. Most people running windows/mac have probably indirectly paid for licensing fees for h.264 multiple times. Nice racket they've got there and nobody is complaining, yet.
Here's a pretty good article:
http://www.zdnet.com/blog/bott/a-closer-look-at-the-costs-and-fine-print-of-h264-licenses/2884
from the article:
To use and distribute H.264, browser and OS vendors, hardware manufacturers, and publishers who charge for content must pay significant royalties—with no guarantee the fees won’t increase in the future. To companies like Google, the license fees may not be material, but to the next great video startup and those in emerging markets these fees stifle innovation. []
The justification for WebM is that it would allow people to freely share videos using your own infrastructure without charge and without additional cost.
It's not about the consequence for the consumer, it's about the chilling effect it has on free culture.
It has HUGE consequences. Mozilla knew that, that's why they tried to play hardball.
-1 Uncomfortable Truth
The notion that H.264 is not "free" isn't a result of a development methodology, it's because people think that somehow patents make it that way, despite the fact that the software authors have no choice in the matter.
H.264 is not free-as-in-freedom nor free-as-in-beer, and patents are the reason. IP amounts to copyright, trade secrets and patents, but the first two don't apply here. It's a patent issue.
tomorrow who's gonna fuss
TFA is not worth your time. He says all sorts of outrageous stuff as if it were fact: apparently he knows exactly what Google was collectively thinking when it introduced WebM, for example.
And the ending is sort of surreal. Hooray! The patent-encrusted H.264 has defeated the challenge by the free and open software! Here are my wrists; there's still room for a couple more handcuffs, put them on! (Eh, probably not a fair summary, but about as fair as his treatment of Google.)
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Besides, VP8 is actually more-or-less equal to H.264 in quality and compression, you can easily verify that yourself with libvpx and x264.
It really isn't. VP8's quality is comparable to that of H.264's Main Profile.
H.264 High Profile eats VP8 for breakfast in bitrate-limited scenarios, meaning
about 800 kilobit/s for SD content.
But even at around 1,5Mbit/s, it's really obvious to the trained and still visible
to the untrained eye. Yes, I actually have done double-blind tests.
vpxenc is still very young, so improvement will happen, in both perfomance
and quality. But the developers themselves have stated that it is unlikely to ever
exceed H.264 MP by much.
I've done extensive tests to try to coax better quality out of VP8, and have pretty
much failed. I even had help from one of the guys at google working on VP8.
And yes, it's part of what I do for a living.
Have a look yourself:
x264 High Profile, 790Kb/s, 4.3MiB
VP8, best effort, 770Kb/s, 4.2MiB (the encoder was given the same constraints as x264)
VP8 falls completely apart on high-frequency picture content, where H.264 holds up quite well.
As one of the x264 devolpers said when I showed this around (verbatim quote): "Holycrapbirds".
Of course, that low a bitrate is a very harsh test. At over twice the bitrate, VP8
still needs more bits for similar quality, but the relative difference is much smaller.
At some point around 2Mbit/s, "quality saturation" sets in.
But for sites doing lots of streaming to clients behind <1Mbit/s connections and aiming
for noncrapbird quality, this is a real issue.
I suspect the bigger problem is that there are so many patents on video codecs that any better open source alternative would infringe on at least one of those patents.
This is a controversion question. The consortium which licenses H264 has certainly expressed this opinion. They say things along the lines of: "we can't say on which of our patents it infringes but we know it must because 1) it is a modern video codec, and 2) one cannot possibly write a modern video codec without having to deal with at least some of our patents."
The view is expressed by the developers of VP8 (WebM) is that H264 is the result of deliberately steering developement so as to intersect as many of the consortium's members' patents as possible. VP8 is supposedly the result of heading toward the same goal while steering around them.
Whether the VP8 developers can make their codec as good as H264 without involving any of the MPEG consortium patents is still an open question. I gather that they have not achieved that goal yet.
If patents really define what makes software "free" or not-free, then no one would be able to chose to make a free H.264 codec.
I am not sure what you are trying to say. One can certainly write H.264 codec and distribute the source code under the GPL. But the recipient does not have the right to _use_ it unless he obtains a license. So, these implementations are not fully free and the authors cannot make them free (without offering to pay the license fees for all of the users).
My point is it's stupid to not support a codec just because of how it was invented. It's still free software.
At present no H.264 implementation _can_ be free software. If you use it for certain purposes or at a certain volume you have to give money to the MPEG consortium. You may think this is OK, but it is not "stupid" to be unhappy with this arrangement.
H.264 is not free-as-in-freedom nor free-as-in-beer, and patents are the reason. IP amounts to copyright, trade secrets and patents, but the first two don't apply here. It's a patent issue.
No. It's a licencing issue. H.264 is not an open, royalty-free standard and that's what makes it bad choice for the web. VP8 is covered by patents but it's licenced under royalty-free terms. If H.264 was licenced under royalty-free terms for all use cases then there would be no issue.