Chiebot-Mirror/FFmpeg - FFmpeg - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Andreas Rheinhardt	0c44f63b02	avcodec/refstruct: Allow to share pools To do this, make FFRefStructPool itself refcounted according to the RefStruct API. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	1 year ago
Andreas Rheinhardt	090d9956fd	avcodec/refstruct: Allow to always return zeroed pool entries This is in preparation for the following commit. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	1 year ago
Andreas Rheinhardt	26c0a7321f	avcodec/refstruct: Add RefStruct pool API Very similar to the AVBufferPool API, but with some differences: 1. Reusing an already existing entry does not incur an allocation at all any more (the AVBufferPool API needs to allocate an AVBufferRef). 2. The tasks done while holding the lock are smaller; e.g. allocating new entries is now performed without holding the lock. The same goes for freeing. 3. The entries are freed as soon as possible (the AVBufferPool API frees them in two batches: The first in av_buffer_pool_uninit() and the second immediately before the pool is freed when the last outstanding entry is returned to the pool). 4. The API is designed for objects and not naked buffers and therefore has a reset callback. This is called whenever an object is returned to the pool. 5. Just like with the RefStruct API, custom allocators are not supported. (If desired, the FFRefStructPool struct itself could be made reference counted via the RefStruct API; an FFRefStructPool would then be freed via ff_refstruct_unref().) Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	1 year ago
Andreas Rheinhardt	12c4cf9f72	avcodec/refstruct: Inline ff_refstruct_allocz() Suggested by James Almer. Reviewed-by: James Almer <jamrial@gmail.com> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	2 years ago
Andreas Rheinhardt	56dd585146	avcodec/refstruct: Allow checking for exclusive ownership This is the analog of av_buffer_is_writable(); it will be used in the next commit. Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>	2 years ago
Andreas Rheinhardt	9281dcb801	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>	2 years ago