A short dialogue explaining which FPS (frames-per-second) metrics WebRTC exposes and how to interpret them. Key distinctions: media-source FPS (camera capture) vs outbound RTP FPS (what is sent), and receiver-side counters (frames received, frames decoded). Notes that 'framesPerSecond' is a 1-second window while frames_ counters are cumulative and must be divided by time differences; advises choosing metrics based on where in the pipeline you measure.
What FPS metrics does WebRTC use and when to use which one?
Okay, so we have metrics for frames per second both at the sender and the receiver at the sender. We have them on two stats objects. One is the media source object, which is describing basically the camera and we have some on the outbound RTP on the peer connection. The media source describes what the camera does, what it captures, and that gives you the frame rate of the camera. While outbound RTP is the what gets sent over the peer connection.
So that's less it what's actually encoded and then sent or m sending.
Yes.
Okay. And what happens on the receiver?
On the receiver we have the same thing. We have a frames per second for receive and we have the frames received and frames decoded. That gives you an indication. Frames per second is always a one second window, so it's very short. Whereas the other counters are something you can do your usual thing with stats. You divide the counter by the time difference between.
Yes and then I might have places where the frames decoded might be higher than the Sorry. Might be lower than the frames received because I didn't have time, they got too late or whatever.
They got dropped or something like that. So you need to be very careful which metrics you're looking at.
Yeah. So you need to ask yourself, what does FPS mean in my application or in the way that I measure it?
Yes. Where does it. At what point in the pipeline are you looking at the numbers?
Okay, thank you.
Meta rebuilt AV1 for mobile scale. Should smaller teams follow? | Chats with Arin
