Say “LED control over a network” and most people think Art-Net or sACN. Both come from the entertainment industry, both are standardized, both run on big stages. DDP and WARLS live in a different corner. They grew up in the WLED and hobbyist community, barely show up in lighting-console manuals, and still have good reasons to exist.
This post explains what the two protocols are, how they work under the hood, and when it pays to look past the Art-Net horizon.
Why these two are outsiders
Art-Net and sACN think in DMX universes: 512 channels per universe, a fixed grid inherited from stage lighting. For a few hundred pixels that already means doing math with universes, start channels, and mapping.
DDP and WARLS drop that grid. Both address pixels and their position in the strip directly. No universe, no 512-channel boundary to keep in your head. That is exactly why they are popular in the WLED world, where an ESP32 often drives a few hundred pixels on a WS2812B strip and nobody wants to carve up a DMX universe.
DDP: lean and pixel-oriented
DDP stands for Distributed Display Protocol and comes from 3waylabs. It runs over UDP on port 4048 and is built to move pixel data with as little overhead as possible.
The header is only 10 bytes. It holds a flags byte with version bits and the so-called push bit, a sequence number, a byte for the data type, a destination ID (1 is the default output), a 4-byte offset, and a 2-byte length field. The color data follows right after.
The offset is the heart of it. Instead of sending each pixel with its own index and color, DDP just says “starting at pixel X, here come N bytes of color data.” The strip fills up sequentially. A single packet carries up to 480 RGB pixels, or 1440 bytes of payload, which fits neatly into a standard Ethernet frame with a 1500-byte MTU. If you have more pixels, you spread them across several packets.
To make sure the image updates only once every packet has arrived, the flags byte carries the push bit. Software like LedFx sets it only on the last packet of a frame. The earlier packets fill the buffer quietly, and the final one triggers the output. Nothing flickers, even when a frame arrives across four or five packets.
DDP also supports RGBW, meaning an extra white channel, and in theory it handles timecodes in the header. WLED does not read those optional timecodes, though. So if you are counting on frame-accurate sync, do not rely on DDP timecodes.
WARLS: WLED’s own realtime format
WARLS belongs to WLED’s family of UDP realtime protocols and lives on port 21324 (configurable in WLED). Its structure is deliberately simple.
The first byte sets the protocol, and for WARLS that value is 1. The second byte decides how long WLED stays in realtime mode before it returns to its normal display. One or two seconds is typical, and the value 255 keeps realtime mode open until the packets stop. After that, each pixel gets a four-byte block of index, red, green, and blue.
| Byte | Meaning |
|---|---|
| 0 | Protocol (1 = WARLS) |
| 1 | Timeout in seconds (255 = unlimited) |
| 2 + n×4 | LED index |
| 3 + n×4 | Red |
| 4 + n×4 | Green |
| 5 + n×4 | Blue |
Because the index takes only one byte, WARLS tops out at 255 pixels. That is plenty for ambient lighting behind a TV or a small strip, but not for a building facade.
The upside of the index: WARLS does not have to send the whole strip. If only three pixels change, only three four-byte blocks go over the wire. For an effect that moves few pixels, that saves a noticeable amount of data.
The siblings of WARLS
WARLS rarely travels alone. WLED ships three related formats that share the same timeout byte up front but differ after that.
DRGB (protocol value 2) drops the index and simply sends red, green, blue for pixel 0, 1, 2, and so on. It is the classic full-frame stream and manages around 490 pixels per packet. DRGBW (value 3) does the same with an added white channel and therefore reaches about 367 pixels. DNRGB (value 4) breaks the 255-pixel limit: its first two data bytes give a start index, so across several packets you can address strips with thousands of pixels.
In practice that means WARLS for targeted single pixels, DRGB for a continuous stream on small strips, and DNRGB for anything larger. If you have the choice and you move a lot of pixels, you usually end up on DRGB or DNRGB rather than WARLS.
DDP or WARLS, and where do Art-Net and sACN fit?
For a WLED setup with a few hundred pixels, DDP is often the calmer choice. It moves large frames efficiently, has no 255-pixel ceiling, and syncs the image through the push bit. WARLS and its siblings become interesting when you need fast, small changes, or when a tool speaks only those formats anyway.
The moment several controllers need to run in sync, many universes come into play, or professional consoles and media servers join in, there is barely a way around Art-Net or sACN. Their reach across the industry is the real reason to use them. DDP and WARLS stay the pragmatic answer for the WLED corner: little overhead, no universe thinking, quick to set up.
In PixDrive Studio
PixDrive Studio speaks both protocols directly, alongside Art-Net, sACN, and TPM2.NET. That lets you send the same show to a WLED controller without a detour, whether the target expects DDP or listens for the WARLS stream. For small WLED projects, one click is often enough, with no universe mapping to work through first.
Which protocol fits a given setup best depends on the pixel count, the hardware, and whether several devices need to run in sync. For the underlying Art-Net versus sACN question, there is already a separate post.
The documentation to read up on
The official DDP specification from 3waylabs is at http://www.3waylabs.com/ddp/. How WLED implements DDP, including the port and the note about timecodes, is described in the WLED docs at https://kno.wled.ge/interfaces/ddp/. A readable account from the sending software’s side comes from the LedFx documentation at https://docs.ledfx.app/en/latest/devices/ddp.html.
WARLS and the related formats DRGB, DRGBW, and DNRGB are documented with their byte layout in the WLED docs on UDP realtime protocols: https://kno.wled.ge/interfaces/udp-realtime/. The matching wiki page on GitHub goes a bit deeper in places: https://github.com/wled/WLED/wiki/UDP-Realtime-Control.