add framesInput stats to rtcoutboundrtpstreamstats about webrtc-stats HOT 6 CLOSED

The source stats are the number of frames inputted to WebRTC and frames encoded are the number of frames outputted from the encoder, so in that sense you can calculate the number of frames that disappeared already.

What exactly do you want to measure?

What you can't tell is why the encoder did not produce more frames, but I guess that would either be because of the adaptation logic purposefully dropping them or the encoder dropping them due to not wanting to overshoot the bitrate? Both of these would be considered adaptation in my opinion.

from webrtc-stats.

the originating frame maybe dropped before inputed to encoder, with input frames stats, user can measure how many frames was dropped before encode , and how many frames dropped by encoder（for rate limiting purposes)， this allow users to more accurately analyze the cause of low output frame rate.

from webrtc-stats.

Frames dropped prior to delivery to WebRTC, e.g. something in the camera pipeline, should be available by the new track stats API (the shape and name of it is still up for debate) but ultimately the track should report its own frame rate. The new API is proposed on the MediaStreamTrack rather than on WebRTC because the consumer of the track may be a different use case than WebRTC and those use cases may still want to know about track stats.

As for WebRTC getStats, ideally the frame rate of "media-source" stats should match the output of the track if no frames are dropped by the capture pipeline. However there is currently a bug in the implementation of media-source stats where we report frame rate and resolution after adaptation, not before adaptation, so you're getting input to encoder rather than input to adaptation module. https://crbug.com/webrtc/13528

And lastly you have output from encoder.

from webrtc-stats.

Would "capture fps -> webrtc input fps -> encoder fps" cover enough ground?

from webrtc-stats.

Frames maybe dropped before being sent to the encoder for various reasons（source、congestion、rate limit), stats dropped frames for every dropped reseaon may be more complicated, i think this(capture fps -> webrtc input fps -> encoder fps) is acceptable.

from webrtc-stats.

Ack! Closing as covered by other specs/efforts. I'll be looking into implementing track stats, hopefully next quarter, in chrome

from webrtc-stats.