<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">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 style="overflow-wrap: break-word;">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, I am seeing duplicate frames which I suspect is the in-drect frame drop issue you spoke about above. Here is my exact pipeline:</div><div><br></div><div>matroskamux name=muxer streamable=true ! multifilesink name=mfsink post-messages=true next-file=5 max-file-duration=\"{}\" location=\"{}\"<br>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<br>! video/x-raw(memory:NVMM), width=(int)4104, height=(int)3046, format=(string)I420, framerate=(fraction)30/1<br>! nvvidconv flip-method=2 ! video/x-raw(memory:NVMM), width=(int)3840, height=(int)2160, format=(string)I420<br>! omxh264enc bitrate=30000000 ! video/x-h264, stream-format=(string)byte-stream ! h264parse ! muxer.video_0<br>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<br>! video/x-raw(memory:NVMM), width=(int)4104, height=(int)3046, format=(string)I420, framerate=(fraction)30/1<br>! nvvidconv flip-method=2 ! video/x-raw(memory:NVMM), width=(int)3840, height=(int)2160, format=(string)I420<br>! omxh264enc bitrate=30000000 ! video/x-h264, stream-format=(string)byte-stream ! h264parse ! muxer.video_1</div><div><br></div><div>where max-file-duration is 60seconds and location is calculated at run-time.</div><div><br></div><div>Both tap0 and tap1's "handoff" callback take almost nothing in terms of time:<br></div><div><br></div><div>2019-07-29 15:22:53,224 INFO: 0: 0.011405869294668882s<br>2019-07-29 15:22:53,224 INFO: 1: 0.010900382847748986s</div><div><br></div><div>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).<br></div><div><br></div><div>Yet I still see duplicate frames when I frame it out (a bit of chop during motion).</div><div><br></div>I tried adding a "queue" after "nvcamerasrc" and that did nothing which even has me more confuzzled?<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>-aps<br> </div></div></div>