GNOME Bugzilla – Bug 732644
RTSP PLAY with specified range replies with wrong range
Last modified: 2014-08-13 11:56:52 UTC
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.
While looking into this, bug #646167 is also an obstacle... and stream-time reporting is completely off when seeking. There's more to fix here on the client side (rtspsrc) here too.
The problem here is indeed that the RTCP pipeline part of rtpsession is not flushed when it receives flush events, thus always continuing to count the time. Just flushing them does not seem like a solution though, nothing is preventing any client to send further RTCP data between flush-start and flush-stop. And then that RTCP pipeline part would shut down and never start again.
Created attachment 282569 [details] [review] rtsp-media: Query position and stop time only on the RTP parts of the pipeline The RTCP parts, in specific the RTCP udpsinks, are not flushed when seeking and will always continue counting the time. This leads to the NPT after a backwards seek to be something completely different to the actual seek position.
commit 6ba5ca447f40bc05ac74c2ab805d1ce9cf77797a Author: Sebastian Dröge <sebastian@centricular.com> Date: Tue Aug 5 16:12:19 2014 +0200 rtsp-media: Query position and stop time only on the RTP parts of the pipeline The RTCP parts, in specific the RTCP udpsinks, are not flushed when seeking and will always continue counting the time. This leads to the NPT after a backwards seek to be something completely different to the actual seek position. https://bugzilla.gnome.org/show_bug.cgi?id=732644