As a first step we only want to enable frame pacing for the case
where min playout delay == 0 and max playout delay > 0.
Bug: chromium:1237402, chromium:1239469
Change-Id: Icf9641db7566083d0279135efa8618e435d881eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228640
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34752}
The UDP sockets in WebRTC are non-blocking, and when writing too much
to them so that their send buffer becomes exhausted, they will return
EAGAIN or EWOULDBLOCK, which indicates that the client will need to
retry a bit later.
Media packets are generally sent by the pacer, which generally avoids
this exhaustion, but for SCTP which has a congestion control algorithm
quite similar to TCP, it may overshoot the amount of data it writes. If
the SCTP library can be notified when writing fails, it can stop writing
for a while until the socket recovers, which will result in less
overshooting and fewer lost packets (possibly even none). But for the
SCTP library to be able to know this, errors must be propagated, which
they weren't with the argument that packets may get lost anyway.
Bug: webrtc:12943
Change-Id: I9244580abf0d48ff810da30a23f995d12be623ed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228439
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34751}
Recently CPD team rolled out upload completion token feature to all users. Pressure on the system increased. Now became more common situations when upload completed, but because of Datastore limitations we can't see confirmation of it for some measurements.
I've checked 6 recent failures. For all of them amount of timeout measurements were less than 3% (less than 15 in absolute numbers, the biggest percent of failures was for 80 measurements, 2 of which timed out).
Bug: b/182111579
Change-Id: Ia5af367870d1cf7d28b9422c4114c6b85c41f865
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228562
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Andrey Logvin <landrey@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34749}
Some deployments, e.g. Chromium, has a limited send buffer. It's
reasonable that it's quite small, as it avoids queuing too much, which
typically results in increased latency for real-time communication. To
avoid SCTP to fill up the entire buffer at once - especially when doing
fast retransmissions - limit the amount of packets that are sent in one
go.
In a typical scenario, SCTP will not send more than three packets for
each incoming packet, which is is the case when a SACK is received which
has acknowledged two large packets, and which also adds the MTU to the
congestion window (due to in slow-start mode), which then may result in
sending three packets. So setting this value to four makes any
retransmission not use that much more of the send buffer.
This is analogous to usrsctp_sysctl_set_sctp_fr_max_burst_default in
usrsctp, which also has the default value of four (4).
Bug: webrtc:12943
Change-Id: Iff76a1668beadc8776fab10312ef9ee26f24e442
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228480
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34744}
This is a private method, and the `prepare_address` argument was
constant true at all call sites.
Bug: None
Change-Id: Id4714ee7c154a729a6e106c29895fc760e9d0455
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228527
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34739}
Currently, the RtpRtcp module of AudioSendStream is (de)registered in
the packet router on calls to
(Register|Reset)SenderCongestionControlObjects.
This CL changes that to happen on Start/Stop instead, which allows us
to safely call (Get|Set)RtpState on suspend/resume without the need
for extra locking in the rtp module.
See also https://webrtc-review.googlesource.com/c/src/+/228430
Bug: webrtc:11340
Change-Id: I54243a9ace8a7659924269418468b49b967b9465
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228433
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34738}
This is a reland of commit 704a834f685eb96c9fcf891ca345557bef4d138a,
after it was reverted in order to merge a CL to M93.
Original change's description:
> Fix bug where we assume new m= sections will always be bundled.
>
> A recent change [1] assumes that all new m= sections will share the
> first BUNDLE group (if one already exists), which avoids generating
> ICE candidates that are ultimately unnecessary. This is fine for JSEP
> endpoints, but it breaks the following scenarios for non-JSEP endpoints:
>
> * Remote offer adding a new m= section that's not part of any BUNDLE
> group.
> * Remote offer adding an m= section to the second BUNDLE group.
>
> The latter is specifically problematic for any application that wants
> to bundle all audio streams in one group and all video streams in
> another group when using Unified Plan SDP, to replicate the behavior of
> using Plan B without bundling. It may try to add a video stream only
> for WebRTC to bundle it with audio.
>
> This is fixed by doing some minor re-factoring, having BundleManager
> update the bundle groups at offer time.
>
> Also:
> * Added some additional validation for multiple bundle groups in a
> subsequent offer, since that now becomes relevant.
> * Improved rollback support, because now rolling back an offer may need
> to not only remove mid->transport mappings but alter them.
>
> [1]: https://webrtc-review.googlesource.com/c/src/+/221601
>
> Bug: webrtc:12906, webrtc:12999
> Change-Id: I4c6e7020c0be33a782d3608dee88e4e2fceb1be1
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225642
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34544}
Bug: webrtc:12906, webrtc:12999
Change-Id: Id6acab2e2d7430c65f4b6a1d7372388a70cc18ab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228465
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34728}
This relands commit I41cae74605fecf454900a958776b95607ccf3745, after
reverting it in order to merge the revert to M93 (the deadline for
which is now exceeded).
Original change description:
> If a bundle is established, then per JSEP, the offerer is required to
> include the new track in the bundle, and per BUNDLE, the answerer has
> to either accept the track as part of the bundle or reject the track;
> it cannot move it out of the group. So we will never need the transport.
>
> Bug: webrtc:12837
> Change-Id: I41cae74605fecf454900a958776b95607ccf3745
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221601
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34290}
Bug: webrtc:12837
Change-Id: I30a8f03165ab797ed766b51c4eb15c2a9cecb5ed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228500
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34727}
With deferred packet sequencing, the PacketSequencer instance is called
directly from the RtpRtcp module while before it was called from within
the RTPSender while holding a lock.
Since sequence number assignment happens on the same thread as actual
packet sending, though thought was that locking was no longer needed.
Unfortunately, SetRtpState()/GetRtpState() also exists - and while they
should only be called on creating/destruction there is a possible race
where a delayed packet from the pacer accesses the sequencer while
GetRtpState() is being called.
For now, this CL just adds a lock to guard sequencer. Follow-ups will
make sure get/set state is never called while module is attached to
the packet router. After that, the lock can be removed again.
Bug: webrtc:11340, webrtc:12470
Change-Id: I123c762fb4afd20b3a6bd03b86234eb9ec34a209
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228430
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34723}
Change types of const std::string& arguments.
Use absl::string_view for the reference to input, to prepare for
parsing with less copies. Use std::string (passed by value) for the
description, to support ownership transfer without copying.
Bug: None
Change-Id: I4358b42bb824e4eb7a5ac9b64d44db1b9b022bab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/223667
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34721}
This is a reland of 320c57b7c6bf68d8612a4f135f44b3d29e802113
Original change's description:
> red: remove special-casing of no-redundancy
>
> removes the special-casing of not sending a RED header when there is no redundant payload.
> This avoids switching back and forth between the primary and the red payload format (primarily at the start of the connection).
>
> BUG=webrtc:11640
>
> Change-Id: I8e0044bef1ed7c4168d9527645522392db2ed068
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220932
> Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
> Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
> Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34703}
Bug: webrtc:11640
Change-Id: I5e5687be575183ee16d74df4a8170e4fedad739f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228422
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34713}
To support implementing RTCSctpTransportStats, a few metrics are needed.
Some more were added that are useful for metric collection in SFUs.
Bug: webrtc:13052
Change-Id: Idafd49e1084922d01d3e6c5860715f63aea08b7d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228243
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34708}
This corresponds to one part of sstat_unackdata in RFC6458. The
remaining part is the data in the send queue, which isn't packetized
yet, so it must be estimated. But the DATA items in the retransmission
queue is already determined, so it can be easily tracked and retrieved.
Bug: webrtc:13052
Change-Id: I16c3b5b61eb6b3022d7104e6457d943d5df3d6b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228240
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34706}
When pacing is enabled for the low latency rendering path,
frames are sent to the decoder in regular intervals. In case of a
jitter, these frames intervals could add up to create a large latency.
Hence, disable frame pacing if the pre-decode queue grows beyond the
threshold. The threshold for when to disable frame pacing is set
through a field trial. The default value is high enough so that
the behavior is not changed unless the field trial is specified.
Bug: chromium:1237402
Change-Id: I901fd579f68da286eca3d654118f60d3c55e21ce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228241
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34705}
