@stefanholmer That sounds logical, maybe update currentlyPlayedCaptureTimestamp name to not imply that it was played (since it was what would have been played). It does have the issue where if there is a legitimate reason for the other side not to be capturing that hasn't been signaled yet then it will still show up as an increase in E2E delay (because you are measuring the E2E delay of frame n by calculating the estimated delay of frame n+1) rather then calculating the delay of frame n. Is it expected for video.currentEstimatedCaptureTime - audio.currentEstimatedCaptureTime = 0? What is the plan for these metrics if a stream is muted? One issue with the current metric is that we can get giant jumps/continual increase when things become muted or unmuted. -- GitHub Notification of comment by icydragons Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/158#issuecomment-278831962 using your GitHub accountReceived on Friday, 10 February 2017 01:31:54 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:40 UTC