libsdl-org
SDL3: Linux V4L2 cameras never acquire a frame
Hello, I've just seen that SDL3 seems to be (experimentally) ready for use, so I've been trying to experiment with the new stuff. However, when I try to acquire a frame on a camera, I am only ever seeing null pointers returned, even when running the example file. A tight loop to see if it just takes some time also doesn't seem to help.
This seems to be irrespective of format as well, which seems to be against what was seen in #9263. I've tried a capture card and Droidcam's loopback camera, and neither seem to work. SDL definitely sees the cameras - they're listed by SDL_GetCameras and SDL_GetCameraSupportedFormats lists each one of their formats - but acquiring a frame seems to be out of reach.
I'm running Arch, and I'm on the latest sdl3 package on the AUR. At the moment, that's SDL3-preview-3.1.6 @ fe3566c. Definitely includes #10881, so I believe this to be a separate issue. If needed for reference, here's a dump of the only SDL_CameraSpec that Droidcam returns. (The capture card returns around 120 of them!)
desiredSpec = {SDL_CameraSpec}
format = {SDL_PixelFormat} SDL_PIXELFORMAT_IYUV
colorspace = {SDL_Colorspace} SDL_COLORSPACE_BT709_LIMITED
width = {int} 640
height = {int} 480
framerate_numerator = {int} 30
framerate_denominator = {int} 1
If there's any additional debugging information that's needed, please let me know.
Is there any chance we can log in and debug? We don't have this environment and hardware for testing.
I'm a bit hesitant, but I'm happy to help. What do you need me to do, then?
If you reach out to me via e-mail at [email protected], we can schedule a Zoom live debugging session.
An update, I just tried the same code with the same SDL version with my laptop's integrated camera, and it works! It's internally connected over USB, which theoretically should be the same behavior as the capture card - but of course, in this case it functions. It's possible that this problem may be more related to v4l2loopback devices? (Of which Droidcam, and as I've since tested the OBS Virtual Camera are.)
Oh, and I've sent you an email.
Ah, I don't know anything about v4l2loopback devices. Maybe @icculus knows more, or we can contact one of the authors for some help here?
I don't know more at the moment, but we can probably add some logging to see why it opens the camera but never gets any frames.
@BlockBuilder57 The simplest way to get extra logging is to set
https://github.com/libsdl-org/SDL/blob/572cc7af634ba713b5523ff25cca71307f7b6c65/src/camera/SDL_syscamera.h#L28
to 1.
(assuming you guys don't already sat together)
@BlockBuilder57, can you set that and see what output you get, both in the successful case and the unsuccessful one?
Compiled from latest on both. desktop.log laptop.log
Seems like the desktop is never getting its camera permission approved? I'm using Plasma 6.2.3 as my DE, if that's relevant.
What happens if you change the camera code to get frames without waiting for approval?
Commenting out these lines, you mean?
https://github.com/libsdl-org/SDL/blob/0f9e551d7127e9d244b25bf8ceef63422f77cfc2/src/camera/SDL_camera.c#L1223-L1227
It did not seem to help. As an experiment I also checked if the SurfaceList was getting populated, and it's not.
Seems like the desktop is never getting its camera permission approved
The v4l2 code does not have a concept of permission, so it approves everything immediately.
...is it possible the desktop is using the PipeWire backend and not v4l2?
I use PipeWire on both the desktop and laptop, so as far as I know that shouldn't be the problem. I also just tried pw-v4l2 to see if it would start working, but to no avail. There could be a difference in the config, though?
(I'm asking this on all the open bugs about this.)
If you're still having this problem, try forcing the v4l2 backend:
SDL_CAMERA_DRIVER=v4l2 ./MyCameraProgram
It defaults to PipeWire (and, on my Ubuntu 24.04 system, this is what it chooses by default). I'm wondering if the actual V4L2 backend works better than the PipeWire one.
It seems to work just fine! It likely does, and I would not be surprised if it was just a PipeWire issue. I'll rename this issue to better clarify.
I think (for the time being) we're just going to favor v4l2 over pipewire. My guess is this is causing all the camera problems.
I think (for the time being) we're just going to favor v4l2 over pipewire. My guess is this is causing all the camera problems.
That sounds like a good idea.