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}
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}
