GNOME Bugzilla – Bug 788294
rtspsrc: allow sending keep-alive in shorter intervals
Last modified: 2018-11-03 15:22:32 UTC
Dear all, I am experiencing an annoying issue when trying to stream a h264 video from an IP camera over RTSP. I am using the following pipeline to stream the video to a videosink window: gst-launch-1.0 rtspsrc location="rtsp://192.168.0.100/live2.sdp" latency=0 do-rtcp=1 do-rtsp-keep-alive=1 debug=1 ! rtph264depay ! h264parse ! avdec_h264 ! autovideosink This pipeline works well but after, approximately, 60 secs, the server (IP camera) disconnects my client (i.e. the aforementioned pipeline) with the following message: gstrtspsrc.c(4726): gst_rtspsrc_loop_udp (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: The server closed the connection. By taking a look at the wireshark capture file, I noticed that the get param packet to keep the connection alive (according to RTCP protocol) is not sent by my pipeline. You can find the wireshark capture and a small log in this GDrive folder: https://drive.google.com/drive/folders/0B_a9LRsqB6MfRTl3SE1TcmRzVXc?usp=sharing Thank you for your support. Best, AP
I uploaded a full log into the same GDrive folder. It is recorded from another session but with the same result. It is a compressed tar.bz2 30MB archive. AP
Created attachment 360659 [details] Packet Capture - Gstreamer
Created attachment 360660 [details] Packet Capture - VLC
I compared sessions created by gstreamer and vlc because the latter framework seems to manage the rtsp session successfully. The main differences is that vlc sends a keep_alive get_parameter just after the server reply to the play message.
It looks as if your server is timing out earlier than it advertises. It advertises a timeout=70 (seconds) and closes the connection at 60 seconds after the last communication. GStreamer has an algorithm that sends the keep-alive just a few seconds before the advertised timeout. In this case, it tries to send a keep-alive every 65 seconds, but this is just too late for your server. VLC seems to have a different algorithm and first of all sends a keep-alive right after the PLAY command (which is not required). I guess (it doesn't show from your log, because you've stopped it), that it goes on sending a keep-alive at its own pace, way earlier than the advertised server timeout, which is probably why it works with VLC.
(In reply to George Kiagiadakis from comment #5) > It looks as if your server is timing out earlier than it advertises. It > advertises a timeout=70 (seconds) and closes the connection at 60 seconds > after the last communication. GStreamer has an algorithm that sends the > keep-alive just a few seconds before the advertised timeout. In this case, > it tries to send a keep-alive every 65 seconds, but this is just too late > for your server. Yes. > > VLC seems to have a different algorithm and first of all sends a keep-alive > right after the PLAY command (which is not required). I guess (it doesn't > show from your log, because you've stopped it), that it goes on sending a > keep-alive at its own pace, way earlier than the advertised server timeout, > which is probably why it works with VLC. Yes, it behaves exactly as you described. Just for the record, my server is an IP Vivotek camera. Through its interface, the timeout parameter (or its source) cannot be modified. I had to modify my application to send a keep alive just after the camera connection (I used the code in gstrtspsrc.c send_keep_alive() ). The issue is caused by the server. Closing the bug. Thank you for your support. AP
(In reply to a.priolo from comment #6) > The issue is caused by the server. Closing the bug. Thank you for your > support. Indeed, this is a server bug, but maybe it makes sense to introduce some property in rtspsrc that allows changing the keep-alive interval in order to work-around buggy servers...
(In reply to George Kiagiadakis from comment #7) > (In reply to a.priolo from comment #6) > > The issue is caused by the server. Closing the bug. Thank you for your > > support. > > Indeed, this is a server bug, but maybe it makes sense to introduce some > property in rtspsrc that allows changing the keep-alive interval in order to > work-around buggy servers... Or, at least, an option to send the keep alive just after the PLAY command to reset the server timer. Does it make sense to reopen the bug?
I think so...
Maybe you should be aware of this bug too, https://bugzilla.gnome.org/show_bug.cgi?id=744209
-- 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-plugins-good/issues/407.