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 797249 - big timestamp jumps create problems in gst_rtp_buffer_ext_timestamp()
big timestamp jumps create problems in gst_rtp_buffer_ext_timestamp()
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.14.x
Other All
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-10-04 13:58 UTC by Alexander Kordecki
Modified: 2018-11-03 12:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Alexander Kordecki 2018-10-04 13:58:48 UTC 
Hi,

the current implementation returns 0 for a large jump and does not change the exttimestamp. So if I intentionally jump > G_MAXINT32 and when my new timestamp is <= G_MAXUINT32, I not only lose the one package with the big jump, but also all following packages.
Comment 1 Alexander Kordecki 2018-10-09 11:52:35 UTC 
If I'm using a pipeline with rtp_jitterbuffer and have a rtp stream with these jumps in the timestamps, sending events to this pipeline hangs until I kill the process.
Comment 2 Sebastian Dröge (slomo) 2018-10-11 12:47:44 UTC 
This looks kind of related to https://bugzilla.gnome.org/show_bug.cgi?id=783443
Comment 3 Kenneth Ekman 2018-10-11 12:58:40 UTC 
I am seeing that some cameras get stuck with RTCP.SR RTP-timestamp stuck close to 0 (below 22000 and above 4294650000) since the gst_rtp_buffer_ext_timestamp() function keeps returning zero in some cases when a new stream is started. 

When this happens the print "Cannot unwrap, any wrapping took place yet. Returning 0 without updating extended timestamp" starts spamming.

Is that anything anyone else has noticed?

Do you have a suggested fix?

(The above comment was also added to 783443)
Comment 4 Alexander Kordecki 2018-10-11 13:13:30 UTC 
(In reply to Alexander Kordecki from comment #1)
> If I'm using a pipeline with rtp_jitterbuffer and have a rtp stream with
> these jumps in the timestamps, sending events to this pipeline hangs until I
> kill the process.

for clarification: hanging of the pipeline doesn't depend on the timestamp problem.
Comment 5 Sebastian Dröge (slomo) 2018-10-27 11:04:16 UTC 
So the timestamp problem is solved now, but there's a separate, independent problem? Can you file a new bug about that hang, with a testcase to reproduce it, etc?
Comment 6 GStreamer system administrator 2018-11-03 12:10:43 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/491.