It was used only to break the circular dependency between SocketServer
and Thread at destruction time. Replaced with a method call to
SetMessageQueue(nullptr).
Bug: webrtc:11943
Change-Id: I0606d473ad79655cca28411bb02c21e21d2d7220
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215587
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33807}
There's a problem where the destruction of the contained rtc::Thread
will join the spawned thread blocked on getaddrinfo(). However,
getaddrinfo() is sometimes slow and this behavior hinders packet traffic
when it happens.
Fix this by using the brand new detachable PlatformThread support.
Fixed: b:181572711, webrtc:12659
Change-Id: I0b7e0cca3b8b1b3ed22328d940b1bb95cacb5e24
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214780
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33804}
Logic for throttling how often REMB messages are sent is added to ReceiveSideCongestionController as well as a new method SetMaxDesiredReceiveBitrate. These are based on the logic in PacketRouter. The logic for throttling REMB and setting the max REMB will be removed from PacketRouter in a follow up cl.
The purpose is to eventually decouple PacketRouter from sending RTCP messages when RtcpTransceiver is used.
Bug: webrtc:12693
Change-Id: I9fb5cbcd14bb17d977e76d329a906fc0a9abc276
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215685
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33801}
Having a function that changes its behavior based on the build
flavor (debug vs release) is error prone, especially if considered
that the behavior change invalidates the expectation from the function
name itself.
If this feature is required to improve debugging, it should be behind
a macro (for example WEBRTC_LOG_FULL_IP_ADDRESSES) enabled by an
explicit build configuration which is turned OFF by default.
Bug: None
Change-Id: Id7adafc67d1ae674a3dbb382b16ad9faea59eba6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215064
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33800}
When the client asks for a message to be sent, it's put in the
SendQueue, which is available even when the socket is not yet connected.
When the socket is connected, those messages will be sent on the wire,
possibly fragmented if the message is large enough to not fit inside a
single packet. When the message has been fully sent, it's removed from
the send queue (but it will be in the RetransmissionQueue - which is
added in a follow-up change, until the message has been ACKed).
The Send Queue is a FIFO queue in this iteration, and in SCTP, that's
called a "First Come, First Served" queue, or FCFS. In follow-up work,
the queue and the actual scheduling algorithm which decides which
message that is sent, when there are messages in multiple streams, will
likely be decoupled. But in this iteration, they're in the same class.
Bug: webrtc:12614
Change-Id: Iec1183e625499a21e402e4f2a5ebcf989bc5c3ec
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214044
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33798}
The change introduces support for detachable PlatformThreads, for which
the Stop() call doesn't wait until the thread has finished executing.
The change also introduces rtc::ThreadAttributes that carries priority
and detachability thread attributes. It additionally refactors all
known use to use the new semantics.
Bug: b:181572711, webrtc:12659
Change-Id: Id96e87c2a0dafabc8047767d241fd5da4505d14c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214704
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33796}
- Received FEC packets are purged from the queue if:
1. All media packets protected by the FEC packet are received.
2. All media packets protected by the FEC packet are recovered.
3. Newer FEC packet(s) with sequence number '0x3fff' larger than an old FEC packet is received.
- When FEC packets get separated from their protected media packets by more than 48, none of the first conditions ever delete that FEC packet, no matter how old/ irrelevant it gets.
- Under specific circumstances, the new FEC packet (condition 3) is not received before the media sequence number space wraps around, and incorrectly activates the old FEC packet, resulting in FEC decode for the wrong packet.
- This change purges such old FEC packets in time before the media sequence numbers wrap around.
Bug: webrtc:12656
Change-Id: I6ddf5382638c8c7e9a65724b2544dfbbc4803342
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215100
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33795}
SdpVideoFormat is used to configure video encoder and decoders.
This CL adds support for comparing two SdpVideoFormat objects
to determine if they specify the same video codec.
This functionality previously only existed in media/base/codec.h
which made the code sensitive to circular dependencies. Once
downstream projects stop using cricket::IsSameCodec, this code
can be removed.
Bug: chromium:1187565
Change-Id: I242069aa6af07917637384c80ee4820887defc7d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213427
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33794}
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 field was only used in RTP Data Channels and isn't needed anymore.
Bug: webrtc:6625
Change-Id: Ieaa7ae03ca3e90eb4ddec4d384f5a76cef1600cc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215687
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33791}
Adding strong types went a little too far as these two types represent
the same sequence number. A "request sequence number" is a number, that
- when responded to - will be used as "response sequence number".
Having them separate added confusion and just a lot of type-casting.
Bug: webrtc:12614
Change-Id: I4636ea8f2252023a2d5a9b7033763e1978b1812e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214130
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33789}
The SCTP RFCs aren't very strict in specifying when a chunk or parameter
is invalid, so most chunks and/or parameters must be accepted but they
may need some cleaning to avoid a lot of error handling deeper in the
chunk handling code.
Bug: webrtc:12614
Change-Id: I723f08cbdc26e1a1b78463b6137340e638089037
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214966
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33788}
This test verifies that a StrongAlias<bool> can be evaluated as
a boolean without dereferencing it. Note that this is not the case
for StrongAlias<int>, for example, as that wouldn't even compile. Which
is quite good.
Bug: webrtc:12614
Change-Id: I67329364721fe0354d78daac1233254035454c03
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215686
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33787}
The ERLE is used to estimate residual echo for echo suppression. The
ERLE is reduced during far-end offset to avoid echo leakage. When there
is a strong near-end present this can cause unnecessary transparency loss.
This change adds an ERLE estimation that does not compensate for onsets and
uses it for residual echo estimation when the suppressor considers the near-end to be dominant.
Bug: webrtc:12686
Change-Id: Ida78eeacf1f95c6e62403f86ba3f2ff055898a84
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215323
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33786}
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}
This CL adds a new property to the DesktopFrame interface to indicate
that the capturer supports cursor capture and the frame may contain
an image of the cursor (if the cursor was over the window or screen
being captured). This allows the DesktopAndCursorComposer to avoid
compositing another image of the cursor on the frame.
This is preferred because natively capturing the cursor will likely
be more efficient, and for WGC the API to disable cursor capture
is only availabe on later versions of Win10, reducing the number
of users that could use it.
Bug: webrtc:12654
Change-Id: I992804ff2a65eb423fb8ecc66e066408dc05e849
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215341
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33780}
This changes modifies EnumerateCapturableWindows to accept an optional
parameter consisting of extended window styles that will prevent windows
with the specified styles from being returned. This allows us to filter
out windows with the WS_EX_TOOLWINDOW style for the WgcCapturerWin,
which does not support capture of such windows.
Bug: webrtc:12679
Change-Id: Id9ac28afd331ba20fcb7f9e7be54ea5eee2e022e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215161
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33779}
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}
Biggest change is a new helper class used to read data from the
bitstream and then pass the result to a function if reading was
successful. There's also helper to do if/else flow based on the read
values. This avoids a bunch of temporaries and in my view makes the
code esaier to read.
For example, this block:
uint32_t bit;
RETURN_FALSE_IF_ERROR(br->ReadBits(&bit, 1));
if (bit) {
RETURN_FALSE_IF_ERROR(br->ConsumeBits(7));
}
...is now written as:
RETURN_IF_FALSE(
br->IfNextBoolean([br] { return br->ConsumeBits(7); }));
In addition, we parse and put a few extra things in FrameInfo:
show_existing_frame, is_keyframe, and base_qp.
Bug: webrtc:12354
Change-Id: Ia0b707b223a1afe0a4521ce2b995437d41243c06
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215239
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33776}
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}
SequenceChecker needs to be prefixed with & in RTC_DCHECK_RUN_ON;
all examples except the first one were showing this.
Bug: none
Change-Id: I90468689675319f9df67eb04a5d4cc0767ffb7a9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215582
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33771}
This change introduces a race-checking mutex implementation useful
for downstream consumers that can guarantee that they invoke
WebRTC serially.
Fixed: webrtc:11787
Change-Id: I7cb74e2e88dc87b751130504c267ac20ee8df4ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179284
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33769}
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}
Due to a previous refactoring, the SCTP packet header is only added when
the first chunk is written. This wasn't reflected in the
`bytes_remaining`, which made it add more than could fit within the MTU.
Additionally, the maximum packet size must be even divisible by four as
padding will be added to chunks that are not even divisble by four (up
to three bytes of padding). So compensate for that.
Bug: webrtc:12614
Change-Id: I6b57dfbf88d1fcfcbf443038915dd180e796191a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215145
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33760}
