I’m trying to figure out how to get real time playback without caching footage. Right now my Flame’s storage and the server where footage is kept are the same type of storage. But I still have to cache footage to get real time playback. So I’m trying to figure out if the issue is coming from the file format. In general I’m working with 16bit linear exrs.
1 Like
I think that is a choice you make at the project creation page @invisiblejam
Down in the Cache and Renders tab at the bottom.
Yeah. I always select uncompressed. So I’m not sure what that is.
Uncompressed is actually EXR w PIZ compression. It is terrible UX. Your source EXRs are probably 16bit EXR un-compressed which would have a much higher data load than if they were PIZ which is what “un-compressed” on Flame is, which explains the performance difference.
2 Likes
Ok thank you.
Yo! The ‘same type of storage’ may or may not be helpful/relevant. How are you connected to the server? Can ya have Ol’ McSeveney do you a iPerf3 between your Flame and server to get network throughput? Because likely that’d be the bottleneck. If you are on 10GB networking, then yeah you could not be able to playback 16bit EXRs at 2k/4k/5k. If its a cloud flame/cloud storage situation, typically the rule of thumb I’ve experienced is HD/2K/3.2K MAYBE 4k at 10bit is totally fine, but 16bit EXRs above 2k are likely a problem Also, are the EXRs compressed? If you are on 25GB or 40GB or fiber then its less likely the culprit. Also, anybody else using the network/server? All things to check with AMcS. Most of the big studios use/require caching.
I thought someone would ask me how it’s all connected. I’m not sure. I’ll ask Alan. I think we use zip scan line for our exrs.
1 Like
ZIP is slow, makes sense you can not get real time playback even in network is fast enough. Always use PIZ everywhere.
2 Likes
@ALan you’re a PIZ fan? You’ve had good experience? Im always caching but on someone else’s storage dime so I don’t have much experience in this world.
You sure uncompressed is 16bit EXR PIZ? Isnt this only when you select 16bit float? I think for non float things its real uncompressed pure RGB/10 or 12bit data (integer)
oh and if you cache EXRs they always get cached as EXR no matter what your cache settings are afaik.
EXR speed/compression depends on how the reader works, for flame itz PIZ for nuke its Zip 1 scanline… I use DWAA for most things because I am mad and I do not care 
Ok. I’ll try PIZ.
always PIZ
PIZ is the way… oohhhhmmm
So I am also a PIZ fan but I am less than confident about the ‘Preferred Format’ options.
It is a terrible user interface @ALan
I can’t be sure about the compression.
What I am reading makes me think that I could choose Apple ProRes 4444 (which I do) and any 16-bit file will be saved as an EXR.
To follow up on this I do get real time playback with PIZ exrs.
I also did some render time vs storage tests for 3 different files types. I tested the speed of 2 things: a 2d track of 1 clip (which is the most common thing I spend time waiting for) and then a full comp using 5 4k+ clips.
These are the results:
Cached (8bit tiffs):
2D track. 3min 42 sec
Render time. 10min 42 sec
Archive size. 1tb.
16bit PIZ EXR (soft import):
2D track. 7min 09 sec
Render time. 12 min 33 sec
Footage size. 168 gig
12bit Prores 4444 (soft import):
2D track. 7min 25 sec
Render time. 13 min 13 sec
Footage size. 109 gig
Oh. Your biggest wait times are for 2d tracks? Sounds like an underpowered cloud station?
I think the tracking might be connected to read time on the drive.
I think the most surprising number here is that 150 gigs of footage becomes 1tb in a flame archive without any extra renders or set ups.
That’s gotta be the best argument for working unmanaged ever.
1 Like
@ALan if someone decided to use exr dwa to save on space and xfers, what would be the net result? Shit playback and interaction everywhere? (Asking for a friend)