Considering cancelling my Mac Pro order. No speed benefits in FCPX / Compressor

[nathan43082]

I did another HandBrake test using Apple TV 3, it generated a 159mb file, instead of 111, and it actually ran a bit faster... 14:30. I love the fact that the files are so small compared to Compressor, but Compressor is so much faster on my MacBook 3:37.

You are using single-pass encoding, right? You should with constant quality. A second pass would add nothing to the equation.

----------

Great resource, thanks!

In my case, I normally have 3 possible destinations. Tablets like iPads, media players like Apple TV, and streaming sites like YouTube (which should re-process the stream into all sorts of devices and sizes for you).

I've generally just used Apple's YouTube preset for the stuff I put online, then used the Apple TV 3rd gen as my second target (using the newer Apple Devices HD (Best Quality). While the file size was 5-6 times bigger, it renders at a 5-10 times faster than HandBrake.

I think I'll use HandBrake to eventually spit out a nice small file for archives, but send the larger ones to YouTube, so when they process and re-compress it into other formats, they are starting with more data.

I'm very excited to hear about HandBrake's beta using OpenCL. As I've said, that would be a real game changer for a lot of people.

I guess I am old school when it comes to compression. I prefer the smallest possible file with the highest possible quality, even if it takes longer to encode; at least within reason. I won't double compression time for a 5% improvement in quality.

 

[CouponPages]

You are using single-pass encoding, right? You should with constant quality. A second pass would add nothing to the equation.

----------



I guess I am old school when it comes to compression. I prefer the smallest possible file with the highest possible quality, even if it takes longer to encode; at least within reason. I won't double compression time for a 5% improvement in quality.

The Apple TV 3 Preset in HandBrake is *probably* a single pass. It's not checked, but it's also greyed out, so it's possible it may turn it on and off depending on the content.

I'm in the same boat when it comes to compression. I want the smallest possible files without visible loss, but I also want them fast. It looks like you can't have both. The interesting thing about smaller files is you get speed when you move them around later.

I like the idea that HandBrake lets you dial up a picture quality rather than assuming a pre-set filesize. Apple should consider an option like that. It takes the guesswork out of deciding a bitrate.

Let's hope HandBrake OpenCL gets out of Beta soon. I'd love to see how the D700s would do.

 

[nathan43082]

The Apple TV 3 Preset in HandBrake is *probably* a single pass. It's not checked, but it's also greyed out, so it's possible it may turn it on and off depending on the content.

If you changed nothing, then it is single pass. It won't turn on or off all by itself.

I'm in the same boat when it comes to compression. I want the smallest possible files without visible loss, but I also want them fast. It looks like you can't have both. The interesting thing about smaller files is you get speed when you move them around later.

I like the idea that HandBrake lets you dial up a picture quality rather than assuming a pre-set filesize. Apple should consider an option like that. It takes the guesswork out of deciding a bitrate.

One big reason why I don't use Compressor. Both Handbrake and Adobe Media Encoder offer constant quality settings, so I go there instead. I keep hoping Apple will fix that.

Let's hope HandBrake OpenCL gets out of Beta soon. I'd love to see how the D700s would do.

If they do anything with it, it might take a while. My guess is six months to a year. It's all written by volunteers and maintained by a core group.

 

[joema2]

...It's just strange that the $6000 street price for a pair of GPUs like the D700s with 7 TFLOPS of performance are not able to assist in the compression of video. My point is there is a market for a company that can make a card that can compress quickly... while still giving you high quality...

The problem is much existing transcoding software is already written for a conventional multi-core architecture. Re-writing it for the fundamentally different GPU programming model while retaining production-level quality and reliability is not simple.

To illustrate, this ExtremeTech article was titled "The Wretched State of GPU Transcoding": http://www.extremetech.com/computing/128681-the-wretched-state-of-gpu-transcoding

 

[chfilm]

Guys I'm pretty sure that developers will figure out a way to utilize the dual d700s for encoding in time.

Btw, h264 will soon be an old horse anyway, h265 is lurking around the corner and will blow h264 away.
I guess you would have to buy next gen nMP to get hardware acceleration for that. But in the meantime maybe someone figures out a way to make use of the gpus for h265.

If you just look at how great redcine x has been improved performance wise by utilizing the gpus, I'm confident it's doable for h264 encoding as well.
But it will take some time..

I still hope an 8 core nMP might be at least on par with my current 2012 imac in single pass...

 

[CouponPages]

The problem is much existing transcoding software is already written for a conventional multi-core architecture. Re-writing it for the fundamentally different GPU programming model while retaining production-level quality and reliability is not simple.

To illustrate, this ExtremeTech article was titled "The Wretched State of GPU Transcoding": http://www.extremetech.com/computing/128681-the-wretched-state-of-gpu-transcoding

Great link... thanks for sharing. It's amazing how complicated it is. There are so many variables in video compression bit rate, frames per second, keyframes, noise reduction, sound sampling rates/compressions, sizes, aspect ratios, palettes, etc. and each of those potentially require different values based on the source content's image contrast, motion, background noise, etc. It blows the mind.

Even if you tweak the settings to be perfect for one project, if the next project has more scrolling, explosions, stripes, squares, rectangles, colors, your settings could change.

 

[CouponPages]

Guys I'm pretty sure that developers will figure out a way to utilize the dual d700s for encoding in time.

Btw, h264 will soon be an old horse anyway, h265 is lurking around the corner and will blow h264 away.
I guess you would have to buy next gen nMP to get hardware acceleration for that. But in the meantime maybe someone figures out a way to make use of the gpus for h265.

If you just look at how great redcine x has been improved performance wise by utilizing the gpus, I'm confident it's doable for h264 encoding as well.
But it will take some time..

I still hope an 8 core nMP might be at least on par with my current 2012 imac in single pass...

Yes. I've heard that without h.265, 4k files will be too big for widespread public adoption. It'll eat up too much bandwidth.

Here's why I think real-time video compression should be easier to perfect. It's been said that some of the best ideas come from taking an idea from another task and re-applying it to something else.

Consider the chips inside of cameras, such as the Canon DIGIC 6. It's the chip inside the current line of cameras, including some of the lower priced PowerShot models. It takes essentially 21 or more million pixels of raw, uncompressed images that change as much as 60 frames per second and compresses them down (using H264) to 1080p at 60 fps... even factoring in noise reduction and all sorts of filters and settings... in real time as you press the trigger. Hell, even some $100 cameras can compress video in real time using crude chips.

If nothing else, if they simply had a video card that could feed the output to a chip like that instead of the screen, we'd be crunching video in real time, instead of taking 2-10 times more than real time. By chaining two or more of those chips into a larger board, and dividing the clips into chunks you'd have better than real time.

A few years ago, I bought a cheap Chinese camera that had a crappy lens and it shot lousy video, but it had one thing that I hadn't seen in a camera in a long time, a video-in jack. I never shot videos with it, but I used that line-in to digitize a bunch of videos into H.264... it actually did a good job, and the files were small. Granted the videos were SD, but the principle is the same.

 

[linuxcooldude]

Final Cut Pro X 10.1 does utilize the GPU during export. Larry Jordan also emphasizes "Apple Compressor does use the GPUs when exporting from Final Cut Pro X, but not when compressing within Compressor"

I think either Adobe Premiere Pro or Adobe Media Encoder also uses the GPU for export too.

 

[jerryrock]

"Optimized playback and rendering using dual GPUs in the new Mac Pro "

https://www.macrumors.com/2013/12/19/apple-updates-final-cut-pro-x-with-2013-mac-pro-compatibility-4k-content/

"Final Cut Pro X companion apps Compressor and Motion have also received similar improvements."

 

[CouponPages]

Final Cut Pro X 10.1 does utilize the GPU during export. Larry Jordan also emphasizes "Apple Compressor does use the GPUs when exporting from Final Cut Pro X, but not when compressing within Compressor"

I think either Adobe Premiere Pro or Adobe Media Encoder also uses the GPU for export too.

Really? That's a big step in the right direction. So, if I create a Compressor Preset, then pull that into FCPX as a share preset, when I push the video from FCPX using that Compressor Preset, it'll go faster than if I loaded into Compressor itself? It sounds almost too good to be true.. and if it's true, then I would imagine they would eventually fix it so you get the same result if you load compressor directly.

I will go to the Apple Store, and re-do the benchmark (on the D300s) and export directly from FCPX using the Compressor "Apple Devices HD (Best Quality)" to see if it gets a better response. If it does.. I'll let you know.

 

[DrManhattan]

It's going to take a few months for apps to be optimized for the new Mac Pro. Same thing happened with the Retina Display.

 

[CouponPages]

By the way... I just posted the XML of my Benchmark on my DropBox account, it's only 2k and uses only built-in effects, like BruceX.

The CouponPages Benchmark

Because it will render the whole thing at once, you don't get the fun of timing the background renders of each independent step, but you can test the final render and compression.

One reason I'm posting it here so that when I get to the Apple Store, I can just click it and jump right to the final rendering.

If anyone with a hex core or greater with D500s or D700s wants to compare.. the time to beat on the stock quad core D300s is 6:25... and my MacBook Pro 17" Late 2011 does it in 3:37 (because it's an i7 with QuickSync).

== EDIT ==

I just created a blank library to test the XML and made two observations.

1. If you load the XML and let it finish the background render, the sum time to background render is pretty decent, so it's quicker than the sum of each step.

2. If you do let it finish the background render, the share through the Compressor preset will be slightly faster than from Compressor directly... most likely because it's already in memory (assuming you have decent amounts of RAM... I have 16GB).

3. If you don't let it finish the background render before hitting share, the final render will take more than twice as long... then it'll still need to background render the project when it's done (somehow it doesn't save it).

Also... as I write this, Apple has pushed out an update to the CODECs inside the Pro Apps to 1.0.4, since it looks like they just released it, there isn't much written about what the improvements are, but one source thinks it has something to do with Haswell tweaks.

 

[joema2]

Final Cut Pro X 10.1 does utilize the GPU during export. Larry Jordan also emphasizes "Apple Compressor does use the GPUs when exporting from Final Cut Pro X, but not when compressing within Compressor"

I think either Adobe Premiere Pro or Adobe Media Encoder also uses the GPU for export too.

I can confirm FCP X 10.1 uses the GPU on export, at least for the Apple 720p and 1080p presets. Using iStatMenus to monitor GPU memory and GPU processor, they are very active. Doing a similar export in Compressor was much slower, and it showed no GPU activity.

In my tests, FCP X 10.1 was roughly 5 times faster than Premiere Pro CS6 in exporting the same project. CS6 was on a Windows machine roughly equal to my 2013 iMac 27, but it had a more powerful GPU. CS6 does not use GPU for rendering or exporting. The GPU is only used for effects.

I assumed the huge performance advantage of FCP in my export tests was due to GPU, but maybe it was also due to Quick Sync.

 

[CouponPages]

The strange thing for me on my MacBook Pro Late 2011, which does have a Radeon HD 6670M (1GB) GPU is that I made a habit of always exporting a master in FCPX then exiting and loading Compressor because I found it to be MUCH faster.

