> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Lynne > Sent: Saturday, February 20, 2021 11:36 PM > To: FFmpeg development discussions and patches <ffmpeg- > de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] libavutil: add side data > AV_FRAME_DATA_BOUNDING_BOXES > > Feb 20, 2021, 15:13 by yejun....@intel.com: > > > > > > >> -----Original Message----- > >> From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > >> Lynne > >> Sent: 2021年2月20日 6:54 > >> To: FFmpeg development discussions and patches > >> <ffmpeg-devel@ffmpeg.org> > >> Subject: Re: [FFmpeg-devel] [PATCH 2/4] libavutil: add side data > >> AV_FRAME_DATA_BOUNDING_BOXES > >> > >> Feb 19, 2021, 07:59 by yejun....@intel.com: > >> > >> > Signed-off-by: Guo, Yejun <yejun....@intel.com> > >> > --- > >> > doc/APIchanges | 2 ++ > >> > libavutil/frame.c | 1 + > >> > libavutil/frame.h | 7 +++++++ > >> > libavutil/version.h | 2 +- > >> > 4 files changed, 11 insertions(+), 1 deletion(-) > >> > > >> > diff --git a/doc/APIchanges b/doc/APIchanges index > >> > c353d2d281..3c6e9e351e 100644 > >> > --- a/doc/APIchanges > >> > +++ b/doc/APIchanges > >> > @@ -14,6 +14,8 @@ libavutil: 2017-10-21 > >> > > >> > >> This won't really work. > >> Side data must be public but the header it's specified in is neither > >> installed, neither in lavu. There's no such thing as ffmpeg-only private > data. > >> > >> If we do plan to make this side data public, it'll require a lot more > >> considerations, and versioning like with the film grain side data, > >> since as you pointed out it may be used by codecs. > >> > > > > Thanks for your feedback. > > > > Could you share a bit more about the 'versioning' of film grain? thanks. > > > > I checked file film_grain_params.h/c and do not find it is version relative. > > > > As for the bounding box, the BoundingBoxHeader.bbox_size acts like a > > version checker. (different bbox_size if the struct is changed later) > > > > That's not really a good solution. I meant having a dedicated and > documented version field which switches structs. > Changing the struct size means we can only add fields, so if we need to alter > the behavior of previous fields we'll end up with a data format more > convoluted than mpeg audio codecs.
Thanks, got it. > > > >> For now, although it's somewhat less appropriate, you can replace the > >> side data with frame->private_ref. It's an AVBufferRef that's for use > >> by a single internal library, and we don't use it anywhere except in > >> lavc for now. > >> > > > > Thanks for pointing this possible way, I'll investigate it. > > I would prefer side data which is possible the final solution. > > > > I'd rather not commit us to a side data format that may change in the future > and has no lavfi-external use. Could you implement it as a private_ref, at > least for the time being? It's lavfi-only, so it makes sense for now, plus we > can keep changing it, and once an external user appears we can make it > proper public side data? Sure, I'll look at this method, thanks. > _______________________________________________ > 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". _______________________________________________ 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".
