h264 memory leak about lavfilters HOT 5 CLOSED

Does it actually leak the memory? What if you close the LAV instance, does it get free'ed? 100mb of memory isn't something to worry about if its not actually leaked, and maybe just in-use.

Its not a leak if the memory is free'ed, since its not lost. Its just in use.

from lavfilters.

Perhaps I used an incorrect term (memory leak). Indeed, consumed memory is freed when I close LAV video instance. However, another problem still exists.
The problem is that memory consumption always grows while decoding h264, especially in case of "bad" stream, and it seems that it is never released. As a result, the application that uses LAV instance for h264 decoding will be anyway terminated by the system with "out of memory" exception.
Maybe such behaviour is ok if LAV is used for movie watching - in this case LAV is used only while the movie is being played and there will be not enough time for memory to finish. But my purpose is to use LAV for 24/7 video decoding from network - that's why I am worried about it.
You said that 100 mb of memory is ok, but that value was just for a couple of minutes of errorneous video decoding.
From my point of view, I just do not understand such behaviour of h.264 decoder - the memory consumption and allocations only increase with time and released only when instance of decoder is closed. Why those huge amounts of already allocated memory cannot be reused somehow?

Have you performed some long-lasting tests of LAV video decoder with h264 videos?

from lavfilters.

The H264 decoder is the most common decoder to be used, on a daily basis by millions, not only in LAV but also through the FFmpeg project in many other applications - so if it had any big fundamental flaws, it would be known, trust me. :)

Without knowing where exactly the memory goes to, I cannot judge why it does that. But considering its not actually leaked, it seems to be functioning fine. Allocating memory it doesn't really need without leaking is rather unusual.

from lavfilters.

One simple idea, LAV has internal queues that it tries to fill as best as it can to ensure smooth playback. Obviously with real-time streaming, it won't be able to really fill the queues, because data arrives in realtime and is played in realtime.

However, if such a short stream "hiccup" occurs, it could feed a bit more data into the queues as audio and video have to sync again. If your stream is sufficiently high bitrate, this could accumulate over time.
Note that these queues have an upper limit and won't grow indefinitely.

LAV offers a maintenance interface to inspect the size of the queues through IBufferInfo (definition in developer_info), which lets you query the number of packets and the overall memory size of the queues. You could check that.

There is also options in LAV Splitter to tune the maximum size of the queues, both in number of packets and memory size.

from lavfilters.

Closing due to lack of clear information. Its definitely not a leak, as the memory is free'ed when the LAV instance is closed.

from lavfilters.