[FFmpeg-devel] [PATCH] stop av_find_stream_info after reading a certain amount of frames

[Baptiste Coudurier]

Hi Michael,

On 3/2/2009 6:25 AM, Michael Niedermayer wrote:
> On Mon, Mar 02, 2009 at 03:19:04PM +0100, Michael Niedermayer wrote:
>> On Sun, Mar 01, 2009 at 08:43:25PM -0800, Baptiste Coudurier
>> wrote:
>>> Baptiste Coudurier wrote:
>>>> Marc Mason wrote:
>>>>> Baptiste Coudurier wrote:
>>>>> 
>>>>>> Index: libavformat/utils.c 
>>>>>> ===================================================================
>>>>>>
>>>>>> 
--- libavformat/utils.c	(revision 17505)
>>>>>> +++ libavformat/utils.c	(working copy) @@ -2019,7 +2019,7
>>>>>> @@
>>>>>> 
>>>>>> count = 0; read_size = 0; -    for(;;) { +    for(; count <
>>>>>> 200; ) {
>>>>> Just wondering. Why not "while (count < 200)" ?
>>>> Yes, why not.
>>>> 
>>> Michael, can you please comment and propose a better solution if
>>> you see one.
>> limiting the loop to 200 iterations wil cause regressions, iam sure
>> of that but i cant point to some file. I just know there are files
>> where one stream starts later then the other and 200 isnt all that
>> much
>> 
>> 
>>> It seems EAGAIN thing broke FFserver, since there is an infinite
>>> loop in av_find_stream_info.
>> what about a solution like: if(ret == AVERROR(EAGAIN) &&
>> strcmp(is->iformat->name, "ffm")) continue; as we have in ffmpeg.c 
>> ?
> 
> other options would be useig url_interrupt_cb() in ffserver.c

I'll look.

> or making ffm return AVERROR_EOF when it reaches EOF instead of
> EAGAIN

Yes, I'm working on this, but this won't solve the case where feed is
actually being written, and we need to wait for more data to be
available, this case must return EAGAIN, and this might happen in
av_find_stream_info.

> or making av_find_stream_info() return EAGAIN itself immedeatly but 
> this is hardest as we would need to store all context to allow
> continuation also this one would break all user apps but it is
> technically most correct behavior IMHO

Humm, I see, it seems currently issue only concerns ffm.

A potential infinite loop might not be desireable though, IMHO there
should be a internal limit.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org