Type 'additional_compile_target' are not meant to be tests.
Type 'raw' has no usage for xctests.
Explicitly set dcheck_always_on=false.
Bug: webrtc:13867
Change-Id: Ie47c300609ff5054d36110e8ee6c7a059ec452da
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256805
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#36336}
This patch takes a stab at modules/video_coding,
but reaches only about half.
Bug: webrtc:10335
Change-Id: I0d47d0468b818145470c51ae4e8e75ff58d499ae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256112
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36335}
This reverts commit e1223747c27e22c4c4c3006af10d58aec9718b28.
Reason for revert: Breaks WebRTC roll into Chromium. E.g:
https://ci.chromium.org/ui/p/chromium/builders/try/cast_shell_linux/1166014/overview
Original change's description:
> wayland: Add a common interface for screencast and remote desktop portal
>
> Change adapts the `base_capturer_pipewire` so that a portal can be
> injected in the capturer. This allows the remoting to inject its
> own portal for the purpose of capturing desktop stream as long
> as the injected portal provides implementation of the new interface
> that is added as part of this change.
>
> Additionally, a method has been exposed on the capturer to get
> details about the portal session so that the remoting
> implementation can use the same underlying session for controlling
> inputs on the remote host.
>
> Finally, desktop capturer interface is extended with a generic
> method `GetMetadata` that is used to retrieve session related
> information by CRD and relay it over to its input injector. Clients
> provide override for the method and it eventually invokes the
> underlying `GetSessionDetails` method on the portal instance.
>
> Bug: chromium:1291247
> Change-Id: I81b7ce3b949d8be2e24e2d303d5fbc76a849209c
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256400
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Commit-Queue: Salman Malik <salmanmalik@google.com>
> Cr-Commit-Position: refs/heads/main@{#36323}
Bug: chromium:1291247
Change-Id: I73fbb1b9a103d61fd8d7f04bb8452b3e29da9025
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256801
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36331}
Change adapts the `base_capturer_pipewire` so that a portal can be
injected in the capturer. This allows the remoting to inject its
own portal for the purpose of capturing desktop stream as long
as the injected portal provides implementation of the new interface
that is added as part of this change.
Additionally, a method has been exposed on the capturer to get
details about the portal session so that the remoting
implementation can use the same underlying session for controlling
inputs on the remote host.
Finally, desktop capturer interface is extended with a generic
method `GetMetadata` that is used to retrieve session related
information by CRD and relay it over to its input injector. Clients
provide override for the method and it eventually invokes the
underlying `GetSessionDetails` method on the portal instance.
Bug: chromium:1291247
Change-Id: I81b7ce3b949d8be2e24e2d303d5fbc76a849209c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256400
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Salman Malik <salmanmalik@google.com>
Cr-Commit-Position: refs/heads/main@{#36323}
The only caveat is that a name attribute for the `@Parameters`
annotation is required, as otherwise the test infrastructure
doesn’t find test results.
Bug: webrtc:13662
Change-Id: Ib3e2a6671d1045b0e19746ce78dd434fbee78b87
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256462
Reviewed-by: Linus Nilsson <lnilsson@webrtc.org>
Auto-Submit: Xavier Lepaul <xalep@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36322}
This is a solution to some problems that have been found locally when
running the fuzzer for a long time. The fuzzer keeps on fuzzing, and has
found a way to trigger a consistency check to fail when a client
intentionally sends different messages - unordered and ordered - using
the same TSNs. As the reassembly queue has different handling of ordered
and unordered chunks due to how they are reassembled, it will not notice
if it receives two different chunks with the same TSN. They will both go
to their respective reassembly streams, as those are separate by design.
The data tracker - which keeps track of all received DATA chunks as it
needs to generate SACKs, has a global understanding of all received
chunks. By having it indicate if this is a duplicate received chunk, the
socket can avoid forwarding both chunks to the reassembly queue; only
one chunk will get there.
Bug: None
Change-Id: I602a8552a9a4c853684fcf105309ec3d8073f2c2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256110
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36316}
The Thread class internally (`Thread::DoDestroy`) makes this call:
ss_->SetMessageQueue(nullptr);
Which sets the `msg_queue_` member variable of VirtualSocketServer
to nullptr. VSS checks for this in several places, but not all. In
particular `CancelConnects()` does handle it, but Disconnect(), which
is called from the same place (VirtualSocket::Close()), is missing
this check.
This CL adds some DCHECKs to catch when a pointer might be nullptr
and also avoids dereferencing a potential nullptr deref during teardown
if `Disconnect` is called, e.g. from within `VirtualSocket::Close()`
which is called from the dtor of `VirtualSocket`.
Bug: webrtc:13864
Change-Id: I717a0f033ebf70b1f59338680957723a77ccf4ca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256600
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36312}
This metric weights the PSNRs of luma and chroma planes in
a slightly smarter way than our current PSNR metric.
> J. Ohm, G. J. Sullivan, H. Schwarz, T. K. Tan and T. Wiegand,
> "Comparison of the Coding Efficiency of Video Coding Standards—Including
> High Efficiency Video Coding (HEVC)," in IEEE Transactions on Circuits and
> Systems for Video Technology, vol. 22, no. 12, pp. 1669-1684, Dec. 2012
> doi: 10.1109/TCSVT.2012.2221192.
Bug: None
Change-Id: Iec105e0b491628fc0ad4be9155b991203846ad1b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256463
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36311}
It is hard to add an unit test for this change, because OnTransportPacketsFeedback is the way to change the loss based estimate, and it also changes the lower link capacity.
Thus we cannot track the two values without making changes in goog_cc, which seem to be unecessary.
Bug: none
Change-Id: I689ef52c4440c9bc2ff30f88b9cda96a90b0b64e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256368
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36304}
This migrates all tests that work by just changing their runner.
This excludes tests using `@RunWith(ParameterizedRunner.class)`, and a
few other non-parameterized tests that fail with the default runner.
Bug: webrtc:13662
Change-Id: Ia0b7c80e04a6a6b7a51348b3a7f587d10061b58e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256367
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Xavier Lepaul <xalep@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36298}
DxgiOutputDuplicator objects hold a reference to the last frame that
they succesfully captured by maintaining a reference to the
SharedDesktopFrame that was passed as their target. This is done because
the DirectX capture APIs may fail to provide an update if there has been
no (or no substantial) change since the last capture call was made.
However, the higher levels of this capture stack
(DxgiDuplicatorController and ScreenCapturerWinDirectX), were unaware of
this, and assumed that the caller of CaptureFrame is the only one who
may have held a reference to the frame. Thus, when CaptureFrame is
called, the DirectX screen capturer assumes that the oldest frame in its
queue can be safely reused.
In the steady state, where capture is not being switched between
monitors, this is fine as there are no competing DxgiOutputDuplicators
being run and this assumption mostly holds true (or the frame is being
overwritten only when the DxgiOutputDuplicator is also done holding it).
However, when capture is being rapidly switched between multiple targets
(e.g. to show a preview of each of the available monitors), this can
result in a frame being held by one DxgiOutputDuplicator being passed to
another as a valid target and overwritten. In the common case of only a
single monitor this is essentially the same as steady state capture,
where there are no competing DxgiOutputDuplicator. In the other common
case of two monitors being captured, the fact that the
ScreenCaptureFrameQueue has two frames ends up masking this issue. Since
each monitor is captured in the same order, the same frame ends up
getting passed to each DxgiOutputDuplicator, so no data actually ends
up getting overwritten. In the case of 3 monitors, the 1st and 3rd
monitor end up sharing a frame, which when capture fails on one of them
surfaces as the other monitor being duplicately shown.
This change addresses the issue by ensuring that each screen that the
ScreenCapturerWinDirectX *actually attempts* to capture, gets it's own
FrameQueue, and thus essentially brings us back to the "steady state"
case for each monitor. Note that this does increase memory usage of
capturers that are switched between multiple targets by 2 frames/target
used (and actually attempted to be captured).
Alternatives considered:
DxgiOutputDuplicator makes a copy of the frame, rather than holding
a reference
This was rejected because adding an additional copy for every
capture upon getting a new frame, would expensive and could degrade
performance.
Allow the DxgiOutputDuplicators to "fail" when there has been no update
This would result in either a breaking change to the API for consumers
or would require the ScreenCapturerWinDirectX to track these last
captured frames; which would result in essentially the same approach,
but with less abstraction for re-using the frames.
Bug: chromium:1296228
Change-Id: I5442ec40e9f234046010b562b258db63693ccc6b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256043
Reviewed-by: Mark Foltz <mfoltz@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36295}
