<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le jeu. 22 sept. 2022, 09 h 45, Louis-Antoine Blais-Morin via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-CA" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="m_-4283038939439128183WordSection1">
<p class="MsoNormal"><span lang="FR-CA">Hi,<u></u><u></u></span></p>
<p class="MsoNormal"><span lang="FR-CA"><u></u> <u></u></span></p>
<p class="MsoNormal">We are working on an application where the pipeline is configured as follow:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">v4l2src ! capsfilter caps=[…] ! tee name=t ! appsink ! t. [remaining of pipeline not important for this discussion]<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The v4l2src video source uses DMABUF acquisition, which is great to reduce memory copies.<u></u><u></u></p>
<p class="MsoNormal">However, to completely prevent memory copies, the buffer pool in v4l2src should have enough buffers available for the v4l2 driver while acquired buffers are sent to the downstream elements.<u></u><u></u></p>
<p class="MsoNormal">If I understand correctly, the number of buffers in the v4l2src buffer pool is decided (amongst other things) according to the GST_QUERY_ALLOCATION query response to the downstream elements. The downstream elements could inform the upstream
 v4l2src of their needs (for example, if they need to keep references to the acquired buffers).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Here is where things get complicated: our application keeps references on many buffers sent to the app via appsink. The application needs to have some short time history of the buffers. We allowed the app to keep references to a fixed number
 of buffers. As far as I investigated, there seems to be no way for the appsink to inform the upstream elements (v4l2src) about this fact, via GST_QUERY_ALLOCATION reply or via other means.</p></div></div></blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-CA" link="#0563C1" vlink="#954F72" style="word-wrap:break-word"><div class="m_-4283038939439128183WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">My question:<u></u><u></u></p>
<p class="MsoNormal">What is the best way to configure the v4l2src to allocate a pool with a larger number of buffers?<u></u><u></u></p>
<p class="MsoNormal">Is it possible via a reply to GST_QUERY_ALLOCATION from the downstream appsink (or other)?</p></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">You can and should implement the allocation query using a pad probe. You probably want to expose the videometa support, and set a minimum number of buffers, be aware that the pool pointer can be left to null. Have a look at kmscube software for some examples (only the meta though).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-CA" link="#0563C1" vlink="#954F72" style="word-wrap:break-word"><div class="m_-4283038939439128183WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal">Is there a hidden way to configure the v42lsrc buffer pool size directly?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thanks<u></u><u></u></p>
</div>
</div>

</blockquote></div></div></div>