[FFmpeg-devel] [PATCH V5 3/5] libavutil: add side data AV_FRAME_DATA_BOUNDING_BOXES

[Anton Khirnov]

Quoting Lynne (2021-03-08 14:18:15)
> Mar 8, 2021, 09:33 by anton at khirnov.net:
> 
> > Quoting Guo, Yejun (2021-03-08 06:05:20)
> >
> >> Signed-off-by: Guo, Yejun <>> yejun.guo at intel.com>> >
> >> ---
> >>  doc/APIchanges    | 2 ++
> >>  libavutil/frame.c | 1 +
> >>  libavutil/frame.h | 5 +++++
> >>  3 files changed, 8 insertions(+)
> >>
> >> diff --git a/doc/APIchanges b/doc/APIchanges
> >> index 4027d599e7..b83409a412 100644
> >> --- a/doc/APIchanges
> >> +++ b/doc/APIchanges
> >> @@ -14,6 +14,8 @@ libavutil:     2017-10-21
> >>  
> >>  
> >>  API changes, most recent first:
> >> +2021-03-xx - xxxxxxxxxx - lavu 56.xx.100 - frame.h
> >> +  Add AV_FRAME_DATA_BOUNDING_BOXES
> >>  
> >>  2021-03-04 - xxxxxxxxxx - lavc 58.128.101 - avcodec.h
> >>  Enable err_recognition to be set for encoders.
> >> diff --git a/libavutil/frame.c b/libavutil/frame.c
> >> index eab51b6a32..53868a2410 100644
> >> --- a/libavutil/frame.c
> >> +++ b/libavutil/frame.c
> >> @@ -852,6 +852,7 @@ const char *av_frame_side_data_name(enum AVFrameSideDataType type)
> >>  case AV_FRAME_DATA_VIDEO_ENC_PARAMS:            return "Video encoding parameters";
> >>  case AV_FRAME_DATA_SEI_UNREGISTERED:            return "H.26[45] User Data Unregistered SEI message";
> >>  case AV_FRAME_DATA_FILM_GRAIN_PARAMS:           return "Film grain parameters";
> >> +    case AV_FRAME_DATA_BOUNDING_BOXES:              return "Bounding boxes";
> >>  }
> >>  return NULL;
> >>  }
> >> diff --git a/libavutil/frame.h b/libavutil/frame.h
> >> index 1aeafef6de..3fbe15c47e 100644
> >> --- a/libavutil/frame.h
> >> +++ b/libavutil/frame.h
> >> @@ -198,6 +198,11 @@ enum AVFrameSideDataType {
> >>  * Must be present for every frame which should have film grain applied.
> >>  */
> >>  AV_FRAME_DATA_FILM_GRAIN_PARAMS,
> >> +
> >> +    /**
> >> +     * The data is for internal use by libavfilter.
> >>
> >
> > I do not like this. We should not have internal side data unless there
> > is a strong reason for it. There is nothing about this side data that
> > makes it inherently lavfi-specific.
> >
> 
> I object to making this public. This is not something we want to be
> stuck with.

Why not? What about this API should be changed and why not make this
change now?

> That's why I suggested internal_ref was used instead,
> but unfortunately someone just noticed it exists, of course though
> "but what if we need it for something else later, even though we've
> done just fine without it until now!?!".
> I still want to have internal_ref be used for this until the format
> is stable enough and/or codecs which make use of this appear.
> Or at least keep this patch as-is.

I see no reason to believe the format will become more public-worthy
with time.

-- 
Anton Khirnov