A fast connection can still feel slow, and a low-latency path can still run out of capacity. Latency measures how long data takes to travel. Throughput measures how much useful data arrives over time. Live video needs both, but each one breaks the picture in a different way.
Quick answer
Low latency shortens the time between source and viewer. Adequate throughput keeps every required bit moving during sustained load and short bursts. For a stable live feed, reserve bandwidth above the encoded bitrate, measure round-trip time, jitter and loss, and give the transport enough recovery time for the real network path.
Latency, bandwidth and throughput are not the same metric
- Latency
- The elapsed time for data to move from one point to another. Teams often measure round-trip time because it is easy to observe, but contribution and viewer delay are end-to-end outcomes with several additional stages.
- Bandwidth
- The nominal capacity of a link. A 100 Mbps interface describes a ceiling, not the useful rate your stream will always receive.
- Throughput
- The rate of data successfully transferred during the measurement window. Protocol overhead, competing traffic, congestion, loss and device limits can reduce it below the advertised link speed.
- Goodput
- The useful application payload delivered per second after overhead and retransmitted data are excluded. This is often the most relevant capacity number for media.
A path with high throughput may cross a long geographic distance and therefore have high latency. A local network may have very low latency but insufficient throughput for several high-bitrate feeds. One metric cannot stand in for the other.
How the two limits appear in live video
| Symptom | Likely pressure | Check next |
|---|---|---|
| The feed is stable but arrives too late for conversation or switching. | Latency | Capture, encode, network RTT, recovery buffer, decode and player buffer. |
| Picture breaks up when motion or several streams raise the data rate. | Throughput or burst capacity | Actual upload, queue drops, encoder bitrate peaks and competing traffic. |
| SRT remains connected but retransmissions rise and media becomes unstable. | Loss, jitter or an undersized recovery window | RTT, packet loss, retransmitted packets, latency setting and available headroom. |
| A file upload is slow even though delay is acceptable. | Throughput | Sustained goodput, server limits and parallel traffic. |
Live video is continuous, so average throughput is not enough. An encoder can produce short bitrate peaks, and several feeds can peak together. If the uplink runs close to saturation, queues fill, packets arrive late and recovery traffic competes with new media. Leave measured headroom instead of sizing the link exactly to the sum of target bitrates.
Build the latency budget stage by stage
End-to-end delay is the sum of multiple buffers and processing steps. Write them down before tuning. Otherwise one team may reduce the SRT recovery window while the player quietly holds several seconds.
- Capture: camera readout, frame synchronization and any hardware conversion.
- Encode: frame reordering, look-ahead, GOP structure and encoder load.
- Contribution transport: geographic delay, queues, jitter and the time reserved for packet recovery.
- Processing: routing, transcoding, switching, graphics and packaging.
- Delivery: origin, CDN or relay behavior.
- Playback: decoder and application buffer, device rendering and display.
The right target depends on the job. A remote interview may value conversational delay above extra recovery time. A one-way contribution feed across an imperfect WAN may accept more delay to protect continuity. A VOD upload primarily needs sustained throughput. Treat these as separate service profiles.
Measure transport and media in the same window
Start with a controlled source and record the time range for every test. Correlating metrics matters more than collecting a long dashboard.
- End-to-end delay: use a visible timecode or counter at the source and compare it with the decoded output.
- RTT and jitter: watch how the path changes over time, not only one ping taken before the event.
- Loss and retransmissions: confirm whether recovery traffic rises before picture damage appears.
- Input bitrate and goodput: compare the encoder output with sustained capacity and short peaks.
- Media continuity: inspect dropped or repeated frames, audio discontinuities, A/V sync and the actual recording.
- Recovery time: disconnect the active source and measure when the replacement becomes usable.
Callaba SRT Server exposes live connection state, bitrate and transport health while the received source can be watched in Multiview or recorded for later comparison. This makes it easier to determine whether damage happened before ingest, during transport or farther downstream.
Tune in an order that preserves the diagnosis
- Prove the source locally. Confirm picture, audio, frame rate and encoded bitrate before changing the network.
- Measure sustained capacity and peaks. If the required media rate consumes nearly all available goodput, reduce the bitrate or add capacity before tuning buffers.
- Measure the real path. Collect RTT, jitter and loss during the same period as the media test.
- Set the recovery window. For SRT, choose latency from observed path behavior and the amount of delay the production can tolerate. A smaller number is not automatically better.
- Remove downstream delay. Inspect transcoder, packager and player buffers only after contribution is stable.
- Repeat under failure. Add controlled impairment and force the backup path so the chosen settings are tested beyond ideal conditions.
Change one variable at a time and keep the recording, metrics and configuration together. If bitrate, codec, latency and player buffer all change at once, a better result cannot be attributed to a specific decision.
Four examples
Remote SRT contribution
The encoder bitrate must fit comfortably below measured goodput, while the SRT latency setting must leave time to recover packets on the actual WAN path. Watch RTT, loss, retransmissions and input bitrate together.
Browser Multiview
Operators need prompt source feedback, but monitoring quality does not have to consume the same bitrate as the contribution master. Use a viewing profile that preserves timing and source identity without saturating the operator connection.
Multistreaming
One high-quality ingest can feed several destinations from the server. This reduces source-side upload demand, but the server still needs enough outbound capacity for the sum of active outputs and their bitrate peaks.
Recording and file transfer
Recording continuity depends on the live ingest first. Moving the finished file later is primarily a throughput problem and can use the available capacity without imposing the same real-time deadline.
Latency and throughput FAQ
Does more bandwidth reduce latency?
Not necessarily. Added capacity can reduce queueing when a link was congested, but it does not remove propagation distance or processing and playback buffers. Measure the stages before buying bandwidth as a universal fix.
Can a speed test prove a link is ready for live video?
No. It is one capacity sample. A production test should also observe bitrate peaks, RTT, jitter, packet loss, retransmissions and media continuity over the expected route and event duration.
Why does video break up when average bitrate is below upload speed?
The stream may peak above its average, competing traffic may consume capacity, or queues may drop packets during bursts. Protocol overhead and retransmissions also use bandwidth. Measure short intervals and leave headroom.
Should SRT latency be set as low as possible?
No. SRT needs time to recover lost packets. Set the value from measured RTT, jitter and loss, then confirm the resulting end-to-end delay is acceptable for the production.
Which metric matters most for Multiview?
There is no single metric. Operators need timely feedback, continuous playback and enough visual detail to identify the source. Track source arrival, preview delay, frame continuity and the bandwidth used by all visible tiles.
Test one real path, not a theoretical preset
Send a representative feed, watch transport health and the decoded source together, record the result, then repeat with packet loss and a forced reconnect. That produces a latency and capacity profile your operators can trust.
Estimate the media bitrate · Launch Callaba on AWS · Install Callaba on Linux
