query/set parameters/controls from GST pipeline

Kieran Bingham kieran.bingham at ideasonboard.com
Wed Mar 6 10:41:21 CET 2024


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