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

[Gildas Bazin]

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>