[FFmpeg-devel] [PATCH 04/13] lavc: Deprecate av_hwaccel_next() and av_register_hwaccel()

Rostislav Pehlivanov atomnuker at gmail.com
Sat Nov 18 22:18:04 EET 2017


On 18 November 2017 at 20:11, James Almer <jamrial at gmail.com> wrote:

> On 11/18/2017 5:03 PM, Rostislav Pehlivanov wrote:
> > On 18 November 2017 at 19:17, James Almer <jamrial at gmail.com> wrote:
> >
> >> On 11/18/2017 4:07 PM, Mark Thompson wrote:
> >>> On 18/11/17 19:00, Rostislav Pehlivanov wrote:
> >>>> On 18 November 2017 at 18:47, Mark Thompson <sw at jkqxz.net> wrote:
> >>>>
> >>>>> ---
> >>>>>  doc/APIchanges       |  4 ++++
> >>>>>  libavcodec/avcodec.h | 13 +++++++++++++
> >>>>>  libavcodec/utils.c   | 16 +++++-----------
> >>>>>  libavcodec/version.h |  3 +++
> >>>>>  4 files changed, 25 insertions(+), 11 deletions(-)
> >>>>>
> >>>>>
> >>>>>  int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
> >>>>>  {
> >>>>> diff --git a/libavcodec/version.h b/libavcodec/version.h
> >>>>> index 5b25a9a8ac..693f67386c 100644
> >>>>> --- a/libavcodec/version.h
> >>>>> +++ b/libavcodec/version.h
> >>>>> @@ -123,6 +123,9 @@
> >>>>>  #ifndef FF_API_CODEC_GET_SET
> >>>>>  #define FF_API_CODEC_GET_SET     (LIBAVCODEC_VERSION_MAJOR < 59)
> >>>>>  #endif
> >>>>> +#ifndef FF_API_USER_VISIBLE_AVHWACCEL
> >>>>> +#define FF_API_USER_VISIBLE_AVHWACCEL (LIBAVCODEC_VERSION_MAJOR <
> 60)
> >>>>>
> >>>>
> >>>> 60? That's 2 bumps away, this should be 59, no?
> >>>
> >>> Two bumps away is the usual number, isn't it?  Or does it count as
> >> not-bumped-yet for this purpose because we are still in the unstable
> period?
> >>
> >> The number doesn't matter as long as the condition evaluates to true
> >> when it's meant to.
> >> If you use 59 and there's a bump before the two years period for this
> >> specific deprecation is over, then the line will have to be changed to
> >> 60 during said bump to make sure the API doesn't get disabled.
> >> However using 60 would mean that the line can be left alone. The bump
> >> that changes the major to 60 is unlikely to happen before the two year
> >> mark.
> >>
> >> So it's fine as is. No need to change it.
> >>
> >>
> > It'll be forgotten and it'll take 4 years to remove. How is anyone
> supposed
> > to know when something's meant to be removed aside from the MAJOR
> version?
>
> By git blaming version.h to look at the exact date of the commits that
> deprecated every listed API, same as it's done every time a bump takes
> place.
>
> As long as whoever handles the bump does it properly then it shouldn't
> make a difference. But if you feel more comfortable making it 59 then it
> can be changed. Both values are fine.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I'd be more comfortable with 59, that should save effort on the part of the
person doing the bump.


More information about the ffmpeg-devel mailing list