On Wed, Aug 20, 2014 at 02:36:29PM +0200, Daniel Oberhoff wrote: > > --- > Daniel Oberhoff > daniel.oberh...@gmail.com > > > > On Aug 20, 2014, at 2:33 PM, Michael Niedermayer <michae...@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.
sure > 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 thanks [...] -- 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.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
