This makes it possible for us to migrate to using the bot_update step
on our buildbots. That would mean they'd use a Git checkout, which
brings stability, speed and best of all: re-enables the
DEPS-second-sync capability on our trybots that we've been lacking.
bot_update currently doesn't support the use_relative_paths variable
so the synced deps end up in the wrong path with it enabled.
Since Chromium doesn't use it, and it doesn't pollute our
DEPS file that much, I think we should switch.
NOTICE: Any custom_deps entries for the solution in .gclient have to be
updated to support this change, which includes the entry normally present
for Valgrind binaries. The bots will need to be updated as well at the
same time as landing this.
BUG=3534
TESTED=Verified a local sync works.
R=andrew@webrtc.org, niklas.enbom@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/13349004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7078 4adac7df-926f-26a2-2b94-8c16560cd09d
1. the options set in the first CreateOffer call should not affect the result of a second CreateOffer call, if SetLocalDescription is not called after the first CreateOffer. So the member var options_ of MediaStreamSignaling is removed to make each CreateOffer independent.
Instead, MediaSession is responsible to make sure that an m-line in the current local description is never removed from the newly created offer.
2. OfferToReceiveAudio used to default to true, i.e. always having m=audio line even if no audio track. This is changed so that by default m=audio is only added if there are any audio tracks.
BUG=2108
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/16309004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7068 4adac7df-926f-26a2-2b94-8c16560cd09d
Since the sync_chromium.py script always passes --revision
to the gclient sync command, we don't need to have
managed=True in the .gclient file.
This will avoid a warning that confuses our developers.
BUG=3776
TESTED=Removed my chromium/.last_sync_chromium and performed
a gclient sync with this patch applied. No warning complaining
about Managed mode appears.
R=andresp@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/23469004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7065 4adac7df-926f-26a2-2b94-8c16560cd09d
Fixes the following failure for mips:
"ERROR at //third_party/webrtc/BUILD.gn:136:7: Undefined variable for +=.
cflags += [ "-mhard-float" ]
^-----
I don't have something with this name in scope now."
BUG=3441
TEST=In Chromium. Passing compile locally on Linux using:
gn gen out-gn/mips --args="is_debug=false os=\"android\" cpu_arch=\"mipsel\"" --verbose && ninja -C out-gn/mips all
gn gen out-gn/arm --args="is_debug=false os=\"android\" cpu_arch=\"arm\"" --verbose && ninja -C out-gn/arm all
gn gen out-gn/x86-linux --args="is_debug=false os=\"linux\"" --verbose && ninja -C out-gn/x86-linux webrtc
R=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/15349004
Patch from Gordana Cmiljanovic <Gordana.Cmiljanovic@imgtec.com>.
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7063 4adac7df-926f-26a2-2b94-8c16560cd09d
This changes some method signatures to better reflect how callers are actually
using them. This also has the tendency to make signatures more consistent about
e.g. using int (instead of int16_t) for lengths of things like vectors, and
using int16_t (instead of int) for e.g. counts of bits in a value.
This also removes a couple of functions that were only called in unittests.
BUG=3353,chromium:81439
TEST=none
R=andrew@webrtc.org, bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/23389004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7060 4adac7df-926f-26a2-2b94-8c16560cd09d
This reverts selected parts of r7014 to enable
rolling WebRTC in Chromium DEPS.
This works around the problem with GYP includes
being processed in the first pass (i.e. variables
cannot be used for paths). Using a dependency with
a path using a variable that is conditioned for
build_with_chromium being 0 or 1 solves the Chromium
build.
These changes will be restored once I've finished
a major GYP refactoring that will break out all
test related code (at least the parts that includes
the Android APK targets) into a separate chain
of GYP targets that are not processed when generating
projects for Chromium (which is why r7014 is breaking
the Chromium build).
BUG=3741
TESTED=Passing compilation of standalone using:
GYP_DEFINES="OS=android component=static_library fastbuild=1 target_arch=arm" webrtc/build/gyp_webrtc
ninja -C out/Debug
Then verified the *_apk targets are generated and compiled.
Passing compilation from a Chromium checkout with third_party/webrtc
directory removed and a new empty third_party/webrtc mapped to the
standalone checkout using:
sudo mount --bind /path/to/trunk/webrtc third_party/webrtc
Then running build/gyp_chromium
I also verified WebRTC GYP targets exist and are able to compile.
R=henrike@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/20299004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7040 4adac7df-926f-26a2-2b94-8c16560cd09d
In the fixed point version of the Noise Suppression. At one place we subtract a value in the wrong Q-domain, which later may cause a divide by zero. Going through the floating point code that particular variable should be zero if this happens, which is what the old code tried to accomplish, but in an awkward way.
The bug has been there since development, so the likelihood of actually get a divide by zero is very small.
BUG=chromium:407812
R=ljubomir.papuga@gmail.com, tina.legrand@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/17229004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7035 4adac7df-926f-26a2-2b94-8c16560cd09d
