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
signature.asc
Description: PGP signature
_______________________________________________ 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".
