aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/msrledec.c
diff options
context:
space:
mode:
authorAndreas Rheinhardt <andreas.rheinhardt@outlook.com>2022-08-04 03:07:58 +0200
committerAndreas Rheinhardt <andreas.rheinhardt@outlook.com>2023-10-07 22:33:32 +0200
commit9281dcb8011f52f17379789edf67595fa15f8244 (patch)
tree1027cac2f1ba6f679796f36d7c33f7116b754d89 /libavcodec/msrledec.c
parenteb73d178ea7f18817eb4f0808eb44ab095f725b1 (diff)
downloadffmpeg-9281dcb8011f52f17379789edf67595fa15f8244.tar.gz
avcodec/refstruct: Add simple API for refcounted objects
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: a) The unnecessary allocations (and ensuing error checks) when using the API. Besides the need for runtime checks it imposes upon the developer the burden of thinking through what happens in case an error happens. Furthermore, these error paths are typically not covered by FATE. b) The AVBuffer API is designed with buffers and not with objects in mind: The type for the actual buffers used is uint8_t*; it pretends to be able to make buffers writable, but this is wrong in case the buffer is not a POD. Another instance of this thinking is the lack of a reset callback in the AVBufferPool API. c) The AVBuffer API incurs unnecessary indirections by going through the AVBufferRef.data pointer. In case the user tries to avoid this indirection and stores a pointer to AVBuffer.data separately (which also allows to use the correct type), the user has to keep these two pointers in sync in case they can change (and in any case has two pointers occupying space in the containing context). See the following commit using this API for H.264 parameter sets for an example of the removal of such syncing code as well as the casts involved in the parts where only the AVBufferRef* pointer was stored. d) Given that the AVBuffer API allows custom allocators, creating refcounted objects with dedicated free functions often involves a lot of boilerplate like this: obj = av_mallocz(sizeof(*obj)); ref = av_buffer_create((uint8_t*)obj, sizeof(*obj), free_func, opaque, 0); if (!ref) { av_free(obj); return AVERROR(ENOMEM); } (There is also a corresponding av_free() at the end of free_func().) This is now just obj = ff_refstruct_alloc_ext(sizeof(*obj), 0, opaque, free_func); if (!obj) return AVERROR(ENOMEM); See the subsequent patch for the framepool (i.e. get_buffer.c) for an example. This API does things differently; it is designed to be lightweight* as well as geared to the common case where the allocator of the underlying object does not matter as long as it is big enough and suitably aligned. This allows to allocate the user data together with the API's bookkeeping data which avoids an allocation as well as the need for separate pointers to the user data and the API's bookkeeping data. This entails that the actual allocation of the object is performed by RefStruct, not the user. This is responsible for avoiding the boilerplate code mentioned in d). As a downside, custom allocators are not supported, but it will become apparent in subsequent commits that there are enough usecases to make it worthwhile. Another advantage of this API is that one only needs to include the relevant header if one uses the API and not when one includes the header or some other component that uses it. This is because there is no RefStruct type analog of AVBufferRef. 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). Finally, this API supports const-qualified opaque pointees; this will allow to avoid casting const away by the CBS code. *: Basically the only exception to the you-only-pay-for-what-you-use rule is that it always uses atomics for the refcount. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Diffstat (limited to 'libavcodec/msrledec.c')
0 files changed, 0 insertions, 0 deletions