Managing Multiple Drone Feeds Simultaneously With EyesOn
Three drones airborne. Three operators on the ground. One incident commander watching from a unified view in a command trailer two hundred meters back from the perimeter. Each feed has to be live, labeled, and sub-second latent. If any one of those feeds drops or buffers, someone makes a worse decision with worse information.
That is not a hypothetical scenario. That is exactly the operational pressure that multi-operator drone deployments create — and it is precisely the problem EyesOn was designed to handle without routing everything through a third-party cloud that charges per viewer minute, throttles feeds during peak load, or goes dark the moment your satellite uplink hiccups.
This post is about how EyesOn actually manages multiple simultaneous drone feeds: the architecture that makes it work, the practical workflow for coordinating operators, and what the experience looks like from the receiving end when you have five people watching the same airspace from different roles.
How EyesOn Handles Multiple Concurrent Streams
EyesOn runs entirely on your own infrastructure. One Docker container on a server you control — whether that's a rack unit in your operations center, a mini PC in a command trailer with a generator and a Starlink uplink, or a VPS you manage yourself. The platform does not phone home. Streams do not route through any intermediate relay you didn't set up.
The WebRTC layer is what enables the simultaneous feeds. Each drone operator running the companion Android app opens a separate stream. The server ingests those streams independently. Viewers then pull any combination of active streams through the browser interface — one window, multiple tiles, full-screen toggle per feed.
Latency on each stream runs at approximately 200 milliseconds end-to-end over a solid connection. When you have three feeds open simultaneously, that 200ms holds per stream — you are not distributing a single bandwidth budget across multiple feeds and watching each one degrade. They are independent WebRTC sessions. The server handles the routing. Your viewers consume what they need.
What the Companion App Sends
The companion Android app does something that matters more than most people initially realize: it captures the entire DJI controller screen, including the OSD data overlay. That means every viewer watching that feed sees the same flight telemetry the operator sees — altitude, speed, battery state, GPS lock, camera settings, gimbal angle.
When you are managing three feeds simultaneously at an incident, that OSD data is what lets the incident commander trust what they're seeing. A thermal return that looks like a heat signature means more when you can also see the altitude at which the operator is flying, confirm the camera mode, and verify GPS position against your site map. You are not watching raw video with no context. You are watching an operator's full situational display.
Multiply that across three concurrent feeds and you have a complete real-time aerial picture of an operation — not a slide deck, not a radio report, live streaming telemetry from every aircraft.
Practical Workflow for Multi-Operator Coordination
The stream management question is not just technical — it is procedural. Three operators in the air without a coordination plan create airspace conflicts, redundant coverage, and wasted flight time. EyesOn provides the visibility layer. The workflow is what you bring to it.
Here is how a multi-operator deployment works in practice:
Stream Naming and Feed Assignment
Before anyone launches, each operator registers their stream with a label that matches your operational naming convention. Bird 1, Bird 2, Bird 3 — or thermal north, wide south, command overwatch — whatever your team uses. That label persists in the interface for every viewer. When the incident commander pulls up the multi-feed view, they are not looking at three identical thumbnails trying to remember which operator is covering which sector.
This sounds minor until you are forty minutes into a search pattern at 11 PM and someone keys up on radio asking "which feed is the thermal pass on the north ridge?" With labeled streams, that question does not need to be asked.
Viewer Roles and Access
EyesOn runs on your server. You control who has the URL. There is no per-viewer seat charge, no viewer license, no metered consumption. If you have five people in a command element who need to watch — incident commander, logistics coordinator, agency liaison, documentation lead, safety officer — all five can watch simultaneously without adding a dollar to your operational cost.
On platforms like FlytBase, you are paying per viewer minute. On DroneSense, licensing runs $1,500 to $5,000 per drone per year and still routes your data through their infrastructure. With EyesOn Personal at $39 per month after the $149 setup, you are running unlimited drones and unlimited viewers on your hardware. The math on a multi-operator deployment is not close.
Bandwidth Management in the Field
The biggest practical constraint on multi-feed streaming from a field deployment is not the platform — it is uplink bandwidth. EyesOn does not manufacture bandwidth out of thin air. What it does is eliminate the overhead that cloud routing introduces. When your stream goes directly from the operator's Android device to your server to your viewers, you are not adding relay hops, re-encoding steps, or cloud routing latency into the path.
With a Starlink uplink in a command trailer (typical download 50-200 Mbps, upload 10-40 Mbps depending on conditions), three simultaneous 1080p WebRTC streams are manageable. If bandwidth is constrained, operators can dial back resolution per stream without the platform collapsing — each stream degrades independently and recovers independently.
What the Receiving End Actually Looks Like
The description of "multiple feeds" often conjures a wall of monitors in a movie-style command center. The reality for most operations is a laptop screen, a tablet, or a second monitor plugged into a command trailer workstation.
EyesOn's browser interface tiles active streams. A viewer can pull all active streams into a grid view, watching simultaneous feeds side by side, or go full-screen on a single feed when something specific demands attention. Switching between the two takes one click. There is no login process, no app install on the viewer side — access is browser-based.
The OSD Advantage in Multi-Feed Context
Return for a moment to the OSD capture. In a single-drone deployment, the telemetry overlay is useful context. In a multi-operator deployment, it becomes coordination infrastructure.
Consider a search scenario where Bird 1 is flying thermal at 200 feet AGL over the north sector, Bird 2 is doing optical zoom passes at 300 feet over the south sector, and Bird 3 is holding a high wide view at 400 feet as a command overwatch. The incident commander watching all three feeds in the tiled view can confirm altitude separation at a glance from the OSD overlays on each stream. No radio check required. No interruption of the operators' focus on their search patterns. The telemetry is visible on the stream.
That is the difference between video as evidence and video as operational awareness.
Enterprise and Managed Tier Configurations
For organizations running multi-operator deployments regularly — public safety agencies, enterprise security operations, large-scale inspection programs — the question of tier selection comes down to server count and support requirements.
EyesOn Personal ($149 setup, $39/month) covers one server, community support. For a solo operator who occasionally runs two drones simultaneously, that is sufficient. For a team where multiple operators need server access for different deployments running in parallel, Professional ($299 setup, $89/month) covers up to five servers with email support.
Agency operations with multiple simultaneous field deployments across different geographic locations — each deployment running its own server instance for data separation or bandwidth reasons — fit the Enterprise tier ($499 setup, $209/month), which removes the server count cap and includes priority support plus custom branding for client-facing deployments.
Managed ($999 setup, $499/month) is for organizations that want BarnardHQ to host and manage the infrastructure directly, with dedicated support and a service level agreement. The stream capability is identical across all tiers — what changes is scale, support structure, and infrastructure ownership.
One thing that does not change across any tier: if your subscription lapses, the software keeps running. Your streams keep working. Your data stays on your server. There is no kill switch.
The Actual Constraint Worth Planning For
Here is the honest answer to "how many concurrent streams can EyesOn handle?": it depends on your server hardware and your network uplink, not on the platform.
A basic VPS with 4 cores and 8GB RAM handles three to five concurrent streams without strain. A more capable server — or a dedicated machine in a command trailer — scales further. The platform does not impose an artificial stream limit to push you up a pricing tier. You are running Docker on your hardware. Configure the hardware to match your operational requirements.
For field deployments where server resources are constrained by what you can physically transport and power, plan your stream count against your hardware realistically. Three concurrent full-quality streams on a capable mini PC with a generator and Starlink is straightforward. Ten concurrent streams from a Raspberry Pi is not.
The platform handles the routing. You handle the infrastructure sizing. That is the self-hosted contract, and it is a better deal than paying per drone per year to route your operational footage through someone else's servers indefinitely.
---
If you are building out a multi-operator configuration and want to verify your server spec against your planned stream count before purchasing, the [EyesOn documentation](https://eyeson.barnard.hq) covers hardware recommendations by deployment scale. Start there before you start anywhere else.
← Back to all posts