This change just affects the ERLE metric that is reported. The rest is unaffected and bitexact.
Bug: webrtc:12280
Change-Id: I2d28ef14a9b704c83aba18b624f67671eec4a042
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196649
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Jesus de Vicente Pena <devicentepena@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32809}
Instead of signaling an inter layer dependency with the inter_layer_prediction flag we instead flatten the frame IDs so that an inter layer dependency can be signaled as a regular frame reference.
Bug: webrtc:12206, webrtc:12221
Change-Id: I0390fd3d0f5494cde59eece227db938dbc5d7992
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196648
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32808}
The implementations for the fully connected layer can be simlpified by
using `VectorMath:DotProduct()`. In this way, it is also possible to
remove (nearly) duplicated SIMD code, reduce the binary size and more
easily maintain the code.
This CL also forces unoptimized code for the output layer of the VAD,
which is a FC 24x1 layer. A slight improvement of the realtime has
been measured (delta ~ +5x).
Bug: webrtc:10480
Change-Id: Iee93bd59f7905ebf96275dbbfeb3c921baf4e8db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195580
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32806}
Using `VectorMath::DotProduct()` in GatedRecurrentLayer to reuse existing
SIMD optimizations. Results:
- When SSE2/AVX2 is avilable, the GRU layer takes 40% of the unoptimized
code
- The realtime factor for the VAD improved as follows
- SSE2: from 570x to 630x
- AVX2: from 610x to 680x
This CL also improved the GRU layer benchmark by (i) benchmarking a GRU
layer havibng the same size of that used in the VAD and (ii) by prefetching
a long input sequence.
Bug: webrtc:10480
Change-Id: I9716b15661e4c6b81592b4cf7c172d90e41b5223
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195545
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32803}
After the refined filter has been determined to perform better than
the coarse filter, and the coefficients of the coarse filters are
overwritten by the ones from the refined filter, at least 100 ms have
to pass before the adaptation of the refined filter is allowed to speed
up due to good coarse filter performance.
This change solves the vicious circle described in webrtc:12265, where
the coarse and refined filters can diverge over time.
This feature can be disabled remotely via a kill-switch. When disabled
the AEC output is bit-exact to before the change.
Bug: webrtc:12265,chromium:1155477
Change-Id: Iacd6e325e987dd8a475bb3e8163fee714c65b20a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196501
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32801}
There is currently an error reported about unsupported formats
for most users when an WebRTC connection is setup. This CL
changes the error to a warning.
The reason is that some H264 profiles are supported in hardware
but not in software. When the decoder is created we will try to
create pair of both software and hardware decoders for the
union of supported formats. The creation of the software
decoder will then fail. There is a small risk that this leads
to errors later but only in rare circumstances. Most of the time
this log line only confuses consumers as well as developers.
Bug: none
Change-Id: Ib2119016fa91bc270437a2bcf7892e9fdd7c419c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196645
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32800}
The a=rtcp:9 IN IP4 0.0.0.0 line is required by JSEP to be generated,
but is also required to be ignored. This reduces log spew.
Bug: None
Change-Id: I984060d9693b9df4c4cfdf2c5dea0ea620f4bc83
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196641
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Philipp Hancke <philipp.hancke@googlemail.com>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32798}
This CL makes the static variable kChunkSizeMs constexpr to avoid
potential issues on some compilers.
Bug: None
Change-Id: I8e2b1819561ec96fb17d3899af95405cc36a6097
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196640
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32795}
This moves the code for threadjumping to get the RTP transport
despite its thread guard from the main function to two functions
marked especially "ForTesting".
Bug: webrtc:12230
Change-Id: I4473ed38e6fdedb05e2fbc97c2521bc1993fdd1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196521
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32792}
This CL:
1) Updates RtpSenderVideo to actually populate the is_key_frame field
properly.
2) Updates UlpfecGenerator to:
* Allow updating the protection parameters before adding any packet.
* Apply keyframe protection parameter when at least one buffered
media packet to be protected belongs to a keyframe.
Updating the parameters in the middle of a frame is allowed, at that
point they only determine how many _complete_ frames are needed in order
to trigger FEC generation. Only that requirement is met, will the
protection parameters (e.g. FEC rate and mask type) actually be applied.
This means that delta-frames adjecent to a key-frame (either ahead of
or after) may be protected in the same way as the key-frame itself.
Bug: webrtc:11340
Change-Id: Ieb84d0ae46de01c17b4ef72251a4cb37814569da
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195620
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32787}
Handle the case in which neither WEBRTC_ARCH_X86_FAMILY nor
WEBRTC_HAS_NEON are defined.
Bug: webrtc:10480
Change-Id: I241583911d8e5645dfbd39b60337dd20b2d9f046
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196525
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32786}
This makes it thread-safe to access, but not necessarily to use.
Bug: webrtc:12230
Change-Id: I6b48d86dff24b162d382135abeaf560971fdf614
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196524
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32785}
This time the class is added but only used if the field trial "WebRTC-Bwe-NewInterArrivalDelta/Enabled/" is enabled.
Original cl description:
This cl copies modules/remote_bitrate_estimator/inter_arrival.x to inter_arrival.h and interrival_delta.cc in goog_cc
but modified to use webrtc::Timestamp and webrtc::Timedelta in order to avoid having to use 24 bit time repressentation.
patchset 1 is a pure revert of the revert https://webrtc-review.googlesource.com/c/src/+/196343
patchset 2 contains a modification to allow running it behind an experiment.
Bug: webrtc:12269
Change-Id: Ide80e9f5243362799a2cc1f0fcf7e613e707d851
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196502
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32784}
This will soon become a compile-time error. Fix class hierarchies that
wrap StrictMock in a NiceMock or vice-versa by removing redundant
wrappings and removing inheritance from Nice/StrictMock and fixing the
call sites as appropriate.
Bug: b/173702213
Change-Id: Ic90b1f270c180f7308f40e52e358a8f6a6baad86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196461
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32783}
This is a reland of 6e7167456b5eba36c7985d6a74f1d191958d4e0f
Patch set 1 is the original.
Later patch sets fix a parsing bug, and adds a new flag which enables
or disabled the ability to set separate per spatial layer speed
(use_per_layer_speed).
Original change's description:
> Adds experimental libvpx VP9 speed settings.
>
> Using the field trial WebRTC-VP9-PerformanceFlags, this CL allows you to
> configure the libvpx VP9 encoder with a list of flags to affect the
> quality vs speed tradeoff. This CL adds support for:
>
> * Speed (effort), for the temporal base layer frames
> * Speed for higher (non-base) layer frames
> * De-blocking (as part of the loopfilter) enabled for:
> 0 = all frames
> 1 = all but frames from the highest temporal layer
> 2 = no frames
>
> Each entry in the list has a threshold in min number of pixels needed
> for settings in the entry to apply.
>
> Example: Two spatial layers (180p, 360p) with three temporal
> layers are configured. Field trial "WebRTC-VP9-PerformanceFlags" set to:
> "use_per_layer_speed,min_pixel_count:0|129600,base_layer_speed:5|7,high_layer_speed:8|8,deblock_mode:1|2"
> This translates to:
> S0:
> - TL0: Speed 5, deblocked
> - TL1: Speed 8, deblocked
> - TL2: Speed 8, not deblocked
> S1:
> - TL0: Speed 7, not deblocked
> - TL1: Speed 8, not deblocked
> - TL2: Speed 8, not deblocked
>
> Bug: webrtc:11551
> Change-Id: Ieef6816d3e0831ff53348ecc4a90260e2ef10422
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188461
> Reviewed-by: Michael Horowitz <mhoro@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32749}
Bug: webrtc:11551
Change-Id: Ie7c703eb122197235d8ce77cb72db7a347382468
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196345
Reviewed-by: Michael Horowitz <mhoro@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32780}
This CL implements a Resource that aggressively reports overuse or
underuse until the encoded stream has the max pixels specified. The
pixel limit is controlled with a field trial, e.g:
--force-fieldtrials="WebRTC-PixelLimitResource/Enabled-307200/"
This caps the resolution to 307200 (=640x480). This can be used by the
TestBed to simulate being CPU limited. Note that the resource doesn't
care about degradation preference at the moment, so if the degradation
preference would be set to "maintain-resolution" the PixelLimitResource
would never stop reporting overuse and we would quickly get a low-FPS
stream.
PixelLimitResource runs a repeating task and reports overuse, underuse
or neither every 5 seconds. This ensures we quickly reach the desired
resolution.
Unit tests are added. I did not add any integration tests (I think
that's overkill for a testing-only resource) but I have manually
verified that this works as intended.
This CL also moves the FakeVideoStreamInputStateProvider into a test/
folder and exposes video_stream_adapter.cc's GetLowerResolutionThan().
Bug: webrtc:12261
Change-Id: Ifbf7c4c05e9dd2843543589bebef3f49b18c38c0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195600
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@{#32771}
Refactoring done to more easily and cleanly add SIMD optimizations and
to remove `GatedRecurrentLayer` from the RNN VAD api.
Bug: webrtc:10480
Change-Id: Ie1dffdd9b19c57c03a0b634f6818c0780456a66c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195445
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32770}
Adds a new "rtc_pipewire_version" build option to specify version of
PipeWire we want to build against. We use version "0.2" by default
which is version of PipeWire we currently have in sysroot and which
is supported even on older systems like RHEL7 and Debian.
Bug: chromium:1146942
Change-Id: Ib74b52fa87623a3f960e419916b01586aaeba47f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195441
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32768}
Refactoring done to more easily and cleanly add SIMD optimizations and
to remove `FullyConnectedLayer` from the RNN VAD api.
Minor improvements (readability, API):
- `FullyConnectedLayer` gets the ActivationFunction enum and not
a function view anymore
- SSE2 optimization moved into `FullyConnectedLayer::ComputeOutputSse2`
- layer name added for improved logs
Bug: webrtc:10480
Change-Id: Ida4903a67655e19ef0464f378c433c1f6e96dca7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195444
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32766}
This reverts commit 0496a4121188a26013dca007bf6e9a7ab6d961b6.
Reason for revert: Causes unexpected changes in perf tests.
Original change's description:
> Add class InterArrivalDelta to goog_cc
>
> This cl copies modules/remote_bitrate_estimator/inter_arrival.x to inter_arrival.h and interrival_delta.cc in goog_cc in the first patchset.
> In the following- this class is modified to use webrtc::Timestamp and webrtc::Timedelta in order to avoid having to use 24 bit time repressentation.
>
> Bug: none
> Change-Id: I9befe6e3e283cf7e21efa974ae33e8a83e26cbe6
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194004
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32733}
TBR=perkj@webrtc.org,crodbro@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: none
Change-Id: I725b246f6ec0c293cb3ada39b1a65a14ef9a001e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196343
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32765}
Changes:
1) Scoped class
This is a special class for GLib based objects which we need to manually
delete with different functions. Wrapping these objects into Scoped class
will destroy them automatically when they go out of scope.
2) Window sharing support
Unlike screen sharing, with window sharing we are required to obtain more
information from the PipeWire stream, like video crop metadata, which we
use to properly set size of our buffer.
3) Support for DmaBuf and MemFd buffer types
As of now, we expected the PipeWire stream will provide only plain data
which we just need to copy to our buffer. We now add support for new
buffer types, which are often preferred for better effeciency.
4) Minor bugfixes:
a) Additionally accept PipeWire streams using alpha channels (BGRA, RGBA)
b) Add lock over PipeWire loop to prevent potential issues until we fully
intialize everything we need
c) When obtaining buffers, make sure we work with the latest one
Bug: chromium:682122
Change-Id: I64638d5dcbe18e7280550dca0b01b17c511ac98a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194100
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#32763}
This reverts commit 6e7167456b5eba36c7985d6a74f1d191958d4e0f.
Reason for revert: Unexpected perf change
Original change's description:
> Adds experimental libvpx VP9 speed settings.
>
> Using the field trial WebRTC-VP9-PerformanceFlags, this CL allows you to
> configure the libvpx VP9 encoder with a list of flags to affect the
> quality vs speed tradeoff. This CL adds support for:
>
> * Speed (effort), for the temporal base layer frames
> * Speed for higher (non-base) layer frames
> * De-blocking (as part of the loopfilter) enabled for:
> 0 = all frames
> 1 = all but frames from the highest temporal layer
> 2 = no frames
>
> Each entry in the list has a threshold in min number of pixels needed
> for settings in the entry to apply.
>
> Example: Two spatial layers (180p, 360p) with three temporal
> layers are configured. Field trial "WebRTC-VP9-PerformanceFlags" set to:
> "min_pixel_count:0|129600,base_layer_speed:5|8,high_layer_speed:7|8,deblock_mode:1|2"
> This translates to:
> S0:
> - TL0: Speed 5, deblocked
> - TL1: Speed 8, deblocked
> - TL2: Speed 8, not deblocked
> S1:
> - TL0: Speed 7, not deblocked
> - TL1: Speed 8, not deblocked
> - TL2: Speed 8, not deblocked
>
> Bug: webrtc:11551
> Change-Id: Ieef6816d3e0831ff53348ecc4a90260e2ef10422
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/188461
> Reviewed-by: Michael Horowitz <mhoro@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32749}
TBR=sprang@webrtc.org,ssilkin@webrtc.org,mhoro@webrtc.org
Change-Id: If910963441ac1a0e002aac7066791c7cc7764a1a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11551
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196344
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32762}
