[PATCH] gst: provider: Do not hide v4l2deviceprovider

Nicolas Dufresne nicolas at ndufresne.ca
Tue May 7 21:00:21 CEST 2024


Le lundi 06 mai 2024 à 20:56 +0000, Barnabás Pőcze a écrit :
> Hi
> 
> 
> 2024. május 6., hétfő 21:51 keltezéssel, Nicolas Dufresne <nicolas at ndufresne.ca> írta:
> 
> > Le lundi 06 mai 2024 à 21:38 +0300, Laurent Pinchart a écrit :
> > > On Mon, May 06, 2024 at 08:03:53PM +0530, Umang Jain wrote:
> > > > Hi Hou Qi

[...]

> > > > 
> > 
> > Do you have links to that ? I was not ware that you could mix v4l2 and libcamera
> > in pipewire today.
> 
> I believe it was always possible. The only recent thing is camera de-duplication,
> which was introduced in wireplumber not so long ago:
> 
>   https://gitlab.freedesktop.org/pipewire/wireplumber/-/merge_requests/525

Didn't know, thanks. They coded knowledge of this in a central place, a place we
don't have in GStreamer. The monitor is completely agnostic code (it does not
even know the difference between audio/video or GPU devices). Though, what we
can do is filtering in each implementation.

I think the solution is to split the work between libcamera and v4l2 providers.
In short, libcamera should only expose MC centric devices and v4l2 provider
should filter out any MC centric devices.

In short, anything MC centric shall be ignored from v4l2src, its something I
wanted to do anyway, since using v4l2 video device (which imho should not have
been video devices to avoid confusion) without configuring the MC just bugs out
and break generic software. So v4l2src will pick UVC devices and non-MC centric
device (device with a static MC pipeline like most hdmi capture).

Then libcamera provider will filter out UVC, which I think is the only non-MC
centric device supported, and offer all the ISP or MC centric devices.

Finally, pipewire provider will mask both libcamera and v4l2 provider, cause its
expected to be a superset, and we expect software to use that so the software
can work inside a sandbox like flatpak.

So here's my take as maintainer of both component, if you can redo this M with
the proposed filtering and make a matching MR against GStreamer, I'm ready to
accept. In libcamera, you will have to only enable this new code for the version
of GStreamer your gstv4l2 changes hits, so we'll need to coordinate. The
existing behaviour will have to remain meanwhile.

Nicolas


More information about the libcamera-devel mailing list