I mistakenly ommitted the checks when logging.h was ported from
libjingle to webrtc. This caused a significant CPU cost for logs which
were later filtered out anyway.
Verified with LS_VERBOSE logging in neteq4, running:
$ out/Release/modules_unittests \
--gtest_filter=NetEqDecodingTest.TestBitExactness \
--gtest_repeat=50 > time.txt
$ grep "case ran" time.txt | grep "[0-9]* ms" -o | sort
Results on a MacBook Retina, averaged over 5 runs:
Verbose logs disabled: 666 ms
Exisiting implementation, verbose logs enabled: 944 ms (1.42x)
New implementation, verbose logs enabled: 673 ms (1.01x)
BUG=2314
R=henrik.lundin@webrtc.org, henrike@webrtc.org, kjellander@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2160005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4682 4adac7df-926f-26a2-2b94-8c16560cd09d
Adds AllowCommandLineParsing to allow us to ignore "--no-sandbox" given
by new TSanV2 bots. Not ignoring this flag prevents the test from
running on this machine. Also removing unnecessary asserts that clutter
code.
BUG=
TEST=Locally running video_engine_tests with --no-sandbox.
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2178004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4679 4adac7df-926f-26a2-2b94-8c16560cd09d
Tests enabled in r4671 failed:
build.chromium.org/p/client.webrtc/builders/Android%20Tests/builds/31/steps/slave_steps/logs/stdio
> Enable SetInitialPlayoutDelay on Android.
>
> Background:
> In Chrome mirroring which uses 500ms buffering mode,
> audio video mismatch happens in the begining because of the lack of the api.
>
> BUG=b/10538425
> TEST=pass 'git try' except tests which is aleady broken in the bot. pass 'build/android/test_runner.py gtest -s modules_tests --verbose --release -f *InitialPlayoutDelayTest*'
> R=henrika@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/2144004TBR=dwkang@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2160006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4672 4adac7df-926f-26a2-2b94-8c16560cd09d
Background:
In Chrome mirroring which uses 500ms buffering mode,
audio video mismatch happens in the begining because of the lack of the api.
BUG=b/10538425
TEST=pass 'git try' except tests which is aleady broken in the bot. pass 'build/android/test_runner.py gtest -s modules_tests --verbose --release -f *InitialPlayoutDelayTest*'
R=henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2144004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4671 4adac7df-926f-26a2-2b94-8c16560cd09d
Breaks out config part of FakeEncoder from VideoSendStream tests to
FakeEncoder. Also sets FakeEncoder as encoder for VideoSendStream tests.
Anticipated speedup didn't happen as VP8 is still initialized by default
when creating channels in the old API. This will be sped up when moving
off the old API as VP8 won't be enabled by default.
BUG=2312
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2155004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4659 4adac7df-926f-26a2-2b94-8c16560cd09d
On Windows, when tests are run under memory tools like
DrMemory and TSan, slashes occur in the path as directory
separators. This makes the fileutils.cc fail to figure out
the project root, making paths to resource files invalid.
By replacing slashes in the path with backslashes for Windows
this can be fixed.
BUG=2318
TEST=running the same command as the bot locally, succeeding after this patch is applied.
R=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2137004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4640 4adac7df-926f-26a2-2b94-8c16560cd09d
This test goes into an eternal loop sometimes when run under
TSan v2, therefore I'm disabling it until this is resolved.
Doing that, the TSan v2 bot in our new WebRTC FYI waterfall at
http://build.chromium.org/p/client.webrtc.fyi/waterfall
will hopefully go green.
The define used only exists for TSan v2, so v1 should be
unaffected.
The suppression added in http://review.webrtc.org/2126005/
turns out actually has no effect, so I'm removing it again.
It's probably useless since TSan v2 obviously alters the code's
behavior, causing these errors. Since the errors are not TSan v2
failures, the suppression has no effect.
BUG=2259
TEST=test passing locally when run as described in 2259 (since
no tests are run).
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2115005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4639 4adac7df-926f-26a2-2b94-8c16560cd09d
The metrics_unittests tried to write an empty file to the
current working directory, which caused a crash on Android. By
using the output folder instead, this is avoided.
This makes it possible to re-enable the tests disabled in r4474
and also remove the empty dummy test added in r4627.
BUG=1882,
TEST=Setup a Chromium+WebRTC checkout as described in issue 1882
. build/android/envsetup.sh
export GYP_DEFINES="$GYP_DEFINES include_tests=1 enable_tracing=1"
gclient runhooks
ninja -C out/Release metrics_unittests_apk
build/android/test_runner.py gtest -s metrics_unittests --verbose --release
R=henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2127006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4634 4adac7df-926f-26a2-2b94-8c16560cd09d
The ACM tests needed re-writing, because all tests were not individual gtests, and the result was difficult to interpret.
While doing the re-write, I discovered a bug related to 48 kHz CNG. We can't have the 48 kHz CNG active at the moment. The bug is fixed in this CL.
I also needed to rewrite parts of the VAD/DTX implementation, so that the status of VAD and DTX (enabled or not) is propagated back from the function SetVAD().
BUG=issue2173
R=minyue@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1961004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4625 4adac7df-926f-26a2-2b94-8c16560cd09d
I broke captured image flipping when refactoring this code while it was
still in chromium. Previously we had CaptureData that was returned from
capturers with correctly inverted stride, but frames were still stored
with positive stride. CaptureData was removed and so the returned frames
always had positive stride, which is not correct. Now ScreenCapturerMac
uses frames with inverted stride when capturing using OpenGL.
R=wez@chromium.org
Review URL: https://webrtc-codereview.appspot.com/2105004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4621 4adac7df-926f-26a2-2b94-8c16560cd09d
Window enumeration is based on the code used by hangouts plugin
(see libjingle/talk/base/linuxwindowpicker.cc). XServerPixelBuffer
is used to capture windows. It had to be refactored to support window
capturing (previously it worked only for the whole screen).
R=wez@chromium.org
Review URL: https://webrtc-codereview.appspot.com/1741004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4605 4adac7df-926f-26a2-2b94-8c16560cd09d
