[FFmpeg-user] Changing the crop filter's output width over time?

[John Hawkinson]

Gyan Doshi <ffmpeg at gyani.pro> wrote on Sun, 26 Apr 2020
at 02:03:23 EDT in <76dff16c-331a-534c-fe28-558dae8a8d5b at gyani.pro>:

> The temporal parameters t, n and pos are only applicable for x and y
> expressions. At present, the only way to vary w and h over time is by
> sending commands with varying constants for w/h. Not very convenient, I
> know. Open a ticket if you want an enhancement for the crop filter.

Thanks, that's clear enough.

It would appear that there is both a documentation bug (the crop filter's doc says "The out_w, out_h, x, y parameters are expressions containing the following constants" and includes a list with n, pos, and t), and also either bugs or odd limitations in the error reporting.

These errors don't seem to make sense:

  Undefined constant or missing '(' in 'T'
    Error when evaluating the expression '1146+T'
  
  Unknown function in 'T*(1920-1146)'
    Error when evaluating the expression '1146+T*(1920-1146)'

  Error when evaluating the expression '1146+t'

Upon further review, I wonder if the parser is trying to parse T as the 10^9 SI prefix, although that doesn't quite explain it. And there's not even a detailed error message for the '1146+t' form.


As for code enhancements, it seems to me that it would be more valuable to focus on the zoompan filter?

For instance, I would like to:

* give it a duration for the entire zoom effect (in frames or seconds, just like fade and oher filters

* specify a starting and ending zoom factor, rather than the current zoom factor and calculate an expression to
parameterize steps, which needs clip() or max() and other awkward functions

* Not force me hard-code the fps. Since fps isn't available in the expression parser, there seesm no way to make zoompan operate properly on video input without a preprocessing step to check the fps of the input video.

* Similarly, a way to not hard-code the resolution, although I assume s=(iw)x(ih) might work, although maybe the parser wouldn't be happy?

It also seems the filter could use a clearer definition than "Apply Zoom & Pan effect."

Philosophically, I kind of wonder why "crop", "scale", and "zoompan" are 3 separate filters. It would seem that "zoompan" could do the same work as a chain of crop and scale, so I have to imagine one method is more efficeint than the other, but the arbitrary differences in parameters and evaluable expressions just feel odd.

Maybe I'm missing something.

Thanks.

--
jhawk at alum.mit.edu
John Hawkinson
+1 617 797 0250