GNOME Bugzilla – Bug 777224
rtspsrc: unable to receive data using select-stream
Last modified: 2017-01-26 13:59:22 UTC
Created attachment 343443 [details] gstlogs rtspsrc is unable to receive data in tcp mode if the rtsp server has multiple stream and an app setup only some streams using select-stream signal. Please take a look at the attacched logs, the rtsp server has 3 media: audio,video and metadata audio and metadata are disabled by signal and video is enabled, rtsp SETUP for video is correctly done but the received data is ignored. This use case works fine in udp mode and if no stream is disabled by signal, the problem happen only using rtsp over tcp if some medias are not selected and only with some rtsp server, I have no time to do a proper investigation now but I suspect that the problem happen because the first declared media (audio) is disabled, for rtsp server that declare video (not disabled by signal) before audio works fine
Created attachment 343444 [details] wireshark capture
what happen here is that when new data is received over tcp we have these streams: audio (no setup done): stream id 0 channelpad[0] (nil) channel[0] 0 setup 0 video (setup done): stream id 1 channelpad[0] 0x2259b70 channel[0] 0 setup 1 metadata (no setup done): stream id 2 channelpad[0] (nil) channel[0] 0 setup 0 find_stream_by_channel here: https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtsp/gstrtspsrc.c#n4372 is called with channel 0 and it returns the audio stream that have no outpad, a quick solution is to check if setup is done in find_stream_by_channel since find_stream_by_channel is used only for rtsp over tcp should not break anything
Created attachment 344040 [details] [review] proposed fix
this is the same bug reported here https://bugzilla.gnome.org/show_bug.cgi?id=777101
Ah sorry, I missed this one and only saw the other one popping up in my mails. *** This bug has been marked as a duplicate of bug 777101 ***