# MOQ Video Streaming for Robots, Drones, and Embedded Devices > Source: > Published: 2026-08-21 07:38:03+00:00 ## Table of Contents When people think about MOQ ( Media over QUIC), they usually picture [live sports](https://www.red5.net/solutions/sports-live-streaming/), [entertainment](https://www.red5.net/case-studies/red5-cloud-zixi-real-time-monitoring-and-streaming-solution-for-live-event-production/), or interactive broadcasts. Those are important markets, but some of the protocol’s most interesting opportunities may come from robots, [drones](https://www.red5.net/blog/drone-live-streaming/), and other embedded devices. A drone inspecting power lines, a robot entering a burning building, an underwater vehicle examining offshore infrastructure, and a remotely operated medical system all depend on timely video. However, the video may need to reach far more than one remote operator. Command centers, subject-matter experts, AI models, recording systems, and other authorized viewers may all need access to the same feed. That combination of real-time performance, one-to-many distribution, and support for multiple types of subscribers is where [MOQ](https://www.red5.net/blog/what-is-moq-media-over-quic/) could become the missing link. ## Why Robots and Drones Need More Than a Point-to-Point Video Link Remote devices often begin with a simple requirement: send video from a camera to an operator. Real deployments quickly become more complex. Consider a drone used during a wildfire. The pilot needs a responsive feed to navigate safely. Incident commanders may need the same stream for situational awareness. An AI service may analyze frames for smoke, people, or changing fire boundaries. A remote specialist may join to assess infrastructure damage, while the full stream is recorded for later review. The same pattern appears in many industries: - Public safety robots can send video to operators, incident commanders, and remote specialists. - Industrial inspection drones can share feeds with engineers, asset owners, and AI defect-detection systems. - Autonomous or remotely operated vehicles can deliver video and sensor data to control centers and fleet-management platforms. - Agricultural drones can stream crop imagery to operators and computer vision systems. - Underwater vehicles can connect offshore crews with experts located anywhere in the world. - Broadcast drones can supply live production feeds while creating recordings for replays and highlights. In each case, a single device may produce video that needs to be consumed live, processed by machines, recorded, replayed, and distributed to multiple locations. A point-to-point connection alone does not address the entire workflow. ## Where Current Streaming Protocols Fit Robots, drones, cameras, and embedded devices commonly use protocols such as RTSP, SRT, RTMP, or WebRTC. These protocols remain useful, and MOQ should not be presented as an immediate replacement for all of them. [RTSP is widely used by IP cameras and other connected devices](https://www.red5.net/blog/rtmp-vs-rtsp/), but browsers do not play RTSP streams natively. A platform typically needs to ingest the feed and convert or restream it for browser playback and broader distribution. [SRT](https://github.com/Haivision/srt) is designed to deliver reliable, low-latency video over unpredictable networks. Its configurable latency buffer allows retransmission of lost packets, but every workflow must balance additional recovery time against responsiveness. SRT is especially valuable for contribution links, although scaling a feed to many different consumers generally requires additional streaming infrastructure. WebRTC provides real-time browser communication and is already proven in interactive applications. However, it also brings connection-establishment components such as ICE, STUN, and TURN. H.264 is supported in WebRTC browsers, contrary to a common misconception, but interoperability can still depend on compatible H.264 profiles, levels, and packetization modes between an embedded encoder and the receiving endpoint. In some workflows, the stream may still need to be repackaged or transcoded. These technologies solve important parts of the problem. The opportunity for MOQ is to create a more unified path from contribution through distribution, processing, and playback. Requirement | RTSP | SRT | WebRTC | Potential MOQ fit | |---|---|---|---|---| | Common on cameras and embedded encoders | Strong | Growing | Varies | Emerging | | Real-time remote operation | Limited without added infrastructure | Strong with tuned latency | Strong | Designed for real-time delivery | | Native browser path | No | No | Yes | Yes through WebTransport-based implementations | | One-to-many distribution | Requires a media server | Requires a media server or distribution layer | Requires an SFU or media server | Relay-based publish-and-subscribe model | | Live and time-shifted access in one architecture | Limited | Limited | Usually requires added systems | A central design opportunity | | Ecosystem maturity | Mature | Mature | Mature | Still developing | ## What Makes MOQ Interesting for Embedded Devices The current [IETF Media over QUIC Transport draft](https://datatracker.ietf.org/doc/draft-ietf-moq-transport/) defines a publish-and-subscribe protocol that operates over QUIC or WebTransport. Publishers produce data, intermediate relays can subscribe to this data and can forward it on to subscribers who request it. That model maps naturally to device-based video workflows. ### One Published Feed Can Serve Many Subscribers A robot or drone could publish its feed once to the nearest MOQ relay. The relay architecture could then deliver that content to authorized subscribers rather than requiring the device to maintain a separate upstream connection for every viewer or system. Those subscribers might include: - A human operator controlling the device - A command center monitoring multiple devices - An AI model analyzing video or other data - A recording service preserving the session - A remote expert joining only when needed - A supervisor reviewing delayed or historical footage This matters because embedded devices have limited power, processing capacity, and uplink bandwidth. Offloading distribution to the network can reduce the work required at the device. ### Media and Related Data Can Share a Common Delivery Model Robots and drones generate more than video. They may also produce audio, GPS coordinates, equipment status, telemetry, detection events, or other sensor data. MOQ organizes content into addressable tracks, groups and objects. That creates the potential to transport related media and data through a common publish-and-subscribe model while preserving their logical relationships. An application could subscribe to the video and telemetry it needs without treating every data type as an unrelated workflow. This does not mean MOQ replaces a device’s command-and-control system. Control signals may have different reliability, safety, and timing requirements. However, MOQ could provide a consistent distribution layer for the video, audio, sensor data, and machine-generated events that support operational decisions. ### It Can Support Human and Machine Viewers In many next-generation video systems, the first viewer may be an AI model rather than a person. A computer vision service could inspect a drone feed for smoke, structural defects, unauthorized activity, or damaged equipment, then publish detection data for human operators. MOQ’s subscriber model could allow separate systems to request only the tracks or objects relevant to them. A browser might receive video and audio, while an AI pipeline consumes video plus metadata. A monitoring dashboard could subscribe to lower-bitrate previews from many devices and switch to a higher-quality track when an alert occurs. This type of selective distribution can make large fleets easier to operate than architectures that send every feed and every data element through the same fixed path. ### Live, Replay, and Recorded Workflows Could Converge Remote operations don’t end when the live moment passes. Teams often need instant replay, time-shifted review, evidence retention, training footage, or post-event analysis. Today, organizations may combine one protocol and infrastructure path for real-time operation with another for recording and on-demand playback. MOQ is being designed to support both real-time and non-real-time media delivery within a common architecture. For device operators, that could reduce the need to move between separate live and playback systems. This is one reason MOQ may be especially valuable for applications that combine live and on-demand streaming. A team could monitor an active inspection, jump back to review a suspicious moment, and return to the live feed without changing to an entirely different delivery architecture. ## Mobile Networks Make the Opportunity More Complicated Robots and drones frequently operate on unstable wireless connections. They may move between 5G, LTE, Wi-Fi, satellite, or private networks while bandwidth, packet loss, and signal strength change from one moment to the next. QUIC provides a useful foundation for changing network conditions, including multiplexed streams and modern congestion control. That does not mean MOQ automatically solves every mobility problem. One important example is network bonding. SRT-based tools such as [SRTLA](https://github.com/IRLServer/srtla_send) can distribute traffic across multiple network links for added capacity and redundancy. A field device might combine connections from different cellular carriers so a weak or failed link does not immediately interrupt the stream. MOQ will need practical answers for multipath connectivity, seamless handoffs, bandwidth adaptation, and rapid recovery if it is to support mission-critical mobile deployments. These capabilities may come from the protocol ecosystem, the underlying transport, device software, or surrounding network architecture rather than MOQ alone. As discussed in our article on the [emerging next-generation 5G streaming architecture](https://www.red5.net/blog/emerging-5g-streaming-architecture-has-major-implications-for-content-providers/), advanced mobile streaming will depend on cooperation between applications, transport systems, and network capabilities. The strongest device deployments will treat connectivity as part of the complete architecture rather than assuming one protocol can compensate for every network problem. ## Security, Reliability, and Control Still Matter Some of the most compelling robot and drone applications are also the least forgiving. Public safety, defense, industrial control, and remote healthcare cannot choose a transport protocol based on latency alone. A production architecture may need: - Strong authentication and authorization for devices and viewers. - Encryption in transit and, where required, end-to-end protection. - Resilience when a relay, network path, or device connection fails. - Audit logs and recording policies. - Predictable behavior under congestion. - Fine-grained access to individual media and data tracks. - On-premises, private cloud, [closed networks](https://www.red5.net/case-studies/connect-offline-secured-network-systems-to-the-gov-cloud-for-government-real-time-streaming/), or[air-gapped deployment](https://www.red5.net/solutions/air-gapped-live-streaming/). - Clear separation between media delivery and safety-critical control. MOQ’s security and media-format work is still evolving. For example, the IETF is developing a separate [secure objects specification](https://datatracker.ietf.org/doc/draft-ietf-moq-secure-objects/) for authenticated encryption between publishers and subscribers, including scenarios in which relays should not be able to decrypt the content. That work is promising, but an Internet-Draft is not the same as a mature, field-proven security profile. Organizations evaluating MOQ should test the complete system, not just the transport protocol. ## What Must Happen Before MOQ Becomes the Missing Link MOQ has a strong architectural fit for robots, drones, and embedded devices, but adoption will depend on more than a promising standard. - Device makers need efficient client implementations that can run within real limits on CPU, memory, battery life, and thermal performance. The industry also needs interoperable media formats, codec handling, hardware acceleration, and stable SDKs across embedded operating systems. - The ecosystem needs production-ready approaches to mobility. Network bonding, path changes, adaptation, and recovery must work under real field conditions, not only on stable test networks. - Operators need complete security and management capabilities. Provisioning thousands of devices, rotating credentials, enforcing permissions, monitoring performance, and updating software are essential parts of deployment. - MOQ implementations must prove interoperability as the IETF specifications continue to change. Teams evaluating the technology today should plan for revision rather than treating the current draft as a finished standard. Red5 is already contributing to this ecosystem through the [OpenMOQ Software Consortium](https://www.red5.net/blog/red5-joined-openmoq/) and our work across MOQ transport, relay, and playback technologies. Developers can also [evaluate MOQ](https://www.red5.net/media-over-quic-moq/) through the Red5 Cloud MOQ beta or discuss self-hosted Red5 Pro deployment options. ## Conclusion MOQ’s opportunity in robotics is not simply that it can move video with low latency. Its greater potential is to connect one constrained device with many human and machine consumers while supporting live monitoring, AI analysis, recording, and playback through a shared architecture. That could make MOQ a valuable foundation for drones, emergency-response robots, autonomous systems, industrial inspection tools, underwater vehicles, and other connected devices. Important gaps remain around mobility, security, embedded hardware support, and interoperability, so MOQ is not yet a universal answer. Still, if the ecosystem solves those gaps, robots and drones may become some of the strongest examples of why real-time media needs a modern publish-and-subscribe protocol in the first place. For another perspective on how MOQ supports real-time video use cases, see [5 Reasons MOQ Streaming Is a Great Fit for Surveillance and Monitoring](https://www.red5.net/blog/moq-streaming-is-a-great-fit-for-surveillance-and-monitoring/). Chris Allen is the co-founder and CEO of Red5, with over 20 years of experience in video streaming software and real-time systems. A pioneer in the space, he co-led the team that reverse-engineered the RTMP protocol, launching the first open-source alternative to Adobe’s Flash Communication Server. Chris holds over a dozen patents and continues to innovate at the intersection of live video, interactivity, and edge computing. At Red5, he leads the development of TrueTime Solutions, enabling low-latency, synchronized video experiences for clients including NVIDIA, Verizon, and global tech platforms. His current work focuses on integrating AI and real-time streaming to power the next generation of intelligent video applications.