When packet arrives with large gap majority of the time could be spend
in finding next received packet. Embedding such search into PacketArrivalMap
makes it faster
Bug: chromium:1373414
Change-Id: I2e0be0f2fc4ea96af081531d575a17c70b72b25b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279881
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38459}
This new class implements the existing FieldTrialsView interface,
extending it with the verification functionality. For now, the
verification will only be performed if the rtc_strict_field_trials GN
arg is set.
Most classes extending FieldTrialsView today have been converted to
extend from FieldTrialsRegistry instead to automatically perform
verification.
Bug: webrtc:14154
Change-Id: I4819724cd66a04507e62fcc2bb1019187b6ba8c7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276270
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38453}
Remove useless comments and properly test frame values. Also rename the
FakeScreenCastStream to TestScreenCastStreamProvider.
Bug: webrtc:13429
Change-Id: I9b1943f0903101a1d9228cded541d3766879d84f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279740
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#38450}
We already communicated SPA_META_VideoDamage before, but we never used
these metadata. This change checks whether SPA_META_VideoDamage metadata
are available and construct a damage rect combined from all sent damage
regions.
Bug: webrtc:13429
Change-Id: I326109b4bacf51855904e53345c671640d670323
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278820
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#38449}
This test created another PipeWire stream we can connect to with
SharedScreenCastStream and recieve frames from there. This is an
initial version, where I test whether we can successfuly connect
and disconnect, receive frames and it also tests DesktopFrameQueue.
In the future I will add tests to test mouse cursor and try to
come up with some corner cases and possible scenarios.
Bug: webrtc:13429
Change-Id: Ib2a749207085c6324ffe3d5cc8f2f9c631fa6459
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256267
Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38431}
Tested: Chromium built with this change; verified that the
behavior at the beginning of the call has not changed with
both low (< 12) and high (> 12) input volumes.
Bug: webrtc:7494
Change-Id: Ie184c994d46bf6fd1cb209873383b911beb766e3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278787
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38420}
This reverts commit c1d5fda22c8ae456950c5549d22d099b478c67e2.
Reason for revert: This CL created thousands of metric alerts in the perf tests. It's possible that these are all expected, but since mbonadei@ is OOO right now, I think it's better to revert, and have him re-land when he is back.
Most alerts are here: https://bugs.chromium.org/p/webrtc/issues/detail?id=14549
Original change's description:
> Add documentation, tests and simplify webrtc::SimulatedNetwork.
>
> This CL increases the test coverage for webrtc::SimualtedNetwork, adds
> some more comments to the class and the interface it implements and
> simplify the logic around capacity and delay management in the
> simulated network.
>
> More CLs will follow to continue the refactoring but this is the
> ground work to make this more modular in the future.
>
> Bug: webrtc:14525, b/243202138
> Change-Id: Ib0408cf6e2c1cdceb71f8bec3202d2960c5b4d3c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278042
> Reviewed-by: Artem Titov <titovartem@webrtc.org>
> Reviewed-by: Per Kjellander <perkj@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Björn Terelius <terelius@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38388}
Bug: webrtc:14525, b/243202138
Change-Id: I5bc56c954bb12e7c27cb859e838f0b7a89e006f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279522
Owners-Override: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38415}
This reverts commit 332810ab5d41862b8f85ef30e84dbec4241f8b21.
Reason for revert: This commit chain seems to cause problems in LossBasedBwe.
Original change's description:
> Probing integration in loss based bwe 2.
>
> - Loss based bwe has 3 states: increasing (increasing when loss limited), decreasing (decreasing when loss limited), or delay based bwe (the same as delay based estimate).
> - When bandwidth is loss limited and decreasing, and probe result is available, GetLossBasedResult = min(estimate, probe result).
> - When bandwidth is loss limited and increasing, and the estimate is bounded by acked bitrate * a factor.
> - When bandwidth is loss limited and probe result is available, use probe bitrate as the current estimate, and reset probe bitrate.
>
> Bug: webrtc:12707
> Change-Id: I53cb82aa16397941c0cfaf1035116f775bdce72b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277400
> Commit-Queue: Diep Bui <diepbp@webrtc.org>
> Reviewed-by: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38382}
Bug: webrtc:12707
Change-Id: Ied86323b0ce94b87ac503a2ee34753cebef5f53d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279500
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38412}
This reverts commit aa71259b06b72ba0fc5a28c0ffa4891c69c09441.
Reason for revert: This commit chain seems to cause problems in LossBasedBwe.
Original change's description:
> Probe when network is loss limited.
>
> Trigger probes next process intervals if the loss based current state is either increasing or decreasing. 0/ first probe at the loss based estimate. 1/ if increasing: allow further probing. 2/ if decreasing: not allow further probing.
>
>
> Bug: webrtc:12707
> Change-Id: I4e99edcbe4e2c315e8498ffb7fb2e589cdb4e666
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279041
> Commit-Queue: Diep Bui <diepbp@webrtc.org>
> Reviewed-by: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#38395}
Bug: webrtc:12707
Change-Id: I1fb61337148faf6faaa0056dc25f14536a19a462
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279480
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38410}
Trigger probes next process intervals if the loss based current state is either increasing or decreasing. 0/ first probe at the loss based estimate. 1/ if increasing: allow further probing. 2/ if decreasing: not allow further probing.
Bug: webrtc:12707
Change-Id: I4e99edcbe4e2c315e8498ffb7fb2e589cdb4e666
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279041
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38395}
Libdrm is an essential library and should be available everywhere where needed. It also looks it's a dependency for Chromium already.
Bug: webrtc:13429
Change-Id: Id81497b4f29bbd80f7d94f57333aa533288c3538
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279023
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38392}
This CL increases the test coverage for webrtc::SimualtedNetwork, adds
some more comments to the class and the interface it implements and
simplify the logic around capacity and delay management in the
simulated network.
More CLs will follow to continue the refactoring but this is the
ground work to make this more modular in the future.
Bug: webrtc:14525, b/243202138
Change-Id: Ib0408cf6e2c1cdceb71f8bec3202d2960c5b4d3c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278042
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38388}
- Loss based bwe has 3 states: increasing (increasing when loss limited), decreasing (decreasing when loss limited), or delay based bwe (the same as delay based estimate).
- When bandwidth is loss limited and decreasing, and probe result is available, GetLossBasedResult = min(estimate, probe result).
- When bandwidth is loss limited and increasing, and the estimate is bounded by acked bitrate * a factor.
- When bandwidth is loss limited and probe result is available, use probe bitrate as the current estimate, and reset probe bitrate.
Bug: webrtc:12707
Change-Id: I53cb82aa16397941c0cfaf1035116f775bdce72b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277400
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38382}
This CL:
- makes it easier to understand the (nontrivial) metric interpretation
- corrects the computation of BufferDelay to use 0 for absent delay
- deletes metric MaxSkewShiftCount, unused since https://webrtc-review.googlesource.com/c/src/+/119701
- updates the unit test to directly test metric reporting
Corresponding update to histograms.xml:
https://crrev.com/c/3944909
Previous revert:
https://webrtc-review.googlesource.com/c/src/+/279040
This CL is identical to the original, except:
- the test is updated to spam fewer EXPECT_EQ failures on failure (EXPECT_EQs moved out of inner loop)
- the test not resets metrics (metrics::Reset()) at the beginning, like other histogram tests
Bug: webrtc:8671, chromium:1349051
Change-Id: Ie802e1f9d03a22ff7018f522a63b19e0b6eec2e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279046
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38376}
This is a speculative fix for the DCHECK at the top of
ScreenCapturerX11::CaptureScreen(). Whenever |selected_monitor_rect_|
changes, |queue_| should be reset, so that new frames are allocated
with the correct size. This CL adds a reset to UpdateMonitors() which
modifies |selected_monitor_rect_| and is called whenever an X11
configuration-change event is received (for example, when a monitor is
resized).
Bug: chromium:1372579
Change-Id: I9cc84a8b6990802f9d7dde05966ee17a80ddd48e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279065
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Lambros Lambrou <lambroslambrou@chromium.org>
Auto-Submit: Lambros Lambrou <lambroslambrou@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38374}
- Set the initial input volume to that forced by startup min volume
since the latter is removed in a follow-up CL
- Remove unwanted expectations
Bug: webrtc:7494
Change-Id: I2df28f5bfaf4e592dfeae5e03b157268473cc822
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278784
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38370}
If the network thread and worker thread is the same, this log will spam.
Bug: webrtc:14502
Change-Id: Icb283f38fe6fbbca06ce911b9c0793148d459eef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278790
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38363}
This CL:
- makes it easier to understand the (nontrivial) metric interpretation
- corrects the computation of BufferDelay to use 0 for absent delay
- deletes metric MaxSkewShiftCount, unused since https://webrtc-review.googlesource.com/c/src/+/119701
- updates the unit test to directly test metric reporting
Corresponding update to histograms.xml:
https://crrev.com/c/3944909
Bug: webrtc:8671, chromium:1349051
Change-Id: If73b6fca4de7343bff2c53f72cedda458d36c599
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278782
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38362}
This makes the implementation in line with the existing X11
implementation:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/desktop_capture/linux/x11/screen_capturer_x11.cc;l=240-243
The issue I am observing on slightly slower machines with 4k monitor
is that the frames tend to go back in time. I believe this happens
when the shared frame queue is full and has its frame shared. When
that happens, we still end up calling MoveToNextFrame and doing so
we will wrap around the queue and if the capturer captures a frame
again, it sees an older frame. This is causing screen glitches.
This CL normalizes the implementation with X11 (which is known to
work fine) and moves to next frame and always uses it. This helps
to keep the current_frame_ in sync for the caller / capturer and
the capturer will then always see the video moving forward.
On the same machine, these screencasts were taken:
Without this fix: https://youtu.be/7Toi8dL5eYw
With this fix: https://youtu.be/LOE8Si5iOuQ
Bug: chromium:1291247
Change-Id: I51d3d700d3417d31371b12a94f445fc7b530cf73
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278700
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@chromium.org>
Cr-Commit-Position: refs/heads/main@{#38342}
Instead of re-using the sender task queue, a new task queue will
suffice.
Bug: webrtc:14445
Change-Id: Ia7395ace2f0bb66bf9e76e3783b208f2cd0385dc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275771
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38332}
This CL adds #includes to header files in order to make them
self contained after the preprocessor pass.
Bug: b/251890128
Change-Id: I81c3ba38fb8ab8a2bbd151ba99aa871fae9f1b1b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278422
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38327}
Add passing optional speech level and speech probability to Process().
This enables computing an override for the RMS error from
Agc::GetRmsErrorDb(). Currently no speech level or probability are
passed outside the tests and no override happens elsewhere.
Bug: webrtc:7494
Change-Id: I0a7b1204aa51bcde8588963a5af023410405e83d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277560
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38318}
Add a buffer class to store speech probabilities and to estimate speech
activity. Follows the implementation of speech activity computation in
LoudnessHistogram but uses floats for computations.
Bug: webrtc:7494
Change-Id: I6ee72ec52919904ea4e1fbe51d61993aa7813c9f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277801
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38309}
The pacer can thus run on the Worker thread or an owned TQ depending on field trial string "WebRTC-SendPacketsOnWorkerThread"
Bug: webrtc:14502
Change-Id: Ic74b92b21371cc62c7b2f62f039bc800dcceef8c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277622
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38301}
The class will be used in experiment aiming at reducing the number of
used threads. The experiment will remove the need for the Pacer TQ and
RTP module worker TQ.
The helper ensure calls are made on either the worker thread a TQ
depending on the field trial
"WebRTC-SendPacketsOnWorkerThread"
Bug: webrtc:14502
Change-Id: I47581e3e3203712a244f1cb76952cd94734cc3f1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277444
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38289}
