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).
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.
Pity that a licensed tech won, but who can blame people when you have the hardware accelerated decoding in billions of handsets worldwide. I'm not opposed to people making money, but not at the cost of making devices prohibitively expensive.
Here's to hoping that "Fair, Reasonable and Nondiscriminatory" licensing fees stay that way.
You're not paranoid if they really ARE out to get you...
There's plenty of open source encoders and decoders available. ffmpeg, x264 (produced for VLC) to start.
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.
Wonder what the public key field is for?
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 thresholds for encoders/decoders are based on distribution quantities, not revenue thresholds. Below 100,000 units, there is no royalty fee owed. Between 100,000 and 5 million units, the cost is 20 cents per unit. Above 5 million, the cost is 10 cents per unit.
The maximum royalty fee owed is currently capped at $6.5 million.
Part of the license agreement specifies that the fees can't increase more than 10% per 5 year period (2011-2016 is the current period). The max cap can go up more than 10% per period, but that only affects the biggest distributors.
Mozilla can certainly afford it, the Foundation brings in over $300 million in search engine fees alone. Smaller open source projects would probably fall under the 100,00 units. The ones most affected will be popular projects that lack an income stream like Mozilla Foundation has.
Not necessarily, the decoder/encoder royalty fees are pretty cheap and could be sold at a good profit as an add-on for less than a buck.
Soon, in this case, is still a few years away. MPEG-2 was published in 1996, so any patents in it are likely to have been filed by at least 1995. This still leaves three more years before they all expire. Amusingly, TFA (which is full of flamebait) seems to think that both MPEG-2 and MPEG-4 Part 2 were released in 2002, and that DVDs were first released in 2002. Those DVDs I saw in 1998 containing MPEG-2 video must have come from a time traveller...
I am TheRaven on Soylent News
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
Parts of MPEG-2 (AAC, for one) were not published until 1997, and some hardware codec chips might have patents that were filed much later. Similarly, there may be patents on algorithm optimizations that were filed much later, e.g. patents on ways to use pixel shaders to perform some part of the MPEG-2 decoding process. So although the format will ostensibly become free and clear of patents four years from now in its barest reference implementation, that does not necessarily mean that you can't get sued if you write your own implementation. :-)
Check out my sci-fi/humor trilogy at PatriotsBooks.
It's not that it's arcane, it's that it's boring. It's a whole lot of very, very boring work to develop a good video codec. It's the kind of thing open source development is very bad at.
So no, there isn't one.
Sure. And if it becomes the dominant codec, I guess we can pray they don't alter the deal further after 2016. Enjoy your clown suit.
Yes, it really is that hard. I've written some of these things. It's not that the knowledge is inaccessible: most of the concepts involved are covered in a good undergrad discrete math course. It's just that 99.999% of the programmers out there either don't take the course, or forget what was taught the moment after the final is handed in.
Look at the sorry state of linux audio, for one. Layer upon layer, library upon library, everyone's an architect slinging metaphors and objects around but very few actually know how to write a good sample-rate conversion function, for example, or to even build the filters necessary to do so.
And video's harder. There's tons of mind-twisting buffer management issues to handle interpolated, motion-compensated frames that can take as reference past frames, future frames, and even other interpolated frames either past or future, using any of a number of different block sizes as the base motion-compensating element to which the discrete cosine transforms are applied. All with modified coefficients from the mathematically pure transforms -- powers of two to improve hardware decoding ease (even if it makes the filesize somewhat larger) -- that's what one of the key patents is about.
So, yes, it's hard enough and arcane enough that the likelyhood of someone with both the free time and the knowledge to do so, does it.
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.
HEVC will suck because MPEG always follows the pattern of releasing a prototype video codec followed by a decent one.
Thus far it's been:
- MPEG1 - lack of support for profiles except a single low resolution "standard", two channel audio, no support for Interlace (at the time a necessity), no metadata to describe how to deal with a difference between original and display frame rates.
- MPEG2 - Identical to MPEG1, except all the above fixed.
- MPEG4 part 2 (ASP) - Entire kitchen sink thrown in, with no thought as to what would be useful, apparently to pacify patent holders. Only a subset of features actually *allowed* to be used. Requires huge amounts of processing effort. Promised 50% improvement over MPEG-2, achieved closer to 5%. Only popular thanks to DivX ;-).
- MPEG4 part 10 (AVC/H.264) - The good parts of ASP, coupled with the stuff that should have been there to begin with, and most of crap removed. Made good, for the most part, on the "50% better than MPEG-2" promise.
Thus, HEVC will be a giant pile of crap, but AHEVC (or whatever the post HEVC codec will be called) will actually be pretty decent.
You are not alone. This is not normal. None of this is normal.
Soon Linux will be, depending on context, "that operating system that can't play videos on the web and doesn't support standards", or "that operating system where everyone infringes patents, so it would be crazy to use it in a business".
Both of these scenarios can be avoided by using the hardware H.264 decoding capabilities built into nearly every PC video output device made in the past 5 years. (Intel's pre-Cedar Trail Atom is about the only exception I can think of.) As long as the driver support is present (which, granted, may be a big if on Linux) then the software can simply pass the raw H.264 bitstream to the video driver, and the driver will handle the decoding. The license fees were already paid by the hardware manufacturer in this case, so there's no need to shell out any additional money.
Superior in what way? Certainly not in terms of licensing. And there is no guarantee that h264 doesn't infringe on patents.
Phillip.
Property for sale in Nice, France
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.
Not that I am doubting you, but could you provide the encoding settings you used for both VP8 and H.264? The tests I have conducted myself were more-or-less of the same quality so I am curious as to whether or not I did something wrong myself.
Not even nearly. One of the more prominent examples of an entity using High Profile is Apple; the streams to AppleTV are High Profile - encoded and it has provided them with clearly superior picture-quality while also consuming less bandwidth compared to Main Profile. Media that is to be consumed on mobile devices is still mostly Main Profile, yes, but even there the movement is towards High Profile.
The videos look absolutely identical until the last part with birds, a clearly pathological case of "make benchmark to fit the product" type. In both videos the view of birds is highly distorted at the end, and no details other than a whole screen filled with slow-moving high-frequency pattern, are visible. x264 example keeps the birds distinct while VP8 blurs them, but neither provides usable details -- those videos have to be encoded at higher rate to be watchable, no matter what.
Contrary to the popular belief, there indeed is no God.
Wow, you couldn't be more wrong. There are many more differences between the two videos.
In the first segment (the one that lasts only 0.62 seconds), the details of the mountains. In the second segment, the blue sky as the camera passes through the mountains, and to a lesser degree the two mountains themselves. In the third segment, the details in the foam and, more evidently, in the trees far away behind the cascades.
Saying that "The videos look absolutely identical until the last part" is just ridiculous.
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.
Not that I am doubting you, but could you provide the encoding settings you used for both VP8 and H.264?
I'm on vacation until mid next week, so don't have access to the scripts used. From memory:
Both are two-pass encodes. x264 recommends single-pass with --crf nowadays, because it's
faster and nearly as good, but constant quality mode and bitrate limits don't mix too well, and
for my low-bitrate case there's still a clear advantage for longer-range precognition.
The x264 settings are a tweaked "--preset slower", with longer rc-lookahead and added
bandwidth limitations (vbv_maxrate and friends). x264 writes the exact settings used – including
an expansion of a preset into its individual parameters – at the beginning of its output, so have
a look at "strings testenc_x264.mp4 | grep x264", or use mediainfo on the file.
For vpxenc, it's basically the same, using "--good" and "--tune=ssim", adding bitrate control
settings and minor tweaks. No parameter logging in the output here unfortunately, so I can't give
you any more details right now.
The tests I have conducted myself were more-or-less of the same quality so I am curious as to whether or not I did something wrong myself.
You probably did nothing wrong at all, you just didn't restrict the encoder as heavily as I did.
I tried to make it clear that those examples are rather extreme: If you allow higher bitrates, VP8
quality improves quite a bit, and everything above about 1.5Mbit/s is fine in the vast majority of cases.
Also, the test clip used is intentionally really really hard to encode (smooth, slow-moving, weak
gradients; rotations; low contrast; high motion; high frequency; all combined; hard cuts; etc.),
to highlight encoder capabilities – and shortcomings. It stress-tests everything from motion
estimation to several other predictors the encoders may or may not have, to bitrate allocation,
so it's an excellent worst case.
I'm not trashing VP8 or vpxenc by the way, we're still going to use it to serve video to clients and/or
devices without H.264 support. It's just that H.264 (in its x264-encoded manifestation, there are lousy
H.264 encoders out there, mostly the really expensive ones) really shines in low-bandwidth use cases,
and VP8 is universally outclassed by H.264 High Profile.