The new name more accurately reflects the intent of the actual implementation.
Bug: none
Change-Id: I3d2aeb561104165f9f9879854a4a210730e02ff5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232130
Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Fanny Linderborg <linderborg@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35020}
This CL ensures that each DesktopFrame's updated-region is expressed in
the frame's own coordinates, where the top-left is always (0, 0).
For example, DesktopFrame::GetFrameDataAtPos() and its callers use
this coordinate system.
Previously, whenever a RANDR monitor with a non-zero offset was
selected, ScreenCapturerX11 would hit some DCHECKs when trying to
copy pixels from previous frames, or when capturing new pixels into
them from XDAMAGE regions.
Bug: None
Change-Id: I7b2e8d0449359ee7b263ad60af193e2bf89aa1f4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/232085
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#35017}
by not encoding redundancy. The timestamp gap of 400ms means a
rtp timestamp difference of 19200 which would overflow the 14 bit
RED timestamp difference field.
To test in Chrome, go to
https://webrtc.github.io/samples/src/content/peerconnection/audio/
set `useDtx = true` in the console and be very quiet.
BUG=webrtc:13182,webrtc:11640
Change-Id: I1cedc7d846ac7ae821bb7cb5c0f37a17511ac727
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231940
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35005}
All valid scalability modes should be supported by the builtin
software decoder/encoder.
Bug: chromium:1187565
Change-Id: If66105d210d5055019f35dae2f80a18ad4a70cdd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222642
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34998}
The nack threshold feature is unlikely to provide any value, since
reordered packets are rare. This CL also removes the factory method
from the NackTracker class, since it did not add much value.
Bug: webrtc:10178
Change-Id: Ib6bece4a2d9f95bd4298799aaa15627f5c014b61
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231953
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34993}
This is tested by a simple unit test and a new fuzzer that verify that all that can be parsed also can be written.
Bug: webrtc:12000
Change-Id: I461aedf97d3dec6e8916e72110fa097c3b31c27f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231642
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34986}
This is done by not adding missing packets to the NACK list if the number of samples per packet is too large.
Bug: webrtc:10178
Change-Id: If46398d6d05ea35f30d7028040d3b808559e950b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231841
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34984}
The documentation for `OpenPipeWireRemote()` says:
> Open a file descriptor to the PipeWire remote where the camera nodes
> are available. The file descriptor should be used to create a
> pw_core object, by using pw_context_connect_fd.
In `InitPipeWire()` we already successfully requested the FD, but then
went on and used the unrestricted default socket.
This does not matter in non-sandboxed environments, as the stream we
want to use is available from both FDs. In flatpak sandboxes, however,
this requires to give full Pipewire access to the application.
Fix this by simply using the right, restricted FD, and while on it,
also make sure to not leak it.
This change has already landed in downstream in Firefox, see
https://phabricator.services.mozilla.com/D122904https://phabricator.services.mozilla.com/D124508
Bug: webrtc:13152
Change-Id: I3f8995c54c797e1a90a980f231e496a13cbe65b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230803
Reviewed-by: Joe Downing <joedow@chromium.org>
Commit-Queue: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#34983}
The VP9 encoder may drop a frame internally which will not advance the
frame pattern. Consider the following scenario where only spatial layer
0 and temporal layer 0 is active:
1. Key frame encoded
2. Spatial layer 1 is activated
3. Delta T0 dropped
4. Delta T0 encoded
No S1T0 frame is encoded in (1) since it's not active. When
NextFrameConfig is called in (3) it will say that future frames may
reference T0 on both S0 and S1, but it's then dropped.
On step (4), the SVC controller essentially thinks it's encoding a new
picture and will happily reference the T0 on what it thinks is the first
delta frame. However, this is actually still the key frame and since
there was no S1T0 frame produced it will reference an invalid buffer.
To fix this, only say it's possible to reference a T0 frame after it has
been successfully encoded.
Bug: webrtc:11999, webrtc:13142, chromium:1178444
Change-Id: Iab3d2042ce0b3fa7d952b2831d1a36b1a6613a86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231695
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34982}
Unlike libvpx, the VideoBitrateAllocation expects that the bitrate
allocation is separate for each temporal layer. In this instance, if the
bitrates are not separated it will fool the SVC controller into thinking
that all temporal layers are always active.
Bug: webrtc:11999
Change-Id: Ibc33ac00b8b7716c011b94e1ec9c640cedb5274e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231693
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34980}
which is a "degenerated" case that just adds a one-byte header.
BUG=webrtc:11640
Change-Id: I173f4cb56270e0090219e4450b036bbe1b51756a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231696
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34976}
Requesting nacks in more cases allows the delay adaptation to better
predict if it's worth it to increase the jitter buffer delay to wait for
the nacked packets to arrive.
Bug: webrtc:10178
Change-Id: I46adb76c013dbb8df0b99eb3f7a398f8f21c2bf6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231648
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34970}
This cover scenario where target bitrate is changed in a middle of
of group of frame after spatial upswitch.
This change should avoid wasting encoder resources to produce those
frames, reduce number of errors
"Encoder produced a frame for layer that wasn't requested"
Bug: webrtc:11999
Change-Id: I06045259b1cee2c21bfdabbafff3892b57c82a84
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230543
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34969}
This is done by adding a reorder optimizer that estimates the probability of receiving reordered packets.
The optimal delay is decided by balancing the cost of increasing the delay against the probability of missing a reordered packet, resulting in a loss. This balance is decided using the `ms_per_loss_percent` parameter.
The usage and parameters can be controlled via field trial.
Bug: webrtc:10178
Change-Id: Ic484df0412af35610e74b3a6070f2bac7a926a63
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231541
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34954}
Setting the rtp header extensions on the packet delivery thread
(currently worker, soon to be network), is now possible without
taking the hit of deleting and recreating the receive stream (and
rtp receiver and related state).
Bug: webrtc:11993
Change-Id: I9bbe306844a25d85d79cd216092ead66eaf68960
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/223741
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34953}
The HandleXr method has output arguments that are not set when an RTCP
report cannot be parsed. We should give these a sensible default value
to avoid accessing uninitialized memory
Bug: chromium:1247182
Change-Id: I6c54260aef3834643c41b96c0709489522d82533
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231237
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34943}
To focus on the ability to predict clipping, the clipping predictor
evaluator doesn't increment the true positive count anymore when a
prediction is simultaneously observed with a detection.
Note that `WebRTC.Audio.Agc.ClippingPredictor.F1Score` is still used
to log the F1 score - i.e., the histogram hasn't been renamed.
Bug: webrtc:12774
Change-Id: Ia987e568a6df2a3ddba7fa1b5697d6feda22d20c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231233
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34942}
BitstreamReader itself uses idea of Read function that always succeed,
and a separate function to check for errors.
Thus extra layer in the DependencyDescriptorReader is not needed.
Bug: None
Change-Id: Ie58861f2cbecc02a5a1a9538232494b4442c9afd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231226
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34940}
Split out `RelativeArrivalDelayTracker` and `DelayOptimizer` logic.
This is in preparation for adding another `DelayOptimizer` specialized in handling reordered packets.
Bug: webrtc:10178
Change-Id: Id3c1746d91980b171fa524f9b2b71cf11fc75f64
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231224
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34938}
Evaluate the clipping predictor whenever injected but keep using the
predictions only when allowed.
Bug: webrtc:12774
Change-Id: I9e8930a528d1d514d52b821a28b6c8ad0c3aeb5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231137
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
Commit-Queue: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34937}
Move Precision, Recall and F1-score computation from `AgcManagerDirect`
to a separate function that can be tested.
Bug: webrtc:12774
Change-Id: Iba20f153a72b7f957bf938e0642055d421045c02
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231228
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Hanna Silen <silen@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34933}
This reverts commit 2c41cbae37cac548a1133589b9d2c2e8614fa6cb.
Reason for revert: The breaking test in Chromium has been temporarily disabled in https://chromium-review.googlesource.com/c/chromium/src/+/3139794/2.
Original change's description:
> Revert "Wire up non-sender RTT for audio, and implement related standardized stats."
>
> This reverts commit fb0dca6c055cbf9e43af665d3c437eba6f43372e.
>
> Reason for revert: Speculative revert due to failing stats test in chromium. Possibly because the chromium test expected the metrics to not be supported, and now they are. Reverting just to unblock the webrtc roll into chromium.
>
> Original change's description:
> > Wire up non-sender RTT for audio, and implement related standardized stats.
> >
> > The implemented stats are:
> > - https://www.w3.org/TR/webrtc-stats/#dom-rtcremoteoutboundrtpstreamstats-roundtriptime
> > - https://www.w3.org/TR/webrtc-stats/#dom-rtcremoteoutboundrtpstreamstats-totalroundtriptime
> > - https://www.w3.org/TR/webrtc-stats/#dom-rtcremoteoutboundrtpstreamstats-roundtriptimemeasurements
> >
> > Bug: webrtc:12951, webrtc:12714
> > Change-Id: Ia362d5c4b0456140e32da79d40edc06ab9ce2a2c
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226956
> > Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> > Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#34861}
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> TBR=hta,hbos,minyue
>
> Bug: webrtc:12951, webrtc:12714
> Change-Id: If07ad63286eea9cdde88271e61cc28f4b268b290
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231001
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
> Reviewed-by: Olga Sharonova <olka@webrtc.org>
> Commit-Queue: Björn Terelius <terelius@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34897}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:12951, webrtc:12714
Change-Id: I786b06933d85bdffc5e879bf52436bb3469b7f3a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231181
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34930}
According to the RANDR 1.5 spec:
https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt
RRSetMonitor and RRDeleteMonitor requests will generate a
ConfigureNotify event on the root window of the screen.
They do not appear to generate any RRScreenChangeNotify or other
similar event. So this CL causes ScreenCapturerX11's monitor list to be
updated on ConfigureNotify events. It is needed, for example, when
using a commandline such as "xrandr --setmonitor ..." to add monitors.
Bug: None
Change-Id: I1948a8b96800721409472ac6264c935abe169ec3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230882
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#34919}
This reverts commit 677195d3eb6a5f0bc1d31d794a5190ba281c0335.
Reason for revert: Broke WebRTC to Chrome rolls:
https://crrev.com/c/3141000
example: https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/790256/overview
The error is similar to the failure on previous attempt to land this CL. See: https://crrev.com/c/3135220, and crash https://ci.chromium.org/ui/p/chromium/builders/try/linux-rel/787945/overview
Original change's description:
> Reland "PipeWire capturer: implement proper DMA-BUFs support""
>
> This is a reland of f2177f6612079ccce9c320ea7e77bc934c684f5c
>
> Original change's description:
> > PipeWire capturer: implement proper DMA-BUFs support
> >
> > Currently both KWin (KDE) and Mutter (GNOME) window managers don't
> > use DMA-BUFs by default, but only when client asks specifically for
> > them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
> > While current implementation works just fine on integrated graphics
> > cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
> > code either crashes or screensharing is slow and unusable.
> >
> > To fix this, DMA-BUFs has to be opened using OpenGL context and not
> > being directly mmaped(). This implementation requires to use DMA-BUF
> > modifiers, as they are now mandatory for DMA-BUFs usage.
> >
> > Documentation for this behavior can be found here:
> > https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
> >
> > Bug: chromium:1233417, webrtc:13137
> > Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
> > Commit-Queue: Tommi <tommi@webrtc.org>
> > Reviewed-by: Tommi <tommi@webrtc.org>
> > Reviewed-by: Erik Språng <sprang@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#34889}
>
> Bug: chromium:1233417, webrtc:13137
> Change-Id: I7d5763dd5db708cee20a31e559b26db0287f40d6
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230946
> Reviewed-by: Tommi <tommi@webrtc.org>
> Commit-Queue: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34903}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1233417, webrtc:13137
Change-Id: I64e2ce864f69e6097aba65ade04af7166e407409
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231135
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34915}
The desktop capturer uses a circular queue (currently of length 2) to
implement a double-buffer scheme. This allows a C++ API consumer to keep
a reference to the latest captured image without the pixels being
overwritten by a pending capture request.
The DCHECK was intended to warn that the application is still holding a
reference to a recycled frame that is being captured into. This made
sense when the capturer implementations were originally part of the
Chromoting host process. Now that the capturers are part of the WebRTC
C++ library, a DCHECK seems too harsh. A DCHECK should be reserved for
impossible conditions, but this one triggers simply because an API
consumer holds onto a reference for too long. This CL changes these
DCHECKs into log warnings.
The DCHECK is sometimes triggered by the Chromoting host process
(because of the recent change to use the standard encoding pipeline).
This is tracked by http://crbug.com/1239746.
Bug: None
Change-Id: Iad9ef38b4800315bd17c93b27d287e115d4fe54c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230881
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#34910}
delta_q is encoded as signed integer (s(4)) that uses extra bit for the
sign. See VP9 Bitstream Specification section 6.2.10 Delta quantizer syntax
Bug: None
Change-Id: Ib458c2a2ded3c4d6c153b6bedd29c48ef12cc538
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231125
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34908}
This is a reland of f2177f6612079ccce9c320ea7e77bc934c684f5c
Original change's description:
> PipeWire capturer: implement proper DMA-BUFs support
>
> Currently both KWin (KDE) and Mutter (GNOME) window managers don't
> use DMA-BUFs by default, but only when client asks specifically for
> them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
> While current implementation works just fine on integrated graphics
> cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
> code either crashes or screensharing is slow and unusable.
>
> To fix this, DMA-BUFs has to be opened using OpenGL context and not
> being directly mmaped(). This implementation requires to use DMA-BUF
> modifiers, as they are now mandatory for DMA-BUFs usage.
>
> Documentation for this behavior can be found here:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
>
> Bug: chromium:1233417, webrtc:13137
> Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34889}
Bug: chromium:1233417, webrtc:13137
Change-Id: I7d5763dd5db708cee20a31e559b26db0287f40d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230946
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34903}
Remove unreachable return statements from audio_device_alsa_linux.cc.
This is blocking the chromium roll into webrtc.
Bug: b/198565646
Change-Id: I6cd2a04d84f1ceabdba7b295e163b133869806fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231122
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34902}
This allows NetEq to adapt to late reordered packets which are common when using retransmissions.
Remaining cleanup of the plumbing from WebRTC API will be done in a follow-up cl.
Bug: webrtc:10178
Change-Id: Ia9911eaafdabd3b69441dc089116d79e24f1b2b2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231002
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34898}
This reverts commit fb0dca6c055cbf9e43af665d3c437eba6f43372e.
Reason for revert: Speculative revert due to failing stats test in chromium. Possibly because the chromium test expected the metrics to not be supported, and now they are. Reverting just to unblock the webrtc roll into chromium.
Original change's description:
> Wire up non-sender RTT for audio, and implement related standardized stats.
>
> The implemented stats are:
> - https://www.w3.org/TR/webrtc-stats/#dom-rtcremoteoutboundrtpstreamstats-roundtriptime
> - https://www.w3.org/TR/webrtc-stats/#dom-rtcremoteoutboundrtpstreamstats-totalroundtriptime
> - https://www.w3.org/TR/webrtc-stats/#dom-rtcremoteoutboundrtpstreamstats-roundtriptimemeasurements
>
> Bug: webrtc:12951, webrtc:12714
> Change-Id: Ia362d5c4b0456140e32da79d40edc06ab9ce2a2c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226956
> Commit-Queue: Ivo Creusen <ivoc@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34861}
# Not skipping CQ checks because original CL landed > 1 day ago.
TBR=hta,hbos,minyue
Bug: webrtc:12951, webrtc:12714
Change-Id: If07ad63286eea9cdde88271e61cc28f4b268b290
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231001
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Reviewed-by: Olga Sharonova <olka@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34897}
This CL also includes the following changes:
- `AudioProcessing::Config::GainController2::noise_estimator`
deprecated
- `EnergyToDbfs()` optimized by removing unnecessary `sqrt`
- Unit test minor fix, incorrect type was used
Bug: webrtc:7494
Change-Id: I88a6672d6f7cd03fcf6a3031883522d256880140
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230940
Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34893}
This reverts commit f2177f6612079ccce9c320ea7e77bc934c684f5c.
Reason for revert: Broke WebRTC to Chrome rolls:
https://chromium-review.googlesource.com/c/chromium/src/+/3135220
example: https://ci.chromium.org/ui/p/chromium/builders/try/fuchsia-x64-cast/431230/overview
ERROR at //third_party/webrtc/modules/desktop_capture/linux/egl_dmabuf.cc:26:11: Include not allowed.
#include "rtc_base/sanitizer.h"
^-------------------
It is not in any dependency of
//third_party/webrtc/modules/desktop_capture:desktop_capture_generic
The include file is in the target(s):
//third_party/webrtc/rtc_base:sanitizer
which should somehow be reachable.
Original change's description:
> PipeWire capturer: implement proper DMA-BUFs support
>
> Currently both KWin (KDE) and Mutter (GNOME) window managers don't
> use DMA-BUFs by default, but only when client asks specifically for
> them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
> While current implementation works just fine on integrated graphics
> cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
> code either crashes or screensharing is slow and unusable.
>
> To fix this, DMA-BUFs has to be opened using OpenGL context and not
> being directly mmaped(). This implementation requires to use DMA-BUF
> modifiers, as they are now mandatory for DMA-BUFs usage.
>
> Documentation for this behavior can be found here:
> https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
>
> Bug: chromium:1233417, webrtc:13137
> Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#34889}
TBR=mbonadei@webrtc.org,tommi@webrtc.org,sprang@webrtc.org,mfoltz@chromium.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com,grulja@gmail.com
Change-Id: I2c573f17adbb216156cd72f62f4dbb7328f8fb6a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1233417, webrtc:13137
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230944
Reviewed-by: Olga Sharonova <olka@webrtc.org>
Commit-Queue: Olga Sharonova <olka@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34892}
Currently both KWin (KDE) and Mutter (GNOME) window managers don't
use DMA-BUFs by default, but only when client asks specifically for
them (KWin) or when experimental DMA-BUF support is enabled (Mutter).
While current implementation works just fine on integrated graphics
cards, it causes issues on dedicated GPUs (AMD and NVidia) where the
code either crashes or screensharing is slow and unusable.
To fix this, DMA-BUFs has to be opened using OpenGL context and not
being directly mmaped(). This implementation requires to use DMA-BUF
modifiers, as they are now mandatory for DMA-BUFs usage.
Documentation for this behavior can be found here:
https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/doc/dma-buf.dox
Bug: chromium:1233417, webrtc:13137
Change-Id: I0cecf16d6bb0f576954b9e8f071cab526f7baf2c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227022
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34889}
