[FFmpeg-devel] [PATCH 3/3] avfilter/vf_lenscorrection: get rid of floats i init code
michaelni at gmx.at
Wed Aug 20 14:55:55 CEST 2014
On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote:
> Daniel Oberhoff
> daniel.oberhoff at gmail.com
> On Aug 20, 2014, at 2:33 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Wed, Aug 20, 2014 at 02:23:10PM +0200, Daniel Oberhoff wrote:
> >> So we prefer int64_t above float32?
> > well, its not exactly making me happy either but its just 2 32x32->64
> > operations per pixel which shouldnt be that bad when we need to do
> > 16 multiplications for bicubic per sample
> > also at the expense of a bit more space they could be precalculated
> > as they dont change between frames
> >> I assumed we stick with 32bits for calculations. Did you test this with very large resolutions?
> > just tried:
> > ./ffplay -f lavfi -i testsrc=s=16385x8192 -vf lenscorrection=0.3:0.2:0.2:0.9,scale=640x48
> > which seems working
> >> I so congratulation :). I am glad I could push you to finish what I failed to do :).
> >> As I would still like to have interpolation, I assume I shall refactor the interpolation out of perspective and rotation instead, right?
> Ok, but by default I would only refactor so far as to support all use cases currently in perspective/rotate/lens_correction, and none more.
> Do you still think there should be a version/versions of the algorithm for packed formats?
i think if we want to add gamma correct interpolation then yes
otherwise its probably not worth the work
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel