Problems with rtspsrc
Marco Ballesio
gibrovacco at gmail.com
Thu Mar 3 23:48:36 PST 2011
Hi Marc,
On Mon, Feb 28, 2011 at 7:38 PM, Marc Murphy <marcmltd at marcm.co.uk> wrote:
> 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.
>
It would be good to discuss the handling of "multiple choices" within
a bug. Can you please file one (Gnome desktop/Gstreamer component) and
attach the patch there? It would IMO need some cleaning, but I'm not
really the one who can give the go/nogo for it to be integrated.
Regards
> 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 at lists.freedesktop.org
> [mailto:gstreamer-devel-bounces+marcmltd=marcm.co.uk at lists.freedesktop.org]
> 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 at 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:
>
> http://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/gst/rtsp/gstrtspsrc.c?h=0.11&id=6d545e29add17f1c02ee4fe5623409ed63369c17#n5328
>
> 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 at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
More information about the gstreamer-devel
mailing list