[FFmpeg-devel] [PATCH] Yield on AVERROR(EAGAIN).
Fri Mar 5 11:48:02 CET 2010
On Fri, Mar 05, 2010 at 11:16:51AM +0100, Nicolas George wrote:
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel