I've made up a little test bed that compares fu7.7.1 and fu9.0.2. Basically it is a slate frame then 5 frames of Marcie - there is a comp file for fu7.7.1 that makes a DNxHD qt and a comp file for fu9.0.2 that does the same. Below is a screen grab of the result, admittedly on an 8 bit monitor as my 10 bit stuff is in transit at the moment. Top left is the 7.7.1 file displayed in Resolve 14.3.0.014, then clockwise fu7.7.1, quicktime 7.7.9 then fu9.0.2 all in win10.
The good news is the current 9.0.2 seems to display the file with contrast that matches the current Resolve, and 7.7.1 seems to match quicktime (nearly) which makes sense given the comments on changing to a proprietary decoder above. So maybe 7.7.1 is the buggy one, and 9.0.2 is the fix?
One thing I noticed to watch out for - if you read (or if your pipeline uses) a comp file that makes DNxHD quicktimes and was created using 7.7.1 reading it into 9.0.2 has an unseen side effect whereby the compression that was set as 8 bit DNxHD in 7.7.1 gets changed to apple prores 4.2.2 and you have to manually change it to DNxHD SQ 1080p 8bit to get what you would have outputted in 7.7.1. There are a lot more DNxHD options in 9.0.2 (a good thing) but best check that it's still outputting what you think it is.
If anyone wants the testbed files to check for themselves I could post a zip file - it's about 12 megs.
- resultsA
- resultsA.jpg (161.08 KiB) Viewed 1835 times