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

[Michael Niedermayer]

On Sat, Jul 25, 2009 at 02:44:32PM +0200, Ivan Schreter wrote:
> Hi,
>
> I'm trying to get new seeking API working according to specified contract 
> for MPEG-TS/AVCHD (patch not yet checked in, see the thread about AVCHD 
> seeking). It works in the meantime correctly and other programs (e.g., 
> kdenlive video editor with appropriate MLT patches) can seek properly.
>
> However, ffplay seems to have a problem when seeking forward. Seeking 
> backward works properly, but when seeking forward, sometimes it hangs for a 
> while. I've checked that the seeking routine really repositions the stream 
> to appropriate position. ffplay also reads a few frames, which have correct 
> timestamps, and displays the first video frame after the seek. But then it 
> hangs for several seconds (up to 10, when using right arrow key), before 
> actually playing back from the new position (the playback is correct, 
> then).
>
> The difference between original and new seeking API is that the new seeking 
> API will reposition to such a point, where _all_ streams synchronize at 
> given timestamp, not just one reference stream. I suppose, this somehow 
> brings timing of ffplay out-of-sync. It looks like the playback timestamp 
> is not updated after the seek, so the video thread thinks it has to wait 
> until those up to 10 seconds have passed.
>
> I found out there is a timer used to time video frames using 
> video_current_pts_time and video_current_pts members. However, this seems 
> not to be reset at all after a seek. Only compute_frame_delay() checks, 
> whether there is an "incorrect" delay.
>
> Since we seek now to the closest keyframe (which may be closer than those 
> 10 seconds), compute_frame_delay() thinks, the delay is OK and lets the 
> video thread wait.
>
> 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?

no, this change is just wrong

>
> 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 


> 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 ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is not what we do, but why we do it that matters.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090725/c1116c3d/attachment.pgp>