This experiment will tell if we still see the performance gains that we
saw with the "bursty slacked pacer" even if we don't apply slack (since
the "slack without burst" showed little impact at Stable).
The hope is that without slack all quality regressions will go away but
that bursting will still provide the desired performance benefits.
Bug: chromium:1354491
Change-Id: I95f05d040713addaaa1856c8e374a01c27311612
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272366
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37845}
For now use doubles as units in api/units have insufficient precision for jitter estimation.
Bug: webrtc:14381
Change-Id: I5a691b6a404b734a5bef11d677b72040bc02ff0f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272367
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37841}
Now Configure(), Decode() and Release() calls to the decoders should
all happen on the decoder thread. Added thread checkers to verify.
Bug: None
Change-Id: I2a1cf2cf7f3c3c7c50e382d82a3638e916ed9c34
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272368
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37840}
which has been superseeded by the equivalent nonstandard sdp fmtp
sps-pps-idr-in-keyframe
parameter.
Bug: webrtc:11769
Change-Id: I02667a165dd3f86b4685530c43f19531ec654737
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271121
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37839}
This is a reland of commit 02b5f3c9c12cddf3fc6e9125238b77ddb44f3b53
without making SetRemoteFingerprint private (but adding a deprecation warning)
Original change's description:
> dtls: allow dtls role to change during DTLS restart
>
> which is characterized by a change in remote fingerprint and
> causes a new DTLS handshake. This allows renegotiating the
> client/server role as well.
> Spec guidance is provided by
> https://www.rfc-editor.org/rfc/rfc5763#section-6.6
>
> BUG=webrtc:5768
>
> Change-Id: I0e8630c0c5907cc92720762a4320ad21a6190d28
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271680
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Philipp Hancke <phancke@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#37821}
Bug: webrtc:5768
Change-Id: I8dd674db8b683160013e1b4aa7776775d130978f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272221
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#37838}
Re-enabled multithreaded encoding using OpenH264, as the issue described in crbug.com/583348 no longer applies.
Bug: webrtc:14368
Change-Id: I5ae768a6edf3b40d99c13fb4ee4662626c993a66
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271820
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37837}
This way we're sure instantiation, configuration and decode calls all
happen on the decoder queue - making thread checking easier in the
actual decoder classes.
Bug: None
Change-Id: Ia98f47009f26b34eb8dad2ee0b4ddcde082d1994
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272022
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37825}
Encapsulate the results in a struct and move the post back to the packet
sequence in the original method. This allows the calls to
ReceiveStatisticsProxy::OnPreDecode to be moved to the main thread
always.
Bug: webrtc:11993
Change-Id: I37516444efeabdb330868733bccb1e842ea4d54f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271285
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37823}
This was only set to nullptr in non-test environments and was thusly
unused. With this change, the stats callbacks are gaurenteed to only
come from the VideoStreamBufferController and so the thread checks can
be removed.
Bug: webrtc:14003
Change-Id: Iaf0e77aa7c45a317e38ae27739edcefd3123d832
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272021
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37816}
I've added the proper headers to the only file in Chromium which includes screen_capture_frame_queue.h (see https://chromium-review.googlesource.com/c/chromium/src/+/3836317).
I've also built the remoting host and Chrome on Windows and Linux with this change and did not see any build errors.
The only build error I encountered was in shared_screencast_stream when building webrtc so I added the required header there.
Bug: webrtc:14378
Change-Id: Ie88e606dfa52f18514a87b87e5904424543d7df3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271922
Commit-Queue: Joe Downing <joedow@google.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#37811}
While transitioning to TimeDelta, WebRTC and Chromium has a
different idea about what type rtc::Event::kForever is. Code
can't assume rtc::Event::kForever is the same type as timed
wait arguments.
Bug: webrtc:14366
Change-Id: I4783c7de6d567c70b211de9aa9889417f6fafba1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272060
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37810}
Use TimeDelta type instead of raw ints
Remove usage of rtc::MessageHandler and RTC_FROM_HERE
Reduce usage of sigslots
Simplify storage for Channels and Permissions.
Classes that were previously self deleted are now deleted by their owner
Bug: webrtc:9702, webrtc:11318, webrtc:11943
Change-Id: I32c63c11c16c42ae58a65020b1c20a03b21a5abb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271298
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37808}
Moves FrameBuffer2 to its own GN target to reduce the binary size of the
video target.
Bug: None
Change-Id: I40e86a1eabc0c9e8e6fada3dcdb4e3a043c61c6c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271286
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37803}
It no longer has to interact with the decode queue, that will only
happen in VideoReceieveStream2. This moves some members in
VideoReceieveStream2 to the packet sequence which removes a few
post-tasks.
Bug: webrtc:14003, webrtc:11993
Change-Id: I4641b593b1a2f68e017c384b73ee4e75d06cf559
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271700
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37802}
- Move existing check on `max_frame_size` to the top.
By doing this early, the filter will not end up in an
inconsistent state (predicted but not updated) when
called with a tiny `max_frame_size`.
- Add sanity check on noise variance.
This will avoid sqrt of a negative number.
Bug: webrtc:14151
Change-Id: I2507a9114655d3c3ae35bf5ed83f3f1154c42ad3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271281
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37798}
