AllocationSequence uses legacy rtc::Thread message handling. In order
to cancel callbacks it uses rtc::Thread::Clear() which uses locks and
necessitates looping through all currently queued (unbounded) messages
in the thread. In particular, these Clear calls are common during
negotiation and the probability of having a lot of queued messages is
high due to a long-running network thread function invoked on the
network thread.
Fix this by migrating AllocationSequence to task queues.
Bug: webrtc:12840, webrtc:9702
Change-Id: I42bbdb59fb2c88b50e866326ba15134dcc6ce691
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221369
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34241}
Removes dependence on rtc::Thread APIs from BPAS, which removes
the need to remove callbacks via rtc::Thread::Clear().
Bug: webrtc:12840
Change-Id: I0bcc1828c5ab38f521b583f52707174961f28e8a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221366
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34239}
AV1X->AV1 mapping added to SdpVideoFormatToVideoCodecInfo in
https://webrtc-review.googlesource.com/c/src/+/215586 results in
discrepancy of codec name between SDP and VideoCodecInfo. That violates
VideoCodecInfo design and breaks downstream projects.
This CL moves the mapping from VideoCodecInfoToSdpVideoFormat and
SdpVideoFormatToVideoCodecInfo to VideoCodecTypeMime.
Bug: b/181690054
Change-Id: I2a76524c29b082241f2ec72a60a209ce9b0c7c5f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221205
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34230}
UpdateActiveSimulcastLayers has been blocking
WebRtcVideoChannel::SetSend which may be called quite frequently during
negotiations. This CL changes UpdateActiveSimulcastLayers to not
synchronize with the transport's task queue to wait for the changes to
get applied.
This synchronization is quite costly, but so too are other remaining
things in VideoSendStream, so we should aim to get rid of the
`thread_sync_event_` in VideoSendStream.
Bug: webrtc:12840, webrtc:12854
Change-Id: Idb48d29b6b8382881c7c1e6f1d0f5e708dbca30f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221203
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34228}
documents the various payload type mappers used by WebRTC.
BUG=webrtc:12194,webrtc:12295
No-try: true
Change-Id: I88e2388f54e72db5e5fe0f72fa4fe4c455c99679
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220936
Commit-Queue: Philipp Hancke <phancke@nvidia.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34227}
Change-Id: I0880caa77a1097f56c560152e85c9ca29242f825
This PR add support for the `PeerConnectionObserverJni::OnRemoveTrack()`
event on Java, allowing to be notified when a remote track has been
removed. It's a very thing JNI wrapper on top of C++ API, being mostly
similar to other already available events like `track` and `addTrack`.
In Javascript API, tracks are not "removed" explicitly from the
PeerConnection, but instead receiver PeerConnection gets notified that
they have been removed from the streams they are associated to, and when
no `MediaStream` object has that track, it's considered that the track
has been removed from the PeerConnection. In Java and C++ APIs there's no
`MediaStreamObserver` class, so there's no way to listen to the
`removeTrack` event the same way happens in Javascript API, but instead
C++ API has a `removeTrack` event at PeerConnection level. This patchset
just only wraps and expose this `removeTrack` event from the C++ API to
the Java API.
This PR has been sponsored by Atos Research and Innovation
(https://atos.net/en/about-us/innovation-and-research).
Bug: webrtc:12850
Change-Id: I0880caa77a1097f56c560152e85c9ca29242f825
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218847
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Xavier Lepaul <xalep@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34225}
* Make VideoSendStream and VideoSendStreamImpl construction non-blocking.
* Move ownership of the rtp video sender to VideoSendStream.
* Most state is constructed in initializer lists.
* More state is now const (including VideoSendStreamImpl ptr)
* Adding thread checks to classes that appear to have had a race before
E.g. RtpTransportControllerSend. The change in threading now actually
fixes an issue we weren't aware of.
* Moved from using weak_ptr to safety flag and made some PostTask calls
cancellable that could potentially have been problematic. Initalizing
the flag without thread synchronization is also simpler.
This should speed up renegotiation significantly when there are
multiple channels. A follow-up change will improve SetSend as well
which is another costly step during renegotiation.
Bug: webrtc:12840
Change-Id: If4b28da5a085643ce132c7cfcf80a62cd1a625c5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221105
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34224}
Use dedicated DataSize/DataRate/Time classes instead plain integers
this avoid subtle overflows and makes code easier to follow.
Hide helper structs Probe and Cluster as private structs.
User foreach loops where possible.
Make private constants constexpr instead of using enum hack
Bug: None
Change-Id: I3e71dc1254d7ff8ce71e051de53f0459bfa5264d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219795
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34222}
Also renaming 'worker_queue_' variables to 'rtp_transport_queue' to
avoid confusion with the worker thread.
Bug: webrtc:12840
Change-Id: Ia647a9a5ed8fdc59929f5b7ac222328ccd129a18
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221140
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34217}
This removes the two step initialization and explicit circular
dependency between the sender and the observer that complicates
construction and making members const that should be.
Moving forward the encoder feedback instance will move to a different
class, so this CL is one part of making that change possible.
Also removing an unnecessary mutex and replacing with a checker.
Bug: webrtc:12840
Change-Id: I21694806b122592de0cd1e1d96f241d339a0860f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221108
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34214}
It was found from Chrome tracing that worker packet progression in
https://webrtc.github.io/samples/src/content/peerconnection/negotiate-timing/
during renegotiation of 100 transceivers is hindered by a multi-hundred
millisecond Invoke from the signaling to the worker thread. This
causes audio impairment.
Fix this by splitting the single Invoke into a series of Invokes,
allowing packets received during the renegotiation to be processed
between the worker invocations.
Experimental data of negotiation from 1 to 100 video transceivers
WebRtcDistinctWorkerThread OFF, before change:
4415.60 milliseconds, audio impairment 29760
4216.00 milliseconds, audio impairment 25560
4298.40 milliseconds, audio impairment 25440
WebRtcDistinctWorkerThread OFF, after change:
4258.70 milliseconds, audio impairment 26280
4255.50 milliseconds, audio impairment 25920
4363.10 milliseconds, audio impairment 25200
WebRtcDistinctWorkerThread ON, before change:
4407.80 milliseconds, audio impairment 24840
4541.00 milliseconds, audio impairment 26160
4377.80 milliseconds, audio impairment 17040
WebRtcDistinctWorkerThread ON, after change:
4364.80 milliseconds, audio impairment 0
4174.30 milliseconds, audio impairment 0
4309.00 milliseconds, audio impairment 0
We should reconsider this split after lazy decoders and decoder stream
projects have shipped, see
- bugs.webrtc.org/12462
- crbug.com/1157227
- crbug.com/1187289
Bug: webrtc:12840, webrtc:12462, chromium:1157227, chromium:1187289
Change-Id: I8e3b3943bd76f09da74b457690799415335b51f5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221103
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34202}
If at creation of a VP8 encoder there is not enough bitrate to enable a
given spatial layer - the configuration won't be updated to indicate
the correct temporal layer count. This means GetEncoderInfo() will
indicate lack of temporal layer support, which triggers issues with
rate allocation.
This CL fixes that by always setting an initial bitrate of 0bps.
Bug: webrtc:12788
Change-Id: I10974e85446b58e597d2ca415eaf2550306ce986
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220929
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34198}
If there is only little space left in a packet, and the remaining data
for a partially sent message is much larger, it will not generate a
small fragment for this message. This is to avoid fragmenting a message
into too many packets, as that increases the risk of losing messages
when partial reliability is enabled.
And when a stream doesn't want to generate a too small fragment, the
scheduler should _not_ switch streams. It should only switch streams
when a message has been fully sent. Previously, it would switch stream
when a stream doesn't want to produce a message, but as noted above,
that could happen for other reasons.
This required some refactoring, which also increased its robustness by
now only doing explicit stream switching on fully produced messages.
Bug: webrtc:12832
Change-Id: Icb213774fd0d26fba5640b00aac0407d393e4bfc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220937
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34197}
With this change, RTCVideoEncoder can specify:
- requested_resolution_alignment,
- apply_alignment_to_all_simulcast_layers
in the same way scaling_settings is specified.
Change-Id: I3de79a2eabaae581d6a9f2ef3e39496b9545a4f5
Bug: webrtc:12829
Change-Id: I3de79a2eabaae581d6a9f2ef3e39496b9545a4f5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220933
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Abby Yeh <abbyyeh@webrtc.org>
Commit-Queue: Peter Hanspers <peterhanspers@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34196}
