[FFmpeg-devel] [PATCH] Correct ffplay timing of video after seek forward by 10 seconds when new seeking API used
Sat Jul 25 14:44:32 CEST 2009
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
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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 434 bytes
Desc: not available
More information about the ffmpeg-devel