In fact, I don't think that the cause is the subsampling. I'm aware that one should avoid unnnecesary transcoding steps, and that upsampling could alter the results (DNxHR doesn't support 4:2:0, which is the subsampling of the source file, so I don't have a choice but to do some upsampling), but I didn't expect such a difference in colors.

How can I transcode the original file to a true HDR DNxHR video, preserving its color space? Is there some kind of limitation of the DNxHR codec or MXF container? I was under the impression that the 444 flavor of DNxHR can be almost considered lossless, and the codec clearly supports all the info and metadata needed for HDR. The result was the same, with the same FFprobe output info, same info with Mediainfo, and no matter if I use Media Encoder or FFmpeg, the videos look very different when you compare them with VLC.

I went a step further and transcoded the source file to DNxHR 444 10 bits, but this time using FFmpeg. So, unless FFprobe is not reading the files correctly, the DNxHR video is not preserving its colors after transcoding. The output says that the source file is BT2020 and that the DNxHR file is BT709. I did some more troubleshooting and opened the source file with FFprobe (command line), and did the same with the resulting MXF DNxHR 444 file. Mediainfo shows the correct info (correct profile, 10 bits, CBR with the right fps, etc). The resulting file after transcoding is a MXF file, transcoded directly from the source file using Adobe Media Encoder 2020, using DNxHR RGB 444 10 bits profile, with render at maximum depth and quality enabled. I compared them using VLC after transcoding, and the difference is evident. The problem is that the resulting video looks very different from the source file, the colors are messed up, sometimes over saturated, others it looks very dark. Hi, I'm starting a HDR project, and I'm having issues transcoding a H.264 video to a DNxHR 444 video (using MXF as container).

Dnxhr ffmpeg windows 10