Opened 12 years ago
Last modified 12 years ago
#2407 new defect
Conversion from yuv to RGB leads to broken gradients and colors.
Reported by: | Björn Sonnenschein | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | swscale |
Version: | git-master | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
If you convert a yuv source to RGB, the image is gets broken up. There appears a slight overall color tint as well as a little change in brightness and depending on the input pixel format heavy banding.
How to reproduce:
ffmpeg -i dnxhd.mov -vcodec libx264 -b:v 100000k -vf format=rgb24 dnxhdconv.mov ffmpeg version 1.2 built on Mar 25 2013 21:47:38 with gcc 4.7 (Ubuntu/Linaro 4.7.2-2ubuntu1)
Download the example file from here:
http://www.mediafire.com/?3hk4w4v425d7rwb
Use the command and look at the relatively dark, flat sufaces.
You can make a countercheck by using:
ffmpeg -i dnxhd.mov -vcodec libx264 -b:v 100000k -vf format=bgr24 dnxhdconv.mov
Which will not show the problem, so it's not a mathematical issue of rounding values during conversion, but a unique issue of the rgb24 conversion.
This is a dnxd 10-bit file. I have also tested 8 bit limited- and 8 bit fullscale videos and the problem shows up there too, but not that strong.
I will post full terminal output as soon as I get my complete system running. It's broken at the moment.
Attachments (1)
Change History (11)
comment:1 by , 12 years ago
Version: | 1.2 → git-master |
---|
comment:2 by , 12 years ago
If you transcode the first frame of your input file to v210 or ffv1, is the output file sufficient to reproduce the problem when converting to bmp? If yes, please attach the ffv1 (or v210) file.
comment:3 by , 12 years ago
Hmm, converting the v210 or ffv1 to bmp does not reproduce the problem.
But converting the v210 or ffv1 video to an image format that uses rgb24, for example by using
ffmpeg -i ffv1.avi -vf format=rgb24 ffv1.png
reproduces the issue.
by , 12 years ago
comment:5 by , 12 years ago
Replying to cehoyos:
I tested the following:
Please ignore, I apparently overwrote a file while testing.
comment:6 by , 12 years ago
Do I understand correctly that rgb.bmp shows the problem but bgr.bmp does not?
$ ffmpeg -i ffv1.avi -vf format=rgb24 rgb.bmp $ ffmpeg -i ffv1.avi -vf format=bgr24 bgr.bmp
and the same for:
$ ffmpeg -i ffv1.avi -vf format=rgb24 rgb.png $ ffmpeg -i ffv1.avi -vf format=bgr24 bgr.png
comment:8 by , 12 years ago
I suspect this is a duplicate of ticket #1582, sorry for not realizing this earlier.
comment:9 by , 12 years ago
please try:
ffmpeg -i ffv1.avi -sws_flags +full_chroma_int -vf format=rgb24 rgb.png
The default C code is not as accurate as the full_chroma_int or the asm code but later exists just for bgr currently
comment:10 by , 12 years ago
I have tried it and it works. The resulting image is clean!
sun@shine /media/dd624e38-4f22-471f-b835-5d0958a4fbf0/Tests/101TEST_/Schaerfe $ ffmpeg -i ffv1.avi -sws_flags +full_chroma_int -vf format=rgb24 rgb.png ffmpeg version 1.2 Copyright (c) 2000-2013 the FFmpeg developers built on Mar 25 2013 21:47:38 with gcc 4.7 (Ubuntu/Linaro 4.7.2-2ubuntu1) configuration: --enable-gpl --enable-libass --enable-libfaac --enable-libfdk-aac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libspeex --enable-librtmp --enable-libtheora --enable-libvorbis --enable-libvpx --enable-x11grab --enable-libx264 --enable-nonfree --enable-version3 --enable-frei0r --enable-shared 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 libpostproc 52. 2.100 / 52. 2.100 [avi @ 0x25fe380] non-interleaved AVI Input #0, avi, from 'ffv1.avi': Metadata: encoder : Lavf54.63.104 Duration: 00:00:00.04, start: 0.000000, bitrate: 223622 kb/s Stream #0:0: Video: ffv1 (FFV1 / 0x31564646), yuv422p10le, 1920x1080, 25 tbr, 25 tbn, 25 tbc Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 48000 Hz, stereo, s16p, 128 kb/s File 'rgb.png' already exists. Overwrite ? [y/N] y Output #0, image2, to 'rgb.png': Metadata: encoder : Lavf54.63.104 Stream #0:0: Video: png, rgb24, 1920x1080, q=2-31, 200 kb/s, 90k tbn, 25 tbc Stream mapping: Stream #0:0 -> #0:0 (ffv1 -> png) Press [q] to stop, [?] for help frame= 1 fps=0.0 q=0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A video:2708kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.000793%
Checked on git-master, too.
I have to revert the statement that the command
wouldn't show the issue.
In fact I have tried the bgr24 conversion with that command before:
Output:
Which looks good, while doing a conversion to RGB before will look bad.
Blender (www.blender.org) also uses libswscale to convert input yuv videos to PIX_FMT_RGBA and so shows the issue, too.