[vlc-devel] Re: vlc: svn commit r8284 (gbazin)
gbazin at altern.org
Mon Jul 26 18:28:28 CEST 2004
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
> Very rapid, very large, memory leak -- hundreds of megabytes growth per
> 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
> 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
> 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.
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