[FFmpeg-user] FFMPEG introduces color shift to DNxHD MOVs

[Tim Nicholson]

On 08/07/12 12:06, Mark Himsley wrote:
> [...]
> I'd like to post, for posterity, that this will reduce the fidelity of
> your video.
> 
> RGB -> YUV (BT.601) is a lossy transformation (in the sense that you
> cannot go RGB -> YUV (BT.601) -> RGB and expect to get out exactly what
> you put in)
> 

Well lossy because of subsampling and then add in rounding errors...


> AND
> 
> YUV (BT.601) -> YUV (BT.709) is a lossy transformation (in the sense
> that you cannot go YUV (BT.601) -> YUV (BT.709) -> YUV (BT.601) and
> expect to get out exactly what you put in)
> 

Not so much lossy, but more down to rounding errors really IMHO. And
also wasteful of cpu cycles with all that floating point matrix arithmetic.


> Concatenating two lossy transforms is very bad. I understand that this
> is currently your only course of action.
> 
> 
> I think a worthwhile addition to the scale filter (which does the format
> conversion) would be to add a choice of colourspace, much like the use
> of "format" forces the scale filter to change colour format. Tim
> Nicholson has been discussing something similar.
> 

libswscale currently supports 8 colourspaces, and the colormatrix filter
only 4. By default libswscale uses "ITU-R Rec. 624-4 System B, G" which
amounts to 601 coefficients. However it is not clear (to me at least) if
any process ever uses anything other than the default. There are a
number of #defines of SWS_CS_*  in libswscale/swscale.h which never seem
to get used anywhere (well grepping didn't reveal anything)


> Perhaps (this is just off the top of my head, and I'm willing to be shot
> down) something like: "-vf scale=0:0:rgbyuv=bt709,format=yuv422p" may
> tell the scale filter to convert to yuv422p and if an RGB -> YUV
> conversion is needed then use the RGB -> BT.709 conversion.
> 

And fix color_range as well?


-- 
Tim