[FFmpeg-user] YUV->RGB Color Shift

[Bob Richards]

In 0.9 when transcoding from ProRes 4444 to a DPX sequence I am
experiencing a color shift that I believe may be due to the yuv-rgb
conversion. I'm assuming ffmpeg does a video level scale/unscale
operation in these conversions by default but is it possible to
disable this? I did try forcing specific pix_fmts and color_range
options without it affecting much change in my output.

Sample command:
ffmpeg -i input_prores.mov -vcodec dpx sample_seq_%03d.dpx

[Carl Eugen Hoyos]

Post by Bob Richards
ffmpeg -i input_prores.mov -vcodec dpx sample_seq_%03d.dpx

Please add complete, uncut console output.

Carl Eugen

[Bob Richards]

Post by Carl Eugen Hoyos

Post by Bob Richards
ffmpeg -i input_prores.mov -vcodec dpx sample_seq_%03d.dpx

Please add complete, uncut console output.
Carl Eugen
_______________________________________________

$ ffmpeg -i A033C005.mov -vcodec dpx sample_seq_%03d.dpx
ffmpeg version 0.9, Copyright (c) 2000-2011 the FFmpeg developers
built on Dec 14 2011 15:50:52 with clang 2.0 (tags/Apple/clang-139)
configuration: --prefix=/usr/local/Cellar/ffmpeg/0.9 --enable-shared
--enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables
--cc=/usr/bin/clang --enable-libx264 --enable-libfaac --enable-libmp3lame
--enable-libtheora --enable-libvorbis --enable-libvpx --enable-libxvid
--disable-ffplay
libavutil 51. 32. 0 / 51. 32. 0
libavcodec 53. 42. 0 / 53. 42. 0
libavformat 53. 24. 0 / 53. 24. 0
libavdevice 53. 4. 0 / 53. 4. 0
libavfilter 2. 53. 0 / 2. 53. 0
libswscale 2. 1. 0 / 2. 1. 0
libpostproc 51. 2. 0 / 51. 2. 0

Seems stream 0 codec frame rate differs from container frame rate: 23976.00
(23976/1) -> 23.98 (2997/125)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'A033C005.mov':
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt ARRI
creation_time : 2011-12-13 19:50:02
Duration: 00:00:11.26, start: 0.000000, bitrate: 281199 kb/s
Stream #0:0(eng): Video: prores (ap4h / 0x68347061), yuv444p10le,
1920x1080, 277332 kb/s, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 23976 tbn,
23976 tbc
Metadata:
creation_time : 2011-12-13 19:50:02
handler_name : ?Apple Alias Data Handler
Stream #0:1(eng): Data: none (tmcd / 0x64636D74)
Metadata:
creation_time : 2011-12-13 19:50:02
handler_name : ?Apple Alias Data Handler
Incompatible pixel format 'yuv444p10le' for codec 'dpx', auto-selecting
format 'rgb48le'
[buffer @ 0x101613820] w:1920 h:1080 pixfmt:yuv444p10le tb:1/1000000
sar:1/1 sws_param:
[buffersink @ 0x101613aa0] auto-inserting filter 'auto-inserted scale 0'
between the filter 'src' and the filter 'out'
[scale @ 0x101613e80] w:1920 h:1080 fmt:yuv444p10le -> w:1920 h:1080
fmt:rgb48le flags:0x4
Output #0, image2, to 'sample_seq_%03d.dpx':
Metadata:
major_brand : qt
minor_version : 537199360
compatible_brands: qt ARRI
creation_time : 2011-12-13 19:50:02
encoder : Lavf53.24.0
Stream #0:0(eng): Video: dpx, rgb48le, 1920x1080 [SAR 1:1 DAR 16:9],
q=2-31, 200 kb/s, 90k tbn, 23.98 tbc
Metadata:
creation_time : 2011-12-13 19:50:02
handler_name : ?Apple Alias Data Handler
Stream mapping:
Stream #0:0 -> #0:0 (prores -> dpx)
Press [q] to stop, [?] for help
frame= 27 fps= 2 q=0.0 Lsize= 0kB time=00:00:01.12 bitrate=
0.0kbits/s
video:328094kB audio:0kB global headers:0kB muxing overhead -100.000000%

[rotoman]

Hi,

I'm having the same problem. The reason is simple: the Prores 4444 is RGB
and not YUV. FFmpeg assumes it's YUV and converts to RGB.

Is there a way to force ffmpeg to treat the input as RGB? Otherwise I'll
just file a bug report...

Thanks

R

