Speed Test – Compressor 4.2 and YouTube

Posted on by Larry

logo-CompressorI spend a lot of time each week compressing video and I’ve written a lot comparing compression speeds for both Apple Compressor and Adobe Media Encoder. With the release of Compressor 4.2 a couple of weeks ago, Apple touted the speed improvements in the new version. This week, I had the time to test some of these claims.

The big benefits of Compressor, in terms of speed, is that the newest version takes advantage of both GPU and hardware acceleration for H.264 files; both MPEG-4 and QuickTime. The YouTube default settings create QuickTime files using the H.264 codec.

This is the first of three articles looking at Compressor 4.2 speeds – comparing speeds using the YouTube default settings on an iMac and MacBook Pro.

NOTE: I’ve written other articles looking at Apple Compressor 4.2 in more detail:

EXECUTIVE SUMMARY

HOLY SMOKES! The new version is FAST!

Speeds varied from 36 to 92% faster, depending upon codec. The new version of Compressor also takes advantage of the much faster speeds of SSD and Fusion drives to reduce compression times even further.

This speed differential can result in saving several HOURS of compression time when compressing longer-form media.

TEST GEAR

Speed001

Compressor 4.1.2 was tested on a Late 2013 iMac, running OS X 10.10.2 (screen shot above). Note that the processor speed is 3.5 GHz.

Speed002

I ran Compressor 4.2 on two different computers: a Late 2013 iMac, running OS X 10.10.3 (screen shot above). Note that the CPU and GPU are both slightly slower than the 27″ iMac; however both iMac use Fusion drives.

Speed003

I also tested on a 2013 MacBook Pro, running OS X 10.10.3. It uses an internal SSD drive.

NOTE: I’m hoping to borrow a Mac Pro for a few days to test on that system, as well.

SPEEDS MATTER

The two iMacs are similar in speed; though not identical because 21″ iMacs don’t offer the same components as 27″ iMacs. However, their speeds are generally comparable.

The MacBook Pro is slower than the iMacs, but what I discovered is that where you store your media can make a big difference in speed, allowing the MacBook Pro to compete with an iMac.

TEST MOVIES

Not to put too fine a point on it, but Compressor 4.1.2 is dog-slow when compressing H.264 movies. One-hour movies compressed for YouTube can take multiple hours. (This is the main reason I use Adobe Media Encoder for all my YouTube movies; it is light-years faster.)

For this article, I created a compression test suite of three movies – spanning three different frame sizes and three different codecs – with durations that ranged from five to 38 minutes.

COMPRESSION SETTINGS

Speed010

All files were compressed using the default Video Sharing Services (YouTube/Vimeo) settings of HD 720. This creates a 720p file.

RESULTS

FW_image021

Click the image to see a more detailed PDF of my speed test results.

I expected the new version to be faster. What I didn’t expect was that speeds would also vary depending upon where you stored your media.

Here’s a detailed PDF containing my test results.

INTERESTING TRIVIA

Speed030

I was also surprised by how much more efficiently Compressor was processing data. In this screen shot, the top stat shows that Compressor 4.1.2, with both application and data stored on a Fusion drive, was only accessing about 70 MB of data per second.

Compressor 4.2, with data and application also stored on a Fusion drive, is accessing data 3.5 times faster (264 MB/second), and using much more of the CPUs; 75% vs. 30% in the earlier version.

SUMMARY

Now that I’ve seen the kind of results we can get with default settings, I’m really looking forward to seeing how this translates into productivity when compressing files for local websites; as well as a speed test between Compressor and Media Encoder.

For now, though, I’m very impressed with how Apple has transformed Compressor into a speed machine.


Bookmark the permalink.

6 Responses to Speed Test – Compressor 4.2 and YouTube

  1. Jim Blankenship says:

    Great info Larry. Looking forward to the next two reports. I’m hoping you have enough time to address Compressor Vs. Media Encoder on multi-core machines. I have a Mac Pro (Late 2013) 2.7 GHz 12-Core Intel Xeon E5 and 32 GB of RAM. I rarely used Compressor in the past but after reading this article, I’m anxious to try it out. I also have the latest versions of Media Encoder and Sorenson Squeeze, which has been my go-to app for compression, mostly because of the presets I already have established. I’ll probably do some of my own testing now after reading this article, but I’m just lazy enough to not want to reinvent a wheel that someone else has already invented. Also, I am wondering if you know which of these three best utilizes multi-core machines?

    • Larry says:

      Jim:

      This is part of what I am trying to learn as I test this new version. I will also try to take a look at Sorenson Media.

      Larry

  2. Eric says:

    Hi Larry, thanks for posting the results. Is Compressor’s implementation of the H.264 codec still considered poor? I remember reading on the COW, I think, that if you do a CBR file the quality is similar to x.264.

    Thanks Eric

    • Larry says:

      Eric:

      Good question. Let me do some homework and see what I can find out. So far, I haven’t had time to look closely at it.

      Larry

  3. Jonathan says:

    Hi! Finally someone is reviewing and writing about this stuff. I’ve been meaning forever to start a blog of my own.

    I’ll try to get to the point and not ramble.

    I’ve used Compressor for several years now. I find I get the best looking and quickest transcodes through it. Especially since I discovered the hack that lets you apply filters (watermarks esp) over DNxHD material.

    But the main feature is the Qmaster distributed encoding. (the way it takes apart MOVs and stitches them back together) Yes it’s buggy as hell but once you learn it’s quarks and set up a few systems, it’s easy and generally runs great. I could compress a 2 hour movie into a baseline 2pass H264 from DNxHD36 source, while applying a mask, timecode, and a watermark in 10 minutes using 2-3 MacPro 12 cores.

    When Compressor 4.1 came out… part of me died. They took out most of the qmaster functionality and simplified the program. I kept all of my systems on 10.8 just so I could use compressor. It seems like they just updated it to utilize the new MacPros GPUs… or at least that was the idea.

    I haven’t tried using Compressor 4.2 yet across multiple systems. Have you? Nobody does this. I’ve taught a lot of people. And usually it takes a techy type to get it.

    The only other thing that comes close to the speed of my setups is Telestream’s episode engine. And that’s $5k+ per license and you need a license on every system. It basically does the exact same thing Compressor does they just refined it. Apple sort of does pro video very half assed. They always have and it shows.

    Anyway. Would love to talk more about everything. I’d like to know if they put back some of the distributed encoding on 4.2. They say it works in Apple’s documentation but does it actually… and to what degree.

    The ideal solution would be to have the distributed encoding across all available networked CPU cores, along with utilizing GPUs processing. And being able to control this on a per system basis. It’s like where Resolve has gotten to. Now it works with all GPUs and CPUs at the same time.

    I haven’t tested the latest versions of sorenson squeeze or Media encoder. I gave up on them a few years ago. Squeeze never got multi core CPUs, and they don’t have any documentation on their site about what it does. Nor does Adobe. Drives me nuts. Adobe’s encoder is said to better utilize GPUs, though I’ve never had a system that had a compatible GPU. ME used to not be able to access most of the CPUs cores.

    Anyway.

    Thanks

    • Larry says:

      Jonathan:

      I agree – getting networked compression to work using Compressor requires faith, luck and a lot of trial and error. I haven’t tested the network capability because in order to use it, you need to store assets on a network server which all compression nodes need to access. It is faster for us to compress a file stored locally than to transfer it to the server then compress using the network.

      Larry

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!

JOIN NOW

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