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}
This reverts commit f22af3cca7cfe517e4126db4b7083475722c3e6d.
Reason for revert: Downstream tests have been updated.
Original change's description:
> Revert "Distinguish between send and receive video codecs"
>
> This reverts commit 18314bd8d2cb27fa58e4d304bbc428e3ed1736ba.
>
> Reason for revert: Breaks downstream test.
>
> Original change's description:
> > Distinguish between send and receive video codecs
> >
> > Even though send and receive codecs are 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: I16a80da44c5061ca42f2aabda76e6bf0b879bf7b
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161306
> > Reviewed-by: Anders Carlsson <andersc@webrtc.org>
> > Reviewed-by: Steve Anton <steveanton@webrtc.org>
> > Commit-Queue: Johannes Kron <kron@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#30041}
>
> TBR=steveanton@webrtc.org,andersc@webrtc.org,kron@webrtc.org
>
> Change-Id: I7e5807460006db613e9b3b369ec6036b88f164fd
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1029737
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161662
> Reviewed-by: Johannes Kron <kron@webrtc.org>
> Commit-Queue: Johannes Kron <kron@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30042}
TBR=steveanton@webrtc.org,andersc@webrtc.org,kron@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1029737
Change-Id: Ia70b11376b43888e2495ef21838c2d2e3c68d735
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161734
Reviewed-by: Johannes Kron <kron@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Anders Carlsson <andersc@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30078}
from LS_INFO to LS_VERBOSE.
By default, unit tests run with logging at info level.
A random run today produced more than 70.000 lines of
output. This CL would reduce that by approximately 15.000.
Bug: none
Change-Id: Ie62708cebf109510a2443aa5ab5c4e645ffc6707
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161950
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30077}
This reverts commit 18314bd8d2cb27fa58e4d304bbc428e3ed1736ba.
Reason for revert: Breaks downstream test.
Original change's description:
> Distinguish between send and receive video codecs
>
> Even though send and receive codecs are 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: I16a80da44c5061ca42f2aabda76e6bf0b879bf7b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161306
> Reviewed-by: Anders Carlsson <andersc@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Johannes Kron <kron@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#30041}
TBR=steveanton@webrtc.org,andersc@webrtc.org,kron@webrtc.org
Change-Id: I7e5807460006db613e9b3b369ec6036b88f164fd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1029737
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161662
Reviewed-by: Johannes Kron <kron@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30042}
Even though send and receive codecs are 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: I16a80da44c5061ca42f2aabda76e6bf0b879bf7b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161306
Reviewed-by: Anders Carlsson <andersc@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30041}
This is the start of generating compliant errors, including diagnostics,
when datachannels close because of errors.
Bug: chromium:1030631
Change-Id: I39aa41728efb25bca6193a782db4cbdaad8e0dc1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161304
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30034}
Cause: VideoRtpReceiver::media_channel_ was used when it was null.
Fix: only use when provably not null.
Bug: chromium:1031013
Change-Id: I765e183186d895f39c122e26d50ac787216c44f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161328
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30017}
This change finally wires up VideoRtpReceiver::OnGenerateKeyFrame and
OnEncodedSinkEnabled into internal::VideoReceiveStream so that encoded
frames can flow to sinks installed in VideoTrackSourceInterface.
Bug: chromium:1013590
Change-Id: I76f8226752294aee8fe137d1a78ee66548900cc2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161095
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#30003}
I could find no reason for the extra complexity of doing messaging
in order to schedule a task to be done after the current cycle.
It also simplifies the peerconnection/datachannelcontroller coupling.
Bug: webrtc:11146
Change-Id: I68f45059b9f4a6869fb44b856e05a480f4652365
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161232
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29997}
This CL:
- Moved HasDataChannel and data_channel_type_
- Moved rtp_data_channels_
- Moved sctp_data_channels_
- Moved data_channel_controller to its own .h file
- Various changes to reduce the coupling between the classes
- Removed friendship between DataChannelController and PeerConnection
Bug: webrtc:11146
Change-Id: Ib8c395e4c90ce34baf40812d1dade0ffa79f2438
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161094
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29987}
to generate less versions of the function template and FunctorMessageHandler helper
thus producing less binary size
Bug: None
Change-Id: Idbd6fb1e1f23b9b2dc4e4306a74ef11e74ba94cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/161044
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29962}
Many WebRTC users need only Opus, and no other audio codecs. This
makes it convenient for them to do the right thing.
To prove that the new factories work, use them in
PeerConnectionEndToEndTest.
Bug: webrtc:11130
Change-Id: I2c2450ba0fb33ef3b50da8f6cd325cad6b1e59a6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/160648
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29921}
This change implements the methods in VideoTrackSourceInterface
that are related to encoded output.
Bug: chromium:1013590
Change-Id: Id9ddbc00a7098e9b44cee1517c69002865a5fb33
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/159926
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29912}
This change factors out VideoRtpTrackSource in preparation
of building the class out.
Bug: chromium:1013590
Change-Id: I015e285b9fcc10b39428dea9f74e0e8648385f62
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/159925
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29870}
This will be immediately useful to guarantee consistent state across
components referencing the pacer, but will be a net benefit overall
imo.
Bug: webrtc:10809
Change-Id: I49630696f757a832ccf2e4c8597193bf087ce53b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/159885
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29859}
This is the same as the existing version, except it uses the Operations
Chain. As such, if an asynchronous operation that uses the chain is
currently pending, such as CreateOffer() or CreateAnswer(),
AddIceCandidate() will not happen until the previous operation
completes.
Bug: chromium:1019222
Change-Id: Ie6e5fc386fa9c29b5e2f8e3f65bfbaf9837d351c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158741
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29704}
Injecting both a custom NetEqFactory and an AudioDecoderFactory is not
supported, in that case the AudioDecoderFactory should be wrapped inside
the NetEqFactory.
Bug: webrtc:11005
Change-Id: I4e311eb1bfa03c91bca587d70540e81829f881c9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158720
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29673}
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}
This is a reland of 1dddaa1a84330091ca083c950ef2e24a85a48fc8
The regression that caused the original CL to be reverted was the fact that
invoking SetLocalDescription() inside of the CreateOffer() callback was no
longer executing synchronously and immediately.
In this CL, the original CL is patched so that the CreateOffer() operation
is marked as completed just before invoking the CreateOffer() callback
(versus doing it just afterwards). This ensures that the OperationsChain is
popped before the callback runs. The same applies for CreateAnswer().
See diff between Patch Set 1 (Original CL) and the latest Patch Set.
Original change's description:
> [PeerConnection] Use an OperationsChain in PeerConnection for async ops.
>
> For background, motivation, requirements and implementation notes, see
> https://docs.google.com/document/d/1XLwNN2kUIGGTwz9LQ0NwJNkcybi9oKnynUEZB1jGA14/edit?usp=sharing
>
> Using the OperationsChain will unblock future CLs from chaining multiple
> operations together such as implementing parameterless
> setLocalDescription().
>
> In this CL, the OperationsChain is used in existing signaling operations
> with little intended side-effects. An operation that is chained onto an
> empty OperationsChain will for instance execute immediately, and
> SetLocalDescription() and SetRemoteDescription() are implemented as
> "synchronous operations".
>
> The lifetime of the PeerConnection is not indended to change as a result
> of this CL: All chained operations use a WeakPtr to the PC to ensure
> use-after-free does not happen.
>
> There is one notable change though: CreateOffer() and CreateAnswer() will
> asynchronously delay other signaling methods from executing until they
> have completed.
>
> Drive-by fix: This CL also ensures that early failing
> CreateOffer/CreateAnswer operation's observers are invoked if the
> PeerConnection is destroyed while a PostCreateSessionDescriptionFailure
> is pending.
>
> Bug: webrtc:11019
> Change-Id: I521333e41d20d9bbfb1e721609f2c9db2a5f93a9
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157305
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29605}
TBR=steveanton@webrtc.org
Bug: webrtc:11019
Change-Id: I57b4496e63378c91c24679ee496e21f5cb6a0e59
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158524
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29630}
This reverts commit 1dddaa1a84330091ca083c950ef2e24a85a48fc8.
Reason for revert: Breaks downstream projects :(
Original change's description:
> [PeerConnection] Use an OperationsChain in PeerConnection for async ops.
>
> For background, motivation, requirements and implementation notes, see
> https://docs.google.com/document/d/1XLwNN2kUIGGTwz9LQ0NwJNkcybi9oKnynUEZB1jGA14/edit?usp=sharing
>
> Using the OperationsChain will unblock future CLs from chaining multiple
> operations together such as implementing parameterless
> setLocalDescription().
>
> In this CL, the OperationsChain is used in existing signaling operations
> with little intended side-effects. An operation that is chained onto an
> empty OperationsChain will for instance execute immediately, and
> SetLocalDescription() and SetRemoteDescription() are implemented as
> "synchronous operations".
>
> The lifetime of the PeerConnection is not indended to change as a result
> of this CL: All chained operations use a raw pointer to the PC that is
> ensured not to be used-after-free using an "IsAlive" object.
>
> There is one notable change though: CreateOffer() and CreateAnswer() will
> asynchronously delay other signaling methods from executing until they
> have completed.
>
> Drive-by fix: This CL also ensures that early failing
> CreateOffer/CreateAnswer operation's observers are invoked if the
> PeerConnection is destroyed while a PostCreateSessionDescriptionFailure
> is pending.
>
> Bug: webrtc:11019
> Change-Id: I521333e41d20d9bbfb1e721609f2c9db2a5f93a9
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157305
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#29605}
TBR=steveanton@webrtc.org,hbos@webrtc.org
Change-Id: Ie540dcc8ecdc48ad0c65d23645fbc3ad5f99592b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11019
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/158405
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29611}
For background, motivation, requirements and implementation notes, see
https://docs.google.com/document/d/1XLwNN2kUIGGTwz9LQ0NwJNkcybi9oKnynUEZB1jGA14/edit?usp=sharing
Using the OperationsChain will unblock future CLs from chaining multiple
operations together such as implementing parameterless
setLocalDescription().
In this CL, the OperationsChain is used in existing signaling operations
with little intended side-effects. An operation that is chained onto an
empty OperationsChain will for instance execute immediately, and
SetLocalDescription() and SetRemoteDescription() are implemented as
"synchronous operations".
The lifetime of the PeerConnection is not indended to change as a result
of this CL: All chained operations use a raw pointer to the PC that is
ensured not to be used-after-free using an "IsAlive" object.
There is one notable change though: CreateOffer() and CreateAnswer() will
asynchronously delay other signaling methods from executing until they
have completed.
Drive-by fix: This CL also ensures that early failing
CreateOffer/CreateAnswer operation's observers are invoked if the
PeerConnection is destroyed while a PostCreateSessionDescriptionFailure
is pending.
Bug: webrtc:11019
Change-Id: I521333e41d20d9bbfb1e721609f2c9db2a5f93a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/157305
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#29605}
