This queue is a more strict round robing queue, unlike the class
named RoundRobinPacketQueue. That is, we don't have the same logic to
prioritize lower-bitrate streams.
The queue time mechanism is essentially directly copied from the
previous implementation however.
Bug: webrtc:11340
Change-Id: Ie38ba8ce27c985f5f1e907cec068d6a365089bcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260562
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36737}
This reverts commit 942cac2e9e6a205fd673dc003a051cfb3867f2e3.
Reason for revert: Reverting while downstream updates are made.
Original change's description:
> Make deletion of Connection objects more deterministic.
>
> This changes most deletion paths of Connection objects to go through
> the owner class of the Connection instances, Port.
>
> In situations where Connection objects still need to be deleted
> asynchronously, `async = true` can be passed to
> `Port::DestroyConnection` and get the same behavior as
> `Connection::Destroy` formerly gave.
>
> The `Destroy()` method still exists for downstream compatibility, but
> instead of deleting connection objects asynchronously, the deletion
> now happens synchronously via the Port class.
>
> Bug: webrtc:13892, webrtc:13865
> Change-Id: I07edb7bb5e5d93b33542581b4b09def548de9e12
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259826
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#36676}
Bug: webrtc:13892, webrtc:13865
Change-Id: I37a15692c8201716402ba5c10f249e4d3754ce4c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260862
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36736}
Prior to this CL, rollback did not restore FiredDirection and remote
streams were only sometimes restored. This resulted in not firing
ontrack if a track was rolled back and then added again on the same
transceiver.
Rollback also never performed OnTrack, which is incorrect because a
transceiver that goes from sendrecv to inactive will cause OnRemoveTrack
and if this is rolled back (so we become sendrecv again) then we need
OnTrack to fire.
This CL improves rollback's "memory", fires ontrack in Rollback() and
adds test coverage.
Needed to solve similar bugs in the Chromium layers as well:
https://chromium-review.googlesource.com/c/chromium/src/+/3613313
Bug: chromium:1320669
Change-Id: I655dd7d8a6b86080fe0e7c32c9e8c6434062ae91
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260330
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36734}
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 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}
