Quoting James Almer (2020-06-01 18:35:39) > Signed-off-by: James Almer <jamr...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
