query/set parameters/controls from GST pipeline

[Joel Winarske]

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.

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
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20240308/c12e1baa/attachment.htm>