Hey guys. What’s the interface to get v4l2 working on Pi4? The only mention I found in the code is in the browser support interface that allows access to /dev/video.
Gstreamer does not instantiate v4l2h264dec unless I am installing the snap in devmode. Am I missing something?
You should be able to access video4linux cameras using the camera interface. Note that it won’t auto-connect without an assertion from the store, so you will need to run snap connect after installing your snap during testing.
Hi, sorry, I did not clarify - I don’t need cameras. I need h/w decoding of h264 videos on pi4. Works fine in devmode on UC 20 at the moment but confined gstreamer can’t detect that system has those capabilities.
Not sure if this is related - https://github.com/snapcore/snapd/pull/9804/
v4l2 should be built on to of MMAL in rpi4 I think? I might be wrong though.
this PR is only part of the picture and will indeed help with MMAL decoding … the long term solution the Pi foundation wants to implement is access via /dev/videoX and m2m v4l support:
https://www.raspberrypi.org/forums/viewtopic.php?t=268356#p1628856
james is correct that the camera interface combined with opengl should be enough for the latter (i’m not sure about the state of the implementation in our kernel for v4l m2m though) …
PS: a snap using the MMAL implementation (still waiting for the PR to be merged before it can drop devmode) is at:
Thanks.
With UC 20 kernel it works well in devmode. I will try adding camera interface to check if it works confined.
can confirm that it works. Though it’s very not obvious that when you want to show a video you need to connect to camera interface to be honest.
So this requires something outside of the standard V4L2 API? That’s probably what confused me 
no, it only needs rw access to /dev/videoX to make use of any HW acceleration … the camera interface is the only one providing that … perhaps the description could be a bit more informative
$ snap interface camera|grep summary
summary: allows access to all cameras
Oh ok - I just saw this comment here and it said it enabled video for Linux: https://github.com/snapcore/snapd/blob/30ef6dd52df387d359afdcd15f96210e6e0a1d71/interfaces/builtin/browser_support.go#L159
hah, you are better than me in grepping 
with this browser-support could indeed work too (not sure if it is enough though because it only allows udev access to /dev/video but not to /sys/class/video4linux)
Yeah it’s not enough - I had enabled it initially when I found that v4l2 reference.
The interface seems to be “access to cameras through a variety of APIs”, where that currently means video4linux plus some extra VideoCore access that seems to be Raspberry Pi specific. Presumably if people needed access to yet another camera capture API (Firewire access for dvgrab?) it would be added to this interface.
Of course, the interface does nothing to distinguish camera and non-camera V4L devices (e.g. mem2mem codecs, TV tuners, etc). It’s not clear such filtering will ever be added, so it is probably the right choice for apps needing access to non-camera V4L devices despite its name.
Long term, I suspect we’ll probably see camera access for most desktop apps migrate to PipeWire, with just-in-time decisions about access to specific hardware rather than ahead of time interface connection.
The camera interface started as something for the camera and evolved into camera-like things like capture since, as mentioned, there isn’t a way to split things up easily, especially on ARM. We knew that camera was a bit of a transitional interface because it also allows access to all cameras, not specific ones (it hasn’t been converted to hotplug yet). As mentioned, with the cleaner implementation of pipewire (from a sandboxing point of view), we can probably be more specific and perhaps have concepts of record/grab vs playback like we do with pulseaudio and audio-record/audio-playback.