Mac Pro can apparently play back R3D's at Full debayer

[David Battistella]

Hm...
Read speeds should not really be such a bottleneck. R3Ds, even from Dragon is pretty lean compared to most things...

Yep, The debayering, decompression has been a bottleneck. Doing that on internal flash storage and doing it on external storage should be a bit different since that compression and decompression has to be read and calculated, so I'm just wondering if in practice it will be the same as having the files on internal flash storage or say, external USB3 5400rpm spinning disk media drive. Not sure the drives have the buffer to sustain the RT.

Jeff, was saying there were a few buffering issues too, like, things needed to be loaded into a cache, it's just whether every link in the chain can sustain the computing power that is required, read, write, display, compression, decompression, etc.

I'll be very surprised if we have to do away with Proxies, but very pleased if they were a thing of the past.

David

 

[paul schefz]

Got my hands on a new Mac Pro at the local Apple Store, played with it there. They invited in some of the local business customers to come see it and do a bit of shopping.

Works with Dragon 6K footage -- tried it tonight. Plays back 6K at 1/2 without a hitch on a 6-core 3.5GHz with 32GB and I think the GPUs were D500's. At least until it overruns the buffering -- have to let it spool up a bit before hitting play. Full res works, but stutters a bit and overruns the buffer, 32GB is not enough RAM if you think you want to work at 1/2 or larger res. FCPX wasn't liking the Dragon clips. It played 5K EPIC clips just fine at whatever the working resolution was. This is one impressive little computer. Silky smooth compared to my HP Z820 box that has 10 more cores... Could not try any Adobe software or other stuff. I'm surprised they let me install RC-X. And time was somewhat limited, there were a handful of others trying to get their hands on it as well, half of my observations came from some others playing with what I put on the system.

The one thing I can say about this system is this... I don't know what Apple did here, but the system has no internal bottlenecks or hangups. It just runs like a crazy fast sonofabitch. If they would've had a 6 or more core available to take home with D700 GPUs, I would've done it. They had no systems. They do have some coming in and expect to get them end of next week. All stock configurations, most 6-core, 16GB, D500 GPUs with 256GB SSD.

so i guess the question is what is more important for full quality: cpu speed or number of cores? i am only interested in playback quality not (so much) rendering speed....is the 6 core the better solution? the 2xD700 seem to be a no brainer (as well as larger SSD and 64 ram)....
i need to decide between the mac pro or rocketX (via TB) and my main goal is to be able to scrub through 6K raw footage 1/1 in rcx, davinci and fcpx....
obviously 2014 will be interesting with software upgrades and i guess it is hard to tell how much improvement we can expect with rcx and resolve now that these new mac pros are shipping?

 

[paul schefz]

Yep, The debayering, decompression has been a bottleneck. Doing that on internal flash storage and doing it on external storage should be a bit different since that compression and decompression has to be read and calculated, so I'm just wondering if in practice it will be the same as having the files on internal flash storage or say, external USB3 5400rpm spinning disk media drive. Not sure the drives have the buffer to sustain the RT.

Jeff, was saying there were a few buffering issues too, like, things needed to be loaded into a cache, it's just whether every link in the chain can sustain the computing power that is required, read, write, display, compression, decompression, etc.

I'll be very surprised if we have to do away with Proxies, but very pleased if they were a thing of the past.

David

i think you are thinking in extremes here...either the internal pcie SSD or a 5400rpm external....in reality a pegasus raid can easily handle the r/w and so can a portable 1TB SSD via TB so the storage really should not be an issue....i expect prices to fall even more this year and i would be surprised if we are even talking about "hard drives" anymore in 2015....it will be all SSD....
in reality working in fcpx with red raw is absolutely no problem now on imac or retina mbp....just check "better performance" and things should be smooth without proxies anyway....and final output is rendered from the raw file anyway....

 

[Patrick Tresch]

Regarding read speed, I guess that the computer reads as much data when full or 1/8 debayering is made. I don't think there is a directory that tells the debayering process to read only 1/8th of the wavelet data when 1/8 debayer is selected.
I mostly use 5k 2:1 1/8 compression and get RT in RCx with MBPr and Mypassport USB3 HD. I don't think HD speed is the bottleneck.

Pat

 

[jake blackstone]

Jake,

i can't remember where or when it was confirmed here by someone at Red, but i recall that selecting optimized and best performance meant 1/2 res on playback, but more importantly, full res on output, when creating a file. There might be a new RED apple driver to leverage all that computing power, but I think RED would have to write that.

accordingto Philips findings fcp x is doing a full debayer all the time at best/optimized and he would know, he's a well respected and trusted source.



David

Yes, I have no doubt, that the render in FCPX is a full debayer. The problem is every NLE has different nomenclature for playback debayer quality, such as Avid yellow/green indicators or Quality/Performance in FCPX. Frankly, if FCPX does even 1/2 debayer during editing, I'm ok with that. It's just the playback during the editing. What I really would like to know, if the actual rendering is in real time.

 

[Nils Ruinet]

....... What I really would like to know, if the actual rendering is in real time.

Indeed, I don't remember reading anything about render speeds in RCX an FCPX. Would be curious to know.
Also, has anybody tried Resolve on the new Mac Pro ?

 

[Gunleik Groven]

Regarding read speed, I guess that the computer reads as much data when full or 1/8 debayering is made. I don't think there is a directory that tells the debayering process to read only 1/8th of the wavelet data when 1/8 debayer is selected.
I mostly use 5k 2:1 1/8 compression and get RT in RCx with MBPr and Mypassport USB3 HD. I don't think HD speed is the bottleneck.

Pat

This is my basic understanding as well- Yet there are many refering to ultra fast raids being neccesary for reading. I can get that, if it is a large number of files that have to be read in sync, like for a composition, but for normal edits, even with 5 layers of video tossed on top of eachother. only one is read, as far as I can see.

Working with compositions does of course alter this perspective...

 

[Karim Ayari]

According to the Larry Jordan FCP X training, "Best Performance" plays back at 1/4 res.

 

[Paul Kalbach]

I have an 8-core on order and a colleague of mine has a 12-core on order as well. We're going to do some comparisons and I will probably order a second Mac Pro and will go with either the 8 or 12 core, depending on which one I think I need at that time. I was so conflicted between the two when they went live in the store, decided on the 8 for the 12% average boost in clock speed over the 12 while still providing 16 threads.

The 6-core today ran very nicely. It provides another 500MHz per core over the 8-core at their base clock rates and that makes a compelling option as well for many people.

One concern I have for the 12-core, more so than the lower clock speed, is the current maximum of 64GB. In most situations where I can truly utilize that many cores or threads (24 threads in all), it really helps to have 3 to 4 GB of RAM to allocate to each thread process. Especially so for serious rendering tasks or similar uses. This and the CPU speed in GHz is what steered me to the 8-core for my initial purchase.

I would be really interested in hearing the results of your 8/12 core comparison tests. I too was very conflicted, but went ahead and ordered a 12 core. If an 8 core actually gets better performance, I wouldn't mind saving some money as well!

 

[David Battistella]

@paul schefz,


it's great that RT performance has come a long way, but I am still not sure of the necessity of editing full resolution on long form productions. Ie: right now I've got many (12) tb's of r3d's across some raid drives. It's all going to be properly finished, Di, sound mix etc.


i guess maybe for for some quick turnaround stuff it's great to skip transcoding, but I'm just not sure it's gone in long form production.


ill have to see and test it for myself when I have it set up. I have always found it's not so much the read speeds but the compression/decompression bottleneck that has been there since the beginning, hence the RR card dedicated pretty much to this task for dallies creation etc., with GPU enabled in rcine we will have to see how the new mac (and RCX) leverages dual GPU +CPU computing power and then how other apps, pro, fcpx etc respond with the handoff through the sdk, etc.

none the less, exciting times.


battistella

 

[paul schefz]

@paul schefz,


it's great that RT performance has come a long way, but I am still not sure of the necessity of editing full resolution on long form productions. Ie: right now I've got many (12) tb's of r3d's across some raid drives. It's all going to be properly finished, Di, sound mix etc.


i guess maybe for for some quick turnaround stuff it's great to skip transcoding, but I'm just not sure it's gone in long form production.


ill have to see and test it for myself when I have it set up. I have always found it's not so much the read speeds but the compression/decompression bottleneck that has been there since the beginning, hence the RR card dedicated pretty much to this task for dallies creation etc., with GPU enabled in rcine we will have to see how the new mac (and RCX) leverages dual GPU +CPU computing power and then how other apps, pro, fcpx etc respond with the handoff through the sdk, etc.

none the less, exciting times.


battistella

agree....it is nice to discuss "problems" like these
i never work with long form productions so i really would not know, i should have clarified....

 

[David Battistella]

What I really would like to know, if the actual rendering is in real time.

Jake,

I know you are a wise man. . I'd actually like to know if the render is in RT as well. I have to say that in the offhollywood pieces did on a 2008 octo core, I was impressed at how quickly it rendered two minutes of 6k r3d at full debayer in the new FCP X. I can't say it was RT but faster than previous versions. We'll see how the new macpro fairs.

battistella

 

[Blair S. Paulsen]

Using the R3Ds as source media during editorial can be a terrific way to work. No transcoding time, no storage space taken up by offline transcodes, no conform step, etc. If your NLE can handle 1/4 res during playback and go to full res when parked on a frame (checking for focus buzzes, continuity, etc) without slowing the editor down - sign me up.

I won't rehash all the reasons that flipping R3Ds into widely supported RGB formats in the early stages of editorial is a superior choice for many pipelines - its been covered. That said, if the toolsets/hardware evolve to where you can utilize a wide variety of source material in its native format with no performance penalty...

Cheers - #19

 

[jake blackstone]

Using the R3Ds as source media during editorial can be a terrific way to work. No transcoding time, no storage space taken up by offline transcodes, no conform step, etc.
Cheers - #19

I don't see how using R3Ds for editing will eliminate conforming step, unless you propose grading from DPX or EXR. Using PPro and Speedgrade kinda does, but in it's ultimate wisdom, Adobe decided, that if one wanted to adjust the metadata, it could only be done in PPro and not in Speedgrade, which kinda defeats the wholele purpose of metadata.

 

[jake blackstone]

Jake,

I know you are a wise man. . I'd actually like to know if the render is in RT as well. I have to say that in the offhollywoodthere pieces did on a 2008 octocopter, I was impressed at how quickly it rendered two minutes of 6k r3d at full debayer in the new FCP X. I can't say it was RT but faster than previous versions. We'll see how the new macpro fairs.

battistella

Actually, it's not really necessary for real time rendering performance. I just would want better, than say, 6-8 fps, that you now can get with older CPU types.

 

[Neil Cronin]

Actually, it's not really necessary for real time rendering performance. I just would want better, than say, 6-8 fps, that you now can get with older CPU types.

FWIW, I am getting 24fps realtime playback of Final Cut Pro X 10.1 projects with Epic 5K footage on a 2012 Mac Pro with a GTX 570, barely taxing the CPU. "Best performance" of course, but it looks perfect on a 1080p panel.

-n

 

[jake blackstone]

FWIW, I am getting 24fps realtime playback of Final Cut Pro X 10.1 projects with Epic 5K footage on a 2012 Mac Pro with a GTX 570, barely taxing the CPU. "Best performance" of course, but it looks perfect on a 1080p panel.

-n

I'm asking about full debayer render speed, not 1/4. I was always able to do 1/4 debayer playback consistently, even on my 2009 MacPro. Unless Apple got the advanced GPU debayer SDK from RED, there is nothing particularly new about 1/4 debayer playback. Now, doing four 1/4 debayer streams at once, that's a different story.

 

[Johnny Friday]

FCPX wasn't liking the Dragon clips. It played 5K EPIC clips just fine at whatever the working resolution was.

Well, i'm editing a small 5min. piece -- Dragon 6k footage within FCPx on my 2009 dual 4 core with 32gb of ram....and stuttering is an issue until i let the timeline render...BUT, it's working....just making the whole post process take longer. I'm actually surprised i can do this...5k and 4k Epic footage works just fine.