webrtc_m130/video/video_source_sink_controller_unittest.cc

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

166 lines
5.7 KiB
C++
Raw Normal View History

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
/*
* Copyright 2020 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.
*/
#include "video/video_source_sink_controller.h"
#include <limits>
#include "api/video/video_frame.h"
#include "api/video/video_source_interface.h"
#include "call/adaptation/video_source_restrictions.h"
#include "test/gmock.h"
#include "test/gtest.h"
using testing::_;
namespace webrtc {
namespace {
constexpr int kIntUnconstrained = std::numeric_limits<int>::max();
class MockVideoSinkWithVideoFrame : public rtc::VideoSinkInterface<VideoFrame> {
public:
~MockVideoSinkWithVideoFrame() override {}
MOCK_METHOD(void, OnFrame, (const VideoFrame& frame), (override));
MOCK_METHOD(void, OnDiscardedFrame, (), (override));
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
};
class MockVideoSourceWithVideoFrame
: public rtc::VideoSourceInterface<VideoFrame> {
public:
~MockVideoSourceWithVideoFrame() override {}
MOCK_METHOD(void,
AddOrUpdateSink,
(rtc::VideoSinkInterface<VideoFrame>*,
const rtc::VideoSinkWants&),
(override));
MOCK_METHOD(void,
RemoveSink,
(rtc::VideoSinkInterface<VideoFrame>*),
(override));
MOCK_METHOD(void, RequestRefreshFrame, (), (override));
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
};
} // namespace
TEST(VideoSourceSinkControllerTest, UnconstrainedByDefault) {
MockVideoSinkWithVideoFrame sink;
MockVideoSourceWithVideoFrame source;
VideoSourceSinkController controller(&sink, &source);
EXPECT_EQ(controller.restrictions(), VideoSourceRestrictions());
EXPECT_FALSE(controller.pixels_per_frame_upper_limit().has_value());
EXPECT_FALSE(controller.frame_rate_upper_limit().has_value());
EXPECT_FALSE(controller.rotation_applied());
EXPECT_EQ(controller.resolution_alignment(), 1);
EXPECT_CALL(source, AddOrUpdateSink(_, _))
.WillOnce([](rtc::VideoSinkInterface<VideoFrame>* sink,
const rtc::VideoSinkWants& wants) {
EXPECT_FALSE(wants.rotation_applied);
EXPECT_EQ(wants.max_pixel_count, kIntUnconstrained);
EXPECT_EQ(wants.target_pixel_count, absl::nullopt);
EXPECT_EQ(wants.max_framerate_fps, kIntUnconstrained);
EXPECT_EQ(wants.resolution_alignment, 1);
});
controller.PushSourceSinkSettings();
}
TEST(VideoSourceSinkControllerTest, VideoRestrictionsToSinkWants) {
MockVideoSinkWithVideoFrame sink;
MockVideoSourceWithVideoFrame source;
VideoSourceSinkController controller(&sink, &source);
VideoSourceRestrictions restrictions = controller.restrictions();
// max_pixels_per_frame() maps to `max_pixel_count`.
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
restrictions.set_max_pixels_per_frame(42u);
// target_pixels_per_frame() maps to `target_pixel_count`.
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
restrictions.set_target_pixels_per_frame(200u);
// max_frame_rate() maps to `max_framerate_fps`.
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
restrictions.set_max_frame_rate(30.0);
controller.SetRestrictions(restrictions);
EXPECT_CALL(source, AddOrUpdateSink(_, _))
.WillOnce([](rtc::VideoSinkInterface<VideoFrame>* sink,
const rtc::VideoSinkWants& wants) {
EXPECT_EQ(wants.max_pixel_count, 42);
EXPECT_EQ(wants.target_pixel_count, 200);
EXPECT_EQ(wants.max_framerate_fps, 30);
});
controller.PushSourceSinkSettings();
// pixels_per_frame_upper_limit() caps `max_pixel_count`.
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
controller.SetPixelsPerFrameUpperLimit(24);
// frame_rate_upper_limit() caps `max_framerate_fps`.
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
controller.SetFrameRateUpperLimit(10.0);
EXPECT_CALL(source, AddOrUpdateSink(_, _))
.WillOnce([](rtc::VideoSinkInterface<VideoFrame>* sink,
const rtc::VideoSinkWants& wants) {
EXPECT_EQ(wants.max_pixel_count, 24);
EXPECT_EQ(wants.max_framerate_fps, 10);
});
controller.PushSourceSinkSettings();
}
TEST(VideoSourceSinkControllerTest, RotationApplied) {
MockVideoSinkWithVideoFrame sink;
MockVideoSourceWithVideoFrame source;
VideoSourceSinkController controller(&sink, &source);
controller.SetRotationApplied(true);
EXPECT_TRUE(controller.rotation_applied());
EXPECT_CALL(source, AddOrUpdateSink(_, _))
.WillOnce([](rtc::VideoSinkInterface<VideoFrame>* sink,
const rtc::VideoSinkWants& wants) {
EXPECT_TRUE(wants.rotation_applied);
});
controller.PushSourceSinkSettings();
}
TEST(VideoSourceSinkControllerTest, ResolutionAlignment) {
MockVideoSinkWithVideoFrame sink;
MockVideoSourceWithVideoFrame source;
VideoSourceSinkController controller(&sink, &source);
controller.SetResolutionAlignment(13);
EXPECT_EQ(controller.resolution_alignment(), 13);
EXPECT_CALL(source, AddOrUpdateSink(_, _))
.WillOnce([](rtc::VideoSinkInterface<VideoFrame>* sink,
const rtc::VideoSinkWants& wants) {
EXPECT_EQ(wants.resolution_alignment, 13);
});
controller.PushSourceSinkSettings();
}
TEST(VideoSourceSinkControllerTest,
PushSourceSinkSettingsWithoutSourceDoesNotCrash) {
MockVideoSinkWithVideoFrame sink;
VideoSourceSinkController controller(&sink, nullptr);
controller.PushSourceSinkSettings();
}
TEST(VideoSourceSinkControllerTest, RequestsRefreshFrameWithSource) {
MockVideoSinkWithVideoFrame sink;
MockVideoSourceWithVideoFrame source;
VideoSourceSinkController controller(&sink, &source);
EXPECT_CALL(source, RequestRefreshFrame);
controller.RequestRefreshFrame();
}
TEST(VideoSourceSinkControllerTest,
RequestsRefreshFrameWithoutSourceDoesNotCrash) {
MockVideoSinkWithVideoFrame sink;
VideoSourceSinkController controller(&sink, nullptr);
controller.RequestRefreshFrame();
}
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
} // namespace webrtc