On Mon, Nov 2, 2015 at 11:58 AM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi, > > On Mon, Nov 2, 2015 at 11:07 AM, Ganesh Ajjanagadde <gajja...@mit.edu> > wrote: > >> On Mon, Nov 2, 2015 at 10:28 AM, Ronald S. Bultje <rsbul...@gmail.com> >> wrote: >> > Hi, >> > >> > On Sun, Nov 1, 2015 at 8:20 PM, Ganesh Ajjanagadde <gajja...@mit.edu> >> wrote: >> > >> >> On Sun, Nov 1, 2015 at 7:59 PM, Ronald S. Bultje <rsbul...@gmail.com> >> >> wrote: >> >> >> >> - I think the name of this function is confusing. The av_clip* namespace >> >> > seems reserved for int to int clips, so using it for a float to int >> >> > conversion with clip is kind of weird. I would use a different >> namespace >> >> > for it. >> >> >> >> Mathematically, it is the same as clipping, albeit "lossy", but then >> >> again all clipping is by nature "lossy" on inputs outside the clipping >> >> range, hence the choice of name. Any ideas for a namespace for this? >> >> >> > >> > Clip is the namespace for _just_ a clip. This function converts _and_ >> > clips. How about av_rint64_clip. >> >> I like this name, thanks. Also, please tell me what to do about >> version bumps etc, so that I can get this done for v2. > > > I'm not sure actually. > > I believe for new API you increment minor (see libavutil/version.h) by 1 > and reset micro to 0. You bump major on API changes, and you bump micro for > behavioural changes (?).
Hmm, then there is a micro bump that I missed: av_gcd works differently for negative inputs than before: previously it was undefined in terms of its documentation, not actuality I believe, but now it has well defined semantics for all int64_t, and this has been documented. > > Ronald > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
