Signal latency and frame delay: from source to screen

What is a latency budget on a live video chain?

A latency budget is the total delay a chain is allowed to add between the source and the screen before the image stops matching the event. It is written down in milliseconds, then divided among the stages: capture, conversion, transport, processing, display. Each stage reports its own contribution, and the sum is compared to the budget rather than to the previous stage.

Measurement is done with a test pattern, not with content. Color bars, a clock with a frame counter, or a flash recorded by both the camera and a reference display give a number that can be repeated. Without a pattern, latency is estimated from memory and the estimate drifts with the operator.

How do test patterns reveal where the image stops being faithful?

A test pattern makes each stage visible in isolation. Bars show whether the signal is being clipped or shifted in level; a moving counter shows how many frames of delay sit between the source and the display; a still frame held for several seconds shows whether the chain is dropping or repeating frames. The pattern does not judge the image, it exposes the chain.

The moment of unfaithfulness is not a single failure. It arrives in stages: first the delay exceeds the budget, then the operator compensates by anticipating, then the audience sees a gesture and its image separated in time. The image is still sharp and correctly colored at that point. It has simply stopped being a record of the event.

How do frame delays and disposal methods work in a GIF build?

A GIF has no transport stage, so its budget is spent entirely on frame timing and on what happens between frames. Frame delay is expressed in hundredths of a second, and the encoder rounds it; a delay of 4 is 40 ms, a delay of 10 is 100 ms. The disposal method decides whether the previous frame is kept, restored to background or replaced, and that choice changes both the file size and the perceived smoothness.

A practical sequence for setting both:

The viewer perceives the loop when the first frame and the last frame do not connect, or when a repeated element lands on a different pixel. That is the GIF equivalent of a latency overrun: the image is intact, but the cycle is visible.

1. Fix the intended frame rate first, then convert it to hundredths of a second and accept the rounding error.
2. Choose the disposal method per frame: keep for overlays, restore to background for full replacements, previous for reversible effects.
3. Encode a short loop and play it at the intended size, not at full resolution.
4. Measure the loop duration and compare it to the intended cycle; adjust one frame delay rather than all of them.
5. Re-encode only after the timing is correct, since disposal changes affect palette and size.

Where does the direct stop being faithful on screen?

On a projection chain, the room is part of the budget. Throw distance, image size, and the surface, whether screen, scrim, smoke or water, change both the delay and the legibility of the image. A larger image takes longer to read, so a delay that was acceptable on a monitor becomes visible on a wall.

The same holds for a GIF placed in a live context. If the loop is projected next to a performer, the audience compares two time bases. The loop is faithful only while its cycle stays shorter than the gesture it accompanies, or long enough that the repetition is not read as a rhythm.