Line-accurate SDI output: what the card does, and what the computer has to do

The claim

We hear it often, from people who have run playout for years: line-accurate HD-SDI output needs a server with two Xeon processors. The reason behind it is real. The conclusion does not follow from it, and this entry says why, with what our own two machines read on 12 November 2026.

Who draws the lines

An SDI output is a serial stream: every sample of every line, the blanking between lines, and the sound and data packets carried in that blanking, clocked out at a fixed rate by the output card’s own hardware. The computer never times a line. It hands the card complete frames, each picture with its sound and ancillary data, and the card plays each one in its slot.

The rate the card clocks at comes from one of two places. Running free, from its own oscillator. Genlocked, from a house reference on its reference input, so that its frames and lines start in step with every other device on that reference. The second is what “line-accurate” usually means in a facility: the output’s timing held against the house reference. That is a property of the card and the reference. The processor driving the card is not in that loop, whatever its socket count.

What the computer has to get right

Three things, and none of them is timing a line.

• Never be late. The card must hold the next frame before its slot comes round. Our engine keeps eight frames queued on the card, 160 ms at 1080p50, so a computer that is slow for a moment does not reach the output.
• The right frame in each slot. Which picture airs in which frame is arithmetic on a clock: the engine schedules on the machine’s TAI time, and each item starts on a frame of the output’s grid.
• Do each frame’s work in time. Decoding, converting the picture to the card’s format, the sound and the ancillary data, every 20 ms on each 1080p50 channel. That is a question of capacity. More cores buy capacity. They do not make a deadline more certain: the threads that keep time have to be kept clear of everything else, on any number of processors.

So the useful questions about a playout computer are how close its work comes to the frame period, and whether anything it does can make a frame late. Both can be measured, and the engine measures them on every frame.

What our two machines read

Both are built from retail desktop parts, one processor each; the parts are on our hardware page. We read the figures below from each engine’s own interface on 12 November 2026 at 16:16 UTC. Each is a reading of that afternoon, not a claim about any other.

The clock thread is the one that keeps time: at every frame tick it hands each channel its next frame, and decoding and conversion run on other cores. Its work at a tick is the share of the frame period that thread spends before it sleeps again. The first unit runs a newer engine, which hands a decoded frame on without copying it. The two machines differ in engine, processor and channel count, so we compare neither with the other; each reading stands for its own machine.

Where the two-socket advice comes from

The advice has a sound origin. Playout has long done in software what no card does for it: decoding several streams, drawing graphics, often on a general-purpose operating system with no real-time care taken. There, a frame not ready in time went to air, and more cores were the cheapest insurance against it. That insurance buys capacity, and capacity is worth having. It does not touch the output’s line timing, which the card owns.

The worst timing events in our own record were two wakes of the clock thread more than half a millisecond late, in a fourteen-day run in August on a machine playing one channel. Neither reached the output: the card had its queue. Chasing them took us into where Linux places a sleeping thread’s timer, not into a shortage of processing; that work, and what it did and did not settle, is in its own entry.