[FFmpeg-devel] [PATCH] Yield on AVERROR(EAGAIN).
Michael Niedermayer
michaelni
Sat Mar 6 14:17:58 CET 2010
On Sat, Mar 06, 2010 at 10:39:55AM +0100, Luca Abeni wrote:
> On Fri, 2010-03-05 at 12:35 +0100, Michael Niedermayer wrote:
> [...]
> > >>> I might be wrong (maybe I remember the wrong problem :), but I seem to
> > >>> remember that it consumed 100% of the CPU if the network returned EAGAIN
> > >>> because of AVFMT_FLAG_NONBLOCK.
> > >> question is, even if so, why would this hold adding nonblock support to
> > >> tcp/udp up?
> > >> Its not as if av_find_stream_info() didnt consume 100% now in that case
> > >
> > > Ok; let me run some tests during the weekend and I'll provide some
> > > more reliable information. But (as far as I remember) with blocking
> > > network input (as it is right now) av_find_stream_info() does not consume
> > > 100% of the CPU (because the process is almost always blocked).
> > > With nonblocking network input, it consumes 100% of the CPU.
> >
> > sounds like you need a usleep() somewhere
> Yes, my impression is that an usleep() would be needed in
> av_find_stream_info(). But I did not want to insert a sleeping function
> in the "generic" libavformat code, so I wanted to find an alternative
> solution.
The philosophical correct solution would probably be to safe state and
return EAGAIN from av_find_stream_info()
and iam not against this if it can be done simply ...
also usleep() is better then a 1 goto 1 heating the cpu
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I wish the Xiph folks would stop pretending they've got something they
do not. Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- 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/20100306/389fbd64/attachment.pgp>
More information about the ffmpeg-devel
mailing list