The purpose is to ensure send socket buffers are not overfilled at high
pacing rates.
Bug: chromium:1354491
Change-Id: Ic6f473080292f84a2a099b85fb5817f7e14e7355
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323000
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40911}
since the extension can be too large to fit the 16 bytes available
to one-byte extensions
https://www.rfc-editor.org/rfc/rfc8285#section-4.2
when including the width and height fields.
Also document when those fields are sent.
BUG=webrtc:12000
Change-Id: If17f57d40c0bde9b060f223c548e407d6c124b82
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321200
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40910}
Convert most field trials used in PCLF tests.
Change-Id: I26c0c4b1164bb0870aae1a488942cde888cb459d
Bug: webrtc:10335
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322703
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40909}
Checking in sending classes avoids using global field trial string in favor of the injected one.
In addition to that RateLimiter looks wrong layer for check that field trial:
checking inside RateLimiter class might be surprising if it is used for limiting something else than RTX bitrate.
evaluating field trial for each retransmitting packet might be expensive
Bug: webrtc:15184, webrtc:10335
Change-Id: I87bae3522bbd9692629d4f9b6caa119be03f2bd6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322720
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40908}
This patch is a follow up to https://webrtc-review.googlesource.com/c/src/+/260943
which made it possible to destroy a Port before a Connection (on that
port).
This patch "reverses" this, by adding RTC_DHECK, and fixes the Port
destructor to release the Connections before invalidating the WeakPtr<>.
Currently there are no known occurrences where a Connection is destroyed after it's Port is. But prior to the change in Port destructor, a bunch unit tests failed on the newly added DCHECKs.
In addition:
a) modify StunReqquestManager to remove entry from hash before calling callback. This makes it possible for callback to modify (clear) hash.
b) clear pending requests when disconnecting from port, "should not be needed", depends on a)
c) add a getter for pending_delete()
Bug: webrtc:13892, webrtc:13865
Change-Id: I5d18f2db8d93b7cc25d18bd620063589ee9257c9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322861
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40907}
This removes internal usage of AsyncResolver, including from
PhysicalSocketServer.
PhysicalSocketServer was also run through IWYU.
Bug: webrtc:12598
Change-Id: I18aa6fb60e4a40face4afa0446a161379470680d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322721
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40900}
This field trial is configured via command line flag, so may use flag system directly, reducing dependency on global field trial string.
Bug: webrtc:7101, webrtc:10335
Change-Id: I1e48e0e3fdc251b73a375c6d7f1a46fa4f8a179b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322624
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40897}
Its predecessor is being used directly by at least one Chromium function.
Bug: webrtc:12598
Change-Id: I0c521f03cf6664036a48d5d45dcacaa74ae8582c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322800
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40896}
Do not automatically remove all tokens once we attempt to use them. This
mitigates an issue with Google Meet where an additional instance of a
DesktopCapturer is created and destroyed right away, taking away the
token we would use otherwise. Also save the token under same SourceId
once we get a new (but could be same) token from the restored session.
Bug: webrtc:15544
Change-Id: I565b22f5bf6a4d8a3b7d6d757f9c1046c7a0557d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322621
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40892}
When a sender has requested a stream to be reset, and the last sender
assigned TSN hasn't been received yet, the receiver will enter deferred
reset mode, where it will store any data chunks received after that
given TSN, and replay those later, when the stream has been reset.
Before this CL, leaving deferred mode was done as soon as the sender's
last assigned TSN was received. That's actually not how the RFC
describes the process[1], but was done that way to properly handle some
sequences of RE-CONFIG and FORWARD-TSN. But after having read the RFCs
again, and realizing that whenever RFC6525 mention "any data arriving",
this also applies to any FORWARD-TSN[2] - it's better to reset streams
synchronously with the incoming requests, and defer not just DATA past
the sender last assigned TSN, but also any FORWARD-TSN after that TSN.
This mostly simplifies the code and is mostly a refactoring, but most
importantly aligns it with how the resetting procedure is explained in
the RFC. It also fixes two bugs:
* It defers FORWARD-TSN *as well as* DATA chunks with a TSN later
than the sender's last assigned TSN - see test case. The old
implementation tried to handle that by exiting the deferred reset
processing as soon as it reached the sender's last assigned TSN, but
it didn't manage to do that in all cases.
* It only defers DATA chunks for streams that are to be reset, not
all DATA chunks with a TSN > sender's last assigned TSN. This was
missed in the old implementation, but as it's now implemented
strictly according to the RFC, this was now done.
[1] https://datatracker.ietf.org/doc/html/rfc6525#section-5.2.2
[2] RFC6525 cover stream resetting, and RFC3758 cover FORWARD-TSN, and
the combination of these is not covered in the RFCs.
Bug: webrtc:14600
Change-Id: Ief878b755291b9c923aa6fb4317b0f5c00231df4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322623
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40889}
Return the error code from ValidateSessionDescription rather than
returning INTERNAL_ERROR for every failure case.
Bug: chromium:1490510
Change-Id: I3b745174ce986f9d7ebfa051c116b1c9d29e31c2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322622
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40885}
ARM-specific settings were intended to be used on mobile ARM devices which may not be powerful enough. But the settings were also applied to ARM-based Macs. This changes restricts ARM-specific settings to Android and iOS platforms.
Bug: none
Change-Id: I68764b4c0679db07399bba5923f4a6be89c5ad80
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321861
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Jerome Jiang <jianj@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40884}
With shared EglConnections each client must ensure their EGLSurface
is made current every time they access the thread. This will lead to
unnecessary eglMakeCurrent calls when the EGLSurface is in fact already
current, such as when the EglConnection only has one client or when one
client accesses the thread without interruption.
Bug: b/217863437
Change-Id: I1b03daec4d5cd43af21fe9c168e3637f676b6fec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322322
Reviewed-by: Ranveer Aggarwal <ranvr@webrtc.org>
Commit-Queue: Linus Nilsson <lnilsson@webrtc.org>
Reviewed-by: Zoé Lepaul <xalep@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40883}
Before this CL, a message was identified by the triple (stream_id,
is_unordered, MID) (and yes, the MID is always present in the send
queue, even when interleaved message is not enabled.). So when a chunk
was abandoned due to e.g. having reached the retransmission limit, all
other chunks for that message in the retransmission queue, and all
unsent chunks in the send queue were discarded as well.
This works well, except for the fact that resetting a stream will result
in the MID being set to zero again, which can result in two different
messages having the same identifying triple. And due to the
implementation, both messages would get abandoned.
In WebRTC, an entire data channels is either reliable or unreliable, and
for a message to be abandoned, the channel must be unreliable. So this
means that in the case of stream resets - meaning that a channel was
closed and then reopened, an abandoned message from the old (now closed)
channel would result in abandoning another message sent on the re-opened
data channel.
This CL introduces a new internal property on messages while in the
retransmission and send queue; The "outgoing message id". It's a
monotonically increasing identifier - shared among all streams - that is
never reset to zero in the event of a stream reset. And now a message is
actually only identified by the outgoing message id, but often used
together with the stream identifier, as all data in the send queue is
partitioned by stream. This identifier is 32 bits wide, allowing at most
four billion messages to be in-flight, which is not a limitation, as the
TSN is also 32 bits wide.
Bug: webrtc:14600
Change-Id: I33c23fb0e4bde95327b15d1999e76aa43f5fa7db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322603
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40881}
This will allow to stop CLs on CQ in case the CL is adding or removing
a field trial without updating the field trial registry.
This only affects debug and release bots but not pure_release bots
since they are used for performance tests.
Bug: webrtc:14154
Change-Id: Iab277fd4791b6f0cfb5304fd4e39a8519ea71198
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321880
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40877}
MID is a RFC8260 property on an I-DATA chunk, replacing the SSN property
on the DATA chunk in non-interleaved message. The MID stands for
"Message Identifier", and it was frequently named "message_id" in the
source code, but sometimes "mid". To be consistent and using the same
terminology as is most common in the RFC, use "mid" everywhere.
This was triggered by the need to introduce yet another "message
identifier" - but for now, this is just a refacotring CL.
Bug: None
Change-Id: I9cca898d9f3a2f162d6f2e4508ec1b4bc8d7308f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322500
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40876}
This is a reland of commit 0d4b350006eae7dfeeb8c67f16f51b1c62351cee
Patchset 1 is the original CL. Patchset 2 contains a small tweak of the target bitrate in the unit test, in order to make in less susceptible to flakiness on runtime environments running a slightly different libvpx.
Original change's description:
> Add mitigation for very long frame drop gaps with vp8
>
> Bug: webrtc:15530
> Change-Id: I11f5e3f31f71301700dbff3fc9285236160bee45
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322320
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Auto-Submit: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#40866}
Bug: webrtc:15530
Change-Id: I096b7d952286f7f53852d1ca70aea398b2747784
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322540
Auto-Submit: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40874}
