The identity plugin not being called per frame?

[pisymbol .]

On Fri, Aug 2, 2019 at 1:18 PM Nicolas Dufresne <nicolas at ndufresne.ca>
wrote:

> Le vendredi 02 août 2019 à 09:00 -0400, pisymbol . a écrit :
> >
> >
> > On Fri, Aug 2, 2019, 7:51 AM Nicolas Dufresne <nicolas at ndufresne.ca>
> wrote:
> > > Le vendredi 02 août 2019 à 06:45 -0400, pisymbol . a écrit :
> > > > Nicolas:
> > > >
> > > > Can you please please pretty please answer me the following
> questions:
> > > >
> > > > 1) Would you expect the number of I420 frames to be equal to the
> H.264 ones?
> > > >
> > > > i.e. nvcamerasrc ! identity name=count420 ! blah ! omxh264dec !
> h264parse ! identity name=count264 ! mux out...
> > > >
> > > > Again: Would you expect the number of "handoff" calls to be equal
> between the two identity plugins above?
> > >
> > >
> > > For most cases it should. There exist of course corner cases, when
> > > omxh264dec qos property is on, frames could be dropped at the input to
> > > ensure real-time operation. On very ancient gst-omx, I'm pretty sure
> > > there is random miss-behaviour.
> >
> > What's ancient? I assume 1.8+ is not.
>
> In term of gst-omx, 1.8 is pretty ancient, most of the recent work
> landed in 1.16. I still don't understand why people keep using OMX
> though.
>

So I can talk to you! What do you suggest then?

> > > 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"?
> > > >
> > > > 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?
> > >
> > > Looks like a bad "drain/finish" implementation. It's possibly an OMX
> > > implementation issue though, please report to NVidia as this bit is
> > > proprietary, hence cannot be fixed by if broken.
> >
> > 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?
>
> Splitmux sink is a better choice yes. But in theory there should be no
> lost caused by this sink, it mean yield an invalid file though.
>

Yes, and I do plan to use that. I was looking at it today. This pipeline I
inherited.

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