webrtc_m130/call/adaptation/resource_adaptation_module_interface.h

99 lines
4.2 KiB
C
Raw Normal View History

/*
* Copyright 2019 The WebRTC Project Authors. All rights reserved.
*
* Use of this source code is governed by a BSD-style license
* that can be found in the LICENSE file in the root of the source
* tree. An additional intellectual property rights grant can be found
* in the file PATENTS. All contributing project authors may
* be found in the AUTHORS file in the root of the source tree.
*/
#ifndef CALL_ADAPTATION_RESOURCE_ADAPTATION_MODULE_INTERFACE_H_
#define CALL_ADAPTATION_RESOURCE_ADAPTATION_MODULE_INTERFACE_H_
#include "absl/types/optional.h"
#include "api/rtp_parameters.h"
#include "api/video_codecs/video_encoder.h"
#include "api/video_codecs/video_encoder_config.h"
VideoStreamEncoder configuring source/sink with VideoSourceController. 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}
2020-01-13 11:27:18 +01:00
#include "call/adaptation/video_source_restrictions.h"
Introduce ResourceAdaptationModuleListener and VideoSourceRestrictions. The VideoSourceRestrictions describe the maximum pixels per frame and max frame rate of a video source. This CL makes the ResourceAdaptationModuleInterface responsible for the reconfiguration of video sources. The VideoSourceRestrictions is the output of an adaptation module, and the ResourceAdaptationModuleListener handles the callback for when the source restrictions change. The OveruseFrameDetectorResourceAdaptationModule is updated to output its changes using these interfaces, and VideoStreamEncoder - now a listener - is made responsible for triggering the reconfiguring the video source. Performing the reconfiguration still requires interacting with the VideoSourceProxy - it is still partially responsible for keeping track of rtc::VideoSinkWants settings and performing AddOrUpdateSink(). For now this may look a bit weird: the VideoSourceProxy tells the VideoStreamEncoder about the new restrictions, and then the VideoStreamEncoder tells the VideoSourceProxy to apply these restrictions on the source/sink. This exercises the listener though, and unblocks the next CL. The next CL should move all "configuring the source" logic to the VideoStreamEncoder instead, so that the only information that is tracked by OveruseFrameDetectorResourceAdaptationModule is what it actually outputs to the listener. See the next CL (https://webrtc-review.googlesource.com/c/src/+/162802) where a VideoSourceController is introduced, to be owned by the VideoStreamEncoder rather than the adaptation module. Bug: webrtc:11222 Change-Id: I450ce74f51d96c4b98009a06134db671893d8fdc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162522 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@{#30227}
2020-01-10 15:44:01 +01:00
namespace webrtc {
// Information about an encoder available when reconfiguring the encoder.
class EncoderSettings {
public:
EncoderSettings(VideoEncoder::EncoderInfo encoder_info,
VideoEncoderConfig encoder_config,
VideoCodec video_codec);
// Encoder capabilities, implementation info, etc.
const VideoEncoder::EncoderInfo& encoder_info() const;
// Configuration parameters, ultimately coming from the API and negotiation.
const VideoEncoderConfig& encoder_config() const;
// Lower level config, heavily based on the VideoEncoderConfig.
const VideoCodec& video_codec() const;
private:
VideoEncoder::EncoderInfo encoder_info_;
VideoEncoderConfig encoder_config_;
VideoCodec video_codec_;
};
Introduce ResourceAdaptationModuleListener and VideoSourceRestrictions. The VideoSourceRestrictions describe the maximum pixels per frame and max frame rate of a video source. This CL makes the ResourceAdaptationModuleInterface responsible for the reconfiguration of video sources. The VideoSourceRestrictions is the output of an adaptation module, and the ResourceAdaptationModuleListener handles the callback for when the source restrictions change. The OveruseFrameDetectorResourceAdaptationModule is updated to output its changes using these interfaces, and VideoStreamEncoder - now a listener - is made responsible for triggering the reconfiguring the video source. Performing the reconfiguration still requires interacting with the VideoSourceProxy - it is still partially responsible for keeping track of rtc::VideoSinkWants settings and performing AddOrUpdateSink(). For now this may look a bit weird: the VideoSourceProxy tells the VideoStreamEncoder about the new restrictions, and then the VideoStreamEncoder tells the VideoSourceProxy to apply these restrictions on the source/sink. This exercises the listener though, and unblocks the next CL. The next CL should move all "configuring the source" logic to the VideoStreamEncoder instead, so that the only information that is tracked by OveruseFrameDetectorResourceAdaptationModule is what it actually outputs to the listener. See the next CL (https://webrtc-review.googlesource.com/c/src/+/162802) where a VideoSourceController is introduced, to be owned by the VideoStreamEncoder rather than the adaptation module. Bug: webrtc:11222 Change-Id: I450ce74f51d96c4b98009a06134db671893d8fdc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162522 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@{#30227}
2020-01-10 15:44:01 +01:00
// The listener is responsible for carrying out the reconfiguration of the video
// source such that the VideoSourceRestrictions are fulfilled.
class ResourceAdaptationModuleListener {
public:
virtual ~ResourceAdaptationModuleListener();
// TODO(hbos): When we support the muli-stream use case, the arguments need to
// specify which video stream's source needs to be reconfigured.
virtual void OnVideoSourceRestrictionsUpdated(
VideoSourceRestrictions restrictions) = 0;
};
// Responsible for reconfiguring encoded streams based on resource consumption,
// such as scaling down resolution or frame rate when CPU is overused. This
// interface is meant to be injectable into VideoStreamEncoder.
//
// [UNDER CONSTRUCTION] This interface is work-in-progress. In the future it
// needs to be able to handle all the necessary input and output for resource
// adaptation decision making.
//
// TODO(https://crbug.com/webrtc/11222): Make this interface feature-complete so
// that a module (such as OveruseFrameDetectorResourceAdaptationModule) is fully
// operational through this abstract interface.
class ResourceAdaptationModuleInterface {
public:
virtual ~ResourceAdaptationModuleInterface();
// TODO(hbos): When input/output of the module is adequetly handled by this
// interface, these methods need to say which stream to start/stop, enabling
// multi-stream aware implementations of ResourceAdaptationModuleInterface. We
// don't want to do this before we have the right interfaces (e.g. if we pass
// in a VideoStreamEncoder here directly then have a dependency on a different
// build target). For the multi-stream use case we may consider making
// ResourceAdaptationModuleInterface reference counted.
virtual void StartResourceAdaptation(
Introduce ResourceAdaptationModuleListener and VideoSourceRestrictions. The VideoSourceRestrictions describe the maximum pixels per frame and max frame rate of a video source. This CL makes the ResourceAdaptationModuleInterface responsible for the reconfiguration of video sources. The VideoSourceRestrictions is the output of an adaptation module, and the ResourceAdaptationModuleListener handles the callback for when the source restrictions change. The OveruseFrameDetectorResourceAdaptationModule is updated to output its changes using these interfaces, and VideoStreamEncoder - now a listener - is made responsible for triggering the reconfiguring the video source. Performing the reconfiguration still requires interacting with the VideoSourceProxy - it is still partially responsible for keeping track of rtc::VideoSinkWants settings and performing AddOrUpdateSink(). For now this may look a bit weird: the VideoSourceProxy tells the VideoStreamEncoder about the new restrictions, and then the VideoStreamEncoder tells the VideoSourceProxy to apply these restrictions on the source/sink. This exercises the listener though, and unblocks the next CL. The next CL should move all "configuring the source" logic to the VideoStreamEncoder instead, so that the only information that is tracked by OveruseFrameDetectorResourceAdaptationModule is what it actually outputs to the listener. See the next CL (https://webrtc-review.googlesource.com/c/src/+/162802) where a VideoSourceController is introduced, to be owned by the VideoStreamEncoder rather than the adaptation module. Bug: webrtc:11222 Change-Id: I450ce74f51d96c4b98009a06134db671893d8fdc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162522 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@{#30227}
2020-01-10 15:44:01 +01:00
ResourceAdaptationModuleListener* adaptation_listener) = 0;
virtual void StopResourceAdaptation() = 0;
// The following methods are callable whether or not adaption is started.
// Informs the module whether we have input video. By default, the module must
// assume the value is false.
virtual void SetHasInputVideo(bool has_input_video) = 0;
virtual void SetDegradationPreference(
DegradationPreference degradation_preference) = 0;
virtual void SetEncoderSettings(EncoderSettings encoder_settings) = 0;
virtual void SetEncoderTargetBitrate(
absl::optional<uint32_t> target_bitrate_bps) = 0;
[Overuse] MaybeUpdateTargetFrameRate() & ResetVideoSourceRestrictions() This CL does two things for the sake of getting us closer to adaptation modules being injectable and usable without knowing implementation details. Firstly, RefreshTargetFramerate() is removed. The target frame rate is dependent on two things: 1) the codec max frame rate, and 2) the video source restrictions. If either of these two changes, the target frame rate is updated - there is no need to trigger this externally; the module already knows if either of these factors change. The private method MaybeUpdateTargetFrameRate() is added to ensure overuse_detector->OnTargetFramerateUpdated() happens when necessary. In doing this, the frame rates are updated to use absl::optional<double>. This documents its optionality and avoids magical values (previously -1 was not a bug but meaning "missing"). It also matches VideoSourceRestrictions::max_frame_rate()'s type. Secondly, ResetAdaptationCounters() is renamed ResetVideoSourceRestrictions(). This more accurately describes what it is doing; it is resetting the restrictions (the adaptation counters getting reset is merely an implementation specific side-effect of this). This method is added to the generic interface. The usefulness of being able to ResetVideoSourceRestrictions() is questioned in a TODO - current usage of this is when "quality rampup" finishes. Nevertheless, any module could implement this functionality so it belongs to the interface for now. Bug: webrtc:11222 Change-Id: I079785df55fc9894e85087ec98be3e4ebd0713c5 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166522 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@{#30320}
2020-01-20 11:16:50 +01:00
// Removes all restrictions; the module will need to adapt all over again.
// TODO(hbos): It's not clear why anybody should be able to tell the module to
// reset like this; can we get rid of this method?
virtual void ResetVideoSourceRestrictions() = 0;
};
} // namespace webrtc
#endif // CALL_ADAPTATION_RESOURCE_ADAPTATION_MODULE_INTERFACE_H_