Long term, ideally, these would be fixed and this flag can be removed.
For now, this is an expedient way to allow enabling -Wshadow in
Chromium.
Bug: chromium:794619
Change-Id: I7aba1c7bb7dfe0598cdb077cb97def752b8bac79
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232660
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35110}
Instead of using two different headroom parameters, namely
`kHeadroomDbfs` and `kSaturationProtectorExtraHeadroomDb`, only use
the former that now also accounts for the deleted one - i.e., it equals
the sum of the two headrooms. In this way, tuning AGC2 will be easier.
This CL does *not* change the behavior of the AGC2 adaptive digital
controller - bitexactness verified with audioproc_f on a collection of
AEC dumps and Wav files (42 recordings in total).
The unit tests changes in agc2/saturation_protector_unittest.cc are
required since `extra_headroom_db` is removed and the changes in
agc2/adaptive_digital_gain_applier_unittest.cc are required because
`AdaptiveDigitalGainApplier` depends on `kHeadroomDbfs` which has been
updated as stated above.
Bug: webrtc:7494
Change-Id: I0a2a710bbede0caa53938090a004d185fdefaeb9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232905
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35109}
along the lines of RTX handling but with limited support for missing
fmtp lines because of video/red.
BUG=webrtc:13178
Change-Id: Ia866c0e857da6da2ef1e4b81b51f90f534c7bb83
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231948
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35107}
This feature is used only by chromium, and only for UDP sockets.
Bug: webrtc:13065
Change-Id: I207ea643aa57cf23bdd36266895f65f1ee251aaa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232860
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35106}
It's to be used for clients to record metrics and to e.g. attribute
metrics to which SCTP implementation the peer was using.
This is not explicitly signaled, so heuristics are used. These are not
guaranteed to come to the correct conclusion, and the data is not always
available.
Note: The behavior of dcSCTP will not change depending on the assumed
implementation - only by explicitly signaled capabilities.
Bug: webrtc:13216
Change-Id: I2f58054d17d53d947ed5845df7a08f974d42f918
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/233100
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35103}
Currently the implementation of FrameTransformers uses distinct,
incompatible types for recevied vs about-to-be-sent frames. This adds a
flag in the interface so we can at least check that we are being given
the correct type. crbug.com/1250638 tracks removing the need for this.
Chrome will be updated after this to check the direction flag and provide
a javascript error if the wrong type of frame is written into the
encoded insertable streams writable stream, rather than crashing.
Bug: chromium:1247260
Change-Id: I9cbb66962ea0718ed47c5e5dba19a8ff9635b0b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232301
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tony Herre <toprice@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35100}
This CL improves `GainController2::CheckGainAdaptiveDigital`, namely:
- correctly initialize AGC2 with the correct number of channels
- attenuate the input signal in order to avoid that the target gain is
set to zero (which was the case before)
- run AG2 adaptive digital for a longer period to allow time to trigger
the adaptive behavior (namely, from 2s to 10s)
- minor code style improvements
Bug: webrtc:7494
Change-Id: Ib41de088b341bb30460238b83e306a507b2bc5af
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/233101
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35099}
When a HEARTBEAT is sent out, the current timestamp is stored in the
parameter that will be returned by the HEARTBEAT-ACK. If the timestamp
from the HEARTBEAT-ACK would be from the future (either by jumping
clocks, bit errors, exploiting peer or a fuzzer), the measured RTT would
become really large, and when it was calculated, it would result in an
integer overflow; a wrapping subtraction.
This isn't a problem, as RetransmissionTimeout::ObserveRTT method would
discard measurements that were negative or too large, but it would
trigger an UBSAN violation.
Adding an additional check so that the subtraction doesn't ever wrap.
Bug: chromium:1252515
Change-Id: I1f97b1e773a4639b8193a528716ebd6a27fcb740
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232904
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35095}
maxBitrate is set to a minimum of kEncoderMinBitrateKbps in VideoCodecInitializer::SetupCodec and cannot be zero at this point.
Bug: none
Change-Id: I4e062b054d99fabc1a9650260db03dd45b033c3c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230142
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35094}
Add histograms WebRTC.Audio.Agc.ClippingPredictor.Precision and WebRTC.Audio.Agc.ClippingPredictor.Recall. The histograms are defined in https://chromium-review.googlesource.com/c/chromium/src/+/3150271.
Bug: webrtc:12774
Change-Id: I1561ec7a61377c262f636d7aa3a5d5fd60a8839d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231460
Commit-Queue: Hanna Silen <silen@webrtc.org>
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35083}
peerconnection_client sample on Windows is using the current UI thread
as signaling thread. Create a dedicated thread for that purpose.
Bug: webrtc:13104
Change-Id: Iccff8165373101996913c4389cf134a60051462c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230729
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35078}
By initialization, time since backoff is unlimited at startup.
Bug: none
Change-Id: I9693cd09b7201606374a8bf9a0a03e6ee83191d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232611
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Reviewed-by: Fanny Linderborg <linderborg@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35076}
It wasn't correct and not enabled by default, so just remove it.
Bug: webrtc:12943
Change-Id: Idd426abd0da4ae259e519dd01239b4303296756a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232609
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35075}
CreateSharedMemory is allowed to return nullptr if memory can't be
allocated but DesktopFrameWin didn't check to ensure was allocated
before accessing it. This CL just adds a null check, logs a
warning, and returns nullptr which is already done lower in the
function and the error is correctly handled in the screen and window
capturers which call DesktopFrameWin::Create().
Bug: chromium:1251651
Change-Id: Ie9231f03ba9c7a96823af986b9df38f97fcb682c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232663
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35072}
This is mentioned in
https://datatracker.ietf.org/doc/html/rfc4960#section-6.3.1 and further
described in https://datatracker.ietf.org/doc/html/rfc6298#section-4.
The TCP RFCs mentioned G as the clock granularity, but in SCTP it should
be set much higher, to account for the delayed ack timeout (ATO) of the
peer (as that can be seen as a very high clock granularity). That one is
set to 200ms by default in many clients, so a reasonable default limit
could be set to 220 ms.
If the measured variance is higher, it will be used instead.
Bug: webrtc:12943
Change-Id: Ifc217daa390850520da8b3beb0ef214181ff8c4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232614
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35068}
setExif: would create a CFDictionary using NULL for keyCallBacks and
valueCallBacks. This has the effect of comparing the keys of the
dictionary by pointer instead of by value. With ld64, this works
because it always dedupes identical constant CFSTR("foo") literal,
but lld currently doesn't do this.
Using kCFTypeDictionaryKeyCallBacks and kCFTypeDictionaryValueCallBacks
fixes the problem with lld and is "more correct" in general: Now the
dictionary would work with computed CFStrings too, it shows up better
in CFShow() output, etc.
While here, also fix a memory leak in setExif:.
Bug: chromium:1251763
Change-Id: I43c96d2189a4a77fe3bd0dfb3e33623925b0f900
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232760
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35067}
This was caused by change 231229 and was later caught when reviewing the
code. The rtt variable was accidentally re-used for another purpose, and
then assumed to still be used to represent the rtt.
There have been no issues found with this re-use, but it was wrong.
Bug: webrtc:12614
Change-Id: If1a180315cf833e293f78c54c3c3b29394a19a20
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232610
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35064}
In callers where it's non-trivial to explicitly pass the right
SocketFactory, pull the call to rtc::Thread::socketserver() into the
caller, with a TODO comment.
Bug: webrtc:13145
Change-Id: I029d3adca385d822180e089f016c3778e0d4fd0c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231227
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35063}
Prior to this commit, the SCTP association could terminate due to too
many retransmission attempts when there is a long duration of packet
loss. The RTCPeerConnection wouldn't terminate, and when the network
later recovers (possibly using a different ICE candidate), it would be a
RTCPeerConnection with media, but without DataChannels.
This commit will make the dcSCTP library never abort by itself when
there are too many retransmissions. It will also put a cap on the retry
duration so that it will do a retry every three seconds (or lower).
Bug: webrtc:13129
Change-Id: I08162ea20d6a60aa0eae2717966d9a2ddba8fc22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232540
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35061}
