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 711819 - rtpbuffer: gst_rtp_buffer_ext_timestamp() returns wrong value when compiled with clang 5 on iOS/ARM
rtpbuffer: gst_rtp_buffer_ext_timestamp() returns wrong value when compiled w...
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
Other other
: Normal major
: 1.2.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2013-11-11 07:04 UTC by jacobhameiri
Modified: 2013-11-13 19:16 UTC
See Also:
GNOME target: ---
GNOME version: ---

client full log (878.41 KB, application/zip)
2013-11-11 07:07 UTC, jacobhameiri

Description jacobhameiri 2013-11-11 07:04:02 UTC
Perhaps the problem is a race condition between rtspsrc and the pipeline going to PLAYING (or more specific: setting the base time)
Comment 1 jacobhameiri 2013-11-11 07:07:55 UTC
Created attachment 259526 [details]
client full log
Comment 2 Sebastian Dröge (slomo) 2013-11-11 10:35:08 UTC
Problem here seems that basesink waits for a time that is 26 hours in the future. This seems to be caused by rtpjitterbuffer putting a timestamp on buffers according to base-time 0, while later base-time is set to some large value when the pipeline goes to PLAYING. Or something like that. Later buffers seem to get a correct timestamp by rtpjitterbuffer.
Comment 3 Sebastian Dröge (slomo) 2013-11-13 19:16:00 UTC
commit 76985c5e81bd206439409ed8aa34aedb4ac47fce
Author: Sebastian Dröge <>
Date:   Wed Nov 13 20:12:48 2013 +0100

    rtpbuffer: Fix gst_rtp_buffer_ext_timestamp() with clang 5 on iOS/ARM
    The bitwise NOT operator is not defined on signed integers.
    Thanks to Wim Taymans for finding the cause.