Linked by Thom Holwerda on Wed 14th Mar 2012 19:37 UTC
Internet & Networking Ever since it became clear that Google was not going to push WebM as hard as they should have, the day would come that Mozilla would be forced to abandon its ideals because the large technology companies don't care about an open, unencumbered web. No decision has been made just yet, but Mozilla is taking its first strides to adding support for the native H.264 codecs installed on users' mobile systems. See it as a thank you to Mozilla for all they've done for the web.
Thread beginning with comment 510630
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: In through the back door.
by lemur2 on Wed 14th Mar 2012 23:33 UTC in reply to "In through the back door."
lemur2
Member since:
2007-02-17

While H.264 is a better codec the difference isn't something I would care about unless I was trying to watch HD movies. I would hope that IF Mozilla does incorporate H.264 they do it via codecs on your computer (not browser native) so they just skirt the issue instead of hard coding it. Actually I was somewhat irked this wasn't already the case.


H.264 is not the better codec. WebM quality-per-bit surpassed it a version or two ago. The latest version of the WebM software encoder is version "D" for "Duclair", released on Jan 27 this year.

http://blog.webmproject.org/2012/01/vp8-codec-sdk-duclair-released....

This version is better than version "C", which in turn was better than version "B", and so on. Each version was an improvement over the previous version in quality-per-bit by about 6% each time. Version B almost matched h.264 quality-per-bit, and version C surpassed it.

The "Duclair" release has been numbered by Google as the 1.0.0 release.

Reply Parent Score: 5

RE[2]: In through the back door.
by d3vi1 on Thu 15th Mar 2012 00:04 in reply to "RE: In through the back door."
d3vi1 Member since:
2006-01-28

"While H.264 is a better codec the difference isn't something I would care about unless I was trying to watch HD movies. I would hope that IF Mozilla does incorporate H.264 they do it via codecs on your computer (not browser native) so they just skirt the issue instead of hard coding it. Actually I was somewhat irked this wasn't already the case.


H.264 is not the better codec. WebM quality-per-bit surpassed it a version or two ago. The latest version of the WebM software encoder is version "D" for "Duclair", released on Jan 27 this year.

http://blog.webmproject.org/2012/01/vp8-codec-sdk-duclair-released....

This version is better than version "C", which in turn was better than version "B", and so on. Each version was an improvement over the previous version in quality-per-bit by about 6% each time. Version B almost matched h.264 quality-per-bit, and version C surpassed it.

The "Duclair" release has been numbered by Google as the 1.0.0 release.
"

Even so, I assume that a new stream encoded with all the bells and whistles (of better quality than H.264) does not play if you have version 1.0 of the VP8 codec.
This is a problem with it as it's a moving target. No hardware manufacturer will include webm support in the sillicon if it will stop working 12 months after the release of the chip. H.264 is successful because it's great for Digital TV, Digital Distribution of Movies/TV Shows, Blu-Ray, VVoIP (FaceTime is a great example), etc. Every idiot on the web talks about this as if the rest of the industry doesn't matter. The rest of the (usually quite expensive) hardware and media recordings can be upgraded to WebM over night or at no cost. If Google can afford to use twice the storage for Youtube to also include WebM, good for them. I doubt that many others can do the same within financial reason.

Reply Parent Score: 1

lemur2 Member since:
2007-02-17

"H.264 is not the better codec. WebM quality-per-bit surpassed it a version or two ago. The latest version of the WebM software encoder is version "D" for "Duclair", released on Jan 27 this year.

http://blog.webmproject.org/2012/01/vp8-codec-sdk-duclair-released....

This version is better than version "C", which in turn was better than version "B", and so on. Each version was an improvement over the previous version in quality-per-bit by about 6% each time. Version B almost matched h.264 quality-per-bit, and version C surpassed it.

The "Duclair" release has been numbered by Google as the 1.0.0 release.


Even so, I assume that a new stream encoded with all the bells and whistles (of better quality than H.264) does not play if you have version 1.0 of the VP8 codec.
This is a problem with it as it's a moving target. No hardware manufacturer will include webm support in the sillicon if it will stop working 12 months after the release of the chip.
"

You assume incorrectly.

http://blog.webmproject.org/2012/01/vp8-codec-sdk-duclair-released....

"Note that the VP8 format definition has not changed, only the SDK. Duclair is ABI incompatible with prior releases of libvpx, so the major version number has been increased to 1, and you must recompile your applications against the v1.0.0 libvpx headers. The API remains compatible, so code changes shouldn't be required in most applications."


