Thanks for the slides.
Slide 12 is especially interesting because it comes so close to being real, useful information.
It's strange that they chose to give PSNR decibels, instead of filesize percentages, as a measurement. It's grudgingly acceptable if they only focused on a single bitrate or QP, but the slide itself noted that on the CQP graph, they did the full 4-point measurement necessary for reliable delta-filesize summarization. That meant they had the RD curve right in front of them, but they chose to measure the less "real" axis (PSNR db). Well, let's try our best to speculate anyway, as Intel's methods are similar to the "official" MPEG/JCT ones and I highly doubt they reinvented the wheel in regards to how they approach quantization parameters.
We first need to reproduce Intel's PSNR vs log-bitrate graph. Old JCT docs testing the reference JM encoder
very reliably produce a ~9 db PSNR gap between QP22 and QP37. Filesize spreads there are harder to summarize, but I say an ~8x (mostly between 6x and 10x) size spread between smallest and largest encode per clip is a good average. Assuming there isn't something wrong with the encoder, this log-log RD graph (PSNR-to-logSize) should then be linear in this range, which means each
extra 0.1 db encoder quality bump would correspond to a new file being ~97.7% of the original size for the same quality. The full 0.7db increase going from Haswell-TU7 to TU1 would then suggest that TU1 files are ~85% of TU7's size for the same quality. (Using a 6x spread changes the last number to 87% instead. 10x to 83.6%)
Algorithmic metrics have their downfalls, of course, but having a numeric starting point as rough guidance is better than having nothing at all. Additionally, while the above is entirely speculatory, based on the limits we know exist, I doubt independent testing with better metrics (SSIM or preferably MS-SSIM) would produce something much different. Still, it'd be nice to know specific numbers for ourselves. I've been waiting for the compression folks at
MSU to release their yearly report, but they've been silent lately.
If anyone has Haswell and can share encodes spread over 4 points on some common
raw test sequences, I can help with the number crunching.
And after that's done, it'd also be nice to aggregate encoding speed, combine it with quality/delta numbers, and compare it to x264 and produce something
like this.
