rtpsession: The RTP timestamp in the RTCP Sender Report may be completely wrong
Submitted by Linus Svensson
Link to original bug (#797304)
Description
Created attachment 373962
Reset the RTPSession object in PAUSED->READY
The RTP timestamp used for RTCP Sender Report is generated from a cached extended RTP timestamp, which in turn is updated for every pushed RTP buffer. The timestamp generation does not work with a gst-rtsp-server that uses GST_RTSP_SUSPEND_MODE_RESET.
If the reset suspend mode is used, the server will configure a media and prepare it in RTSP DESCRIBE/SETUP, which will trigger rtpsource to cache an extended RTP timestamp. The pipeline will now be set to GST_STATE_NULL.
In RTSP PLAY, the pipeline will be set to GST_STATE_PLAYING again. A new random offset will be used for the RTP timestamp, but the previously cached extended RTP timestamp in all RTPSource objects remains, which leads to a situation where gst_rtp_buffer_ext_timestamp() sometimes return 0. When this happens, the RTP timestamp in the RTCP Sender Report is completely broken.
I have implemented rtp_session_reset() that will iterate over all it's RTPSource's and reset them. The important part is to clear RTPSource.last_rtptime. Does it make sense to reset the whole RTPSession object?
Patch 373962, "Reset the RTPSession object in PAUSED->READY":
0001-gstrtpsession-Reset-RTP-sources-in-PAUSED-to-READY.patch