Upgrade to latest ShotCut Kills Memory

[khastings256]

In RE to 22.12.21:

Hello. Love the App!!! Having a general app issue with the latest version where once I open a project the memory utilization begins to climb to a point where the app is soon unusable and unstable. It doesn't crash, but just clicking on something takes minutes.

Rolled back to the previous version and not having the issue.

Windows 11 OS: Version 10.0.22623 Build 22623 SurfaceBook Pro 2 16gb RAM

[bmatherly]

Thanks for your report. We will need more information to narrow down your problem.

For my tests, I created a simple project with a single clip on the timeline. For this simple test, I do not see a memory leak with 22.12.21 and in fact, it uses less memory than 22.11.25.

I have another test project that leaks memory in both 22.12.21 and 22.11.25.

To help narrow the problem for your project, can you try to make a minimum project that demonstrates the memory leak?

[ddennedy]

I did not reproduce it either while testing builds for release. No beta tester reported a problem either.

[ddennedy]

I do not think it is related to the Shotcut version. See the related forum thread.

[ddennedy]

Does the problem occur if you make a new project (dummy project for test) or only when editing your existing project? If the problem is specific to your project, maybe you can find some certain steps or some combination of things that triggers it.

[CamSoper]

Also experiencing severe slowdowns in Shotcut 22.12.21 on Windows 11. Feels like it's UI thread blocking. Perhaps something with Qt? Let me know if I can run a profiler for you.

Device name I-Am-No-Jedi
Processor   11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz   3.30 GHz
Installed RAM   32.0 GB (31.8 GB usable)
System type 64-bit operating system, x64-based processor
Pen and touch   Pen and touch support with 10 touch points

Edition Windows 11 Enterprise
Version 22H2
Installed on    ‎1/‎5/‎2023
OS build    22621.1105
Experience  Windows Feature Experience Pack 1000.22638.1000.0

[bmatherly]

Also experiencing severe slowdowns

@CamSoper, Can you confirm that your slowdowns are caused by memory consumption? If not, maybe you have a different issue than @khastings256.

[CamSoper]

@bmatherly Not conclusively, no, but on loading my ~8 minute 1080p project, the performance is snappy and the memory consumption is around ~700 MB. After just moving the playback head a couple of times, the memory usage is over 1 GB and it's definitely getting slower. After a period of editing, the memory footprint is up over 8 GB and every single menu click is... a... wait...

I'm totally willing to believe it's not memory-related, but when I came to look at what issues were already existing, this seemed like the most likely to be related. LMK if you'd like me to open a separate issue. Also, I don't have any idea what type of info I can capture for you that might be useful, but I'm completely willing. Please let me know if I can help!

[CamSoper]

