GNOME Bugzilla – Bug 747731
basesrc: Always setting segment.start as DTS on first buffer
Last modified: 2015-04-13 07:23:36 UTC
+++ This bug was initially created as a clone of Bug #747722 +++ Currently basesrc always sets the segment.start (or 0) as the DTS of the first buffer if the subclass did not provide a DTS. Live sources that provide raw data usually don't set any DTS, so in those cases the first buffer would always get a DTS of 0. This seems wrong, and like something that should only be done if do-timestamp=true. It's not guaranteed that the first buffer should have a DTS of 0, the source might start much later. (And apart from that we should never set DTS on raw media!)
Created attachment 301408 [details] [review] basesrc: Only set DTS to segment.start on the first buffer if subclass did not provide PTS Otherwise we're going to set a rather arbitrary DTS of segment.start (usually 0) for live sources, which confuses synchronization if the source started capturing at a later time. And it's especially wrong for raw media, for which we should not set any DTS at all.
commit 7d3d4503a1d33f22dfdfb7402240f0d125b31239 Author: Sebastian Dröge <sebastian@centricular.com> Date: Sun Apr 12 13:13:32 2015 +0200 basesrc: Only set DTS to segment.start on the first buffer if subclass did not provide PTS Otherwise we're going to set a rather arbitrary DTS of segment.start (usually 0) for live sources, which confuses synchronization if the source started capturing at a later time. And it's especially wrong for raw media, for which we should not set any DTS at all. https://bugzilla.gnome.org/show_bug.cgi?id=747731