The most widely used delivery codec today on the internet is h.264. There are at least 10 encoders out there from different vendors, but which one is the best? I tried MainConcept (via Vegas Pro 8.0c), SonyAVC (via Vegas Pro 8.0c), Apple’s h.264 (via the latest Quicktime Pro), and x264 (via the latest ffmpeg).
The maximum profile/level is used by the user interface offered. For example, if an encoder only supports the “main” profile I would use that, even if it goes against another encoder that supports the “high” profile. Same goes for CABAC and CAVLC — I used the best options an encoder or its UI can offer me. What I am comparing here is *end-user solutions*, not how the encoder itself could perform tweaked if the sun was black and the moon was red. The source file is a 4 second uncompressed Quicktime 720/30p progressive file. The machine used is my usual 630-P4 3Ghz with 3 GBs of RAM (more specs were given before in this blog). All encodings used 4 mbps CBR, 1 pass, at 720/30p. Quality is compared using a Perceptual Diff utility: I compared frames 1 and 41. Frame 1 is stationary, Frame 41 has lots of motion in it.
A note on Quicktime
I tested both the .mov and the .mp4 h.264 exporting options from Quicktime, just in case they are internally configured differently. Please note that a lot of the quality loss shown below for Quicktime, is because of the gamma change Quicktime applies to these files. In the past, you could go to the video track “properties” with Quicktime, and change the “blend” to 100%, in order to get the original color look back. I would have tested that kind of exporting too, but it seems that the latest Quicktime Pro has this feature broken (it used to work a few months ago with an older version).
So I had to do it manually: I played with a lot of gamma values on PaintShopPro and when I gave it a 0.75 gamma (making it darker, as it was supposed to be), the pixel difference went down to 18,826 and 31,794 points for frames 1 and 41 respectively (down from about 200,000 points). So if Apple stops adding that dithering crap by default, they can deliver a pretty good result by default. “Defaults matter” as users whine and whine.
A note on x264
I used the following ffmpeg switches for the x264 encoding: -me_method umh -subq 5 -coder 1 -trellis 1 -g 300 -qmin 10 -qmax 51 -qdiff 4 -level 41 -rc_eq "blurCplx^(1-qComp)"
I did try to further optimize the x264 encoding like this: -flags +loop -coder ac -refs 5 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 6 -me_range 21 -chroma 1 -slice 2 -bf 3 -b_strategy 1 -level 41 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq blurCplx^(1-qComp) -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -cmp 1 -maxrate 4000k -bufsize 4M, but the video file produced was not readable by Vegas’ MainConcept h.264 reader, and therefore I could not take PNG screenshots off specific frames in order to carry out the comparison. FFdshow and Quicktime could read the file btw. I don’t have all day trying to find needles in a haystack, so if anyone knows which switch creates the incompatibility, let me know and I will update the article.
Update: It’s the -g 300 that created the problem. I removed it, but the resulted video is not frame by frame identical to the original. Some of these “advanced” switches do something really nasty to the video in terms of timing. Because the frames I get at position 1 and 41 are not identical to the original, there can’t be pixel comparison.
Update 2: Now, get this. Using this pretty optimized command line: -me_method umh -subq 5 -coder 1 -trellis 1 -qmin 10 -qmax 51 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -qdiff 4 -level 41 -rc_eq "blurCplx^(1-qComp)" I got over 55,000 pixels of difference. However, it seems that x264 uses a different gamma than the original file, just like Quicktime does so above. So when I changed its gamma using the “Color Corrector” Vegas plugin to 0.925, I was able to get the “true” quality that the encoder is capable of. And that comes out to 16085 for frame 1, and 19597 for frame 41. In other words, if both Quicktime and Ffmpeg were to fix their gamma problems, they are pretty much identical in quality (it’s just that x264 is way faster).
The tests

Conclusion
In terms of quality, it seems that Sony AVC and MainConcept are pretty good here. x264 would probably fair better too if some of their optimization switches are not so incompatible with some decoders or if it fixes its gamma problem. Nevertheless, x264 is the fastest encoder. Quicktime quallity suffers by default more than x264 because of its extreme gamma changes. If Apple wasn’t doing that gamma change by default, it would fair much better, as my gamma test shows. Download the OpenOffice .ods spreadsheet file here.