It is possible to get event logs from both RTP and MediaTransport when
media transport is only used for data channel. This is undesirable. We
would rather not get any logs from media transport when it's not used
for media.
This change disables rtc event log when media transport is not used for
media.
Bug: webrtc:9719
Change-Id: Ibc660b37c5d98001144e5f68b32f0608fd6ede33
Reviewed-on: https://webrtc-review.googlesource.com/c/123260
Commit-Queue: Peter Slatala <psla@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26776}
Most of the implementation in rtp_sender.cc is a copy paste for both
Audio & Video RTP senders. This change moves all the common behavior
into the base RtpSenderInternal class.
Template method pattern is used to accomodate for the very slight differences
between audio and video senders.
Bug: None
Change-Id: I6d4e93cd32fbb0fb361fd0e1883791019bde9a92
Reviewed-on: https://webrtc-review.googlesource.com/c/123411
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26758}
Added a layer in RtpSender that bridges the gap between the layers
that the user sees and the layer that the media engine sees.
Media engine still maintains the invariant that the number of layers
cannot be changed, while RtpSender adds and removes layers between
the user GetParameters and SetParameters calls and the media engine.
Bug: webrtc:10251
Change-Id: I33839c1f9a9052cb6130253e5a582606f2cbe54a
Reviewed-on: https://webrtc-review.googlesource.com/c/122641
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26756}
Plus all the annotations that are necessary to make things compile
again.
Bug: webrtc:9987
Change-Id: If7bbd5a468a8c50ac3cfe03cd2ed4f5b5f461195
Reviewed-on: https://webrtc-review.googlesource.com/c/123047
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26727}
This reverts commit 05d43c6f7fe497fed0f2c8714e2042dd07a86df2.
Reason for revert: It breaks some Chromium trybots:
https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_asan_rel_ng/206387https://ci.chromium.org/p/chromium/builders/luci.chromium.try/linux_chromium_tsan_rel_ng/207737https://ci.chromium.org/p/chromium/builders/luci.chromium.try/win10_chromium_x64_rel_ng/202283
Original change's description:
> Fix getStats() freeze bug affecting Chromium but not WebRTC standalone.
>
> PeerConnection::Close() is, per-spec, a blocking operation.
> Unfortunately, PeerConnection is implemented to own resources used by
> the network thread, and Close() - on the signaling thread - destroys
> these resources. As such, tasks run in parallel like getStats() get into
> race conditions with Close() unless synchronized. The mechanism in-place
> is RTCStatsCollector::WaitForPendingRequest(), it waits until the
> network thread is done with the in-parallel stats request.
>
> Prior to this CL, this was implemented by performing
> rtc::Thread::ProcessMessages() in a loop until the network thread had
> posted a task on the signaling thread to say that it was done which
> would then get processed by ProcessMessages(). In WebRTC this works, and
> the test is RTCStatsIntegrationTest.GetsStatsWhileClosingPeerConnection.
>
> But because Chromium's thread wrapper does no support
> ProcessMessages(), calling getStats() followed by close() in Chrome
> resulted in waiting forever (https://crbug.com/850907).
>
> In this CL, the process messages loop is removed. Instead, the shared
> resources are guarded by an rtc::Event. WaitForPendingRequest() still
> blocks the signaling thread, but only while shared resources are in use
> by the network thread. After this CL, calling WaitForPendingRequest() no
> longer has any unexpected side-effects since it no longer processes
> other messages that might have been posted on the thread.
>
> The resource ownership and threading model of WebRTC deserves to be
> revisited, but this fixes a common Chromium crash without redesigning
> PeerConnection, in a way that does not cause more blocking than what
> the other PeerConnection methods are already doing.
>
> Note: An alternative to using rtc::Event is to use resource locks and
> to not perform the stats collection on the network thread if the
> request was cancelled before the start of processing, but this has very
> little benefit in terms of performance: once the network thread starts
> collecting the stats, it would use the lock until collection is
> completed, blocking the signaling thread trying to acquire that lock
> anyway. This defeats the purpose and is a riskier change, since
> cancelling partial collection in this inherently racy edge-case would
> have observable differences from the returned stats, which may cause
> more regressions.
>
> Bug: chromium:850907
> Change-Id: Idceeee0bddc0c9d5518b58a2b263abb2bbf47cff
> Reviewed-on: https://webrtc-review.googlesource.com/c/121567
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#26707}
TBR=steveanton@webrtc.org,hbos@webrtc.org
Change-Id: Icd82cdd5bd086a90999f7fd5f8616e1f2d2153bf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:850907
Reviewed-on: https://webrtc-review.googlesource.com/c/123225
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26721}
Plus all the annotations that are necessary to make things compile
again.
Bug: webrtc:9987
Change-Id: I68a51bfa3342c6d66d67276d5979144af34692c9
Reviewed-on: https://webrtc-review.googlesource.com/c/123046
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26716}
Plus all the annotations that are necessary to make things compile
again.
(The latter could only be made const, since it is accessed from both
the signal thread and the worker thread.)
Bug: webrtc:9987
Change-Id: I49f1568d26a327f48cd94c2c70bc5939e9fbd59a
Reviewed-on: https://webrtc-review.googlesource.com/c/122842
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26715}
PeerConnection::Close() is, per-spec, a blocking operation.
Unfortunately, PeerConnection is implemented to own resources used by
the network thread, and Close() - on the signaling thread - destroys
these resources. As such, tasks run in parallel like getStats() get into
race conditions with Close() unless synchronized. The mechanism in-place
is RTCStatsCollector::WaitForPendingRequest(), it waits until the
network thread is done with the in-parallel stats request.
Prior to this CL, this was implemented by performing
rtc::Thread::ProcessMessages() in a loop until the network thread had
posted a task on the signaling thread to say that it was done which
would then get processed by ProcessMessages(). In WebRTC this works, and
the test is RTCStatsIntegrationTest.GetsStatsWhileClosingPeerConnection.
But because Chromium's thread wrapper does no support
ProcessMessages(), calling getStats() followed by close() in Chrome
resulted in waiting forever (https://crbug.com/850907).
In this CL, the process messages loop is removed. Instead, the shared
resources are guarded by an rtc::Event. WaitForPendingRequest() still
blocks the signaling thread, but only while shared resources are in use
by the network thread. After this CL, calling WaitForPendingRequest() no
longer has any unexpected side-effects since it no longer processes
other messages that might have been posted on the thread.
The resource ownership and threading model of WebRTC deserves to be
revisited, but this fixes a common Chromium crash without redesigning
PeerConnection, in a way that does not cause more blocking than what
the other PeerConnection methods are already doing.
Note: An alternative to using rtc::Event is to use resource locks and
to not perform the stats collection on the network thread if the
request was cancelled before the start of processing, but this has very
little benefit in terms of performance: once the network thread starts
collecting the stats, it would use the lock until collection is
completed, blocking the signaling thread trying to acquire that lock
anyway. This defeats the purpose and is a riskier change, since
cancelling partial collection in this inherently racy edge-case would
have observable differences from the returned stats, which may cause
more regressions.
Bug: chromium:850907
Change-Id: Idceeee0bddc0c9d5518b58a2b263abb2bbf47cff
Reviewed-on: https://webrtc-review.googlesource.com/c/121567
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26707}
Plus all the annotations that are necessary to make things compile
again.
Bug: webrtc:9987
Change-Id: I53caa3c6644c5d0fcb50f7c1e89e853eddd769a5
Reviewed-on: https://webrtc-review.googlesource.com/c/122882
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26705}
This is a reland of ce470aab518f067a67aa03aaab1fc61a45afa0ec
Original change's description:
> Enabling Simulcast use via AddTransceiver.
>
> This change removes the restriction on multiple send encodings when
> calling AddTransceiver. If RIDs are not provided in the
> simulcast scenario, they are auto-generated by the platform.
>
> This effectively enables the use of spec-compliant simulcast.
> Tests are also added to verify simulcast functionality.
>
> Bug: webrtc:10075
> Change-Id: I088feba70a26e85abcc7bfbe3ea1fe5103cd47d2
> Reviewed-on: https://webrtc-review.googlesource.com/c/121389
> Reviewed-by: Florent Castelli <orphis@webrtc.org>
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#26590}
Bug: webrtc:10075
Change-Id: Ib4392e36d5d60b966ecff56d4df69bf60d13a73d
Reviewed-on: https://webrtc-review.googlesource.com/c/122962
Reviewed-by: Amit Hilbuch <amithi@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26694}
Hard-coding default values forces IDs over 14 to be used even
when we offer less than 15 different extensions.
Note that the code relies on MergeRtpHdrExts for making sure
that extension IDs are kept consistent and non-colliding between
different streams (audio/video).
Bug: webrtc:10288
Change-Id: I3e59f7ddc8ca43cea91084a6b7f36df70fb6be4a
Reviewed-on: https://webrtc-review.googlesource.com/c/121646
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26622}
This change removes the restriction on multiple send encodings when
calling AddTransceiver. If RIDs are not provided in the
simulcast scenario, they are auto-generated by the platform.
This effectively enables the use of spec-compliant simulcast.
Tests are also added to verify simulcast functionality.
Bug: webrtc:10075
Change-Id: I088feba70a26e85abcc7bfbe3ea1fe5103cd47d2
Reviewed-on: https://webrtc-review.googlesource.com/c/121389
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26590}
Adds methods AddNetworkChangeCallback and RemoveNetworkChangeCallback,
to replace SetNetworkChangeCallback. Needed because both VideoChannel and
VoiceChannel register such a callback.
Bug: webrtc:9719
Change-Id: Ic592b2d775d721a0f44ba0af88ed963bf02d73a3
Reviewed-on: https://webrtc-review.googlesource.com/c/121460
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Peter Slatala <psla@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26575}
The usage of "nogncheck" is disallowed in WebRTC (the only exception is
for the "#includes" that are part of conditional compilation with the
preprocessor).
This CL removes some "nogncheck" from the pc/ folder. The included
headers were unused so this should be a no-op change.
Bug: webrtc:8733
Change-Id: I22f5238bbc08aa500d4f0850e30acfbaed9742ae
Reviewed-on: https://webrtc-review.googlesource.com/c/120929
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26528}
Googletest recently started replacing the term Test Case by Test Suite.
From now on, the preferred API is TestSuite*; the older TestCase* API
will be slowly deprecated.
This CL moves WebRTC to the new set of APIs.
More info in [1].
This CL has been generated with this script:
declare -A items
items[TYPED_TEST_CASE]=TYPED_TEST_SUITE
items[TYPED_TEST_CASE_P]=TYPED_TEST_SUITE_P
items[REGISTER_TYPED_TEST_CASE_P]=REGISTER_TYPED_TEST_SUITE_P
items[INSTANTIATE_TYPED_TEST_CASE_P]=INSTANTIATE_TYPED_TEST_SUITE_P
items[INSTANTIATE_TEST_CASE_P]=INSTANTIATE_TEST_SUITE_P
for i in "${!items[@]}"
do
git ls-files | xargs sed -i "s/\b$i\b/${items[$i]}/g"
done
git cl format
[1] - https://github.com/google/googletest/blob/master/googletest/docs/primer.md#beware-of-the-nomenclature
Bug: None
Change-Id: I5ae191e3046caf347aeee01554d5743548ab0e3f
Reviewed-on: https://webrtc-review.googlesource.com/c/118701
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26494}
Currently, the RtpTransport checks that the packet is either RTP or
RTCP. However, the RTCP check does not verify that the packet is a valid RTP,
and therefore invalid RTCP packets were allowed in the RtpTransport::OnReadPacket.
This change makes sure that the test for RTCP header (IsRtcpPacket) checks that it has the valid RTP version (2).
So far if the packet had the second byte that looked like
RTCP, it would ignore the first byte.
Bug: None
Change-Id: I5d07d497b9ef609c74b6e507c5f3e19e4bf10194
Reviewed-on: https://webrtc-review.googlesource.com/c/120646
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26480}
Enables downstream projects to use the existing fake ice transport implementation, without taking dependency on gunit
Bug: None
Change-Id: I78bac9d40aa6e12b55e86f0460bcd98d85c7f214
Reviewed-on: https://webrtc-review.googlesource.com/c/120445
Commit-Queue: Peter Slatala <psla@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26456}
Support varies by codec, especially in the simulcast case, but using
the EncoderSimulcastProxy codec should fix this.
Bug: webrtc:10069
Change-Id: Idb6a5f400ffda1cdb139004f540961a9cf85d224
Reviewed-on: https://webrtc-review.googlesource.com/c/119400
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26449}
In the January 22nd 2019 WebRTC meeting it was agreed that an offer
for sending (or receiving) simulcast should only contain the RIDs
of the layers that are sent by the client.
This change removes the complexity that was added to support sending
and receiving the single layer (and RID) that are sent from the server.
Bug: webrtc:10076
Change-Id: I8bae1336d5cb8ba2f91c5b62332dc69e67ddfd47
Reviewed-on: https://webrtc-review.googlesource.com/c/120242
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26432}
CreateOffer and CreateAnswer will now examine the layers on the
transceiver to determine if multiple layers are requested (Simulcast).
In this scenario RIDs will be used in the layers (instead of SSRCs).
When the offer is created, only RIDs are signalled in the offer.
When the offer is set locally SetLocalDescription() SSRCs will be
generated for each layer by the Channel and sent downstream to the
MediaChannel.
The MediaChannel receives configuration that looks identical to that of
legacy simulcast, and should be able to integrate the streams correctly
regardless of how they were signalled.
Setting multiple layers on the transciever is still not supported
through the API.
Bug: webrtc:10075
Change-Id: Id4ad3637b87b68ef6ca7eec69166fee2d9dfa36f
Reviewed-on: https://webrtc-review.googlesource.com/c/119780
Reviewed-by: Seth Hampson <shampson@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26428}
Currently it's possible that no-op DTLS is created if media transport is only used for data channels.
Changing it so that no-op DTLS is only created when both media & data will flow through media transport.
Bug: webrtc:9719
Change-Id: I87f27fc778ea21b12f2904bad1452d893f66b541
Reviewed-on: https://webrtc-review.googlesource.com/c/119909
Commit-Queue: Peter Slatala <psla@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Anton Sukhanov <sukhanov@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26416}
It is possible that media transport is re-set by the caller, but once
disabled it should stay disabled.
it's possible to fail this check the check in JsepTransportController::SetMediaTransportFactory in such case.
We should also change the caller to not invoke SetMediaTransportFactory
multiple times (with the same value), but I'll leave it as an excercise
to someone else :)
Bug: webrtc:9719
Change-Id: Ideea8a50d863edf4ef59e594a78c74bb9aba5aa7
Reviewed-on: https://webrtc-review.googlesource.com/c/119911
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Bjorn Mellem <mellem@webrtc.org>
Commit-Queue: Peter Slatala <psla@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26411}
This is intended to be used in Blink to implement proper support
for the JavaScript RTCIceCandidate API.
Bug: chromium:683094
Change-Id: I93d117ef1bd9541593f2715bdf3291dc2941737f
Reviewed-on: https://webrtc-review.googlesource.com/c/119940
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26404}
UniqueIdGenerator classes are useful outside the pc directory.
This change moves them to the rtc_base directory to enable code
in all directories to reference them.
Bug: None
Change-Id: I1c77da87ea26d9611f37dc1d4d2c16006a6589c6
Reviewed-on: https://webrtc-review.googlesource.com/c/119460
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Commit-Queue: Amit Hilbuch <amithi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26378}
