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

[CouponPages]

I just completed my benchmark from the demo Quad-Core D300 in the Apple Store.

The results... much better. The problematic Compressor compression was cut down from 1 hour to a more manageable 6:25 seconds. However, this is still slower than the 3:15 from my 2011 MacBook Pro. I will re-calculate my MacBook Pro tests one more time, just to be sure the baseline is correct.

Assuming the MacBook times are accurate, the gap has closed a bit, but since the times are no closer, I will run them one more time on each because one thing about a benchmark, it can change depending on unseen background tasks.

In case other people would like to try the benchmark using other rigs, such as the 6,8 or 12 core with D500 or D700, I will make a video showing the exact steps so people can verify the timing. Naturally, I'll point a camera to the screen so the screen capture does not have any effect on the results.

 

[deconstruct60]

Most likely because for video compression, there is no QuickSync to give hardware acceleration to H.264 compression.

Actually there is a H.264 encoders.... it just isn't Intel's specific implementation.

"... Quick Sync made real-time H.264 encoding practical on even low-power devices, and made GPU encoding redundant at the time. AMD of course isn’t one to sit idle, and they have been hard at work at their own implementation of that technology: the Video Codec Engine (VCE). ... "
http://www.anandtech.com/show/5261/amd-radeon-hd-7970-review/9

Of course Apple's probably assignment of 3-4 to make the Mac Pro case as shiny and glossy as possible probably under resourced any work to make Apple's hardware H.264 encoder support not stuck entirely to Intel hardware.

Apple is skittish about proprietary hardware/interfaces but this is one of those one of those where it is more tha reasonable to bite the bullet on some singular, low level fixed function.

Very similar issue to why AirPlay won't work on most ( or all ?) previous Mac Pros where there is no shortage of hardware horseppower to make it happen.

VCE probably wouldn't bring them exactly even.

"... Both VCE and QuickSync appear to halve transcoding times... except the latter looks to be considerably faster. ... "
http://techreport.com/review/22932/amd-a10-4600m-trinity-apu-reviewed/8

(a dGPU should do better than a A10 though. )

QuickSync's "ultra fast" mode isn't necessarily high quality though. 20x slower at producing the same quality ?

 

[anticipate]

I just completed my benchmark from the demo Quad-Core D300 in the Apple Store.

The results... much better. The problematic Compressor compression was cut down from 1 hour to a more manageable 6:25 seconds. However, this is still slower than the 3:15 from my 2011 MacBook Pro. I will re-calculate my MacBook Pro tests one more time, just to be sure the baseline is correct.

Assuming the MacBook times are accurate, the gap has closed a bit, but since the times are no closer, I will run them one more time on each because one thing about a benchmark, it can change depending on unseen background tasks.

In case other people would like to try the benchmark using other rigs, such as the 6,8 or 12 core with D500 or D700, I will make a video showing the exact steps so people can verify the timing. Naturally, I'll point a camera to the screen so the screen capture does not have any effect on the results.

If you run single pass H.264 encoding, then yes, an iMac or MBP will be faster. Significantly in some cases.

If you perform multi pass encoding for quality (I always do) than the nMP will be significantly faster, assuming you have 6+ cores. Same with ProRes render outs; I am seeing up to 45% increase in speed over my maxed out late 2012 iMac. So it depends on what you're trying to do.

And FCPX is significantly faster all around on the nMP with the latest version. Fluid for the most part. And I hate FCPX but I'll admit it's well coded.

 

[AidenShaw]

Apple is skittish about proprietary hardware/interfaces....

Oh, I see.

- That's why Apple offers both ATI and Nvidia graphics cards in the new Mini Pro.

- That's why any generic SSD can be swapped for the Apple SSD in the new Mini Pro.

- That's why any standard ATX power supply can be used in the new Mini Pro if you need more power.

- That's why any off-the-shelf graphics card from Newegg or Fry's can be installed in the new Mini Pro if you want something cheaper or better.​

Until I read your post, I thought that Apple was all about proprietary hardware lockin.

</sarcasm>

 

[richard371]

If you cancel it now and reorder you then have another 6 weeks before it ships to see if software catches up etc.

 

[mrsavage1]

If you cancel it now and reorder you then have another 6 weeks before it ships to see if software catches up etc.

This is a reasonable position to be in. I too am gonna wait. There are still too many questions.

 

[richard371]

Yea if questions aren't answered in about 5 weeks when mine is close to shipping I'll cancel and get back in line again for another 6 weeks lol.

This is a reasonable position to be in. I too am gonna wait. There are still too many questions.

 

[daviesaz]

I then called corporate, Tweeted the issue with all the popular hashtags #MacPro, #AppleStore etc., posted in popular forums, wrote daily emails to Tim Cook and Phil Schiller, used the Mac Pro feedback form on the site... Nothing. They didn't seem to care that the Mac Pros are all using old images.

It's not a priority for them. [/URL]

I don't think they want to do anything extra that will outsell their capacity to produce. They're already quoting March deliveries. Why would they want to push that out to April or May? When their supply chain is up to speed, you can bet they'll pull out all the stops to show maximum performance.

Installing old software on their new computer? Just a marketing trick to keep the doubters from clogging the order flow.

 

[td2243]

If you cancel it now and reorder you then have another 6 weeks before it ships to see if software catches up etc.

Software companies have known about the dual GPU MP for like 8 months now. What makes you think they will get it together in 6 weeks? Believe me, I hope they do, but it seems unlikely.

 

[CouponPages]

I just spent an hour or so re-calibrating my entire test, which I also recorded with a DSLR (so it wouldn't alter the speeds by screen capturing it).

I'm happy to report... I'm more frustrated than before, so the order stands, for now.

It all comes down to where your "Pain Points" are. What is the part of your workflow that drives you crazy and you want to fix?

For me, the final compression is painfully slow. The funny thing is Compressor lets you cut the time down by tapping into other Macs running Compressor on your network. You would think that if they can split the rendering job into multiple computers, it would be able to split the job up into bite-sized chunks and send them to the GPUs.

The fact that they don't is pretty funny, when you think of it. Based upon my final set of figures, the Mac Pro now kicks my MacBook's ass on every step... except the one step that bothers me... compressing it.

My test has 5 steps:

1. Create a 1920 x 1080p 30p project, and place "Pages" Generator on the timeline... then make the duration 8 minutes, then time how long it takes to background render it.

2. Add the "Clouds" title to the start, change it's duration to 8 minutes too... and time the background render.

3. Add the "Romantic" filter to the "Pages" clip and time the background render.

4. Export a ProRes 422 master, then time it.

5. Compress it with Compressor using the "Apple Devices HD (Best Quality)" preset... then time it.

The results comparing a Mac Pro D300 / Quad Core store display to my Late 2011 MacBook Pro:

1. MacBook: 2:49 vs Mac Pro 1:49 (Mac Pro beats it by 35.5%)

2. MacBook: 6:52 vs Mac Pro: 2:28 (Mac Pro beats it by 64%)

3. MacBook: 8:31 vs Mac Pro: 2:44 (Mac Pro beats it by 68%)

4. MacBook: 1:01 vs Mac Pro: :36 (Mac Pro beats it by 40.9%)

5. MacBook: 3:37 vs Mac Pro: 6:25 (MacBook beats Mac Pro by 77.4%)

The kick in the ass for me is although the top 4 section are clearly faster on the Mac Pro, other than step 4 (creating the master file), the faster speed is in the background so it just makes it "feel" faster. You can edit to your heart's content without stopping, it'll just stutter from time to time while it background renders every time you make a change).

So I'm back where I started I guess, lacking actual time savings in my pain points... plus I would love to know if my configuration 6 core / D700 makes a difference?

If my real pain points are the last stage, can I overlook them because the edit process feels smoother, even though it won't get the job done any quicker? One thing we now know, these figures prove that poorly configured software can make or break your experience. Putting the wrong software in the Apple Stores made that obvious.

If anyone with a 6 core / D700 has any thoughts / statistics on their workflow improvements, it would be useful to me and others like me who are sitting on the fence.

