<HTML dir=ltr><HEAD><TITLE>Re: Problems with rtspsrc</TITLE> <META content="text/html; charset=unicode" http-equiv=Content-Type> <META name=GENERATOR content="MSHTML 8.00.6001.18928"></HEAD> <BODY> <DIV dir=ltr id=idOWAReplyText43020> <DIV dir=ltr>Hi Marco I have managed to fix it after looking at the extremely verbose logs. The problem was that the udp sockets were being closed too early and later in the close process a message was trying to be posted and the socket was no longer there so there was an error. I have created a unique fallthrough for MULTIPLE_CHOICES. I have a patch if you can have a look and see if it doesn't break anything, apply to gstrtspsrc.c.  I am now getting reliable redirects and rtsp sessions. Once it is fully tested I will submit for integration to future releases. Thanks Marc <A href="https://exchange.marcm.co.uk/exchweb/bin/redir.asp?URL=http://gstreamer-devel.966125.n4.nabble.com/file/n3328215/rtspsrc_multichoice.patch" target=_blank>http://gstreamer-devel.966125.n4.nabble.com/file/n3328215/rtspsrc_multichoice.patch</A> rtspsrc_multichoice.patch</DIV> <DIV dir=ltr> </DIV></DIV> <DIV dir=ltr id=idSignature69016> <DIV> <DIV class=MsoNormal>w <A href="http://www.marcm.co.uk/">www.marcm.co.uk</A></DIV> <DIV class=MsoNormal>MARCM CONSULTANCY LTD registered office: </DIV> <DIV class=MsoNormal>10 Church Road, Cheadle Hulme, Cheadle, Cheshire, SK8 7JU. Registered no: 792 9557 66, England.</DIV> <DIV class=MsoNormal> </DIV> <DIV class=MsoNormal>This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the addressee. If you are not the addressee please note that any distribution, reproduction, copying, publication or use of this communication or the information is prohibited. If you have received this communication in error, please contact us immediately and also delete the communication from your computer.</DIV></DIV></DIV> <DIV dir=ltr> <HR tabIndex=-1> From: gstreamer-devel-bounces+marcmltd=marcm.co.uk@lists.freedesktop.org on behalf of Marco Ballesio Sent: Sat 26/02/2011 16:15 To: Discussion of the development of and with GStreamer Subject: Re: Problems with rtspsrc </DIV> <DIV> Hi Marc, some comments below, I hope this will help.. On Fri, Feb 25, 2011 at 5:12 PM, Marc Murphy <marcmltd@marcm.co.uk> wrote: ..snip.. > > I have modified gst_rtspsrc_send to trap the error code I understand you have added the case GST_RTSP_STS_MULTIPLE_CHOICES as a fall-through for MOVED_PERMANENTLY and MOVE_TEMPORARILY. In case you've done something more, would it be possible to provide a patch, either as an attachment in this thread or as something pullable from a repo? >    case GST_RTSP_STS_MULTIPLE_CHOICES: >    { >         gchar *new_location; >         GST_INFO("got redirection"); >         /* if we don't have a Location Header, we must error */ >         if (gst_rtsp_message_get_header (response, GST_RTSP_HDR_LOCATION, >                 &new_location, 0) < 0) >         { >           GST_INFO("Ooops no Location Header"); >         } >         GST_INFO("Source Address %p", src); >         src->addr = g_strdup (new_location); >         GST_INFO("Redirect to [ %s ]", src->addr); >         src->need_redirect = TRUE; >         src->state = GST_RTSP_STATE_INIT; > //        res = GST_RTSP_OK; Why is this commented? >    } > Then in gst_rtspsrc_open I trap the src->need_redirect > > open_failed: >   { >     GST_WARNING_OBJECT (src, "can't setup streaming from sdp"); >     GST_RTSP_STATE_UNLOCK (src); >     if ( src->need_redirect ) >     { >      //Lets emit a message to the playbin..... >      GstStructure *messageStruct; >      GstMessage   *message; >      gchar * uri = g_strdup (src->addr); >      messageStruct = gst_structure_new ("redirect_message", >                                         "uri",        G_TYPE_STRING, uri, >                                         NULL); >      message = gst_message_new_element (GST_OBJECT (src), messageStruct); >      gst_element_post_message (GST_ELEMENT(src), message); >      printf("Going to redirect to [ %s ]\n", uri); > >      gst_rtspsrc_close(src); >      //We are being asked to redirect. >      gst_rtspsrc_uri_set_uri (GST_URI_HANDLER (src), >         src->addr); After setting the URI you should probably need to go through a state change READY->PAUSED to initiate the new sessions (I don't recommend you to force a state change from the element itself) but I don't understand, in the first place, why the default handling of the redirection does not suffice in your case: <A href="http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtsp/gstrtspsrc.c?h=0.11&id=6d545e29add17f1c02ee4fe5623409ed63369c17#n5328">http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtsp/gstrtspsrc.c?h=0.11&id=6d545e29add17f1c02ee4fe5623409ed63369c17#n5328</A> The handling of need_redirect would automatically retry with the new URI after your modification of above. Or is there something particular you want the application to perform? >      goto retry; >  } > The jump to retry goes back to the beginning of the gst_rtspsrc_open > function. Spaghetti are good :D > I would have thought that if I use the gst_rtspsrc_close(src); > call before attempting to open with the new connection it would destroy all > the current sockets to the RTSP server (RTP and RTCP ports). It's not clear to me how we can have RTP/RTCP ports already opened if we're still in the session initiation phase. When seeing those, it's probably already too late and a proper redirection has been missed. > Here is a session log; > ..snip.. Could you use a lower verbosity and possibly dump packets in a network capture with tcpdump? Something I could see with Wireshark.. . > Caught SIGSEGV accessing address 0x2b2f5bd8 > This is interesting as well.. any backtraces available? > > Its almost as if the old ports havent been closed or discarded. Which old ports do you mean? Unless I've missed something from the log, no RTP/RTCP sessions have started yet (you got a 300 right at the beginning of the SETUP). Again, a proper network dump, possibly taken from the client, will clarify our ideas here. Suggested command: tcpdump -i<your_interface> -s0 -w/path/to/dump.cap Regards It will > successfully re-negotiate the connection but not UDP data is coming through. > > If I dont do the redirect and let the pipeline go through the state change > Setting pipeline to NULL ... > Freeing pipeline ... > I can successfully use the new redirect address.  I dont understand the > difference between the forced close and the close applied by the pipeline > going from PLAYING to READY to NULL.  I thought the rtspsrc would handle its > own sources and sinks and connect to the rest of the pipeline when dataflow > is active. > > This has been driving me mental. If anyone can point me to how I can > successfully debug or find out where the blockage in the pipeline is it > would be fantastic.  The target is an embedded platform not a PC. > > Regards > Marc > > _______________________________________________ > gstreamer-devel mailing list > gstreamer-devel@lists.freedesktop.org > <A href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</A> > > _______________________________________________ gstreamer-devel mailing list gstreamer-devel@lists.freedesktop.org <A href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</A> </DIV></BODY></HTML>