[FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
Daniel Oberhoff
danieloberhoff at gmail.com
Wed Aug 20 14:57:08 CEST 2014
---
Daniel Oberhoff
daniel.oberhoff at gmail.com
On Aug 20, 2014, at 2:54 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Wed, Aug 20, 2014 at 02:42:35PM +0200, Daniel Oberhoff wrote:
>>
>> ---
>> Daniel Oberhoff
>> daniel.oberhoff at gmail.com
>>
>>
>>
>> On Aug 20, 2014, at 2:17 PM, Michael Niedermayer <michaelni at 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.
More information about the ffmpeg-devel
mailing list