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 765093 - baseparse: Timestamp tracking has accumulating rounding errors when using frame rate
baseparse: Timestamp tracking has accumulating rounding errors when using fra...
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
1.8.0
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-04-15 10:20 UTC by Sebastian Dröge (slomo)
Modified: 2018-11-03 12:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Sebastian Dröge (slomo) 2016-04-15 10:20:30 UTC 
Audio parsers often just use the frame rate based timestamp tracking, i.e. gst_base_parse_set_frame_rate(). The base class then simply stores fps_d/fps_n and uses this for the buffer durations. And then uses the buffer durations to interpolate the next buffer timestamps.

So if upstream only provides timestamps every now and then, or only one in the very beginning, or none at all (filesrc ! mpegaudioparse ! ...), the rounding errors caused by the division will accumulate until the point when things start to fail.
Comment 1 Sebastian Dröge (slomo) 2016-04-15 11:06:00 UTC 
Basically we should remember the frame rate and not the duration as a fraction, start counting from a anchor the number of frames and then calculate the current duration based on the number of frames, the frame rate and the anchor.

The anchor should probably be based on the last known upstream PTS/DTS and be reset whenever upstream provides a new timestamp somehow. But also needs to take into account changing frame rates, and subclasses providing durations sometimes instead of nothing, and ...
Comment 2 Sebastian Dröge (slomo) 2016-04-15 11:25:02 UTC 
Note that for MP3 with 44.1kHz, we increase timestamps by 0.9796 nanoseconds less per 1 second than we should. That's probably neglible, the 40ms alignment threshold in baseaudiosink (40ms) would happen after almost 463 days.
Comment 3 GStreamer system administrator 2018-11-03 12:34:24 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/169.