From: James Almer <jamrial@gmail.com> To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH 03/11] avutil/frame: add functions to check and ensure a side data entry is writable Date: Fri, 21 Feb 2025 09:25:32 -0300 Message-ID: <990dac59-e02a-4b2c-84de-51bbbe20d456@gmail.com> (raw) In-Reply-To: <AS8P250MB0744D6DE9EA8AF15B7A108858FC72@AS8P250MB0744.EURP250.PROD.OUTLOOK.COM> [-- Attachment #1.1.1: Type: text/plain, Size: 3726 bytes --] On 2/21/2025 8:44 AM, Andreas Rheinhardt wrote: > James Almer: >> Signed-off-by: James Almer <jamrial@gmail.com> >> --- >> libavutil/frame.h | 19 +++++++++++++++++++ >> libavutil/side_data.c | 25 +++++++++++++++++++++++++ >> 2 files changed, 44 insertions(+) >> >> diff --git a/libavutil/frame.h b/libavutil/frame.h >> index 49260ae2dd..a707b35087 100644 >> --- a/libavutil/frame.h >> +++ b/libavutil/frame.h >> @@ -1211,6 +1211,25 @@ void av_frame_side_data_remove(AVFrameSideData ***sd, int *nb_sd, >> void av_frame_side_data_remove_by_props(AVFrameSideData ***sd, int *nb_sd, >> int props); >> >> +/** >> + * Check whether the data described by a given AVFrameSideData can be >> + * written to. >> + * >> + * @return 1 if the caller may write to the data, 0 otherwise. >> + */ >> +int av_frame_side_data_is_writable(const AVFrameSideData *sd); >> + >> +/** >> + * Create a writable reference for the data described by a given >> + * AVFrameSideData, avoiding data copy if possible. >> + * >> + * @param sd Side data whose data should be made writable. >> + * >> + * @return 0 on success, a negative AVERROR on failure. On failure, the >> + * side data is unchanged. >> + */ >> +int av_frame_side_data_make_writable(AVFrameSideData *sd); > > I don't see the point of either of them: The former is just a wrapper > around av_buffer_is_writable() and the latter is basically the same as > av_buffer_make_writable() (and could actually use it). > > If this is designed with using something else but flat buffers in the > future in mind, then av_frame_side_data_make_writable() is misdesigned, > because making a non-flat object writable is ambiguous: It is not clear > whether making something writable is meant in a shallow or a deep sense > which may become an issue if future side-data contains references of its > own. In the previous iteration of this set, where i added RefCount as backing for the side data, av_frame_side_data_make_writable() included per type callbacks in the descriptors that would take care of any kind of refcounted buffer or object within the side data. I can skip this patch in any case, since you were against adding the RefCount backing implementation right now, its usefulness is limited. > >> + >> /** >> * @} >> */ >> diff --git a/libavutil/side_data.c b/libavutil/side_data.c >> index 8c57fd838a..beb8ea3212 100644 >> --- a/libavutil/side_data.c >> +++ b/libavutil/side_data.c >> @@ -315,3 +315,28 @@ const AVFrameSideData *av_frame_side_data_get_c(const AVFrameSideData * const *s >> } >> return NULL; >> } >> + >> +int av_frame_side_data_is_writable(const AVFrameSideData *sd) >> +{ >> + return !!av_buffer_is_writable(sd->buf); > > av_buffer_is_writable() is documented to only return 0 or 1, so the > binarization is unnecessary. > >> +} >> + >> +int av_frame_side_data_make_writable(AVFrameSideData *sd) >> +{ >> + AVBufferRef *buf = NULL; >> + >> + if (av_buffer_is_writable(sd->buf)) >> + return 0; >> + >> + buf = av_buffer_alloc(sd->size); >> + if (!buf) >> + return AVERROR(ENOMEM); >> + >> + if (sd->size) >> + memcpy(buf->data, sd->data, sd->size); >> + av_buffer_unref(&sd->buf); >> + sd->buf = buf; >> + sd->data = buf->data; >> + >> + return 0; >> +} > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 495 bytes --] [-- Attachment #2: Type: text/plain, Size: 251 bytes --] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2025-02-21 12:25 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-02-20 17:24 [FFmpeg-devel] [PATCH 01/11] avutil/frame: move side data helpers to a new file James Almer 2025-02-20 17:24 ` [FFmpeg-devel] [PATCH 02/11] avutil/side_data: allow the addition of internal fields to AVSideDataDescriptor James Almer 2025-02-20 17:24 ` [FFmpeg-devel] [PATCH 03/11] avutil/frame: add functions to check and ensure a side data entry is writable James Almer 2025-02-21 11:44 ` Andreas Rheinhardt 2025-02-21 12:25 ` James Almer [this message] 2025-02-20 17:24 ` [FFmpeg-devel] [PATCH 04/11] avutil/frame: av_frame_side_data_new_struct() James Almer 2025-02-20 17:24 ` [FFmpeg-devel] [PATCH 05/11] avutil/ambient_viewing_environment: deprecate av_ambient_viewing_environment_create_side_data() James Almer 2025-02-20 17:24 ` [FFmpeg-devel] [PATCH 06/11] avutil/downmix_info: deprecate av_downmix_info_update_side_data() James Almer 2025-02-20 17:24 ` [FFmpeg-devel] [PATCH 07/11] avutil/hdr_dynamic_metadata: deprecate av_dynamic_hdr_plus_create_side_data() James Almer 2025-02-20 17:24 ` [FFmpeg-devel] [PATCH 08/11] avutil/hdr_dynamic_vivid_metadata: deprecate av_dynamic_hdr_vivid_create_side_data() James Almer 2025-02-20 17:24 ` [FFmpeg-devel] [PATCH 09/11] avutil/mastering_display_metadata: deprecate av_{content_light, mastering_display_metadata}_create_side_data() James Almer 2025-02-20 17:24 ` [FFmpeg-devel] [PATCH 10/11] avutil/mastering_display_metadata: deprecate av_mastering_display_metadata_alloc() James Almer 2025-02-20 17:24 ` [FFmpeg-devel] [PATCH 11/11] avutil/stereo3d: deprecate av_stereo3d_create_side_data() James Almer
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=990dac59-e02a-4b2c-84de-51bbbe20d456@gmail.com \ --to=jamrial@gmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git