So Many H.264 Codecs, So Little Time
MainConcept
The MainConcept codec is used by companies such as Adobe, Sorenson, and Rhozet, the latter for Carbon Coder, a batch-encoding tool that I used to produce the MainConcept files for all three tests. As you would expect in a tool that starts at $5,000, Carbon Coder provides a broad range of well-documented H.264 encoding controls, which display the controls used for the SD encodes. Note that you can also operate the program in a simple mode that shows much fewer controls.
As part of my testing, I compared the MainConcept output of Carbon Coder and Squeeze and found them roughly equivalent, with Squeeze retaining slightly more detail in low-motion settings and Carbon Coder preserving quality better during high-motion sequences. For this reason, I think that you can assume that the findings discussed below apply to all encoding tools that use the MainConcept codec, though mileage may vary, and you never know until you test.
Interestingly, where Rhozet exposes a full gamut of encoding controls, Squeeze exposes only five H.264-related controls when producing MainConcept files, yet it produces near-equivalent quality. This underscores the point that although Compressor and Episode show fewer controls than Rhozet, under the hood, the encoders are applying a similar range of encoding parameters.
SD Tests
For SD tests, I used a test clip that contains about 42 different scenes with varying complexity and motion, from talking heads to twirling Tae Kwon Do. All source clips were shot in 4:3 DV, and I produced the file in Adobe Premiere Pro and After Effects, exporting a scaled, deinterlaced clip from the latter. This is important because various encoding tools use different deinterlacing and scaling algorithms, and some work better than others. Encoding a prescaled, predeinterlaced clip took these variances off the table, so any qualitative differences should be almost totally codec-related.
I produced all SD test files at 640x480 with a frame rate of 30 fps and a data rate of 468Kbps for video and 32Kbps for audio. I produced using multipass CBR encoding using the High Profile and CABAC entropy coding with tools that enabled this selection.
I used the High Profile setting because this is supported in both the Flash Player and the most recent version of the QuickTime Player. I set the keyframe interval at 300 and enabled "natural" keyframes or the equivalent in all encoding tools, which should produce keyframes at all scene changes.
Examining each file within Semaphore, I noticed that while the average data rate was very close among the three files, the Episode (Dicas codec) and Carbon Coder (MainConcept codec) files strayed further from the average than the file produced by Apple Compressor (Apple codec).
Specifically, the peak data rate for Apple was about 920Kbps, while the Carbon Coder strayed up to 1.21Mbps and Episode up to 1.28Mbps despite all three files being compressed in CBR mode.
These data spikes create a risk that when streaming over constrained-bandwidth connections, the Carbon Coder and Episode clips could be interrupted at the peaks, which is always cause for concern, though much less so in the broadband world where most connections are several times faster than 500Kbps.
To try to create an equivalent encoding pattern in Compressor, I tried encoding in VBR mode, but I got the same peak bit rate. I used a variety of techniques to try to reduce the peak data rate in Episode and Carbon Coder, but I never got closer than the results reported earlier.