[Bug 657221] Bug with clock dv
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Fri Sep 2 02:25:51 PDT 2011
https://bugzilla.gnome.org/show_bug.cgi?id=657221
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_hi++;
}
_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