New Mac Pro: Adobe Media Encoder vs. Compressor [Updated]

Posted on by Larry

[ Please see my disclosure statement on product reviews. ]


This article has generated a lot of readers and discussion. In the week since this article was first published, I had the opportunity to continue researching the differences reported here on Apple’s website, as well as talk with Patrick Palmer, the Senior Product Manager at Adobe, who is responsible for Adobe Media Encoder. In my continued research, I realized that there were a number of significant mistakes and false assumptions I made in the first version, so I updated this article and retested both programs.

Last week, I compared the speed of video compression on an iMac vs. the new Mac Pro. (Read the article here.)

This week, I decided to continue this comparison by comparing the speed of Apple Compressor to Adobe Media Encoder (AME) on the new Mac Pro. And I discovered that testing video compression software is MUCH more complicated than I first thought.


It is incorrect to simply compare the speed of video compression without also comparing image quality. All other settings being equal, lower bit-rate settings will compress faster than higher-bit rate settings. If file sizes are radically different for the “same” setting, which they were in my original tests, it means that the bit rate settings are also significantly different. Similar bit rate settings should yield similar file sizes, though not, necessarily, similar image quality.

The H.264 codec, like all standardized codecs, describes what the finished compressed file should look like. However, different developers will take different paths to get to that result and those different paths can result in different compression times with, potentially, different image quality. (Think of this as climbing a mountain, there are many paths to the top, but only one peak once you get there.)

In this retest, we look both at speed and image quality for MPEG-4 compression. I chose MPEG-4 because both applications support it extensively, and it is the preferred video codec for all Apple devices.


There are significant variations between Apple Compressor 4.1 and Adobe Media Encoder 7.2, in both speed and quality. While it would be true to say that AME is generally faster, it is not true to say that it is consistently faster.

NOTE: This article is based on tests run on the new Mac Pro. I would expect similar results on iMacs or MacBook Pros, though the compression speeds will be different.

Even more surprisingly, when using default settings in each application, the compressed file sizes can vary by hundreds of megabytes. This indicates that simply using the default settings may not be sufficient to get the best results. For some codecs, such as QuickTime, getting the settings to match between the two programs is difficult. For others, like MPEG-4, settings are easier to match.

For some tasks, Compressor is a better choice. For others, AME is a better choice.


In the original article, I wrote: “And neither application takes advantage of all the power that the Mac Pro has to offer.” Except that isn’t completely true. In fact, its downright murky.

Adobe Media Encoder (AME) does take advantage of both graphics cards in the new Mac Pro, provided the Mercury Playback Engine is enabled. Apple Compressor does use the GPUs when exporting from Final Cut Pro X, but not when compressing within Compressor. Compressor does access hardware acceleration on Macs that support it, such as iMacs and MacBook Pros, but not on the Mac Pro. AME does not access hardware acceleration at all.

Some codecs are single-threaded, which means even if you tried to use all the resources on a Mac Pro, the codec itself would throttle performance. Some codecs, such as ProRes, fully support multi-threading. For multi-threaded codecs, the operating system handles parceling out compression tasks to the CPU, rather than the application. Simply watching CPU load in Activity Monitor does not provide a full picture.

There are three basic steps in compression:

  1. Export from the application. Both FCP X and Premiere Pro CC are optimized to export as fast as possible.
  2. Rendering. This involves scaling, speed changes, video effects. Here, speeds are gated by the application.
  3. Encoding. This is the actual compression process using the codec. Here, speeds are gated by the codec.

In AME, all rendering functions use the Mercury Playback Engine, which is a very fast rendering engine that is GPU-accelerated in most Macs, but not the MacBook Air. In the Air, the Mercury Playback Engine uses the CPU.

Like I said, “murky.”


I’ve been using a Mac Pro for a month for testing and writing articles. (You can read my first review of it here.)

The Mac Pro I used for testing has:

NOTE: There was debate in last week’s article about whether the processor speed of the iMac offset the extra cores and GPUs in the Mac Pro. This week, I ran all the tests on the same computer, which would make the system performance the same for both applications.


I’m running the latest version of Adobe Media Encoder with all its default installation settings.

