Re: Stats variables - some more input

On 2013-05-27 16:25, Harald Alvestrand wrote:
> 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....

I think the second argument makes a lot of sense!

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

Yes, same name and same definition.

Which brings up stream/trackIdentifier: I assume this is the same as the 
Id in the MediaStream/MediaStreamTrack IDLs, so perhaps the name should 
be the same.
>
>
>>
>> Stefan
>>
>>
>
>

Received on Tuesday, 28 May 2013 07:31:21 UTC