Timed SRT observation
An SRT field becomes useful only after you know whether it is an accumulated count, an interval value or an instantaneous gauge. Two samples from the same session can then be tied to both the transport event and the decoded media.
This page is about interpreting statistics, not choosing a latency value or redefining RTT across every network protocol.
Start with the operator question
The operator decision comes before the fields. Is the goal to confirm that media is moving, investigate a burst of loss, see whether recovery pressure persists or decide whether an unstable path needs escalation? The answer determines the smallest useful set of statistics and the active SRT session to name.
SRT is an open-source transport protocol for live video and audio; it uses UDP and ARQ-based retransmission, with optional AES encryption. That context explains the loss and retransmission fields, but no field value describes visible quality by itself. The receiver observation belongs on the same incident timeline.
Separate flow, recovery and decoded outcome
Flow fields such as receive rate establish whether bytes are moving at the measured endpoint. Loss and retransmission fields describe recovery activity, while RTT provides a current path-timing signal. Picture, audio, synchronization and connection state complete the observation at those same timestamps.
A non-zero rate does not prove the intended program or codec. Accumulated loss cannot locate the event in time. One RTT sample does not describe an entire route, and a clean preview does not mean that retransmission never happened. The useful conclusion lies in the relationship among the layers, not in a single “health” badge.
| Layer | Examples | Question answered |
|---|---|---|
| Flow | Receive rate, session state | Is data moving here? |
| Recovery | Loss and retransmission fields | How hard is transport working? |
| Outcome | Decoded picture/audio | Was the media usable? |
Know whether each field is a rate, gauge or counter
The SRT statistics reference classifies pktRcvLossTotal and pktRcvRetransTotal as accumulated receiver packet counts; pktRcvLoss and pktRcvRetrans as interval-based receiver packet counts; mbpsRecvRate as an interval-based receiver rate in Mbps; and msRTT as an instantaneous smoothed round-trip time in milliseconds available at both endpoints.
The record needs the exact field name, endpoint and unit because sender and receiver retransmission fields are not interchangeable. An interval value cannot be subtracted as though it were accumulated, and an instantaneous RTT sample is not an average over the observation window. If an application renames a field, map that label to the documented API field before interpreting it.
- Total
- Accumulated within the documented clearing/session boundary.
- Interval
- Activity associated with the current collection interval.
- Instantaneous
- A value reported at the sampling moment.
Capture two timestamped samples
srt_bstats and srt_bistats report current statistics into SRT_TRACEBSTATS; the clear argument controls whether accumulated values are cleared after retrieval. Alongside each sample, keep the producing function or application surface, clear behavior, timestamp, session identity and endpoint side.
Sample A and sample B need a defined interval between them, with no reconnect. If the collection call clears accumulated values, that behavior governs the interpretation; the readings are not lifetime totals to subtract. A reconnect closes the interval and establishes a new baseline.
Automation claims about Callaba SRT Servers must stay within the fields and operations currently exposed by the public SRT Servers API documentation. Check the Callaba SRT API before building a poller, and record the contract version or date.
Calculate deltas only across one session
For an accumulated counter that was not cleared, B − A is valid only when both samples belong to the same endpoint and session. The result should retain its interval duration in seconds. A reconnect, application restart or counter reset breaks that measurement boundary, making subtraction meaningless.
A documented interval-based field stays with its collection window instead of receiving a manufactured second delta. For msRTT, preserve the sample sequence and state any summarization method explicitly. The objective is an audit trail of what changed during the incident, not a decorative dashboard.
Correlate RTT, loss and retransmissions
Timed values are more useful than one universal threshold. Rising or uneven RTT can shrink the practical room inside a fixed recovery budget. Loss fields describe missing-packet activity at their documented boundary, retransmission fields show recovery work, and the decoded outcome reveals whether the event became visible.
This correlation may justify a controlled latency experiment, but it does not select the setting here. Use the latency tuning runbook with the measured path. Bitrate saturation, firewall interruption, encoder pause and decoder errors remain separate hypotheses until the evidence distinguishes them.
- Align samples and media observations by timestamp.
- Compare equal interval lengths.
- Mark loss injection or real incident windows.
- Keep sender and receiver fields labelled.
- Record recovery and unrecovered outcome separately.
Turn evidence into one bounded action
The measured interval should lead to one next action: repeat with a controlled impairment, inspect capacity, check encoder continuity, tune latency in its own experiment or escalate a decoder problem. Changing several network and media controls at once would erase the comparison. Preserve the before-and-after interval so the action remains evaluable.
Open the SRT server page only for product configuration, and Compare statistics with decoded output when it is the approved view. The evidence set contains two timestamped samples from one session, the counter clearing behavior, exact deltas, the matching decoded-media observation and the operator action.
