The VideoLAN Forums

I'm having the following issues with 0.7.2 on Win32 (precompiled):

1) With a Happaugge wintv-go card and the latest drivers (not BTwincap) for W2K the colors are being mixed up. I can't tell which colors for sure but it looks like the blue and green are being transposed. The colors are consistent between the live display and the saved files. The results are the same regardless of which color format is requested.I believe this issue was brought up previously but there was no fix detailed.

2) With a cheapie webcam (sightcam pc-100p) under windows XP pro I'm finding that if I try to capture video for extended periods of time (longer than an hour) any one of several things may happen: Stopping the capture doesn't work. ie the recorded file stops growing but does't seem to get closed and the capture device does not get released (the indicator light stays on) ultimately the process has to be killed to release the device and the recorded file is unreadable unless it is saved as transport stream. Alternately if the capture is left to run long enough it simply crashes eventually.

3)Also, with extended capture preiods a memory leak appears. For a capture of mp4v @ 192 and mp4a @32, the memory footprint of VLC will increase steadily at a rate of about 10 Mb/hour.

If anyone has any thoughs, revelations or hints regarding these issues it would be appreciated. Thanks.

bump.

Matt -- How about trading memory leaks with dshow? I hit a 200 MB leak in one minute, when streaming

What's your CPU? When I ran an earlier VLC on a more powerful CPU, I ran many hours with no obvious problems. Today, the very rapid memory leak occured when I was using my framegrabber in a fairly weak CPU. On a 3 GHz machine VLC was using about 20% of the CPU, while on my 800 MHz machine it soared to 99%.

I sent a post to vlc-devel, asking if maybe there was some problem with signalling between the dshow input, transcoding, and streaming.

The machine on which I'm experiencing the memory leak is a P4 3.2Ghz c/w 1 gig ram so the slower machine theory might not be correct.

What i did find however was in the changelog for ffdshow:

2004-05-25 11:18 milan_cutka

* libavcodec memory leak fix by Andrew Ivanov

Perhaps this is where the problem lies. If you roll your own, perhaps a fresher compile will do the trick. I haven't got any compilers installed on this rig yet so I'll wait.

As for the Dshow issues, I poked around and it seems that I'm unable to actually set the capture window size for my card so right now I'm assuming that some part of the dshow configuration process for this card is totally borked and it simply stays set at whatever the default settings are. The color format is probably stuck as BTYUV or some odd thing. If there were some other app that could set the color format from outside of VLC I could comfirm it. Or maybe one of the developers could shed some light on it for me.

Thanks, Matt

There had been a dshow change that occured before 0.7.2 came out, which made it more stringent in how it worked with framegrabbers. The developer has gone back to a more lenient dshow now, so at least in my case I can select device properties and get at my device's control panel app, adjust things.

I changed my settings so I was only working 320x240 on the slower machine -- CPU utilization became OK, but there was still a memory leak, about 2.5 MB over 20 minutes (my input was fairly static). This was running no audio, mp4v video streaming at 768 kbps.