Cache target bit- and framerate in a frame_num -> rates map and fetch
the rates accociated with the current frame when needed. This solves
the issue when wrong target rates may be used due to frames buffering
in encoder.
Bug: b/254447893
Change-Id: I369c8d8e71234c957dc2362b055061d12cec818f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283841
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38673}
This is a reland of commit b46c4bf27ba5c417fcba7f200d80fa4634e7e1a1
Original change's description:
> [ACM] iSAC audio codec removed
>
> Note: this CL has to leave behind one part of iSAC, which is its VAD
> currently used by AGC1 in APM. The target visibility has been
> restricted and the VAD will be removed together with AGC1 when the
> time comes.
>
> Tested: see https://chromium-review.googlesource.com/c/chromium/src/+/4013319
>
> Bug: webrtc:14450
> Change-Id: I69cc518b16280eae62a1f1977cdbfa24c08cf5f9
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282421
> Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38652}
Bug: webrtc:14450
Change-Id: Ia22c4d7724b6022238235fede93e36e570a49376
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283843
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38665}
We have seen a few instances in a down-stream project where the circuit
breaker is still triggering and causing issues.
This CL makes the threshold configurable and adds more debug logging to
try and get to the bottom of this rarely occuring bug.
Bug: webrtc:11340, b/258509536
Change-Id: I92674d446b926ad66538ff9c8be2a32a3d95b057
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283762
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38664}
This CL adds more explicit tests for unsupported sample rates in the WebRTC audio processing module (APM). Rates are restricted to the range [8000, 384000] Hz. Rates outside this range are handled as best as possible, depending on the format.
Tested: bitexact on a large number of aecdumps
Bug: chromium:1332484, chromium:1334991
Change-Id: I9639d03dc837e1fdff64d1f9d1fff0edc0fb299f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276920
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38663}
This reverts commit b46c4bf27ba5c417fcba7f200d80fa4634e7e1a1.
Reason for revert: breaks a downstream project
Original change's description:
> [ACM] iSAC audio codec removed
>
> Note: this CL has to leave behind one part of iSAC, which is its VAD
> currently used by AGC1 in APM. The target visibility has been
> restricted and the VAD will be removed together with AGC1 when the
> time comes.
>
> Tested: see https://chromium-review.googlesource.com/c/chromium/src/+/4013319
>
> Bug: webrtc:14450
> Change-Id: I69cc518b16280eae62a1f1977cdbfa24c08cf5f9
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282421
> Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
> Reviewed-by: Sam Zackrisson <saza@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38652}
Bug: webrtc:14450
Change-Id: Ice138004e84e8c5f896684e8d01133d4b2a77bb7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283800
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#38655}
Note: this CL has to leave behind one part of iSAC, which is its VAD
currently used by AGC1 in APM. The target visibility has been
restricted and the VAD will be removed together with AGC1 when the
time comes.
Tested: see https://chromium-review.googlesource.com/c/chromium/src/+/4013319
Bug: webrtc:14450
Change-Id: I69cc518b16280eae62a1f1977cdbfa24c08cf5f9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282421
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38652}
This makes it easier to update devices in th e future (avoiding multiple
CLs to change names, etc..).
Bug: b/259076774
Change-Id: I20ae940823978fbae84495d266345e4990184130
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283720
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38650}
Replace kUpdateInputVolumeWaitFrames with
update_input_volume_wait_frames in InputVolumeController::Config.
Also, fix an off-by-one error in the frame count to give a better
readability for non-zero wait frames. Now
update_input_volume_wait_frames_ = 100 allows updates every 100 frames
instead of every 101 frames. Effectively, this makes
update_input_volume_wait_frames = 0 and 1 to behave similarly (i.e.,
they now both allow updates after every frame).
Bug: webrtc:7494
Change-Id: I597f7e88895a4dcd365dc6dee526acb9d971b2fc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282863
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38648}
remove unused support for more than four spatial layer descriptions
of temporal layers
BUG=webrtc:12000
Change-Id: I087bcd020897898636bdf9c838abafa8c73c53f3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281320
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38646}
The DCHECK crashes debug builds running some applications such as Webex.
Bug: None
Change-Id: I0061286c4c1d04964678a00014896f1fccd4685d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276460
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38644}
After changing base functions to a CHECK instead of an =0, these
are no longer needed.
Bug: webrtc:14632
Change-Id: If3f1a62905cf433486f4974b2153c9210d1e045b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283542
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38643}
Address perkj's comments left in
https://webrtc-review.googlesource.com/c/src/+/283420. I was a bit
trigger-happy with the submit button.
Bug: chromium:1354491
Change-Id: Ifd052f75af3763b0b52807c31ea790e3efee921d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283521
Reviewed-by: Erik Språng <sprang@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38638}
* Use the same logdog_butler as Chromium instead of redefining one.
* Use luci-auth to prevent "local auth - HTTP 400" errors.
Change-Id: I2a0d1393f9f0e1e41b2bcc9a9fec2c50c19675f3
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283520
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#38637}
Add loss_limited_probe_scale as a scale factor which decides how much we should probe when bandwidth is loss limited.
Bug: webrtc:12707
Change-Id: I194b2b40c9a7861d82b61585bcaf484ab228eedb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281360
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38636}
I've been working with SizeBench (binary size analysis tool) and it
reported that 39 virtual functions were not overridden. Removed
virtual keyword from each. SizeBench estimated waste 2.1kb. Change
made chrome.dll 5.3kb smaller. Since these 39 virtual functions
are never overridden, they are wasteful.
Note: These are the savings for Windows, relocation savings are probably larger on other platforms.
GN args for builds:
use_goma=true
is_debug=false
target_cpu="x64"
use_lld=false
fatal_linker_warnings=false
symbol_level=2
dcheck_always_on = false
pe_summarize analysis pre-change -> change:
Size of out\Default\chrome.dll is 187.205120 MB
Size of out\MediaContentDescription\chrome.dll is 187.199488 MB
Memory size change from out\Default\chrome.dll to
out\MediaContentDescription\chrome.dll
.text: -2624 bytes change
.rdata: -1984 bytes change
.pdata: -48 bytes change
.reloc: -644 bytes change
Total change: -5300 bytes
Bug: chromium:1371503
Change-Id: Ib33829fada54abdf8fed33ec96f11a03ce6fcb68
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281442
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Ivan Rosales <rosalesi@google.com>
Cr-Commit-Position: refs/heads/main@{#38630}
As the synchronous version only posts a task to recreate the encoder
later, it is not possible to catch errors and state changes that
could appear then.
The asynchronous version of SetParameters() aims to solve this by
providing a callback to wait for the completion of the encoder
reconfiguration, allowing any error to be propagate and subsequent
getParameters() call to have up to date information.
Bug: webrtc:11607
Change-Id: I5548e75aa14a97f8d9c0c94df1e72e9cd40887b2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278420
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38627}
Motivation: loss based ramp-up can be incorrect when (1) bandwidth is loss limited, and (2) delay based estimate might be incorrect due to no delay signals. Therefore, bounding the loss based estimate by the delay based estimate is not much helpful in those cases.
Thus strengthening the bounding logic by using upper link capacity is one of solutions to avoid incorrect ramp-up.
Without the change: screen/qmLedxapJWvUTmn
With the change: screen/8sQcksWa6CptywK
Bug: webrtc:12707
Change-Id: I32ba82693b3ffa83cbb89c2cc9690fe16fb10c78
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283085
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38626}
In the experiment WebRTC-SendPacketsOnWorkerThread ensure the safety
flag is set not alive even if Start/Stop has never been called.
Bug: webrtc:14502, chromium:1382602
Change-Id: I01c1e663762c8bb848e9bc31b2dcb22d38d0d1e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283380
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38624}
