<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2019 at 9:56 PM pisymbol . <<a href="mailto:pisymbol@gmail.com">pisymbol@gmail.com</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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2019 at 9:15 PM pisymbol . <<a href="mailto:pisymbol@gmail.com" target="_blank">pisymbol@gmail.com</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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2019 at 9:07 PM pisymbol . <<a href="mailto:pisymbol@gmail.com" target="_blank">pisymbol@gmail.com</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"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2019 at 8:47 PM Michael Gruner <<a href="mailto:michael.gruner@ridgerun.com" target="_blank">michael.gruner@ridgerun.com</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"><div>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.<div><br></div><div>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.</div><div><br></div><div>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. </div></div></blockquote><div><br></div><div>Michael, after the identity? Not before?</div><br></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>-aps<br></div></div></div></blockquote><div><br></div><div>Note that:</div><div><br></div><div>nvcamerasrc queue-size=50 ... ! queue max-size-buffers=2000 ! identity name=tap ! ...</div><div><br></div><div>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).<br></div><br></div></div></blockquote><div><br></div><div>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):<br></div><div><br></div><div>259<br>300<br>302<br>299<br>299<br>300<br>298</div><div><br></div><div>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?<br></div><div><br></div><div>But the number of frames looks fairly consistent and within range.<br></div><div><br></div><div>-aps<br> </div></div></div>