[FFmpeg-devel] Buffers Threads and refcounts

Hendrik Leppkes h.leppkes at gmail.com
Wed Jan 9 20:06:08 CET 2013

On Wed, Jan 9, 2013 at 7:54 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Wed, Jan 09, 2013 at 03:43:03PM +0100, Hendrik Leppkes wrote:
>> > If you interface with libavcodec/libavfilter and the buffers you have
>> > from whichever platform specific API (de)uxer, (decoder, display, ...
>> > arent refcounted but instead only valid till the next call or return.
>> > Then you do NOT need a copy now in many cases but will need one with
>> > the new API
>> > (at least thats how i understand it, please correct me
>> >  if i missed something)
>> >
>> It should be very much possible to use non-refcounted buffers still,
>> at least i saw this in one of the new lavu headers. If a
>> non-refcounted buffer is encountered and lavfi needs to store it for
>> later, it should copy it to a ref-counted buffer, like its done now
>> with buffers without the "keep" permission. At least i don't see how
>> the API would limit this by design.
> Huh? You're countering Michael's argument that this (very common) use
> case will now need an additional memcpy by saying that it is supported
> by doing a memcpy? That makes no sense to me.

If you have buffer that is only valid until the call ends, and you
want to keep its conents longer then that, its quite obvious that the
only choice is to memcpy it, today or with any new system.
If all processing on that buffer is done during this call, i don't
believe the new system would require a memcpy (or could be designed to
not require one, its still wide-open for comments)

I hope this was clear enough.

More information about the ffmpeg-devel mailing list