[Bug 732644] New: RTSP PLAY with specified range replies with wrong range

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=732644
  GStreamer | gst-rtsp-server | git

           Summary: RTSP PLAY with specified range replies with wrong
                    range
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-rtsp-server
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: linus.svensson at axis.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


An RTSP PLAY with specified range replies with wrong range if this is not the
first RTSP PLAY for the session and the requested range's start position is
earlier than the current position in the RTSPMedia.

It can be reproduced with gst-rtsp-server/examples/test-ogg. I created an
.ogg-file with both audio (vorbis encoded) and video (theora encoded) as
described in gst-plugins-base/ext/ogg/README

Steps to reproduce:
1. Create an .ogg file
2. Start the RTSP server (./test-ogg test.ogg)
3. Connect to the server ( rtsp://127.0.0.1:8554/test ). I used totem for this
4. Let it play for 10 seconds and then pause it
5. Seek backwards in the playback (move the cursor in totem) and play again.

The fifth step will trigger an RTSP PLAY response with a range with a start
position ~10 seconds.


I have made some observations that can be useful when debugging this. When the
server serves a PLAY request with a range, it will first do a flushing seek on
the pipeline to the requested position, wait until preroll, and then do a query
position when constructing the the RTSP PLAY response. The seek on the pipeline
seems to work just fine, at least for RTP buffers. The multiudpsinks
corresponding to the RTP stream get the position as requested in the seek. But
all sinks does not get updated with the position being seeked to, I suspect
that the multiudpsinks for the RTCP stream still got the same position as they
had before the seek.

I used GST_DEBUG=basesink:5 to look at how the sinks responded to position
queries. Then I noticed that some sinks got an updated position, while some
where not updated. I suspect that the difference for the updated and
non-updated sinks is if they are used for RTP or RTCP packets. The sinks used
for RTCP has "async" property set to FALSE.

I also tried to do an RTSP PLAY with a range header as the first PLAY request
in a session and then the reply looked ok, but the internal behavior in the
pipeline was the same, except that the the sinks (RTCP-sinks?) had not seen any
buffers yet and could therefore not answer a position query.

Maybe the RTCP multiudpsinks don't get flushed when we seek? I don't see any
FLUSH_START/FLUSH_STOP events arriving at the multiudpsinks. If so I guess that
something should be fixed in rtpbin/rtpsession.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.