Can the identity plugin cause frame drop?

[pisymbol .]

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, I am seeing duplicate frames which I suspect is the in-drect frame
drop issue you spoke about above. Here is my exact pipeline:

matroskamux name=muxer streamable=true ! multifilesink name=mfsink
post-messages=true next-file=5 max-file-duration=\"{}\" location=\"{}\"
nvcamerasrc do-timestamp=true enable-meta=true fpsRange="30.0 30.0"
auto-exposure=1 aeLock=true sensor_id=0 name=nvcam0 ! identity name=tap0
! video/x-raw(memory:NVMM), width=(int)4104, height=(int)3046,
format=(string)I420, framerate=(fraction)30/1
! nvvidconv flip-method=2 ! video/x-raw(memory:NVMM), width=(int)3840,
height=(int)2160, format=(string)I420
! omxh264enc bitrate=30000000 ! video/x-h264,
stream-format=(string)byte-stream ! h264parse ! muxer.video_0
nvcamerasrc do-timestamp=true enable-meta=true fpsRange="30.0 30.0"
auto-exposure=1 aeLock=true sensor_id=1 name=nvcam1 ! identity name=tap1
! video/x-raw(memory:NVMM), width=(int)4104, height=(int)3046,
format=(string)I420, framerate=(fraction)30/1
! nvvidconv flip-method=2 ! video/x-raw(memory:NVMM), width=(int)3840,
height=(int)2160, format=(string)I420
! omxh264enc bitrate=30000000 ! video/x-h264,
stream-format=(string)byte-stream ! h264parse ! muxer.video_1

where max-file-duration is 60seconds and location is calculated at run-time.

Both tap0 and tap1's "handoff" callback take almost nothing in terms of
time:

2019-07-29 15:22:53,224 INFO: 0: 0.011405869294668882s
2019-07-29 15:22:53,224 INFO: 1: 0.010900382847748986s

So that's ~11ms. That's WAY before the 33ms deadline. (this is expected
since the callback just copies in some memory, pointer derefs essentially,
and returns).

Yet I still see duplicate frames when I frame it out (a bit of chop during
motion).

I tried adding a "queue" after "nvcamerasrc" and that did nothing which
even has me more confuzzled?

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