› FPV Drone Video Latency & FPS Budget Simulator Back
FPV / Video Link

FPV Drone Video Latency & FPS Budget Simulator

Estimate FPV drone glass-to-glass latency (sensor → encoder → RF → decoder → display), required bandwidth, range margin and total pilot response time in real time. Switch between analog 5.8GHz, DJI O3, HDZero and Walksnail Avatar to see whether your link sits in the Race, Freestyle, Cinematic or Casual class.

Parameters
Video link system
Preset for encoder latency, max range and noise tolerance
Camera resolution
p
Frame rate
fps
Encoder bitrate
Mbps
Target bitrate configured on the air unit
TX-RX distance
m
Antenna gain
dBi
Gain of the receive patch / helical antenna
Pilot reaction time
ms
Simple-reflex baseline (humans: 200-300ms)
Results
—
Sensor latency (ms)
—
Encoder latency (ms)
—
Total latency (ms)
—
Pilot total response (ms)
—
Required bandwidth (Mbps)
—
FPV class
—
Signal path — drone camera to goggles

Visualises camera → encoder → RF → goggles → pilot reaction as a glass-to-glass stacked bar. Colour follows Race (green) / Freestyle (blue) / Cinematic (orange) / Casual (red).

Total latency vs FPS
System compare — encoder latency and max range
Theory & Key Formulas

$$t_{\text{total}} = t_{\text{sensor}} + t_{\text{enc}} + t_{\text{tx}} + t_{\text{dec}} + t_{\text{disp}}$$

Glass-to-glass latency. $t_{\text{sensor}}=1000/\text{FPS}$ (one exposure frame), $t_{\text{disp}}=1000/(2\,\text{FPS})$ (half a scan frame), $t_{\text{tx}}=d/c$ (RF propagation).

$$\text{BW}_{\text{req}} = \frac{p^{2}\cdot\frac{16}{9}\cdot\text{FPS}\cdot k}{10^{6}}\,[\text{Mbps}]$$

Required bandwidth. $p$: resolution (vertical lines), $k$: compression factor (≈0.5 for H.265-class codecs).

$$\text{LB}_{\text{dB}} = -30 + G_{\text{ant}} - 20\log_{10}(d/100)$$

Simple link budget. Attenuation scales with the log of distance $d$ (m) and is lifted by antenna gain $G_{\text{ant}}$ (dBi). $\text{rangeMargin}=d/d_{\max}$ above 1 means out of range.

What is the FPV Drone Video Latency & FPS Budget Simulator?

🙋
People keep saying "video latency is everything" for FPV. Where does the delay actually come from — is the RF link slow?
🎓
Radio waves travel at the speed of light, so even at 2 km you only spend about 7 µs (0.007 ms) in flight. The real culprits are sensor exposure, H.264/265 encoding and the goggle scan-out. At 60 fps each frame is 17 ms, and exposure plus display alone burns about 25 ms. Add an H.265 encoder and you pile on 20-40 ms more, which is why a digital link easily passes 50 ms total. That is exactly why analog 5.8 GHz, despite being old, still wins on pure latency for racing.
🙋
So if I crank FPS up, does latency drop with it? 60 → 120 fps should roughly halve it, right?
🎓
Good question. The sensor and display parts do halve — the 25 ms at 60 fps becomes about 12.5 ms at 120 fps. But the encoder latency (45 ms on DJI O3, for example) hardly cares about FPS, so the total drops a lot but never halves. Drag the "Total latency vs FPS" chart above and you can watch the curve flatten out. Also remember that 120 fps needs a 120 Hz goggle on the other end, which today is only HDZero and a couple of DJI modes.
🙋
My bitrate is set to 25 Mbps but the tool says I need 28 Mbps — that is a bit short. Is that actually a problem?
🎓
"Required bandwidth" is the theoretical floor below which the codec starts to struggle. Cross under it and you get blockiness and motion smear on fast pans. Real digital FPV systems usually run adaptive bitrate: rich pixels up close, fall back gracefully as range increases. If you fix a 25 Mbps cap and try 1080p60, a hard yaw spin will fall apart. That is why this tool flags a warning when (set bitrate / required bandwidth) is below 0.9.
🙋
"Pilot total response 308 ms" sounds like a lot. How do I think about it in real flight?
🎓
It is 250 ms of human reflex plus 58 ms of video latency. At 120 km/h (33 m/s) a racing quad covers about 10 m in 308 ms. In other words "by the time you see something and try to dodge, you have already flown 10 m". On a course with gates 10 m apart, getting video latency under 20 ms is literally what keeps you flying. Cinewhoop work flies slowly, so Cinematic class (60 ms total) is totally fine. Pick the latency target from the use case.

Frequently Asked Questions

