This is a follow up of this CL: https://crrev.com/c/3611486.
Bug: b/231404336
Change-Id: I3b6f4b780aa1939b6b2d0f1d08d1746a3a6f86dc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261080
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36752}
This also hides the existence of the classes VideoChannel and
VoiceChannel from anything that does not include "channel.h".
Bug: webrtc:13931
Change-Id: I080a692b6acfd5d2d0401ec20d59c3a684eddb05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260944
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36746}
This extends AlwaysValidPointer to take a lambda for its default
rather than requesting a constructor.
Bug: none
Change-Id: Ied97968c3f511af15422a1eef9801d14d4ec5b96
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260580
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36745}
Also eliminate FillBitrateInfo from the Channel object.
Bug: webrtc:13931
Change-Id: I5265b7629413a1ed04898272adf26708e2ee9b8d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260469
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36744}
The feature is now enabled in other ways. See PSA or linked Monorail issue for details.
https://groups.google.com/g/discuss-webrtc/c/mJV5cDysBDI/m/7PTPBjVHCgAJ
Bug: webrtc:11539
Change-Id: I0f5816baf2bfa1508a1c85ddbd7b775417434c62
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260107
Auto-Submit: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36742}
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}
