Copy AgcManagerDirect files from agc to agc2. Rename the newly
created files and classes ahead of refactoring. Add a build
target.
This change is done to enable creating a class
InputVolumeController based on AgcManagerDirect. The added
temporary dependency on files in agc will be removed
in https://webrtc-review.googlesource.com/c/src/+/278625.
The exact copy of the files happened in the 1st patchset and it
has been verified as follows:
Checksum check:
```
$ git checkout main && git pull
# Go back to the tree state before [1] landed
$ git new-branch tmp
$ git reset --hard 2235776597e2f47ec353ac911428eb9a54d64a10
$ cd modules/audio_processing/agc/
$ md5 agc_manager_direct*
MD5 (agc_manager_direct.cc) = e661481a85f72596cae4599b62907f5b
MD5 (agc_manager_direct.h) = bf68280e2d0f689b4ebcd665b5db6052
MD5 (agc_manager_direct_unittest.cc) = 6bf0bf45ff5e940b1a3bb37154f09269
```
Patchset 1 (see [2])
```
$ cd modules/audio_processing/agc2/
$ md5 input_volume_controlle*
MD5 (input_volume_controller.cc) = e661481a85f72596cae4599b62907f5b
MD5 (input_volume_controller.h) = bf68280e2d0f689b4ebcd665b5db6052
MD5 (input_volume_controller_unittest.cc) = 6bf0bf45ff5e940b1a3bb37154f09269
```
[1] https://webrtc-review.googlesource.com/c/src/+/278781
[2] https://webrtc-review.googlesource.com/c/src/+/278624/1
Bug: webrtc:7494
Change-Id: I7804da899d18adf556b089c76a567ce27c299a62
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278624
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38512}
These metrics were not only non-standard, but residing in the
non-standard "track" stats object that we want to delete. As per
https://github.com/w3c/webrtc-stats/issues/695#issuecomment-1259611462
these metrics are no longer needed because we already have
inbound-rtp.totalInterFrameDelay/totalSquaredInterFrameDelay which is
basically the same thing.
// mac_rel infra failures are unrelated
NOTRY=True
Bug: webrtc:14522
Change-Id: I565da42514a93f15532ba8357dd006547a5296ee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278100
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38509}
This ensures that if for some reason, the frame buffer becomes
undecodable while waiting to decode a frame, the decoding is halted.
This also guards against receiving an empty temporal unit from the frame
buffer, even though this should never happen when the frame buffer has a
decodable temporal unit.
Bug: chromium:1378253, chromium:1361623
Change-Id: I8c4c897bf474d5cbda5f0f357781bf1dc0701fe4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280701
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38494}
It's deprecated and has been removed from Chrome. Let's follow suite.
// Passing all but unrelated bots
NOTRY=True
Bug: webrtc:14608
Change-Id: I6f2601af5b1dc08164230ebf15db2d2f1754f9e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280740
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38488}
This doesn't effect for how long the test will run, it just gives
PipeWire more time to establish connection and create empty buffers
before we try to work with it. All the waiting events will be
interrupted by signals once we no longer need to wait so it doesn't
matter if we wait 2 seconds or 5 seconds.
Bug: webrtc:14568
Change-Id: Ie918e8943bf882059b1289f57595fc302216745e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280700
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#38486}
the foundation attribute is currently calculated as
CRC32(baseaddress, protocol, relayprotocol)
which is a way to satisfy the requirements from
https://www.rfc-editor.org/rfc/rfc5245#section-4.1.1.3
However, this leaks the base address which defeats the
MDNS obfuscation described in
https://datatracker.ietf.org/doc/draft-ietf-mmusic-mdns-ice-candidates/
since the CRC32 can be reversed using a table lookup as shown in
https://github.com/niespodd/webrtc-local-ip-leak/
To defeat that lookup, "seed" the CRC32 with the ICE tie-breaker which is a randomly picked unsigned 64 bit integer described in
https://www.rfc-editor.org/rfc/rfc5245#section-5.2
The tie-breaker is not known to Javascript and adding it scopes the foundation within the peer connection as described in section 4.1.1.3
To manually test (preferably with a DCHECK for IceTiebreaker() in ComputeFoundation)
- gather candidates twice on https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ and observe that the foundations are not the same after this change
- create two RTCPeerConnections with {iceCandidatePoolSize: 1}, create a datachannel, call setLocalDescription, inspect the candidates and observe that the foundations are not the same after this change.
Unit test changes have been split into a separate CL for easier integration.
BUG=webrtc:14605
Change-Id: I6bbad1635b48997b00ae74d251ae357bf8afd12f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280621
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38485}
This is a reland of commit 8d7273357d92fab881561d886ce8dfe94e6e2238
Root cause:
audioproc_f doesn't call `metrics::Enable()` and therefore the stats
reporter crashed when `metrics::HistogramFactoryGetCountsLinear()`
returned a nullptr.
Bug fix:
Added `InputVolumeStatsReporter::cannot_log_stats_`, a const flag
that is set to true if any histogram factory returns a nullptr.
When true, the class does nothing.
This CL also includes other code readability improvements that were
not part of the original CL.
Original change's description:
> APM: log both applied and recommended input volume stats
>
> This CL replaces the existing `WebRTC.Audio.ApmAnalogGain.*` stats
> with `WebRTC.Audio.Apm.AppliedInputVolume.*` and adds the
> `WebRTC.Audio.Apm.RecommendedInputVolume.*` stats.
>
> Bug: webrtc:7494
> Change-Id: I70be710d20b1589fc814cbce3d3329ac1500686f
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280220
> Reviewed-by: Hanna Silen <silen@webrtc.org>
> Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38468}
Bug: webrtc:7494
Change-Id: I8373d16beb06b84f439d2c2274ededea7c5e95b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280661
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38484}
This information is now readily available. Let's expose it.
In practise we don't pace audio by default and the delay is ~0, however
we can tell that this metric is working as intended by setting
PacingController's pace_audio_ to true via the "WebRTC-Pacer-BlockAudio"
field trial. In this case chrome://webrtc-internals/ plots neats graphs
for audio send delay.
Bug: webrtc:10635
Change-Id: Iecfd93bb84ec61e5d54232769a9e7a500601b199
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280523
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38483}
Also run IWYU on a file picked for testing and check in the result.
Bug: none
Change-Id: Ide36bc59d126064f2bab7af441f72a6e8477c848
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280601
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38481}
This metric was always supposed to be the spec's answer to
googBucketDelay, and is defined as "The total number of seconds that
packets have spent buffered locally before being transmitted onto the
network." But our implementation measured the time between capture and
send, including encode time. This is incorrect and yields a much larger
value than expected.
This CL updated the metric to do what the spec says. Implementation-wise
we measure the time between pushing and popping each packet from the
queue (in modules/pacing/prioritized_packet_queue.cc).
The spec says to increment the delay counter at the same time as we
increment the packet counter in order for the app to be able to do
"delta totalPacketSendDelay / delta packetSent". For this reason,
`total_packet_delay` is added to RtpPacketCounter. (Previously, the
two counters were incremented on different threads and observers.)
Running Google Meet on a good network, I could observe a 2-3 ms average
send delay per packet with this implementation compared to 20-30 ms
with the old implementation. See b/137014977#comment170 for comparison
with googBucketDelay which is a little bit different by design -
totalPacketSendDelay is clearly better than googBucketDelay.
Since none of this depend on the media kind, we can wire up this metric
for audio as well in a follow-up:
https://webrtc-review.googlesource.com/c/src/+/280523
Bug: webrtc:14593
Change-Id: If8fcd82fee74030d0923ee5df2c2aea2264600d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280443
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38480}
It doesn't really make sense to try to create the X11 capturer if we are
running under Wayland; nor does it make sense to create the PipeWire
capturer if we are going to fail to actually start a stream with it.
This change addresses both of these issues by exposing an IsSupported
method on BaseCapturerPipeWire and checking that we are not running
under Wayland before creating the X11 capturer.
Bug: chromium:1374436
Change-Id: Ieb291307376010e084824124ea8fde065545337c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279163
Auto-Submit: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38474}
defined in
https://w3c.github.io/webrtc-encoded-transform/#rtcrtpsender-extension
Note: this does not implement the "rid(s)" parameter which will be done in a future CL.
VP8 still synchronizes keyframes on all layers even when asked for ones on individual layers while H264 (when implemented as three different encoders in SimulcastEncoderAdapter) can actually utilize this.
This does not change the behavior when receiving a RTCP PLI for a particular layer.
BUG=chromium:1354101
Change-Id: Ic8b14d155242e32c9aeafa55fe6652f346ac76b8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274169
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#38472}
This CL replaces the existing `WebRTC.Audio.ApmAnalogGain.*` stats
with `WebRTC.Audio.Apm.AppliedInputVolume.*` and adds the
`WebRTC.Audio.Apm.RecommendedInputVolume.*` stats.
Bug: webrtc:7494
Change-Id: I70be710d20b1589fc814cbce3d3329ac1500686f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280220
Reviewed-by: Hanna Silen <silen@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38468}
Adopt the new naming convention, which replaces "analog gain" and
"mic level" with "input volume", in the input volume stats reporter.
Bug: webrtc:7494
Change-Id: Ia24876151f51dd1dcc4e4f9db56c64d11ae3b442
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279840
Reviewed-by: Hanna Silen <silen@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38467}
