[Bug 783443] rtp: fix gst_rtp_buffer_ext_timestamp taking into account backwards

[GStreamer (GNOME Bugzilla)]

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

Linus Svensson <linus.svensson at axis.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |linus.svensson at axis.com

--- Comment #20 from Linus Svensson <linus.svensson at axis.com> ---
It is possible to set the suspend mode for a rtsp-media in gst-rtsp-server and
that is something we do for live pipelines. We use a suspend mode called reset,
which will set the state of the pipeline to NULL (It was introduced to get rid
of of the preroll buffers produced in RTSP DESCRIBE).

The RTP timestamp of the first buffer is based on a random offset, which is
generated when rtp*pay goes from READY to PAUSED (it is possible to configure
this manually). The RTP buffer generated in DESCRIBE and the one from PLAY have
RTP timestamps. If the two timestamps differ too much,
gst_rtp_buffer_ext_timestamp() will fail and return 0 (0 will then be kept and
used as input for the next buffer, and the problem will occur for the next
buffer as well).

To me the problem appears to be that the timestamp generated in DESCRIBE is
still kept in RTPSource (stored in RTPSource.last_rtptime). GstRtpSession will
not reset it's internal RTPSession object when the pipeline goes to READY.

I think the solution should be to 
1) reset last_rtptime in RTPSource when GstRtpSession goes from PAUSED to
READY, or
2) manually configure the timestamp offset for rtp*pay.

To me option 1) sound better. Any other opinions?

Anyway, I don't think the merged patch is wrong, it just exposed another
problem.

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