Edit: I am keeping the older posts for posterity, but I worked this out to be a firmware bug at the bottom.
Has anyone had any success playing the Anafi’s video stream using a GStreamer pipeline? It’s working fine with VLC for me, but with GStreamer I get an error very early in rtspsrc:
Setting pipeline to PAUSED …
Pipeline is live and does not need PREROLL …
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://192.168.42.1/live
Progress: (open) Retrieving server options
ERROR: from element /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstRTSPSrc:source: Could not read from resource.
Additional debug info:
gstrtspsrc.c(6317): gst_rtsp_src_receive_response (): /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstRTSPSrc:source:
Could not receive message. (Parse error)
ERROR: pipeline doesn’t want to preroll.
Setting pipeline to PAUSED …
Setting pipeline to READY …
Setting pipeline to NULL …
Freeing pipeline …
I’ve had no success working past this.
My Qt ground control application uses GStreamer for playback as it’s one of the very few options that work well across both desktop Linux and Android and can also do RTP without RTSP for the Bebop 2. I’d prefer to stay on the same stack across models.
0:00:00.035143897 7418 0x559607f72190 WARN rtspsrc gstrtspsrc.c:7949:gst_rtspsrc_open: can’t get sdp
0:00:00.035163608 7418 0x559607f72190 WARN rtspsrc gstrtspsrc.c:6029:gst_rtspsrc_loop: we are not connected
I recall from another thread that MPlayer also has some sort of problem with the SDP that the Anafi is serving up.
Could one of the SDK developers perhaps post the SDP file (or an example thereof) so I could maybe try just using my ‘naked’ RTP pipeline I use for the Bebop 2? Or clue us in what might be going wrong in GStreamer here?
With VLC, I see the following RTSP commands with repsonses from the Anafi: OPTIONS, DESCRIBE, SETUP, PLAY.
With GStreamer, GStreamer gives up after getting the resonse to OPTIONS.
So either the response is malformatted and GStreamer code is stricter, or it could be a bug in GStreamer’s parsing code. Since it never progresses to the DESCRIBE stage it’s not even been served the SDP yet.
In the VLC Wireshark log, I see the LibVLC client send OPTIONS with ‘CSeq: 2’, which the Anafi then returns in its response (albeit in a different case, ‘Cseq’).
But the GStreamer client sends ‘CSeq: 0’, and the Anafi response doesn’t include a CSeq (or Cseq) header at all. Maybe a bug in the Anafi’s RTSP server there?
I got it working by locally patching GStreamer’s RTSP lib in gst-plugins-base to start with a sequence number (CSeq) of 2 instead of 0.
Note this is not a viable solution for me - my application is designed to be packaged by Linux distributions, and the chance of getting this patch included in GStreamer (or distributions) is very low, because the RTPS spec says:
The initial sequence number can be any number; however, it is RECOMMENDED to start at 0.
So I think I found a legitimate bug in the Anafi’s firmware that I would kindly request to be fixed in future updates!
Thanks for your feedback and all the different sources and data you gave us, we are currently working on it, we will keep you updated once it’s fixed (if we can fix it :p)
Thanks!