- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Sat, 08 Feb 2020 12:51:07 +0000
- To: public-webrtc-logs@w3.org
If the purpose is to measure end-to-end delay, then jitter buffer delay is indeed useless. In the common transmission chain of server host -> outgoing router -> ISP router* -> home NAT -> home AP -> PC Wifi card -> PC network buffer -> Chrome network process -> Chrome renderer process -> jitter buffer, I don't see a point that is easily reachable that is a reasonable definition for "packet arrival" - the most reasonable time would be the time at which the checksum is verified in the Wifi card for the incoming packet, but there isn't an easy way to get hold of that time. In WebRTC, I think we should be aiming for guesstimating end-to-end delay, and quantizing delays that are fully within the WebRTC model of things. -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/549#issuecomment-583733892 using your GitHub account
Received on Saturday, 8 February 2020 12:51:09 UTC