[gstreamer-bugs] [Bug 561627] New: Audio/Video freezes randomly if I pause then play the pipeline(rtsp)

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=561627

  GStreamer | gst-plugins-bad | Ver: 0.10.20
           Summary: Audio/Video freezes randomly if I pause then play the
                    pipeline(rtsp)
           Product: GStreamer
           Version: 0.10.20
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: chao.zhang at access-company.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: 2.21/2.22
   GNOME milestone: Unspecified


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:


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=561627.