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}
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: Ic156f31bc7978c7a3fed937fc9aa2f6aa51caf5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/224843
Reviewed-by: Björn Terelius <terelius@google.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34411}
Currently, PRESUBMIT.py always runs pylint on all .py files when
at least one python file changes.
This helps to maintain consistency across the codebase, but
due to changes in the pylintrc rules, it has been failing for months.
Migrating all python files to the new rules can take a lot of time,
so as a workaround, for now, just run pylint on modified files.
Also, fixed or suppressed all complaints of too long lines in the
PRESUBMIT.py file to get this CL to pass the presubmit.
Bug: webrtc:12114
Change-Id: I4f6c0c269b3fe07878e168e7c90c196cb34f1d16
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220980
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34408}
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}
This is a step in the direction of being able to make configuration
changes without having to tear down and reconstruct the object
during renegotiation.
Bug: none
Change-Id: If594fd41f3a561060f64212c479a25d19adf8598
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/223740
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34402}
jitterBufferDelay and jitterBufferEmittedCount are defined
in RTCMediaStreamStats for both audio and video.
But for video, they were not populated in RTCInboundRtpStreamStats.
Bug: webrtc:12910
Change-Id: I135d473f055ecfb2c39b078ccf18c1bb9bc4f210
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/224280
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34398}
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}
When the transport is terminated, if an error has occured, it will
be propagated to the channels.
When such errors can happen at the SCTP level (e.g. out of resources),
RTCError may contain an error code matching the definition at
https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xhtml#sctp-parameters-24
If the m= line is rejected or removed from SDP, an error will again be sent
to the data channels, signaling their unexpected transition to closed.
Bug: webrtc:12904
Change-Id: Iea3d8aba0a57bbedb5d03f0fb6f7aba292e92fe8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/223541
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34386}
