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