Quote:
Originally Posted by hello_hello
The way that testing was done makes me wonder how often Apples were being compared with Apples. In some instances CBR was used for one encoder and 2 pass VBR for another. The SSIM tuning was used for x264 but not for x265. Varying keyint settings. When a minimum encoding speed was required and 2 pass encoding was used I'm not sure if it applied to only the second pass, or both passes combined when multi pass encoding was used.
|
As far as I know the encoder developers were asked to provide encoder settings for their encoder. So if an encoder performs below its capabilities its the developers fault. I agree that more specified and constrained use cases would have helped for a more fair comparison but then again not all encoders would have been able to enter for a use case as they are lacking certain features. Its the first time the MSU did an HEVC encoder comparison. Regarding speed requirements, it was all passes combined.
Quote:
Originally Posted by hello_hello
Ignoring those types of differences though, HEVC doesn't seem to be setting the world on fire. According to those tests x265, which generally rated the best in respect to bitrate for a specific quality, still didn't do all that much better than x264. 74% the bitrate of x264 when encoding speed wasn't a factor and around 90% for more realistic encoding speeds. Wasn't the original promise somewhere in the vicinity of 50%?
|
You should not assume that just because x265 did below your expectations in that particular test for HEVC that HEVC as a standard is not "delivering". There was an option to participate in the MSU test and have the results for an encoder to remain private and not show up in the publicly available results. I mean the only interesting encoders in the public comparison are Intel, x265 and Ittiam. There are possibly quite a lot of results kept private or some developers just did not bother to participate. It is a wrong assumption that x265 is the best HEVC encoder out there.