The test was failing (in a flaky fashion, interestingly), comparing:
* 50.5 whose mantissa is:
1001010000000000000000000000000000000000000000000000
* with 50.500000000000036 whose mantissa is:
1001010000000000000000000000000000000000000000000101
since EXPECT_DOUBLE_EQ() only allows 4 ULPs difference.
We don't need this kind of precision.
Bug: webrtc:11134
Change-Id: I811178b0762dbcd61d4f2d3f047ea0b59847fa57
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165761
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Yves Gerey <yvesg@google.com>
Cr-Commit-Position: refs/heads/master@{#30230}
The overlap in functionality is quite limited and separating the
functionality makes it a bit easier to follow each. This prepares
for adding a SimulatedThread class in a follow up CL.
Bug: webrtc:11255
Change-Id: I83c754bd570113dfb582098bb4d39e27bb4f4d87
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165688
Reviewed-by: Jonas Olsson <jonasolsson@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30229}
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}
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}
Avoid a warning-as-error of MSVC 2019 due to a test ignoring a
[[nodiscard]] return value:
C4834: discarding return value of function with 'nodiscard' attribute
Change-Id: I6b70d85769f311814393412830f48d0d8bfef63d
Bug: webrtc:11275
Change-Id: I6b70d85769f311814393412830f48d0d8bfef63d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/164467
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30226}
Add missing #include to fix some build error on `winuwp` with some code
using rtc::dchecked_cast<> under an `#ifdef (WINUWP)`, resulting in an
undefined symbol error.
Bug: webrtc:11194
Change-Id: Iad9e74c3e92ed6cf1461f34cdd9329d13f5d62e6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161721
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30224}
This way we can rely on existing task scheduling and execution
functionality, reducing the required functionality to support the
fake socket server.
This prepares for support simulated time execution of peer
connection level tests.
Bug: webrtc:11255
Change-Id: I7de64a099c2e355c70929ecff79b8ea3b98b70b8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165398
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30221}
Given that we already have Thread:.Invoke that can be used with lambda,
SynchronousMethodCall doesn't add any value.
This simplification prepares for simulated time peer connection tests.
Bug: webrtc:11255
Change-Id: I478a11f15e30e009dae4a3fee2120f6d7a03355f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165683
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30217}
Some messages were processed after involved objects were destructed,
a.k.a. 'use after free'.
This CL fixes that by disconnecting signals before fixture destruction,
honoring CreateChannel/DestroyChannel symmetry and following what is
done in similar test cases.
Bug: webrtc:11269
Change-Id: I122aca70a9978b752edc01e5f31583f4425f3624
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165685
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Commit-Queue: Yves Gerey <yvesg@google.com>
Cr-Commit-Position: refs/heads/master@{#30214}
Long term goal is to use the VideoStreamDecoder in the VideoReceiveStream so
that we can stop using legacy VideoCodingModule components and classes. This CL is
one of several in preparation for that.
Bug: webrtc:7408, webrtc:9378
Change-Id: Ifd7e4c3c7d38dbb7c4b0636aaad318c571a29158
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/164525
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30211}
If in simulcast case some streams are disabled (especially the first one), the key-frame
requests might be ignorred by e.g. libvpx vp8 encoder wrapper.
Before this CL SimulcastEncoderAdapter always passes single frame type in Encode() call.
However, if underlying encoder used simulcast, it would've expected as many frame types
as there are streams.
Bug: none
Change-Id: I7f56a6540b67273b7d3cf9fa86dc76015b92d271
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165681
Reviewed-by: Evan Shrubsole <eshr@google.com>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30210}
This will make RESULT lines still come out after we add a second JSON
writer implementation.
Bug: chromium:1029452
Change-Id: I5cba3151c21df2901f19305e9b71bc5c9638a0ae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165399
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30208}
This change improves performance under high load by processing
all pending tasks each time the thread is woken up by libevent.
Additionally, the pipe used to wake up the TaskQueue thread now
not be written to if there's already a pending write on the pipe.
This fixes a bug where under high load the pipe write buffer can
fill and cause tasks to get dropped.
Bug: webrtc:11259, webrtc:8876
Change-Id: Ic82978c71bf9e9a25f281ca4775d46168d161d4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165420
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30202}
The current camera switch API sequentially cycles through each
camera name for each method invocation. This policy provides
reasonable behavior for devices with 2 or 3 cameras, but
presents challenges with devices that contain several cameras.
For example in a scenario where the current camera is oriented
on the same side as the next camera name, a developer would need to
call switchCamera multiple times to capture from a camera oriented on
a different side of the device.
This commit allows a developer to specify a camera name when switching
cameras. This flexibility allows developers to have more control over
which device they switch to in cases where a device contains several cameras.
Bug: webrtc:11261
Change-Id: I93d46d70b2c7cf735a411a4ef4f33e926bf3a5ea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165040
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30199}
Split out of https://webrtc-review.googlesource.com/c/src/+/165389.
I disentangled the plottable counter printer from the perf result
printer so it will work for both future implementations of the perf
test JSON writers. The only thing plottable counters and the
results writer had in common was that both wrote JSON anyway.
Bug: chromium:1029452
Change-Id: I041c3096641eda42542e8d994b246eb313940b4b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165397
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30198}
This is a reland of 63db77007bea78487af05d46b1b46106761556a1 that
was broken as I flipped != and == :(
Luckily this made a test flaky, and hence was the original change reverted.
Original change's description:
> Add field trial to base stable target rate on loss based target rate
>
> I.e not the pushback_rate that includes the congestion window pushback
> (if enabled).
>
> Bug: None
> Change-Id: I413d011004a95da03dd62f5b423abc3c8b66b333
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165383
> Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30189}
Bug: None
Change-Id: Ia637d0498e6c0c2708eba659e2a30f3235944d4c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165391
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30196}
This reverts commit 63db77007bea78487af05d46b1b46106761556a1.
Reason for revert: Flipped !=which should have been == makes tests
Original change's description:
> Add field trial to base stable target rate on loss based target rate
>
> I.e not the pushback_rate that includes the congestion window pushback
> (if enabled).
>
> Bug: None
> Change-Id: I413d011004a95da03dd62f5b423abc3c8b66b333
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165383
> Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Reviewed-by: Sebastian Jansson <srte@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30189}
TBR=brandtr@webrtc.org,srte@webrtc.org,jonaso@webrtc.org
Change-Id: I883edb8a74f1ae2a4d783b9825cc08c6a5228aa9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165388
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30193}
This means that we avoid exposing FakeNetworkSocket and
moves related code closer together.
It's done in preparation for future work on simulated time testing.
Bug: webrtc:9883
Change-Id: Id6d1b0a6055f30da8e6646bd5347024fbd9c9dfd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/164537
Reviewed-by: Jonas Olsson <jonasolsson@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30181}
