This reverts commit 0ba10283fb.
Reason for revert: This workaround is no longer needed, as the libyuv team has already fixed the underlying issue (in b/234824290)
Original change's description:
> Fix memory corruption in BasicDesktopFrame::CopyTo
>
> This memory corruption happens inside libyuv::CopyPlane()
> on platforms that support AVX. I opened b/234824290 so the libyuv team
> can investigate and fix this, but in the mean time we need to get this
> fixed asap as this is causing crashes on both M102 (which is released to
> stable) and M103 (which has this issue marked as beta blocking).
>
> Fixed: b/234824290
> Fixed: chromium:1330019
> Test: Manually reproduced on zork board
> Change-Id: I6bfd1e089020dfb23d974d3912d45c01a4e5ce26
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265041
> Auto-Submit: Jeroen Dhollander <jeroendh@google.com>
> Commit-Queue: Alexander Cooper <alcooper@chromium.org>
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#37121}
Fixed: b/234824290
Fixed: chromium:1330019
Change-Id: Iafc0eac651fbc7a7fce5092306b12c4377248839
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265165
Auto-Submit: Jeroen Dhollander <jeroendh@google.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Frank Barchard <fbarchard@google.com>
Cr-Commit-Position: refs/heads/main@{#37142}
Make HasDataToSend not mutate any state, and let the Produce method do
all state mutation and possibly indicate if there is nothing that can be
sent. This is helpful preparation for extracting the scheduling part of
the send queue to a separate component.
Bug: webrtc:5696
Change-Id: I132779e77d3ce6a41e5fcf4432140d3728d03cdc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261945
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37141}
This CL introduces PacketQueue::SizeInPacketsPerRtpPacketMediaType
keeping track of the number of packets in the queue per
RtpPacketMediaType.
The TaskQueuePacedSender is updated not to apply slack if the queue
contains any kRetransmission or kAudio packets. The hope is that not
slacking retransmissions will make the NACK/retransmission regression
of the SlackedPacer experiment go away. Wanting to not slack audio
packets is unrelated to the regression but a sensible thing to due
since audio is highest priority.
This CL does not change anything when the SlackedPacer experiment is
not running, since if its not running then none of the packets are
slacked.
Bug: webrtc:14161
Change-Id: I1e588599b6b64ebfd7d890706b6afd0b84fd746d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265160
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37139}
Removes all remaining usage of SetType and marks the method as
deprecated.
Bug: none
Change-Id: I98dc613978ffe7ad8a4ffd951dd974d56ed92983
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265100
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37137}
SrtpTransportInterface has been deleted, but the comment is still
retained.
Bug: None
Change-Id: I5565a29bea663a396560f7458abbe902187b1338
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264660
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37131}
This is the receive-side part of supporting what is frequently called
"ndata", but actually RFC8260 - "User Message Interleaving".
This CL adds a new ReassemblyStreams implementation that can assemble
I-DATA chunks and process I-FORWARD-TSN for partial reliability.
Bug: webrtc:5696
Change-Id: I3cfbea62e7b6c02fbd3f51b43ba3fb7863cf0f88
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218506
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37128}
Construction in StunRequest and derived classes now happens in
the ctor.
Bug: none
Change-Id: I803f6fd2b6d0ac1d9426304d1e1de10dec855eed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264942
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37126}
This moves the construction of StunMessage instances for
ConnectionRequest, outside of the Prepare() method.
Following this, removing Construct()+Prepare() is relatively
straight forward.
Bug: none
Change-Id: Ibcf0510cef30a6e648005b43602c7ae1fb06729e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264558
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37122}
This memory corruption happens inside libyuv::CopyPlane()
on platforms that support AVX. I opened b/234824290 so the libyuv team
can investigate and fix this, but in the mean time we need to get this
fixed asap as this is causing crashes on both M102 (which is released to
stable) and M103 (which has this issue marked as beta blocking).
Fixed: b/234824290
Fixed: chromium:1330019
Test: Manually reproduced on zork board
Change-Id: I6bfd1e089020dfb23d974d3912d45c01a4e5ce26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265041
Auto-Submit: Jeroen Dhollander <jeroendh@google.com>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37121}
This change removes the following after internal cleanup:
- IceRecheckEvent::Type enum, replaced with IceSwitchReason
- IceControllerEvent alias for IceRecheckEvent
Bug: webrtc:14125, webrtc:14131
Change-Id: I07bfeb7fa8a9c4d4a3f940213befd6418dfd6644
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264145
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Cr-Commit-Position: refs/heads/main@{#37118}
When the slacked pacer experiment is enabled the next pacing opportunity
may be a full tick (~16 ms) from now. Add a flag to allow experimenting
with a burst interval (= 16 ms?) such that we can send bursts in
MaybeProcessPackets.
A common use case would be that EnqueuePackets triggers
MaybeProcessPackets when we are off-tick but we'd still like to create
an immediate burst instead of waiting for the next tick or two for that
to happen.
Bug: webrtc:14152
Change-Id: Ib0ed8312cb7d53b80f3520fff3a6e3bbb5a93fd1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264985
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37116}
This is a re-land of commit 3180a5ad06.
This is an issue found in fuzzer, and doesn't really happen in WebRTC
as it never closes the connection and reconnects.
The issue is that the send queue outlives any connection since you're
allowed to send messages (well, enqueue them) before the association is
fully connected. So the send queue is always present but the TCB
(information about the connection) is torn down when the connection is
closed for example. And the TCB holds the Stream Reset handler, which is
responsible for e.g. keeping track of stream reset sequence numbers and
such - which is tied to the connection.
So to ensure that the Stream Reset Handler is in charge of deciding
if a stream reset is taking place, make sure that the send queue is in
a known good state when the Stream Reset handler is created.
Bug: webrtc:13994, chromium:1320194
Change-Id: Ib8254488523c7abb58057c602f76f411fce896fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265000
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37115}
APM has historically allowed sample rates not divisible by 100, but there is also code that explicitly states that such rates are not supported.
It is unclear how well rates like 22050 are handled in practice.
This CL adds support for fuzzing more sample rates, to help find issues.
We usually preserve fuzzer data reads to avoid invalidating unresolved fuzzer-found issues, but to make the code a little more readable this CL removes the discarded reads. This renders the only currently open bug non-reproducible, crbug.com/1299393.
Bug: webrtc:9413, chromium:1299393
Change-Id: I98ac1c653627c20adc73b8edede02f1526d80d9d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264504
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37114}
This is verifying the theory that the fix on bug 12592 also fixed
bug 3608.
Bug: webrtc:3608, webrtc:12592
Change-Id: Ia1f5ba5ebdc9a839034092351c970c3b6a159fa2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264829
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37113}
This changes renames the event to better suit its purpose. An alias
with the old name is added for compatibility pending internal cleanup.
Bug: webrtc:14125, webrtc:14131
Change-Id: I87026e19f2620eaa6a6770dcbedf1d0399c6c6b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264149
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Cr-Commit-Position: refs/heads/main@{#37111}
The current code assumed that chunks that were scheduled for fast
retransmission would never be abandoned, as chunks marked for fast
retransmission would be immediately sent after the SACK has been
processed, giving no time for them to be abandoned.
But fuzzers keep on fuzzing, and can craft a sequence of chunks that
result in a SACK that both marks the chunks for fast retransmission and
later (while processing the same SACK) abandons them.
Bug: chromium:1331087
Change-Id: Id218607e18a6f3a9d6d51044dccb920e1e77372a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264960
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Auto-Submit: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37108}
This is a partial reland of commit 794e68cf3d
which uses the new enum in P2PTransportChannel and BasicIceController.
Original change's description:
> Refactor IceControllerEvent
>
> This change is the first step in decoupling IceControllerEvent from
> the ICE switch reason. Further cleanup is earmarked, and will be
> landed after some internal cleanup.
>
> This change
> - adds a new enum - IceSwitchReason
> - adds a member for the new enum in IceControllerEvent
> - uses the new enum within P2PTransportChannel
> - adds methods to IceControllerInterface accepting the new enum
> - deprecates usages of the old enum in IceControllerInterface
> - adds conversion between the old and new enums for compatibility
>
> Bug: webrtc:14125, webrtc:14131
> Change-Id: I5b7201c3f631eb40db334dfeec842841a7e58174
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264140
> Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
> Commit-Queue: Sameer Vijaykar <samvi@google.com>
> Cr-Commit-Position: refs/heads/main@{#37051}
Bug: webrtc:14125, webrtc:14131
Change-Id: I81b0338ae2f0560cd3df7ad9bd9af37e7c3499df
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264554
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Sameer Vijaykar <samvi@google.com>
Cr-Commit-Position: refs/heads/main@{#37105}
Allows the PacerController to send packets in bursts. If there are enqued packets, or a packet is enqueued while the pacer have a small media debt, an enqued packet is allowed to be sent immediately as long as the debt is smaller than the set burst interval.
Bug: b/233850913
Change-Id: Ibb0fa63c97409ca23b9fa7148b5ff6ce8c4517e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264462
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37098}
Adds a function to PeerConnectionIntegrationBaseTest to stop and destroy
the caller and callee objects. This should take care of dangling pointers.
Before this change, the affected test would crash randomly - typically
detected within a few minutes of a gtest-repeat=-1 run.
After this change, it has not crashed in 15 minutes of running.
Bug: webrtc:12592
Change-Id: I9980f8974015bf2b2104fcb83c2ca0d677d03c3e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264555
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37096}
