Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use portal to request access to camera #238

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

marbetschar
Copy link
Member

... instead of the --device=all flag. Eventually fixes #234 - however, I don't know how to effectively use the camera after the access was granted.

After access was granted, we should somehow provide the device to gstreamer so we are able to use it around here: https://github.com/elementary/camera/blob/portal/access_camera/src/Widgets/CameraView.vala#L121-L123

Anyone an idea?

@marbetschar marbetschar requested a review from a team June 5, 2022 17:33
@danirabbit
Copy link
Member

I saw this the other day when trying to find more information about porting to Gtk4. Maybe relevant? Here he’s using Pipewire: https://blog.gtk.org/2020/05/20/media-in-gtk-4/

@Marukesu
Copy link
Contributor

Marukesu commented Jun 6, 2022

After access was granted, we should somehow provide the device to gstreamer https://github.com/elementary/camera/blob/portal/access_camera/src/Widgets/CameraView.vala#L121-L123

I believe this snippet has what you want.

basically, i would drop the Gst.DeviceMonitor code, since we can't enumerate devices without --device=all, and make create_pipeline() accept the fd instead of a Gst.Device.

AFAIK, the camera portal means an hard dependency in pipewire 0.3 in the host and runtime, and camera would only work in systems with pipewire 0.3 installed.

@marbetschar
Copy link
Member Author

marbetschar commented Jun 6, 2022

Thanks guys! I started playing around with it and now getting the below error. It probably makes more sense to finish the Gtk4 port first, so we then can use the new APIs instead of investing more time into legacy stuff:

(io.elementary.camera:2): libportal-DEBUG: 10:18:47.076: Calling AccessCamera
** (io.elementary.camera:2): DEBUG: 10:18:47.284: CameraView.vala:115: access_granted: true
** (io.elementary.camera:2): DEBUG: 10:18:47.286: CameraView.vala:122: camera_fd:  19

** (io.elementary.camera:2): WARNING **: 10:19:17.586: CameraView.vala:200: Unexpected error from pipeline: Internal data stream error.

PS: Had to install the gstreamer1.0-pipewire plugin to get things "working". So we might want to ship this by default at some point.

@@ -190,6 +246,62 @@ public class Camera.Widgets.CameraView : Gtk.Box {
current_device = camera;
}

private void create_pipeline_fd (int camera_fd) {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi there. I've been looking into starting a new application involving webcam recording with GStreamer so I was taking a look through this source code and found this PR.

This function is largely duplicate code with the create_pipeline function which uses the v4l2src GStreamer element. The common code could be factored out to another function. However, I'm not sure it's really necessary to keep the V4L2 code path at all. From https://blogs.gnome.org/uraeus/2021/10/01/pipewire-and-fixing-the-linux-video-capture-stack/ :

we do not recommend your GStreamer application using the v4l2 or libcamera plugins, instead we recommend that you use the PipeWire plugins

In the future you may be able to remove the explicit call to the XDG Portal too:

There are a few major items we are still trying to decide upon in terms of the interaction between PipeWire and the Camera portal API. It would be tempting to see if we can hide the Camera portal API behind the PipeWire API, or failing that at least hide it for people using the GStreamer plugin. That way all applications get the portal support for free when porting to GStreamer instead of requiring using the Camera portal API as a second step. On the other side you need to set up the screen sharing portal yourself, so it would probably make things more consistent if we left it to application developers to do for camera access too.

However, taking a look at the source code for the pipewiresrc GStreamer element, I don't see any usage of the XDG Portal. I'm unclear if that's still on the roadmap to be implemented or if that idea was dismissed. I asked in the Pipewire Matrix room earlier today but haven't gotten a response yet.

Copy link

@Be-ing Be-ing Jun 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cheese and Kamoso use the camerabin GStreamer element.

Pipewire registers pipewiresrc with GST_RANK_PRIMARY + 1 so camerabin automatically uses pipewiresrc if it is available. Running gst-launch-1.0 -v camerabin confirms this:

/GstCameraBin:camerabin0/GstWrapperCameraBinSrc:camerasrc/GstAutoVideoSrc:camerasrc-real-src/GstPipeWireSrc:camerasrc-real-src-actual-src-pipewir.GstPad:src: caps = video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720, framerate=(fraction)10/1

Without Pipewire's GStreamer plugin, camerabin uses V4L2, running GST_PLUGIN_FEATURE_RANK=pipewiresrc:NONE gst-launch-1.0 -v camerabin:

/GstCameraBin:camerabin0/GstWrapperCameraBinSrc:camerasrc/GstAutoVideoSrc:camerasrc-real-src/GstV4l2Src:camerasrc-real-src-actual-src-v4l.GstPad:src: caps = video/x-raw, width=(int)1280, height=(int)720, framerate=(fraction)10/1, format=(string)YUY2, pixel-aspect-ratio=(fraction)1/1, interlace-mode=(string)progressive, colorimetry=(string)2:4:5:1

So camerabin would support both the cases of Pipewire being present or not. However, I don't know if there's a way to pass the file descriptor from the portal to camerabin.

@Be-ing
Copy link

Be-ing commented Jun 9, 2022

FWIW the camera portal may be deprecated soon(ish).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use portal to request access to camera
4 participants