Re: Stats variables - some more input

On 05/27/2013 04:09 PM, Stefan Håkansson LK wrote:
> On 2013-05-27 15:36, 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!
>
> Overall I think we're moving towards something useful.
>
>> 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;
>> }
>
> Just a note: there is a great overlap between the above and the 
> MediaSourceStates dictionary (defined in "Media Capture and Streams").
>
> (And the hard-to-define audio level is in both).

Yes. The MediaSourceStates has had a shorter life than the stats proposals.
>
> Would it not be sufficient to report width, height, framerate and 
> audio level via source states? I know you won't get the high 
> resolution time stamp, but perhaps that is not needed for that kind of 
> data.

Three counterarguments:

- An app that already uses the stats API shouldn't have to use another 
API for these specific values
- MediaSourceStates have to be defined in a way that makes sense for all 
sources. Stats can be defined in a way that makes sense for 
transported-over-network entities only. This may matter if, for a 
sending stream, the stuff sent over the wire is rescaled compared to 
what comes from the source, for instance.
- And yes, they will be timestamped....

That said, the numbers SHOULD have the same definitions in both places 
as far as possible.


>
> Stefan
>
>

Received on Monday, 27 May 2013 14:25:53 UTC