[Libav-user] avcodec_receive_frame returns duplicate buffers.

[Hugh Waite]

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 <dheitmueller at kernellabs.com>
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
> Libav-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/libav-user
>
> To unsubscribe, visit link above, or email
> libav-user-request at ffmpeg.org with subject "unsubscribe".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20190902/eaa4722b/attachment.html>