On 9/19/2023 4:56 PM, Andreas Rheinhardt wrote:
+
+/**
+ * Allocate a refcounted object of usable size `size` managed via
+ * the RefStruct API.
+ *
+ * By default (in the absence of flags to the contrary),
+ * the returned object is initially zeroed.
+ *
+ * @param sizeDesired usable size
Andreas Rheinhardt (12023-10-06):
> And as I have already explained, I do not think that this benefit is
> significant and you have provided no evidence (i.e. an example) that it
> is so. Additionally, the flexibility provided by function pointers is
> useful for stuff like CBS.
I must have
Nicolas George:
> Andreas Rheinhardt (12023-10-06):
>> Do you mean a template that generates functions like
>>
>> HEVCVPS *ff_hevc_vps_ref(HEVCVPS *vps)
>> {
>> return ff_refstruct_ref(vps);
>> }
>>
>> automatically?
>
> Yes, but better, directly:
>
> void ff_hevc_vps_unref(HEVCVPS *vps)
> {
Andreas Rheinhardt (12023-10-06):
> Do you mean a template that generates functions like
>
> HEVCVPS *ff_hevc_vps_ref(HEVCVPS *vps)
> {
> return ff_refstruct_ref(vps);
> }
>
> automatically?
Yes, but better, directly:
void ff_hevc_vps_unref(HEVCVPS *vps)
{
if
Nicolas George:
> Andreas Rheinhardt (12023-10-06):
>> Will apply patches 2-16 (i.e. up to the pool API) tomorrow unless there
>> are objections.
>
> Have you given some thought to using a template to make the API
> type-safe directly?
Do you mean a template that generates functions like
Andreas Rheinhardt (12023-10-06):
> Will apply patches 2-16 (i.e. up to the pool API) tomorrow unless there
> are objections.
Have you given some thought to using a template to make the API
type-safe directly?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
Andreas Rheinhardt:
> 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
Nicolas George:
> 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.
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
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
10 matches
Mail list logo