vf_crop filter breaks setting variables like x=x+1

[Alan Amaral]

Summary of the bug:
If you create a filter graph with a crop filter, and zmq enabled, you can't set any of the values, x, y as recursive expressions, like x=x+1. In the overlay filter you can set x=x+1 and for each frame the value of x is increased by 1, and automatically pans the video, for example. This does not work with the crop filter. Setting x=10 works, as does setting x=10+10 but setting x=x+10 doesn't work and breaks things. In fact, as far as I can tell setting x or y to any expression involving x or y, like x=x or y=y, which should leave the positions unchanged, doesn't give the expected results. Setting x=x or y=y seems to set the x,y position to the center of the input area. This looks intentional given this code from vf_crop.c:

{"x", "set the x crop area expression", OFFSET(x_expr), AV_OPT_TYPE_STRING, {.str = "(in_w-out_w)/2"}, 0, 0, TFLAGS },
{"y", "set the y crop area expression", OFFSET(y_expr), AV_OPT_TYPE_STRING, {.str = "(in_h-out_h)/2"}, 0, 0, TFLAGS },

but seems to make absolutely no sense, given that other filters (such as vf_overlay) allow recursive variable expressions, like x=x+1, which cause the x value to increase by 1 for each frame, and x=x causes the motion to stop.

How to reproduce:
Build an ffmpeg command with a crop filter and try to control the x and y position using zmqsend.
Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

[Gyan]

Yeah, changing x and y through commands would need to be handled differently. Currently all commands are treated effectively as reinit of all filter state variables.

I'll send a patch for this soon-ish.

[Alan Amaral]

It would also be great if there was a way to change X and Y at the same time. My current use case shows a stair-step effect when I pan diagonally because I have to step in the X direction, then the Y direction.