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)

Den 19. sep. 2015 23:47, skrev Bernard Aboba:
> Here is an updated proposal containing clarifications for the time and RTCRtpContributingSource questions.   There is still an open question relating to the time interval. 
> 
> partial interface RTCRtpReceiver {
>     sequence<RTCRtpContributingSource> getContributingSources ();
> };
> 
> getContributingSources
> 
> Returns an RTCRtpContributingSource object for each unique CSRC or SSRC received by this RTCRtpReceiver since {the last time this method was called || last 10 seconds  || last second   }. 

"Since the last time this method was called" seems iffy - if two
functions call it asynchronously, for whatever reason, they will
interfere with each others' reading.

An implementation doesn't have to remember packet history to clear old
entries (which was troubling me when we discussed averaging over some
interval); it can simply remove entries older than N seconds when
called. So I can't bring myself to care whether it's 1 second or 10 seconds.

> No parameters.
> Return type: sequence<RTCRtpContributingSource>
> 
> dictionary RTCRtpContributingSource
> 
> The RTCRtpContributingSource object contains information about a contributing source. Each time an RTP packet is received, the RTCRtpContributingSource objects are updated. If the RTP packet contains CSRCs, then the RTCRtpContributingSource objects corresponding to those CSRCs are updated, and the level values for those CSRCs are updated based on the mixer-client header extension [RFC6565] if present. If the RTP packet contains no CSRCs, then the RTCRtpContributingSource object corresponding to the SSRC is updated, and the level value for the SSRC is updated based on the client-mixer header extension [RFC6464] if present. 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.
> 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]. Both [RFC6464] and [RFC6465] define the level as an 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. The time (obtained on the user agent) is relative to the UNIX epoch (Jan 1, 1970, UTC).


The use of DOMHiResTimeStamp is actually troubling, for multiple
reasons, none of which is actually a technical concern:

1) The name is wrong. It's DOMHighResTimeStamp.

2) The definition (which is a typedef for Double) states that "The
DOMHighResTimeStamp type is used to store a time value measured relative
to the navigationStart attribute of the PerformanceTiming interface
[NavigationTiming], the start of navigation of the document, or a time
value that represents a duration between two DOMHighResTimeStamps."

It also says that "The time values returned when calling the now method
MUST be monotonically increasing and not subject to system clock
adjustments or system clock skew. The difference between any two
chronologically recorded time values returned from the now method MUST
never be negative." Not normative for our usage, but might surprise some.

Both of these are troublesome given that they don't seem to admit of an
implementation that uses the system clock's idea of time relative to Jan
1, 1970.
We can do it, but it's a novel usage of the type.

Reference: http://www.w3.org/TR/hr-time/#sec-DOMHighResTimeStamp

(One possible resolution: Return time relative to
PerformanceTiming.navigationStart, just like the Performance.now()
function does.)

Received on Sunday, 20 September 2015 06:04:46 UTC