How does the Frame Buffer work?

[Michal Śledź]

Hi, 

we are noticing very strange behavior on some of our computers where Chromium sends a lot of NACKs even though we are running our SFU on localhost. Mostly slow machines are affected (e.g. i5 4 CPUs 8 threads).

Looking at webrtc-internals we can see the following:

packets dropped/packets received

1st peer: 15/22k; 

2nd peer: 20/38k

frames dropped/frames received

1st peer: 424/2k

2nd peer: 700/2k

Even though that the packet loss is almost 0% we are still noticing about 16-35% of frames being dropped. And we are on localhost. 

RTX is on, simulcast is off, max bitrate was 1.5Mbps, resolution 1280x720. CPU usage was about 50-60%.

We dived a little bit into the Chromium source code and found the framebuffer.cc (in third_party) and it looks like it is responsible for this strange behavior. 

But we cannot get what we would have to do to make frame buffer drop so many frames.

I believe we are not modyfing RTP packets that are generated by a client - we are not performing munging as simulcast is off.

We also noticed that the metric framesReceived - framesDecoded - framesDropped can be a negative number (see screenshot).Sounds like a bug?

The whole behavior doesn't occur on more powerful CPUs e.g. i9 16 cores/24 threads.

[Michal Śledź]

It turned out that our UDP socket was configured with too small recv buffer. Because we are streaming 1280x720, some frames (in particular keyframes) are sent in a burst of multiple RTP packets that were exceeding our recv buffer and some of them were dropped.

Increasing recv buffer solved the problem :)