Is Compressor a serious product?

[Gabriele Sartori]

it is irrelevant, it is probably bad coding or much higher quality. My reference point is HandBrake that actually has better quality than compressor and makes a better use of the CPU. I wish to use compressor because I like the Apple integrated solution. I stopped using Adobe products for Video over 10 years ago when it was impossible to finish a project without a crash. A CPU is a mathematical device, there is nothing to gain “going slower”, there isn’t an tiny artisan inside that does a better job taking more time. If you are good at writing your code, you go as fast as the CPU can go for an equivalent output quality.

Gabriele – California

[Craig Seeman]

Larry Jordan ran these tests in early 2015. I believe Compressor may have improved since then with the 4.3 update as well.

Note how Compressor compares to Handbrake on the 21″ iMac. But note how HandBrake compares to the MacPro.

Here’s the article.

Larry notes:
If you own a new Mac Pro, HandBrake is the leader by a wide margin, followed by Apple Compressor.
If you own an iMac or MacBook Pro, Apple Compressor is fastest, with HandBrake second.

[Jeremy Garchow]

Until you are willing to share your settings or compare settings, it is impossible to consider any action.

[Tom Sefton]

I’m really curious about this. If you are saying that there is not a chance that a program can make a faster encode without using the processor at 100% for its full duration of the project, how is it possible to quantify the efficiency of software by ignoring the amount of time it takes to do a job?

Perhaps the task being offloaded to GPU or hardware acceleration of h264 might help?

Co-owner at Pollen Studio
http://www.pollenstudio.co.uk

[Craig Seeman]

[Tom Sefton] “Perhaps the task being offloaded to GPU or hardware acceleration of h264 might help?”

Recent versions of Compressor use Intel QuickSync to speed encoding. Xeon processors don’t have the integrated GPU that supports this. That’s why an iMac can be faster than a MacPro when encoding H.264. The 2013 Mac Pros are particularly slow compared to a 2017 Quad i7 iMac or MacBook Pro.

I’ve heard Xeon processors may (may soon) support accelerated H.264 (and H.265?) encoding which is why I’ll be very curious how a base iMac Pro compares to the latest iMac (non Pro).

[Gabriele Sartori]

Thanks, Craig Seaman, I never saw this article before It is a bit old and at a first look it seems well done; he seems to have pretty different results from mine on HandBrake but I will definitely spend some time on this, thanks.

Gabriele – California

[Gabriele Sartori]

You see Jeremy is not that I don’t want to share settings. I have too many settings and all bring me the same results. Compressor doesn’t fully utilize 12 cores 24 threads in my case and I suspect in all cases. If you have experience with a 12 cores machine it is definitely a good thing, but if you have experience with a quad-core is not that I don’t like what you are telling me, I have the same results on a quad-core. I fill the pipelines on a quad-core. The problem is with 12 cores. Thanks for your help and good intentions though.

Gabriele – California

[Gabriele Sartori]

During the period around 2007/2008 there was a great deal of enthusiasm about GPU encoding. At that time I was CTO in a company doing “desktop virtualization” basically we were sending the screen of many virtual machines to remote thin clients. I was immediately attracted by GPU transcoding and I spent a good deal of time with a company called Elemental Technology doing that. I’ve to admit, their results were pretty impressive but at least in my case I found out that GPU transcoding is good if you only do that. “Context Switching” pay a big price in latency that translates into low performance. It may be the case here, Apple made a big deal about OpenCL but now they don’t use it in Compressor for what I know. The usage of OpenCL is done when FCPX transcode directly using compressor and OpenCL does the rendering part of the process not the actual compression. It seems a good thing in theory but not as effective in practical terms.

Gabriele – California

[Gabriele Sartori]

You are correct, Quicksync is great but for now it seems to be a consumer technology. Is not based on GPU is based on “hardware primitives” basically a disaggregate H264 hardware encoder where the SW can call the elementary functions. My experience with HW encoder is partially good. They usually can’t do double pass encoding so the quality is inferior. They also have hard time to do variable bit rate although in satellite communication there are sophisticated encoder doing variable bit rate for statistic multiplexing. My MacBook is very fast when I use encode but my question was about SW encoding that I love and can be fast. I would be happy if my 12 cores Mac Pro is as fast as handbrake when I use compressor. At least for now, my output looks better than what I get with Quicksynk.

Gabriele – California

[Jeremy Garchow]

[Gabriele Sartori] ” I have too many settings and all bring me the same results. “

But you aren’t using x264 in Compressor, so of course you’re going to get different results.