Linked by Thom Holwerda on Wed 14th Nov 2012 22:12 UTC
Permalink for comment 542707
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-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.