[FFmpeg-devel] [PATCH 0/2] first steps to resolving float to int undefined behavior
gajjanag at mit.edu
Mon Nov 2 18:32:21 CET 2015
On Mon, Nov 2, 2015 at 11:58 AM, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> On Mon, Nov 2, 2015 at 11:07 AM, Ganesh Ajjanagadde <gajjanag at mit.edu>
>> On Mon, Nov 2, 2015 at 10:28 AM, Ronald S. Bultje <rsbultje at gmail.com>
>> > Hi,
>> > On Sun, Nov 1, 2015 at 8:20 PM, Ganesh Ajjanagadde <gajjanag at mit.edu>
>> >> On Sun, Nov 1, 2015 at 7:59 PM, Ronald S. Bultje <rsbultje at 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
>> >> > 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
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
More information about the ffmpeg-devel