All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=819564

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=777ffb0d4a98adcf0aa359fe982bfd8d7fb5e4495451971065fb0dc7c4272d16


Bot(s) for this bug's original alert(s):

webrtc-android-tests-nexus6-nougat

There are several groups of alerts:
In simulcast tests lower streams are now not starved by huge frames in the higher streams. This results in smaller sender delay for them but slightly higher delay for the high streams. I think this is good.

In screenshare simulcast this behavior even helped to reduce number of key frames request which resulted in higher PSNR and lesser send bandwidth.

There're also changes regarding FEC tests. Because FEC packets are now "prioritized" (they will get at least up-to half of bandwidth if they have anything to send), they get their configured bandwidth more consistently. This slightly increases send-side delay for video, but reduces total delay in high packet loss scenarios more.

Last group of changes is in the ramp up tests. Ramp up time is up, sent media and rtx is also up. This is not drastic, e.g. on bot jumped from 5 to 18 seconds, but other was already oscillating between 5 and 18 seconds and now is consistently at 18s. I will continue looking into that. This is probably caused by difference in how RTX stream is competing with media stream.

I think there's no need to revert CL, since it works good on perf tests and there were no bad signals in UMA data for the experiment.