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 Sep 20, 2015, at 12:04 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> 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.

I don't think the "since last called" will work. We did get agreement in the room on 10 seconds - I dont' see any reason to go with some other number. 


> 
>> 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).
> 

I do think it is good to clarify the time represents the time time of reception of the RTP packets that had the data and not some other time. 

I'm not sure what type of type we should use but it seems the advantage of DOMHighResTimeStamp is it can be converted into all the other types of times a browser might have in a consistent way. When using it, it does not have surprising effects when you take the difference of two times and other forms of time in the browser do have some very surprising and somewhat underspecified problems. ( Like thing a have after b but when you difference them you get a negative number when expecting a positive number). The primary use case was to display current speaker info and that requires a time you can sort on. DOMHighResTimeStamp meets that requirements and it is much harder with a time that can go backwards. If we do go with DOMHighResTimeStamp, I don't see why we we redefine it as bound the the unix epoch - an app can always create it own mapping between the two. 


> 
> 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 Monday, 21 September 2015 19:02:50 UTC