Filter out devices that do not support any format supported by WebRTC.
This will for example be IR cameras that show as duplicated in the list
of cameras, but support only GRAY8 format and for that reason do not
work at all.
Bug: webrtc:42225999
Change-Id: Ic2905bc66b55c3f48b49ff4097167f10d17ad656
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/358864
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Andreas Pehrson <apehrson@mozilla.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42785}
Similar to PipeWire implementation of desktop capture, we have to avoid
CFI check for calls of dlopened PipeWire library. This avoid crashing
PipeWire camera backend when "is_official_build=true" option is used as
this turns on "is_cfi=true" enabling control flow integrity.
Bug: chromium:354776214
Change-Id: I7a9fc1c2d77c4ee0e8fe0586369b7246e0bb9180
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/358103
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#42706}
Similar to BGRA/RGBA we added recently, formats from PipeWire are in
big-endian, while WebRTC (using libyuv) is little-endian, therefore we
have to map BGR to RGB and not RGB to RGB as colors would be off. Also
add some additional formats supported by libyuv.
Bug: webrtc:42225999
Change-Id: Iee8303f0922fe434069b2b3f88994abecf7d2cc5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355860
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#42609}
Some DMAbuf types don't properly implement MAP_PRIVATE as it requires
copy-on-write support. As we don't need to write to these buffers, we
can switch to MAP_SHARED instead, making it work reliably on current
kernels without having any drawbacks in this context.
Tested and confirmed with libcamera software ISP on Thinkpad X13 with
an arm processor.
Bug: webrtc:42225999
Change-Id: Ic47b8c90456cccf3742e8274945dbd64fb8aac6d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/354623
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42484}
Do not add offset to the "length" argument for mmap call as it should be
passed as the last argument instead. This was not causing any problems
since the offset is usually 0, but it's still better to do it correctly.
Bug: webrtc:42225999
Change-Id: If1dbe7dfd2fb22c53493c0fafd23d782f0683a11
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/354521
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#42481}
Adds support for 32 bits formats needed for libcamera software ISP. This
is needed, because libcamera enforces 8 byte alignment and we only
support 3 byte alignment for RGB. This will make it work with 32 bits
aligned output formats recently added to libcamera.
Relevant libcamera patch: https://patchwork.libcamera.org/patch/20253/
This has been verified on an snapdragon device using libcamera and software ISP and on my machine using "vivid" virtual camera from libcamera and enforcing specific format.
Bug: webrtc:346808586
Change-Id: I8d89120660b2304b880d952c5acd7f5cd09b611e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/354400
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42474}
This avoids having duplicate camera entries presented to the user when
PipeWire camera is being used.
Bug: webrtc:346350844
Change-Id: I423db7fe0654cc1b1c91ee5264c6ba5dc4e24100
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/354320
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Andreas Pehrson <apehrson@mozilla.com>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#42462}
We want to copy device id to _lastUsedDeviceName variable, but we use
length of display name instead of length of device id, which might be
longer than expected and we end up reading beyond the source string.
Bug: webrtc:15853
Change-Id: Id278ed7e361ead85475910adec18b9db51e6890b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/341521
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41844}
Announce that we support SPA_DATA_DmaBuf and tell PipeWire not to map
memory for us so we can handle it ourself, similar like we do in case of
screen sharing. This fixes an issue when a camera is already in use by
gstreamer (pipewiresrc), where DMABufs are used, and we try to share
same camera and get no content, as PipeWire doesn't want to mmap DMABuf
memory for us and we get NULL data pointers.
Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1876895
Bug: webrtc:15654
Change-Id: I788d8d12b2fcd5588329d7265e45b479f74bb628
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/338921
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41826}
This RaceChecker is intended to be used on API thread only when we are
not capturing, however, since StartCapture() can be called while already
capturing, we have to avoid using it to guard members that do not meet
this expectations. Use API checker for _captureStarted instead and move
the capture race checker down where we can be sure that capturing is not
happening.
Bug: webrtc:15181
Change-Id: I52f74b893f2c36c3ce0facd053b003fa497101b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/338040
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#41714}
Use only one RaceChecker as intended with the original change. This gets
rid of specific RaceChecker for PipeWire members. Make PipeWireSession
guarded by API checker instead, since this member is accessed only in
[Start/Stop]Capture and move the race checker within PipeWire thread
loop lock. Also remove race check from OnStreamStateChanged where we
only modify one property guarded by API mutex.
Partially reverts a9d497b52dc21497fdfd0e8c03ab2f8559e02d15 reviewed
on https://webrtc-review.googlesource.com/c/src/+/326781.
Bug: webrtc:15181
Change-Id: I46449fce86611124688a65d5337771c75853f2ca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/338021
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#41713}
This allows to share an instance of VideoCaptureModulePipeWire which is
what browsers usually do when the same camera is being shared with more
than one consumer. This matches V4L2 implementation.
Bug: webrtc:15211
Change-Id: I2ae466739c2649029e76a29e6f16aad1014e9d42
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306964
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#41639}
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}
Make sure the notifier is reset when tearing down the camera portal and also when we already called it. Destruction of camera portal will be mostly invoked by an object holding it and serving as an implementation of the notifier interface and in such case we have to make sure it will
not get called at this moment.
Bug: webrtc:15407
Change-Id: If0c1fb1493d64d5e1f0228ed71813abbb9280083
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/315420
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#41167}
Moving the header file and definitions for PipeWireSession to the source
file allows DeviceInfoPipeWire to be reimplemented or used in wrappers
without the consumer needing to add PipeWire includes and definitions.
Bug: webrtc:15654
Change-Id: I895059d50bdf9e6ed152eca729c618261701457a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327381
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#41163}
Support the Pipewire videotransform meta via the already existing shared
infrastructure. This is needed for mobile devices which often have a 90
degree rotated camera - which is likely the reason there is already
support in the shared code paths.
Bug: webrtc:15464
Change-Id: I15223055d8675502ae326d270ebd2debbcfbfa50
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318641
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@{#40708}
This can be helpful in various situations, such as debugging with an
unrestricted Pipewire socket or for downstream projects like
B2G/Capyloon. Additionally it will help once we move from the camera
portal to the more generic device portal.
Original patch by Fabrice Desré <fabrice@desre.org>
Bug: webrtc:15464
Change-Id: Iae6802f242d68244bca85947cb15ef3eee923ab0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318642
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40706}
Make sure the callback is reset when tearing down the PipeWireSession
and that there is no concurrent access to it, which can potentially lead
to a crash.
Bug: webrtc:15386
Change-Id: I0b09002fe0479dc1cd946c80684bcc5d8754d54a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311546
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#40464}
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}
VideoCaptureV4L2 has some members that are set in StartCapture during
configuration of the device, but later accessed both on the capture
thread and on the api thread (same as StartCapture) in
CaptureSettings(), which can be called at any time. This is safe because
they are written only on the api thread when the capture thread is not
running. However, there is no helper class that separates the read and
write modes to allow annotations and static analysis of the thread
access of these members.
This commit allows annotations to be added by making VideoCaptureV4L2
use:
- VideoCaptureImpl::_requestedCapability for storing those members
requested through StartCapture(), to allow access on the api thread
through CaptureSettings().
- A new member configured_capability_ to replace those members mentioned
in the first paragraph above. Writes to it happen only in
StartCapture() and StopCapture(), while reads happen exclusively on
the capture thread in between.
Bug: webrtc:15181
Change-Id: I27e0f578e6ac2a2e6b0e34fbabfe4f743b296321
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306122
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@{#40290}
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 add a SequenceChecker guard to _deviceFd that
ensures it is accessed only on the api thread while the capture thread
is not running, and only on the capture thread otherwise.
Bug: webrtc:15181
Change-Id: Ibc414ee973a3c4798e38e9b9a63e3053b95b9599
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305645
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40194}
We use value -1 on over all the places through our code so it might be
better to define a constant and use it instead to make the code more
understandable on first look.
Bug: webrtc:15203
Change-Id: I4fc3e561bc7a7778c43ec6cfde7acebef2af79e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306620
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40156}
Allows to use camera portal separately in implementations where each
implementation needs to be called in different places.
This is targeted for Firefox support, where we need to ask for camera
access in the FF frontend code, otherwise making camera access requests
in the backend WebRTC code might result into presenting portal dialogs
asking for access from the javascript API.
Bug: webrtc:15202
Change-Id: Ida8b010bb93e08a9e5ddd9dd8a2a3549ee7fde8b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305222
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#40148}
This is what Firefox implementation relies on and I can see that also
the V4L2 implementation is doing the same.
Bug: webrtc:15087
Change-Id: I641062ba879b6ef83e31af79ecc9d06fdae54adb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/301320
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#39869}
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}
This is in preparation for adding a portal / pipewire backend.
This just renames one class and moved the code to different files.
There are no changes to the implementation.
Bug: webrtc:13177
Change-Id: Iae101fcabafdb6cddd4d82adbb26219e4b37557f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261680
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@{#36848}
With some slightly broken webcams, it's possible that the select()
returns with a timeout or no event. In that case, the v4l2 thread
never returns. To fix this, just check if quit_ is set and exit
unconditionally in that case.
https://bugzilla.mozilla.org/show_bug.cgi?id=1752326
Bug: None
Change-Id: Ic07ce15afd0016ff9f967c2cf64e646c20127457
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/251540
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36200}
This reverts commit 793bac569fdf1be16cbf24d7871d20d00bbec81b.
Reason for revert: rare compilation error fixed
Original change's description:
> Revert "Refactor the PlatformThread API."
>
> This reverts commit c89fdd716c4c8af608017c76f75bf27e4c3d602e.
>
> Reason for revert: Causes rare compilation error on win-libfuzzer-asan trybot.
> See https://ci.chromium.org/p/chromium/builders/try/win-libfuzzer-asan-rel/713745?
>
> Original change's description:
> > Refactor the PlatformThread API.
> >
> > PlatformThread's API is using old style function pointers, causes
> > casting, is unintuitive and forces artificial call sequences, and
> > is additionally possible to misuse in release mode.
> >
> > Fix this by an API face lift:
> > 1. The class is turned into a handle, which can be empty.
> > 2. The only way of getting a non-empty PlatformThread is by calling
> > SpawnJoinable or SpawnDetached, clearly conveying the semantics to the
> > code reader.
> > 3. Handles can be Finalized, which works differently for joinable and
> > detached threads:
> > a) Handles for detached threads are simply closed where applicable.
> > b) Joinable threads are joined before handles are closed.
> > 4. The destructor finalizes handles. No explicit call is needed.
> >
> > Fixed: webrtc:12727
> > Change-Id: Id00a0464edf4fc9e552b6a1fbb5d2e1280e88811
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215075
> > Commit-Queue: Markus Handell <handellm@webrtc.org>
> > Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> > Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> > Reviewed-by: Tommi <tommi@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33923}
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> TBR=handellm@webrtc.org
>
> Bug: webrtc:12727
> Change-Id: Ic0146be8866f6dd3ad9c364fb8646650b8e07419
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217583
> Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
> Reviewed-by: Markus Handell <handellm@webrtc.org>
> Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33936}
# Not skipping CQ checks because this is a reland.
Bug: webrtc:12727
Change-Id: Ifd6f44eac72fed84474277a1be03eb84d2f4376e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217881
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33950}
This reverts commit c89fdd716c4c8af608017c76f75bf27e4c3d602e.
Reason for revert: Causes rare compilation error on win-libfuzzer-asan trybot.
See https://ci.chromium.org/p/chromium/builders/try/win-libfuzzer-asan-rel/713745?
Original change's description:
> Refactor the PlatformThread API.
>
> PlatformThread's API is using old style function pointers, causes
> casting, is unintuitive and forces artificial call sequences, and
> is additionally possible to misuse in release mode.
>
> Fix this by an API face lift:
> 1. The class is turned into a handle, which can be empty.
> 2. The only way of getting a non-empty PlatformThread is by calling
> SpawnJoinable or SpawnDetached, clearly conveying the semantics to the
> code reader.
> 3. Handles can be Finalized, which works differently for joinable and
> detached threads:
> a) Handles for detached threads are simply closed where applicable.
> b) Joinable threads are joined before handles are closed.
> 4. The destructor finalizes handles. No explicit call is needed.
>
> Fixed: webrtc:12727
> Change-Id: Id00a0464edf4fc9e552b6a1fbb5d2e1280e88811
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215075
> Commit-Queue: Markus Handell <handellm@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33923}
# Not skipping CQ checks because original CL landed > 1 day ago.
TBR=handellm@webrtc.org
Bug: webrtc:12727
Change-Id: Ic0146be8866f6dd3ad9c364fb8646650b8e07419
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217583
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33936}
PlatformThread's API is using old style function pointers, causes
casting, is unintuitive and forces artificial call sequences, and
is additionally possible to misuse in release mode.
Fix this by an API face lift:
1. The class is turned into a handle, which can be empty.
2. The only way of getting a non-empty PlatformThread is by calling
SpawnJoinable or SpawnDetached, clearly conveying the semantics to the
code reader.
3. Handles can be Finalized, which works differently for joinable and
detached threads:
a) Handles for detached threads are simply closed where applicable.
b) Joinable threads are joined before handles are closed.
4. The destructor finalizes handles. No explicit call is needed.
Fixed: webrtc:12727
Change-Id: Id00a0464edf4fc9e552b6a1fbb5d2e1280e88811
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215075
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33923}
This is essentially replacing `new rtc::RefCountedObject` with
`rtc::make_ref_counted` in many files. In a couple of places I
made minor tweaks to make things compile such as adding parenthesis
when they were missing.
Bug: webrtc:12701
Change-Id: I3828dbf3ee0eb0232f3a47067474484ac2f4aed2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215973
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33852}
The change introduces support for detachable PlatformThreads, for which
the Stop() call doesn't wait until the thread has finished executing.
The change also introduces rtc::ThreadAttributes that carries priority
and detachability thread attributes. It additionally refactors all
known use to use the new semantics.
Bug: b:181572711, webrtc:12659
Change-Id: Id96e87c2a0dafabc8047767d241fd5da4505d14c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214704
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33796}
Some locations in the WebRTC codebase RTC_LOG the value of the
__FUNCTION__ macro which probably is useful in debug mode. Moving
these instances to RTC_DLOG saves ~10 KiB on arm64.
Bug: webrtc:11986
Change-Id: I5d81cc459d2850657a712b9aed80c187edf49a3a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/203981
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33086}
Reader-writer locks helps performance only when there are many
concurrent readers, and I would expect that isn't the case for this
class. Using a plain mutex reduces complexity.
Bug: webrtc:12102
Change-Id: I07c315bcbfc38f1d8befe5395c9ece54c673aeb7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/190722
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32547}
This is a reland of 44dd3d743517fe85212ba4f68bda1e78c2e6d7ec
Original change's description:
> Migrate modules/desktop_capture and modules/video_capture to webrtc::Mutex.
>
> Bug: webrtc:11567
> Change-Id: I7bfca17f91bf44151148f863480ce77804d53a04
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/178805
> Commit-Queue: Markus Handell <handellm@webrtc.org>
> Reviewed-by: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#31681}
Bug: webrtc:11567
Change-Id: I03a32cb7194cffb9e678355c4af4d370b39384b3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/179093
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31716}
The side effect of not filtering on V4L2_CAP_VIDEO_CAPTURE is that
every device is enumerated twice. Because we look up devices by name,
and the device that supports V4L2_CAP_VIDEO_CAPTURE seems to always
appear first in /dev/video, this does not seem to end up with us ever
choosing an inappropriate device. We might get away with just filtering
device names from the list, but if the order of devices ever changed in
/dev/video there could be problems.
Bug: webrtc:11641
Change-Id: I16fee4edc873838ed4643ee16a8bbc699d6bbcf5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/176460
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Dan Minor <dminor@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#31508}
And delete corresponding dependencies on :webrtc_common. After this
change, common_types.h is included directly only from code in the
following directories:
api/
api/video/
api/video_codecs/
common_video/libyuv/include/
media/base/
modules/remote_bitrate_estimator/
modules/rtp_rtcp/source/
modules/video_coding/codecs/vp9/
There remains plenty of indirect dependencies on the types declared in
common_types.h, but the fewer direct dependencies should make it
easier to find the proper place for each type.
Bug: webrtc:5876
Change-Id: I93e8f214025ecb613c19fdec2015bd3f96c59aae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130501
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27376}
