This reverts a change introduced last week in [1] whereby the port_
pointer would be valid while firing the `Destroyed` event.
[1] https://webrtc-review.googlesource.com/c/src/+/259826
Bug: webrtc:13892, webrtc:13865
Change-Id: I9c7be8fa9a5603fbdbf0debd91e2d4e21b303270
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260860
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36728}
This reduces the visibility of the implementation details
of cricket::ChannelInterface implementations.
Bug: webrtc:13931
Change-Id: Ia720a297821c1ddc242af2b04da4f52b1e04ab6b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260560
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36727}
Since MSVC bots has been removed, we can't say that MSVC is supported.
Bug: webrtc:13232
Change-Id: I39c6b8d9ef7af2aca6c6e5f2e5c44c9b1146145b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260521
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36726}
This limits the exposure of the implementation of ChannelInterface.
Bug: webrtc:13931
Change-Id: Ifc0fa496c210413d81ad71f44fa4040b881d092c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260561
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36725}
Before this CL, fast retransmission didn't follow the SHOULDs:
https://datatracker.ietf.org/doc/html/rfc4960#section-7.2.4
* "the sender SHOULD ignore the value of cwnd (...)"
* "(...) and SHOULD NOT delay retransmission for this single
packet."
With this CL, chunks that are eligible for fast retransmission (limited
to what can fit in a single packet) will be sent just after having
received the SACK that reported them missing and transitioned the socket
into fast recovery, and they will be sent even if the congestion window
is full.
Bug: webrtc:13969
Change-Id: I12c7e191a8ffd67973db7f083bad8a6061549fa2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259866
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36724}
This CL makes OutstandingData keep track of chunks that are eligible for
fast retransmission. When the socket goes into fast recovery, the
reported missing chunks can be retransmitted quickly (ignoring the
congestion window) according to
https://datatracker.ietf.org/doc/html/rfc4960#section-7.2.4.
The CL also adds the new API to OutstandingData to retrieve only the
chunks that are eligible for fast retransmission, and moves the
remaining chunks to the ordinary list of chunks to be retransmitted
later.
This solves an issue where the retransmission timer wouldn't start if
there wouldn't be any chunks to fast-retransmit.
It doesn't, however, make sure that chunks that should be fast
retransmitted can send even when the congestion window is full. That
will be solved in the follow-up CL.
Bug: webrtc:13969
Change-Id: If4012d1cb284ef4a2d815683ed60cbbbff5b3c3b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259865
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36721}
This makes the channel manager object into a factory, not a manager.
Bug: webrtc:13931
Change-Id: I59f7d818a739797a7c0a7a32e6583450834df122
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260467
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36718}
In https://webrtc-review.googlesource.com/c/src/+/244420,
I added sanity check of RTCVideoFrame in RTCMTLVideoView, but I forgot
to modify the related tests.
Fix this by adding the appropriate property stubs to RTCVideoFrame stubs
created in RTCMTLVideoViewTests.
Bug: webrtc:13990, webrtc:13490
Change-Id: I21f0f75cd052e4255e1eee5f39ffdd50c2f8e61b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260420
Reviewed-by: Peter Hanspers <peterhanspers@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#36714}
See a full explanation of the problem on this blog [1] post about changing
std::sort in LLVM and relative issues uncovered.
The CompareNetwork function was violating the 4th rule of "strict weak
ordering" (Transitivity of incomparability: x == y and y == z imply x == z, where x == y means x < y and y < x are both false).
[1] - https://danlark.org/2022/04/20/changing-stdsort-at-googles-scale-and-beyond/
Bug: None
Change-Id: I7e893f0a30da31403766284823f75c45c4db91c3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251681
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36711}
This calls out the fact that SetChannel() is only used on M-section activation; ClearChannel is called on deactivation, and we never change the channel while a transceiver is active.
Bug: webrtc:13931
Change-Id: I3a3bfeec7c1d27d98c3f94a9401bee2130754ed7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260461
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36709}
Fixing a race condition where session.sampleRate changes before AudioDeviceIOS::HandleValidRouteChange() finishes.
session.sampleRate is read into session_sample_rate at 576 and used at 623 to initialize the audio unit. However, in the call to SetupAudioBuffersForActiveAudioSession() the session.sampleRate is read again and may have changed, resulting in different sample rates used for the buffers and the audio unit. The consequence is a sample rate mismatch with either high pitched or low pitched audio.
The fix is to always use the buffer sample rate for the audio unit.
The DCHECK at 622 would save us in debug, but not in production, hence removed.
Change-Id: I562f1bf7f94d7447139ada2636b02ade7fcd6371
Bug: webrtc:14011
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260329
Reviewed-by: Henrik Andreasson <henrika@google.com>
Commit-Queue: Peter Hanspers <peterhanspers@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36708}
This CL replaces two booleans, that could never be active at the same
time (there is no such thing as an abandoned chunk that is scheduled
for retransmission), with a single enum.
Just for increased readability, and to understand that there is no such
thing as an abandoned chunk that will be retransmitted.
Bug: None
Change-Id: I1682c383aed692db07fd4ae1f84c0166db86c062
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259864
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36707}
This is a reland of commit 7679e9bf071250e8e98ef6ef58962ddcc73cd498
Breakage in chrome/services/sharing/ (not built as part of webrtc
presubmit) should be fixed with
https://chromium-review.googlesource.com/c/chromium/src/+/3604642
Original change's description:
> Delete deprecated versions of MergeNetworkList
>
> Bug: webrtc:13869
> Change-Id: I6b888ba14ca664a1f28de2fb59b7d1343cb18bd8
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259300
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#36611}
Bug: webrtc:13869
Change-Id: I4cf0fe0f2310eabb2d0b32c6dec5f8aef64c7712
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259869
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36704}
(Used to run gtests on iOS, but we don't want to depend on //base.)
Optimistically try to use the existing partial fork
Bug: webrtc:13402
Change-Id: I10528670862f2db67e77adb73b8a71b19642666d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260328
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36703}
With MSVC, compiling with AVX2 support will also result in the
generation of BMI2 instructions. Some early Haswell CPUs reportedly support AVX2 but not BMI2. We have seen crashes (illegal instruction)
on these CPUs in our AVX2 code paths on MULX instructions (part of BMI2).
Including a check for BMI2 when checking for AVX2 support is
expected to solve the issue.
Please see the bug referenced below for more background on this issue.
Bug: chromium:1315519
Change-Id: I3a0a9838f1f632704ba505ecbb81a6f8b1889319
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260323
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Henrik Andreasson <henrika@google.com>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36701}
which signals a permanent connection failure to the application
BUG=webrtc:13999
Change-Id: I7ba25db4aa9035583558a613db97561c48796c76
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260100
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/main@{#36700}
This makes it clearer which modules set the channel.
Also remove GetChannel() from PeerConnection public API
This was only used once, internally, and can better be inlined.
Part of reducing the exposure of Channel.
Bug: webrtc:13931
Change-Id: I5f44865230a0d8314d269c85afb91d4b503e8de0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260187
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36695}
video_stream_decoder2 is the only one used.
Change-Id: Iabee3521b2946f097296cf2b02025aa6e41e87a4
Bug: webrtc:11489
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260282
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36692}
This is achieved by wrapping a fake decoder inside the mock decoder, in
a sort of spy pattern.
This is preperation for moving the FrameBufferProxy tests into the main
VideoReceiveStream2 suite.
Bug: webrtc:14003
Change-Id: I7b9691cc5a1a8a3fadfb7aa6981752b647d5c73f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260113
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36691}
...and add to TCPConnection as it's still needed there.
Bug: webrtc:11943
Change-Id: Id66b890677d7e0b03a4a700414f574abd6e3af58
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260320
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36689}
This is mainly an issue when sending items with partial reliability,
with high bandwidth on a link with packet loss.
In SCTP, when a fragment isn't included in the SACK a number of times,
it's scheduled to be retransmitted or abandoned, if it has been
retransmitted too many times already (depending configuration). Before
this CL, if a fragment was NACKed and scheduled for retransmission, but
couldn't be retransmitted immediately (due to congestion window not
allowing it), future received SACKs - that would still indicate that the
fragment hasn't been received yet - would still increment the
retransmission counter. Which wasn't fair, because this fragment hasn't
had a chance to be retransmitted yet.
With this CL, the fragment will only have its retransmission counter
increased when it is not already scheduled to be retransmitted, but
actually sent on the wire and considered in-flight again.
Bug: webrtc:12943
Change-Id: I2af08255650221c044cc14591a5835c885e94c58
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259825
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36683}
