VLC Memory Leak, UDP Streaming of DirectShow Input

[markfm]

A partial repost of a message from another thread. The general difficulty in the other thread seems to have cleared up, but I now am encountering a different issue -- memory leak.

I'm using a 22 June build of the Subversion files, Win2K, fully patched, Osprey framegrabber.

VLC is set to take DirectShow input, video only, 320x240 resolution off of a framegrabber, stream via UDP, using point-to-point UDP, mp4V transcoding, 768 kbps.

There's definitely a memory leak somewhere. With just the Message window and Windows Task Manager open on the desktop, running 320x240 video capture, VLC memory utililzation increased from 14580 KB to 16540KB over 10 minutes, and 17000 KB at 20 minutes. (in other words 2.4 MB increase). It's a gradual increase but consistently trending upwards with time.

For VLC Messages, I only had one over the 10 minutes:
mux_ts debug: adjusting rate at 66022/239100 (193/19)

I believe that may not have occured until I popped open my Web browser. As I've mucked about a bit, opening and sliding windows on the Desktop, I've gotten a few more of the above message -- ffmpeg auto-adjusting itself a bit to keep within the nominal bandwidth?

(for testing, I'm taking an analog composite output from my PC, a clone of the Desktop, and feeding that as the input to the Osprey card being used by the VLC server)

When I tested at higher resolution, something that was pegging the CPU, the leak was huge -- over 200 MB growth in VLC memory use in 1 minute. It seems (probably wrong) like there must be some kind of video buffer that is growing if the individual video frames aren't getting encoded/transmitted fast enough -- a "marshmallow mountain" where frames just keep building in an input queue. I have no clue what queue this is -- whether it's frames going to the mpeg encoding area, encoded frames going to the packetizer,...

I would be happy to turn on any additional debugging that could assist tracking this down, just don't know what to do.

Thanks.

[Frater Kork]

I have not seen this leak, but I have only captured a total of an hour or so at a time.
But now that You mention it I will take a close look at my box during a couple of hours to see if I get the same behaviour.

Cheers!

[markfm]

I'm pretty sure the leak isn't unique to my configuration -- Matt reported it separately at:
viewtopic.php?t=3127

so it's likely something already in the code, not directly related to the dshow input having been "loosened up" a bit (My Osprey 210 stopped working with VLC, and the dev went in and change part of the code back to an earlier version, more lenient; Matt's report, however, is with the "stricter" version of the Dshow input SW, which means the memory leak isn't directly due to the more forgiving version of DShow input)

[markfm]

I'm definitely open to thoughts on this. Using my USB Webcam I see no leak, but I'm definitely getting it off of the Osprey, and someone else reported a memory leak using a Hauppauge card.

Is there something which occurs with dshow, relative to a "non-standard" device, that does not occur if you hit a USB Webcam? Some kind of queue that isn't clearing properly? I would be happy to add lines to various files to check on memory utilization at different points in the code, to try and trap which modules are leaking, test them out against the Osprey. I just need a suggestion on what to try, where.

Thanks much.

[Gibalou]

This one is indeed weird. I can't think of any reason why you would get a mem-leak with your Osprey and not the USB cam.

I think you should do a few tests and procede by elimination.
1 - try without streaming, just playing.
2 - try without streaming and disable the audio and video (--novideo --noaudio).
3 - try without streaming and force the dummy demuxer (vlc dshow/dummy://)

Do you have the leak with all the above tests ?

[Matt]

Just a clarification here. I have had issues with capture using both the Hauppauge card and an web cam but so far I can only confirm the memory leak when using the webcam. I have not done any extended captures with the hauppauge card on account of the other dshow issues that I mentioned.

I have however done a capture test using the webcam and mediaplayer classic, with ffdshow's libavcodec based mpeg4 being used and can confirm that there was no memory leak. This version did have a more recent version of libavcodec however. I would suggest that this indicates that the issue either lies in the specific version of libavcodec being used or some issues with the dshow access module in vlc.

cheers, matt

[markfm]

I need to do more extensive checks. I just tried a current latest-and-greatest build, admittedly limited time, wasn't getting a leak.