Cacheing/proxie and Red?

I am getting more and more rushes shot on 5kRed and i’m finding Flame is struggling to handle them without constant freezes and pauses. How are others working with such footage?

I am looking to install internal raid card and NVME to use as a framestore (currently its on external thunderbolt 2 raid along with the rushes). However, after that point i am confused what is seen as best practice.

Do i work on the raw files red files or do i convert them into another format? if so, what?

(I expect it depends what the delivery specs are - in my case that is usually Rec709 for HD broadcast, then multiple different versions for online content which i usually supply as H264. I maybe looking to supply 4k also but thats something i know nothing about yet.)

Is this what proxies are?

Are Proxies stored in the framestore or somewhere else?

what is caching? Often see people mention caching and soft/hard importing but i haven’t a clue what the differences are

Would i manually copy files onto the NVME before importing them into Flame?

apologies if this all seems a bit basic - i never worked in a facility, so have not had exposure to this kind of data handling. All my knowledge stems from prying my FCP7 experience into a Smoke then Flame workflow, and the file handling between the two is quite different. I have got by reasonably well so far, but as i no longer have to digitize into whatever format the NLE prefered and i’m faced with a myriad of file types and complexities, its probably time to revise my working practices. Any advice would be welcomed!

Hi Adam,

Great name!

A proxy file is a lower resolution and potentially compressed version of the original media. You can work in proxy mode to speed up performance when comping or potentially your framestore wasn’t fast enough to playback the high resolution media. You can work at proxy resolution but then render out your full resolution version.

Cache is storing a version of the media on your local system. In the case of Flame, when you cache source media it will transcode the media into the cache format chosen when you setup your project (in the project setup menu when creating a new project) and store it on your framestore. The beauty of the cache system is you can choose to cache the media at anytime by using the drop down menu in the Media Panel and choosing to cache. You can also do the reverse by deleting the cache which means Flame will then look at the original media instead of the locally cached file.

Soft import simply means that you look at the source media in its original location without doing any cache. Hard import means you are cacheing it onto your framestore.

1 Like

agreed - so few enjoy owning such a good name!

thanks again…i am starting to understand the variations, and can see the benefits of installing nvme ssd’s inside the mac now, and using that as the framestore.

The bit thats still slightly cloudy in my head is what to do with Red material. If i want to cache it, what format do i set the Project to cache as? theres quite a few options in the settings, but as i have only ever used a few flavours of ProRes and not used EXR/DPX/Prores Raw, i’m not sure how the raw Red would translate.

I usually just import into an Aces project with the media tagged, then export with a colour management on the top track of the timeline to ensure everything is coming out in the format i need (rec709). The problem comes with playing back and grading or manipulating that raw red material.

For RAW media, definitely select a media option that has exrs, especially if you are working on ACES. Flame will then cache (after debayering it) the red as 16bit float exr files which will maintain all the sensor information.

1 Like

brilliant - thank you!

Hi Adam, can you just clarify something… what is the Framestore?
is that the Autodesk Managed Media Folder? And if that folder is located on the same raid as the source media, is there any point in doing a hard import?


Yes, the Flame storage location which you select in setup.

The only benefit of cacheing media in this circumstance would be so the debayering is done. You’d be playing off exr files instead of the r3d RAW files. It would obviously take up more room on your RAID though.

1 Like

Thanks Adam…I figured that was the case!

Hi Adam,

sorry for revisiting this topic again, so long after we first had it…

The current project i’m working on has highlighted something that i hadn’t spotted before and i’m not sure if its something i have been doing wrong, or just misunderstanding.

I have my project set to cache files to my internal nvme raid. The cache settings are Apple ProRes 422 Proxy/EXR(PIZ)

Once i have imported the files and the caching has been done, they are still showing in the mediahub / conform tab as being BRAW files, not EXR’s, even though they are now showing the file location as the nvme drive rather than the source drive the rushes are stored on.
Is this the correct behaviour? I would have thought the files should be showing a filetype of EXR.

I’m baffled about exactly what formats i’m working with.


This behavior is correct. Flame is a managed framestore. Meaning, all of the under the hood caching behavior is done behind the scenes and never exposed to the user.

The original files are always untouched. The Media Hub will always show the original file you cache, not the resulting cached images which you never need to know about.


thanks Randy,
that helps clear up my confusion. At least until the next fog descends!

Hi Adam,

To expand on what Randy said, because you can uncache media as easily as you can cache it, Flame shows the media in the state it was imported in.

On a RAW format in particular, you can still access the RAW settings and adjust them on something like r3d or X-OCN even after being cached. I’d have to check the behaviour of Flame in such an event but I believe it would then need to recache.

So don’t think of cacheing as generating new media that Flame now takes to be the source media. The cache is simply a localised working copy of the original source medi that you can go back to at any stage.

Hope that makes a bit more sense?

1 Like

Thanks Adam, its all starting to get a bit more resolved in my mind!

1 Like