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

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


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

webrtc-linux-large-tests
webrtc-win-large-tests

huh, that's unexpected.
Looks like it's an increase in media bitrate/quality, and tiny increase in delay, and actually decrease in time between freezes on windows? Not worth reverting imo, but I'll look into this a bit more.

OK, I think I have found what changed here:
https://webrtc.googlesource.com/src.git/+/59021ba4e1dcd6b5dddf966591a4d0ebc6862705%5E%21/#F6

-      } else if (codec_.mode == VideoCodecMode::kScreensharing) {
+      } else if (!temporal_layers_[stream_idx]
+                      ->SupportsEncoderFrameDropping()) {

Previously, we allowed drop-reencode for the upper stream, even though DefaultTemporalLayers isn't really intended for that. Now we base the decision on the TemporalLayers implementation instead of the content type. So we drop, but don't re-encode until the next frame. That explains the increase in dropped frames, but not really why media bitrate increases. Less risk over bwe overuse?

I'll do some more testing before closing this bug.

Change is small enough and partly positive, so I'm gonna close this.