Out of segment data sent to clients when not wanted
Submitted by Linus Svensson
Link to original bug (#770133)
Description
gst-rtsp-server sometimes sends buffers that are outside the current segment (before the segment in this case), when it performs a seek.
The problem appears if a client issues an RTSP PLAY (without specifying a new start position) when the server is PAUSED at a delta unit in the stream, and the RTSP PLAY method requires the server to perform a seek. A seek will be required; if the stop position is updated (Range: npt=135.42), scale or speed is changed (currently not supported though), or something else that's updated with a seek. The server always performs a FLUSHING seek, but that is unfortunate since we want to keep the current position in case the start position isn't changed. GstRTSPMedia will actually seek to the current position (obtained with a gst_query_position on the pipeline) and set GST_SEEK_FLAG_ACCURATE in such case. The result (in a use case with a H.264 stream contained a matroska file) from such seek is that the segment will have a start time matching the seek'ed start position and the first buffer will be the previous non-delta unit in the stream (That's of course good :)), which results in an RTP stream starting at position X, and the Range in the RTSP PLAY response is position X + the delta between the seek'ed position and the non-delta unit. In this case the connected client already have received all frames until the delta frame at the seek'ed position.
Would it make sense to drop all buffers outside of the segment in GstRtpBasePayload, or make it configurable to do so?