W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2013

Re: Stats variables - some more input

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Tue, 06 Aug 2013 11:57:13 -0400
Message-ID: <52011CD9.7000904@mozilla.com>
To: Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
I think this looks great - I'm working on implementing this for Firefox, 
so I appreciate all the good info!

I have a few general comments on the webidl to start (sorry if this is 
outside the scope of your post).

Our webidl guy (behind our webidl compiler), had two concerns with the 
spec that he shared with me:

The first was the polymorphism implied in the RTCStats-derived 
dictionaries returned. He thinks webidl wont work that way and that any 
bindings generated (for c++ for instance) from this as written, will 
only ever return timestamp, type and id this way, and none of the 
derived fields. I think this can be circumvented using a union:

   typedef (RTCStats or
            RTCRTPStreamStats or
            RTCInboundRTPStreamStats or
            RTCOutboundRTPStreamStats or
            RTCMediaStreamTrackStats or
            MediaStream or
            RTCTransport or
            RTCIceComponentStats or
            RTCIceCandidatePairStats or
            RTCIceCandidate or
            RTCCodec) AnyRTCStats;

and have the API return AnyRTCStats.

The second point was that getters apparently have name collision issues, 
and he was wondering if it would be better for our needs to return a 
(read-only) "Map-like" object 
http://dev.w3.org/2006/webapi/WebIDL/#MapClass like this:

   [MapClass(DOMString, AnyRTCStats)]
   interface RTCStatsReport {};

A third comment from someone else was that we could use interfaces here, 
which would give us inheritance (to avoid the long and growing typedef 
above), though that seems like overkill, to me, for data that's never 
passed back to the browser, but I wanted to mention it.

---

I have no specific comment on the specific fields yet, except that the 
naming seems to be inconsistent in a few places. For instance, I would 
have expected "RTCMediaStreamStats" rather than "MediaStream" etc. Are 
those short-hands or typos?

Thanks!

.: Jan-Ivar :.

On 5/27/13 9:36 AM, Harald Alvestrand wrote:
> I'm continuing with the process of designing stats variables that make 
> sense and are useful.
> My current draft is reproduced below. Comments welcome!
>
> One question that arose about audio volume representation: It's hairy.
> Especially it's hairy to define volume in a way that makes sense when 
> you don't know the sampling interval (because this is a polling 
> interface), and you don't want to give undue importance to the last 
> tenth of a before the sample. Or perhaps you do - it might be app 
> dependent.
>
> One suggestion made internally: Just report the cumulative audio 
> energy (sum of audio energy over time) instead. Then people can 
> transform that as they will.
>
> Thoughts on this?
> For now, the proposal contains a conventional "audio level" variable.
> For the rest:
>
>
> Root of hierarchy:
>
> dictionary RTCStats {
> DOMHiResTimeStamp timestamp;
> RTCStatsType type;
> DOMString id;
> };
>
> All SSRCs:
>
> dictionary RTCRTPStreamStats : RTCStats {
> DOMString ssrc;
> DOMString remoteId;
> // New stuff:
> DOMString mediaTrackId;
> DOMString transportId;
> DOMString codecId;
> };
>
> Note the convention that names ending in “Id” are identifiers of other 
> stats objects.
> Directed SSRCs:
>
> dictionary RTCInboundRTPStreamStats : RTCRTPStreamStats {
> unsigned long packetsReceived;
> unsigned long bytesReceived;
> // In addition to current spec:
> float jitter;
> };
>
> dictionary RTCOutboundRTPStreamStats : RTCRTPStreamStats {
> unsigned long packetsSent;
> unsigned long bytesSent;
> };
>
> Representing MediaStreamTracks:
>
> dictionary RTCMediaStreamTrackStats : RTCStats {
> DOMString trackIdentifier; // track.id property
> boolean remoteSource;
> sequence<DOMString> ssrcIds;
> // Only makes sense for audio
> unsigned int audioLevel;
> // Only makes sense for video
> unsigned int frameWidth;
> unsigned int frameHeight;
> unsigned float framesPerSecond; // The nominal FPS value
> unsigned int framesSent;
> unsigned int framesReceived; // Only makes sense for remoteSource=true
> unsigned int framesDecoded;
> int firs;
> }
>
> dictionary MediaStream : RTCStats {
> DOMString streamIdentifier; // stream.id property
> sequence<DOMString> trackIds; // Note: This is the id of the stats 
> object, not the track.id
> }
>
> Representing transports:
>
> dictionary RTCTransport: RTCStats {
> unsigned long bytesSent;
> unsigned long bytesReceived;
> }
>
> dictionary RTCIceComponentStats : RTCStats {
> DOMString transportId;
> int component;
> unsigned long bytesSent;
> unsigned long bytesReceived;
> bool activeConnection;
> }
>
> dictionary RTCIceCandidatePairStats : RTCStats {
> DOMString componentId;
> DOMString localCandidateId;
> DOMString remoteCandidateId;
> boolean writable; // Has gotten ACK to an ICE request
> boolean readable; // Has gotten a valid incoming ICE request
> }
>
> dictionary RTCIceCandidate : RTCStats {
> DOMString ipAddress;
> int portNumber;
> // More ICE-related info goes here.
> }
>
> dictionary RTCCodec : RTCStats {
> unsigned int payloadType; // As used in RTP encoding.
> DOMString codec; // video/vp8 or equivalent
> unsigned int clockRate;
> unsigned int channels; // 2 for stereo, missing for most other cases.
> DOMString parameters; // From SDP description line
> }
>
>

.: Jan-Ivar :.
Received on Tuesday, 6 August 2013 15:57:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC