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

[rogerdpack]

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

[cehoyos]

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

[rogerdpack]

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!

[cehoyos]

Try

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

or

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

[rogerdpack]

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.

Similarly, converting from mostly_white.bmp -> ffv1 out.avi -> back to bmp results in a white image all the way through, so I'm not sure what's going on.

[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).

[rogerdpack]

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

[michael]

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