W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > February 2017

Re: [webrtc-stats] Stats to keep track of sync between audio and video

From: Robin Schriebman via GitHub <sysbot+gh@w3.org>
Date: Fri, 10 Feb 2017 01:31:40 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-278831962-1486690299-sysbot+gh@w3.org>
@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 account
Received 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