[FFmpeg-trac] #2452(undetermined:new): decoding yuv420p to rgb shifts luminance down

FFmpeg trac at avcodec.org
Tue Apr 9 04:44:53 CEST 2013


#2452: decoding yuv420p to rgb shifts luminance down
-------------------------------------+-------------------------------------
               Reporter:  burek      |                  Owner:
                   Type:  defect     |                 Status:  new
               Priority:  normal     |              Component:
                Version:             |  undetermined
  unspecified                        |               Keywords:
             Blocked By:             |               Blocking:
Reproduced by developer:  0          |  Analyzed by developer:  0
-------------------------------------+-------------------------------------
 Original post on the forum:
 http://ffmpeg.gusari.org/viewtopic.php?f=11&t=884

 Summary of the bug:
 "I'm recording video from a grayscale camera into an MPEG4 video file
 using FFMPEG 1.2. Recently I noticed a weird effect: if I decode the file
 using FFMPEG or windows media player, the output frames are noticeably
 darker (by about 10/12 brightness values) than the original source."

 How to reproduce:
 {{{
 ffmpeg -ss 0.5 -i video.avi -vframes 1 -t 1 -s 1280x680 -pix_fmt gray
 gray.bmp

 ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers
   built on Apr  4 2013 12:40:58 with gcc 4.6.2 (GCC)
   configuration: --enable-w32threads
   libavutil      52. 18.100 / 52. 18.100
   libavcodec     54. 92.100 / 54. 92.100
   libavformat    54. 63.104 / 54. 63.104
   libavdevice    54.  3.103 / 54.  3.103
   libavfilter     3. 42.103 /  3. 42.103
   libswscale      2.  2.100 /  2.  2.100
   libswresample   0. 17.102 /  0. 17.102
 Input #0, avi, from 'video.avi':
   Metadata:
     encoder         : Lavf53.32.100
   Duration: 00:00:07.47, start: 0.000000, bitrate: 16532 kb/s
     Stream #0:0: Video: mpeg4 (Simple Profile) (FMP4 / 0x34504D46),
 yuv420p, 128
 0x720 [SAR 1:1 DAR 16:9], 30 tbr, 30 tbn, 30 tbc
 Output #0, image2, to 'gray.bmp':
   Metadata:
     encoder         : Lavf54.63.104
     Stream #0:0: Video: bmp, gray, 1280x680 [SAR 17:18 DAR 16:9], q=2-31,
 200 kb
 /s, 90k tbn, 30 tbc
 Stream mapping:
   Stream #0:0 -> #0:0 (mpeg4 -> bmp)
 Press [q] to stop, [?] for help
 frame=    1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.03 bitrate=N/A
 video:851kB audio:0kB subtitle:0 global headers:0kB muxing overhead
 -100.002524%
 }}}

 "I thought the encoding step was doing this until I opened the same file
 in VLC and it gave me back the correct result. I played around with FFMPEG
 command lines to decode a single frame and realized that if I decode a
 frame into GRAY8 pixel format, the brightness/luminance values are
 preserved."

 "This happens with every single grayscale video that I encode to MPEG4
 with FFMPEG. My best guess so far is it has to do with how the container
 pixel format gets converted to/from. Since I'm using MPEG4, the file pixel
 format is YUV420P. I have no idea how ffmpeg encodes from GRAY8 to
 YUV420P, but maybe it stores just the luminance values in Y... if this
 happens, then decoding from this to RGB could produce darker pixels due to
 the shift factor that is applied to the luminance on decoding?

 To sum it up:

 1) How can encoding a grayscale video to YUV420P with FFMPEG and decoding
 back produce wrong (darker) brightness values when decoding to RGB versus
 GRAY8? Presumably once the frames are in YUV420P format it shouldn't
 matter whether the source is actually grayscale or not so the result
 should be equivalent, no?

 2) How does VLC avoid this situation? I was under the impression that VLC
 used FFMPEG as well for video decoding, but somehow they managed to figure
 out how to produce the correct values without requiring me to indicate
 explicitly that the video was grayscale."

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2452>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list