admin/webrtc_m130
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
webrtc_m130/video/video_source_sink_controller.h

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

95 lines
3.9 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.
*/
#ifndef VIDEO_VIDEO_SOURCE_SINK_CONTROLLER_H_
#define VIDEO_VIDEO_SOURCE_SINK_CONTROLLER_H_
Add logging for video restrictions This will help show what the restrictions are before and after they transform into sink wants. These will not be so spammy as adaptations do not happen very often. Bug: None Change-Id: Ib72b313f68c6934d7833d8a3f14ce00df602832b Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175800 Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Evan Shrubsole <eshr@google.com> Cr-Commit-Position: refs/heads/master@{#31341}
2020-05-20 12:24:57 +02:00
#include <string>
Communicate encoder resolutions via rtc::VideoSinkWants. This will allow us to optimize the internal buffers of webrtc::VideoFrame for the resolution(s) that we actually want to encode. Bug: webrtc:12469, chromium:1157072 Change-Id: If378b52b5e35aa9a9800c1f7dfe189437ce43253 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208540 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33342}
2021-02-25 10:30:39 +01:00
#include <vector>
Add logging for video restrictions This will help show what the restrictions are before and after they transform into sink wants. These will not be so spammy as adaptations do not happen very often. Bug: None Change-Id: Ib72b313f68c6934d7833d8a3f14ce00df602832b Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175800 Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Evan Shrubsole <eshr@google.com> Cr-Commit-Position: refs/heads/master@{#31341}
2020-05-20 12:24:57 +02:00
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 "absl/types/optional.h"
Use SequenceChecker from public API Bug: webrtc:12419 Change-Id: I00cca16a0ec70246156ba00b97aa7ae5ccbf5364 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205323 Commit-Queue: Artem Titov <titovartem@webrtc.org> Reviewed-by: Tommi <tommi@webrtc.org> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33220}
2021-02-10 14:31:24 +01:00
#include "api/sequence_checker.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 "api/video/video_frame.h"
#include "api/video/video_sink_interface.h"
#include "api/video/video_source_interface.h"
[Adaptation] Rename and move resource adaptation module/processor stuff. Rename: - call/adaptation/resource_adaptation_module_interface.[h/cc] --> call/adaptation/resource_adaptation_processor_interface.[h/cc] - call/adaptation/resource_adaptation_processor.[h/cc] --> call/adaptation/new_resource_adaptation_processor_poc.[h/cc] Move + Rename: - video/overuse_frame_detector_resource_adaptation_module.[h/cc] --> video/adaptation/resource_adaptation_processor.[h/cc] Move: - video/encode_usage_resource.[h/cc] --> video/adaptation/... - video/overuse_frame_detector.[h/cc] --> video/adaptation/... - video/quality_scaler_resource.[h/cc] --> video/adaptation/... Unittests are also moved. In order to avoid a circular dependency, VideoStreamEncoder::kDefaultLastFrameInfo[Width/Height] is moved and renamed to kDefaultInputPixels[Width/Height] in video/adaptation/resource_adaptation_processor.[h/cc]. Bug: webrtc:11222 Change-Id: Icf920e8a7362002b1c63c42b2d9e2e63c990b532 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/170117 Reviewed-by: Evan Shrubsole <eshr@google.com> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/master@{#30754}
2020-03-10 19:08:05 +01:00
#include "call/adaptation/video_source_restrictions.h"
Reland "Introduce RTC_NO_UNIQUE_ADDRESS." This is a reland of f5e261aaf65cdf2eb903cdf40d651846be44f447 This CL disables RTC_NO_UNIQUE_ADDRESS on MSan builds since there have been some issues. Original change's description: > Introduce RTC_NO_UNIQUE_ADDRESS. > > This macro introduces the possibility to suggest the compiler that a > data member doesn't need an address different from other non static > data members. > > The usage of a macro is to maintain portability since at the moment > the attribute [[no_unique_address]] is only supported by clang > with at least -std=c++11 but it should be supported by all the > compilers starting from C++20. > > Bug: webrtc:11495 > Change-Id: I9f12b67b4422a2749649eaa6b004a67d5fd572d8 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173331 > Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> > Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#32246} Bug: webrtc:11495, webrtc:12218 Change-Id: I4e6c7cc37d3daffad2407c9a2acfa897fa5b426a Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/189968 Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> Cr-Commit-Position: refs/heads/master@{#32668}
2020-11-23 11:07:42 +01:00
#include "rtc_base/system/no_unique_address.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
namespace webrtc {
// Responsible for configuring source/sink settings, i.e. performing
// rtc::VideoSourceInterface<VideoFrame>::AddOrUpdateSink(). It does this by
// storing settings internally which are converted to rtc::VideoSinkWants when
// PushSourceSinkSettings() is performed.
class VideoSourceSinkController {
public:
VideoSourceSinkController(rtc::VideoSinkInterface<VideoFrame>* sink,
rtc::VideoSourceInterface<VideoFrame>* source);
Remove use of asyncinvoker from WebRtcVideoSendStream. This turned out to be a bit complicated, mostly related to the tests, but here's what's changed: * No AsyncInvoker (and avoid ClearInternal) in WebRtcVideoSendStream (WVSS) * The reason it was there is due to a "design leak" from VideoSourceSinkController/VideoStreamEncoder where the former uses locks in all methods and is unaware of a threading model. That design affected downstream objects, pushed the need for an async hop into WVSS and added a lock. A suggestion was made to address this in a follow-up change, here: https://webrtc-review.googlesource.com/c/src/+/165684 * All methods in VideoSourceSinkController are now called on a known and checked sequence and this CL removes the lock. This also makes checking state consistent (i.e. calling a getter twice in a row on the same sequence, will always return the same value, avoiding race with other threads). * Handling of reporting state changes from the encoder queue to the VSSC, is done by VideoStreamEncoder. * VideoSendStreamImpl is still instantiated on the incorrect thread [1] but has two initialization steps [2]. The second one already runs on the right thread. Addressing that TODO [1] is something we should do but it has side effects to consider. For the purposes of this CL the steps relating to the encoder (setting the sink pointer) have been moved to [2]. [1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;l=94 [2] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;drc=f4a9991cce74a37d006438ec0e366313ed33162e;l=115 Bug: webrtc:11222, webrtc:11908 Change-Id: Ie46d46e3a52bbe225951b4bd580ecb8cc9cad873 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184508 Reviewed-by: Henrik Boström <hbos@webrtc.org> Commit-Queue: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#32150}
2020-09-21 14:31:23 +02:00
~VideoSourceSinkController();
Move DegradationPreference logic out of VideoSourceSinkController. The DegradationPreference logic is moved into OveruseFrameDetectorResourceAdaptationModule. This makes the adaptation module solely responsible for degradation preference, and the VideoStreamEncoder the only bridge between the adaptation module and the VideoSourceSinkController. The adaptation module is now unaware of the existence of a controller. It only "speaks" VideoSourceRestrictions, which is a big milestone in making adaptation modules injectable. A follow-up CL will explore the possibility of reconfiguring the controller's source and which degradation preference to use to the encoder queue. This would allow us to make several classes single-threaded, but it is a change in behavior and should be done in a separate CL. Bug: webrtc:11222 Change-Id: Ib7f640e12789da5f801177926c2072a51818f261 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165684 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@google.com> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Cr-Commit-Position: refs/heads/master@{#30237}
2020-01-13 17:26:50 +01:00
void SetSource(rtc::VideoSourceInterface<VideoFrame>* source);
Remove use of asyncinvoker from WebRtcVideoSendStream. This turned out to be a bit complicated, mostly related to the tests, but here's what's changed: * No AsyncInvoker (and avoid ClearInternal) in WebRtcVideoSendStream (WVSS) * The reason it was there is due to a "design leak" from VideoSourceSinkController/VideoStreamEncoder where the former uses locks in all methods and is unaware of a threading model. That design affected downstream objects, pushed the need for an async hop into WVSS and added a lock. A suggestion was made to address this in a follow-up change, here: https://webrtc-review.googlesource.com/c/src/+/165684 * All methods in VideoSourceSinkController are now called on a known and checked sequence and this CL removes the lock. This also makes checking state consistent (i.e. calling a getter twice in a row on the same sequence, will always return the same value, avoiding race with other threads). * Handling of reporting state changes from the encoder queue to the VSSC, is done by VideoStreamEncoder. * VideoSendStreamImpl is still instantiated on the incorrect thread [1] but has two initialization steps [2]. The second one already runs on the right thread. Addressing that TODO [1] is something we should do but it has side effects to consider. For the purposes of this CL the steps relating to the encoder (setting the sink pointer) have been moved to [2]. [1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;l=94 [2] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;drc=f4a9991cce74a37d006438ec0e366313ed33162e;l=115 Bug: webrtc:11222, webrtc:11908 Change-Id: Ie46d46e3a52bbe225951b4bd580ecb8cc9cad873 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184508 Reviewed-by: Henrik Boström <hbos@webrtc.org> Commit-Queue: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#32150}
2020-09-21 14:31:23 +02:00
bool HasSource() const;
ZeroHertzAdapterMode: handle key frame requests. Under zero-hertz mode, provided that a frame arrived to the VideoStreamEncoder, the receiver may experience up to a second between incoming frames. This results in key frame requests getting serviced with that delay, which is undesired. What's worse is also the fact that if no frame ever arrived to the VideoStreamEncoder, it will not service the keyframe requests at all until the first frame comes. This change introduces VideoSourceInterface::RequestRefreshFrame which results in a refresh frame being sent from complying sources. The method is used under zero-hertz mode from the VideoStreamEncoder when frames didn't arrive to it yet (with changes to the zero-hertz adapter). With this change, when the frame adapter has received at least one frame, it will conditionally repeat the last frame in response to the key frame request. go/rtc-0hz-present Bug: chromium:1255737 Change-Id: I6f97813b3a938747357d45e5dda54f759129b44d Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242361 Reviewed-by: Erik Språng <sprang@webrtc.org> Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Henrik Boström <hbos@webrtc.org> Commit-Queue: Markus Handell <handellm@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35562}
2021-12-21 19:14:58 +01:00
// Requests a refresh frame from the current source, if set.
void 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
// Must be called in order for changes to settings to have an effect. This
// allows you to modify multiple properties in a single push to the sink.
void PushSourceSinkSettings();
VideoSourceRestrictions restrictions() const;
absl::optional<size_t> pixels_per_frame_upper_limit() const;
absl::optional<double> frame_rate_upper_limit() const;
bool rotation_applied() const;
int resolution_alignment() const;
Communicate encoder resolutions via rtc::VideoSinkWants. This will allow us to optimize the internal buffers of webrtc::VideoFrame for the resolution(s) that we actually want to encode. Bug: webrtc:12469, chromium:1157072 Change-Id: If378b52b5e35aa9a9800c1f7dfe189437ce43253 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208540 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33342}
2021-02-25 10:30:39 +01:00
const std::vector<rtc::VideoSinkWants::FrameSize>& resolutions() const;
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
// Updates the settings stored internally. In order for these settings to be
// applied to the sink, PushSourceSinkSettings() must subsequently be called.
void SetRestrictions(VideoSourceRestrictions restrictions);
void SetPixelsPerFrameUpperLimit(
absl::optional<size_t> pixels_per_frame_upper_limit);
void SetFrameRateUpperLimit(absl::optional<double> frame_rate_upper_limit);
void SetRotationApplied(bool rotation_applied);
void SetResolutionAlignment(int resolution_alignment);
Communicate encoder resolutions via rtc::VideoSinkWants. This will allow us to optimize the internal buffers of webrtc::VideoFrame for the resolution(s) that we actually want to encode. Bug: webrtc:12469, chromium:1157072 Change-Id: If378b52b5e35aa9a9800c1f7dfe189437ce43253 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208540 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33342}
2021-02-25 10:30:39 +01:00
void SetResolutions(std::vector<rtc::VideoSinkWants::FrameSize> resolutions);
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
private:
Move DegradationPreference logic out of VideoSourceSinkController. The DegradationPreference logic is moved into OveruseFrameDetectorResourceAdaptationModule. This makes the adaptation module solely responsible for degradation preference, and the VideoStreamEncoder the only bridge between the adaptation module and the VideoSourceSinkController. The adaptation module is now unaware of the existence of a controller. It only "speaks" VideoSourceRestrictions, which is a big milestone in making adaptation modules injectable. A follow-up CL will explore the possibility of reconfiguring the controller's source and which degradation preference to use to the encoder queue. This would allow us to make several classes single-threaded, but it is a change in behavior and should be done in a separate CL. Bug: webrtc:11222 Change-Id: Ib7f640e12789da5f801177926c2072a51818f261 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165684 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@google.com> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Cr-Commit-Position: refs/heads/master@{#30237}
2020-01-13 17:26:50 +01:00
rtc::VideoSinkWants CurrentSettingsToSinkWants() const
Remove use of asyncinvoker from WebRtcVideoSendStream. This turned out to be a bit complicated, mostly related to the tests, but here's what's changed: * No AsyncInvoker (and avoid ClearInternal) in WebRtcVideoSendStream (WVSS) * The reason it was there is due to a "design leak" from VideoSourceSinkController/VideoStreamEncoder where the former uses locks in all methods and is unaware of a threading model. That design affected downstream objects, pushed the need for an async hop into WVSS and added a lock. A suggestion was made to address this in a follow-up change, here: https://webrtc-review.googlesource.com/c/src/+/165684 * All methods in VideoSourceSinkController are now called on a known and checked sequence and this CL removes the lock. This also makes checking state consistent (i.e. calling a getter twice in a row on the same sequence, will always return the same value, avoiding race with other threads). * Handling of reporting state changes from the encoder queue to the VSSC, is done by VideoStreamEncoder. * VideoSendStreamImpl is still instantiated on the incorrect thread [1] but has two initialization steps [2]. The second one already runs on the right thread. Addressing that TODO [1] is something we should do but it has side effects to consider. For the purposes of this CL the steps relating to the encoder (setting the sink pointer) have been moved to [2]. [1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;l=94 [2] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;drc=f4a9991cce74a37d006438ec0e366313ed33162e;l=115 Bug: webrtc:11222, webrtc:11908 Change-Id: Ie46d46e3a52bbe225951b4bd580ecb8cc9cad873 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184508 Reviewed-by: Henrik Boström <hbos@webrtc.org> Commit-Queue: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#32150}
2020-09-21 14:31:23 +02:00
RTC_EXCLUSIVE_LOCKS_REQUIRED(sequence_checker_);
// Used to ensure that this class is called on threads/sequences that it and
// downstream implementations were designed for.
// In practice, this represent's libjingle's worker thread.
Reland "Introduce RTC_NO_UNIQUE_ADDRESS." This is a reland of f5e261aaf65cdf2eb903cdf40d651846be44f447 This CL disables RTC_NO_UNIQUE_ADDRESS on MSan builds since there have been some issues. Original change's description: > Introduce RTC_NO_UNIQUE_ADDRESS. > > This macro introduces the possibility to suggest the compiler that a > data member doesn't need an address different from other non static > data members. > > The usage of a macro is to maintain portability since at the moment > the attribute [[no_unique_address]] is only supported by clang > with at least -std=c++11 but it should be supported by all the > compilers starting from C++20. > > Bug: webrtc:11495 > Change-Id: I9f12b67b4422a2749649eaa6b004a67d5fd572d8 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173331 > Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> > Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#32246} Bug: webrtc:11495, webrtc:12218 Change-Id: I4e6c7cc37d3daffad2407c9a2acfa897fa5b426a Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/189968 Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Karl Wiberg <kwiberg@webrtc.org> Cr-Commit-Position: refs/heads/master@{#32668}
2020-11-23 11:07:42 +01:00
RTC_NO_UNIQUE_ADDRESS SequenceChecker sequence_checker_;
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
rtc::VideoSinkInterface<VideoFrame>* const sink_;
Remove use of asyncinvoker from WebRtcVideoSendStream. This turned out to be a bit complicated, mostly related to the tests, but here's what's changed: * No AsyncInvoker (and avoid ClearInternal) in WebRtcVideoSendStream (WVSS) * The reason it was there is due to a "design leak" from VideoSourceSinkController/VideoStreamEncoder where the former uses locks in all methods and is unaware of a threading model. That design affected downstream objects, pushed the need for an async hop into WVSS and added a lock. A suggestion was made to address this in a follow-up change, here: https://webrtc-review.googlesource.com/c/src/+/165684 * All methods in VideoSourceSinkController are now called on a known and checked sequence and this CL removes the lock. This also makes checking state consistent (i.e. calling a getter twice in a row on the same sequence, will always return the same value, avoiding race with other threads). * Handling of reporting state changes from the encoder queue to the VSSC, is done by VideoStreamEncoder. * VideoSendStreamImpl is still instantiated on the incorrect thread [1] but has two initialization steps [2]. The second one already runs on the right thread. Addressing that TODO [1] is something we should do but it has side effects to consider. For the purposes of this CL the steps relating to the encoder (setting the sink pointer) have been moved to [2]. [1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;l=94 [2] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;drc=f4a9991cce74a37d006438ec0e366313ed33162e;l=115 Bug: webrtc:11222, webrtc:11908 Change-Id: Ie46d46e3a52bbe225951b4bd580ecb8cc9cad873 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184508 Reviewed-by: Henrik Boström <hbos@webrtc.org> Commit-Queue: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#32150}
2020-09-21 14:31:23 +02:00
rtc::VideoSourceInterface<VideoFrame>* source_
RTC_GUARDED_BY(&sequence_checker_);
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
// Pixel and frame rate restrictions.
Remove use of asyncinvoker from WebRtcVideoSendStream. This turned out to be a bit complicated, mostly related to the tests, but here's what's changed: * No AsyncInvoker (and avoid ClearInternal) in WebRtcVideoSendStream (WVSS) * The reason it was there is due to a "design leak" from VideoSourceSinkController/VideoStreamEncoder where the former uses locks in all methods and is unaware of a threading model. That design affected downstream objects, pushed the need for an async hop into WVSS and added a lock. A suggestion was made to address this in a follow-up change, here: https://webrtc-review.googlesource.com/c/src/+/165684 * All methods in VideoSourceSinkController are now called on a known and checked sequence and this CL removes the lock. This also makes checking state consistent (i.e. calling a getter twice in a row on the same sequence, will always return the same value, avoiding race with other threads). * Handling of reporting state changes from the encoder queue to the VSSC, is done by VideoStreamEncoder. * VideoSendStreamImpl is still instantiated on the incorrect thread [1] but has two initialization steps [2]. The second one already runs on the right thread. Addressing that TODO [1] is something we should do but it has side effects to consider. For the purposes of this CL the steps relating to the encoder (setting the sink pointer) have been moved to [2]. [1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;l=94 [2] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;drc=f4a9991cce74a37d006438ec0e366313ed33162e;l=115 Bug: webrtc:11222, webrtc:11908 Change-Id: Ie46d46e3a52bbe225951b4bd580ecb8cc9cad873 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184508 Reviewed-by: Henrik Boström <hbos@webrtc.org> Commit-Queue: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#32150}
2020-09-21 14:31:23 +02:00
VideoSourceRestrictions restrictions_ RTC_GUARDED_BY(&sequence_checker_);
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
// Ensures that even if we are not restricted, the sink is never configured
Use backticks not vertical bars to denote variables in comments for /video Bug: webrtc:12338 Change-Id: I47958800407482894ff6f17c1887dce907fdf35a Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227030 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Artem Titov <titovartem@webrtc.org> Cr-Commit-Position: refs/heads/master@{#34585}
2021-07-27 16:22:11 +02:00
// above this limit. Example: We are not CPU limited (no `restrictions_`) but
// our encoder is capped at 30 fps (= `frame_rate_upper_limit_`).
Remove use of asyncinvoker from WebRtcVideoSendStream. This turned out to be a bit complicated, mostly related to the tests, but here's what's changed: * No AsyncInvoker (and avoid ClearInternal) in WebRtcVideoSendStream (WVSS) * The reason it was there is due to a "design leak" from VideoSourceSinkController/VideoStreamEncoder where the former uses locks in all methods and is unaware of a threading model. That design affected downstream objects, pushed the need for an async hop into WVSS and added a lock. A suggestion was made to address this in a follow-up change, here: https://webrtc-review.googlesource.com/c/src/+/165684 * All methods in VideoSourceSinkController are now called on a known and checked sequence and this CL removes the lock. This also makes checking state consistent (i.e. calling a getter twice in a row on the same sequence, will always return the same value, avoiding race with other threads). * Handling of reporting state changes from the encoder queue to the VSSC, is done by VideoStreamEncoder. * VideoSendStreamImpl is still instantiated on the incorrect thread [1] but has two initialization steps [2]. The second one already runs on the right thread. Addressing that TODO [1] is something we should do but it has side effects to consider. For the purposes of this CL the steps relating to the encoder (setting the sink pointer) have been moved to [2]. [1] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;l=94 [2] https://source.chromium.org/chromium/chromium/src/+/master:third_party/webrtc/video/video_send_stream.cc;drc=f4a9991cce74a37d006438ec0e366313ed33162e;l=115 Bug: webrtc:11222, webrtc:11908 Change-Id: Ie46d46e3a52bbe225951b4bd580ecb8cc9cad873 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/184508 Reviewed-by: Henrik Boström <hbos@webrtc.org> Commit-Queue: Tommi <tommi@webrtc.org> Cr-Commit-Position: refs/heads/master@{#32150}
2020-09-21 14:31:23 +02:00
absl::optional<size_t> pixels_per_frame_upper_limit_
RTC_GUARDED_BY(&sequence_checker_);
absl::optional<double> frame_rate_upper_limit_
RTC_GUARDED_BY(&sequence_checker_);
bool rotation_applied_ RTC_GUARDED_BY(&sequence_checker_) = false;
int resolution_alignment_ RTC_GUARDED_BY(&sequence_checker_) = 1;
Communicate encoder resolutions via rtc::VideoSinkWants. This will allow us to optimize the internal buffers of webrtc::VideoFrame for the resolution(s) that we actually want to encode. Bug: webrtc:12469, chromium:1157072 Change-Id: If378b52b5e35aa9a9800c1f7dfe189437ce43253 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208540 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33342}
2021-02-25 10:30:39 +01:00
std::vector<rtc::VideoSinkWants::FrameSize> resolutions_
RTC_GUARDED_BY(&sequence_checker_);
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
#endif // VIDEO_VIDEO_SOURCE_SINK_CONTROLLER_H_
Reference in New Issue Copy Permalink