Using my benchmark video, it's still about twice as fast if I exit FCPX and process directly in Compressor. Since there are often fluctuations in times (sometimes big ones), I ran the export 3-4 times and although sending it directly from FCPX gave me good results once... using Compressor directly is still consistently faster using the same preset.

With my benchmark, doing the final export consistently gives me about 3:30 to compress vs about 6-7 minutes when I do it in FCPX. I'm not sure why, but I plan to test this on the demo Mac Pro in the store to see if the D300s make any difference.

As a reminder, thus far, my MacBook Pro 2011 has always done this step at least twice as fast as the 4 core Mac Pro D300 in the Apple Store. Prior to Apple's update of FCPX to 10.1, the Mac Pro took about an hour to do it... thankfully they finally pushed the right software on them.

 

[N19h7m4r3]

As a reminder, thus far, my MacBook Pro 2011 has always done this step at least twice as fast as the 4 core Mac Pro D300 in the Apple Store. Prior to Apple's update of FCPX to 10.1, the Mac Pro took about an hour to do it... thankfully they finally pushed the right software on them.

I don't get it, besides Quick Sync, the entire architecture and system of the MBP is inferior to the MP in ever way.

I find it really bizarre that it can outperform amuck newer and faster system.

 

[CouponPages]

I don't get it, besides Quick Sync, the entire architecture and system of the MBP is inferior to the MP in ever way.

