In this guide
Compare two original delivery patternsMeasure the gap and the recovery separatelyChoose a comparison that tests one explanationA long-term transfer average can look sufficient while a player still runs out of immediately playable media. Data arriving after its presentation deadline cannot retroactively prevent the pause that already occurred.
This does not mean every uneven request is a network-jitter fault. Segment size, server response, player scheduling and transport recovery can all create uneven application-level delivery. Use the word “bursty” to describe the observation before choosing a packet-level explanation.
Compare two original delivery patterns
Imagine ten seconds of media arrives over ten seconds in two ways. In pattern A, one second of media arrives each second. In pattern B, nothing arrives for eight seconds, then all ten seconds arrive in the final two seconds. Both patterns have the same total media and elapsed time, but a client beginning with only three seconds buffered cannot play pattern B continuously.
The example deliberately ignores startup and parallel tracks. Its purpose is to show why the temporal distribution matters. A sufficiently large existing buffer could absorb that particular gap; the same arrival pattern can therefore have different visible results at different buffer depths.
Measure the gap and the recovery separately
Record when media stopped arriving, the buffer available at that point and when useful delivery resumed. Note whether the late data was actually decodable and in the needed timeline position. A large response arriving later does not help if it contains the wrong range or depends on missing initialization information.
If your tool displays a packet-level jitter value, retain its definition rather than substituting it for the application observation. The player’s segment timing and a network probe can cover different hosts, protocols and intervals.
Choose a comparison that tests one explanation
Compare the same affected device over a supported wired link if practical, close in time and with other traffic documented. Alternatively, reduce a known competing upload briefly and observe whether the gap pattern changes. Restore normal conditions afterward and avoid changing unrelated decoder settings at the same time.
Report the gap duration, buffer trend, request statuses and recovery timing. A conclusion such as “the observed gap exceeded the available playable buffer” follows from the evidence. Naming the ISP, CDN, router or packet-loss mechanism requires additional observations. This keeps the finding useful even when the underlying cause remains unresolved.
| Evidence | Why it helps |
|---|---|
| Longest delivery gap | Shows the interruption to useful media arrival |
| Buffer before the gap | Shows the available timing cushion |
| Segment size and duration | Separates size changes from timing changes |
| Recovery request outcomes | Shows whether media actually became usable |