On Mon, Jun 02, 2025 at 11:25:43AM +0200, Quentin RENARD wrote:
> > If this filter is meant to be same as existing zoompan but more precise, 
> > then you should modify the original filter with a mode option for FP use.
> 
> Thing is I hesitated modifying the existing zoompan but there are a few things that don’t fit my use case and I didn’t want to update too many things:
> 
> - frame’s PTS is rewritten
> - configurable output size is not dynamic (and is not evaluated in frame mode)
> - if output aspect ratio is different than input aspect ratio, output image will be stretched
> 
> I can:
> 
> - add an option to enable PTS passthrough
> - add “w” and “h” options on top of “s” options that would allow dynamic output size
> - make sure computed crop size respect output aspect ratio
> 
> Would that be ok?
> 
> > I would suggest to add a 2nd FFFilter entry to
> > libavfilter/vf_perspective.c
> >
> > with a zoompan user interface to access the already existing interpolation code
> > in vf_perspective.c
> >
> > we have bilinear and bicubic interpolation there and it should form a
> > better basis for the implementation
> 
> Reusing vf_perspective.c interpolation implementations seems like a really great idea, I didn’t know they existed.
> 
> However I don’t understand the way you suggest I should do it.
> 

> Are you suggesting I should add “const FFFilter ff_vf_yazp = {}” in “vf_perspective.c” and move the zoompan logic there? If not, maybe what you’re suggesting has already been implemented in another filter and I can use it as an example to understand and reproduce it better?

I guess whats best would be to factor the interpolation code out of
vf_perspective.c into a new file as patch #1
and then use that new factored out code in a new filter that has a zoompan
style user interface in patch #2

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato