This CL introduces the handling of multiple microphone channels in
the EchoRemover layer.
The implementation is done such as to support an arbitrary number of
channels in a way that balances stack and heap-space usage.
Bug: webrtc:10913
Change-Id: I475369de6c463b8fe2d7e53799d7322eefb6938f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151647
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29140}
The existing restriction of max 48k seems old and outdated. I am unable to
see any issues by simply extending the support to 96 and utilize the existing
resampler in WebRTC. There are no memory limitations involved either.
It is a rather common case today in Chrome that users need 96k/192k input; hence this
simple change will have a positive impact for many WebRTC clients using gUM.
Bug: webrtc:10958
Test: https://webrtc.github.io/samples/src/content/peerconnection/audio/ using mic @96k
Change-Id: I8123da886ef7d48cbec9482795ec837ec1f61d81
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152162
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29135}
Multichannel signals are downmixed to mono before decimation and
delay estimation. This is useful when not all channels play
audio content. The feature can be toggled in the AEC3 configuration.
Bug: webrtc:10913
Change-Id: I7d40edf7732bb51fec69e7f3ca063d821c5069c4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151762
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29126}
A followup cl will move VideoCodingModule and related code into this
target.
Bug: webrtc:7408
Change-Id: Iade572b597769456c9b8c76f584500e2bd9a58f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152280
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29122}
This reverts commit 9e380fd484db09c37323b90a19c5ce7965927975.
Reason for revert: breaking downstream projects
Original change's description:
> Improve performance of RtpPacketHistory
>
> The data structures in RtpPacketHistory were chosen based on assumption
> of few packets with possible sparse segments due to missing acking.
> In practice high bitrate usages with full histories seem to be more of
> a problem.
> Due to that, change storage from an std::map to an std::deque and live
> with potential segments of nullptr. Also limit size of padding prio
> set so that doesn't become a bottleneck.
>
> Bug: webrtc:8975
> Change-Id: I3b6314fb3255937d25362ff2cd906efb7b1397f7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145901
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29117}
TBR=danilchap@webrtc.org,sprang@webrtc.org
Change-Id: I5d5b74a6f4d60588e01a52dafe33e26deb9bdf77
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:8975
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/152220
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Commit-Queue: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29121}
The data structures in RtpPacketHistory were chosen based on assumption
of few packets with possible sparse segments due to missing acking.
In practice high bitrate usages with full histories seem to be more of
a problem.
Due to that, change storage from an std::map to an std::deque and live
with potential segments of nullptr. Also limit size of padding prio
set so that doesn't become a bottleneck.
Bug: webrtc:8975
Change-Id: I3b6314fb3255937d25362ff2cd906efb7b1397f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145901
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29117}
Reland with fixes for fuzzer found crashes.
This refactoring helps to reduce unnecessary memcpy calls on the receive side.
This CL replaces |uint8 data[IP_PACKET_SIZE]| with |rtc::CopyOnWriteBuffer data| in Packet class, removes |length| field there, and does necessary changes.
Original Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/145332
Bug: webrtc:10750
Change-Id: I6775a701bcb2ae25ec1666e1db90041cd49013b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151131
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29116}
The vcm::VideoReceiver class is used by both VideoReceiveStream and
the legacy api VideoCodingModule. They have different requirements,
since the latter uses the old jitterbuffer and runs the code on a
ProcessThread.
By making a copy and trimming it down to what's actually used by
VideoReceiveStream, we can drop the dependency on the old
jitterbuffer, without breaking the legacy api. This should also make
it easier to do follow-up refactorings to trim down the class further,
and ultimately remove it.
Bug: webrtc:7408
Change-Id: Iec8a167fe5d0425114b0b67a5b4c2fd5fc4fa150
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151910
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29108}
if higher layer is enabled, then disabled, then key-frame is issued, then
the layer is enabled again, the buffer would contain a picture from before
the key-frame and it might have a higher pid than the currently encoded one.
This would trigger the DCHECK. It's safe to remove the DCHECK completely, because
such occasions would cause unsigned overflow and cause the following check for
maximum allowed picture difference to fail and the wrong picture won't
be used as a temporal reference.
This error only caused failures in debug builds and couldn't lead to corruptions
because there're periodical key-frames generated and pid difference can never become so
big that negative value would overflow to something close to 0.
Bug: webrtc:10257
Change-Id: Ie3b3ed0e24421787e3b40a37987ccecb75d04635
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151643
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29099}
This CL reduces the complexity and heap usage of the adaptive filter
in AEC3 by avoiding to compute these for the shadow
filter. In particular it
-Moves to compute the ERL, frequency response and impulse response
on an on-demand basis.
-Stores the ERL, frequency response and impulse response outside
of the adaptive filter.
All the changes have been tested for bitexactness on a sizeable
amount of recordings.
Bug: webrtc:10913
Change-Id: If83c236a6e3f2e489be129b9ebf6143a72f521d1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151138
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29081}
All channels are populated by RenderDelayBuffer. but all other
dependent modules are hardcoded to do their regular mono processing
on the first channel.
Bug: webrtc:10913
Tested: Bitexactness on a large set of aecdumps
Change-Id: I11d11aa0ad3da0f244c0ec020d2c9f0f4a735834
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151640
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29079}
The VectorBuffer and MatrixBuffer names are too generic for their use case.
Bug: webrtc:10913
Change-Id: Ideecd0d27e07487a85a61dc6474e69733d07dcd6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151602
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29076}
All dependent modules are hardcoded to do their regular mono processing on the first channel.
This _almost_ makes RenderBuffer multi-channel: FftData is still only mono.
Bug: webrtc:10913
Change-Id: Id5cc34dbabfe59e1cc72a9675dc7979794e870ed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151139
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29074}
This behavior seems to conform to expectations from the rate allocators,
using this signal to chose which layers to enable and then distributing
the remaining bandwidth to the activated layers.
Bug: webrtc:10126
Change-Id: If0e1b27dc672ec2fbb30a5f5ac734e5ed4b42e45
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151306
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29065}
This CL propagates the number of render and capture channels into
the echo subtractor and the adaptive filters.
Bug: webrtc:10913
Change-Id: I5ffff24ff64b7cc0f262bf008b34b6dfca1e78f9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151300
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29059}
Update the |cumulative_lost_| counter per received packet. The rules
follow from RFC 3550 and are fairly simple: Decrement the counter by
one for every received packet. For every in-order packet, i.e., increasing
|received_seq_max_|, add that change to |cumulative_lost_|.
Net change is zero as long as packets are received in proper sequence.
This way, GetStats() always returns an up-to-date value, independent
of the timing of RTCP report blocks.
For RTCP reports, keep a workaround to never report negative cumulative loss.
Bug: webrtc:10679
Change-Id: I47ff3bf266ff2382f405ec9828d34f7fad7068b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150641
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29058}
These fixes are automatically created by various analysis tools, but have been manually triggered to be applied.
* the 'empty' method should be used to check for emptiness instead of 'size' (3 times)
* using decl 'Return' is unused (4 times)
* using decl '_' is unused (3 times)
* using decl 'DoAll' is unused (2 times)
* using decl 'SetArgPointee' is unused
* using decl 'Dlrr' is unused
* using decl 'IsEmpty' is unused
* redundant get() call on smart pointer
* using decl 'Invoke' is unused (2 times)
* using decl 'SizeIs' is unused (3 times)
* using decl 'make_tuple' is unused
* using decl 'NiceMock' is unused
* using decl 'SaveArg' is unused (2 times)
* using decl 'AtLeast' is unused
* using decl 'ElementsAre' is unused
* using decl 'Gt' is unused
Bug: None
Change-Id: I97658fb0e94620b8319d7c3da29b15e27ec23188
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151133
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29056}
This is a reland of a66395e72f9fc86873bf443579ec73c3d78af240
Original change's description:
> Reland "Add core multi-channel pipeline in AEC3 This CL adds basic the basic pipeline to support multi-channel processing in AEC3."
>
> This is a reland of f3a197e55323aee974a932c52dd19fa88e5d4e38
>
> Original change's description:
> > Add core multi-channel pipeline in AEC3
> > This CL adds basic the basic pipeline to support multi-channel
> > processing in AEC3.
> >
> > Apart from that, it removes the 8 kHz processing support in several
> > places of the AEC3 code.
> >
> > Bug: webrtc:10913
> > Change-Id: If5b75fa325ed0071deea94a7546cb4a7adf22137
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150332
> > Commit-Queue: Per Åhgren <peah@webrtc.org>
> > Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#29017}
>
> Bug: webrtc:10913
> Change-Id: Ifc4b13bd994cfd22dca8f8755fa5700617cc379d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151124
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Commit-Queue: Per Åhgren <peah@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29034}
Bug: webrtc:10913
Change-Id: Id8da5666df8c86f290c73ad5dc9958199f1a7ebe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151127
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29042}
This metric is not used anywhere and is not calculated correctly when the delay manager is in relative arrival delay mode.
Bug: webrtc:10333
Change-Id: Iac79ab40b79b17802ad9d626c130e82f761bae26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150786
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29037}
This is a reland of f3a197e55323aee974a932c52dd19fa88e5d4e38
Original change's description:
> Add core multi-channel pipeline in AEC3
> This CL adds basic the basic pipeline to support multi-channel
> processing in AEC3.
>
> Apart from that, it removes the 8 kHz processing support in several
> places of the AEC3 code.
>
> Bug: webrtc:10913
> Change-Id: If5b75fa325ed0071deea94a7546cb4a7adf22137
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150332
> Commit-Queue: Per Åhgren <peah@webrtc.org>
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29017}
Bug: webrtc:10913
Change-Id: Ifc4b13bd994cfd22dca8f8755fa5700617cc379d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151124
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29034}
The change is behind a field trial. The intention is to use this
to (heuristically) base the bandwidth estimate only on video packets
even if both audio and video packets have transport sequence numbers.
Bug: webrtc:10932
Change-Id: I6cc5bb9ab6f1a3f25b84ee6ac78e4abb4112032e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150787
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29031}
This reverts commit 7db900e2e78d1644a173a0bc505ad52c61c43f9b.
Reason for revert: Speculative revert
Original change's description:
> Simplify pacer queue
>
> This CL simplifies the pacer queue by removing the now unnecessary
> beginpop/cancelpop/finalizepop methods. Instead there's a const top()
> and a pop() much like an stl queue.
> Old methods using the deprecated pacing code path are cleaned away.
>
> Bug: webrtc:10633
> Change-Id: Ib6da4d46a571bf56415172b790cc9e3f63206a38
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150522
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Philip Eliasson <philipel@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#28997}
TBR=sprang@webrtc.org,philipel@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:10633
Change-Id: I38f61afed4f4d542e236bcce3152a3aab52c6e6b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/151120
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29030}
This reverts commit f3a197e55323aee974a932c52dd19fa88e5d4e38.
Reason for revert: Speculative revert, as this may'be broken some build bots
Original change's description:
> Add core multi-channel pipeline in AEC3
> This CL adds basic the basic pipeline to support multi-channel
> processing in AEC3.
>
> Apart from that, it removes the 8 kHz processing support in several
> places of the AEC3 code.
>
> Bug: webrtc:10913
> Change-Id: If5b75fa325ed0071deea94a7546cb4a7adf22137
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150332
> Commit-Queue: Per Åhgren <peah@webrtc.org>
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29017}
TBR=saza@webrtc.org,peah@webrtc.org
Change-Id: I877d2993b9ccf024bd1d57bca1513c3e24d0bed3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10913
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150940
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29022}
This CL adds basic the basic pipeline to support multi-channel
processing in AEC3.
Apart from that, it removes the 8 kHz processing support in several
places of the AEC3 code.
Bug: webrtc:10913
Change-Id: If5b75fa325ed0071deea94a7546cb4a7adf22137
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150332
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29017}
This CL increases the maximum supported sample rate so that all rates
up to 384000 Hz are handled.
The CL also adds tests that verifies that APM works as intended for
different combinations of number of channels and sample rates.
Bug: webrtc:10882
Change-Id: I98738e33ac21413ae00fec10bb43b8796ae2078c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150532
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29014}
Also adding code in preparation of hiding the Module
implementation in PacedSender. The implementation details of
how the PacedSender+ProcessThread interaction works, has now
been moved into PacedSender (and out of RtpTransportControllerSend).
Instead of adding a "GetModuleImplementationForTesting" method
to the PacedSender class (which would have been the lazy way
out), I incorporated MockedProcessThread in the PacedSender tests.
This means more boilerplate code but the Module functionality
can be tested separately from the PacedSender and down the line
I think it would be a good idea to start using a separate thread
in the test, which is how the class under test is really used
in production.
Bug: none
Change-Id: Iec1b7c97cb0b363b331143ca70545e6ebafe2cd4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/149176
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29011}
There are a few reasons for making this test only:
* The code is only used by tests and utilities.
* The pure interface has only a single implementation so an interface isn't really needed.
(a followup change could remove it altogether)
* The implementation always incorporates locking regardless of how the class gets used.
See e.g. previous use in the Packet class.
* The implementation is a layer on top of RtpUtility::RtpHeaderParser which is
sufficient for most production cases.
Change-Id: Ide6d50567cf8ae5127a2eb04cceeb10cf317ec36
Bug: none
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/150658
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29010}
