Please describe the problem:
Rtspsrc sends PAUSE method when I pause the pipeline and sends PLAY method when I replay the pipeline. The rtsp server will generate a new seqnumbase and rtptimebase in the response of PLAY request. For example:

================================================
RTSP response message 0xbfff6804
 status line:
   code:   '200'
   reason: 'OK'
   version: '1.0'
 headers:
   key: 'Session', value: '3f48abf7;timeout=90'
   key: 'Range', value: 'npt=21.666-32.100'
   key: 'RTP-Info', value:
'url=rtsp://bfug.rtsp-youtube.l.google.com/CkILENy73wIaOQkbtZ8lPb6RIxMYDSANFEIJbXYtZ29vZ2xlSARSBWluZGV4Wg5DbGlja1RodW1ibmFpbGDGp_3rBww=/0/0/0/video.3gp/trackID=0;seq=33714;rtptime=81371322,url=rtsp://bfug.rtsp-youtube.l.google.com/CkILENy73wIaOQkbtZ8lPb6RIxMYDSANFEIJbXYtZ29vZ2xlSARSBWluZGV4Wg5DbGlja1RodW1ibmFpbGDGp_3rBww=/0/0/0/video.3gp/trackID=1;seq=3724;rtptime=46395124'
   key: 'CSeq', value: '8'
   key: 'Server', value: 'Google RTSP 1.0'
 body: length 0
================================================

Rtspsrc will parse the response, configure the caps and forward to the downstream elements. When the caps received by gstrtpjitterbuffer, it will check out the `seqnum-base' field and udpate the `next_seqnum' -- this is in function `gst_jitter_buffer_sink_parse_caps'. The code snippet is:

================================================
  /* first expected seqnum */
  if (gst_structure_get_uint (caps_struct, "seqnum-base", &val))
      priv->next_seqnum = val;
  else
    priv->next_seqnum = -1;

  GST_DEBUG_OBJECT (jitterbuffer, "got seqnum-base %d", priv->next_seqnum);
================================================

The problem is: the gstrtpjitterbuffer uses `next_seqnum' to judge whether the packet is `late'. When I pause the pipeline then replay it, the seqnum-base which responsed from rtsp server maybe is not continuous with the last packet we played. If the seqnum-base rtsp server responsed is greater than the seqnum we played, the packets which seqnum are between the last played and the current seqnum-base will all be dropped. -- This makes the audio/video freezes.

If I execute a seek action, this logic is correct because during the seek action, the FLUSH action will also be executed, this makes all the packets we cached unavailable.

Now, I modifed the codes list above a little bit to solve this problem:

================================================
  /* first expected seqnum */
  if (gst_structure_get_uint (caps_struct, "seqnum-base", &val))
  /* Added by Eric   BEGIN */
  {
    if (priv->next_seqnum == -1) {
      priv->next_seqnum = val;
    }
  }
  /* Added by Eric   BEGIN */
  else
    priv->next_seqnum = -1;

  GST_DEBUG_OBJECT (jitterbuffer, "got seqnum-base %d", priv->next_seqnum);
================================================

next_seqnum will be set to -1 if FLUSH stop event received. So update the next_seqnum is required. At other time, it is not necessary to update the next_seqnum.


Steps to reproduce:
Write a rtsp player, then pause/play the pipeline repeatedly

Actual results:


Expected results:


Does this happen every time?
No. It happens randomly.

Other information: