With the encoding parameters in the SimulcastConfig objects, it wasn't
possible to configure explicit encoding parameters when using singlecast,
required for example to use the spec standard SVC API.
Bug: webrtc:11607
Change-Id: I92b1446e772e2ecec93379dc91a3da159b8bc209
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260002
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36731}
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}
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}
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}
(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}
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}
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}
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}
