7298 Logo

My compressor presets

Compresor
icon

Let me say this at the beginning: Presets are not the best way to compress video. Although a present can produce beautiful results, the real art of doing any kind of compression is to remember that every source is unique. The guidance is: don’t just slap a preset on a video, churn it through an encoder and call it done.1 Find the hardest sections of video to compress, test encode with variations in bitrate and settings, and compare the results to the original. Then, encode with the best settings you’ve discovered.

That being said, we all live in the real world, with deadlines, and expections, and sometimes you just need to get the job done. So, I offer up my Compressor Presets, for better or for worse. I developed these based on videos with a fairly moderate amount of movement, dissolve transitions, moderate dynamic range, but visually complex detail. Use these settings as a starting point, and develop your own settings.

Installing

Download the presets for yourself.

The presets come in 3 sets,

Unzip the file, open compressor and drag into the settings pane under the Current view.

The thinking

Based on TN2224, I built these settings to produce MPEG-4 video files for four variants, with the aim at compatibility with mobile devices on different networks. 2 Compressor does come with presets for HTTP Live Streaming, but these are for 7 different variants. I decided to simplify for 4 variants, picking the most common at the time:

Apple’s tech article is a bit out of date, and doesn’t even cover Android or 1920 x 1080 (1080p) videos. I know, weird, but it is a starting point.

I’ve optimized each preset for highest quality at the target bitrate, squeezing the last of the toothpaste out of the tube, so to speak, using the best practices of Master of Video Encoding, Fabio Sonnati. 3

Fabio uses FFMPEG for encoding and so should anyone concerned with absolute best quality, but there’s a few reasons why you might choose Compressor instead:

  1. FFMPEG either runs on a command line, or with a set of advanced options when using a GUI, so you need to know what you’re doing to run it.
  2. You’re working Quicktime ProRes or DNxHD and FFMPEG can’t read it without adding additional fiddling.
  3. You’re a visual person and like to have an interface where you can see what you’re doing and see the progress of what you’re doing, i.e., staring at the progress bar.
  4. You really want something you can export from a FCPX timeline, and Compressor does a good enough job.

So let’s see what we can accomplish with Compressor. Beware, the reasoning involves math. You’ve been warned!

Compressor doesn’t give you a whole lot of options on B-frames, reference frames, deblocking, and so on. It’s an Apple product. So you get simplicity and trust that Apple is doing all those good things for you behind the scenes, and that they know better than you. Hmm… I miss the Apple II sometimes.

For all these presets, I've turned Multi-pass off. Although Multi-pass is supposed to be more efficient, I found it produced more artifacted video, and it took longer to process. So it’s off.

640 x 360

For 640x360 we targeting lower-end devices are restricted to the Baseline 3.0 profile, and CAVLC. Wah. Key frames is set to 90, because the frame rate is the same as the sources, 29.97 frames per second or 23.976 fps. Yay!

Video data rate is set using a bits per pixel ratio of 0.150, which works out to a low-low bitrate of 868kbps for 23.976 fps and 1035kbps for 29.97.

Multipass stays off because we’re hot rodding and looking for compression speed. Frame reordering stays on.

Audio is set to 96Kbps at 44.1 KHz.

960 x 540

Frame size is set to 1/4 of HD, 960x540. Bit rate is set to 1942kbps. Why not at 2330kbps? Since the math says:

960 x 540 = 518,400 pixels per frame,

times a frame rate of 29.97 fps = 15,536,448,

times a bits per pixel value of 0.150 = 2330467.2,

and converted to kbps by dividing by 1000 = 2330 kbps?

The reason is according to TN224, we can use the Main 3.1 profile and CABAC (Context-adaptive binary arithmetic coding) which is more efficient and requires less kilobits per second for the same quality. Main 3.1 and CABAC is more processor intensive to decode, so while it requires more computing resource, you can be happy that all that money spent on your fancy computer is being put to good use. The result is smaller file size, less storage and less bandwidth consumed than using Basic 3.0 CAVLC.

So we can use a bits per pixel value of 0.125 and we can get 1942kbps for 29.97 and 1553kbps for 23.976.

Keyframes, frame reordering, and frame rate are all kept the same, and audio stays at 96Kbps at 44.1.

1280 x 720

720p gets a 2762kbps for 29.97 and 2209kbps for 23.976. 518,400 pixels vs. 921,600 pixels, and only 820 more kilobits per second? How are we getting away with that?

The answer is, H.264 gets more efficient with larger frame sizes and we start using the High and CABAC setting. I know, but I told you there was an art to this science. Our bits per pixel ratio is 0.100 for this encode, compared with 0.125 for 960x540. Try it and take a look at the result. It works.

Keyframes, frame reordering, frame rate, multipass: it’s all the same, baby. Even audio is at 98Kbps/44.1.

1920 x 1080

With 1080p, we run out of H.264 profile settings to use, but with the higher frame sizes, we can still reduce the bits per pixel ratio to 0.080, because codecs are just more efficient at higher resolutions. So we end up with 4971kbps for 29.97 and 3977kbps for 23.976.

Keyframes, frame reordering, frame rate, multipass: all stays the same, as well as audio at 98Kbps/44.1.

Fabio Fast, 1024 x 576

And for pure encoding speed, for those high-volume, fast-turnover, keep-the-quality-at-a-decent-level times, use the Fabio Fast settings. These are optimized for fast encoding, and the secret sauce here is to use a frame size, not full HD (1080p), not smaller HD (720p), or even 1/4 HD (540p) but 576p.

Why 576p? Because 576p, is 1024 x 576 and if you do the math, they're both easy multiples of 16. And, it's also a multiple of 8, and a multiple of 4. So, for the special blocks, the transforms, the colour zones, and all the other math done during encoding, it's easy (and quick) calculations for the encoder to do. Yes, it's not a standard size. Yes, it's not even and HD. But who cares when you're not encoding for a standard delivery, when you need a quick preview file to send to a client, or a quick publish to the web? 576p with sufficient bitrate, will look good.

Notes

  1. It’s the enconomy of scale working here. While you might get away from inefficient encoding for a one-off video, when you do another one, and other one, the costs start to build up. Netflix, with their monstrous catalogue, sees how impactful ineffecient encoding really is, see “Netflix Re-Encoding Entire Catalog to Reduce File Sizes By 20%”, http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=108142

  2. For playback abilities of mobile devices see, “How to Produce High-Quality H.264 Video Files”, http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/How-to-Produce-High-Quality-H.264-Video-Files-94216.aspx. For the seminal reference on producing H.264 variants, see Apple’s Technical Note TN2224, “Best Practices for Creating and Deploying HTTP Live Streaming Media for the iPhone and iPad”, https://developer.apple.com/library/ios/technotes/tn2224/_index.html

  3. If you really want to go deep, Fabio’s the guy to follow. https://sonnati.wordpress.com/best-of-blog/. Compressor doesn’t have the options to really tweak the encode to Fabio’s extreme levels. But we can implement a lot of his best practices. Also take a look at his 2008 Adobe Max presentation, "Encoding Video for the Highest Quality and Performance", http://www.progettosinergia.com/flashvideo/Fabio_Sonnati_Encoding Video for the Highest Quality and Performance MaxEurope2008.pdf 

Published 16 Feb. 2017. Updated December 17, 2021.