This breaks the link from sdp_offer_answer.cc to channel.h.
Bug: webrtc:13931
Change-Id: I75608f75713bf4e69013ac5f5b17c19e53d07519
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261060
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36757}
This also hides the existence of the classes VideoChannel and
VoiceChannel from anything that does not include "channel.h".
Bug: webrtc:13931
Change-Id: I080a692b6acfd5d2d0401ec20d59c3a684eddb05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260944
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36746}
Also eliminate FillBitrateInfo from the Channel object.
Bug: webrtc:13931
Change-Id: I5265b7629413a1ed04898272adf26708e2ee9b8d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260469
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36744}
Also apply IWYU to all .cc files in pc/, and correct BUILD file to match.
Note: Some files came out wrong when iwyu was applied. These are not included.
Bug: none
Change-Id: Ib5ea46b8fcc505414d0447cca7218ad3afc2e321
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/252280
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36064}
The interface is implemented by the ChannelManager and contains methods
to create and destroy media channel objects as used by a transceiver.
This will subsequently allow us to delete the channel objects from
the transceiver class where ownership really lies rather than from
the outside - which is currently required by some tests that keep
channel objects on the stack. We'll furthermore be able to do the
destruction asynchronously without additional Invoke()s as we do now
which will remove an Invoke when making sdp changes.
With introducing the interface, the following simplifications were made:
* ChannelManager constructed on the signaling thread.
Before, there was an Invoke in the context class, which existed
for the purposes of calling MediaEngine::Init() (which in turn is
only needed for the VoiceEngine). This Invoke has now been moved
into the CM (more tbd).
* The CM now has a pointer to the signaling thread (since that's the
construction thread). That allows us to remove the signaling thread
parameter from the CreateFooChannel methods.
* The ssrc_generator (UniqueRandomIdGenerator) instance for SSRCs moved
from SdpOfferAnswerHandler to the CM, as it's always used in
combination with the CM. This simplifies the CreateFooChannel methods
as well as a couple of other classes that have a CM dependency.
* Removed DestroyFooChannel related code from SdpOfferAnswerHandler since
the channel type detail can be taken care of by the CM.
Bug: webrtc:11992, webrtc:13540
Change-Id: I04938a803734de8489ba31e6212d9eaecc244126
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/247904
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35766}
...and one when destroying a channel object.
This CL removes Init_n() and Deinit_n() from the BaseChannel class.
Channel classes now use SetRtpTransport to do initialization and
uninitialization on the network thread.
Notably if an implementation has called SetRtpTransport() with a valid
transport pointer, it is required that SetRtpTransport be called again
with a nullptr before the channel object can be deleted.
In situations where multiple channels are created, this can mean
a substantial reduction in thread hops. We still hop to the worker
in order to construct the objects - this can probably be avoided
and SetChannel() is still a synchronous operation for the transceivers.
Furthermore, teardown of channel objects also still happens
synchronously and across network/worker/signaling threads.
Bug: webrtc:11992
Change-Id: I68ca7596e181fc82996e3e290733d97381aa5e78
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246740
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35738}
Remove Init_w and Deinit(), both of which were wrappers around Invoke()
calls from the worker thread to the network thread.
Instead, replace them with Init_n() and Deinit_n() that are currently*
required to be called by external code in order to associate/disassociate
the channels with the transport.
This CL mostly moves things around in order to prepare for upcoming
changes, but it does change channel destruction in the following way:
- When destroying channels, we don't block the worker thread anymore
while uninitialization happens on the network thread. Previously
both signal and worker threads were blocked during the
uninitialization in the ChannelManager.
* In an upcoming CL, Init_n() and Deinit_n() will be called internally
from a different method that's always called on the network thread
when a channel is associated/disassociated with a transceiver. When
we're there, we will have removed several invokes that currently are
a part of constructing/destructing channel objects.
Bug: webrtc:11992
Change-Id: Ibc30447a40749ceb36d37834b0cfc5c5ea60e895
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246502
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35707}
This is a simple check for upcoming changes for media channels to
be able to check if the state on the network thread is consistent.
Bug: webrtc:11992
Change-Id: I8ed2d091ecf3869a66970fc4733aebf209c4ef82
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246681
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35706}
With these changes, we now often have 0 invokes and at most 1 when
calling SetLocalContent on a channel. Before we had at least 1 and
typically 2.
Summary of changes.
* Updating RtpExtension::DeduplicateHeaderExtensions to return a sorted
vector (+test) for easy detection of changes.
* Before updating the transport on the network thread, detect if
actual changes to the demuxer criteria or changes to the rtp header
extensions have been made.
* Consolidate both transport updates to a single call instead of two.
* Added DCHECK guards to catch regressions in number of invokes.
A possible upcoming improvement is to update the transport
asynchronously.
Bug: webrtc:13536
Change-Id: I71ef7b181635a796ffa1e3a02a0f661d28a4870c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244700
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35638}
This is a bit of refactoring to clear the way for some more upcoming
changes and fix little oddities here and there that are basically
artifacts of many small incremental changes throughout the years.
* Remove the CryptoOptions member variable and instead only keep around
the filter for rtp header extensions.
* Remove several member methods that only forwarded calls to
media_channel() and effectively reduced readability.
* Consolidated quite a bit of code related to UpdateRemoteStreams_w
and the copy/pasted code in the Video/Voice classes around calling it.
* UpdateRemoteStreams_w now returns an error when it's encountered.
Before, an error would still be returned in those cases but all
operations were unnecessarily performed.
Bug: none
Change-Id: I85a37b9e8f00584aa794abef11abfe89dec5d0a6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244098
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35637}
This is a slight refactoring while doing some other changes, so not
strictly necessary, but the error param is always supplied in practice
so it made sense to update the tests to reflect that, test that error
values are reported in (at least) some cases and remove the additional
code that checks for whether or not error information is requested.
Bug: none
Change-Id: Ia5739a18ea2beb6970eabf9d809c24dfa43466b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244097
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35632}
Improve consistency between using DCHECK checkers and compile time.
For virtual methods, we were sometimes using both and in other cases
we could be using compile time checks but were using runtime.
Added annotation for last_send_params_, last_recv_params_ in
audio/video channel classes.
Also removing redundant logging for when registration with the
transport fails. This is already being logged in the demuxer.
Bug: webrtc:12230
Change-Id: I48e156c9996dec26a990151301dabc06673541d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244095
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35630}
Remove unnecessary optimization from BaseChannel,
previous_demuxer_criteria_, that I'm not seeing as providing value.
Previously it was used to avoid a thread hop if a reconfiguration
wasn't needed, but the way that was done, wasn't thread safe. So after
addressing that issue, the variable more represents increased complexity
in the code than runtime efficiency.
Bug: webrtc:11993, webrtc:12230
Change-Id: Ic8e3e1d2f57e669a168cc7b5cf5d407133976e3c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244093
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35628}
BaseChannel::content_name() is consistently used as the mid throughout
the code and the mid is stored in the demuxer criteria. Furthermore
there's a chance that the two variables might not be in sync if the
mid needs to be truncated, so it's better to use one source of truth.
Bug: webrtc:11993, webrtc:12230
Change-Id: Ia98443d8ee65fd0795651981acab27c29428ba0c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244092
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35622}
Make sure previous_demuxer_criteria_ is only accessed on the network
thread and add annotation.
Bug: webrtc:11993, webrtc:12230
Change-Id: I4700fe41c947a3b1cce9649642dcd38ed62f873d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244087
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35618}
Because of this (seemingly simple) change, I had to change the return
type of transport_name from `const std::string&` to `absl::string_view`
to handle the case when there's no transport assigned.
That in turn caused an avalanche of required updates.
Bug: webrtc:12230, webrtc:11993
Change-Id: I16ec6c6a5fc2f5f7c7de572355a3c6ca924bb9d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244084
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35617}
Removes the ability to accept nonencrypted answers to encrypted offers.
Fixes some logic around bundled sessions and requirement for
transport parameters.
Bug: webrtc:11066
Change-Id: I56d8628d223614918a1e5260fdb8a117c8c02dbd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236344
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35298}
Reland of commit a743303211b89bbcf4cea438ee797bbbc7b59e80
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
- Mark FindHeaderExtensionByUri without filter argument as deprecated
Bug: webrtc:11713
Change-Id: I52a5ade1b94bc01d1c2a35cb56023684fcaf9982
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219081
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34129}
Pending messages on network thread for MediaChannel, will be dropped
when the MediaChannel object is deleted (without blocking).
Remove MessageHandler inheritance from Channel since Post-ing to the
network thread has been removed from there.
Copy/pasted code for SendRtp/SendRtcp in WebRtcVideoChannel and
WebRtcVoiceMediaChannel consolidated in MediaChannel.
Bug: webrtc:11993
Change-Id: I05320eb7f86b98adba50ca5eb8b76b78f4111263
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217720
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33955}
The channel classes have stored the negotiated headers but a more
natural place to store them is in the RtpTransceiver class where
RtpHeaderExtension state is managed as well as the implementation of
the only method that depends on the stored state,
HeaderExtensionsNegotiated().
Also adding a TODO for further improvements where we're unnecessarily
storing state in the channel classes for the purposes of the transports.
Bug: webrtc:12726
Change-Id: If36668e3e49782ddeada23ebed126ee2c4935b8c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/216691
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33917}
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}
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}
* 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 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}
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 reverts commit a743303211b89bbcf4cea438ee797bbbc7b59e80.
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}
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}
By changing was_ever_writable_ to be guarded by the worker thread
instead of the network thread.
Gets rid of one network thread invoke per audio/video m= section per
round of negotiation.
NOTRY=True
Bug: webrtc:12266
Change-Id: Ie913a9f96db3fd8351559e916922c82d2d0337f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/203881
Commit-Queue: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33130}
This reverts commit c1ad1ff178f0d0dfcde42843c51ae703005aaca1.
Reason for revert: This blocks the worker thread for a longer
contiguous period of time which can lead to delays in processing
packets. And due to other recent changes, the need to speed up
SetLocalDescription/SetRemoteDescription is reduced.
Still plan to reland some of the changes from the CL, just not the
part that groups the Invokes.
Original change's description:
> Do all BaseChannel operations within a single Thread::Invoke.
>
> Instead of doing a separate Invoke for each channel, this CL first
> gathers a list of operations to be performed on the signaling thread,
> then does a single Invoke on the worker thread (and nested Invoke
> on the network thread) to update all channels at once.
>
> This includes the methods:
> * Enable
> * SetLocalContent/SetRemoteContent
> * RegisterRtpDemuxerSink
> * UpdateRtpHeaderExtensionMap
>
> Also, removed the need for a network thread Invoke in
> IsReadyToSendMedia_w by moving ownership of was_ever_writable_ to the
> worker thread.
>
> Bug: webrtc:12266
> Change-Id: I31e61fe0758aeb053b09db84f234deb58dfb3d05
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194181
> Commit-Queue: Taylor <deadbeef@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32817}
TBR=deadbeef@webrtc.org,hta@webrtc.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:12266
Change-Id: I40ec519a614dc740133219f775b5638a488529b1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/203860
Reviewed-by: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Taylor <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33111}
Functionality wise, there should be no change with this CL, aside
from updating tests to anticipate OnPacketReceived to handle the packet
asynchronously (as already was the case via BaseChannel).
This only removes the network->worker hop out of the BaseChannel
class into the WebRTC MediaChannel implementations. However, it updates
the interface contract between BaseChannel and MediaChannel to align
with how we want things to work down the line, i.e. avoid hopping to
the worker thread for every rtp packet.
The following steps will be to update the video and voice channel
classes to call Call::DeliverPacket on the network thread and only
handle unsignalled SSRCs on the worker (exception case).
Bug: webrtc:11993
Change-Id: If0540874444565dc93773aee89d862f3bfc9c502
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202242
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33040}
all invokes, as well as BaseChannel constructor and destructor
should run on the same task queue which allow to use
simpler cancellation of pending task on BaseChannel destruction
Bug: webrtc:12339
Change-Id: I311b6de940cc24cf6bb5b49e1bbd132fea2439e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202032
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33009}
SetNegotiatedHeaderExtensions_w queued a task to update the list
of negotiated header extensions on the signal thread from the
worker thread, in belief that a later call to
GetNegotiatedHeaderExtensions() would happen on the WebRTC proxies,
leading to the update happening before the readout. In downstream
project, this is not always the case.
Fix this by synchronously updating the list of negotiated header
extensions.
Bug: chromium:1051821
Change-Id: I3266292e7508bb7a22a3f7d871e82c12f60cfc83
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/201728
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32977}
Instead of doing a separate Invoke for each channel, this CL first
gathers a list of operations to be performed on the signaling thread,
then does a single Invoke on the worker thread (and nested Invoke
on the network thread) to update all channels at once.
This includes the methods:
* Enable
* SetLocalContent/SetRemoteContent
* RegisterRtpDemuxerSink
* UpdateRtpHeaderExtensionMap
Also, removed the need for a network thread Invoke in
IsReadyToSendMedia_w by moving ownership of was_ever_writable_ to the
worker thread.
Bug: webrtc:12266
Change-Id: I31e61fe0758aeb053b09db84f234deb58dfb3d05
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194181
Commit-Queue: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32817}
This moves the code for threadjumping to get the RTP transport
despite its thread guard from the main function to two functions
marked especially "ForTesting".
Bug: webrtc:12230
Change-Id: I4473ed38e6fdedb05e2fbc97c2521bc1993fdd1d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/196521
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32792}
