Why Renders so slow?

I’m struggling to understand why rendering an 8 minute video is taking my Flame 2024.2 nearly 6 hours!

I rarely do greenscreen stuff so i don’t really know what to expect performance wise from Flame.

I’m on a 2020 MacPro (3,2ghz, 16core, 32gb Pro VegaII, 224gb ram). I have cached my rushes to an internal nvme raid. The rushes are shot on Blackmagic Raw, in rec 709 colour space, at 4096x2160 rez.

Most shots have some greenscreen keying, which is fairly straightforward and is being handled by a single MasterKey node. The background image is a single 1920x1080 tiff image. Some basic grading and a bit of stabilize on a couple of the shots, and i’m using a 1920x1080 timeline.

Flame is taking approx 1.5s per frame to render - is this correct? 6 hours to render 8 minutes? seems like something is not right, so any helpful suggestions would be very welcome.


That does sound unusually slow. Have you tried a system reboot then rerender just in case there is some kind of memory leak or some other process slowing your system down.

I haven’t worked with Blackmagic RAW before but potentially it is CPU debayering which would slow it down. Can you get real-time playback of the camera RAW? RAW is RAW so you must be debayering into Rec709. You may want to check that you are not debayering at a crazy resolution.

Other things to check. Your render resolution. Your bit depth of the render. Are your nodes working in 32bit float as opposed to 16bit?

1 Like

Do you restart flame before of render? Despite the promised improvements in graphics performance for version 2024, I have noticed that this version is extremely sensitive to vram overflow and each new version is more and more demanding of vram. So since version 2024 I have noticed how a graphics card with full vram significantly slows down the render time. So, I have made it a habit to restart flame before each big or demandant render.

1 Like

Any luck?
I’m wondering if Flame is processing everything at 32bit or higher. Do you have Neat Video in your setup? I have seen the output of that to greatly increase the bit depth compared to the input so worth checking.
Good luck!

1 Like

no luck!

the nodes are not 32bit.

Restart Flame - no difference to render time.

Tried setting some of the clips to use GPU for debayer and thats made no difference. Debayer is set to Full resolution, so tried half resolution but that screwed up all the comps as the clips were suddenly half the size.

Whatever i try, it still looks like 5-6 hours of rendering.

edit - I don’t have Neat video

i do have a Denoise on each clip - so i tried to see if i could create a bfx with the clip, and the denoise then render those before adding all the keying/ghrading etc…but it refused to render the bfx (called it a decoy denoise! whatever that means), and when i tried to render the timeline, i now get the spinning beach ball.

I had to force quit Flame, so won’t be trying that again.

1 Like

It’s the Denoise.


Agree, having a live denoise in the tree brings everything to a grinding halt. I find it best to put a render node behind denoise, and then bring that back in for the rest of the tree. Especially since there’s no need to refresh that ever, since it’s only source footage.

[edit: just saw that you mention you’re using something other than Neat for denoise, take away may still apply though. And Neat in an OFX will always return a 32fp pipe, so you need to put a reformat after it to get it back to 16fp.]

thanks for all the help Chaps…

turns out i will not be using Denoise again. Having removed it from each clip, my render is now fluctuating between 30 mins and 80 mins. Much more manageable than the earlier madness.


Definitely worth pre-rendering any denoise. I wouldn’t remove it entirely though, you can just bake it in. I generally will right click on the denoise node (I use Neat but same goes for denoise) and select create BFX clip. Once it has created the new clip I just right click that and render it.

Can be worth writing out as suggested above too, but that is entirely up to you as essentially the BFX clip is doing the same thing.

Sometimes you just have to denoise to pull a decent key, especially when dealing with blue screen.


I tried exactly that…crashed Flame!

1 Like

I personally prefer using render nodes, pre-rendering clips into the schematic, over BFX clips.

You can set a group of multiple render nodes to pre-render at the same time in the render list, you can set frame ranges to render, and generally I’ve just had stability problems with BFX clips at times so I just bailed.


Precomp denoise and gMasks.
Will make huge diff as mentioned above.

Do you find that with just legacy gmask or also tracer?

Both. GMasks and gmask tracers both add up quickly w the amount of shapes.

When doing minor tweaks at delivery, I commonly have all masks precomped to turn around changes in a few minutes.

my lifehack is to denoise everything ahead of time, I use nuke for that and throw it on my render farm.

every shot I ingest goes through nuke for pushing out plates and denoised plates and all else i need.

Call me crazy but having quick access to DN plates for every shot is gold.


Install Burn on there and use Flame to render on farm.


thanks for all the advice.

will definitely have to try some of these tips out.

no metadata no fun :wink:

1 Like

Any easy way to keep the batch tidy & readable, yet avoid the apparent pitfalls of BFX, is to just group it…



No risk, and still readable…

And retains access to the original if you do stolen grain workflow

(resize is just for the 32ftp → 16fp conversion)