[vlc-devel] DirectShow Input

Mark Moriarty mfmbusiness at earthlink.net
Thu Jun 24 04:27:11 CEST 2004

 I did more testing today, stayed with the 800 MHz machine but dropped the
frame size to 320x240.  CPU use dropped to 30%, and very few Messages were
reported by VLC, just an occaissional MPEG adjustment, which makes sense
since those occurred when I was playing with the input video, introducing
more motion.  No CapturePin warnings -- I was able to get them when I
briefly reran at 640x480, which pegged the CPU.

Definitely a memory leak in there somewhere.  VLC memory utilization grew
2.5 MB over 20 minutes -- a slow, steady, increase.  No idea if it comes
from the Dshow input, the mpeg compression, or the encapsulation and
streaming, but something has a slowly increasing buffer.

(when I ran 640x480 framegrabs yesterday, memory use leaped a full 200 MB
over only 1 or 2 minutes).

Is there some kind of compile switch or debug option I could use in the
compile, to help provide more information on where the memory leak is
occuring?  Would using -vvv do something?


-----Original Message-----
From: vlc-devel-bounce at videolan.org [mailto:vlc-devel-bounce at videolan.org]
On Behalf Of Mark Moriarty
Sent: Tuesday, June 22, 2004 6:29 PM
To: vlc-devel at videolan.org
Subject: [vlc-devel] Re: DirectShow Input Problem on Current Builds of VLC

Damien --
I compiled this morning (EST), tried it at work.
The Osprey is working -- video displaying, Viewcast's (Osprey vendor)
control panel applet opening fine.

I did notice a massive memory leak when I stream the input, and documented
what's happenning on the forum.  Essentially, if I run an MPEG4 stream (UDP)
of the dshow input, memory use surges rapidly -- VLC memory use > 250
megabytes in one minute, plus the CPU is absolutely pegged (99+%
utilization).  The particular machine I worked with today is weak CPU-wise,
only 800 MHz, so I'm curious if that may just be a problem with too much
data from dshow for the streaming portion to handle?  (Is there any internal
signalling between the dshow input parser, the transcode engine, and the
streaming multiplexer, or perhaps the dshow just keeps shoveling frames and
they keep building in a queue?)  I'll try again tomorrow with a more
powerful PC, one of our 2+GHz jobs.

I also saw a CapturePin warning, forgot to grab a copy of the message at
work, that popped up maybe every 5 seconds.  For comparison I checked the
pre-0.7.2 version of VLC, with the 5 March dshow -- that version was also
leaking memory badly on my lightweight CPU, maxing out CPU use, but did not
generate the CapturePin warning messages.

Anyhow, having the Osprey work in any way is a huge plus for me.

Thank you.


This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>

More information about the vlc-devel mailing list