1) return the first global temporary and non-deprecrated ones.
2) if #1 not available, return global one.
3) if #2 not available, use ULA ipv6 as last resort.
ULA stands for unique local address. They are only useful in a private
WebRTC deployment. More detail: http://en.wikipedia.org/wiki/Unique_local_address
BUG=3808
At this point, rule #3 actually won't happen at current
implementation. The reason being that ULA address starting with 0xfc 0r 0xfd will be grouped into its own Network. The result of that is WebRTC will have one extra Network to generate candidates but the lack of rule #3 shouldn't prevent turning on IPv6 since ULA should only be tried in a close deployment anyway.
R=jiayl@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/31369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7200 4adac7df-926f-26a2-2b94-8c16560cd09d
This is based on webrtc/build/merge_libs.gyp, with a dependency on
voice_engine.gyp instead and suitable name changes.
Executing:
$ rm -rf out/
$ ./webrtc/build/gyp_webrtc -Denable_video=0 -Denable_protobuf=0
-Drelease_optimize=s webrtc/build/merge_libs_voice.gyp
$ ninja -C out/Release merged_lib_voice
results in a minimially sized voice engine lib at:
out/Release/librtc_voice_merged.a
Linux: 6.4 MB
Mac: 3.7 MB
R=braveyao@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/23659004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7199 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
- Change hw video decoder wrapper to allow to feed multiple input
and query for an output every 10 ms.
- Add an option to decode video frame into an Android surface object. Create
shared with video renderer EGL context and external texture on
video decoder thread.
- Support external texture rendering in Android renderer.
- Support TextureVideoFrame in Java and use it to pass texture from video decoder
to renderer.
- Fix HW encoder and decoder detection code to avoid query codec capabilities
from sw codecs.
BUG=
R=tkchin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/18299004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7185 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
This requires two fixes:
1. Use DCHECK instead of assert in ThreadChecker's unittest.
2. Activate DCHECK when DCHECK_ALWAYS_ON in enabled.
Both these modifications are in line with Chromium's implementation.
The ThreadChecker unittest was changed to use assert instead of DCHECK
on the initial import (since WebRTC did not have a DCHECK back then).
BUG=3803
TEST=local out/{Debug,Release}/rtc_unittests built with and without DCHECK_ALWAYS_ON
R=andrew@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24569004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7178 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
In r7140 the webrtc_base target was renamed to rtc_base. This
breaks our FYI bots for rolling WebRTC in Chromium's DEPS.
By re-adding a None target named webrtc_base, this transition
should be smoother.
TBR=henrikg@webrtc.org,
TESTED=Passed build/gyp_chromium on a Chromium checkout with src/third_party/webrtc replaced by a mount like this:
cd /path/to/chromium/src
sudo mount --bind /path/to/webrtc/trunk/webrtc third_party/webrtc
Review URL: https://webrtc-codereview.appspot.com/23589004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7150 4adac7df-926f-26a2-2b94-8c16560cd09d
