[FFmpeg-devel] [PATCH 1/6] avutil/frame: add av_frame_remove_side_data_changed
Niklas Haas
ffmpeg at haasn.xyz
Fri Nov 29 17:50:19 EET 2024
On Thu, 02 May 2024 12:11:25 +0200 Niklas Haas <ffmpeg at haasn.xyz> wrote:
> On Fri, 26 Apr 2024 16:29:03 -0300 James Almer <jamrial at gmail.com> wrote:
> > On 4/26/2024 9:27 AM, Niklas Haas wrote:
> > > From: Niklas Haas <git at haasn.dev>
> > >
> > > Many filters modify certain aspects of frame data, e.g. through resizing
> > > (vf_*scale* family), color volume mapping (vf_lut*, vf_tonemap*), or
> > > possibly others.
> > >
> > > When this happens, we should strip all frame side data that will no
> > > longer be correct/relevant after the operation. For example, changing
> > > the image size should invalidate AV_FRAME_DATA_PANSCAN because the crop
> > > window (given in pixels) no longer corresponds to the actual image size.
> > > For another example, tone-mapping filters (e.g. from HDR to SDR) should
> > > strip all of the dynamic HDR related metadata.
> > >
> > > Since there are a lot of similar with basically similar operations, it
> > > make sense to consolidate this stripping logic into a common helper
> > > function. I decided to put it into libavutil as it may be useful for API
> > > users as well, who often have their own internal processing and
> > > filtering.
> >
> > Maybe instead of "changed", which is a concept that doesn't belong to a
> > frame but to a process, use a name that references side data that
> > depends on specific properties (dimensions, color props, etc).
> >
> > Also, don't make it depend on AVFrame, but AVFrameSideData instead, so
> > it can be reused in other contexts (Use the av_frame_side_data_*
> > namespace for it).
>
> Do you have a proposed name?
>
> I can think of:
> - av_frame_side_data_remove_aspect()
> - av_frame_side_data_remove_dependent()
> - av_frame_side_data_remove_category()
>
> Not sure if I like any more (which is why I went with _changed(), which
> tells you exactly when this function was intended to be used).
Ping? I need this one for an upcoming swscale change.
More information about the ffmpeg-devel
mailing list