I find it really bizarre that it can outperform amuck newer and faster system.

Agreed. Quite inferior. My MBP 2011 has a slower CPU (2.5 Ghz i7 vs 3.7 Xeon... in the Quad Core base I tested), my internal drive is 250Gb SATA III SSD from Corsair (fast... but not even close to PCIe).

My MBP has 16 GB RAM vs 12 GB in the demo nMP, but it shouldn't be a factor.

We can't underestimate QuickSync's role in single pass H.264 rendering. Hardware designed specifically to compress video. Apparently the GPUs in the Mac Pro are not designed for compression.

It's an issue of purpose driven hardware and software working together. QuickSync is hardware designed specifically for single pass H.264 compression. If I created videos with any other format, it would not use the hardware and subsequently crawl.

On a technical level, many people don't like the quality of QuickSync's compression, but it's fast and to the untrained eye, very hard to distinguish from software based compression.

I'm still hoping they figure out a way to tap into the GPUs to compress video. To me, if they can split jobs up across multiple Mac nodes on a network, they should be able to treat the GPUs a node and get some boost.

I'm hoping to find time in the next few days to try LinuxCoolDude's suggestion of exporting directly from FCPX instead of directly from Compressor. If it can at least match my MBP, I will do a little happy dance right in the store.

 

[linuxcooldude]

I can confirm FCP X 10.1 uses the GPU on export, at least for the Apple 720p and 1080p presets. Using iStatMenus to monitor GPU memory and GPU processor, they are very active. Doing a similar export in Compressor was much slower, and it showed no GPU activity.

In my tests, FCP X 10.1 was roughly 5 times faster than Premiere Pro CS6 in exporting the same project. CS6 was on a Windows machine roughly equal to my 2013 iMac 27, but it had a more powerful GPU. CS6 does not use GPU for rendering or exporting. The GPU is only used for effects.

I assumed the huge performance advantage of FCP in my export tests was due to GPU, but maybe it was also due to Quick Sync.

Using the BruceX FCP X benchmark I confirmed simular results. Using Compressor 4.1 took 5:57 minutes....FCP X 10.1.1 took 1:30 minutes. This was on a 2009 Octo core Mac Pro using an Nvidia GTX 570.

I don't think Adobe CS6 supports multiple GPUs as far as I know, but the newer Adobe CC one does.

Making a video on the results which I will post later.

 

[td2243]

I don't get it, besides Quick Sync, the entire architecture and system of the MBP is inferior to the MP in ever way.

I find it really bizarre that it can outperform amuck newer and faster system.

That's the whole point. Is the MP really worth a $5K investment for results inferior to a laptop? People can say "you're using the software wrong" or "that isn't a valid test given the Map Pro's design", but those statements are silly.

IMHO, for the price of the MP, it should crush laptop performance. A $2500 iMac performs better in many instances. That is both a testament to the power of the current iMacs, but also presents the MP as less than extraordinary.

 

[Dranix]

It does - Just not in the sucking 1pass quality the intel hw encoder produces. I wonder why anyone would accept that ugly quality.

 

