GNOME Bugzilla – Bug 116618
desynchronized clock?
Last modified: 2004-12-22 21:47:04 UTC
It seems that the GstClock object given by gst_bin_get_clock() has its time property desynchronized after 3 seconds. I have hacked a bit the file "testsuite/clock/clock1.c" to produce this weird behaviour (attachement is following). I selected 'core' as the bug component, but maybe it's a bug in the gstelements plugin, I don't know. It has been tested on FreeBSD 5.1 with GStreamer 0.6.2. I will try on my Linux box as well as soon as possible.
Created attachment 17998 [details] test case
Here is the output of the test case execution: pinux@natalie ~/tmp> ./clock INFO (26636: 0) Initializing GStreamer Core Library version 0.6.2 INFO (26636: 0) CPU features: (00000000) MMX SSE INFO (26636: 0) registry: loaded global_registry in 0.207785 seconds (/usr/X11R6/share/gnome/cache/gstreamer-0.6/registry.xml) Clock info: speed 1.000000, active no, time 0 Clock info: speed 1.000000, active no, time 0 Clock info: speed 1.000000, active yes, time 1007493000 Clock info: speed 1.000000, active yes, time 2017315000 Clock info: speed 1.000000, active yes, time -1267634296 Clock info: speed 1.000000, active yes, time -257619296 Clock info: speed 1.000000, active yes, time 752402704 Clock info: speed 1.000000, active yes, time 1762407704 Clock info: speed 1.000000, active yes, time -1522543592 Clock info: speed 1.000000, active yes, time -512522592 Clock info: speed 1.000000, active yes, time 497485408 Clock info: speed 1.000000, active yes, time 1507503408
It's an integer overflow. Use guint64. ;). The maximum value of a gint is 2^31, that being rightly around 2,1M. After that, it flips back to its minimum value, that being around -2,1M. From there, it increases again and goes its cycle around again. Since we measure time in nanoseconds, one second is already approximately 2^30. Two seconds can barely be hold in one gint, and three seconds is far too much. I don't think the clock is broken, your test case simply can't hold it. To fix this, use %ulld (on 32bit platforms) or %uld (on 64bit platforms), this can also be typed as G_GUINT64_FORMAT (a glib macro for this), and don't cast the return value to an integer in g_print(). Then, it should work. If it doesn't please reopen. For now, I'll mark this as a non-bug.
You're right, sorry to have posted this stupid think, I should have noticed it before ;-) BTW, it seems that %uld | %ulld don't work on my system, but %llu (~G_GUINT64_FORMAT) does. Maybe it's related to the BSD C library. Anyway, thank you for your fast feedback.