Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#1852 closed enhancement (fixed)

libswscale can't handle destination widths below 8

Reported by: gjdfgh Owned by:
Priority: wish Component: swscale
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

libswscale outputs warnings like these if the destination width is below 8:

[swscaler @ 0x8ae9860]1280x720 -> 7x4 is invalid scaling dimension

Change History (11)

comment:1 Changed 5 years ago by cehoyos

  • Priority changed from normal to wish
  • Reproduced by developer set
  • Status changed from new to open
  • Type changed from defect to enhancement

For future reports: Please always provide a command line together with complete, uncut console output to make the reports valid.

$ ffmpeg -i tests/lena.pnm -s 8x3 out.png
ffmpeg version N-46039-g7fe6f6e Copyright (c) 2000-2012 the FFmpeg developers
  built on Oct 26 2012 14:53:11 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      52.  0.100 / 52.  0.100
  libavcodec     54. 69.100 / 54. 69.100
  libavformat    54. 35.100 / 54. 35.100
  libavdevice    54.  3.100 / 54.  3.100
  libavfilter     3. 20.106 /  3. 20.106
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 16.100 /  0. 16.100
  libpostproc    52.  1.100 / 52.  1.100
Input #0, image2, from 'tests/lena.pnm':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: ppm, rgb24, 256x256, 25 tbr, 25 tbn, 25 tbc
Output #0, image2, to 'out.png':
  Metadata:
    encoder         : Lavf54.35.100
    Stream #0:0: Video: png, rgb24, 8x3, q=2-31, 200 kb/s, 90k tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (ppm -> png)
Press [q] to stop, [?] for help
Segmentation fault
cehoyos@lisbeth:~/Projects/cehoyos/FFmpeg> ./ffmpeg -i tests/lena.pnm -s 7x8 out.png
ffmpeg version N-46039-g7fe6f6e Copyright (c) 2000-2012 the FFmpeg developers
  built on Oct 26 2012 14:53:11 with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl
  libavutil      52.  0.100 / 52.  0.100
  libavcodec     54. 69.100 / 54. 69.100
  libavformat    54. 35.100 / 54. 35.100
  libavdevice    54.  3.100 / 54.  3.100
  libavfilter     3. 20.106 /  3. 20.106
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 16.100 /  0. 16.100
  libpostproc    52.  1.100 / 52.  1.100
Input #0, image2, from 'tests/lena.pnm':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: ppm, rgb24, 256x256, 25 tbr, 25 tbn, 25 tbc
[swscaler @ 0x34bd340] 256x256 -> 7x8 is invalid scaling dimension
[swscaler @ 0x34bd340] 256x128 -> 7x4 is invalid scaling dimension
    Last message repeated 1 times
[scaler for output stream 0:0 @ 0x34b2700] Failed to configure output pad on scaler for output stream 0:0
Error opening filters!

comment:2 Changed 5 years ago by gjdfgh

I would consider this rather a bug report than an enhancement request. A good library pays attention to corner cases. Sorry if that sounds ass-holish, but... seriously.

comment:3 Changed 5 years ago by cehoyos

Could you describe your use case?

(Afair this has never worked and a useful error message is shown which makes this an enhancement request imo.)

comment:4 Changed 5 years ago by compn

i think the 8 pixel limitation might also be due to many codecs not supporting a size under that resolution as well.

