<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">I did some experiments, and it seems that 1.2 branch works fine, but the problem appears somewhere before 1.3.1. I tried bisecting, but I couldn't clearly see commit which broke it. The closest one I could find was 18b69419. After this commit, the server failed 1 in 5 attempts to connect. Before this commit, the server seemed to work ok after 25 attempts. But there seemed to be a lot of chasing of ghosts, and I can't really understand how that commit could cause the effect I'm seeing. Joel On 06/06/14 10:28, Sebastian Dröge wrote: </div> <blockquote cite="mid:1402046898.16601.25.camel@thor.lan" type="cite"> <pre wrap="">On Fr, 2014-05-30 at 11:55 +0100, Joel Holdsworth wrote: </pre> <blockquote type="cite"> <pre wrap="">Hi Tim, Thanks for your hints. I compiled GStreamer 1.3.2 and plugins from source, and this fixed this issue and a couple of others. But now I have a new problem! I'm trying to connect to a CCTV video encoding device on the LAN via RTSP. But since the upgrade rtspsrc has become nearly unusable. So doing this... gst-launch-0.10 rtspsrc location=<a class="moz-txt-link-freetext" href="rtsp://192.168.1.51:8554/ufirststream">rtsp://192.168.1.51:8554/ufirststream</a> ! application/x-r tp,payload=96 ! rtph264depay ! decodebin ! autovideosink ...works 10 times out of 10, but doing this... gst-launch-1.0 rtspsrc location=<a class="moz-txt-link-freetext" href="rtsp://192.168.1.51:8554/ufirststream">rtsp://192.168.1.51:8554/ufirststream</a> ! application/x-r tp,payload=96 ! rtph264depay ! decodebin ! autovideosink ...only works 2 times in 10. I put in the payload=96 filter, because there is some bundled metadata that I wanted to make sure was being discarded. The RTSP session gets set up, and I can see many incoming UDP RTP packets in wireshark, but these are never being played. Mostly the video window never appears. I tried tweaking the parameters a little, and so far the only parameter I've found that makes any difference is setting drop-on-latency=true, which sets gives me a corrupted mess at ~1FPS. The encoder device uses live555 as it's RTSP server, and it works reliably via VLC. Perhaps there's some issue with the device's RTSP server implementation, but arguably GStreamer should be tolerant of it. Any hints about the best way to track down the issue? </pre> </blockquote> <pre wrap=""> Try running gst-launch-1.0 with -v to see what exactly is built there, and if that doesn't help yet the debug logs should be able to help. You can enable them by setting e.g. GST_DEBUG=6 in the environment. </pre> <fieldset class="mimeAttachmentHeader"></fieldset> <pre wrap="">_______________________________________________ gstreamer-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </pre> </blockquote> </body> </html>