[FFmpeg-devel] [PATCH] avoid infinite loop when seeking flv and non seekable input

[Baptiste Coudurier]

Hi Michael,

Michael Niedermayer wrote:
> On Tue, Jul 22, 2008 at 07:41:51PM -0700, Baptiste Coudurier wrote:
>> Hi,
>>
>> $subject,
>>
>> Reproduceable when trying to seek and input is non seekable (like http
>> through ffserver).
>>
>> [flv @ 0x8e27eb0]skipping flv packet: type 32, size 2705408, flags 0
>> [flv @ 0x8e27eb0]skipping flv packet: type 32, size 2763520, flags 0
>> [flv @ 0x8e27eb0]skipping flv packet: type 32, size 2818048, flags 0
>> [flv @ 0x8e27eb0]skipping flv packet: type 32, size 2856192, flags 0
>> [flv @ 0x8e27eb0]skipping flv packet: type 32, size 2889728, flags 0
>> [flv @ 0x8e27eb0]skipping flv packet: type 0, size 11469089, flags 0
>> [flv @ 0x8e27eb0]skipping flv packet: type 32, size 2949120, flags 0
>> [flv @ 0x8e27eb0]skipping flv packet: type 32, size 2987264, flags 0
>>
>> With patch resync happens faster:
> 
> I dont understand the problem, "trying to seek and input is non seekable"
> makes no sense to me. If the input is unseekable, seeking wont succeed
> anyway.

It will it when seeking forward, aviobuf.c:
} else if(s->is_streamed && !s->write_flag &&
       offset1 >= 0 && offset1 < (s->buf_end - s->buffer) + (1<<16)){

> Besides i do not understand why the attempt leads to any desyc in the first
> place. Whatever causes the desyc in the first place likely is buggy.

Yes, probably.

> Of course besides this, flvdec.c can be improved to be more resistant
> against errors and to resync faster that would require first to detect
> the desync (easy as the previous patcket size is stored in the header).
> ...

Indeed, good idea, thanks for remembering me.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA