[gstreamer-bugs] [Bug 561625] New: Rtspsrc set segment's last_stop incorrectly

[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=561625

  GStreamer | gst-plugins-good | Ver: 0.10.20
           Summary: Rtspsrc set segment's last_stop incorrectly
           Product: GStreamer
           Version: 0.10.20
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-good
        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 implements `seek' feature by sending a `PLAY' method with a `Range'
header. When I play the rtsp movie in m.youtube.com, I find out the range
header in youtube server's reponse doesn't match the range which we requested.
For example, If rtspsrc sends a PLAY method like this:

==========================================================
RTSP request message 0xbfff6820
 request line:
   method: 'PLAY'
   uri:   
'rtsp://bfug.rtsp-youtube.l.google.com/CkYLENy73wIaPQkbtZ8lPb6RIxMYDSANFEIJbXYtZ29vZ2xlSARSBWluZGV4Wg5DbGlja1RodW1ibmFpbGDGp_3r57jP7WMM/0/0/0/video.3gp'
   version: '1.0'
 headers:
   key: 'Range', value: 'npt=23.577449-'
 body:
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
==========================================================

We requested a play range: npt=23.577449-, but the response is:
npt=21.666-32.100. OK, when the rtspsrc sent the PLAY method, it will parse the
response. The function `gst_rtspsrc_parse_range' handles the `range' part.This
function will separate the min and max value in range and call
`gst_segment_set_last_stop' to update the segment's last_stop field using the
min value.

The interest part is in `gst_segment_set_last_stop'. This function updates the
segment's last_stop field in this way:

segment->last_stop = MAX (segment->start, position);

segment->start is 23.57749, and the position is 21.666. So, the result is the
segment's last_stop is 23.57749 while not 21.666.

After parsing the response finished, rtspsrc will call the function
`gst_rtspsrc_configure_caps' and the GstRtpBaseDepayload will send the
newsegment event according to this caps. This will make the newsegment has a
WRONG npt-start value. And this will also cause the POSITION query returns a
wrong value. In my rtsp-player, I noticed that when the progress bar exceeds
100%, the movie is still playing.


Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?
Yes

Other information:
We should set the segment's last_stop to the value youtube server gives. So we
can set the last_stop directly, not calling the `gst_segment_set_last_stop'.


-- 
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=561625.