Re: CSRC and DOMHighResTimestamp

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