Can the identity plugin cause frame drop?

[pisymbol .]

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

>
>
> 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).
>
>
Well, I kinda take that back. Here is the total number of frames I collect
in my signal callback on a 10s basis (max-file-duration=10s):

259
300
302
299
299
300
298

That's the number of frames I see at 30fps at 10s intervals. Looks pretty
good actually. What's throwing me off is that the nvcamerasrc metadata is
not specifying the frame numbers as 0,1,2,3 order, i.e. sometimes it skips
a frame_num which I interpret as a drop? Maybe it isn't?

But the number of frames looks fairly consistent and within range.

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