First Look: Apple Compressor 4.1

Seeking to understand the quality difference, I analyzed all the files in Inlet Semaphore, which was discontinued after Inlet was purchased by Cisco. Among other file details, Semaphore identifies key frames in the stream, and showed that with the QuickTime files, multi-pass encoding inserted a key frame every 90 frames, rather than the requested 300 frames, which is the interval used for the single-pass, CABAC file. With the MP4 output, in my test file, Compressor inserted just a single keyframe at the start of the clip, while with other files, it inserted a key frame every 90 frames, even though I requested 300 in all cases.

To determine if the key frame interval was responsible for the quality difference, I reencoded the single-pass CABAC file using a keyframe interval of 90 to both MOV and MP4 formats,  and saw minimal difference between the original files produced with an interval of 300. So the fact that the multi-pass clips were encoded with a key frame interval of 90 wasn’t it.

I then encoded to both MOV and MP4 formats using single-pass encoding and CAVLC, as opposed to CABAC, and saw a minor quality drop, but not sufficient to make up the difference between multi-pass and single pass. So it wasn’t entropy encoding technique, either.

I then expanded testing to incorporate other synthetic test files, which all include multiple scenes of varying content with changing levels of detail and motion. In general, the results were consistent with those from the 720p test clip; single-pass CABAC was almost always better than multi-pass CAVLC.

Then I started encoding regular video clips from various projects and sources. In general, if the clips were relatively consistent, say a single camera talking head, the results reversed, and multi-pass encoding with CAVLC produced better results than single-pass CABAC. As the clips gained motion and complexity, the results started to turn around, and single-pass CABAC proved the better option. In all tests, the output from the x264Encoder was always the highest-quality option.

As you’ll learn in the next section, Apple’s new “hardware-based” H.264 encoding is only available with single-pass encoding, which means a completely different technique is being used for multi-pass encoding. To me, this feels like there are two H.264 codecs involved, one hardware-accelerated, the other not.

Long story short, my best advice for those using Compressor 4.1 would be to use the x264Encoder, which I explain how to do here. Unfortunately, you can’t use the x264Encoder with MP4 or M4V output, since it’s a QuickTime plug-in which doesn’t work with the other outputs. If you must use the Apple codec, I would try both techniques, first single-pass with CABAC, then multi-pass with CAVLC, and see which produced the best result. Note that at its best, Compressor 4.1 produced better quality using the Apple codec than previous versions of Compressor, which showed very little quality difference between single and multi-pass.

Where does Compressor 4.1 rank competitively? In addition to the 720p tests, I ran a series of comparisons using an older 640x480 clip encoded to 468 kbps video/32 kbps audio. While there were some outliers, like the exceptionally high motion clip shown in Figure 7, for the most part the Apple codec was only slightly behind x264.

Figure 7. In my SD test clip, one-pass CABAC was better than multi-pass CAVLC, and x264 was better than both. 

Overall, at its best, the Apple codec produces better quality than the MainConcept codec, which is the only H.264 codec used in the Adobe Media Encoder, and is also an option in desktop tools like Sorenson Squeeze and Telestream Episode. Note that Squeeze also comes with x264, and Squeeze’s x264 output is better than Apple’s at its best. With Episode, you’ll have to pay an additional $99.00 for x.264 which will allow Episode users to produce slightly better quality than Compressor.

As a final quality note, I was never able to produce even acceptable quality with the podcast output. Given this, and the relative paucity of configuration options, I recommend using the MP4 output instead.

One great option that carried over from previous Compressor versions is the ability to produce the chunked MPEG-2 Transport Stream and metadata files necessary for Apple’s HTTP Live Streaming (HLS) adaptive streaming technology. As a final quality control check, I ran these files through Apple’s Media Stream Validator tool to ensure their compliance with the format, and they passed all tests.

Performance

