[Bug 793513] New: rtpbin, jitterbuffer: ts-offset on RFC7273 synchronized streams

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Feb 16 14:19:40 UTC 2018


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

            Bug ID: 793513
           Summary: rtpbin, jitterbuffer: ts-offset on RFC7273
                    synchronized streams
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: m.tretter at pengutronix.de
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

The rtpbin sets the ts-offset on rtpjitterbuffer to synchronize multiple SSRC
for one CNAME based on the timestamps in the SR. The offset is added to the
buffer pts after the pts has been calculated from the rtptime.

However, I use RFC7273 to already synchronize RTP streams between multiple
clients and the rtpjitterbuffers already calculate a synchronized pts. The
additional offset breaks the synchronization again. Therefore, I don't want the
rtpbin to add a ts-offset to the streams if the pts is already in sync.

I added a check in the rtpbin, if rfc7273-sync is set and skip the
synchronization in these cases and with this change, my streams are in sync.
However this is not really a fix, because the rfc7273-sync can be also set if
the SDP does not announce an RFC7273 clock. In this case, the rtpbin should
synchronize the streams.

If there is only one SSRC, there not an issue, because then the rtpbin does not
add the offset, but I want separate streams for audio and video to avoid the
additional latency for muxing and demuxing.

Maybe we can add a property to the rtpjitterbuffer if the produced pts are
already synchronous to a wall clock or if the rtpbin should take care of
synchronization.

Any thoughts?

-- 
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