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

Luca Abeni lucabe72
Fri Mar 5 12:26:00 CET 2010


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.

I'll provide more trustable (not based on weak memories) information
in the next days.


				Luca



More information about the ffmpeg-devel mailing list