What is your Shotcut version (see Help > About Shotcut)? Is it 32-bit?
21.12.21
Can you repeat the problem? If so, what are the steps?
(Please be specific and use the names as seen in Shotcut, preferably English. Include a screenshot or screen recording if you can. Also, you can attach logs from either View > Application Log or right-click a job and choose View Log.)
Itâs repeatable however I donât have any idea by what it might be caused (even in any approximate way).
The issue is that when editing my project, the longer I edit, the more memory it takes. Ex. I start with 25GB of memory free and after 30-45 min of editing I have only 1 GB of free memory. I could understand this if I make any big changes in the project, add many new clips etc. But it also happens when I do final project polishing so Iâm doing very small things, like adding somewhere just few filters, changing some texts in Simple Text filter etc. Nothing big and nothing which would justify that memory used by shotcut is constantly increasing in GB. Moreover even if I close my project (but when still keeping shotcut opened) the memory is not released. Thus I can have ex. 31 MB used (in that 2-3 GB are used by operating system). And nothing is released even after many seconds. Only closing and re-opening shotcut is releasing memory.
Have you observed anything similar? Do you have any suggestions by what it might be caused? Please note that it happens when editing the project, not when rendering the video.
Shotcut has an internal frame cache. When it is decoding video from disk, it saves a selection of those frames in memory (uncompressed), which will appear to quickly explode the computerâs memory usage.
The idea is that if youâre making small changes to an area of the timeline, youâre probably wanting to go frame-forward, compare, frame-back, compare, etc a lot of times while making keyframes or color adjustments. If Shotcut had to re-read and decompress those frames from disk every time, the preview would appear very sluggish. So Shotcut stores video frames in memory for rapid recall. It doesnât take many full-sized uncompressed frames to fill memory up.
Having said that, Iâm not used to seeing Shotcut push memory to only 1 GB being free. That seems extreme. The algorithm for âhow many frames to keep in memoryâ has changed multiple times over the years, so Iâm unable to say what normal behavior should be today.
If the problem was truly a leak, then in theory it should overrun that 1 GB boundary and crash itself. If it never actually crashes, then my guess is that everything is running as expected. The frame cache is simply being very aggressive about taking all the memory on your system to give you the highest preview performance.
Have you encountered any crashes as a result of 100% memory usage? There could still be a leak involved. Iâm just providing background on where that memory usage normally goes and giving some ideas for further testing.
Well, itâs more complicated I think. Sure I expected that memory size increase is probably caused by some caching. But I have doubts if around 25GB of caching is a good idea.
Concerning crashing, it happens that shotcut crashes sometimes when editing but probably for other reasons (Iâve already reported few bugs). However I believe it might be another problem. If after long editing I have ex. only 1 GB of free memory and then I run export to mp4 function then sometimes shotcut crashes during this export. Usually before export I close shotcut and re-run a fresh copy to make export. But if I forget and itâs after long editing, then it usually crashes. Iâm not sure how it works internally. Perhaps before export this internal cache should be released (or at least decreased).
I thought there had been some code changes in this area, particularly in regard to a project being closed. When I went searching the forum, I found an old post of mine saying basically the same thing you are. A leak is certainly possible.
In order to do anything about this, you need to state what causes it other than âusing it.â Otherwise, this is basically a bug report saying there is a bug and fix all of the bugs. It goes without saying that all of the bugs should be fixed, it should be as fast as possible, and it should use the least amount of memory possible. I have no doubt there are leaks, but that takes general usage with memory profiling tools similar to how general bug fixing requires general usage to find issues. As for me using it more, well, I already spend too much time looking at screens.
@Austin, Thanks for adding these thread. Yeah it looks like that itâs very similar/the same problem.
@shotcut, itâs really challenging to say what is causing it. I tried to check if ex. using any filters or any special operations are causing it but no idea. The only thing which is sure is that when closing the project, shotcut is not releasing its cache in any way. And I believe after closing it should release it. Another suggestion, perhaps this cache should be also release before export operation? How could I report this bug more precisely? What comes to my mind is to make video with system monitor showing that the memory taken by shotcut is increasing all the time ( mean two windows visible in the video: one shotcut, one system monitor). But does it bring any value?
The issue isnât proving a leak⌠we can all agree there are leaks. The challenge is figuring out exactly whatâs causing them.
The codebase is huge. Manually scanning source code isnât a productive option.
A better option is to use memory profilers or debuggers or other developer tools to figure out which actions cause the leak and enable a connection to be made to the relevant source code. Those tools are a little bit complicated to use.
A further complication is that Shotcut is built on top of many other libraries. Itâs possible the leak is in one of those libraries, which means the Shotcut program canât do anything about it. It would need to be fixed in the libraryâs code, which is maintained by somebody else.
Basically, without developer tools pointing to a specific leak and its correlating code, nobody knows what to do about it or where to start. The leak could literally be anywhere.
If there was a document in the FAQ or Wiki about âhow to run Shotcut with a debuggerâ geared towards a general audience, then maybe we could get more eyes contributing more precise reports.
A leak is certainly possible.