Problems with rtspsrc
Marc Murphy
marcmltd at marcm.co.uk
Mon Feb 28 09:14:33 PST 2011
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
http://gstreamer-devel.966125.n4.nabble.com/file/n3328215/rtspsrc_multichoice.patch <https://exchange.marcm.co.uk/exchweb/bin/redir.asp?URL=http://gstreamer-devel.966125.n4.nabble.com/file/n3328215/rtspsrc_multichoice.patch>
rtspsrc_multichoice.patch
w www.marcm.co.uk <http://www.marcm.co.uk/>
MARCM CONSULTANCY LTD registered office:
10 Church Road, Cheadle Hulme, Cheadle, Cheshire, SK8 7JU. Registered no: 792 9557 66, England.
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.
________________________________
From: gstreamer-devel-bounces+marcmltd=marcm.co.uk at 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
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/b6d4d108/attachment.html>
More information about the gstreamer-devel
mailing list