[FFmpeg-devel] [PATCH] Correct ffplay timing of video after seek forward by 10 seconds when new seeking API used

[Ivan Schreter]

Michael Niedermayer wrote:
> On Sat, Jul 25, 2009 at 02:44:32PM +0200, Ivan Schreter wrote:
>   
>> [...]
>> The attached trivial patch reduces the maximum frame time to 5 seconds, 
>> which fixes the problem for this particular case of (inexact) seeking of 10 
>> seconds into future.
>>
>> OK to apply?
>>     
> [...]
>> However, someone should fix it correctly for seek case, but I don't get the 
>>     
>
> as you say "someone should fix it correctly" i guess i dont need to
> explain why your patch is wrong you seem to already know 
>
>   
Ehm, it's not "wrong". It happens it's not a proper solution. It's just 
a workaround to alleviate the problem. But it doesn't change readability 
of the code or otherwise interfere - it's just a change of one 
wildly-chosen constant (actually, quite badly chosen, given 10 second 
step for seeking).
>   
>> code 100%, so I didn't want to create more problems than to fix...
>>     
>
> and yes ffplays timing code is tricky and not even 100% bugfree, for example
> i think theres a little issue with timestamps or durations being applied to
> th next or previus frame by mistake ...
>
>   
I tried for a proper quick fix, but as you write, it looks like frame 
timings are shifted by one frame, thus it doesn't help just to change 
delay computation of one frame after seek (or reset timing after seek) - 
it's the second frame, which hangs.

I don't have time for a proper fix, since I'd rather make sure other 
stuff works well (especially seeking for relevant formats for video 
editing). ffplay is in my eyes just a toy tool (or proof of concept how 
a player can be written with FFmpeg). Or am I mistaken there?

Therefore, I'd propose to change the constant for now, since it doesn't 
make anything worse.

Regards,

Ivan