This also marks all virtual overrides of other classes in the same files.
This will make a subsequent change I intend to do safer, where I'll change the
argument types of the base Transport functions, by breaking the compile if I
miss any overrides.
This also highlighted a number of unused functions. I've removed some of these.
TBR=mflodman@webrtc.org, pkasting@chromium.org
BUG=none
TEST=none
Review URL: https://webrtc-codereview.appspot.com/28709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7421 4adac7df-926f-26a2-2b94-8c16560cd09d
RemoteNtpTimeEstimator needed user to give a remote SSRC and it intended to call RtpRtcp module to obtain RTT, to be able to calculate Ntp time.
When RTT cannot be directly obtained from the RtpRtcp module with the specified SSRC, RemoteNtpTimeEstimator would fail.
This change allows RemoteNtpTimeEstimator to calculate NTP with an external RTT estimate.
An immediate benefit is that capture_start_ntp_time_ms_ can be obtained in a Google hangout call.
BUG=
TEST=chromium + hangout call
R=stefan@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24879004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7407 4adac7df-926f-26a2-2b94-8c16560cd09d
Mainly to pick up https://codereview.chromium.org/619723006/
to fix our MSan bot.
Summary of changes (git diff c264a05..fc668e2 DEPS):
* third_party/boringssl 01fe820..c7dd5f30
* third_party/usrsctp/usrsctplib 8975bd5..d5685d4
* tools/swarming_client 79940aee..33d442a
Clang updated 216630:217949 (git diff c264a05..fc668e2 tools/clang/scripts/update.sh)
This caused TSan v2 to hit an assert in libjingle_peerconnection_unittest
and libjingle_media_unittest, which is why the dlclose call
had to be disabled for now (webrtc:3895).
BUG=3895
R=henrika@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/28659004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7385 4adac7df-926f-26a2-2b94-8c16560cd09d
Libvpx now supports GN and this CL turns on compiling it.
I also introduced an executable target 'webrtc_tests'
that depends on all in WeBRTC + tests in order to get a full
linking step executed (since we've seen link problems for GN
when rolling WebRTC into Chromium).
I also converted a few test targets and made a GN file for
third_party/gflags.
BUG=3441
TESTED=Trybots + full Chromium build with a symlinked src/third_party/webrtc
dir to a workspace wit this CL applied.
R=brettw@chromium.orgTBR=niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/25569004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7344 4adac7df-926f-26a2-2b94-8c16560cd09d
> Remove the different block lengths in ns_core
>
> This CL has bit-exact output.
>
> What it does:
> * Remove the blockLen10Ms, as it is hardcoded to be equal to blockLen.
> * This makes outLen to be always zero, so it can be removed too.
> * It also avoids the need to have an outBuf, because it is not used, so it is also removed
> * Replaced blockLen10Ms by blockLen everywhere, since they were hardcoded to be equal.
> * We don't need to check if outLen is zero, because it always is, so it was removed.
> * Of course, the outBuf needs no initial set or copying around, because it is not used.
>
> BUG=webrtc:3811
> R=bjornv@webrtc.org, kwiberg@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/30539004TBR=aluebs@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26629004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7306 4adac7df-926f-26a2-2b94-8c16560cd09d
This CL has bit-exact output.
What it does:
* Remove the blockLen10Ms, as it is hardcoded to be equal to blockLen.
* This makes outLen to be always zero, so it can be removed too.
* It also avoids the need to have an outBuf, because it is not used, so it is also removed
* Replaced blockLen10Ms by blockLen everywhere, since they were hardcoded to be equal.
* We don't need to check if outLen is zero, because it always is, so it was removed.
* Of course, the outBuf needs no initial set or copying around, because it is not used.
BUG=webrtc:3811
R=bjornv@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/30539004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7297 4adac7df-926f-26a2-2b94-8c16560cd09d
r7049 added some unnecessary casts ("return 0" -> "return static_cast<uint16_t>(0)"). r7123 converted these to "return 0u". The original impetus for this was to eliminate type conversion warnings. However, the 'u's are unnecessary; Visual Studio can return "0" from a function returning an unsigned value without producing a warning. The real reason for the original warnings was that the code was returning -1 from a function returning an unsigned value, which does need a cast; the -1s were eliminated before the above two revisions landed.
Also reverse the order of some conditionals to prevent possible underflow.
While the underflow wouldn't have changed the behavior of the code, it's easier
to reason about the code when such underflow can't happen, and possibly safer
against future modifications as well.
BUG=3663
TEST=none
R=tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22599004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7296 4adac7df-926f-26a2-2b94-8c16560cd09d
In practice, we have been doing this since time immemorial, but have
relied on the user to do the downmixing (first voice engine then
Chromium). It's more logical for this burden to fall on AudioProcessing,
however, who can be expected to know that this is a reasonable approach
for AEC. Permitting two render channels results in running two AECs
serially.
Critically, in my recent change to have Chromium adopt the float
interface:
https://codereview.chromium.org/420603004
I removed the downmixing by Chromium, forgetting that we hadn't yet
enabled this feature in AudioProcessing. This corrects that oversight.
The change in paths hit by production users is very minor. As commented
it required adding downmixing to the int16_t path to satisfy
bit-exactness tests.
For reference, find the ApmTest.Process errors here:
https://paste.googleplex.com/6372007910309888
BUG=webrtc:3853
TESTED=listened to the files output from the Process test, and verified
that they sound as expected: higher echo while the AEC is adapting, but
afterwards very close.
R=aluebs@webrtc.org, bjornv@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31459004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7292 4adac7df-926f-26a2-2b94-8c16560cd09d
This attenuates the noise pumping generated from the NS adapting to the AEC comfort noise.
When there is echo present the AEC suppresses it and adds comfort noise. This is underestimated on purpose to avoid adding more than the original background noise. The NS has to be called after the AEC, because every non-linear processing before it can ruin its performance. Therefore the noise estimation can adapt to this comfort noise, making it less aggressive and generating noise pumping.
By putting the noise estimation analysis stage from the NS before the AEC, this effect can be avoided. This has been tested manually on recordings where noise pumping was present: Two long recordings done in our team by bjornv and kwiberg plus the most noisy (5) recordings in the QA set.
On the other hand, one risk of doing this is to not adapt to the comfort noise and therefore suppress too much. As verified in the tested files, this is not a problem in practice.
BUG=webrtc:3763
R=andrew@webrtc.org, bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24679004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7289 4adac7df-926f-26a2-2b94-8c16560cd09d
