Media diagnostics · Primary-source explanation; examples are illustrative. Instructions are based on publisher guidance; a UK IPTV account was not tested on this platform.
Identify the clock in each field
MDN describes requestVideoFrameCallback as running when a new video frame is sent to the compositor. Its metadata includes mediaTime on the media timeline, an expected display time and a presentation time. Those names are not interchangeable with the original broadcast capture time. A programme position of 35 seconds says where a frame belongs in that media timeline, not that it took 35 seconds to reach the screen.
Keep an illustrative calculation within its scope
Suppose a diagnostic callback has an expected display time of 10,020 milliseconds and runs at 10,015 milliseconds on the same high resolution clock. Their five millisecond difference concerns expected presentation relative to the callback. It does not include an unknown encoder, origin, network or prebuffer interval. The example is invented arithmetic, not a latency measurement from this website. Do not subtract an unrelated wall clock value and label the result end to end delay.
Know when more metadata exists
The documentation lists additional capture and receive timing fields for WebRTC use cases. Availability of those fields in that context does not establish that a normal on demand or live HTML video element exposes them. Feature check the API in the actual browser and retain the field names and units in diagnostic output. A useful report can describe presentation behaviour without making a stronger camera to screen latency claim that its observations cannot support.