Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Considering cancelling my Mac Pro order. No speed benefits in FCPX / Compressor
- Thread starter CouponPages
- Start date
- Sort by reaction score
They updated the software in the Apple Store to 10.1 and although it's now running MUCH better than with 10.0.9, my 2.5 Ghz i7 MacBook Pro 17" Late 2011 is currently twice as fast at exporting the H.264 1080p video compared to the Quad Core D300 Mac Pro 2013 base model they display in Apple Stores.
This isn't as far-fetched as it sounds. In the benchmark you posted, the iMac is #3, which is not too different from my MacBook. We know this is because i7s have QuickSync hardware compression, specifically designed to compress H.264 video. Xeons don't have it, so they can't compress video as quickly without lots of cores.
The only Mac Pro that beat the iMac was the 2010, 12 core. 12 cores... vs 4.
Granted, most will agree for broadcast use, QuickSync is sub-par, but many of us can't see the difference.
Just boy one of those h264 encoding usb sticks already
I think CPUs finally got so fast that Elegato became a software only solution, but it does make you wonder... it a little company can make a $100 dongle that can compress video, why can't most GPUs do it? If they did, we wouldn't need 12 core systems.
So let me get this straight. You're comparing one of the lowest spec Mac Pro against the highest spec iMac/MacBook Pro and you're disappointed that it has poor performance.
Yes.
Just clarifying my response to your post:
I assumed you doubted that it was possible that a MacBook Pro could even be in the running.
The BruceX benchmark you posted listed a similarly equipped iMac as the third best, only bested by two other computers, one of which was a 12 core 2010 Mac Pro.
The only reason I have compared my results to the base Mac Pro is that it's the only one I've had my hands on. I would love to see benchmarks that show the Mac Pro's muscle crunching 1080p video. I'm still on the fence. My order still stands (6 core, D700, 32GB, 1TB)... I would love to see one benchmark that makes me feel like I'm going to see an improvement.
To be clear. My MacBook Pro cost me $2999, the same as the new entry level Mac Pro.
Technically, it's a bit more than the top of the (2011) line, because I boosted the RAM to 16GB and swapped the internal drive for a $400 Corsair GTX Neutron.
It also should be clear that the 2013 iMac in the BruceX benchmark you posted costs the same as the base Mac Pro, except it comes with a $1000 Thunderbolt display.
I made it to the Apple Store twice today to try some of the alternate exporting scenarios suggested in this thread to confirm that export speeds would be faster if they were done directly from FCPX instead of loading them directly into Compressor.
Unfortunately, the results were nearly identical when I selected a Compressor Preset from within FCPX, 6:25 seconds, exactly.
The reason for the re-test was because it was suggested that Final Cut Pro X is optimized to use the dual GPUs only if you exported directly from FCPX, not from compressor.
Since the time was nearly identical, I decided to go back one last time to modify my final step to a direct master export with the CODEC changed from the native ProRes 422 to H.264, under the hope that a direct export to my true target could bypass Compressor entirely.
Unfortunately again, the time was even slower, and it generated a file twice the size 1.2 GB instead of 600MB using the Compressor output. For the record, HandBrake can crunch it down to 114-150 MB depending on the RF setting... Since HandBrake is CPU based... it's MUCH slower, but produced a much smaller file.
So, I'm back to square one. I truly want to see signs that the Mac Pro I ordered (6 core, 32GB, D700, 1TB) can smoke the doors off my MacBook 2011, specifically to take away the long wait exporting videos.
Can somebody show me a benchmark that I can re-create on my own MacBook Pro that can compare to. I've documented the exact steps in my test, and I've uploaded the XML to generate it, but I don't have any takers. I have the BruceX XML on my MacBook, but I haven't seen anyone's BruceX results using a 2013 Mac Pro, preferably one with 6 cores and D700s would be great.
Can somebody with a 6 core / D700 run either my test or the BruceX and post the results... or show me a benchmark that includes it?
For the record, these are the BruceX results from my MacBook Pro 2011:
Exporting a ProRes 422 Master: 57 seconds
Compressing the ProRes master from above in Compressor to 4K, 22 seconds
Compressing the ProRes master from above in Compressor to Apple Devices HD (Best Quality) 6 seconds.
For some reason I am unable to export that as an H.264 5K master, nor can I configure Compressor to spit it out as 5K. There are no 5k presets, and when I tried to create a custom 5k, or one that is automatic (same as the source), it fails to generate, so I'm posting my ProRes 422, 4K and Apple Devices (1080p).
I'm looking forward to seeing some non-entry level Mac Pro benchmarks.
Thanks!
=== EDIT ===
Please note, the 6 second and 22 second benchmarks are the time to take the ProRes master and generate the compressed file from the 422 master, which took 57 seconds, so the actual times would be 1:03 and 1:19. I would've posted a direct to H.264 Master, but it fails every time I try it.
Unfortunately, the results were nearly identical when I selected a Compressor Preset from within FCPX, 6:25 seconds, exactly.
The reason for the re-test was because it was suggested that Final Cut Pro X is optimized to use the dual GPUs only if you exported directly from FCPX, not from compressor.
Since the time was nearly identical, I decided to go back one last time to modify my final step to a direct master export with the CODEC changed from the native ProRes 422 to H.264, under the hope that a direct export to my true target could bypass Compressor entirely.
Unfortunately again, the time was even slower, and it generated a file twice the size 1.2 GB instead of 600MB using the Compressor output. For the record, HandBrake can crunch it down to 114-150 MB depending on the RF setting... Since HandBrake is CPU based... it's MUCH slower, but produced a much smaller file.
So, I'm back to square one. I truly want to see signs that the Mac Pro I ordered (6 core, 32GB, D700, 1TB) can smoke the doors off my MacBook 2011, specifically to take away the long wait exporting videos.
Can somebody show me a benchmark that I can re-create on my own MacBook Pro that can compare to. I've documented the exact steps in my test, and I've uploaded the XML to generate it, but I don't have any takers. I have the BruceX XML on my MacBook, but I haven't seen anyone's BruceX results using a 2013 Mac Pro, preferably one with 6 cores and D700s would be great.
Can somebody with a 6 core / D700 run either my test or the BruceX and post the results... or show me a benchmark that includes it?
For the record, these are the BruceX results from my MacBook Pro 2011:
Exporting a ProRes 422 Master: 57 seconds
Compressing the ProRes master from above in Compressor to 4K, 22 seconds
Compressing the ProRes master from above in Compressor to Apple Devices HD (Best Quality) 6 seconds.
For some reason I am unable to export that as an H.264 5K master, nor can I configure Compressor to spit it out as 5K. There are no 5k presets, and when I tried to create a custom 5k, or one that is automatic (same as the source), it fails to generate, so I'm posting my ProRes 422, 4K and Apple Devices (1080p).
I'm looking forward to seeing some non-entry level Mac Pro benchmarks.
Thanks!
=== EDIT ===
Please note, the 6 second and 22 second benchmarks are the time to take the ProRes master and generate the compressed file from the 422 master, which took 57 seconds, so the actual times would be 1:03 and 1:19. I would've posted a direct to H.264 Master, but it fails every time I try it.
Strange, I also did the BruceX benchmark and was able to use GPU rendering in FCP 10.1 with speeds 4 times as fast as Compressor 4.1 Heres the video I made showing the difference:
http://www.youtube.com/watch?v=BS-GzLw7gSI&feature=c4-overview&list=UU8Z6SeoKer2Lmxmu2uk706A
I'm also not using a new Mac Pro but a 2009 model. Both FCP X and Compressor 4 is using a compressor pre-set.
Last edited:
BTW Handbrake can use Quick Sync, provided you pick the right options. See page 15 the Intel paper "Utilizing Intel Quick Sync Video for High Density Video Transcoding": https://intel.activeevents.com/sf13...71C0103EE10222677FEDEDE2/SF13_COMS004_100.pdf
This is a fascinating area.
The Xeon E5 v2 in the nMP is a prior architectural version "Ivy Bridge". It has design features that favor server and workstation use -- large caches, higher core counts, etc. It doesn't have on-chip GPU because that wastes transistors/power and workstations have dedicated GPU cards. It is well suited for the nMP, except....
It doesn't have Quick Sync. This is really Intel's fault, not Apple. Intel may have viewed Quick Sync as a consumer-related technology, or maybe it's architecturally tied to their on-chip GPU. At the current process technology an on-chip GPU is expensive; it's understandable leaving it off (most) Xeons.
This Intel web site implies Quick Sync is (currently) inextricably tied to their on-chip GPU: http://www.intel.com/content/www/us...uick-sync-video/quick-sync-video-general.html
Likewise this Intel white paper says only the Xeon X3-1200 v3 has Quick Sync, apparently due to its on-chip GPU: http://newsroom.intel.com/servlet/JiveServlet/downloadBody/3880-102-1-6896/WP-HD-Graphics-4200.pdf
Quick Sync is limited to certain codecs and certain parameters, e.g, single-pass H.264, MPEG-2, etc. However those are commonly used. When H.265 becomes common, maybe all the Quick Sync-accelerated systems will stumble, and the more flexible GPU-based approaches will shoot ahead.
The problem is the nMP is a workstation-class machine pitched at higher-end video tasks. Part of those tasks may include transcoding of common formats like single-pass H.264. The Xeon generally doesn't have hardware acceleration of that, and 6 or 12 cores can't equal Quick Sync's dedicated hardware. I wouldn't use single-pass H.264 for the final rendering of a feature film, but it's very useful for many other things.
In theory the nMP's immensely fast GPU could be harnessed for transcoding but that's a different programming model and may take longer to upgrade software for that. Also, page 10 of Intel's IDF13 white paper implies a GPU (while more flexible) still can't achieve the transcoding performance of Quick Sync. In a Tom's Hardware test, Quick Sync was still faster than GPU-accelerated transcoding: http://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
The obvious long-term solution is for Intel to add Quick Sync to Xeon, and for Apple and other vendors to add GPU acceleration (where not already present) to video transcoding software.
But what to do in the near term? That's a good question. A nMP will be a more expandable, flexible choice, capable of higher multi-threaded and GPU-based performance than other Macs, and over a wider range of tasks. Unfortunately in this one narrow area (video transcoding of single-pass H.264 and MPEG-2), Quick Sync gives lesser systems an advantage.
Well put.
I definitely don't fault Apple for the lack of QuickSync, and to an extent, Intel. It would seem to me that AMD is the one who should've considered this type of optimization for their GPUs.
GPU makers have always focused on two high profit markets, high end games and workstation graphics such as 3D CAD and animation. They neglect to consider the potential market for speeding up video compression.
Editing programs spit out huge files. 1 minute of 1080p ProRes 422 can take up 60 GB or more per hour... just imagine how large 4K files will be. Without hardware assisted compression, the long waits for compression are going to get much longer as 4K becomes more mainstream.
In a nutshell, almost every video editing project must end with delivering a compressed file. Faster compression is not just a luxury, it should be considered part of the goal of both hardware and software developers in order to give editors a complete start-to-finish solution.
We've come to accept that this last dreaded step is just a part of the job. Something you do before you go for lunch or that you leave running all night so you can have it ready when you get back to your desk in the morning. The trouble with that is if you find something wrong, you fix it and you have to do it all over again. That means another lunch break... or another day later.
I still have hope. I keep thinking that if they can split a Compressor job between other Macs on your LAN, then the architecture of splitting the job up into computational tasks and just waiting for results is already there. I'm hoping that means there must be a way to use that technique to send jobs to the GPUs.
The fact that there is a HandBrake OpenCL Beta in the works means at least they think it can work.
----------
I had no trouble doing the BruceX export using the presets, but did get errors when I tried to export it as a 5K H.264. My 57 second render time (on a MacBook Pro 2011) was based on exporting a 5K master, which is in the native ProRes 422 format.
I could also export it into other sizes in H.264... just not 5K.
I definitely don't fault Apple for the lack of QuickSync, and to an extent, Intel. It would seem to me that AMD is the one who should've considered this type of optimization for their GPUs.
GPU makers have always focused on two high profit markets, high end games and workstation graphics such as 3D CAD and animation. They neglect to consider the potential market for speeding up video compression.
Editing programs spit out huge files. 1 minute of 1080p ProRes 422 can take up 60 GB or more per hour... just imagine how large 4K files will be. Without hardware assisted compression, the long waits for compression are going to get much longer as 4K becomes more mainstream.
In a nutshell, almost every video editing project must end with delivering a compressed file. Faster compression is not just a luxury, it should be considered part of the goal of both hardware and software developers in order to give editors a complete start-to-finish solution.
We've come to accept that this last dreaded step is just a part of the job. Something you do before you go for lunch or that you leave running all night so you can have it ready when you get back to your desk in the morning. The trouble with that is if you find something wrong, you fix it and you have to do it all over again. That means another lunch break... or another day later.
I still have hope. I keep thinking that if they can split a Compressor job between other Macs on your LAN, then the architecture of splitting the job up into computational tasks and just waiting for results is already there. I'm hoping that means there must be a way to use that technique to send jobs to the GPUs.
The fact that there is a HandBrake OpenCL Beta in the works means at least they think it can work.
----------
I had no trouble doing the BruceX export using the presets, but did get errors when I tried to export it as a 5K H.264. My 57 second render time (on a MacBook Pro 2011) was based on exporting a 5K master, which is in the native ProRes 422 format.
I could also export it into other sizes in H.264... just not 5K.
I got 22 seconds with BruceX with my nMP (6-core/D500)... Compared with 145sec. On my 2009 Mac Pro...
https://forums.macrumors.com/threads/1692536/
I couldn't get H264 codec to work so used the ProRes LT option.
To me the trouble with the BruceX benchmark is that it's nothing like a real world test... it's 5K, and it's only a few seconds long, so the results aren't long enough to gauge time savings. This is further compounded by the fact that under short loads like this, Turbo-Boost favors non-workstation CPUs. If the test were longer, like my 8 minute test... you can hear the CPU fans kick into high gear, which also means they are too hot to Turbo Boost.
I'm guessing we couldn't get the H.264 codec to work in full 5K because it gets sent to QuickSync and that may not be able to handle 5K.
Speaking of my 8 minute benchmark... I had planned to post a YouTube video of me doing the test in real time, so people could see the procedure itself and see that the results were real.
I didn't want a screen capture to slant the results, so I pointed a DSLR at the screen. Then I added some titles, a timecode and a voice track. It took 27 minutes to record. That's when it got interesting. The rendering took HOURS, and barely moved past 25%... So I decided to let the background render complete itself before making a master. This took about 4-5 hours more.
When it was done, I exported the ProRes 422 master... it took a while, but since it had been background rendered, it wasn't too bad. I then attempt to send it to Compressor. The wait was driving me nuts.
So here I was nearly 6 hours into this 27 minute project and I realized that since videos and compression vary based upon the content (for example static content renders and exports faster than moving content), I created a compression nightmare. Even though to me, the content was somewhat static (all you see is the FCPX screen for 27 minutes)... it was actually very dynamic. Because it was a camera pointing to the screen, the camera likely saw it as a very rapidly changing subject... pixels flickering 60 times per second.... compounded by me adding static titles... and the timecode moving frame by frame.
In a sense, I did everything wrong... and right. While I was trying to torture test FCPX with my benchmark, documenting the benchmark became an even more exhaustive benchmark. It beat the crap out of my MacBook Pro for 6+ hours with the fans going at full speed as it gasped for air.
I'm sure the Mac Pro with D700s would've handled it better, especially since it was purpose driven to handle tough loads and background rendering.
For the record, I tried to export the 32GB ProRes master using Compressor 4.1, but after all those hours waiting to export the master, I tapped out as I saw it crawl barely 10% in 25+ minutes.
I gave up... loaded it into HandBrake, using the "Normal" preset... it crunched it at 45+ fps... and gave me a nice 400MB file in about 20 minutes, better than real-time (27 minutes).
The strange thing is for some of my projects, HandBrake is much slower than Compressor, other time it leaves it in the dust.
My question for the OP is, are you really basing your entire computer purchasing decision on solely one function, exporting with compressor?
What about the rest of your workflow? You do have to produce the videos before you can export them.
That's why for me, I'm less concerned about importing in LR, and more about the generation and loading of previews.
One other thought.. have you tested if the nMP handles exports well in the background? as compared to your current systems?
What about the rest of your workflow? You do have to produce the videos before you can export them.
That's why for me, I'm less concerned about importing in LR, and more about the generation and loading of previews.
One other thought.. have you tested if the nMP handles exports well in the background? as compared to your current systems?
My question for the OP is, are you really basing your entire computer purchasing decision on solely one function, exporting with compressor?
What about the rest of your workflow? You do have to produce the videos before you can export them.
That's why for me, I'm less concerned about importing in LR, and more about the generation and loading of previews.
One other thought.. have you tested if the nMP handles exports well in the background? as compared to your current systems?
You hit the nail right on the head. I hate the wait for compression more than I generally hate the wait for the background renders. Because many times, I don't notice the time it takes to background render because as I make my way through a project, the background renders are often done by the time I export and compress.
The twist here was that I discovered a scenario where I lost more time before hitting export than after. In fact, when I attempted to export before letting the background render complete, it took hours and barely made 20%... so I stopped the export, then decided to let it background render first. It still took quite a few hours, but that made the export faster.
When I discovered a typo in one of my titles... It had to re-render nearly the whole thing (in the background at first)... dragging the whole thing out to nearly 7 hours from end to end.
The lesson learned: As it stands, I WILL NOT cancel the order and I hope that these kinds of background rendering tasks will be diminished enough to tolerate compression times that are twice as slow as my MacBook. Maybe there will be better OpenCL compression in the future. Worst case, edit and render on the nMP... compress with my MacBook.
Ho hum
I cancelled. Partly because I discovered that FCPx10.1 plays nice with dual 5770s, so buying another one of those will be a significant upgrade.
Partly through learning about the joys of RAID0 pcie SSDs from here (thanks all)
And also because I had a big tidy up, hiding printer, airport and other peripherals. The workplace looks much neater with Mac Pro and screen. While the nMP is a lot smaller, I'd need external storage for RAID0 which would add to clutter and energy draw.
I cancelled. Partly because I discovered that FCPx10.1 plays nice with dual 5770s, so buying another one of those will be a significant upgrade.
Partly through learning about the joys of RAID0 pcie SSDs from here (thanks all)
And also because I had a big tidy up, hiding printer, airport and other peripherals. The workplace looks much neater with Mac Pro and screen. While the nMP is a lot smaller, I'd need external storage for RAID0 which would add to clutter and energy draw.
To put it into the perspective of a photographer using LR, imagine that you shoot 2000 raw photos of a wedding and you shot all of them with a messed up light balance. You import all the files, and because of your new faster Mac Pro, you through the previews in a fraction of the time and they all look perfect, but then you have to save the final JPGs, only to find that your old MacBook will take twice as long as your MacBook. It did save you time looking at the previews with the filters you selected, but you lose some when you deliver it. But then... you find out that the monitor was not calibrated, so you need to adjust everything a bit... now that slow last step will pile up.
This is what often happens to me. I'm not a video pro per se, so I make lots of mistakes. Unfortunately, I tend to catch mistakes as I sit there waiting for the final render or compression. So, I make a quick change (typo in a title, wrong sound level, missed cut, etc)... then I wait for the final export / compress. If you make the kinds of mistakes I do, it adds up to hours lost.
Naturally, if I took the time to render lower quality proofs or just viewed it all in FCPX before render / compression... and didn't keep looking to tweak it, I wouldn't mind the exporting time.
Yes. I discovered that unless I let it render everything before generating the master, it's not only slower, but it makes subsequent changes slower.
You should check out one of the external h264 accelerators here:
http://www.matrox.com/video/en/products/
http://www.matrox.com/video/en/products/
Well, in my case, LR is mainly CPU bound, for now, but PS is beginning to get updated for the new GPUs.. and with the other tools, some are faster, some are slower..
What it really should boil down to for anyone is are there enough improvements overall to make it worth upgrading? For me sitting on a 1,1 cMP, yes, as I'm not a fan of the iMac, and there's not a headless iMac option.
(Of course, if Fujifilm rolls out that XT-1 as expected, and I still don't have a nMP in my hands.. my dollars might waver...
Thanks! I'll check them out.
It does go to show you there's a market for hardware to compress video... and it makes you wonder why AMD didn't consider this to be a feature of the D300s, D500s and D700s. After all, if they are going to claim video editing to be a target audience, they should try to optimize the whole workflow.
It does go to show you there's a market for hardware to compress video... and it makes you wonder why AMD didn't consider this to be a feature of the D300s, D500s and D700s. After all, if they are going to claim video editing to be a target audience, they should try to optimize the whole workflow.
It's just my way of rationalizing the choice not to cancel it in spite of the one thing I wanted to see go faster becoming twice as slow as my current rig.
The potential for the graphics card to compress video is already there. If Apple & Adobe can encode video within their video editing applications so can others. While quicksync is nice its also limited, something that can be programmed into existing applications using the GPU.
It is a bit confusing, considering your primarily concerned with compression, but when background rendering is not complete, it affects the final render as well.
I have the Matrox CompressHD PCIe card. But it comes with its own set of problems. You have to be careful when upgrading Compressor and/or FCP X or operating system ( Or any supported application for that matter )
Is often a long wait in them supporting the drivers which I'm still waiting...I made the mistake of upgrading Compressor 4 which did not work anymore.
I also use Wirecast...so I can only use version 2.3.1 drivers ( Vice 4.04 ) for the hardware encoder as newer version uses AV Foundation and Wirecast is still using older ones based on Quicktime.
Why not? Are you targeting a bandwidth-limited delivery mechanism like DVD, Blu-Ray or the web? If not, consider a constant-quality single-pass encode, which allows the bit rate to continually adapt with each GOP as action and detail fluctuate.
It's just my way of rationalizing the choice not to cancel it in spite of the one thing I wanted to see go faster becoming twice as slow as my current rig.
lol ok. Main thing to worry about is the overall performance..and not just one thing.