R15b5 : Delivery Corruption of R3D

I have stumbled on Resolve settings that can play footage back in MEDIA, EDIT, FUSION and COLOUR tabs Correctly.

However - I can't find any combination of Resolve settings when Debayering is set at the highest level (ie FULL RES PREMIUM) that can DELIVER output without INTRODUCING corrupt frames at random intervals.

Attached are some examples:

AJ

To Try and minimise the FRAME CORRUPTION in DELIVERIES:

I have tried setting :
+) Use Display GPU for Compute = NO
+) Use Red Rocket for = None
+) Use GPU for RED Debayer = NO
+) GPU processing mode = OpenCL

I was hoping that if the Resolve 'GPU code' was deactivated - that this would not utilised the code causing the corruption -> BUT this did not work - Radom frames still get corruptions.

The Most useful aspect of not Using the GPU seems to be that DELIVERY seems less likely to crash when Noise Reduction is applied to long (30 sec) clips.

AJ

As this problem make be specific to the (relatively new) IPP2 workflow - here is a copy of the Colour Management setup.

AJ

Here is the Camera Raw Setting

Note : That during Playback - even with Noise Reduction activate - there is no Corruption with these settings.

Corrupt Horizontal & Vertical Lines only seems to happen in DELIVERY.

If anyone with 8K VV Monstro footage has found settings that increase the chance of No-Corruption please let me know (I have been trying diligently for 6 days without success).

AJ

After a tip from Adrian - I also attempted to see if changing:
+) Playback : Performance Mode or
+) Playback : Proxy mode
had any impact on Corruptions.

Settings that I have had the least RESOLVE CRASHES during delivery was:
PLAYBACK +) PROXY MODE = Quarter Resolution
PLAYBACK +) PERFORMANCE MODE = Active

I don't know why playback settings would effect the DELIVERY stability.
It is possible that I haven't got enough crash results for these settings to be statistically significant.

AJ

There's an option to set max render speed (measured in frames per sec) in the delivery video prefs. Change from the default (maximum) to something like 20 or 24 or 30 and see if that fixes it. Something tells me the fundamentally broken Mac Pro GPUs are losing it when they try to render faster than they can cool.

Caching.

Before DELIVERY:

+) Wipe OPTIMISED media
+) Wipe all Render Cache
+) Set Render Cache : None.

This was done to try and avoid any chance of the caching being involved in the Frame Corrupt to help BlackMagic zero in on the problem.

AJ

Michael,

Thankyou for your suggestion - I will investigate if Resolve is more stable when changing the output (frame rate) settings.

In my humble opinion - this looks like a coding bug to me. If I was to hazard a guess - the DEBAYER code is performing an OUTPUT = FN( X:0..N, Y:0..N) ... and need to be fixed to ( FN( X:1..N-1, Y:1..N-1). My guess is that as there is no video data to DEBAYER .. and it is (guess) NOT BEING DELETED before the calculation of the debayer ... then the TOP, RIGHT, LEFT and BOTTOM are all RANDOMLY getting junk.

Example of getting exactly the same issues in FUSION when the machine is COLD : viewtopic.php?f=32&t=75315#p417793
when I posted that thought (incorrectly) the problem was specific to FUSION.

I also note that there ARE other people with Windows reporting the same sort of error - but not necessarily with images to highlight the problem.

AJ

There's an option to set max render speed (measured in frames per sec) in the delivery video prefs. Change from the default (maximum) to something like 20 or 24 or 30 and see if that fixes it. Something tells me the fundamentally broken Mac Pro GPUs are losing it when they try to render faster than they can cool.

Trying again to find a way of DELIVERING timelines with Noise Reduction on R3D that DO NOT CRASH.

All suggestions welcome.

Last Delivery Crash log :
https://www.dropbox.com/s/98qfy8kmend57 ... 8.zip?dl=0

This DELIVERY made it 10% of the way through before Crashing.

SUGGESTION : Is there any way that Resolve can Break its BATCH PROCESSING into transacitonal chunks - and allowed the RESTART of an crashed render?

Eg create :
+) Main output file + Journal of next transactional part of the render.
+) Each time the next part (eg 5 secs of timeline is processed) Append this to the Main output file
+) Restarting of a DELIVERY render would then delete the Partial Journal file and restart the render from the last point.

It would definitely reduce the Frustration level (and might even help push past data induced Resolve Bugs)

AJ

I tried another line of attack to try and get a DELIVERY (of Footage that has NR and R3D clips) without RESOLVE Crashing.

TRYING TO USE BACKGROUND RENDERING TO GET PAST RESOLVE CRASHES
+) On this attempt - I changed the CACHING format to UNCOMPRESSED 16bit HDR
+) I set the Project to RENDER in the background after 1 sec
+) I set the delivery page to be ready to USE previously rendered footage (because this would hopefully be used in the DELIVERY process - which would hopefully reduce render time down to a minimum and therefore reduce the chance of a crash during delivery).
+) I would also Save the project every so often - as hopefully the Even if a CRASH occurs - you would be able to background render from where you left off.

What I found was:
+) At some point RESOLVE crashes (and as Always there is no Dialog or popup box to indicate why on startup)
+) Render cache is WIPED (which Surprised me as some clips had completed rendering in the background).

Here is a Crash log (During background rendering of R3D Footage with NR):
https://www.dropbox.com/s/t5bxartgjc03x ... 5.zip?dl=0

AJ

BM Team.

I have (after many attempts) managed to create a delivery of a PROJECT.

+) Frame corruptions : Total around 50 in a three minute Timeline
+) Delivery time was about 10 hours.
+) The FRAME corruptions occur at EXACTLY THE SAME FRAMES as my earlier delivery
+) The FRAME corruptions occur in EXACTLY the same places as my earlier delivery.

This means this is not GPU over heating issue - this is a DATA INDUCED frame Corruption caused by a CODING Error.

Is this something that you have been able to reproduce in your Lab?

Do you need help in reproducing this problem?

AJ