Relax the way framesPerSecond is calculated.

[bc-lee]

Currently, framesPerSecond (RTCInboundRtpStreamStats, RTCOutboundRtpStreamStats , RTCVideoSourceStats) is defined as the number of encoded frames during the last second.

The problem with the current definition is that it is too restrictive to calculate framesPerSecond exactly within the last second. To conform to the spec, the implementation needs to bookkeep the last 1-second amount of the frame's timestamp since it doesn't know when getStats() is called. In my opinion, the implementation may want to choose how framesPerSecond is calculated, like RTCAudioSourceStats.audioLevel, to simplify its logic while reducing the complexity of implementation.

Also, except for RTCVideoSourceStats.framesPerSecond, these values are informative. Users of webrtc-stats easily calculate exact FPS from consecutive two getStats() calls by using framesDecoded / framesEncoded

[fippo]

@henbos thoughts?

[henbos]

I agree, for exact 1 second window frames this is already available by looking at delta total counters. This FPS is mostly for convenience and it looks like the libwebrtc implementation has been using an approximate value since forever. The easiest way to get conformance is to simply update the spec to match the fact that implementations are using approximations.

The question is how vague we should be in the spec language.

[henbos]

@alvestrand Do you have an opinion how to phrase this so that it is an approximation? We want vagueness but it shouldn't be completely untestable

[alvestrand]

We should add a comment saying "this is an approximation for people who don't want to use multiple getStats call and calculating the exact value". I suggest we add "using a browser defined algorithm, which should approximate the number of frames during the last second".

[henbos]

Makes sense to me