1844020 - Fix camera enumeration with PipeWire backend

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, enhancement)

Description

[Jan Grulich]

We are not able to enumerate camera devices without permissions when PipeWire is used, but we can use xdg-desktop-portal to ask whether there is at least a camera present, which is enough to know. Currently we are using v4l2 backend to list the devices and later when we want to use PipeWire, we already have device info initialized using v4l2 and end up using it instead for everything.

Comment 1

[Jan Grulich]

Attachment: WIP: Bug 1844020 - correctly handle camera enumeration when PipeWire is used r=pehrsons

We are not able to enumerate camera devices when PipeWire is used and we
were currently (not intentionally) using v4l2 backend for that, which
made it to mix both backends together and that didn't end up well. Since
we are not able to query camera devices using PipeWire when we don't
have permissions, we are allowed to instead ask xdg-desktop-portal if
there is a camera device present, which is enough to satisfy all the
requirements. Also re-create device info when it was previously created
using v4l2 backend so it next time uses VideoCaptureOptions we get after
user granted us permission to access the camera and we use PipeWire as
expected.

Comment 2

[Jan Grulich]

Attachment: Bug 1844020 - Use VideoCaptureOptions to initialize VideoCapture and DeviceInfo also for V4L2 r=pehrsons

1. Avoid using V4L2 backend when PipeWire is enabled
   When WebRTC backend was initialized without using VideoCaptureOptions it
   always defaulted to use V4L2 backend as PipeWire can be only used when
   options are passed with "allow_pipewire=true". We now use options right
   from the beginning, setting allow_pipewire=true" or "allow_v4l2=true"
   depending on the backend we intend to use.

2. Use a camera placeholder when PipeWire is not fully initialized
   In scenario where websites do an enumeration without being able to ask
   for permissions, we would not have access to PipeWire socket and not
   being able to list camera devices. In this case we return a placeholder
   to indicate there is a camera device and later when there is a proper
   gUM request, we will be able to ask for permissions and enable access
   to PipeWire to give back the full list of camera devices.

Comment 3

[Jan Grulich]

Attachment: Bug 1844020 - WebRTC backport: Add a new VideoCaptureOptions ctor allowing to construct specific backend r=pehrsons

This is a simple backport of an upstream change.

TBD

Comment 4

[Jan Grulich]

Attachment: Bug 1844020 - Implement CameraPortal::HasCameraDevice() to check camera device presence r=pehrsons

Using PipeWire, we are only to query camera device once we were granted
permissions, however, in certain scenarios we need to know in advance
whether there is a camera device present and that's why camera portal
has IsCameraPresent() property.

Depends on D188217

Comment 5

[Jan Grulich]

Attachment: Bug 1844020 - WebRTC backport: Move PipeWireSession include from the header file r=pehrsons

This is a simple backport of an upstream change.

TBD

Depends on D189087

Comment 6

[Jan Grulich]

Attachment: Bug 1844020 - Add a camera device placeholder in case PipeWire is not initialized yet r=pehrsons

Reimplement DeviceInfoPipeWire with option to add a device placeholder
when there is a camera device, but we don't have access to PipeWire yet.
We ask the Camera portal whether there is a camera device present.

Depends on D189088

Comment 7

[Jan Grulich]

Attachment: Bug 1844020 - Clear device cache before proper enumeration when there is placeholder r=karlt

Ensure there is no placeholder device in the device cache to ensure the
calling site tries to only use real devices obtained through a proper
enumeration where, in case of PipeWire, we can finally get list of real
cameras after we are gained access to PipeWire socket.

Depends on D189089

Comment 8

[Jan Grulich]

Attachment: Bug 1844020 - Add option to DeviceInfo::GetDeviceName() identifying a placeholder device r=pehrsons

This is a simple backport of an upstream change.

TBD

Depends on D189088

Comment 9

[Jan Grulich]

Attachment: Bug 1844020 - Adapt desktop capturer implementations with an additional property in DeviceInfo::GetDeviceName() r=pehrsons

There was an API change in WebRTC in DeviceInfo::GetDeviceName() adding
a new property to identify whether the device is a placeholder or not.

Depends on D189929

Comment 11

[Jan Grulich]

Attachment: Bug 1844020 - Change DesktopCaptureImpl::CreateDeviceInfo() to return raw pointer r=pehrsons

This follows same API as used in WebRTC and makes the code more simple
without need of a different handling because of different returned type.

Depends on D188217

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/32bb962ad5fc
Use VideoCaptureOptions to initialize VideoCapture and DeviceInfo also for V4L2 r=pehrsons
https://hg.mozilla.org/integration/autoland/rev/339a3d7994b7
Implement CameraPortal::HasCameraDevice() to check camera device presence r=pehrsons
https://hg.mozilla.org/integration/autoland/rev/ed31b2acb5fb
Add option to DeviceInfo::GetDeviceName() identifying a placeholder device r=pehrsons,webrtc-reviewers
https://hg.mozilla.org/integration/autoland/rev/fef894fcc429
Add a camera device placeholder in case PipeWire is not initialized yet r=pehrsons
https://hg.mozilla.org/integration/autoland/rev/ae5d8a4c6f18
Clear device cache before proper enumeration when there is placeholder r=karlt
https://hg.mozilla.org/integration/autoland/rev/16dd60021954
apply code formatting via Lando

Comment 13

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/32bb962ad5fc
https://hg.mozilla.org/mozilla-central/rev/339a3d7994b7
https://hg.mozilla.org/mozilla-central/rev/ed31b2acb5fb
https://hg.mozilla.org/mozilla-central/rev/fef894fcc429
https://hg.mozilla.org/mozilla-central/rev/ae5d8a4c6f18
https://hg.mozilla.org/mozilla-central/rev/16dd60021954