I’m trying to understand how PX4 / QGroundControl users validate the full video path after integration, not just the camera output.
A pattern I keep seeing is this:
The camera can produce a clear image on its own, but once it is connected into the full UAV system, the video feed may not stay usable for control, monitoring, or payload operation.
The issue is usually not one single component. It can come from the whole path:
camera → encoder → MAVLink / metadata / OSD overlay → transmission → receiver → decoder → display → QGroundControl
Some failure points I’m interested in:
- End-to-end latency is not the same as camera latency
A camera preview may look fast, but after encoding, transmission, decoding, display, and QGroundControl rendering, the operator feedback can become noticeably delayed. - QGroundControl video behavior can depend heavily on the pipeline
RTSP, UDP / RTP, GStreamer, HDMI capture, USB capture, and direct receiver display can all behave differently, even with the same camera and encoder. - MAVLink / telemetry / OSD integration can affect stability
A clean video stream may work alone, but once telemetry, metadata, or overlay logic is added, the system may show stutter, freeze, sync issues, or inconsistent display behavior. - Companion-computer processing can become the hidden bottleneck
On some embedded platforms, the camera input may be high frame rate, but the actual processed or displayed frame rate can drop because of buffer handling, codec settings, CPU / GPU load, memory bandwidth, or pipeline configuration. - Power and layout problems can look like video-link problems
Power noise, shared rails, high-current WiFi/video modules, ESC noise, HDMI interference, antenna placement, weak filtering, or receiver settings can cause frame loss or intermittent freezing. - A working prototype does not always mean a repeatable deployment build
Firmware version, encoder settings, receiver settings, GStreamer pipeline, QGC version, display device, cable layout, and power configuration can all change the result between one prototype and repeated builds.
So I’m starting to think UAV video should be tested as a full camera-to-QGroundControl path, not only as a camera or transmitter spec.
I’m interested in how others here validate this in real PX4 / QGroundControl setups:
- How do you measure end-to-end video latency?
- Do you use LED tests, timestamp overlays, frame counters, stopwatch methods, or another approach?
- Which video path has caused the most problems for you: RTSP, UDP / RTP, GStreamer, HDMI capture, USB capture, or direct receiver display?
- Have you seen QGroundControl display behavior differ from an external player or direct monitor?
- Has MAVLink / telemetry / OSD integration added noticeable delay or instability in your setup?
- Have you seen companion-computer load, buffer settings, or codec configuration create delayed video?
- Have power noise, antenna layout, or receiver settings caused video stutter or frame drops?
- For systems that need to be repeated across multiple builds, how do you document the full video-path configuration?
I’m mainly looking for practical test methods, failure cases, and debugging order from people who have integrated video into real PX4-based systems.
Not looking for product recommendations only — more interested in how you prove that the full video path is current, stable, usable, and repeatable after integration.