After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 116618 - desynchronized clock?
desynchronized clock?
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.6.2
Other FreeBSD
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-07-03 09:42 UTC by Laurent Sansonetti
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case (1.82 KB, text/plain)
2003-07-03 09:54 UTC, Laurent Sansonetti
Details

Description Laurent Sansonetti 2003-07-03 09:42:54 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.
Comment 1 Laurent Sansonetti 2003-07-03 09:54:24 UTC
Created attachment 17998 [details]
test case
Comment 2 Laurent Sansonetti 2003-07-03 09:55:57 UTC
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
Comment 3 Ronald Bultje 2003-07-03 11:15:42 UTC
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.
Comment 4 Laurent Sansonetti 2003-07-03 12:32:59 UTC
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.