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}
Enumerating windows owned by the current process on Windows has some
complications due to the GetWindowText*() APIs potentially causing a
deadlock. The APIs will send messages to the window's message loop, and
if the message loop is waiting on this operation we will enter a
deadlock.
I previously put in a mitigation for this [1] which brought the
incidence rate down by an order of magnitude, but we are still seeing
this issue fairly frequently.
So, I've added DesktopCaptureOption enumerate_current_process_windows
which allows consumers to avoid this issue completely by ignoring
these potentially problematic windows.
By default the flag is set to true which equates with the current
behavior, consumers can set the flag to false to get the new behavior.
I've also updated all the capturers that enumerate windows on Windows
to respect the option.
[1] https://webrtc-review.googlesource.com/c/src/+/195365
Bug: chromium:1152841
Change-Id: I0e0d868957d6fbe1e607a440b3a909d005c93ccf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219380
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#34191}
The way that the "next stream" was picked when round-robin cycling was
flawed. When a message was produced in its entirety, the "next stream"
would be put at a stream identifier value that was just larger than what
was previously used. And then, for each fragment that was to be created,
it would try to resolve the nearest stream (above or equal to that
number) that had messages to send - always starting from that stream id
that didn't necessarily point to the stream for which fragments were
actually produced.
For example, if the previous stream ID for which a message was fully
produced on was 5, then the next_stream_id would be set to 6, and then
when producing next fragment, it might have produced something from
stream_id=1, because that was the only stream with messages in it. It
wouldn't update next_stream_id at this time; it would still be 6.
After a single fragment had been produced from that stream, a message
was queued on stream_id=6. The next time a fragment was to be produced,
it would not continue one stream_id=1, but instead pick the new stream,
which would suddenly produce a new fragment (with B flag set) while the
previous message (from stream_id=1) wasn't finished yet.
The fix is simple; Just ensure that we continue iterating from where we
ever produce a fragment from.
Bug: webrtc:12832
Change-Id: Icc761c572ed200db607a7609dab1ac6a8aeb2f04
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220938
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34190}
This variable is not used, always set to false but complicates
things for `keyframe_generation_requested_` as setting keyframe_needed
requires keyframe_generation_requested_ to be read synchronously from
what soon will be a different thread than where SetAndGetRecordingState
is called on.
Bug: webrtc:11993
Change-Id: I25675d9b70c9ec96a2542e7cf5480c835ea984eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220840
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34188}
Call send statistic updates are initiated on the send
transport sequence which forced calls to PostTask to the
worker thread which keeps several related attributes
protected by it.
Change this by:
* Using std::atomics for three attributes where synchronization
doesn't really matter and which can be accessed on either
context.
* Introducing a thread-compatible internal class which keeps
the statistics protected by the send transport sequence, and
emits UMA statistics on destruction.
The change also achieves the following trivial changes:
* The call origin time is now tracked by a proper
webrtc::Timestamp.
* The explicit use of the |send_transport_queue_| was replaced by
a more relaxed sequence checker.
Bug: webrtc:11993
Change-Id: I428a4d98b5fd2fd31222f62e597a9d61a3d4899f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220931
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34187}
The 'worker' noun in WebRTC is tied to the worker thread.
Hence naming an unrelated queue to something with worker
confuses code reading.
Change this to something which can't reasonably be confused
with the worker thread.
Bug: webrtc:11993
Change-Id: Icdcc728cf3dd9eb020f922367eebd0c520814568
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220934
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34183}
Both flexfec and AV1 seem not to have created interop issues and falling
back to the lower range is better than skipping the codecs.
BUG=webrtc:12295
Change-Id: I58459133beae4f17b767af92a4e2c9028ab8cbe3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217888
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@nvidia.com>
Cr-Commit-Position: refs/heads/master@{#34182}
This way we can have custom implementation of RtpTransportControllerSendInterface and pass it properly to Call.
Call relies on RtpTransportControllerSendInterface already so this is natural way to customize RTP related classes.
If there is custom factory present in dependencies it will be used, otherwise default factory will be used.
Intention behind this change is to have ability to have custom QoS with custom parameters.
Bug: webrtc:12778
Change-Id: I5b88957025621ef4bcd63eaa98c218ad213da9c8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217769
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@nvidia.com>
Cr-Commit-Position: refs/heads/master@{#34181}
Before this CL, before sending out any chunk, all inflight data chunks
were inspected to find out if they were supposed to be retransmitted.
When the congestion window is large, this is a lot of data chunks to
inspect, which takes time.
By having a separate collection for chunks to be retransmitted, this
becomes a much faster operation. In most cases, constant in time.
Bug: webrtc:12799
Change-Id: I0d43ba7a88656eead26d5e0b9c4735622a8d080e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219626
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34178}
