W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2015

Re: CSRC and DOMHighResTimestamp

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 28 Sep 2015 11:53:51 -0700
Message-ID: <CABkgnnXQCD9kd0pa4sca1n2g=WUhv0uXp8cv3pjAeyT6k4c9TA@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 26 September 2015 at 14:12, Bernard Aboba
<Bernard.Aboba@microsoft.com> wrote:
>> As I noted elsewhere, we need to be very precise about how this is
>> translated from the RTP based on what the local browser understands to
>> be the relationship between the remote RTP time and the local
>> DOMHighResTimestamp time, including different epochs, time errors, and drift.
>
> [BA] Can you take a shot at posting text to the list?


On consideration, the text in the PR currently has:

> The timestamp of type DOMHighResTimeStamp [HIGHRES-TIME], indicating the time of reception of the most recent RTP packet containing the source. The timestamp corresponds to the local clock.

That might be enough.  Unless we feel that some greater level of
precision is required.  After all, applications will be unable to
perform any matchup based on RTP clocks.  They also don't get to see
other aspects of timing (esp. CNAME).  All told, even though timing
for different sources can't be matched up precisely, we aren't exactly
providing timing-critical information here.

If we retain the behaviour, adding a note might be wise:

> Note that `timestamp` does not correspond to the time that the media was generated, or the time of the media that it describes.
Received on Monday, 28 September 2015 18:54:19 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:46 UTC