<div dir="ltr"><div>Okay, that's great info.  Thanks Nicolas!<br></div><div><br>I see the spa trajectory, and I like it.<br><br></div><div>George what's your take, is the libcamera spa likely to deprecate the `libcamerasrc` plugin?<br><br></div><div>Cheers,</div><div>Joel<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 5, 2024 at 2:53 PM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca">nicolas@ndufresne.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Hey,<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 5 mars 2024, 15 h 27, Joel Winarske <<a href="mailto:joel.winarske@gmail.com" target="_blank">joel.winarske@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> I can assist with building a cpp tool that transforms src/libcamera/control_ids.yaml into src/gstreamer/gstlibcamera-controls*.<br>
<br>
That would be more then welcome !<br></blockquote><div><br></div><div>Cool.  I'll start looking into it.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This is a different approach from the upstream pipewire approach. It will<br>
certainly yield higher latency, but then you got a more usable buffer lifetime<br>
policy. Let us know the outcome for the "node control", this is still an open<br>
question in regard to the in-pipewire libcamerasrc node. There was also open<br>
questions upon if a node control can cause the number of ports to dynamically<br>
change.<br></blockquote><div><br></div><div>This approach came from George (WirePlumber); context is complex Camera graphs.  What upstream approach are you referring to?<br></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">There is a spa plug-in that can provide cameras in the same way audio device are made available.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><a href="https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/master/spa/plugins/libcamera?ref_type=heads" target="_blank">https://gitlab.freedesktop.org/pipewire/pipewire/-/tree/master/spa/plugins/libcamera?ref_type=heads</a></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Having a daemon like bluez could also be an option, that is open for research.</div><div dir="auto"><br></div><div dir="auto">regards,</div><div dir="auto">Nicolas</div></div>
</blockquote></div>