How to Share a DJI Live Drone Feed with Incident Command
Practical options for getting the video off the pilot's tablet — ranked by latency, reliability, and what it costs in budget and procurement time.
If you have a DJI enterprise drone in the air, the hardest part of the job is usually not the flying. It is answering this question: how does the person actually making the decisions see what the drone is seeing, right now, without walking over to the pilot?
This post walks through every practical method available in 2026, ranked by what actually works under operational conditions. Spoiler: most of the "official" methods have problems nobody talks about in marketing material.
The actual problem
You're on a scene. Pilot is flying an M30T. The video is on their DJI RC Plus controller, full screen. Meanwhile, the Incident Commander is:
- In a command vehicle fifty yards away
- At a command post across the parking lot
- Back at dispatch, miles away
- On their way, still in transit
They all need to see the feed. None of them are holding the pilot's controller. This is the central video-distribution problem for every drone program.
Option 1: DJI's built-in RTMP broadcast
Every modern DJI enterprise aircraft can push an RTMP stream from Pilot 2 to a destination server. It's the "free" built-in answer.
What works: It exists, it's included, and it does produce video on a receiving server.
What doesn't:
- Latency. RTMP is push-based TCP. Combined with whatever transcoding happens on the receiving end (usually HLS re-packaging), you're looking at 8–30 seconds of delay. That's fine for B-roll. It's not operational video.
- You still need a server. RTMP has to go somewhere. You need to run or pay for an ingest server that accepts the stream and re-publishes it to viewers. Most agencies don't have one ready.
- Viewer experience. Recipients usually get HLS playback — buffered, delayed, and often with the "video is loading" spinner at the worst possible moment.
Use RTMP when: you need a public or semi-public broadcast (PIO posting to a press pool, training archive, post-incident review) and latency doesn't matter. Do not rely on it for tactical decision-making.
Option 2: DJI FlightHub 2 livestream
FlightHub 2 is DJI's cloud ops platform. It has a livestream viewer built in.
What works: If you already run FlightHub 2 for fleet management, adding a chief or supervisor as a viewer is straightforward. Latency is better than RTMP — typically 2–6 seconds.
What doesn't:
- Per-seat licensing. Every viewer needs a FlightHub 2 seat. For a 5-person command staff and 3 mutual-aid partners on a major incident, that's a procurement problem.
- Account friction. Every viewer needs a DJI account plus organization access. Not a workable mutual-aid model.
- Still not sub-second. 2–6 seconds of latency is better than RTMP, but still measurable lag on rapid events.
- Cloud dependency. Video transits DJI's infrastructure. Some agencies have policy constraints about that.
Use FlightHub 2 livestream when: all viewers are already inside your FH2 organization and the incident is slow enough that a few seconds of latency doesn't matter. This is a minority of operational scenarios.
Option 3: Screen-share over Zoom/Teams/WebEx
The pilot mirrors their controller to a tablet, joins a conference bridge, shares screen.
What works: Nothing, actually. Don't do this.
What doesn't:
- Ties up the pilot's tablet (can no longer fly)
- 15+ seconds of video compression latency
- Conference-bridge bandwidth collapses on poor networks
- Privacy nightmare if the bridge is public
Fine for after-action review with the chief in the office. Not for live ops.
Option 4: Hand them the controller
Worth calling out because people still do this. Pilot hands the RC Plus to the IC for a quick look. Now the pilot is not flying. The IC is reading sensor feeds instead of commanding the scene. Nobody's doing their job correctly.
If you're doing this regularly, you don't have a video distribution problem — you have a workflow gap. Fix the distribution.
Option 5: WebRTC via a purpose-built platform
This is what EyesOn does. Pilot's aircraft feeds live video into the EyesOn server (via RTMP ingest from DJI Pilot 2). The server converts to WebRTC and serves it to any browser. IC, safety officer, chief, and mutual-aid partners all open a URL and see sub-second video.
What works:
- Sub-second latency. 300–800 ms glass-to-glass. Operational video, not a recording.
- Browser-only for viewers. No app install, no account, no login.
- Time-limited guest links. Generate a link scoped to this incident, share it by text, revoke when done.
- Self-hosted option. Video stays on agency hardware if your policy requires it.
- FlightHub 2 compatible. Pairs with FH2 — you keep fleet management there, live video lives here.
Comparison
| Method | Latency | Viewer install | Mutual-aid sharing |
|---|---|---|---|
| RTMP broadcast | 8–30 s | Depends on receiver | Public-URL-ish |
| FlightHub 2 livestream | 2–6 s | DJI account + seat | Impractical |
| Zoom/Teams screen-share | 15+ s | App install | Doesn't scale |
| Hand over the controller | 0 s | None | Impossible |
| EyesOn (WebRTC) | 300–800 ms | None — browser only | Time-limited guest links |
What to do this week
- Figure out who actually needs to see the feed — not who "might as well" see it. Usually 3–6 roles.
- Test your current distribution method under realistic network conditions — LTE hotspot, congested Wi-Fi, VPN over flaky uplink. Time the latency with a stopwatch.
- If it's over 2 seconds, it's not tactical. Plan the upgrade path.
- If you want to skip the experiment, EyesOn runs on a $300 mini-PC at the station or a managed instance BarnardHQ operates for you. Four tiers from $39/mo.
Related
- EyesOn for Police & Sheriff
- EyesOn for Fire Service
- EyesOn for Search and Rescue
- Drones for Public Safety — Practical Guide
See the sub-second workflow in a 20-minute demo — straight pilot-to-pilot, no sales hurdle.
Request a Demo