Media diagnostics · Primary-source explanation; no UK IPTV implementation or account test. Instructions are based on publisher guidance; a UK IPTV account was not tested on this platform.
The same integer can mean different durations
Take an invented RTCP jitter value of 450 timestamp units. If its actual RTP clock runs at 90,000 units per second, the conversion is 450 divided by 90,000: 0.005 seconds, or five milliseconds. At 48,000 units per second, the same integer represents 0.009375 seconds, or 9.375 milliseconds. The raw numbers are equal, but the durations differ. These clock rates are examples; the payload mapping and session context determine which rate applies to a real source.
Keep the field identity with the number
RFC 3550 defines the base report field as a smoothed estimate of interarrival variation, rather than a direct end-to-end latency reading. A monitoring interface might already convert it to milliseconds, while a raw report exposes the integer. Check the unit label and the interface documentation before converting anything. Dividing a value that has already been converted produces a second, incorrect conversion. Conversely, appending milliseconds to an unidentified integer invents precision that the observation does not contain.
Compare like with like
Record the source identifier, payload clock rate, reporting interval and whether the value came from raw RTCP or an application display. Keep comparisons within the same metric definition. This makes a before-and-after change interpretable even when audio and video use different clocks. The converted jitter estimate still does not tell you total live delay, a required buffer setting, or the exact cause of a visible stall. Those questions need additional observations from the media and playback path.