GStreamer-devel

Problems with rtspsrc

Classic

List

Threaded

5 messages Options

Marc Murphy

Problems with rtspsrc

Hi,

I am using gst-plugins-good-0.10.25 and trying to add functionality to rtspsrc plugin so I can react to a server MULTIPLE_CHOICES (300) response.

I am successfully trapping the message and extracting the redirect uri.

It is all going wrong when I attempt to force the redirect...... from what I understand the following is happening;

The pipeline is constructed using gst-launch e.g.

gst-launch -v rtspsrc location=rtsp://x.x.x.x/video ! \
rtpmp2tdepay ! playpump ! decode (playpump and decode are just symbolic of the rest of the pipeline)

The startup works OK and I get the negotiation as should happen, except for when there is a 300 response.

I have traced the path through the rtspsrc and I see the following path

gst_rtspsrc_change_state -> gst_rtspsrc_open -> gst_rtspsrc_retrieve_sdp

gst_rtspsrc_open_from_sdp -> gst_rtspsrc_send

I have modified gst_rtspsrc_send to trap the error code

   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;
   }

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);
     goto retry;

}

The jump to retry goes back to the beginning of the gst_rtspsrc_open function. 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).

Here is a session log;

Setting pipeline to PAUSED ...
gst_rtspsrc_change_state --- gst_rtspsrc_open
RTSP request message 0x7fa13918
request line:
   method: 'OPTIONS'
   uri:    'rtsp://x.x.x.x/video'
   version: '1.0'
headers:
body:
RTSP response message 0x7fa13934
status line:
   code:   '200'
   reason: 'OK'
   version: '1.0'
headers:
   key: 'CSeq', value: '1'
   key: 'Public', value: 'OPTIONS'
   key: 'Public', value: 'DESCRIBE'
   key: 'Public', value: 'SETUP'
   key: 'Public', value: 'PLAY'
   key: 'Public', value: 'PAUSE'
   key: 'Public', value: 'GET_PARAMETER'
   key: 'Public', value: 'TEARDOWN'
   key: 'Server', value: 'Kasenna MediaBase version 9.0'
   key: 'Date', value: 'Fri, 25 Feb 2011 14:30:42 GMT'
body: length 0
RTSP request message 0x7fa13918
request line:
   method: 'DESCRIBE'
   uri:    'rtsp://x.x.x.x/video'
   version: '1.0'
headers:
   key: 'Accept', value: 'application/x-rtsp-mh, application/sdp'
body:
RTSP response message 0x7fa13934
status line:
   code:   '200'
   reason: 'OK'
   version: '1.0'
headers:
   key: 'CSeq', value: '2'
   key: 'Date', value: 'Fri, 25 Feb 2011 14:30:42 GMT'
   key: 'Server', value: 'Kasenna MediaBase version 9.0'
   key: 'Content-Type', value: 'application/x-rtsp-mh'
   key: 'Content-Length', value: '445'
