ffplay: workaround libsdl's bug with odd width/height

[ami_stuff]

​http://bugzilla.libsdl.org/show_bug.cgi?id=652

Currectly ffplay displays incorrectly odd-sized video due to libsdl's bug.
I think it would be good to automaticly insert scale filter and round the size to even width/height when the input have odd width/height.

ffplay -vf 1024x768 odd.jpg

C:\>ffplay odd.jpg
ffplay version N-40593-g6d37634 Copyright (c) 2003-2012 the FFmpeg developers
  built on May 11 2012 12:12:53 with gcc 4.6.3
  configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-ru
ntime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass
 --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable
-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libope
njpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libth
eora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-
libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --e
nable-zlib
  libavutil      51. 50.100 / 51. 50.100
  libavcodec     54. 21.101 / 54. 21.101
  libavformat    54.  4.100 / 54.  4.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 72.105 /  2. 72.105
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 11.100 /  0. 11.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, image2, from 'odd.jpg':
  Duration: 00:00:00.04, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: mjpeg, yuvj420p, 1023x767, 25 tbr, 25 tbn, 25 tbc
[format @ 02253620] auto-inserting filter 'auto-inserted scale 0' between the fi
lter 'src' and the filter 'format'
1337435061.92 A-V:  0.000 fd=   0 aq=    0KB vq=   65[scale @ 02253be0] w:1023 h
:767 fmt:yuvj420p sar:0/1 -> w:1023 h:767 fmt:yuv420p sar:0/1 flags:0x4
   1.34 A-V:  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0

[ami_stuff]

ffplay -vf 1024x768 odd.jpg

should be

ffplay -vf scale=1024:768 odd.jpg

[Carl Eugen Hoyos]

I cannot reproduce libsdl bug 652 here with 1.2.12, ffplay's output of test32bf.bmp looks like with ImageMagick for me (and not like ffplay-test32bf.png), I therefore assume it is not a good idea to unconditionally scale the input.

[Stefano Sabatini]

Tested with libsdl 1.2.14+ffplay on Ubuntu, seems to work just fine, so I wonder if they fixed it upstream. Please show the libsdl version number, I don't know if it would be an acceptable hack to rescale based on libsdl version (much better would be to support an alternative display engine).

On the other hand testing with the sdl output device (ffmpeg -i IN -pix_fmt yuv420p -f sdl out) shows the same artifacts, so maybe there is some way to avoid the problem which can be spotted by checking the differences between the two implementations.

[ami_stuff]

I see this (ffplay.png) with SDL 1.2.15 on MinGW.

[Michael Niedermayer]

I can reproduce this issue with ffplay and 1.2.14 on ubuntu so it seems theres some other aspect to this than just the SDL version

[Marton Balint]

I can't reproduce the corruption, maybe the video driver is also involved in the issue.

Can you try the attached patch?

[ami_stuff]

Replying to cus:

I can't reproduce the corruption, maybe the video driver is also involved in the issue.

Can you try the attached patch?

Your patch fixes the problem, thanks.

[Carl Eugen Hoyos]

Not reproducible with SDL 1.2.13 and current FFplay git head here.

[Marton Balint]

Patch with cropping instead of scaling

[Marton Balint]

Can you also try the patch which crops the video instead of scaling it?

[ami_stuff]

I can't test because I deleted by mistake old shapshot and it takes too much time to configure and compile ffmpeg again, but if the patch works for Michael then it should probably work for me as well. I will test with autobuilds when the patch hits git head.

[Carl Eugen Hoyos]

Is it a possible alternative to use padding instead of cropping (which effectively removes a part of the output)?

[Marton Balint]

Basically it is, at the cost of some performance.

I finally decided to use crop because at the moment the padding filter copies the buffer even when no actual padding is required, because it always checks for AV_PERM_WRITE permission.

[Carl Eugen Hoyos]

Fixed by Marton.