[Bug 784002] rtpbin: ntp-sync temporarily causes old timestamps

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Mon Aug 28 17:25:03 UTC 2017


https://bugzilla.gnome.org/show_bug.cgi?id=784002

Sebastian Dröge (slomo) <slomo at coaxion.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #354614|none                        |needs-work
             status|                            |

--- Comment #4 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
Review of attachment 354614:
 --> (https://bugzilla.gnome.org/review?bug=784002&attachment=354614)

Generally looks good to me

With old timestamps, you mean timestamps going backwards? That should be
prevented in any case in rtpjitterbuffer and would be a bug that must be fixed.
There is code already to prevent that in the calculations for the actual PTS
(before ts-offset adjustment), but it would make sense one layer above
additionally too

::: gst/rtpmanager/gstrtpbin.c
@@ +2497,3 @@
+   * GstRtpBin:ts-offset-rate
+   *
+   * Syncing time stamps to either NTP or RFC7273 clocks adds a time offset.

RFC7273 does not go via ts-offset though. The offset comes from the SDP (or
otherwise via caps) at the beginning and does not change. What can change
however is the underlying network clock synchronization, but that would not be
affected here.

@@ +2505,3 @@
+      g_param_spec_uint64 ("ts-offset-rate", "Timestamp Offset Rate",
+          "The rate in nanoseconds per frame to apply adjustments to "
+          "time stamps (0 = apply all at once) ", 0, G_MAXUINT64,

This is not really a rate as implemented, but a maximum step size per "group of
packets with same RTP timestamp". Maybe should be called
"max-ts-offset-adjustment"?

::: gst/rtpmanager/gstrtpjitterbuffer.c
@@ +3391,3 @@
       update_estimated_eos (jitterbuffer, item);

+      priv->last_pts = pts;

This one here could also be used for detecting backwards timestamps caused by
the ts-offset

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list