Skip to content

Problem with shared media if client is requesting streams over separate RTSP sessions

We've encountered a problem with shared media if client is requesting streams over separate RTSP sessions. In that case client will be able to receive only audio or only video stream. From the logs we could see that the stream which is not received by client is left in the blocked state

0:00:15.050728583  5124 0xffff6400f320 DEBUG              rtspmedia rtsp-media.c:2604:media_streams_set_blocked: media 0xffff64038330 set blocked 1
0:00:15.050747208  5124 0xffff6400f320 DEBUG             rtspstream rtsp-stream.c:4980:set_blocked:<GstRTSPStream@0xffff6403e340> blocked: 1
0:00:15.050770957  5124 0xffff6400f320 DEBUG             rtspstream rtsp-stream.c:4980:set_blocked:<GstRTSPStream@0xffff6403e660> blocked: 1

In this case the '0xffff6403e340' stream will be unblocked later on in

0:00:16.924458219  5124 0xffff7000b050 DEBUG              rtspmedia rtsp-media.c:2634:gst_rtsp_media_set_status: setting new status to 2
0:00:16.924476843  5124 0xffff7000b050 DEBUG              rtspmedia rtsp-media.c:2620:media_unblock_linked: media 0xffff64038330 unblocking linked streams
0:00:16.924494593  5124 0xffff7000b050 DEBUG             rtspstream rtsp-stream.c:4980:set_blocked:<GstRTSPStream@0xffff6403e340> blocked: 0

But the 0xffff6403e660 stream will never be unblocked even though the client is properly requesting it over separate RTSP session.

The pipeline looks like this.

appsrc name=onvif-videosrc ! h264parse name=onvif-parse ! rtph264pay name=pay0 pt=96 
appsrc name=onvif-audiosrc ! audioconvert name=onvif-audioconvert ! audioresample name=onvif-audioresample ! mulawenc name=onvif-mulawenc ! rtppcmupay name=pay1 pt=97

And the factory is set to shared and has GST_TYPE_RTSP_ONVIF_MEDIA type.

gst_rtsp_media_factory_set_shared (onvifFactory, TRUE);
gst_rtsp_media_factory_set_media_gtype (onvifFactory, GST_TYPE_RTSP_ONVIF_MEDIA);

For UDP case the attached patch (based on 1.16.2) is working and both audio and video can be received by the client, but RTSP tunneling case is not working 0001-Ensure-that-stream-is-unblocked-when-new-client-is-r.patch. I suppose that there's a more elegant way to solve this. If we are not using shared media this is working ok too.

Also attached are:

I would appreciate any feedback on this.

Edited by Mihael Brenko