[FFmpeg-user] FFMPEG introduces color shift to DNxHD MOVs
nichot20 at yahoo.com
Mon Jul 9 09:25:27 CEST 2012
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...
> 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?
More information about the ffmpeg-user