Memory leak in relation to the preview buffer

Issue #43 new
Former user created an issue

References to source information from a fork project that is attempting to find the root cause:

If you load a script->preview->close->preview->close, the memory will slowly goes up by 10MB without dropping. It wasn't noticeable until the use of preview filters, where you'll do preview-close actions much more often.

Source: https://forum.doom9.org/showpost.php?p=1920557&postcount=49

The memory usage goes up to the max cache size, if it was set in the script. Otherwise it feels like there is no garbage collection in VS, and everything is cached indefinitely.

Source: https://forum.doom9.org/showpost.php?p=1920581&postcount=50

I just tested it, I spammed the buttons until around 1.5G ram and the program crashed.

Source: https://forum.doom9.org/showpost.php?p=1920697&postcount=58

The RAM usage came from the frame cache. The program is caching two copies of a frame at a time. One copy would be convert to RGB for preview and the other copy for process like running benchmark and retrieving frame info. This led to unnecessary doubling of RAM usage during preview playback. As a result, a supposedly 600 MB of frame cache for a 1080 video was doubled to 1600 MB.

In comparison, the same 1080 video on Avspmod only uses 270 MB of RAM

Source: https://forum.doom9.org/showpost.php?p=1922237&postcount=122

and finally an apparent fix for this issue on the Fork:

Capping frame cache and frame ticket queue sizes, greatly reducing memory usage

The original version had the frame ticket queue and frame cache size set too big, I pretty much disabled them now. Though the memory usage is still a lot higher than Avspmod. For example, my 720x480 dvd source is using 48 MB on playback in avspmod while vseditor is using 105 MB. The original loading of the video is only 62 MB but then it raise as more frames were loaded and were capped at 105 MB. After going through all the codes looking for the cap, I finally realized that the frame caching actually came from vapoursynth, as running benchmark through vspipe results in about the same amount of memory usage.

Source: https://forum.doom9.org/showpost.php?p=1931108&postcount=150

I prefer using the original VapourSynth Editor over the fork because of multiple somewhat minor (but annoying) changes or bugs on the fork. So it would be great to have this fixed in the original too.

Comments (0)

  1. Log in to comment