Thank you for expanding the user requirements, that is very helpful.
I have reviewed the specification of the Sony camera. I misread the specification prior to my first post, and in consequence I mislead you about HDR recording for which I apologise. The dynamic range of the Sony camera sensor and processing does have the ability to capture high-dynamic range content, but it can only save this onto a local file recording system using RAW encoding. After the files are graded an HDR signal that can be passed across an SDI link is created in either Hybid Log Gamma or Dolby. A quick check with a retail supplier shows the Sony RAW recorder elements are expensive.
This means the SDI output from the camera can only have a standard dynamic range, requiring each shot to be carefully exposed ready for minor adjustment in post production grading.
I think the SVT client record presets cover the expected majority of HD recording. You are correct that you need to use a custom command to send your chosen record properties to the CasparCG server. You can save good solutions in a client preset, speeding preparation of further record commands.
Both ProRes and DNX codecs are well proven in operations. Avid started offering versions of media composer using DNX with Ultra-HD resolution about 5 years ago. The DNX codec is an SMPTE standard (VC-3), enabling wide access to the standard documentation.
The ProRes codec situation is more complex. Apple have not, as far as I can detect, offered the ProRes documentation to any standards body for open publication. There is a recent (January 2020) Apple White Paper about the ProRes codec available here. This document does make it clear that the ProRes in ffmpeg is not an authorised implementation, and incompatibilities can occur.
H.264 decoding is very well specified. Like all codecs intended for distribution applications the documentation concentrates on processing a bitstream. An H.264 encoder is a process that creates a compliant decodable bitstream. Given a file containing source samples two H.264 encoders are likely to create two very different bitstreams, but both of which should decode correctly, but with possibly very different picture qualities.
I think you probably have to test DNx against H.264 encoded with relatively short GOPs. In addition to visual checking of decoded codec outputs for given file size per frame, you may also need to make objective quality tests. There are several psnr software suites available for free, such as the one from EPFL available here on GitHub. One bonus to ffmeg as the encoder is that it can be used to encode a source file at various settings, later switching the operation to input from a device instead of a file.
I do not currently have access to Ultra-HD kit, so I hope another member of the forum can provide an ffmpeg command string to speed investigations.