The push_back pattern results in frequent vector growth which has performance overhead. This is .5% of our server's CPU
Bug: webrtc:15723
Change-Id: Ic151c81a4b49a7d48a354b75f62694bc6f9a1ee4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331440
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Commit-Queue: Daniel Collins <dpcollins@google.com>
Cr-Commit-Position: refs/heads/main@{#41388}
Access to `internal_dtls_transport_` only occurs on the network thread
and doesn't require locking. Access to `info_` still requires a lock
but writing to it only occurs on the network thread. If reading from
the network thread is needed, that could be done without requiring
the lock.
The scope of holding the lock is much smaller now.
Bug: none
Change-Id: Ic284df04196dfcf8b77c66a48e484ca6893de050
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325283
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41387}
by also taking into account any a=msid: line in addition to
msid-semantic. Also document issues with msid-semantic generation and unify support determination by removing the msid_supported flag.
BUG=webrtc:10421
Change-Id: Icea554ebd1998f2b526846457029eff6854a772a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329760
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41386}
Instead of using raw pointers.
Bug: webrtc:11943
Change-Id: I39ce45868d95aca44f32cfed27c91986f9c3278a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331480
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41384}
which come from the a=fmtp:<pt> lines in the SDP and were used as either
std::map<std::string, std:string>
with three aliases,
cricket::CodecParameterMap
SdpAudioFormat::Parameters
SdpVideoFormat::Parameters
Use webrtc::CodecParameterMap in all places.
BUG=None
Change-Id: If47692bde7347834c349c6539b43309d8770e67b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330420
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#41375}
OutstandingData::NackItem nacks a chunk, and if that chunk reaches its
partial reliability critera, it will abandon the entire message. If that
message hasn't been sent in full, a placeholder "end" message is
inserted (see https://crbug.com/webrtc/12812). And when the message is
inserted, any iterators may be invalidated (if e.g. std::deque would
want to grow the deque).
So ensure that there are no iterators used after having called NackItem.
By changing the interface of NackItem, and not passing an Item, but just
the TSN, this is encouraged. NackAll was rewritten as a two-pass
algorithm to first collect TSNs, then iterating that list, looking up
the items in the second pass (constant complexity).
Bug: chromium:1510364
Change-Id: I5156b6d6a683184f290e71c98f16bc68ea2a562f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331320
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41374}
Instead of using raw pointers.
Also, ensure callbacks are registered on the correct thread.
Nat servers are test only code.
Bug: webrtc:11943
Change-Id: Ib70a5966acb512f1a07212a07aaedab70aa20f9b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331260
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@google.com>
Cr-Commit-Position: refs/heads/main@{#41372}
This should substantially reduce the overhead due to deferred callbacks in profiles.
Bug: webrtc:15723
Change-Id: I4c52beb91eb08c9b0ac2d1ce9a4e11839aa35e38
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331020
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Commit-Queue: Daniel Collins <dpcollins@google.com>
Cr-Commit-Position: refs/heads/main@{#41363}
instead of throwing an error when trying to pick a send codec.
BUG=webrtc:15145,webrtc:4957
Change-Id: I056b145c093348576e1aeaf5def50d5414f2de70
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330122
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41360}
This adds neccessary checks for SDP negotiation with HEVC.
Test: Manually apply the CL on Chromium and enable HEVC HW encoder,
and add HEVC profiles in rtc video decoder/encoder factory, H265 is
negotiated in SDP with correct FMTP lines added.
Bug: webrtc:13485
Change-Id: I5557b20b646cc96c5acb578521204fe10df0dcf0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330202
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#41357}
as preparation for H265 work.
BUG=webrtc:15703
Change-Id: Ib6e0afa5ccbb8172a70d4e4eb876639559070fd6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329981
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41350}
This is temporary and should be re-enabled as soon as the test is
fixed.
Bug: webrtc:15722
Change-Id: I9d262c9931a19bc9c33f7f93e9e275d39fab403c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330561
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41348}
This allow exernal applications to control how many packets can be sent relative current BWE.
This is a partial revert of https://webrtc-review.googlesource.com/c/src/+/311102
Bug: chromium:1354491
Change-Id: Ia236aaacc468ddac12341efa555041bb2dfdde62
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330580
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41343}
This reverts commit 33c7edd58ad0edc71939b9372fff3ab563c1f4a7.
Reason for revert: Breaks downstream project
Original change's description:
> Enable DD and VLA header extensions by default for Simulcast/SVC
>
> When Simulcast (more than one encoding) or SVC (a scalability mode
> other than the default L1T1) is used, enable the AV1 Dependency
> Descriptor and the video-layer-allocations RTP header extensions by
> default.
>
> The RTP header extensions API can be used to disable them if needed.
>
> BUG=webrtc:15378
>
> Change-Id: I587ac32c9d681461496a136f6950b007e72da86d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326100
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Philipp Hancke <phancke@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#41332}
Bug: webrtc:15378
Change-Id: I6b5f71f321d30a510db3bd180deaa57732f9349b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330540
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41341}
In the example below, the association is being established between peer
A and Z, and A is the initiating party.
Before this CL, when an association was about to be established, Z would
after having received the INIT chunk, persist state in the socket about
which verification tag and initial TSN that was picked. These would be
re-generated on every incoming INIT (that's fine), but when A had
extracted the cookie from INIT_ACK and sent a reply (COOKIE_ECHO) with
the state cookie, that could fail validation when it's received by Z, if
the sent cookie was not the most recent one or if the COOKIE_ECHO had a
verification tag coming not from the most recent INIT_ACK, because Z had
replaced the state in the socket with the one generated when the second
INIT_ACK chunk was generated - state it used for validation of future
received data.
In other words:
A -> INIT 1
<timeout>
A -> INIT 2 (retransmission of INIT 1)
INIT 1 -> Z - sends INIT_ACK 1 with verification_tag=1, initial_tsn=1,
cookie 1 (and records these to socket state)
INIT 2 -> Z - sends INIT_ACK 2 with verification_tag=2, initial_tsn=2,
cookie 2 (replaces socket state with the new data)
INIT_ACK 1 -> A -> sends COOKIE_ECHO with verification_tag=1, cookie 1
COOKIE_ECHO (cookie 1) -> Z <FAILS, as the state isn't as expected>.
The solution is really to do what RFC4960 says, to not maintain any
state as the receiving peer until COOKIE_ECHO has been received. This
was initially not done because the underlying reason why this is
important in SCTP is to avoid denial of service, and this is why SCTP
has the four-way handshake. But for Data Channels - SCTP over DTLS -
this attack vector isn't available. So the implementation was
"simplified" by keeping socket state instead of encoding it in the
state cookie, but that obviously had downsides.
So with this CL, the non-initiating peer in connection establishment
doesn't keep any socket state, and puts all that state in the state
cookie instead. This allows any COOKIE_ECHO to be received by Z.
Bug: webrtc:15712
Change-Id: I596c7330ce27292612d3c9f86b21c712f6f4e408
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330440
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41340}
