YUV->RGB Color Shift

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

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
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: YUV->RGB Color Shift

Carl Eugen Hoyos
Bob Richards <richardsb771 <at> gmail.com> writes:

> ffmpeg -i input_prores.mov -vcodec dpx sample_seq_%03d.dpx

Please add complete, uncut console output.

Carl Eugen

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: YUV->RGB Color Shift

Bob Richards
On Thu, Dec 15, 2011 at 1:31 PM, Carl Eugen Hoyos <[hidden email]> wrote:

> Bob Richards <richardsb771 <at> gmail.com> writes:
>
> > 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%
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: YUV->RGB Color Shift

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
Reply | Threaded
Open this post in threaded view
|

Re: YUV->RGB Color Shift

Carl Eugen Hoyos
rotoman <rotoman <at> gmail.com> writes:

> 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
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: YUV->RGB Color Shift

rotoman
Carl Eugen Hoyos wrote
rotoman <rotoman <at> gmail.com> writes:

> 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
[hidden email]
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!
Reply | Threaded
Open this post in threaded view
|

Re: YUV->RGB Color Shift

Carl Eugen Hoyos
rotoman <rotoman <at> gmail.com> writes:

> Carl Eugen Hoyos wrote
> >
> > rotoman <rotoman <at> gmail.com> writes:
> >
> >> 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

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: YUV->RGB Color Shift

FFmichael
Carl Eugen Hoyos wrote
rotoman <rotoman <at> gmail.com> writes:

> Carl Eugen Hoyos wrote
> >
> > rotoman <rotoman <at> gmail.com> writes:
> >
> >> 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

_______________________________________________
ffmpeg-user mailing list
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: YUV->RGB Color Shift

Carl Eugen Hoyos
FFmichael <michael.rampe <at> gmail.com> writes:

> 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

_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
Reply | Threaded
Open this post in threaded view
|

Re: YUV->RGB Color Shift

Gavin Kinsey
In reply to this post by Carl Eugen Hoyos
On Tuesday 10 January 2012 22:19:00 Carl Eugen Hoyos wrote:
>
> 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.

--
Gavin Kinsey
AD Holdings Plc


This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to whom they are addressed. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system; you may not copy this message or disclose its contents to anyone. The recipient should check this email and any attachments for the presence of viruses. The Company accepts no liability for any damage caused by any virus transmitted by this email. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the Company. Contact Customer Services for details [hidden email]
_______________________________________________
ffmpeg-user mailing list
[hidden email]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user