How to measure realtime video API latency and responsiveness
Measure first-frame time, control-to-visible delay, delivered FPS and stalls. Evaluate a realtime video or world model through the client your users see.
Measure a realtime video API from the user's client. At minimum, record time to first visible frame, control-to-visible delay, delivered frame rate and stalls. Server-side generation speed is useful, but it leaves out transport, buffering, decoding and display.
A single latency number cannot describe every model. Live editing reacts to incoming camera frames; an interactive world reacts to movement; a window-generating model may finish a whole block before playing it. Define the interaction before comparing numbers.
Use precise measurement boundaries
| Metric | Start | End | What it explains |
|---|---|---|---|
| Connect-to-ready | Client begins connecting | Ready state reaches the client | Queueing and startup experience |
| Ready-to-first-frame | Client receives ready | First generated frame is displayed | Generation bootstrap and media delivery |
| Control acknowledgement | Client sends a command | Acknowledgement arrives | Control-path responsiveness |
| Control-to-visible | Client sends a command | Its intended change appears on screen | What the user experiences |
| Frame gap | One displayed frame | Next displayed frame | Stalls and uneven playback |
Use a monotonic clock for intervals measured on one client. Avoid subtracting timestamps from unsynchronized machines. For controls with an identifiable change, pair the command timestamp with the displayed-frame evidence; otherwise label the result as an approximation.
Distinguish generated frames from delivered frames
Native generation FPS describes model output before delivery processing. Delivered FPS describes frames received or displayed by the client. Interpolation, repetition and upscaling can make those values differ.
Report both when available, with resolution and interpolation settings. Do not call a 30 fps displayed track 30 fps native generation without measuring the native path. Also report gaps: an average frame rate can hide long freezes followed by a burst.
Run a repeatable interaction
For a prompt-driven model, use a visible scene change at fixed intervals. For a world model, use a fixed movement-and-turn sequence. For camera editing, use a repeatable moving source and a recognizable edit.
Include several starts and a sustained session. Record model revision or published profile where available, output size, transport, client device, network region, session duration and reconnect events. Keep the same conditions when comparing models or serving profiles.
Report distributions and failures
Record the median and a tail percentile, plus the number of observations. A result with three samples should not look as authoritative as a long sustained run. Include startup failures, rejected controls and interruptions rather than dropping them from the report.
Check quality alongside speed. A quicker profile that changes identity, loses scene continuity or ignores a control may not meet the product requirement. Save a representative recording with the settings that produced it.
Turn measurements into a product decision
Set a budget for the interaction you need. A cinematic window can tolerate a different delay from a player steering a world or a webcam user watching their own motion. Test the actual application and expected network route.
Windflow exposes model specifications on model pages, while readiness is reported separately. The transport guide explains delivery choices. For published AMD examples, see MI355X measurements.
FAQ
Is a command acknowledgement the same as visible latency?
No. Acknowledgement confirms the control path accepted or processed a command. The generated change can become visible later, after a model boundary and media delivery.
Can a model generate faster than realtime but still have a slow first frame?
Yes. A window-generating model can produce each window faster than its playback duration while requiring the first window to complete before generated playback begins.
Which latency number should I compare across providers?
Use the same interaction, client and measurement boundary. Compare control-to-visible delay for live controls and first-frame time for startup, with resolution, transport, quality and GPU configuration stated.