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:
- logs from UDP case sharedMediaUDP.txt
- logs from RTSP tunneling case sharedMediaRtspTunneling.txt
- Wireshark RTSP traffic sharedMediaRTSP.pcapng
I would appreciate any feedback on this.