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}
There is no need to iterate through all outstanding data chunks to know
if a FORWARD-TSN can be sent. As the FORWARD-TSN will just move the
cumulative TSN ack, if a chunk is found that is not to be expired,
there is no need to continue any further. This makes it much faster
to know if to send a FORWARD-TSN when the congestion window is large.
Bug: webrtc:12799
Change-Id: I58bce408ae9814c8d3d7bbb480b0037a2cf88dd7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219625
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34176}
Specifying guards for functions and member variables. Also updating
a few places for VideoReceiveStream2 accordingly.
Bug: webrtc:11993
Change-Id: I2d13b009ec9853c6b2d90b08af555ecdd2b1ced6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220765
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34174}
Before this CL, a SACK was generated from scratch based on information
about each received fragment, to generate correct gap-ack-blocks.
When there was a lot of data in the data tracker (due to packet loss),
this took considerate time, as generating a SACK was O(N), where N is
the amount of fragments in the data tracker.
By instead having precomputed gap-ack-blocks that are continuously
updated, generating a SACK is much faster and the memory usage goes down
a bit as well.
Bug: webrtc:12799
Change-Id: I924752c1d6d31f06d27246e10b595e9ccb19320f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220763
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34171}
There limit that decides if an incoming TSN should be accepted or not
was decided based on very small transfers with no packet loss. But in
simulations where a socket tries to send a lot of data and when there
is moderate packet loss, the number of tracker data chunks on the
receive side will be considerably higher than what the limit was.
Set the limit to allow high data rate also on moderate packet loss.
Bug: webrtc:12799
Change-Id: I6ca237e5609d8b511e9b10c919da33dca7420c01
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220761
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34169}
The receive buffer mustn't be full; If it's full, and a message can't be
assembled, the socket can't accept more data. To avoid this, there is
a high watermark limit that, when reached, will make the socket only
accept chunks that advance the cumulative ack TSN.
Before this CL, the announced receiver window size in every sent SACK
was based on what the receive buffer could maximally be, which means
that in really high data rate applications, the amount of outstanding
data could actually fill the receive buffer (due to packet loss, that
prevents messages from being reassembled). As the socket started
behaving more conservatively when the high watermark limit was reached,
this resulted in unnecessary T3-RTXes. But by announcing the high
watermark limit instead, the sender will stay within it, and will have
a peer socket that behaves as expected.
Bug: webrtc:12799
Change-Id: Ife2f409914a230640217553c54f60d05843efc70
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220762
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34168}
Starting new audio codecs from the top of the lower range
reduces collisions with video codecs which are assigned from
the bottom of the lower range
BUG=webrtc:11640
Change-Id: If6d2b849b8e1de777a1d4352df533e4f1845fde9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220022
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34166}
