webrtc_m130/video/video_source_sink_controller_unittest.cc

200 lines
7.0 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 {
Reland "RtpEncodingParameters::request_resolution patch 1" This reverts commit b625101da8d798c936cfd695505a5514644158b0. Reason for revert: Found problem that was specific how configuration is handled for VP9. A 1-line change in webrtc_video_engine.cc line 3715. Thanks Rasmus and great that this was tested! Original change's description: > Revert "RtpEncodingParameters::request_resolution patch 1" > > This reverts commit ef7359e679e579ccb79afacf5c42e8c6020124e2. > > Reason for revert: Breaks downstream test > > Original change's description: > > RtpEncodingParameters::request_resolution patch 1 > > > > This patch adds RtpEncodingParameters::request_resolution > > with documentation and plumming. No behaviour is changed yet. > > > > Bug: webrtc:14451 > > Change-Id: I1f4f83a312ee8c293e3d8f02b950751e62048304 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276262 > > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> > > Reviewed-by: Henrik Boström <hbos@webrtc.org> > > Reviewed-by: Rasmus Brandt <brandtr@webrtc.org> > > Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> > > Commit-Queue: Jonas Oreland <jonaso@webrtc.org> > > Cr-Commit-Position: refs/heads/main@{#38172} > > Bug: webrtc:14451 > Change-Id: I4b9590e23ec38e9e1c2e51a4600ef96b129439f2 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276541 > Commit-Queue: Björn Terelius <terelius@webrtc.org> > Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > Reviewed-by: Jonas Oreland <jonaso@webrtc.org> > Owners-Override: Björn Terelius <terelius@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#38176} Bug: webrtc:14451 Change-Id: Ica9b74180bce22d09bf289126bb5ac137bf9eb70 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276543 Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Jonas Oreland <jonaso@webrtc.org> Cr-Commit-Position: refs/heads/main@{#38178}
2022-09-23 12:08:57 +02:00
using FrameSize = rtc::VideoSinkWants::FrameSize;
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
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());
Reland "Rename `requested_resolution` to `scale_resolution_down_to`." This is a reland of commit 82617ac51e7825db53451818f4d1ad52b69761fd The reason for the revert was a downstream use of `rtc::VideoSinkWants::requested_resolution`, so in this reland we don't rename this field, it's fine just to rename the one in RtpEncodingParameters for now. Original change's description: > Rename `requested_resolution` to `scale_resolution_down_to`. > > This is a pure refactor/rename CL without any changes in behavior. > > This field is called scaleResolutionDownTo in the spec and JavaScript. > Let's make C++ match to avoid confusion. > > In order not to break downstream during the transition a variable with > the old name being a pure reference to the renamed attribute is added. > This means we have to add custom constructors, but we can change this > back to "= default" when the transition is completed, which should only > be a couple of CLs away. > > Bug: webrtc:375048799 > Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560 > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> > Reviewed-by: Henrik Andreassson <henrika@webrtc.org> > Commit-Queue: Henrik Boström <hbos@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#43300} NOTRY=True Bug: webrtc:375048799 Change-Id: Ic4ee156c1d50aa36070a8d84059870791dcbbe5e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366660 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Henrik Andreassson <henrika@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Cr-Commit-Position: refs/heads/main@{#43304}
2024-10-25 09:51:44 +02:00
EXPECT_FALSE(controller.scale_resolution_down_to().has_value());
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
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, std::nullopt);
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
EXPECT_EQ(wants.max_framerate_fps, kIntUnconstrained);
EXPECT_EQ(wants.resolution_alignment, 1);
Revert "Rename `requested_resolution` to `scale_resolution_down_to`." This reverts commit 82617ac51e7825db53451818f4d1ad52b69761fd. Reason for revert: Break downstream projects Original change's description: > Rename `requested_resolution` to `scale_resolution_down_to`. > > This is a pure refactor/rename CL without any changes in behavior. > > This field is called scaleResolutionDownTo in the spec and JavaScript. > Let's make C++ match to avoid confusion. > > In order not to break downstream during the transition a variable with > the old name being a pure reference to the renamed attribute is added. > This means we have to add custom constructors, but we can change this > back to "= default" when the transition is completed, which should only > be a couple of CLs away. > > Bug: webrtc:375048799 > Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560 > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> > Reviewed-by: Henrik Andreassson <henrika@webrtc.org> > Commit-Queue: Henrik Boström <hbos@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#43300} Bug: webrtc:375048799 Change-Id: Ie41723a39420e12e7b5b681d3d00ccd14f66b4b1 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366642 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Florent Castelli <orphis@webrtc.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#43301}
2024-10-24 14:36:27 +00:00
EXPECT_FALSE(wants.requested_resolution.has_value());
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.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();
}
Reland "RtpEncodingParameters::request_resolution patch 1" This reverts commit b625101da8d798c936cfd695505a5514644158b0. Reason for revert: Found problem that was specific how configuration is handled for VP9. A 1-line change in webrtc_video_engine.cc line 3715. Thanks Rasmus and great that this was tested! Original change's description: > Revert "RtpEncodingParameters::request_resolution patch 1" > > This reverts commit ef7359e679e579ccb79afacf5c42e8c6020124e2. > > Reason for revert: Breaks downstream test > > Original change's description: > > RtpEncodingParameters::request_resolution patch 1 > > > > This patch adds RtpEncodingParameters::request_resolution > > with documentation and plumming. No behaviour is changed yet. > > > > Bug: webrtc:14451 > > Change-Id: I1f4f83a312ee8c293e3d8f02b950751e62048304 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276262 > > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> > > Reviewed-by: Henrik Boström <hbos@webrtc.org> > > Reviewed-by: Rasmus Brandt <brandtr@webrtc.org> > > Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> > > Commit-Queue: Jonas Oreland <jonaso@webrtc.org> > > Cr-Commit-Position: refs/heads/main@{#38172} > > Bug: webrtc:14451 > Change-Id: I4b9590e23ec38e9e1c2e51a4600ef96b129439f2 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276541 > Commit-Queue: Björn Terelius <terelius@webrtc.org> > Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > Reviewed-by: Jonas Oreland <jonaso@webrtc.org> > Owners-Override: Björn Terelius <terelius@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#38176} Bug: webrtc:14451 Change-Id: Ica9b74180bce22d09bf289126bb5ac137bf9eb70 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276543 Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Jonas Oreland <jonaso@webrtc.org> Cr-Commit-Position: refs/heads/main@{#38178}
2022-09-23 12:08:57 +02:00
Reland "Rename `requested_resolution` to `scale_resolution_down_to`." This is a reland of commit 82617ac51e7825db53451818f4d1ad52b69761fd The reason for the revert was a downstream use of `rtc::VideoSinkWants::requested_resolution`, so in this reland we don't rename this field, it's fine just to rename the one in RtpEncodingParameters for now. Original change's description: > Rename `requested_resolution` to `scale_resolution_down_to`. > > This is a pure refactor/rename CL without any changes in behavior. > > This field is called scaleResolutionDownTo in the spec and JavaScript. > Let's make C++ match to avoid confusion. > > In order not to break downstream during the transition a variable with > the old name being a pure reference to the renamed attribute is added. > This means we have to add custom constructors, but we can change this > back to "= default" when the transition is completed, which should only > be a couple of CLs away. > > Bug: webrtc:375048799 > Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560 > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> > Reviewed-by: Henrik Andreassson <henrika@webrtc.org> > Commit-Queue: Henrik Boström <hbos@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#43300} NOTRY=True Bug: webrtc:375048799 Change-Id: Ic4ee156c1d50aa36070a8d84059870791dcbbe5e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366660 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Henrik Andreassson <henrika@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Cr-Commit-Position: refs/heads/main@{#43304}
2024-10-25 09:51:44 +02:00
TEST(VideoSourceSinkControllerTest, ScaleResolutionDownToPropagatesToWants) {
Reland "RtpEncodingParameters::request_resolution patch 1" This reverts commit b625101da8d798c936cfd695505a5514644158b0. Reason for revert: Found problem that was specific how configuration is handled for VP9. A 1-line change in webrtc_video_engine.cc line 3715. Thanks Rasmus and great that this was tested! Original change's description: > Revert "RtpEncodingParameters::request_resolution patch 1" > > This reverts commit ef7359e679e579ccb79afacf5c42e8c6020124e2. > > Reason for revert: Breaks downstream test > > Original change's description: > > RtpEncodingParameters::request_resolution patch 1 > > > > This patch adds RtpEncodingParameters::request_resolution > > with documentation and plumming. No behaviour is changed yet. > > > > Bug: webrtc:14451 > > Change-Id: I1f4f83a312ee8c293e3d8f02b950751e62048304 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276262 > > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> > > Reviewed-by: Henrik Boström <hbos@webrtc.org> > > Reviewed-by: Rasmus Brandt <brandtr@webrtc.org> > > Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> > > Commit-Queue: Jonas Oreland <jonaso@webrtc.org> > > Cr-Commit-Position: refs/heads/main@{#38172} > > Bug: webrtc:14451 > Change-Id: I4b9590e23ec38e9e1c2e51a4600ef96b129439f2 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276541 > Commit-Queue: Björn Terelius <terelius@webrtc.org> > Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > Reviewed-by: Jonas Oreland <jonaso@webrtc.org> > Owners-Override: Björn Terelius <terelius@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#38176} Bug: webrtc:14451 Change-Id: Ica9b74180bce22d09bf289126bb5ac137bf9eb70 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276543 Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Jonas Oreland <jonaso@webrtc.org> Cr-Commit-Position: refs/heads/main@{#38178}
2022-09-23 12:08:57 +02:00
MockVideoSinkWithVideoFrame sink;
MockVideoSourceWithVideoFrame source;
VideoSourceSinkController controller(&sink, &source);
Reland "Rename `requested_resolution` to `scale_resolution_down_to`." This is a reland of commit 82617ac51e7825db53451818f4d1ad52b69761fd The reason for the revert was a downstream use of `rtc::VideoSinkWants::requested_resolution`, so in this reland we don't rename this field, it's fine just to rename the one in RtpEncodingParameters for now. Original change's description: > Rename `requested_resolution` to `scale_resolution_down_to`. > > This is a pure refactor/rename CL without any changes in behavior. > > This field is called scaleResolutionDownTo in the spec and JavaScript. > Let's make C++ match to avoid confusion. > > In order not to break downstream during the transition a variable with > the old name being a pure reference to the renamed attribute is added. > This means we have to add custom constructors, but we can change this > back to "= default" when the transition is completed, which should only > be a couple of CLs away. > > Bug: webrtc:375048799 > Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560 > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> > Reviewed-by: Henrik Andreassson <henrika@webrtc.org> > Commit-Queue: Henrik Boström <hbos@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#43300} NOTRY=True Bug: webrtc:375048799 Change-Id: Ic4ee156c1d50aa36070a8d84059870791dcbbe5e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366660 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Henrik Andreassson <henrika@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Cr-Commit-Position: refs/heads/main@{#43304}
2024-10-25 09:51:44 +02:00
controller.SetScaleResolutionDownTo(FrameSize(640, 360));
EXPECT_TRUE(controller.scale_resolution_down_to().has_value());
Reland "RtpEncodingParameters::request_resolution patch 1" This reverts commit b625101da8d798c936cfd695505a5514644158b0. Reason for revert: Found problem that was specific how configuration is handled for VP9. A 1-line change in webrtc_video_engine.cc line 3715. Thanks Rasmus and great that this was tested! Original change's description: > Revert "RtpEncodingParameters::request_resolution patch 1" > > This reverts commit ef7359e679e579ccb79afacf5c42e8c6020124e2. > > Reason for revert: Breaks downstream test > > Original change's description: > > RtpEncodingParameters::request_resolution patch 1 > > > > This patch adds RtpEncodingParameters::request_resolution > > with documentation and plumming. No behaviour is changed yet. > > > > Bug: webrtc:14451 > > Change-Id: I1f4f83a312ee8c293e3d8f02b950751e62048304 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276262 > > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> > > Reviewed-by: Henrik Boström <hbos@webrtc.org> > > Reviewed-by: Rasmus Brandt <brandtr@webrtc.org> > > Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> > > Commit-Queue: Jonas Oreland <jonaso@webrtc.org> > > Cr-Commit-Position: refs/heads/main@{#38172} > > Bug: webrtc:14451 > Change-Id: I4b9590e23ec38e9e1c2e51a4600ef96b129439f2 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276541 > Commit-Queue: Björn Terelius <terelius@webrtc.org> > Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > Reviewed-by: Jonas Oreland <jonaso@webrtc.org> > Owners-Override: Björn Terelius <terelius@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#38176} Bug: webrtc:14451 Change-Id: Ica9b74180bce22d09bf289126bb5ac137bf9eb70 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276543 Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Jonas Oreland <jonaso@webrtc.org> Cr-Commit-Position: refs/heads/main@{#38178}
2022-09-23 12:08:57 +02:00
EXPECT_CALL(source, AddOrUpdateSink(_, _))
.WillOnce([](rtc::VideoSinkInterface<VideoFrame>* sink,
const rtc::VideoSinkWants& wants) {
Revert "Rename `requested_resolution` to `scale_resolution_down_to`." This reverts commit 82617ac51e7825db53451818f4d1ad52b69761fd. Reason for revert: Break downstream projects Original change's description: > Rename `requested_resolution` to `scale_resolution_down_to`. > > This is a pure refactor/rename CL without any changes in behavior. > > This field is called scaleResolutionDownTo in the spec and JavaScript. > Let's make C++ match to avoid confusion. > > In order not to break downstream during the transition a variable with > the old name being a pure reference to the renamed attribute is added. > This means we have to add custom constructors, but we can change this > back to "= default" when the transition is completed, which should only > be a couple of CLs away. > > Bug: webrtc:375048799 > Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560 > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> > Reviewed-by: Henrik Andreassson <henrika@webrtc.org> > Commit-Queue: Henrik Boström <hbos@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#43300} Bug: webrtc:375048799 Change-Id: Ie41723a39420e12e7b5b681d3d00ccd14f66b4b1 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366642 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Florent Castelli <orphis@webrtc.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#43301}
2024-10-24 14:36:27 +00:00
EXPECT_EQ(*wants.requested_resolution, FrameSize(640, 360));
Reland "RtpEncodingParameters::request_resolution patch 1" This reverts commit b625101da8d798c936cfd695505a5514644158b0. Reason for revert: Found problem that was specific how configuration is handled for VP9. A 1-line change in webrtc_video_engine.cc line 3715. Thanks Rasmus and great that this was tested! Original change's description: > Revert "RtpEncodingParameters::request_resolution patch 1" > > This reverts commit ef7359e679e579ccb79afacf5c42e8c6020124e2. > > Reason for revert: Breaks downstream test > > Original change's description: > > RtpEncodingParameters::request_resolution patch 1 > > > > This patch adds RtpEncodingParameters::request_resolution > > with documentation and plumming. No behaviour is changed yet. > > > > Bug: webrtc:14451 > > Change-Id: I1f4f83a312ee8c293e3d8f02b950751e62048304 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276262 > > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> > > Reviewed-by: Henrik Boström <hbos@webrtc.org> > > Reviewed-by: Rasmus Brandt <brandtr@webrtc.org> > > Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> > > Commit-Queue: Jonas Oreland <jonaso@webrtc.org> > > Cr-Commit-Position: refs/heads/main@{#38172} > > Bug: webrtc:14451 > Change-Id: I4b9590e23ec38e9e1c2e51a4600ef96b129439f2 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276541 > Commit-Queue: Björn Terelius <terelius@webrtc.org> > Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> > Reviewed-by: Jonas Oreland <jonaso@webrtc.org> > Owners-Override: Björn Terelius <terelius@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#38176} Bug: webrtc:14451 Change-Id: Ica9b74180bce22d09bf289126bb5ac137bf9eb70 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276543 Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Jonas Oreland <jonaso@webrtc.org> Cr-Commit-Position: refs/heads/main@{#38178}
2022-09-23 12:08:57 +02:00
});
controller.PushSourceSinkSettings();
}
TEST(VideoSourceSinkControllerTest, ActivePropagatesToWants) {
MockVideoSinkWithVideoFrame sink;
MockVideoSourceWithVideoFrame source;
VideoSourceSinkController controller(&sink, &source);
controller.SetActive(true);
EXPECT_TRUE(controller.active());
EXPECT_CALL(source, AddOrUpdateSink(_, _))
.WillOnce([](rtc::VideoSinkInterface<VideoFrame>* sink,
const rtc::VideoSinkWants& wants) {
EXPECT_TRUE(wants.is_active);
});
controller.PushSourceSinkSettings();
}
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