Opened 12 years ago

Closed 12 years ago

#1322 closed defect (fixed)

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

Reported by: ami_stuff Owned by:
Priority: normal Component: ffplay
Version: git-master Keywords:
Cc: cus@passwd.hu Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

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

Attachments (4)

odd.jpg (65.0 KB ) - added by ami_stuff 12 years ago.
ffplay.png (745.5 KB ) - added by ami_stuff 12 years ago.
0001-ffplay-fix-odd-YUV-width.patch (2.1 KB ) - added by Marton Balint 12 years ago.
0001-ffplay-fix-odd-YUV-width-by-cropping-the-video.patch (2.1 KB ) - added by Marton Balint 12 years ago.
Patch with cropping instead of scaling

Download all attachments as: .zip

Change History (17)

by ami_stuff, 12 years ago

Attachment: odd.jpg added

comment:1 by ami_stuff, 12 years ago

ffplay -vf 1024x768 odd.jpg

should be

ffplay -vf scale=1024:768 odd.jpg

comment:2 by Carl Eugen Hoyos, 12 years ago

Component: undeterminedFFplay

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.

comment:3 by Stefano Sabatini, 12 years ago

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.

comment:4 by ami_stuff, 12 years ago

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

Last edited 12 years ago by ami_stuff (previous) (diff)

by ami_stuff, 12 years ago

Attachment: ffplay.png added

comment:5 by Michael Niedermayer, 12 years ago

Reproduced by developer: set

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

by Marton Balint, 12 years ago

comment:6 by Marton Balint, 12 years ago

Cc: cus@passwd.hu added

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

Can you try the attached patch?

in reply to:  6 comment:7 by ami_stuff, 12 years ago

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.

comment:8 by Carl Eugen Hoyos, 12 years ago

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

by Marton Balint, 12 years ago

Patch with cropping instead of scaling

comment:9 by Marton Balint, 12 years ago

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

comment:10 by ami_stuff, 12 years ago

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.

comment:11 by Carl Eugen Hoyos, 12 years ago

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

comment:12 by Marton Balint, 12 years ago

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.

comment:13 by Carl Eugen Hoyos, 12 years ago

Resolution: fixed
Status: newclosed
Version: unspecifiedgit-master

Fixed by Marton.

Note: See TracTickets for help on using tickets.