This seems an issue with recently updated MSan prebuilt libraries,
or at least the issue started to happen after that. While investigating
let's skip the two tests to unblock presubmit and LKGR.
Bug: webrtc:12950
Change-Id: Iebd391deb9f669f6471bd41aae1ab32b7f6f8fc5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225420
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34434}
RTCPReceiver initially used a std::map, which made
RTCPReceiver::IncomingPacket's use of std::map represent ~0.45% CPU in
highly loaded media servers. Using std::unordered_map in change 216321
reduced it only slightly, to 0.39%.
This is the second attempt to reduce it even further. By using a
flat_map and taking advantage of the increased cache locality, the hope
is that it will be reduced. These maps generally have low cardinality
(indexed by SSRC), and are looked up often, but modified less often,
which make them a potential candidate for flat_map.
Bug: webrtc:12689
Change-Id: I6733ccf3484d1c54e661250fb6712971b80fa2a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225203
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34432}
std::unordered_map represents ~0.57% CPU in a loaded media server,
which is expected to be reduced by using flat_map and its increased
cache locality compared to std::unordered_map, which use quite a few
allocations and indirections.
The number of SSRCs tracked by this class is expected to be low and
infrequently updated, but as GetOrCreateStatistician is called for every
incoming RTP packet, lookups are frequent.
Bug: webrtc:12689
Change-Id: I9a2c3798dcc7822f518e8f2624e78fceacd12d27
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225202
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34430}
Webrtc designed to work for point-to-point topology, and thus
each rtcp_receiver handles single remote sender.
While remote sender ssrc may change, it should be ok to assume
the remote endpoint is still the same.
Bug: webrtc:12798
Change-Id: I62aebe7ac802306fc7fa17d7bf3959d6d4cca023
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/224548
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34407}
If the RTP header extension playout-delay is used and set
to min=0, max>=0, frames are scheduled to be decoded as
soon as possible. There's a risk that too many frames are
sent to the decoder at once, which may cause problems
further down in the video pipeline.
This CL adds the fieldtrial WebRTC-ZeroPlayoutDelay with
the parameter min_pacing that determines the minimum
pacing interval between two frames scheduled for
decoding.
Bug: None
Change-Id: I471f7718761cfce9789b3aa8adea3e8a16ecb2fd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/223742
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34387}
If timestamp_scaler_ is used, then rtp_header.timestamp, passed to UpdateLastDecodedPacket, will advance at a different rate than the scaled timestamp packet->timestamp, passed to UpdateLastDecodedPacket.
NackTracker::EstimateTimestamp uses timestamp_last_received_rtp_, and NackTracker::TimeToPlay uses timestamp_last_decoded_rtp_.
This difference causes TimeToPlay to continuously increase to huge values, so that every missing packet will be returned from GetNackList, even if RTT > real time to play.
Change-Id: Ie6ca347972edea98a202c9cdd26c6ab3f45a73c4
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222841
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34361}
This change achieves an Idle Wakeup savings of 200 Hz.
ModuleRtcRtcpImpl2 had Process() logic only active if TMMBR() is
enabled in RtcpSender, which it never is. Hence the Module
inheritance could be removed. The change removes all known
dependencies of the module inheritance, and any related mentions
of ProcessThread.
Fixed: webrtc:11581
Change-Id: I440942f07187fdb9ac18186dab088633969b340e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222604
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34358}
This change migrates RTCP send polling happening in
ModuleRtpRtcpImpl2::Process to task queues.
ModuleRtpRtcpImpl2 would previously only cause RTCP sends while being
registered with a ProcessThread. This is now relaxed so that RTCP will
be sent regardless of ProcessThread registration status, and it seems
no tests cared.
Now there's only one piece of polling left in Process.
Bug: webrtc:11581
Change-Id: Ibdcffefccef7363f2089c34a9c7d694d222445c0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222603
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34350}
This change prepares for later CLs that partly replaces
logic in the module that depends on the Module system
for logic that depends on task queues.
The change also changes SendTransport::SendRTCP
to schedule packet reception with the simulated time
controller. This fixes the problem that SendRTCP itself
updates the simulated time which makes it hard to
understand the tests.
Finally, GlobalSimulatedTimeController was updated
to support addition of custom SimulatedSequenceRunners
like SendTransport.
Bug: webrtc:11581
Change-Id: I0aa310ad0a10526479ad8c28affc38a413363ffd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222602
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34348}
This change migrates RTCPSender to use webrtc::Timestamp, preparing
for later improvements regarding bugs.webrtc.org/11581.
Fixed: webrtc:12873
Change-Id: I1159701dc373883367d9b2c86823f8fb59904d55
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222324
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34346}
The class depends on RtcRtcpInterface::Configuration which adds an
unneeded dependency, and inhibits well-manored changes to the
constructor interface.
Fix this so that RTCPSender uses it's own configuration struct which
can be extended in future CLs.
Also add a legacy constructor while downstream dependencies are
updated.
Bug: webrtc:11581
Change-Id: I8d166ab8253b27c08fcbe6aa7c7adde92688b7dc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222322
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34343}
In cases where ToI420 fails it should be able to return null.
Bug: webrtc:12877
Change-Id: Ia13859c104d978a29712ae10f8e15acada8406ac
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222613
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Cr-Commit-Position: refs/heads/master@{#34342}
Integrate ClippingPredictorEvaluator in AgcManagerDirect adding the
possibility to run the predictor without affecting the analog gain
adjustment process.
The evaluator is used to compute precision, recall and F1 score.
F1 score and the measured clipping prediction intervals are logged as
`WebRTC.Audio.Agc.ClippingPredictor.F1Score` and `.PredictionInterval`
histograms respectively.
Bug: webrtc:12774
Change-Id: I708dcda9321f92d5bd17ec4c36ebce1165ead57f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221921
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34327}
it is not required because during construction members can be set on
wrong thread, and in some corner cases it may even cause a crash.
Bug: none
Change-Id: I37d7f2a7772b6ab5e574077d3f53bca2529f9ae1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222651
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34315}
This is a consistent way to get to common config parameters for
all receive streams and avoids storing a copy of the extension
headers inside of Call. This is needed to get rid of the need of
keeping config and copies in sync, which currently is part of why
we repeatedly delete and recreate audio receive streams on config
changes.
Bug: webrtc:11993
Change-Id: Ia356b6cac1425c8c6766abd2e52fdeb73c4a4b4f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222040
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34285}
The dominant nearend detector uses the residual echo spectrum for
determining whether in nearend state. The residual echo spectrum in
computed using the ERLE. To reduce the risk of echo leaks in the
suppressor, the ERLE is capped. While minimizing echo leaks, the
capping of the ERLE can affect the dominant nearend classification
negatively as the residual echo spectrum is often over estimated.
This change enables the dominant nearend detector to use a residual
echo spectrum computed with a virtually non-capped ERLE. This ERLE
is only used for dominant nearend detection and leads to increased
transparency.
The feature is currently disabled by default and can be enabled
with the field trial "WebRTC-Aec3UseUnboundedEchoSpectrum".
Bug: webrtc:12870
Change-Id: Icb675c6f5d42ab9286e623b5fb38424d5c9cbee4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221920
Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34270}
