[Libav-user] avcodec_receive_frame returns duplicate buffers.

[Devin Heitmueller]

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