Streaming Learning Center Where Streaming Professionals Learn to Excel
Related Articles
Apple introduced Compressor 4.1 in mid-December. I just spent four days with the tool, and I can’t synthesize the results. All I can offer is a series of observations that will transfer the knowledge that I’ve acquired, and hopefully, allow you to make your own decision about whether to buy or upgrade.
Here are the key observations in roughly the order presented in the review.
- Some users, including me, experienced some issues when installing and running the program, though I was able to get all of them resolved. Others weren’t so lucky; at the time of this writing, Compressor 4.1 had 14 five-star ratings on the App store, and 18 1-star. Most users either love it or hate it.
- Compressor 4.1 has enjoyed a major facelift, which makes the program much easier to use and much more accessible to users. Apple also enabled crucial H.264 options like the High profile and entropy encoding selection. On the other hand, the low-level plumbing hasn’t been completely refurbished; it’s still a 32-bit program that uses three different interfaces for producing H.264 files for Internet delivery. And you still can’t directly choose constant or variable bitrate encoding, which is a critical configuration option.
- Compressor 4.1 produces very good quality, much better than previous versions of Compressor. But how you get there is confusing; with some files, multiple-pass encoding, supposedly the highest quality option, was clearly inferior to single-pass encoding. With others, the opposite was true. So you may have to encode each file both ways to identify the best option.
- Apple removed the quirky QMaster from the program and added the ability to add Compressor instances within the program. However, if you check Activity Monitor you see processes named QMaster running; does that mean multiple instances will be just as quirky?
- Apple added “hardware-based” H.264 encoding, but you can’t tell whether your Mac supports it. In addition, hardware-based encoding doesn’t work if you enable multiple-pass encoding or if you’ve added Compressor instances. So in addition to testing whether single- or multiple-pass encoding produces better quality, you may have to test to see whether using multiple instances is faster than hardware-based encoding.
If I had to come down one way or the other I would say give it a shot; the extra quality may be worth it, and the new interface is quite nice. Just be prepared for a bumpy ride on install and when figuring out how to configure your encoding settings. Here’s a quick video tour of Compressor 4.1
So, let’s begin. In this review, I’ll describe the new interface, and then discuss quality and performance. Note that I’ll be discussing only the standalone application, not its interaction with Final Cut Pro X. I also only tested streaming formats, not Blu-ray or DVD.
Contents
Getting Started with Compressor 4.1
Let me start by saying that my test computer is a circa 2009 MacPro with two 2.93 GHz Quad Core Xeons and 16 GB of RAM. This means that it has many older versions of Final Cut Pro and Compressor installed, and three versions of OSX. It’s about as far away from a clean install as you can get. Still, it’s a computer I use every day for writing (Microsoft Word, Adobe InDesign), creating presentations (PowerPoint), editing and authoring (Adobe Creative Suite), creating screencams (Techsmith Camtasia), and encoding (Adobe Media Encoder, Sorenson Squeeze, Telestream Episode) with very little muss or fuss.
I’m sure Compressor 4.1 is working fine for many, if not most users; unfortunately, I was not one of them. In my case, once installed, Compressor worked fine during the initial installation, but I rebooted, jobs wouldn’t start encoding, they just displayed a “waiting” notice, and refused to cancel. Then I started getting an “Unable to submit to queue” error message (Figure 1). Long story short, I had to uninstall using a free utility called FCS Remover (thank you Digital Rebellion), delete some folders in the user library and reinstall. Ultimately, this worked, though if you Google “Compressor 4.1” and “FCS Remover” you’ll find some posts that indicate that I was a lucky one.
Figure 1. Never a good sign, and this signalled the need to uninstall and reinstall.
During my testing, I occasionally experienced jobs that wouldn’t cancel, a seeming hangover from previous Compressor versions. One time I opened a previous version of Compressor while 4.1 was open. This proved to be a bad idea; not only did I experience jobs that wouldn’t run or cancel, but once I rebooted, all of my Compressor 4.1 settings were deleted.
In the end, program operation was very stable. Still, if you’re going to upgrade, I wouldn’t do it at a time when I had projects to deliver. And I wouldn’t do it without Googling “Compressor 4.1” and “FCS Remover” to get a feel for the problems that potentially lie ahead.
With this as prologue, let’s get to heart of the review.
The Shiny New Compressor Interface
Figure 2 shows the new interface. Up top are three buttons, Current, Active and Completed. The figure shows the Current view, which is where you create your presets, import your source files, choose your locations and create your batches. On the left side is the Settings and Locations pane, which you use to toggle between Settings and Locations. You can build a setting from scratch, or duplicate any built-in setting and customize that.
You make all modifications to settings in the Inspector pane on the right, which is currently inspecting the selected Job (CM2.mov). We’ll get a better look at the Inspector pane below, but it has only three panels (General, Video and Audio), so all the individual panes in previous versions are gone (and not missed at all). In the top center is the Preview area, with the Batch area below that.
Figure 2. Compressor’s new interface.(Click on image to see full-size version.)
The new workflow paradigm includes Settings, or encoding presets, Locations, which is where you save the encoded file, and Actions (on the bottom right of Figure 2), which are steps taken after the file is encoded and stored in the target location. There are also Destinations, which is where Compressor sends the file after the action. Figure 3 shows a close up of the Settings pane, where the top settings with the blue arrow are destinations, which include one or more settings, plus an action.
Figure 3. Settings and Destinations. (Click on image to see full-size version.)
To explain Destinations further, I’ve highlighted Create DVD in Figure 3. The two settings are for the audio and video elementary streams. The post encode action is to configure the menus, while the final destination is the DVD. When you drag a destination onto a source file, all you have to do is make sure you complete the settings and/or provide the necessary login information, and Compressor takes care of the rest. Operationally, it’s not much different than in previous versions, but it works better in some cases and is much easier to understand.
The basic encoding workflow is simple; you input either a single or multiple source files, either using menu or button commands or drag and drop, and then apply a setting or settings or destination or destinations. If you select multiple source files and then apply a setting or destination, the applied setting/destination applies to all selected files, which is very efficient. You can apply one or more video filters like text overlay, watermark, fade In/Out and gamma correction to your source files, as well as audio filters like fade in/out and a graphics equalizer. The preview window will show these effects as you add them, but doesn’t simulate the affects of your compression settings; to see those, you’ll actually have to encode. When you’re ready to start the batch, you click Start Batch on the lower right and off you go.
Once encoding starts, you can follow the action by clicking the Active button on top; Once encoding is finished, the batch is stored in the Completed view. If you’re running experiments, you can click a Reuse button in the Completed view and reload the source file and settings, make any adjustments and re-encode, which is often very useful to fine-tune your configurations.
Confusing Configuration Options
So far, so good, the new interface is very well thought out and highly usable. The problems appear when you start to dig beneath the surface. The biggest problem is that there are three interfaces used to create H.264 files for different deployments, which is confusing. Specifically, as with Compressor 4.07, there were three different interfaces for configuring the H.264 encoding parameters for files targeted for device playback (.m4v), QuickTime playback (.mov) and HTTP Live Streaming (.mp4), all with different terminology and controls. For example, for QuickTime playback, you controlled H.264 parameters in the QuickTime codec panel, for MP4, in the Inspector panel, for M4V, in the Inspector panel with completely different controls.
When producing MP4 files, you can directly change the H.264 profile, and the key frame interval was called, well, the key frame interval. When producing m4v files for devices, you can’t choose the profile, and the key frame interval is called Frame sync. 
Figure 4. Compressor retains the three different interfaces for encoding H.264, which is unnecessarily confusing.
There are some improvements to the H.264 configuration options, including the ability to access the High profile for the first time, as well as entropy coding controls (CABAC vs. CAVLC), though strangely, CABAC is unavailable when you choose multi-pass encoding. Overall, however, Apple missed an opportunity to simplify producing H.264 for different outputs, and as a result, the program is more confusing that many of its competitors.
Confusing Quality Options
Things really started heading south for me when I started running quality tests. By way of background, you expect a learning curve when working with a new or substantially updated program, but in the end, you almost always “grok” the program, understand how it works and why, and produce generally consistent results. With Compressor 4.1, I didn’t get there.
By way of background, my biggest problem with previous versions of Compressor, multiple interfaces aside, was that the Apple H.264 codec was sub par. No problem, I simply installed the x264Encoder QuickTime plugin which works within Compressor to produce much better results. This still works in Compressor 4.1, though only when producing QuickTime files, not MP4 or M4V, which is a serious limitation.
Anyway, once I heard about the upgrade, my first question was how the quality compared to x.264. So, in Compressor 4.1, I encoded my standard 720p test file to 800 kbps video/128 kbps audio using the x264Encoder and Apple codec, producing the result shown in Figure 5, which showed no improvement.
Figure 5. x264 vs. the Apple codec; no contest.
During the first round of tests, I noticed that when I enabled multi-pass encoding, which Apple recommends for the best quality, entropy coding switched from CABAC, the higher-quality option, to CAVLC, which delivers lower quality but is easier to decode. In fact, you can’t use CABAC with multi-pass encoding; the option is grayed. So I decided to try single-pass encoding with CABAC enabled, producing the result shown in Figure 6. Here, single-pass CABAC encoding was vastly superior to multi-pass CAVLC, and almost (but not quite) as good as x264.
Figure 6. Single-pass CABAC vs. Multi-pass CAVLC.
I then tested the same scenario using MP4 output, and produced the same result; the single-pass CABAC file exhibited much higher quality than the multiple-pass CAVLC. I couldn’t run the same tests for the M4V file produced for podcasting because you can’t choose either the profile or entropy coding technique.
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 640×480 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.
