ZRGARDNE wrote:I personally don't want to be bothered with the faff, DNxHR HQ for 8 bit, HQX for 10-bit, done.
As of my current understanding and (limited) experience, I second this approach.
But there's one interesting boundary case where the different approach works better, see
http://vanhurkman.com/wordpress/?p=3471BTW under the hood DaVinci makes all the transforms and grading in it's internal uncompressed floating point format anyway. So it seems to me that pre-transcoding of the source footage from H.264/265 4:2:0 into something "better" makes no sense (if you are on paid Studio which ingests H.264/265).
How does it work? To avoid problems with H.264/265 decoding "on the fly" each time again and again while editing and grading, you generate optimized media which is good for timeline viewer to run buttery smooth on your hardware. I use DNxHR LB at ¼ timeline resolution for UHD, and at ½ resolution for FHD timeline for both optimized media and render cache format.
But if you are not limited with either NVME SSD space or CPU power, you may use uncompressed 16bit floating-point format, too. According to Alexis Van Hurkman, this format is optimal in terms of IQ.
But be prepared to get your optimized media at a really huge disk space consumption level; H.264 UHD source clip size gets multiplied like ~100x of the size of the original).For the
final delivery rendering, you either use the source files -- if your optimized media and render cache are in a low-IQ codec. DaVinci will re-decode the source stuff and recalculate everything in it's internal format then export into whatever codec you wish.
In this scenario, the delivery workflow under the hood is:
Src H.264 re-decoding into -> internal uncompressed 16bit floating point representation -> do transforms+grading -> export to delivery codec.
If you have done heavy transforms and grading upon your 4:2:0 footage, this means that your delivery may need more bit space to reflect your work properly. So you may well need 10bit or 12bit 4:4:4 for delivering it, thus choose the proper codec for your delivered "master" file.
Or, in case you were using the uncompressed full-size 16bit floating-point format for your optimized media and render cache, you may well use these as a source for your final delivery as well, thus avoiding re-decoding of your sources from scratch altogether.
The workflow under the hood then is, as far as I understand:
Uncompressed 16bit FP optimized & cached media (pre-rendered already) -> delivery codec.