Re: Stats variables - some more input

I just noticed this proposal - I hope its ok to pick up on this old
thread again. I can't seem to find these extensions in the current
draft. I'd like to state my support for the proposed extensions.

To explain my motivation: I'm finding it rather hard to determine when
a UA is under-resourced to decode a video stream and thus needs to
re-negotiate a stream. I have the situation where a UA receives all
the data that the other UA sends, but can't keep up with decoding and
thus framesDecoded goes to 0. None of the existing stats that are
currently exposed in the stats API provide that information, but the
below proposal has this and a lot of further information that can help
author better user experiences.

Regards,
Silvia.


On Mon, May 27, 2013 at 11:36 PM, Harald Alvestrand
<harald@alvestrand.no> 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
> }
>
>

Received on Monday, 5 August 2013 03:35:30 UTC