[Bug 784132] rtpmanager: Add support for in-band synchronization (RFC 6051).

[GStreamer (GNOME Bugzilla)]

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

--- Comment #6 from GstBlub <gstblub at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #3)
> In rtpjitterbuffer this could probably also be used for some of the sync
> modes instead of interpolating timestamps. There already is code that
> calculates timestamps based on the NTP timestamp, which could directly use
> this then.

I think the interpolation there is still needed.

> ::: gst/rtpmanager/gstrtpbin.c
> @@ +1633,3 @@
> +
> +  if (gst_structure_has_field (s, "ntp-time")) {
> +    /* perform in-band synchronization for this stream */
> 
> Now you would do sync based on this, and based on RTCP. Is that a problem?
> Also this now would only work if the first RTP packet has the header
> extension, or not? Or will this be called for every single RTP packet (that
> would be a lot of overhead)?

No, the ntp-time field only exists for in-band synchronization.  Currently,
this is only called when the first in-band timestamp is provided, as per spec
RTCP is still required (in fact the 56 bit mode won't work until the first
RTCP).  If we wanted to work entirely without RTCP we should set a timer or
something to trigger in-band synchronization periodically.

> 0xA / 0xB are not really reserved for this but could also be used for other
> header extensions, or not? Isn't this usually negotiated over the SDP?

I'm not sure.  I assumed so, at least looking at section 3.3.  I don't know if
these values can be configured through SDP, section 3.3 only mentions
urn:ietf:params:rtp-hdrext:ntp-64 and urn:ietf:params:rtp-hdrext:ntp-56

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