Adapting up or down is currently a "Maybe Adapt" method. In the future
we will want to be able to decide which stream to adapt, and as such we
need to be able to tell if a stream is able to do so.
This takes us one step in that direction, by refactoring
OveruseFrameDetectorResourceAdaptationModule::VideoSourceRestrictor's
methods to follow a simple pattern:
- What is the next step?
GetHigherFrameRateThan, GetLowerFrameRateThan,
GetHigherResolutionThan, GetLowerResolutionThan
- Can we adapt?
CanIncreaseFrameRate, CanDecreaseFrameRate,
CanIncreaseResolution, CanDecreaseResolution
- Do adapt!
IncreaseFrameRateTo, DecreaseFrameRateTo,
IncreaseResolutionTo, DecreaseResolutionTo
Hopefully this makes the code easier to follow.
This CL changes the "Request Higher/Lower" methods to take the target
as input instead of implicitly calculating the target from the current
input resolution or frame rate.
Bug: webrtc:11222
Change-Id: If625834e921a24a872145105f5d553fb8f9f1795
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168966
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30600}
This is part of the work for making VideoStreamEncoder responsible for
configuring its source/sink and limiting the responsibility of
OveruseFrameDetectorResourceAdaptationModule to only output relevant
VideoSourceRestrictions.
BEFORE THIS CL
Prior to this CL, OveruseFrameDetector was responsible for performing
AddOrUpdateSink() on the source, which it did using its nested class
VideoSourceProxy.
AddOrUpdateSink() could happen for both adaptation and non-adaptation
related reasons. For example:
- Adaptation related: AdaptUp() or AdaptDown() happens, causing updated
VideoSourceRestrictions.
- Non-adaptation related: VideoStreamEncoder asks the module to
reconfigure the source/sink for it, such as with
SetMaxFramerateAndAlignment() or SetWantsRotationApplied().
AFTER THIS CL
AddOrUpdateSink() is performed by VideoSourceController, which is owned
by VideoStreamEncoder. Any reconfiguration has to go through the
VideoStreamEncoder. This means that:
- Non-adaptation related settings happen between VideoStreamEncoder and
VideoSourceController directly (without going through the adaptation
module).
- Adaptation related changes can be expressed in terms of
VideoSourceRestrictions. OveruseFrameDetectorResourceAdaptationModule
only has to output the restrictions and not know or care about other
source/sink settings.
For now, VideoSourceController has to know about DegradationPreference.
In a future CL, the DegradationPreference logic should move back to
the adaptation module. The VideoSourceRestrictions are fully capable of
expressing all possible source/sink values without the "modifier" that
is the degradation preference.
Bug: webrtc:11222
Change-Id: I0f058c4700ca108e2d9f212e38b61f6f728aa419
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162802
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@{#30228}
