[Bug 657221] Bug with clock dv

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Sep 2 02:25:51 PDT 2011

  GStreamer | gst-plugins-good | git

--- Comment #3 from anthony <anthony.violo at ubicast.eu> 2011-09-02 09:25:37 UTC ---
I found an interesting information
In function gst_1394_clock_get_internal_time of gst1394clock.c file, i added an
usleep of 200 microseconds to see the behavior.
    GST_OBJECT_LOCK (clock);
    raw1394_read_cycle_timer (_1394clock->handle, &cycle_timer, &local_time);

    if (cycle_timer < _1394clock->cycle_timer_lo) {
      GST_LOG_OBJECT (clock, "overflow %u to %u",
          _1394clock->cycle_timer_lo, cycle_timer);

    _1394clock->cycle_timer_lo = cycle_timer;

    /* get the seconds from the cycleSeconds counter */
    result = (((((guint64) _1394clock->cycle_timer_hi) << 32) |
            cycle_timer) >> 25) * GST_SECOND;
    /* add the microseconds from the cycleCount counter */
    result += (((cycle_timer >> 12) & 0x1fff) * 125) * GST_USECOND;
    usleep (200);
    GST_LOG_OBJECT (clock, "result %" GST_TIME_FORMAT, GST_TIME_ARGS (result));
    GST_OBJECT_UNLOCK (clock);
I notice when I added usleep, the clock seems worked perfectly.
I'm running the same pipeline for 1:30 while before she rans only 10 minutes.
I know that adding an usleep function is not something good.
What could be doing to replace it?
Is that the problem is hardware or software (gstreamer plugin)?
I hope this information will help you.

Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- 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