webrtc_m130/video/video_stream_encoder.h

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

456 lines
19 KiB
C
Raw Normal View History

/*
* Copyright (c) 2012 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_STREAM_ENCODER_H_
#define VIDEO_VIDEO_STREAM_ENCODER_H_
#include <atomic>
Reland of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #1 id:1 of https://codereview.webrtc.org/2783183003/ ) Reason for revert: Seem to be a flaky test rather than an issue with this cl. Creating reland, will add code to reduce flakiness to that test. Original issue's description: > Revert of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #8 id:410001 of https://codereview.webrtc.org/2781433002/ ) > > Reason for revert: > This has resulted in failure of CallPerfTest.ReceivesCpuOveruseAndUnderuse test on the Win7 build bot https://build.chromium.org/p/client.webrtc.perf/builders/Win7/builds/1780 > > Original issue's description: > > Reland of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #1 id:1 of https://codereview.webrtc.org/2764133002/ ) > > > > Reason for revert: > > Found issue with test case, will add fix to reland cl. > > > > Original issue's description: > > > Revert of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #14 id:250001 of https://codereview.webrtc.org/2716643002/ ) > > > > > > Reason for revert: > > > Breaks perf tests: > > > https://build.chromium.org/p/client.webrtc.perf/builders/Win7/builds/1679 > > > https://build.chromium.org/p/client.webrtc.perf/builders/Android32%20Tests%20%28L%20Nexus5%29/builds/2325 > > > > > > Original issue's description: > > > > Add framerate to VideoSinkWants and ability to signal on overuse > > > > > > > > In ViEEncoder, try to reduce framerate instead of resolution if the > > > > current degradation preference is maintain-resolution rather than > > > > balanced. > > > > > > > > BUG=webrtc:4172 > > > > > > > > Review-Url: https://codereview.webrtc.org/2716643002 > > > > Cr-Commit-Position: refs/heads/master@{#17327} > > > > Committed: https://chromium.googlesource.com/external/webrtc/+/72acf2526177bb4dbb5103cd6e165eb4361a5ae6 > > > > > > TBR=nisse@webrtc.org,magjed@webrtc.org,kthelgason@webrtc.org,ilnik@webrtc.org,stefan@webrtc.org,sprang@webrtc.org > > > # Skipping CQ checks because original CL landed less than 1 days ago. > > > NOPRESUBMIT=true > > > NOTREECHECKS=true > > > NOTRY=true > > > BUG=webrtc:4172 > > > > > > Review-Url: https://codereview.webrtc.org/2764133002 > > > Cr-Commit-Position: refs/heads/master@{#17331} > > > Committed: https://chromium.googlesource.com/external/webrtc/+/8b45b11144c968b4173215c76f78c710c9a2ed0b > > > > TBR=nisse@webrtc.org,magjed@webrtc.org,kthelgason@webrtc.org,ilnik@webrtc.org,stefan@webrtc.org,skvlad@webrtc.org > > # Not skipping CQ checks because original CL landed more than 1 days ago. > > BUG=webrtc:4172 > > > > Review-Url: https://codereview.webrtc.org/2781433002 > > Cr-Commit-Position: refs/heads/master@{#17474} > > Committed: https://chromium.googlesource.com/external/webrtc/+/3ea3c77e93121b1ab9d5e46641e6764f2cca0d51 > > TBR=ilnik@webrtc.org,stefan@webrtc.org,asapersson@webrtc.org,sprang@webrtc.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=webrtc:4172 > > Review-Url: https://codereview.webrtc.org/2783183003 > Cr-Commit-Position: refs/heads/master@{#17477} > Committed: https://chromium.googlesource.com/external/webrtc/+/f9ed235c9b7248694edcb46feb1f29ce7456ab59 R=ilnik@webrtc.org,stefan@webrtc.org BUG=webrtc:4172 Review-Url: https://codereview.webrtc.org/2789823002 Cr-Commit-Position: refs/heads/master@{#17498}
2017-04-02 23:53:04 -07:00
#include <map>
#include <memory>
#include <string>
#include <vector>
#include "api/adaptation/resource.h"
#include "api/field_trials_view.h"
#include "api/sequence_checker.h"
#include "api/units/data_rate.h"
#include "api/video/video_bitrate_allocator.h"
#include "api/video/video_rotation.h"
#include "api/video/video_sink_interface.h"
#include "api/video/video_stream_encoder_interface.h"
#include "api/video/video_stream_encoder_observer.h"
#include "api/video/video_stream_encoder_settings.h"
#include "api/video_codecs/video_codec.h"
#include "api/video_codecs/video_encoder.h"
#include "call/adaptation/adaptation_constraint.h"
#include "call/adaptation/resource_adaptation_processor.h"
#include "call/adaptation/resource_adaptation_processor_interface.h"
VideoStreamEncoder configuring source/sink with VideoSourceController. This is part of the work for making VideoStreamEncoder responsible for configuring its source/sink and limiting the responsibility of OveruseFrameDetectorResourceAdaptationModule to only output relevant VideoSourceRestrictions. BEFORE THIS CL Prior to this CL, OveruseFrameDetector was responsible for performing AddOrUpdateSink() on the source, which it did using its nested class VideoSourceProxy. AddOrUpdateSink() could happen for both adaptation and non-adaptation related reasons. For example: - Adaptation related: AdaptUp() or AdaptDown() happens, causing updated VideoSourceRestrictions. - Non-adaptation related: VideoStreamEncoder asks the module to reconfigure the source/sink for it, such as with SetMaxFramerateAndAlignment() or SetWantsRotationApplied(). AFTER THIS CL AddOrUpdateSink() is performed by VideoSourceController, which is owned by VideoStreamEncoder. Any reconfiguration has to go through the VideoStreamEncoder. This means that: - Non-adaptation related settings happen between VideoStreamEncoder and VideoSourceController directly (without going through the adaptation module). - Adaptation related changes can be expressed in terms of VideoSourceRestrictions. OveruseFrameDetectorResourceAdaptationModule only has to output the restrictions and not know or care about other source/sink settings. For now, VideoSourceController has to know about DegradationPreference. In a future CL, the DegradationPreference logic should move back to the adaptation module. The VideoSourceRestrictions are fully capable of expressing all possible source/sink values without the "modifier" that is the degradation preference. Bug: webrtc:11222 Change-Id: I0f058c4700ca108e2d9f212e38b61f6f728aa419 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162802 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@google.com> Cr-Commit-Position: refs/heads/master@{#30228}
2020-01-13 11:27:18 +01:00
#include "call/adaptation/video_source_restrictions.h"
[Adaptation] Introduce VideoStreamInputState and its Provider. This CL is part of the Call-Level Adaptation Processing design doc: https://docs.google.com/document/d/1ZyC26yOCknrrcYa839ZWLxD6o6Gig5A3lVTh4E41074/edit?usp=sharing The "input state" of a VideoStream, needed for adaptation and decision-making, are: source resolution and frame rate, codec type and min pixels per frame (based on encoder scaling settings). These values are modified on the encoder queue of the VideoStreamEncoder. But in order to unblock call-level adaptation processing, where adaptation and decision making happens off the encoder queue, a snapshot of the input states need to be available at point of processing: introducing the VideoStreamInputState. In this CL, the VideoStreamInputStateProvider is added to provide input state snapshots across threads based on input from VideoStreamEncoder and VideoStreamEncoderObserver. The input state's HasInputFrameSizeAndFramesPerSecond() can now be DCHECKed inside the VideoStreamAdapter in favor of having less Adaptation::Status codes. Whether input is "sufficient" for adaptation is now the responsibility of the Processor. (Goal: adapter is purely a Adaptation generator and apply-er.) Somewhat tangental, this CL also deletes VideoStreamEncoder-specific methods from ResourceAdaptationProcessorInterface making them an implementation detail of ResourceAdaptationProcessor. In a future CL, the "processor" will be split up into a "processor" part and a "video stream encoder resource manager" part - more on that later. Bug: webrtc:11172 Change-Id: Id9b158f569db0140b75360aaf0f7e2e28fb924f4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/172928 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@{#31098}
2020-04-17 12:10:59 +02:00
#include "call/adaptation/video_stream_input_state_provider.h"
Reland "Refactor and remove media_optimization::MediaOptimization." This reverts commit 6613f8e98ab3654ade7e8f5352d8d6711b157499. Reason for revert: This change seemed innocent after all, so undoing speculative revert. Original change's description: > Revert "Refactor and remove media_optimization::MediaOptimization." > > This reverts commit 07276e4f89a93b1479d7aeefa53b4fc32daf001b. > > Reason for revert: Speculative revert due to downstream crashes. > > Original change's description: > > Refactor and remove media_optimization::MediaOptimization. > > > > This CL removes MediaOptmization and folds some of its functionality > > into VideoStreamEncoder. > > > > The FPS tracking is now handled by a RateStatistics instance. Frame > > dropping is still handled by FrameDropper. Both of these now live > > directly in VideoStreamEncoder. > > There is no intended change in behavior from this CL, but due to a new > > way of measuring frame rate, some minor perf changes can be expected. > > > > A small change in behavior is that OnBitrateUpdated is now called > > directly rather than on the next frame. Since both encoding frame and > > setting rate allocations happen on the encoder worker thread, there's > > really no reason to cache bitrates and wait until the next frame. > > An edge case though is that if a new bitrate is set before the first > > frame, we must remember that bitrate and then apply it after the video > > bitrate allocator has been first created. > > > > In addition to existing unit tests, manual tests have been used to > > confirm that frame dropping works as expected with misbehaving encoders. > > > > Bug: webrtc:10164 > > Change-Id: I7ee9c8d3c4f2bcf23c8c420310b05a4d35d94744 > > Reviewed-on: https://webrtc-review.googlesource.com/c/115620 > > Commit-Queue: Erik Språng <sprang@webrtc.org> > > Reviewed-by: Niels Moller <nisse@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#26147} > > TBR=nisse@webrtc.org,sprang@webrtc.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: webrtc:10164 > Change-Id: Ie0dae19dd012bc09e793c9661a45823fd760c20c > Reviewed-on: https://webrtc-review.googlesource.com/c/116780 > Reviewed-by: Niels Moller <nisse@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Commit-Queue: Niels Moller <nisse@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#26191} TBR=nisse@webrtc.org,sprang@webrtc.org Change-Id: Ieda1fad301de002460bb0bf5a75267ea065176a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:10164 Reviewed-on: https://webrtc-review.googlesource.com/c/116960 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Niels Moller <nisse@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26213}
2019-01-11 11:11:10 +01:00
#include "modules/video_coding/utility/frame_dropper.h"
Reland "Parse encoded frame QP if not provided by encoder" This reverts commit 727d2afc4330efebc904e0e4f366e885d7b08787. Reason for revert: Use thread-safe wrapper for H264 parser. Original change's description: > Revert "Parse encoded frame QP if not provided by encoder" > > This reverts commit 8639673f0c098efc294a7593fa3bd98e28ab7508. > > Reason for revert: linux_tsan fails https://ci.chromium.org/ui/p/webrtc/builders/ci/Linux%20Tsan%20v2/25329/overview > > Original change's description: > > Parse encoded frame QP if not provided by encoder > > > > Bug: webrtc:12542 > > Change-Id: Ic70b46e226f158db7a478a9f20e1f940804febba > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/210966 > > Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> > > Reviewed-by: Åsa Persson <asapersson@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#33434} > > TBR=asapersson@webrtc.org,ssilkin@webrtc.org > > Change-Id: Ie251d8f70f8e87fd86b63730aefd2ef3f941e4bb > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: webrtc:12542 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211355 > Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> > Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#33441} # Not skipping CQ checks because this is a reland. Bug: webrtc:12542 Change-Id: Ib7601fd6f2f26bceddbea2b4ba54d67a281f3a59 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211660 Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> Reviewed-by: Åsa Persson <asapersson@webrtc.org> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33458}
2021-03-15 10:12:57 +01:00
#include "modules/video_coding/utility/qp_parser.h"
#include "rtc_base/experiments/rate_control_settings.h"
#include "rtc_base/numerics/exp_filter.h"
#include "rtc_base/race_checker.h"
Reland "Refactor and remove media_optimization::MediaOptimization." This reverts commit 6613f8e98ab3654ade7e8f5352d8d6711b157499. Reason for revert: This change seemed innocent after all, so undoing speculative revert. Original change's description: > Revert "Refactor and remove media_optimization::MediaOptimization." > > This reverts commit 07276e4f89a93b1479d7aeefa53b4fc32daf001b. > > Reason for revert: Speculative revert due to downstream crashes. > > Original change's description: > > Refactor and remove media_optimization::MediaOptimization. > > > > This CL removes MediaOptmization and folds some of its functionality > > into VideoStreamEncoder. > > > > The FPS tracking is now handled by a RateStatistics instance. Frame > > dropping is still handled by FrameDropper. Both of these now live > > directly in VideoStreamEncoder. > > There is no intended change in behavior from this CL, but due to a new > > way of measuring frame rate, some minor perf changes can be expected. > > > > A small change in behavior is that OnBitrateUpdated is now called > > directly rather than on the next frame. Since both encoding frame and > > setting rate allocations happen on the encoder worker thread, there's > > really no reason to cache bitrates and wait until the next frame. > > An edge case though is that if a new bitrate is set before the first > > frame, we must remember that bitrate and then apply it after the video > > bitrate allocator has been first created. > > > > In addition to existing unit tests, manual tests have been used to > > confirm that frame dropping works as expected with misbehaving encoders. > > > > Bug: webrtc:10164 > > Change-Id: I7ee9c8d3c4f2bcf23c8c420310b05a4d35d94744 > > Reviewed-on: https://webrtc-review.googlesource.com/c/115620 > > Commit-Queue: Erik Språng <sprang@webrtc.org> > > Reviewed-by: Niels Moller <nisse@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#26147} > > TBR=nisse@webrtc.org,sprang@webrtc.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: webrtc:10164 > Change-Id: Ie0dae19dd012bc09e793c9661a45823fd760c20c > Reviewed-on: https://webrtc-review.googlesource.com/c/116780 > Reviewed-by: Niels Moller <nisse@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Commit-Queue: Niels Moller <nisse@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#26191} TBR=nisse@webrtc.org,sprang@webrtc.org Change-Id: Ieda1fad301de002460bb0bf5a75267ea065176a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:10164 Reviewed-on: https://webrtc-review.googlesource.com/c/116960 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Niels Moller <nisse@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26213}
2019-01-11 11:11:10 +01:00
#include "rtc_base/rate_statistics.h"
#include "rtc_base/task_queue.h"
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
#include "rtc_base/task_utils/pending_task_safety_flag.h"
#include "rtc_base/thread_annotations.h"
#include "system_wrappers/include/clock.h"
#include "video/adaptation/video_stream_encoder_resource_manager.h"
#include "video/encoder_bitrate_adjuster.h"
#include "video/frame_cadence_adapter.h"
#include "video/frame_encode_metadata_writer.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 "video/video_source_sink_controller.h"
namespace webrtc {
// VideoStreamEncoder represent a video encoder that accepts raw video frames as
// input and produces an encoded bit stream.
// Usage:
// Instantiate.
// Call SetSink.
// Call SetSource.
// Call ConfigureEncoder with the codec settings.
// Call Stop() when done.
class VideoStreamEncoder : public VideoStreamEncoderInterface,
Introduce ResourceAdaptationModuleListener and VideoSourceRestrictions. The VideoSourceRestrictions describe the maximum pixels per frame and max frame rate of a video source. This CL makes the ResourceAdaptationModuleInterface responsible for the reconfiguration of video sources. The VideoSourceRestrictions is the output of an adaptation module, and the ResourceAdaptationModuleListener handles the callback for when the source restrictions change. The OveruseFrameDetectorResourceAdaptationModule is updated to output its changes using these interfaces, and VideoStreamEncoder - now a listener - is made responsible for triggering the reconfiguring the video source. Performing the reconfiguration still requires interacting with the VideoSourceProxy - it is still partially responsible for keeping track of rtc::VideoSinkWants settings and performing AddOrUpdateSink(). For now this may look a bit weird: the VideoSourceProxy tells the VideoStreamEncoder about the new restrictions, and then the VideoStreamEncoder tells the VideoSourceProxy to apply these restrictions on the source/sink. This exercises the listener though, and unblocks the next CL. The next CL should move all "configuring the source" logic to the VideoStreamEncoder instead, so that the only information that is tracked by OveruseFrameDetectorResourceAdaptationModule is what it actually outputs to the listener. See the next CL (https://webrtc-review.googlesource.com/c/src/+/162802) where a VideoSourceController is introduced, to be owned by the VideoStreamEncoder rather than the adaptation module. Bug: webrtc:11222 Change-Id: I450ce74f51d96c4b98009a06134db671893d8fdc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162522 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@google.com> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/master@{#30227}
2020-01-10 15:44:01 +01:00
private EncodedImageCallback,
public VideoSourceRestrictionsListener {
public:
// TODO(bugs.webrtc.org/12000): Reporting of VideoBitrateAllocation is being
// deprecated. Instead VideoLayersAllocation should be reported.
enum class BitrateAllocationCallbackType {
kVideoBitrateAllocation,
kVideoBitrateAllocationWhenScreenSharing,
kVideoLayersAllocation
};
VideoStreamEncoder(
Clock* clock,
uint32_t number_of_cores,
VideoStreamEncoderObserver* encoder_stats_observer,
const VideoStreamEncoderSettings& settings,
std::unique_ptr<OveruseFrameDetector> overuse_detector,
std::unique_ptr<FrameCadenceAdapterInterface> frame_cadence_adapter,
std::unique_ptr<webrtc::TaskQueueBase, webrtc::TaskQueueDeleter>
encoder_queue,
BitrateAllocationCallbackType allocation_cb_type,
const FieldTrialsView& field_trials);
~VideoStreamEncoder() override;
Reland "Remove RTC_DISALLOW_COPY_AND_ASSIGN usages completely" This reverts commit 3f87250a4f0e6c69002fbcdfb995b0dfcd7bf710. Reason for revert: Downstream is fixed Original change's description: > Revert "Remove RTC_DISALLOW_COPY_AND_ASSIGN usages completely" > > This reverts commit 5f0eb93d2a44cec2102fc8c3757d5bb814bd145f. > > Reason for revert: Breaks downstream project. I'm going to fix that one and create a reland of this CL after. > > Original change's description: > > Remove RTC_DISALLOW_COPY_AND_ASSIGN usages completely > > > > Bug: webrtc:13555, webrtc:13082 > > Change-Id: Iff2cda6f516739419e97e975e03f77a98f74be03 > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249260 > > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > > Reviewed-by: Artem Titov <titovartem@webrtc.org> > > Commit-Queue: (Daniel.L) Byoungchan Lee <daniel.l@hpcnt.com> > > Cr-Commit-Position: refs/heads/main@{#35805} > > TBR=hta@webrtc.org,titovartem@webrtc.org,daniel.l@hpcnt.com,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com > > Change-Id: I33d497f1132adfe6d151023195a388d9b7d548f9 > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: webrtc:13555, webrtc:13082 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249364 > Reviewed-by: Artem Titov <titovartem@webrtc.org> > Owners-Override: Artem Titov <titovartem@webrtc.org> > Reviewed-by: Andrey Logvin <landrey@webrtc.org> > Reviewed-by: Björn Terelius <terelius@webrtc.org> > Commit-Queue: Artem Titov <titovartem@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#35807} # Not skipping CQ checks because this is a reland. Bug: webrtc:13555, webrtc:13082 Change-Id: I7ef1ef3b6e3c41b1a96014aa75f003c0fcf33949 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/249365 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Artem Titov <titovartem@webrtc.org> Cr-Commit-Position: refs/heads/main@{#35814}
2022-01-26 15:01:10 +00:00
VideoStreamEncoder(const VideoStreamEncoder&) = delete;
VideoStreamEncoder& operator=(const VideoStreamEncoder&) = delete;
void AddAdaptationResource(rtc::scoped_refptr<Resource> resource) override;
std::vector<rtc::scoped_refptr<Resource>> GetAdaptationResources() override;
void SetSource(rtc::VideoSourceInterface<VideoFrame>* source,
const DegradationPreference& degradation_preference) override;
void SetSink(EncoderSink* sink, bool rotation_applied) override;
// TODO(perkj): Can we remove VideoCodec.startBitrate ?
void SetStartBitrate(int start_bitrate_bps) override;
void SetFecControllerOverride(
FecControllerOverride* fec_controller_override) override;
void ConfigureEncoder(VideoEncoderConfig config,
size_t max_data_payload_length) override;
// Permanently stop encoding. After this method has returned, it is
// guaranteed that no encoded frames will be delivered to the sink.
void Stop() override;
void SendKeyFrame() override;
void OnLossNotification(
const VideoEncoder::LossNotification& loss_notification) override;
void OnBitrateUpdated(DataRate target_bitrate,
DataRate stable_target_bitrate,
DataRate target_headroom,
uint8_t fraction_lost,
int64_t round_trip_time_ms,
double cwnd_reduce_ratio) override;
DataRate UpdateTargetBitrate(DataRate target_bitrate,
double cwnd_reduce_ratio);
protected:
// Used for testing. For example the `ScalingObserverInterface` methods must
// be called on `encoder_queue_`.
rtc::TaskQueue* encoder_queue() { return &encoder_queue_; }
Introduce ResourceAdaptationModuleListener and VideoSourceRestrictions. The VideoSourceRestrictions describe the maximum pixels per frame and max frame rate of a video source. This CL makes the ResourceAdaptationModuleInterface responsible for the reconfiguration of video sources. The VideoSourceRestrictions is the output of an adaptation module, and the ResourceAdaptationModuleListener handles the callback for when the source restrictions change. The OveruseFrameDetectorResourceAdaptationModule is updated to output its changes using these interfaces, and VideoStreamEncoder - now a listener - is made responsible for triggering the reconfiguring the video source. Performing the reconfiguration still requires interacting with the VideoSourceProxy - it is still partially responsible for keeping track of rtc::VideoSinkWants settings and performing AddOrUpdateSink(). For now this may look a bit weird: the VideoSourceProxy tells the VideoStreamEncoder about the new restrictions, and then the VideoStreamEncoder tells the VideoSourceProxy to apply these restrictions on the source/sink. This exercises the listener though, and unblocks the next CL. The next CL should move all "configuring the source" logic to the VideoStreamEncoder instead, so that the only information that is tracked by OveruseFrameDetectorResourceAdaptationModule is what it actually outputs to the listener. See the next CL (https://webrtc-review.googlesource.com/c/src/+/162802) where a VideoSourceController is introduced, to be owned by the VideoStreamEncoder rather than the adaptation module. Bug: webrtc:11222 Change-Id: I450ce74f51d96c4b98009a06134db671893d8fdc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162522 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@google.com> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/master@{#30227}
2020-01-10 15:44:01 +01:00
void OnVideoSourceRestrictionsUpdated(
VideoSourceRestrictions restrictions,
const VideoAdaptationCounters& adaptation_counters,
rtc::scoped_refptr<Resource> reason,
const VideoSourceRestrictions& unfiltered_restrictions) override;
Introduce ResourceAdaptationModuleListener and VideoSourceRestrictions. The VideoSourceRestrictions describe the maximum pixels per frame and max frame rate of a video source. This CL makes the ResourceAdaptationModuleInterface responsible for the reconfiguration of video sources. The VideoSourceRestrictions is the output of an adaptation module, and the ResourceAdaptationModuleListener handles the callback for when the source restrictions change. The OveruseFrameDetectorResourceAdaptationModule is updated to output its changes using these interfaces, and VideoStreamEncoder - now a listener - is made responsible for triggering the reconfiguring the video source. Performing the reconfiguration still requires interacting with the VideoSourceProxy - it is still partially responsible for keeping track of rtc::VideoSinkWants settings and performing AddOrUpdateSink(). For now this may look a bit weird: the VideoSourceProxy tells the VideoStreamEncoder about the new restrictions, and then the VideoStreamEncoder tells the VideoSourceProxy to apply these restrictions on the source/sink. This exercises the listener though, and unblocks the next CL. The next CL should move all "configuring the source" logic to the VideoStreamEncoder instead, so that the only information that is tracked by OveruseFrameDetectorResourceAdaptationModule is what it actually outputs to the listener. See the next CL (https://webrtc-review.googlesource.com/c/src/+/162802) where a VideoSourceController is introduced, to be owned by the VideoStreamEncoder rather than the adaptation module. Bug: webrtc:11222 Change-Id: I450ce74f51d96c4b98009a06134db671893d8fdc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162522 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Evan Shrubsole <eshr@google.com> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/master@{#30227}
2020-01-10 15:44:01 +01:00
// Used for injected test resources.
// TODO(eshr): Move all adaptation tests out of VideoStreamEncoder tests.
[Adaptation] Make Resources reference counted and add more DCHECKs. In a future CL, adaptation processing and stream encoder resource management will happen on different task queues. When this is the case, asynchronous tasks will be posted in both directions and some resources will have internal states used on multiple threads. This CL makes the Resource class reference counted in order to support posting tasks to a different threads without risk of use-after-free when a posted task is executed with a delay. This is preferred over WeakPtr strategies because WeakPtrs are single-threaded and preferred over raw pointer usage because the reference counted approach enables more compile-time and run-time assurance. This is also "future proof"; when resources can be injected through public APIs, ownership needs to be shared between libwebrtc and the application (e.g. Chrome). To reduce the risk of making mistakes in the future CL, sequence checkers and task queue DCHECKs are added as well as other DCHECKs to make sure things have been cleaned up before destruction, e.g: - Processor gets a sequence checker. It is entirely single-threaded. - Processor must not have any attached listeners or resources on destruction. - Resources must not have any listeners on destruction. - The Manager, EncodeUsageResource and QualityScalerResource DCHECKs they are running on the encoder queue. - TODOs are added illustrating where we want to add PostTasks in the future CL. Lastly, upon VideoStreamEncoder::Stop() we delete the ResourceAdaptationProcessor. Because the Processor is already used in posted tasks, some if statements are added to ensure the Processor is not used after destruction. Bug: webrtc:11542, webrtc:11520 Change-Id: Ibaa8a61d86d87a71f477d1075a117c28d9d2d285 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174760 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@{#31217}
2020-05-11 16:29:22 +02:00
void InjectAdaptationResource(rtc::scoped_refptr<Resource> resource,
VideoAdaptationReason reason);
void InjectAdaptationConstraint(AdaptationConstraint* adaptation_constraint);
void AddRestrictionsListenerForTesting(
VideoSourceRestrictionsListener* restrictions_listener);
void RemoveRestrictionsListenerForTesting(
VideoSourceRestrictionsListener* restrictions_listener);
[Adaptation] Move adaptation logic to a separate task queue. This CL unblocks future Call-Level Mitigation strategies by moving the ResourceAdaptationProcessor to a separate task queue. This signifies a major milestone in the new resource adaptation architecture because with this CL the threading model is in place and moving the Processor to the Call and increasing its responsibilities is made possible. In this CL, we still have one Processor per VideoStreamEncoder and the VideoStreamEncoder is responsible for the creation and the destruction of its Processor and that Processor's task queue. But the PostTasks are in place and the decision-making is executed on a separate queue. This CL: - Moves ResourceAdaptationProcessor to an adaptation task queue. It continues to be entirely single-threaded, but now operates on a separate task queue. - Makes Resources thread-safe: Interaction with the Processor, i.e. OnResourceUsageStateMeasured() and IsAdaptationUpAllowed(), happens on the adaptation task queue. State updates are pushed from the encoder task queue with PostTasks. - QualityScalerResource operates on both task queues; the QP usage callbacks are invoked asynchronously. - The VideoStreamEncoderResourceManager operates on the encoder task queue with the following exceptions: 1) Its resources are accessible on any thread (using a mutex). This is OK because resources are reference counted and thread safe. This aids adding and removing resources to the Processor on the adaptation task queue. 2) |active_counts_| is moved to the adaptation task queue. This makes it possible for PreventAdaptUpDueToActiveCounts to run IsAdaptationUpAllowed() on the adaptation task queue. A side-effect of this is that some stats reporting now happen on the adaptation task queue, but that is OK because VideoStreamEncoderObserver is thread-safe. The Manager is updated to take the new threading model into account: - OnFrameDroppedDueToSize() posts to the adaptation task queue to invoke the Processor. - OnVideoSourceRestrictionsUpdated(), now invoked on the adaptation task queue, updates |active_counts_| synchronously but posts to the encoder task queue to update video source restrictions (which it only uses to calculate target frame rate). - MaybePerformQualityRampupExperiment() posts to the adaptation task queue to maybe reset video source restrictions on the Processor. |quality_rampup_done_| is made std::atomic. Bug: webrtc:11542, webrtc:11520 Change-Id: I1cfd76e0cd42f006a6d2527f5aa2aeb5266ba6d6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174441 Reviewed-by: Evan Shrubsole <eshr@google.com> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/master@{#31231}
2020-05-12 18:49:07 +02:00
private:
class CadenceCallback : public FrameCadenceAdapterInterface::Callback {
public:
explicit CadenceCallback(VideoStreamEncoder& video_stream_encoder)
: video_stream_encoder_(video_stream_encoder) {}
// FrameCadenceAdapterInterface::Callback overrides.
void OnFrame(Timestamp post_time,
int frames_scheduled_for_processing,
const VideoFrame& frame) override {
video_stream_encoder_.OnFrame(post_time, frames_scheduled_for_processing,
frame);
}
void OnDiscardedFrame() override {
video_stream_encoder_.OnDiscardedFrame();
}
void RequestRefreshFrame() override {
video_stream_encoder_.RequestRefreshFrame();
}
private:
VideoStreamEncoder& video_stream_encoder_;
};
class VideoFrameInfo {
public:
VideoFrameInfo(int width, int height, bool is_texture)
: width(width), height(height), is_texture(is_texture) {}
int width;
int height;
bool is_texture;
int pixel_count() const { return width * height; }
};
struct EncoderRateSettings {
EncoderRateSettings();
EncoderRateSettings(const VideoBitrateAllocation& bitrate,
double framerate_fps,
DataRate bandwidth_allocation,
DataRate encoder_target,
DataRate stable_encoder_target);
bool operator==(const EncoderRateSettings& rhs) const;
bool operator!=(const EncoderRateSettings& rhs) const;
VideoEncoder::RateControlParameters rate_control;
// This is the scalar target bitrate before the VideoBitrateAllocator, i.e.
// the `target_bitrate` argument of the OnBitrateUpdated() method. This is
// needed because the bitrate allocator may truncate the total bitrate and a
// later call to the same allocator instance, e.g.
// |using last_encoder_rate_setings_->bitrate.get_sum_bps()|, may trick it
// into thinking the available bitrate has decreased since the last call.
DataRate encoder_target;
DataRate stable_encoder_target;
};
class DegradationPreferenceManager;
void ReconfigureEncoder() RTC_RUN_ON(&encoder_queue_);
[Adaptation] Introduce VideoStreamInputState and its Provider. This CL is part of the Call-Level Adaptation Processing design doc: https://docs.google.com/document/d/1ZyC26yOCknrrcYa839ZWLxD6o6Gig5A3lVTh4E41074/edit?usp=sharing The "input state" of a VideoStream, needed for adaptation and decision-making, are: source resolution and frame rate, codec type and min pixels per frame (based on encoder scaling settings). These values are modified on the encoder queue of the VideoStreamEncoder. But in order to unblock call-level adaptation processing, where adaptation and decision making happens off the encoder queue, a snapshot of the input states need to be available at point of processing: introducing the VideoStreamInputState. In this CL, the VideoStreamInputStateProvider is added to provide input state snapshots across threads based on input from VideoStreamEncoder and VideoStreamEncoderObserver. The input state's HasInputFrameSizeAndFramesPerSecond() can now be DCHECKed inside the VideoStreamAdapter in favor of having less Adaptation::Status codes. Whether input is "sufficient" for adaptation is now the responsibility of the Processor. (Goal: adapter is purely a Adaptation generator and apply-er.) Somewhat tangental, this CL also deletes VideoStreamEncoder-specific methods from ResourceAdaptationProcessorInterface making them an implementation detail of ResourceAdaptationProcessor. In a future CL, the "processor" will be split up into a "processor" part and a "video stream encoder resource manager" part - more on that later. Bug: webrtc:11172 Change-Id: Id9b158f569db0140b75360aaf0f7e2e28fb924f4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/172928 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@{#31098}
2020-04-17 12:10:59 +02:00
void OnEncoderSettingsChanged() RTC_RUN_ON(&encoder_queue_);
void OnFrame(Timestamp post_time,
int frames_scheduled_for_processing,
const VideoFrame& video_frame);
void OnDiscardedFrame();
void RequestRefreshFrame();
void MaybeEncodeVideoFrame(const VideoFrame& frame,
int64_t time_when_posted_in_ms);
void EncodeVideoFrame(const VideoFrame& frame,
int64_t time_when_posted_in_ms);
// Indicates whether frame should be dropped because the pixel count is too
// large for the current bitrate configuration.
bool DropDueToSize(uint32_t pixel_count) const RTC_RUN_ON(&encoder_queue_);
// Implements EncodedImageCallback.
EncodedImageCallback::Result OnEncodedImage(
const EncodedImage& encoded_image,
const CodecSpecificInfo* codec_specific_info) override;
void OnDroppedFrame(EncodedImageCallback::DropReason reason) override;
bool EncoderPaused() const;
void TraceFrameDropStart();
void TraceFrameDropEnd();
// Returns a copy of `rate_settings` with the `bitrate` field updated using
// the current VideoBitrateAllocator.
EncoderRateSettings UpdateBitrateAllocation(
const EncoderRateSettings& rate_settings) RTC_RUN_ON(&encoder_queue_);
Reland "Refactor and remove media_optimization::MediaOptimization." This reverts commit 6613f8e98ab3654ade7e8f5352d8d6711b157499. Reason for revert: This change seemed innocent after all, so undoing speculative revert. Original change's description: > Revert "Refactor and remove media_optimization::MediaOptimization." > > This reverts commit 07276e4f89a93b1479d7aeefa53b4fc32daf001b. > > Reason for revert: Speculative revert due to downstream crashes. > > Original change's description: > > Refactor and remove media_optimization::MediaOptimization. > > > > This CL removes MediaOptmization and folds some of its functionality > > into VideoStreamEncoder. > > > > The FPS tracking is now handled by a RateStatistics instance. Frame > > dropping is still handled by FrameDropper. Both of these now live > > directly in VideoStreamEncoder. > > There is no intended change in behavior from this CL, but due to a new > > way of measuring frame rate, some minor perf changes can be expected. > > > > A small change in behavior is that OnBitrateUpdated is now called > > directly rather than on the next frame. Since both encoding frame and > > setting rate allocations happen on the encoder worker thread, there's > > really no reason to cache bitrates and wait until the next frame. > > An edge case though is that if a new bitrate is set before the first > > frame, we must remember that bitrate and then apply it after the video > > bitrate allocator has been first created. > > > > In addition to existing unit tests, manual tests have been used to > > confirm that frame dropping works as expected with misbehaving encoders. > > > > Bug: webrtc:10164 > > Change-Id: I7ee9c8d3c4f2bcf23c8c420310b05a4d35d94744 > > Reviewed-on: https://webrtc-review.googlesource.com/c/115620 > > Commit-Queue: Erik Språng <sprang@webrtc.org> > > Reviewed-by: Niels Moller <nisse@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#26147} > > TBR=nisse@webrtc.org,sprang@webrtc.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: webrtc:10164 > Change-Id: Ie0dae19dd012bc09e793c9661a45823fd760c20c > Reviewed-on: https://webrtc-review.googlesource.com/c/116780 > Reviewed-by: Niels Moller <nisse@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Commit-Queue: Niels Moller <nisse@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#26191} TBR=nisse@webrtc.org,sprang@webrtc.org Change-Id: Ieda1fad301de002460bb0bf5a75267ea065176a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:10164 Reviewed-on: https://webrtc-review.googlesource.com/c/116960 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Niels Moller <nisse@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26213}
2019-01-11 11:11:10 +01:00
uint32_t GetInputFramerateFps() RTC_RUN_ON(&encoder_queue_);
void SetEncoderRates(const EncoderRateSettings& rate_settings)
RTC_RUN_ON(&encoder_queue_);
Reland "Refactor and remove media_optimization::MediaOptimization." This reverts commit 6613f8e98ab3654ade7e8f5352d8d6711b157499. Reason for revert: This change seemed innocent after all, so undoing speculative revert. Original change's description: > Revert "Refactor and remove media_optimization::MediaOptimization." > > This reverts commit 07276e4f89a93b1479d7aeefa53b4fc32daf001b. > > Reason for revert: Speculative revert due to downstream crashes. > > Original change's description: > > Refactor and remove media_optimization::MediaOptimization. > > > > This CL removes MediaOptmization and folds some of its functionality > > into VideoStreamEncoder. > > > > The FPS tracking is now handled by a RateStatistics instance. Frame > > dropping is still handled by FrameDropper. Both of these now live > > directly in VideoStreamEncoder. > > There is no intended change in behavior from this CL, but due to a new > > way of measuring frame rate, some minor perf changes can be expected. > > > > A small change in behavior is that OnBitrateUpdated is now called > > directly rather than on the next frame. Since both encoding frame and > > setting rate allocations happen on the encoder worker thread, there's > > really no reason to cache bitrates and wait until the next frame. > > An edge case though is that if a new bitrate is set before the first > > frame, we must remember that bitrate and then apply it after the video > > bitrate allocator has been first created. > > > > In addition to existing unit tests, manual tests have been used to > > confirm that frame dropping works as expected with misbehaving encoders. > > > > Bug: webrtc:10164 > > Change-Id: I7ee9c8d3c4f2bcf23c8c420310b05a4d35d94744 > > Reviewed-on: https://webrtc-review.googlesource.com/c/115620 > > Commit-Queue: Erik Språng <sprang@webrtc.org> > > Reviewed-by: Niels Moller <nisse@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#26147} > > TBR=nisse@webrtc.org,sprang@webrtc.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: webrtc:10164 > Change-Id: Ie0dae19dd012bc09e793c9661a45823fd760c20c > Reviewed-on: https://webrtc-review.googlesource.com/c/116780 > Reviewed-by: Niels Moller <nisse@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Commit-Queue: Niels Moller <nisse@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#26191} TBR=nisse@webrtc.org,sprang@webrtc.org Change-Id: Ieda1fad301de002460bb0bf5a75267ea065176a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:10164 Reviewed-on: https://webrtc-review.googlesource.com/c/116960 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Niels Moller <nisse@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26213}
2019-01-11 11:11:10 +01:00
void RunPostEncode(const EncodedImage& encoded_image,
Reland "Refactor and remove media_optimization::MediaOptimization." This reverts commit 6613f8e98ab3654ade7e8f5352d8d6711b157499. Reason for revert: This change seemed innocent after all, so undoing speculative revert. Original change's description: > Revert "Refactor and remove media_optimization::MediaOptimization." > > This reverts commit 07276e4f89a93b1479d7aeefa53b4fc32daf001b. > > Reason for revert: Speculative revert due to downstream crashes. > > Original change's description: > > Refactor and remove media_optimization::MediaOptimization. > > > > This CL removes MediaOptmization and folds some of its functionality > > into VideoStreamEncoder. > > > > The FPS tracking is now handled by a RateStatistics instance. Frame > > dropping is still handled by FrameDropper. Both of these now live > > directly in VideoStreamEncoder. > > There is no intended change in behavior from this CL, but due to a new > > way of measuring frame rate, some minor perf changes can be expected. > > > > A small change in behavior is that OnBitrateUpdated is now called > > directly rather than on the next frame. Since both encoding frame and > > setting rate allocations happen on the encoder worker thread, there's > > really no reason to cache bitrates and wait until the next frame. > > An edge case though is that if a new bitrate is set before the first > > frame, we must remember that bitrate and then apply it after the video > > bitrate allocator has been first created. > > > > In addition to existing unit tests, manual tests have been used to > > confirm that frame dropping works as expected with misbehaving encoders. > > > > Bug: webrtc:10164 > > Change-Id: I7ee9c8d3c4f2bcf23c8c420310b05a4d35d94744 > > Reviewed-on: https://webrtc-review.googlesource.com/c/115620 > > Commit-Queue: Erik Språng <sprang@webrtc.org> > > Reviewed-by: Niels Moller <nisse@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#26147} > > TBR=nisse@webrtc.org,sprang@webrtc.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: webrtc:10164 > Change-Id: Ie0dae19dd012bc09e793c9661a45823fd760c20c > Reviewed-on: https://webrtc-review.googlesource.com/c/116780 > Reviewed-by: Niels Moller <nisse@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Commit-Queue: Niels Moller <nisse@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#26191} TBR=nisse@webrtc.org,sprang@webrtc.org Change-Id: Ieda1fad301de002460bb0bf5a75267ea065176a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:10164 Reviewed-on: https://webrtc-review.googlesource.com/c/116960 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Niels Moller <nisse@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26213}
2019-01-11 11:11:10 +01:00
int64_t time_sent_us,
int temporal_index,
DataSize frame_size);
void ReleaseEncoder() RTC_RUN_ON(&encoder_queue_);
// After calling this function `resource_adaptation_processor_` will be null.
void ShutdownResourceAdaptationQueue();
Reland of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #1 id:1 of https://codereview.webrtc.org/2783183003/ ) Reason for revert: Seem to be a flaky test rather than an issue with this cl. Creating reland, will add code to reduce flakiness to that test. Original issue's description: > Revert of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #8 id:410001 of https://codereview.webrtc.org/2781433002/ ) > > Reason for revert: > This has resulted in failure of CallPerfTest.ReceivesCpuOveruseAndUnderuse test on the Win7 build bot https://build.chromium.org/p/client.webrtc.perf/builders/Win7/builds/1780 > > Original issue's description: > > Reland of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #1 id:1 of https://codereview.webrtc.org/2764133002/ ) > > > > Reason for revert: > > Found issue with test case, will add fix to reland cl. > > > > Original issue's description: > > > Revert of Add framerate to VideoSinkWants and ability to signal on overuse (patchset #14 id:250001 of https://codereview.webrtc.org/2716643002/ ) > > > > > > Reason for revert: > > > Breaks perf tests: > > > https://build.chromium.org/p/client.webrtc.perf/builders/Win7/builds/1679 > > > https://build.chromium.org/p/client.webrtc.perf/builders/Android32%20Tests%20%28L%20Nexus5%29/builds/2325 > > > > > > Original issue's description: > > > > Add framerate to VideoSinkWants and ability to signal on overuse > > > > > > > > In ViEEncoder, try to reduce framerate instead of resolution if the > > > > current degradation preference is maintain-resolution rather than > > > > balanced. > > > > > > > > BUG=webrtc:4172 > > > > > > > > Review-Url: https://codereview.webrtc.org/2716643002 > > > > Cr-Commit-Position: refs/heads/master@{#17327} > > > > Committed: https://chromium.googlesource.com/external/webrtc/+/72acf2526177bb4dbb5103cd6e165eb4361a5ae6 > > > > > > TBR=nisse@webrtc.org,magjed@webrtc.org,kthelgason@webrtc.org,ilnik@webrtc.org,stefan@webrtc.org,sprang@webrtc.org > > > # Skipping CQ checks because original CL landed less than 1 days ago. > > > NOPRESUBMIT=true > > > NOTREECHECKS=true > > > NOTRY=true > > > BUG=webrtc:4172 > > > > > > Review-Url: https://codereview.webrtc.org/2764133002 > > > Cr-Commit-Position: refs/heads/master@{#17331} > > > Committed: https://chromium.googlesource.com/external/webrtc/+/8b45b11144c968b4173215c76f78c710c9a2ed0b > > > > TBR=nisse@webrtc.org,magjed@webrtc.org,kthelgason@webrtc.org,ilnik@webrtc.org,stefan@webrtc.org,skvlad@webrtc.org > > # Not skipping CQ checks because original CL landed more than 1 days ago. > > BUG=webrtc:4172 > > > > Review-Url: https://codereview.webrtc.org/2781433002 > > Cr-Commit-Position: refs/heads/master@{#17474} > > Committed: https://chromium.googlesource.com/external/webrtc/+/3ea3c77e93121b1ab9d5e46641e6764f2cca0d51 > > TBR=ilnik@webrtc.org,stefan@webrtc.org,asapersson@webrtc.org,sprang@webrtc.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=webrtc:4172 > > Review-Url: https://codereview.webrtc.org/2783183003 > Cr-Commit-Position: refs/heads/master@{#17477} > Committed: https://chromium.googlesource.com/external/webrtc/+/f9ed235c9b7248694edcb46feb1f29ce7456ab59 R=ilnik@webrtc.org,stefan@webrtc.org BUG=webrtc:4172 Review-Url: https://codereview.webrtc.org/2789823002 Cr-Commit-Position: refs/heads/master@{#17498}
2017-04-02 23:53:04 -07:00
void CheckForAnimatedContent(const VideoFrame& frame,
int64_t time_when_posted_in_ms)
RTC_RUN_ON(&encoder_queue_);
void RequestEncoderSwitch() RTC_RUN_ON(&encoder_queue_);
const FieldTrialsView& field_trials_;
TaskQueueBase* const worker_queue_;
const int number_of_cores_;
EncoderSink* sink_;
const VideoStreamEncoderSettings settings_;
const BitrateAllocationCallbackType allocation_cb_type_;
const RateControlSettings rate_control_settings_;
std::unique_ptr<VideoEncoderFactory::EncoderSelectorInterface> const
encoder_selector_;
VideoStreamEncoderObserver* const encoder_stats_observer_;
// Adapter that avoids public inheritance of the cadence adapter's callback
// interface.
CadenceCallback cadence_callback_;
// Frame cadence encoder adapter. Frames enter this adapter first, and it then
// forwards them to our OnFrame method.
std::unique_ptr<FrameCadenceAdapterInterface> frame_cadence_adapter_
RTC_GUARDED_BY(&encoder_queue_) RTC_PT_GUARDED_BY(&encoder_queue_);
VideoEncoderConfig encoder_config_ RTC_GUARDED_BY(&encoder_queue_);
std::unique_ptr<VideoEncoder> encoder_ RTC_GUARDED_BY(&encoder_queue_)
RTC_PT_GUARDED_BY(&encoder_queue_);
bool encoder_initialized_;
Reland #2 of Issue 2434073003: Extract bitrate allocation ... This is yet another reland of https://codereview.webrtc.org/2434073003/ including two fixes: 1. SimulcastRateAllocator did not handle the screenshare settings properly for numSimulcastStreams = 1. Additional test case was added for that. 2. In VideoSender, when rate allocation is updated after setting a new VideoCodec config, only update the state of the EncoderParameters, but don't actually run SetRateAllocation on the encoder itself. This caused some problems upstreams. Please review only the changes after patch set 1. Original description: Extract bitrate allocation of spatial/temporal layers out of codec impl. This CL makes a number of intervowen changes: * Add BitrateAllocation struct, that contains a codec independent view of how the target bitrate is distributed over spatial and temporal layers. * Adds the BitrateAllocator interface, which takes a bitrate and frame rate and produces a BitrateAllocation. * A default (non layered) implementation is added, and SimulcastRateAllocator is extended to fully handle VP8 allocation. This includes capturing TemporalLayer instances created by the encoder. * ViEEncoder now owns both the bitrate allocator and the temporal layer factories for VP8. This allows allocation to happen fully outside of the encoder implementation. This refactoring will make it possible for ViEEncoder to signal the full picture of target bitrates to the RTCP module. BUG=webrtc:6301 R=stefan@webrtc.org Review URL: https://codereview.webrtc.org/2510583002 . Cr-Commit-Position: refs/heads/master@{#15105}
2016-11-16 16:41:30 +01:00
std::unique_ptr<VideoBitrateAllocator> rate_allocator_
RTC_GUARDED_BY(&encoder_queue_) RTC_PT_GUARDED_BY(&encoder_queue_);
int max_framerate_ RTC_GUARDED_BY(&encoder_queue_);
// Set when ConfigureEncoder has been called in order to lazy reconfigure the
// encoder on the next frame.
bool pending_encoder_reconfiguration_ RTC_GUARDED_BY(&encoder_queue_);
Revert "Replace VideoEncoderFactory::QueryVideoEncoder with VideoEncoder::GetEncoderInfo" This reverts commit cdc5eb0de179dcc866ef770ea303879c64466879. Reason for revert: Causes wrong CPU adaptation to be used for some HW codecs since GetEncoderInfo() is polled before InitEncode(). Original change's description: > Replace VideoEncoderFactory::QueryVideoEncoder with VideoEncoder::GetEncoderInfo > > Make implementation of VideoEncoderFactory::QueryVideoEncoder optional > until it is removed downstream and remove all implementations of it. > > Bug: webrtc:10065 > Change-Id: Ibb1f9612234e536651ce53f05ee048a5d172a41f > Reviewed-on: https://webrtc-review.googlesource.com/c/113065 > Commit-Queue: Mirta Dvornicic <mirtad@webrtc.org> > Reviewed-by: Sebastian Jansson <srte@webrtc.org> > Reviewed-by: Per Kjellander <perkj@webrtc.org> > Reviewed-by: Rasmus Brandt <brandtr@webrtc.org> > Reviewed-by: Sami Kalliomäki <sakal@webrtc.org> > Reviewed-by: Kári Helgason <kthelgason@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#25924} TBR=brandtr@webrtc.org,sakal@webrtc.org,kthelgason@webrtc.org,sprang@webrtc.org,srte@webrtc.org,perkj@webrtc.org,mirtad@webrtc.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: webrtc:10065 Change-Id: Idaa452e1d8c1c58cdb4ec69b88fce9042589cc3c Reviewed-on: https://webrtc-review.googlesource.com/c/113800 Reviewed-by: Mirta Dvornicic <mirtad@webrtc.org> Reviewed-by: Per Kjellander <perkj@webrtc.org> Reviewed-by: Kári Helgason <kthelgason@webrtc.org> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org> Reviewed-by: Sebastian Jansson <srte@webrtc.org> Commit-Queue: Mirta Dvornicic <mirtad@webrtc.org> Cr-Commit-Position: refs/heads/master@{#25943}
2018-12-10 09:47:34 +00:00
// Set when configuration must create a new encoder object, e.g.,
// because of a codec change.
bool pending_encoder_creation_ RTC_GUARDED_BY(&encoder_queue_);
absl::optional<VideoFrameInfo> last_frame_info_
RTC_GUARDED_BY(&encoder_queue_);
int crop_width_ RTC_GUARDED_BY(&encoder_queue_);
int crop_height_ RTC_GUARDED_BY(&encoder_queue_);
absl::optional<uint32_t> encoder_target_bitrate_bps_
RTC_GUARDED_BY(&encoder_queue_);
size_t max_data_payload_length_ RTC_GUARDED_BY(&encoder_queue_);
absl::optional<EncoderRateSettings> last_encoder_rate_settings_
RTC_GUARDED_BY(&encoder_queue_);
bool encoder_paused_and_dropped_frame_ RTC_GUARDED_BY(&encoder_queue_);
// Set to true if at least one frame was sent to encoder since last encoder
// initialization.
bool was_encode_called_since_last_initialization_
RTC_GUARDED_BY(&encoder_queue_);
bool encoder_failed_ RTC_GUARDED_BY(&encoder_queue_);
Clock* const clock_;
// Used to make sure incoming time stamp is increasing for every frame.
int64_t last_captured_timestamp_ RTC_GUARDED_BY(&encoder_queue_);
// Delta used for translating between NTP and internal timestamps.
const int64_t delta_ntp_internal_ms_ RTC_GUARDED_BY(&encoder_queue_);
int64_t last_frame_log_ms_ RTC_GUARDED_BY(&encoder_queue_);
int captured_frame_count_ RTC_GUARDED_BY(&encoder_queue_);
int dropped_frame_cwnd_pushback_count_ RTC_GUARDED_BY(&encoder_queue_);
int dropped_frame_encoder_block_count_ RTC_GUARDED_BY(&encoder_queue_);
absl::optional<VideoFrame> pending_frame_ RTC_GUARDED_BY(&encoder_queue_);
int64_t pending_frame_post_time_us_ RTC_GUARDED_BY(&encoder_queue_);
VideoFrame::UpdateRect accumulated_update_rect_
RTC_GUARDED_BY(&encoder_queue_);
bool accumulated_update_rect_is_valid_ RTC_GUARDED_BY(&encoder_queue_);
// Used for automatic content type detection.
absl::optional<VideoFrame::UpdateRect> last_update_rect_
RTC_GUARDED_BY(&encoder_queue_);
Timestamp animation_start_time_ RTC_GUARDED_BY(&encoder_queue_);
bool cap_resolution_due_to_video_content_ RTC_GUARDED_BY(&encoder_queue_);
// Used to correctly ignore changes in update_rect introduced by
// resize triggered by animation detection.
enum class ExpectResizeState {
kNoResize, // Normal operation.
kResize, // Resize was triggered by the animation detection.
kFirstFrameAfterResize // Resize observed.
} expect_resize_state_ RTC_GUARDED_BY(&encoder_queue_);
FecControllerOverride* fec_controller_override_
RTC_GUARDED_BY(&encoder_queue_);
absl::optional<int64_t> last_parameters_update_ms_
RTC_GUARDED_BY(&encoder_queue_);
absl::optional<int64_t> last_encode_info_ms_ RTC_GUARDED_BY(&encoder_queue_);
VideoEncoder::EncoderInfo encoder_info_ RTC_GUARDED_BY(&encoder_queue_);
VideoCodec send_codec_ RTC_GUARDED_BY(&encoder_queue_);
Reland "Refactor and remove media_optimization::MediaOptimization." This reverts commit 6613f8e98ab3654ade7e8f5352d8d6711b157499. Reason for revert: This change seemed innocent after all, so undoing speculative revert. Original change's description: > Revert "Refactor and remove media_optimization::MediaOptimization." > > This reverts commit 07276e4f89a93b1479d7aeefa53b4fc32daf001b. > > Reason for revert: Speculative revert due to downstream crashes. > > Original change's description: > > Refactor and remove media_optimization::MediaOptimization. > > > > This CL removes MediaOptmization and folds some of its functionality > > into VideoStreamEncoder. > > > > The FPS tracking is now handled by a RateStatistics instance. Frame > > dropping is still handled by FrameDropper. Both of these now live > > directly in VideoStreamEncoder. > > There is no intended change in behavior from this CL, but due to a new > > way of measuring frame rate, some minor perf changes can be expected. > > > > A small change in behavior is that OnBitrateUpdated is now called > > directly rather than on the next frame. Since both encoding frame and > > setting rate allocations happen on the encoder worker thread, there's > > really no reason to cache bitrates and wait until the next frame. > > An edge case though is that if a new bitrate is set before the first > > frame, we must remember that bitrate and then apply it after the video > > bitrate allocator has been first created. > > > > In addition to existing unit tests, manual tests have been used to > > confirm that frame dropping works as expected with misbehaving encoders. > > > > Bug: webrtc:10164 > > Change-Id: I7ee9c8d3c4f2bcf23c8c420310b05a4d35d94744 > > Reviewed-on: https://webrtc-review.googlesource.com/c/115620 > > Commit-Queue: Erik Språng <sprang@webrtc.org> > > Reviewed-by: Niels Moller <nisse@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#26147} > > TBR=nisse@webrtc.org,sprang@webrtc.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: webrtc:10164 > Change-Id: Ie0dae19dd012bc09e793c9661a45823fd760c20c > Reviewed-on: https://webrtc-review.googlesource.com/c/116780 > Reviewed-by: Niels Moller <nisse@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Commit-Queue: Niels Moller <nisse@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#26191} TBR=nisse@webrtc.org,sprang@webrtc.org Change-Id: Ieda1fad301de002460bb0bf5a75267ea065176a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:10164 Reviewed-on: https://webrtc-review.googlesource.com/c/116960 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Niels Moller <nisse@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26213}
2019-01-11 11:11:10 +01:00
FrameDropper frame_dropper_ RTC_GUARDED_BY(&encoder_queue_);
Reland "Refactor and remove media_optimization::MediaOptimization." This reverts commit 6613f8e98ab3654ade7e8f5352d8d6711b157499. Reason for revert: This change seemed innocent after all, so undoing speculative revert. Original change's description: > Revert "Refactor and remove media_optimization::MediaOptimization." > > This reverts commit 07276e4f89a93b1479d7aeefa53b4fc32daf001b. > > Reason for revert: Speculative revert due to downstream crashes. > > Original change's description: > > Refactor and remove media_optimization::MediaOptimization. > > > > This CL removes MediaOptmization and folds some of its functionality > > into VideoStreamEncoder. > > > > The FPS tracking is now handled by a RateStatistics instance. Frame > > dropping is still handled by FrameDropper. Both of these now live > > directly in VideoStreamEncoder. > > There is no intended change in behavior from this CL, but due to a new > > way of measuring frame rate, some minor perf changes can be expected. > > > > A small change in behavior is that OnBitrateUpdated is now called > > directly rather than on the next frame. Since both encoding frame and > > setting rate allocations happen on the encoder worker thread, there's > > really no reason to cache bitrates and wait until the next frame. > > An edge case though is that if a new bitrate is set before the first > > frame, we must remember that bitrate and then apply it after the video > > bitrate allocator has been first created. > > > > In addition to existing unit tests, manual tests have been used to > > confirm that frame dropping works as expected with misbehaving encoders. > > > > Bug: webrtc:10164 > > Change-Id: I7ee9c8d3c4f2bcf23c8c420310b05a4d35d94744 > > Reviewed-on: https://webrtc-review.googlesource.com/c/115620 > > Commit-Queue: Erik Språng <sprang@webrtc.org> > > Reviewed-by: Niels Moller <nisse@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#26147} > > TBR=nisse@webrtc.org,sprang@webrtc.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: webrtc:10164 > Change-Id: Ie0dae19dd012bc09e793c9661a45823fd760c20c > Reviewed-on: https://webrtc-review.googlesource.com/c/116780 > Reviewed-by: Niels Moller <nisse@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Commit-Queue: Niels Moller <nisse@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#26191} TBR=nisse@webrtc.org,sprang@webrtc.org Change-Id: Ieda1fad301de002460bb0bf5a75267ea065176a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:10164 Reviewed-on: https://webrtc-review.googlesource.com/c/116960 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Niels Moller <nisse@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26213}
2019-01-11 11:11:10 +01:00
// If frame dropper is not force disabled, frame dropping might still be
// disabled if VideoEncoder::GetEncoderInfo() indicates that the encoder has a
// trusted rate controller. This is determined on a per-frame basis, as the
// encoder behavior might dynamically change.
bool force_disable_frame_dropper_ RTC_GUARDED_BY(&encoder_queue_);
// Incremented on worker thread whenever `frame_dropper_` determines that a
Reland "Refactor and remove media_optimization::MediaOptimization." This reverts commit 6613f8e98ab3654ade7e8f5352d8d6711b157499. Reason for revert: This change seemed innocent after all, so undoing speculative revert. Original change's description: > Revert "Refactor and remove media_optimization::MediaOptimization." > > This reverts commit 07276e4f89a93b1479d7aeefa53b4fc32daf001b. > > Reason for revert: Speculative revert due to downstream crashes. > > Original change's description: > > Refactor and remove media_optimization::MediaOptimization. > > > > This CL removes MediaOptmization and folds some of its functionality > > into VideoStreamEncoder. > > > > The FPS tracking is now handled by a RateStatistics instance. Frame > > dropping is still handled by FrameDropper. Both of these now live > > directly in VideoStreamEncoder. > > There is no intended change in behavior from this CL, but due to a new > > way of measuring frame rate, some minor perf changes can be expected. > > > > A small change in behavior is that OnBitrateUpdated is now called > > directly rather than on the next frame. Since both encoding frame and > > setting rate allocations happen on the encoder worker thread, there's > > really no reason to cache bitrates and wait until the next frame. > > An edge case though is that if a new bitrate is set before the first > > frame, we must remember that bitrate and then apply it after the video > > bitrate allocator has been first created. > > > > In addition to existing unit tests, manual tests have been used to > > confirm that frame dropping works as expected with misbehaving encoders. > > > > Bug: webrtc:10164 > > Change-Id: I7ee9c8d3c4f2bcf23c8c420310b05a4d35d94744 > > Reviewed-on: https://webrtc-review.googlesource.com/c/115620 > > Commit-Queue: Erik Språng <sprang@webrtc.org> > > Reviewed-by: Niels Moller <nisse@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#26147} > > TBR=nisse@webrtc.org,sprang@webrtc.org > > # Not skipping CQ checks because original CL landed > 1 day ago. > > Bug: webrtc:10164 > Change-Id: Ie0dae19dd012bc09e793c9661a45823fd760c20c > Reviewed-on: https://webrtc-review.googlesource.com/c/116780 > Reviewed-by: Niels Moller <nisse@webrtc.org> > Reviewed-by: Erik Språng <sprang@webrtc.org> > Commit-Queue: Niels Moller <nisse@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#26191} TBR=nisse@webrtc.org,sprang@webrtc.org Change-Id: Ieda1fad301de002460bb0bf5a75267ea065176a8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: webrtc:10164 Reviewed-on: https://webrtc-review.googlesource.com/c/116960 Reviewed-by: Niels Moller <nisse@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Niels Moller <nisse@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26213}
2019-01-11 11:11:10 +01:00
// frame should be dropped. Decremented on whichever thread runs
// OnEncodedImage(), which is only called by one thread but not necessarily
// the worker thread.
std::atomic<int> pending_frame_drops_;
// Congestion window frame drop ratio (drop 1 in every
// cwnd_frame_drop_interval_ frames).
absl::optional<int> cwnd_frame_drop_interval_ RTC_GUARDED_BY(&encoder_queue_);
// Frame counter for congestion window frame drop.
int cwnd_frame_counter_ RTC_GUARDED_BY(&encoder_queue_);
std::unique_ptr<EncoderBitrateAdjuster> bitrate_adjuster_
RTC_GUARDED_BY(&encoder_queue_);
// TODO(sprang): Change actually support keyframe per simulcast stream, or
// turn this into a simple bool `pending_keyframe_request_`.
std::vector<VideoFrameType> next_frame_types_ RTC_GUARDED_BY(&encoder_queue_);
FrameEncodeMetadataWriter frame_encode_metadata_writer_;
// Experiment groups parsed from field trials for realtime video ([0]) and
// screenshare ([1]). 0 means no group specified. Positive values are
// experiment group numbers incremented by 1.
const std::array<uint8_t, 2> experiment_groups_;
struct AutomaticAnimationDetectionExperiment {
bool enabled = false;
int min_duration_ms = 2000;
double min_area_ratio = 0.8;
int min_fps = 10;
std::unique_ptr<StructParametersParser> Parser() {
return StructParametersParser::Create(
"enabled", &enabled, //
"min_duration_ms", &min_duration_ms, //
"min_area_ratio", &min_area_ratio, //
"min_fps", &min_fps);
}
};
AutomaticAnimationDetectionExperiment
ParseAutomatincAnimationDetectionFieldTrial() const;
AutomaticAnimationDetectionExperiment
automatic_animation_detection_experiment_ RTC_GUARDED_BY(&encoder_queue_);
// Provides video stream input states: current resolution and frame rate.
[Adaptation] Make Resources reference counted and add more DCHECKs. In a future CL, adaptation processing and stream encoder resource management will happen on different task queues. When this is the case, asynchronous tasks will be posted in both directions and some resources will have internal states used on multiple threads. This CL makes the Resource class reference counted in order to support posting tasks to a different threads without risk of use-after-free when a posted task is executed with a delay. This is preferred over WeakPtr strategies because WeakPtrs are single-threaded and preferred over raw pointer usage because the reference counted approach enables more compile-time and run-time assurance. This is also "future proof"; when resources can be injected through public APIs, ownership needs to be shared between libwebrtc and the application (e.g. Chrome). To reduce the risk of making mistakes in the future CL, sequence checkers and task queue DCHECKs are added as well as other DCHECKs to make sure things have been cleaned up before destruction, e.g: - Processor gets a sequence checker. It is entirely single-threaded. - Processor must not have any attached listeners or resources on destruction. - Resources must not have any listeners on destruction. - The Manager, EncodeUsageResource and QualityScalerResource DCHECKs they are running on the encoder queue. - TODOs are added illustrating where we want to add PostTasks in the future CL. Lastly, upon VideoStreamEncoder::Stop() we delete the ResourceAdaptationProcessor. Because the Processor is already used in posted tasks, some if statements are added to ensure the Processor is not used after destruction. Bug: webrtc:11542, webrtc:11520 Change-Id: Ibaa8a61d86d87a71f477d1075a117c28d9d2d285 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174760 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@{#31217}
2020-05-11 16:29:22 +02:00
VideoStreamInputStateProvider input_state_provider_;
const std::unique_ptr<VideoStreamAdapter> video_stream_adapter_
RTC_GUARDED_BY(&encoder_queue_);
// Responsible for adapting input resolution or frame rate to ensure resources
// (e.g. CPU or bandwidth) are not overused. Adding resources can occur on any
// thread.
std::unique_ptr<ResourceAdaptationProcessorInterface>
resource_adaptation_processor_ RTC_GUARDED_BY(&encoder_queue_);
std::unique_ptr<DegradationPreferenceManager> degradation_preference_manager_
RTC_GUARDED_BY(&encoder_queue_);
std::vector<AdaptationConstraint*> adaptation_constraints_
RTC_GUARDED_BY(&encoder_queue_);
// Handles input, output and stats reporting related to VideoStreamEncoder
// specific resources, such as "encode usage percent" measurements and "QP
// scaling". Also involved with various mitigations such as initial frame
// dropping.
// The manager primarily operates on the `encoder_queue_` but its lifetime is
// tied to the VideoStreamEncoder (which is destroyed off the encoder queue)
// and its resource list is accessible from any thread.
VideoStreamEncoderResourceManager stream_resource_manager_
RTC_GUARDED_BY(&encoder_queue_);
std::vector<rtc::scoped_refptr<Resource>> additional_resources_
RTC_GUARDED_BY(&encoder_queue_);
// Carries out the VideoSourceRestrictions provided by the
// ResourceAdaptationProcessor, i.e. reconfigures the source of video frames
// to provide us with different resolution or frame rate.
[Adaptation] Make Resources reference counted and add more DCHECKs. In a future CL, adaptation processing and stream encoder resource management will happen on different task queues. When this is the case, asynchronous tasks will be posted in both directions and some resources will have internal states used on multiple threads. This CL makes the Resource class reference counted in order to support posting tasks to a different threads without risk of use-after-free when a posted task is executed with a delay. This is preferred over WeakPtr strategies because WeakPtrs are single-threaded and preferred over raw pointer usage because the reference counted approach enables more compile-time and run-time assurance. This is also "future proof"; when resources can be injected through public APIs, ownership needs to be shared between libwebrtc and the application (e.g. Chrome). To reduce the risk of making mistakes in the future CL, sequence checkers and task queue DCHECKs are added as well as other DCHECKs to make sure things have been cleaned up before destruction, e.g: - Processor gets a sequence checker. It is entirely single-threaded. - Processor must not have any attached listeners or resources on destruction. - Resources must not have any listeners on destruction. - The Manager, EncodeUsageResource and QualityScalerResource DCHECKs they are running on the encoder queue. - TODOs are added illustrating where we want to add PostTasks in the future CL. Lastly, upon VideoStreamEncoder::Stop() we delete the ResourceAdaptationProcessor. Because the Processor is already used in posted tasks, some if statements are added to ensure the Processor is not used after destruction. Bug: webrtc:11542, webrtc:11520 Change-Id: Ibaa8a61d86d87a71f477d1075a117c28d9d2d285 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174760 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@{#31217}
2020-05-11 16:29:22 +02:00
// This class is thread-safe.
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 video_source_sink_controller_
RTC_GUARDED_BY(worker_queue_);
// Default bitrate limits in EncoderInfoSettings allowed.
const bool default_limits_allowed_;
Reland "Parse encoded frame QP if not provided by encoder" This reverts commit 727d2afc4330efebc904e0e4f366e885d7b08787. Reason for revert: Use thread-safe wrapper for H264 parser. Original change's description: > Revert "Parse encoded frame QP if not provided by encoder" > > This reverts commit 8639673f0c098efc294a7593fa3bd98e28ab7508. > > Reason for revert: linux_tsan fails https://ci.chromium.org/ui/p/webrtc/builders/ci/Linux%20Tsan%20v2/25329/overview > > Original change's description: > > Parse encoded frame QP if not provided by encoder > > > > Bug: webrtc:12542 > > Change-Id: Ic70b46e226f158db7a478a9f20e1f940804febba > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/210966 > > Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> > > Reviewed-by: Åsa Persson <asapersson@webrtc.org> > > Cr-Commit-Position: refs/heads/master@{#33434} > > TBR=asapersson@webrtc.org,ssilkin@webrtc.org > > Change-Id: Ie251d8f70f8e87fd86b63730aefd2ef3f941e4bb > No-Presubmit: true > No-Tree-Checks: true > No-Try: true > Bug: webrtc:12542 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211355 > Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> > Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> > Cr-Commit-Position: refs/heads/master@{#33441} # Not skipping CQ checks because this is a reland. Bug: webrtc:12542 Change-Id: Ib7601fd6f2f26bceddbea2b4ba54d67a281f3a59 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211660 Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> Reviewed-by: Åsa Persson <asapersson@webrtc.org> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> Cr-Commit-Position: refs/heads/master@{#33458}
2021-03-15 10:12:57 +01:00
// QP parser is used to extract QP value from encoded frame when that is not
// provided by encoder.
QpParser qp_parser_;
const bool qp_parsing_allowed_;
// Enables encoder switching on initialization failures.
bool switch_encoder_on_init_failures_;
const absl::optional<int> vp9_low_tier_core_threshold_;
[Adaptation] Move adaptation logic to a separate task queue. This CL unblocks future Call-Level Mitigation strategies by moving the ResourceAdaptationProcessor to a separate task queue. This signifies a major milestone in the new resource adaptation architecture because with this CL the threading model is in place and moving the Processor to the Call and increasing its responsibilities is made possible. In this CL, we still have one Processor per VideoStreamEncoder and the VideoStreamEncoder is responsible for the creation and the destruction of its Processor and that Processor's task queue. But the PostTasks are in place and the decision-making is executed on a separate queue. This CL: - Moves ResourceAdaptationProcessor to an adaptation task queue. It continues to be entirely single-threaded, but now operates on a separate task queue. - Makes Resources thread-safe: Interaction with the Processor, i.e. OnResourceUsageStateMeasured() and IsAdaptationUpAllowed(), happens on the adaptation task queue. State updates are pushed from the encoder task queue with PostTasks. - QualityScalerResource operates on both task queues; the QP usage callbacks are invoked asynchronously. - The VideoStreamEncoderResourceManager operates on the encoder task queue with the following exceptions: 1) Its resources are accessible on any thread (using a mutex). This is OK because resources are reference counted and thread safe. This aids adding and removing resources to the Processor on the adaptation task queue. 2) |active_counts_| is moved to the adaptation task queue. This makes it possible for PreventAdaptUpDueToActiveCounts to run IsAdaptationUpAllowed() on the adaptation task queue. A side-effect of this is that some stats reporting now happen on the adaptation task queue, but that is OK because VideoStreamEncoderObserver is thread-safe. The Manager is updated to take the new threading model into account: - OnFrameDroppedDueToSize() posts to the adaptation task queue to invoke the Processor. - OnVideoSourceRestrictionsUpdated(), now invoked on the adaptation task queue, updates |active_counts_| synchronously but posts to the encoder task queue to update video source restrictions (which it only uses to calculate target frame rate). - MaybePerformQualityRampupExperiment() posts to the adaptation task queue to maybe reset video source restrictions on the Processor. |quality_rampup_done_| is made std::atomic. Bug: webrtc:11542, webrtc:11520 Change-Id: I1cfd76e0cd42f006a6d2527f5aa2aeb5266ba6d6 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174441 Reviewed-by: Evan Shrubsole <eshr@google.com> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/heads/master@{#31231}
2020-05-12 18:49:07 +02:00
// Public methods are proxied to the task queues. The queues must be destroyed
// first to make sure no tasks run that use other members.
rtc::TaskQueue encoder_queue_;
// Used to cancel any potentially pending tasks to the worker thread.
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
ScopedTaskSafety task_safety_;
};
} // namespace webrtc
#endif // VIDEO_VIDEO_STREAM_ENCODER_H_