[vlc-devel] Re: vlc: svn commit r8284 (gbazin)

[Mark Moriarty]

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

Limiting the fifo is critical -- it's a runaway condition, locking both CPU
and memory in a race condition of acquiring more images (memory) and trying
to process them (CPU)which should not be able to occur.  I've hit this with
both Dshow and screen inputs.

VNC uses a DIB approach, I believe, and seems to not eat too many resources.
Granted it only polls foreground at 1 Hz. 
-----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>