This reverts commit 46b3bc6c24c233fe41a2401ce6e8eb8204a2d5a8.
Reason for revert: Speculative revert. Breaks downstream project
Original change's description:
> Make sure that "current" rtc::Thread instances are always current for TaskQueueBase.
>
> This is a necessary part of fulfilling the TaskQueueBase
> interface. If a thread does not register as the current TQ, yet offers
> the TQ interface, TQ 'current' checks will not work as expected and
> code that relies them (TaskQueueBase::Current() and IsCurrent())
> will run in unexpected ways.
>
> Bug: webrtc:11572
> Change-Id: Iab747bc474e74e6ce4f9e914cfd5b0578b19d19c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175080
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31254}
TBR=mbonadei@webrtc.org,tommi@webrtc.org
Change-Id: I69ff3355f0ec447b25604bd95fdacbdb4d4f3f27
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11572
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175104
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31259}
This reverts commit 475006d4a30f8bc47f82eb540a6a066da2829095.
Reason for revert: Speculative revert. Breaks downstream project
Original change's description:
> Revert back to using the task_queue_ for guarding access.
>
> This removes the SequenceChecker that was temporarily used while
> the rtc::Thread TQ implementation was being fixed.
>
> Bug: none
> Change-Id: Iaa46e47371211ac0a97b2dcaf23cef12b43ee8ea
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175081
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31256}
TBR=tommi@webrtc.org,srte@webrtc.org
Change-Id: I17a12bdca888a63f2fd161da30c0def5b9c3d04e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: none
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175103
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31258}
This removes the SequenceChecker that was temporarily used while
the rtc::Thread TQ implementation was being fixed.
Bug: none
Change-Id: Iaa46e47371211ac0a97b2dcaf23cef12b43ee8ea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175081
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31256}
This is a necessary part of fulfilling the TaskQueueBase
interface. If a thread does not register as the current TQ, yet offers
the TQ interface, TQ 'current' checks will not work as expected and
code that relies them (TaskQueueBase::Current() and IsCurrent())
will run in unexpected ways.
Bug: webrtc:11572
Change-Id: Iab747bc474e74e6ce4f9e914cfd5b0578b19d19c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175080
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31254}
This test ensures that when changing degradation preference,
a resource that was previously downgraded in a different degradation
preference can not adapt up.
Bug: webrtc:11522, webrtc:11523
Change-Id: Id362530408db4c49b0d0b2516be9a11ccc7c8f37
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175012
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#31250}
The current documentation seems outdated: Building the `AppRTCMobile`
target does not generate a `run_modules_unittests` binary and the
`AppRTCMobileTest` target does not exist.
No-Try: True
Bug: None
Change-Id: Ia9156fe475188f07d13898b4d83a606c49119a2e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175013
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31249}
In https://webrtc-review.googlesource.com/c/src/+/173704 the overhead
calculations were made more static, so that "volatile" extensions
(those that are not set on every packet) are ignored. The intent, as
the comments specify, was to ignore RepairedRtpStreamId since that is
only used on RTX packets.
This CL makes us actually count that extension as volatile.
Bug: webrtc:10809
Change-Id: If42ae84e4c09ff9112e93f8d872ee890c6253a23
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175010
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31246}
Android lint is changing, so min_sdk_version is no longer needed in GN.
Relanding because webrtc was able to roll chromium.
Bug: chromium:1017190
Change-Id: I3e351381cb735d511da648d4ef41613c923d62c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174983
Commit-Queue: Peter Wen <wnwen@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31244}
(Misc cleanup associated with
https://webrtc-review.googlesource.com/c/src/+/174441.)
This test was previously assuming what when QP usage is handled it
first posts to the adaptation queue and then back with the result from
the encoder queue.
While the assumption is correct it is not an implementation detail that
the test was trying to assert, nor do we need such a test.
TriggerQualityScalerHighQpAndReturnIfQpSamplesShouldBeCleared() is
updated to wait for an event associated with QP having been handled,
which is all that the test really cares about.
Bug: webrtc:11542, webrtc:11520
Change-Id: I3286c3ab631f09c43abe0fd59f31c3997aedd9f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175004
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#31243}
A connection is currently deleted if it has not recevied anything for
30s. This patch adds a field trial that allows modifying this value
if no pings are outstanding.
The motivation for this is to experiment with pinging slower than
once per 30s in order to save battery.
Bug: webrtc:10282
Change-Id: I3272b9d68d44fc30379bd9a6c643db6b09766486
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175005
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31239}
This reverts commit 1b8ef63876ebfa55a51c8ca9b1d8206bf8233e01.
Reason for revert: Breaks downstream projects. b/155256727
Original change's description:
> Add an optional override for AudioRecord device
>
> This is important when we have multiple named devices connected over
> USB (eg. "Webcam", "Microphone", "Headset") and there is some way to
> choose a specific input device to route from.
>
> Bug: b/154440591
> Change-Id: I8dc1801a5e4db7f7bb439e855d43897c1f7d8bc4
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/173748
> Commit-Queue: Robin Lee <rgl@google.com>
> Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31130}
TBR=henrika@webrtc.org,sakal@webrtc.org,rgl@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: b/154440591, b/155256727
Change-Id: I6836676096d47d9da5702a40b9d127569ad50dda
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/175008
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31238}
Now we only await a previous adaptation if the degradataion
preference is the same as our current degradation preference.
Without this guard we can get stuck as detailed in the attached bug.
Bug: webrtc:11562
Change-Id: I91be48546446ef8d01fe901bc6889201a5b97ba6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174805
Commit-Queue: Evan Shrubsole <eshr@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31236}
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}
When Chromium displays the selection dialog for screens it gets the thumbnails by calling SelectSource for the first monitor then CaptureFrame, then SelectSource for the next monitor then CaptureFrame, and so on. With 1 or 2 screens this does not show any issues, but with 3 or more screens the program may crash.
The queue of frame buffers is actually just 2 frame buffers that get swapped every time a frame is captured. When you have one monitor both buffers will be sized for it's resolution. When you have two monitor the first buffer is sized for the first monitor and the second buffer for the second monitor. Since the monitors are selected in turn monitors and frame buffers stay matched up and things work fine. With a third monitor the first buffer is sized for the first monitor, but then later reused to capture the third monitor. If the resolution of the third monitor does not match the first we either crash or have extra junk in the frame from when we captured the first monitor.
Bug: chromium:396091
Change-Id: I7b5ee914b02fee48c09422cee1e320396c9550c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174520
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#31229}
This allows users to inject the residual echo detector, as a step toward making it an optional part of compilation.
Bug: webrtc:11292, webrtc:11539
Change-Id: I7fcc8dbaced67a82851cd6cdcbc115eb01c21fcf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174040
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31222}
This CL makes the VideoStreamEncoderResourceManager's inner Resources
(PreventAdaptUpDueToActiveCounts,
PreventIncreaseResolutionDueToBitrateResource and
PreventAdaptUpInBalancedResource) not directly depend on any of the
manager's states that will continue to live on the encoder task queue
when the adaptation task queue is introduced in the next CL.
PreventAdaptUpDueToActiveCounts depends on effective degradation
preference, which it can get from the Processor, and the active counts,
which will move to the adaptation queue and is safe to use.
PreventIncreaseResolutionDueToBitrateResource depends on encoder
settings and target bitrate. This Resource now listens to these states
being updated, which may be implemented with a PostTask when the
adaptation queue is added.
PreventAdaptUpInBalancedResource depends on the effective degradation
preference, which it can get from the Processor; balanced settings,
which is a const readonly struct (thread-safe); and encoder target
bitrate, which it listens for being updated (to be PostTask'ed).
All resources depends on GetReasonFromResource() which will be callable
from the adaptation queue.
Bug: webrtc:11542, webrtc:11520
Change-Id: Ifa7bd87d9d8729988073f78f6a37c6f3b8aa4db1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174807
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@{#31220}
This CL adds a queue for pending QualityScalerQpUsageHandlerCallbacks
and private methods for "Queueing", "Handling" and "Aborting" them,
using a sequence number as an ID to ensure we don't accidentally invoke
the same callback twice.
Because we don't have the adaptation task queue yet, callbacks are still
synchronously handled, which means the "pending callbacks" queue would
never have more than 1 element. However, when the adaptation task queue
is added and this is made asynchronous, it will be possible for multiple
callbacks to be pending simultaneously. This design is future-proof.
This CL is split out to aid reviewability. The CL that adds the
adaptation task queue will affect a lot of code. By landing this
separately, the adaptation queue CL will be easier to review.
This CL adds quality_scaler_resource_unittest.cc.
Bug: webrtc:11542, webrtc:11520
Change-Id: I00e7f6bfda9f8e8e82ec25916aa48e9349c8d70c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/174802
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@{#31219}
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}
