UDP/Multicast Streaming — Low-Latency LAN Transport with FFmpeg

What You Will Learn

• The characteristics of UDP streaming: connectionless and low-latency, but with no packet-loss recovery
• Unicast (one-to-one) send and receive commands
• How to distribute via multicast (one sender → multiple receivers)
• Key parameters: the meaning and use cases of pkt_size, fifo_size, and overrun_nonfatal
• A production-grade command that re-encodes while sending
• The decision criteria for choosing between UDP, RTMP, and SRT

Tested with: FFmpeg 6.1 (verified against real FFmpeg) Target OS: Windows / macOS / Linux

What Is UDP Streaming

UDP (User Datagram Protocol) is a transport protocol that, unlike TCP, operates in a connectionless manner. Because it performs no handshake or retransmission control, its overhead is small, allowing video to be transported with low latency. FFmpeg supports this UDP transport directly through the udp:// protocol.

There is, however, an important precondition with UDP: there is no mechanism to recover from packet loss. Unlike SRT or TCP-based RTMP, packets lost in transit are not retransmitted. In other words, if the network drops packets, the video degrades accordingly.

Because of this property, UDP streaming is best suited to the following use cases.

For the container carried over UDP, use MPEG-TS (MPEG Transport Stream), which is well suited to streaming. In FFmpeg you specify it with -f mpegts. MPEG-TS is composed of fixed-length 188-byte packets and can begin receiving partway through (it is self-synchronizing), which makes it ideal for live transport.

Unicast Send and Receive

Unicast is one-to-one transport that delivers from a single source to a single destination. You specify the receiver’s IP address and port.

Sending (No Re-Encoding)

If the input is already in a codec well suited to streaming (H.264 + AAC), streaming it as-is without re-encoding is the most lightweight approach.

ffmpeg -re -i input.mp4 -c copy -f mpegts "udp://192.168.1.50:1234"

• -re — reads the file at its native frame rate. Without this, FFmpeg sends the file out as fast as possible, which does not work as live transport. It is essential for real-time streaming.
• -c copy — copies the streams without re-encoding. CPU load is low and there is no quality degradation.
• -f mpegts — specifies MPEG-TS as the container carried over UDP.
• udp://192.168.1.50:1234 — the destination (receiver) IP and port.

Receiving and Saving

On the receiving side, you can specify 0.0.0.0 to listen on all of your interfaces and save to a file.

ffmpeg -i "udp://0.0.0.0:1234" -c copy received.mp4

0.0.0.0 means “receive on the specified port across all interfaces on this machine.” With -c copy, it writes out to received.mp4 as-is without re-encoding.

Receiving and Playing (ffplay)

If your goal is monitoring rather than saving, you can verify playback directly with ffplay.

ffplay "udp://0.0.0.0:1234"

By starting the sender and receiver on separate machines (or in different terminals on the same machine), you can immediately try low-latency transport across a LAN.

Multicast Distribution

Unicast is one-to-one, but with multicast you can distribute simultaneously to multiple receivers from a single send. The sender simply pushes one stream onto the network, and compatible switches and routers replicate it only to the receivers that need it. The sender’s bandwidth does not increase even as the number of receivers grows.

Multicast uses a dedicated IP address range. A representative one is 239.0.0.0/8 (local scope, a range reserved for organization-internal multicast). Because it does not collide with global addresses, it can be used safely for distribution within a LAN.

Multicast Sending

ffmpeg -re -i input.mp4 -c copy -f mpegts "udp://239.0.0.1:1234?pkt_size=1316"

The difference from unicast is that the destination is a multicast address (239.0.0.1). Here we specify pkt_size=1316 (described later). You may substitute a different port number (1234) to suit your use.

Multicast Receiving

The receiving side simply specifies the multicast address being distributed.

ffplay "udp://239.0.0.1:1234"

Receivers that specify the same address — however many there are — can all receive the same stream. This shines in cases where you want to “deliver the same video to many devices,” such as digital signage or simultaneous distribution to a classroom.

Note that multicast depends on the configuration of routers and switches (IGMP support and so on). On consumer routers and some switches, multicast may be blocked or filtered, so if the distribution does not reach the receiver, check the configuration of your network equipment.

Key Parameters (pkt_size, fifo_size, overrun_nonfatal)

The UDP protocol has parameters passed via the URL query string (?key=value&...). Let’s organize the ones worth knowing for stable transport.

pkt_size

pkt_size is the number of bytes per packet sent over UDP. Since MPEG-TS is a fixed length of 188 bytes, the standard practice is to make it an integer multiple of that.

188 bytes × 7 = 1316 bytes

pkt_size=1316 corresponds to exactly seven MPEG-TS packets, and it also fits within a typical Ethernet MTU (1500 bytes), which avoids IP fragmentation. It is the recommended value when streaming MPEG-TS over UDP.

ffmpeg -re -i input.mp4 -c copy -f mpegts "udp://192.168.1.50:1234?pkt_size=1316"

fifo_size and overrun_nonfatal

The receiving side temporarily buffers arriving packets in an internal FIFO buffer (ring buffer) before processing them. When the send rate is high, or when receive processing temporarily cannot keep up, this buffer can overflow.

