Quoting Lynne (2021-03-08 14:18:15)
> Mar 8, 2021, 09:33 by an...@khirnov.net:
>
> > Quoting Guo, Yejun (2021-03-08 06:05:20)
> >
> >> Signed-off-by: Guo, Yejun <>> yejun....@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
_______________________________________________
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".
