On 12/14/2019 7:50 PM, Marton Balint wrote:
>
>
> On Sat, 14 Dec 2019, James Almer wrote:
>
>> On 12/7/2019 6:57 PM, Marton Balint wrote:
>>> In order to access the original opaque parameter of a buffer in the
>>> buffer
>>> pool. (The buffer pool implementation overrides the normal opaque
>>> parameter but
>>> also saves it so it is accessible).
>>>
>>> Signed-off-by: Marton Balint <c...@passwd.hu>
>>> ---
>>> doc/APIchanges | 3 +++
>>> libavutil/buffer.c | 6 ++++++
>>> libavutil/buffer.h | 13 +++++++++++++
>>> libavutil/version.h | 4 ++--
>>> 4 files changed, 24 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/doc/APIchanges b/doc/APIchanges
>>> index 401c65a753..5b8d801f06 100644
>>> --- a/doc/APIchanges
>>> +++ b/doc/APIchanges
>>> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>>>
>>> API changes, most recent first:
>>>
>>> +2019-12-xx - xxxxxxxxxx - lavu 56.37.100 - buffer.h
>>> + Add av_buffer_pool_buffer_get_opaque().
>>> +
>>> 2019-11-17 - 1c23abc88f - lavu 56.36.100 - eval API
>>> Add av_expr_count_vars().
>>>
>>> diff --git a/libavutil/buffer.c b/libavutil/buffer.c
>>> index f0034b026a..ec00fb22ec 100644
>>> --- a/libavutil/buffer.c
>>> +++ b/libavutil/buffer.c
>>> @@ -355,3 +355,9 @@ AVBufferRef *av_buffer_pool_get(AVBufferPool *pool)
>>>
>>> return ret;
>>> }
>>> +
>>> +void *av_buffer_pool_buffer_get_opaque(AVBufferRef *ref)
>>> +{
>>> + BufferPoolEntry *buf = ref->buffer->opaque;
>>> + return buf->opaque;
>>
>> I'm not sure if this is a good idea. It takes any AVBufferRef as input,
>> so it will crash on pretty much every one not created by an AVBufferPool
>> (unless it checks that buf is not NULL before dereferencing it), or
>> return something unrelated otherwise.
>
> It is documented below that the buffer has to be part of the pool, so I
> don't really see this as an issue.
>
> An alternative approach might be to introduce
> AVBufferRef *av_buffer_pool_get2(AVBufferPool *pool, void **opaque);
> which returns the original opauqe value of the allocated buffer in
> addition to returning the buffer.
>
> Do you prefer this? Or maybe something entirely different?
I'd like to hear other devs opinions, but that suggestion does sound
good. It complements av_buffer_pool_init2(), the pool init function that
allows this scenario to being with.
>
> Thanks,
> Marton
>
>>
>>> +}
>>> diff --git a/libavutil/buffer.h b/libavutil/buffer.h
>>> index 73b6bd0b14..e0f94314f4 100644
>>> --- a/libavutil/buffer.h
>>> +++ b/libavutil/buffer.h
>>> @@ -284,6 +284,19 @@ void av_buffer_pool_uninit(AVBufferPool **pool);
>>> */
>>> AVBufferRef *av_buffer_pool_get(AVBufferPool *pool);
>>>
>>> +/**
>>> + * Query the original opaque parameter of an allocated buffer in the
>>> pool.
>>> + *
>>> + * @param ref a buffer reference to a buffer returned by
>>> av_buffer_pool_get.
>>> + * @return the opaque parameter set by the buffer allocator function
>>> of the
>>> + * buffer pool.
>>> + *
>>> + * @note the opaque parameter of ref is used by the buffer pool
>>> implementation,
>>> + * therefore you have to use this function to access the original
>>> opaque
>>> + * parameter of an allocated buffer.
>>> + */
>>> +void *av_buffer_pool_buffer_get_opaque(AVBufferRef *ref);
>>> +
>>> /**
>>> * @}
>>> */
>>> diff --git a/libavutil/version.h b/libavutil/version.h
>>> index e18163388d..4de0fa1fc3 100644
>>> --- a/libavutil/version.h
>>> +++ b/libavutil/version.h
>>> @@ -79,8 +79,8 @@
>>> */
>>>
>>> #define LIBAVUTIL_VERSION_MAJOR 56
>>> -#define LIBAVUTIL_VERSION_MINOR 36
>>> -#define LIBAVUTIL_VERSION_MICRO 101
>>> +#define LIBAVUTIL_VERSION_MINOR 37
>>> +#define LIBAVUTIL_VERSION_MICRO 100
>>>
>>> #define LIBAVUTIL_VERSION_INT
>>> AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
>>>
>>> LIBAVUTIL_VERSION_MINOR, \
>>>
>>
>> _______________________________________________
>> 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".
> _______________________________________________
> 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".
_______________________________________________
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".
