Re: Issue #4 (Need API to read the CSRC on received tracks) and Issue #6 (Need API to receive mixer to client audio level information for a track)

On 09/11/2015 12:37 PM, Martin Thomson wrote:
> On 11 September 2015 at 12:07, Bernard Aboba
> <Bernard.Aboba@microsoft.com> wrote:
>
<snip>
> 3.    How is the timestamp value obtained?  Is this the timestamp value from
> the RTP packet?  Or is it an NTP timestamp?
> That's a good question.  And part of why I wasn't particularly happy
> with the timestamp.  HighResTimestamp is usually something that is
> local to the browser, so some translation would be required if the
> time was based on the NTP time.  That said, the NTP time from the
> packet isn't going to relate well to the playback time, but it might
> be the best option, since packet arrival time doesn't really match to
> anything of use.  Do we have any way to determine what the difference
> is between the NTP times used in RTP and the playback time?
The RTP timestamp value is a reasonable choice because it is:
- Defined for all packets
- Universally known to not have global meaning

The second alternative is the NTP translation of the RTP timestamp.
This is:
- Only defined for packets for which an RTCP SR has been received and parsed
- Related to the global "NTP time" through the sender's clock
configuration - which means that it will have its obvious meaning *most*
of the time (not a good thing).

The third alternative is that it's the HighResTimestamp of the time the
browser thinks it received the packets. This is:
- Defined for all packets
- Related to the local system clock, which makes it consistent with most
APIs the client is likely to access
- Somewhat variable offset from the time the sender thinks it sent the
packet - so it's not likely to be meaningful to send it to other clients
(if there was ever a reason for that).

I'm leaning towards going with the third option. It's simplest to implement.



-- 
Surveillance is pervasive. Go Dark.

Received on Sunday, 13 September 2015 20:09:05 UTC