GNOME Bugzilla – Bug 611500
[regression] Wrong outgoing timestamps
Last modified: 2010-10-07 15:53:15 UTC
The timestamp reordering code in gst-ffmpeg seems to have a problem with buffers coming in with DTS values as buffer timestamps.
The following is an example of what happens (following a seek to 0:02:29.960000000):
* Incoming buffer 0:02:29.960000000
avdecode_video decodes it properly, we push it out with that timestamp
* Incoming buffer 0:02:30.000000000
avdecode_video consumes it but doesn't return anything for the moment
* Incoming buffer 0:02:30.040000000
avdecode_video decodes it properly but we set a timestamp of 0:02:30.040000000
* Incoming buffer 0:02:30.080000000
avdecode_video decodes it properly, but we get a timestamp of 0:02:30.000000000, we finally recognize the incoming data was in DTS and therefore patch up the timestamp to 0:02:30.080000000
So we push out:
0:02:29.960000000 (which has the proper timestamp since it's the keyframe)
0:02:30.040000000 (which should have been 0:02:30.000000000)
0:02:30.080000000 (which should have been 0:02:30.040000000)
So two things are wrong:
1) We detect that the incoming stream is timestamped as DTS too late
2) We introduce an offset of one frame in the outgoing buffers
We should have detected when avdecode_video returns the SECOND buffer that the incoming stream is DTS, instead of at the THIRD buffer it outputs
Extract of debug log for incoming values we store in the ts_handler system
store timestamp @ index  buf_count: 0 ts: 0:02:29.960000000 duration: 0:00:00.040000000, offset: 18446744073709551615, size: 9266
store timestamp @ index  buf_count: 0 ts: 0:02:30.000000000 duration: 0:00:00.040000000, offset: 18446744073709551615, size: 1569
store timestamp @ index  buf_count: 0 ts: 0:02:30.040000000 duration: 0:00:00.040000000, offset: 18446744073709551615, size: 40
store timestamp @ index  buf_count: 0 ts: 0:02:30.080000000 duration: 0:00:00.040000000, offset: 18446744073709551615, size: 1740
Demoting this to major, demuxers pushing out buffers with DTS timestamps is just bad to start with.
It currently reacts when the output timestamps go backwards, which is exactly one frame late and then we need to patch up the rest of the buffers with wrong timestamps. It's quite simple but bad.
A better approach would be to track input and output timestamps but I'm concerned that it would freak out when a frame fails to decode. I'll see if it can be improved.
Author: Wim Taymans <email@example.com>
Date: Thu Oct 7 17:46:22 2010 +0200
ffdec: use a better algorithm to detect DTS timestamps
Add function to reset the timestamp tracking.
Check for reordered timestamps on the input buffers and assume PTS input
timestamps when we see reordered timestamps.
Recover from an occasionally wrong input timestamp by also tracking the output
timestamps. When we detect a reordered output timestamp, assume DTS input