crop filter can't do single pixel width

[adaerr]

Summary of the bug:

When trying to crop a rectangle that is one pixel wide (-vf crop=1:70), ffmpeg aborts without output with the error

[Parsed_crop_0 @ 0x55fc84e75600] Invalid too big or non positive size for width '0' or height '70'
[Parsed_crop_0 @ 0x55fc84e75600] Failed to configure input pad on Parsed_crop_0

Expected was an output frame of width=1 by height=70 pixel from the input stream. Two pixels or more for the width work fine.

How to reproduce:

% ffmpeg -i input -vf crop=1:70 -vframes 1 slice.png
ffmpeg version 4.1.1-1 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8 (Debian 8.2.0-20)

[full log attached]

This bug is also observed with a synthetic video source, e.g.

ffmpeg -f lavfi -i color -vf crop=1:70 -vframes 1 slice.png

Curiously, "crop=70:1" (i.e. single pixel height) produces an error as well with the synthetic video, but works fine with the sample source I used (in other words, I am able to make single pixel high captures although not from the lavfi input).

I reproduced the bug with an ffmpeg built from the current git master:

ffmpeg version N-93476-g391f884675 Copyright (c) 2000-2019 the FFmpeg developers
  built with gcc 8 (Debian 8.3.0-2)

Attached is the full log generated with the git build using the "-report" option. Here are some potentially relevant lines:

Command line:
./ffmpeg -report -f lavfi -i color -vf "crop=1:70" -vframes 1 slice.png
ffmpeg version N-93476-g391f884675 Copyright (c) 2000-2019 the FFmpeg developers
[...]
Reading option '-vf' ... matched as option 'vf' (set video filters) with argument 'crop=1:70'.
[...]
[Parsed_color_0 @ 0x560e8f6ddf80] size:320x240 rate:25/1 duration:-1.000000 sar:1/1
[...]
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> png (native))
[...]
[Parsed_crop_0 @ 0x560e8f7259c0] Setting 'out_w' to value '1'
[Parsed_crop_0 @ 0x560e8f7259c0] Setting 'out_h' to value '70'
[graph 0 input from stream 0:0 @ 0x560e8f727a80] Setting 'video_size' to value '320x240'
[...]
[format @ 0x560e8f728280] auto-inserting filter 'auto_scaler_0' between the filter 'Parsed_crop_0' and the filter 'format'
[AVFilterGraph @ 0x560e8f725b80] query_formats: 4 queried, 2 merged, 1 already done, 0 delayed
[auto_scaler_0 @ 0x560e8f72b400] picking rgb24 out of 10 ref:yuv420p alpha:0
[Parsed_crop_0 @ 0x560e8f7259c0] w:320 h:240 sar:1/1 -> w:0 h:70 sar:1/1
[Parsed_crop_0 @ 0x560e8f7259c0] Invalid too big or non positive size for width '0' or height '70'
[Parsed_crop_0 @ 0x560e8f7259c0] Failed to configure input pad on Parsed_crop_0
Error reinitializing filters!
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #0:0
Conversion failed!

[adaerr]

log of reported error using ffmpeg from current git master

[Gyan]

The crop filter, by default, constrains output dimensions, taking into account the chroma subsampling scheme of the input. For the common 4:2:0 format, each dimension needs to be even, so, crop will round down odd values. For the case of width 1, that's rounded to 0, which is, of course, invalid. Your input is probably 4:2:2, for which there is no constraint on values for height.

To override this behaviour, set option exact to 1 i.e.

-vf "crop=1:70:exact=1"

Although you'll get an error from encoders like x264 which require even dimensions for 4:2:0 input. JPEG output should be fine.

[adaerr]

Additional observation:
The bug is not observed when using lavfi's testsrc instead of color. That is,

ffmpeg -report -f lavfi -i testsrc -vf crop=1:70 -vframes 1 -y slice.png

runs fine, producing the expected 1x70 PNG image, whereas

ffmpeg -report -f lavfi -i color -vf crop=1:70 -vframes 1 -y slice.png

as mentioned in the initial report fails with an error. Inspecting the logs reveals that the second variant leads to the auto-insertion of an auto_scaler_0 into the filtergraph, which is not the case in the first variant. Just after that, Parsed_crop_0 reports its configuration as "[Parsed_crop_0 @ 0x55d8e481f540] w:320 h:240 sar:1/1 -> w:0 h:70 sar:1/1" (see log attached with original message) and produces a fatal error, while the corresponding line in the output of the testsrc variant above reads "[Parsed_crop_0 @ 0x55dea412be00] w:320 h:240 sar:1/1 -> w:1 h:70 sar:1/1". Small but essential difference...

[adaerr]

Thanks for comment #1, Gyan. I was busy writing comment #2 which I posted before reading yours. Your explanation also explains the difference between testsrc (rgb24) and color (yuv420p).

[adaerr]

It might be a good idea to add some debug output when (and why) the image dimensions get modified automatically, like in the case at hand. Wasn't aware of the "exact=1" option, thanks.
Keep up the great work on ffmpeg! Cheers A