Glass-to-glass latency is the sum of (1) sensor exposure (half to one frame at 1/FPS), (2) encoder processing, (3) RF propagation, (4) decoder processing and (5) display scan. RF propagation is only ~0.01ms even at several km and is negligible; the dominant terms are encoder/decoder time and the sensor/display frame time. Analog 5.8GHz has no compression and totals about 25ms, HDZero is an ultra-low-latency digital link at under 30ms, while DJI O3 and Walksnail land around 45-65ms.
This tool labels total latency under 20ms as Race (HDZero), 20-40ms as Freestyle, 40-80ms as Cinematic and above 80ms as Casual. Pylon racing requires under 20ms or your braking points will not match the gates. Freestyle aerial filming is comfortable at 30-40ms, and Cinewhoop-style cinematic shots tolerate over 60ms. Above 100ms the visual-control mismatch causes motion sickness and crashes, so the tool flags it as ng.
Required bandwidth is roughly resolution² × 16/9 × FPS × compression / 1e6. This tool uses a compression factor of 0.5 (H.265-class), giving about 28Mbps at 720p60 and 62Mbps at 1080p60. If your set bitrate is below this target you get blockiness and motion smear; if it is far above, the RF margin shrinks and your range drops. In real systems an adaptive bitrate that stays around 0.8-1.2× the required value is the pragmatic choice.
A practical target for total pilot reaction (pilotTotalReaction = video latency + human reflex) is under 300ms for racing and under 350ms for freestyle. Human simple reaction time is about 250ms, so an extra 50ms of video latency adds the same 50ms to the total. At 100 km/h that is about 1.4 m of additional travel — enough to cause a crash on tight gates. Choose your target from speed, obstacle density and gap distance.

Real-World Applications

Drone racing / MultiGP: Race quads pass 5-10 m gates at 150 km/h, so total latency under 20 ms is effectively the price of entry. Analog 5.8 GHz and HDZero dominate this niche, trading image quality for pure latency. In this tool, picking HDZero and pushing FPS above 90 puts you in the Race class.

Freestyle aerial filming: Power loops, bridge dives and other mid-speed, high-G stunts sit comfortably around 30-40 ms. DJI O3 and Walksnail at 60 fps land in the Freestyle class with a good balance of image quality and feel, with a GoPro on top for the master record.

Cinewhoops and cinematic platforms: Slow, cinematic moves only need Cinematic class (40-80 ms). Image quality and long-range stability matter more than latency, so DJI O3 at 1080p60 / 50 Mbps is a common pick. Use this tool to verify that range margin stays under 1 and that the colour-rich preset survives.

Industrial inspection and search drones: Bridge, power-line and mountain SAR missions live or die by range margin and RF headroom. Crank antenna gain past 12 dBi and check that the rangeMargin at 5-10 km stays under 1. Even latency above 100 ms is acceptable when you are mostly hovering.

Common Misconceptions and Pitfalls

The biggest misconception is "radio propagation is the main source of video latency". Radio travels at the speed of light, so even at 5 km you spend only 17 µs (0.017 ms). The dominant terms are sensor exposure, H.264/265 encoding and goggle scan-out — especially in digital systems where the encoder alone burns 30-60 ms. Try the latency breakdown above and notice that going from 100 m to 10 km hardly moves the total. Distance changes link budget and noise tolerance, not latency.

The next trap is "more FPS is always better". Sensor and display latency do shrink as 1/FPS, but the encoder has a near-constant overhead, so 120 fps does not halve the total. Worse, doubling FPS doubles the bandwidth requirement, so a fixed bitrate suddenly cannot keep up and you get more blockiness, not less. Getting real value from 120 fps requires camera, goggle and bitrate to all line up.

Finally, "my reflexes are fast, 100 ms of latency is fine". Human simple reaction time bottoms out around 200 ms; even with training, breaking 180 ms is nearly impossible. Add 100 ms of video latency and pilotTotalReaction crosses 300 ms — over 8 m of extra travel at 100 km/h, more than enough to crash on tight gates. Treat video latency as a physical quantity stacked on top of your reflexes, and budget your gear accordingly.

How to Use

  1. Select camera resolution (720p, 1080p, or 4K) and frame rate (25–120 fps) matching your FPV platform specs.
  2. Enter encoder bitrate in Mbps (typical range 4–50 Mbps for H.264/H.265) and transmission distance in meters.
  3. Review calculated sensor latency, encoder latency, total glass-to-glass latency, and pilot response time; verify required bandwidth against your video link capacity (5.8 GHz analog vs. digital systems).

Worked Example

Racing quad with 720p 60 fps camera, H.264 at 8 Mbps, 100 m transmission: sensor introduces ~8 ms (rolling shutter), encoder adds ~12 ms, RF propagation lag ~0.33 ms. Total glass-to-glass latency ~22 ms. Pilot reaction (~200 ms) plus vehicle response lag (50–80 ms quad) yields ~270 ms effective decision-to-control delay. Required bandwidth 8 Mbps fits 40 MHz analog 5.8 GHz channel (30 Mbps max). FPV class: low-latency racing.

Practical Notes

  1. Interlaced vs. progressive sensors: interlaced (PAL 576i, NTSC 480i) reduces sensor latency by ~8–10 ms but increases motion artifacts; progressive preferred for competitive FPV racing above 50 fps.
  2. Encoder selection matters: hardware H.264 on Betaflight F7+ ~8–15 ms; software encoding or WiFi modules ~30–50 ms; choose dedicated video encoder chips for sub-20 ms targets.
  3. Antenna position and polarization loss degrade signal at distance; budget 2–4 dB margin to maintain 95% frame delivery at rated range.
  4. Pilot effective response bottleneck: even with <20 ms video latency, human reaction adds 150–250 ms; optimize for consistency, not absolute minimum.