Inside 16.7 milliseconds

That number is the whole design brief. Decode a frame, grade it, run a stack of effects on it, composite it, and push it out of five interfaces at once — and be finished inside 16.683 ms, every time, or the audience sees a judder instead of a show. Deckboy is free, so the temptation is to assume it is the slow option. It is not, and this page is the receipts.

Every effect is benchmarked, and over-budget is a bug

Deckboy has 36 video effects. Adding one is not finished when it looks right; it is finished when --effect-bench <name> 1920x1080 says it fits inside a frame. That check has caught every single one of them at least once, and in each case the cost was somewhere other than where it looked:

Effect	First working	Shipped	What it actually was
Grain flow	119 ms	13 ms	a luma conversion inside a 3×3 window — every pixel converting thirty-six neighbours its neighbours had already done — plus trig and a `pow` on frame constants in the pixel loop
Chladni	24 ms	7 ms	twenty sines per pixel. The plate equation is separable, so two tables the width of the frame replace all of them and the inner loop does no trigonometry at all
Crystallise	18 ms	16 ms	nine square roots per pixel to rank nine seeds. Ranking by the square gives the identical order; only the grain boundary needs a real distance
Any channel-wise effect	—	10–66×	if the output channel depends only on the input channel, it is a 256-entry lookup table, built from the same expression, byte-identical

Three rules came out of that work and they are enforced on every new effect: table anything that depends on one byte; parallelise the row loop unless the rows genuinely are not independent; and compute a smear on a reduced raster, because an effect whose job is to destroy detail does not need full resolution to destroy it. Grain flow's third-resolution pass is visually indistinguishable from the full one — as it would be.

None of this is a claim you have to take on trust. --effect-bench ships in the binary you download, and --effect-dump renders any effect headlessly so two builds can be compared frame-for-frame, byte-for-byte.

The picture never takes the slow road

Zero-copy GPU decode. Hardware-decoded frames stay on the GPU as D3D11 surfaces and are composited there. They are never downloaded to system memory and pushed back — the round trip that quietly costs a 4K player its frame rate.
10-bit is decoded as 10-bit. Only true NV12 takes the zero-copy path; P010 and everything else falls through to a correct conversion rather than being mislabelled. That distinction is the difference between HDR footage and a flat green screen.
The programme monitor is the output. The control window samples the finished composite on the output renderer, once per presented frame, rather than decoding a second time to show you a preview.
Readback uses the fast path per backend — D3D11's staging ring, or SDL_GPU's download. The portable synchronous read costs 16.8–18.8 ms at 4K, which is the entire frame, so it is a fallback and never the default.

Where the rest of the chain spends its time

For context, because the playback machine is usually blamed for delay it did not cause. At 59.94, one frame is 16.683 ms:

Stage	Cost	Whose
Capture	1 frame, always — the sensor has to finish reading out	physics
Encode	1 frame intra-only; 2–8 for long-GOP H.264/HEVC	your choice
Transport	SDI effectively nil; ST 2110 on PTP under 1 ms; SRT whatever you set	the network
Display	1–3 frames of scaler nobody publishes	the venue's

Deckboy sits at the encode stage, and it is the stage where the choice is actually yours. It sends uncompressed ST 2110-20 — one 1080p59.94 10-bit 4:2:2 flow is 2.49 Gb/s, UHD is 9.95 Gb/s — alongside NDI, SRT, RTMP and SDI, simultaneously. Uncompressed IP video is normally the preserve of equipment that arrives with a quotation attached.

The effects nothing else has

Speed is table stakes. The more interesting claim is the work that a plug-in structurally cannot do, however fast it runs.

Every audio effect ever written receives a buffer of samples and nothing else. That is not a limitation anybody chose; it is what a plug-in is. A compressor inside a mixing desk cannot know that the thing it is compressing is a drone shot, that the shot sits a quarter of the way across the screen, that it has four seconds left, or that the operator has just held it.

Deckboy keeps the picture and the sound in one object, so 5 of its 14 audio effects read the frame they are playing under:

Picture — the cue's own video drives the filter.
Placement — where the picture sits on the raster is where the sound sits in the room.
Seam — the approaching end of the cue resolves the tail, so the outgoing sound lands with the cut instead of being chopped by it.
Frame lock — granular stutter quantised to the video frame period, not to a tempo you guessed.
Suspend — a held cue keeps its room tone instead of stopping dead.

These are not ports of anything. No plug-in host can offer them, because no plug-in host has the frame to hand.

One honest boundary: the numbers above are Deckboy's own measurements, taken with tools that ship in the build so you can repeat them. They are not head-to-head benchmarks against Mitti, PlaybackPro, QLab, Millumin or vMix — running a fair test against five commercial products is not something this project can claim to have done. What it can say is what its own budget is, that it holds it, and that you can check.

Try the measurement yourself

End-to-end delay through your own chain, with no test equipment: put a running millisecond timer on a screen at the start, put the output display beside it in the same shot, and photograph both with a second camera at 1/1000 s. The difference between the two readings is your latency. Do it once per stage as well as end to end and you will find the frame nobody knew about — it is almost never where the argument said it was.

Deckboy has an A/V delay beacon built in for exactly this: a white frame with a click on the same frame, so the offset comes back in samples rather than in opinions.

Download Deckboy How it compares