The biggest thing to note is that Adobe Media encoder is a 64-bit application, which allows it to take full advantage of all the RAM contained in the Mac Pro. (Look in the “Kind” column.)

I’m also running the latest version of Apple Compressor, also set to its default settings.

NOTE: I ran these tests with Compressor in single-instance mode. Running Compressor in multi-instance mode can speed compression of some codecs, such as H.264, though not others, such as ProRes. However, I discovered that running Compressor in multi-instance mode can sometimes conflict when also running Final Cut Pro X. So, to emulate my real-world conditions where I run both programs at the same time, I tested in single-instance mode only.

The biggest point here is that Compressor is still a 32-bit application. Which means that it can only access 4 GB of RAM. As you will see, that may, or may not, have an impact on its speed. (Again, you can monitor this for yourself using Utilities > Activity Monitor > CPU tab and look in the “Kind” column.)

As an interesting aside, Compressor doesn’t actually compress video. Instead, a background application called “compressord” does all the heavy lifting. This is why we can quit Compressor, once compression starts, without affecting the compression itself.


While it is true that AME is 64-bit, vs. 32-bit for Compressor, when it comes to video compression this is less of a factor than might at first appear. Most codecs only require 1-2 GB of RAM for compression. A BIG benefit to remaining a 32-bit application is that Compressor is able to support legacy 32-bit codecs, such as DVCPROHD and older camera-native codecs.

Another note about Activity Monitor is that it has no way of displaying how busy the GPUs are for any task.


In my original tests, I used the same four video files I used in last week’s tests:

My principal goal was to test the speed of the two applications. I was not trying to achieve the highest quality, nor the smallest files. To meet this goal, I tried to keep settings identical between the programs. However, over this last week, I discovered my results were flawed because the settings did not match closely enough.

For the second set of tests, I used:


As I mentioned at the beginning, measuring speed without also looking at quality is not particularly meaningful. This week, I created new tests specifically to look at whether I could better match the settings to compare results, as well as examine image quality.

For example, here are the settings I used for the MPEG-4 movie in Adobe Media Encoder.

NOTE: Up until the 7.1 release, Adobe Media Encoder was missing too many features to make a comparison with Compressor even feasible. For the first time, in my opinion, AME and Compressor can now be reasonably compared to each other.

In my first report, I ran 24 tests on each application, using my four different media files. For the custom QuickTime and MPEG-4 tests, all bit rates were set to 2,000 bps.

In this updated report, I ran 14 tests on each application across the two test files. I used variations on their default YouTube settings and a custom MPEG-4 setting with a bit rate of 2,000 kbps.

NOTE: Neither application supports the H.265 codec and I did not attempt to run the X.264 open source version of H.264.


This screen shows Compressor (actually “compressord”) chomping its way through a movie. Notice that it is only using 182% of all the CPUs. (The maximum is 100% times the number of virtual cores, or 2400%.) Notice, also, how none of the processors are working very hard; the average CPU usage is 7.72%.


While this is a true statement, we are missing any measure of how hard the GPUs are working. In fact, Activity Monitor provides no GPU tracking at all. All this means is that the CPUs may be mostly idle because the GPUs are working extra hard. There’s no way for us to easily know. CPU load will vary by codec. For example, ProRes encoding uses CPUs and GPUs much more extensively.

This screen shows Adobe Media Encoder munching its way through a file using almost 1100% of total CPU power. Notice how it uses system resources much more intensively and the processors are much busier; though even here the average CPU usage is only 44.15%.

Take-away? Don’t judge speed solely by Activity Monitor.


This table is a subset of my initial results – I removed the portions that were most incorrect. However, even here, notice the huge variations in file sizes. This is a clear indicator, though I didn’t realize it at the time, that we were comparing kumquats to rudabegas. I was using default settings, but the default settings did not match.

(Click the image to display a larger view of this spreadsheet.)

In my research and conversations, it became obvious that I made two significant mistakes in my original methodology. First, was that I did not check for image quality as well as speed. Second, the large file size variations indicate major differences in data rate; which affects both compression speed and image quality.

So, I went back and retested, focusing just on MPEG-4.


