Linked by Thom Holwerda on Wed 14th Nov 2012 22:12 UTC
Permalink for comment 542738
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 06/13/13 14:35 UTC
Linked by Thom Holwerda on 06/11/13 17:07 UTC
Linked by Thom Holwerda on 06/10/13 23:13 UTC
Linked by Thom Holwerda on 06/08/13 14:57 UTC
Linked by Thom Holwerda on 06/07/13 11:40 UTC
Linked by Thom Holwerda on 06/04/13 12:45 UTC
Linked by nfeske on 05/31/13 10:12 UTC
Linked by Thom Holwerda on 05/29/13 16:59 UTC
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
More Features »
Sponsored Links



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