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

Michael Niedermayer michaelni
Fri Mar 5 11:48:02 CET 2010


On Fri, Mar 05, 2010 at 11:16:51AM +0100, Nicolas George wrote:
> Hi.
> 
> Le quintidi 15 vent?se, an CCXVIII, M?ns Rullg?rd a ?crit?:
> >			  On a modern Linux system it will merely invoke
> > the scheduler, which will notice that nothing else wants to run and
> > put this thread back on the CPU immediately.
> 
> It will also do that if there are plenty of other process who want to run
> but they have a lower priority.
> 
> > The correct solution is to make the devices somehow notify when input
> > is available so the process can sleep properly while waiting.  On Unix
> > systems this is typically done with select() on a file descriptor.
> 
> Unfortunately, select will not always do the trick: AFAIK, there are devices
> who relie on ioctls rather than plain reads, or libraries who do not expose
> the underlying file descriptor.
> 

> A more generic solution is to use threads: each possibly-blocking device
> runs in its own thread, where it can block all it wants without delaying the
> other devices or the encoding. The packets read from the devices is queued
> in memory, and the main loop just takes the packets from the queue.

Threads allow you to turn any blocking device in a non blocking one, yes


> 
> If AVFormatContext gets a new field "AVThreadInfo *thread_info", then the
> basic feature can probably be implemented with minor changes to
> av_read_packet and av_close_input_stream, and later extended without the
> need for a version bump.

i dont understand you, libavdevice/jack_audio.c for example alraedy uses
a seperate thread (its the way how jack is supposed to be used it seems)
and without any AVThreadInfo

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle
-------------- 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/a7d5a073/attachment.pgp>



More information about the ffmpeg-devel mailing list