#199 Very big memory usage !!!

Ian Brabham
Internals (76)


Here the problem :
First, i must say that the problem occurs only
with video encoded with lagarith codec in YV12 mode.
The problem doesn't occur with video encoded with
lagarith codec in other mode (YUY2), and it neither
occurs with other video encoded in YV12 (DivX, H264).
Even if i found sometime the memory used a little high.

I've already notify this problem to the person
doing the lagarith codec, but it's hard to say which
is responsible. I suggest you get in touch with him
to see where the problem lies.

My PC : Dual core (note core2duo) with 2Go of
mermory under Windows XP SP3.

When i open an avisynth script under virtual dub,
with the only command inside is :
if the avi file is encoded with lagarith codec in
YV12 mode, the memory used go up until around 900Mo !!!!
This occur with V2.5.8 RC2 and RC3.
I've tested with V2.5.7, the memory used go up
(only... ^_^) to around 450Mo...
Opening directly the file in VDub, not using an
avisynth script, memory used is only 45Mo.
You must have a long enough file to reproduce the
problem, as it take around 20s for the memory used
to stabilise and stop growing.

I realy think there is a problem somewhere !!!


<< < 1 2 (Page 2 of 2)

    • status: pending-remind --> open-remind

    Logged In: YES
    Originator: YES


    I'm using the latest Lagarith codec version : 1.3.17.
    Here the link : http://lags.leetcode.net/codec.html

  • Ian Brabham
    Ian Brabham

    Logged In: YES
    Originator: NO

    I have found no memory leaks either Avisynth or Lagarith with the simple script provided. The Avisynth cache does however grow to approximately the SetMemoryMax limit. The default limit is currently quite high and has been causing problems, the next release candidate will have a lower default.

    In the YUY2 case the cache heuristics notice no cache hits and start early buffer reuse. This stops adding new frames to the cache. This happens after about 75 to 100 events. Corresponding to between 49Mb and 66Mb of cache.

    YV12 sources, 720 pixel wide, have a 360 byte chroma plane rowsize. As this is NOT mod16 aligned, the internal AlignPlanar filter is added to the graph, to provide mod16 pitch aligned frames. The AlignPlanar filter does not use the cache heuristics, so no early release of frame buffers occurs.

    Relaxing the alignment constraints for chroma planes to mod8, i.e 720 pixels wide YV12, will not require the AlignPlanar filter to be included. This will then show similar behaviour to the YUY2 case for YV12 720 pixel wide sources.

    AviSource("Lag_720x480_YV12.avi", False, "YV12")

    With the above example the cache starts early reuse mode after about 75 to 100 frames or about 37Mb to 50Mb. Without Legacy Alignment the cache will grow to 1024Mb if that much free memory was available. Mod4 width source will of course always exhibit the original behaviour.

    Under normal conditions it is intended that the cache track as many frames as will fit within the SetMemoryMax limit. There are some heuristics that limit this.

  • Ian Brabham
    Ian Brabham

    • status: open-remind --> pending-wont-fix
    • status: pending-wont-fix --> closed-wont-fix
  • Logged In: YES
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

<< < 1 2 (Page 2 of 2)