Converting the test to a method within the test fixture, and setting
up two tests that call this method. One for positive and one for
negative clock drift. The one with positive clock drift is disabled
for now since it does not pass, but will be re-enabled shortly.
This change is only made for NetEq4.
R=tlegrand@google.com
Review URL: https://webrtc-codereview.appspot.com/8599004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5541 4adac7df-926f-26a2-2b94-8c16560cd09d
Before the change no padding was allowed before the first remote bitrate
estimation was received. This bitrate estimation is based on what's
actually sent. In tests I set codec.startBitrate to 300 instead of
325, which incidentally means that only the first layer gets encoded.
As we only send ~150kbps instead of 300, the first REMB will
significantly pull down the remote bitrate estimate instead of keeping
the existing rate, even though there's no problem with the link.
This was detected in RampUpTest.PacingWithRtx,
(send_config.codec.startBitrate=300), which caused the tests to become a
lot slower, and flake out more. By allowing padding initially we're able
to keep our initial bitrate estimate.
R=stefan@webrtc.org
TEST=Running RampUpTest.WithPacingAndRtx with startBandwidth=300.
BUG=
Review URL: https://webrtc-codereview.appspot.com/8529004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5534 4adac7df-926f-26a2-2b94-8c16560cd09d
The name "libwebrtc.a" was conflicting with the newish webrtc target,
resulting in this error:
$ ./webrtc/build/gyp_webrtc merged_lib.gyp
$ ninja -C out/Debug
ninja: warning: multiple rules generate libwebrtc.a. builds involving
this target will not be correct; continuing anyway
ninja: error: dependency cycle: no_op -> libwebrtc.a -> no_op
BUG=b/12955740
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8409005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5528 4adac7df-926f-26a2-2b94-8c16560cd09d
These high level tests were disabled over time. Since they depend on
real-time results and the filesystem, they tended to be flaky on the
bots. We now give it a very generous 1 second to start up all channels
before verification and a further relaxed file length check. If we
continue to see problems, I will up the startup delay.
The restored tests would have caught the AGC bug fixed here:
https://code.google.com/p/webrtc/source/detail?r=5454
Add a new "real audio" stress test to exercise more code paths. This
would have caught the refactor bug fixed here:
https://code.google.com/p/webrtc/source/detail?r=5437
BUG=2164,2844
TESTED=git try. Verified it would have caught the aforementioned bugs
by reintroducing them.
R=andresp@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8009004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5522 4adac7df-926f-26a2-2b94-8c16560cd09d
These tests have been failing for a long time at
http://build.chromium.org/p/client.webrtc.fyi/builders/Linux%20TsanRV
This bot runs a tool called TSan Race Verifier.
More info about Race Verifiers can be found at
https://code.google.com/p/data-race-test/wiki/RaceVerifier
By excluding the tests like this, they will also be disabled
for the normal TSan bot, where they currently pass. This shouldn't
be a problem since we have a TSan v2 bot running too (which uses
a different set of suppressions), so it should catch any newly
introduced race conditions. The TSan v2 bot will soon replace the
old TSan bot, as v1 is being deprecated.
TBR=mallinath@webrtc.org
BUG=2396
TEST=Passing run on Linux of:
GYP_DEFINES=build_with_tool=tsan gclient runhooks
ninja -C out/Release libjingle_p2p_unittest
tools/valgrind-webrtc/webrtc_tests.sh --tool=tsan_rv -b out/Release -t libjingle_p2p_unittest
Review URL: https://webrtc-codereview.appspot.com/8329005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5515 4adac7df-926f-26a2-2b94-8c16560cd09d
The find_depot_tools.py is needed to workaround the import
error we get from gyp_chromium when importing it in
webrtc/build/gyp_webrtc (to avoid code duplication).
gyp_chromium introduced a dependency on it in
http://crrev.com/245412 but as we cannot sync all of Chrome's
src/tools (it's quite big), we'll work around this by
adding an empty find_depot_tools module.
The removal of the Cygwin relates to
http://crrev.com/248802 which is a step on the way to remove
Cygwin in Chromium. We seem to already be able to remove it
entirely for WebRTC though.
Changes in the isolate framework required us to update our
copies of the isolate.gypi files.
BUG=none
TEST=trybots passing on all platforms
R=andrew@webrtc.org, fischman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8099004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5512 4adac7df-926f-26a2-2b94-8c16560cd09d
According to https://code.google.com/p/webrtc/issues/detail?id=2907#c2
r5505 was committed to resolve exactly these flakes.
Let's revert the disabling and see.
BUG=2907
TBR=mallinath@webrtc.org
> Disable failing libjingle_p2p_unittest test on Linux
>
> I realize this diables 84 test cases and for all platforms, which
> I'm not really comfortable with. I tried finding a better way but
> couldn't without doing significant changes to the file.
> I think the tests either needs to be fixed or otherwise refactored
> in order to make more fine-grained disabling possible.
>
> Another (too) large disabling was done by holmer@ in
> https://webrtc-codereview.appspot.com/2227004 where he should only have
> disabled them on Windows, if the failures in webrtc:2383 was all that
> caused those flakes.
>
> BUG=2907
> TEST=Verified this ran 0 tests:
> out/Release/libjingle_p2p_unittest --gtest_filter=P2PTransportChannelTest.TestNAT_ADDR_RESTRICTEDToNAT_PORT_RESTRICTEDAsGiceBothSharedUfragWithMinimumStepDelay
> TBR=wu@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/8309004TBR=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8329004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5511 4adac7df-926f-26a2-2b94-8c16560cd09d
I realize this diables 84 test cases and for all platforms, which
I'm not really comfortable with. I tried finding a better way but
couldn't without doing significant changes to the file.
I think the tests either needs to be fixed or otherwise refactored
in order to make more fine-grained disabling possible.
Another (too) large disabling was done by holmer@ in
https://webrtc-codereview.appspot.com/2227004 where he should only have
disabled them on Windows, if the failures in webrtc:2383 was all that
caused those flakes.
BUG=2907
TEST=Verified this ran 0 tests:
out/Release/libjingle_p2p_unittest --gtest_filter=P2PTransportChannelTest.TestNAT_ADDR_RESTRICTEDToNAT_PORT_RESTRICTEDAsGiceBothSharedUfragWithMinimumStepDelay
TBR=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8309004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5510 4adac7df-926f-26a2-2b94-8c16560cd09d
New errors arrived when rolling libjingle in r5502.
These suppressions are needed to green up the Memcheck and
TSan bots.
BUG=1976,2080
TEST=local runs on Linux:
tools/valgrind-webrtc/webrtc_tests.sh --tool=tsan -b out/Release -t libjingle_unittest
tools/valgrind-webrtc/webrtc_tests.sh --tool=memcheck -b out/Release -t libjingle_unittest
and trybot:
git try --bot=linux_memcheck,linux_tsan -t libjingle_unittest
TBR=wu@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8299004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5509 4adac7df-926f-26a2-2b94-8c16560cd09d
Because chromium is compiled with a different version of logging macros
defined in logging.h that header cannot be used in headers that can
also included from chromium code. Removed LOG_F(LS_WARNING) from
callback.h . That issue would block this code from being rolled in
chromium.
R=mallinath@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/8279004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5507 4adac7df-926f-26a2-2b94-8c16560cd09d
