This CL significantly improves the response time
of the AEC3 delay estimator to audio buffer issues.
The CL adds ensures that the delay estimator
correlators reacts to buffer issues from the
zero state which is much faster than if it has already
achieved a state matching a previous alignment.
The CL has been extensively tested on offline
recordings.
Bug: webrtc:9023, chromium:822245
Change-Id: Ic149b9429e592d4c3535eb8432582f435a1b4745
Reviewed-on: https://webrtc-review.googlesource.com/62081
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22461}
This CL prepares for adding the BBR network controller and
unit tests for GoogCC network controller.
The changes include:
* Adding pad_rate helper method on PacerConfig.
* Adding ostream operators for controller feedback structs.
* Adding increment operator to Timestamp class.
* Adding kEpoch to Timestamp class to represent 0.
* Rounding when multiplying with double.
Bug: webrtc:8415
Change-Id: I58289f37a6f9f2eee0a88bb06fb24dc295942862
Reviewed-on: https://webrtc-review.googlesource.com/61503
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22458}
We currently have one build target containing everything for audio_device: the interfaces,
the "fine" audio buffer, and the actual implementations for each platform.
Since we are planning to move the Android implementation to the sdk/android folder,
we only want to depend on the interfaces and the "fine" audio buffer, not the other platform
specific implementations. This CL splits the audio_device target into three different targets:
the interfaces, the fine audio buffer, and the platform specific implementations. The default
audio_device target now points to the interfaces instead.
Bug: webrtc:7452
Change-Id: I57e849cc6f4087d950fa02d969ecc682934839cd
Reviewed-on: https://webrtc-review.googlesource.com/61321
Commit-Queue: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Patrik Höglund <phoglund@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22452}
This CL ensures a smooth transition from the parameters used during
the startup phase in the call to the parameters used in the rest of the
call. This is achieved by slowly transitioning between the parameter
sets via interpolation.
Bug: chromium:819240,webrtc:8983
Change-Id: Ifbac4b93fc6ad6efc441f41fb88ef09e8ee3d669
Reviewed-on: https://webrtc-review.googlesource.com/60360
Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22451}
The interface of the audioproc_f tool should be located in the api/ directory, so it becomes visible to the outside world.
Bug: webrtc:8732
Change-Id: Ia7475883aeb0e1f7a6afa5e791204b38dc53a8b8
Reviewed-on: https://webrtc-review.googlesource.com/61801
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22449}
It previously owned only the picture id and only in the
WebRTC-VP8-Forced-Fallback-Encoder-v2 experiment.
Moving responsibility to PayloadRouter ensures that both
picture id and tl0 idx are continuous over codec changes,
as required by the specs for VP8 and VP9 over RTP.
Bug: webrtc:8830
Change-Id: Ie77356dfec6d1e372b6970189e4c3888451920e6
Reviewed-on: https://webrtc-review.googlesource.com/61640
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22448}
This work is in preparation for refactoring the TemporalLayers api.
Bug: webrtc:9012
Change-Id: I01908ee034fb79996e687ff72d10178acf102321
Reviewed-on: https://webrtc-review.googlesource.com/61781
Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22445}
We want to know how the AudioMixer is used and how FixedGainController
behaves.
The WebRTC.Audio.Agc2.FixedDigitalGainCurveRegion.* metrics measures
how often the input level hits different regions of the Fixed Gain
Controller gain curve (when the limiter is enabled). They also measure
how long the metrics stay in different regions. They are related to
WebRTC.Audio.ApmCaptureOutputLevelPeakRms, but the new metrics measure
the level before any processing done in APM.
The AudioMixer mixes incoming audio streams. Their number should be
mostly constant, and often some of them could be muted. The metrics
WebRTC.Audio.AudioMixer.NumIncomingStreams,
WebRTC.Audio.AudioMixer.NumIncomingActiveStreams log the number of
incoming stream and how many are not muted. We currently don't have
any stats related to that.
The metric WebRTC.Audio.AudioMixer.MixingRate logs the rate selected
for mixing. The rate can sometimes be inferred from
WebRTC.Audio.Encoder.CodecType. But that metric measures encoding and
not decoding, and codecs don't always map to rates.
See also accompanying Chromium CL
https://chromium-review.googlesource.com/c/chromium/src/+/939473
Bug: webrtc:8925
Change-Id: Ib1405877fc1b39e5d2f0ceccba04434813f20b0d
Reviewed-on: https://webrtc-review.googlesource.com/57740
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Alex Loiko <aleloi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22443}
This is a reland of 6328d7cbbc8a72fdc81a766c0bf4039e1e2e7887
Original change's description:
> Rework rtp packet history
>
> This CL rewrites the history from the ground up, but keeps the logic
> (mostly) intact. It does however lay the groundwork for adding a new
> mode where TransportFeedback messages can be used to remove packets
> from the history as we know the remote end has received them.
>
> This should both reduce memory usage and make the payload based padding
> a little more likely to be useful.
>
> My tests show a reduction of ca 500-800kB reduction in memory usage per
> rtp module. So with simulcast and/or fec this will increase. Lossy
> links and long RTT will use more memory.
>
> I've also slightly update the interface to make usage with/without
> pacer less unintuitive, and avoid making a copy of the entire RTP
> packet just to find the ssrc and sequence number to put into the pacer.
>
> The more aggressive culling is not enabled by default. I will
> wire that up in a follow-up CL, as there's some interface refactoring
> required.
>
> Bug: webrtc:8975
> Change-Id: I0c1bb528f32eeed0fb276b4ae77ae3235656980f
> Reviewed-on: https://webrtc-review.googlesource.com/59441
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#22347}
Bug: webrtc:8975
Change-Id: I162cb9a1eccddf567bdda7285f8296dc2f005503
Reviewed-on: https://webrtc-review.googlesource.com/60900
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Original-Commit-Position: refs/heads/master@{#22356}
Reviewed-on: https://webrtc-review.googlesource.com/61661
Cr-Commit-Position: refs/heads/master@{#22438}
Since the echo detector processes both the render and the capture audio streams, it needs to know the sample rates and number of channels of both.
Bug: webrtc:8732
Change-Id: Icd26e561d5dd98bd789a6dfa75f468f3fde06fee
Reviewed-on: https://webrtc-review.googlesource.com/61861
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22436}
This CL corrects the bug that only looked at narrowband
render signals above 900 Hz and only assumed that the
influence of such lasted for 6 blocks, which resulted
in filter divergence and echo leakage.
Bug: webrtc:9008,chromium:821670
Change-Id: I9b2635d24b260e9d9a8c5c088ab663e03fb93c42
Reviewed-on: https://webrtc-review.googlesource.com/61800
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22434}
last_target_rate_ is used to retrieve the bandwidth in the callback
handler in RtpTransportControllerSend. If last_target_rate_ is not
set before the callback in OnNetworkInvalidation, the value will
be outdated.
Bug: webrtc:8415
Change-Id: Ic6f898db212a02c2afa1997840e3c4929bb7f0f7
Reviewed-on: https://webrtc-review.googlesource.com/61720
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22428}
This is a follow up on an earlier CL removing the usage of
SetTransportOverhead.
Bug: webrtc:8415
Change-Id: I8d9572c06f3ae1e8cacbe7b9bd57a9b65f371c0e
Reviewed-on: https://webrtc-review.googlesource.com/61502
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22427}
Also delete the method RTPPayloadRegistry::red_payload_type() and
remnants of RED support in RTPReceiverAudio.
Bug: webrtc:8995,webrtc:5922
Change-Id: Iee310f5a8628ba70942e8c0277a856d2ca1f9b35
Reviewed-on: https://webrtc-review.googlesource.com/61500
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22425}
Delete method RTPPayloadRegistry::ulpfec_payload_type().
RtpVideoStreamReceiver can check its own config to know what the
payload type is.
Bug: webrtc:8995
Change-Id: Idc2bc7d747d77127f2b2261ff50610422e5686a6
Reviewed-on: https://webrtc-review.googlesource.com/61501
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22414}
This CL adds methods to the SendSideCongestionController (SSCC)
interface for configuring pacing factor and allocation based data rate limits.
This means that old SSCC implement the same interface as the new, task
queue based SSCC. This also allows merging the max total allocated
bit rate into SetAllocatedSendBitrateLimits.
This is done in preparation for an upcoming CL where the SSCC version
is controlled by a field trial.
Bug: webrtc:8415
Change-Id: I4d5446a3bedd5b0c725dbd009fb75815fd661eff
Reviewed-on: https://webrtc-review.googlesource.com/61320
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22408}
Replacing Module based mechanism for processing with posting tasks.
This prepares for allowing the interval to be changed at runtime and
for removing the dependency on Module threads.
Bug: webrtc:8415
Change-Id: Iaad50466bec695be4ba26d8bd670a1981f2e0df4
Reviewed-on: https://webrtc-review.googlesource.com/60862
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22406}
Adding configuration of new GoogCcNetworkController to initializer, this
makes sure that it is properly initialized from the start. To achieve
this SendSideCongestionController waits until it has received the
necessary information to construct the object. This information should
be provided in the constructor for SendSideCongestionController in the
future.
Bug: webrtc:8415
Change-Id: Icc09b8b246bae9f9704b80855fc4caa3450b34fc
Reviewed-on: https://webrtc-review.googlesource.com/58099
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22404}
Cleanup after moving test/fake_audio_device to
modules/audio_device/include/test_audio_device.
Hide implementation of test audio device module in the anonymous namespace.
Bug: webrtc:8946
Change-Id: I2d49c3ec5d43eeb5f155d38de95f69ed3c537805
Reviewed-on: https://webrtc-review.googlesource.com/61426
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22401}
Removing the Synchronous call AvailableBandwidth from the
RtpTransportControllerSend interface. The bandwidth estimate is
provided trough a new interface that communicates with a struct
making it easier to add parameters in the future.
This prepares for removing locking behavior in
SendSideCongestionController that exists just to support this feature.
To keep backwards compatibility with the old
SendSideCongestionController, the struct TargetTransferRate
is constructed in RtpTransportControllerSend. This step can be
removed in the future when the old SendSideCongestionController
is deprecated.
Bug: webrtc:8415
Change-Id: I06f64a89848157de412901c989650d1ecf35246b
Reviewed-on: https://webrtc-review.googlesource.com/60800
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22387}
This CL corrects some errors that were included in the CL for reading
the AEC3 options in the audioproc_f tool
Bug: webrtc:8671
Change-Id: Iecaee0ebf08f8a8f75aba1d395dd467a41b876f3
Reviewed-on: https://webrtc-review.googlesource.com/60870
Reviewed-by: Gustaf Ullberg <gustaf@webrtc.org>
Commit-Queue: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22384}
For the buffering of |input_frames_|, we assume that frames
are ordered per simulcast layer but we make no assumptions
between layers.
For SVC, we still assume ordering of encode callbacks for
the spatial layers. If we ever add async codecs that support SVC,
they should still obey this assumption.
Bug: webrtc:8448
Change-Id: I4ebb0c1e1d0eef41d850ed5b92aacc79d0a11137
Reviewed-on: https://webrtc-review.googlesource.com/60801
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22380}
The stereo-ness depends on the input Capturer and Renderer:
1) The stereo-ness of playout equals to Renderer;
2) The stereo-ness of recording equals to Capturer.
Bug: webrtc:8978
Change-Id: Ib41b8294c30ef6db54fdaf9d1890de0135a976d1
Reviewed-on: https://webrtc-review.googlesource.com/60100
Commit-Queue: Pengyu Liao <pengyul@google.com>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22374}
This refactoring makes it easier to experiment with injectable components.
Bug: webrtc:8732
Change-Id: I2cd2a8ff80516a76aec814af02b61778915f2217
Reviewed-on: https://webrtc-review.googlesource.com/60863
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22372}
This adds the ability to the pacer to apply a congestion window by
tracking sent data. This makes it more reliable when the congestion
window is small enough to be filled at a high rate as there are less
thread context switches that might affect the timing and performance.
Outstanding data is not reduced by the pacer as it has no information
about acknowledged packet feedback. This is by design as the pacer would
also need to keep track of on which connection packets were sent or
received, requiring a larger, more complex, change to the pacer.
Bug: webrtc:8415
Change-Id: I4ecd303e835552ced042cd21186da910288a8258
Reviewed-on: https://webrtc-review.googlesource.com/51764
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22371}
This ensures that SendSideCongestionController is always initialized
with starting bitrate and bitrate limits.
Bug: webrtc:8415
Change-Id: If3b75e935dda755f9e0f40af1021f97ff150c9e9
Reviewed-on: https://webrtc-review.googlesource.com/59224
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22370}
If 10ms delayed report is scheduled at 1.9ms (truncated by TaskQueue clock to 1ms)
it may run at 11.1ms (truncated to 11ms, i.e. first time it look like 10ms passed).
But (test) clock with different time offset may see passed time as 9ms
which result in a test failure for a wrong reason.
Relaxing period expectation by 1ms should mitigate the issue
Bug: webrtc:8945
Change-Id: I902d8af436fc74d4a3a0ad8ffdb5a6d3565adb7d
Reviewed-on: https://webrtc-review.googlesource.com/58095
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22361}
* Removed video files which were not used by any tests.
* Removed ConferenceMotion_1280_720_50.yuv for mobile builds.
Bug: webrtc:8936
Change-Id: I0539e9fce20470fcc2f0af84bd297faffc4b587a
Reviewed-on: https://webrtc-review.googlesource.com/60942
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22359}
This reverts commit 7bb37b884b197ea22e2830b043c09018c186bad5.
Reason for revert: Breaks downstream projects
Original change's description:
> Reland "Rework rtp packet history"
>
> This is a reland of 6328d7cbbc8a72fdc81a766c0bf4039e1e2e7887
>
> Original change's description:
> > Rework rtp packet history
> >
> > This CL rewrites the history from the ground up, but keeps the logic
> > (mostly) intact. It does however lay the groundwork for adding a new
> > mode where TransportFeedback messages can be used to remove packets
> > from the history as we know the remote end has received them.
> >
> > This should both reduce memory usage and make the payload based padding
> > a little more likely to be useful.
> >
> > My tests show a reduction of ca 500-800kB reduction in memory usage per
> > rtp module. So with simulcast and/or fec this will increase. Lossy
> > links and long RTT will use more memory.
> >
> > I've also slightly update the interface to make usage with/without
> > pacer less unintuitive, and avoid making a copy of the entire RTP
> > packet just to find the ssrc and sequence number to put into the pacer.
> >
> > The more aggressive culling is not enabled by default. I will
> > wire that up in a follow-up CL, as there's some interface refactoring
> > required.
> >
> > Bug: webrtc:8975
> > Change-Id: I0c1bb528f32eeed0fb276b4ae77ae3235656980f
> > Reviewed-on: https://webrtc-review.googlesource.com/59441
> > Commit-Queue: Erik Språng <sprang@webrtc.org>
> > Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#22347}
>
> Bug: webrtc:8975
> Change-Id: Ibbdbcc3c13bd58d994ad66f789a95ef9bd9bc19b
> Reviewed-on: https://webrtc-review.googlesource.com/60900
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#22356}
TBR=danilchap@webrtc.org,sprang@webrtc.org
Change-Id: Id698f5dbba6f9f871f37501d056e2b8463ebae50
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:8975
Reviewed-on: https://webrtc-review.googlesource.com/61020
Reviewed-by: Oleh Prypin <oprypin@webrtc.org>
Commit-Queue: Oleh Prypin <oprypin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22358}
This is a reland of 6328d7cbbc8a72fdc81a766c0bf4039e1e2e7887
Original change's description:
> Rework rtp packet history
>
> This CL rewrites the history from the ground up, but keeps the logic
> (mostly) intact. It does however lay the groundwork for adding a new
> mode where TransportFeedback messages can be used to remove packets
> from the history as we know the remote end has received them.
>
> This should both reduce memory usage and make the payload based padding
> a little more likely to be useful.
>
> My tests show a reduction of ca 500-800kB reduction in memory usage per
> rtp module. So with simulcast and/or fec this will increase. Lossy
> links and long RTT will use more memory.
>
> I've also slightly update the interface to make usage with/without
> pacer less unintuitive, and avoid making a copy of the entire RTP
> packet just to find the ssrc and sequence number to put into the pacer.
>
> The more aggressive culling is not enabled by default. I will
> wire that up in a follow-up CL, as there's some interface refactoring
> required.
>
> Bug: webrtc:8975
> Change-Id: I0c1bb528f32eeed0fb276b4ae77ae3235656980f
> Reviewed-on: https://webrtc-review.googlesource.com/59441
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#22347}
Bug: webrtc:8975
Change-Id: Ibbdbcc3c13bd58d994ad66f789a95ef9bd9bc19b
Reviewed-on: https://webrtc-review.googlesource.com/60900
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22356}
