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

Nathan Rusch nathanrusch at gmail.com
Sat Jul 7 03:18:34 CEST 2012

Thanks for the information Mike.

This definitely clears up the cause of the issue. It's unfortunate that a 
manual preprocessing step is required to achieve 1:1 RGB reconstruction when 
compared to the source material or the Avid codec, but at least it's a known 
constant that can be accounted for. Perhaps I will explore a manual patch in 
the future.



-----Original Message----- 
From: Mike Scheutzow
Sent: Friday, July 06, 2012 10:21 AM
To: FFmpeg user questions and RTFMs
Subject: Re: [FFmpeg-user] FFMPEG introduces color shift to DNxHD MOVs

Nathan Rusch wrote:
> Hello all,
> In trying to troubleshoot another issue, I’ve run across a subtle,
> consistent color shift being introduced by FFMPEG to DNxHD-encoded
> MOVs. Thus, they fail to match both DNxHD MOVs generated with the
> Avid codec, as well as both MOVs’ common source material (an 8-bit
> RGB TIFF sequence).

ffmpeg always assumes the BT.601 colorspace when converting from
RGB->YUV and from YUV->RGB. A patch to fix this is welcome, but no one
has ever cared enough to provide it.

So if you do:

ffmpeg:     RGB -> [BT.601 matrix] -> YUV

other tool: YUV -> [BT.709 matrix] -> RGB

then you get a color shift like you describe.

Workaround: feed ffmpeg with a file containing YUV that's been properly

Mike Scheutzow

ffmpeg-user mailing list
ffmpeg-user at ffmpeg.org

More information about the ffmpeg-user mailing list