query/set parameters/controls from GST pipeline
Kieran Bingham
kieran.bingham at ideasonboard.com
Mon Mar 11 13:13:37 CET 2024
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
> > > >
> >
More information about the libcamera-devel
mailing list