Filled the empty analyze API, separating the noise estimation from the process API.
No formatting fixes or extra refactoring has been done, to make the review process easier.
This patch has been tested for bit-exactness over the whole QA set in every aggressiveness.
BUG=webrtc:3811
R=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/27549004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7243 4adac7df-926f-26a2-2b94-8c16560cd09d
- Fix video encoder Reset() function to avoid setting codec
resolution to zero.
- Follow SW codec implementation and do not crash when frame
with the resolution different from the encoder resolution arrives.
Instead wait for at least 3 frames with new resolution and
re-initialize the codec. HW codec reset may take much longer
than SW codec, so these 3 frames threshold avoids resetting
codec when outstanding camera frame captured from previous device
orientation arrives.
- Plus some minor changes to make encoder reset/release
implementation closer to decoder implementation.
BUG=
R=tkchin@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/30439004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7230 4adac7df-926f-26a2-2b94-8c16560cd09d
The synchronization access is unnecessary for rtc::Thread::WrapCurrent (called from JingleThreadWrapper) since JingleThreadWrapper never calls rtc::Thread::Stop or rtc::Thread::Join. Failing to get the access caused crashes in Chrome since rtc::Thread::Current will be NULL when rtc::Thread::WrapCurrent fails.
rtc::ThreadManager::WrapCurrentThread still requires the synchronization access, since I am not sure if the callers (e.g. the plugin) depends on it.
BUG=crbug/413853
R=juberti@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/30429004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7224 4adac7df-926f-26a2-2b94-8c16560cd09d
The .gclient_entries file is written after a successful
gclient sync operation and contains paths mapped to URLs for
all DEPS entries that have been synced.
This has been causing problems for users when switching from
the legacy Subversion based checkouts to the new DEPS approach
using a Chromium Git checkout combined with symlinks.
Also it has been discovered that when entries have been
removed from the Chromium DEPS file, subsequent gclient sync
operations fail when it's trying to process those directories.
This CL changes so that .gclient_entries is wiped for the WebRTC
checkout when moving from the legacy SVN to Git.
It also wipes the chromium/.gclient_entries file when a new Chromium
revision is about to be synced, to avoid problems when DEPS entries
have been removed.
BUG=415219
R=agable@chromium.org
Review URL: https://webrtc-codereview.appspot.com/28509004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7222 4adac7df-926f-26a2-2b94-8c16560cd09d
Targets must now link with implementation of their choice instead of at "gyp"-time.
Targets linking with libjingle_media:
- internal implementation when build_with_chromium=0, default otherwise.
Targets linking with default render implementation:
- video_engine_tests
- video_loopback
- video_replay
- anything dependent on webrtc_test_common
Targets linking with internal render implementation:
- vie_auto_test
- video_render_tests
- libwebrtcdemo-jni
- video_engine_core_unittests
GN changes:
- Not many since there is almost no test definitions.
Work-around for chromium:
- Until chromium has updated libpeerconnection to link with video_capture_impl and video_render_impl, webrtc target automatically depends on it. This should fix the FYI bots and not require a webrtc roll to fix.
Re-enable android tests by reverting 7026 (some tests left disabled).
TESTED: passes all the bots. If this inadvertently breaks a target please fix the linking rules so the target has the desired implementation linked in.
BUG=3770
R=kjellander@webrtc.org, pbos@webrtc.orgTBR=mflodman@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/19359004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7217 4adac7df-926f-26a2-2b94-8c16560cd09d
into its own targets. Dependencies must link directly with the desired one.
Targets linking with libjingle_media:
- internal implementation when build_with_chromium=0, default otherwise.
Targets linking with default/external capture implementation:
- anything dependent on webrtc_test_common
- anything dependent on video_engine_core
Targets linking with internal capture implementation:
- vie_auto_test
- anything dependent on webrtc_test_renderer
GN changes:
- Not many since there is almost no test definitions.
TESTED: passes all the bots. If this inadvertently breaks a target please fix the linking rules so the target has the desired implementation linked in.
BUG=3768
R=glaznev@webrtc.orgTBR=kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/24589004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7209 4adac7df-926f-26a2-2b94-8c16560cd09d
Replacing #include of "base/basictypes.h" in
overrides/webrtc/base/constructormagic.h with "base/macros.h". Our
version of constructormagic.h is not meant to include the base types,
only DISALLOW_COPY_AND_ASSIGN etc.
This fix is also a workaround for our overrides in Chromium seemingly
including the wrong things for certain webrtc targets like
audio_processing, so it looks like this #include "base/basictypes.h"
didn't include Chromium's base/basictypes.h but webrtc/base/basictypes.h
somehow, hence DISALLOW_COPY_AND_ASSIGN wasn't defined, causing the
revert in r7151.
R=henrike@webrtc.org, tommi@webrtc.org
BUG=3070
TEST=Chromium still builds locally with this change.
Review URL: https://webrtc-codereview.appspot.com/27509004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7204 4adac7df-926f-26a2-2b94-8c16560cd09d
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
Committed: https://code.google.com/p/webrtc/source/detail?r=7200
Review URL: https://webrtc-codereview.appspot.com/31369004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7201 4adac7df-926f-26a2-2b94-8c16560cd09d
