query/set parameters/controls from GST pipeline

[Joel Winarske]

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?

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/20240305/167e6fee/attachment.htm>