- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Feb 2017 09:55:24 +0000
- To: public-webrtc-logs@w3.org
To echo what has already been said, - Actual achieved framerate is already achievable with framesSent and framesReceived or framesDecoded (which may be lower than framesReceived due to incorrectly decoded frames or frames dropped on the way to the decoder - can that happen?). - This should be configured frame rate. So, for "configured framerate", we are either talking about: - "Target framerate": the lowest value of all or some of: a=framerate, track configuration and RtpSender's maxFramerate. - Adapted (degraded) framerate; what the encoder or decoder is currently using. I expect the adapted framerate is already obtainable by RTC[In/Out]boundRTPStreamStats.frames[Encoded/Decoded]. So "target framerate" it is. How about something like? > Only valid for video. It represents the nominal FPS value. This is the configured framerate for this track attachment to the RTCPeerConnection. It is limited by track constraints and a=framerate in SDP. Local tracks may also be limited by encoding parameters (see RTCRtpEncodingParameters.maxFramerate). Assuming a=framerate and track constraints are two different things? Or is a=framerate what the track was constrained to use? -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/141#issuecomment-277207823 using your GitHub account
Received on Friday, 3 February 2017 09:55:33 UTC