Transcoding from H.264 HDR to MXF DNxHR 444 issue: Colors are not transcoded correctly

New Here ,
Jan 22, 2020 Jan 22, 2020

Copy link to clipboard


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). 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. The source file looks as it should. I compared them using VLC after transcoding, and the difference is evident.

The source is a MP4 file, H.264 10 bits, main 10, level 5, 4:2:0, HDR, UHD, 23,976 fps. 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. Mediainfo shows the correct info (correct profile, 10 bits, CBR with the right fps, etc).

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. The output says that the source file is BT2020 and that the DNxHR file is BT709. That's the only difference I could find. So, unless FFprobe is not reading the files correctly, the DNxHR video is not preserving its colors after transcoding. I went a step further and transcoded the source file to DNxHR 444 10 bits, but this time using FFmpeg. 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.

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. 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. In fact, I don't think that the cause is the subsampling. Like I said, unless FFprobe is giving wrong info on that regard, I guess something is not working correctly during the transcoding process while trying to preserve the color space of the source file, but I don't know why. Bottom line is that I'm getting a DNxHR 444 10 bits file that behaves like a SDR video, transcoded from a H.264 HDR video, and all the settings for a correct transcoding look ok to me.


Any ideas would be highly appreciated. Thanks in advance.


PS: for the record, I want to transcode the original file because I'm editing with Premiere Pro 2020 and with proxies (DNxHR LB), and they don't sync with the source file, at least not to the level I need. I edit making a lot of fast cuts, so both files must be perfectly synced considering my workflow. Using DNxHR LB proxies and the source file for exporting gives sync issues of about a second (sometimes less than that), which in my case is not acceptable. I'm starting to think that it may be because of the source file being VBR and DNxHR being CBR (or maybe it's because one is non long-GOP and the other is not, idk). When both the source file and proxies are DNxHR, no matter the flavor, the sync issues disappear. And I don't use Prores for the same reason, because in the case of Prores the sync issues are worse, most of the time with delays of several seconds, which is of no use for me.


PS2: Using Windows 10 Pro, latest drivers, latest Klite codec pack, transcoding with Adobe Media Encoder 2020.

Error or problem, Export or render, Formats, How to








Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
no replies

Have something to add?

Join the conversation