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

[Joe Kocsis]

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?

[Deanan]

Are you going from 2048x1024 to 1920x1080 with a fit width or something else?

[Joe Kocsis]

yes 2048x1024 to 1920x1080 with fit width.. so it should be downscaling to
1920x960 and then adding letter box.. which is what I see in the results..

[Joe Kocsis]

Hey Deanan any update on your thoughts on this?

[Deanan]

Hey Deanan any update on your thoughts on this?

We'll try to replicate over here and see if we get the same thing.

[Joe Kocsis]

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..

[Deanan]

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..

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.

[Joe Kocsis]

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..

[Deanan]

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


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 :)

[Joe Kocsis]

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 Kocsis]

are you one of the coders?

[Matthew Yaeger]

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.

[Joe Kocsis]

log sent..

[Joe Kocsis]

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..



I've got about 30 years of coding experience too but the RCX team regularly kicks my ass :)

[Deanan]

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..

Mine was TRS80-III around 1980 and the Sinclair ZX81. :)

[Joe Kocsis]

TRS80.. LOL.. I forgot about Tandy. Good old Radio Shack...