Dear all,
I am trying to connect my IP camera but not having much luck.
Using Onvif Device Manager, I can see my camera feed with address: rtsp://192.168.2.88:554/11
Hopefully someone can help.
I’ve already read other posts on the subject but couldn’t find a solution.
Cheers,
E.
Hi @etienne ,
I think you are missing a username and password. Example: rtps://user:password@192.168.2.88:554/11
In any case, it seems to me an incomplete rtps address. It should be something like this: rtps://user:password@192.168.2.88:554/video1 or rtps://user:password@192.168.2.88:554/h264/ch1/stream_0 or something similar.
Watch this video Find RTSP URL IP Camera Using ODM (Onvif Device Manager) - YouTube
I’ve tried multiple ip cams through rtsp in Qgroundcontrol and whenever they haven’t connected it was due to an incomplete or incorrect address.
I’m thinking now that another option may be that you have to allow remote connection to rtsp, through the web browser of the camera, some have that option, or even for remote access authorization. For example the hikvision cameras to use onvif you have to create a specific user and authenticate it.
Best regards
Andrés
Hi @etienne,
I asked internally in case there were any ideas, and it was suggested that it’s possible QGC’s video pipeline is missing some required compatibility flag for handling your particular stream. In particular
Hi Andres,
Thank you for your response.
As per my previous pictures I got the rtsp from ODM and videolan was fine with it. That said, keeping an open mind, I added the username and password. Same results. VLC is ok and QGC is not.
Cheers,
E.
Hi Eliot,
Thank you for looking into it. I am not sure what I am supposed to do with the information. Do I copy and paste the arguments in QGC like this?
gst-launch-1.0 -vc rtspsrc location=rtsp://192.168.2.88:554/11 is-live=true onvif-mode=true ! decodebin ! autovideosink
That didn’t work for me.
Cheers,
E.
QGC’s video pipeline can’t be modified without building a new version of QGC. If you’ve got gstreamer installed[1] on your (topside) computer then you can test different pipelines to see whether they do or don’t work, and if you find that getting the pipeline to work requires a cap or flag that QGC definitely isn’t using then that could help determine why QGC is failing to properly receive your stream.
Alternatively you might find there’s some other information / URL you need to use, which might get it working in both plain gstreamer and QGC (e.g. if Andres is correct about the address being potentially incomplete / needing a username or password)
Instructions from this comment:
PATH environment variable)Hello @EliotBR
I am testing a new model of IP camera 4k 30 fps that I transmit to qgroundcontrol by rtsp:// protocol
I have tried all the encoding systems that qgroundcontrol offers (DirectX, software, etc) and I have even forced qgroundcontrol to run with my PC’s GPU, but still if I set the camera to its maximum quality (4k/3840 *2160/h265+/30fps/CBR/Maximum bite rate) has a lot of latency, as you can see in the attached video at the following link:
If I reduce the image quality, the latency improves, for example in the following settings: (3072*1728/30fps/ h265+ /VBR/ Bit rate Best quality) or (4k/30fps/h264/VBR/Bit rate best quality ) or (4k/25fps/h265+/VBR/Bit rate best quality). These transmissions have good quality, but without a doubt at their highest quality and a significant improvement is noted.
Thanks to your comments about gstreamer 1.0, I have decided to test this camera directly through gstreamer 1.0 by command line in CMD, and my surprise has been great, since I get an almost instantaneous transmission, with excellent latency, according to the following pipeline , as you can see in the video below is the pipeline:
gst-launch -vc rtsprc location=rtsp://admin:123456@192.168.2.15:554/video1 ! decodebin ! autovideosink sync=false
My doubts are: If qgroundcontrol uses gstreamer 1.0 for video display, why is there such a big difference in latency? What exactly is qgroundcontrol’s pipeline for the rtsp:// protocol?
I think the problem lies in the qgroundcontrol pipeline. In your previous comments you commented that this pipeline cannot be modified without creating a new version of Qgroundcontrol. Would it be too difficult to simply change qgroundcontrol’s rtsps:// pipeline?
I have tested the connection by gstreamer with the same pipeline for 3 different IP cameras, all 4k h265, and with all of them I have the same result, a perfect latency with gstreamer and very late with qgroundcontrol. Therefore, I think it is worth reviewing this topic.
On the other hand I have written a small program through python to control the zoom and focus by cgi commands, and it works very well, so if the visualization in qgroundcontrol was better, the integration of the camera would be perfect, to use in BR2 with the design I do with this camera as you can see in the following photo.
Thank you very much for your help or that of other forum members.
Note: @etienne I hope you have found the solution to your rtsp connection
Andrés
Hi @EliotBR
Any comments on my previous message? I would like to be able to move forward with this problem, and if necessary try to compile a version of qgroundcontrol with a better pipeline for rtsp h265+, but some answers to my doubts would help me.
Very grateful in advance
Andrés
Hi @Andres, apologies for the delay on this.
It’s very possible for different pipelines to have different amounts of latency, depending on how they do their processing and whether there are additional queues and buffers that are intended to provide some form of smoothing / jitter avoidance.
It’s also possible that your installed QGC version does not have access to the same gstreamer plugins as your separate gstreamer installation, so perhaps the latter is able to use hardware decoding where the former is stuck doing it in software, for example.
Honestly I’m not sure - as I understand it QGC’s video pipelines are dynamically created, but the code is challenging to parse, and gstreamer can do all sorts of configuration / element selection internally if it’s asked to automatically convert from one format to another.
@joaoantoniocardoso do you happen to have any insights here, either on how to determine what pipeline and elements QGC is using, and/or whether MAVLink Camera Manager’s WebRTC output is supposed to be able to handle 4k H265-encoded streams (in which case we could test the receiving with Cockpit)?
@EliotBR, to check what pipeline QGC is creating, one must run QGC with the debug-dump environment variable, like export GST_DEBUG_DUMP_DOT_DIR=$(pwd)/dots; , and then use some software to read it, like xdot dots/somestream-played.dot. Since it’s using decodebin3 element to create the decoding elements, each type of stream can potentially have different setups, so I won’t try to reproduce here unless we want to compare different systems/cases.
About the MCM’s WebRTC, there’s no plan for us to support H265 because it’s not supported by many browsers/OSs/platforms, at least not yet.
Hi @EliotBR & @joaoantoniocardoso
There is nothing to excuse, you have to attend to many queries. very grateful for the answer.
So I understand that qgroundcontrol is dynamic in assigning pipelines, which I understand complicates the option of assigning a specific pipeline.
I had also thought about doing it through webRTC, but I already knew that I only handle H264. I have tried to create a pipeline that converts rtsp to udp and visualize it through udp h265 in qgroundcontrol but the result has more delay than connecting directly to qgroundcontrol by rtsp.
Would it be possible to create a version of qgroundcontrol with a fixed pipeline?
Best regards
Andrés
