Looks like this is caused by https://chromium-review.googlesource.com/c/chromium/src/+/724660

From the comments it sounds like this is useful to workaround BWE bugs. It seems like a better addressed by improving BWE algorithms directly.

The high frequency of empty frames (5 FPS as opposed to just sending them every 2.99 seconds) was to work around BWE issues.

However, the main purpose of that CL was to work around the problem where the receiver sends PLI/FIR if no frames have been received for 3 seconds. The resulting key-frames are a vastly greater waste of resources than 5 empty frames per second! :)

If there's a better method of suppressing the PLI/FIR every 3s, we should use that.

I have no problem with sending empty frames periodically, e.g. every 2 seconds. But 5fps to keep BWE happy seem wrong. The problem here is that the BWE probing algorithm expects to see some data in the pipe. It doesn't send probes unless the sender generates some data. Perhaps the BW prober can send some dummy packets if there is no real data to send. 
Philip, WDYT?

note also that side-effect of that change is that it hides the bug introduced in crrev.com/743027 . After that change frame duration is calculated based on the time passed since the previous frame. This is a wrong way to calculate frame_duration. Limiting min fps at 5 means that this delay can't be higher than 200ms, which limits frame duration passed to the encoder.

We already send dummy packets if there is no media to send, so it works even without data in the pipeline. It is better to have some media packets available though, since dummy packets have a limited size (~240 bytes I think), so we have to send a lot more dummy packets to probe a certain bitrate.

I don't think sending five "empty" frames per second will help the BWE since the generated bitrate will still be rather low.

Lambros, what do you suggest we do here?

At the time of choosing the 200ms rate, my testing suggested that it gave better results than sending empty frames every 2s. The top priority at the time was minimizing the video freezes, and the 200ms rate seemed to help, so I went with it.
I can revisit this test on latest ToT build, and try to test more thoroughly. Or we can wait until we get a better handle on the freezing-video problem. Once the underlying issue is fixed, we can certainly reduce the empty frame rate to every 2s.

On the issue of sending-enough-fake-data-to-help-BWE, it sounds like we already do that? In which case, the rapid empty frame rate shouldn't make any difference.
Definitely worth re-testing to confirm this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/035185dee8763d8c48e3614b739ef5594536e100

commit 035185dee8763d8c48e3614b739ef5594536e100
Author: Lambros Lambrou <lambroslambrou@chromium.org>
Date: Tue Feb 20 23:06:09 2018

[remoting host] Remove limitations added for video-freezing issues

Some limitations were added, because they were believed to mitigate
the video-freezing problems with WebRTC connections. Now that the
underlying problems have been addressed, these limitations can be
removed.

Max bitrate is increased to 100Mbps from 20Mbps, undoing
crrev.com/a975bd60169fcce356ef61f30e3a4c448f5899e5

Empty frames are sent every 2s instead of 200ms, to address
 crbug.com/803599 . Empty frames were introduced in
crrev.com/a6a3f1e839e900f335350c8555a973cadce46386

Bug:  773549 ,  803599 
Change-Id: I5c463d12d8935a63792656c7e79586bec0caed69
Reviewed-on: https://chromium-review.googlesource.com/907591
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537921}
[modify] https://crrev.com/035185dee8763d8c48e3614b739ef5594536e100/remoting/protocol/webrtc_frame_scheduler_simple.cc
[modify] https://crrev.com/035185dee8763d8c48e3614b739ef5594536e100/remoting/protocol/webrtc_frame_scheduler_unittest.cc
[modify] https://crrev.com/035185dee8763d8c48e3614b739ef5594536e100/remoting/protocol/webrtc_transport.cc