A grand slam for me would be to either try this on my 6 core D700s when they finally arrive... or potentially hear from somebody who is curious enough to try it on theirs.

This could come down to the wire. I may get the thing, test it... still get crappy compression times and fall in love with it anyway. Rats!

 

[ozbimmer]

I just spent an hour or so re-calibrating my entire test, which I also recorded with a DSLR (so it wouldn't alter the speeds by screen capturing it).

I'm happy to report... I'm more frustrated than before, so the order stands, for now.

It all comes down to where your "Pain Points" are. What is the part of your workflow that drives you crazy and you want to fix?

For me, the final compression is painfully slow. The funny thing is Compressor lets you cut the time down by tapping into other Macs running Compressor on your network. You would think that if they can split the rendering job into multiple computers, it would be able to split the job up into bite-sized chunks and send them to the GPUs.

The fact that they don't is pretty funny, when you think of it. Based upon my final set of figures, the Mac Pro now kicks my MacBook's ass on every step... except the one step that bothers me... compressing it.

My test has 5 steps:

1. Create a 1920 x 1080p 30p project, and place "Pages" Generator on the timeline... then make the duration 8 minutes, then time how long it takes to background render it.

2. Add the "Clouds" title to the start, change it's duration to 8 minutes too... and time the background render.

3. Add the "Romantic" filter to the "Pages" clip and time the background render.

4. Export a ProRes 422 master, then time it.

5. Compress it with Compressor using the "Apple Devices HD (Best Quality)" preset... then time it.

The results comparing a Mac Pro D300 / Quad Core store display to my Late 2011 MacBook Pro:

1. MacBook: 2:49 vs Mac Pro 1:49 (Mac Pro beats it by 35.5%)

2. MacBook: 6:52 vs Mac Pro: 2:28 (Mac Pro beats it by 64%)

3. MacBook: 8:31 vs Mac Pro: 2:44 (Mac Pro beats it by 68%)

4. MacBook: 1:01 vs Mac Pro: :36 (Mac Pro beats it by 40.9%)

5. MacBook: 3:37 vs Mac Pro: 6:25 (MacBook beats Mac Pro by 77.4%)

The kick in the ass for me is although the top 4 section are clearly faster on the Mac Pro, other than step 4 (creating the master file), the faster speed is in the background so it just makes it "feel" faster. You can edit to your heart's content without stopping, it'll just stutter from time to time while it background renders every time you make a change).

So I'm back where I started I guess, lacking actual time savings in my pain points... plus I would love to know if my configuration 6 core / D700 makes a difference?

If my real pain points are the last stage, can I overlook them because the edit process feels smoother, even though it won't get the job done any quicker? One thing we now know, these figures prove that poorly configured software can make or break your experience. Putting the wrong software in the Apple Stores made that obvious.

If anyone with a 6 core / D700 has any thoughts / statistics on their workflow improvements, it would be useful to me and others like me who are sitting on the fence.

A grand slam for me would be to either try this on my 6 core D700s when they finally arrive... or potentially hear from somebody who is curious enough to try it on theirs.

This could come down to the wire. I may get the thing, test it... still get crappy compression times and fall in love with it anyway. Rats!

I see I this way: you spent 13 mins on the Mac Pro to complete the 5 steps compared to 22 mins on the MBP. Is that an improvement?

 

[CouponPages]

I see I this way: you spent 13 mins on the Mac Pro to complete the 5 steps compared to 22 mins on the MBP. Is that an improvement?

The trouble is the biggest gains are in the first steps, which happen in the background anyway. So, although they can eliminate occasional stutter while an un un-rendered clip renders in the background, but there isn't an actual time savings.

The only steps that cause me to wait for the system are steps 4 and 5. Step 4 (Render to a master) did have a nice bump on the Mac Pro... then it takes it away in the last. In theory, if I didn't use a preset, and fine tuned my output to make a custom multi-pass preset, the Mac Pro should be faster, but I'm not sure how much... mainly because I'm generally happy with the Apple Devices HD (Best Quality) preset. The resulting file is usually a good mix of quality and speed.

