GNOME Bugzilla – Bug 622588
thread problem in rtspsrc
Last modified: 2012-03-07 14:23:38 UTC
Hi, I try to connect to an rtsp server with 16 rtspsrc. When I change them to PLAYING one at a time, everything is fine. But when I try to change all of the source's states to PLAYING simultaneously, only 10-12 of them start receiving rtp data, the rest goes to timeout. The sources are in different pipelines (1 source per pipeline). I made the test with a shell script like this: gst-launch rtspsrc location="..." timeout=30000000 ! rtph264depay ! h264parse ! ffdec_h264 ! xvimagesink & gst-launch rtspsrc location="..." timeout=30000000 ! rtph264depay ! h264parse ! ffdec_h264 ! xvimagesink & gst-launch rtspsrc location="..." timeout=30000000 ! rtph264depay ! h264parse ! ffdec_h264 ! xvimagesink & ... ... The locations are different for each rtspsrc. I think it's a kind of thread problem because in one test case 10 source can start, in other 11 or 12 (it's random). If I put the rtspsrcs into one pipeline, and set the pipeline's state to PLAYING, it's works too, but in this case the sources aren't start simultaneously. Any ideas? Regards Tibor
Do you have a small test program or shell/python script to easily reproduce this ?
Created attachment 167402 [details] test
First of all you need at least 16 rtsp uri (i used a video recorder server for that), then replace the rtsp uris in the attached file above and run it. On my computer only started 10-12 of the 16 pipelines. I noticed the following: if i take care of the sources start only one in a time (with a synchronized block or something else) in an application, than it's work fine, but when i remove the block than the result is the same as the running the shell script.
Maybe this could be caused by the UDP port reuse bug that was fixed recently, see Bug #622017. Can you try this with latest git?
It still fails me with the latest git :( Have you any other ideas?
any news with this? it's still not working in the latest release...
I found something that maybe cause this problem. In my application I watch a lot of h264 encoded stream and sometimes it crashed at plugin loading: 0:00:28.024064013 [331m10992 [00m 0x8e37d20 [37mLOG [00m [00;01;36m GST_PLUGIN_LOADING gstplugin.c:782:gst_plugin_load_file: [00m Plugin 0x92640800 for file "/usr/lib/gstreamer-0.10/libgstrtsp.so" prepared, registering... 0:00:28.024091155 [331m10992 [00m 0x8e37d20 [37mLOG [00m [00;01;36m GST_PLUGIN_LOADING gstplugin.c:538:gst_plugin_register_func: [00m plugin "/usr/lib/gstreamer-0.10/libgstrtsp.so" looks good ERROR: Caught a segmentation fault while loading plugin file: /usr/lib/gstreamer-0.10/libgstrtsp.so I have a similar crashlog with libgstffmpeg.so, too. After that I had the idea to load the elements I'm using at the start of my app. I did this with creating every elements and throwing them away. The goal was to preload the .so files. With this workaround the crashes are gone and all the rtsp streams are showed up. So I think maybe the loading of the plugins is not thread safe: while a thread initializing a plugin, an another thread can use this partially loaded plugin, and the result is crash or some weird behavior. Can this be correct? Regards Tibor
any comment on thread safety and plugin loading?
> sometimes it crashed at plugin loading: > > 0:00:28.024064013 [331m10992 [00m 0x8e37d20 [37mLOG [00m > [00;01;36m GST_PLUGIN_LOADING > gstplugin.c:782:gst_plugin_load_file: [00m Plugin 0x92640800 for file > "/usr/lib/gstreamer-0.10/libgstrtsp.so" prepared, registering... > 0:00:28.024091155 [331m10992 [00m 0x8e37d20 [37mLOG [00m > [00;01;36m GST_PLUGIN_LOADING > gstplugin.c:538:gst_plugin_register_func: [00m plugin > "/usr/lib/gstreamer-0.10/libgstrtsp.so" looks good > > ERROR: Caught a segmentation fault while loading plugin file: > /usr/lib/gstreamer-0.10/libgstrtsp.so > > I have a similar crashlog with libgstffmpeg.so, too. After that I had the idea > to load the elements I'm using at the start of my app. I did this with creating > every elements and throwing them away. The goal was to preload the .so files. > With this workaround the crashes are gone and all the rtsp streams are showed > up. > > So I think maybe the loading of the plugins is not thread safe: while a thread > initializing a plugin, an another thread can use this partially loaded plugin, > and the result is crash or some weird behavior. Can this be correct? That seems unlikely. Plugin loading should be serialised in GStreamer core. Please provide a stack trace for the crash you get during plugin loading. I've just pushed the following fix which may or may not be related: commit 9f042ae224b3d84643bf4ad977080987fe80d36f Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Sat Jan 7 20:12:17 2012 +0000 rtspconnection: make hostname lookup more thread-safe Don't write IP number string to return into a static array which is shared amongst all threads (note: of course a copy is returned). https://bugzilla.gnome.org/show_bug.cgi?id=666711 Setting NEEDINFO for: (a) please re-test with current git and confirm the problem still exists (b) please provide a stack trace of the crash during rtsp plugin loading
Tibor, Levente, can you please provide more information as requested in comment#9 ?
unfortunately we're too busy in this week, and still use the workaround. but next week we'll test the latest release from yesterday.
Closing as incomplete. Please re-open if issues remain with the latest versions.