<HTML><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> I'll try with the correct link this time ;o) 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 w www.marcm.co.uk -----Original Message----- From: gstreamer-devel-bounces+marcmltd=marcm.co.uk@lists.freedesktop.org [<A href="mailto:gstreamer-devel-bounces+marcmltd=marcm.co.uk@lists.freedesktop.org">mailto:gstreamer-devel-bounces+marcmltd=marcm.co.uk@lists.freedesktop.org</A>] On Behalf Of Marco Ballesio Sent: 26 February 2011 16:15 To: Discussion of the development of and with GStreamer Subject: Re: Problems with rtspsrc 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> </BODY></HTML>