Slashdot Mirror
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).
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!
People figured out that Real (and Realplayer) were utter pieces of garbage and stopped using them?
Same thing I wish would happen to quicktime.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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.
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. []
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.