On Fri, Nov 13, 2015 at 5:33 PM, Michael Niedermayer
<mich...@niedermayer.cc> wrote:
> On Fri, Nov 13, 2015 at 07:38:31AM -0500, Ganesh Ajjanagadde wrote:
>> On Fri, Nov 13, 2015 at 6:40 AM, Michael Niedermayer
>> <mich...@niedermayer.cc> wrote:
>> > On Thu, Nov 12, 2015 at 09:46:04PM -0500, Ganesh Ajjanagadde wrote:
>> >> The rationale for this function is reflected in the documentation for
>> >> it, and is copied here:
>> >>
>> >> Clip a double value into the long long amin-amax range.
>> >> This function is needed because conversion of floating point to integers
>> >> when
>> >> it does not fit in the integer's representation does not necessarily
>> >> saturate
>> >> correctly (usually converted to a cvttsd2si on x86) which saturates
>> >> numbers
>> >> > INT64_MAX to INT64_MIN. The standard marks such conversions as undefined
>> >> behavior, allowing this sort of mathematically bogus conversions. This
>> >> provides
>> >> a safe alternative that is slower obviously but assures safety and better
>> >> mathematical behavior.
>> >> API:
>> >> @param a value to clip
>> >> @param amin minimum value of the clip range
>> >> @param amax maximum value of the clip range
>> >> @return clipped value
>> >>
>> >> Note that a priori if one can guarantee from the calling side that the
>> >> double is in range, it is safe to simply do an explicit/implicit cast,
>> >> and that will be far faster. However, otherwise this function should be
>> >> used.
>> >>
>> >> avutil minor version is bumped.
>> >>
>> >> Reviewed-by: Ronald S. Bultje <rsbul...@gmail.com>
>> >> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com>
>> >> ---
>> >> libavutil/common.h | 31 +++++++++++++++++++++++++++++++
>> >> libavutil/version.h | 4 ++--
>> >> 2 files changed, 33 insertions(+), 2 deletions(-)
>> >>
>> >> diff --git a/libavutil/common.h b/libavutil/common.h
>> >> index 6f0f582..4f60e72 100644
>> >> --- a/libavutil/common.h
>> >> +++ b/libavutil/common.h
>> >> @@ -298,6 +298,34 @@ static av_always_inline av_const double
>> >> av_clipd_c(double a, double amin, double
>> >> else return a;
>> >> }
>> >>
>> >> +/**
>> >> + * Clip and convert a double value into the long long amin-amax range.
>> >> + * This function is needed because conversion of floating point to
>> >> integers when
>> >> + * it does not fit in the integer's representation does not necessarily
>> >> saturate
>> >> + * correctly (usually converted to a cvttsd2si on x86) which saturates
>> >> numbers
>> >> + * > INT64_MAX to INT64_MIN. The standard marks such conversions as
>> >> undefined
>> >> + * behavior, allowing this sort of mathematically bogus conversions.
>> >> This provides
>> >> + * a safe alternative that is slower obviously but assures safety and
>> >> better
>> >> + * mathematical behavior.
>> >> + * @param a value to clip
>> >> + * @param amin minimum value of the clip range
>> >> + * @param amax maximum value of the clip range
>> >> + * @return clipped value
>> >> + */
>> >> +static av_always_inline av_const int64_t av_rint64_clip_c(double a,
>> >> int64_t amin, int64_t amax)
>> >> +{
>> >> +#if defined(HAVE_AV_CONFIG_H) && defined(ASSERT_LEVEL) && ASSERT_LEVEL
>> >> >= 2
>> >> + if (amin > amax) abort();
>> >> +#endif
>> >> + // INT64_MAX+1,INT64_MIN are exactly representable as IEEE doubles
>> >> + if (a >= 9223372036854775808.0)
>> >> + return INT64_MAX;
>> >> + if (a <= INT64_MIN)
>> >> + return INT64_MIN;
>> >> + // Finally safe to call av_clipd_c
>> >> + return (int64_t)av_clipd_c(a, amin, amax);
>> >> +}
>> >
>> > this fails to build here:
>>
>> Does not get compiled on my machine, that is why I missed this. Very
>> strange, stdint is included in this header. Can you tell me what to
>> pass to configure in order to reproduce this?
>
> i think "--enable-libutvideo"
> i suspect that any C++ file which includes this might trigger it
> but i didnt check that
Thanks for the info, not needed for the patch though which has been pushed.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The worst form of inequality is to try to make unequal things equal.
> -- Aristotle
>
> _______________________________________________
> 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
