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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #2 from Joakim Johansson <Joakim.Johansson at 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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.