2.1.5 Memory Leak

[Raydude]

We have two instances of VLC 2.1.5 feeding a remote re-broadcaster. They are doing identical jobs with two separate cameras, yet one of them is leaking memory badly.

When first started the processes look like this:

25382 user 20 0 733032 21200 8100 S 4.3 0.1 0:00.56 vlc
25377 user 20 0 733032 21260 8100 S 4.0 0.1 0:00.54 vlc

But after a few hours, they look like this:

25382 user 20 0 733032 25744 8104 S 4.3 0.2 3:21.16 vlc
25377 user 20 0 1322856 608024 8124 S 3.7 3.7 2:48.53 vlc

In 2.1.4 both would slowly leak memory until they had to be restarted. So one is much better, the other much worse.

Both are running with a command like this:
/usr/bin/cvlc -d -q 'http://user:password@192.168.1.252:5252 ... ty=Clarity' --sout '#transcode{vcodec=mp4v,vb=100,width=240,height=208,fps=9}:rtp{dst=IP.AD.DR.ES,port-video=7990,ttl=64,sdp=file:///usr/local/movies/file.sdp,name=streamname}'

I can help debug this, just tell me what to do.

Thanks for any help you can offer.

[Jean-Baptiste Kempf]

You should valgrind it.

[Raydude]

Thanks, I'll google that and figure out what to do.

We're also having problems restarting the processes. The killall -9 script doesn't appear to be working. Strange how an OS could fail to kill a process.

[Raydude]

I'm running valgrind on the two processes and it's clear that memory is being lost, but valgrind is not detecting it.

I'm wondering if it's possible that the streamer is getting behind and buffering up unsent data, when it should be tossing stale and lost data away, skipping forward to current time and reclaiming it's memory...

How could I check that?

[Raydude]

I've decided that it is likely that the video camera (a reliable local device) is getting ahead of the DSS (on the internet connected by wireless), causing VLC to buffer data. (heaven forbid VLC lose data!) It seems to me that vlc needs a new command line option, '-live,' which tells the mux to only allow itself to get behind by two buffer lengths, once it crosses that threshold it needs to look for an i-frame at around the one buffer location, jump to it and throw the intervening data into the bit bucket. This will ensure that the live stream stays up to date and prevent memory from being allocated beyond two buffers worth...

Of course I don't know the code at all. I started looking at the streaming code to understand how it works and will continue to do so tonight, but if anyone had any pointers, I'd really appreciate it.