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 677475 - Delay in play-pause-play
Delay in play-pause-play
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
Other Windows
: Normal minor
: 0.11.x
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2012-06-05 15:09 UTC by Maria Giovanna Chiossa
Modified: 2012-06-07 10:13 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Maria Giovanna Chiossa 2012-06-05 15:09:10 UTC
I experimented a very annoying delay when doing a play-pause-play command sequence when playing from rtsp (rtsp-server). 
I see the server immediately restart sending packets but the client start showing frames after 5-10 sec.
I verified also that  if I comment in gstrtspjitterbuffer.c in gst_rtp_jitter_buffer_clear_pt_map these 2 instructions:
  rtp_jitter_buffer_reset_skew (priv->jbuf);
  priv->next_seqnum = -1;
the client restart playing is instantaneously.
So, how to fix this issue? 
I find out that the gst_rtp_jitter_buffer_clear_pt_map call is caused by gst_rtspsrc_configure_caps (src, segment); called in gst_rtspsrc_play
Should gst_rtspsrc avoid to call gst_rtspsrc_configure_caps when not strictly needed?
Or should jitterbuffer check in gst_rtp_jitter_buffer_clear_pt_map if reset all? (I tried this solution, apparently seems to work, but it is not very smart...)
Or could you suggest a better way?
Thank you very much
Comment 1 Wim Taymans 2012-06-07 10:13:42 UTC
commit eb982e4bbea159b0f9247f2649ca5327581cd788
Author: Wim Taymans <>
Date:   Thu Jun 7 12:11:14 2012 +0200

    rtspsrc: only reset the manager object when we did a seek
    Only reset the manager object when we used a Range header, ie. when we did a
    seek. Otherwise we just paused and we can resume just fine.