ffplay seems to "darken" certain inputs (ex: bgr24)

[Roger Pack]

Hello all. First time here, and first of all thank you for a
marvelous program in ffmpeg.

I have noted the following behavior:

With this bmp (bgr24) [1], if I use ffplay on it ($ ffplay mostly_white.bmp), the white border displays
"darkened" or "with an added red hue" for whatever reason (you can see this effect within the image itself).

[1] ​http://rogerdpack.t28.net/incoming/mostly_white.bmp the "white"
outermost backgrounded window looks somewhat red (here's an
example output ​http://rogerdpack.t28.net/incoming/red_hue.bmp to compare)

Here's the command line output (mingw build, but it seems to reproduce
with all platform/versions I have tried).

$ ffplay version N-31706-g335bbe4, Copyright (c) 2003-2011 the FFmpeg developers

built on Jul 31 2011 18:52:06 with gcc 4.6.1
configuration: --enable-gpl --enable-version3 --enable-memalign-hack

--enable-runtime-cpudetect --enable-avisynth --enable-bzlib
--enable-frei0r --enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-libfreetype --enable-libgsm --enable-libmp3lame
--enable-libopenjpeg --enable-librtmp --enable-libschroedinger
--enable-libspeex --enable-libtheora --enable-libvorbis
--enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid
--enable-zlib

libavutil 51. 11. 1 / 51. 11. 1
libavcodec 53. 9. 0 / 53. 9. 0
libavformat 53. 6. 0 / 53. 6. 0
libavdevice 53. 2. 0 / 53. 2. 0
libavfilter 2. 27. 5 / 2. 27. 5
libswscale 2. 0. 0 / 2. 0. 0
libpostproc 51. 2. 0 / 51. 2. 0

Input #0, image2, from 'mostly_white.bmp':

Duration: 00:00:00.04, start: 0.000000, bitrate: N/A

Stream #0.0: Video: bmp, bgr24, 1680x1050, 25 tbr, 25 tbn, 25 tbc

[buffersink @ 03C05D40] auto-inserting filter 'auto-inserted scaler 0'
between the filter 'src' and the filter 'out'
[scale @ 03C06280] w:1680 h:1050 fmt:bgr24 -> w:1680 h:1050
fmt:yuv420p flags:0x4

[Carl Eugen Hoyos]

Do I understand correctly that you can only reproduce your problem with ffplay, not with ffmpeg?

[Roger Pack]

in the one test I did with ffmpeg it didn't appear to be present. Howevever, I wasn't sure how to insert the bgr24 -> yuv420p filter so I'm not 100% sure.
Thanks!

[Carl Eugen Hoyos]

Try

ffmpeg -i mostly_white.bmp -vcodec ffv1 out.avi

or

ffmpeg -i mostly_white.bmp -qscale 2 out.avi

[Roger Pack]

Interestingly

ffmpeg -y -f dshow -i video="screen-capture-recorder" -f dshow -i audio="virtual-audio-capturer" -r 30 -t 20 -vcodec huffyuv "G:\yo.avi"
ffmpeg version N-32726-ga254452, Copyright (c) 2000-2011 the FFmpeg developers
Input #0, dshow, from 'video=screen-capture-recorder':
  Duration: N/A, start: 305101.060000, bitrate: N/A
    Stream #0.0: Video: rawvideo, bgr24, 794x546, 0.08 tbr, 10000k tbn, 10000k tbc
Incompatible pixel format 'bgr24' for codec 'huffyuv', auto-selecting format 'yuv422p'

creates files that are (apparently) yuv422p that show up as "working, normal, pure white" in avidemux, but if played back in mplayer/ffplay/vlc the whites are RGB(235,235,235) and the blacks are RGB(16,16,16). Maybe mplayer/VLC are using the same thing ffplay is and hence similarly display poorly? mplayer's only converter is

[swscaler @ 01291d34]using unscaled yuv422p -> yuyv422 special converter

so I wouldn't have anticipated problems, so not sure. Also mplayer has the same "hue" problem with directx/direct3d/sdl so that makes me suspect it's not an SDL thing.

[reimar]

IMHO I think this is a "wontfix".
What is going on is that SDL only supports YUV. It also assumes that YUV is the limited TV-range one.
When converting from full-range RGB that results in wrong colors.
It also results in wrong colors for HD content I think.
You might be able to configure your graphics card to display video as full-range content, which should avoid this.
You can see a similar (though looks weaker to me) effect if you compare
mplayer mf://mostly_white.bmp -loop 0 -vo gl
mplayer -vf format=yv12 mf://mostly_white.bmp -loop 0 -vo gl
(the first should display the RGB as it is, the second one will convert to YUV as ffplay does, though with some differences in the details - if -vo gl does not work for you, -vo direct3d should show the same behaviour).

[Roger Pack]

ok sounds like the situation has been ascertained well. thanks!

[Michael Niedermayer]

I disagree that this shoudl be "wontfix", yes its a limitation in SDL but we could workaround it so at least this should be a feature request

[Michael Niedermayer]

​http://rogerdpack.t28.net/incoming/mostly_white.bmp is 404

[Roger Pack]

normal "all white" bmp

[Roger Pack]

OK uploaded. It appears that if ffmpeg get input of "white.bmp" and convert it to "white.loop.avi" (also attached) like this:

$ ffmpeg -loop 1 -i white.bmp -t 10 -y white.loop.avi
ffmpeg version 2.8.4 Copyright (c) 2000-2015 the FFmpeg developers
  built with Apple LLVM version 7.0.2 (clang-700.1.81)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/2.8.4 --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-opencl --enable-libx264 --enable-libmp3lame --enable-libvo-aacenc --enable-libxvid --enable-ffplay --enable-vda
  libavutil      54. 31.100 / 54. 31.100
  libavcodec     56. 60.100 / 56. 60.100
  libavformat    56. 40.101 / 56. 40.101
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 40.101 /  5. 40.101
  libavresample   2.  1.  0 /  2.  1.  0
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.101 /  1.  2.101
  libpostproc    53.  3.100 / 53.  3.100
Input #0, bmp_pipe, from 'white.bmp':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: bmp, pal8, 256x256, 25 fps, 25 tbr, 25 tbn, 25 tbc
Output #0, avi, to 'white.loop.avi':
  Metadata:
    ISFT            : Lavf56.40.101
    Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p, 256x256, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.60.100 mpeg4
Stream mapping:
  Stream #0:0 -> #0:0 (bmp (native) -> mpeg4 (native))
Press [q] to stop, [?] for help
frame=  250 fps=0.0 q=2.0 Lsize=      44kB time=00:00:10.00 bitrate=  36.2kbits/s
video:33kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 35.687309%

the resultant video file is yuv420p and is "good" (if I play it with mplayer, the screen is white). So ffmpeg conversion is OK.

However, if I then play that file with ffplay, the output is greyed again, even though the input is yuv420p. So this may be a more general problem in/of ffplay than just bgr24 input, FWIW. Thanks!

[Clément Bœsch]

Is this better with SDL2 now?

ffplay seems to have native SDL BGRA output now (since 9c5fab5ed421da4e55cafcbff0482e1ad926c27b).

[Carl Eugen Hoyos]

Replying to ubitux:

Is this better with SDL2 now?

ffplay seems to have native SDL BGRA output now (since 9c5fab5ed421da4e55cafcbff0482e1ad926c27b).

Are you sure that this rgb output is used for bgr24 input (the pix_fmt used as example in this ticket)?