Instead explicitly ignore only the flags we know should be ignored.
BUG=webrtc:7568
Review-Url: https://codereview.webrtc.org/2968003003
Cr-Commit-Position: refs/heads/master@{#19412}
This test is the only remaining one that does not use gtest and that's
blocking some infra cleanup tasks. Ideally this test would use
webrtc/rtc_base/flags.h but that's a lot of unnecessary work.
This also replaces some exit() status codes - the logic behind this is
if you get incorrectly specified command line arguments, exit(1) is
invoked for a failure, because it's not a test failure, and if flag
parsing was done properly, it would not be a gtest failure anyway.
BUG=webrtc:7568
Review-Url: https://codereview.webrtc.org/3000033002
Cr-Commit-Position: refs/heads/master@{#19388}
I want to publish an API for iSAC in webrtc/api/, and I want to use
the class names Audio{De,En}coderIsac{Fix,Float}.
BUG=webrtc:7835, webrtc:7841
Review-Url: https://codereview.webrtc.org/2996593002
Cr-Commit-Position: refs/heads/master@{#19381}
Found via supersize query:
size_info.symbols.WhereFullNameMatches(r'\bk[A-Z]').WhereInSection('d')
This moves 90 symbols from .data -> .data.rel.ro (5.50kb)
BUG=chromium:747064
Review-Url: https://codereview.webrtc.org/2986163002
Cr-Commit-Position: refs/heads/master@{#19274}
I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
The only manual edit is to add an include of webrtc/rtc_base/checks.h in
webrtc/modules/audio_device/android/opensles_common.h, which likely
was needed due to changed include paths due to 'git cl format'.
BUG=webrtc:7634
NOTRY=True
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2969653002
Cr-Commit-Position: refs/heads/master@{#18871}
This header was not tracked by a GN target and in the discussion on
https://bugs.chromium.org/p/webrtc/issues/detail?id=7617 we decided
to also move it under webrtc/base.
I checked in chromium code search and it seems safe to move it
without creating a stub header in webrtc/system_wrappers.
BUG=webrtc:7617
Review-Url: https://codereview.webrtc.org/2882673002
Cr-Commit-Position: refs/heads/master@{#18151}
A DCHECK added in a recent bugfix, which asserted that a signed 64->32
bit cast did not overflow, has been found to not always pass. We fix
this by saturating.
BUG=chromium:693868
Review-Url: https://codereview.webrtc.org/2746903002
Cr-Commit-Position: refs/heads/master@{#17209}
In an attempt to help Kenny locate the evil Dr. Deo.
BUG=webrtc:7307
Review-Url: https://codereview.webrtc.org/2732193006
Cr-Commit-Position: refs/heads/master@{#17135}
A fuzzer run caused the operands of this multiplication to be 512 and
5000000, resulting in a product about 20% too large for int32_t. So
change this from a 16x32->32 to a 16x32->64 multiplication. Since we
right shift by 2 at the end, the end result will still fit in int32_t.
I also had to fix a few follow-on add/sub overflows found by the same
fuzzer input once the multiplication was fixed. I chose to saturate
these, since it wasn't just an intermediate value that overflowed.
BUG=chromium:693868
Review-Url: https://codereview.webrtc.org/2729573002
Cr-Commit-Position: refs/heads/master@{#17003}
A left shift by 10 was assumed to never overflow, since "[s]imulation
of the 25 files shows that maximum value in the vector gain_lo_hiQ17[]
is 441344, which means that it is log2((2^31)/441344) = 12.2 shifting
bits from saturation." However, a fuzzer test succeeded in provoking
an overflow, which we ignore in this CL on the theory that only
"abnormal" inputs cause overflow.
Also had to replace a "foo << 1" with "foo * (1 << 1)" in
WEBRTC_SPL_MUL_16_32_RSFT15 because foo could be negative; this
problem showed up as soon as I'd asked UBSan to ignore the overflow
discussed above.
BUG=chromium:615819
Review-Url: https://codereview.webrtc.org/2314413002
Cr-Commit-Position: refs/heads/master@{#14162}
We have RTC_CHECK and RTC_DCHECK for C now, so we should use it. It's
one fewer difference between our C and C++ code.
NOPRESUBMIT=true
Review-Url: https://codereview.webrtc.org/2274083002
Cr-Commit-Position: refs/heads/master@{#13930}
I've settled on replacing x << n with x * (1 << n); this gets rid of
the "left shift of negative value" warning, but will still trigger
undefined behavior if the multiplication overflows. It also still
looks like a left shift, which is good for the readability of the
fixed-point code.
(The compiler is smart enough to recognize that the
multiplication+shift is just a shift, for both variable and constant
shift amounts, so the generated code should not change.)
BUG=chromium:603491
Review-Url: https://codereview.webrtc.org/1989803002
Cr-Commit-Position: refs/heads/master@{#12845}
Chrome does not detect NEON instruction set at runtime in WebRTC code starting
with M50, which is now in Stable. Remove support for runtime detection for
simplicity.
The only remaining piece of Chrome that will continue to depend on runtime
detection is /net, where devices with _broken_ neon support are also detected,
and it is not configurable via GYP/GN.
BUG=522035
NOPRESUBMIT=true
Review-Url: https://codereview.webrtc.org/1955413003
Cr-Commit-Position: refs/heads/master@{#12778}
The problem with gmock is worked around by commenting out any other override declarations in classes using gmock.
NOPRESUBMIT=True
BUG=webrtc:3970
Review-Url: https://codereview.webrtc.org/1921653002
Cr-Commit-Position: refs/heads/master@{#12563}
WebRtcIsacfix_PitchFilterCore requires indW32 >= PITCH_FRACORDER - 2;
otherwise, it will read from entries of ubufQQ that haven't been
written yet. (The problem of indW32 being too small has only been seen
in fuzzer tests, not in real life.)
BUG=chromium:581901
Review URL: https://codereview.webrtc.org/1811453002
Cr-Commit-Position: refs/heads/master@{#12047}
By doing an unsigned instead of a signed addition, we get the exact
same machine code (in non-UBSan builds), but no longer trigger
undefined behavior since unsigned overflow is defined behavior.
BUG=webrtc:5485
Review URL: https://codereview.webrtc.org/1734883003
Cr-Commit-Position: refs/heads/master@{#11776}
* Better param names
* Avoid using negative values for (bogus) placeholder channel counts (mostly in tests). Since channels will be changing to size_t, negative values will be illegal; it's sufficient to use 0 in these cases.
* Use arraysize()
* Use size_t for counting frames, samples, blocks, buffers, and bytes -- most of these are already size_t in most places, this just fixes some stragglers
* reinterpret_cast<int64_t>(void*) is not necessarily safe; use uintptr_t instead
* Remove unnecessary code, e.g. dead code, needlessly long/repetitive code, or function overrides that exactly match the base definition
* Fix indenting
* Use uint32_t for timestamps (matching how it's already a uint32_t in most places)
* Spelling
* RTC_CHECK_EQ(expected, actual)
* Rewrap
* Use .empty()
* Be more pedantic about matching int/int32_t/
* Remove pointless consts on input parameters to functions
* Add missing sanity checks
All this was found in the course of constructing https://codereview.webrtc.org/1316523002/ , and is being landed separately first.
BUG=none
TEST=none
Review URL: https://codereview.webrtc.org/1534193008
Cr-Commit-Position: refs/heads/master@{#11191}
Currently, it's sitting in AudioEncoderIsac*'s files, which is less
than obvious. This CL puts the encoder and decoder in separate files
together with the C implementation; CLs are afoot to make it so for
the other built-in codecs as well.
BUG=webrtc:4557
R=henrik.lundin@webrtc.org
Review URL: https://codereview.webrtc.org/1339253003 .
Cr-Commit-Position: refs/heads/master@{#10018}
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition.
Alternative solutions:
* Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable.
* Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce.
* Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable.
* Changes in Chromium for this is obviously not an option.
BUG=chromium:468375
NOTRY=true
Review URL: https://codereview.webrtc.org/1335923002
Cr-Commit-Position: refs/heads/master@{#9964}
It makes more sense to combine the two interfaces, since there wasn't
a clear line separating them. The result is a combined interface with
just over a dozen methods, half of which need to be implemented by
every subclass, while the other half have sensible (and trivial)
default implementations and are implemented only by the few subclasses
that need non-default behavior.
Review URL: https://codereview.webrtc.org/1322973004
Cr-Commit-Position: refs/heads/master@{#9894}
The Init() method was previously used to initialize and reset
decoders, and returned an error code. The new Reset() method is used
for reset only; the constructor is now responsible for fully
initializing the AudioDecoder.
Reset() doesn't return an error code; it turned out that none of the
functions it ended up calling could actually fail, so this CL removes
their error return codes as well.
R=henrik.lundin@webrtc.org
Review URL: https://codereview.webrtc.org/1319683002 .
Cr-Commit-Position: refs/heads/master@{#9798}
The only shared state is now the bandwidth estimation info.
This reduces the amount and complexity of the locking
substantially.
Review URL: https://codereview.webrtc.org/1208993010
Cr-Commit-Position: refs/heads/master@{#9762}
WebRtcIsacfix_AllpassFilter2FixDec16Neon was disabled due to a Clang
bug. The bug is fixed in current Clang version, re-enable it in this patch.
BUG=4567
R=andrew@webrtc.org, kjellander@webrtc.org
TEST=buildbot build
Change-Id: I71e309cec6caf376181cf9c299c9e8967c9a328e
Review URL: https://codereview.webrtc.org/1194773002 .
Patch from Zhongwei Yao <zhongwei.yao@arm.com>.
Cr-Commit-Position: refs/heads/master@{#9645}
These are mostly trivial changes and are separated out just to reduce the
diff on that change to the minimum possible.
Note explanatory comments on patch set 1.
BUG=none
TEST=none
Review URL: https://codereview.webrtc.org/1235643003
Cr-Commit-Position: refs/heads/master@{#9617}
This patch tests separate iSAC encoder and decoder in more cases (32
kHz in addition to 16 kHz, and 30 ms adaptive and 60 ms nonadaptive).
In order to handle 32 kHz adaptive, the decoder needs to be told of
the encoder's sample rate (16 kHz worked already because that's the
default). And since we can't set the encoder's frame size without also
setting its bit rate, we need a way to set the decoder's bit rate as
well.
It turned out to be way too messy to continue verifying that the
bandwidth estimator does something reasonable in all these cases,
because it seems it doesn't. So the GetSetBandwidthInfo is now just
responsible for ensuring that split encoder/decoder behaves the same
as conjoined encoder/decoder; the job of verifying that the bandwidth
estimator does its job properly falls on some other test (that doesn't
exist yet).
Review URL: https://codereview.webrtc.org/1225093005
Cr-Commit-Position: refs/heads/master@{#9583}
They make it possible to send bandwidth estimation info from decoder
to encoder even if they are separate objects (which we want them to be
because multithreading).
R=henrik.lundin@webrtc.org
Review URL: https://codereview.webrtc.org/1208923002.
Cr-Commit-Position: refs/heads/master@{#9535}
Before this change, it could happen that a caller would get a pointer
to the encoder_ but not use it before another thread called the
Reconstruct method, changing the pointer. This of course resulted in
bad access crashes. With this change, each use of the pointer acquired
from the encoder() method is protected by the same lock that is
required to update the pointer. Note that this fix is probably too
aggressive, since it also affects the Opus implementation; the crash
has so far only been seen for iSAC.
Also adding a test to trigger the problem. The test did not trigger
the problem deterministically, but out would typically find it in less
than 1000 runs.
BUG=chromium:499468
R=jmarusic@webrtc.org, kwiberg@webrtc.org
Review URL: https://codereview.webrtc.org/1176303004.
Cr-Commit-Position: refs/heads/master@{#9436}
Fix AppRTCDemo crash under iOS due to the unaligned access in vld1
instruction in iSACFix codec, which is not allowed in iOS build.
BUG=4717
R=andrew@webrtc.org, jridges@masque.com
TEST=Run the AppRTCDemo
Change-Id: Ie5fbc9b8ae88cd00b243a8e65cab95b00362a9da
Review URL: https://codereview.webrtc.org/1182493006.
Cr-Commit-Position: refs/heads/master@{#9432}
