[Bug 770133] New: Out of segment data sent to clients when not wanted

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770133

Bug ID: 770133
Summary: Out of segment data sent to clients when not wanted
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-rtsp-server
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@axis.com
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---

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?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770133

Joakim Johansson <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@axis.com

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770133

--- Comment #1 from Joakim Johansson <***@axis.com> ---
Created attachment 334224
--> https://bugzilla.gnome.org/attachment.cgi?id=334224&action=edit
Drop buffers outside segment

This patch drops all buffers that are outside the segment.

This solves the problem with the call to gst_segment_to_stream_time that
returns GST_CLOCK_TIME_NONE for a buffer that is outside the segment.

This can happen if an empty PLAY request is received (after PAUSE).

The result in that scenario is a empty RTP-Info is being sent which is solved
with this patch.

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770133

--- Comment #2 from Joakim Johansson <***@axis.com> ---
Hi,

I heard from Linus which talked with Slomo during the Gstreamer conference that
there where some discussions of removing Accurate Seek functionality and
instead use KeyUnit Seek.

I have done a quick test of using KeyUnit for this use case that we have
problem with:

1) Play with a Range

2) Pause

3) Empty Play requested

Since it is a onvif stream do we want to update the extension headers of
buffers that are still in queue and therefore forces a seek from the
application with no range set which today triggers the accurate seek (but in
this test changed to keyunit seek).

Comparing Accurate and KeyUnit:

Accurate seek does not work onfly because there will be segment data before the
start position which will result in the error print “Failed to get stream time”
in gstrtponviftimestamp which means that the buffers are sent without valid
time information.

This is solved with a patch provided with this bugzilla case which drops all
buffers before the accurate position (in my test was 18 buffers dropped) but
this is data that the client have already received before the Pause command and
this should be correct.

KeyUnit seek does not need any dropping functionality but in the tests that I
have done will the empty play request cause a jump back between 0.6s – 1.2s
(this can be a much larger jump depending on how frequent the I-frames is
coming).

I see a couple of problems with KeyUnit approach:
1) The application might not like to receive an old chunk of data again, worst
case is the same data played twice (if not dropped by application)
2) Does KeyUnit approach follow the specification?

Important parts of the specification: rfc2326

A PLAY request without a Range header is legal. It starts playing a stream from
the beginning unless the stream has been paused. If a stream has been paused
via PAUSE, stream delivery resumes at the pause point. If a stream is playing,
such a PLAY request causes no further action and can be used by the client to
test server liveness.

Any server resources are kept, though servers MAY close the session and free
resources after being paused for the duration specified with the timeout
parameter of the Session header in the SETUP message.

If the Range header is missing, stream delivery is interrupted immediately on
receipt of the message and the pause point is set to the current normal play
time.

A PAUSE request discards all queued PLAY requests. However, the pause point in
the media stream MUST be maintained. A subsequent PLAY request without Range
header resumes from the pause point.

My opinion is that KeyUnit Seek will not follow the specification because the
pause point will not be maintained and used when resuming after the empty play
request.


While testing have I also seen one more thing that looks strange:

1) Play with a Range

2) Play with a new Range (seek)

In step 2 are the rtptimestamp (received from gstrtpbasepayload) reset and the
same rtptimestamp are re-used again (but the correct data is handled)

This is because gstrtpbasepayload set a ts_base when the element is going from
ready to paused and then is there a running clock that is added to the base to
get the rtptimestamp for each buffer.

But the running time is reset at the seek operation so the same timestamps are
“re-used”.

Is this according to the specifications?

This is taken from Appendix B: Interaction with RTP (rfc2326)

As an example, assume a clock frequency of 8000 Hz, a packetization
interval of 100 ms and an initial sequence number and timestamp of
zero. First we play NPT 10 through 15, then skip ahead and play NPT
18 through 20. The first segment is presented as RTP packets with
sequence numbers 0 through 49 and timestamp 0 through 39,200. The
second segment consists of RTP packets with sequence number 50
through 69, with timestamps 40,000 through 55,200.

Should the ts_base be set to last rtptimestamp when performing the seek and
then reset the running clock?

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770133

--- Comment #3 from Joakim Johansson <***@axis.com> ---
Please review or comment

["GStreamer" (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770133

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #4 from GStreamer system administrator <***@gstreamer.net> ---
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been
closed from further activity.

You can subscribe and participate further through the new bug through this link
to our GitLab instance:
https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/25.