[FFmpeg-devel] [PoC][PATCH 1/2] avutil/buffer: add av_buffer_create2() to allow AVBufferRef to store complex structures

Anton Khirnov anton at khirnov.net
Mon Jun 1 23:20:34 EEST 2020


Quoting James Almer (2020-06-01 18:35:39)
> Signed-off-by: James Almer <jamrial at gmail.com>
> ---
> This is an attempt at solving the annoying constrain of only supporting flat
> arrays within any given AVBufferRef. It introduces a new function to create
> buffers that accepts two new callback functions, one to allocate a new buffer
> when a new writable reference needs to be created, and one to copy data to it.

This makes me rather uneasy.
Is this constraint really so limiting that we need to get rid of it? In
my experience the limitation actually tends to be beneficial - it
serves as a powerful hint that maybe you're doing things in a way you
shouldn't.

What use cases do you imagine this would allow that are not possible
currently? The video enc params thing has been implemented as a flat
array without that much ugliness. It is a bit more convoluted than it
could be with this change, but then again making it a flat memcpyable
array also has advantages.

More generally, looking back at AVBuffer I have come to regret some
design choices about it. It was a mistake to (ab)use it as a base for ALL
refcounting everywhere. Instead, I should have added an AVRefcount for a
thread safe counter+opaque+destructor and then used that as a base for
anything that needed to be refcounted.
The bottom line is that I believe AVBuffer should remain as close as
possible to its original idea of "refcounted data buffer". If we want
more complex refcounted structures, we should make them separate
objects.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list