webrtc_m130/call/adaptation/resource_adaptation_module_interface.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

69 lines
2.9 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 "api/rtp_parameters.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 {
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;
};
} // namespace webrtc
#endif // CALL_ADAPTATION_RESOURCE_ADAPTATION_MODULE_INTERFACE_H_