[vlc-devel] Memory leaks

[Mark Moriarty]

In Src\misc\block.c
Function block_FifoPut

Variable i_depth already keeps track of blocks allocated, just no test to
see if it's getting large.

Suggest updating it to:
    int i_size = 0;
		if (p_fifo->i_depth < 60)
		{
    vlc_mutex_lock( &p_fifo->lock );
	......
    vlc_mutex_unlock( &p_fifo->lock );
		}

The "60" isn't a magic number, but putting some kind of limit would keep it
from expanding to infinity
Unfortunately, this will not clear the memory growth I'm seeing; there's
either an alternate buffer being filled or something else is allocating
memory without freeing it.

Block_Release gets called in block_FifoEmpty, but perhaps there is something
else needed in decoderdecode of decode.c?

 

-----Original Message-----
From: vlc-devel-bounce at videolan.org [mailto:vlc-devel-bounce at videolan.org]
On Behalf Of Gildas Bazin
Sent: Monday, July 26, 2004 11:28 AM
To: vlc-devel at videolan.org
Subject: [vlc-devel] Re: vlc: svn commit r8284 (gbazin)

On Monday 26 July 2004 16:13, Mark Moriarty wrote:
>  WinXP, fully patched, current SVN build, 2.6GHz Intel P4.
> I tried using the screen: function, UDP output.
> High CPU utilization, variable but generally stayiung between 45 - 80%.
>

I did the win32 part on Linux so couldn't test it but I did today and the
performance is indeed abysmal. That partly comes from the fact that I've
been using the GDI api and this one totally locks the display while a frame
is being grabbed.
I think I'll investigate doing this with directx. It should be a lot
quicker.

> Very rapid, very large, memory leak -- hundreds of megabytes growth 
> per minute.
> 
> This is similar to what I saw with an Osprey framegrabber in a slower 
> 800 MHz Win2K PC, a separate thread series.
> 
> Is there some chance that there is a "marshmallow mountain" effect, 
> that
if
> frames are being served to the ffmpeg CODEC engine faster than they 
> can be processed a queue, just gets larger and larger?
> 

Yes, this is what happens.
The input thread is only putting data in a fifo that the decoder / stream
output thread empties as it processes the data. So if the decoder thread
doesn't process the data quickly enough, the fifo will grow. We could have a
mechanism to limit the size of the fifo but that's not been done yet.

> Anyhow, for Windows screen, perhaps an option to decimate the input, a 
> straight /2 in both width and height, would cut the input by a factor 
> of
4,
> perhaps help a large amount.
> 
> The GPL'd RealVNC does pretty well on Windows, screen 
> capture/manipulation functions in it might map well to VLC, handles 
> different screen bits-per-pixel, and I believe has things related to 
> multi-monitor implementations (they've had several years experience, a 
> lot of lessons-learned).  The VNC windows source code germane to this 
> is in sdisplay and deviceframebuffer.
> 

I doubt I'll be able to re-use the VNC code because they are likely working
by only catching regions that have been updated. This would be way too much
work/code for VLC and I'm not sure of the benefit because the most CPU
intensive task here will be the encoding anyway. I'll have a quick look at
their code anyway.

--
Gildas

--
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>

-- 
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>