After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 611500 - [regression] Wrong outgoing timestamps
[regression] Wrong outgoing timestamps
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-libav
git master
Other Linux
: Normal major
: 0.10.12
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-03-01 17:16 UTC by Edward Hervey
Modified: 2010-10-07 15:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Edward Hervey 2010-03-01 17:16:28 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

NOTES:
Extract of debug log for incoming values we store in the ts_handler system
store timestamp @ index [01] buf_count: 0 ts: 0:02:29.960000000 duration: 0:00:00.040000000, offset: 18446744073709551615, size: 9266
store timestamp @ index [02] buf_count: 0 ts: 0:02:30.000000000 duration: 0:00:00.040000000, offset: 18446744073709551615, size: 1569
store timestamp @ index [03] buf_count: 0 ts: 0:02:30.040000000 duration: 0:00:00.040000000, offset: 18446744073709551615, size: 40
store timestamp @ index [04] buf_count: 0 ts: 0:02:30.080000000 duration: 0:00:00.040000000, offset: 18446744073709551615, size: 1740
Comment 1 Edward Hervey 2010-03-02 20:23:20 UTC
Demoting this to major, demuxers pushing out buffers with DTS timestamps is just bad to start with.
Comment 2 Wim Taymans 2010-10-07 10:44:37 UTC
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.
Comment 3 Wim Taymans 2010-10-07 15:53:15 UTC
commit 3f213c1b7306f5c5a895048affb31dbfb66a9e01
Author: Wim Taymans <wim.taymans@collabora.co.uk>
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
    timestamps again.
    
    Fixes #611500