Before getting into my performance results, let’s talk about the performance-enhancing features in Compressor 4.1. As mentioned, Apple removed Qmaster in favor of the ability to enable additional instances in the preferences dialog. From my perspective, that’s a good move, though Qmaster worked well when it worked, it hardly ever worked reliably for me. That said, if you check Activity Monitor with Compressor running, you’ll see multiple Qmaster processes running, which is a bit scary; maybe they’ve been rewritten, maybe not.

According to Apple help files, the number of additional instances that you can enable relates to the number of cores that you have installed on your system, and the amount of memory. On my 8-core (16 with HTT) system with 16 GB of RAM, I could enable three additional instances for a total of four. In Figure 8, you can see Compressor happily processing four files simultaneously, and this is the configuration that I used in my tests below.

Figure 8. I enabled three additional Compressor instances in my tests.

The other performance improvement related to Apple’s hardware-based H.264 encoding. For the record, everything I know about hardware-based encoding comes from Larry Jordan, both from his website, and a conversation about the Compressor update (thanks, Larry). This description is taken from his website.

• Hardware encoding is enabled automatically within Compressor. If your system has the right set of chips, and you select the right compression setting, hardware encoding kicks in.
• Hardware encoding is available on all shipping Macs that use an i5 or i7, Sandy Bridge or Ivy Bridge processor.
• Hardware encoding is applied to QuickTime and MPEG-4 compression that uses the H.264 codec; but not to Blu-ray Disc compression.
• Hardware encoding cannot be used for multi-pass encoding. In fact, turning on multi-pass encoding turns off hardware encoding.

Interestingly, Jordan also tested multiple files, and noticed that on the highest motion file, a dance clip, single-pass encoding produced higher quality than multi-pass.

Beyond these rules, Apple’s help documents indicate that hardware encoding also doesn’t work when you enable additional instances. In fact, the Compressor 4.1 help file says the following:

Note:  If the computer has a hardware encoder, and if you enable multiple instances of Compressor, the time it takes to process a batch can potentially increase, because the hardware encoder can only be used with single-pass, nonsegmented jobs. If you find that processing time has increased significantly, turn off additional Compressor instances by deselecting the “Enable additional Compressor instances” checkbox.

So, if you produce the best quality with multiple-pass encoding, then enable additional instances if your computer supports it. If single-pass delivers the best quality, don’t enable additional instances.

This second scenario reflects my situation, since my Mac Pro Xeons supported neither Sandy Bridge or Ivy Bridge. Accordingly, I produced all Compressor results using single-pass encoding, which I also used for the other encoders. I used the x264 codec for Squeeze and Episode, using the default Medium quality preset.

Of the three tests shown in Table 1; the first two are self explanatory, the third involved the output of nine video and one audio file to MP4 format for encoding in HTTP Live Streaming (HLS) format. For this test, I used the configurations suggested by Apple TechNote 2224, which strangely enough, Apple didn’t use when creating Compressor’s presets for HLS output.

Table 1. Performance trials.

Unfortunately, almost any way you look at them, Compressor’s results are totally idiosyncratic to my encoding station and test results. That is, if you have a computer with hardware acceleration, your single-pass-encoding times should be faster, but if you find that multi-pass acceleration delivers better quality, they’re totally irrelevant. On my Mac Pro, encoding time in the second test jumped from 40 seconds to 1:49 for multi-pass, while the encoding time for a three-minute 1080p clip jumped from 1:48 to 6:47. The bottom line is, your performance results with Compressor will vary significantly based upon whether your encoding station has hardware acceleration, has sufficient resources to enabled additional instances, and the encoding method that works best on your clips.

To close, let me say that 95% of Compressor users likely encode at data rates high enough to eliminate any quality difference between single-pass and multiple pass. For these users, Compressor 4.1 will be a lifesaver (assuming it installs without difficulty), because almost any way they use it the results will be favorable. For advanced users seeking to optimize encoding quality and data rate, or encoding efficiency, Compressor 4.1 will simply be frustrating, a multiple variable equation that you’ll have to calculate on a clip-by-clip basis.