There are two threads involved here, the thread that calls the API
functions and the pipwire main loop. Using one race checker for both is
wrong and triggers aborts.
Use a different race checker for all variables that are used by the
pipewire main loop or guarded against concurrent access with the
thread_loop_lock.
In one case, two RTC_CHECK_RUNS_SERIALIZED() checks are needed, so
enhance the macro to generate unique variable names.
Bug: webrtc:15181
Change-Id: Ib41514eb7aa98fe85d830461aa0c71e42ba821bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326781
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41198}
We will not always initialize PipeWire stream when we fail early and in
such case we will end up cleaning VideoCaptureModulePipeWire instance
where we will attempt to free it even when it is not initialized.
Bug: chromium:1457131
Change-Id: Id78310485aa5ae5d72c2d0d753dd5318b1b673ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311261
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#40390}
This annotates all unannotated members in VideoCaptureImpl and its
subclasses with either of:
- api_checker_: access on the api thread only
- capture_checker_: access in callbacks/on the capture thread while
capture is active, on the api thread otherwise
- a Mutex if it is already protected by it
Bug: webrtc:15181
Change-Id: I5084e7752a4716c29b85a9b403a88696f66d811f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305647
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40335}
CaptureSettings() can read started_ on the api thread at any time. But
it is written and read in pipewire callbacks, on other threads. A lock
seems suitable.
Bug: webrtc:15181
Change-Id: I3d26f02408a4e56921b955f059e504ffa9b8cae9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306121
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40286}
frameInfo_ is used on multiple threads. This commit splits it into:
- VideoCaptureImpl::_requestedCapability for writing what was requested
in StartCapture() and for reading in CaptureSettings(), on the api
thread only.
- A new member configured_capability_ (renamed from frameInfo_) for
accesses in callbacks, or on the api thread when no callbacks can
happen.
Bug: webrtc:15181
Change-Id: I105d8adfde52320e43ffe95fe23e11d028c80684
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306120
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40285}
This makes it possible to access cameras through xdg-desktop-portal and
pipewire.
For pipewire, a shared state is needed between the enumeration and the
creation of camera object. So a new API is needed with a shared options
object that holds the state and can be used to choose which backend to try.
Bug: webrtc:13177
Change-Id: Iaad2333b41e4e6fb112f4558ea4b623e59afcbd1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261620
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39251}
