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

[Michael Niedermayer]

On Fri, Mar 05, 2010 at 12:26:00PM +0100, Luca Abeni wrote:
> Michael Niedermayer wrote:
>> On Fri, Mar 05, 2010 at 11:58:06AM +0100, Luca Abeni wrote:
>>> Michael Niedermayer wrote:
>>>> On Fri, Mar 05, 2010 at 11:46:03AM +0100, Luca Abeni wrote:
>>>>> Michael Niedermayer wrote:
>>>>>> 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
>>>>> The networking code does not support the AVFMT_FLAG_NONBLOCK flag.
>>>>> I tried adding support for it in the UDP and RTP protocols some
>>>>> time ago (this is actually quite trivial), but then I had issues with
>>>>> some other code in libavformat (av_find_stream_info(), if I remember
>>>>> well - but I might be wrong) that is not prepared to it...
>>>>> Then, I ran out of time :)
>>>> av_find_stream_info() will block from the users point of view, unless 
>>>> the
>>>> user stops it through url_interrupt_cb()
>>>> is there some other problem with it?
>>> 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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 
-------------- 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/ebcb242b/attachment.pgp>