You can do that. Setup the filter, then open the story board view, and it shows you just the matches. Then you click on the one you want.
It is probably cheaper to just by a 48GB gpu than spending the time to try and figure out what is leaking Flame.
If itās a memory leak no amount of VRam saves you on a long timeline.
This is not like an ONNX thatās just hungry but has a stable need.
When I open the timeline it only use 20% VRam and then I can play it for 5-7K frames before it trips at a random place.
I do long form all day long, every day. Mostly BFX, some Batch, lots of TLFX. That being said, I donāt use Flame for a color-grading system. Our colorists do that in ResolveĀ® & Baselight. Iāve had two corrupt desktops in my entire career using Flame as an on-line/DI conform software. I tried ResolveĀ®. It does some things really well, but as I do a lot of things that require batch & TLFX, I just donāt see ResolveĀ® as a replacement for me.
I do cut my personal/home movies with it though! 
1 Like
interesting! do you access the storyboard view via the Effects tab? or is there a way to jump right into it from reels or timeline view? (hotkey editor tells me ALT+F1 or shift+F1 do it but i cannot get that to work)
So kind of. I think I got one detail wrong.
The filter works only for the storyboard reel, not the full storyboard that you can put in one of the viewers. If select a view pane (like the left where I would have the image schematic, and hit Shift+F1, I do get the full storyboard.
But now I remember from Grantās video, that the storyboard view is disabled when the filter is active. So if you use the filter, you get the results in the reel, and if you double click on one of them, it becomes the active effect clip, the master grade updates and you can grade it, and you can navigate via the HUD.
Without filter active, you can get the storyboard in the viewer (via Shfit+F1) and you can click on any clip and it becomes the active effects clip.
Itās a great transcoding app 
But, no I donāt use it as my main color app anymore.
2 Likes
First round with ADSK tech support.
The asked me to go into the setup utility, and change the target memory consumption to 80% for main and VRam. By default it was set to 45% and automatic. Weāll see if that does anything.
1 Like
Some more test observationsā¦
- Adjusting the memory parameters in setup didnāt make any difference. Still crashes
- Removing some Sapphire effects in a different timeline, didnāt change anything. Just to ensure weāre only using basic ADSK TL-FX anywhere in the project.
- Replacing all the image effects with a basic 3 selective image effect didnāt help. To ensure that using the primary grade, the 3DLUT, and the color_matrix matchbox isnāt the problem.
- Removing all the image effects in totality and leaving basic clip with just resize didnāt help.
- Looking into why there is a resize (because out of habit I created a 16fp timeline instead of making at 12bit timeline to match footage), and using a new timeline setup to match footage didnāt help either.
That leaves me with thereās something more basic leaking. This is three reels of 4K DCI ProRes4444 footage with combined TRT of 22min. Footage came out Premiere flatpass render.
Playing even just that back on the timeline causes the GPU memory to max out.
Hmm. Tomorrow is another day.
Sent crash logs to ADSK support.
Iām sorry I donāt have much to contribute on the specifics of this demon youāre fighting, but I can contribute by saying Iāve graded 3 feature length films in Flame and maybe 7 short films (~10-20mins) and I havenāt had crashing issues like what youāre describing. Iāve had a full 90 min sequence where every clip has Image timeline fx and they were able to render out successfully without having to break it up.
There are a ton of variables involved with every issue like this so I appreciate you documenting your journey here so we can try to understand the issue.
2 Likes
Getting some traction with support, but no answers yet.
In the meantime more testing and ruling things out.
I have a pretty good idea though why this project is on the edge, but others have had more luck.
I do work a lot on heavy short-form comp/beauty work. So I have a habit of setting up my projects with 16fp bit depth, same for the timelines.
I created two test projects from scratch and brought in just the footage, and then variations of the timeline.
Just the footage plays back without issues and with normal GPU memory stats (maybe 15% used).Having this long timeline scene cut into 300+ segments does tax the GPU memory (full red), but playback remains stable even with the image nodes present for the test project that I setup in 12bit rather than 16fp. Repeating this with a test project in 16fp pushes it over the edge.
I also tested committing 0 frame handles and other variations to rule these out.
This system has a broadcast monitor and a BMD output, which runs as HD, so there is extra work and an extra resize running in the background.
Still want to find the root cause of what is clearly a memory leak, as it builds up over time.
But in the short term, the conclusion is pretty obvious - when working on long form projects with just color, setup the project with 10bit or at most 12bit bit depth. And for this type of work that is obviously appropriate.
So for those who responded that they have done long-form work without problems, do you remember your timeline specs?
This project uses 4K DCI ProRes 4444 footage, and initially I had set my timeline to 4K DCI 16fp and hell to pay.
Iāve had more luck with a 4K DCI 12bit timeline, and a 10bit timeline would probably be better yet.
Things that come to mind
Have you tried putting your source clip into a new sequence of the deliverable format?
After the scene detect did you consolidate to 0 handles?
Has your framestore got plenty of space?
My gut feeling is that there is something up with the source clip. Maybe run it through media encoder to create a new file.
My last longform project was a similar scenario to yours. It was 150 minutes of a prores444 clip of about 1800 shots and an image node on every shot. Some bfx, Action nodes, neat video, a few ring in RED raw shots too.
Worked rock solid.
The only pain on this project was that it was boring as bat shit and the footage was crap.
3 Likes
Thanks @johnag!
Weāve narrowed it down, and tested most of your suggestions along the way.
Media on itās own plays fine. Media scene cut (with or without handles) in a 16fp timeline dies after 5 minutes. Itās linked media, so framestore doesnāt come into play. Iāve also ruled out the BMD card adding pressure.
Devs had me turn on some debug messages for the log and we just captured that. There were definitely some interesting tidbits in, but theyāll have more context what that means.
My suspicion is that itās an old code problem, but rarely gets triggered because I ended up with an odd combination of long, high segment count timeline in a high res, high bit-depth project. For the most part youāre either short and high bit depth, or youāre long and lower bit depth.
Weāll see where this goes. In the short term I know how to make the project work now, but also want to see this through so it gets fixed if possible.
All that said, enough of you confirmed that you worked long-form projects successfully and without stability problems. So Flame is totally capable of handling this in the bigger picture. No need to escape to Resolve (just say no!), and totally fine to keep this in a TL-FX workflow and not kill the baby with openclips and batches and other overhead meant for different workflows.
1 Like
The movie I did 18 months ago where I graded the whole thing with green TL Image fx had some problems with crok_beauty matchboxes in the Image node borking out and having to be rendered in chunks, but otherwise was pretty solid. Youāre doing the Lordās Work in getting to the bottom of this.
3 Likes
There definitely are issues with longform. I think flame relies on the GPU for output. As though it loads it into vram in order to push the file out. I know of a horror story from a time when I worked at Brickyard and we were working on a 7 hour commercial for US Cellular. We had to dump sections to tape and then reingest into resolve to get the file out.
flame is the best way to deal with multi-track, multi-version, timelines for finishing, bar none.
everything else is a cheap copy with caveats.
everyone is welcome to drop their $0.98 against.
donāt care - i have 1 penny in my left ear, and one penny in my right ear.
2 Likes
All color apps rely on GPU for finishing frames. Only way to get realtime playback for complex color grades.
In fact they process the frame in the GPU, bring it back so it be rendered but also to send it back out via the broadcast interface.
One difference between games and post is, with games the displays get fed right from the GPU, so all data flows one way. In post displays and rendering is back on the system, so data flows both ways.
Unless you need to master an IMF with Dolby Atmos or a DCP. And you donāt mind converting H265, DNG or several other codec sources
As you know @philm, I love Flame so this is mostly in jest.
2 Likes
Devs asked and received materials to reproduce and thereās a now a ticket to validate and find the memory leak. Will update if there are new developments.
Thank you all for the helpful context and constructive tips. It takes a village.
6 Likes
One thing that came to mind @allklier is what is your cache formats in your project setup? There are definitely tradeoffs between space consumed and processing overhead required with uncompressed versus compressed formats that may also be contributing to your downfall.
Not for nothing since a lot of us use compressed formats for 16bit cache, having to decompress a huge number of files continuously for minutes at a time may be a contributing factorā¦
Or maybe not. Just spitballing
2 Likes