Do not downgrade layers too early

[boks1971]

Problem

On my slow machine, about half the time the "f" layer does not even start before the
monitor code swoops in and downgrades quality.

It is puzzling as to why it is not started. Activity Monitor shows 75% idle even when all
layers are encoding. And the server is running on the same machine. So, bandwidth
should not be an issue.

Anyhow, once downgraded, we wait the 60 seconds before enabling the "f" layer
which is quite a while for high quality video to be sent out.

Fix

Check if the best encoder has been active (by checking framesSent !== 0) before
downgrading. With this change, the "f" layer starts about 15 - 20 seconds into the
session rather the 60+ seconds because of downgrading too early. 15 - 20 seconds is
not great either, but at least it is not as bad.

To think about

What if even "h" was too much and we need to downgrade to "q"? By waiting for "f"
to start, we will never get to that. Maybe, we need to check the currently active (or
at some point active) best encoding and see if that is suffering. Or maybe, letting the
browser handle it is okay as "h" suffering is probably a sign that the machine is going
to perform poorly even for the most basic cases.

Testing

Ensure that "f" layer is not clobbered before it has a chance to start.

[boks1971]

@davidzhao Realized that this could be due to the RTP change I made to parse the padding packet properly. Chrome sends a bunch of padding packets initially to probe available bandwidth. Because of the RTP change, they were not submitted to the TWCC.

I made a change in ion-sfu to submit to TWCC before dropping any padding only packets. Will make a PR for that.

In spite of that, I think this is a decent change to not downgrade prematurely. What do you think?

[davidzhao]

this is a good fix. 👍