Simple Shape Mask tanking performance, lagging, and crashing?

It happens at the same rate no matter how I OC my RAM. I run 5.0GHz on my CPU with 16gb of ram for 1080p masking projects. 2-3 minutes of Mask keyframing, completely regardless of softness setting or any settings, real time mode off, crashes, probably without saving. Apparently it doesnt even have hardware acceleration? If you guys bring back the sliders (?) as an option then sliders would not tank performance?? I think I saw a video where some potato computer was not lagging with simple shape mask sliders in a tutorial. I think the only other hiccup Ive ever got from this app is separating audio from video gets sticky on selection as far as I can tell. I do like the keyframe “workflow” for the record and it’s only really laggy when its ready to crash

Thanks for your report and comments. There isn’t really enough information in your report for us to act on. It would be helpful for you to tell us what version of Shotcut you are using.

The next time you experience a crash, it would be good if you could send us the Shorcut log file. Here are some instructions that can help you find it. Be sure to get the file before re-starting Shotcut or the file will be over written and any crash information will be lost.

Also, for lagging, here are some features that might help you:

Wouldve been nice for you to mention that the log is stored at:
C:\Users#Your user Name#\AppData\Local\Meltytech\Shotcut
But it was not hard to find.

Anyways, I lasted a bit longer this time before crashing. I really cant do this project with proxies or preview scaling, but Im about 90% sure it was crashing even with them on. I can investigate that because the next project will be more important and I will be able to use proxies for it. Idk why its pretty blurry even with proxy and preview scaling off, but I can BARELY see what Im working on as it is, even though my exports are fine. Well anyways here’s the log, it was the only program running, thanks
shotcut-log.txt (1.2 MB)

Also, what is the deal with the grabbable box becoming disjointed from the actual mask? Its super handy when the thing Im masking is so small and it adds a lot of visibility but I dont think its supposed to do that because it seems really random when it does. I’ll call this issue 1. Im also getting issue 2, a lot of instances where the mask Im grabbing becomes disjointed from my mouse as I go to move it, where the mask and its grabbable box get locked in at that disjointed distance. I believe issue 1, the part about the grabbable portion being disjointed (semi-permanently) from the mask itself, happened briefly during that log session, and issue 2 where what Im actively grabbing becomes (suddenly and temporarily) disjointed from my mouse cursor happened a whole bunch of times. Issue 2 keeps the apparent grabbable box and the mask itself together but away from my mouse cursor, unlike issue 1
(I made sure my temps on CPU and RAM were good and I’m maxing out at like 75C on the CPU and 32C on my RAM)

shotcut-log2.txt (620.7 KB)
Idek what was happening at this point. As I pushed through the crashes and saved often, it got to a point where sooner and sooner it would… delete all my keyframes? Or delete most of them and then slide the rest of them down 10 seconds? At this point it’s just “too many keyframes” but I have about 10x as many in this log as I did when I first encountered problems and crashes with the simple shape mask. I hit the export button with the effect I was going for wearing out 95% through the sequence. It took laughably long to render, came out perfect though besides the fact that the effect wears off right before the bit wraps up. Kinda sad, but at this point I’m clearly reaching some sort of limit because it got to the point where it would crash from 0-10 additional keyframes every time, even after removing 5 old ones that werent necessary. I even tried dropping 100MHz on the RAM and adding .05v on my B-die, zero effect, if anything it would need more to the CPU but she’s getting pretty old and I question if she could handle the stress

Shotcut version 24.01.28
Edit: Updated to latest version, no change. It was actually laggier before it crashed, but I only tried once

I did not say that because I did not know what operating system you were using. That is why I provided the link.

Proxies and preview scaling typically don’t avoid crashes. They just help to reduce slowness/lag since there is less processing for Shotcut to do when the resolution is lower.

Unfortunately, this file does not provide any hints about why it crashed. Sometimes, before a crash, Shotcut will print an error message in the log. But not in this case.

This file also does not give any crash hints. In fact, it seems to indicate that Shotcut was closed properly by the user.

I would still encourage you to use the latest version if you can. That way, if you do experience a bug, we don’t question if it is a bug that has been fixed in a newer release.

My typical advice for this situation is:

  1. Make a COPY of your project file
  2. Store a way to ORIGINAL project file for safe keeping
  3. Install the latest version of Shotcut
  4. Open the COPY of the project file in the latest version
  5. If the latest version does not work for you, go back to the older Shotcut version and open the ORIGINAL project file.

I don’t have any other advice for you. But maybe someone else will have some ideas.

This could likely be a cause of the crashes. That turns on additional multi-threading–as explained in the FAQ (link at the top of this page and in web menu) and documentation. That can also be the source of lag since it ensures every video frame is shown regardless of how long it takes and “lag” = abnormal latency from things responding slowly.

Wouldve been nice for you to mention that the log is stored at:

It is in the FAQ. Also, the very first link shared with you explains app data directory contains the log and shows how to get to the folder in the Shotcut menu.

Or, just make sure you use File > Backup and Save when running a different version if you actually feel the need to save. Autosave in Shotcut does not overwrite your current project file on some timer. Rather, in the background, it periodically saves to a file in a special folder in app data.

It may be worth noting that I only ever saw Shotcut using up ~700MB RAM. It seems like it just needs more but that’s definitely just a guess. CPU usage seemed to sit pretty below 35% according to task manager. Also, the timeline with my keyframes on it flickers every time I go to add a new one, which I dont remember when working with keyframes not associated with a simple mask. In my second log, Im not 100% sure if it actually crashed or if it just wiped my keyframes and I exited, but in this 3rd one, it definitely wiped them out and then crashed very shortly after. Before I had a boatload of keyframes down, it would just crash. Now as I tried to push through the crashes, it does the deleting thing and/or crashes. I turned real-time mode on, didnt appear to make any discernible difference. Sad. Concerned about the more important project. Does Shotcut use AVX for anything?
shotcut-log3.txt (176.5 KB)