NetEQ can crash when decoder gives too many output samples than it can handle. A practical case this happens is when multiple opus packets are combined.
The best solution is to pass the max size to the ACM decode function and let it return a failure if the max size if too small.
BUG=4361
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45619004
Cr-Commit-Position: refs/heads/master@{#8730}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8730 4adac7df-926f-26a2-2b94-8c16560cd09d
The macro is in C defined as
#define WEBRTC_SPL_MUL_16_16(a, b) ((int32_t) (((int16_t)(a)) * ((int16_t)(b))))
(For definition on ARMv7 and MIPS, see
common_audio/signal_processing/include/spl_inl_armv7.h and
common_audio/signal_processing/include/spl_inl_mips.h)
The replacement consists of
- avoiding casts to int16_t if inputs already are int16_t
- adding explicit cast to <type> if result is assigned to <type> (other than int
or int32_t)
Some other minor code cleanup also exists.
BUG=3348,3353
TESTED=locally on Mac and trybots
R=henrik.lundin@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/42639004
Cr-Commit-Position: refs/heads/master@{#8717}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8717 4adac7df-926f-26a2-2b94-8c16560cd09d
The current way that iSAC RCU is packetized and sent as a RED packet,
with the same payload type for primary and redundant payloads, does
not follow the specification for RED. As it is now, it is impossible
for a receiver to know if an incoming RED packet with iSAC payloads
inside consists of two "primary" (but time-shifted) payloads, or one
primary and one RCU payload. The RED standard stipulates that the
former option is the correct interpretation, while our implementation
currently applies the latter.
This CL removes support for iSAC RCU from Audio Coding Module, but
leaves it in the iSAC codec itself (i.e., in the C implementation).
BUG=4402
COAUTHOR=kwiberg@webrtc.orgR=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45569004
Cr-Commit-Position: refs/heads/master@{#8713}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8713 4adac7df-926f-26a2-2b94-8c16560cd09d
Added method AudioEncoder::MaxEncodedBytes() and provided implementations in derived encoders. This method returns the number of bytes that can be produced by the encoder at each Encode() call.
Unit tests were updated to use the new method.
Buffer allocation was not changed in AudioCodingModuleImpl::Encode(). It will be done after additional investigation.
Other refactoring work that was done, that may not be obvious why:
1. Moved some code into AudioEncoderCng::EncodePassive() to make it more consistent with EncodeActive().
2. Changed the order of NumChannels() and RtpTimestampRateHz() declarations in AudioEncoderG722 and AudioEncoderCopyRed classes. It just bothered me that the order was not the same as in AudioEncoder class and its other derived classes.
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/40259005
Cr-Commit-Position: refs/heads/master@{#8671}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8671 4adac7df-926f-26a2-2b94-8c16560cd09d
Passed building isac_neon and modules_unittests on Android ARM64 and ARMv7.
Passed modules_unittests with following filters:
--gtest_filter=FiltersTest*
--gtest_filter=LpcMaskingModelTest*
--gtest_filter=TransformTest*
--gtest_filter=FilterBanksTest*
WebRtcIsacfix_CalculateResidualEnergyNeon is not enabled due to Issue 4224.
BUG=4002
R=andrew@webrtc.org, jridges@masque.com, kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/39979004
Patch from Zhongwei Yao <zhongwei.yao@arm.com>.
Cr-Commit-Position: refs/heads/master@{#8632}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8632 4adac7df-926f-26a2-2b94-8c16560cd09d
Clang version changed 223108:230914
Details: e144d30..6fdb142/tools/clang/scripts/update.sh
Removes the OVERRIDE macro defined in:
* webrtc/base/common.h
* webrtc/typedefs.h
The majority of the source changes were done by running this in src/:
perl -0pi -e "s/virtual\s([^({;]*(\([^({;]*\)[^({;]*))(OVERRIDE|override)/\1override/sg" `find {talk,webrtc} -name "*.h" -o -name "*.cc*" -o -name "*.mm*"`
which converted all:
virtual Foo() OVERRIDE
functions to:
Foo() override
Then I manually edited:
* talk/media/webrtc/fakewebrtccommon.h
* webrtc/test/fake_common.h
Remaining uses of OVERRIDE was fixed by search+replace.
Manual edits were done to fix virtual destructors that were
overriding inherited ones.
Finally a build error related to the pure virtual definitions of
Read, Write and Rewind in common_types.h required a bit of
refactoring in:
* webrtc/common_types.cc
* webrtc/common_types.h
* webrtc/system_wrappers/interface/file_wrapper.h
* webrtc/system_wrappers/source/file_impl.cc
This roll should make it possible for us to finally re-enable deadlock
detection for TSan on the buildbots.
BUG=4106
R=pbos@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41069004
Cr-Commit-Position: refs/heads/master@{#8596}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8596 4adac7df-926f-26a2-2b94-8c16560cd09d
This should be safe to land now that issue 4143 was resolved (in r8492).
This change effectively reverts 8488.
TBR=kwiberg@webrtc.org
Original commit message:
This CL changes the way the decoder sample rate is set and updated. In
practice, it only concerns the iSAC (float) codec.
One single iSAC decoder instance is used for both wideband and
super-wideband decoding, and the instance must be told to switch
output frequency if the payload type changes. This used to be done
through a call to UpdateDecoderSampleRate, but is now instead done in
the Decode call as an extra parameter.
Review URL: https://webrtc-codereview.appspot.com/39289004
Cr-Commit-Position: refs/heads/master@{#8496}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8496 4adac7df-926f-26a2-2b94-8c16560cd09d
Without this patch, Valgrind's Memcheck was complaining that the test
for whether we should return -1 following the call to
WebRtcIsac_DecodeLb made a conditional branch or move based on the
value of numSamplesLB, which was uninitialized if WebRtcIsac_DecodeLb
failed.
However, as can be seen in the source, the control flow only depends
on the value of numSamplesLB if numDecodedBytesLB >= 0; i.e., if
WebRtcIsac_DecodeLb returned successfully, in which case numSamplesLB
is always initialized. The discrepancy is due to the fact that
Valgrind works on the generated machine code, which contains spurious
such dependencies. The generated code for this test:
if ((numDecodedBytesLB < 0) || (numDecodedBytesLB > lenEncodedLBBytes) ||
(numSamplesLB > MAX_FRAMESAMPLES)) {
looks like this:
95: 0f bf 45 d6 movswl -0x2a(%rbp),%eax
99: 3d c0 03 00 00 cmp $0x3c0,%eax
9e: 0f 8f 45 01 00 00 jg 1e9 <Decode+0x1e9>
a4: 44 89 f0 mov %r14d,%eax
a7: c1 e0 10 shl $0x10,%eax
aa: 0f 88 39 01 00 00 js 1e9 <Decode+0x1e9>
b0: 41 0f bf ce movswl %r14w,%ecx
b4: 89 8d 98 e1 ff ff mov %ecx,-0x1e68(%rbp)
ba: 41 0f bf c7 movswl %r15w,%eax
be: 39 c1 cmp %eax,%ecx
c0: 0f 8f 23 01 00 00 jg 1e9 <Decode+0x1e9>
Note how the compiler has seemingly ignored the C language's guarantee
that the arguments to || must be evaluated in left-to-right order, and
compares numSamplesLB (%eax) with MAX_FRAMESAMPLES (0x3c0, a.k.a. 960)
before the other two conditions! If the uninitialized value in
numSamplesLB happens to be greater than 960, we'll jump to
Decode+0x1e9 (where we'll return -1) without even looking at the other
two conditions. Has the compiler generated broken code?
Well, no. If numDecodedBytesLB is < 0 so that numSamplesLB is
uninitialized, we'll end up jumping to 1e9 whether that value is
greater than 960 or not; we'll just do it with different jump
instructions. This is entirely invisible as far as the C language is
concerned, but the dependency on the uninitialized value is visible at
the machine code level, which is why Memcheck complains.
This patch solves the problem by pragmatically initializing
numSamplesLB before the call even though it isn't necessary other than
for placating Memcheck.
BUG=4143
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/36309004
Cr-Commit-Position: refs/heads/master@{#8492}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8492 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL changes the way the decoder sample rate is set and updated. In
practice, it only concerns the iSAC (float) codec.
One single iSAC decoder instance is used for both wideband and
super-wideband decoding, and the instance must be told to switch
output frequency if the payload type changes. This used to be done
through a call to UpdateDecoderSampleRate, but is now instead done in
the Decode call as an extra parameter.
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34349004
Cr-Commit-Position: refs/heads/master@{#8476}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8476 4adac7df-926f-26a2-2b94-8c16560cd09d
Although sample_rate_hz(), num_channels(), and rtp_timestamp_rate_hz()
are simple accessors for almost all implementations of AudioEncoder,
they are virtual and not guaranteed to be just simple accessors. Thus,
it makes more sense to use the normal CamelCase naming scheme.
BUG=4235
R=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34239004
Cr-Commit-Position: refs/heads/master@{#8407}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8407 4adac7df-926f-26a2-2b94-8c16560cd09d
- Add max_bit_rate and max_payload_size_bytes to config structs.
- Fix support for 48 kHz sample rate.
- Fix iSAC-RED.
- Add method UpdateDecoderSampleRate().
- Update locking structure with a separate lock for local member
variables used by the encoder methods.
BUG=3926
COAUTHOR:kwiberg@webrtc.org
R=minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/41659004
Cr-Commit-Position: refs/heads/master@{#8204}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8204 4adac7df-926f-26a2-2b94-8c16560cd09d
The following three methods are added:
rtp_timestamp_rate_hz()
SetTargetBitrate()
SetProjectedPacketLossRate()
Default implementations are provided, and a few overrides are
implemented. AudioEncoderCopyRed and AudioEncoderCng propagate the new
methods to the underlying speech codec.
BUG=3926
COAUTHOR:kwiberg@webrtc.org
R=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/34049004
Cr-Commit-Position: refs/heads/master@{#8171}
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8171 4adac7df-926f-26a2-2b94-8c16560cd09d
This intrinsics version gives bit-exact result as the current C
code. And the performance is 14% better than current assembly
neon version, 3.4 times faster than current C version. The test runs
under Cortex-a53 aarch32 mode, other cpu should give similar performance
result.
Change-Id: Icce5eaf2e17790ce44513d52b53b9f600cc16f96
BUG=4002
R=andrew@webrtc.org, jridges@masque.com
Review URL: https://webrtc-codereview.appspot.com/36689004
Patch from Zhongwei Yao <zhongwei.yao@arm.com>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@8070 4adac7df-926f-26a2-2b94-8c16560cd09d
This intrinsics version gives bit-exact result as the current assembly
neon code. And the performance is 38% better than current assembly
neon version, 5.92 times faster than current C version. The test runs
under Cortex-a53 aarch32 mode, other cpu should give similar performance
result.
BUG=4002
R=andrew@webrtc.org, jridges@masque.com
Change-Id: I257e33ef6d634a519fd71adc4f52b06dd655bd9d
Review URL: https://webrtc-codereview.appspot.com/32749004
Patch from Zhongwei Yao <zhongwei.yao@arm.com>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7891 4adac7df-926f-26a2-2b94-8c16560cd09d
The modification only uses the unique part of the
WebRtcIsacfix_AutocorrC function. Pass FiltersTest.AutocorrFixTest test
on both ARMv7 and ARM64, and the single function performance is similar
with original assembly version on different platforms. If not
specified, the code is compiled by GCC 4.6. The result is the "X
version / C version" ratio, and the less is better.
| run 100k times | cortex-a7 | cortex-a15 |
| use C as the base on each | (1.2Ghz) | (1.7Ghz) |
| CPU target | | |
|----------------------------+-----------+------------|
| Neon asm | 24% | 23% |
| Neon intrinsics (GCC 4.6) | 33% | 32% |
| Neon intrinsics (GCC 4.8) | 27% | 27% |
BUG=3850
R=andrew@webrtc.org, jridges@masque.com
Change-Id: Id6cd0671502fadbebd10b1f5493f5b16c988286f
Review URL: https://webrtc-codereview.appspot.com/27999004
Patch from Zhongwei Yao <zhongwei.yao@arm.com>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7802 4adac7df-926f-26a2-2b94-8c16560cd09d
Pick up the libvpx roll: https://codereview.chromium.org/674753002
Summary of changes (28d1981..d3db2ff/DEPS):
* third_party/android_tools 36bf7ac..ea50ccc
* third_party/boringssl 7ea8481..751e889
* third_party/icu 8ac906f..d8b2a9d
* third_party/libvpx efe9712..2e5ced5
* third_party/usrsctp/usrsctplib
* tools/gyp 1990:1991
* tools/swarming_client a57d7db..bcb3bc3
Clang is not updated in this roll.
Made the change getchar() --> getc(stdin) as seems like getchar() isn't supported on android anymore.
(getchar() was causing the error: undefined reference to '__srget')
Update rate control parameter in vp9 test.
R=andrew@webrtc.orgTBR=ajm@google.com
Review URL: https://webrtc-codereview.appspot.com/23229004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7598 4adac7df-926f-26a2-2b94-8c16560cd09d
