On Thu Oct 20 09:04:43 UTC 2016 Sebastian Dröge wrote:
>The initial RTSP requests/responses (DESCRIBE, SETUP, PLAY) are missing >though. That's what would've been interesting. >It seems like rtspsrc is failing on those already Thanks for your reply Sebastian, the pcap file is pretty huge, as the pipeline worked for a while, so I saved just the last packets. Here attached the initial RTSP request/response and all the RTSP request/responeses. d. [hidden email] _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On Thu, 2016-10-20 at 14:28 +0200, Diego Buffa wrote:
> On Thu Oct 20 09:04:43 UTC 2016 Sebastian Dröge wrote: > >The initial RTSP requests/responses (DESCRIBE, SETUP, PLAY) are > missing > >though. That's what would've been interesting. > > >It seems like rtspsrc is failing on those already > > Thanks for your reply Sebastian, the pcap file is pretty huge, as the > pipeline worked for a while, so I saved just the last packets. > Here attached the initial RTSP request/response and all the RTSP > request/responeses. is with the last packets you provided. The next step would then be to dive into the code and check why it considers the packet as invalid, what is confusing it. And if the packet is indeed broken in one way or another. Can you provide again that the last packet that it successfully parses and the one where it fails? Which might not be the last one from your pcap capture, but an earlier one. -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel signature.asc (949 bytes) Download Attachment |
On Mon, Oct 24, 2016 at 9:05 AM, Sebastian Dröge <[hidden email]> wrote: So it was running for a while? That would indeed mean that the problem Yes Sebastian, it run for a while. I guess the last good packet was the one of 1055 received at 1:53:05.895046809 1:53:05.893728142 414 0x77c230 DEBUG rtspsrc gstrtspsrc.c:4431:gst_rtspsrc_handle_data:<rtspsrc0> pushing data of size 1446 on channel 0 1:53:05.894069476 414 0x77c230 DEBUG rtspsrc gstrtspsrc.c:4561:gst_rtspsrc_loop_interleaved:<rtspsrc0> doing receive with timeout 114 seconds, 991176 usec 1:53:05.894463809 414 0x77c230 DEBUG rtspsrc gstrtspsrc.c:4571:gst_rtspsrc_loop_interleaved:<rtspsrc0> we received a server message 1:53:05.894605809 414 0x77c230 DEBUG rtspsrc gstrtspsrc.c:4607:gst_rtspsrc_loop_interleaved:<rtspsrc0> got data message 1:53:05.894743809 414 0x77c230 DEBUG rtspsrc gstrtspsrc.c:4431:gst_rtspsrc_handle_data:<rtspsrc0> pushing data of size 1055 on channel 0 1:53:05.895046809 414 0x77c230 DEBUG rtspsrc gstrtspsrc.c:4561:gst_rtspsrc_loop_interleaved:<rtspsrc0> doing receive with timeout 114 seconds, 990192 usec 1:53:06.151676476 414 0x77c230 WARN rtspsrc gstrtspsrc.c:4641:gst_rtspsrc_loop_interleaved:<rtspsrc0> error: Could not receive message. (Parse error) ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not read from resource. Anyway I cannot find a packet of size 1055 in my pcap file while I see the previous ones of 1446 (end of pcap file attached). Is there better way to identify the last good packet and the bad one than looking at the size? _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel end_pcap (13K) Download Attachment |
On Mon, Oct 24, 2016 at 12:29 PM, Diego Buffa <[hidden email]> wrote: > > > Yes Sebastian, it run for a while. > I guess the last good packet was the one of 1055 received at 1:53:05.895046809 > > 1:53:05.893728142 414 0x77c230 DEBUG rtspsrc > gstrtspsrc.c:4431:gst_rtspsrc_handle_data:<rtspsrc0> pushing data of size > 1446 on channel 0 > 1:53:05.894069476 414 0x77c230 DEBUG rtspsrc > gstrtspsrc.c:4561:gst_rtspsrc_loop_interleaved:<rtspsrc0> doing receive > with timeout 114 seconds, 991176 usec > 1:53:05.894463809 414 0x77c230 DEBUG rtspsrc > gstrtspsrc.c:4571:gst_rtspsrc_loop_interleaved:<rtspsrc0> we received a > server message > 1:53:05.894605809 414 0x77c230 DEBUG rtspsrc > gstrtspsrc.c:4607:gst_rtspsrc_loop_interleaved:<rtspsrc0> got data message > 1:53:05.894743809 414 0x77c230 DEBUG rtspsrc > gstrtspsrc.c:4431:gst_rtspsrc_handle_data:<rtspsrc0> pushing data of size > 1055 on channel 0 > 1:53:05.895046809 414 0x77c230 DEBUG rtspsrc > gstrtspsrc.c:4561:gst_rtspsrc_loop_interleaved:<rtspsrc0> doing receive > with timeout 114 seconds, 990192 usec > 1:53:06.151676476 414 0x77c230 WARN rtspsrc > gstrtspsrc.c:4641:gst_rtspsrc_loop_interleaved:<rtspsrc0> error: Could not > receive message. (Parse error) > ERROR: from element /GstPipeline:pipeline0/GstRTSPSrc:rtspsrc0: Could not > read from resource. > > Anyway I cannot find a packet of size 1055 in my pcap file while I see the previous ones of 1446 (end of pcap file attached). > Is there better way to identify the last good packet and the bad one than looking at the size? > > (gdb) p res $1 = GST_RTSP_EPARSE (gdb) p timeout $2 = (GTimeVal *) 0x80d623c (gdb) p *timeout $3 = {tv_sec = 20, tv_usec = 0} (gdb) p message->type $4 = GST_RTSP_MESSAGE_REQUEST (gdb) p *conn $5 = {url = 0xb6d00cb0, fd0 = {fd = 10, idx = 1}, fd1 = {fd = -1, idx = 0}, readfd = 0xb6d01304, writefd = 0xb6d01304, manual_http = 0, tunnelid = '\000' <repeats 23 times>, tunneled = 0, tstate = TUNNEL_STATE_NONE, fdset = 0xb6d01808, ip = 0xb6d01640 "192.168.214.117", read_ahead = 0, initial_buffer = 0x0, initial_buffer_offset = 0, cseq = 16, session_id = "123012", '\000' <repeats 505 times>, timeout = 120, timer = 0xb6d01598, auth_method = GST_RTSP_AUTH_DIGEST, username = 0xb6d03490 "******", passwd = 0xb6d034a0 "******", auth_params = 0x80d9088, ctx = {state = 0, save = 0, out = "\000\000", cout = 0, coutl = 0}, ctxp = 0x0, proxy_host = 0x0, proxy_port = 0} (gdb) p *message $7 = {type = GST_RTSP_MESSAGE_REQUEST, type_data = {request = {method = GST_RTSP_INVALID, uri = 0xb6d1c608 "q\262\265\277@\020\064\026!I", version = GST_RTSP_VERSION_1_0}, response = { code = GST_RTSP_STS_INVALID, reason = 0xb6d1c608 "q\262\265\277@\020\064\026!I", version = GST_RTSP_VERSION_1_0}, data = {channel = 0 '\000'}}, hdr_fields = 0xb6d1cd80, body = 0x0, body_size = 0} I see "reason" in the message structure, could someone tell me what it means, and more in general has someone any clues of why I got this "Could not receive message. (Parse error)?" _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
On Tue, 2016-10-25 at 12:12 +0200, Diego Buffa wrote:
> > I see "reason" in the message structure, could someone tell me what > it means, and more in general has someone any clues of why I got this > "Could not receive message. (Parse error)?" That looks like invalid data. Bigger question is where exactly in the parsing code it starts failing, and what the data at that point is. -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel signature.asc (949 bytes) Download Attachment |
Free forum by Nabble | Edit this page |