Re-land: http://review.webrtc.org/2151007/TBR=bjornv@webrtc.org
Original change description:
This mode extends the filter length from the current 48 ms to 128 ms.
It is runtime selectable which allows it to be enabled through
experiment. We reuse the DelayCorrection infrastructure to avoid having
to replumb everything up to libjingle.
Increases AEC complexity by ~50% on modern x86 CPUs.
Measurements (in percent of usage on one core):
Machine/CPU Normal Extended
MacBook Retina (Early 2013),
Core i7 Ivy Bridge (2.7 GHz, hyperthreaded) 0.6% 0.9%
MacBook Air (Late 2010), Core 2 Duo (2.13 GHz) 1.4% 2.7%
Chromebook Pixel, Core i5 Ivy Bridge (1.8 GHz) 0.6% 1.0%
Samsung ARM Chromebook,
Samsung Exynos 5 Dual (1.7 GHz) 3.2% 5.6%
The relative value is large of course but the absolute should be
acceptable in order to have a working AEC on some platforms.
Detailed changes to the algorithm:
- The filter length is changed from 48 to 128 ms. This comes with tuning
of several parameters: i) filter adaptation stepsize and error
threshold; ii) non-linear processing smoothing and overdrive.
- Option to ignore the reported delays on platforms which we deem
sufficiently unreliable. Currently this will be enabled in Chromium for
Mac.
- Faster startup times by removing the excessive "startup phase"
processing of reported delays.
- Much more conservative adjustments to the far-end read pointer. We
smooth the delay difference more heavily, and back off from the
difference more. Adjustments force a readaptation of the filter, so they
should be avoided except when really necessary.
Corresponds to these changes:
https://chromereviews.googleplex.com/9412014https://chromereviews.googleplex.com/9514013https://chromereviews.googleplex.com/9960013
BUG=454,827,1261
Review URL: https://webrtc-codereview.appspot.com/2295006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4848 4adac7df-926f-26a2-2b94-8c16560cd09d
DWM doesn't update window decorations in bitmap captured
from GetWindowDC(). Work it around by calling PrintWindow()
after each resize (which somehow affects what's later
captured from GetWindowDC()). That solution avoids the
downsides of PrintWindow() (namely flickering) while still
allowing to capture window decorations correctly.
BUG=crbug.com/289759
R=alexeypa@chromium.org
Review URL: https://webrtc-codereview.appspot.com/2295004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4847 4adac7df-926f-26a2-2b94-8c16560cd09d
The map was just mapping an index to a pointer of a POD, so the code is easily
simplified by using a vector (with implicit index key) and the POD as a value.
(also fixes a leak in the windows code, which lacked a virtual dtor for
VideoCaptureCapabilityWindows but was deleting through a base pointer).
R=perkj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2298004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4840 4adac7df-926f-26a2-2b94-8c16560cd09d
> Add an extended filter mode to AEC.
>
> This mode extends the filter length from the current 48 ms to 128 ms.
> It is runtime selectable which allows it to be enabled through
> experiment. We reuse the DelayCorrection infrastructure to avoid having
> to replumb everything up to libjingle.
>
> Increases AEC complexity by ~50% on modern x86 CPUs.
> Measurements (in percent of usage on one core):
>
> Machine/CPU Normal Extended
> MacBook Retina (Early 2013),
> Core i7 Ivy Bridge (2.7 GHz, hyperthreaded) 0.6% 0.9%
>
> MacBook Air (Late 2010), Core 2 Duo (2.13 GHz) 1.4% 2.7%
>
> Chromebook Pixel, Core i5 Ivy Bridge (1.8 GHz) 0.6% 1.0%
>
> Samsung ARM Chromebook,
> Samsung Exynos 5 Dual (1.7 GHz) 3.2% 5.6%
>
> The relative value is large of course but the absolute should be
> acceptable in order to have a working AEC on some platforms.
>
> Detailed changes to the algorithm:
> - The filter length is changed from 48 to 128 ms. This comes with tuning
> of several parameters: i) filter adaptation stepsize and error
> threshold; ii) non-linear processing smoothing and overdrive.
> - Option to ignore the reported delays on platforms which we deem
> sufficiently unreliable. Currently this will be enabled in Chromium for
> Mac.
> - Faster startup times by removing the excessive "startup phase"
> processing of reported delays.
> - Much more conservative adjustments to the far-end read pointer. We
> smooth the delay difference more heavily, and back off from the
> difference more. Adjustments force a readaptation of the filter, so they
> should be avoided except when really necessary.
>
> Corresponds to these changes:
> https://chromereviews.googleplex.com/9412014
> https://chromereviews.googleplex.com/9514013
> https://chromereviews.googleplex.com/9960013
>
> BUG=454,827,1261
> R=bjornv@webrtc.org
>
> Review URL: https://webrtc-codereview.appspot.com/2151007TBR=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2296005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4839 4adac7df-926f-26a2-2b94-8c16560cd09d
This mode extends the filter length from the current 48 ms to 128 ms.
It is runtime selectable which allows it to be enabled through
experiment. We reuse the DelayCorrection infrastructure to avoid having
to replumb everything up to libjingle.
Increases AEC complexity by ~50% on modern x86 CPUs.
Measurements (in percent of usage on one core):
Machine/CPU Normal Extended
MacBook Retina (Early 2013),
Core i7 Ivy Bridge (2.7 GHz, hyperthreaded) 0.6% 0.9%
MacBook Air (Late 2010), Core 2 Duo (2.13 GHz) 1.4% 2.7%
Chromebook Pixel, Core i5 Ivy Bridge (1.8 GHz) 0.6% 1.0%
Samsung ARM Chromebook,
Samsung Exynos 5 Dual (1.7 GHz) 3.2% 5.6%
The relative value is large of course but the absolute should be
acceptable in order to have a working AEC on some platforms.
Detailed changes to the algorithm:
- The filter length is changed from 48 to 128 ms. This comes with tuning
of several parameters: i) filter adaptation stepsize and error
threshold; ii) non-linear processing smoothing and overdrive.
- Option to ignore the reported delays on platforms which we deem
sufficiently unreliable. Currently this will be enabled in Chromium for
Mac.
- Faster startup times by removing the excessive "startup phase"
processing of reported delays.
- Much more conservative adjustments to the far-end read pointer. We
smooth the delay difference more heavily, and back off from the
difference more. Adjustments force a readaptation of the filter, so they
should be avoided except when really necessary.
Corresponds to these changes:
https://chromereviews.googleplex.com/9412014https://chromereviews.googleplex.com/9514013https://chromereviews.googleplex.com/9960013
BUG=454,827,1261
R=bjornv@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2151007
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4837 4adac7df-926f-26a2-2b94-8c16560cd09d
Background:
In Chrome mirroring which uses 500ms buffering mode,
audio video mismatch happens in the begining because of the lack of the api.
BUG=b/10538425
TEST=pass 'git try' except tests which is aleady broken in the bot. pass 'build/android/test_runner.py gtest -s modules_tests --verbose --release -f *InitialPlayoutDelayTest*'
R=henrika@webrtc.org, turaj@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2177004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4807 4adac7df-926f-26a2-2b94-8c16560cd09d
First patch set is the same as patch set 3 of http://review.webrtc.org/2237004/
-Make ACM1 to depend on ACM2.
-Remove APIs to set and get background noise mode. There is no VoE call to these
APIs.
-Remove APIs to set and get receive side VAD mode. There is no VoE call to these
APIs, and NetEq 4, doesn't support them.
-Remove callback for in-band DTMF detection. ACM doesn't support in-band DTMF
detection.
-Use acm_common_defs.h everywhere required.
-Complete ACM factory method.
-Update ACMCodecDatabase of ACM2. CNG full-band need to be define-guarded.
Remove dynamic payload-type assignment.
BUG=
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2249004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4785 4adac7df-926f-26a2-2b94-8c16560cd09d
-Make ACM1 to depend on ACM2.
-Remove APIs to set and get background noise mode. There is no VoE call to these APIs.
-Remove APIs to set and get receive side VAD mode. There is no VoE call to these APIs, and NetEq 4, doesn't support them.
-Remove callback for in-band DTMF detection. ACM doesn't support in-band DTMF detection.
-Use acm_common_defs.h everywhere required.
-Complete ACM factory method.
-Update ACMCodecDatabase of ACM2. CNG full-band need to be define-guarded. Remove dynamic payload-type assignment.
BUG=
R=andrew@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2237004
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4772 4adac7df-926f-26a2-2b94-8c16560cd09d
