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

[Ivan Schreter]

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?

However, someone should fix it correctly for seek case, but I don't get 
the code 100%, so I didn't want to create more problems than to fix...

Regards,

Ivan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffplay_flush.patch
Type: text/x-patch
Size: 434 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090725/1a2cd26c/attachment.bin>