Re: [webrtc-pc] RTCRtpContributingSource.timestamp needs a clearer definition

The timeOrigin implementation is Firefox is really simple: take the monotonic clock timestamp at navigation start, subtract a process-global initialization timestamp, add the wall-clock time of said initialization.

The navigationStart implementation is just a snapshot of wall-clock time at navigation start.

So if there is a difference, it's due to skew between the monotonic and wall clocks over the period between process init and navigation start.  I suspect based on the number I'm seeing that in Firefox the monotonic clock doesn't run while the computer is asleep, which can easily introduce significant skew given that content process lifetimes in Firefox are a good bit longer than in Chrome.

GitHub Notification of comment by bzbarsky
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 9 January 2018 17:45:17 UTC