- From: Robin Raymond <robin@hookflash.com>
- Date: Fri, 18 Sep 2015 19:07:25 -0400
- To: "public-ortc@w3.org" <public-ortc@w3.org>, Bernard Aboba <bernard.aboba@microsoft.com>
- Message-ID: <etPan.55fc992d.54a1e533.d9a5@Robin-iMac.home>
“The browser must keep information from RTP packets received in the previous second. “ In this context, I’m unclear the value of the timestamp into the contributing sources. The timestamp can only have a resolution sub-second and that will tell you relative to the last second when they last contributed. Not sure knowing that someone was 450 ms vs 210 ms difference is all that important. Only keeping track within 1 second limits the usefulness of the levels to having flickering LED activity lights and the relative timestamp is not valuable. If the browser kept a much longer history then we could tell whom is currently active vs whose been inactive for a long time. That might allow us to not only do flickering LEDs but to eliminate people whom have been inactive for a long period of time. I would actually recommend the API return all activity SINCE the last call to the API. Thus each time the API is called, the old list is purged and a new list is built thus allowing the application to keep all information about the contributing sources without loss but still not maintain huge volumes of data needlessly over time. -Robin On September 11, 2015 at 3:09:59 PM, Bernard Aboba (bernard.aboba@microsoft.com) wrote: [BA] Some questions: 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? 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? 3. How is the timestamp value obtained? Is this the timestamp value from the RTP packet? Or is it an NTP timestamp? ===================================================================================== partial interface RTCRtpReceiver : RTCStatsProvider { sequence<RTCRtpContributingSource> getContributingSources (); }; getContributingSources Returns an RTCRtpContributingSource for each unique CSRC or SSRC received by this RTCRtpReceiver in the last second. No parameters. Return type: sequence<RTCRtpContributingSource> 6.4 dictionary RTCRtpContributingSource The RTCRtpContributingSource object contains information about a contributing source, such as the most recent time a packet was received from the source. The browser must keep information from RTP packets received in the previous second. When an RTP packet is received, the entries are updated for the SSRC of the RTP packet and for any CSRC contained within it. interface RTCRtpContributingSource { readonly attribute DOMHiResTimeStamp timestamp; readonly attribute unsigned long source; readonly attribute byte? audioLevel; }; 6.4.1 Attributes audioLevel of type byte, readonly , nullable The audio level contained in the last RTP packet received from this source. If the source was set from an SSRC, this will be the level value in [RFC6464]. If the source was set from a CSRC, this will be the level value in [RFC6465]. If the RTP packet does not contain a client-to-mixer header extension, then the browser will compute the level value as described in [RFC6464] and will provide that. Both [RFC6464] and [RFC6465] define the level as a integral value from 0 to -127 representing the audio level in decibels relative to the loudest signal that they system could possibly encode. source of type unsigned long, readonly The CSRC or SSRC value of the contributing source. timestamp of type DOMHiResTimeStamp, readonly Time of reception of the most recent RTP packet containing the contributing source.
Received on Friday, 18 September 2015 23:07:57 UTC