We use this Config struct for enabling/disabling Extended filter mode
in AEC. This change renames it to ExtendedFilter for readability
reasons. The corresponding media constraint is also renamed to
kExtendedFilterEchoCancellation.
The old Config is kept in parallel with the new during a transition
period. This is to avoid problems with API breakages. During this
period, if any of the two Configs are enabled, the extended filter
mode is engaged in APM. That is, the two Configs are combined with an
"OR" operation.
This change also renames experimental_aec in AudioOptions to extended_filter_aec.
BUG=4696
R=bjornv@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/54659004
Cr-Commit-Position: refs/heads/master@{#9378}
When initiating a call default audio options are applied, which turns on platform-AEC if such exists. Then, if delay agnostic AEC (DA-AEC) is enabled through a media constraint no action with respect to platform-AEC is taken (a bug) and turning on SW AEC. Hence, we run both AECs.
This CL makes sure the platform-AEC is disabled if we want to run DA-AEC.
BUG=
TESTED=locally on Nexus 4 and Nexus 6.
R=henrika@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/52049004
Cr-Commit-Position: refs/heads/master@{#9361}
This change connects currentAccelerateRate and currentPreemptiveRate
in webrtc::NetworkStatistics, through corresponding variables in
VoiceReceiverInfo, to googAccelerateRate and googPreemptiveExpandRate.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50179004
Cr-Commit-Position: refs/heads/master@{#9350}
This CL connects RTCConfiguration::audioJitterBufferFastMode in
PeerConnection.java, through libjingle, down to
NetEq::Config::enable_fast_accelerate in native WebRTC.
When enabled, it will allow NetEq to do faster time-compression when
the buffer level is very high.
BUG=4691
R=henrika@webrtc.org, mflodman@webrtc.org, pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/55479004
Cr-Commit-Position: refs/heads/master@{#9344}
BUG=4690
Changes:
1. In MediaEngineInterface changed CreateChannel() to CreateChannel(const AudioOptions&). Plan is to eventually remove Get/SetAudioOptions and the cousins SetDelayOffset and SetDevices.
2. In ChannelManager changed CreateVoiceChannel(...) to CreateVoiceChannel(..., const AudioOptions&).
3. In ChannelManager removed SetEngineAudioOptions, because it is not used and we want to eventually remove SetAudioOptions.
4. Updated MediaEngineInterface implementations and unit tests accordingly.
5. In WebRtcVoiceEngine changed access of Set/ClearOptionOverrides to protected. These are only used by WebRtcVoiceMediaChannel (now a friend). Plan is to rethink the logic behind option overrides.
6. Cosmetics: replaced NULL with nullptr in touched code
R=solenberg@google.com, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/56499004
Cr-Commit-Position: refs/heads/master@{#9330}
This avoids a deadlock in WebRtcVideoCapturer.
The deadlock could occur because OnIncomingFrame() has the |critical_section_stopping_| lock, which could block a Stop() on the |start_thread_|. When OnIncomingFrame() then tries to do synchronous invoke on |start_thread_| (before releasing said lock) we have a deadlock.
BUG=4670
R=magjed@webrtc.org, tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47259004
Cr-Commit-Position: refs/heads/master@{#9294}
BUG=4690
I have removed methods in VoE interfaces that were marked to be removed. I have removed them also in fake and mock implementations. I have also updated the callers in various ways:
1. Project win_test had some calls to the removed methods, but it turned out that the project is not used anymore, so I removed it entirely.
2. There were some calls to removed methods in jni methods. I have removed couple of jni methods as now they seem to do nothing.
3. With the remaining callers I just removed the calls to removed methods.
R=pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/53519004
Cr-Commit-Position: refs/heads/master@{#9281}
This is being done in preparation of moving base/logging.* to rtc_base_approved. base/stream.* has libjingle dependencies that webrtc can't use, so logging.* can't depend on streams. It does look like stream.* isn't used much, so cleaning that up as well as cleaning up usage of the actual stream support (now LogStream) in the logging code, is in order, but I'll leave that to another cl.
BUG=
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/54529004
Cr-Commit-Position: refs/heads/master@{#9269}
This fixes a bug where, if the VideoCapturer failed to start under certain circumstances, the capture manager would cause a callback saying that the capturer stopped even though it never started in the first place. A VERIFY check in VideoSource::SetState would then cause a crash since the state was set to kEnded when it was already in state kEnded (SetState only allows being called when the state changes).
I only noticed this bug while doing a mistake in a separate CL. Not sure how to reliably reproduce said bug on a working build, but I have previously had camera hardware issues where it couldn't start the camera which resulted in the SetState kEnded -> kEnded crash. Hopefully this will fix that.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51039004
Cr-Commit-Position: refs/heads/master@{#9259}
When a frame being stretched, the original rotation information is lost. This is to ensure it's carried over.
Also removed StretchToBuffer function as it's not called and dangerous.
BUG=4366
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/51869004
Cr-Commit-Position: refs/heads/master@{#9224}
Addressing discrepancy where NACK used to be set from send codecs in
WebRtcVideoEngine(1), and before this change, from recv codecs in
WebRtcVideoEngine2. This should address that NACK might be sent even if
the remote side does not support it.
BUG=4626
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/53409004
Cr-Commit-Position: refs/heads/master@{#9171}
Fixes bug where Chromium would send REMB even though the remote party
doesn't announce support for it (because it was based on local codec
settings instead of remote ones).
BUG=4626
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/54389004
Cr-Commit-Position: refs/heads/master@{#9170}
Attempts to get wireshark to decode the DTLS were problematic (wireshark only does it for certain versions of some DTLS implementations), so just do what firefox does and dump a txt2pcap-compatible log when requested.
R=pthatcher@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49159004
Cr-Commit-Position: refs/heads/master@{#9162}
This CL will change the behavior when enabling Delay Agnostic AEC through the media constraint (and AudioOption delay_agnostic_aec)
FROM
Use DA-AEC instead of AECM if there is no HW-AEC
TO
Use DA-AEC even if there is a HW-AEC
Before this change the user will not really know if the Delay Agnostic AEC is running or not, so it is more intuitive if the option overrides the built-in one if the user has asked for it.
BUG=4472
TESTED=locally with a modified AppRTCDemo app
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49859004
Cr-Commit-Position: refs/heads/master@{#9147}
Instead a ViECapturer object is allocated and directly operated on. This
additionally exposes ViESharedData to Call to access the module
ProcessThread, moving towards Call ownership of shared resources.
BUG=1695
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45339004
Cr-Commit-Position: refs/heads/master@{#9119}
Replaces interface usage with direct calls on ViEEncoder removing a
layer of indirection. Also removing some methods from ViEImageProcess
that were only added for Video{Send,Receive}Stream usage.
BUG=1695
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/45319004
Cr-Commit-Position: refs/heads/master@{#9111}