[linuxcooldude]

That's the whole point. Is the MP really worth a $5K investment for results inferior to a laptop? People can say "you're using the software wrong" or "that isn't a valid test given the Map Pro's design", but those statements are silly.

IMHO, for the price of the MP, it should crush laptop performance. A $2500 iMac performs better in many instances. That is both a testament to the power of the current iMacs, but also presents the MP as less than extraordinary.

Thats because Intels QuickSync technology is a one trick pony. It can only do single pass in H264. If your a professional video editor you might need to work in multiple formats with different codecs then it won't work.

Where quality counts for broadcast applications QuickSync is also not the answer.

Some people don't want QuickSync to automatically take over in some cases where they want to control every aspect of the render of video.

More then likely QuickSync was meant to be a consumer version rather then a professional one. Probably the reason why its used on consumer CPU's i5/i7 while Xeons don't.

Perhaps thats why Apple is using the GPU's and OpenCL to do rendering within FCP X. You can control every aspect of how your video is rendered, instead of any limitations that might be imposed if your using something like "QuickSync"

I do hope they will make Compressor use GPU rendering as well in the future.

 

[CouponPages]

That's the whole point. Is the MP really worth a $5K investment for results inferior to a laptop? People can say "you're using the software wrong" or "that isn't a valid test given the Map Pro's design", but those statements are silly.

IMHO, for the price of the MP, it should crush laptop performance. A $2500 iMac performs better in many instances. That is both a testament to the power of the current iMacs, but also presents the MP as less than extraordinary.

The concept of which is superior comes down to purpose. For mid-range video production, the iMac / MacBook Pro are superior at high speed compression. If you are doing 3D design, like Pixar a nMP with D700s will outperform just about any other computer on the planet... so it's superior to them.

If you compose complex videos in FCPX and the unrendered previews are stuttering enough to distract you, the Mac Pro is superior. It should be smoother and more responsive. To me, those are "micro" improvements that can add up for some.

If those micro improvements in speed save you 10 seconds a minute, most won't notice it, but that's 10 minutes (600 seconds) an hour. After 8 hours they have saved 80 minutes... potentially yielding more than more than an hour of extra time to either get more done, or get home early.

 

[td2243]

All those responses definitely help. Thanks

 

[CouponPages]

It does - Just not in the sucking 1pass quality the intel hw encoder produces. I wonder why anyone would accept that ugly quality.

It may not be for broadcast TV, where there is a higher degree of measurable standards, but I have a hard time telling them apart for my use.

The funny thing is Apple doesn't have a checkbox for "Use QuickSync" in Compressor... it's just assumed that unless you create a custom preset, you're going to get Single Pass... and subsequently QuickSync on i7s.

 

[N19h7m4r3]

The concept of which is superior comes down to purpose. For mid-range video production, the iMac / MacBook Pro are superior at high speed compression. If you are doing 3D design, like Pixar a nMP with D700s will outperform just about any other computer on the planet... so it's superior to them.

If you compose complex videos in FCPX and the unrendered previews are stuttering enough to distract you, the Mac Pro is superior. It should be smoother and more responsive. To me, those are "micro" improvements that can add up for some.

If those micro improvements in speed save you 10 seconds a minute, most won't notice it, but that's 10 minutes (600 seconds) an hour. After 8 hours they have saved 80 minutes... potentially yielding more than more than an hour of extra time to either get more done, or get home early.

I'm finding this all fascinating. Although I do games testing, 3D rendering, and amateur video editing in my spare time.

For me at least the new MP seems the best match.

Sadly there are no Apple Resellers near me to test things on.
I am however attending a small Apple interactive demonstration, focussing primarily on the new MP and it's uses for business in late February.
I'll certainly bring up this issue where Quick Sync in consumer Intel chips are out performing the MP.

 

[handsome pete]

If you are doing 3D design, like Pixar a nMP with D700s will outperform just about any other Mac on the planet... so it's superior to them.

Fixed that for you.