So based upon just time savings, the render phase (with a 4 core D300) were 40% better on the Pro than the MacBook... but they vanish if I take 77% longer to compress.

I may not know until I get results based upon 6 core D700s... but if everything I've read about compression is accurate, there may not be much of a boost. At best, it may be a tie.

 

[anticipate]

Are your tests based on a 4core nMP? If so expect a roughly 40% (give or take; that's theoretical) decrease with 6 cores in export time to H264. It scales under compressor with more CPUs. However again, the "apple devices" preset is single pass. If you want more quality and a smaller file, you should be encoding multipass. Multipass does not use QuickSync on non-Xeon chips, so it will be slower. But it will be relatively much faster on the 6+ core nMP than the MBP.

 

[CouponPages]

Are your tests based on a 4core nMP? If so expect a roughly 40% (give or take; that's theoretical) decrease with 6 cores in export time to H264. It scales under compressor with more CPUs. However again, the "apple devices" preset is single pass. If you want more quality and a smaller file, you should be encoding multipass. Multipass does not use QuickSync on non-Xeon chips, so it will be slower. But it will be relatively much faster on the 6+ core nMP than the MBP.

Yes. It's the stock D300 they put in the stores. Do you think the D700 will give an improvement too. That's what I ordered.

I'll create a custom preset based upon that one, with the exception of adding multi pass and measure the results.

Still... It makes me wonder why Apple would call that one "(best quality)", when in fact it's just better than the normal quality. They should've created three... Normal, better, best... With the latter being a multi pass version of the middle option.

 

[nathan43082]

For me, the final compression is painfully slow.

I've owned every version of Compressor, both when it came bundled with Final Cut Studio and now that you can buy it separately on the App Store. I've never liked the way Apple designed the UI, along with the fact that you have to fire up a different application to monitor compression progress. I've also found Compressor, or rather the background compressing engine, to be painfully slow, so I stopped using it.

I just fired up version 4.0.7 and inspected the HD for Apple Devices (10 Mbps) settings. It's nothing more than high bit-rate multi-pass h.264 encoding with audio at 128 Kbps (a bit anemic there).

You might find Handbrake gives better duration results. For me, it stomps all over Compressor and makes it its bitch. It's free, easily configured with presets and gives you the ability to fine-tune just about every conceivable compression parameter and save out new presets. Handbrake is my go-to compression engine for nearly everything. If it can't handle it, then the latest Adobe Media Encoder (you get it with Adobe Creative Cloud), can do it and is also extremely fast and very high quality.

About two-pass encoding... Back in the early days, when ripping a DVD and compressing it down to fit on a CD was all the rage, we would use two-pass to squeeze the movie down to be just under the CD max capacity yet retain an equal quality level throughout. This was back when the Sorenson codec was the premier choice and Media Cleaner Pro was the encoder. Nowadays the only delivery medium that chokes on a constant-quality encode (my preferred method) is online streaming. It will give you a better result faster than 2-pass encoding. Just set the RF to 20 in Handbrake and never again worry about the overall quality. Or go lower, to 19 or 18, if you are paranoid that 20 won't maintain enough detail. As always, run tests to see what works for you.

 

[CouponPages]

I've owned every version of Compressor, both when it came bundled with Final Cut Studio and now that you can buy it separately on the App Store. I've never liked the way Apple designed the UI, along with the fact that you have to fire up a different application to monitor compression progress. I've also found Compressor, or rather the background compressing engine, to be painfully slow, so I stopped using it.

I just fired up version 4.0.7 and inspected the HD for Apple Devices (10 Mbps) settings. It's nothing more than high bit-rate multi-pass h.264 encoding with audio at 128 Kbps (a bit anemic there).

You might find Handbrake gives better duration results. For me, it stomps all over Compressor and makes it its bitch. It's free, easily configured with presets and gives you the ability to fine-tune just about every conceivable compression parameter and save out new presets. Handbrake is my go-to compression engine for nearly everything. If it can't handle it, then the latest Adobe Media Encoder (you get it with Adobe Creative Cloud), can do it and is also extremely fast and very high quality.

About two-pass encoding... Back in the early days, when ripping a DVD and compressing it down to fit on a CD was all the rage, we would use two-pass to squeeze the movie down to be just under the CD max capacity yet retain an equal quality level throughout. This was back when the Sorenson codec was the premier choice and Media Cleaner Pro was the encoder. Nowadays the only delivery medium that chokes on a constant-quality encode (my preferred method) is online streaming. It will give you a better result faster than 2-pass encoding. Just set the RF to 20 in Handbrake and never again worry about the overall quality. Or go lower, to 19 or 18, if you are paranoid that 20 won't maintain enough detail. As always, run tests to see what works for you.

I no longer have Compressor 4.0.7, you should update to 4.1; the interface alone is worth doing the update.

In 4.1, the Apple Devices HD (best quality) is not multi-pass... Or single for that matter, nor is it 10kbs as I assumed by looking at the output files. It's apparently set to "automatic" on both of those critical settings, which means sometimes it's multi pass, sometimes single (which can use QuicksSync on i7s).

I just made a duplicate of the preset, then changed the automatic to multi-pass, and changed the bit rate from automatic to 10.

As I write this, my MacBook is has been running step 5. It just completed with a total time of 32:16... Waaaay slower than 3:37. Keep in mind, the source video is only 8 minutes, so I doubt I will use this setting for the stuff I produce.

That said, when I get a chance, I will re do the test on the Apple Store demo computer, using the same settings. It'll be interesting.

I just wish Apple put a video card in it that could also optimize compression... With all those teraflops... Still wondering if my D700 choice even matters.

 

[nathan43082]

I no longer have Compressor 4.0.7, you should update to 4.1; the interface alone is worth doing the update.

In 4.1, the Apple Devices HD (best quality) is not multi-pass... Or single for that matter, nor is it 10kbs as I assumed by looking at the output files. It's apparently set to "automatic" on both of those critical settings, which means sometimes it's multi pass, sometimes single (which can use QuicksSync on i7s).

I just made a duplicate of the preset, then changed the automatic to multi-pass, and changed the bit rate from automatic to 10.

As I write this, my MacBook is has been running step 5. It just completed with a total time of 32:16... Waaaay slower than 3:37. Keep in mind, the source video is only 8 minutes, so I doubt I will use this setting for the stuff I produce.

That said, when I get a chance, I will re do the test on the Apple Store demo computer, using the same settings. It'll be interesting.

I just wish Apple put a video card in it that could also optimize compression... With all those teraflops... Still wondering if my D700 choice even matters.

I have Compressor 4.1, but I downgraded from Mavericks back to Mountain Lion (long story), and it only supports 4.0.7. Here is what the preset shows inside 4.0.7 on my end:

10000 Kbps (10 Mbps) video , 128 Kbps audio, Multi-pass checked.

Again, have you tried Handbrake?

 

[CouponPages]

I have Compressor 4.1, but I downgraded from Mavericks back to Mountain Lion (long story), and it only supports 4.0.7. Here is what the preset shows inside 4.0.7 on my end:

10000 Kbps (10 Mbps) video , 128 Kbps audio, Multi-pass checked.

Again, have you tried Handbrake?

It looks like Apple changed the names of some of the presets. The one they now call (Best Quality) is what used to be 1080p for Apple Devices... This is a guess based upon the newer names and that they specify Apple TV Gen 3 for that one, and only Gen 2 for the one you saw.

Screenshot of 4.1 settings for Apple Devices HD (Best Quality)

I will try Handbrake and let you know what I discover. One thing I can say, no matter how much I try, I cannot see any difference between the one that rendered in 3:37 vs 32:16, other than the one that longer one is 30MB larger (600 mb vs 630 mb).

 

[CouponPages]

Again, have you tried Handbrake?

Just finished running my master through HandBrake. I used the "Normal" preset which is at your suggested RF=20.

The results were a bit of a mixed bag.

The time was 22:07, with an average frame rate of 11 fps. The odd thing was the file size and the bitrate in the result. I guess the bitrate is dynamic because from what I see Handbrake used the term "maximum" bitrate of 20, which I guess means it tries to figure out the best bitrate, based upon a target image quality.

As such, it created a file size of only 113 MB, as opposed to 600+ in the Compressor versions, and over 8GB in the master.

Once again, it's hard to tell any of them apart with the naked eye. Unfortunately, I have no way to benchmark Handbrake in the Apple store, so all that I can do is try the other Compressor preset changes and measure that.

I wish I had a 6-core / D700 to kick around. I'd have my answer. The people in the Apple Store think I should just take delivery and when in doubt, return it within 30 days if it doesn't do what I want.

It's crazy that they beefed up the graphics cards so much for engineering, 3D graphics and scientific buyers (I'm sure they have deeper pockets) but don't have an optimization for video editing. Say what you want about the older model, but one great thing was if you found a card that did something you didn't have, you could add it.

Maybe somebody can design a Thunderbolt video compression processor. There used to be a cheap USB dongle that did that before QuickSync came along. I'm sure down the road compression will speed up; I was hoping that the D700s would bring that reality to today.

 

[nathan43082]

In 4.1, the Apple Devices HD (best quality) is not multi-pass... Or single for that matter, nor is it 10kbs as I assumed by looking at the output files. It's apparently set to "automatic" on both of those critical settings, which means sometimes it's multi pass, sometimes single (which can use QuicksSync on i7s).

I just did a quick test comparing Compressor 4.0.7 (yes, you have 4.1, so results may vary) against Handbrake.

Computer
A temporary 2012 Mac Mini with 2.5Ghz 2-core (4 with HT) i5 that I am running temporarily until my new Mac Pro comes in. My old Mac Pro died (the long story).

Source
A 30 fps 1280x720 progressive video, exactly one minute long, that I rendered out of After Effects a few years ago. It's a bunch of 3D butterflies flying around in front of some stock footage. I made it when I was building this tutorial for VTC http://www.vtc.com/products/Adobe-After-Effects-6.5-Advanced-tutorials.htm.

Results in Compressor 4.0.7
I used the HD for Apple Devices (10 Mbps) preset unmodified
Encoding time was 2 minutes, 27 seconds
CPU utilization was 172%
Final bitrate is 9.38 Mbits/sec
Dropped my 30 fps source to 29.97 fps

Results in Handbrake 0.9.9
I used the Apple TV 3 preset unmodified
Encoding time was 1 minute, 2 seconds
CPU utilization was 390%
Final bitrate is 1.67 Mbits/sec
Maintained my 30 fps source as 30 fps

So faster encode and smaller file. However, the smaller file is of lower quality, which is to be expected on one level. There is an easy remedy for that, but let's take a look at just how bad. Interesting note: Compressor had shifted the frames off by one. I had to bump the encoded version by one frame to properly line-up the action. Dunno if this is because of the conversion to 29.97 or not.

Darker is good; lighter is bad. You can see the characteristics of the different approaches to quantization of data. On further experimentation, it looks like a Constant Quality setting of RF10 in Handbrake yields results similar in quality to what I am seeing with that particular preset in Compressor.

----------

Just finished running my master through HandBrake. I used the "Normal" preset which is at your suggested RF=20.

RF20 is a quantization setting, not a bit rate. What you are telling the transcoder to do is disregard bit rate, but instead always compress every frame and every GOP (group of pictures) using one compression setting. The bit rate will go up if there's action or detail and will go down if nothing much is happening.

RF20 is great for compressing movies for viewing on an Apple TV. In fact, to my eye, it's overkill and I usually drop down to RF22 or even RF23. However, if you want higher quality, quality that perhaps matches what you are seeing with that particular preset in Compressor, raise the RF to 10. You will get similarly large file results and the encoding should take little to no more actual time to complete.

----------

It's crazy that they beefed up the graphics cards so much for engineering, 3D graphics and scientific buyers (I'm sure they have deeper pockets) but don't have an optimization for video editing. Say what you want about the older model, but one great thing was if you found a card that did something you didn't have, you could add it.

