GNOME Bugzilla – Bug 610916
rtspsrc dosen't work under windows
Last modified: 2011-06-15 22:43:39 UTC
Hi, I'm using this pipeline under windows: gst-launch rtspsrc location="rtsp://..." debug=1 latency=1000 protocols=1 ! rtpmp4vdepay ! mpeg4videoparse ! ffdec_mpeg4 ! ffmpegcolorspace ! directdrawsink I set the camera to stream 10 seconds then stop the stream, but the rtspsrc can't go into PAUSED state, just 1 minute later. GST_DEBUG=4 said: ... 0:00:05.812500000 rtspsrc gstrtspsrc.c:5210:gst_rtspsrc_pause:<src01> wait for connection idle 0:01:00.921875000 rtspsrc gstrtspsrc.c:5212:gst_rtspsrc_pause:<src01> connection is idle now ... There is 1 minute between the two message... Any ideas why it isn't working properly? Regards
My guess is that something's wrong with rtsp library from -base. Everything that involves I/O is difficult to port to Windows.
is there any change to fix it in the near future?
I'm planning to port all I/O in GStreamer to GPoll (from GstPoll) once GStreamer raises minimal GLib version requirement high enough (which is expected to happen sometime this year). That will most assuredly break something, that is why i will also make sure that the code passes all related unit tests. Which may lead to fixing this bug. Or not. Depends on completeness of rtsp unit tests.
Can you make a debug log with: GST_DEBUG=*rtsp*:5,*rtp*:5,*POLL*:5 gst-launch rtspsrc location="rtsp://..." debug=1 latency=1000 protocols=1 ! rtpmp4vdepay ! mpeg4videoparse ! ffdec_mpeg4 ! ffmpegcolorspace ! directdrawsink >debug.log 2>&1 then compress (like zip, gzip,..) and attach the resulting debug.log file to this bugreport.
Created attachment 155539 [details] test case for Wim output for this pipeline: GST_DEBUG=*rtsp*:5,*rtp*:5,*POLL*:5 gst-launch rtspsrc location="rtsp://..." debug=1 latency=1000 protocols=1 ! rtpmp4vdepay ! mpeg4videoparse ! ffdec_mpeg4 ! ffmpegcolorspace ! directdrawsink >debug.log 2>&1
Hi Wim, is there any progress in the issue?
(In reply to comment #6) > Hi Wim, > > is there any progress in the issue? Not yet. I'll update this report when there is.
Reopening as I guess the requested information has been provided in comment #5.
*** Bug 636893 has been marked as a duplicate of this bug. ***
In our investigation to find the problems on windows withj RTSP we found that the problem is in gst_rtspsrc_close (gstrtspsrc.c:5479) function. It stops at GST_RTSP_STREAM_LOCK (gstrtspsrc.c:5502) and waits until gst_rtspsrc_connection_receive (gstrtspsrc.c:3680) timeouts (the timeout value is 53 seconds). Although there is gst_rtspsrc_loop_send_cmd (src, CMD_STOP, TRUE) (gstrtspsrc.c:5492) the flush command doesn't affects the gst_rtspsrc_connection_receive function but it should stop and return immediately. Anybody how knows the source better can help us why this can happened? thanks in advance.
in file gstpoll.c line 1482 in the flush there is condition: if (flushing && set->controllable && set->waiting > 0) { where set->controllable always 0 after the fist packet received in gst_rtspsrc_connection_receive, then it set to 1. so after that function becomes unstoppable, after setting gst_poll_set_controllable (gstrtspconnection.c:2272) FALSE. if you start to debug a simple example and pause the running during this timeout, then visual studio show you probably in a deadlock situation.
Created attachment 187915 [details] [review] Fix for the bug report
yes, patch makes sense to me.
commit 30b2abaddd84a7f8bc61c8ebdc58b934c94712b4 Author: Miguel Angel Cabrera Moya <madmac2501@gmail.com> Date: Mon May 16 15:35:50 2011 +0200 rtspconnection: not enter in not controllable state unless it is necessary When closing rtspsrc the state change blocks until the polling in the connection timeouts. This is because the second time we loop to read a full message controllable is set to FALSE in the poll group, even though no message is half read. This can be avoided by not setting controllable to FALSE the poll group unless we had begin to read a message. Fixes #610916