<div dir="ltr">I made some progress on PipeWire libcamera SPA thanks to George:<br><div>```</div><div><p dir="auto">In your distribution, make sure you have the libcamera plugin for pipewire installed, then restart wireplumber. The libcamera plugin is automatically loaded there and you should be able to see the <code>libcamera_input.*</code> nodes in <code>wpctl status -n</code>, under <code>Video -> Sources</code>.</p>
<p dir="auto">Use <code>pw-dump libcamera_input...</code> to list the properties and control of each such node.</p>
<p dir="auto">Use <code>gst-launch-1.0 pipewiresrc target-object="libcamera_input..." ! autovideosink</code> to test capture.<br></p></div><div>```<br></div><div>libcamera SPA debug is available using:  <code>WIREPLUMBER_DEBUG="3:spa.libcamera*" wireplumber</code></div><p>As an example for available properties using a Logitech 1080P USB camera, the trimmed output of `pw-dump \_SB_.PCI0.GP17.XHC0.RHUB.PRT1-1.4.1:1.0-046d:0892`:<br></p><p>...<br>      "params": {<br>        "PropInfo": [<br>          {<br>            "id": "device",<br>            "description": "The libcamera device",<br>            "type": "\\_SB_.PCI0.GP17.XHC0.RHUB.PRT1-1.4.1:1.0-046d:0892"<br>          },<br>          {<br>            "id": "deviceName",<br>            "description": "The libcamera device name",<br>            "type": ""<br>          },<br>          {<br>            "id": "exposure",<br>            "description": "ExposureTime",<br>            "type": { "default": 25000, "min": 300, "max": 204700 }<br>          },<br>          {<br>            "id": "gain",<br>            "description": "AnalogueGain",<br>            "type": { "default": 1.000000, "min": 1.000000, "max": 4.000000 }<br>          },<br>          {<br>            "id": "id-01000001",<br>            "description": "AeEnable",<br>            "type": {<br>              "default": true,<br>              "alt1": true,<br>              "alt2": false<br>            }<br>          },<br>          {<br>            "id": "saturation",<br>            "description": "Saturation",<br>            "type": { "default": 1.000000, "min": 0.000000, "max": 1.992188 }<br>          },<br>          {<br>            "id": "contrast",<br>            "description": "Contrast",<br>            "type": { "default": 1.000000, "min": 0.500000, "max": 1.496094 }<br>          },<br>          {<br>            "id": "brightness",<br>            "description": "Brightness",<br>            "type": { "default": 0.000000, "min": -1.000000, "max": 0.992188 }<br>          }<br>        ],</p><p>...</p><p>It would be good to mention the use of pipewiresrc + libcamera in the docs somewhere.<br></p></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 6, 2024 at 1:41 AM Kieran Bingham <<a href="mailto:kieran.bingham@ideasonboard.com">kieran.bingham@ideasonboard.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Quoting Joel Winarske (2024-03-06 01:34:32)<br>
> Okay, that's great info.  Thanks Nicolas!<br>
> <br>
> I see the spa trajectory, and I like it.<br>
> <br>
> George what's your take, is the libcamera spa likely to deprecate the<br>
> `libcamerasrc` plugin?<br>
<br>
They serve two separate roles.<br>
<br>
gstlibcamerasrc provides libcamera integration to gstreamer. libcamera<br>
spa provides direct integration for libcamera to pipewire...<br>
<br>
Gstreamer can be used without pipewire, and pipewire can be used without<br>
gstreamer, so two implementations are necessary IMO. (And I expect they<br>
may have different ways to handle the feature sets).<br>
<br>
--<br>
Kieran<br>
<br>
> Cheers,<br>
> Joel<br>
> <br>
> On Tue, Mar 5, 2024 at 2:53 PM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" target="_blank">nicolas@ndufresne.ca</a>><br>
> wrote:<br>
> <br>
> > Hey,<br>
> ><br>
> > Le mar. 5 mars 2024, 15 h 27, Joel Winarske <<a href="mailto:joel.winarske@gmail.com" target="_blank">joel.winarske@gmail.com</a>> a<br>
> > écrit :<br>
> ><br>
> >><br>
> >> > I can assist with building a cpp tool that transforms<br>
> >>> src/libcamera/control_ids.yaml into src/gstreamer/gstlibcamera-controls*.<br>
> >>><br>
> >>> That would be more then welcome !<br>
> >>><br>
> >><br>
> >> Cool.  I'll start looking into it.<br>
> >><br>
> >><br>
> >>> This is a different approach from the upstream pipewire approach. It will<br>
> >>> certainly yield higher latency, but then you got a more usable buffer<br>
> >>> lifetime<br>
> >>> policy. Let us know the outcome for the "node control", this is still an<br>
> >>> open<br>
> >>> question in regard to the in-pipewire libcamerasrc node. There was also<br>
> >>> open<br>
> >>> questions upon if a node control can cause the number of ports to<br>
> >>> dynamically<br>
> >>> change.<br>
> >>><br>
> >><br>
> >> This approach came from George (WirePlumber); context is complex Camera<br>
> >> graphs.  What upstream approach are you referring to?<br>
> >><br>
> ><br>
> > There is a spa plug-in that can provide cameras in the same way audio<br>
> > device are made available.<br>
> ><br>
> >><br>
> ><br>
> > <a href="https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/master/spa/plugins/libcamera?ref_type=heads" rel="noreferrer" target="_blank">https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/master/spa/plugins/libcamera?ref_type=heads</a><br>
> ><br>
> > Most of my discussions so far with upstream devs has been around this<br>
> > implementation. It implements a slightly broken buffer lifetime policy and<br>
> > is missing the ability to configure more ports.<br>
> ><br>
> > Having a daemon like bluez could also be an option, that is open for<br>
> > research.<br>
> ><br>
> > regards,<br>
> > Nicolas<br>
> ><br>
</blockquote></div>