Opened 5 years ago

Closed 4 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 5 years ago.
ffplay.png (745.5 KB) - added by ami_stuff 5 years ago.
0001-ffplay-fix-odd-YUV-width.patch (2.1 KB) - added by cus 4 years ago.
0001-ffplay-fix-odd-YUV-width-by-cropping-the-video.patch (2.1 KB) - added by cus 4 years ago.
Patch with cropping instead of scaling

Download all attachments as: .zip

Change History (17)

Changed 5 years ago by ami_stuff

comment:1 Changed 5 years ago by ami_stuff

ffplay -vf 1024x768 odd.jpg

should be

ffplay -vf scale=1024:768 odd.jpg

comment:2 Changed 5 years ago by cehoyos

  • Component changed from undetermined to FFplay

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 Changed 5 years ago by saste

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 Changed 5 years ago by ami_stuff

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

Version 1, edited 5 years ago by ami_stuff (previous) (next) (diff)

Changed 5 years ago by ami_stuff

comment:5 Changed 4 years ago by michael

  • 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

Changed 4 years ago by cus

comment:6 follow-up: Changed 4 years ago by cus

  • 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?

comment:7 in reply to: ↑ 6 Changed 4 years ago by 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.

comment:8 Changed 4 years ago by cehoyos

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

Changed 4 years ago by cus

Patch with cropping instead of scaling

comment:9 Changed 4 years ago by cus

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

comment:10 Changed 4 years ago by 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.

comment:11 Changed 4 years ago by cehoyos

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

comment:12 Changed 4 years ago by cus

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 Changed 4 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from new to closed
  • Version changed from unspecified to git-master

Fixed by Marton.

Note: See TracTickets for help on using tickets.