(Click the image to display a complete view of this spreadsheet as a PDF.)

The most obvious finding in the new results is that the default settings used by AME and Compressor use different bit rates, MPEG-4 profiles, and methods of matching frame rates. When those are adjusted to match – as closely as possible – the compressed file sizes and data rates are almost identical.

When compressing files without scaling the image size, Compressor has an edge in single-pass encoding, though the Mac Pro does not use hardware acceleration, while AME has the edge in multi-pass encoding.

When compressing files that require image scaling, both applications are about the same speed in single-pass encoding, while AME retains its lead in multi-pass encoding. Again, file sizes were within 500 KB of each other.

Image quality for both software was excellent with data rates of 5 mbps or greater. These would be typical compression settings for YouTube. However, when the data rate dropped to 2 mbps, which is more typical for posting to a local website, AME had better image quality, with Compressor exhibiting artifacting and lack of detail around edges. More on this in a minute.

In general, AME was faster compressing MPEG-4 video, but the speed differences and file sizes were MUCH closer between the two applications.


There’s a checkbox at the bottom of the AME’s settings pane that is off by default, called “Use Maximum Render Quality.” When I was talking with Patrick Palmer, I asked him about this.

When you are scaling an image (meaning you are changing its size from bigger to smaller), turning this on accesses a higher-quality scaling algorithm that will improve the image quality of the reduced image. However, it will also increase compression time. If you are not changing the size of an image, you can leave this off.

Initially, based on Patrick’s comments, I was tempted to leave this off, because it would slow compression down too much. However, in my testing, I saw virtually no difference in compression speed when this was turned on. Nor, for that matter, did I see much difference in image quality. If you are reducing an image by 50%, leave this off. Otherwise, it probably won’t hurt to turn it on.

As a side-note, if you are enlarging an image, Patrick recommends using After Effects, rather than AME. After Effects just improved all its scaling algorithms and enlarging an image in After Effects will look better than enlarging an image in AME.


In the retest, I also wanted to compare image quality. While image quality at the higher bit rates was excellent in both software, there were noticeable differences. Here are three examples.

(Click to see a larger image.)

Here is a comparison of the original file on the left, and the Adobe Media Encoder file compressed for YouTube at 10 mbps on the right. Notice the a lack of color with a color shift toward red in the compressed image.

(Click to see a larger image.)

Here is a comparison of the original file on the left, and the Compressor file compressed for YouTube at 10 mbps on the right. There seems to be a slight decrease in saturation, but the color seems quite accurate.

(Click to see a larger image.)

However, when the data rates dropped from 10 mbps to 2 mbps, there was a decided difference in image quality. The AME compressed file is on the left, the Compressor file is on the right. The settings were as close to identical as I could make them – 2 mbps, multi-pass, MPEG-4 Main profile. Keep in mind that this frame is in the middle of her spinning rapidly in the shot.

The AME image is better. Compare the pink piping in her top – visible in the AME version, blurred in Compressor. Look at the edge of her lips and nostrils. Sharp in AME, but with artifacts in Compressor.

Every compression setting will yield different results. It is not correct to say that AME is consistently better, but it is better in this specific instance. What I do want to emphasize is that spending time tweaking your compression settings can improve your results.


Though AME was generally faster, AME was less flexible in many of its settings. For example, based on my first tests:


The biggest lesson, for me, is that just because a setting is a default setting, does not mean it has the same properties as a similar default setting on other software. I forgot what I teach in my own training: The principle determiner of file size is bit rate. If file sizes are significantly different, then the bit rates don’t match. Which means that the settings don’t match, which probably also affects image quality. In my initial tests, I wasn’t paying enough attention to the individual specific settings.

There are multiple ways to compress a clip, yet still end up with a compliant file. Different methods of compression, like different paths up a mountain, will yield different results yet still take you to the same place. However, simply considering speed without also considering image quality and file size is inadequate.

When I took the time to match settings, the resulting file sizes are very similar. When bit rates suitable for YouTube are used, the image quality of both applications is excellent. As bit rates decrease, image quality starts to suffer. Which is an excellent reason to test your settings whenever you are compressing a new movie.

