Gabriele Sartori
Forum Replies Created
-
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
-
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
-
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
-
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
-
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
-
Trust me, I developed H264 compression routines for 10 years. That is not true. Giving a good code if you fill twice the pipelines you go twice as fast. It is a basic law of physics. (and math as well). The “engineers” were giving the marketing party line as they are directed too.
Gabriele – California
-
I can guarantee you that we are in front of a marketing crafted BS answer. If you use 30% of your CPU and you are able to go to 60% you will encode in half the time preserving all the other technical choices and the identical quality. These answers are really upsetting because they offend the customer intelligence
Gabriele – California
-
Yeah, parallel programming is complicated. Video compression lends itself to it because you can assign different task to different 8×8 (or other square sizes) blocks but there is a limit to that since you have to tie everything together. I do have a Macbook 13″, core i5 and I fill both CPU four thread, I used to have an i7 before and I almost filled the 4 cores, you are also scaling down and doing other things so maybe there are more parallel tasks. With the 12 cores 24 threads I get between 25 to 30% of overall CPU utilization that it’s about equivalent to 4 cores indeed.
Problem is that I bought years ago this monster assuming that I would run faster than a quad core MacBook. It never did with Compressor, it does it with FCPX and Handbrake . Pretty depressing. Apple next month with be out with a 18 cores machine. Will they do something about this? I’m not too upset because handbrake is freaking fast but I really wish the integrated environment. Normally what I do I export with a lightweight codec so the export is very fast and then I pass it with Handbrake. Thanks for the help
Gabriele – California
-
Yes but that it’s relatively easy. You don’t have 12 cores on two CPU and separate memory channels.
Gabriele – California
-
I tested many settings. Simple or complicated I just can’t fill the CPU pipelines. Same Mac Pro with “HandBrake” I get 80% sometimes even 90% of CPU utilization and the quality is great. This CPU utilization with Handbrake let me compress really, really fast. FYI I did SW compression for 20 years and design compression solution in HW and SW myself, I know the parameters. I’m wondering what is your CPU occupation doing HD H264 compression with Compressor. I was never able to use it due to the slowness. It could be the Apple H264 Codec that is not multithreaded I don’t know, but in this case why Apple doesn’t do a new codec? They had major advances in speed with Final Cut, it is time that we see compressor using all the cores available, we are in 2017. It is still possible that I do something wrong although it doesn’t seem to me. I’m wondering about the results you guys get from it.
Gabriele – California