[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