query/set parameters/controls from GST pipeline

[Kieran Bingham]

Quoting Joel Winarske (2024-03-09 01:57:17)
> I made some progress on PipeWire libcamera SPA thanks to George:
> ```
> 
> 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 libcamera_input.* nodes in wpctl
> status -n, under Video -> Sources.
> 
> Use pw-dump libcamera_input... to list the properties and control of each
> such node.
> 
> Use gst-launch-1.0 pipewiresrc target-object="libcamera_input..." !
> autovideosink to test capture.
> ```
> libcamera SPA debug is available using:  WIREPLUMBER_DEBUG="3:spa.libcamera*"
> wireplumber
> 
> 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`:
> 
> ...
>       "params": {
>         "PropInfo": [
>           {
>             "id": "device",
>             "description": "The libcamera device",
>             "type": "\\_SB_.PCI0.GP17.XHC0.RHUB.PRT1-1.4.1:1.0-046d:0892"
>           },
>           {
>             "id": "deviceName",
>             "description": "The libcamera device name",
>             "type": ""
>           },
>           {
>             "id": "exposure",
>             "description": "ExposureTime",
>             "type": { "default": 25000, "min": 300, "max": 204700 }
>           },
>           {
>             "id": "gain",
>             "description": "AnalogueGain",
>             "type": { "default": 1.000000, "min": 1.000000, "max": 4.000000
> }
>           },
>           {
>             "id": "id-01000001",
>             "description": "AeEnable",
>             "type": {
>               "default": true,
>               "alt1": true,
>               "alt2": false
>             }
>           },
>           {
>             "id": "saturation",
>             "description": "Saturation",
>             "type": { "default": 1.000000, "min": 0.000000, "max": 1.992188
> }
>           },
>           {
>             "id": "contrast",
>             "description": "Contrast",
>             "type": { "default": 1.000000, "min": 0.500000, "max": 1.496094
> }
>           },
>           {
>             "id": "brightness",
>             "description": "Brightness",
>             "type": { "default": 0.000000, "min": -1.000000, "max":
> 0.992188 }
>           }
>         ],
> 
> ...
> 
> It would be good to mention the use of pipewiresrc + libcamera in the docs
> somewhere.

This would be really good to document somewhere, but I'm not sure
/where/. Pipewire and the pipewire libcamera-spa are not a component of
libcamera.

It could be more generic/helpful documentation to add about using a
camera somewhere ... but we don't erally have a starting point there
yet.

Any ideas?

--
Kieran

> 
> On Wed, Mar 6, 2024 at 1:41 AM Kieran Bingham <
> kieran.bingham at ideasonboard.com> wrote:
> 
> > Quoting Joel Winarske (2024-03-06 01:34:32)
> > > Okay, that's great info.  Thanks Nicolas!
> > >
> > > I see the spa trajectory, and I like it.
> > >
> > > George what's your take, is the libcamera spa likely to deprecate the
> > > `libcamerasrc` plugin?
> >
> > They serve two separate roles.
> >
> > gstlibcamerasrc provides libcamera integration to gstreamer. libcamera
> > spa provides direct integration for libcamera to pipewire...
> >
> > Gstreamer can be used without pipewire, and pipewire can be used without
> > gstreamer, so two implementations are necessary IMO. (And I expect they
> > may have different ways to handle the feature sets).
> >
> > --
> > Kieran
> >
> > > Cheers,
> > > Joel
> > >
> > > On Tue, Mar 5, 2024 at 2:53 PM Nicolas Dufresne <nicolas at ndufresne.ca>
> > > wrote:
> > >
> > > > Hey,
> > > >
> > > > Le mar. 5 mars 2024, 15 h 27, Joel Winarske <joel.winarske at gmail.com>
> > a
> > > > écrit :
> > > >
> > > >>
> > > >> > I can assist with building a cpp tool that transforms
> > > >>> src/libcamera/control_ids.yaml into
> > src/gstreamer/gstlibcamera-controls*.
> > > >>>
> > > >>> That would be more then welcome !
> > > >>>
> > > >>
> > > >> Cool.  I'll start looking into it.
> > > >>
> > > >>
> > > >>> This is a different approach from the upstream pipewire approach. It
> > will
> > > >>> certainly yield higher latency, but then you got a more usable buffer
> > > >>> lifetime
> > > >>> policy. Let us know the outcome for the "node control", this is
> > still an
> > > >>> open
> > > >>> question in regard to the in-pipewire libcamerasrc node. There was
> > also
> > > >>> open
> > > >>> questions upon if a node control can cause the number of ports to
> > > >>> dynamically
> > > >>> change.
> > > >>>
> > > >>
> > > >> This approach came from George (WirePlumber); context is complex
> > Camera
> > > >> graphs.  What upstream approach are you referring to?
> > > >>
> > > >
> > > > There is a spa plug-in that can provide cameras in the same way audio
> > > > device are made available.
> > > >
> > > >>
> > > >
> > > >
> > https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/master/spa/plugins/libcamera?ref_type=heads
> > > >
> > > > Most of my discussions so far with upstream devs has been around this
> > > > implementation. It implements a slightly broken buffer lifetime policy
> > and
> > > > is missing the ability to configure more ports.
> > > >
> > > > Having a daemon like bluez could also be an option, that is open for
> > > > research.
> > > >
> > > > regards,
> > > > Nicolas
> > > >
> >