<div dir="ltr"><div><br></div><div>That would have the drawback of not being able to become real time as you will always be processing with some latency, that latency is equal to your queued buffer, am I right?</div><br clear="all"><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr">Best Regards,<br>Eslam Ahmed</div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 15, 2021 at 10:15 AM keith Thornton via gstreamer-devel <<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</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">Hi,<br>
<br>
I have used min-threshold (buffers, time, bytes) together with the<br>
max-size parameters, for the purpose of keeping the last 5 minutes of<br>
video. I used them together with the  leaky parameter. This maintained<br>
the last five minutes in the buffer. If I wanted to save them to disk I<br>
then set the threshold parameters down to a minimum.<br>
<br>
Grüße<br>
<br>
Am 15.11.2021 um 08:01 schrieb Marianna Smidth Buschle via gstreamer-devel:<br>
> This isn't something I have ever tried.<br>
><br>
> But what about the min-threshold-buffers and similar properties of the<br>
> queue?<br>
> Can't they be used to require that this amount of data is inside the<br>
> queue?<br>
><br>
> On 14.11.2021 13.00, <a href="mailto:gstreamer-devel-request@lists.freedesktop.org" target="_blank">gstreamer-devel-request@lists.freedesktop.org</a> wrote:<br>
>> Hi,<br>
>><br>
>> In the spirit of joining your discussion,<br>
>><br>
>>     - What makes you think that these queues will always have the<br>
>> amount of<br>
>>     buffers that you require at some point? Aren't you just setting<br>
>> their<br>
>>     maximum limit?<br>
>><br>
>> On the other hand, I would like to know if your method would work<br>
>> because I<br>
>> have tackled this problem via a totally different approach.<br>
>> The idea is to have 2 pipelines. One acting as the trigger, with just<br>
>> the<br>
>> inference plugin, and whenever it finds something interesting it signals<br>
>> the other application, via a method of your choice, controlling the<br>
>> second<br>
>> pipeline. This second pipeline is running concurrently with the first<br>
>> and<br>
>> using an appsink as its sink, you will be able to retain some of the<br>
>> frames<br>
>> in a data structure queue of a size of your choice. Once signalled, the<br>
>> second pipeline would trigger a new on-demand pipeline with an appsrc<br>
>> just<br>
>> to write/record the event.<br>
>><br>
>> Here's my post on stackoverflow to get the full idea:<br>
>> <a href="https://stackoverflow.com/questions/68066985/how-to-write-specific-time-interval-of-gstsamples-rtp-over-udp-h264-packets" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/68066985/how-to-write-specific-time-interval-of-gstsamples-rtp-over-udp-h264-packets</a><br>
>><br>
>><br>
>> Hope that helps!<br>
>><br>
>> Best Regards,<br>
>> Eslam Ahmed<br>
><br>
</blockquote></div>