rgb to yuv422p10 color shift PRORES issue

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Encode file with 24bit RGB codec (ex. Apple Animation)
2. encode using following line:

ffmbc.exe -i rgb.mov -threads 16 -vcodec prores -profile hq -pix_fmt yuv444p10 
-acodec copy -vf "format=yuv422p,colormatrix=bt601:bt709" rgb_out.mov

What is the expected output? What do you see instead?

Expected to use cleaner command line, for example:
ffmbc.exe -i rgb.mov -threads 16 -vcodec prores -profile hq -pix_fmt yuv444p10 
-acodec copy rgb_out.mov

Currently this leads to a huge color shift. Some people point out this is 
because of SWS_CS_DEFAULT value in swscale.h - I have altered and recompiled 
with no success. ProresEnc.c also claims to use Rec 709 primaries and matrix 
for HD sized frames. 

-vf "format=yuv422p,colormatrix=bt601:bt709" is a work around but does not 
maintain color precision as the matrix conversion is done in 422 8-bit. This is 
also dangerous because -vf "colormatrix=bt601:bt709" alone falls back on 
yuv420p precision.

Since no professional YUV 444 codecs exist, there is no way to feed ffmbc an 
RGB encoded video and maintain fidelity to ProRes HQ 444. This renders ProRes 
HQ 444 useless as ProRes HQ 422 can be fed a 422 YUV codec and is not prone to 
conversion/precision issues.

Ideally, the longstanding RGB -> YUV color shift should be fixed. Barring that, 
it would be nice to have 444 10-bit precision for the matrix conversion filter. 

What version of the product are you using? On what operating system?
Windows 8, FFMBC 0.7rc8 32-bit and 64-bit

Please provide any additional information below:

C:\Users\Angelo>"C:\Users\name\Desktop\ffmbc.exe" -v 3 -i "D:\watch\green_rgb.
mov" -threads 16 -vf "format=yuv422p,colormatrix=bt601:bt709" -vcodec prores -pr
ofile hq -pix_fmt yuv444p10 -acodec copy "D:\watch2\green_rgb.mov"
FFmbc version 0.7-rc7
Copyright (c) 2008-2012 Baptiste Coudurier and the FFmpeg developers
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'D:\watch\green_rgb.mov':
  Metadata:
    major_brand: qt
    minor_version: 537199360
    compatible_brands: qt
    creation_time: 2013-05-10 10:20:19
    timecode: 00:00:00:00
  Duration: 00:00:01.62, start: 0.000000, bitrate: 500246 kb/s
    Stream #0.0(eng): Video: qtrle, rgb24, 1920x1080p, 500211 kb/s, PAR 1:1 DAR
16:9, 23.98 fps
    Metadata:
      codec_name: Animation
    Stream #0.1(eng): Data: unknown (tmcd)
File 'D:\watch2\green_rgb.mov' already exists. Overwrite ? [y/N] y
[scale @ 03742660] w:1920 h:1080 fmt:rgb24 -> w:1920 h:1080 fmt:yuv422p flags:0x
4
[colormatrix @ 03737B00] bt601 -> bt709
[scale @ 03742200] w:1920 h:1080 fmt:yuv422p -> w:1920 h:1080 fmt:yuv444p10le fl
ags:0x4
Output #0, mov, to 'D:\watch2\green_rgb.mov':
  Metadata:
    encoder: FFmbc 0.7
    Stream #0.0(und): Video: prores, yuv444p10le, 1920x1080p [PAR 1:1 DAR 16:9],
 263977 kb/s, 23.98 fps
Stream mapping:
  Stream #0.0 -> #0.0
Press [q] to stop, [?] for help
frame=    5 fps= 19 q=1.0 size=    5614kB time=00:00:00.20 bitrate=220531.6kbits
.....
s/s
video:43777kB audio:0kB global headers:0kB muxing overhead 0.002324%

---

FFMPEG's legacy ProRes encoder (not prores_kostya) seems to handle RGB material 
without a color shift but it is limited to yuv422p10. It may be a place to 
revisit when crafting a solution.

ffmpeg.exe -i rgb.mov -threads 16 -vcodec prores -profile:v 3 -acodec copy 
rgb_out.mov"

Original issue reported on code.google.com by [email protected] on 10 May 2013 at 10:17

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Correction, no professional yuv 444 *10-bit codecs exist. Quicktime's 410 comes 
close but is, basically, supported by nothing.

Also tested with 10-bit RGB codecs like AJA's, same fidelity and color shifting 
issues.

Original comment by [email protected] on 10 May 2013 at 11:23

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Seems like I've come across a better solution. "-color_primaries bt470bg" as an 
argument after input seems like a cleaner conversion (whatever it's doing 
exactly, I've yet to look in source) with no minute color shift and better 
accuracy than the video filter color matrix.

Original comment by [email protected] on 11 May 2013 at 10:38

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

"FFMPEG's legacy ProRes encoder (not prores_kostya) seems to handle RGB 
material without a color shift but it is limited to yuv422p10."

This is very suspicious.
Can you please use rc8 and post your file that seems to not have a color shift ?

It would be nice if colormatrix would handle 10 bits, yes. Feel free to send a 
patch or sponsor the feature.

Original comment by [email protected] on 13 May 2013 at 8:56

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Original comment by [email protected] on 13 May 2013 at 8:57

• Changed title: rgb to yuv422p10 color shift PRORES issue
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Can you also please upload your source file somewhere ?

Original comment by [email protected] on 13 May 2013 at 9:01

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

After researching the issue further, my summary, findings, and solution are as 
follows:

When encoding HD sized material in ProRes originating from an RGB-based codec, 
there is a color shift due to some misinterpretation of color primaries during 
RGB-YUV conversion.

This can be resolved during encoding by using the flag "-color_primaries 
bt470bg". This avoids or mitigates a procedural color conversion based on frame 
size achieved in lines 282-304 of proresenc.c (as of 0.7rc8). This also seems 
to preserve full 10-bit fidelity.

Rather than writing a patch, it may be more beneficial to include this flag's 
usage in documentation.

Original comment by [email protected] on 10 Jul 2013 at 8:23

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

It's not a proper "fix".

Default:
RGB->601 YUV (due to ffmbc bug)-> ProRes tagged as 709->decoding through 
709=wrong RGB on display

With your tagging:
RGB->601 YUV (due to ffmbc bug)-> ProRes tagged as 601->decoding through 
601=correct RGB on display (but this is not a proper fix) 

This ProRes file has 601 color spaces, where it should have 709, as it's HD 
file. Also some software don't read flags but use matrix based on frame size 
and than your file will still look wrong.

Proper way (for HD file):
RGB->709 YUV -> ProRes tagged as 709->decoding through 709=correct RGB on 
display (and proper color space)

Original comment by [email protected] on 9 Nov 2013 at 9:42

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Related to http://code.google.com/p/ffmbc/issues/detail?id=114

The issue is the RGB to / from YCbCr conversion, all of which are hardcoded to 
601 in FFMPEG / FFMBC. Also applies to SSE / MMX optimizations.

Affected files:
swscale.c
swscale.h
utils.c

Original comment by [email protected] on 30 Jun 2014 at 9:39

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I can confirm that I'm also seeing this issue.

Using either full range DPX or full range v210 files at both 1920x1080 and 
3840x2160 produces a ProRes 422HQ file with ITU-R BT.601 colourspace (according 
to MediaInfo)

Original comment by [email protected] on 4 Feb 2015 at 1:51

• Added labels: ****
• Removed labels: ****