As far as I observe, there are several reasons for this:
1. webrtc/modules/audio_coding/neteq4/neteq_impl.cc : 870
assert(new_codec_);
This is related to webrtc/modules/audio_coding/neteq4/decision_logic_normal.cc : 81
kUndefined can happen without new_codec_ being set
2. webrtc/modules/audio_coding/neteq4/neteq_impl.cc : 745
assert(sync_buffer_->FutureLength() >= expand_->overlap_length());
3. some other assert triggered.
The above happens not very often and goes away with no assertion.
3. (most common, this CL addresses this)
webrtc/modules/rtp_rtcp/source/rtp_receiver_audio.cc : 201
payload_data_length = payload_length - rtp_header->header.paddingLength;
There are situations that
payload_length < rtp_header->header.paddingLength;
OLD ACM + NetEq3 can handle this:
a) webrtc/modules/audio_coding/main/source/acm_neteq.cc : 477
int16_t payload_length = static_cast<int16_t>(length_payload);
payload_length becomes negative in this situation
b) webrtc/modules/audio_coding/neteq/recin.c
WebRtcNetEQ_RecInInternal() handles negative payload length
I do not want to touch VoE, so I tried to let ACM2 and NetEq4 handle negative payload length.
This CL does not follow the exact way of OLD ACM + NetEq3. I stopped negative payload length at ACM and did not allow it go to NetEq4.
To try this, apply my uploaded patch : https://webrtc-codereview.appspot.com/2281004/
Let me know if you see better solutions.
R=henrik.lundin@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2292005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4860 4adac7df-926f-26a2-2b94-8c16560cd09d
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
To run this test, the executable in
libjingle_peerconnection_objc_test.app/Contents/MacOS/libjingle_peerconnection_objc_test
must be run. Running executables like this is not supported by
the buildbot scripts, which makes the paths to the stdio invalid.
Adding it to our command-line wrapping script and executing it as
'libjingle_peerconnection_objc_test' on the bots should work around
this limitation.
BUG=2120
TEST=locally building and executing the test on Mac using:
GYP_DEFINES="host_arch=x64 target_arch=x64" gclient runhooks
ninja -C out/Release
out/Release/buildbot_tests.py -t libjingle_peerconnection_objc_test
R=phoglund@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/2275007
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4826 4adac7df-926f-26a2-2b94-8c16560cd09d
