[Bug 763325] New: Multiple netclocks do not work anymore
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue Mar 8 14:26:01 UTC 2016
https://bugzilla.gnome.org/show_bug.cgi?id=763325
Bug ID: 763325
Summary: Multiple netclocks do not work anymore
Classification: Platform
Product: GStreamer
Version: 1.7.90
OS: All
Status: NEW
Severity: blocker
Priority: Normal
Component: gstreamer (core)
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: xartigas.bugzilla at gmail.com
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Created attachment 323398
--> https://bugzilla.gnome.org/attachment.cgi?id=323398&action=edit
Debug output
On 1.6.1 this used to work, and does not work anymore on 1.7.90.
My setup has two different GstNetClientClock, on two different Pipelines,
running in the same application, synchronizing to the same remote master clock
(gst-rtsp-server's test-netclock server).
Both clocks share the same internal clock, which is fine.
The attached debug output combines GST_DEBUG=2,netclock:7 with output from the
program, including the PTS of all buffers received at the sinks plus the
current clock at the time (gst_clock_get_time).
As can be seen from the debug output, both clocks start at 0, and so does the
remote clock.
After a while, the remote clock jumps to the actual remote clock value.
After a bit more, one of the clocks slaves to the remote clock, but the other
does not, and stalls.
On 1.6.1, all clocks stayed close to zero (which is probably wrong), but both
pipelines run happily.
I am currently working on a smaller test case that reproduces the issue.
--
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