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}
This is a reland of 3097008de03b6260da5cfabb5cbac6f6a64ca810
Patchset 1 is a pure reland. Patchset 2 contains a bugfix plus a test
covering that case.
Bug: webrtc:12354, chromium:1230448
Original change's description:
> Rename vp9::FrameInfo to vp9::UncompressedHeader and add more fields.
>
> These fields will be used for bitstream validation in upcoming CLs.
> A new vp9_constants.h file is also added, containing common constants
> defined by the bitstream spec.
>
> Bug: webrtc:12354
> Change-Id: If04256d83409069c8bee43ad41aed41c3707dfd3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226060
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Philip Eliasson <philipel@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34476}
Bug: webrtc:12354
Change-Id: Ibd301eb458a6104b562cefbc0e616c39b54fb38b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229060
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34789}
Setting different number of temporal layers is supported by SimulcastEncodeAdapter and LibvpxVp8Encoder will fallback to SimulcastEncoderAdapter if InitEncode fails.
Bug: none
Change-Id: I8a09ee1e6c70a0006317957c0802d019a0d28ca2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228642
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34785}
Using usrsctp_getladdrs() would sometimes be flagged by TSAN for a lock
order inversion. It was used to retrieve the "id" of the socket on the
transport.
The "id" is instead stored in the "ulp_info" parameter, which is
passed with each callback from usrsctp.
Bug: webrtc:12823
Change-Id: Ifb3d7780273a460e677526dd3a93f9365b29300c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/229000
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34784}
