webrtc did not build if AGC_DEBUG was turned on. This CL fixes that. Has no impact on performance since it is development/debug code.
* Name change to WEBRT_AGC_DEBUG_DUMP
* Added build flag agc_debug_dump to .gypi
* Added missing "%d" in printf at two places
* Some line length related style changes
Tested audioproc and modules_unittests with GYP_DEFINES=agc_debug_dump=1 webrtc/build/gyp_webrtc
BUG=N/A
TESTED=locally and trybots
R=aluebs@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31429004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7271 4adac7df-926f-26a2-2b94-8c16560cd09d
The reason why ApmTest.Process breaks on Android is that two metrics over counts. I decided to add an offset and a different slack to the EXPECT_NEAR() calls that are affected. I think this is a reasonable approach since we have no more than two failing metrics. If any feature change that will make another metric fail, we should go back to the desk and find another way of solving this.
BUG=114
TESTED=locally on Nexus 7 and trybots
R=aluebs@webrtc.org, andrew@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26509004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7268 4adac7df-926f-26a2-2b94-8c16560cd09d
This time reverts the Cl that actually broke the tests. Got the wrong rev before. :/
BUG=3520
TESTED=Locally with CHECKOUT_SOURCE_ROOT=`pwd` build/android/test_runner.py gtest -s modules_unittests --gtest_filter=AcmReceiverBitExactness.8kHzOutput --verbose --isolate-file-path=webrtc/modules/modules_unittests.isolate
TBR=henrik.lundin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26579004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7264 4adac7df-926f-26a2-2b94-8c16560cd09d
In order to maintain test coverage for the old API (AudioCodingModule)
during the transition period, the old test was copied to
AcmReceiverTestOldApi.
Modified and extended AudioCoding and the implementation to make the
test compile and run.
Created a converter method from new to old config struct
BUG=3520
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31409004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7259 4adac7df-926f-26a2-2b94-8c16560cd09d
The converted tests are:
AcmIsacMtTest
AcmReceiverBitExactness
AcmSenderBitExactness
AudioCodingModuleMtTest
AudioCodingModuleTest
In order to maintain test coverage for the old API (AudioCodingModule)
during the transition period, the old tests were copied and given the
suffix OldApi:
AcmIsacMtTestOldApi
AcmReceiverBitExactnessOldApi
AcmSenderBitExactnessOldApi
AudioCodingModuleMtTestOldApi
AudioCodingModuleTestOldApi
BUG=3520
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/23719004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7258 4adac7df-926f-26a2-2b94-8c16560cd09d
Before this change it could happen that a large jump in timestamp (a
jump not correlated to wall-clock change) caused the audio to go silent
without recovering. The reason was that all incoming packets after the
jump were considered too old compared to the last decoded packet, and
were deleted. With CL changes two things:
1. If the only available packet in the buffer is an old packet, NetEq
will do Expand instead of immediate reset. This is to avoid that one
late packet triggers a reset.
2. Old packets are discarded only when the decision to decode a packet
has been taken. This is to allow the buffer to grow and eventually
flush if no decodable packet has been found for some time.
This CL also includes a new unit test for this situation.
BUG=3785
R=minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7255 4adac7df-926f-26a2-2b94-8c16560cd09d
Filled the empty analyze API, separating the noise estimation from the process API.
No formatting fixes or extra refactoring has been done, to make the review process easier.
This patch has been tested for bit-exactness over the whole QA set in every aggressiveness.
BUG=webrtc:3811
R=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/27549004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7243 4adac7df-926f-26a2-2b94-8c16560cd09d
Targets must now link with implementation of their choice instead of at "gyp"-time.
Targets linking with libjingle_media:
- internal implementation when build_with_chromium=0, default otherwise.
Targets linking with default render implementation:
- video_engine_tests
- video_loopback
- video_replay
- anything dependent on webrtc_test_common
Targets linking with internal render implementation:
- vie_auto_test
- video_render_tests
- libwebrtcdemo-jni
- video_engine_core_unittests
GN changes:
- Not many since there is almost no test definitions.
Work-around for chromium:
- Until chromium has updated libpeerconnection to link with video_capture_impl and video_render_impl, webrtc target automatically depends on it. This should fix the FYI bots and not require a webrtc roll to fix.
Re-enable android tests by reverting 7026 (some tests left disabled).
TESTED: passes all the bots. If this inadvertently breaks a target please fix the linking rules so the target has the desired implementation linked in.
BUG=3770
R=kjellander@webrtc.org, pbos@webrtc.orgTBR=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/19359004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7217 4adac7df-926f-26a2-2b94-8c16560cd09d
into its own targets. Dependencies must link directly with the desired one.
Targets linking with libjingle_media:
- internal implementation when build_with_chromium=0, default otherwise.
Targets linking with default/external capture implementation:
- anything dependent on webrtc_test_common
- anything dependent on video_engine_core
Targets linking with internal capture implementation:
- vie_auto_test
- anything dependent on webrtc_test_renderer
GN changes:
- Not many since there is almost no test definitions.
TESTED: passes all the bots. If this inadvertently breaks a target please fix the linking rules so the target has the desired implementation linked in.
BUG=3768
R=glaznev@webrtc.orgTBR=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24589004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7209 4adac7df-926f-26a2-2b94-8c16560cd09d
These optimizations were originally committed in r6860, but reverted in r6861, since it broke a bitexactness test (ApmTest.Process) in modules_unittests. That test has now been updated in r7149, hence this CL now pass the test.
BUG=3767
TESTED=manually on linux and trybots
TBR=aluebs@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/25539004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7189 4adac7df-926f-26a2-2b94-8c16560cd09d
rtc_base drags in a bunch of unwieldly dependencies (e.g. nss and
json) not required for standalone webrtc (aka rtc/media). The root of
the problem appears to be that MessageQueue depends on a socket server.
(And since common.h -> logging.h -> thread.h -> messagequeue.h, this
dependency spreads quickly.)
This starts a new target for a "purified" subset of rtc_base. It adds
the files which are already being used, replacing the use of common.h
with checks.h. desktop_capture is a lost cause, and retains its
dependency on the full rtc_base.
The hope is that as additional components are desired they will be
cleaned and added to rtc_base_approved.
BUG=3806
R=andresp@webrtc.org, henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22649004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7188 4adac7df-926f-26a2-2b94-8c16560cd09d
When writing to wav files in the low level flag aec_debug_dump incorrect sample rates were used for recordings using rates from 32 kHz and above. This since internally inside the AEC we process the data using 16 kHz. Any upper band is processed and combined later on.
This CL adds the correct sample rate to the recording.
BUG=3359
TESTED=locally on 44.1 kHz recordings on Linux
R=aluebs@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/23649004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7182 4adac7df-926f-26a2-2b94-8c16560cd09d
There are reports (not reproducible with appRtcDemo) that
outstanding device orientation change event
OrientationEventListener.onOrientationChanged can be
triggered even after these events are disabled by
OrientationEventListener.disable() code.
Avoid calling native code in this case since underlying
C++ class may have already been deleted.
BUG=3564
R=braveyao@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/23609004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7172 4adac7df-926f-26a2-2b94-8c16560cd09d
This is to get the DrMemory Full bots to go green, this was previously
suppressed. This fix is likely hiding a real bug that should be
investigated, but it's not a regression from before. The issue should
not be closed before we figure out why this is the case and revert this
"fix".
TBR=stefan@webrtc.org
BUG=3183
Review URL: https://webrtc-codereview.appspot.com/30369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7169 4adac7df-926f-26a2-2b94-8c16560cd09d
Changes include,
1) Introduce class RtpPacketizerGeneric & RtpDePacketizerGeneric.
2) Introduce class RtpDepacketizerVp8.
3) Make RTPSenderVideo::SendH264 generic and used by all packetizers.
4) Move codec specific functions from RTPSenderVideo/RTPReceiverVideo to
RtpPacketizer/RtpDePacketizer sub-classes.
R=pbos@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/26399004
Patch from Changbin Shao <changbin.shao@intel.com>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7163 4adac7df-926f-26a2-2b94-8c16560cd09d
AddressSanitizer can't symbolize parts of the stack that contains
dlclose()d modules. This makes some LSan suppressions not kick in and
blocks launching the LSan bot for WebRTC.
This "fix" excludes dlclose() in
webrtc/modules/audio_device/linux/latebindingsymboltable_linux.cc which
resolves this on the bot.
R=xians@webrtc.org
BUG=3402,chromium:375154
Review URL: https://webrtc-codereview.appspot.com/25499004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7157 4adac7df-926f-26a2-2b94-8c16560cd09d
During porting some neon optimizations to sse2 the ApmTest.Process failed despite bit exact outputs. The reason is that with float data between component, as to previously truncating to int, we get small deviations in logged metrics. This affected a noise probability to a small fraction, which is not a particular bug.
This CL change the comparison from EXPECT_EQ() to EXPECT_NEAR() which then as a result makes the test run on Mac and Windows as well.
For int values a deviation of 1 is acceptable, which would include any rounding errors.
For float values a deviation of 0.0005 is chosen by looking at current test stats for the affected platforms/optimizations.
BUG=114
TESTED=locally on linux with and without sse2 optimizations and trybots
R=aluebs@webrtc.org, andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/20289004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7149 4adac7df-926f-26a2-2b94-8c16560cd09d
