On Sun, Nov 05, 2017 at 10:35:06AM -0300, James Almer wrote: > On 11/5/2017 9:34 AM, Michael Niedermayer wrote: > > This gives libavcodec a field that it can freely and safely use. > > Avoiding the need of wraping of a users opaque_ref field and its issues. > > Could this perhaps be in an opaque internal struct instead, much like > AVCodecInternal and whatnot?
We could do a AVFrameInternal but that would require some differenecs to AVCodecInternal. The AVBufferRef from the patch has its own reference counting and destruction callback. (which avcodec can use for cleaning it up) a straight AVFrameInternal (in AVCodecInternal style) would not have that, we could place the AVFrameInternal inside a AVBufferRef or provide seperate API / fields to make cleanup from libavcodec possible. > As wm4 said in the relevant discussion, > this approach is nonoptimal and *will* snowball into a mess of fields if > other libav* libraries start requiring their own buffers in a frame. I remember and i think i didnt reply there but this is not really a plausible scenario. If we added a field per lib we would have realistically 2 fields one for libavcodec and one for libavfilter. Beyond that even with constructed use cases it seems to become hard (at least to me ATM) to see what else would be added. libswscale ? libavformat ? but what would they do with their fields ? But really i primarly want this to move forward, i have no real preferrance as long as we dont cram muliple opaques in a single opaque field with wraping or other. > An internal field of an opaque struct being in a public header is much > cleaner and easier to maintain than adding such specific fields that may > at some point in the future need to be removed. > > No actual comments about the approach in question to solve the issue. > Will leave that to someone more knowledgeable. But at least I'm glad > something is being done about it. > [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel