Is Compressor a serious product?

[Gabriele Sartori]

Thank You Andreas, I see, no easy solution. If you have any codec you can suggest it would be great. Thanks

Gabriele

Gabriele – California

[Joe Marler]

[Gabriele Sartori] “Quicksync is great but for now it seems to be a consumer technology….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….”

As you can see from these encoding tests on industry-standard material, there is virtually no visible quality difference between Quick Sync and multi-pass software encoding: https://joema.smugmug.com/Video-Tests/Quick-Sync-vs-Software-Encoding-Test/n-CksJjj/

The fastest way to encode H264 on a Mac is using FCPX on a 2017 i7 iMac 27, which is twice as fast as a 12-core D700 Mac Pro — I have tested that myself. Supposedly Compressor has been upgraded in recent versions to use Quick Sync and is allegedly as fast as FCPX but in my tests it’s never been as fast. However I haven’t tested it in some time.

If you want to see how 100% CPU utilization doesn’t translate into best performance, compare editing 4k H264 in Premiere CC vs FCPX. On Premiere all CPU cores are pegged at 100% just scrubbing the timeline, and FCPX is much lower. However Premiere is laggy and slow on the same Mac hardware (despite the higher CPU utilization) so the situation is more complex than just CPU.

That said, when encoding or decoding long GOP formats like H264, each GOP should generally be independent of all other GOPs, so should be a viable candidate for a dedicated CPU core. That said there are long GOP variants which have inter-GOP dependencies, and it doesn’t take much to kill multi-core scalability due to Amdahl’s Law: https://en.wikipedia.org/wiki/Amdahl%27s_law

Parallelism within a GOP is almost impossible due to the sequential nature of the algorithm. This was well described by Jason Garrett-Glaser, lead developer of X264, in this video lecture:
https://www.youtube.com/watch?v=uOOOTqqI18A

[Gabriele Sartori]

I previously discussed somewhere in this thread that GPU gave great expectations but never delivered up to those expectations (when used for encoding H264). I did that myself for professional reasons when I used to be the CTO of a company doing remote desktop computing. What is described in the video is mostly this aspect and the super-parallelism of GPUs. about CPUs has been proved over and over that using a decent number of cores for H264 encoding is possible. I’m not thinking about using cores for the sake of it , I hope I was clear. I was talking about using more cores for a faster speed like actually Apple does with some of their codecs that are also GOP based. The reality here is that Apple H264 is not a great codec in terms of CPUs parallelism. X264 (used in HandBrake) is much better and can compress equivalent quality in a fraction of the time due to the higher CPU (not GPU) parallelism. All my tests are related to the Apple products, Intentionally I don’t do Premiere because otherwise I would introduce other unknown variables. For what is concerning HW encoding in imac, it’s possible that a visual inspection of the output is not significantly different but under the mathematical point of view it’s different. Single pass is not 2 pass. In any case I would be happy to do this in HW but since I’ve a 12 core Mac Pro I’d like to use the resources of my expensive HW that Apple sold me as the most poferful HW they do. I will just continue to use HandBrake, it works, it’s good, it’s fast and uses X264 inside, a very good codec. Thank you for your help.

Gabriele – California

[Jeremy Garchow]

I did some informal tests. I tried to match the settings as best as I could form handbrake and compressor.

Handbrake had all the processors pegged (~1500%) (these were done on an 8 core MacPro D700s) but took longer to compress.

Compressor used less CPU (~1200%), but the overall encoding job finished more quickly.

Not sure what to make of it.

[Gabriele Sartori]

must make sure that all the parameters are identical, not easy task. With identical visual quality Handbrake is faster to me and it is linearly faster with the number of cores used. Your CPU utilization with Compressor is pretty good though, it seems better than mine even if I factor in that you are on 8 cores and I’m on 12.

Gabriele – California

[Jeremy Garchow]

[Gabriele Sartori] “must make sure that all the parameters are identical, not easy task. “

This has been my point all along.

I can make Compressor “go faster” so without emperical evidence or settings, one could say Handbrake isn’t a serious tool.

[Gabriele Sartori]

Wait a moment, I never said that I don’t work with identical parameters. I do work with the closest possible parameters, I do check the visual output and Handbrake is faster, pretty much linearly scaling with the number of cores used. I don’t find this to be strange both X264 and H264 are very mature, very optimized coded. They are pretty much equivalent on one core under all the measurable aspects. The difference is that X264 can use more cores and this means that is a very well crafted product.

Gabriele – California