GNOME Bugzilla – Bug 715078
Critical message when second consumer connects to shared RTSP media factory
Last modified: 2013-11-28 18:05:25 UTC
gst-rtsp-server is built from git revision 33c4bdfa01c8db82e1dd50c1b43cb637dea2d103 (of Nov 18, 2013). Gstreamer and everything is 1.2.0. To reproduce it, you can use the code given below (derived from https://github.com/RidgeRun/eval-sdk-imx6/blob/master/myapps/rr-rtsp-server/src/src/rr_rtsp_server.c , slightly updated to succeed compilation, also changed port to 8554). I start it, then i start a client process with "ffmpeg rtsp://localhost:8554/test". It works. Then i start one more client process with same ffmpeg command, and critical message appears: GStreamer-CRITICAL **: gst_mini_object_unref: assertion `mini_object->refcount > 0' failed If i don't set G_DEBUG=fatal_criticals, the second client likely receives media stream OK. This critical message does not appear when i omit the line gst_rtsp_media_factory_set_shared(factory, TRUE); I'd be grateful for at least the explanation of what that means. Code: https://gist.github.com/krieger-od/7618457 Command line and output: https://gist.github.com/krieger-od/7618491 GDB info: https://gist.github.com/krieger-od/7618508
In a case of two or more concurrent consumers, such RTSP server leaks file descriptors. With fast-reconnecting script instances like below, and monitoring /proc/$SERVER_PID/fdinfo contents, you may monitor it. I=0; while true; do I=$(( I + 1 )); echo -e "\n\n\nI=$I\n\n\n"; DISPLAY=:0 ffmpeg -i rtsp://localhost:8554/test -t 5 -codec copy -f null /dev/null -y; sleep 1; done
The reason is that ffmpeg sends a dummy RTP packet to the RTSP server with SSRC of 0 (and all other fields 0 too). When you start 2 clients, this causes a collision on the server because now there are 2 clients with the same SSRC and different IP:port pairs. There is a bug in the code to deal with the collision that got fixed with this commit: commit e8edecc56eb71d88a89a953489ba55a946a926ec Author: Wim Taymans <wtaymans@redhat.com> Date: Thu Nov 28 16:50:42 2013 +0100 rtpsession: don't unref buffer twice Cleaning the packet info will already unref the buffer. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=715078
Fix confirmed, thanks. Opened another ticked for FD leak issue: https://bugzilla.gnome.org/show_bug.cgi?id=719506