The data format of WebM has not changed at all since the first release. Videos encoded with the earliest release of WebM will still play correctly with the latest release of the decoder (they just won't have the same quality-per-bit). The latest version of the encoder produces higher quality-per-bit video with the same data format, so these videos will still play with the earliest release of the decoder (although the earlier decoder will take more CPU than the current version would).

There is no "moving target" here at all, simply increasing quality and performance with the same data format.

Incidentally, Duclair is version 1 of the codec. Version 1.0.0 to be more precise. Earlier version had version numbers lower than 1.

For information, the preceding release was codenamed Cayuga, and it was version v0.9.7.

Edited 2012-03-15 03:09 UTC

Reply Parent Score: 6

Xight Member since:
2012-01-06

I will take your word for it. The link looks promising (will research this a bit) I hope it continues to improve and if it indeed is becoming the superior codec I could see it possibly becoming dominant (at least I could hope). Thanks for giving me incentive to look into this further. My main point however was if Mozilla has to implement it why not use whats already on peoples computers or allow us to hack it ourselves. For instance I have the S3TC enabled via libtxc_dxtn. It was my choice if I wanted to use a technology the distributer could get in trouble if they bundled it directly. Last time I checked (may no longer be true) Mozilla didn't use external codecs so you COULDN'T do anything like that (yet).

Reply Parent Score: 1

Neolander Member since:
2010-03-08

If I'm not misunderstood, only the encoder has improved, without any need to change the underlying video codec. Just like x264 kicks the arses of most other H.264 encoders without requiring an x264-specific decoder. But I need someone more familiar with the matter to confirm that.

Reply Parent Score: 3

Beta Member since:
2005-07-06

Even so, I assume that a new stream encoded with all the bells and whistles (of better quality than H.264) does not play if you have version 1.0 of the VP8 codec.

You assume an awful lot. The VP8 format hasn’t changed.

H.264 is successful because it's great for Digital TV, Digital Distribution of Movies/TV Shows, Blu-Ray, VVoIP (FaceTime is a great example), etc.

Which profile are you talking about now exactly? Hopefully you understand you’re taking about a group of encodings with different features which don’t run on all devices you just mentioned… it has the exact problem you just assumed WebM doesn’t have.

Every idiot on the web talks about this as if the rest of the industry doesn't matter.

Maybe if they weren’t busy filling comments with assumptions, real discussions about why it doesn’t matter would happen.

Reply Parent Score: 3

modmans2ndcoming Member since:
2005-11-09

so WebM is available on smart TVs and set-top boxes for DLNA streaming?

Reply Parent Score: 2

bowkota Member since:
2011-10-12


H.264 is not the better codec. WebM quality-per-bit surpassed it a version or two ago. The latest version of the WebM software encoder is version "D" for "Duclair", released on Jan 27 this year.

http://blog.webmproject.org/2012/01/vp8-codec-sdk-duclair-released....

This version is better than version "C", which in turn was better than version "B", and so on. Each version was an improvement over the previous version in quality-per-bit by about 6% each time. Version B almost matched h.264 quality-per-bit, and version C surpassed it.

The "Duclair" release has been numbered by Google as the 1.0.0 release.


You forget to mention that HEVC(H265?) is almost ready and among other things it will feature half the file footprint of High Profile H264.

Reply Parent Score: 3

lemur2 Member since:
2007-02-17

You forget to mention that HEVC(H265?) is almost ready and among other things it will feature half the file footprint of High Profile H264.


AFAIK H.265 is not format-compatible with h.264.

http://en.wikipedia.org/wiki/HEVC

Reply Parent Score: 3

Soulbender Member since:
2005-08-18

H.264 is not the better codec.


Good job missing the entire point of the post.
It's not about which is better but how it will be implemented.

Reply Parent Score: 2

RE[2]: In through the back door.
by saynte on Thu 15th Mar 2012 04:30 in reply to "RE: In through the back door."
saynte Member since:
2007-12-10

Initially there were some extensive tests on comparing VP8 and H264, have they been re-done recently with the results posted online for us to check? Do you have any proof that VP8 is better than H264?

Otherwise, even Google is not claiming that VP8 is better than H264, just that they've improved by a certain percentage on a certain metric.

Reply Parent Score: 1

lemur2 Member since:
2007-02-17

Initially there were some extensive tests on comparing VP8 and H264, have they been re-done recently with the results posted online for us to check? Do you have any proof that VP8 is better than H264?

Otherwise, even Google is not claiming that VP8 is better than H264, just that they've improved by a certain percentage on a certain metric.


One can unfortunately debate this topic ad infinitum. About a year ago, after WebM quality had twice been significantly improved compared to its initial release, on OSNews there was a topic about encoder speed, and a poster who knew how to do so provided a couple of examples using WebM and h264 encoder profiles such that the quality of the output was all but identical. As close as could be achieved.

The x264 encoder was far faster. The WebM files were actually a bit smaller.

Google have significantly improved the encoder speed of WebM twice since then.

http://blog.webmproject.org/2011/08/vp8-codec-sdk-cayuga-released.h...

http://blog.webmproject.org/2012/01/vp8-codec-sdk-duclair-released....

I think that the x264 encoder speed is still faster than libvpx, but nevertheless the point remains that the WebM format actually needs slightly fewer bits for the same quality of output.

Edited 2012-03-15 08:36 UTC

Reply Parent Score: 2

RE[2]: In through the back door.
by Gusar on Thu 15th Mar 2012 12:01 in reply to "RE: In through the back door."
Gusar Member since:
2010-07-16

H.264 is not the better codec. WebM quality-per-bit surpassed it a version or two ago.

Did you confirm this by conducting your own test, encoding the same video with both encoders? May we see the results of that test? I did so a bit more than a year ago, and posted sample screenshots from the encoded videos here. VP8 was lagging behind *a lot* and the encoder was also a lot slower than x264. Sure libvpx has had releases since then, so I'd need to repeat the test to see how much things have changed.

But what I'm trying to say is, unless you provide such a test and the info so that others can reproduce it (I posted command-lines I used to encode the videos), statements about the quality of the encoders have no merit.

Reply Parent Score: 2