Neither of these applications yields exactly the same speeds or compressed file size. What this means is that if you are having problems getting a file to the size you need, or compression is taking too long, or you don’t like the look of the compressed file, try another compression application.

There is no obvious reason why Adobe is so slow at compressing screen capture movies. If screen caps are your life (think training), Compressor is probably better choice.

If MPEG-4 is your prime focus, AME may be the better choice. If QuickTime movies are your primary focus, Compressor wins. AME is the best choice for Flash. Compressor for HTTP Live Streaming.

For me, the biggest take-away is the complexity of something as simple as video compression. Legacy codecs force software to keep one foot in the past, while hardware changes force them to keep another foot in the future. We are still in the very earliest days of optimizing compression for the Mac Pro and today’s hardware. As I learned, video compression is both a test of the hardware and the programming artistry of the engineers writing the software.

While both Adobe and Apple each have something to brag about, both applications are also an evolving work in progress.

Bookmark the permalink.

37 Responses to New Mac Pro: Adobe Media Encoder vs. Compressor [Updated]

Newer Comments →
  1. William Hohauser says:

    This mirrors my experience with AME and Compressor. There are things going on deep within the architecture of how these programs work that make for some odd experiences if one is observing. One point I’d like to make is that both programs are dependent on codec encoding programming not the GUI shell that we use to choose settings so whether Compressor is 32bit or not isn’t the issue, it’s the encoder that counts. And I have found that different encoders access the processors differently in both programs. AC3 encoding only activates one core in Compressor for example while most of the video codecs hit half the cores listed in Activity monitor (on my 8-core) if Multi-threading isn’t activated. However if you choose BluRay in Compressor, when the program starts the h264 encoding, the entire core list lights up to about 75% without Multi-threading activated. H264 in other setting doesn’t do this. AME is more consistent in lighting up the processors than the encoders in Compressor but as you found out that doesn’t always translate to faster or better performance. While Multi-threading generally gives Compressor the speed advantage sometimes this is not always the case as the file fragment stitching process causes the speed gains to be lost.

  2. ryan says:

    Sometimes I think we’re not seeing the performance we should out of these apps because the trend is that they need to run on all new hardware. Back in the “old days” (i.e. the Quicksilver G4 Towers, let’s say) Apple and others had no problem putting out software that might not run on say an iBook G3. If there was a new encoder written from the ground up, strictly for the new Mac Pro, I’d imagine the performance would be significantly increased. Pro software required pro hardware.

  3. David Arbor says:

    Thanks for doing this, Larry! It was really informative, and it’s such a shame that there are so many inconsistencies. As AME gets updated more I’m sure more and more processes will become GPU accelerated. Speaking of which, you said you used the default settings in AME, and it seems like the answer is ‘yes’ because of the scaling and watermark tests, but were you using the OpenCL renderer? If your graphics card isn’t certified then I don’t think it would default to being turned on, and since the Mac Pro wasn’t out before 7.2 was released then it wouldn’t have even had a chance to be certified.

  4. Lee Berger says:

    Thanks for your excellent article. I did find two of your assertions that you may want to reconsider. You said that “AME does not support compressing DVD audio into AC3 files. ” If you double check the DVD settings, there are three audio choices: PCM, MPEG and Dolby Digital. Under Dolby Digital you can choose bit-rates from 128 to 448. You also noted “Adobe Media Encoder does not allow setting bit rates for audio compression, only sample rates.” That’s only ture true for QuickTIme settings including H.264 in a QT wrapper. If you choose an Mpeg 4 setting, you have more audio choices including ACC, Dolby Digital and MPEG. To me if you are uploading to YouTube or Vimeo there’s no advantage in choosing H.264 as Mp4 or H.264 in a QuickTime wrapper. That is unless you prefer one of the QuickTime H.264 encoders such as the x264 encoder. I find the Adobe H.264 encoder to be quite good.

    Up until 2013 I was quite a fan of Compressor, but but got tired of problems with multi-processor encoding. Often one core would fail in the process. AME is always multi-core and now takes advantage of CUDA and open CL. On my Octo MacPro with FX4800 video card, H.264 encodes are often 2x real time. I am also pleased with the addition of more filters and a professional Timecode overlay. This makes window dub encoding much faster than Compressor and the timecode is easier to read as you can adjust the background opacity. To me the problem with Compressor is that they’ve updated the UI, but not the underlying engine, the 32-bit compressord application.

  5. William Hohauser says:

    Having just completed some h.264 encoding with Compressor 4.1, there are two things I would like to mention.

    1) The transcoder program in 4.1 is no longer called ‘compressors”, it comes up as “CompressorTranscoder”. There’s no way I know of to tell if it’s 64bit or not.

    2) Following instructions from a previous post by Larry, I switched the video encoding from multi-pass to single just to see what would happen. First of all, what was a 3 minute encode dropped down to 40 seconds with little in the way of image degradation. Second, in multi-pass, fewer processors were enabled. Single pass enabled all the processors to around 75%.

    • Larry Jordan says:


      Hmmm… I am running a test now on the Mac Pro, Compressor 4.1, and the background process is named “compressord” when compressing for MPEG-4 or QuickTime. However, I have seen “CompressorTranscoder,” but can’t remember what process I was running that enabled it.

      You can see if an application is 32-bit vs 64-bit using Activity Monitor (Utilities > Activity Monitor) and displaying the Kind column. Compressor and compressord are both 32-bit.


      • William Hohauser says:

        Yes, it is indeed called “CompressorTranscoder” and it is 32bit. I just made a set of h264 files in varying sizes of the same file using the stock Compressor Video Sharing settings with the single-pass adjustment except for one transcode and this is what happened on my 2009 8-core MacPro:

        HD1080p – 1000% CPU usage – CPU graph hovered over 80 to 85% on the 16 bars
        HD540P – 750 to 800% CPU usage – CPU graph hovered between 70 and 75% on the 16 bars
        Small (left this in multi-pass) – 500% CPU usage – CPU graph hovered around 500% on 8 alternating bars and around 5% on the rest.

        I do not have multiple instances set up as they stall Compressor completely, I have been in communication with Apple about this as it’s been a running issue with Compressor and the old Qmaster on my MacPro for awhile. I probably need to do a clean system install but work prevents me from a drastic measure like that.

        • Al B. says:

          Interesting. What version of the OS are you using? It would seem an older version as it appears from both Larry and your results that the new version on the new MP is running in some way that the process is not capable of taking the whole CPU while on yours it is. I don’t know enough of how the Mac OS handles threads to understand why the newest OS doesn’t use all available memory to do a conversion task like this. Bottom line is that you’d think it would allow for much faster operations than Larry is getting and that if they ever rewrite it into 64 bit, it’s likely to really be much faster.

          • William Hohauser says:

            Once my new MacPro arrives, I’ll be able to give it a test. Some time in February unfortunately. Right now I am running 10.9 updated completely.

            There seem to be things going on that maybe an experienced programmer could clarify for us. I just made some DCP files of the same project for digital projection and watched the program in Activity Monitor as it used the CPUs. Just like Compressor (but unlike FCPX), the DCP program launches a separate rendering program behind the scenes but this one is 64bit and there is a separate renderer launched for each CPU so there ends up being 16 identical renderers running at once on my computer. The percentages for each DCP renderer go up to 100 percent, none of the over 100% readings we get with other programs, while filling the bars in the CPU graph. Oddly the special DCP player made by the same company, which is also 64bit, plays back the finished files but it goes to 1000% inside the program while running while using all the CPUs to around 80%.

            While FCPX gets into the video card for it’s horsepower, it is possible that Compressor and it’s rendering codecs are more CPU based. Why? Good question.

  6. Al B. says:

    Thanks for this Larry. First thing that struck me on the testing was: ProRes. Obviously, if I am shooting with an external recorder that allows me to automatically transcode, then I’ll be using ProRes. But you and others have said that one of the great advantages of Pr is *not having to transcode for many jobs*. So most of my work is not transcoded to Prores anymore. So a second chapter to this review might compare taking native footage, i.e. an AVCHD or MXF project at the same length in Pr as in FCPX. Obviously, overall time spent editing is important if you are charging by the hour, so if I’m not transcoding but taking a small amount more to render, then things change. My thought is that I am having FCPX take the time to transcode, (albeit in the background in most cases?) and then recode it to rendered output. Or am I missing something?

    Also, has Adobe brought out a MacPro optimized version of AME? I know that Apple’s developers have had access to the machine likely longer than Adobe has, and maybe there is some code that isn’t being shared as readily as it can be. Will be interesting to see if Adobe brings out an upgrade in the next few months specifically for the MacPro. That Apple hasn’t rewritten this core code to 64 bit is rather odd, (some might say lame), but obviously disk speed transfers seem to be more of a deciding factor here? As a similar but very different story, I have used Sony Vegas and Premiere on some projects over the last two years, but on Windows 7 64 bit, I routinely see 7 out of 8 cores pushed to the max with both products. Not that you would need to do the test, but someone might want to compare W7 into this chart and see how Pr itself compares on the MacPro. There may be a certain level of cross platform code that can be more easily optimized for the W7 environment?

    Again, thanks for the tests, but it doesn’t make me want to jump up and buy Compressor, since the only thing I see on this chart that is in it’s favor for my workflow is single pass MPEG-4 coming from ProRes which I don’t use. Unless I’m missing something in my analysis, which, having is totally possible.

    • Larry Jordan says:


      All good points. However, If I knew that I was going to be compressing a file, I’m not sure I would edit it in camera native. Compressing a compressed file is generally not a good thing.

      You are correct in that my tests were done using ProRes. My assumption, which could be faulty, was that the speed of compression was not determined by the format of the source file, but, rather, the specs of the compressed file.


  7. David Arbor says:

    Larry, it’s a little of both. This is how it was explained to me, but it was in the context of editing. I don’t suspect it’s much different for transcoding. If you have a highly compressed format then you need to decode it to read it, and then re-encode it to your destination codec. It’s harder to decode highly compressed files vs one that’s not so compressed. That’s why rendering (actual rendering, not transcoding) is faster when you’re rendering as ProRes because it’s easy to write. So when I edit HDV, even though Premiere can read it natively, I still set my previews as ProRes because it writes back to ProRes much faster. Plus, I can later use Smart Rendering to stitch a long meeting together quickly.

  8. Mal says:

    Hi Larry,

    You’re always on the cutting edge! Interestingly, I performed a speed comparison test also where I had loaded a timeline in both Premiere Pro and FCPX containing a continuous 25min native clip recorded on my Olympus EM5. There were no effects apart from boosting the audio and adding a fade in/out.

    I set up the export with identical codec and bit rate settings, but when I exported both (at different times of course) Compressor had it finished in 10.5mins vs AME which took well over 30mins. This really surprised me. I was doing this on a late 2013 15″ MBP.

    Also, I was doing some simple work in Motion last night (getting my hands dirty instead of using After Effects) and noticed that the direct export from Motion was way faster rather than sending the project to Compressor.

  9. Al B. says:

    Great info David. I didn’t even think to set my previews to Prores. I’ll have to try that. And thanks for that info Larry. I hadn’t even though about the issue of de-compressing the footage and then sending it back out in the same format. I guess that I had forgotten that Vimeo and Youtube could accept AVCHD for example, because it already *is* H.264 MPEG-4. Likely for a lot of my work it won’t look any better really. But I’ll have to try it out. As usual my *assumptions* were wrong.

  10. Jim B says:

    Great information Larry. For the past year or so, I’ve been using Sorenson Squeeze for almost all my encoding. It has always seemed faster to me than Compressor and AME but I have never really compared them. It’s just my “gut feel”, but I would like to see how they actually compare to each other. I really like the Squeeze interface and it’s loaded with options you can apply during the encoding process. Maybe you can put this on your ‘to do’ list for a future date.

Newer Comments →

Leave a Reply

Your email address will not be published. Required fields are marked *

Larry Recommends:

FCPX Complete

NEW & Updated!

Edit smarter with Larry’s latest training, all available in our store.

Access over 1,900 on-demand video editing courses. Become a member of our Video Training Library today!


Subscribe to Larry's FREE weekly newsletter and save 10%
on your first purchase.