Linked by Thom Holwerda on Wed 14th Nov 2012 22:12 UTC
Internet Explorer "In Windows 8, we reimagined the browser with IE10. We designed and built IE10 to be the best way to experience the Web on Windows. With the IE10 Release Preview for Windows 7 consumers can now enjoy a fast and fluid Web with the updated IE10 engine on their Windows 7 devices. The release preview of IE10 on Windows 7 is available for download today."
Thread beginning with comment 542689
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: IE10 still disappointing
by lemur2 on Fri 16th Nov 2012 01:04 UTC in reply to "RE[4]: IE10 still disappointing"
lemur2
Member since:
2007-02-17

" WebM does take longer to encode than h264 at the same quality level, but that is its only penalty. If one chooses encoding profiles to yield the same quality level, the WebM codec actually ends up with slightly lower bandwidth (iow a slightly smaller filesize) than H264.


Have a WebM/H264 comparison to verify that?

Here's a fairly thorough one that puts x264 above WebM's standard encoder consistently, both in terms of quality and encoding speed (encoding speed seems to be about 3x faster for x264):

http://www.compression.ru/video/codec_comparison/h264_2011/mpeg-4_a...
"

The comparisons you linked all compare a chosen profile of one codec against another. At some particular profile, one codec will be better than another ... but one can simply choose a higher profile for the second codec and it will be the other way around. The second codec at a higher profile will take longer to encode then the first profile chosen, but the resulting video will be better quality for the same filesize.

OK, so one can also choose a higher profile for the first codec, and now once again it will be better, once again at the cost of taking longer to encode. One can get a lot of combinations/comparisons this way, with each codec surpassing the other (in quality per bit) depending on the profile chosen.

There are multiple variables at play. Because the profiles are different for each codec, which profile to compare with which is somewhat an arbitrary choice. If one wants to make a reasonable comparison, one should eliminate at least one of the variables.

OK, so the best way to make a direct comparison between codec performance is what I alluded to in my original post. One chooses profiles for each codec such that they produce the same quality video at the same resolution and bitrate, and THEN one can compare the time to encode and the filesize.

If you do it that way, then WebM takes a lot longer to encode (to the same quality as a given profile of x264), but the resulting file size is a bit smaller.

Having said that, WebM time to encode is getting a lot smaller as the codec matures. The latest release (just over a week ago) is the fifth generation of the libvpx software (codename Eider) and sixth generation of the hardware (G1 decoder “Fairway” and the H1 encoder “Foxtail”). The first letter of the codenames indicate the generation since the inaugural release.

http://blog.webmproject.org/

This new Nov 2012 release is probably at least two generations better than the version tested in the PDF file you linked. The gap in encoding speed (to the same quality of resulting video, with slightly smaller filesize) has probably narrowed considerably.

So, I repeat, the only penalty for using WebM is that it takes longer to encode. If the profile you are using for WebM gives you lesser quality than the one you have been using for x264, then simply choose a higher profile for WebM. Admittedly this choice will cost you in terms of the time taken to encode, but that time cost is the only penalty. Then again, it must be remembered that video is normally encoded once for many times that it is replayed, so if there must be one area of compromise, then encoding speed is the best area in which to take the penalty.

Edited 2012-11-16 01:08 UTC

Reply Parent Score: 1

saynte Member since:
2007-12-10


There are multiple variables at play. Because the profiles are different for each codec, which profile to compare with which is somewhat an arbitrary choice. If one wants to make a reasonable comparison, one should eliminate at least one of the variables.


Okay, let's eliminate a variable: look at page 27, this fixes the quality to "high" for all encoders, let's assume this is the top for WebM: it uses --good --cpu-used=0 which is listed as an alternative for --best by the WebM encoding guide.

The quality for a given bitrate is always higher for x264. This means for the high-quality settings, for equally sized files, the x264 will be of higher quality (by the Y-SSIM metric they use). You will also spend 1/3 the time waiting for it to encode.

Reply Parent Score: 3

lemur2 Member since:
2007-02-17

"
There are multiple variables at play. Because the profiles are different for each codec, which profile to compare with which is somewhat an arbitrary choice. If one wants to make a reasonable comparison, one should eliminate at least one of the variables.


Okay, let's eliminate a variable: look at page 27, this fixes the quality to "high" for all encoders, let's assume this is the top for WebM: it uses --good --cpu-used=0 which is listed as an alternative for --best by the WebM encoding guide.

The quality for a given bitrate is always higher for x264. This means for the high-quality settings, for equally sized files, the x264 will be of higher quality (by the Y-SSIM metric they use). You will also spend 1/3 the time waiting for it to encode.
"

They won't be equally-sized files, WebM gives slightly smaller filesizes for the same bitrate and resolution. So, in order to match the highest profile of x264, one must increase the bitrate for WebM. If one increases it just enough so that the filesize becomes equal, and the quality is equal, WebM must employ a slightly higher bitrate. In other words, once one exhausts the options of going to a higher profile, one can only increase the quality further by increasing the bitrate. Once again, one can then also increase the bitrate for the other codec as well (but then that increases the filesize), and we get into the exact same revolving door (since now more filesize is available for WebM allowing it to go to an even higher bitrate), where one codec is better then the other, and all the time the time taken to encode (for both codecs) keeps increasing.

I told you there were multiple independent variables. This is evident from the very graphs you keep referencing. Very plainly, if one runs out of "higher profiles", the way to further increase the quality is to increase the bitrate. Why is this so hard apparently for you to accept?

With WebM one does NOT have to suffer lower quality per bit (i.e. filesize) if one chooses not to, but the penalty that one must pay, as I have said twice now, is encoding time. There is no question that to get the same quality per bit WebM does take longer to encode. However, as I have said, that is the only penalty, and furthermore, as I have already pointed out, this gap in encoding time is reducing as the WebM software and hardware implementations mature. In any event, because videos are only encoded once per many times they are downloaded or viewed, encoding time is the best area of any in which to compromise.

Edited 2012-11-16 10:03 UTC

Reply Parent Score: 1

lemur2 Member since:
2007-02-17

The quality for a given bitrate is always higher for x264.


BTW, I don't argue that WebM is better than x264, because it simply isn't. There is a penalty to pay (somewhere) if you use WebM.

What I do say is that quality is NOT necessarily where one has to pay the penalty. It is always possible instead to pay the penalty in time to encode.

What I also claim is that, given the objective of, and indeed the fundamental RIGHT to, an open web, it is by far preferable to pay the penalty for using WebM (especially if one chooses time to encode as the currency of that penalty) than it is to pay the penalty for using H264/AAC (which is the encumbrances of royalties to be paid, and restrictions to open competition).

Reply Parent Score: 1