The biggest change to NetEq is the move from a primary flag, to a
Priority with two separate levels: one set by RED splitting and one
set by the codec itself. This allows us to unambigously prioritize
"fallback" packets from these two sources. I've chosen what I believe
is the sensible ordering: packets that the codec prioritizes are
chosen first, regardless of if they are secondary RED packets or
not. So if we were to use Opus w/ FEC in RED, we'd only do Opus FEC
decoding if there was no RED packet that could cover the time slot.
With this change, PayloadSplitter now only deals with RED
packets. Maybe it should be renamed RedPayloadSplitter?
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2342443005
Cr-Commit-Position: refs/heads/master@{#14347}
audio_decoder.cc depends on LegacyEncodedAudioFrame and
LegacyEncodedAudioFrame depends on AudioDecoder::EncodedAudioFrame, so
there's no clear way to separate them as of now. This error is also
hodling up builds downstream. I expect we'll revisit these
dependencies as part of the upcoming larger restructuring effort.
NOTRY=true
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2359763002
Cr-Commit-Position: refs/heads/master@{#14329}
There's still some code run specifically for Opus w/ FEC. It will be
addressed in a separate CL.
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2326003002
Cr-Commit-Position: refs/heads/master@{#14319}
It allows the decoder to split the input up into usable chunks before
they are put into NetEq's PacketBuffer. Eventually, all packet splitting
will move into ParsePayload.
There's currently a base implementation of ParsePayload. It will
generate a single Frame that calls the underlying AudioDecoder for
getting Duration() and to Decode.
BUG=webrtc:5805
BUG=chromium:428099
Review-Url: https://codereview.webrtc.org/2326953003
Cr-Commit-Position: refs/heads/master@{#14300}
Remove a large number of targets that are no longer built, to reduce maintenance.
Only targets that have a GN version were removed.
BUG=webrtc:6323
NOTRY=True
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2340773003
Cr-Commit-Position: refs/heads/master@{#14231}
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}
The sample uses are from when I debugged bug 617124. The change in neteq_network_stats_unittest.cc is a fix for a minor unrelated bug found by the try bots when I tried to land this CL (a test was passing uninitialized packet data to NetEq).
BUG=chromium:617124
Review-Url: https://codereview.webrtc.org/2293893002
Cr-Commit-Position: refs/heads/master@{#14034}
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}
We detect an unreasonable state (caused by a bad encoded stream)
before it can lead to problems, and handle it by resetting the
decoder.
NOPRESUBMIT=true
BUG=chromium:617124
Review-Url: https://codereview.webrtc.org/2255203002
Cr-Commit-Position: refs/heads/master@{#13888}
So that we don't have to use assert(). Includes one sample call site.
NOTRY=true
BUG=chromium:617124
Review-Url: https://codereview.webrtc.org/2262173002
Cr-Commit-Position: refs/heads/master@{#13862}
scale1 == 31 if and only if w10 == 0. So even though 1 << scale1
overflows, we know that the result of the multiplication should be 0.
Handle that case.
BUG=chromium:615818
Review-Url: https://codereview.webrtc.org/2258543002
Cr-Commit-Position: refs/heads/master@{#13847}
Reland of https://codereview.webrtc.org/2072753002/ which broke
chromium due to how their build was setup. This issue should now be
resolved.
Changed WebRtcVoiceEngine to present receive codecs from the formats
provided by its decoder factory. Added supported formats to
BuiltinAudioDecoderFactory. Added helper functions for creating some
simple decoder factories for mocking.
Created a PayloadTypeMapper for assigning payload types to formats. I
think we'll eventually want to use this further up, or possibly in
both the audio and video sides. It would be best if the engines didn't
have to talk payload types at all, but it might be more difficult to
get around when payload types depend on each-other, like the RTX
codecs for video.
BUG=webrtc:5805
TBR=ivoc@webrtc.org
Review-Url: https://codereview.webrtc.org/2250683002
Cr-Commit-Position: refs/heads/master@{#13793}
Reason for revert:
For some reason, payload_type_mapper.cc is not being picked up in Chrome builds, leading to undefined references. Reverting while investigating.
Original issue's description:
> WebRtcVoiceEngine: Use AudioDecoderFactory to generate recv codecs.
>
> Changed WebRtcVoiceEngine to present receive codecs from the formats
> provided by its decoder factory. Added supported formats to
> BuiltinAudioDecoderFactory. Added helper functions for creating some
> simple decoder factories for mocking.
>
> Created a PayloadTypeMapper for assigning payload types to formats. I
> think we'll eventually want to use this further up, or possibly in
> both the audio and video sides. It would be best if the engines didn't
> have to talk payload types at all, but it might be more difficult to
> get around when payload types depend on each-other, like the RTX
> codecs for video.
>
> This CL also includes some changes to rtc::Optional. I've put them in
> a separate CL that should (or should not) land first, making these
> changes void.
> See: https://codereview.webrtc.org/2072713002/
>
> BUG=webrtc:5805
>
> Committed: https://crrev.com/95eb1ba0db79d8fd134ae61b0a24648598684e8a
> Cr-Commit-Position: refs/heads/master@{#13459}
TBR=ivoc@webrtc.org,tina.legrand@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2151453002
Cr-Commit-Position: refs/heads/master@{#13460}
Changed WebRtcVoiceEngine to present receive codecs from the formats
provided by its decoder factory. Added supported formats to
BuiltinAudioDecoderFactory. Added helper functions for creating some
simple decoder factories for mocking.
Created a PayloadTypeMapper for assigning payload types to formats. I
think we'll eventually want to use this further up, or possibly in
both the audio and video sides. It would be best if the engines didn't
have to talk payload types at all, but it might be more difficult to
get around when payload types depend on each-other, like the RTX
codecs for video.
This CL also includes some changes to rtc::Optional. I've put them in
a separate CL that should (or should not) land first, making these
changes void.
See: https://codereview.webrtc.org/2072713002/
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/2072753002
Cr-Commit-Position: refs/heads/master@{#13459}
If the specification for the speech encoder hasn't changed, we should
reuse it instead of recreating it. Otherwise, we lose its state. (This
problem was originally discovered because AudioEncoderOpus instances
would forget that they were supposed to be using DTX.)
BUG=webrtc:6020, chromium:622647
Review-Url: https://codereview.webrtc.org/2089183002
Cr-Commit-Position: refs/heads/master@{#13273}
We didn't really want it; it was only necessary because we wanted to
use rtc::Optional<SdpAudioFormat>, and Optional used to require the
contained type to be default constructable. But as of May 9th
(https://codereview.webrtc.org/1896833004), it no longer does.
Review-Url: https://codereview.webrtc.org/2066233002
Cr-Commit-Position: refs/heads/master@{#13211}
And implement SampleRateHz in a bunch of mocks.
BUG=webrtc:5801
NOTRY=true
Review-Url: https://codereview.webrtc.org/2029543002
Cr-Commit-Position: refs/heads/master@{#13161}
WebRtcSpl_CrossCorrelation and WebRtcSpl_DotProductWithScale compute
the int32 sum of pairwise products from two int16 arrays. So as to
avoid overflow (which could otherwise happen when as little as two
products were summed), the products are right-shifted by an amount
specified by the caller.
This CL changes WebRtcIlbcfix_MyCorr and WebRtcIlbcfix_Smooth to give
sufficient right-shift amounts, instead of ones that may be too small
and cause overflow.
BUG=chromium:601787
Review-Url: https://codereview.webrtc.org/2014033002
Cr-Commit-Position: refs/heads/master@{#13066}
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}
When this class was created, we inadvertently set the default to 64
kbit/s for both cases, failing to preserve the previous behavior. This
patch restores the old behavior.
From what I've been able to dig up, this problem did not affect Opus
encoders created internally in the Audio Coding Module. Those have
always used the bitrate from the supplied CodecInst.
Review-Url: https://codereview.webrtc.org/1942193002
Cr-Commit-Position: refs/heads/master@{#12827}
First step of AudioDecoderFactory injection CLs. AudioDecoderFactories will be shared, and shared_ptr is currently off the table, so this CL changes the current uses of AudioDecoderFactory from std::unique_ptr to rtc::scoped_refptr.
BUG=webrtc:5805
Review-Url: https://codereview.webrtc.org/1990803004
Cr-Commit-Position: refs/heads/master@{#12815}
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}
This is the last step in changing the signature of AudioEncoder::Encode
to taking an rtc::Buffer as its output parameter, rather than a pointer
to and a size parameter.
The notry parameter has been added specifically to work around android_compile_x86_dbg bot failing.
NOTRY=True
BUG=webrtc:5591
Review-Url: https://codereview.webrtc.org/1962013003
Cr-Commit-Position: refs/heads/master@{#12685}