body: length 446
00000000 (0x4abb80): 3c 4d 65 64 69 61 44 65 73 63 72 69 70 74 69 6f <MediaDescriptio
00000010 (0x4abb90): 6e 3e 0a 3c 4d 65 64 69 61 43 6f 6e 74 61 69 6e n>.<MediaContain
00000020 (0x4abba0): 65 72 0a 4e 75 6d 53 74 72 65 61 6d 73 20 3d 20 er.NumStreams =
00000030 (0x4abbb0): 31 0a 3e 0a 3c 4d 65 64 69 61 53 74 72 65 61 6d 1.>.<MediaStream
00000040 (0x4abbc0): 73 3e 0a 3c 4d 65 64 69 61 53 74 72 65 61 6d 0a s>.<MediaStream.
00000050 (0x4abbd0): 53 74 72 65 61 6d 49 44 20 3d 20 30 0a 4d 69 6d StreamID = 0.Mim
00000060 (0x4abbe0): 65 54 79 70 65 20 3d 20 61 70 70 6c 69 63 61 74 eType = applicat
00000070 (0x4abbf0): 69 6f 6e 2f 78 2d 73 67 69 6d 62 0a 4d 61 78 42 ion/x-sgimb.MaxB
00000080 (0x4abc00): 69 74 52 61 74 65 20 3d 20 33 33 36 38 32 33 39 itRate = 3368239
00000090 (0x4abc10): 0a 48 65 69 67 68 74 20 3d 20 35 37 36 0a 57 69 .Height = 576.Wi
000000a0 (0x4abc20): 64 74 68 20 3d 20 37 36 38 0a 46 72 61 6d 65 73 dth = 768.Frames
000000b0 (0x4abc30): 50 65 72 53 65 63 6f 6e 64 20 3d 20 32 35 2e 30 PerSecond = 25.0
000000c0 (0x4abc40): 30 30 30 30 30 0a 41 73 70 65 63 74 52 61 74 69 00000.AspectRati
000000d0 (0x4abc50): 6f 20 3d 20 30 2e 30 30 30 30 30 30 0a 46 72 61 o = 0.000000.Fra
000000e0 (0x4abc60): 6d 65 73 54 6f 49 46 72 61 6d 65 73 52 61 74 69 mesToIFramesRati
000000f0 (0x4abc70): 6f 20 3d 20 30 2e 30 30 30 30 30 30 0a 41 75 64 o = 0.000000.Aud
00000100 (0x4abc80): 69 6f 48 65 61 64 65 72 20 3d 20 30 0a 44 75 72 ioHeader = 0.Dur
00000110 (0x4abc90): 61 74 69 6f 6e 20 3d 20 34 39 36 35 37 39 32 30 ation = 49657920
00000120 (0x4abca0): 30 30 0a 53 74 61 72 74 54 69 6d 65 20 3d 20 30 00.StartTime = 0
00000130 (0x4abcb0): 0a 50 6c 61 79 4d 6f 64 65 73 20 3d 20 37 0a 4e .PlayModes = 7.N
00000140 (0x4abcc0): 75 6d 54 72 69 63 6b 53 70 65 65 64 20 3d 20 31 umTrickSpeed = 1
00000150 (0x4abcd0): 0a 54 72 69 63 6b 53 70 65 65 64 73 20 3d 20 31 .TrickSpeeds = 1
00000160 (0x4abce0): 32 0a 54 79 70 65 53 70 65 63 69 66 69 63 44 61 2.TypeSpecificDa
00000170 (0x4abcf0): 74 61 20 3d 20 4d 50 45 47 2d 32 0a 56 69 64 65 ta = MPEG-2.Vide
00000180 (0x4abd00): 6f 50 69 64 20 3d 20 30 0a 41 75 64 69 6f 50 69 oPid = 0.AudioPi
00000190 (0x4abd10): 64 20 3d 20 30 0a 3c 2f 4d 65 64 69 61 53 74 72 d = 0.</MediaStr
000001a0 (0x4abd20): 65 61 6d 73 3e 0a 3c 2f 4d 65 64 69 61 44 65 73 eams>.</MediaDes
000001b0 (0x4abd30): 63 72 69 70 74 69 6f 6e 3e 0d 0a 0d 0a 00        cription>.....
RTSP request message 0x7fa13768
request line:
   method: 'SETUP'
   uri:    'rtsp://x.x.x.x/video/'
   version: '1.0'
headers:
   key: 'Transport', value: 'RTP/AVP/UDP;unicast;client_port=8254-8255'
   key: 'User-Agent', value: 'GSTREAMER_USER_AGENT_KA'
body:
RTSP response message 0x7fa13784
status line:
   code:   '300'
   reason: 'Multiple Choices'
   version: '1.0'
headers:
   key: 'CSeq', value: '3'
   key: 'Location', value: 'rtsp://x.x.x.newx/video'
   key: 'Connection', value: 'close'
   key: 'Date', value: 'Fri, 25 Feb 2011 14:30:42 GMT'