--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/YUV-RGB-Color-Shift-tp4202084p4283251.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.

[Carl Eugen Hoyos]

Post by rotoman
I'm having the same problem. The reason is simple: the Prores 4444 is RGB
and not YUV. FFmpeg assumes it's YUV and converts to RGB.

Please provide a sample.

Carl Eugen

[rotoman]

Post by Carl Eugen Hoyos

Post by rotoman
I'm having the same problem. The reason is simple: the Prores 4444 is RGB
and not YUV. FFmpeg assumes it's YUV and converts to RGB.

Please provide a sample.
Carl Eugen
_______________________________________________
ffmpeg-user mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Here is a sample Prores 4444 footage, with RGB encoding.

http://www.mynahmedia.com/videos/AlexaCafe709.mov (approx. 20 MB)

Thanks!


--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/YUV-RGB-Color-Shift-tp4202084p4283472.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.

[Carl Eugen Hoyos]

Post by rotoman

Post by Carl Eugen Hoyos

Post by rotoman
I'm having the same problem. The reason is simple: the Prores 4444 is RGB
and not YUV. FFmpeg assumes it's YUV and converts to RGB.

Please provide a sample.

Here is a sample Prores 4444 footage, with RGB encoding.

There is a misunderstanding, sorry!

You mean that the colour dynamics are wrong, is that correct?
("video level" or "MPEG vs JPEG" etc.)
Red is red for you, but you think it is too red (or not red enough)?

There is a color_range option that should affect this conversion, some users
reported it does not work correctly, a reproducible bug report would be nice.

You can try to force PIX_FMT_YUVJ444P in the decoder, if this is needed for all
samples, consider sending a patch to ffmpeg-devel.

If the encoding is "RGB" instead of "YUV" (this is possible for example with
H264 and JPEG2000), red, green and blue become completely different colours.

Carl Eugen

[FFmichael]

Post by Carl Eugen Hoyos

Post by rotoman

Post by Carl Eugen Hoyos

Post by rotoman
I'm having the same problem. The reason is simple: the Prores 4444 is

RGB

Post by Carl Eugen Hoyos

Post by rotoman
and not YUV. FFmpeg assumes it's YUV and converts to RGB.

Please provide a sample.

Here is a sample Prores 4444 footage, with RGB encoding.

There is a misunderstanding, sorry!
You mean that the colour dynamics are wrong, is that correct?
("video level" or "MPEG vs JPEG" etc.)
Red is red for you, but you think it is too red (or not red enough)?
There is a color_range option that should affect this conversion, some users
reported it does not work correctly, a reproducible bug report would be nice.
You can try to force PIX_FMT_YUVJ444P in the decoder, if this is needed for all
samples, consider sending a patch to ffmpeg-devel.
If the encoding is "RGB" instead of "YUV" (this is possible for example with
H264 and JPEG2000), red, green and blue become completely different colours.
Carl Eugen
_______________________________________________
ffmpeg-user mailing list
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Prores4444 can be EITHER RGB or Y'CbCr (usually incorrectly referred to as
YUV;-) This is dependent on the origination of the footage and the
editing/conversion software. (Historically speaking, 4:4:4 referred to
Y'CbCr only)

If FFmpeg really was decoding RGB as Y'CbCr you would notice things to be a
whole lot stranger than a simple color shift.

FFmichael


--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/YUV-RGB-Color-Shift-tp4202084p4283796.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.

[Carl Eugen Hoyos]

Post by FFmichael
Prores4444 can be EITHER RGB or Y'CbCr (usually incorrectly referred to as
YUV This is dependent on the origination of the footage and the
editing/conversion software. (Historically speaking, 4:4:4 referred to
Y'CbCr only)
If FFmpeg really was decoding RGB as Y'CbCr you would notice things to be a
whole lot stranger than a simple color shift.

FFmpeg always interprets Prores4444 as Y'CbCr (YUV444P in FFmpeg terms), if
there really are RGB samples, please provide one.

Carl Eugen

[Gavin Kinsey]

Post by Carl Eugen Hoyos
You mean that the colour dynamics are wrong, is that correct?
("video level" or "MPEG vs JPEG" etc.)
Red is red for you, but you think it is too red (or not red enough)?
There is a color_range option that should affect this conversion, some
users reported it does not work correctly, a reproducible bug report
would be nice.

libswscale doesn't actually use the color_range value currently, it only
looks at the pixel format. YUVJ vs YUV pixel formats. The color_range is
only in the AVCodecContext, which libswscale never sees so it can't use it.