Can the identity plugin cause frame drop?

pisymbol . pisymbol at gmail.com
Tue Jul 9 01:56:04 UTC 2019


On Mon, Jul 8, 2019 at 9:15 PM pisymbol . <pisymbol at gmail.com> wrote:

>
>
> On Mon, Jul 8, 2019 at 9:07 PM pisymbol . <pisymbol at gmail.com> wrote:
>
>>
>>
>> On Mon, Jul 8, 2019 at 8:47 PM Michael Gruner <
>> michael.gruner at ridgerun.com> wrote:
>>
>>> The handoff will be emitted for every buffer and won’t drop buffers.
>>> Recall, however, that signals block. I suspect that you have an indirect
>>> buffer drop on nvcamerasrc.
>>>
>>> Nvcamera src has an internal (limited) buffer queue. If you block the
>>> processing on the signal callback for too long, the queue will start
>>> filling up and, eventually, drop buffers. I believe that you can increase
>>> this queue size a lot, but if your signal processing takes more than 33ms
>>> (assuming a 30fps capture), eventually you’ll end up losing buffers in the
>>> same way.
>>>
>>> Make sure the processing your are doing on the callback actually is
>>> below your period deadline. If it’s below, but high, I recommend adding a
>>> queue after the identity to split processing in different threads.
>>>
>>
>> Michael, after the identity? Not before?
>>
>>
> Just to clarify: I'm seeing a drop I guess in nvcamerasrc since my
> identity signal callback ("handoff") is dumping the frame numbers per buf
> and that's where I see what appears to be drops/gaps between them.
>
> -aps
>

Note that:

nvcamerasrc queue-size=50 ... ! queue max-size-buffers=2000 ! identity
name=tap ! ...

still results in drops! My avg runtime per signal callback is ~40-50ms
right now (that includes the overhead of calling time.time() twice and
appending it to a list).

-aps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190708/49ca16fb/attachment.html>


More information about the gstreamer-devel mailing list