Stuttering and memory leak, Is this normal?

So I’ve been using ShotCut for a few months and I’ve consistently had this issue and just worked through it. With some issues with the latest update [23.12.15] and had to revert [23.11.29]. I finally really dug into it and wondered IF MAYBE … it’s me that’s got something wrong.

I work on large files (2-3 hr 60fps gameplay captures) and when I play back, even just on an audio track for my voiceover. I notice the RAM while watching the task manager and it generally just stair steps up, but I notice the stutter happens right as it ticks up each time. Then eventually it maxes out and crashes.

I notice if I move a clip or change something it will reset the memory and start over, but tends to go faster as I keep doing this until I just have to restart ShotCut.

Let me see if I can get some image links here:
RAM Stair Step: Screenshot-2023-12-31-113147 hosted at ImgBB — ImgBB
RAM Reset after clip change: Screenshot-2023-12-31-113557 hosted at ImgBB — ImgBB

My setup: (Win11) [ShotCut v231129]
Intel Core i7 at4.2ghz
48GB RAM
RTX2080ti [MSI afterburner OC on the 2080 (it’s water cooled)]

  • 2nd card GTX1070ti running a 3rd monitor (No Shotcut window on that monitor)
    C:\ (OS) 500GB Crucial NVME
    V:\ (Video files and project files) 4TB USB 7200RPM disk
    S:\ (Proxy folder) 500GB Samsung 860 EVO SSD

I record the videos with Geforce Experience to the V:\ volume, then I create a project using ShotCut in that same volume. I load the clips and create proxies stored on the S:\ volume. Then save and restart the project and work exclusively with those proxies without preview scaling.

Is there a setting I’ve got wrong with my setup or something I’m missing here? Or is this just the way I should expect ShotCut to work?

I’m planning to upgrade my RAM to 64GB but I figure that 48GB is enough for almost anything. I’ve got 100GB free on the C drive but am planning to double that as well with a new NVME card.

Any help is greatly appreciated. Thanks!

Can you tell us more about your project? Video Mode? Number of tracks? Any filters/transitions? A screenshot of Shotcut can go a long way. Maybe there is a feature that you are using that is hungry for RAM.

What does “clip change” mean? Is it when you close a clip and open a new one? Or is it a transition from one clip to another clip on the timeline?

Sure,
currently 3x video tracks:

  1. one for top level overlay,
  2. second overlay, and then
  3. video track.

Then I have 3x audio tracks:

  1. a music one,
  2. VO1 and
  3. VO2 (since it keeps adding a track for some reason when I click the mic button).

On the main video track, I’ve got 4x video files (1600x900 60fps hevc) (~200GB total raw) and those are then converted to proxies (~20GB total proxies) which is what I’m currently working in proxy mode. There’s a lot of time lapsing (speed up) on the videos in clips and I do see a stutter there but that’s understandable when I’m moving at a faster speed. The other filters would be mostly audio gain and fade etc. The video mode is set to the for 1080p 60fps and the YT preset when exporting.

There is some PNGs with text that I’ve use the size and rotate on and one transparent webm file that I used for a title card that I created in ShotCut. There is some small video that I do alpha chroma key etc with and use the size and move filter on but that’s a small short file.

The clip change is probably wrong term but it’s where I split a clip and either cut something out or add a filter or something like that. There are a few transitions too.

That is helpful. If you are interested in spending some time to narrow down the source of the memory utilization, my suggestion would be to try to eliminate tracks and features until you see a difference. You can start by saving a COPY of your project. Then, delete tracks one at a time and test the memory between each deleted track. Or, start from the other end: open a single clip, convert to proxy, and then play the clip. How does the memory utilization look? That would be your baseline.

1 Like

Alright, This is what I did,

  1. Start a new project,
  2. move the proxy folder to a new folder on that same volume and then
  3. add one of the files into the playlist,
  4. build new proxies for that file,
  5. restart shotcut after the proxy for that file is built,
  6. add it into the timeline,
  7. drop in some random stuff for overlays and add some filters like the other plus more complex ones and
  8. repeat with the other 4 files, then
  9. see at what point I start to see a memory leak.

And you know what’s frustrating, is that I didn’t see any memory leak with doing this vs the old project file. There was a jump in memory when adding files but no stuttering or laddering usage etc while testing voiceover and playback. So I don’t know what the issue is with the old project file. It must be corrupted in some way.

I’m also pretty stuck as I’m multiple days into this project so I’d hate to cut it now. Since I did it sequentially, maybe I’ll cut my losses and just export what I have now, and then use that new file in a new project to finish the end. That might be my best option, unless there is a tool to do a full repair of an mlt file.

Well, not a complete loss if I can fix my issues here. I also played with some more filters and took some time to create some reusable content I can just drop in to save some time later while I was testing this.

Thanks for reading my story. HAHA!

And now the old file works! Insert [Jakie Chan confused meme] here. I did erase all the old proxy files and then replaced them with the new ones so maybe that was the issue all along, though I was pretty sure I’d already done that BUT from within the non working project, so maybe it just needed a new one to make fresh ones. Well I’m not complaining. :sweat_smile:

Try to split up your long videos into parts of 10-30 minutes videos and combine the part video projects in an master video with File->“Open MLT as Clip”.

You get the advantage of faster less RAM consuming editing because less thumbnails are loaded in the GUI-RAM and you are faster if you have to check parts in the exported video by part rendering.

1 Like

Oh? Interesting, I’ll have to look into doing this going forward. Thanks!