<div dir="ltr">Thanks Devin,<div>Your comment about the kernel buffers makes sense as there are only 8 addresses that turn up as being reused in my debug output.</div><div>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.</div><br class="gmail-Apple-interchange-newline"><div>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.</div><div><br></div><div>Regards,<br></div><div>Hugh</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 26 Aug 2019 at 16:03, Devin Heitmueller <<a href="mailto:dheitmueller@kernellabs.com">dheitmueller@kernellabs.com</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">Hi Hugh,<br>
<br>
> 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.<br>
> 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.<br>
> Specifically I am checking that the returned av_frame->data[0] is not being used by any other AVFrames and this is failing.<br>
<br>
Just a couple of observations which might point you in the right direction...<br>
<br>
So I am not an expert on the specifics of libavdevice's implementation<br>
for v4l2, but I did take a quick look at the code (and I've worked on<br>
plenty of other v4l2 based apps over the years).  In order to avoid<br>
memory copies, the avpackets data[0] points to the underlying mmap'd<br>
buffer provided by the kernel.  In other words data[0] will only ever<br>
point to a small number of specific memory addresses (e.g. actual<br>
number dependent on the specific v4l2 device, but somewhere between 3<br>
to 8 is typical).  This is generally a good thing, but if your<br>
reference counter is screwed up then you will see results similar to<br>
where you described since the buffers will be reused by the driver as<br>
soon as they are released.<br>
<br>
What decoder are you using?  If it's one that involves no format or<br>
colorspace conversion, I wouldn't be shocked to find that it just<br>
unwraps the AVPacket into an AVFrame and references the same<br>
underlying buffer.  I would probably start by looking there and see<br>
what gets done with the reference counting within the decoder.<br>
<br>
In cases like this I've also found it helpful to be feeding video with<br>
some form of on-screen timecode or incrementing frame counter.  That<br>
makes it much more easy to spot out-of-order issues which might be<br>
less obvious with real video.<br>
<br>
Devin<br>
<br>
-- <br>
Devin J. Heitmueller - Kernel Labs<br>
<a href="http://www.kernellabs.com" rel="noreferrer" target="_blank">http://www.kernellabs.com</a><br>
_______________________________________________<br>
Libav-user mailing list<br>
<a href="mailto:Libav-user@ffmpeg.org" target="_blank">Libav-user@ffmpeg.org</a><br>
<a href="https://ffmpeg.org/mailman/listinfo/libav-user" rel="noreferrer" target="_blank">https://ffmpeg.org/mailman/listinfo/libav-user</a><br>
<br>
To unsubscribe, visit link above, or email<br>
<a href="mailto:libav-user-request@ffmpeg.org" target="_blank">libav-user-request@ffmpeg.org</a> with subject "unsubscribe".</blockquote></div>