Most of what is written about live drone video is either a product page or a forum thread. This guide covers how the video actually gets from a pilot standing in a field to people somewhere else, what each path can and cannot carry, and what tends to go wrong. Where a number is needed we cite where it came from, including our own bench measurements, so you can check it.
A drone flight already produces a good live picture. The pilot has it on the controller, sharp and low-latency, and has had it since the aircraft powered on. The problem is that the picture stops there.
Everyone else who needs it is somewhere else. An incident commander two streets away, a client who paid for the survey, an engineer who can identify the fault in a second if she can just see it. They are waiting on a description from someone whose attention is on flying. The pilot ends up narrating, and narration is slower and worse than the thing itself.
The problem to solve here is transport, not imaging. A good picture is already being produced; the work is getting a copy of it to people who are not standing next to the pilot.
There are three arrangements in common use. They differ in who runs the software, and in what travels alongside the video.
The app pushes the stream. Most consumer flight apps can send the live feed to a streaming address you type in. You paste in an address, the app starts sending, and the video comes out the other end wherever that address points. Nothing is installed, and the aircraft does not need its own connection because the app sends over the controller's or the phone's.
What travels is video. Position, altitude, battery and gimbal angle stay in the app. So does camera control. Anyone watching sees the picture and nothing else, which for many jobs is the whole requirement.
The platform binds the aircraft. Enterprise flight apps can sign in to an account on the controller, after which the aircraft is associated with that account instead of with a stream address. This carries more: the video, the telemetry, and in some setups the ability to hand camera control to an operator elsewhere. It is also narrower, because it needs an aircraft and an app that support it.
You run a relay yourself. For cameras and aircraft that do neither of the above, you run a piece of software near the camera that takes the local stream and forwards it out. This is the most general arrangement and the most work. It also decouples support from any one manufacturer's app, because the relay only needs the camera's local stream, usually RTSP, the protocol most fixed cameras already speak, rather than a partnership with the airframe vendor.
A useful way to keep these straight is to ask what decides whether a given setup works. For the push path it is usually the controller rather than the aircraft, because the streaming option lives in the app running on the controller. Two identical drones can differ if one is paired with a controller whose app offers no streaming option at all.
Worked example. On Nebli the first two paths need nothing installed. A pilot either pastes the stream address into the flight app, or signs in on an enterprise controller and the aircraft binds. Which one is available comes down to the controller, and our compatibility page lists it controller by controller. A pilot remains in command of the aircraft throughout on both paths; handing over camera control hands over the camera, not the flying.
When a live feed fails in the field, the link is usually the cause and the software usually is not. This is where most of the disappointment in live drone video lives, and the numbers involved are less obvious than people expect.
Flight apps present bitrate as a short menu rather than a number you set. In DJI's case the documented options are 2 Mbps or 1 Mbps on iOS and 5 Mbps or 3 Mbps on Android, with resolution offered as 1080p or 720p, and the resolution ceiling depending on which controller is in your hands. Those are DJI's published figures as of August 2026.
Those menu labels turn out to understate the traffic considerably. We put an enterprise aircraft on a bench, pointed it at a receiver and measured what actually left the controller. Against an in-app quality setting labelled "1.5M", the real upstream traffic ran between 9.5 and 14 Mbps, with the app's own live rate readout confirming north of 13 Mbps sustained. The encoder produced H.264 High profile at 1280 by 720, about 30 frames per second, with no audio track.
If you have sized a data plan from the label, size it again from the measurement. Budget closer to 14 Mbps than to 1.5.
A cellular uplink is not a fixed pipe. Throughput changes as the aircraft moves, as the tower loads up with other people, and as weather and terrain get in the way. Several things follow from that, and they show up in the video differently.
Packets go missing, and packets arrive out of order. The second is more common than people assume and is often mistaken for the first. On our own measurements a packet that appears lost has usually just taken a different path through the network and turns up 15 to 25 milliseconds later. Treating that as loss and asking for it again wastes capacity on a link that has none to spare.
Latency also moves with load. Round-trip times on a working link sit around 50 milliseconds and climb toward 600 when the link saturates. A viewer experiences that climb as the picture drifting behind the radio, then freezing.
Worked example. The Nebli relay that receives the self-run path waits 75 milliseconds before deciding a gap is genuine loss and not reordering, and only then asks for the packet again. The cost is about 75 milliseconds of recovery latency; the benefit is roughly an order of magnitude less retransmit chatter on a link that cannot afford it. Different systems draw that line in different places, and the line is a real engineering choice rather than a detail.
The failure arrives looking like a software problem. The picture stalls, someone reloads, it comes back, and the conclusion is that the platform is unreliable. Underneath, the uplink lost capacity for a few seconds while the aircraft was behind a building.
The practical consequence is that the useful questions are about the link. What was the uplink doing at the moment of the stall, was the aircraft moving, was the tower busy. Platforms differ in how gracefully they recover from a bad link, and that difference is worth shopping for. None of them adds capacity to an uplink that has run out of it.
Size the connection from measurements, not from labels. Take the highest sustained figure you have actually seen, not the app's quality setting. If you have no measurement of your own, use someone's published one and treat it as a floor.
Check the uplink where you will fly, not where you are standing. Signal at the staging area tells you very little about signal over the far end of the site. Bring up the stream from the actual position before it matters.
Decide what the far end needs before choosing a path. If the people watching need only to see, the push path is less to go wrong. If they need telemetry or need to take the camera, that requirement narrows your aircraft and app choices, and it is cheaper to know that before buying hardware.
Check the controller, not only the aircraft. On the push path the streaming option lives in the app on the controller, so the controller is what decides. This is the single most common surprise: the same drone that streams for a colleague will not stream for you if your controller's app has no such option.
Plan for the stream to drop. Field links fail. Decide in advance what happens then, whether the flight continues, whether someone re-establishes the link, and whether a recording on the aircraft or at the edge covers the gap.
Rehearse once with the people who will be watching. Most first live sessions lose time to someone not having the link, not knowing where to click, or being on a network that blocks the player. That is all discoverable in fifteen minutes on a day when nothing is happening.
Getting the video off the aircraft is only useful if it reaches people in a form they can act on.
Most of the people who need to see a flight will never have a login on your system. They are a client, a fire chief, an inspector, someone senior who needs thirty seconds of it. A path that requires each of them to be provisioned as a user is a path that does not get used, because the provisioning takes longer than the flight.
The workable pattern is a link that opens in a browser, with access controlled on the link itself instead of on each person. That raises a real question about who can open it, which is why link-level protection matters, and it is worth knowing whether a link expires, whether it can be revoked, and whether opening it is recorded.
The second half is what happens after the flight. If a flight matters enough to watch live, it usually matters enough to keep, and the people who most need it are often the ones who could not drop everything at the time. A recording held only on a card in the field is also at the mercy of whatever happens to the aircraft.
Worked example. On Nebli a flight becomes a private page protected by a PIN, which the pilot shares with whoever needs it, and the flight records to the cloud so the people who missed it can watch it afterwards. Recordings are stored and retrievable.
Live drone video is a transport problem with a well-understood shape. The picture already exists. The paths for moving it are few, and they differ mainly in what rides alongside the video and in who runs the software. Most failures in the field turn out to be link failures that presented as software ones, and most are predictable from measurements taken before the day.
If you are choosing a path, start from what the people at the far end actually need. Check the controller and not only the aircraft. Size the connection from a real measurement.
