Hi, On Mon, Nov 2, 2015 at 12:32 PM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote:
> 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. A micro does not have to be bumped on the very commit. We can merge that micro-bump together for various features, or we can forget it altogether and it's simply part of the next (totally unrelated) microbump. You can even bump it today if there has not been a bump since already. Regardless of when the micro was bumped after the fact, the application that relies on the new/fixed/changed behaviour can then use that micro as minimum required runtime version. That this was committed a month later is merely a detail that most users will never know or care for. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
