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}
This CL is a minor cleanup of the work done earlier in [1].
We now remove the arguments which contained the measured delta times
between two TRACE_EVENT_ASYNC_BEGIN and TRACE_EVENT_ASYNC_END events.
Also, the ID for FrameToQueue1 is now unique which was not the case
previously.
The same information can be obtained from the `slice` table and the
`dur` key.
Also renames the events to OnFrameToEncode (total), OnFrameToQueue and
QueueToEncode to match what it measures better.
[1] https://webrtc-review.googlesource.com/c/src/+/322121
Bug: webrtc:15456
Change-Id: Ibe2d7bb53380710671c2c36012dcd573942bae69
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322220
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40860}
Similar to change I602a8552a9a4c853684fcf105309ec3d8073f2c2, which
ensured that only new DATA chunks would be processed by the reassembly
queue by utilizing the data tracker, the same is done for FORWARD-TSN
chunks.
By having the data tracker gate keeping what is provided to the
reassembly queue, the reassembly queue can be simplified as well, which
is an added bonus, by removing last_assembled_tsn_watermark_ and
reassembled_messages_ as those were protecting the queue from
re-delivering messages it had already delivered, but as now the data
tracker would ensure that it wouldn't re-process DATA/FORWARD-TSNs, that
would have the same effect. In this CL, we will still update those
variables and save to the handover state, but not actually read from
them, and then when this change has been rolled out on the servers, I
can remove the variables as well.
The core change is to move validation from ReassemblyQueue::Handle
to DataTracker::HandleForwardTsn.
Some tests have been moved/replicated into data_tracker_test.cc to
ensure that it catches the issues that the reassembly queue did earlier.
Bug: webrtc:14600
Change-Id: I75c1d5911185d594f73c8b1e6bcf776e88f5b7c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321603
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40856}
There's no trace of it being in use, so let's remove it.
Bug: webrtc:12497
Change-Id: I9e81ef58b459b5a0b9f79b6638231a3a19eb8a0e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322180
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Auto-Submit: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40855}
Does not change any functionality but improves the ability to look
for (using Perfetto) possible latency issues where a posted task might
be prevented from running.
Bug: webrtc:15456
Change-Id: I522599c646c8de2183074628df9cab337b1cb85d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322121
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40854}