• fifo_size — enlarges the receive FIFO buffer to absorb momentary spikes in inflow. The unit is the number of packets, and making it larger than the default helps suppress dropouts.
• overrun_nonfatal=1 — when the buffer overflows (overruns), it continues processing rather than stopping with an error. This is useful when you do not want to stop receiving even at the cost of some loss.

A receive command combining both is as follows.

ffmpeg -i "udp://0.0.0.0:1234?overrun_nonfatal=1&fifo_size=1000000" -c copy received.mp4

fifo_size=1000000 reserves a larger buffer, and overrun_nonfatal=1 keeps it from crashing even when it overflows. In environments where the “Circular buffer overrun” warning appears, these two stabilize the stream.

Re-Encoding While Sending

When the input codec or bitrate is unsuitable for transport as-is (too large, an unsupported codec, and so on), re-encode at send time. The following settings are mindful of low latency and a constant bitrate for live transport.

ffmpeg -re -i input.mp4 -c:v libx264 -preset veryfast -b:v 2000k -maxrate 2000k -bufsize 4000k -pix_fmt yuv420p -g 60 -c:a aac -b:a 128k -f mpegts "udp://192.168.1.50:1234?pkt_size=1316"

The intent of each option is as follows.

By suppressing bitrate spikes with -maxrate and -bufsize, you prevent exceeding the bandwidth during UDP transport and inducing packet loss. By inserting periodic keyframes with -g 60, the receiver can begin showing video in a short time even when it connects partway through.

Choosing Between UDP, RTMP, and SRT

You select live transport protocols by use case. Let’s organize the characteristics of each.

The guidelines for deciding are as follows.

• UDP — when you want to minimize latency above all on a closed, managed LAN. It assumes a low-loss environment such as a direct switch connection. It is unsuited to crossing the internet or to lossy paths.
• SRT — when you want to maintain low latency even across the internet. Although UDP-based, it recovers from packet loss with its own retransmission (ARQ), compensating for UDP’s weakness.
• RTMP — when pushing video into a distribution platform. Many services support it as an ingest endpoint, and being TCP-based, it is reliable.

It helps to remember: “every millisecond of latency counts on a LAN” → UDP, “want it stable across the internet” → SRT, “want to ingest to a distribution service” → RTMP, and you won’t be at a loss.

Common Errors and Fixes

Cannot Receive

This is the most common case. Check the following in order.

• Port number mismatch — are the sender and receiver specifying the same port (e.g., 1234)?
• Firewall — is the receiving machine’s firewall blocking the relevant UDP port? Open the receive port on Windows or Linux (ufw/firewalld).
• Multicast blocking — for multicast distribution, if the router or switch is configured not to forward multicast (IGMP), it will not arrive. Isolate the issue by testing under the same switch, checking the multicast settings of network equipment, and so on.

Video Is Garbled

If you see block noise or audio dropouts, packet loss is likely occurring. Because UDP cannot recover from loss, the fix lies on the underlying network side.

• Secure bandwidth (lower -maxrate to reduce the bitrate, switch to wired).
• Resolve congestion along the path.
• For a path where loss is truly unavoidable, consider migrating to SRT, which has loss recovery.

Circular buffer overrun

This is a warning indicating that the receiving side’s buffer is overflowing. It appears when receive processing cannot keep up with the inflow.

ffmpeg -i "udp://0.0.0.0:1234?overrun_nonfatal=1&fifo_size=1000000" -c copy received.mp4

Increase the buffer capacity by enlarging fifo_size, and keep it from stopping on overflow with overrun_nonfatal=1.

Latency Is High

If you enlarge the buffer too much, latency increases by that amount. Since it is a trade-off against stability, tune fifo_size to “the minimum within a range that doesn’t drop out.” If you prioritize low latency above all, set the -preset for re-encoding faster and avoid excessive buffer settings.

Related Articles

• SRT Streaming — Low-Latency, Reliable Transport Across the Internet
• RTMP Streaming — Ingest to Distribution Platforms
• HLS Segment Generation — Creating Segments for Web Streaming

Tested with: ffmpeg 6.1.1 / Ubuntu 24.04 (verified against real FFmpeg)
Primary sources: ffmpeg.org/ffmpeg-protocols.html#udp / trac.ffmpeg.org/wiki/StreamingGuide

FAQ

Should I use UDP or SRT?

If the path is a managed LAN with low loss, lightweight, ultra-low-latency UDP is the first candidate. For paths where loss is unavoidable, such as across the internet or over wireless, SRT — which has loss recovery (ARQ) — is more suitable. Because UDP cannot recover dropped packets, it is at a disadvantage where reliability is required.

Why is pkt_size 1316?

Because MPEG-TS packets are a fixed length of 188 bytes, and seven of them (188×7=1316) fit exactly within an Ethernet MTU (1500 bytes), avoiding IP fragmentation. It is the standard value when streaming MPEG-TS over UDP.

Which multicast address range should I use?

For local use within a LAN, 239.0.0.0/8 (local scope) is safe. It does not collide with global addresses and is reserved for organization-internal multicast. If the receiver specifies the same address and port as the sender, multiple devices can receive the same stream simultaneously.

What happens if I forget to add -re?

FFmpeg sends the file out as fast as possible, and the receiving side cannot process it in real time, so things break down. When streaming a file as if it were live, -re, which reads at the native rate, is essential.