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

Eugene Mymrin emymrin
Fri Mar 5 12:44:15 CET 2010


I'm experimenting with rtsp:// streams with FFmpeg built for Android
and I do see av_find_stream_info blocking forever consuming very close
to 100% CPU.
There are many loops nested in av_find_stream_info which don't check
url_interrupt_cb.

On Fri, Mar 5, 2010 at 2:26 PM, Luca Abeni <lucabe72 at email.it> 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.
>
> I'll provide more trustable (not based on weak memories) information
> in the next days.
>
>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Luca
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>



More information about the ffmpeg-devel mailing list