Andreas Rheinhardt (12023-09-19):
> For now, this API is supposed to replace all the internal uses
> of reference counted objects in libavcodec; "internal" here
> means that the object is created in libavcodec and is never
> put directly in the hands of anyone outside of it.
> 
> It is intended to be made public eventually, but for now
> I enjoy the ability to modify it freely.
> 
> Several shortcomings of the AVBuffer API motivated this API:

<snip>

Thanks for stating qualms that I have had for a long time about this
API.

An API like this one would have been really useful when the new channel
layout structure was integrated. On a brighter note, it will be really
useful if we finally turn the library's global state into a structure
that can exist in multiple instances.

>					      This brings with it
> one further downside: It is not apparent from the pointer itself
> whether the underlying object is managed by the refstruct API
> or whether this pointer is a reference to it (or merely a pointer
> to it).

I do not count it as a downside: it is just how the C language is
supposed to work. When we get a pointer, there is nothing written on it
that says whether we are supposed to free(), av_free(), g_object_unref()
it or just do nothing. People who cannot track static pointer ownership
in their sleep should do Java.

Also, you probably do not remember, three years ago I started proposing
a similar idea, and it got bikeshedded to death:

http://ffmpeg.org/pipermail/ffmpeg-devel/2020-June/265227.html

The difference is:

You make this API universal using void pointers and callbacks, and you
make it convenient by hiding the internals using pointer arithmetic.

I achieve more or less the same using a template to generate code, with
the extra benefit that it is type-safe.

I see a few places in the code below where you pay the price for your
design choice. I think you should consider taking a few ideas from my
version.

Regards,

-- 
  Nicolas George