Clear video feed, but unstable camera-to-GCS path — how do you test end-to-end latency and repeatability?

General
1

I’m trying to compare how different teams test UAV video paths after full integration, not just 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 system, the video feed may no longer be usable for control, monitoring, or payload operation.

The issue is usually not one single component. It can come from the whole path:

camera → encoder → OSD / telemetry overlay → transmission → receiver → decoder → display → GCS

Some failure points I’m interested in:

  1. End-to-end latency is not the same as camera latency
    A camera preview may look fast, but after encoding, OSD, receiver, decoder, display, and GCS rendering, the operator feedback can become noticeably delayed.

  2. OSD / telemetry overlay can change the behavior of the video path
    A clean video stream may work alone, but after MAVLink / OSD overlay is added, the system may show stutter, freeze, sync issues, or inconsistent display behavior.

  3. RTSP / GStreamer / GCS combinations can behave very differently
    The same camera and encoder may perform differently depending on receiver hardware, pipeline settings, Android / Windows GCS, USB capture, HDMI capture, or QGroundControl configuration.

  4. Power and layout problems can look like video-module problems
    Power noise, high-current WiFi/video modules, ESC noise, HDMI interference, antenna placement, weak filtering, or shared power rails can cause frame loss or intermittent freezing.

  5. A working prototype does not always mean a repeatable deployment build
    Firmware version, encoder settings, receiver settings, display device, GCS version, and cable layout can all change the behavior between prototype and fielded units.

So my current view is that UAV video should be tested as a full camera-to-ground-station path, not only as a camera spec.

I’m interested in how others here validate this in real ArduPilot / 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 path has caused the most problems for you: RTSP, GStreamer, HDMI capture, USB capture, or direct receiver display?

  • Has MAVLink / OSD overlay added noticeable delay or instability in your setup?

  • Have you seen power noise, antenna layout, or receiver settings cause 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 this into real UAV 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.