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?
Excellent! Another card in Microsoft's FUD-deck.
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".
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. []
What other than patents is it?
If we abolished patents how would this not be a free standard?
As a web developer you could just use MPEG2 for videos. That will soon be free to use.
My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
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.
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
Perhaps he means greeting cards printed on e-paper that wirelessly stream annoying musical greetings and show choppy washed-out videos of kittens line-dancing?
Or if you wait until 2023 or so, all the patents involved will have expired. (I don't know the exact dates; wiki just says it was finalized in 2003.)
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
There's no such thing as "MPEG3". It's MPEG audio Layer 3.
Non-troll question: Is there actually an open-source codec which equals or even surpasses H264 in quality? I find it hard to believe the math is so arcane and long-winded that nobody can beat it in quality for a given file size and compress/decompress speed.
Why OpalCalc is the best Windows calc
You're thinking MP3, MPEG-1, Layer 3.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
So, "They all suck" still applies.
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.
They should have done that from the beginning.
Ogg Theora and WebM are no better in quality than MPEG3
You're comparing video codecs to an audio codec?
MPEG-3 was the brief name for high-bitrate video and audio that was eventually rolled into MPEG-2. It should not be confused with MP3, which is really MPEG-1 or MPEG-2, layer 3 audio.
So basically, both you and the GP are confused, although Theora isn't anywhere close to H.264, especially when implemented with a good encoder like x264. VP8 is used so little that it's hard to say what the quality is like over a wide variety of content.
Also, WebM is technically the name of the container for VP8 video with Orbis audio, but in theory, the container could hold any audio and video formats.
Are they planning on doing the same with mp3 for audio? Every device I could name that can play mp4 movies can also play mp3s. I have my doubts that ogg is going to gain any more traction than webm did. I'd be fine with aac as long as something gets standardized.
Quicktime isn't a codec, really.
.qt, .mov
Quicktime movies.
It's a codec, your post is like saying "WMV isn't a codec, Windows Media Player can play any codec you have a plugin for." The software and the codec have a similar name.
You don't understand what you're talking about. Codecs are not the same thing as file extensions. .mov files are container files. They can contain media encoded with a variety of codecs, the vast majority of which have nothing to do with Apple. There is no "QuickTime codec" the way there are Windows Media codecs.
Back when Apple was viciously proprietary about the spread of their QT codec...
And what supposed codec would that be? The only QuickTime codec Apple really developed was the first one, which even Apple never really used. The codecs Apple has endorsed for quicktime lately are MPEG-4 Part 2, and most recently H.264, neither of which is owned by Apple.
I still don't understand why it has to be an either/or for people. That's like saying browsers need to "choose between PNG, JPG, and GIF. They must all agree on a single format and disregard the rest".
The real solution is for all browsers to support about 3-4 different codecs to choose from. And let developers decide on what to use. So Apple and Microsoft, you need to support WebM, and Mozilla, you need to support h264. Let the people decide on what to use! Don't limit them!
But this is true of any codec. You could patent an optimization for WebM just as easily as you could patent an optimization for H.264.
I interpreted that comments as "Ogg Theora and WebM are no better in quality than what MPEG3 might have been if there had been a codec between MPEG2 and MPEG4".
Maybe I'm just giving the poster too much benefit of the doubt?
I think H.264 will be pretty outdated in 2023.
HEVC is supposed to be twice as good as H.264.
I won't be surprised if HEVC's successor is created before 2023.
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.
My point is it's stupid to not support a codec just because of how it was invented. It's still free software.
Wonder what the public key field is for?
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.
I think it's a bit early to call the winner, for the moment. Don't forget that Google holds a big trump card: YouTube. For lots of people YouTube is the only video on the web that they watch, and at least for the moment YouTube's HTML5 player uses WebM.
How do I know? Well, as it turns out Google Chrome is kind of bad at playing back WebM video. Think croaky audio, jittery video. So I looked at the code to figure out the URL to paste into Windows Media Player, which played it just fine with... wait for it... Google's own WebM DirectShow codec. So that's how I know.
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.
Excellent examples.
I need to bookmark these for the next time someone claims "MPEG4 is no better than WebM"
Oh and by the way I wasn't confused about MPEG3. I am well aware that No such standard exists. I was making the point that WebM lies about halfway between MPEG2 and 4 in quality..... that WebM==MPEG3 if that standard had existed.
My AC stalker: " I personally agree with your posts most of the time, but that won't keep me from modding you troll"
Ogg Theora and WebM are no better in quality than MPEG3 (i.e. halfway between crappy MPEG2 and the newer MPEG4).
I wish ATSC used MPEG4 cause I'm tired of seeing blocks/mosquitos on my television screen. Oh well... the ATSC arrived too soon (1998).
There is no such thing as MPEG3. They went right from MPEG2 to MPEG4. I imagine they did this because they thought MPEG3 would be confused with MP3. MP3 refers to MPEG audio layer III (part of the MPEG1 and MPEG2 standards).
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
Excellent examples. I need to bookmark these for the next time someone claims "MPEG4 is no better than WebM"
Meh, I'm sorry, I didn't consider bookmarking: Those files are in /temp on my server,
where everything older than 10 days gets killed. That was stupid of me.
I've just added an exception to the cleanup script, so the URLs should survive –
but still: Feel free to save the files locally or put them somewhere else.
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.
Did they even get past the proposal evaluation part?
Old article is old.
Help stamp out iliturcy.
Yep, webm can hold near as many things as mkv
I use vorbis and FLAC every once in a wile
H.264 is not an open standard. Not as defined by the W3C anyway. An open standard on the web can't be patent-encumbered.
Clever signature text goes here.
So in other words we're following the Star Trek Rule here...
A bullet may have your name on it but splash damage is addressed "To whom it may concern."
Isn't everyone using the main profile, though? So what's your point?
Clever signature text goes here.
Vorbis is an excellent audio codec. VP8 isn't as good as h.264, but it does the job for low res vids I use xVid for alot of my higher RES vids. H.264 also has tons of hardware support, VP8 could possibly match h.264 with that kinda support.
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.
I do too. The thing that hurts those formats is the lack of hardware support on music devices.
"Science can amuse and fascinate us all, but it is engineering that changes the world. " - Asimov.
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.
Someone sees sense. Use whatever codecs are available on the host platform. h.264 is ubiquitous a the moment, but there is no point tying us into a standard current in 2012, when hardware inevitably moves forward.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
By 2015 H.264 won't be free no more
Muchas Gracias, Señor Edward Snowden !
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.
Codecs ? And plugins ? I mean INSTALLABLE a/v decoders ? What does video decoding have to do with hypertext markup language ? And why should Mozilla, Google or Froogle decide on what I encode the videos on my page with ?
True, but it's worth noting that computers weren't able to play back DVD video without dedicated hardware codec chips until about 2000, give or take, and most of the work to hardware accelerate playback with more generic hardware likely didn't begin until about that time. So if you want to write an all-scalar-math version of the codec that sucks down all four cores to decode 480i, then yes, you'll be able to do it without running into patents in only three or four years, but it is likely that most of the implementations that are even marginally usable will remain under patent protection for several more years after that.
It won't be nearly as bad for future codecs now that the techniques are well understood (and thus not realistically patentable for future codecs), but MPEG-2 decoding broke new ground in a lot of ways.
Check out my sci-fi/humor trilogy at PatriotsBooks.
That last part is key. In particular, anyone who redistributes Firefox (Linux distributions come to mind) would be affected. Quite a number of distros have >100,000 users, I bet.
There is a far more advanced x264 under VLC/FFMpeg, also open source, but it is illegal to use it unless you purchase a license.
There was never any reason to avoid specifying other profiles, or including at least some of the metadata I mentioned (such as the source/display frame rates), or to hardcode the number of audio channels.
No, it was a failure. It wasn't a huge step forward from MPEG-2, if it had it would have been used for more than just DivX ;-) and low resolution MMS messages. It's been around since before the adoption of digital TV standards, don't you think it says something that ATSC, DVB, ISDB, and the other standards actually stuck with MPEG-2 - despite later jumping right onto the AVC codec despite the fact the digital TV standards had already been rolled out by the time they were adopted?
Why do you think Blu-ray, launched long after ASP's release, never incorporated the technology?
Why do you think AVC and Microsoft's VC-2 came about in the first place? They were both launched several years after ASP and had exactly the same aims!
You are not alone. This is not normal. None of this is normal.
But that's still just as true for WebM. This issue is not a differentiator between the two codecs.
But I use free software H.264 encoders and decoders already. There's been a lot of discussion about patents and FOSS software licenses, but that's all there's been. Free software and especially open source software is copyright thing and development methodology first, not a patent thing.
It's the same debate we had with MP3. Until the government wants to come around and say, "Your free software implementation is [somehow] illegal" the argument that H.264 is non-free -- or any piece of software, no matter how it's licensed -- is pure FUD. (And even if the state were to come around and say stop-you-can't-do-that, what would they do about it? We've already got the source code, because, you know, open source.)
If you want to say it's a bad idea because Mozilla would get sued into the ground, say that. But don't claim it's not non-free software because some third party wants to assert their power.
Wonder what the public key field is for?