GNOME Bugzilla – Bug 769979
Possible race condition when fetching rtp info
Last modified: 2018-11-03 15:40:08 UTC
If the application do not send pause before a new play request then is there a possibility for a race condition to occur when fetching the RTP-Info. This is easily triggered by adding a short sleep just before /* grab RTPInfo from the media now */ rtpinfo = gst_rtsp_session_media_get_rtpinfo (sessmedia); in rtsp-client, handle_play_request and then execute two Play requests without a Pause in between. Running a test case executing 10 Play requests with 1s delay between each other triggers this problem 80% of the times (without short sleep) and since the test case is checking the D-bit in the extension header is it mandatory that the RTP Info finds the absolute first rtp package after the play command. The solution is to perform a forced pause if the application have not send a Pause command before the Play command.
Created attachment 333408 [details] [review] Solution for race condition
This patch however violates the RTSP protocol: "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. Ongoing with a new solution that does not violate the protocol.
-- 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/24.