[FFmpeg-devel] [PATCH] Yield on AVERROR(EAGAIN).

[Michael Niedermayer]

On Fri, Mar 05, 2010 at 08:23:07AM +0100, Reimar D?ffinger wrote:
> On Fri, Mar 05, 2010 at 03:48:52AM +0100, Michael Niedermayer wrote:
> > What you suggest needs a select() like system that works with files,
> > network protocols, audio and video grab APIs as well as screen capture
> > APIs needs to work on all platforms
> > that support yield()/sleep() of some kind and needs to work with
> > any set of supported protocols on that platform and needs protocols
> > to pass thier file/object handle(s) through demuxers to the user app so
> > it can do that select() call
> 
> Actually... No, it would be enough for the devices to just do a select themselves.

> After all, our networking code does not just do a non-blocking read and then
> just returns EAGAIN if it didn't get anything.

this should be fixed of course


> Now the issue is a bit larger if audio and video are separate, we can't block
> on one while the other overflows a buffer, but a 10ms select in each of the
> devices that currently cause this issue should be enough, shouldn't it?

demuxers or protocols blocking a single thread application is bad.
and not scaleable at all
if you imagine a video security system with 5 cameras, from which do you
read? (each can block you by 10ms if it has no video but at 30fps reading
from 4 cams that had no video will cause the fifth to drop a frame)
if each immedeatly returns EAGAIN you can poll all with near zero cpu time
and then sleep for 1-10ms in a central place once and not per camera


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100305/94b5e745/attachment.pgp>