Holy Smokes – we have a horse race!
This week, in my continuing series looking at video compression software, I want to compare the compression speeds of six different software when encoding files for YouTube using a new Mac Pro and a 21″ iMac.
The software I used were the current versions as of today:
We used the trial versions of both Telestream Episode and Sorenson Squeeze for this test.
Here are the other articles in this series:
This test used the same YouTube compression setting for all systems and all tests, or as close as each software would allow. While this does not yield the smallest file sizes, a 10 mbps bit rate will yield excellent image quality in all cases. So, no image quality determinations were made.
What’s the fastest compression software? Well, that depends…
HandBrake seems to take fullest advantage of the Mac Pro architecture. I suspect that it would be even faster running on a top-of-the-line Mac Pro.
The latest version of Compressor is the fastest version yet, though running it in multiple instance mode caused some 2-pass compression jobs to fail.
Adobe Media Encoder was a solid contender, ranked third for speed in almost all tests.
MPEG Streamclip was problematic. In 1-pass mode it was reasonably fast, but 2-pass mode was unstable. In three different cases on both computers, it took more than 2 hours to compress a 4 minute movie. In both cases, I canceled the compression. I strongly recommend against using 2-pass mode in MPEG Streamclip.
I was surprised that both Episode and Squeeze were slower than average on both systems.
If you want pure speed, pick HandBrake. However, if you need to add watermarks or other effects, Apple Compressor is a better choice with Adobe Media Encoder a solid runner up.
Click here to download a PDF of all my findings so you can check my math.
BIG NOTE: Within the next few weeks Adobe is releasing a new version of Adobe Media Encoder. I’ll keep these results and media on file and test to see how the speeds of the new version of AME compare.
While this test did not focus on comparing interfaces, a few notes:
Late 2013 Mac Pro
3.0 GHz, 8-core Xeon processor
32 GB RAM
AMD D700 GPU
Late 2013 21″ iMac
3.1 GHz Intel Core i7
16 GB RAM
NVIDA GeForce GT750M GPU with 1024 VRAM
Clips. I tested clips using three different codecs: XDCAM EX, ProRes 422 HQ and ProRes 4444. Two clips had native 720p images. The other two clips were scaled to 1280 x 720 during compression. Clip durations ranged from 4 minutes to 48 minutes. All source clips were stored on the internal drive, which yields the fastest results on SSD systems.
Compression settings. AME defaults to 1-pass VBR with a 16 mbps bit rate. Compressor defaults to a 2-pass VBR with a 9765 kbps bit rate. I tested both 1-pass and 2-pass VBR, with a standardized bit rate of 10,000 kbps for both applications. For both software I used the default YouTube 720p compression setting and only modified the bit rates to match at 10 mbps. Max and Min settings in AME were identical at 10. Keyframes,when they could be set, were set to 90.
Compressor was restarted when I changed the number of instances.
HandBrake and MPEG Streamclip did not have YouTube presets. I configured a compression setting to match our tests. Episode and Squeeze had YouTube settings, but needed tweaks to match the test setting. All YouTube default settings in all software that had them, looked like they would create excellent images without any additional tweaks.
Compression times were reported by the application. No other apps were running during compression. Only one setting was applied to each clip. Clips compressed individually, no two clips compressed at the same time. Episode only reported compression time by the minute.
(Click image to see a larger version of this table.)
This is a summary of what I learned. Green bars indicate the fastest results in each category. Red bars indicate the slowest.
Because Adobe Media Encoder has, for the last year or so, been the fastest software out there, for this first test I set AME 1-pass equal to 100% and compared all the other software to it. Numbers higher than 100% are slower than AME, while numbers lower than 100% are faster.
You can NOT compare Mac Pro speeds to iMac speeds in this section, as they use different numbers. The next section allows you to compare speeds between systems.
ACTUAL TIMES ANALYSIS
I calculated this section by totaling compression times for all four movies compressed on each system (Total Time). For completeness, I also averaged compression times, but the results were the same; as you would expect.
The horsepower of the MacPro enabled applications that did not take advantage of hardware compression to do well: HandBrake, MPEG Streamclip, Episode and Squeeze.
Compressor, which accesses both hardware and GPU compression, handily beat the Mac Pro for all but the 2-pass multiple instance test. AME also uses the GPU to achieve its speeds and posted solid numbers on both systems.
CODEC COMPRESSION TIME PER SETTING
In this section, I show how long it takes to compress a minute of each codec using each of the six tested software. This averages both the MacPro and iMac numbers.
What surprised me was the variability between codecs and software. Compressor, for instance, compressed one minute of ProRes 4444 in under ten seconds, while XDCAM EX took Compressor more than 4 minutes.
CODEC BY SYSTEM
This compares compression speed by software for each system standardizing on ProRes 422 HQ. This illustrates the differences in compression speed between software.
(Click here to download a 4-page PDF detailing all my findings, so you can check my math.)
Running this test took almost four days and I’m grateful to Brianna Murphy for her help in compiling these results.
Here are my thoughts:
As always, I’m interested in your opinions.
16 Responses to Speed Test: Compare Video Compression SoftwareNewer Comments →
Great information as always, thanks.
In your BIG NOTE, you meant to say Media Encoder CC, not Motion.
Great article Larry. It would be interesting in seeing if you achieve the same results using watch folders and droplets. Also is Apple coming out with a new compressor or is Adobe coming out with a new AME? I wasn’t sure with your big note.
BIG NOTE: Within the next few weeks Adobe is releasing a new version of Compressor.
Adobe is coming out with a new version of Adobe Media Encoder. I’ve already corrected the story.
Aside from the delay in getting started with a Watch folder, the results would be identical.
Your speed test reveals the most expensive software on the market is the slowest. I own Telestream Episode, but put it on the shelf when Adobe AME and Apple Compressor continuously got the work done in quick order. Episode is a huge disappointment in the speed department. Appreciate your objective testing on all the brands out there.
Great info, as always.
For a point of clarification, were you testing using “Episode” or “Episode Pro?” My understanding with that line from Telestream is the more you spend the more speed you get. I don’t have numbers to back up that statement, but that is the impression I’ve been given by sales. Episode Pro sure “feels” pretty fast, but again, no data to compare to your chart.
“Episode Engine” with distributed rendering is much more powerful and would likely help with overall speed by spreading the work out in pieces, but that’s pretty expensive – and expansive – and not indicative of what many users would need.
I’m really happy with what Apple has been working toward with Compressor, and 4.2 is a great update. Same with AME CC. This competition for performance is really a win for the user base.
We downloaded the Episode free trial, so probably not the Pro version. It is my understanding, which could be wrong, that the difference with the Pro version is not speed but additional format support.
I agree, Episode Engine provides a distributed compression environment, but at a fairly steep price. This is valuable if you are creating dozens of movies a day.
You should try the x264 encoder with MPEG Steramclip. Fast and produces good-looking output.
By the way, Handbrake is encoding H.264 with the x264 encoder. In my testing I did get the best looking results with x264 (either Handbrake, QuickTime Component or command line). I also recommend using the CRF setting (instead of VBR) if there is no limit on size or data rate. CRF encodings are very fast and the data rate adapts automatically to compensate for complex images and to guarantee the desired quality.
Yeah. Episode Engine (at 5k+ per seat) would have been the fastest.
Though… roll back to OSX 10.8 using Compressor 4.0.7 and it will easily beat everything by a long run. Even with a single system.
I can get 100% processor utilization with that version. Across as many systems as I could. I’d max out the server read speeds. And you need at least 2GB of RAM per core.
I’m in LA if anyone wants a demo. 😉
Using Squeeze 10 Pro:
A little behind in reading this fine article. Was wondering if in 2017 there are any significant Compression Software changes that might change these numbers?
I haven’t explicitly tested Squeeze this year. However, in general, while everything speeds up with new hardware, the timing outlines suggested in this piece are probably still roughly correct.
love your content, truly excellent, so useful for a self taught person like me. i was hoping you could help me in terms of the best settings for youtube and vimeo encoding via handbrake? i’m not sure if i’m getting the best exports, particularly for youtube and matching their recommended settings. Also, for exports with noise in the video, what settings/encoder would you recommend to help reduce noise? thanks Larry, appreciate it.
I found this article incredibly helpful., but wondering if it would be practical to do a 2020 version of these speed tests as both the hardware in the mac pro / macbook pro has improved, and the software have all developed further as well…
Yes and no. Based on what I’ve seen recently from both Apple and Adobe, software speeds have not improved a whole lot. The big factor that affects performance is CPU speed, as most codecs are CPU-based, rather than GPU-based. Also, I don’t own a Mac Pro, so I can’t test with that.