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}
A better solution than forcing OPUS_APPLICATION_VOIP when enabling DTX has been found, which is to set OPUS_SIGNAL_VOICE.
This reduces the uncertainty of entering DTX over silence period of audio.
This CL contains the setup of OPUS_SIGNAL_VOICE and decoupling opus application mode with DTX.
BUG=4559
R=henrik.lundin@webrtc.org, henrika@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/46959004
Cr-Commit-Position: refs/heads/master@{#9168}
The main purpose of this CL is to clean up RTCPSender::PrepareRTCP, but
it has quite a few ramifications. Notable changes:
* Removed the rtcpPacketTypeFlags bit vector and don't assume
RTCPPacketType values have a single unique bit set. This will allow
making this an enum class once rtcp_receiver has been overhauled.
* Flags are now stored in a map that is a member of the class. This
meant we could remove some bool flags (eg send_remb_) which was
previously masked into rtcpPacketTypeFlags and then masked out again
when testing if a remb packet should be sent.
* Make all build methods, eg. BuildREMB(), have the same signature.
An RtcpContext struct was introduced for this purpose. This allowed
the use of a map from RTCPPacketType to method pointer. Instead of
18 consecutive if-statements, there is now a single loop.
The context class also allowed some simplifications in the build
methods themselves.
* A few minor simplifications and cleanups.
The next step is to gradually replace the builder methods with the
builders from the new RtcpPacket classes.
BUG=2450
R=asapersson@webrtc.org, pbos@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48329004
Cr-Commit-Position: refs/heads/master@{#9166}
When compiling against an OSX 10.7+ SDK, explicitly redeclare methods only
available from an OSX 10.7+ SDK. This suppresses the clang warning
-Wpartial-availability, which will be turned on in the future.
BUG=chromium:471823
R=jiayl@webrtc.org, mark@chromium.org
Review URL: https://webrtc-codereview.appspot.com/44359004
Cr-Commit-Position: refs/heads/master@{#9163}
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}
Instantiates ProcessThread/ChannelGroup inside Call instead of using
VideoEngine or ViEBase. This removes the need for ViEChannelManager,
ViEInputManager and other ViESharedData completely.
Some interface headers are still referenced due to external interfaces
being defined there. Upon interface removal these will be moved to
implementation headers.
BUG=1695
R=mflodman@webrtc.org, stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50849005
Cr-Commit-Position: refs/heads/master@{#9160}
This adds functionality from audioproc_float. The geometry parsing code
is now shared from test_utils.h. I removed the "mic_spacing" flag from
audioproc_float because it's a redundancy that I suspect isn't very
useful.
Includes a cleanup of the audio_processing test utils. They're now
packaged in targets, with the protobuf-using ones split out to avoid
requiring users to depend on protobufs.
pcm_utils is no longer needed and removed.
The primary motivation for this CL is that AudioProcessing currently
doesn't support more than two channels and we'd like a way to pass
more channels to the beamformer.
R=aluebs@webrtc.org, mgraczyk@chromium.org
Review URL: https://webrtc-codereview.appspot.com/50899004
Cr-Commit-Position: refs/heads/master@{#9157}
CodecOwner is introduced here; AudioEncoderMutable was introduced in a
previous commit, but had no users until now. The only remaining task
for ACMGenericCodec was to construct and maintain the stack of speech,
CNG, and RED encoders. This task is now handled by the CodecOwner,
which is owned and used by the CodecManager.
COAUTHOR=henrik.lundin@webrtc.org
BUG=4228
R=jmarusic@webrtc.org, minyue@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43189004
Cr-Commit-Position: refs/heads/master@{#9152}
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}
The implementation of this proposal is in progress.
More unittest will be added.
Sender side is being implemented.
Some constants need to be tuned.
BUG=4550
R=stefan@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/43299004
Cr-Commit-Position: refs/heads/master@{#9146}
Changes:
1. Documented return values of VoENetwork methods.
2. In VoENetworkImpl: replaced calls to SetLastError() with LOG_F(). SetLastError() is not used anymore because no one is calling LastError() to check for last error. Also, its usage is being removed in Video Engine and we want to be consistent.
3. In VoENetworkImpl: removed WEBRTC_TRACE() usage.
4. In VoENetworkImpl: replaced some defensive code with assert(). We are now assuming that the caller has called VoEBase::Init() where needed. We are also assuming that it is invalid to pass nullptr where data is expected.
5. Updated unit tests accordingly.
R=henrika@webrtc.org, kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/53369004
Cr-Commit-Position: refs/heads/master@{#9145}
When running AEC in extended_filter mode there is no startup phase to evaluate the reported system delay values.
Instead we simply use the first value and scale by two to avoid over compensating when synchronizing render and capture.
We don't need to be too accurate since we have extended the filter length.
On Android we use fixed (measured) reported delay values.
There is no need to be extra conservative here, because that is already built-in in the measured value.
In fact, the difference between devices is large and with such an extra conservative approach the true delay can not be caught by the filter length.
With this change we can improve performance on some devices.
BUG=4472
TESTED=offline on recordings from various devices
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/49909004
Cr-Commit-Position: refs/heads/master@{#9144}
The delay estimator has a robust_validation mode used to deliver more stable delay etimates. The cost is increased reaction time when we have a delay jump.
This mode can be turned on and off on the fly, but statistics are not updated while disabled. This makes the estimator unreliable if it is enabled on the fly.
This CL makes sure the update is always done.
BUG=4472
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50889004
Cr-Commit-Position: refs/heads/master@{#9143}
For quick and easy aecdump verifiation storing data as text speeds up the issue tracking process, since anyone can simply view values like mic volume.
BUG=4609
TESTED=verified unpacking an aecdump with flag --txt stores that data in text files
R=kwiberg@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/50849004
Cr-Commit-Position: refs/heads/master@{#9142}
Passed building isac_neon and modules_unittests on Android ARMv7.
Passed modules_unittests with following filters:
--gtest_filter=FiltersTest*
--gtest_filter=LpcMaskingModelTest*
--gtest_filter=TransformTest*
--gtest_filter=FilterBanksTest*
WebRtcIsacfix_CalculateResidualEnergyNeon is removed, refer more in
Issue 4224.
The old review url is at: https://webrtc-codereview.appspot.com/37259004/
BUG=4002
R=andrew@webrtc.org, jridges@masque.com, kjellander@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48319005
Patch from Zhongwei Yao <zhongwei.yao@arm.com>.
Change-Id: I4c16e15930f1b3449d67b67bf023fac28121dff8
Cr-Commit-Position: refs/heads/master@{#9140}
Introduces a new capture class derived from cricket::VideoCapturer that
provides the ability to switch cameras and updates AppRTCDemo to use it.
Some future work pending to clean up AppRTCDemo UI.
BUG=4070
R=magjed@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/48279005
Cr-Commit-Position: refs/heads/master@{#9137}
This CL makes two changes to rtc::Buffer that have had to wait for
Chromium's use of it to be modernized:
1. Change default return type of rtc::Buffer::data() from char* to
uint8_t*. uint8_t is a more natural type for bytes, and won't
accidentally convert to a string. (Chromium previously expected
the default return type to be char, which is why
rtc::Buffer::data() initially got char as default return type in
9478437f, but that's been fixed now.)
2. Stop accepting void* inputs in constructors and methods. While
this is convenient, it's also dangerous since any pointer type
will implicitly convert to void*.
(This was previously committed (9e1a6d7c) but had to be reverted
(cbf09274) because Chromium on Android wasn't quite ready for it).
TBR=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/47109004
Cr-Commit-Position: refs/heads/master@{#9132}
This CL makes two changes to rtc::Buffer that have had to wait for
Chromium's use of it to be modernized:
1. Change default return type of rtc::Buffer::data() from char* to
uint8_t*. uint8_t is a more natural type for bytes, and won't
accidentally convert to a string. (Chromium previously expected
the default return type to be char, which is why
rtc::Buffer::data() initially got char as default return type in
9478437f, but that's been fixed now.)
2. Stop accepting void* inputs in constructors and methods. While
this is convenient, it's also dangerous since any pointer type
will implicitly convert to void*.
R=tommi@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/44269004
Cr-Commit-Position: refs/heads/master@{#9121}
