This will allow us to enable receive-side RTT without having to recreate all AudioReceiveStream objects.
Bug: webrtc:12951
Change-Id: I1227297ec4ebeea9ba15fe2ed904349829b2e669
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225262
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34464}
This reverts commit e2ab77ba57bff5db8eaa7a8442fa6b2f43914b69.
See bugs, this CL seems to be the culprit of crashes in
cricket::TurnPort::OnMessage and
jingle_glue::JingleThreadWrapper::Dispatch.
TBR=handellm@webrtc.org, hta@webrtc.org
Bug: chromium:1227839, chromium:1228462
Change-Id: I7521210970fe543a01682bb08de31ac025e79981
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225880
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34462}
The previous logic to abandon chunks when partial reliability was used
was a bit too eager and trigger happy.
* Chunks with limited retransmissions should only be abandoned when a
chunk is really considered lost. It should follow the same rules as
for retransmitting chunks - that it must be nacked three times or
due to a T3-RTX expiration. Before this change, a single SACK not
referencing it would be enough to abandon it. This resulted in a lot
of unnecessary sent FORWARD-TSN and undelivered messages - especially
if running with zero retransmissions.
The logic to expire chunks by limited retransmissions will now only
be applied when a chunk is actually nacked.
* The second partial reliability trigger - expiration time - wasn't
evaluated when producing a middle chunk of a larger message.
A number of test cases were added and updated as chunks will now be
abandoned immediately instead of first scheduled for retransmission and
later abandoned.
Bug: webrtc:12961
Change-Id: I0ae17b2672568bdbdc32073a99d4c24b09ff5fe9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225548
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34458}
Add a histogram WebRTC.Audio.Agc.InputClippingRate and logging of
max clipping rate in AgcManagerDirect.
Bug: webrtc:12774
Change-Id: I4a72119b65ad032fc50672e2a8fb4a4d55e1ff24
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225264
Commit-Queue: Hanna Silen <silen@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34450}
Remove unused functions GetRtpHeader/GetRtpHeaderLength
Replace usage of SetRtpHeader with webrtc::RtpPacket
Move SetRtpSsrc next to the only place it is used.
Bug: None
Change-Id: I3ecc244b1a2bdb2d68e0dbdb34dd60160a3101f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225547
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34447}
CL partially auto-generated with:
git grep -l "\bassert(" | grep "\.[c|h]" | \
xargs sed -i 's/\bassert(/RTC_DCHECK(/g'
And with:
git grep -l "RTC_DCHECK(false)" | \
xargs sed -i 's/RTC_DCHECK(false)/RTC_NOTREACHED()/g'
With some manual changes to include "rtc_base/checks.h" where
needed.
A follow-up CL will remove assert() from Obj-C code as well
and remove the #include of <assert.h>.
The choice to replace with RTC_DCHECK is because assert()
is because RTC_DCHECK has similar behavior as assert()
based on NDEBUG.
This CL also contains manual changes to switch from
basic RTC_DCHECK to other (preferred) versions like
RTC_DCHECK_GT (and similar).
Bug: webrtc:6779
Change-Id: I00bed8886e03d685a2f42324e34aef2c9b7a63b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/224846
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34442}
It is not uncommon to save rtp header of an rtp packet for later parsing
(e.g. rtc event log does that)
Such header is invalid as an rtp packet when padding bit is set.
This change suggest to treat header only packets with padding as valid.
Bug: webrtc:5261
Change-Id: If61d84fc37383d2e9cfaf9b618276983d334702e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225265
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34438}
On ASan, SimulatedRealTimeControllerConformanceTest is flaky and
triggers `stack-use-after-scope` because on some occasions, the delayed
callback gets invoked when the test is tearing down (the callback
holds a reference to an object allocated on the test function stack).
This CL ensures threads and TaskQueues are stopped when the tests
scope is exited. Some flakiness might remain on realtime tests but
that can only be addressed by increasing the wait.
Bug: webrtc:12954
Change-Id: I4ac1a6682e18bb144a3aeb03921a805e3fb39b2d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225422
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34437}
When a single stream is reset, and an outgoing SSN reset request is sent
and later acked by the peer sending a reconfiguration response with
status=Performed, the sender should unpause the paused stream and reset
the SSNs of that (ordered) stream. But only the single stream that was
paused, and not all streams. In this scenario, dcSCTP would - when the
peer acked the SSN reset request - reset the SSN of all streams.
This was found by orphis@webrtc.org using a data channel test
application. The peer, if it's a usrsctp client, will ABORT with
PROTOCOL_VIOLATION as it has already seen that SSN on that stream but
with a different TSN.
This bug was introduced when implementing the Round Robin scheduler in
https://webrtc-review.googlesource.com/c/src/+/219682. The FCFS
scheduler prior to this change was implemented correctly.
Bug: webrtc:12952
Change-Id: I3ea144a1df303145f69a5b03aada7f448c8c8163
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225266
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34436}
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}
Before this CL, EraseIf was defined in flat_tree.h, but that file can
only be included by the flat_map/flat_set implementation, as it's an
internal file with limited visibility.
This CL will move the flat_tree's base EraseIf implementation to the
internal namespace and define specific variants of it in flat_map.h and
flat_set.h
Bug: webrtc:12689
Change-Id: Idf31915f4abe36ad302c1da669b702974a27c647
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225206
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34431}
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}
Except for a use of std::multimap (for which there currently is no
drop-in replacement), use webrtc::flat_map and flat_set for increased
performance.
The number of ssrcs/mids/payload types/etc is likely to be small and is
generally updated very rarely, but looked up a lot.
RtpDemuxer::ResolveSink's use of std::map represents about 0.6% CPU in
heavily loaded media servers. It does quite a few map lookups, and by
taking advantage of the increased cache locality of the flat_map and
flat_set containers, performance should be increased.
A previous attempt to use std::unordered_map failed in change 216243,
which was reverted. This is the second attempt.
Bug: webrtc:12689
Change-Id: Ifdbec63b2fd8f2f52e45ebaf12834b11dd7a41c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/224662
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34429}
These implementations have been copied from Chromium and adapted to
build and run in WebRTC's environment.
Bug: webrtc:12689
Change-Id: Id8ff5d86b00827102a6be9d613fad7864130d013
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/224661
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34425}
To build XCFramework, changed build_ios_libs.py to support
target pairs (environment, arch).
Also, changed default architecture to include the Arm64 iOS Simulator
and not the x86 iOS Simulator.
Mac Catalyst (target_environment = "catalyst") builds can also
be achieved in the same way, but at the moment, Mac Catalyst builds fail,
so I skipped them from the active arch.
Bug: webrtc:12372, webrtc:11516
Change-Id: I3f07ded81c7d0bdecc69a903b32e06c4ab63cee2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202160
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34420}
iOS 12.0 is the new iOS deployment target and iOS 10 is the maximum
deployment target for 32-bit targets.
Bug: webrtc:12928
Change-Id: I60f300c991cc67f826b2bff56415ed8e20cee77f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/224845
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34415}