why support it, if many codecs cannot work ?
(i'm not arguing for or against here, just asking for use case)

comment:5 Changed 5 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from open to closed

Fixed by Michael.

comment:6 Changed 5 years ago by gjdfgh

sws: filterSize 728 is too large, try less extreem scaling or increase MAX_FILTER_SIZE and recompile
sws: initFilter failed

comment:7 Changed 5 years ago by richardpl

  • Resolution fixed deleted
  • Status changed from closed to reopened
> ffmpeg -i ~/git/fate-suite/dxtory/dxtory_mic.avi -s 7x4 /tmp/out.png
ffmpeg version git-2012-10-28-8b99c7c Copyright (c) 2000-2012 the FFmpeg developers
  built on Oct 28 2012 14:29:32 with FreeBSD clang version 3.1 (branches/release_31 156863) 20120523
  configuration: --cc=clang --as=clang --extra-cflags=-fcolor-diagnostics --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/lib --samples=../fate-suite --disable-debug --disable-static --disable-postproc --disable-indev=v4l2 --disable-indev=alsa --disable-indev=bktr --disable-indev=dshow --disable-indev=dv1394 --disable-indev=fbdev --disable-indev=jack --disable-indev=libcdio --disable-indev=libdc1394 --disable-indev=openal --disable-indev=pulse --disable-indev=sndio --disable-indev=vfwcap --disable-outdev=sndio --disable-outdev=alsa --disable-outdev=sdl --disable-doc --enable-nonfree --enable-openssl --enable-gpl --enable-shared --enable-libx264 --enable-libmp3lame --enable-libschroedinger --enable-x11grab --enable-libopenjpeg --enable-libfdk-aac --enable-libvorbis --enable-libtheora --enable-libvpx
  libavutil      52.  1.100 / 52.  1.100
  libavcodec     54. 69.100 / 54. 69.100
  libavformat    54. 35.100 / 54. 35.100
  libavdevice    54.  3.100 / 54.  3.100
  libavfilter     3. 20.106 /  3. 20.106
  libswscale      2.  1.101 /  2.  1.101
  libswresample   0. 16.100 /  0. 16.100
Guessed Channel Layout for  Input Stream #0.1 : stereo
Guessed Channel Layout for  Input Stream #0.2 : stereo
Input #0, avi, from '/home/r/git/fate-suite/dxtory/dxtory_mic.avi':
  Metadata:
    encoder         : DxtoryCore ver2.0.0.109
    ISRC            : Video:YUV420 Audio0:Lautsprecher (Realtek High Definition Audio) Audio1:Mikrofon (Realtek High Definition Audio)
  Duration: 00:00:07.48, start: 0.000000, bitrate: 1496 kb/s
    Stream #0:0: Video: dxtory (xtor / 0x726F7478), yuv420p, 1280x720, 25 tbr, 25 tbn, 25 tbc
    Stream #0:1: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s
    Stream #0:2: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 48000 Hz, stereo, s16, 1536 kb/s
sws: filterSize 728 is too large, try less extreem scaling or increase MAX_FILTER_SIZE and recompile
sws: initFilter failed
sws: filterSize 728 is too large, try less extreem scaling or increase MAX_FILTER_SIZE and recompile
sws: initFilter failed
sws: filterSize 728 is too large, try less extreem scaling or increase MAX_FILTER_SIZE and recompile
sws: initFilter failed
[scaler for output stream 0:0 @ 0x2a00c480] Failed to configure output pad on scaler for output stream 0:0
Error opening filters!

comment:8 Changed 5 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from reopened to closed

Please recompile with increased MAX_FILTER_SIZE if you need down-scaling with a higher factor than the supported default value.

You did not explain your use case, so I assume it must be very unusual and most people will prefer a faster libswscale that does not support arbitrary scaling factors.

comment:9 follow-up: Changed 5 years ago by gjdfgh

Looks like when downscaling to 1x1, libswscale wants to create a filter that's as large as the width and height of the source image, but the filter size is statically limited to 256 by default.

Definitely not the same bug, but still could be considered a bug. Should stay closed.

You did not explain your use case, so I assume it must be very unusual and most people will prefer a faster libswscale that does not support arbitrary scaling factors.

I think people would prefer a libswscale that doesn't blow up on dozens of corner cases and sacrifices bug-freeness for uncompromised speed, but that's just my opinion. The fact that libswscale suddenly fails when the scaling factor is too high is just one example.

comment:10 in reply to: ↑ 9 Changed 5 years ago by cehoyos

Replying to gjdfgh:

I think people would prefer a libswscale that doesn't blow up on dozens of corner cases and sacrifices bug-freeness for uncompromised speed, but that's just my opinion. The fact that libswscale suddenly fails when the scaling factor is too high is just one example.

I suspect that libswscale is mostly used for video (or image) input, in its default configuration it supports downscaling from 1920x1080 to 32x18 which I already find hard to imagine as a real-world use-case. (As you correctly pointed out, this limitation existed before and after the patch that fixed this ticket and is unrelated.)
Whoever needs higher scaling ratios can easily fix the limitation by recompiling FFmpeg.

If you believe that I am wrong, please suggest that the default gets increased, but imo you should at least outline what the use-case might be. (Note that there are hundreds of known bugs in the FFmpeg libraries that describe if not every-day so at least common use-cases so concentrating on true "corner cases" is probably not such a good idea given that man-power is the only limiting factor in FFmpeg development.)

(Otoh, maybe we now have to support downscaling from common camera resolutions to X-Face, so my reasoning may be completely wrong.)

comment:11 Changed 5 years ago by compn

someone mentioned that dvd vobsubs can be scaled with ffmpeg.
maybe thats the reason for these smaller resolutions.

Note: See TracTickets for help on using tickets.