body: length 0
Going to redirect to [ rtsp://x.x.x.newx/video ]
make sure we're not flushing anymore
close connections
cleanup

(gst-launch-0.10:447): GStreamer-WARNING **: Element udpsrc0 is not in bin rtspsrc0

(gst-launch-0.10:447): GStreamer-WARNING **: Element udpsrc1 is not in bin rtspsrc0
RTSP request message 0x7fa13918
request line:
   method: 'OPTIONS'
   uri:    'rtsp://x.x.x.newx/video'
   version: '1.0'
headers:
body:
RTSP response message 0x7fa13934
status line:
   code:   '200'
   reason: 'OK'
   version: '1.0'
headers:
   key: 'CSeq', value: '1'
   key: 'Public', value: 'OPTIONS'
   key: 'Public', value: 'DESCRIBE'
   key: 'Public', value: 'SETUP'
   key: 'Public', value: 'PLAY'
   key: 'Public', value: 'PAUSE'
   key: 'Public', value: 'GET_PARAMETER'
   key: 'Public', value: 'TEARDOWN'
   key: 'Server', value: 'Kasenna MediaBase version 9.0'
   key: 'Date', value: 'Fri, 25 Feb 2011 14:30:42 GMT'
body: length 0
RTSP request message 0x7fa13918
request line:
   method: 'DESCRIBE'
   uri:    'rtsp://x.x.x.newx/video'
   version: '1.0'
headers:
   key: 'Accept', value: 'application/x-rtsp-mh, application/sdp'
body:
RTSP response message 0x7fa13934
status line:
   code:   '200'
   reason: 'OK'
   version: '1.0'
headers:
   key: 'CSeq', value: '2'
   key: 'Date', value: 'Fri, 25 Feb 2011 14:30:42 GMT'
   key: 'Server', value: 'Kasenna MediaBase version 9.0'
   key: 'Content-Type', value: 'application/x-rtsp-mh'
   key: 'Content-Length', value: '445'
body: length 446
00000000 (0x4addf8): 3c 4d 65 64 69 61 44 65 73 63 72 69 70 74 69 6f <MediaDescriptio
00000010 (0x4ade08): 6e 3e 0a 3c 4d 65 64 69 61 43 6f 6e 74 61 69 6e n>.<MediaContain
00000020 (0x4ade18): 65 72 0a 4e 75 6d 53 74 72 65 61 6d 73 20 3d 20 er.NumStreams =
00000030 (0x4ade28): 31 0a 3e 0a 3c 4d 65 64 69 61 53 74 72 65 61 6d 1.>.<MediaStream
00000040 (0x4ade38): 73 3e 0a 3c 4d 65 64 69 61 53 74 72 65 61 6d 0a s>.<MediaStream.
00000050 (0x4ade48): 53 74 72 65 61 6d 49 44 20 3d 20 30 0a 4d 69 6d StreamID = 0.Mim
00000060 (0x4ade58): 65 54 79 70 65 20 3d 20 61 70 70 6c 69 63 61 74 eType = applicat
00000070 (0x4ade68): 69 6f 6e 2f 78 2d 73 67 69 6d 62 0a 4d 61 78 42 ion/x-sgimb.MaxB
00000080 (0x4ade78): 69 74 52 61 74 65 20 3d 20 33 33 36 38 32 33 39 itRate = 3368239
00000090 (0x4ade88): 0a 48 65 69 67 68 74 20 3d 20 35 37 36 0a 57 69 .Height = 576.Wi
000000a0 (0x4ade98): 64 74 68 20 3d 20 37 36 38 0a 46 72 61 6d 65 73 dth = 768.Frames
000000b0 (0x4adea8): 50 65 72 53 65 63 6f 6e 64 20 3d 20 32 35 2e 30 PerSecond = 25.0
000000c0 (0x4adeb8): 30 30 30 30 30 0a 41 73 70 65 63 74 52 61 74 69 00000.AspectRati
000000d0 (0x4adec8): 6f 20 3d 20 30 2e 30 30 30 30 30 30 0a 46 72 61 o = 0.000000.Fra
000000e0 (0x4aded8): 6d 65 73 54 6f 49 46 72 61 6d 65 73 52 61 74 69 mesToIFramesRati
000000f0 (0x4adee8): 6f 20 3d 20 30 2e 30 30 30 30 30 30 0a 41 75 64 o = 0.000000.Aud
00000100 (0x4adef8): 69 6f 48 65 61 64 65 72 20 3d 20 30 0a 44 75 72 ioHeader = 0.Dur
00000110 (0x4adf08): 61 74 69 6f 6e 20 3d 20 34 39 36 35 37 39 32 30 ation = 49657920
00000120 (0x4adf18): 30 30 0a 53 74 61 72 74 54 69 6d 65 20 3d 20 30 00.StartTime = 0
00000130 (0x4adf28): 0a 50 6c 61 79 4d 6f 64 65 73 20 3d 20 37 0a 4e .PlayModes = 7.N
00000140 (0x4adf38): 75 6d 54 72 69 63 6b 53 70 65 65 64 20 3d 20 31 umTrickSpeed = 1
00000150 (0x4adf48): 0a 54 72 69 63 6b 53 70 65 65 64 73 20 3d 20 31 .TrickSpeeds = 1
00000160 (0x4adf58): 32 0a 54 79 70 65 53 70 65 63 69 66 69 63 44 61 2.TypeSpecificDa
00000170 (0x4adf68): 74 61 20 3d 20 4d 50 45 47 2d 32 0a 56 69 64 65 ta = MPEG-2.Vide
00000180 (0x4adf78): 6f 50 69 64 20 3d 20 30 0a 41 75 64 69 6f 50 69 oPid = 0.AudioPi
00000190 (0x4adf88): 64 20 3d 20 30 0a 3c 2f 4d 65 64 69 61 53 74 72 d = 0.</MediaStr
000001a0 (0x4adf98): 65 61 6d 73 3e 0a 3c 2f 4d 65 64 69 61 44 65 73 eams>.</MediaDes
000001b0 (0x4adfa8): 63 72 69 70 74 69 6f 6e 3e 0d 0a 0d 0a 00        cription>.....
RTSP request message 0x7fa13768
request line:
   method: 'SETUP'
   uri:    'rtsp://x.x.x.newx/video/'
   version: '1.0'
headers:
   key: 'Transport', value: 'RTP/AVP/UDP;unicast;client_port=8254-8255'
   key: 'User-Agent', value: 'GSTREAMER_USER_AGENT_KA'
body:
RTSP response message 0x7fa13784
status line:
   code:   '200'
   reason: 'OK'
   version: '1.0'
headers:
   key: 'CSeq', value: '3'
   key: 'Transport', value: 'RTP/AVP/UDP;unicast;source=62.142.123.24;client_port=8254-8255;server_port=60398-60399;ssrc=163c081b'
   key: 'Session', value: '1293466192;timeout=60'
body: length 0
/GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:rtpbin0: latency = 2000
/GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstRtpBin:rtpbin0: buffer-mode = slave (1)
/GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0/GstUDPSrc:udpsrc2: timeout = 5000000
Pipeline is live and does not need PREROLL ...
ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not write to resource.
Additional debug info:
gstrtspsrc.c(5066): gst_rtspsrc_setup_streams (): /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0:
Could not send message. (Unknown error (1))
ERROR: pipeline doesn't want to preroll.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
make sure we're not flushing anymore
construct a control url
construct a control url
try aggregate
do TEARDOWN
RTSP request message 0x7fa14208
request line:
   method: 'TEARDOWN'
   uri:    'rtsp://x.x.x.newx/video'
   version: '1.0'
headers:
   key: 'User-Agent', value: 'GSTREAMER_USER_AGENT_KA'
body:
RTSP response message 0x7fa14224
status line:
   code:   '200'
   reason: 'OK'
   version: '1.0'
headers:
   key: 'CSeq', value: '4'
   key: 'Date', value: 'Fri, 25 Feb 2011 14:30:43 GMT'
body: length 0
parse result?
close connections
cleanup
Setting pipeline to NULL ...
Freeing pipeline ...
Caught SIGSEGV accessing address 0x2b2f5bd8

Its almost as if the old ports havent been closed or discarded. 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Marco Ballesio

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 <[hidden email]> 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
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Marc Murphy

RE: Problems with rtspsrc

In reply to this post by Marc Murphy

Re: Problems with rtspsrc

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
rtspsrc_multichoice.patch

w 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=[hidden email] 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

Why is this commented?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Marc Murphy

RE: Problems with rtspsrc

In reply to this post by Marc Murphy

RE: Problems with rtspsrc

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=[hidden email] [[hidden email]] 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 <[hidden email]> 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?

Why is this commented?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

rtspsrc_multichoice.patch (5K) Download Attachment

Marco Ballesio

Re: Problems with rtspsrc

Hi Marc,

On Mon, Feb 28, 2011 at 7:38 PM, Marc Murphy <[hidden email]> 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=[hidden email]
> [mailto:gstreamer-devel-bounces+marcmltd=[hidden email]]
> 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 <[hidden email]> 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
>> [hidden email]
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel