Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Premiere CS6 anything but smooth (6.0.1 made it worse!)

Found an 18-second long 5120x2160/23.976 clip and dropped it into Premiere, RR enabled... and the clip played very smoothly in both Source and Program monitors at 1/4 and 1/2 resolutions. This supports Wes' recent discovery.

I then exported the clip to DVD-compliant NTSC MPEG-2 (2-pass encode). The process took less than 15 seconds, i.e. faster than realtime (yay!). During export there wasn't much happening in the CPU (2-5% load only, most cores active) but at least the CPU was doing something throughout the export instead of only once in a long while. The main GPU (GTX580) worked at 4%, while the GUI GPU (GTX460) stayed at 0%.

Next test: export to Blu-ray compliant H.264 (2-pass encode at medium bitrate preset). For this test I slapped a Colorista II correction on the clip and added simple film dissolves on both ends. Export took 19 seconds. CPU usage leapt to 60-70% (all cores workout) and main GPU to 35%.
 
That's one nice thing about the Rocket. It leaves your CPU available for processing things like 3rd party / Non-CUDA effects, etc.
 
What was Wes's discovery? i missed that.....something about 16x9 material?
Yes. Premiere and RED Rocket stop talking to each other when Premiere is trying to process 16x9 material, such as 4800x2700 or 2880x1620.

The limited testing I've managed to do so far suggests this issue applies to editing (i.e. playback smoothness) and exporting alike. So if we're lucky, Adobe might squash both these bugs in one go. Fingers crossed.
 
Yes. Premiere and RED Rocket stop talking to each other when Premiere is trying to process 16x9 material, such as 4800x2700 or 2880x1620.

The limited testing I've managed to do so far suggests this issue applies to editing (i.e. playback smoothness) and exporting alike. So if we're lucky, Adobe might squash both these bugs in one go. Fingers crossed.

So would working with 2:1 material BUT then putting it on a 16:9 timeline with center crop create these problems ?

OR

Is it only working with the original content at 16:9 that is the problem?

thanks....
 
I haven't seen the issue when cropping from 2:1 to 16:9 but only with 5k 5HD native footage. I am just disabling my rocket for this particular project. Unfortunately I normally shoot at 2:1 but this current job I shot it at 5K HD. This was before I knew of this issue...
 
I haven't seen the issue when cropping from 2:1 to 16:9 but only with 5k 5HD native footage. I am just disabling my rocket for this particular project. Unfortunately I normally shoot at 2:1 but this current job I shot it at 5K HD. This was before I knew of this issue...

For this reason i've been shooting everything at 2:1 or 5kFF and then doing center crops from RCX...BUT, i've not yet tried any work on PrPro to see if any problems.
 
Yes. Premiere and RED Rocket stop talking to each other when Premiere is trying to process 16x9 material, such as 4800x2700 or 2880x1620.

The limited testing I've managed to do so far suggests this issue applies to editing (i.e. playback smoothness) and exporting alike. So if we're lucky, Adobe might squash both these bugs in one go. Fingers crossed.

Are these bugs still active? Can you confirm that this issue applies to both playback and exporting?
 
cant comment on export...

but I am running 5k HD (4800x2700) in a 1080p timeline with near realtime full rez playback via 1 red rocket....

Also running 1/2 and 1/4 via RR isnt going to help as the RR always does full quality debayer....
there have been times when my system is not actually using rocket (even when set to) and it appears that 1/2 and 1/4 are helping, when in fact it is using CPU.
 
cant comment on export...

but I am running 5k HD (4800x2700) in a 1080p timeline with near realtime full rez playback via 1 red rocket....

Also running 1/2 and 1/4 via RR isnt going to help as the RR always does full quality debayer....
there have been times when my system is not actually using rocket (even when set to) and it appears that 1/2 and 1/4 are helping, when in fact it is using CPU.

I'm pretty sure if you have a 1080 timeline it will be extracting 1080 from the 5k so it's effectively 1/2.5 res playback. I don't know for sure how it's extracting that, but probably doing a 1/2 debayer and then scaling...?

As far as running at 1/2 or 1/4 it does help in Pr. I believe the playback monitor controls for Pr while giving you the option of 1/2, 1/4, etc. do not it fact directly control the debayer of .r3d's as you can playback any type of footage at different resolutions. (anyone confirm this?)

The RR always decodes at full res but it does make a big difference if you playback at full or 1/2, 1/4 etc. at least with 5K, so I'm guessing this means the rocket can only handle 4k effectively so for smooth playback it does resort to 1/2 debayer or the bottleneck is what the computer can process after the RR has spit out the information.
Of course if the RR is only doing a full debayer and it can only do so at say 14fps or something, does that mean the CPU is filling in the rest of the job to achieve 24fps?

This is a lot of speculation and I would love to hear exactly what's going on from the guys who know!


I am still having RR issues when playing back 5k HD in Pr 6.0.2. via Magma chassis on rMBP.
 
I'm pretty sure if you have a 1080 timeline it will be extracting 1080 from the 5k so it's effectively 1/2.5 res playback. I don't know for sure how it's extracting that, but probably doing a 1/2 debayer and then scaling...?

As far as running at 1/2 or 1/4 it does help in Pr. I believe the playback monitor controls for Pr while giving you the option of 1/2, 1/4, etc. do not it fact directly control the debayer of .r3d's as you can playback any type of footage at different resolutions. (anyone confirm this?)

The RR always decodes at full res but it does make a big difference if you playback at full or 1/2, 1/4 etc. at least with 5K, so I'm guessing this means the rocket can only handle 4k effectively so for smooth playback it does resort to 1/2 debayer or the bottleneck is what the computer can process after the RR has spit out the information.
Of course if the RR is only doing a full debayer and it can only do so at say 14fps or something, does that mean the CPU is filling in the rest of the job to achieve 24fps?

This is a lot of speculation and I would love to hear exactly what's going on from the guys who know!


I am still having RR issues when playing back 5k HD in Pr 6.0.2. via Magma chassis on rMBP.

well the rocket always does full debayer...so even it a 1080p timeline...it's a full debayer...
I am not sure how the "extracted 1080 from the 5k" rumour started...but I have never seen anything to support this in adobe docs...I have heard that alot mind you....but never from an official source
somebody suggested that is the case with maximum render quality...but as far as the adobe literature goes...it only affects scaling algorithm used....and with CUDA the scaling is always the same algorithm whether checked or not

and the CPU does not help debayer at all when RR is enabled...as they are 2 different algorithms...so you would have one frame with the sharper RR look ,and the next frame with the softer CPU debayer look

so if you are using rocket...even in a 640x480 timeline you are doing a full debayer via RR
if you run the 1/2 1/4 options it will scale the full debayer down to help playback

in my tests with RR enabled it will do full 5k playback at near 24 frames(probably 20)...realtime but with lots of dropped frames...
when switching to 1/2 1/4 it will not playback at all...with rocket enabled...or like 2 frames a second...


if I go into source settings and disable rocket...then i can get smooth playback at 1/2 and 1/4....

your issue may be the thunderbolt interface....
my rocket is running internally on 8x pcie 2.0...meaning 4000MB/sec transfer....

while on thunderbolt...the maximum single channel bandwidth is 1250MB/sec...equal to 2 1/2 lanes PCIe
and that is maximum theoretical bandwith....probably cant hit that in reality

not saying that is the issue...but something to take into account...and I would bet there is differences from PP on mac to win, in the internals at least
 
I'm really glad to know others are experiencing this issue. Hopefully Adobe works this out. I always shoot 5K16x9 and the rocket won't work with that source in CS6. Redcine works great
 
Back
Top