[FFmpeg-devel] [PATCH v8 07/14] avutil/frame: add helper for adding side data w/ AVBufferRef to array
James Almer
jamrial at gmail.com
Tue Mar 12 23:14:24 EET 2024
On 3/11/2024 5:58 PM, Jan Ekström wrote:
> This was requested to be added in review.
> ---
> libavutil/frame.c | 43 ++++++++++++++++++++++++++++++-------------
> libavutil/frame.h | 21 +++++++++++++++++++++
> 2 files changed, 51 insertions(+), 13 deletions(-)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 46f976a3ed..30db83a5e5 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -781,29 +781,46 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData ***sd, int *nb_sd,
> return ret;
> }
>
> -int av_frame_side_data_clone(AVFrameSideData ***sd, int *nb_sd,
> - const AVFrameSideData *src, unsigned int flags)
> +AVFrameSideData *av_frame_side_data_add(AVFrameSideData ***sd, int *nb_sd,
> + enum AVFrameSideDataType type,
> + const AVBufferRef *buf,
> + unsigned int flags)
> {
> - AVBufferRef *buf = NULL;
> - AVFrameSideData *sd_dst = NULL;
> - int ret = AVERROR_BUG;
> + AVBufferRef *new_buf = NULL;
> + AVFrameSideData *sd_dst = NULL;
>
> - if (!sd || !src || !nb_sd || (*nb_sd && !*sd))
> - return AVERROR(EINVAL);
> + if (!sd || !buf || !nb_sd || (*nb_sd && !*sd))
> + return NULL;
>
> - buf = av_buffer_ref(src->buf);
> + new_buf = av_buffer_ref(buf);
> if (!buf)
> - return AVERROR(ENOMEM);
> + return NULL;
>
> if (flags & AV_FRAME_SIDE_DATA_FLAG_UNIQUE)
> - remove_side_data(sd, nb_sd, src->type);
> + remove_side_data(sd, nb_sd, type);
>
> - sd_dst = add_side_data_to_set_from_buf(sd, nb_sd, src->type, buf);
> + sd_dst = add_side_data_to_set_from_buf(sd, nb_sd, type, new_buf);
> if (!sd_dst) {
> - av_buffer_unref(&buf);
> - return AVERROR(ENOMEM);
> + av_buffer_unref(&new_buf);
> + return NULL;
> }
>
> + return sd_dst;
> +}
> +
> +int av_frame_side_data_clone(AVFrameSideData ***sd, int *nb_sd,
> + const AVFrameSideData *src, unsigned int flags)
> +{
> + AVFrameSideData *sd_dst = NULL;
> + int ret = AVERROR_BUG;
> +
> + if (!src)
> + return AVERROR(EINVAL);
> +
> + sd_dst = av_frame_side_data_add(sd, nb_sd, src->type, src->buf, flags);
> + if (!sd_dst)
> + return AVERROR(ENOMEM);
> +
> ret = av_dict_copy(&sd_dst->metadata, src->metadata, 0);
> if (ret < 0) {
> remove_side_data_by_entry(sd, nb_sd, sd_dst);
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index ce93421d60..a7e62ded15 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -1021,6 +1021,27 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData ***sd, int *nb_sd,
> enum AVFrameSideDataType type,
> size_t size, unsigned int flags);
>
> +/**
> + * Add a new side data entry to an array from an existing AVBufferRef.
> + *
> + * @param sd pointer to array of side data to which to add another entry,
> + * or to NULL in order to start a new array.
> + * @param nb_sd pointer to an integer containing the number of entries in
> + * the array.
> + * @param type type of the added side data
> + * @param buf AVBufferRef for which a new reference will be made
> + * @param flags Some combination of AV_FRAME_SIDE_DATA_FLAG_* flags, or 0.
> + *
> + * @return newly added side data on success, NULL on error. In case of
> + * AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of matching
> + * AVFrameSideDataType will be removed before the addition is
> + * attempted.
> + */
> +AVFrameSideData *av_frame_side_data_add(AVFrameSideData ***sd, int *nb_sd,
> + enum AVFrameSideDataType type,
> + const AVBufferRef *buf,
> + unsigned int flags);
> +
> /**
> * Add a new side data entry to an array based on existing side data, taking
> * a reference towards the contained AVBufferRef.
This also LGTM, but Anton has expressed a dislike for the function
signature, preferring instead one that takes ownership of the buffer by
taking a pointer to pointer, and clearing it on success.
The argument was that the user may not care about keeping a reference to
the buffer after it's added to the side data array, but seeing how the
very first user in this patch does, I personally think this more
appropriate.
If others agree with him then I'll not oppose to it.
More information about the ffmpeg-devel
mailing list