This makes it easier to update devices in th e future (avoiding multiple
CLs to change names, etc..).
Bug: b/259076774
Change-Id: I20ae940823978fbae84495d266345e4990184130
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283720
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38650}
* Use the same logdog_butler as Chromium instead of redefining one.
* Use luci-auth to prevent "local auth - HTTP 400" errors.
Change-Id: I2a0d1393f9f0e1e41b2bcc9a9fec2c50c19675f3
Bug: None
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/283520
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#38637}
Add a few tests to get started on debugging.
The goal of this CL is to get the Fuchsia bots running the tests without infra specific issues. After landing this, failures will be in test framework files (e.g. test/testsupport folder) and WebRTC code.
Bug: b/232740856
Change-Id: I332607fe875334769e7dadf6696d878a23a7e69f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280440
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Reviewed-by: Andrey Logvin <landrey@google.com>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#38596}
This CL will also make PipeWire tests retried 3 times in case of failures.
Change-Id: I9c66351f7ee171e29266fe4b8dcd52ca282c8f6d
Bug: webrtc:14644
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282820
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38595}
This flag is passed by default in chromium after https://crrev.com/c/3953676
Bug: b/257915522
Change-Id: If3518fa86f3e05ad02bfad8f200b17958f78602d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282225
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Andrey Logvin <landrey@google.com>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Auto-Submit: Andrey Logvin <landrey@google.com>
Cr-Commit-Position: refs/heads/main@{#38581}
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}
This reverts commit dd32562f242b247aed8add4efecaf3e20c623b9a.
Reason for revert: Updated the original change to dynamically load
the CoreMessaging.dll instead of statically linking with the .lib.
Original change's description:
> Revert "Wait for frames to arrive in WgcCapturer instead of returning nothing."
>
> This reverts commit 93bb3051490253d56dc1cdab4701b91138a151c3.
>
> Reason for revert: It breaks a test while rolling into Chromium,
> see https://webrtc-review.googlesource.com/c/src/+/261780/21#message-4a96e33bfb475f19a618be82bbe72951b23085ef for details.
>
> Original change's description:
> > Wait for frames to arrive in WgcCapturer instead of returning nothing.
> >
> > We're seeing a high instance of "first capture failed" in Chromium when
> > using WGC. We can reduce this by waiting for frames to arrive if there
> > are none in the frame pool instead of returning a temporary error.
> >
> > I've set the maximum time to wait for a frame to 50ms. If no frame
> > arrives before 50ms has elapsed, we will return a temporary error.
> > Added a new test, FirstCaptureSucceeds, to verify that this is working
> > as expected.
> >
> > As part of this I updated the name of the `kCreateFreeThreadedFailed`
> > enum value to `kCreateFramePoolFailed`. The value remains the same
> > since they both report failures in frame pool creation.
> >
> > I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
> > store two frames. This should prevent us from having to wait on the
> > event as frequently. This will increase the latency between capture
> > and display, however. High frame rate applications should not be
> > noticeably affected.
> >
> > Additionally, we uncovered a bug in the OS that prevents window capture
> > when there are displays attached, but none of them are active. Added
> > a new check to `IsWgcSupported` to cover this scenario.
> >
> > Finally, some issues with other WGC tests blocked moving the TryBots
> > to a newer version of Windows. This CL fixes those issues and updates
> > the TryBot configuration.
> >
> > bug: chromium:1314868
> > Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
> > Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> > Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
> > Commit-Queue: Austin Orion <auorion@microsoft.com>
> > Reviewed-by: Jeremy Leconte <jleconte@google.com>
> > Cr-Commit-Position: refs/heads/main@{#37404}
>
> Change-Id: If237df4826fe20b6fe2ca4b57253623321bf33c5
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267460
> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
> Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37408}
Change-Id: I6cc2becd9ed363782ab2f326f58d9401bc8fb820
Bug: chromium:1314868
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267902
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#37470}
This reverts commit 93bb3051490253d56dc1cdab4701b91138a151c3.
Reason for revert: It breaks a test while rolling into Chromium,
see https://webrtc-review.googlesource.com/c/src/+/261780/21#message-4a96e33bfb475f19a618be82bbe72951b23085ef for details.
Original change's description:
> Wait for frames to arrive in WgcCapturer instead of returning nothing.
>
> We're seeing a high instance of "first capture failed" in Chromium when
> using WGC. We can reduce this by waiting for frames to arrive if there
> are none in the frame pool instead of returning a temporary error.
>
> I've set the maximum time to wait for a frame to 50ms. If no frame
> arrives before 50ms has elapsed, we will return a temporary error.
> Added a new test, FirstCaptureSucceeds, to verify that this is working
> as expected.
>
> As part of this I updated the name of the `kCreateFreeThreadedFailed`
> enum value to `kCreateFramePoolFailed`. The value remains the same
> since they both report failures in frame pool creation.
>
> I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
> store two frames. This should prevent us from having to wait on the
> event as frequently. This will increase the latency between capture
> and display, however. High frame rate applications should not be
> noticeably affected.
>
> Additionally, we uncovered a bug in the OS that prevents window capture
> when there are displays attached, but none of them are active. Added
> a new check to `IsWgcSupported` to cover this scenario.
>
> Finally, some issues with other WGC tests blocked moving the TryBots
> to a newer version of Windows. This CL fixes those issues and updates
> the TryBot configuration.
>
> bug: chromium:1314868
> Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
> Reviewed-by: Alexander Cooper <alcooper@chromium.org>
> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
> Commit-Queue: Austin Orion <auorion@microsoft.com>
> Reviewed-by: Jeremy Leconte <jleconte@google.com>
> Cr-Commit-Position: refs/heads/main@{#37404}
Change-Id: If237df4826fe20b6fe2ca4b57253623321bf33c5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267460
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37408}
We're seeing a high instance of "first capture failed" in Chromium when
using WGC. We can reduce this by waiting for frames to arrive if there
are none in the frame pool instead of returning a temporary error.
I've set the maximum time to wait for a frame to 50ms. If no frame
arrives before 50ms has elapsed, we will return a temporary error.
Added a new test, FirstCaptureSucceeds, to verify that this is working
as expected.
As part of this I updated the name of the `kCreateFreeThreadedFailed`
enum value to `kCreateFramePoolFailed`. The value remains the same
since they both report failures in frame pool creation.
I also increased `kNumBuffers` from 1 to 2, so that the frame pool can
store two frames. This should prevent us from having to wait on the
event as frequently. This will increase the latency between capture
and display, however. High frame rate applications should not be
noticeably affected.
Additionally, we uncovered a bug in the OS that prevents window capture
when there are displays attached, but none of them are active. Added
a new check to `IsWgcSupported` to cover this scenario.
Finally, some issues with other WGC tests blocked moving the TryBots
to a newer version of Windows. This CL fixes those issues and updates
the TryBot configuration.
bug: chromium:1314868
Change-Id: Id9c4d5ee98621e682ef04864c3848d50e761cdb7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261780
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#37404}
This reverts commit 915d419eb94782ce424ae59c07d8b4366e88be74.
Reason for revert: The bots which can run this tests is now working
Original change's description:
> Temporarily disable video_capture_tests on linux
>
> No bots can run linux video_capture_tests for now.
>
> Bug: webrtc:14220
> Change-Id: I5dbdefdd104befff92648a0693bee331d2b50e88
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266660
> Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
> Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
> Reviewed-by: Andrey Logvin <landrey@webrtc.org>
> Reviewed-by: Jeremy Leconte <jleconte@google.com>
> Cr-Commit-Position: refs/heads/main@{#37312}
Bug: webrtc:14220
Change-Id: I0a7a82cf64b0692be62a38f3df6416a33917c3d5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267105
Owners-Override: Andrey Logvin <landrey@webrtc.org>
Commit-Queue: Andrey Logvin <landrey@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#37369}
No bots can run linux video_capture_tests for now.
Bug: webrtc:14220
Change-Id: I5dbdefdd104befff92648a0693bee331d2b50e88
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266660
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#37312}
The tests check that the various scalability mode are supported
and the frames are marked properly by the encoder with their
spatial and temporal index.
The same information is then checked on the receiving side.
A new member is added on EncodedImage to store the temporal index,
and is filled by the encoders and retreived by the ref finder
objects on the decoding side.
Bug: webrtc:11607
Change-Id: I7522f6a6fc5402244cab0c4c64b544ce09bc5204
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260189
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37303}
Also use baremetal pool only for the video_capture_tests.
Currently this test is disabled on the M1 machines because they don't have a camera ready.
Change-Id: Ie34b5a09219d7e0e43ff026bcbdfba922955f8bb
Bug: b/230719743
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265680
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37235}
Baremetal machines have webcams and it makes it confusing wether webrtc_perf_tests require cameras to run.
Change-Id: I1f3dc05c976ed008079f990b9a55f3310ea73dda
Bug: b/235780120
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265641
Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#37189}
This reverts commit 5a71f1585875a9ef80b79d9f247d1e21319a17d6.
Reason for revert: Turns out all the tests are running on all the shards.
Original change's description:
> Run iOS tests on multiple shards.
>
> Bug: b/230824012
> Change-Id: I6d27a8ed2c07eb76972b3bbe3679f6346ba58e06
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261306
> Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
> Commit-Queue: Jeremy Leconte <jleconte@google.com>
> Cr-Commit-Position: refs/heads/main@{#36796}
Bug: b/230824012
Change-Id: Id353501f07156ccc109abf94e6d2a22014a5e767
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261562
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#36807}
This reverts commit 3466511ee1bb29f34851e497d7734f47cd078918.
Reason for revert: Pending time can be very long when the test are running at the same time as this builder:
https://luci-milo.appspot.com/p/chromium/builders/ci/ios15-beta-simulator
Original change's description:
> Migrate iOS simulator tests to Mac-12 machines.
>
> Bug: b/227442116
> Change-Id: I7b5157a735596616f9785391c40b8f26974c222d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260985
> Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
> Commit-Queue: Jeremy Leconte <jleconte@google.com>
> Cr-Commit-Position: refs/heads/main@{#36751}
Bug: b/227442116
Change-Id: I87f27b36db7aa4c6d9d6982a5e86d56648a709e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261307
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Christoffer Jansson <jansson@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#36795}
This CL moves all tests that take more than 5 seconds into the new target.
Bug: webrtc:14025
Change-Id: I760d1a270b399b581f41606647740466f6b87e7c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261262
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36782}
