#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 by , 12 years ago
Priority: | normal → wish |
---|---|
Reproduced by developer: | set |
Status: | new → open |
Type: | defect → enhancement |
comment:2 by , 12 years ago
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 by , 12 years ago
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 by , 12 years ago
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:6 by , 12 years ago
sws: filterSize 728 is too large, try less extreem scaling or increase MAX_FILTER_SIZE and recompile
sws: initFilter failed
comment:7 by , 12 years ago
Resolution: | fixed |
---|---|
Status: | closed → 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 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → 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.
follow-up: 10 comment:9 by , 12 years ago
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 by , 12 years ago
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 by , 12 years ago
someone mentioned that dvd vobsubs can be scaled with ffmpeg.
maybe thats the reason for these smaller resolutions.
For future reports: Please always provide a command line together with complete, uncut console output to make the reports valid.