These tests create multiple transceivers, and attempt to renegotiate.
They serve to show where the limit is for adequate performance (arbitrarily
set as one second).
This version should pass on all platforms; it only tests up to 16 tracks.
Bug: webrtc:12176
Change-Id: I1561a56f6a392dbfa954319c538a9959c3a6f590
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/193061
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32820}
- Add Flex FEC format as default supported receive codec
- Disallow advertising FlexFEC as video sender codec by default until implementation is complete
- Toggle field trial "WebRTC-FlexFEC-03-Advertised"s behavior for receiver to use as kill-switch to prevent codec advertising
Bug: webrtc:8151
Change-Id: Iff367119263496fb335500e96641669654b45834
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/191947
Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32639}
This fixes regressions caused by:
https://webrtc-review.googlesource.com/c/src/+/183120
... which disabled payload type demuxing when multiple video tracks are
present, to avoid one channel creating a default track intended for
another channel.
However, this isn't an issue when not bundling, as each track will be
delivered on separate transport.
And it's also not an issue when each track uses a distinct set of
payload types (e.g., VP8 is mapped to PT 96 in one m= section, and PT 97
in another).
This CL addresses both of those cases; PT demuxing is only disabled
when two bundled m= sections have overlapping payload types.
Bug: chromium:1139052, webrtc:12029
Change-Id: Ied844bffac2a5fac29147c11b56a5f83a95ecb36
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/187560
Commit-Queue: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32419}
This is a reland of
https://webrtc-review.googlesource.com/c/src/+/174261
Patchset 1 contains the old cl (plus a merge conflict fix).
Later patchets are bufixes: A PeerConnection can be created without a
Call instance (in the case of DataChannel only), so we can't always
use that to fetch the current trials.
Old CL descritpion:
This replaces field_trial:: -based functions from system_wrappers.
Field trials are still used as fallback, but injectable trials are now
possible.
// Since re-land is otherwise unchanged, setting previous reviewers as TBR
TBR=kthelgason@webrtc.org,mbonadei@webrtc.org,stefan@webrtc.org,srte@webrtc.org
Bug: webrtc:11926
Change-Id: I57a9e8c3454f226f77fb93215bcac83da65034b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/185003
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32163}
This patch fixes a minor bug in the implementation of
surface_ice_candidates_on_ice_transport_type_changed. The existing
implementation correctly handles the surfacing, but accidentally also
set the SetNeedsIceRestartFlag, which made _next_ offer contain
a ice restart.
Modified existing testcase to verify this.
Bug: webrtc:8939
Change-Id: If566e3249296467668627e5941495f6036cbd903
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176127
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31363}
This CL adds a build flag to allow building the non-test parts
of WebRTC without the audio processing module.
The CL also ensures that the WebRTC code correctly handles
the case when no APM is available.
Bug: webrtc:5298
Change-Id: I5c8b5d1f7115e5cce2af4c2b5ff701fa1c54e49e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/171509
Commit-Queue: Per Åhgren <peah@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31133}
This reverts commit 8e8b36a94a7a7a1fd0f8093979a406afa56e18c1.
Reason for revert: The CL has been improved with the following changes,
- Fixed negotiation of send/receive only clients.
- Handles the implicit assumption that any H264 decoder also can
decode H264 constraint baseline.
Original change's description:
> Distinguish between send and receive codecs
>
> Even though send and receive codecs may be the same, they might have
> different support in HW. Distinguish between send and receive codecs
> to be able to keep track of which codecs have HW support.
>
> Bug: chromium:1029737
> Change-Id: Id119560becadfe0aaf861c892a6485f1c2eb378d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165763
> Commit-Queue: Johannes Kron <kron@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30284}
Change-Id: I834ed48ee78d04922c73e2836165e476925e1cc5
Bug: chromium:1029737
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/168605
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30932}
Currently, datagram transports must report identical transport
parameters in order to negotiate use of the datagram transport. This is
not strictly necessary, they just need parameters that fit some notion
of "compatability" (eg. both ends share some mutually-supported version
of the datagram protocol).
This change allows datagram transports to implement their own notion of
compatible transport parameters, by adding a
SetRemoteTransportParameters method to DatagramTransportInterface which
checks if the remote parameters are compatible with the local endpoint
and returns an error if they are not.
Bug: webrtc:9719
Change-Id: I166c787b468b89d9082d7e3c9995a6ed50a1650a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167741
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30412}
This reverts commit 133bf2bd28596aab5c7684e0ea3da99b1fece77f.
Reason for revert: Breaks Chromium import due to flaky test in Chromium.
Original change's description:
> Reland "Distinguish between send and receive codecs"
>
> This reverts commit e57b266a20334e47f105a0bd777190ec8c6562e8.
>
> Reason for revert: Fixed negotiation of send-only clients.
>
> Original change's description:
> > Revert "Distinguish between send and receive codecs"
> >
> > This reverts commit c0f25cf762a6946666c812f7a3df3f0a7f98b38d.
> >
> > Reason for revert: breaks negotiation with send-only clients
> >
> > (webrtc_video_engine.cc:985): SetRecvParameters called with unsupported video codec: VideoCodec[96:H264]
> > (peer_connection.cc:6043): Failed to set local video description recv parameters. (INVALID_PARAMETER)
> > (peer_connection.cc:2591): Failed to set local offer sdp: Failed to set local video description recv parameters.
> >
> > Original change's description:
> > > Distinguish between send and receive codecs
> > >
> > > Even though send and receive codecs may be the same, they might have
> > > different support in HW. Distinguish between send and receive codecs
> > > to be able to keep track of which codecs have HW support.
> > >
> > > Bug: chromium:1029737
> > > Change-Id: Id119560becadfe0aaf861c892a6485f1c2eb378d
> > > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165763
> > > Commit-Queue: Johannes Kron <kron@webrtc.org>
> > > Reviewed-by: Steve Anton <steveanton@webrtc.org>
> > > Cr-Commit-Position: refs/heads/master@{#30284}
> >
> > TBR=steveanton@webrtc.org,kron@webrtc.org
> >
> > Change-Id: Iacb7059436b2313b52577b65f164ee363c4816aa
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Bug: chromium:1029737
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166420
> > Reviewed-by: Steve Anton <steveanton@webrtc.org>
> > Commit-Queue: Steve Anton <steveanton@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#30292}
>
> TBR=steveanton@webrtc.org,kron@webrtc.org
>
>
> Bug: chromium:1029737
> Change-Id: I287efcfdcd1c9a3f2c410aeec8fe26a84204d1fd
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166604
> Reviewed-by: Johannes Kron <kron@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Johannes Kron <kron@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30348}
TBR=steveanton@webrtc.org,kron@webrtc.org
Change-Id: I9f8731309749e07ce7e651e1550ecfabddb1735f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1029737
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/167205
Reviewed-by: Johannes Kron <kron@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30360}
This reverts commit e57b266a20334e47f105a0bd777190ec8c6562e8.
Reason for revert: Fixed negotiation of send-only clients.
Original change's description:
> Revert "Distinguish between send and receive codecs"
>
> This reverts commit c0f25cf762a6946666c812f7a3df3f0a7f98b38d.
>
> Reason for revert: breaks negotiation with send-only clients
>
> (webrtc_video_engine.cc:985): SetRecvParameters called with unsupported video codec: VideoCodec[96:H264]
> (peer_connection.cc:6043): Failed to set local video description recv parameters. (INVALID_PARAMETER)
> (peer_connection.cc:2591): Failed to set local offer sdp: Failed to set local video description recv parameters.
>
> Original change's description:
> > Distinguish between send and receive codecs
> >
> > Even though send and receive codecs may be the same, they might have
> > different support in HW. Distinguish between send and receive codecs
> > to be able to keep track of which codecs have HW support.
> >
> > Bug: chromium:1029737
> > Change-Id: Id119560becadfe0aaf861c892a6485f1c2eb378d
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/165763
> > Commit-Queue: Johannes Kron <kron@webrtc.org>
> > Reviewed-by: Steve Anton <steveanton@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#30284}
>
> TBR=steveanton@webrtc.org,kron@webrtc.org
>
> Change-Id: Iacb7059436b2313b52577b65f164ee363c4816aa
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1029737
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166420
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30292}
TBR=steveanton@webrtc.org,kron@webrtc.org
Bug: chromium:1029737
Change-Id: I287efcfdcd1c9a3f2c410aeec8fe26a84204d1fd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166604
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30348}
We make sure the fake clock is constructed first thing,
so that all subsequent calls to GetClockForTesting() are
consistent and non-racy.
This proper scoping also allows to remove some explicit
destructions which are no longer necessary.
Bug: webrtc:11282
Change-Id: Id9263617c2e2b025b17d9bcb9cd415d651405a8a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166043
Commit-Queue: Yves Gerey <yvesg@google.com>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30309}
The test previously assumed that doing an offer/answer exchange would
leave the ICE state completed which is unlikely in practice but probably
worked most of the time in test since the network components were faked.
Bug: webrtc:11280
Change-Id: I9bc0e1490b0b8401cc832b73da9dc7fe870bc9fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/166400
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Commit-Queue: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30289}
This CL propagates a "closed" signal from DTLS up to the
SCTP section of the data channel controller, where it causes
closing of all open datachannels.
Bug: chromium:1030631, webrtc:10360
Change-Id: I88bb9e1aff5c25f330edfd092ef609d4fcc3a9f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162206
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30099}
This is in preparation for writing tests that verify that
they close, and that they close at the right times.
Bug: chromium:1030631, webrtc:10360
Change-Id: I8129a9fc9731c1bfe1a660e82e23c1aeff1e5087
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/162181
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30091}
Move the GCM srtp cipher suites below the default SRTP_AES128_CM_SHA1_80 one.
This will not negotiate them by default since they have an impact on packet overhead for audio-only calls.
GCM can still be negotiated if the peer offers it as preferred cipher suite or answers with just that cipher suite.
BUG=chromium:713701
Change-Id: I79bd4ab827e5c7f55f5550d14db3f4217a7eff86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158404
Reviewed-by: Justin Uberti <juberti@google.com>
Reviewed-by: Justin Uberti <juberti@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Justin Uberti <juberti@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29672}
The plugin transport parameters (a=x-opaque: lines) relate to how to create and
set up a plugin transport. When SDP bundle is used, the x-opaque line needs to
be copied into the bundled m= section. This means x-opaque can appear on a
section even if the offerer does not intend to use the transport for the media
described by that section. Consequently, the answerer cannot currently tell
whether the caller is offering an alternate transport for media, data, or both.
This change adds an a=x-alt-protocol: line to SDP. The value following this
line matches the <protocol> part of the x-opaque:<protocol>:<params> line.
However, alt-protocol is not bundled--it only ever applies to the m= section
that contains the line. This allows the offerer to express which m= sections
should actually use an alternate transport, even in the case of bundle.
Note that this is still limited by the available configuration options:
datagram transport can be used for media (audio + video) and/or data. It is
still not possible to use it for audio but not video, or vice versa.
PeerConnection places an alt-protocol line in each media (audio/video) m=
section if it is configured to use a datagram transport for media. It places
an alt-protocol line in each data m= section if it is configured to use a
datagram transport for data channels. PeerConnection leaves alt-protocol in
media (audio/video) m= sections of the answer if it is configured to use a
datagram transport for media, and in data m= sections of the answer if it is
configured to use a datagram transport for data channels.
JsepTransport now negotiates use of the datagram transport independently for
media and data channels. It only uses it for media if the m= sections for
bundled audio/video have an alt-protocol line matching the x-opaque protocol,
and only uses it for data channels if a bundled m= section for data has an
alt-protocol line matching the x-opaque protocol.
Bug: webrtc:9719
Change-Id: I773e4fc10c57d815afcd76a2a74da38dd0c52b3b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154763
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29351}
Adds a field trial and configuration parameter to control whether
datagram transport may be used for data channels in a receive-only
manner. By default, if use_datagram_transport_for_data_channels is
enabled, PeerConnection will create a datagram transport and offer its
use for outgoing calls as well as accept incoming offers with compatible
datagram transport parameters.
With this change, a receive_only mode is added for datagram transport
data channels. When receive_only is set, the PeerConnection will not
create or offer datagram transports for outgoing calls, but will accept
incoming calls that offer compatible datagram transport parameters.
Bug: webrtc:9719
Change-Id: I35667bcc408ea4bbc61155898e6d2472dd262711
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154463
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29327}
This fixes a DCHECK during teardown in the case when the primary
DataChannelTranspot (eg. DatagramTransport) is successfully negotiated.
DatagramTransport expects the DataSink to be unset before it's deleted.
This was not caught by existing tests because the fallback transport
(SctpDataChannelTransport) does not have the same DCHECK.
Also adds a regression test for the issue, in which SCTP is available
as a fallback but DataChannelTransport is negotiated successfully.
Bug: webrtc:9719
Change-Id: I414d964d3c85d3d01cdb5e34d6b248659a613c39
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/154365
Commit-Queue: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29292}
