The number of audio channels can be configured in SDP, and can thus be
set to arbitrary values by an attacker. This CL fixes an out-of-bounds
memory access that could occur when the number of channels is set to a
large number.
Bug: chromium:1265806
Change-Id: Ic88ff6d85b978b8eb99bf03cc52457a4552e8c24
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237808
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35354}
Add implementation of RTC_DCHECK_NOTREACHED equal to the RTC_NOTREACHED.
The new macros will replace the old one when old one's usage will be
removed. The idea of the renaming to provide a clear signal that this
is debug build only macros and will be stripped in the production build.
Bug: webrtc:9065
Change-Id: I4c35d8b03e74a4b3fd1ae75dba2f9c05643101db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237802
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35348}
This CL set the spatial id in LibaomAv1Encoder and set correct number
of spatial layers for AV1 in FrameEncodeMetadataWriter.
Bug: None
Change-Id: I40092e45be88ec9ab75f228d9ca84c44e3cad326
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237662
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Zhaoliang Ma <zhaoliang.ma@intel.com>
Cr-Commit-Position: refs/heads/main@{#35339}
This adds the Main 3.1 profile to the list of supported H264 codecs. This unifies the output of WebRTC codecs among macOS/Windows (which both have Main 3.1 codecs) and headless Linux browsers.
Bug: None
Change-Id: Ife2fe8c1827be9368fabccc5f24ba316671b1b8b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236600
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35328}
alcooper@ and mfoltz@ are taking ownership of desktop_capture; while
joedow@ and jamiewalch@ are no longer working in this area.
Bug: chromium:1268590
Change-Id: Ie28f10ad1ef19aa428e22a6fa537a98b82c42233
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237542
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Joe Downing <joedow@google.com>
Reviewed-by: Joe Downing <joedow@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35327}
* Clearing while waiting for a frame should return a new frame
entering the buffer.
* Stopping while waiting for a frame should cancel the wait.
Bug: webrtc:13343
Change-Id: Ife9abfa8b6ea56141c9f32ff37d3b2a2e62a44f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236849
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35314}
UpdateMonitors() crops the selected RANDR monitor to the root window,
in case X returns a monitor that lies outside it. But it wasn't enough.
SelectSource() alters the selection directly and doesn't call
UpdateMonitors(), so it also needs to crop. This fixes the case
where a virtual monitor is added, the screen resolution is reduced,
then the new monitor is selected (which now extends outside the reduced
screen size).
This CL also fixes an issue where the ScreenCapturerHelper would
sometimes expand a damage-region outside the DesktopFrame boundary.
This occurred because the helper's size was set to the full
pixel-buffer, so it didn't crop correctly to the monitor's rect.
This CL sets the helper's correct size, and removes some unnecessary
cropping now that the helper will do it correctly.
Bug: chromium:1266179
Change-Id: I8eb8f3302701be4f393934c0899f41def3512853
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237120
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35304}
Implement AnalogGainStatsReporter and add it in AudioProcessingImpl.
This class computes statistics for analog gain updates and
periodically reports them into a histogram.
The added histograms for analog gain update statistics:
- WebRTC.Audio.ApmAnalogGainDecreaseRate
- WebRTC.Audio.ApmAnalogGainIncreaseRate
- WebRTC.Audio.ApmAnalogGainUpdateRate
- WebRTC.Audio.ApmAnalogGainDecreaseAverage
- WebRTC.Audio.ApmAnalogGainIncreaseAverage
- WebRTC.Audio.ApmAnalogGainUpdateAverage
The histograms are defined in
https://chromium-review.googlesource.com/c/chromium/src/+/3207987
Bug: webrtc:12774
Change-Id: I3c58d4bb3eb034a11c3f39ab8edb2bc67c5fd5e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/234140
Commit-Queue: Hanna Silen <silen@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35301}
Remove analog_level_minimum and analog_level_maximum from
AudioProcessing GainController1 and replace their use with fixed
values 0 and 255, respectively.
Bug: webrtc:12774
Change-Id: Ia4bfe5ed43a65f1587ed67f36bfbb2966b6fdf26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235822
Commit-Queue: Hanna Silen <silen@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35297}
This was changed by mistake (?) to 5 in a refactoring cl: https://webrtc-review.googlesource.com/c/src/+/222324
This caused the packets lost metric to not count loss gaps that are larger than 5 packets.
Bug: webrtc:13336
Change-Id: Ied4732312aeed81862a74fbc889e33fcedde3def
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236840
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35290}
This is part of a set of CLs to fix the Chromium roll.
Bug: None
Change-Id: I3b00a4051b4219f8338986ebc4c69fa8318920de
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236681
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35286}
We need to use RTC_NOT_SANITIZE("cfi-icall") everywhere where we do
function typecasting, otherwise doing official Chrome builds will result
into crash.
Bug: chromium:1262535
Change-Id: If7358ccab6bd626e494b7ecd3077aa29502080c1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236587
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35281}
The class has also been renamed to better reflect its purpose.
Bug: webrtc:7494
Change-Id: I223a364ab4f8b8a5fef765848bf05675d045cefd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236343
Reviewed-by: Hanna Silen <silen@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35277}
This ensures that the payload descriptor and potential generic
descriptors uses the same temporal layer.
Bug: b/200518293
Change-Id: I17e980b47fe6c814cb393fc459064576447aa27a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236520
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35275}
Holdback window can be specified as absolute time and in terms of packet
send times. Example:
WebRTC-TaskQueuePacer/Enabled,holdback_window:20ms,holdback_packet:3/
If current conditions have us running with 2000kbps pacing rate and
1250byte (10kbit) packets, each packet send time is 5ms.
The holdback window would then be min(20ms, 3*5ms) = 15ms.
The default is like before 1ms and packets no take into account when
TQ pacer is used, parameters have no effect with legacy process thread
pacer.
Bug: webrtc:10809
Change-Id: I800de05107e2d4df461eabaaf1ca04fb4c5de51e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/233421
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35266}
This is somewhat klugey, because it does the same checks at two
different layers in the stack, in different functions, which runs
the risk of making them out of sync. But it solves the immediate
problem.
Bug: chromium:1249753
Change-Id: I2ad96f0cc9499c15540ff6946a409b40df3e3925
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235826
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35259}
This CL includes two changes that break bit-exactness, but that haven't
changed the way AGC2 behaves - the new behavior has been verified with
audioproc_f on a collection of AEC dumps and Wav files (42 recordings
in total).
1) The fixed digital controller can directly be initialized in the
`GainController2` ctor. Before, `SetGainFactor()` was called after the
creation of the object and that caused an initial ramp up lasting one
10 ms frame from -inf to 0 dB. As an effect of the new initialization,
the initial ramp up doesn't happen anymore.
2) In [1] the AGC2 VAD has been moved from the adaptive digital
controller into `GainController2`. In order to not break bit-exactness,
the VAD was placed after the fixed digital controller and before the
adaptive digital one. However, to reduce the chance of incorrect
estimation of the speech probability, the VAD should analyze the
audio before any digital processing is applied inside AGC2.
[1] https://webrtc-review.googlesource.com/c/src/+/234583
Bug: webrtc:7494
Change-Id: I9418229cbe537014fed8271c5550c3ce2bc88e26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235240
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Hanna Silen <silen@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35252}
Bit exactness verified with audioproc_f on a collection of AEC dumps
and Wav files (42 recordings in total).
Bug: webrtc:7494
Change-Id: Id9849c4463791f5a203afe31efc163efb4d4458e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/234583
Reviewed-by: Hanna Silen <silen@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35248}
Only used in unit tests and a duplication of what `capture_output_rms_`
already does.
This CL also removes `AudioProcessingStats::output_rms_dbfs`, which is
now unused.
Bug: webrtc:5298
Fix: chromium:1261339
Change-Id: I6e583c11d4abb58444c440509a8495a7f5ebc589
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235664
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35246}
To be able to generate candidates the configuration must support at
least one of the following:
* enable acknowledged bitrate as a candidate,
* enable delay based bwe as a candidate, or
* enabled a candidate factor other than 1.0.
If none of the above is supported then the configuration will be marked
as invalid and thus the `LossBasedBweV2` will be disabled.
Bug: webrtc:12707
Change-Id: I836ee59a396497f577b34fe0650ffc79f6cadc31
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235210
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35239}
Also stop using ApplyConfig() and in [1] fix the build errors when
WEBRTC_EXCLUDE_AUDIO_PROCESSING_MODULE is defined.
[1] modules/audio_processing/test/audio_processing_builder_for_testing.cc
Bug: webrtc:5298
Change-Id: I50dc5668b952e7ca7fa83c7a5182c013e928c450
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235365
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35228}
This makes android bots fail and blocks chromium to webrtc roll: https://webrtc-review.googlesource.com/c/src/+/235484/. Unused variable was there for a while. This was probably triggered by Chromium enabling -Wunused-but-set-variable on the toolchain level.
Bug: b/203383377
Change-Id: I50e1c7852def90501694cba57d3a3611c2ffa149
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235377
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Andrey Logvin <landrey@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35226}
Not passing the sample rate to the `VoiceActivityDetectorWrapper` ctor
yet since that would require an unnecessary refactoring of `AdaptiveAgc`
which will soon be removed.
Instead, to ensure correct initialization until the child CL [1] lands,
`VoiceActivityDetectorWrapper::initialized_` is temporarily added.
Bit exactness verified with audioproc_f on a collection of AEC dumps
and Wav files (42 recordings in total).
[1] https://webrtc-review.googlesource.com/c/src/+/234583
Bug: webrtc:7494
Change-Id: I4b4be7b8106ba36c958d91bf263a7b30271a1ee3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/234587
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35213}
which can no longer happen since the end index and delta sizes are
checked in the surrounding condition.
Replace with a DCHECK to guard against potential errors.
BUG=None
Change-Id: I868d54c5923de773f248d10a40dbc6b2c563b0f1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231957
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@nvidia.com>
Cr-Commit-Position: refs/heads/main@{#35210}
