Jul 1, 2020, 19:20 by jamr...@gmail.com:
> On 7/1/2020 12:05 PM, Anton Khirnov wrote:
>
>> Quoting Nicolas George (2020-06-27 17:16:44)
>>
>>> Signed-off-by: Nicolas George <geo...@nsup.org>
>>> ---
>>> libavutil/avrefcount_template.h | 140 ++++++++++++++++++++++++++++++++
>>> tests/ref/fate/source | 1 +
>>> 2 files changed, 141 insertions(+)
>>> create mode 100644 libavutil/avrefcount_template.h
>>>
>>>
>>> I will need to refcount something soon. Recently, the need to stop
>>> abusing AVBuffer for all refcounting was mentioned on the list. So here
>>> is an attempt at isolating the refcounting itself.
>>>
>>> This is not the final verion, I will first work on the "something" to
>>> make sure it suits the needs. But it is a first version.
>>>
>>> Anton, I would appreciate if you had a look at this and told me if there
>>> is something you strongly dislike about before I have piled too much
>>> efforts over it.
>>>
>>
>> Why a template? It seems simpler to add a struct like
>> typedef struct AVRefcount {
>> atomic_uint refcount;
>> void *opaque;
>> void (*free)(void *opaque);
>> } AVRefcount;
>> and then embed it in everything that wants to be refcounted. All just
>> normal structs and functions, no layers of macros.
>>
>
> I very much prefer this approach, being clean looking, public, and free
> of macros from unguarded headers, but it needs to be either easily
> extensible or well defined since day 1.
> For example, it could have more callbacks to be triggered by specific
> actions, like when creating new references, to workaround the current
> constrains of AVBufferRef.
>
Same.
_______________________________________________
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".
