Before this change it could happen that a large jump in timestamp (a
jump not correlated to wall-clock change) caused the audio to go silent
without recovering. The reason was that all incoming packets after the
jump were considered too old compared to the last decoded packet, and
were deleted. With CL changes two things:
1. If the only available packet in the buffer is an old packet, NetEq
will do Expand instead of immediate reset. This is to avoid that one
late packet triggers a reset.
2. Old packets are discarded only when the decision to decode a packet
has been taken. This is to allow the buffer to grow and eventually
flush if no decodable packet has been found for some time.
This CL also includes a new unit test for this situation.
BUG=3785
R=minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/22709004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@7255 4adac7df-926f-26a2-2b94-8c16560cd09d
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