I have a gut feeling that the Handbrake coders/contributors are salivating over the power of the D700s and are probably already figuring out a way to use them. They seem to be fanatical about performance, seeing as how they always fully saturate the CPU cores.

----------

As such, it created a file size of only 113 MB, as opposed to 600+ in the Compressor versions, and over 8GB in the master.

If you are compressing a source file that large, then the time it takes to get 8GB of data into the transcoder could become part of the problem. I was working off an SSD for my tests and with only a 360MB source file.

I should have asked from the very beginning, but what is the purpose of the compressed version of this video? Is it for archival purposes or for some sort of distribution. That will determine what bit rate or RF setting to use. Also, it will impact the audio bit rate you choose.

 

[CouponPages]

Truly fascinating. Thanks for the information.

What's really funny is that the gaps in sizes and speed can vary so much.

It comes down to pain points. I hate waiting for files to be exported. More often than not, I export a file, find something wrong, re-export it several times before I'm happy. Each time I do, the long waits drive me nuts.

I'm guessing I can overcome some of these problems with fast and dirty l rough-cuts, then only after I'm completely happy, batch them and have a sandwich. But my guess is I'll still find something, re-submit and have another sandwich.

If that were the case, I could batch them and run them at night and not care how long they take.

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.

I have a gut feeling that the Handbrake coders/contributors are salivating over the power of the D700s and are probably already figuring out a way to use them. They seem to be fanatical about performance, seeing as how they always fully saturate the CPU cores.

