Choppy Video Playback on Hard Committed Timeline and Rendered Media

Hey all,
Posted a similar question over in the autodesk flame forum. Having an interesting issue on a new, nonstandard flame setup (don’t judge me!) :slight_smile:
I can’t get hard committed timelines or cached footage to playback at speed. It is always incredibly choppy. Meanwhile, simply playing back the footage from the hard drive is silky smooth. It is odd because the situation has always been the other way around for me on standard Flames. The footage is zip1, 4608x3164, aces2065-1 exrs, and the timeline is a 30 second 1920x1080, 16 bit timeline. The storage is an 8 tb D7-P5520 server grade storage drive, u2 format, directly plugged into a pcie16 lane on the motherboard.
The debug toolkit is indicating Video GFX drops at an alarming rate for the cached footage, not so on the uncached read from disk. I can playback the entire timeline without lag with uncached footage, cant get past 1 second with cached.
Any thoughts on this? Flame must be driving the read setup from its Framestore in a way that is not friendly with my hardware, but I can’t think of how to solve this–the framestore and the uncached files are housed on the same drive btw, though I have discreet storage setup as directed for the framestore itself. New to this Flame configuration stuff!

1 Like

YO. Nice to see you here JK.

Hmm. Non-standard is always uncharted territory.

What OS?

What’s the internal cache format for the project? I can imagine that there are definitely some cache formats in the setup that could cause your playback to exceed the bandwidth required for source.

The analogy being 4k ProRes that plays fine over the nextwork but the same as 12bit dpx cache would crush bandwidth.

I judge you!

Do a Flame Fish > Preferences > Storage > Test Disks

I just got a OWC Mercury Pro 2x U.2 RAID on TB3 and I get only 130MB/s. Thats crap. The Flame at work w 8x SSDs in a RAID10 gets 3850MB/s. Mayyybe U.2 wasnt the way to go for either of us. I might look at selling the U.2 drives and getting these sleds that hold 4xM.2s to create a U.2, I believe that is how OWC got 2800MB/s using the Mercury Pro.

Hey you three-- Kieran and Randy watttup! And nice to emeet you Christopher! I’m on Rocky Linux. Running Flame 2023. Randy I used your video to actually do the flame conformed linux install btw --worked like a charm :). Because the setup is nonstandard we brought in Tom Gentry at Gunpowder to help me get Flame itself up and running. Never would’ve gotten this far myself that’s for sure. @cnoellert the cache format is uncompressed raw at the moment–pretty heavy I would think lolz. Is there an alternative that would work better?
Btw just as an update, after a reboot of the operating system, the uncached files do NOT immediately play at speed. I was wrong. It takes a a couple play throughs and then it plays back smoothly. This tells me this is a ram cache then. The hardcommitted timeline issue remains, the timelines literally NEVER play at speed, no matter what I do. Still stumped.
@knhn I did that test by the way–sequential frame read is coming in at: 358 fps 000.00 spf 4257.36 MBps. 130 MB/s over a raid is nowhere near what you should be getting with those u/2s… You got an extra pcie slot on your motherboard? —you can just attach one of those u.2s there and get the same bandwidth as your gpus-nothing will be faster not even thunderbolt.

Update @cnoellert I changed the cache format to 422 and its flying!!!–any media caches are now flying with playback :). I do feel a bit ignorant here though, what exactly is this cache file doing? Is it just a viewport proxy that flame is storing in place of the actual exr clip? That way it vastly accelerates playback, but when you export footage you still retain that original timeline bit depth and resolution?

Awesome. That’s what I figured it was. The cache format is the intermediate file format that all renders are rendered to.

The manual describes it as follows →

The Cache and Renders sets the formats used by the application to write media to the managed storage, for example when:

  • Caching media. On demand (contextual menu > Media) or on import (MediaHub > General > Clip Options).
  • Rendering a Timeline FX, a clip using a Tools module, or when using a Render node in Batch or Batch FX.
  • Creating virtual media such as coloured frames.
  • Creating proxies. On demand (contextual menu > Media) or on import (MediaHub > General > Clip Options).

You can read more yourself here →

That being said, your cache format arguably depends on your tasks, workflow and pipeline. For me, in commercial production and working largely within an openEXR publishing workflow with 10 or 16bit timelines, I opt for Apple ProRes 4444/ EXR(PIZ) as my cache settings. That covers me just fine, but different strokes for different folks.

So helpful @cnoellert. thank you. Gonna read that documentation as well :).

1 Like

OT - but to follow up on my slow U.2 experience for if anyone searches in the future. Changed the cache format from 4444/EXR PIZ to Legacy, now getting 800MB/s. This is on a MBA that I just tinker at home with, so I suspect it doesnt have the horsepower for PIZ compression.

PIZ is quite taxing.