--- Daniel Oberhoff daniel.oberh...@gmail.com
On Aug 20, 2014, at 2:54 PM, Michael Niedermayer <michae...@gmx.at> wrote: > On Wed, Aug 20, 2014 at 02:42:35PM +0200, Daniel Oberhoff wrote: >> >> --- >> Daniel Oberhoff >> daniel.oberh...@gmail.com >> >> >> >> On Aug 20, 2014, at 2:17 PM, Michael Niedermayer <michae...@gmx.at> wrote: >> >>> The only remaining floats are in the user interface, they are left as they >>> should not cause a problem in practice >>> --- >>> libavfilter/vf_lenscorrection.c | 13 +++++++------ >>> 1 file changed, 7 insertions(+), 6 deletions(-) >>> >>> diff --git a/libavfilter/vf_lenscorrection.c >>> b/libavfilter/vf_lenscorrection.c >>> index 11fa4c8..d30a81b 100644 >>> --- a/libavfilter/vf_lenscorrection.c >>> +++ b/libavfilter/vf_lenscorrection.c >>> @@ -149,8 +149,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame >>> *in) >>> int h = rect->height / vdiv; >>> int xcenter = rect->cx * w; >>> int ycenter = rect->cy * h; >>> - float k1 = rect->k1; >>> - float k2 = rect->k2; >>> + int k1 = rect->k1 * (1<<24); >>> + int k2 = rect->k2 * (1<<24); >>> ThreadData td = { >>> .in = in, >>> .out = out, >>> @@ -162,7 +162,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame >>> *in) >>> >>> if (!rect->correction[plane]) { >>> int i,j; >>> - const float r2inv = 4.0 / (w * w + h * h); >>> + const int64_t r2inv = (4LL<<60) / (w * w + h * h); >>> >>> rect->correction[plane] = av_malloc_array(w, h * >>> sizeof(**rect->correction)); >>> if (!rect->correction[plane]) >>> @@ -172,9 +172,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame >>> *in) >>> const int off_y2 = off_y * off_y; >>> for (i = 0; i < w; i++) { >>> const int off_x = i - xcenter; >>> - const float r2 = (off_x * off_x + off_y2) * r2inv; >>> - const float radius_mult = 1.0f + r2 * k1 + r2 * r2 * >>> k2; >>> - rect->correction[plane][j * w + i] = >>> lrintf(radius_mult * (1<<24)); >>> + const int64_t r2 = ((off_x * off_x + off_y2) * r2inv + >>> (1LL<<31)) >> 32; >> >> won’t this potentially overflow for large off_x if int is 32bit? (same above >> for off_y2) > > yes, with images somewhere around 32k X 32k there will be problems > but images in that size range arent very well supported when pixels > are addressed by int, which they are all over the codebase Ok, get it. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel