[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