Problems with rtspsrc
Marc Murphy
marcmltd at marcm.co.uk
Mon Feb 28 09:38:29 PST 2011
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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110228/26de204e/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rtspsrc_multichoice.patch
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20110228/26de204e/attachment.txt>
More information about the gstreamer-devel
mailing list