DJI RTMP Broadcast: What It Can and Can't Do
DJI's built-in RTMP is free and works on every enterprise controller. Here's what it actually does — and where it falls down under operational use.
DJI ships RTMP livestreaming in Pilot 2. It's a checkbox option in the camera menu, it's free, and it works. Which is why most operators try it first — and why so many end up frustrated when they realize what RTMP was designed for and what they actually need.
This post is an honest breakdown: what RTMP broadcast gets you, where it breaks down, and the three questions to ask before you commit a drone program to an RTMP-first workflow.
What RTMP actually is
Real-Time Messaging Protocol is a streaming protocol originally designed by Macromedia in the early 2000s for Flash Player. It's a persistent TCP connection where a publisher (your drone controller) pushes video chunks to a server. The server then typically re-packages the stream as HLS (HTTP Live Streaming) for consumption by viewers.
"Real-Time" in the name is aspirational. RTMP was built for broadcast, not for interactive video. The full path looks like this:
- Camera captures frame
- Drone encodes to H.264
- Controller relays via RTMP TCP session to ingest server (adds a few hundred ms)
- Server repackages into HLS segments (typically 2–6 second chunks)
- Viewer player downloads segments over HTTP, buffers 1–3 segments, plays back
Glass-to-glass: 8–25 seconds on a typical deployment. On well-tuned Low-Latency HLS, you can sometimes get down to 4–8 seconds, but that requires a server that supports LL-HLS and a player that supports it too.
Where RTMP actually works well
RTMP is good at what it was designed for:
Public-facing broadcasts
A PIO posting drone footage of a scene to a press pool URL. A live feed during a planned event. Training footage archived to a department video library. None of these care about 15 seconds of delay.
Archive and after-action
If you're streaming so the video ends up recorded on a server for later review, RTMP is fine. Latency doesn't matter because nobody's making real-time decisions off the stream.
Large-audience streaming
RTMP-to-HLS scales cheaply. A single ingest server can fan out to thousands of viewers over CDN-delivered HLS. For streams with audience scale but no interactivity, RTMP is the right tool.
Where RTMP falls down
Tactical decision-making
An IC deciding whether to send an entry team based on what a drone is seeing through a window has one requirement: sub-second video. Fifteen seconds of delay is not a "minor latency issue" — it's watching a different event than the one currently unfolding. RTMP fails this test completely.
Multi-viewer operations
RTMP with HLS downstream works for viewer count, but each viewer still buffers their HLS segments independently. Two viewers watching "the same stream" can be 2–6 seconds apart from each other. For coordinated ops where multiple roles are deciding together, that's a problem.
Guest sharing and access control
RTMP ingest is just a URL. Downstream viewer access is whatever your HLS server provides — usually a public URL or a simple token. Time-limited, revocable, signed guest links aren't native. You can build them; they aren't free.
Low-bandwidth or variable networks
RTMP over TCP is fragile on networks with packet loss. A brief uplink hiccup triggers TCP retransmission cascades that can freeze the stream for seconds. WebRTC's UDP foundation with congestion control handles this dramatically better.
Bi-directional anything
RTMP is one-way push. If you ever want a feature that involves feedback — sending a command back to the pilot, enabling two-way audio, synchronizing overlays — RTMP is architecturally the wrong layer.
Real-world numbers from DJI Pilot 2
A rough field-test benchmark, Matrice 30T + RC Plus over LTE:
| Hop | Typical Latency |
|---|---|
| Camera → Controller display | 50–150 ms |
| Controller → RTMP server (LTE) | 300–1500 ms |
| RTMP → HLS segment creation | 2000–6000 ms |
| HLS player buffering (2–3 segments) | 4000–18000 ms |
| Total glass-to-glass | 6–25 seconds |
Wired Ethernet and a LL-HLS player can shave the bottom end closer to 3 seconds. That's still not operational video.
What to use instead
For tactical, sub-second, guest-viewable video:
- WebRTC-based platforms — purpose-built for low latency and browser delivery. EyesOn is what we build here. 300–800 ms glass-to-glass.
- SRT / ZeroLatency streaming protocols — for operators who want to build their own pipeline and can tolerate more complexity.
For broadcast, archive, PIO, and training: RTMP is still the right tool. Don't fix what isn't broken.
Quick test for your use case: if you'd be satisfied watching your drone feed delayed by 15 seconds on a TV news rebroadcast, RTMP is fine. If even one person making decisions needs to see "now" — you need WebRTC.
Related
- DJI Live Streaming: Every Method Explained
- How to Share a DJI Live Drone Feed with Incident Command
- EyesOn — Sub-Second WebRTC Drone Streaming
See WebRTC drone streaming in a demo. Twenty minutes. No sales call.
Request a Demo