Existing test would only check the channel was not open instead of
checking for a proper transition to closing then closed.
Bug: webrtc:12614
Change-Id: Iab74d6252ca1411c0fe8c1ee4ca09bc6d81af90c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216388
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33874}
This changes the notification to a single std::function pointer
instead of being a sigslot::signal1<> collection.
Summary:
* Remove SignalFirstPacketReceived_, the last sigslot member variable.
(still inherits from sigslot::has_slots<>)
* BaseChannel doesn't post to the signaling thread anymore. The only
reason that remains for the signaling_thread_ variable, is for
thread checking.
* Remove BaseChannel's reliance on MessageHandlerAutoCleanup
(still inherits from MessageHandler)
RtpTransceiver is the consumer of this event. That class is also the
class that sits between the PC classes and the channel object, holding
a pointer to the channel and managing calls that come in on the
signaling thread, such as SetChannel. The responsibility of delivering
the first packet received on the signaling thread is now with
RtpTransceiver:
* RtpTransceiver always requires a ChannelManager instance. Previously
this variable was sometimes set, but it's now required.
* Updated tests in rtp_transceiver_unittest.cc to include a
ChannelManager as well as fix them to include call expectations for
mock sender and receivers.
Bug: webrtc:11993, webrtc:11988
Change-Id: If49d6be157cd7599fa6fe3a42cd0a363464e3a74
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215979
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33853}
This is essentially replacing `new rtc::RefCountedObject` with
`rtc::make_ref_counted` in many files. In a couple of places I
made minor tweaks to make things compile such as adding parenthesis
when they were missing.
Bug: webrtc:12701
Change-Id: I3828dbf3ee0eb0232f3a47067474484ac2f4aed2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215973
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33852}
There's a bit of copy/pasted code in the channel code, which is
making moving network traffic consistently over to the network thread
a bit trickier than it needs to be, so I'm also updating variable
names used in Set[Local|Remote]Content_w to be more explicitly the same
and make it clear that the code is copy/pasted (and future updates can
consolidate more of it).
Also removing some code from the video/voice media channels that's
effectively dead code (vector + registration methods that aren't needed)
Bug: webrtc:12705
Change-Id: I2e14e69fbc489a64fc1e8899aaf1cfc979fe840b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215978
Reviewed-by: Sam Zackrisson <saza@google.com>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33847}
In this CL, JsepTransportController and MediaSessionDescriptionFactory
are updated not to assume that there only exists at most a single BUNDLE
group but a list of N groups. This makes it possible to create multiple
BUNDLE groups by having multiple "a=group:BUNDLE" lines in the SDP.
This makes it possible to have some m= sections in one group and some
other m= sections in another group. For example, you could group all
audio m= sections in one group and all video m= sections in another
group. This enables "send all audio tracks on one transport and all
video tracks on another transport" in Unified Plan. This is something
that was possible in Plan B because all ssrcs in the same m= section
were implicitly bundled together forming a group of audio m= section and
video m= section (even without use of the BUNDLE tag).
PeerConnection will never create multiple BUNDLE groups by default, but
upon setting SDP with multiple BUNDLE groups the PeerConnection will
accept them if configured to accept BUNDLE. This makes it possible to
accept an SFU's BUNDLE offer without having to SDP munge the answer.
C++ unit tests are added. This fix has also been verified manually on:
https://jsfiddle.net/henbos/to89L6ce/43/
Without fix: 0+2 get bundled, 1+3 don't get bundled.
With fix: 0+2 get bundled in first group, 1+3 get bundled in second
group.
Bug: webrtc:10208
Change-Id: Iaf451fa5459c484730c8018274166ef154b19af8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214487
Reviewed-by: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33838}
* Changing return value from bool to void since the operation as async
effects anyway.
* Removing the `enabled()` accessor due to potential threading issues
and potential TOCTOU issues. It was only used in one place anyway.
* Applying thread restrictions to member variables.
Bug: none
Change-Id: I51949f5594339952d7b717cfd82f99b532e86b23
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216182
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33830}
Adds a signaling unit tests which asserts that a flexfec
offer negotiates flexfec in the answer
BUG=webrtc:8151
Change-Id: Ica6bfe2bdde1a035cdd429d636fefb7f751062d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204680
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33816}
Add new PPIDs 56 and 57. When sending an empty message,
we use the corresponding PPID with a single byte data chunk.
On the receiving side, when detecting such a PPID, we just
ignore the payload content.
Bug: webrtc:12697
Change-Id: I6af481e7281db10d9663e1c0aaf97b3e608432a1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215931
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33808}
On a 32bit system, this reduces the allocation size of the flag
down from 12 bytes to 8, and removes the need for a vtable (the extra
4 bytes are the vtable pointer).
The downside is that this change makes the binary layout of the
flag, less compatible with RefCountedObject<> based reference counting
objects and thus we don't immediately get the benefits of identical
COMDAT folding and subsequently there's a slight binary size increase.
With wider use, the binary size benefits will come.
Bug: none
Change-Id: I04129771790a3258d6accaf0ab1258b7a798a55e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215681
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33793}
This is a refactor to simplify a follow-up CL of adding
SdpVideoFormat::IsSameCodec.
The original files media/base/h264_profile_level_id.* and
media/base/vp9_profile.h must be kept until downstream projects
stop using them.
Bug: chroimium:1187565
Change-Id: Ib39eca095a3d61939a914d9bffaf4b891ddd222f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215236
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33782}
Also add a function for accessing the list as internal transceivers
rather than accessing the proxy objects; this exposes where the
internal objects are accessed and where we need external references.
Used the new list function in sdp_offer_answer wherever possible.
Adds an UnsafeList function that is not thread guarded, so that the
job of rooting out those instances can be done in a later CL.
Bug: webrtc:12692
Change-Id: Ia591f22a1c8f82ec452a1a66a94fbf9ab9debd14
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215581
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33781}
Since there is only a single type of DataChannel now, the enum was only used
when data channels were disabled at the PC API. That option has been
deprecated 4 years ago, it's now time to remove it.
Bug: webrtc:6625
Change-Id: I9e4ada1756da186e9639dd0fbf0249c55ea0b6c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215661
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33778}
* Adds a OnPacketSent callback to MediaChannel, which matches with
MediaChannel::NetworkInterface::SendPacket.
* Moves the OnPacketSent handling to the media channel implementations
(video/voice) and removes the PeerConnection/SdpOfferAnswerHandler
layer from the call path.
* Call::OnSentPacket is called directly from the channels on the network
thread. This eliminates a PostTask to the worker thread for every
audio/video network packet.
* Remove sigslot dependency from MediaChannel (and derived).
Bug: webrtc:11993
Change-Id: I1f79a7aa60f05d47e1882f9be1c9323ea8fac5f6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215403
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33777}
With this change, all production callers of BaseChannel::transport_name()
will be making the call from the right thread and we can safely delegate
the call to the transport itself. Some tests still need to be updated.
This facilitates the main goal of not needing synchronization inside
of the channel classes, being able to apply thread checks and eventually
remove thread hops from the channel classes.
A downside of this particular change is that a blocking call to the
network thread from the signaling thread inside of RTCStatsCollector
needs to be done. This is done once though and fixes a race.
Bug: webrtc:12601, webrtc:11687, webrtc:12644
Change-Id: I85f34f3341a06da9a9efd936b1d36722b10ec487
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213080
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33775}
Classes associated with the Call instance, need access to these threads
and/or awareness, for checking for thread correctness.
Bug: webrtc:11993
Change-Id: I93bcee0657875f211be2ec959b96f818fa9fd8a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215584
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33772}
There's no change in functionality, which was verified by adding
an 'else' catch-all clause in the loop with an RTC_NOTREACHED()
statement. See patchset #3.
This is mostly a cosmetic change that modifies the loop such that
it's guaranteed that Remove() is always called for transceivers
whose state is "stopped" and there's just one place where Remove()
is called.
Bug: none
Change-Id: Iffe237bb2f08e5e6ef316a6b76c4b183df671f3b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215232
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33765}
BaseChannel adds and removes receive streams on the worker thread
(UpdateRemoteStreams_w) and then posts a task to the network thread to
update the demuxer criteria. Until this happens, OnRtpPacket() keeps
forwarding "recently removed" ssrc packets to the WebRtcVideoChannel.
Furthermore WebRtcVideoChannel::OnPacketReceived() posts task from the
network thread to the worker thread, so even if the demuxer criteria was
instantly updated we would still have an issue of in-flight packets for
old ssrcs arriving late on the worker thread inside WebRtcVideoChannel.
The wrong ssrc could also arrive when the demuxer goes from forwarding
all packets to a single m= section to forwarding to different m=
sections. In this case we get packets with an ssrc for a recently
created m= section and the ssrc was never intended for our channel.
This is a problem because when WebRtcVideoChannel sees an unknown ssrc
it treats it as an unsignalled stream, creating and destroying default
streams which can be very expensive and introduce large delays when lots
of packets are queued up.
This CL addresses the issue with callbacks for when a demuxer criteria
update is pending and when it has completed. During this window of time,
WebRtcVideoChannel will drop packets for unknown ssrcs.
This approach fixes the race without introducing any new locks and
packets belonging to ssrcs that were not removed continue to be
forwarded even if a demuxer criteria update is pending. This should make
a=inactive for 50p receive streams a glitch-free experience.
Bug: webrtc:12258, chromium:1069603
Change-Id: I30d85f53d84e7eddf7d21380fb608631863aad21
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214964
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33757}
This denies the ability to request RTP data channels to callers.
Later CLs will rip out the actual code for creating these channels.
Bug: chromium:928706
Change-Id: Ibb54197f192f567984a348f1539c26be120903f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177901
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33740}
When fixing so that RemoteAudioSource does not end the track just
because the audio channel is gone in Unified Plan[1], this made it
possible for ~PeerConnection to delete all objects, including deleting
the MediaStreamTrack and its RemoteAudioSource, when all tracks are not
in an ended state.
In a real application or Chromium, the PeerConnection would not be
destroyed prior to closing and not hit this DCHECK. But in upstream
dependent projects' unit tests, it would be possible for ref counted
tracks to be destroyed when the track are still kLive, and as a
side-effect hit this DCHECK.
sinks_ is just a list of raw pointers, and whether or not we have done
sinks_.clear() prior to destruction is irrelevant going forward.
[1] https://webrtc-review.googlesource.com/c/src/+/214136
Bug: chromium:1121454
Change-Id: If6cf3dffcd3cb47d46694755b5dc45fa381285fc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215226
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33739}
Also removing a count check from DestroyTransceiverChannel that's
not useful right now. We can bring it back when we have
DestroyChannelInterface better under control as far as Invokes goes.
Bug: none
Change-Id: I8e9c55a980f8f20e8b996fdc461fd90b0fbd4f3d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215201
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33730}
This reverts commit a743303211.
Reason for revert: Breaks downstream tests that attempt to call FindHeaderExtensionByUri with 2 arguments. Could you keep the old 2-argument method declaration and just forward the call to the new 3-argument method with a suitable no-op filter?
Original change's description:
> Fix RTP header extension encryption
>
> Previously, RTP header extensions with encryption had been filtered
> if the encryption had been activated (not the other way around) which
> was likely an unintended logic inversion.
>
> In addition, it ensures that encrypted RTP header extensions are only
> negotiated if RTP header extension encryption is turned on. Formerly,
> which extensions had been negotiated depended on the order in which
> they were inserted, regardless of whether or not header encryption was
> actually enabled, leading to no extensions being sent on the wire.
>
> Further changes:
>
> - If RTP header encryption enabled, prefer encrypted extensions over
> non-encrypted extensions
> - Add most extensions to list of extensions supported for encryption
> - Discard encrypted extensions in a session description in case encryption
> is not supported for that extension
>
> Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
> into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
> header extensions will prevent any RTP packets being sent/received.
>
> Bug: webrtc:11713
> Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Taylor <deadbeef@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33723}
TBR=deadbeef@webrtc.org,terelius@webrtc.org,hta@webrtc.org,lennart.grahl@gmail.com
Change-Id: I7df6b0fa611c6496dccdfb09a65ff33ae4a52b26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11713
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215222
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33727}
Previously, RTP header extensions with encryption had been filtered
if the encryption had been activated (not the other way around) which
was likely an unintended logic inversion.
In addition, it ensures that encrypted RTP header extensions are only
negotiated if RTP header extension encryption is turned on. Formerly,
which extensions had been negotiated depended on the order in which
they were inserted, regardless of whether or not header encryption was
actually enabled, leading to no extensions being sent on the wire.
Further changes:
- If RTP header encryption enabled, prefer encrypted extensions over
non-encrypted extensions
- Add most extensions to list of extensions supported for encryption
- Discard encrypted extensions in a session description in case encryption
is not supported for that extension
Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
header extensions will prevent any RTP packets being sent/received.
Bug: webrtc:11713
Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33723}
This also creates a g3doc directory under pc/
Bug: webrtc:12552
Change-Id: I0913c88831658776a0f02174b57b539ac85b4a9f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215077
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33718}
simplifying the code and comparing against the value libsrtp expects
and increase verbosity of error logging related to key length mismatches.
BUG=None
Change-Id: Icc0d0121d2983e23c95b0f972a5f6cac1d158fd7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213146
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/master@{#33685}
This test flakes due to the expectation at
http://shortn/_XxN4cgzMLD.
Bug: webrtc:12590
Change-Id: Id75ecd4f12cd6f9af86aeb2213fd3cb39aecb6d5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214920
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33684}
The SdpOfferAnswerHandler::ssrc_generator_ variable is used from
multiple threads.
Adding thread checks + tests for UniqueNumberGenerator along the way.
Bug: webrtc:12666
Change-Id: Id2973362a27fc1d2c7db60de2ea447d84d18ae3e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214702
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33668}
StatsCollector::ExtractSessionInfo was run fully on the signaling thread
and several calls were being made to methods that need to run on the
network thread.
Additionally, BaseChannel::transport_name() was being read directly
on the signaling thread (needs to be read on the network thread).
So with shifting the work that needs to happen on the network thread
over to that thread, we now also grab the transport name there and
use the name with the work that still needs to happen on the signaling
thread.
These changes allow us to remove Invoke<>() calls to the network thread from
callback functions implemented in PeerConnection:
* GetPooledCandidateStats
* GetTransportNamesByMid
* GetTransportStatsByNames
* Also adding a correctness thread check to:
* GetLocalCertificate
* GetRemoteSSLCertChain
Because PeerConnection now has a way of knowing when things are
or have been uninitialized on the network thread, all of these
functions can exit early without doing throw away work.
Additionally removing thread hops that aren't needed anymore from
JsepTransportController.
Using the RTC_LOG_THREAD_BLOCK_COUNT() macro in GetStats, the number
of Invokes (when >1), goes down by 3. Typically from 8->5, 7->4, 6->3.
Bug: webrtc:11687
Change-Id: I06ab25eab301e192e99076d7891444bcb61b491f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214135
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33656}
This also deletes unused method has_channels() and moves us closer
to having the ChannelManager just be a factory class. Once we get there
the ownership of the channels themselves can be with the classes that
hold pointers to them. Today the initialization and teardown of those
classes need to be synchronized with ChannelManager. But there's no
real value in keeping the channel pointers owned elsewhere.
Places where we have naked un-owned channel pointers:
* RtpTransceiver for voice and video
* PeerConnection::data_channel_controller_ (rtp data channel)
Bug: webrtc:11994
Change-Id: Id6df27414cc57b6ecf0f7f769fdb9603ed114bfd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214440
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33654}
The RTCReceivedRtpStreamStats hierarchy, which inherit from
RTCRtpStreamStats, already contain members ssrc, kind, codec_id and
transport_id so there's no need to list them inside
RTCRemoteInboundrtpStreamStats.
This CL removes duplicates so that we don't DCHECK-crash on Android,
and adds a unit test ensuring we never accidentally list the same
member twice.
Bug: webrtc:12658
Change-Id: I27925eadddc6224bf6d6a91784ed7cafd7a4cfb3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214343
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33649}
This reverts commit 5a40b37105.
Reason for revert: Fixed the bug and ran layout tests.
Original change's description:
> Revert "Use the new DNS resolver API in PeerConnection"
>
> This reverts commit acf8ccb3c9.
>
> Reason for revert: Speculative revert for https://ci.chromium.org/ui/p/chromium/builders/try/win10_chromium_x64_rel_ng/b8851745102358680592/overview.
>
> Original change's description:
> > Use the new DNS resolver API in PeerConnection
> >
> > Bug: webrtc:12598
> > Change-Id: I5a14058e7f28c993ed927749df7357c715ba83fb
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212961
> > Reviewed-by: Niels Moller <nisse@webrtc.org>
> > Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33561}
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> TBR=hta@webrtc.org
>
> Bug: webrtc:12598
> Change-Id: Idc9853cb569849c49052f9cbd865614710fff979
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213188
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33591}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:12598
Change-Id: Ief7867f2f23de66504877cdab1b23a11df2d5de4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214120
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33647}
The RemoteAudioSource has an AudioDataProxy that acts as a sink, passing
along data from AudioRecvStreams to the RemoteAudioSource. If an SSRC is
changed (or other reconfiguration happens) with SDP, the recv stream and
proxy get recreated.
In Plan B, because remote tracks maps 1:1 with SSRCs, it made sense to
end remote track/audio source in response to this. In Plan B, a new
receiver, with a new track and a new proxy would be created for the new
SSRC.
In Unified Plan however, remote tracks correspond to m= sections. The
remote track should only end on port:0 (or RTCP BYE or timeout, etc),
not because the recv stream of an m= section is recreated. The code
already supports changing SSRC and this is working correctly, but
because ~AudioDataProxy() would end the source this would cause the
MediaStreamTrack of the receiver to end (even though the media engine
is still processing the remote audio stream correctly under the hood).
This issue only happened on audio tracks, and because of timing of
PostTasks the track would kEnd in Chromium *after* promise.then().
This CL fixes that issue by not ending the source when the proxy is
destroyed. Destroying a recv stream is a temporary action in Unified
Plan, unless stopped. Tests are added ensuring tracks are kLive.
I have manually verified that this CL fixes the issue and that both
audio and video is flowing through the entire pipeline:
https://jsfiddle.net/henbos/h21xec97/122/
Bug: chromium:1121454
Change-Id: Ic21ac8ea263ccf021b96a14d3e4e3b24eb756c86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214136
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33645}
It's triggering when CreateAnswerWithDifferentSslRoles is run
so marking that test for follow-up in the TODO.
Commenting out the check to make bots go green.
Tbr: hta@webrtc.org
Bug: none
Change-Id: I3fe7b67f12c45aace05e2d7e7c267e10cdf3f8f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214138
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33643}
Follow up https://webrtc-review.googlesource.com/c/src/+/210340, |RTCReceivedRtpStreamStats| is the new parent of |RTCInboundRtpStreamStats| and |RTCRemoteInboundRtpStreamStats| so the verification structure in test should change accrodingly.
Bug: webrtc:12532
Change-Id: I0e7a832de2bb60ec68fb963a8846f6b15fdc30a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214082
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Di Wu <meetwudi@gmail.com>
Cr-Commit-Position: refs/heads/master@{#33642}
The testing code prevents the production code from protecting the
member variables properly. The convenience methods for testing
purposes, can be located with the testing code.
Bug: none
Change-Id: Ieda248a199db84336dfafbd66c93c35508ab2582
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213661
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33635}
Also updating SocketOptionsMergedOnSetTransport test code to make the
call to SetRtpTransport from the right context.
Bug: webrtc:12636
Change-Id: I343851bcf8ac663d7559128d12447a9a742786f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213660
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33633}
This is useful to understand how often we block in certain parts of the
api and track improvements/regressions.
There are two macros, both are only active for RTC_DCHECK_IS_ON builds:
* RTC_LOG_THREAD_BLOCK_COUNT()
Example:
void MyClass::MyFunction() {
RTC_LOG_THREAD_BLOCK_COUNT();
thread_->Invoke<void>([this](){ DoStuff(); });
}
When executing this function during a test, the output could be:
(my_file.cc:2): Blocking MyFunction: total=1 (actual=1, would=0)
The words 'actual' and 'would' reflect whether an actual thread switch
was made, or if in the case of a test using the same thread for more
than one role (e.g. signaling, worker, network are all the same thread)
that an actual thread switch did not occur but it would have occurred
in the case of having dedicated threads. The 'total' count is the sum.
* RTC_DCHECK_BLOCK_COUNT_NO_MORE_THAN(x)
Example:
void MyClass::MyFunction() {
RTC_LOG_THREAD_BLOCK_COUNT();
thread_->Invoke<void>([this](){ DoStuff(); });
thread_->Invoke<void>([this](){ MoreStuff(); });
RTC_DCHECK_BLOCK_COUNT_NO_MORE_THAN(1);
}
When a function is known to have blocking calls and we want to not
regress from the currently known number of blocking calls, we can use
this macro to state that at a certain point in a function, below
where RTC_LOG_THREAD_BLOCK_COUNT() is called, there must have occurred
no more than |x| (total) blocking calls. If more occur, a DCHECK will
hit and print out what the actual number of calls was:
# Fatal error in: my_file.cc, line 5
# last system error: 60
# Check failed: blocked_call_count_printer.GetTotalBlockedCallCount() <= 1 (2 vs. 1)
Bug: webrtc:12649
Change-Id: Ibac4f85f00b89680601dba54a651eac95a0f45d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213782
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33632}
provides an implementation of the rtx-time parameter from
https://tools.ietf.org/html/rfc4588#section-8
that determines the maximum time a receiver waits for a frame
before sending a PLI.
BUG=webrtc:12420
Change-Id: Iff20d92c806989cd4d56fe330d105b3dd127ed24
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/201400
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33627}
