After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769979 - Possible race condition when fetching rtp info
Possible race condition when fetching rtp info
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-08-16 12:40 UTC by Joakim Johansson
Modified: 2018-11-03 15:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Solution for race condition (1.32 KB, patch)
2016-08-16 12:58 UTC, Joakim Johansson
none Details | Review

Description Joakim Johansson 2016-08-16 12:40:35 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.
Comment 1 Joakim Johansson 2016-08-16 12:58:48 UTC
Created attachment 333408 [details] [review]
Solution for race condition
Comment 2 Joakim Johansson 2016-08-17 08:30:42 UTC
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.
Comment 3 GStreamer system administrator 2018-11-03 15:40:08 UTC
-- 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.