That would be a GAME CHANGER. I just did a Google search for HandBrake OpenCL, and came up with quite a few pages regarding an OpenCL version already in the works.

One is regarding a Windows beta of an OpenCL version of HandBrake https://trac.handbrake.fr/milestone/OpenCL%20Beta

From what I see, there are a lot of Betas... but nothing official just yet. This could be the missing link to make it all perfect.

If you are compressing a source file that large, then the time it takes to get 8GB of data into the transcoder could become part of the problem. I was working off an SSD for my tests and with only a 360MB source file.

I installed a 240 GB Corsair SSD in my MacBook and used that in my original test, which yielded a 3:15 result. I did this to somewhat level the field with the all SSD in the Mac Pro demo unit.

In subsequent tests, I moved the file external, simply because I needed the space. It added about 20 seconds to the total compression time.

 

[nathan43082]

Source
A 30 fps 1280x720 progressive video, exactly one minute long, that I rendered out of After Effects a few years ago. It's a bunch of 3D butterflies flying around in front of some stock footage. I made it when I was building this tutorial for VTC http://www.vtc.com/products/Adobe-After-Effects-6.5-Advanced-tutorials.htm.

I uploaded the results of my Handbrake RF14 encode to Youtube. Google's transcoding will destroy it a bit, but you at least get an idea of what you are looking at in those weird screen shots above.
http://youtu.be/PuS8md7hHos

 

[td2243]

I'm actually not as miffed by exporting times. I usually just go do something else and let it run. Obviously, faster speeds in that area are nice too. I want to see results while I'm actually editing. If I can't see smoother everything on that side of it, then I'd be really disappointed. Especially if I paid for the D700s and the D300s performed the same.

 

[nathan43082]

What's really funny is that the gaps in sizes and speed can vary so much.

This is what you'd expect to see when comparing a fixed bit rate encode to a fixed quality encode. My guess is that a good number of the bits in your fixed bit rate version are going to waste, attempting to preserve detail that either isn't there or is superfluous, at least some of the time.

When you use fixed-quality, the bit rate fluctuates with action and detail, but quality is consistent from start to finish. Of course, you cannot use fixed-quality if you want to deploy to the web, burn to DVD or Blu-Ray, but it's great for local streaming from iTunes to something like the Apple TV or for archival purposes (bumping up the quality setting accordingly).

There are videos online showing the whys and wherefors of each approach, like this one:

http://www.jwplayer.com/blog/transcoding-best-practices/

 

[CouponPages]

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.