Thanks Devin, Your comment about the kernel buffers makes sense as there are only 8 addresses that turn up as being reused in my debug output. There is some memory copying going on, because I only occasionally get duplicate buffers, even through there are 900 frames stored in my 30s ring-buffer.
I have fixed / worked around this issue by allocating new buffers and copying the frame contents (av_get_buffer + av_frame_copy) just after the avcodec_receive_frame. Regards, Hugh On Mon, 26 Aug 2019 at 16:03, Devin Heitmueller <[email protected]> wrote: > Hi Hugh, > > > I have an application that decodes an input stream into AVFrames and > stores these in a ring buffer. On a trigger, I can create an output file > containing video from the past N seconds until I stop. > > I am seeing a problem with the output video that it sometimes contains > duplicate frames and sometimes contains frames from "the future" (i.e. the > wrong point in the ringbuffer). I have added debug and it appears that > avcodec_receive_frame() sometimes returns the same data buffer for multiple > decoded frames, even though I have not unref'ed the previous AVFrame. > > Specifically I am checking that the returned av_frame->data[0] is not > being used by any other AVFrames and this is failing. > > Just a couple of observations which might point you in the right > direction... > > So I am not an expert on the specifics of libavdevice's implementation > for v4l2, but I did take a quick look at the code (and I've worked on > plenty of other v4l2 based apps over the years). In order to avoid > memory copies, the avpackets data[0] points to the underlying mmap'd > buffer provided by the kernel. In other words data[0] will only ever > point to a small number of specific memory addresses (e.g. actual > number dependent on the specific v4l2 device, but somewhere between 3 > to 8 is typical). This is generally a good thing, but if your > reference counter is screwed up then you will see results similar to > where you described since the buffers will be reused by the driver as > soon as they are released. > > What decoder are you using? If it's one that involves no format or > colorspace conversion, I wouldn't be shocked to find that it just > unwraps the AVPacket into an AVFrame and references the same > underlying buffer. I would probably start by looking there and see > what gets done with the reference counting within the decoder. > > In cases like this I've also found it helpful to be feeding video with > some form of on-screen timecode or incrementing frame counter. That > makes it much more easy to spot out-of-order issues which might be > less obvious with real video. > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > _______________________________________________ > Libav-user mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/libav-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe".
_______________________________________________ Libav-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/libav-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
