Re: [FFmpeg-devel] [PATCH 02/42] avcodec/refstruct: Add simple API for refcounted objects

[Nicolas George <george@nsup.org>]

[-- Attachment #1.1: Type: text/plain, Size: 2035 bytes --]

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".