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
As discussed many times before, h264 is an open standard, which means anybody can implement it and there's no compentitive advantage / disadvantage by locking people out of the market. like frand patents (cough cough, motorola!). Of course, it's not open source, and anybody who makes money from h264 (over a certain revenue threshold) has to pay a licensing fee. Are there any precedents for this? How about 3g, lte, etc. It seems fair to me and a logical choice for firefox.
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!
Even if Apple is blamed to be a big h264 pusher
they choose parts of MPEG 2 for Http Live Streaming,
maybe Apple made the good patent decisions?
Will HLS become free before the other solutions?
*ducks*
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.
There is an open source implementation of h.264. It's called jm and is available at http://iphome.hhi.de/suehring/tml/ - and I recall it is also the reference implementation
Syllable you need to have patent licence to use it but that doesn't stop an open source implementation
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. []
They all suck?
(BTW, don't you mean hybrid cars?)
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
Ogg Theora and WebM are no better in quality than MPEG3
You're comparing video codecs to an audio codec? 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. If you're comparing Theora to VP8 and claiming they're of the same quality then you're only displaying your ignorance on the subject and/or that you're trying to troll.
O.G.G. has had it's day.
Does anyone even use V.O.R.B.I.S. anymore? MP3 has long overtaken it. I can't see T.H.E.O.R.A. gaining traction when even Google hasn't managed to push WebM.
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?
This story is from last month, and was widely covered by Streaming Media and others. It was probably posted to /. at that time, too.
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.
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!
Seriously. VLC et al have freedom to write their x264, becaise they are based in France. Why can't they just make Mozilla Corp Europe (like FSFE) to be legally responsible (under sane jurisdiction)?
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?
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.
As an end user, every video I rip is encoded in h264. Why ? Because every off the shelf device for playing video supports h264. Every device that includes a browser that supports video supports h264. No other protocol has as much widespread support at this point, particularly webm which has hardly any. Why would I want to give myself a headache trying to support a codec that has already lost the war ? I've seen claims divx is better than webm is better than h264 because blah, but when it comes right down to it, h264 already handles HD video and the ratio of file size vs quality isn't bad. I can watch it straight from any device I have without needing to switch, be it my xbox, ps3 , smart tv, or PC. As someone said before, If you want to look at who's winning, just look at the torrent sites. I've yet to see on webm encoded video.
You're just confusing the issue with facts.
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).
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.
Old article is old.
Help stamp out iliturcy.
Yep, webm can hold near as many things as mkv
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.
No, not everyone.
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.
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 ?
If you look at the details, the quality varies also in the different places, but in my opinion there seems to be not a clear winner.
The sky, at about 0.5s from the beginning - webm makes rectangular artifacts, mp4 is fine.
The peaks above the clouds after a few seconds - webm is much better here, a detailed stratification is seen, where mp4 makes a very ugly blur.