Deletes the helper methods SdpSetObserver and SdpCreateObserver,
replaced with observer classes where used, in peer_scenario_client.cc.
Deletes the class webrtc_sdp_obs_impl::SdpSetObserversInterface, which
indirectly inherits rtc::RefCountInterface twice. Migrates this code
to use rtc::make_ref_counted, and migrates away from deprecated
versions of SetLocalDescription and SetRemoteDescription that use raw
pointers and SetSessionDescriptionObserver.
Bug: webrtc:12701, webrtc:11798
Change-Id: I18ea3fb51f533d7454a6dc75292b1827b1c80ef0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229981
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Sebastian Jansson <srte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34843}
This patch adds a vp preference field to RTCConfig.
DEFAULT, // No VPN preference.
ONLY_USE_VPN, // only use VPN connections.
NEVER_USE_VPN, // never use VPN connections
PREFER_VPN, // use a VPN connection if possible, i.e VPN connections sorts higher than all other connections.
AVOID_VPN, // only use VPN if there is no other connections, i.e VPN connections sorts last.
Bug: webrtc:13097
Change-Id: I3f95bdfa9134e082c7d389f803bd08facfb70262
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229591
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34842}
This change does not affect downstream dependencies as androidx.annotation
is fully compatible with android.support.annotation.
Bug: webrtc:11962
Change-Id: I714b473df8d0fee8000ddf3a9beca7c5613db5ff
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226881
Commit-Queue: Xavier Lepaul <xalep@webrtc.org>
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34839}
Instead offer getters for the sync_group and rtp struct. Both are
a part of the config but expose much less of the config, which has
mutable parts.
Bug: none
Change-Id: Icc8007246e9776a5d20f30cda1a2df3fb7252ffc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229980
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34838}
Having ScopedFieldTrials at class scope might introduce some hard
to understand lifetime patterns. Keeping them in scope only for the
Run method simplifies that, reducing the risk of problems.
Bug: b/197053062
Change-Id: I1c1239757387443552a7b5f83f68014ee56e4248
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229920
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34836}
The config struct is big and in order to control access to its state,
some of which isn't always const, we need to limit raw unlocked access
to it from other classes.
Bug: none
Change-Id: I4513c41486e79ef6c5cfd6376122ab338ad94642
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229921
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34835}
PeerConnectionFactory to break off the dependency.
- This is required so that Android app that doesn't use the
peerconnection_java as dependency can include android monitor
directly without incurring size bloat.
Bug: None
Change-Id: I7b3453f268467550c0a4b3a0bbf858d55d2fd8a4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229322
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Tim Na <natim@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34829}
This CL adds an RTC_CHECK in both ctor and dtor to ensure field trials
are valid. Even if the check in the ctor is done already in debug mode,
having it done always is fine because ScopedFieldTrials are testonly.
The check in the dtor should catch issues like reverting to another
ScopedFieldTrial which has already been destroyed.
Bug: None
Change-Id: I53a8680c3ff4fd0e2cbb3055af726a9023b45ac7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229861
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34828}
This patch adds small cost to Vpn connections
so that a "raw" connection identical to a vpn connection
will be chosen first.
The feature is gated by a field trial WebRTC-AddNetworkCostToVpn
for safe roll out.
Bug: webrtc:13097
Change-Id: I4ad40fa00780a6d7f89cacf6f85f3db4ecd0988c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229585
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34822}
Don't DCHECK that network send is successful, it may fail, e.g., EPIPE
if remote end has disconnected.
Bug: None
Change-Id: I7ccff072420498b60fe16598110da91b01bfe7cb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229384
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34821}
It's not clear why the availability check doesn't work,
but the plain old macro works just fine, so we can get rid of
the suppression of another compiler warning.
Fixed: webrtc:10837
Change-Id: I4f5bcba794a0e34103e581c3e6495c9542e07342
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228701
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34819}
Before this change HardwareVideoEncoder used capture time as frame
timestamp passed to HW encoder. That led to buffer overshoots with
HW encoders which infer frame rate from timestamps when frames were
dropped before encoding (i.e., frame rate decreases according to frame
timestamps) or when FramerateBitrateAdjuster was used.
Fixed this by using synthetic monotonically increasing timestamps
calculated based on target frame rate provided by bitrate adjuster.
Bug: webrtc:12982
Change-Id: I2454cd4e574bbea1cb9855ced4d998104845415c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228902
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34810}
After a send stream is stopped, it can still be re-used and implicitly
restarted by activating layers. This change removes marking the flag
we use for async operations as 'not alive' inside Stop() and only doing
so when the send stream is stopped permanently.
The effect this has is that an implicit start via
UpdateActiveSimulcastLayers() will run and correctly update the states.
Before, if a stream had been stopped, the safety flag would prevent
the async operation from running.
Bug: chromium:1241213
Change-Id: Iebdfabba3e1955aafa364760eebd4f66281bcc60
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229304
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34809}
I meant to do this with the Chromium change but forgot. UMA registers
zero uses of 3DES, so this should be safe. (Not too surprising, since
3DES had already been obsolete for just under a decade by the time
WebRTC existed.)
Bug: chromium:1203442
Change-Id: I5bddd2bd3f24beb486c8246fa5dab5836883b8c1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229120
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: David Benjamin <davidben@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34806}
dcSCTP seems to be able to provoke usrsctp to send ABORT in some
situations, as described in
https://github.com/sctplab/usrsctp/issues/597. Using a packetdrill
script, it seems as a contributing factor to this behavior is when a
FORWARD-TSN chunk is bundled with a DATA chunk. This is a valid and
recommended pattern in RFC3758:
"F2) The data sender SHOULD always attempt to bundle an outgoing
FORWARD TSN with outbound DATA chunks for efficiency."
However, that seems to be a rare event in usrsctp, which generally sends
each FORWARD-TSN in a separate packet.
By doing the same, the assumption is that this scenario will generally
be avoided.
With many browsers and other clients using usrsctp, and which will not
be upgraded for a long time, there is an advantage of avoiding the issue
even if it is according to specification.
Before this change, a FORWARD-TSN was bundled with outgoing DATA and due
to this, it wasn't rate limited as the overhead was very little. With
this change, a rate limiting behavior has been added to avoid sending
too many FORWARD-TSN in small packets. It will be sent every RTT, or
200 ms, whichever is smallest. This is also described in the RFC.
Bug: webrtc:12961
Change-Id: I3d8036a34f999f405958982534bfa0e99e330da3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229101
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34801}
All decoders are supposed to be able to decode all valid bitstreams
that can be produced by an encoder. In the cases where this is not
the case, reference_scaling better captures the cause of this than
scalability_mode which was used initially.
Bug: chromium:1187565
Change-Id: I21174077badf0fb9d90b1b58f003edac5b8ee0f2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229184
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34800}
