We use Optional in our public API, so its header should be in
webrtc/api/.
BUG=webrtc:8205
Review-Url: https://codereview.webrtc.org/3011943002
Cr-Commit-Position: refs/heads/master@{#19693}
This is done to make UBSan testing more convenient in integration with projects using WebRTC
Some blacklist entries were obsolete so don't need a replacement
Also fix one of the warnings (thanks, kwiberg@)
BUG=webrtc:8189, webrtc:5486, webrtc:5491
Review-Url: https://codereview.webrtc.org/3009123002
Cr-Commit-Position: refs/heads/master@{#19682}
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}
Plumbed AudioEncoderFactory up into CreatePeerConnectionFactory.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2799033006
Cr-Commit-Position: refs/heads/master@{#17977}
With the upcoming changes to WebRtcVoiceEngine due to injectable audio
encoders, codec names will no longer be normalized against the ACM's
codec database. This not only breaks a couple of downstream tests
(which I've written fixes for) but also runs the risk of breaking
other external usage, like SDP mangling etc.
Eventually, we should change to using the spelling from the relevant
RFCs, although not as part of this other, large change.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2845603002
Cr-Commit-Position: refs/heads/master@{#17903}
This CL contains all the changes made to audio_coding while making
audio encoders injectable. Apart from some small changes to
webrtcvoiceengine, nothing here is hooked up to the outside
world. Those changes will be added to a follow-up CL.
BUG=webrtc:5806
Review-Url: https://codereview.webrtc.org/2695243005
Cr-Commit-Position: refs/heads/master@{#17569}
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}
We read past the end of the initialized part of the buffer, seemingly
on purpose (no one knows the details of this code anymore). The right
thing to do is probably to zero that part of the buffer.
(The *right* right thing to would be to rewrite this so that it was
easier to see what data was supposed to be where when, but
priorities...)
BUG=chromium:683040
Review-Url: https://codereview.webrtc.org/2659383002
Cr-Commit-Position: refs/heads/master@{#16365}
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 hit a fuzzer bug that caused numDecodedBytesLB + numDecodedBytesUB
> lenEncodedBytes, which is obviously bogus. Check for that, and for
the case whhere the UB decoder itself realized that something was
wrong. (The code already makes the corresponding check for the LB
decoder.)
BUG=chromium:637899
Review-Url: https://codereview.webrtc.org/2315693002
Cr-Commit-Position: refs/heads/master@{#14091}
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}
This gets rid of the complex & icky state where the sample rate is not
yet determined.
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2020353003
Cr-Commit-Position: refs/heads/master@{#13011}
This will let NetEq (and the factory, and every layer in between) keep
track of just the decoder, instead of decoder and sample rate.
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2024633002
Cr-Commit-Position: refs/heads/master@{#12968}
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}
Any file that uses the RTC_DISALLOW_* macros should #include
"webrtc/base/constructormagic.h", but a shocking number of them don't.
This causes trouble when we try to wean files off of #including
scoped_ptr.h, since a bunch of files get their constructormagic macros
only from there.
Rather than fixing these errors one by one as they turn up, this CL
simply ensures that every file in the WebRTC tree that uses the
RTC_DISALLOW_* macros #includes "webrtc/base/constructormagic.h".
BUG=webrtc:5520
Review URL: https://codereview.webrtc.org/1917043005
Cr-Commit-Position: refs/heads/master@{#12509}
Remove the deprecated EncodeInternal interface from AudioEncoder
Also hid MaxEncodedBytes by making it private. It will get removed as soon as subclasses have had time to remove their overrides.
BUG=webrtc:5591
Review URL: https://codereview.webrtc.org/1881003003
Cr-Commit-Position: refs/heads/master@{#12409}
Reason for revert:
Broke import. Implementations of the old interface still exists somewhere.
Original issue's description:
> Remove the deprecated EncodeInternal interface from AudioEncoder
>
> Also hid MaxEncodedBytes by making it private. It will get removed as soon as subclasses have had time to remove their overrides.
>
> BUG=webrtc:5591
>
> Committed: https://crrev.com/5222d315dbea8f3563c100cc9f2451907f70b05f
> Cr-Commit-Position: refs/heads/master@{#12329}
TBR=kwiberg@webrtc.org,solenberg@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5591
Review URL: https://codereview.webrtc.org/1883543002
Cr-Commit-Position: refs/heads/master@{#12330}
