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
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
The reason for this is that http://crrev.com/245412
introduces a dependency of Chrome's src/build/gyp_chromium
to src/tools/find_depot_tools.py, which we don't have
synced in WebRTC (src/tools is very big).
Offline discussions shows that we cannot rely on syncing
individual subdirectories from Chrome in the future, but
maintaining our own gyp_webrtc file will at least buy us
some time for now, so we can roll past that chromium_revision
in WebRTC DEPS.
Overview of differences between gyp_webrtc and gyp_chromium
(and how we previously used gyp_chromium):
* No .gyp file needs to be passed (defaults to all.gyp)
* CHROMIUM_GYP_FILE is ignored (i.e. cannot be used to
specify an alternate .gyp file to process)
* Ninja is used by default on all platforms unless GYP_GENERATORS
is set.
* Gyp syntax check is always on
* Gyp circular dependency check is always on
* No support for automatic toolchain detection on Windows.
* --depth argument is no longer needed since calculated by
the script.
* Support for a webrtc.gyp_env file sitting next to the
.gclient file in the top dir of checkout, which can be
used to override Gyp variables similar to chromium.gyp_env.
* SKIP_WEBRTC_GYP_ENV can be set to skip reading webrtc.gyp_env.
BUG=2863
TEST=Ran and verified behavior on Linux with:
gclient runhooks
webrtc/build/gyp_webrtc
webrtc/build/gyp_webrtc -Dextra_gyp_flag=0
. build/android/envsetup.sh && gclient runhooks
SKIP_WEBRTC_GYP_ENV=1 webrtc/build/gyp_webrtc
GYP_GENERATORS=make webrtc/build/gyp_webrtc
The patch also passes runhooks and compile step on all trybots.
R=andrew@webrtc.org, fischman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/7759004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5467 4adac7df-926f-26a2-2b94-8c16560cd09d
This will allow an embedder to use it directly.
Adding inertia/hangover time between updates of the reported detection status to the algorithm, controlled by a parameter. That is usually desired and this way a consumer of
the class don't have to implement that. (VoiceEngine will let it be 1, which results in the same behavior as before, and keep controlling the hangover itself.)
R=andrew@webrtc.org, niklas.enbom@webrtc.org, xians@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/6219004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5462 4adac7df-926f-26a2-2b94-8c16560cd09d
In webrtc::vcm::VideoReceiver::ResetDecoder(), the lock order is:
1. take _receiveCritSect,
2. take process_crit_sect_
This conflicts with the follow code path:
1. webrtc::vcm::VideoReceiver::Process(), take process_crit_sect_
call -> webrtc::vcm::VideoReceiver::NackList(),
2. with nackStats=kNackKeyFrameRequest, take _receiveCritSect
BUG=2861
TEST=trybots
R=sprang@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/7749004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@5456 4adac7df-926f-26a2-2b94-8c16560cd09d
