- From: Sergio Garcia Murillo via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Feb 2020 09:07:34 +0000
- To: public-webrtc-logs@w3.org
Regarding reception time, it should calculated in the same "place/layer" as the reception time used for the DSLR of the RTCP SR/RR. DSLR is used for calculating the rtt, so it makes sense to consider anything before that layer as "network transmission time". Obviously, the closest to the hardware as possible, but this should not be a specific issue for calculating stats (it affects also transport wide cc feedback messages). I am not against having a jitter buffer only stat, the more stats the better. But I think that having a stat that calculates the time between the reception time and the the play time (as accurately as possible) is interesting for both app developers (which care more about that than the jitter buffer delay). Would it make sense to modify the `jitterBufferDelay` to account jitter only processing time (and only for audio, so it could even be moved into `RTCAudioReceiverStats` ) and a new stat called `playoutDelay` that takes into account the time since reception until it is ready for playback (as close to the display layer as possible). The `playoutDelay` stat would make sense for both audio and video. Also, this would make sense as the `playoutDelayHint` attribute is aiming to provide the hint for play out delay, and not just the jitter buffer delay. Regarding the e2e delay estimate, I will answer in the corresponding issue. -- GitHub Notification of comment by murillo128 Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/549#issuecomment-584022755 using your GitHub account
Received on Monday, 10 February 2020 09:07:41 UTC