Welcome to our community

Be a part of something great, join today!

Log in
  • 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 :)

Slow 2k 2:1 renders, this is not upscaling

J

Joe Kocsis

Well-known member
Joined
Feb 10, 2009
Messages
93
Reaction score
0
Points
0
Location
Burbank, CA
Website
www.nooneuknow.com
So I'm rendering a bunch of footage today and when I hit some 2K 2:1 footage I notice the speed comes to a crawl. I've searched around and the supposed answer is that going from a 2048x1024 RAW to 1920x1080 ProRes image is upscaling and so thats why the rocket is not accelerating it..

umm... I dont think thats correct..

I'm maintaining my width and my aspect, so this is still a down scale with the addition of some letter boxing top and bottom..

So my question is, is this something that can and should be fixed? and perhaps is addressed in a newer beta? or am I misunderstanding the process here?
 
Are you going from 2048x1024 to 1920x1080 with a fit width or something else?
 
I ran some additional test today.. It seems that whenever the results horizontal image size is less than 1080 there a significant performance hit. Assuming because now the processors are doing the scaling.. This is an issue with 2K 2:1 natively since when fit hroizontal you end up with a letter box, and the original vertical source size is 1024.. less than 1080..

You can also replicate in a slightly different manner by using 2K 16:9.. Without a crop and a fit to width you get full RR accelleration.. Now use the crop function to create a letter box on your 1920x1080 output.. If you crop the source height so that the result is less than 1080.. no RR scaling.. set it to 1080 or higher you get RR scaling.. With Fit to Width the down scaling is always the same , however it seems the RCX makes some assumption based on the input size being less than 1080 that your upscaling or something of that nature.. I'd guess there's a line of code that assumes that if either x,y size of the input is less than x,y of the output that its an up scale.. which is obviously not always going to be the case.. anyhow..

tx.. for the quick responses and I hope this leads to a fix..
 
Last edited:
Joe Kocsis said:
I ran some additional test today.. It seems that whenever the results horizontal image size is less than 1080 there a significant performance hit. Assuming because now the processors are doing the scaling.. This is an issue with 2K 2:1 natively since when fit hroizontal you end up with a letter box, and the original vertical source size is 1024.. less than 1080..

You can also replicate in a slightly different manner by using 2K 16:9.. Without a crop and a fit to width you get full RR accelleration.. Now use the crop function to create a letter box on your 1920x1080 output.. If you crop the source height so that the result is less than 1080.. no RR scaling.. set it to 1080 or higher you get RR scaling.. With Fit to Width the down scaling is always the same , however it seems the RCX makes some assumption based on the input size being less than 1080 that your upscaling or something of that nature.. I'd guess there's a line of code that assumes that if either x,y size of the input is less than x,y of the output that its an up scale.. which is obviously not always going to be the case.. anyhow..

tx.. for the quick responses and I hope this leads to a fix..
Click to expand...

If I'm understanding correctly, if you're doing a crop from the 2k 2:1 and then the scale, the scale itself could be pushing it into an upscale situation.
We'd have to go through the math and check.
 
no thats not the case..

There are two situations which I describe above where RCX with RR slows.. Assuming because its no longer using RR to scale.. Neither results in up-scale.. Both are down-scale. Let me explain the math in detail..

1) Original file is 2K 2:1
Original File Res 2048x1024
No Cropping
Fit to width
The result is a Down-scale to
1920x960

2) Original File is 2K 16:9
Source is 2048x1152
crop only the height to any number below 1080. Let's arbitrarily pick 1000
Fit to width
Result is a DOWN-scale to
1920x937.5

In either case it's a Down-scale..

Technically the RR should be accelerating this.

So what's the issue?

My guess? (I've got about 30 years of Coding Experience)

Your coders solution to deciding whether we were doing a down-scale or up-scale is something like...

if (width_of_source < width_of_output) or (height_of_source < height_of_output) we are doing a down-scale and send the processing to CPU..

This, however, is not correct..

The fix is easy but it is also dependent on the type of fit we are doing..

In the CASE of probably the most common fit, "Fit to Width", the only relevant figure is the width value..

so for "Fit to Width"

if (width_of_source < width_of_output) we are up-scaling send to CPU otherwise send to RR for downres..

In both cases above width_of_source is greater than width_of_output and we are in fact down-scaling.

Hope that helps..
 
Joe Kocsis said:
1) Original file is 2K 2:1
Original File Res 2048x1024
No Cropping
Fit to width
The result is a Down-scale to
1920x960

2) Original File is 2K 16:9
Source is 2048x1152
crop only the height to any number below 1080. Let's arbitrarily pick 1000
Fit to width
Result is a DOWN-scale to
1920x937.5
Click to expand...

Thanks, that's clearer now.

The upscale/downscale cases for rocket have a few caveats so we'll have to trace through all the paths to see if we aren't landing in a corner case somehow.

I've got about 30 years of coding experience too but the RCX team regularly kicks my ass :)
 
I also ran a third test to verify the 1080 theory and be sure the letterboxing wasnt causing the slow down.. Cropped to height of 1090

2) Original File is 2K 16:9
Source is 2048x1152
crop only the height to any number above 1080. I chose 1090
Fit to width
Result is a DOWN-scale to
1920x1022

It was fully RR accelerated..
 
Joe please send a RCX log file of one of these exports that is going slower than expected to redcinex _at_ red dot com so we can see what is actually going on.
 
LOL! Ok I realize it's not quiet 30.. I started programming in basic on an Atari 800 in 1983.. Thinking about it and a quick google of the history and looking them up on ebay almost brings tears to my eye... I might have to buy one just to have in the house as an art piece..

Deanan said:
I've got about 30 years of coding experience too but the RCX team regularly kicks my ass :)
Click to expand...
 
Joe Kocsis said:
LOL! Ok I realize it's not quiet 30.. I started programming in basic on an Atari 800 in 1983.. Thinking about it and a quick google of the history and looking them up on ebay almost brings tears to my eye... I might have to buy one just to have in the house as an art piece..
Click to expand...

Mine was TRS80-III around 1980 and the Sinclair ZX81. :)
 
You must log in or register to reply here.
Back
Top