commit b613e3ab6b7126512a3a1fbc3852fa946ca4ee30
author Henrik Boström <hbos@webrtc.org> Fri Apr 17 11:48:21 2020
committer Commit Bot <commit-bot@chromium.org> Fri Apr 17 12:35:18 2020
tree 3d154fc1dab25fcc742d7599c9d193d45829958d
parent d516b2585292819a34f6e206d5e830895cee41b6

[Adaptation] Resource::IsAdaptationUpAllowed() for IsBitrateConstrained.

This CL is part of the Call-Level Adaptation Processing design doc:
https://docs.google.com/document/d/1ZyC26yOCknrrcYa839ZWLxD6o6Gig5A3lVTh4E41074/edit?usp=sharing

The VideoStreamAdapter is currently responsible for aborting and not
providing adaptations if we are bitrate constrained
(kIsBitrateConstrained). Whether or not we are bitrate constrained is
clearly a resource question and should be phrased as such. By moving
this logic to Resource::IsAdaptationUpAllowed(), the VideoStreamAdapter
can continue to be thread-agnostic when a future CL introduces a
"processing queue", and the VideoStreamAdapter can be simplified: it
returns Adaptations even if we are constrained (but we refuse to Apply
them any resource rejects it).

This CL adds new Resource classes as inner classes of
ResourceAdaptationProcessor that take on the responsibility of
kIsBitrateConstrained logic:
PreventIncreaseResolutionDueToBitrateResource and
PreventAdaptUpInBalancedResource.

A third class, PreventAdaptUpDueToActiveCounts, also allows us to move
adaptation-aborting logic. This piece of code appears to be about not
adapting up if we’re already at the highest setting, which would be
VideoStreamAdapter responsibility (covered by
Adaptation::Status::kLimitReached), but it is actually more complicated
than that: the active_counts_ care about "reason", so it is really about
"is this resource type OK with you adapting up?". We should probably
rewrite this code in the future, but for now it is moved to an inner
class of ResourceAdaptationProcessor.

Other misc changes:
- ApplyDegradationPreference is moved to video_stream_adapter.[h/cc]
  and renamed "Filter".
- OnResourceOveruse/Underuse now use Resource* as the reason instead of
  AdaptReason. In a future CL, the processor will be split into a
  "processor" part and a "video stream encoder resource manager" part.
  Only the manager needs to know about AdaptReason since this is only
  used for |active_counts_| and we want to get rid of it as much as
  possible as it is not future-proof.

Bug: webrtc:11172
Change-Id: I2eba9ec3d717f7024c451aeb14635fe759551318
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/172930
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#31099}