[FFmpeg-devel] [PATCH] avutil/frame: Add avcodec_private_ref to AVFrame

Michael Niedermayer michael at niedermayer.cc
Sun Nov 5 17:20:07 EET 2017


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171105/64f7133e/attachment.sig>


More information about the ffmpeg-devel mailing list