It might also be relevant that my device is a Surface Laptop Studio (I'm a Microsoft employee). @khastings256 is using a Surface Book.

[ddennedy]

previous version

Which one? How about you @CamSoper does a previous version work better?

Regarding a profiler, this Windows app is based on a mingw64 runtime and not built with full symbols and profile options. It is typical that memory usage grows quickly. Then, after several clips it flattens out and then continually gradually increases while editing. It depends heavily on the number of tracks and the resolution. When things are getting very slow, it is important to know about the amount of system free memory and whether the OS is swapping memory. If it using 8 GB and 8 GB is still free then it is very unlikely a memory issue. With that said, Shotcut has a low free memory watcher and displays a warning dialog when it gets very low. You usually don't need a fancy profiler to understand more about whether memory is the issue. However, if you know about a profiler that can pinpoint a UI latency or GPU usage issue without much build changes, that would be good to know. With that said, major changes are also underway that kind of makes the exercise a kind of moot point. We are upgrading the Qt library to a major new version and using Direct3D directly instead of going through OpenGL.

[CamSoper]

@ddennedy Good to know.

I reverted to 22.10.22 and got the same behavior. As you say, it's likely a moot point with the upgrades you're making so I'll just cool my heels for now and make do.

[CamSoper]

@ddennedy @bmatherly FWIW, the current alpha build with Qt 6 seems to fix the issue for me. Much snappier, no apparent UI blocking.

[ddennedy]

Thank you for the feedback! Especially glad to get positive feedback about that as we are hoping the changes improves compatibility performance. Our beta is coming on April 2. Please keep an eye out on our GitHub Releases, home page, or Twitter.

[Yamakuzure]

I am currently trying to render an 8 minutes video. (218 clips, one flac) and ask myself whether this is normal:

 ~ # ps xfa | grep /usr/bin/shotcut | grep -v grep | cut -d ' ' -f 1
27371
 ~ # pstree 27371 -p -a -u -A | gawk 'BEGIN{FS=","}{print $2}' | cut -f1 -d " " | sort -u | wc -l
4101

4,101 threads? Is this normal?

(It also managed to make my Laptop swap. I have 64GB Ram.)

(Edit) Rendering is at 30%

 ~ # pstree 27371 -p -a -u -A | gawk 'BEGIN{FS=","}{print $2}' | cut -f1 -d " " | sort -u | wc -l
5258
~ # ps xfa | grep /usr/bin/melt-7 | grep -v grep | cut -d ' ' -f 1
31070
 ~ # pstree 31070 -p -a -u -A | gawk 'BEGIN{FS=","}{print $2}' | cut -f1 -d " " | sort -u | wc -l
1436

I wonder why (and what for???) they spawn 6694 threads together?

[ddennedy]

There is no global thread pool for FFmpeg unfortunately. Every clip gets a decoder with number of threads = cpu count. Every filter that uses FFmpeg libavfilter and supports sliced image processing is the same. Clips are cached to prevent over-utilization of resources, but the cache size is dependent upon the number of tracks. MLT native and frei0r effects share a thread pool except in the rare case one of them is using OpenMP (e.g. 360 video filters). Stabilization also uses OpenMP. I am not an OpenMP expert, and I read that it has a thread pool, but it's pool will be separate from the MLT image slice pool. There are other management threads beyond obviously the encoder, which is often 1.5x#cpus. Finally, the parallel processing option in export adds up to 5 more threads for frame threading. If you want to know more you need to study the source. But I think your comment @Yamakuzure is not directly related to the original post. All of the above is only about MLT. When you consider MLT inside Shotcut obviously there are more threads that Qt creates too. Plus if you use mesa+llvmpipe for OpenGL, it has a threaded fragment shader equal to cpu count.

More user oriented info here: https://forum.shotcut.org/t/how-to-reduce-memory-usage/27814

[Yamakuzure]

But I think your comment @Yamakuzure is not directly related to the original post.

I think you are right. What I have seems to be an MLT issue. This was at 60% rendering, before I stopped the job.

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
14968 sed       23   3  100,8g  50,2g 722056 S  1088  80,5 134:36.87 melt-7

I will downgrade mlt to 7.12.0 and try again. Sorry for the noise!

Edit : Some Shotcut problem actually does exist, that might be related to OPs report: I have downgraded to Shotcut-22.09.23 with MLT-7.12.0 and then my project from above took about 2 seconds to load. With Shotcut-22.12.21 with MLT-7.14.0 it needs about 5 minutes or so. But the real deal is the render project. I always have an extra "render" project, which has my projects MLT file in the playlist and on the timeline as the only object. This way I can put some effects on everything, like deband or 2-pass-filter. (!!) The old Shotcut just loaded that project in about 5 seconds. The current one needs almost 15 minutes. It has also spawned less threads. Whatever that means.

Edit 2 : For consistency and completeness' sake. Stats of the same rendering at 62% with the old shotcut+mlt:

Threads: 714 (shotcut)+ 523 (mlt) = 1237 (instead of almost 7000) Ram:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
23266 sed       23   3   38,0g   9,0g 833456 S  1138  14,4 123:38.82 melt-7

Big difference I daresay

final note : Yes, mlt issue. No problems with shotcut-22.12.21 with mlt-7.12.0. Sorry for highjacking this issue