[FFmpeg-trac] #437(undetermined:open): ffplay seems to "darken" certain inputs (ex: bgr24)

[FFmpeg]

#437: ffplay seems to "darken" certain inputs (ex: bgr24)
-------------------------------------+-------------------------------------
             Reporter:  rogerdpack   |                    Owner:
                 Type:  defect       |                   Status:  open
             Priority:  normal       |                Component:
              Version:  unspecified  |  undetermined
             Keywords:  ffplay       |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by 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.

-- 
Ticket URL: <http://ffmpeg.org/trac/ffmpeg/ticket/437#comment:4>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker