Fix the following issues with fuzz targets when built on Windows:
1. Fix audio_processing_fuzzer by making types match in
invocations of CheckedDivExact by explicitly casting to size_t.
2. Fix packet_buffer_fuzzer by including "frame_object.h" for
declaration of RtpFrameObject.
3. Fix rtcp_receiver_fuzzer by including "tmmb_item.h" for declaration
of TmmbItem.
Bug: chromium:891867
Change-Id: Iddc338360ca37d5fc31488ec908eb4cdb5cc7b94
Reviewed-on: https://webrtc-review.googlesource.com/c/103844
Commit-Queue: Jonathan Metzman <metzman@chromium.org>
Reviewed-by: Alex Loiko <aleloi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25028}
This is quite useful in many places where we need to restrict the range
of a DataRate. It makes it easier to read the intention than with:
value_ = std::max(some_lower_limit, std::min(value_, some_upper_limit));
The naming follows the naming for rtc::SafeClamp.
Bug: webrtc:9709
Change-Id: I08e05197acec325d85babd2a06806a8667f2fcb1
Reviewed-on: https://webrtc-review.googlesource.com/c/104040
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25023}
Original CL: https://webrtc-review.googlesource.com/c/src/+/101340
A (actually several weeks) while ago, we noticed an error with the
WebRTC.Audio.Agc2.EstimatedNoiseLevel histogram. It always reported
the value 0. Here is why:
The histogram bins go from 0 to 100. But the value logged is dBFS. It
is always less than or equal to 0. This CL changes inverts the value
logged. The noise level value should be somewhere between -90 and 0
dBFS.
The histogram description is updated in
https://chromium-review.googlesource.com/c/chromium/src/+/1264578
Bug: webrtc:7494
Change-Id: I0b53630d4284ce1078fd453e05e89ee53ca9f6c7
Reviewed-on: https://webrtc-review.googlesource.com/c/104063
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Alex Loiko <aleloi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25021}
This also moves the packet feedback tracking to RtpVideoSender.
Bug: webrtc:9517
Change-Id: Ifb1ff85051730108a0b0d1dd30f6f8595ad2af6e
Reviewed-on: https://webrtc-review.googlesource.com/c/95920
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25019}
This code is much more sophisticated in that it doesn't rely
on argv[0], but rather asks the OS where our executable is.
We can then simply go two steps up since we count on running
in out/Whatever relative to the src dir. This is how Chromium
does it.
The aim here is to get rid of SetExecutablePath, which will
be the next CL.
Bug: webrtc:9792
Change-Id: I7da027b7391e759b1f612de12f27a244fe884c09
Reviewed-on: https://webrtc-review.googlesource.com/c/103121
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Patrik Höglund <phoglund@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25017}
Also rename runningOnLollipopOrHigher() etc in WebRtcAudioUtils
to runningOnApi21OrHigher() etc since mapping API numbers to
names is error prone.
Bug: webrtc:9818
Change-Id: I4a71de72e3891ca2b6fc2341db9131bb2db4cce7
Reviewed-on: https://webrtc-review.googlesource.com/c/103820
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Paulina Hensman <phensman@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25009}
The AdaptiveAgc often boosts the signal outside of Float S16 range. It
is expected, which is why we have a limiter after it in the process
chain. But it turns out that this happens regularly even for simple
input examples. The output signal peaks can be as high as +4 dBFs for a
single speaker example (which should be easy). It leads to excessive
gain modulation by the limiter.
This CL is a new tuning designed to produce a safer gain. After this,
we shouldn't hit the saturation region of the limiter as often. But we
will still maintain a high gain.
We have a 'configurable kill-switch': the settings can be changed via
field trials WebRTC-Audio-Agc2Force(Initial|Extra)SaturationMargin.
Bug: webrtc:7494, chromium:892043
Change-Id: I5014377050c74c32ae8998282991141eae31cf58
Reviewed-on: https://webrtc-review.googlesource.com/c/102922
Commit-Queue: Alex Loiko <aleloi@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25006}
Automatic detection if one-byte header or two-byte header should be used based
on extension ID and extension length.
Bug: webrtc:7990
Change-Id: I9fc848ecc59458d1ca97bace0e57ea04d3d0ced6
Reviewed-on: https://webrtc-review.googlesource.com/c/103422
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25004}
The inclusion of <memory.h> creates problems when building with Chromium
third_party/webrtc/rtc_base/memory/aligned_malloc.cc:13:10:
fatal error: 'memory.h' file not found
#include <memory.h>
It seems the code doesn't need to include <memory.h> but <cstring>.
Bug: None
Change-Id: Ib6591711aa7cfea49a2ff08321cfb3bd3689797a
Reviewed-on: https://webrtc-review.googlesource.com/c/103980
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25003}
This change integrates the FrameDecryptorInterface and the FrameEncryptorInterface into
the audio media path. If a FrameEncryptorInterface is set on an outgoing audio RTPSender
then each outgoing audio payload will first pass through the provided FrameEncryptor which
will have a chance to modify the payload contents for the purposes of encryption.
If a FrameDecryptorInterface is set on an incoming audio RtpReceiver then each incoming
audio payload will first pass through the provided FrameDecryptor which have a chance to
modify the payload contents for the purpose of decryption.
While AEAD is supported by the FrameDecryptor/FrameEncryptor interfaces this CL does not
use it and so it is left as null.
Bug: webrtc:9681
Change-Id: Ic383a9dce280528739f9d271357c2220e0a0dccf
Reviewed-on: https://webrtc-review.googlesource.com/c/101702
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Emad Omara <emadomara@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25001}
If layers have been enabled or disabled, send immediate instead of on
next available report.
Bug: webrtc:9823
Change-Id: Ifd774641d4b8c03a9efa8ad48ff5e88328ed2ba9
Reviewed-on: https://webrtc-review.googlesource.com/c/103802
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24997}
This CL introduces a major refactoring of AecState for the purpose of
simplifying further improvements to the logic in this code.
The changes have successfully been tested for bitexactness.
Bug: webrtc:8671
Change-Id: If98efde55a22c76b093089a11a0562daac7e16e6
Reviewed-on: https://webrtc-review.googlesource.com/c/102362
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24996}
And also drop dependency on module_api, where possible. With this
change, common_video/ no longer depends on
libjingle_peerconnection_api.
Bug: None
Change-Id: Icc0648559bef5b7f549e81d58f2a5f97c0af3abf
Reviewed-on: https://webrtc-review.googlesource.com/c/103782
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24991}
Add checks to ensure encoder is not used below API level 19. Removes
global @TargetApi from MediaCodecUtils since it is also used by the
decoder. Ensures that texture mode is never enabled below API level 18.
Bug: webrtc:9821
Change-Id: I2ca1014bf8995719c970eb1449b0acbf7b3c883e
Reviewed-on: https://webrtc-review.googlesource.com/c/103701
Reviewed-by: Paulina Hensman <phensman@webrtc.org>
Commit-Queue: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24990}
This name will better describe what implementation should do and how
users will interact with this class. The real simulation is done
by FakeNetworkPipe and this class is just operates with packages
metadata, so it is more about describing behavior.
Bug: webrtc:9630
Change-Id: I00977e6be0ca84e7c233b4c35f0677e8263e4382
Reviewed-on: https://webrtc-review.googlesource.com/c/95944
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24989}
- Added field trial to force issuing of key frame on deactivation of
spatial layer. This fixes video corruptions in VP9 K-SVC tests where
layers can be activated/deactivated on-fly due to bandwidth change.
- Added 100ms network delay to the test with restricted link capacity.
This fixes rapid drop of available bandwidth which happens when
bandwidth overuse is detected in the very beginning of call and several
feedback packets arrive without any delay. Also, this makes the test
more realistic.
- Disabled filtering of spatial layer in the test with restricted
link capacity. 1) We don't really need filtering in this test.
2) It appeared that in video quality tests filtering is done before
sending packets to network simulator. Filtering of high layers causes
channel underuse which is compensated by increase of sent bitrate.
This is why we got sent/media bitrates about 2Mbps in test where link
was limited to 1Mbps.
Bug: chromium:889017
Change-Id: I33ffcee0274523f6183c3bbd27d3d29395417d52
Reviewed-on: https://webrtc-review.googlesource.com/c/103520
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24988}
Some important NetEq information was not available in NetEqState, which
meant it was not available on the API. This CL adds additional
information.
Bug: webrtc:9667
Change-Id: I702707c7d60472f488047d48fb286f839c5608dc
Reviewed-on: https://webrtc-review.googlesource.com/c/102300
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24985}
