<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 2, 2019 at 1:18 PM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca">nicolas@ndufresne.ca</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">Le vendredi 02 août 2019 à 09:00 -0400, pisymbol . a écrit :<br>
> <br>
> <br>
> On Fri, Aug 2, 2019, 7:51 AM Nicolas Dufresne <<a href="mailto:nicolas@ndufresne.ca" target="_blank">nicolas@ndufresne.ca</a>> wrote:<br>
> > Le vendredi 02 août 2019 à 06:45 -0400, pisymbol . a écrit :<br>
> > > Nicolas:<br>
> > > <br>
> > > Can you please please pretty please answer me the following questions:<br>
> > > <br>
> > > 1) Would you expect the number of I420 frames to be equal to the H.264 ones?<br>
> > > <br>
> > > i.e. nvcamerasrc ! identity name=count420 ! blah ! omxh264dec ! h264parse ! identity name=count264 ! mux out...<br>
> > > <br>
> > > Again: Would you expect the number of "handoff" calls to be equal between the two identity plugins above?<br>
> > <br>
> > <br>
> > For most cases it should. There exist of course corner cases, when<br>
> > omxh264dec qos property is on, frames could be dropped at the input to<br>
> > ensure real-time operation. On very ancient gst-omx, I'm pretty sure<br>
> > there is random miss-behaviour.<br>
> <br>
> What's ancient? I assume 1.8+ is not.<br>
<br>
In term of gst-omx, 1.8 is pretty ancient, most of the recent work<br>
landed in 1.16. I still don't understand why people keep using OMX<br>
though.<br></blockquote><div><br></div><div>So I can talk to you! What do you suggest then?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > > 2) In the above pipeline would you expect the number of frames counted by "count264" equal the number of frames muxed to a multifilesink? i.e. a 1-to-1 match between frames IN the file and frames caught by identity "count264"?<br>
> > > <br>
> > > The problem I am seeing is that on stopping the pipeline, it looks like a few frames hit my handoff callback that don't make it out to the muxer and subsequently in the file stream. Is this because stopping is asynchronous, i.e. some frames hit handoff but never made it out to the muxer because the element is shutting down? Is there an idiom where I can guarantee a 1-to-1 match between number of frames that hit "handoff" vs number of frames that make it into the stream?<br>
> > <br>
> > Looks like a bad "drain/finish" implementation. It's possibly an OMX<br>
> > implementation issue though, please report to NVidia as this bit is<br>
> > proprietary, hence cannot be fixed by if broken.<br>
> <br>
> Could be. Does multifilesink drop any frames if you use max-file-duration? i.e. I assume splitting every 60s shouldn't inherit frame loss. However, there is a thread somewhere in the NVidia forums that claims we need to use splitmuxsink instead?<br>
<br>
Splitmux sink is a better choice yes. But in theory there should be no<br>
lost caused by this sink, it mean yield an invalid file though.<br>
</blockquote><div><br></div><div>Yes, and I do plan to use that. I was looking at it today. This pipeline I inherited.</div><div><br></div><div>-aps <br></div></div></div>