Re: 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 11 September 2015 at 12:07, Bernard Aboba
<Bernard.Aboba@microsoft.com> wrote:
> 1.    When an RTP packet is received with a Mixer-Client extension and CSRCs
> is an RTCRtpContributing source dictionary created for the SSRC as well as
> the CSRCs?   If so, is an audioLevel attribute computed with that
> dictionary?   Or is the audioLevel only computed for the SSRC when there are
> no CSRCs?

I don't think that this matters much, but I would say that the most
valuable thing would be to populate a value for the SSRC.

We should also stipulate that the SSRC goes first.

> 2.    If an RTP packet is received with no Mixer-Client extension, but with
> CSRCs, would the RTCRtpContributingSource dictionaries for the CSRCs have
> the audioLevel attribute unset since that cannot be determined?

Yes.  That seems obvious to me.  You could omit the CSRCs from the
list, but that just loses more information.

> 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?

Received on Friday, 11 September 2015 19:37:53 UTC