[FFmpeg-trac] #5083(avcodec:new): Conversion from yuv410p to rgb24 looks wrong

FFmpeg trac at avcodec.org
Fri Dec 11 13:21:36 CET 2015


#5083: Conversion from yuv410p to rgb24 looks wrong
---------------------------------+--------------------------------------
             Reporter:  khali    |                     Type:  defect
               Status:  new      |                 Priority:  normal
            Component:  avcodec  |                  Version:  git-master
             Keywords:           |               Blocked By:
             Blocking:           |  Reproduced by developer:  0
Analyzed by developer:  0        |
---------------------------------+--------------------------------------
 Summary of the bug:
 When generating still pictures from a yuv410p video stream in PNG or BMP
 format, the output looks incorrect. The same still pictures written as
 TIFF or JPEG pictures look right. Given that TIFF and JPEG store the data
 in YUV color space while PNG and BMP use the RGB color space, this makes
 me suspect that the conversion from yuv410p to rgb24 is broken.

 How to reproduce:
 {{{
 % ffmpeg -f lavfi -i "color=color=white:size=16x16" -frames:v 1 -vf
 "format=yuv410p,drawbox=color=red:x=4:y=4:w=8:h=8" -f image2 410p.png
 ffmpeg version N-77180-g45938f0 Copyright (c) 2000-2015 the FFmpeg
 developers
   built with gcc 4.8 (SUSE Linux)
   configuration: --prefix=/opt/ffmpeg --enable-shared --enable-libmp3lame
 --enable-libxvid --enable-postproc --enable-gpl --enable-x11grab --enable-
 avfilter --enable-version3 --enable-libx264 --enable-pthreads --enable-
 libvorbis --enable-libtheora --enable-fontconfig --cpu=corei7 --enable-
 libfaac --enable-nonfree
   libavutil      55. 10.100 / 55. 10.100
   libavcodec     57. 17.100 / 57. 17.100
   libavformat    57. 19.100 / 57. 19.100
   libavdevice    57.  0.100 / 57.  0.100
   libavfilter     6. 20.100 /  6. 20.100
   libswscale      4.  0.100 /  4.  0.100
   libswresample   2.  0.101 /  2.  0.101
   libpostproc    54.  0.100 / 54.  0.100
 Input #0, lavfi, from 'color=color=white:size=16x16':
   Duration: N/A, start: 0.000000, bitrate: N/A
     Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p, 16x16 [SAR
 1:1 DAR 1:1], 25 tbr, 25 tbn, 25 tbc
 Output #0, image2, to '410p.png':
   Metadata:
     encoder         : Lavf57.19.100
     Stream #0:0: Video: png, rgb24, 16x16 [SAR 1:1 DAR 1:1], q=2-31, 200
 kb/s, 25 fps, 25 tbn, 25 tbc
     Metadata:
       encoder         : Lavc57.17.100 png
 Stream mapping:
   Stream #0:0 -> #0:0 (rawvideo (native) -> png (native))
 Press [q] to stop, [?] for help
 [swscaler @ 0x1b9f4c0] Warning: data is not aligned! This can lead to a
 speedloss
 frame=    1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A
 video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
 muxing overhead: unknown
 }}}

 The generated image file does not look good. While the generated pattern
 is fully symmetric, the output image is not. Same problem with 410p.bmp as
 the output. However both 410p.jpg and 410p.tiff look right.

 Also note that format=yuv420p and format=yuv411p both work properly. So
 this is not a generic problem with the YUV to RGB color space conversion,
 rather this seems to be specifically related to yuv410p.

 Converting from yuv410p to yuv420p seems to also be broken, but
 differently. See how
 {{{
 % ffmpeg -f lavfi -i "color=color=white:size=16x16" -frames:v 1 -vf
 "format=yuv410p,drawbox=color=red:x=4:y=4:w=8:h=8,format=yuv420p" -f
 image2 410p_to_420p.tiff
 }}}
 manages to create green pixels from a picture that originally only had
 white and red.

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


More information about the FFmpeg-trac mailing list